Balancing Risk and Improvement
Process improvements. That section of nearly every pharma manufacturing engineer’s job description. It’s one of those headliners at end-of-year reviews, “I’ve improved efficiency by X, I’ve saved you Y! How about that bonus/increase?”. It’s only natural for engineers to fall in love with the improvements they’ve concocted, it’s just generally how we’re wired and can be a big ego boost when it’s something that you’ve instigated.
But there’s another side that doesn’t generally get highlighted enough. The risk of impact and how the optimism of well-intentioned engineers can cloud the view of that risk.
Here are a few things to consider when embarking on improvements to existing processes, both for those well-intentioned engineers and those people part of the decision-making process on go/no-gos.
1. Is the improvement worth it?
"We saved 20 seconds on this process cycle! When do we tell the CEO?" You also spent 200 hours of SME time on a painful big change control and the ROI is the year 3257. No one’s getting that time back and you’ve probably burned any social capital you’ve built up (Yay?). This should always be the first stop, what’s the cost/benefit analysis even before risk. Some engineers like to gloss over the costs and only focus on the benefits. Don’t be that engineer and hold your engineers to this standard. If you can’t have a detailed line-by-line breakdown of the costs (time of people, all materials, facility time, monetary cost), you don’t understand it enough to begin in the first place. Return to GO and do your homework (or something else…).
Risk reduction as a benefit is a notoriously difficult one to quantify because humans just aren’t terribly good at decisions around unlikely events. It can also require large amounts of data to be truly confident and even then, if this information is being supplied by the vendor selling something, you need to look at those cherry-picked figures and sanity-check them. If the risk isn’t fairly intuitive and clear to see, probe the data.
2. What’s the absolute worst case?
If the possible answer to this is “stop production”, you better have a good hard think about floating it. No one wants to be that person who brought down a critical manufacturing line with one of their great ideas because they didn’t do the due diligence. Spend time really thinking about these, get creative and bounce it off others for different perspectives. One example I’ve heard anecdotally was a time reduction of a cleaning cycle. Changes were made without understanding the rationale and impact of the original design decisions and the cleaning was compromised, resulting in scrapped batches worth millions.
3. How robust is the knowledge of the current process?
Pharma manufacturing processes are highly complex, there’s really no escaping that. What can be controlled is how well understood it is, the critical factors and what influences them, where the landmines are and how it all fits together with the various designs and documents. It has to be considered how knowledgeable the people involved are on this specific process, especially the lead of the change. I’d argue that if someone’s less than a year working on this specific process, they haven’t had the time to be exposed to the tacit knowledge needed to fill in the unknown unknowns and can’t be let loose on any anything critical.
A good way to test that process knowledge is robust is to get the improvement lead to bring others through the change. If a clear before/after and the risks involved can’t be demonstrated, put up your hand and say so. Another consideration is how long the process was put in place. If the improvement driver was part of the original team who setup the process, they unconsciously have huge amounts of tacit knowledge somewhere in their head. Compare this with some engineer rocking into a process that’s been setup 20 years. Knowledge leaks over time and as knowledge goes down, risk goes up.
4. How can we best understand and manage risks?
Can the change be tested or setup in parallel? Can it be rolled back if needed? The best engineers plan for Murphy’s Law. If things hit the proverbial fan, it’s not going to look great if you’ve no backup. Are there other examples of similar improvements? If not, your risk of unknown factors is much higher. If so, pick up the phone and talk to those SMEs. What were some implementation problems? Were there any teething issues? After 6/12 months, was the benefit realised? If not, why and what else would they recommend looking out for?
If you go through all the above, the go/no-go decisions should be clear. As sad a thought of just leaving inefficiency in a process, a positive outcome could be doing (drum roll) nothing! If you don’t have a very high level of confidence or reduced the risk of any potential impact to an acceptable level, shelve it. See the assessment as a learning exercise to better understand your process and a win in itself. Just make sure you capture that newly created knowledge so it’s findable/usable in the future and be honest with any gaps there might be.
I don’t want to add to the anti-innovation rhetoric of “if it ain’t broke”, improvements should always be looked for but not just for the sake of change. A clear assessment of the cost, risk and benefit needs to be put together and stress-tested with others. If it’s still standing after this, what are you waiting for?