1 Einführung

1.1 Problemstellung

Public Cloud Services sind eine externe Form der Bereitstellung von IT-Services, welche aus Sicht des Anwenders eine IT-Infrastruktur mit fremden Personal auf fremden Ressourcen betrieben werden. Eine Zuordnung von Nutzer und physischen Ressourcen ist nicht möglich. Die Nutzer bedienen sich virtualisierter Hardware und üben eine reine Nutzerrolle bei der Verwendung der IT-Services aus. Sie greifen innerhalb eines Mandanten in einer virtualisierten Umgebung des Dienstleisters auf „ihre“ Daten zu (vgl. Brassel und Gadatsch 2019).

Die Nutzung von Public Cloud Services nimmt zu (vgl. z. B. Cisco 2016). Viele Unternehmen stehen vor der Herausforderung, die große Zahl der Cloud-Projekte zu steuern. Der Beitrag schildert aus der Perspektive zahlreicher Implementierungen eine mögliche Vorgehensweise, welche an unternehmensbezogene Belange angepasst werden kann.

1.2 Motivation

Die Motive für die professionelle Nutzung von Public Cloud Services betreffen Kosteneinsparungen, Prozessverbesserungen, Zugang zu Innovationen, Qualitätsverbesserungen, Konzentration auf das Kerngeschäft oder der allgemeine Wunsch nach Erneuerung (vgl. z. B. die Studie von Gebauer et al. 2015). Ein wichtiger Aspekt ist, ob es sich bei der Maßnahme um ein Einzelvorhaben handelt (z. B. Nutzung von Cloud-Services für die Reisekostenabrechnung, initiiert durch die Buchhaltung) oder ob die Maßnahme ein Teil der Digitalisierungsstrategie des Unternehmens ist. Hieraus ergeben sich unterschiedliche Erwartungen an das Projekt und diese sollten zu Beginn festgelegt werden.

1.3 Einflussfaktoren

Um eine detaillierte Analyse von Cloud Services für ein Unternehmen durchzuführen sind zahlreiche relevante Einflussfaktoren zu identifizieren. Dies sind u. a. Branchenbezug, Zertifizierungen, Verträge mit Dritten, Personalvertretung und Datenschutz (vgl. z. B. die Studie von Gebauer et al. 2015).

1.3.1 Branchenbezug

Für personendatenintensive Branchen sind teilweise spezielle Regelungen der Datennutzung zu beachten, welche häufig Einschränkungen mit sich bringen. So gelten für Banken hinsichtlich Datenschutz und Datensicherheit besonders hohe Anforderungen, die durch die Vorgaben der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) in den Mindestanforderungen an das Risikomanagement (MaRisk) festgelegt wurden (vgl. z. B. Heng 2012, S. 8).

1.3.2 Zertifizierungen

Bereits durchgeführte oder geplante Zertifizierungen können die Entscheidungen für oder gegen Cloud Services beeinflussen, insbesondere wenn Sie einen übergreifenden Charakter haben, wie z. B. eine Zertifizierung nach ISO 27001 (vgl. BSI 2020).

1.3.3 Verträge mit Dritten

Auch gilt es zu prüfen, ob Verträge mit dritten Parteien Vereinbarungen enthalten, welche einen Einfluss auf die Handhabung interner Daten und Informationen nehmen. Als Beispiel für vermutlich aus Kundensicht überraschend ausgestaltete Verträge mit Cloud-Dienstleistern sei auf den Dienst „Analytics“ (vgl. Microsoft 2020a) des Microsoft Services „Microsoft 365“ (vgl. Microsoft 2020b) hingewiesen. Innerhalb dieses Angebotes werden dem Nutzer Daten über seine Aktivitäten im Rahmen der Nutzung des Services zur Verfügung gestellt. Problematisch ist, ungeachtet der Frage nach der Vereinbarkeit einer solchen Funktion mit datenschutzrechtlichen Grundsätzen (DSVGO, vgl. BMWI 2020), dass die Funktion von Microsoft automatisch aktiviert werden kann (vgl. Schulzki-Haddouti 2020). Ein derartiger Umgang mit personenbezogenen Daten sollte eine unternehmensinterne Diskussion unter Einbeziehung der betroffenen bzw. verantwortlichen Parteien und daraus folgend eine entsprechende Betriebsvereinbarung nach sich ziehen.

1.3.4 Personalvertretung

