SAP Testing – Lücken schliessen ist angesagt

Theoretisch können und sollten Testdefinitionen bereits in der Requirementsphase abgeleitet werden, um später wirksam zu testen. Dies gilt auch für das Testen von Prozessen. Testen aber SAP-Anwender konsequent alle Prozesse, die im System von Änderungen betroffen sind? Trotz offensichtlicher Konsequenzen lautet die Antwort: Kaum einer.

Prozess-Modelle sind nicht auf dem aktuellen Stand
Viele SAP-Kunden treiben den Aufwand schon nicht, ihre Geschäftsprozesse so zu dokumentieren, dass daraus Qualitätsmassnahmen und Testingdefinitionen abgeleitet werden können. Aber selbst wenn es gemacht wird, zeigt sich, dass im Rahmen von SAP R/3 Implementierungen ein lauffähiges System erstellt wird, bei welchem die Prozessdokumentation schon während des Projekts nicht mehr nachgeführt und deshalb auch nicht aktuell ist.

Bei der Übergabe von SAP-Änderungen an den Betrieb ist damit ein konsequente und auf die Änderungen bezogen vollständiges Testen der Prozesse enorm aufwendig. Dadurch, dass die Zusammenhänge zwischen Änderungen und Prozessen nicht aktuell dokumentiert sind, bliebe nichts anderes übrig, als umfassend zu testen. So werden, wenn überhaupt, Prozesse unvollständig getestet. Das Prozess-Testing wird als „erfolgreich“ vollzogen abgehakt, weil die nötigen Voraussetzungen für solche qualitätssichernden Massnahmen inexistent sind! Die Folgen sind fatal. Bisher funktionierende Prozesse, die die selben Programme und Customizings nutzen, verhalten sich plötzlich anders. Andere Systemkomponenten im homogenen, oder mit noch mehr Konsequenzen im heterogenen SAP-System melden Fehler oder verweigern den Dienst.

In der SAP Customizing-Welt ist es zu komplex, zu aufwendig und zu wenig vom System unterstützt, zu dokumentieren, warum im System auf und ab Prozessebene die Dinge so sind, wie sie sind, ganz abgesehen davon, nachzuvollziehen, warum sie so geworden sind. Die Entwickler von neuen Funktionen und Änderungen orientieren sich in erster Linie an den unmittelbaren Projektzielen. Langfristige, qualitätssichernde Systemziele für den gesamten Lebenszyklus der betroffenen Anwendung sind im besten Fall sekundär.

Geschäftsprozess Lifecycle Management
Ein typisches SAP Business Blueprint-Dokument, ein SAP Prozessdokument, gibt auch nicht Auskunft darüber, ob einzelne Prozesse „bestehend und zu ändern“ oder „neu zu implementieren“ sind. Wird dies bei der Definition der Anforderungen an die Prozesse aber noch nicht unterschieden, kann zu diesem Zeitpunkt auch noch nicht festgelegt werden, ob und welche Auswirkungen auf Prozesse entstehen und später getestet werden müssen.

Dieser Misstand besteht auch beim Beseitigen von Problemen, also im Bereich des IT Service Management (ITSM). Hier fehlt dieser Bezug zum Lebenszyklus des Prozessobjekts ebenso.

Würde in den Projekten ein nachhaltiges Lifecycle Management für die Prozesse forciert, wäre klar ersichtlich, welches Entwicklungsprojekt oder welcher Service-Request, welche Version der Prozesse zur Folge hatte und welche Objekte dabei wofür verändert wurden. Die Auswirkungen für das Prozess-Testing könnten so frühzeitig erkannt und somit sauber geplant werden.

Im idealen SAP System initialisiert das erste Projekt die Geschäftprozesse. Jedes weitere Projekt oder jeder Service-Request mit Änderungen am Prozess, also Roll-ins, Roll-outs, Erweiterungen oder Fehlerbeseitigung, erweitert dann mit einer neuen Version der Geschäftprozesse das System inklusive der Auswirkungen für das Testing sauber und nachvollziehbar.

Fazit
Damit Testing im SAP-Umfeld nicht zur Alibiübung wird, muss für Projekte und Fehlerbeseitigungen sichergestellt sein, dass das Nachführen der Dokumentation auf Prozessebene als wesentlicher Bestandteil des Application Lifecycle-Management vollzogen wird. Nur so können alle Auswirkungen von Projekten auf den Geschäftsprozess und damit auf das Geschäftsprozess-Testing festgehalten und später für das Testing als Anweisung herangezogen werden.

Sinnvolles Prozess-Testing, im Rahmen des Integration- oder User Acceptance-Testing, muss am Geschäftsprozess ansetzen. Entwickler und Nutzer müssen vom Geschäftprozess ihre korrekten und vollständigen Testdefinitionen ableiten können. Der Bezug zum Testen muss somit schon bei der Arbeit mit dem Business Blueprint hergestellt und konsequent mitgepflegt werden. So können die Testing-Definitionen über das Projekt hinweg umfassend definiert und verfeinert werden. Meist genügen die so erhaltenen Testspezifikationen bereits als Testdefinition, zumindest können, darauf basierend, die Realisierung der endgültigen Test-Definition und das Test Scripting geplant und die Testaufwände geschätzt werden.

Das oben geforderte, konsequente, durchgängige Geschäftsprozess-Lifecycle Management erlaubt die geschäftskritischen Prozesse mit allen ihren abhängigen Objekten zu identifizieren. Dem Risikomanagement stehen entsprechend Informationen zur Verfügung, um solche Prozesse gesondert zu behandeln und beispielsweise intensiver zu testen.

Auch im SAP Umfeld kann richtig aufgesetztes Testing enorm Zeit, Ressourcen und somit viel Geld sparen. Auch Risiken können reduziert werden. Wird jedoch auf eine laufend aktuelle und eingebundene Prozessdokumentation und ein Prozess-Lifecycle Management verzichtet, ist mit jedem Projekt mit erheblichen und exponentiell wachsenden Mehrkosten zu rechnen. Im besten Fall ist es nur der ROI für die Investionen in System und Testing, der unerreichbar bleibt. Oft müssen aber ganze Systeme nach kurzer Zeit ersetzt werden.