Schlimmer als Brexit, Trump und Handelskrieg...

Das Werkzeug, die gewählte Software, ist nicht primär für Probleme verantwortlich. Aber jeder einzelne der nachstehenden Gründe kann die Implementierung eines Enterprise-Resource-Planning-Systems grandios zum Scheitern bringen ...

Ressourcen (Personal)

• Jede ERP-Einführung braucht Unterstützung durch Menschen. Die Projektteams sind meist heterogen aufgesetzt. Das heißt, Spezialisten vom Implementierungsdienstleister arbeiten zusammen mit Mitarbeitern des betroffenen Unternehmens, die als Key-User über besonderes Hintergrundwissen rund um die jeweiligen Abläufe im Unternehmen verfügen (sollten).
• Häufig entstehen hier schon erste Schwierigkeiten, wenn das Management die zusätzliche Aufgabe ihrer Mitarbeiter nicht klar und eindeutig von den sonstigen Aufgaben im Tagesgeschäft abgrenzt. Ohne klare Aufteilung hinsichtlich der Arbeiten für das Projektteam sind Frust, Unzufriedenheit und fehlende Unterstützung im Projekt vorprogrammiert. Hier muss absolute Transparenz herrschen! Die Aufteilung kann über verschiedene Projektphasen hinweg variieren: wenn das Projekt hochgefahren wird (sogenanntes Ramp-Up) wirken die Mitarbeiter mit einem hohen Anteil von 70/30 (Projekt zu Tagesgeschäft) bei der Konzeption bzw. einem BluePrint mit. Während der Implementierung wird dieser Einsatz beispielsweise auf 20/80 reduziert und gegen Ende dann für die Integrations- und Abnahmetests wieder auf einen Anteil von 80/20 erhöht.
• Transparenz und Klarheit über die jeweils zu leistenden Aufwendungen sind das A und O im Projekt, was eine sorgfältige Abstimmung nicht nur mit den betroffenen Mitarbeitern, sondern auch jeweiligen Teamleitern (Tagesgeschäft) voraussetzt. Dabei sollte man gerade in frühen Phasen des Projektes ausreichend Zeit für die dazu notwendigen Abklärungen und gegebenenfalls erforderliche Aus- & Weiterbildung der betroffenen Mitarbeiter einplanen.

Projekt Know-How

• Meist ist das theoretische Rüstzeug für Projektmanagement Methoden vorhanden. Wir stellen aber häufig fest, dass es an praktischen Erfahrungen und einer engen Zusammenarbeit mit der Führungsebene mangelt. Leider wird aufgrund einer fehlenden Seniorität häufig versäumt, unangenehme Wahrheiten zu kommunizieren, Fehler offen zu be- und Probleme rechtzeitig anzusprechen. Mit der Konsequenz, dass der Projektstatus lange schön geredet wird und die Entscheider oft unsanft aufwachen, weil sich die Probleme nicht länger kaschieren lassen.
• In diesen Fällen leistet ein externer Projektmanager bzw. -leiter oder auch Projektsteuerer wertvolle Unterstützung. Er stellt mit seiner Seniorität und dem fachlichen Background die Augenhöhe zwischen Dienstleister und Entscheidern her. Dabei unterliegt er keinen internen Abhängigkeiten, kann also offen und fokussiert agieren.

Standards versus Customizing

• Der Klassiker aller Verzögerungen: Es gibt kein detailliertes Pflichtenheft (häufig als BluePrint bezeichnet)! Stattdessen wird der Auftrag an den Implementierer mit zahlreichen "Standards" erteilt. Nicht selten mischen sich dabei technische Standards & Methoden mit "Best Practice" Ansätzen aus der jeweiligen Branche. Übersehen wird häufig der Umstand, dass diese "Best Practice" nur eine Summe aller Module darstellt, die von anderen Markt- & Branchenteilnehmern ausgewählt und implementiert wurde. Eine Prüfung des Matching für die eigenen Prozesse oder entsprechende Anpassungen im Vorfeld (Konzeption / BluePrint) unterbleibt. Oft wegen der damit einhergehenden, finanziellen Auswirkungen.
• Im Verlauf des Projektes kommen die Key-User aus der Praxis mit dem eigenen Verständnis der internen Abläufe, die sie natürlich 1:1 in der neuen Lösung wiederfinden wollen. Passend dazu folgt die Argumentation, dass der jeweilige Prozess schließlich eine Besonderheit des Unternehmens ist (ohne die man nie so erfolgreich geworden wäre). Klar ist, wenn man alles nur im Standard löst und die Wünsche der Anwender ignoriert, entsteht Widerstand, der die Einführung verlangsamt oder zu Blockaden führt.
• Entscheidend ist auch hier eine klare Positionierung des Unternehmens. Idealerweise ist diese im Vorfeld verbunden mit einer detaillierten Konzeption (BluePrint) unter Einbeziehung der relevanten Key User aus allen Bereichen. Ein stringenter, emphatischer Projekt-Verantwortlicher nimmt die Mitarbeiter auf diesem Weg mit und findet immer wieder die Balance zwischen Terminen, Kosten und Ergebnis. Dazu gehört auch die fachliche Expertise, die jeweiligen Auswirkungen von Anpassungen transparent zu machen.
• Sofern es relevante Entscheidungsgremien gibt, um über solche Änderungen zu entscheiden (ein sogenanntes Steering Committee), gehören faktisch belegte und entsprechend dokumentierte Entscheidungsvorlagen zu jedem Change, moderiert vom Projekt Verantwortlichen.

