The author has purchased, implemented, designed and built Safety Management Systems (SMS) and Process Safety Management Systems (PSMS) for over 30 years as part of his field and corporate HES/PSM responsibilities. Additional experience with the implementation of SAP and EPA systems also brings an understanding of systems.
As a result of this experience, the author has revealed many important SMS/PSM system features and issues. This paper provides an overview of the technology available to develop a SMS/PSM system utilizing the latest "bleeding edge" technology.
Building an incident reporting system in the late 1970s with Fortran and using punch cards produced results that actually worked well because the program was fairly simple and not yet loaded with copious amounts of code. As programming languages got more complex, the features increased, but so did the complexity. This complexity made systems limited and fragile.
It seems that the components of any SMS/PSM system exist to have "features" added, or as it is sometimes called "feature creep." Features are great until they start to provide so much complexity that the system crashes or is hard to use.
Simple and complex systems exist today but all fall into one of three general categories:
Off-The-Shelf – The prices of these systems range from low to high, but the universal issue is they typically cannot be modified to fit the organization's needs. In essence, the organization must adapt to the software.
Custom – Getting exactly what is needed is best when the program is custom, but the time and expense are high.
Hybrid – A hybrid system provides the best features of Off-the-Shelf and Custom. This approach provides sufficient content and design to reduce development time, but also allows for custom features that meet the specific needs of the organization. This is analogous to buying a house and getting to pick the cabinets, color, etc.
Newer systems have advanced code that allows custom or hybrid programming to be done much easier than in the past. This is especially true of applications that utilize the Internet. There are many systems available for specific modules in SMS/PSM but very few cover all the essential modules.
Larger organizations need an "enterprise" level system. This is a robust system with large data requirements, multiple users and centralized 24/7 access. An important feature is a common database where information can be stored and retrieved in real-time. It provides a centralized system with all SMS/PSM components within one system with full interactivity.
The goal of this paper is to define what is needed for a SMS/PSM enterprise system.
First, the components needed for the SMS/PSM system must be identified. There is significant redundancy of requirements for regulatory and industry initiatives, and the focus should be to determine the SMS/PSM components from each of them.
The database is the key component for managing information and many exist from simple ones such as Microsoft Access or FileMaker to advanced ones like SQL Server or Oracle.
