Does your business struggle with process ownership? Are your process improvements not “sticking”? The failure of an organization to have in place well-functioning process owners is a common occurrence these days. The root causes (if anyone cares to do a full postmortem) are numerous. We’ve heard it all before; “the organizational structure won’t allow for it”, “incentives are misaligned”, “leaders don’t understand what it takes to be a process owner” etc. I’m sure we can all relate to some or all of these statements.
While all of the above may be valid root causes as to why a process owner is not performing as expected, the focus of this article is to highlight one additional root cause which I feel is much more specific, often gets overlooked and is entirely in the control of the process gurus themselves making it quite easy to rectify. I call it a failure to communicate. The specific lack of communication I am referring to in this case is the complexity with which we as process gurus capture business processes and the language we choose to depict it. What do I mean by all this? Let me explain.
Businesses (and some process gurus) often pay little attention to the true value of proper decomposition of their core processes and as a result, they often jump to tools like Visio (or worse MS Word or PowerPoint) to map their processes at painstakingly low levels of detail as part of their process mapping efforts. Simply put, I often see businesses document their processes at excruciating levels of detail without first (or ever) documenting the higher level process flow leaving business leaders and process owners frustrated and suffocating in the details. Don’t get me wrong, mapping out these details are absolutely essential in certain circumstances, but without a higher level process map existing, your extremely detailed process map simply dangles in the wind like a loose thread never being anchored to any core business process. Why is it important to tether your maps hierarchically rather than just map to whatever level of detail you prefer? For two fundamental reasons:
Another aspect of process mapping communication that dramatically affects process ownership is with respect to the mapping language that process practitioners use when it comes to process mapping. Process & technology teams are so quick to jump to complex mapping notations that business leaders simply do not understand which also contributes to the businesses inability to properly “own” and manage their processes. After all, how can one take responsibility for something which they don’t fully understand? Sure, you might argue that we should teach all process owners BPMN 2.0 mapping language, or that we should have all our business users take training on how to map using UML mapping language, but is this really feasible? Is this even logical? I don’t think so. My experience has been to leverage the most basic and self-explanatory symbols as possible to remove any impediments the business has to actually read, interpret and own their processes. Not everyone in a company is a process guru, nor do they need to be.
Unless we as process practitioners want to own all these processes ourselves in the future then I suggest we rethink the language we use when the processes get mapped in the first place. Fear not my process colleagues, there is a solution! Consider leveraging a more intuitive mapping notation. One of the better notations I’ve seen is called UPN (Unified Process Notation…a great write up on UPN is found here) although well labelled boxes and arrows work just as well. Don't forget for whom we map these processes for and why we map them in the first place. If technology and the process gurus are your customers, by all means pick a mapping language of your choice. If the general business user, leader or executive is your audience, best go with something simpler.
So the next time you are challenged with a lack of process ownership or processes that slowly diverge back to their original state of ineffectiveness, I might suggest taking a look at the artifacts that have been left behind to see how easy (or not) we as process practitioners have made it for the business users to actually interpret, manage and own their processes.