Cosa succede quando l'azienda evolve più in fretta del software?

The business acquired a second company in March. The integration plan was clear. The operational integration plan was not.

The acquired business ran on different margin structures, different approval thresholds, different payment terms with suppliers, and a service delivery model that the acquiring company's ERP had no concept of. The system didn't break. It just became increasingly fictional.

The finance team started maintaining a second set of records in a spreadsheet for the acquired entity. The operations team built a manual process to handle jobs that crossed between the two businesses. The reporting pack became a manually assembled document rather than a system export. Three months after acquisition, the ERP modelled one business. The actual business was something different.

This is what happens when a business evolves faster than its software. Not a crisis. A slow accumulation of workarounds, manual exceptions, and operating processes that live outside the system — until the system is no longer a system of record. It is a legacy record of how things used to work.

The Common Belief

Software systems are investments. Once implemented, they serve the business for five to ten years with periodic updates. If the business changes significantly, the system can be adapted through configuration changes or upgrades.

Most business leaders accept this. They know systems are not infinitely flexible, but they believe that the cost and effort of keeping a system aligned with business evolution is a manageable ongoing expense.

Why That Belief Is Wrong

The assumption that systems can be adapted to match business evolution at reasonable cost and speed is wrong for most enterprise software, for the reasons explored elsewhere in this series: change requests are expensive, they take too long, and the vendor's expertise is required for modifications that should be operationally routine.

But the more fundamental problem is not cost. It is lag.

Between the moment the business changes and the moment the system reflects that change, there is always a gap. In a fast-moving business, that gap is never zero. The business is always slightly ahead of the system's model of it. Most businesses manage this gap with workarounds.

Workarounds do not close the gap. They widen it. Because every workaround is a process that runs outside the system — outside the audit trail, outside the approval logic, outside the data model. The system's model of the business becomes progressively less accurate. The workarounds become progressively more load-bearing. The gap becomes structural.

What Actually Happens

Business evolution takes many forms: new markets, new services, acquisitions, regulatory changes, structural reorganisations, pricing model changes, new customer segments, new channels. Each form of evolution changes some aspect of how the business operates.

For each change, the organisation faces the same sequence:

1. The business starts operating in the new way.
2. The system does not yet reflect the new way.
3. A workaround is created to bridge the gap.
4. A change request is submitted to make the system reflect the new way.
5. The change request takes weeks or months to deliver.
6. By the time the change is delivered, the business has evolved again.

The workaround, which was meant to be temporary, becomes permanent because the change request window never catches up with the business reality. The gap between system and business accumulates layer by layer.

Larger changes — acquisitions, pivot to a new service model, major regulatory changes — create larger gaps that require more significant system changes. These changes are not just expensive. They sometimes reveal that the system's architecture cannot accommodate the new business model at all.

When that happens, the business faces a choice between a major reimplementation — effectively starting again — or an increasingly elaborate workaround infrastructure that runs in parallel with a system that is now largely decorative.

Real-World Example

Company: Northgate Advisory Group
Industry: HR and employment law consulting
Size: 85 staff, £14.2M revenue
Problem: Business pivot created an irreconcilable gap between operating model and system

What happened:

Northgate had operated for eight years as a project-based consultancy, billing clients on a day-rate basis. The ERP was configured for this model: projects, timesheets, day-rate invoicing, project profitability reporting.

In 2023, the business pivoted to a subscription model. Clients paid a fixed monthly fee for retained access to advisory services, with usage tracked against agreed call limits. The model was commercially successful — recurring revenue made the business significantly more attractive to investors.

The ERP could not model it. The project-based architecture — projects, phases, resource bookings, day-rate billing — had no concept of a subscription with a monthly fee and a usage allowance. The billing module could not generate invoices in the required format. The profitability reporting was meaningless because it was designed around project margins, not subscription unit economics.

Northgate raised a change request. The vendor assessed it and proposed a customisation that would add subscription billing functionality to the existing platform. Cost: £94,000. Timeline: five months.

Outcome:

The business declined the customisation. The cost was acceptable; the five-month timeline was not — the subscription model was already generating revenue and the billing process needed to work immediately.

