Leadership, Change Management and User Adoption

Introduction

Enterprise resource planning (ERP) systems integrate processes, data, controls, and decisions across functions such as finance, procurement, production, sales, human resources, and supply chain management. Their implementation is therefore not merely an information-technology project. It is an organizational transformation in which authority, work routines, performance measures, professional identities, and patterns of collaboration may all change.

An ERP system can be technically sound and still fail to deliver value if users do not trust it, understand it, or incorporate it into daily work. Conversely, strong leadership, credible governance, timely communication, relevant training, and systematic resistance management can convert a technically complex implementation into a sustainable organizational capability. User adoption is not achieved by compelling employees to attend training; it emerges when users perceive that the system is useful, usable, legitimate, and supported by their managers and peers.

This chapter examines the leadership and organizational dimensions of ERP implementation. It integrates stakeholder theory, change-management models, organizational culture, governance, competence development, communication, resistance management, and adoption evaluation. Particular attention is given to the strategic role of senior executives, the operational role of process owners and super-users, and the ethical responsibilities associated with data, automation, monitoring, and organizational change.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain why leadership and user adoption are strategic determinants of ERP value.
2. Design stakeholder-engagement, governance, communication, and training arrangements.
3. Apply established change-management and technology-adoption models critically.
4. Diagnose cultural, role, competency, and resistance issues affecting ERP implementation.
5. Evaluate critical success and failure factors using appropriate measures and evidence.
6. Recommend ethical and sustainable approaches to ERP-enabled organizational change.

1. ERP Implementation as Organizational Transformation

ERP implementation changes the relationship between people, processes, and information. Before implementation, departments may use local spreadsheets, unofficial databases, paper approvals, or workarounds. An integrated ERP environment replaces many of these arrangements with standardized processes, shared master data, formal authorization rules, and visible transaction histories.

This creates four forms of transformation:

• Process transformation: activities are standardized, integrated, automated, or redesigned.
• Information transformation: data becomes more centralized, governed, traceable, and available across functions.
• Structural transformation: responsibilities, reporting relationships, decision rights, and control mechanisms may change.
• Cultural transformation: employees are expected to value cross-functional accountability, data discipline, transparency, and continuous improvement.

The implementation challenge is consequently socio-technical. Technical design determines what the system can do; organizational design determines whether people will use it appropriately and whether the organization will realize benefits. A technically correct configuration may be rejected when it conflicts with local practices, professional judgment, workload realities, or perceptions of fairness.

ERP benefits are often described as improved efficiency, lower inventory, faster reporting, stronger compliance, and better decision-making. These benefits are not automatic outputs of software. They depend on changed behaviors. For example, real-time inventory visibility is valuable only when employees record receipts, issues, adjustments, and stock counts accurately and promptly. A workflow approval is effective only when managers use it consistently rather than bypassing it through email or informal instructions.

2. Leadership and the Strategic Case for Change

2.1 Leadership versus administration

Project administration coordinates schedules, resources, risks, and deliverables. Leadership creates meaning, legitimacy, direction, and commitment. ERP programs require both. A project manager may report that configuration is complete, but an executive leader must explain why the organization is changing, what benefits are expected, what trade-offs are accepted, and how leaders will behave when implementation becomes difficult.

Effective ERP leadership has five characteristics:

1. Strategic alignment: the ERP program is connected to business strategy rather than treated as a software replacement.
2. Visible sponsorship: senior leaders communicate consistently and participate in critical decisions.
3. Cross-functional orientation: leaders resolve conflicts between departments and protect enterprise interests.
4. Realistic commitment: leaders provide time, resources, and decision capacity rather than relying on slogans.
5. Behavioral consistency: leaders follow the new processes and use the system themselves.

A common failure occurs when executives declare that the ERP program is strategic but delegate all important decisions to the information-technology department. This signals that the system is an IT issue and leaves business units free to protect local practices. Executive sponsorship must therefore be active, not ceremonial.

2.2 The leadership coalition

