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.