The Security Stuff (part 2)

I'm following on from last week's post - because I think that there is a bit more to say about this topic.

If you follow any of the people that promote the concept of "Empowerment" within a business, you'll no doubt be aware that many of these people or companies are talking about allowing staff access to more of the information held within their systems, so that it is easier for decisions to be made at lower levels, rather than having all decisions coming down from the top. This is also sometimes described as "agile" business decision making.

There is something to be said for this idea - if someone has to purchase some goods, and has been doing the job for some years, she may well be quite capable of negotiating the right kind of deal without having to refer it to her line manager. This then means that the manager is left to deal with more important issues - and when I was a younger manager, it was known as delegation. A senior manager once told me that if you cannot delegate, you cannot manage.

The problem is of course that not everyone is entirely capable of making decisions at certain levels, and need to be monitored more closely than some others. It also has to be said that there are more than a few managers and senior executives that would be horrified at the thought of more junior people making even quite minor decisons without referring to them. Even if all they are doing is glancing at an email and then replying "do what you think best", they feel that they are "managing the situation". (A bit like the PHB in the "Dilbert" cartoons!)

So it's necessary to decide how you want to secure your date as well as how you need to secure your data (the two are not the same). How you need to secure the data is often defined by regulatory compliance or the need to prevent commercially sensitive information from going astray. How you want to secure the data is more about how you structure the business and how the various processes work.

Most people would agree that when SAP was first created, the main target was the larger enterprise business. Within this size of business it is generally necessary to provide some separation of duties - you don't want the person that creates a new bank account being able to transfer money, otherwise  he might create an account for himself in the Caribbean and transfer $10 million, before taking a one way flight to his retirement (which he also puts on expenses!).

As a result, much of the way that things are structured in SAP security has been done specifically to provide the required levels of security for those large organisations. The problem is that when you get to the smaller businesses like ours, it's actually much harder to define what you need in terms of security. Worse, this can actually change a lot more frequently as staff will often be doing more types of jobs than their counterparts in the enterprise business.

Now we have a problem - I've been trying to make sure that all of the permissions are properly set-up and correctly tested, but even so, sometimes it's not always easy to do this. I will hold my hands up and admit that there have been many occasions when I was going thru a role and suddenly spotted something that didn't look right, that then needed to be corrected.

Partly this is due to some people taking the view that "give them access to everything, and we can take away what they shouldn't have". This doesn't work - why? Because the only time that you find someone can do something that they shouldn't is when they have done just that, and it has caused a problem. And usually, that is when things are going seriously wrong.

We have seen that, not just the one time, but on a number of occasions. Most recently because we have some transactions that were created for us by one of the consultants based upon standard SAP t-codes. Unfortunately, the new t-codes have absolutely no authorisation checks built into them - and as a result, we have found that some people are able to do some work that was supposed to only be done by the Production Manager once a day to clear up any issues.

Oh, and in case you wondered - when I said that I would take the offending t-code out of the role, the Production Manager asked me to leave it in. He is going to speak to staff to try to make sure that they understand that they shouldn't run this particular process, just use the t-code to look at the data. Yes - I'm sure that will work (until the next time).