With thinking caps on, we are ready for process modeling! And because we are modeling with BPM technology, we enjoy modeling where work and repetition are first-class citizens of our modeling tools. (For more information about “work and repetition”, please see Paper I of the series.)
BPM Automation Artefact Life-Cycle
Modeling is “work”, too. In order to be effective in this work of modeling processes, we will need to consider our BPM process modeling skills, our BPM tool skills, our business domain knowledge and also the specific process requirements of our own organization. Typically all these requirements are managed via a BPM programme. Note Gap “A” , between Think and Model. There will always be a gap between thinking and modeling – new business ideas developed since yesterday may provide today’s new “modeling to-do list”.
But even with total modeling readiness, there are modeling and deployment challenges that should be managed if we are realize the full promise of BPM software automation technology. Mastering these challenges is the main focus of this Paper III.
Model Fidelity and Process Modeling Limitations
Until recently, capturing business ideas in BPM software for a new business process has often been quite difficult, unless one is working with the simplest of process patterns. As we have mentioned in Paper I, any software is in essence a simplification of reality; this is of course also true of BPM process models.
Takeaway: Process Model Limitations
Avoid frustration and disappointment by understanding the complexity of the business processes you want to automate – and whether your chosen software solution is a match for those requirements.
Concerning this inevitable simplification, business people and technologists tasked with making BPM process models have in the past often been frustrated because the simplifications demanded by BPM software have been too severe.
BPM software packages have been characterized by seemingly arbitrary restrictions on deployed processes patterns. Whereas a business leader may express a desire to make a given business process, in response it’s not unheard of for the BPM technologist to say “that the software doesn’t make that kind of business idea easy to do” – even when the imagined process pattern makes business sense.
When you run into such restrictions, based on software limitations, your BPM software will tell you that “no, you can’t do it that way”. Again, this can be very frustrating for the business person.
The fact that BPM software technology packages have been characterized by arbitrary restrictions on process models is not a criticism of software packages, merely an acknowledgement of the evolving state of technology. Behind the scenes, BPM software technology is very sophisticated and it's almost a miracle that BPM process modeling is as easy it is!
Let's see where these process model-based limitations show up, and what might be done about them. Here are two key technical reasons for what seem like arbitrary restrictions on process model freedom:
Two Sources Of Process Modeling Limitations
- Process Notation Limitations: Any process notation execution language has been created for the purpose of expressing work process semantics that machines can understand. Whether that machine-friendly language is capable of also capturing the business process semantics desired by humans is a separate question. The BPMN (“Business Process and Model Notation”) language has gained widespread adoption over the last few years and is very powerful. Nevertheless, BPMN is not always ideal for expressing some business process patterns, for example that may involve business case patterns (such as might be found in insurance).
- BPM Execution Engine Limitations: Modeling is one thing; the execution of a modeled process by the BPM software process execution engine is a different technical capability. A BPM software process execution engine is an extremely sophisticated and powerful piece of software: it basically has to “solve” a graph (your process models) in real-time, with all the restraints and interfaces that you’ve included in your model. In an ideal world, you’d be able to model anything (that made sense in reality) and you could then deploy and use the model. In actual fact however, some complex process patterns are harder than others for BPM execution engines to solve. Examples might include complex dependencies, which may also involve re-work (or loops). These BPM engine execution limitations will show up either while you model your desired processes or when you test them. These challenges are not only of interest to academics; desired real-world process complexities often reflect the desire of business leaders to serve customers with greater flexibility and richness of experience!
Certainly there are ways around such problems. But those workarounds rapidly begin to add complexity and inflexibility to your business processes. For example, one way around a certain class of restriction is for one of your programmers to write some code. That might be fine now, but over time your processes will add all sorts of work-arounds, and before you know it, you no longer have process flexibility – changing your process is no longer possible via a fast model / deploy pattern. (This issue is explored in more depth in Part 4 of this Paper III, under the topic of the "roundtrip problem".)
Together the limitations of notation and execution engine show up in limitations imposed on business analysts or others performing the work of process modeling. There are even well-known courses which will teach you modeling best practices. In such courses, some of the course content concerns fundamentals of business process modeling. But some of the content only exists to help you avoid arbitrarily forbidden process model patterns, restrictions which are not business-related, but only artefacts of immature technology.
Oddly enough, there hasn’t been much visibility around this problem: in your author’s view this is because until only recently most BPM programmes were run by technologists and IT-side staff, professionals for whom coding work-arounds are not in themselves challenging. However, as BPM moves from IT-side to business-side of the house, we can expect to see this problem receive more attention. Business people tend to find a resort to coding to be a failure when compared to the reasons for which BPM is adopted in the first place.
Fortunately, academic and vendor research on BPM technology continues to enable ever-more-powerful and easy-to-use BPM technology.
And especially the release of new common process languages (especially BPMN), with wide vendor support, has contributed to improvements in this area.
Now more than ever, it’s possible to “imagine and do”! And enjoy “high fidelity” business process artefacts that closely match the original business vision.
Paper Road Map
There are four papers in the Series: Explore BPM Technology As Revolutionary Enabler:
- The first Paper, “Why BPM Is Unique & Important”, introduces the exciting topic of BPM software technology and why BPM so relevant to business today. Work, process and modeling are revealed as built-in to BPM software, enabling rapid construction of new business capabilities. Published in five parts.
- The second Paper, “Minimum Viable Definition Of BPM”, introduces the whole BPM ecosystem but then zeros in on the Minimum Viable Definition. Promotion and adoption of BPM software technology is facilitated when the unique value of core BPM is clear. Published in two parts.
- This third Paper, “Challenges Of Being A BPM Pioneer”, highlights technical keys to success for a BPM programme. BPM software technology is not mature, and “results may vary”. However, there are ways of narrowing the “cone of outcomes” for your BPM programme.
- The fourth Paper, “Adoption Process & BPM Institutionalization”, covers how BPM software technology adoption can accelerate beyond the current technology grid-lock, a process which is less about technology and more about community.