Nach 6 Jahren ITIL4 kommt jetzt, d.h. noch im Februar die neue ITIL-Version. Dies wollen wir zum Anlass nehmen, eine erste Einschätzung der neuen Version vorzunehmen. Erfreulich ist aus unserer Sicht, dass ITIL 5 nicht wie einige vorherige Versionen einen Bruch darstellt, sondern eine schlüssige Weiterentwicklung der Version 4 ist – Evolution statt Revolution. Bewährtes bleibt erhalten, während das neue Framework gleichzeitig wichtige neue Entwicklungen am Markt aufgreift und integriert. Dies betrifft insbesondere die Themen KI, automatisierte Betriebsformen und Experience-Orientierung.

ITIL 5 ist da – was ist neu?

• Digital Product & Service Management statt reinem Service Management – ITIL 5 erweitert den bisherigen Service-lastigen Fokus, indem es digitale Produkte und Services stärker gemeinsam in einem Modell abbildet. So können Produkt‑ und Service-Teams besser kooperieren.
• Erweitertes, einheitliches Lifecycle‑Modell – in der Service-Value-Chain wird der in der Version 4 etwas fragmentierte Lifecycle in 8 Schritte aufgeteilt. Dies sind: Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support. Hierdurch wird das Modell klarer, einfacher und flexibler.
• ITIL 5 ist „KI-native“ – Künstliche Intelligenz ist nicht nur Add‑on, sondern wird vollständig in das Framework integriert, d.h. die Prinzipien für Automatisierung und KI-Nutzung sind durchgängig im Framework verankert. Neben der Darstellung der KI-Governance-Gestaltung sind KI-Aspekte unter anderem auch in allen Practice Guides enthalten.
• Stärkere Experience‑Orientierung – Nutzer‑ und Mitarbeitererlebnisse rücken stärker in den Mittelpunkt. Für jede Aktivität und jeden Service wird geprüft, welchen Beitrag er zur Wertgenerierung leistet. Und dies wird an den Erfahrungen von Nutzern und Mitarbeitern gemessen.

Was bleibt gleich?

• Guiding Principles, Four Dimensions, Service Value System aus der Version 4 bleiben das stabile Fundament.
• Alle 34 Practices der letzten ITIL-Version behalten ihre Gültigkeit.
• Bestehendes Wissen, Erfahrungen und Zertifizierungen behalten ihren Wert – es ist kein Neustart erforderlich.

Was bedeutet das für Unternehmen?

• Investitionsschutz: Bestehende Strukturen und Verfahren im Servicemanagement der eigenen Organisation können weiter genutzt werden. Mit den Erweiterungen in ITIL 5 können sie sukzessive weiterentwickelt werden.
• Mehr Alignment über die Organisation hinweg – ITIL wird mit seiner evolutionären Entwicklung noch stärker zum Enterprise‑Service‑Management‑Framework.
• Vorbereitung auf KI‑getriebene Digitalisierung: Die gute Integration von KI in dem Framework schafft einen soliden Rahmen, um intelligente Automatisierung im Service-Management zu etablieren und immer weiter auszubauen.

Unser erstes Fazit:

ITIL 5 schafft eine gute Grundlage für alle Organisationen, die sich im digitalen Produkt‑ und Servicezeitalter auf Basis der bisherigen eigenen Aufstellung weiterentwickeln wollen. So können sie weiterhin und ohne großen Bruch verlässlich, skalierbar und zukunftsfähig agieren.

Beim Outsourcing von IT-Services, insbesondere Commodity-Services wie RZ-Dienstleistungen oder Workplace, gibt es viel Erfahrung, daher ist es inzwischen weit verbreitet, Teile der IT an Service-Provider auszulagern. Bezüglich des Outsourcing von IT Security-Services allerdings haben viele Unternehmen aufgrund der hohen Risiken noch Bedenken. Doch ist diese Einstellung in Zeiten ständig neuer Bedrohungen sowie immer schneller zu aktualisierender Spezialexpertise noch zeitgemäß? Diese Fragen werden im Folgenden untersucht.

Outsourcing von IT Security-Services – Ausgangssituation

Nahezu jeder Bereich der IT lässt sich heutzutage outsourcen:
Angefangen beim Service Desk, über das Hosting von Rechenzentren, Webseiten, dem SAP-Betrieb, Datenbanken oder CRM-Systemen, für jeden IT-Service-Bereich gibt es etablierte Anbieter. Auch im Bereich der IT-Security gibt es inzwischen eine Vielzahl von Anbietern, die unter Anderem das Storage-Backup, Security Information und Event Management (SIEM) oder den Betrieb von Firewalls übernehmen. Doch gerade der Betrieb von Firewalls ist gesondert zu betrachten, stellen doch die Firewalls in der Regel den entscheidenden Schutz vor Angreifern aus dem Internet dar.

Überblick Firewall-Services

Eine Firewall analysiert den Datenverkehr und blockiert oder gewährt den Datenfluss auf Basis von Regeln, die erlaubten oder unerlaubten Traffic definieren. Next Generation Firewalls bieten zudem Funktionen wie Intrusion Detection (IDS) und Intrusion Prevention (IPS) an, um Angriffe auf das Unternehmensnetz zu erkennen und abzuwehren. Dadurch schützen sie einzelne Rechner, Server und Netzwerke vor Angriffen mit Malware, Trojanern oder unbefugten Zugriffen.

Je nach Unternehmensgröße kann die Verwaltung und Überwachung von Firewalls durch sehr viele Regeln sowie ständig neuen Angriffsmöglichkeiten schnell sehr komplex und zeitaufwendig werden. Das jeweilige IT-Team muss in der Lage sein, mit der neuesten Software und Technologie stets Schritt zu halten. Nur so kann es in der heutigen digital vernetzten Welt das Unternehmen dauerhaft schützen. Die entsprechenden Spezialisten sind unter Umständen durch den Fachkräftemangel schwer zu bekommen, beziehungsweise zu halten. Hier kommt das Thema „Firewall-Administration durch einen Service-Provider“ ins Spiel: Der Service Provider kümmert sich um Betrieb, Wartung und Administration der jeweiligen Firewall-Lösung.

