Pulling Power

September 13, 2015 giantknave Brain Farts Flow, John Seddon, Lean Enterprise Institute, Push vs Pull, Service

There are two very different productivity ideas:

Make as much as you can! …meaning that:

you are always busy (it is a ‘corporate crime’ to be idle!);
it is irrelevant whether the next activity down the track is already snowed-under with work or even if it is available….you just keep pumping it out! They aren’t your problem;
the ‘performance police’ are likely measuring the cost of the activity being performed, and judging you accordingly.

…this reflects a Push system, which fits with an ‘economies of scale’ efficiency mindset (“how many did you make!”).

Make only what is needed when it is needed…meaning that:

each person is highly connected to the next activity down the track (because they need visibility of how the next step is going);
it becomes immediately obvious if there is a blockage and where it is;
the process performers can:
- collaborate on making improvements at the (now visible) bottlenecks; and
- see and measure the overall flow, from customer demand through to its satisfaction.

…this reflects a Pull system, which fits with a ‘flow’ effectiveness mindset (“how did we all do together for the customer?”)

Now, you might think that push will cost a lot less than pull because everyone is always working flat out, not waiting to do something….but you’d probably be wrong, and by a profound margin.

What’s so good about pull?

Here’s a simple ‘push’ diagram from the Lean Enterprise Institute to assist:

Stick man ‘A’ is happily making stuff, much to the despair of ‘B’ and, given that a real life process will have far more steps than A and B, you can imagine what this looks and feels like on a bigger scale – organised(?) chaos:

work will pile up throughout the process, meaning that there will be loads of ‘work in process’;

process steps might be working flat out, but it takes a really long (and usually increasing) time for a unit of work to get from start to (proper) completion. It spends a massive amount of its overall cycle time simply waiting;

defects are hidden within this mess, so it takes a long time for them to surface….with the time and cost to rectify the defect rising alarmingly as more work is performed on the defective unit of work;

changes in specifications or customer needs whilst units are (a long time) in process mean a huge amount of rework, and even scrapping of work done to date (Customer: “In the time you’ve taken, things have changed….I don’t want that anymore!”);

the long cycle times will create a huge amount of failure demand (blue marbles) from customers asking where their unit of value demand has got to and how long it will be.

Is this relevant to Service?

Absolutely! But, like most things, it can be a bit different to manufacturing.

THE big difference in service is that the trigger to start work is pull by default i.e. you can’t make a service in advance ‘and put it into stock’…you need to wait for demand to trigger the work. But, just because we have a customer pulling the demand lever doesn’t mean we should then be pushing their unit along a value stream before the downstream activities are ready for them.

For a really obvious example, let’s take a natural catastrophe (flood, earthquake, etc.), which results in an insurer getting a huge spike of claims demand. The insurer wants to help everyone as soon as they can but they a) are still getting the necessary processes defined ‘on the ground’ and b) have limited resources to do the work.

Now, this is a challenge: Insurers want to be seen to be pro-active and ‘getting on with it’ for their customers. But beware of creating a seemingly good short-term impression at the expense of a huge longer-term mess.

If you push claims through a process that isn’t yet defined and resourced then you can expect to:

only partially perform the necessary work, but not realise this;
set expectations that turn out to be incorrect (e.g. what you thought looked clearly a house rebuild turns out later to only be a repair…and vice versa);
go back and perform a great deal of re-work (ending up in multiple site visits, ‘reconciliations’ with previous findings, defensive explanations and compensatory actions);
throw away old work and virtually start again to cope with changing customer circumstances (“I was okay with you doing that 6 months ago…but not anymore”); and
lose the trust of the customer (your unintended mistakes are seen by them as malice and trickery)…which creates much failure demand, to be cautiously tip-toed through.

If you hear management say “right, let’s get all the claims through ‘assessment’ by [date x] and then we’ll focus on the next stage”, you know you’ve got push and all its associated problems.

This doesn’t mean that you don’t do all you can to make sure your customer is okay whilst you work things out (e.g. temporary repairs, emergency accommodation) and explain to them what is happening (including what you haven’t got in place yet)…but it is saying pull work through your flow when, and only when, you (& they) are ready for it.

This means that you focus your attention on defining and refining the flow, rather than wasting it firefighting each and every ‘undoing what’s already been done’ disaster.

A specific example for the catastrophe claims scenario: If a builder has a number of house builds on the go, don’t push any more on them (they may very well tell you they can take them!). Instead, allow them to pull the next one only as and when each build is satisfactorily complete. This will mean that the builder is focused on making their build processes effective, rather than trying to stockpile work for the next few years.

