Risikomanagement bei der Einführung von Business-Software

Wer möchte schon die Euphorie des - häufig nicht ohne Widerstand erkämpften - Aufbruchs durch Gedanken an Gefahren und Risiken dämpfen? In der Folge ist Risikomanagement ein Feld, das bei der Einführung von Business-Software noch immer stiefmütterlich behandelt wird.

Von der Lösung zum Problem

Die Einführung von Business-Software ist zu einem der am stärksten wachsenden Märkte der letzten Jahre geworden. Während die Geschäftsleitung im Einsatz von moderner Business-Software einen strategischen Wettbewerbsvorteil sieht, ist die Euphorie auf Seiten der betroffenen Anwender in der Regel beschränkt. Bei den externen Beteiligten stehen die positiven Aspekte im Vordergrund: Für junge Hochschulabsolventen stellt Business Software eine Karriereleiter par excellence dar, für zahlreiche Anbieter ist sie eine Goldgrube und immer mehr Beratungshäuser sehen im Auf- und Ausbau von Implementationsdienstleistungen die Möglichkeit zu einem rasanten Wachstum.

Business-Software wird dabei mit einer geradezu mystischen Grundhaltung betrachtet. Sie ist im Verbund mit Reengineering zum "Deus ex machina" moderner Organisationsgestaltung geworden. Dabei scheint die Meinung vorzuherrschen, die Einführung von Business-Software bliebe ganz ohne Nebenwirkungen, wie dies oft in Anzeigen von Softwarehäusern suggeriert wird. Die Realität ist hier weit nüchterner: was noch zu Beginn nicht selten mit kessen T-Shirts und einer Sonderausgabe der eigenen Hauszeitschrift gefeiert wurde, wird nicht selten von der Lösung zum Problem.

Wenn nicht bereits während der eigentlichen Einführungsphase die Probleme im eigenen Unternehmen mit aller Deutlichkeit etwa in Form von politischen Machtkämpfen zwischen Promotoren und Gegnern des häufig mit einer neuen Software eingeführten, neuen Denkens hervorbrechen, kommt in vielen Fällen spätestens nach dem Produktivstart das böse Erwachen. Die bis dahin in der Regel stark abgespeckte Lösung wird immer wieder zum Problem an sich. Tage oder gar Wochen mit hohen Produktivitätsausfällen und ohne jede Möglichkeit zur Auslieferung sind nicht selten. Die krassesten Fälle kann man häufig in der einschlägigen Fachpresse wieder finden. Hier finden sich auch Berichte von millionenhohen Investitionsruinen, bei denen das Projekt vorzeitig beendet wurde.

Worst Case Szenarien: Ein Beispiel aus der Praxis

Innerhalb von 16 Monaten hatte ein Großunternehmen ein neues Standardsoftware-Paket in den Bereichen Finanzen, Personalverwaltung und Betriebsbuchhaltung eingeführt. Nach etlichen Erfahrungen mit der Eigenentwicklung von Software hatte man sich auf ein Standardpaket eines der Marktführer geeinigt. Mehrere Tausend Kunden versprachen Zuverlässigkeit des Systems und ausreichendes Know-how für die Einführung. Zum geplanten Stichtag ging das neue System "produktiv", die alte Software musste bereits nach wenigen Tagen abgeschaltet werden, da ein längerer Parallelbetrieb schon aufgrund der Datenmengen undenkbar war. Ziel war es, einen Monat später wieder wie gehabt Rechnungen verschicken zu können.

Eine genaue Überprüfung der ersten Rechnungen zeigte jedoch etliche, zum Teil gravierende Fehler. Schnell beschloss man, sich noch etwas Zeit zu lassen, und zwei Monate später auch die Rechnungen des Vormonats zu verschicken. Was als Projektende mit kleinen Schrecken betrachtet wurde, wurde jedoch schnell zu einem Schrecken ohne Ende: es sollte noch weitere vier Monate dauern, bis wirklich Rechnungen verschickt werden konnten. Bis dahin waren einige bereits gut ein halbes Jahr alt. Lange kämpfte die eigene Buchhaltung mit falschen Daten und säumigen Zahlern. Neben dem finanziellen Mehraufwand durch die verlängerte Einführung steht ein erheblicher Verlust in der Bilanz und ein noch immer unbezifferter Imageschaden.

Komplexe Gefahrenfelder

