Copyright 2024 - BV TallVision IT

Where solutions are implemented that are a little larger than normal, the concept of Health check report or Diagnostics report should be introduced.


SAP implementations are never perfect. They are implemented by people. No shame of course, but a simple fact that should be accepted and for which a safety net approach can be set up quite easily. For many problems an investigation will include the query "how often does this happen" - which invloves chacking table content using transaction SE16(n). Where these selections become time consuming and involve multiple tables, the actual knowledge on how to check a certain problem can become something the sysyem needs to hold by itself. The health check report should handle them. Health check reporting is a very effective way to position knowledge on problems into the system, in the form of a check that can be re-applied over and over again. Instead of a virus scanner - you would have an automated health scan.

Goal and objectives

The goal of the Health check reports is to present a platform where known problems are made visible. Let go of the assumption that everything is correct, and focus on selecting business objects that have problems. Diagnose your system and focus on the oddball cases. When a given problem is targetted (reported) action can be undertaken and the sheer size of the problem will be clear.

The blue print

A simple report where key fields for the interrogated business object (e.g. the Purchase Order) is set up. The report will select all relevant data needed to perform a health check, for which some examples are listed here:

  • Purchase orders that are over 3 months old and still not released
  • Purchase order items with a delivery date well in the past
  • Open Purchase Order has had no changes at all done to it in the past month
  • Unreleased purchase orders for which no active workflow inbox entries are available (for systems that use workflow for PO processing)
  • 5% of last months PO's are marked for deletion, and the month before this was 6%...
  • Add new diagnostics messages as you find them.. (in ABAP coding)

Taking it further...When a program is developed which tracks down problems, can an addition be added to fix the problems ? Of course this will depend on the actual problem and this will need to be looked at for every problem found. First of all effort should be put in making sure the problem doesn't occur at all and the safety net of a health check (with fix) can do the rest. In effect, in the lifecycle of a diagnostics problem, diagnostics problems will eventually only be reported if for some reason the problem re-occurs. So effectively we are reporting on "issues from the past" making sure they have not returned. A nice guarantee (so leave old diagnostics in, as they serve a purpose). 

And a little further... If you look at the reports developed, you may come to the conclusion that some (or many) of the reports are actually set up as health-check already. "Report on the overdue orders that such and such" could well be a report that is already available. From a system support point of view, these reports are all in the same family and even though they can be about very different business objects, they could all be in the same daily checklist. A developer could emphasize this by setting up a "Family" tab on the selection screen, linking to all related health check reports.

Pro's and cons

  • Monitor how the system is coping with known problems
  • Resolve a problem once - get the problem solved many times
  • Valuable asset to a stable implementation
  • ABAP development required
  • After the fact approach

Success story

The blood report where the process of shipping was reported, marking trouble-columns in red. "Diagnostics report", "Vendor without timezone", "Purchase order without output", "Tasks and flows", there are many many members in the health check family on every system implemented..