Jeder CIO kennt diesen Druck: Das Applikationsportfolio unterliegt dynamischen Veränderungen und muss kontinuierlich gepflegt werden. Hier wie in jedem anderen Bereich, der dem CIO unterstellt ist, sind zudem die Nutzung von Einsparungsmöglichkeiten sowie Preistransparenz wichtig. Das Management der Applikationen wird jedoch meist in Form intransparenter Festpreisverträge vom externen Service Provider übernommen.
Der Status Quo
Die IT-Applikationsportfolios der Fortune 500-Unternehmen sind in den vergangenen 15-20 Jahren in historischem Ausmaß gewachsen. Sie umfassen im Normalfall zwischen 800 und 2000 Applikationen in verschiedenen Technologien und Geschäftsbereichen sowie in verschiedenen Stadien ihrer Lebensdauer, von neu bis auslaufend.
Aufgrund dieser unterschiedlichen Lifecycle-Stadien der Applikationen ist eine Portfolio-Wechselrate von bis zu 40 Prozent während einer Laufzeit von 4-5 Jahren nicht ungewöhnlich. Da auch die IT immer schneller auf wirtschaftliche Anforderungen reagieren muss, wird die Wechselrate immer höher. So kommen während der Vertragslaufzeit ständig neu entwickelte Applikationen hinzu und alte werden aus dem Programm genommen. Fazit: Standard-Preismodelle sind schlicht und einfach nicht mehr zeitgemäß.
Ein weltweit tätiges Fortune 100-Unternehmen etwa hat ein Applikationsportfolio mit über 2000 Applikationen, die sich auf über 15 Geschäftseinheiten und verschiedene Technologie-Stacks erstrecken. Ein Lieferanten-Konsolidierungsprogramm zur Kostensenkung führte zur Konzentration der ADM-Services (Application Development and Maintenance) auf einige wenige große Anbieter.
Die Idee hierbei war, durch einen Festpreisvertrag mit fünf Jahren Laufzeit die Kosten vorhersagbar zu gestalten. Der stetige Wechsel in den Applikationsportfolios führte dann jedoch zu monatlichen zähen Diskussionen mit den Service Providern über die Preisgestaltung für Änderungswünsche.
Die bei solchen Verträgen verwendeten Standard-Preismodelle wie Festpreisverträge und ticketbasierte Preismodelle sind nicht geeignet, dem stetigen Wechsel im Portfolio gerecht zu werden.
Preismodelle sind auf Bedürfnisse der Service Provider ausgerichtet
In aktuellen Fachbeiträgen wird die Preisgestaltung entweder in Form von Strategien aus der Sicht des Service Providers behandelt (Penetrationsstrategien, Skimming-Strategien) oder als Vergleich zwischen häufigen Formen der Preisstellung (Festpreis vs. Preis nach Aufwand).
Die meisten der oben genannten Preismodelle (Festpreis, Berechnung nach Aufwand, Volumenpreis,…) sind direkt in den Arbeitskosten begründet und spiegeln die Welt des Service Providers wider.
In Verbindung mit dem Wettbewerbsumfeld, in dem solche Vereinbarungen geschlossen werden, greifen Service Provider oft auf Standard-Preisstrategien zurück - auch wenn sie längst nicht mehr die aktuellen Bedürfnisse der Unternehmen wieder spiegeln.
Standard-Preismodelle sind unflexibel und nicht transparent
Daraus ergibt sich ein Muster, Standard-Preismodelle sind:
-
Unflexibel: Viele Festpreisverträge für das Applikationsmanagement werden auf der Grundlage einer Momentaufnahme des aktuellen Applikationsportfolios geschlossen. Solche Verträge müssen mit vielen Änderungsanfragen ständig aktualisiert werden, um die Änderungen im Portfolio zu berücksichtigen - und dies über die gesamte Vertragslaufzeit.
-
Nicht transparent: Applikationen werden in Verträgen oft gebündelt, wodurch versucht wird, Synergieeffekte bei den verschiedenen Services im Portfolio zu realisieren. Während solche Synergien bei den Gesamtkosten durchaus lohnenswert sind, können die IT-Manager nicht mehr mit Sicherheit sagen, was sie die Pflege einer bestimmten Applikation kostet. Dies spielt jedoch eine wichtige Rolle bei "Buy vs. Build"-Entscheidungen.
Die ständigen Veränderungen im Applikationsportfolio führen zu zahlreichen Diskussionen über Änderungsanfragen, bei denen es sich um kleine Geldbeträge dreht. Das Management solcher Verträge wird zu einem kostspieligen Fulltime-Job. Bei einem durchschnittlichen monatlichen Preis in der Größenordnung von 300 - 700 Euro pro Applikation in so großen Portfolios ist dieser Aufwand nur schwer zu rechtfertigen.
Probleme mit heute gebräuchlichen Preismodellen Festpreise für große Portfolios legen den Preis für den aktuellen Zustand des Portfolios fest, wobei nachfolgende Portfolio-Änderungen durch Änderungsanfragen gehandhabt werden müssen. Jede Änderungsanfrage könnte dann mit einem Service Provider verhandelt werden, der den Auftrag möglicherweise über Penetrationspreise gewonnen hat und jetzt versucht, die verlorenen Margen wieder gutzumachen. Nach Aufwand abgerechnete Verträge verlagern das Betriebsrisiko vollständig auf die IT-Abteilung. Volumenbas ierte Preismodelle wie z.B. ticketbasierte Preise mögen auf den ersten Blick gut aussehen, da sie sich nach der Größe des Betriebs richten - aber fördern sie auch das richtige Verhalten des Providers? Ein Service Provider, der durch proaktives Problemmanagement die Anzahl der Tickets verringert, schadet seinen eigenen Umsätzen. |
Um die Kosten ihrer komplexen und dynamischen Applikationsportfolios effektiv im Griff behalten zu können, sollten sich CIOs nicht mit dem bestehenden Angebot des Marktes zufrieden geben - sondern ein Kostenmodell anstreben, das ihren individuellen Anforderungen entspricht.
Anforderungen an ein Anwenderfreundliches Modell
Grundsätzlich gilt, dass ein derartiges "kundenfreundliches" Modell
-
für die Zukunft skalierbar ist: Das Modell sollte Änderungen aller Art im Applikationsportfolio über die Laufzeit des Service-Vertrages durch Skalierung berücksichtigen.
-
transparent und abgestuft ist: Die Kosten müssen pro Applikation angegeben werden, so dass der Kosteneffekt jedes Services problemlos berechenbar und transparent ist.
-
das richtige Verhalten fördert: Die Preisgestaltung des Service Providers sollte ein gutes Verhalten fördern und belohnen.
-
elastisch ist: Das Modell sollte flexibel sein und sich dem Geschäftsumfang anpassen; es sollte jederzeit den Aufwand für die Serviceleistung wiedergeben.
-
die richtige Risikoverteilung sicherstellt: Das Modell sollte das Betriebsrisiko derjenigen Partei (IT-Abteilung oder Service Provider) zuordnen, die am besten mit diesem Risiko umgehen kann.
Das ideale Kostenmodell für Applikationen
Ein Applikationskostenmodell, das die Realität in einer IT-Abteilung tatsächlich widerspiegelt, sollte aus drei Säulen bestehen, die gemeinsam die Ziele unterstützen:
-
Gesamtfestpreis für das gesamte Applikationsportfolio als Summe der Basispreise pro Applikation auf der Grundlage von deren individuellen Eigenschaften (wie Komplexität und Stabilität).
-
Preiskategorien zur Festlegung der Bandbreite der Basispreise; diese werden dann zur Preisgestaltung für jede neue Applikation innerhalb dieses Bereichs verwendet.
-
Multiplikationsfaktoren für verschiedenen Service-Bedingungen (z.B. Doppelschichten, Support an Wochenenden,....); diese Faktoren entkoppeln die Service-Bedingungen von den Eigenschaften der Applikationen.
Ein solches Kostenmodell sollte sehr sorgfältig konzipiert werden, da es die Grundlage für die gesamte zukünftige Vertragsgestaltung und das Kostenmanagement bildet. Bevor ein Unternehmen in den Dialog mit einem Service Provider tritt oder gar einen Vetragsabschluss erwägt, sollte es seine Hausaufgaben erledigt haben. Dazu zählen etwa die frühzeitige Analyse des Applikationsportfolios sowie die Festlegung der finanziellen Grundlagen.
Einige Fortune 500-Unternehmen haben bereits die ersten Schritte zur Einführung eines solchen Applikationskostenmodells getan, indem sie die Dienste externer Sourcing-Berater in Anspruch genommen haben, und die Ergebnisse sind ermutigend.
Ein europäisches Unternehmen hat ein solches Modell bereits für 30 Prozent seines gesamten Applikationsportfolios umgesetzt. Es hat die vergangenen drei Jahre sehr genau betrachtet, um die einzelnen Parameter auf seinen Bedarf abzustimmen und befindet sich jetzt mitten in der Einführung des entwickelten und abgestimmten Modells für den Rest der Applikationen.
Ein anderes Unternehmen zieht die Einführung eines solchen Modells bei der Neuverhandlung eines Vertrages mit seinem aktuellen Provider in Betracht, um seinen Vertrag transparent zu machen, ohne unbedingt den Provider wechseln zu müssen.
In den vergangenen drei Jahren haben sich auch führende Anbieter von Applikationsmanagement-Lösungen mit solchen Modellen vertraut gemacht und zeigen Bereitschaft, die Preise für ihre Leistungen entsprechend zu gestalten.
Das Modell muss zukunftsorientiert sein
Bei der Umsetzung eines transparenten Applikationskostenmodells sollten CIOs die folgenden Elemente einer flexiblen Service-Erbringung in den Vordergrund stellen:
-
Klare Zuordnung zwischen Service-Angebot und Preisen, damit ersichtlich ist, welche Services durch den Basispreis pro Applikation abgedeckt werden.
-
Zusammenfassung gleichartiger/ähnlicher Applikationen, damit die Unterschiede innerhalb der Preiskategorie im akzeptablen Rahmen bleiben.
-
Faktor Produktionseffizienz im Zeitverlauf: dieser Punkt sollte als zusätzlicher Faktor in das Preismodell aufgenommen werden.
-
Berücksichtigung aller Service-Elemente, die sich wesentlich auf die Preisgestaltung auswirken, z.B. die Zeitzone, in welcher der Service erbracht werden soll.
-
Vereinbarung von Richtlinien , die festlegen, wie Änderungen der Aufwands- und Service-Treiber während der Vertragslaufzeit berücksichtigt werden sollen.
-
Abrechnung nach Aufwand (für Arbeitszeit und Ausgaben) zur Abdeckung aller Services (z.B. Umsetzung von Änderungsanfragen), die nicht durch den Basispreis abgedeckt werden.
Preistransparenz und Flexibilität in Applikationsportfolios sind möglich
Mit einem erfolgreich implementierten Applikationsportfolio Kostenmodell können Unternehmen den Spagat zwischen Transparenz, Skalierbarkeit, Flexibilität und Vorhersehbarkeit (Predictability) meistern.
Mit zunehmender Beliebtheit solcher Modelle haben einige Fortune 500-Unternehmen in Europa bereits die ersten Schritte mit vielversprechenden Ergebnissen getan, und viele andere dürften ihrem Beispiel folgen.
Alexander Müller-Herbst ist Partner Managing Director bei der Information Services Group Germany GmbH (ISG).