Posts Tagged: ‘multi-sourcing’

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (8/12)

4. Dezember 2014 Posted by Bernd Kueppers

IBM Service Integration Capability Model: Information.

imageIn diesem Beitrag widmen wir uns dem vierten entscheidenden Aspekt der Service-Integration:

Der "Information".

Die Dimension “Information“ des Service Integration Capability Models behandelt die Definition von Daten und Datenstrukturen, die die Service Provider und der Service Integrator gemeinsam verwenden, um die Leistung zu erbringen und zu überwachen.

In einer Multi-Sourcing Umgebung hat jeder einzelne Service Provider bestimmte vertraglich vereinbarte Service Levels für seine Services zu erfüllen. Der Service Integrator wiederum hat dann die Aufgabe, die einzelnen Service Levels zu kombinieren, um daraus Ende-zu-Ende Service Levels zu berechnen.

Nehmen wir einmal die Verfügbarkeit eines Services als Beispiel. Die Ende-zu-Ende Verfügbarkeit ergibt sich dann aus dem Produkt der Verfügbarkeiten der verschiedenen Services, die Teil des Ende-zu-Ende Services sind.  

Ein Service Integrator kann den Nachweis der Ende-zu-Ende Service Levels wie im Beispiel dargestellt rein durch Aggregation der einzelnen Service Levels erbringen oder alternativ oder ergänzend durch Auswertung von Daten zur Leistungserbringung, die er von den einzelnen Providern ad hoc oder in regelmässigen Intervallen erhält. Ad Hoc werden dann üblicherweise bestimmte Ereignisse übertragen (Events) und in regelmässigen Abständen werden Rohdaten zur Leistungserbringung (Bulk Data) übertragen.

Diese Vorgehensweise hat für den Service Integrator den Vorteil, dass er über die Darstellung der Events in einem Dashboard die Verfügbarkeit des Ende-zu-Ende Services beinahe in Echtzeit anzeigen kann, wodurch auch die Arbeit des Service Desks sinnvoll unterstützt wird.
Über die Auswertung der Rohdaten zur Leistungserbringung kann er zudem die Ende-zu-Ende Service Levels selber berechnen und so die Berechnungen der Service Provider kontrollieren.

Damit die Auswertung der Service Levels möglichst reibungslos und aufwandsarm ablaufen kann, ist es Aufgabe der Dimension „Information“ des IBM Service Integration Capability Models, die Art und Weise, wie Informationen bereitgestellt und übermittelt werden sollen, für alle Service Provider in der Multi-Sourcing Umgebung verbindlich festzulegen.

Ein weiterer Bereich, der von der „Information“ Dimension behandelt wird ist der Austausch von Ticket-Informationen zwischen den verschiedenen Service Management Toolsets der einzelnen Service Provider.

Hier ist es ggf. möglich, dass sich der Service Integrator und die einzelnen Service Provider auf bestimmte Ticket-Formate verständigen. Sollte dies nicht möglich sein können die Tools aber dennoch miteinander verbunden werden, wie im Beitrag zur „Werkzeugunterstützung“ erläutert. In diesem Fall ist dann für jede Toolschnittstelle eine Übersetzungslogik erforderlich, die z.B. in einer Middleware wie IBM Security Directory Integrator implementiert werden kann.
 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (7/12)

27. November 2014 Posted by Bernd Kueppers

image

IBM Service Integration Capability Model: Werkzeugunterstützung

In diesem Beitrag aus der Serie zu Service Integration in Multi Sourcing/ Hybrid IT diskutieren wir diesmal die Frage:
Wie verbinde ich die Werkzeuge der einzelnen Service-Provider und des Service Integrators?

In den beiden vorangehenden Blog-Artikeln dieser Serie haben wir diskutiert, wie die Ablauforganisation zwischen dem Service Integrator und den Service Providern koordiniert werden kann und wie die Aufbauorganisation gestaltet sein sollte, damit die Zusammenarbeit gut funktioniert.

