ERP Implementation Team Structure: Roles You Actually Need

Last updated: August 25, 2026

By Mike Carter, Director of Partnership Success, KORE1

An ERP implementation needs seven filled seats, and only three of them are full-time. Executive sponsor, project manager, solution architect, data lead, one process owner per in-scope area, a test owner, and the administrator who runs the system after go-live. Everything else on the org chart is one of those seven wearing a second hat.

A distribution company outside Fontana sent us their project org chart last spring. Twenty-two names on it. Boxes, dotted lines, a color key.

Two of those twenty-two had the ERP project written into their goals for the year. Two. The other twenty were, in the words of the VP who built the deck, involved.

Involved is not a staffing level. It is a feeling. And it does not show up when somebody has to decide whether the new system keeps the legacy part-numbering scheme or finally kills it. That decision sat open for eleven weeks. Go-live moved twice.

Nobody was lazy. The chart just described attendance instead of ownership, which is the most common thing wrong with an ERP staffing plan before anyone has written a single requirement.

So here is the version we use when a client asks how much of their own team to free up. Which seats can they rent? That question comes second.

The Seven Seats, and the Three That Are Actually Full-Time

Every ERP project, whether it lands on NetSuite, SAP S/4HANA, Dynamics 365, Oracle Cloud, or Epicor, resolves down to the same seven functions. Same seven, every time. The platform changes the skill profile. The shape of the team holds.

Three of those are full-time: project manager, solution architect, and the data lead during the migration stretch. Three, not seven. The rest are real jobs held by people who also have day jobs, which works fine as long as the percentage is written down somewhere a manager can see it and staff around it.

Percentages that live only in a kickoff deck are not commitments. They are wishes with a number attached.

A Steering Committee Is Not the Governance Layer

Of everything on this list, sponsorship is the part that most reliably decides the outcome. Prosci’s benchmarking research puts projects with extremely effective sponsors at 79% likely to meet their objectives, against 27% for projects with extremely ineffective ones. Sponsorship has topped their list of success contributors in every benchmarking cycle since 1998.

Which is why it is strange how often the seat gets filled by a group.

A steering committee of nine directors is a communication forum. Useful, genuinely. It is not a decision-making body, because nine people with equal standing and unequal exposure to the outcome will not settle a fight about whether Finance or Operations owns the item master. Somebody has to lose that argument and stay on the project afterward, and only a person with budget authority over both departments can make that happen.

One name. Enough seniority that the loser of the argument does not escalate. Enough calendar to show up weekly rather than at phase gates.

The tell that you have the wrong sponsor is quiet. Meetings end with an action item to align. Same topic, three weeks later. More slides.

How Many People This Actually Takes

The question underneath the org chart is almost always headcount. Below are the planning ranges we work from before a client has picked a partner. Treat them as a starting point for a conversation with your partner, not as a survey result.

Two things drive the internal number more than revenue does. Process count. And whether anyone has bothered to write those processes down. A $60M manufacturer with eleven in-scope processes and no written procedures will need more internal time than a $200M distributor running four clean ones.

Backfill is the line item that gets cut. Always first. A process owner at 30% is a person doing 130% of a job unless somebody covers the other part, and the cheapest fix is almost always a contract resource holding the day job for nine months while the permanent employee does the project. Companies resist this because the contractor looks like an added cost against the ERP budget. The alternative is a burned-out controller who quits in month seven. That costs more. It also lands in a different budget, where nobody ever connects it back.

The Roles That Are Mostly Theater

Now the part the vendor org chart will not tell you.

The ERP champion with no decision rights. Every deck has one. Enthusiastic, well-liked, genuinely helpful at demos. If the role carries no budget and no authority to settle a process dispute, it is a communications role, and it should be named as one so nobody mistakes it for ownership.

Super-user councils that meet monthly are the same problem wearing a bigger hat. Twelve people, one hour, no decisions, minutes circulated. We have watched two of these run for a full year alongside a project and produce nothing that changed a configuration. Not one setting.

