„WIR SIND DOCH SCHON ZUFRIEDEN, wenn ein Projekt einigermaßen im Budget bleibt und die Anwender sich nachher nicht laut beschweren.“ Der Leiter der Anwendungsentwicklung einer Bank, von dem dieses Zitat stammt, möchte nicht namentlich dazu stehen – wohl deshalb, weil es die schwierige Frage aufwirft: „Wie gut sind wir wirklich?“
Um darauf eine Antwort zu geben, sind statistische Verfahren erforderlich, die Softwareentwicklungs- Projekte anhand von Maßzahlen in puncto Kosten, Qualität und Zeitaufwand bewerten – gern belegt mit dem Schlagwort „Benchmarks“.
Unter IT-Entscheidern gibt es jedoch viel Skepsis. Keinen Ansatz für Benchmarks zum Zweck der Optimierung in der Softwareentwicklung sehen einige CIOs. Auch Olaf Röper, CIO des Dortmunder Chemieanlagen- Bauers Uhde aus dem Thyssen-Krupp-Konzern, gehört zu den Skeptikern. Der Nutzen einer Software hänge „nicht von der Effizienz des Erstellungsprozesses“ ab. Vielmehr stehe der Wertbeitrag einer Anwendung im Vordergrund, wenn es gelte, über die Entwicklung beziehungsweise Implementierung einer Software zu entscheiden. Den Wertbeitrag zu realisieren, indem man den „Prozess des Business Alignments organisiert und Potenziale identifiziert, etwa zur Standardisierung und Wiederverwertbarkeit der Abläufe” – darum gehe es. „Vor diesem Hintergrund sind Überlegungen zur Effizienzverbesserung des Software-Erstellungsprozesses zu relativieren“, meint Röper. Als Methodenmuffel möchte er allerdings nicht gelten. „Besondere zeitliche oder sachliche Einschränkungen“ könnten Messverfahren in der Entwicklung sinnvoll machen. Dazu gehören etwa gesetzliche Zeitvorgaben wie durch Basel II oder ein besonders enger Wettbewerb.”
Keine Wildcards für Laufzeit und Budget
Das ist nun wiederum durchaus konsensfähig unter Fachleuten. Kosten- und Effizienzdruck legen nämlich den meisten Entscheidern just solche Einschränkungen auf; strategische Entwicklungsvorhaben mit einer „Wildcard“ in puncto Laufzeit und Budget werden immer seltener. „Stattdessen werden Projekte in Portfolios eingeordnet und gewichtet – nach strategischer Relevanz, aber auch nach Zeit- und Ressourcenbindung”, stellt Achim Feyhl fest.
Der frühere CIO des Fuldaer Automotive-Unternehmens Edag, heute Interims-Manager und Autor (siehe Buchtipp), erläutert: „Man braucht eine Übersicht für die Fachabteilungen beziehungsweise für die Geschäftsführungen, um entscheiden zu können, welche Projekte mit welcher Wertigkeit und in welcher Reihenfolge abgearbeitet werden sollen.“ Auf jeden Fall jedoch benötige man für Benchmarkings verlässliche Anhaltspunkte, betont Feyhl. Also validierte Vergleichswerte, um die eigene Entwicklungsperformance dagegenmessen zu können. Ansonsten laufe man Gefahr, „Schlendrian mit Schlendrian" zu vergleichen.
Benjamin Poensgen, Geschäftsführer des Wiesbadener Analysespezialisten Quantimetrics, stimmt einerseits den Skeptikern zu: „Benchmarking an sich ist nicht strategisch, sondern taktisch.“ Andererseits könne es die Erreichung strategischer Ziele wie Kosten-, Produkt- und Qualitätsführerschaft sichern. „Jeder strategisch denkende Manager tut deshalb gut daran, sich mit Benchmarking zu beschäftigen", plädiert Poensgen.
Weit verbreitet in der Anwendungsentwicklung ist zu diesem Zweck die „Function-Point-Analyse“ (FPA). Mit diesem Verfahren wird bereits seit den achtziger Jahren der Funktionsumfang von Software aus Benutzersicht gemessen; die International Function Point User Group (www.ifpug.org) pflegt sogar einen international akzeptierten Standard dafür: IFPUG 4.1. Die Zahl der Function Points liefert das Basismaß für die Produktivität und Qualität einer Anwendung; gemessen werden Anzahl und Umfang fachlicher Funktionen. „Eine Software, die viel bietet, wird mit mehr Function Points bewertet“, fasst Poensgen, dessen Unternehmen Quantimetrics auf FPA setzt, den Ansatz bündig zusammen.
Die Methode wird typischerweise, aber nicht ausschließlich für Benchmarks eingesetzt. Darüber hinaus lassen sich mit Function Points Größe und Komplexität einer Anwendung messen, was vorab Schlüsse auf den zu erwartenden Aufwand bei der Wartung zulässt – allerdings nur im Vergleich mit anderen Anwendungen. Beim Verhandeln von Service-Level-Agreements kann die Methode als Grundlage für die Messung der Leistungen dienen. In der Softwarebeschaffung ermöglichen Function Points Preisvergleiche – sei es, um unterschiedliche Angebote miteinander zu vergleichen oder die Grundlage für eine Make-or-Buy-Entscheidung zu liefern. In jedem Fall erforderlich: eine Referenzdatenbank mit abgeschlossenen Projekten, um Vergleiche anstellen zu können.
Commerzbank nutzt Referenzdatenbank
Die Commerzbank etwa stellt in der zentralen Anwendungsentwicklung Vergleiche mit Projekten an, die in einer selbst aufgebauten Referenzdatenbank gespeichert sind. Der Zweck: bei neuen Anwendungen und Erweiterungen vorhandener Applikationen Verbesserungspotenzial aufdecken, etwa was die Wartungskosten angeht. Das ist nicht trivial und schon gar nicht kostenneutral. „Die Bewertung eines Softwaresystems kann nicht vollständig automatisiert werden. Zur Messung durch einen Function-Point-Spezialisten gibt es keine Alternative“, räumt Quantimetrics-Chef Poensgen ein. Und wenn ein Unternehmen nicht möchte, dass externe Fachleute den Entwicklern über die Schulter schauen, die Zählungen und Auswertungen also intern durchführen will, dann muss es dazu, wie die Commerzbank, eine eigene Infrastruktur etablieren: Neun Function-Point-Experten stehen beim viertgrößten deutschen Finanzinstitut auf der Payroll.
Auch die Festnetztochter der Deutschen Telekom, T.Com, nutzt FPA als Methode, und zwar zur Steuerung ihrer Software-Entwicklungspartner, die mit knapp 1400 Mitarbeitern in zirka 180 Projekten pro Jahr tätig sind. Das Ziel, so Ulrich Völkoi aus dem Bereich Informationsmanagement und Prozesse: die IT-Projekte im „magischen Dreieck“ von Kosten, Zeit und Qualität optimieren. Sowohl intern als auch extern wird verglichen: intern etwa die Anzahl der Änderungsanforderungen aus den Fachbereichen, die Anzahl der verschobenen Termine und die Fehlerzahl in der Software. Externe Vergleiche anhand von Function Points beziehen sich unter anderem auf Produktität (FP pro Personenmonat) und Stückkosten je Function Point. Laut Völkoi hat T.Com mit diesem Verfahren „signifikante Einsparungen“ realisiert.
Vielleicht kommt es auch gar nicht so sehr darauf an, welches Verfahren man im Entwicklungs-Controlling anwendet. Allein das Bewusstsein bei den Entwicklern, beobachtet zu werden, kann nämlich eine Produktivitätssteigerung bewirken. Schon in den zwanziger Jahren des letzten Jahrhunderts hat der US-Psychologe Elton Mayo genau diesen Effekt nachgewiesen. Im Werk Hawthorne von Western Electric studierte er fünf Jahre lang Arbeiter. Allein dadurch, dass sie unter Kontrolle standen und das auch wussten, waren die beobachteten Western-Electric-Worker produktiver als ihre Kollegen, auf deren Arbeit man kein so scharfes Auge warf. Poensgen ist überzeugt, dass dieser Effekt (Volksmund: „Das Auge des Herrn macht das Vieh fett.“) sich auch bei der Softwareentwicklung einstellt.
Plädoyer für realistische Zeitpläne
Man sollte allerdings aufpassen, dass die Planer und Akteure in der Softwareentwicklung es mit dem Eifer nicht übertreiben, meint Falk Janotta, Interims-Projektmanager aus Wilhelmshaven. Wenn nämlich bereits in der Planungsphase enge Zeitvorgaben akzeptiert würden, um auch ja mit guten Kennzahlen in ein Projekt einzusteigen, seien Projektverantwortliche von Anfang an in der Defensive. Häufig bleibe noch nicht einmal genug Zeit, ein Projekt seriös durchzuplanen und dann mit der Geschäftsleitung oder der Fachabteilung über eine realistische Projektstruktur und damit einen realistischen Zeit- und Kostenplan zu reden.
Janotta lehnt Benchmarking in der Softwareentwicklung nicht ab. Um mehr Qualität und einen höheren Wertbeitrag der Software zu erreichen, plädiert er, sei jedoch etwas anderes vordringlich: „weniger Zeitdruck, kleinere Einheiten und mehr Aufwand für Analyse, Konzeption und Spezifikation von Projekten“.