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!
I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.
Welcome to the Real World! 
Hi Max,
Thanks for this post, definately one I mostly agree with particularly that of the use of BPMN when working with the “Business”. In my experience simply using boxes and lines to help users understand the context of what they are trying to explain is enough to then articulate to the “techies” what the solution may be in the language of their choice.
You mention the underlying Business Architecture should define the language then used for the business processes. Could you elaborate on what Business Architecture Diagrams you are referring to? For example are we talking Enterprise Architecture here? Would you be prepared to share some examples or overviews of the models you feel back this up?
The reason I ask is that I am embarking on trying to formalise how we should continue to map processes at my current organisation. Should we map them blindly? Map them because someone shouts at us to? Or because someone “thinks” there is a problem with their process?
The issue I have is selling such a concept as to spending the time mapping the business architecture as we are under pressure to demonstrate potential efficiency savings which means getting stuck in to the business process before we understand the context in which it operates.
Any help is greatly appreciated.
Thanks,
Dai Williams, South Wales, UK.
LikeLike
David, thanks for reading and commenting.
Flowcharts are ok for presenting an overview of what happened or what could happen. They are actually useless as a way to control a real-world process flow.
The Business Architecture is necessary to structure the business hierarchy and define the language ontology of terms that will describe all necessary resources (data, content, rules, states, events, activities, GOALS) to describe a process and enable the relevant business people to create and adapt those processes as they see fit.
If process management happens ONLY under the principle idea to cut costs then the project is doomed anyway to become a job killer and will never be seen as a good thing for the business by the people who have to use it. Good luck.
LikeLike
“All standard languages and notations are foreign mush to your business people.” — I don’t agree with this statement unless we’re talking about BPMN or other technologist-friendly languages. I find UPN to be very end-user friendly in the many situations where I’ve seen it used.
When it comes to expressing process, it doesn’t get more straightforward than symbols expressing precondition-activity-added value with contextual links and data attached. Business architecture helps enable this, but I don’t think it creates the language to communicate it.
I think your argument underserves the importance of having a systematic way to capture and manage key manual activities and to provide a framework of manual activities that reference automated transactions. I’ve witnessed it being done well and having significant value to the enterprise. I wouldn’t feel so strongly about it but for the visual evidence.
LikeLike
Chris, thanks for reading and commenting. Much appreciated.
It is my experience that the performers don’t really care much what happens in the whole of the process and they do not care much to see it in terms of graphics, while that is not necessarily a bad thing. But they certainly have not much interest to design processes this way. The problem is that you are just talking about ‘process flows’ and leave out process resources while that is the only thing that the performer is interested in: data entities, content and content resources, forms (GUI) and most of all rules, states, events and goals as controls! I don’t see any of that in UPN in a user friendly way. But then I couldn’t find a UPN description on the web to check.
The business architecture defines all the elements of the process and once you provide access to data entities and content they are usually mapped into a backend system. If the process requires a goal that requires an automated process piece than all the user does is to add it to the process/case. Done! He has no need or interest to see how the automated piece flows and where in his process this is linked into.
You approach involves the top-down enforcement of processes. I propose to define the Business Architecture and give users a simple GUI that fits their need to add activities involving the business resources to the execution. Voila – instant process capture. No need for flows.
LikeLike
Max
Perhaps the confusion here is what each person understands by Business Architecture. What Nimbus clients are capturing is a definition of the way their business operates; ie a business architecture. It is detailed enough to be able to initiate workflow development of ERP application configuration.
It is far more than “a bit of flowcharting”, which is maybe the root of the confusion, and has promoted a huge level of discussion on your blog.
So a picture is worth a thousand words. Maybe you should see what we are talking about before anyone engages in more debate?
LikeLike
Ian, thanks for reading and commenting. I don’t yet see a huge debate and anyway debate is good.
The way a business operates is a small part of the business architecture and yes, flowcharts are only a small part of that. That is exactly my position. Where are in UPN the rules, states, events, goals and process resources such as data and content provided to the business user in a functional manner for authorized creation and manipulation?
A picture is worth a thousand words, but just looking at them or just talking about process as in ‘Social BPM’ is worth a lot less than actually doing the process and while you are at it perform continuous innovation.
I provide real-world business architecture templates to executives, managers, process owners, performers and customers. Presented to each one in their best fitting way. Process owners are really the only ones who are interested in flowchart-like presentations.
LikeLike
[…] Business Architecture – Max J. Pucher If you don’t have a Business Architecture to describe them, it is […]
LikeLike
Max
I agree with most of your views, but the last comment is wrong “Process owners are really the only ones who are interested in flowchart-like presentations.”
We have over 1 million end-users in clients who use what you call “flow chart presentations” as their day to day operations manual. It provides the guidance for how they get to forms, documents and how they use the automated applications.
LikeLike
Thanks Ian, again!
I will only make one point on the subject of 1 million users proving anything. I walked into a Carphone Warehouse in London a few days ago and asked the sales representative if he could show me their process documentation. He had no idea what I was talking about … I wondered if I should spend the time and visit more of the stores that I had seen all over town with the same question. I decided not to push it.
As it happens, that is a non-relevant, singular experience and vendor-sponsored, anectodal evidence is just as irrelevant.
I stand by my experience that performers care about THEIR OWN customer interaction and not what the process looks like overall in terms of a flowchart. Process owners care .
Let’s make up: There is nothing wrong with providing a centralized database (operations manual) of process definitions, especially of they don’t enforce execution. But it won’t provide continous improvement and learning except through a process bureaucracy. But that is maybe all the business is capable of and thus its good.
LikeLike