There is a lot of process safety management (PSM) software out there, and more software packages are coming every day. The problem is that nothing out there effectively meets all of an operating companies requirements, and in fact, a lot of the software, if not most, is really bad. There are a wide variety of reasons why this is the case, but ultimately they all boil down to the fact that the software developers are narrowly focused on their own areas of expertise, and/or their own needs.
The software vendors fall into two broad camps – the software houses and the consultants. The software houses usually have the best software from a usability standpoint. They typically have professional software developers who are very experience in developing software that is easy to use, appealing from a visual perspective, and packed with sophisticated features for data handling. The problem with many of these packages is that while the software houses intuitively understand good software design, they do not have sufficient expertise in the problems that they are trying to solve, and as a result enforce work practices in their software that do not match the work processes of the engineers and designers that are required to implement process safety management. These software packages only work because the end users are able to customize the packages to meet their needs, but this customization is time consuming, expensive, and hinders communication and sharing across the organization.
The consultants are exactly the opposite. Their software is based on their expertise in a specific design niche, and thus performs that specific task very well. The problem is that the software itself, is usually difficult to use, poorly supported, non-intuitive, and limited in its features. Even the best of these software packages is still an island of data that can not be used in other situations where the data files that were created “on the island” would be useful.
As a result, operating companies are using a multitude of software specialty packages that do not communicate, don’t allow information sharing, and are generally expensive and inefficient. Each operating company (and often each individual plant within an operating company), will have packages for process hazards analysis, safety instrumented system design, relief system design, incident management, and so on. Trying to keep a plant up to date with all of these disparate packages is difficult.
The Holy Grail in software would be for all of these “apps” to be combined into a unified platform that would allow seamless integration, sharing, and coordination – consistently, across the enterprise. When a management of change activity is opened – a review team can be called together to analyze the situation – tracking the status of the MOC, performing the MOC’s process hazards analysis, during the analysis checking and updating the designs of engineered safeguards such as SIS, fire and gas systems, and relief valves that are impacted by the change. All done seamlessly, in one software package that is consistent and usable throughout the organization, and providing overview dashboards that are actionable by all levels of staff and management.
Hmmmm. Someone should really do something about this…