I blogged last week about Human Interaction Management as a process modelling notation, along with some dissenting opinions that favour BPMN for process modelling. I tend towards the BPMN camp, and don’t see any benefit in using different modelling notations for some artifical divisions between “human” or “system” processes, considering that the goal of most BPM implementations is to convert some of the human processes into system processes in order to gain efficiency.
One of the biggest problems with any process modelling notation is that the techies (and, having a very techie background, I sometimes fall prey to this myself) tend to put too much detail in the models that are used to gain consensus among all stakeholders: once a model gets past a page or two, anyone who isn’t intimately involved with the modelling efforts won’t understand it — not because they’re not capable of understanding it, but because they don’t want to spend the time tracing through pages of stuff that has way more detail than they really need to know.
In a recent article on Keeping BPM Simple for Business Users, Michael Havey discusses the inherent problem of comprehensive notations such as BPMN or UML activity diagrams: the business users don’t understand them. Well, they get the gist of them, but don’t understand many of the finer points of the notation, which means that much discussion of the business processes during requirements gathering and functional design ends up being about the notation rather than the business processes that are being modelled. He proposes a “dumbed down” notation of just boxes and arrows, but I think that by modelling processes at a higher level for general communication with the business users, they can understand the notation: I think that the bigger problem is too much complexity in the diagrams — such as trying to present business users with sufficient BPMN detail to map directly to executable BPEL code — not an overly complex notation.
There’s been a significant focus on process modelling notations in the past few months, both as an adjunct to a BPM initiative, and as a way of modelling non-automated processes as part of a Lean or Six Sigma process improvement initiative. As process becomes a key competitive differentiator for more and more businesses, that interest will only increase.
We in the IT space often get accused of blinding the users with heavy notations that, more often than not, they cannot be bothered to try to understand. However, I have to agree with you re the complexity of some of the process diagrams I have seen from technical and process specialists: way over the top for communication purposes.
So, I now have instituted my own checkpoint for any diagram: is there “just enough” information for the consumer to understand or am I on an ego trip?
Seems to be working 🙂
Sandy, I agree with you. It is possible to create a diagram using BPMN that it is easy to understand for business people (additional information can be included using text annotations). I think the notation proposed by Michael Havey can be useful to create diagrams that act as a intermediate artifacts, but I would use BPMN for the final artifacts (even to describe processes that are actually executed by people).
Michael Havey missed the loop to business process v2.0 – how do you get back to the business users when updates are required? We don’t have the BPEL-to-boxes-and-arrows converter yet…
In my experience, you should in fact start simple but educate business key users in the course of the project. Next version will be much less painful, for business users to understand, and for the BA to adopt change requests into a readable and processable format