ERP Systemeinfu¦êhrung – ERP-Systemeinführung

Dieses Kapitel beschreibt das generelle Vorgehen einer ERP-Systemeinführung, hierbei wird das Vorgehensmodell von Gronau in Abb. 1 verfolgt.

Als erstes wird die Projektorganisation betrachtet, da hier zu beachten ist, dass nun auch Softwareanbieter und möglicherweise weitere Dienstleister (z.B. Consultants) in das Projekt mit eingebunden werden müssen. Darauf folgt die Phase der Feinspezifikation, diese Phase wird auch als „Workshop-Phase“ bezeichnet, weil in dieser Phase ein Workshop als typische Arbeitsform gilt. Es gilt gemeinsam Detaillösungen zu erarbeiten, die den Geschäftsprozess widerspiegeln. Der Zeitraum dieser Phase variiert je nach Umfang des Einführungsprojektes und kann hierbei auch die Zeitdauer einiger Workshops überschreiten. Die nachfolgende Prototyp-Phase beinhaltet die Installation eines an die Feinspezifikation angepasstem ERP-Systems beim Anwender. Ziel ist hierbei der Test der vorgenommenen Einstellungen. Darauf folgt der Probebetrieb, dieser unterscheidet sich durch die Integration von Echtdaten von der Prototyp-Phase. Im Falle eines erfolgreichen Pilotbetriebs wird anschließend der Produktivbetrieb aufgenommen, in diesem Betrieb dürfen zum ersten Mal alle Mitarbeiter, die an den durch das ERP-System abgebildeten Prozessen beteiligt sind, mit dem neuen System arbeiten (Gronau 2010, S. 333).

Risikoanalyse

Da die Einführung eines ERP-Systems ein durchaus zeitkritisches Projekt darstellt ist es sinnvoll sich während der Vorbereitungsphase mit einer systematischen Abschätzung möglicher Risiken zu beschäftigen. So lässt sich im Verlauf des Projekts leichter auf Überraschungen durch Risiken reagieren. Hierbei gibt es verschiedene Arten von Risiken zu beachten (Gronau 2015, S. 39).

Zu den organisatorischen Risiken zählen die mit der ERP-Einführung verbundenen Regelungen zur Aufbau- bzw. Ablauforganisation. Ein Beispiel für ein Risiko aus diesem Bereich ist die fehlende Mitarbeiterkapazität, die für die Inhalte oder Betreuung eines neuen ERP-Systems zwingend erforderlich ist. Technische Risiken hingegen beziehen sich auf noch nicht erprobte und für den konkreten Anwendungsfall als geeignet erkannte Techniken. Als Beispiel hierfür gilt eine zu große Anzahl an Artikeldaten, welche aber von einem technisch kaum ausreichendem System bearbeitet werden soll (Gronau 2015, S. 40).

Terminliche Risiken liegen vor, wenn die Gefahr besteht, dass ein vereinbarter Zielerreichungstermin überschritten wird. Unabdingbare Individualanpassungen eines ERPSystems sind meistens mit einem terminlichen Risiko verbunden. Hervorzuheben ist hierbei die notwendige Zeit für Integrationstests. Es können auch Kapazitive Risiken entstehen, wenn eine Diskrepanz zwischen dem abzuarbeitenden Arbeitsumfang und dem dafür zur Verfügung gestellten personellen Ressourcen entsteht. Da es in ERPProjekten möglicherweise zu ungeplanten Aufgaben kommen kann ist es wichtig, dass das zur Verfügung stehende Personal über genügend zeitlichen Spielraum verfügt (Gronau 2015, S. 40).

Sobald der Erfolg eines Projektes zweifelhaft ist, ohne dass mit dem Projekt verbundene monetäre Beeinflussungsmöglichkeiten bestehen, spricht man von Kosten-/Nutzen-Risiken. Zu den psychologischen Risiken zählen jene Risiken, die aus dem Verhalten und aus der Einstellung der Benutzer des Systems entstehen. Als Beispiel hierfür gilt unter anderem die mangelnde Akzeptanz der Benutzer beim Produktivstart, diese mangelnde Akzeptanz kann die Erwartungen an den Produktivstart nahezu vollständig zunichtemachen (Gronau 2015, S. 40).

