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?
Read the rest of this entry »