I started to write this item a couple of weeks ago – but didn’t finish it at the time. I was highly annoyed and wanted to think about things before posting.
We actually started work on the SAP rollout at our overseas site almost 2 years year ago. However, nothing was ever completed, even in the development system and eventually, the project stopped before being started again with a new set of consultants in the middle of last year. The plans then were to go live at the end of October last year – as the previous consultants had done quite a bit of work, it was felt that this was achievable.
However, it quickly became clear that most of what had been done was of no value. Essentially, it all had had to go right back to the very beginning. The SI were still trying to say that October 2010 was achievable, but most people on our project team could see that was never going to be possible. A date was set for the end of July this year – most people agreed that this could be done if all went well.
As it happens, in April of this year, the consultants still had not finished working on the development system. We also had issues because almost no testing had been carried out, and absolutely no training had been done either. Our project team then went to the site to do some work, and as I’ve indicated, we managed to get a great deal done. So much in fact that we all thought it might still be possible to go-live in July. There is still major work being done by the consultants, but from experience, it seems to be normal for them to still be working on items right up to (and even after) the go-live date.
But there has been a major problem with getting data loaded. First getting data out of their existing system has proven to considerably more difficult than anyone believed would be the case. Cleansing the data was also a bit of an issue – but the biggest problem has been getting it matched to the relevant data load into SAP. I had been told by the SI that about 80 - 85% of the data load had been completed into the development system – but during our test phase it became very clear that it was really closer to 10 - 15%.
Since then, some data has also been loaded into the test system – but no more than about 30 – 40%. Some training has been done with key users, but none with the rest of the end users. I had to go over there again a few weeks ago, and they were trying to do some testing work in the test system. Most of this failed simply because there was insufficient data to allow more than few test scripts to be used – it took them as much as half a day to complete a single test item.
As it became clear that July was slipping away, a decision was made to move the go-live date back yet again. This makes sense, and I have no issue with that other than once again, we are committing many resources to the project than was originally planned. But what has outraged me is a decision that has been made following further discussions with the SI.
The director of the SI suggested to our senior managers that we did not need to complete the data load process in either of the development or test systems, but simply go straight to the production system and load the data without having to do any testing. The argument was that we had done a few items so that proved the process worked and therefore any further data added to the same process would also work. He also argued that if we needed to have data in the other systems, it would be easier to do a system copy after the go-live.
I tried to point out that this view was completely wrong – we have seen repeatedly that people make mistakes when preparing the data. In some cases, the mistakes are so significant that the data will simply not go into the database without considerable manipulation by the people carrying out the work. To trust that all of the data will load correctly just because you have loaded a few lines is at best, wishful thinking in my opinion. As far as I am concerned, completing the data load process in the development and test systems should then save time and effort when loading into the production system.
But there we are – I can do no more than point out the issues and then do my best to see if I can fix the problems when they occur. But I must admit that I am now really beginning to feel that I can do no more on this project. I feel so frustrated all of the time – all I hear is that everything is going well, when it is abundantly clear that things are far from satisfactory.
I have no problem people trying to maintain a positive attitude – I can see that sometimes this is a necessity. When something requires such a major business transformation as SAP, it is essential to keep everyone motivated. But what worries me is that we are seeing “ostrich management” – burying their heads in the sand in the hope that if they don’t see the problem, it will just go away. I can’t believe that will be any good for us, now or in the future, on this project or any other.
Saturday, 30 July 2011
Sunday, 10 July 2011
Eye of the beholder
Last week, I had the opportunity to visit the manufacturing plant of another company. These people started to work on SAP a couple of years before us, and I had been told that they had been successful – so I was interested in talking to them in a bit more depth.
I had the chance to talk to the IT manager on site – a nice enough guy, although he seemed a little distant. As we talked, he made the point that they had gone live after just 8 months and they had experienced no problems. I won’t say that he was being arrogant, but there was a definite sense that he was as far as he was concerned, their project had gone very well indeed, and he was more than a bit proud of that. When I told him of our project and how long it took, he made me feel a bit bad.
However, I also had the chance to their production guys, and they had a slightly different story to tell. A few days after go-live, the system had gone down, and it took a couple of days before it was working again. They didn’t know why, all they knew was that it caused a few problems for them. That was bad enough, but it appears the same thing happened on several occasions over the next 4-6 months. Added to that, it appears that they still have an on-going issue relating to some of the data that they are accessing – they couldn’t tell me why.
After that, I spoke to a couple of their finance people. They remembered the first few months as being a complete nightmare caused by a series of issues with billing documents, financial reports and figures just not adding up. It appears that most of these are sorted, but they still recall those problems and again, they are still finding issues on a regular basis.
Later when I checked, it seems that there is quite a difference between the size of the projects, even tho’ the companies are about the same size. They have a lot fewer products than us, and there was a lot less to do on data migration. In addition, they don’t use a couple of them modules that we are using – and these items were seen as being responsible for a good proportion of our delays. Possibly our project might not have taken so long if we had been in the same situation as them.
When I thought about it later, it seemed to me that this is a case that the individual people were really only concerned about what had happened within their own areas of the business, and the project had been judged by that. As far as IT was concerned, the project went well because it came in on time and budget – the other issues were irrelevant. But for the other departments, they could only see the issues that had caused them major problems. Even years later, they don’t see their SAP project as being that successful.
I was once told by a CEO that he liked me because I looked at the bigger picture, and in his experience, most people in IT just didn’t do that. I can appreciate that the IT manager in this case was pleased with the project and felt that his team had performed well – but I could also see that the other departments were not as happy and for valid reasons. OK, they did get things sorted, but it was clear that it could have been a lot worse for them. When I compare that to our project, I don’t feel quite as bad.
I think that with an ERP system, it is important that people look at it from an over view rather than just within their own specific areas. If I think back, it seems to me that when things weren’t going well, it was because it was a single person or a couple of people working on their own without involving others. When things went well, it was because we were working as a team.
I know that the SI have been telling people that our project was a success – and if you look at it from a particular perspective, they are probably right. SAP is working for us, and in some respects, it has achieved some of the primary requirements. From the company point of view, that’s not the whole story – the project has been very expensive and taken a lot longer than we had been told it would. In some areas there has been no benefit or processes are much more difficult – in other areas, we have seen improvement or there is an indication that we may see this in the future.
Essentially, it seems that the quality or success of an SAP project is very much in the eye of the beholder. Personally, I would rather judge on well it achieves the requirements stated at the beginning of the project – but then, that’s just my opinion.
I had the chance to talk to the IT manager on site – a nice enough guy, although he seemed a little distant. As we talked, he made the point that they had gone live after just 8 months and they had experienced no problems. I won’t say that he was being arrogant, but there was a definite sense that he was as far as he was concerned, their project had gone very well indeed, and he was more than a bit proud of that. When I told him of our project and how long it took, he made me feel a bit bad.
However, I also had the chance to their production guys, and they had a slightly different story to tell. A few days after go-live, the system had gone down, and it took a couple of days before it was working again. They didn’t know why, all they knew was that it caused a few problems for them. That was bad enough, but it appears the same thing happened on several occasions over the next 4-6 months. Added to that, it appears that they still have an on-going issue relating to some of the data that they are accessing – they couldn’t tell me why.
After that, I spoke to a couple of their finance people. They remembered the first few months as being a complete nightmare caused by a series of issues with billing documents, financial reports and figures just not adding up. It appears that most of these are sorted, but they still recall those problems and again, they are still finding issues on a regular basis.
Later when I checked, it seems that there is quite a difference between the size of the projects, even tho’ the companies are about the same size. They have a lot fewer products than us, and there was a lot less to do on data migration. In addition, they don’t use a couple of them modules that we are using – and these items were seen as being responsible for a good proportion of our delays. Possibly our project might not have taken so long if we had been in the same situation as them.
When I thought about it later, it seemed to me that this is a case that the individual people were really only concerned about what had happened within their own areas of the business, and the project had been judged by that. As far as IT was concerned, the project went well because it came in on time and budget – the other issues were irrelevant. But for the other departments, they could only see the issues that had caused them major problems. Even years later, they don’t see their SAP project as being that successful.
I was once told by a CEO that he liked me because I looked at the bigger picture, and in his experience, most people in IT just didn’t do that. I can appreciate that the IT manager in this case was pleased with the project and felt that his team had performed well – but I could also see that the other departments were not as happy and for valid reasons. OK, they did get things sorted, but it was clear that it could have been a lot worse for them. When I compare that to our project, I don’t feel quite as bad.
I think that with an ERP system, it is important that people look at it from an over view rather than just within their own specific areas. If I think back, it seems to me that when things weren’t going well, it was because it was a single person or a couple of people working on their own without involving others. When things went well, it was because we were working as a team.
I know that the SI have been telling people that our project was a success – and if you look at it from a particular perspective, they are probably right. SAP is working for us, and in some respects, it has achieved some of the primary requirements. From the company point of view, that’s not the whole story – the project has been very expensive and taken a lot longer than we had been told it would. In some areas there has been no benefit or processes are much more difficult – in other areas, we have seen improvement or there is an indication that we may see this in the future.
Essentially, it seems that the quality or success of an SAP project is very much in the eye of the beholder. Personally, I would rather judge on well it achieves the requirements stated at the beginning of the project – but then, that’s just my opinion.
Saturday, 18 June 2011
Paperwork
Right back at the beginning of our project, I talked to the SI about the need to provide us with detailed information concerning what changes they had made to the system. To me, this is just good practice – any time that someone makes a change to a system, it should be documented. There are a number of reasons behind this – people are not always available to confirm what has been done, jobs change and people move, security and audit issues etc. so good documentation is really important, especially before you start making other changes.
The SI promised that we would have full documentation, and they did indeed send us a document once we had gone live. However, it contained almost no actual information on the changes made, other than some flow charts to show processes and was quite a small document compared to the work done. I queried this at the time, and was told that this was standard SAP documentation – when I pushed a bit harder, the guy concerned got really snotty with me. His view was that this was the same format provided to everyone else implementing SAP, and those people had no issue with it, so I should just accept it and stop complaining.
I spent quite a bit of time trying to see if I could find a way to uncover what config chnges had been done, but I must confess that with all the other work going on at the time, I simply could not keep track of what was happening. It also became pretty difficult to maintain details of who was working on what, when, why and what they did. We had an issues list, and for the most part, this is now our primary resource for determining what work was carried out.
As it happens, when we applied a number of support packages, we found several issues. After investigation, it was determined that some of these (not all of them) were down to config changes having been made, and this caused a number of delays until we could complete various work to deal with the situation. It definitely took much longer to do the updates than it should have, and the delays impacted other work.
However, about a year after we went live, we had another consultant on site for a few weeks. When he left, he handed over a really detailed document that we still have – it gave information on what he had done, what changes, what code even. The file was everything that we had previously asked for, and exactly what was needed. It ran to a couple of dozen pages, and was really helpful as we could then refer to it when there was a question about an issue a few weeks after he had gone.
As you can probably tell, I think that this is a very sensible and professional way to work. I raise the subject because there is a particular consultant that has been doing quite a lot of work on our systems, and a couple of weeks ago, we found out that he has now left the SI. The trouble is that he has documented nothing – and I mean absolutely zip. No-one at the SI can talk to the guy, and they have no idea of what he had done, or how far he has got with the work he was doing other than at a pretty basic level.
OK, we will survive – but it is not the best way of working. It’s just another example of bad practice, and when you are paying about $1500 a day, I think that you are entitled to expect a certain level of professionalism and I am not convinced that we’ve seen that from some of the people that we have had working for us on our project.
Having said all that, I would understand if anyone then turned the criticism back on us. The systems are ours, and it would not be unreasonable for someone outside of the company to suggest that it is our responsibility to maintain records of what work is done. As it happens, we do keep some records for various reasons and we can point to a number of audit trails that show we are attempting to maintain a level of control.
The problem is of course that in many ways, the SI and the consultants working for them were working in the way that they want to, rather than in a way that matched what we want or need. I suspect that for most of the consultants concerned, this is the same way that they have worked on all of their projects, and they know no different. Our project leader should have forced the issue (and he freely admits that) but he was taking advice from the SI on how the project should run. But we will probably never know all of the configuration that has been done.
Well it’s too late now – just got to keep going as we are.
The SI promised that we would have full documentation, and they did indeed send us a document once we had gone live. However, it contained almost no actual information on the changes made, other than some flow charts to show processes and was quite a small document compared to the work done. I queried this at the time, and was told that this was standard SAP documentation – when I pushed a bit harder, the guy concerned got really snotty with me. His view was that this was the same format provided to everyone else implementing SAP, and those people had no issue with it, so I should just accept it and stop complaining.
I spent quite a bit of time trying to see if I could find a way to uncover what config chnges had been done, but I must confess that with all the other work going on at the time, I simply could not keep track of what was happening. It also became pretty difficult to maintain details of who was working on what, when, why and what they did. We had an issues list, and for the most part, this is now our primary resource for determining what work was carried out.
As it happens, when we applied a number of support packages, we found several issues. After investigation, it was determined that some of these (not all of them) were down to config changes having been made, and this caused a number of delays until we could complete various work to deal with the situation. It definitely took much longer to do the updates than it should have, and the delays impacted other work.
However, about a year after we went live, we had another consultant on site for a few weeks. When he left, he handed over a really detailed document that we still have – it gave information on what he had done, what changes, what code even. The file was everything that we had previously asked for, and exactly what was needed. It ran to a couple of dozen pages, and was really helpful as we could then refer to it when there was a question about an issue a few weeks after he had gone.
As you can probably tell, I think that this is a very sensible and professional way to work. I raise the subject because there is a particular consultant that has been doing quite a lot of work on our systems, and a couple of weeks ago, we found out that he has now left the SI. The trouble is that he has documented nothing – and I mean absolutely zip. No-one at the SI can talk to the guy, and they have no idea of what he had done, or how far he has got with the work he was doing other than at a pretty basic level.
OK, we will survive – but it is not the best way of working. It’s just another example of bad practice, and when you are paying about $1500 a day, I think that you are entitled to expect a certain level of professionalism and I am not convinced that we’ve seen that from some of the people that we have had working for us on our project.
Having said all that, I would understand if anyone then turned the criticism back on us. The systems are ours, and it would not be unreasonable for someone outside of the company to suggest that it is our responsibility to maintain records of what work is done. As it happens, we do keep some records for various reasons and we can point to a number of audit trails that show we are attempting to maintain a level of control.
The problem is of course that in many ways, the SI and the consultants working for them were working in the way that they want to, rather than in a way that matched what we want or need. I suspect that for most of the consultants concerned, this is the same way that they have worked on all of their projects, and they know no different. Our project leader should have forced the issue (and he freely admits that) but he was taking advice from the SI on how the project should run. But we will probably never know all of the configuration that has been done.
Well it’s too late now – just got to keep going as we are.
Monday, 30 May 2011
No change here...
It’s been about a month since my last post – and there’s a simple reason for that. I’ve been really busy on other projects, not related to SAP. I’m not the only either – several other departments have also been catching up on various things that have been delayed.
We started the SAP implementation about 4 years ago. At times it seems astonishing how quickly the time has passed, at other times it seems that we have been working on it for ever. The problem is that during that time, so much effort has gone into the project, that many other jobs have been postponed. In a couple of cases, this has not been a good thing – we needed to get on and get them done so it was decided that we would do exactly that.
For IT, there have been a couple of hardware refresh jobs, replacing workstations, printers and a Xerox machine. We’ve also been testing a couple of tablets that we think might be of value to the sales force. There have been couple of jobs done within some of the offices to make more efficient use of the space available, so we were also getting involved in the cable work. As you can see, this has meant that there hasn’t been a lot of time left to do more than basic work on SAP.
After the last visit to our overseas site, everyone felt that we had gotten thru a lot of the outstanding work and had almost caught up so that we would be back on schedule. When we left, the point was made that they needed to get on with the data preparation so that it could be loaded. We had done some loading of a few basic data items into the Development system, but not all of the data, and literally only a few items in each category. A decision was made that we would load no more into the Dev system and just go straight thru to the QAS system.
I was a bit concerned about this, as I felt that the actual loading wouldn’t really take up that much time, and felt that it would make sense to try to get all of the data sorted and proven. However, I could see that we need to keep on schedule – I’m not happy about cutting corners, but I can probably live with this.
However, when the data arrived, it quickly became clear that it was simply no good. Not one of the data loading batch jobs was able to complete successfully, and most were so poor that we were looking at maybe 10-20% had gone in successfully on each batch. It was so bad that the project leader took another trip over there to talk to them again. When he arrived back, he was really pissed – he went back over the requirements with their people but feels that they still don’t quite yet get it.
I haven’t been asked if I would go over again, but I know that there have been discussions, and I get the feeling that they are expecting me to offer to go there in the next couple of weeks. As it happens, there is work that I was planning to do, but I’m not sure I will have time to do both jobs, the planned work and talking with them about the data preparation and cleansing.
There is no question that it is essential we get the data right. We found this out ourselves when it was our turn. We have made the point to the people at the overseas site, and several people discussed it with them, making the points very clearly. We provided some sample files showing how it should be done, highlighting the main pitfalls – but none of this seems to have made the slightest difference, and they are now well over a month behind where they should be, and falling further behind each day.
No-one has said anything, but I’m now a bit concerned that they will cut back on the testing in the QAS system before we go live. I’m also a bit worried that staff over there won’t get the full amount of training before their cutover. For me, it would make sense to push the go-live out again, and make sure that things are done right. But it seems that there is something going on in the background, and they don’t seem too keen to discuss any further delays.
Well, we’ll probably know a bit more in a couple of weeks’ time.
We started the SAP implementation about 4 years ago. At times it seems astonishing how quickly the time has passed, at other times it seems that we have been working on it for ever. The problem is that during that time, so much effort has gone into the project, that many other jobs have been postponed. In a couple of cases, this has not been a good thing – we needed to get on and get them done so it was decided that we would do exactly that.
For IT, there have been a couple of hardware refresh jobs, replacing workstations, printers and a Xerox machine. We’ve also been testing a couple of tablets that we think might be of value to the sales force. There have been couple of jobs done within some of the offices to make more efficient use of the space available, so we were also getting involved in the cable work. As you can see, this has meant that there hasn’t been a lot of time left to do more than basic work on SAP.
After the last visit to our overseas site, everyone felt that we had gotten thru a lot of the outstanding work and had almost caught up so that we would be back on schedule. When we left, the point was made that they needed to get on with the data preparation so that it could be loaded. We had done some loading of a few basic data items into the Development system, but not all of the data, and literally only a few items in each category. A decision was made that we would load no more into the Dev system and just go straight thru to the QAS system.
I was a bit concerned about this, as I felt that the actual loading wouldn’t really take up that much time, and felt that it would make sense to try to get all of the data sorted and proven. However, I could see that we need to keep on schedule – I’m not happy about cutting corners, but I can probably live with this.
However, when the data arrived, it quickly became clear that it was simply no good. Not one of the data loading batch jobs was able to complete successfully, and most were so poor that we were looking at maybe 10-20% had gone in successfully on each batch. It was so bad that the project leader took another trip over there to talk to them again. When he arrived back, he was really pissed – he went back over the requirements with their people but feels that they still don’t quite yet get it.
I haven’t been asked if I would go over again, but I know that there have been discussions, and I get the feeling that they are expecting me to offer to go there in the next couple of weeks. As it happens, there is work that I was planning to do, but I’m not sure I will have time to do both jobs, the planned work and talking with them about the data preparation and cleansing.
There is no question that it is essential we get the data right. We found this out ourselves when it was our turn. We have made the point to the people at the overseas site, and several people discussed it with them, making the points very clearly. We provided some sample files showing how it should be done, highlighting the main pitfalls – but none of this seems to have made the slightest difference, and they are now well over a month behind where they should be, and falling further behind each day.
No-one has said anything, but I’m now a bit concerned that they will cut back on the testing in the QAS system before we go live. I’m also a bit worried that staff over there won’t get the full amount of training before their cutover. For me, it would make sense to push the go-live out again, and make sure that things are done right. But it seems that there is something going on in the background, and they don’t seem too keen to discuss any further delays.
Well, we’ll probably know a bit more in a couple of weeks’ time.
Sunday, 1 May 2011
What a difference a day makes...
Or even a week…
Our project leader has been over to our overseas site a number of times so far this year, about once every 3 weeks or so - and altho he has said in the board meetings that things were going well, it was clear that there was a bit more hope than confidence in what he was saying.
Privately, he has been suggesting to the project team leaders that there are still far too many issues unresolved, and that despite quite a lot of hard work, we don’t seem to be progressing as fast as we should be. Although he wouldn’t actually say we were behind schedule, it’s pretty clear that the proposed go live date was looking increasingly hard to meet.
I’ve suggested a number of times that we should get the staff from our overseas site to visit with us for a week so that we can help them out with training and testing – by getting them to work with our staff I hoped that they would pick up some of the required knowledge. But altho it was seen to be a good idea, we have had none of their staff visit with us since last August.
It was then suggested about a month ago that we should arrange for our project team to go over there instead. Plans were made, travel and hotels booked and the project leader set out a plan for the week. This was primarily to test their processes to make sure that these would work – I felt that this would be a good start, but was concerned that we would miss a good opportunity to ensure that their staff was adequately trained.
I’d also gotten a bit worried about some of the comments from our project team – one or two had said to me that they were not really sure what they were supposed to be doing over there. So I made a point of spending some time with each one, to discuss how to test the various processes, and I set-up a series of test user accounts for them and made sure that they knew what they had to do.
On the first day at the site, we weren’t able to get much done – we arrived late in the day, and really only just managed to introduce ourselves to people, and get things organised so that we could start work properly the following day. But after that, things really started to take off.
The project team made a point of getting the key staff in with them so that they could see the processes, and in most cases after a couple of demos, these people were carrying out many of the actual tests. That second day, we had actually gone thru every single process and tested at least 3 variants for each. Their staff are now far more confident in the way that they use SAP, and altho they still have more work to do, based upon what they did last week, they should be ready for the go-live.
It should be said that during the tests, we did actually find several key issues – but about half of these I was able to correct almost immediately. As one of their consultants was on site, the rest were passed to him and it has to be said, he made a good start on getting them corrected. However, he also made contact with a couple of the other consultants and they were then available on the third and fourth days.
In fact, by the last day, we had not only gone thru every process many times and confirmed all were working, most of the outstanding issues had also been addressed. This included several that have been on the list for months. It also highlighted a couple of issues with data – I had tried to highlight this previously, and now it is obviously the most urgent major problem remaining so they are looking at dealing with this next.
It should be said that it was hard work - most of the guys were suffering with jet lag, and one had an upset stomach. It's also been a bit warmer there than we normally face this time of year, and some had difficulty sleeping at night. Despite these problems, everyone was really pleased - and I have to say that it is very clear that we have made a major leap forward.
We still have a lot of work to do, but we are almost back on schedule to go live in a couple of moths time. If we can get the data done on time next, then it should be possible to start the next stage of testing in the test system before the end of the month - and if it there are no major problems, we will be back on track.
It helps that there are not that many staff at that site and that they don't have to learn all of the various processes. But there is a lot more confidence now, both on site and in the project team. It has been said that it may be necessary to organise another trip over, and if we do, I'm sure that it will prove to be as valuable an exercise as this one was.
Our project leader has been over to our overseas site a number of times so far this year, about once every 3 weeks or so - and altho he has said in the board meetings that things were going well, it was clear that there was a bit more hope than confidence in what he was saying.
Privately, he has been suggesting to the project team leaders that there are still far too many issues unresolved, and that despite quite a lot of hard work, we don’t seem to be progressing as fast as we should be. Although he wouldn’t actually say we were behind schedule, it’s pretty clear that the proposed go live date was looking increasingly hard to meet.
I’ve suggested a number of times that we should get the staff from our overseas site to visit with us for a week so that we can help them out with training and testing – by getting them to work with our staff I hoped that they would pick up some of the required knowledge. But altho it was seen to be a good idea, we have had none of their staff visit with us since last August.
It was then suggested about a month ago that we should arrange for our project team to go over there instead. Plans were made, travel and hotels booked and the project leader set out a plan for the week. This was primarily to test their processes to make sure that these would work – I felt that this would be a good start, but was concerned that we would miss a good opportunity to ensure that their staff was adequately trained.
I’d also gotten a bit worried about some of the comments from our project team – one or two had said to me that they were not really sure what they were supposed to be doing over there. So I made a point of spending some time with each one, to discuss how to test the various processes, and I set-up a series of test user accounts for them and made sure that they knew what they had to do.
On the first day at the site, we weren’t able to get much done – we arrived late in the day, and really only just managed to introduce ourselves to people, and get things organised so that we could start work properly the following day. But after that, things really started to take off.
The project team made a point of getting the key staff in with them so that they could see the processes, and in most cases after a couple of demos, these people were carrying out many of the actual tests. That second day, we had actually gone thru every single process and tested at least 3 variants for each. Their staff are now far more confident in the way that they use SAP, and altho they still have more work to do, based upon what they did last week, they should be ready for the go-live.
It should be said that during the tests, we did actually find several key issues – but about half of these I was able to correct almost immediately. As one of their consultants was on site, the rest were passed to him and it has to be said, he made a good start on getting them corrected. However, he also made contact with a couple of the other consultants and they were then available on the third and fourth days.
In fact, by the last day, we had not only gone thru every process many times and confirmed all were working, most of the outstanding issues had also been addressed. This included several that have been on the list for months. It also highlighted a couple of issues with data – I had tried to highlight this previously, and now it is obviously the most urgent major problem remaining so they are looking at dealing with this next.
It should be said that it was hard work - most of the guys were suffering with jet lag, and one had an upset stomach. It's also been a bit warmer there than we normally face this time of year, and some had difficulty sleeping at night. Despite these problems, everyone was really pleased - and I have to say that it is very clear that we have made a major leap forward.
We still have a lot of work to do, but we are almost back on schedule to go live in a couple of moths time. If we can get the data done on time next, then it should be possible to start the next stage of testing in the test system before the end of the month - and if it there are no major problems, we will be back on track.
It helps that there are not that many staff at that site and that they don't have to learn all of the various processes. But there is a lot more confidence now, both on site and in the project team. It has been said that it may be necessary to organise another trip over, and if we do, I'm sure that it will prove to be as valuable an exercise as this one was.
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!
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!
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)