Moving on to ‘workflow management’:

Okay, so thankfully catastrophe management doesn’t happen all the time…so what about ‘day to day’ pull in service?

Who works in an area that has a ‘workflow management’ role (or even team) that sorts out work as it comes in the door by briefly looking at what it is, categorising it and then assigning it to people as fairly as they can? This is pushing.

What does this cause?

Incorrect classification: As explained in ‘The Spice of Life’, there is huge variation in service demand. It is impossible to properly appreciate the necessary work content until you do the work; which means that…

Feelings of unfairness: …it is impossible to fairly divide up the work. This wouldn’t be such a problem if judgement and rewards weren’t hanging on it…but they usually are! This creates a constant tension between the work assigner and the workers; leading to…

Dysfunctional behaviour: …people will do what they can to protect themselves. You can read ‘The trouble with targets’ to see the general techniques that people understandably use to survive;

Re-working the workflow: So the work has been carefully assigned for the week ahead but Jack’s work is turning out to be slower than expected (Bob’s is easier than expected but he isn’t going to tell you!), and Jill is off sick…this only comes to light mid-way through the week so customers in Jack and Jill’s trays have been waiting in vain. Push requires a constant need to review and re-sort allocations between queues as circumstances (always) change…which is pure waste.

What’s wrong with people pulling work from a central and highly visible ‘pile’?

‘Command & Control’ Manager: “Well, people can’t be trusted to do this can they!”

Counsel: “Eh? Why ever not?!”

Manager: “Well, they will slow down and look for the easy ones.”

Counsel: “and why would they do that?

Manager: “Erm, because of their personal metrics…needed because their performance is being judged…which will affect their linked rewards/awards.”

I hope you can see that this is a classic case of looking past a logical tool/technique (in this case ‘pulling work’) and seeing the root causes within the ‘command and control’ management thinking.

If the team:

had a capability measure as to how they are all doing (so that they could see the system, rather than being blinded by personal targets);
were being coached, not judged (so that they wanted to improve, not protect, themselves;) and
were sharing in their success (so that they wanted to collaborate, not compete)

…then a) designing an initial* pull system could deliver great results and b) the workers would likely look for, and make, continual improvements to it…so that it worked better and better and better.

* don’t try to implement the perfect pull system: let the workers move towards pull through experimentation….but management must remove the constraints that are in their way.

Examples of service moving from push to pull:

In fact we have all felt moves from push to pull. One obvious area has been customers (that’s us) being able to book appointments (pull) rather than being assigned a slot (push). This has happened from medical appointments, through school parent evenings, to home deliveries.

Note that ‘pull’ is actually an ideal, not a tool. You need to think widely (and differently) about achieving it. It isn’t an easy journey…but it’s well worth the effort.

How about this one from John Seddon: When a contact centre agent gets a customer demand that they are unfamiliar with, they should ‘pull’ in the necessary expertise to handle it, instead of ‘pushing it’ to the expert to perform. In this way, the agent is developing on the job and the customer feels that one person is caring for/ owning their need…developing great trust: a win/win.

Pulling is linked with continuous improvement, like an umbilical cord.

Notes:

Pull is a key part of the Toyota Production System (TPS), and is the 4^th of the 5 ‘Lean Thinking’ principles;
Kanban is a Japanese word and refers to a visual signal (often a card) used to trigger an action. The downstream process provides the kanban (signal) to the upstream process (i.e. it pulls the work along the value stream).
You can substitute the catastrophe example used above with any service process where a) the process isn’t yet properly defined and/ or b) a spike in demand has to be handled (i.e. exceeds capacity)

So why can’t we do that?!

September 2, 2015September 3, 2015 giantknave Brain Farts customer, John Seddon, Manufacturing, Service, Taiichi Ohno, Toyota

I don’t know about you but ever since I was a kid I have loved watching short videos of manufacturing plants and staring in wonder at how the products we take for granted actually get made! It all seems so futuristic and alien.

Here’s a short (4 mins) yet amazing video showing the mind-boggling production of TESLA Model S cars over in Fremont, California.

What do you notice? Here’s what I see:

a large, high volume manufacturing plant;
an ultra clean and tidy environment;
ordered, smooth flow through specialised process steps;
consistency of operation and velocity;
substantial mechanisation & automation;
calm and assured humans working alongside the machines;
…with a high quality product coming out the end.

Sounds fantastic, I’ll have some of that!

…so why is it that service organisations don’t seem to get anywhere near the awesomeness that is modern day manufacturing?

