Process Modelling: Setting Yourself Up For Success. A Pragmatist’s Guide (Part 2)
In Part 1 of this article, we looked at what we want to achieve out of a process modelling exercise, so now let’s consider the how.
Factors to Consider
This may be the most complex area separating success from its alternative, but the many possible permutations and variables boil down to these following factors:
What scope to model
What level of detail to model (granularity, exceptions)
How to model (notation)
Who to involve
Let’s take a look at each of these in turn.
Process scope may seem obvious, but getting this right can have an enormous impact on ultimate project success and ROI. There are two main aspects of process scope to consider. Firstly, get a clear definition of exactly where the process begins, and ends, for the purposes of the exercise at hand. The answers may not be the same as they are considered from a day-to-day internal departmental or organisational perspective. Get it wrong, and you may load a downstream project up with more scope than it can achieve, or miss out on fertile territory for root-cause analysis and remediation. Using a simple technique such as “SIPOC” (Supplier-Inputs-Process-Outputs-Customer) can be very helpful in framing this correctly. Secondly, identify and get agreement on which sub-processes are in- and out-of scope (again for the purposes of the exercise at hand). There may well be sub-processes which are outside of your influence or remit, or just too problematic, to realistically address, and can - or should - be considered a “black box”. An example here is in trying to intricately model a partner organisation’s subprocesses when this information cannot be readily ascertained and is effectively irrelevant from an “outputs and inputs” perspective.
Getting the right level of detail in process modelling is very much the proverbial “an art as much as a science”. Again there are two nuances to this, being granularity and exception paths, and both of these wreak havoc on a modelling exercise in their own way. In terms of granularity, the single most important thing is to model the flow correctly, articulating when work is handed off from person to person, a person to a system, a system to a person, and sometimes a system to another system. I’ll cover this a little more under notation below, but capturing the key tasks, decisions, and handoffs really represents the core aspects of the process to any downstream usage requirement. Additional detail such as keystroke procedures, value tables and the like can always be documented and stored along with the process models, without trying to capture everything in one ghastly complicated "spaghetti diagram”. This is really important to facilitate the shared stakeholder understanding that is so fundamental to a successful outcome. Exceptions are a similar, and often nefarious two-way problem. Few things can kill that simple, shared understanding better than a multitude of infrequent exception paths being modelled; and yet these exception paths are often there for highly valid and relevant reasons. Glossing over them can lead to insufficiently sophisticated solutions and an ongoing plethora of nasty workarounds. Again, the art is in representing the exceptions that are frequent and/or important; and yet capturing the fuller details in a way that they can inform subsequent project efforts without clouding the bigger picture.
Notation is another significant factor in producing clear, effective and usable process models. There are various common modelling notations available for use, including some that are recognised standards. In addition, many enterprise applications have their own proprietary model notations. There have been many, often fervent words written on this subject, but this is “A Pragmatist’s Guide” and I have a very pragmatic recommendation. BPMN, ("Business Process Model and Notation”), a standard notation from the OMG, is the basis of my recommendation. It is widely used, which is not always the case with industry standards, and when used in “swim lane” format it is in my opinion the most universal and readily understood way of charting the flow of a process from beginning to end, and across different participants and systems. When done well, of course! Utilising BPMN helps meet the “clearly captured” success criteria above, which in turn strongly supports the “engage stakeholders in a collaborative manner” criteria. As an added bonus, modelling with BPMN provides the basis for readily orchestrating a process in one of the several process management platforms that have adopted the standard for WYMIWYE (“What You Model Is What You Execute”) implementation.
BPMN is more business-stakeholder-friendly for these purposes than using a software development notation such as UML, and much more universally interoperable and actionable than any of the proprietary software vendor notations. But it is not without its detractors, the most reasonable argument being that BPMN is a very complex specialist’s tool. The truth to that assertion is that BPMN is incredibly comprehensive, with a large number of symbols covering the nuances of an incredible array of complex process behaviours. To learn BPMN to its fullest extent, and to be adroit in its most detailed usage, is indeed a specialist skill. However, in the vein of Pareto, 80% or more of the benefits of using BPMN come from 20% or less of the notation. I strongly counsel organisations to keep their BPMN modelling as simple as possible, and annotating detail rather than trying to visually model it all. Noting even if you’re modelling for the purposes of implementing in a process management application that is BPMN-compliant, that the different vendors use different subsets of the notation. Keeping it simple also means keeping it application-agnostic and this will reduce your costs and issues whatever path you might subsequently take.
Last but absolutely not least, who should you involve in your process modelling? Time is always a constraint, as is often geography, but ideally you should include representatives from each department, team or area that is involved with delivering the process. These participants should be knowledgeable in the detail of the process, and collectively should cover all the different perspectives of the process, including management and technology. Wherever possible, I recommend using a workshop format, with most or all of these stakeholders participating in real time - even better if they can all be in the same location at that time. This approach best supports the collaborative aspect, creating more of a shared understanding and mutual appreciation than one-on-one interviews. It also reduces or eliminates the rework loops of doubling-back to people with follow up questions and requests for clarification, when a subsequent interview yields information that is in conflict with earlier statements.
It is also important not only to capture a wide variety of inputs to the modelling process, but to broadly share the outputs for appropriate review and validation. It is all too easy to capture information incorrectly, or make assumptions or translation errors, and it will never be cheaper and more expedient to remedy such errors that at this point, before any changes are made to the process.