Vorteile einer vollständigen Ausgliederung

Grundsätzlich ist beim Outsourcing von IT Security-Services zu entscheiden, ob der gesamte Firewall-Betrieb oder nur Teile der Betriebsaufgaben abgegeben werden sollen. Je nach Unternehmen sind möglicherweise besonders sensible Bereiche vorhanden, die nicht an einen Provider outgesourct werden können (z.B. in der Medizin). Wird der gesamte Betrieb ausgegliedert, kann dies für Unternehmen eine Reihe von Vorteilen bringen:

• Kein Administrationsaufwand
  Der Provider übernimmt alle Services rund um die Administration der Firewall-Lösung. Dazu gehören beispielsweise Updates, Patch-Management, Best Practice-Konfiguration, Monitoring oder Support. Somit müssen keine eigenen Spezialisten mehr vorgehalten werden, die stetig ihr Know-how aktualisieren und ausbauen müssen.
• Einfache Skalierbarkeit
  Je nach Anforderung bezüglich Traffic oder Administration lassen sich die Firewall-Leistungen hinsichtlich der Provider-Ressourcen schnell nach oben oder unten skalieren.
• Flexibilisierung der IT-Investitionen
  Firmen können ihre IT-Investitionen flexibel gestalten. So erfolgt die Abrechnung entweder in einem nutzungsbasierten Mietmodell oder man beschafft die Hardware selbst und kauft nur die Betriebsleistungen ein.
• Hohe Sicherheit
  Hat sich ein Service-Provider auf IT-Security-Services spezialisiert und erbringt diese für mehrere Kunden, so ist er in der Regel professioneller aufgestellt, da er mehr spezialisiertes Personal hat und die Effizienz seines Betriebskonzepts stetig optimiert, um seine Marge zu steigern. Somit ist die Firewall-Lösung stets auf dem aktuellen Stand und kann zeitnah mit den neuesten Funktionen ausstattet werden.

Diese Vorteile können nur erzielt werden, wenn zwischen Unternehmen und Service-Provider die entsprechenden Verträge gut ausgearbeitet und abgestimmt sind: Im Service-Schein müssen die vom Provider zu übernehmenden Leistungen sowie ihre Qualität (über die Festlegung von SLAs) genau spezifiziert sein, die Schutzmechanismen sollten auf Basis der Ergebnisse eines ganzheitlich etablierten Risikomanagements gestaltet sein. Das interne IT-Security-Team muss im Rahmen des Outsourcings bei den entsprechenden Planungen, Abstimmungen und ggf. in Verhandlungen mit dem künftigen Service-Provider eingebunden werden, um ein gemeinsames Sicherheitsverständnis zu erreichen. Auch wenn die Service-Provider über ein enormes Sicherheits-Wissen verfügen, kann eine Anpassung an etwaige Unternehmensbesonderheiten durchaus erforderlich sein, anstatt sich rein auf allgemeine Security-Standards des Service-Providers zu verlassen.

Sonderfall Produktionsumgebungen

Alle genannten Punkte hinsichtlich des Firewall-Betriebs sind bei einigen Unternehmen in bestimmten Bereichen nicht so einfach anzuwenden. Insbesondere bei produzierenden Unternehmen ergeben sich in den Produktionsumgebungen häufig besondere Anforderungen wie zum Beispiel spezielle lHard- oder Software. Hier ist es oftmals notwendig, eine angepasste Firewall-Lösung zu betreiben, die meist besser auf die spezifischen Anforderungen ausgerichtet ist. In Produktionsumgebungen stehen oft sehr alte IT-Systeme, für die es keine Sicherheitsupdates mehr gibt, ebenso läuft spezielle und sehr alte Steuerungs- oder Mess-Software häufig nicht auf neuen Betriebssystemversionen. Daher sind diese Bereiche noch besser abzusichern, um nicht nur die Produktion nicht zu gefährden, sondern auch, um Firmengeheimnisse (z.B. Patente) zu schützen. Vorhandene Sicherheitskonzepte müssen geprüft und ggf. angepasst werden, da ein anderes Know-How bei der Konzeption und beim Betrieb solcher Firewalls nötig ist. Auch die Firewall-Anforderungen können sich von Standard-Lösungen hinsichtlich Verfügbarkeit und Konfigurationsmöglichkeiten unterscheiden.

Spezifikation der Leistungen

Damit sich auch Firewalls für solche Umgebungen von einem Service-Provider managen lassen, ist eine möglichst genaue Spezifikation in der Leistungsbeschreibung erforderlich, da sich viele Standard-Lösungen nicht 1:1 nutzen lassen. Der Service-Provider hat zwar das bessere Wissen, kennt aber etwa die Vor-Ort-Umgebung nicht. Nach einer Vergabe sollte die Provider-Expertise in einem entsprechenden Transition-Projekt genutzt werden, um die aktuelle Firewall-Konzeption und den Betrieb zu prüfen und gemeinsam mit dem Auftraggeber Verbesserungen umzusetzen. Dadurch lernen die Mitarbeiter:innen des Service-Providers die Systemumgebung kennen und können sich auf die Anforderungen einstellen.

Anpassungen an diese Firewalls müssen schnell und präzise umsetzbar sein, damit es nicht zu Verzögerungen bei der Implementierung oder Ausfällen kommt. Ein Ticketsystem mit angeschlossener Hotline und idealerweise einem Chat für Change-Requests ist entsprechend einzurichten, um besonders kurze Reaktions- oder Lösungszeiten, auch zu ungewöhnlichen Arbeitszeiten (etwa am Wochenende) zu ermöglichen. Auch müssen die Kommunikationswege klar geregelt sein, damit die Anpassungen schnell vorgenommen werden können. Die dafür ggf. notwendige Optimierung der Service-Request-Prozesse ist ebenfalls im Rahmen der Transition anzugehen, um die erforderlichen internen Zuarbeiten im Prozess, wie etwa Genehmigungen und Freigaben, zu verbessern.

