Outsourcing, Offshoring & Alliances - Transition

=
Phase 3: Transition =

Implementierung, Transition

Die Implementationsphase ist im Standardfall ein klassisches Projekt.

Es hat fast immer alle Merkmale eines großen Organisationsprojektes wie

• Firmenübergreifend und manchmal auch länderübergreifend

• Großes Projektbudget

• Großer Zeitdruck

• Komplexe Anforderungen

Die Implementierungsphase bei großen Outsourcingprojekten realisiert eine umfassende, bereichsübergreifende und inhaltlich weit reichende Veränderung. Es muss neben der Lösung der technischen Herausforderungen auch berücksichtig werden, dass sehr viele Personen im Unternehmen nach der Transition andere Aufgaben, andere Kollegen, einen anderen Arbeitsort oder gar keine Arbeitsstelle mehr haben. Um die Betroffenen dennoch zur Mitarbeit zu motivieren ist ein großes Fingerspitzengefühl seitens des Projektleiters erforderlich.

Die technischen Anforderungen sind meist auch sehr groß, können aber bei guter Vorbereitung in der Due Diligence Phase auch von einem geübten Projektmanager ohne IT-Spezialwissen abgewickelt werden. Der Projektleiter muss allerdings bei der Ausarbeitung der Leistungsverträge bereits aktiv eingebunden sein.

Die technischen Details unterscheiden sich natürlich von Projekt zu Projekt. Auf der Metaebene haben diese Projekte immer zwei Hauptaufgaben. Es sind dies die technische Implementierung und die Integration der Mitarbeiter.

Integration der Technik

Hier wird sich in fast allen Fällen der Ort der Leistungserbringung verändern. Prinzipiell sind informationstechnische Dienstleistungen nicht an Örtlichkeiten gebunden. Es gibt aber eine Reihe von technischen Details deren Nichtbeachtung für den Endbenutzer zu einer Nichtverfügbarkeit der Systeme führen kann (z.B. IP-Adressenänderung oder Serverkonsolidierung).

Zentraler Aspekt dieser Phase ist ein funktionierendes Business Continuity Management. Da sich in der Transition Phase unter Umständen bei mehreren Prozessen, die Prozessverantwortlichen ändern und auch die Schnittstellen organisatorisch und technisch geändert werden, besteht in dieser Phase die größte Gefahr einer Prozessunterbrechung für das Unternehmen. Der einzige Vorteil dabei ist, dass bei sorgfältiger Vorbereitung die möglichen Gefahrenpunkte sachlich und zeitlich relativ genau definiert werden können. Da nicht alle Aspekte im Vorhinein getestet werden können, ist ein Business Continuity Plan unerlässlich. Das bedeutet, dass man für die wesentlichen Teilschritte, ein Fallback-Szenario vorbereiten muss.

Neben der funktionellen Planung dieser Szenarien muss auch der Zeitplan so definiert sein, dass zumindest ein Teil der Notszenarien so eingeplant ist, dass keine Terminüberschreitung dadurch verursacht wird.

Man sollte aber in der Implementierungsphase nur die aufgrund des neuen Umfeldes notwendigen Änderungen durchführen. Eine Optimierung des Betriebes in dieser Phase wird das Projekt meist überfordern und kann Ursache für ein Scheitern sein.

Typische kritische Phasen sind zum Beispiel, die Umschaltung von Datenleitungen zwischen verschiedenen Anbietern und Standorten oder ein erzwungener Wechsel eines Betriebssystems im Transition Projekt.

Integration der Mitarbeiter

Die Integration von Mitarbeitern ist nicht nur ein Thema wenn ein großer Teil der Mitarbeiter zum Outsourcer wechselt. Auch wenn keine Mitarbeiter den Dienstgeber wechseln (Shared Service, Beibehaltung der personalrechtlichen Zugehörigkeit, etc) bedeuten solche Projekte immer eine massive Änderung der Organisation speziell der Kommunikationswege sowie der Arbeitsinhalte.

