Warum IT-Großprojekte häufig scheiternDer Mangel an Generalisten
27. September 2019
Immer wieder ist zu lesen, dass IT-Großprojekte scheitern, wie etwa die Bildungsplattform „ELLA“ des Landes Baden-Württemberg oder die „IT-Konsolidierung Bund„, bei der der Rechnungshof nach mehr als 400 Millionen Euro verplanter Investitionen den Stecker gezogen hat. Aber auch die Privatwirtschaft hat so ihre Probleme mit den IT-Projekten, wie etwa Lidl (ca. 500 Millionen versenkt) oder Liqui Moly. Eine der möglichen Ursachen für diese Fehlleistungen kann man auch in den Trümmern des ehemaligen Klosters von Cluny finden.
Solche Projekte sind wie die drei Akte eines griechischen Dramas: Hybris, Katharsis, „aus is“: Die ehrgeizigen Mönche von Cluny wollten im Jahr 1000 n. Chr. die größte Kirche des christlichen Abendlandes (Hybris) bauen. Dann stürzte der Mammutbau im Jahr 1125 ein (Katharsis). Der Grund: Die in der zeitlich späteren Gotik (von ca. 1250 bis um 1500) verwendeten Strebe- und Spitzbögen waren noch nicht erfunden. Das heißt, die zur Gründungszeit verfügbare Architektur für so ein großes Bauwerk war nicht geeignet und es gab keinen Architekten, der das hätte erkennen können. Und aus war‘s mit dem großen Kirchenbau bis zum endgültigen Abriss während der französischen Revolution.
Ein ähnliches Schicksal erleiden heute viele IT-Projekte. Hunderte IT-Spezialisten werkeln gleichzeitig an und in mehreren riesigen Programmen. Allein ihnen fehlt der Plan vom Ganzen. Kein Wunder! So etwas wurde ihnen auch noch nie gezeigt oder gar gelehrt. Weder in irgendwelchen Aus- und Weiterbildungsinstituten noch an Hochschulen oder Universitäten. Alles was die Spezialisten kennen, sind „klein-klein“-Diagramme aus der Anfangszeit in den 1960er Jahren und ein paar Derivate davon. Allerdings waren die Computer damals auch noch sehr klein und die Programme, naja, sehr bescheiden im Vergleich zu heute.
Woran erkennt man die Architektur einer Software
Eines der besten Beispiele für eine gute, beständige und trotzdem flexible Struktur ist die doppelte Buchführung. Die besteht zwar – genau wie programmierte Software – zunächst nur aus ein paar Rechenregeln, aber diese Konstrukte (Soll und Haben, Debitoren-, Kreditoren-, Sachkonten, Gewinn&Verlust, Bilanz) bilden zusammen eine Architektur, die die Jahrhunderte und mit ihnen alle Veränderungen der Wirtschaft und der Gesellschaften überdauert hat. Genauer, seit 1492, als der italienische Mathematiker und Mönch Luca Pacioli das Prinzip der doppelten Buchführung aufgeschrieben hat.
In der Architektur eines Buchhaltungssystems ist die Bilanz ganz oben. Sie bildet sozusagen das Dach, das alles überspannt. Wer jetzt denkt, das ist ja ganz einfach, vielleicht zu einfach, der hat noch nie eine Weltbilanz eines multinationalen Konzerns mit -zig Gesellschaften gesehen.
Gleich unterhalb der Bilanz ist die G&V, die Gewinn- und Verlustrechnung. Ihr Ergebnis, eine Zahl mit einem Vorzeichen, ist nur ein Baustein in der Bilanz. Darunter wiederum, rein logisch betrachtet, liegt das Hauptbuch mit seinen beliebig vielen Konten. Und damit das nicht zu viele Konten werden, liegen darunter noch die Debitoren- und die Kreditorenkonten. Alles schön hierarchisch angeordnet. Aber das Beste daran ist, dass in dieser Architektur ein Regularium eingebaut ist, das jeden Fehler sofort erkennt: Ist Soll minus Haben ungleich Null gibt es einen Alarm!
Das ist nur ein Beispiel für eine Systemarchitektur. Tausende verschiedene Buchhaltungssysteme haben genau diese Architektur und nur ganz, ganz selten wurde Kritik daran laut. Diese Architektur verträgt viele Schnittstellen, z.B. nach „oben“ zur Konsolidierung innerhalb einer Unternehmensgruppe oder von „unten“ aus der Fakturierung oder Rechnungsprüfung. Ein Buchhaltungssystem sieht aus wie jedes andere IT-System auch, nur dass es sozusagen „unkaputtbar“ ist. Die Einfachheit der Architektur, die dadurch gewonnene Robustheit und die eingebaute Selbstkontrolle sorgen für einen reibungslosen Betrieb.
Die Struktur von ERP-Systemen
Auffällig an der aktuellen Diskussion ist, dass viele abgebrochene oder „verunglückte“ IT-Projekte im Kern ein ERP-System haben, das – natürlich auf Wunsch der Anwender – „ein bisschen“ auf deren Vorstellungen angepasst wurde. Pech dabei war nur, dass niemand auf die Architektur des ERP-Systems geachtet hat. Vielleicht, weil keiner wusste, dass es so etwas überhaupt gibt, vielleicht, weil keiner verstanden hat, wie ein ERP-System generell funktioniert.
ERP-Systeme haben, ähnlich wie Buchhaltungssysteme ein eingebautes Kontrollsystem:
Bedarf – Bedarfsdecker = Null.
Da das praktisch nie der Fall ist, ist das System immer in Bewegung. Das „Oben“ eines ERP-Systems ist dort, wo sich die Disposition befindet. „Unten“ ist das Lager, das die ständigen Ungleichheiten zwischen Bedarf und Bedarfsdecker puffert. Wareneingang und Versand fungieren quasi wie die Nebenbuchhaltungen zur Hauptbuchhaltung. Sie liefern die Bewegungsdaten.
Vielleicht wird es durch diesen Vergleich verständlicher, dass schon kleinste Eingriffe in diese Systematik zu Störungen und Unstimmigkeiten (in dieser Gleichung) führen können. Vielleicht liegt aber auch gerade darin der Reiz, wie beim Bergsteigen „am Rande des Abgrunds“ ein bisschen herum zu programmieren.
Es könnte auch daran liegen, dass den „Programmierern“ noch nie jemand die Einfachheit und Ausgewogenheit eines funktionierenden ERP-Systems gezeigt hat. Schon seit den Anfängen der kommerziellen Datenverarbeitung wird versucht, die Software und Systeme irgendwie „ins Bild“ zu setzen, da sie ja aus purer und unsichtbarer Mathematik bestehen.
Herausgekommen ist bei den vielen Versuchen fast immer dasselbe: Kästchen, Sternchen, Kreise, Pünktchen und Striche, genannt Vektoren. Ob es die (frühen) Flussdiagramme in den 1960er Jahren waren, die filigranen Symbole von UML oder die bunten Klötzchen von ARIS – gemeinsam ist allen diesen Methoden und Tools, dass sie immer „ganz unten“, bei der Logik das Programmcodes anfingen, irgendetwas zu zeichnen. Im Prinzip wird nicht viel mehr dargestellt als die Primäroperationen „und“, „oder“, „nicht“.
Von oben nach unten und von außen nach innen
Geht man in der Geschichte der IT ein paar Jahre zurück, sieht man, dass sehr viele Systeme „von innen nach außen“ gewachsen sind, von einer kleinen Programmschleife zu (fast) unbeherrschbaren Mammutsystemen. Das wachsende Unbehagen großen IT-Systemen gegenüber kommt nicht von ungefähr: Man kann die Systeme nicht sehen. Die vielen Versuche, Software zu visualisierten und in ihrem Umfeld der Anwendung und Anwender darzustellen, sind immer wieder an der mangelnden Orientierung gescheitert. Für das, was bei einer Software „oben“ und „unten“ sein soll oder „außen“ und „innen“ gibt es keine Definition oder Festlegung. Und so sieht jedes Bild von Software oder Softwaresystemen anders aus. Es ist ein babylonisches Icon-Gewirr.
Dabei ist der Gedanke, Software zu visualisieren sehr zu begrüßen, denn Graphiken erleichtern und unterstützen die Kommunikation. Damit sich Anwender und IT-Spezialisten auch verstehen, wenn sie dasselbe Bild eines Softwaresystems betrachten, sollte es ein paar gemeinsame Regeln geben eben für das, was „oben“, „unten“, „links“ und „rechts“ dargestellt sein soll. Eine Orientierung eben.
Es gibt ganz natürliche Orientierungspunkte, die auch für eine Abbildung der realen Welt in der Software verwendet werden können. Da in unseren „Längengraden“ von links nach rechts gelesen wird, ist der „Einstieg“ in die Darstellung, der Ausgangspunkt links. Speziell für ERP-Systeme könnte das genutzt werden. Der Ausgangspunkt aller Geschäftsprozesse ist der Kunde. Und der, bzw. sein digitales Abbild, der Bedarf, steht links.
Oder: In jedem Unternehmen ist der „Chef“ (Vorstand, Geschäftsführer) in den obersten Stockwerken untergebracht. Übertragen auf „Unternehmenssoftware“, also ERP-Systeme, residiert die Steuerung, das Rechnungswesen, oben. Unten befindet sich der Keller, also das Lager und der ganze Warenverkehr mit Eingang und Versand. So kommt man einer verständlichen Darstellung eines ERP-Systems schon näher. Fast möchte man mit Goethe sagen. „Es trägt Verstand und rechter Sinn mit wenig Kunst sich selber vor“. Mit diesen Orientierungspunkten entstand schon in den 1990er Jahren der GPS Software-Atlas, ein sehr anschauliches und verständliches Werk über software-gesteuerte Unternehmensprozesse.
Werner Schmid ist Senior Consultant bei der GPS Gesellschaft zur Prüfung von Software mbH, Ulm
