Supporting Continuous Improvement Efforts with Incident Management (Part 2 of 2)

This post is a continuation of my prior post “Supporting Continuous Improvement with Incident Management."

I’m working with a customer right now that’s using Incident Management to support their continuous improvement efforts. As an example, one incident that they are particularly interested in is a tool change event – periodically they need to stop manufacturing and re-tool an asset. There’s a downtime hit when the asset is being re-tooled and there’s scrap associated with the event. How long the re-tooling process takes is varied, we know when it occurs and we know how long the asset has been in the tool change state – we’ve taken Mike’s first step and armed ourselves with data. What we’re interested in is catching the top 20% of the tool changes that take longer than they should (and represent 80% of the downtime). We want to manage them to completion, quickly, and capture as much intelligence as we can about why the incident occurred and what was done to resolve it. 

We’ve defined a “tool change incident” to be a tool change that is taking longer than [an acceptable period of time]. When the incident occurs, the workflow based system is instantiated and we log all relevant data related to the incident in the system. The appropriate leads on the floor are notified instantly that an incident has occurred and they are prompted to perform an investigation of and document the incident as well as the response that was taken to resolve the incident. As this isn’t a critical incident and we’re still in “learning mode”, we’re not requiring review and approval of the response (we are skipping the final two steps in the process). Actions required of users that are not complete in an acceptable period of time are escalated and managed appropriately.

As we learn more about the tool change incident we expect that there may be changes to training and tool change procedures. If warranted, a specific workflow can be developed to manage the tool change process and we can instantiate it when a tool change is required, managing the execution of the procedure and error-proofing it. We don’t expect that we will turn off the tool change incident because it provides assurance that 100% of the tool changes that are taking longer than acceptable are being managed properly. We do expect that the average time to complete a tool change and the standard deviation of tool change times will decrease – and the frequency of occurrence of the tool change incident will decrease as a result. Since we can measure this we can quantify the impact that we are having on the operation (in terms of improved availability and actual dollar savings). 

Providing support for the continuous improvement process with incident management provides significant benefits:

• We know that every incident is being managed in a consistent manner – 100% guaranteed execution and process compliance.
• We know that the appropriate people are made aware of and acting to resolve incident on occurrence – we have the right people on task.
• We are capturing information related to incidents and their resolution in real-time – there’s no after the fact documentation that we all know is error prone and all too often ignored.
• We have all the information we need to quantify the impact of incidents, their frequency of occurrence by asset, by tool, by process, by product, by operator, etc., and how long they take to resolve – all data is correlated to specific incidents.
• We have the ability to categorize and Pareto the causes of incidents and have documentation about how they are resolved – we can prioritize continuous improvement efforts.
• We are providing summary statistics and reporting in and managing user interactions through the corporate SharePoint portal – everyone has visibility.
• We have made all relevant data openly accessible via SharePoint and OData services and it is stored in a back-office / IT friendly, managed system – it’s a highly scalable and manageable solution.

I’ll be writing more about incident management in upcoming posts and how we are using workflow automation to support continuous improvement, lean and six sigma initiatives. If you are interested in learning more about Incident Management don’t hesitate contact us, we’d be more than happy to provide additional information and a demonstration of the system.

Supporting Continuous Improvement Efforts with Incident Management (Part 1 of 2)

In our last post on Level3, “Ghosts, Goblins, and Monsters – The Power (and Danger) of Visibility”, Mike Stuedemann included a fantastic list of actions that you can take to maintain and build the organizational courage to follow through on improvement efforts. I’m particularly fond of the (adapted) Voltaire quote “perfection is the enemy of done” and his recommendation to start simply and iterate often. The continuous improvement process works, anyone telling you differently is selling something. 

But there’s a situation that I run into very frequently, more often than you would expect, when I am talking to customers and prospective customers. They have a known list of “problems” that are impacting their manufacturing operations, sources of waste and inefficiency (scrap events, unplanned tool downtime, frequent setups, etc.) but they don’t have enough information about them to quantify their impact and prioritize them, let alone address any underlying root causes. Recognizing and acknowledging this is a good thing because there’s a lot you can do to support the continuous improvement process.

One thing we advocate is having a rigorous business process in place to manage how you respond when problems occur – we call it Incident Management. It’s a “Workflow based System”, a tightly defined collection of configurable workflows that work in concert to manage incidents through a standard process – Creation, Notification, Investigation, Resolution, Review and Approval. Incidents can be configured to run through the full process, or a subset depending on the level of response required. User activities are managed through a SharePoint portal and directed to participants based on roles. As it is a collection of workflows, so it’s easily reconfigured to meet unique customer needs.

In a couple of days I’ll publish a follow on to this post. I have a customer example that will help describe the functionality and benefits of Incident Management, so stay tuned.