Large ERP programs require a coalition rather than a single champion. A useful coalition includes the executive sponsor, program director, business process owners, information-security leadership, functional managers, change and training leads, local representatives, and—where relevant—employee representatives or unions.

The coalition should have authority to make decisions about process standardization, customization, data ownership, policy, resource allocation, and risk acceptance. It must also be sufficiently representative to understand operational consequences. A coalition composed only of executives may lack process knowledge; one composed only of specialists may lack authority.

2.3 Leading through competing interests

ERP implementation creates legitimate conflicts. Finance may prefer strict controls, sales may seek flexibility, operations may prioritize speed, and information security may require segregation of duties. These are not merely communication problems. They are governance choices involving risk, service, cost, and accountability.

Leaders should make trade-offs explicit. A decision record should state the issue, alternatives considered, decision criteria, responsible authority, consequences, and review date. This reduces retrospective blame and prevents the same issue from being debated repeatedly.

3. Stakeholder Engagement and Governance

3.1 Stakeholder analysis

Stakeholders are individuals or groups that affect, are affected by, or perceive themselves to be affected by the ERP program. They may include executives, process owners, end users, customers, suppliers, auditors, regulators, implementation partners, works councils, and IT operations teams.

Stakeholder analysis should assess at least:

• influence over decisions;
• degree of operational impact;
• level of support or resistance;
• knowledge of the current and future processes;
• concerns, incentives, and potential contributions; and
• preferred communication and participation methods.

A power–interest matrix is useful, but it should not be treated as static. A warehouse supervisor may have limited influence during vendor selection but substantial influence during cutover. A regulator may have low day-to-day involvement but high interest in financial controls. Stakeholder positions should be reviewed at major lifecycle stages.

3.2 Participation mechanisms

Participation should be meaningful rather than symbolic. Appropriate mechanisms include process-design workshops, conference-room pilots, user-story reviews, data-cleansing sessions, usability testing, role-based training pilots, site readiness assessments, and post-go-live review forums.

Participation does not mean that every preference is implemented. It means that affected parties can provide evidence, identify risks, understand constraints, and see how decisions are made. Transparent rejection of a request is usually more trust-building than silent exclusion.

3.3 Governance architecture

ERP governance allocates decision rights and accountability. A practical structure may contain the following bodies:

Governance should distinguish accountability from responsibility. A process owner may be accountable for the design and performance of an order-to-cash process, while several managers are responsible for executing parts of it. Confusing these roles produces gaps, duplication, and escalation delays.

Figure: A governance structure linking executive direction, specialist governance, change networks, and sustained adoption.

3.4 Decision rights and escalation

Decision rights should be documented before major design conflicts arise. A responsibility assignment matrix can identify who is accountable, responsible, consulted, and informed for each decision. However, the matrix is useful only when it is linked to actual authority, meeting routines, and escalation deadlines.

Escalation should be viewed as a control, not a failure. Issues that exceed the authority, risk tolerance, or time horizon of a working group should move quickly to the appropriate level. Delayed escalation is particularly dangerous during data migration, integration testing, security design, and cutover planning.

4. Change-Management Models and Their Critical Use

4.1 Lewin’s three-stage model

Lewin’s model conceptualizes change as unfreezing, changing, and refreezing. Unfreezing challenges existing assumptions and creates readiness. Changing introduces new practices and learning. Refreezing stabilizes the new pattern through structures, incentives, routines, and reinforcement.

The model is valuable as a simple diagnostic, but it can imply that organizations reach a permanently stable state. Contemporary ERP environments are continuously updated, cloud-based, and subject to regulatory and market change. A more appropriate interpretation treats “refreezing” as institutionalization of a current capability while preserving readiness for future adaptation.

4.2 Kotter’s process perspective

Kotter’s widely used model emphasizes urgency, a guiding coalition, a strategic vision, broad participation, removal of barriers, short-term wins, acceleration, and institutionalization. Its practical contribution is the recognition that change requires both emotional commitment and removal of structural obstacles.

The model should not be applied as a rigid checklist. Creating urgency through exaggerated crisis claims can damage trust. Short-term wins should be meaningful indicators of improved performance or learning, not cosmetic demonstrations. Institutionalization requires alignment with recruitment, performance management, training, budgeting, and leadership behavior.