Outsourcing von IT Security-Services – Fazit

Zusammenfassend lässt sich sagen, dass beim Outsourcing von IT Security-Services, insbesondere beim Thema Firewall, deutlich mehr Punkte zu beachten sind als bei anderen IT-Dienstleistungen. Gerade im Bereich der Produktion ist im Rahmen der Transitionsphase eine enge Zusammenarbeit zwischen Unternehmen und Service-Provider notwendig, um die entsprechenden Umgebungen effizient zu schützen. Zudem muss bei der Zusammenarbeit sichergestellt sein, dass es zu keinen Behinderungen im Betrieb, wie etwa Produktionsverzögerungen oder Ausfällen, kommt. Klare Kommunikationsstrukturen und Verantwortlichkeiten sind daher neben Einrichtungs- und Konfigurationsstandards unabdingbar.

Anfang Juli 2021 sorgte eine Supply-Chain-Attacke, der „REvil-Group“ weltweit für Aufsehen: Es gelang dieser Hackergruppe auf einen Schlag, mehr als 1000 Unternehmen erfolgreich anzugreifen und über den Einsatz von Ransom-Software enorme Lösegeldmengen zu fordern. Betrachtet man sich diesen Angriff etwas näher, dann wird klar, dass er die IT-Welt nachhaltig verändern wird. Doch was genau macht diesen Fall so besonders, und was sind die Auswirkungen, gerade wenn Unternehmen IT-Services outgesourct haben, im Bereich Providermanagement? Auf diese Fragen geht der folgende Blog-Artikel ein.

Cyberangriffe und die aktuelle Supply-Chain-Attacke

Bislang erfolgten Ransomware-Angriffe meist gezielt auf einzelne Unternehmen, bei denen Sicherheitslücken entdeckt wurden, oder bei denen ein möglicher Profit sehr hoch sein könnte. Oder aber es wurden Schwachstellen über Massenscans gesucht und anschließend ausgenutzt, wie etwa der sogenannte „Hafnium Exchange-Server-Hack“, den wir in unserem Blog-Artikel im April 2021 näher betrachtet haben. Die jetzt erfolgte Attacke über eine IT-Management Software des IT-Dienstleisters Kaseya hat allerdings eine ganz neue Qualität, denn sie erfolgte über ganz reguläre Prozesse, wie sie jede IT aufweist. Es handelt sich hier um eine sogenannte Supply-Chain-Attacke, bei der ein Unternehmen nicht direkt, sondern über einen Service Provider, welcher bestimmte IT-Dienstleistungen erbringt, angegriffen wird.

Funktionsweise und Angriffsverlauf

Die Anwendung Kaseya VSA ist eine Plattform für das Software-Management. Zu ihren Aufgaben gehört unter anderem die Installation von Software und Updates auf den jeweiligen Kundensystemen. Genutzt wird VSA von Service Providern, wie zum Beispiel IONOS, die damit die IT ihrer Kunden administrieren. Diese Service Provider setzen dazu wahlweise entweder eine eigene On-Premise-Installation der Kaseya-Lösung ein, oder sie nutzen ein von Kaseya gehostetes Cloud-Angebot als Software-as-a-Service. In dieser Management-Software gab es offenbar mehrere Lücken, die zumindest teilweise auch bereits im Rahmen einer sogenannten „Coordinated Disclosure“ bei Kaseya gemeldet wurden. Dabei wird der Hersteller rechtzeitig vor Veröffentlichung einer Sicherheitsschwachstelle vorgewarnt, um in angemessener Zeit entsprechende Gegenmaßnahmen zu ergreifen. Über den weiteren zeitlichen Ablauf ist bislang nichts genaueres bekannt.

Der aktuelle Angriff erfolgte dann am 2. Juli 2021, noch bevor die nötigen Patches vom Hersteller eingespielt waren (ein sogenannter Zero-Day-Exploit). Konkrete Informationen zu Details der Schwachstelle sind zwar noch nicht bekannt, allerdings ergaben öffentliche Analysen, dass es einen ungesicherten Endpunkt des VSA-Web-Interfaces gegeben hat. Über diesen konnte man aus dem Internet ohne Authentifizierung mit der Server-Software kommunizieren. Mittels einer sogenannten SQL-Injection schleusten die Angreifer dann Datenbank-Befehle ein und konnten damit schlussendlich den bzw. die Server kontrollieren, deren Aufgabe es war, ihre Clients mit neuer Software und Patches zu versorgen. Anschließend wurde durch die Angreifer das Ausrollen eines Pakets namens „Kaseya VSA Agent Hot-fix“ auf alle Client-Systeme ausgelöst. Dieses war im Prinzip eine getarnte alte Version des Windows Defenders, die den eigentlichen Ransomware-Trojaner der REvil-Gruppe beinhaltete. Da Kayesa für seine Management Software umfangreiche Ausnahmeregeln für AntiVirus-Sofware und Firewalls empfiehlt, hatten die entsprechenden Agenten auf den Client-Systemen leichtes Spiel, da diese mit sogenannten SYSTEM-Rechten laufen, und somit aus Sicht von Sicherheits- und Monitoring-Software völlig legitime Systemprozesse sind.

Betroffen waren offenbar nicht nur die On-Premise-Installationen der Kaseya-Kunden, sondern auch die von Kaseya betriebene SaaS-Cloud-Infrastruktur. Diese konnte jedoch nach Hersteller-Angaben noch rechtzeitig heruntergefahren werden, sodass darüber keine Client-Systeme infiziert wurden. Mittlerweile ist von etwa 60 direkt betroffenen Service-Provider-Kunden von Kaseya die Rede, die alle die On-Premise-Version von VSA einsetzten. Diese betreuten zusammen wiederum etwa 1.000 bis 1.500 Unternehmen (Endkunden). Der entstandene Schaden ist also enorm, und dass, obwohl Kaseya eher zu den kleineren Anbietern derartiger IT-Management-Plattformen gehört. Es ist kaum vorstellbar, welcher Schaden entsteht, wenn ein solcher Supply-Chain-Attacke Microsoft, Amazon oder Google treffen sollte, deren Software viele Millionen Kunden nutzen.

