The first mistake in automation projects is not technical, it is sequential: you buy the tool before understanding the process. You then automate an idealized version of the work, the one on the slides, not the one on the ground. And the tool breaks on the first edge case nobody documented.

Map the real process, not the official one

There are always two versions of a process: the one in the procedure and the one your teams actually follow, with its workarounds, exceptions and sticky notes. It is the second you must capture. Sit next to the person doing the work and record every step, every decision, every click.

  • Inputs: where the information comes from, in what format, how often
  • Steps: each action, who does it, how long it takes
  • Decisions: the points where a human judges by fuzzy rules
  • Exceptions: edge cases that break the rule (often 20% of cases, 80% of the complexity)
  • Outputs: what is produced, for whom, in what form

Spot what deserves automation

Not everything is worth automating. A good candidate is repetitive, high-volume, governed by clear criteria and expensive in human time. A bad candidate is rare, ambiguous, relationship-sensitive or constantly changing. Mapping lets you tell the two apart at a glance.

Before buying, ask whether you could explain the process to an intern in one page. If not, no AI tool will.

Clean up before you automate

A map almost always reveals useless steps: duplicate entries, validations that no longer serve a purpose, files copied by hand. Remove them first. Automating waste produces faster waste, not improvement. Often 30% of the gain comes from cleanup alone, before a single line of AI.

This step has a valuable side effect: it shrinks the scope to automate, and so the project cost and its risk. Fewer steps means fewer integrations to maintain and fewer potential breaking points.

From map to specification

Once the process is mapped and cleaned, you hold a near-ready specification. You know exactly what comes in, what goes out, which rules apply and where the human must keep control. That document protects you against a vendor: you buy a solution to a defined problem, not a generic tool hoping it fits.

  • A visual flow diagram, step by step
  • The list of explicit decision rules
  • Volumes and current cost (your ROI baseline)
  • Exceptions to handle or route to a human
  • Measurable success criteria

Challenge first, then build: a good process map beats a good tool poorly framed.

At NexusOS we always start with this mapping before talking technology. That is often where we discover a project does not need AI, or on the contrary desperately does. To frame yours, reach us at contact@nexus-os.fr.