Looking forward

I hope that everyone has had a good Christmas holiday and is looking forward to the new year with anticipation. We have a family get together planned to see in the new year - my wife is just starting to get the food arranged, so I am banished to the den. As it is the end of another year, I thought that I would look back to analyze what has been happening, and I also decided that I would try to be more upbeat than usual.

So... lets start by looking at the actual systems. This is very definitely a positive point as our servers are running (for the most part) pretty smoothly and we only get a few issues from time to time. When we do get an issue, it is generally down to someone doing something that they have been told NOT to do - run a report without filling in any filtering information so the program tries to run the sales data on every single item that we have in the catalogue for every single customer. I'm sure that you will know the problem!

For many people this will sound stupid - after all, you would expect a system to run well, or why would you want to use it? However, I know from talking to many other users that we seem to be doing better than a lot of other businesses in terms of system operation, even tho' we are still quite new to SAP.

We are also managing to stay on top of the database admin work, software updates, system monitoring, and still do the rest of the normal IT work, even tho' we have no more extra staff than before. Again, I have heard stories from other companies that indicate they allocated a significant increase in manpower in order to maintain a level of service, and we have been able to avoid that so far. This all means that we are able to maintain our budget levels, and that has been noted by the senior managers.

Partly that has been due to training - we have spent some time to get all of the IT staff (including myself) along to an SAP training center. This has proven to be money well spent in many areas, and I am really keen to see this rolled out amongst the rest of the project team. Just before Christmas, I spoke to the CEO about a particular organization - I was able to tell him how much they have spent in a particular area that we have handled internally, and to estimate just how much we have saved as a result. In dollar terms, it's about $400,000 over the last 2 years which has to be good news. He is not entirely convinced about the training yet, but he has given the green light to a couple of others to do some training and if that goes well, I'm sure that he will then authorize more.

Throughout the business, we can see that most people (not all yet sadly) are getting quite proficient at using SAP. Certainly in each department, we are seeing most staff can complete most processes with relative ease. It has to be said that there are still issues with about 20% of the various processes, and these (naturally) seem to be the biggest stumbling blocks and generate more work than they save. We are using the key staff to try to make sure that others are trained appropriately - we have tried to start some "refresher" style training sessions using these key people. Time will tell if this works or not.

There is unfortunately still an issue with data output - we are still not where we would want to be. However, we are starting to get some valid data at last, and this is being used to correct some of the initial input which we always knew was poor at best. For example, we are now seeing some more accurate figures on production costs, so that is being fed back into the systems, and hopefully, we will see this improve the way that we start to price goods up. It has taken a lot longer than anticipated, and some of the figures are still questionable, but it is what we hoped we would eventually be able to see.

We successfully completed a secondary project to use document management within SAP at the beginning of the year - as I have indicated before, this has been a truly useful change and has been instrumental in encouraging some people to look at the program in a more positive light. This has also lead to a couple of other small projects associated to SAP. We have reduced the amount of printing that is required by about 20% - not a huge saving in the overall scheme of things, but something positive to point to. We are producing bar code labels for products that have customer codes on them as well as ours, and we are currently evaluating making use of scanning more widely as part of our internal processes.

So we would have to say that our SAP implementation has been successful. Certainly, there are many other organizations that have had a far worse time than us and are still struggling with their systems. Of course, there is still much to be done and considerable effort required to ensure that the ERP does deliver what was always hoped for. But with what we have achieved so far, and what has been learned, I am sure that we can continue to build upon that success.

Now at this stage, I should say that I am not an SAP convert - we have spent so much, the project has taken so long that I'm still not entirely sure that we will ever see an ROI. In addition I am going to say again that much of the success of our project is down to the hard work of our internal project team. Without their effort, skill, commitment and knowledge of the business, I seriously doubt that we would have ever gone live successfully.

But we have gone live, and it has been fairly successful and there is evidence that we can continue in this way. So tomorrow night, I will definitely raise a glass to the guys and gals that have worked so hard and wish them all the best for 2011.

I also wish the same to everyone that reads this blog - and may the new year bring happiness, health and prosperity to you all.

What price training?

I've been back to work for a few weeks, but have been a bit busy on a couple of non-SAP related projects. But as they are progressing well, I thought that I would return to an issue that has been bugging me (and others) for a while.

One of the most consistent comments from the project team and to a lesser extent from the end users, relates to the training that they receive in how to use SAP. Within the wider scope of a project, this is referred to as "knowledge transfer" and is seen as a key requirement for a successful project. In fact, this was identified as a major item right back at the beginning of the company plans to implement a new ERP system, even before the decision was made to install SAP.

The feeling is quite clear amongst the project team that overall, the level of knowledge transfer that has taken place is not what we would have wanted. Certainly, there were a few sessions where a couple of the consultants working on the project sat down with the various people and went thru the processes - but almost from the beginning, comments were made that far too often, these seemed to be very high level overviews rather than explanations of how to complete a specific process.

As a result of this, many of the various processes were never really tested properly or fully in the early stages. In fact, it can be identified that the real testing only took place finally about 3 months before we went live. Until that point, there may have been some limited testing such as placing a purchase order, but no-one would then use that data to conduct a goods receipt and warehousing process for example.

As is regularly stated, SAP is very integrated - making an entry in one module will have an affect in others, so it is vital to make sure that the linked processes are functioning correctly by a series of end to end tests. In order to carry out this testing work effectively, it is essential that people know how to complete the full process from a very early stage, but it seemed that at best, people were shown just limited steps within part of a process and often these were very generic items that in themselves did little to fully test anything.

In the end, we were pretty much left to our own devices to draw up a training plan, to put together the required material, and conduct end user training. A considerable effort was put in by my colleagues to make sure that their staff knew what as required and how they would be doing their jobs in future. Unfortunately, sometimes this was then invalidated by changes made by the consultants - they would do some configuration change, not actually test anything, and the first anyone would know was when someone was trying out a process that had previously worked, only to find that it suddenly didn't.

This happened a lot - far more than I would have liked. I won't say that it was a daily occurence, but certainly weekly for about 5-6 months (sometimes even 2-3 times in a week) before we went live. As you can imagine, this was immensely frustrating and caused considerable delays, perhaps unnecessarily - altho I am sure that there are those who will say that this is just part of a development process.

The reason that I highlight this is that we have had another issue recently. Suddenly, a process that has worked perfectly for almost a full year, now doesn't. A member of the finance team was left in tears because she was being blamed for not doing her work correctly - a job that she has been able to do completely satisfactorily every month for 11 months, she is now unable to do at all. It took a while to identify the cause, and it is due to a consultant working on something, making a change that he hasn't checked, but pushed thru to the Production system.

The modification is required - in fact it was required before we went live, but the consultants that are still on site have only just started to look at this specific item. Essentially, the config change means that a process has been changed slightly, and now we need to re-train other staff in sales support. They have to change the way that they work and do their process to meet the new requirements, so that this will go thru to the other areas, so that the finance people can then do their work. But of course, no-one has said a thing, none of the project team were aware of the change made, and no testing or training has taken place.

I raise this issue because I have made a point of getting my own staff in IT off to an SAP training center over the last year. We have completed a number of courses between us, and the cost in total has been just under $18,000, even with some travel, accomodation and meals - and that's still less than 12 days consultancy fees. Which is the better value? As far as I am concerned, we learnt far more at the training center and it was better organised, so for me it is pretty clear. It also has to be said that following the SAP training, we actually now know what we are supposed to be doing, which is more than could be said for the training we received from the consultants.

