After a couple of forays into the worlds of wildlife and motorway driving, I return briefly to the subject of food and drink, largely because once you have been afflicted with seeing everyday situations from a systems perspective, the pub is a rich resource of good ‘case studies’ to blog about. Honest. I’m a researcher!
Today’s example is a pretty straightforward lesson about system design and how to optimise it to meet the customer’s or service user’s requirements. It’s as relevant to policing as it is to landlords. What strikes me though, is how often the basic principles I’m about to outline are completely disregarded. Hey, if you’re looking for reduced costs, greater efficiencies and happier customers (or service users), what follows is a no-brainer…
Yesterday I went for a bite to eat and a pint at a town centre pub. Nothing unusual about that, you might think, but what was unusual was the bizarre method this place relies on to serve drinks. Normally you would just ask for what you wanted (in my case the usual small lemonade – ahem) then the bar staff would pour it and pass it to you. Not here. Once a drink has been ordered, customers must leave the bar area and sit at a table, then wait for another member of staff to pick up their drink and bring it to them.
Now, I’m all for table service if that’s what you want, but I cannot understand the logic in basically refusing to hand that refreshing glass of lemonade straight across the bar to the thirsty customer. Of course what happened as the place got busier was that lines of drinks were building up behind the bar, as the staff responsible for delivery duties struggled to keep up with demand. This demand would be hugely reduced if those customers who simply wanted to get their own drinks were allowed to do so. It would also mean that others who do prefer table service experience a faster service, as a proportion of the existing drinks queue would no longer be present, thereby affording the process additional capacity with which to handle demand.
As it happened, the system design resulted in delays and frustration for people like me who could see my drink stuck way down the line in this daft inflexible process. Ultimately it also costs the business, as customers like me are unable to put away pints (I mean lemonade) at the rate I want.
The traditional method of simply passing the drink to the customer at the time of ordering works best because of the systems notion of pull. Essentially, this theory is no more complex than designing the front end of your system to meet demand from the perspective of the customer or service user. The customer is always right, as they say, so give them what they want if you can. Let them pull what they require from your system – don’t push at them what you think they want. If they want table service, great, the option is there, but why make it the only option?
Such an inflexible method of serving drinks is incapable of handling predictable demand and leads to unnecessary stages in the process (i.e. staff having to ferry drinks from bar to table), bottlenecks (i.e. drinks queuing behind the bar until someone is free to deliver them), impaired and uneven flow (i.e. having to unnecessarily wait for your drink for varying amounts of time), higher cost to the business (less drinks sold, more staff capacity required to operate under this model) and potentially frustrated customers.
Notably, none of this occurs because those operating within this system are bad or lazy individuals. (This is a really important point).
So… what are the lessons to be gleaned from this traumatic episode and how do they relate to policing or other non-pub-based systems? Well in summary:
1. Systems should always be designed to meet purpose from the customer’s or service user’s perspective. Pull, don’t push.
2. One-size-fits-all ‘solutions’ do not work. They are incapable of absorbing the variety present amongst demand.
3. Inflexible operating models generate waste, higher costs and dissatisfied end users.
4. No matter how hard they try, workers can only perform to the extent that the system design permits. (Deming’s 94% / 6% rule).
Next, let’s have a look at how these principles transfer into public services…
Recently, a friend of mine underwent some medical tests and subsequently received a letter instructing her to book an appointment with Dr Smith to discuss the results. She duly phoned the GP’s surgery and the conversation went like this:
Patient: “Can I book an appointment sometime next week with Dr Smith please?”
Receptionist: “Sorry, we have no advance appointments for Dr Smith. You can book an appointment with Dr Jones if you want though”.
Patient: “I really need to see Dr Smith, as she’s the one who sent me for the tests and knows my medical history”.
Receptionist: “Well Dr Smith is the duty doctor next Wednesday so perhaps you could try then”.
Patient: “Yes, that’ll be great. Can I book an appointment next Wednesday then please?”
Receptionist: “No, you will have to phone up at 8am next Wednesday morning when we open”.
The result of this inflexible system is that the patient may or may not get to see Dr Smith. It all depends whether she will be one of the lucky ones who manages to get through the stampede for appointments that occurs every morning at 8am.
None of this is the receptionist’s fault of course – it’s the system again. In this case, the root cause of this madness is the 48 hour target for GP’s appointments. The situation is an example of another rigid front end that works against the service user, generating waste, uneven flow and huge frustration.
A much better option would be to allow the patient to pull what they require from the system. Deregulating the appointments process and removing the target would stop the mad rush for appointments, resulting in much more even flow and a front end more capable of absorbing variety. It would also let those responsible for managing the system know if there is sufficient capacity to meet predictable demand…
Different setting, same problems.
Finally, we come to policing.
Using that four-point checklist from earlier, let’s see how the principles can help create a more responsive police operating model…
Let’s say that the fabled Mrs Miggins calls the police to report some anti-social behaviour. Now, a systems-orientated model would first have us consider what purpose is; i.e. what response / outcome would Mrs Miggins like to see? It could be something as straightforward as ‘stop the bad thing from happening’. This then acts as the cue to determine what the appropriate response would be. Probably something as straightforward as ‘deploy an officer to speak to those involved and take steps to prevent a reoccurrence’. Easy.
In essence, Mrs Miggins has communicated what purpose looks like from her perspective and the police have responded in a manner that meets it. Pull in action. This is efficient, effective and reduces failure demand.
Now, what if the operating model had insufficient resources to respond in this manner? Well, the operator might have to book a diary appointment. This means that Mrs Miggins could receive a visit sometime later that day, or maybe even the next day (or later). Of course, by then the problem isn’t happening anymore, meaning that the officer can’t deal with it as effectively. It also increases the likelihood of a reoccurrence, thereby generating failure demand.
When a member of the public genuinely wants a visit at a time other than when they called the police, diary appointments are fine. They are not fine, however, when they are the only option given to the caller (think enforced table service or rigid GP appointments – same principle).
The solution? Well, there’s no better alternative to dealing with today’s problem today. If this means redesigning the front end of the operating model so as to absorb variety and handle predictable demand, then it should be done. It’s cheaper in the long run anyway. A larger, multifunctional initial response capability is much more able to achieve purpose from the service user’s perspective, as opposed to fragmented operating models that rely on rigid protocols, tight remits, handovers and departmental silos. Therefore, design your system so that the service user can pull what they require from it.
The result? Better service delivery, lower costs, reduced failure demand. What’s not to like?
Now, where’s my drink? 😉
Ref Doctor : providing the surgery uses a computer system , the doctor should see what is happening from the screen .
The computer system is just a ‘sticking plaster’ (geddit?!) to fix the problems of the system. I don’t know of any computer that will record all the detail of a consultation, history, and personal knowledge, so that any doctor could just read the history and quickly make the best decision. The GP system is supposed to encourage personal knowledge and foster relationships with patients – and most doctors say that this is essential to deciding the right treatment. Without that knowledge, you get failure. Wasted treatments and referrals, delays, missed opportunities, more appointments and prolonged treatment. A system that was designed by managers to reduce costs and hit performance targets, enabled by expensive IT, actually ends up causing more cost and more pain.
Thumbs up to the lady at Leeds City Council’s One Stop Centre in Great George Street for managing to circumvent the appointment system and find me a registrar to register a death on the spot the other day. My mother lived in Leeds but I live 1.5 hours drive away and needed a quick turnaround. The undertaker was … Er … gobsmacked to hear I’d registered the death so quickly as there is a week’s wait for an appointment at the moment. This is despite all the official blurb stating that a death has to be registered within 5 days.
Presumably having an appointment to …. has been redefined as expediting …. in this world of appointments and queues.
Thumbs down to the NHS (Leeds General Infirmary) who managed to highlight the wrong spot on the map for the Leeds City Council One Stop Centre in Great George Street though. 500 yards out less than half a mile from the hospital is heroic.
I’m intrigued as to why the pub designed a system like that?
What advantages could this offer the company? I can think of a load of possible theories, but I’d love to know what the real logic for this was.
I asked and no one knew. ‘its just the policy’ they said. A great reason to challenge the status quo I thought…
A Marston’s pub by any chance?
No, not Marstons…
Interestingly, O’Neils pubs did at one time offer a much better variation on the theme. You were free to use the conventional method of drinks ordering, but at quiet times they would also do table service, which meant that they actually sold more (having someone come up and ask tends to persuade you another pnt is in order, and they would usually time it while you were still drinking the last one…). At busy times, all the staff would revert to working the bar, so throughput was maximised. Good illustration of flexibility.
Absolutely. Flexible because it gives the customer a real choice (i.e. ‘pull’). More responsive, makes use of available capacity when not too busy.
An establishment I know started a similar system after a recent referb. No one really knows why but there have been some observations about “trying to create a more relaxed cafe type atmosphere”??? It’s fallen on it’s arse! The problem is so often a management that tries to second guess what customers want, based upon their own personal needs/desires, with reduced costs and without doing the required reasearch… Another Guinness Simon (other beers are available)?
“The problem is so often a management that tries to second guess what customers want”. As ever, your insight cuts straight to the root of the problem.
I did try really hard to keep this short, and failed badly [again], I think it might take several bottles and a comfort break, to get through, sorry.
I thought that ‘pull’ would pop up sooner or later. It’s one of the ‘sacred cows’, and usually taught without revealing the dirty little motives in the background.
[If one were to follow the trail back it leads to ‘kanban’ which is more sophisticated than generally believed, and requires a significant amount of time and expense to operate effectively.
It only works within a very, very narrow set of constraints, and can be an enormous source of waste if not monitored very closely. Unless there are very high volumes of production over very long runs, there is no noticeable advantage over standard inventory management systems].
Now for each ‘pull’ there is usually a corresponding amount of ‘push’ and vice-versa, but it may not always be obvious. In fact sometimes great effort will be made to disguise one or the other. Lets explore the scenarios you laid out.
“Systems should always be designed to meet purpose from the customer’s or service user’s perspective. Pull, don’t push. “
True-ish, but systems are designed by their owners to meet their objectives. So in a ‘system’ called ‘Pub’ you are not the winner, you are an opportunity to be exploited. The objective of ‘Pub’ is to ‘pull’ as much money out of your pockets as is possible.
When you enter a den of iniquity, they would like to ‘push’ you into a booth so you won’t leave. Having trapped you in the milking stall and got the teats on, they can start to get as much out of you as they can.
If the system works properly, they will have their beady eyes open, and as soon as one persons glass gets a bit low they will spring up, all solicitous offering to fetch more drinks [push].
So the rate at which drinks are consumed is now driven by the pace of the fastest drinker, rather than the slowest [push].
And because nobody has to lift a finger let alone stager to the bar to get a drink, the temptation to have more drink is increased [push]
While they are being so helpful bringing drinks, they might offer some food, just out of the kindness of their heart you understand. And definitely not because the profit on a bowl of salty chips is 10 times that of beer, and will make you thirsty for more beer [push].
If you are not the one ‘pulling’ you’re most likely being ‘pushed’, every where you go there are adverts trying to ‘push’ you into buying something or other. The more you are ‘pushed’ the greater their ‘pull’.
In areas where a service is delivered at zero cost, and where there is zero competition between suppliers, there is very little ‘pull’ or ‘push’ at the delivery point, provided that the system has capacity.
The booking system used to work quite well until somebody decided that leaving empty spaces in the appointment book to cover peaks in demand was wasteful, so the doctors said OK and filled them up.
Oops, suddenly there’s a problem, who could have possibly thought that if you hammer the sh!t out of a process it might breakdown? Well they could have asked any of the thousands of people that have ever built anything, and they have explained the “stress test” and why you never design anything to operate at 100%. [100% is frankly a movable feast, and depends if you are buying or selling].
So patients got the hump, and rather than just go back to the old system, they lumped on another bit, which means the process has gone back to how it was [with spare slots], but now there is a counting mechanism in place, with an extra cost. Top work, that, by idiots whose only talent for efficiency was getting their snouts as deep as they can into the trough, and hoovering up as much public money as possible. [you might guess, I’m not a fan].
Before tinkering with any ‘system’ the effects of any change should be very carefully studied before hand, and only implemented if it will have precisely the desired effect, with no knock on effects.
Whether to ‘pull’ or to ‘push’ depends to a large extent on the desired outcome and the constraints on resources.
For example [this is your area of expertise, not mine], I suspect that you would want to ‘push’ out RPU’s as much as possible and only ‘pull’ up India99, when it will be most effective.
The solution again is to have sufficient ‘excess’ capacity, to flex as the demand changes.
Policing is in a very unique position, as if there are surplus resources [sorry, officers], they can perform useful work doing active patrols in key areas, while still being available at short notice.
The eternal problem is proving that an activity that costs money and when effective yields zero results is efficient.
[The only other example I can think of that is similar is making a case for ‘planned preventive maintenance’ and it only tends to be used where the cost of a stoppage would be catastrophic.
Eg. Where liquefied chocolate is pumped round a plant, a failure of either the pump or the heater, will lead to all the down stream pipework blocking completely with solid chocolate. And it will all need to be cut out and replaced.]
Tying up the loose ends
“One-size-fits-all ‘solutions’ do not work. They are incapable of absorbing the variety present amongst demand.”
Quite true, but be mind your foot there, what else does ‘system thinking’ do but attempt to reduce processes to the most simple and straight forward and efficient state possible?
“Inflexible operating models generate waste, higher costs and dissatisfied end users. “
I’m sure there is a ‘can’ missing there some where, because the opposite effects can also be demonstrated IF the objective is simple.
“No matter how hard they try, workers can only perform to the extent that the system design permits. (Deming’s 94% / 6% rule). “
Not consistently, workers are a dead sneaky lot, and they will always find a way to break, subvert, or game the ‘system’. Systems don’t think, people do [to a greater or lesser extent]. And Police officers are masters [or mistresses] at bending systems to get the best outcome, [in a good way].
Cheers! mine’s a pint! Hic!
[*Slides gracefully under the table*].