Erfolgreiches IT-Outsourcing  erfordert eine Providersteuerung mit Tools, die stets den Zugang zu notwendigen Informationen sicherstellen. In dynamischen IT-Landschaften mit Cloud-Lösungen und “As-a-Service”-Modellen ist es entscheidend, externe Service-Provider effektiv zu überwachen. Governance-Vorgaben und Compliance-Regeln bieten einen Ordnungsrahmen, stellen aber allein nicht einen guten IT-Service sicher. Viele Unternehmen setzen für an der Providersteuerung Beteiligte eine ungeeignete Tool-Landschaft ein und das führt zu ineffizienten Arbeitsabläufen. Eine umfassende IST-Analyse der bestehenden Tool-Landschaft identifiziert Schwachstellen wie redundante Datenhaltung und fehlende Schnittstellen. Basierend darauf wird ein Soll-Konzept entwickelt, das ein Datenmodell und ein flexibles Berechtigungskonzept umfasst, um die Zugänglichkeit und Transparenz der Informationen für alle Beteiligten zu verbessern.

Ein möglicher Ansatz für Providersteuerung-Tools ist die Nutzung von Werkzeugen wie MS SharePoint. Denn das ermögicht einen zentralen Zugang zu allen relevanten Daten – auch aus verschiedenen Systemen. Dies erleichtert die Verknüpfung von Informationen und den Einsatz von KI-Funktionen, um die Effizienz zu steigern und manuelle Prozesse zu reduzieren. Hierbei sollte die Implementierung schrittweise erfolgen und durch Schulungen und Kommunikation unterstützt werden. Ausgereifte, integrierte Tools zur Providersteuerung sparen Zeit und Kosten und stärken die Position des Unternehmens gegenüber Service-Providern. Eine effiziente Tool-Landschaft für die Providersteuerung ist somit ein bedeutender Faktor für den Erfolg der IT-Services.

Lesen Sie im nachfolgenden Whitepaper, wie Sie eine für Ihre Organsiation angemessene Toolumgebung für Ihre Providersteuerung gestalten können.

Risikomanagement im IT-Providermanagement ist unerlässlich, um die Risiken beim und nach dem Outsourcing von IT-Services zu minimieren und einen reibungslosen Service-Betrieb zu gewährleisten. In der heutigen digitalen Welt wächst für Unternehmen die Abhängigkeit des Kerngeschäfts von IT-Services stetig und Erfolg oder Misserfolg des Unternehmens wird zunehmend durch Effizienz und Qualität der IT-Services mitbestimmt.
Wir zeigen im Folgenden auf, wie beim Outsourcing und insbesondere in der Betriebsphase im Rahmen des Providermanagements Risikomanagement für IT-Services gehandhabt werden kann. 

Risikomanagement im IT-Providermanagement – Einführung in die Risiko-Handhabung bei IT-Outsourcing

Das Management von Outsourcing-Risiken ist von großer Bedeutung, da es Unternehmen dabei hilft, die Stabilität, Sicherheit und Integrität ihrer IT-Systeme und Daten sicherzustellen. Zudem trägt es dazu bei, die Compliance mit ihren gesetzlichen und regulatorischen Anforderungen zu gewährleisten. Das Ziel des Risikomanagement im IT-Providermanagement ist es, Risiken, die sich aus dem Einsatz von Service-Providern ergeben, zu identifizieren, zu bewerten und Maßnahmen zu ergreifen, um diese Risiken zu minimieren.

Wichtig ist dabei, Risikomanagement in allen Phasen des Outsourcing Life Cycle aktiv zu betreiben:

Abbildung 1: Risikomanagement und Outsourcing-Lebenszyklus

In der Phase „Strategie“ werden Risiken untersucht, welche mit der Entscheidung zum Outsourcen auftreten können. In der Konzept-Phase, d.h. der Konzeption der auszusourcenden Services, werden nur Alternativen mit tragbaren Risiken berücksichtigt. In der Request-for-Proposal- (RFP-) Phase werden Providereigenschaften abgefragt und analysiert, die Rückschlüsse auf Risiken zulassen. Die Vergabe an einen Service-Provider erfolgt dann bei einem angemessenen Verhältnis von (vertretbaren) Risiken zu angestrebtem Nutzen. Notwendige Maßnahmen zur Begegnung wesentlicher Risiken sind im Vertrag mit dem Service-Provider aufzunehmen. In der Transitionsphase wird Risikomanagement im Rahmen des Projektmanagements geleistet. Zum Abschluss des Transitionsprojekts übergeben Projektmanager:innen das Risikomanagement an die Linienorganisation, damit dieses in der Betriebsphase fortgesetzt wird.

Risikomanagement im IT-Providermanagement – Gesetzliche und regulatorische Anforderungen

Insbesondere für regulierte Branchen wie den Finanzsektor, Versicherungen und Betreiber kritischer Infrastrukturen (KRITIS) gibt es Richtlinien und gesetzliche Vorgaben zum Risikomanagement bei IT-Outsourcing, deren Einhaltung sichergestellt werden muss. Die dort oft nur generell formulierten Vorgaben sind in konkrete Verfahren und Prozesse im jeweiligen Unternehmen umzusetzen. Beispiele für derartige Vorgaben sind unter anderem:

Finanzsektor

• Kreditwesengesetz (KWG), §25b
• EBA Leitlinien zu Auslagerungen (EBA/GL/2019/02)
• Mindestanforderungen an das Risiko-Management (MaRisk) – AT 9
• Bankaufsichtliche Anforderungen an die IT (BAIT)

Versicherungssektor 

• Das Versicherungsaufsichtsgesetz (VAG), §32
• EIOPA Leitlinien zu Sicherheit und Governance im Bereich der Informations- und Kommunikationstechnologie (EIOPA-BoS-20/600)
• Mindestanforderungen an die Geschäftsorganisation von Versicherungsunternehmen (MaGo) – §13
• Versicherungsaufsichtliche Anforderungen an die IT (VAIT)

KRITIS-Sektor

• BSI-Standard 200-3: Risikomanagement
• BMI – Schutz Kritischer Infrastrukturen – Risiko- und Krisenmanagement · Leitfaden für Unternehmen und Behörden
• IT-Sicherheitsgesetz 2.0
• ISO/IEC 27001

Risikomanagement im IT-Providermanagement – Risiko-Identifikation und -analyse bei outzusourcenden IT-Services

Das Risikomanagement bei outzusourcenden IT-Services kann in zwei Phasen unterteilt werden, nämlich vor dem Outsourcing und nach dem Outsourcing (siehe Abbildung 2). Vor dem Outsourcing ist der Auftraggeber für die Durchführung des Risikomanagements allein verantwortlich und zuständig.

Nach dem Outsourcing können die Risiken in drei Gruppen unterteilt werden: Auftraggeber-Risiken, Provider-Risiken und Schnittstellen-Risiken. Auftraggeber-Risiken sind IT-bezogene Risiken, die bei dem Auftraggeber verbleiben. Es entstehen durch das Outsourcing auch neue Risiken, die vom Auftraggeber zusätzlich gemanagt werden müssen. Provider-Risiken sind Provider- und Service-bezogene Risiken, letztere werden zum Teil vom Auftraggeber an den Provider verlagert. Sie sind vom Provider zu managen. Jedoch ist der Auftragsgeber weiterhin für diese Risiken verantwortlich und muss sicherstellen, dass der Provider seinen Pflichten angemessen nachkommt. Zwischen Auftraggeber und Provider werden im Rahmen des Outsourcings organisatorische und technische Schnittstellen geschaffen, die auch Schnittstellenrisiken mit sich bringen. Eine klare Definition und Zuordnung der Zuständigkeiten bezüglich des Risikomanagements sind hier notwendig.

Abbildung 2: Risikomanagement vor und nach dem Outsourcing

Es ist auch wichtig, die verschiedenen Kategorien von Risiken im Zusammenhang mit IT-Outsourcing zu identifizieren. Die Risiko-Kategorien unterstützen bei der Einordnung von erkannten Risiken und helfen zudem bei der Überprüfung der Vollständigkeit der erfassten Risiken. Folgende können insbesondere auftreten*:

