Warum die größte SAP-Einführung Deutschlands kein IT-Projekt war

Als ich 2012 zu Herrenknecht zurückkam, hieß meine Rolle Programm-Manager, nicht CIO. Ich saß an einer Stabsstelle beim Vorstand, und der Auftrag lautete nicht „führen Sie SAP ein“. Er lautete: Die Prozesse im Konzern sollen zusammenpassen, über alle Standorte hinweg. Dass daraus die zu diesem Zeitpunkt größte SAP-Einführung Deutschlands wurde, stand am Anfang auf keinem Blatt. Das System war die Konsequenz aus der Prozessfrage, nicht ihr Auslöser.

Diese Reihenfolge ist aus meiner Sicht der Hauptgrund, warum das Programm funktioniert hat. In vielen Unternehmen läuft es andersherum. Erst wird ein System ausgewählt, weil das bestehende ausläuft oder weil der Wettbewerber es auch hat. Dann stellt jemand fest, dass die eigenen Abläufe nicht dazu passen. Und dann beginnt der eigentliche Konflikt, nämlich die Frage, welcher Standort sich bewegt. Nur führt man ihn zu diesem Zeitpunkt unter Zeitdruck und mit einem laufenden Vertrag im Rücken. Wir hatten diesen Konflikt vorher, und das war unangenehm genug.

Die wichtigste Entscheidung war eine Personalentscheidung

Bei der Besetzung der Projektteams haben wir stärker auf Soft Skills geachtet als auf technische Qualifikation. Das war intern nicht populär, weil es der üblichen Logik widerspricht: Wer ein Modul im Detail kennt, gilt als der naheliegende Kandidat für das Modulteam.

Meine Erfahrung ist eine andere. Ein Kollege, der ein SAP-Modul auswendig kennt, im Werk aber keine Tür geöffnet bekommt, bringt ein Programm nicht voran. Er produziert Spezifikationen, die fachlich sauber sind und an denen die Fachbereiche vorbeiarbeiten. Umgekehrt lässt sich Modulwissen aufbauen, und zwar in Monaten. Die Fähigkeit, in einer Werkshalle eine halbe Stunde lang zuzuhören, bevor man den ersten Vorschlag macht, lässt sich deutlich schlechter nachschulen.

Diese Entscheidung kostet etwas. Man beginnt langsamer, weil ein Teil des Fachwissens erst entstehen muss, und man braucht externe Unterstützung länger, als es der Plan vorsieht. Dafür bekommt man Projektmitarbeiter, denen die eigene Organisation glaubt. Über die Jahre eines Programms wiegt das schwerer.

Drei Tage über Kultur, bevor über Prozesse gesprochen wurde

Ein erheblicher Teil des Programms lag in Asien, mit China als Schwerpunkt. Wir haben dreitägige Workshops zur Zusammenarbeit angesetzt, für die deutsche Seite und für die chinesische Seite.

Wer schon einmal ein Projektbudget verteidigt hat, weiß, wie dieser Posten aussieht: drei Tage, mal die Zahl der Beteiligten, mal Reisekosten, und am Ende steht kein einziger konfigurierter Prozess. Ich habe diese Workshops trotzdem durchgesetzt und würde es wieder tun.

Der Grund liegt in dem, was ohne sie passiert. Deutsche Projektleiter interpretieren ein Nicken als Zustimmung und eine ausbleibende Rückmeldung als Einverständnis. Auf der chinesischen Seite kann beides das Gegenteil bedeuten, ohne dass jemand die Absicht hätte, etwas zu verschleiern. Wenn man diese Differenz nicht vorher bearbeitet, merkt man sie zum ersten Mal beim Testlauf, und dann ist der Termin schon verloren. Die drei Tage waren billiger als eine verschobene Inbetriebnahme.

Wichtig war dabei, dass beide Seiten den Workshop bekommen haben. Ein interkulturelles Training nur für die Zentrale wäre eine Belehrung gewesen, und als solche hätte man es in Asien auch verstanden.

Nach elf Monaten kam die IT-Verantwortung dazu

Elf Monate nach dem Start habe ich zusätzlich die Rolle des CIO übernommen. Der Anlass war nüchtern: Der Vorstand sah die IT als Bremse der digitalen Transformation. Von da an habe ich zwei C-Level-Rollen parallel geführt, das Programm und eine IT mit 84 Mitarbeitern in einem Konzern mit 5.000 Beschäftigten.

Rückblickend war diese Bündelung nützlicher, als sie zunächst aussah. Ein Programmleiter ohne IT-Verantwortung verbringt einen guten Teil seiner Zeit damit, Prioritäten in einer Abteilung durchzusetzen, die er nicht führt. Jede Terminverschiebung wird zu einer Eskalation, jede Eskalation kostet Vertrauen auf beiden Seiten. Mit beiden Rollen in einer Hand fiel dieser Weg weg. Zugleich stand ich dann selbst in der Verantwortung, wenn die IT nicht lieferte, und konnte den schwarzen Peter nicht weitergeben. Das hat die Diskussionen in der Geschäftsleitung erheblich verkürzt.

Was daraus für ERP-Vorhaben folgt

Wenn ich heute in ein Unternehmen komme, in dem eine ERP-Einführung stockt, finde ich die Ursache selten im System. Meist liegt sie an einer dieser Stellen.

• Die Prozessentscheidung wurde vertagt. Es gibt keinen verbindlichen Zielprozess, sondern eine Sammlung von Standortvarianten, die im Customizing abgebildet werden sollen. Damit baut man die alte Organisation neu, nur teurer.
• Die Fachbereiche stellen die falschen Leute ab. Ins Projekt geht, wer im Tagesgeschäft am ehesten entbehrlich ist. Das ist verständlich und ruiniert das Ergebnis.
• Die Geschäftsleitung hat das Vorhaben delegiert. Ein Konzernprogramm, das nur in der IT verankert ist, hat keine Instanz, die Konflikte zwischen Bereichen entscheidet. Also werden sie nicht entschieden.

Keiner dieser Punkte ist ein technisches Problem, und keiner löst sich dadurch, dass man den Implementierungspartner wechselt. Es sind Führungsthemen, und sie gehören auf den Tisch der Geschäftsleitung.

Deshalb frage ich in einem Mandat zuerst nach dem Lenkungskreis. Wer sitzt darin, und wann hat dieses Gremium zuletzt eine Entscheidung getroffen, die einem Standort wehgetan hat? Die Antwort sagt mir mehr über die Erfolgsaussichten als jeder Statusbericht.