Implementing QHSE software: a step-by-step plan from Excel to a working system

Implementing QHSE software in ten steps

An implementation succeeds mainly through sequence and ownership, less through the software itself. Adapt the scale to your organisation: a company with twenty employees and one location needs less time than a group with several sites. The steps are worked out in the following sections:

• Define the goal and scope
• Appoint an owner and a project team
• Start small with one or two modules
• Set up roles, locations and templates
• Transfer existing data and documents
• Run a pilot with one team
• Train the office and the shop floor
• Communicate what changes and roll out
• Measure usage and adjust
• Expand to the next modules

Steps 1 and 2: goal, baseline, scope and owner

Start with the question of which problem you are solving: reports that are followed up too slowly, actions that get lost, or days spent looking for evidence for an audit. Choose two or three goals and measure beforehand how things stand now, for example the hours per audit spent on evidence and the number of actions that are late. That is your baseline. Also record which locations, departments and modules fall within the first phase.

Then appoint one owner with time and authority, usually the quality, safety or QHSE coordinator. Without an owner a system runs empty: nobody manages the templates, permissions fall behind and reports receive no feedback. Record who decides when a choice has to be made. Divide the roles like this:

• Owner: steers the implementation, manages templates and permissions and safeguards the measurement
• Sponsor from management: makes decisions, sets the example and frees up time
• Key users per department: help colleagues, give feedback and test along in the pilot
• Administrator or IT: arranges sign-in, integrations and any security questions
• Supplier: helps with set-up, supports the data transfer and trains the administrators
• Employees: report, carry out tasks and indicate what does not work

Steps 3 to 5: start small, set up and transfer data

Choose as a start the module where the most pain is, for example reports and actions, or documents. One or two modules are enough to let the team get used to the new way of working. Preferably choose modules that visibly save work straight away, because that gives the team a reason to use the system. Build further when that works, not before.

When setting up you define roles and permissions, create locations and departments, work out templates and forms and decide who receives which report. Do not rebuild your Excel system one-to-one. Use the switch to simplify the way of working and drop fields that nobody fills in.

Transfer what is still current: open actions, valid documents and ongoing registers. History that nobody uses you archive outside the system. After an import, check a sample, and agree a date on which the old Excel list becomes read-only. That prevents two systems from continuing side by side.

Steps 6 and 7: pilot and training of office and shop floor

Run the pilot with one team or one location and real reports, in this example for four to six weeks. The aim is to find out where it chafes: unclear fields, too many clicks, a report that reaches the wrong person. Evaluate briefly every week and adjust the set-up before you roll out further.

Train the office and the shop floor differently. Administrators and key users learn to set up, report and follow up. The shop floor needs only a short, practical instruction: how do I report something, how do I complete a task, where do I find the current procedure. Do this on site on the phone they actually use, for example during a toolbox meeting.

Agree in advance when the pilot has succeeded, for example when the team puts all new reports into the system, every action has an owner and deadline and nobody reaches for the old list any more. Then you know at a fixed moment whether you can roll out or must adjust first.

Support and communication: what changes for employees?

Explain why you are introducing the system, what changes and what stays the same. Employees want to know what they have to do differently, how much time it takes and what it gives them. Be concrete: from now on you report in the system and no longer by email or on paper, and the old list is read-only from an agreed date.

Support comes from involvement and from results. Let a few shop-floor employees test along, let managers work with the system themselves and make sure a report visibly leads to an action and feedback. If reporters hear nothing, they stop reporting. Also keep track of which questions and complaints come in and adjust the set-up accordingly.

Resistance is normal. People fear extra administration, monitoring, or that their reports will be used against them. Name those concerns openly, explain who can see what and show that the system is meant to solve problems and not to hold people to account.

Indicative timeline for introducing a QHSE platform (illustrative)

This timeline is illustrative. The actual duration depends on the size of your organisation, the number of modules and your owner's time. A short timeline is not a goal in itself: a pilot that lasts a week longer is better than a roll-out to a team that does not yet trust the system. For a small or medium-sized company with one or two modules the sequence could look like this:

• Weeks 1 and 2: define goal, scope and owner and confirm the supplier
• Weeks 2 to 4: set up roles, locations, templates and reporting routes
• Weeks 4 and 5: transfer and check existing data and documents
• Weeks 5 to 9: pilot with one team or location, with a weekly evaluation
• Weeks 9 and 10: train the office and the shop floor and roll out to the rest
• Weeks 10 to 14: the first month after roll-out, measure usage and adjust
• Months 4 to 6: add the next module

Common mistakes when implementing QHSE software

An implementation can get stuck on the approach: ownership, sequence and involvement of the shop floor. These mistakes occur in practice, and most can be prevented with an owner, a small start and a fixed closing date for the old way of working:

• Wanting to introduce everything at once: all modules and all locations in one go
• No owner, or an owner without time and authority
• Forgetting the shop floor: training only the office, while reporting and inspecting happen on site
• Continuing to use the old Excel lists alongside the new system
• Rebuilding the Excel system one-to-one instead of simplifying the way of working
• Taking all history along, including what nobody uses any more
• Giving reporters no feedback, so that reports dry up
• Not choosing measuring points in advance, so you do not know whether it works

How do you assess the first month after roll-out?

Assess the first month on usage and follow-up, not on the number of configured functions. Compare the outcomes with the goals and the baseline from step 1. A good start does not mean everything works perfectly, but that people use the system and that problems become visible quickly. These are the points to look at:

• Usage: how many employees have reported, completed a task or read a document at least once
• Speed: how long does it take from report to first action
• Follow-up: how many actions have an owner and deadline, and how many are late
• Completeness: does new information go into the system, or still into Excel and email
• Time saved: how long does finding evidence or producing a report take, compared with your baseline
• Experience: what do employees find difficult, for example the number of clicks or unclear fields

Expanding to the next modules

Only expand when usage is stable and the first goals have been met. Choose the next module based on the next bottleneck, reuse the roles, locations and departments you have already set up, and repeat the approach on a small scale: a short pilot, training and a measurement after a month. That way the system grows with what your organisation actually uses.

An expansion again costs set-up time and your owner's attention. So plan no more than one new module at a time and record each time which one it will be, who sets it up and what goal it serves. Also re-evaluate the existing modules: are the agreements still current, do the reporting routes work and do roles or templates need adjusting?

How BrydgeOne supports this

BrydgeOne is modular, so you can start with one or two modules and expand later without switching systems. According to the website, implementation and set-up are included in the monthly price and you can start with a pilot for one department and a few modules. If you switch from another package, BrydgeOne takes your existing data along, and you import and export lists yourself.

For the shop floor there is an employee app that, according to the website, works without a login. In Incidents & reports employees report with photos, by dictating or by describing it themselves. Without coverage the report is sent as soon as there is a connection again, and people without an account report through a public reporting point with a link or QR code. Under My reports they follow the status.

In Roles & responsibilities you record who is responsible for what, with role holders, a deputy and a RACI matrix per process. With Document management you keep procedures current with an approval route and a read confirmation per person, and employees also confirm in the app if you share the document there. In Training you see who has been trained for what, and employees follow e-learning in the app or through a personal PC link, without a platform login.