Profile picture for user TheBPMGuy

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

by M. Zschuckelt
Posted on Mon, 06/07/2021 - 11:20

Hello Caspar,

Kudos! I see another key point that you mention and that should be emphasized: The stakeholders' process of working together on the plan. Establishing a practice of coming to decisions with all involved stakeholders means aligning stakeholders interests on a regular basis and thus coming to aligned decisions with all of those it concerns. The decision on what to model is based on who shall be involved and aligned. This way you will come to a situation where you model and validate your change decisions well before you even publish them. Documenting your change decisions becomes an integral part of making your change decisions. You use the documentation to arrive at your change decisions and you announce your decisions by publishing the new documentation.

Ciao, M. Zschuckelt

0

Featured achievement

Rookie
Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock