Design

Whether the process being designed is for implementation of a new product or service, or for inclusion into an existing organisational framework, process design usually starts with requirements.

Capturing Requirements

For a new product or service, where the Voice of the Customer may be needed, a common method is to capture customer(s) responses to surveys about the intended new product or service and rate the responses according to a Kano model (created by Noriaki Kano). This will produce a number of needs which are rated by a minimum of three factors :

Basic Needs: Requirements are those that must be present for the product or service to be successful. Without these, the customer will go elsewhere.
Performance Needs: Requirements are those that are on a sliding scale. The more we have, or the better they are, the more customer satisfaction they bring. The converse is also true.
Delighters: Requirements that will delight your customer. These are the items that will typically not be missed if they are absent. Over time, these generally become Performance Needs. A good example is the smartphone.

The next step is to translate those customer requirements into practical process requirements and a simple method for doing this is to use a Critical to Quality tree. For each of the needs identified, that you want to satisfy, determine how this can be achieved (the Quality Driver) and how it can be implemented and measured. You can then incorporate this knowledge into your requirements for the process design. The example shown below is one that should be familiar to most people and illustrates some requirements for a software application and the availability of a call centre during certain hours.

For an internal organisational requirement, there are usually known, upstream and downstream constraints and systems with which a new process must comply, so a Kano analysis may not be appropriate. No process is an island and this is where the Linkage of Process map comes in useful, yet again.

Having collected some requirements, a simple way to turn them into a formal process is to use a tool called a SIPOC, which stands for Source > Input > Process > Output > Customer. It's just a table with those headings and can be modified to include other items if required, such as System and Operator. Our requirements might be represented as shown below, which could then be translated into a cross functional process flow diagram or integrated into an existing process.

This example could also be represented as a user story, of the form "As a .., I want to .., So that I can ..", which is a common format for software design. To illustrate the difference, if requirements were being collected for the web site and for the phone Interactive Voice Response (IVR) software being accessed by the customer, a user story format might look like this.

The priority of "M" stands for "Must Have" and is one of the options used in a rating called MoSCoW. The others are Should have, Could have and Won't have.

Whilst the content is approximately the same, it allows a software developer to see the intent or goal of the action required (so that I can …), which may be helpful in designing the best solution for the user. However, it doesn’t represent the overall process flow as well as the SIPOC format. Each format has it’s own strengths and weaknesses.

Process Example

As an example, our update requirements, taken from the SIPOC, could be represented by the following process drawing, which uses the Business Process Model and Notation (BPMN) format, although others are equally possible.

Design Considerations

When commencing the design, along with the organisational and technical requirements already captured, consider all the points listed below. See what improvements to the design can be made.

Create a Linkage of Process map for at least, the area around the process that you designing or modifying. This will ensure that you know where critical connections are before you start.
Create a SIPOC for the new or modified process.
Draw up a process flow diagram to visualise the SIPOC. If there are only a small number of players, a cross functional layout (swim lanes) works well. If there is a cast of thousands, a more open format using owner identifiers works better. (see Document section)
Minimise customer touch points. After they've told you what it is that they want, customers generally don't want to be further bothered until the product or service is delivered. Would you? An important exception to this is to keep the customer informed, especially if the news is bad, as might occur if there is going to be a delay in delivery. Silence is not golden when things are not going according to plan.
Minimise potential breakpoints. Can you identify weak points in the process? Are there dependencies over which you have no control? If so, can you avoid these? If not, how do you manage the consequences?
Minimise handovers, both within the process and to other processes or entities. Handovers are a source of miscommunication and errors. Where they are needed, can you error-proof them?
Minimise waste and maximise workflow. As well as creating a process flow diagram, consider adding a Value Stream Map (see Waste section). The former will illustrate who does what and the latter will highlight potential delays and other forms of waste.
Stand back and look at the user experience (UX) for both the external customer (where there is one) and the internal users of the process. Ask yourself if you would like to use the process and if the answer is no, is there a better way of doing whatever it is that is causing a problem. The UX for an external customer is often the focus, but how the internal users feel about it can be just as important.
Create appropriate key performance indicators (KPI) for your process and use them to inform current performance and future improvements.
Where necessary, perform a Failure Mode and Effect Analysis (FMEA) on your completed process. This can be a very time consuming exercise but one that is often used in high risk situations, to anticipate and mitigate possible failures.

Modelling

It can sometimes be useful to create a software model of your new process, either using purpose built simulation software or, more simply, by drawing up a Value Stream Map. (see Waste section) Since there can be no actual performance data, you will need to estimate values for the required parameters, such as process cycle times, material quantities, customer demand etc. However, a model can give an indication as to probable performance and can validate the design, or highlight problems such as bottlenecks, before testing is commenced.

Defining Metrics

Traditional performance metrics tend to be siloed, focussing on the performance of each business function participating in the process. Having gone to the trouble of optimising your new process, appropriate metrics should follow the Value Stream approach, whereby the product or service being delivered has the shortest lead time, the highest quality and lowest cost. An example of this is “utilisation”, where it may add more value to the overall process to have some areas underutilised, so as not to produce excess inventory, and cross train so that people can move between different processes as required.

Testing and Verification

For a new process that may have a significant impact on the organisation, a test plan should be created and implemented, using a quarantined environment where possible. If the latter is not possible, a small scale test should be tried, together with the creation of a backout plan, to be used should the test produce unexpected results.

Determine if the defined KPIs are suitable and if the test results are as expected. Check if the linkages to connected processes are still working correctly? If not, why not? If you need to change anything (problems might be due to external sources) then use the Plan > Do > Check > Act (PDCA) cycle.