Posts Tagged: ‘hybrid’

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

29. Januar 2015 Posted by Bernd Kueppers

Entwicklung bzw. Fortschreibung der IT-Sourcing Strategieimage

(geschrieben von Bernd Küppers & Frank Deleiter)
 
Im vorangehenden Beitrag haben wir diskutiert, warum immer mehr Unternehmen IT-Sourcing betreiben und welche Möglichkeiten es dazu gibt. In diesem Artikel möchten wir nun Anregungen geben, wie man als Unternehmen seine individuelle IT-Sourcing Strategie festlegen kann.

Eine IT-Sourcing Strategie sollte Teil einer unternehmensweiten Sourcing-Strategie sein, in der die Unternehmensleitung festlegt, wie die Fertigungstiefe des Unternehmens in den einzelnen Bereichen der Organisation sein sollte bzw. nach welchen Kriterien die Fertigungstiefe zu bestimmen ist. Damit ist eine Sourcing-Strategie immer individuell auf ein Unternehmen zugeschnitten.

Die Entwicklung dieser Strategie besteht wie im Schaubild illustriert typischerweise aus mehreren Schritten:image
 
1. Start und Strategische Analyse

Nach der Basisklärung (u.a. Grundzweck der Aufgabenstellung, Umfang der Untersuchung, strategische Rahmenbedingungen und Strukturüberblick hinsichtlich der IT- Leistungen) muss als zentraler Ausgangspunkt aller Sourcing-Überlegungen festgestellt werden, inwieweit ein Unternehmen bereit ist, Verantwortung und Ressourcen (zwischen intern und extern) zu verteilen. Dadurch kann sich der Lösungsraum der Sourcing Varianten zielgerichtet eingrenzen. Die Optionen wie „Eigenbetrieb“, „Teil-Sourcing“, „Total-Outsourcing“ ebenso wie die mögliche zukünftige Form der Zusammenarbeit werden initial bewertet und ein Sourcing-Profil definiert.

Ebenso wichtig ist die Einschätzung der Kernkompetenzen der IT. Für Kernkompetenzen einer IT sollte lediglich internes Sourcing weiter verfolgt werden. Für alle weiteren Aufgabenbereiche (Nicht-Kernkompetenzen) kann weiter auf Produktivitätserhöhung hin untersucht und damit auch die Option des externen Sourcing weiterverfolgt werden.

In der strategischen Analyse wird weiterhin ein Bewertungsmodell entwickelt und verabschiedet. Abhängig von der Granularität der Serviceblöcke sollte aus Effizienzgründen das Modell Kriterien für eine Vorfilterung enthalten, da es für manche Aufgabenbereiche bzgl. externem Sourcing keinen Sinn macht, weiter zu untersuchen. Als Filter-Kriterien eignen sich beispielsweise „Service ist Kernkompetenz“, „Gering eingestufte Reife eines Services bei IT Providern“ oder „Aufwandsteil für den Service zu gering“.

Für die verbleibenden Servicebausteine sind die Kriterien für die eigentliche Bewertung der Service-Kandidaten festzulegen. Als Bewertungskriterien eignen sich beispielsweise: Aufwand, Kosten, Volumenschwankung, heutige Einschätzung der Fertigkeiten und Grad der Industrialisierung sowie der Dokumentationsstand. Sie können Indikationen bzgl. des Nutzens von Sourcing und dem mit der Transformation zum Sourcing verbundenen Aufwand geben.

Im Vorfeld sollte geklärt sein, inwieweit vorhandene Skills im Rahmen des Projekts berücksichtigt werden sollen und ggf. durch eine optionale Organisationsanalyse mit erhoben werden sollen. Diese sind insbesondere beim Transfer von Sourcing-Kandidaten in den definierten Kernkompetenzen von Relevanz. Entsprechend ist dies bei den Kriterien dann (z.B. als Aufwand für Personaltransfer) zu berücksichtigen.

2. Bewertung ausgewählter Service-Bausteine

In dieser Phase erfolgt die eigentliche Evaluierung von Service-Bausteinen mit dem definierten Team der IT Organisation. Nach der Wertung der Kriterien sollte erkennbar sein, welche Service-Bausteine gleichzeitig einen großen Nutzen versprechen und vertretbaren Transformationsaufwand indizieren.

3. Bewertung der Steuerungsfähigkeit

In der dritten Phase wird untersucht, ob die Fähigkeiten zur Service Integration der Services von verschiedenen Dienstleistern gut genug ausgeprägt sind, oder in welchem Bereich diese Fähigkeiten noch verbessert werden sollten. Die Bewertung der Fähigkeiten zur Service Integration kann sehr gut entlang der sechs Dimensionen des IBM Service Integration Capability Models erfolgen, wie in den vorangehenden Beiträgen dieses Blogs beschrieben (4/12 bis 10/12).
Falls die Fähigkeiten zur Service Integration nicht hinreichend ausgeprägt sind, dann kann es in der Folge zu Problemen bei der Zusammenarbeit mit den Service Providern und zu spürbaren Einbußen bei der Service-Qualität kommen. Daher ist es wichtig, das richtige Maß an Fähigkeiten zur Service Integration rechtzeitig zu entwickeln – oder sich von einem erfahrenen Partner an dieser Stelle Unterstützung zu holen.

4. Entwicklung und Abstimmung der Sourcing-Strategie

