Checkliste für das Reduzieren von IT-Kosten

Stand in den Krisenjahren für die IT Kostensenkung im Mittelpunkt, beginnt mit dem Aufschwung wieder eine Investitionsphase. Die IT muss dem Business Wachstumsimpulse geben und bei Bedarf neue Geschäftsmodelle unterstützen. Doch auch jetzt werden ihre Budgets kaum explodieren - sprich: Die Mittel für Investitionen muss sich der CIO zum erheblichen Teil selbst "freischaufeln".

Ein wichtiges Optimierungspotenzial findet er im Applikationsbetrieb. Im gesamten Applikationsbetrieb inklusive der zugehörigen Infrastruktur sind nicht selten 70 bis 80 Prozent der Gesamtkosten gebunden. Aufgrund der Historie - nicht zuletzt infolge oft widersprüchlicher Vorgaben der Fachbereiche - bestehen hier nach wie vor viele Redundanzen, Doppel-Implementierungen und funktionale Lücken sowie ein bunter Mix aus Plattformen, Schnittstellen und Werkzeugen.

Ziel sollte es sein, den Anteil des "RUN" deutlich unter 50 Prozent zu drücken - und die freiwerdenden Mittel in den jetzt dringend benötigten "CHANGE" zu investieren
(siehe Grafik 1).

Ansatzpunkte bietet bereits das Anwendungsvolumen. Große Unternehmen betreiben oft 1000 Applikationen und mehr. Eine Reduzierung ist meist sinnvoll und notwendig. Das betrifft zunächst die Verwaltungstools und Office-Applikationen. Deren Standardisierung senkt nicht nur die Komplexität, sondern oft - quasi als Seiteneffekt - auch die Lizenzkosten.

Noch wichtiger ist eine Konsolidierung der Business-Applikationen. Die Instrumente dafür liefert ein professionelles, zeitgemäßes Application Lifecycle Management (ALM).

Dimensionen des Application Lifecycle Management

Generell steht der CIO vor der Herausforderung, die Applikationen in eine Struktur zu bringen, mit der er sie als Gesamtportfolio bewerten kann. Hier hilft ihm ein systematischer, modellgestützter Ansatz. Er sollte nicht nur Hard-Facts berücksichtigen, sondern auch subjektive Faktoren wie etwa Experteneinschätzungen einfließen lassen. Die Prüfung und Bewertung sollte fünf Dimensionen abdecken (vergleiche Grafik 2).

1. Business-Fit

Inwieweit passt die vorhandenen Anwendungslandschaft zu den Wertschöpfungsprozessen ?

In einem Mapping wird untersucht, welche Prozesse das Unternehmen betreibt und welche Applikationen welche Abläufe unterstützen.

Ein Beispiel: Im Versicherungswesen kann das die "Verwaltung von Policen" mit den Geschäftsprozessen Call Center, Beitrags- und Bestandsverwaltung, Schadenregulierung, Zahlungen oder Kundenkorrespondenz sein; ihnen werden dann alle Anwendungen zugeordnet, die sie unterstützen. Dabei werden Redundanzen und Überlappungen transparent. Weiterhin wird geprüft, welche System- und Prozess-Brüche an den Schnittstellen bestehen und ob die Applikationen zur Ziellandschaft passen, ob sie künftige Services und Produkte unterstützen.

Im Fokus sollten jene Prozesse stehen, die langfristig im Haus bleiben und nicht ausgelagert werden. Hier ist die klassische "Make or Buy"-Entscheidung auf Prozesse anzuwenden. Sind neue Geschäftsmodelle und Business-Initativen geplant, werden auch Anwendungslücken erkannt, die durch Investitionen geschlossen werden müssen. Ziel sollte es sein, jede fachliche Anforderung durch maximal ein Softwaremodul zu unterstützen.

2. Anwender-Unterstützung

Hier wird die Anwenderzufriedenheit untersucht. Kriterien sind zunächst die klassischen Service Level Agreements:

• Wie stabil ist die Anwendung?

• Wie lange steht sie zur Verfügung, wie oft fällt sie aus?

• Wie häufig kommt es zu Fehlern?

• Wie gut ist ihre Performance (Antwortzeitverhalten etc.)?

• Wie sieht die Applikations-Ergonomie aus, gemessen an einfacher Handhabbarkeit und Automatisierungsgrad: Wie viele Schritte sind erforderlich, um bestimmte Geschäftsprozesse abzuschließen?

• Wie viele Masken muss der Nutzer dazu öffnen?

• Muss er Daten doppelt eingeben, sind häufige Wechsel zwischen Maus und Tastatur notwendig?

Neben den Hard-Facts sind hier auch Zufriedenheitsbefragungen angebracht, denn die Nutzer nehmen die Qualität oft anders war, als die Erfüllung üblicher SLA-Kriterien dies vorspiegelt.

3. Technologie

Entspricht die Architektur den künftigen Anforderungen:

• Passen die Anwendungen zu den Standards im Unternehmen?

