Why run a diagnosis before automating a business process?

A diagnosis is worth doing before automating because automation does not fix a process: it repeats the process you already have, only faster, mistakes included. The diagnosis shows how the work really flows, where it breaks, and which part is worth automating first, before anyone spends money on tools.

Have you ever bought a system, switched on an integration, or set up a messaging bot, and a month later the team was fixing by hand what the machine got wrong? Almost always the problem was not the tool. It was whatever nobody looked at before switching it on.

In 1797, Goethe published the ballad The Sorcerer's Apprentice. The old sorcerer leaves his workshop and gives the apprentice chores. Tired of fetching water by pail, the apprentice enchants a broom to do the work for him, using magic he has not yet mastered. The floor starts to flood, and he realizes he does not know the spell to make the broom stop.

In despair, he splits the broom in two with an axe. Each half becomes a whole broom, both go back to fetching water, and now at twice the speed. Only when the sorcerer returns is the spell broken. In 1940, Disney brought the story to Fantasia, with Mickey Mouse as the apprentice.

It is a good picture of automation without a diagnosis. The broom does exactly what it was told. The problem is that nobody defined when it stops, what happens when the pail overflows, and who switches everything off. And the most common reaction to the flood, putting one more automation on top of the first, does the same as the axe: it doubles the problem.

In 1990, Michael Hammer wrote an article in the Harvard Business Review with a blunt title: Reengineering Work: Don't Automate, Obliterate. In it he says that many of the workflows and structures in companies came of age before the computer, and concludes: "It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over."

You do not need to go as far as Hammer to use the idea. In a small business, tearing everything down rarely makes sense. But the core point still holds: if the path was opened by habit rather than by decision, paving it only makes the habit harder to change.

At DOUVRAS, the page for our automation and integrations service describes the problem we meet most often: the information exists, but it crosses the company through manual copying, memory, and scattered messages. Automating that without looking first means turning someone's memory into code, flaws included.

A diagnosis is not an opinion meeting. It is a short piece of work that ends with something concrete in the business owner's hands. In the format we use to start with small businesses, the delivery includes:

• Analysis of the current process. How the work happens today, not how the manual says it should.
• A flow map. Who does what, in what order, with which systems, and where data is copied by hand.
• One simple automation. A first automated step, small enough to test the idea without risk.
• An organized spreadsheet or CRM. The data base the workflow starts to rely on.
• An improvement report. What is worth automating next, in what order, and what is not.
• A video explaining how to use it. So the team learns to operate it without depending on whoever built it.

Behind this are the four questions that open any project of ours: what the bottleneck is, what the dependencies are, what evidence shows it worked, and what stays out. We covered them in the article on why business owners don't buy AI. The diagnosis is where those answers stop being guesses.

The map almost always shows more than one candidate. To pick the first, we use the criterion we already published in how to automate without automating chaos: the best first candidate is frequent, bounded, and reversible.

• Frequent. It happens every day or every week, so any gain shows up quickly.
• Bounded. It has a clear start and end, like answering a new contact or recording a payment.
• Reversible. If it goes wrong, it can be undone without serious harm.

The same article gives the opposite warning: if the cost of an error is high, or if nobody can explain the exception, the process still needs architecture before automation. This is where Goethe's apprentice could have saved himself. Before enchanting the broom, he only needed to know how to stop it.

An automation built from a diagnosis is born with what the apprentice lacked. Our automation scope includes the map of the current flow and its failure points, integrations with retry handling so the same event is not processed twice, and logs, alerts, and a contingency procedure. The expected result is a versioned, observable workflow, where failure shows up instead of hiding.

And the diagnosis creates a baseline. After measuring volume, failures, and time saved in the first workflow, you can decide based on facts whether it is worth connecting the next system. The automation grows because it worked, not because there were tools to spare.

Doesn't the diagnosis delay the project? Less than rebuilding an automation set up on top of the wrong process. It is short on purpose and already ends with a first automated step.

Is my company too small for this? No. It is precisely in a small company that the process lives in the heads of two or three people, and that knowledge is what the flow map puts on paper.

What if the diagnosis shows automation is not worth it? That is a useful result too. The improvement report says what to fix first and what can stay as it is.

DOUVRAS Labs works with automation and integrations, custom software, AI agents, websites, and technical rescue, and every project starts the same way: a diagnosis conversation that defines the bottleneck, the dependencies, the evidence of completion, and what stays out. The budget only comes after that scoping.

And in your company, which broom is already fetching water without anyone knowing how to make it stop?

Douglas Henrique, DOUVRAS Labs.

Hammer, Michael. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review, July 1990. hbr.org

Goethe, Johann Wolfgang von. Der Zauberlehrling (The Sorcerer's Apprentice), 1797.

The Sorcerer's Apprentice. Wikipedia. wikipedia.org

DOUVRAS Labs. Automation and integrations. douvras.com

DOUVRAS Labs. How to automate without automating chaos. douvras.com