Ein Vorgehensmodell zur erfolgreichen ERP-Einführung

Jeder ERP-Anbieter stellt für die Einführung seines ERP-Systems ein Vorgehensmodell bereit. Doch sind diese Vorgehensmodelle tatsächlich für alle Arten von Unternehmen und ERP-Projekten geeignet? Der Beitrag geht auf typische Kritikpunkte an den klassischen Anbieter-Vorgehensmodellen ein und beschreibt ein aus Wissenschaft und Beratungspraxis abgesichertes Vorgehensmodell für eine erfolgreiche ERP-Einführung.

Alle Anbieter von ERP-Systemen weisen Vorgehensmodelle auf, die jedoch typischerweise auf einem hohen Aggregationsniveau angelegt sind, also drei bis fünf Phasen mit jeweils drei bis zehn Aufgaben, die in dieser Phase zu erledigen sind, enthalten. Eine Anpassung dieser Vorgehensmodelle an die konkrete Unternehmens- oder Projektsituation ist in den meisten Modellen nicht enthalten. Ebenso sind nur wenige Projekte bekannt, die bereits nach den Prinzipien der agilen Softwareentwicklung durchgeführt wurden. Den Verfassern dieses Beitrages sind Projekte von GUS, Kumavision, Abas, Infor und Yaveon bekannt.

Die agile Vorgehensweise kommt im Bereich der Erstellung von Anwendungen immer häufiger zum Einsatz und erzielt sehr gute Erfolge. Weiterhin beeinflusst die Wahl des Vorgehensmodells generell Laufzeit und Aufwand sowie das im Projekt zu erreichende Ergebnis sehr weitgehend.

Bild 1: SCRUM im ERP-Projekt [1].

Einführungsmodelle

Heute sollte, wenn die Voraussetzungen erfüllt sind, eine ERP-Einführung in Form einer agilen Einführung erfolgen. Schüller hat dazu eine an ERP-Projekte angepasste Vorgehensweise entwickelt [1], die im Folgenden kurz skizziert wird (Bild 1).

Ein Problem in ERP-Projekten ist, dass vorschnell von Standardfunktionen abgewichen wird. Ein Product Owner, der Anpassungswünsche priorisiert und Gesamtbudgetverantwortung hat, kann hier ein wirkungsvoller Gegenpol sein. Die Aufgaben der Key-User sind durch Interessenkonflikte geprägt. Ein Unterstützer und Schlichter (Scrum Master), der das Projekt verteidigt, aber auch Konflikte löst, kann viel zur Effektivitätssteigerung beitragen. Beide Rollen würden nach einem herkömmlichen Projektverständnis dem Projektleiter zufallen. Nach dem Scrum-Ansatz kann der Product Own-
er jedoch nicht der Scrum Master sein. Damit ergeben sich interessante Ansätze für eine bessere Ausbalancierung bei Zielkonflikten.

Backlog und Sprints schaffen eine zusätzliche Struktur. ERP-Projekte sind zeitlich gut strukturiert, abhängige Aufgaben in unterschiedlichen Arbeitsbereichen werden jedoch sehr schlecht abgebildet. Durch Zusammenfassung von Aufgaben in Sprints lassen sich effiziente Verbindungen herstellen. In Verbindung mit einer Sprintdynamisierung lassen sich agile Projektstrukturen schaffen. Während Aufwandsschätzungen für die Tätigkeiten der Anwendungsentwickler die Regel sind, lassen Tätigkeiten der Key-User oft derartige Schätzungen vermissen. In Verbindung mit Burndown-Analysen können Verzögerungen deutlich früher erkannt werden. Zudem können realistische Arbeitspakete gebildet werden, die Frustration vermeiden.

Durch Dynamisierung von Sprint-Teams und Sprint-Zeiten lassen sich die Scrum-Vorteile Eigenverantwortung und Flexibilität auch in ERP-Projekten erschließen. User Stories, d. h. konkrete Beschreibungen von Anwendungsfällen, bieten im Gegensatz zu definierten funktionalen Anforderungen die Freiheit, Lösungsansätze kreativ zu gestalten. Durch den iterativen Ansatz bleibt diese Freiheit im Projektverlauf bestehen.

Diese Vorgehensweise setzt jedoch ein hohes Maß an Vertrauen zwischen Anbieter und Anwender voraus, welches häufig zu Beginn der Einführungsphase nicht vorhanden ist. Möglicherweise haben in den zurückliegenden Vertragsverhandlungen Anbieter und Anwender eher gegensätzliche Positionen aufgebaut.