Then there is the second project manager. Your partner brings one. That person manages the partner’s scope, hours, and margin, and they are usually good at it. They are not accountable to you for your outcome, and the moment a decision requires trading your internal politics against the schedule, they cannot make it. We wrote a whole piece on the seat that owns the change log, because the ERP project manager hire is the one companies most often assume is covered when it is not.

A dedicated full-time communications lead at a 40-person company is the fourth one. At 4,000 people the role is essential. At 40, the sponsor sends an email. That covers it.

Keep those people on the project. Just make the org chart show what each one actually decides, because a box that decides nothing gives everyone the comfortable impression that a seat is filled.

Somebody Has to Be the Author of Record for AI-Assisted Configuration

This seat did not exist on an ERP org chart three years ago. It does now. Almost nobody staffs it deliberately.

SuiteScript, ABAP, X++, integration mappings, and report logic are all being drafted with AI assistance on live projects right now. No problem there, yet. It becomes a problem the moment an auditor, a customer quality team, or your own CFO asks who wrote a piece of logic and whether anyone understood it before it shipped.

The governance model that holds up under that question is written down in a change-control procedure we reviewed from a consultancy doing regulated NetSuite work. Three provisions matter for staffing.

A named qualified person is the author of record for every deliverable. AI output is draft material, never a deliverable, and the named author has to be able to explain any part of it to an auditor without reference to the tool that produced it. Where they cannot explain a passage, the rule is that it gets rewritten rather than kept.

Review before merge is mandatory, documented, and performed by a qualified person other than the author of record.

Validation and test deliverables that exercise AI-assisted code are authored by a person, and not the same person who built the thing under test.

Read those three as headcount. The implication is blunt. A build team of one cannot satisfy its own review control. If your entire technical bench for this project is a single developer, whether they are yours or the partner’s, you do not have a governance gap you can close with a policy document. You have a second seat to fill.

Most mid-market companies are not in a validated environment and do not need protocol-level rigor. The author-of-record rule still travels. It costs nothing. It survives turnover. And it is the difference between an integration somebody owns and one that merely exists.

Name a Backup for Every Seat Before Kickoff

Large IT programs have a well-documented tendency to end badly. The McKinsey and University of Oxford study of more than 5,400 IT projects found that large ones ran 45% over budget and 7% over schedule while delivering 56% less value than predicted. That research is over a decade old now and those numbers still get quoted, mostly because nobody has produced friendlier ones.

Key-person risk drives a large share of that. Almost nobody manages it.

The best-run engagement document we have read on this handles it with three provisions, none of which cost money at kickoff and all of which are worthless if added later. Roles are named in the plan before work starts, each with a named alternate. Work product, meaning specifications, the traceability matrix, test protocols, the regression set, and the administrator runbook, is held by the organization under version control rather than by individuals, so a replacement inherits a working document set instead of starting over. Knowledge transfer is scheduled as a deliverable in its own phase rather than treated as a courtesy at the end.

One line from that document has stuck with us, and we now repeat it to clients. They would not hold a schedule commitment that depends on one person being available every week for nine months without saying so out loud.

Say that part out loud. Then go find the alternate.

Two seats deserve named alternates above all others. The solution architect, because that knowledge is the least written down. And the data lead, since migration work concentrates into a few brutal weeks where losing the person who knows which legacy fields lie to you is close to unrecoverable.

Ninety Days After Go-Live the Team Shrinks, It Does Not Disband

The most expensive staffing mistake in ERP is not a missing architect. It is a calendar error. Treating go-live as the end of the project rather than the middle of it.

Hire the day-two administrator roughly 60 days before cutover, so they sit through user acceptance testing and watch the configuration decisions get made. An administrator who joins in week two of hypercare inherits a system nobody can explain, and by that point the partner’s build team has rolled off to the next client and their answers have started arriving in days rather than minutes.

