Hospitals are full of workarounds and fire fighting, it's a pretty common problem. That's one reason cost is so high and quality is often so poor.
One of the key insights that comes from introducing healthcare professionals to Lean concepts, even in the first few days, is that they:
- Start seeing the difference between being busy and adding value for the patient
- Start recognizing that many of their daily activities are “workarounds” disguised as necessary work
Let me share an example that you might see in a hospital:
At the start of, or during a surgical procedure, a needed instrument might be missing. As part of the fire-fighting, the team might call the sterile processing department, asking them to expedite an instrument to the O.R., possibly using something called a “flash sterilization” process.
It's not the full, regular sterilization process – “flash sterilization” is something that hospitals try to minimize as it's not considered as effective as regular sterilization. But it's faster — in a pinch.
Let's say, also, that the flash sterilization process is taking too long, or longer than the surgical team would want.
I'd propose it wouldn't be the best use of Lean principles to try to improve the “flash sterilization” value stream — doing THAT process faster, the process and method that's not ideal for the patient, misses the point of the true opportunity for improvement…
We should step back and ask why instruments are sometimes missing from the tray — how do we ensure the right instrument is always there at the right time? Fixing that process defect (missing instrument) would do far more to reduce waste than improving the workaround (flash sterilization).
It's not enough to use a specific Lean method properly, such as a value stream map or a kaizen event. We have to make sure we're solving the core, fundamental problem instead of doing the wrong thing faster.
In recent discussions with one hospital, we talked about how a workaround (such as flash sterilization or fixing an incorrect medication order) often gets viewed as “normal.” It's something that happens every day and people get used to it. Therefore, the focus might be on improving the workaround instead of eliminating the need for the workaround. I think this is a core principle of Lean thinking, getting to the root cause.
My doctor regularly checked my lab results and I was eventually taken off of the drug when my cholesterol was well into the safe range.
When we instill a process workaround, do we, as an organization, give that workaround a limited 30-day prescription that requires a figurative call to the doctor to get a refill??
Maybe workarounds need to have a specific expiration date to help us from thinking of the workaround as the new normal that will be around forever??
Waste hides in workarounds – it eventually appears like normal work, especially when new people are taught the workaround as the normal process, as opposed to a temporary workaround…
Do you see examples of this in your organization? Have you been able to battle that workplace disease successfully?
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
I agree that an efficient system is better than a work-around. You see wasteful examples in every industry, then it becomes someone’s job to make those fixes and the problem gets further embedded. But what do you do if you’re empowered to fix problems at the end but not to rearrange a system?
Hi Daniela – yes, it’s easiest when it’s something you have direct control over in your local workplace. Let’s say you are the O.R. — you might not have direct influence to get the sterile processing department to help initiate improvements. That’s where senior leadership needs to play the role of servant leader (listening to the concerns) and then influencing change across the broader system (or across the “value stream” if you wil).
Mark Hamel’s Kaizen Event Fieldbook has a great story where a team tried to enlist a sensei to help them reduce the cycle time of a re-work process. The sensei refused to help them unless they worked on improving the need for re-work.
I like the idea of an expiring workaround if you must use it in the interim.
How do you know which one is the workaround.
Imagine a government department spent millions on a computer that didn’t really do its job properly. The staff build one thousand small workarounds to cope with every problem.
the Lean group ask those staff what can be done.
Of course they could standardise the workarounds, pick the best of them, make them visual, etc etc
At the end of the day, all of them were caused by a computer program that never met its objectives.
So you say “Fix the computer then” but what if the government department was tied up politically – couldn’t ask for more money, wanted to keep the story out of the media, didn’t want to sue the original contractors.
Stuck in Limbo-land for ever with a half-baked process.
Of course I don’t know of any examples of the situation above in real life…
It’s why Deming was justifiably suspicious of computers, and why Toyota are still using a lot of labor where others are using automation.
You can only “see” the attributes of a lean process inside a computer such as flow, WIP, balance and so on, if someone knowledgable about lean built the computer and programmed those attributes to be visible.
Typically they don’t though – and the software architects and BPR types want ‘black box’ approaches where you just get an ‘answer’ out the end, but you don’t know how the computer arrived at it. And these types seem to be skeptical about the human interface, expecting humans to work around the machine’s limitations, rather than the other way round.
Not all computer programs have the same degree of inflexibility, though I’d agree that they are more likely to be “monuments” — like machines or load-bearing structural components in a factory than otherwise.
At the same time, in government, I know that in at least one HUD office, the IT folks are being responsive about changing process details that are obstacles to smooth flow. It’s not a massive overhaul so it hasn’t required massive dollars. The same is true of one of our large public utilities. It’s solving small problems in real-time to make improvement happen.
The big overhaul may be necessary in the long run, but the processes to be automated are less likely to be replicated in their inefficiency, and everyone will have a clearer idea of what questions to ask the IT system vendor.
What I’ve typically seen is:
-no genuine analysis of actual process, more likely documentation of summarised or ideal process.
-lack of analysis of root cause – IT analysts fixing symptoms of business problems rather than the heart
-“training cures everything” rather than design to minimise training requirement
-blame the user
-‘escalating commitment’ – more money thrown at systems that really need to be removed as they are too far gone
-building IT around the ‘ideal’ customer rather than the typically difficult ones
-and the analogy to the “I don’t like what my girlfriend/boyfriend does, but when I marry them I’ll get them to change” in other words, our culture isn’t great, we don’t provide training or recognition or autonomy to staff, but when the new IT system comes, we’ll start then.
A well working piece of IT or software should be like a pocket calculator, simple, easy to use and 99.9999999999% reliable. When it doesn’t ‘feel’ like that to me, I can be pretty sure it’s gonna fail at a key point.
Some good examples of IT that I see as an end user are airline on-line or booth check-in systems, look like they’ve been simplified and tested to within an inch of failure.
Let’s hear it for the older stuff – the card-based index systems, the punched cards, the charting on grid-square paper and so on we used to do.