MENU

SIAM – Das Service Integration Modell im Multiprovider Umfeld

Veröffentlicht am von Allgemein, Cloud Computing, IT Governance, ITIL

Traditional IT

Traditional IT

Alles aus einer Hand, das war einmal: eine zentrale IT-Organisation, welche das Datacenter noch selber betreibt, die Applikationen grösstenteils selber entwickelt und die Systeme und Netzwerke auch eigenständig wartet. Klar, externe Unterstützung insbesondere im Hardware- oder Betriebssystem-Umfeld war immer schon ein wichtiger und fester Bestandteil eines IT Betriebskonzepts. Aber die Kontrolle, was wann wo und vor allem auch durch wen genau gemacht wird, war in fester, interner Hand. Der Zugriff von aussen auf Daten und Systeme konnte man relativ gut einschränken und die Sicherheit war mit einem guten Firewall- und Netzonenkonzept sowie einem regelmässig aktualisierten Virenscanner sowohl für den Sicherheitschef wie auch der internen und externen Revision mehr als genügend. Das IT Service Management System auf Basis von ITIL® basierte auch mehrheitlich darauf, dass man intern „unter sich“ ist und die externen Lieferanten mittels gemanagtem „Underpinning Contract“ gut im Griff hatte.

nkontrollierte Shadow-IT

Unkontrollierte Shadow-IT

Die Erde hat sich bekanntlich gedreht: Mehr und mehr werden IT-Leistungen eingekauft und auf etablierte Standards gesetzt. So lange sich klar abgrenzbare Leistungsbereiche bilden lassen und ein Outsourcing-Partner den Service „ganzheitlich“ mit überschaubaren technischen und organisatorischen Schnittstellen erbringen kann, funktioniert dies in aller Regel auch recht gut. Mit dem starken Aufkommen von Cloud-Services bringt die gewonnene Flexibilität aber auch eine stattliche Komplexität mit sich. End-to-End Services setzen sich aus einer Vielzahl von teils dynamisch zu- und abschaltbaren Service-Komponenten zusammen und werden von den unterschiedlichsten Lieferanten bereitgestellt. Diese Lieferanten selbst stützen sich ebenfalls immer mehr auf weitere Unterlieferanten ab, damit jeder in der Service-Kette nur noch den eigene Mehrwert selbst erbringt, der sich ökonomisch rechtfertigt. Ohne klare Weisungen und Strategien werden einfache Cloud-Services aufgrund der tiefen Kosten von Fachabteilungen relativ eigenständig und ohne grosse Bedenken eingekauft und genutzt (Shadow IT). So manch ein Security Officer war nach einer gezielten Bestandsaufnahme verblüfft erkennen zu müssen, wie viele Dienste im eigenen Unternehmen ohne seine Kenntnis und Kontrolle genutzt werden. Nicht das keine Verträge mit den Lieferanten zustande gekommen wären – dies sind oft per Mausklick und durch blindes Akzeptieren der allgemeinen Geschäftsbedingungen rechtsgültig endstanden. Ob  und wie die Einhaltung der gesetzlichen und geschäftlichen Compliance-Vorschriften eingehalten werden, lässt sich dabei nicht wirklich kontrollieren und noch weniger nachvollziehen.

overnance un Management im Cloud Umfeld

Governance un Management im Cloud Umfeld

