Geschäftliche Anforderungen an die IT unterscheiden sich nicht nur zwischen Branchen und Unternehmen auch innerhalb einer Organisation ändern sie sich im Laufe der Zeit immer wieder. Wo in den vergangenen Jahren die Kostenoptimierung im Mittelpunkt stand, etwa in der Fertigungsindustrie, liegt der Schwerpunkt heute immer häufiger auf der Zukunftssicherung.
Hier lesen Sie ...
wie die IT unterschiedliche, sich immer wieder ändernde Anforderungen aufnehmen kann;
welche Hindernisse bei einer strategischen Steuerung des Anwendungs-Portfolios zu überwinden sind;
wieso ein Leading-Practice-Rahmenwerk hilft, die bestehende Anwendungslandschaft und geplante Neuentwicklungen an den Unternehmenszielen auszurichten.
Zehn Kriterien, um Anwendungen zu bewerten
Strategische Bedeutung: Welche Rolle spielt die Anwendung in der Geschäftsstrategie? Welche Geschäftsfelder und Kunden unterstützt sie? Ist das Know-how im eigenen Haus vorhanden, oder muss es von außen hinzugeholt werden?
Intention erwartete Nutzungsdauer, funktionale und technische Relevanz, angepeiltes Ergebnis: Was kostet die Weiterpflege, was der Ersatz durch eine andere Anwendung?
Funktionale Angemessenheit: Inwieweit unterstützt die Anwendung gegenwärtige und künftige Geschäftsprozesse? Wie viel manuellen Aufwand erfordert der Prozess zusätzlich? Ist die Applikation die einzige Quelle für die Daten, die der Prozess benötigt? Ist sie gut dokumentiert? Wie hoch ist der Trainingsbedarf? Welche Fehlerarten treten auf? Wie einfach lässt sich die Anwendung an qualitative Änderungen der geschäftlichen Anforderungen anpassen?
Technische Angemessenheit: Wie entwicklungsfähig ist die Applikation aus Sicht der IT bezüglich Plattformen, Sprache, Dateistruktur, Nutzeroberflächen, Kapazität? Wie schneidet sie hinsichtlich Skalierbarkeit, Aktualität, Designqualität und Zuverlässigkeit ab? Wie leicht lässt sie sich an quantitative Veränderungen (organisches Wachstum, Migration, Übernahmen) anpassen? Wie häufig kommen Fehler vor, und wie viel Aufwand erfordert deren Behebung? Wie gut ist die technische Dokumentation?
Applikations-Skills: Welche technischen Fertigkeiten verlangt die Anwendung? Inwieweit sind sie im Unternehmen vorhanden? Könnten neu eingestellte Entwickler sofort an der Applikation arbeiten, oder müssten sie sich zunächst tieferes Wissen darüber aneignen? Wie gut und zu welchen Preisen sind die Skills am Markt verfügbar?
Externe Unterstützung: Wie hoch sind die IT-Kapazitäten externer Organisationen, die in das Projekt eingebunden werden? Wie viele externe Mitarbeiter werden für Nutzersupport, Wartung, technische Erweiterungen und Entwicklung eingesetzt? Welche Kompetenzen und Erfahrungen hat das Team? Welche Entwicklungswerkzeuge werden verwendet?
Geschäftskritische Bedeutung: Inwieweit hängt das Geschäft von der Anwendung ab? Wie viele Nutzer benötigt sie täglich? Wie wichtig ist der Geschäftsprozess, den sie unterstützt? Welche Auswirkungen hätte der Ausfall des Systems?
Stabilität: Wie viele und welche Änderungen erfordert die Anwendung und wie oft erfordert sie sie? Schaffen die Änderungen einen geschäftlichen Mehrwert? Sind sie verbunden mit Umsatzwachstum, besserem Service, Kostensenkung oder Erfüllung von Compliance-Anforderungen? Inwieweit sind sie zeit- und geschäftskritisch?
Komplexität: Wie gut ist das System in die Gesamtumgebung und in verwandte Anwendungen integriert? Werden dafür standardisierte oder individuelle Schnittstellen verwendet? Lässt sich die Applikation leicht warten? Läuft sie nach Änderungen sofort fehlerfrei?
Einschätzung der Nutzer: Wie zufrieden sind die Nutzer generell mit der Anwendung? Wie zufrieden ist die IT damit?
Spartendenken und gewachsene Landschaften
Die strategischen Anforderungen des Unternehmens wandeln sich also ständig. Wie kann sich die IT da flexibel an ihnen ausrichten? Zwei Hindernisse stehen dem zunächst entgegen: das nach wie vor ausgeprägte Spartendenken und die daraus entsprungene Anwendungsarchitektur der Unternehmen.
Allmählich hat sich die Einsicht durchgesetzt, dass Spartenorientierung und ganzheitliche Unternehmensstrategie schlecht zusammenpassen. Vielfach existieren Gremien mit Vertretern aus Fachseite und IT, deren Aufgabe die Steuerung der IT-Investitionen ist. Aber wenn knappe Budgets in Lösungen umgesetzt werden sollen, regieren häufig doch wieder die Bereichsinteressen. Selbst wenn es gelingt, neue Projekte nach übergreifenden Aspekten zu priorisieren: Spätestens dann, wenn sich in ihrem Verlauf die geschäftlichen Anforderungen ändern und einzelne Anwendungen neu gewichtet werden müssen, setzen sich die berüchtigten "Entscheidungen nach Gutsherrenart" durch.
Eine gewisse Scheu vor dem konsequenten Aufräumen
In den meisten Fällen hat die IT die oft widersprüchlichen Vorgaben der verschiedenen Geschäftsbereiche eins zu eins in Anwendungen umgesetzt. Das Ergebnis sind Redundanzen, Doppelimplementierungen und funktionale Lücken, ein Mix aus Plattformen, Schnittstellen und Entwicklungswerkzeugen.
Viele CIOs zementieren diesen Zustand auch noch. Zwar beklagen sie sich über ihre ungeordnete IT-Welt, doch scheuen sie sich, das Chaos konsequent und systematisch neu zu ordnen nach geschäftlichem Mehrwert und operativer Effizienz. Häufig ist es auch einfacher (und zunächst billiger), neue, durchgehende Prozesse zu unterstützen, indem Schnittstellen zwischen den bestehenden Einzelsystemen geschaffen werden. Ändert sich später irgendwo etwas, so müssen alle Interfaces erneut angepasst werden. Kosten und Komplexität nehmen also langfristig zu.
Ziel ist der maximale geschäftliche Mehrwert
Ein koordiniertes Anforderungs-Management kann hier Abhilfe schaffen. Mit seiner Hilfe lassen sich Investitionen in Anwendungen so steuern, dass sie den höchstmöglichen geschäftlichen Mehrwert bringen. Dazu ist es wichtig, in einem formalen und neutralen Prozess objektive Kriterien zu definieren. Dieser Prozess muss so gestaltet sein, dass er während der Projektdauer veränderte Anforderungen aufnehmen kann.
Dabei sollten die verschiedenen Anforderungsarten möglichst früh einbezogen werden. Dazu gehören zuerst die Wünsche der Fachseite, die nach sachlichen Kriterien zu priorisieren sind: Welchen Wertbeitrag leisten ein Produkt und der jeweilige Ge-schäftsprozess überhaupt für das Unternehmen?
Technikentscheidungen sind oft Hindernisse
Aber auch der IT-Betrieb sollte bereits in der Frühphase des Projekts seine Vorstellungen einbringen. Nur so wird transparent, welche betriebstechnischen Anforderungen und Folgekosten bestimmte Entscheidungen nach sich ziehen. Unter Umständen erhöht die Festlegung auf eine bestimmte Programmiersprache die Zahl der zu betreibenden Rechner, oder sie schafft einen ganz neuen Skill-Bedarf, der nur durch externe Mitarbeiter zu decken ist.
Werden solche Aspekte zu Beginn vernachlässigt, kann das den Betrieb unnötig komplex und damit teuer machen. Möglicherweise baut das Unternehmen damit auch massive Hindernisse für ein geplantes Outsourcing auf.
Das strategische Portfolio-Management
Nach streng objektiven Kriterien sollte auch das Applikations-Portfolio bewertet werden. Das gilt für neue wie bestehende Lösungen. Am Anfang steht die Bestandsaufnahme: Inwieweit passt die vorhandene Anwendungslandschaft zu den Wertschöpfungsprozessen?
Betrachtet werden sowohl die Produkte als auch die zugehörigen Geschäftsabläufe. Beispielsweise besteht im Bankbereich das Produkt Baukredit aus Einzelprozessen wie Vertrieb und Beratung, Antragsbearbeitung, Voting. Diesen Geschäftsabläufen werden in einer Matrix alle Anwendungen zugeordnet, die sie unterstützen (siehe Grafik "Wenn sich Anwendungen überschneiden"). Das verdeutlicht auf einen Blick, wo sich die Anwendungen überlappen. Oft haben unterschiedliche Applikationen identische Funktionen kommt es doch immer wieder vor, dass jede Tochtergesellschaft eine eigene Lösung für ähnliche Aufgaben nutzt! An dieser Stelle können gezielte Konsolidierungsmaßnahmen ansetzen.
Bewerten und vergleichen - anhand von Referenzwerten
Die Bewertung der Anwendung orientiert sich zum einen daran, wie gut diese einen Geschäftsprozess unterstützt, zum anderen daran, welchen Wertbeitrag der Ablauf für das Unternehmen leistet. Prinzipiell wird jeder Prozess auf den Prüfstand gestellt.
Im nächsten Schritt lässt sich untersuchen, was der Betrieb und die Wartung bestimmter Prozesse und Applikationen kosten. Werden die begrenzten Mittel sinnvoll eingesetzt?
Dazu das Beispiel einer Versicherung: Dort werden die Kosten pro Police heruntergebrochen auf die dahinterstehenden Geschäftsprozesse und IT-Kosten: für Neugeschäft, Call-Center, Schadenregulierung, Zahlungen, Kundenkorrespondenz etc. Diese Positionen lassen sich dann mit Referenzwerten am Markt vergleichen.
Auf diese Weise wird vielleicht offenbar, dass das eigene Call-Center eine relativ schlechte geschäftliche Leistung erbringt, also pro Police viele Kontakte benötigt. Die Ursachen dafür können wiederum in Terminierungsproblemen oder langsamer Korrespondenz (aufgrund mangelhafter Automatisierung) liegen. Sie sind vielleicht schuld daran, dass zu viele Kunden zu häufig zum Telefon greifen.
Möglicherweise stellen die Verantwortlichen auch fest, dass das Unternehmen pro Police fast doppelt so viele Anwendungen einsetzt wie die Referenzgruppe, was einen überhöhten Wartungsaufwand nach sich zieht. Wichtig ist es allerdings, die Kosten des Geschäftsprozesses und der IT gemeinsam zu betrachten. Denn der IT-Aufwand kann auch deshalb höher ausfallen, weil auf der Business-Seite dank der Automation durch die IT Geld gespart wurde.
Lücken im Portfoliowerden offensichtlich
Die Matrix mit Produkten, Prozessen und Anwendungen zeigt bisweilen auch Lücken auf. Dort ist aus Business-Sicht zu investieren. Geplante Neuentwicklungen sollten nach demselben Raster bewertet werden wie vorhandene Anwendungen und Prozesse. Die Fragen lauten auch hier: Welchen Beitrag zur Wertschöpfung leistet der Prozess selbst? Und wie effizient sind die unterstützenden Anwendungen?
Die IT-Verantwortlichen können dann entscheiden, welche Anwendungen fortgeführt, migriert, neu entwickelt oder ganz abgeschaltet werden und welcher der jeweils günstigste Zeitpunkt dafür ist.
Die Maßgabe sollte sein, jede fachliche Anforderung durch maximal ein Softwaremodul zu unterstützen sowie die Modullandschaft möglichst einfach und homogen zu gestalten. Langfristig könnten diese Ziele in eine Service-orientierte Architektur (SOA) münden.
Ein Leading-Practice-Rahmenwerk
Wie lassen sich nun die Prozesse und Anwendungen nach objektiven Maßstäben beurteilen? Es bietet sich an, einen formalen Prüfprozess auf der Basis eines Rahmenwerks zu installieren. Dabei sollte ein Kriterienkomplex primär die strategischen und fachlichen Anforderungen spiegeln, also die strategische Bedeutung und Intention der Applikation, ihre funktionale Angemessenheit, geschäftskritische Relevanz und Zufriedenheit der Nutzer. Die Anforderungen des IT-Betriebs finden sich ergänzend in einem eher technisch ausgerichteten Kriterienbündel wieder. Es umfasst technische Angemessenheit, benötigte Skills, externe Unterstützung, Stabilität und Komplexität (siehe Kasten "Zehn Kriterien, um Anwendungen zu bewerten").
Jedes Kriterium erhält eine bestimmte Anzahl von Punkten, die sich nach seiner Bedeutung richtet. Diese wiederum hängt von den Unternehmenszielen ab, seien sie nun Kostensenkung oder Expansion, Konsolidierung oder schnellere Marktreife.
Die Einzelbewertungen werden dann verdichtet unter den beiden übergreifenden Aspekten geschäftliche Bedeutung und technische Eignung. Mit Hilfe dieser Einordnung können Unternehmen ihr individuelles Modell zum Management des Applikations-Lebenszyklus aufbauen (siehe Grafik "Bewertungsraster für Investitionsentscheidungen").
So lässt sich in jedem Einzelfall entscheiden, was mit einer Anwendung geschehen soll: abschalten, ändern, funktional erweitern, repositionieren etwa wenn sie strategisch wichtig, aber technisch veraltet ist oder weiterbetreiben.
Ändern sich die Anforderungen, so wird auch die Zahl der Punkte für die einzelnen Aspekte modifiziert. Damit verschiebt sich die Anwendung (oder ein Modul) im Raster. Auf diese Weise lassen sich die Prioritäten in Entwicklungsprojekten flexibel anpassen nach objektiven, neutralen Kriterien. (qua)