Insbesondere zum Projektbeginn von ERP-Projekten kommt es häufig zu psychologischen oder terminlichen Risiken, die den Start des Projektes behindern oder verzögern. Beispiele hierfür sind die Verschiebung des Projektstarts, mit gleichbleibendem Endtermin, oder die Bildung von offenen bzw. verdeckten Fronten innerhalb des Mitarbeiterkreises gegen das Projekt. Hierzu zählt auch der Zweifel an der fachlichen oder persönlichen Kompetenz des Projektleiters. Oftmals wird auf andere negativ verlaufene Pro jekte verwiesen, welche dafür sorgen, dass ein mögliches Scheitern des aktuellen Projektes suggeriert wird. Dies kann zu Spekulationen und Gerüchten bezüglich der Auswirkung des Projektes führen, zum Beispiel kann ein Arbeitsplatzverlust befürchtet werden. Darüber hinaus kann es allgemein zu einer zu hohen Erwartungshaltung gegenüber den mit dem Projekt verbundenen Ergebnissen kommen (Gronau 2015, S. 40).

Überprüfung der Projektorganisation

Im Gegensatz zur Auswahlphase ist bei der Einführung eines ERP-Systems eine professionalisierte Projektorganisation notwendig. Die Anzahl der hierbei im Projektteam hauptamtlich tätigen Mitarbeiter ist abhängig von der Unternehmensgröße. Es sollte auf externe Dienstleister zurückgegriffen werden, wenn die notwendige Kompetenz oder Kapazität des Unternehmens selbst überschritten werden. Der Projektleiter repräsentiert hierbei das Projekt sowohl innerhalb des Unternehmens als auch außerhalb des Unternehmens gegenüber Software-Lieferanten oder ggf. weiteren Zulieferern. Externe Dienstleister können die Rolle des Beraters, Projektleiters oder Projektsteuerers übernehmen. Unabhängig von der zeitlichen Freistellung von Mitarbeitern sollte auf jeden Fall ein internes Team bestehend aus Vertretern der von der Systemeinführung betroffenen Fachabteilungen, Vertretern der IT-Abteilung und Vertretern der Unternehmensleitung gebildet werden (Gronau 2010, S. 334–335).

Darüber hinaus muss ein Lenkungsgremium eingerichtet werden. Diesem Gremium sollten Projektleiter, Vertreter der Unternehmensleitung und der Projektleiter des ERP-Anbieters beisitzen. Ebenfalls ins Lenkungsgremium entsandt werden sollten Projektdokumentation- und Qualitätssicherungsbeauftragte der externen Projektsteuerung (Gronau 2015, S. 40–41).

Aufgaben des Projektleiters

Der Projektleiter muss sich fachlich in den Prozessen auskennen und Überzeugungsfähigkeit besitzen, um das notwendige Veränderungsmanagement umzusetzen. Externe Projektleiter sind meistens nicht in der Lage beiden Anforderungen gerecht zu werden (Gronau 2015, S. 41; Bartsch 2000, S. 3–10).

Zu den Aufgaben des Projektleiters zählt unter anderem das Integrationsmanagement, in Form von Koordination der richtigen Funktionsweise aller Bestandteile des Projektes. Außerdem das Geltungsbereichsmanagement, welches die Sicherstellung der genau notwendigen Projektarbeiten beinhaltet. Auch das Zeit- und Kostenmanagement gehören zu den Aufgaben des Projektleiters, hierbei gilt die Sicherstellung des termingerechten Projektablaufs und der Einhaltung des vorgegebenen Budgetrahmens. Sowohl das Qualitätsmanagement, zu dessen Aufgaben die Erfüllung der geplanten Anforderungen an das ERP-System zählt, als auch das Human Ressource Management, welches die Personaleinsatzplanung und -führung beinhaltet, zählen ebenfalls zu den Aufgaben des Projektleiters. Eine weitere Aufgabe ist das Risikomanagement, hierbei geht es um die Identifikation und die Analyse von Risiken aber auch um die Ergreifung von nötigen Gegenmaßnahmen. Außerdem hat ein Projektleiter auch die Aufgabe des Beschaffungsmanagements, dies beinhaltet die Beschaffung von Waren und Dienstleistungen (Gronau 2015, S. 41).