4.3 ADKAR and individual adoption

The ADKAR framework focuses on individual outcomes: awareness, desire, knowledge, ability, and reinforcement. It helps managers distinguish different causes of non-adoption. An employee may understand why the system is needed but lack the desire to change. Another may be willing but lack knowledge or practice. A third may possess skill but receive no reinforcement and therefore return to old methods.

These stages are not necessarily linear. Users can regress when system performance deteriorates, management priorities change, or workload increases. Adoption interventions should therefore be diagnosed by cause rather than by assuming that more communication or more training will solve every problem.

4.4 Technology acceptance perspectives

The Technology Acceptance Model proposes that perceived usefulness and perceived ease of use influence attitude and behavioral intention, which in turn influence use. Unified models of technology acceptance add factors such as social influence and facilitating conditions.

These models are useful for designing surveys and identifying adoption barriers, but they have limitations. Intention does not always predict actual use, especially when system use is mandatory. Employees may report acceptance because of social desirability or managerial pressure. Measures should therefore combine perceptions with behavioral and operational evidence.

5. Organizational Culture, Roles, and Competencies

5.1 Culture and ERP outcomes

Organizational culture consists of shared assumptions, values, norms, and practices. ERP programs interact with culture in several ways. A culture that values enterprise collaboration may support integrated processes. A culture built around local autonomy may resist standardization. A culture that penalizes error harshly may encourage hidden workarounds and inaccurate data rather than transparent correction.

Culture should not be reduced to national stereotypes or simplistic labels such as “strong” and “weak.” Leaders should examine observable practices: How are bad-news issues reported? Who is permitted to challenge process designs? Are data definitions negotiated openly? Are performance targets aligned across departments? Are workarounds rewarded because they preserve short-term output?

5.2 Role redesign

ERP implementation often changes roles. Some transactional work may be automated, while analytical, exception-management, master-data, control, and process-improvement responsibilities increase. A job title may remain unchanged even though decision rights and required competencies have changed substantially.

Role analysis should identify:

• activities removed, added, or transferred;
• decisions newly supported by system data;
• required technical and process knowledge;
• control responsibilities and segregation-of-duties restrictions;
• interfaces with other functions; and
• performance measures and escalation routes.

Role redesign should be undertaken with affected employees and managers. Otherwise, the organization may discover after go-live that responsibilities are ambiguous, approvals are excessive, or critical knowledge has been lost.

5.3 Competency architecture

ERP competence includes more than screen navigation. A useful competency architecture covers:

• business-process understanding;
• ERP transaction and workflow skills;
• data-quality and master-data discipline;
• internal-control awareness;
• analytical and problem-solving capability;
• collaboration across functional boundaries; and
• change and continuous-improvement capability.

Training needs analysis should compare current competence with the future-role requirement. Training intensity should reflect task criticality and risk. A user who enters regulated financial data requires deeper control understanding than a user who occasionally views a dashboard.

6. Communication, Training, and Learning Transfer

6.1 Communication as a management process

Communication should answer five questions: Why is the change necessary? What will change? What will remain stable? How will individuals be affected? Where can concerns and support requests be raised?

Messages should be tailored to audiences. Executives need strategic outcomes and risk implications. Process owners need design decisions and performance expectations. Front-line users need task-level consequences, timing, support, and assurance about workload. Suppliers may need changes to purchase orders, portals, invoices, or master-data requirements.

Communication is two-way. Listening sessions, pulse surveys, user forums, and issue logs provide evidence about readiness and unintended consequences. Leaders should distinguish information requests from resistance; repeated questions may indicate that the message is unclear or that the proposed process is not credible.

6.2 Training design

Effective ERP training is role-based, process-oriented, practice-intensive, and close to the time of use. It should use realistic data and scenarios rather than generic demonstrations. A procurement user should practice requisition, approval, purchase order, receipt, exception, and correction processes—not merely click through menus.