Die Integration von Mitarbeitern in eine neue Organisation ist oft anspruchsvoller als die Integration der Technik. Die Qualität der IT-Dienstleistung steht und fällt maßgeblich mit der Qualifikation und besonders der Motivation der Mitarbeiter. Werden Mitarbeiter übernommen, müssen diese in die für sie neue Struktur sukzessive überführt werden. Eine frühzeitige Einbindung der Mitarbeitervertretungen und Mitarbeiter bereits während der Detailanalyse ist wichtig. Dies kann in Form von Workshops, Einbindung des Betriebsrates und einer offenen Kommunikation mit den zu übernehmenden Mitarbeitern geschehen.

Transitionsansatz anhand eines Beispieles

Abbildung 14: Besonderheit im Transitionsprojekt

Während bei der Evaluierung die ganzen Prozesse betrachtet werden, sind die anderen Phasen des Projektes nach Sachthemen strukturiert. Je nach Outsourcinggegenstand (Prozesse, Teilprozesse) werden sich bereits in der Due Diligence Phase jeweils andere Personen bei den Verhandlungen gegenübersitzen.

Bei der Ausformulierung der Teilaspekte sind die Sachkenntnisse wesentlich. Am deutlichsten merkt man diese Unterteilung in der Transition Phase. Hier sind je Sachgebiet/Teilprozess/Applikationen jeweils eigene Teilprojekte mit unterschiedlichen Teams zu definieren. Je nach Abhängigkeiten zwischen den Applikationen können diese tw. oder zur Gänze parallel abgewickelt werden. Es müssen allerdings für jedes Teilprojekt die oben angeführten Überlegungen bezüglich Business Continuity Management bzw. Wiederaufsetzpunkte geplant werden.

Auch im Betrieb ist im Normalfall die Struktur genau erkennbar. Häufig wird für jede Applikation ein eigener Leistungsvertrag abgeschlossen. Diese Teilverträge können sowohl unterschiedliche Service Levels als auch unterschiedliche Laufzeiten haben.

Bei Cloud Computing werden nur eine oder mehrere Applikationen vom Anbieter abgelöst (SaaS) oder vom Anbieter übernommen (PaaS). Das Transition Projekt besteht in diesem Falle nur aus Datenübernahme, Datenmigration und Test der Daten. Da bei diesen Projekten praktisch immer die Applikation wechselt, kann kaum eine 1:1 Übernahme erfolgen. Müssen danach historische Daten übernommen werden so ist dies häufig mit einem größeren Migrationsaufwand verbunden.

Ein Aspekt ist auch das Zeitverhalten der Applikation, das oft erst nach Übernahme aller Produktionsdaten wirklich getestet werden kann.

Transition vs. Transformation

Im Übergang der Leistung an den Outsourcer sind oftmals zwei Phasen abzugrenzen: Transition und Transformation.

Die Transition ist dabei ein rein horizontaler Prozess. Die Leistungserbringung wechselt vom Outsourcing-Kunden oder vom Bestandsvendor (auch oft als Incumbent Provider bezeichnet) zum neuen Outsourcer. Die Art der Leistungser­bringung bleibt dabei jedoch im Kern unverändert (CMO / Current Mode of Oper­ations). Die Transformation hingegen ist ein vertikaler Prozess, der die Leistungs­erbringung verändert und in den sogenannten Future Mode of Operation (FMO) bringt. Die Transformation spielt dabei eine wesentliche Rolle, denn damit können erst die eigentlichen Ziele des Outsourcings erreicht werden. Eine Transformation befasst sich beispielsweise mit der Konsolidierung von Prozessen, Applikationen, der Reduktion und Standardisierung von Hard- und Software, etc. Abbildung 15 zeigt den Zusammenhang von Transition, Transformation, dem CMO und dem FMO.