• Strategisches Risiko: tritt auf, wenn die Entscheidungen und Handlungen eines Service Providers nicht mit den strategischen Zielen des Unternehmens vereinbar sind
• Betriebsrisiko: bezieht sich auf das Verlustrisiko, das sich aus ineffektiven oder fehlerhaften Prozessen, Mitarbeitern, Kontrollen oder Systemen eines Service Providers ergibt
• Risiko der Geschäftskontinuität: tritt auf, wenn ein externes Ereignis die Fähigkeit des Service Providers beeinträchtigt, den IT-Betrieb fortzuführen, mit entsprechenden Auswirkungen auf den Auftraggeber
• Compliance- und regulatorisches Risiko: entsteht aus der potenziellen Nichteinhaltung von Gesetzen und Vorschriften durch einen Service-Provider
• Informationssicherheitsrisiko: bezieht sich im Wesentlichen auf Cyberangriffe und Datenschutzverletzungen, die aufgrund von Sicherheitslücken bei Providern entstehen können
• Finanz- und Kreditrisiko: bezieht sich direkt auf eine kritische finanzielle Situation des Service-Providers, in der er seinen vertraglichen Verpflichtungen nicht mehr nachkommen, d.h. Produkte und Dienstleistungen nicht wie vereinbart bereitstellen kann
• Reputationsrisiko: umfasst jede der zahlreichen Möglichkeiten, wie der Service- Provider den Ruf, die Marke oder den Namen des Auftragsgebers direkt oder indirekt schädigen könnte
• Konzentrationsrisiko: tritt auf, wenn das Unternehmen zu viele risikoreiche oder kritische Dienste von einem einzigen Service-Provider bezieht oder es nur einen Provider auf dem Markt gibt, der für den Auftragsgeber kritische Produkte und Dienstleistungen anbietet
• Geopolitisches Risiko: kann auftreten, wenn sich der Sitz des Service-Providers in einem Land befindet, das anfällig für Probleme wie politische Unruhen, Korruption oder Menschenrechtsverletzungen ist
• Umwelt-Risiko: umfasst politische Veränderungen, Naturkatastrophen und andere gesellschaftliche Belange, die sich auf die Dienstleistungserbringung des Service- Providers auswirken können

* https://www.venminder.com/blog/types-vendor-risks-monitor

Diese Liste hat keinen Anspruch auf Vollständigkeit. Die aufgrund der Risikokategorien sind in einem Risikoregister aufzunehmen und angemessen zu managen, d.h. sie sind sorgfältig zu bewerten und es sind geeignete Maßnahmen zu planen und zu ergreifen.

Risikomanagement im IT-Providermanagement – Beispielhafte Maßnahmen zur Risikominimierung

Für ausgewählte Risikokategorien werden im Folgenden Beispiele für Maßnahmen aufgezeigt:

Betriebsrisiko:

• Klare Definition von Verantwortlichkeiten und Zuständigkeiten, um das Risiko von Missverständnissen, Verwechslungen und Verzögerungen bei der Durchführung von Aufgaben zu minimieren
• Klare Spezifikation der Service Level – Leistungskennzahlen (KPIs) und Zielwerte – in der Strategie- und Konzeptions-Phase, um das Risiko unklarer Erwartungen und Ziele zwischen dem Auftraggeber und dem Service-Provider zu minimieren

Compliance- und regulatorisches Risiko:

• Forderungen nach Standards und Zertifizierungen sowie Sicherheits-Systemen und -Technologien bei der Providerauswahl
• Implementierung von Kontrollen und Prozessen, um sicherzustellen, dass der Service- Provider die gesetzlichen Anforderungen und Vorschriften einhält
• Festlegung von KPIs und Zielwerten zur Messung der Compliance sowie Etablierung eines regelmäßigen Reporting und dessen Prüfung

Risiko der Geschäftskontinuität:

• Implementierung eines Business Continuity Plan (BCP) durch den Service-Provider, um im Falle eines externen Ereignisses die Fortsetzung des IT-Betriebs sicherzustellen
• Regelmäßige Überprüfung und Aktualisierung des BCP, um sicherzustellen, dass er den aktuellen Bedürfnissen und Anforderungen entspricht
• Regelmäßiges Testen des BCP, um sicherzustellen, dass er im Ernstfall effektiv funktioniert

Risikomanagement im IT-Providermanagement – Schlussfolgerung

Zusammenfassend lässt sich sagen, dass das Risikomanagement im IT-Providermanagement von großer Bedeutung ist, um die Stabilität, Sicherheit und Integrität von IT-Systemen und -Daten zu gewährleisten. Insbesondere in regulierten Branchen wie dem Finanz- und Versicherungssektor, sowie im KRITIS-Sektor müssen die Unternehmen enge regulatorische Vorgaben einhalten, indem sie angemessene Verfahren und Prozesse für das Risikomanagement etablieren.

Das Risikomanagement ist in allen Phasen des Outsourcing-Life-Cycle zu berücksichtigen und muss alle relevanten Risiko-Kategorien umfassen. Bei Outsourcing sind zwischen Auftragsgeber-Risiken, Provider-Risiken und Schnittstellen-Risiken zu unterscheiden, die risikobezogene Gesamtverantwortung verbleibt aber beim Auftraggeber. Daher ist es wichtig, dass Unternehmen klare Zuständigkeiten definieren, um Risiken zu managen, die sich aus der Zusammenarbeit mit Service-Providern ergeben.

Provider-Management-Tools werden verwendet, um die Beziehung zwischen einem Unternehmen und seinen IT-Service-Providern zu verwalten. Sie unterstützen Unternehmen, ihre Provider und Lieferanten zu verwalten, ihre Leistung zu verfolgen und sicherzustellen, dass sie die Anforderungen des Unternehmens erfüllen. Dabei gibt es keine Einheitslösung für an die Tools gestellte Anforderungen, weil die Funktionsschwerpunkte der eingesetzten Tools häufig verschieden sind. Dieser Artikel vergleicht drei Tools mit jeweils unterschiedlichen Schwerpunkten: ServiceNow, SAP Ariba und Kissflow Procurement, die als Provider-Management-Tool genutzt werden können.

Provider-Management-Tools – Funktionsanforderungen im Providermanagement

Neben allgemeinen Anforderungen an ein Provider-Management-Tool wie

• intuitive Bedienbarkeit
• schnelle Einarbeitung für Benutzer:innen
• einfache Möglichkeit der Anpassung an die individuellen Bedürfnisse eines     Unternehmens
• Skalierbarkeit
• Wirtschaftlichkeit
• Unterstützung von unterschiedlichen Rollen
• Datensicherheit und Datenintegrität,

gibt es funktionelle Anforderungen, die für die Aktivitäten im Providermanagement wichtig sind. Diese Funktionsanforderungen fokussieren auf die Unterstützung des Unternehmens bei folgenden Providermanagement-Aufgabenbereichen: Vertragsmanagement, Performance Management, Beziehungsmanagement, Risikomanagement, Changemanagement, Providerbewertung, Compliance Management, Continual Improvement und Financial Management. Jeder Aufgabenbereich wird im Idealfall durch einen Funktionsbereich im Tool unterstützt, siehe hierzu auch unser Blogbetrag: SharePoint-gestützte Providersteuerung – alle Infos an einem Ort

Providermanagement – Funktionsbereiche

Provider-Management-Tools – eine Übersicht

Es gibt viele verschiedene Tools mit Providermanagement-Funktionalitäten auf dem Markt, jedes mit seinen eigenen einzigartigen Funktionen und Vorteilen. In diesem Abschnitt stellen wir beispielhaft die drei Tools ServiceNow, SAP Ariba und Kissflow gegenüber. Aufgrund ihrer unterschiedlichen inhaltlichen Ausrichtung setzen sie verschiedene funktionale Schwerpunkte.

ServiceNow

ServiceNow ist ein globaler Anbieter einer Cloud-basierten Plattform, mit der es möglich ist, Geschäftsprozesse schnell und einfach zu automatisieren. Dieses Tool ist modular und besteht aus den Workflows IT, HR, Kunde und Creator. Jeder Workflow beinhaltet mehrere Produktbereiche, die je nach Anforderungen des Unternehmens zusammengestellt werden können und in jedem Produktbereich sind mehrere Produkte mit unterschiedlichen Funktionen zusammengefasst.

