Event Detection and Workflow Management
“Angie, you have notifications pending” Show of hands, how many of you have received this email from Facebook? I have, and it’s because I set up my account so that I don’t get notified every time one of my “friends” does something. Therefore, my email inbox does not get filled with tons of useless notifications because why? I only want to see the important stuff.
Angie is a Sr. Quality Engineer and has been assigned the task of implementing an electronic real-time SPC solution at her facility. There are many things she needs to consider prior to implementation.
- Which areas of the facility are to be implemented and when?
- What processes in the product flow need to be monitored?
- What test characteristics are critical to these processes?
- How many samples are being tested (piece data)?
- How many locations or positions on each part (if any) are being measured (with-in piece data)?
- What kind of violations will be recorded?
- Specification limit violations?
- Control limit violations?
- Trending rule violations?
- What actions need to be taken when product falls outside specified parameters?
- Will assignable causes and corrective actions be required for alarm violations?
- Who needs to be notified when there are alarm violations?
- How will these individuals get notified?
To some of you, this might seem simple. These questions have surely already been answered and they are recording these things on paper. It just needs to be transferred into the new system, right? Yes, of course it does, but let’s not make any assumptions. Before implementation, there needs to be a clear understanding of what is desired and the SPC solution that has been chosen should have most, if not all, of these capabilities built in.
What constitutes an “Event”?
Is it just an alarm when a product falls outside upper and lower specifications? Not necessarily. An event could be that the line is down for mechanical reasons or that a data collection was missed. Detecting an event requires the system to know what is expected, so it knows if those expectations aren’t met. It is critical to understand everything that is required, such as specification limits, control limits, trending rules and data collection requirements. In detecting these events, the software recognizes an alarm violation based on the configuration and writes the event, hopefully to a central database. Some systems also allow the user to manually create an event, which allows the user to tell the system that the line is down, for example.
In many cases, these events may drive additional activities that directly affect the operator. An out-of-specification value may require an assignable cause and/or corrective action, or may require additional samples to be tested. It is very important to consider this workflow when setting up the system. Angie should be aware of this and get operator input to ensure the requirements are clear and the proper tools are in place to meet the requirements. Data needs to be entered into the system efficiently (data in) as much as it needs to be easily retrieved for review by upper management (data out). Once the data is collected, does anyone else need to be notified? If so, should these notifications be sent via e-mail, or will a report that is reviewed on a regular time basis sufficient?
Just remember, when you are preparing to implement a SPC solution at your facility to ask these simple, yet tough questions and get input from both sides of the workflow. Defining these items up front will give you assurance that your solution will meet the requirements you set out to satisfy.