Sofern im Unternehmen vorhanden, sollte ein Betriebsrat in den Entscheidungsprozess mit eingebunden werden, da die Funktionalität von Public Cloud Diensten in Bezug auf Analysefunktionen mit Mitarbeiterbezug bedeutend sein könnten und einem modernen Konzept der Arbeitnehmervertretung entsprechen (vgl. z. B. Georg et al. 2018).

1.3.5 Datenschutz

Eine hohe Aufmerksamkeit sollte auch auf wesentlich weitreichendere personenbezogene Datenanalysedienste von Microsoft gelegt werden, welche im Rahmen der Services von Microsoft 365 mit klarem Fokus auf die Unternehmensleitung zur Verfügung stehen, wie z. B. „Microsoft Workplace Analytics“ (vgl. Microsoft 2020c).

2 Vorgehensmodell

Als Vorgehen für die Einführung von Cloud-Services werden folgende Schritte vorgeschlagen: Voruntersuchung, Bedarfsanalyse und Identifikation der Auswirkungen (vgl. Tab. 1). Nach einer Voruntersuchung sollten die Handlungsoptionen feststehen. Für jede relevante Option kann anschließend eine Bedarfsanalyse für die notwendigen Aufwendungen vorgenommen werden. Abschließend sind die Auswirkungen der Alternativen auf das Prozessumfeld zu identifizieren um hieraus eine Planung zu erstellen.

Tab. 1 Vorgehensmodell Public Cloud Services
Full size table

3 Management-Sicht: Public Cloud Services ist Paradigmenwechsel

Die Nutzung von Cloud-Services ist mit Veränderungen vieler Prozesse verbunden und fordert ein Umdenken aller Beteiligten. Im klassischen IT-Sourcing-Modell (Kauf und Nutzung der Software auf eigenen Ressourcen) steht der „Lizenzvertrag“ mit dem Softwareanbieter im Vordergrund. Weitere Fragen drehen sich um den Betrieb und die Nutzung der Software im eigenen Rechenzentrum.

Der Wechsel zum „Public Cloud Service-Modell“ ist ein Paradigmenwechsel. Cloud-Dienstleister bieten nicht nur den externen Betrieb der Software (klassisches Outsourcing), sondern offerieren weitere Services und Prozesse. Damit bewegt sich der Standardsoftwaremarkt in Richtung „Business Process Outsourcing“. Der Kunde bezieht und nutzt Services (Prozesse), welche die Nutzung von Hardware, Software sowie weiteren Dienstleistungen umfassen. Die „klassische“ Lizenzierung der Software spielt nur noch eine untergeordnete Rolle (vgl. Brassel und Gadatsch 2019, S. 59–60). Vereinfachend lässt sich sagen: Die Nutzung von Public Cloud Services entspricht einem Outsourcing von IT-Diensten und den damit verbundenen Prozessen zu standardisierten und nicht durch den Kunden anpassbaren Vertragskonditionen.

Besonders wichtig ist hierbei die Zielsetzung der Entscheider zu hinterfragen. Häufig sind Kosteneinsparungen zumindest im ersten Schritt schwer zu realisieren. Valide Ansatzpunkte für den Einsatz von Public Cloud Services können zum Beispiel die Modernisierung der eigenen IT-Infrastruktur, die flexible Nutzung von Rechenzentrumsleistungen oder die verstärkte Nutzung von Standardsoftware sein (z. B. Office von Microsoft).

Die Anforderungen einzelner Fachabteilungen sind zu berücksichtigen. Wichtig ist, die Anforderungen am Nutzen der jeweiligen Prozesse mit Blick auf die Wertschöpfungskette des Unternehmens zu spiegeln. Einen guten Einstieg in die Problematik bietet der Bereich der Büroprozesse und die oft genutzten Produkte der Firma Microsoft. Da diese einen klaren Fokus auf Public Cloud Services setzt, eignet sich dieses Umfeld besonders gut um erste Erfahrungen mit dem zielgerichteten Einsatz sowie potentiellen Fallstricken von Online-Services in einem Unternehmen zu sammeln.

4 Auswahl von Public Cloud Services

Nachdem die Anforderungen an Public Cloud Services geklärt sind, müssen konkrete Services ausgewählt werden. Am Beispiel der „Büroprozesse“ und des Diensteanbieters „Microsoft“ sollen einige grundlegende Aspekte thematisiert werden, die in der Praxis immer wieder diskutiert werden.

4.1 Vielfalt an Produktvarianten