Das wesentliche Providermanagement-Funktionen bereitstellende Produkt Vendor Management Workspace von ServiceNow ist Teil des Produktbereichs IT Service Management (ITSM). Vendor Management Workspace integriert Daten aus den Produkten Service Portfolio Management (SPM), Contract Management, Assets, SLA Contracts, Vendor Risk Management und Continual Improvement Management (CIM). Ein integriertes „Provider Performance Dashboard“ liefert dem Unternehmen ein klares Bild davon, wie gut die Provider arbeiten. Weitere Produkte wie Audit Management, Vendor Risk Management und Compliance Management, die für das Providermanagement auch relevant sind, sind im Produktbereich Governance, Risk, und Compliance angesiedelt.

Abbildung 1: ServiceNow vereinfachte Produktstruktur

SAP Ariba

SAP Ariba bietet einen Online-Marktplatz für den Business-to-Business-Handel, der für den Kauf von Waren und Dienstleistungen von Lieferanten genutzt werden kann. Es unterstützt Einkäufer:innen bei all ihren klassischen Aufgaben und Lieferanten bei der Interaktion mit Einkäufer:innen. Der Leistungsschwerpunkt ist die Digitalisierung und Automatisierung von Einkaufsprozessen und Lieferketten. Es gibt keinen direkten Bezug auf IT Service Management, jedoch können IT-Services damit beschafft und Service-Provider gesteuert werden. SAP Ariba verfügt über eine breite Palette von Produktbereichen, die in weiteren Produkten wie Supplier Risk, Contracts, Spend Analysis, rollenbasierte Dashboards, Supplier Lifecycle and Performance und mehr unterteilt sind. Fast alle diese Produkte unterstützen mit ihren Funktionen Teile der für das Providermanagement geforderten Funktionsbereiche. Weiterhin kann SAP Ariba mit SAP HANA (für z.B. Rechnungsprüfung und -genehmigung sowie Budgetüberwachung) synchronisiert werden.

Abbildung 2: SAP Ariba vereinfachte Produktstruktur

Kissflow

Kissflow ist ein einfaches und anpassbares cloud-basiertes Workflowtool. Dieses Tool ermöglicht die Entwicklung von Applikationen für Geschäftsprozesse ohne oder mit wenig Code und stellt Templates bereit, um Unternehmen bei der Erstellung von personalisierten Workflows, die genau auf die Bedürfnisse der Organisation abgestimmt sind, zu unterstützen. Darüber hinaus stellt es Produkte mit allgemeinen Features bereit. Diese Features können benutzt werden, um unternehmensspezifische Applikationen zu entwickeln.

Unter den Produkten sind auch vorgefertigte Applikationen wie z.B. Projektmanagement und die Procurement App. Die Funktionen der Procurement App können bei der Durchführung der Providermanagement-Aufgaben eingesetzt werden. Die Procurement App bietet als Funktionalität zum Beispiel einen automatisierten Onboarding-Prozess für Provider, einen Bestellanforderungs-Prozess und ein integriertes Provider-Performancemanagement. Ebenso lässt sie sich über die Schnittstellen-Funktion in andere Kissflow-Produkte oder Anwendungen von Drittanbietern wie SAP, Google Apps, Office 365 und Zapier integrieren. Somit können fehlende Providermanagement-Funktionen wie z.B. Beziehungsmanagement erweitert werden.

Abbildung 3: Kissflow vereinfachte Produktstruktur

Provider-Management-Tools – Ein Vergleich

Alle drei Tools erfüllen die oben beschriebenen allgemeinen Anforderungen. In der folgenden Tabelle werden die Produkte bzw. die Funktionen der Tools aufgelistet, welche die oben aufgeführten Funktionsanforderungen an das Providermanagement adressieren:

Legende: — Nicht vorhanden

Fazit

ServiceNow deckt alle Funktionen des Providermanagements durch vorhandene Produkte ab.

SAP Ariba hat zwar Funktionen für Providermanagement, aber einige der Funktionsanforderungen können nur über Umwege abgedeckt werden, zum Beispiel können beim Performance Management die aktuelle IT-Service-KPIs nur über eine Umfrage-Funktion importiert werden, um sie anschließend analysieren zu können. Allerdings ist die Umfrage-Funktion eher für die Bewertung des Providers gedacht und nicht für Reporting und Analyse der IT-Service-KPIs.

Kissflow deckt am wenigsten Providermanagement-Funktionen ab, aber es scheint   möglich zu sein, Applikationen in Kissflow zu entwickeln, um weitere Funktionen zu realisieren.

Da alle vorgestellten Provider-Management-Tools APIs zum Integrieren von anderen Tools wie ERP-, Vertragsmanagement- oder IT-Service-Management-Systemen bereitstellen, können die nicht abgedeckten Funktionen auch über die Implementierung dieser Schnittstellen realisiert werden. Demnach können so Finanzdaten aus dem ERP oder Vertragsdaten aus dem vorhandenen Vertragsmanagement synchronisiert werden. Das Unternehmen muss entscheiden, ob mit nur einem zentralen Provider-Management-Tool und synchronisierten Daten gearbeitet wird oder ob mehrere Tools zur Unterstützung des Providermanagements zum Einsatz kommen.

Unternehmen agieren heute in einem Marktumfeld, welches komplexer und kompetitiver ist als jemals zuvor. Die stabile und sicher vorhersagbare Umwelt der vergangenen Jahrzehnte weicht einer digitalisierten Zukunft mit neuen Spielregeln.
In diesem Zusammenhang stellt sich insbesondere für Betriebe mit einem outgesourcten IT-Service die Frage, wie die bestehende interne Organisationsstruktur regelmäßig für die Zukunft ausgerichtet werden kann. Bei dem Review ihrer Sourcing Strategie konzentrieren sich Unternehmen häufig ausschließlich auf das IT-Outsourcing selbst, während die intern verbleibende Organisation häufig weniger Beachtung findet. Aus diesem Grund legen wir in diesem Artikel den Fokus auf die Gestaltung der intern verbleibenden Organisation bei betrachteten Sourcing-Szenarien.

Um eine Sourcing Strategie zum Erfolg zu führen, muss die interne Organisation eine effiziente Steuerung der Service Provider sowie eine reibungslose Zusammenarbeit aller an der Service-Bereitstellung Beteiligten sicherstellen. Hierfür ist vor jeder Outsourcing-Maßnahme die gesamte Organisation zu prüfen und zu bewerten. Für diese Bewertung müssen Antworten für folgende Fragen ermittelt werden:

• Wie kann das Unternehmen den Aufgabenkomplex IT-Service zukünftig optimal organisieren und aufbauen? Wie kann die aktuelle Organisationsstruktur verbessert werden?
• Ist eine Auslagerung an einen externen Provider bei bereits outgesourcten Services weiterhin sinnvoll und die bessere Alternative als eine interne Realisierung aller Aufgaben?
• Mit welchem Personal- und Budgetbedarfen ist bei den jeweiligen Organisationsoptionen zu rechnen? Welche Anforderungsprofile müssen dabei die Mitarbeiter*innen erfüllen?

Für die Beantwortung dieser Fragen bietet sich eine Überprüfung der bestehenden Sourcing Strategie an. Hierfür wird in der Regel ein methodisches Vorgehen in mehreren Schritten angewendet, wie es beispielhaft in Abbildung 1 dargestellt wird:

Abbildung 1: Review einer Outsourcing-Strategie

Im Folgenden wollen wir in den einzelnen Schritten eines Sourcing-Strategie-Reviews den Fokus auf die Fragen legen:

Schritt 1: Umfeldanalyse

Bei der Umfeldanalyse werden die definierten Ziele und Rahmenbedingungen für das IT-Outsourcing auf Aktualität reviewt und gegebenenfalls angepasst. In dem Rahmen wird auch geprüft, ob die Ziele von IT-Outsourcing weiterhin klar von der Unternehmens-Strategie abgeleitet sind. Aus ihnen werden Bewertungskriterien für verschiedene Outsourcing-Szenarien abgeleitet. Beispiele für Ziele sind in Abbildung 2 dargestellt:

Abbildung 2: Beispiele für Outsourcing-Ziele