Nun kann eine Transformation bereits im Zuge einer Transition oder erst danach stattfinden. Viele Entscheidungsträger werden erstere Variante nachfragen, da damit in der Regel auch schneller die erwarteten Ziele eintreten können. Dem entgegen steht die gewaltige Komplexität, die durch die Vermischung von Transition und Transformation entsteht. Die Gestaltung des Übergangs sollte damit genau überlegt werden.

Abbildung 15: Transition und Transformation

=
Phase 4: Betrieb =

Dies ist zeitlich gesehen die längste Phase des Outsourcings. Ab diesem Zeitpunkt gelten die Leistungsverträge und der Outsourcer ist für die Leistungserbringung voll verantwortlich (Change of Control).

Wichtig sind am Beginn dieser Phase eine klare Festlegung der Einzelrollen und Gremien inklusive Ihrer Aufgaben und Kompetenzen. Die Organisation wird zwar je Outsourcinggegenstand etwas unterschiedlich aussehen, einige Rollen sollten aber auf jeden Fall vorhanden sein.

Eine wesentliche Rolle auf beiden Seiten ist die des Single Point of Contact. Zusätzlich gibt es normalerweise ein Betriebsführungsteam, das die Produktion auf beiden Seiten plant und abwickelt. In diesem Team ist dann auch die Funktion des operativen Controllings vertreten.

Meist ist dann auch ein Lenkungsausschuss eingerichtet, der sowohl die strategischen Aspekte der Zusammenarbeit beachtet und auch als Eskalierungsgremium im Problemfall dient. Der Lenkungsausschuss sollte mit entscheidungsbefugten Managern besetzt sein, damit im Krisenfall auch rechtzeitig Entscheidungen getroffen werden.

Betriebsphase

Der Betrieb muss möglichst rasch etabliert werden. Am Beginn sind noch häufig die Betriebshandbücher zu erstellen oder zumindest an die geänderten Bedingungen beim Outsourcer anzupassen. Wichtig ist der Aufbau einer funktionierenden und klaren Kommunikation. Hier kann es durchaus zu Änderungen der geplanten Kommunikation kommen, da die Situation oder die Kommunikationsfähigkeit der handelnden Personen falsch eingeschätzt wurden. (s. 8.12)

Das geplante Reporting und Controlling kann sich auch im ersten Jahr noch ändern. Speziell die Zeiträume und die Detailgenauigkeit kann erst im täglichen Betrieb den Erfordernissen angepasst werden.

Auch wenn das Change Management für Leistungsverträge in den Verträgen bereits vordefiniert ist, können in der Praxis kleinere Änderungen der Vorgehensweise zielführend sein. Sobald sich solche Änderungen bewährt haben, müssen Sie aber in den Leistungsverträgen nachvollzogen werden.

Generell sollte man in der Betriebsphase von Anfang an genügend Raum für kontinuierliche Verbesserungen lassen.

Single Point of Contact (SPoC)

Eines der Hauptprobleme in der Startphase ist die geänderte Kommunikation.

Ausgangssituation:

Auch wenn beim Auftraggeber bereits Werkzeuge und Verfahren für den Betrieb im Einsatz waren (Trouble Ticket System) so werden diese häufig von menschlich verständlichem Verhalten unterlaufen. Aufgrund der persönlichen Kontakte zwischen den Kunden und dem Servicepersonal im Betrieb gibt es immer wieder Versuche, die Verfahren durch Gangbeauftragung oder Direktkontakt mit den Servicemitarbeitern zu umgehen. Auch sind die Servicemitarbeiter aufgrund der persönlichen Beziehungen einem stärkeren indirektem Druck ausgesetzt, Dinge außerhalb des Systems zu erledigen.

Diese Umgehung führt zwar bei einigen Kunden zu manchmal besseren Reaktionszeiten und höheren Prioritäten. Insgesamt über das Unternehmen gesehen wird der Service dadurch allerdings schlechter.

