ERPAn ERP system connects a company’s core processes—such as sales, finance, inventory, manufacturing, and service—in one place so teams can work with shared information. is often described as a software project. In reality, it is a business change project supported by software.
An ERP system connects areas such as sales, CRM, purchasing, warehouse management, production, finance, HR, service, and reporting. Because it affects so many parts of the company, no single department can implement it successfully alone.
The quality of the implementation team has a direct effect on the result. The right people help the company make clear decisions, describe real processes, prepare clean data, test the system properly, train employees, and solve issues before they become expensive.
A strong team turns ERP from a technical installation into a working system that improves the business.
How We Approach ERP Team Design
We built this guide by reviewing the governance models used across manufacturing and distribution implementations we have observed over the past decade. Our criteria were straightforward: every role listed must deliver a specific, measurable outcome during the project lifecycle, and any position that merely observes without owning a deliverable was excluded from the core team definition. We evaluated how each function interacts during requirements gathering, system build, testing, and post-go-live support.
This structure is deliberately provider-agnostic. Whether you deploy SIX ERP or another platform, the human architecture required to map business processes to software remains consistent. What we see most often is companies copying a vendor’s suggested org chart without adjusting it for their own operational complexity. A well-structured ERP team is usually cross-functional rather than purely technical, blending internal process knowledge with external system expertise to prevent blind spots during design and rollout.
What Is an ERP Implementation Team?
An ERP implementation team is the group of people responsible for guiding the project from planning to go-live and beyond.
It includes people from inside the company, such as management, department representatives, IT staff, finance users, warehouse users, sales employees, and production managers. It also includes the ERP provider’s consultants, technical specialists, trainers, and project managers.
The company brings knowledge about its daily work. The ERP provider brings knowledge about the system and implementation method.
Both sides are needed.
The internal team must explain how the business really works today, where the problems are, and what needs to improve. The ERP partner must translate this knowledge into practical processes, system settings, training, and a realistic implementation plan.
ERP implementation succeeds when business knowledge and system knowledge work together.
| Role | Side | Core responsibility | Typical time commitment |
|---|---|---|---|
| Executive sponsor | Internal | Owns business case, budget, and escalation decisions | 5–10% throughout |
| Internal project lead | Internal | Coordinates scope, schedule, risks, and communication | 50–100% throughout |
| Key users / process owners | Internal | Define functional requirements and validate workflows | 20–50% (peaks in design/testing) |
| Business analyst | Internal/Provider | Translates business needs into system specifications | 75–100% (design phase) |
| IT / technical lead | Internal | Manages infrastructure, security, and access controls | 30–50% throughout |
| Developer / integrationIntegration connects systems so they can exchange information or coordinate actions. An ERP integration helps link business tools and reduce manual transfers between them. specialist | Provider/Internal | Builds custom code and connects external applications | Project-based sprints |
| Test users | Internal | Executes business scenarios and logs defects | 20–40% (testing phase) |
| Trainer | Provider/Internal | Delivers role-based instruction and materials | 50–100% (pre-go-live) |
| ERP provider project manager | Provider | Manages vendor deliverables and methodology adherence | 50–100% throughout |
This table represents the standard ERP project team structure. During the project, these roles temporarily override the company’s normal organizational structure. The internal project lead reports directly to the executive sponsor rather than their usual department head, and key users take direction from the project lead for implementation tasks while maintaining their standard reporting lines for daily operations. This dual-reporting model prevents departmental silos from stalling cross-functional decisions.
The Executive Sponsor Gives the Project Direction
ERP implementation is ultimately the responsibility of the executive sponsor, who is accountable for overall success. Day-to-day execution falls to the internal project lead, while departmental process owners remain responsible for validating and adopting changes within their specific areas.
The executive sponsor is a senior decision-maker who supports the ERP project from the top of the company.
This person does not need to manage every project detail. Their main role is to keep the project connected to the company’s strategic goals. They help make important decisions, remove internal barriers, approve priorities, and ensure that departments take the project seriously.
Consider a common conflict: the sales department demands a frictionless, one-click order entry screen to maximize speed, while finance requires mandatory credit-check approvals before any order is confirmed. The executive sponsor must resolve this by deciding which business objective takes priority—revenue velocity or risk mitigation—and enforcing that decision across both departments.
Without visible support from management, employees may see ERP as an extra task rather than an important company project. Research underscores why this governance matters: a widely cited project assessment found that only 37% of ERP projects succeeded when measured by finishing on time and within budget, while 21% failed entirely because they were canceled or never used (Standish Group report via ERIC). More than half of the evaluated projects cost 189% of their original estimates, illustrating how weak planning and unclear ownership turn technology initiatives into financial liabilities.
The Internal Project Lead Keeps Work Moving
The internal project lead is usually the person who coordinates the company’s side of the implementation.
They work closely with the ERP provider’s project manager. They organize meetings, collect questions, follow up on responsibilities, help obtain data, coordinate key users, and make sure decisions do not remain open for too long.
This person needs good communication skills, a clear understanding of the company, and enough authority to move work forward. They do not need to know every technical detail, but they must understand the project scope and recognize when an issue needs management attention.
The internal project lead is often the bridge between employees, management, and the ERP partner.
Business Process Owners Explain How Work Really Happens
Every important business area needs a person who understands how its processes work.
A sales process owner can explain how leads become offers, orders, deliveries, and invoices. A purchasing process owner can explain supplier selection, purchase requests, approvals, orders, and invoice matching. A warehouse process owner understands receiving, locations, picking, stock movements, returns, and inventory counts. A production process owner understands bills of materials, work orders, materials, capacity, quality, and reporting.
These people are often called key users or process owners.
They are essential because ERP configuration should be based on reality, not assumptions.
Key users also play an important role after go-live. They become the first point of support for their colleagues and help make sure the new process is used consistently.
The Business Analyst Connects Requirements and Solutions
The business analyst helps turn business needs into clear ERP requirements.
They ask practical questions. What problem are we trying to solve? Who performs this task today? What information is needed? Which approval is required? What happens if something goes wrong? Which report must management see?
The business analyst helps document processes, identify gaps, challenge unnecessary steps, and make sure that the solution supports the company’s real goals.
This role may be filled by an internal employee, an ERP consultant, or a combination of both. In smaller projects, the project lead and business analyst may be the same person.
The important point is that someone must make sure the business process is understood before the system is configured. In our review of implementation projects, the missing role is almost always the business analyst; teams skip straight to configurationConfiguration sets up software using its existing options. In an ERP system, it adapts workflows, roles and other settings to the company's business processes. without mapping the underlying logic, which often causes rework during user acceptance testing.
The Technical Team Protects the System Environment
The technical team supports the infrastructure around the ERP system.
Depending on the chosen hosting model, this may include internal IT staff, the ERP provider, a managed cloud partner, or external specialists. Their responsibilities may include user access, network setup, security, backups, integrations, devices, data migration support, system monitoring, and technical troubleshooting.
A managed cloud ERP reduces the need for an internal team to manage servers and infrastructure. But internal IT is still important because the ERP must work with the company’s users, devices, internet connections, printers, scanners, external software, and security policies.
The technical team should be involved early, especially when the ERP needs to connect with e-commerce platforms, CAD systems, carrier services, barcode scanners, accounting systems, machines, customer portals, or other applications. Connecting disparate systems introduces significant friction, and reviewing practical advice on system integration challenges over at Rite NRG helps technical leads anticipate data-mapping errors and APIAn API (Application Programming Interface) allows software systems to exchange information. Connected to an ERP system, it helps transfer business data and reduce manual entry. limitations before they stall the project timeline.
Developers and Integration Specialists Are Needed When Standard Tools Are Not Enough
A good ERP should solve most business needs through standard functions, configuration, and existing modules.
Sometimes, however, the company has a genuine special requirement. It may need an integration with an external system, a customer portal, a carrier service, specialized machinery, an e-invoicing platform, or a custom workflow that cannot be handled through standard tools.
In these cases, developers and integration specialists may be required.
Their work should always be based on a clear business need. Custom development should not be used to copy every old habit or private Excel file into the new ERP. Every custom function creates a long-term responsibility for testing, maintenance, security, documentation, and future updates.
The best approach is to standardize where possible, configure where useful, and develop only where the business benefit is clear.
Testers and End Users Make Sure the System Works in Real Life
The ERP system must be tested by people who understand the work.
A technical test can show that a button works. A business test shows whether the process works when a supplier delivers the wrong quantity, a customer changes an order, stock is missing, a product is damaged, or an invoice does not match the purchase order.
End users should be involved before go-live. They can test the new system, give feedback, identify confusing steps, and help improve instructions.
This also makes change easier. Employees are more likely to trust a new process when colleagues from their own department have helped test and improve it.
Testing is not about finding fault. It is about protecting the business before the system is used for real orders, real stock, real invoices, and real customers.
Trainers Help Employees Use the ERP With Confidence
Training is one of the most important parts of ERP implementation.
Employees do not need to learn every function in the system. They need role-based training that prepares them for their actual daily work.
A warehouse employee should understand receiving, put away, stock movement, picking, and delivery. A salesperson should understand customers, leads, offers, orders, and follow-ups. A finance user should understand invoices, payments, approvals, and reports. A manager should understand dashboards and key performance information.
The best training uses real examples from the business.
A trainer may be provided by the ERP partner, supported by internal key users. After go-live, key users can continue helping their teams and collecting questions for further training or system improvement.
External Consultants Bring Experience and Perspective
External ERP consultants can bring valuable experience, especially when the company is implementing a complex system or changing important processes.
They have seen common implementation risks before. They understand how to plan data migration, define project scope, manage change, prepare testing, structure training, and avoid expensive mistakes.
External consultants should not replace internal involvement. No consultant can understand the company as well as the people who work there every day.
The strongest projects combine external experience with internal process knowledge.
Team Size Depends on Scope, Not a Fixed Number
Team sizing must reflect company scale and operational complexity. Global adoption statistics demonstrate why a small business should not copy the governance model of a multinational manufacturer: reported ERP adoption in Germany reached 37.5% among companies with 10–49 employees, 67.7% for 50–249 employees, and 89.4% for organizations with 250 or more employees in 2025 (ERP Research adoption statistics). A smaller firm typically operates with a compact team where the managing director serves as the executive sponsor.
For concrete staffing benchmarks, a typical small-company core team consists of 4 to 6 people: the sponsor, project lead, two or three key users, and the provider’s project manager. Mid-market deployments generally require 8 to 12 members to cover distinct functional areas, while larger multi-site projects demand 15 or more participants to handle parallel rollouts. Across all sizes, key users commonly need 20% to 50% of their working time freed from daily duties during the design and testing phases to participate meaningfully. According to Flectic’s breakdown of ERP team roles, functional leads representing finance, sales, purchasing, and manufacturing must be explicitly allocated this protected time, otherwise the project relies on assumptions rather than validated processes.
Staffing intensity shifts depending on the project phase. During design, business analysts and key users carry the heaviest load. In the testing phase, end users and developers peak as scenarios are executed and defects resolved. At go-live, trainers and the technical team dominate the schedule. Aligning resource allocation to these phases prevents burnout and ensures the right expertise is available exactly when needed, mirroring the phased resource loading recommended in Oracle’s implementation project plans.
The teams that struggle are the ones where key users are expected to maintain 100% of their operational output while simultaneously designing and testing the new system. Management must provide time, authority, budget, and support to succeed.
Clear Communication Prevents Conflict
ERP projects often bring old problems to the surface.
Departments may discover that they use different definitions for the same data. One team may want more control, while another wants faster approvals. Employees may disagree about who owns a process. Managers may have different expectations about reports and responsibilities.
This can create tension, but it can also create improvement.
The company should make it clear that ERP is an opportunity to discuss these issues openly and build better processes. The goal is not to blame people for past workarounds. The goal is to create a stronger way of working for the future.
Regular meetings, documented decisions, realistic timelines, clear responsibilities, and honest progress reports help keep the project healthy.
Every team member should understand what is expected from them, what decisions they can make, and where they can raise concerns.
Recognize the Extra Work
ERP implementation takes effort.
Employees may need to prepare data, attend training, test scenarios, review documents, answer questions, and continue their normal responsibilities at the same time. This can be demanding, especially during the weeks before go-live.
Management should recognize this work.
Celebrate completed milestones. Thank employees who contribute their knowledge. Show the team how their effort is improving the business. Give people enough time to perform their project responsibilities properly.
A successful ERP implementation is not created by one consultant or one department. It is created by people working together toward a shared goal.
Frequently Asked Questions
Who is responsible for ERP implementation?
The executive sponsor holds ultimate accountability for the project’s success and budget. Day-to-day responsibility belongs to the internal project lead, while departmental process owners are responsible for defining and validating workflows within their specific areas.
What is the role of ERP in an organization?
ERP centralizes data and standardizes processes across departments like finance, sales, inventory, and production. It replaces disconnected spreadsheets and legacy systems with a single source of truthA single source of truth is an agreed set of authoritative business information. An ERP system helps teams use consistent records across departments and processes., enabling faster reporting and coordinated operations.
How many people do you need on an ERP project team?
Small businesses typically need a core team of 4 to 6 people. Mid-market companies usually require 8 to 12 members, and large multi-site enterprises often staff 15 or more to cover all functional areas and parallel testing tracks.
What is the difference between the core team and the wider user group?
The core team designs, configures, and tests the system. The wider user group consists of all employees who will eventually operate the software; they receive training and provide feedback but do not make architectural decisions.
Why do ERP projects fail due to team structure?
Projects fail when key users lack protected time to participate, when the executive sponsor delegates authority without providing budget, or when the business analyst role is left unfilled, forcing developers to guess at process requirements.
