Wednesday 9 December 2009

It's the process stupid!

One thing that everyone says about SAP - the processes can be long winded. However, you have to understand the reason behind that. The software was developed for use by very big companies and to meet the requirements of very restrictive legislation. As a result, many of the business processes seem to require more work than you would find in other software packages.

As I work primarily on the admin side, it's worth mentioning that the process of applying user access is particularly long winded. But there is very good reason for this - when you have 10,000 plus users, it is absolutely crucial to give all of these people the appropriate permissions. But working out what is correct can take a long time. And it has to be said that this has caused some friction amongst our project team.

Our basic AD permissions have been set-up over many years. They are not perfect by any means, but generally people have the necessary access and are kept out of those areas that they should not see. If we have to make changes, it usually only takes a few minutes and it is a pretty straight forward process that can be carried out by anyone in the IT team at any time during the day.

Unfortunately SAP is not so simple. A few months ago, I found out about Central User Administration (CUA), and we wll be looking to implement this at some stage, but at present we don't use it as it was not set-up at the beginning of the project. User admin requires details to be maintained in each system which is awkward and time consuming. The actual access permission is based upon a series of roles - permissions for transactions and authorisation objects are added to the role, and then user is placed in the role. A series of "transports" allows the roles to be copied between systems, so these should be the same in each of the systems.

However, the process is also designed to allow the change(s) to be made and then for these changes to be checked - first in the development system, then the test system, before it finally arrives in the production system. This is to ensure that any such changes are appropriate and don't do something that they shouldn't do. It makes a lot of sense and for the larger companies, I can see that this would be absolutely essential. For us, it is a very tedious process and we are not doing it as we should.

Unfortunately, even tho' the project team have been told about the correct process (repeatedly), they just don't get it. I've noted many times that I have been asked to allow a particular person to have a particular access permission - when I apply it, I've indicated that this then allows someone else within that role the same permission. We could have people able to do specific tasks that we would rather they didn't. After the first few months, I set-up a process to try to get these changes authorised properly. It sort of works, but even now people will try to bypass the process.

One other thing that I've noted - when we started, we set-up the roles based upon the job role descriptions that we use within the business. This was the advice from the consultants and I agreed that it made the most sense. However, having been doing it for some time now, I feel that we might need to look at this again as we have a lot of overlap in what various people do - the number of staff is limited, so most people actually do 2 or 3 "jobs". There is a good argument for changing some of the permissions so that instead of being applied to a "job role", we might have a "process role".

For example, we have sale clerks with various transactions, but there are a couple of these transactions that might also be requested for other people not in sales for various valid reasons - they could be used by accounts, by shipping, by purchasing, by production, as well as a couple of others. This is in fact, 15 roles in total. At the moment, these permissions have to be added to each of those roles, and after testing, they have the same permissions - potentially, we could have just 2 roles with those permissions, and then apply people to them in order to do the work and it would work just the same. Obviously, more work to set-up to begin with, but going forward, possibly much better as it would require less admin work.

Oh well, another day, another dollar!