Making it fit: Does your software fit the way your business actually works?

The idea of software fit

Systems return value when it works well with the sequence your business runs in. They return very little when your people have to work around it, and the working around is where the cost hides. Almost no company can judge fit at the point of purchase, because the process written in the requirements document is not the process the business runs. The real one lives partly in software, partly in spreadsheets, and partly in the heads of people who have been there long enough to know the exceptions.

Fit is measurable before you buy anything. The measurement already exists in your operation: the spreadsheet maintained beside the system of record, the approval that happens over email because the workflow in the software routes to the wrong person, the report someone rebuilds by hand every month. Each one marks a place where the software and the work diverged. Read them first. Then decide what to buy, configure or build.

Hidden behind the demo

Ask the finance lead at a growing manufacturing company to walk you through how a customer invoice gets produced, and watch how many applications the answer touches. The order arrives in one system. Pricing gets checked against a spreadsheet because the contract has tiers the software cannot pull data. Someone confirms the shipment in a second system, then keys the quantity manually into the first. The credit exception goes to the owner over text, because the approval chain in the software routes to a manager who left in 2023. The invoice comes out correct, because four people know the exceptions, which the system does not.

That company owns an ERP. On paper, it runs order-to-cash. In practice, it runs order-to-cash with six undocumented interventions, and nobody has written them down, which means nobody can specify them to a vendor.

"The premise of enterprise software was that you find the platform closest to how you operate and absorb the difference. Businesses absorbed the difference in spreadsheets and in people's heads, then called the project a success. The system worth having is the one that holds the exceptions instead of exporting them to your staff" says Anand Krishnan, CEO, thinkbridge, on his blog Meaningful Tech.

Fit determines whether software adds value, and fit is the property no evaluation looks for. This is the question that precedes the choice a business has to make for software. Three things make the case: the process a company documents diverges from the one it runs, which is a measured finding rather than a suspicion; the workarounds that fill the gap are legible evidence a business already holds; and the cost of misfit lands in attention and rework rather than on the software invoice, which is why nobody counts it. A closing section covers where chasing fit becomes the wrong instinct.

Documented process and the process running are two different things

Conformance and compliance checking exists as a formal discipline because the gap between the documented process and the executed one is standard. Process-mining tools compare a target process model against what the event logs in your systems show people did, and the reason a market grew up around that comparison is because the two rarely match. In a Gartner forecast circulated widely by vendors in the category, and directional for that reason, expected 80 percent of organizations to embed process-mining capability in at least a tenth of their operations. This was driven by the search for deviations that were never mapped.

The academic literature on process mining draws a distinction worth studying. Some deviations depart from a written process script. Others happen in businesses where no adequate script exists, and people execute work from mental models built out of their own experience and judgment. Case research on small and mid-sized companies documents exactly the second condition: process specifications missing or incomplete, the operating knowledge held by individuals, and a separate spreadsheet system running alongside the ERP with no integration between them. Researchers also found activities performed by whoever was closest to the problem rather than the role the process assigned, with buyers and planners closing orders that administrative staff were supposed to sign off.

None of that is dysfunction. It is how a business absorbs the distance between generic software and its own operation. The consequence is specific: when a company writes requirements for its next system, it describes the process it believes it runs. The divergences are invisible to everyone above the people performing them. It then buys software against that description and rediscovers the discrepancies during rollout, one at a time, as change or customization requests.

Workarounds are the requirements document never written

By definition, a workaround is solving a problem. Someone identified a gap between what the software permitted and what the work required, then built a mechanism to bridge it. That mechanism carries information: missing fields, owner and approval mapping, chain of command for approval and flyby calculations the system cannot hold. Read as a dataset, the workarounds in a business describe the operating model accurately than any process diagram in a shared drive.

Companies treat this as a hygiene issue to be trained away. But they are instrumentation, and they cost nothing to collect. The answer lies in walk through the process, listing the interventions, and asking what each one indicates.
‍

The drill is to run such a checklist before a vendor conversation rather than during implementation. Companies that do it usually find two things at once:  

• Their real functional footprint is narrower than any commercial platform's feature list.  ‍
• The functions they most want to preserve are the functions where every platform demands the heaviest customization.

Distinctiveness and poor fit describe the same property from two directions.

Feature comparison cannot detect misfit

