IT-Bereiche von Unternehmen stehen derzeit unter verstärktem Kostendruck, der sich auch in den Budgets für das IT-Projektportfolio niederschlägt. Trotzdem erwarten die Auftraggeber den gleichen Leistungsumfang. Ähnlich ergeht es IT-Dienstleistern, die verstärkten Konkurrenzdruck beim Angebot von Anwendungsentwicklungs-Leistungen spüren.
Um die gleiche Leistung bei geringeren Kosten erbringen zu können, müssen IT-Bereiche die Produktivität ihrer Anwendungsentwicklung (AE) steigern. Doch es ist bereits schwierig, den realisierten fachlichen Umfang zu beziffern. Alle angewandten Messmethoden sind umstritten.
Die Function-Point-Methode ist allerdings relativ weit verbreitet. Doch auch an ihr gibt es Zweifel: Wesentliche Kritikpunkte sind ihr geringes Kosten-/Nutzen-Verhältnis sowie die mangelnde Aussagekraft. Denn dieses Messverfahren lässt selbst im Falle der Anwendung einer standardisierten Vorgehensweise gemäß IFPUG (International Function Point Users Group) noch Interpretationsmöglichkeiten zu, die zu unterschiedlichen Zählergebnissen führen können.
Außerdem sind die Messergebnisse nur begrenzt vergleich- und aggregierbar, weil unterschiedliche Variablen das Verfahren beeinflussen: zum Beispiel Host- vs. Client-Server-Technologien, Neu- vs. Weiterentwicklung, große vs. kleine Projekte oder Eigenentwicklung vs. Standardsoftware. Und schließlich stellt sich die Frage, welche konkreten Handlungsanweisungen sich aus den Messungen ableiten lassen.
Viele Unternehmen führen daher gar keine systematische Anwendungsentwicklungs-Produktivitätsmessung durch, sondern versuchen, ihre Produktivität indirekt zu optimieren, beispielsweise durch eine höhere Qualität. Diese lässt sich erreichen durch eine Reduktion der Anzahl der Defects, durch Sicherstellung von "on time" / "on budget" / "on specification" für Projekte oder schlicht durch eine niedrigere IT-Kostenquote.
Rahmenbedingungen für AE-Produktivitätsmessung sicherstellen
Einige Unternehmen versuchen, die beschriebenen Herausforderungen der Function-Point-Methode zu meistern und machen damit grundsätzlich positive Erfahrungen. Mehrere Punkte entscheiden dabei über den Erfolg:
Aufwand: Um den Aufwand für die Messungen in Grenzen zu halten, sollte ein spezialisiertes Team gebildet werden, das die Messungen für alle Projekte durchführt und so die erforderliche Routine erwirbt und behält.
Eindeutigkeit: Um die Eindeutigkeit der Messergebnisse sicherzustellen, sind zunächst einheitliche Zählstandards nötig. Damit diese auch durchgesetzt werden, sollte das spezialisierte Team die Zählungen durchführen, und zwar für alle Projekte. Die gesammelten Erfahrungen und aufgekommenen Fragen sollten im Team regelmäßig ausgetauscht werden.
Vergleichbarkeit: Um sicherzustellen, dass vergleichbare Projekte gegenübergestellt werden, sollte die Function-Point-Messung in geeignete Cluster aufgeteilt werden (zum Beispiel Projekte für Host vs. Server vs. gemischt). Dadurch können zwar die Cluster-Werte nicht aggregiert werden – eine Gesamt-Produktivitätszahl für die gesamte AE ist nicht möglich – aber dafür sind die Werte für die jeweiligen Cluster historisch und in Benchmarkings vergleichbar.
Aussagekraft: Um konkrete Steuerungsinformationen ableiten zu können, müssen die Function-Point-Messergebnisse um weitere Indikatoren ergänzt werden, zum Beispiel um Informationen aus einer Analyse des Softwareentwicklungs-Prozesses. Außerdem sollten die Function-Point-Ergebnisse auf einer möglichst detaillierten Ebene, etwa der Software-Modulebene, erhoben werden, um die Interpretationsfähigkeit zu erhöhen.
Darüber hinaus ist wichtig, dass die Messungen sowohl von Auftraggebern als auch IT-intern akzeptiert werden. Das Commitment des Managements, die Neutralität der Zählung, die Transparenz und der Nutzen für alle Beteiligte sowie eine konsequente Anwendung der Methode können IT-interne und IT-externe Vorbehalte entkräften (siehe Abbildung 1).
Unternehmen können die Function-Point-Messung also grundsätzlich erfolgreich anwenden. Eine einfache Erfolgsformel gibt es aber nicht: Jedes Unternehmen muss seinen eigenen Weg finden. Die Benchmarking-Daten unterschiedlicher Anbieter lassen Rückschlüsse auf die Anwendungsentwicklungs-Produktivität anderer Unternehmen zu. Zählen Unternehmen die Function-Points im Rahmen der fachlichen Spezifikation und gleichen sie mit historischen Aufwandsdaten ab, können sie den Aufwand einzelner Projekten sehr viel genauer abschätzen.
AE-Produktivität als Kennzahl in CIO-Cockpit einbeziehen
Auch wenn es mit der Function-Point-Methode nicht möglich ist, eine einzelne, aggregierte Anwendungsentwicklungs-Produktivitätskennzahl zu ermitteln, ist die Aufnahme der Anwendungsentwicklungs-Produktivität als Effizienz-Indikator in das CIO-Cockpit hilfreich. Statt einer einzigen Kennzahl müssen vielmehr geeignete Cluster definiert und berichtet werden, zum Beispiel zu kleinen und großen Projekten (siehe Abbildung 2).
Anhand der historischen Daten lässt sich so die AE-Produktivitätsentwicklung für IT und Auftraggeber darstellen und so eventuell im Zusammenspiel mit anderen Kennzahlen ermitteln, wo Handlungsbedarf besteht. Wenn zusätzlich zur Verschlechterung der AE-Produktivität (etwa der Anzahl der Function-Points pro Personenmonat) eine Zeitüberschreitung der jeweiligen Projekte identifiziert wird, können die Gründe hierfür zum Beispiel in Mängeln in der Auftrags-Spezifikation oder im Projektmanagement liegen.
Druck von Fachabteilungen zuvorkommen
Ob ein Unternehmen Anwendungsentwicklungs-Produktivitätsmessung betreiben sollte oder nicht, lässt sich nicht pauschal beantworten. Um den größtmöglichen Nutzen für das Unternehmen zu erzielen, bedarf es jedenfalls einer individuellen, maßgeschneiderten Lösung.
Ein weiterer wichtiger Erfolgsfaktor besteht darin, dass die IT das Thema von sich aus aktiv angeht und so vermeidet, dass die Fachabteilungen hinsichtlich des IT-Leistungsumfangs Druck auf sie ausüben. Sind die IT-Produktivitäts-Kennzahlen in ein geschäftliches Cockpit eingebettet, kann die IT die entsprechende Transparenz schaffen.
Matthias Gröbner ist Projektmanager im Kompetenzzentrum InfoCom bei Roland Berger Strategy Consultants.