Grundsätzlich ist die Vorbereitung der Einführungsphase außerordentlich wichtig und als eigene Phase im Vorgehensmodell auch herauszustellen. In der Praxis stellt sich immer wieder heraus, dass eine klare Abschottung zwischen der Auswahl einerseits und der Einführung andererseits nicht sinnvoll ist. In der Einführungsphase werden wichtige Fragen abschließend geregelt, die den Liefer- und Leistungsumfang erst vollständig bestimmbar machen. Dies sind Aspekte, die eigentlich bereits in den Projektvertrag gehören. Auch kann die Auswahlsicherheit erst maximiert werden, wenn diese Informationen bekannt sind, die am Ende der Auswahlphase noch nicht unbedingt vorliegen. Daher ist es ratsam keine strikte Trennung zwischen Auswahl und Einführung vorzunehmen und insbesondere darauf zu achten, dass bei Auswahlprojekten nur solche Berater herangezogen werden, die in der Lage sind, kompetent und mit Hilfe von abgesicherten Methoden auch die Einführungsphase angemessen zu begleiten [2].

Bild 2: Vorgehensmodell für eine erfolgreiche ERP-Einführung.

Die Vorbereitung der Einführung

Die Vorbereitungsphase zwischen Auswahl und dem tatsächlichen Beginn der Einführung ist extrem wichtig. In dieser Phase werden wesentliche Entscheidungen getroffen, die Aufwand, Ergebnis und Zeitbedarf für die nachfolgende Einführungsphase erheblich beeinflussen. Dazu seien im Folgenden nur einige Beispiele genannt.

Vor Beginn einer ERP-Einführung müssen Architekturfragen geklärt werden. In vielen Fällen werden nicht alle vorhandenen Standardsoftwaresysteme oder Individualentwicklungen gleichzeitig abgelöst, sondern einzelne Systeme, die vielleicht erst in den letzten Jahren angeschafft wurden, bleiben bestehen; andere bleiben zunächst bestehen, vielleicht bis zur zweiten oder dritten Phase. Daher ist der Ablösereihenfolge und auch der Notwendigkeit der Ablösung von vorhandenen Systemen große Bedeutung beizumessen. Weiter ist bei strittigen Fragen eine sorgfältige Abwägung vorzunehmen, in welchem betrieblichen Anwendungssystem welche Funktionalität oder welche Stammdatenhaltung angesiedelt werden soll. Häufig existieren sowohl ERP-Kundenstammdaten als auch CRM-Kundenstammdaten. Hier ist nicht nur eine Integrationsmethode (z. B. führende System) festzulegen, sondern auch zu entscheiden (auf der Basis wirtschaftlicher Argumente), ob überhaupt zwei verschiedene Systeme eingesetzt werden müssen. Schließlich kommt dem Standort für das Startprojekt eine besondere Rolle zu, insbesondere in internationalen Settings oder in Unternehmensgruppen, in denen prinzipiell eine Auswahlmöglichkeit besteht, welches Unternehmen zuerst umgestellt wird. Abschließend ist die Festlegung der Projektorganisation eine wichtige Entscheidung. Neben der Aufteilung von Verantwortlichkeiten sollte zwingend ein Kommunikationsplan erarbeitet werden. Externe und insbesondere die internen Ressourcen müssen, entsprechend des Projektplans, reserviert werden.

Vorgehensmodell zur ERP-Einführung

Das praxiserprobte Vorgehensmodell der ERP-Einführung ist in Bild 2 dargestellt. Es besteht im Prinzip aus einem Kreislauf zwischen Analyse, Konzeption, Anpassung und Test, der je nach Wahl für eine agile oder klassische lineare Einführung einmal oder mehrmals durchlaufen werden kann. Im agilen Konzept wäre das ein Sprint. Diese Abschnitte liegen zwischen der zuvor genannten wichtigen Vorbereitungsphase und der Umstellungs- bzw. Abnahmephase nach Abschluss eines Teilprojektes, um einen nutzbaren Status des ERP-Systems zu erreichen. Über- bzw. unterlagert werden diese Schritte von drei wesentlichen Querschnittsaufgaben: dem Projektmanagement, dem Qualitätsmanagement und der Projektkommunikation, während als Projektsteuerung, wie sie auch im PRINCE-Vorgehen [3] definiert ist, ein Trusted Advisory dringend empfohlen ist, um schwerwiegenden Konflikten bei der ERP-Einführung vorzubeugen.

