Few executives begin the day thinking their company is losing money because of the way it is organised. They think about revenue, margins, the next hire, the competition.

Disorganisation rarely announces itself as a problem in its own right. It shows up as a detail. An email left unanswered. One more meeting. A spreadsheet that has to be updated by hand, again.

Taken on its own, each of these is negligible. That is precisely what makes them dangerous. None is serious enough to be tackled head-on, yet together they quietly shape the real performance of the business.

Nobody chooses to ignore it. It escapes attention by construction.

This essay comes from a conviction formed in the field, after years of assignments spent watching how companies actually work, beyond their org charts and their software. That conviction is simple: operational friction costs most companies more than a majority of the strategic decisions they take. And it has no budget, no KPI, no steering committee.

Operational friction is the sum of the effort, the delay and the loss that appear on no accounting line, but that slow down, degrade or complicate how an organisation actually runs.

No breakdown, no incident triggers it. It settles in as a permanent regime of small losses, spread everywhere, that nobody ever adds up.

The friction paradox

Executives manage what they can measure. Operational friction fits no accounting category. A non-conformity that drags on three weeks longer than necessary generates no invoice. Information that has to be asked for three times from the same person generates no expense claim.

Time lost looking for a file, chasing a colleague, reconstructing a history before an audit appears on no standard financial dashboard. Friction therefore escapes management naturally, not through negligence, but by construction: the systems executives rely on were never designed to reveal it.

The law of accumulation

No organisation is born disorganised. It becomes so, one tool at a time, one exception at a time, one hire at a time.

Friction is not an event. It is an accumulation.

There is nothing extreme about this case. It is an ordinary situation, repeated in very similar forms across a large majority of the manufacturing SMEs we meet. The details change. The underlying problem almost never does.

Operational friction is therefore not a problem of competence, nor of goodwill. It is a problem of structure.

A problem of structure is never solved by working harder. It is solved by changing the structure itself.

To act on operational friction, you first have to be able to name it precisely.

After years spent mapping how SMEs of every size and sector actually work, the same pattern comes back every time. Friction does not take a single form. It shows up at five distinct points in the life cycle of a piece of information, a decision or an action.

It is along this cycle, at each of its stages, that the five forms of friction appear.

1. Informational friction

It appears when the information exists, but is not in the right place, at the right moment, for the right person.

The volume of data has nothing to do with it. Companies are surrounded by information. Circulation is the problem: information is scattered across tools that do not talk to each other, or reachable only by interrupting somebody else.

The information exists. It does not flow.

2. Decision friction

It appears when a decision that could be taken in minutes takes days.

For want of a clear process, it depends on several exchanges scattered across emails, corridors, chat and improvised meetings. Meanwhile, nobody really knows where the matter stands, or whose decision it is.

The delay almost never comes from the complexity of the decision. It comes from the absence of a process for taking it.

3. Organisational friction

It appears when the structure itself complicates what it should simplify.

Poorly defined roles. Responsibilities that shift depending on who happens to be there that day. Processes that exist in the written procedures, but bear only a distant resemblance to how the work actually gets done.

The company ends up running on two parallel models: the one that is written down, and the one the teams apply every day.

4. Regulatory friction

It appears when compliance — quality, safety, environment, data — rests on periodic reconstruction rather than continuous tracking.

The company is not non-compliant. It is simply unable to prove it quickly, which on audit day amounts to almost the same thing. When the audit approaches, teams scramble to rebuild documentation that should have existed all along.

5. Human friction

It appears when the running of the company depends on a small number of people who know, remember, or compensate.

These people remember the unwritten procedures, understand the historical exceptions and make up for weaknesses elsewhere in the organisation. Their value is real. So is the risk they represent.

This is not a problem of talent. It is a problem of dependency: when that person is away, on holiday, or leaves, part of the organisation's knowledge leaves with them.

Faced with friction, the natural reflex is to add a tool. One more spreadsheet, an ERP, an Asana, a Monday, and today a piece of artificial intelligence.

The problem is not that these tools are bad. Many are excellent within the scope they were designed for. It is that each solves one piece of the problem, never its overall structure.

Spreadsheets structure data, but structure no process. Every file quickly becomes a personal version of reality, different from the one held by the colleague sitting next door.

An ERP structures processes, but rarely the ones that make the difference. Designed for finance, production or procurement, it handles what is generic, identical from one company to the next, and supported the same way everywhere. The key processes, the very ones that set a company apart from its competitors, do not fit that mould. They end up handled elsewhere, in a spreadsheet or an email.

Asana and Monday structure tasks, not operations. They excel at organising a one-off project, far less at sustaining a recurring process with business rules, traceability and clear responsibilities.

Artificial intelligence, finally, structures answers, not data. A conversational agent can draft, summarise, synthesise. It cannot, on its own, decide where the reference information lives, who is responsible for what, or which business rules apply.

Each new tool, taken on its own, seems to solve a specific problem. End to end, they produce the opposite of what was intended: more places to look for information, more interfaces to learn, more different logics to remember, more people who know "how it really works" in one tool or another.

The stack of tools grows. The structure never gets built.

Operational debt

This mechanism has a name, on the same principle as technical debt in software or financial debt in management. Organisations accumulate operational debt too.

Every shortcut taken to absorb a one-off exception looks free at the time: a process worked around, a file created under pressure, an unwritten rule tolerated for an important client. It is not.

