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

The Role of Architecture in Process Models

Sandeep Johal Sandeep Johal on July 12, 2016

Every single process model that you create is part of a larger ecosystem, an ecosystem of dependency and relationships. It definitely is because in real life, your processes are related to one another. In this video, we talk about what that ecosystem framework is, and how to place your models in there. 

Every single model tells a story of the organization, a story of how processes deliver value. However, on its own, it may not fully describe what's going on. More specifically, it may not describe the relationships and the dependencies, which means that each process model that you create on its own may not be able to show you an impact cause at the start of the process, and its effects downstream.

The way process models are linked to one another is through relationships and dependencies. And to show that, we use the process architecture. The process architecture is a 30,000 foot view of the value that your organization delivers to its external and internal stakeholders. The process architecture can be thought of as a set of processes that can be categorized in three areas: Strategic processes on the top, for example, strategic planning, then in the middle of that architecture you have your core processes. Your core processes are the processes that sets you aside from your competitors. For a university, it may be how they create graduates, on the quality of those graduates. And finally the support processes. Support processes are required to carry out the core processes, and these are in the form of your finance processes, IT processes, HR processes. Not organizational units, but processes.

DOWNLOAD PROCESS ARCHITECTURE PAPER

So in this process architecture, every single one of your process models needs to be connected. The connections can be thought of in the form of relationships and dependencies. Simply put, the outcomes or outputs of the first process need to become triggers or inputs into the next process. We find this to be a one to many relationships and that's okay - that's one way to ensure that there is connectivity.

Another way would be to uniquely identify each process model within that architecture. For example, you might use numbers to do so. Numbers that make sense to you. So four numbers might indicate a fourth level process model, three numbers might indicate three, and so on, you get the idea. But you could also give it a unique identifier to identify where it lives within that process. In other words, does it live in the core, does it live in the strategic, does it live in the support? 

A combination of using inputs and outputs, outcomes and triggers from one process to another and connecting those up in an architecture using unique identifiers is the best way to ensure that your process models are kept in ecosystem of connectivity and relationships. You want this because an impact that's caused upstream in the process may have effects downstream. The only way is to understand this through the dependencies and relationships.

Watch Process Modeling Excellence Video Seminar - 45 minutes!

Topics: BPM - Business Process Management, The Process Session, Process Modelling

6 Steps to Follow When Designing Modeling Standards & Conventions

Sandeep Johal Sandeep Johal on June 19, 2016

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!

Topics: BPM - Business Process Management, Process Modelling

How to Use Process Models

Sandeep Johal Sandeep Johal on May 23, 2016

Have you thought about how process models will be used in your organization? If you have, that's great. Have you thought about the second time they'll be used, the third, or the fourth time? Here are some tips on how to ensure continuous use of your process models.

There is no point in creating process models without a purpose. The point is now how do you ensure that the second and the third time that you use your process models, it's just as effective as the first time. I go back to my mantra which says, create a process model once, it's useful. Use it again, it's valuable. The secret sauce in making sure that any organization uses process models over and over again is not scientific except it's just about making sure that these process modeling activities are well embedded in existing organizational methodologies. Some of the methodologies that I'll be talking about today include change management methodology, process improvement methodology, and project management methodology.

Process Improvement Methodology

First, let's talk about the real obvious one, which is process improvement methodology. This is a no brainer to most. Any time that you conduct any form of transformation in your organization where you go from an as-is, to a, or current state to a desired to-be state, you do some form of process visualization, so it makes sense to have process models at that time. Continuously use them, you know, and change them in order that additional buy in and usage. You'll end up using and reusing process models for anything between communication, as well as, uh, getting people to buy in to a single vision.

Reuse_process_models_Make_models_great_again_1.00_00_08_05.Still001.jpgProject Management Methodology

The next methodology that is pretty common in most organizations is project management methodology. You would have come across some flavor or some form of this methodology in your organization. Some of the more common ones that are used today are PMBOK, which is the project management book of knowledge, or PRINCE 2 methodology. These methodologies also talk about a transformation from current state, an as-is state, to a desired state or to-be state. Their objective is a little bit different. It is to deliver the project on time on budget. However, you can fit some modeling, key modeling activities across that life cycle. Look for points at which, again, you need visual confirmation from your stakeholders and where there is transformation and you can point out the delta in the change. You immediately become valuable, and, of course, so do your process models.

Change Management Methodology

Lastly, we'll talk about change management methodology. Now change management methodologies can come in several flavors, including the traditional Kotter's eight step change methodology, as well as Deming's Plan, do check and act. Change methodologies, or change management is particularly prone to needing visual aid to understand where processes are currently and where they will be in the future. What will that project change? Is that an IT project that will change a system? Is it a process improvement project that will then insure that going forward processes and organizational performan-performance is continuously improved.

Whatever it may be, process models have a part to play and it is your task to identify key points in that methodology that you include process models activities, and, most importantly, inlcude the appreciation of the value of the process models.

