Why do many ERP customers under-invest in training and change management?

I agree, all great answers. Being an ERP solution provider, the total cost of the solution is very often one of the most critical elements that determines whether a deal is won or lost. It is a rare case, but it has happened, that a company will say "we don't want to skimp on the implementation/training hours." More often it is, "we don't need as many hours as the average company, because we have used ERP systems before".

While we have completed full implementations in 40 hours, 80 hours or 100 hours, for a small company, we feel that a minimum of 120 hours is typically required from "kick-off" meeting" to "go-live". The 120 hours includes process discover/consultation/finalization, implementation, training, and first month-end close support (i.e. soup to nuts). Unfortunately, many companies insist that they don't need that many hours, so about 9 months ago I inserted a disclaimer on all our quotes that essentially says 120 hours is the minimum recommended hours and anything less may require the purchase of additional hours. This disclaimer has actually helped as much internally as externally, because my customer support team would always complain to me "why do the sales people sell so few hours; it won't be enough". At least, now they know that we don't recommend fewer hours.

As a final comment, in some cases, to ensure that the business relationship gets off on the right foot, I have "eaten" professional services hours.

I agree, all great answers. Being an ERP solution provider, from my perspective, the total cost of the solution is very often one of the most critical elements that determines whether a deal is won or lost. For being such an important long-term investment, one would think that cost while important, and assuming that the competitor's pricing is all within the same ballpark, there are so many other elements to consider that should ultimately drive the decision.In addition, the best way to leverage any enterprise application is to ensure that it gets deployed properly.

It is a rare case, but it has happened, that a company will say "we don't want to skimp on the implementation/training hours." More often it is, "we don't need as many hours as the average company, because we have used ERP systems before".

While we have completed full implementations in 40 hours, 80 hours or 100 hours, for a small company, we feel that a minimum of 120 hours is typically required from "kick-off" meeting" to "go-live". The 120 hours includes process discover/consultation/finalization, implementation, training, and first month-end close support (i.e. soup to nuts). Unfortunately, many companies insist that they don't need that many hours, so about 9 months ago I inserted a disclaimer on all our quotes that essentially says 120 hours is the minimum recommended hours and anything less may require the purchase of additional hours. This disclaimer has actually helped as much internally as externally, because my customer support team would always complain to me "why do the sales people sell so few hours; it won't be enough". At least now they know that we don't recommend fewer hours.

Unfortunately for me, in some cases, to ensure that the business relationship gets off on the right foot, I have "eaten" professional services hours rather than getting into a heated discussion on why the hours required were more than the quoted hours.In addition, training the customers right, saves time on the back-end as there will be fewer calls into our customer support organization.

A company does not know, what a company does not know. In my humble opinion; lack of ERP experience, and knowledge base is why it happens so much. One factor; many times, the sale of the software and implementation services not only comes down to best fit, but also total cost is a major factor. Unfortunately, training and change management requirements, and the importance, is an area that has been glossed over for an attractive total cost, and competitive bid. Underestimating training and change management can certainly cause disastrous consequences (yes, I've seen it). When it comes to ERP, and what it takes to be successful, it is critical for a company to bring on board an ERP specialist (prior to the software selection stage) who has solid knowledge and experience in ERP, including; training requirements and options for cost effective training, change management, and risk management.

There are a variety of reasons. Some of the most common are:
1) The initial planning and schedule includes training and change management, but as the deliverables continue to slip, eventually the training and change management components get jettisoned to "deliver" the project closer to the original timeline.
2) The executive sponsor is trying to cut corners on cost, so training will be done by internal people after project delivery, which of course rarely happens.
3) The implementation is done (or controlled) by internal people with little or no experience who don't consider training and change management to be important.
4) As a subset of the last, if the company doesn't currently have any training or change management programs for anything else, the ERP likely won't be the first.

Training and change management add both time and cost to the project, neither of which seems important to people without experience in implementing complex applications. Sometimes those people are the project managers, but more commonly they are executives trying to get the project done faster and cheaper.

