Ein schreiender Manager machte in den letzten Tagen Schlagzeilen. Ernst Prost, Geschäftsführer der Liqui Moly GmbH in Ulm, hatte sich laut schreiend fotografieren lassen. Der Grund für seine Wut ist, dass seit der Umstellung auf ein neues ERP-System in seinem Unternehmen nichts mehr läuft. Die FAZ meint dazu, dass das Thema Software-Umstellungen nicht nur Prost, “sondern auch viele andere Unternehmenschefs zur Weißglut treibt”.
Einer Pressemitteilung des Unternehmens, mit der auch das Bild des wütenden Chefs verbreitet wurde, kann man entnehmen, dass Fehler und Probleme in der neuen Software für das Chaos verantwortlich wären. Sicherlich gibt es bei der Einführung neues Software immer Situationen, in denen Fehler auftreten, die zuvor trotz intensiver Tests nicht entdeckt worden sind. Aber wie kann es kommen, dass durch die Umstellung auf eine neue Software ein ganzes Unternehmen ins Schleudern gerät.
Wenn ein Einzelner über Jahrzehnte eine Software betreut
Ein Satz im FAZ-Bericht gibt einen interessanten Hinweis. Dort heißt es:
Während aber die alte IT auf Cobol-Basis von einem einzigen Mitarbeiter am Laufen gehalten wurde, hakt es jetzt an allen Ecken und Enden
Was so klingt, als sei die alte Software um vieles besser gewesen als das neue System, verweist in Wirklichkeit darauf, dass die Probleme womöglich eher in der Vergangenheit liegen. Oft werden nämlich in Unternehmen tatsächlich individuelle Lösungen von einzelnen Experten über Jahrzehnte gepflegt, erweitert, verändert, ergänzt. Auf Zuruf und oft dringend wird immer wieder an einzelnen Modulen programmiert, werden Algorithmen für spezielle Fälle angepasst, wird hier und da noch eine Besonderheit eingebaut.
Es entsteht ein unübersichtliches System, von dem niemand mehr weiß, was es wirklich tut, was davon überhaupt noch gebraucht wird und unter welchen besonderen Umständen welche spezielle Bedingung zu einem einzelnen Ergebnis führt. Am Ende weiß jeder nur: Es läuft irgendwie, und so, wie es läuft, ist es auch gewollt.
Solche Systeme sind nur selten dokumentiert, die Geschäftsanforderungen stehen nirgends als im Programmcode, keiner weiß noch, welche Anforderungen wann zu welcher Funktion beigetragen haben.
Wenn ein neues System spezifiziert wird
Leider erinnert sich auch keiner an diese vielen Einzelfälle und Besonderheiten, wenn es an die Anforderungsanalyse für das neue System geht. Da werden oft nur die Standardfälle beschrieben, die vielen Ausnahmen werden eher zufällig aufgeführt. Dass der alltägliche Geschäftsprozess vor allem aus Ausnahmen besteht, will da nur selten jemand wahrhaben. Es herrscht das Prinzip Hoffnung: Wenn wir das neue System erst mal haben, gibt es diese Ausnahmen vielleicht auch nicht mehr.
Die Ernüchterung folgt in der Praxis, wenn die gewohnten, optimierten und vertrauten Geschäftsprozesse auf die neue Software treffen, die von all den Ausnahmen nichts weiß. Dann fällt den Mitarbeitern plötzlich auf, dass in diesem speziellen Fall ja jene Ausnahmebedingung gilt, dass man ja vor Jahren den einzigen Programmierer gebeten hatte, in der Situation die Schnittstelle so anzupassen, dass jenes Feld ja manchmal doch einen anderen Wert enthalten kann usw. usf.
Gerade für Altsysteme endlich ein Anforderungsmanagement einrichten
Ob die Probleme bei Liqui Moly von dieser Art sind, weiß ich nicht. Aber die Geschichte sollte jedem, der mit jahrzehntealten “gewachsenen” Software-Lösungen arbeitet, eine Lehre sein: Endlich ein Anforderungsmanagement einzurichten, das möglichst auch rückwirkend alle Spezialfälle, Besonderheiten, Anpassungen, Änderungen und Erweiterungen am System Stück für Stück dokumentiert. Auf dieser Basis kann man bei der Einführung einer neuen Lösung dann zweierlei machen:
- Vollständige Anforderungsdokumentationen für die neue Software erstellen
- Für Spezialfälle, die von der neuen Software nicht abgedeckt werden, rechtzeitig Änderungen in den Geschäftsprozessen vornehmen.
Und dann klappt es auch mit der neuen Software.