Training and Change Management Cost on IBM i Implementations
Why training costs more than classroom hours on an IBM i implementation, especially for 5250 green-screen users, with four shop scenarios and how to budget for the change.
Training gets underbudgeted because it's priced as classroom hours. The bigger cost is the productivity your most experienced people lose while they relearn a job they could do half asleep on a 5250 screen, plus the time the business spends covering for them. Budget for that explicitly and training stops being the line item that surprises you after go-live.
Green-screen users aren't slow or stuck in the past. Many of them are fast, and that's exactly the problem. Heads-down entry on a 5250 runs on function keys, field exits, and type-ahead that people stopped thinking about years ago. A new interface can be better for the business and still make your best clerk slower for the first few weeks. Change management is the work of planning for that dip instead of getting ambushed by it.
The costs that actually show up are backfill and overtime while people train, a productivity dip after go-live, extra support in the first weeks (often called hypercare), and the process changes that ride along with the new software. None of those appear on a trainer's invoice.
Find your situation
Small shop
Twenty-five users, most with fifteen years on the green screen
Users
About 25
Tenure
Most 15+ years
Training team
None
Trigger
New release with a browser UI
Sound familiar?
There's no training department, nobody can be spared from the floor for a week, and the people who know the business best are the ones most worried about the new screens. The training line in the quote looks small, which somehow makes it more worrying.
What's really driving the number
In a small shop the trainer's fee is the cheap part. The real cost is backfill: overtime, temps, or work that simply waits while people sit in sessions. And because everyone is critical, pulling people out all at once isn't an option, so the schedule stretches.
What takes the pressure off
Pick two super users and train them deeply first. They become your in-house help desk, and their questions shape the training for everyone else.
Teach by role in short sessions scheduled around your slow periods, instead of full-day classes that empty the office.
Practice in a test environment loaded with your own customers, items, and orders. People learn faster when the screens show work they recognize.
Build a one-page quick reference card for each role's daily tasks.
If this is you
You don't need a training department. You need two people who know the new system cold, and training time actually blocked on the calendar.
Distribution
A warehouse running 5250 screens on RF handheld scanners
Users
60 office, 40 warehouse
Devices
RF handhelds, 5250 emulation
Busy season
Q4 peak
Trigger
New warehouse module
Sound familiar?
The office staff will adjust. The warehouse is the worry. Pickers move fast on screens they know by feel, the new mobile flow looks nicer and takes more taps, and someone has floated a fall go-live.
What's really driving the number
On the floor, a screen change isn't really a training issue. It's a throughput issue. If every pick takes a few seconds longer, that adds up in labor hours and late shipments across every order. Going live near peak season turns a normal learning dip into a customer service problem.
What takes the pressure off
Keep go-live well clear of peak season. A normal learning curve is fine in a slow month and expensive in a busy one.
Pilot the new scan flow on real picks with a few experienced pickers, and time it against the current flow so any slowdown is a number, not a guess.
Ask whether warehouse screens need to change in phase one at all. If the floor can keep a familiar flow while the office moves first, the warehouse changes on a quieter schedule.
Put a floor-level super user on every shift for the first weeks, not just a help desk number.
If this is you
Protect the flow that ships product. The rest of the organization can learn on a slower clock.
Mid-market
Moving 120 users from green screen to a browser interface
Users
About 120
Mix
Long-tenured staff and recent hires
Interface
5250 to browser
Trigger
ERP modernization
Sound familiar?
Newer employees can't wait. The veterans are pushing back hard, and it's starting to read as resistance to the whole project. Leadership is asking whether the rollout is in trouble before it has even started.
What's really driving the number
You have two groups with opposite experiences of the same change. New hires get faster because a browser feels familiar. Veterans get slower because their speed lived in keystrokes the new screens don't use. That dip is real, it's temporary, and it costs money in the first weeks through slower processing and more support calls.
What takes the pressure off
Measure how long key tasks take today, before go-live. Then "the new system is slower" becomes a number you can watch improve.
Ask the vendor which daily tasks can be driven from the keyboard, and show veterans those first.
Staff the first weeks after go-live with people walking the floor, not only a ticket queue.
Budget training and change management as their own line, not folded into implementation where they get squeezed first.
If this is you
The pushback usually isn't resistance to change. It's experts noticing they've been made temporarily slower. Say that out loud, measure it, and it gets much easier to manage.
Enterprise
Rolling out to five sites in waves
Sites
5
Users
600+
Rollout
Site by site
Trigger
Standardizing on one system
Sound familiar?
The training estimate looks like one site's cost multiplied by five. Every site thinks it's different, and some of them are. There's a real worry that each wave will reinvent the training and pay for it all over again.
What's really driving the number
The first site is expensive because it pays for the curriculum, the materials, and the mistakes. Whether sites two through five get cheaper depends almost entirely on whether that first investment gets reused. If each wave builds its own training, you pay the first-site price five times.
What takes the pressure off
Pilot with the site whose team is most engaged, not the biggest or the most troubled. The job of wave one is a curriculum that works.
Record sessions and build role-based materials once, then adjust only for the real differences at each site.
Have champions from each finished wave help the next site go live. People trust a peer who just did it.
Track support tickets per user by wave. If the curve isn't dropping, fix the materials before the next site.
If this is you
The first site pays for the curriculum. Set the rollout up so every site after it gets the benefit.
These scenarios are composites built from common IBM i project patterns and the published ranges on this site, not individual client case studies. Use them to recognize your situation, then get a scoped proposal for your own team.
What belongs under training and change management
Trainer or partner fees for sessions and materials.
Backfill and overtime while people are in training.
The productivity dip in the first weeks after go-live.
Floor support and extra help desk coverage after go-live.
Communication and process documentation for the changes that come with the new software.
Most quotes cover the first item. The rest are real whether or not anyone writes them down, which is exactly why they belong in the budget.