<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">

The Leonardo Blog

All Posts

6 Steps to Follow When Designing Modeling Standards & Conventions

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.

Watch Process Modeling Excellence Video Seminar - 45 minutes!

Related Posts

Are We Too Good at Fixing Process Problems?

Arriving at your destination airport to discover that your checked-in bags are somewhere else is a sufficiently common occurrence to have travelers staring anxiously at the stationary carousel, then fixedly watching the point where bags are first seen, and then breathing a sigh of relief on seeing their bags finally appear. SITA reports1 that 4 billion passengers checked in 4.5 billion bags last year. While only about six bags per thousand passengers get lost, lost bags (more gently termed by the airline industry ‘mishandled baggage’) is a significant problem for airlines, airport owners and managers, and their customers. SITA further reports2 that in 2016 alone, baggage mishandling cost the industry US$2.1 billion, and in the period 2007-2016, the industry cost was a staggering US$27 Billion. The problem is easing3 with the use of new technology, but millions of pieces of luggage are still being ‘lost’ each year, costing the airlines significant amounts, and causing considerable aggravation for travelers.4

A new Leonardo for 2019

The beginnings of Leonardo Consulting started humbly. Our first office was located in the stuffy front room of a small weatherboard house located in the southern suburbs of Brisbane that I rented in September of 1999. Leonardo Consulting was named after the technologist and innovator Leonardo Da Vinci - and was founded to help enterprises implement a little-known BPM tool called ARIS - made by German software developer IDS Scheer. Fast forward to 2014 - we decided to create a technology arm of the business that would help execute on the great architectural work that our consulting team delivered. That small group now has grown tenfold and has developed our business into new clients, new services and new partnerships - both in Australia and worldwide. Together, the skills and capabilities of our current team allows Leonardo to truly delivery end-to-end process improvement - from strategy to execution. Today Leonardo Consulting is more than just a consulting company. We are a 70+ diverse team of developers, consultants, trusted-advisors, technologists, project managers, scrum-masters, coaches, architects, agile delivery-leads, knowledge managers, trainers, analysts, pre-sales, channel marketers, business administrators and team-leaders. Just as people and businesses evolve, so do brands. I am excited to announce we marking a new chapter of our company - we’re evolving our business to simply ‘Leonardo’.

Leonardo at the Red Hat Forum in Sydney

Leonardo will be exhibiting and presenting at the Red Hat Forum in Sydney at the Hyatt Regency.  Our presentation topic will be 'Using Processes-as-Microservices to Drive Better Customer Experiences' which presents an approach that combines digitised processes, business rules, and microservices that collectively deliver improved customer experiences through event-driven digital “micro-moments” – those brief interactions with your customers that can sometime be neglected.