Die Vielfalt von Produktvarianten und deren häufige Umbenennungen sind in der Praxis regelmäßig auftauchende Sachverhalte, die bei der Serviceauswahl relevant sind. Die Firma Microsoft hat beispielsweise zum 21. April 2020 einige ihrer bekanntesten Onlineservices zur Unterstützung von Büroprozessen umbenannt (vgl. Tab. 2). Weitere Varianten ergeben sich durch Zusätze wie „for Business“ oder „for Enterprise“, um zwischen Angeboten für kleine und mittelständische Unternehmen (Business) und Großunternehmen (Enterprise) zu unterscheiden (vgl. Microsoft 2020d).

Tab. 2 Microsoft-Services für Büroprozesse ab 21.02.2020
Full size table

Die Vielzahl der Einzelservices, Paketangebote und Namensänderungen zeigt die Notwendigkeit einer konkreten Bedarfsanalyse auf. Wichtig ist, dass es sich bei „Public Cloud Services“ um standardisierte Dienste zu feststehenden und nicht verhandelbaren Vertragsbedingungen handelt (z. B. bei Microsoft die sogenannten „Onlineterms“, vgl. Microsoft 2020e). Diese Angebote mit konkreten Leistungsabgrenzungen bzw. Leistungsausschlüssen können vom Kunden nicht geändert werden.

4.2 Spezifische Risiken von Public Cloud Services

Der Service Microsoft Teams (vgl. Microsoft 2020f) stellt Unternehmen eine umfassende Plattform für Prozesse der „Zusammenarbeit“ bzw. „Kommunikation“ zur Verfügung. In den Vertragsbestimmungen sind Details erhalten, die möglicherweise überraschend erscheinen. Für die Verwendung von Microsoft Teams in einem Unternehmen empfiehlt sich daher die Erarbeitung einer unternehmensinternen Nutzungsrichtlinie, damit die Nutzer im Unternehmen informiert sind. Beispielsweise enthält der Subdienst „Microsoft Planner“ (vgl. Microsoft 2020g) derzeit keine Datensicherungsfunktion. Zudem lassen sich Projektunterlagen nicht exportieren (vgl. Microsoft 2020h). Die produktive Nutzung im Unternehmen, beispielsweise im Rahmen von Kundenprojekten, könnte daher risikobehaftet sein. Das Risiko „Back-Up“ (revisionssichere Datenspeicherung) tritt generell im Zusammenhang mit der Nutzung von Public Cloud Diensten auf, da viele Anbieter die Einhaltung gesetzlicher Vorgaben nicht „automatisch“ garantieren (vgl. Ovat 2020). Auch schützen sie den Kunden generell nicht vor Datenverlusten (vgl. Microsoft 2020k).

Beispielhaft sei dies am Service „Office 365“ erläutert. In dem sogenannten „Tenant“ (vgl. Saxton 2015) lassen sich durchaus Aufbewahrungsrichtlinien (vgl. Microsoft 2020l) konfigurieren. Dies ist unter anderem für die Services „Exchange Online“, „Teams“, „Share Point Online“ möglich. Die konkrete Auswirkung ist, dass Daten bei Verlust (z. B. durch Löschung durch den Nutzer) weder für den Administrator, noch den Nutzer sichtbar für einen bestimmten Zeitraum aufbewahrt werden. Bei Bedarf kann ein berechtigter Administrator nach „verlorenen Inhalten“ suchen. Dies erfordert jedoch eine manuelle Definition der entsprechenden Suchparameter, was in der Praxis aufwandsbedingt eher selten durchgeführt wird. Zudem es nicht möglich, einzelne Versionsstände von Dokumenten oder Daten an einen bestimmten Zielort (z. B. Posteingang) zurückzusetzen. Werden Nutzer aus der Aufbewahrungsrichtlinie entfernt, werden die entsprechenden Daten unwiederbringlich gelöscht! Es existiert keine unabhängige revisionssichere Kopie der Daten (für detaillierte Informationen bzgl. Sicherheit und Compliance der Microsoft Public Cloud Services sei an dieser Stelle auf den entsprechenden Leitfaden für Microsoft 365 verwiesen) (vgl. Microsoft 2020m). Die Anforderungen an ein durch einen Nutzer zu erwartendes „Back-Up“ sind vermutlich anders gestaltet.

4.3 Serverworkloads als Schlüsselfaktor für die Migration in die Cloud

