Will Fixed Prices be the future for ERP rollouts?

Written by Jerome Josephraj | Aug 24, 2026, 12:08:20 PM

The ERP implementation market has priced itself on duration for thirty years. A rollout takes eighteen months, so the Statement Of Work (SOW) or Work Order counts consultants and months, and everyone involved, the customer’s finance director, the SI’s delivery lead, the software vendor’s account manager, negotiates inside that shape. Nobody chose it. It is what you do when nobody can honestly predict how long the work will take, and it has held because the prediction problem was real.

That shape is coming apart, and the reason is not that buyers have become more demanding or that an analyst has declared a new pricing era. The reason is that the parts of a rollout that used to absorb the hours are being done by AI agents in a fraction of the time.

What compresses and what does not

  1. Requirements capture time compresses. A consultant used to sit through a fortnight of workshops and then spend another fortnight turning notes into a structured requirements set; an agent produces the structured set from the workshop recordings and the customer’s existing documents, and the consultant reviews and corrects it.
  2. Test authoring and execution compresses hardest, because writing scenarios from requirements and running them against a live ERP is exactly the work that gains nothing from a human doing it by hand.
  3. Training material compresses: one manufacturer we work with produced over a hundred videos and seventeen courses across four languages before go-live, which is not a volume any training manager would have attempted manually.
  4. Configuration is compressing now, as agents learn to turn a stated requirement into the actual setup in the system.

Plenty does not compress, and anyone claiming otherwise will be caught out on their first real programme. Data cleansing does not, because someone in the business has to decide which of the four supplier records is the real one. Decisions do not, because they wait on the people authorised to make them. Third-party integrations move at the pace of the third party. Warehouse readiness, master data ownership, and the shop floor actually changing how it works on the Monday after go-live are human problems that run at human speed.

So when I say rollouts will be measured in weeks rather than years, I mean the system work: requirements, configuration, testing, training, and the proving of all four. The customer’s own readiness sits alongside it and does not shrink at the same rate. Even so, a programme that reliably took a year now takes a small number of months, and the direction of travel only goes one way.

The problem this creates in the proposal

Here is where it gets uncomfortable for the SI, and it starts long before delivery.

A competitor bids the same scope in four months. You bid twelve. You will not be asked to explain your methodology; you will simply not be shortlisted. So every SI is going to have to put shorter timelines into their proposals, whether or not they have worked out what that does to their own numbers.

What it does, under time and materials, is remove revenue. Fewer weeks means fewer consultant days means a smaller invoice, and the better you get, the less you earn. That is the trap, and it explains why so many implementation partners talk enthusiastically about AI in marketing and move very slowly in delivery. Under an hourly model, efficiency is something you are punished for, short term. Efficient, lower cost, high quality projects will make you win more projects to offset the lower revenue per project - but it’s a scary transition.

 

Requirements is where the rollout becomes predictable

The way out is not to resist the compression. It is to change what is being sold, and the compression itself is what makes that possible.

The reason SIs have historically avoided fixed prices on ERP is that they could not predict their own delivery because of project uncertainty. Scope moved, decisions slipped, testing found things nobody expected in month nine, and any fixed number would have been a gamble dressed up as a quote. That is a fair reason, and it was true.

It is becoming less true. Once requirements are captured and structured — which now happens in weeks, not months — the shape of the remaining work is visible. You know the scenario count. You know the configuration set. You know what has to be tested and trained. Work you can see is work you can price, and a partner who can price it can put a fixed number in front of the customer while everyone else is still quoting rates.

Lower price, higher margin, more projects

This is the part that surprises people, and it is worth stepping through slowly, because the instinct is to assume that a lower price means a worse business.

The customer pays less than they would have under time and materials, and they pay a number that does not move. For a CFO who has been through an ERP programme before, the second half of that sentence may matter more than the first. Every ERP buyer has a story about the change request pile, the overrun conversation in month fourteen, and the budget that ended up somewhere it was never approved. Removing that risk is worth real money to them, independent of the discount.

The SI’s margin goes up at the same time, and this is not sleight of hand. The price falls, but the cost to deliver falls further, because agents are doing the work that consultants used to bill for. As long as delivery cost drops faster than price, margin percentage rises on every project. That condition is the whole game, and it is the number any SI finance director should be modelling before they commit to a pricing change.

Then there is volume. The same consultants, freed from writing test scripts and building training decks, can run more programmes in a year. Lower revenue per project multiplied by more projects can comfortably exceed what the old model produced, and the partner with the shortest credible timeline is the one being invited to bid in the first place.

Customers get a lower, predictable cost. SI gets a better margin and more projects. That is a genuinely better arrangement than the one it replaces, which is rare enough in this industry to be worth saying plainly.

Fixed price is a confidence test

None of this works if you cannot actually predict your delivery, and a fixed price is a public statement that you can.

If the outcome of your configuration work depends on which consultant you assign, you cannot quote fixed, because your cost is a function of staffing luck. If your test cycle takes three weeks when the requirements are clean and seven when they are not, you cannot quote fixed, because you do not control the variance. If your agents work beautifully in a demo tenant and then need a specialist babysitting them on a customer’s real system, you cannot quote fixed either, because what you have is not repeatable delivery — it is a demo with people behind it.

The SIs who will quote fixed and win on it are the ones whose agents behave the same way on the eleventh project as on the first. That is a much higher bar than having agents at all.

What we expect to happen

Our view is that the system work in an ERP rollout compresses to weeks, that shorter timelines in proposals force the pricing conversation whether partners are ready or not, and that fixed price stops being a risk to avoid and becomes the way the market buys.

The winners will not be the SIs with the most AI agents. Everyone will have agents. The winners will be the ones with the fewest surprises, because only they can name a price and a date and be right. That confidence is not bought in a procurement cycle or announced in a press release. It accumulates, go-live after go-live, edge case after edge case, until predicting your own delivery stops being a gamble and starts being arithmetic.