IT-Projekte Das A und O der Softwareeinführung

Wenn die Einführung einer neuen Geschäftssoftware scheitert, muss ein Schuldiger her. Das ist die Stunde der Anwälte. Sie fordern dann, wie jüngst im Fall von SAP, Schadensersatz in Millionenhöhe. Dabei lassen sich Fehlschläge und teure Gerichtsverfahren leicht vermeiden. Ein Leitfaden für erfolgreiches IT-Projektmanagement.
Von Andreas Schaffry

München - Kein Zweifel. Bei der Einführung einer neuen Geschäftssoftware kann viel schief gehen. Nach einer europaweiten Studie des Wirtschaftsforschungsinstituts Economist Intelligence Unit (EIU) im Auftrag des BTO-Anbieters Mercury liefern nur 49 Prozent aller Technologieprojekte einen messbaren geschäftlichen Erfolg.

Meist werden zudem die Projektrisiken unterschätzt. Werden Zeitpläne und Fristen überschritten, führt dies häufig zu betriebswirtschaftlich negativen Folgen. Einerseits dreht sich dadurch die Kostenspirale unaufhaltsam nach oben, andererseits kann es zu erheblichen Beeinträchtigungen bei betrieblichen Kernprozessen kommen.

Nicht selten sind nach einem fehlgeschlagenen IT-Projekt Kunde und Softwarehersteller beziehungsweise 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 (Enterprise Resource Planning) fehlgeschlagen war.

Die Baumarktkette Hornbach  wiederum verklagte den deutschen Softwarekonzern SAP , weil es bei der Umstellung auf die SAP-Software zu Problemen gekommen war. 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.

Was also läuft falsch bei IT-Projekten? Die Berater von Infora machen als Hauptursachen veränderte Anforderungen im Projektverlauf, unzureichendes Projektmanagement sowie -controlling, begrenzte Ressourcen und fachliche Mängel aus.

Nicht nur ein reines IT-Projekt

Nicht nur ein reines IT-Projekt

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 die Kommunikation zu vernachlässigen.

Ein wesentliches Problem sieht Helmut Strohmeier, Leiter der Fachgruppe IT-Projektmanagement bei der Deutschen Gesellschaft für Projektmanagement e.V. auch darin, dass eine Softwareimplementierung häufig als reines IT-Projekt und nicht als Organisationsprojekt gesehen wird. Die Einführung einer neuen Geschäftssoftware verändert aber auch Prozesse und damit Organisationsstrukturen, teilweise werden Verantwortlichkeiten neu geordnet.

Auf welche Weise ein Softwareprodukt Unternehmensprozesse verändert, steht laut Strohmeier nicht a priori fest. Deshalb sind die Anforderungen zu 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 der Experte. "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 werden häufig auch bei der Softwareauswahl 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 Softwareprodukten, 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 Softwareauswahl 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äftssoftware."

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.

Was bei der Auswahl zu beachten ist

Was bei der Auswahl zu beachten ist

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 Marktanalyse durchgeführt und mögliche Lösungen nach Wirtschaftlichkeitsprinzipien beurteilt sowie eine Entscheidungsvorlage erstellt.

Bei laufenden Einführungsprojekten 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", erklärt IT-Berater Dorsch.

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", meint Dorsch.

Hierfür gibt es bewährte Methoden. Eine Möglichkeit bietet das Project Management Office (PMO) oder Projektbüro. Der US-Projektmanagement-Guru Tom DeMarco bezeichnet es als War Room. Es handelt sich um ein zentrales Organisationskonzept, das die effektive, sach-, termin- und kostengerechte Projektabwicklung im Unternehmen sicherstellen 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.

Eine weitere Option liegt im Einsatz des Project Management Maturity Model (PMMM) beziehungsweise des Organizational PMMM, das vom Software Engineering Institute der Carnegie Mellon Universität 1993 aus dem Capability Maturity Model der Softwareentwicklung 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ätsmanagement - die Implementierung eines kontinuierlichen Verbesserungsprozesses für das Projektmanagement.

Förmliche Abnahme vereinbaren

Förmliche Abnahme vereinbaren

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äftssoftware 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 Softwareanbieter vorgegeben, etwa durch Lizenz- und Nutzungsvereinbarungen. Von entscheidender Bedeutung für den Kunden ist, dass im Vertrag eine förmliche Abnahme des eingeführten Softwareproduktes 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.

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 beziehungsweise IT-Dienstleister, verlangen, den Leistungsumfang in einem Lasten- und Pflichtenheft festzuhalten. Zum Beispiel kann dies die Softwarelieferung inklusive Wartung, Installation, Anpassung, Schulungen, Datenmigration und Inbetriebnahme umfassen.

Vereinbarungen über zu erbringende Dienstleistungen, etwa im Rahmen von Hosting- oder Outsourcingprojekten, 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 Experte 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.

Verwandte Artikel
Die Wiedergabe wurde unterbrochen.