Aber auch wenn die Nutzung von externen IT-Dienstleistungen und Cloud-Services auf Basis einer klaren Strategie und unter strikter Überwachung der Sicherheitsanforderungen umgesetzt wird, bleiben grössere Herausforderungen bei der verbleibenden internen IT-Organisation (Retained IT-Organisation). Wir haben bereits mehrfach in diesem Blog auf die Auswirkungen und veränderten Anforderungen mit dem Aufkommen von Cloud Computing hingewiesen (Wandel von der IT-Abteilung zum Service Broker, The role of a Service Owner in the era of Cloud Computing). Da die Bereitstellung der Services immer weniger intern erbracht wird, sind entsprechende Skills und Fertigkeiten weniger gefragt. Dafür nehmen in einem professionellen Umfeld die Anforderungen hinsichtlich Sourcing-Management, Informations- und Cyber-Security sowie die Compliance-Überwachung stark zu. Service Strategie, Service Design und insbesondere Service Transition werden entscheidende Funktionen und Prozesse für eine erfolgreiche Service Integration in einem Multiprovider-Umfeld.  Die Komplexität liegt nicht bloss in der technischen Orchestrierung der Teil-Services zu einem Ganzen, sondern in der Abstimmung und Durchsetzung der Business-Anforderungen bei allen beteiligten Partnern. Der auf Standardisierung und Optimierung des Skaleneffekts ausgerichtete externe Service Lieferant steht den individuellen Bedürfnissen nach Customizing und Integration der Businesspartner gegenüber. Agil und dynamisch entstehende und umzusetzende Bedürfnissen verlangen auch nach agilen Governance-Strukturen (Lesen Sie dazu den Artikel „Agile Projekte brauchen agile Governance“  auf dem Portal GoingPublic.de).

Die vielfältigen Lieferantenbeziehungen lassen sich nicht einfach per SLA steuern. wie gut, ausgeklügelt und kundenfokussiert dieser auch immer ausgehandelt wurde. Die Rolle der Service Integration und das aktive Management rund um die Service Integration wird eine eminent wichtige Funktion oder Fähigkeit, eines verbleibenden internen Service Providers, damit der Vertrag auch zur Businesszielerreichung beiträgt. Was nützt dem Business, wenn er nach verpassten Geschäftszielen auf einen nicht erfüllten Lieferantenvertrag verweisen kann: Operation gelungen, Patient gestorben.

Disziplinen End-User-Organisation

Disziplinen End-User-Organisation

Das Service Management Modell von ITIL® trägt diesem Umstand zu wenig Rechnung. Obwohl alle Prozesse und Funktionen nach wie vor Gültigkeit haben und nicht weniger wichtig werden, lässt sich die Komplexität mit den einzeln instanziierten Prozessen und Rollen nicht reduzieren und schon gar nicht den Lieferanten einzeln übertragen. Auch wenn jeder einzelne Lieferant nachweislich nach den Konzepten lebt (z.bps. via ISO/IEC 20000 und/oder ISO/IEC 27001 Zertifikat), garantiert dies bezüglich empfangener End-to-End Serviceleistung rein gar nichts. Es bescheinigt lediglich, dass die Lieferanten ihre Services und ihre eigenen Risiken im Griff haben. Wie die Services als Ganzes beim Business funktionieren und ob die Risiken entsprechend gemanagt sind, bleibt in der Verantwortung des Kunden.

SIAM – das Service Integration und Management Modell

High-Level SIAM Modell

High-Level SIAM Modell

SIAM steht für „Service Integration and Management“ und ist derzeit ein Konzept, dass sich sehr schnell entwickelt und verbreitet. Kevin Holland (Linkedin-Profil) hat für Axelos das Konzept beschrieben und zwei White Paper publiziert (Link zu „An introduction to Service Integration and Management and ITIL®“ sowie „An example ITIL®-based model for effective Service Integration and Management“). In diesem Konzept wird SIAM nicht als neues Framework dargestellt, sondern viel mehr die bestehenden Konzepte von IT Service Management gemäss ITIL® auf die Problematik des Multiprovider-Managements ausgeweitet.

SIAM ist dabei einerseits eine spezialisierte Fähigkeit mit entsprechend vorausgesetzten Skills, kann aber auch als Funktion innerhalb der Service Provider Organisation eingerichtet werden. Grundsätzlich stellt SIAM frei, ob diese Funktion intern geleistet oder aber auch von einem externen SIAM-Provider bereitgestellt werden kann. Bezüglich den Grundprinzipien basiert das Modell aber auf den Service Management Prinzipien von ITIL mit den 4 P’s: People, Process, Product und Partner. Ohne die beteiligten internen und externen Personen (People, Partners) geht gar nichts. Basis dazu ist ein Vertrauen, das gegenseitig aufgebaut und geschenkt wird. Wenn ein Service Integrations-Modell auf fehlendem Vertrauen basiert, resultiert dies in übermässige Kontrolle, einem ständigen Hinterfragen der erbrachten Leistung und im Falle von Problemen in ein sofortiges Eskalieren und auf Pochen auf den Vertrag, bis sich die Juristen treffen. Das ist Gift in einem agilen dynamischen Umfeld. Die Auswahl der Partner und das Abstimmen der Kulturen im Vorfeld darf daher nicht genügend betont werden.

