After You Buy: 4 Ways Health and Safety Software Implementations Fail
There is a great deal of advice about choosing health and safety software. Feature comparisons, buyer's guides, vendor shortlists.
There is almost none about the part that actually determines whether it works, which is the twelve months after the contract is signed.
Most organisations that are disappointed with their safety software did not buy the wrong product. They bought a reasonable product and implemented it in a way that guaranteed it would become an expensive document store. The failures are consistent, and all four are avoidable.
1. Buying before deciding what you are managing
The failure that happens before implementation starts.
Software organises a process. If the process does not exist, the software will not create one, and configuring a system around an absence produces a system nobody can use.
The symptom is recognisable: a procurement exercise that compares features in detail and never establishes what the organisation is actually trying to hold. How many entities. How many buildings. Which assessments exist and which do not. Who is appointed where. What actually needs to be tracked, and by whom.
Regulation 5 of the Management of Health and Safety at Work Regulations 1999 requires arrangements for the effective planning, organisation, control, monitoring and review of preventive and protective measures. The software is a tool for the monitoring and review part. The arrangements come first.
What prevents it: a short scoping exercise before selection that establishes what exists, what is missing, and what genuinely needs tracking. That usually shortens the requirements list rather than lengthening it.
2. Loading documents instead of building a register
The most common implementation, and the one that produces the least value.
Organisations migrate what they have: PDFs of assessments, scanned certificates, policy documents, a folder per site. The system becomes searchable storage. Everything is in one place, and nothing is being managed.
The difference matters. A document library answers "where is the assessment for the Manchester office?" A register answers questions the business actually has: which sites have no current fire risk assessment, how many actions are open and how old the oldest is, which training expires in the next ninety days, which entity has nobody appointed.
Those are different data structures. The first is files. The second is records with dates, owners and statuses attached, which means somebody has to extract that information from the documents during implementation rather than uploading them whole.
What prevents it: deciding at the outset which fields must be structured, and accepting that migration is an extraction exercise rather than a file transfer.
3. Nobody owns it after go-live
Need Expert H&S Guidance?
Our qualified consultants can help you implement the right health & safety measures for your business.
The organisational failure, and the most predictable.
Implementation has a project manager, a timeline and attention. Then the project closes, the consultant leaves, and the system passes to whoever has capacity, usually somebody for whom it is the fourth priority.
Three things stop working within months. Actions are raised and never chased, because chasing is a person's job rather than a system's. New sites, new starters and new equipment are not added, so the register drifts from reality. And the reports nobody reads stop being produced, which removes the only signal that anything is wrong.
Regulation 7 requires the appointment of competent persons to assist in complying with statutory duties. A system is not a competent person, and giving somebody a login is not an appointment.
What prevents it: naming the owner before go-live, giving them time in their objectives, and agreeing what they produce and to whom. A monthly report with open actions by age, sent to somebody accountable, does more for adoption than any amount of training.
4. Expecting the system to supply the judgement
The conceptual failure, and the most expensive.
Software is very good at holding records, prompting on dates, routing actions and showing a position across sites. It is not able to decide whether a risk assessment is suitable and sufficient, whether a control is reasonably practicable, whether an incident was reportable, or whether an entity in another country is meeting its own national requirements.
Those are judgements, and regulation 3 requires the assessment to be suitable and sufficient, which is a question of competence rather than of completeness. A form that has been filled in completely can still be wrong.
The symptom is an organisation with a high compliance percentage on a dashboard and assessments that describe a building it left two years ago. The system is reporting that the fields are populated, which is what it was asked to report.
What prevents it: treating the software as the place the work is recorded and reviewed, and keeping competent judgement in the loop for the decisions the system cannot make. That is why health and safety consultants and software are worth more together than either alone, and it is not a marketing line: the system holds the position, and somebody competent has to decide whether the position is acceptable.
The four, in short
| Failure | Symptom | What prevents it |
|---|---|---|
| Buying before scoping | Feature comparison with no baseline | Scope what exists and what is missing first |
| Documents, not a register | Searchable storage, nothing managed | Decide which fields must be structured |
| No owner after go-live | Actions unchased, register drifting | Named owner, time allocated, a monthly report |
| Expecting judgement | Green dashboard, stale assessments | Competent review of what the system holds |
Rows three and four together account for most disappointment. One is about attention, the other about competence, and no product solves either.
What a working implementation looks like at ninety days
Five practical tests, and they take an afternoon to run.
Can you answer a question you could not answer before? For example, which of your sites has no current fire risk assessment. If not, you have storage.
Is the oldest open action getting older? A register where the oldest action keeps ageing has no owner.
Has anything been added since go-live? New starters, new equipment, a new site. If not, it is already drifting.
Does anybody outside the safety function look at it? A system read only by its administrator is not informing anybody.
Has a report gone to somebody accountable? If not, the monitoring and review duty is being recorded rather than discharged.
HSE's framework for managing health and safety describes the plan, do, check, act cycle the system is meant to support.
For international groups
Two considerations, and this is where implementations most often go wrong at scale.
A single configuration assumes a single legal framework. This series has documented how sharply requirements differ: appointments attaching from the first employee in Belgium, Bulgaria, Slovakia and Greece; risk assessments reserved to qualified specialists in Hungary and Greece; named statutory documents in Slovenia and North Macedonia; filings due on fixed dates in Bulgaria and Estonia; audits filed with regulators in Kenya.
A system configured around British requirements will show an overseas entity as compliant while it is missing an obligation the system was never told to look for.
Retention rules differ too. Regulation 12 of RIDDOR requires records to be kept for at least three years, and health records elsewhere are kept far longer. A system that was not configured for the longest applicable period will delete something that mattered.
What prevents it: configuring by entity rather than globally, with each entity's obligations established locally. Periodic health and safety audits are how a group finds out whether the dashboard reflects reality.
Where Arinite fits
Arinite works on both halves: the arrangements the software is meant to hold, and the judgement the software cannot supply. We support 1,500+ businesses across 50+ countries and protect 100,000+ employees, with 95%+ client retention over 15+ years.
Our health and safety consultants work extensively with finance and banking, insurance and IT and software organisations, many of which run mature systems in every other domain and have found safety harder to systematise.
Where entities sit in several countries, our global health and safety consultants establish what each one must actually hold, and our international health and safety consultants keep that current as requirements change.
If your system shows a high compliance figure and you are not confident it is true, a free gap analysis will tell you what the dashboard is not measuring.
Related Articles
Written by
Arinite Health & Safety Consultants
Health & Safety Expert at Arinite
