SIPOCs and System Maps

All representations of organisational processes and structures are to an extent arbitrary. At different times, or with different teams and individuals doing the analysis, the representations will differ.

Whilst it is often useful to map a process in detail, it is also very helpful to have a way of representing it "on a page" at a high level. We will briefly look at two alternative ways of doing this, depending on the process context.


For most processes, the appropriate format is a SIPOC diagram, with optional degrees of detail and complexity as required. 


SIPOC is an acronym for Supplier - Input - Process - Output - Customer, which is the left-to-right flow of the diagram. In practice, it is often helpful to work from right to left, in other words to start with the Customer view and work backwards. Note that the process is captured at a very high level, typically 5 to 8 steps. The aim here is to show the scope and broad shape of the process rather than its logic and complications.

For the initial draft, capturing the top line will be enough. As the investigation deepens, the other elements can be filled out, so that the SIPOC is updated as a living record.

The SIPOC can be created via a group discussion; alternatively it can be drafted using silent brainstorming and clustering (see the Tool note for Affinity Diagram).

The SIPOC complements the project charter. The Charter shows what the project is setting out to do, the SIPOC shows what it is that the project is directing its attention to. 

System Map

The SIPOC is ideal for processes that are embedded in an existing management structure. However, it does not show how the process is managed, nor does it show what external processes are required to support it.

The system map does include these two elements, and also distinguishes between transactional (production) processes and the development processes which lead to the establishment and improvement of production processes.


  • Governance processes are the means by which the entity maintains relevance and effectiveness
  • Operations processes (sometimes called Core processes) are the customer facing processes that form the entity's value stream
  • Development processes are non-transactional processes that enable the operations processes
  • Support processes (often but not always shared services) assure the provision of the infrastructure and operational support required for the entity to function

Most organizations have well developed support processes, which typically encompass “shared services” as well as function specific processes such as equipment maintenance and certification.

However, it is also our experience that most organizations’ governance processes tend towards the unstructured and ad hoc - except for “resourcing processes”, which are more commonly known as  “budgeting”, a process with which all managers will be familiar, and whose challenges will take up much time.

Critically, the monitoring processes should track:

  • the organisation's social, competitive and political environment
  • customer feedback
  • internally process performance indicators
  • stakeholder (including employee) perceptions.

This monitoring should be synthesized by planning processes into inputs to the resourcing processes, which in turn drive the change and control processes that maintain the operational, development and support processes.

In a nutshell, all organizations have governance activities, but most tend not treat them as processes that are subject to the same characteristics of variation and predictability as the core processes. There are great opportunities in doing so.

[For more on the "GODS" framework, see this article.]

Process Catalogues

Depending on the maturity of the organisation under review, it may well be a challenge to just name the processes involved, and to structure them into a catalogue that can be used to assess issues and priorities areas for further investigation. Process catalogues are also useful for identifying process ownership and the applicable governance structures that are required to resolve any cross functional issues.

There are various generic and industry specific catalogues that can be referenced as a cross check for completeness. See for example the AQPC Classification Framework.

These guides do not tell you what you should do, but they do provide a useful point of comparison for your own process catalogue.