D - Fense

Some time ago, I went to a vendor sponsored event. These are usually good places to pick up on new technologies. find out what else is going on and also network with other people within the industry. It also allows me to take some time off away from normal activities, and re-charge my batteries so to speak.

I took a short break during the lunch period and started talking to a guy who told me that he was the IT manager for a government organization. Although he and I have the same job title, he has a lot more responsibility - a base of several thousand users and a large team of specialists working for him.

During the conversation, the topic of SAP came up - it turns out that his organization has also installed SAP. It appears they started about a year before we did, and went live a couple of months before us. Although there is little in common between our two businesses, we had similar issues with the SAP implementation. We swapped business cards and made promises to contact each other again. This is quite common practice, but generally I wouldn't expect to hear from anyone afterwards.

To my surprise, I got an email from this guy a short while ago. In it, he detailed a number of issues regarding their project and the people involved. They have been using one of the top tier consultancies and have spent many 10s of millions of dollars so far. Although they went live well over a year ago, they still have consultants on site - in fact these people almost have their own office space and on any given day, they will have between 5 and 10 consultants working on something to do with the product.

I've now shared several emails with this guy. Although he didn't specifically ask me not to reveal too many details, I wouldn't want to put him in an awkward position, so I am going to be a bit careful. However, I can say that he and his staff feel very unhappy about the position they are in. From his comments, it seems that the consultants almost never talk to the IT staff or manager. Certainly, the IT staff appear to have had limited training at best and in most cases, none at all.

The project itself seems have been entirely managed by the consultancy firm, and very little communication seems to have occurred between them and the IT department or the business process owners. Worse, the end users seem to have had equally limited training. At this stage, the IT staff take calls from the end users, record the issue what ever it might be, and then just pass it on to the consultants. He indicated that on some occasions, they get a response the same day, but in most instances, it is usually several days before they are offered a resolution - in most cases, they just get told that the issue is "closed".

When they started their project, an amount of money was allocated specifically for training. All of this has now been sucked up by by the project along with amounts budgeted for other IT projects. It appears that the money pit that is SAP just gobbles up cash, and at this stage, they seem to be able to do little with the product in terms of the business processes - he indicated that not one module seems to be working as it should.

I have to be honest, I feel really sorry for this guy and his staff. I've been there, I have the war marks and I know just how frustrating it can be. There were times when I seriously doubted that we would be able to get some of the processes working. I wanted to try to help him out and give him some practical advice - I then realised something really bizarre.

I was trying to defend SAP.

Seriously, I actually found myself writing to him, telling him that once it was working, he would be really pleased at how he could get certain things working for him. I've passed information to him on certain specific transactions for admin and systems monitoring. I know that several of these have been previously unknown to him or his staff - he asked for clarifaction how to use the t-code. He also came back with questions about some of the information that they found, some of which I have been able to assist him with.

From my point of view, one of the most serious issues was to do with user permissions - previously, all of this had been managed by the consultants. I've helped this guy understand how to analyse what permissions have been allocated, and also how to test to see where they are going wrong. What got me was how greatful he was for the information that I was able to give him.

I'll be honest, I've not been impressed with the consultants that we have had working on our project. I felt that they didn't achieve a lot of the things that they were supposed to do. Most of our internal project people struggled to get the required information they needed, and it seemed to take far too long to get some of what we saw as fairly simple issues resolved. I think that we have spent a great deal of money and at the moment, don't really have a lot to show for it in terms of ROI. But at least our system is working, and people can use it to do the basics.

But when we compare our implementation to the project at this other organization, ours is a runaway success.

It got me talking to one of my staff - I discussed the issues they had had, and what would be needed to correct them. He then made a comment that perhaps we could hire ourselves out as "guns for hire" - experienced IT staff with SAP knowledge that could go around the companies trying to install SAP having issues, and help them get the problems resolved. He was a bit taken aback when I pointed out that such people already existed - and they are called "consultants"!

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.

The price is right

Anyone that has read this blog will know that I regularly criticize the consultants that have worked on our project - but I have also indicated where I think that the company and our project team (and my staff and I) have not done so well. On this occasion, I'm going to concentrate on an area where I think we made a big mistake right back at the beginning and what we should have done and why.

First, I should say that I believe that there is only one way to determine the price for goods to be sold, no matter what they are, how they are made, how they are sold or what industry sector they are in. It's necessary to know what something costs you - the wholesale price of the item, the price of the raw materials, however it starts. You then add in the various costs needed to perform the tasks that add value to the goods, and any overheads. Once you have your final cost, you can then decide what margin you need and uplift the price accordingly, and of course then discount it to help sell the goods. Within that process, it is possible to have a myriad of different techniques - but it all starts from knowing what something costs you.

However, not everyone does it that way, and I regret that we are the same. Many years ago, someone sat down and did the calculations, then produced a "price list" that gave us a reasonable return on the sales. But since then, all that has happened is that each year the prices are uplifted by a fixed amount (or percentage amount) - and now after 20, 30, 40 years of trading, the price we charge bears little relationship to the cost price.

In fact, we don't actually ever know if we are selling something for a profit - the only time we know that the organization has made a profit is after the year end when all of the accounts are settled and we can declare a profit. And it gets worse - we have more than one price list. In fact we have so many that we have more price lists than we have sales staff and different customers get quoted from different lists. Despite what our sales people try to say, I know that they regularly used to make pricing errors when providing detailed quotes for customers.

Now the introduction of SAP was a superb opportunity to correct this - we could have had just the one price list and based it upon what the costs were. In fact, it was one of the key requirements for the new system that we should be able to determine costs on each individual product, so that we could achieve a sensible and balanced profit margin across the board.

Some work was done on establishing the costs, but it turned out that these fiugures were from our old system, and modified based upon certain assumptions. Unfortunately, they have proven to be less than accurate. Worse, instead of developing a new pricing system based upon this, the old price lists were entered into the SAP system and we are effectively still using the old pricing.
that we used previously

Now all is not lost - after operating for a year, we are starting to get some information from the system that means we can start to put some sensible values in for the costs and activity rates. These show that some of our intial assumptions were way out, but some were not too bad under the circumstances. The general feeling is that in about a years time, we will have values that are about as accurate as we could get, and most people would be happy to use those.

However, we are still no nearer getting a pricing structure that will give us confidence of selling anything for a profit. I know that our sales people don't agree with me on this - but I can guarantee that not one of them actually knows what sort of a profit we make on any sale at all. As it happens, I am sure that we are making a profit, but I'd be very surprised if we couldn't do better at both selling and making a profit if we had a better pricing structure.

I suppose that we can say that this is a project for the future, and I'm certain that if we did do this, we would see some benefits. But I doubt that there will be any pressure from the sales staff to change - they are happy with their current method and they see no problem at all in continuing with the same old system. I just feel that we have missed a golden opportunity to make a significant improvement to our processes.