Die Ausgangsbasis: Das Einspielen von SAP-SupportPacks bereitet immer Kopfzerbrechen. Welche Teile der genutzten Prozesse sind betroffen? Was muss getestet werden? Wieviele Resourcen sind nötig? Welche Eigenentwicklungen sind betroffen? Dies ist nur ein Ausschnitt der Fragen, die man im Normalfall nicht beantworten kann. All dies führt dann in der Praxis zur Entscheidung “Alles” zu testen.
Die Erfahrung
Im Zuge meiner Tätigkeit komme ich mit vielen SAP-Kunden zusammen und stelle dann u.a. folgende Fragen: Was bedeutet “alles testen”. Alle Prozesse? Alle genutzten Teile im System? Wer hat denn eine Liste davon? Eine der häufigsten Antworten auf diese Fragen ist ?Unsere Keyuser wissen das schon?. Etwas überzeichnet ausgedrückt läuft die Qualitätssicherung dann so ab: die Basis spielt die Packages am Test-System ein, sendet daraufhin Montagmorgen ein e-mail an alle Key-User mit der Bitte zu testen und dem Zusatz “sollten wir bis Freitag Mittag nichts hören, dann gehen wir davon aus, es wurden keinerlei Fehler gefunden und gehen live”. Wir wissen wozu dieses Vorgehen führt.
Die Zukunft
Als moderne IT ist man Dienstleister innerhalb des Unternehmens. Ist es zulässig, die Qualitätssicherung ganz zum Kunden auszulagern, also allein dem Keyuser zu überlassen, ohne den Prozess der QS in der Hand zu haben, ohne diesen messen zu können? Auch schauen immer mehr Wirtschaftsprüfer und Auditoren auf diesen Prozess und dessen Dokumentation. Aber wie lässt sich der Change-Management Prozess kostengünstig und ohne große Reibungsverluste implementieren. Können eventuell sogar Einsparungen aufgezeigt werden?
Eine Lösung
Der Weg den wir gehen, besteht aus 2 Hauptkomponenten:
1. schrittweise Einführung: Den Kunden dort abholen wo er steht, und in kleinen Schritten, die auch immer schon einen sichtbaren Mehrwert bringen, den QS-Prozess erweitern.
2. Automatisierung. Hier ist nicht (nur) die Automatisierung von Testfällen gemeint, sondern der gesamte Change-Management Prozess.
Von der Auswahl der einzuspielenden Pakete, über die Impact-Analyse bis hin zur Generierung der durchzuführenden Testfälle. Entscheidend ist immer den gesamten Prozess im Auge zu behalten. Auch bei kleinen Schritten, beispielsweise der Einführung einer Impact- und Risikoanalyse, ist immer zu bedenken, dass diese irgendwo stattfinden muss und dass die Ergebnisse verwendet werden. All dies muss immer durch begleitende Maßnahmen gemonitored werden (vgl. auch ITIL).
Für die Risiko- und Impact- Analyse gibt es zur Zeit mehrere Tools am Markt. IntelliCorp’s LiveCompare mit dem Assessor SupportPack Template hat sich als die flexibelste Lösung herausgestellt, da damit eine nahtlose Integration sowohl in SAP als auch in Test-Werkzeuge wie die HP-Toolsuite, der SAP-Solution Manager oder andere.
Dieser blog ist auch bei unserem Partner beteo erschienen und dort auch auf englisch abrufbar.
Atom Feed
