The ERP Team You Need
Most executives building an ERP team start with three roles in mind: a project manager, a business analyst, and someone from IT. They discover the other sixteen roles they needed somewhere around month eight — usually because a gap has already turned into a cost, a delay, or a decision nobody was actually authorised to make.
An ERP program is not one discipline wearing different hats. It’s a coalition of distinct disciplines, each with its own failure mode if left unowned. Data migration fails differently to change management. Testing fails differently to document management. Put one overstretched project manager in charge of all of it, and you haven’t simplified your team — you’ve hidden nineteen risks inside one job title.
Some of these roles can be combined in a smaller organisation. A steering committee member might also chair business architecture discussions. A change manager might own communications too. That’s a legitimate structural choice. What isn’t legitimate is combining roles by accident — where a gap gets silently absorbed by whoever’s closest, without anyone deciding it should be that way.
Below is the full set, in the sequence it actually plays out:
| Dimension | Key Role | Purpose |
|---|---|---|
| Business Architecture | Business/Enterprise Architect | Aligns the ERP design to how the organisation actually operates — not to whatever configuration is easiest to build. |
| Business Analysis | Business Analyst | Translates business problems into solution requirements. The bridge between what the organisation needs and what gets built. |
| Project Sponsor | Executive Sponsor | Owns the ROI. Accountable for the value delivered — not just the go-live date. |
| Executive Steering Group | Steering Committee | Makes the decisions the project team isn’t authorised to make alone. Where trade-offs get resolved, not deferred. |
| Project Management | Project Manager | Owns schedule, budget, risk, and scope control. |
| Change Management | Change Manager | Owns adoption — prepares the people side of the organisation to actually use what’s being built. |
| Integrations | Integration Lead | Owns how the ERP connects to other systems, so data moves correctly between them. |
| Data Migration | Data Migration Lead | Owns the accuracy and completeness of data moved from legacy systems — including the unglamorous work of cleaning it first. |
| Testing | Test Lead | Owns verification that the system actually works as designed, before it’s trusted with real operations. |
| Quality Management | Quality Manager | Owns the standard of deliverables and process discipline across the whole program. |
| Reports/Dashboards | Reporting Lead | Owns what executives and staff will actually see and rely on to make decisions. |
| BI | BI Lead | Owns the organisation’s deeper analytical capability — beyond standard reports. |
| AI | AI/Automation Lead | Owns where and how AI gets embedded into new processes, deliberately rather than by accident. |
| Document Management | Document Management Lead | Owns how documents live natively inside the new system going forward, replacing the shadow filing systems that quietly outlive every go-live. |
| Training | Training Lead | Owns building real competence in the people who’ll use the system every day. |
| Communications Management | Communications Lead | Owns what the organisation is told, when, and how — so rumour doesn’t fill the vacuum. |
| Support | Support Lead | Owns what happens after go-live, when something breaks and someone needs to answer. |
| Access & Security Management | Security/Access Lead | Owns who can see and touch what — segregation of duties, compliance, and risk. |
| Product Management | Product Owner | Owns the system as a living product after go-live, not a closed project — the case for continued investment. |
The real question isn’t whether all nineteen roles are filled by nineteen named individuals. It’s whether you can say, right now, who is accountable for each one. If you can’t answer that in under a minute, you have a gap.
Gaps in ERP programs don’t show up in status reports. They show up eighteen months after go-live, when someone finally asks why the data migration was never actually validated, or why nobody owns the dashboards the executive team stopped trusting months ago.
