Saturday, 9 April 2011

Learning the hard way

I got back late last night from our overseas site. The project lead and I made a trip over to check on how things were going, and to make arrangements for some later work.

The first issue was the cleansing and preparation of data. When we first did this for the initial project, we found that there were some key issues - getting the actual data extracted into a format that people could use, then getting the relevant departments to tackle the job of cleaning the data out so that we would have only good stuff to load.

We'd found that this was a lot harder than we had anticipated. Some of the data extracts from the legacy system were OK, but there were many areas where the different aspects of the data were not together in the old database, so it required some careful work and a lot of double checking in order to assemble the separate bits of data together. We made this point very clearly to the people at the new site - and gave them what we thought would be the right tools to help them.

Unfortunately, the extract has again taken a lot longer than we expected. In this case, they are dealing with an outside company on a system that we know little about, and the actual data only started coming thru about 4-5 weeks ago. They have been checking the data, but there is still a lot to do - the first couple of tests showed that they are not even close to having it ready for the full data load process which is supposed to start in 1 weeks time.

I'm not involved in it this time - one of my staff is doing the data load and I have virtually lost him for the next month whilst he processes the data. He is really confident and I'm sure that he will do it right - but I know from the work that he has done previously, that it will take more than just the next month to finish. He gets bored with things very easily and moves on to new stuff before finishing a job - I have to monitor him all the time and keeping reining him back in to make sure that he stays on track.

There is another concern as well - and it relates to the knowledge transfer process. I think that the big problem here is that several of the staff are still thinking in terms of how they do the various processes within their existing system. They then have got the consultants to show them how that specific process is done in SAP - and that is not the best way to approach learning the product.

When we first started, I read in several books that it was important to understand that implementing SAP is very different to many other products. To begin with, I probably didn't really see why that should be the case, but having spent a while working with it now, I can see that point that these people were trying to make. It's necessary to learn how to do it the "SAP way" and almost forget how things used to be done (yes, there may be exceptions).

I'd made that point on my previous visits to the site, but I don't think that they really understood what I was trying to tell them. As a result, they are still thinking on how the process was done in the legacy sysem, and then try to remember how that process is then done with SAP. I know that it is still early days, but I don't think that there is a single person yet that can actually complete a single process on their own, even if they are using the training material that they have.

I did speak to the project lead about this, but he doesn't seem to be too worried. His view is that they will pick up speed and they will all be ready by the time of their go-live. I'm not so sure - I don't think that they have had sufficient hands on experience with the consultants, and I'm convinced that whilst they may have seen a given process, they don't fully know any of them.

Unfortunately, our project lead has been working with SAP now every day for several years, and I get the feeling that he expects everyone else to know as much about it as he does. Even tho he has watched them and seen just how slow and uncertain they are, he is convinced that they will improve in a very short time. For me, I am a bit concerned that they won't keep up their practisng if we are not staying on top of them.

And that of course is going to be a big thing. We will of course provide some support for them, but it's going to be a bit difficult - certainly not as easy as when you are on a single site, or even a few hundred miles apart as long as you speak the same language. It will be much better for everyone if they are more confident in using the system before they go live.

I've also been told that it is absolutely essential they go live no later than the last week of July. It won't be possible for them to continue working with their legacy system after then. I did think about suggesting perhaps we should consider a backup plan in case we can't get the data load, and testing finshed by then, but it was pretty clear that this would not have a been a welcome suggestion.

I get the feeling that our project team are going to be earning a lot of frequent flyer miles!

1 comment:

  1. Yes, with SAP (and other ERP systems) it's 10 guaranteeed years of work.For many reasons.