In agilen IT-Organisationen ist die Schnittstelle zum Business wichtig

Weil Agilität keinen Selbstzweck verfolgt, sondern einer anpassungsfähigeren und stärker kundenfokussierten Ausrichtung dient, bedarf es auch eines engeren Zusammenspiels zwischen der IT-Organisation und dem Business. In den agilen Entwicklungsorganisationen hat sich hier in den letzten Jahren bereits die Rolle des „Product Owner“ als die zentrale Instanz etabliert, die die Kundenanforderungen an der Schnittstelle zum Business aufnimmt, evaluiert und im Backlog des Entwicklungsteams priorisiert.

Doch welche Anpassungsnotwendigkeit besteht für die Rolle eines klassischen IT-Service-Owners, wie er heute in vielen IT-Organisationen etabliert ist? Wie wird ein IT-Service zukünftig gesteuert, der eine Vielzahl von Produkten anhand seiner Lieferkette umfassen kann? Und wie verhält es sich mit IT-Services, die eher unterstützender Natur sind und traditionell vielfach auch aus den Bereichen der IT-Infrastruktur-Teams heraus erbracht werden, wie etwa den „Communication & Collaboration Services“?

Der Blick in agile Organisationsmodelle kann helfen, die notwendigen Anpassungen an der klassischen Rolle des IT-Service-Owners zu erkennen, von denen hier exemplarisch einige genannt werden:

1. Der Service Owner sollte grundsätzlich im engen Kontakt mit seinen internen/externen Kunden stehen, gerade bei den unterstützenden IT-Services ist das heute nicht immer gegeben. Somit sind neue Kanäle und Formate zum Austausch mit den Kunden zu finden, die sicherstellen, dass der jeweils aktuelle und reale Bedarf sowie die Erwartungshaltung der Nutzergruppen eindeutig durch den Service Owner verstanden werden.
2. Die Nutzung eines „Service Backlogs“ kann dabei helfen, sämtliche Anforderungen transparent zu konsolidieren und den jeweiligen Business-Nutzen iterativ herauszuarbeiten. Hierbei ist darauf zu achten, dass die Anforderungen einerseits anhand des Kundennutzens zu bewerten sind. Gleichzeitig sind aber auch die technologische Weiterentwicklung sowie die konstante Bearbeitung der „technischen Schuld“ des Services sicherzustellen.
3. Die Umsetzung der Anforderungen, die möglicherweise auch infrastrukturelle Maßnahmen oder Abstimmungen mit externen Service-Providern nach sich ziehen, kann beispielsweise über die Scrum-Methodik erfolgen. Dabei sind die Sprint-Zyklen ggf. länger anzusetzen als in den klassischen Software-Entwicklungsprojekten. Erstreckt sich der Service entlang seiner Lieferkette über mehrere Produkte oder unterstützende Services, sind geeignete Verfahren zu etablieren, um das Service Backlog mit den individuellen Product Backlogs in Einklang zu bringen. Schlussendlich müssen Lieferungen bzw. Veränderungen in der Produktivumgebung miteinander synchronisiert werden.
4. Über regelmäßige Reviews und Retrospektiven, gemeinsam mit Nutzervertretern sowie Vertretern der internen ggf. zuliefernden Einheiten, kann sichergestellt werden, dass die umgesetzten Maßnahmen auch wirklich zum Geschäftserfolg beitragen. Auch wird hier schnell erkannt, an welcher Stelle noch Bedarf zur Nachbesserung bzw. Erweiterung besteht und ob die Abstimmungsprozesse zwischen allen beteiligten Einheiten zielführend und ausreichend etabliert sind.
    

Um ausreichend handlungsfähig zu sein, benötigt der Service Owner zwangsläufig auch die notwendigen Befugnisse. Vorteilhaft ist, wenn ihm hierfür ein Service-Team entlang der Lieferkette zur Verfügung steht, welches idealerweise auch die verschiedenen benötigten Fähigkeiten und Fachlichkeiten in sich vereint. Die Verfügbarkeit dieser Ressourcen minimiert Abstimmungsaufwände und ermöglicht erst eine unterbrechungsfreie Ende-zu-Ende-Umsetzung notwendiger Maßnahmen, und der Service Owner kann bei Engpässen gezielt in die Abläufe eingreifen.

„Als einen wesentlichen Erfolgsfaktor erkennen wir die Notwendigkeit, Zuständigkeiten aus der Linie an die Rolle des Service Owners zu übergeben, was möglicherweise nicht gänzlich ohne Widerstände erfolgen wird“, betont Christian Rauch, Principal Consultant bei der ITSM Group.

Ein weiterer wichtiger Aspekt betrifft die Art und Weise, wie die Service Level Agreements (SLA) der Zukunft zu gestalten sind. „Es ist absehbar, dass diese einen Service Owner dazu in die Lage versetzen müssen, mit dem Kunden wesentlich gezielter die Ressourcen priorisieren zu können“, erläutert Herr Rauch. Dies etwa bei der Frage, ob bevorzugt eine neue Kunden-Anforderung, die Beseitigung einer Störung oder eine vorausschauende Stabilisierungsmaßnahme realisiert werden soll. „Eine Betrachtung traditioneller SLA-Strukturen in Hinblick auf deren Unterstützung bzw. Ermöglichung einer agileren Arbeitsweise inkl. situativer Priorisierung und einem neuen Set von Performance-Kriterien erscheint dringend angeraten“, schließt Rauch von der ITSM Consulting.