Make [the process] as simple as possible, but no simpler…

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!


10 thoughts on “Make [the process] as simple as possible, but no simpler…

  1. Great post, Nick. Although I am not intimately familiar with BPMN, there are a lot of key points that you have underscored in this post. As rightly pointed by you, it is truly difficult to keep up with learning newer technologies and approaches. The goals of a project or effort must never be compromised because of any tools and techniques; these are enablers rather than impediments to progress and articulation of the problem domain. The two key points that you have stated, very well resonate with me about undervaluing stakeholders, and understating the complexity of the processes. This unfortunately happens for other approaches too, and something to be mindful of.

    Additionally, I would love to know how have you handled:
    1. The learning curve with stakeholders when it comes to making them feel comfortable about the models covering everything using BPMN. When do you see their eureka!?
    2. Breaking down complex processes into simpler constituents, without making them too simple.

    I reckon, these could be separate blog posts themselves. 🙂 But if you have some succinct insights, would love to hear them.

    • Hi Yamo, thanks very much for your comments and glad to hear that the key themes have resonated with you! I am in firm agreement that tools and techniques should never take priority over outcomes; I’ve worked with some delivery methods where I’d argue that you spend 50% of the time doing the work and then 50% trying to figure out how to crowbar it into a particular format! The main counter-argument I’d make to this is where the adoption of a new tool or technique actually has longer term benefits.

      It’s easy to focus on “the day job” as I mention because it usually has tangible deliverables and deadlines; any impediment to that is seen as a bad thing, which is unsurprising as it could increase project costs in the short term and these costs are visible. It’s difficult to measure the future cost of inconsistency and rework. But that means an organisation needs some way of discovering where resource is being spent unproductively.

      I also considered whether it’s a case that as adults, we get out of the habit of learning, but that’s probably another line of thinking altogether! But in all seriousness, the BA “profession” isn’t mandated on the same continuous improvement principles that many others are. For example, with the introduction of the Retail Distribution Review in the UK, financial advisers will have to demonstrate 35 hours of continuing professional development every year. This is similar to nurses and midwives in the UK; if they want to maintain their registration, they have to demonstrate continuous development over a period of 3 years. The IIBA certification means that you need to demonstrate continuous development to recertify, but at the moment, certification is not a requirement of the profession. But equally I could argue against the case for certification in that it forces people down a certain path and stifles innovation. Just because you have certification doesn’t actually mean you can do the job. In summary, my main thought is that in the first line – we get out of the habit of learning; certification mandates that we keep learning, but doing something because you have to isn’t the same as doing something because you want to. I’m always looking to improve ways of working because I enjoy it (tragic as that may sound!)

      To address your specific points:

      1. When introducing stakeholders to BPMN for the first time, it’s a case of a piecemeal approach. I tend to start with a very simple model and then build up a more detailed picture by introducing the new concepts one or two elements at a time and explaining the benefits of each and how they provide more meaning to the model. People understand processes and the complexities that can occur, so it’s just a case of showing how BPMN handles those complexities. The great thing about the elements like events is that if people see an envelope, they know it’s a message and that a clock represents time. I’ve started with a very trivial “make a cup of coffee” example and introduce things like “supposing the kettle has no water in it?” “what if you’ve run out of coffee?” This could get very detailed “what if there’s a power cut?” but this takes me into my next point about understanding what’s important to model.
      2. My approach to breaking down processes is twofold:
        1. Understand the needs of the model and your audience – the scope of the project may not need to map all process inputs, outputs and paths to the nth degree. Understand what’s important and model that.
        2. Utilise Bruce Silver’s BPMN method and style approachBruce’s book has been and continues to be an invaluable resource to modelling with BPMN effectively. His approach breaks modelling into “levels” – Level 1 is focussed on a simplified palette of BPMN shapes that is easily understandable by all. Level 2 goes into the deeper meanings behind BPMN. Level 3 takes us into executable model territory. The use of sub-processes is key, because it allows a model to be defined in increasing detail, but people can choose the level at which the detail is relevant to them. For example, senior management may only be interested in the top-level, end-to-end process articulated primarily using collapsed sub-processes, because they want to see the triggers and outcomes on one page. Day-to-day project stakeholders may be interested in the detail contained within the sub-processes that relate specifically to their area.

      Having written all this, you’re quite right, I could probably get individual posts out of these topics alone! Thanks again for your comments and I hope I’ve answered your questions, but feel free to keep asking!


  2. Thanks a bunch for the detailed comments and explanation, Nick. It is much appreciated.

    No, there is nothing wrong with loving what you do and striving to make it better. In my book “The Five Pillars of a Great BA”, I advocate “Passion fueled driven by talent..” as a first pillar to transcend a BA to perform better. I boldly start the chapter with “If you don’t like it don’t do it. If you were not made for it don’t do it either.” So, that should summarize my viewpoint on doing what you are fit for and liking what you do. It is the yin and yan of happiness from work.

    Couldn’t agree more on the piecemeal approach to get the stakeholders up to speed. I would suggest you take that segment of the comment and write another blog post, on how to get the stakeholders up to speed with BPMN.

    Thanks for the reference to Brice Silver’s website. Have bookmarked it and will check it out; and maybe have him come on a future episode of the “AuthorCast” podcast. 🙂

    Thanks again for the comprehensive reply to my comment.

  3. Pingback: Can you think of a[n interview] when…… | Nick Broom – musings of an analyst

  4. I enjoyed this posting Nick. I agree with your comments about BPMN. I am new to this method, having always used basic flow charting in Visio. I am finding more business users understand the models and they really do bring out some good questions including “why do we do that?” and bring visibility to redundancies and manual processes that could be automated. Keep up the postings….BPMN is a key topic of discussion for me at work these days.

  5. Pingback: I like your [BPMN Method &] style | The Hive Collaboration Central

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s