The Pitfalls of Business Process Visualisation and How to Avoid Them

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.

Visualising business processes is central to many quality and process improvement methodologies—from ISO 9001 and Six Sigma to BPMN and PRINCE2. These visual representations can clarify workflows, improve compliance, and drive consistent performance.

But despite good intentions, many visualisation efforts fall short. In fact, the reality of rolling out process maps often clashes with the ideal—and can derail even the best-planned QMS implementation.

Let’s explore why.

Why Visualise Processes?

The theory is simple:
If employees can see the process, they’re more likely to:

• Understand what’s required of them
• Follow the correct sequence of steps
• Spot inefficiencies
• Improve compliance and quality outcomes

Visuals also make training easier and standard work instructions more accessible.

Common tools include:

• Flowcharts (used in ISO 9001)
• SIPOC Diagrams (Six Sigma)
• Business Process Diagrams (BPD) (BPMN)
• Product Flow Diagrams (PFD) (PRINCE2)

The 10 Most Common Pitfalls of Process Visualisation

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.

The Root Problem: Tools and Ownership

While governance committees have long been recommended to oversee process design, this top-down approach can feel outdated.

What’s needed today?

• Empowerment with structure.
• Collaboration with oversight.
• Digital tools that support fast, user-friendly visualisation—with built-in control.

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

Last updated 1 June 2025