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.