Corrective Actions Process
Actions are about reporting what's been done after an Issue has been reported. QSToolbox provides a guided corrective actions workflow for resolving an issue. It's a guided workflow, so you can skip steps, add them out of order, and add more than one action per step.
If you want to plan and/or delegate what needs to be done for a corrective action, you can add Tasks under the Issue.
To add an action, click on the link for the appropriate step in the progress bar, or scroll down to the bottom of the issue to see the add action form and select the action type.
The steps are:
- Describe the problem
- Contain the problem
- Investigate the root cause
- Propose a solution
- Implement a solution
- Verify the solution was effective
Here's what you need to do for each step in the corrective actions process.
1. Describe the problem
It may be unnecessary to add a 'Describe' action if the issue has been fully descibed already within the Issue description. There's no need to duplicate the information in an action.
As more information comes to light, you can add more 'Describe' Actions to capture all the details about the Issue and its impact. Other team members can also add their observations by adding another 'Describe' Action and uploading any relevant files or images that help describe the problem.
When describing an Issue, you want to provide details of what happened and why it is a concern. Include any information about circumstances that may have led up to, or contributed to, the occurrence. Record details about the actual impact of the problem - who has been or will be affected and how (e.g., delays, costs, function, customer satisfaction, safety, etc.).
It's often helpful to include any tracking information that links the issue to your other systems or records - e.g., job numbers, work order, purchase order, RMA#.
Where the problem has not yet occurred, or there was significant potential for more serious consequences, these risks should be described. The level of risk associated with the problem will affect the nature and priority of actions that are taken.
2. Contain the problem
Containment actions are meant to prevent or minimise any further consequences. These actions are a temporary fix for damage control, and include steps to:
- 'Put out the fire' - this initial step is simply to stop the problem from continuing.
- Contain all effects - stop anything affected by the problem being released to the customer, prevent further processing (which will be wasted effort), and determine if anything has already escaped.
- Assess the damage - determine what and how much damage has been done and if anything can be "repaired / replaced / recovered".
- Notify the customer, as appropriate - If defective product may have already been released, notify any impacted customers. You may also need to notify customers if there will be a delay to their expected delivery date.
Note that there have been no actions yet to correct the cause of the problem.
Multiple 'Contained' Actions may be added to an Issue in QSToolbox to record everything that was done to contain the effects of the problem.
Some issues may not require a 'Contained' action if there were no effects to contain, e.g. improvements.
3. Investigate the root cause
This step is about finding out the cause of the issue so that you can fix the right thing. You need to distinguish between the observed symptoms of a problem and the fundamental (root) cause of the problem.
The investigation will involve collecting and recording relevant data, talking to stakeholders, and looking into all possible contributing causes. The investigator will also evaluate if similar issues exist, or could occur.
Record the information you find by adding one or more 'Investigate' Actions to the Issue.
There are many different techniques to assist in determining the root cause. One of the simplest is to ask a series of ‘why?’ questions (ref: 5 WHY technique) to dig deep into the situation until the fundamental reason for the problem is found. There may be more than one significant contributing factor.
It is important that the investigation is not about finding someone to blame. Look instead at where the process failed, or could be improved.
4. Propose a solution
Describe in detail one, or several, possible solutions that address the root cause(s) in order to prevent recurrence (or an initial occurrence) of the problem. It's important to record the different solutions that were considered. If the selected solution is not effective, you may need to come back and reconsider another options.
Different options will be evaluated on factors such as the severity of the issue, the likelihood of it occurring again, as well as the cost and effectiveness of the proposed solutions.
5. Implement a solution
Once a solution has been selected and implemented, record in detail what was done. You can attached evidence of the solution as files or images uploaded to the 'Implement' Action.
If it is decided that no actions will be taken to address the Issue, the reason(s) why must be recorded.
Adding an 'Implement' Action changes the Issue status to 'pending' - i.e., waiting for final verification that the measures taken to address the problem have been effective.
6. Verify the solution was effective
After the implemented solution has been in place for an appropriate time and the problem has not recurred, record details of the objective evidence that prove the actions taken have addressed the problem.
If the implemented solution has NOT been effective, the issue should not be closed. Further actions must be taken to address the root cause of the issue. Add an appropriate Action to record what was done to 'implement' a different solution, 'propose' an alternative solution, or go back to 'investigate' further.
Adding a 'Verify' Action to the Issue will change the Issue status to 'closed'.
Your QSToolbox system can be configured to allow, or not allow, the Assignee to close an Issue. If you decide that assignees can't close Issues, then the status field 'closed' option and the 'verify' action category will only be available to a user in the 'issues_managers' or 'staff' permission groups.
Other
This category can be used to give an update that doesn't fit into any of the other workflow categories.
You might use 'other' when you're waiting on a response from someone else (e.g., a supplier) and you want to add a note to say you've followed up. In this example, nothing has progressed and there's no new information, but this is a good way to show the Issue hasn't been forgotten.
