The Process of Process Modeling

Do not be alarmed. This post is not an instruction manual on the finer points of BPMN. For those of you who wish to indulge, this should provide you with many hours of entertainment.

Rather, I want to reflect upon a few thoughts about process modeling, and share some practical hints.

And whilst Blueprint is my favorite modeling tool in existence, the following comments are equally applicable whether you’re using sticky notes, a white board, or the back of an envelope. (I’ve also seen bits of string used quite creatively!)

Process modeling is a process in itself. Therefore, like any other process, we can aim to improve its efficiency, effectiveness and flexibility. So instead of approaching modeling in an ad-hoc manner, how can we make it more repeatable, reduce the cycle time, raise quality and customer satisfaction?

To me, process modeling is fundamentally an exercise in communication. A model may be generated in order to share information between members of a project team about the way the process currently works. Or to share information between the project team and the stakeholders. Or with vendors. Or between a business expert and a business analyst. Or a business analyst and a developer. In all of these instances, the process modeling is not meant to be an end in itself, but a means to identify, verify, and inform interested parties about the way the process is, could or should be.

If we accept the model as an abstraction of reality, a visual representation of various process attributes, then the question arises not so much as to whether a process model is right or wrong, but, like a conversation between two people - is it effective or ineffective? Does it convey useful meaning to the intended audience, or not? A meaningful communication forms a sound basis for action - but a confusing, misleading or ambiguous one cannot be expected to yield a high quality outcome. Garbage in, garbage out.

How then, to create effective, clear, useful communication about a process?

In the first instance: Simplicity. Occam’s razor, “Keep It Simple, Stupid” and all that. Is it really necessary to show every little bit of detail on one enormous process map? Can you, or anyone else, really understand what’s going on amongst all of that noise? Perhaps you can use sub-processes, linked processes, or notes to keep things relatively high level, so the general flow, relationships and dependencies are obvious.

George Orwell wrote “Good prose is like a window pane”. So is a good process model. Make it clear and no more complicated than it needs to be.

Consistency, too, can be of great help. An activity, for example, should be a verb - it represents someone or something doing something. Name similar actions in a similar way, yet make them specific - “Notify Completion” rather than “Send Email” - and apply these principles across different processes. Show similar patterns (e.g. chasing responses) in a uniform way.

Types of process model. Not all process models are created equal. Form should follow function. What are your objectives - spotting opportunities for process improvement; training material; compliance & controls documentation; BPM execution?

The purpose of the model determines how detailed and technical the model should be. A model to be used for training new staff should be broken down into detailed steps with minimal assumption gaps. A “To Be” design for presentation to senior business executives for approval should be more high-level and descriptive, and be sparing with objects like decisions, gateways, and events. However, in modeling for execution it is necessary to use such devices in all their glory.

Method. The way you approach process modeling may impact how complicated or simple it turns out. You don’t have to model one perfect box at a time, it’s fine to draft something out from end to end, then go back & make it more consistent, more concise - or more detailed if necessary. Remember, there’s no right or wrong as such! Get agreement when you have the full process width, then following significant revisions.

Have you got it wrong if you end up with spaghetti? Well, it depends. Maybe your current process is spaghetti, in which case that’s a useful thing to share. But you wouldn’t want that for a “To Be”. It’s usually possible to take a higher-level view, and maintain the detail behind the scenes, utilizing linked processes, sub-processes, and notes as appropriate.

I believe in process modeling as a means to an end….ideally for improving the process, and sharing process information with those who need to understand it. I urge you not to get caught up modeling for modeling’s sake, but as a precursor to action. And remember, communicate not obfuscate!