Stell Dir vor…
In den Nachrichten und Schlagzeilen ist von nichts anderem mehr die Rede als dem wahrscheinlichen und nun Realität werdenden Einschlag eines Monster-Asteroiden auf der Erde? Wie würdest du dieser lebensbedrohlichen Gefahr entgegen treten? Wie würdest du überleben?
Du bräuchtest eine ausgeklügelte Waffe, die die großen Felsen zerstört, lange bevor sie auf die Oberfläche treffen. Kleinere Gesteinsbrocken könnten die Menschen möglicherweise verletzen, aber die Menschheit nicht auslöschen. Das wär’s! Aber haben wir eine solche Waffe?
… und was hat das mit SAP zu tun?
Wenn wir uns deine bevorstehende S/4HANA-Transformation ansehen, fühlt sich die schiere Anzahl der kommenden SAP-Standardänderungen an wie Asteroiden, die auf die Erde prallen, und die Folgen können für dein Business dramatisch sein, wenn du nicht über eine wirksame Waffe verfügst, um die Auswirkungen der Änderungen zu verstehen und die Risiken entsprechend zu mindern. Nicht nur bei der S/4HANA-Transformation, sondern bei jedem größeren SAP-Projekt ist dies der Fall. Die folgenden Fragen müssen im Vorfeld beantwortet werden:
- Welche Auswirkungen auf die Benutzer gibt es? Welche Business-Bereiche sind von den Änderungen an den Prozessen und Benutzeroberflächen betroffen?
- Welcher kundenspezifische Code wird angegriffen? Im Durchschnitt hängt etwa ein Drittel der Business-Funktionen von kunden-konfiguriertem Code ab.
- Welche Auswirkungen hat das auf andere Systeme, die mit SAP verbunden sind? Die Lieferketten sind in der Regel mit anderen Datenhaltungssystemen integriert.
- Was sind die Auswirkungen auf die Sicherheit? Deine Rollen, Berechtigungen und Profile werden sich ändern. Wie kannst du sicherstellen, dass kritische Daten vor unberechtigtem Zugriff geschützt sind?
- Wie kannst du das Datenvolumen genau bestimmen und einen performanten Betrieb in Zukunft sicherstellen?
Welche Daten können bei einer Umstellung auf S/4HANA ausgemustert werden?
Warum ist es so wichtig, die Auswirkungen von Veränderungen zu verstehen?
Neben der höchstkomplexen S/4HANA Transformation bestehen SAP Deployments in der Regel aus
- SAP-Standardänderungen wie SAP Support- oder Enhancements-Packs.
- SAP-Anpassungen, die typischerweise als Z-Transaktionen bezeichnet werden.
- Eine Kombination aus beidem gleichzeitig.
Es ist in jedem Szenario wichtig, genau zu verstehen, WELCHE Objekte sich ändern und WIE sie mit deinen Geschäftsprozessen verbunden sind. Nur wenn man das genau versteht, kann man den Testaufwand und damit das Risiko für das Release reduzieren. Die Reduzierung des Testaufwands hat auch mit Testautomatisierung zu tun. Nicht diejenige mit den meisten Testfällen gewinnt, sondern diejenige, der mit den wenigsten Testfällen die meisten Risiken abdeckt, also die richtigen Dinge automatisiert hat!
Andersherum: Du hast heute vielleicht eine Vorstellung davon, welche Geschäftsvorgänge von den Änderungen betroffen sind, aber das Wissen über die genauen Auswirkungen und potentiellen Nebeneffekte bleibt vage. Darum entscheidest Du dich heute für den "Test all"-Ansatz. Die Nachteile dieser Wissenslücke sind vielfältig:
- Ein "Test all"-Ansatz in der gesamten SAP-Landschaft ist einfach nicht realistisch. Erstens werden viele Funktionen in deiner Umgebung vielleicht gar nicht aktiv genutzt, aber wo soll man die Grenze zum Testen ziehen? Zweitens: Wer würde all diese Aufgaben übernehmen? Kannst du den Fachleuten aus dem Betrieb noch mehr Testaufwand aufbürden?
- Die Schlüsselanwender müssen mehr Zeit aufwenden, um Dinge zu testen, die vielleicht gar nicht betroffen sind.
- Die Anzahl der Releases kann durch den massiven Testaufwand nicht erhöht werden. Das Testing scheint der Flaschenhals zu sein.
- SAP-Standardreleases werden hinausgezögert, da sie von den Auswirkungen her die kritischsten sind. Zu viele Änderungen, zu viel Unsicherheit machen Dich zögerlich. Sie bringen nicht sofort einen Business-Vorteil. Lieber später machen. Aber das bringt den nächsten Nachteil mit sich: Die Chargengröße wird immer größer, das Risiko steigt. Das nächste ungeliebte Transformationsprojekt steht an.
Eine stichhaltige Analyse der Abhängigkeiten kann diese Probleme überwinden.
Welche Waffe soll es nun richten?
Klingt toll, du musst nur die Abhängigkeiten und Auswirkungen verstehen und schon bist du auf der sicheren Seite. Aber WIE funktioniert das eigentlich? Eines ist klar: Angesichts der technischen Komplexität einzelner Deployments ist es in den meisten Fällen alles andere als einfach zu verstehen, was zu testen ist. Was kannst du also tun, um Erkenntnisse zu gewinnen?
Die erste Möglichkeit ist, eine Armada von SAP-Beratern damit zu beauftragen, die Auswirkungen zu ermitteln. Das ist zeitaufwändig und daher kostspielig. Aber was ist mit all den täglichen SAP-Transporten, von kleineren Patches über benutzerdefinierte Änderungen bis hin zu Support und Enhancement Packs? Die Berater mögen weg sein, das Problem bleibt.
Die andere Antwort: Du brauchst einen permanenten Tool-Support. Du musst dich zuerst mit den technischen Auswirkungen befassen, um zu verstehen, wie sich diese auf die Geschäftsprozesse auswirken. SAP hat im Vergleich zu anderen Plattformen einen Vorteil: Seine Codebasis ist zugänglich. Das ermöglicht es den Tools, Änderungen von einem Deployment zum nächsten aufzudecken. Und das hilft dir, den Testbedarf zu verstehen.
Schlussbemerkung
Heute haben wir festgestellt, dass es zu jeder Zeit im SAP-Lebenszyklus wichtig ist, die Auswirkungen von Änderungen zu verstehen - während einer S/4HANA-Transformation, aber auch im normalen Betriebsmodus, wenn Support Packs oder benutzerdefinierte Codeänderungen eingeführt werden. Wenn du den Testaufwand für wichtige Benutzer/innen reduzieren und gleichzeitig mit den regelmäßigen SAP-Releases Schritt halten willst, verschafft dir ein Tool zur Auswirkungsanalyse die nötigen Einblicke.
Beim Werkzeugeinsatz kommt es darauf an, wer es in der Hand hat und mit welcher Präzision es zum Einsatz kommt.