Geschäftsprozesse optimieren/Softwareentwicklung und Gestaltung von Geschäftsprozessen

Entwickler und Kunde - zwei Welten

16.08.2002
Software ist heute das wichtigste Instrument zur Verbesserung und Automatisierung von Geschäftsprozessen. Tatsache ist aber auch, dass Softwareprojekte regelmäßig scheitern oder zumindest nicht zur Zufriedenheit der Kunden abgeschlossen werden. Der folgende Beitrag zeigt die Besonderheiten von Software und Softwareentwicklung und schildert, warum die Kommunikation zwischen Auftraggebern und Entwicklern oft misslingt. Von Volker Kopetzky und Uwe Valentini*

Wer nach den Gründen für das häufige Nichtgelingen von Softwareprojekten fragt, wird unterschiedliche Antworten erhalten: Die Auftraggeber klagen darüber, dass die Software nicht das leistet, was sie zur Unterstützung ihrer Geschäftsprozesse erwartet haben, oder dass Softwareprojekte nicht professionell genug gesteuert werden. Die Softwareentwickler führen dagegen ins Feld, dass die Anforderungen des Kunden an seine Prozesse nicht klar formuliert oder zu oft modifiziert worden sind. Die Beschuldigungen auf beiden Seiten machen die Ursache für den Misserfolg deutlich: Auftraggeber und Entwickler sprechen offenbar unterschiedliche Sprachen.

Die Klagen über die schlechte Planbarkeit der Ergebnisse und die Kosten von Softwareprojekten sind so alt wie die Software selbst. Einer der Gründe dafür ist, dass Software nach wie vor falsch beurteilt wird: Während ein Marketing-Manager oder Art Director Ergebnisse "produziert", beispielsweise ein Marketing-Konzept oder eine Werbekampagne, liefert der Softwareentwickler künftige Geschäftsprozesse. So ist Software sozusagen das "eingefrorene Denken" des Entwicklers darüber, wie Prozesse in Zukunft ablaufen werden. Um dieses Problem zu lösen, benötigt er engsten Kontakt mit seinem Auftraggeber.

Technische und soziale Prozesse

Softwareentwicklung ist nicht nur - wie gemeinhin angenommen - etwas Technisches, sondern basiert auf sozialen Prozessen. Ein Entwicklungsteam arbeitet nicht nur zusammen, es denkt zusammen. Ein Beispiel: Ein Team von fünfzig "Romanentwicklern" möchte ein Konkurrenzprodukt zu Tolstois "Krieg und Frieden" schreiben. In der Welt der Softwareentwicklung würde dies heißen: Ein Team kümmert sich um die Verwendung des Wortes "Krieg", ein anderes um das Wort "Frieden". Ein weiteres Team garantiert die Spannungskurve, und ein Grammatikteam schließlich befasst sich mit den generellen sprachlichen Anforderungen.

Teams auf der Spielwiese

Bereits zu Projektbeginn ist es Aufgabe eines Architekturteams, die allgemeinen Anforderungen an das Produkt in einer einfachen und stabilen Architektur zu definieren, um den Verlauf des Projektes unter Beachtung des Budgets festzulegen. Um den Zeitrahmen einzuhalten, müssen die Kapitel parallel geschrieben werden. Das Ergebnis jedes Teams sind Worte oder, besser, "zu Papier gebrachte Gedanken".

Die Softwareentwicklung offenbart allen Beteiligten eine unendlich weite und sich ständig verändernde "technische Spielwiese" mit immer neuen Möglichkeiten. Gleichzeitig steigt die Komplexität des Softwareentwicklungssystems bei großen Projekten exponentiell an, so dass diese kein Einzelner mehr vollständig begreifen kann. Deshalb ist es einem Mitarbeiter kaum möglich, die Auswirkungen seiner Veränderungen am Produkt während der Entwicklung abzuschätzen. Jede Änderung bedeutet so eine Risikoerhöhung für den Projekterfolg.

Was Software ist, wie sie entsteht und wie sie arbeitet - das alles interessiert den Auftraggeber nicht. Er erwartet in einem bestimmten Zeitrahmen und zu einem bestimmten Preis ein fertiges Softwaresystem, das die gewünschten Prozesse automatisiert und deren Qualität garantiert. Sein Ziel ist es, mit Hilfe des IT-Systems neue Produkte und/oder Dienstleistungen anzubieten oder bestehende Angebote zu verbilligen. Um diese Investition planen zu können, benötigt er eine verlässliche Aussage über die Kosten der Softwarelösung und den geschäftlichen Nutzen. Der Auftraggeber sucht immer Sicherheit in der Planung seiner Investition. Seine Wünsche und Erwartungen formuliert er in "Anforderungen".

Veränderungen der Geschäftsprozesse leiten sich aus strategischen und langfristigen Entscheidungen ab. Auch wenn dies seit einigen Jahren in immer schnelleren Zyklen und mit größerer Flexibilität geschieht, ist es Ziel eines jeden Unternehmens, die Planung vor der Investition in ein Projekt abgeschlossen zu haben.

