Your People Were Trained. Can the Business Actually Run the New Process?

Training completion is not operational readiness

Transformation programs are good at producing evidence that training happened: attendance sheets, completion percentages, assessments and sign-offs. Those controls matter. They do not answer the harder question: can the business actually perform the new process when live volume, dependencies and pressure arrive?

This is why I separate Knowledge from Ability. Prosci's ADKAR® Model makes the same distinction. Knowledge is knowing how to change and how to perform in the future state. Ability is demonstrating the required skill or behavior in practice. Prosci notes that knowledge may take much longer to translate into ability.

Make the business own the knowledge

I prefer to build capability through business ownership rather than treat training as a service the implementation partner delivers at the end. Key users should learn early enough to understand what the platform and standard process can do before design decisions are locked. After the solution is built, they need a focused refresh on the actual configured process.

Closer to go-live, those key users should play a central role in training end users, supported by shadow or super users who also participate in testing and hypercare. The executive point is not who stands in front of the classroom. It is where the knowledge lives after the partner leaves.

When key users can explain the future process, coach colleagues and challenge an exception intelligently, knowledge has become a business asset rather than a purchased project service.

Training Needs Analysis is a readiness gate

Before any course, I want a real Training Needs Analysis: what is this person's role in the future state, what must they know, what terminology or digital skill may get in the way, is the device and authorization ready, and has the manager actually committed time for learning? If someone enters training without knowing their future role or without the tools to practice it, the program is burning training and will often blame the user later.

In several ERP programs in Egypt and the Gulf, I have seen excellent operational key users ask to withdraw because English terminology and unfamiliar system screens made them afraid of failing publicly. Management can read that as lack of cooperation. A little support with terminology, protected practice and reassurance can reveal the opposite: the person was committed enough to be afraid of letting the team down.

Ability belongs to the operating environment as well as the individual

A user can know the transaction perfectly and still be unable to complete it reliably. The constraint may be authorization, device access, master data, response time, staffing, upstream inputs or a hand-off owned by another function.

A team can pass a classroom exercise and still fail at operating volume. A process can be logically correct and still create a bottleneck when hundreds of transactions, approvals or inspections arrive together.

In one manufacturing go-live, the quality team knew the process and had trained its users. What we had not tested was the real volume: hundreds or thousands of inspection lots arriving with production receipts. The knowledge was there; the operating capacity was not. Quality release slowed, downstream work waited, and more training would not have solved the constraint.

That is why I do not treat Ability as a characteristic of the person alone. In enterprise transformation, demonstrated ability is produced by the person plus the process, tools, data, capacity and support environment around that person.

UAT, training and dry runs answer different questions

I like to keep three questions separate.

• UAT asks: does the configured solution work for the agreed scenario?
• Training asks: do the impacted people know what they are expected to do?
• A realistic dry run asks: can the operating model execute the process end to end under conditions close enough to reality to expose capacity, timing, ownership and hand-off problems?

Those are not interchangeable controls. A consultant clicking through a scenario while users observe may prove configuration. It does not prove operational capability.

A good dry run puts the people who will actually run the process into the flow, with realistic roles, data, approvals, timing and volume wherever practical. Failure in that environment is not wasted effort. It is early evidence.

The best dry runs expose organizational design problems

One reason dry runs are uncomfortable is that they expose problems that sit outside the system configuration. A role may be understaffed. A manager may not have decided who owns an exception. A master-data lead time may make the planning cycle impossible. A cross-functional approval may exist on paper but have no workable service level.

If the response to all of those findings is 'train the users again,' the program is treating an operating-model problem as a learning problem.

Post-go-live learning is different from pre-go-live learning

Before go-live, people ask hypothetical questions. After several days or weeks of real work, the questions change. Users understand the edge cases, the pressure points and the places where the written procedure does not match the operating reality.

That is why I value post-go-live training and coaching. It is not an admission that the first training failed. It is a different learning event, built on lived experience rather than anticipation.

The related article After Go-Live: How to Diagnose and Stabilize an ERP That Is Live but Not Running the Business covers how these capability and adoption gaps appear during stabilization.

Prosci's Ability guidance emphasizes practice, time, coaching, access to tools and feedback. Those elements matter because proficiency develops through supported performance, not through information transfer alone.

Readiness should include performance evidence

Before go-live, I want evidence that the system is ready, but I also want evidence that the business can run it. That may include transaction timing, realistic volume, cross-functional hand-offs, exception handling, availability of key roles and whether managers can support users when the normal path breaks.

The exact test depends on the process. The principle is consistent: if a critical future-state behavior has never been performed under something close to real conditions, the program should be honest about that uncertainty.

That performance evidence also connects to the Adoption level defined in Beyond Go-Live: Four Levels of Transformation Success.

The practical sequence

Build the knowledge. Create a safe place to practice. Test the process at realistic enough scale. Fix capacity, access, data and hand-off constraints. Support people after go-live. Then measure whether the behavior is becoming normal.

Training is necessary. Capability is demonstrated.