Best Practices bei der Einführung von ERP-Systemen

Norbert Gronau

Während bei der ERP-Auswahl die Reduzierung der Auswahlsicherheit das wesentliche Ziel darstellt, verfolgt die ERP-Einführung ein Zielbündel rund um die wirtschaftliche Abbildung der wertschöpfenden Geschäftsprozesse im neuen ERP-System. Dieser Beitrag beschreibt die einzelnen Aufgaben, die im Verlauf des Einführungsprozesses zu erfüllen sind, um eine erfolgreiche ERP-Einführung sicherzustellen. Dabei wird ein praxiserprobtes Vorgehensmodell verfolgt.

Bild 1: Vorgehen bei der Einführung eines ERP-Systems [1].

Das generelle Vorgehen bei der ERP-Einführung entspricht der Darstellung in Bild 1. Zunächst wird die Projektorganisation überprüft, da nunmehr auch der Softwareanbieter sowie möglicherweise weitere Dienstleister (z. B. Consultants) in die Projektarbeit eingebunden werden müssen.

Die sich anschließende Phase der Feinspezifikation wird als Workshop-Phase bezeichnet, da dies die typische Arbeitsform zur gemeinsamen Erarbeitung von Detaillösungen für die abzubildenden Geschäftsprozesse darstellt. Je nach Umfang des Einführungsprojektes kann diese Phase auch erheblich umfangreicher sein als nur die Zeitdauer einiger Workshops.

In der dann folgenden Prototyp-Phase wird ein weitgehend an die Festlegungen der Feinspezifikation angepasstes ERP-System beim Anwender installiert. Ziel dieses Arbeitsschrittes ist der Test der vorgenommenen Einstellungen.

Anschließend wird ein Probebetrieb aufgenommen, der sich durch die Integration von Echtdaten von der vorhergehenden Phase unterscheidet. Verläuft der Pilotbetrieb erfolgreich, so wird anschließend der Produktivbetrieb aufgenommen, bei dem erstmals alle Mitarbeiter, die an den durch das ERP-System abgebildeten Prozessen beteiligt sind, mit dem neuen System arbeiten.

Zur Vorbereitung der ERP-Einführung empfiehlt es sich, eine Risikoanalyse vorzunehmen und basierend darauf eine Projektdurchführungsstrategie zu erarbeiten. Sinnvollerweise wird für die ERP-Einführung eine externe Projektsteuerung einbezogen. Auf die Notwendigkeit und Rolle der externen Projektsteuerung wird am Schluss dieses Beitrags eingegangen.

Risikoanalyse
In der Vorbereitungsphase eines Projektes ist eine systematische Abschätzung möglicher Risiken sinnvoll, um im späteren – wesentlich zeitkritischeren – Verlauf des Projektes auf Überraschungen durch Risiken besser eingestellt zu sein. Dabei sollten folgende Risiken betrachtet werden:

Organisatorische Risiken beziehen sich auf die mit der ERP-Einführung einhergehenden Regelungen zur Aufbau- bzw. Ablauforganisation. Fehlende Mitarbeiterkapazität, die für die inhaltliche oder Betreuung eines neuen ERP-Systems zwingend erforderlich ist, stellt z. B. ein erhebliches organisatorisches Risiko dar.

Technische Risiken liegen vor, wenn auf noch nicht erprobte und für den konkreten Anwendungsfall als geeignet erkannte Techniken gesetzt wird. So kann ein technisches Risiko z. B. dadurch entstehen, dass eine zu große Anzahl von Artikeldaten mit einem dafür technisch kaum geeigneten System bewältigt werden soll.

Terminliche Risiken beziehen sich auf die Gefahr, dass ein planerisch festgelegter Zielerreichungstermin überschritten wird. Notwendige Individualanpassungen eines ERP-Systems stellen meist ein terminliches Risiko dar, insbesondere wenn die notwendige Zeit für Integrationstests nicht berücksichtigt wird. Kapazitive Risiken im Projekt entstehen, wenn der abzuarbeitende Arbeitsumfang und die dafür zur Verfügung stehenden personellen Ressourcen auseinanderklaffen.