Schritt 2: Aufnahme der Ist-Situation

In diesem Schritt wird eine Bestandsaufnahme der aktuellen Organisationsstruktur für die Bereitstellung aller IT-Services gemacht. Dies wird zum Beispiel mit Hilfe eines Organigramms bewerkstelligt. Häufig muss hierbei das bestehende Organigramm mit aktuellen oder fehlenden Informationen aktualisiert werden. Dabei wird die Organisation,
von der obersten Führungsebene des Unternehmens bis hin zu allen Abteilungen, welche mit in die Bereitstellung der IT-Services involviert sind, betrachtet. Um das notwendige Gesamtbild zu erhalten, sind auf dem Organigramm auch externe Service Provider, IT-Anwender und die Beziehungen zwischen den verschiedenen Abteilungen darzustellen. Anschließend werden die Zuständigkeiten der an der IT-Bereitstellung beteiligten Abteilungen ausführlich beschrieben.

Basierend auf dem aktualisierten Organigramm werden die für die Bereitstellung der IT-Services relevanten Aktivitäten und die dazugehörigen Aufwände aufgenommen. Als Rahmenwerk können Best-Practice-Frameworks wie ITIL und SIAM genutzt werden, um die relevanten Aufgabenfelder für die Bereitstellung der IT-Services zu identifizieren. Ihr Einsatz dient dazu, die Vollständigkeit der wahrzunehmenden Aufgabenfelder sicherzustellen.

Abbildung 3: Aufgabenfelder zur Bereitstellung der IT-Services

Die Aufgabenfelder werden in interne und externe aufgeteilt. Interne Aufgabenfelder beinhalten alle Aufgaben, die von der intern verbleibenden Organisation übernommen werden. Sie beinhalten die übergreifenden Aufgaben, das Providermanagement und interne IT-Services. Beispiele der übergreifenden Aufgaben sind in Abbildung 3 aufgelistet. Eine Identifikation der für die eigene Situation relevanten Aufgaben kann über Frameworks wie ITIL erfolgen. Auf Basis des amendos Frameworks 9PROFITS (s. Abbildung 4) können die Aufgabenfelder des Providermanagements abgeleitet werden. Die internen IT-Services umfassen alle Aufgaben des Betriebs dieser Services. Die externen Aufgabenfelder enthalten alle Aufgaben, welche von externen Dienstleistern (Service Providern,
Beratern, usw.) übernommen werden.

Basierend auf den Aktivitäten in den Aufgabenfeldern sind die Kosten für die Erbringung der Services zu ermitteln.

Abbildung 4: Aufgabenfelder von Providermanagement auf Basis von 9PROFITS

Schritt 3: Bewertung der Ist-Situation

Mit der Gegenüberstellung der in den Frameworks aufgeführten und den tatsächlich wahrgenommenen Aktivitäten entsprechend der Bestandsaufnahme wird schnell ersichtlich, welche Aktivitäten nur teilweise oder gar nicht wahrgenommen werden. Sich ergebende Gaps bei den Aktivitäten, aber auch die Spezifikation der Services, die bestehenden Prozesse, die eingesetzten Tools, die Schnittstellen zwischen den beteiligten Organisationen und die Bewertung der Provider werden auf Schwachstellen untersucht.

Anschließend erfolgt auf der Basis der identifizierten Schwachstellen eine Analyse der Ursachen. Daraufhin werden Maßnahmenpakete zur Beseitigung der Schwachstellen definiert. Die Kosten zur Realisierung der Maßnahmen werden dann entsprechend geschätzt und später in den Gesamtkosten zur Bereitstellung IT-Services berücksichtigt.

Schritt 4: Marktpotenzialanalyse

In diesem Schritt wird geprüft, wie der Markt potenziell extern zu erbringende Services anbietet. Hierbei wird analysiert, ob die entsprechenden IT-Leistungen am Markt wirtschaftlich und im geforderten Umfang zu beziehen sind. Auf Basis sinnvoller Service-Angebotszuschnitte kann anschließend abgeleitet werden, wie die interne Organisation aufgestellt werden muss.

Schritt 5: Strategiegestaltung

Unter Heranziehung strategischer Vorgaben und der Outsourcing-Ziele werden verschiedene Outsourcing-Szenarien mit passend gestalteter interner Organisationsstruktur gebildet und bewertet. Anschließend werden die Kosten sowie die Vor- und Nachteile für jedes Szenario ermittelt. Für die Szenarien werden dann auch die Anforderungsprofile für interne Teams und für externe Service Provider aufgestellt.

Anschließend werden die Szenarien einer Kosten-Nutzen-Analyse unterzogen.

Nur diejenigen Outsourcing-Szenarien werden weiter betrachtet, welche einen angemessenen Nutzen bei Einhaltung der vorgegebenen Kostenziele versprechen.
Diese werden dann einer Risikoanalyse unterzogen.
Die bisherige Bewertung der Outsourcing-Szenarien wird um die Ergebnisse der Risikoanalyse ergänzt.

Mit dem Ergebnis der Bewertung kann abschließend eine Gesamtempfehlung abgegeben werden. Für die erarbeitete Gesamtempfehlung ist im nächsten Schritt eine Entscheidung seitens des Managements einzufordern, ehe die Umsetzung geplant werden kann.

Fazit

Um eine bereits bestehende Organisation mit einem outgesourcten IT-Service für die Zukunft neu auszurichten, muss im Rahmen der Bestands- und der Schwachstellenanalyse die Organisationsstruktur und das Serviceumfeld durchleuchtet werden. Basierend auf den Ergebnissen und den Unternehmenszielen können verschiedene Outsourcing-Szenarien entwickelt und bewertet werden. Die Szenarien sollten hierbei die notwendigen Veränderungen in der Organisationsstruktur einbeziehen. Auf Basis der Bewertung der Szenarien kann eine Empfehlung abgeleitet werden, die dem Management eine fundierte Entscheidung ermöglicht. Bei der Umsetzung von Outsourcing-Maßnahmen sind als notwendig identifizierte Anpassungen der Organisationsstruktur frühzeitig zu planen und zu implementieren.

Public Cloud Services gelten als Extremvariante von IT-Outsourcing: Die sehr hohe Standardisierung ihrer Services ermöglicht den Cloud Service Providern, diese zu sehr attraktiven Preisen anzubieten. Unternehmen, die komplette IT-Services outsourcen (sogenannte Managed Services), haben allerdings eine geringere IT-Fertigungstiefe als Unternehmen, die nur Public Cloud Services beziehen. Letztere erbringen die nicht vom Cloud Service Provider übernommenen Aufgaben selbst. Im Folgenden betrachten wir die Gegenüberstellung “Cloud Services versus Managed Services”, d.h. ob und wann es vorteilhaft sein kann, einen zusätzlichen Service Provider für diese intern verbleibenden Aufgaben einzubinden und so auf Managed Service Niveau zu kommen.

Zunächst betrachten wir jedoch die Public Cloud Services und die mit dem jeweils gewählten Cloud-Servicemodell verbundenen Restaufgaben, die beim Kunden verbleiben. Als ausführlicheres Beispiel dient anschließend das Servicemodell „Infrastructure as a Service (IaaS)“.

Leistungsinhalte bei Public Cloud Services

Cloud Service Provider bieten Kunden mit ihren Public Cloud Services geteilte Computer-Ressourcen als Dienstleistung, in Form von Servern, Datenspeicher oder Applikationen an. Der Kunde kann den Service entsprechend seinem tatsächlichen Bedarf skalieren, der Service wird nach tatsächlicher Nutzung abgerechnet. Der Service ist für alle Kunden jeweils identisch und kann in der Regel über ein Serviceportal vom Kunden eingerichtet, abgerufen und überwacht werden.

Verbleibende Kundenaufgaben

Hier beginnt die Arbeitsteilung: Für alle Kunden gleiche Servicebestandteile werden vollständig vom Cloud Service Provider übernommen, alles Kundenspezifische ist vom Kunden selbst zu „administrieren“. Das ist – abhängig vom Servicemodell und konkreten Service – wenig oder mehr Aufwand für den Kunden und die erforderlichen Arbeiten erfordern wenig oder mehr Expertise. Bei den drei klassischen Cloud Servicemodellen sieht die Arbeitsteilung grob wie folgt aus:

