The last four weeks I’ve shared my thoughts on business transformation and the challenges that it brings with it. This month I’m going to elaborate a little bit on one of the more underrated components of a wider BPM approach: process documentation, or as most people refer to it: process modeling. Back in the nineties of the previous century (and even millennium) process modeling enjoyed quite some popularity, very often a part of BPR (Business Process Redesign) projects. The major mistake, in my view, very often made was that process modeling / documentation was seen and treated as a goal instead of as a mean to another goal. I’ll try to put some perspective on it in this week’s blog.

The first question that I think deserves an answer is: why engage in process modeling (or documentation, but I’ll use both terms interchangeably) in the first place? When we think back to the transformation topic of last month, I regularly mentioned that having a single source of truth to make sure that everyone will uses to retrieve information from is a key requirement for a successful transformation. The only way to fill up such a repository is through the activity of process documentation (this activity of course also includes the documentation/modeling of applications, strategies, operating models, risks, roles and much more) and thus this activity is quite important. 

I always like to compare the act of process documentation to the creation of construction drawings when you are building a house. Your architect draws a rough sketch of your new house (compare this to the Level 0 process map for an organization) and the contractor will translate these sketches into construction drawings that the builders on the worksite can actually use to build the house (or: the work instructions and processes that people on the shop floor execute to actually get work done for the organization, let’s say the Level 3 and up). Once you’ve finished building your house you are going to live in it, right? At least, that’s what you hope of course and when you do, you’re probably not going to look very often at the construction drawings, but when you are to drill a hole in the wall (or do even more extensive remodeling) checking the construction drawings might prevent a potential mishap or even worse. So, checking your process documentation before you want to make a change might prevent an unwanted side-affect or worse. 

The key point I’m trying to make here, is that documenting processes never is the goal, you’re not modeling a process just for the modeling, that would be a massive waste of effort and thus money. No, you’re modeling processes in order to facilitate efficient new employee trainings, or to facilitate the management of change process, or to ensure alignment between all the various parts of the organization and their inner workings. In other words, the things you document are put into the repository for a purpose other than just the documentation itself. If you don’t plan on using the documentation, don’t create it in the first place. 

So, to wrap it up for this week… you only need to remember this one thing about process documentation: it’s not a goal, but a means to another end and this end (or ends) can be various however they all play a vital role in any transformation program or continuous improvement initiatives. 

Next week, I’ll share my thoughts on the two sides of the same coin that is called process documentation: consumption and maintenance. More next week.

Ciao, Caspar