Adoption before automation: Why automating a poorly designed process only speeds up the problem

HSE process automation is one of the main opportunities linked to digitalisation. Technology can send notifications automatically, assign tasks based on rules, analyse documents and extract data. It can also trigger alerts from deadlines and exchange information between different systems without manual intervention. As artificial intelligence evolves, this capability grows even further. In addition, it opens new ways to reduce administrative work and handle large volumes of information. Teams can then focus on situations that genuinely require analysis.

But the ability to automate is not the same as the ability to improve. Consider a process with redundant steps, unclear responsibilities, unnecessary information or rules that are hard to interpret. Automation does not remove those problems. It may simply run them faster and at a larger scale. An overly complex workflow is still complex once automated. Likewise, a form full of information that nobody uses keeps collecting data with no value. Finally, an ambiguous rule keeps producing decisions that are hard to justify.

Transformation should therefore start before automation. First, it is necessary to understand the process, question what remains necessary and make sure there is a clear operational logic. Only then does it make sense to decide which parts to automate. Automating a good process can multiply efficiency. Automating a poorly designed process can multiply complexity.

Before automating, decide what should continue to exist

Many HSE processes are the result of years of incremental change. An audit added a check and a client requirement created a new field. Then an incident introduced another approval, and an operational exception led to yet another rule. Individually, each decision may have had a valid reason. The problem arises when they all stay in the process and nobody reviews the whole to ask whether they still add value.

That is precisely when technology can create an opportunity for review. For example, before automating four approval levels, you need to understand which decision each level supports. Before configuring fifty fields, find out who uses that information, for what purpose and what would happen without it. Similarly, before turning a historical exception into an automatic rule, the organisation should check whether an operational need still justifies it. This analysis does not aim to reduce control, but to separate necessary control from accumulated complexity.

In HSE process automation, this distinction is particularly important. Simplification cannot mean removing the checks that meet requirements, control risk or preserve traceability. The aim is to remove whatever improves none of these dimensions. A critical check must stay. However, the organisation can question duplicated information, an approval with no decision behind it or a field nobody uses. The better this analysis before configuration, the more likely automation is to deliver real efficiency rather than simply speed up the old process.

The most robust sequence is therefore clear: understand, simplify, structure and only then automate. When the organisation starts directly with the question “What can we automate?”, it risks turning technology into a fix for problems that belonged in the process design.

Automation requires turning informal knowledge into clear rules

Manual processes can survive for a long time with incomplete rules. People fill the gaps with experience, interpretation and informal knowledge. A professional knows that a certain exception requires different handling. They also recognise when information is contradictory, or realise that they should refer a case to someone else before continuing.

When the decision moves into an automatic workflow, much of that knowledge has to become explicit. The platform needs to know which conditions produce a given result and when a case can move forward. It also needs to know when to stop and when to call for human intervention. This need is particularly clear in document management. There, a requirement may depend on the link between company, worker, role, project, activity, risk, expiry date and type of evidence.

HSE process automation requires clear answers

Automating correctly therefore requires clear answers to several questions. Who does the rule apply to? Which evidence does the organisation accept? What is the relevant deadline, and who is responsible? And what happens when the information does not support a conclusion? If these questions remain unresolved, the problem is not technological. HSE process automation simply exposes an ambiguity that already existed in the process.

This clarification has value beyond the technology itself. It forces the organisation to document criteria, harmonise interpretations and define responsibilities. In many cases, preparing to automate improves the process before any automation exists. That happens precisely because it takes important decisions out of informal knowledge and turns them into an understandable, governable model.

It also becomes easier to identify what technology should not decide automatically. A clear rule may let a case move forward without human intervention. In contrast, an incomplete document, a contradictory situation or a high-impact condition may need analysis. Good design does not try to automate every decision. Instead, it defines precisely where automation is safe and where human judgement still adds value.

Adoption should come before HSE process automation at scale

There is another risk in automating too early: building a sophisticated architecture on a process that users have not yet embraced. Technology can send alerts, create tasks and change statuses automatically. However, if part of the organisation keeps working through email, Excel or parallel procedures, automation will act on only part of the reality.

