Ein neues ERP soll das Unternehmen beflügeln. Die Verträge mit dem Softwareanbieter sind unterschrieben, und nun soll so bald als möglich mit der neuen Software gearbeitet werden. Doch die Einführung eines ERP ist alles andere als trivial. Immer wieder hört man erstaunliche Stories von grandiosen Projektmisserfolgen. Wie geht man am besten vor? Wo liegen Stolpersteine? Schliesslich will man ja nicht die gleichen Fehler machen wie andere.
Ziel einer Softwareauswahl ist es, die für die individuellen Anforderungen eines Unternehmens am besten geeignete Software zu bestimmen. Dabei ist es mit der Nennung eines Produktes natürlich bei weitem nicht getan. Hinter jeder Lösung stehen Menschen. Entsprechend sind ausgewiesene Fachleute notwendig, um den Personen im Unternehmen ein effizientes Arbeiten mit der neuen Software zu ermöglichen. Solche Spezialisten müssen einerseits tiefes Know-how in Bezug auf die neue Business-Software mitbringen, andererseits aber auch die Anwenderorganisation und deren Geschäftsprozesse kennen. Wobei Kennen noch harmlos ausgedrückt ist. Sie müssen auch in der Lage sein, gegebenenfalls liebgewordene Gewohnheiten der täglichen Arbeit in Frage zu stellen und neue Abläufe durchzusetzen. Und zwar auf allen Hierarchiestufen, nicht nur am unteren Ende der Befehlskette.
Unterschiedliches Know-how muss zusammenfliessen
Personen, welche Fähigkeiten mitbringen, um sowohl interne Prozessverbesserungen gestalten und durchsetzen zu können, als auch technische Eingriffe im neuen ERP vornehmen zu können und deren Auswirkungen abzuschätzen, finden sich intern kaum. Es braucht daher in jedem Fall eine Projektorganisation, welche Mitarbeitende mit diesen unterschiedlichen Fähigkeiten zusammenbringt. In den meisten Fällen werden dabei die Fachspezialisten für das neue ERP-System auch gleich vom neuen Softwareanbieter gestellt. Die Softwareauswahl hat daher das Minimalziel, ein „Paket“ aus Implementationspartner und Software zu schnüren. Etwas anders sieht es bei den internen Fachspezialisten für die Prozessgestaltung und –umsetzung aus. Sinnvollerweise spielen diese bereits bei der Auswahl der Software eine zentrale Rolle um die Anforderungen an die neuen Geschäftsprozesse zu definieren. Tatsächlich werden also die Weichen für eine erfolgreiche Softwareeinführung schon lange vorher gestellt, bevor die eigentliche Installation und das Anpassen losgeht. Die tragfähige Basis wird idealerweise während der Softwareauswahl mit der Prozessgestaltung gelegt.
Das aufgebaute Know-how sichern
Mit dem Entscheid für eine bestimmte Software und deren Implementationspartner wird das interne Projektteam um die entsprechenden externen Kompetenzen ergänzt. An dieser Stelle ist darauf zu achten, dass wirklich eine Ergänzung vorgenommen wird und nicht versucht wird, die bisherigen Treiber und Wissensträger ersatzlos zu streichen. Um von der Investition in die methodische und umfassende Softwareevaluation zu profitieren, gilt es nun, beim Projektstart den neuen Projektpartner effizient in das Know-how über die anvisierten Sollprozesse einzuführen.
Das reibungslose Zusammenspiel von externem und internem Projektleiter ist von entscheidender Bedeutung, bringen doch beide Seiten für den Projekterfolg wichtiges Know-how ein. Bei Problemen übernimmt die Steuergruppe die Schlichtungs- und Entscheidungsfunktion. Gleichzeitig obliegt ihr auch das Gesamtcontrolling des Projekts.
Die Projektleitung sinnvoll einrichten
Die neuen Geschäftsprozesse müssen im ERP umgesetzt werden und definieren daher die benötigte Funktionalität der Software. Auch nach der Vertragsunterzeichnung sind die Kompetenzen über die Prozesse als auch jene über die IT-Möglichkeiten gleichermassen gefragt. Ein ERP-Projekt zu leiten, bedeutet daher weit mehr, als nur Termine und Kosten im Griff zu halten. Es bedeutet, die Welt der IT und der Geschäftsprozesse zusammenzubringen und daraus eine effiziente Unterstützung aller Mitarbeitenden im Unternehmen zu formen. Neue Arbeitsabläufe und Arbeitsmittel zu nutzen, bedeutet für die betroffenen Mitarbeitenden stets eine Veränderung. Auch wenn die Notwendigkeit dafür bekannt ist, so werden trotzdem Widerstände dagegen auftauchen – und zwar auf allen Hierarchiestufen. Diese Widerstände können zwar durchaus auch einmal offen zu Tag treten, in der Regel wird der Widerstand aber recht unbewusst im Detail gelebt. Es werden beispielsweise weiterhin Excel-Tabellen geführt, statt dass die entsprechenden Funktionen im ERP genutzt werden. Die Projektleitung muss daher mit Kompetenzen ausgestattet sein, um umfassende Prozessänderungen diskutieren und durchsetzen zu können. Das allein genügt aber nicht: Es braucht auch eine Menge Geduld um die Mitarbeitenden zu schulen und sie in der Ausführung ihrer Arbeit mit dem neuen Werkzeug zu begleiten.
Das reibungslose Zusammenspiel von externem und internem Projektleiter ist von entscheidender Bedeutung, bringen doch beide Seiten für den Projekterfolg wichtiges Know-how ein. Bei Problemen übernimmt die Steuergruppe die Schlichtungs- und Entscheidungsfunktion. Gleichzeitig obliegt ihr auch das Gesamtcontrolling des Projekts.
Sehr oft wird das Projektteam mit zwei Projektleitern ausgestattet. Derjenige mit dem ERP-Know-how wird vom Software-Anbieter gestellt und arbeitet auf Augenhöhe eng mit dem von der Anwenderfirma gestellten Projektleiter zusammen, welcher die interne Umsetzungskompetenz in der Ablauforganisation hat und idealerweise schon die Evaluationsphase leitete. Je nach Projekt- und Firmengrösse werden die Projektleiter weitere Mitarbeiter benötigen um technische Aufgaben zu lösen aber auch um die Umsetzung flächendeckend möglich zu machen. Auch bei einem ideal bestückten Projektteam können unterschiedliche Ansichten zu einer Patt-Situation zwischen den beiden Projektleitern führen. Eskalationswege sind daher zu definieren, damit in einem solchen Fall die verschiedenen Möglichkeiten und deren Auswirkungen in einer Steuergruppe besprochen werden können. Die Steuergruppe wird nicht selten mit einer aussenstehenden Person bestückt, welche allenfalls auch zwischen den Parteien vermittelt. Wird frühzeitig eskaliert, so ist dies in der Regel für den Projektverlauf positiv. Schlimmer wirken sich Probleme aus, welche nie genau erkannt wurden und – über längere Zeit mitgeschleppt – das Projekt bremsen oder gefährden.
Die Stolpersteine vermeiden
IT-Projekte können scheitern. Glaubt man den offiziellen Quellen, so geschieht dies sogar recht oft. Dabei sind Projekte zur Entwicklung einer Individualsoftware häufiger betroffen als solche für die Einführung einer Standardsoftware. Dies ist auch die gute Nachricht: Beim ERP als einzuführende Standardsoftware kann davon ausgegangen werden, dass es technisch funktioniert. Mindestens so lange man im Standard der Software bleibt, ist nicht mit technischen Problemen zu rechnen. Technische Probleme können dann entstehen, wenn das ERP umgebaut wird. Schnittstellen zu Umsystemen können dabei eine Quelle nachhaltigen Ärgers darstellen. Umfassende ERP-Systeme decken heute ein sehr breites funktionales Spektrum ab. Ob Schnittstellen zu anderer Software wirklich nötig sind, muss daher gerade bei KMU hinterfragt werden. Oft werden dazu aber schon in der Evaluationsphase die Weichen falsch gestellt. Gesucht wird eine Ergänzung der bereits zerstückelten Softwarelandschaft, anstatt die Chance zur Integration zu nutzen.
Die häufigen Probleme bei der Software-Einführung sind organisatorischer Natur:
- Ungünstige Evaluation. Wenn hier versucht wird, Zeit und Geld zu sparen, so wird sich das später rächen. Die Entwicklung realistischer Sollprozesse und ein angemessener Aufbau von Know-how sind notwendig für die Ausschreibung und bilden die Basis für eine erfolgreiche Einführung.
- Ungünstige Zeitvorgaben. Sowohl für die Auswahl als auch für die Einführung der Software braucht man Zeit. Bei unrealistisch kurzen Vorgaben lässt sich die Zeit nicht gewinnen, in dem wichtige Schritte übersprungen werden. Und falls das trotzdem versucht wird: Diese Schritte lassen sich später kaum mehr vernünftig nachholen. Eine zu lange Laufzeit kann allerdings auch problematisch werden, weil sich dann im Laufe des Projektes zu viele Randbedingungen ändern.
- Unklare Zuständigkeiten. Das Projektteam muss mit klaren Kompetenzen ausgestattet sein. Schwierig kann es z.B. bei inhabergeführten Unternehmen werden, wenn der Besitzer selbst spontan die Strukturen aushebelt und sich niemand getraut, die Konsequenzen aufzuzeigen. Königreiche, welche sogar vom Topmanagement selbst gepflegt werden, können sinnvolle Lösungen verhindern und zu teuren Basteleien verleiten.
- Ignorieren der Abmachungen. Zwar legen die meisten Anbieter mit schönen Grafiken los, welche die Etappen der Einführung und dazwischen die Meilensteine zeigen. Die Idee dahinter ist, dass vor jeder neuen Etappe zuerst alle Bedingungen des vorgängigen Meilensteins erfüllt sein müssen. Wer dies vernachlässigt – so nach dem Motto: Ach, wir sind ja alle mit grossem Einsatz und gutem Willen dabei, und wenn noch Kleinigkeiten fehlen, kann man die später noch nachholen – verpasst die Chance eines reinigenden Eskalationsgewitters. Hoffen, dass man schon noch aufholt und niemand etwas merkt, ist sehr problematisch. Lieber frühzeitig eskalieren und die notwendigen Mittel zur Korrektur abholen.
- Undefinierte Änderungen. Änderungen brauchen Zeit und Geld. Werden diese Parameter nicht offiziell zur Verfügung gestellt, droht Ärger. Es braucht dauernd wachsame Geister, welche feststellen, ob Anforderungen im Auftrag enthalten sind oder zu unvorhergesehenen Ausgaben und Verzögerungen führen. Dieser Weg muss über die Projektsteuergruppe und über Change Requests führen. Und zwar nicht erst zu einem Zeitpunkt, wenn keine anderen Möglichkeiten mehr offen stehen.
Natürlich lauern noch weitere Fallen in einem ERP-Projekt, beispielsweise durch ungeeignete Arbeitsteilung oder einer Hemmschwelle, sich als Projektleiter tief mit der neuen Software auseinanderzusetzen. Um solche Fehler zu vermeiden, kann die Erfahrung eines professionellen Beraters sinnvoll genutzt werden. Konkrete Tipps finden sich auch im Buch „Das ERP als Erfolgsfaktor im Unternehmen“.
