A growing company rarely suffers from too little software. Sales, marketing, finance, service and operations introduce new applications because each is expected to solve a real problem. Every individual decision may be reasonable. Yet the company as a whole becomes slower: information is entered repeatedly, employees keep moving between interfaces, approvals remain pending and nobody owns the complete flow of work.
The economic consequence extends well beyond a larger licence budget. Invisible process costs, conflicting data and operational dependencies increase with every stage of growth. The answer is neither another tool nor a blanket move to one platform. Management must design the end-to-end flow and judge every system by whether it improves that flow.
This article explains how executive teams can recognise tool sprawl, which decisions they need to make and how an accumulated application landscape can become a manageable operating system.
Tool sprawl does not simply mean “too many tools”. It occurs when the coordination burden between applications grows faster than the business value those applications create individually.
The problem begins with reasonable local decisions
Tool sprawl is rarely the result of one obviously poor choice. A team needs faster reporting and buys an analytics solution. Sales adds a prospecting tool. Marketing introduces another automation platform. Operations digitises approvals. Individual employees adopt AI assistants because the official process is too slow.
Each measure initially reduces a local constraint. The side effects emerge between functions. A lead has one status in marketing and another in the CRM. An order is updated in the ERP, but the change does not reach service. An AI assistant receives context from only one part of the process. Executives see different versions of the same metric.
Okta reported that the average number of applications used across its customer base reached 101 in 2025.1 This is not a universal average for every SME. It does, however, indicate how broad modern business application landscapes can become. The decisive question is therefore not whether one piece of software is useful. It is: What does connecting all these applications cost the business every day?
Across more than 20 years working at the intersection of marketing, CRM, performance, transformation and automation, I have seen the same development repeatedly. Companies invest in functions but far less often in the architecture between those functions. As long as the business remains manageable, experienced people compensate for the gaps. As customer numbers, teams and markets grow, that human improvisation becomes the constraint.
Four types of cost remain invisible in conventional budgets
Licence costs are easy to identify. The larger burden often sits outside the software budget. It is distributed across working time, waiting time, errors and management attention.
Switching cost: people become the interface
A study of 20 teams comprising 137 users across three Fortune 500 companies analysed 3,200 working days. Employees switched between applications and websites almost 1,200 times per day on average. The measured reorientation time added up to just under four hours per week or around nine per cent of annual working time.2 3
These figures should not be transferred uncritically to every organisation. The underlying observation is nevertheless important: when people must find, transfer, compare and reinterpret information, they perform the integration work that the system does not provide.
Context cost: the process loses its history
A CRM record may contain the customer status. The ticketing system knows the current issue. The contract sits in a document repository. Price and delivery information comes from the ERP. The relevant decision remains in an email or in one employee’s memory.
None of these systems is necessarily poor. The process is still weak if context must be reconstructed at every handover. Microsoft’s 2023 Work Trend Index found that 62 per cent of respondents struggled with too much time spent searching for information. Across the Microsoft 365 work patterns analysed, employees spent an average of 57 per cent of their time communicating and 43 per cent creating.4
This is not an argument against communication. It is evidence that search and coordination have themselves become a production system, often without a named owner.
Data cost: more systems create more versions of reality
Every additional application introduces fields, definitions, duplicates and synchronisation rules. Which source owns the customer number? Where is the current revenue stage maintained? Which date is binding for the delivery commitment? May the new AI tool access the same information as the sales representative?
When these questions remain unresolved, technical effort is not the only cost. Management begins to distrust its metrics. Decisions are delayed or protected by manual one-off analyses. A data problem becomes a leadership problem.
Accountability cost: everyone owns a tool, nobody owns the flow
Marketing owns the automation platform, sales owns the CRM, finance owns the ERP and IT owns access. But who owns the complete journey from customer enquiry through quotation, order and delivery to the next commercial opportunity?
The NIST Cybersecurity Framework 2.0 places GOVERN and IDENTIFY at the beginning. Organisations are expected to establish roles, responsibilities and authorities and to understand assets including data, software, systems, services and suppliers.7 This is more than a security requirement. It is a prerequisite for operational control.
Why one platform does not automatically solve the problem
The instinctive response to tool sprawl is consolidation. That can be the right decision, but it is not a strategy in itself. Replacing specialist applications with one broad suite may reduce licence and integration effort. It can also produce weaker functional capabilities, new workarounds and greater dependency on one supplier.
A best-of-breed approach can work equally well when specialised applications provide a meaningful advantage and are properly integrated into the business process. The choice between a suite and a specialist tool should not be ideological. It depends on process criticality, differentiation, integration capability, data ownership, risk and switching cost.
The U.S. General Services Administration therefore does not describe application rationalisation as a universal, one-size-fits-all method. Applications should be evaluated in the context of business, technology, security, value, fit and cost, with participation from both senior leadership and real users.8
An executive team should not ask, “How many tools are too many?” The better question is, “Which combination creates the lowest coordination burden for the business outcome we need?”
The Fassbender Tool-to-Flow Test
Before a new system is purchased, an existing application is renewed or an internal solution is built, management should examine six areas. The Tool-to-Flow Test shifts the decision away from feature lists and towards the end-to-end outcome.
| Test area | Management question | Warning sign |
|---|---|---|
| Outcome | Which measurable business result will the tool improve? | Value is described only as functionality or theoretical time saved. |
| Ownership | Who owns value, data, cost and ongoing operation? | Procurement, the business function and IT point at one another. |
| Flow | Which handovers disappear and which new ones are introduced? | One local step becomes faster while the overall process becomes more complex. |
| Context | Will customer, case and decision context survive each handover? | Employees reconstruct context from several sources. |
| Control | Are identities, access, risk, portability and exit defined? | The contract is clearer than the route out of it. |
| Evidence | Which baseline and metric will demonstrate value? | Success is defined by usage rather than business impact. |
The test is deliberately more demanding than a conventional feature comparison. An application can be functionally impressive and still weaken the overall system. Conversely, an unremarkable tool can be highly valuable when it simplifies a critical process, preserves context and establishes accountability.
My decision rule is straightforward:
A tool should be scaled only when it improves the end-to-end flow and reduces the total cost of coordination.
Four decisions instead of a blanket clean-up
Once the assessment is complete, every relevant system needs a clear portfolio decision. “We will look at it later” is not a fifth category.
| Decision | When it makes sense | What must happen next |
|---|---|---|
| Keep | The tool creates clear value and fits the target process. | Define the owner, cost, controls and performance measures. |
| Integrate | The specialist capability is strong, but handovers and context are broken. | Design data flows, identities, events and error handling. |
| Replace | The functionality or architecture no longer meets the target requirement. | Plan migration, data quality, user transition and fallback. |
| Retire | Value is redundant, limited or no longer demonstrable. | Archive data, close access, terminate contracts and remove dependencies. |
This decision cannot be made solely by IT or procurement. Finance sees cost, IT sees technical risk, the business function sees capability and users experience daily friction. Only a combined view produces a credible answer.
AI can resolve tool sprawl or accelerate it dramatically
AI lowers the threshold for introducing new capabilities. Teams can buy or create assistants, automations and small applications more quickly. That is positive in principle. Without architecture, the same speed creates a new generation of shadow processes: several assistants with different knowledge, unclear data access, parallel automations and decisions whose origin nobody can trace.
McKinsey reported in 2025 that, among 25 organisational attributes studied, fundamentally redesigning workflows had the strongest relationship with reported EBIT impact from generative AI. Yet only 21 per cent of organisations using generative AI had fundamentally redesigned at least some workflows.5
McKinsey’s 2026 survey reinforces the pattern. Nearly three quarters of the defined AI high performers reported fundamentally redesigning workflows, compared with around one quarter of other respondents. High performers were also more likely to combine deployment with senior leadership commitment, impact measurement and operational discipline.6
The conclusion is not that every company should deploy more AI. It is that AI creates reliable enterprise value only when the flow of work is redesigned. When AI is simply placed on top of a fragmented application landscape, it often automates handovers without removing their underlying cause.
An AI Operating System is not a new super-platform in this context. It is the connecting operating logic: Which processes matter? Which data is authoritative? Which identity may act? Where must a human decide? How is impact measured? Who remains accountable?