Von der Vorbereitungs- zur Betriebsphase. Ein Modell zur Einführung von Cloud Computing

Inhaltsverzeichnis

Abkürzungsverzeichnis

Glossar

Einleitung

1. Vorbereitungsphase
1.1. Systemanalyse
1.2. Identifizierung der Lösungsansätze
1.3. Auswahl des geeignetesten Lösungsansatzes
1.3.1. Kostenvergleichsrechnung
1.3.2. Analyse der Stärken und Schwächen, Chancen und Risiken
1.3.3. Nutzwertanalyse
1.3.4. Analyse des Nutzen-, Risiko- und Aufwandspotentials
1.4. Vorbereitung der Umsetzung

2. Umsetzungsphase

3. Betriebsphase
3.1. Kontinuierliche Verbesserung
3.2. Cloud Management
3.3. Support
3.4. Cloud Controlling

Literaturverzeichnis (inklusive weiterführender Literatur)

Anlagen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Glossar

Application Service Provider: „Dienstleistungsanbieter …, bei denen Anwendungsprogramme über das Internet durch die Anwender für eine bestimmte Zeit gemietet werden können. Die Anwendungen werden vom Server des A. S. P. [hier als Abkürzung für Application Service Provider] aus gestartet (Client-/Server-Architektur). Einnahmen generiert der A. S. P. durch zeitabhängige Gebühren, die für den Zugriff auf die Software berechnet werden.“^[1]

Benutzerservice: „Betreuung der Benutzer im Umgang mit Anwendungssystemen, insbesondere Officepaketen und dem Internet“.^[2]

Betriebssystemvirtualisierung: Hierbei werden von einem Betriebssystem mehrere unabhängige virtuelle Instanzen erstellt. Dabei verwenden alle Instanzen das gleiche Basisbetriebssystem. Dadurch wird sowohl die Art der installierbaren Anwendungssoftware, aber auch die Betriebssysteme, die installiert werden können, eingeschränkt.^[3]

Business Continuity: „Alle organisatorischen, technischen und personellen Maßnahmen, die a) zur Fortführung der Kerngeschäfte unmittelbar nach Eintritt des Krisenfalles und b) zur sukzessiven Wiederaufnahme des gesamten Geschäftsbetriebs bei länger andauernden schweren Störungen dienen.“^[4]

Datenintegrität: In „der Datenbankorganisation (Datenorganisation) die Korrektheit der gespeicherten Daten im Sinn einer widerspruchsfreien und vollständigen Abbildung der relevanten Aspekte des erfassten Realitätsausschnitts.“^[5]

Entwicklungsumgebung: Eine Anwendung zur Entwicklung von Software.

Extensible Markup Language: Extensible Markup Language (XML) ist eine Auszeichnungssprache, mit der Daten in hierarchisch strukturierten Form abgebildet werden. XML ist plattform- und programmiersprachenunabhängig und wird zum Austausch von Daten zwischen Computersystemen eingesetzt.

Funktionale Anforderungen: Begriff aus dem Software Engineering. Nach Sommerville sind dies „Aussagen, zu den Diensten, die das [zu planende] System leisten sollte, zur Reaktion des Systems auf bestimmte Eingaben und zum Verhalten des Systems in bestimmten Situationen. In manchen Fällen können die funktionalen Anforderungen auch explizit ausdrücken, was das System nicht tun soll.“^[6]

Hypervisor: Eine Virtualisierungssoftware, die in einer isolierten, virtuellen Umgebung, die man virtuelle Maschine nennt, die Hardware eines Rechners zur Verfügung stellt. Dies kann entweder durch die Emulation der Hardware oder durch die Virtualisierung der realen Hardware geschehen.

IT-Verteilung: Festlegung der informationstechnischen, räumlichen bzw. geografischen und organisatorischen Verteilung von IT-Ressourcen.^[7]

Konsolidierung von IT-Infrastrukturen: Das Ziel der Konsolidierung ist es, die Kosten der IT-Infrastrukturen zu senken. Man kann zwischen vier Teilaspekten unterscheiden:

- Harmonisierung und Standardisierung von Hard- und Software
- Virtualisierung von Hard- und Software
- Zusammenfassung von verteilten Rechenzentren
- Outsourcing von Teilen der IT-Infrastruktur

Nichtfunktionale Anforderungen: Begriff aus dem Software Engineering. Nach Sommerville sind dies „Beschränkungen der durch das [zu planende] System angebotenen Dienste oder Funktionen. Das schließt Zeitbeschränkungen, Beschränkungen des Entwicklungsprozesses und einzuhaltende Standards ein. Nichtfunktionale Anforderungen beziehen sich oft auf das ganze System und gewöhnlich nicht auf einzelne Systemfunktionen oder Dienste.“^[8]

Skalierbarkeit: Dynamische Anpassung der zu beziehenden IT-Ressourcen an variierende Anforderungen.^[9]

SOAP: Ein plattform- und programmiersprachenunabhängig Protokoll, das zum Austausch von XML-Nachrichten zwischen Computersystemen eingesetzt wird.

Thin Client: Ein, im Verhältnis zu einem PC-Rechner, kleines Endgerät bei dem die Datenverarbeitung und Rechenleistung über einen Server erbracht wird, mit dem der Thin Client über eine Remote-Desktop-Verbindung verbunden ist.^[10]

Unified Modeling Language: Eine Beschreibungssprache zur grafischen Darstellung von Softwareprogrammen und Informationssystemen. Diese können mit UML modelliert, spezifiziert und dokumentiert werden.

Virtuelles privates Netz: Über ein virtuelles privates Netz (engl. virtual private network; Abk.: VPN) können einzelne Rechner oder Netzwerke mit einem LAN verbunden werden. Dazu wird eine verschlüsselte Verbindung (Tunnel) über das Internet hergestellt. Zwischen zwei LANs werden VPN-Verbindungen meistens über Firewalls hergestellt.

Einleitung

