Managing change during a system rollout: a training plan

Why change management matters when a system is being rolled out

Technical rollout often goes according to plan: the system is configured, data migrated, accesses given. But the next day people keep working the old way: maintaining parallel spreadsheets, calling out of habit, bypassing new steps. The system is live, but the impact hasn’t appeared.

Without change management the same problems usually surface: different departments interpret new rules differently, managers don’t set expectations, and employees don’t see what is now mandatory. Delays, data errors and team conflicts emerge because everyone pulls the process toward familiar habits.

Training is important but doesn’t guarantee adoption on its own. A person may know where to click but not understand why they must change the sequence of actions, where responsibilities lie, or what to do in ambiguous cases. If there are no clear answers, the old way wins.

Measure success not by launch, but by actual work being done through new processes. For example: requests are created only in the system, approvals follow new routes, reports come from a single source, and manual workarounds disappear.

Departments with high throughput and transaction volume (contact centers, sales, procurement, accounting) and teams at boundaries (logistics, warehouse, support) tend to revert most often because they face many exceptions and dependencies. These areas need clear rules, start-up support and checks that the new routine becomes the norm.

Roles and responsibilities: who owns adoption

Adoption rarely happens by itself. If roles aren’t assigned in advance, people wait on each other: business waits for IT, IT waits for users, and users keep doing the old job.

A sponsor is needed not just to sign the budget. Their job is to remove blockers the team can’t resolve: approve priorities, allocate people for training, agree cross-departmentally, back unified rules and publicly confirm the new system is the required way to work.

It’s important to distinguish the process owner and the system owner. The process owner defines how the work should look (steps, roles, deadlines, KPIs) and decides when a process is ready to launch. The system owner manages settings, access, directories, integrations and stability, but shouldn’t unilaterally rewrite business rules.

The implementation team’s job is to get to launch and the first weeks of operation: configure, train, prepare instructions, collect feedback and fix critical issues. Support takes over once work is steady: they handle requests, maintain the knowledge base, monitor updates and service quality. The line is simple: implementation makes it right and teaches; support helps daily.

Adjacent functions are often underestimated. HR helps with training schedules and embedding responsibilities into roles. Security reviews access and data-handling rules. Internal trainers make materials understandable. Internal control and compliance agree in advance how to validate operations and store documents.

To avoid fuzzy expectations, record five answers up front: who approves the process, who resolves inter-department disputes, who owns accesses, who accepts the system into operation, and who is responsible for adoption metrics after launch.

Who is affected: quick stakeholder breakdown

Start with people’s actual actions, not job titles. The same person can be an executor, an approver and responsible for reporting. If you don’t see that, training will miss its mark and the process will start to crumble in week one.

Group users by function: who enters data, who checks and approves, who prepares reports, who handles customers and inquiries, who manages directories and rights, and who is responsible for control and compliance. This makes it easier to decide which scenarios to practice and where error risk is highest.

Then make a practical influence map. Usually three groups emerge:

• amplifiers: people who speed up adoption (shift leaders, experienced operators, go-to advisors)
• blockers: owners of old files and manual procedures, final approvers, those given extra responsibility without time
• neutral but critical: IT, security, accounting, HR, quality

Before training, collect a few facts for each group: pain points (what wastes time), fears (making mistakes, fines, doing it wrong), time constraints (period close, season, peak hours), and working conditions (one PC shared, access only from internal network, phone restrictions).

Consider branches, shift work and remote teams separately. In a two-shift branch, short 45-minute sessions at shift handover and one common scenario on a test system often work best. Resistance is lower and adoption chances are higher.

Training plan: what to include and how not to overload people

A good training plan isn’t about showing the system. It’s about enabling people to do their work under new conditions without wasting time guessing. Focus on three things: how to perform operations in the system, which rules change (deadlines, approvals, responsibilities), and which roles appear or change.

To avoid overload, split training into real-day scenarios. Not every menu, but: what I do in the morning, how I create a request, how I approve, what to do if data is missing. One scenario – one short objective and a clear outcome: after the session the person can repeat the steps independently.

Formats that work

A few simple formats are usually enough:

• short 30–45 minute sessions with demo and Q&A
• hands-on practice with examples from the department
• short 3–5 minute refresher videos
• in-person for key roles, online for mass users

Keep materials light. One one-page instruction for how to do X and a cheat sheet with common errors beats an 80-page manual. Use a single template: goal, steps, common mistakes, where to get help.

How to time training close to launch

Plan main training 1–2 weeks before launch, not a month prior, so skills don’t fade. 2–3 days before go-live give a short refresher on critical actions and a checklist for day one. After launch provide in-work support: quick reviews after the first 3–5 days and targeted sessions where errors are frequent.

Superusers: how to select, train and keep them motivated

