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!
Saturday, 9 April 2011
Sunday, 3 April 2011
...And yet another.
When we first started creating the roles for users, I took the advice of the consultants - but after a short while, realised that it was going to get a bit more complicated than I had originally expected. For that reason, I changed the names of the roles, using Z1 for those at our first site, Z2 at the second, Z3 at the third.
The reason for this was that we actually needed to define some limits to what people on each site would be able to do. We didn't want the staff at our second site to have the oppotunity to make changes to items from the main site. This seemed to work quite well, but then I found that some roles were getting very big - and at that point, I started to split the roles down.
We had a hierarchy - sales clerk, sales manager and added a couple of other items to this to allow some staff more access to do certain functions. So for example, 2 staff are involved in contract review, so we have a role for that. 2 other staff are involved in dealing with certain groups of customers, and that is a seperate role as well.
There were some issues right from the beginning, as the project team didn't really understand the concept of permissions - I would regularly be asked to give someone access to something, and when I pointed out that it was to the role that permission was granted, they would get very frustrated. However, it appears that for the most part, they now do understand and we do have a set of roles that serve our needs.
When we started on our first overseas site, I copied the basic roles from our second site, changed the organisational levels and applied user accounts to get them started as Z4. I felt that as we had most of the authorisations already confirmed, this would be pretty much what was needed. I sent details through to the relevant people, including the consultants that I had been told would be doing the necessary work, and waited for some minor changes.
Up until the first day of the work to go thru the processes with the staff, I had heard nothing. Later in the day, I received an email from a completely new consultant asking me to give permission for the staff member to have access to certain t-codes. When I checked, about 80% of those were already in the relevant role, and the member of staff had been added to the role. The few remaining were t-codes that we didn't actually use - we used different ones to do the same job.
I had several more emails requesting access, each time on the day of the process testing rather that before hand. In several cases, I pointed out that the t-codes being requested were restricted to certain people. It was decided that currency rates, period closure etc would be done centrally, rather than have different people at each site getting involved. However, I was also asked to provide access to certain t-codes that I was very reluctant to hand over - why would the staff members need access to things such as SCC4, STMS, SE16N just to name a couple. These are only for administrative positions, and I could see lots of issues if they had access to these.
What I didn't know was that the staff at our overseas site had made a complaint that they didn't feel that they were getting the relevant training they needed and this was passed to our CEO. He then discussed this with the director of the SI, who basically said that I was holding up the work by not providing the required access.
I was dragged into the CEO's office, and to be brief, he told me that the SI were insisting that I give all of the staff at our overseas site the profile SAP_ALL. I tried to point out that this was not good practice etc. but this cut no ice. I highlighted that we needed to get the roles right, but he had been told that this could be done afterwards - in order to get the site up and running as soon as possible, they needed SAP_ALL.
At that point, I told him that if he wanted this, I required him to put it in writing - and I thought that he was going to explode. I won't go into the discussion because it's not necessary, but it was very unpleasant. However, I did get the instruction in writing as I requested.
Someone has subsequently said that he thinks that's a good thing - that when things go wrong, I can produce the written instruction, and throw it back at him. That's not why I did this - when it goes wrong, I will not bother arguing, I'll just get on and try to resolve the problem. My reason for asking for the instruction to be in writing, was to make sure that he understood just how seriously I take the issue.
As it happens, the process testing over at the other site is way behind. They still have almost all of the work to go thru still, and based upon the last project plan, we are about a month behind. There is going to be a big push in a couple of weeks and I have done some work to allow some of our people to do some testing for them. However, I'm not convinced that this will be of any value, as it it appears the consultants are teaching the staff over there different processes to what our people worked on.
I have reason to believe that the SI are pushing to get our overseas site operational on the agreed date, no matter if they are ready or not. I think that this is potentially a serious error of judgement - if they are not ready, we should admit that, and hold off until they are ready. Pushing for them to go live without them being ready could be disastrous - and not just for them, but for the company as a whole.
The reason for this was that we actually needed to define some limits to what people on each site would be able to do. We didn't want the staff at our second site to have the oppotunity to make changes to items from the main site. This seemed to work quite well, but then I found that some roles were getting very big - and at that point, I started to split the roles down.
We had a hierarchy - sales clerk, sales manager and added a couple of other items to this to allow some staff more access to do certain functions. So for example, 2 staff are involved in contract review, so we have a role for that. 2 other staff are involved in dealing with certain groups of customers, and that is a seperate role as well.
There were some issues right from the beginning, as the project team didn't really understand the concept of permissions - I would regularly be asked to give someone access to something, and when I pointed out that it was to the role that permission was granted, they would get very frustrated. However, it appears that for the most part, they now do understand and we do have a set of roles that serve our needs.
When we started on our first overseas site, I copied the basic roles from our second site, changed the organisational levels and applied user accounts to get them started as Z4. I felt that as we had most of the authorisations already confirmed, this would be pretty much what was needed. I sent details through to the relevant people, including the consultants that I had been told would be doing the necessary work, and waited for some minor changes.
Up until the first day of the work to go thru the processes with the staff, I had heard nothing. Later in the day, I received an email from a completely new consultant asking me to give permission for the staff member to have access to certain t-codes. When I checked, about 80% of those were already in the relevant role, and the member of staff had been added to the role. The few remaining were t-codes that we didn't actually use - we used different ones to do the same job.
I had several more emails requesting access, each time on the day of the process testing rather that before hand. In several cases, I pointed out that the t-codes being requested were restricted to certain people. It was decided that currency rates, period closure etc would be done centrally, rather than have different people at each site getting involved. However, I was also asked to provide access to certain t-codes that I was very reluctant to hand over - why would the staff members need access to things such as SCC4, STMS, SE16N just to name a couple. These are only for administrative positions, and I could see lots of issues if they had access to these.
What I didn't know was that the staff at our overseas site had made a complaint that they didn't feel that they were getting the relevant training they needed and this was passed to our CEO. He then discussed this with the director of the SI, who basically said that I was holding up the work by not providing the required access.
I was dragged into the CEO's office, and to be brief, he told me that the SI were insisting that I give all of the staff at our overseas site the profile SAP_ALL. I tried to point out that this was not good practice etc. but this cut no ice. I highlighted that we needed to get the roles right, but he had been told that this could be done afterwards - in order to get the site up and running as soon as possible, they needed SAP_ALL.
At that point, I told him that if he wanted this, I required him to put it in writing - and I thought that he was going to explode. I won't go into the discussion because it's not necessary, but it was very unpleasant. However, I did get the instruction in writing as I requested.
Someone has subsequently said that he thinks that's a good thing - that when things go wrong, I can produce the written instruction, and throw it back at him. That's not why I did this - when it goes wrong, I will not bother arguing, I'll just get on and try to resolve the problem. My reason for asking for the instruction to be in writing, was to make sure that he understood just how seriously I take the issue.
As it happens, the process testing over at the other site is way behind. They still have almost all of the work to go thru still, and based upon the last project plan, we are about a month behind. There is going to be a big push in a couple of weeks and I have done some work to allow some of our people to do some testing for them. However, I'm not convinced that this will be of any value, as it it appears the consultants are teaching the staff over there different processes to what our people worked on.
I have reason to believe that the SI are pushing to get our overseas site operational on the agreed date, no matter if they are ready or not. I think that this is potentially a serious error of judgement - if they are not ready, we should admit that, and hold off until they are ready. Pushing for them to go live without them being ready could be disastrous - and not just for them, but for the company as a whole.
Subscribe to:
Posts (Atom)