Darstellung Supply-Chain-Attacke

Supply-Chain-Attacken und Providermanagement

Und genau hier liegt die Schwierigkeit für die eben genannten Endkunden. Mit Ausnahme von ggf. fehlenden vertraglichen Regelungen für Cyberangriffe und deren Handhabung haben diese Kunden im Prinzip nichts falsch gemacht: Sie haben Teile ihrer IT an Service Provider outgesourct, die sich im Rahmen der ihnen übertragenen Services auch um die Software- und Updateverteilung kümmern. Welche Software diese Service Provider für die Erbringung der jeweiligen Leistungen einsetzen, darauf hat der Endkunde meist wenig Einfluss. Er vertraut darauf, dass der Service Provider seine Dienstleistungen auf einem angemessenen Sicherheitsniveau erbringt. Der Service Provider wiederum vertraut darauf, dass die Softwarehersteller die von ihm eingesetzten Produkte sicher gestaltet haben und insbesondere regelmäßig und rechtzeitig Sicherheitsupdates geliefert werden.

Aus Sicht des Providermanagements werden sich hier einige Konsequenzen ergeben. Entsprechende Verträge mit Service Providern müssen hinsichtlich Haftungs- und Regress-Anforderungen geprüft und möglicherweise angepasst werden. Für den Bereich Software- und Update-Management müssen ggf. Strategien entwickelt werden, um das Ausmaß von zukünftigen Angriffen dieser Art zu reduzieren. In einzelnen Schritten abgebildet, kann eine solche Strategie in etwa wie folgt aussehen:

1. Review des Sicherheitsproblems gemeinsam mit dem Service Provider
2. Erarbeiten eines Verfahrens zur Vermeidung zukünftiger Fälle eines Angriffstyps
3. Spezifikation aus dem Verfahren resultierender Leistungen des Service Providers
4. Vertragliche Vereinbarung der entsprechenden Leistungen
5. Verfahrensimplementierung
6. Überwachung des Verfahrens, u.a. durch SLA Reporting, Audits etc.

Praktisch kann ein solches Verfahren zum Beispiel in der Einrichtung von Testgruppen bestehen, die Software-Updates zuerst erhalten, bevor ein Massenrollout stattfindet. Dabei finden dann für diese Testgruppen diverse Prüfungen statt, um die Freigabe für eine sichere Software-/Updateverteilung zu erhalten. All diese Service-Inhalte müssen dann mit dem Provider genau spezifiziert und vertraglich festgeschrieben werden.

Fazit

Der Schutz vor solchen Supply-Chain-Attacken ist ein schwieriges Thema, da es sie in dieser Form so bislang eher selten gab. Erwähnenswert ist in diesem Zusammenhang der massive Angriff über die SolarWinds Software, bei der Ende 2020 bis zu 18.000 Netzwerke von Behörden und Unternehmen betroffen waren. Wie der aktuelle Fall zeigt, hilft an dieser Stelle auch das schnelle Einspielen von Sicherheitsupdates nicht, da eben diese Updates die eigentliche Schadsoftware enthielten. In den jetzt anstehenden Diskussionen zwischen Providern und Endkunden müssen völlig neue Bedrohungsszenarien diskutiert und entsprechende Gegenmaßnahmen vereinbart werden. Hier ist mit einem erheblichen Aufwand zu rechnen, insbesondere wenn Services an verschiedene Provider vergeben wurden. Dieser Mehraufwand lohnt sich aber in jedem Fall, da der nächste Angriff dieser Art nicht lange auf sich warten lassen wird.

Viele Unternehmen nutzen Continual Improvement (CI), um auf sich ständig wandelnde Anforderungen an Services, Produkte und Prozesse zu reagieren und Ihren Kunden stetig neuen Nutzen anbieten zu können. Vor diesen Herausforderungen stehen mittlerweile alle Organisationseinheiten, so auch das Providermanagement, insbesondere bei eigener Ausrichtung gemäß Service Integration and Management (SIAM). In dem heutigen Blogbeitrag möchten wir Ihnen aufzeigen, wie CI nach erfolgtem IT-Outsourcing in SIAM-Umgebungen implementiert werden kann.

Ausgangslage

Nach einem erfolgten IT-Outsourcing kommt es vor, dass die erbrachten Services sich zunächst verschlechtern, da sich die entsprechenden externen Service Provider in einer anfänglichen „Lernphase“ befinden. Dies kann schnell zu Unzufriedenheit in der Organisation des outsourcenden Unternehmens führen und sich bis hin zu starkem Widerstand gegenüber den externen Service Providern entwickeln. Von Kooperation, geschweige denn kontinuierlicher Verbesserung, ist gar nicht zu reden. Wie kann eine derartige Frontenbildung und sich verfestigende Unzufriedenheit mit den externen Services vermieden werden? Wie schafft man stattdessen gemeinsam mit den Service Providern den Einstieg in einen Verbesserungsprozess, der die Qualität der Services stetig erhöht?

Voraussetzungen

Kontinuierliche Verbesserung von Services, Produkten und Prozessen beginnt nicht erst während des Regelbetriebs. Deshalb ist es aus unserer Sicht entscheidend, bereits vor Beginn eines Outsourcings den Grundstein für eine Kultur der kontinuierlichen Verbesserung zu legen. Diese beinhaltet nicht nur die kontinuierliche Verbesserung der Services, sondern auch der Prozesse und der Zusammenarbeit. Basis hierfür ist ein, in der Phase der Gestaltung des übergreifenden Konzepts für Outsourcing, zu definierender Verhaltenskodex. Dieser gilt für alle Service Provider gleichermaßen.