The steady-state team after go-live is usually smaller than clients expect. One administrator, the sponsor at a much reduced commitment, process owners back to their day jobs with a standing monthly session, and a defined escalation path to whoever owns integrations. That is the whole team. For most mid-market companies, anyway.

Budget for the seat properly. The Bureau of Labor Statistics put median pay for computer and information systems managers at $171,200 in May 2024, with employment projected to grow 15% from 2024 to 2034 against 3% across all occupations. ERP administrators sit below that median in most markets, but they come out of the same shrinking pool, and competition for them is not going to loosen.

We fill IT roles in an average of 17 days across 30-plus US metros, and 92% of the people we place are still in the seat at twelve months. The day-two administrator search is the one clients most often start too late, and it is the one where starting late costs the most, because you end up hiring under pressure with a live system and an unhappy user base.

If the go-live window sits inside 90 days and nobody has opened that req, that is the thing to fix this week. Not the org chart.

Questions That Come Up While the Org Chart Is Still a Draft

Can our IT director just run this on top of their day job?

Almost never. The failure is predictable. An ERP project needs 30 to 40 hours a week of coordination during design and build, and an IT director already has a full week of operational work that does not pause. The realistic options are backfilling the operational half with contract support, or hiring a dedicated project manager for the duration. Doing neither produces a project that moves only during the hours nobody else needs the IT director, which is usually evenings.

Our partner says they will handle the whole team. Should we believe them?

Believe them about the build. Do not believe them about the decisions. A partner can supply the architect, the developer, the data engineer, and their own project manager, and a good one will. What they cannot supply is the person who decides that the item master belongs to Operations, or who signs off that the trial balance is right. Those seats stay yours whatever the statement of work says. Our piece on implementation partner versus staffing agency covers where the line actually falls.

How much SME time is realistic, honestly?

20 to 40% per process area during design, spiking to near full-time for two to three weeks around testing. The promised number is 10%. Big gap. That gap explains a large share of ERP schedule slippage, and it is visible at kickoff if anyone compares the commitment against the calendar. Ask each SME’s direct manager to confirm the percentage in writing. The ones who hesitate are telling you something useful.

Which seat should we fill first?

The sponsor. Not close. Everything downstream, including how fast you can hire the rest, depends on someone holding the authority to move budget and settle arguments. Second is the project manager. Third is whichever of data lead or solution architect matches your particular mess, and if your legacy data is bad, it is the data lead, no matter what the vendor’s implementation methodology puts first.

We are already six months in and the structure is wrong. Now what?

Fix ownership first. Then add people, if you still need them. Adding headcount to a project with unclear decision rights makes it slower, not faster. Write down who decides what, get the sponsor to sign it, and only then look at where the capacity gaps actually are. In our experience the recovery is usually two hires and one uncomfortable conversation, not a restructure. The six staffing root causes behind failed ERP projects are worth reading against your own chart first.

Do we need a change management lead or is that a luxury?

Headcount decides it. The threshold is lower than most people assume. Under about 150 affected users, the sponsor and process owners can carry communications and training between them. Above that, someone needs to own it as a real job, because training 400 people across three shifts is a logistics problem that will otherwise land on whoever is least able to refuse it. Adoption and training specialists are usually contract roles running from user acceptance testing through 60 days past go-live.

Fill the Seven, Then Argue About the Boxes

The org chart is the last artifact to build, not the first. Start with the seven functions, decide honestly who owns each one and at what percentage, name an alternate, and write down what each person decides rather than what they attend.

The distribution company outside Fontana eventually got there. Twenty-two names became six, with real percentages and one sponsor who could end an argument. They went live eight months later than the original plan. Nobody enjoyed that. The system has been stable since. If you are working backward from a date rather than forward from an org chart, the go-live window each team size actually supports is the companion piece to this one.

Six people who own something will outrun twenty-two who are involved. Every time.

If you are mapping this out now and want a second opinion on which seats to hire, which to rent, and which to backfill, talk to our ERP staffing team. We work across NetSuite, SAP, Dynamics, Oracle, and Epicor, and we will tell you when you do not need us.