Kein anderes Thema der Informationstechnik weckt derzeit so große Erwartungen wie Cloud Computing. Dem aktuellen „Hype Cycle for Emerging Technologies“ des Marktforschungsunternehmens Gartner zufolge, befindet sich Cloud Computing derzeit auf dem Höhepunkt überzogener Erwartungen.^[11] In den Augen von Gartner bedeutet dies, dass Cloud Computing von den Massenmedien stark thematisiert wird, dass nach den Pionieren viele neue Anbieter auf den Markt drängen und dass es bereits erste negative Berichte über das Thema gibt.^[12] Bisheriger Höhepunkt dieser Entwicklung war die CeBit, die mit dem Schwerpunktthema „Work and Life with the Cloud“ ganz im Zeichen des Cloud Computing stand.^[13]

In der folgenden Arbeit wird ein Modell zur Einführung von Cloud Computing in Unternehmen oder sonstigen Organisationen vorgestellt. Dabei wird auf den Arbeiten von Hodel et al.^[14] zum IT-Outsourcing und von Henneberger et al.^[15] zur Analyse des Nutzen-, Risiko- und Aufwandspotentials aufgebaut.

Der Einführungsprozess wird dabei in drei Phasen zur Vorbereitung, Umsetzung und zum Betrieb von Cloud Computing-Systemen aufgeteilt. Diese Phasen werden in Abbildung 1 und in den nächsten Kapiteln Schritt für Schritt dargestellt. Die Beschreibung des Einführungsprozesses wird durch Ablaufpläne und Checklisten (siehe Anlage 3) ergänzt.

Vor der Einleitung eines Einführungsprozesses, sollte die Unternehmensleitung (der Begriff wird im Folgenden auch für die Leitungsgremien anderer Organisationen verwendet) die Unternehmenspolitik zum Thema Outsourcing festlegen.^[16] Neben der Frage der grundsätzlichen Bereitschaft Teile der IT auszulagern, sollte die Unternehmensleitung auch festlegen, welche Prozesse und Daten zu den Kernkompetenzen des Unternehmens zählen und daher unter keinen Umständen zu anderen Unternehmen ausgelagert werden dürfen. Dies ist insbesonders daher wichtig, weil durch die Festlegung einer einheitlichen Unternehmenspolitik bestimmte Cloud Sourcing-Optionen in der Vorbereitungsphase direkt ausgeschlossen werden können, so dass sie nicht weiter berücksichtigt werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Überblick über die drei Phasen der Einführung von Cloud Computing^[17]

1. Vorbereitungsphase

Am Anfang des Cloud-Einführungsprozesses steht immer eine Entscheidung der Unternehmens-, IT- oder Geschäftsbereichsleitung (im Folgenden der Auftraggeber) die Einführung einer bestimmten Cloud-Lösung zu prüfen. Dazu beauftragt der Auftraggeber einen fachlich qualifizierten Mitarbeiter oder einen externen Unternehmensberater. Ziel dieses Prüfauftrages ist es mögliche Lösungsansätze zu identifizieren, die am besten für die Umsetzung geeignete Lösung auszuwählen und diese dem Auftraggeber in Form eines Business Case zur Entscheidung über die Umsetzung vorzulegen. Im Anschluss daran werden die Vorbereitungen für die Umsetzung der ausgewählten Lösung getroffen, indem die Ressourcen für das Projekt bereitgestellt werden.

In der Vorbereitungsphase werden dazu die folgenden Schritte abgearbeitet:

1 Durchführung einer Systemanalyse
2 Identifizierung der möglichen Lösungsansätze
3 Analyse der möglichen Lösungsansätze
4 Entscheidung über die Umsetzung des Lösungsansatzes durch den Auftraggeber und Vorbereitung der Umsetzung

Einen Überblick über den Ablauf der Vorbereitungsphase bietet die Abbildung in Anlage 1.

1.1. Systemanalyse

Die Systemanalyse besteht aus den folgenden Teilbereichen:

- Analyse der Unternehmenspolitik und der rechtlichen Rahmenbedingungen: Zu diesem Zweck wird die Outsourcing-Unternehmenspolitik und die rechtlichen Rahmenbedingungen, die das Outsourcing der zu planenden IT-Lösung betreffen, analysiert. Hierzu müssen durch die Analyse die folgenden Fragen beantwortet werden:
- Ist es unter Berücksichtigung der Unternehmenspolitik und der rechtlichen Rahmenbedingungen möglich, die gesamte oder Teile der zu planenden Lösung durch einen externen Outsourcingnehmer als Dienstleistung erbringen zu lassen? Falls die Lösung mehrere Länder und Tochtergesellschaften betreffen soll, muss diese Frage für jedes Land einzeln beantwortet werden.
- Wie hoch ist das finanzielle Budget, das für das Projekt zur Verfügung steht?
- Gibt es von Seiten der Unternehmensleitung oder des Auftraggebers eine Vorgabe, die die Höhe der anfänglichen Investitionen der Lösung begrenzt (z.B. aus Gründen der Liquidität)?
- Gibt es von Seiten der Unternehmensleitung oder des Auftraggebers weitere Vorgaben, die die Umsetzung des Projektes oder die Vorgehensweise bei der Umsetzung des Projektes betreffen?
- Identifizierung von Kernkompetenzen: Dieser Schritt der Systemanalyse baut auf den bei der Analyse der Unternehmenspolitik und der rechtlichen Rahmenbedingungen gewonnenen Erkenntnissen auf. Dabei wird überprüft, ob die zu planende Lösung Prozesse und Daten betrifft, die zu den Kernkompetenzen des Unternehmens gehören und aus diesem Grund nicht ausgelagert werden sollten. Nach Hodel et al. sind Kernkompetenzen fester Bestandteil der Strategie oder des Leitbildes eines Unternehmens. Sie basieren auf den Überzeugungen der Mitarbeiter und bieten dem Unternehmen einzigartige Wettbewerbsvorteile gegenüber seinen Konkurrenten, die diese Vorteile nicht ohne weiteres kopieren oder nachahmen können.^[18] Die sich daraus ergebenden Anforderungen werden gesammelt.
- Strategieanalyse: Hierbei steht die Frage im Mittelpunkt, ob mit der Einführung der geplanten Lösung bestimmte strategische Ziele verbunden sind. Mögliche Ziele wären z.B. Kostenreduktion, Qualitätsverbesserung, Steigerung der Produktivität oder des Umsatzes, höhere Flexibilität oder Verbesserung der Kundenbindung.
- Bestimmung von Ausgangslage und Anforderungen: Aufbauend auf den Erkenntnissen der Strategieanalyse wird in diesem Bereich dokumentiert, welche für die zu planende Lösung möglicherweise benötigten Elemente der IT-Infrastruktur bereits vorhanden sind. Hierzu zählen z.B. Server, Software, Internetanbindung, Personal, Wissen. Der IT-Infrastruktur-Mix kann genutzt werden, um diese Dokumentation zu erstellen.

