Kein Zweifel. Bei der Einführung einer neuen Geschäftssoftware kann viel schiefgehen.
Unterschätzte Risiken
Nach einer europaweiten Studie des Wirtschaftsforschungsinstituts Economist Intelligence Unit (EIU) im Auftrag des BTO-Anbieters Mercury liefern nur 49 Prozent aller Technologie-Projekte einen messbaren geschäftlichen Erfolg.
Meist werden zudem die Projekt-Risiken unterschätzt. Werden Zeitpläne und Fristen überschritten, verzögert sich nicht nur der geplante Einsatz einer neuen Business-Software, sondern führt auch zu betriebswirtschaftlich negativen Folgen. Einerseits dreht sich dadurch die Kostenspirale unaufhaltsam nach oben, andererseits kann es zu erheblichen Beeinträchtigungen bei betrieblichen Kernprozessen kommen.
Die Stunde der Anwälte
Nicht selten sind nach einem fehlgeschlagenen IT-Projekt Kunde und Software-Hersteller bzw. der mit der Einführung beauftragte IT-Dienstleister heillos zerstritten. Man trifft sich vor Gericht, es schlägt die Stunde der Anwälte. J.D. Edwards etwa, heute in Oracle aufgegangen, musste im Jahr 2003 an seinen enttäuschten Kunden Evans Industries 1,8 Millionen US-Dollar zahlen, weil eine umfangreiche ERP-Einführung fehlgeschlagen war.
Die Baumarktkette Hornbach wiederum verklagte den deutschen Software-Konzern SAP, weil es bei der Umstellung auf die SAP-Software zu Problemen gekommen sei. Beide Unternehmen einigten sich außergerichtlich. Jüngst brachte der US-Müllentsorger Waste Management den Konzern aus Walldorf vor den Kadi und fordert wegen angeblich unbrauchbarer Software mehr als 100 Millionen Dollar Schadenersatz.
Doch auch SAP-Erzrivale Oracle hat massive Probleme. Eine beim Essener Baukonzern Hochtief unter dem Projektnamen "Aristoteles 2005" gestartete Ablösung der SAP-Applikationen durch Oracles "E-Business-Suite" droht - wenig philosophisch - zu scheitern.
Lernprozesse organisieren
Was also läuft falsch bei IT-Projekten? Die Berater von Infora machen als Hauptursachen veränderte Anforderungen im Projektverlauf, unzureichendes Projekt-Management sowie -Controlling, begrenzte Ressourcen und fachliche Mängel aus.
Meist sind die Ursachen komplex und vielschichtig, wobei sowohl Anbieter als auch Anwender ihre Hausaufgaben nur teilweise erledigen. Besonders groß ist die Gefahr, sich über Ziele und Leistungen nur unzureichend abzustimmen und eine vernachlässigte Kommunikation.
Ein wesentliches Problem sieht Helmut Strohmeier, Leiter der Fachgruppe IT-Projekt-Management bei der Deutschen Gesellschaft für Projekt-Management e.V. auch darin, dass eine Software-Implementierung häufig als reines IT-Projekt und nicht als Organisations-Projekt gesehen wird. Die Einführung einer neuen Geschäfts-Software verändert aber auch Prozesse und damit Organisations-Strukturen, teilweise werden Verantwortlichkeiten neu geordnet.
Auf welche Weise ein Software-Produkt Unternehmensprozesse verändert, steht laut Helmut Strohmeier nicht a priori fest. Deshalb sind die Anforderungen am Beginn auch nicht exakt spezifizierbar. Welche Zielvorstellungen eine Software erfüllen soll, stellt sich oft erst im Projektverlauf heraus.
"Es geht darum, diese Lernprozesse bestmöglich zu organisieren", verdeutlicht Strohmeier. "Das ist auch der Unterschied zu technischen Produkten wie einem Auto oder einer Maschine, die sich gemäß der verfügbaren Varianten genau nach den eigenen Vorstellungen konfigurieren lassen."
Fehler schon bei der Auswahl
Fehler werden häufig auch bei der Software-Auswahl und -beschaffung gemacht. Die Anforderungen, was die neue Software leisten soll, sind unklar oder unstrukturiert formuliert, Expertenwissen wird zu wenig genutzt und Geschäftsentscheider haben Vorbehalte gegenüber bestimmten Software-Produkten, was zu "ideologisch“ verengten und meist emotionalen Diskussionen führt.
Dadurch werden Entscheidungen verschleppt. So kommt es zu ewigen Projekten, die schon gescheitert sind ehe sie richtig begonnen haben. Häufig sind die Gründe für die Software-Auswahl sowie deren Richtigkeit nicht nachvollziehbar und Entscheidungswege nicht ausreichend dokumentiert.
"Business und IT müssen sich bereits im Vorfeld auf ein Auswahlverfahren einigen, das ähnlich wie das eigentliche Einführungsprojekt durchgeführt wird", erklärt Johannes Dorsch von der IT-Beratungsfirma Experton Group. "Zeitrahmen, Aktivitäten sowie die Einbindung der Geschäftsleitung werden vorab definiert und von allen am Auswahlprozess Beteiligten akzeptiert. Zudem ist die aktive Unterstützung durch Geschäftsleitung und Management eine wesentliche Voraussetzung für die erfolgreiche unternehmensweite Implementierung einer Geschäfts-Software."
Strukturiert vorgehen
Ein strukturiertes Vorgehen ist daher unabdingbar, um qualitativ hochwertige und nachvollziehbare Ergebnisse sicher zu stellen - und zwar sowohl bei der Auswahl als auch der späteren Einführung.
Die Auswahl erfolgt in mehreren Schritten. Zunächst werden Aufgabenverteilung und Vorgehen aufeinander abgestimmt, die Anforderungen grob strukturiert, verabschiedet und der Entwurf für ein Pflichtenheft festgelegt. Auf dieser Basis werden dann die Inhalte erarbeitet, die Anforderungsprofile konkretisiert und schließlich das Pflichtenheft verabschiedet.
Dann erfolgt der Bewertungsprozess. Dabei werden die im Pflichtenheft definierten Anforderungen gewichtet, eine Markt-Analyse durchgeführt und mögliche Lösungen nach Wirtschaftlichkeitsprinzipien beurteilt sowie eine Entscheidungsvorlage erstellt.
Transparenz im War Room
Bei laufenden Einführungs-Projekten sind fehlende Transparenz und mangelnde Steuerung einer der häufigsten Fehler. "Enorm wichtig ist daher ein detaillierter Projektplan, der alle Aktivitäten und Meilensteine mit dedizierten Verantwortlichkeiten darstellt", hebt Johannes Dorsch hervor.
Der aktuelle Projektstand muss laufend neu ermittelt werden, um die Fortschritte dokumentieren und beurteilen zu können - je nach Anforderung durch einfache Soll-Ist-Vergleiche, Trend- oder ausgefeilte Earned-Value-Analysen. "Die Dynamik und Komplexität von IT-Projekten erfordern ein regelmäßiges, zeitnahes Erfassen von Projektfortschritten, aber auch von auftretenden Problemen. Die nötigen Projektplananpassungen sowie Gegenmaßnahmen müssen dann rasch initiiert und durchgeführt werden", bestätigt Experton-Berater Dorsch.
Hierfür gibt es bewährte Methoden. Eine Möglichkeit bietet das “Project Management Office” (PMO) oder Projektbüro. Der US-Projekt-Management-Guru Tom DeMarco bezeichnet es als "War Room". Es handelt sich um ein zentrales Organisations-Konzept, das die effektive, sach-, termin- und kostengerechte Projekt-Abwicklung im Unternehmen sicher stellen soll. Es ist vor allem im angelsächsischen Raum verbreitet.
Zu den Kernaufgaben gehören unter anderem die Erfassung von Projektstammdaten und Terminrückmeldedaten und die Bereitstellung projektrelevanter Informationen.
Mitarbeiter des Projektbüros generieren Projektdaten-Auswertungen, erstellen, drucken und verteilen Projektpläne und Projektberichte. Sie bauen eine Projekt- und Erfahrungsdatenbank auf und aktualisieren diese laufend. Auf Grundlage eines einheitlichen Berichtswesens bereiten sie überdies Entscheidungsunterlagen für die Projektleitung vor.
Den höheren Reifegrad erreichen
Eine weitere Option liegt im Einsatz des Project Management Maturity Model (PMMM) bzw. des Organizational PMMM, das vom Software Engineering Institute der Carnegie Mellon Universität 1993 aus dem Capability Maturity Model der Software-Entwicklung entwickelt wurde. Das PMMM beschreibt fünf Stufen des Reifegrads von Projektorganisationen.
Die erste Stufe ist das undokumentierte, nicht reproduzierbare Herangehen an Projekte, quasi „aus dem Bauch heraus“. Die fünfte Stufe besteht in einem vollständig implementierten, unternehmensweiten Standard für Projekte, der beständig überprüft und optimiert wird.
Je höher der Reifegrad, den eine Organisation erreicht, umso schneller und besser lassen sich auftretende Probleme erkennen und beheben. Ziel ist - analog zum Qualitäts-Management - die Implementierung eines kontinuierlichen Verbesserungsprozesses für das Projekt-Management.
Gute Verträge schaffen Sicherheit
Ein fehlerfreies Projekt gibt es grundsätzlich nicht. Deshalb gilt: Aufgaben, Leistungen und Ziele müssen vertraglich klar, verbindlich und eindeutig geregelt sein, denn die Anschaffung und Einführung einer neuen Geschäfts-Software ist eine strategische Investition. Diese soll im Ernstfall nicht durch schlampig ausgearbeitete Verträge zum juristischen Rohrkrepierer werden.
Für Kauf und Einführung von Software schreibt der Gesetzgeber - zumindest in Deutschland - keine bestimmte Vertragsart vor. In den meisten Fällen wird diese jedoch vom Software-Anbieter vorgegeben, etwa durch Lizenz- und Nutzungsvereinbarungen. Von entscheidender Bedeutung für den Kunden ist, dass im Vertrag eine förmliche Abnahme des eingeführten Software-Produktes oder -Systems vereinbart wird.
Gibt es diese nicht, wird der Vertrag als normaler Kaufvertrag behandelt und der vereinbarte Preis ist sofort zahlbar. Arbeitet die Software fehlerhaft, ist der Kunde in der Beweispflicht. Mit einem Werkvertrag lassen sich diese Klippen umschiffen.
In der öffentlichen Verwaltung regeln die ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen (EVB-IT) die Rechtsgeschäfte im IT-Bereich. Die EVB-IT bestehen aus bestimmten Vertragstypen, etwa für Kauf, Dienstleistungen sowie Instandhaltung.
Service Level vereinbaren
Am Anfang eines Vertrages steht die Leistungsbeschreibung des Herstellers. Diese sollte sich der Kunde genau anschauen. Will er später Anpassungen, die vom Standard abweichen, wird es meist empfindlich teuer.
Der Kunde sollte auch vom Auftragnehmer, also dem Hersteller bzw. IT-Dienstleister, verlangen, den Leistungsumfang in einem Lasten- und Pflichtenheft festzuhalten. Zum Beispiel kann dies die Software-Lieferung inklusive Wartung, Installation, Anpassung, Schulungen, Datenmigration und Inbetriebnahme umfassen.
Vereinbarungen über zu erbringende Dienstleistungen, etwa im Rahmen von Hosting- oder Outsourcing-Projekten, müssen durch ein Service-Level-Agreement, etwa zu Verfügbarkeit und Ausfallzeiten, abgesichert sein. Ein weiterer wichtiger Punkt sind Haftungsklauseln. Vorsicht ist geboten, wenn der Auftragnehmer diese individuell verhandeln will.
Doch nicht alles lässt sich vertraglich absichern. "Verträge in der heutigen Form, wie etwa die Werksverträge, werden nicht auf den späteren Projekterfolg hin gestaltet", verdeutlicht Helmut Strohmeier. Es gehe hauptsächlich darum, den möglichen Misserfolg abzusichern und dafür einen Schuldigen zu bestimmen.
Sein Fazit: "Bei IT-Projekten mit hohem Organisationsanteil müssen wir weg von den Werksverträgen. Wenn überhaupt sollten diese nur für kleine Teilprojekte wie die Implementierung eines bestimmten Prozesses abgeschlossen werden." Dagegen sollten sich Auftraggeber und Auftragnehmer stärker darauf konzentrieren, die gegenseitige Zusammenarbeit laufend zu verbessern - und dazu bedarf es in erster Linie gegenseitiges Vertrauen und anders gestaltete Verträge.