Businesses never wanted software products
The software inventory of a typical company is a museum of purchases nobody wanted to make. What people wanted, every single time, was one business.
The inventory nobody chose
Walk through how any company actually acquired its systems. The CRM arrived when the sales team outgrew a shared inbox. The accounting package was whatever the auditor recommended in 2011. The warehouse module came bundled with the ERP, the project tool came with a new manager who could not live without it, and the BI layer was bought to glue the reporting together after the first five stopped agreeing with each other.
Every purchase was rational. Someone had a real problem, evaluated real options, and picked a defensible one. Nobody made a mistake, and the sum is still something no one would ever have designed on purpose: a dozen half-connected products, each holding a fragment of the truth.
The inventory was assembled by accretion, not by intent. That distinction is the whole principle.
What each purchase was actually buying
Nobody wakes up wanting a CRM. They want to remember what a customer said last month and what was promised to whom. Nobody wants an ERP — they want orders to flow into production without a phone call. The software product was never the want; it was a proxy for the removal of a business problem.
This sounds obvious, and its consequence is routinely ignored: when you buy outcomes through products, you inherit everything the product decided for you. Its data model, its borders, its idea of what your industry does. You wanted one outcome and you received an opinionated system that delivers the outcome plus its own worldview.
Multiply that by every problem the company solved this way, and the worldviews start colliding.
The patchwork tax
The collisions have a running cost. Duplicate entry, integration projects that never quite finish, one management report that requires exports from three systems and an afternoon in a spreadsheet. Every seam between products is staffed by a human doing synchronization work that nobody's job description admits to.
The strongest counterargument deserves its say: best-of-breed advocates hold that a specialized tool beats a generic suite at every single job, and they are right — at the job. But the business does not experience jobs one at a time. It experiences the seams, and no amount of per-job excellence pays back what the seams cost.
One business, one system
The unit of software should match the unit of operation. The unit of operation is the business — not the department, not the vendor's product category.
One system does not mean one monolith bought from one giant vendor. It means one coherent whole: one data model, one set of workflows, one place where the truth lives — assembled to fit the specific business it serves. What that covers in practice is a catalog question, and the catalog is public.
People want one business. The software should finally agree.
See what one system covers