Kapazitive Risiken entstehen auch dann, wenn das für das ERP-Projekt zur Verfügung stehende Personal über die gesamte Projektlaufzeit zu mehr als 80 % bereits mit geplanten Tätigkeiten belegt ist, da für ungeplante Aufgaben und persönliche Verteilzeiten nicht mehr ausreichend Spielraum verbleibt.

Kosten-/Nutzen-Risiken liegen vor, wenn der Erfolg eines Projektes zweifelhaft ist, ohne dass Möglichkeiten zur Beeinflussung der mit dem Projekt verbundenen Kosten bestehen.

Psychologische Risiken entstehen aus dem Verhalten und aus der Einstellung der Benutzer des Systems. So kann mangelnde Akzeptanz der Benutzer die mit dem Produktivstart verbundenen Erwartungen nahezu vollständig zunichte machen, wenn das notwendige Maß an Aufgeschlossenheit fehlt.

Die Erfahrung zeigt, dass es zu Projektbeginn bei ERP-Projekten häufig zu Problemen kommt, die den Start des Projektes behindern oder verzögern. Solche Probleme sind z. B.:

  • Der Anfangstermin des Projektes wird nach hinten verschoben, der Endtermin (Produktivstart) bleibt jedoch bestehen. Die zur Verfügung stehende Zeitspanne verringert sich.
  • Es bilden sich – offen oder ver-deckt – Fronten gegen das Projekt. Es werden Zweifel an der fachlichen oder persönlichen Kompetenz des Projektleiters geäußert.
  • Mit dem Verweis auf andere, negativ verlaufene Projekte wird ein mögliches Scheitern dieses Projektes antizipiert.
  • Es kommt zu Spekulationen bzw. zur Bildung von Gerüchten bezüglich der Auswirkungen des Projektes. Zum Beispiel wird der Verlust von Arbeitsplätzen befürchtet.
  • Es existiert eine zu hohe Erwartungshaltung an die mit dem Projekt verbundenen Ergebnisse.

Um die Auswirkungen solcher Probleme zu begrenzen, wird empfohlen, eine Projektdurchführungsstrategie [2, 3] zu planen und entsprechende Maßnahmen, etwa eine Situationsanalyse, Betroffenheitsanalyse und Beteiligungsplanung umzusetzen.

Bild 2: Beispiel einer Projektorganisation (Quelle: Potsdam Consulting).

Überprüfung der Projektorganisation
Während in der Auswahlphase eine nebenamtliche Betreuung des ERP-Projektes ausreichte, muss nun die Projektorganisation professionalisiert werden (Bild 2). Je nach Größe des Unternehmens sind dazu mehrere Mitarbeiter hauptamtlich für die Mitarbeit im Projektteam abzustellen. Der Einsatz externer Dienstleister bietet sich an, wenn im Unternehmen selbst die notwendigen Kompetenzen oder Kapazitäten nicht verfügbar sind. Externe Dienstleister können als Berater, Projektleiter oder Projektsteuerer eingesetzt werden. Als Projektleiter vertreten sie das Unternehmen nach innen (gegenüber den Mitarbeitern) und nach außen (gegenüber dem Software-Lieferanten und ggf. weiteren Zulieferern).

Unabhängig von der zeitlichen Freistellung von Mitarbeitern ist in jedem Fall ein internes Projektteam zu bilden, das mindestens aus Vertretern der von der Systemeinführung betroffenen Fachabteilungen (Key-User) und der IT-Abteilung besteht. Zudem muss ein Lenkungsgremium eingerichtet werden, dem, neben dem Projektleiter, Vertreter der Unternehmensleitung und der Projektleiter des ERP-Anbieters angehören. Projektdokumentation und Qualitätssicherung sind Aufgabe der externen Projektsteuerung, die ebenfalls in das Lenkungsgremium entsandt wird.