Für die Einführung einer neuen Lösung stehen grundsätzlich zwei Szenarien zur Auswahl:

- Die Lösung soll ein bestehendes Informationssystem ablösen.
- Die Lösung ist ein neues Informationssystem, das eine Aufgabe erfüllt, für die es bisher noch kein Informationssystem gab (z.B. die Einführung eines Dokumentenmanagementsystems oder von Datenbankservern für einen neuen Unternehmensstandort).

Außerdem sollten die funktionalen und nichtfunktionalen Anforderungen erhoben werden, die die zu planende Lösung erfüllen soll. Die funktionalen Anforderungen sollen dabei die Anforderungen, die an die Lösung gestellt werden, beschreiben. Darüber hinaus werden die nichtfunktionalen Anforderungen gesammelt, die ähnlich wie Sommerville einerseits in Produktanforderungen unterschieden werden, die an die fertige Lösung gestellt werden, beispielsweise wie viel Speicher die Lösung benötigen darf oder wie hoch der Verfügbarkeitsgrad der Lösung sein muss. Andererseits unterscheidet man nach externen Anforderungen, die festlegen, wie die Lösung mit anderen Systemen zusammenarbeiten muss (Kompatibilitätsanforderungen) und welche Bedingungen erfüllt sein müssen um sie für Anwender und die Öffentlichkeit akzeptabel zu machen (ethische Anforderungen).^[19]

Bereits in dieser Phase können die potentiellen Anwender einer veränderten Lösung beteiligt werden, indem man sie zu Problemen mit der derzeitigen Lösung und zu Verbesserungswünschen befragt.

- Anforderungen festlegen (Pflichtenheft): Im letzten Schritt der Systemanalyse werden die in den vorhergehenden Analysen gewonnenen Anforderungen, Ziele und Vorgaben in einem Pflichtenheft gesammelt und dokumentiert. Für den inhaltlichen Aufbau eines Pflichtenheftes gibt es verschiedene Möglichkeiten: Für Softwareprojekte gibt es beispielsweise den Standard IEEE/ANSI 830-1998^[20], aber auch Abts und Mülder beschreiben den möglichen Aufbau eines Pflichtenheftes^[21]. Bei der Erstellung des Pflichtenheftes kann allerdings auch ein individueller Ansatz gewählt werden. Zu beachten ist, dass darin alle in den vorhergehenden Analysen gewonnenen Erkenntnisse dokumentiert werden.

Zur Unterstützung für die einzelnen Schritte der Systemanalyse, findet man Checklisten in Anlage 3.

1.2. Identifizierung der Lösungsansätze

Ausgehend von den Anforderungen des Pflichtenheftes wird in diesem Abschnitt der Vorbereitungsphase nach Sourcing-Optionen gesucht. Grundsätzlich stehen die folgenden Sourcing-Optionen zur Auswahl:

- Traditionelle IT-Infrastruktur
- Private Cloud (in den Betriebsformen Eigenbetrieb – als Private Cloud im engeren Sinne -, Managed Private Cloud und Outsourced Private Cloud)
- Public Cloud (möglicherweise auch Community Cloud)

Dabei ist allerdings anzumerken, dass der Betrieb der Lösung als traditionelle IT-Infrastruktur eigentlich nur den Vorteil bietet, dass die Kosten für die Weiterbildung des vorhandenen Rechenzentrums-Personals niedriger ausfallen. Ansonsten fallen bei dieser Option in der Regel höhere Kosten an. Sie sollte daher nur dann in Betracht gezogen werden, wenn der Betrieb als virtualisierte Cloud-Lösung aus technischen Gründen nicht möglich ist (beispielsweise weil Anwendung und Hypervisor nicht kompatibel sind).

Der Betrieb als eine Managed oder Outsourced Private Cloud-Lösung ist für eine einzelne Lösung alleine nicht sinnvoll, da es sich um Betriebsmodelle für eine größere Private Cloud handelt. Diese Lösungen eignen sich dagegen für eine Cloud, in der verschiedene Lösungen nebeneinander ausgeführt werden. Da das Betriebsmodell für eine Private Cloud unabhängig vom Betreiber ist und auch nachträglich noch mit relativ geringem Aufwand verändert werden kann, kann hier als Lösungsansatz auch von einer Private Cloud im weiteren Sinne ausgegangen werden.

Darüber hinaus wäre es auch möglich, die Lösung als Public oder Community Cloud zu realisieren, es sei denn die Unternehmenspolitik schließt die Auslagerung von IT-Dienstleistungen generell aus.

Eine weitere Lösungsmöglichkeit besteht in der Form einer Hybrid Cloud. Diese ermöglicht es einem Informationssystem, das zu verschiedenen Zeiten (z.B. zu bestimmten Tageszeiten oder an bestimmten Tagen) überdurchschnittlich stark ausgelastet ist, sich bei Bedarf mit den zusätzliche Rechen- und/oder Speicherkapazitäten einer Public oder Community Cloud zu erweitern. Voraussetzung hierfür sollte allerdings sein, dass die Daten, die unternehmensextern verarbeitet werden sollen, nicht zu den Kernkompetenzen des Unternehmens gehören.