Genau das ist ein Problem bei Softwareprojekten: Es lässt sich zwar festlegen, ab wann genau geplant werden kann - doch von Beginn an sind die Projekte nicht exakt planbar. Diese Vorphase ist selten in der Planung eines geschäftlichen Projektes vorgesehen, geschweige denn im Rahmen der Vertragsverhandlungen zugelassen. Weil aber das Projekt von A bis Z durchgeplant sein soll, legt man bei der "Kollision" von langfristiger Strategieplanung und unplanbarer erster Phase der Softwareentwicklung meistens "blind" irgendwelche Meilensteine fest. So werden bewusst falsche Zwischenergebnisse geliefert, um die Forderungen des Unternehmens nach Planbarkeit zu befriedigen. Vor diesem Hintergrund wird klar, dass Projekte mit Fixpreisangeboten von vornherein zum Scheitern verurteilt sind. Denn im Fixpreis findet die in jedem Softwareprojekt enthaltene Unplanbarkeit von Software keine Berücksichtigung.

Einem Menschen kann man ungenaue Aufträge geben. So ist beispielsweise im modernen Management das Führen nach Zielvorgaben weit verbreitet. Solche Vorgaben sind selten exakt oder eindeutig messbar: Eine Zielvorgabe wie "mehr Kundenorientierung" lässt reichlich Interpretationsspielraum für die Ausgestaltung der Geschäftsprozesse. Diese Management-Methode hat sich etabliert, denn ein Mensch ist kreativ und flexibel, und ein Team von Menschen ist durchaus in der Lage, nach einer ungenauen Anweisung wie "Baut ein umweltfreundliches Fortbewegungsmittel" verschiedenste Lösungen zu erfinden - angefangen vom Kickboard bis hin zum Fahrrad mit 27 Gängen. Im Gegensatz dazu kann ein Computer oder ein System von Computern mit einer solchen Vorgabe nichts anfangen. Damit ein sinnvolles Ergebnis zustande kommt, wird immer eine bis ins letzte Bit detaillierte Beschreibung benötigt.

Die Softwarebranche war schon immer technologieverliebt. Nichts ist dem Entwickler lieber, als neue Werkzeuge, Sprachen, Oberflächen und Kniffe zu lernen. Diese Freude am Lernen und Ausprobieren von Neuem ist ein Charakteristikum der Softwarebranche. Einerseits ist dieser "Spieltrieb" der Motor für Innovation und Fortschritt, andererseits birgt er aber auch ein großes Risiko: Denn es wird oft lieber am schwierigsten Feature herumgetüftelt, als dass die wichtigste Funktion entwickelt wird - zumal eben oft nicht klar vom Auftraggeber definiert wurde, welche Anforderungen oberste Priorität haben.

So scheitern IT-Projekte häufig nicht zuletzt deshalb, weil unnötigerweise zu viele technische Spielereien zum Einsatz kommen. Das "Lost in the Technology Jungle" führt sozusagen zu einem Autismus der Entwickler: Sie kreisen nur noch um ihre eigenen Probleme und verlieren den Blick auf die Anforderungen des Auftraggebers. Dabei ist es den Entwicklern zugute zu halten, dass sie nur "gute" Software liefern wollen. Doch dabei wird von ihnen "gut" mit "technologisch 1a" gleichgesetzt, was noch lange nicht der Qualitätsdefinition des Auftraggebers entsprechen muss. Denn was nützt dem Kunden ein kleiner, in jede Parklücke passender Smart, wenn er für seine Belange einen Land Rover braucht.

Eine fundierte Architektur

Das wirksamste Mittel gegen die Technologieverliebtheit der Entwickler sowie gegen die oft nur vage formulierten Anforderungen der Kunden ist die Architektur eines Softwaresystems. Sie beschreibt die wichtigsten Teile eines geplanten IT-Systems und ist damit das Gerüst des Projekts. Da jedoch die Architektur auf den ersten Blick primär dem Entwicklungsteam und nicht dem Auftraggeber nützt, ist es für die Entwicklungsseite oft schwierig, dafür Gelder bewilligt zu bekommen - eine Milchmädchenrechnung, denn: Viele "Schnell-und-billig"-Lösungen sind unterm Strich teurer als ein Softwaresystem auf einer fundierten Architektur.

Damit eine sinnvolle Architektur zustande kommt, müssen Entwickler und Auftraggeber gemeinsam die wichtigsten Anforderungen und Vorgehensweisen definieren. Die darauf aufsetzende Architektur ist dann das Herzstück des Projekts; sie bildet die "Schnittmenge" aus den Prioritäten der Entwickler und denen der Auftraggeber.

Es empfiehlt sich, über "Use Cases" miteinander zu kommunizieren. Sie gehören zur Unified Modeling Language (UML), der allgemein verständlichen Sprache in der Softwarebranche. Softwareprojekte gelingen nur dann, wenn beide Parteien sich über die Anforderungen, Risiken und Ziele eines Projekts verständigen und dies in einer Architektur festlegen.

*Volker Kopetzky ist Senior Representative und Uwe Valentini Senior Technical Representative bei Rational Software GmbH in München.

Angeklickt

- Der Softwareentwickler liefert künftige Geschäftsprozesse.

- Softwareentwicklung basiert auf sozialen Prozessen.

- Was Software ist, interessiert den Auftraggeber nicht.

- Der Auftraggeber will mit Hilfe von Software neue Produkte anbieten.

- Es empfielt sich, über "Use Cases" miteinander zu kommunizieren.