Die Dimensionierung des Serverworkloads ist eine zentrale Fragestellung, die bei einem Wechsel in eine Public Cloud zu treffen ist. Hierbei sind Fragen der Verfügbarkeit und den Auswirkungen auf geschäftskritische Prozesse zu beantworten. Verfügbarkeit und Skalierbarkeit der Public Cloud Services sind üblicherweise Parameter der Preismodelle der Anbieter (vgl. Abb. 1). Einen ersten Eindruck bzgl. der Auswirkungen der Workloads auf Nutzungskosten bieten die im Netz verfügbaren Preisrechner der Anbieter Microsoft für das Produkt Azure (vgl. Microsoft 2020i), Amazon für das Produkt Amazon Webservices (AWS, vgl. Amazon 2020a) oder IBM (vgl. IBM 2020).

Abb. 1
figure 1

Preismodelle für Public Cloud-Services

Full size image

In diesen Fällen liefern die Tools Schätzungen, die durch erfahrene Consultants präzisiert werden können. Ein wichtiger Punkt, der oftmals übersehen wird, ist die Möglichkeit und reale Praxis von Cloud-Anbietern, dass die Produkt- und Preispolitik jederzeit geändert werden kann. Angesichts der Lock-in-Effekte solcher Lösungen (hohe Wechselhürden und -kosten), ist dies ein wichtiges Unsicherheitskriterium.

Viele Services, wie z. B. „Reservierung“ von Rechenleistung bei Amazon (vgl. Amazon 2020b), versprechen eine hohe Kostenersparnis. Die Flexibilität der „Public Cloud Services“ geht jedoch aufgrund der vertraglichen Bindungen teilweise verloren. Dies lässt lokal installierte Serverhardware unter Umständen wieder attraktiv werden. Hinzu kommt, dass plattformunabhängige Applikationen einen „Cloud-Broker“ Ansatz ermöglichen, durch den Rechenleistung bei unterschiedlichen Anbietern zum tagesaktuell günstigsten Preis zugekauft werden kann. Bislang konnten die Autoren noch keinen solchen Ansatz am Markt beobachten, sind aber zuversichtlich, dass vergleichbare Konzepte in Zukunft angeboten werden.

4.4 Cloud native versus Customized Services

Wie schon dargelegt, bietet es sich an, erste Erfahrungen mit Public Cloud Services im Rahmen der Nutzung von Standardangeboten wie Microsoft Office 365 zu sammeln. Grundlegende Fragen zum Thema Datenintegrität bzw. Datenschutz, technische Voraussetzungen bzw. Einschränkungen sowie die Diskussion der Unterstützung der Wertschöpfungskette innerhalb des Unternehmens, lassen sich hieran erfahren. Zudem wird die Problematik eines möglichen „Lock-in“-Effektes (vgl. Schonschek 2014) in Bezug auf die Services eines einzelnen Anbieters entsprechend transparent.

Fühlt sich ein Unternehmen „sicher“ mit dem Umgang von Public Cloud Angeboten und deren Einbindung in die zur Verfügung gestellten IT-Services, stellt sich die Frage nach individuellen Lösungsszenarien. Diese lassen sich in der Regel beispielsweise über Cloudplattformangebote wie Amazon Web Services, Microsoft Azure oder die Angebote von IBM abbilden.

Der bei klassischer IT-Serverinfrastruktur verfolgte Ansatz der Virtualisierung verwendet sogenannte „Hardware Abstraction Layer“ (vgl. hierzu z. B. Yoo und Jerraya 2003) als „Zwischenschicht“, auf der dann die sogenannten virtuellen Maschinen (VM) ausgeführt werden. Das Konzept jedoch hat einen gewichtigen Nachteil, denn jede VM muss separat aktualisiert werden (z. B. Betriebssystem und installierte Applikationen).

4.4.1 Betrieb virtueller Maschinen in der Cloud

Der reine Betrieb von virtuellen Maschinen auf Public Cloud Plattformen ist im Vergleich zum klassischem Rechenzentrumsbetrieb nicht immer attraktiv, da fixe Kosten entstehen können. Langfristig bindende Angebote, wie z. B. die Reservierung von Azure-Serverinstanzen führen zwar zu verringerten Kosten im Vergleich zur nutzungsbasierten Abrechnung, allerdings um den Preis der Flexibilität (vgl. Microsoft 2020j).

4.4.2 Container