Ein einfaches Mittel um die Fragestellung Eigenbetrieb (Engl.: make) oder Fremdbezug (Engl.: buy) von IT-Lösungen zu analysieren, ist die Make or Buy-Matrix. Dabei wird auf der horizontalen Achse die Differenzierung der Lösung gegenüber Lösungen eingetragen, die von der Konkurrenz genutzt werden. Dies ist z.B. dann der Fall, wenn sich das Unternehmen durch den Einsatz einer bestimmten Lösung ganz bewusst von seinen Konkurrenten absetzen will. Nach Osterloh und Frost geht es dabei „um den Grad der Substituierbarkeit und Imitierbarkeit“ der Lösung. Auf der vertikalen Achse werden die Stärken und Schwächen des eigenen Unternehmens eingetragen.^[22] Dazu wird ein gemeinsamer Wert aus den Aspekten Qualität, Kosten und Häufigkeit des Lösungseinsatzes für den Eigenbetrieb der Lösung ermittelt. Das Ergebnis dieser Analyse kann in der Positionierung abgelesen werden, wobei die folgenden Ergebnisse möglich sind: Make (Private Cloud), Buy (Public Cloud) und Make or Buy. Wobei bei letztgenannter Möglichkeit der Betrieb als Managed oder Outsourced Private Cloud sinnvoll sein kann. Allerdings sollte man in diesem Fall auch die Möglichkeit des Betriebs als Private Cloud (im engeren Sinne) oder als Public Cloud genauer überprüfen. Abbildung 2 zeigt den Aufbau einer Make or Buy-Matrix. Das Problem der Make or Buy-Matrix ist, dass ihr eine subjektive Datenerhebung in Form von Annahmen zugrunde liegt und das Ergebnis durch persönliche Präferenzen, der an der Datenerhebung beteiligten Personen, verfälscht werden kann. Trotzdem eignet sich die Make or Buy-Matrix als erster Schritt im Auswahlverfahren durch den bestimmte Lösungen direkt ausgeschlossen werden können, wodurch die Anzahl der in Frage kommenden Lösungsmöglichkeiten reduziert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Make or Buy-Matrix als Entscheidungsgrundlage für Cloud Sourcing-Optionen^[23]

Nachdem die in Frage kommenden Sourcing-Optionen identifiziert wurden, werden anschließend im Rahmen einer Markterhebung verschiedene Lösungsansätze ausgearbeitet. Dabei können neben den möglichen Sourcing-Optionen auch Lösungsansätze mit unterschiedlicher Hard- und Software, sowie Angebote von verschiedenen Outsourcingnehmern entworfen werden.

Bei der Nutzung von externen Anbietern ist zu beachten, dass die Verantwortlichen für Datensicherheit und für die Qualität von Informationssystemen an der Ausarbeitung der Lösungen beteiligt werden sollten. Falls in einem Lösungsansatz die Leistungen eines externen Partners (z.B. der Anbieter einer Public Cloud-Lösung) genutzt werden sollen, sollte die Rechtsabteilung oder besser ein spezialisierter Rechtsanwalt beteiligt werden um die Verträge zu überprüfen.

1.3. Auswahl des geeignetesten Lösungsansatzes

Im nächsten Schritt werden die verschiedenen Lösungsansätze mit betriebswirtschaftlichen Mitteln miteinander verglichen und der zur Lösung bestgeeignetste Ansatz ausgewählt.

Bei der Auswahl sollte darauf geachtet werden, dass neben einer reinen Kostenbetrachtung (hier in Form einer Kostenvergleichsrechnung) auch andere Auswahlkriterien beachtet werden um die Lösung auszuwählen, die für das Unternehmen wirklich am besten geeignet ist. Auch sollte darauf geachtet werden, dass sowohl der Kostenaspekt als auch die sonstigen Kriterien bei der Entscheidung angemessen berücksichtigt werden. Welches Verhältnis für diese Angemessenheit angebracht ist, kann dabei individuell auf die jeweilige Situation bezogen festgelegt werden.

1.3.1. Kostenvergleichsrechnung

Da Erlöse bei Einführung von Informationssystemen selten eine Rolle spielen und auch nur schwer zu schätzen sind (z.B. die zu erwartenden Umsatzsteigerungen als Folge der Einführung eines CRM-Systems), ist in den meisten Fällen eine Kostenvergleichsrechnung^[24] ausreichend. Falls es sich bei dem geplanten Lösungsansatz um eine Lösung handelt, durch deren Einführung mit gut zu schätzenden oder bereits bekannten Erlösen zu rechnen ist, sollte stattdessen eine Gewinnvergleichsrechnung^[25] durchgeführt werden.

Götze weist allerdings darauf hin, dass die Verwendbarkeit des durch Kostenvergleichsrechnungen erzielten Ergebnisses stark von der Qualität der zugrundegelegten Daten abhängt.^[26] Daher sollten diese Daten sorgfältig zusammengetragen werden.

Empirische Studien weisen darauf hin, dass die Schulungskosten, die beim Fremdbezug von IT-Dienstleistungen anfallen, häufig unterschätzt werden, aber auch dass versteckte Kosten für Optimierungs- und Restrukturierungsmaßnahmen häufig überhaupt nicht einkalkuliert werden.^[27] Daher ist es notwendig, die Folgekosten des Umstiegs zum Cloud Computing genau zu kalkulieren.

Für die Durchführung der Kostenvergleichsrechnung sollte man bei einer Private Cloud-Lösung neben den Kosten für kalkulatorische Abschreibungen und kalkulatorische Zinsen auch die Personalkosten berücksichtigen, die für die Inbetriebnahme und Außerbetriebnahme und den Betrieb der Lösung (Wartung, Schulung, Support) anfallen. Darüber hinaus sollten die Kosten für Strom, Speicherplatz (SAN) und Antiviruslösung anteilig berücksichtigt werden. Bei Public Cloud-Lösungen sollte man neben den monatlich anfallenden Kosten für den Dienst selbst, auch die Kosten für die Inbetriebnahme (Vertragsprüfung, Konfiguration oder Einrichtung der Lösung, Integration des Supports des externen Anbieters), Außerbetriebnahme, regelmäßige Kosten für die Veränderung der Konfiguration (anstelle der Wartung) und die monatliche Verbuchung der Kosten berücksichtigen. In beiden Fällen sollte darauf geachtet werden, dass nicht nur die Kosten für das technische, sondern auch die für das kaufmännische Personal berücksichtigt werden. Entsprechende Checklisten findet man in Anlage 3. Alternativ kann man auch auf das TCO Framework von Klems et al. zurückgreifen. Bei diesem werden die Kosten von Cloud Computing-Lösungen mit den Kosten von Lösungen auf der Basis von IT-Infrastrukturen verglichen.^[28]

