Saturday 25 April 2009

User Roles

When the project started, we looked at the amount of access that users would need to get their specific jobs done. I’m well aware that if a user has too much access, then there is the potential for them (possibly quite un-intentionally) to cause a lot of damage, and made the point of explaining this in some detail. It was agreed by everyone that we needed to be really careful about what permissions were set-up.

Now having dissed the consultants on a regular basis, I am prepared to say that in this area, they did actually make some sensible suggestions. I’ve not worked with SAP before (although I’d heard about it from others) and I was prepared to be guided by their advice on this.

They suggested that I create a series of “Job Roles” which would be the basis of the permissions. Originally these were based more on their modules within SAP, but after a few tests, I felt that it was better to manage it more around our departmental structure. There is also a hierarchy of user, supervisor & manager as required. This was agreed in a meeting with the project team, way back about 2 months after we started the project. (This also actually fits well with the way that we’ve structured our AD)

The guy that showed me the process was quite helpful – he made the time to cover the main points, and then left me to get on with setting it up. He did say that it normally takes 1-2 weeks to set-up the initial user accounts and roles – in fact, it was completed within 24 hours. OK, the initial roles only had a limited number of transactions within them as that was all we had been advised of – we knew this would change as we learned more about the product.

After the blueprint phase was completed, the various consultants then started to talk in more details with the various members of the project team. From these discussions, I started to get a number of requests for additional changes. These were added at the earliest opportunity to allow people to check things out. I then found that some of what had been explained to me was slightly incorrect; so had to spend a couple of weeks going back through some of the roles to correct errors in the authorisation objects as a result. But again, that’s all right by me as I expected some of these problems.

This went on for some time; as the project team worked with the consultants, they would find out about yet more transactions that they not previously heard of – I was regularly getting 10 - 15 requests for these to be added per day (sometimes just one t-code or authorisation object, occasionally dozens). Although happy to add these, I felt that we needed to be more structured in our approach; I was concerned that I was being asked to add specific items without the need for a user to have these verified, and that this would give access that actually wasn’t needed.

I had spent some time trying to explain this to the internal project team and although they said they understood, it was clear that this was not the case. It has taken a while to get to the stage where they now really do appreciate the potential problems. In the end that I was covering this almost on a one to one basis with the guys and gals – it was the only way to make sure that they knew and I didn’t want them to feel that I was putting any of them down in front of their colleagues.

The biggest challenge for me was that the different sites in each country work in different ways – different products, different processes. Although it would require a lot more admin, to get the most value, it was thought we needed a different set of roles for each site. Now SAP standard practice is that all user roles are prefixed with a Z – they don’t use this, so if you do a search using Z*, it only produces your own roles. Sounds good – but we actually have a lot of roles, and duplicating them by country made it messy. So I suggested that we could use other letters for each country – say Y for Canada, X for Mexico etc. This has worked really well; it’s made life easier and we should get what we want from it all.

It was then suggested that we could use a similar practice for other areas – for example reports, structure etc. This was seen as a really good idea – unfortunately they didn’t stick to it. We found that we had to go back over quite a few items to correct them as the consultants hadn’t used the same structure throughout – it caused some confusion to be sure. Our PM has gone through a lot of these and straightened them out – it’s taken a while, but he is getting there.

What does worry me a bit is that I’m still getting request for changes, even after all this time. I think that part of this is due to the number of changes in consultants. I may be wrong, but they seem to each favor different methods, different transactions etc. As a result, with each change of consultant, yet more t-codes are requested. I did a quick check on the number of these – I now have in excess of 3,000 copies of requests for changes stored in a folder that I created specifically to keep track of the requests.

It’s also the case that as we do more testing, we are finding more requirements for changes. According to their original project plan, all of the changes should have been finished about 3 months before we went live – certainly before the user training began. However, as we carry out more of the training, we are finding more and more issues where the user actually needs more access than the role was given during the sessions with the consultants. I suspect that I am still going to be getting these requests for months to come.

The main thing that concerns me is the amount of time involved in all of this. During the original pitch, I specifically asked them to highlight the amount of work involved; this was to try to see if we would need additional resources. They assured our directors, that the maximum amount of work involved in administration would be 2-3 hours a week – in fact, there are 2 of us working on this and from records we have kept, we are averaging 3-4 hours a day each. This is not just user account or role admin, but server and system maintenance as well.

