Are there Naming Conventions in Business Process Modeling?

Hi -puzzled- Isabella,

business people have little time and the little they have, they value a lot.

So while it would be more "correct" to say "Managing Accounts Payable", you will never see a request for proposal like this.

You will hear something like "Have you got a solution for AP?".

The same applies to Help Desk, Consumer loans, Mortgages etc.

Perhaps which product lines are supported by the solution (Vehicle claims or life claims?) could be valuable information, but in general the rule is: the shorter, the better.

Regards

Gustavo Gomez 

Hello Gustavo,

in a sort of "lingo" used during a project, I'm sure I would also use "AP" or "Accounts Payable".

Ok, my question is nswered, there is no naming convention.

Puzzle resolved.

Thanks,

Isabella

Hello Isabella,

I do not know of any rules.  I believe the naming conventions would be those related to your profession or industry.  Therefore, I think you are correct in naming your processes by using the logically connected tasks.

In my case, I use naming conventions familiar with me and my audience; "Purchase Order Request", "Accounts Payable - Processing Vendor Invoices", etc.

I hope this helps.

John

All process engineers follow naming conventions for business process modeling. Most widely accepted industry standard on naming business activities or processes is that the name must be a verb-noun combination, beginning with the verb. So when you say "Organizational Performance Reporting", "Managing Accounts Payable", "Performing Help Desk Functions", "Obtaining Vacation Leave", the rather standard name of these processes will be "Report Organization Performance", "Manage Account Payable", Perform Help Desk Function and Apply/Obtain Leave respectively

Hello,

superb! As I thought! But I do catch myself in the act of using nouns or gerunds at best. You can't believe how tickled I am.

Almost dancing around in my office,

Isabella

Does the verb-noun naming convention referred to by @Ashish Joshi also apply to the naming diagrams as well or are there different conventions for naming the diagrams in a project? I'm especially curious as it would apply to a set of parent / child diagram(s). Do you do something like this:

Parent Diagram: Accounts Receivable

Child Diagram: AR - Process Deductions

Or do you do something like number your diagrams 1, 1a, 2, 2a,2b,2c,....

Let me know what you think of this. For activities I'm always use a verb-noun naming convention, while the process implementing that same activity is named noun-nounification. And since we're often dealing with service abstractions the naming would be the same noun, while it's operation will be named the verb.

I.e.:

Activity: Open Account

Service: Account

Operation: Open

Process: Account Opening

Jonas, that's pretty much how I handle that aspect of it now. But what I'm curious about tends to relate more to modeler project itself.

Using your example the diagram tab for the Account Opening process in the modeler project would be named Account Opening. Let's say that process has a subprocess named Verify Address. 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. Op. - Verify Address, so that it is easily relatable back to its parent process?

I would think this would be relevant when your project has multiple suprocess diagrams and those sub process diagrams could have sub process diagrams. Or for when you're thinking about including reusable subprocesses across a number of applications.

What happens when you leave and they hire a new process modeler?

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?

Hi Jeff,

The relationship back to the use of an embedded subprocess would be natural since it cannot be reused by other processes. This is why I never name embedded subprocesses including the name of the calling process (AO - Address Verification).

The naming of an embedded subprocess is limited to how the modeling tool has implemented the underlying relationship though. 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. This is not the case with BizAgi Modeler. Embedded subprocess have to have the same name as the activity in the process calling it. 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. I recommend using the same name for the subprocess shape in the top process and for the embedded subprocesses it self(verb + noun).

But for reusable subprocess there are no limitations naming subprocess and calling activity differently.

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. 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). It's easier to just focus on processes and activities.

Let me know your experiences.

Jonas,

Honestly, I don't have any yet. 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.

At 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.

With regard to the reusable subprocesses, I think most folks here would like to know who the 'owner' of the process is. So for instance, the 'Verify Address' process would most likely be 'owned' (read developed / maintained) by the HR Department, while another process like the one used to assign your office extension would be owned by the Telephone Support Office. So with that in mind, to better catalog and organize our reusable suprocesses (once we develop them) we'd most likely implement something where the process name might be Verify Address, but when someone is looking it up in the catalog it might be list as Verify Address, Owner: HR. Description:....

But again, I can't say for certain because the catalog doesn't exist yet. Once I finish my project the higher-ups will go over the findings and decide what to do from there.