In continuation to some of the other posts in the topic of metrics and KPIs, this time I would like to discuss the use of metrics. So, not so much what the metrics are or which metrics are most important, but how do we use them. If we look at how analysis is performed we may be able to gain some insight into how the data should be collected and structured. This may be for example to support lean or process improvement initiatives. The idea regardless of methodology requires that the team or person gain an understanding of the process and its behaviour based on the data at hand.
I think the best way to frame this up is to tell the story of a persona in a simple scenario. Let’s consider Patrick Process Engineer who is trying to understand yield fluctuations specifically and maybe the yield’s behaviour in general. He is perplexed about why he cannot accurately predict yield given that most of the processes are “in control” (yes, another one of these myths about processes). What he really is striving for is an understanding the process and the best way to investigate it – in other words analyze the process.
Obviously Patrick will be looking at the Yield metric(s) and once he sees some fluctuation he will embark on an analysis. Typically he will perform what I call a high-level analysis, which is kind of a “look-around” in the data and maybe other related metrics to determine patterns. But wait, why patterns. Well whether we like it or not when we analyze processes we naturally look for patterns since that is what complex processes really exhibit. I guess I need to write a bit more about the complex adaptive behavior of manufacturing systems, but let me leave that for a future post. For now let’s just say that the patterns really tell us about the dependencies between the different metrics and parameters in the system.
OK, once Patrick has performed is “high-level” analysis he may then start digging a bit deeper in to some of the areas that may lead him to the root-cause of the fluctuation. He may perform some more detailed analysis, maybe choose to monitor some specific metrics, define some additional more detail or focused metrics. If he really is trying some advanced analysis he may try and observe dependencies between metrics for a period of time. That means monitor maybe a few metrics and how they change in relation to each other.
What is described here is really a simple scenario of human behavior exhibited when we perform troubleshooting. Although this as simple behavior for us, when we think about the data and data structures that we need to support what Patrick is trying to do, we may quickly realize that the complexity abounds. Modern business intelligence concepts such as multidimensional analysis, OLAP, and practices for data aggregation provide the tools. However it takes a lot of work and process knowledge to transform the base process data to such information structures.
This I believe is the main challenge in modern manufacturing systems. Compounding this problem is that effective analysis needs to use information from all the host of system that may reside in a manufacturing business, i.e. ERP, MES, Automation, Historians, LIMS and others. Most manufacturing intelligence tools that are in the market today simply do not address this simple scenario. If we do our inbound marketing work correctly and draw up the scenarios above, with Patrick our main persona, the problem definition is straightforward; however the engineering task required to solve it is not.