Here’s the answer…..because they try to copy manufacturing!

“Hey, that doesn’t make sense…”

Surely (I hear you say) if manufacturing is sooo advanced from the times of Henry Ford and through Taiichi Ohno’s Toyota Production System, then service organisations should be studying what they have done and applying it to their world?

And, indeed, that is what many (most) service organisations have done. But, in doing so, they have spectacularly missed a crucial point: Service is different to manufacturing and therefore they have been ‘solving the wrong problem’.

Here’s a fundamental John Seddon quote with regards to service:

“Service differs from manufacturing. There is inherently more variety in customer demand….Whilst the Toyota method was developed to solve the problem of how to produce vehicles at the rate of customer demand, in service organisations the problem is how to design the system to absorb variety.”

Going back to the TESLA factory, notice how each car being made is essentially the same. Now I know that there is some variety – different colours, different engines, different trim levels – but it is basically the same (modular) product. I also know that Taiichi Ohno’s Toyota Production System brilliantly worked out methods to deliver this limited variety within the one production process (as opposed to requiring separate lines).

Much of manufacturing has adopted the mantra of ‘specialise, standardise, centralise and then automate’….but this is just about the opposite of what would be good for a customer requiring their very specific needs to be met for a service.

Let’s carry on with the car example but move on down the process to the service end – the selling, distribution and servicing of the car.

Let’s assume that TESLA’s competitor, TRAGIC, has applied the manufacturing mantra to their car service processes.

TRAGIC has created a centralised and highly automated ‘contact centre’ and separate ‘service centre’, both of which are broken up into highly specialised teams with standardised processes.

you will be directed to a website on which it is nigh on impossible to find out what you need to know, let alone a way of contacting a human being for a conversation;
…assuming you do find a contact number, you will then be punished by a multi-layered IVR that doesn’t have an option that meets your specific need;
you will have a standardised ‘scripted’ conversation with someone who doesn’t seem to be allowed to help you with your actual needs…but who can transfer you to [insert name of another department here];
you will then be passed around a number of specialised departments as they all ‘pass the parcel’;
you will be allocated to a ‘back office’ work queue and will have to repeat everything you have said so far to whomever is allocated your ‘ticket’…and they will likely disagree with whatever the person before them said to you along the lines of “oh no, I only do this” or “no, they don’t know what they are talking about, we can’t do that for you”;
you will talk with people who have a standard time slot allocated to you (or at least an ‘average handling time’ target), who will ask you standardised questions, categorise you according to limited drop-down boxes in their computer and then allocate you to defined ‘solutions’;
you will be confused as to who is actually dealing with you (or who even cares);
you will spend time and effort chasing up what is happening;
you will be provided with a standardised solution which either doesn’t meet (or only partially meets) your needs;
….you will be forced through the whole sorry process again (and perhaps again) as you struggle to get your actual need resolved.

The Point:

In service, the customer comes in ‘customer shaped’. Our job is to design the system so that it can absorb their variety, not frustrate it.

Beware the manufacturing mantra of ‘specialise, standardise, centralise and then automate’.

Toyota and automation: I know that the TESLA factory looks like it’s been taken over by intelligent robots…but don’t get too carried away with automation in manufacturing. It’s worth noting that:

Studies have shown Toyota factories to be significantly more efficient than their competitors despite being less automated;
Toyota is wary of ‘over automation’ and has been reported to be reducing/ removing some automation in preference to human beings carrying out the work.

Their rationale? Putting to one side the enormous cost of developing, buying, installing and maintaining robotics, a robot simply does what it is programmed to do. Contrast this with a human that can think about the process they are performing and continually look for ways to improve it.

This can be the difference between static and dynamic processes…but of course this is only relevant if the human is in an environment that motivates them to continually improve what they do.

A Service Revolution!

July 11, 2015July 11, 2015 giantknave Brain Farts customer, Demand, Flow, John Seddon, Service, Variation, W Edwards Deming

Service is different to manufacturing…and this difference is gob-smackingly important for a service organisation to understand if it is to truly move towards its (stated) customer purpose.

I was recently passed a link to a Malcolm Gladwell TED talk by a colleague and whilst watching it I thought…

“Nice! This is a simple tie-in to the incredibly important concept of variety in customer demand.”

So here’s the link to the very watchable talk (18 mins): Choice, happiness and spaghetti

Here’s the key points from the talk:

that Howard Moskowitz (a psychophysicist) had his ‘aha moment’ that “they had been looking for the perfect pickle…but they should have been looking for the perfect pickles“;

