Cloud Services

Cloudy Monday IV: Heute in die Cloud und dann schauen wir mal!

In vielen Bereichen wurden in den letzten Jahren durch den ansteigenden Preisdruck Massnahmen ergriffen, um Kosten zu reduzieren. Dabei wurden Anstrengungen in diversen Bereichen unternommen, oft auch solche, die kurzfristig Mehrkosten verursachten. Sei es durch ein Projekt oder durch die Anschaffung von Infrastruktur oder Software. Grundsätzlich spricht nichts gegen dieses Vorgehen und damit wurden auch Einsparungen erzielt. Wo gibt es aber noch Potential? Gerade in der IT verspricht die Migration und Konsolidierung der Informatikmittel in die Cloud ein nicht zu unterschätzendes Einsparungspotential.

Von Nicolas Dörig, Product Manager

27. März 2017

Wie stellt man aber sicher, dass die Journey to the Cloud ein Erfolg wird?

Sich aus finanzieller Sicht für einen solchen Schritt zu entscheiden ist das eine, die Kultur und nicht zuletzt die diversen Individuen in dem eigenen Unternehmen aber als bedingungslose Supporter oder Promoter eines solchen Ansatzes zu gewinnen, ist eine Herkulesaufgabe für sich. Nicht zuletzt werden mit einem solchen Vorhaben auch Existenzängste hervorgerufen und es bilden sich grosse Widerstände, welche das gewünschte Ziel der Kostensenkung und der Effizienzsteigerung zum scheitern bringen können. Ein interessanter Ansatz für Anbieter von Cloudlösungen wäre neben dem Verkauf der technischen Lösung, auch ein Dienstleistungsangebot rund um den Culture Change.

Ein Erfolgsfaktor spielen also die Alternativen und Zukunftsaussichten, welche ein Unternehmen den Mitarbeitenden beim Start eines solchen Projektes aufzeigen kann.

Es ist aber nicht nur die Kultur, welche sich auf die neuen Gegebenheiten einstellen muss, denn die Kultur ändert man nicht einfach mal so nebenbei! Wesentlich für den Entscheid, die Journey to the Cloud anzutreten, ist somit, dass die Mitarbeitenden verstehen, wieso das gemacht werden soll und wo für sie Chancen und Vorteile daraus entstehen.

Ein weiterer Erfolgsfaktor liegt beim Umdenken in der Planung von Ressourcen und Budgetierungen von Infrastrukturen und Software. Anfänglich betrieb man die meist noch kleine IT selber und die Kosten waren sekundär. Mit dem steigenden Kostenbewusstsein und der Tatsache, dass sich das IT Knowhow breiter abstützt, wurde die IT vom unangefochtenen Hauptdarsteller zum Mittel zum Zweck und somit suchte man Lösungen, welche die Kosten senken. Begriffe wie Outsourcing, Offshoring, Nearshoring machten sich in jedem Geschäftsbericht gut und zeigte den Willen zur Minimierung der Kosten. Das Ressourcen Management war aber immer noch eng mit dem Controlling und der Finanzbuchhaltung verbunden. Es wurde analysiert, evaluiert und, meist auf Basis von Kosten und Nutzen, entschieden, welche Lösung eingesetzt wird. Klar, dass Kunden bei einem IT Outsourcer nicht wirklich nach Services mit definierten SLAs suchten, sondern bis auf das Bit und Byte mitreden wollten, was dieser wie zu betreiben hat.

Wieso sollte das in der Cloud anders sein?

Nun geht es künftig also in die Cloud, und genau hier muss ein Umdenken beginnen. Der Anbieter einer Cloudlösung setzt technische Komponenten ein, welche den Kunden in keinster Weise interessieren müssen. Was die Kunden interessieren muss, sind die zugesicherten Service Levels und Performanceparameter. Kunden beziehen einen Standard und sparen damit Kosten ein, der Cloudanbieter seinerseits spart Kosten durch die Masse bzw. deren Gleichartigkeit in der Produktion des Services und den daraus entstehenden Synergien, auch bekannt unter dem Begriff Economies of Scale.

Hierzu ein kleines Beispiel aus dem Produkt Dynamic Database von Swisscom:

Dieser Service stellt dem Kunden eine Oracle DB as a Service bereit, also die Infrastruktur, die Lizenzen, der Support und Optionen wie Hochverfügbarkeit, Disaster Recovery und Backup, alles in einem Tages oder Stundenpreis. Der Kunde zahlt nur was er nutzt und ist nicht langfristig gebunden.

Früher mussten Kunden ihre Infrastruktur bereits bei der Beschaffung so dimensionieren, dass die Lizenzkosten tragbar waren, die Lösung bei stetigem Wachstum aber nicht bereits nach einem Jahr ersetzt werden musste. Fehleinschätzungen wurden teuer und es gab jeweils drei mögliche Szenarien, die eintreten konnten:

A) Überdimensionierung: Zu teure Infrastruktur wurde eingesetzt und damit mussten auch mehr Lizenzen eingekauft werden, genutzt wurde es aber nie.
B) Unterdimensionierung: Zusatzinvestition, denn noch vor der Abschreibung des ersten Systems musste ein neues beschafft und dafür auch die Lizenzen eingekauft werden.
C) Jackpot: Die Annahme entsprach der realen Entwicklung.

