In the last three episodes of my BPM blog I shared my thoughts around the noble activity called process documentation, or sometimes referred to as process modeling. And as I mentioned earlier, this is specific activity is suffering from a bad reputation as being outdated, unnecessary and more. I hope that with the previous three and today’s blog I have swayed your mind a bit to not just understanding that process documentation is important (it’s critical, if you ask me) but also that it can bring much more added value to an organization (think about the transparency and connectedness of all documented organizational artifacts). 

In this last episode around process documentation I would like to visit the topic of organizing the governance. Who is responsible for what and why? Of course, this relates to the way that you have organized your modeling efforts (see episode 34 – organizing your modeling), but let’s assume that you have picked the hybrid form of documenting processes with a limited number of central modelers and a larger number of local modelers, but these local modelers only draft the outline of the process, reuse as much objects as possible and the central modelers safeguard the compliance to the method and conventions (and maybe some aesthetic finetuning). This variant defines who is doing what, but it does not define who is approving and reviewing what, does it?

This is, I think, the core essence of governance. Besides the way of working that ensures that things actually get done, you also need a parallel universe that looks over their shoulders (not during the activities of course, I hate micro-management, it’s the death trap for creativity) at the moment that important steps are done so the result can be validated, reviewed and if necessary, approved (or not). My son is a huge fan of rollercoasters and there is a nice analogy to be found. Imagine you’re about to embark on a rollercoaster, the train comes into the station, the people that just completed the ride get out of the trains and your gate opens up. You scurry into your seat in the train, make yourself as less uncomfortable as you can and you apply all the available safety measures (straps, bars, whatever). Before you can go, two things will always (at least I hope) happen. First of all, there will be parc staff to physically check if you applied the safety measures properly (is everything secured and all) and subsequently a second person (typically sitting up high in a booth and controlling the rollercoaster) is looking for confirmation from the parc staff who performed the physical check and if received, will set the train in motion. Off you go!

Now, where is the analogy to process documentation and governance then?

First of all, the person getting on the train, strapping themselves in is the local process modeler documenting a process (either from scratch, or importing it or even discovering it via process mining) and adding all relevant and available information to it. Sometimes this goes very smooth, sometimes it’s a bit of mess (sometimes strapping in goes first time right, sometimes you can’t seem to get the bloody strap connected). 

Next, the parc staff performing the physical safety check can be compared to the central modelers going over your modeling efforts to check whether or not you sticked to the rules (did you apply the method, conventions etc all properly). The so-called semantic check is something that is always done here (sometimes the local modelers also do a semantic check, but this typically only happens when the local modelers are a bit more mature). 

Finally, the controller of the rollercoaster is your process owner. Ultimately, it is in his/her interest that the processes, for which (s)he is responsible, are documented properly and complying to the standards. So the process owner is the one who set the train in motion by approving the process model and therefore making it public. Again, the process owner needs both other roles (the local modelers for the subject matter expertise and the central modelers for the conformance to the defined standards and conventions). 

In short, when engaging in process documentation, make sure that you’ve put some thought into the topic of governance. What is the RACI table looking like for your organization when it comes process documentation? Who is ultimately responsible for the content of a process model? Hint, it’s never the BPM group (they are responsible for making sure people are capable of documenting a process and that it happens in a consistent manner)…

Having said that, I hope you enjoyed the process documentation topic. The coming month (July) is going to be all about task mining (or process discovery) and the link it has to BPM. 

Ciao, Caspar