Aufgaben des Projektleiters
Dem Projektleiter kommt eine besondere Rolle zu. Er muss sich fachlich in den Prozessen auskennen und für das notwendige Veränderungsmanagement mit einer gewissen Überzeugungsfähigkeit ausgerüstet sein. Externe Projektleiter können meist nicht beide Anforderungen abdecken. In den Verantwortungsbereich des Projektleiters fallen weiterhin folgende Aufgaben [4]:

  • Integrationsmanagement: Koordination der richtigen Funktionsweise aller Bestandteile des Projektes
  • Geltungsbereichsmanagement: Sicherstellung der genau notwendigen Projektarbeiten
  • Zeitmanagement: Sicherstellung des termingerechten Projektablaufs
  • Kostenmanagement: Sicherstellung der Einhaltung des vorgegebenen Budgetrahmens
  • Qualitätsmanagement: Das neue ERP-System soll die geplanten Anforderungen erfüllen.
  • Human Resource Management: Personaleinsatzplanung und -führung Kommunikationsmanagement: Sicherstellung des Projektinformationswesens
  • Risikomanagement: Identifikation und Analyse von Risiken sowie Ergreifen von Maßnahmen gegen diese Beschaffungsmanagement von Waren und Dienstleistungen

Feinspezifikation
Aufgabe dieser Phase ist es, die Parameter des einzuführenden ERP-Systems und die organisatorischen Abläufe so weit aneinander anzugleichen, dass ein effizienter Produktivbetrieb aufgenommen werden kann. Dabei erfolgt die Abbildung der Organisationsstruktur im System, das Einstellen der Geschäftsprozessparameter und das Prototyping. Wenn das einzuführende ERP-System über ein Referenzmodell verfügt, muss dieses insbesondere bei der Feinspezifikation herangezogen werden.

Eng verbunden mit der Übertragung der Stammdaten ist die zumeist erforderliche Umstellung oder Neueinführung von Nummernsystemen für Kunden, Artikel oder Teile. Während Kundennummern aufsteigend vergeben werden können, sind bei der Nummerierung von Produkten, Baugruppen oder Teilen weitergehende Überlegungen notwendig, da die Sachnummernsysteme in praktisch jeder Abteilung des Unternehmens benötigt werden. Es wird dringend empfohlen, Klassifikationen und Merkmale nicht in der Artikelnummer, sondern in eigens dafür vorzusehenden Datenfeldern des Artikels und dann weitgehend natürlichsprachlich vorzunehmen.

Einstellen der Geschäftsprozessparameter
Zu den in diesem Arbeitsschritt notwendigen Einstellungen gehören u. a. [5]:

  • Währungen, Betriebskalender mit Feiertagen, landesspezifische Einstellungen
  • Festlegung der von den einzelnen Unternehmensbereichen genutzten oder geplanten Nummernkreise für Artikel, Kunden, Lieferanten, Organisationseinheiten, Belege etc.
  • Festlegungen zum Aufbau und zur Pflege von Stammdatenstrukturen
  • Eingabe der im System verwendeten Maßeinheiten und der Umrechnungsvorschriften zwischen Maßeinheiten (z. B. wird bei der Blechbearbeitung Stahlblech nach Tonnen eingekauft, aber in der Fertigung nach Millimetern angefordert und verarbeitet)
  • Festlegung der einzusetzenden Kontenrahmen für Kostenrechnung, Controlling und Buchhaltung sowie die Zuordnung der Konten zu den Positionen der Bilanz bzw. der Gewinn-und-Verlust-Rechnung

Ebenfalls in diesen Aufgabenbereich gehören die Festlegung von Schnittstellenspezifikationen zu anderen Anwendungssystemen und die organisatorische Einbettung dieser Schnittstellen (z. B. wer überspielt die Rechnungsdaten in die Buchhaltung?).

Der Umfang der einzustellenden Parameter bewegt sich zwischen einigen Dutzend bei funktionsspezifischer Software über einige 100 bei kleineren ERP-Systemen bis hin zu mehreren 1 000 bei unternehmensweit eingesetzten Systemen wie SAP ERP.