Instead, Northgate used Stripe for subscription billing, maintained client usage tracking in a spreadsheet, and attempted to reconcile the two with Xero at month-end. The ERP became the system of record for the legacy project work and was progressively abandoned for the growing subscription business.

Eighteen months after the pivot, approximately 60% of Northgate's revenue ran through systems that were not the ERP. The ERP licence continued to cost £42,000 per year. It modelled a business that no longer existed.

The Cost of Ignoring It

Direct cost: The cost of operating with misaligned systems is borne in manual processes, reconciliation overhead, and change request fees. For a business with significant operational complexity, this typically runs to 3–5% of revenue annually.

Reporting degradation: When the system does not model the business accurately, reporting cannot be trusted. The board pack becomes a manually assembled document. The investor update requires manual preparation. The management team makes decisions on data that does not reflect current reality.

Audit risk: An ERP that does not reflect how the business actually operates creates audit complications. The auditor's questions cannot be answered from the system. Reconstructing activity from manual records takes time and creates exposure.

Growth constraint: Investors and acquirers value businesses with clean, scalable operational infrastructure. A business with a widening gap between its operating model and its system model is not investable at the valuation the business case deserves. The system gap becomes a due diligence problem and a valuation discount.

Team impact: Operational staff who work daily with systems that do not match how they are asked to work become frustrated, inventive in unhelpful ways, and eventually leave. High-performing operations people do not stay in environments where their job is to fight infrastructure.

What Good Looks Like

Systems that stay aligned with business evolution share a common architectural property: the system derives from a business model, and changing the business model changes the system.

This is the inverse of the standard enterprise software architecture, where the business is expected to operate within the constraints of a fixed system.

In practice, staying aligned requires:

Version control for the business model. The same way code changes are tracked in a repository, changes to how the business operates should be tracked in the system. What changed, when, who approved it, what was the previous state. When the business evolves, the evolution is recorded.

Change in TEST before PROD. Business model changes should be validated in a test environment before they affect live operations. A pricing model change, a new service line, a new approval hierarchy — all should be tested against real business scenarios before they go live. The cost of getting a change wrong in production is disproportionate to the cost of catching it in test.

Fast change cycles. If changes that take minutes to specify take months to implement, the system will always lag the business. The gap between business intent and system reality needs to be measured in days, not months. This is why enterprise software costs more to change than to buy — the change cost is structural, not incidental, and it compounds with every month the business outpaces the system.

No change request dependency. The business should be able to make operational changes — workflow adjustments, approval hierarchy changes, new service configurations — without depending on vendor expertise. The system should encode business logic in a format the business controls. The businesses that feel this most acutely are growing businesses that have already outgrown one software stack — they know what change dependency costs because they have already paid it.

ENTMAZ Perspective

The gap between business evolution and system evolution is a design problem, not a management problem. It exists because enterprise systems store their business logic in a format that only the vendor can modify.

ENTMAZ's architecture starts from a different assumption: that the business model is the source of truth, and the system is derived from it. When the business evolves, the business model is updated. The update is compiled, validated in TEST, and promoted to PROD. The system reflects the new reality.

This is not incremental configuration management. It is a different relationship between business and system. The business model is not an artifact of the implementation. It is a living document that drives the system. When it changes, the system changes with it — not in months, and not through a vendor's change request process.

The gap closes because it is architectural, not procedural.

Conclusion

Businesses evolve constantly. Software systems evolve slowly, expensively, and with a dependency on vendor expertise that the business cannot control.

The gap that results is not a systems failure. It is the predictable output of an architecture where the business logic is stored in a format the vendor owns. Every workaround is evidence of that gap. Every manual process that bridges the system's model and the business's reality is a cost that does not appear in the original business case.

The businesses that manage this well are not running better projects. They are running systems that were designed to evolve with them.

Key Takeaways

• The gap between business evolution and system evolution is structural — it is produced by an architecture where business logic is vendor-owned and vendor-modified
• Workarounds do not close the gap — they widen it, creating load-bearing manual processes that run outside the audit trail and data model
• A system that does not model the business creates reporting degradation, audit risk, and investment valuation discounts
• Staying aligned requires systems where the business model is the source of truth and changes to the model are reflected in the system — not through change requests, but by design
• Fast change cycles, test-before-production, and version-controlled business logic are the structural properties of systems that evolve with the businesses they serve