ERP Stakeholders and Their Role in Software Selection and Implementation

Selecting an Enterprise Resource Planning (ERP) system is not only a software decision. It is an operating model decision that affects how the business sells, plans, buys, makes, ships, invoices, reports, and serves customers.

My perspective on ERP stakeholder involvement comes from working across multiple sides of ERP programs. I have served as a client-side ERP leader, an implementation lead for a large US-based implementation partner, and an ERP advisor to companies ranging from smaller businesses to Fortune 50 organizations implementing new ERP systems. That experience has shaped one of my strongest beliefs about ERP success. The right stakeholders need to be involved early enough to define current needs, future needs, operational gaps, and decision criteria before the company commits to a platform or implementation path.

A strong ERP software selection should bring together executive leadership, finance, operations, Information Technology, functional business process owners, end users, customers or customer-facing teams, software vendors, implementation partners, and independent advisors. Each role has a different responsibility. Some define strategy. Some validate daily process fit. Some assess technical risk. Others help protect objectivity, implementation readiness, and long-term adoption.

The goal is not to involve everyone in every decision. The goal is to involve the right people in the right way so the company can make a defensible ERP decision and carry that decision into a successful implementation.

Why stakeholder alignment matters in ERP selection and implementation

ERP touches the core of the business. When stakeholder input is too narrow, companies often select systems based on polished demonstrations, executive preference, vendor familiarity, or incomplete requirements. That can lead to gaps later in implementation, including process workarounds, reporting limitations, user adoption challenges, integration issues, and scope changes.

Stakeholder alignment helps leadership answer several important questions before committing to a platform.

• Does the ERP support the company’s strategic direction?

• Can the system handle how the business actually operates?

• Are the most complex processes represented in the requirements and demonstrations?

• Has the company considered total cost, implementation effort, data readiness, integration risk, and adoption?

• Are decision rights clear enough to avoid delays during implementation?

These questions matter because selection and implementation are connected. The requirements, demo scripts, assumptions, scoring, and decisions made during selection should become the foundation for design, configuration, testing, training, and go-live readiness.

Key ERP stakeholders and how they should be involved

Executive sponsors

Executive sponsors are responsible for setting the business direction of the ERP program. They should clarify why the company is evaluating ERP, what business outcomes matter most, and what tradeoffs are acceptable.

During selection, executive sponsors should align the organization around priorities such as growth, standardization, margin improvement, operational visibility, compliance, customer experience, and scalability. They do not need to participate in every requirement workshop, but they should be involved in kickoff, decision checkpoints, finalist reviews, total cost review, and final recommendation.

During implementation, executive sponsors need to stay engaged. ERP implementations create competing priorities, resource conflicts, design decisions, and change fatigue. Sponsors help maintain momentum, resolve escalations, and reinforce that the implementation is a business transformation, not just a technology project.

Consideration for leadership

Executive involvement should not end after vendor selection. The strongest ERP programs keep executive sponsors active through design, testing, cutover, go-live, and stabilization.

Finance leadership

Finance is often one of the most influential stakeholder groups in ERP selection because the system must support accounting, reporting, controls, approvals, costing, budgeting, revenue recognition, procurement, and audit needs.

During selection, finance should help define requirements for general ledger, accounts payable, accounts receivable, fixed assets, cash management, financial reporting, consolidation, project accounting, cost accounting, and compliance needs. Finance should also play a major role in evaluating licensing, implementation services, third-party systems, support costs, and long-term total cost of ownership.

During implementation, finance validates the future-state design and confirms that the system can support close processes, approval workflows, reporting requirements, and internal controls. Finance is also critical during data migration, opening balances, cutover planning, and user acceptance testing.

Consideration for leadership

The lowest software price is not always the lowest-risk decision. Finance should evaluate the full cost and the assumptions behind the implementation estimate.

Operations leadership

Operations leaders help ensure the ERP reflects how the business actually runs. This may include manufacturing, distribution, supply chain, quality, procurement, warehouse management, field service, maintenance, or customer fulfillment.

During selection, operations should define the processes that are most likely to create implementation risk. These may include production scheduling, work orders, routings, labor reporting, inventory movements, lot and serial traceability, quality holds, substitutions, outside processing, shipping compliance, or multi-location planning.

