The Incidents Management Module User Guide

Getting going.

Navigate to the incidents module using the left navigation menu.

The incidents module.

An incident is an unplanned event, acknowledged by the quality management system. Examples of incidents might include customer complaints, quality deviations, health and safety accident reporting, or non-conforming product identified by analytical testing.

You can record a new incident using this form.

The incidents module.

The source of information determines incident property choices such as category of fault.

Using the source of event information as a principal attribute helps to orient the quality system toward root cause analysis and enables appropriate categories to be inferred.

The source of information determines incident property choices such as category of fault.

Category of fault is dependent on the source of event information for the unplanned occurrence.

In the example, we’ve specified ‘process/manufacturing’ as the source of information – so the categories of fault available to select from are behavior, equipment, process control, product contamination, product quality, and storage and handling.

The categories of fault will update according to the source – so for example, if we had selected H&S and accident reporting as the source of information, the categories would be accident, near miss, and unsafe situation.

Category of fault is dependent on the source of event information for the unplanned occurrence.

Sub-category of fault is dependent on the category of fault for the nonconformance.

In the example, we’re selecting personal hygiene or PPE as the sub-category.

Sub-category of fault is dependent on the category of fault for the nonconformance.

Ownership of an incident can be assigned to a specific department or left unassigned.

Normally, the owner department should be the department or team most responsible for the management of whatever function or systems yielded the incident – i.e. the function or management systems that either led to the incident occurring, or are intended to reduce or prevent the occurrence of the unplanned event.

If the person recording the incident isn’t clear about what department or team that is, the incident can still be recorded with the owner department unassigned.

Ownership of an incident can be assigned to a specific department or left unassigned.

Ownership of an incident can be assigned to a specific individual or left unassigned.

As with the owner department, the individual responsible for the investigation can be specified, or left unassigned.
If there is a specific individual most appropriate to take ownership of the investigation, specify that person here.

A lot of the time, it can actually be helpful managerially if you specify the department, but leave the individual owner unassigned – because it enables the department manager to delegate responsibility as incidents are assigned to their department or team.

Responsibility for an incident can be assigned to a specific individual or left unassigned.

When you record a new incident, you’ll be redirected to the incident profile.

The incident profile has information about the incident, its investigation, and corrective/preventative action plan.

When you record a new incident, you’ll be redirected to the incident profile.

Change log.

You can update the incident record, and those updates will be reflected in the change log. You can also enter your own text updates into the comments/updates table to reflect the progression of the investigation.

Change log.

You can indicate a planned completion date for the investigation.

Add a planned completion date, and the schedule will update on the user dashboard for the investigation owner.

Adding a planned completion date isn’t mandatory, but it can really help you to maintain visibility of workload and deadlines.

You can indicate a planned completion date for the investigation.

The incident investigation appears on the dashboard for the owner of the incident.

We’re only just starting to interact with the systems in this demonstration account, but you can start to see the organisational benefits for transparency and communication. Here, we’re logged in as Terry, and the dashboard is flagging one open investigation, which is also displayed on Terry’s schedule.

The incident investigation appears on the dashboard for the owner of the incident.

The incident is listed for the owner department in addition to the site incidents management system.

From the moment an incident is recorded, it’s visible to anyone with access to the incidents management module here.

The incident is listed for the owner department in addition to the site incidents management system.

As the investigation identifies contributing factors, they can be recorded and categorised from the incident profile.

There’s often a combination of factors that led to the occurrence of an incident. You can list each contributor here, and categorise according to the nature of the cause.

As the investigation identifies contributing factors, they can be recorded and categorised from the incident profile.

A corrective action plan is generated for each contributing factor identified.

A corrective/preventative action plan is generated for each contributing factor. This is automated, so once you’ve recorded a contributing factor, the corrective/preventative action plan will become available immediately.

A corrective action plan is generated for each contributing factor identified.

Objective evidence and other attachments can be added to the incident record below contributing factors.

In the example, we’ve uploaded a photo of the non-compliance, and you can upload as much or little evidence as you wish.

Objective evidence and other attachments can be added to the incident record below contributing factors.

Corrective actions are integrated into the project management system.

The mechanisms for entering tasks and sub-tasks is exactly the same as for the project manager – which means there can be multiple responsive actions applied to any contributing factor. Alternatively, a single corrective action may be all it takes. It would also be possible to close these action plans without action where recording/trending is the only necessary action.

In any event, the systems give you the flexibility to manage and delegate as each situation requires.

Corrective actions are integrated into the project management system.

A single contributing factor might result in numerous responsive actions.

In the example, the non-conformance cited operators not wearing their disposable ear defenders correctly – with a contributing factor of ‘The disposable ear defenders are uncomfortable.’

3 Actions have been assigned to different individuals working in different departments.
Sami Harrell (Production Department) has been assigned the task: Evaluate alternative ear defenders for comfort.
Marianne Wood (Purchasing Department) has been assigned the task: Cost assessment for alternative ear defenders
Franklin Acosta (Health and Safety Department) has been assigned the task: Re-assessment of noise rating throughout different production areas

Each of these actions are associated with the contributing factor: The disposable ear defenders are uncomfortable. As with the project manager, sub-tasks can be assigned in cases where a multi-step corrective/preventative action plan is needed.

A single contributing factor might result in numerous responsive actions.

The incident status is set to investigation complete, responsive actions assigned.

The investigation record can be updated independently of its corrective/preventative actions. This enables you to differentiate between incidents whose investigations are ongoing and those whose investigations have concluded, while maintaining visibility of progress with responsive actions.

The incident status is set to investigation complete, responsive actions assigned.

Reassign responsive actions, and the change log will reflect as much on the project or task record.

Throughout operations, you can make changes and amendments and you’ll accumulate a record of updates. This can help if you need to go back and review the timeline, or if different people in your organisation need to understand a developing situation.

Reassign responsive actions, and the change log will reflect as much on the project or task record.

Responsive actions feature on the schedule located on the dashboard for the user they are assigned to.

(Just to demonstrate, we’ve reassigned a task to Terry.)

Responsive actions feature on the schedule located on the dashboard for the user they are assigned to.

When the actual completion date of the incident is set, the incident stops showing on the dashboard.

This also applies to the corrective/preventative action plans and associated tasks. They’ll be displayed until the actual completion date is entered, and then they’ll stop showing on the dashboard.

When the actual completion date of the incident is set, the incident stops showing on the dashboard.

Get the most out of it.

The way to get the most out of the incidents management system is to encourage everyone in your organisation to engage proactively in fault reporting.

Incidents can be recorded anywhere. With smartphones and other mobile devices, you can have complete managerial visibility of quality and safety occurrences throughout your organisation in real time.
Proactive fault reporting is the exact type of organisational behaviour that you’d expect to be exhibited by companies with a strong food safety and quality culture – so it’s reasonable to think that encouraging fault reporting would bring cultural benefits.

The advantages for continuous improvement will be proportionate to engagement throughout your organisation, so simply encourage your team to make use of the systems on an ongoing basis to see the greatest impact.