Sunday, 1 May 2011

What a difference a day makes...

Or even a week…

Our project leader has been over to our overseas site a number of times so far this year, about once every 3 weeks or so - and altho he has said in the board meetings that things were going well, it was clear that there was a bit more hope than confidence in what he was saying.

Privately, he has been suggesting to the project team leaders that there are still far too many issues unresolved, and that despite quite a lot of hard work, we don’t seem to be progressing as fast as we should be. Although he wouldn’t actually say we were behind schedule, it’s pretty clear that the proposed go live date was looking increasingly hard to meet.

I’ve suggested a number of times that we should get the staff from our overseas site to visit with us for a week so that we can help them out with training and testing – by getting them to work with our staff I hoped that they would pick up some of the required knowledge. But altho it was seen to be a good idea, we have had none of their staff visit with us since last August.

It was then suggested about a month ago that we should arrange for our project team to go over there instead. Plans were made, travel and hotels booked and the project leader set out a plan for the week. This was primarily to test their processes to make sure that these would work – I felt that this would be a good start, but was concerned that we would miss a good opportunity to ensure that their staff was adequately trained.

I’d also gotten a bit worried about some of the comments from our project team – one or two had said to me that they were not really sure what they were supposed to be doing over there. So I made a point of spending some time with each one, to discuss how to test the various processes, and I set-up a series of test user accounts for them and made sure that they knew what they had to do.

On the first day at the site, we weren’t able to get much done – we arrived late in the day, and really only just managed to introduce ourselves to people, and get things organised so that we could start work properly the following day. But after that, things really started to take off.

The project team made a point of getting the key staff in with them so that they could see the processes, and in most cases after a couple of demos, these people were carrying out many of the actual tests. That second day, we had actually gone thru every single process and tested at least 3 variants for each. Their staff are now far more confident in the way that they use SAP, and altho they still have more work to do, based upon what they did last week, they should be ready for the go-live.

It should be said that during the tests, we did actually find several key issues – but about half of these I was able to correct almost immediately. As one of their consultants was on site, the rest were passed to him and it has to be said, he made a good start on getting them corrected. However, he also made contact with a couple of the other consultants and they were then available on the third and fourth days.

In fact, by the last day, we had not only gone thru every process many times and confirmed all were working, most of the outstanding issues had also been addressed. This included several that have been on the list for months. It also highlighted a couple of issues with data – I had tried to highlight this previously, and now it is obviously the most urgent major problem remaining so they are looking at dealing with this next.

It should be said that it was hard work - most of the guys were suffering with jet lag, and one had an upset stomach. It's also been a bit warmer there than we normally face this time of year, and some had difficulty sleeping at night. Despite these problems, everyone was really pleased - and I have to say that it is very clear that we have made a major leap forward.

We still have a lot of work to do, but we are almost back on schedule to go live in a couple of moths time. If we can get the data done on time next, then it should be possible to start the next stage of testing in the test system before the end of the month - and if it there are no major problems, we will be back on track.

It helps that there are not that many staff at that site and that they don't have to learn all of the various processes. But there is a lot more confidence now, both on site and in the project team. It has been said that it may be necessary to organise another trip over, and if we do, I'm sure that it will prove to be as valuable an exercise as this one was.

Saturday, 9 April 2011

Learning the hard way

I got back late last night from our overseas site. The project lead and I made a trip over to check on how things were going, and to make arrangements for some later work.

The first issue was the cleansing and preparation of data. When we first did this for the initial project, we found that there were some key issues - getting the actual data extracted into a format that people could use, then getting the relevant departments to tackle the job of cleaning the data out so that we would have only good stuff to load.

We'd found that this was a lot harder than we had anticipated. Some of the data extracts from the legacy system were OK, but there were many areas where the different aspects of the data were not together in the old database, so it required some careful work and a lot of double checking in order to assemble the separate bits of data together. We made this point very clearly to the people at the new site - and gave them what we thought would be the right tools to help them.

Unfortunately, the extract has again taken a lot longer than we expected. In this case, they are dealing with an outside company on a system that we know little about, and the actual data only started coming thru about 4-5 weeks ago. They have been checking the data, but there is still a lot to do - the first couple of tests showed that they are not even close to having it ready for the full data load process which is supposed to start in 1 weeks time.