Bei Infrastructure as a Service (IaaS) wird die IT-Infrastruktur wie Computer (virtuelle oder dedizierte Hardware), Netzwerke und Speicher über das Internet bereitgestellt und vom Service Provider betrieben. Der Kunde übernimmt die Einrichtung „seiner“ Server und Storage-Bereiche und betreibt die darauf installierte Software.

Bei Platform as a Service (PaaS) stellt der Service Provider das Infrastruktur- und Software-Framework bereit und betreibt es. Der Kunde entwickelt darauf seine Anwendungen, lässt sie hier ausführen und betreibt diese.

Bei Software as a Service (SaaS) wird die Anwendung vom Service Provider auf seiner eigenen Infrastruktur bereitgestellt und verwaltet. Der Kunde richtet User-Accounts, Berechtigungen und Schnittstellen zu anderen Anwendungen ein.

In der folgenden Abbildung werden die Verantwortlichkeiten von Service Provider und Kunde bei den verschiedenen Cloud Servicemodellen dargestellt. Bei allen Servicemodellen muss der Kunde neben seinen eben skizzierten „Restaufgaben“ zusätzlich die Aufgaben des Providermanagements übernehmen.

Abbildung 1: Verantwortlichkeiten bei Cloud-Servicemodellen

Kundenaufgaben am Beispiel IaaS

Am Beispiel IaaS schauen wir uns die verbleibenden Kundenaufgaben einmal genauer an. Die betriebsbezogenen „Restaufgaben“ umfassen insbesondere:

• Verwaltung des Gastbetriebssystems (einschließlich Updates und Sicherheitspatches) und jeglicher Anwendungssoftware oder Dienstprogramme, die vom Kunden installiert werden
• Konfiguration der vom Provider bereitgestellten Firewall
• Datenverwaltung und Verschlüsselung
• Datensicherung und Recovery-Maßnahmen
• Benutzer- und Zugriffsverwaltung
• Risikomanagement

Neben dem Ansatz, Public Cloud Services mit eigenem Restaufgabenanteil einzusetzen gibt es jedoch auch noch die Möglichkeit, alle mit einem Cloud-Service anfallenden Aufgaben nach außen zu vergeben (Managed Services). Dies würde bedeuten, dass ein weiterer Service Provider die Restaufgaben für den Kunden erbringt und letzterer nur noch das Providermanagement übernimmt. Diese beiden Optionen stellen wir im folgenden Abschnitt am Beispiel IaaS gegenüber (Cloud Services versus Managed Services).

Vergleich Cloud Services versus Managed Services (IaaS + Restaufgaben und IaaS + ergänzende Services)

Zunächst werfen wir einen Blick auf die Gesamtkosten der beiden Optionen: Die Gesamtkosten bei der Option „IaaS + Restaufgaben“ teilen sich in drei Teile:

• externe Servicekosten für IaaS,
• interne Kosten für Kunden-seitige Restaufgaben und
• interne Kosten des Providermanagements.

Die internen Aufgaben erfordern ein angemessenes Fachwissen, das bei vielen Unternehmen zunächst nicht vorhanden ist. Zwar gestaltet es sich relativ einfach, mit einigen wenigen Diensten zügig loszulegen. Ein optimaler Einsatz von Cloud Services aber, der auch innovative Services, Best Practices, Sicherheit, Compliance und das Kosten-Management berücksichtigt, ist für viele IT-Organisationen eine große Herausforderung: Intern müssen hierfür erst einmal Kompetenzen und Ressourcen aufgebaut werden.

Der Aufwand im Providermanagement ist deutlich niedriger als bei klassischem Outsourcing, denn es gibt kaum einen persönlichen Kontakt zum Provider. Dies ist auch nicht erforderlich, da IaaS ein für alle Kunden gleicher Standardservice ist und keine Kunden-individuellen Leistungen erbracht werden. Providermanagement-Aufgaben konzentrieren sich deswegen im Wesentlichen auf Vertragsmanagement, Security und Compliance Management, Performance Management und Finanzmanagement.

Bei der Option „IaaS + ergänzende Services“ übernimmt ein ergänzender Service Provider die Kunden-seitigen Restaufgaben. Er kann zudem die operative Steuerung des IaaS-Providers übernehmen. Dadurch entstehen insgesamt höhere externe Servicekosten. Der Aufwand und damit die Kosten im Providermanagement steigen ebenfalls, da der externe Gesamtservice jetzt „kundenspezifisch“ wird und damit besser mit dem internen Servicemanagement zusammenspielen muss.

Abbildung 2: Vergleich der Kostenkomponenten der beiden Optionen

Vorteile der Option „IaaS + ergänzender Service“:

+ geringe Fertigungstiefe (vergleichbar mit anderen Managed Services)

+ kein internes Betriebs-Know-how mehr erforderlich

+ Nutzung der Kernkompetenz und Erfahrung eines spezialisierten Service Providers

+ höhere Kostentransparenz durch externe Abrechnungsstrukturen

Nachteile der Option „IaaS + ergänzender Service“

– zwei Provider erhöhen gegebenenfalls die Komplexität

– Abhängigkeit vom ergänzenden Service Provider, da das Betriebs-Know-how intern nicht mehr vorhanden ist

– anspruchsvolleres und aufwändigeres Providermanagement

Gesamtbewertung

Bei Outsourcing ist die Option „IaaS + ergänzende Services“ gegenüber der Lösung „IaaS + interne Restaufgaben“ die einheitlichere, wenn Unternehmen die Strategie verfolgen, IT-Services komplett outzusourcen und nicht nur Teilaufgaben eines IT-Services extern erbringen lassen: So wird eine einheitliche (und geringe) Fertigungstiefe sichergestellt. Ob diese Alternative wirtschaftlicher ist, hängt von den Rahmenbedingungen im Unternehmen und insbesondere vom Reifegrad des Providermanagements ab.

Der Erfolg der Steuerung externer Service Provider hängt wesentlich von der Gestaltung der Toolunterstützung ab: Zuständige Mitarbeiter benötigen den einfachen und schnellen Zugriff auf alle relevanten Informationen. In der Praxis wird häufig ein Sammelsurium an Tools eingesetzt. Dadurch entstehen Schwachstellen, die zur Ineffektivität und Reibungsverlusten bei der Providersteuerung führen. In diesem Beitrag wird eine beispielhafte Möglichkeit vorgestellt, diese Schwachstellen zu minimieren.

Die eingesetzte Toollandschaft soll alle Prozesse unterstützen, um externe IT-Services über den gesamten Outsourcing-Lebenszyklus zu managen, zu monitoren und zu bewerten. Diese Prozesse sind insbesondere: Vertragsmanagement, Performance Management, Beziehungsmanagement, Risikomanagement, Changemanagement, Providerbewertung, Compliance Management, Continual Improvement.

Abbildung 1: Providersteuerungsprozesse

Beispielaktivitäten und typischer Tooleinsatz

Die Rolle des Providermanagers ist je nach Rollenfestlegung an vielen dieser Prozesse beteiligt. Beispielaktivitäten in den Prozessen und für die jeweils verwendeten Tools sind:

Rechnungsprüfung und Budgetüberwachung:

Im Rahmen des Prozesses Finanzmanagement prüft der Providermanager alle Rechnungen auf Vollständigkeit. Er gibt sie frei, wenn sie korrekt sind. Bei Unstimmigkeiten werden Rückfragen an den Provider gestellt. Weiterhin überwacht er den Status der Rechnungen und die relevanten Budgets (inkl. Forecasting). Für seine täglichen Aktivitäten braucht der Providermanager eine Momentaufnahme von folgenden Informationen:

• Budget: Sollbudget, IST-Ausgabe und Budget-Forcast
• Rechnungsprüfung: Budgetname, Rechnungsdatum, Rechnungsname, Rechnungsstatus, Rechnungsbetrag
• Service-Vertrag und Service-Reports: abzurechnende Mengen, Pauschalen, Einzelpreise, Rabatte, Skonti etc.

Tools zur Bereitstellung dieser Informationen sind zum Beispiel das eigene ERP-System, ein Vertragsmanagement-System und eine Datei-Ablage.