Feinspezifikation

In der Phase der Feinspezifikation werden die Parameter des einzuführenden ERP-Systems an die organisatorischen Abläufe angeglichen, so dass ein effizienter Produktivbetrieb aufgenommen werden kann. Die Feinspezifikation lässt sich in die Bereiche Abbildung der Organisationsstruktur im System, Einstellen der Geschäftsprozesse und die Prototyp-Phase unterteilen. Sobald ein Referenzmodell für das einzuführende ERP-System vorliegt wird dieses auch insbesondere in der Phase der Feinspezifikation herangezogen (Gronau 2010, S. 335).

Abbildung der Organisationsstruktur im System

Die Einführung oder Umstellung von Nummernsystemen für Kunden, Artikel oder Teile ist eng verbunden mit der Übertragung der Stammdaten. Hierbei werden Kundenummern aufsteigend vergeben. Für die Nummerierung von Produkten, Baugruppen oder Teilen sind genauere Überlegungen anzustellen, da diese Sachnummernsysteme in jeder Abteilung des Unternehmens eine Rolle spielen. Es wird empfohlen die Klassifikationen und Merkmale nicht in die Artikelnummer einzubetten, da ein eigenes nur für diesen Sachverhalt erstelltes Datenfeld des Artikels in natürlicher Sprachnorm mehr Nutzen stiftet (Gronau 2010, S. 335).

Einstellen der Geschäftsprozessparameter

In diesem Arbeitsschritt werden verschiedene Einstellungen getroffen, zum Beispiel Währungen, Betriebskalender mit Feiertagen, landesspezifische Einstellungen. Außerdem erfolgt die Festlegung von genutzten oder geplanten Nummernkreisen für Artikel, Kunden, Lieferanten, Organisationseinheiten und Belege, welche in verschiedenen Unternehmensbereichen relevant sind. Zusätzlich wird die Pflege und der Aufbau der Stammdatenstrukturen festgelegt. Die für den Geschäftsprozess wichtigen Maßeinheiten, sowie Umrechnungsvorschriften zwischen den relevanten Maßeinheiten werden ebenfalls eingestellt. Darüber hinaus erfolgt die Festlegung der einzusetzenden Kontenrahmen für Kostenrechnung, Controlling und Buchhaltung. Diese Konten werden zur jeweiligen Position bzw. der Gewinn-und-Verlust-Rechnung zugeordnet (Appelrath und Ritter 2000, S. 100).

Eine wichtige Rolle spielt in dieser Phase auch die Schnittstellenspezifikation zu anderen Anwendungssystemen und die organisatorische Einbettung dieser Schnittstellen, es stellt sich zum Beispiel die Frage, wer überhaupt für das Überspielen der Rechnungsdaten in die Buchhaltung zuständig ist (Gronau 2010, S. 336).

Konfigurationsfehler bei der Parameterfestlegung können erhebliche Auswirkungen haben. Wenn ein bestimmtes Konfigurationsziel mit der falschen Stellgröße verfolgt wird liegt eine aufgabenwidrige Parameterverwendung vor. Hierbei gilt zum Beispiel zwischen verschiedenen Dispositionsparameter wie der nur auf die Mindestbestellgröße wirkende minimale Losgröße und dem für alle Bestellungen relevanten Rundungswert zu unterscheiden (Dittrich et al. 2009, S. 15).

