It's quite a challenge to keep a whole stack of process models consistent across a different set of stakeholders. You do this through conventions, and today I'll be talking to you about six steps that you can undertake to design good conventions.

Process modeling conventions are a set of rules that actually go through how your process models look and feel, and most importantly, how your content is being produced in those process models. Keep in mind that process modeling conventions and standards are not set in stone, and these set of rules can constantly be updated depending on your requirement, and of course, the purpose of your process modeling. As you move along the journey of maturity of process modeling, you'll find yourself being involved less and less in defining and designing the conventions, and reiterating on them.

There are six key steps that we in Leonardo Consulting undertake to ensure the best quality conventions that you can possibly have.

Let's list them out, and I'll go through each one briefly.

1. Define the modeling information that you need.
2. Define your modeling levels.
3. Define the models used at each level.
4. Define the models and objects look and feel.
5. Define the naming conventions of your processes.
6. Define the modeling categorization or structure that you intend to keep these models in.

So, now that you know about the six key steps, let's go through them one by one.

Define required modeling information.

The required modeling information talks about all of the things that you need to show in your process models, so the obvious one is activity. That would be your main centerpiece. So, the high, it could be a high-level activity or a low-level activity, but your activity has first-degree relationships with a whole raft of things. So, think of the activity as the centerpiece, and relationships, first-degree relationships, across applications, to data, to people, to information. So, this defines the way your conventions are laid out. In Leonardo Consulting, we use a petal model to show you that. Here is an example.

Define the modeling levels required. 

The number of levels is usually defined by the purpose of your process modeling. So, think of the first two levels as your high-level process models, and then your third level onwards as your more detailed process models. It's common to have about five models, but again, this is highly, highly determined by the purpose of modeling.

Define the process models you use at each level.

So, if you have defined five levels in the previous step, you are now to associate these five levels against, say, modeling notation. So, for each level, you could potentially use different modeling notations, but I wouldn't go too far with that. It's very common to see that the first two levels are value chain models and the third level onwards usually is more of a BPMN or an event-driven process chain. This is not set in stone, and your organization might want something different.

Define the objects used and their appearance.

For this one, it's quite straightforward. If you're using a notation like BPMN, you've already had your work, um, done for you, and you can just address these appearances, and the objects, the colors and the shapes, directly from BPMN standards, which are easily available. However, if you decide to customize the look, and feel, and shape, and colors, that's also fine, except then, you are now, um, given the burden of making sure that things are kept up to date and it's a proprietary standard that you've come up with. So, I would encourage you to a, address this by going to the known standards first before you customize. 

Define the naming conventions and standards for your processes and for everything else associated with it.

The naming of objects actually is very important is ensuring consistency across many, many, many process models. An example of an activity would be the verb-noun structure, and when you apply that, I guess you get something like "Approve invoices," "approve" being the verb and "invoices" being the noun. It doesn't have to stop at processes alone. You could go on to applications and have naming standards for that. You could have information naming standards, data naming standards, people naming standards. The list goes on.

Define the model categorization or structure.

Models need to live in an ecosystem, and that ecosystem could be in the form of a process architecture. It's important to keep models in a structure so that you're able to connect these models with other things in your organization or other models in your organization. The process architecture is almost a natural place to put all these models. So, based on that process architecture, you would have categorization of each one of your process models. Alternatively, you could use end-to-end value chains to house your process models, too.

So, where are these conventions, and standards, and rules actually stored?

Well, in our consulting practice, we find two keys areas where you, where you'd come across them. The first one is in a document, like in a Word document. These are good, except you may want to keep them up to date, and they are really a passive entity that sits by the side. Our preferred method is the second one, which is to use an actual modeling tool and come up with the conventions within the tool. That way, you can ensure that they're up to date and used at all times.

Just a quick tip, ensure that your modeling conventions are looked after and governed in a proper way. It's very easy to see them go quite astray if they're not controlled properly.

In conclusion, keep your models consistent by using modeling conventions. To design good modeling conventions, we've listed out six key steps to get you on your journey of good process models.