SLA-Reports prüfen:

Bei dem Prozess Performance Management prüft der Providermanager die SLA-Kennzahlen auf Plausibilität, Richtigkeit und darauf, ob das SLA erfüllt wurde. Der Provider stellt ihm dafür periodisch SLA-Reports zur Verfügung. In den regelmäßigen Governance-Meetings bespricht der Providermanager die Ergebnisse der SLA-Prüfung mit dem Provider. Bei SLA-Verletzungen werden Maßnahmen diskutiert und vereinbart. Der Providermanager kann zudem die vertraglich festgelegten Strafen einfordern.

Um diese Aktivität auszuführen, braucht er zusätzlich zu dem SLA-Report mit Ist- und Zielwerten, die SLA-Rahmenbedingungen aus dem Vertrag. Diese Informationen sind häufig wieder in Vertragsmanagementsystemen oder Dokumentenablagen gespeichert.

Risiken überwachen:

Im Prozess Risikomanagement werden die Risiken im Risikoregister in regelmäßigen Abständen überprüft und die Umsetzung der zu ergreifenden Maßnahmen sowie deren Status überwacht. Der Providermanager behält stets den Status der Risiken im Blick.

Für diese Aktivitäten kommen meisten Excel-Dokumente und zentrale Datei-Ablagen zum Einsatz.

Schwachstellen

Der Einsatz von diversen verschiedenen und unverbundenen Tools zur Steuerung des Providers hat Schwachstellen zu Folge. Diese wiederum führen zur Ineffektivität und Reibungsverlusten bei der Providersteuerung. Typische Schwachstellen sind:

Zugangsrestriktionen zu Systemen:

Häufig kann der Providermanager nicht direkt auf Informationen in verschiedenen Systemen zugreifen, weil er keine Zugriffsberechtigung hat. Gute Beispiele hierfür sind Vertragsmanagement-Systeme, die beim Einkauf angesiedelt sind. Der Providermanager muss in solchen Fällen die nötige Information über Drittpersonen einholen.

Redundante Datenhaltung:

Der Providermanager braucht für seine tägliche Arbeit Daten aus vielen Systemen, die er sich manchmal mühselig zusammensuchen muss. Um der Sucherei zu entgehen, fängt er an, sich Daten auf einer eigenen Datei-Ablage abzulegen. Dadurch entsteht das Risiko der Dateninkonsistenz zwischen den Datei-Ablagen und Systemen.

Fehlende Systemschnittstellen:

Wegen fehlender Schnittstellen zwischen den Systemen können bei teilweise redundanter Datenhaltung ebenfalls Dateninkonsistenzen entstehen.

Zeitintensiver Zugriff auf Informationen:

Ad hoc Informationen müssen mühsam manuell aus den Systemen oder Dokumenten zusammengesucht werden. z.B.:

• Termine im Kalender oder in der Datei-Ablage abgespeicherte Protokolle: Wann finden welche Gremienmeetings statt? Mit welchen Beteiligten?
• Fristen in den Verträgen (Vertragsmanagement-System): Kündigungsfristen, Verlängerungsfristen, Abwicklungsfristen usw.
• Ansprechpartner und Rollen beim Provider in der Datei-Ablage
• Aktionsstatus im Kollaborationstool
• SLA-Vorgaben mit Vertragsstrafen in den Verträgen (Vertragsmanagement-System)

Verbesserungsansatz

Es zeigt sich, dass für die Providersteuerung eine Menge an Informationen aus verschiedensten Tools notwendig sind. Entsprechend ist es wichtig, den Mitarbeitern die wesentlichen Informationen konsolidiert und vereinfacht an einem Ort bereitzustellen. Ein Weg dies zu erreichen ist, mit Hilfe eines Tools wie SharePoint einen zentralen Zugang zu allen relevanten Informationen für die Providersteuerung zu schaffen.

SharePoint ist webbasiert und erlaubt es, die Bereitstellung von Informationen nach den eigenen Bedürfnissen zu konfigurieren. Wesentliche Informationen zur Datenanalyse und Steuerung der Provider können in SharePoint abgelegt und dargestellt werden. Sie können dabei untereinander verknüpft werden. Weiterhin besteht die Möglichkeit, die jeweils erforderlichen Daten über ein flexibles Berechtigungskonzept den verschiedenen Beteiligten entsprechend ihrer jeweiligen Rolle transparent zur Verfügung zu stellen. Detaillierte Informationen können zudem über eine Verlinkung zu den relevanten Systemen (ERP-System, ITSM-System, Vertragsmanagement-System) bereitgestellt werden. Dabei ist es möglich, die Informationen mit den Daten aus den Originalsystemen automatisch abzugleichen.

Abbildung 2: Providersteuerungssystem basierend auf SharePoint

SharePoint bietet die Option, wesentliche Informationen aus allen Bereichen mittels eines Dashboards darzustellen. Dies kann als Einstieg in die verschiedenen Bereiche dienen. In unserem Beispiel mit dem Providermanager sind es die Bereiche für Performance Management, Finanzmanagement, Beziehungsmanagement und Risikomanagement.

Im Risikomanagement-Bereich können das Risikoregister und die Risikostammdaten direkt eingepflegt werden. Der Risikostatus der Services kann automatisch ermittelt und dargestellt werden. Der Providermanager kann sich so zu jeder Zeit einen Überblick über den aktuellen Risikostatus jedes einzelnen Services verschaffen.

Finanzdaten (i.d.R. auch Budgets und Rechnungen) sind alle im ERP-System. Zusätzlich sind aber für die Rechnungsprüfung SLA- und Vertragsdaten (Abrechnungspositionen, Pauschalen, zu erreichende Service Level Zielwerte, Vertragsstrafen etc.) erforderlich. Diese können aus dem im Vertragsmanagement-System abgelegten Verträgen extrahiert und direkt in SharePoint bereitgestellt werden.

Die periodischen SLA-Reports vom Provider können automatisch in den Performancemanagement-Bereich eingepflegt werden. Dies bietet die Möglichkeit, die SLA-Vorgaben, ebenfalls automatisch, direkt mit den Reports zu vergleichen und zu visualisieren. Eine Verlinkung zu Maßnahmen bei SLA-Verletzungen in das Vertragsmanagement-System ist ebenfalls möglich. Die schnelle Prüfung der SLA-Reports fällt dem Providermanager somit leichter.

Abbildung 3: Beispielhafte SharePoint-Lösung für den Providermanager

Fazit

Mit der Bereitstellung aller wesentlichen Informationen zur Providersteuerung an einem Ort spart der Providermanager viel Zeit. Die aufwendige Suche nach Informationen entfällt. Das flexible Berechtigungskonzept stellt sicher, dass nur berechtigte Personen Zugriff auf die für sie jeweils relevanten Daten haben. Der Providermanager ist stets gut informiert und kann schnell auf negative Entwicklungen reagieren. Dies untermauert sein kompetentes Auftreten und sicheres Standing gegenüber Management und Providern.

Wenn Unternehmen ihre IT-Services an mehrere Service Provider outsourcen, hängt der Erfolg des IT-Gesamtservices wesentlich von der effektiven Steuerung der externen Service Provider ab. Mit sich ständig weiterentwickelnden Liefermodellen wie Cloud und „As-a-Service“ und immer zahlreicheren Serviceangeboten ist die Fähigkeit, den ständigen Wandel zu überwachen, von entscheidender Bedeutung. In dieser Situation kommt einer effizienten Toolunterstützung eine Schlüsselrolle zu: Bei der Providersteuerung müssen in jeder Situation die jeweils erforderlichen Informationen einfach abrufbar sein. Bessere Providersteuerung durch Toolunterstützung kann nur so erreicht werden.

Ausgangspunkt Governance

Governance-Regeln setzen in vielen Unternehmen feste Regeln für die Providersteuerung. In Branchen wie dem Finanzsektor oder dem KRITIS-Sektor werden hierfür zudem klare Regulierungsvorgaben gegeben, die im eigenen Unternehmen beim Outsourcing umzusetzen sind. Hierbei entstehen Daten, Dokumentationen und Informationen. Die Kombination dieser Daten ist umso komplexer, je mehr Services an unterschiedliche Provider outgesourct werden. Diese Daten und Informationen müssen dem Mitarbeiter ad hoc bereitstehen, um mit Providern schnell und auf Augenhöhe zu interagieren.