Ein weiterer Ansatz ist die Nutzung der in der Praxis verbreiteten Containertechnologie (vgl. Computerwoche o.J.). Container bilden eine vollständige Laufzeitumgebung ab (inkl. Programmbibliotheken, Konfigurationsdateien und allen sonst nötigen Tools). Dadurch kann von den Betriebssystem-Distributionen und der darunterliegenden Infrastruktur abstrahiert werden. Auf diese Weise erstellte Programme, lassen sich vergleichsweise einfach von Betriebsplattform zu Betriebsplattform umziehen (vgl. Trüstedt 2017). Da sich Container basierte Programme auf einem Server Ressourcen teilen (wie z. B. das Betriebssystem), werden diese auch wesentlich effizienter genutzt. Darüber hinaus sind Container basierte Programme nicht monolithisch aufgebaut, sondern stellen „Microservices“ (vgl. Red Hat o.J.) dar, welche sich erheblich leichter handhaben lassen.

4.4.3 DevOps

In diesem Zusammenhang wird auch häufig „DevOps“ genannt (vgl. Augsten 2017), welches einen methodischen Ansatz im Umfeld der agilen Softwareentwicklung beschreibt. Gemeint ist damit nicht ein Methodenbaukasten auf den man als Unternehmen zurückgreifen kann, sondern ein Wandel innerhalb der Unternehmenskultur in Bezug auf die Zusammenarbeit einzelner Abteilungen und Geschäftsbereiche (vgl. Kim et al. 2015).

Die Entwicklung Cloud nativer Anwendungen, welche die Wertschöpfung des Unternehmens nachhaltig unterstützen, ist wesentlicher komplexer, als der Einsatz einer einzelnen Applikation oder eines Services. Es erfordert einen neuen methodischen Ansatz und einen Paradigmenwechsel innerhalb des Unternehmens, der nicht nur die IT-Abteilung betrifft, sondern auch andere Bereiche.

5 Praxisbeispiel

Die „Genussvoll Leben GmbH“ ist ein fiktives Handelsunternehmen aus der Nahrungsgenussmittelbranche. Als Zwischenhandelspartner ohne Endkonsumentenkontakt für hochwertige Genussmittel, liegen die unternehmerischen Schwerpunkte im weltweiten Einkauf und Verkauf der Waren. Das Unternehmen blickt auf eine über vierzigjährige Tradition zurück. Die Unternehmensführung sah Informationstechnologie dabei immer als „Hilfsinstrument“ für die logistische Abwicklung und die kaufmännischen Prozesse. Entsprechend blieben größere IT-Investitionen lange Zeit aus. Zudem zeigt sich dies auch in der geringen Personalstärke des IT-Teams. Bei insgesamt weltweit 500 Mitarbeitern standen dem kurz vor dem Ruhestand stehenden IT-Leiter nur drei Mitarbeitende zur Verfügung.

Seit Beginn des Jahres findet jedoch ein Umdenken innerhalb der Unternehmensleitung in Bezug auf die hauseigene IT-Infrastruktur statt. Eine Umfrage unter Mitarbeitern und Geschäftspartnern ergab, dass diese die zur Verfügung gestellte IT-Infrastruktur als „unattraktiv“ bewerten. Zudem ist in der Branche ein genereller Trend zur Digitalisierung von Geschäftsprozessen zu beobachten. Eine Analyse zeigte, dass die eingesetzten Softwarekomponenten zu großen Teilen nicht mehr durch Wartungsverträge abgesichert sind und veraltete Serverversionen eingesetzt werden, für die es keinerlei Unterstützung der Hersteller mehr gibt. Ein ähnliches Bild zeigte sich bei der genutzten Hardware.

