What is the role of business process mapping to internal controls? The Sheffield model outlines various purposes for mapping, including clarity, compliance, process improvement, and training. The Sheffield University guidance provides a structured approach to process mapping, with different levels and options for each purpose, emphasizing the importance of accurate documentation.

I have been doing a deep dive into internal controls over the past few months and one of the sub-texts to internal controls is the importance of business process mappings. 

This post re-states of some super work done by Sheffield University and presented in their ‘Process Mapping Guidance and Standards for The University of Sheffield‘ [1].  Although the content is available elsewhere (e.g. via a certification in Six Sigma), I like Sheffield’s presentation and contextualization.  Of course I can’t leave well enough alone so I have added some of my own thoughts.

1. Love, Hate, and SIGMA
2. Process Design and Deduction
3. Five Levels of Process Design
   1. Level 0: Strategic Process Description.
   2. Level 1: Strategic Process Description
   3. Level 2: Strategic Process Description
   4. Level 3: Tactical Process Description
   5. Level 4: Operational Process Design
4. Don’t Start Quite Yet
5. 10 Reasons for Documenting a Process
   1. 1. Overview/scope setting/clarity.
   2. 2. Diagnosing a process problem
   3. 3. Regulation/audit
   4. 4. System build
   5. 5. Support Agile Development
   6. 6. Process improvement
   7. 7. Process Cost Analysis
   8. 8. Training/ Standard Operating Procedure
   9. 9. Detailed Process Documentation
   10. 10. Understand how a Process Works/ Visualize a Process
6. References and Further Reading

Love, Hate, and SIGMA

I have a love-hate relationship with business process maps.  I love them because that take implicit knowledge and attempt to codify it.  I hate them because they never truly show the richness of the implicit knowledge people apply in their daily work.  Most people cannot read them, and they can become straitjackets or worse yet, a complete waste of time [for more on this read – Phrankism: Documentation is a Waste of Time].

Process Design and Deduction

Process design, such as that used in Six Sigma, is deductive. You start at a general level and the, like the top of a pine tree, and then work your way down. Building on the waste of time theme, the further down you go, the lower the value to all but the most mechanistic processes. This is discussed in the idea of minimal procedure manuals (see reference below).

Where are the Manuals – Minimalism and Procedure Manuals

Five Levels of Process Design

The above graphic demonstrates the five possible levels of process design going from the most conceptual to most detailed. If you are building a very complex system (nuclear reactor, jet fighter, medical system), getting to Level 4 is probably a good idea but most people lose interest or enthusiasm about level 2. Nevertheless, the descriptions for the five levels:

Level 0: Strategic Process Description.

A single graphic encapsulating complex systems in a single image. This is typically done by listing Suppliers, Inputs, Processes, Outputs, and Customers (SIPOC) [2].

• SIPOC: to enable process overview. To identify all relevant elements of the process. Will support scoping of a project and/or process mapping workshop.
• Characteristics: Two to five steps, Table format. Links with Service Design Catalogue.

Level 1: Strategic Process Description

• Level 1 maps are used to show “what” is going on.
  • They are very useful to give a high level understanding of your process to others. They show the basic steps
• Characteristics: No more than ten steps. No decision points. Likely to include primary process triggers and key outputs

Level 2: Strategic Process Description

• Level 2 maps are used to show “who does what”.
  • They are very useful to show the interactions and handovers between teams/functions required to convert inputs to outputs.
  • Understanding these connections is invaluable in breaking down silos.
  • It should help people understand how their work is connected with others.
• Characteristics: Usually 10-15 steps. (often uses the same steps from level 1);
  • No decision points. Likely to include primary process triggers and key outputs.
  • Includes swimlanes/ systems pool.

Level 3: Tactical Process Description

• Level 3 maps show the process at a transactional level and show “how?” work is being done.
  • They are very useful for team members who are in the process.
  • They give a level of granularity of how the work is delivered.
  • These are commonly used for end to end process improvement exercises.
• Characteristics: Swimlanes/ pool, Decision Points, Process detail.
  • A supporting process description and business rules can enhance the usability of this process map

Level 3a: Tactical Process Description

• These maps show the process at a transactional level and show how the work is undertaken for a subset of the process e.g a department.
• It can be used to show variation in processing inputs and outputs. They are commonly used for departmental improvement exercises.
• Characteristics: as for level 3.

Level 4: Operational Process Design

• These maps are commonly used for creating standard operations. The detail should be at a level that ensures that standard operations are followed by the staff within the process. The performance metrics from this should feed into KPIs.
• Characteristics: Full process, detailed for the team/ function that is carrying out the Standard Operating Procedure. Swimlanes/pool, decision points, detail.