Ebenso häufig kommt es vor, dass wirksame Parameter nicht beachtet werden. Als Beispiel hierfür gelten nicht angelegte Sicherheitsbestände, welche für ein Unternehmen aber durchaus wichtig sein können (Dittrich et al. 2009, S. 15).

Von einer zwangsweisen Außerkraftsetzung von Parameterwirkungen spricht man, wenn durch die Wahl des Losgrößenverfahrens für feste Bestellmengen das System dazu bringt in der Folge immer Rundungswerte zu ignorieren und somit abhängig von der tatsächlichen Unterdeckung ein oder mehrere Lose mit der gleichen Menge generiert (Dittrich et al. 2009, S. 15–16).

Aus diesen Parameterfehleinstellungen können mehrere Arten von Problem resultieren. Insbesondere bei der simultanen Inbetriebnahme aller Module kann es zu einem hohen Termindruck kommen. Hieraus entsteht Zeitmangel bei der Parametereinstellung, welcher sich zu Lasten der Sorgfalt auswirkt. Außerdem können diese Mängel zu fehlendem Controlling bezüglich des betriebswirtschaftlichen Erfolgs des neuen Systems führen (Dittrich et al. 2009, S. 16–17).

Eine fehlerhafte Parametereinstellung in Form von einer ungeprüften Übernahme aus Altsystemen kann zu Problemen führen, wenn unterschiedliche Verfahren auf diesen Parametern basieren und verwendet werden. Bei einer Parameterübernahme aus ähnlichen Unternehmen ist zu überprüfen, ob die Parameter für den gleichen Verwendungszweck vorgesehen sind (Dittrich et al. 2009, S. 18–19).

Prototyp-Phase

In dieser Phase werden die zuvor eingestellten Parameter des ERP-System unter möglichst realitätsgetreuen Bedingungen getestet. Hierfür ist eine Übernahme der Stammdaten aus dem Altsystem ein vorbereitender Schritt. Die Möglichkeiten zur Übernahme der alten Daten variiert je nach den bisher genutzten Stammdaten. Es ist meistens nicht möglich die Daten in Form einer Exportroutine, bei der alle Daten unter Beachtung der vorgesehenen Relationen des in der neuen Standardsoftware verwendeten Datenmodells exportiert werden, zu übertragen, wenn die Daten in einer proprietären Datenstruktur vorliegen (Gronau 2010, S. 340). Alternativ besteht nur die Möglichkeit die Stammdatenlisten in ASCII-Dateien zu übertragen. Sollte auch dies nicht möglich sein, müssen die Daten manuell in das neue System übertragen werden. Die manuelle Übertragung ist zwar mit mehr Aufwand verbunden, hat aber dennoch Vorteile. Bei der Neuübertragung kann entschieden werden welche Daten übertragen werden sollen und somit können veraltete Daten, zum Beispiel Kunden die seit mehreren Jahren nichts bestellt haben oder Artikel die für das aktuelle Programm nicht mehr relevant sind, aussortiert werden. Bei einer manuellen Neueintragung der Daten überprüft das neue System mit Hilfe von Gültigkeitsüberprüfungen die Datensätze und es können keine ungültigen Daten, wie zum Beispiel ungültige Postleitzahlen, übertragen werden. Diese Daten würden bei einer automatischen Übertragung nicht überprüft werden und alte Fehler würden ins neue System eingebettet werden (Gronau 2010, S. 341).

Parametertest

Beim Parametertest handelt es sich um einen Teil der Prototyp-Phase, welcher die Überprüfung der eingestellten Berechtigungen überprüft, diese sollen korrekt die vorgesehene organisatorische Aufgabenverteilung wiedergeben. Ausdrücke des Systems, zum Beispiel Belege, Berichte oder im Geschäftsverkehr verwendete Briefe, müssen formal und inhaltlich auf ihre Richtigkeit überprüft werden (Gronau 2010, S. 341).