the false assumption that the way to find out about what people want is to ask them….leading to years of fruitless and misleading focus groups. The truth is that:
- people commonly don’t actually know, or cannot (and even will not) express, what they want; and
- they will be constrained by what they currently know. “No customer asked for an automobile. We have horses: what could be better.” (Deming)

the importance of horizontal rather than hierarchical thinking about customer demand: we thought that customer demand was hierarchical (from cheap up to expensive products or services). Instead, there are only different kinds of products and services that suit different kinds of people;

that, instead of looking for one way to treat all of us, we now understand the importance of variability;

when we pursue universal truths [one standardised product/ service/ way of doing things], we aren’t just making an error, we are actually doing our customers a massive disservice;

We need to embrace the diversity of human beings

Hang on a minute….

So, I started off this post by saying that service is different to manufacturing but Gladwell uses lots of examples of physical products in his TED talk to make his point about the importance of customer variety (cola, pickle, spaghetti sauce, coffee,)…“make your mind up Steve!”

Well, this is a nice segue to explain about two types of variation, and how incredibly important this understanding should be to a service organisation (or the service part of any value stream).

These two types of variety are:

Customer-introduced (i.e. within their demand); and
Internally created within the process (regarding flow)

To go back to Gladwell’s spaghetti sauce: Different consumers like different sauces (this is variety in demand) but, once they have determined which variety of sauce they like, they then expect each jar they buy to be the same week in, week out (i.e. minimal variation in the process that creates that sauce).

So, whilst we definitely want to reduce and remove variation in the quality of the process, we should not remove the ability of the process to provide a suitably varied experience and outcome. Rather, it is the opposite – we should be trying to cater for this variety.

In fact, variety in service is MUCH bigger than Gladwell’s product examples:

One of my earlier posts set out five categories of variety in customer demand, as identified by Professor Frances Frei (see The Spice of Life).

Now, whilst it might be useful to categorise service variation (purely to help you ‘see’), the bigger point is that the customer sets the nominal value – the specific value of a service to them.

“The customer comes in customer shaped“

…there is virtually infinite variety in people….and that variety can change for a given person depending on, say, time of day/ external influences/ mood….

Standardisation is NOT the answer…in fact, it is often the problem:

There are legions of service organisations that have hired manufacturing improvement experts (or people who have read books about them) to ‘standardise, specialise, centralise and automate’ because they say “this is the solution”.

Examples at attempts to standardise the customer include:

using IVRs to standardise customers into categories (“press 1, then press 3…”);
using call scripts to standardise the content of customer conversations;
using average handling times to standardise the length of a conversation;
using ‘box ticking’ forms to standardise customer information collection;
using ‘black and white’ rules above common sense, when dealing with a customer’s needs;
forcing customers down one path (e.g. you can only pay by direct debit, you can only interact online, you can only use these suppliers, …….and on and on).
…..

Interestingly, if you read the list above with your ‘I am a customer’ hat on, you will likely recall many instances where you have tried interacting with a service organisation and one or many of the above attempts at standardising you and your demand has seriously frustrated you!

This leads to much failure demand, waste (and cost) but with little value delivered (as written about in an earlier post).

Clarification: this isn’t to say that technology cannot assist or that there is no place for any standards. It’s making the point that the starting point should be that:

“….in service organisations, the problem is how to design the system to absorb variety” [and not frustrate it]. (Seddon)

Our starting point always seems to be ‘efficiency’ and a focus on activity cost. Perverse as it may seem, a focus on activity cost often has the unintended consequence of increasing total cost (though this is not visible to a silo’d organisation and is nigh on impossible for them to measure).

If we standardise, say, a site visit (the activity) such that it can’t absorb the variety in the customer’s demand…then don’t be surprised that:

there is failure demand from the customer when they complain and/or disagree with the outcome of the visit;
there is much ‘expert’ time spent reviewing this complaint;
there are yet more site visits required to resolve the problems;
there is lots more paperwork/ computer inputting/ workflow management required;
there is much confusion created by all this extra work (who did what when, who authorised what change from the standard, who is explaining all this jumble to the customer?); and
trust has been lost with the customer who now questions everything we do

The most important point to note is that “cost is in flow, not in activity”

So why the title of this post?

Well, the above is quite different thinking to where ‘command and control’ service organisations have been going. A revolution if you will.

Put simply, if we understand the variety in our customer demand and try to design our system to absorb (rather than frustrate) it we will go a long way towards our customer purpose…with the likely side effect of doing so for less cost.

“Managing value [for the customer] drives out cost….Focussing on cost paradoxically adds cost and harms value.” (Seddon)