Typische Situation in Unternehmen

Viele Unternehmen steuern ihre Provider mit Unterstützung einer nur geringfügig oder nicht an den Bedarf des Providermanagements angepassten Toollandschaft. Häufig sind nicht alle relevanten Informationen in dieser Toollandschaft gespeichert. Einige dort gespeicherte Informationen sind zudem für einige Mitarbeiter in der Providersteuerung nicht einfach oder gar nicht zugänglich, Abhängigkeiten zwischen Informationen nicht immer transparent oder toolseitig unterstützt. Grund hierfür sind oftmals fehlende Schnittstellen zwischen den eingesetzten Tools.

Der Mitarbeiter im Providermanagement muss also in vielen Fällen wissen, welche Informationen über welches Tool bereitgestellt werden und sich dann die für eine konkrete Situation erforderlichen Informationen mühsam manuell zusammensuchen. All dies führt dazu, dass er nicht effizient arbeiten kann, weil ihm nicht alle Daten vorliegen, die er für seine Aufgabe in einer konkreten Situation benötigt.

Wie geht es besser?

Im Providermanagement besteht also der Bedarf nach einer Toollandschaft, die die Möglichkeit bietet, alle relevanten Informationen zur Datenanalyse und Steuerung der Provider abzulegen. Die abgelegten Informationen sollen dabei untereinander verknüpft sein. Weiterhin sollen die jeweils erforderlichen Daten über ein flexibles Berechtigungskonzept den verschiedenen Beteiligten entsprechend ihrer jeweiligen Rolle transparent bereitgestellt werden. Die Anwenderzielgruppe umfasst Providermanager und weitere Stakeholder, die intern Rollen im Providermanagement und Outsourcing wahrnehmen. Dies sind zum Beispiel die Geschäftsführung, der Einkauf, die Rechtsabteilung, Buchhaltung, das Controlling sowie extern die Service Provider und die Kunden. Der Provider als externer Stakeholder soll die Möglichkeit haben Servicedaten, wie zum Beispiel KPIs, einzupflegen, aber auch auf gemeinsame Dokumente wie Protokolle und Vorgaben zugreifen zu können. Die Einbindung von Kunden ist unter anderem bei toolbasierten Umfragen für die Ermittlung der Kundenzufriedenheit wichtig.

Abbildung 1: Stakeholder

Die Toollandschaft soll alle Prozesse unterstützen, um IT-Services über den gesamten Outsourcing-Lebenszyklus zu managen, zu monitoren und zu bewerten. Diese Prozesse sind insbesondere:

• Vertragsmanagement
• Performance Management
• Beziehungsmanagement
• Risikomanagement
• Changemanagement
• Providerbewertung
• Compliance Management
• Continual Improvement.

Diese Liste hat keinen Anspruch auf Vollständigkeit. Sie hängt vom Unternehmen und den für die jeweilige Outsourcing-Situation als relevant bewerteten Managementprozessen ab.

Doch wie kommt ein Unternehmen zu einer der eigenen Outsourcing-Situation angemessenen Toollandschaft? Im Folgenden wird vorausgesetzt, dass die relevanten Prozesse einen angemessenen Reifegrad erreicht haben: Sie sind in der Organisation etabliert und vorhersagbar (Level 4 gemäß ISO 15504). Erst dann ist die Schaffung einer integrierten Toolunterstützung in Betracht zu ziehen.

Folgendes Vorgehen zur Realisierung einer integrierten Toollandschaft hat sich in der Praxis bewährt:

1. IST-Analyse vorhandener Tools

Eine IST-Analyse ist notwendig, um den aktuellen Stand der Toollandschaft zu ermitteln. Die Dokumentation der für die Providersteuerung relevanten Prozesse wird ausgewertet und die Toolunterstützung für die einzelnen Aktivitäten je Prozess aufgelistet. Die Schnittstellen zu den externen Stakeholdern werden ebenfalls aufgenommen.

2. Schwachstellenanalyse der Toollandschaft

Bei der Schwachstellenanalyse wird der IST-Stand der Toolunterstützung auf Aspekte untersucht, die zur Verschlechterung oder Verlangsamung der Abläufe führen.

Schwachstellen bei der Toollandschaft können u.a. die folgenden sein:

• fehlende Funktionen
• mangelnde Performance
• Dateninkonsistenz aufgrund redundanter Datenhaltung in verschiedenen Tools
• manuelle oder fehlende Schnittstellen zwischen Tools
• mangelhafte Benutzerfreundlichkeit
• fehlende Zugriffsrechte.

Grundsätzlich ist zu hinterfragen, ob den Mitarbeitern im Providermanagement alle nötigen Informationen schnell und einfach zugänglich sind.

3. Soll-Konzept erstellen

Basierend auf den Ergebnissen der Ist- und Schwachstellenanalyse erfolgt die Erstellung eines Konzepts, um die identifizierten Lücken Schritt für Schritt zu schließen. In diesem Rahmen wird eine iterative Erarbeitung des Soll-Zustands vorgenommen. Folgende Schritte sind u.a. zu beachten:

• Erstellen eines Daten-Modells auf Basis der Prozesse
• Konzeption der Soll-Toollandschaft:
  • Entscheidung, ob bestehende Tools erweitert oder abgelöst werden sollen
  • Prüfen, ob und für welche Funktionen ergänzende Tools zu schaffen sind
  • Festlegung von Rollen und Verantwortlichkeiten in den Tools
  • Bestimmung wie die Schnittstellen zwischen den Tools (manuell, teilautomatisiert oder voll automatisiert) realisiert werden sollen
  • Berechtigungskonzept erstellen
• Kostenanalyse
• Dokumentation der Ergebnisse
• Prüfen der Schwachstellenbeseitigung.

Es ist wichtig, die Provider bei der Konzipierung einzubeziehen. Denn insbesondere die Schnittstelle zur Übertragung von SLA-Reporting-Daten aus der Providerumgebung muss gewährleistet werden.

4. Implementierung

Die Einführung der entstehenden Änderungen aus dem Soll-Konzept kann nur durch eine ganzheitliche Planung, eine unterstützende Kommunikation und Schulungen erfolgreich durchgeführt werden. Dabei ist zu überlegen, ob eine Einführung stufenweise, mit Big Bang oder über eine Pilotierung erfolgt.

Fazit – Bessere Providersteuerung durch Toolunterstützung

Bessere Providersteuerung durch Toolunterstützung ist nur zu erreichen, wenn die Voraussetzung erfüllt ist, dass die zu unterstützenden Prozesse eine angemessene Reife aufweisen. Die zu schaffende Toollandschaft muss die Schwächen, welche Kosten sowie einen Zeit- und Qualitätsverlust in den Prozessen verursachen, beseitigen. Eine derartige, ganzheitlich strukturierte Toolunterstützung ermöglicht dann auch eine reibungslose Steuerung der Provider auf Augenhöhe: Der Mitarbeiter hat sofort Zugriff auf alle relevanten aktuellen Daten, um seine Aufgaben zu erledigen. Dies spart langfristig Zeit und Kosten. Zudem stärkt es die Position gegenüber dem Provider in allen Situationen des Tagesgeschäfts.

Auftraggeber kennen die Situation: IT-Services wurden an einen externen Provider outgesourct. Die Abnahme der IT-Services in der Transitionsphase läuft jedoch nicht reibungslos ab. Typische Schwachstellen sind fehlende Dokumentation, unzureichende Personalressourcen, fehlende Messgeräte und insbesondere vom Provider vorab nicht ausreichend getestete Serviceleistungen. Wir zeigen auf, wie man durch erfolgreiche Abnahmen in der Transition Reibungsverluste bvermeiden und  die geplanten Ergebnisse sicherstellen kann.

Bei der Abnahme identifizierte Schwachstellen führen in der Regel zu einer Verzögerung ersterer. Im schlimmsten Fall wird sie abgebrochen, weil die Funktionalität der Services nicht vollständig nachgewiesen werden kann. Werden Abnahmen abgebrochen oder nur teilweise freigegeben, müssen zusätzliche Abnahmetermine geplant werden. Dies verursacht sowohl für den Auftraggeber als auch für den Provider erhebliche Kosten.

