The phrase “make things as simple as possible, but no simpler”, usually attributed to Einstein is a perfect starting place for my first blog post [sound fanfare].
I want to look at process modelling and specifically the development of process models using BPMN and the cultural challenges it can face. I’m a huge fan of this standard and really believe in its power as a communication and requirements development tool. However, it can get a bit of bad press. A lot of it has stemmed from the development of the BPMN 2.0 spec and its efforts to define executable BPMN 2.0 models. Personally, I’d also add that it comes from the belief that the perceived simplicity of traditional flowcharting is enough to define modern processes.
One of my greatest bugbears when it comes to process modelling is that this discipline, more than any other, seems to attract calls of “but the business won’t understand it” if one tries to apply the rigour of BPMN. It’s claimed not to be “simple” enough. I have two main problems with this stance:
- It undervalues your business stakeholders – what surprises me most is that I hear the “business won’t understand it” mostly from other analysts and IT people: “My stakeholders simply won’t follow that”. Really? The business people are the ones with the expert knowledge of the process! They know the different events that can occur at different times and the effect it has on the process, which leads onto how…..
- It understates the complexity of real processes – I’ve had any number of conversations where I’m documenting a process and a business SME will say something like, “Oh, but the customer can also do x at that point, which means we then have to do y”. Most processes are complex and these complexities usually come in the form of events. The expressiveness of BPMN events allow these complexities to be articulated clearly, indicating whether the event diverts the flow of activity (interrupting event – customer cancels an order) or whether it triggers a parallel set of activities (non-interrupting event – customer updates email address details whilst order is being processed).
So by all means, make the process as simple as possible, but no simpler because the reality is that processes are complex.
The shock can come from the fact that people have never seen the process with all of its idiosyncrasies written down. Seeing the alternative paths, the additional manual processes and all of the possible events that can occur allows people to ask things like, “Why do we do that?” “How often does that occur?” “What happens if that message never arrives?” It’s easier to drive these questions out with a process model because the process can be visualised.
Whilst BPMN shares common shapes with “traditional” flowcharting methods (rectangles for activities; diamonds for gateways; arrows for flow), it recognises that those shapes are not enough to articulate real process behaviour. I’ve seen analysts document processes filled with gateway after gateway after gateway routing flow, creating something truly hideous to try and follow. OK, you’ve used a single shape that everyone understands, but has that really created an understandable process model? The numerous gateways example leads to another discussion on the separation of business decisions from business process, but that’s for another day….
Could it be that analysts are put off by having to learn another technique? Keeping up with emerging practice is difficult at the best of times without the “day job” getting in the way. It can be even more frustrating when the rate of change means that people may approach anything new with some trepidation for fear that as soon as they learn it, something else will come along to supplant it. That’s understandable; it’s almost a full-time job just keeping up with the different social media outlets: what they are, how they’re different and whether we should be using one, some or all of them.
Whatever the reasons, my view is that BPMN gives process models consistency; they can be validated (automatically) in the same way as one would spell and grammar check in MS Word. A validated model means that when this process is revised or reviewed in the future, there is no ambiguity in its interpretation, something that certainly can’t be said for many traditional flowcharts. That means greater reuse, which means less time spent doing the same piece of work over and over again across projects and modellers. The key for me is still communication; people constantly strive to break down language and cultural barriers to enable better ways of working together. An ambiguous model means that time is spent understanding what actually happens when a project should be focussing the way they want things to work in the future. There is a learning curve with BPMN, I won’t dispute that. The off-putting thing about this is that the cost is visible. Reviewing and refining ambiguous models is a hidden cost, because it can just be put down to part of the requirements gathering process. But that happens for each and every project.
I’ve not touched on the actual automation of processes through the use of BPMN 2.0; the one thing I would say in this post is that I believe the analyst is there to bring the business and IT together and the modelling of processes directly into the tool that will automate them does just that. Organisations are continually looking to ways of delivering faster and with greater quality. If requirements are modelled and not just documented, that brings timescales down and quality goes up because the business is reviewing the actual deliverable as opposed to documentation alone. Plus, your processes are now truly reusable because they are the actual process, not just a picture in a Word document. If that’s not a reason to buy-in to BPMN, I don’t know what is!
I’d be interested to hear other people’s experience with their stakeholders and what barriers, cultural, technical or otherwise you may have faced, in addition to your views on whether what I’ve said resonates or is wide of the mark!