I've suggested many times, that it would make sense to get some of our project team off on some of these courses - possibly even some of the non-project team super users. I recently identified a series of 4 courses that would be of real value in a particular area of the business. The cost would be just under 5 days consultancy and I am fairly confident that the person I suggested for the courses would be able to pick up exactly what would be needed to get the best value from the courses and to ensure that he would be able then to pass that knowledge on to others.

Instead, the director from the SI firm has arranged with our CEO and internal project lead to have another one of his consultants come to site for 10 days to look at this specific module, get it set up and train the staff. As this is a guy that we have had on site many times before, we know what his area of expertise is - and it isn't this particular module. We know what capabilities he has in training and to be blunt they are pretty awful - several staff have stated privately that they don't like the guy as they consider him to be arrogant and offensive and there are female staff that really don't want to be part of the training if he is running it.

It also has to be said that he considers himself to be a jim dandy ABAP developer. I don't know sufficient about ABAP myself to measure his skill in that code, but I have worked with other codes and in software development, and I can say with some assurance that he just is not that good at doing program coding in a structured and managed way. He has taken it upon himself to make more than a few changes to code that have caused issues and it seems to take quite some time to get corrections to these problems.

It seems so odd to me - that senior management are willing to pay a substantial fee to a firm that have not exactly shown themselves in the best light, for a consultant that seems to cause more problems than he resolves. All this to work on an area that our own staff might well be able to do once they have had the right training, and which training will cost less than the consultancy fee.

It does seem that the senior managers have a blind spot in this - they value an external consultant in a suit higher than their own staff, even when the evidence doesn't seem to support their belief. I just find it so frustrating.

Qualifications

I'm going to be taking a short vacation - my wife's sister has been unwell, so we will be visiting with them for a short while. However, I want to leave you with a few thoughts.

Now I accept that I have only done the one implementation project - I have however, spoken to half a dozen people that have also been involved in completely separate projects. Based on the information from these, I am going to highlight a few issues that seem to be common between these.

