Eight Steps to Selecting Health & Safety Software
Rather than looking for a system with a lot of standard reports, I recommend a system that enables you to build your own reports.
HUNDREDS of H&S software applications are available; choosing the one that can best address your needs can be a difficult process. During the past 17 years, I have seen a variety of procedures used to select software. While some have worked brilliantly, others resulted in exorbitant costs and requirements never being met. The purpose of the article is to guide you through the selection process; i.e., to select the one that meets your budget and requirements.
I have distilled the process down into the following eight crucial steps:
1. Define needs and justification.
2. Establish and prioritize requirements.
3. Establish budget and acquire approval.
4. Determine potential solutions.
5. Develop RFI.
6. Select a short list.
7. Conduct vendor demonstration and selection.
8. Purchase.
Define Needs and Justification
Simply stated: "Why are you considering new H&S software?" Is it to move away from a paper system to a database? Is the technology of your existing system obsolete? Maybe your organization or processes have changed and cannot be supported by your existing system. Whatever the case may be, you should document it. When going through this process, keep in mind the cost/benefits of the new system--this will help you gain budget approval.
Example: ACME, Inc. has a need for automating its incident management process. Our paper file system requires significant resources to manage, retrieve and report incident records and statistics. Additionally, currently we can't easily share incident data and lessons learned throughout our company. The new system would greatly reduce the resources needed to track and manage incident data and report statistics to Corporate.
Deliverable: Project scope and justification documented.
Establish and Prioritize Requirements
Now that you have defined your high-level needs, you must get into the details. The most successful software projects begin with a clear list of prioritized items, or requirements.
A team of key H&S professionals and key stakeholders should be formed to define your requirements. I recommend from three to 10 people for the team. A small team helps solicit ideas, but a very large team causes difficulty in establishing consensus on the requirements. Requirements can be broken down into three key categories: functional, technical, and reporting.
Functional Requirements
There are many methods for defining functional requirements. The simplest and most effective method utilizes process flow diagrams and a list of requirements. Process flow diagrams are simple to construct, and you can use your standard desktop software to get the job done. Remember to work from the start (always on the left) to the end (always on the right). You simply define each of the steps and interactions between the entities to complete the task at hand.
Once the process flow models are completed for each key function within the scope of the project, detailed requirements can be defined. List the key requirements for each key process identified in your process flow model. I recommend using a spreadsheet to track requirements and enable the sorting and prioritizing. The following rating system has proven to be very effective for setting priorities:
1. Must have
2. Strong want
3. Want
4. Nice to have
Technical Requirements
Do not underestimate the importance of this step! Many software purchases have been based on the "nice look and feel" but failed miserably because of the system's weak technology. I recommend working with your IT group to define your technical requirements. Some items to consider are:
1. Do you need an Enterprise (company-wide) system, or is a PC-Based system sufficient?
2. Are you restricted to use an Oracle, SQL Server or AS400 database?
3. Does the software need to be multilingual?
4. Are Web applications required or desired?
5. If Web applications are required, must they be 100 percent browser-based (i.e., not require anything to be loaded on the PC)?
Reporting Requirements
Do not overestimate the importance of reporting. You and only you know what reports you need out of an application. Rather than looking for a system with a lot of standard reports, I recommend a system that enables you to build your own reports. Your reporting needs consistently will change; you need a system that will change with you.
The only standard reports that should be mandatory are regulatory reports (e.g., OSHA 300, 300a). Document a list of the regulatory reports your business requires.
This article originally appeared in the January 2004 issue of Occupational Health & Safety.