Saturday 30 July 2011

None so blind...

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.

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.