ERP rollouts
I run ERP rollouts from the business side, not the vendor side. My job is to make sure the system reflects the process that actually runs in the company — not the one written in the procedure or shown in the sales deck.
The rollout is under way, but scope is growing faster than progress and nobody can say when go-live happens.
The vendor's consultants talk about modules, your team talks about problems, and the two conversations never meet.
The system is live, but people work around it in spreadsheets because “Excel is faster”.
Quality was treated as an add-on during the rollout and now does not connect to production or logistics.
The data due for migration is in a state nobody wants to discuss out loud.
Target-state processes documented in a form the team can read, not just the consultant
A full set of test scenarios and a documented record of acceptance testing
Trained users and material they will actually reach for when they forget
A working quality area wired into the rest of the system
A list of deliberately deferred items with reasons, so they do not return as surprises
Talking to the team and management, mapping the constraints: people, systems, deadlines and budget.
Mapping how the process actually runs, not how the procedure describes it.
What gives the largest effect for the smallest cost, in what order, and who owns what.
Working with users, piloting, training, correcting based on what practice shows.
Checking whether the change actually worked, then locking it into the standard.
Most of my hands-on work is on Infor M3, where I have spent four years leading a global rollout as Product Owner and Global Process Owner for quality. The method itself is system-agnostic: process analysis, requirements, testing, migration, training and stabilisation look much the same in SAP, IFS or Dynamics. What differs is the terminology and what the system does out of the box.
Yes, and it is a common moment to bring someone in. I start by establishing where the project actually is rather than where the schedule says it should be: what has been tested, which decisions were made, what the team has not said out loud. The problem usually is not the system — it is scope that grew without a decision, or a process nobody described before configuration started.
No. The consultant knows the system; I know your process and manufacturing from the inside. I sit on the business side and make sure what gets built can actually be used in the company. I add the most value exactly where those two perspectives diverge — and they almost always do.
It depends on scope and the number of sites, but duration is a poor measure here. The better question is whether the first phase has a scope that can be closed. Rollouts derail not because they were planned too short, but because scope grew mid-flight without anyone deciding what gets dropped.
Describe what is happening in the process and what you have already tried. I reply within one business day.
