Die es-muss-so-sein-wie-vorher Migration

Vor etlichen Jahren war ich mal lose Teil einer technischen Migration. SAP ECC EHP ganz-alt auf EHP damals-neu. Die Einführung lag schon ein paar Jahre zurück. Bis dahin wurde technischer Support geleistet. Keine neuen Features, maximal Support Hinweise wurden, soweit es ging eingespielt. Was zum damaligen Zeitpunkt aber schon nicht mehr so passierte. Im Grunde war das ECC-System fachlich und technisch auf einem veralteten Stand. Um wieder einen brauchbaren Mehrwert an die Fachbereiche zu bieten, wurde beschlossen das System erst technisch zu aktualisieren, dann fachlich neue Features zu nutzen. Das Hauptziel war im Grunde einen besseren Support für das System zu haben. Das Szenario kommt einen heute bekannt vor, nennt sich im S/4HANA Umfeld Brownfield. Hauptsache irgendwie aktualisieren wegen Support.

Auch damals waren die Vorgaben: was vor der Migration funktioniert, hat auch nach der Migration zu funktionieren. Das sollte jedem einleuchten. Nur war der Knappunkt bei dieser technischen Migration: Es musste exakt so funktionieren wie vor der Migration.

Die Vorgabe das es exakt so zu funktionieren hat kam von den Verantwortlichen. Es war ein Erfolgskriterium für die technische Migration. Das Wort exakt wurde exakt befolgt. Es war nicht so, dass ein Prozess zu funktionieren hatte, z.B. eine Freigabe, Anlegen oder Bearbeiten von einem Auftrag, etc. Die Anwendungen mussten genau so funktionieren wie davor. Bei Einführung hatte man aber schon so einige technischen Probleme mit workarounds gelöst. Im Standard gefundene Fehler hatte man mit eigenem Coding „gelöst“. Genau diese Fehler waren aber über die Zeit auch von SAP gelöst worden und nun Teil des neuen Releases. Prozessabläufe, die damals noch nicht so gingen wie gewünscht und die in der neuen Version aber funktionierten. SAP entwickelt ihre Software durchaus weiter, löst Bugs, bringt Verbesserungen. Man entschied sich jedoch diese Quick Wins zu ignorieren.

Exakt bedeutete hier: Fehler haben weiter ein Fehler zu sein. Ein Wahnsinn der durchgezogen wurde. Ein Fehler z.B. war, dass ein Wert (ich glaube das Datum), im damaligen SAP Standard falsch dargestellt / formatiert wurde. Die damalige Lösung: eine Anpassung programmieren. Nach der technischen Migration funktionierte der SAP Standard und die Darstellung korrekt, aber die Anpassung nicht mehr. Ergo: man wollte das auch die ursprüngliche Anpassung wieder funktioniert. Also: die Anpassung, die nur wegen dem damaligen Fehler überhaupt notwendig war und mit dem Update überflüssig. Anstatt die obsolet gewordene Anpassung rauszunehmen, wurde diese dann so angepasst das der Standard wieder den falschen Wert an die Anpassung übergab. Das war die praktizierte Realität. Bei einem Versand per E-Mail wurde auch eine damals implementierte Anpassung beibehalten. Die neue Standard E-Mail sah zwar besser aus, aber war halt nicht exakt die gleiche wie vor der Migration. Viele Leute waren wirklich damit beschäftigt die alten Anpassungen so anzupassen, dass sie auch dann noch funktionierten, wenn der ursprüngliche Grund nicht mehr gegeben war.

Exakt klingt nett und nach absolut notwendig. Aber man darf hier nicht vergessen: den Anwendern ist ein exakt durchaus egal. Sie wollen und brauchen eine Anwendung, die funktioniert, die sie unterstützt. Eine Anpassung, vor allem Workarounds, sollten immer wieder daraufhin untersucht werden. Was implementiert ist, um den eigenen Daseinszweck zu rechtfertigen, ist überflüssig. Anwender fragen bei Problemen: warum funktioniert das nicht? Warum kann ich meiner Aufgabe nicht nachkommen? Wenn die Anwendung schneller, einfacher, besser und intuitiver wird, ist die Frage eher nicht: kann man das wieder langsamer, komplizierter, schlechter und nur mit Zusatztraining nutzbar machen? Bei einer technischen Migration ist das Ziel sicherzustellen, das die Funktionalität weiterhin vorhanden ist. Der Prozess muss funktionieren. Wenn da jetzt ein Aufruf weniger notwendig ist, eine dann überflüssige App rausfällt oder sich die Darstellung geändert hat: das ist nicht wichtig. Konnten die Anwender davor einen Auftrag anlegen, eine Anfrage freigeben, so hat dies auch danach zu funktionieren. Die unabdingbaren Informationen müssen weiterhin angezeigt werden. All das hat zu funktionieren nach einer technischen Migration. Wenn es exakt wie vorher zu funktionieren hat, dann kann man sich den Aufwand einer technischen Migration auch sparen. Der Grund der Migration ist ja gerade das es nicht mehr exakt wie vorher funktionieren soll.