Die Business Story hinter einer IT-Investition verstehen

Business Story: Fehlt Geld für Innovationen?

Thomas Gregg
©Shutterstock/ Brues

Die Grenzen zwischen Produkten, Services und IT verschwimmen zunehmend. Egal, ob Industrie 4.0, IT in the Car oder Mobile Banking – der Anteil der IT in der Wertschöpfungskette von Unternehmen aller Branchen nimmt ständig zu. Und damit die Notwendigkeit, die zugrunde liegende Unternehmensarchitektur nicht nur als technologisches Randthema, sondern als strategischen Unternehmenswert zu verstehen. Um die Unternehmensarchitektur aber zielgerichtet entwickeln zu können, müssen viele Faktoren und Abhängigkeiten verstanden und interpretiert werden. Ein Ansatz hierfür ist der des integrierten IT-Portfoliomanagements.

Neben der Notwendigkeit, immer neue Anwendungen und Projekte zu liefern, um eben diese neuen Produkte und Märkte für das Unternehmen zu erschließen, stehen die IT-Abteilungen unter enormen Kostendruck von Seiten der Fachabteilungen. Es ist zu beobachten, dass in vielen Unternehmen weiterhin versucht wird, die IT-Budgets von Jahr zu Jahr zu senken oder dass sich diese im idealen Fall auf der gleichen Stufe zum Vorjahr bewegen. Laut der Studie „Maximizing the Value of Information Technology“ der CFO Research gibt fast die Hälfte der Unternehmen 70 Prozent für „Keep it running“ (OPEX) aus – bei 15 Prozent der Unternehmen sind es sogar 90 Prozent.

Wenn nun Kosten reduziert werden müssen, geschieht dies meist zu Lasten der Innovationskosten (CAPEX), was zur Folge hat, dass zukünftige und notwendige Investitionen in neue Produkte und Märkte, welche das Geschäft voranbringen sollen, reduziert oder aber ganz gestrichen werden müssen. Dies führt nicht nur zu Frust innerhalb der IT, sondern auch ganz besonders bei den Fachabteilungen, welche in ihren Visionen und Wachstumsplänen gehindert werden. Um dieser Problematik zu entgehen, bleibt nur ein Ausweg. Die IT-Organisation muss parallel zu den Innovationsprojekten Programme und Initiativen starten, die die operativen Kosten drastisch senken können, um so mehr Budget für Innovationen freizumachen. Solch ein Shift von Budgets ist zwar naheliegend, aber keine einfach zu bewerkstelligende Aufgabe.

Abbildung 1 erklärt das Kostendilemma der CIOs. Nach einer Budgetkürzung, die in mehr als der Hälfte der Fälle das Innovationsbudget trifft, bleiben von anfänglich 30 Prozent (früher) nur noch 18 Prozent (heute) übrig. Um in Zukunft wieder auf einen höheren Innovationsanteil bei gleichbleibendem Budget zu kommen, müssen die operativen Kosten reduziert werden. Hierfür benötigt man eine nachhaltige IT-Planung.

Abb. 1: Die große Herausforderung bei der IT-Planung

Um dieser Umverteilung der Budgets gerecht zu werden, ist es elementar, bei der Entscheidungsfindung und der Priorisierung von neuen Projekten komplette Transparenz über das bestehende IT-Portfolio zu haben. Es ist notwendig, proaktiv erkennen zu können, welches die Kostentreiber in der IT-Landschaft sind, welche Anwendungen oder Technologien abgeschaltet werden sollen oder in welche mittel- und langfristig investiert werden muss. Der Impact der bestehenden und geplanten IT-Architektur muss bei der Entscheidungsfindung für ein neues Vorhaben bekannt sein. Darüber hinaus muss gewährleistet sein, dass weiterhin ersichtlich bleibt, wieso ein Projekt wichtig ist. Es muss klar zu erkennen sein, welches strategische Ziel es unterstützt und wie es das Geschäft nachhaltig verbessert. Kurz gesagt: Die Business Story hinter jeder IT-Investition muss klar verständlich und transparent sein.

Aufmacherbild: Businessman holding golden money symbol von Shutterstock / Urheberrecht: Brues

[ header = Seite 2: Klassische IT-Planung ]

Klassische IT-Planung nutzt das Potenzial des EAM nicht