Hierbei lassen sich auch möglicherweise notwendige weitere Berichte einbetten. Über deren Realisierung sollte aber möglichst schnell entschieden werden, damit der geplante Produktivstarttermin nicht verfehlt wird. Außerdem gilt es in dieser Phase die Mitarbeiter an die Bedienung des Systems heranzuführen. Dies birgt die Notwendigkeit von entsprechenden Schulungen, sowie deren Vorbereitung. In diesen Schulungen sollen Kenntnisse für das neue ERP-System direkt vermittelt werden. Hierfür kann der Einsatz von Beispieldaten von Vorteil sein, da mit ihnen direkt am neuen ERP-System geübt werden kann. Wichtig ist, dass jeder Teilnehmer aktiv in diese Schulung einbezogen wird und direkt am System üben kann. Es bietet sich an die Schulungen zeitnah vor dem Produktivstart durchzuführen, damit neuerworbene Kenntnisse nicht in Vergessenheit geraten (Gronau 2010, S. 342).

Lasttests der Software sollten spätestens in der Prototyp-Phase erfolgen, um zu überprüfen, ob die gewählte Hardware den Anforderungen an das System gerecht wird. Anderenfalls besteht die Gefahr, dass Performanceprobleme erst im Lastbetrieb auffallen. Diese Performanceprobleme können im Produktivbetrieb den Erfolg der Systemeinführung maßgeblich gefährden (Gronau 2010, S. 342).

Umstellungsstrategien

Nach den vorherigen Phasen wird das System nun in einem begrenzten Probebetrieb betrieben. Für diesen Probebetrieb stehen verschiedene Optionen zur Wahl, die Aufteilung nach Geschäftsobjekten oder nach Funktionen und die vollständige Ablösung des alten Systems. Je nach Umstellungsstrategie wird zwischen diesen Optionen gewählt (Gronau 2010, S. 342).

Aufteilung nach Geschäftsobjekten

Bei der Aufteilung nach Geschäftsobjekten übernimmt das Altsystem noch ausgewählte Aufgaben und nur ein Teil der Geschäftsobjekte wird vom neuen System übernommen. Dies ermöglicht einen Test der vorgenommenen Einstellungen am realen Geschäftsobjekt. Andererseits führt diese Methode zu dem Nachteil, dass zur Sicherung der Datenintegrität im bisherigen System Doppeleingaben erforderlich sind. Diese parallele Bedienung der Systeme erfordert eine höhere Belastung der Mitarbeiter und sollte deshalb nur über einen kürzeren Zeitraum praktiziert werden. Da dieser Zeitraum bestenfalls nur im Wochenbereich liegen sollte, sind für das durchzuführende Testprogramm sorgfältige Planungen notwendig (Gronau 2010, S. 342–343).

Aufteilung nach Funktionen

Bei dieser Aufteilung werden nacheinander fertig angepasste Module des neuen Systems in den Produktivbetrieb genommen. Es erfolgt also zu verschiedenen Stichtagen die teilweise Ablösung des Altsystems durch die jeweiligen Module oder Funktionsblöcke des neuen ERP-Systems. Voraussetzung für dieses Vorgehen ist die Aufteilbarkeit des Funktionsumfangs zwischen dem alten und neuen System. Je nach Fortschritt der Systemintegration können Schnittstellen zwischen dem einzuführenden und dem alten System benötigt werden. Da die Integrationsdichte umfassender ERP-Systeme hoch ist, ist es schwierig einzelne Module des Systems zu ersetzen. Nachteilig hierbei ist der lange Zeitraum der Umstellung und dass die betroffenen Funktionen beider Systeme arbeiten müssen. Hierfür ist also der doppelte Ressourcenbedarf notwendig. In der Praxis besteht außerdem das Problem, dass betriebswirtschaftliche Aufgaben von beiden Systemen erfüllt werden können, wenn die Funktion nicht bereits im alten System deaktiviert wurde. Dies erhöht den Aufwand bei der Datenintegration und -konsolidierung im neuen System (Gronau 2010, S. 343).

Vollständige Ablösung des alten Systems

