Skip to Content

Taking Stock in 2012 and taming the Wild West

I continue to be surprised at how poorly documented enterprise class systems can be. I am not sure whether this is a function of the complexity of these systems, the lack of diligence on the part of the people who run and manage these systems or just the velocity at which change is taking place in many environments.

If you’re in an IT operational role or even a consultant on a project I would hope that one of your resolutions for 2012 will be to take stock of what you have in operational use and how it is being used. Visits to old haunting grounds for me, work wise at least, are always entertaining. I discover very quickly that things are not the same as they were when i worked there, and that should come as no surprise at all. Businesses that are growing and improving rarely allow their systems to stagnate  The one common trait though is that it continues to be a challenge to get useful and meaningful documentation in some of these environments.

I accept that the people doing the work are busy; that documentation takes second place to operational actions however documentation is the key to understanding the context of all things operational and on that fateful day that you call up support to help triage a problem, the first question that you will be asked will be , “what has changed?”.

Bad things do happen, systems do crash, resources become exhausted and bad or increasing volumes of data eventually will get you to a point where something goes wrong that you had previously never seen before. Documentation won’t avoid any of these things but it may be a life saver when you’re trying to remediate the situation or resolve a problem.

In 2011 I saw many sadly avoidable situations where downtime was suffered by the business because either they or IT failed to adequately and appropriately document systems and system usage.

Some basic examples were things like, what are the external system dependencies that our business has on our SAP landscape? One company had implemented a standard SAP purchasing BAPI only to discover after an upgrade that it was broken, that worse still, it was only partially broken and as a result thousands of PO’s were created in ECC that had partial information; the configuration on their SAP system had changed and the BAPI that they had been using was no longer aligned with their solution requirement. They were so bruised and battered by the experience that I felt it inappropriate to quiz them on whether they had appropriately tested the upgrade and regression tested key business interfaces like the purchase order solution. I couldn’t help feeling though, that had they adequately documented the interface and had an appropriate testing plan, the disaster may have been averted.

Elbonian Documentation

Several other companies upgraded to a new Support Pack Stack during the course of the year and a number of them then discovered that interfaces that had previously worked wonderfully for them now wouldn’t work any longer. Some frantic support activity eventually revealed that some core components in SAP were changed as a result of the upgrade and as a result security authorization objects needed to be revisited. Clearly in these examples, no thought or consideration had been given to these external interfaces or at least someone had not documented that these interfaces existed or were in use and needed to be tested as a part of the upgrade plan.

Many users had their SAP GUI front ends upgraded during 2011 and many users also had their Windows desktop environments upgraded but just as many, if not more, did not. The result, I discovered, was that in any given customer environment there could be a dizzying number of combinations of operating systems, SAP GUI front ends and Microsoft Office environments. From an enterprise perspective it is easy to dismiss these as end user environment issues but this situation goes far deeper when some of these users are heavily depended upon for lights on activities like payroll and sales order processing. The decision to upgrade desktop software should typically be part of an overarching strategy for desktop renewal and more importantly, should be done with a clearly documented plan and not the proverbial hip shot.

So, with just a few more days before the year runs out, consider what the new year will represent for you in terms of improving general operations, avoiding fire drills, escalations and heading off disasters. You may well find that applying a little more energy to documenting your systems will save you a few headaches in the year ahead. That is of course assuming that you don’t  like living in the ‘wild west’.

You must be Logged on to comment or reply to a post.
  • I regularly clean up undocumented RFC access scenarios. Even if there is documentation, I can assure you that it is very seldom useful in comparison to what is realy going on.

    This is most unpleasant when the clients have access as the RFC-client server and can freely determine which RFC and which paramters to call, as is the case with generic functions such as RFC_READ_TABLE which bypass the application logics completely. This means you need to document each client installation to be able to correctly authorize each of them and the failing authority-checks will be like the flees of a million camels in your traces and troubleshooting.

    Glad to see you mentioning BAPIs now and hopefully seeing more of this (also SAP’s own Data Services!) in 2012.

    Cheers, Julius

    • I hear you Julius, unfortunately I think it is a function of just too much uncontrolled activity that doesn’t require a discipline to maintain the documentation and the audit trail. It’s a gap. Between the time that you have to tackle a problem and the time the architected solution was originally set up, things changed and documenting the changes wasn’t a priority. Yet, who signed off on the change? How do they know the change was effected and even more importantly, how do they know that the change was the right one to make?

      As for BAPIs; I have always endorsed them as the correct approach however they are more difficult to work with for Business Unit Application Development and more importantly there are not standard scenarios for everything that businesses want to do. Moreover, many companies simply don’t want to make a big investment in something that doesn’t make more products or make more sales but simply reduces operational costs, reduces back office inefficiency and reduces data quality issues. Master Data Managers and leaders in the back office have a tough time accurately describing and enumerating the costs associated with bad data and inefficient back office data processing procedures.