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!)
Subscribe to:
Post Comments (Atom)
Speaking as one who has done battle with SAP Security groups in the past, I'd suggest you sort this out very quickly. Apart from risking the breaking of your production system, you are alos running the risk of fraud and subsequent coverup. After all, if there is a discrepancy due to fraud, how easy will it be for someone to correct it ?. I'd also be worried about how your Project leader is keeping track of his changes, and their impact on other system changes.
ReplyDeleteThe people charged with enforcing this policy need to be experienced with SAP Security and to have thick skins; experienced, because they can design profiles and roles that negate the need for, and prevent, that one little change in production, and thick skins, so they can deal with the project leader and his superiors in an identical manner to the way he deals with junior ABAP coders.
Not that you need more evidence that your consultants are lousy but the notion that this practice is OK is illogical, irresponsible, and could not be a more glaring example of how bad they are.
ReplyDeleteIt seems to me that the average experience level of consultants in the industry is actually decreasing... which is odd but statistically possible. On that note, I sense that this bad practice of doing updates directly in production is becoming more widespread. It's a sign of laziness and poor control... nothing more, nothing less.
Martin,
ReplyDeleteI think that you are correct - and you are NOT going to like my next post. I was going to add it on to this one, but decided to leave it for next time, as it will be quite a big one.
The points you make are the same ones that I did - and they have made no difference at all. I could also say "what track of changes?" but that would be a bit unfair. There is some tracking going on, although it is fairly minimal.
As for security - well, read my next post, it may tell you more (and probably more than you want to hear).
Nathan,
As far as I am cocerned, most of the consultants I've seen are nice enough people; but I question the level of training and monitoring that they have received. Far too many have been people with limited experience, and it seems that they are being driven to get things done quickly.
Someone made the point that things can be done right, or they can be done quickly and cheaply. Most companies try to cut costs (we are no different) so the quality of work suffers.
Once again guys, thanks for the input - believe me, it is really appreciated.