Artificial intelligence doesn't fix a poorly designed company; it accelerates it. A language model connected to a confusing process doesn't produce clarity; it produces confusion at a faster rate and on a larger scale. This is why so many companies that have deployed AI don't see a return on investment in any line of their income statement: they didn't buy a solution; they bought a multiplier, and they applied it to something that wasn't ready to be multiplied.
This is not an anti-AI stance. It's quite the opposite. AI deserves to be applied where it can generate real advantage, and to do that, we need to stop treating it as a product that is installed and start treating it as a capability that is integrated into a functioning system.
A business process is a chain of decisions, responsibilities, data, and exceptions. When that chain is well-defined, automating it frees up capacity. When it isn't, automating it turns ambiguity into output.
Think about what exactly happens when you connect an AI assistant to an order approval process that no one has documented. The model doesn't know which orders require dual signatures, because that rule exists only in the mind of someone in the department. It doesn't know what to do when a customer has an open issue, because that condition was never written down. It doesn't know what an exception is, because exceptions were handled through conversation.
The result is not that the system visibly fails. The result is worse: the system functions, produces plausible responses, and these responses circulate throughout the organization with the implicit authority of having originated from a system. The error ceases to be detectable at first glance and becomes systematic.
This is the difference between a tool and an amplifier. A tool performs a task. An amplifier boosts the signal it receives, and it doesn't distinguish between signal and noise.
McKinsey, in its 2025 State of AI global survey (1,993 participants in 105 countries), found that 88.1% of organizations routinely use AI in at least one business function. That headline has been repeated in every business presentation over the past year.
The rest of the report is much less repetitive. Only 39% reports any impact on EBIT at the company level. Only 6% qualifies as *high performers*, with more than 5% of EBIT attributable to AI. And McKinsey's conclusion is literal: significant impact on the bottom line remains rare.
IBM arrived at the same place by a different route. Its 2025 CEO Study, with 2,000 CEOs from 33 countries, found that only 251% of AI initiatives had produced the expected return, and only 161% had been scaled to the organizational level.
The interesting question isn't why so many fail, but what distinguishes the ones that succeed. McKinsey identifies one factor that correlates more than any other with the impact on EBIT: having fundamentally redesigned workflows. Only 21% of the organizations that adopted generative AI had done so.
In other words: the variable that separates those who make money from those who don't is not the model. It's the prior work.
It doesn't mean a poorly managed or unprofitable company. Many companies with inefficient processes are profitable because they compensate for the disorganization with human effort. The problem arises when they try to automate that effort.
These are the four symptoms we most frequently encounter in a diagnosis:
The process only exists in someone's head. There's someone who knows how it's really done. When that person is on vacation, the process deteriorates. An undocumented process can't be automated; at best, it can only be partially imitated.
There is no single source of truth. The customer data is in the CRM, in a salesperson's spreadsheet, and in the ERP, and all three are slightly different. AI doesn't resolve this contradiction; it chooses one of the three versions without telling you.
Exceptions are not designed, they are discovered. No one has listed the rare cases. They are resolved as they arise. In production, these rare cases fall between 15% and 30% of the actual volume, and they are precisely where automation breaks down.
There is no one responsible for the result, only for the task. There's someone who approves, someone who records, and someone who invoices, but no one is accountable for the entire process. When it's automated, the accountability gap doesn't disappear; it gets bigger, because now there's a system in between that can be blamed.
None of these four problems is a technology problem. All four are exacerbated by adding technology.
The sequence matters more than the tools. This is the contrast between the two approaches:
Approach | Start with AI | Start with the process |
First step | Choose a model or supplier | Map decisions, data, and exceptions |
Initial metric | Number of users, queries, demos | Cycle time, error rate, cost per case |
Where does the problem appear? | In production, after three months | In the diagnostic phase, on paper |
Cost of correcting | Stop: integrations need to be redone | Below: a diagram is corrected |
What remains in the end | A tool that nobody uses | A better process, with or without AI |
The column on the right has a property that the one on the left does not: it generates value even if AI is discarded. If, at the end of the analysis, it is concluded that the case does not justify a model, the company still retains a mapped process, identified exceptions, and located bottlenecks. That work is never lost.
At The Cloud Group, this sequence is formalized in our TCG-SAF™ methodology: first, the ecosystem vision is defined; then, the functional domains are mapped; then, the modules and their contracts are structured; and only then does engineering begin. When process analysis precedes development, the debate about which model to use becomes what it should be: a reversible technical decision, not the strategic decision of the project.
This same principle is what we apply in our services process redesign and technology consulting [internal link], where process mapping and bottleneck identification always precede any automation recommendations.
It would be dishonest to claim that you should never start there. There are three situations in which starting directly with a model is the right decision:
When the process is already clean and the bottleneck is volume. If the ticket classification system is well-defined, with explicit criteria and consistent data, and the problem is that ten thousand tickets arrive each month, there's no need to redesign anything. What's needed is capacity.
When the stated goal is to learn, not to produce. A limited experiment, with a fixed budget and a defined endpoint, is a reasonable investment in organizational capacity. The mistake isn't experimenting; it's calling an experiment a "project" and expecting a return on it.
When the use case lives in language. Summarizing documentation, extracting information from contracts, analyzing sentiment in support conversations. These are problems that traditional software inherently struggles with, and where this model provides capabilities that didn't previously exist.
Outside of those three scenarios, starting with the model is starting with the end.
The conversation in management committees is often framed as "where do we put AI?". It's a question that guarantees a mediocre answer, because it starts with the solution and looks for the problem.
The useful version of that question has three parts:
A company that honestly answers those three questions almost always discovers that its first AI project isn't really an AI project. It's an operational clarity project that will later incorporate models where they provide an advantage.
That's the difference between a company that spends on AI and a company that profits from it.
No. AI amplifies the process it connects to: if the process has ambiguous rules, contradictory data, or undocumented exceptions, automation reproduces those flaws at a higher speed and scale. Process redesign should precede automation, not follow it.
Four things: document the decisions and who makes them, establish a single source of truth for the data involved, list and design the exceptions, and assign someone responsible for the overall outcome of the process, not just individual tasks.
According to IBM's 2025 CEO Study, only 251% of AI initiatives have delivered the expected return, and only 161% have been scaled. McKinsey identifies deep workflow redesign as the factor most strongly correlated with EBIT impact, and only 211% of organizations had implemented it.
It depends on the scope, but diagnosing a specific process—decision map, data, exceptions, and responsible parties—is usually completed in weeks, not months. This is a much shorter timeframe than correcting a poorly designed automation system once it's in production.
When the process is already defined and the problem is one of volume, when the stated objective is to learn through a bounded experiment with a stopping criterion, or when the use case lives in natural language (documentary summary, information extraction, sentiment analysis).
Digitizing is transferring the current process to a tool. Redesigning is questioning the process before transferring it. Digitizing an inefficient process produces a faster, inefficient process; redesigning it produces a change in the business outcome.
Do you want to know if your process is ready to be automated? At The Cloud Group, we start with a diagnosis, not a technical proposal. We analyze your specific case in a two-hour, no-obligation consultation and tell you what deserves to be redesigned and what deserves to be automated—even if the answer is that it's not time yet. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
