![appian business process modelling appian business process modelling](https://image.slidesharecdn.com/bpmpresentationfinalss-130514053534-phpapp02/95/appian-bpm-and-building-a-centre-of-excellence-7-638.jpg)
With regard to the reusable subprocesses, I think most folks here would like to know who the 'owner' of the process is. I'm looking into this as part of a project at my work I am also trying to anticipate questions from the group so I can get feedback on those here beforehand and be better prepared.Īt the same time though, I am a huge advocate for best practices in my department, so with regards to this project, I'm responsible for gathering the most common best-practices, organizing and distilling them down so that they are easier for everyone in the department to remember and use. It's easier to just focus on processes and activities. Our modelers (business modelers typically) would never comply with such a naming convention, since it's too hard to understand the benefits from it, but first of all it would generate too much confusions about the abstractions related to enterprise architecture (processes, services, capabilities, functions, roles, etc). Regarding conventions cross organization - this is a very relevant question and from my experience it's much easier not to use such a scheme suggested in my post above. I recommend using the same name for the subprocess shape in the top process and for the embedded subprocesses it self(verb + noun).īut for reusable subprocess there are no limitations naming subprocess and calling activity differently. This is not an issue really since an embedded subprocess is not really a process, and would not be considered as such in a naming convention. Embedded subprocess have to have the same name as the activity in the process calling it. This is not the case with BizAgi Modeler.
Appian business process modelling free#
I'm not a BPMN expert, but I'm normally working with tools where you are free to set the name of an embedded subprocess (Address Verification) explicitly from the naming of the activity (Verify Address) representing it. The naming of an embedded subprocess is limited to how the modeling tool has implemented the underlying relationship though. This is why I never name embedded subprocesses including the name of the calling process (AO - Address Verification). The relationship back to the use of an embedded subprocess would be natural since it cannot be reused by other processes. Is this type of standard convention for naming of diagrams within a project more a 'per project' or 'per company' decision instead of a defined best practice for naming of diagrams in processes that have more than one diagram? What happens when you leave and they hire a new process modeler? Or for when you're thinking about including reusable subprocesses across a number of applications. I would think this would be relevant when your project has multiple suprocess diagrams and those sub process diagrams could have sub process diagrams. Verify Address, so that it is easily relatable back to its parent process? Is there a naming convention with regard to the sub diagram tabs within the modeler project? Would the tab for the Verify Address suprocess be named Verify Address? Or should it be something like Account Opening - Verify Address, or AO - Verify Address, or Acct. Let's say that process has a subprocess named Verify Address. Using your example the diagram tab for the Account Opening process in the modeler project would be named Account Opening. But what I'm curious about tends to relate more to modeler project itself. Jonas, that's pretty much how I handle that aspect of it now. Please point me to such rules, if there are any.Ĭurrently, until I get the hint, I will name the proces, the logically connected tasks, in the gerund form, like "Organizational Performance Reporting", "Managing Accounts Payable", "Performing Help Desk Functions", "Obtaining Vacation Leave". The above mentioned samples like "Vacation Leave" or Accounts Payable" or Help Desk" are nouns and as such entities in my world of thinking, thus they are rather data, or objects. Now you get in some difficulty when you try to name the process. Folks, I have to admit, I come from IT, where methods of an object ("tasks" of the object) are commonly named like "GetDocumentByIdentifier", "SaveFile", you get the idea. Tasks are something you do, so they should be described using verbs, like "Fill form XYZ", "Obtain signature", etc. Isn't a process a set of logically related tasks (possibly with events) delimited by a start and end node. When I look at the sample processes provided on the site, I see nouns like "Vacation Leave" or "Accounts Payable" or "Help Desk". I'm wondering if there are naming conventions in business process modeling.