In diesem Beitrag widmen wir uns nun der Frage der Werkzeugunterstützung, d.h. mit welchen Service Management Tools wird gearbeitet und wie verbinde ich diese?

Üblicherweise implementiert der Service Integrator die X-Service Management Domäne (siehe vorangehenden Beitrag zu Ablauforganisation) in einem eigenen Toolset.

Ausgehend davon gibt es zwei unterschiedliche Möglichkeiten:
a.)    Der Service Integrator bietet den einzelnen Providern an, dieses Toolset ebenfalls zu nutzen.
b.)    Die einzelnen Service Provider nutzen ihre eigenen Tools und verbinden diese mit dem Service Integrator.

Variante a) hat den Vorteil, dass keine Schnittstellen zwischen verschiedenen Tools bedient werden müssen.
Meistens ist es aber so, dass die Service Provider viel Aufwand zur Automatisierung der Prozesse in eigene Toolsets investiert haben. Die Provider würden somit an Effizienz einbüssen, wenn sie das Service Management Tool des Service Integrators nutzen würden. Somit kommt in der Praxis meistens Variante b) zum Einsatz. Es gibt aber auch Fälle, in denen manche Provider mit Variante a) arbeiten und andere Provider mit Variante b).

Wenn es um die Frage geht, wie man konkret einzelne Tools miteinander verbinden kann, dann gibt es grundsätzlich drei Möglichkeiten:
A)    Man programmiert die Schnittstellen direkt in den beiden Tools, die verbunden werden sollen
B)    Man baut einen Enterprise Service Bus auf und schliesst alle Tools daran an
C)    Man nutzt Middleware, um Tools Point to Point zu verbinden. Die Schnittstellenlogik wird hierbei in der Middleware abgebildet.

In der Praxis wird A) heute selten verwendet, da bei dieser Lösungsvariante mit jeder einzelnen Schnittstelle die Toolkomplexität wächst.
Der Aufbau eines Enterprise Service Bus gemäß Variante B) ist häufig zu finden, allerdings mit relativ hohen Vorlaufzeiten verbunden und nicht für jede Tool-Umgebung geeignet.
Variante C) vermeidet die Nachteile von A) und B) und wird heute in der Praxis vielfach eingesetzt.


Für diese Art der Toolintegration eignet sich zum Beispiel die Software IBM Security Directory Integrator. Diese Software realisiert die Schnittstellen-Logik nach dem Fliessbandprinzip auf Basis zahlreicher vorgefertigter Logikbausteine aus einer Bibliothek.

Für die Leser, die es einmal ausprobieren möchten, besteht unter dem folgenden Link die Möglichkeit, eine kostenlose Testversion der Software herunterzuladen:

http://www-03.ibm.com/software/products/en/directoryintegrator
 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (6/12)

20. November 2014 Posted by Bernd Kueppers

IBM Service Integration Capability Model: Aufbauorganisation.     

In diesem Beitrag gehen wir auf die zweite Dimension des IBM Service Integration Capability Models ein: Die Aufbauorganisation.

Ausgehend von der Darstellung der Ablauforganisation/ der Prozessintegration, die wir im vergangenen Beitrag erläutert haben, wollen wir in diesem Beitrag diskutieren, wie denn die Aufbauorganisationen der einzelnen Provider strukturiert sein sollte.

Ausgangspunkt der Betrachtungen ist die Segmentierung der Prozesse in Anteile, die vom Service Integrator erledigt werden und in Anteile, die von den einzelnen Service Providern erledigt werden.

Die folgende Abbildung verdeutlicht die Aufteilung der Verantwortlichkeiten zwischen Service Integrator und Service Provider.

image

 
Abbildung: Prozessorientierte Aufbauorganisation

In der Praxis hat sich die Strukturierung des betrieblichen Anteils der Aufbauorganisation nach Prozessen bewährt.

Wenn wir bei unserem Beispiel Change Management bleiben, dann gibt es z.B. die Rollen „Change Coordinator“ und „Change Controller“ auf Seiten des Service Integrators und die dazu korrespondierenden Rollen des „Change Administrators“ und „Change Managers“ bei den einzelnen Service Providern.

