Process mapping is boring?!

Open any book on business change, process improvement, enterprise architecture or systems implementation methods and one activity is certain to feature early on in the recommended approach – process mapping.  Documenting a graphical representation of the processes, activities and tasks that the organisation performs to execute its business.  Whether that be the current or future state, capturing process descriptions is seen as an essential task for any business improvement, change or systems project.  However, for the participants, those that are being asked to give up their intimate knowledge of the processes they work with, it can still be a hard sell.

Too often the activity of capturing processes is positioned as, or at least the participants perceive the production of process diagrams to be, the purpose and the deliverable – mapping activity has a tendency to become self-justifying.  The amount of time and level of detail that is required to capture processes, gathering the underlying data and information, seen as boring, a drain on resources, even an unnecessary task conducted to educate the consultants and sometimes even a personal threat.

So why is process mapping identified as being so important? What can you gain by documenting processes?

Some of the potential value of process mapping includes:

• Analysis and problem solving – used to uncover issues, bottlenecks and come up with ideas for improvement
• Process improvement – identify non-value add activities to improve process effectiveness, efficiency, decrease the opportunity for error or reduce costs by eliminating non-value add activities
• Elicitation of requirements – the discussion and narrative that occurs when you map processes is used to frame and understand business requirements
• Identify interfaces and hand-offs – useful in defining service agreements and contracts between organisational entities or to specify system to system interfaces
• Alignment of roles and responsibilities – which can be used to target training and define security requirements
• Communication and training tools – the diagrams can be used to provide context for education and training. This is especially effective if communicated by somebody who was involved in their generation, to provide the “colour commentary”
• Hand over documentation – in outsourced arrangements with an external service provider, process documentation should enable a better understanding of business operations, process activities and systems configuration. This is one of the purposes that may manifest resistance from participants who feel naturally threatened by such business arrangements
• Alignment of performance metrics – both for process level and individual personal performance measurement, process maps enable measures to be defined and positioned at the appropriate part of the process to create leading and lagging indicators
• Support for compliance and control processes – using process documentation to provide evidence of operating standards and quality controls to achieve industry or regulatory compliance and certification

Above all, the capturing of processes creates a shared understanding and a common language for the organisation.  It makes end-to-end process flows and interactions visible.  Depending upon how they are used, process maps provide the basis for improvement and change, as well as a framework for day-to-day management and controls.

There is as much, if not more value in the process of generating the documentation and maps, as there is in the end product diagrams themselves, but the mapping activity needs to have a clear set of objectives and shared purpose.

The approach and techniques used in process mapping should be easy to understand and supporting tools intuitive; complicated and abstract techniques and tools will only engender resistance to the task.  Approaches should encourage or enable an “outside in” or customer perspective of how things work or could work – a process that does not deliver what its customers need is not effective; a process that is inefficient does not give the participants/actors what they need either; a requirement that is not captured from the users perspective will not deliver the experience that is required from a successful system.

The diagrams and documents need to be in a form that is easily understood, communicable and accessible.  They need to have the ability to stand-alone with limited explanation but must retain and be able to convey the information that underlies the process map, so that those not involved in their creation can still extract value from them.  The burden of and commitment to maintenance needs to be assessed upfront, you do not want to be repeating the exercise in 3 years’ time, because the information is out of date and a different set of participants do not feel any emotional attachment to the original documentation.

View process mapping as a means to an end, not an end in its own right.  Be clear on the purpose and objectives of process analysis and mapping. Explain to contributors the expected value and handle any change management concerns up front; provide context for the activity – is it to capture today’s processes in order to … or to capture a common perspective of the “to-be”, providing a target description of the future state that the organisation wants to be at/in? Do we want the ability to map the gap/changes that will be required to move from the “as-is” to the “to-be”? Are we trying to define requirements for new processes and systems? How will the documentation be used afterwards?

So, when somebody says, “we need to map our processes” don’t be afraid to ask “why?”.  It is certainly an important stream of work in any project.  If you understand the objectives and purpose, then chances are there will be less resistance and better quality as a result.

What’s your perspective? Do you have any hints or tips for improving the effectiveness of process mapping activities?