ERP-Projekte sind keine IT-Projekte

Der Autor ist Managing Partner bei Zellweger Management Consultants in Pfäffikon (SZ), spezialisiert auf Reorganisations-, Proessoptimierungs- und ERP-Projekte. Die Liste mit Literatur zur erfolgreichen Durchführung von ERP-Projekten ist lang und doch sind die Resultate in der Praxis ernüchternd. Laut einer von uns durchgeführten Umfrage aus dem Jahr 2010 werden 35 Prozent der ERP-Projekte teurer als geplant, bei 57 Prozent wird der Terminplan nicht eingehalten und 75 Prozent aller Systeme werden nach der Einführung punkto Anpassungs­fähigkeit als problematisch eingestuft. Es besteht also eine beachtliche Diskrepanz zwischen Erwartungen und Ergebnissen. Warum bringen ERP-Systeme nicht den erhofften Nutzen? Die How-to-Literatur behandelt das Thema mehrheitlich aus der IT-Optik und liefert Tipps und Tricks für eine erfolgreiche Implementierung. Diese Sichtweise greift aber zu kurz, denn sie betrachtet die Aufgabe aus dem falschen Blickwinkel.

ERP-Systeme basieren auf Software, das verleitet zu einer folgenschweren Fehlüberlegung. ERP-Projekte sind jedoch keine IT-, sondern Business-Projekte. Die Abkürzung ERP steht für Enterprise Ressource Planning. Es handelt sich also um Systeme, die das ganze Unternehmen betreffen – Strukturen, Organisation und Prozesse – und die Operational Excellence vorantreiben sollen. ERP-Projekte bieten die Gelegenheit, historisch gewachsene Komplexität zu reduzieren. Das zahlt sich gerade bei der Ablösung von Legacy-Systemen aus. Strukturen und Prozesse zu optimieren, kann und soll jedoch nicht Aufgabe der IT-Abteilung sein. Die Projektverantwortung muss bei der Geschäftsleitung und in der Linie liegen. Die IT-Abteilung spielt nur eine unterstützende Rolle, sie sichert die Machbarkeit und den Abgleich mit der IT-Strategie. Leider nutzen nur wenige Unternehmen diese grosse Chance. Die meisten gehen stattdessen vom Istzustand aus und versuchen, diesen mit dem neuen ERP-System nachzubilden und allenfalls zu automatisieren. Das hat gravierende Folgen: Die 1:1-Abbildung bestehender Strukturen und Prozesse führt zu einem zwangsläufig komplexen und zudem rückwärtsorientierten ERP-System. Das verursacht während der Einführung teures Customizing und später hohe Folgekosten für Anpassungen, Wartung und Unterhalt. Wenn das ERP-System schon bei seiner Einführung unnötig komplexe Strukturen abbildet, kann es auch nicht flexibel auf künftige organisatorische Veränderungen reagieren und macht jeden ERP-Releasewechsel zur Zitterpartie. Das Resultat: Das ERP-System wird nicht zum Treiber von Operational Excellence, sondern zum Bremser.

Lesen Sie auf der nächsten Seite: Vom Umgang mit Komplexität

ERP-Projekte werden sinnvollerweise in drei Phasen unterteilt: Zielzustand, ERP-Evaluation und Realisierung (vergleiche Grafik 1). Eine gründliche Analyse der Istsituation steht am Anfang von Phase 1. Was jedoch oft vergessen geht, ist die darauf folgende Definition des Zielzustands von Prozessen und Strukturen. Die Differenz zwischen Ist- und Zielzustand bietet in der Regel grosses Optimierungspotenzial – nicht zuletzt bei der Reduktion der Komplexität. Der Löwenanteil dieser Komplexität ist hausgemacht und muss schonungslos identifiziert und radikal eliminiert werden, zum Beispiel durch Reduktion des Sortiments, Standardisierung von Prozessen und Strukturen oder differenzierterer Segmentierung von Geschäftsfällen. Die geschäftsbedingte Komplexität lässt sich nicht eliminieren, also muss sie mit agilen, zukunftsgerichteten Strukturen und Prozessen intelligent bewältigt werden.

Zur Veranschaulichung dient dieses Praxisbeispiel: ein internationales Unternehmen mit Produktions- und Vertriebsgesellschaften in einer Vielzahl von Ländern. Dessen hohe Komplexität ist typisch für historisch gewachsene Unternehmen. Das Geschäft ist geprägt von redundanten Prozessen und Funktionen und in der Folge von vielen Schnittstellen zwischen den einzelnen Gesellschaften (vergleiche Grafik 2). Lesen Sie auf der nächsten Seite: Fokus Zielzustand

Vor der Spezifikation des neuen ERP-Systems wurde der Fokus auf den Zielzustand gelegt. Man entschied sich für ein hierarchisches Prinzipalmodell, um eine einfache, agile und flexibel skalierbare Struktur mit möglichst wenig Redundanzen zu schaffen. Zwischen die bestehenden Stufen wurde als neue Ebene ein regionales Businesscenter eingeführt. Dieses steuert den gesamten Wertefluss und übernimmt alle Funktionen an den Schnittstellen zwischen den Produktions- und den Vertriebsgesellschaften, das heisst die gesamte Auftragsabwicklung, Abrechnung und Logistik. Durch dieses neue Modell entsteht eine klare Rollenverteilung. Die lokalen Gesellschaften fokussieren auf Verkauf und Service, die Produktionswerke auf Entwicklung und Produktion und das Businesscenter auf Auftragsabwicklung und Logistik. Dies reduziert Redundanzen sowie Komplexität und führt zu einem quantifizierbaren Nutzen. Aus IT-Sicht hat dieser Zielzustand viele Vorteile. Mit dem neuen Modell entfällt der lokale Wertefluss. Folglich braucht es für die lokalen Vertriebsgesellschaften auch kein ERP-System mehr, es genügt ein CRM für das Erfassen von Neugeschäfts- und Serviceofferten. Ein standardisiertes ERP koordiniert im Businesscenter den Wertefluss, die Auftragsabwicklung und die Logistik. Die Produktionsgesellschaften arbeiten weiterhin mit den auf ihre Bedürfnisse optimierten ERP-Systemen, die Schnittstellen zum ERP des Businesscenters sind überschaubar. Diese neue Struktur macht die IT wesentlich anpassungsfähiger und vereinfacht Änderungen. Kommt zum Beispiel eine Vertriebsgesellschaft hinzu, müssen nur die Schnittstellen und ein lokales CRM implementiert werden. Das lässt sich wesentlich schneller und kostengünstiger bewältigen, als ein lokales ERP zu integrieren.

Das Beispiel zeigt, dass ERP-Projekte, inbesondere die Ablösung von Legacy-Systemen, eine doppelte Erfolgschance darstellen: Erstens lässt sich im Rahmen des ERP-Projekts die Geschäftskomplexität markant reduzieren und zweitens werden dadurch auch gleich die Voraussetzungen für eine agile IT-Architektur geschaffen. Die Praxis zeigt aber auch, dass ein ERP-System immer nur so schlank und agil sein kann, wie es die Prozesse und Strukturen des Zielzustands erlauben. Weil die Definition des Zielzustands nicht Sache der IT-Abteilung sein kann, sind ERP-Projekte auch keine IT-Projekte. Zumindest nicht in der ersten Phase. Die weiteren Projektphasen bieten der IT-Abteilung noch ausreichend Chancen, sich grosses Lob zu verdienen.