Software capability is described in its list of features.  The actual test of the software performing those functions in the order your business performs them, with the expected exceptions, is never recorded by comparison matrix. Selection becomes a contest between demo, and a demo is a rehearsed path through a successful case. The gaps come to light when the work meets the system.

Panorama Consulting Group's 2026 ERP Report, published in March, found that more than a quarter of organizations exceeded their project budgets, and named additional technology needs as the leading cause. The firm's own consultants describe the mechanism. In the words of senior client services manager Chris Devault, “Organizations often discover fatal misfits late in the project and respond with additional technology, expanded scope and custom builds”. The knee-jerk instinct to buying more software to compensate for software that did not fit, at a point when the contract was signed, means the negotiating position was gone.

Broader implementation data points the same way, with the caveat that most of it circulates second hand. Analyst estimates put the share of ERP implementations that miss their original business objectives somewhere between 55 and 75 percent, and industry compilations put the average implementation at roughly 17 months against the 12 most organizations plan for. Treat the range as directional. The direction has held for two decades.

The cost is paid for by attention and time

Misfit rarely appears as a line item, which is why finance never flags it. It appears as work about work.

Research published by the Harvard Business School indicates that workers toggle between applications up to 1,200 times each day, spending nearly 9% of their work year in transition. Over a year that runs to roughly five weeks per employee. Some of that toggling is unavoidable. The portion that exists because one process runs across four systems the result of a purchasing pattern, and the cost is paid by the people doing the work along with the budget line item in the TCO.

The licensing waste is easier to see and gets more attention. Zylo's 2026 index puts the share of SaaS licenses that go unused or underused above half, with the average enterprise spending around $21 million a year on software nobody opens. Unused licenses are the visible residue of a misfit purchase. The invisible cost is the manual work: data reconciliation and institutional memory required to keep a process running across tools that were designed to do two different things.  

Automation works only if the fit is right

The argument for fit used to be efficiency, which made it easy to defer. Automation changed its status.

McKinsey's April 2026 account of AI-native software delivery is direct about what agents require before they produce anything reliable: structured requirements, clear user stories, unambiguous acceptance criteria, and rich context including data models, service boundaries and business rules. Agents cannot imply business intent. The firm's summary of the failure mode is that good output comes from good context rather than clever prompting.

A business that has never mapped how its work happens cannot supply that context. It holds the operating knowledge in spreadsheets and in individual judgment, which is precisely the form an AI agent cannot read. Companies in this position tend to conclude that AI did not work for them. Actually, it did not work because it was automating a process nobody had described.

Where fit isn't a prerequisite

Fit can be pursued past the point of value, and the failure mode is worse than buying generic software.

Some processes run the way they run for no defensible reason. Workarounds can encode an old policy, a departed manager's preference, or accommodate for a system that has since been retired. Building software around those factors is a way of making an accident permanent. And purpose-built systems make bad processes durable in a way spreadsheets never do. For a commodity function, adopting a vendor's standard model is often the better decision, because the vendor has seen the process ten thousand times and your version carries no advantage.  

The distinction lies between exceptions that have strong reason to exist and exceptions that merely survived. For example: pricing rule that reflects how you win contracts belongs in the system. But a three-step approval invented to compensate for a report nobody trusted belongs in a decision about whether to keep it or not. Sorting one from the other is the work, and it happens during discovery, or it never happens.

That sorting also determines what to do next. Some findings point to configuration, others to a narrow purchased tool, and the ones touching how the business competes point toward a system built around the operation. That path leads to making a build or buy decision. It becomes tractable once fit has been measured, and unanswerable while it has not.

Making the right decision

Software returns are directly proportional to how well it complements the business running on it. Businesses evaluate capability, negotiate price, and discover fit during rollout, at the point when the only remaining instrument is a change order or a customization request. Panorama's finding that the leading cause of budget overruns is buying additional technology is the aggregate of that operation, repeated across every industry.

The correction is not very aesthetic. It requires deep observation of the work before specifying the system. Treat every spreadsheet and side-channel approval as a finding to reckon. Decide which exceptions describe how the business competes and which ones merely persisted. When a company that does this arrives at a vendor conversation with a specification drawn from its own operation. That only position from which the right decision about fit can be made.  

Building a system that is grounded in a mapping the operating layer is the substance of what thinkOne does. Talk to us to know how to find the right fit for your operating layer.