Aber auch die Prozesse müssen nun End-to-End gedacht und gemanagt werden. Mit der Vorstellung jedoch, einen Standard Prozess über alle Lieferanten hinweg durchsetzen zu wollen, wird man schlicht Schiffbruch erleiden. Lieferanten werden darauf insistieren, ihre Prozessstandards zu leben und nicht auf die individuellen Konzepte der Kunden (z.bps. RFC-Strukturen, Incident-Kategorien ect) umzustellen. Es wird stark empfohlen, den Fokus auf die Prozess-Schnittstellen zu legen und allenfalls ein Mapping der unterschiedlichen Modelle abzubilden, anstelle den Versuch zu wagen, alle Prozessvarianten im Detail aufzuzeichnen. Als Basis-Prozess dient ein transparentes Service-Portfolio/Service Katalog mit den jeweiligen Abgrenzungen und Abhängigkeiten zwischen den Services und Lieferanten. OBASHI wäre hierzu eine ideale Methode zur Erarbeitung dieser Grundlagen.

Tool-Requirements

Tool-Requirements

Bei den Tools (Products) besteht eine der grössten technischen Herausforderungen. Es braucht Werkzeuge für das Managen der Services, der einzelnen Service-Towers, das Reporting und der Überwachung der Sicherheit und Compliance. Es ist dabei ein Mythos zu glauben, alle externen Lieferanten werden die gleichen Werkzeuge wie die Kunden einsetzen. Man soll alles daran setzen, eine Integration der Werkzeuge zu ermöglichen, aber auch das wird nicht in jedem Falle durchsetzbar sein. Wichtig ist auch hier bei der Auswahl der Lieferanten vor der Vertragsunterzeichnung, klare „Business-Standards“ für die Datenschnittstellen  als Grundlage der Zusammenarbeit festzulegen. Ein weiterer Grundsatz liegt dabei in der Optimierung der Automation.

SIAM Komponenten

SIAM Komponenten

SIAM Komponenten

Im SIAM Modell ist ein Beispiel von notwendigen Komponenten dargestellt, welche spezifische Prozesse und Funktionen für die Service-Integration und deren Management beschreiben. Dies beinhaltet:

  • Business/Customer Relationship Management – dieser Prozess oder Funktion stellt die Beziehung zwischen Business, SIAM-Provider und den Lieferanten sicher
  • Service Katalog und Portfolio Management
  • SIAM Design – hier wird der Kern des SIAM-Betriebskonzepts definiert und über alle involvierten Teilservices und Lieferanten sichergestellt (Design Coordination, Availability Management Design, Capacity Management Design)
  • IT Information Security – die Sicherheitsanforderungen insbesondere auch im Identity und Access Management werden abgestimmt und durchgesetzt.
  • Service Desk als Single Point of Contact und damit zentrale Auskunft über Status der Services
  • Toolset Integration – dies beinhaltet die Werkzeuge zur Ausführung und Überwachung der Prozesse beim SIAM-Provider, Service Überwachung und Monitoring, Tools zur Entscheidungsunterstützung, Diagnose und Discovery Tools, Sicherheitswerkzeuge, Analyse und Reporting Tools
  • Business & Service Continuity Management – zur Sicherstellung eines integrierten Business- und Service Continuity Plans
  • Service Transition und Planning
  • Operation Bridge
  • Service Validation & Testing – hier ist der Aspekt der Integration-Tests im Vordergrund
  • Knowledge Management
  • Multiple-Supplier Koordination – insbesondere die Koordination, welche über verschieden involvierte Lieferanten betreffen. Zum Beispiel Change Management, Release Planung, Kapazitätsplanung, Major Incident Management, Problem Management, Innovation und Continual Service Improvement
  • Supplier & Service Qualitätssicherung
  • Operational Service Management

Nutzen eines SIAM Modells

SIAM muss unter dem Aspekt der effektiven und effizienten Service-Erbringung eingerichtet werden. Wenn die Kosten des SIAMs höher sind als der erwartete Nutzen, dann lässt man es besser bleiben.  Wie bereits erwähnt, basiert SIAM auf dem Prinzip des Vertrauens, dass jeder Partner seine Leistungen in der geforderten Qualität erbringt. Andererseits braucht es spezifische technische und Prozess Skills, welche in den traditionellen ITIL-Trainings nicht oder ungenügend vermittelt werden:

  • Relationship Management
  • Konflikt Management
  • Verhandeln und Überzeugen
  • Stakeholder Management
  • Cloud Service Management
Service Towers

Service Towers

Wenn SIAM gut etabliert und eingesetzt wird, ist der Nutzen so, wie man sich das grundsätzlich bei der Business-Veränderung vorgestellt hat:

  • Optimierte Kosten für die Bereitstellung der Services an das Business
  • Reduzierte Risiken
  • Nutzung der Skaleneffekte der Lieferanten
  • Verbesserte Kunden- und Benutzerzufriedenheit
  • Verbesserte Service-Leistung an die Anwender
  • Konsistente Überwachung der Qualität
  • Reduzierung von Doppelspurigkeiten
  • Agile Umsetzung von neuen Business-Anforderungen
  • etc.

Als Fazit kann gezogen werden, dass SIAM eine Erweiterung des bestehenden IT Service Management Systems darstellt, jedoch mehr ist als nur ITIL®. Die Transition zu einem SIAM-Betriebskonzept muss gut vorbereitet und als Veränderungsprojekt umgesetzt werden. Wenn die bestehende Maturität in den Prozessen und Organisationsstrukturen bereits schwach sind, so steht eine grosse Aufbauarbeit an. Wir seitens Glenfis erleben immer wieder die Aussage, dass IT Service Management durch das externe Sourcing aufgelöst werden kann. Das Gegenteil ist der Fall – wenn die Hausaufgaben des IT Service Managements und der IT-Governance nicht gemacht sind, wird das Integrationsmodell ein „Sourcing within the mess“.


 

4 Antworten auf SIAM – Das Service Integration Modell im Multiprovider Umfeld

  1. Hallo Martin,

    danke für den Überblick zu SIAM. Du bringst es insbesondere im letzten Abschnitt auf den Punkt: Vertrauen, Reden und die Stakeholder einbinden. Soweit ich SIAM verstehe, setzt nach Vertragsabschluss an. Transition, Betrieb, Servicekatalog, etc.
    Auch steht der / die Provider im Mittelpunkt – also letztendlich der Betrieb. Das ist gut und wichtig, denn die Fähigkeit einen oder mehrere Provider „ordentlich“ zu steuern haben heute die wenigsten Organisationen.

    Ich möchte gern noch eher ansetzen und zwar am Anfang. Wenn darüber nachgedacht wird, dass eine Unternehmen Services auslagern könnte. Dort läuft meiner Meinung nach einiges schief, was dann hinterher wieder ausgebügelt werden muss. Durch die Flexibilität des Providers. Allerdings: Flexibel = teuer.

    Daher lohnt es sich, im Vorfeld darüber nachzudenken, welche Ziele (und ich meine nicht höher, schneller und billiger) erreicht werden soll. Auch hier geht es um Kommunikation und Partizipation. Vor allem der Fachbereiche. Ich bin häufig überrascht, was Fachbereiche zu einem Service zählen und wie viel mehr das ist, als das was die IT darunter versteht.

    Sechs Punkte sind wichtig:

    1. notwendiger Wandel der IT-Organisation wird unterschätzt
    2. fehlende Klarheit über das Ziel und die Anforderungen
    3. keine Einbeziehung der Fachbereiche
    4. Vernachlässigung der Kommunikation nach innen und außen
    5. Providerauswahl – der billigste gewinnt
    6. fehlender Reife der eigenen Organisation

    Nicht alles kann mit SIAM erschlagen werden. Für vieles reicht die Fähigkeit der Problemanalyse und Kommunikation. Über die Punkte habe ich in einer Podcastfolge laut nachgedacht: http://different-thinking.de/podcast-warum-outsourcing-scheitert/

    Robert

    • Hallo Robert,
      Deine Schlussfolgerungen sind nicht ganz korrekt. Es ist nicht nicht der Betrieb im Mittelpunkt, sondern gerade die Strategie und der Design. Ein seriöser Sourcing-Prozess wie Du ihn aufskizzierst gehört natürlich dazu. Das ist aber nicht der Punkt hier. Vielmehr ist es sogar eine der Gründe, weshalb Sourcing-Vorhaben zu komplexen und schwer manage-baren Gebilden führt. Jeder Sourcingvertrag wie auch immer seriös abgewickelt führt in der regel zu einer Best-of-breed-Lösung, welche für die gesuchte Aufgabe wohl optimal ist.
      Die Problematik ist vielmehr, dass bei einer Vielzahl von solchen Sourcig-Lösungen jede Beziehung unterschiedlich und in aller Regel auf den externen Provider ausgerichteten Definitionen beruht. In der internen verbleibenden Organisation gilt es die Enden zu sammen zu halten und die Koordination über alle involvierten Provider im Griff zu haben. Und dies führt eben vielfach zu der komplexen Situation und aus End-to-End-Service Betrachtung sschwierig zu steuern.

      SIAM stellt das Modell vor, dass insbesondere im Service Design die „Standards“ definiert werden, wie Provider überhaupt mit der Organisation zusammen zu arbeiten haben und welche Interfaces bereitgestellt werden müssen. Diese Anforderungen müssen bei der Wahl eines Providers genauso einfliessen, wie die Service-Lösung, welche evaluiert wird.

      Zudem ist es primär ein Koordinieren, Verhahdeln, Abstimmen zwischen den beteiligten Providern – was letztlich wiederum zu einer ganz anderen Form von Kooperation im Netzverbund führen kann.

      Man kann mit SIAM sicherlich nicht alles erschlagen. An diesem „Schweizer Taschenmesser“ arbeiten wir noch 🙂
      Gruss
      –Martin

      • Na, wenn einer das Schweizer Sourcing-Messer erfindet, dann doch Glenfis, oder?

        Ich bin mir grad nicht sicher, ob wir das gleiche meinen. Ich finde es einen guten und wichtigen Punkt, darüber nachzudenken und zu definieren, wo sind meine Schnittstellen und wie will ich mit dem Provider zusammenarbeiten. Unternehmen müssen ihre Standards setzen und nicht die vom Provider übernehmen.

        Es ist mir allerdings zu technokratisch. Ich glaube, ich bin immer noch vorher. Ich bin da, wenn sich Unternehmen die Gedanken machen bestimmte Leistungen anders zu sourcen. Ich bin da, wenn Finanzer und Techniker sagen, dass das alles super ist und billiger wird (ich simplifiziere). Und der „gemeine“ Fachbereich das dann irgendwann ausbaden muss. Und das ist in meiner Welt vor Service Design.

        Robert

        • Nun gut – SIAM ist die Grundlage für das Betriebskonzept einer Multiprovider-Umgebung – auf Basis des Service Managements.

          Eine Sourcing-Strategie und die Ausarbeitung eines Businesscase für Sourcing-Lösungen inklusive eines Transitionkonzepts muss natürlich immer vorgängig erfolgen. Wenn hier leichtsinnig vergeben wird, wird man es im Tagesbetrieb sofort spüren.

          Aber auch beim Service Management fängt es nicht erst beim Operation an, sondern bei der strategischen Positionierung. Daher muss auch bei der Sourcing-Strategie nicht nur die Sourcing-Lösung alleine im Fokus stehen, sondern eben auch das Leben danach. Und hier setzt eben bei SIAM der „Service Design“ an.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ähnliche Beiträge

« »