Most leadership teams no longer ask whether to automate, but where to start. Robotic process automation, workflow platforms and AI models are now accessible to organizations of every size, and the pressure to show progress is real. Yet the decisive factor in whether these investments pay off is rarely the technology itself. It is the state of the process the technology is asked to run.
A process that is unclear, inconsistently executed or fed with unreliable data does not improve when it is automated. It simply fails faster, at greater scale and with less visibility. Preparing operations before automating them is therefore not a delay; it is the work that makes automation worth doing.
Automation amplifies the process it inherits
In a manual process, experienced staff quietly compensate for gaps. They know which supplier always sends incomplete invoices, which customer codes are duplicated, which approval can safely wait. That tacit knowledge is invisible in process documentation, and it disappears the moment a bot or model takes over. The result is a familiar pattern: an automation that works in testing, then generates a growing queue of exceptions in production, handled by the same teams it was meant to relieve.
The lesson is not to avoid automation, but to make the process explicit first: its steps, its decision rules, its exceptions and its owners.
Start with how work actually flows
Documented procedures describe how work should happen. Automation needs to know how it does happen. The preparation phase should therefore be grounded in observation and data, not only in workshops. Process mining tools can help where system logs are rich enough, but interviews and walk-throughs with the people who execute the work remain indispensable.
- Map the process end to end, from the triggering event to the final outcome, across departmental and system boundaries.
- Identify the variants and exceptions, and decide which ones should be eliminated, standardized or deliberately left to human judgment.
- Write down decision rules explicitly, including the thresholds and criteria that experienced staff apply informally.
- Name a business owner for the process, accountable for its performance and for any change to its rules once automated.
- Establish a baseline of current performance (volumes, lead times, error and rework rates) so that the effect of automation can be assessed honestly.
Data quality is an operational discipline
Rules-based automation breaks on bad data; AI models learn from it. In both cases, the quality of master data and transactional inputs determines the quality of outcomes. Data quality is often treated as an IT matter, but most defects originate in operations: free-text fields used inconsistently, reference data maintained by several teams, documents received in formats nobody controls.
Preparing for automation means assigning ownership for critical data, defining what “correct” looks like, and putting controls at the point of entry rather than relying on downstream correction. For AI use cases, it also means understanding where training and reference data come from, whether they reflect current practice, and whether their use is compatible with confidentiality and data protection obligations.
Choosing what to automate, and how
Not every process should be automated, and not every automatable process should use AI. Stable, high-volume, rules-based activities are usually better served by conventional workflow or rules engines, which are predictable and easy to audit. AI earns its place where inputs are unstructured or variable, such as classifying documents, extracting information or drafting a first response, and where a degree of uncertainty in the output can be managed. Prioritization should weigh business value, process maturity, data readiness, risk and the effort required to maintain the solution over time, not only the speed of initial delivery.
It is often worth simplifying a process before automating any part of it. Removing redundant approvals, consolidating duplicate data entry or clarifying a handover between teams can deliver much of the expected benefit on its own, and leaves a cleaner foundation for whatever is automated next. Where the process is still changing, a lighter, reversible solution is usually preferable to a heavily engineered one that will need rebuilding.
Keep humans in the loop by design
Responsible automation is designed with oversight built in, not added after an incident. That means defining which decisions a system may take alone, which require human validation, and how exceptions are routed to people with the authority and context to resolve them. It also means preserving an audit trail: what the system did, on which data, under which version of its rules or model. Internal control, information security and, where relevant, legal and compliance specialists should be involved before deployment, not asked to approve it afterwards.
An automation you cannot explain, monitor and switch off is not an operational asset; it is an unmanaged risk.
Questions to ask before funding automation
- Who owns this process today, and will they own the automated version?
- Do we know how the process actually runs, including its exceptions, or only how it is documented?
- Is the data this solution depends on owned, reliable and lawfully usable for this purpose?
- Which decisions remain with people, and how will they be alerted when the system is uncertain or wrong?
- How will we monitor performance, detect drift and maintain the solution once the project team has moved on?
- What is the fallback if the automation must be suspended?
Organizations that take the time to answer these questions tend to automate fewer things at first, but they automate them well, and they build the governance, data discipline and confidence needed to scale. That is a sounder foundation than a portfolio of pilots that never quite reach production.