The systems integrator decides whether your ERP program succeeds, and it is a separate choice from the software. The SI is 40 to 60% of implementation cost, per ERP Research, so on a $6M implementation one firm holds $2.4M to $3.6M and most of the delivery risk. Choose it on the named team you will actually get, not the logo on the cover. Require references of your size, industry, and scope; a rate card by role rather than a blend; any AI saving written into the hours table; named key personnel you must approve before replacement; and a contract that splits fixed-fee from time-and-materials by scope certainty. This guide is the full method, from the three kinds of integrator to managing the one you pick.
The SI decision is separate from the software choice, and usually bigger
Buyers spend months choosing the software and days choosing the SI. The money runs the other way. Implementation services are 1x to 3x the first-year subscription, per ERP Research, and the SI takes 40 to 60% of the services spend. On a program where the software subscription is $1.5M a year, implementation runs $1.5M to $4.5M, and the SI's share is $600,000 to $2.7M. The SI is the largest single line in almost every program.
It is also the line that carries the risk. The software works the same whoever installs it; the difference between a program that goes live on its business case and one that does not is design quality, data discipline, test coverage, and whether the business was carried through the change, and all four are delivered by people, most of them the SI's. Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will fall short of their original business case goals. Most will go live on working software; what they miss is the case, and the case is delivered by the team.
So run the SI selection as its own competition, with its own criteria and scoring, after the software is chosen or in parallel with the final two. A firm that is excellent on Oracle Fusion Cloud ERP may be thin on Infor CloudSuite, and the reverse holds, so the right SI is specific to the product, the industry, and the size of program you are running.
Three kinds of integrator, and when each one wins
Three kinds of firm implement ERP, and they fail and succeed in different ways. The right one is whichever matches your program's largest risk.
| Kind | Best fit | Where it struggles |
|---|---|---|
| Global firm | Multi-country tier 1, many legal entities, heavy change management | Named experts roll off after the sale; junior-heavy delivery at a senior blend |
| Boutique | Single product, one to a few countries, deep configuration | Thin bench if a key person leaves; limited surge capacity |
| Vendor professional services | New products, net-new modules, first reference customers | Smaller delivery capacity than a dedicated SI; incentive to protect the software |
The global firm
The global firm wins the large, complex, multi-country program. If you are rolling tier 1 software across ten legal entities in six countries with their own statutory reporting, you need a firm that can staff that breadth, has done it before, and will still exist in five years. Its weakness is the one the companion article on reading an SI proposal names first: the senior experts who win the work often roll off within the first weeks after go-live, replaced by juniors you are still billed for at the blended rate. The defense is the named-personnel clause later in this guide, and you need it most here.
The boutique
The boutique wins the single-product, one-to-a-few-country program where configuration depth matters more than scale. A firm of 40 people who do nothing but NetSuite, or nothing but Epicor Kinetic, will often out-deliver a global firm on that product at a lower rate, because their consultants configure it every week. The risk is bench depth: a boutique that loses your lead architect may not have a second one, so the churn clause and a named backup matter more here than surge capacity. For a tier 2 program of 6 to 18 months on one product, the boutique is frequently the better bet.
The vendor's own professional services
The vendor's professional services arm wins where the product is new, the module is net-new, or you are an early reference customer. On a recently released product, the vendor's own people have seen more of it than any independent SI and can reach the product engineers when something breaks. The trade-off is capacity and incentive: the vendor's team is usually smaller than a dedicated SI's, and it has a reason to protect the software's reputation rather than tell you the module is not ready. Use it for the genuinely new parts, and an independent SI for the well-trodden ones.
Evaluate the named team, not the logo
The proposal is signed by a firm; the work is done by a team, and the gap between the two is where most SI disappointment lives. A firm's brand tells you it has delivered programs like yours. It does not tell you that the specific architect, functional leads, and data lead assigned to you have. Evaluate the second fact, not the first.
Ask for the named team before you score price. For each lead role (program manager, solution architect, each functional lead, data lead, integration lead, test lead), require a one-page record: how many full implementations of this product they have led, in what industries, at what size, and when they can start. Then interview the three who matter most (program manager, architect, data lead) the way you would hire them, because for the length of the program you are. A firm that cannot produce those people at interview has told you the people in the room at the sale are not the ones who will do the work.
Pin availability to a date. The strongest-looking team is worthless if the architect is committed elsewhere until two months after your design starts. Require the named leads to confirm start dates and their time committed to you, in writing, and make any change to those names subject to your approval. The site's recommended rule is that the program manager, architect, and data lead are each committed at least half-time through design and that none can be replaced without your written sign-off.
References of your shape, and the 15 questions worth asking
A reference is only useful if it matches your shape on three axes: size, industry, and scope. A firm that implemented tier 1 software at a $5B manufacturer tells you little about your $400M distribution business, and a finance-only rollout tells you little about your plant-floor program. Require two or three references that match you on all three, and speak to the customer's sponsor and process owners, not the account the SI hand-picks.
Work through these 15 questions on the call. The answers on overruns, team churn, and change orders are worth more than any score in the proposal.
- What was the original budget and the final cost, and what explained the gap?
- What was the original go-live date and the actual one?
- Were the named people in the proposal the people who did the work?
- Did any of the key people (program manager, architect, data lead) change during the program, and when?
- How many change orders were raised, and what triggered the largest three?
- Who owned data cleanup, and was it budgeted correctly at the start?
- How many integrations were scoped, and how many did you actually need?
- How many test environments and test cycles were planned, and how many did you run?
- Were the designs signed by your business process owners or by IT delegates?
- How did the SI behave when something went wrong, not when it went right?
- If the SI made AI or tooling efficiency claims, did they show up as lower hours or lower cost?
- What did the SI get wrong, and how did they put it right?
- Did the business get the people it was promised, backfilled from day jobs, or not?
- Knowing what you know now, would you hire this SI again, and for which parts?
- What should we insist on in the contract that you did not?
Call the references the SI gives you, then find one it did not, reached through your own network or a user group. One honest unlisted reference is worth five polished ones.
Rate-card transparency and the junior-senior mix
A price is a count of hours times a rate. A single blended rate hides the lever the SI controls most: the mix of junior and senior people behind the blend. Require a rate card by role and the hours by work package, so you can see both halves of the number, because you cannot negotiate a price whose structure you cannot see.
The ranges set a reference point. KORE1, a staffing firm, puts 2026 boutique SI rates at $200 to $325 an hour or more for SAP work, $150 to $275 or more for NetSuite, and $150 to $250 for Dynamics 365, with one of its own pages showing less senior roles at $90 to $175. These are confidence C figures from a firm that sells staffing, and KORE1's pages disagree with each other, so treat them as directional ranges, not fixed prices. What matters is the spread inside each product: the top of the range is roughly 1.5x to 1.7x the bottom, and that gap is the junior-to-senior split the blended rate conceals.
Consider a $4M fixed fee built on 20,000 hours at a blended $200. That blend could be 30% senior at $300 and 70% junior at $130, which costs $181 an hour to deliver. The $19 gap across 20,000 hours is $380,000 the blended rate never shows. The point is not that margin is wrong; it is that you cannot negotiate what you cannot see, or tell whether the senior people you interviewed are in the senior rows. Ask for the mix, ask which named people sit in it, and ask what happens to the rate when a senior leaves and a junior takes the seat.
Make every AI claim appear in the hours table
Every SI now claims AI cuts its effort, and the claims almost always sit in the sales deck as a percentage, not in the price as fewer hours. A saving that is real reduces the hours in a work package; a saving that is marketing stays a slide. The rule the site recommends is to treat any AI claim with no hours delta by work package as worth zero in your price comparison.
The arithmetic bounds the claim before any agent runs. SI fees are 40 to 60% of implementation, so even a 50% cut in SI effort is worth 20 to 30% of the budget at most, and only if it shows up as fewer billed hours. The McKinsey projection from May 2026 is "at least 50%" with conditional wording and no completed program behind it; BCG, in April 2025, put it lower at 20 to 40%. Both describe the SI's hours, not your budget. Worse, agents remove junior hours first, so the blended rate rises and the price drops by less than the hours do. The companion article on why the quote has not moved traces that in full.
Two contract moves convert an effort claim into a price saving. Put a blended-rate cap at or below the bid's starting rate, so the SI cannot hold the price up by shedding juniors and keeping the mix senior. Fix-price the packages the agents touch most, usually testing and documentation, so the SI carries the risk if its tooling underperforms. And write a re-baseline point at the end of design, when the SI has run its agents on your configuration and the saving is either visible or gone. Design is only 10 to 20% of implementation hours and sits at the front of the program, so that proof arrives early.
The SI RFP and how to score it
The SI RFP is a different document from the software RFP. It asks for a team, a price structure, references, and a contract position, not a feature list. Keep it short and demand depth: a named team with records, hours by work package, a rate card by role, two or three references of your shape, a position on each key contract clause, and any AI claim expressed as hours removed. A ten-page RFP that demands those six things tells you more than a hundred-page one that demands none of them.
Score it on a fixed weighting agreed before the proposals arrive, so the loudest brand does not pull the result. The weighting below is the site's recommended default; shift it toward references and team for a complex program, toward price structure for a well-understood one.
| Criterion | Weight | What a strong answer looks like |
|---|---|---|
| Named team and their records | 30% | Named leads with product, industry, and size experience, available on your dates |
| Price and hours transparency | 25% | Hours by work package, rate by role, the junior-senior mix shown |
| Approach and scope coverage | 20% | Data cleanup, integrations, test environments all scoped, not assumed |
| Contract terms and risk | 15% | Accepts named personnel, replacement approval, and a split of fixed and T&M |
| AI and efficiency evidence | 10% | Any saving written into the hours table, not the deck |
Score the proposals blind to price first, then open the price, so a low headline number cannot distort a team and approach you have already scored. Hold the scoring meeting with the business process owners in the room, not just IT, because they are the ones who will live with the team you pick.
Fixed-fee, time-and-materials, and the hybrid that holds up
No single pricing model fits a whole program. Fixed-fee protects you where scope is firm and punishes you where it is not, because the SI prices the uncertainty into the fee or claws it back through change orders. Time-and-materials protects the SI and exposes you to open-ended hours. The hybrid that holds up draws the line at scope certainty.
| Model | Fits | Risk it creates | Where to use it |
|---|---|---|---|
| Fixed-fee | Firm, well-understood scope | Padding, or change orders when scope shifts | Standard configuration, training, a defined cutover |
| Time-and-materials | Genuinely uncertain work | Open-ended hours, weak cost control | Data cleanup, discovery, integrations to unknown systems |
| Hybrid | Most tier 1 and tier 2 programs | A blurred line between the two | Fixed on the firm parts, T&M with a cap on the rest |
The rule the site recommends is fixed-fee on anything you can specify today, T&M with a not-to-exceed cap on anything you cannot, and the line between them written into the contract rather than left to the SI. The two packages that most often belong on T&M are data cleanup and integrations to systems nobody has mapped, because a fixed fee on either is a fixed fee on a guess that returns as a change order the first time it is wrong.
Named key personnel and replacement approval
The most valuable clause in an SI contract is also the cheapest to write. Name the key personnel, and require your written approval before the SI replaces any of them. Without it, the named experts win the work and roll off within the first weeks after go-live, replaced by juniors you are still billed for at the blended rate. With it, a departure becomes a conversation you control.
Three roles belong in the clause without exception: the program manager, the solution architect, and the data lead. These are the people who hold the program's decisions, and losing them quietly is how a program drifts toward a rescue that runs 30 to 50% of the original budget, per Deliberate Directions, a firm that sells NetSuite rescues, so treat that as a single firm's planning range. The clause costs nothing and protects against the top of it. Pair it with a named backup for each key role, so an approved departure has a successor you have already met.
Write a churn threshold into the governance terms as well. The site's recommended rule is that turnover above 20% in the SI's named roles inside six months, or the loss of the program manager, architect, and data lead inside two quarters, forces a joint review. Structural churn is one of the few conditions that justifies replacing the SI, because at that point you are paying a new team to relearn the work the firm was supposed to retain, whether you switch or not.
The onshore-offshore mix
The blended rate also hides where the people sit, not just how senior they are. An offshore team lowers the rate and can deliver excellent work, but it changes the communication cost, the time-zone overlap, and the rework that lands back on your side. A low blended rate on a complex program usually means a heavy offshore mix, and the saving is real only if the rework does not eat it.
Read the rate against the product. A blended $160 an hour on SAP work sits below KORE1's onshore boutique range of $200 to $325, which tells you the team is mostly offshore before anyone says so. That is not a problem by itself; it is a question. Ask for the onshore-offshore split by role, the daily overlap your team gets with the offshore team, and who owns the rework when offshore output comes back wrong. The design and business-facing roles (architect, functional leads, the people in your workshops) most need onshore presence and time-zone overlap, because a design decision made without the business in the room reopens the moment testing reaches it. Set the expectation in the contract: onshore presence for the named leads through design and integration testing, a stated daily overlap window, and the rework risk on a T&M line rather than a change order.
Red flags
Some signals are worth more than any score, because each predicts a specific later failure. Treat two or more as a reason to widen the field, not narrow it.
- A single blended rate with no role breakdown. The mix is the lever the SI controls most, and hiding it is a choice.
- Roles named but no people ("a senior consultant"). You are buying the team, and they will not show it.
- References that do not match your size, industry, or scope, or a refusal to let you speak to the sponsor rather than the account manager.
- A fixed fee on scope the proposal has not specified, especially data cleanup or integrations to systems nobody has mapped.
- AI efficiency claims in the deck with no matching reduction in the hours table.
- An assumptions page that moves data cleanup, integration count, and test environments onto your books, uncounted.
- Resistance to named-personnel and replacement-approval clauses, which tells you the sale team is not the delivery team.
- A price far below the field with no structural reason, which is a mistake you will pay for in change orders or a bid to win and renegotiate.
None is disqualifying alone. Each is a question the SI should answer, and the answer, or the refusal to give one, is the evidence.
Managing the SI after selection
Choosing the SI is half the work; holding it to the contract is the other half, and the clauses above only protect you if someone reads the records they describe. Three disciplines carry it.
Stand up independent assurance that reports to you, not to the program. The reviewer reads the source records (the weekly defect log, the mock-load reconciliation, the staffing list, and the steering minutes) week to week, so you govern from evidence rather than the status color. The site's recommended budget is 1 to 2% of the program, which on a $6M program is $60,000 to $120,000. Below 1% the review cannot read the records deeply enough to contradict the SI; above 2% it competes with the program for attention. The full method is in the article on independent program assurance.
Govern the named-personnel and re-baseline clauses actively. Check the staffing list against the statement of work every month, so a quiet swap surfaces while you can still refuse it, and hold the re-baseline point at the end of design, where the SI shows actual hours by work package against the bid and the price reopens to match.
Keep the business staffed on its own side. Free the finance, order-to-cash, and supply chain owners at least half-time through design and again through integration testing, and track attendance by name. A design signed by an IT delegate instead of the owner is a decision the business has not made, and it reopens as a change order the moment testing reaches it. If the program does drift, the article on rescuing a program without firing the SI covers the moves that recover it, most of which are governance rather than a new contract.