Michael - I think Paul's comment about schedule conflicts may be one of the root causes. As the schedule slips and budgets are overrun when the white smoke appears in the chimney to say the system is ready the customer may feel compelled to rush to get the system running. The total cost of the project may have been underbid too as cost is always a factor in selection. But ultimately, I think the sheer scope of change management is misunderstood by the customer and misrepresented by the SI and/or software vendor. The UX of these massive systems is negative as simple tasks previously done are now complex and overwhelming. If the user doesn't have constant interaction with the system the learning curve must continously be climbed at every new exchange.

Hmm. I think the answer is more simple. We are uncomfortable with the "peopley stuff". We want a silver bullet that creates the changes we want. The process of overcoming resistance and change is not a well developed skill in most organizations.
That is why we have invested billions in strategies like lean, Six Sigma, etc and not seen the long term sustainable success we should have.
Technology is a tactic. You work with and lead and manage people.
Our scores and productivity losses due to disengagement are horrendous, but we keep trying to apply technology solutions to people issues...

I would suggest that it is not just ERP where the under investment occurs. There seems to be a "blind spot" with training on any IT project.

I've heard a number of different comments from senior managers, but they essentially boil down to "We don't believe that it's necessary to train people to use IT; we don't need them to be IT experts". I consider most of the training is not actually about the IT; most of it is about the business process and the IT side of it is just a small proportion of how the process is completed.

There is also a tendancy for senior managers to think that they are IT experts just because they can pick up an email on their iPhone / Blackberry. Unfortunately, there is often a serious lack of indepth knowledge of many key areas, and I would suggest that a lot of decisions are made based upon a faulty understanding of the issues.

I would also suggest that in a lot of cases, senior managers do not even understand how their existing processes actually work, either abstractly or in practice. They seem to assume that what they believe to be the way that things should be done, is the way that everyone else does it; and therefore, why would you need to re-train staff?

The answer is all tied up in our desire for instant answers and even more rapid results. Training (not to mention education)takes time and cost money. It is so much easier to get training from the vendor at a free seminar (or the like) and beleive that it is adequate. I think the late George Plossl said it best - "If you thin education is expensive, try ignorance!"
Change Management is underfunded because Management tends not to understand it or appreciate its impact on the enterprise. When one approaches Supply Chain there isa third area ythat is under funded: Risk Assessment & Management. This can really kill a company.
Leo Roth Klein

Bob,
I enjoyed your answer. It is both clever and smart to add the disclaimer. if it gets them to recognize the importance of training then it is the right thing to do.
But (and there always is a "but") do they also spend the time on education? I distinguish between the two as follows. Training tells you which button to push; education tells you what you want to push it in the first place. It may be a replacement ERP, but how many of the people who may have recieved training (or education) the first time around are still with the company? Even better, what percentage were not with the company then?
MCS is not a supplier of software either directly or indirctly so I do appreciate that from wence you come. We do education (non-vendor specific - not training)specializing in supply chain. You can find us at "mcs4scm.com"
Leo (CFPIM, CMfgE and others)

Thanks Michael and Leo; much appreciated.

Leo, with regards to education, it really tends to be a similar theme. Ater the initial deployment of the ERP solution, employee turnover inevitably occurs. Some companies have documented their processes and procedures very effectively, so the "hand-off" or knowledge transfer to new employees goes smoothly. Other companies have problems in knowledge transfer and then problems tend to surface.

Education really should be an ongoing investment. Unfortunately, while some companies will acknowledge the problem as their own and have their employees trained, other companies will blame the ERP company. Please note, I am not complaining as every company has issues with which they encounter. I am just providing another perspective.

Regardless, each situation needs to addressed indivually as their no generic answer. If the customer has a history of the situation, it is handled one way, while another company might be handled differently. For instance, just last week I sent a sales engineer to a customer in MN, at no charge, that has been off maintenance for a few years and where complaining about the software. They have a new CEO who was assessing the situation so I called him and offered 2 days of free training and process consulting so he can make a more intelligent evaluation. The meeting went great, he was very appreciative and hopefully we will know soon if they will return on maintenance, upgrade to the latest release, and perhaps add additional users and modules.

Leo, one final point regarding the disclaimer. While I appreciate your thinking it was both clever and smart, the main reason for the disclaimer was Integrity. I don't want someone looking at the quote and thinking it is something we recommend.