In dieser Phase gilt es zudem, die groben Prozesse für die kontinuierliche Verbesserung, die ebenfalls für alle Service Provider gelten, festzulegen. Denn gerade in einer Multi-Provider-Umgebung sollte sichergestellt sein, dass alle Provider dieselben Prozesse implementieren, damit eine reibungsfreie Zusammenarbeit gewährleistet ist. In der Ausschreibungsphase sollte darauf geachtet werden, dass Bieter in ihren Angeboten bereits Lösungsansätze konkretisieren, wie sie den geforderten kontinuierlichen Verbesserungsprozess in ihrer Organisation praktisch umsetzen wollen. Der Auftraggeber schließlich legt jedoch die endgültige Ausgestaltung der Prozesse fest. Letztere sind dann wiederum für alle Provider verbindlich. Die Prozesshoheit verbleibt also beim Service Integrator. Anpassungsspielraum bleibt für die einzelnen Provider höchstens noch in der eigenen Organisation, ohne jedoch die Kooperation mit anderen Providern zu beeinträchtigen. Im Rahmen der Bietergespräche gilt es dann zu klären, ob beide Seiten ein gleiches Verständnis vom CI-Prozess und den daraus abgeleiteten Maßnahmen entwickelt haben.

Ist dies der Fall, sollten neben dem beidseitigen Bekenntnis zur kontinuierlichen Verbesserung die erarbeiteten Verfahrensvorgaben und deren Rahmenbedingungen in dem zu schließenden Vertrag festgeschrieben werden. Dies sollten mindestens folgende sein:

• Einzusetzende Methoden, z.B. Deming-Zyklus, Continual Improvement Model (ITIL)
• Umgang mit Kosten und Einsparungen
• Verantwortlichkeiten
• Regelmechanismen

In der Transitionsphase schließlich werden die vereinheitlichten Maßnahmen für CI sowohl auf Seiten des Service Integrators als auch auf Seiten aller Provider verbindlich implementiert und müssen anschließend mit Leben gefüllt werden. Denn nur so ist eine erforderliche Zusammenarbeit mehrerer Provider bei Verbesserungsaktivitäten möglich. Spätestens zu diesem Zeitpunkt sollte deshalb nochmals ein Review durch Vertreter aller Parteien durchgeführt werden, ob ein einheitliches Verständnis und eine einheitliche Handhabung erreicht worden sind. Ist dies nicht der Fall, muss der CI-Prozess auf jeden Fall nochmal auf den Prüfstand.

Schließlich soll Folgendes noch hervorgehoben werden: Eine lebendige Continual-Improvement-Kultur bedeutet, dass Verbesserungsvorschläge auf allen Ebenen, sowohl auf Provider- als auch auf Providermanagement-Seite aber auch von zusätzlichen Stakeholdern gemacht werden können und sollen. CI ist dabei kein einmaliger Vorgang, sondern soll Teil der DNA aller Beteiligten werden. Um dies zu erreichen, ist eine weithin sichtbare Unterstützung des Managements unabdingbar.

Abbildung 1: Deming-Zyklus

Mögliche Verfahren und Maßnahmen

Damit CI sein Potenzial, neuen Nutzen zu generieren und wechselnden Anforderungen zu begegnen, entfalten kann, muss es ein lebendiger Bestandteil des Betriebsalltags werden. Dies gelingt, wenn CI als Prozess bei allen Beteiligten präsent ist. Im Folgenden sollen beispielhaft einige Möglichkeiten aufgeführt werden, wie dies bewerkstelligt werden kann.

1. CI in allen Gremien mit (Multi-)Providerbeteiligung auf die Agenda setzen:

• regelmäßig am Ende jedes Gremien-Meetings (operatives Board, Service Management Board, …) wird das Thema CI zusätzlich auf die Agenda gesetzt
• identifizierte und besprochene Schwachstellen, weitere spontane Ideen sowie Verbesserungsansätze werden in einer CI-Liste dokumentiert

2. Ein regelmäßig tagendes CI-Gremium mit relevanten Service Providern etablieren:

• (aktualisierte) Bewertung der Vorschläge in der CI-Liste
• Verbesserungsvorschläge priorisieren und dabei darauf achten, dass die Priorisierung für alle transparent und nachvollziehbar ist
• Quick-Wins identifizieren und schnell zur Umsetzung führen (dienen als sichtbarer Motivationsschub für alle Beteiligten) – dies gilt auch für low-Cost / low-Effort Initiativen
• Anstoßen der Maßnahmen mit hoher Priorisierung
• Initiierung der Entwicklung von Verbesserungsansätzen (siehe Punkt 4)

3. CI-Liste für alle Stakeholder mittelbar oder unmittelbar zugänglich machen

• Möglichkeit schaffen, alle Formen von Feedback und Ideen aufzunehmen und in die CI-Liste zu überführen; dafür ist es eventuell notwendig, verschiedene Kanäle (z.B. Mail-Account, CI-Ansprechpartner, CI-Briefkasten) einzurichten
• gleichzeitig stetig allen Beteiligten signalisieren, dass ihre Verbesserungsvorschläge wichtig und erwünscht sind

4. Durchführung regelmäßiger Workshops mit folgender Agenda:

Anwendung kreativer Techniken zur Identifikation und Konkretisierung weiterer Verbesserungsvorschläge (und deren Aufnahme in CI-Liste), z.B.

• Design Thinking
• Creative Spaces
• sonstige Kreativitätstechniken

5. Einsatz agiler Methoden, um die Verbesserungsmaßnahmen umzusetzen

Um stetig Ergebnisse zu erzielen, ist es sinnvoll, komplexe Verbesserungsmaßnahmen in mehrere kleine und in sich abgeschlossene Pakete aufzubrechen und mit agilen Methoden umzusetzen. Geeignete Methoden hierfür sind z.B.:

• Kanban
• Kaizen
• Lean Six Sigma
• Scrum

6. Review der Verbesserungsmaßnahmen im CI-Gremium (siehe Punkt 2)

