A company buys an automation tool. Three months later the tool is installed, two people know how to use it, and the work still gets done the way it always was. The problem is rarely the tool.
The pattern goes well beyond Senegalese SMEs. In a preliminary study published in July 2025 by the MIT Media Lab’s NANDA project (The GenAI Divide: State of AI in Business 2025), based on 153 responses from executives and 52 interviews, 95 % of the organisations surveyed were measuring no return at all on their generative AI pilots. The authors put the gap down not to the quality of the models, but to the way the projects fit, or fail to fit, into how the company actually works. The sample is small and the method has been debated, but the finding matches what we see in the field.
A process that is written down nowhere still exists. It lives in the heads of the people who carry it out, in habits nobody ever decided on, and in exceptions each person settles their own way. As long as it stays there, it works. The day you want to automate it, you discover there was not one process but four: one per person.
What automation actually requires
A system, whether a simple chain of rules or a language model, needs to know three things before it can take a task on: what triggers it, what a correct result looks like, and what to do with the cases that fall outside the frame.
These questions sound elementary. They are not.
Take supplier invoice approval. What triggers the processing: the email arriving, the goods being received, or the moment somebody thinks to open the file? Which invoice counts as properly approved: the one carrying two signatures, the one that matches a purchase order, or the one whose amount stays under a certain threshold? And when the supplier bills 5 % more than the quote, who decides?
In a company where the process is not written down, those answers change depending on who you ask. That is what makes automation impossible. It is also what makes it profitable once the answers are settled, because the gain does not come from the tool alone. It comes from the clarity you had to produce to make the tool work.
“But that is exactly it, AI copes with the fuzziness”
This is the most frequent objection since language models arrived, and it deserves an honest answer. Yes, a language model tolerates more mess than a classic automation: it reads a badly written email, recognises an invoice in an unusual format, summarises an incomplete file. It cuts down the formatting work.
What it cannot do is take a decision in your place that nobody in the company has taken. When accounting applies one rule and purchasing another, the model does not arbitrate. It chooses, with confidence, and sometimes differently from one day to the next. It knows how to read a badly made document; it does not know how to guess a rule that does not exist, and when it guesses, it invents.
The mirror effect
As long as a human handles the task, they absorb the inconsistencies without saying so. They know that a particular invoice goes through even with a single signature, because that supplier matters. They know that at month end, everyone looks the other way on the deadline. That flexibility is useful, and nobody sees it.
A tool does not have it. Faced with a case nobody described to it, it stops or it gets it wrong. The conclusion drawn is that the tool is poor, when what it has just done is put its finger on a decision nobody had taken.
This is why the most useful automation projects begin with a phase that has nothing technical about it.
What a process audit brings to the surface
We carried out this kind of work for an organisation in the agricultural sector in Senegal, operating across several regions with a central structure and autonomous branches. The assignment started with a digital diagnostic and a full audit of the business processes. The action plan, the choice of collaborative tools, then the training of the teams came afterwards, once the way the organisation really worked had been set down in black and white. There is nothing original about that order. It is simply rarely respected.
From one organisation to the next, whatever the sector, this kind of audit brings up the same things:
- steps nobody can justify any more, inherited from an old control or from someone who left long ago;
- information keyed in two or three times between tools that do not talk to each other;
- waiting: the file sitting there for a signature, the information that has to be fetched somewhere else;
- implicit rules that hold only because one particular person is there.
Lost time rarely sits in carrying out a task. It sits in the waiting between two steps, and that is where a simple automation (a notification, a routing rule, a reminder) produces the most effect for the least effort.
Map before you buy
The exercise requires no tool. It requires a few days and some discipline. For each candidate process, three questions.
Who does what, and in what order?
Ask two people who perform the same task to describe it separately, without conferring. The gaps between their two accounts are your real map. Where they agree, the process exists. Where they diverge, it still has to be decided.
Where does the work wait?
Follow a real file from end to end and note the moments when it does not move. Count in hours or in days, not in impressions. You will get the one measure that will later let you say whether the project served any purpose.
What are the exceptions, and who decides?
List the cases that fall outside the frame and, for each one, the person who settles it. If the answer is “it depends”, you have found what will block the automation. Deciding now costs less than discovering the problem in production.
This work produces a clear decision on what deserves to be automated, and the material to do it properly. Now and then it produces a third result, less expected: the discovery that a step can simply disappear. Automating a useless task makes it useless faster.
Four signs tell you a process is not ready yet:
| The sign | What it reveals |
|---|---|
| “It depends” keeps coming back in the answers | A decision rule is missing. It will have to be written before anything is automated. |
| Two people describe two different circuits | The process has never been arbitrated. There are as many versions of it as there are people performing it. |
| One person alone knows all the exceptions | The knowledge is not transferable, so it cannot be automated as it stands. |
| Nobody can say how long a file takes | The gain will not be measurable, and the project will not be judgeable. |
Training the teams does not replace this work
Faced with the fuzziness, many managers make another choice, one that looks more prudent than buying a tool: train the teams first. The reasoning runs as follows. If people understand AI, they will know what to do with it. That reasoning is right in one case and wrong in the other, and the difference lies in the context the training takes place in.
A generic course teaches what a tool can do. Participants leave with some notions, a few reflexes, and a working environment identical to the one they left that morning: the same files, the same approvals, the same information arriving by phone. They do not know where to apply what they have learned, because nobody said which task was supposed to change. A few weeks later, they work as before. The skill has not disappeared, it never had anything to attach itself to.
The same course has a different effect when it comes after the mapping. Participants know the process being targeted, they know where it jams, and they work on their own files during the training. They leave with something that runs on their data, not with an example seen on a screen. The next day, they have a precise task to do differently, and a result to compare with the old way of doing it.
This costs no more than an off-the-shelf course, but it does require having done the work described in the previous section. It is how we build our programmes. kaikai is a 3FPT-accredited training body in the information systems domain: these courses may be eligible for funding, subject to the fund’s conditions.
The order matters
Map, decide, then tool up.
The temptation to start with the tool is strong: it is concrete and it demonstrates well in a meeting. A tool laid on top of a fuzzy process reproduces the fuzziness, only faster and at greater cost.
A company that has written its processes down can choose its tools without rushing, and change them without rebuilding everything. Above all, it can measure what the automation earned it, which is the only way to know, a few months on, whether the project was worth its price.
Where to start
Choose a single process: the one your teams complain about most. Put it through the three questions above. If the answers are clear, it is ready to be automated. If not, you know what has to come first, and it requires no software. And if you would rather run the exercise with an outside eye, a few days of diagnostic are enough to map a first process.
Book a conversation: calendar.app.google/RCeLhNZCPsY72Jvb7
Source cited
Challapally A., Pease C., Raskar R., Chari P., The GenAI Divide: State of AI in Business 2025, MIT NANDA (MIT Media Lab), July 2025, preliminary report.