Fundamentals of Process Mapping

I’ve written before about the elements involved in a process map. In this series of articles, I want to start at the basics and explain what a process map should contain. I’ve seen a fair few methodologies come and go. Fortunately, methodology seems to be settling down with a few interesting branches appearing. I’ve also seen and used a lot of different process mapping tools at different levels, some more like CASE tools, some more like business process management tools, some just diagramming tools.

The aims of this series
I want to work with better-written process descriptions. I want to pass on best-practice as I’ve seen it after working with a lot of process and business analysts. I’ll discuss why following the methodology is not enough on its own, nor is just creating process maps on their own.

I am not writing against any software lifecycle methodologies, any project frameworks nor am I saying one tool is better than another (although I may touch on that). What I will provide are tips for improving the process analyses that you create regardless of which tool, methodology or framework.

Why am I writing this series?
As part of my BPR activities, I’ve received a lot of process descriptions that are not detailed enough, not internally consistent, not wide enough in scope, have gaps in them…in short, not good enough. It doesn’t matter to me who did the analysis, what counts is that someone (maybe the same person) is going to have to do more work to get it up to scratch.

If the work isn’t improved, then it causes problems further down the line. Some examples of the problems caused:

• increase in customer complaints because agents can’t handle their questions
• having to hire in more people as process gaps are identified
• having longer queuing times because the the time taken to complete the process was underestimated, based on too simple a view of the process.
• delay to process implementation while the correct level of detail is captured
• stakeholder conflict as the invalid process maps highlight distrust between the operational teams and the process improvement teams

I’d prefer it if the process descriptions were defined properly in the first place. So please, distribute this.