Damit solch eine Transparenz über die verschiedenen IT-Portfolios hinweg funktioniert, ist es wichtig, den bestehenden IT-Planungsprozess im Unternehmen zu verstehen und gegebenenfalls zu optimieren.

Die meisten IT-Organisationen sind bereits sehr gut aufgestellt, wenn es darum geht, Anforderungen der Fachabteilungen aufzunehmen und diese genauer zu spezifizieren, um entsprechende Lösungen vorzuschlagen. Hierfür werden meist Rollen wie Businessanalysten oder Key Account Manager innerhalb der IT-Abteilung oder aber der Fachabteilungen etabliert. Diese fungieren dann als das Bindeglied zwischen den beiden Welten, kennen die Prozesse der jeweiligen Fachabteilungen, deren Geschäft und auch die unterstützende IT im Detail. Sehr häufig ist es dann aber der Erfahrung des Businessanalysten und dem Kenntnisstand der Gesamtorganisation überlassen, herauszufinden, welche bereits existierenden Anwendungen anderweitig im Unternehmen eingesetzt werden oder geplant sind, um eine entsprechende Anforderung umsetzen zu können. Bei global agierenden Mischkonzernen, aber auch bei mittelständischen Unternehmen, die verteilt agieren, kann sich solch eine fachabteilungsübergreifende Transparenz ohne ein integriertes IT-Portfolio-Management sowie einen funktionierenden IT-Planungsprozess schwierig gestalten. In einer von der alfabet AG kürzlich durchgeführten Umfrage unter IT-Entscheidern gaben 70 Prozent der Befragten an, dass bei ihnen schon mindestens ein IT-Projekt gescheitert ist, weil Entscheidungen andernorts getroffen wurden, die zum Zeitpunkt der Planung nicht bekannt waren.

Das klassische Aufnehmen von Anforderungen in den Fachabteilungen und die Auswahl einer entsprechenden Lösung wird meist gefolgt von einem Programmportfoliomanagement-Prozess. In diesem werden die gesammelten Anforderungen häufig nach klassischen Portfolio-Management-Kriterien – basierend auf Business Cases, Strategiebeitrag, verfügbaren Ressourcen und Budgets – priorisiert. Sofern aus diesen Anforderungen dann genehmigte Projekte entstehen, werden häufig Enterprise-Architekten hinzugerufen, um die bestmögliche IT-Architektur für das umzusetzende Projekt zu berücksichtigen. Die Enterprise-Architekten unterstützen dabei die IT-Vorgaben – häufig auch Standards und Guidelines genannt – bei der Anwendung und der Analyse von Abhängigkeiten zu anderen Anwendungen. Genau an diesem Punkt stellt man dann häufig fest, dass die Komplexität eines Projekts meist viel größer ist, als noch bei der Genehmigung des Projekts vermutet wurde. Möglichweise sind die Anzahl der zu integrierenden Anwendungen auf einmal größer als angenommen, mehr Schnittstellen müssen abgelöst oder neu gebaut werden, und die zugrunde liegende Technologie entspricht nicht mehr den aktuellen Vorgaben. Oder aber ein anderes Projekt möchte die Anwendung, die das Projekt eigentlich ablösen soll, erweitern. Projektverzögerungen, höhere Kosten oder eine geringere Abdeckung der Anforderungen, um „in Time“ und im Budget zu bleiben, sind meist die Folge.

Auch wenn dies sicherlich nicht der idealste IT-Planungsprozess ist, spricht man hier aufgrund der starken Verbreitung in Unternehmen von der „klassischen“ IT-Planung. Ein Enterprise Architektur Management (EAM) ist in solchen Organisationen häufig etabliert, aber völlig losgelöst vom eigentlichen IT-Planungsprozess. Die Folge ist die isolierte Definition von Standards und Guidelines als auch eine sehr starke Einbindung in operative Projekte. Abbildung 2 verdeutlicht diesen Prozess schematisch mit dem niedrigsten Reifegrad.

Abb. 2: Reifegrad von IT-Planungsprozessen

[ header = Seite 3: Weiterentwicklung der klassischen IT-Planung durch EAM ]

Weiterentwicklung der klassischen IT-Planung durch Einbindung von EAM