Each one adds a layer of complexity that somebody will one day have to understand, maintain and explain. Like any debt, operational debt earns interest. The bill rarely arrives at once. It arrives at the moment the company can least afford it: an audit, rapid growth, an ERP migration, the departure of a key person.

Growth inevitably creates exceptions. The problem is not that they exist. It is that they are allowed to become permanent. The longer a workaround lasts without being revisited, the more it settles into daily operations. One day nobody remembers why it is there, and everybody keeps applying it.

The costs accumulate quietly: time lost, errors, a growing dependence on the few people who still know why a given rule exists.

Generative artificial intelligence is today the object of considerable investment. It is also, if the most widely cited studies are to be believed, one of the best indicators of what this essay is trying to demonstrate.

A widely reported study from the MIT Media Lab (Project NANDA, 2025) finds that 95 % of generative AI pilot projects in business produce no measurable financial impact². Other studies point to converging causes: projects chosen for their innovative character rather than their business relevance, internal developments far more fragile than external partnerships, and above all, according to IBM's most recent analyses, an obstacle that is almost always organisational rather than technological³.

The obstacles are always the same.

It is almost never the technology that is the problem. It is the organisation.

What these studies sometimes stop short of naming clearly, field experience confirms bluntly: an artificial intelligence agent plugged into informal business rules and data scattered across five tools that do not talk to each other cannot produce lasting value. It inherits the disorder it was asked to resolve, and hands it back, simply faster.

Artificial intelligence is not the cause of this failure. It is its most visible indicator. Previous generations of software masked structural weaknesses, because they were slow and confined to a narrow scope. AI exposes them immediately.

That principle alone explains why so many AI projects disappoint despite considerable budgets. Many organisations approach AI as though it could compensate for fragile operational foundations. The opposite is true: the more sophisticated the technology, the more it depends on structured processes, reliable data and explicit business rules.

AI does not manufacture organisational discipline. It only exploits the discipline that already exists.

After four chapters spent demonstrating that every tool added makes friction worse, proposing a piece of software architecture looks like a contradiction.

It deserves to be met head-on, because it is exactly the objection you should have in mind at this point. The difference is not about the software. It comes down to one simple test:

One more tool adds a place to look for information. A hub removes one.

If, six months after deployment, your teams are still consulting the same number of spreadsheets, mailboxes and business applications to reconstruct the state of a case, you have bought one more tool, whatever its vendor calls it.

An operational hub is a different kind of thing. Its purpose is not to add an application to an already crowded estate. It is to become the single reference point through which work is coordinated and understood.

In practice, an operational hub meets four conditions, and all four can be checked before you buy.

1. Business rules are written in business language

The quality manager can read, understand and change the rule that triggers a follow-up on a non-conformity, without raising a ticket with a developer and without depending on a colleague's memory.

Business rules belong to the business. Not to IT.

2. Every operational record has a single home

A qualification, an action plan, a customer complaint, a maintenance report exists in one place only. Other tools may read it or feed it, never hold a copy that goes on to live its own life.

As soon as several versions of the same information coexist, disagreement about which one holds authority is never far behind.

A single source of reference is not a technical objective. It is an operational necessity.

3. Existing applications plug in rather than pile up

The ERP stays the ERP, email stays email, business applications carry on doing what they were designed for. The hub does not replace them. It becomes the point where their information converges, where business rules apply, and where the process itself is steered.

Instead of creating one more silo, the hub connects the ones that already exist.

4. The real state of the organisation is continuously visible

How many action plans are still open? Which customer complaints are overdue? Which audit findings are still outstanding? If answering those questions takes days of investigation, several meetings and a manual consolidation of files, the organisation has no operational visibility.

The number of open action plans, the example from chapter 1, stops being a question that takes three weeks to answer.

Operational status should never require an investigation. It should be read.

Why this changes everything

This is also what answers the failure described in chapter 4. An artificial intelligence agent plugged into five tools and spoken rules inherits the disorder. Plugged into a hub, it finds what it was missing: explicit rules, data that holds authority, named responsibilities and structured processes.

Instead of interpreting chaos, it works in an environment that has already been organised. Deploying AI then stops being a technological bet and becomes the logical continuation of structuring work already done.

This is the model we have been building at Klaro Cards since 2017, first for manufacturing SMEs facing certification requirements, and more broadly today.

This vision was not born this year. Klaro Cards has carried it from the start, against the grain of a market that was not yet ready to hear it. What is changing today is the context, not the vision itself: the large-scale deployment of artificial intelligence, and a collective realisation among executives of the need to finally structure their processes and their business rules.

The organisations that win tomorrow will not be those that use the most artificial intelligence. They will be those with the least operational friction.

That sentence may look out of step at a moment when every board is calling for an AI strategy. It is not. It is the most realistic reading of it. Artificial intelligence only amplifies what already exists in an organisation.

The technology is the multiplier. The organisation decides what gets multiplied.

This conviction has carried Klaro Cards from the start. What has changed is not the vision, it is the context. That moment, long anticipated, is arriving.

This essay was not written to convince you to buy anything. It had a more modest and, we hope, more useful aim. That you never look at your organisation in quite the same way again.

Thomas Godin — Fractional CRO, Klaro Cards — thomas@klaro.cards