I've been back to work for a few weeks, but have been a bit busy on a couple of non-SAP related projects. But as they are progressing well, I thought that I would return to an issue that has been bugging me (and others) for a while.
One of the most consistent comments from the project team and to a lesser extent from the end users, relates to the training that they receive in how to use SAP. Within the wider scope of a project, this is referred to as "knowledge transfer" and is seen as a key requirement for a successful project. In fact, this was identified as a major item right back at the beginning of the company plans to implement a new ERP system, even before the decision was made to install SAP.
The feeling is quite clear amongst the project team that overall, the level of knowledge transfer that has taken place is not what we would have wanted. Certainly, there were a few sessions where a couple of the consultants working on the project sat down with the various people and went thru the processes - but almost from the beginning, comments were made that far too often, these seemed to be very high level overviews rather than explanations of how to complete a specific process.
As a result of this, many of the various processes were never really tested properly or fully in the early stages. In fact, it can be identified that the real testing only took place finally about 3 months before we went live. Until that point, there may have been some limited testing such as placing a purchase order, but no-one would then use that data to conduct a goods receipt and warehousing process for example.
As is regularly stated, SAP is very integrated - making an entry in one module will have an affect in others, so it is vital to make sure that the linked processes are functioning correctly by a series of end to end tests. In order to carry out this testing work effectively, it is essential that people know how to complete the full process from a very early stage, but it seemed that at best, people were shown just limited steps within part of a process and often these were very generic items that in themselves did little to fully test anything.
In the end, we were pretty much left to our own devices to draw up a training plan, to put together the required material, and conduct end user training. A considerable effort was put in by my colleagues to make sure that their staff knew what as required and how they would be doing their jobs in future. Unfortunately, sometimes this was then invalidated by changes made by the consultants - they would do some configuration change, not actually test anything, and the first anyone would know was when someone was trying out a process that had previously worked, only to find that it suddenly didn't.
This happened a lot - far more than I would have liked. I won't say that it was a daily occurence, but certainly weekly for about 5-6 months (sometimes even 2-3 times in a week) before we went live. As you can imagine, this was immensely frustrating and caused considerable delays, perhaps unnecessarily - altho I am sure that there are those who will say that this is just part of a development process.
The reason that I highlight this is that we have had another issue recently. Suddenly, a process that has worked perfectly for almost a full year, now doesn't. A member of the finance team was left in tears because she was being blamed for not doing her work correctly - a job that she has been able to do completely satisfactorily every month for 11 months, she is now unable to do at all. It took a while to identify the cause, and it is due to a consultant working on something, making a change that he hasn't checked, but pushed thru to the Production system.
The modification is required - in fact it was required before we went live, but the consultants that are still on site have only just started to look at this specific item. Essentially, the config change means that a process has been changed slightly, and now we need to re-train other staff in sales support. They have to change the way that they work and do their process to meet the new requirements, so that this will go thru to the other areas, so that the finance people can then do their work. But of course, no-one has said a thing, none of the project team were aware of the change made, and no testing or training has taken place.
I raise this issue because I have made a point of getting my own staff in IT off to an SAP training center over the last year. We have completed a number of courses between us, and the cost in total has been just under $18,000, even with some travel, accomodation and meals - and that's still less than 12 days consultancy fees. Which is the better value? As far as I am concerned, we learnt far more at the training center and it was better organised, so for me it is pretty clear. It also has to be said that following the SAP training, we actually now know what we are supposed to be doing, which is more than could be said for the training we received from the consultants.
I've suggested many times, that it would make sense to get some of our project team off on some of these courses - possibly even some of the non-project team super users. I recently identified a series of 4 courses that would be of real value in a particular area of the business. The cost would be just under 5 days consultancy and I am fairly confident that the person I suggested for the courses would be able to pick up exactly what would be needed to get the best value from the courses and to ensure that he would be able then to pass that knowledge on to others.
Instead, the director from the SI firm has arranged with our CEO and internal project lead to have another one of his consultants come to site for 10 days to look at this specific module, get it set up and train the staff. As this is a guy that we have had on site many times before, we know what his area of expertise is - and it isn't this particular module. We know what capabilities he has in training and to be blunt they are pretty awful - several staff have stated privately that they don't like the guy as they consider him to be arrogant and offensive and there are female staff that really don't want to be part of the training if he is running it.
It also has to be said that he considers himself to be a jim dandy ABAP developer. I don't know sufficient about ABAP myself to measure his skill in that code, but I have worked with other codes and in software development, and I can say with some assurance that he just is not that good at doing program coding in a structured and managed way. He has taken it upon himself to make more than a few changes to code that have caused issues and it seems to take quite some time to get corrections to these problems.
It seems so odd to me - that senior management are willing to pay a substantial fee to a firm that have not exactly shown themselves in the best light, for a consultant that seems to cause more problems than he resolves. All this to work on an area that our own staff might well be able to do once they have had the right training, and which training will cost less than the consultancy fee.
It does seem that the senior managers have a blind spot in this - they value an external consultant in a suit higher than their own staff, even when the evidence doesn't seem to support their belief. I just find it so frustrating.
Subscribe to:
Post Comments (Atom)
This is a common and accurate complaint; the customer's internal project team does not get adequate knowledge transfer from the consultants during the project. There are many reasons for this and they reflect the way large IT projects are run these days. The pace of the implementations has quickened over the past decade leaving less time for adequate training. The projects are also more leanly staffed leaving the same amount of work for fewer people. I doubt those will change.
ReplyDeleteBut there are two other reasons why knowledge transfer often fails.
1. customers don't require it. As a consultant I have only had one customer in my 15 years say that knowledge transfer was a requirement to the project's success... "if we go live on time with a working solution but don't get knowledge transfer, then the project is a failure." Sure, it's on the project plan and there is some money tied up in it... but once you get into the 4th quarter of the project (see above: fast pace, little staff), the requirements for training, documentation, thorough data cleansing, etc. tend to fall off. The team tends to scramble to meet go-live.
2. Training is a two way street. Even if the customer tells me that training is truly required and I have the time to prepare enough documentation and maybe a scenario or two in the system (est: 50-100 hours), the customer has to be willing to meet with me to go over it. This the failure point. They have their own set of deliverables; the training is a consultant deliverable and not the customer's. So once I write up a 30 page doc on FICO configuration, the task is done as far as the PMO and my customer are concerned.
Once customers start requiring training and put an emphasis on their own staff to pick up the information we'll start to see some movement in the industry. Until then, there are 10,000 config guides sitting on sharepoint servers around the world but no one is looking at them.
-nathan
First, let me thank you for documenting your experience. It's been a fascinating read.
ReplyDeleteAs you've experienced, it's not easy to effectively implement any ERP solution and gain optimal adoption - for many of the reasons cited in your post and in Nathan's comments - but the problems here seems to span a plethora of topics from communication, project management, change-approval process and a commitment to user training - rather than just a training issue.
In prior posts you've talked about some of the executive involvement during the process from which I infer that they've been supportive and yet what's concerning is there's an absence of a willingness to have 'real ownership' of this internally (as evidenced by the constant seeking of external guidance.)
The problem with the traditional SI business model is that they benefit the longer they can 'camp out' in your project. When what's really beneficial to the client is that they 'teach you how to fish' so you can self sustain and maintain moving forward. These conflicting objectives have been the death of many projects and, without intervention from either party (and believe me, some SI firms will step up and force that knowledge transfer/ownership debate), I'm not sure your well documented experience will improve any time soon.
We'll keep following and hope to read a 'happily ever after' ending to your story. In the meantime, we wish you a relaxing holiday season.
With best wishes,
datango