Neben dem betrieblichen Anteil der Aufbauorganisation, der auch als operationaler Anteil bezeichnet wird gibt es noch die Anteile der Aufbauorganisation, die sich um die taktischen und strategischen Aufgaben kümmern.

Die Aufbauorganisation in diesem Bereich hängt wiederum stark von der gewählten Governance Struktur ab, auf die wir in einem der nächsten Beiträge eingehen werden.  
 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (5/12)

12. November 2014 Posted by Bernd Kueppers

IBM Service Integration Capability Model: Ablauforganisation.

 

Im vorangehenden Beitrag hatten wir das IBM Service Integration Capability Model als Vorgehensmodell für eine erfolgreiche Service-Integration vorgestellt. In diesem und in den nächsten Beiträgen gehen wir nun auf die einzelnen Dimensionen des Modells ein.

Dieser Beitrag beschäftigt sich mit der Ablauforganisation der Service Integration und somit mit der Frage:
Wie koordiniere ich die einzelnen Ablauforganisationen aller Beteiligten so, dass jeder weiß, was er wann zu tun hat?

Eine wichtige Voraussetzung für Service Integration ist die Prozessintegration. Das folgende Beispiel zeigt einen vereinfachten Change-Management Prozess zur Erläuterung der Prozessintegration in einer Multi-Sourcing Umgebung.

Auf der linken Seite des Bildes sehen wir die einzelnen beteiligten Organisationen, in diesem Fall 3 verschiedene Service Provider, den Service Integrator, das Service Desk und die Kunden-IT Organisation.
Die Service Integrator Funktion und der Service Desk können entweder selbst betrieben oder als Service eingekauft werden.
Alle Beteiligten können Anträge auf Changes (RfC) stellen.
Der Service Integrator managed den Change Prozess Ende zu Ende, vom Request for Change bis zum final „review and close“ des Changes.

Hierzu
-    organisiert der Service Integrator ein Change Advisory Board, in dem die beteiligten Service Provider und der Service Integrator Changes und ihre Auswirkungen auf die Gesamtumgebung besprechen.
-    holt er die Freigabe des Kunden ein, sofern eine Ergänzung der Leistung erforderlich wird
-    Koordiniert er Tests
-    Koordiniert Termine, an dem Changes bei den einzelnen Providern implemetiert werden
-    Reviewed die Ergebnisse und dokumentiert und schliesst den Change

image
 
Bildunterschrift: Change Management Prozess

Ein Teil einer gelungenen Service Integration ist also die Prozessintegration. Aber nicht alle Prozesse müssen vom Service Integrator so eng koordiniert werden wie Change Management. Die folgende Darstellung erläutert den unterschiedlichen Integrationsbedarf der einzelnen Prozesse.

Auf der linken Seite der Abbildung sind drei Provider dargestellt. Der eine kümmert sich um Anwedungen, der andere um Rechenzentren und der Dritte um die IT am Arbeitsplatz. Auf der x-Achse ist eine kleine Auswahl der Prozesse der Ablauforganisation dargestellt.

Wie wir grade gesehen haben, muss der Change Management Prozess aufgeteilt werden: In ein übergreifendes Prozess-Segment, das der Service Integrator verantwortet und Teilprozesse, die von den einzelnen Providern verantwortet werden. Diese sind hier als Change Execution bezeichnet.

Im Gegensatz zum Change Management gibt es auch Prozesse wie z.B. Performance Management oder Bereiche des Operations Management, die komplett in Verantwortung der einzelnen Provider liegen. So interessiert es z.B. den Netzbetreiber nicht, wie der Rz-Betreiber sein Performance Management macht und umgekehrt.

Außerdem ist unserer Erfahrung nach bei manchen Prozessen der Integrationsbedarf von Kunde zu Kunde unterschiedlich. Asset Management kann z.B. wie Change Management aufgeteilt sein, oder aber alleine in Verantwortung des Kunden verbleiben, wenn er z.B. alle Assets weiter in seiner Bilanz führen will. Der letztere Fall ist hier im Bild dargestellt.