Der im Reifegrad nächsthöhere und in der Praxis am praktikabelsten empfundene IT-Planungsprozess wird als „integrated“ IT-Planung bezeichnet. Der große Unterschied zum „klassischen“ IT-Planungsprozess ist hier, dass das EAM bereits als Teil des IT-Planungsprozesses verankert ist. Hiermit kann sichergestellt werden, dass vor der Verabschiedung von Projekten ein Architekturcheck für einen Teil dieser Projekte durchgeführt wird. Eine 360-Grad-Sicht über alle IT-Portfolios hinweg ist somit vorzeitig möglich. Planungsrisiken können minimiert und Synergieeffekte aus unterschiedlichen Portfolios können erkannt und gehoben werden. Ein solcher Planungsprozess mag auf den ersten Blick viele Fragen aufwerfen:

  • Wieso sollten ab sofort alle Projektvorhaben einen Architekturcheck durchlaufen?
  • Eine komplette Zielarchitektur ist zu diesem frühen Zeitpunkt noch nicht vorhanden, deshalb führen wir ja das Projekt durch, um diese zu erstellen, oder?
  • Sind dies nicht nur Mehraufwände und damit verbundene Mehrkosten?

Diese Fragen können aber leicht beantwortet und Bedenken entkräftet werden. Die Erfahrung zeigt, dass solch ein Set-up keinesfalls negative Auswirkungen auf die Entscheidungsgeschwindigkeit hat. Das Gegenteil ist sogar der Fall, wenn einige grundsätzliche Regeln beachtet werden:

  • Nicht jedes Projektvorhaben muss einen Architekturcheck durchlaufen. Dies kann zum Beispiel anhand des geschätzten Umfangs in Kosten oder Manntagen geschehen. Ist eine Anforderung mit zum Beispiel weniger als 100 000 Euro umzusetzen, kann der Prozess einen Architekturcheck lediglich als optional vorsehen. Für größere Investitionen ist dann zum Beispiel ein Architekturcheck zwingend.
  • Das Projektvorhaben muss keineswegs bereits vollständig definiert sein, um einen Architekturcheck durchzuführen. Gewisse Dinge wie betroffene Geschäftsprozesse, die davon unterstützen Anwendungen und möglichweise zu berücksichtigende Informationsflüsse können auch ohne eine detaillierte Zielarchitektur betrachtet werden. Mithilfe eines geeigneten IT-Portfolio-Management-Tools ist es relativ einfach, die Abhängigkeiten aufzuzeigen.
  • Die entsprechende Transparenz über die mögliche einfache oder auch notwendig komplexe Umsetzung der Anforderungen erlaubt eine bessere Abschätzung des Projektvorhabens. Dies bringt einen erheblichen Mehrwert und liefert genauere Zahlen für die Erstellung des Business Cases und die Ressourcenplanung.

Mit diesem zusätzlichen Wissen kann man dann in die Programmportfolioplanung gehen und hat die Möglichkeit, die Projekte nicht nur nach den klassischen PPM-Kriterien zu priorisieren, sondern auch die IT-Architektur und deren Abhängigkeiten mit zu berücksichtigen. Wo genau bringt dies einen Mehrwert? Ein klassisches – aber lang nicht das einzige – Beispiel hierfür ist die große Herausforderung, Projekte und deren Abfolge richtig zu planen. Wenn zum Beispiel das Projekt für die Einführung einer neuen CRM-Anwendung die Fertigstellung eines Technologieprojekts voraussetzt, auf dem die CRM-Anwendung aufbaut, so ist es wichtig, dies frühzeitig zu wissen. Nur dann kann es in der Gesamtplanung berücksichtigt werden. Durch das frühzeitige Aufspüren solcher Architekturabhängigkeiten können mögliche Verzögerungen beim späteren CRM-Rollout schon während der Planungsphase unterbunden werden. Detaillierte Architekturfragen, die dann in der operativen Umsetzung der Projekte aufkommen, werden dann weiterhin durch Enterprise-Architekten in diesen Phasen unterstützt. Diese haben den großen Vorteil, auf den vorab geleisteten Architekturuntersuchungen aufzubauen und müssen somit nicht bei null beginnen.

Eine Integration der unterschiedlichen IT-Portfolios (z. B. Anforderungen, Projekte, Prozesse, Architektur) wird aufgrund der enormen Abhängigkeiten und Komplexität der Projekte untereinander immer wichtiger.