Bei der Parameterfestlegung werden Konfigurationsfehler begangen, die teilweise erhebliche Auswirkungen haben können [6]. Eine aufgabenwidrige Parameterverwendung liegt vor, wenn ein bestimmtes Konfigurationsziel mit der falschen Stellgröße verfolgt wird. So ist z. B. bei der Einstellung von Dispositionsparametern zwischen dem nur auf die Mindestbestellgröße wirkenden Parameter minimale Losgröße und dem auf alle Bestellmengen wirkenden Rundungswert zu unterscheiden, der alle Bestellmengen auf ein Vielfaches seines Betrages aufrundet. Wirksame Parameter werden nicht beachtet, wenn z. B. auf das Setzen eines Sicherheitsbestandes verzichtet wird.

Bild 3: Möglichkeiten der Altdatenübernahme [1].

Ein zwangsweises Außerkraftsetzen von Parameterwirkungen erfolgt etwa, wenn durch Wahl des Losgrößenverfahrens ‚Feste Bestellmenge‘ der oben beschriebene Rundungswert durch das Losgrößenverfahren ignoriert wird und stattdessen ein oder mehrere Lose mit der ‚festen‘ Menge erzeugt werden.

Während des Projektablaufs sind über die inhaltlichen Fehler bei der Parametereinstellung hinaus folgende Probleme zu erkennen:

  • Hoher Termindruck insbesondere bei ‚Big-Bang-Projekten‘, die alle Module gleichzeitig in Betrieb nehmen, führt zu Zeitmangel bei der Parametereinstellung und damit auch zu mangelnder Sorgfalt. Statt individuell ermittelter passender Parameterwerte werden Initialwerte oder Defaultwerte belassen, deren Auswirkungen nicht überprüft werden.
  • Fehlendes Controlling des betriebswirtschaftlichen Erfolges des neuen Systems, insbesondere des Einflusses auf wirtschaftliche Größen wie Kapitalbindung oder Dispositionsmängel und deren Auswirkungen
  • Die ungeprüfte Parameterübernahme aus Altsystemen kann dann zu Problemen führen, wenn unterschiedliche, auf diesen Parametern basierte Verfahren genutzt werden. In diesem Fall ist die Parameter- übernahme nicht sinnvoll.
  • Auch bei der Parameterübernahme aus ähnlichen Unternehmen ist zu berücksichtigen, ob der mit der jeweiligen Parametereinstellung intendierte Zweck nicht ein anderer ist.

Prototyp-Phase
Ziel dieser Phase ist es, die zuvor eingestellten Parameter des ERP-Systems unter realitätsnahen Bedingungen zu testen. Dazu ist als vorbereitender Schritt die Übernahme der Stammdaten aus den Altsystemen erforderlich (Bild 3). Je nach Vorliegen der bisher genutzten Stammdaten sind unterschiedliche Möglichkeiten einer Altdatenübernahme zu unterscheiden. Liegen die Daten in Form von proprietären Datenstrukturen vor, ist es zumeist nicht möglich eine entsprechende Exportroutine zur Verfügung zu stellen, die alle Daten unter Beachtung der vorgesehenen Relationen des in der neuen Standardsoftware verwendeten Datenmodells exportiert. Daher besteht nur die Möglichkeit, Stammdatenlisten in ASCII-Dateien zu übertragen.

Wenn auch diese Möglichkeit nicht zur Verfügung steht, müssen die Daten ausgedruckt und manuell in das neue System übertragen werden. Der Nachteil des großen Aufwandes ist jedoch mit zwei erheblichen Vorteilen verbunden: Zum einen kann bei der Neuerfassung zwischen zu übertragenden und nicht zu übertragenden Daten entschieden werden. Artikel, die nicht mehr im Programm sind oder Kunden, die seit mehreren Jahren nichts mehr bestellt haben oder deren Firma nicht mehr existiert, werden nur so identifiziert. Zum anderen sind bei der manuellen Neueingabe alle Gültigkeitsüberprüfungen des neuen Systems aktiv. Ungültige Postleitzahlen oder falsche Verknüpfungen zwischen Firma und Ansprechpartner werden unter Umständen bei einem automatischen Import in die entsprechende Tabelle nicht erkannt.

Parametertest
Zur Prototypphase gehört die Überprüfung, ob die eingestellten Berechtigungen korrekt die gewollte organisatorische Aufgabenverteilung wiedergibt. Alle Ausdrucke des Systems, sowohl die intern verwendeten Belege und Berichte als auch die im Geschäftsverkehr verwendeten Briefe müssen auf formale und inhaltliche Richtigkeit überprüft werden.