I'm not involved in it this time - one of my staff is doing the data load and I have virtually lost him for the next month whilst he processes the data. He is really confident and I'm sure that he will do it right - but I know from the work that he has done previously, that it will take more than just the next month to finish. He gets bored with things very easily and moves on to new stuff before finishing a job - I have to monitor him all the time and keeping reining him back in to make sure that he stays on track.

There is another concern as well - and it relates to the knowledge transfer process. I think that the big problem here is that several of the staff are still thinking in terms of how they do the various processes within their existing system. They then have got the consultants to show them how that specific process is done in SAP - and that is not the best way to approach learning the product.

When we first started, I read in several books that it was important to understand that implementing SAP is very different to many other products. To begin with, I probably didn't really see why that should be the case, but having spent a while working with it now, I can see that point that these people were trying to make. It's necessary to learn how to do it the "SAP way" and almost forget how things used to be done (yes, there may be exceptions).

I'd made that point on my previous visits to the site, but I don't think that they really understood what I was trying to tell them. As a result, they are still thinking on how the process was done in the legacy sysem, and then try to remember how that process is then done with SAP. I know that it is still early days, but I don't think that there is a single person yet that can actually complete a single process on their own, even if they are using the training material that they have.

I did speak to the project lead about this, but he doesn't seem to be too worried. His view is that they will pick up speed and they will all be ready by the time of their go-live. I'm not so sure - I don't think that they have had sufficient hands on experience with the consultants, and I'm convinced that whilst they may have seen a given process, they don't fully know any of them.

Unfortunately, our project lead has been working with SAP now every day for several years, and I get the feeling that he expects everyone else to know as much about it as he does. Even tho he has watched them and seen just how slow and uncertain they are, he is convinced that they will improve in a very short time. For me, I am a bit concerned that they won't keep up their practisng if we are not staying on top of them.

And that of course is going to be a big thing. We will of course provide some support for them, but it's going to be a bit difficult - certainly not as easy as when you are on a single site, or even a few hundred miles apart as long as you speak the same language. It will be much better for everyone if they are more confident in using the system before they go live.

I've also been told that it is absolutely essential they go live no later than the last week of July. It won't be possible for them to continue working with their legacy system after then. I did think about suggesting perhaps we should consider a backup plan in case we can't get the data load, and testing finshed by then, but it was pretty clear that this would not have a been a welcome suggestion.

I get the feeling that our project team are going to be earning a lot of frequent flyer miles!

Sunday, 3 April 2011

...And yet another.

When we first started creating the roles for users, I took the advice of the consultants - but after a short while, realised that it was going to get a bit more complicated than I had originally expected. For that reason, I changed the names of the roles, using Z1 for those at our first site, Z2 at the second, Z3 at the third.

The reason for this was that we actually needed to define some limits to what people on each site would be able to do. We didn't want the staff at our second site to have the oppotunity to make changes to items from the main site. This seemed to work quite well, but then I found that some roles were getting very big - and at that point, I started to split the roles down.

We had a hierarchy - sales clerk, sales manager and added a couple of other items to this to allow some staff more access to do certain functions. So for example, 2 staff are involved in contract review, so we have a role for that. 2 other staff are involved in dealing with certain groups of customers, and that is a seperate role as well.

There were some issues right from the beginning, as the project team didn't really understand the concept of permissions - I would regularly be asked to give someone access to something, and when I pointed out that it was to the role that permission was granted, they would get very frustrated. However, it appears that for the most part, they now do understand and we do have a set of roles that serve our needs.

When we started on our first overseas site, I copied the basic roles from our second site, changed the organisational levels and applied user accounts to get them started as Z4. I felt that as we had most of the authorisations already confirmed, this would be pretty much what was needed. I sent details through to the relevant people, including the consultants that I had been told would be doing the necessary work, and waited for some minor changes.

Up until the first day of the work to go thru the processes with the staff, I had heard nothing. Later in the day, I received an email from a completely new consultant asking me to give permission for the staff member to have access to certain t-codes. When I checked, about 80% of those were already in the relevant role, and the member of staff had been added to the role. The few remaining were t-codes that we didn't actually use - we used different ones to do the same job.