Dieses Vorgehensmodell kann bei Einführung eines ERP-Systems in mehreren Unternehmensteilen mehrfach durchlaufen werden, wobei der Umfang der einzelnen Phasen zeitlich und vom notwendigen Aufwand her stark variieren kann. Die horizontalen Pfeile sollen verdeutlichen, dass hier ein Tailoring des Modells auf den projektspezifischen Umfang erfolgen muss. Die konkreten Inhalte einer Phase sind dabei von verschiedenen Kriterien abhängig. So ergeben sich bereits bei unterschiedlicher Unternehmensgröße, sehr unterschiedliche Anforderungen an die einzelnen Inhalte einer Phase. So wird z. B. die Einführung eines ERP-Systems an einem Auslandsstandort deutlich schneller verlaufen und eine geringere Vorbereitungsphase bedürfen als die Ersteinführung am Heimatstandort des Unternehmens.

Bild 3: Goldene Regeln zur ERP-Einführung.

Goldene Regeln

Abschließend stellen die Verfasser dieses Beitrages noch eine Reihe von goldenen Regeln für die ERP-Einführung auf. Diese Regeln sind in fünf übergreifende Regeln und sechs Regeln für die Vorbereitungsphase differenziert (Bild 3). Eine übergreifende Regel besteht darin, dass die Geschäftsprozesse und deren Abbildung eine wesentliche Erfolgsvoraussetzung für das gelungene ERP-Einführungsprojekt darstellt, da jederzeit bekannt sein muss, welche Prozesse umgestellt und welche Funktionen des ERP-Systems dazu benötigt werden. Häufig führen die Unternehmen in diesem Zusammenhang auch ein Geschäftsprozessmanagement als Unternehmensfunktion neu ein. 

Weiterhin ist immer wieder davon auszugehen, dass eine ERP-Einführung ein Businessprojekt ist und kein IT-Projekt. Das bedeutet, der Projektleiter muss zwingend aus der Fachabteilung kommen oder aus dem Bereich der Unternehmensleitung, nicht aber aus dem Bereich der IT. Die Anforderungen an ein ERP-System unterscheiden sich zwischen IT-Abteilung und Fachabteilungen. Entscheidet die IT über die Prioritäten, bleibt Wertschöpfung oft unbeachtet.

Die Anforderungen, die das neue ERP-System in Phase 1 nach Inbetriebnahme erfüllen muss, sind zwingend nach Wirtschaftlichkeitskriterien zu priorisieren, hier liefern RoI-Berechnungsverfahren gute Möglichkeiten, Konflikte aufgrund der begrenzten Ressourcen zu entschärfen [4].

Eine weitere goldene Regel liegt in der intensiven Einbeziehung des Managements. Bei der ERP-Einführung sind an vielen Stellen Kompromisse zu schließen und Entscheidungen zwischen konfligierenden Anforderungen zu treffen; dies kann nicht an den Projektleiter delegiert werden, sondern ist in der Regel Aufgabe des Managements. Schließlich muss durch eine Vielzahl von Maßnahmen, über die einführungserfahrene Unternehmensberatungen gerne Auskunft geben, die Motivation der Beteiligten, z. B. der Keyuser und Workshop-begleitenden Personen deutlich gefördert werden, denn der Erfolg stellt sich erst am Ende der ersten Umstellungsphase ein.

Für die wichtige Vorbereitungsphase lassen sich weitere goldene Regeln definieren: die Projektziele müssen im gesamten Unternehmen kommuniziert werden, um Diskussionen immer wieder gegen diese Projektziele zu führen. Eine ausgewogene Projektorganisation ist anzustreben, die aus Fach- und IT-Kompetenz mit Entscheidungsverantwortung besteht. Eine weitere Regel ist, nicht alle Probleme in der ersten Phase des Projektes zu lösen, sondern durchaus das Projekt in mehrere Phasen aufzuteilen. Im Projekt ist es oft sehr verlockend ein zusätzliches Modul oder eine neue Funktion zu implementieren. Der zusätzliche Aufwand verzögert jedoch den Go-Live und somit erste Projekterfolge und Wertbeiträge des Systems.

Als weitere Schwachstelle ist zu erkennen, dass ERP-Einführungen immer am 1.1. eines Jahres produktiv gehen sollen. Das kann sowohl beim ERP-Anbieter als auch beim Kunden zu Kapazitätsengpässen führen und letztendlich sind die Mitarbeiter über den Jahreswechsel nicht effektiv einsetzbar oder verfügbar. Auch wenn einige Buchhalter anderes wollen, kann selbstverständlich auch zu jedem Monatsersten eine ERP-Einführung erfolgen, da die meisten Systeme in der Lage sind, Monatsabschlüsse abzubilden.

Die letzte Regel lautet, den internen Bedarf an Mitarbeiterkapazitäten auf keinen Fall zu unterschätzen und bereits in der Planungsphase drohenden Engpässen vorzubeugen. Faustregeln besagen, dass für jede durch einen externen Berater geleistete Einheit (z. B. Personentag) zwei interne Einheiten geleistet werden müssen.