Six Sigma process documentation with Event-driven Process Chains

Joining EPC and Process FMEA for optimal transparency.

Introduction

Event-driven Process Chains are a process mapping technique which separates process flow into a sequence of “elements”, where each element consists of an event and a function.

Properly applied, this technique can greatly assist the Six Sigma practitioner both in determining the correctness of their process information as well as locate critical areas in the flow.

Going from bad to good examples, we will consider how the Belt’s life becomes easier by a fusion of the EPC process into DMAIC. To simplify this paper, we will not discuss eEPC, which provide the same and much more information as a regular EPC.

The Event: what a regular PFD does not tell you

Let us consider a typical process flow diagram of a simplified Customer Care process in classic PFD notation:

Figure 1

If the Belt has to work with this process, there is much information which needs to be collected external to the process map:

Who is involved in the process, when is the process started, where does the complaint come from, what has really happened within the process – and so on.

Generating an FMEA from such a diagram becomes haphazard guessing: “What’s connected to Requests, what’s connected to Complaint handling? Ok, are we done?”

A poor EPC

Practitioners who consider EPC a modification of PFD might deliver this kind of EPC:

Figure 1

This will at least answer the questions “When is the process started?”, and in part “What has this process actually done?”?

This representation completely mystifies “Where does the complaint from?” – hiding even at which stage the complaints might arrive.

This is our first sure-fire hint that something in this diagram is missing.

How to recognise that an EPC is incomplete

The EPC notation above is incomplete: The “Process Request” function does not terminate by generating an event: in classic SIPOC terms, that is a process without any output.

Functions which do not generate events are either completely non-value adding (nothing is produced) or not properly explored.

In Six Sigma terms:
If a process function dos not generate an event, that is 0=f(x).
If we do not know what event is generated by the process function, we know that y=f(x) is unknown.

Likewise, the above example does not provide an input event for “Handle Complaint”. Obviously, there should be one: in classic SIPOC terms, that is a process without any input: “Do they run it ‘just because’?”

In Six Sigma terms:
If a process function does not require an input event, that is y=f(0) – no “x”!

If we do not know what event is generated by the process function, we know that for y=f(x), y can not be properly analyzed.

Improving the EPC

With the knowledge that each event (save process-terminating events) must lead to a function and that each function requires both input and output events, at least one of each, we can boost our EPC:

Figure 3

While this might in practice be the exact same process as described in the initial Process Flow Diagram, the information is much more precise: we have realised that the process can not be closed unless the request has been processed and that a filed complaint triggers a handling process.

In process improvement terms:
Once the EPC is completed, we can quickly see which events are on the critical path. We can reduce our Value Stream Analysis to event analysis: if a function does not generate any value-adding events, the function itself is NVA. We do no longer need expert information about intricate details of process activities to explore step value.

The Link between EPC and FMEA

We can create an FMEA-generation process based on a completed EPC diagram:

1. For each event in the EPC:

   a. Ask: “Is this event really what we expect from the generating function?” If not, add it to the FMEA – and re-examine your process map.

   b. Ask: “Is this event a process failure?” If so, add it to the FMEA – and schedule it for elimination.

   c. Ask: “Does this event result from a process failure?” If so, add it to the FMEA – and schedule the entire corresponding path for elimination!

   d. Ask: “Is this event on a path leading to any desired output?” If not, add it to the FMEA – and schedule both the event and everything on the path below it for elimination!

   e. Ask: “How many XOR functions are triggered by this event?” If there are many different functions connected to an event, the process may be poorly streamlined. Add the event to the FMEA – and get more data.

   f. Ask: “How many AND/OR functions are triggered by this
   event?” If there are many different functions requiring the same event, we most likely are dealing with a bottleneck: Add the event to the FMEA.

2. For each function in the EPC
   g. Ask: “Can we get all the precondition events for this function?” If not, the function is dead meat in the process – it will never happen. Add it to the FMEA and examine the “why”.

   h. Ask: “Are all events generated from this function listed in the EPC?” If not, add it to the FMEA – and re-examine your process map. We most likely have a Hidden Factory here!

   i. Ask: “How likely is this function going to result in an event on the desired path?” If the probability is low, you have a malfunctioning action: add it to the FMEA – and schedule it for scrutiny in the ANALYSE and IMPROVE phases.

   j. Ask: “How many OR/XOR event outputs are connected to this function?” if there are many different outputs to a single function, it hints that either this function is a Hidden Factory – or the function has low precision. Functions of low precision must be added to the FMEA and later improved.

   k. Ask: “How many AND/OR event inputs are connected to this function?” If there are many different inputs to a single function, this function is a potential bottleneck: It should be added to the FMEA.

   l. Ask: “How many XOR event inputs are connected to this
   function?” A function with many mutually exclusive inputs is probably too complex and inefficient: It should be added to the FMEA.

   m. Ask: “Is this function elementary? Is this possibly more than one function?” If so, add it to the FMEA – it’s a Hidden Factory and most likely generates further events: Refine your EPC here.

Following this procedure, the process FMEA is complete when:

1. For each event, we know whether it is desired or not.
2. For each function, we know how well it contributes to the process y=f(x).
3. For each function, we know how many failures it may result in (i.e. how much risk it causes).
4. We have identified all potential flow problems in events and functions.

Like this, we can utilise Event-driven Process Chains to provide a solid foundation for fact-based process improvement.

About the author:

Michael Küsters is Executive Manager and Six Sigma MBB/Deployment Leader at SE-Consulting GmbH & Co. KG in Germany. www.se-co.de