top of page
  • Writer's pictureNicholas Ross

The Joy of SIPOCs

In my previous post , "Why Swimlanes Sink" I had a wee bit of a rant about how much I dislike the use of swimlane diagrams. "Checklists", I said; "Now you're talking".

I was being only a little facetious. Lists are good. Lists allow processes to be categorised, classified, scored, ranked and filtered. They allow for standardisation of the information captured.

But diagrams & process flows have a strength too - if you can avoid the temptation to allow them to get so complex that the ability to interpret them easily is lost.

Imagine a methodology which combined the best facets of lists and clear process flow diagramming. It already exists, thanks to Lean Six Sigma: SIPOC diagrams.

SIPOC diagrams (Suppliers - Inputs - Process - Outputs - Customers) combine the capture of standardised information with the ability to represent the Process flow element as a (relatively simple) diagrammatic element. Within Six Sigma, the SIPOC is utilised during the first phase of the DMAIC process: Define (the remainder being Measure, Analyse, Improve, Control)

In effect, the standardisation of SIPOC actually means you can capture them entirely ignoring the 'drawing' element - just using a standard spreadsheet template. This makes them a super-quick methodology for capturing a list of processes when interviewing an operational team. The transfer to a SIPOC template - lovely process flow and all - can be done later.

This systemising / coding of a mapping approach which is more ordinarily associated with Powerpoint templates or Visio diagrams was the crucial step in allowing us to harness the key strengths of the SIPOC, multiply those thanks to the power of connected data – and address the most common criticisms of the format.

We’ve seen SIPOC mapping allow a project team to successfully abstract complex investment management process flows and represent an entire asset management function’s operating model in a manner that is presentable to a non-technical audience – while still satisfying the investment managers that the representation was correct.

Making the logical leap that related processes or steps within a process - that could better be represented by an entire sub-process in their own right - could be navigated between and visually connected by a web application allows us to maintain that fundamentally simple SIPOC representation of a process on the surface – while satisfying the need, where appropriate, to allow a user to ‘drill down’ to infinitely granular levels of detail where required.

This simultaneously gives us the power to address a common criticism of SIPOC maps – that they “don’t give the same level of detail as a swimlane diagram” – while retaining the surface simplicity that so appeals to the business process owners. Basically - the more senior the stakeholder, the more blithely abstracted their view can be...

Meanwhile, the elements of a process codified in the SIPOC allow full context of any issues, risks, requirements - not to mention quantitative measurements which allow a rational assessment of candidate processes for improvement. Using SIPOC diagrams to capture the essence of the processes impacted by a project means there is no longer any excuse for the lack of clarity about who, when or why an orphaned technical requirement was created. Everything should be traceable to - at a minimum - a process, and ideally to a step within a process (or to one of the inputs or outputs).

If it sounds simple, or blindingly obvious - that's because it is. To paraphrase Victor Kiam - we liked the principle so much we built the company (that built the software).

In my next post, I'm going to talk about the software we built - Opmodal. That journey from "Hey - I've got an idea!" through despair, anguish, annoyance, triumph, more despair, even more annoyance and finally - the wonderful realisation you may actually have built something really rather useful.

(Originally published on LinkedIn)

27 views0 comments

Recent Posts

See All


bottom of page