• das Erstellen eines Lessons-Learned-Logs kann hilfreich sein, um Erfahrungen aus Verbesserungsinitiativen zu dokumentieren und für spätere Initiativen zu nutzen
• regelmäßiger Review des CI-Prozesses selbst durch z.B. folgende Fragen
• • Waren die eingesetzten Methoden hilfreich?
  • Was war hinderlich?
  • Was war förderlich?

7. Aktive Vermarktung der Verbesserungen

Die Ergebnisse der Verbesserungsinitiativen, sollten dazu genutzt werden, das Bekenntnis zum Continual Improvement bei allen beteiligten externen Providern, Mitarbeitern im Providermanagement und sonstigen Stakeholdern weiter zu festigen. Dies kann durch aktive Vermarktung der bisherigen Erfolge geschehen.

So lässt sich z.B. bei internen Stakeholdern innerhalb der Organisation des Auftraggebers die Akzeptanz des Outsourcings, der externen Provider und der Retained Organisation durch gute Ergebnisse steigern. Finanzielle Einsparungserfolge können mit einer, vorab im Vertrag zu vereinbarenden, Einsparungsaufteilung zwischen Auftraggeber und Providern verbunden werden. Auf diese Weise können die Kosten auch beim Auftraggeber gesenkt werden. Die positiven Auswirkungen der Verbesserungen wiederum sind ein Anreiz, den CI-Prozess weiterzuverfolgen.

Aber auch die externen Provider können von erreichten Erfolgen profitieren. Sie können die gemachten Erfahrungen auf andere Kunden übertragen und somit dort ihr Ansehen und ihre Einnahmen steigern. Die Übertragung von Rechten an bestimmten verbesserungsbedingten Innovationen könnte ebenfalls ein Anreiz und Motivationsschub sein, die eingeschlagene Richtung weiterzuverfolgen. Selbiges gilt auch für positives Feedback von internen und externen Kunden. So kann allmählich das Ziel erreicht werden, CI zum selbstverständlichen Bestandteil der gemeinsamen Arbeit werden zu lassen.

Fazit

Als gelebte Praxis ist Continual Improvement in SIAM-Umgebungen leider immer noch viel zu selten. Dabei hilft ein gut etabliertes CI dem Service Integrator und den externen Providern, Services und Prozesse stetig zu verbessern und den Nutzen der Services für die Kunden laufend zu erhöhen. Es verbessern sich jedoch nicht nur die angebotenen Services, sondern auch die Zusammenarbeit aller Beteiligten untereinander, denn auch die ist Gegenstand der kontinuierlichen Verbesserung. So hilft die CI-Einführung in einer SIAM-Umgebung schließlich auch, eine vertrauensvolle Kultur der Kooperation zu fördern, von der am Ende alle Beteiligten profitieren.

Die Service Value Chain ist das Herzstück des in ITIL4 vorgestellten Service Value Systems. Letzteres beschreibt, wie alle Komponenten und Aktivitäten einer Organisation zusammenspielen, um durch IT-Services einen Wert zu erschaffen. ITIL4 Engage wiederum ist eine Aktivität in der Service Value Chain.

Zweck dieser Aktivität ist, ein gutes Verständnis der Stakeholder-Anforderungen und die kontinuierliche Einbeziehung aller Stakeholder bei der Entwicklung und dem Management von IT-Services sicherzustellen. Kommunikation kann bzw. muss in diesem Zusammenhang als fortwährender Austausch mit den Stakeholdern verstanden werden, der an jeder Stelle der Service Value Chain auftaucht. Wie sieht dies in der Praxis aus?

Abbildung 1: Service Value Chain gem. ITIL4

Der Kunde kommt mit einem neuen oder zusätzlichen Bedarf (Demand) für einen Service oder ein Produkt auf die IT-Abteilung zu, bzw. der Service-Manager in der IT-Abteilung stellt diesen fest. Die Kommunikation hierüber kann über verschiedene Kanäle geführt werden, z. B. über regelmäßige Meetings von Service-Manager und Kunde, ein Self-Service-Portal oder einen Service Desk. Die IT-Abteilung muss diesen Bedarf zunächst analysieren und besser verstehen, um mit der Planung zu beginnen. Dazu bedarf es wiederum der Rücksprache mit dem Kunden, denn dessen Anforderungen sind ausschlaggebend für die Serviceplanung und das Service Design.

Bei komplexen Services ist eine iterative Feedbackschleife, wie sie Scrum einsetzt, hilfreich. So ist gewährleistet, dass nicht nur der Output (Maßnahmen oder Dinge, die ein gewünschtes Resultat herbeiführen sollen) stimmt. Auch das Outcome stimmt, also das Resultat (oder anders gesagt: das, was ein Unternehmen erreichen möchte), welches letztlich den Wert für die verschieden Stakeholder ausmacht.

Ist ein externer Service-Provider an der Service-Gestaltung und -Erbringung beteiligt, so ist er von Beginn an mit in die Kommunikation einzubeziehen. Hierzu später mehr. In den Kernphasen des Designs, des Erstellens und des Ausrollens des Services müssen verschiedene Informationen fließen, so z.B. Analyse von Risiken, Security- und Compliance-Anforderungen, Service-Performance-Reporting, Verträge und Vereinbarungen mit internen und externen Providern, um nur einige zu nennen. Die Informationen fließen über verschiedene Medien, wie z.B. Reports, Collaboration Tools, Service Level Agreements, Wissensmanagement-Datenbanken und viele mehr. Auch die entstandenen Services ziehen Kommunikation nach sich. Sie müssen in den Servicekatalog aufgenommen und bekannt gegeben werden. Regelmäßiges Feedback von Usern und Kunden muss eingeholt werden (z.B. über eine Kunden-Umfrage) und natürlich müssen die Services auch kontinuierlich verbessert werden.

