In der heutigen Folge unterhalte ich mich mit dem Digital-Transformer Tayfun Tastan über das Thema Cloud-Transformation. Hallo und herzlich willkommen zu Ein Geek kommt selten allein. Mein Name ist Stephan und heute freue ich mich besonders, den Digital-Transformator Tayfun begrüßen zu dürfen. Hallo, freut mich. Wir beide sprechen heute über den riesigen Berg Cloud Transformation und wie eine erfolgreiche Reise in die Cloud verlaufen kann und natürlich auch, was für Risiken auf dem Weg liegen. Bevor es aber jetzt losgeht und wir tief in das Thema abtauchen, Taifun, geht es erstmal um dich. Was bringt dich überhaupt dazu, digitale Transformationen zu begleiten? Ja, das ist eine sehr gute Frage. Ja, ich beschäftige mich, seit es Cloud-Technologien gibt, historisch gewachsen. Ich komme von einem Konzern, der ja sehr aktuell auch sehr groß im Cloud-Umfeld unterwegs ist, bei der Firma Microsoft und durfte da schon die Cloud mit aufbauen, mit entwickeln und dadurch halt auch Kunden begeistern im Bereich Cloud-Transformation. Wenn. Wir über Cloud Transformation sprechen, ich finde, da reden wir relativ viel drüber. Also auch bei uns im Unternehmen reden wir viel darüber. Und ich finde es immer so wenig greifbar. Und ich frage mich dann immer, was genau meint eigentlich Cloud Transformation? Und deswegen würde ich gerne einsteigen mit der Frage, woran merkt man eigentlich, dass irgendjemand erfolgreich eine Cloud Transformation gemacht hat? Hast du da irgendwie eine Idee? Also wie man es messbar machen kann, kann man es ja wahrscheinlich am einfachsten machen, dass man eine höhere Skalierung hat und am Ende des Tages einen höheren Umsatz gewinnt. Wachstum, Qualität, das sind alles Merkmale, die man natürlich sehr grob erstmal definiert sind, aber natürlich unternehmerisch zu sagen, ich bin in der Lage als Vorjahr viel schneller Services, IT-Services auszuliefern, Fachbereiche zu entfalten, ihre Anforderungen schneller abzubilden, schneller auf Geschäftsanforderungen und Marktanforderungen zu reagieren und nicht nur technologisch, sondern auch als Organisation. Ja, beflügelt mit Prozessen. Daran erkenne ich, ob eine Cloud-Transformation sauber oder in die richtige Richtung geht. Eine Cloud-Transformation oder eine Transformation an sich sollte im Idealfall nie enden, sondern sich immer stetig weiterentwickeln. Das bedeutet ja auch, dass du im Grunde genommen eher nach innen gehst. Also wenn man jetzt sagt, würde ich eher was nach außen ändern, sprich mein Produkt großartig ändern oder ich würde vielleicht meine Channels in der letzten Vorgesprache über Channels ändern, aber das ist ja mehr ein organisatorisches, wie ich mich als Unternehmen aufstelle. Wenn ich sage skalieren, wenn ich sage schneller Services bereitstellen. Als Kunde weiß ich das ja gar nicht. Ich weiß ja nicht, ob jetzt hier der Karstadt, in den ich nebenan gehe, ob der schnell oder langsam Services bereitstellt. Das heißt, Cloud-Chance-Formation ist eigentlich ein Thema, was nach innen den meisten Mehrwert bietet, oder? Als erstes ja, sollte natürlich auch im Idealzustand auch nach außen hin ausgestrahlt werden. Das heißt, der Kunde merkt das dadurch, dass gewisse Bestellvorgänge viel schneller laufen, eine höhere Servicequalität, Reaktionszeit der Kunde mitbekommt und einfach, wenn es im Einzelhandel ist, dass die Produkte, die dort angeboten werden, immer verfügbar sind und idealerweise zum günstigsten Preis in der höchsten Qualität. Wer sind denn so die Treiber, aus deiner Erfahrung, die Cloud-Transformationen initiieren? Ist es eher eine Top-Down-Entscheidung, wo eine Geschäftsleitung sagt, wir müssen eine Cloud-Transformation machen? Ist es eher aus einer Entwicklerecke, wo man sagt, wäre mal ganz schön, wenn wir ein bisschen mehr Cloud hätten? Das ist in der Tat total unterschiedlich. Die einen kommen als Visionär im Unternehmen und haben gewisse Ziele in den kommenden Jahren mit dem Unternehmen irgendwo zu stehen und reflektieren dann halt mit der Ist-Situation. Wo stehe ich denn eigentlich und was muss ich tun und mit welchen Mitteln kann ich das tun? Und dann kommt man ziemlich schnell auf die Erkenntnis, dass man mit der jetzigen organisatorischen, technologischen Aufstellung nicht in der Lage ist, diese Ziele adäquat zu erreichen. Die andere Perspektive ist, gerade im Mittelstand merke ich das ziemlich häufig bei Kunden, dass sie aus der technologischen Perspektive der Treiber ist, weil man veraltete Systeme hat, dort eine große Investition wagen muss, teilweise auch ein Stück weit Stillstand in der Evolution der Technologie gemacht hat, weil es lief ja irgendwie alles und am Ende des Tages soll IT ja ihren Zweck erfüllen, da zu sein. Und ich möchte ja auch, und das ist natürlich ein Stück weit die Innovationsbremse bei Familienunternehmen oder Mittelständlern oder Geschäftsführern, die dann halt die Technik als, ja, oder Innovation, nicht so innovationsbereit sind. Und somit Investitionen teilweise gehalten werden oder jahrelang ausgesetzt werden und dann man irgendwann von den Technikern, von seinen Engineers genötigt wird hier zu handeln und wenn man halt Monate, jahrelang Stillstand hat, dann überlegt man sich dreimal, ob man jetzt große Investitionen in vorhandene Rechenzentren und Hardware tut. Oder ob man sie mit einer Cloud strategisch entgegen wird, wo man die Investitionen Stück für Stück hochfahren kann. Ich kenne Unternehmen, die haben über Jahre ihre eigene ERP- oder CRM-Software geschrieben. Sind ganz stolz und das ist schön und die muss man maintainen. Es gibt sogar Kunden, die haben eine AS400 im Keller und freuen sich auch, dass die schön läuft. Und irgendwann kommt der Moment, wo man sagt, die AS400 oder aber die Software, die wir da haben. Kennen das noch welche? Tatsächlich im Versicherungsumfeld ist es nicht ganz so unüblich, dass man auch nochmal einen Mainframe hat, Der funktioniert ja und da sind sicherheitskritische Anwendungen und dann irgendwann staunen sich Dinge und dann bist du bei Modernisierungsprojekten und Modernisierungsprojekte überlappen dann irgendwie mit der Cloud-Transformation. Dass du sagst, wenn wir eh modernisieren, machen wir noch was. Immer eine gute Idee, viele Steine gleichzeitig zu bewegen, weil was kann schon passieren. Aber besser wäre es natürlich zu sagen, man macht alles so Stück für Stück und ich glaube, deswegen sollten wir es auch mal so ein bisschen sortieren und sagen so Stück für Stück. Wenn wir über Cloud reden, da hat ja jeder immer eine andere Vorstellung. Wie würdest du Cloud definieren und sagen, was ist Cloud? Also, jetzt aus der Informatikperspektive betrachtet, ja, aus meinem Informatikstudium sage ich, ja, die Cloud ist ja nichts anderes als ein Remote-Rechenzentrum. Ein Rechenzentrum von Zusammenschluss von Netzwerkkomponenten, Serverkomponenten, Storage dahinter und am Ende des Tages dann halt von der Ferne aus zugreifbar. Natürlich ist Cloud, wie wir sie heute kennen als eine AS400 früher, viel, viel skalierbarer und flexibler und das Leistungsangebot ist ja auch einfach wesentlich höher geworden. Es ist schneller von Kunden und von Unternehmen partizipierbar und nutzbar und konsumierbar. Aber Cloud an für sich ist ja, da gibt es ja zwei Ausprägungen. Es gibt einmal die Private Cloud und einmal die Public Cloud. Von der Thematik her, von der Struktur her ist es nahezu eigentlich gleich, dass dort Komponenten in Rechenzentren bereitgestellt werden, die dann von Kunden oder von einem einzelnen Unternehmen in der Hoheit genutzt werden. Gerade im Hinblick, dass Unternehmen immer größer international unterwegs sind und internationale Teams haben und internationale Strukturen, ist die Zusammenarbeit mit Cloud-Komponenten und das Bereitstellkonzept natürlich auch, auf die Kundenanforderungen zu reagieren, in der Cloud wesentlich flexibler und schneller, als wenn man das in einem eigenen Rechenzentrum betreibt. Irgendwer hatte mal gesagt, oder ich habe es in Heise-Kommentaren gelesen, The Cloud is just someone else's computer. Und ich finde, im Grunde genommen mag das ja stimmen, aber der spannende Teil oder der mir super oft begegnet, ist, alle Leute, die über Cloud sprechen, sprechen auch irgendwie über Kubernetes. Also die sprechen über Elastizität, die sprechen darüber, du hast eigentlich kein Ende. Weil du hast ja zwar bestimmte Rechenkapazitäten in deinem eigenen Rechner, in deiner AS400, aber was, wenn du darüber hinaus gehst? Also kaufst du eine größere AS400 oder wie gehst du darüber hinaus? Und das ist bei der Cloud eben das Spannende, dass man sagt, eigentlich spielen physische Grenzen gar keine Rolle mehr. Und du kannst über Geo-Redundanz oder du kannst über Virtual RAM, ich erweitere das einfach, kannst einfach was Großes machen und das ist glaube ich das, was für mich bei der Cloud einen großen Eindruck macht, und ich muss dieses Beispiel bringen, weil ich habe das jetzt vor einer Woche oder so gelesen, es hat mich einfach so geflasht, KI ist ja gerade in aller Munde und alle wollen ganz viel KI machen und ich weiß nicht, ob du das gesehen hast, Meta hat ja jetzt angekündigt, die wollen so ein paar H100 Chips von Nvidia kaufen. Ja, ich glaube ein Investitionsvolumen von 9 Milliarden circa, ne? Ja, genau. Die wollen 350.000 H100 kaufen. Das ist die Goldserie, glaube ich, von denen. Das sind die Dinger, die 20.000 bis 30.000 Dollar pro Stück kosten. Deswegen kommst du ganz schnell dahin. Insgesamt wollen sie, glaube ich, 600.000 Chips, die H100 wertig sind, haben. Wo du dann bei der Cloud natürlich bist und dir sagst, toll, das ist aber sehr elastisch. Da kannst du dann jederzeit quasi deinen Bedarf nachfahren. Ich frage mich, wo die die Kernkraftwerke bauen, damit das auch funktioniert, weil die brauchen ja auch so ein paar Watt pro jeweiligen Kern. Aber das ist so das Cloud-Thema. Du musst nicht vorher sagen, wie viel brauche ich eigentlich. Und das Schöne dann, wenn du sagst, jetzt kommen Leute aus der ganzen Welt in eine Cloud, du kannst eben sagen, manche Dinge sind halt Lastspitzen getrieben. Also wenn ich jetzt hier dran denke, du hast einen Streaming-Dienst eines Fernsehsenders und abends gucken alle Leute Tagesschau, dann musst du abends Tagesschau streamen können. Aber vielleicht um 13, 14, 15 Uhr brauchst du fast gar keine Ressourcen, weil da streamt eben keiner. Und das ist in der Cloud eben gut, dass du nicht 90 Prozent des Tages eilen musst, oder wie beim Auto, das steht nur rum und dann fährst du einmal, sondern du kannst es wirklich hochfahren, wenn du es brauchst. Richtig, diese schnelle Bereitstellung und Anpassung an die Anforderungen selbst. Ich spitze das mal weiter. Ich habe zum Beispiel in einer Branche, gerade im Lebensmittelhandel, wo ich auch ganz stark unterwegs bin, auch immer bestimmte Phasen, wo der Einzelhandel, gerade im Lebensmittelhandel, bestimmte Spitzzeiten hat. Nehmen wir mal an, die Weihnachtszeit, die Bissinniche Zeit, wo viel mehr Performance und Workload-Performance benötigt wird vom Kunden. Und das muss die IT bereitstellen. Und dann außerhalb der Zeit liegen die Systeme oder die Ressourcen dann brach. Und das ist nicht gerade effizient. Vor allen Dingen auch die Investition, die dahinter hängt. Das kann man mit einer Cloud entgegenwirken und sagen, ich buche mir oder reserviere mir bestimmte Kapazitäten. Und dann, wenn ich sie nicht mehr brauche, gebe ich sie wieder ab. Und das kann man in einem lokalen Rechenzentrum sehr schwierig, bis gar nicht. In der Cloud kann man das schon, aber man muss auch die Spielregeln der Cloud verstehen und auch den Kulturwandel, weil mit der Cloud kommt auch der Wandel, eine andere Perspektive einzunehmen, damit das auch funktioniert. Lass uns kurz noch darauf eingehen, du hattest schon über Private und Public Cloud gesprochen und wir hatten gesagt, wir können ganz viel skalieren und da ist jetzt das Rechenzentrum woanders. Bedeutet Public Cloud für dich, dass du quasi die Cloud in deinem Keller betreibst? Also ich habe das schon gesehen, dass Leute quasi das als Verständnis haben oder würdest du sagen, Public Cloud auf den klassischen Hyperscalern, über die wir sicherlich auch gleich noch reden, ist auch eine Public Cloud oder Private? Was macht eine Private Cloud für dich Private? Erstmal gar nicht technologisch, sondern eher organisatorisch und reglementiert. Eine Public Cloud, da ist die Datenhoheit, die Infrastrukturhoheit, die Prozessenhoheit, die Servicehoheit immer bei dem Unternehmen. Also das Unternehmen verantwortet auch diese unterschiedlichen Abstraktionsebenen. Bei einer Public Cloud wiederum teilt man sich gezielt aus der Hyperscaler Perspektive, aus der Provider Perspektive, versucht man natürlich eine ganz hohe Kundendichte auf die Hardware zu bekommen, um einfach effizient zu sein aus der Kundenperspektive. Und auch aus der Provider-Perspektive gibt es da eine Trennung zwar, aber bei einer Public Cloud teilt man sich die technologischen Ressourcen mit anderen. Aber man kriegt dann halt die Ressourcen, die man eingekauft hat, auch garantiert zur Verfügung gestellt. Falls nicht, gibt es auch dort Rollback-Szenarien oder Rebate-Szenarien, wo man sagt, okay, außerhalb einer Abrechnungszeit hat der Provider nicht das erfüllt, was er vertraglich zugesagt hat. Dann gibt es auch wieder Geld zurück. Aber in der Regel teilt man sich im Vergleich zu der Private Cloud die Systeme mit anderen Kunden, die man nicht sieht, die komplett isoliert sind. Aber nichtsdestotrotz ist es bei einer Private Cloud vom Betriebsmodell auch eine andere, weil man halt alles selber verantwortet. Das hat man früher bei Kunden, die etwas größer waren, die haben sich ihre eigene Cloud aufgebaut, ob mit Azure Stack oder mit HCM damals, hat man quasi sein eigenes Rechenzentrum oder Rechenzentren gebaut, die dann miteinander gespiegelt, damit man diesen Service nur für den Kunden und auch die, je nachdem was das für eine Unternehmensstruktur war, ob das ein Holding war oder Töchterfirmen, die dann halt konsolidiert wurden auf diese Plattform, aber nur von den Kunden betrieben und genutzt wurden. Das ist bei der Public Cloud dann ein Stück weit anders. Dann bleiben wir Public und bei den Hyperscalern. Wir hatten ja schon darüber gesprochen. Die Hyperscaler sind ja quasi die Platzhirschen, diejenigen, die eben maximal gut skalieren können, die diese Elastizität gut bereitstellen können. Ich glaube, in Deutschland kennen wir vor allen Dingen drei von denen und kennen in der Regel Azure von Microsoft bereitgestellt. Wir kennen Google mit der Google Cloud und GCP, die ganz viele Leute kennen. Und als Entwickler kennt man natürlich immer AWS, weil die einfach die Besten sind darüber, Leute direkt als Entwickler abzufangen, tolle Dokumentationen, dann hast du da nochmal ein S3-Bucket und so weiter. Und deswegen AWS ist, glaube ich, so die Einstiegsdroge, die die meisten Entwickler so für sich entdecken. Und darüber hinaus, ich glaube, das wissen viele in Deutschland nicht unbedingt, gibt es ja noch mehr Hyperscaler. Also da gibt es ja noch Alibaba, der groß mit rumgeht. Meta ist als großer Hyperscaler dabei. Da kann man sich zwar nicht so richtig problemlos einkaufen. Ich habe gelesen, OVH zählt auch inzwischen als Hyperscaler. Also von daher, die Player sind schon mehr, als man denkt, aber immer noch abzählbar. Also es sind nicht so wahnsinnig viele. Und wie würdest du sagen, welche Hyperscale eignet sich für wen am besten? Das ist so dein Favorit. Bist du AWS-Fan? Ich bin prinzipiell allen Cloud-Technologien ja offen, weil ich hier nicht voreingenommen bin, auch weil ich historisch ja auch von einem Hersteller komme, der auch einer der sind, die du gerade aufgezählt hast. Immer zu gucken, welchen Business-Case der Kunde hat und welche Erfahrungen und welchen Ist-Zustand er hat. Die meisten Kunden haben zum Beispiel auch bereits schon Cloud-Services, SaaS-Services im Einsatz in Form von Office 365 oder jetzt heißt es ja M365 im Einsatz. Und da liegt es natürlich auch nah, weil man sich schon damit auseinandergesetzt hat und ein bisschen Erfahrung gesammelt hat, dass man vielleicht damit beginnt. Oder je nachdem, wenn das ein Business Case ist, wo man mit Kubernetes arbeitet, wo wir dann in Richtung Kontinuierung gehen, macht es auch durchaus Sinn, über AWS und Google Cloud zu sprechen. Ich würde das abhängig machen, wo der Kunde steht. Und welche Anforderungen er hat und welche Erfahrungen er auch hat, weil am Ende des Tages muss es ja jemand bedienen können, damit die Fachbereiche auch dieses adäquat nutzen können. Deswegen würde ich jetzt nicht sagen, der eine ist besser als der andere, sondern die sind alle schon sehr skalierbar und ordentlich und in der Verfügbarkeit viel, viel höher als ein Rechenzentrum, was man selbst betreiben würde. Und das ist der feine Unterschied. Diese Skalierbarkeit, diese Rückgabe von Kapazitäten zurück, das kann man mit einem eigenen Rechenzentrum nicht. Und von einer Georendertanz, wie du gerade gesprochen hast, ein Zusammenschluss von unterschiedlichen Rechenzentren in der Region. Wenn man dasselbe aufbauen müsste, wäre man viel, viel teurer und ich würde auch behaupten, sehr, sehr schwierig für ein Unternehmen und auch gar nicht rechenbar, was ein Hyperscaler kann. Die sind schon so optimiert und automatisiert, dass die das für diesen Preis anbieten können. Als Kunde sehr schwer zu realisieren. Ich. Erinnere mich da gerade an den Anfang der 2000er, als wir mit VMware ESXi-Servern Dinge quasi virtualisiert haben. Und da konntest du auch sagen, diese Maschine hat jetzt bestimmte Ressourcen. Und du hattest gerade das As-a-Service-Konzept ja auch mit reingebracht. Und ich glaube, es ist spannend, da zu unterscheiden und zu sagen, was ist eigentlich As-a-Service? Also eine Maschine einfach nur zu nehmen, die woanders ist und die einfach unendlich groß ist, ist ja was anderes, als zu sagen, ich nehme jetzt einen hochwertigen Dienst wie einen Autor, Word oder Office, was online verfügbar ist oder ich nehme vielleicht irgendeinen speziellen Service wie einen S3 Bucket, da muss ich ja gar nichts tun. Also deswegen diese Unterscheidung zwischen einer Plattform als Service, einer Infrastruktur als Service oder vielleicht Software as a Service ist ja das, was so ein bisschen hineinspielt in die IT, wie du gerade sagst. Wie reif ist der Kunde eigentlich? Braucht er eigentlich nur unendlich dickes Blech? Also braucht er so eine Infrastruktur as a Service? Oder ist er schon so weit, dass er höherwertige Dienste einfach in Anspruch nehmen möchte und sagt, ich brauche eigentlich einen Identity Provider und dann holst du dir einen Active Directory vielleicht über die Azure Cloud? Absolut. Was auch noch hinzukommt, was ziemlich viel vernachlässigt wird, ist der Mensch. Gerade der digitale Wandel in die Cloud haben zu Recht auch ITler Angst um ihre Arbeit, weil sie sagen, okay, wenn wir keine Virtualisierung mehr selbst betreiben und ich die Virtualisierung einkaufe und eine viel, viel höhere Verfügbarkeit bekomme und nur noch auf Knopfdruck oder per Code solche Infrastrukturen aufbaue, Wofür braucht man mich denn noch? Und da entgegne ich immer wieder und sage, natürlich braucht man dich. Deine Arbeit ändert sich auch ein Stück weit. Also das heißt, du schreibst nicht nur Buchstaben in Zukunft, sondern auch noch Zahlen. Der Service, der muss ja weiterentwickelt werden. Der Code muss angepasst werden. Auch du wirst deine Arbeit verändern müssen, aber es steckt verdammt viel Potenzial in deinem Arbeitsplatz, wenn du dich auf das Thema Cloud einlässt. Weil das ist meiner Meinung nach, kann sich niemand mehr davor verschließen, weil einfach die Mehrwerte zu groß sind. Es ist natürlich nicht das Allerhaltsmittel. Aber wenn man das richtig macht, bringt das nahezu allen Unternehmen, in allen Branchen einen Mehrwert. Und da muss man die Menschen auch mitnehmen, abholen und die digitale Transformation angehen. Und da gibt es gewisse bewährte Methoden und Herangehensweisen, um... Aber am Ende des Tages eine erfolgreiche Cloud-Transformation beim Kunden zu haben. Das kommt jetzt wieder ein bisschen zurück auf das, was du vorher gesagt hast. Leute, die Monate oder jahrelang nichts gemacht haben. Ich hatte vor einer ganzen Weile mal Kontakt mit jemandem, der in der Baubranche tätig war. Und die wollten auch gerne in die Cloud gehen. Und deren Anforderungen, die haben aber gedacht wie in der Baubranche, wo sie gesagt haben, so ich habe 20, 40 Jahre Gewährleistung auf meinem Gebäude. Und jetzt wollten sie das gerne digitalisieren. Und haben gesagt, jetzt brauche ich eine Digitalisierungslösung, wo mir jemand zusichert, dass das in 20 Jahren auch noch so funktionieren wird. Wo man mit dem ganzen Cloud-Geschäft einfach sagen muss, niemand kann dir sagen, dass das in 20 Jahren so läuft. Gehst du in die Google-Cloud, bist du nicht mal sicher, dass morgen noch irgendein Service funktioniert da vorne, weil Google ja auch gerne mal alte Zöpfe abschneidet. Und das ist, glaube ich, ein Thema, wo man sich auch bewusst sein muss, das ist halt der Preis, den man so ein bisschen zahlt, wenn man da reingeht, speziell wenn du höherwertige Dienste nimmst. Also wenn du nicht sagst, ich lasse es einfach nur abstrahiert laufen. Baue meinen eigenen Identity-Provider, sondern wenn du sagst, du verlässt dich eben auf die Dienstleistungen, die du in der Cloud bekommst, sind alle irgendwie ähnlich zwischen den Hyperscalern, keine Frage, die machen so ähnliche Sachen, aber die verändern sich über die Zeit und du musst sie eben dann anpassen, dann wird irgendwas deprecated und es fällt weg und die Zyklen sind dann ein bisschen anders, als wenn du dein eigenes ERP auf der AS400 laufen lässt, da hast du selber das Heft in der Hand, kannst sagen, soll sich jetzt erst in zwei Jahren ändern und hier bist du so ein bisschen fremdbestimmt und ich glaube, deine IT muss auch darauf eingestellt sein, Dieses fremdbestimmte mitzugehen, so ein bisschen das Ohr am Zahn der Zeit zu haben, zu wissen, wann ändert sich denn eigentlich was? Wollen die was ändern in den Services? Gibt es neue Services, die mir helfen oder fallen die Services, die ich gerade benutze, weg? Und die ganzen nervigen E-Mails, ich weiß nicht, ob du auch hier bei Google Workspace bist, regelmäßig kriegt man irgendwelche E-Mails, die man nicht liest. Aber da steht ja immer drin, jetzt ändern wir was, irgendein Service fällt weg und würde das mein Unternehmen sein, wo meine private Google Workspace Adresse ist, dann sollte ich das aufmerksamer lesen, weil es kann sein, dass bestimmte geschäftskritische Dinge, einfach ersatzlos gestrichen werden oder migriert werden und ich muss da tatsächlich was machen. Ja, absolut. Man kann es auch immer wieder positiv sehen. Wer mich kennt, der versucht natürlich aus der Negativität das Positive rauszuziehen. Und das zwingt ein Stück weit den Kunden und auch die Mitarbeiter auch immer wieder nachzudenken, ob der Service, den ich dort betreibe, also nichts ist in den Stein gemeißelt. Gerade im Hinblick der Cloud ist der Evolutionszyklus viel, viel enger geworden. Das bedeutet, dass man sich viel früher mal Gedanken machen muss, wo entwickelt sich mein Service hin? Kann ich mein Service, den ich wie jetzt betreibe, ist der noch effizient genug oder kann ich den verbessern, dass der auch Mehrwerte schafft für die Bereiche oder für die Mitarbeiter? Darum geht es ja am Ende des Tages. Wir wollen Mehrwerte durch IT schaffen und nicht wie in Maurer, der mauert zehn Jahre lang immer die gleiche Mauer. Der muss sich keine Gedanken machen, ob er in der Elfenjahr die gleiche Mauer nochmal mauern soll, sondern er hat einfach die Erfahrung. Und da ist die Evolution natürlich sehr eingeschränkt. In der IT und in dem jetzigen Wandel von Unternehmen, die immer wieder sich in die Breite gehen, internationalisieren, sind die Anforderungen einfach immer kürzer geworden, darauf zu reagieren. Und das ist auch wie in der Baubranche, ein Kunde, der sagt, habe ich eine Planungssicherheit von 20 Jahren, das kann keiner geben. Die Frage einfach ist, möchtest du 20 Jahre lang Stillstand haben oder möchtest du mit der Zeit gehen, weil. Die Welt ändert sich ja auch tagtäglich. Willst du dieses Potenzial der Synergie und des Erkenntnisgewindes ausschalten, um nur eine Planungssicherheit zu haben? Die Frage würde ich dann gerne beantwortet bekommen. Und dann kriegt man meistens die gleiche Antwort, nein. Man möchte natürlich mit der Zeit gehen, weil sonst geht man mit der Zeit. Für dich selber kannst du natürlich sagen, bleibt 20 Jahre gleich. Aber ich gucke in meine Schublade, da sind drei iPhones. Eins hat so einen breiten, doofen Stecker, eins hat einen Lightning-Stecker und das dritte ist ein USB-C. Und das ist alles in weniger als 20 Jahren passiert. Klar kann ich versuchen, das alles in ein Auto einzubauen oder gar in ein Haus und zu sagen, das ist jetzt dein Anschluss, aber das wird ein Hase-und-Igel-Spiel sein, was du nicht gewinnen kannst am Ende. Vielleicht kann man den Kunden, mit dem du gesprochen hast aus der Baubranche, ein bisschen entgegenwirken und sagen, wenn du das mit einem Kubernetes-Cluster machst und als Mikroservice abbildest, dann wirst du, egal in welcher Cloud, flexibel sein mit deinem Service. Aber Stillstand, 20 Jahre lang nichts tun und auf der gleichen Evolutionsebene bleiben, das kann meiner Meinung nach kein Kunde. der will sich stetig weiterentwickeln, weil auch die Marktanforderungen sich ständig ändern. Und deswegen kann man sagen, lieber Kunde, das willst du doch auch nicht. Wir haben jetzt sehr viel über Cloud gesprochen. Bevor wir in den Transformation-Teil gehen, vielleicht noch eine Frage, auch aus meiner VMware ESXi-Zeit. Da gab es ganz viele Diskussionen immer über dieses CapEx versus OPEX. Da hat man gesagt, bevor wir uns jetzt ein Rechenzentrum bauen, das ist dann aus dem einen Pott, da müssen wir eben Kapital einsetzen. Lass uns doch einfach die OPEX nehmen, Also die operativen Kosten, weil dann zahlen wir nur die Miete im Monat und das ist alles viel besser. Spielt das heute noch eine Rolle bei Unternehmen, dass sie sagen, CapEx versus OpEx ist eine Entscheidungsgröße bei Cloud-Projekten? Selbstverständlich wird natürlich geguckt, was für ein Investitionsvolumen muss ich bereitstellen, um in der Cloud das abzubilden, was meine Anforderung ist und welche Betriebskosten sind dahinter. Das Schöne bei der Cloud ist, dass man, so empfehle ich das immer, mit einem kleinen oder mittleren großen Projekt anfängt. Und sich herantastet an das Thema. Und nicht, wie man in der Vergangenheit große Anzahl von Blech, um in dein Wording zu bleiben, investiert und dann feststellt, okay, strategisch passt das gar nicht mehr zu dem, was ich jetzt vorhabe. Gerade wenn man visionsgetrieben ist, auf dem Weg dahin kann sich sehr vieles wieder ändern, weil sich die Welt permanent weiter dreht und interessiert dann nicht, was du als Unternehmen für eine Vision hast. Die Marktanforderungen wechseln, die Gegebenheiten wechseln, Kriege kommen auf einmal zustande, die die Welt aus den Fugen bringen. Und wenn man dann halt solche großen planerischen Visionen hat, die man erreichen möchte, aber dabei die Berücksichtigung nicht hat, dass man das kleinteilig machen sollte. Ich sage immer, wenn du einen Elefanten durch die Tür bringen willst, dann musst du den in Scheiben schneiden. Dann hast du eine riesen Investition gemacht und das war eine Fehlinvestition und das entwirkt gegen den agilen Ansatz in der Cloud, wo man sagt, ich fange klein an, ich wachse menschlich, prozessual und technologisch an einem tatsächlichen Mehrwert, an einem Business Case und nicht an etwas Fiktives. Ja, Transformation hast du ja gerade sehr gut beschrieben, ist dehnbar, jeder versteht was anderes darunter. Aber was konkret bedeutet das für mein Unternehmen? Deswegen empfehle ich den Kunden immer zu sagen, nimmt ein Business Case in der Legacy-Welt, gerade wo ihr aktuell Probleme habt. Ich habe zum Beispiel einen Kunden, wo die Hardware zehn Jahre lang out of support ist und jetzt mal eben sagt, schnell, schnell muss ich in die Cloud. Du hast zehn Jahre lang geschlafen, warum jetzt auf einmal schnell, schnell? Ja, mit jedem zunehmenden Tag ist das Risiko höher. Da gebe ich dir recht. Aber schnell, schnell heißt auch sehr teuer in der Cloud, wenn man es nicht richtig macht. Und da gibt es ja unterschiedliche Ansätze Lift und Shift oder. Rebuilding oder Reengineering also man sollte sich wirklich an das Thema herantasten und das als Organisation weil die Arbeitsweise wird sich ändern, es muss sich auch ändern gerade agil, um schnellere Zyklen und Auslieferungsfähigkeit von Produkten oder Services zu sein, auf der anderen Seite aber auch auf Marktanforderungen schneller reagieren zu können, sonst verliert man Marktanteile in dem Bereich Untertitelung des ZDF für funk, 2017 Deswegen ist CapEx und OPEX ganz wichtig und meiner Meinung nach als Synergie kann man das in der Cloud sehr gut abbilden, als wenn man das konventionell macht. Gerade Risiko reduzieren ist, glaube ich, ein ganz wichtiger Punkt. Speziell, wenn du am Anfang stehst und noch nicht weißt, wo du hingehst. Da gibt es aber diese Berichte, hier war das 37 Signals, die haben ganz groß letztes Jahr angekündigt, die verlassen die Cloud, die brauchen das nicht, sie bauen ihr eigenes Rechenzentrum wieder auf. Kann man ja machen. Also wenn man rausfindet für sich, dass der Case besser funktioniert, weil man eh die ganzen Server haben muss und was immer dahinter steckt. Aber für jemanden, der eben einsteigt, der mal gucken möchte, ich glaube, es ist immer eine gute Sache, sich leiten zu lassen von, wo habe ich am wenigsten Risiko? Also wo ändert sich vielleicht meine Welt schnell? Also wo ich überlege, vielleicht mache ich es mit einem Partner oder ich baue es selber. Wenn ich dann nämlich das Blech erstmal angeschafft habe und dann doch mit dem Partner machen möchte, kommt dieses ganze Sunk-Cost-Fallacy-Thema. Also ich habe halt schon so viel investiert, da mache ich das jetzt auch noch weiter, auch wenn es eine doofe Idee ist. Und ich weiß nicht, ob genug Leute über dieses Risiko sehr stark nachdenken. Also zu gucken, was riskiere ich eigentlich? Wie kann ich kleine Schritte gehen und wie kann ich Erkenntnis gewinnen? Die Frage ist, wer muss eigentlich Erkenntnis gewinnen? Und damit sind wir ja quasi in diesem Transformationsthema drin. Also wer muss eigentlich Erkenntnis gewinnen? Wer will eigentlich in die Cloud? Wer treibt das Ganze? Und jetzt wird es, wie du gerade nett angesprochen hast, jetzt geht es mehr um den Menschen und die Organisationen ja auch, als um reine Technik. Aber ganz Technik können wir natürlich nicht ausblenden. Wollen wir auch nicht. Fangen wir mit so einem Startszenario aus. Also malen wir uns mal irgendwie eine Welt, wo irgendjemand... Vielleicht den mit dem zehn Jahre alten Hardwarehaufen oder mit was anderem. Wen wollen wir in die Cloud schicken? Einer, der akut Bedarf hat, einen Service so bereitzustellen, dass er seine Businesses-Anforderungen erfüllt. Und da habe ich immer so einen Leitsatz, Stabilität vor Einfachheit und Innovation. Am Ende des Tages muss IT in der Lage sein, das ist so stabil zu laufen, dass sie Geschäftsprozesse stattfinden lässt, erfüllt und weiterentwickelt mit den Menschen zusammen. Aber am Ende des Tages verdient man ja mit IT Geld oder soll man ja IT Geld verdienen. Ein Unternehmen ohne IT wird heutzutage meines Erachtens kein Geld mehr verdienen können. Die Zeit von Kreide und Bleistift ist auch vorbei. Also von daher, welcher Kunde ist es? Ich habe zum Beispiel aktuell einen Kunden gehabt, der seine kompletten Kassensysteme ausgetauscht hat. Diese Kassensysteme, die er vor Ort hatte in den jeweiligen Filialen, waren nicht managebar. Also man hat sie dann halt mit CDs zum Leben erweckt oder Updates per CD. Da ist ein Techniker rausgefahren und das weltweit und hat dann CDs eingespielt. Natürlich ein ganz, ganz interessanter, kostspieliges Akt. Der wird der Erfolg ja zum Fluch. Je mehr Kassen du hast, desto teurer wird der ganze Spaß. Genau. Und der Dienstleister, der dann die CDs in den Rechner einwerfen darf und Stunden abrechnen kann, der freut sich natürlich darüber. Umgestellt auf ein komplettes managebares Kassensystem, anderes Betriebssystem, andere Anwendungen teilweise drauf. Alte Anwendungen, die nicht sofort abgelöst werden können, müssen sichergestellt werden, dass sie weiterlaufen. Die Services wurden von dezentral auf zentral umgestellt, also eine riesengroße Transformation von einigen Jahren, wo der Kunde sich Meilensteine auferlegt hat, wo er gesagt hat, wann möchte ich mit welchem Land beginnen, wann soll etwas umgestellt werden und auch so Marktanforderungen wie, ich möchte ein neues Land erobern mit meinem Unternehmen. Nee, baue ich jetzt komplett neue Filialen auf unter meinem Namen oder kaufe ich einen Wettbewerb und platziere mich dadurch. Das ist auch wieder ein Rechenexempel, was geht schneller, Marktanteile in dem Land zu bekommen. Und dann entschließt sich der Kunde, ich kaufe einen anderen auf und in einer Woche muss die Filiale komplett aussehen, wie meine eigene Filiale weltweit standardisiert und auch die IT. Du musst es konsolidieren irgendwie. Du willst ja nicht das kaufen und dann nochmal zweigleisig, dreigleisig, fünfgleisig irgendwann fahren. Genau, weil das ist ja auch Verwaltungsakt. Und das war sehr, sehr spannend und auch... Am Ende ist es auch sehr erfolgreich, weil man Betriebsprozesse wesentlich beschleunigt hat, M&A-Szenarien sehr schnell abbilden konnte, weil die Technologie immer schnell war, weil sie modular war und man konnte dann halt innerhalb von einer Woche die komplette IT von dem alten übernommenen Unternehmen so umstellen, dass sie sofort integrierbar war in die neue Welt. Und dann brauchte man nur halt oben die Werbebeine wechseln und die Produkte müssen geliefert werden und dann konnte das Unternehmen schon die Filiale eröffnen. Was war dann konkret der Cloud-Bestandteil? Also wir hatten vorher die CD, die verstehe ich ja. Und das heißt, dann gab es in der Cloud eine Verwaltungssoftware dafür und da haben sich die einzelnen Kassen als Client quasi Software runtergezogen oder wie funktionierte das? Sowohl als auch. In der ersten Interaktionsstufe war es so, so dass die alten Systeme, die noch nicht cloudfähig waren, die Geräte musste man erst mal cloudfähig hinbekommen. Und davon musste man einmal vor Ort. Man hat das immer so kombiniert, weil die Filiale wurde eh umgebaut. Man hat immer die Filialen genommen, die nicht nur eine alte Kassensoftware haben, sondern halt auch eine komplette Modernisierung im Bereich Kühlschränke. Wo man eh musste, da kann man vielleicht ein bisschen mehr machen. Da ist ein IT-Team vor Ort gewesen. Die haben dann halt die Kassen erstmal auf die neue Version umgestellt und sobald die Umstellung war, konnten sie die dann halt auch zentral managen und auch alles dann halt auch zentral verwalten, halt neue Updates einspielen, auch später über die Cloud neu provisionieren oder halt auch die ERP-Zugriffe realisieren. Das heißt, die Abverkäufe, die landen ja dann irgendwo dann in dem ERP-System, was zentral bereitgestellt wurde. Sehr viele zentrale Dienste wurden dann in dem Zusammenhang auch automatisiert und halt auch standardisiert. Und in der ersten Phase waren es Rechenzentren. Und später ist man dann auch immer ein Stück mehr in die Cloud gegangen mit den Backend-Services, mit der ERP-Lösung, weil man sich dadurch viel mehr Verfügbarkeit und Skalierbarkeit versprochen hat. Und das wurde dann auch belegt, dass der Kunde im Verhältnis zu seiner alten Kassensoftware in der Lage war, dass die Kassen viel stabiler liefen, viel aktueller waren, weniger Betriebskosten hatten, weil der Techniker musste jetzt auf einmal nicht rauchen. Das ist alleine das Ersparnis von Reisekosten eines Technikers in einem Land. Das ist es immerhin. Da haben andere mittelständische Unternehmen diesen Umsatz, den Großkunden dort nur für den Betriebsaufwand aufwerfen müssen. Ja, das war eine absolute Erfolgsstory. Und ich habe letztens mir wieder eine Studie angeschaut, die sich genau mit meiner Erfahrung widerspiegelt. Dass der Cloud-Ansatz der Transformation im Großkundensegment viel höher ist als im Mittelstand. Im Mittelstand ist man noch sehr verhalten, man plant schon etwas, aber von der Umsetzung her circa 60 Prozent noch nicht in der Cloud. Liegt vermutlich auch daran, dass der Mittelstand schon etwas hat und dann dieser Sprung auf das Neue natürlich wieder mit dem Invest verbunden ist. Dass sie dann sagen, wir haben ja Dinge, die funktionieren und jetzt muss man diesen großen Sprung machen, dafür müssen wir viel bewegen. Bei den Großen, die sind es gewohnt, relativ viel zu bewegen. Und mir ist auch gerade in den Kopf gekommen, als du darüber gesprochen hast, dieses Bild von dem, was ich jetzt eigentlich arbeite, erinnert sich ja wirklich von dem verwaltenden Patch einspielenden kleinen ITler, der einfach darauf wartet, dass das System mal wackelt und dann dagegen tritt. Zu jemandem, der viel mehr Glue-Code schreiben muss, der dafür sorgen muss, dass die verschiedenen Komponenten miteinander sind. Vielleicht ist das hier ein bisschen SAP, da ein bisschen Eigenentwicklung. Machen, dass das alles irgendwie läuft. Daten durchreichen. Hier ein bisschen Databricks, da vielleicht Power BI, wenn wir im Azure uns bewegen. Dass man das alles anbindet und nicht so sehr am Laufen hält. Und dieses am Laufen halten shiftet aus meiner Sicht so ein bisschen in, lerne Dinge miteinander zu verbinden und Daten fließen zu lassen und da dann irgendwie Compliance und Governance drauf anzuwenden, die du in deinem Unternehmen eben machen musst. Wie soll das laufen? Wer soll Zugriff haben auf bestimmte Dinge? Aber du bist derjenige, der jetzt nicht mehr einfach nur mal ab und zu Schraubenschlüssel dagegen haut, sondern der sagt, okay, jetzt wie binden wir diese einzelnen Bestandteile an, dass die Kassensoftware an die Kasse ausgespielt werden kann, wenn die anfragt oder wie mache ich ein Interface, dass da jemand einen Button klicken kann, damit das passiert. Die Cloud hat viele Vorteile, wenn man es mit dem Use Case und all den Szenarien richtig macht. Es macht nicht nur den technologischen Wandel, sondern man hat die Chance und die hat man nicht häufig im Unternehmen, auch zu standardisieren. Ein Architekturportfolio aufzubauen. Ich habe Kunden, die haben 600 aufwärts Anwendungen und die muss man betreiben. Und wie viele von den Anwendungen brauchst du tatsächlich noch? Das ist alles historisch gewachsen. Wenn man die Kosten mal wirklich zu dem tatsächlichen Use Case und wie viel sie verwendet werden, mal monetär bewerten müsste, dann ist ein Unternehmen schon lange nicht mehr IT-technisch effizient, würde ich behaupten. In der Cloud hat man die Möglichkeit, diesen Sprung zu wagen, aber nicht den großen Sprung, sondern den kleinen Sprung. Erstmal wirklich mit einem Use Case anzufangen, nicht nur die Arbeitsweise, nicht die technologische Veränderung, auch die Organisation mitzunehmen und zu verproben und immer in einen höheren Reifegrad zu bekommen, dass man irgendwann sowas nur noch multiplizieren muss. Dass man sagt, okay, ich habe meine Change- und Demand-Prozesse definiert, ich habe ein Risk-Management, ich habe ein Demand-Management hinterlegt, ich habe einen ITSM-Prozess dahinter, um einfach, und das ist das, was das Wichtigste heute, meiner Meinung nach ist, Transparenz zu haben. Was habe ich und bin ich noch effizient in dem, was ich tue? Ja, oh Gott, da kommen ja die ganzen Enterprise-Architekten jetzt auch ins Spiel, die jetzt zu Cloud-Architekts werden und wo das Thema Transparenz ja seit Jahrzehnten eine große Rolle spielt und was wird hier eigentlich betrieben? Wer kriegt von wem Daten und wer gibt wem Daten? Und wenn ich dieses System ausmache, wie viel Umsatz verliere ich, weil irgendwas kaputt geht? Und dann halt zu sagen, welche Komponenten, sowohl menschlicher Art, aber welche Komponenten auch technologischer Art, stellen überhaupt diesen Service bereit. Also in den seltensten Fällen sehe ich wirklich eine Durchgängigkeit, das wird natürlich immer besser. Jetzt gerade sagtest du ja auch Enterprise-Architekten und ERM-Tools, die dann halt für diesen Service-Dokumentationsschritt erforderlich sind, umzusehen. Welche Komponenten spielen bei dem Service eine Rolle? Wie Verfügbarkeit ist so ein Service? Was geschieht, wenn ich da eine Komponente wegnehme oder verändere? Man hat sehr viele kleine Dokumentationen, aber dieses Big Picture hat man nicht. Und wenn man das Big Picture nicht hat, kann man auch keine vernünftige, nachhaltige Vision entwickeln. Deswegen ist es wichtig, Dokumentation ist bekanntlich alles. Haben die meisten Leute relativ wenig Motivation oder nicht das Geld dafür. Und dann, wenn ein Service oder ein Ausfall existiert, wo sind denn die Notfallpläne? Die sind schon längst veraltet oder nie richtig durchgeführt worden. Dann wundert man sich, dass der Service dann nicht so schnell wiederhergestellt werden kann. Ob es jetzt ein Hackerangriff ist oder ein menschliches Versagen oder maschinelles Versagen, spielt keine Rolle. Am Ende des Tages dauert der Wiederherstellungsprozess viel, viel länger. Ja. Das Wiederhochfahren, exakt. Und Transparenz gefällt mir auch. Wenn ich eine Sache dokumentieren würde, wären das für mich immer Architecture Design Records oder Decision Records, wo man sagt, warum haben wir das eigentlich getan? Ich habe am Anfang meiner Karriere mal für einen großen Telekommunikationsanbieter gearbeitet und wenn wir da gefragt haben, warum etwas so ist, gab es immer den Dreiklang. Historisch gewachsen, politisch gewollt, konzernbedingt. Immer sind es die anderen Schulden, ja? Ja. Irgendwie, man weiß es nicht so genau. Und es hat nie eine fachliche Begründung gehabt. Also historisch gewachsen ist nicht fachlich, politisch gewollt definitiv nicht fachlich, konzernbedingt vielleicht so ein bisschen Governance-1-Thema. Aber ultimativ, wenn man weiß, warum Dinge entschieden werden, kann man sich da auch viel besser dranhängen und gerade zwischen Teams wird das ja nicht transportiert. Warum haben wir das jetzt so gemacht? Ich glaube, das ist auch einer der Gründe, warum man sich eher für Microservices entschieden hat. Da muss man den anderen nichts mehr erzählen. Zumindest war das die Hoffnung, ob das so stimmt, muss man auch mal in irgendeiner Folge eruieren, aber genau das ist so der Teil man muss wissen, was man da tut und da muss man gucken, wenn etwas Altes da ist und man braucht es nicht mehr, es hat keinen Wert mehr man muss es wegmachen. Ja, man muss es gucken, ob es noch einen Mehrwert für das Unternehmen darstellt, also nur weil etwas zeitlich da ist heißt es nicht, dass es zeitlich weiter noch da sein muss. Es kann ja durchaus sein dass es dass es da viele andere technologische, prozessuale Möglichkeiten gibt, viel effizienter unterwegs zu sein und viel stabiler vor allem. Die meisten schimpfen ja über die IT-Gesellschaft, Manchmal auch nicht unzurecht, weil die Services einfach nicht so sind, wie sie sein müssen, dass sie eine durchgängige Transparenz haben, um zu gucken, laufe ich mit meinem Service noch zeitgemäß oder nicht oder bedarf es dort einer Veränderung oder laufe ich auf irgendwelche Lasten oder auf Probleme zu. Dafür brauche ich Transparenz, um solche Entscheidungen zu treffen. Am Ende des Tages müssen wir erst stabile Systeme haben und dann können wir uns um Innovation kümmern. Aber viele Unternehmen sind damit beschäftigt, das Wasser aus dem Boot zu bekommen, anstatt zu paddeln. Und somit funktioniert der Fortschritt nicht. Und meistens kommen externe Berater, die dann halt jemanden beraten und sagen, was alles nicht funktioniert. Viel wichtiger ist zu sagen, wie es funktioniert und wie man sowas schnell abstellen kann. Und Zuständigkeit. Ich glaube, das ist ein wesentlicher Faktor. Also in so einem klassischen mittelständischen Unternehmen, wo du eben alles Blech gekauft hast, da ist die IT für alles zuständig, was mit Computern zu tun hat. Sei es, der Drucker druckt nicht bis hin zu das ERP muss irgendwie umkonfiguriert werden. Das macht alles die IT. Ist hoffnungslos überlastet. Aber jetzt gehst du in das große Unternehmen, jetzt gehst du in so ein Cloud-Thema rein und da gibt es verschiedenste Services, die irgendwer gelauncht hat, vielleicht auch irgendwie auf eine andere Kostenstelle. Und dann ist die Frage natürlich über Zeit, wenn man fragt, kann ich das abstellen oder muss das noch laufen? Wer ist eigentlich der richtige Mensch? Weil immer zu sagen, wir als Unternehmen oder die IT, das gibt es ja gar nicht so sehr. Es ist ja immer irgendein Mensch, der dahinter hängt. Vielleicht ist es jemand, der die Abteilung verlassen hat und weggelobt wurde. Vielleicht ist es jemand, der immer noch da ist, aber der vergessen hat, dass er das jemals ins Leben gerufen hat. Und da ist die Frage, wie kriegt man eigentlich diese Ownership in das Unternehmen, dass jeder für seinen Teil quasi auch regelmäßig mal überprüft, möchte ich das noch haben, hat es seine Lebenszeit überdauert und jetzt ist es fertig, es hat seinen Zweck erfüllt, weil wir mussten nur ein paar Mergers und Acquisitions-Themen damit adressieren. Die sind jetzt reingeholt, wir lassen das jetzt nicht einfach rumlaufen, sondern wir schalten es ab. Also Abschaltthemen und ich glaube, die Leute, die ich so sehe in diesen IT-Kontexten, sind immer super Sachen anzufangen, also Greenfield-Projekte sehen wir alle, wir wollen gerne was Neues machen, aber dann über den Lifecycle nachzudenken und zu sagen, und wie beerdigen wir das Projekt, was sind denn die Todeskriterien, sag ich mal, wann wollen wir das Projekt zu Ende bringen, wann ist die Cloud-Transformation abgeschlossen, klar man kann argumentieren, es gibt immer Change, man muss immer wieder was machen, aber die Einzelbausteine davon, ich glaube die Einzelbausteine brauchen ein definiertes Lebensende. Und da muss man sagen, herzlichen Dank, dass du so lange gelebt hast. Du hast mir einen Zweck erfüllt. Dein Zweck ist erreicht. Jetzt kannst du abgelöst werden durch irgendetwas anderes. Bei der Cloud-Transformation ist das Einfachste meiner Meinung nach die Technologie. Die Physik ist vorgegeben, sie ist nicht überlistbar, aber der Mensch und die Organisation viel mehr. Und demzufolge sind ja auch mittlerweile in großen Strukturen, gibt es sogenannte Product Owner. Es gibt ja einmal den fachlichen Verantwortlichen und einmal den technologischen Verantwortlichen. In der Idealwelt, wenn man in Richtung Bis-DevOps geht, ist ein Team sowohl technologisch verantwortlich für einen Liefergegenstand und aber auch fachlich verantwortlich. Davon sind wir ja noch in Deutschland sehr weit von entfernt. Hast du das schon mal erfolgreich gesehen? Nicht in Deutschland. Und mit vor allen Dingen am Anfang sehr viel Aufwand und Mindset-Change, den es fordert. Weil die Leute, wenn jemand versucht, in meiner eigenen Suppe rumzurühren, dann ähm. Dann haben die Leute ein Problem damit und sagen, pass auf, wenn du damit rumrührst, dann kann ich die Gewährleistung, nicht dieses physische Services weiter übernehmen, was ja eigentlich völlig gerechtfertigt ist. Aber diese Offenheit zu sagen, hey, ich stelle dir als IT eine Plattform bereit, auch die Komponenten, die du bei mir gebucht hast, du kannst sie sogar zubuchen, total automatisiert am besten ist es, umso weniger die IT mit der Belegschaft in technologischen Fragen eine Verbindung hat, umso besser. Weil dann sieht man den Automationsgrad eigentlich ganz stark, dass Fachbereiche sich standardisierte, zertifizierte, lizenzierte Komponenten sich buchen können, über etwaige Prozesse, Self-Service-Portale etc. Und dann loslegen können. Da müssen sie relativ wenig mit der IT umgehen. Aber dieser menschliche Wandel, dieser organisatorische Wandel, wer verantwortet was? Wer ist für die Evolutionsentwicklung zuständig? Wann endet eine Evolution? Da macht man sich meistens keine Gedanken. Und dann, wenn die Mitarbeiter auch nicht vernünftig diese Services übergeben bekommen, weil sie das Unternehmen verlassen, dann passiert mir genau sowas. Es wird irgendwas angeschafft. Warum, weiß man immer noch nicht. Dann darf derjenige, der das ehrenamtlich übernommen hat, auch nochmal etwa irgendwelche Dokumente durchforsten, Mails durchforsten, um eine Analyse zu machen, warum sich damals jemand dafür entschieden hat. Und das ist meiner Meinung nach die Hauptaufgabe eines CIOs oder eines C-Levels, dafür zu sorgen, dass man ganz klare Verantwortlichkeiten haben, sowohl technisch und auch fachlicher Art. Die Fachlichkeit sollte immer in der Fachabteilung liegen, aber die Technologie bis zur Bordscheinkante, sage ich immer, der IT oder... Der entsprechenden Abteilung, die dafür zuständig ist technologisch und dann muss ein Sparing stattfinden. Also wenn der Fachbereich meint, eine Evolution seines Services voranzutreiben und es setzt eine technologische Veränderung voraus, dann muss es über bestimmte zentrale Prozesse gehen, dass es A klar ist, warum diese Veränderung, ist es ein Change, ist es ein Demand stattfindet und immer diese Durchgängigkeit und diese Transparenz sicherzustellen, Wer verantwortet was bis wohin? Und wenn wir was verändern, warum? Und wofür? Das ist ja der super spannende organisatorisch-technische Conways-Law-Bereich, in dem man sich dann da bewegt. Und da gibt es immer diese Sehnsucht nach einem Messias, der alles macht. Also ich möchte gerne jemanden haben, der einfach sowohl die Technik als auch die Fachlichkeit versteht und der die Verantwortung für alles übernimmt, der soll es mal tun. Und ich finde so eine gesunde Arbeitsteilung ist a sehr wichtig und b so herausfordernd, wo du die Grenze ziehst und dass du kein Silo wirst. Weil eigentlich finden wir Arbeitsteilung ganz gut, weil dann kann ich einen Fokus auf ein bestimmtes Thema machen. Aber ich möchte halt nicht, dass ich diese Mentalität habe mit, ich stelle es dir nur an die Straße und du musst dann selber den Kühlschrank irgendwie reintragen. Sondern ich möchte schon, dass die beide irgendwie dasselbe machen. Und es ist mehr wie ein Tanz, als dass es so wie zwei Silos sind. Sondern die beiden Tanzpartner, der eine macht halt die Herren und der andere macht die Damen Schritte. So ist es besser, als wenn man sagt, beide können irgendwie alles und warum sollen denn mehrere da zusammenkommen? Das interessiert auch den Konsumenten dieses Services am Ende des Tages ja nicht. Der möchte diesen Service in einer bestimmten Qualität und Schnelligkeit nutzen. Nehmen wir mal das klassische Beispiel, was sich vorangeführt hat im Lebensmittelhandel, die Kassiererin. Die will, dass der Kassiervorgang sehr schnell stattfindet. Nicht nur sie, sondern der Kunde auch. Ob jetzt dahinter zwei Service- oder Product-Owner existieren, der eine technologische und der andere, das interessiert die Kassiererin nicht. Also am Ende des Tages muss der Service in der definierten und, In ausgelieferter Form, die man auch garantiert hat und auch publiziert hat. Und wenn der verfügbar ist weitestgehend und wenn man das einhält, dann kriegt man auch Vertrauen. Und wenn man Vertrauen hat, sowohl nicht nur bei den Konsumenten, sondern halt auch bei den Servicegestaltern, bei den Product Ownern, dann braucht man sich um Motivation gar nicht kümmern, weil das ist eine Wertschätzung genug. Und damit kriegt man auch die besten Resultate hin, dass Services ständig sich weiterentwickelt werden, wenn gewisse Verantwortlichkeiten und Transparenzen sichergestellt sind. Der Können und Wollen fällt mir dabei ein. Also das sind halt diese beiden Seiten der Medaille. Du musst irgendwas wollen, das heißt die Anforderung muss da sein. Ich will schnell abrechnen können und dann aber erst gepaart mit dem Können macht es Sinn. Also es bringt nichts, wenn der Product Owner sagt, wir wollen jetzt ganz schnell abrechnen können, aber du kannst es nicht, weil dein System es nicht hergeben. Es bringt aber auch nichts, dass du es ganz schnell hergeben kannst, aber das wollte keiner, sondern man möchte vielleicht so einen Slow-Consuming-Laden haben, wo man sagt, okay, der Kunde steht im Mittelpunkt, wir machen es langsam, wir wollen gar nicht, dass der Prozess schnell ist. Deswegen können und wollen muss man übereinander schieben, glaube ich und das merkst du von außen dann. Kann mein Gegenüber die Leistung erbringen, die er erbringen möchte, ist er in der Lage und er bringt dir die richtige Leistung. Effizienz, Effektivität, können, wollen, wie immer man dieses Pärchen nennen möchte. Ja. Der limitierte Faktor wird meistens immer der Mensch sein. Technologisch ist vieles möglich. Wie wir alle wissen, in der Informatik geschieht die Kommunikation zwischen den Systemen nahezu Lichtgeschwindigkeit. Aber Kommunikation ist ein ganz wichtiges Thema. Wozu auch die Leute mitnehmen, wenn der Konsument da Wünsche hat, Feedbacks hat, etwas zu verbessern. Dann sollte natürlich die IT und der Product Owner natürlich affin dafür sein, das nachzugehen und zu gucken, wie er den Service verbessern kann. Und wenn es nicht verbesserbar ist aktuell oder wo der Kosten-Nutzen einfach nicht aus der unternehmerischen Sicht ist, das hat ja der Konsument oder die Kassiererin in dem Sinne nicht. Die sieht ja das große Bild nicht, was das Unternehmen an einem Kostenapparat herbeirufen müsste, wenn diese Veränderung von dem Kassierer erfüllt werden soll. Dieses große Ganze, aber es steht und fällt mit Adaption and Change Management, also eine gute Kommunikation, sind auch Leute gerne gewillt zu sagen, okay, ich habe verstanden, momentan ist es monetär oder nicht lösbar. Ich weiß, ihr könntet das technisch lösen, aber ihr könnt es momentan nicht lösen, weil wir das im Gesamtkontext sehen müssen. Vielen Dank dafür, dass ihr so offen und transparent mit mir kommuniziert habt. Das bringt auch verdammt viel. Schauen wir uns mal diesen Prozess des Mitnehmens der Leute an. Was sind so die Top-Argumente, die du hörst, die gegen Cloud-Transformation sprechen? Oder die Ängste, die Leute mitbringen? Was ist das, warum Menschen mitnehmen, sozusagen noch so einen kleinen Widerstand haben gegen Cloud-Transformation-Projekte. Die Frage ist, welche Zielgruppe du meinst. Es gibt ja unterschiedliche Zielgruppen, die haben unterschiedliche Ängste. Eine Angst an der Zielgruppe hatte ich ja gerade mal herangeführt, das ist der Virtualisierungsingenieur, wo seine virtuellen Maschinen von dem lokalen Blech in einen virtuellen Blech hineinwandern und er diese Art von Tätigkeit in der Form nicht mehr machen muss. Er muss sich mit ganz anderen Sachen auseinandersetzen, wie er muss sich jetzt zum Beispiel keine Gedanken machen, um I.O. Oder RAM zu monitoren oder ist der Speicherplatz noch da? Sein Wissen fällt weg. Sein Wissen, was er sich über Jahre angeeignet hat und da weiß er ganz genau, wie die Dinge miteinander funktionieren, wo er mit seinem Schraubenschlüssel gegenhauen muss. Das Wissen muss er jetzt erneuern über Wissen, wo muss ich eigentlich bei einem Azure, bei einem AWS dagegen treten. Genau. Meine Arbeit ändert sich ein Stück weit. Aber wenn etwas wegfällt, habe ich aber Zeit für was anderes. Also ich gehe ja dann, meine Tätigkeit ändert sich und nicht weniger unspannend. Dann reden wir von, dass ich auf Knopfdruck in der Lage bin, komplette Farmen oder Services aufzubauen in Form von Terraform-Code zum Beispiel. Aber für mich persönlich bedeutet das ja erstmal, ich muss raus und wenn ich keine Lust auf Veränderung habe, wäre ja das drüberliegende Thema sozusagen, eigentlich will ich mich gar nicht verändern, läuft doch alles gut. Ja. Das ist ein spannendes Beispiel. Ich hatte mal vorletztes Jahr ein Summit als Speaker sprechen dürfen vor 5000 Leuten, wo ich dann die Frage gestellt habe, wer ist alles für Veränderung? Und ich würde sagen 90, 95 Prozent haben die Hände gehoben. Und wo ich gesagt habe, wer will sich dabei auch verändern, sich verändern? Das waren weniger Hände. Also alle schreien irgendwie nach Veränderung, aber nur dann, wenn es für einen nicht selbst gut läuft. Wenn es für einen selbst gut läuft, ist die Veränderungsbereitschaft gleich gering. Es ist ein Risiko da, mich zu verändern. Läuft doch gerade gut, es kann doch schlechter werden sogar. Genau, und woher hat er die Erkenntnis? Das heißt, man muss es ja immer als Unternehmenskontext, und das ist das, was ich immer gerne sage, ihr müsst als Unternehmen erfolgreich sein. Nein. Und jedes Zahnrad muss ineinander greifen. Und jedes Zahnrad, was nicht performant genug ist, der muss bewertet werden, angepasst werden, damit es wieder wie ein Uhrwerk funktioniert. Und dafür sind meiner Meinung nach die Führungskräfte zuständig, die das große Ganze immer im Blick haben müssen. Und erreiche ich noch mit meinem Vorgehen, mit der Mission, die Vision zu erreichen. Ansonsten hat man kleine Silos, die man heute schon hat. und dann wird es sehr schwer, diese Silos aufzubrechen, nicht nur menschlich, sondern auch technologisch, weil man dann halt lauter kleine Insellösungen hat und Schatten-ITs aufgebaut hat und war doch eh da und immer funktioniert. Und dann ist der Change-Prozess extrem schwer und der Transformationsprojekt auch. Können wir überlegen, was so die low-hanging fruits, wie man so schön sagt, oder die quick wins sind, die man erreichen kann, wenn man jetzt anfängt mit einer Cloud-Transformation. Ich weiß, wir müssen ja immer abschichten zwischen, was ist ein großes Unternehmen, was ist ein kleines Unternehmen. Bei den Kleinen ist es sicherlich, du musst dir gar kein Blech anschaffen. Du kannst also ohne Mitarbeiter, ohne IT-Abteilung, kannst du schon loslegen. Für die Kleinen sozusagen, also ganz easy. Aber bleiben wir bei den Mittleren, bleiben wir vielleicht bei den Großen. Was sind so typische Quick Wins? Was könnte man erreichen? Wenn man eine Cloud-Transformation anstößt? Der erste Faktor ist, man muss sich um Sachen nicht mehr Gedanken machen, die man vorher machen musste. Wie zum Beispiel, läuft meine Hardware aus dem Support? Ah ja. Ja, klasses Beispiel. Wie schaut es aus mit der Lizenzierung? Steht irgendwann mal ein Wirtschaftsprüfer vor die Tür und sagt, pass auf, du bist absolut unterlizenziert und brummt dann eine große Strafe auch. Auch das habe ich gesehen. Und das kann auch sehr unangenehm werden. Schnelligkeit in der Bereitstellung Wenn ich eine Hardware als, egal ob jetzt Mittelstand oder Enterprise-Kunde unterwegs bin und ich muss eine Hardware dafür anschaffen, dann geht ja alleine schon monatelang, gerade in der aktuellen Zeit, monatelang ins Land, bis die Hardware überhaupt erstmal da ist. Ich fange mit der Ausschreibung an und dann gucken wir mal. Nein. Und das kann ich in der Cloud sehr simplifizieren, weil ich kann ziemlich schnell den Use Case technologisch vorantreiben. Ich muss mir keine Gedanken machen über das Lizenzmodell, über die Verfügbarkeit kann ich mit einem Häkchen sagen, wie verfügbar etwas sein soll und kann mich auf das Kerngeschäft fokussieren. Aber dabei aber auch immer klein anfangen, diesen Wandel. Und der Wandel ist nun mal so nicht nur technologisch, sondern halt auch menschlich und prozessual. Weil wenn ich immer das gleiche tue, was ich bereits schon tagtäglich mache, dann wird es sehr schwer, ein anderes Ergebnis zu erwarten. Das ist ein Albert Einstein Mal in der Form. Deswegen die Low-Hanging-Fruits sind darin begründet, dass ich viel schneller die Anforderungen, die ich auferlegt bekomme, und die können ja nicht täglich, aber wirklich nicht sich ändern. Wenn ich zum Beispiel gerade einen Geschäftsführer habe, der ein anderes Unternehmen gekauft hat, und sagt, pass auf, jetzt macht man hier ein Assessment von der IT und ihr müsst in der Lage sein, innerhalb von einem halben Jahr die komplette IT in unsere Standard-ID zu überführen. Und dabei müsst ihr auch die Mitarbeiter mitnehmen, die wir hinzugekauft haben. Eine spannende Sache. Auf jeden Fall. Parallel sollst du auch noch als IT den Betrieb aufrechterhalten. Auf der anderen Seite sollst du Projektmanagement und Innovation vorantreiben und nebenbei noch andere Unternehmenskäufe in das Unternehmen zu integrieren. Sehr spannend. Und das wird, wenn man das klassisch macht, eh nicht funktionieren, weil einfach sehr viel Vorlaufzeit erforderlich ist. Ist bei den anderen teilweise auch. Aber wenn es um technische Bereitstellung von etwas geht, ist es in der Cloud wesentlich schneller. Wesentlich schneller. Das ist alles sehr technisch gewesen. Für die fachlichen Leute ändert sich ja auch eine ganze Menge durch diese Geschwindigkeit alleine. Also sie merken es nicht direkt, weil sie nicht selber diese Technik bestellen müssen. Doch, wenn sie nicht mehr monatelang auf eine Anfrage warten müssen, bis sie abgebildet ist, sondern nur noch Wochen oder Tage. Genau, das bedeutet ja auch, du musst auch in den nicht technischen Bereichen musst du anders jetzt darüber nachdenken. Du kannst nicht mehr sagen, ich order das jetzt mal und dann denke ich mir mein Projekt aus. Du musst es schon machen und der große Vorteil ist aus meiner Sicht, in der Regel musst du ja, oder so wie ich es gerade gesagt habe, kann es ja niemals sein, du denkst dir ja immer schon aus, was du genau machen möchtest und dann startest du deine Initiative. Und wenn dann aber viel Zeit vergeht, bis zu dem, wo du zum ersten Mal Marktkontakt hast oder Kundenkontakt, ist das Risiko ja deutlich größer geworden, weil die Welt sich bewegt und du hast dann auf einmal zwei sich bewegende Dinge, nämlich einmal eine Lösung, die ich bauen möchte und der Markt, der sich weiterentwickelt und es kann sein im schlimmsten Fall, dass das, was du dir im Frühjahr 2024 überlegst, eine gute Idee ist, aber die Umsetzung, die erst im Frühjahr 2025 kommt, völlig an den Bedürfnissen vorbeigeht, weil die Welt sich gedreht hat, weil der Wettbewerb nochmal fünf andere aufgekauft hat und deswegen jetzt auf einmal andere Dinge eine Rolle spielen und da merkst du es ja schon also ich glaube, du kannst deutlich weniger Frust haben in der Cloud Transformation, wenn du quasi den Maschinenraum so weit optimiert hast dass du dann an der Fachstelle eben wirklich flott am Ohr der Zeit bleiben kannst dass du ganz individuell reagieren kannst und schnellere Zyklen einfach, also diese schnelleren Zyklen was wir aus dem ganzen Scrum und agilen Umfeld. Ja, käme mit, oh, es geht alles schneller. Sehr gut, das hätte ich jetzt auch gesagt. Das ist ja gar nicht der Punkt. Es geht ja nicht darum, schneller zu entwickeln. Es geht ja darum, schneller zu lernen. Und einer der Punkte, die mich am meisten aus Silicon Valley ärgern, ist immer dieses Fail Fast. Niemand möchte failen. Das will keiner. Und es geht eigentlich ja darum, schnell zu lernen. Es geht darum, ganz schnell zu lernen. Ist meine Idee die richtige? Soll ich sie weitermachen? Und wenn ich irgendwie falsch unterwegs bin, möchte ich schnell rausfinden, dass ich falsch unterwegs bin. Also das ist das Fail Fast. Da gebe ich dir sogar auch eine Studie an die Hand, die sehr interessant ist. Menschen Menschen sind erst geneigt, die Entscheidung zu wählen, die die geringstes Risiko oder eine Fehlervermeidung hat. Bevor sie für die denken, ich entscheide mich für die Option, die am meisten Profit hat oder einen Mehrwert darstellt oder was Positives ist. Genau das Gegenteil ist der Fall. Ich habe etliche Studien gesehen und die haben alle das Gleiche gesagt. Der Mensch entscheidet sich erstmal auf die Option, die am wenigsten scheitert oder das geringste Risiko hat. Ja. Ich glaube, da gibt es so ein ganz klassisches psychologisches Experiment auch. Die schenken dir irgendwie 10 Dollar und dann musst du wetten. Also dann gibt es halt so ein Rad, was man dreht oder so und dann, Die sind sehr risikoavers, die Leute, die diese 10 Dollar geschenkt bekommen haben. Also sie können das verdoppeln, aber sie sind konservativ, sie behalten diese 10 geschenkten Dollar, obwohl sie nichts dafür gemacht haben. Also sie könnten einfach richtig viel kriegen, wäre eine Möglichkeit. Der Mensch tickt nicht so, der Mensch möchte nicht Profit optimieren, der Mensch möchte Verlust minimieren. Genau, genau. Das widerspielt auch die Studie und auch meine Erfahrung wieder, da, wo die Leute halt erstmal noch sehr konservative und zurückhaltende Entscheidungen treffen. Wo man sagt, du hättest das schon vorher viel, viel mehr haben können. Nein, wir müssen erstmal so, wir müssen ja auch die Menschen mitnehmen, die sind noch nicht so weit. Da muss man halt solche Interaktionsstufen aufbauen. Ähnlich wie vielleicht bei Enterprise Architekturen, finde ich, hast du immer so ein paar zugrunde liegende Konzepte, die du umsetzen möchtest. Also sei es Robustheit, Skalierbarkeit oder Sicherheit, kannst du dann in der Architektur machen. Und ich Ich finde auf einer organisatorischen Ebene ist es eben auch zu sagen, ist Vorhersehbarkeit oder Vorhersagbarkeit meiner Organisation wichtig oder ist Transparenz mir wichtig oder ist viel Umsatz mir wichtig und auf diese Dinge optimierst du dann. Und wenn du sagst, du bist ein großes Unternehmen, wird natürlich Vorhersagbarkeit immer wichtiger, weil 20.000 Leute arbeiten da und wenn die alle in verschiedene Richtungen rennen, wird es auf einmal crazy. Deswegen ist der Wert von ganz viel Umsatz vielleicht so ein bisschen vom Slider her so ein bisschen in Richtung, sei mal ein bisschen vorhersagbar, verlässlich, stabil, damit auch meine Gesellschafter, damit meine Aktionäre, damit die wissen, worauf sie sich einlassen, weil zu viel Unsicherheit in zu großen Dingen könnte sehr viel Verlust bedeuten. Absolut. Ein gutes Beispiel ist ja die Reaktion oder die Vision, die Mark Zuckerberg gemacht hat mit der Investition von 9 Milliarden in H100 Chips. Also davon leitet man ab, aha, für die Firma Meta ist künstliche Intelligenz ein ganz, ganz wichtiger Faktor geworden und sie wollen ja auch teilweise das als Open Source bereitstellen, diese KI-Modelle. Und das Ziel ist es, vom Meta unter anderem zu sagen, ich möchte eine KI entwickeln, die intellektuell dem Menschen nicht nur ebenbürtig ist, sondern noch mehr. Ja. Und das ist ja die Vision dahinter. Und ich denke mal schon, dass der Mark Zuckerberg oder ein Team hat, die natürlich vorher, bevor sie das der Welt mitgeteilt haben, intern schon mal kommuniziert haben, was sie da vorhaben. Und deswegen ist es wichtig, Kommunikation, und das ist die Hauptaufgabe der Geschäftsführung, die C-Levels, je nachdem in welcher Organisation ich bin, oder Führungskräfte, klar zu kommunizieren. Das klare Kommunizieren ist vielleicht ein guter Punkt für, wenn du jetzt eine Cloud-Transformation begleitest. Worauf achtest du, um festzustellen, läuft es gut oder läuft es nicht so gut? Was sind so die Merkmale, an denen du festmachen würdest, ich muss hier nachsteuern oder ich kann mich entspannt zurücklehnen, diese Cloud-Transformation läuft gut. Gibt es so Dinge, wo du das festmachen kannst? Ja, Agilität ist ein ganz wichtiger Faktor eigentlich meiner Meinung nach bei der Cloud-Transformation, weil sie einfach sehr viel beherrschbarer macht. Auf der anderen Seite fordert das Unternehmen, weil auf einmal die Organisation selbstbestimmender wird. Aber durch die Interaktionsstufen, du hast ja gerade ein sehr schönes Beispiel genannt, ich entwickle eine Software in 2024 und dann will ich 2025 online gehen mit dem Produkt am Markt und stelle fest, dass die Rahmenbedingungen sich komplett verändert haben und ich 80% des Source-Codes wegwerfen muss. Das ist bei der Agilität genau anders. Gerade komme ich meistens eigentlich, wenn die Cloud-Transformation nicht oder suboptimal läuft, werde ich dann meistens gerufen. Wenn die es alle schon selber gemerkt Genau. Und dann sagen wir, jetzt holen wir doch mal einen, der das schon ein paar Mal gemacht hat oder weiß, worauf es ankommt. Aber woher wissen deine Kunden, dass ihre Cloud-Transformation nicht so gut gelaufen ist? Woran machen sie das dann fest? Entweder der Kostenfaktor sehr hoch. Die haben dann etwas provisioniert, was nicht dem widerspiegelt, was sie als Budget da geplant haben. Dass auf einmal jetzt ein SQL-Server 64.000 Euro im Monat kostet, hätten die auch nicht gedacht, weil sie versucht haben zu konsolidieren. Und versuchen aus zehn ERPs ein ERP-System zu machen. Aber diese zehn ERPs im Gesamten haben keine Kosten von 64.000 Euro pro Komponente verursacht und stellen dann halt fest, dass die Kosten immens in die Höhe gehen, weil man halt einfach nicht alle Faktoren mit berücksichtigt hat. Und wie man so ein, das Schlimmste, was passieren kann, oder ein gängiger Fehler, sagen wir es mal so, was viele Kunden machen, versuchen, ihr eigenes Rechenzimmer in der Cloud 1 zu 1 abzubilden. Also einfach nur den fremden Computer zu nehmen. Lift und Shift zu machen und dann zu hoffen, dass alles in der Cloud billiger wird. Die Cloud ist alles andere als billig. Wenn man es nicht richtig macht, ist es sogar sehr teuer. Wenn man es aber richtig macht, kann sie billig sein und Effizienz zugleich und Skalierbarkeit kriegt man dazu. Und die Verfügbarkeit, die man dort bekommt, kann ich nur als Ansatzweise bereitstellen in einem normalen Rechenzentrum, gerade im Mittelstand. Agilität, Meilensteine, ich erkenne, ob ich die Ergebnisse, die ich mir als Team oder als Organisation auferlegt habe, ob ich die erreiche in dem Meilenstein. Wenn ich merke, ich habe drei Meilensteine und ich ziehe alle meine Aufgaben von einem Meilenstein in das andere, erkenne ich daran, dass die Agilität nicht oder der Fortschritt des Unternehmens nicht funktioniert. Ich sehe es sehr konkret. Das kann ich bei einem Wasserfall-Projektmanagement-Methoden nicht, weil da warte ich ja erstmal ab, bis das Ergebnis X dasteht und bis dahin habe ich maximal Uneffizienz teilweise, das aber erstmal zum späteren Zeitpunkt sichtbar wird. Bei der Agilität nicht. Bei der Agilität sehe ich dann, entwickle ich mich richtig oder nicht und kann dann schnell gegensteuern. Und auf der menschlichen Ebene? Also wir sprachen ja viel über die Menschen. Diejenigen, deren Rollen sich ändern. Hat man da irgendeine Möglichkeit für Frühwarnsysteme? Weil meckern tun die Leute ja immer. Also da jetzt einfach nur die Anzahl des Meckerns zu nehmen, wäre glaube ich schwierig. Die. Teilnahme an Meetings, an großen Meetings, wo dann die Leute sich gewisse Sachen an den Kopf werfen, woran es scheitert, an was Schuld ist, daran erkennt man die Stimmung in Meetings, wo man dann als Externer so ein bisschen teilnimmt und guckt, was ist denn tatsächlich dieses, also ineffiziente Meetings, das merkt man ziemlich schnell. Weil wenn man die Frage stellt was wollt ihr in diesem Meeting und wie wollt ihr später dann, also woran macht ihr fest, dass es ein erfolgreiches Meeting war mit genügend Output die Frequenz der Meetings etwas abzustimmen daran erkenne ich, ob etwas falsch läuft, weil, Wenn etwas klar ist und die Arbeitsplakete vergeben sind, dann sind die Meetings auch ein Stück weit vorgegeben und alle anderen Meetings kann man ja auch im kurzen Dialog klären. Gerade wenn ich jetzt mit einem anderen Fachbereich, der mir was zuliefern soll, sprechen muss, da brauche ich keine großen Meetings initiieren. Aber wenn ich große Permanent-Meetings habe, die ich initiieren muss, irgendwelche teilweise Taskforces oder Steering-Komitees, wo lauter bunte Bilder geballt werden und die Lichtjahre von dem Produkt entfernt sind. Die wissen gar nicht, was die Teams da unten tun, wo sie gerade stehen. Die Anzahl der Meetings erkenne ich ziemlich schnell, dass etwas im Argen ist, weil das setzt ja voraus, dass man sich viel mehr abstimmen muss und Sachen vielleicht korrigieren muss, um das Ziel zu erreichen. Und natürlich die Stimmung in den Meetings und in den Einzelgesprächen merke ich das auch immer. Gerade in der Kaffeeküche oder in der Mensa oder in der Kantine merke ich, dann halt immer, ey, was hältst du davon? Oder wie ist dein Gefühl? Und die Ergebnisse bleiben dann einfach aus. Man ist mit einer großen Euphorie losgelaufen, aber hat das nicht konsequent weiter verfolgt und hat sich dann verhaspelt. Daran erkennt man an der Stimmung der Menschen am Ende des Tages. Und wenn dann der Karren so richtig schön im Dreck ist, dann ruft man dich. Und was kann man da so machen? Nicht unbedingt mich, aber jemanden wie dich. Ja. Ja, die Die Hauptaufgabe, also in solchen Projekten komme ich schon ziemlich häufiger, dann frage ich erstmal, was war denn eigentlich der Motivator? Warum habt ihr dieses Projekt initiiert? Welche Geschäftsziele wollt ihr damit erreichen? Oder war das nur ein Proof of Concept, mal kurz rantasten, wie sich das anfühlt? Was lernen dann. Ja, lernen. Okay, dann dürfen die Leute auch nicht böse sein, wenn man daran scheitert, weil beim Lernen kannst du ja auch scheitern. Du lernst ja immer was. Du lernst, das ist nichts für dich oder du lernst, wie es funktioniert oder du lernst, das löst dein Problem nicht. Weil es ist ja auch ein kultureller Wandel. Gerade wenn es im Cloud-Kontext ist, ist die Arbeitsweise auch eine andere. Es gibt neue Rollen. Es gibt Leute, die sich ausschließlich mit Adoption und Change Management beschäftigen. Also das heißt Kommunikation und Abholen von Mitarbeitern. Ob sie Meetings, Kick-Offs, Veranstaltungen initiieren, um einfach das Wir-Gefühl zu entfachen, weil gute Cloud-Transformationsprojekte leben einfach vom Mitmachen. Und da muss man die Leute abholen. In der Regel ist es so, dass ich meistens in die Projekte gehe, also erstmal mir das anschaue, was will der Kunde tatsächlich tun, dann vergleiche ich das, wo sie gerade stehen und dann... Egal wie etwas aussichtslos ist oder schlecht ist, also ich suche nicht den schwarzen Peter, sondern immer wertschätzend und sage, okay, du wusstest es damals nicht besser, alles gut, aber wir wollen es jetzt besser machen. Und eine Aufbruchsstimmung und dabei eine Motivation, aber auch einen klaren Fahrplan, wie man dieses Ziel noch erreichen kann, wenn das Ziel noch das richtige Ziel ist. Und dann, ich sage immer, klein anfangen und stetig wachsen, Schritt für Schritt, dann wenn es erfordert. Nicht versuchen, das große Rad zu drehen, wenn ich schon beim kleinen Rad schon Probleme habe. Ja. Auf jeden Fall. Vielleicht ist es allein schon wegen der Buchstaben. Cloud Transformation, es gibt mehr Buchstaben bei Transformation als bei Cloud. Also ist da anscheinend mehr drin. Und in meiner Erfahrung ist auch so, alles das, wo Dinge sich verändern sollen im Unternehmen, alles das, wo Transformation, Change oder dergleichen ist, das braucht dedizierte Menschen, die sich darum kümmern, das zu begleiten. Weil du hast immer zwei Arten von Kräften. Du hast die Aufbruchstimmung und du hast die Erhaltungskräfte. Ich hatte letztens auch mit einem Kollegen gesprochen und da ging es darum, über so ein Change-Thema, welche wichtigen sieben Fragen stellen wir eigentlich dem Kunden, wenn es um Change geht. Und die Fragen waren alle in die Zukunft gerichtet, was gut ist. Aber ich finde, du musst auch in die Vergangenheit gucken und sagen, was wollen wir alles erreichen und was wollen wir mitnehmen von dem Alten. Gibt es von dem Alten noch etwas? Und das ist bei den Leuten sehr, sehr wichtig, wenn die sagen, ich habe ja hier den Schraubenschlüsseltyp, der muss jetzt den ganzen Tag herhalten. Wenn der halt ein gewisses Wissen hat und er hat Sorge, dass er das loswerden muss, weil er jetzt in die Cloud geht und dann ist das alles nicht mehr wichtig, was er vorher wusste, dann ist da ja irgendwas zu bewahren. Und diese Bewahrungskräfte, die so ein bisschen Aikido-haft in Aufbruchskräfte umzuverwandeln, das kannst du nicht nebenbei machen. Du kannst nicht sagen, ich mache jetzt hier ein bisschen Technik und vielleicht auch noch Geschäftsmodell und ich frage nur, was die machen wollen und dabei nehme ich noch die Leute mit und bin die inspirierende Galleonsfigur. Sondern du musst Change auch als das begreifen, was es ist Leuten zuhören. Hier Betroffene zu Beteiligten machen, dass sie auch sagen können, was ist ihr Ding und das, was Chefetagen am wenigsten wollen und wenn die irgendwas sagen, wo eine neue Erkenntnis ist und man muss seinen Plan nochmal anpassen, diesen Plan bitte auch wirklich anpassen und wenn du sagst, was war der Grund, warum wir ursprünglich hingeklaut wollten, vielleicht ändert der sich jetzt nach dem, was wir an Widerstandskräften gesehen haben. Vielleicht müssen wir es nuanciert oder größer anpassen, damit das Unternehmen an einem Faden ziehen oder an einem Seil ziehen möchte, dass sie mitkommen. Ja und das ist die Hauptaufgabe der Geschäftsführung des C-Levels, das zu kommunizieren. Zu sagen, wir haben einen Weg beschritten, wir wollen folgendes erreichen. Wir wissen auf dem Weg vielleicht noch vieles, das wir noch beantworten müssen, was wir heute noch nicht wissen. Und es ist ein Stück weit, also was heißt ein Stück weit, Fehler sind erlaubt. Wir haben eine Fehlerkultur. Wir wissen alle das nicht besser. Und wir machen alle in einer Form Fehler. Das macht auch keiner wissentlich. Also von daher, das bringt auch nochmal den Druck aus dem Kessel. Und es gibt auch ein Stück weit Menschlichkeit und Vertrauen wieder. Wir wollen alle gemeinschaftlich lernen. Das ist ein Stück weit Pioniersarbeit für mich als Unternehmen. Ich weiß am Ende des Tages das Resultat nicht ganz. Aber ich bin voller guter Hoffnung, weil ich habe eine Vision. Und male mir die aus und versuche, die bestmöglich zu erreichen, unter anderem auch mit Cloud und mit den Menschen. Und es gibt ein schönes chinesisches Zitat, wenn der Wind der Veränderung weht, bauen die einen Mauern und die anderen Windmühlen. Und das Adoption and Change Management Team, das muss ein Team sein von Pädagogen und Kommunikatoren, genau denen, der den Schraubenschlüssel in der Hand hält, zu sagen, pass auf, dein Arbeitsplatz und wie alle anderen Arbeitsplätze werden sich in der Zukunft ändern. Ihr werdet einen anderen Schwerpunkt haben. Du kannst nicht jederzeit den Schraubenschlüssel an die Hand wollen und den verteidigen müssen. Irgendwann gibt es keine Schrauben mehr, weil dann gibt es was anderes. Und dann bist du nicht mehr wettbewerbsfähig, nicht nur für das Unternehmen, aber auch später im Markt nicht. Und das als die Vorteile, wenn er sich weiterentwickelt, welche Vorteile er noch bekommt, dass er sich fachlich und auch disziplinarisch vielleicht auch weiterentwickeln kann. Dieses Positive, das ist die Aufgabe eines Teams, dass diesen Wandel kulturell hauptverantwortlich, also nicht nebenbei zu tausend anderen Sachen stiefmütterlich, sondern wirklich die Leute mitnimmt und gerade bei diesem Wandel. Deswegen bin ich immer drauf und dran zu sagen, fangt klein an, nehmt ein bestimmtes Projekt, wo ihr gerade Schmerzen habt, verprobt das, sowohl menschlich, organisatorisch, prozessual und technologisch und reift daran und wird immer besser und dann nehmt ihr euch das zweite Projekt, das dritte Projekt. Ihr glaubt nicht, wie dieser Ansatz euch weiter bringen wird und irgendwann seid ihr auf einer Ebene, wo ihr immer mehr Gleichgesinnte bekommt, von Kritikern zum Fan umgemünzt und dann haben die Leute Bock mitzumachen, weil sie dann sehen, wie erfolgreich diese Meilensteine werden und wie sagt man so schön, tue Gutes und spreche darüber und das bringt auch jeden Kritiker irgendwann durch die Ergebnisse positiv geschimpft und nicht jeder muss den Wandel mitmachen, dann ist es halt so, dann ist er aber auch nicht mehr der Richtige für das Unternehmen. Ich finde das Kleinanfangen wichtig, aber wo man darauf aufpassen sollte, Kleinanfang heißt nicht in einem Team auf einer niedrigen Ebene, sondern ich glaube, du brauchst es bei ihnen schon. Aus der Geschäftsleitung heraus muss jemand sagen, ich unterstütze das und ich finde das richtig. Ich habe schon oft gesehen, gerade mit Agil, wenn Teams anfangen wollen, agil zu sein, sind sie in dem harten Unternehmenskorsett, bleiben da, sind dann aber ihr eigenes Team von 30 Entwicklerteams, das eine ist jetzt agil. Das ist immer so ein sehr kleiner Tropfen auf dem super heißen Stein. Das wird auch nicht funktionieren. Und deswegen ist, glaube ich, so ein kleiner, So einen Kuchenschnitt zu machen, wo man sagt, von ganz oben nach ganz unten schneide ich einen ganz kleinen Streifen und dieser kleine Streifen, der hat aber auch hier einen Sponsor im Top-Management, der hat Leute, die das auf der Fachebene umsetzen können, der hat Leute, die das eben als Maschinenraum-Experten mit Schraubenschlüsseln, was auch immer man dann braucht, umsetzen können. Und ganz leicht verwechselt man ja, dass man sagt, fang klein an mit, fang doch mal auf irgendeiner Arbeitsebene an, mach das mal irgendwo. Aber Selbstabteilungsleitung wäre, glaube ich, noch zu klein, wenn du sagst, du willst das irgendwie nach vorne tragen. Es braucht immer irgendeine Art von Sponsorship aus einer höheren Ebene, um da wirklich nachhaltig nach vorne gehen zu können. Und auch durchgängig. Also ich könnte sogar ein konkretes Beispiel nennen. Wir haben eine Organisationseinheit in einem Unternehmen aufgebaut, das nennt sich Center of Excellence. Das beschäftigt sich um Legacy-Anwendungen in die Cloud zu bringen. Das arbeitet hoch agil. Jetzt gibt es aber zuständige Fachbereiche, mit denen dieses agile Team zusammenarbeiten muss, damit sie diese Workloads wirklich effizient in die Cloud bringen. Und dann gibt es so Abteilungen wie Steuer oder Compliance oder halt auch IT-Sicherheit, die kein Bestandteil dieses agiles Teams waren. Und dann ist die Evolutionsbremse, sobald eine agile Arbeitsweise auf eine klassische nicht agile Arbeitsweise trifft, passiert Stillstand, nahezu Stillstand. Und dann hat man den ganzen Spirit, die ganze Performance, was man alles sich geplant hat, aufgebaut hat, darf man es nicht betreiben, weil die IT-Sicherheit oder weil die Compliance oder die Steuer diese Arbeitsweise nicht gewohnt ist und dir erstmal wochenlang irgendwelche Termine gibt in die Zukunft. Es liegt auf unserem Haufen, wir kümmern uns drum, wenn du dran bist, bitte komm wieder. Genau, und jetzt hast du das Auto fertig gebaut, jetzt brauchst du nur noch Sprit rein, dann kannst du losfahren, dann sagst du, den Sprit kriegst du nicht, weil ich muss erstmal alle Radkappen prüfen. Und das ist genau der Punkt, du musst anpassen. Einen Use Case wählen, der komplett mit allen Fachabteilungen, denen es dazu bedarf, Teile davon, daran widmen müssen, auch agil. Ansonsten baust du eine agile Welt mit einer nicht agilen Welt auf und sobald du eine Komponente oder eine Ressource aus einer nicht agilen Welt brauchst, wirst du scheitern oder kommst dann halt in den Stillstand und in die Frustration, weil du hast ja ein tolles Produkt gebaut, du weißt es, aber derjenige, der nicht agil mitarbeiten soll, weiß es aber noch nicht und arbeitet auch ganz anders und dann passiert der Frust und das ist wirklich von der Geschäftsführung zu klären, diesen Schnitt zu machen. Ich will was verproben und ich brauche alle Stakeholder an dem Tisch, den ich dafür brauche, um diesen Use Case umzusetzen. Du. Hattest das schon mehrfach gesagt und ich traue mich gar nicht, die Frage zu stellen, aber wie lang sollte denn ungefähr so eine Transformation angesetzt sein? Ich weiß, die ist nicht so richtig zu Ende, aber Ich habe so ein kleines Projektmanagement-Herz und das sagt mir immer, alles hat irgendwie eine bestimmte Dauer, auf die es angelegt ist. Spricht man da eher von Monaten, Jahren, Jahrzehnten? Wie würdest du sagen, wenn man das jetzt so ein bisschen abschichtet und sicher kann man dann weitermachen, aber was… Was wäre so der Rahmen, in dem man sich bewegen sollte für die kleineren, aber auch für eine etwas größere Initiative? Das sollte man für eine Cloud-Transformation mal so grob. Nehmen. Also eine Zeitdauer kann man leider nicht sagen, weil sie an umfangreichen Faktoren geknüpft ist. Also das heißt, die Antwort würde heißen, kommt drauf an. Das hat ich befürchtet. Ja. Deswegen würde ich es sehr agil machen. Ich würde es in Interaktionsstoff machen. Ich würde jede drei Monate, jedem Planungsschritt einen Erfolg verkünden, damit die Leute auch daran Spaß haben und sagen, hey, erst in zwei Jahren sehe ich den Erfolg meiner Arbeit oder sehe ich den schon alle drei Monate. Das ist eine ganz andere Motivation. Und ein Unternehmen, was seine ERP-Lösung weltweit zentralisieren und in der Cloud aufbauen will, was zwei, drei, vier Jahre dauert, dann kannst du die Leute nicht vier Jahre lang bei Laune halten und sagen, hey, am Ende des Tages knallt der Schampus. Bis dahin ist halt viel, viel Arbeit und Schweiß und scheitern verurteilte Schritte zu durchlaufen. Nein, damit kriegt man keine Transformation erfolgreich, nachhaltig abgeschlossen. Wie lange dauert eine Transformation ist auf Basis des Use Cases, der Größenordnung des Unternehmens ist auch ganz wichtig und der Aufgabe. Wenn man sagt, ich möchte gerne, dass mein Mittelstand von lokalen Office-Anwendungen in die Cloud M365 nutzen soll, dabei immer mehr Services adaptieren, also erstmal typisch Word, Excel, Teams und so weiter nutzen will, aber später soll sie auch die Prozesse optimieren, wie zum Beispiel über Power-Plattformen, wo ich dann halt komplette Geschäftsprozesse automatisiere. Ich würde das in Interaktionsstufen machen und sagen, hey, diese Transformation von diesem Use Case dauert so und eine Transformation hat normalerweise eigentlich nie ein Ende, weil die Welt dreht sich ja permanent losgelöst, welche Transformation man als Unternehmen gestoßen hat, immer weiter. Auf jeden Fall. Und man muss darauf reagieren und wenn man es agil macht, kann man schnell darauf reagieren, wenn man es…, klassisch macht, dann wird es schwierig. Somit könnte man eigentlich sagen, dass die Cloud-Transformation eigentlich nicht eine einzelne Transformation, die irgendwann fertig ist, sondern das ist das neue Geschäftsmodell, wie IT funktioniert oder wie Technologie im Unternehmen funktioniert. Genau. Es ist nicht nur der Wandel technologischer Art für das Unternehmen, sondern auch der kulturelle Wandel und der Wandel mit den Menschen zusammen. Technologie anders zu sehen, anders bereitzustellen, anders mitzuarbeiten und im Zeitalter, wo man sagt, anytime, anyplace, anydevice, rund um die Uhr das System verfügbar ist, in der Qualität und Form, wie ich es brauche. Und egal, wo ich bin, kann ich den Service adaptieren. Dann. Ist, glaube ich, der Begriff schwierig gewählt, weil Cloud-Transformation für mich bedeutet, da ist irgendwann was angefangen und fertig. Aber es ist eigentlich eher eine Art zu denken. Es ist nicht so sehr ein Vorgang, der abgeschlossen wird, sondern es ist ein Paradigma, es ist eine Art zu denken. Die Leute sagen dann, oder was man durchaus sagen kann, dann, wenn ich alle meine Systeme in der Cloud habe, habe ich ja keine Cloud-Transformation mehr. Wenn all meine alten Anwendungen, die ich nicht mehr habe, die gibt es nicht mehr. Ich habe nur ein paar Netzwerkkomponenten lokal, vielleicht noch ein, zwei Testsysteme, ansonsten habe ich alles in der Cloud. Dann kann ich ja sagen, okay, jetzt bin ich auf einer Ebene, die ich vorher noch nie hatte. Jetzt bin ich komplett in der Cloud. Jetzt mache ich mir Gedanken, wie ich in der Cloud Multicloud-Modelle betreibe. Also das heißt, das Evolutionslände ist ja noch nicht fertig. KI besser einbinde. Dass meine Cloud über die KI komplett gesteuert wird, dass ich meine Workloads auf Basis von unterschiedlichen Kriterien an den besten Cloud-Provider platziere, der mich am meisten voranbringt. Sowohl Kosten, Nutzen und Risiko. Die Transformation geht trotzdem in der Cloud, auch wenn ich alle Workloads hätte in der Cloud, trotzdem weiter, weil die Cloud sich ja auch in sich weiterentwickelt und die Services immer mehr werden. Wenn wir das jetzt versuchen zusammenzufassen, für Menschen, die da draußen zuhören und sich sagen, oh, Cloud Transformation, würde ich auch gerne mal probieren. Was für drei Tipps würdest du denen geben und sagen, auf diese Sachen solltest du achten, um das nochmal zu pointieren, was wir hier jetzt die ganze Zeit gesagt haben? Klare Ziele sich stecken, diese zu kommunizieren, dann zu sagen, warum man sich für Cloud entschieden hat, um diese Ziele zu erreichen, also auch wieder Kommunikation, klein anzufangen, das Ungewisse zulassen dabei, in bester Form mit Agilität anzufangen und Stück für Stück kleine Quick Wins zu erzielen, um zu zeigen, dass man auf dem richtigen Weg ist und die Leute dabei abholt. Und die Leute kriegt man immer gut abgeholt, wenn man Erfolge feiert. Kurzfristige Erfolge feiert, die Menschen mitnimmt, deren Bedürfnisse und deren Ängste wirklich sich anhört und auch ein Team darauf ansetzt, diese Kommunikation aufzubauen. Weil wenn die Kommunikation nicht stimmt, dann löst die ausgeklügelste Technologie in der Cloud nichts, wenn die Leute das nicht annehmen. Also, klein anfangen, klare Ziele stecken und ja, Menschen mitnehmen. Das war Ein Geek kommt selten allein. Vielen Dank fürs Zuhören und großen Dank an dich, Taifun. Danke auch. Mach's gut, lass dein Abo da und bis zur nächsten Folge. Wir hören uns.