So werden IT-Abteilungen agiler

Mit Service-Portfolio-Management gegen Schatten-IT

20.04.2016
Von Ulrich  Conzelmann
Die Anforderungen an die IT sind in Zeiten von Cloud und Digitalisierung besonders hoch: Agilität, Sicherheit und Wirtschaftlichkeit sind gefragt. Doch vor allem in puncto Agilität können viele IT- Organisationen nicht Schritt halten. Die Konsequenz ist, dass die Fachbereiche sich unkoordiniert aus der Cloud bedienen. Hier hilft nur eines: Service-Portfolio-Management.

Der Grund für die mangelnde Agilität ist oft, dass Entscheidungen zu Portfolioinhalten nicht wirksam getroffen werden. Das Problem existiert in unterschiedlichen Ausprägungen: Eine Variante ist, dass neue Ideen vom CIO mit dem Hinweis auf fehlende Ressourcen abgelehnt werden. Oder der IT-Chef begrüßt neue Ideen und sagt eine Implementierung zu, kann aber dann aufgrund von fehlenden Ressourcen nicht liefern. Eine weitere Spielart: Es wird so lange diskutiert, bis die Idee zerredet ist und niemand mehr dafür brennt.

In einem agilen Ansatz wird zunächst festgestellt, welche Ressourcen einen Engpass bedeuten. Das lässt sich gut auf einem Kanban-Board darstellen.
In einem agilen Ansatz wird zunächst festgestellt, welche Ressourcen einen Engpass bedeuten. Das lässt sich gut auf einem Kanban-Board darstellen.
Foto: Rawpixel/Shutterstock.com

Der Weg zu wirksamen Portfolioentscheidungen beginnt damit, die Bedarfe der Anwender zu identifizieren. In der Praxis scheitert das oft an der schlechten Kommunikation zwischen Business und IT. Ein gutes Instrument ist hier eine Kommunikationsplattform, auf der Ideen und Bedarfe offen und transparent beschrieben, diskutiert und bewertet werden können. Wichtig ist es, die Kommunikation breit aufzusetzen und alle wichtigen Stakeholder einzubeziehen.

Wirtschaftliche und strategische Kriterien

Die Bewertung von Ideen und Anforderungen sollte nach wirtschaftlichen und nach strategischen Kriterien erfolgen. Eine solche Plattform ist auch die richtige Grundlage für die Messung der Time-to-market, für die Zeit also, die für die Bereitstellung neuer Services benötigt wird. Man kann damit leicht feststellen, wann ein Bedarf von der Fachseite angemeldet worden ist.

Im nächsten Schritt auf dem Weg zur Entscheidung gilt es, Budget- und Ressourcenverfügbarkeit zu prüfen. Für die Services, die von den Fachseiten am höchsten priorisiert wurden, müssen initiale Business-Cases erstellt werden, um Budgetverfügbarkeit und Wirtschaftlichkeit zu prüfen. Hier sollte anfänglich keine zu hohe Genauigkeit angestrebt werden. Da der Nutzen eines Services sich in der Regel nur grob quantifizieren lässt, müssen die Kosten nicht exakt bekannt sein.

Möglichen Kostenabweichungen begegnet man durch übergreifende Puffer, die eine dynamische und agile Reaktion auf Unvorhergesehenes ermöglichen. Hohe Ansprüche an die Genauigkeit beim initialen Business Case gehen immer zu Lasten der Agilität. Neben dem Budget muss auch ausreichend Personal verfügbar sein. Um diese beurteilen zu können ist ein Projekt-Portfoliomanagement erforderlich, das Auskunft darüber gibt, welche Ressourcen wie verplant sind.

Es gibt solche Planungssysteme in der klassischen Ausprägung, in der einzelner Projektpläne zu einem großen übergreifenden Plan zusammengestellt werden. Der Nutzen solcher Systeme ist eher begrenzt, da es zu oft zu Terminverschiebungen kommt. Dann sind wichtige Personen oft nicht mehr wie geplant verfügbar. Außerdem harmoniert dieser Ansatz nicht mit agilen Entwicklungsmethoden wie zum Beispiel Scrum, weil keine Detailpläne vorgesehen sind, die die Basis für eine integrierte Gesamtplanung sein könnten.

Agiler Ansatz mit Fokus auf Engpässe

In der Praxis bewährt sich ein agiler Ansatz, der sich gemäß der 'Theory of Constraints' auf den Engpass konzentriert: Man stellt zunächst fest, welche Ressourcen einen Engpass darstellen. Es werden dann nur so viele Projekte pro Periode geplant, wie von den Engpass-Ressourcen in diesem Zeitraum verarbeitet werden können. Welche Ressourcen einen Engpass darstellen, kann man gut mit Kanban untersuchen: Auf einem Kanban-Board, das die Portfolioelement in den jeweiligen Phasen visualisiert, sieht man schnell, wo es zu einem Rückstau kommt. Im Sinne der Agilität sollte die Planungsperiode nicht zu groß sein.

Wenn für die Projektumsetzung nicht genügend personelle Ressourcen verfügbar sind, besteht natürlich auch die Möglichkeit externe Ressourcen hinzuzuziehen. Eine Make-or-buy-Entscheidung muss zu jedem neuen Service getroffen werden, außerdem ist festzulegen, welche Leistungen intern erbracht und welche fremdvergeben werden sollen. Diese Entscheidung sollte vor dem Hintergrund einer generellen strategischen Positionierung der Serviceorganisation erfolgen, die besagt, welche Leistungen Kernkompetenz einer Organisation sind. Es ist zu beachten, dass nicht beliebig viele externe Ressourcen beauftragt werden können, da die Steuerungskapazität einer Organisation immer ein limitierender Faktor bleibt.

Um agiler zu werden, ist es wichtig, dynamisch auf Veränderungen der Rahmenbedingungen und Abweichungen vom ursprünglichen Business Case zu reagieren und Mittel gegebenenfalls umzuverteilen. Viel zu oft werden einmal getroffene Entscheidungen nicht revidiert, auch wenn absehbar ist, dass Maßnahmen nicht den erhofften Effekt haben werden oder sich inzwischen lukrativere Chancen ergeben haben.

Service- versus Projekt-Portfolio-Management

Könnte ein Immobilienunternehmen, das sich nur auf den Neubau und auf Neuerwerbungen konzentriert, erfolgreich sein, wenn es nicht gleichzeitig die Rentabilität der Bestandsobjekte im Blick hätte? Wohl kaum! Erstaunlicherweise agieren aber sehr viele IT-Organisationen so: Im Projekt-Portfoliomanagement wird nur die Service-Entwicklung betrachtet, die Nutzungsphase, also der Servicebetrieb, bleibt außen vor. Eine Konsequenz ist, dass nicht geprüft wird, ob sich der Nutzen, der mit einer Investition verbunden wurde, tatsächlich einstellt. Auch wenn die Betriebskosten wesentlich höher sein sollten als ursprünglich angenommen, wird dies vom Portfoliomanagement nicht vermerkt. Korrekturbedarfe werden somit nicht erkannt. Und es wird auch nicht systematisch untersucht, ob ein Service sich dem Ende seines Lebenszyklus' nähert und zurückgebaut werden sollte.