Zumeist ergibt sich in der Prototyp-Phase auch die Notwendigkeit weiterer Berichte. Über deren Realisierung sollte zügig entschieden werden, um einen geplanten Produktivstarttermin nicht zu gefährden.

Ein weiteres Ziel der Prototyp-Phase liegt darin, weitere Mitarbeiter an die Bedienung des Systems heranzuführen. Hierzu sind entsprechende Schulungen vorzubereiten und durchzuführen. Wichtig ist, dass die Schulungen nicht nur aus Folienvorträgen bestehen, sondern den Schwerpunkt auf die direkte Vermittlung von Kenntnissen am neuen ERP-System legen. Dies kann erreicht werden, indem einzelne Abschnitte der Geschäftsprozesse, die das neue System unterstützen soll, mit Beispieldaten direkt am System geübt werden. Daher sollte jedem Teilnehmer der Schulung ein eigener Rechner mit installiertem ERP-System zur Verfügung stehen. Die Schulungen sind zeitnah zum Produktivstart durchzuführen, damit der erreichte Kenntnisstand nicht wieder in Vergessenheit gerät. Regelmäßige Wiederholungen unter allmählicher Erweiterung des Stoffs sind empfehlenswert.

Spätestens in der Prototyp-Phase sind auch Lasttests der Software durchzuführen, um zu erkennen, ob die zu Beginn gewählte Dimension der Hardware ausreichend war. Ansonsten besteht die Gefahr, dass sich Performance- Probleme häufig erst bei Lastbetrieb herausstellen. Daher ist es außerordentlich empfehlenswert, diese Lasttests bereits in der Prototyp-Phase durchzuführen. Im Produktivbetrieb des neuen Systems gefährdet eine unzureichende Performance unter Umständen die mit der Einführung der neuen Standardsoftware verbundenen Ziele. Wenn z. B. Änderungen des Auftragsnetzwerks (Net Change) nicht schnell genug durchgeführt werden können, ist eine genaue Lieferfähigkeitszusage nicht mehr möglich. Wenn nicht alle pro Tag eintreffenden Bestellungen am selben Tag bearbeitet werden können, ist ebenfalls die Konkurrenzfähigkeit des Unternehmens nicht mehr sichergestellt, da sich die Auslieferung bestellter Aufträge verzögert.