• Oder läuft etwa die Applikation auf einer Plattform, die man mittelfristig abschaffen möchte? (Wie beispielsweise das Betriebssystem BS2000, dessen Pflege heute hohe Kosten verursacht).

• Erlaubt die Architektur die Portierung auf andere Systeme, inklusive Cloud-Services?

• Wie steht es um die Erweiterbarkeit: Sind funktionale Änderungen ohne Programmierung - über Parameter - möglich?

• Welche Schnittstellen zu anderen Anwendungen gibt es - können neue Module zugekauft werden, oder ist eine völlige Neuentwicklung notwendig?

• Handelt es sich um einen monolithischen Block, oder besteht die Applikation aus wieder verwendbaren Modulen?

• Und last but not least: Ist eine Dokumentation vorhanden und ist sie vollständig?

4. Kosten

Wie hoch sind die Kosten für das Betreiben und die Wartung einer Applikation?

Hier ist es wichtig, wirklich alle Kosten vollständig zu erfassen: Hardware, Mitarbeiter, Software-Lizenzen sowie die umgelegten Gemeinkosten (Rechenzentrum etc.). Für viele Unternehmen ist bereits eine solche Vollkostentransparenz ein großer Gewinn. Oft stellt sich heraus, dass kleine Anwendungen, die für das Business relativ unbedeutend sind, einen hohen Kostenanteil verursachen.

5. Risiken

Sowohl interne als auch Marktrisiken sind zu bewerten.

• Sind genügend (interne und externe) Mitarbeiter verfügbar, um eine Applikation zu pflegen, und wenn ja: in welcher Kostenhöhe? Beispielsweise sind heute Spezialisten für auslaufende Systeme wie BS2000 oder Programmiersprachen wie Assembler und mittlerweile auch Cobol knapp und entsprechend teuer.

• Besteht eine Abhängigkeit von bestimmten Lieferan-ten, die eventuell vom Markt verschwinden können (wie etwa im Fall von Baan)?

• Das Risiko spiegelt sich auch im Verhältnis von Standardsoftware und Eigenentwicklungen: Bei einem hohen Standard-Anteil verringert sich die Abhängigkeit von Spezialisten. Doch wird der Hersteller diese Applikation auch mittelfristig zur Verfügung stellen? Beide Risiken sind gegeneinander abzuwägen.

• Zur Risikoanalyse gehört außerdem das gesamte Thema Compliance (gesetzliche Vorgaben, eventuelle Sicherheitslücken etc.).

Modellgestützter Entscheidungsbaum

Im nächsten Schritt kann der CIO das systematisch erfasste Applikationsportfolio im Zusammenhang bewerten. Dazu kann er einen Entscheidungsbaum aufbauen, in dem jede Anwendung gelistet ist. Ihr Life Cycle wird dann anhand der oben skizzierten Kriterien in drei Kategorien klassifiziert (vergleiche Grafik 3):

• Grün - die Applikation erfüllt alle Anforderungen und wird weiter betrieben.

• Gelb - die Anwendung ist zu beobachten, eventuell zu ergänzen.

• Rot - hier ist sofortiges Handeln notwendig: abschalten, neu entwickeln, auf eine andere Umgebung portieren oder durch Standardsoftware ersetzen.

In der Praxis ist nur ein Viertel der Anwendungen in den grünen Bereich einzuordnen - 50 Prozent werden in der Regel mit gelb, 25 Prozent sogar mit rot klassifiziert. Diese Erkenntnisse, die direkt die strategische und operative Handlungsfähigkeit des Unternehmens berühren, erkennt der CIO erst durch einen solchen systematischen Check-up.

Bei gelb und rot Cloud und SaaS prüfen

Bei Anwendungen, die in die gelbe oder rote Kategorie eingeordnet werden, ist der Umstieg auf Cloud oder sogar SaaS immer eine Alternative, die sorgfältig geprüft werden sollte. Die Optionen reichen von der reinen Infrastruktur (nur Server, Server und Storage) über komplexere Lösungen (etwa eine Plattform mit lauffähiger Datenbank und Webservices) bis zum SaaS-Ansatz, der sozusagen die höchste Entwicklung der Cloud darstellt: Die gesamte Software wird funktionsfähig auf SaaS-Basis eingekauft.

Letzteres stellt eine Variante des Outsourcing dar und unterliegt den hier üblichen Erwägungen: Was gehört zum Kerngeschäft, wo liegen besondere Risiken, wo ist der Wettbewerbsvorteil höher zu bewerten als die Kosten etc. Mit Hilfe des oben aufgeführten Kriterienkatalogs lässt sich jede Option exakt prüfen.

Die Erfahrung zeigt, dass rund 90 Prozent der CIOs heute grundsätzlich über Cloud oder SaaS nachdenken. Doch an die Umsetzung haben sich bisher weniger als zehn Prozent herangewagt - meist aus Unsicherheit über die tatsächlichen Risiken, Vorteile und Wirkungen eines solchen Schrittes auf das Business. Das systematische, modellgestützte Application Lifecycle Management stellt auch diese Entscheidung auf eine solide Faktenbasis.

Jörg Hild ist Geschäftsführer der Compass Deutschland GmbH.