Stop Chasing Symptoms by Asking 5 Simple Questions:
I’ve always thought of myself as a “systems thinker”. If you read my previous post here on PII about Transitioning from Startup to Optimisation Successfully then you may know what I mean. A systems thinker is someone who takes the broader “system” into consideration before getting on with the fix to any particular problem.
It’s the mechanic who asks about a car’s sounds and how it drives before he dives under the hood. It’s the IT Specialist who queries about recent network changes and software updates before he digs into the event log.
Although my last post focused on differences between startup and normal operation of an offshore oil and gas platform, it applied the same basic philosophy of initiating each task with questions and analysis so as to understand the big picture.
Today I’m reminded of a project that I led while working in the Pharma sector. The facility was a bi-layer tablet manufacturer located in Ireland. This was one of my earliest management assignments. I had a team of engineers and techs programming and validating the control system. We were tasked with coding of the control scheme for solution preparation and tablet coating as well as applying changes as the process and recipe evolved. It was a good crew – clever and inquisitive….mostly.
European Integration and Sales, Control Station
At that moment I ignored the voice in my head which cautioned me to step back, slow down, and think.
In spite of our collective training and experience we found ourselves falling into a common trap: Fixing one problem only to find or cause another. I recall over 250 change controls processed from FAT to SAT. The team learned quickly to question how each change might impact the rest of the process and to adapt accordingly.
When a broad systems approach to problem solving isn’t applied, bad things can happen…and they often do. That was the case when an improvement to the process’ cycle time wasn’t initially achieved. The first sign of trouble came about when the cycle rate didn’t increase in spite of our code changes. A technician alerted me to a slightly decreased vacuum pressure used for vessel transfer.
At that moment I ignored the voice in my head which cautioned me to step back, slow down, and think. Instead of verifying the tech’s assessment and considering why the rate hadn’t improved, I opened the powder inflow valve slightly more to reduce the vacuum.
Indeed, adjustments to the powder flow had previously resulted in slow or even stuck transfers. By acting on old information I chose to rely on my instinct rather than my intellect. Needless to say the powder flow wasn’t the root-cause of the problem…just a symptom.
A narrow perspective is often counterproductive. By jumping in immediately I limited my view of the problem and failed to consider other possible reasons for the blockage. In this case I’d overlooked the docking station that was located between the infeed bin and the holding chamber.
As an integral part of the overall system the docking station had a direct impact on the flow rate, lowering it sufficiently that the improved cycle time couldn’t be achieved. It was the root-cause that I should’ve gotten to sooner. Once it was properly addressed the gains in powder transfer were realised. It was one of those experiences that stuck with me, and it influences how I approach all projects – whether simple or complex.
My systems thinker approach involves asking these five basic questions:
1. How has the process changed?
Like the mechanic and IT Specialist it’s essential for process engineers to determine “what’s changed” or “where could change have happened” before calibrating a sensor, repacking a valve, or tuning a PID. Simple, everyday events such as a change in feed stock, a software patch, a valve replacement, or even a change in weather can all have a significant impact on a process. Ask around operations, engineering, and maintenance in order to know what new conditions exist.
2. Does the solution make sense?
Try as you may, tuning a PID controller won’t correct for Stiction. It’s one thing to correctly characterise a problem, and it’s another thing to develop an appropriate corrective action. If your solution is temporary or fails to address the core problem, then it’s not really a solution. That may be OK if your temporary fix is Step 1 in a series of adjustments. Sometimes buying time truly does make the most sense, but you must circle back around.
3. What other factors might come into play?
Most manufacturing sites operate complex, highly interactive processes. When assessing symptoms be wary of getting caught off guard and overlooking the impact of a secondary line, a recirculating loop or the performance of some upstream system that’s trickling down thru the process. Even details that seem trivial can colour your assessment. Don’t get caught wearing rose coloured glasses.
4. Does data support the conclusion?
Today’s manufacturing plants are awash in data. There is likely an available data resource that will either substantiate or refute your assessment of the problem – regardless of the hypothesis. Diagnostic tools can help you evaluate data by providing finite measurements of oscillations, noise, valve movement and such. In the end the goal is to increase the odds of a successful outcome by capitalising on the plant’s existing resources.
5. How can I validate the ‘fix’ after implementation?
If there’s data to support the proposed corrective action, then the same data can be used to verify that the action did the job. Always keep in mind that it’s essential to measure performance both before and after a project. Indeed the job isn’t complete until there’s confirmation that the issue was resolved. I know very few plant managers who are satisfied by my word alone – they expect concrete evidence.
The concept of a systems thinker and applying a broader, closed-loop perspective to process control and plant-wide optimisation isn’t new. I’ve adopted the philosophy in my work and even written on the subject.
From the early days of my career it’s helped me to recognise symptoms for what they are and to avoid chasing phantom problems. If you’ve applied the systems thinker approach – or another that’s proven successful – please share your experience with me and the community here on PII.