Die dritte und höchste Reifegradstufe ist die „embedded“ IT-Planung. Bei diesem Ansatz wird die nahezu komplette Architekturplanung bereits in der Planungsphase geleistet. Dies trägt dazu bei, die Projektrisiken auf ein Minimum zu reduzieren, da bereits verschiedene Szenarien vorab berücksichtigt wurden. Da heute aber oft nicht nur die IT agil ist, sondern immer häufiger auch das Business, ist diese Art von Planung meist zu starr und langwierig. In solch einem Szenario kann es schwierig sein, sich in der geforderten Zeit auf neue Anforderungen und Änderungen einzustellen. Weiterhin ist die Gefahr sehr groß, bereits sehr viel Energie in ein Projektvorhaben investiert zu haben, welches dann im Programmportfoliomanagement abgelehnt wird.

Wegen erwähnten Vor- und Nachteilen der verschiedenen Ansätze entscheiden sich immer mehr Unternehmen für den „integrated“ Ansatz.

[ header = Seite 4: Die kollaborative IT-Planung ]

Die kollaborative IT-Planung

Um die Verzahnung der verschiedenen IT-Portfolios im Unternehmen auch umsetzbar und für jeden Beteiligten greifbar zu machen, ist es wichtig, diesen Ansatz als Teil der täglichen Arbeit jedes einzelnen zu implementieren. Keiner der Beteiligten soll mehr, sondern idealerweise weniger Aufwand in die Planung investieren müssen, um von den genannten Vorteilen profitieren zu können. Ein in der Praxis bewährtes Vorgehen, um dies zu implementieren, ist der so genannte „Demand-to-Budget“-Prozess, auf den hier noch genauer eingegangen wird.

Wie in Abbildung 3 zu erkennen, basiert dieser Ansatz auf einem kollaborativen Vorgehen. Bildlich gesprochen sitzen dabei die Akteure nicht Rücken an Rücken. Vielmehr sitzen sie sich gegenüber und teilen ihre Perspektiven für eine integrierte Gesamtsicht.

Abb. 3: Die kollaborative IT-Planung

Die Devise hierbei ist: „All do some“ und nicht „Some do all“. Jeder der beteiligten Stakeholder, sei es ein Businessanalyst, ein Enterprise-Architekt, das Investment Board oder der CIO arbeiten mit den gleichen und gemeinsam genutzten Portfolioinformationen. Jeder ist ausschließlich verantwortlich für die Informationen in seinem Portfolio und muss auch nur das verantworten, was er bisher auch schon verantwortete. Durch die Verknüpfung der Informationen in den verschiedenen Portfolios ergibt sich jedoch ein enormer Mehrwert für alle Beteiligten.

[ header = Seite 5: Beispiel: Einführung eines neuen CRM-Systems bei Luckys Lemonade ]

Beispiel: Einführung eines neuen CRM-Systems bei Luckys Lemonade

Im Folgenden soll das oben genannte Vorgehen zur Einführung einer neuen CRM-Anwendung am Beispiel des Demand-to-Budget-Prozesses (Abb. 4) für das Unternehmen „Luckys Lemonade“ exemplarisch durchgespielt werden.

Abb. 4: Der Demand-to-Budget-Prozess

Die neue Geschäftsstrategie beinhaltet unter anderem ein Ziel zur „Erhöhung der Kundenbindung“. Aus diesem Ziel wird nun eine strategische Anforderung abgeleitet, welche die Erweiterung der bestehenden CRM-Anwendungen um neue Funktionalitäten vorsieht. Da diese Anforderung eine 1:1-Zuordnung zu einem strategischen Geschäftsziel des Unternehmens darstellt, genießt diese höchste Priorität und hat den CIO als globalen Sponsor.

Neben dieser strategischen Anforderung sind die Businessanalysten in den verschiedenen Unternehmensteilen aktiv dabei, ebenfalls Anforderungen zu sammeln und zu priorisieren. All diese Anforderungen laufen nun bei „Luckys Lemonade“ im globalen Demand-Management zusammen. Bevor nun daraus Projektvorhaben abgeleitet werden, wird untersucht, ob es möglicherweise redundante Anforderungen aus bestimmten Teilen der Organisation gibt. Da die Businessanalysten ihre Anforderungen bereits mit den unterstützenden Geschäftsprozessen im IT-Portfoliomanagementsystem verknüpft haben, ist es ein Einfaches herauszufinden, dass es eine weitere Anforderung im Bereich der CRM-Systeme gibt. Nach Analyse der Anforderungen wird beschlossen, aus Kostengründen die Anforderungen zusammen in einem Projektvorhaben zu betrachten. So wird verhindert, dass die Anforderungen zur Folge haben, die CRM-Anwendungen mehrmals in kürzester Zeit zu ändern.