Wenn man heute Unternehmen fragen würde, welches Szenario bei ihnen am häufigsten vorgekommen ist, glaube ich nicht, dass bei einer ehrlichen Beantwortung dieser Frage viele auf das Szenario C verweisen würden! Was hier auch ausser Acht gelassen wird, Szenario B hatte eine valide Chance anschliessend noch einmal in einer Unterdimensionierung oder sogar in einer Überdimensionierung zu enden.

Neben der Fehleinschätzung bezüglich der Dimensionierung einer Lösung ist aber ein weiterer Punkt mindestens eben so relevant. Egal in welchem Szenario die Investition endete, es war eine Vorinvestition, welche das Kapital gebunden hat und durch vertragliche Gegebenheiten jährliche Kosten für Lizenzsupport & Wartung mit sich brachte.

Alles in allem eine sehr kostenintensive Angelegenheit, bei welcher die Systemerneuerungskosten und die Personalkosten für Datenbankspezialisten noch nicht einmal berücksichtigt sind!

Um bei dem Beispiel zu bleiben: Dynamic Database würde diesen Investitionen nach einem kurzen Migrationsauftrag (als Richtwert 2 Arbeitstage), hinfällig machen. Die Bedingung für den Kunden liegt aber auf der Hand. Er bezieht einen standardisierten Service, welcher die Wahl von gewissen Optionen ermöglicht und auch gewisse Service Levels wie Availability und Support Time anbietet. Das Bestimmen von Infrastrukturelementen wie Server Typ, CPU Taktung etc. liegt aber nicht (mehr) in der Verantwortung des Kunden. Dafür spart der Kunde Geld ein, unter Umständen sogar sehr viel Geld.

Damit komme ich zurück zu der Ausgangsfrage: Warum sollte das für die Cloud anders sein?

Weil die Spielregeln geändert haben und die Budgetierung von IT variabler wird, genau so wie eine Mobiltelefonrechnung vor einigen Jahren. Man konnte nach einer Stabilisierungsphase sagen, was man ungefähr pro Monat zahlen muss, weil man sein eigenes Nutzungsverhalten kannte. Gerade in jüngeren Jahren, wenn mal das Geld knapp wurde oder man sich etwas Teures anschaffen wollte, hat man ggf. ein paar SMS weniger geschrieben oder das Festnetz genutzt und so die Kosten optimiert. In der Cloud funktioniert das grundsätzlich nicht anders und wer weiss, evtl. gibt es ja schon bald die ersten Flatrates für die B2B Cloud.

Das Umdenken ist also ein weiterer Erfolgsfaktor auf dem Weg in die Cloud. Ich staune immer wieder, in welche Diskussionen ich verwickelt werde, wenn ich Dynamic Database bei Kunden vorstellen darf: Wie viele mit mir über die Hardware und deren Leistungsfähigkeit philosophieren wollen und wie viele über das inkludierte Lizenzpaket diskutieren wollen. Wie mir dann erklärt wird, dass sie gewisse Lizenzoptionen, welche mit dem Service angeboten werden, gar nicht brauchen und ob man diese exkludieren kann und so auf einen günstigeren Preis kommt. Dass sie aber jahrelang aufgrund einer überdimensionierten Hardware überlizenziert waren und mit Dynamic Database umgehend von ihren hohen Investitionen bzw. der Kapitalbindung wegkommen würden, scheint für viele im ersten Gespräch noch indiskutabel. Vermutlich weil viele noch in ihren alten Denkmustern agieren und einfach mal den Preis minimieren wollen und dazu Potential suchen, in dem sie versuchen Leistungen wegzustreichen, welche für sie irrelevant sind. Aber gerade wegen diesen Individualisierungen hatten IT Provider in der Vergangenheit Mühe, ihre Kostenstrukturen im Griff zu halten und den Kunden interessante Angebote zu machen.

Zusammengefasst:

Wer auf der Journey to the Cloud erfolgreich sein will, muss seinen Mitarbeitenden die damit verbundenen Ziele klar aufzeigen, Mitarbeitende zu Beteiligten machen, ihnen Perspektiven aufzeigen und alte Denkmuster über Bord werfen. Vor allem muss man bereit sein, einen standardisierten Service zu beziehen, bei welchem man nicht bis ins Detail mitbestimmen kann, wie er produziert wird, aber selbstverständlich immer Anforderungen an die Leistung im Bezug auf Service Levels stellen darf.

Zurzeit befinden wir uns in einer Lernphasen, in welcher genau dieses Umdenken stattfindet. Dazu eine schöne Aussage eines Kunden, welche ich vor wenigen Wochen zu hören bekommen habe: „Wir möchten euren Standard Service beziehen, aber wir wollen nur 15 Tage nicht 31 Tage Backup und bei dem XS Angebot brauchen wir nicht 16 GB RAM sondern 8 GB reichen aus. Wie wirkt sich das auf die Preise aus?“ 🙂

In diesem Sinne, let’s get ready for the Journey to the Cloud.

Nicolas Dörig

Product Manager

Mehr getIT-Beiträge

Bereit für Swisscom

Finde deinen Job oder die Karrierewelt, die zu dir passt. In der du mitgestalten und dich weiterentwickeln willst.

Was du draus machst, ist was uns ausmacht.