Umstellungsstrategien
Nachdem in der vorangegangenen Phase die für den reibungslosen Betrieb des ERP-Systems erforderlichen Parameter eingestellt wurden, muss sich das neue System nun in einem begrenzten Probebetrieb in der Praxis bewähren. Je nach Umstellungsstrategie stehen für diesen begrenzten Probebetrieb verschiedene Optionen zur Auswahl [1]:
Aufteilung nach Geschäftsobjekten: Bei der Aufteilung nach Geschäftsobjekten wird ein ausgewählter Teil der Kunden, Artikel, Projekte etc. mit dem neuen System bearbeitet, während die übrigen Geschäftsobjekte weiterhin mit dem alten System bearbeitet werden. Vorteil dieser Aufteilung ist die Möglichkeit, die vorgenommenen Einstellungen am realen Geschäftsobjekt testen zu können. Nachteilig bei dieser Variante ist jedoch, dass zur Sicherstellung der Datenintegrität im bisher verwendeten System Doppeleingaben erfolgen müssen. Daher kann der Zeitraum einer Aufteilung nach Geschäftsobjekten mit einer parallelen Bedienung beider Systeme wegen der daraus resultierenden höheren Belastung der Mitarbeiter nur kurz, d. h. im Wochenbereich sein. Das in dieser kurzen Zeit durchzuführende Testprogramm muss daher sorgfältig geplant werden.
Aufteilung nach Funktionen: Bei der Aufteilung nach Funktionen oder Programmmodulen werden nach und nach fertig angepasste Module des neuen Systems in den Produktivbetrieb überführt. Für jedes Modul oder jeden Funktionsblock findet somit eine stichtagsbezogene Ablösung der alten Systemfunktionalität durch ein Modul des neuen ERP-Systems statt. Dieses Vorgehen setzt die Aufteilbarkeit des Funktionsumfangs zwischen alten und neuen Systemen voraus. Je nach Integrationsgrad sind aber u. U. zahlreiche Schnittstellen des abgelösten alten Systems zu anderen Altsystemen für das neue System zu schaffen, solange die verbliebenen Altsysteme noch weiter betrieben werden. Zudem ist angesichts der hohen Inte- grationsdichte umfassender ERP-Systeme eine Herauslösung einzelner Module zumindest schwierig. Nachteilig ist darüber hinaus, dass der Zeitraum der Umstellung sehr lang wird und die betroffenen Funktionen mit beiden Systemen arbeiten müssen. Auch der zweifache Ressourcenbedarf wird meist als nachteilig an dieser Lösung angesehen. In der Praxis kommt als Problem hinzu, dass bestimmte betriebswirtschaftliche Aufgaben, etwa das Anlegen eines neuen Projektes, Auftrages oder Kunden wahlweise im alten oder im neuen System vorgenommen werden können, wenn diese Möglichkeit nicht im alten System ausdrücklich gesperrt werden kann (und dies auch tatsächlich durchgeführt wurde). Durch Fehlbedienungen dieser Art entsteht zusätzlicher Aufwand bei der Datenintegration und -konsolidierung im neuen System.
Vollständige Ablösung des alten Systems: Bei der als ‚Big Bang‘ bezeichneten vollständigen Ablösung eines oder mehrerer Altsysteme durch das neue ERP-System werden zu einem Stichtag alle Geschäftsprozesse auf das neue System umgestellt. Diese Lösung vermeidet die Implementierung nur vorübergehender Schnittstellen zu Altsystemen und verkürzt den Zeitraum der Umstellung erheblich. Sie eröffnet jedoch ein hohes Risiko, weil u. U. bei Problemen kein mit aktuellsten Daten versehenes Altsystem mehr zur Verfügung steht und die betroffenen Geschäftsprozesse unmittelbar beeinträchtigt werden. Der Big Bang stellt daher höchste Anforderungen an die Qualität der vorbereitenden Maßnahmen.

Bild 4: Aufgaben der externen Projektsteuerung (Quelle: Potsdam Consulting).

Notwendigkeit einer externen Projektsteuerung
Die Einführung eines neuen ERP-Systems lässt sich mit einer Operation am offenen Herzen vergleichen. Nur wenige nehmen allerdings eine Herzoperation selbst vor! Bei der Einführung von ERP-Systemen kommt es jedoch immer wieder vor, dass der noch zur Markt- erkundung unbedingt erforderliche Berater nach Aussprechen seiner Empfehlung wieder verabschiedet wird, mit dem Argument, den Rest allein bewältigen zu können. Der Autor dieses Beitrags kennt nur sehr wenige Unternehmen mit überaus großer ERP-Reife, die tatsächlich eine ERP-Einführung allein mit dem liefernden Softwarehaus erfolgreich gestaltet haben. Den meisten anderen Unternehmen fehlt es an den notwendigen personellen Ressourcen und dem notwendigen Wissen zur Optimierung von Geschäftsprozessen sowie über die Gepflogenheiten der ERP-Branche. Die Notwendigkeit einer externen Projektsteuerung liegt dann auf der Hand, wenn folgende Merkmale erkennbar sind:

  • Der Zeitplan für die Einführung ist im Rückstand.
  • Der Anbieter hält Qualitätsversprechen nicht ein.
  • Die Funktionalität erscheint schwächer als ursprünglich erwartet.
  • Anbieter und Kunde können sich nur schwer koordinieren.
  • Ein deutlich höherer Projektaufwand ist zu erwarten. Die internen Kapazitäten sind ausgelastet.
  • Die Mitarbeiter des Anbieters verfügen (noch) nicht über die erwarteten Fähigkeiten.
  • Das Management des Kunden ist mit anderen Aufgaben ausgelastet.

