Choosing and Supporting ERP Change Champions. Give champions time, clear duties and a route for raising issues.
A change champion can hear about an ERP problem before it reaches a project meeting. A colleague mentions that an approval route makes no sense on the late shift. Another admits that a practice task was completed only because someone supplied the answer. These signals are valuable when they reach someone who can act on them.
A network built only to distribute positive messages has no reliable way to handle those signals. A network expected to solve everything can become an informal support service with unclear authority and unprotected workload. Design the network around a narrower purpose: connect affected colleagues with accurate information and accountable resolution.
Three working tools make that purpose practical: a coverage map, a champion charter, and a feedback-to-resolution workflow. Together they answer who is represented, what champions may do, and what happens after someone raises an issue.
Begin with the work being changed. List affected roles, operating sites, shifts, languages, and working arrangements. Identify groups whose experience differs enough to require direct representation. A central office employee may not see the access restrictions, staffing constraints, or handoff problems experienced on a production floor.
The coverage map should show the primary champion, a backup or alternate route, the manager protecting their time, and the channels colleagues can use. Mark uncovered groups explicitly. One familiar name beside several sites does not demonstrate that the person can hear from all of them.
Choose champions for credibility, listening, and willingness to raise inconvenient questions. Knowledge of the current process helps, but the person who knows every workaround may need support in distinguishing a legitimate business need from a habit the future process intentionally changes.
Do not require constant enthusiasm. A constructive skeptic can reveal weaknesses in an explanation or an operating assumption. The relevant test is whether the person can listen fairly, communicate accurately, respect confidentiality, and help an issue reach the right owner.
Specify the activities champions are expected to perform. These may include explaining approved changes, demonstrating familiar tasks, collecting feedback, directing colleagues to support, and checking whether a communicated answer actually resolved the concern.
Define what must move to an accountable specialist. Champions should not independently change access, approve control exceptions, promise design changes, or interpret unresolved policy. They should know how to recognize these situations and where to route them.
Include a simple statement about uncertainty: a champion may say that an answer is not yet known and give the route for obtaining it. Inventing an answer to preserve confidence can create a larger problem when different teams act on conflicting instructions.
The charter also needs:
Review the charter with champions and their managers. A volunteer title without managerial agreement can leave someone doing two jobs while both sets of colleagues assume full availability.
Estimate demand from actual activities: preparation sessions, demonstrations, team conversations, feedback logging, resolution checks, and support during practice or launch. Include time away from the person's ordinary work and identify what will be postponed, reassigned, or covered.
Avoid promising a universal ratio of champions to employees. A useful arrangement depends on process complexity, working hours, distance, language, available support, and the extent of the change. Start with an explicit capacity assumption, then revise it using observed demand.
Give champions a route to report overload. Repeated unanswered questions, missed follow-through, and reliance on personal messages after hours may indicate that the network's workload exceeds its design. Managers should respond by changing coverage or routing, rather than praising extra effort while leaving the conflict unresolved.
Keep specialist support visible. If colleagues believe the champion is the only acceptable point of contact, incidents may wait while the champion is unavailable. Explain which questions can go through peers and which should enter formal support immediately.
Use a short record that preserves the original observation and adds a working classification. Helpful categories include a suspected defect, an unclear process or policy, a knowledge gap, an access problem, and a concern about operating consequences.
Treat the classification as a routing aid, not a verdict. An apparent training problem may be caused by contradictory instructions. A request for a familiar screen may reflect a missing decision input. Let the receiving owner revise the classification and explain why.
Capture enough context to make the issue actionable:
Do not record unnecessary personal details or circulate private employee concerns in a general issue list. Route employment, accessibility, harassment, or other sensitive matters through the organization's appropriate confidential channels. The network should connect people with help without turning informal conversations into broadly visible records.
An issue has been routed successfully when the receiving team acknowledges ownership and the next action is clear. Forwarding a message to a shared mailbox is weaker evidence. Establish how ownership is accepted, what happens if it is disputed, and who handles a request that crosses functions.
Set response expectations according to consequence and operating need. A blocked critical activity needs a different route from a suggestion for a future improvement. The responsible support and business owners should agree the categories and escalation triggers before champions are asked to use them.
Separate the owner of the fix from the owner of communication. A technical team may resolve a defect while a process owner explains the resulting procedure. The champion can bring the approved answer back to colleagues, but should not have to reconstruct it from a technical resolution note.
A declined request also needs closure. Explain the reason, any safe alternative, and whether the decision can be revisited if new evidence emerges. Silence encourages repeated submissions and makes the network look powerless even when a legitimate decision has been made.
Use a hypothetical late-shift receiving team as a rehearsal. Staff discover that a required approver is available only during daytime hours. A champion initially hears the complaint as a request for more training on exception handling.
The champion records the actual task and operating constraint, then routes the issue to the process owner. The owner confirms that the gap concerns approval coverage and asks the responsible manager to choose an authorized arrangement. Any access change follows the normal approval route.
Once an arrangement is approved, the relevant procedure and support instructions are updated. The champion explains the answer to the shift and asks staff to try the process in a suitable practice setting. The issue closes when the team can use the arrangement and the responsible owner accepts the evidence.
This illustrative example shows why a resolution loop needs more than a communications calendar. The champion contributes observation and follow-through; the manager and process owner retain operating authority.
Useful measures concern coverage, routing quality, aging, and closure. Review whether affected groups have a usable contact route, whether issues reach an owner, and whether people understand the answer they receive. Look at recurring issues to identify unclear instructions or unresolved design questions.
Interpret issue volume carefully. More reports may mean a deteriorating process, better visibility, or increased trust in the route. Fewer reports may mean improved operation or a network people have stopped using. Pair counts with examples, observation, and representative conversations.
Avoid ranking champions by the number of issues they close. They do not control every resolution, and the incentive may encourage premature closure or discourage difficult reports. Managers should assess the quality of listening, routing, explanation, and follow-through within the role's agreed boundaries.
Review the network's own friction. Are champions receiving updates before colleagues ask about them? Can they find the current approved procedure? Do receiving teams acknowledge issues? These questions often reveal a fix the program can make without asking frontline employees to do more.
Define which responsibilities continue after the transition. Peer learning may remain useful, while incident handling should move into a stable support model. Name the permanent owner for knowledge updates, recurring questions, and process-improvement proposals.
Reduce special duties only when the permanent routes are accessible and working. Tell colleagues what changes, where to go, and how open items will be handled. Thank champions through the organization's normal recognition practices, but also restore their capacity by removing duties that have ended.
A useful champion network leaves behind clearer routes and better operating knowledge. Start by testing one complete loop: a colleague raises a real concern, the right owner responds, the answer reaches the team, and the team confirms what to do. If that loop works, the network has something worth scaling.