In der neuen Situation gibt es die persönlichen informellen Kontakte zumindest am Beginn überhaupt nicht. Es erfolgt also die Servicierung genau nach dem vorliegenden Leistungsvertrag. Dies wird von den bisher privilegiert behandelten Personen als Verschlechterung empfunden.

Lösung: SpoC auf beiden Seiten

Um die Service möglichst rasch und reibungslos implementieren zu können, muss eine geordnete für beide Seiten zufriedenstellende Kommunikation aufgebaut werden. Dies geschieht meist durch die Installation eines Single Point of Contact.

Die Kommunikation von auftretenden Problemen ist ausschließlich über das Incident Management (Help Desk) abzuwickeln. Für darüber hinausgehende Probleme fungiert der SPoC als Relaisstation. Damit wird gewährleistet, dass alle Probleme dokumentiert sind und an die richtige Stelle kommuniziert werden.

Die Kontaktperson soll beide Unternehmen kennen, alle Prozesse einigermaßen verstehen, die Leistungsverträge gut kennen und am Beginn auch im Tagesgeschäft mitwirken. Diese Person ist spätestens bei der Due Diligence Phase in das Projekt einzubinden, da er dann nicht nur den Vertragstext sondern auch die Gründe warum es dazu gekommen ist kennt. (Geist des Vertrages)

Spezialfall IT Support

Der Auftraggeber muss die Betriebsprozesse des Auftragnehmers zumindest verstehen.

Fast alle großen Anbieter sind ISO 20000 zertifiziert. Das heißt, sie wickeln den Betrieb nach ITIL (IT Infrastructure Library) Definitionen ab. In ITIL sind die wesentlichen Betriebsprozesse beschrieben. Die untenstehende Abbildung 16 zeigt die nach ITIL V2 definierten Betriebsprozesse. Obwohl es inzwischen bereits ITIL V3 gibt sind noch viele Unternehmen nach dem älteren Standard organisiert. Deshalb wurde die Darstellung vom Autor gewählt.

Abbildung 16: Prozessmodell für den Betrieb (nach ITIL 2)

Monitoring, Reporting und Controlling

Art und Häufigkeit des Reportings sollte weitgehend bereits im Vertrag vereinbart werden. Reporting zeigt im Nachhinein den Grad der Erfüllung der Service Levels und auch ihre tendenzielle Entwicklung. Zum Unterschied vom Monitoring ist das Reporting vergangenheitsorientiert. Es dient nicht dazu im Fehlerfall sofort Maßnahmen treffen zu können, sondern ist ein Instrument für einen Lenkungsausschuss der eher langfristige Maßnahmen oder auch Vertragsmodifikationen beschließen kann..

Controlling ist hingegen wesentlich weiter gefasst als Reporting.

Cloud Controlling:

Das Controlling sollte dabei folgende Aspekte berücksichtigen:

1. Einhaltung der vereinbarten funktionalen Leistungen.

2. Einhaltung der vereinbarten rechtlichen Rahmenbedingungen (Datenschutz, Sicherheitsbestimmungen, etc.)

3. Rechnungscontrolling:
   Stimmen die abgerechneten Mengen mit den genutzten Mengen überein? Wurden die vereinbarten Preismodelle berücksichtigt?

4. Anbieterbewertung:
   Eigentumsverhältnisse, wirtschaftliches Rating, ev. Benchmarks

Aktivität	Ergebnis, Themen
Überprüfen auf strategischer Ebene Controller	Validierte Strategien, Prozesse, Strukturen, Zielerreichung, Koordination, Kulturintegration und Abgleich, IT-Plattform, Managementsysteme, Know How Transfer, Kundenorientierung, Ressourcen, Kosten, Win/Win-Konstellation
Überprüfen auf operativer Ebene Betriebsverantwortlicher (AG), SPoC	Schnittstellen Management, SLA’s, Qualität, Trouble Shooting, Weiterbildung, Budget, Qualitätsaudits, Know How Transfer, Frühwarnsysteme, Prozesskosten, Eskalationsverfahren, Zielvereinbarung pro Mitarbeiter, Kommunikation

