In sieben Schritten zur Kosten/Nutzen-Analyse

Nicolas Stammel ist Junior Consultant bei der Berliner Beratungsfirma Lexta.

Jeder IT-Manager kennt den Zielkonflikt zwischen den Kosten, die eine Applikation verursacht und dem Nutzen, den sie für das Unternehmen bringt. Dabei steht er nicht selten einem scheinbar unlösbaren Paradoxon gegenüber: Einerseits hat er dafür zu sorgen, dass die Applikation «optimal» betrieben wird. Andererseits ist niemand in der Lage, näher zu definieren, was «optimal» im Fall dieser Applikation eigentlich genau bedeutet.

Im Versuch, solche Zielkonflikte zwischen den Kosten- und Nutzen-Erwägungen aller beteiligten Anwender und Verantwortlichen zu umschiffen, begeben sich viele IT-Manager auf die Suche nach Musterbeispielen, halten Ausschau nach anderen Unternehmen in ähnlichem Fahrwasser. Der Ansatz dieser Vorgehensweise: Es sollen bei vermeintlichen «Best-in-Class»-Organisationen die vermuteten «Best Practices» abgespickt werden. Prinzipiell kein abwegiger Gedanke. Allerdings gilt es dabei zu bedenken: Wer nichts falsch macht, hat noch lange nicht alles richtig gemacht!

Entsprechend ist ein «Copy & Paste»-Ansatz für den Applikationsbetrieb leider in den allermeisten Fällen nicht möglich. Unternehmen sind individuell, die Anforderungen unterschiedlich, keine Umsetzung gleicht der anderen.

Zu Recht wird bei Optimierungsversuchen deshalb auf sauber funktionierende Prozesse verwiesen. Schliesslich ist der Benchmark von End-to-End-Leistungsbeziehungen ein probates Mittel, um Optimierungspotenziale aufzudecken und nutzbar zu machen. Eine Vielzahl verschiedener Kennzahlensysteme und Kennzahlen unterstützen die Verantwortlichen hierbei.

Im Folgenden wird eine Vorgehensweise vorgestellt, welche die verantwortlichen IT-Manager in die Lage versetzt, mit bereits vorhandenen Informationen und Ressourcen eine Standortanalyse ihrer Applikationslandschaft durchzuführen. Nicht der allzeit beste Betriebsmodus ist das Ziel, sondern die -Herausstellung all jener Merkmale und Potenziale vorhandener Applikationen, welche diese zu einer Best-Practice-Lösung führen können. Notwendige Daten lassen sich leicht auch im eigenen Unternehmen schürfen. Oder anders gesagt: Unternehmen können von sich selbst lernen. Dafür sind lediglich sieben Schritte notwendig:

Zunächst gilt es, eine überschaubare Anzahl an Applikationen auszuwählen, die untersucht werden sollen. Dabei ist darauf zu achten, dass nicht nur Problemapplikationen darunter sind. Ebenso wichtig sind Positivbeispiele, welche als Vergleichswerte dienen. Das sind gerade solche Applikationen, die in der subjektiven Wahrnehmung der Anwender sehr gut positioniert sind.

Zudem sind für jede ausgewählte Applikation die laufenden Service- und Supportkosten sowie deren aktuelle Nutzerzahl zu ermitteln. Dabei ist unbedingt zu beachten, dass die Kosten auf die gleiche Art und Weise abgegrenzt wurden.

Die Stakeholder einer Applikation lassen sich grundsätzlich in vier Gruppen einteilen. Zum einen gibt es jene, die der Applikation Daten zuliefern. Zum anderen gibt es jene, die den Output einer Applikation nutzen. Manchmal können beide Gruppen auch kongruent sein. Darüber hinaus partizipieren jeweils die inhaltlich und die technisch verantwortlichen Abteilungen.

Für jede ausgewählte Applikation ist mindestens eine Person aus jeder Stakeholder-Gruppe heranzuziehen. Jede dieser Personen soll aus ihrer jeweiligen Perspektive im nächsten Schritt und im weiterführenden Analyseprozess als Ansprechpartner Auskunft geben.

