Sunday, 11 July 2010

Practice what you preach

Over the years, SAP has worked with a lot of companies in different industries - they have seen many different ways of working, and various people have developed parts of the program to modify it, to allow better integration with the business processes of those organisations. When a vendor then sells SAP to a new customer, they then promote these as "best practices" and suggest that if the more successful companies (using SAP) use them, then it makes sense for the newer purchasers of SAP to use them as well if they wish to be equally successful.

I'm not sure that I fully endorse this idea - just because a successful business uses a particular process does not mean automatically that process will work elesewhere, or that it is the best way to do something. I've seen many different organisations and ways of working - each had their own methods of doing things and in most cases, they worked really well. However, I am prepared to keep an open mind on the topic.

I understand the concept of challenging existing practices, and agree that sometimes a business can get stuck with doing something a particular way because "that's how we've always done it". My own company had exactly this issue (and in some areas, I think that we are still suffering the same problem) and it makes sense to use the implementation project as an opportunity to examine what we do and try to find more efficient methods of working.

As it happens, I believe that this is a process that should never end. People should be encouraged to try to find better ways of doing things and as this does not always come naturally, it may be necessary to undertake appropriate training. I spoke to several of the consultants working on our project, and what became clear was that none of their people have attended any official SAP training sessions or seminars in the last 5 years. This would raise the question if the "best practices" that they are advising us to follow are actually the most appropriate or up to date.

However, I believe that the "best practices" are not just about the processes that are used within the normal business flow. I'm sure that some of the more seasoned SAP people that follow this blog will correct me if I am wrong, but it seems to me that the "best practices" should also include the way that the SAP system is structured and managed. In particular, such elements as change management & testing are crucial and it is vital that correct procedures are followed to ensure that when development work is undertaken, it does not cause problems to the operations of the organisation.

I have to admit to being very concerned about the way that our consultants seem to ignore the practices that SAP promote in this area. As an example, shortly after go live, our internal project manager highlighted that we still needed a particular report (one that had been requested way back). One of the consultants worked on this and in due course, I received an email to request that certain staff should be given access to a new transaction that had been created from an existing one. But when I tried to do this in the golden list, the transaction simply did not exist. It turned out that he had unlocked the production client and created the new transaction - then locked the client, instead of creating it in the development system and transporting it in the approved manner.

I queried this in an email, and received no reply - I'm told that when the consultant concerned was questioned about it, he became angry and told the project manager that I was being unhelpful. I subsequently found that he then unlocked the production client again, and added the transaction to some roles, before locking it down. That worked fine for a couple of days, but after I had carried out another transport of roles between the systems for another update, the transaction was again not available.

Of course, he then did the work in the correct way (although I note that the transaction is slightly different in the production system to the one in development and test systems). But it seems strange that he wouldn't use the correct procedure to begin with - he should have known what would happen. I regret to say that this is not an isolated incident, and there have been several other similar issues with work not being done according to SAP's own guidance.

Another area of contention relates to testing of development work - or rather the non-testing of development work. Checking in the transport system, I see that one particular item was transported from development system to production system a dozen times in the space of an hour. It's clear that the consultant was not bothering to check anything in the development or test systems, but simply making a change, transporting it and testing in the production system.

What worries me a bit is that the project team have been working with the consultants, so they have seen these unsatisfactory processes and seen them as normal. If I suggest that doing something a particular way is not appropriate, they immediately point to the consultants and indicate that is the way that they do things.

So does it really matter if people don't quite follow this "best practice"? I would suggest that yes it does - SAP is a large, complex, inter-related piece of software. The procedures are there for a reason, to ensure that the changes that are required are working appropriately and do not cause issues elesewhere. If people don't follow the procedures, then things can go wrong, and putting them right can be a huge undertaking.

What is worse, if someone gets used to doing something in a particular way (even if it is wrong), then it is hard to get them to change. And this of course then brings us back to the beginning - we have replaced one set of practices with another, but neither of these are "good practices" and I seriously doubt that we could define them as "best practices".

But perhaps that is just me - it could be that I am making a mountain out of a molehill. These issues are causing the IT staff work, and we seem to spend time on dealing with what I see as unnecessary corrections rather than what I feel we should be doing, which is the more proactive work to maintain systems. However, we are coping, so maybe things are not so bad after all.


  1. I absolutely can't stand how the term Best Practice has been applied to the SAP industry. There are certainly de-facto standards that many customers have chosen to implement in terms of their business processes... no doubt about it. But my main issue with the term is how consultants routinely hide behind the phrase as a way to shield their recommendation from their own lack of experience or ability to articulate the real reason why XYZ is the best way to go. "Oh, it's best practice to routinely open up Production and make changes to authorization profiles without replicating it throughout the landscape. Definitely best practice." That's horseshit.

    You're correct that best practices (or standards) apply to not just the business processes that are governed in SAP but also the system's administration, implementation, testing, and any other actions that relate to it's care and feeding. In your case, there are oodles of widely accepted approaches to managing transports.


  2. I have found your blogs very interesting, and illuminating. BUT it sounds like your implementation partner is certainly not using "best practices". You really need to lock down the production system, so that they do not have access which allows them to open that system for changes - your auditors will give you a big red flag when they find this out... Either remove their user id's from the production system, or reduce their authorisations so they can't do this kind of thing. Why do they even have logons there, except for support analysis purposes? Use transaction SUIM to help identify these users.