Wenn schon Customizing, dann ein klarer Change Prozess!

• Diese wesentliche Komponente jedes komplexeren IT-Projektes wird oft völlig unterschätzt. Dabei werden Veränderungen gerne und fälschlicherweise in die Schublade "IT-Thema" gesteckt. Tatsächlich geht es meist um neue Prozesse und Abläufe, welche die gesamte Organisation fordern und sorgfältiger Abstimmung mit den involvierten Abteilungen und Teams bedürfen. Wenn Mitarbeiter neue Rollen & Aufgaben bekommen, möglicherweise sogar Tätigkeiten wegfallen, ist auch der Betriebsrat mit im Boot.
• Hier bedarf es einer klaren Prozess-Methodik inklusive stringenter Führung durch den Projektverantwortlichen. Alle offenen Themen und TODOs sollten transparent für alle Beteiligten elektronisch dokumentiert und fortlaufend aktualisiert werden. Dabei ist die Unterscheidung zwischen Veränderungen (Changes) und im Verlauf erkannten Problemen (Fehler im Prozess oder der Software) entscheidend für eine nachhaltige Behandlung und Behebung (Bugfixing).
• Auch für die Kostenseite ist eine klare Differenzierung entscheidend, soweit es die vertraglichen Vereinbarungen mit dem Implementierungsdienstleister hergeben. Dabei gelten Veränderungen (Changes) meist als kostenpflichtig, während Probleme mit erforderlichem Bugfixing abhängig von der Vertragsausprägung durchaus als "inkludiert" gelten können und somit keine weiteren Kosten für den Kunden verursachen.

Migration der Stammdaten

• Entscheidend für eine erfolgreiche Einführung ist die Mitnahme all jener Daten, die im vorherigen System über viele Jahre oder gar Jahrzehnte aufgelaufen sind.
• Dabei müssen die Erwartungen von Entscheidern an die Qualität dieser Vorgänger-Daten meistens deutlich reduziert werden. Im schlimmsten Fall gibt es keine oder völlig unterschiedlich strukturierte Stammdaten, die über mehrere (historische) Systeme bzw. Datenbanken verteilt sind, über viele Jahre stiefmütterlich gepflegt wurden und in der Folge stark veraltet sind. Dopplungen, unterschiedliche Schreibweisen oder verschiedene Versionen sind nur ein Ausschnitt jener Probleme, die mit Alt-Daten verbunden werden.
• Für moderne ERP Systeme müssen die Stammdaten aufwendig aufbereitet oder gar zusätzlich generiert werden, um in den neuen Strukturen zur Anwendung zu kommen. Auch für die im späteren Verlauf anstehenden Tests der Software ist ein solider Datenbestand unbedingte Voraussetzung, um dateninduzierte Fehler in der Software frühzeitig zu finden und zu beheben.
• Dazu ist es wichtig, dass klare Vorgehensweisen und ein Stammdaten-Verantwortlicher und gegebenenfalls erfahrene Programmierer früh im Projekt allokiert und festgelegt werden. Entsprechende Rollen und Verantwortungen müssen klar geregelt sein. Die für einen Projekterfolg maßgebliche Unterstützung durch entsprechende Fachleute rechtzeitig organisiert und zum richtigen Zeitpunkt eingesteuert werden. Zusätzliche Tools wie zum Beispiel Excel mit einem versierten Programmierer kommen schnell und pragmatisch zum Einsatz, um die notwendige Prüfung, Korrektur und Transformation der Altdaten zu gewährleisten.

Klare Prioritäten