Für diese Analyse ist es vollkommen hinreichend, die Applikationen von den Stakeholdern ordinal bewerten zu lassen. Daraus kann bereits eine fundierte Einschätzung getroffen werden. Bewährt haben sich Fragebögen, die auf einer Skala von 1 («Trifft nicht zu») bis 5 («Trifft vollkommen zu») zu beantworten sind. Darüber hinaus kann von den technisch Verantwortlichen die Komplexität der Applikation mit einem relativ einfachen Fragebogen ermittelt werden.

Nun lässt sich das Applikationsportfolio darstellen (siehe Grafik). Ziel dieser Darstellung ist es, einen groben Überblick zu erhalten, welche Applikationen aus dem Ruder laufen. Jede Applikation wird dazu als Kreis dargestellt, wobei der Mittelpunkt den entsprechenden Kennziffern entspricht und der Radius linear abhängig zu den Gesamtkosten berechnet wird.

Anhand dieser Darstellung lassen sich sehr schnell Schwierigkeiten ablesen. Denn wünschenswert sind Applikationen, die im oberen rechten Bereich der Grafik rangieren. Applikationen, die im unteren linken Bereich der Grafik liegen, weisen indes gravierende Schwierigkeiten auf, sowohl im Bereich der Effizienz wie auch bei der fachlichen Erfüllung. Diese Applikationen bedürfen besonderer Aufmerksamkeit. Applikationen, die im linken oberen Bereich dargestellt werden, erfüllen zwar die Anforderungen, benötigen dafür aber einen grossen Aufwand. Applikationen in der rechten unteren Ecke hingegen benötigen nur wenig Aufwand, können aber auch ihre fachlichen Anforderungen nicht voll erfüllen.

Für die weiteren Analyseschritte ist es notwendig, eine Referenzapplikation zu definieren. Dazu sollte eine Anwendung gewählt werden, die im Applikationsportfolio möglichst rechts oben angesiedelt ist und deren Reifegrad bereits institutionalisiert ist. Die bereits erwähnten Positivbeispiele dienen als Richtwerte.

Ziel dieser Untersuchung ist es nicht, den unter allen Bedingungen richtigen Betriebsmodus zu finden, sondern die Merkmale und das Potenzial zur individuellen Best-Practice-Lösung zu identifizieren. Dafür werden beispielsweise die Kostenpositionen der Referenzapplikationen mit den zuvor bestimmten Kennzahlen skaliert, um die theoretischen Kosten der untersuchten Applikation zu schätzen.

Die Differenz zwischen tatsächlichen Kosten und theoretischen Kosten ergibt letztlich das geschätzte Optimierungspotenzial. Wenn man diese Rechnung nicht auf die Gesamtkosten, sondern auf Teilkosten, wie zum Beispiel Fremdleistungsanteil Second-Level-Support bezieht, erhält man eine feinere Auflösung, was eine spätere Ursachensuche deutlich erleichtert.

Bildet man das Verhältnis von theoretischen Kosten zu tatsächlichen Kosten, so erhält man eine Kennzahl, die alle vorangegangen Überlegungen verdichtet. Diese Grösse wird als «Fortschritt der Optimierung» definiert. Sie sollte zwischen 0 und 100 Prozent liegen, kann aber in Ausnahmefällen dieses Intervall auch verlassen.

Wenn Schritt 6 einen Optimierungs-Fortschritt von weniger als 100 Prozent ergeben hat, wird es interessant, die Ursachen auszuloten. Für eine erste Identifikation sollten die Fragebögen der Referenzapplikation und der untersuchten Applikation gegen-über-gestellt werden. Die Kategorie der Herausforderung lässt sich dann schnell bestimmen. Die häufigsten Fehlerquellen, so zeigt die Erfahrung, sind Schulungs-, Informations-, GUI- (General User Interface) und Design-Defizite, unklare Funktionalitäten, supportintensive Release-Wechsel, mangelhafte Stabilität sowie fehlerhafte Funktionen der Applikationen.