Aufgabe der externen Projektsteuerung (Bild 4) ist es, Zeit, Qualität und Projektkosten zu überwachen sowie zwischen Anbieter und Kunde zu vermitteln. Dazu gehört es, vorzuschlagen, was im Lenkungsausschuss entschieden werden muss, zu eskalieren, wenn der Anbieter nicht liefert und zu besänftigen, wenn der Kunde Unmögliches fordert.

Im Rahmen der Zeitplanung drängt die externe Projektsteuerung auf Termineinhaltung, erinnert an bevorstehende Termine und fordert Ressourcen bei Anbieter und Kunde an. Vorschläge des Anbieters, welche Ressourcen er in das Projekt einbringen will, werden überprüft. Kommt es zu Terminverschiebungen, werden die Gründe validiert und dem Anbieter/Kunden zugeordnet. Ebenfalls werden Auswirkungen von Änderungswünschen auf den Zeitplan aufgezeigt.

Gleichermaßen bedeutsam für den Einführungserfolg ist das Qualitätsmanagement. Hier nimmt die externe Projektsteuerung Arbeitspakete nach Prüfung ab, beachtet Validierungsanforderungen, beurteilt Fachkonzepte, Schulungsmaßnahmen und deren Ergebnisse, die Dokumentation, Testverfahren und -ergebnisse sowie den jeweils erreichten Zielerreichungsgrad. Sie schätzt die Systemperformance ein und fordert die notwendige Datenqualität.

Schließlich trägt die externe Projektsteuerung auch zur Kostendisziplin bei: Sie berechnet die Auswirkungen von Änderungen auf die Projektkosten, überprüft die Anbieterrechnungen und bestreitet nicht geleisteten Anbieteraufwand. Sie übernimmt Verantwortung dafür, dass abgerechnete Leistungen lt. Vertrag auch erbracht wurden, und bewertet Erweiterungsangebote. So wird sichergestellt, dass nicht versehentlich seitens des Anbieters zu hohe Kosten geltend gemacht und mangels Überblick des Kunden auch gezahlt werden.

Praxiserfahrungen zeigen, dass allein die direkt gesparten Kosten des Anbieters schon eine Einschaltung einer externen Projektsteuerung rechtfertigen. Wenn vor Beginn des ERP-Projektes eine RoI-Analyse [7] durchgeführt wurde, kann auch der Wert der Zeiteinhaltung bemessen werden. Ein halbes Jahr Projektverzögerung führt in jedem Fall dazu, dass der erkannte Produktivitätsverlust anhält. Dieser kann schon 25 % des externen Projektvolumens ausmachen. Das Qualitätsmanagement schließlich beugt zu spät entdeckten Fehlern vor und senkt somit Kosten unmittelbar vor oder während des Produktivstarts. Insgesamt kann daher eine externe Projektsteuerung für die ERP-Einführung nur empfohlen werden.

Schlüsselwörter:

ERP-System, Einführung, Risikoanalyse, Projektorganisation, Parameter, Prototyp

Literatur:

[1] Gronau, N.: Enterprise Resource Planning. Funktionen, Architektur und Management von ERP-Systemen. 3. Auflage München 2014.
[2] Litke, H.: Projektmanagement. Methoden, Techniken, Verhaltensweisen. 2. Auflage München Wien 1993.
[3] Litke, H.: Projektmanagement. Methoden, Techniken, Verhaltensweisen. 3. Auflage München Wien 1995, S. 191.
[4] Bartsch, M.: Qualitätssicherung für Software durch Vertragsgestaltung und Vertragsmanagement. Informatik Spektrum 23 (2000) 1, S. 3 - 10.
[5] Appelrath, H.-J.; Ritter, J.: R/3-Einführung. Methoden und Werkzeuge. Berlin Heidelberg New York 2000.
[6] Dittrich, J.; Mertens, P.; Hau, M.; Hufgard, A.: Dispositionsparameter in der Produktionsplanung mit SAP. Einstellungshinweise, Wirkungen, Nebenwirkungen.
5. Auflage Braunschweig Wiesbaden 2009.
[7] Gronau, N.: Handbuch der ERP-Auswahl. Berlin 2012.