Tabelle 12: Controlling - Hauptaktivitäten

Der Betriebsverantwortliche des Auftraggebers hat gemeinsam mit dem SPoC die Steuerung des Outsourcers in seiner Verantwortung. Er muss darauf achten, dass die vereinbarte Qualität eingehalten wird, entscheidet gemeinsam mit dem Outsourcer über Sofortmaßnahmen, überwacht die Prozesskosten und veranlasst Qualitätsaudits.

Der Controller (auf beiden Seiten) hat eher strategische Aufgaben. Er prüft ob die Prozesse noch gültig sind, überprüft in erster Instanz die Zielerreichung, achtet darauf ob genügend qualifizierte Ressourcen zur Verfügung stehen, überwacht die Kostenentwicklung und ist auch bei geplanten Änderungen der IT-Plattformen oder der Managementsysteme rechtzeitig einzubinden.

Kriterien zur Bewertung des ON

In der Betriebsphase sollte der Outsourcer in regelmäßigen Abständen (zumindest jährlich) von den Kunden und Kontaktpersonen bewertet werden. Bewertungskriterien können sein:

• Termingetreue Leistungserbringung

• Qualität der Leistung

• Kostentransparenz

• Flexibilität

• Fachkompetenz

• Sozialkompetenz

• Innovation

• Einbezug des Outsourcinggebers

• Rasche Informationsvermittlung

• Kundenorientierung

Change Management in der Betriebsphase

Die in den Leistungsverträgen vereinbarten Leistungen können sich während der Betriebsphase durchaus ändern. Meist sind es Zusatzwünsche des Kunden oder auch gänzlich neue Projekte, die der Kunde mit dem Outsourcer gemeinsam durchführen möchte.

Beispiele für Projekte oder Änderungswünsche, die nach einem RZ-Outsourcing während der Betriebsphase anfallen könnten sind:

• WAN – Bandbreitenänderung

• Einführung von VoIP

• Einbindung von mobilen Usern

• Einführung eines Supply Chain Management

• Erhöhte Security – Anforderungen

• Anpassung an die Marktpreise für die vereinbarten Leistungen

• Geänderte Ansprechpartner

Bei Erfüllung dieser Wünsche ändert sich natürlich auch der monatliche Preis der Leistung. So ist es durchaus üblich, dass nach halber Laufzeit des Vertrages bereits 50% der Kosten für ursprünglich nicht vereinbarte Leistungen anfallen (siehe auch Abbildung 17). Dies ist nicht auf schlechte Planung zurückzuführen sondern zeigt, dass das partnerschaftliche Verhältnis gut funktioniert.

Abbildung 17: Entwicklung des Auftragsvolumens über die Vertragszeit

Cloud spezifische Aktivitäten

Zum Unterschied zu herkömmlichen Outsourcingmodellen wird man bei Cloud Projekten regelmäßige Datensicherungskopien anfertigen, um im Falle von Totalverlust der Daten oder Insolvenz des Cloud Betreibers zumindest mit Altdaten weiterarbeiten zu können.

Es sollte auch laufend geprüft werden, ob die Daten lesbar, und in gebräuchliche Formate konvertierbar sind.

Change Management bei Vertragsende

Die Outsourcingverträge haben immer eine mehrjährige Vertragszeit.

Es ist im Interesse des Auftraggebers, sich die Möglichkeit eines Anbieterwechsels oder einer Rücknahme des Outsourcings offenzuhalten. Dies funktioniert erfahrungsgemäß nur dann ohne große Probleme, wenn die Bedingungen bei Vertragsende bereits bei den Vertragsverhandlungen angesprochen wurden und auch im Vertrag Ihren Niederschlag fanden.

Nach Ablauf der Vertragslaufzeit bzw. rechtzeitig davor überprüft der Auftraggeber folgende Punkte:

• Werden für die nächsten Jahre andere Services oderandere Mengengerüste benötigt als in der Vergangenheit?

• Haben sich die Marktpreise für die bezogenen Leistungen wesentlich verändert?

• Gibt es inzwischen neue ernstzunehmende Anbieter am Markt?

• Benötigen die Leistungsinhalte und Serviceziele eine Anpassung?

• Können bestimmte Funktionen oder Services inzwischen besser intern erbracht werden?

Manche dieser Punkte lassen sich bei guten Verträgen auch während der Laufzeit modifizieren. Die Verhandlungsposition ist allerdings kurz vor Ablauf des Vertrages wesentlich besser.

Es ist deshalb üblich die Services nach Ablauf der Vertragszeit neu auszuschreiben. Wenn das Verhältnis zwischen Auftraggeber und Auftragnehmer gut war, kann davon ausgegangen werden, dass der bisherige Partner wieder zur Angebotslegung eingeladen wird. Er wird aufgrund seiner intensiven Detailkenntnis durchaus höhere Chancen als neue Mitbewerber haben.

Sollte der bisherige Partner aber nicht mehr anbieten oder nicht mehr den Zuschlag erhalten, ist es für den Auftraggeber sehr wichtig, folgende Punkte bereits im Vertrag inkludiert zu haben:

• Mitwirkung des bisherigen Partners beim Wechsel zum neuen Partner. Hierbei müssen sowohl der Umfang in Manntagen als auch die Qualifikation der Mitwirkenden definiert sein.

• Herausgabe aller erforderlichen Unterlagen und Aufzeichnungen. Es sind dies die Betriebshandbücher, gemeinsam entwickelte Jobs, Programmadaptierungen aber auch Logfiles.

Nur wenn dies ausreichend definiert war, bleibt der Auftraggeber Herr seiner Entscheidungen.

Trends im Outsourcing

Generell erkennbare Trends

Der Beginn des Outsourcings war gekennzeichnet von immer größer werdenden Deals zwischen Großkonzernen. Viele Großunternehmen fanden, dass Ihre IT keine Kernkompetenz für das Geschäft darstellt und lagerten sie in der Folge aus. In manchen Fällen geschah dies nur in Form von sogenannten Shared Services. Das bedeutete, die Unternehmen gründeten eine IT-Tochtergesellschaft und beauftragten diese mit Ihren IT-Agenden. Der Hintergedanke war in vielen Fällen, dass das IT-Unternehmen mittelfristig nicht nur die IT der Muttergesellschaft betreiben sollten, sondern Ihre Dienstleistung auch am freien Markt anbieten sollten.

Besonders häufig war diese Überlegungen bei den europäischen Banken.

Im Falle eines echten Outsourcings an ein Drittunternehmen mussten diese aufgrund der Größe der IT des Auftraggebers ebenfalls sehr große Unternehmen sein. In der damaligen Zeit war die IT mit sehr großen Investitionen verbunden, so dass nur wenige Big Player dafür in Frage kamen. Es waren dies Unternehmen wie EDS, IBM, Siemens, die deutsche Telekom Tochter t-Systems und einige andere.

In den Neunzigerjahren änderten sich aufgrund der technologischen Entwicklung die Randbedingungen wesentlich.

Diese Randbedingungen waren:

• Starker Preisverfall bei Prozessoren und Speichern und damit rascher Rückgang der Hardwarekosten.

• Ablöse vieler Hostsysteme durch Unix-Systeme und später sogar durch Windowsbasierende Systeme.

• Besonders starken Einfluss hatte die Virtualisierung der Serversysteme.

Zusätzlich zu den technischen Randbedingungen änderte sich auch durch die Globalisierung der Anbieter-Markt. Es war plötzlich möglich, IT-Dienstleistungen von weit entfernten Ländern zu beziehen. Durch die rasch anwachsenden verfügbaren und leistbaren Datenverbindungen, war es nicht mehr nötig, dass der Anbieter in geografischer Nähe sein Rechenzentrum betrieb.