A superuser is not the most technical person. They are someone who helps the department adopt new rules. They translate project language into daily tasks and ease tension in the first weeks.

How to choose and how many you need

The best candidates have team respect, patience and good process knowledge. They must be actually available; otherwise the role becomes formal.

A guideline: one superuser per 10–15 active users. With shifts, have at least one per shift. If processes differ significantly (procurement, warehouse, accounting), assign at least one per key process.

Look for simple criteria: colleague respect, calm communication, understanding of process pain points, willingness to repeat explanations, ability to record issues and push them to resolution, and dedicated time (typically 10–20% during launch).

How to prevent superuser burnout

Agree rights and expectations from the start: which questions they resolve, where enhanced rights are needed, and where they only advise. Ensure time is allocated and confirmed with their manager.

Train superusers deeper than others: common errors, causes of failures, edge cases, control points and quick diagnostics. Training plus review of real department cases works well.

Formalize support: office hours, a single channel for questions and a clear escalation path (for example, issues blocking work >30 minutes go to the project team). Motivation comes from visible impact: public thanks, involvement in improvements and simple metrics (requests closed, errors eliminated).

Communications: what to tell people before and after launch

Communication is not sending messages for the sake of it; it answers three clear questions: what changes, why it matters to us, and how it will affect my work tomorrow.

Managers need boundaries: which processes become mandatory, how control will look, and what success means. Users need practical language: what steps in their tasks change, where instructions are, and where to get help. Support teams (IT, helpdesk, business admins) need rules for handling requests: priorities, response times, and what is a user error versus a system defect.

Explain why you’re changing without slogans and tie it to losses and goals: fewer manual approvals, faster request closure, fewer duplicates in Excel, unified data for reports. Example: previously a procurement request got lost in email chains; now status is visible in the system and forwarding chains are unnecessary.

Address fears openly: early mistakes are expected; they won’t be penalized; controls are for process quality, not blame. If changes do not mean layoffs and no such plans exist—say so.

A simple message calendar prevents overload:

• 2 weeks before: what changes, who is affected, how to sign up for training
• 3 days before: reminder, what to prepare, support contacts
• Go-live day: what works and from what time, where to write, what to do if things fail
• 3–5 days after: FAQs, quick tips, early results
• 2 weeks after: what was fixed from feedback, what is now mandatory

To collect feedback without drowning in chats, set one official channel and a simple request format (subject, step, screenshot, urgency). Agree that decisions and answers are published in one place so there aren’t multiple versions of the truth.

Step-by-step rollout plan focused on process adoption

You need a simple plan that checks the main question: are people actually following the new processes or bypassing the system?

1. Confirm processes and rules before training. Record who does what, which statuses and deadlines are normal, and which exceptions are allowed. If rules change during training, trust falls and questions multiply.

2. Run a pilot in one department. Choose a team with clear tasks and manageable load. In 1–2 weeks collect issues, refine instructions and fix access problems.

3. Train by role and verify readiness. Don’t teach everyone everything. For each role provide 3–5 typical scenarios and a short check: the person must demonstrate the task in the system.

4. Launch in waves, not all at once. Each wave should be manageable: responsible people assigned, materials ready, and success criteria clear.

5. Provide hypercare for 1–2 weeks. Hold daily short reviews: what broke, where people got stuck, and what decisions were made today.

Then stabilize: update regulations for the new process, move requests into the regular service contour, and keep routine monitoring of metrics (for example, share of operations in the system and number of workarounds).

Example: for a request system rollout, pilot accounting first, then HR, then procurement. For each wave verify rights, templates and approval routes so the next department doesn’t reinvent rules.

Monitoring adoption by department: metrics and signals

Monitoring adoption isn’t about finding guilty parties. It’s about spotting issues early and helping teams. Department-level visibility matters: workloads, scenarios and learning speed differ.

What to measure to see real adoption

Metrics tied to actions beat attendance:

• activity: share of users who log in and perform key operations
• scenario completion: percent of tasks finished end-to-end without rework
• data quality: number of errors, duplicates, missing mandatory fields
• timings: how long a typical operation takes before and after launch
• exceptions rate: share of operations routed outside the standard process

Normalize metrics per employee, per 100 operations or per shift to compare departments fairly. Set different thresholds for different functions so the report isn’t a “shame board.”

Control tools and risk signals

A mix of system reports, spot checks and short 3–5 question polls works well (is it clear what to do; where do you get stuck; what blocks you). Weekly reviews of 2–3 real cases per department are more useful than arguing opinions.

Signals adoption is weakening:

• increase in workarounds: “let’s do it the old way”
• return of manual tables and parallel records
• more task returns due to data errors
• repeated missed deadlines at the same step
• superusers overwhelmed with repetitive questions