1.3.2. Analyse der Stärken und Schwächen, Chancen und Risiken

Auch diese Analyse dient dem Ausschluss bestimmter Sourcing-Optionen und sollte am Anfang des Auswahlprozesses eingesetzt werden. Für jede in Frage kommende Sourcing-Option werden zu diesem Zweck zuerst die unternehmensinternen Stärken und Schwächen in Bezug auf die Sourcing-Option gegenübergestellt. In einem zweiten Schritt stellt man anschließend die unternehmensexternen Chancen und Risiken nebeneinander, die sich aus dem Einsatz von Cloud Computing ergeben.

Ausgehend von diesen Gegenüberstellungen kann man anschließend entscheiden, ob die analysierte Cloud Sourcing-Option weiter als Lösung in Frage kommt.

1.3.3. Nutzwertanalyse

Die Nutzwertanalyse (auch Scoring-Modell) dient nach Götze dem Vergleich mehrerer Handlungsalternativen unter Berücksichtigung von Zielgrößen, die durch den Entscheidungsträger gewichtet wurden. Der Zielerreichungsgrad jedes Ziels ist für jede Alternative zu bestimmen und als Teilnutzwert anzugeben. Anschließend werden die Teilnutzwerte gemäß ihrer Gewichtung zu einem Gesamtwert zusammengefasst, der als Nutzwert bezeichnet wird.^[29] Einen Überblick über die Vorgehensweise der Nutzwertanalyse geben Götze^[30] und Schierenbeck^[31].

Die Nutzwertanalyse ist für die Auswahl einer Lösung besonders gut geeignet, weil bei der Auswahl der geeignetesten Lösung nicht nur ein Kosten- oder gegebenenfalls ein Gewinnvergleich eine Rolle spielen sollte, da auch andere Faktoren bei der Entscheidungsfindung berücksichtigt werden sollten. Es ist allerdings möglich, dass die Ergebnisse der Analyse durch persönliche Präferenzen der Entscheidungsträger verfälscht werden.

Für die Auswahl der Ziele können die Anforderungen aus dem oder der Aufstellung von Chancen, Risiken und Herausforderungen bereinigt und verdichtet werden. Die daraus entstandene Liste kann nach den folgenden vier Aspekten geordnet werden. Mindestens die unten aufgeführten Kriterien sollten analysiert werden:

- Aspekte der Datensicherheit und Verfügbarkeit: Verlässlichkeit der Lösung, Sicherheit der Lösung, Performance der Lösung
- Rechtliche Aspekte: Rückabwicklung nach Vertragsende, Möglichkeiten der Beweismittelsicherung
- Wirtschaftliche Aspekte: Flexibilität und Skalierbarkeit der Lösung,
- Organisatorische Aspekte: Professionalität der Leistungserstellung, Funktionsumfang der Lösung in Bezug auf die Anforderungen des Unternehmens, Vorbehalte der Mitarbeiter gegen die Einführung der Lösung

Um den Einfluss von persönlichen Präferenzen auf das Ergebnis der Analyse gering zu halten, kann, ausgehend von einer empirischen Untersuchung von Benlian et al.^[32], für den Einsatz von SaaS-Lösungen, auf einer Skala von 1 (niedrig) bis 7 (hoch), von folgenden Werten für die Teilnutzenbestimmung ausgegangen werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Werte für die Teilnutzenbestimmung von SaaS-Lösungen32

Die Kosten, die beim Einsatz einer Lösung entstehen würden, sollten nach Götze nicht als Kriterium in der Nutzwertanalyse verwendet werden, da sie meistens bereits in anderen Kriterien der Analyse enthalten sind (z.B. entstehen bei SaaS-Lösungen mit höherem Funktionsaufwand höhere Kosten). Trotzdem sollten die Kosten bei der Entscheidungsfindung berücksichtigt werden (beispielsweise durch eine Kostenvergleichsrechnung).^[33]

1.3.4. Analyse des Nutzen-, Risiko- und Aufwandspotentials

Dieses Verfahren wurde von Henneberger et al. vorgeschlagen und dient eigentlich zur Identifizierung von potentiellen Cloud Computing-Projekten. Da auch in diesem Verfahren die in Frage kommenden Lösungen miteinander verglichen werden, sollte es grundsätzlich auch für den Vergleich von zwei ähnlichen Lösungsansätzen geeignet sein. Dazu werden Kriterien (die entweder Henneberger et al. oder einer vorangegangenen Analyse der Chancen und Risiken entnommen werden können) den Dimensionen Nutzen, Risiko und Aufwand zugeordnet und anhand einer Skala von null bis eins bewertet. Aus den Werten der Kriterien einer Dimension wird anschließend ein Durchschnittswert für die Dimension ermittelt. Zur Auswertung können die Ergebnisse in einer Nutzen-Risiko-Matrix dargestellt werden, in der der Aufwand als Kreisgröße abgebildet wird:^[34]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Nutzen-Risiko-Matrix als Entscheidungsgrundlage für Cloud-Lösungsansätze^[35]

Um das Ergebnis der Analyse aussagekräftiger zu machen, ist es sinnvoll anstelle eines bewerteten Aufwandes die prognostizierten Kosten aus der Kostenvergleichsrechnung zu verwenden.

Außerdem hat die Anwendung der Analyse in Rahmen der Fallstudie (siehe Anlage 2) einen Hinweis darauf geliefert, dass das Verfahren in seiner ursprünglichen Form nicht zum Vergleich von verschiedenen Lösungsansätzen geeignet ist. Um das Verfahren zu verbessern, wird vorgeschlagen, die Zielkriterien zu gewichten und anschließend die Ausprägungen bei der Auswertung der Dimensionen mit dem Gewichtungsfaktor zu multiplizieren (siehe Anlage 2).