Diese Art des Outsourcings ist durch zwei Begriffe geprägt:

Offshoring: Beziehung der Leistung aus einem weit entfernten Land, mit meist sehr geringen Lohnkosten und gut ausgebildeten Mitarbeitern.

Nearshoring: Beziehung der Leistung aus den Nachbarländern im Osten, mit den gleichen Randbedingungen.

Unabhängig vom Offshoring und Nearshoring war es aufgrund der technologischen Entwicklung plötzlich auch wesentlich kleineren Unternehmen möglich, Rechenzentrumsdienstleistungen anzubieten.

Der Effekt war in den letzten Jahren eine Verschiebung bei den Outsourcingprojekten von Großprojekten mit Gesamtoutsourcing der IT hin zu kleineren Projekten bei denen häufig nur Teile der IT an kleinere Partner outgesourct werden.

Dieser Trend ist besonders in Mitteleuropa erkennbar, da hier die durchschnittliche Unternehmensgröße wesentlich geringer ist als etwa in USA oder in Großbritannien.

Bei der Laufzeit der Verträge war keine so große Änderung zu bemerken. Es scheint zwar, dass die sehr großen Vertragslaufzeiten (>5 Jahre) eher seltener werden. Vereinzelt findet man aber doch immer wieder Laufzeiten von 10 Jahren. Der häufigste Wert ist aber eine Laufzeit von ca 3 Jahren.

Virtualisierung

Kennzeichen der bisher besprochenen Outsourcingvorhaben war die Tatsache, dass es sich immer um eine genau definierte Hardware und Software handelte.

In den vergangenen Jahren rückte der Servicebegriff immer mehr in den Mittelpunkt. Es wurde den Unternehmen immer mehr bewusst, dass es sich nicht um eine Hardware mit einer darauf laufenden Software handelt, sondern um ein Service, das ein Unternehmen zur Unterstützung seiner Geschäftsprozesse benötigt.

Mit der Cloud-Entwicklung ist dieser Trend noch verstärkt worden. Es interessiert überhaupt nicht mehr, wie eine Leistung im Hintergrund erbracht wird, sondern man versucht nur mehr das Service möglichst klar zu definieren und den entsprechenden Anbieter zu finden.

Ausblick

Das Thema Cloud ist längst kein Hype mehr, sondern ein Faktum mit dem alle Bereiche, die IT Services in Zukunft nutzen wollen leben müssen. Es gibt sehr viele Initiativen von Anbieter-und Anwender-Vereinigungen sowie Forschungsstellen , die versuchen die Anwender aufzuklären und die gleichzeitig Maßnahmen initiieren um die derzeitigen noch bestehenden Probleme in den Griff zu bekommen.

Eine dieser Initiativen ist die Entwicklung von Zertifizierungen für Cloud Services.

Zum Beispiel hat die Vereinigung Eurocloud ein spezielles Gütesiegel entworfen, dessen Nutzung voraussetzt, dass die für die Bereitstellung der Cloud-Services grundlegenden Anforderungen durch geschulte Auditoren geprüft und durch ein Zertifikat bestätigt werden.

Die VITE-Group (Vienna IT Enterprises) hat zum Beispiel einen Leitfaden für Cloud Verträge herausgebracht.

Es werden in nächster Zeit sicher auch Anstrengungen im Bereich der Legal Compliance und deren Kontrolle von verschiedenen Stellen gemacht werden.

Fazit

Das Thema Outsourcing hat sich somit von Großprojekten hin zu fast beliebige Serviceleistungen durch Dritte entwickelt. In allen Unternehmensgrößen gilt, dass die IT im Normalfall keine Kernkompetenz des Unternehmens darstellt und daher immer mehr zu möglichst preiswerten variablen Kosten eingekauft werden wird.