Um Probleme, wie im beschriebenen Fall zu vermeiden, ist es notwendig, Risikomanagement als aktive Aufgabe des Projektmanagements zu begreifen. Die Einführung von Business-Software muss nüchtern als Aufgabe betrachtet werden, die sich zwar als sehr komplex, aber auch als machbar darstellt. Im vorgestellten Beispiel lag der Fehler auf mehreren Ebenen: Während des Customizing wurde die Möglichkeiten des Systems voll ausgeschöpft. In der Folge entstand ein komplexes Gebilde, dessen Funktionsfähigkeit nicht mehr sicher gewährleistet war. Zugleich wurde die Leistung der Systemberater überschätzt, die zu jeder Zeit Herr der Lage zu sein schienen. Als sich die Probleme bereits kurz vor der eigentlichen Einführung abzeichneten, wurden diese von der Projektleitung bewusst zurückgehalten, um das ohnehin von einigen Seiten ungeliebte Projekt vor dem vollständigen Abbruch zu bewahren.

Die Gefahrenfelder bei der Einführung von Business-Software sind zahlreich:

• Unternehmenspolitik:

Allem zum Trotz, Business-Software findet in Unternehmen immer wieder Freunde und Gegner. Nicht selten werden die lang anhaltenden Auseinandersetzungen auf dem Rücken des Projektteams ausgetragen und gefährden den Projekterfolg.

• Technologie:

Technologie ist eines der offensichtlichsten Probleme von Standardsoftware. Altbewährte Systeme sind robust aber komplex, moderne Systeme sind häufig noch immer instabil, versprechen aber eine lange Zukunft. Nur beste Technologiekenntnisse im eigenen Haus versprechen hier Abhilfe.

• Marktentwicklung:

Der Markt rund um Business-Software ist ein Boommarkt auf dem die Goldgräberstimmung noch immer vorherrscht. Entsprechend wechselhaft treten Anbieter am Markt auf. Heute noch an der Spitze können sie schon morgen der Vergangenheit angehören.

• Unternehmensorganisation:

Moderne Business-Software ist "Org Ware", d.h. mit der Einführung soll ganz bewusst eine Organisation gestaltet und verändert werden. Obwohl dieser Zusammenhang bei der strategischen Entscheidung eine große Rolle spielt, herrschen in der Praxis häufig paradoxe Situationen vor: einerseits wird vor jeder Form von Veränderung immer wieder zurückgeschreckt, anderseits kommt es immer wieder zum globalen Rundumschlag.

• Endanwender:

Der Endanwender ist die Maßschnur für den Projekterfolg. Ist er kompetent und motiviert im Umgang mit dem System, bleibt der Erfolg nicht aus. Umgekehrt schaffen es Endanwender immer wieder, ein frisch implementiertes System in kürzester Zeit mittels Access-Applikationen und Excel-Tabellen auszutricksen. Noch immer werden die Endanwender gerne als Störfaktor für das Projektteam verstanden, denen es an Verständnis und Wissen mangelt.

• Projektteammitglieder:

Die Einführung einer Business-Software ist Profilierungsmöglichkeit und endlose Strapaze zugleich. Innerhalb des Projektteams kommt es mit der näher rückenden "Deadline" (Todeslinie!) immer wieder zur Verrohung, Stresserscheinungen nehmen überhand und einzelne Mitglieder fallen vollständig aus. Diese Phänomene sind hinlänglich bekannt, werden aber gerade von den Vorgesetzten geflissentlich ignoriert.

• Externe Berater:

Externe Berater sind integraler Bestandteil eines jeden Projektes. Ohne sie geht nichts. Es gibt durchaus kompetente Berater, diese sind auf dem Markt jedoch sehr rar. Die Realität besteht hauptsächlich aus viel Inkompetenz und Halbwissen. Gerade bei so hohen Investitionen, wie sie bei der Einführung von Business-Software getätigt werden, ist es sinnvoll, den externen Beratungspartner im positiven wie im negativen in die Verantwortung mit einzubeziehen.

Die Schwierigkeit eines Risikomanagement ergibt sich in der Interaktion einzelner Faktoren, der Anzahl und Heterogenität der betroffenen Gruppierungen im Unternehmen und im gesamten Projektumfeld sowie durch das Zusammenwirken von technischen, wirtschaftlichen, sozialen und emotionalen Faktoren.

Risikomanagement als aktive Aufgabe des Projektmanagements

Die Einführung von Business-Software ist machbar, dass beweisen nicht zuletzt die unzähligen erfolgreichen Anwendungen. Dennoch, sie ist kein Kinderspiel und ist durch zahlreiche Hindernisse gekennzeichnet. Mittels Szenariotechniken ist es möglich, sich bereits im Vorfeld von bestimmten Problemen mit diesen auseinander zu setzen. Risikomanagement muss dazu als konsequente und aktive Aufgabe des Projektmanagements verstanden werden.

Weitere Informationen erhalten sie unter weiss@i2s-consulting.com