The Delay Following the Spike – Issues with Cycle Time in Service Industries

speaker
How long does it take you to do what your customers want? Not just the first part, but the whole of it?

1. The Pattern

I see this pattern commonly replicated across service industries. It involves a very short spike of activity (e.g. 5-20 minutes) followed by a lengthy delay where something is sent to the customer and the organisation waits for the return. This is followed by a 2nd spike of activity which in turn is followed by another lengthy delay. Depending on the bureaucracy involved, this process may involve several rounds of spike and delay, each adding to the overall delay in service for the customer and, most likely, increasing failure demand on the organisation.

2. Some Samples

Let’s have a look at a few industries and see how this pattern plays out:

2a. Retail Industry

Bed
A bed to sleep in: What the customer wants
Take for example, ordering a new item of furniture. We’ll start at the sales phase – although the complete process starts before then with marketing or customer acquisition – where the customer is in the retail store.
The customer, let’s call her Lilly, is buying a bed. Lilly spends up to an hour viewing and trying beds on a Saturday afternoon, talking to the sales advisor and then committing to buying one particular bed. The sales advisor creates the order, takes details in order to arrange finance, takes some information regarding proposed delivery times.
This is the first spike. There may be finance involved and almost definitely delivery involved. Lilly is told that the delivery company will contact her by the end of the week. That’s the first disappointment, can’t they arrange delivery now for later that week? Instead, she begrudgingly continues with the order hoping for a delivery time that meets her needs.
Some customers stop the order and go elsewhere. They’ve arrange finance, but may not have committed at this stage. For Lilly, who continues with the order, she goes home, then spends her week as normal waiting for the phonecall. This is the first of the delays. In Lilly’s case, the delivery company ring her on Tuesday, two working days after the order. Two days is a long time when you’re waiting. And it’s definitely a long time when compared to the processing time in the showroom on that Saturday afternoon. So it would not have been surprising had she rang the salesman on Monday or even Tuesday morning, creating failure demands disturbing him from achieving more sales.
The delivery company have a van that delivers to Lilly’s area on Tuesdays but she’s missed the delivery for that week so it will be the following Tuesday. This is the second spike followed by the second delay.
The week passes and Lilly receives the bed at her house. She finds there’s a part missing and calls the number. There’s a spike of activity as the after-sales staff figure out what’s missing, decide what to do with it and then initiate that action. For Lilly, it’s a small part that’s missing, so they’re going to post it to her. A few days wait ensues and, on Saturday – that’s 2 weeks after the order was placed – she receives the part.
It’s broken, either in the post or during the picking process. Again she calls the after-sales and they go through the same conversation as the previous week; this time a bit more aggravated. The part arrives intact on Tuesday and 2 weeks and 3 days after the initial order, Lilly has her bed.
If we take into account a pro rata of the delivery effort, we end up with about 5 hours activity across 17×8 hours = 136 hours. That works out at 3.7%. If we look at the actual value-add activities rather than all activities, that’s probably a lot less (i.e. the original order time plus the delivery, but not arranging the bed delivery or arranging for delivery and redelivery of the missing part). Let’s say that’s 1.5 hours including ordering, picking and delivery that works out at 1.1%. That also assumes that we’re looking at working day hours, not full 24 hours as customers are becoming more accustomed to. Had we considered 24 hour days for 7 days a week, that 1.1% reduces drastically.

2b. Service Function