Die direkte vollständige Ablösung eines oder mehrerer Altsysteme, zu einem bestimmten Stichtag, durch das neue ERP-System wird auch als „Big Bang“ bezeichnet. Durch diese Methode wird die vorübergehende Einführung von Schnittstellen zum Altsystem umgangen. Somit verkürzt sich der Umstellungszeitraum deutlich. Hierbei bestehen aber höchste Anforderungen an die Qualität des neuen Systems, da diese Methode ein hohes Risiko birgt, weil kein Altsystem mit den aktuellsten Daten zur Verfügung steht. Im Falle von Fehlern werden die betroffenen Geschäftsprozesse also direkt beeinträchtigt (Gronau 2010, S. 343).

Externe Projektsteuerung

In der Praxis lassen Unternehmen sich häufig nur zu einem ERP-System beraten und wollen die Einführung des ERP-Systems selbst stemmen, jedoch verfügen nur wenige Unternehmen über deine ausreichende ERP-Reife um die ERP-Einführung allein mit dem liefernden Softwarehaus erfolgreich zu gestalten. Wenn die notwendigen personellen Ressourcen und das notwendige Wissen zur Optimierung der Geschäftsprozesse fehlt ist eine externe Projektsteuerung notwendig (Gronau 2015, S. 43).

Erkennbare Anzeichen für die Notwendigkeit einer externen Projektsteuerung sind unter anderem ein Rückstand im Zeitplan für die Einführung des ERP-Systems, Qualitätsmangel des Anbieters, schwächere Funktionalität als ursprünglich erwartet, Kommunikationsprobleme zwischen Anbieter und Kunde, ein höherer Projektaufwand als erwartet, Auslastung der internen Kapazitäten, Mitarbeiter des Anbieters verfügen nicht über die erwarteten Fähigkeiten und eine Auslastung des Managements des Kunden durch andere Aufgaben. Eine externe Projektsteuerung überwacht Qualität, Zeit und Projektkosten und vermittelt zwischen Anbieter und Kunde. Es werden Ressourcen bei Kunde und Anbieter angefordert, damit der geplante Zeitrahmen eingehalten wird. Die externe Projektsteuerung erinnert also an bevorstehende Termine und behält den Zeitrahmen stets im Auge. Es werden außerdem Vorschläge bezüglich der Ressourceneinteilung des Anbieters überprüft. Sollte es zu Terminverschiebungen kommen, wird die Ursache ausfindig gemacht und dem Kunden oder Anbieter zugeordnet. Der Zeitplan kann zusätzlich aufgrund von Änderungswünschen angepasst werden. Ein wichtiger Bestandteil der externen Projektsteuerung ist das Qualitätsmanagement, hier werden Arbeitspakete erst nach Prüfung abgenommen, Validierungsanforderungen beachtet, Fachkonzepte beurteilt, Schulungsmaßnahmen und deren Ergebnisse berücksichtigt, dokumentiert, sowie Testverfahren und -ergebnisse den jeweiligen Zielerreichungsgraden zugeordnet. Außerdem wird die Systemperformance eingeschätzt und die notwendige Datenqualität gefordert. Außerdem trägt eine externe Projektsteuerung auch zur Kostendisziplin bei weil die Auswirkungen von Änderungen auf die Projektkosten berechnet werden und Anbieterrechnungen überprüft werden, so können falls nötig nicht geleisteter Anbieteraufwand angefochten werden. Praxiserfahrungen zufolge lohnt sich die Einschaltung einer externen Projektsteuerung schon allein aufgrund der direkt gesparten Kosten beim Anbieter (Gronau 2015, S. 44).

Mit Hilfe einer RoI-Analyse kann im Vorfeld des ERP-Projektes der Wert der Zeiteinhaltung bemessen werden (Gronau 2012, S. 127).

Dieses Qualitätsmanagement beugt Fehler vor und senkt die Kosten unmittelbar vor oder während des Produktivstarts (Gronau 2015, S. 44).