image
 
Bildunterschrift: Prozessintegration


Soweit der Überblick zur ersten Dimension des IBM Service Integration Capability Models: Der Ablauforganisation.

Im nächsten Beitrag gehen wir dann auf die Aufbauorganisation ein.

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (4/12)

6. November 2014 Posted by Bernd Kueppers

Aufgaben des Service-Integrators / IBM Service Integration Capability Model :

 

Was tut ein Service Integrator, um Services aus verschiedenen Quellen zu einem Ende-zu-Ende Service zu integrieren?


Im vorangehenden Beitrag hatten wir Service Management als Ausgangspunkt der Service Integration beschrieben. Die Aufgabe des Service Integrators ist es nun, -bildlich gesprochen- aus den verschiedenen Service Management Dreiecken der einzelnen Service Provider ein neues, virtuelles Dreieck zu erzeugen, um ein ganzheitliches Service Management zu erreichen.

 

Typische Fragestellungen dabei sind:

 Ablauforganisation: Wie koordiniere ich die einzelnen Ablauforganisationen so, dass jeder Service-Provider weiß, was er wann zu tun hat?
 Werkzeugunterstützung: Wie verbinde ich die Werkzeuge der einzelnen Service-Provider und des Service Integrators?
 Aufbauorganisation: Wer sind die verantwortlichen Ansprechpartner in den jeweiligen Aufbauorganisationen?

Die Praxiserfahrung hat gezeigt, dass neben den drei Dimensionen des Service Managements drei weitere Dimensionen für das Gelingen der Service Integration relevant sind:
 Information: Definition von Daten und Datenstrukturen, die die Provider und der Service Integrator gemeinsam verwenden, um die Leistung zu erbringen und zu überwachen.
 Governance: Festlegung der Regeln der Zusammenarbeit zwischen Service Providern und Service Integrator
 Business: Festlegung der Regeln des Demand/Supply Managements zwischen Service Integrator und Service Providern

 

Die sechs Dimensionen gemeinsam werden als IBM Service Integration Capability Model bezeichnet:

 

image

 



  Abbildung: IBM Service Integration Capability Model

 
In den kommenden Beiträgen werden wir die einzelnen Dimensionen des Modells näher erläutern.

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (3/12)

29. Oktober 2014 Posted by Bernd Kueppers

Einer für Alle(s) – die Rolle des Service-Integrators

 
Nachdem wir über das Kunden-Feedback zu einer geeigneten Definition von Service-Integration gelangt sind, wird erkennbar, wer der heimliche Held der IT-Service-Integration ist: der Service-Integrator.

Wie im vorherigen Beitrag gezeigt, ist Service-Integration in ITIL V3 nicht definiert. Allerdings  hat der Markt selbständig ein einheitliches Verständnis entwickelt, was Service Integration bedeutet. Das IBM Technical Expert Council hat auf Basis von mehreren Kundendefinitionen Service-Integration definiert als:
 

 “IT Service Integration establishes End-to-End services based on independent IT services from various sources”

 

Gehen wir von dieser Definition aus – was folgt als nächstes? Dazu ist es wichtig zu verstehen, wie ein Service-Provider seinen Service produziert: mittels Service Management. Der Ausgangspunkt der Service-Integration ist also das Service Management.

Jeder einzelne Service wird von einer Aufbauorganisation mit Hilfe einer Ablauforganisation und Werkzeugen produziert. Das kann ein interner Service-Provider sein, d.h. eine IT-Abteilung im Unternehmen, oder ein externer Service-Provider, die beide mit eigenen ITIL-basierten Prozessen und einem Service-Management-Werkzeug einen Service produzieren. Prozesse und Werkzeuge sind dabei in der Praxis sehr unterschiedlich.

 

imageAbbildung: Drei Dimensionen hat das Service-Management – und daraus entspringt eine Vierte: die Service-Integration.

 

