Implementing an HSE or document management platform is a project that is relatively easy to define. There are requirements, configuration, data migration, testing, training, a go-live date and a set of deliverables that make it possible to assess whether the project went as planned. Adoption is different. It does not happen on a specific date, nor can you confirm it simply because users have received credentials or attended a training session. In fact, adopting an HSE platform only happens when it becomes part of the organisation’s normal way of working.
This distinction is particularly important because an implementation can be technically successful and still produce operational results far below expectations. The system is available, the workflows work, users can log in and the team has already loaded the initial data. Even so, a few months later, Excel sheets still track processes, documents circulate by email, certain users avoid features, people prepare reports by hand and some teams use only a small part of the solution.
When this happens, the organisation has the technology, but it has not yet truly transformed the process.
In reality, the challenge is not just making a platform available. It lies in creating the conditions for people, processes and information to genuinely work through it. For HSE professionals, this difference is especially relevant, because an underused platform is not just an underexploited investment. It can also mean lower data quality, less visibility over operations and critical processes that remain spread across different tools.
Adopting an HSE platform starts before go-live
One of the most common mistakes is to treat adoption as an activity that starts with training. First the team configures the solution, then it presents the features to users and expects that, from go-live onwards, everyone will naturally start working in a new way.
In practice, adopting an HSE platform starts with the design of the process itself.
If an operational team only gets involved once the configuration is already complete, it may discover too late that certain steps do not reflect how the work is really done. A form may require information that is not available when someone fills it in. In addition, a workflow may create approvals that work in theory but do not match actual responsibilities. A process designed on a computer may prove too complex when someone carries it out on a mobile device, on a site or in an industrial facility.
That is why the implementation should involve different perspectives from the outset. HSE knows the requirements and control objectives. Operations knows the real conditions in which the process takes place. IT knows the security, integration and architecture requirements. End users know the details that only become clear when someone repeats a task every day.
However, none of these perspectives should dominate the implementation on its own.
A good platform needs to reflect the organisation’s requirements, but it also needs to allow people to do their work simply and consistently.
This is where adoption begins: not when someone learns where to click, but when the team designs the digital process to work in the real context of operations.
Digitising the old process can preserve the old problems
Another risk arises when the implementation only serves to reproduce digitally what already existed.
For example, an Excel sheet becomes a form. A chain of emails turns into a workflow. The team replicates existing approvals one by one. Legacy fields move across because they have always been part of the process.
Technically, there is digitisation.
But there may be no real transformation.
Many business processes have grown over the years. Each audit, incident, client requirement or internal need may have added a new step, a new field or a new approval. Individually, each change probably had a reason. The cumulative result, however, can be a process far more complex than the one anyone would design if they were starting today.
A new platform offers precisely the opportunity to carry out that review.
Before configuring an approval, it is worth asking what decision someone takes at that point and what risk would arise if it did not exist. Likewise, before migrating a field, it is important to understand who uses that information and for what purpose. Before creating an exception, you need to distinguish a real need from a historical practice.
For an HSE function, simplifying does not mean reducing control. On the contrary, it means eliminating tasks that add no safety, compliance, traceability or operational value.
This distinction matters because users quickly recognise when technology simply presents them with the same old process on a new screen.
When the new solution requires more steps, more fields or more time than the previous method, shortcuts become more likely. And when people start using those shortcuts systematically, adoption weakens.
Adopting an HSE platform: Real-world use must be simpler
People tend to use whichever tool lets them meet a need with the least effort. That is why Excel and email remain present even in organisations with robust enterprise platforms. They are familiar, flexible and immediate tools.
A corporate platform cannot replace these behaviours through an internal instruction alone.
Therefore, it has to offer an alternative that is sufficiently clear and useful.
If an HSE manager needs to know which actions are overdue and can get that information directly from a dashboard, there is little incentive to create an Excel sheet. If they need to export different tables, cross-check the data manually and prepare the information before they can answer, Excel naturally reappears.
The same also happens in document management. If a contractor can immediately see which documents are missing, which ones the team has rejected and what needs correcting, the process tends to work within the platform. If they cannot interpret the statuses or work out the next step, they will look for help or send the documentation through another channel.
The operational experience, therefore, has a profound influence on adoption.
This is not about making every process extremely simple. Some HSE processes are necessarily complex. The aim is to ensure that this complexity stems from what needs to be controlled, and not from the way someone configured the platform.
A platform should remove friction from the process, not digitise the friction that already existed.
Training should prepare people for the job, not for a demonstration
Training is another decisive factor in adoption. A platform-centred approach tends to present menus, modules, features and different configuration options. This information may be useful for administrators, but it is too much for many users and, at the same time, not enough for those who need to understand the logic of the process.
A worker who logs an incident, a supervisor who follows up actions, an HSE technician, a document controller and a functional administrator do not need the same training.
Each profile should above all understand what they need to do.
More importantly still, they should understand what happens after their action. When someone records a non-conformity, what process starts? If the team rejects a document, what needs to happen? When an action goes past its deadline, who receives the information?
This understanding matters because it reduces mechanical use of the platform.
Users no longer just memorise a sequence of clicks; instead, they start to understand the process.
It is also necessary to recognise that training is not a one-off event. Organisations change, new employees join, new features appear and some processes only see occasional use. As a result, without follow-up, knowledge naturally fades.
An adoption strategy therefore needs to combine initial training, simple materials, user support and the ability to identify recurring questions.
When dozens of people repeatedly ask the same question, we should not automatically conclude that they need more training. There may be a configuration that deserves a review.
Adopting an HSE platform: Go-live starts an observation phase
Go-live is an important milestone, but only at that point does real information about how people use the platform begin to emerge.
The first few weeks reveal where difficulties arise, which workflows see the most use, which processes remain outside the system and which questions come up most often. It is worth treating this information as part of the implementation, not merely as post-project support.
An organisation can look out for a few very simple signs: do certain locations use the platform much less than others? Are there processes that still run by email? Do some users abandon tasks before completing them? Do Excel sheets keep appearing to control information that already exists in the system?
Each of these signs is an opportunity for analysis.
The answer may lie in training, configuration, usability, the permissions model or even the design of the process itself.
This is also the phase in which the platform should start to evolve based on real data. For example, a field that seemed important may turn out to be unnecessary. An approval may be causing delays without adding control. An additional view may eliminate a manual report.
The aim is not to change the system continuously. It is to use real experience to improve what is not yet working as well as it could.
We can think of adoption as a cycle:
Implement → use → observe → learn → improve
The faster the organisation can complete this cycle, the sooner the platform stops being “the new system” and simply becomes part of operations.
Success in adopting an HSE platform shows in the processes that changed
Measuring the execution of an implementation is relatively easy. We can know how many users there are, how many training sessions took place, which modules the team configured or whether go-live happened on schedule.
These indicators are important for managing the project.
But they say little about transformation.
The real assessment begins afterwards.
How many processes have actually stopped depending on Excel? Which documents no longer circulate by email? How much manual work has disappeared? Can users obtain information without constantly depending on others? Is the data more complete and up to date? Does action tracking take place within the platform? Do managers use the dashboards to manage?
After all, it is these changes that demonstrate adoption.
A platform does not create value simply because it is available. It creates value when it positively changes the way the organisation works.
Adoption is a shared responsibility
That is also why it is unwise to see adoption exclusively as the users’ responsibility. It is a responsibility shared by those who design processes, configure the platform, deliver training, provide support, manage change and lead the organisation.When a solution is difficult to use, it is not enough to ask people to use it more. You need to understand why.
When an area keeps running parallel processes, it is not enough to ban those processes. You need to understand what they are solving.
And when a feature is hardly used, we should not automatically assume that users are unaware of its value. Perhaps the process is not sufficiently aligned with what they need to do.
It is this ability to continuously question the relationship between technology and operations that distinguishes implementation from adoption.
Implementing means making a platform available. Adopting an HSE platform means making that platform part of the organisation’s natural way of working.
And, for an HSE organisation, it is this second stage that determines whether the technology investment really translates into greater control, better data and more efficient operations.
Further reading: HSE platform and HSE digitalisation: The complete guide.
Read also: How to measure whether an HSE platform is really being adopted and Why users go back to Excel after implementing an HSE platform.
For more information on occupational safety and health, visit the European Agency for Safety and Health at Work (EU-OSHA).