Darüber hinaus kann die Darstellung an die jeweilige Situation im Unternehmen angepasst werden, indem man die Größe der Quadranten der Matrix entsprechend des im Unternehmen vorherrschenden Risiko- und Nutzenempfindens verändert, da dieses in der ursprünglichen Form der Analyse willkürlich mit 0,5 angegeben wird. Dazu wird zuerst das Risiko- und Nutzenempfinden ermittelt, indem man die Gewichtungsfaktoren der beiden Dimensionen ermittelt, sie jeweils summiert und diese Summe dann durch die Gesamtsumme beider Summen dividiert. Indem man die Größe des Quadranten für eine Risikolösung für beide Achsen an das Risikoempfinden anpasst, werden auch die Größen der anderen Quadranten modifiziert. Durch diese Veränderung wird das Ergebnis der Analyse an das Risiko- und Nutzenempfinden des Unternehmens angepasst. In Abbildung 3 werden diese Veränderungen beispielhaft für ein Risikoempfinden von 0,6 und ein Nutzenempfinden von 0,4 dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Veränderte Nutzen-Risiko-Matrix für ein Risikoempfinden von 0,6 und ein Nutzenempfinden von 0,4^[36]

1.4. Vorbereitung der Umsetzung

Für die ausgewählte Lösung sollte danach ein Business Case ausgearbeitet werden, um der Unternehmensleitung oder dem Auftraggeber eine Grundlage für die endgültige Entscheidung zu geben. Nach Hodel et al. sind dazu die getroffenen Annahmen zu dokumentieren, um anschließend auf dieser Grundlage Aussagen über die Vorteilhaftigkeit der Lösung darzulegen. Einheitliche Standards über den Aufbau eines Business Case gibt es nicht, was für den Autor einige Freiheiten bedeutet. Darüber hinaus wird empfohlen, das Projekt aus verschiedenen Blickwinkeln zu analysieren, um auf diese Weise ein möglichst vollständiges Bild der Lösung zu zeichnen.^[37]

Laut Hodel et al. sollte ein Business Case in erster Linie die folgende Fragestellung beantworten: „Was sind die betriebswirtschaftlichen Auswirkungen, wenn wir das Projekt durchführen? Was passiert, wenn wir es nicht durchführen?“^[38]

Für die Unternehmensleitung oder den Auftraggeber bildet der Business Plan die Grundlage für die Entscheidung, ob das Projekt zur Einführung der Lösung in der beschriebenen Form durchgeführt, mit Auflagen durchgeführt oder nicht durchgeführt wird.

Nachdem die Entscheidung für die Durchführung des Projektes getroffen wurde, müssen die Entscheidungsträger im letzten Schritt der Vorbereitungsphase die für die Durchführung des Projektes notwendigen Ressourcen bereitstellen. Dazu gehören:

- Das Personal, das für die Durchführung des Projektes erforderlich ist, insbesondere:
- Ein Projektleiter, der idealerweise bereits Erfahrung mit der Durchführung ähnlicher Projekte hat. Sollte im Unternehmen kein geeigneter Mitarbeiter verfügbar sein, dann sollte eine geeignete Person von außerhalb des Unternehmens für diese Aufgabe verpflichtet werden.
- Hodel et al. empfehlen einen erfahrenen externen Change Management-Coach im Projektteam vorzusehen, der neutral zwischen Mitarbeitern und Projektleitung vermitteln kann. Dadurch kann die Gefahr von Widerständen unter den Mitarbeitern, die durch mangelnde oder ungenügende Kommunikation entstehen, reduziert werden.^[39] Eine weitere Aufgabe soll darin bestehen die Anwender in die Lage zu versetzen, auftretende Probleme mit der neuen Lösung selbst zu lösen.^[40] Dies ist zumindest dann sinnvoll, wenn der Einsatz von Public Cloud Computing geplant ist.
- Das technische Personal (Entwickler, Netzwerkadministratoren usw.), das für die Durchführung des Projektes benötigt wird.
- Je nach Größe des Projektes ein oder mehrere Mitarbeiter, die für die Qualitätssicherung und Dokumentation der Lösung zuständig sind. Dazu können Mitarbeiter des Benutzerservice eingesetzt werden.
- Key User, die aus dem Kreis der späteren Anwender der Lösung stammen, sollten das Projektteam während der Projektumsetzung bei anwendungsspezifischen Fragestellungen beraten und beim Test der Lösung mitwirken.^[41] Auf diese Art und Weise können Berührungsängste mit der neuen Lösung verringert und die Akzeptanz unter den zukünftigen Anwendern erhöht werden.
- Dem Projekt sollte auch ein Projekteigner zugewiesen werden (meistens ein Mitglied der Unternehmensleitung), der an den wichtigsten Entscheidungen des Projektes beteiligt ist und bei bedeutenden Abweichungen des Projektverlaufs umgehend zu unterrichten ist, damit er entscheiden kann, wie mit dieser Abweichung umzugehen ist.^[42] Gegebenenfalls kann zusätzlich auch ein Projektsponsor aus der Unternehmensleitung für die finanziellen Aspekte der Projektdurchführung zuständig sein.
- Die für die Durchführung des Projektes erforderlichen finanziellen Mittel.

Natürlich kann in kleineren Unternehmen die Anzahl der am Projekt beteiligten Personen geringer ausfallen und eine Person des Projektteams mehrere Aufgaben gleichzeitig wahrnehmen.

Darüber hinaus sollte ein zeitlicher Rahmen für die Durchführung des Projektes gesetzt werden.

2. Umsetzungsphase

Im folgenden Kapitel wird die Umsetzungsphase kurz beschrieben. Diese reicht vom Entwurf (Modellierung) der Lösung und ihrem Test bis hin zu ihrer Inbetriebnahme. Abbildung 5 zeigt den Ablauf der Umsetzungsphase, die im Folgenden Schritt für Schritt beschrieben wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Der Ablauf der Umsetzungsphase^[43]