A blended learning architecture may include instructor-led sessions, simulations, short digital modules, job aids, process maps, sandbox practice, assessments, and floor support. Training environments must be governed so that learners can experiment without contaminating production data.

6.3 Transfer and reinforcement

Training attendance is an input, not an outcome. Learning transfer requires opportunity to practice, supervisor support, accessible reference materials, timely feedback, and consequences for non-compliant workarounds. Managers should allocate learning time explicitly; otherwise training becomes unpaid extra work and is experienced as a burden.

A useful evaluation sequence is:

1. learner reaction and confidence;
2. knowledge or skill demonstration;
3. correct performance in a realistic scenario;
4. usage and process-behavior evidence after go-live; and
5. operational and business outcomes.

The final two levels are essential because satisfaction does not prove competence and competence does not prove business value.

7. Resistance Management

Resistance is often described as an individual attitude problem, but it may be rational. Users may resist because the new design creates additional work, removes autonomy, exposes performance differences, threatens professional identity, or transfers risk without transferring authority. Resistance can therefore provide valuable information about design quality and implementation fairness.

A diagnostic approach distinguishes several forms:

Managers should not label all disagreement as resistance. Constructive challenge can prevent control failures and usability problems. At the same time, persistent deliberate circumvention of approved controls may require formal accountability, especially where financial reporting, privacy, safety, or regulatory obligations are involved.

Resistance interventions should follow evidence. If users cannot complete a task because the interface is confusing, redesign is preferable to motivational speeches. If the process is understood but local managers reward bypassing it, leadership accountability is required. If fear arises from potential job displacement, honest workforce planning is more ethical than false reassurance.

8. Measuring Readiness, Adoption, and Value

Measurement should combine leading indicators, behavioral indicators, and outcome indicators. Examples include:

• percentage of roles with completed impact assessments;
• training completion and demonstrated competence;
• user-reported confidence and perceived usefulness;
• successful completion of end-to-end scenarios;
• frequency and age of support tickets;
• transaction completeness and data-error rates;
• use of unauthorized spreadsheets or workarounds;
• process-cycle time, rework, inventory accuracy, or close duration; and
• realized financial, service, risk, or compliance benefits.

Metrics must be interpreted in context. High login counts do not prove correct use. Low support-ticket volume may indicate stability—or that users have stopped reporting problems. A reduction in manual adjustments may reflect better data quality—or suppressed correction activity. Triangulation is therefore essential.

A simple adoption rate can be defined as:

The measure assumes that the required behavior is clearly defined, the observation period is specified, and the sample is representative. “Performing correctly” should include relevant controls and data-quality requirements, not merely system login. For example, if 176 of 220 observed users complete a required transaction correctly, the adoption rate is (176 ÷ 220) × 100% = 80%.

A benefits-realization measure can compare actual benefit with the approved target:

The numerator and denominator must use the same benefit definition, time period, baseline, and units. Benefits should be adjusted for external factors where feasible. A shorter month-end close, for instance, should not be attributed entirely to ERP if staffing, accounting policy, or transaction volume also changed.

9. Critical Success and Failure Factors

Research and practice commonly identify the following success factors:

• committed and credible executive sponsorship;
• clear business case and measurable objectives;
• capable program and process leadership;
• realistic scope and disciplined change control;
• active business ownership rather than IT-only ownership;
• high-quality master data and migration governance;
• fit-for-purpose process standardization;
• role-based training and local support;
• early testing with representative users and data;
• effective communication and participation;
• adequate resources and protected user time; and
• benefits tracking after go-live.

Common failure factors include:

• treating ERP as a software installation;
• excessive customization to preserve every local practice;
• weak process ownership and unresolved decisions;
• insufficient data cleansing and unclear data ownership;
• unrealistic schedules and compressed testing;
• inadequate training or training too early;
• executive disengagement after contract signature;
• ignoring informal workarounds and local power structures;
• measuring activity rather than adoption and outcomes; and
• declaring success at go-live instead of evaluating sustained performance.

