The subject of how to perform process analysis and design is essential for those who believe that it improves the workings of a business to define its processes. Mark Cotgrove wrote about ‘Which language should we use then?’ and he comes to the conclusion that one needs two languages for capturing manual (I would say human) activities which he also refers to as ‘above the line’ and automated activities as ‘below the line’. His options are BPMN, EPC or UPN. I admit that I don’t fully understand what his advice is. He does not touch the fact that to a large extent human processes can’t be predefined as they are mostly unstructured and event driven. As it happens, even EPC (Event Process Chains) can’t handle this, because one doesn’t know which events appear when and often enough there are completely unexpected new events. An event is not defined by its event signature, but much more by the context it happens in. In some context the event can disrupt the process, while in another it is irrelevant. These situations are impossible to model a priori, despite EPC being better suited than BPMN. What is needed is not a different design language but a process/case environment that allows to capture events into a context and empowers the user to perform goal-oriented, event-handling activities.
But the discussion is not just about languages or notations, but also what should be defined by them to manage process improvement. Scott Cleveland reacted with a post to an eBizQ question on ‘Capturing AS-IS processes’ saying that business processes in large organizations are remnant legacies of “that’s the way it has always been done” that have to be improved.
He suggests that you can’t make an improvement if you don’t know what you are trying to improve. One needs to compare ‘before’ with ‘after’ to know if efforts have been successful. I question if that is not a 1993 ‘process re-engineering’ mindset to improve time and cost parameters of existing processes. It simply means that innovation could only happen through the governance bureaucracy and not through the process owner and performers. Comparing old and new processes focuses on squeezing them like a lemon for efficiency and that means mostly reducing manpower. Scott says that success is defined by numbers that have to be shown to upper management. I don’t see it. Success happens if performers find it easy to service customers and it improves the perceived value. Process improvement must focus on meeting goals and delivering outcomes, while only observing efficiency metrics.
I did already say on eBizQ that spending time to capture as-is processes is a waste of time. The time must be spent on defining the business architecture models before anything can be captured, defined, guided or improved. The process in terms of flow is irrelevant for improvements. If you bring in Six Sigma improvement methodology you try to reduce bureaucracy with more bureaucracy.
Let’s face it: this is not about what standard flowcharting language to use. All standard languages and notations are foreign mush to your business people. It is not about how, if and when one captures as-is processes. Processes can at any time – through an unexpected event in a certain context – go from being well defined to totally unpredictable. The only relevant thing is: How can I still handle unexpected events in a process context and execute through my normal process environment? How do I empower people to turn this process to achieving its goals and delivering outcomes still?
Mark says, that he can’t see how one can disagree with needing two different languages for two different audiences. While I do agree that BPMN is unusable for a business person, so is every other flowcharting notation. For the non-technical business user the process environment must not require the use of the process definition language, while it can still be there underneath. The key issue is that BPMN, EPC or UPN describe no more than 20% of what the process needs to execute. Flowchart pundits completely ignore all the real-world aspects of processes that business people understand and need.
Business users care about real-world entities such as customers, cases, states, events and related inbound and outbound content. They care about rules that constrain them, what goals they need to fulfill, what authority they have to execute and how all this information is presented to them. All these entities must be presented to the performers in understandable form and allow them to interact as needed. These entities cannot defined by BPMN, EPC or UPN as they lack the semantic capability.
So is it a technobabble issue? Yes, but unfortunately even the technical approach is unsound. We cannot have systemic breaks in our process/case environment and live with a fragmentation of process types or worse process languages. Add to that the principles of social interaction, and complex business events and the recommendation for analysis or design of human or automated processes in some language simply falls apart. Also human interactions need to access data in the backend silos and they may be requested from or kick-in well-defined, automated process structures. I don’t see how multiple languages would help with any of the above.
Conclusion: It must be the previously listed entities of the Business Architecture that describe the process for the users in business terminology. The system has to empower them to work with those with goals, authority and means. It has absolutely nothing to do with one flowcharting paradigm or the other. If you don’t have a Business Architecture to describe them, it is irrelevant if you capture as-is processes in advance, through simply performing them, or not at all. And suddenly you will find that the kind of language used to define the few flows needed becomes utterly irrelevant. A Business Architecture is a must prerequisite for a BPM project to enable the continuous innovation of processes through the skills and experience of the performers.
The language of process for your business is thus defined in your Business Architecture!