Reinforcement includes more than training: update regulations, tie leaders to key operations and do light audits of the most important transactions (for example, 10 random operations per week per department).

Common mistakes and traps that derail adoption

Failures usually result from small management decisions that seem convenient early on, not from a bad system.

One trap is training everyone the same way. Accounting, a warehouse operator and a manager need different scenarios, terminology and pace. When everyone sees the full course, people get tired, remember the wrong things and revert to old habits.

Second mistake: appointing a superuser by decree without time or support. If the role depends on after-hours enthusiasm, the person will burn out and the team loses local help.

Third trap: launching without a pilot and without an honest list of what is Day 1 versus later. Users expect the new system to solve everything immediately. If some functions aren’t ready, trust falls and workarounds stick.

Another issue is no process owner. Departments argue about who can change steps and rules and the blame falls on the person doing the work. A simple record of who approves regulations, who owns data, and who decides in conflicts helps.

Finally, data quality matters. If directories, balances or customer cards are dirty, the system runs but delivers no value. Before launch check the essentials: key directories and mandatory fields, input rules (what’s allowed and not), owners for fixes and deadlines.

Quick readiness checklist before launch

Before go-live make sure people are ready not just to log in but to do the work under new rules. A good sign of readiness is being able to answer quickly: who does what, where to get help and how to know processes have been adopted.

Start with basics: role-based scenarios should be approved and tested on real examples. Not an 80-page manual, but short scenarios: what accounting does at day close, how a manager creates a request, how approval works, what counts as an error and what to do next.

Next—superusers. They must be assigned per department and shift, not just one person for the whole office. Each needs a clear escalation path: what they solve, what goes to IT or vendor, and expected response times.

Training often fails on coverage. The plan must consider shifts, branches and new hires who arrive after launch. For remote sites decide formats in advance: short sessions, recordings, and practical checks.

Before start agree how you’ll measure adoption and how often you’ll review numbers. A few metrics usually suffice: share of operations in the new system, number of workarounds (Excel, email), time for a key step and number of critical support requests.

Quick pre-launch checks:

• role scenarios approved and tested on real examples
• superusers assigned, know escalation and boundaries
• training covers shifts, branches and new hires (schedule and materials ready)
• adoption metrics configured, reporting cadence and data owner defined
• hypercare plan ready for first 2–4 weeks (channels, schedule, on-call rota)

Decide in advance what to do if metrics fall: additional role-specific training, temporary increased oversight by shift managers, scenario adjustments, or prohibiting old methods for a process—but only after root causes are fixed.

Example scenario: three-department rollout without fires

A company rolls out one system for finance, procurement and warehouse. The risk is everyone launching at once while people are not confident. To avoid a 24/7 fire, the rollout is cascaded with clear controls.

Two weeks before, assign 1–2 superusers per department. Train them on real scenarios only: period close for finance, request creation and approval for procurement, receipt and write-off for warehouse. Superusers then run short practical sessions in their teams: 45 minutes demo and 45 minutes hands-on with current tasks.

In the first 2–4 weeks monitor simple metrics by department:

• share of operations in the system (no workarounds) per process
• average processing time: invoice, request, receipt
• number of support requests per 10 users
• percent of tasks returned for rework due to errors
• who hasn’t logged in for 3+ workdays

Pack common problems into short answers so there is no panic: missing rights, approval failure, unclear field, balance mismatch, system slowness. Agree a route: first superuser, then support line, and critical blockers recorded in one log with deadlines.

After a month consolidate results: update regulations (what changed and who does which step), add quality controls (spot-check 5–10 operations weekly) and close convenience workarounds people created.

Next steps: what to do in the next 2 weeks

The first 14 days set the project’s tempo. If you agree simple rules now, change becomes manageable.

Start by capturing how work is done today. Don’t try to describe everything. Choose 3–5 scenarios that really hold departments together: creating a request, approving an invoice, month-end close, patient admission, issuing goods. For each scenario record who does each step, where the process stalls, and what the correct result looks like.

Simultaneously appoint superusers and officially allocate their time in schedules. If the role relies on after-work help, support will quickly fade.

A typical two-week plan includes:

• approve 3–5 critical scenarios and a verification method (what correct traces remain in the system)
• assign superusers per department and agree on 10–30% time for early support
• prepare training: one-page instructions, 2–3 typical cases, list of frequent errors
• schedule hypercare after launch: single request channel, office hours, escalation owners
• set up adoption reporting: weekly slices for 30–60 days by department

Agree which signals count as problems (rise in Excel workarounds, overdue tasks, drop in system transaction volume).

If you lack people for training and hypercare, involve a system integrator. For organizations in Kazakhstan GSE.kz can cover these tasks as part of system integration and 24/7 follow-up support so users have a clear backbone in the first weeks.