In the cases involved, the projects all overran by a considerable amount - they also cost a significant amount more than was originally budgeted. Another common complaint was that there were many more days consultancy involved than had been advised and everyone highlighted issues with the quality of the consultants involved, the knowledge transfer that took place (or didn't!) and problems with getting the right advice for the business concerned.

Now I have slowly come to see that actually the software does do what it needs to (for the most part). I still think that it looks outdated, some of the processes are very cumbersome, and there are a number of technical items that seem to be designed by people specifically to ensure that they will always been needed. But there is no question that it can be made to do what is needed by many organizations, and if done correctly, will actually achieve what it was designed for - to help a business manage itself better.

The problem is that when an issue occurs, it is always "Darn SAP" (or worse). People are not able to distinguish between the software product, the company and the System Integrator employees (and why should they?).

Taking a slightly higher level view, I could say that it could be down to the implementation process. But if you look at the methodology, it should work (and I am assured that it does by many more experienced people than myself). It meets the needs of the project if carried out. But there I would say is a key problem - from my own experience, I know that the SI director constantly used that SAP image with the project roadmap used in many books to prove that they work to the SAP methodology. But just using the image is not the same as actually following the full procedure.

It could of course be down to the individual consultants. We were promised experienced people with key skills, but instead got people that proved to be relatively new to the SAP world. In many cases, they had received SAP training, but it was in modules that they then didn't work on - and as a result, we have found many areas where we were given poor advice, and are now having to consider re-doing several major sections of the project again.

In a recent coversation with our senior finance officer, she made the comment that one consultant had been on site, then was called back in to do the job that he should have done the first time but didn't - and was then called back a third time to fix the problems that he created the second time! What really annoyed her was the cost - we know that he won't get what we have paid the SI, just a part of that, but even if he only gets half of what was paid, he will actually recive more money this year from us, than any of the senior management team below the C level.

Now all of this is creating serious PR issues for SAP. To be blunt, if we had that sort of major perception problem with our customers, we would have had shareholders screaming for heads to roll. Somehow though, SAP seem to get around this. But the question then is for how much longer can this situation remain unchanged? Surely SAP need to take a long hard look at the people that are representing them and ensure that these people are doing the right kind of job in order to preserve a reputation just like everyone else?

Now at this point, I think it fair to mention that a while ago, a couple of long time readers (Jon Reed and Denis Howlett) along with a couple of other guys set out to take a critical look at just this topic. They produced a document that I have now had the chance to read and made a number of key suggestions that they felt would be to everyone's benefit. I'm adding link below as I think everyone should take the time to read it.
(http://www.jonerp.com/pdf/sap_certification_from_cert5.pdf)

Now you can read what you like into what they say - personally, I think they make a lot of sense. Can you imagine McDonalds operating the way that SAP seem to? The reason that McDonalds are so successful is that they have a key set of operations and every one of their restaurants has to follow them - if a franchisee chooses to ignore these, he may well find that the franchise is taken away from him. They go to great lengths to ensure that the correct training is carried out, that staff work to the defined standards and that is "policed" by careful observation from "mystery shoppers".

From what I've seen, most SAP SIs are rewarded not for the work that they do, but just on how much money they generate. It's therefore in their interest to ensure that costs are kept down, so they engage less well experienced staff. They don't worry about doing a good job - after all, they will earn more by doing a crappy job and getting called back in again and again.

Perhaps SAP could take a look at the McDonalds method - perhaps they need to police their SIs more carefully. These people are representing SAP, and if I was an SAP shareholder, I would want to make darn sure that they did so in a way that I found acceptable.

SAP have training academies, run both by themselves and by others - is there a difference in the quality of the teaching? I can't say for certain, but I suspect from what I have seen that this is a possibility. Having taken a certification, is there a need to refresh it? There have been a lot of changes in various processes in the last few yers, and I know that the guys we had working with us were not aware of many of these. Perhaps SAP should declare a "life" to a cert - say 5 years? After that, the consultant would have to retake the exam to prove that they have stayed up to date.

Certainly from what I have seen, I would question the value of some of the certs. Back in the 90s, people were highly critical of "paper MCSEs" - Microsoft certifications that were obtained without real knowledge, just a series of brain dumps. These days, it is almost impossible to pass an MS exam without real handson experience - they heard the complaints and have done something about it. Can anyone say the same about an SAP cert?

I would say tho' that I don't have too much confidence in seeing any changes any time soon. I do wonder if SAP have reached the point where they are so big that they think they will just carry on the way they are without having to worry about standards. Oh well, time will tell.

See you again in a couple of weeks.

Irritation with invoices

It's been real busy the last few weeks - we've had some issues with invoicing. But to really understand the problems, and to put it in context, I need to go back to the early days.

When we were starting out, almost everyone seemed to either know someone or had talked to someone that had a story about SAP and invoicing. I got talking to a copier salesman who told me that his company had implemented SAP and were unable to invoice anyone for about 9 months after their go live. From what he said, it seemed the business almost went bust - and they were a multi billion dollar outfit. This did cause some concerns, and so we wanted to make sure that this sort of thing wouldn't happen to us.

Right back at the beginning, we gave the system integrators a copy of the paperwork we needed to generate - I'm not sure, but I think it was within the first two weeks. This included the invoice and we made it very clear what actual information needed to be on it. We weren't too bothered about the specific layout, orientation, fonts etc. but the right text was vital. This had been developed over many years, and much of it was as a result of various problems with customers.

We had got thru the initial planning stages and were starting to work on the config and data. At one of the sessions, someone from finance asked about the documents (invoice, sales forms, shipping forms etc.) - the consultants' project manager told us that someone would be working on these. Now we had been told that we would go live on a date 9 months after the initial launch - when we got to month 6, and there was still no sign of the documents, the question was raised yet again.

At that point, a director from the system integrator firm got involved and he basically tried to tell us that we would be using the standard SAP forms as that was all we required. You can imagine that there were some fairly strong discussions about this - it had been highlighted that we needed the specific text and we weren't prepared to move on that. Eventually, he gave in and arranged for a specialist to come to site to work on the revised documents.

Now I had previously worked on another ERP product and had produced numerous standard forms pretty quickly - generally, once you know what is wanted, it takes maybe a day to get the right data output, and then maybe a few tweaks to get the formatting right. I expected that SAP might be a bit more work, but as a basic design already existed, I thought it was just going to be a matter of making the relevant changes to ensure that we had the right logo, the right addresses and text statements.

The specialist turned up on site and started on this a couple of days a week. About 3 weeks later, we were given what the consultant said was our invoice - and forgive me for saying this, but it was a bunch of crap. It was missing two whole sections of text, it showed the wrong address for the company, none of the text boxes lined up and when it printed, part of the page was missing and our company logo was squashed up so that it looked wrong. The CEO wrote all over the printout in red pen to highlight the areas to fix, then gave it back to the consultant. She worked on it again for another 2 weeks and sent a copy to us. The CEO hit the roof as it looked like nothing had changed at all.

This went on for another couple of months with the consultant turning up on site every few weeks and supposedly working on it from home in between. But after about 4 months, not one of the forms that we needed was actually complete. This lead to more discussions - as we had already decided to delay the go-live, we could live with it, but at that stage were only moving the go-live by a month or two at a time, so it was really important to get the forms completed.

After more complaints, another consultant started to work on it. A couple of months later, we had some of the sales documents, and some for the shipping, but the invoice was still missing. In the end, we finally got the version that we went live with about 2 months before the go live date - about a year after we should have gone live. The invoice form still wasn't exactly right, but we could live with the slight inconsistencies in alignment as long as the text was OK.

As it happens, after go live, we then hit a snag. A process had been set-up so that the invoice would be automatically generated once all of the parts for an order had been shipped. There were a couple of exceptions - we have a couple of big customers that buy regularly, and we are able to invoice for goods shipped as part of orders, even if the whole order has not been completed. The week after go live was OK, but the invoice run after that was not.

As it happens, we quickly found that this was actually down to us - there was a procedural problem, and stuff was not getting marked up properly. As a result, we had some orders going out that should have been invoiced, but weren't - and this lead to a number of other items that were then being blocked. As it happens, altho this lead to a bit of a panic, we did get it fixed real quick and the invoices started going out again. In fact, this an area where we definitely had not had the kind of issues that so many other projects seem to have had.

But a couple of weeks ago, we had a real serious issue. The invoices are printed off on a big high speed printer in the finance office. The print run generally takes about 15-20 minutes each day for those that are not transmitted electronically (and there is an increasing amount of those). One of the staff in accounts noticed that the print run hadn't occurred - after checking, one of my staff realised the printer was not working at all.

Well no problem - just re-direct the print job to a different printer. After all we do this all the time without any issues with all the other forms. But it appeared that we couldn't do that with the invoices - every attempt, the print job was being sent to the faulty printer. Eventually we realised that for some reason, the printer selected was actually hard coded into the form and couldn't be changed on the fly unlike all the others. Now why this is the case, I have no idea - it is just the way that it has been setup.

As it happens, we have got around the problem. We have another machine of the same make and model. We've changed the settings on the print server so that the replacment machine has exactly the same share name and IP address as the faulty one, and we were able to set it up within SAP to replace the faulty machine, so we can now print off the invoices as we should.

It has caused a slight holdup in the billing process - I spent about 5 hours on Friday with one of my staff helping the finance staff get the newly printed invoices put into envelopes ready to be posted. This has helped them catch up, and as everything has gone out in the same month as it should have, we shouldn't get too much of a delay in billing.

But I see this as a major irritation - I can see the need perhaps for labels to have the printer hard coded in them to make sure that they go to the right type of machine. But why an invoice? I really can't see why they should have done that. I also have to say that this was an area that I wanted to try to get a better handle on, but the consultants were simply not interested in passing on any of their precious knowledge and no-one got chance to learn how to work with the forms. I did get a book on it, but it wasn't much help.

I've also tried to get one of my staff booked in on a course to learn about changing forms, but there doesn't seem to be one available until next year. We also have a major problem now in that we have a lot of work coming up, and some of it will be last minute organised (nothing we can do about it - we have to be flexible to fit in with others). It could be that we will simply have to wait - and hope that the printer doesn't break down again.

However, I suppose that now we know the problem exists, we are in a better position. We know how to get around the issue, so we shouldn't get the same delay if it happens again. With luck, the replacement printer will last until we can get someone trained up so that we can get this form fixed more appropriately. With a bit of luck, we will have a couple of quiet weeks to make up for the rather more hectic weeks of the last month!

Count the cost

A few weeks ago, I highlighted the case of a local government organization which had tried unsuccessfully to implement SAP. As it happens, one of the regular readers of this blog had let me have details of another case in California shortly before that - I have been trying to get some more information on the situation out there, but without much success. In both cases, they have spent a great deal on their implementation without seeing any real benefits - and it looks highly likely that they could cancel their projects having spent millions of public finance for no real value.

About a month ago, I was browsing thru SCN (SAP Community Network). I read an article that I found really interesting (can't remember who by, and can't seem to find it again). The author asked why there were so many stories of poor implementations, and so few stories of successful ones. If I were to be a bit facetious, I might say that it reflects the real situation - but I am actually not sure that is the case. I found the comments made in the item quite interesting, particularly when analyzing the two cases I've highlighted and the situation at the place where I work.

As a general rule, if people are satisfied, they tend not to say very much - they will only make the point publicly if they are extremely pleased. On the other hand, if they are not happy for any reason, they will let you know, often in no uncertain terms! This is just the way that people are - anyone working in customer service will be aware of this. It's usually seen as normal that you will get a lot more letters of complaint than you will of praise - and the complainers will often highlight relatively minor issues, whereas the praisers will normally highlight more major aspects.

One of the common complaints over SAP implementation is that the cost is so high. In our case, we have now spent over $2.5 million with the System Integrators, and it is still climbing. But that doesn't include the internal costs of staff time involved in the project. No exact figures have been kept, but it would seem that most people agree we have spent at least another $1.2 million, probably more, and there is more to come yet.

And we are not finished - we have to roll SAP out to sites overseas, and no-one is prepared to guess what the costs will be, and certainly not what the final tally will reach once they are all done. It also seems likely that once we complete the intial implementation, we could find that we are paying for further development work - it's possible that the project costs will continue to rise over the next couple of decades.

Now there are many that will say we haven't actually spent that much - after all, the implementations at the two organisations highlighted have both been in the 10s of millions of dollars. But they are both much bigger projects, with more people involved so they are bound to be more costly. They have greater revenue streams, so can afford bigger budgets. In our case, the amount committed is many times higher than was originally planned and it has eaten up our annual profits for the last couple of years. It makes it difficult to find cash to pump into other areas of the business that are in need of investment, and this could have a negative impact on our ability to continue to trade.

There are those that say a project involving an ERP implementation cannot just be judged on the same criteria that a smaller project would be assessed against. For example, cost and time overruns are less important than making sure the project does actually get finished and that the product should be judged on many more aspects. I can see the logic in this, and to an extent, I would accept that we do have to take much more of an overview for such a major operation. But equally, no-one should just continue to pour greenbacks into something if there is no indication that the results will justify the expenditure.

In our case, we were assured right back at the beginning, that the costs for the first five years of software, consultancy and support, would be around $1.3 million. Clearly that was a badly underestimated figure and in fact we will probably have spent more than 3 times that much, not including the costs of our own people by the 5 year mark. If that were to result in savings, extra sales or improved margins, then an argument could be made that it was all worthwhile. I would agree that we have seen some efficiencies, but I'm afraid not enough to offset the high cost of the project.

No-one believes that implementing SAP will actually help us sell more - it doesn't make the sales process any easier, and is not going to help us win new business. It may help us improve our margins, but that is more of a long term initiative and won't help us deal with more urgent concerns. I may be wrong, but I suspect that we may never see any return on our investment, even if we take a really long term view of 25 years.

So how do we then assess the value of our implementation? I wish I could answer that. Yes it is working and in that we have clearly been more successful than some others. But has the cost been too high? Only time will tell.

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.

Call me certifiable

There is no question that the advent of the PC has made a huge difference to businesses. Over the last 20 plus years, we have seen the introduction of systems that are designed to improve the way that we operate. The PC promised more accurate information processing, better analysis, greater efficiencies, and faster communication. However, this came with a slight downside - unfortunately, there were not enough people that knew how the computers worked.

My youngest daughter has a book, and one of the quotes in it is "when she was good, she was very, very good; when she was bad, she was horrid!". There are a lot of people that work with PCs that could say the same of their systems - when they work well, everyone can operate them. But when things go wrong, you need to have someone that understands what is going on behind the scenes and rectify any problems.

However, a lot of people of that time that called themselves "IT staff" were just people that had turned a hobby into a job. Far too many of them knew enough to make it sound as if they were experts, but in reality, they relied upon the lack of knowledge of other people so that they could just BS the way thru a problem. Companies needed to have someone available to help fix problems, but they didn't know if a particular person actually had the right skills or not.

Over a decade ago, Microsoft introduced their MCSE certification. The idea was simple - produce a formal training and examination process that could offer organizations a way to see if a potential hire actually had the relevant skills. Others were doing the same - they all saw the value to their business model by offering customers a means of being more comfortable with their purchase, by knowing that people they employed had a minimum level of skills.

The problem was that the certifications then meant that some people could command higher salaries - and that then lead to the "brain dump" sites that offered people the chance to learn answers to specific questions, without necessarily knowing the product that well. These were followed by "boot camps" - places that could allow you to undertake intensive training for a week or two just to pass the exam. These lead to what became known as "paper MCSEs" - people that had the certification, but not the experience to go with it.

Since starting our SAP project, I've obviously taken more note of a lot of things that I see out on the Internet to do with SAP. Like a lot of people, I've seen the posts from people asking how they can get into SAP consultancy. I suspect that in most cases, they've heard that they earn a whole bunch of money from this and are hoping that they can a course or two, get a certification, then sit back and watch the dollars roll in. I don't know if there is such a phrase as "paper SAP consultant", but I think that such people are out there in abundance.

What worries me a bit is that I think this is more common than most realize - and as a result, we get consultancy firms charging their customers $1500 a day, but they then employ the newly qualified people on maybe half that. We were given the resumes of the consultants that we were to get which were satisfactory - but when we didn't get the experienced people that we were promised, we should have done something about it, certainly asked for more info on the people we did get.

As it happens, I have taken a couple of courses at an SAP Training center and I think that the quality of training there is very good. I have made a couple of my staff take courses and they have learned a lot - and there is no question that this will help us do our jobs better. But it worries me a little that one of my staff now has an SAP certification - although he has taken the courses and done a little bit of work on the product, I would question if he is really sufficiently experienced for him to be at that level. He could in fact leave to go somewhere else with that paper - but I wouldn't yet suggest that he is actually ready to become a consultant.

I've also noticed that this is an issue that concerns a lot of people within the SAP consultancy world - they see the poorly trained, barely certified people screwing up and giving them a bad rep. I can actually understand their concern over this and I think that it is good that is recognized as an issue. I think that SAP could do themselves a big favor by monitoring just what a lot of people with their certifications are doing out there - I think that they might not be too happy with what they find.

Now I don't pretend to have a complete answer to this problem - but I think that it would have to start with listening to some of the more experienced independent people. They are the ones that suffer the most from other people's poor performance, and they generally have less to gain by covering up problems.

I have a qualification on the wall behind my desk - it shows that I have undertaken a considerable amount of work over many years to achive a high standard in my work that hs been recognized by a prestigious institution. And yes, I am quite proud of that qualification as I am of the many others that I have obtained. I wouldn't mind adding an SAP certification into my collection - but only if I feel that it means something of real value, and not that it is just there to allow me to ask for an extra five hundred bucks a year.

Meet me in St Louis

We had a team meeting the other day, and it got me to thinking about some of the project meetings we have had in the past.

A lot of people don't like team / project meetings - all too often, you can see them drifting into their own little worlds, trying to hide their yawns, doodling on pads, apparantly fascinated by their socks, desperate to be anywhere but where they are. But meetings are important - you have to keep people informed, get them to agree on what is going to happen and make sure that what is planned doesn't cause too much disruption or interfere in other peoples planned work.

For that reason, I like to have shorter meetings, with a clear agenda - preferably one that has been sent out before hand, so that everyone can prepare. (There is nothing worse than someone going to a meeting and suddenly being asked about something, and they have to speak off the cuff - too often, they forget important points.) There should always be notes taken and someone should type these up and circulate them so that everyone has access to a record of the details.

I also like to see clear action points at the end of meetings - with responsibilities and timetables or deadlines agreed. I also have no issue if someone fails to meet a deadline - we all have other work to do, sometimes this has to take precedence. But a meeting without an agenda or an agreed plan of action at the end, is just a talking shop, with no benefit to the business.

When the consultants organised the first launch meeting, they did actually have an agenda - but it wasn't circulated before hand, they just had it as part of a PowerPoint presentation which they referred to during the meeting. Unfortunately, the points listed were pretty brief - mostly just the names of the key stages within the process to be followed. They talked a lot about the stages, but again, mostly in fairly bland details.

The meeting dragged on for over 5 hours, not including the 40 minute break in the middle or the two coffee breaks. I still have my notes from the meeting and in the corner I have written "they could have covered all this in under an hour". I believe that I may have shown the note to one of my colleagues during the meeting.

For me tho', the biggest issue was that at the end of the meeting, no-one had a clear idea of what anyone was supposed to do, when the work was to be done by, what the next steps were or pretty much anything else. I remember a few days later, I spoke to a manager from the production area and asked about a particular issue related to assembling data on the products list - he replied that he thought that was for those of us in IT to do. When I pointed out that it was necessary to make sure the information was correct, and that only his people could do that, he was astonished - he had no idea of what I was talking about. I also had similar discussions with virtually every other department head, all of whom had been at the same meeting!

I did actually speak to the project leader from the consultants about making sure that information from meetings was properly circulated - his response was that it was our project and therefore it was our responsibility to manage all of these details. I can agree on things such as notes, action lists, and circulating details etc. but they were the ones actually planning and running the meetings, and therefore putting the agenda together. I felt that as we were paying for their experience in the project, it would not have been unreasonable to expect them to provide details of agendas and when their people would have been on site, and what they were there to do - but clearly, he didn't agree with this.

As it happens, shortly after that first meeting, I organised a structure for the notes to be taken and posted on an intranet site as a resource for people to refer to. I also tried to get a regular action list agreed, altho' that proved a bit problematic, particularly if I wasn't at the particular meeting. Many of the presentations were supplied by the consultants and were also posted, but I don't think anyone actually bothered to refer to these as they contained so little of any benefit. I also setup a snag list and that very quickly became a very lengthy file.

Looking back on it now, I think that if we had been able to get a bit more disciplined from the start over the way that meetings were planned and organised, and there had been a more structured approach to getting notes, actions lists etc out after meetings, this would have made sure that we stayed a bit more on track. Certainly I feel that there was an amount of time wasted due to lack of adequate control.

It would be unfair to blame all of this on the consultants - partly it has to come down to company culture and the individuals concerned. But I think that the consultants could have given some better guidance - they are supposed to have seen many projects, so should know the importance of getting organised and making sure that everyone knows and understand what is required.

If you start off in a particular manner, people generally continue in that way - unfortunately, if you don't get the right type of disciplined structure in at the beginning, people will just do their own thing, and instead of everyone working together, you get a more haphazard approach. As it happens, we overcame that, primarily by sheer hard work on the part of everyone on the team. But I think that it could have been made much more effective from the beginning and getting the organisation of meetings correct is a first step to a better project.

Evaluating efficiency

At the beginning of the SAP implementation project, it was identified that one of the key drivers was to improve efficiency. We had a large number of systems, none of which talked to each, and as a result, a large number of staff were involved in just manipulating data. It made sense to try to get all of the data in a single system so that it would be easier to work with - and don't say this too loudly, but it was felt that we could perhaps reduce headcount by being more efficient.

We were told that it was possible to improve processes by using the various processes that were built into the SAP software. A number of key areas were identified and we looked forward to seeing these in action. However, in most of those areas, we have still yet to see any significant improvement. In some cases, we have had to take on a couple of staff as the process is now a bit more complex than before.

However, there is an area where we have seen some spectacular improvements - the funny thing is that it was completely unexpected. It has made a major difference to many departments, has saved hours of work every week, reduced waste and saved a sizable amount of money.

When I first joined the comapny, I discussed the concept of electronic document management - at that time, everything was paper based. It was decided that it was not practical, and when we started work on SAP, it was not even put on the blueprint. Having talked to one of the consultants, he did some work for us to set it up, and I bought and installed some hardware to allow staff to scan all incoming documents.

To begin with, there were a few teething issues - getting people to understand where the files were being scanned to was the biggest, and then getting these attached to the relevant item within SAP. But within a fairly short time period, almost everyone was getting to grips with the system.

To explain in more detail, let's look at the sales office. They process around 1,000 orders a week - and every day without fail, they will get a number of queries about an order that has been placed. In the past, this caused some considerable work - although they had access to the data entered, people would question if the order had been entered correctly. The staff member would have to take the customer's details, then hang up, and go look for the original documentation.

As this was not a key driver, we don't have hard evidence of the time taken to recover the paper files, but it is generally accepted that it would normally take between 15 and 30 minutes for each order. (Some would take longer, particularly if the file was misplaced). The staff member would then have to call the customer back wasting more time - and of course, it caused some frustration with the clients.

Now, if someone queries an order, the sales person can click on a link and the scanned file opens up in a matter of seconds. I don't use it that regularly, but I can find and open an order, and then the scanned file in about 40 seconds - the sales staff can do it in just over half that time. And it is not just the sales office that benefits from this - purchasing, accounts, distribution are all making good use of this facility. In fact, we estimate that we are saving the time equivalent of between 4 and 5 full time staff each and every week with the document management system. (My colleagues agree that is a conservative estimate.) We think that as we roll it out to other sites, the savings could be as much as 20 full time staff.

Now don't get me wrong, we are not going to be laying staff off any time soon - but the time saved is going to allow us to do more things that we need to. Sales can do a bit more cold calling, a bit more customer relationship management etc. Some of the saved time will be used to make sure that they have more time to concentrate on other areas where they are not so confident.

I had a comment from one of the staff the other day - she said that the document management system on its own was almost worth the effort of the SAP implementation. Well, I'm not sure that I would totally agree as the cost has been so high. But it is an area that we can point to, in order to highlight success in the project, and as my old football coach used to say "a win is a win".

Now a lot of people within IT will say that this should not be such a surprise - electronic document mangement has been around for many years, and the benefits are well known and fully documented. But you have to understand that for our company, this is a completely new way of working - and one that took a bit of effort to get people to use in the initial stages.

If staff get excited about it because they can now see some tangible benefits, then that is a good thing (a really good thing!). We can then try to use that to get them on board with other aspects of the SAP system. If one area of the system makes their jobs easier, then maybe we can encourage them to be more positive about the rest of the system - and who knows, maybe we will eventually be able to say with hand on heart that the project was worthwhile. We may even see a return on our investment!

Trouble with training

When I was still in high school, I had an English teacher for a year, who told me something that I still remember - "Learning is a science; but teaching is an art". At the time, I didn't fully understand what he meant, but over the years, I have come to see that this is actually a very profound statement.

Since college, I have worked hard to keep my skills up to date. I've read technical material, books and white papers, many of which I have kept - and these have sections highlighted or pages marked out with colored tabs. I scribble comments in the margins, and occasionally use post-it notes as well. I use a structured method to read, digest and understand the various items, and it is clear that this is a scientific approach to gaining knowledge. For me, this is the best way to learn new things - altho I always then want to try to apply what I have learned in a test environment.

However, this method doesn't suit everyone. Altho I am happy to spend my own time wading thru various documents, most of my colleagues are not so eager. They leave work at the end of the day, and don't really want to spend their leisure time on what they see as "work related" tasks. Having said that, they are also not too keen to spend much of their working day reading books. At the beginning of the project, we bought a number of the SAP Press books (and some others) which were handed out to the relevant department heads - many of these books were opened once, a few pages looked at, then closed, and they have remained that way since.

The reality is that not everyone is comfortable with self-learning material - they find it difficult to motivate themselves to work their way thru the material, and have difficulty in relating what they read to the work that they do. This is an issue that affects a lot of the training that we carry out, not just SAP - and this is where the teaching "art" comes in. It is necessary for the tutor to understand that each person is different and requires different methods to learn - and the teacher has to have a streak of creativity that allows them to develop ways of presenting the material that will get thru to the student.

During the project, the various project leaders were encouraged to create self-study items to be used by the staff. These were generally involving a single process or part of process - for example, "how to create a sales order" or "how to release a purchase order". I setup a shared repository for these files, and access permission was given to all staff to read and a few more senior people to change or replace, so that they could go thru the files, make whatever changes were felt appropriate to make the materal as relevant as possible.

Unfortunately, it appears that none of the staff actually use this material. Altho it has been specifically aimed at providing them with the right information, and they have all been reminded of where to find it, no-one actually makes any use it at all. It seems that the concept of learning by reading is totally alien to them and that doesn't look as if it is going to change any time soon.

When I first joined the company, I expressed my concern at what I saw a very low level of IT literacy amonsgt staff. People had learnt by rote - "press button 3, press button A, press F7". They had no idea of what these keystrokes did, or why they had to press them - they just knew that was the sequence.

In many cases, altho they were carefully trained to use other equipment, or given instruction in safety procedures, they had received little or no training on how to do the specific task on the computer. At best, someone else that just knew the sequence without understanding why would pass on that information, often by writing it down on a sticky note which was then pasted on the monitor.

Senior management were not particularly bothered - they didn't see the need for staff to be "IT Trained" as they put it. I can understand that there is a limit, but I do feel that a lot of problems are caused by inadequate training, and these create problems, delay work and all of this will actually end up wasting money.

With the SAP project, I had hoped that we move away from this attitude and be able to get people properly trained. The problem is of course that if people don't have the right motivation, then it is unlikely that they will improve their skills. If we can't improve work practices, then we will never get the full value out of the SAP project. I therefore suggested that we needed to have a properly dedicated training facility.

So we set-up a fully equipped training room for IT - this is available for everyone to use and there was some good use made of it before the go-live. However, since then it hasn't been used once. I think that this is a shame as it could help us get more out our investment. But with so few people having the self-motivation to learn new stuff and the discipline to stick with it, I suspect that we will not see the value that we should.

Ultimately, we need to change people's perceptions - it is just no longer good enough for someone to know the sequence of key strokes, they need to understand the process and why they have to follow it.

Practice what you preach

Over the years, SAP has worked with a lot of companies in different industries - they have seen many different ways of working, and various people have developed parts of the program to modify it, to allow better integration with the business processes of those organisations. When a vendor then sells SAP to a new customer, they then promote these as "best practices" and suggest that if the more successful companies (using SAP) use them, then it makes sense for the newer purchasers of SAP to use them as well if they wish to be equally successful.

I'm not sure that I fully endorse this idea - just because a successful business uses a particular process does not mean automatically that process will work elesewhere, or that it is the best way to do something. I've seen many different organisations and ways of working - each had their own methods of doing things and in most cases, they worked really well. However, I am prepared to keep an open mind on the topic.

I understand the concept of challenging existing practices, and agree that sometimes a business can get stuck with doing something a particular way because "that's how we've always done it". My own company had exactly this issue (and in some areas, I think that we are still suffering the same problem) and it makes sense to use the implementation project as an opportunity to examine what we do and try to find more efficient methods of working.

As it happens, I believe that this is a process that should never end. People should be encouraged to try to find better ways of doing things and as this does not always come naturally, it may be necessary to undertake appropriate training. I spoke to several of the consultants working on our project, and what became clear was that none of their people have attended any official SAP training sessions or seminars in the last 5 years. This would raise the question if the "best practices" that they are advising us to follow are actually the most appropriate or up to date.

However, I believe that the "best practices" are not just about the processes that are used within the normal business flow. I'm sure that some of the more seasoned SAP people that follow this blog will correct me if I am wrong, but it seems to me that the "best practices" should also include the way that the SAP system is structured and managed. In particular, such elements as change management & testing are crucial and it is vital that correct procedures are followed to ensure that when development work is undertaken, it does not cause problems to the operations of the organisation.

I have to admit to being very concerned about the way that our consultants seem to ignore the practices that SAP promote in this area. As an example, shortly after go live, our internal project manager highlighted that we still needed a particular report (one that had been requested way back). One of the consultants worked on this and in due course, I received an email to request that certain staff should be given access to a new transaction that had been created from an existing one. But when I tried to do this in the golden list, the transaction simply did not exist. It turned out that he had unlocked the production client and created the new transaction - then locked the client, instead of creating it in the development system and transporting it in the approved manner.

I queried this in an email, and received no reply - I'm told that when the consultant concerned was questioned about it, he became angry and told the project manager that I was being unhelpful. I subsequently found that he then unlocked the production client again, and added the transaction to some roles, before locking it down. That worked fine for a couple of days, but after I had carried out another transport of roles between the systems for another update, the transaction was again not available.

Of course, he then did the work in the correct way (although I note that the transaction is slightly different in the production system to the one in development and test systems). But it seems strange that he wouldn't use the correct procedure to begin with - he should have known what would happen. I regret to say that this is not an isolated incident, and there have been several other similar issues with work not being done according to SAP's own guidance.

Another area of contention relates to testing of development work - or rather the non-testing of development work. Checking in the transport system, I see that one particular item was transported from development system to production system a dozen times in the space of an hour. It's clear that the consultant was not bothering to check anything in the development or test systems, but simply making a change, transporting it and testing in the production system.

What worries me a bit is that the project team have been working with the consultants, so they have seen these unsatisfactory processes and seen them as normal. If I suggest that doing something a particular way is not appropriate, they immediately point to the consultants and indicate that is the way that they do things.

So does it really matter if people don't quite follow this "best practice"? I would suggest that yes it does - SAP is a large, complex, inter-related piece of software. The procedures are there for a reason, to ensure that the changes that are required are working appropriately and do not cause issues elesewhere. If people don't follow the procedures, then things can go wrong, and putting them right can be a huge undertaking.

What is worse, if someone gets used to doing something in a particular way (even if it is wrong), then it is hard to get them to change. And this of course then brings us back to the beginning - we have replaced one set of practices with another, but neither of these are "good practices" and I seriously doubt that we could define them as "best practices".

But perhaps that is just me - it could be that I am making a mountain out of a molehill. These issues are causing the IT staff work, and we seem to spend time on dealing with what I see as unnecessary corrections rather than what I feel we should be doing, which is the more proactive work to maintain systems. However, we are coping, so maybe things are not so bad after all.

Confidence vs Arrogance

I like to think that I am pretty confident, and generally for a good reason. Over the years, I've proven my skills many times - I've managed my teams, my budgets, some big projects and delivered real measurable benefits to the various companies that I have worked for. When I am in a particularly good mood, you may hear me say that I can fix anything, given the time and resources.

In fact, at one previous position, I was known as the "go-to guy" - if they had an issue, the first name that came up was mine. Where was I. what was I doing, could I be moved to take care of the problem. My direct manager loved to use football metaphors -he told me that whenever someone fumbled the ball, they looked to me to pick it up and run with it.

Having said that, I recognise that I don't always know the answer. Sometimes, it is necessary to fully analyse a problem, and look at alternative answers before choosing a course of action. It's often necessary to look to other people for advice and support - and sometimes even relatively junior members of staff can have good ideas. It's foolish to ignore these just because of the status of the person, but a lot of people will do just that. And I'm more than happy to accept that I've made a few bad decisions at times - but I always try to learn from these so that I can prevent them being made again.

The problem is that sometimes, confidence can cross the line into arrogance. I would suggest that a couple of our consultants have crossed that line - and one guy in particular stands out.

When we first started the project, some 3 years ago, we were given a series of resumes of the people that would be working on the project with us from the consultancy. These looked really good, with a group of people that had all had at least 6 projects and and an average of 8 years working with SAP.

Unfortunately, none of these people were ever "available" to actually work on our project, so we had a group of people that we knew little about. What became clear was that in most cases, they had limited experience - an average of 2 or 3 projects with at most a couple of years experience.

However, the one particular guy was uber confident - if you listened to him, he had almost 20 years experience of SAP and had worked on literally dozens of projects. He certainly seemed to be the one that the others looked to for advice whatever the problem.

As it happens, I met someone that knows this guy from a previous implementation. It turns out that he actually only has had coming up for 6 years experience, and our project is the first one that he has worked on for the whole lifecycle. Of the other projects he worked on, not one was for more than 5 months, and several of them were jobs that were being done at the same time and he was only a minor player in each one.

Added to that, the reason that his colleagues look to him, is that he makes changes without telling anyone or documenting the work - if someone has an issue, they check to see if it is caused by something that he has done. As for him being the one with the answers, it turns out that he has a direct line to some people that have a great deal of SAP experience, and whenever he hits a snag, he calls them - but then he presents their answer as his own.

Now to be fair, the guy has worked hard on our project - he has listed more days work than anyone else. He has dealt with complex requirements and produced some really good work, things that will eventually mean that we can get more out of our investment in SAP. It has taken a while but we are starting to see some of the benefits, and if we persist, I think that we will eventually have a system that we can be proud of.

The problem for me tho', is that it has taken a lot longer to get where we need to be, and that his over confidence has not helped us. A big issue is that he doesn't want to share his knowledge - he likes to do the work himself. This may be quicker in the short term, but it is clear that a key requirement for success with SAP is knowledge transfer, getting people to learn how to do things for themselves. It's also very frustrating when he makes decisons without sharing the reasons behind them - and particularly when subsequently they prove to be wrong, so that the work has to be re-done.

What really worries me is that now it has been agreed that this guy will be staying on to assist with carrying out a software upgrade instead of one of their basis guys being made available. I did ask him if he had done this work before, and he became quite incensed by the question, accusing me of not trusting him. Well it is quite simple - I can't trust him as he has been proven wrong several times with fairly serious consequences. The upgrade is a major step, and he has never even installed the software before, yet he seems to be utterly confident that he can do the upgrade work without a hitch.

Well we will see.

Keep on movin' on

So after having made a few posts about what I've seen eleswhere, I'm back to writing about our project.

As you might expect, things have begun to settle into place. Most of the staff are now beginning to know what the processes are, they can generally carry them out most of the time and we are now starting to see some of the benefits of the SAP installation project.

We are seeing far fewer mistakes with the purchasing which had previously been very high. No-one has quantified this yet in detail, but it appears that we may see some savings in that area of about $100,000 per year due to fewer errors. Although this won't cover the cost of the project, it was an unexpected side benefit that will be very welcome. There is also evidence that it has reduced the work load on the purchasing staff by an amount which will also be beneficial.

The finance department still have some issues with analysis, but the data is going in the system, and with the ability to attach scanned copies of documents, they have significantly reduced the problems they used to get with missing files. Again it is not something that we have tried to put a value on, but the accounts manager has estimated that it is saving her staff 2-3 hours work per week. This may not sound a lot, but the time benefit does mean that they are able to concentrate more on the actual work they are paid for, rather than simply chasing down bits of paper.

Sales still have quite serious issues - I'm convinced that we have not got the right approach to pricing which makes it too complex. They are now looking at changing part of the process which I think will help. Customer feedback has been mixed with some people seeing fewer errors, but unfortunately also some fairly major failures due to a problem in the system. It appears that if someone places an order, and then a few days later changes the order, the due date for the goods is automatically pushed back a few days, and this has caused some delivery issues and this problem has yet to be resolved.

Shortly after our go-live, we added in an electronic fax server service which can supplement the email transmission of orders, invoices etc. We did this ourselves without the assistance of the consultants (they wanted to charge us $25,000 in consultancy fees to do the work!). Customer comments are that they appreciate the new feature - there were a few issues back at the beginning of the year, but they mostly seem to have been resolved. The only problems we get are down to inaccurate data regarding email address or fax number - sales staff were supposed to have cleaned up the data way back, but it appears that they could have done a better job.

Distribution have also seen some benefits, although they have had a few major problems caused by the orders being pushed back incorrectly. There were also some inventory issues for several months, probably due to faulty data at the beginning, but these now seem to have been corrected. For some years, we have wanted to implement bar code scanning and this is an area that we think will benefit from this - the staff are quite positive about the concept, and I think that they would make good use of it.

The production area generally is also seeing some benefits with the use of the technology - previously everything was on paper. Again, the details have yet to be accurately quantified, but the production manager suggested that we have seen reduced waste and a slight uplift in productivity. Nothing to set the world on fire, but enough to suggest that the process change is beginning to make a difference.

Unfortunately tho' the project system area is still struggling. About 40% of the work is repeat business and that seems to be generally OK, but the rest is all bespoke and we are still seeing far too many issues. We've had one particular consultant working on that are from the beginning and although I accept that the requirements are quite complex, I think that he seems to have taken a very long time to address some of the simpler issues. The scheduling of work has been one of the biggest issues and it still isn't working as it should which has an affect on so many other areas.

So pretty much a mixed message overall - definitely some benefits in time and cost savings, but some issues yet to be fixed that still frustrate everyone. We have a little bit more time to try to address these, but soon the company wants to start rolling SAP out across the rest of the group. We have a couple of sites in this country and a few others elsewhere and I think that we really need to try to get these problems sorted before rolling it out any further. However, I am a bit concerned that we won't get the time, as pressure is on to try to standardize across the group.

Still; as the man says, "keep on movin' on". We will get there, it may just take longer and require more effort than perhaps it should.

People get ready (part 2)

I've been off-line for a couple of weeks - busy at work, then the chance of a last minute vacation. But I'm back now.

As I indicated, earlier this year, I had the chance to meet up with some people at companies that are also involved in SAP implementation. Two of the companies were large organizations - both had $1 billion per year plus revenue, so they were both much bigger than the one that I work for. One has about a dozen sites around the world, with between 250 and 500 staff at each - the other has about 80 sites around the world with between 30 and 200 staff at each.

In both cases, the parent sites(s) have already implemented SAP and are making good use of the product. One for about 2 years, the other for a little less. They are now planning to roll this out to the rest of the business and it was interesting to see how they plan to do this.

In both cases, they had a consultancy on site for the original implementation - one of these was well known, the other less so. The larger business took almost 4 years to get up and running, and although they didn't confirm this, I did hear that they had a false start, and after just over a year, pretty much went back to the beginning.

What was clear was that in both cases, they had a fairly clear idea of what they wanted to achieve from the project. They also had a set of KPIs to measure against, although one guy I spoke to said that these appeared to have changed after the false start. The directors of both organizations were keen to see the project succeed, and a great deal of effort went into making sure that the work was done as required.

However, in both cases, they indicated that they had major issues - a common complaint was that they didn't get the same consultants throughout the project and this lead to several instances of work beng delayed or being done incorrectly due to lack of consistency. I found it interesting that they also had issues in getting output documents sorted out, something that has plagued us from the beginning.

One thing that was clear in both cass, was that for their rollout across their larger business, they are very keen to avoid making use of any consultancy at all. There were a number of comments (some quite strong language as well) that indicated their preference for using their own internal staff as much as possible.

They have both set quite ambitious targets for the rollout - I did query this, and their senior management seemed keen to push ahead as quickly as they could. No doubt this was to try to see some sort of return for their investment The staff that I spoke to were not quite as confident that they could do it in the time allotted. One manager expressed serious concern at the proposed plans, indicating that it could mean no vacation time for any of the key project team for the next 3 or 4 years. She also said that most people agreed it seemed unlikely that they would be able to maintain the current plans, and the dates would inevitably slip.

As it happens, in both instances they are actually late starting their roll out to the other sites. In one case, they have been trying to get a suitable Project Manager, which they now have, but I was told that he has only ever been part of an SAP project, not actually running one. It also appears that he hasn't made him self popular with the senior managers. Having bee told what they wanted, he agreed that it was possible, and now he is in place, is insisting that they change the plans to roll them out over a longer period.

I will say though that I suspect in both cases, they should be able to achieve what they are planning to do, if not in the time frame set - they have previous experience, the right people in their teams and the right attitude from the senior managers. It appears that they have also spent a lot more time, effort and money in preparing their staff for the project. They both have excellent communications channels, and have done a much better job of engaging with their staff than we did (something I think that we could learn a lot from).

I have wished them both well and hope that I will be able to keep in touch. I think that it will be interesting to see how they get on.

People get ready (part 1)

When we first started work on our SAP project nearly 3 years ago, I made a point of searching the Internet for material that might be of help in making our project a success. One of the sites that I found was Jon Reed's (www.jonerp.com) where I found a link to the SAP Blue Book by Michael Doane and others. (Michael has very kindly linked to my blog so I'm returning the favor - http://searchlight.blogspot.com) I bought a copy and have to say that I found it very useful - although, I must admit that I've gone back to read it again and note that there are several points that make much more sense now that I've been involved in an SAP installation.

One of the items raised in the Blue Book concerned the idea of seeing how ready a business is to implement an ERP solution like SAP. It identified areas where senior management should ask questions, that could highlight points of conflict, potential pitfalls and those things that will stop a project from being successful.

Now I've been able to see a number of other businesses in the last few months that are in different stages of an SAP implementation (partly why I've not been writing much). Having done only the one SAP project, I'm not trying to suggest that I'm some kind of expert, but I can use what we have been through, plus the information from various sources (including the Blue Book) to indicate a couple of the key items that caused us issues and perhaps others as well.

In our case, we had a really good idea of what we needed from an ERP system - and for the most part, senior management had communicated that to the management team. Most of the staff also had a pretty good understanding of what we hoped for. I will say tho' that we might have done a better job of assessing some KPIs to measure against, and that would be useful to see how far we have come and to measure the benefits more accurately.

Since the beginning of the year, I've been talking to some people at a company that started work on their SAP implementation almost a full year and half before us. Not only have they not gone live, they have now dumped their consultants and are suing them - they have given up on SAP and are looking at other products. I wanted to try to see what had gone so badly wrong, and I have to say that I can see that they were never ready to take on this huge a project.

Whilst we had identified the key needs of the business and understood why we needed an ERP system, I can't say the same of this other company. In fact, it seemed that they were looking at an ERP system because they had been told it was needed by a consultant, but didn't really see why. Certainly, the senior management team had not discussed it with the rest of the managers and none of the staff.

Worse, when it came to the project itself, they thought that it was a case of "install the software, get the manuals, learn the system, make lots of money". They had no previous experience of a large implementatoin, and thought that it was only another "IT project". None of the senior managers wanted to get involved - no-one discussed business processes, and when the consultants were on site, no-one was really ever available to work with them. Lots of excuses - "we have to keep the business running" etc. I'm sure that if you are reading this blog, you will have heard similar stories.

The reality is that well over 2 years into the project, they still thought that the software would be changed to allow them to continue running their business processes the same way that they always had. I was suprised that the were still trying to get it working when I spoke to them - their IT staff told me that they had only ever got the development system running and although the consultants had talked about the test and production systems, their senior managment thought that this was a "waste of time" and wouldn't pay for the additional equipment.

I have to be honest, I was amazed - we are using all of the SAP system apart from HR, Quality Control and Asset Management and it was live in just over 2 years- they had barely got the Sales working and some of the Finance after almost 3 years. It seemed to me that no-one in their company had even the slightest interest in making the system work - astonishing when you think of how much they had paid.

Now I have been pretty dismissive of the quality of the consultants that we had working with us - one area in particular was the transfer of knowledge. I felt that they just didn't seem to want us to understand how things were done (partly I think because their company wants us to buy their support package). However, I have to say that what was happening at his other company seemed even worse. Talking to their IT people, they had only the most basic understanding of how the SAP system runs. They had paid for it to be hosted, and thought that meant they would not then be required to do any work - boy were they surprised when they found out just what was not being done, and what was still expected of them!

Having spent a couple of days on site at this other place, and having had the chance to talk things thru with their key people, I can see just how much more our project team achieved, and how things could have been so much worse for us. Considering all the things that I have written about in the past, it seems unbelievable that we could be considered a success story, but it certainly seems that way.

Same old, same old

I had actually planned a slightly different post, but with a few things happening at work, I've decided to update you on a couple of issues.

Some weeks back, we had the chance to get a consultant on site from another company. Boy - what a difference! This guy was not a native English speaker, but still managed to understand what we wanted and in the couple of weeks that he was with us, went thru the list of outstanding jobs and put a big dent in them. Several of these tasks have been hanging around for ages, and it has been really good to get them out of the way.

However from my point of view, the best thing was the last day that he was on site. He presented us with a document that detailed exactly what he had done - listing the specific items, a description of a revised process with the flow chart, screen shots as appropriate to show this and the details of some mods to a database table and a script as well. The document was close to 20 pages long and was quite superb. If ever we have an issue in future, there is no question that this document will guide us well.

Compare this to what we normally get from the normal consultants - zip, zero, ziltch. In several cases, they have done specific work and simply not told us about it. I had one particular case a couple of month ago when I received an email informing me that a specific piece of work had been done. I checked this - then I sent the guy a screen shot proving that he hadn't done what he said he had. He just ignored me and told our project leader that I should go ahead and process a change anyway. Best part of that was it didn't fix the problem - he then told the project manager that I hadn't done what was asked - our project manager sent a screen shot proving I had!

What really bites is that we are still using these people despite all of the issues we have experienced. I spoke to the Financial Director today and he is really pissed about this. His comment was that we are paying for these people to do shoddy work, then paying again for them to come back in to fix the mistakes that they make, and then paying a third time, because they didn't actually fix the issue at all. (Note that we are now 6 months past go-live, and there are STILL issues outstanding!)

He showed me the invoices from the consultancy for the last six months - and the total is astonishing. He has written to them several times to ask for proof of work done - they've claimed for people being on site when they haven't been any where near the place. Our total expenditure on the project has topped $3.25 million and is still climbing (and that doesn't include some travel costs, our own staff costs and some additional expenditure on hardware which has been written off against normal IT budget).

Now for some people, this will not sound like a particularly big expenditure, but for us it is getting really serious - our gross profit last year was just $480,000 on a revenue of $25 million. We simply can't afford to bleed money like this particularly in the current economic climate.

There is one other instance I want to write about that I've not mentioned previously. A while back we had a young lady consultant on site for a few days to cover a couple of items on FI/CO. She had not been with us before so wasn't completely up to speed with what had been completed. Apparently she had sent an email off to their project manager asking about something that was needed and was waiting a response from him.

She had then called to ask for me to to have a look at something with her - but when I arrived in the office that she was working in, she had gone to the ladies rest room. While I was waiting for her to return, a pop up appeared on her laptop with a response from her project manager. I don't normally make a habit of reading other people's email (which is why I haven't mentioned this before), but in this case I couldn't really avoid it.

Essentially the message said something along the lines of "Yeah, we've screwed up, that should have been done some time ago. Just BS them for a couple of hours, and we'll get someone to connect and make the necessary config change. They won't know any different". (Those are my words - the original were a little less polite). I was tempted to raise the issue, or report to our people, but decided not to - I've got to be honest tho', it really gets me mad when I think about it. (Particularly when they keep asking us to sign up with them for a support contract.)

I wanted to finish on a more positive note - yes, we do have those as well. About a month after we went live, we started to experience some issues with the system running very slowly. With the help of the SAP support portal and some training at an SAP center, I've identified a number of areas where they set the system up incorrectly. Changes were made to address these and as a result, over the last couple of months, we have had very few of these speed problems at all. In fact, many people have noted this.

Despite what many people might think, I can see that when the software runs well, it does in fact do what is needed (not necessarily what people want) and it can be very effective. Getting people to accept the changes is (certainly for us) a major task, but once they do get with the program, there are real benefits. We just have to try to make the most of these.