How does IT matter?

Projekte ableiten

Jetzt liegt der Ball bei uns. Die operativen Geschäfts- und IT-Bereiche schlagen Projekte vor, von denen sie annehmen, dass sie zur Umsetzung der Unternehmensstrategie beitragen können. Dabei ist für die Entscheider vor allem die Auswirkung auf die Bottom Line des Unternehmens interessant: Was bringt mir das vorgeschlagene Projekt unter dem Strich aller Ausgaben und Einnahmen? Falls ich ein neues Produkt vorschlage, ist das ziemlich direkt möglich und die Vorhersage des Effekts auf die Bilanz des Unternehmens keine Raketenphysik: 5000 verkaufte Einheiten pro Produkt bei 0.5 Credits Gewinn pro Einheit = 2500 Credits Gewinn in der Bilanz. Fertig.

Im Regelfall haben wir in der IT jedoch mit ganz anderen Arten von Projekten zu tun. Ich würde tippen, dass auch Sie sich in 95 % der Zeit mit so genannten Infrastrukturprojekten befassen, für die es nahezu unmöglich ist, einen solchen Gewinn seriös anzugeben. Und das, obwohl man intuitiv genau weiß, dass sie unbedingt notwendig sind. Woran liegt dieses scheinbare Paradox? John Thorpe bringt es auf den Punkt: „In reality, value does not come from technology projects. Technology only provides a capability. Value is only realized when this capability is applied and managed as part of a program of business change, including changes to business strategy, business processes, how people work, organizational structure, and technology“ [3].

Neben den Technologieprojekten sind immer zusätzliche Schritte notwendig, damit der Nutzen (Value) sichtbar wird. Die Folge davon, dass wir in der Vergangenheit Projekte überwiegend ohne Beachtung dieses Prinzips geplant, bewertet und kommuniziert haben, ist die, dass wir als reiner Kostentreiber dastehen, da der erhoffte Nutzen kaum nachweisbar war. Uns werden zwar gelegentliche Zufallstreffer attestiert, letztendlich spricht man uns jedoch kaum eine strategische Bedeutung zu. Um in Zukunft den Wert unserer Arbeit deutlich beziffern zu können, dürfen wir IT-Projekte nicht mehr alleine für sich betrachten, sondern müssen immer den relevanten Gesamtkontext mit einbeziehen. So entsteht das Bild ganzer Ketten von Projekten (IT und Nicht-IT), die solange aufeinander aufbauen und sich gegenseitig stützen, bis das Endziel – mehr Gewinn – erreicht ist. Im Terminus des Managements heißt ein solches Bündel von Projekten „Programm“. Die Koordination sowie die Visualisierung und Bewertung der Abhängigkeiten ist Aufgabe des Programmmanagements.

Programme planen und visualisieren

Wie findet man die Programme, die die dokumentierten strategischen (Zwischen-)Ziele wie neue Geschäftsfelder durch Innovation oder operative Exzellenz umsetzen?

Result Chains

Mit Result Chains [3] lassen sich Programme und deren Auswirkungen auf strategische Ziele visualisieren. Projekte, deren Ergebnisse sowie Annahmen und Risiken werden erfasst und so lange aneinandergereiht, bis eines der strategischen (Zwischen-)Ziele erreicht ist. Gelingt die Verknüpfung eines Programms mit einer der Topstrategien nicht, fehlt noch ein Programmbaustein. Oder passt eventuell das Vorhaben schlicht nicht in die vorgegebene Strategie? Result Chains helfen uns dabei, operative Projekte in ihrem strategischen Kontext bewert- und managebar zu machen, fehlende Projekte und Initiativen zu entdecken sowie Risiken zu erkennen und (z. B. durch Szenarioplanung) zu beherrschen. Und damit nicht zuletzt beim Aufpolieren unseres Images als IT durch die nachvollziehbare Darstellung unseres Beitrags zur strategischen Komponente des Unternehmenserfolgs verhelfen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.