During implementation, operations leaders and business process owners validate whether the configured system supports the real flow of work. They are also essential to testing, training, adoption, and cutover readiness.

Consideration for leadership

ERP demos need to show operational reality. A polished demo that avoids exceptions, bottlenecks, and high-volume scenarios can create false confidence.

Information Technology

Information Technology is a critical stakeholder, but ERP should not be treated as an Information Technology-only decision. The Information Technology team helps assess technical fit, architecture, integrations, security, data migration, reporting tools, system performance, support model, and long-term maintainability.

During selection, Information Technology should evaluate whether the platform fits the company’s technical landscape. This includes cloud strategy, cybersecurity, identity management, integration tools, data access, reporting architecture, and vendor support capabilities.

During implementation, Information Technology typically supports environments, integrations, testing, data migration, access controls, reporting, and production support readiness.

Consideration for leadership

Information Technology should help the business understand technical risk in plain language. The executive team needs to know what will be easy to support, what will require custom work, and where future complexity may increase cost.

Business process owners

Business process owners (BPOs) are the bridge between leadership priorities and daily execution. They understand how work gets done, where the current pain points exist, and which requirements are truly important.

During selection, business process owners should participate in requirements workshops, review vendor responses, attend scripted demos, score scenarios, and identify process gaps. They should not simply react to software screens. They should test whether the vendor can support the business scenarios that matter most.

During implementation, business process owners help make design decisions, validate configuration, support user acceptance testing, and prepare their teams for change.

Consideration for leadership

Business process owners need clear authority. If they are asked to participate but cannot make decisions, the implementation can slow down or drift into unresolved design issues.

End users and super users

End users provide the practical perspective that leadership and project teams can miss. They understand transaction volume, workarounds, timing pressures, customer requests, and the small details that determine whether the system will be adopted.

During selection, end-user input should be gathered in a structured way. This may include workshops, current-state pain points, demo feedback, and usability scoring. Not every end user needs to participate in every session, but the project should include enough input to understand how the system will affect daily work.

During implementation, selected end users often become super users. They support user acceptance testing, training, issue identification, and go-live support.

Consideration for leadership

End-user involvement should be targeted. Too little input creates adoption risk. Too much unstructured input can slow decisions and create conflicting priorities.

Customers and customer-facing teams

Customers may not sit directly on the ERP selection team, but customer impact should still be represented. In many businesses, ERP affects quoting, order status, delivery dates, invoices, customer portals, service responsiveness, returns, compliance documents, and shipment visibility.

During selection, customer-facing teams should help define requirements that affect customer experience. This may include sales, customer service, account management, logistics, or quality teams.

During implementation, these teams validate order-to-cash processes, customer documents, notifications, portal workflows, EDI, shipping requirements, and service-related reporting.

Consideration for leadership

ERP should improve the customer experience, not just internal reporting. Selection teams should evaluate how each system supports customer promises and service expectations.

Software vendors

Software vendors are important participants in the process, but they have a specific role. Their job is to explain and demonstrate what their software can do, how it is licensed, where it fits, and where assumptions apply.

During selection, vendors should respond to requirements, participate in discovery, provide pricing, demonstrate scripted scenarios, and clarify product capabilities. The strongest evaluations give every finalist the same scenarios, data, and scoring structure so leadership can compare options fairly.

During implementation, the vendor may provide product support, solution guidance, technical resources, or roadmap input, depending on the delivery model.

Consideration for leadership

Vendor demonstrations should be controlled by the buyer’s scenarios. Without scripted demos, vendors may show what looks best instead of what matters most.

System integrators and implementation partners

The implementation partner is often just as important as the ERP software. The partner’s methodology, staffing model, industry experience, assumptions, accelerators, and project governance can significantly affect timeline, cost, and quality.

During selection, the implementation partner should explain how the project would be delivered, what resources are required from the client, what assumptions are included in the estimate, and where scope risk exists.

During implementation, the partner configures the system, supports design, builds integrations, migrates data, supports testing, trains users, and helps move the company through go-live.

Consideration for leadership

A strong software product can still fail with the wrong implementation approach. Executives should evaluate the partner’s delivery model, not just the software platform.

Independent ERP advisor

An independent ERP advisor can help the company structure the ERP selection process, protect objectivity, and translate business needs into selection and implementation decisions. This role is especially important when internal teams do not run ERP selections often or when vendors and implementation partners have a natural bias toward the solutions they sell.