These factors interact. For example, poor executive sponsorship can weaken scope discipline; weak scope discipline can increase customization; customization can increase complexity; complexity can reduce usability and training effectiveness; and poor adoption can then be misdiagnosed as user resistance.

10. Ethics, Control, and Responsible Change

ERP systems increase organizational visibility. This can improve accountability, but it can also enable intrusive monitoring, excessive surveillance, unfair performance comparisons, or unauthorized access to personal and commercial information. Governance must therefore address privacy, purpose limitation, access minimization, retention, transparency, and lawful processing.

Segregation of duties is a central control principle. No individual should normally control incompatible stages of a sensitive transaction, such as creating a supplier and approving payment. However, controls must be designed with operational realism. Excessive restrictions can encourage credential sharing or informal bypasses. Compensating controls, documented exceptions, and periodic access reviews may be necessary in small organizations.

AI-enabled ERP features introduce additional concerns. Predictive recommendations, automated classification, conversational interfaces, and anomaly detection can support decisions, but users should understand the purpose, limitations, data basis, and accountability arrangements. Automation does not eliminate managerial responsibility. High-impact decisions should retain appropriate human review, auditability, and appeal mechanisms.

Change should also be evaluated for distributive effects. Benefits may accrue to senior management while workload, surveillance, or job insecurity falls disproportionately on front-line employees. Ethical leadership requires honest communication, consultation, reasonable transition support, and attention to vulnerable groups, including temporary workers, remote users, employees with disabilities, and users operating in less-supported locations.

11. Illustrative Case: Northstar Components ERP Program

Background

Northstar Components, a fictional mid-sized manufacturer operating three plants and a central distribution center, implemented an ERP system to integrate purchasing, production planning, inventory, sales, and finance. The organization had grown through acquisitions. Each plant used different item codes, spreadsheets, and scheduling conventions.

Problem

The initial program focused on technical configuration and planned a rapid, standardized rollout. Plant managers were consulted late. Training consisted of generic demonstrations held six weeks before go-live. Executives announced that the system would be mandatory but did not define process ownership or benefits measures.

During testing, users reported that item descriptions were inconsistent, production issues were difficult to record, and approval responsibilities were unclear. These issues were classified as “user resistance.” At go-live, inventory transactions were delayed, planners maintained parallel spreadsheets, and finance received incomplete receiving information. The system was available, but integrated performance deteriorated.

Analysis

The program had several interacting weaknesses:

• no enterprise data owner or common item-definition process;
• weak local participation and insufficient operational representation;
• training that emphasized navigation rather than end-to-end work;
• unclear authority for resolving process conflicts;
• inadequate testing with realistic plant scenarios; and
• leadership behavior that rewarded output even when users bypassed the ERP.

The resistance was partly rational. Users faced genuine usability, data, and role problems. Treating their concerns as attitude failures delayed corrective action.

Approach and solution

The steering committee paused further rollout and appointed process owners for plan-to-produce, procure-to-pay, order-to-cash, and record-to-report. A data council established item-code ownership, definitions, approval rules, and cleansing priorities. Plant representatives became members of a change network and participated in conference-room pilots.

The program redesigned training around role-based scenarios. Super-users received deeper process, troubleshooting, and coaching preparation. Supervisors were required to allocate practice time and review adoption evidence. A temporary command center categorized incidents into data, process, access, training, and technical defects, enabling targeted responses.

Leadership also changed performance expectations. Production output remained important, but managers were instructed not to authorize undocumented workarounds that undermined inventory and financial control. Approved exceptions were logged, reviewed, and removed when root causes were addressed.

Outcome

After a controlled second rollout, transaction completeness improved, parallel spreadsheets were reduced, and finance received more timely receiving information. The organization did not achieve every original efficiency target in the first quarter, but it established reliable ownership, support routines, and benefits measurement. The most important improvement was not a particular software feature; it was the development of shared accountability for processes and data.

Learning points

1. Go-live is a transition point, not evidence of adoption.
2. Resistance signals may reveal defects in design, data, governance, or leadership.
3. Process ownership and data ownership must be explicit.
4. Training is most effective when integrated with realistic work and supervision.
5. Sustainable adoption requires reinforcement through measures, support, and managerial behavior.