Man kann anhand dieses sehr groben Beispiels bereits sehen, dass bei jedem Schritt in der Service Value Chain Kommunikation in verschiedenste Richtungen und über verschiedenste Medien notwendig ist. Wer aber ist in der IT-Organisation dafür verantwortlich, diese Kommunikation zu lenken? In erster Linie ist dies der Service-Manager, denn er ist die Schnittstelle zwischen der IT-Organisation im Sinne eines internen IT-Providers und dem Kunden. Auch wenn er nicht immer direkt in die Kommunikation eingebunden ist (zum Beispiel beim Self-Service-Portal), ist er stets informiert, um die Bedürfnisse und Interessen seiner Kunden zu vertreten. Gleichzeitig kommt dem Kunden in dieser Konstellation eine erweiterte Rolle zu. Er ist nicht mehr nur Kunde, sondern potenziell auch Product Owner, das heißt er setzt die Prioritäten bei der Service-(weiter-)Entwicklung. Auf jeden Fall wird er aktiv an der Produktentwicklung und -verbesserung beteiligt. Dies kann im Rahmen von regelmäßigen Foren und Meetings geschehen, aber auch zusätzlich über verschiedene mündliche oder schriftliche Feedbackkanäle.

Sind nun noch ein oder mehrere externe Service Provider an der Serviceerbringung beteiligt, sieht das Kommunikationskonstrukt etwas anders aus. Die Rolle des Kunden nimmt jetzt der Providermanager ein. Er steht im Austausch mit den externen Providern und übernimmt die Kommunikation mit diesen über alle Schritte der Service Value Chain. Außerdem moderiert er die Anforderungen der Service-Manager und ihrer Kunden.

Dies ist zu empfehlen, da sonst die Gefahr besteht, dass durch direkte Kommunikation der Kunden mit den externen Service-Providern eine Schatten-IT entsteht, die neben der „offiziellen“ IT betrieben wird.

Sollte die Situation eintreten, dass aufgrund der notwendigen fachlichen Kompetenz zur Klärung von Fragen zum Service ein Providervertreter einzubinden ist, so sollten Service-Manager und Providermanager diesen begleiten und das Gespräch mit dem Kunden moderieren. Der Providervertreter wiederum sollte nicht einen vertrieblichen, sondern einen fachlichen Schwerpunkt (=Fachexperte) haben.

Abbildung 2: Kommunikationskette Kunde IT-Organisationexterne Provider

Wie aber kommen die Informationen vom externen Service-Provider zum Kunden? Der regelmäßige Austausch zwischen Service- und Provider-Manager (sofern diese beiden Rollen nicht von einer einzigen Instanz übernommen werden) bildet diese „Kommunikationsbrücke“. Dazu ist es notwendig, nicht nur regelmäßig, sondern auch in kurzen Intervallen in Austausch zu treten. Hierzu sind verschiedene Formen denkbar, je nachdem, wie die IT-Organisation aufgestellt ist:

• regelmäßige persönliche Runden
• Videokonferenzen
• direkte Telefon- und Chat-Kommunikation

Wichtig ist, dass Ergebnisse, Entscheidungen, Absprachen etc. dokumentiert werden, damit sie nachvollzogen werden können und das Wissen nicht verloren geht. Reibungsverluste in diesem Teil der Kommunikationskette können zu wachsenden Reibungsverlusten in den anderen Teilen führen.

Fazit: ITIL4 Engage

Wie in ITIL4 und hier insbesondere im Rahmen der Service Value Chain sehr gut adressiert, erhält die Kommunikation mit Kunden und anderen Stakeholdern in heutigen Zeiten deutlich mehr Gewicht. ITIL4 Engage ist hierbei ein Schlüsselelement. IT-Organisationen müssen zukünftig sicherstellen, dass Informationen ungehindert in alle Richtungen fließen können. So kann schnell auf Änderungsanforderungen reagiert werden. Herzstück dieser Kommunikationskette ist der regelmäßige Austausch zwischen dem Kunden, dem Service-Manager und dem Provider-Manager.

In vielen Unternehmen werden die Begriffe Service- und Provider-Manager für IT-Servicemanagement Rollen genutzt. Da es keine akzeptierte Standard-Definition für diese Begriffe gibt, ist das Verständnis der damit in Unternehmen bezeichneten Rollen sehr unterschiedlich. Zum Teil werden sie auch synonym für ein und dieselbe Stelle in der IT verwendet. Entsprechende Stellenbezeichnungen tauchen ebenfalls immer wieder in den entsprechenden Jobportalen auf. Im Folgenden zeigen wir einerseits eine Abgrenzung, parallel aber auch das notwendige Zusammenspiel der beiden Rollen auf. Die grundlegenden Definitionen orientieren sich dabei an der üblichsten Verwendung im Markt. Unser Hauptfokus ist aber die Gestaltung von Kunden- und Lieferantenmanagement.

Zunächst werde ich die beiden IT-Servicemanagement Rollen konkretisieren und gegeneinander abgrenzen, bevor wir auf die Abhängigkeiten und das Zusammenspiel der beiden Rollen kommen. Beide Rollen haben Schlüsselfunktionen in der Dienstleisterkette eines IT-Bereichs (siehe Abbildung 1).

Die Rolle des Service-Managers

Ein Service-Manager stellt sicher, dass die intern angebotenen IT-Services stets den Anforderungen seines/seiner IT-Kunden gerecht werden. Er hat eine vertriebsorientierte Rolle und ist erster Ansprechpartner für den Kunden. Hierfür benötigt er ein grundlegendes Verständnis des Business, der Anforderungen und der Prozesse seiner Kunden sowie Softskills für den Umgang mit dem Kunden. Er übernimmt insbesondere folgende Aufgaben:

• Sicherstellen, dass die mit dem Kunden geschlossenen Servicevereinbarungen eingehalten werden – dies impliziert das Vertreten der Kundeninteressen in der eigenen
  IT-Organisation,