During selection, a vendor-neutral advisor can help define requirements, develop a request for proposal, manage vendor communications, facilitate scripted demos, build scorecards, evaluate total cost, and support the final recommendation.

During implementation, a client-side advisor can help leadership maintain governance, manage risk, validate design decisions, support testing strategy, prepare for go-live, and hold the vendor and implementation partner accountable to the business outcome.

Consideration for leadership

An advisor should not replace executive ownership or business process ownership. The advisor should strengthen the client’s ability to make informed decisions and manage the ERP program with discipline.

How stakeholder involvement changes from selection to implementation

ERP selection is about choosing the right platform and partner. ERP implementation is about turning that decision into a working business system. The ERP selection should begin with a clear understanding of the company’s current needs, future needs, and gaps. Stakeholders help define what is working today, where the current systems or processes are creating friction, and what the business will need from ERP as it grows or changes.

During selection, stakeholder involvement should focus on requirements, process pain points, future-state needs, risk areas, and decision criteria. This includes understanding current workflows, identifying manual workarounds, documenting reporting and control gaps, and clarifying where the business needs greater standardization, visibility, scalability, or automation.

The best selection processes do not simply ask stakeholders what features they want. They ask what the business needs to accomplish, where today’s process breaks down, and what capabilities must be in place to support future operations. That input becomes the foundation for requirements, request for proposal content, scripted demos, vendor scoring, implementation planning, and testing.

Define decision rights early

Clarify who provides input, who recommends, who approves, and who resolves conflict. This avoids confusion when priorities compete and helps keep the selection and implementation moving.

Separate input from authority

Many stakeholders should be heard, but not every stakeholder should have decision authority. A clear governance model keeps the process focused while still allowing the business to contribute meaningful input.

Start with current needs, future needs, and gaps

ERP requirements should be grounded in how the business works today, where the current process or system falls short, and what the company will need in the future. This helps leadership evaluate vendors against business direction, not just today’s pain points.

Use requirements to guide the selection

Requirements should do more than create a checklist. They should define the business scenarios, process priorities, reporting needs, integration points, compliance needs, and operational gaps that vendors must address.

Use scripted demos

Vendor demos should be based on the company’s business scenarios, not generic software tours. Scripted demos help stakeholders evaluate whether the ERP can support the real flow of work across finance, operations, supply chain, sales, service, and reporting.

Score more than features

Evaluate process fit, user experience, reporting, integration, data migration, implementation effort, partner quality, cost, risk, and long-term support. A system can look strong functionally but still create risk if it is difficult to implement, support, or adopt.

Plan for operational readiness and change management

ERP adoption depends on people, not just system configuration. Leaders should consider how roles, responsibilities, workflows, approvals, training, communication, and day-to-day behaviors will change. Operational readiness and change management should be acknowledged early so the business is prepared for implementation, go-live, and stabilization.

Connect selection to implementation

Requirements, gaps, demo scripts, scoring rationale, and vendor assumptions should carry into implementation. These outputs help guide design, configuration, testing, training, and go-live readiness.

Watch for bias

Vendors, implementation partners, internal departments, and even executives can bring preferences into the process. A structured method helps keep the decision grounded in business fit and implementation reality.

Protect the business outcome

ERP success depends on more than selecting the right system. It also depends on governance, stakeholder accountability, testing, data quality, change management, adoption, and disciplined execution through go-live and stabilization.

Turning Stakeholder Alignment into ERP Adoption

Selecting an Enterprise Resource Planning system is not only a software decision. It is an operating model decision that affects how the business sells, plans, buys, makes, ships, invoices, reports, and serves customers. When stakeholders are involved in the right way, they do more than provide input. They become advocates for the decision, help prepare their teams for change, and support the adoption needed to make the system successful after go-live.

John Hannan LLC helps companies navigate ERP selection and implementation with a vendor-neutral, client-side approach. Our team helps leadership define requirements, structure vendor evaluation, facilitate scripted demos, compare total cost, assess implementation readiness, and carry key decisions into delivery.

With the right stakeholders, the right process, and the right guidance, your ERP selection can become more than a software decision. It can become the foundation for a stronger operating model and a more successful go-live. Contact John Hannan LLC to learn how we can help with your selection.