Essentially, there are two key take aways  from this video.

  1. One is, if you're going to analyze transformation from an as-is to a to-be state, you need process models. You need process models more than once, at least two times.
  2. The second key point to take note is that whenever you need any kind of visual buy in or agreement between a set of stakeholders, that is when process models shine, so look for any organizational methodologies that incorporate these two things and you will ensure that your process models will be used once, twice, three times, and so on.
Remember creating a process model once makes it useful. Using it again makes it valuable.

Watch Process Modeling Excellence Video Seminar - 45 minutes!

Topics: BPM - Business Process Management, The Process Session, Process Modelling

How to Keep Process Models Consistent

Sandeep Johal Sandeep Johal on May 19, 2016

Models created by different people in different parts of the organization with a different set of skills often create very, very different models. Now, this can be a problem because you are trying to keep models consistent. 

Why would you want to keep process models consistent across different areas of your organization? Well, one simple reason. You want to keep widespread use of your process models.  That's what makes them valuable. And in order to get that widespread use, people in different parts of the organization need to be able to understand these process models. Take for example our language. You're able to understand me because we agreed that the English language is spoken in a certain way with certain structure, certain grammatical tense, and because of that, I'm able to communicate. Same way with process models.

ModEx_-_How_to_keep_process_models_consistent.00_00_06_00.Still001.jpgSo the big question is how do you keep a whole set of process models produced in different parts of the organization or even by different people consistent? Well, just like the English language, I'd encourage you to look at modeling conventions and standards as your key to resolving this issue. Modeling's conventions and standards are actually the set of rules that govern and and show consistency across the look and feel of your process models. So modeling conventions allow you to define the look and feel of your process models, establish the relationships that are important between the objects within your process model. For example, every process step has to have to have an application that supports it to set the levels of granularity as to what you require to see at different levels of your process modeling. And, they tell you about notation.

So what kind of language are you going to use in your process modeling? Examples of notion include, BPMN, DMN, EPC, and the list goes on. Those are not the only things that the modeling standards and conventions are supposed to do. There's a whole raft of other stuff that you can include in those conventions and standards. Very often modeling standards and conventions are stored in a document or possibly even included and embedded in your process modeling tool. Many modern day tools have this capability built in, so that it minimizes the amount of creativity. To develop conventions and standards,

To summarize, the consistency of process models is crucial. Crucial so that you can promote widespread use between two different parties within your organization to understand the same thing. That's the only way to keep these models valuable. You can do that through a set of modeling conventions and standards, which are usually in the form of either a document or embedded in a process modeling tool. And, be sure to tune in next time for the video where I talk about the six key steps of great modeling conventions. 

Watch Process Modeling Excellence Video Seminar - 45 minutes!

Topics: BPM - Business Process Management, The Process Session, Process Modelling

Resolving the Modeler's Dilemma

Sandeep Johal Sandeep Johal on May 16, 2016

Hey everyone and welcome once again to the process sessions. In this video I'll be talking about resolving the process modeler's dilemma. What is the dilemma? You might ask. It's a delicate balance of conformance, accuracy, and fit for purpose for every single process model you have.

Imagine this you have to create a process model for your senior management group and you decide to put in a process model that they can understand easily. Chances that that process model is fit for the purpose of your presentation, but it may be thin on details such as granularity. It might also not conform to those standards that the organization conforms to. Now it may be the case that that's happened, and if it has ever happened to you, or if you can imagine it you're not alone. That's why you need to resolve the modeler's dilemma.

Semantic, Syntactic, and Pragmatic

 I call those three quality semantic, syntactic, and pragmatic. Semantic refers to how accurate your process model is. Syntactic refers to the conformance of your process model to your organizational standards. And finally, pragmatic, how fit for purpose it is. When a model lives up to all of those three aspects you've got a great valuable model.

ModEx_-_Resolve_Modelers_Dilemma.00_00_08_10.Still001.jpgYou want to resolve the modeler's dilemma because you want to create high quality process models that have high integrity. You want to create process models that are consistent across the entire organization. You want to create models that will be used, and for those reasons alone you need to be able to resolve the modeler's dilemma. There are many ways to the resolution of the process modeler's dilemma. One of the key ways in which I do it is to make sure that I've got the right stakeholders guiding me through all three aspects of quality.

For the semantic review, I look upon the subject matter experts to give me guidance on how accurate a process model technically is.

For syntactic standards, I look upon a power user across the organization who can give me clear guidance on how good a process model informs to the standards.

Finally pragmatic quality, I look upon the users and consumers of the process models to then get an understanding of whether this model fits that purpose or not.

When you gather input from all three areas you have a good idea of who the kind of balance that you need to employ in all your process models to make them valuable and successful.

To summarize, the process modelers dilemma is real. Your models could be skewed towards pragmatic or towards semantic or towards syntactic or potentially a combination of. Find a way to balance the right aspects and you can do so by approaching the right stakeholders and getting them involved in your modeling journey. I wish you the best for your modeling efforts and I'll see you at the next one.

Watch Process Modeling Excellence Video Seminar - 45 minutes!

Topics: BPM - Business Process Management, The Process Session, Process Modelling