Der neue IT-Leiter, der von seinem Amtsvorgänger noch einige Monate begleitet wird, beschloss daraufhin, einen Beratungsauftrag an einen externen Dienstleister zu vergeben, um der Geschäftsleitung einen Vorschlag für eine neue IT-Infrastruktur machen zu können. Eine erste Ergebnispräsentation stützt den bisherigen Eindruck:

  • Die Analyse des „Active Directory“ (AD) zeigt eine organisch gewachsene, inkonsistente Struktur im Aufbau.

  • Hardware und Software der virtualisierten Serverumgebung sind veraltet. Die verwendeten Remote Desktop Services müssten im Falle einer Erneuerung von IT-Serverkomponenten vollständig ersetzt werden.

  • Der ausgelagerte Emailservice zeigt sich im Vergleich zu einem entsprechenden Hyperscaler-Angebot als funktional unterlegen und dabei jedoch deutlich teurer in Bezug auf die monatlichen fixen Kosten.

  • Ein einheitliches Managementsystem für Endgeräte fehlt. Tablets sowie Smartphones sind zwar an den verwendeten Emaildienst angebunden, eine zentrale Verwaltung der Geräte findet aber nicht statt.

  • Ein umfassendes IT-Security-Konzept (Architektur, Endgeräte, Server, Gateways, Prozesse) ist nicht vorhanden. Erste Analysen zeigen, dass dem Unternehmen bereits Daten entwendet wurden.

  • Zudem fällt auf, dass Mitarbeiter einzelner Abteilungen bereits ohne Rücksprache mit der zentralen IT-Abteilung Public Cloud Services nutzen oder Unternehmensdaten „unkontrolliert“ über Cloud-Shares mit anderen Abteilungen sowie externen Geschäftspartnern teilen.

  • Das begleitend stattfindende Software-Asset-Management Projekt ergab, dass der komplette Bestand an verwendeter Software nicht mehr unter Wartung steht, von den Herstellern die meisten Versionen nicht mehr mit Sicherheitsupdates versorgt werden und zudem eine Vielzahl an Compliance Verstößen auszumachen sind.

Aufgrund des Gesamtbildes beschließt der Dienstleister, ein Konzept für eine vollständig neue, hybride IT-Infrastruktur anzubieten. Im Rahmen eines mehrtägigen Workshops mit unterschiedlichen Vertretern einzelner Abteilungen entsteht ein Gesamtbild der Anforderungen an die zukünftigen IT-Services.

  • Grundlage ist dabei ein neu gestaltetes „Active Directory“ welches zukünftig die Basis für ein „Identitymanagement“ bilden soll und als „Anker“ für die Verwaltung eingesetzter Software, Services, Endgeräteverwaltung dient.

  • Eine neue Serverinfrastruktur trennt kritische Dienste, welche weiterhin lokal betrieben werden, sowie flexibel zu nutzenden IaaS. Bei dem Design der Public Cloud Serverdienste wird durch den Dienstleiter darauf geachtet, eine möglichst verursachungsgerechte interne Verrechnung sicher stellen zu können.

  • Bei der Lizenzierung der notwendigen Server Software soll es möglich sein, Workloads kostengünstig (aus Lizenzierungssicht) zwischen Eigenbetrieb und Public Cloud Service zu „verschieben“.

  • Für die Kollaboration entscheidet sich das Unternehmen für das Angebot eines großen Anbieters von Public Cloud Services. Teil der Lösung ist ein umfassendes, revisionssicheres BackUp Konzept.

  • Die Administration der zukünftigen Umgebung soll vom Dienstleister als „Service“ bezogen werden kein zusätzliches IT-Personal einstellen zu müssen.

Ergänzend wurde ein umfassendes IT-Sicherheitskonzept erarbeitet, das neben technischen Komponenten, auch eine Sensibilisierung der Mitarbeiter durch einen Anbieter aus dem Umfeld des „Social-Engineering“ vorsieht.

6 Fazit

Die Implementierung von Public Cloud Services in die betriebliche IT-Infrastruktur erfordert im Vorfeld einen fachlich begleiteten Workshop, dessen Ergebnisse die notwendigen Schritte für die Nutzung der Dienste insbesondere im Hinblick auf hybride Infrastrukturszenarien aufzeigt. Der Schwerpunkt sollte nicht auf der technischen Machbarkeit, sondern der optimalen Geschäftsprozessunterstützung liegen. Public Cloud Services sollten nicht eingesetzt werden, weil das Konzept „im Trend“ liegt, sondern zur Erfüllung der sich verändernden Anforderungen. Die Frage des „IT-Sourcing“ sollte sich daher ausschließlich am Mehrwert für die Wertschöpfungskette des Unternehmens orientieren. Ausgehend von einer Bedarfsanalyse und einer spezifischen Konzeption sollte am Ende des Projektes ein individuelles Lösungsszenario stehen.

Um den Nutzen von Public Cloud Services bewerten zu können, sollten im Zuge der Analyse personelle und materielle Aufwände (Beratungsleistungen, Implementierung, Hardware, Software, Public Cloud Services) erfasst und dargestellt werden. Um die Auswirkungen auf den laufenden IT-Betrieb abschätzen zu können, sowie eine „realistische“ Erwartungshaltung in Bezug auf die Zeitachse des Projektes bei Anwendern und Entscheidern sicher zu stellen, sollte eine konkrete Projektimplementierungsplanung vorgenommen werden.