speaker
A working bluetooth speaker
Michael is returning a bluetooth speaker to an online retailer. It’s Saturday evening but, like most, the website is 24×7. First he logs onto the retailer’s website, looks at his past orders, finds the order for the bluetooth speaker and submits a complaint. This is the start of the RMA process that’s commonly used for returning (technical) goods.
On Monday afternoon, Maria a member of the service function, replies to Michael’s email. Maria expresses regret about the fault and attaches a fault reporting form for Michael to fill out. Michael’s a bit annoyed about this; he’s already provided some of the information in his original email to the company. However, he does accede that they will want some additional information in the form.
He has to print the form but he can’t do that until he’s next using a computer that can open the pdf document and print it to a nearby printer. So on Wednesday evening, he prints the Fault Report form, writes the details and then scans it. He emails back the completed form that evening.
On Thursday morning, one of Maria’s colleagues, Zoe reads the form, agrees that the bluetooth speaker is faulty and then sends Michael the RMA note, authorising the return.
Michael has to print this out, so again has to be next to the printer. He does this on Saturday morning, boxes up the speaker and posts it on Saturday afternoon. The parcel arrives on Tuesday morning, opened by customer returns who agree with the fault, authorise an exchange to be sent to Michael and inform Michael of such. Michael reads the email on Tuesday afternoon, around the same time that the warehouse dispatch his replacement to him.
On Friday morning, the delivery company attempted to deliver the replacement speaker to Michael’s address, but as he was working, it was returned to the depot. “Fortunately” for Michael, the depot is open on Saturday morning, so he drives to the depot and collects his blue speaker. That’s not really fortunate since a better solution would have been to have checked with Michael when he would be available to receive the package. But it could be worse, the depot could work standard mon-fri office hours.
Almost 2 weeks have passed since Michael reported the initial fault, with more effort required of the customer than of the retail company (so far). Michael has probably spent 4 hours of his time in sending emails, reading emails, printing, completing forms, boxing, arranging for delivery and subsequent collection. The retail company spent 3 minutes in the initial fault report form, 3 minutes reading the fault report form, 5 minutes arranging for the RMA, then 5 minutes despatching a new one. Less than an hour. They’d also have disposal or return of the fault item plus accounting and other supporting activities. However, having spent less than an hour of “value” time in the returns process, the company managed a process that took two weeks. The ratio of value added activities to the length of time to complete the process is low, 1 hour to 24 hours x 14 days = 0.29%. That’s not uncommon.

2c. Local Authorities

signature
signature
This is where I first encountered the pattern. Instead of writing about it in this article, I’m going to save it for its own article as I’d like to explore it in more depth. The pattern is rife in local government and related services. I’ll post a link here when the article has been published.

3. The Calculation

There’s a term for this concept and formula for calculating it. It’s called CPE for Cycle Process Efficiency or occasionally PCE for Process Cycle Efficiency.
In this case, I’m calculating the time for the whole end-to-end service process. If our examples are consistent, then the service function is showing a Process Lead Time of 2 weeks per unit. That’s the elapsed time it takes from the point that the customer first contacts us to the point that we deliver the solution back to the customer.
We also require the Value Add Time, i.e. how much time per customer is spent creating or transforming value? This may actually be easier to arrive at the Value Add Time as equal to the Process Lead Time minus the Non-Value Add Time. It’s often easier to identify the steps that do not add value. Whichever route we take, we’re aiming to identify the Value Add Time for this process.
The PCE is then the Value Add Time divided by the Process Lead Time. It’s usually way lower than you initially think. If it’s above 70%, then you probably haven’t identified all the non-value add steps. To put that statement into perspective, I’ve seen PCEs lower than 1% for appallingly bad processes and improved them to 25% for a drastic improvement. Unfortunately, finding PCEs <1%  is not that uncommon.

4. Resolution

So what can we do about the pattern?
1) Recognise if the pattern is active in your organisation’s services.
2) Focus on the delay. You’ll almost always achieve more value and improvement from resolving the delays since they outweigh the spikes.
3) Consider different methods for removing each round of the spike-delay pattern.
For example, in the returns process, the fault reporting form could be on the website, ready for customers to complete. In addition, the organisation could implement automated authorisations when submissions meet certain criteria. This could include printing returns labels on the invoices packaged with the original goods. That would be 2 of the rounds reduced.
There’s no question about the fact that fixing the problems so that they do not happen again is the most important step and will have a greater impact on CPE than any factor. However some of the above issues with CPE don’t involve a failure (such as a defective part), but are due to the inefficiencies present in the process. These are often caused by a bureaucratic need to manage risk. The question then becomes one of addressing that risk through other methods.
Do you want to comment, get in touch at @alanward.

Fundamentals of Process Mapping – Introducing Subprocesses Part 4

From what we have seen so far, we’d have 3 separate, but related process models. One for each of the following:

  • Buy a Book
  • Choose a Book
  • Pay for Book

Numbering the processes

Some of that was getting difficult to describe. The fact that Pay for Book is a process step in one diagram and a whole process was causing some difficulties in describing the relationship. I’d recommend reading through it again, slower this time, checking that you are certain which process step is being to referred to at each point.

Some standards help understanding by providing a key to each process step. The most common method is to assign a unique number to each process. The benefit of this is that you can define the process once (e.g. say we define “check stock level”) and then we can use it elsewhere as a process step (e.g. in an ordering, logistics or auditing processes).

Some standards help you navigate the hierarchy by assigning and set of numbers, e.g. everything at the top level has one number (1, 2, 3, 99, 123, etc). The next level down would have another point number so that all the process steps in process 1 would have numbers of 1.1, 1.2, 1.3 and those in process 3 would have 3.1, 3.2. Down another level and we’d see labels such 1.1.1, 1.3.4 and 4.3.5. This does lean towards a parent-child relationship between processes. Not necessarily bad, but I prefer more freedom.