• Die meisten Unternehmen unterliegen dynamischen Entwicklungen aus dem Tagesgeschäft, deren Auswirkung eine flexible Anpassung von Prioritäten verlangt. Ein neuer Großkunde, Druck vom Mitbewerb, neue Produktanforderungen oder der Zukauf eines anderen Unternehmens. Denkbare Gründe sind vielfältig und berechtigt, fordern aber auch die Projektbeteiligten in ihrem Tagesgeschäft und bedürfen eines klaren Committment vom Top-Management.
• Wird die Priorität eines laufenden Einführungsprojektes im Verlauf geändert, muss  immer mit massiven Auswirkungen auf Termine und Kosten gerechnet werden. Sei es durch fehlende Unterstützung/Beteiligung von Key Usern als auch durch neue Terminziele, die beim Implementierungsdienstleister zu Verzögerungen und zusätzlichen Kosten führen.
• Diese Veränderungen müssen vom Projektverantwortlichen mit allen Implikationen transparent gemacht und an das Top Management kommuniziert werden. Dabei darf es keine Ausflüchte im Sinne von "... das schaffen wir schon ..." geben. Eine neue Projektplanung unter Berücksichtigung aller Prämissen muss kurzfristig aufgelegt und von allen Entscheidern der Beteiligten unterzeichnet werden.
• Sofern möglich, können zusätzliche, externe Ressourcen herangezogen werden, um fehlende Unterstützung von Mitarbeitern zu kompensieren. Sofern zum Planungszeitpunkt (neue Prioritäten) hinreichend Projektzeit "übrig" ist, ist der Einsatz zusätzlicher Ressourcen sinnvoll. Zu einem späten Zeitpunkt (z. B. kurz vor GoLive!) müssen die Unterstützer perfekte Voraussetzungen mitbringen, um schnell und ohne große Einarbeitung sofort produktiv wirksam zu werden.

Einführungsstrategie

• Die Strategie und der zeitliche Ablauf der Einführung muss präzise geplant und rechtzeitig kommuniziert werden. Dabei müssen Umfeldbedingungen (Ferien, Saisonzeiten etc.) wie auch mögliche Risiken (Ausfall von Leistungsträgern, Verzögerungen bei der Implementierung) berücksichtigt werden. Schwierig zu finden und häufig unter einem Kostendruck nicht realisierbar, ist die Balance zwischen einer agilen Strategie mit kleinen Zwischen-Ergebnissen (sogenannte "Sprints") und einer Wasserfallartigen "Big Shot" Einführung zu einem alles entscheidenden Termin.
• Es gibt für beide Strategien gute Argumente. Die Herausforderung für einen erfahrenen Projekt-Verantwortlichen liegt darin, die richtige Mischung in Form einer modernen, oft hybriden Strategie zu finden.

Test der Lösung

• Komplexe Softwarelösungen in Verbindung mit neuen Prozessen und Abläufen verlangen unabdingbar, dass sich die Tester aus dem Umfeld der Key User tief mit dem neuen System vertraut machen. E häufiger Fehler ist die unzureichende Vorbereitungsphase der Projekte. Am Rande einer seriösen Konzeption enthält der BluePrint idealerweise schon die relevanten Testfälle (sogenannte "UseCases"), mit denen später die korrekte Umsetzung der Vorgaben überprüft wird.
• Ein Fehlen dieser vorbereitenden Maßnahmen oder der kompetenten Ausbildung der Tester hat auf den Gesamtprozess enorme Auswirkungen. Schon die Unterscheidung von Bedienungsfehlern und echten Problemen kann eine große Herausforderung werden, die durch sorgfältige Schulung im Vorfeld ihren Schrecken verliert. Ohne umfassende Testzyklen werden Probleme einzeln analysiert und behoben, nicht selten sind Key User beim Nachtest von Fehlerbehebungen nicht mehr im Thema und verlieren viel Zeit für das Projekt.
• Für die einzelnen Testphasen ist ausreichend Zeit im Projektplan zu berücksichtigen, um die funktionalen Tests konzentriert und sorgfältig in einem praxisnahen Umfeld durchzuführen. Je nach Ergebnis müssen einzelne Tests mehrfach wiederholt werden, ein seriöser Projektplan berücksichtigt diese Praxiserfahrung entsprechend. Bewährt hat sich auch hier eine eher agile Vorgehensweise, mit der in einem festen 2-3 Wochen Sprint alle relevanten Key User gemeinsam in einem Raum alle wesentlichen Prozesse in der richtigen Reihenfolge von Anfang bis zum Ende ausprobieren und so die Lösung funktional testen.

Schulungen

• Oft das ungeliebte Stiefkind jedes Projektes. Schulungen kosten Geld und Zeit, die betroffenen Mitarbeiter stehen nicht für das Tagesgeschäft zur Verfügung.
• Die Planung und Koordination der Schulungen ist zeitaufwendig. Wenn es nicht gelingt für die zahlreichen Anwender der neuen Software gemeinsame Schulungstermine zu finden, muss das Top-Management ein Machtwort sprechen.
• Das Erfolgsrezept eines funktionierenden Schulungskonzeptes setzt sich zusammen aus der rechtzeitige Planung, der Aufteilung aller Schulungsinhalte auf Gruppen und Themenbereiche, der transparenten Kommunikation über das gesamte Projekt hinweg und der Berücksichtigung von Nachzüglern.