I've been tied up for the past week (guess why!) so I've not had the time to post - and next week isn't going to be much better.
When I last described the process, the project team had finally begun to start work on their own areas. They were working in one's or twos with a specific consultant that was suppose to be a particular expert in that module. We were fortunate that we had been able to allocate a number of rooms for the project - 2 decent sized meeting rooms at the main site, another at a second site, a smaller interview room at each site plus, the video conference suites. In addition, we had occasional use of smaller rooms in the particular areas for the project.
I had arranged with the site maintenance people to put in some extra electrical outlets and we bought some cheap video projectors which were semi-permananetly mounted in most of these rooms. This allowed the consultants to do what they did best - PowerPoint presentations. However, we got a lot more use out of the projectors later, so I won't complain too much.
The initial meetings did start to show some of the actual transactions within the software (think applications) and we began to start assigning the various transactions to user roles so that the project team could work out which of the staff needed what transaction to do their job. Now this sounds like quite a simple task, but unfortunately it isn't. In many cases, the project team didn't fully appreciate the amount of work that they would be involved in - I know that some of them thought it would be a matter of a few training sessions and then they would know all that they needed to know (boy were they shocked!).
In most cases, they found that they needed to allocate several days just to run though the process, refining it down to the various steps, then they would be told to use a specific transaction. Then they would start on this, only to find that they didn't understand the next step at various points for the different variations, so would have to go back to the consultant. Later, most of the project team were doing at least an hours work a day over many months.
Anyway, after about 3 months work, it was decided to start the process of training end users - remember that this was in preparation for the original go live date last year. It was assumed that the end users would need 1 or 2 training sessions (what is it that they say about "assume"? it makes an ass out of u & me) and about 5 -6 weeks were put aside to cover all end users. In fact, we found that most end users needed a good 6 - 8 sessions plus some extra time to work on things on their own. The meeting rooms with the video projectors really paid off at this point - the project team persons would act as the trainer with 4 - 5 people at a time and demonstrate what they had to do. Some older PCs had been installed in one room to allow the end users to practice what they had seen and we also got hold of some older laptops which proved a godsend for this purpose.
Now I have a simple criterion for measuring the quality of the training. A person should be able to do a given task twice in succession without making a mistake or needing to refer to any training material. When you reach that stage, you can say that the person is ready to start using the product. Now this doesn't mean that they won't make mistakes - far from it. However, it usually means that they can be productive.
Our consultant just couldn't seem to understand this view - they seemed to work on the basis that "I've shown you, so you are fully trained". I'm sorry but that has just got to be a completely dumb ass way of looking at it. We don't let people read a manual on driving and then let them lose in a $50,000 car on the freeway - or allow people that have used Microsoft Flight Simulator, fly a jumbo jet.
At this stage, I would say only about 25% of the end user staff are in a position where they are ready - I wouldn't yet say that they are confidant. Many of them did do some training, but that was months ago and they haven't touched it since. I suspect that they have forgotten most of what they learned and will have to go through it again. I have tried to encourage many of them to do work on their own - but without the cooperation of their section leaders, it probably won't happen.
The consultants insisted that the project team had to produce their own training material - I'd heard this before and I do kind of understand part of the reason behind it. But I still feel that they could provide better stuff that they do - it seems a huge waste of time to constantly re-invent the wheel. Some one out there must have come up with good stuff that could save us having to put so much work into just producing simple user guides.
We tried a couple of different ideas, but decided that our training material should be done as PowerPoint presentations; these were set-up, then modified during the training session to make them more accurate and relevant. They were then saved to a SharePoint Server so that they would be available to the end users for reference. If we could persuade the users to actually make use of the material, I might even say that it's a good idea. Hopefully, they will eventually realise that unlike SAP, I'm not going to charge them for downloading the material!
Enough for today - I'll try to post more when I get time.
Saturday, 21 February 2009
Tuesday, 17 February 2009
Lock and load
There is one thing about SAP that I do like - the data migration workbench. This allows you to load data from older systems. In the past, many other systems that I have worked with only allowed data to be loaded using SQL script - most just don't provide any support for this at all.
The actual process sounds a bit complex - well it's not that simple, but once you have done it a few times, it doesn't seem too bad. I would suggest that for most people, the hardest part is getting a project structure to manage it in place. Certainly, we started using a structure suggested by the consultants, but quickly found that it didn't meet our needs. Primarily because of the need to get the data loaded in the correct sequence, but also because we found some of the data was insufficiently prepared. We also found that they badly underestimated how it long it would take, I think mostly because they just didn't understand how much data we needed to move, even though we had actually explained this to them on several occasions.
Essentially, the data is extracted from the legacy systems in the form of flat text or comma separated files - these are then opened up in a spreadsheet. The records can be tidied up and the record attributes are placed in the colum headers (color, material number, weight, customer name, whatever). The data is then saved as a flat text file with the headers, and then the workbench allows this data to be processed record by record. Think of it in terms of a vb script, SQL script or even a simple Macro.
The problem of course is that the data has to be absolutely correct - if it isn't, the process will fail. This could be caused by the wrong data in a field, the wrong header or just simple mismatches. There is a process to re-run the failed import, but it still requires the data to be correct.
In many ways, this was the hardest part - people simply don't understand that a computer will only do what it is told. In many cases, they don't even see the error - many studies have been done that prove people often see what they want to see rather than what is in front of them. Several of the files had to be re-done, not just once, but several times. As a result, the load process for just one system, took well over 6 months, where we were told it would take a couple of months at the most.
However, once the structure is set up and proven, the good thing is that it can also be used on the other systems. This saves quite a bit of time, as it means you don't have to keep re-designing the process.
One thing we did find, was that it is better done by one person - we tried with a couple of us working on items in parallel. It just caused too many problems, and it was decided that it was wasting time. Since it was given to just one person, many of the problems we had had have faded. It also allowed a much more managed approach - as a result, the second half of the process became a lot easier.
Well enough for tonight - early start tomorrow.
The actual process sounds a bit complex - well it's not that simple, but once you have done it a few times, it doesn't seem too bad. I would suggest that for most people, the hardest part is getting a project structure to manage it in place. Certainly, we started using a structure suggested by the consultants, but quickly found that it didn't meet our needs. Primarily because of the need to get the data loaded in the correct sequence, but also because we found some of the data was insufficiently prepared. We also found that they badly underestimated how it long it would take, I think mostly because they just didn't understand how much data we needed to move, even though we had actually explained this to them on several occasions.
Essentially, the data is extracted from the legacy systems in the form of flat text or comma separated files - these are then opened up in a spreadsheet. The records can be tidied up and the record attributes are placed in the colum headers (color, material number, weight, customer name, whatever). The data is then saved as a flat text file with the headers, and then the workbench allows this data to be processed record by record. Think of it in terms of a vb script, SQL script or even a simple Macro.
The problem of course is that the data has to be absolutely correct - if it isn't, the process will fail. This could be caused by the wrong data in a field, the wrong header or just simple mismatches. There is a process to re-run the failed import, but it still requires the data to be correct.
In many ways, this was the hardest part - people simply don't understand that a computer will only do what it is told. In many cases, they don't even see the error - many studies have been done that prove people often see what they want to see rather than what is in front of them. Several of the files had to be re-done, not just once, but several times. As a result, the load process for just one system, took well over 6 months, where we were told it would take a couple of months at the most.
However, once the structure is set up and proven, the good thing is that it can also be used on the other systems. This saves quite a bit of time, as it means you don't have to keep re-designing the process.
One thing we did find, was that it is better done by one person - we tried with a couple of us working on items in parallel. It just caused too many problems, and it was decided that it was wasting time. Since it was given to just one person, many of the problems we had had have faded. It also allowed a much more managed approach - as a result, the second half of the process became a lot easier.
Well enough for tonight - early start tomorrow.
Friday, 13 February 2009
Slowly, slowly...
We had been working on the SAP project for 6 months; we had completed the "blueprint" phase and had more or less agreed with the consultants' description of our business processes. The development system was in place and working ready for us to use. We had set-up a special training room with a number of PCs, a video projector, a whiteboard and some other essential materials to help get people up to speed. The project team were straining at the leash - they wanted to get on and start to learn how it all works.
Now if you've read any of the rest of the blog, you'll know that I've not been too impressed by the consultants that we had on the project or their methods. However, I will say that at this point, we did start to feel that perhaps we had turned a corner.
Their project manager had spent some time with me discussing user accounts and user roles - from my point of view, a really important topic. The company wanted to make sure that all staff can do the job that they need to do, but we also wanted to make sure that no-one has more access than they need. I had set-up accounts for the project team, and created some basic user roles based for the most part on the primary jobs in the business. The sapgui software was installed on the PCs that would be used - just the training ones to begin with, but the whole estate was done within 3 weeks.
The individual consultants were allocated areas of responsibility and they then started to discuss these areas with the different project team members. The meetings focussed on showing people the software in operation, and how to do certain tasks within each of these areas. The project team members were asked to create training material that they would then use to train those staff under their jurisdiction. Some templates using different methods were created and it was eventually decided that everyone would use the PowerPoint presentation templates - we also set-up an area on the SharePoint server for people to store these for reference.
Within a few days, the project team were starting to sound quite positive - they were now able to logon and experiment in their own time at their own speed. Some of them had started to enter data and were able to now ask questions of the consultants on the processes and get a response that they were beginning to be able to understand in terms of how the software worked.
Over the next few weeks, these sessions continued. There were some frustrations - the data that was being input was mostly incomplete and many of the processes in the software couldn't be completed because of this. Several times, people would start work, find they couldn't continue because of missing data, wait for it to be added then start again, only to find that something else was missing. In a lot of cases, there were configuration problems; either not done or incorrect.
Despite this, some good progress was made. A lot of the team members were finding that they were missing authorisation to do various jobs - they would report this and I would quickly add the required items. I will say that the actual process for this is quite long winded, although once you are used to it, it can be done reasonably easily. There was some confusion among the team members - they are not used to the discipline required to report the problems accurately, and on several occasions, I had to go back to them to remind them that the process had to be followed as had been explained.
The sales staff hit a few issues - they have their own way of working and were not particularly open to changing this and they didn't like the CRM system. But the production staff were up and running very quickly, and shortly after that, the purchasing, inventory and shipping people were starting to feel confident. The finance people didn't get their training at this stage - they had been given some training material, but the consultant spent a lot of time just making configuration changes, so they didn't get too much exposure to the system at this time.
But overall, it was felt that we were making good progress - individual areas of the business were starting to see some real progress and this was generating some very positive attitudes. As a result, although the go-live date was rather ambitious, people did feel that it was achievable.
A couple of initial training sessions for end users were scheduled - these were to be run by the project team, not the consultants which is the SAP way of doing things. The first sessions were run and they did run into some difficulties - lessons were learnt, a few changes were made and the sessions were re-run. Some of the training material was found to be a bit unsatisfactory and these were then modified appropriately.
We also started the data preparation ready for loading. I will write more on this later, but at this stage, it was mostly about understanding the process, and the IT staff quickly became fairly comfortable using it.
So there we were - finally out of the starting blocks, and flying down the track. Yes it had taken us a while to get to this point, but were finally moving towards the finish - what could go wrong?
Well later parts of this blog might answer that.
Now if you've read any of the rest of the blog, you'll know that I've not been too impressed by the consultants that we had on the project or their methods. However, I will say that at this point, we did start to feel that perhaps we had turned a corner.
Their project manager had spent some time with me discussing user accounts and user roles - from my point of view, a really important topic. The company wanted to make sure that all staff can do the job that they need to do, but we also wanted to make sure that no-one has more access than they need. I had set-up accounts for the project team, and created some basic user roles based for the most part on the primary jobs in the business. The sapgui software was installed on the PCs that would be used - just the training ones to begin with, but the whole estate was done within 3 weeks.
The individual consultants were allocated areas of responsibility and they then started to discuss these areas with the different project team members. The meetings focussed on showing people the software in operation, and how to do certain tasks within each of these areas. The project team members were asked to create training material that they would then use to train those staff under their jurisdiction. Some templates using different methods were created and it was eventually decided that everyone would use the PowerPoint presentation templates - we also set-up an area on the SharePoint server for people to store these for reference.
Within a few days, the project team were starting to sound quite positive - they were now able to logon and experiment in their own time at their own speed. Some of them had started to enter data and were able to now ask questions of the consultants on the processes and get a response that they were beginning to be able to understand in terms of how the software worked.
Over the next few weeks, these sessions continued. There were some frustrations - the data that was being input was mostly incomplete and many of the processes in the software couldn't be completed because of this. Several times, people would start work, find they couldn't continue because of missing data, wait for it to be added then start again, only to find that something else was missing. In a lot of cases, there were configuration problems; either not done or incorrect.
Despite this, some good progress was made. A lot of the team members were finding that they were missing authorisation to do various jobs - they would report this and I would quickly add the required items. I will say that the actual process for this is quite long winded, although once you are used to it, it can be done reasonably easily. There was some confusion among the team members - they are not used to the discipline required to report the problems accurately, and on several occasions, I had to go back to them to remind them that the process had to be followed as had been explained.
The sales staff hit a few issues - they have their own way of working and were not particularly open to changing this and they didn't like the CRM system. But the production staff were up and running very quickly, and shortly after that, the purchasing, inventory and shipping people were starting to feel confident. The finance people didn't get their training at this stage - they had been given some training material, but the consultant spent a lot of time just making configuration changes, so they didn't get too much exposure to the system at this time.
But overall, it was felt that we were making good progress - individual areas of the business were starting to see some real progress and this was generating some very positive attitudes. As a result, although the go-live date was rather ambitious, people did feel that it was achievable.
A couple of initial training sessions for end users were scheduled - these were to be run by the project team, not the consultants which is the SAP way of doing things. The first sessions were run and they did run into some difficulties - lessons were learnt, a few changes were made and the sessions were re-run. Some of the training material was found to be a bit unsatisfactory and these were then modified appropriately.
We also started the data preparation ready for loading. I will write more on this later, but at this stage, it was mostly about understanding the process, and the IT staff quickly became fairly comfortable using it.
So there we were - finally out of the starting blocks, and flying down the track. Yes it had taken us a while to get to this point, but were finally moving towards the finish - what could go wrong?
Well later parts of this blog might answer that.
Thursday, 12 February 2009
Hardware hassles
I'm going to go back to the start of the project to highlight some of the issues with the hardware and installation of the software.
I had asked that we get details on how to do the installation, but the consultants director had insisted that installations could only be done by a qualified "basis" consultant. Arrangements had been made to begin the installation almost at the same time as we were conducting the launch meetings.
We were told that they would arrange for one of these "basis" people to be on site, but at the last minute, I was told the person concerned would do the work over a remote connection. Not a problem as we have used remote connections ourselves for many tasks. However, there was a problem as he needed the CDs and DVDs swapping; that's one job you can't do remotely. To make life easier, I copied all of the required disks to a network location so he could get on with job without needing us to keep swapping disks.
The thing that did surprise me was that he seemd to take a long time to complete the job - there were a number of disks involved, but after some 10 days, the system was still not working. In fact, it was actually almost 6 weeks before all of the installation was finally done so that it could be used - and that was just the one system.
Now if you have not worked with SAP, I should highlight that standard practice is to have 3 systems - Development, Test and Production. The idea is that you start with work on the development system, validate it on the test system before moving it to the production system. (This has some merits, although it does make it a tad long winded to do anything.) Much of the configuration work is supposed to be done on the development system to begin with, then it is "transported" between the systems. In theory at least, the 3 systems will all be identical; as you are moving changes between systems, they should be synchronised.
Having had the first system installed, it was several months before they started on the second one - and that was started by a different person to the first one. He only got about half way, before he was replaced by a second person. In turn, this person was replaced by yet another for the third system - which was only finally finished off by another. Subsequently, we have had another 2 people involved to do certain changes.
Now, I expected that these people would all work to set up the systems in the same way - I quickly found that was not the case. Each of the 3 systems was set-up differently and we are still finding variations which cause the occasional problem. A few times I have had to report issues to the SAP service market place (their support system) and their support staff have expressed some questions about why certain things are the way that they are. The answer I was given is that there is no "standard" way to set-up these systems - I find this a little bit odd, but I suppose it is not too different to the way that Windows can vary on different PCs or servers. However, in our case the 3 servers are all identical hardware so I would expect them to be set-up identically. Clearly, this is not the case.
Another issue I had was with the training - or lack of it to be more precise. We were given a massive printout and a 2 day session with a guy who was from part of Eastern Europe, who did speak English, but wasn't completely comfortable with it. Most of the 2 days involved him reading from the pages of the printout; we had no access to a working system, and no chance to test any of the work. Since then, we have had the chance to test some of what we were given, and we found much of the text was incorrect.
We have moved on since then - but it has been a major stumbling block. We are still learning new things every day and often purely by trial and error and I have to say, it is a major source of frustration. My team are willing to learn new things, but it does seem to be a very haphazard process. I got an email from someone a while ago and he suggested that we have at least another 2 years work ahead of us, possibly more in order to reach a good level of competence.
Oh well, tomorrow is another day.
I had asked that we get details on how to do the installation, but the consultants director had insisted that installations could only be done by a qualified "basis" consultant. Arrangements had been made to begin the installation almost at the same time as we were conducting the launch meetings.
We were told that they would arrange for one of these "basis" people to be on site, but at the last minute, I was told the person concerned would do the work over a remote connection. Not a problem as we have used remote connections ourselves for many tasks. However, there was a problem as he needed the CDs and DVDs swapping; that's one job you can't do remotely. To make life easier, I copied all of the required disks to a network location so he could get on with job without needing us to keep swapping disks.
The thing that did surprise me was that he seemd to take a long time to complete the job - there were a number of disks involved, but after some 10 days, the system was still not working. In fact, it was actually almost 6 weeks before all of the installation was finally done so that it could be used - and that was just the one system.
Now if you have not worked with SAP, I should highlight that standard practice is to have 3 systems - Development, Test and Production. The idea is that you start with work on the development system, validate it on the test system before moving it to the production system. (This has some merits, although it does make it a tad long winded to do anything.) Much of the configuration work is supposed to be done on the development system to begin with, then it is "transported" between the systems. In theory at least, the 3 systems will all be identical; as you are moving changes between systems, they should be synchronised.
Having had the first system installed, it was several months before they started on the second one - and that was started by a different person to the first one. He only got about half way, before he was replaced by a second person. In turn, this person was replaced by yet another for the third system - which was only finally finished off by another. Subsequently, we have had another 2 people involved to do certain changes.
Now, I expected that these people would all work to set up the systems in the same way - I quickly found that was not the case. Each of the 3 systems was set-up differently and we are still finding variations which cause the occasional problem. A few times I have had to report issues to the SAP service market place (their support system) and their support staff have expressed some questions about why certain things are the way that they are. The answer I was given is that there is no "standard" way to set-up these systems - I find this a little bit odd, but I suppose it is not too different to the way that Windows can vary on different PCs or servers. However, in our case the 3 servers are all identical hardware so I would expect them to be set-up identically. Clearly, this is not the case.
Another issue I had was with the training - or lack of it to be more precise. We were given a massive printout and a 2 day session with a guy who was from part of Eastern Europe, who did speak English, but wasn't completely comfortable with it. Most of the 2 days involved him reading from the pages of the printout; we had no access to a working system, and no chance to test any of the work. Since then, we have had the chance to test some of what we were given, and we found much of the text was incorrect.
We have moved on since then - but it has been a major stumbling block. We are still learning new things every day and often purely by trial and error and I have to say, it is a major source of frustration. My team are willing to learn new things, but it does seem to be a very haphazard process. I got an email from someone a while ago and he suggested that we have at least another 2 years work ahead of us, possibly more in order to reach a good level of competence.
Oh well, tomorrow is another day.
Tuesday, 10 February 2009
Mea culpa
So far I've been pretty harsh about the consultants - however, I am prepared to say that we didn't get everything right first time.
When the project started, I and a couple of colleagues made a number of suggestions about the best way to proceed. The consultants disagreed with us, and suggested that as they had done this many times, it would be better to follow their lead. That was a definite mistake as it took the ownership away from us - we are definitely dancing to their tune.
I also wanted to start work on the data migration a lot earlier, and there is no question that this would have been much better for us as the process took far longer than the consultants thought it would - about 4 times longer in fact. In addition, the work was supposed to be done by the various team leaders - the assumption was made that they understood what was required but after a month or so, it was clear that many of them didn't. This lead to several delays as we had to go back over various areas more than once. It didn't help that some of the consultants gave slightly misleading information - but our people should have been able to pick that up a lot quicker.
Another issue was to do with the personnel - our guys (and girls) are really quite well motivated, but in some areas, they don't perhaps understand the internal processes as well as they should. I suggested that we should involve a few more staff, but that idea was rejected. It's now become obvious that we need those other people involved - and if that had started a while back, it would certainly have helped us identify some of the more serious issues a lot sooner.
In particular, one specific process area was assigned to one person - it's a major project area and I felt that altho' the guy concerned knows what he is doing, it's gotten just too much for him on his own. That has now become painfully obvious - so we have a number of other people that are being tasked to assist him, but it would definitely have been better if this help had been available much sooner.
From my point of view, the worst thing has been that many of us are effectively doing two jobs - our normal daily work and the implementation project. It becomes very difficult to balance the two areas and the pressure is high for everyone. Several of us are in desperate need of a break - I've had no vacation now for 2 years, other than a couple of days at a time and yes, I know that it's beginning to show as I find myself getting uptight over silly things. One of the other managers came in today; he's just had the results of a medical test and his cholesterol level is way up, an increase of over 80% - his physician told him he has to take immediate action to bring it down.
Each area of the business was responsible for their own data and training preparation - however, 2 areas are really behind everyone else. The finance staff are really struggling to get to grips with some of the new methods, and the project system still doesn't work sufficiently to be able to carry out any real testing. Partly due to lack of resources, partly due to motivation - the training was also inadequate. But they didn't do anything about it, and they didn't highlight the problems soon enough.
That leads me on to the worst aspect. Each area has carried out it's own individual tests, with varying results. Once we started end to end testing, everything started to fall on it's ass. I think in the last 2 months, we actually only had 2 end to end tests that went thru OK, and even those only did so because part of the work was fudged (manually forcing thru something that was supposed to happen automatically). We have more planned, but there is the unspoken suggestion that perhaps we don't need to do all the testing. From everything that I have been told, this is a common error; testing is so important and to miss it out is courting disaster.
Just to make matters worse, we started the end user training 7-8 months ago. Many of the staff that were involved in this have forgotten what they learned - we will have to do it all over again. I've suggested that we tie the two together and get the staff involved in the end to end testing and do the additional training at the same time. To my surprise, this was accepted and it starts next week - I think some of the managers are in for a shock when they see how little the staff remember. There does seem to be a bit of an attitude that they know what they are doing so everyone else does - clearly, that's not the case.
Oh well - onward and upward.
When the project started, I and a couple of colleagues made a number of suggestions about the best way to proceed. The consultants disagreed with us, and suggested that as they had done this many times, it would be better to follow their lead. That was a definite mistake as it took the ownership away from us - we are definitely dancing to their tune.
I also wanted to start work on the data migration a lot earlier, and there is no question that this would have been much better for us as the process took far longer than the consultants thought it would - about 4 times longer in fact. In addition, the work was supposed to be done by the various team leaders - the assumption was made that they understood what was required but after a month or so, it was clear that many of them didn't. This lead to several delays as we had to go back over various areas more than once. It didn't help that some of the consultants gave slightly misleading information - but our people should have been able to pick that up a lot quicker.
Another issue was to do with the personnel - our guys (and girls) are really quite well motivated, but in some areas, they don't perhaps understand the internal processes as well as they should. I suggested that we should involve a few more staff, but that idea was rejected. It's now become obvious that we need those other people involved - and if that had started a while back, it would certainly have helped us identify some of the more serious issues a lot sooner.
In particular, one specific process area was assigned to one person - it's a major project area and I felt that altho' the guy concerned knows what he is doing, it's gotten just too much for him on his own. That has now become painfully obvious - so we have a number of other people that are being tasked to assist him, but it would definitely have been better if this help had been available much sooner.
From my point of view, the worst thing has been that many of us are effectively doing two jobs - our normal daily work and the implementation project. It becomes very difficult to balance the two areas and the pressure is high for everyone. Several of us are in desperate need of a break - I've had no vacation now for 2 years, other than a couple of days at a time and yes, I know that it's beginning to show as I find myself getting uptight over silly things. One of the other managers came in today; he's just had the results of a medical test and his cholesterol level is way up, an increase of over 80% - his physician told him he has to take immediate action to bring it down.
Each area of the business was responsible for their own data and training preparation - however, 2 areas are really behind everyone else. The finance staff are really struggling to get to grips with some of the new methods, and the project system still doesn't work sufficiently to be able to carry out any real testing. Partly due to lack of resources, partly due to motivation - the training was also inadequate. But they didn't do anything about it, and they didn't highlight the problems soon enough.
That leads me on to the worst aspect. Each area has carried out it's own individual tests, with varying results. Once we started end to end testing, everything started to fall on it's ass. I think in the last 2 months, we actually only had 2 end to end tests that went thru OK, and even those only did so because part of the work was fudged (manually forcing thru something that was supposed to happen automatically). We have more planned, but there is the unspoken suggestion that perhaps we don't need to do all the testing. From everything that I have been told, this is a common error; testing is so important and to miss it out is courting disaster.
Just to make matters worse, we started the end user training 7-8 months ago. Many of the staff that were involved in this have forgotten what they learned - we will have to do it all over again. I've suggested that we tie the two together and get the staff involved in the end to end testing and do the additional training at the same time. To my surprise, this was accepted and it starts next week - I think some of the managers are in for a shock when they see how little the staff remember. There does seem to be a bit of an attitude that they know what they are doing so everyone else does - clearly, that's not the case.
Oh well - onward and upward.
Monday, 9 February 2009
Set your phases to stun
So there we were - the blueprint phase was complete and the blueprint document was finished up, the verification phase was more or less complete and we had actually signed off on the document (altho' there were a few items that we queried). We then started on the work with the consultants to go thru in a bit more depth on the various processes.
Now, when we first started the project, the idea was to get the whole company involved and we would all go live at the same time. The director from the consultant firm suggested that it might be better to do it in stages, based upon geographical location. Now I don't actually have a problem with that - it makes sense to reduce workload to a manageable level and if we get problems, in theory at least, it still leaves part of the company able to carry on whilst we sort out the issues.
So therefore we had a "phase 1" for us and a "phase 2" for all other sites thruout the company. But then within a few weeks, the consultants started indicating that they thought we would also do the go live for the sites in this state in more than one go - possibly in 2 more phases. It was pointed out right away that this was not practical - we need the input from one of our other sites in order to get the production rolling at this site. Without their input, we would have to do their data entry manually - and we would need about 12-15 staff extra just to do that.
A few weeks after that, they then started to insist that certain things were not part of the initial plan and would require yet more phases. Several times, we went back to the blueprint document to show that yes, we had actually specified something and that they had actually included it in their document. But this didn't seem to worry them - it seemed that if they didn't know about a particular area or process, the immediate reaction was to suggest that it would be dealt with in a later "phase".
About 7 or 8 months into the project, I raised a question about the output documents - invoices, etc. Their PM sat in with our director and told him that it was not part of phase 1 or phase 2 (and I was in the meeting - boy, it got just a bit heated!). You can imagine the reaction from all of our people. I did actually check afterwards and this guy really did think that we would be able to go live without being able to print off any documentation of any kind. I'd point out that right back at the beginning, we had supplied them with a number of pages of the types and functions of the various documents that we would need - they pretty much covered all of the processes, from sales thru to shipping. I had also provided samples of the actual documents, to give them a good idea of what was needed. But no - has far as he was concerned, documents were part of a "later phase".
So here we are - yes we now have a phase 2 and a phase 3 for our sites in other countries (as I said, this makes sense). But they insist that part of what we needed and what was specified at the very start and in their own paperwork will actually be done later. I actually received an email a while back that indicated they expect to be providing us with consultants for at least the next 2-3 years, and that doesn't include the work for the other sites overseas. One comment indicated that they seem to expect to be working with us for at least 5 years more.
I've received some emails from other people that are, or have been involved in SAP implementations; also 2 Oracle implementations. It does seem to me that there is a pattern developing. Most of those people in IT depts that I have spoken to are clearly well respected, with good experience of various projects, but all of them report similar situations in their project. I may be unlucky, but I have yet to hear from anyone that has not experienced some thing along the lines that we have seen.
But perhaps that's just me?
Now, when we first started the project, the idea was to get the whole company involved and we would all go live at the same time. The director from the consultant firm suggested that it might be better to do it in stages, based upon geographical location. Now I don't actually have a problem with that - it makes sense to reduce workload to a manageable level and if we get problems, in theory at least, it still leaves part of the company able to carry on whilst we sort out the issues.
So therefore we had a "phase 1" for us and a "phase 2" for all other sites thruout the company. But then within a few weeks, the consultants started indicating that they thought we would also do the go live for the sites in this state in more than one go - possibly in 2 more phases. It was pointed out right away that this was not practical - we need the input from one of our other sites in order to get the production rolling at this site. Without their input, we would have to do their data entry manually - and we would need about 12-15 staff extra just to do that.
A few weeks after that, they then started to insist that certain things were not part of the initial plan and would require yet more phases. Several times, we went back to the blueprint document to show that yes, we had actually specified something and that they had actually included it in their document. But this didn't seem to worry them - it seemed that if they didn't know about a particular area or process, the immediate reaction was to suggest that it would be dealt with in a later "phase".
About 7 or 8 months into the project, I raised a question about the output documents - invoices, etc. Their PM sat in with our director and told him that it was not part of phase 1 or phase 2 (and I was in the meeting - boy, it got just a bit heated!). You can imagine the reaction from all of our people. I did actually check afterwards and this guy really did think that we would be able to go live without being able to print off any documentation of any kind. I'd point out that right back at the beginning, we had supplied them with a number of pages of the types and functions of the various documents that we would need - they pretty much covered all of the processes, from sales thru to shipping. I had also provided samples of the actual documents, to give them a good idea of what was needed. But no - has far as he was concerned, documents were part of a "later phase".
So here we are - yes we now have a phase 2 and a phase 3 for our sites in other countries (as I said, this makes sense). But they insist that part of what we needed and what was specified at the very start and in their own paperwork will actually be done later. I actually received an email a while back that indicated they expect to be providing us with consultants for at least the next 2-3 years, and that doesn't include the work for the other sites overseas. One comment indicated that they seem to expect to be working with us for at least 5 years more.
I've received some emails from other people that are, or have been involved in SAP implementations; also 2 Oracle implementations. It does seem to me that there is a pattern developing. Most of those people in IT depts that I have spoken to are clearly well respected, with good experience of various projects, but all of them report similar situations in their project. I may be unlucky, but I have yet to hear from anyone that has not experienced some thing along the lines that we have seen.
But perhaps that's just me?
Saturday, 7 February 2009
SAPping me slowly..
Let's go back a couple of years - we had had the initial launch meetings, and tried to get people fired up for this new project. There was then a long period of about 3 months that was their "blueprint" phase. As I said before, this was supposed to analyse our processes and then allow them to identify what we needed to do to replicate them within SAP.
Of course they also said that they would get us to ask the question "is this really the best way to do XYZ?" Now I have no problem with this - there is no question, the purpose of this project is to make us more efficient and so save / make more money making everyones job more secure. The inference is that they will offer a better way to do the various processes.
The "blueprint" phase involved a lot of meetings - a whole heap in fact. What generally happened was they would identify a specific area (as defined within SAP) and then do a line drawing with action boxes for the tasks in that process. I've undertaken a similar process in the past myself - it's known as "critical path analysis" and I tend to use "finite state machine" drawings to describe the process. If it is done properly, it allows anyone to follow the plan and to successfully complete a process, even if they don't know it or understand it.
However, I didn't consider the plans put up by the consultants to be particularly good. I felt that they left out key sections and the way that they handled the process variants was not especially clever - there was room for misunderstandings. However, I accept that different folks have different ways of doing things - I don't believe for one minute that my way is the only way.
At the end of the "blueprint phase", we were supposed to sit down without the consultants, take the revised plans that they supplied, go through them and confirm that these, more or less accurately described the different processes as we wanted. We would then sign these off, and they would then configure the system to meet our needs.
There were a few problems at that point - the consultants wanted us to complete the "verification phase" in a little over 2 weeks. In fact, it took almost a week just to plow thru the sales part on its own. After 6 weeks, we had raised a lengthy list of queries regarding the various stages of the processes we covered, but still signed off on their plans even though we hadn't covered all of them. I was really concerned that there was almost nothing in the plan about aspects of the finances and administration.
In some cases, they had actually made quite fundamental errors. I wasn't too surprised at this as from brief conversations, it was obvious that most of their people had worked in totally different environments to ours. However, this did leave a bad feeling and I know that I wasn't the only one - although at that stage, I was probably the only one to actually say anything.
What did bother me was that having spent all of that time and effort, they then almost never referred back to the plans again. I'm not sure if they have even kept copies (I have). A couple of months ago, there was a question about something not being done and the consultant was adamant that this had never been discussed. I then produced a copy of his company's document showing the line drawing with the specific item as step 4 - one very red faced guy.
I will say that I think that part of the process was more for them than it was for us - but I don't see what they actually got from it. Certainly, most of their staff don't know what's in the plans. Subsequently, some of their people have made really serious errors in the way that they have configured the systems, and it is obvious that they have not referred to any document produced by us.
OK - I've indicated that I hate to waste money. 18 weeks at an average of 4 days per week, 2 consultants per day = 144 man days. At $1400 per day.... well you can see that it is a ton of money. That of course doesn't allow for our people there, sometimes between 5 and 10 staff. So you'd think that this would be pretty important, but I'm not sure that they see it that way. It's almost as if this is the process of implementation that they have been told they have to do, and they follow it to the letter. But I still say that it hasn't achieved what it was supposed to and that inevitably makes the success of the project less likely.
OK enough for now - stay safe out there people. The weather is turning bad and it's time to hunker down and ride it out.
Of course they also said that they would get us to ask the question "is this really the best way to do XYZ?" Now I have no problem with this - there is no question, the purpose of this project is to make us more efficient and so save / make more money making everyones job more secure. The inference is that they will offer a better way to do the various processes.
The "blueprint" phase involved a lot of meetings - a whole heap in fact. What generally happened was they would identify a specific area (as defined within SAP) and then do a line drawing with action boxes for the tasks in that process. I've undertaken a similar process in the past myself - it's known as "critical path analysis" and I tend to use "finite state machine" drawings to describe the process. If it is done properly, it allows anyone to follow the plan and to successfully complete a process, even if they don't know it or understand it.
However, I didn't consider the plans put up by the consultants to be particularly good. I felt that they left out key sections and the way that they handled the process variants was not especially clever - there was room for misunderstandings. However, I accept that different folks have different ways of doing things - I don't believe for one minute that my way is the only way.
At the end of the "blueprint phase", we were supposed to sit down without the consultants, take the revised plans that they supplied, go through them and confirm that these, more or less accurately described the different processes as we wanted. We would then sign these off, and they would then configure the system to meet our needs.
There were a few problems at that point - the consultants wanted us to complete the "verification phase" in a little over 2 weeks. In fact, it took almost a week just to plow thru the sales part on its own. After 6 weeks, we had raised a lengthy list of queries regarding the various stages of the processes we covered, but still signed off on their plans even though we hadn't covered all of them. I was really concerned that there was almost nothing in the plan about aspects of the finances and administration.
In some cases, they had actually made quite fundamental errors. I wasn't too surprised at this as from brief conversations, it was obvious that most of their people had worked in totally different environments to ours. However, this did leave a bad feeling and I know that I wasn't the only one - although at that stage, I was probably the only one to actually say anything.
What did bother me was that having spent all of that time and effort, they then almost never referred back to the plans again. I'm not sure if they have even kept copies (I have). A couple of months ago, there was a question about something not being done and the consultant was adamant that this had never been discussed. I then produced a copy of his company's document showing the line drawing with the specific item as step 4 - one very red faced guy.
I will say that I think that part of the process was more for them than it was for us - but I don't see what they actually got from it. Certainly, most of their staff don't know what's in the plans. Subsequently, some of their people have made really serious errors in the way that they have configured the systems, and it is obvious that they have not referred to any document produced by us.
OK - I've indicated that I hate to waste money. 18 weeks at an average of 4 days per week, 2 consultants per day = 144 man days. At $1400 per day.... well you can see that it is a ton of money. That of course doesn't allow for our people there, sometimes between 5 and 10 staff. So you'd think that this would be pretty important, but I'm not sure that they see it that way. It's almost as if this is the process of implementation that they have been told they have to do, and they follow it to the letter. But I still say that it hasn't achieved what it was supposed to and that inevitably makes the success of the project less likely.
OK enough for now - stay safe out there people. The weather is turning bad and it's time to hunker down and ride it out.
The cost of doing business
I've been busy the past week - out of the country at a remote site. This is the first chance I've had to add anything more.
The company has several sites, some are quite distant, a couple outside of the country. When I first joined, I was astonished at the amount of travelling that was going on. No-one has ever kept specific details, but I did a (very rough) calculation that among the staff at my site, they were spending an average per month of about 75 -100 days travelling. Some of this was by car, some by plane - very occasionally by train. (This does not include those staff whose job is specifically travelling - sales, trucking etc.)
It's difficult to get any kind of accurate figure, but for travel, hotel & hospitality alone, we were probably spending around a quarter of million dollars for my site alone (which is one of the bigger ones). It seems likely that the company was spending a little over $1 million a year. At the time, gas prices were still stable, but everyone knows what happened there. I dread to think what our costs would have been. This also created issues with staff time wasted.
So one of the first things that I did was to set-up a process of remote access working - this allowed those that were travelling to be able to get on with some work whilst waiting around airport terminals or in hotels. This went down well with almost everyone - productivity went up after an initial period of getting used to it, and now it is seen as absolutely essential. We did have a slight issue a few months ago with some people unable to get access (one of the guys making some modifications and blocked access for about an hour) and the reaction to this showed just how used to it everyone has become.
The next step was to introduce video conferencing -I've worked with it before and know just how good it can be. There were of course a few initial teething troubles (people will play about with the settings) but now it works almost seamlessly. I think that there is at least one VC between sites per day and it is now seen as just another tool. Almost all of the staff have had the opportunity to take part in a VC session. The cost saving to the company cannot be overestimated. The equipment cost around $7,000 per site and we saved that much per month in the first year alone, probably twice that now.
So where does this link to SAP - quite simply, the cost of installation has been enormous and without the VC facility, it would have been a whole lot more. At the initial launch meetings, I estimated that the cost of the 4 meetings were around $35,000. After that, almost all other meetings were conducted over the VC - at one stage, 4 a week and they generally lasted all day.
We still had to have some travelling - there was no getting away from that. However, we have kept some figures that make me feel that I can justifiably say we saved $300,000 last year. Of course, this had never been factored into the calculations for the project which really only ever showed the cost of the software and the consultants. We've had to provide them with office facilities, and at the beginning they were expecting us to provide them with lunch etc. (That soon stopped!)
Now I may sound like I'm being a bit hard-assed about this - and I probably am. Before starting to work in IT, I had a long background in other areas of management; and one thing that I know is that as a manager, I have 3 main areas of responsibility. "To increase sales, to cut costs and to improve margins". This applies to all managers, whatever their title and whatever sector they work in.
The reason for buying SAP is quite simple; we need to improve the way that we do business to make us able to supply our customers with a better and more cost effective product. It should allow the flow of information between all areas of the business that will allow this to happen and make it easier to getter better business decisions. This should also allow us to cut production costs, and lead times.
However, there is a very fine balancing act here. I think it likely that SAP will provide some of those savings and increase our ability to streamline the process from order thru production to sale. However, the cost of implementng it is very high - we have to factor that into our production costs. Essentially, will there be an ROI? I have my doubts - current sales in this country of around $30 million, for the group $75 million. With the current economic conditions, this could contract further - we are still OK at the moment, but are already having to make plans to lay off some staff.
I did some numbers with the FD before Christmas; we would normally expect any project to have a payback of 3-5 years tops. Of course in some cases, it is actually better to set costs off over a longer period, such as for capital plant, but they would still want to see a payback in under 5. For SAP, we cannot see a payback in that period - our estimates make it closer to 12-15 years. That of course assumes that we stay with it that long and that prices only increase by an amount anticipated.
Ultimately, with all the additional costs, is it likely that we would ever see a return? I can't say for certain, but I know that we would have to see some huge savings.
----------------
I also note that there are a couple of people following this blog now; thanks guys for the kind words. I promise to keep writing and hope that you continue to enjoy it.
The company has several sites, some are quite distant, a couple outside of the country. When I first joined, I was astonished at the amount of travelling that was going on. No-one has ever kept specific details, but I did a (very rough) calculation that among the staff at my site, they were spending an average per month of about 75 -100 days travelling. Some of this was by car, some by plane - very occasionally by train. (This does not include those staff whose job is specifically travelling - sales, trucking etc.)
It's difficult to get any kind of accurate figure, but for travel, hotel & hospitality alone, we were probably spending around a quarter of million dollars for my site alone (which is one of the bigger ones). It seems likely that the company was spending a little over $1 million a year. At the time, gas prices were still stable, but everyone knows what happened there. I dread to think what our costs would have been. This also created issues with staff time wasted.
So one of the first things that I did was to set-up a process of remote access working - this allowed those that were travelling to be able to get on with some work whilst waiting around airport terminals or in hotels. This went down well with almost everyone - productivity went up after an initial period of getting used to it, and now it is seen as absolutely essential. We did have a slight issue a few months ago with some people unable to get access (one of the guys making some modifications and blocked access for about an hour) and the reaction to this showed just how used to it everyone has become.
The next step was to introduce video conferencing -I've worked with it before and know just how good it can be. There were of course a few initial teething troubles (people will play about with the settings) but now it works almost seamlessly. I think that there is at least one VC between sites per day and it is now seen as just another tool. Almost all of the staff have had the opportunity to take part in a VC session. The cost saving to the company cannot be overestimated. The equipment cost around $7,000 per site and we saved that much per month in the first year alone, probably twice that now.
So where does this link to SAP - quite simply, the cost of installation has been enormous and without the VC facility, it would have been a whole lot more. At the initial launch meetings, I estimated that the cost of the 4 meetings were around $35,000. After that, almost all other meetings were conducted over the VC - at one stage, 4 a week and they generally lasted all day.
We still had to have some travelling - there was no getting away from that. However, we have kept some figures that make me feel that I can justifiably say we saved $300,000 last year. Of course, this had never been factored into the calculations for the project which really only ever showed the cost of the software and the consultants. We've had to provide them with office facilities, and at the beginning they were expecting us to provide them with lunch etc. (That soon stopped!)
Now I may sound like I'm being a bit hard-assed about this - and I probably am. Before starting to work in IT, I had a long background in other areas of management; and one thing that I know is that as a manager, I have 3 main areas of responsibility. "To increase sales, to cut costs and to improve margins". This applies to all managers, whatever their title and whatever sector they work in.
The reason for buying SAP is quite simple; we need to improve the way that we do business to make us able to supply our customers with a better and more cost effective product. It should allow the flow of information between all areas of the business that will allow this to happen and make it easier to getter better business decisions. This should also allow us to cut production costs, and lead times.
However, there is a very fine balancing act here. I think it likely that SAP will provide some of those savings and increase our ability to streamline the process from order thru production to sale. However, the cost of implementng it is very high - we have to factor that into our production costs. Essentially, will there be an ROI? I have my doubts - current sales in this country of around $30 million, for the group $75 million. With the current economic conditions, this could contract further - we are still OK at the moment, but are already having to make plans to lay off some staff.
I did some numbers with the FD before Christmas; we would normally expect any project to have a payback of 3-5 years tops. Of course in some cases, it is actually better to set costs off over a longer period, such as for capital plant, but they would still want to see a payback in under 5. For SAP, we cannot see a payback in that period - our estimates make it closer to 12-15 years. That of course assumes that we stay with it that long and that prices only increase by an amount anticipated.
Ultimately, with all the additional costs, is it likely that we would ever see a return? I can't say for certain, but I know that we would have to see some huge savings.
----------------
I also note that there are a couple of people following this blog now; thanks guys for the kind words. I promise to keep writing and hope that you continue to enjoy it.
Subscribe to:
Posts (Atom)