I had several more emails requesting access, each time on the day of the process testing rather that before hand. In several cases, I pointed out that the t-codes being requested were restricted to certain people. It was decided that currency rates, period closure etc would be done centrally, rather than have different people at each site getting involved. However, I was also asked to provide access to certain t-codes that I was very reluctant to hand over - why would the staff members need access to things such as SCC4, STMS, SE16N just to name a couple. These are only for administrative positions, and I could see lots of issues if they had access to these.

What I didn't know was that the staff at our overseas site had made a complaint that they didn't feel that they were getting the relevant training they needed and this was passed to our CEO. He then discussed this with the director of the SI, who basically said that I was holding up the work by not providing the required access.

I was dragged into the CEO's office, and to be brief, he told me that the SI were insisting that I give all of the staff at our overseas site the profile SAP_ALL. I tried to point out that this was not good practice etc. but this cut no ice. I highlighted that we needed to get the roles right, but he had been told that this could be done afterwards - in order to get the site up and running as soon as possible, they needed SAP_ALL.

At that point, I told him that if he wanted this, I required him to put it in writing - and I thought that he was going to explode. I won't go into the discussion because it's not necessary, but it was very unpleasant. However, I did get the instruction in writing as I requested.

Someone has subsequently said that he thinks that's a good thing - that when things go wrong, I can produce the written instruction, and throw it back at him. That's not why I did this - when it goes wrong, I will not bother arguing, I'll just get on and try to resolve the problem. My reason for asking for the instruction to be in writing, was to make sure that he understood just how seriously I take the issue.

As it happens, the process testing over at the other site is way behind. They still have almost all of the work to go thru still, and based upon the last project plan, we are about a month behind. There is going to be a big push in a couple of weeks and I have done some work to allow some of our people to do some testing for them. However, I'm not convinced that this will be of any value, as it it appears the consultants are teaching the staff over there different processes to what our people worked on.

I have reason to believe that the SI are pushing to get our overseas site operational on the agreed date, no matter if they are ready or not. I think that this is potentially a serious error of judgement - if they are not ready, we should admit that, and hold off until they are ready. Pushing for them to go live without them being ready could be disastrous - and not just for them, but for the company as a whole.

Sunday, 27 March 2011

...and another?

As anyone that works with SAP will know, it is normally set-up as a 3 system landscape. So you have one system which is for development work, one system for testing purposes and another system which is the actual production server - the one that is used by the organization for the day to day work.

The reason behind this is really quite sensible - when you have an ERP system, it is usually really quite important that the production system continues to operate without interruption. Making changes can have pretty serious consequences - you don't want to make a change and then find that it causes the system to fall over everytime someone enters a piece of data (and most people have had experience of exactly that happening).

So having the 3 systems allows you to do development work on one system which won't generally affect anyone else, plus you can then test out the changes on the second system to make sure that there are no undesirable side affects. Once this is fully tested, the changes can be applied to the production system and this will reduce the likelihood of the changes creating an issue that will stop the main system from running as it should.

When we started out, the consultants did actually explain this - however, our project team members didn't really latch onto the concept. Even some considerable time later, they still didn't really fully grasp the purpose of the 3 system landscape. In fact, I would suggest that most of them thought the idea was we would start with the development system, then at some point we would move to the test system, but that that meant the development system was then no longer needed. The same would then happen to move to the production system, at which point the test system would become redundant. They just couldn't see why the others were needed once we had moved to the production system.

Unfortunately, we have had a problem with this - the consultants from the SI and our project leader regularly perform development work in the production system. In some cases, it is just a variant to a report - but on a number of occasions, it has been a bit more than that. There are many times that I've seen our project leader working on producing a new report or even a Z t-code. I can't tell you how many times I have had an email asking me to add a new t-code to a role, only to find that it doesn't exist in the master system.

Now I have raised this issue (more than a few times), but the problem is that every time, he will simply say that he is just following the same procedure as the people from the SI. I can't dispute that - it's exactly what they do. The fact that they shouldn't doesn't come into the argument. It's difficult to say that he shouldn't do it, when the people that we are paying a great deal of money to, ignore some of the most basic practices. And of course, if the project leader (who is a senior manager) doesn't follow the correct procedure, then it's a bit difficult to get other people to do it the way that it should be done. "Monkey see, monkey do".

