What 20 Years of Building High-Performance Teams Taught Me About IFS Cloud User Training
Most ERP user adoption problems aren't training problems. They're diagnosis problems.
I learned that the hard way and the right way leading teams across the Marine Corps, field service, and asset-heavy operations. Twenty years of building high-performance teams taught me one thing above everything else; you don't prescribe until you understand what's actually broken.
What the Marine Corps taught me about diagnosing before prescribing
Early in my career I was responsible for a maintenance unit carrying real operational pressure. Two specific scenarios come to mind.
The first, procurement errors that were costing us in multiple directions bad orders, excess carry cost, downstream delays. The easy call would have been training and check the box. Instead, I assessed what was actually driving the errors. What I found was a combination of process gaps and habits that hadn't been challenged. We addressed those specifically. Procurement errors dropped 30%. Carry cost came down with them.
On the same team, we were struggling with preventative maintenance turnaround. The bottleneck wasn't effort it was the setup. Through training and development, we streamlined the process, developed kits, established standard tooling. Turnaround times improved because we removed the friction, not because we lectured about urgency.
Neither outcome came from a training course alone. They came from understanding the actual problem first.
When I moved into field service
Sending someone to asset-specific technical training is always a calculated decision. Time off away, cost, disruption to the team leaders stall on it more often than they should. I've been there.
In one case, I didn't stall. An opportunity to send a new technician to targeted asset training presented itself, and we invested it. Within less than two months, the team had recovered the full cost of that training through improved diagnostic accuracy and reduced rework.
Full ROI in under 60 days.
That number mattered not just as a financial result, but as a case that needed to be made internally. Investing in your people's technical capabilities isn't overhead. It's a performance strategy. The return is measurable if you're willing to track it.
When I led a maintenance operation with real gaps
I inherited a team carrying significant technical gaps and a culture that had quietly normalized underperformance.
I didn't start with a training catalog. I started with an honest assessment of where the gaps actually were, what each person needed, and what the workflow could realistically support. From there I built a multi-source development program that pulled from OEM resources, internal subject matter experts, and structured on-the-job exposure calibrated to close the specific gaps I'd mapped.
The results were operational. Asset uptime increased, rework came down, and the team started producing at a level they hadn't before.
What I hadn't anticipated was the cultural signal that sent. Transfer requests started coming in from other facilities. People wanted to be on this team.
The other thing that environment forced me to figure out you cannot pull a busy operations team off the floor for training and expect it to stick. I got creative about how we integrated development into the flow of actual work so learning happened through exposure and experience, not just in a classroom. That approach embedding training into the natural rhythm of the operation became one of the most consistent elements of everything I've done since.
What carried into consulting
The same principles that worked in those environments didn't stop working when I moved into consulting. Some of my best results have come from applying the same framework assess the actual gaps, understand what the team can absorb, and design learning that flows with the work rather than working against it.
For organizations implementing or coming off an IFS Cloud go-live, this is where the gap is most costly and most overlooked. End-user training at go-live gets the team functional. It rarely gets them capable. The difference shows up six months later in the support tickets, the manual workarounds, the under-utilization of modules that were supposed to eliminate those exact problems.
The training needs analysis I run now is designed to surface that gap clearly, before the cost compounds.
Why I'm writing this
What I described above used to live in my head accumulated across twenty years of leading teams in environments where underperformance had real operational consequences.
It's formalized now. The methodology is documented, repeatable, and built on outcomes I've watched happen across multiple industries. I know it works because I've seen it work under pressure, with real teams, against real deadlines.
If your team went live on IFS Cloud and is still reaching for external support on problems, they were expected to own that's a training design and knowledge gap problem, not a people problem.
The right place to start is an honest assessment of where they actually are.
If that's a conversation worth having, I'm easy to find.
IFS Cloud User Training
Comments