Last week (it was last Monday actually) I shared my thoughts around the dichotomy of process documentation, which in short means that all of the content that you document around your business processes can have two purposes (it doesn’t necessarily means it always does, but it can and will at times); one to capture (and create) the content and two to be consumed by the end-users. If you extend that line of thought you automatically end up with the question: who will be doing the modeling and who will own the content once it’s modeled? In other words, how do you organize the process documentation in your company?

Before I get into this, please allow me to re-iterate the purpose of process documentation and also specifically what it is not. The purpose of process documentation is to create transparency around the way of working over all of the business processes that you execute within an organization. This transparency includes the specification of the activities, the roles, the applications, risks and so on AND the connection these activities et al have to other activities within your organization. Processes are hardly ever completely stand-alone, for example your purchase to pay process has connections to your finance processes, to your raw material replenishment processes (MRP, in case you’re into manufacturing), your supply chain management processes and even your auditing processes and you want to make sure that you capture this connectedness properly to ensure that you can perform an impact analysis that actually makes sense and supports your management of change process (just to name one, and yes, this is my favorite underrated process).

The purpose of process documentation is definitely NOT to make process drawings for the sake of having a process model. I purposefully refer to them as process drawings because if you are using tools like Visio, Excel, PowerPoint etc. you’re not even creating a process model, your creating a process drawing (you can compare this drawing to an architectural sketch of your new house, while a true process model is much more like the construction drawing (yes, awkward timing to use this word) that contractors need to actually build your house). Anyway, the goal of process modeling is not to model, but to create transparency and connectedness.

Now that we’ve got that out of the way, let’s dive into the topic at hand: how to organize process modeling? I believe that there are a couple of components to this question:

1. Modeling consistency
2. Modeling roles
3. Modeling governance

On all three you can right a book and still be done about it, but I’ll give it a go anyway in this blog. Let’s start with modeling consistency. It’s very tempting to give your organization as much freedom as you can in the way that they want to capture their business processes. After all, every process is different and unique, right?….. WRONG!……very, very wrong. Despite the fact that the content of each business process is kind of unique, the way that you can document a business process is far from unique and some consideration on standardizing the modeling of these processes is in order. Imagine the situation that you have documented all of your relevant business processes and you are leisurely browsing through these processes, would it reduce the readability if every process was modeled with their own set of conventions (on color schemes, iconography and connections)? A Business Process Owner (typically covering a wide span of processes) would go nutty and would lose valuable insight and transparency because of it. You immediately now notice that points 1 and 2 are very closely connected (and let me spoil the fun here, so is point 3). 

Good, so we established that it is good to think about the consistency of your process documentation before you actually start modeling. Then the next question will be: who is going to do the modeling? The good news is that there are basically only three options here, the bad news is: how do you pick the right one?

Let’s first examine the three options, which are:

1. Fully centralized modeling
2. Fully decentralized modeling
3. Hybrid modeling

Even though I think these options do not even need further explanation, I’ll do it anyway (it’s all about alignment after all). In a fully centralized modeling concept there is a group of people somewhere in the organization where all of the modeling work is done (as a central team, hence the name for this option). The upside of this is that these people will be very experienced modelers in no time, the downside is that these people do not necessarily have sufficient knowledge on the business process context and thus have to do a couple of iterations with subject matter experts before the model is good enough to publish. Next, the fully decentralized concept in which the modeling responsibility is basically placed on top of the responsibilities of the people executing or managing the processes and as you can imagine, the upside is that these people know their own process inside-out, the downside (and this is a huge downside) is that they do not model frequently enough to go fully thru the learning curve and become great modelers.

In the middle there is the hybrid model where the flexibility and agility lives. In all case, I believe there is a lot of merit in having a few (to start with 1 or 2, later to be expanded) people who define the modeling conventions, do most of the initial modeling and are able to train other modelers later on. Besides these centralized resources, you can consider to identify 1 or 2 people per business line (most typical role for this is that of the Subject Matter Expert (SME)) and train them to become modelers too. SME very often work with business processes all day and every day and it will provide them with some great tooling to better help their internal customers. You could even go a step further and consider the following situation: you engage with a BPM platform that allows for smart modeling (for example by being able to import tables that contain the process relevant information and turn this into a process model) so that virtually everybody could create the first high level draft of a process model. This draft could then be further professionalized by either the experienced SME modeler or even the central modeler. This way you can capture the essence of a process model, while at the same time not burdening the process executioners with the administrative tasks of completing the model and bringing it in line with the modeling conventions.

One recommendation that I always give to my clients and prospects is: never just add the full process modeling activities to the process executioner’s workload, that will never ever work. They will almost never be fully engaged with these additional responsibilities and the quality of the output will reflect this, which in turn will not help the organization to achieve the transparency and connectedness that is the main purpose of process documentation in the first place. 

Finally, there is not one solution that works best in every situation but understanding that you have options (with pro’s and cons and consequences) is good to know. It will enable you to make a more conscious decision about it. By the way, as a little disclaimer, the pro’s and cons I’ve mentioned in this blog are not the only ones, but the most obvious ones. So, rest assured, there is more….

From a very hot Netherlands, speak to you next week…

Ciao, Caspar