The more levels and the greater the complexity, the greater the need for a naming convention.

Reuse

By allowing processes to appear in other process maps, they can be reused. For instance, theScan Book process step above could be used elsewhere, e.g. to retrieve information about a book such as how many are in stock, price, different versions, etc. The process step would be the same in all processes.

Common Mistakes

  • The Process Start in a subprocess doesn’t relate to any process step in any other process map. So you’d never actually use this process.
  • The process overlaps with the previous or next process in the chain – as we saw earlier with the Scan Book process step.
  • The Process Ends (i.e. the outcomes of a process) for the subprocesses aren’t reflected in the higher-level processes.
  • Change in process mapping methods – giving a process step to a different analyst can result in that process step being described using different methods or no standards. This isn’t necessarily a mistake, but should be considered before responsibility for process mapping is delegated.

Why 3 Levels?

You don’t have to have 3 levels, they suited the early part of this article. It’s a common concept in a lot of domains. In Data-modelling, the hierarchy of Conceptual, Logical and Physical data models has long proved beneficial. Closer to the process domain, Alistair Cockburn was promoting multiple levels of Use Cases almost a decade ago.

When do you stop going smaller?

When everyone understands the process step without having to ask any questions.

For many clients, two levels is sufficient for the process analysts to be involved in; a high-level mapping of all the processes, then a more detailed view of each process. a 3rd level may be created for the more complex processes that require more analysis. Developers are likely to look for further detail, so either another level or different diagramming technique can be used.

Recap

  1. A process step can be described in more detail in its own process map
  2. Processes can be re-used in more than one process
  3. Process maps should contain sufficient information to relate to each other – using the Process Starts and Process Ends
  4. Different readers will have different ideas of how much detail they want to see
  5. The different levels of process maps can be used for different audiences
  6. As the number of processes and levels increases, the greater the need for a naming convention

Next Article

Notice that Buy a Book was written from the buyer’s perspective whereas Pay For Book was written from the Bookseller’s perspective. We’ll discuss how to handle that in the next article.

Which Diagram type?

All the diagrams above could be process maps. In some cases, especially with mapping the flow of user-interfaces, then UML Sequence Diagrams can be more useful than Activity Diagrams. I’ll explain why in a later article.

This is an article in the Fundamentals of Process Mapping online book provided by Alan Ward

What’s in a process?

I’ve had a view for a number of years now that a process cannot be described with just a process map.

Well, not in its entirety. A standard process map usually consists of rectangular boxes linked with arrows. Better process maps have some variety in the size and shape of boxes representing the variety of actions and decisions that occur at the process steps. When good, these process maps conform to BPMN, UML (Activity Diagrams) or other similar standards. When bad, there can be missing outcomes from decision points, missing references to other processes or references to missing processes and so on, the list goes on.

How Deep?

However, no matter how good the process map, they cannot completely describe the process. Take the instance of capturing an AS-IS process, perhaps during the check phase of lean systems. A process map would only give a brief description (1 to 20 words maximum usually) of the process step in question. Just as a process can be broken down into process steps, process steps can often be broken down to a further level. And then those steps can be broken down again. In practice, there’s a point of diminishing returns after which you decide that enough detail is enough and that to gather more detail, although useful, would not be cost-effective. So it follows that no matter at what level you stop when looking at business processes, there’s always a level of detail that you’re missing. There are exceptions to this, for example when designing circuits, then the process steps may well be atomic. In most cases with business processes, there are further, more granular levels.

BPMN and UML Activity Diagrams are good at showing relationships between steps, including the order and control flow of the process steps and how they link together. That’s useful and should be used. The process maps should be consistent with the standard that the author is using. So make sure that if follows the rules. Simplistically, any decision point has to have at least 2 outcomes. If it has only one, then there wasn’t a decision. How does the standard deal with branching, merging, delays, broken or disjointed processes? Find out and use it. But that’s not all.

So what is missing from a process definition?

Most often, I find that the underling rationale for the process is missing. A process or a process step exists for a reason, usually it’s do something. In reality, the process steps in a process map are representations of what something or someone does on a routine basis. More commonly, it’s an actor (a person or a system) doing an action to transform an object. This could be processing an application form, taking a payment, assessing eligibility, writing a letter, creating an account and so on. Let’s take one of those in more detail. A likely scenario of processing an application would have:

  1. a customer submitting an application form
  2. the organisation receiving the form,
  3. an agent checking the application for completeness
  4. the agent recording the application on the organisation’s system
  5. the agent assessing eligibility
  6. the agent giving a reply to the customer (by letter or email)
  7. if the application was accepted, then a new service or entitlement is started on behalf of the customer

