Blog Series Fitness Plan: Knowledge from the past

Welcome to our first article in the series: “Fitness plan for your SAP system.” Starting from my own personal – and sadly all too frequent – situation of carrying a few extra pounds, wanting to lose them as quickly as possible and thus regaining my fitness again, we turn to ERP systems. And believe me, both situations have comparable problems and solutions…

I never used to have problems with my fitness. I think…



You may recall that in the first article we discussed the fundamental idea of creating a fitness plan for our long-term objective of getting one over on our excess pounds. Possibly using some trickery or other.

But it’s not just gyms that take into account performance diagnostics to precisely assess the status quo and possibilities of someone aspiring to become fit. It is imperative that we consider and reflect on how your own performance was yesterday/last year/ten years ago (you insert whatever time frame you wish).


Regrettably many of us tend to invent classic myths when it comes to our own past performance. They would make many a fisherman blush in embarrassment. After all, somehow time tends to blur a detail here or a detail there. So it really would be totally practical to focus on the past in a little more detail. But we need objective measurements of performance to do this. How can we do this if we don’t have reliable data from the past?

Do you recognize this state of affairs from the day to day life of your IT systems? You sometimes hear people asking “how were things really back then?”, admittedly sometimes behind their hands. In other words, what we need are robust and meaningful performance indicators that map our development and growth, in good times as well as in bad times.

The solution to this problem is self-evident – we simply need to draw on objective performance indicators from past measurements. As with our own personal fitness plan, a purely subjective assessment of our former state is only of limited use. Many statements become totally unrecognizable when viewed against the background of experiences gained in the interim and current agendas. We need clear measurements based on old data. Systematic technical collation is based on a simple approach – we try to obtain the information from archives or old data in active databases. There are many methods available for doing this:

  • Databases with corresponding time stamps
  • Monitor records
  • Past analyses and key performance indicators
  • System enhancements and interfaces
  • Organizational considerations
  • Used Processes and process variants used

Naturally a whole series of tools relies on the examination of these mechanisms. But what do these key performance indicators say? What syntactic analysis of custom code will reveal something about their relevance to my business? Or even about organizational alternatives that are possibly even part of standard functionalities?

It requires a comprehensive wealth of experience not only to gather these key performance indicators but also to assess them. This relates especially to complex business management issues. Instead of relying on the subjective wealth of experience of a consultant or long-serving employee, rather you should rely on trustworthy and transparent information, naturally also based on best practice standards. In terms of our own personal fitness, we simply rely on age-specific comparative values. In relation to operational IT, we refer in this respect to benchmarking. Fundamentally correct benchmarking represents a science in itself, but delivers helpful findings in almost all areas.

We identified three meaningful key performance indicators as examples to illustrate the usefulness of benchmark statements.

Every second company posts debtor invoices too late These sort of delays and exceptions have an adverse effect on process efficiency and increase transaction costs in the form of lost profit and additional work. Measured against our benchmarks, countless companies are far below this level.
Over 50% of customer transactions are unused – and also over 70% of customer programs The level of individualization shows the relationship between standard functionality and individual adjustments. These adjustments are not bad per se, but increase maintenance requirements and thus costs in the long term. It is all the worse when expensively paid for developments are not even used – nonetheless this appears to be widespread.
On average the SAP systems analyzed have over 3,900 users It is anyone’s guess whether 3,900 users are many or few, as this depends ultimately on the individual case and the distribution across the various business units. Nevertheless, this measure shows that process weaknesses and shortcomings occur correspondingly frequently and can quickly go from being an exception to the norm. That is why the group of people affected needs to be quickly identified, above all to clarify: Is the group made up of a few power users or hundreds of end users?



You should have precise key performance indicators about what is happening in your SAP systems to derive the maximum possible benefits from them. Assumptions and estimations may ensure temporary calm, but they do not replace analyses based on experience. When combined with benchmarks and best practices, understandable key performance indicators can deliver valuable experience, which people would otherwise have to learn the painful way. The same as with someone endeavoring to get fit, who overdoes it in his first training session without knowledge of his own abilities…


Find more articles on this topic here.

Leave a comment

Your e-mail address will not be published. Required fields are marked *

13 − eight =