A reader of Why New Systems Fail asked me the following question:
I am about to start in the PMO for a multi-site manufacturing organization. We are a very large player in the medical diagnostics sector doing a SAP implementation. I read Why New Systems Fail on the plane back from the US to Germany last weekend. Most impressive I must say and something I will be immediately recommending within our larger organization. You hit the nail on the head in almost all areas.
I have one burning question which I felt was not covered in much detail. It concerns whether user training should be (or should “best” be) either process-based or role-based.
From what I gather from my predecessor, the first release of the program went the process-based approach. That is to say that they trained the users along the whole process e.g. everything in SAP Materials Management (MM) that one could want to know. Afterwards the complaint (lesson learned) was that the user knew very well about the end-to-end processes and how one lever affects many other things in ERP systems. The users felt however that they did not know enough to do their specific jobs and thus struggled for some time.
In the second release (just after going live), the program did role-based training–i.e., very specific screen-by-screen training (and well documented) but very specific to everyone’s role and job. Again people were not happy with these either because they felt they knew their own bit but not much about how they got their data or how it gets processed further by other functions. They were missing the overview which the release 1 people had but did not always appreciate! Catch 22!
Now the 3rd release site comes to me on my first week on the job wanting the same process training as release 1! The problem is that because we have quite decent change control discipline (a good thing) and that the 3rd release goes live in Feb 2013 there is really no time or budget to redo all the training again to process based because the scope for release 3 training is currently the same as 2.
In my heart I have to believe that my predecessors probably went to both extremes in each release (for the best of intentions) and that really a hybrid approach would have been maybe more effective. At the same time I know very well that you can never please all the people and sometimes none of the people. I am certain this stalemate is going to cause me problems and would like to know how very experienced consultants handle such a situation.
Of course we can use the heavy hand approach and simply deny the change. I can see this being a major hurdle, especially during Christmas.
Any tips on how to handle such a situation?
I know a thing or two about training, having taught more than 100 classes in an organizational setting in my career. Training is never perfect; something is always lacking. The question on these types of projects is typically: Was the training really so bad, so ineffective that people wouldn’t be able to do their jobs once the application went live? If the answer is truly yes, then kudos for the attendees for calling this out. Going live without sufficient knowledge of how applications work is a recipe for disaster.
However, I have rarely found training to be all that bad if the following hold true:
- The training environment was functioning properly. (Sadly, sometimes not a given). An unstable training application will almost always lead to a choppy class—and disaffected employees.
- Attendees were able to leave their day jobs at their desk during the class.
- The class was taught by a knowledgeable and friendly trainer.
Was this the case? If the answers here are yes, then I wonder if the issues here were actually culture and change management–not training.
Training is often the scapegoat for all sorts of personal, resource, and political issues.
Training is often the scapegoat for all sorts of personal, resource, and political factors vitiating projects like these. Jane doesn’t like the new system and has her mind back at her office. John took calls and answered emails during the class.
Now, to answer your question more directly. There’s a reason that I don’t address it in the book. Ideally, there’s no distinction between role- and process-based training. I would sure hope that the CIO here isn’t running payroll and the head of HR is handling key procurement and accounting processes. Organizations ought to align their roles and processes. If there’s a big disconnect here, then I’m not surprised that there were major training issues—and problems well beyond any individual class.