Want advice on implementing Statistical Process Control in a maturing manufacturing organizationThe scenario: We have a LIMS that pushes QC test data from manufacturing to a data warehouse. We have a handful of JMP users. We want to finally introduce a systematic approach to SPC and are discussing different strategies how to do that. One of the things that came up was the disappointment that we are not able to wholesale tap into our LIMS system, but will most likely have to pull the data for trending from the data warehouse. The fact that we haven't had LIMS for a long time resulted in relatively dirty data sources, requiring a lot of cleaning. Yet, cleaning is necessary even with data coming from LIMS due to various and continual changes in the LIMS system (new products requiring new QC tests are introduced, discontinued products and their QC tests are not needed any longer, changing test names, new sample types, configuration changes, etc. etc.). My impression is that this is just how it is: Things change, data literacy levels vary, data discipline is not rigidly enforced, LIMS super users are most often not data warehouse users and often things just work out differently than planned.
One key comment by a team member was the suspicion that Big Pharma is much better organized in terms of data and the question was asked whether our strategy is potentially too complex (LIMS --> data warehouse --> data analytical tools tapping into data warehouse).
Questions:
- Is the approach of pushing data from LIMS to the data warehouse and retrieving it from there again for trend analysis uncommon?
- Are data sources in Big Pharma on average cleaner and better managed than in other areas of manufacturing?
- Are there any standard "one size fits all" approaches of getting where we want to get?
- Isn't JMP just a gem when it gets to data base connection, automation and SPC?
- How to best publish SPC graphs without resorting to JMP Live?
- What other important information can I feed back to the team?
Thank you very much in advance!
Quality and Process EngineeringRe: Want advice on implementing Statistical Process Control in a maturing manufacturing organizationHere's my seven cents (one for each question and a bonus thought:
1. No. During my tenure as a JMP senior systems engineer with many users in Big Pharma this is a common data pathway.
2. No. It's always 'dirty' and data cleanup and surveillance is a big part of the job.
3. No.
4. IMO, JMP is world class.
5. There's always JMP Public or creating a Dashboard application where you internally control who has read/write access.
6. Begin your system design with the end in mind. Then reverse engineer the data acquisition, clean up, reporting, and distribution.
Bonus thought: At the risk of making work for the JMP systems engineer on your sales team, engage that person with these questions to pick their brain. Who knows...maybe there's even a JMP customer that would be willing to talk to you as well.
Re: Want advice on implementing Statistical Process Control in a maturing manufacturing organizationHere are my thoughts/questions:
SPC is an analytical tool. In order to use it correctly, you must understand rational subgrouping and sampling strategies. How you get the data is a very important decision.
“The engineer who is successful in dividing his data initially into rational subgroups based on rational theories is therefore inherently better off in the long run. . .”
Shewhart
SPC and the control chart method was invented (Shewhart) to answer 2 questions:
1. Is the variation associated with the within subgroup sources of variation (The x's varying within subgroup) stable and consistent? If not, why not? This is consistent with Deming's Special cause/Common cause model. If you are looking at data after the "special cause "event" happened, you are missing the opportunity to learn about what happened in real time.
2. Which sources of variation have greater leverage (are dominant), the within or the between? The X-bar chart is a comparison chart. It compares the variation due to the within subgroup sources (the control limits) to the between subgroup sources of variation (the plotted means). It helps the investigator understand where to focus their work.
With this in mind, I'm not sure what you are trying to do? It seems you are interested in plotting data and making this visible to many. This is not a bad idea, but it is only part of the intended purpose of SPC. What SPC was intended to do was to understand causal structure (analytics).
Re: Want advice on implementing Statistical Process Control in a maturing manufacturing organization@statman, thank you for your questions! These questions are very useful.
By "causal structure", I assume you mean the identification of assignable or special causes. In our case, it can take a very long time to manufacture a single batch. Each batch is subject to a comprehensive testing program, resulting in a number of measurement results which we for now assume are representative of the true quality of each batch.
Personally, I don't think we have any reason yet to group the data for multiple batches into rational subgroups. We'd probably only see a lot of variation within each subgroup and have little data to plot along the horizontal axis. So we are really only thinking individual and moving range charts for now, since what we are trying to understand or learn is what causes variations in quality from one batch to the next.
It is also unclear whether we know and fully understand all sources of variation. Presumably, we'll start off by interviewing process engineers about what their thoughts on individual sources of variation are. Next, I am thinking we'd be trying to control these sources of variation individually to test whether we are able to obtain a more consistent process output, i.e., whether batches manufactured in sequence become more similar than they are now. As a result, we'll probably need to define different phases in these control charts, associated with the different initiatives targeted at controlling the individual sources of variation. I imagine that documenting these phases can be problematic: How to call them / is a specific nomenclature required? Where / how to log them and document them for posterity?
As things are now, we have no choice but looking at the data after the "special cause "event" happened, and - as mentioned above - we have little to no understanding of what the specific special causes in each case are.
Are these adequate answers to your questions or am I overlooking something?
What more do you suggest to think of?