Gründe für eine unvollendete Abnahme sind insbesondere:

• Keine klar definierten Abnahmekriterien vor der Vergabe des Auftrags
• Der Provider unterschätzt den Aufwand zur Abnahme der Services und kann daher die notwendigen Ressourcen für die Abnahme nicht bereitstellen.
• Kein angemessenes Konfigurationsmanagement gemäß ITIL

Wie kann man solche Situationen vermeiden und bei Outsourcing erfolgreiche Abnahmen in der Transition sicherstellen? In diesem Artikel möchte ich Wege und Methoden hierfür aufzeigen. Dabei werde ich mich auf wesentliche Punkte, die bei der Abnahme kritisch sind, konzentrieren.

Der Outsourcing-Lebenszyklus besteht aus den Phasen Strategie, Konzeption, Vergabe, Transition und Betrieb. Der Grundstein für eine erfolgreiche Abnahme in der Transition wird in der Vergabephase des Outsourcings gelegt. Von Anfang an sollten, unter Berücksichtigung von unternehmensweiten Richtlinien (z.B. Qualitätsrichtlinien), Vorlagen und Change-Management-Vorgaben, die Rahmenbedingungen für die Abnahme festgelegt werden. Um dies zu realisieren, müssen in der Ausschreibung die Abnahme-Verantwortlichkeiten ebenfalls klar und eindeutig formuliert sein.

Die Abnahme im Outsourcing-Lebenszyklus unterteilt sich in drei Arbeitsschritte:

1. Erstellung der Teststrategie

ITIL definiert die Teststrategie als den Gesamtansatz zur Organisation von Tests und der Zuweisung von Testressourcen. In der Vergabephase erstellt der Provider im Rahmen des Angebots die Teststrategie gemäß den Vorgaben der Ausschreibung. Die erforderlichen Aktivitäten sind u.a.:

• Umsetzung des Servicekonzepts aus dem Service Design in Testanforderungen und Testmodelle (Testplan, Testprozeduren, Liste der Testelemente, Skripte, usw.)
• Definition der notwendigen Teststufen (Komponententest, Integrationstest, usw.)
• Definition der akzeptablen Fehlerquote bei jeder Teststufe (Pass/Fail-Kriterien) sowie Abbruch- und Neustartkriterien
• Abstimmung des Abnahmeverfahrens
• Klärung der Verantwortlichkeiten bei der Abnahme
• Definition der Lieferergebnisse
• Auflistung der Rollenanforderungen bei der Abnahme

Der Auftraggeber überprüft die Teststrategie auf Vollständigkeit und die Rückverfolgbarkeit der Testanforderungen zurück bis zu den Service-Design-Kriterien.

Jedes Unternehmen hat unterschiedliche Einstellungen zum Risiko hinsichtlich der Servicequalität. Diese Risikobereitschaft hat Einfluss auf den Grad und das Niveau der Validierung und der Tests. Je nach Risikobereitschaft kann der Auftraggeber eine Anpassung der Teststrategie fordern. Ziel ist es, dass eine gemeinsame Vereinbarung zur Abnahme der Services zwischen dem Auftraggeber und dem Provider getroffen wird. Die Teststrategie wird ein Teil des Vertrags.

Wenn Serviceänderungen vereinbart werden und zu Vertragsanpassungen führen, sind die Abnahmeverfahren mit entsprechendem Vorlauf anzupassen.

2. Meldung der Abnahmebereitschaft durch den Provider

Um Reibungsverluste während der Abnahme in der Transitionsphase zur vermeiden, sollte vorher eine Abnahmebereitschaftsprüfung durch den Auftraggeber durchgeführt werden. Diese Prüfung stellt sicher, dass alle notwendigen Vorarbeiten, um eine Abnahme starten zu können, korrekt erledigt sind.

Gemäß aktuellem Projektplan meldet der Provider die Abnahmebereitschaft der Serviceleistung an den Auftraggeber. Die Voraussetzungen zur Meldung der Abnahmebereitschaft

sollten schon im Vertrag definiert sein. Der Provider liefert, wie in dem im Vertrag spezifizierten Abnahmeverfahren vereinbart, die relevante Dokumentation.

Die Dokumentation umfasst abhängig von der Leistungsart z.B.:

• Lieferscheine
• Garantienachweise
• Konfigurationsliste(n)
• Netzwerkpläne
• Ausgeführte / ausgefüllte Checkliste(n) oder Test-protokolle
• Betriebshandbuch
• Schulungsunterlagen

Abbildung 1: Arbeitsschritte der Abnahme im Outsourcing-Lebenszyklus

Im Rahmen der Abnahmebereitschaftsprüfung überprüft der Auftraggeber die Dokumentation auf Vollständigkeit und Richtigkeit. Gegebenenfalls kann es mehrere Rückfragen an den Provider geben. Anschließend bestätigt der Auftraggeber die Abnahmebereitschaft. Bei unvollständiger Lieferung gegenüber den Vorgaben wird die Abnahmebereitschaft abgelehnt und der Provider aufgefordert, die offenen Punkte zu schließen. Je nach Situation kann die Abnahmebereitschaft unter der Bedingung bestätigt werden, dass der Provider die Mängel bis zum Start der Abnahme beseitigt. Es ist wichtig, genug Zeit für die Prüfung der Dokumentation sowie eine Nachbearbeitungszeit zur Beseitigung der Mängel vor der Abnahme einzuplanen.

3. Abnahme durch den Auftraggeber und Erklärung der Abnahme

Die Organisation der Abnahme erfolgt durch den Provider. Er stellt sicher, dass die Infrastruktur für die Durchführung der Abnahme geschaffen wird und alle Teilnehmer rechtzeitig die relevanten Informationen bekommen.

In der Abnahme führt der Provider dem Auftraggeber die im vereinbarten Abnahmeverfahren festgelegten Testprozeduren vor. Mängel, die durch zusätzliche, nicht vorab definierte Tests auftreten, dürfen nicht zu einem Abnahmeabbruch führen, es sei denn, die Auswirkungen der Mängel sind durch ihre Art oder Zahl so schwerwiegend, dass der Service erheblich beeinträchtigt wird.

Der Provider muss nach der Abnahme die Möglichkeit der Mängelbeseitigung innerhalb einer realistischen Frist bekommen, auf die man sich gemeinsam bei der Abnahme einigt. Die Ergebnisse der Abnahme sind zu protokollieren und identifizierte Fehler sind unter Angabe von Fehlerbild, Fehlerklasse, weiterem Verfahren und Zuständigkeit aufzulisten.

Die Abnahme endet mit einer Abnahmeerklärung durch den Auftraggeber mit oder ohne offene Fehler oder mit einem Abnahmeabbruch gemäß vertraglich definierten Abbruchkriterien. Der Provider verpflichtet sich, die Fehler fristgemäß zu beseitigen. Empfehlenswert ist es, den größten Zahlungsmeilenstein vertraglich auf eine erfolgreiche Abnahme zu legen. Ansonsten ist der Motivationsdruck auf den Provider nicht aufrecht zu halten.

Fazit: Outsourcing – erfolgreiche Abnahmen in der Transition

Durch die strukturierte Herangehensweise und die Abnahmekriterien – beides wird im Vertrag aufgenommen ist sichergestellt, dass der Provider eine ausführliche Betrachtung der zu erwartenden Aufwände vornimmt. Mit der Einführung der Abnahmebereitschaftsprüfung wird gewährleistet, dass alle Voraussetzungen (z.B. Konfigurationsmanagement, Dokumentation und vorbereitende Tests durch den Provider) für eine reibungslose Abnahme vorliegen. Es ist wichtig, die Aktivitäten der Abnahme im Projektplan darzustellen und regelmäßig zu aktualisieren. Weiterhin ist es empfehlenswert, eine Abnahme in mehreren Schritten und so früh wie möglich zu planen, um rechtzeitig Mängel zu entdecken, damit diese in späteren Teilabnahmen dann nicht mehr auftreten. Eine saubere Abnahme von Serviceleistungen sichert zudem die Service-Qualität in der späteren Betriebsphase.