Floyd on Factories: Cost of Quality - top rationale for undertaking a digital transformation initiative.
Welcome to the first installment of Floyd on Factories and thank you for spending time with me.
To get started I’ll cover the top rationale for digital transformation I heard in 2022: a desire to reduce the cost of quality.
This was by far the most common concern that I heard from executives in the past year.? Of course, each organization had its own unique causes for quality issues and a varying cost associated with them.? Nonetheless, the desire to resolve these issues was fueled by the potential savings, across the board.
To summarize, here is a short list of the concerns, and the associated cost as expressed by each organization.?
Interestingly, when I discussed potential methods for resolving these issues with executives, the common theme was “been there, done that, didn’t work, need help”.? So to help these organizations move forward, I created a framework that would help them structure existing efforts but also plan for success in the future. Furthermore, it intentionally focuses on when, where and why to apply technology without explicitly stating a specific solution. There are many factors involved in what type of technology is applied, and frankly I prefer to delve into this after clarifying the objective.
I’ll admit I did not start with the idea to abusively use onomatopoeia, but it certainly fell into place.
While it's probably quite self-explanatory, I’ll break down each “C” so you have … clarification.
Cost
The framework starts by first documenting the cost of (poor) quality and importantly, the time it will take to resolve it.? Depending on the organization, and the relationship between stakeholders in Operations, IT and Finance, this can vary significantly.? As an example, during the onset of the Pandemic, I found many organizations expressed the ‘cost’ as the impact of scrap on scarce inventory from their suppliers.? I also heard that the cost concern was identified as escalating express freight charges due to avoidable but nonetheless gross inefficiencies.? Only a year later there was a shift from “get as much as we can from what we have on hand” to “reduce the cost of rework, and its impact on deliveries”.? Today I would argue that the trend is “reduce customer returns” or “reduce onsite repairs”.
What is most important - irrespective of the actual need - is to establish an initial target for improvement.? It may change over time, and this is why I advocate documenting and prioritizing a gamut of cost factors, but it should start with an immediate need where the outcome / resolution is achievable in the short term.
Collect
Once the target has been established, we need to determine the right information to collect and to identify its source. The answer is not always from a PLC and nor is it collecting everything from its data model.? It could be data that already exists through an existing collection method, such as an MES system, factory historian or SCADA.
The adage that the answer is in the data you already have is often true.? Hence I advocate evaluating what is available, and treating it like any other resource. It has to be evaluated for the quality of the data, the ease and rate with which it can be acquired, the time it will take to action the data and the desired future state of the data platform.
领英推荐
Calculate
I have seen a fair amount of unused data stored in Historians.? Honestly it's quite common and perhaps more than most would admit.? There are many reasons why - all of which can be addressed - but without using the data in a productive way it will probably go back to being archived.? This is why I advocate using the data to calculate insights that are frequently updated.? It shows there is a purpose behind collecting the data beyond just visibility, diagnostics or post mortem analysis.? This is crucially important for adoption, but also it demonstrates the potential: one successful idea often leads to another.
As a practical example, during a factory tour I asked how the organization was generating OEE for their daily stand-up meetings - somewhat rhetorical.? Of course, I was standing in front of a wall covered in spreadsheet print-outs so the likelihood of the answer being ‘manual’ was high.? Predictably, they were not calculating OEE consistently from one plant to another, and after a quick review of the spreadsheet, they were not calculating OEE correctly anyway.? I did not need to point out the effort required to create the spreadsheets, nor question the freshness of the data and its usefulness. The beauty of using calculated insights is that they are explainable and consistent.
Correlate
One of the least explored methods of understanding the cause and effect of data in manufacturing is correlation.? I am sure that there are many people who would argue otherwise, but in my experience it was at least entirely under utilized.? There is a reason why.? Correlating an event in one part of the manufacturing process with another is not always easy.? It requires cross functional knowledge, multi-disciplinary knowledge, and often, data science expertise.? Furthermore, validating the results in the real world can be time consuming and costly - two dimensions that most manufacturers have little patience for.
However, I believe the benefits outweigh the costs.? I have seen great results that provided a definitive cause, effect and resolution.? In particular, I was very encouraged with the results of?a recall mitigation program that used correlated data from significant systems to identify an endemic problem before it reached any level of scale.? In this case, the correlation design originated from pure practical experience; in a meeting to form a team that could own 'correlations', an experienced field engineer almost casually noted the exact conditions of an exemplary example and the associated cause of the problem. The same engineer even pointed out that the data from a diagnostic computer easily supports his assertion. Of course, the meeting ended with a clear path forward: work with this engineer to document the known issues and the data correlations that would automate a diagnosis.
Confidence
I recently introduced a step in the framework to assess the level of confidence in order to take a specific action. The actual metric can be used to automate the exit criteria, or to garner support for a decision.? I discovered that confidence is critically important when using an advanced analytic such as a forecast or prediction.
As an example, after implementing a rather sophisticated predictive maintenance system I was surprised to see that the organization did not implement the process changes as intended.? Instead they admitted the challenge was gaining the confidence of their personnel involved in the process to trust that the prediction was actually right.? Their inability to act upon the insight was due to a fear of doing the wrong thing when the accountability chain pointed at an AI.? This challenge was overcome by explaining how the prediction is generated, classifying it as an early warning indicator, and assigning a confidence level to it such that real-people were in control of the outcome.? In reality, the confidence level was almost always above 90% because the solution filtered out anything below this threshold on purpose, but by displaying the value it gave people confidence that it could be trusted.
Continue, Correct, Cut
Finally, the goal of any data based outcome should be an action.? I am not a fan of simply creating analytics that simply inform people about the current state without any actions attached to it.? Hence, I believe that the goal of the analytics is to drive a decision within the process itself, and in some cases it makes sense to automate the action so there is a definitive action taken.
I therefore advocate that three decisions are made: a) continue as is - situation is normal, b) correct the situation without stopping, and c) cut the process to prevent any more loss.? It's a simple method and essential to ensuring that actions are taken.? When used in the planning phase of a digital solution, it ensures that data is not just for data’s sake, and it also opens opportunities to use automation and gain additional benefits.
I hope you have found this edition of Floyd on Factories to be interesting or informative. Next I will cover the goals manufacturers have for developing new business and how they have chosen to move forward.
As always, I look forward to your feedback.
President and Business Development at The vdR Group, Inc.
2 年Hi Simon ... wow, nice and very relevant writeup. Thank you for sharing these insights.