Don’t Start Quite Yet

The guidance suggests the following six activities starting with a very wise suggestion of breaking out some paper.

1. Clarify the purpose of your mapping activity
   • So why exactly do you need to create a process map, what is wrong with things as they are now? 
   • Answer: clarity, problem definition, compliance, creating something new, improving something, training or cost analysis,
2. Identify the level/type of process map that needs to be produced
3. Draft the map on paper (in consultation with subject matter experts)
4. Use software to draw the map
5. Verify the accuracy with process owners, actors and stakeholders
6. File and share

10 Reasons for Documenting a Process

If you have your paper ready but are still not quite sure why you need to document, consider these ten reasons (with some editorial comments from me).

1. Overview/scope setting/clarity.

• Overview: Agree on the start and end points of a process and the high level steps. It can be useful to ensure/verify the end to end process.
• Level: 0 or 1
• Other mapping Options: Value Stream Map.
• Phrankism: A picture is worth a thousand words and I like using high level story-boards to describe an overall process and a Value Stream Map is one example.
  • The challenges are that a Value Stream Map may be too restrictive (not telling enough of the story) or a story-board may not be focused enough (not getting to the story).

2. Diagnosing a process problem

• Overview: Diagnosing a Problem.
  • Process health check.
    • Part of the problem identification stage.
    • A map should help identify typical process problems such as failure demand, variation, process handovers, ownership and communication points to key process actors.
• Level: 3
• Other mapping Options: Customer Journey mapping (in collaboration with Persona), Spaghetti Diagram, Service Blueprinting (in collaboration with User Stories or Personae), Rich Pictures.

3. Regulation/audit

• Overview: Regulatory or Compliance purposes.
  • Process mapping to verify whether a process is compliant and/or validate a process adhered to legislation
  • It can also be a useful method of identify process changes to ensure compliance.
• Level: 2 or 4 depending on detail.
• Other mapping Options: Top Down Flow Chart.

4. System build

• Overview: System Build and configuration requirements
• Level: 3
• Other mapping Options: Level 1 and Business Rules documentation.
• Phrankism: My observation of greatest challenge in developing process documents to support system development is their expiry date. 
  • Process documentation is developed and then often quickly abandoned or left to rust in binders or on network drives. 
    • I have seen this in particular with ERP implementations. 
      • If an organization has spent the not-inconsiderable sum to develop level 3 system documentation then they should spend a wee-bit more and find out how they can continue to re-leverage the documentation over the life of the system.

5. Support Agile Development

• Overview: Supporting Agile Development and prioritise development activities with reference to the overarching business process
• Level: 1
• Other mapping Options: User Story mapping Customer Journey mapping (and persona).

6. Process improvement

• Overview: Process Improvement to document improvements to a process, ensure that standard operations can be implemented.
  • This often follows Reason 2. It is essential for Benefits Realisation that the same level maps are used at diagnostic phase as well as improved phase.
• Level: Level 3 (end to end) and Level 4 (post-improvement)
• Other mapping Options: Customer Journey mapping (in collaboration with Personae), Spaghetti Diagram, Service Blueprinting (in collaboration with User Stories or Personae), Rich Pictures

7. Process Cost Analysis

• Overview: Process cost analysis, the map should include an indication of volumes and timings.
• Level: 3
• Other mapping Options: Value Stream Map

8. Training/ Standard Operating Procedure

• Overview: Training and Standard Operations; diagram that can be used for induction and/or on going reference to ensure adherence to the process and standard work
• Level: 2 or 3
• Other mapping Options: Top Down Flowchart.
• Phrankism: I am doubtful of Level 2 or 3 flowcharts are an effective teaching aid except for the most technical procedures. 
  • If you are training someone on how to open the cooling flow to a nuclear reactor or dis-arming a land mine I would agree a good process document makes sense. 
    • For most processes though which are not mechanical in nature I would start with something like a Top Down Flowchart rather than jumping to a more detailed diagram. 

9. Detailed Process Documentation

• Overview: Detailed Process Documentation A highly detailed document where every single process step (every task however minor is represented) and all systems are documented.
• Level: 4.

10. Understand how a Process Works/ Visualize a Process

• Overview: Understand how a process works/visualise a process This activity is almost always carried out in a workshop format involving all key process actors.
• Level: 2 or 3
• Other mapping Options: Customer Journey mapping, Rich Pictures

References and Further Reading

1. The original article has been taken down from the University’s site but fortunately I saved a copy which is provided in the link.
2. There are lots of references explaining SIPOC in the project management and lean management realms, for example:
   • https://www.learnleansigma.com/guides/sipoc-analysis/
   • https://ashwinmore.com/what-is-sipoc-diagram-understand-with-example/