12. Contemporary Developments and Best Practices

Cloud ERP and frequent vendor releases make change continuous rather than episodic. Organizations need release-management capability, regression testing, communication routines, and a permanent product or process ownership model. The change network established during implementation should evolve into an operational community of practice.

Remote and hybrid work increase the importance of digital collaboration, asynchronous learning, virtual support, and equitable access to test environments. Localization should be managed carefully: local legal requirements and legitimate operational differences must be respected, but unnecessary variation increases complexity and weakens enterprise visibility.

The following practices are particularly robust:

• establish a clear case for change linked to measurable business outcomes;
• appoint accountable business process and data owners early;
• involve representative users in design, testing, and readiness decisions;
• use realistic end-to-end scenarios and representative data;
• diagnose resistance before selecting an intervention;
• provide role-based learning, practice, coaching, and post-go-live support;
• monitor actual behavior and outcomes, not only attendance or login data;
• make leadership behavior consistent with the new process;
• protect privacy, fairness, accessibility, and control integrity; and
• treat adoption and benefits realization as ongoing management responsibilities.

Chapter Summary

ERP implementation is an organizational transformation in which technology, processes, data, roles, authority, and culture change together. Leadership creates strategic legitimacy, resolves cross-functional trade-offs, allocates resources, and models the behaviors expected from users. Governance translates leadership intent into decision rights, process ownership, data accountability, control, and escalation.

Stakeholder engagement is most effective when affected users participate in meaningful design, testing, and readiness activities. Lewin, Kotter, ADKAR, and technology-acceptance models provide useful lenses, but they should be applied critically rather than as mechanical checklists. Culture, role design, competence, communication, and training strongly influence whether users can and will adopt new processes.

Resistance may be emotional, cognitive, behavioral, political, or structural, and it often contains valuable information about design and fairness. Adoption must be evaluated through demonstrated competence, correct behavior, data quality, process outcomes, and realized benefits. Ethical ERP leadership protects privacy, maintains appropriate controls, supports vulnerable groups, and preserves human accountability when automation and AI are used.

The central strategic lesson is that ERP value is created after configuration and beyond go-live. It depends on sustained leadership, shared process ownership, continuous learning, disciplined governance, and the integration of new system-enabled practices into everyday organizational work.

Key Terms

ERP transformation: Organizational change involving integrated enterprise processes, data, controls, and technology.

Executive sponsorship: Active senior leadership that provides direction, authority, resources, and visible support.

Stakeholder: An individual or group that affects, is affected by, or perceives an effect from the ERP program.

Governance: Structures and processes for allocating authority, accountability, decision rights, and oversight.

Process owner: The person accountable for the design, performance, and improvement of an end-to-end business process.

Data owner: The person accountable for the definition, quality, access, and appropriate use of a data domain.

Change coalition: A group of leaders and influential participants that guides and legitimizes transformation.

Organizational culture: Shared assumptions, values, norms, and practices shaping behavior.

User adoption: Sustained and correct use of the ERP system and its associated processes.

Super-user: A knowledgeable operational user who provides local support, feedback, and coaching.

Resistance: Behavior or opposition that delays, challenges, or prevents intended change.

Change readiness: The extent to which an organization and its members are prepared and willing to implement change.

Competency: Integrated knowledge, skill, judgment, and behavior required for effective performance.

Benefits realization: The process of measuring and managing whether intended business benefits are achieved.

Workaround: An unofficial method used to avoid, supplement, or bypass an intended system process.

Segregation of duties: A control principle that separates incompatible transaction responsibilities.

Master data: Core shared data entities, such as items, suppliers, customers, employees, and accounts.

Institutionalization: Embedding new practices into routines, structures, incentives, and organizational norms.

Review Questions

Short Answer Questions

1. Why is ERP implementation considered a socio-technical transformation rather than a software installation?
2. What are the principal responsibilities of an ERP executive sponsor?
3. How does a process owner differ from a project manager?
4. Why is training attendance an inadequate measure of user adoption?
5. Identify two ethical risks associated with ERP-enabled employee monitoring.