Im nächsten Schritt wird aufgrund des geschätzten Investitionsvorhabens von mehr als einer Million Euro ein Architekturcheck (EAM Scenario Planning) durchgeführt und die IST-Architektur des Projektvorhabens genauer analysiert. Da die betroffenen Geschäftsprozesse und die damit unterstützenden Anwendungen bereits im IT-Portfolio bekannt sind, kann die Analyse in kurzer Zeit abgeschlossen werden und bringt momentan vier im Einsatz befindliche CRM-Anwendungen mit unzähligen Informationsflüssen ans Licht. Aufgrund der Größe des Vorhabens möchte man nicht nur ein mögliches SOLL-Szenario betrachten, sondern mindestens zwei Szenarien, um diese miteinander vergleichen zu können. Es sollen der Architektur-Impact, der Business Case und die notwendigen Ressourcen für die Szenarien untersucht werden. Ein Team aus Solutionarchitekten arbeitet an folgenden zwei Szenarien:

  1. Ablösung der bisherigen CRM-Anwendungen und Einsatz einer neuen CRM-Anwendung
  2. Erweiterung der bisherigen Anwendungen um die gewünschte Funktionalität

Beide Szenarien werden in enger Anlehnung an die von der EAM Governance erstellten Standards und in Zusammenarbeit mit den Enterprise-Architekten erstellt. So wird sichergestellt, dass die von der EAM Governance definierten und strategischen Anwendungen für die Unterstützung der CRM-Prozesse berücksichtigt werden.

Beide Szenarien können nun miteinander verglichen werden. Aufgrund der besseren Investitionssicherheit in eine neue Technologie fällt die Entscheidung für Szenario eins, die Einführung einer neuen Anwendung und gegen das kostengünstigere und schneller zu implementierende Szenario zwei.

Dieses, wie auch alle weiteren Projektvorhaben, die den gleichen IT-Planungsprozess durchlaufen haben, gelangen ins zentrale Programmportfoliomanagement. Hier werden nun die Abhängigkeiten der unterschiedlichen Projektvorhaben analysiert. Basierend auf dem Strategiebeitrag jedes einzelnen Vorhabens – aber auch basierend auf den existierenden Budgets, Ressourcen und der betroffenen IT-Architektur – werden nun die Projektvorhaben anhand der Fakten und einem klar definierten IT-Planungsprozess priorisiert.

Das Ergebnis ist, das „Luckys Lemonade“ die optimale IT erhält, um das Ziel einer höheren Kundenbindung schnellstmöglich und ohne Fallstricke umzusetzen.

[ header = Seite 6: Fazit ]

Fazit

Der klassische Ansatz der IT-Planung, der die Enterprise-Architektur lediglich als nachgelagerte Kontrollinstanz nutzt, genügt in Zeiten zunehmender Digitalisierung von Unternehmen nicht mehr, um bei gegebenem Budget den Anteil der Investitionen im IT-Budget zu erhöhen.

In der Praxis hat sich der kollaborative Ansatz der integrierten IT-Planung als zielführend erwiesen, da so Sparpotenziale früh erkannt und Fehlentwicklungen rechtzeitig vermieden werden können.

Angesichts der Komplexität der zu verwaltenden IT-Landschaften und der Dynamik ihrer Entwicklung werden CIOs zukünftig integrierte Softwarelösungen einsetzen, die sie bei der Durchführung der notwendigen Management- und Planungsprozesse unterstützen. Ausgehend von einer konsistenten Datenbasis, welche die IT-, Business- sowie Finanzperspektive umfasst, kann damit ein kollaborativer Ansatz der Strategieplanung geschaffen werden – mit dem CIO in einer Hauptrolle.

Geschrieben von
Thomas Gregg
Thomas Gregg
Thomas Gregg verantwortet als Director Global Sales Programs den Bereich Vertriebsunterstützung bei der alfabet AG. Er ist langjähriger IT-Managementberater und überzeugt in seiner Rolle als Evangelist Fortune-500-Unternehmen über die Notwendigkeit eines integrierten IT-Portfoliomanagements. Als Sprecher auf nationalen und internationalen Konferenzen sowie als Blogger berichtet er regelmäßig zu den Themen Enterprise-Architekturmanagement, Business/IT-Alignment und Cloud Computing.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: