2

SIAM – Framework für Multiprovidermanagement

Was SIAM genau ist, welche Rolle es für Dich im Multiprovidermanagement spielt und wie Du davon profitierst, erfährst Du in der heutigen Podcastfolge. Ich nehme das Framework für Dich im Detail auseinander - deswegen ist die Folge auch etwas länger geworden.

Vervollständige bitte folgenden Satz: Wenn ich an meinen Provider denke, dann ….

Und woran denkst Du da? Ich hoffe es ist etwas Positives. Wenn Du magst, teile Deine Gedanken in den Kommentaren mit mir und den anderen Hörern.

Outsourcing und –tasking kann man aus meiner Sicht mit einer Ehe vergleichen: Man findet das Angebot des Providers am Anfang ansprechend und geht eine Beziehung mit ihm ein. Je länger man sich dann kennt, umso mehr Macken offenbaren sich beim Provider.

Du und Dein Unternehmen verändern sich auch – genauso wie Eure Ansprüche. Und wie geht Dein Provider damit um? Wie könnt Ihr drüber reden? Wie sehr geht er auf Dich ein?

Ich glaube, wir dürfen alle mal über den Beziehungsstatus mit unserem oder unseren Providern nachdenken.

Ich erinnere mich an die fünf Jahre, die ich für die Deutsche Post gearbeitet habe und es ein komplettes Outsourcing an ein Telekommunikationsunternehmen gab. Diese Zeit hat mich sehr viel Kraft gekostet. Ich habe häufig und lange mit dem Provider telefoniert, damit überhaupt etwas vorwärts geht.

Klar, wir waren nur eine Tochter – und wir hatten etwas andere Anforderungen als die Mutter. Klar, da kann man schon durcheinander kommen. Aber so …

Nein, das wird jetzt keine Aufarbeitung einer für mich gescheiterten Beziehung. Was ich Dir sagen möchte: Das Management eines Komplettoutsourcings mit einem Provider war eine tagesfüllende Aufgabe. Manchmal sogar mehr. Wie ist das dann erst mit mehr als einem Provider?

Steuerung mehrerer Provider

Aktuell habe ich als CIO mehrere Provider, die uns Leistungen zuliefern, die wir zu Business Services bündeln.

Während Du bei einem Provider monogam lebst und Dich ganz um diese Beziehung kümmern kannst, bist Du mit mehreren Providern  polygam.

Erschwerend kommt dazu, dass im besten Fall die Provider untereinander auch eine Beziehung haben – zumindest auf einer bestimmten Ebene.

Du kennst bestimmt den Spruch: „Drum prüfet wer sich ewig bindet, ob sich nicht was Besseres findet“, oder? Ich möchte hier in Sachen Provider den Schwerpunkt auf das Prüfen legen.

Bevor Du mit einem neuen Provider einen Vertrag schließt, darfst Du prüfen, ob er die gleiche Vorstellung von Zusammenarbeit hat wie Du. Ob er bereit ist, sich auf Deine Art und Weise einzulassen, mit Dir und anderen Providern positiv und zielgerichtet zu arbeiten.

Einfache Frage: Was verstehst Du unter Qualität? Was versteht der Provider unter Qualität? Reicht Dir der 08-15 Standard-SLA oder brauchst Du andere Leistungen?

Und hier hört jetzt der Vergleich mit der Ehe auf. Aus Liebe findet man einen gemeinsamen Weg, geht Kompromisse ein und ändert sich vielleicht sogar ein wenig selbst.

Outsourcing Governance

Die Zugeständnisse in Richtung Provider sollten in der Regel nicht so weitgehend sein. Du erwartest eine Leistung für die Du bezahlst. Du darfst klar formulieren, was Dein Unternehmen erwartet. Und zum Schluss darfst Du prüfen, ob genau das im Vertrag steckt.

Hier legst Du den Grundstein für eine gute Zusammenarbeit und Deine eigene Zufriedenheit.

Ich habe in einem kleinen eBook für Dich zusammengetragen, über was Du alles nachdenken darfst, wenn Du eine Vereinbarung mit einem Provider schließt.

Dazu habe ich in Podcastfolge 32 mit Carsten Bliessen gesprochen und wir beide haben das Outsourcing Governance getauft. 

Das war der erste Schritt. Wenn Du einen Vertrag geschlossen hast, der genau das verspricht, was Dein Unternehmen braucht: Herzlichen Glückwunsch! Du hast eine aufwendige und immer wieder schwierige Aufgabe erfolgreich abgeschlossen!

Die Zusammenarbeit überwachen

Jetzt geht die Arbeit allerdings erst los: Der beste Vertrag nutzt nichts, wenn Du und Dein Provider nun so weitermachen wie bisher.

Der Vertrag und die Leistungserbringung gilt es mit Leben zu füllen. Dazu gehört viel mehr, als mir so auf den ersten Gedanken einfallen würde.

Daher möchte ich Dir heute ein Framework vorstellen, welches sich mit der Steuerung von Providern beschäftigt: SIAM – Service Integration and Management.

SIAM – Service Integration and Management

SIAM geistert seit einiger Zeit durch das Internet und scheint zumindest im englischen Sprachraum einen gewissen neuen Hype auszulösen. Mir scheint, als müsste jetzt alles SIAM sein – so wie das neue ITIL.

Die ersten Berührungen hatte ich 2015 durch ein Whitepaper von Kevin Holland. Warum ich dem damals nicht hinterhergegangen bin? Keine Ahnung. Mir erschien es damals irgendwie nicht passend – überflüssig.

Vor kurzem bin ich immer wieder über SIAM gestolpert und habe begonnen mich damit zu beschäftigen.

Geschichte hinter SIAM

Beginnend in den 70er Jahren haben Unternehmen begonnen Leistungen an andere Unternehmen auszulagern. Im Jahr 1989 kam erstmals das Wort Outsourcing auf und wurde als mögliche Geschäftsstrategie formuliert.

Heute sehen wir viele verschiedene Formen: Auslagern einzelner Tätigkeiten (Outtasking) bis hin zur Auslagerung ganzer Unternehmenszweige wie IT, Personal oder die Buchhaltung – Business Process Outsourcing (BPO) genannt.

Ich habe in den vergangenen Jahren immer wieder, auch ganz persönlich, erfahren, dass das Management von Outsourcing ganz andere Herausforderungen beinhaltet. Du und Deine Organisation brauchen andere Fähigkeiten, um damit erfolgreich umzugehen.

Outsourcing löst Probleme und lässt gleichzeitig neue Probleme entstehen. Du kennst den Klassiker: Während „früher“ der zuständige Sachbearbeiter bei HR immer für Dich ansprechbar war, nutzt Du heute eine Hotline oder schreibst eine eMail. Für Dich und Dein aktuelles Anliegen, geht es langsamer und der Service hat sich verschlechtert. Auf jeden Fall gefühlt.

Hat Dein Unternehmen mehrere Provider beauftragt, einzelne Komponenten einer Leistungskette zu liefern, dann wird es besonders spannend. Dann bist Du beim Multiprovidermanagement.

Das SIAM-Framework

Genau hier möchte Dich SIAM unterstützen.

„SIAM (ausgesprochen: Service Integration and Management) ist eine Managementmethode, welche in Umgebungen angewendet werden kann, in denen Serviceleistungen von mehreren Providern bezogen werden.“

SIAM bietet Dir Hilfestellung für alle relevanten Bereiche:

• Governance
• Management
• Integration
• Sicherheit
• Koordination

Ziel ist es, dass Dein Unternehmen den maximalen Wert aus den Verträgen mit den Providern ziehen kann.

Es bewegt sich auf der strategischen, taktischen und der operativen Ebene der Lieferbeziehung.

Das Ziel von SIAM ist, dass Kunde und alle beteiligten Provider so zusammenarbeiten, dass alle:

• Ihre Rolle, Verantwortlichkeiten und Ihren Erfolgsbeitrag kennen
• In der Lage sind zu liefern
• Rechenschaftspflichtig sind, dass sie auch das liefern, was von Ihnen verlangt wird

Um dies zu erreichen, beinhaltet die SIAM-Methode folgende Komponenten:

• Praktiken
• Prozesse
• Funktionen
• Rollen
• Strukturelemente

Bevor ich Dir etwas zu den einzelnen Komponenten sage, möchte ich mit Dir über das zentrale Element von SIAM sprechen:

Service Integrator

Sprechen wir über die Rolle und Bedeutung des Service Integrator.

Der Service Integrator ist „eine einzelne logische Einheit, die rechenschaftspflichtig für die Ende-zu-Ende Erbringung der Services und das Erreichen des Geschäftsziele ist.“

Die Übersetzung ist vielleicht etwas holprig. Deswegen hier das Original: „Service Integrator is a single logical entity, held accountable for the end to end delivery of services and the business value that the customer recieves.“

In dem Zusammenhang ist mit die Übersetzung von „held accountable“ wichtig. Ich habe sie bewusst als „rechenschaftspflichtig“ übersetzt. Das entspricht dem A in RACI und soll ausdrücken, dass es nur einen geben kann und vor allem, dass es ernst ist mit der Verantwortung.

Wer nicht liefert wie vereinbart, der muss mit Sanktionen rechnen. Egal ob Service Integrator oder die Provider.

Rollen in SIAM

Im SIAM gibt es drei Ebenen: die Kundenorganisation, der Service Integrator und die verschiedenen Provider.

Du darfst Dir das wie ein Schichtenmodell vorstellen: Der Service Integrator ist der Puffer zwischen Kunde und Lieferant.

Er sorgt sich um alles, damit der Kunde ungestört seinem Geschäft nachgehen kann. Ohne sich um die Lieferanten zu kümmern.

Wobei das nicht ganz richtig ist. Und damit bin ich bei einem Punkt, der im Modell von SIAM leicht missverstanden werden kann:

Retained Capabilities

Innerhalb der Kundenorganisation gibt es sogenannte „Retained Capabilities“ – auf Deutsche: beibehaltene Fähigkeiten. Also Funktionen, die durch den Kunden erbracht werden. Dazu können zählen:

• Enterprise Architektur (LINK zu Podcast)
• Governance
• Einkauf
• Vertragsmanagement
• Anforderungsmanagement
• Financial Management
• Service Portfolio Management
• Risikomanagement
• Steuerung des Service Integrators

Wenn Du jetzt die Liste nimmst und so deinen Service Integrator schneidest, dann ist das meiner Meinung nach zum Scheitern verurteilt. Ein großer Teil dieser Funktionen sollte ebenfalls beim Service Integrator liegen.

Nur wenn diese für das Unternehmen einen Wettbewerbsvorteil bringen oder strategisch sind, sollten diese in der Kundenorganisation verbleiben.

Bei allem anderen darfst Du zusätzliche Schnittstellen und Aufwand vermeiden und diese beim Service Integrator ansiedeln.

Das Mandat des Service Integrator

Der Service Integrator braucht das passende Mandat. Ohne Mandat und ohne einen großen Teil der genannten Aufgaben, wird der Service Integrator nur ein Durchlauferhitzer. Eine Organisationseinheit, die kaum zusätzlichen Nutzen bringt und nur kostet.

Etwas anders sieht das aus, wenn Dein Service Integrator eine externe Firma ist. Also Du den Service Integrator selbst outsourcet.

Da werden andere und wahrscheinlich mehr Funktionen in der Kundenorganisation verbleiben, als wenn der Service Integrator Teil Deines Unternehmens ist.

In dieser Konstellation ist das Mandat noch viel wichtiger! Der Service Integrator muss sowohl nach innen als auch nach außen (zu den Providern) ermächtigt werden, für das Unternehmen zu sprechen. Die Verträge mit den Lieferanten hält die Kundenorganisation. Viele Provider werden versuchen sich an den Kunden zu halten und den Service Integrator weitgehend ignorieren.

SIAM geht explizit davon aus, dass der Service Integrator intern oder extern sein kann. Auch kann einer der Provider die Rolle des Service Integrator übernehmen.

Interne Betriebsabteilungen sind natürlich auch Lieferanten und werden ebenso geführt wie Externe.

BTW: Es ist völlig egal, ob es sich um IT, HR, Buchhaltung oder was auch immer für Provider handelt. SIAM kannst Du für alles adaptieren.

 

Strukturelemente in SIAM

Jetzt möchte ich mit Dir über die Komponenten von SIAM sprechen. Lass uns mit den Strukturelementen beginnen:

SIAM kennt drei verschiedene:

• Boards
• Process Forums
• Working Groups

Für mich sind diese drei die interessantesten und wichtigsten Elemente in SIAM. Ich bin leider bisher nie auf den Gedanken gekommen, alle an einen Tisch zu holen.

Ich habe zwar über die Outsourcing Governance klar geregelt, wie ich mit den Providern zusammenarbeiten will. Dort drin steht auch, wie die Provider miteinander arbeiten sollen. Alle zu bestimmten Themen zusammenzuholen – daran habe ich nie gedacht.

Du nutzt die drei Elemente, um bestimmte Fragen und Aufgaben providerübergreifend zu bearbeiten und ein gemeinsames Verständnis herzustellen. Das kann sein:

• Governance
• Entwicklung und Pflege von Policys und Standards
• Überprüfung und Verbesserung der Ende-zu-Ende Servicequalität
• Überprüfung und Verbesserung von Fähigkeiten und des Reifegrades in verschiedensten Bereichen (Zusammenarbeit, Technologie, Prozesse, etc.)
• Identifizierung, Anregung und Umsetzung von Verbesserung (CSI) und Innovation
• Lösen gemeinsamer Vorfälle und von Konflikten
• Durchführung gemeinsamer Projekte
• Integration, Aggregation und Konsolidierung von Messdaten, um eine Ende-zu-Ende Sicht zu bekommen

Boards

Boards sind für die Governance im SIAM Ecosystem zuständig. Sie treffen Entscheidungen und sind für diese rechenschaftspflichtig. Board-Sitzungen finden regelmäßig auf allen drei Ebenen – strategisch, taktisch und operativ – statt.

In den strategischen und operativen Boards sind sowohl der Kunde, der Service Integrator als auch die Provider vertreten. In taktischen Boards nur der Serviceintegrator und die Provider. Die Boards klären auf Managementebene alle Dinge rund um die Serviceerbringung.

Prozessforen

Konkrete und detaillierte Arbeit findet in den Prozessforen und den Workinggroups statt. Prozessforen konzentrieren sich, wie der Name sagt, auf einzelne Prozesse oder auf Teilaspekte der Prozesse. Beispielsweise, wenn es um die Abstimmung und Weiterentwicklung des gemeinsamen Change- oder Incidentmanagement-Prozess geht.

Vertreten sind dann die entsprechenden Spezialisten aller Beteiligten. Damit sind die Prozessforen das wichtigste Instrument, um die Zusammenarbeit der Provider zu forcieren und zu entwickeln. Das Ziel ist, das es in Deinem Ecosystem nicht das Schwarze-Peter-Spiel gibt, sondern alle zum Wohl des Kunden arbeiten.

Working Groups

Die Working Groups sind reaktiv. Sie kommen zusammen, wenn es notwendig ist, um spezielle Vorfälle oder Projekte zu bearbeiten. Prozessforums und Working Groups können auch kombiniert werden – je nach Thema und Ziel. Working Groups sind in der Regel zeitlich bis zur Erledigung der konkreten Aufgabe beschränkt.

Mit Hilfe dieser SIAM Strukturelemente bist Du in der Lage, die Zusammenarbeit so zu entwickeln, dass wirklich die Chance besteht, dass eine vertrauensvolle Umgebung mit abgestimmten und funktionierenden Prozessen entsteht.

SIAM und Multiprovidermanagement an sich bedeutet, dass Deine Provider über Ihren Schatten springen müssen. Sie sind untereinander Konkurrenten beim Gewinnen von Kunden. Sie müssen beim Erbringen der Leistungen zusammenarbeiten. Ich glaube, das wird noch einige Zeit dauern, bis die Unternehmen dies wirklich antizipieren.

Lieferant in einer Multiprovider-Umgebung zu sein, bedeutet sein eigenes Ego zurückzunehmen und die Ende-zu-Ende-Leistung für den Kunden in den Mittelpunkt zu stellen. Die Ideen aus SIAM können Dir helfen, dies erfolgreich aufzubauen.

All diese Strukturelemente sind Cross-Functional-Teams. Und damit sind wir bei den SIAM Practices.

SIAM Practices

Practices sind „die aktuelle Umsetzung oder Nutzung einer Idee, eines Gedanken oder einer Methode.“

In anderen Worten: Practices sind Handlungen einer Organisation, um SIAM umzusetzen. SIAM kennt vier Kategorien:

• People Practices
• Process Practices
• Measurement Practices
• Technology Practices

Für jede Kategorie wird jeweils ein Beispiel beschrieben. Im BoK werden die Herausforderungen genannte, wie Du damit umgehen kannst und wie das in Bezug auf SIAM funktioniert.

Eine People Practice heißt wie gesagt „Managing Cross-functional Teams“. SIAM nennt noch „Managing conflict“ und „Creating shared goals“ als Beispiele. Es geht im Prinzip darum, Vorgehen für die Organisation des SIAM Service Integrator zu etablieren, das Multiprovidermanagement so zu gestalten, dass der Service Integrator wirklich die Ende-zu-Ende Verantwortung wahrnehmen kann.

Entsprechend gestalten sich auch die Beispiele für die anderen drei Gruppen:

• Measurement Practices: „Enabling and Reporting on End to End Services“
• Process Practices: „Integrating Processes across Service Providers“
• Technology Practices: „Creating a Tooling Strategy“

Damit beschreibt SIAM die wichtigsten Aufgaben, um die Du Dich kümmern darfst, wenn Du einen Service Broker aufbauen möchtest.

 

SIAM Rollen

SIAM kennt drei Rollen: die Kundenorganisation, den Service Integrator und die Provider.

Als Service Integrator hast Du es immer mit allen drei Rollen zu tun. Folgende SIAM Rollen sind im BoK definiert.

In der Kundenorganisation (Customer Organisation) findest Du typischerweise die Rollen des IT-Leiters, Service Owner, Enterprise-Architekten, Service Architekt und die ganzen C-Level-Rollen. Wie am Anfang mag ich hier anmerken, dass ich mit der Aufteilung nicht glücklich bin.

Du darfst Dir überlegen, wo die einzelnen Funktionen am besten aufgehängt sind. Das hängt sehr stark vom Mandat des Service Integrators ab. So wie ich mir einen Service Integrator vorstelle, sind die Rollen des Service Owner, Enterprise- und Service-Architekten in der Service Integrator Organisation verwurzelt. Und nicht beim Kunden.

Es wird Situationen geben, in denen ist das nicht so. Je nach Umgebung und Mandat, darfst Du das so schneiden, dass es optimal passt. Achte bitte drauf, dass Du nicht mehr Overhead erzeugst, als das SIAM Konstrukt Nutzen bringt!

Die zweite Rolle ist der Service Integrator selbst. Dort findest Du typischerweise Service Delivery Manager, Service Owner, Service Manager, Prozess Owner, Prozessmanager und den Security Manager.

Bei den Providern, die dritte SIAM Rolle, findest Du die Rollen des Service Managers, Account Manager, Prozess Owner, Prozessmanager und Techniker.

Typische Aufgaben und Verantwortlichkeiten sind im SIAM BoK beschrieben.

 

SIAM Funktionen

Sind wir einmal bei den Rollen, dann lass mir Dir kurz etwas zu den SIAM Funktionen sagen. Funktionen sind Organisationseinheiten, die ein bestimmtes Gebiet von Wissen und / oder Fähigkeiten abdecken.

Es sind die klassischen Bausteine einer Aufbauorganisation: Teams und Abteilungen. Glücklicherweise findest Du in SIAM nur den Hinweis, dass jeder Service Integrator Organisation unterschiedlich ist. Je nach Verteilung der Verantwortung zwischen Kundenorganisation und Service Integrator, sieht die Organisation des Service Integrators anders aus.

SIAM Prozesse

Bleibt das letzte Element der SIAM Methode: die Prozesse. SIAM selbst ist kein Prozessmodell. SIAM sagt Dir, über welche Punkte Du nachdenken darfst, wenn Du Multiprovidermanagement aufbauen möchtest. Dazu gehören natürlich die Prozesse, die ein Multiprovidermanager mit seinen Providern abstimmen und vereinheitlichen darf.

Dafür gibt es den eigenen SIAM Process Guide. Dort werden zu jedem Prozess folgende Aspekte beschrieben:

• Zweck des Prozesses
• Überlegungen, die im SIAM Kontext relevant sind
• Generische Informationen zum Prozess (Aktivitäten, Rollen, Inputs und Outputs sowie KPIs)

Besonders wertvoll ist die Einordnung der Prozesse in den SIAM Kontext. Zu jedem Prozess gibt es ein Kapitel, welches sich damit auseinandersetzte, was Du beachten darfst, wenn Du den Prozess als Service Integrator etablieren möchtest. Das gibt Dir Leitlinien, um nicht jeden Fehler selber machen zu müssen.

Der SIAM Prozessguide geht auf folgende Prozesse ein:

• Service Portfolio Management
• Monitoring and Measuring
• Event Management
• Incident Management
• Problem Management
• Change and Release Management
• Configuration Management
• Service Level Management
• Supplier Management
• Contract Management
• Business Relationship Management
• Financial Management
• Security Management
• Continual Service Improvement
• Knowledge Management
• Toolset and Information Management
• Project Management
• Audit and Control

In meiner Outsourcing Governance fokussiere ich sehr auf die Prozesswelt. Harmonisierte und gut funktionierende Abläufe zwischen den Providern untereinander und zwischen Provider und Service Integrator sind ein wichtiger Erfolgsfaktor für SIAM.

SIAM Roadmap – Implementierung von SIAM

Wie kommt jetzt Deine Organisation von heute zu einer funktionieren Service Integrator Organisation?

Um es gleich zu sagen: Ein Einführungsprojekt wird auch hier nicht funktionieren. Es ist eine Veränderung der Organisation, bei der alle Bereiche betroffen sind. Es ist kein Vorhaben der IT oder ein Vorhaben des Business. Es ist eine Unternehmensentscheidung und damit ein strategisches Projekt. Und genauso darfst Du damit umgehen.

Das bedeutet, Du hast auf der einen Seite das fachliche Projekt und auf der anderen Seite das Veränderungsprojekt. Für letzteres verweise ich Dich auf die Folge mit Reiner Ritter, in der wir über Lean Change Management gesprochen haben.

Für den fachlichen Teil gibt Dir SIAM mit der SIAM Roadmap eine Idee, wie es funktionieren könnte. Es handelt sich dabei um eine iterative Vorgehensweise in vier Stufen. Die vier Stufen der SIAM Roadmap sind:

• Discover and Strategy
• Plan and Build
• Implement
• Run and Improve

Für jeder dieser vier Stufen sind in SIAM die Ziele, Trigger, Inputs, Aktivitäten und Outputs genannt. Daran kannst Du ich gut orientieren.

Lass uns mal auf die Ziele der einzelnen Stufen der SIAM Roadmap schauen.

Phase 1: Discover and Strategy

In der Phase „Discover and Strategy“ sollen folgende Ziele erreicht werden:

• ein SIAM Transition Projekt soll etabliert werden
• das zu verwendende Governance-Framework soll definiert werden
• die Strategie, das spezifische SIAM Modell und die betroffenen Services sollen definiert werden
• die Analyse des Ist-Zustandes der Organisation, Fähigkeiten, Services, Service Provider, und Prozesse soll durchgeführt werden
• der Provider-Markt soll eruiert werden

Damit soll sich die Kundenorganisation klar werden, mit welcher Strategie das SIAM Projekt gestartet werden soll. Dabei geht es noch nicht ins Detail, alles, bis auf die Ist-Analyse, ist High Level!

Phase 2: Plan and Build

In der nächsten Stufe geht es dann ins Detail. Die Ziele der SIAM Roadmap Stufe „Pland and Build“ sind:

• Design des SIAM Modells vollständig beschreiben inkl. der Services, die „betroffen“ sind
• Genehmigung des SIAM Modells
• den Service Integrator und die Service Provider auswählen
• Beginn mit dem Veränderungsprojekt innerhalb der Organisation

Von der Veränderung sind die Kundenorganisation, der Serviceintegrator und die Service Provider betroffen. Alle gilt es in das neue Modell zu integrieren. Diese Arbeit wird in der dritten Stufe der SIAM Roadmap erledigt: „Implement“.

Phase 3: Implement

Hier findet jetzt die Veränderung der Organisation statt. Du baust den Service Integrator auf und kündigst Lieferantenverträge, veränderst diese oder holst neue Provider an Board. Es ändert sich sehr vieles auf einmal: Services, Prozesse, Rollen, Technologie und Tools. Bitte vergiss das Veränderungsmanagement nicht! Sonst hat Deine Organisation zwar eine neue Aufbauorganisation und ein paar neu Titel, doch die Ziele wird das Projekt nicht erreichen.

Es gibt verschiedene Wege, wie Du das Ziel erreichst:

• Umstellung eines Service nach dem anderen
• Umstellung eines Providers nach dem anderen
• Ein einzelner Prozess
• Eine einzelne Practice

Und natürlich kannst Du alles auf einmal ändern – abhängig von Deiner Ausgangssituation. Wichtig: Überfordere nicht Dich, Deine Organisation und auch nicht die Provider.

Phase 4: Run and Improve

Die Phase drei wird ihre Zeit benötigen. Im Sinne eines Projektes wäre dann hier auch Schluss. Wie Du weißt, ist die kontinuierliche Arbeit an einem System und einer Organisation sehr wichtig. Daher sieht die SIAM Roadmap mit „Run and Improve“ eine vierte Phase vor.

Die Ziele dieser Phase sind:

• Das SIAM Modell betreiben
• Die Service Delivery steuern – also das Daily Business
• Prozesse, Teams und Tools managen
• CSI-Aktivitäten durchführen

Somit endet diese Phase nie. Sie ist der tägliche Betrieb des Service Integrators. Sie liefert auch wieder Input in die anderen drei Phase, so dass die SIAM Roadmap im Sinne des CSI immer wieder durchlaufen wird.

Fazit

Du hast jetzt einen Überblick zu SIAM bekommen. Was hältst Du davon? Deine Meinung interessiert mich. Schreibe bitte etwas in die Kommentare zu diesem Beitrag! Ich bin gespann.

Wie sehe ich SIAM? Meiner Meinung nach liefert SIAM interessante Konzepte und Ideen, wie Multiprovidermanagement funktionieren kann. Ich werde einige Elemente, vor allem die Boards, Process und Working Groups, in meine IT Organisation übernehmen.

Die SIAM Roadmap ist ebenfalls sinnvoll und kann als Leitfaden für einen Adaption dienen. Wie immer ist SIAM kein Wunder- und auch kein Allheilmittel. Meine kritischen Gedanken habe ich Dir an der jeweiligen Stelle schon mitgeteilt. Die sind auch gar nicht schlimm, denn auch SIAM kannst Du nicht einführen.

Deswegen nimm SIAM und schaue, was für Dich sinnvoll ist und setzte es entsprechend Deiner Rahmenbedingungen um.

Weitere Links

• Warum Outsourcing scheitert und wie es trotzdem gelingt (Teil 1)
• Warum Outsourcing scheitert und wie es trotzdem gelingt (Teil 2)
• Download Outsorcing Governance
• Multiprovider-Management: die Kunst, Lieferanten erfolgreich zu integrieren
• Die Rolle der IT: Service Broker