Input and Output 

The common item throughout all the above is that there’s an application form being processed. The customer fills it out, the agent assesses it. It goes on a journey and the process steps cover that journey. The application form probably has a “for office use only” on it. Sound familiar? Well the agent would be filling out that part. What’s important is the each process step receives the application from the previous process step. So the application is an output from step (1) and an input to step (2). By noting these on a process map or in an accompanying text document, we’ve improved the quality of process map incredibly. So if a process step needs to receive something, list it as an input. Similarly for output. Often, any analyst who’s previously been a developer  will probably focus on data inputs and outputs to a process, e.g. parameters that have to be passed along the journey. Watch out though, paper, faxes and files are equally as important.

Transformations 

Back to the rationale, the process step will transform the input into the output. These transformations should be recorded. So if the agent adds something to the application, record that fact in the process description. Bear in mind that the process step can (so far) only achieve an output by transforming an input. By recording these, we’ve added more detail and more rigour to the process definition.

Record Data Usage 

In step (5), the agent assesses eligibility. Maybe they retrieve some customer details based on the information in the application form and perhaps also retrieve a sliding scale as a reference. These are pieces of data that the process step uses to change. Ignoring human emotion, the output can only come from a combination of input, retrieved data and an algorithm. From what we covered earlier, the algorithm could be broken down to more more granular steps. The process step could also update a retrieved form or create further data to be stored somewhere. This retrievals and updates should also be recorded as part of the process definition. At a high level, I’d expect to see which systems are being used per process step. At the next level down, we should cover data at the conceptual level (e.g. Customer, Car, Address). Another level down, I’d be looking to record usage of data at the logical level (customer first name, customer last name, address postcode, car registration number). To some extent, the old Data-Flow Diagrams handled the flow of data between process steps. The combination of ERD and DFD seems to be have been lost in today’s modelling skills.

Channels 

In step (6), I mentioned “by letter or by email” rather lazily not differentiating between how the process may differ for each channel. The process should be consistent with the channel that it applies to. If there’s a change in the channel or medium, these should be recorded. Coming from implementing multi-channel solutions, I like process maps to be applicable to all channels and only show the exceptions. In practice, this often requires a split, either due to the time nature of the interaction (synchronous or asynchronous) or whether it’s electronic or in person.

Where? 

Reading the steps in the list above, you’d expect steps (2)-(7) to be performed by an agent in the same place. If the geographic location changes, then record this. Same goes for teams, although using the swimlanes in BPMN and UML should already cater for these. Ideally, anything that changes about the environment in which the processes are conducted should be recorded. It’s best to describe what I mean by example here; if an analyst or group of analysts are mapping a group of processes, if all the processes are performed in one location, then that can be recorded in the text description of the process. If the location changes per process or process step, I’d expect to see each step have the location recorded. It’s better to be explicit rather than leave people guessing, especially where you have the opportunity to reduce ambiguity.

Summary 

To recap, a process definition should consist of at least:

a) a textual description of the process and each process step
b) a control flow of the process through each process step
c) zero or more inputs to the process and to each step
d) zero or more outputs from the process and each step
e) zero or more retrievals for each step
f) zero or more updates for each step
g) environmental variables

Any decent modelling tool should as a minimum allow the analyst to capture this information, be it diagrammatically or textual.

In my experience, the vast majority of analysts do (a) and (b) only. Some analysts make an effort at doing (c) and (d) with varying degrees of success. Get any analyst with a process background rather than full understanding of the systems development life-cycle and you’ll be struggling to get anything beyond (c). I’ve made some generalisations, but they are true from my experience.

Yet there’s still more to capturing an accurate description of a process. Each process has attributes (e.g. time taken, peak volume, average volume, etc.) that should also be recorded.

Service Redesign

Yorkminster
Yorkminster
Yorkminster – design on design on design

Are you designing a service or transforming an existing service?

For redesign, we help organisations to reform teams more logically and change the way that they work resulting in more efficient processes. This is more structured and more logical than older BPR (Business Process Redesign) concepts as we’re heavily influenced by Lean but in a service environment.

At the smaller end of the scale, there are service improvement engagements and delivering strategies and methods for continual improvement. We can’t implement the continual improvement for you; that has to come from within your own organisation, but we can be there with you on your journey.

For new services, we assist organisations in developing their new operating models. At this level, it’s not the strategic target operating model, it’s a more tactical design that has to be workable in a live situation with real customers. It should link to the target operating model and indeed should move your organisation closer to achieving that target.