Consider a document process in which the platform automatically flags missing documents. However, some service providers keep sending them by email. The system may produce a technically correct alert. Meanwhile, information that has not yet entered the process already exists outside it. Or imagine action management in which some owners update the platform while others keep their own lists. Automatic escalations may work perfectly and, even so, the dashboard still shows only part of the operational situation.

Ensure adoption before automating further

Before increasing automation, the organisation should make sure the digital process is clear and practical enough for consistent use. This does not mean waiting for perfect adoption, which will hardly ever exist. Rather, it means reaching enough maturity for data, workflows and responsibilities to reasonably reflect what happens in operations.

Users’ own reactions can help show whether the organisation is ready. Look for shortcuts, tasks outside the system, recurring questions or manual fixes to automatic results. If they are frequent, the process may still need stabilising. Automating more at that stage can make diagnosis harder. It becomes less clear whether a problem stems from configuration, usage or the business rule itself.

A more sustainable sequence therefore involves simplifying, testing, adopting, automating, measuring and improving. HSE process automation then emerges as the evolution of a process that has already proven it works, not as a way to force an immature process to work.

Artificial intelligence increases capability, but it also requires clear limits

In addition, artificial intelligence adds a new dimension to this discussion. The platform may no longer just run predefined rules. It may also extract information, identify patterns, classify content or support decisions. This makes it possible to significantly reduce repetitive tasks, especially in processes that involve large volumes of documents or data.

But AI does not remove the need to distinguish automation from decision-making. Extracting an expiry date from a document is different from concluding that the worker is fit for an activity. Identifying an entity on a certificate is different from automatically determining the compliance of the whole process. Flagging a possible anomaly is not the same as deciding that a non-conformity exists.

The greater the operational impact of the conclusion, the more important the boundaries become. Teams must define what technology can resolve automatically and what requires validation. In some cases, the most robust model is not full automation but assisted automation. Technology collects and structures information, performs objective checks and identifies discrepancies. It then sends whatever remains ambiguous for human review.

This approach captures much of the efficiency without turning uncertainty into an automatic decision. It also improves traceability, because the organisation can distinguish what a rule decided, what the technology identified and what required professional judgement.

Maturity, therefore, does not lie in removing as many people as possible from the process. Instead, it lies in placing technology and human intervention exactly where each one creates the most value.

Mature automation requires governance and the ability to review

As an organisation advances in HSE process automation, governance also becomes more important. A small change to a rule can automatically alter the status of hundreds of records, create new tasks or shift priorities. An incorrect configuration no longer affects only the person running the process. It can quickly spread across the whole operation.

Teams need to know who defines the rules, who can change them, who tests them and how they assess their impact. Relevant changes should keep enough context to show what changed, why and with what expected effect. The aim is not to create bureaucracy, but to ensure that the speed technology provides still comes with control.

There should also be a way to detect when an automation no longer works as well as expected. For example, more exceptions, users who keep bypassing a rule or constant manual corrections may signal a need to review the process. Automation is not a permanent decision made once. It is also a cycle of observation and improvement.

Measuring the value of HSE process automation

This perspective changes the strategic question. Instead of measuring maturity by the number of automated tasks, assess the outcomes. Has automation reduced effort, improved consistency and raised data quality? Has it strengthened control without stripping critical decisions of their context?

The question then stops being “How much can we automate?” and becomes “Where does automation create value without compromising quality, interpretation and control?”

It is this second question that should guide the evolution of an HSE platform.

Because the goal of HSE process automation is not to make human work disappear. It is to remove effort where it adds no value and to speed up objective decisions. As a result, people can focus on situations where knowledge, context and judgement remain essential.

The best automation is not the one that removes the most tasks. It is the one that makes the process simpler, more consistent and more controllable, without automating what people still need to understand.

To go further: HSE platform and HSE digitalisation: The complete guide.

See also: Digitising an old process does not mean transforming it and An underused platform can create a false sense of control.

Similarly, EU-OSHA publishes resources on the impact of digitalisation and automation on occupational safety and health.

We don’t just implement platforms. We make sure they work.

Talk to the AISP team about implementation, administration and ongoing support for your operation after go-live, in any country, from administration centres in Portugal.