Sunday, 12 September 2010

Making up the numbers

A few weeks ago, one of the managers asked me to help him out with a small problem. He needed to extract some data from the SAP system, then put the data into a spreadsheet so that he could analyse the figures.

My immediate reaction was why should he do it that way - surely it would be easier to do the analysis within SAP? After all, the main reason for buying the product was to have the single system that would allow all of the data to be seen thru one system, and having now spent several million dollars on the project, it would be better to make use of it to try and justify that spend.

For many years now, the various departments have used Excel spreadsheets to do the analysis functions needed. We had literally many thousands of spreadsheets stored on servers (and even worse, on people's PCs) all for different things. It was (and still is) quite simply impossible to keep track of all that data. I know that in many cases, people have re-done a spreadsheet several times, because they couldn't remember where they stored the previous one and can't find it amongst all the many others.

But here's the worst part - many of those files are just simply placeholders for data, there is actually very little processing going on. For example, the manager in question has done a great job of designing his spreadsheet. Columns and rows are very carefully sized, colors have been applied to help make cells stand out, and the relevant labels are in place so that you see what the data refers to. But there is not one single formula in the whole file, not one macro or piece of VB to actually process the data. The whole thing is created by hand and must have taken well over an hour - and only has half the data that he needs, so in fact it is a complete waste of time unless he can then get the data he needs.

So back to my original question, why would he waste time on extracting only half the data and not do the processing within SAP? The answer is simple - because the half of the data he needs is actually not in SAP. He has obtained some of the data from our overseas sites, and then wants to extract the SAP data, merge it with the data from overseas, and then manually process it thru the spreadsheet. The data he needs is static data, so it is not affected too much by sales etc. But it was never created in SAP and at this stage won't be for a number of years.

This actually goes back to a decision that was made early in the project. We had been given a date for go-live very early on - it was agreed that it would be 9 months after the project launch. The consultants were very bullish about this and thought that it would be really easy to meet the deadline. However, about half way thru the "blueprint" stage, they started talking about "Phase 1", "Phase 2" etc. even tho' we had always said that the whole project was to be done in one go. But we started to agree with them - as people began to realize just how much work was going to be required, it made sense to concentrate on the key requirements.

The problem was that we were concerned with the amount of data that needed to be obtained from our overseas sites, with cleaning and preparation, we just wouldn't have time to get it done and meet the go-live. It therefore seemed appropriate to forget about that data - after all, if it was missing, it wouldn't really cause an issue, would it?

However, I don't think anyone really understood just how much work that missing data would then cause once we had gone live. Unfortunately, it seems to affect almost all departments and there are serious issues as a result that are causing people to have to spend large amounts of time and effort from a few people just to get around the problem.

I think that there is no question, the decision was made for the right reasons - if we had gone live on the original date, there is simply no way that we could have got that data and loaded in time. But we had to delay the go-live and by over a year - I feel that we should have then looked at that decision and then possibly chosen to import the other data after all.

The problem was that we didn't move the go-live date in one go, from the orginal date to one a year later. The consultants kept insisting that we were very close even tho' it was pretty obvious to most people that the reality was we were nowhere near ready. The go-live date was moved by a month or two at the most every time - and so the thought of loading the overseas data never really landed on the radar.

We now have an issue and I'm not sure if we are going to get a resolution any time soon. If we had gone live on the original date, then according to original plans, we would have had the first of the overseas sites live in July this year. In fact they haven't even started work on their side of it. The consultants have said they can go live at the beginning of the new year, and yet so far not one person on that site has had any training, or has even logged onto the system. But the most serious issue from my point of view is that they have yet to even begin to extract the data from their legacy systems. I suspect that it is unlikely they will be ready until the second quarter of next year at the earliest.

We also have a couple of other sites that need to go thru the same process - and on the original plans, they were due to go live in July of next year. At this stage, no-one believes that will happen - I did hear one person suggest that they may not go live until 2013 and possibly not even until 2014. This means that the problems with the data not being in the system is going to be with us for many more years yet to come - and we will continue to have people spend time and effort trying to get around this issue.

Of course, it is always easy to be a Monday morning Quarterback. But I think if we had known back at the beginning just what issues we were going to face, then at some stage someone would have insisted we make time to get the rest of that data. Quite simply we are wasting probably as much time every month as would have been spent on getting that data loaded.

I have to say that I accept that we made the decision, but I do feel that once again we were let down by our consultants. We had no-one in the company with SAP experience so were relying on them to give us the right guidance. I think that the people we had just didn't have the right amount of experience to provide us with the right advice - and we are now paying for that with the amount of time and effort that is being spent getting around an issue caused by a decision made without understanding the full implications.


  1. Many people will agree that choosing the right consulting company from the get go will make a big difference in your SAP implementation. And yes, it would make sense to have all the data within one system. Michael Doane is an excellent resource for any one looking for a 'how to hire a consulting group' and can be found here:
    He can also discuss the relationship that happens after a go live - there are inevitably areas that need to fixed, employees that need further training, and so on, a good consulting group will help with this process.

  2. As you would gather, I do feel that having the data in one place makes more sense particularly in our case. I do however accept that there may be reasons why you wouldn't do that from the beginning. However I feel that when we made the decision, we probably didn't have the right guidance - if we had, we may have taken a different route. (but possibly not)

    There is no question that getting the right implementation partners with the right team is absolutely crucial to a good installation. I've actually had some contact with Michael Doane and his "SAP Blue Book" contains a lot of really good, highly valuable information. I just wish we had access to that before we started the project.

    As always, thanks for the comments - these mean a great deal to me. I am amazed that people are prepared to follow this blog.