In safety management, there are no absolute “right ways” to do things, and any guru who tells you otherwise has never worked in your organization, right? Certainly, regulatory guidelines, best practices and industry norms can direct an organization through its unique safety journey, but these only go so far.
An organization with a true Safety Management System (SMS) demonstrates that managing risk and assuring a safe working environment are institutionalized into the corporate culture. This requires that the organization evolve beyond just “going through the motions” of assuring basic regulatory compliance to a more robust system of identifying, tracking, interpreting, analyzing and using data to make decisions about risk mitigation and safety improvements.
Typically, one of the important milestones on this pathway is to transition from a paper — or spreadsheet — version of safety-related data and information record-keeping and reporting to a more robust, often off-the-shelf, software product. Unfortunately, the term safety management system has become, at some organizations, synonymous with the off-the-shelf safety software itself. I encourage organizations to be more precise about the differences between a safety management system and a safety software product, the respective nomenclature of each and to be intentional in how safety software products can be used to support such a safety management system. To be sure, the use of a software product by an organization does not in and of itself create a safety management system. No software product can achieve that on its own.
Organizations may struggle in identifying which product to invest in because of the confusion between software and a safety management system. Organizations should consider how they think about purchasing a software product to support the implementation of their safety management system. In order to differentiate this from the software supporting this effort, I will use a new term for the balance of this article to refer to the software: Safety Data and Information Management Software (for those keeping track, that’s SDIMS).
Selecting a SDIMS to support your safety management system is a big decision, likely to affect the organization for many years to come. Switching a SDIMS in the future will not be convenient or inexpensive, so there is a tendency to stick with the original decision, even as the organization and its SMS evolve — a fact well-understood by the vendors themselves. Hence, a thorough acknowledgement of the desired features, both in the present and for anticipated future needs of the organization, becomes an essential prerequisite to selecting the appropriate vendor.
Here are three questions to ask before selecting a SDIMS:
1. Do I need a data repository only or an information-providing product?
2. Does my SDIMS need to include other modules as well (training, inspections, etc.)?
3. Is our safety management system ready to start receiving output from the SDIMS?
Do I need a data repository only, or an information-providing product?
The first question a potential buyer should ask is whether they need a data repository, from which to download reports for analysis, or an information-providing product. So, what’s the difference? It is as fundamental as the terms “data” and “information” themselves.
The term “data” is derived from the Latin noun for “something given.” Use of the term indicates that there is objectivity and a lack of controversy as to the nature of the fact. The term “information” on the other hand derives not from a noun but from the Latin verb “informare,” meaning “to shape mentally” or “to form an idea or conception of.” There is action implied in the word, unlike the passive term “data,” which merely exists, while information actively lives by shaping ideas and impacting real-world decisions. This goes a step beyond the data repository because it provides extra intelligence regarding the data. This is best for organizations with large amounts of data that is difficult to analyze oneself.
Back to SDIMS - some organizations may only need a reliable repository of data, from which they will download for internal analysis from time-to-time. Other organizations might expect a SDIMS to provide automated and actionable information. This, in my opinion, is why the first decision an organization needs to make when considering a potential purchase of an SDIMS is to understand whether it needs data or information out of its SDIMS. Too often, a “Cadillac” model is installed but is only actually used to record injuries and incidents, but none of the analytical modules are utilized yet are being paid for anyway. Worse yet, online training modules, chemical management systems and other add-ons are included but not used. In these cases, the safety program costs are unwittingly undermining the financial health of the organization.
Does my SDIMS need to include other modules as well (training, inspections, etc.)?
While it may be tempting to reduce the number of vendors and systems, avoid purchasing additional modules that your SDIMS may offer unless there is a real business need or opportunity. For example, if a reporting tool that also happens to offer a Learning Management System (LMS)…but you already have an LMS…feel free to pass on the opportunity. Simplicity does not necessarily mean having one vendor or product for everything.
Is our safety management system ready to start receiving output from the SDIMS?
It is important to be prepared to use the data (i.e., to convert it into useful information) when a system element is introduced. For example, an employee safety reporting system needs to result in some kind of response from the organization – not just of the safety concern but also the direct feedback loop to the originator of the concern. A safety management system should view an increase in the number of safety reports as a positive indicator of the safety culture of that organization. A less mature safety culture might see the increase of safety concerns as an unwelcome intrusion on its normal operations. Other potential outputs such as upcoming compliance requirements, training needs or risk level reports need to be received and actioned by actual individuals within the organization. Otherwise, the investment of money and time in acquiring and building the SDIMS is wasted.
The decision to purchase SDIMS is a consequential one but it pales in comparison to the commitment and effort required to implement the overall SMS, of which the software is but one element. Keep this in perspective and avoid the temptation to use the selection of a SDIMS as a substitute for the more difficult – but also more rewarding – effort in developing and evolving your SMS.
Patrick Moylan is a Certified Safety Professional and Senior Associate at FBO Partners, LLC, an aviation consultancy providing business management advisory services to Fixed Base Operations (FBOs). Moylan may be reached at [email protected] .