In dieser Phase wird nach Kenntnis der aussichtsreichsten Service-Kandidaten ein sinnvoller Service-Schnitt entwickelt. Dabei werden typischerweise einzelne Bausteine wieder zugunsten der Volumengrößen und Steuerungsaufwände zu größeren Sourcing-Blöcken zusammengeführt. Die so entstandenen Sourcing-Blöcke werden ggf. auch um weitere angrenzende Aufgabenbereiche ergänzt, die in der Einzel-Bewertung als Service-Kandidaten nicht aussichtsreich erschienen.

Teil des Zielbilds für das Sourcing Modell ist eine Roadmap zur Optimierung der Steuerungsfähigkeit von IT Dienstleistern und ein grundlegendes Zusammenarbeitsmodell mit den Providern.

An dieser Stelle kommt bzgl. der eigentlichen Sourcing Strategie ein Meilenstein zur Abstimmung mit der Geschäftsführung, bevor es dann mit den nächsten Phasen weitergeht:

5. Vorbereitung der Umsetzung des Zielbildes

Nach der Abstimmung und Entscheidung bzgl. eines oder mehrerer Piloten sind für die ausgewählten Serviceblöcke die Anforderungen so zu beschreiben, dass ein angefragter Provider ausreichend Informationen hat, um einen RFI zu beantworten. Der Provider wird beauftragt, die Kosten für den ausgewählten Piloten zu schätzen. Weiterhin sind die Auswirkungen auf betroffene Mitarbeiter zu beleuchten und zu bewerten. Die Mitarbeiter eines Sourcing Blocks sind bzgl. ihrer Skills in andere Bereiche zu entwickeln, was mit Kosten verbunden ist. Auch die kundenspezifische Erfahrung bzgl. der Mitarbeiterfluktuation muss einfließen. Diese und andere durch personelle Veränderungen bedingte größere Kostenblöcke müssen im Business Case berücksichtigt werden.


6. Business Case für Pilotservices

Im Business Case wird die Wirtschaftlichkeitsbetrachtung für einen zu definierenden (typischerweise 3-5 Jahre) Zeitraum durchgeführt. Die zwischenzeitlich beim Provider angefragten Kosten für den ausgewählten Piloten sollten jetzt vorhanden sein, damit die Ist-Kosten den Kosten des Providers plus Transformationskosten gegenübergestellt werden können. Obwohl Kosteneinsparung bei vielen Kunden gar nicht mehr als primäres Ziel einer Transformation zum Outsourcing gesehen wird, sollte immer eine angemessene Transparenz zum Kostenverlauf die Erwartungshaltung klären.

Ab diesem Punkt können die Sourcing Entscheidung getroffen werden und die Sourcing Strategie weiter umgesetzt werden. Die Ausschreibung kann beginnen.


Sourcing-Strategie-Zyklus

Da sich die Rahmenbedingungen für Unternehmen rasch verändern können, sollte die Sourcing-Strategie regelmäßig auf Aktualität geprüft und fortgeschrieben werden. Dazu sollten schon bei der ersten Entwicklung der Strategie und danach in jedem neuen Zyklus Ziele definiert werden, die in der Folge dann umgesetzt und hinsichtlich der erfolgreichen Umsetzung überprüft werden.   

Diese Sourcing Ziele sollten wie üblich “SMART” („Specific, Measurable, Accepted, Realistic, Timely”) formuliert sein, damit die Aktivitäten zur Erreichung der Ziele gut als Projekt steuerbar sind.

Ein mögliches Ziel ist zum Beispiel, dass in einem Zeitraum von 6 Monaten folgendes erreicht werden soll:
•    Es werden 5 Service-Kandidaten identifiziert und jeweils in einem Service-Steckbrief beschrieben
•    Von diesen 5 Service-Kandidaten werden die aussichtsreichsten 1-2 Kandidaten ausgewählt und näher untersucht
•    Die 1-2 Kandidaten sollen innerhalb von weiteren 6 Monaten realisierbar sein
•    Die durch Sourcing realisierte Einsparung soll –nach Abrechnung der für die Service Integration entstehenden Kosten- mindestens x Mio. € p.a. betragen.
Im Beispiel wird von der Annahme ausgegangen, dass das häufig angefragte „selektive Sourcing“ im Sourcing Profil definiert wurde.

Bei regelmäßiger Überprüfung mit Blick auf diese Ziele kann die Unternehmensleitung den Stand der Umsetzung und Zielerreichung überblicken, steuernd eingreifen und ggf. den nächsten Zyklus des Strategie-Prozesses einleiten, um die Strategie zu aktualisieren.

Der typische Zeitraum für einen Strategie-Zyklus liegt bei ca. einem Jahr. Aufgrund der dynamischen Veränderungen am Sourcing-Markt liegt die Dauer bei manchen Kunden auch schon deutlich darunter.


Mit diesem Beitrag kommen wir zum Abschluss der Serie zu Service-Integration in Multi-Sourcing/ Hybrid IT. Wir bedanken uns für Ihr Interesse und hoffen, dass wir hilfreiche Anregungen geben konnten. Wir sind natürlich auch weiterhin immer ansprechbar, wenn Sie Fragen rund um die Themen Sourcing und Service-Integration haben sollten.
Zu diesen Themen werden wir auch zukünftig bei Gelegenheit hier weitere Artikel veröffentlichen.

Bis dahin nochmals Vielen Dank für Ihr Interesse.
 

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 (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.