What I have found a bit irritating is that the project leader does actually understand the reason behind this, and he fully supports my attempts to get people to use the appropriate system. (However, that doesn't apply to him of course!) There was an incident about 2 months ago, and he was bouncing off the walls about the fact that someone was doing what they shouldn't - but he ignored the fact that he had been doing the same thing just a couple of days before. He just couldn't see that people will do as he does, rather than as he says they should.

I remember reading something a few years ago - it's essential to train people up in the way that you want them to work, right from the beginning. There is no point in training people to do things one way, then try to get them to change later as it seldom works out the way that you want. I have to say, we have proven the value of that - I doubt very much that we will ever be able to get people to change their way of working now. I suspect that even if we have a major disaster, they will still carry on in exactly the same way after it has all been sorted out.

But it doesn't mean that it's right - or that we should tolerate it. This slackness leads on to other problems - but more of that another time.

(I've just noticed that there was an issue with the paragraphs on the original post - I've now corrected that. Sorry to anyone that was frightened off by a mass of text!)

Tuesday, 8 March 2011

Please sir, may I have another?

I've been off work for just over a week - I've not been as ill as that for some time. However, I started feeling better at the weekend, and went back into work Monday.

I went thru various things with my staff, made sure that there were no major issues that needed immediate work, the usual sort of stuff. A bit later in the day, I went in to talk to our SAP project leader and catch up on any developments.

We have a new timetable in place for our overseas site project and the go-live date has already been moved several times. Despite that, they are still behind schedule, and falling behind further every week. He was getting concerned so decided to go there last week and he spent a few days on site.

Now as I have said previously, we have had a number of changes of consultant over there. I'm told that the SI didn't have the personnel available to do the work, so they bought in a couple of people who don't work for them. As far as I can tell, these people were quite experienced (8-10 years) with a number of implementations to their credit. However, these people are now gone and have been replaced by two people that do work for the SI. The first guy has about 2 months experience and this is his first implementation. The second is a young lady with slightly more experience - she has just under 6 months with SAP and this will be her second project.

Our project leader went over to the first guy and saw he had a copy of the blueprint document open, and was in the middle of makings some config changes. He was a bit surprised as he had been told that these were all done. However, when he looked a bit harder at the document, it was version 4 - and the final version which was supposed to be the one we are working with is version 7.

Essentially, a bunch of config changes were made ages ago, then changed to update them to meet the required blueprint. The consultant was in the process of changing them all back to the earlier version (which had already been changed before). Our project leader naturally asked him if there had been any conversation on handing over the project from the previous consultant and was met with a blank look. You can bet he made it very clear that the guy was going to have to get it changed back again real quick!

So feeling a bit frustrated he went over to one of the site staff to ask a few questions. To his horror, the guy was in IMG and was busy making config changes of his own. His immediate reaction was to call me on the cell phone to give me a chewing out for letting the guy have access to this - then he thought he would check to see how the guy was logged on. To his astonishment, the staff member was logged on using one of the consultants logon and password. When he queried how this happened, the guy just showed him a sticky note with the details hand written on it.

---------------------

I am sure that some of you are equally astounded - you may even be shouting. When the project leader told me this, I just closed my eyes and thought of my wife and I on a nice, warm, sunny beach, with a couple of cool long drinks. Hmmmm!

---------------------

For what it's worth, the member of staff has had 2 (count them) days of training. The consultant concerned has obviously been on some SAP course, and she is using the same training material to do the training of staff on our site. When asked if it was appropriate for staff to know some of these items, she just shrugged - she clearly thought that this was how it was done.

So rather than train our people in what they have to do to do their jobs, she has tried to show them stuff that they will never actually get involved in. The things that they will need to know, she doesn't appear to have covered at all. This has caused some confusion and I now understand why I got a rather frantic email from the finance guy on the site demanding access to the entire SAP accounts menu. (About 4,000 transactions?)

Anyways, the project leader is back, he is not happy, and he wants to have a meeting with all of the project team. He is basically going to say that each one of them is going to have to do a trip over there to do some of the site training. I raised this option about a year ago, and the response was considerably less than enthusiastic. Now they will have no choice - and that will cause some bad feeling.

There were other things that I wanted to cover, but they can wait for another time.

Sunday, 13 February 2011

Same old, same old

I've been very busy over the last month - there have been a lot of different jobs that needed doing, and I've travelled quite a bit in the process of doing that work. So I've not really had the time to add anything. However, there is something that I am going to post about - and it involves the work that is being done for the first of our overseas sites.

As I've indicated, there is a lot of work that needs to be done for the new site before they can start to use our SAP systems. They have had a group of consultants on site now for some months - I'm not sure how many, as I originally set-up 5 accounts for them, but I know that at least two others have been involved, but as they used the accounts of the others to do the work, I'm not sure who has done what.

Originally, the staff were supposed to have had their training last year, but this never happened. I'm told by one of the staff, that they would see the consultants arrive on site, they would grab a coffee and then vanish into an office, where they stayed until late in the evening. There was no attempt made to talk to staff or managers, and they barely even greeted anyone. As of the middle of January this year, we still had no information on what training would be done when, by who or where it would take place.

Last weekend I was up at our second site - there is some work that has been scheduled for some time, and I spent several days getting it completed, getting back late on Monday night. On Tuesday morning, I walked into a major discussion between people, and spent most of the morning trying to figure out what had happened.

It turns out that a consultant we know nothing about had turned up on the overseas site to do some training the week before. This hadn't been discussed with anyone here as far as I've been able to determine, but it's possible that they had made the arrangement with the local staff, but just not let anyone here know what their plans were.

Anyway, this guy had asked one of the site managers about his user account - I set this (and the others up about 2 years ago, and had sent them all the details. I'd also created specific unique roles for that site, and these had been detailed out in a document that was given to the consultants when they started work last year.

However, the manager couldn't remember the account details - well it's been a couple of years so I can't blame him. I'm told the consultant insists that he tried to call me, but I received no call, no voicemail, no email, nothing. None of my staff were called either. So he went ahead and created a new account for the manager. As he didn't use the format that we have agreed for this, it was pretty easy to see what had been done.

He also created a new role for the manager - again it didn't use the format agreed and it was easy to spot what had been done. Rather than copy an existing role, he created one from blank and then added in a whole menu tree - I haven't counted, but it looks like there are between 3,000 and 4,000 t-codes in there. It also looks like he changed the authorisation objects so that they are set to wildcards for most of the things such as company codes, etc.

OK, so this is a pain, but it's not really that serious right? Except that he had done this directly in the production system. That wouldn't have been such an issue, but he then used that to do the training - and they have created a load of test items in the production system which are just garbage. It caused a real nightmare for the sales people as these items have shown up on their contract review, and no-one knew what the heck it was supposed to be for. Fortunately, it hadn't gone thru to production, or we would have a major problem.

I spent most of Wednesday going thru tidying up the crap that had been left. I don't know what other training is planned, but I'm hoping to speak to the manager concerned tomorrow as he is visiting us. However, it appears that he is on a tight agenda, so I may not get the time I need.

I just feel so darn tired - I think that I need to take a vacation.

Saturday, 15 January 2011

Foreign parts

From the very beginning of our ERP selection and implementation project, it was thought that we should choose a product that could be used by all of our sites, including those overseas. The reasons for this are that with one system, we should be able to improve processes, make costs more transparent and improve the communication, analysis and decison making for the whole group. This simply makes so much sense, that it would be difficult to justify any other course of action.

At the time, every single site was using a different system, with different processes, and it was not easy to tie all the data together, as much of it was in different formats. Once the decision had been made to go with SAP, it was made very clear that the sites in the home country would be done first, then the product would be rolled out across the rest of the sites in other countries.

The project was kicked off back in 2007 and the go live was planned for the second half of 2008. It was suggested by the System Integrator that we would then be able to get the first site overseas done in the first quarter of 2009, then another about 6-8 months later, and the sites in other countries at approx the same interval. However, due to a number of other outside concerns, a decision was made that the third site was put back to just over a year after the second site, and then the others were to follow on again at 6 month intervals.

As you'll be aware if you've followed my previous posts, the initial go-live was put back, first by a month, then again and again until a date 14 months after the original planned date. Of course, as we hadn't gone live, it was impossible for the second site to do so. Their date was also delayed and a tentative date of second quarter 2010 was agreed. But as so much work was being done on the main project, none was being done for them. It later turned out that of the little work that had been done, none was really of any use, so in the end, they had to start from scratch.

There was a meeting just under a year ago between the director of the SI firm, our CEO, our project lead and the VP from the site for that country. I wasn't involved and didn't get very much information about what was agreed - I do know that the director from the consultancy sent an email with his take on what was agreed, and it was just 4 bullet points! I was told that he would supply a project plan for the implementation at that site, and that they would be going live on a date just after the middle of the year.

I made myself a little unpopular at that point - I pointed out that the date that he had indicated was actually during a period when the majority of the staff at that site would be away. They have a number of national holidays and various events, and to set a date for a go-live then would have been pretty darn silly. As it happens, once the VP concerned got his copy of the email, he made exactly the same comments. It appeared he had made that very point during the meeting, but it seems that this had been ignored. It took a while but a new project plan was eventually drawn up, this time with a more sensible date, and this was distributed.

So the new plan was that this second phase would see the site go-live at the end of October 2010. I had a few reservations about that, as I knew that there was a lot of work to be done, and altho the site is smaller, and there would have been slightly less work, as they have fewer staff to spare to do the tasks, it seemed that the plans were optimistic at best. This was not made any easier by our internal project team. Most of them were not that willing to spend as much time working on the project for another site as they were for their own site.

I spent a few days at different stages over there, and I tried to keep in contact with their people. It became obvious that they were falling behind very badly almost from the get go. I tried to see what I could do to help, but it just seemed that as we had experienced with the project for the main site, nothing seemed to stay on schedule. There was little communication, and we had to try to get information for ourselves on the progress.

There was a meeting organised last September - the director for the SI apparently made a statement that we were on schedule and the site would be ready to go live on the date agreed in October. When I heard this, I couldn't believe it - I went into the CEO and told him quite bluntly that this was garbage and showed just how little work had been done. There were some very tense audio conference meetings at which I was accused of being an "Organizational Terrorist" by the consultants. (I'm not quite sure what they meant by it, but it was obviously not intended to be complimentary.)

As it happens, it became abundantly clear that the second site is not ready (and they still aren't). The consultants working on that site were still making config changes right thru to Christmas, and none of these have yet been transported. No data has been extracted from their old systems, so of course it hasn't been loaded. None of their staff have yet had a single training sesson - and as a result not one piece of testing has been carried out. The consultants were complaining that the language packs had not been applied as there were several errors. We have since identified that in fact all of these are in place and working - the missing text is all stuff that they would have to add manually.

At this stage, I don't think that we have a date for the go-live at the second site. Someone did suggest May this year, but I can't see that happening due to the amount still to be done. We are then almost into their main summer holiday period, plus the national holidays again, so I have a feeling that we could in fact be looking at September or October of this year before they will be ready. In other words, they will be going live about a year after the date set for them as part of the revised project.

Now I have been trying to understand why these dates are so clearly out of sync with the project plan, and I feel that I have something to add. I'm sure that what is happening is that the consultancy are using a generic plan that says, X many days for step 1, Y many days for step 2 and so on. This is fine if the allocated amount makes sense and also if they then actually communicate that information so everyone knows what is required.

I am going to say that I don't believe that any meaningful communication is taking place. The reason that I say this is the consultants doing the work didn't seem to know about the stages and had no idea of when anything was supposed to be completed by. But for me the biggest issue is that it appears the director of the consultants is not even checking to see if the work has been done. His plan says that stage 4 should be complete on day 71, this is day 72 so stage 4 is now complete. If it isn't, he just ignores it and carries on to stage 5.

I'm sure that for some people, this makes sense - but I really cannot see it. If the work is not complete, it is not complete. I accept that if you have a fixed date on a project, sometimes you have to make a decision to trim the workload to make sure that you achieve that fixed date. But in this case, trimming the workload is not an option as that means the product won't work - and it then makes sense to make sure the work is complete even if the date has to slip.

So I suspect that I'm going to be doing some travelling later this year - going to have to dig out my old language tapes to brush up!