According to the report The GenAI Divide: State of AI in Business 2025, as many as 95% of companies that have implemented large language models for general-purpose applications have not seen any measurable return on investment. Zero. A similar conclusion was drawn in the study The State of AI commissioned by McKinsey. It states that while the adoption of generative AI is currently very widespread, over 80% of respondents do not see a tangible impact of AI at the enterprise level.
By citing these estimates, I don’t mean to downplay the value of artificial intelligence itself, but rather to shed light on a more complex phenomenon that I like to call unfounded techno-optimism.
You don’t have a problem, but you have a tool
Techno-optimism follows a specific pattern. First, a new, miraculous tool appears. Then comes the buzz on social media; everyone wants it, budgets swell, and implementations get underway. Eventually, after a few months – at most a dozen or so – it comes to light that the team uses the purchased tool only on rare occasions, half the features are unknown to anyone, and the return on investment is hard to find even with a magnifying glass. I’m not writing this based solely on statistics and reports. I see this pattern regularly with clients and in conversations with people who, in hindsight, are amazed at how easily they were talked into an unnecessary purchase.
The funny thing is that, in theory, each of us knows how to protect ourselves from this phenomenon. After all, all you need to do is first define a specific, measurable problem within the organization, then derive a need from it, and only then look for the optimal tool that addresses that specific need. In short, you must follow the only logical sequence of actions. If you don’t know the problem, you might buy the most expensive tool on the market, order a true jack-of-all-trades – which, in practice, will be useless.
The tool must be a means, not an end. We all understand this principle. And yet, carried away by a wave of techno-optimistic enthusiasm, we all forget it from time to time.
Pick the low-hanging fruit
However, defining the problem is only half the battle. We must also ask ourselves another question: do we really need to buy something new, or might it be enough to start making broader use of the tool we already have?
Low-hanging fruit is just begging to be picked. Only when a ripe fruit hangs a little higher, out of reach, does it make sense to buy a taller ladder.
Translating this to the issue of tools, we need to weigh the costs and benefits. On one side of the scale is the cost of extending an existing solution to a new area. On the other, the total cost of implementing something completely new. We’re talking about the license, but also integration, training, implementation time, and the inevitable temporary drop in efficiency. Usually, the first option is cheaper. Not always, but usually.
„We’re talking about licensing, but also integration, training, implementation time, and the inevitable temporary drop in efficiency”.
The problem is that a surprising number of organizations don’t know what they already have at their disposal. Excel is my favorite example here. The ubiquitous spreadsheet from the Office suite – a tool available everywhere, known to everyone, and developed over decades – is used by the average user at perhaps 10-15% of its capacity. It’s no different with more advanced platforms. Without someone who truly understands a tool’s potential, an organization can’t answer the question of whether it needs something new.
The response is a compensatory reflex. Since the team can’t extract value from the tool they already have at their disposal, they easily come to believe they need another one. This is how the pile of programs, platforms, and applications grows, half of which do the same thing. Instead of streamlining processes, this leads to data fragmentation and increases the cognitive cost of daily work.
What do I mean? Too many applications on board cause people to jump between interfaces, search for the same information in multiple places, and handle data twice – even though each of these tools was supposed to streamline work. This kind of chaos even has a name: SaaS sprawl.
Don't just fix the symptoms. Start with a diagnosis
It’s worth distinguishing this from the similar phenomenon of shadow IT. In the latter case, employees install or subscribe to tools on their own, without the IT department’s knowledge or even consent. A classic example: the marketing team starts using some niche design software, pays with a personal credit card, and no one in the company’s IT department knows about it. This activity takes place outside official channels. It has consequences because it allows systems to coexist within the organization that many employees are unaware of. It also limits the ability to control data flow, including sensitive data.
SaaS sprawl happens in full view. Management has approved the tool, IT is aware of it, and invoices go through accounting. The problem arises when the number of these official, legally paid-for tools keeps growing, but no one is monitoring whether they perform duplicate functions. Two different departments purchase separate subscriptions to similar applications. Both have, for example, a reporting module, but each pulls data from a different source. Neither communicates with the other. Data becomes scattered, reports diverge, and the cognitive cost of work rises at an alarming rate. The license fee is the least of the problems in all of this.
When is THAT moment?
Let’s assume, however, that the company’s needs are already reasonably defined and we truly know what we’re looking for. When do we actually know it’s time for a new solution?
The answer lies in measuring throughput. Every process can be broken down into links, where each link has its own capacity – a specific number of operations it can handle per unit of time. If you have that number and track how many operations you’re actually performing, you have an early warning. When you reach 80% of capacity and forecasts indicate further growth, that’s the moment to look for a solution. Ideally, even before the link breaks.
However, this requires a certain level of operational discipline. But what about organizations that lack this discipline – or simply don’t track it? In those cases, bottlenecks emerge on their own. They manifest as frustration, overload, errors, and high staff turnover. It’s a more costly warning, but it works. If you hear signals from the team that something is too slow, too difficult, or too much – that’s already a problem that should be a signal to look for a solution. Not for next year, but right now.
Who should decide on implementation?
The decision to implement a tool depends on the internal policies of each organization. Here, too, patterns prevail. Either the CEO has the final say – often the one most susceptible to the allure of techno-optimism – or the IT department decides, which in turn doesn’t always understand the business context; or – perhaps worst of all – each division of the company decides separately, without a coherent vision for the technology stack.
In my opinion, the optimal approach is a kind of “committee” capable of combining two key functions:
- The financial function. Every implementation should have a well-researched and universally understood path leading to measurable value: revenue growth or cost reduction. Without this, it’s simply a blind purchase.
- Technical function. Responsible for consistency with the existing stack. A tool that works great in isolation but doesn’t integrate with the rest of the infrastructure generates hidden costs that accumulate over the years.
A simple example. If an organization operates within the Microsoft ecosystem, a product from the same vendor has better integration from the start with what people use every day. This doesn’t mean it’s necessarily the best of all the software on the market. But the cost of assimilating external solutions is real, high, and impacts the final bill.
Proof of Concept
And what happens after purchasing the license? One of the most costly illusions in organizations goes something like this: we’ve ordered a great tool, so the problem is solved. All we need to do is configure it somewhat, and the rest will work itself out.
No, things don’t just fall into place on their own. If you believe that, you’re likely to face the following scenario: the pilot project will wow everyone, the demo will pass with flying colors, and at the meeting, everyone will stand up and applaud.
And then the tool will end up in a drawer, where it will be forgotten.
The industry uses the term Proof of Concept (PoC). It’s a preliminary demonstration showing that a solution can work perfectly – at least from a technical standpoint, under controlled conditions, with selected data, and operated by the people who built it. However, a PoC does not prove that the tool will function reliably with real data, real users, real operating costs, and the usual daily chaos. The difference is fundamental. Something may work on paper and during a presentation, yet be completely unsuitable for stable, day-to-day use. Companies invest in a pilot, declare success, and try to scale the solution before answering basic questions regarding integration or day-to-day management of the system.
Without intensive training and showing people how a specific tool adds value to their routine work (important: not abstractly, but specifically in their tasks), most will use 10% of its capabilities – or won’t use it at all. This is a waste of budget in its purest form.
I remain a proponent of requiring that, along with the ordered tool, a guide on how to use it in a specific role be provided to the team. It makes no sense for someone to have to figure out on their own features that someone else discovered and tested long ago. Best practices should be a starting point, not an endpoint. Deepening one’s understanding of how to use the tool and adapting it to individual preferences is, of course, up to each employee. But the basics? Those should be provided during the implementation phase.
Ease of entry and… exit
And what happens if, in the near or distant future, we decide to abandon the solution we’ve purchased? We live in a dynamic technological environment. Tools emerge, disappear, get acquired, change pricing models, and stop being updated or developed. Even if the tool itself remains useful today, we must check whether it is quietly tying our hands. When entering even the most beautiful garden, it’s worth making sure that no one is closing the gate behind us.
A specific and increasingly common manifestation of this danger is so-called vendor lock-in. A situation in which an organization becomes so deeply entrenched in a single software vendor’s ecosystem that leaving becomes technically daunting and financially painful. Data is stored in their format, processes are built around their API, and the team knows only their specific interface. Even if you can formally leave at any time, the cost of migration and rewriting integrations means you’ll stay for many years. And the vendor knows this, which usually translates into higher subscription prices during subsequent contract renewals.
For this reason, the criteria I use to select a tool include not only the cost of implementation and training, the cost of ongoing maintenance, or integration capabilities, but also the potential exit cost. Only these four dimensions together provide a fairly accurate picture of what we’re actually buying. I consider not only the service’s functionality but the entire economics behind the decision being considered.
Not every organization needs a new tool. Usually, it needs a good diagnosis—and that’s exactly where we start when working with our clients.