- Entwurf: In dieser Phase der Umsetzungsphase wird das einzuführende Informationssystem (in der Regel von den Entwicklern) entworfen und detailliert geplant. Als Grundlage für diese Planungen dienen die Ausarbeitungen des Pflichtenheftes und des Business Case. Dazu werden gängige Methoden des System- und/oder Programmentwurfs, wie beispielsweise Programmablaufpläne, Struktogramme, Datenflussdiagramme oder die Unified Modeling Language (UML), eingesetzt.

[...]

---

^[1] Alisch, Katrin/Arentzen, Ute/Winter, Eggert (Hrsg.), Gabler Wirtschaftslexikon, Gabler Verlag, Wiesbaden, 16. Aufl. 2004, Band A-Be, S. 143.

^[2] Vgl. Stahlknecht, Peter/Hasenkamp, Ullrich, Einführung in die Wirtschaftsinformatik, Springer, Berlin und Heidelberg, 11. Aufl. 2005, S. 449.

^[3] Siehe Krcmar, Helmut, Informationsmanagement, Springer-Verlag, Berlin und Heidelberg, 5. Aufl. 2010, S. 318 und Shields, Greg, Der schnelle Weg zur Wahl der richtigen Virtualisierungslösung, http://www.parallels.com/r/pdfs/vz/ebook/SGSRVS-DE.pdf (2010-08-03, 17:20 MEZ), S. 5-6.

^[4] Gabler Verlag (Hrsg.), Gabler Wirtschaftslexikon, Stichwort: Business Continuity, Version 5, http://wirtschaftslexikon.gabler.de/Definition/business-continuity.html (2011-02-22, 11:53 MEZ).

^[5] Alisch, Katrin/Arentzen, Ute/Winter, Eggert (Hrsg.), Gabler Wirtschaftslexikon, Gabler Verlag, Wiesbaden, 16. Aufl. 2004, Band Bf-E, S. 653.

^[6] Sommerville, Ian, Software Engineering, Pearson Studium, München, 8. Aufl. 2007, S. 152.

^[7] Vgl. Stahlknecht, Peter/Hasenkamp, Ullrich, Einführung in die Wirtschaftsinformatik, Springer, Berlin und Heidelberg, 11. Aufl. 2005, S. 440.

^[8] Sommerville, Ian, Software Engineering, Pearson Studium, München, 8. Aufl. 2007, S. 152.

^[9] Vgl. Stanovska-Slabeva, Katarina/Wozniak, Thomas, Cloud Basics – An Introduction to Cloud Computing, in: Stanovska-Slabeva, Katarina/Wozniak, Thomas/Ristol, Santi (Hrsg.), Grid and Cloud Computing: A Business Perspective on Technology and Applications, Springer-Verlag, Berlin und Heidelberg, 1. Auflage 2010, S. 50.

^[10] Vgl. Knermann, Christian/Hiebel, Markus/Pflaum, Hartmut/Rettweiler, Manuela/Schröder, Andreas, Studie: Ökologischer Vergleich der Klimarelevanz von PC und Thin Client Arbeitsplatzgeräten 2008, April 2008, http://it.umsicht.fraunhofer.de/TCecology/docs/TCecology2008_de.pdf (2010-07-23 17:35 MEZ), S. 10-11.

^[11] Vgl. Fenn, Jackie, Hype Cycle - for Emerging Technologies, 2010, August 2010, http://www.gartnerinsight.com/download/HypeCycle_EmergingTechnologies2010.pdf (2011-01-31, 10:04 MEZ), S. 3-4.

^[12] Vgl. Fenn, Jackie/Gammage, Brian/Raskino, Mark, Gartner's Hype Cycle Special Report for 2010, August 2010, http://www.gartner.com/resources/205800/205839/gartners_hype_cycle_special__205839.pdf (2010-11-04, 11:05 MEZ), S. 4.

^[13] Siehe Deutsche Messe AG (Hrsg.), Top-Thema der CeBIT 2011: "Work and Life with the Cloud", ohne Datum, http://www.cebit.de/de/ueber-die-messe/daten-und-fakten/die-cebit-2011/cloud-computing-top-thema (2011-03-05, 15:19 MEZ).

^[14] Siehe Hodel, Marcus/Berger, Alexander/Risi, Peter, Outsourcing realisieren: Vorgehen für IT und Geschäftsprozesse zur nachhaltigen Steigerung des Unternehmenserfolgs, Vieweg Verlag, Wiesbaden, 2. Aufl. 2006.

^[15] Siehe Henneberger, Matthias/Strebel, Jörg/Garzotto, Fabio, Ein Entscheidungsmodell für den Einsatz von Cloud Computing im Unternehmen, in: HMD - Praxis der Wirtschaftsinformatik, Oktober 2010, Heft 275, S. 76-84.

^[16] Für detaillierte Vorschläge zu den einzelnen Punkte einer vollständigen Outsourcing-Unternehmenspolitik siehe Hodel, Marcus/Berger, Alexander/Risi, Peter, Outsourcing realisieren: Vorgehen für IT und Geschäftsprozesse zur nachhaltigen Steigerung des Unternehmenserfolgs, Vieweg Verlag, Wiesbaden, 2. Aufl. 2006, S. 53-56.

^[17] Eigene Darstellung.

^[18] Vgl. Hodel, Marcus/Berger, Alexander/Risi, Peter, Outsourcing realisieren: Vorgehen für IT und Geschäftsprozesse zur nachhaltigen Steigerung des Unternehmenserfolgs, Vieweg Verlag, Wiesbaden, 2. Aufl. 2006, S. 63.

^[19] Siehe Sommerville, Ian, Software Engineering, Pearson Studium, München, 8. Aufl. 2007, S. 154-155. Da die von Sommerville angeführten Unternehmens- und rechtlichen Anforderungen bereits im Rahmen der „Analyse der Unternehmenspolitik und der rechtlichen Rahmenbedingungen“ bearbeitet wurden, werden sie im Zuge dieser Analyse nicht erneut behandelt.

