This white paper provides you with information about the functionality requirements of ‘best in class’ systems in the Australian market and the minimum requirements your company should be looking to achieve from its incident reporting system. Whether you are looking to build your incident reporting system in house, engage a development team to create one or purchase one of the many incident reporting software systems currently on offer this document will help you understand the requirements to look for when consider a world class system.
Comparing incident reporting systems will always be subjective to the unique requirements of your organisation. However, there are a number of generic elements and minimum criteria that each system must be able to perform in order for it to meet the Australian Standards AS/NZS 4801:2001. In addition, there are other important factors that make an incident reporting system valuable to your organisation as a whole. This document allows you to understand the benefits and value that each system brings to your organisation.
Let’s start with the basics
Incident reporting systems are vital components of your total OHS safety management plan, they need to be capable of engaging your staff and contractors (if you use them) and they must deliver the reporting capabilities that let your company understand the trends and issues that surround your workers’ safety.
Software today comes in two distinct types, hosted and non-hosted. Hosted software is operated through the internet and is often referred to as ‘cloud computing’. Non-hosted software is generally hosted and maintained by an in-house IT department. In addition to all this, consideration should also be given to incorporating hazard management. Incident reporting is one half of the puzzle when your company is committed to a solid and sustainable safety system. Incident reporting on its own can be viewed as being re-active whereas hazard management is about being pro-active in eliminating or reducing the risk surrounding potential hazards.
What to look for: step-by-step
The 4 basic elements of incident reporting are:
Reporting an incident
Investigating an incident
Setting corrective actions
Issuing meaningful reports on the data captured
We will focus on exploring each of these four basic elements to understand the functionality required in a best-in-class incident reporting software system.
Reporting an Incident
When reporting an incident the software must allow for a user to enter the data about the incident in a simple and easy manner, using familiar interface technology. If you present the person filling out the report with too much information it can be daunting and may mean they overlook reporting smaller incidents, which often leads to larger and more costly incidents.
When entering names, the user should be able to find them in a database rather than re-typing them every time. This also means the system should be able to return you information about the amount of incidents a person has been involved in. Likewise, locations should also be in a database so the same types of data reports can be returned for locations within the business.
Because each business is uniquely different, you should look for a system that can allow you to enter the locations and people within the incident reporting system. If the system requires you to return to the vendor each time for this information, it will become restrictive and most likely costly over time.