Betriebliche Informationssysteme unterstützen heute 60 bis 90 Prozent der Geschäftsprozesse. Trotz ihrer enormen wirtschaftlichen Bedeutung werden sie in vielen Unternehmen nicht erfolgreich entwickelt und gewartet, unter anderem weil die Firmen kritische Erfolgsfaktoren sträflich vernachlässigen. Nicht weniger als 46 Prozent aller Softwareprojekte leiden an Termin- und Kostenüber-schreitungen sowie reduzierter Funktionalität des Endprodukts, 28 Prozent werden schon vor der Fertigstellung abgebrochen. Lediglich etwa 26 Prozent aller Softwareprojekte enden termin-, kosten- und funktionsgerecht.
Gelingt es einem Unternehmen, Software erfolgreich einzuführen - die Chancen liegen immerhin bei etwa 72 Prozent -, so steht es vor der nächsten Herausforderung: Zwischen 60 und 80 Prozent der Gesamtkosten eines Softwaresystems fallen über 15 Jahre gerechnet für die Wartung an. Schlecht implementierte Lösungen sorgen daher auf Jahre hinaus für erhebliche Folgekosten.
Erfolgsfaktoren der Softwareentwicklung
Ein Team aus Wissenschaftlern der Technischen Universität München und praxiserprobten Managern hat eine Reihe kritischer Er-folgsfaktoren zusammengestellt und daraus das allgemeine Vorgehensmodell "Erfolgsorientiertes Vorgehen in der Softwareentwicklung und Wartung" (Evise) entwickelt. Es liefert eine pragmatische Anleitung für erfolgreiches Management betrieblicher Informations-systeme und beschreibt die Entwicklung von Best-Practice-Modellen, die den gesamten Lifecycle von Software einschließlich der wesentlichen organisatorischen, technischen und personellen Aspekte abdeckt (siehe Kasten "Das Vorgehen").
Zehn Erfolgsfaktoren - jeweils mit Negativbeispiel ("So nicht") - dienten für die Entwicklung von Evise als Richtschnur :
1. Unterstützung durch die Geschäftsführung
Alle Mitglieder der Geschäftsführung müssen hinter den Entwicklungszielen und der Einführungsstrategie des betrieblichen Informationssystems stehen. Entscheidend ist darüber hinaus, dass sie den Projektleiter durch schnelle und konsequente Entscheidungen bei Ressourcenzuteilung, Priorisierungen sowie bei der Lösung von Konflikten unterstützen.
So nicht: Der Vorstand eines Finanzdienstleisters hatte beschlossen, das seit 25 Jahren eingesetzte Informationssystem zur Unterstützung von Vertrieb und Produktverwaltung von Grund auf neu zu entwickeln. Der Chief Financial Officer und Chief Information Officer bildeten den Projektlenkungsausschuss. Vorstandssprecher und Vertriebsvorstand waren nicht direkt in das Projekt eingebunden. Ihre Mitarbeiter lieferten allerdings viele Anforderungen an das zu entwickelnde System.
Eine einheitliche Unterstützung des Projekts durch die Geschäftsführung war damit nicht gegeben. Von ihr gemeinsam akzeptierte und mitgeteilte Projektziele existierten nicht. Jedes Mitglied der Geschäftsführung versuchte über seine Mitarbeiter Einfluss auf das Projekt zu nehmen. Dadurch veränderten sich die Projektziele permanent. Das Projekt wurde nach Überziehung des Gesamtbudgets um 600 Prozent abgebrochen.
2: Einbeziehung der Nutzer
Die künftigen Nutzer eines Systems sind verantwortlich an Spezifikation, Abnahme und Benutzerorganisation zu beteiligen. Sind wesentliche Anforderungen der Nutzer nicht erfüllt, muss ein Projekt auch bei termin- und kostengerechter Abwicklung als Fehlinvestition angesehen werden.
So nicht: In einem zweistelligen Millionen-Euro-Projekt galt es, die Funktionalität einer neuen fachlichen Komponente zu spezifizieren. Das Team überzeugte die Projektleitung, Workshops mit den Anwendern des Systems zu veranstalten. Dort wurde versucht, die Funktionen und die Oberfläche der neuen Komponente zu erarbeiten. Schnell stellte sich im Workshop die Frage, welche Produkte dem internen Kunden über das System angeboten werden sollten. Die Antwort des "Anwenders": "Das kann ich Ihnen aus dem Stegreif nicht sagen, aber vor einigen Monaten habe ich das bereits einem Programmierer im zweiten Stock erzählt. Der müsste es wissen."
Nach einigem Hin und Her stellte sich heraus, dass die vermeintlichen Anwender nicht wirklich die Nutzer des Systems waren, sondern im Unternehmen nur die Schnittstelle zu den tatsächlichen Anwendern bildeten. Neben ihren eigentlichen Aufgaben hatte man ihnen zusätzlich die Spezifikation der Softwareanforderungen übertragen. Da sie nur ein Puffer zwischen den Nutzern und dem Entwicklerteam waren, gingen viele Anforderungen verloren, wurden verfälscht oder neu erfunden.
Nach Einführung des Gesamtsystems mussten über die Hälfte der Masken nochmals angepasst werden. Dies führte zu über fünf Millionen Euro zusätzlichen Entwicklungskosten.
3: Erfahrene Projektleiter
Mit dem Projektleiter steht oder fällt ein Softwareprojekt. Er bildet die Schnittstelle zwischen Auftraggeber und Entwicklern und ist für den reibungslosen Ablauf des gesamten Vorhabens verantwortlich. Ein erfolgreicher Projektleiter benötigt deshalb neben der durchgängigen Verantwortlichkeit über alle Phasen des Projekts hinweg ein grundsätzliches Verständnis für die Anforderungen der Fachabteilungen, der Softwaretechnik sowie Erfahrung in Organisation und Menschenführung.
So nicht: In einem Softwareprojekt mit einem Volumen von mehreren Millionen Euro wurde an Fachkonzept und Architekturentwurf gearbeitet. Die Voraussetzungen waren günstig: Ein gutes Pflichtenheft lag bereits vor, erste Pläne und Teilergebnisse wurden schnell und in hoher Qualität erarbeitet, die Kommunikation mit dem Kunden gestaltete sich angenehm und kooperativ. In dieser viel versprechenden Situation schaffte es der unerfahrene Projektleiter quasi im Alleingang, das Projekt zum Scheitern zu bringen. Durch das Zurückhalten von Informationen zwischen Geschäftsleitung, Anwendern und Entwicklern brachte er zunächst die Kommunikation im Projekt zum Erlahmen. Als sich dadurch erste Komplikationen ergaben, schlug er sich auf die Seite des Auftraggebers und übertrug die unvertrauten und lästigen Aufgaben bei Planung und Controlling sowie die Leitung der Entwicklung vollständig an einen externen Mitarbeiter, den er vor Geschäftsleitung, Auftraggebern und Anwendern abschottete.
Der Auftraggeber entzog dem Auftragnehmer schließlich auf Grund mangelnden Vertrauens das Projekt und übertrug es einem anderen Unternehmen. Insgesamt ergab sich eine Verzögerung von etwa einem Jahr und ein zusätzlicher Aufwand von etwa drei Millionen Euro.
4: Eindeutige Geschäftsziele
Die Geschäftsziele eines Softwareprojekts müssen präzise festgelegt, kommuniziert und überprüft werden. In der Geschäftsführung ist eine klare Verantwortlichkeit für die Projektkosten sowie die Formulierung, Abstimmung und Umsetzung der Geschäftsziele inklusive des konkreten Nutzens festzulegen.
So nicht: Die Entwicklungs- und Betriebskosten des neuen Gepäckabwicklungssystems eines internationalen Flughafens waren so hoch, dass sich die Investition erst nach 1000 Jahren amortisiert hätte. Das primäre Geschäftsziel des Projekts lautete aber Kostenersparnis durch Rationalisierung. Das Projekt wäre in dieser Art nie gestartet oder zumindest frühzeitig gestoppt worden, wenn dieses Geschäftsziel von den Verantwortlichen mitgeteilt und überprüft worden wäre.
5: Überschaubarkeit
Die Größe eines Softwareprojekts beeinflusst dessen Erfolg - je größer und komplexer, desto schwerer ist es zu beherrschen und desto wahrscheinlicher ist sein Scheitern.
So nicht: Eine Kooperation von drei Finanzdienstleistern schrieb ein Festpreisprojekt zur Neuentwicklung eines umfangreichen Abwicklungssystems aus. Die Ausgangsbasis war ein erster Anforderungskatalog von etwa 25 Seiten. Der Auftrag wurde an den billigsten Anbieter, ein weltweit agierendes Softwarehaus, vergeben. Unter der Regie des Auftragnehmers wurde daraufhin ein umfassendes und extrem komplexes Fachkonzept entwickelt, das die Wünsche aller drei Auftraggeber repräsentierte. Erst nach etwa drei Jahren Laufzeit mit einem großen Entwicklungsteam konnte der erste Implementierungsmeilenstein getestet werden. Die Ergebnisse waren bezüglich Funktionalität und Performance inakzeptabel. Das Projekt wurde abgebrochen, da eine Hochrechnung ergab, dass die ursprünglichen Projektkostenschätzungen um den Faktor vier übertroffen werden. Der gesamte Schaden betrug mehr als 50 Millionen Euro.
6: Standardisierte Softwareinfrastruktur
Da sich die funktionellen Anforderungen an ein Softwaresystem häufig und schnell än-dern, muss zumindest die Softwareinfrastruktur und -architektur stabil sein. Nur so können sich die Entwickler auf ihre eigentliche Aufgabe konzentrieren.
So nicht: Bei einem Dienstleistungsunternehmen mit großem Filialnetz wurden die unterschiedlichen Anwendungssysteme zur Sachbearbeitung für verschiedene Fachgebiete ohne eine standardisierte Softwareinfrastruktur entwickelt. Nach etwa sechs Jahren stand eine Reihe von Anwendungen zur Verfügung. Es existierte jedoch kein einheitlicher Styleguide für Benutzeroberflächen einschließlich Help-Funktion, es gab kein einheitliches Rechtekonzept mit Single-Logon, und die zentralen Steuerungsdaten waren redundant auf 54 unabhängige Tabellen verteilt. Die Anwendungssysteme waren folglich umständlich zu bedienen, schwer zu warten und schlecht erweiterbar.
Die Vereinheitlichung der Benutzeroberflächen einschließlich Single-Logon-Verfahren kostete etwa 30 Personenjahre. Die Konsolidierung der Steuerungsdaten brauchte rund fünf Personenjahre, und die Entwicklung einer einheitlichen Hilfefunktion verschlang nochmals fünf Personenjahre.
7: Stabilität der grundlegenden Anforderungen
Als erste Projektstufe wird ein minimaler Satz von grundlegenden Anforderungen festgelegt, der zentrale Funktionen für das Unternehmen abdeckt und als Basis für weitere Entwicklungsstufen dienen kann.
So nicht: In dem unter Regel 1 beschriebenen Projekt wurde entschieden, die gewünschte Funktionalität parallel für alle Produkte zu entwickeln. Dies führte dazu, dass bis zum ersten Test des Softwaresystems drei Jahre vergingen, in denen die Beteiligten gegen eine sich ständig ändernde Systemarchitektur entwickeln mussten. Außerdem wurde gegen das Prinzip der sequentiellen Abwicklung von einzelnen Projektphasen verstoßen und das Objektmodell während der Programmierung ständig geändert.
Besser wäre es gewesen, zunächst das Objektmodell an Hand eines Produkts stabil zu entwickeln und zu testen, um dann in weiteren Teilprojekten die restlichen Produkte zu ergänzen. Zusätzlich hätten so erste Ergebnisse früher genutzt werden können.
8: Angemessenes Vorgehensmodell für den gesamten Software-Lebenszyklus
Es sollte ein an die spezifischen Unternehmensbedürfnisse angepasstes Vorgehensmodell für standardisierte Entwicklungs- und Wartungsprozesse zur Unterstützung der Entwickler etabliert sein. Dabei darf eine effektive Qualitätssicherung nicht fehlen.
So nicht: In einem großen Entwicklungsprojekt war das anfänglich kleine Team von weniger als fünf Personen auf mehr als 50 Entwickler angewachsen, weil umfangreiche neue Funktionen stets möglichst schnell entwickelt werden sollten. Für die Bereitstellung einer angemessenen Verfahrenstechnik standen dagegen nur marginale Mittel und Ressourcen zur Verfügung. Nach insgesamt fünf Jahren Arbeit ohne dokumentiertes Vorgehensmodell mit entsprechenden Standards und Qualitätskontrollen sowie ungenügend integrierten Werkzeugen war neben dem Quellcode eine unüberschaubare Vielzahl an uneinheitlich strukturierten Modellen und Dokumenten entstanden. Dies führte zu untragbaren Kosten für Weiterentwicklung und Wartung. Entwickler konnten erforderliche Informationen nicht oder nur nach stundenlangem Suchen finden und weigerten sich, bestehenden Code zu ändern oder anzupassen, da sich bei jeder Änderung unvorhergesehene Effekte ergeben konnten.
Die Projektleitung entschloss sich, ein ange-messenes Vorgehensmodell zu definieren und in diesem Rahmen auch die Dokumentation neu zu strukturieren. Alleine die Sammlung, Kategorisierung und Neuablage der relevanten Dateien und Dokumente (insgesamt über 20000, bei einer anfänglichen Schätzung von 1500) kostete mehr als drei Personenjahre. Die zusätzlich erforderliche Zeit für die inhaltliche Aufarbeitung und Konsolidierung wurde von den Bearbeitern auf 30 bis 100 Personenjahre geschätzt, ebenso der bereits während der Entwicklung aufgelaufene Produktivitätsverlust.
9: Verlässliche Berechnungen
Verlässliche Berechnungen von Aufwand und Nutzen eines Softwareprojekts sind wesentliche Grundlage für die Entscheidung des Managements über ein Projekt und zudem unabdingbare Voraussetzung für eine realistische Planung.
So nicht: In dem unter Regel 1 beschriebenen Projekt wurde statt einer Wirtschaftlichkeitsberechnung, in die die erwarteten Kosten und der zu erzielende Nutzen des Projektes einfließen, eine nur grobe Schätzung der Entwicklungskosten durch den CIO als Basis für den Start des Projektes akzeptiert.
Im Verlauf des Projekts stiegen die Kosten von geschätzten 7,5 Millionen auf 40 Millionen Euro, wobei nur 80 Prozent der geplanten Funktionen bereit standen. Das Projekt wurde eingestellt, weil allein die Betriebskosten der neuen Anwendung höher veranschlagt wurden, als der Nutzen.
10: Motiviertes und kompetentes Team
Motivation, verbunden mit Kompetenz, zählt zu den wichtigsten Produktivitätsmotoren. Daher ist es eine zentrale Aufgabe des Managements, diese Faktoren mit Hilfe einer produktivitätsfördernden Arbeitsumgebung und angemessener Führung sicher zu stellen.
So nicht: Ein Finanzdienstleister beschloss, ein Internet-basierendes System zu entwickeln. Er beauftragte damit einen international tätigen Softwaredienstleister. Der Auftragnehmer startete mit einem kleinen Team von Experten, vergrößerte es jedoch rasch und zog für die Implementierung überwiegend neu eingestellte Anfänger heran. Der Auftraggeber stellte die Arbeitsumgebung bereit. Aufgrund der Raumknappheit saßen bald über 40 Entwickler über Monate hinweg in zwei mittelgroßen Räumen - die meisten mussten sich dabei einen Schreibtisch mit einem oder sogar zwei weiteren Entwicklern teilen. Die Qualität des dabei entstandenen Systems war insgesamt schlecht; viele Implementierungsfehler führten dazu, dass die Kernfunktionen erst drei bis sechs Monate nach den geplanten Meilensteinen ausgeliefert werden konnten.
Evise schafft Abhilfe
Mit einer konsequenten, schrittweisen Umsetzung des auf den geschilderten Erfolgsfaktoren aufbauenden Evise-Ansatzes können wesentliche Risiken in Projekten schnell verhindert werden. Außerdem lassen sich mittelfristig signifikante Verbesserungen von Qualität und Produktivität der Entwicklungs- und Wartungsprozesse erzielen. (rg)
* Karl-Rudolf Moll ist Berater für Informatik-Management und Honorarprofessor (http://wwwbroy.in.tum.de/~moll/de/index.html), Prof. Manfred Broy ist Leiter des Instituts für Informatik an derTechnischen Universität München, in Garching. Markus Pizka und Tilman Seifert sind dort wissenschaftliche Mitarbeiter. Klaus Bergner und Andreas Rausch sind Geschäftsführer der 4Soft GmbH in München.
Das Vorgehen
Das allgemeine Vorgehensmodell "Erfolgsorientiertes Vorgehen in der Softwareentwicklung und Wartung" (Evise) hilft Unternehmen mit überschaubarem Aufwand, Software erfolgreicher und billiger zu entwickeln. Folgende Stufen sollten durchlaufen werden:
Schritt 1: Entwicklung eines unternehmensspezifischen Vorgehensmodells, das auf dem allgemeinen Vorgehensmodell Evise basiert. Auf Grundlage der bereits im Unternehmen eingesetzten Basistechnologien für Softwareentwicklung werden die unterstützenden Methoden, Prozesse und Werkzeuge nach folgenden Auswahlkriterien festgelegt: Entsprechen sie Best-Practice-Methoden, oder haben sie sich zumindest am Markt bewährt? Sind die entsprechenden Hersteller hinreichend zukunftssicher?
Außerdem müssen die unternehmensspezifischen Standards festgelegt werden. Generell sollte der Anteil von Eigenentwicklung an Methoden, Prozessen, Werkzeugen und Standards so gering wie möglich gehalten werden.
Schritt 2: Vergleich der betrieblichen Praxis mit dem Best-Practice-Vorgehensmodell. Dabei lassen sich Möglichkeiten zu Verbesserungen identifizieren und in drei Gruppen gliedern: Quick-Wins sowie mittel- und langfristige Verbesserungen. Erstere sind meist sehr effektiv und können sofort, spätestens jedoch in drei Monaten, umgesetzt werden. Dazu zählen:
- Installation eines Projektlenkungsausschusses.
- Überprüfung wichtiger laufender Projekte in Hinblick auf Ziele, Wirtschaftlichkeit, Einbindung der Nutzer und Qualifikation des Projektleiters.
- Werkzeuge für Basisaufgaben wie Versionsverwaltung, Debugger oder Tools zur Testautomatisierung.
Mittelfristige Verbesserungen lassen sich in vier bis zwölf Monaten realisieren. Sie stellen grundsätzliche Veränderungen der Softwaretechnik dar und sollten deshalb in Form eines Pilotprojekts abgewickelt werden. Dies fördert sowohl die Praxistauglichkeit als auch die Akzeptanz der Veränderungen.
Die langfristigen Verbesserungen nehmen mehr als ein Jahr in Anspruch und umfassen folgende Punkte:
- Einführung eines Architektur-Managements.
- Verbesserung der Qualifikation der Entwickler.
- Optimierung der Führungssituation.
- Aufbau einer Datenbasis für Projektkenndaten.
Weitere Informationen unter http://www.4soft.de/EViSE