Uncovering the Pitfalls of Business Process Visualisation

Most Quality Control and Quality Assurance methods are concerned with business process mapping as a way of understanding a business transaction lifecycle from the customer's point of view. One widely held view is that business processes are far easier for employees to understand and follow when presented in a graphical representation. If an employee can visualise the workflow, it is easier to follow the steps, understand progress, and identify weak spots in the procedure for improvement.

Techniques for process representation can differ across methodologies. Six Sigma methods may use a process map or a SIPOC (Supplier, Inputs, Process, Outputs, and Customer) model. ISO 9001 may use flowcharts to capture the steps in a work instruction or procedure. Business process modelling (BPM) uses a graphical notation for capturing a business process diagram (BPD). Project management methodologies (e.g. PRINCE2) call for graphical representations such as a Product Flow Diagram (PFD).

Frequently, the goal is to use these graphical views in a corporate Intranet or a Business/Quality Management System (QMS). After all, processes "describe what we do as a company" and "the way we work around here". A good process description should help employees zoom in on what they need to do their job.

However, there is often a large gap between the goal of process mapping and the achievement of successful projects.

There are at least 10 things that can go wrong:

1. Intranet projects take six months and more to deliver, and can be out-of-date as soon as they arrive
2. The processes can be more organic than first envisaged
3. Building models can become a task for analysts, disconnected from the rest of the business
4. The Process Owner (the individual with actual responsibility for a process) may not engage until after a QA team has completed its work
5. The devil can be in the detail where process edge cases are concerned
6. Procedures can become “prematurely frozen” and inflexible
7. Conditions may change faster than it is possible to update the diagrams
8. If there is too much flexibility, the procedure is interpreted almost on a per-instance basis, with little to offer for achieving consistency and repeatability
9. It is almost impossible to keep the QMS integrated if it depends on separate and unconnected resources kept in many spreadsheets and databases
10. There is a Catch-22 in a QMS: the more procedures and forms that exist, the more risk of any individual document being non-compliant

All of these are frequently seen problems in a QMS or process improvement project.

What is the solution?

Previous advisors on this have talked about establishing a steering committee with a balanced mix of participants. Nothing wrong with that - executive management participation shows leadership commitment and is more likely to be tied-in to key business objectives; there's a voice for process owners at all levels; and the project is not overly IT or BPM expert-driven. But "committee-driven" sounds a little too circa-2005 for today's adept social networkers.This is really about giving people the tools to work better and faster.

There is an overlap here with the task of building web sites (including Intranets) and the benefits of using a CMS (content management system) for that.

The main benefits are that non-technical contributors can prepare content ready for publishing online without any required knowledge of HTML or web development. The design elements of the Intranet are kept separate, again removing the need to worry about style sheets and ensuring that there is a consistent look and feel.

There is an argument for role separation. I envisage the Quality Manager as the "QMS Editor" and others as "QMS Contributors". But even the QMS editor is not a web developer, so the CMS element must be very simple in order not to become a technical barrier.

My observation is that employees have different skills and aptitudes for process-orientation. The trick is to find those that are good at it, are interested in participating, and co-opt them to the team. This is a good point at which to grasp the overlap between Intranets and Enterprise Social Networks. What could be more inclusive than employees adding "this is how we do it" diagrams? It is now starting to look like a social Intranet.

But employee-generated content brings the same issues as user-generated content, and with even more potential for mis-information. So, it needs curation.

This is the role of a DMS / ECM. The contributors need to add their content to a well-organised system with clear workflows. Versions must be controlled. Ownership must be clear. Reviews must be structured and easy to follow. Approvals must be explicit and trigger next actions. Publishing must be automatic.

In CogniDox we already have the DMS / ECM elements. In a follow-up post I will speak to the former - how to provide a simple CMS for the QMS Editor.

This post was written by Paul Walsh