When outside training consultants assess ERP implementations already in progress, they act very much like doctors. First they ask the patients (in this case the CIO, project teams, HR and training leads, etc.) what they are experiencing. Then they poke into a few areas looking for pain points and performance issues. They run a few tests to see if the surface symptoms match the deeper issues, and go further to uncover underlying training issues that might not yet have appeared as symptoms to the naked eye.
To complete the analogy: Most of us have a handy “medical symptoms” guide or have bookmarked a Website to help us determine if that pain in our stomach is likely appendicitis, indigestion, or something far worse. The next step is to consult your physician. In the same vein, if you believe that training is or could be affecting the output of your ERP implementation, then you should immediately contact a reputable ERP training consultant.
In the meantime, consider this your handy guide to ERP Training Symptoms.
Symptom 1: No Immediate Pulse
For large-scale implementations, such as SAP, training is often packaged as part of the original proposal. The training elements are line listed with specifics, matched to each phase on the implementation plan (in SAP R/3, this implementation plan is called ASAP). And, in the best case, this includes a plan for customizing the training plan and matching this to internal and external resources.
More often, however, training is bulleted as a vague deliverable towards the bottom of the proposal and no insights or specifics are provided as to how training will be designed, documented or delivered. Even worse, the client organization, which is spending millions of dollars on an ERP implementation and, even more importantly, is counting on the output of this system to meet key organizational goals, has no idea what percentage of their contract is allocated to training, nor of any ROI or metrics assigned to the training.
What can you do? Before you sign the contract, ask the integrators to provide allocated budget and resource details — as well as a timeline as to when the project teams will be trained and when the end-user training schedule will be provided. (Commonly this occurs when defining the business processes.) We also highly recommend you get a third-party review of this training plan and process. Think of it as a second opinion by a specialist, which is always recommended before any major operation.
Symptom 2: Empty Exercise Plans
Interviewing the line managers will help determine if the exercise plans accurately reflect what the end users will do on the job, i.e. matching real-world processes and functions, but a quick assessment of exercise plans often shows that this data is not even in place.
While starting with a template makes great sense, the template is not a plan in itself. If you are six months from pilot/rollout and these are still empty shells (in SAP terms, this would mean not having Business Process Procedures, or BPPs, in place), you will be scrambling to complete them in time for end-user training. The less time you have to do so, the less accurately they will reflect the real-world processes and procedures and the more problems you will see at post go-live.
Symptom 3: Disappearing Resources
Before every ERP implementation is funded, the organization creates a business case detailing the ROI, output and impact of the system. This document should be the measuring stick by which all decisions are made. By assessing the decision making process as go-live nears, you will often see decisions being made that are solely designed to support meeting development deliverables and not the business objectives.
An example is reallocating resources from the training teams to software project teams with no set plans to replace those resources. We also see end user training being pushed back or, worse, marginalized to a series of task-based interactions that do not provide an understanding of the new business process and when and how they interact within that process. This causes expensive training issues and delays and/or decreases the impact the ERP will have on the business.
Symptom 4: The Legacy Loss
The training needs to clearly describe the bridge from the legacy system to the new process, how it will differ, and why. Assuming end users can move quickly from one system to another, without detailing the specific steps and reasons, is a symptom that the end users are not going to adopt the new system quickly or fully.
Note: there are also morale reasons to do so. By including end users in the new process you are telling them their previous hard work and knowledge is appreciated. And they will open their hearts to better learn the new system.
Symptom 5: Information Overload
We have all sat through this class. The 7-hour “one size fits all” training that provides a good intro and then bores us for 5 hours until we hit the 20 minutes that are relevant and valuable to our specific requirements.
Not only is it unproductive to have end users spend seven hours gaining what is really only 20-30 minutes of value, they also have to determine what portion of the training is relevant. Should they attempt to understand all this data, they will likely get only a vague impression of how to accomplish their unique tasks.
Symptom 6: Screens vs. Substance
If you are focusing solely or even proportionally too much on transactional based training versus task/process based training, you will end up with people who can work the screens, but are unable to understand when and how they are supposed to interact within the new business processes. The difference between being able to navigate the software screens and being able to use the ERP to accomplish functional needs is, often, why ERP implementations fail.
If your transactional versus process based training is out of balance, then your end users will have low performance metrics, jerry-rig the system to get the outputs they have had in the past, or gravitate back to the legacy system, if still available.
Symptom 7: Poor Metrics
This one is easy to diagnose. Look for the following: 1) The training ratings are low; 2) The documentation is rated poorly; 3) The end users are finding the system unwieldy and unproductive; and 4) Performance metrics post go-live are not in alignment with expectations.
What do most people do about this? They assume that performance and metrics will improve over time. They believe the training team will “hit their stride” and fix the documentation as they move forward. They also assume (or hope) that the end users will learn on the job while under fire. Things rarely improve. More commonly poor metrics continue to degrade.
Even if they improve over time, you have a document that outlines the business case and expected value timelines for the ERP system. Odds are, the word “eventually” does not appear. It is time to realign the training and the documentation to the business goals.
Symptom 8: Escalating Questions
Taking a lesson from call centers, look at the percentage of end-user questions that escalate upstream, in this case from the field managers to the help desk to the process teams. First, set metrics here and then monitor that this number starts low and decreases rapidly to near zero.
The more questions that cannot be answered at the local office, the higher the likelihood that your training is not effective. If you see a dramatic drop from any area, do not rush to say, “problem cured.” Check the performance metrics and compare the outputs and process to expectations. We have seen cases where this has meant the team decided simply to stop asking questions (or been told to stop) and, though the questions stopped escalating, the performance metrics remained subpar.
Symptom 9: All Your Knowledge in One Basket
This is the opposite of the “all training to all people” approach (See Symptom 5). In this case, the training plan includes no redundancy. People are trained on their tasks and their tasks alone, without taking into consideration two critical business needs: 1) They can do their jobs better when they know what the people up and down the process stream need to do their jobs, and 2) They might not be there every day or, worse, they might leave that job altogether.
At Caveo Learning, we use cascading lesson libraries, which provide end users with insight into both the input and output needs of their tasks, as well as making it easier for new staff to get up to speed. (It also dramatically improves flexibility for adding new processes and updates, but that is a story for another day.) While there are other ways to ensure you have coverage and that end users understand the inputs and effects of their tasks, you need to build in some overlap or redundancy. Not only does overlap help with process continuity, but it also builds teamwork.
Symptom 10: The Training Consultants are Noobs
The last symptom is the one that makes people angry…and for good reason. Larger integrators and consulting firms believe that ERP training is a great place for them to train their own staff on ERP implementations. As the CIO of a Fortune 100 company commented, “It’s common knowledge that a bus load of college kids shows up at this point.”
How can you determine the level of experience of the outside training consultants? Ask the training developers and trainers, directly, about their past work experience and educational background. If they sound like someone you would hire for that role, you are probably in good shape. If not, then ask the project lead to assign more experienced people.
Curing the Underlying Disease (Or at Least Measuring its Impact)
There you have it. Ten symptoms to help you self-assess the deeper issues that will lead to poor training and, as a result, a greater likelihood your ERP implementation will fail to meet stated timelines and business goals.
While it is easy to trim the training budget and make decisions at training’s expense, it is much harder to measure the impact of ineffective training. Or, in the cases where training deliverables were unmet, measuring ROI loss for what did not happen.
That being said, your business case and/or blueprint includes (or should include) metrics assigned to training and desired performance improvements at the functional level — and there are ways to forecast the likelihood of meeting these metrics by looking at how the efficacy of your training might affect them.
If you see any of the symptoms above, you have a training problem. That much is certain. What is uncertain is the size of the problem. Using the medical symptoms analogy at the beginning of this article, you are now faced with two choices: 1) Ignore the symptom and hope it goes away or causes only short-term discomfort, or 2) Better understand the underlying issue and take steps to cure it. Since training is the No. 2 reason why ERP implementations fail (lack of upper management support is No. 1), we humbly suggest any symptom of weak training be taken very seriously.