Long Answer Questions

1. Critically compare Lewin’s three-stage model, Kotter’s process perspective, and ADKAR for managing ERP change.
2. Explain how governance structures can reduce conflict between enterprise standardization and local operational requirements.
3. Discuss the relationship between organizational culture, role redesign, competency development, and ERP adoption.
4. Design a communication and training strategy for a multinational organization implementing a cloud ERP system.
5. Explain why resistance should be diagnosed as potentially rational and describe appropriate responses to its different forms.

Analytical / Application Questions

1. An ERP project has achieved 95% training completion, but only 62% of users complete transactions correctly and 30% of sites maintain parallel spreadsheets. Diagnose the likely causes and propose a 90-day intervention plan.
2. A manufacturing organization wants to centralize item-master governance, while plant managers argue that local flexibility is essential. Develop a decision framework that balances standardization, legal requirements, operational performance, and data quality.
3. Design an adoption dashboard containing at least six measures. For each measure, identify whether it is a leading, behavioral, or outcome indicator and explain one limitation in interpretation.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the strategic role of ERP leadership?

A. Ensuring that the vendor completes configuration on schedule

B. Creating direction, legitimacy, resources, and cross-functional commitment for transformation

C. Delegating all process decisions to the IT department

D. Replacing business-process owners with project administrators

Correct Answer: B. Creating direction, legitimacy, resources, and cross-functional commitment for transformation

Question 2

What is the primary accountability of an ERP process owner?

A. Managing the software vendor’s contract

B. Approving every employee’s training request

C. Designing, monitoring, and improving an end-to-end business process

D. Maintaining all network infrastructure

Correct Answer: C. Designing, monitoring, and improving an end-to-end business process

Question 3

Which activity best represents meaningful stakeholder participation?

A. Sending a general announcement after configuration is complete

B. Inviting users to observe a demonstration without collecting feedback

C. Involving representative users in realistic process testing and design decisions

D. Allowing only executives to define local operational requirements

Correct Answer: C. Involving representative users in realistic process testing and design decisions

Question 4

In the ADKAR framework, a user who understands the reason for change but refuses to support it primarily lacks which element?

A. Awareness

B. Desire

C. Knowledge

D. Ability

Correct Answer: B. Desire

Question 5

Why should resistance to ERP change not automatically be treated as an attitude problem?

A. All resistance is legally protected

B. Resistance may reveal defects in process design, data, workload, or fairness

C. Users are never accountable for bypassing controls

D. Resistance always improves implementation speed

Correct Answer: B. Resistance may reveal defects in process design, data, workload, or fairness

Question 6

Which training design is most likely to support ERP learning transfer?

A. A single generic lecture held several months before go-live

B. Role-based practice using realistic end-to-end business scenarios

C. A vendor brochure distributed to all employees

D. Training limited to senior managers

Correct Answer: B. Role-based practice using realistic end-to-end business scenarios

Question 7

If 176 of 220 observed users perform a required ERP process correctly, what is the adoption rate?

A. 60%

B. 70%

C. 80%

D. 90%

Correct Answer: C. 80%

Question 8

Which is a behavioral indicator of ERP adoption?

A. The approved business case value

B. The number of users completing required transactions correctly

C. The number of executive steering meetings

D. The vendor’s software-release frequency

Correct Answer: B. The number of users completing required transactions correctly

Question 9

What is the main purpose of segregation of duties?

A. To ensure every user has unrestricted access

B. To separate incompatible responsibilities and reduce control risk

C. To eliminate the need for process ownership

D. To maximize the number of approval steps

Correct Answer: B. To separate incompatible responsibilities and reduce control risk

Question 10

Which practice best supports sustained ERP value after go-live?

A. Declaring success once the system is available in production

B. Stopping communication to encourage independence

C. Continuing adoption measurement, support, learning, and benefits realization

D. Allowing each department to create unofficial parallel processes

Correct Answer: C. Continuing adoption measurement, support, learning, and benefits realization