Note that this has to be done on top of our normal jobs – because we were told that no additional resources were needed, none have been provided. In reality, based upon what we have seen so far, we need at least one other person. I also believe that as the other sites come on line, and we need to keep system running for more of the day, we might need another person and start a shift working pattern – something we have previously avoided.

There we are - just over 2 months to go – however, there may be another delay. We will probably know more about this in about 2 weeks time.

Wednesday 8 April 2009

The days and months go by..

I hadn't realised just how long ago it was that I last posted - almost a month.

A few weeks ago, it was my birthday - the kids put together a special treat for me and we planned a meal at a local restaurant. Of course, I was late home, just time to hit the shower and change, then off out with wet hair. I have to be honest, I didn't feel like celebrating, and we cut the evening a bit short. When we got home, I sat down and fell asleep. When I woke up the next morning, I was still there; and my wife had got a blanket and was there with me. I can't get over how lucky I am to be married to her - either I did something really good in a previous life, or this is a case of "pay it forward".

My wife felt that I needed to see the family physician again. He confirmed that my blood pressure is still climbing, although the cholesterol is OK (just). He wants me to take a vacation and I can't disagree with him; we are looking at taking a break later in the year. I don't care where it is - just somewhere that I can relax and forget about all this crap.

Anyway, back to work - I managed to get all of the support package updates loaded. There were a few issues afterwards, but I also managed to get those sorted as well. As I said previously, the only training I've had has been the one day early last year, and that wasn't that good. I feel that despite this, I'm actually making some ground up, although it is still very difficult. As one of the commentators said "SAP = Slow And Painful".

The project team have been working on doing end user training. As a result, there isn't a day that goes by when I don't get requests for changes to user role permissions. Most of these, I can do fairly quickly and I am at the point where I can quote most of the transport numbers for the roles - I've been doing this far too long! This has been happening for about a month now; and the general feeling is that we are not going to hit the go-live date by a long margin. This has caused considerable upset - the CEO is not happy to move it yet again. However, I don't see that he has a choice; we are still waiting for so much work to be completed. Almost every week, we find that something that was fixed is broken again. There are still issues that have been highlighted previously (one going back over a year) that still have yet to be fixed.

None of the consultants have been on site over the last month, but they are still working on stuff. I had a really nasty call from their project leader demanding to know why he couldn't get access to our system - the reason was that someone from SAP Active Support was carrying out some work to correct an error in a database table made by one of his colleagues. That has caused yet another set of emails to fly back and forth as they deny that it is anything to do with them.

Our Sales Director has also been in contact with their people. We bought their CRM system on the basis that it would be useful to have it as it links in to the ERP side and this would save a lot of issues. Unfortunately, it has been a complete disaster - the software is slow, buggy, unstable and it's been reported many times that it isn't linking correctly although the CRM consultant said that it was all set-up as it should be. I finally managed to get directions to correct the link, but it still doesn't seem to do what they promised it would. It's so slow that the sales staff would simply not be able to use when talking to customers.

The CRM runs in Internet Explorer and it crashes when more than 3 or 4 people are working on it. There have also been some issues with incorrect data being returned from some of the searches. It links to Exchange for the email, but there seems to be an issue with saving the emails and we have had some corruption of data. The reporting seems to be skewed; we have had some odd outputs, and although they said that they had the output text sorted, it's wrong again. The worst was a printout that should have been 1 page showing a customers basic sales data for the previous month - it came out as over 100 pages, most of it complete garbage.

Our CEO took this up with a director from the consultants - his response was to say that it works perfectly, that hundreds of customers use it and that it must be down to the stupidity of our staff. I'm not sure where we are going to go from here - the CEO has pretty much given them an ultimatum, it works as we need by the end of May, or he wants his money back. In the meantime, the sales people have another CRM system that they think will do the job; it is about a quarter the price of the SAP CRM.

So where we go from here, I really don't know. My guys and I are working long hours, weekends and putting all the effort in that we can; but we are getting tired, and there are some minor health issues which are starting to appear which never bothered us previously. The project manager and project team are all despondant; they are trying their best, but it just doesn't seem to be good enough. The CEO recognises this, but he is in a difficult position politically - if we delay further, it will reflect badly on him. He's not stupid though - he sees the problems and can see how bad things could be if we go before we are ready.

Well enough for now - I have to prepare a report for the next board meeting.