• SLA Reporting und regelmäßige Service review Meetings mit dem Kunden,
• Beratung des Kunden hinsichtlich des bestehenden IT-Serviceangebots,
• Abstimmung des Demand mit dem Kunden,
• Aufnahme neuer Kundenanforderungen und Initiierung von daraus resultierenden Serviceänderungen und neuen Services in der eigenen IT-Organisation.

Aus Sicht von ITIL ist dies eine Mischung von Aufgaben der Management Practices Relationship Management, Service Level Management und (des noch in ITIL V3 enthaltenen) Demand Management.

Die Rolle des Provider-Managers

Der Provider-Manager stellt sicher, dass die von „seinen“ externen Providern bezogenen
IT-Services stets den Anforderungen des internen Serviceportfolios entsprechen. Seine Rolle hat einen klaren Fokus auf das Lieferantenmanagement. Er ist zentraler Ansprechpartner für den Service-Manager des Providers. Er muss einen guten Überblick über das aktuelle interne (d.h. im Servicekatalog definierte) Serviceangebot, in Planung befindliche Serviceänderungen und die gesamte Serviceorganisation besitzen. Zudem muss auch er Soft Skills mitbringen; in diesem Fall für den Umgang mit seinen Providern wie auch mit internen Kollegen aus anderen Funktionsbereichen. Er übernimmt insbesondere folgende Aufgaben:

• Sicherstellen, dass die mit dem Provider geschlossenen Servicevereinbarungen eingehalten werden – dies impliziert das Vertreten der Interessen der eigenen IT-Organisation gegenüber dem Provider,
• Prüfung von SLA-Reportings und Rechnungen des Providers, regelmäßige Servicereview-Meetings mit dem Provider,
• Providerseitige Abstimmung und Beauftragung von erforderlichen Serviceänderungen und neuen Services, Sicherstellung einer korrekten Implementierung und Inbetriebnahme der Änderungen,
• Sicherstellung von angemessenem Risiko und Compliance-Management bezüglich der extern bezogenen Services,
• Steuerung der Identifikation und Umsetzung von Verbesserungspotentialen und Innovationen im Servicesegment des Providers,
• Überwachung der Provider-bezogenen Budgets.

Aus Sicht von ITIL beinhaltet dies die Management Practices Supplier Management und Measurement & Reporting, geht zum Teil aber deutlich darüber hinaus.

Abbildung 1: Rollenanordnung in der Dienstleisterkette

Abgrenzung und Zusammenspiel der beiden IT-Servicemanagement Rollen

Wie man sieht, sind die Aufgaben der beiden IT-Servicemanagement Rollen gar nicht so unterschiedlich: Beide kümmern sich um die vereinbarungsgerechte Serviceerbringung und – in einer zunehmend agilen Welt immer wichtigeren – Aufnahme und Umsetzung erforderlicher Serviceänderungen. Der Fokus ist aber jeweils ein anderer:

Der Service-Manager als Teil des „IT-Vertriebs“ sorgt dafür, dass das interne Serviceangebot stets dem (sich laufend ändernden) Bedarf des Kunden gerecht wird. Sein Ziel ist der „Vertriebserfolg“, d.h. geplanten Umsatz, Kundenzufriedenheit und dauerhafte Kundenbindung zu erreichen. Letzteres ist heute für den internen IT-Bereich kein Selbstgänger mehr: Durch schnell zugängige, einfach zu beauftragende Cloud-Services besteht die Gefahr, dass interne IT-Kunden zunehmend – an IT-Bereich und Einkauf vorbei – Services extern beziehen (Stichwort: Maverick-Buying).

Der Provider-Manager hingegen hat sicherzustellen, dass die vom IT-Vertrieb verkauften Services, die nicht intern produziert werden, bedarfsgerecht von hierfür vertraglich verpflichteten externen Providern bezogen und erbracht werden. Sein Ziel ist also die korrekte Bereitstellung passender externer Services, um den vom IT-Vertrieb generierten Bedarf zu decken.

Aus der aufgabenseitigen Abgrenzung dieser IT-Servicemanagement Rollen wird schon deutlich, dass die Aufgaben der einen Rolle die der anderen bedingen und gut aufeinander abgestimmt sein müssen: Der Service-Manager ist darauf angewiesen, dass die mit seinen IT-Kunden vereinbarten Services auch in angemessener Qualität und zeitgerecht produziert werden. Wenn die Services von externen Providern erbracht werden, liegt die Verantwortung hierfür beim Provider-Manager: Er hat die Provider entsprechend zu steuern bzw. zu managen. Andererseits muss der Service-Manager stets über die aktuelle Lage der Services des Providers auf dem Laufenden sein, um in Gesprächen mit dem Kunden kompetent Auskunft geben zu können.

Um dies zu gewährleisten, muss ein regelmäßiger Informationsfluss zwischen den beiden Rollen sichergestellt sein. Zudem müssen Prozesse etabliert sein, um von IT-Kunden angeforderte Service-Requests und Service-Changes auch angemessen bearbeiten zu können. In derartigen Prozessen sind, neben den beiden Rollen, auch andere wie zum Beispiel das Service Design beteiligt. Die saubere Implementierung der Prozesse und des Informationsaustauschs erhält eine noch höhere Bedeutung, wenn mehr als ein Provider an der Service-Bereitstellung beteiligt ist.

Fazit

Nach unserer Definition stehen Service-Manager und Provider-Manager an unterschiedlicher Stelle in der Leistungserbringung: Der Service-Manager bedient die Schnittstelle des IT-Bereichs zum Kunden, der Provider-Manager steuert an der Lieferanten-Schnittstelle externe Provider. Beides muss koordiniert ablaufen, damit die eingekauften Provider Services auch den Kundenanforderungen gerecht werden. Im Idealfall werden beide IT-Servicemanagement Rollen an eine Instanz bzw. Stelle gegeben. Dies ist aber in der Praxis meist nur in kleineren Umgebungen möglich. In allen anderen Fällen ist das Zusammenspiel sehr gut zu organisieren, um die Ziele der IT und damit auch der IT-Kunden zu erreichen.