Wenn ein Unternehmen seine Services aus verschiedenen internen und externen Quellen bezieht, kommt zu den drei Dimensionen des Service Managements eine vierte Dimension dazu: eben die der Service-Integration. Service-Integration sorgt dafür, dass der Endnutzer nicht mehr davon „gestört“ wird, dass die Services aus verschiedenen Quellen stammen, auch wenn alle Services von verschiedenen Organisationen mit individuellen Prozessen und Werkzeugen produziert werden.

 

image

Abbildung: Die Service-Integration sorgt idealerweise für nahtloses und für den Nutzer unsichtbares Ineinandergreifen der verschiedentlich gesourcten Services.

 

Die Funktion, die Service-Integration leistet, nennt sich „Service-Integrator“. Dieser heimliche Held der gelungenen Service-Integration kann auf verschiedene Weise verkörpert werden:

1.) Service-Integration durch Kunden: Der CIO beschließt, eine Abteilung in seiner Organisation mit den Aufgaben des Service-Integrators zu beauftragen.

2.) Service-Integration durch Prime-Provider: Der CIO vergibt die Service-Integrator-Funktion im Rahmen einer Gesamtvergabe an einen Generalunternehmer.

3.) Unabhängiger Service-Integrator: Der CIO beauftragt einen erfahrenen externen Partner mit der Service-Integrationsleistung. Dieser Partner liefert ansonsten keinen der zu integrierenden Services.

4.) Service-Integration durch Main-Provider: Der CIO beauftragt denjenigen Provider mit der Service-Integration, der auch den Hauptteil der zu integrierenden Services leistet.

 

image

Abbildung:  Möglichkeiten zur Realisierung der Service-Integrator-Funktion

Alle vier Arten sind am Markt zu finden.

Organisationen, die bereits seit längerem Erfahrungen mit dem Bezug von Services aus verschiedenen Quellen haben und daher das notwendige Know-How zur Service-Integration bereits erworben haben, tendieren dazu, die Funktion des Service Integrators in der eigenen Organisation zu realisieren (Nr. 1). Organisationen, die dieses Know-How noch nicht erwerben konnten, können externe Unterstützung bei der Service-Integration erhalten (Nr.2-4).

Soweit unsere Erfahrungen zur Praxis der Funktion des Service-Integrators – für uns der heimliche Held der Service-Integration. Oder gibt es hier andere Meinungen?

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT (2/12)

22. Oktober 2014 Posted by Bernd Kueppers

 

 

 

image
Service-Integration ist definiert als…ups
Was ITIL V3 vergessen hat

 

 

 

©iStockphoto.com
 

Ja, so ist es: Wenn man die 1400 Seiten der fünf Bücher von ITIL Version 3 durchsucht, findet man keine Definition von „Service Integration“. Ohne geht es aber nicht. Wie eine Lösung aussehen könnte, das zeigen interessante Definitionsversuche der Anwender.

Durchstöbert man IT Infrastructure Library (ITIL) nach einer Definition des Begriffs „Service-Integration“, wird man nur an einer einzigen Stelle fündig: In den Service Design Principles. In Kapitel 3.11.3.2 Off-the-shelf solutions der Service Design Principles steht geschrieben: “A framework for selecting, customizing and implementing these off-the-shelf packaged solutions is needed and includes the need to: Define service integration requirements”...

Der Begriff wird also verwendet, ohne dass er dort definiert wird. Das wäre an sich kein Problem, wenn er denn anderswo einheitlich definiert wäre. Aber das ist leider nicht so. Es gibt derzeit keine allgemein akzeptierte Definition von „Service-Integration“.

Und so kommt es, dass die meisten Unternehmen eine eigene Definition von „Service-Integration“ entwickelt haben. Diese Definitionen finden sich dann zum Beispiel in Angebotsaufforderungen, die uns erreichen. In den letzten zwei oder drei Jahren haben wir auf diese Weise viele dieser Bestimmungen kennengelernt. Aus ihnen lässt sich recht gut ableiten, welche Aspekte von Service-Integration für den Anwender wesentlich sind:

- der Ende-zu-Ende-Charakter von Services (d.h. Es gibt nur einen Ansprechpartner für einen Service und nicht mehrere) und
- der Ursprung der Services aus verschiedenen internen oder externen Quellen.

Diese beiden Aspekte kommen in allen uns vorliegenden Kunden-Definitionen von „Service-Integration“ vor. Damit sind diese beiden Merkmale der „Service-Integration“ für uns das Maß aller Dinge und wir schlagen daher folgende Definition vor:

 “IT Service Integration establishes End-to-End services based on independent IT services from various sources.”

Wenn wir nun noch einmal das Beispiel aus dem ersten Beitrag dieser Serie ansehen, dann erkennen wir die verschiedenen Quellen der Services, interne wie externe. Und wir erkennen, dass es nur einen Ansprechpartner für den Nutzer geben darf: Einen Service-Integrator, der sich darum kümmert, dass ihm geholfen wird. Und über seine Rolle mehr im nächsten Beitrag.

 

image


 

 

Services – wie aus einer Hand! – Alles zum richtigen Vorgehen rund um Service-Integration in Multi-Sourcing/ Hybrid-IT

1. Oktober 2014 Posted by Bernd Kueppers

image

 

Mit den immer breiter am Markt verfügbaren Cloud- und IT-Service-Angeboten schreitet der Trend zur Kommodisierung von Services zügig voran. Doch auf welche IT-Service-Bereiche soll ich mich als IT-Verantwortlicher konzentrieren? Für welche Services nutze ich Partner? Welche kann ich einfach mit Cloud-Services abdecken?

In diesem Blog suchen wir Antworten auf diese und viele anderen Fragen rund um das Thema Service-Integration in Multi-Sourcing/Hybrid-IT.

 

©iStockphoto.com/lim_Isk

 

Das Angebot für Cloud- und IT-Services wird immer breiter, Services sind auf dem besten Weg, zu Commodities zu werden. Damit wachsen aber auch die Anforderungen an die IT-Abteilungen, denn sie müssen dafür sorgen, dass die vielen verschiedenen Services reibungslos ineinandergreifen. Schließlich soll das Endprodukt beim Nutzer „ganzheitlich“, also wie aus einem Guss, ankommen.

Damit das gelingt, reicht es nicht aus, dass jeder Service für sich einwandfrei funktioniert. Auch und vor allem das Miteinander muss stimmen, sprich die Integration der einzelnen, oft aus unterschiedlichen Quellen stammenden Services in einer hybriden IT-Landschaft.

Erreichen lässt sich das durch das richtige Vorgehen bei der Auswahl der Services und der Service-Integration. Und genau das werden wir hier im Blog diskutieren. Wir werden zeigen, wie sich geeignete Sourcing-Bereiche systematisch und nachvollziehbar identifizieren und zu einem ganzheitlichen Service integrieren lassen.

In regelmäßigen Beiträgen werden wir uns hier mit der Technologie der Service-Integration befassen, d.h. mit der Frage, wie ich es schaffe, dass Services aus verschiedenen Quellen so wirken, als kämen sie aus einer Hand. Geplant sind hier Beiträge zu Themen wie Definitionen, Ablauforganisation, Werkzeuge, Aufbauorganisation, Informationen, Governance, Cloud-Services und Hybrid-IT und nicht zuletzt zu kaufmännischen Aspekten.

Außerdem wollen wir erläutern, wie IT-Verantwortliche geeignete Sourcing-Kandidaten identifizieren können und welche Services in einer konkreten Unternehmenssituation sinnvoll gesourced werden können. Dabei werden wir Fragen nachgehen, wie: Woher kommt der aktuelle Trend zu Multi Sourcing/ Hybrid IT? Oder: Wie finde ich systematisch heraus, welche Services ich sourcen könnte?

Auf Diskussionsbeiträge, Tipps und Themen-Anregungen freuen wir uns natürlich sehr!

 

image

Das Ganze ist mehr als die Summe der Teile:

Services werden heute mehr und mehr zur Commodities – nur sollten sie richtig integriert sein, damit sie beim Nutzer auch so ankommen.