^[20] Zum Aufbau und Anwendung des Standards siehe Sommerville, Ian, Software Engineering, Pearson Studium, München, 8. Aufl. 2007, S. 168-171.

^[21] Siehe Abts, Dietmar/Mülder, Wilhelm, Grundkurs Wirtschaftsinformatik: Eine kompakte und praxisorientierte Einführung, Vieweg+Teubner, Wiesbaden, 6. Aufl. 2009, S. 369-371.

^[22] Vgl. Osterloh, Margit/Frost, Jetta, Prozessmanagement als Kernkompetenz: Wie Sie Business Reengineering strategisch nutzen können, Gabler Verlag, Wiesbaden, 5. Aufl. 2006, S. 225-226.

^[23] Eigene Darstellung, in Anlehnung an Osterloh, Margit/Frost, Jetta, Prozessmanagement als Kernkompetenz: Wie Sie Business Reengineering strategisch nutzen können, Gabler Verlag, Wiesbaden, 5. Aufl. 2006, S. 226.

^[24] Zur Durchführung einer Kostenvergleichsrechnung siehe beispielsweise Götze, Uwe, Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, Springer-Verlag, Berlin und Heidelberg, 6. Aufl. 2008, S. 50-58.

^[25] Zur Durchführung einer Gewinnvergleichsrechnung siehe beispielsweise Götze, Uwe, Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, Springer-Verlag, Berlin und Heidelberg, 6. Aufl. 2008, S. 58-60.

^[26] Vgl. Götze, Uwe, Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, Springer-Verlag, Berlin und Heidelberg, 6. Aufl. 2008, S. 56.

^[27] Vgl. Reiss, Michael/Günther, Armin, Complementor Relationship Management im IT-Sourcing, in: Keuper, Frank/Wagner, Bernd/Wysuwa, Hans-Dieter (Hrsg.), Managed Services: IT-Sourcing der nächsten Generation, Gabler, Wiesbaden, 1. Aufl. 2009, S. 113.

^[28] Vgl. Klems, Markus/Nimis, Jens/Tai, Stefan, Do Clouds Compute? A Framework for Estimating the Value of Cloud Computing, in: Weinhardt, Christof/Luckner, Stefan/Stößer, Jochen (Hrsg.), Designing E-Business Systems. Markets, Services, and Networks, Springer-Verlag, Berlin und Heidelberg, 1. Aufl. 2009, S. 110-121.

^[29] Vgl. Götze, Uwe, Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, Springer-Verlag, Berlin und Heidelberg, 6. Aufl. 2008, S. 180-181.

^[30] Siehe Götze, Uwe, Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, Springer-Verlag, Berlin und Heidelberg, 6. Aufl. 2008, S. 180-186.

^[31] Siehe Schierenbeck, Henner, Grundzüge der Betriebswirtschaftslehre, R. Oldenbourg Verlag, München und Wien, 15. Aufl. 2000, S. 157-161.

^[32] Vgl. Benlian, Alexander/Hess, Thomas/Wigand, Rolf T., SaaS und Servicequalität – werden die Kundenerwartungen erfüllt?, in: Wirtschaftsinformatik & Management, Band 2, November 2010, Heft 6, S. 18-25.

^[33] Vgl. Götze, Uwe, Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, Springer-Verlag, Berlin und Heidelberg, 6. Aufl. 2008, S. 181-184.

^[34] Siehe Henneberger, Matthias/Strebel, Jörg/Garzotto, Fabio, Ein Entscheidungsmodell für den Einsatz von Cloud Computing im Unternehmen, in: HMD - Praxis der Wirtschaftsinformatik, Oktober 2010, Heft 275, S. 80-83.

^[35] Eigene Darstellung, in Anlehnung an Osterloh, Margit/Frost, Jetta, Prozessmanagement als Kernkompetenz: Wie Sie Business Reengineering strategisch nutzen können, Gabler Verlag, Wiesbaden, 5. Aufl. 2006, S. 226.

^[36] Eigene Darstellung, in Anlehnung an Osterloh, Margit/Frost, Jetta, Prozessmanagement als Kernkompetenz: Wie Sie Business Reengineering strategisch nutzen können, Gabler Verlag, Wiesbaden, 5. Aufl. 2006, S. 226.

^[37] Vgl. Hodel, Marcus/Berger, Alexander/Risi, Peter, Outsourcing realisieren: Vorgehen für IT und Geschäftsprozesse zur nachhaltigen Steigerung des Unternehmenserfolgs, Vieweg Verlag, Wiesbaden, 2. Aufl. 2006, S. 74.

^[38] Hodel, Marcus/Berger, Alexander/Risi, Peter, Outsourcing realisieren: Vorgehen für IT und Geschäftsprozesse zur nachhaltigen Steigerung des Unternehmenserfolgs, Vieweg Verlag, Wiesbaden, 2. Aufl. 2006, S. 74 (im Original teilweise Fett formatiert).

^[39] Vgl. Hodel, Marcus/Berger, Alexander/Risi, Peter, Outsourcing realisieren: Vorgehen für IT und Geschäftsprozesse zur nachhaltigen Steigerung des Unternehmenserfolgs, Vieweg Verlag, Wiesbaden, 2. Aufl. 2006, S. 187.

^[40] Vgl. Klimmer, Matthias, Unternehmensorganisation: Eine kompakte und praxisnahe Einführung, Verlag Neue Wirtschafts-Briefe, Herne, 2. Aufl. 2009, S. 199.

^[41] Vgl. Abts, Dietmar/Mülder, Wilhelm, Grundkurs Wirtschaftsinformatik: Eine kompakte und praxisorientierte Einführung, Vieweg+Teubner, Wiesbaden, 6. Aufl. 2009, S. 309.

^[42] Vgl. Abts, Dietmar/Mülder, Wilhelm, Grundkurs Wirtschaftsinformatik: Eine kompakte und praxisorientierte Einführung, Vieweg+Teubner, Wiesbaden, 6. Aufl. 2009, S. 308-309.

^[43] Eigene Darstellung.