Folge 14: DevOps im SAP-Umfeld: Geht das überhaupt?

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Viele Prinzipien und Ansätze in der DevOps Philosophie passen auf den ersten Blick nicht zum monolithischen SAP. Mit Daniele Di Croce und Franz Hiltscher von der REALTECH AG spreche ich über die Einsatzmöglichkeiten von DevOps im SAP-Umfeld.

In dieser Podcast-Episode werden die Anwendbarkeit und die Vorteile von DevOps-Praktiken im SAP-Umfeld erörtert. Die Gäste, Franz Hilscher und Daniele di Croce von REALTECH, diskutieren gemeinsam mit dem Moderator über die Herausforderungen und Möglichkeiten der Integration von DevOps in SAP-Systeme. Sie betonen die Bedeutung von kulturellen Veränderungen in Unternehmen, den Einsatz von Automatisierungstools und die Notwendigkeit, klein anzufangen und schrittweise vorzugehen. Trotz der Komplexität von SAP-Systemen und anfänglicher Zweifel, zeigen sie auf, wie agile Methoden und DevOps erfolgreich implementiert werden können, um schneller auf Marktanforderungen zu reagieren und die Qualität der IT-Services zu verbessern.

Inhalt

  • Einleitung und Vorstellung der Gäste
  • Grundlagen und Definition von DevOps
  • Anwendbarkeit von DevOps im SAP-Umfeld
  • Herausforderungen bei der Implementierung von DevOps in SAP
  • Bedeutung von kulturellen Veränderungen und Mitarbeitermotivation
  • Einsatz von Automatisierungstools in SAP
  • Praktische Beispiele und Erfahrungen aus der Realtek
  • Agile Methoden und deren Einfluss auf SAP
  • Organisatorische Veränderungen durch DevOps im Unternehmen
  • Wirtschaftliche Vorteile durch DevOps-Anwendung in SAP
  • Abschließende Empfehlungen und Ausblick

Transkript (automatisiert, daher keine Gewähr 🙂 )

Herzlich willkommen zu einer neuen Folge zum DevOps-Podcast auf die Ohren und ins Hirn.
Wir haben heute das Thema DevOps im SAP-Umfeld. Geht das überhaupt?
Und ich freue mich, dass ich dort zwei Gäste habe, die uns diese Frage beantworten können.
Ich begrüße den Franz Hilscher und den Daniele die Krotsche von der Realtek.
Und insofern würde ich sagen, auch da wieder schnell den Ball rüberspielen.
Daniele, Franz, könnt ihr euch und auch das Unternehmen mal kurz vorstellen?
Ja, gern. Ich bin der Daniele. Ich bin Mitbegründer der Firma Realtek.
Wir haben Realtek vor 25 Jahren gegründet als Beratungsunternehmen im SAP-Umfeld.
Und sind heute als Softwareanbieter im SAP-Umfeld tätig.
Und haben Tools zur Automatisierung vieler Abläufe im SAP-Rechenzentrum, die wir dem Markt anbieten.
Mein Name ist Franz Hilscher. Ich bin seit über zehn Jahren bei der Realtek.
Wenn man zu dem heutigen Thema, ich komme perspektivisch aus dem Ops-Bereich in SAP.
Also SAP-Basis, Betrieb, Systemarchitekturen und Systembereitstellung.
Sehr schön. Die Zuhörer unseres Podcasts kennen das.
Ich bitte dann die Teilnehmer auch immer oder die Gäste auch immer, sich nach der Vorstellung um eine Definition von DevOps zu bemühen.
Also insofern wäre die Frage, wie würdet ihr DevOps definieren oder beschreiben?
Gut, also ganz DevOps ist eine Sammlung von neuer Mindset, Methoden, praktischen und natürlich Software-Tools,
die den Unternehmen ermöglicht, seine Anwendungen und IT,
seine IT-Services schneller und einfacher zur Verfügung zu stellen oder bereitzustellen.
Ja, also agile Methoden sind ja im Entwicklungsumfeld, also im Dev-Bereich schon seit längerer Zeit etabliert.
DevOps ist einfach der Versuch, diese sich wirklich bewährten Methoden auf dem Bereich Betrieb auch mit zu erweitern.
Also Entwicklung und Betrieb gleichermaßen agil zu gestalten.
Franz, bei dir habe ich so ein bisschen rausgehört, auch den Punkt,
den ich ja für immer für sehr wichtig erachte, was du sagst, schneller bereitstellen,
also auch in Richtung des Kunden oder der Kunden, das heißt, den Kunden ein bisschen mehr mit einbeziehen.
Ist das richtig interpretiert?
Korrekt, ja. Es geht alles eigentlich immer weiter Richtung, also alle Services und Lösungen richten sich ja trendmäßig Richtung den Anwender,
also den Endkunden aus, also dieses kundenzentrische Agieren in allem, was wir eigentlich tun.
Ich glaube, das ist…
Mittlerweile allgegenwärtig.
Ja, wenn ich so zurückblicke, ihr habt ja beide auch ein bisschen, ein paar Jahre auf dem Buckel in der IT, aber ich mittlerweile auch.
Und ich meine, mit den Kunden haben wir immer im Fokus gehabt, haben wir jedenfalls gesagt,
aber mein Eindruck ist, dass wir durch DevOps, sprich auch die Pessosarbeit in der IT,
ja, das auch wirklich mit dem Kunden, weil doch mehr mit einer Sprache sprechen gegenüber dem Kunden.
Definitiv.
Also letztendlich ist dieser Fokus…
Der Fokus auf den Kunden, die geheime Zutat schlechthin für Erfolg.
Die Frage ist eben, in welchen Abständen man Kontakt hat zum Kunden.
DevOps ermöglicht das, in sehr kurzen Abständen letztendlich Feedback vom Kunden einzuholen,
um letztendlich auch kontinuierlich abchecken zu können, ob man genau das tut, also das dem Kunden liefert, den Wert, den der Kunde auch erwartet.
Ja, okay.
Der Titel vom Podcast lautet ja…
Im SAP-Umfeld, geht das überhaupt?
Und ich habe diesen etwas ketzerischen Titel mal gewählt, weil in meinen DevOps-Trainings dann auch schon mal SAP-Leute sitzen,
SAP-Minded-Leute sitzen oder auch Programmmanager, teilweise auch Kunden, die im ersten Moment sagen,
ja, die Ideen von DevOps sind gut, aber im SAP-Umfeld geht das nicht.
Das kann man ein bisschen auflösen in der Diskussion und es geht ja nicht nur um Automatisierung an sich,
aber so der erste Eindruck ist immer, das geht nicht.
Und insofern wäre jetzt…
Meine Frage an euch, wie kann man sich denn die DevOps-Ansätze im SAP-Umfeld zunutze machen?
Ja, geht nicht.
Das ist eine beliebte Haltung.
Gerade im SAP-Umfeld haben sich tatsächlich feste Muster etabliert über die letzten Jahre.
Aber nur weil etwas, ich sage mal, schwierig erscheint, darf man sich davor nicht drücken.
Letztendlich müssen die Kunden ihre Release-Zyklen verkürzen, also viel schneller Innovationen zum Markt bringen.
Ja, Time-to-Value.
Das muss kürzer werden.
Und diese Methoden kann man sich tatsächlich im SAP-Umfeld genauso zu eigen machen wie in anderen Bereichen.
Ja, das ist kein Hindernis.
Ja, man muss erstmal der Kopf umschalten, dass es möglich ist und nicht abzublocken.
Das ist, glaube ich, der erste Schritt.
Und die technischen Hürden kann man dann Schritt für Schritt nehmen.
Die sind nicht so groß, wie sie am ersten Blick erscheinen.
Das ist eine Kopfsache im ersten Schritt.
Ja, DevOps.
Das sagt ja, dass man mehr Wert legen muss auf Zusammenarbeit, auf Informationssharing.
Das ist natürlich im SAP-Umfeld genauso möglich wie in anderen Bereichen.
Wie läuft denn der typische Release-Zyklus ab?
Also häufig wird am Wochenende, so einmal im Quartal, ein neues Release eingespielt.
Dann stehen alle Gewehr bei Fuß, sind bereit, Anwendungsentwickler, Basisabteilung, Netzwerkabteilung
und wollen das Release einspielen und hoffen, dass alles gut geht.
Und so eine richtige High-Drama-Geschichte und meistens geht dann doch das eine oder andere schief.
Und dann steckt man die Köpfe zusammen und fängt an, Lösungen zu suchen.
Und hier ist eben der Ansatz von DevOps, warum tut man die Köpfe nicht schon vorher zusammenstecken,
mehr miteinander reden, mehr sich gegenseitig einbinden und versuchen,
bevor die Dinge schief gehen, letztendlich zusammenzuarbeiten und Qualität hereinzubringen.
Vor allen Dingen in einer Zusammenarbeit, die täglich stattfindet, die nicht einmal im Quartal stattfindet.
Damit es eben mehr Routine ist.
Wie wird es im SAP-Umfeld aussehen?
Denn dieses Vorurteil, das geht nicht, das muss ja irgendwo einen Grund haben, muss irgendwo herkommen.
Das SAP-System ist ja immer, sagen wir mal, der digitale Kern in den Unternehmen oder wird es gern bezeichnet
und hat auch diese Mantra, es muss stabil sein und es muss immer verfügbar sein.
Wenn es steht, steht das Unternehmen.
Das hat sich dermaßen, sage ich mal, in den fast Dekaden, 25 Jahre,
denke ich mal, in den Köpfen so eingebrannt und die ganzen Methoden und die Abläufe wurden daraufhin optimiert
und sind halt entsprechend auch unflexibel an der Stelle.
Und das jetzt aufzubrechen, das geht in kleinen Schritten.
Also wenn ich jetzt sage, ich möchte dieses ganze gewachsene Konstrukt und optimierten Betriebs- und Entwicklungsprozess im SAP-Umfeld
in Summe quasi umstellen, wird das…
Also ist das natürlich eine, erscheint diese als unlösbare Aufgabe.
Und ich denke mal, man muss hier wirklich in kleinen Schritten anfangen.
Entweder man macht einen einzelnen Prozessschritt oder man sucht sich ein eigenes System oder einen Bereich aus,
der ein bisschen autark agieren kann, um hier erste Erfolge zu feiern.
Und das dann im nächsten Schritt im SAP geht das natürlich per se über Automatisierungsmaßnahmen.
Das heißt, wenn ich das richtig interpretiere, geht es einmal um Kultur.
Also die Köpfe müssen sich öffnen.
Da ist eben auch eine gewisse Unflexibilität in den Köpfen über die Jahre hinweg gewachsen,
was natürlich auch erstmal nachvollziehbar ist, aber dann eben auch eine Unflexibilität in den Abläufen.
Und wenn man da rangeht, dann kommt man sicherlich auch an den Punkt, dass man es entsprechend technisch unterstützen muss.
Aber wenn ich das richtig verstehe, sagt ihr, erstmal muss ich in den Köpfen etwas verändern.
Das ist richtig.
Also der gesamte DevOps-Ansatz ist ja mehr eine Religion, als dass es eine Methodik ist oder dass es ein Tool ist.
Es betrifft dann am Ende natürlich Tools, es betrifft Leute, People und es betrifft Kultur.
Die Frage ist letztendlich, wo man anfängt.
Hier bewährt sich immer die Politik der kleinen Schritte.
Also der Mitarbeiter fragt sich natürlich am Ende auch immer, was ist denn für mich da drin?
Also wenn ich jetzt hier vieles ändern muss, alles über den Haufen werfen muss, was ich früher gemacht habe,
was habe ich davon?
Ja, und das ist eben eine Führungsaufgabe, dass nicht die Veränderung als Gefahr empfunden wird,
nicht als Bedrohung, sondern als Chance, letztendlich auch selbst zu profitieren.
Das heißt, Qualität zu erhöhen, manuelle Abläufe zu automatisieren, also Sachen, die langweilig sind,
am Ende über Software abzudecken und nicht manuell zu tun.
Ja, okay.
Na gut.
Insofern stößt das auf die Frage, was ist das, was wir tun?
Ja, okay. Na gut. Insofern stößt das auf die Frage, was ist das, was wir tun?
Und dafür ist dann hier vielleicht auch das Grundproblem, was ja auch von vielen gesehen wird,
flexible, schnelle Entwicklung, also agil, versus Stabilität, sprich stabiler Betrieb,
ja dann hier auch entsprechend aufeinander und hier dann vielleicht noch ein bisschen mehr.
Denn das, was ihr sagt, ist ja vollkommen richtig.
SAP ist ja in vielen Unternehmen der Kern.
Wenn SAP steht, dann steht das Unternehmen.
Das geht natürlich nicht für die eine oder andere Inhouse-Applikation oder für andere Themen.
Also insofern ist das natürlich schon der Grund, warum wir das machen.
Da ist natürlich schon der Anspruch da, dass SAP stabil sein muss und ich brauche sicherlich
auch nicht täglich neue Funktionen in der Finanzbuchhaltung ausliefern, wenn ich jetzt
mal so wirklich den einen Kern oder den einen Bereich von SAP rausnehme.
Also insofern, ja, der Kampf, der vermeintliche Widerspruch zwischen Agilität, also Schnelligkeit
und Stabilität, der ist dann im SAP-Umfeld genauso da.
Ist denn überhaupt möglich, dass wir in dem SAP-Umfeld ein Regelmechanismus haben, dass
wir das machen?
Das heißt, dass wir ein regelmäßiges, das heißt kurzfristiges Deployment in diesen
kurzen Zyklen bekommen, denn wir haben hier doch mittlerweile recht komplexe SAP-Landschaften.
Das ist durchaus möglich.
Wir haben auch viele Kunden in der Betreuung, die das auch schon machen.
Also wir deployen Änderungen täglich in die Produktion, entsprechend natürlich mit entsprechenden
Quality-Checks vorneweg und natürlich gesteuert und kontrolliert.
Aber es funktioniert und die Kunden, die den Mut haben, das zu tun, für die wird es, stellen
sich nach einer Zeit auch die Erfolge ein, weil wenn Sie sich mal vorstellen, so ein
typischer Zyklus im SAP ist so drei Monate bis sechs Monate ein Deployment in die Produktion
zu bringen.
Wenn sich jetzt die ganzen Entwicklungen über drei oder Änderungen über drei Monate aufsummieren
und die in Gänze in das System kommen und das ist das, was der Daniel ja auch meinte
mit der großen Fehlerquellen, also eine Vielzahl an Fehlerquellen, die ich habe und das ist
ein großes Drama an der Stelle und in der Regel, nach meiner Erfahrung, funktioniert
immer was nicht.
Und die Fehler dann zu identifizieren bei der Menge der Änderungen, die ich in On-Block
im System einspiele, ist weitaus komplex und auffällig.
Es ist aufwendiger, als wenn ich kontrolliert drei, vier Änderungen am Tag ins System einbringe
und weiß, was ich dann auch getan habe und kann mich dann auch schnell die Ursache identifizieren.
Letztendlich kennt ja jeder den Spruch never change a running system.
Das hat sich lange in der IT gehalten und am Ende kommt es ja wirklich auf die Anforderungen
an.
Also wenn ich, wie Dirk gesagt hat, in der Finanzbuchhaltung brauche ich nicht jeden
Tag neue Funktionen.
Das heißt, wenn die Anforderung gar nicht vorhanden ist, Geschwindigkeit aufzunehmen,
dann muss ich die Anforderung aufnehmen.
Dann spare ich mir natürlich den Aufwand gerne und sage, es reicht mir alle sechs Monate
hier was zu tun.
Wenn aber die Anforderung stärker vom Kunden her kommt, also Vertriebsseite, Marketingseite,
die Konkurrenz macht den Druck, weil sie einfach mit neuen Dingen auf den Markt kommen und
da kann man nicht hinterherhinken, dann verändert sich das Qualitätsverständnis.
Das heißt, von Vollständigkeit und Perfektion oder Gründlichkeit geht man halt zu einem
neuen Qualitätssystem.
Das heißt, das ist ein ganz besonderes Begriff, Schnelligkeit, Flexibilität und Feedback-orientierten
Entwicklungsprozess über.
Und hier setzt eben DevOps ein, das heißt, zu ermöglichen, den Anforderungen der heutigen
Zeit auch gerecht zu werden, sich Gedanken zu machen, wo muss ich ansetzen, damit ich
auch im SAP-Umfeld diese Anforderungen vom Markt erfüllen kann, schneller zu werden.
Ihr habt eben gesagt, tägliches Deployment, einige eurer Kunden im SAP-Umfeld machen wirklich
ein tägliches Deployment.
Nun gehört ja, denke ich, auch im SAP-Umfeld Testen jetzt als Beispiel mit dazu.
Was bedeutet das denn, abgesehen von den Erfolgen, die man erzielt, an Aufwand oder an Veränderungen,
wenn ich täglich deploye im SAP-Umfeld?
Also, sagen wir mal, vom Technischen her ist es mit den richtigen Tools gut umsetzbar.
Du sprichst jetzt natürlich einen guten Punkt an, das ist das Testen, das ist im Regel im
SAP-Fall, fällt das den Fachabteilungen zu.
Also der Buchhaltung oder der Logistikabteilung, die das eben anfordert.
Und da ist halt dieses, und da kommen halt auch wieder diese Silos extrem stark zum Tragen.
Die sind nämlich nicht nur Entwicklung und Administration im SAP-Umfeld, sondern es gibt
dann auch noch die Business-Seite, die Fachbereiche, die gerade im Testumfeld auch mit involviert
sind.
Die müssen natürlich dann in dieses DevOps-Modell investieren.
Ebenso mit eingebunden werden und stärker in der Zusammenarbeit und in den Feedback-Loop
mit integriert werden, damit das auch schnell funktioniert.
Also auch vorab schon in der Entwicklung mit drin, frühzeitig, eventuell schon im Entwicklungssystem
mit auf die Funktion gucken, intervenieren können, falls das nicht in die Richtung geht,
wie es sein muss.
Und nicht mehr diese starren Zyklen haben, auch in den Testphasen.
Also ich entwickle vier Wochen, dann teste ich vier Wochen, und wenn das dann wirklich
alles abgeschlossen ist, dann bereite ich noch zwei Wochen lang das Deployment in die Produktion
vor.
Das muss im Ablauf, im Prozess, in der Dokumentation natürlich in Summe alles beschleunigt werden.
Und natürlich die Königsdisziplin ist dann natürlich auch diese Tests weitestgehend
für einen Großteil der Funktionen zu automatisieren.
Ja, Franz.
Es ist ja so.
Ja.
Franz, es ist ja sicher nicht alles automatisierbar, aber zum Beispiel gibt es ja viele Objekte,
die im SAP-Umfeld transportiert werden müssen.
Man spricht ja bei SAP nicht von Deployment, sondern von Transporten.
Es gibt Objekte, die gar nicht kritisch sind.
Das heißt, die gewissen Approval-Schritte komplett eliminiert werden können, weil man
einfach sagt, wenn das in die Produktion übergeht, dann kann das nicht viel anrichten.
Ja, also man kann solche Checks in Software, sag ich mal, abbilden.
Sodass man sich da keine Gedanken machen muss, gewisse manuelle Schritte einzuhalten,
Workflows einzuhalten, sondern kann das automatisieren.
Da, wo die Automatisierung, ich sag mal, nicht möglich ist, da wird man natürlich mit den
Limitierungen des Systems leben müssen.
Aber man kann vieles beschleunigen, vieles vereinfachen und sich letztendlich auch Routine
antrainieren.
Ja.
Wenn man einmal alle drei Monate so eine Prozedur durchführt, eben Release einzuspielen, dann
ist es jedes Mal wieder ein neues Abenteuer.
Wenn man das täglich macht, dann ist es Routine.
Es verliert einfach den Schrecken, wenn man täglich etwas tut, wie soll ich sagen, also
dass es irgendwie schwierig wird.
Und wenn man täglich etwas tun muss, dann wird man sich auch angewöhnen, so ist der
Mensch halt, weil er faul ist, die Dinge in Skripte oder in Software zu automatisieren,
weil jeden Tag dieselben Handgriffe zu machen.
Ja.
Das kommt dann irgendwann doch ein bisschen merkwürdig vor.
Franz, du hast eben davon gesprochen, dass ja eigentlich auf der Business-Seite auch
die Silos da sind, die Spezialisierung auf ganz bestimmte Bereiche und dann sich die
Silos dort eventuell auch behindern.
Nun ist ja ein Teil von DevOps eventuell auch die Teams entsprechend oder die Organisation
anders zu gestalten, Teams anders zu gestalten und Teams quasi um Business-Funktionen oder
Business-Bereiche herum zu gestalten.
Stichwort Conway’s Law.
Habt ihr da auch schon Erfahrungen bei Kunden, dass sie eben auch ihre SAP-Mannschaft anders
aufgestellt haben, quasi noch mehr in Richtung Business organisiert haben?
Ich kenne viele Kunden, die das gerade machen.
Also die organisieren sich in der IT nicht mehr nach funktionalen Aufgaben, also Server,
Datenbank, wie es, sag ich mal, in den letzten Jahren üblich war, also schon viele oder
sind schon viele.
Oder sind dazu übergegangen.
Ja.
Die Kunden versuchen dann, sich in ihrer Organisation nach den Business-Funktionen auszurichten,
zumindest was die Kundenseite angeht, ja.
Ein paar wenige haben das wirklich auch in der kompletten Linienorganisation dann natürlich
auch mit übergreifenden Teams dahinter schon umgesetzt.
Also was du sagst, also die Richtung ist ganz klar zu erkennen bei den Kunden.
Jetzt haben wir eben schon ein bisschen was angesprochen, also organisatorische Veränderungen
eventuell.
Natürlich technische Veränderungen, Automatisierung.
Gibt es noch ein paar Rahmenbedingungen, die man aus eurer Sicht berücksichtigen müsste,
wenn man im SAP-Umfeld in Richtung DevOps geht?
Ja, also es ist, das Thema in Summe ist natürlich sehr komplex.
Ich würde empfehlen, sich ein kleines Team zu suchen, die auch begeistert sind, innerhalb
der SAP-Organisation oder IT-Organisation das anzugehen.
Und dann mit Keywords.
Ja.
Und dann auch in kleinen Projekten und kleinen Schritten quasi Erfolge feiern und darzulegen,
dass es möglich ist und sich dann Schritt für Schritt an die, ich sage mal, an die
großen Kernsysteme ranzuwagen.
Und man muss, man darf nicht quasi versuchen, die komplette IT-SAP-Organisation mit einem
Big Bang auf DevOps umzuschalten.
Das wird nicht funktionieren.
Und man muss seine Infrastruktur, also auch den ganzen, sage ich mal, den ganzen Application Stack da sukzessive in die Richtung bewegen. Aber Einstieg, sagen wir, start small, think big ist, glaube ich, da der beste Weg.
Ja. Und nicht sofort, wenn man, sagen wir, im ersten Schritt Prozessschritte jetzt nicht nach, sagen wir, nach DevOps, nach dem DevOps-Modell betreiben, umsetzen lässt, dann auch nicht. Dann lege ich den erstmal zur Seite und versuche, den nächsten Prozessschritt zu automatisieren, zu vereinfachen.
Also ich will das vielleicht so ergänzen. Ich meine, am Ende ist es ja so, dass, also ich sage mal, sich agil zu machen.
Ist zunächst mal ja mal ein Change-Prozess. Das heißt, ob das jetzt einhergeht mit Kulturwandel, mit Organisationsveränderungen, mit der Einführung neuer Tools, es sind Changes, es ist Veränderung.
Und der Mensch verändert sich in der Regel nicht so gern, es sei denn, dass er erkennt, dass das notwendig ist. Das heißt, die Frage ist, wo kommt die Anforderung her? Also wo kommt der Druck her, dieses Optimization for Speed im Unternehmen quasi,
Einzug halten zu lassen, statt, wie bisher immer ging es ja darum, Optimierung vor Kost. Es mussten die Sachen immer effizienter, günstiger werden. Und in Zukunft soll man ja eigentlich schneller anpassungsfähig sein auf die Anforderungen des Kunden.
Wenn das gegeben ist, dann wird der Wandel in Richtung einer DevOps-Organisation schon sehr schnell sich rumsprechen in Unternehmen, dass das Vorteile bringt, dass das zwingend ist, dass man sich dem nicht entziehen kann.
Und dann heißt es eben nur, wo fange ich an? Also People, Prozesse. Und da hat der Franz ja gerade gesagt, da bewährt sich die Politik der kleinen Schritte. Also nicht mit der Tür ins Haus fallen, sondern Projekte herausnehmen, wo man das vielleicht auch einfach umsetzen kann.
Das wird sich dann intern schon rumsprechen, dass man schneller zum Ziel gekommen ist mit weniger Problemen, mit weniger Qualitätsproblemen. Und letztendlich hat man sein Ziel in kürzerer Zeit mit besserer Qualität erholen.
Also diese internen Fürsprecher für die Methodik zu finden, das ist, glaube ich, ein guter Ansatz.
Ja, okay. Franz, du hast eben nochmal davon gesprochen und Daniela auch, ja, mit dem Vorschlag, mit kleineren Schritten zu starten, aber auch mit entsprechenden Teams.
Wie stark hindert denn dann das Thema ein komplexes, zusammenhängendes System, nämlich SAP, beim Aufbau von autonomen Teams?
Wenn ich an meine Schulung auch da wieder entsprechend zugehe?
Das ist ja ein wichtiger Punkt, den wir rüberbringen. Autonome Teams. Und autonome Teams heißt auch, dass sie ja auch von der Architektur her autonom sein müssen. Stichwort Microservices. Also insofern, die Frage wäre, wie stark hindert SAP den Aufbau von autonomen Teams, die ja auch architektonisch autonom sind?
Im jetzigen Release, also das SAP ERP, was noch sehr verbreitet ist, gibt es die Softwarearchitektur.
Natürlich ist der Aufbau von Microservices nur sehr, ja, nicht wirklich möglich, eins zu eins. Dazu kommt, dass sich halt aufgrund der steigenden Rechenleistung in den letzten Jahren auch sehr viel konsolidiert wurde von den Unternehmen.
Wieder Optimation for Cost. Natürlich versucht, so viele Funktionen wie möglich in ein zentrales System zu bringen, um Wartungsaufwände zu sparen.
Und so weiter und so fort. Ich glaube mal, natürlich perspektivisch und auch mit S4HANA muss da, was das SAP System Landscape Design angeht, da auch eine andere Richtung eingeschlagen werden, um das natürlich durchgängig zu schaffen.
Und es wird auch mehr und mehr Microservices aus der SAP Cloud mit integriert.
Und das, sage ich mal, Schritt für Schritt, sage ich mal, nicht von alleine löst, aber mehr und mehr entspannen wird.
Es gibt aber, sage ich mal, auch kleinere, sage ich mal, Zuhilfssysteme, die man autonom am Anfang schon betreiben kann.
Das sind jetzt natürlich nicht, sage ich mal, die Produktionssteuerungssysteme, aber zum Beispiel im HR-Umfeld, wenn man gerade sehr viel Richtung Employee Self-Services macht im SAP und da auch, gut, das ist jetzt, und den Mitarbeitern.
Da sehr viele Zusatz-Services bieten will, kann man das auch in einem kleineren Umfeld machen oder in einem GTS-System, was jetzt, sage ich mal, nicht so stark komplex ist.
Man muss, ich glaube, man muss diese Spielfelder identifizieren, finden und anfangen.
Ich glaube, wir müssen vielleicht auch ein paar Begriffe nochmal differenzieren, weil wir reden die ganze Zeit über SAP.
Die Frage ist nur, SAP ist eben nicht mehr wie vor 20, 25 Jahren.
Der Hersteller eines monolithischen, sage ich mal, Systems, damals R3, heute S4, HANA, welches alle diese integrierten Funktionen, die man im Unternehmen zur Steuerung von Unternehmensprozessen benötigt, integriert hat oder in einem Ort hat.
SAP ist heute ein sehr, sehr großes Unternehmen mit sehr, sehr vielfältigen Produkten, die es letztendlich anbietet.
Und deswegen müssen wir nochmal unterscheiden.
Also das Klassische, wie man SAP kennt, ist sehr geprägt von diesem Silo-Denken.
Ich habe eine Basisabteilung, die IT.
Ich habe eine Anwendungsentwicklung, die Prozesse kennt und entwickelt und es eigentlich mal dann auch zur Verfügung stellt den Benutzern.
Die SAP selbst versucht, diese Problematik ein Stück weit damit zu lösen, zu sagen, okay, geht mit dem System, mit dem Monolithen, mit dem Kern in die Cloud.
Dann braucht ihr schon überhaupt gar keine Basis mehr, weil das macht die SAP.
Und alle Änderungen macht ihr über die Cloud-Plattform.
Die SAP Cloud-Plattform ist ja von sich aus, wie sie geboren wurde, schon ein agiles System.
Agilität ist schon in den Genen.
Denn, sag ich mal, in dieser Denke der Open-Source-Welt auch, ist Agilität ja schon lange zu Hause.
Das Problem ist, wie kriegen wir das nach SAP?
Und mit dieser einfachen Lösung, also man tut einfach sein System, sein SAP, sein altes SAP-System in die Cloud und entwickelt dann alles auf der Cloud-Plattform an Ergänzungen und Erweiterungen.
Das ist die ideale Welt.
Die Wahrheit wird anders aussehen.
Die Wahrheit wird aussehen.
Das heißt, man hat Systeme, die man vielleicht nicht sofort in die Cloud geben kann oder will.
Und wie kann man in diesem Umfeld auch DevOps nutzen?
Und hier kommen wir als Giltig auch ein Stück weit mit Tools dem Kunden entgegen, mit Methodiken entgegen, sodass sie auch ihre klassischen Landschaften, ja, da, wo es geht, beschleunigen können.
Und dieses Köpfe zusammenstecken, dieses Einbetten von Entwicklung und Basisabteilung ineinander in diese agilen Teams, die sich eben formieren.
Und das ist ganz wichtig.
Also wir wollen auch den klassischen, sag ich mal, SAP-Kunden helfen, heute schon schneller zu werden.
Ja, du hast es eben schon angesprochen.
Das Ganze muss ja Vorteile bieten für die Unternehmen.
Also Time-to-Market reduzieren, die schönen Buzzwords, die wir so entsprechend auch kennen.
Letzten Endes ist ja die Frage, wo haben Unternehmen, die…
SAP automatisieren, die Change-Management automatisieren, wo haben die wirklich betriebswirtschaftliche Vorteile, die man auch wirklich rechnen kann, die man beweisen kann?
Also ich denke, das geht relativ schnell, die Sachen zu beweisen, denn wir sagen ja heute, dass Ressourcen knapp sind, also vor allen Dingen Fachkräfte sind knapp.
Das heißt, eigentlich muss jedes Unternehmen, jeder Kunde muss sehr interessiert daran sein, eben seine, sag ich mal, wertvollen Fachkräfte in Projekte,
zu stecken, die tatsächlich zukunftsorientiert sind, die Value schaffen und nicht manuelle Routineaufgaben zu erledigen.
Und wenn wir sehen, dass man gewisse Aufgaben, gerade im Change-Management-Bereich, sehr einfach automatisieren kann,
dann bringt das wirtschaftlich in sehr kurzer Zeit einfach Kostenvorteile.
Es wird weniger manuell gemacht.
Viele Dinge werden zur Routine, weil man sie auch häufiger macht.
Das heißt, weniger fehleranfällig.
Man muss sich ja nicht so lange mit gewissen Dingen beschäftigen.
Das verliert alles dann seinen Schrecken, auch so Releases einzuspielen.
Und am Ende merkt man, dass man tatsächlich also nicht nur schneller wird, das heißt, mehr Value zu seinen Kunden bekommt,
mehr Qualität zu seinen Kunden bekommt, sondern auch betriebswirtschaftlich relativ schnell eine Rechnung aufstellen kann, die zu Kosteneinsparungen führt.
Okay.
Also ich habe für mich jetzt mal mitgenommen, Fachkräftemangel als Stichwort.
Also wertvolle Ressourcen kann ich viel sinnvoller nutzen, wenn ich natürlich die sinnlosen oder einfachen manuellen Tätigkeiten automatisiere.
Und daran schließe ich eben den anderen Punkt an.
Weniger Fehler, mehr Qualität, indem ich einfach routine Tätigkeiten automatisiere.
Gibt es noch ein paar andere Punkte, die man da so nennen könnte?
Die Punkte, die wir jetzt ja haben, die kann man ziemlich genau beziffern nach den Betriebskennzahlen des jeweiligen Unternehmens.
Diese Schnelligkeit, glaube ich, oder der schnellere Umsetzung von Noten.
Neue Anforderungen, das kann man jetzt nicht in Zahlen fassen, aber ich glaube mal, der Markt fordert das einfach.
Ich kann mir als Unternehmen heute nicht mehr leisten oder fast nicht mehr leisten, der Zweite zu sein.
Also wenn ich mir heute Beispiel, ich habe Kunden wirklich, die vertreiben auch sehr viel über ein Online-Business und die sind im Wettbewerb.
Und die sagen, wenn jetzt ein gewerblicher Kunde was bestellt,
also in einem Großhandel und der Shop ist für den nicht zur Verfügung, dann geht er einen Shop weiter zum Wettbewerb und bestellt sich das Bauteil da.
Und wenn sich da was verändert, die Anforderung schneller umzusetzen, es wird mehr ein Wettbewerbsvorteil beziehungsweise Nachteil,
wenn ich mich nicht darauf einlasse, auch diese Geschwindigkeit aufzunehmen.
Die englische Sprache, die erlaubt ja in kurzen Worten darzustellen, was wir im Deutschen oft mit bezeichnen.
Und sehr lange Sätzen beantworten müssen.
Also ich sage oft, wenn ich sage über DevOps, was ist das eigentlich, dann sage ich, das hilft einfach, innovate faster.
Das ist eines der Stichworte, also wirklich Innovation schneller zum Endbenutzer zu bringen.
Und das dann eben auch mit einem sicheren Betrieb.
Denn die Innovation allein hilft ja nicht, wenn sie nicht stabil läuft.
Natürlich, definitiv.
Genau.
Und hier sagt man ja auch, also wenn man in kleinen Portionen Innovationen,
also zum Kunden bringt, also dass man, also fail fast und fix fast.
Das heißt, wenn man kleine Veränderungen zum Kunden bringt und merkt, das hat nicht zu dem Effekt geführt,
dann kann man sich auch schnell wieder zurückfahren oder korrigieren.
Dieses Feedback orientierte.
Wenn man drei Monate lang entwickelt hat, bringt ein Produkt oder eine Funktionalität zum Kunden,
der sagt, das ist es nicht, was ich eigentlich wollte, dann hat man schon drei Monate Zeit und Geld in den Sand gesetzt
und braucht.
Und das dauert auch wieder sehr lange, um das zu fixen.
Ja.
Kann ich nicht rechnen.
Das ist auch an vieler Seite an Kunden bestätigt worden.
Die Fachbereiche oder die, sage ich mal, über die die Business-Anforderungen an die IT gehen,
die akzeptieren die langen Release- oder Change-Zyklen im SAP auch nicht mehr.
Die Anforderungen müssen viel schneller umgesetzt werden und in höherer Komplexität
und mit mehr neueren Technologien im Zusammenspiel.
Gerade die Komplexität und dieses, wie heißt das, Vaku?
Daniel, hilf mir, Vuku?
Vuku-Konzept?
Vuka.
Vuka, Vuka.
Genau, danke.
Das lässt sich, glaube ich, jetzt mit den bewährten oder mit den bisher vorherrschenden Abläufen nicht mehr bewältigen.
Jetzt haben wir eben die Vorteile angesprochen, die auf der Hand liegen.
Also du hast ja auch gesagt, Franz, ein paar Sachen kann man rechnen und ein paar Sachen ergeben sich einfach und liegen auf der Hand.
Die kann man jetzt vielleicht nicht mit einem…
Mit besonderen Kennzahlen ausrechnen, aber die liegen auf der Hand.
Gibt es denn auch Hürden?
Also wenn es so einfach wäre und so sinnvoll, dann könnten wir es ja gleich machen.
Wo sind wirklich Hürden, technisch gesehen, organisatorisch gesehen?
Eine große Hürde natürlich ist ein großes zentrales SAP-System,
was sehr viele Prozesse integriert und auch über mehrere Systemlandschaften hinweg Satellitensysteme mit einbindet.
Hier das natürlich in ein…
In einem schnellen Testprozess ohne großen Implementierungsaufwand von Automatisierungslösungen zu kriegen.
Das ist natürlich eine Riesenhürde.
Ja, auch erstmal die Komplexität zu strukturieren und auch inhaltlich zu erfassen, damit ich Schritte definieren kann, diese zu automatisieren,
ist natürlich ein großer Schritt und viel Aufwand dahinter erstmal.
Ja, okay.
Und deshalb empfehlen wir immer, wirklich klein anfangen.
Ja, okay. Und deshalb empfehlen wir immer, wirklich klein anfangen.
Und erfolge haben, weil gerade wenn man sich sofort an diese Integrationstests und Regressionstests im SAP ranmacht,
dann ist der, sag ich mal, der Bissen auch zu groß für den ersten Schritt, um die Erfahrungen zu sammeln.
Ja, also letztendlich die Hürde oder die größte Hürde ist, glaube ich, auch wirklich das Mindset.
Also eine Innovationskultur und eine Change-Kultur überhaupt erstmal zu etablieren.
Das heißt, es muss schon auch von oben her gewollt sein.
Es reicht definitiv nicht, den Mitarbeitern ein Buch in die Hand zu drücken, Scrum Revolution oder wie auch immer, nach dem Motto, und jetzt werdet agil.
Sondern das ist tatsächlich in vielen kleinen, also so agile Stellhebel umzulegen, um eine intrinsische, sag ich mal, Motivation in den Mitarbeitern hervorzurufen,
dass sie mit einer neuen Arbeitsweise, mit mehr Collaboration, mehr Sharing und natürlich auch einem weitestgehenden Automatisierung von monotonen Abläufen
letztendlich ihre Arbeit machen können.
Und das ist ein Zusammenspiel, ja, und auch eine Gratwanderung zwischen Führung, Lernbereitschaft von Mitarbeitern, sich gegenseitig Informationen zuspielen und sich gegenseitig schulen und Wissen abholen.
Und letztendlich die ganze Arbeitsweise muss sich verändern.
Und ich glaube schon, dass das eine große Hürde in Unternehmen darstellt.
Und wie der Franz gesagt hat, das kann man nicht.
Das kann man nicht erreichen, indem man mit dem Big Bang reingeht ins Unternehmen und sagt, so, wir werden jetzt agil von heute auf morgen.
Das muss sich langsam etablieren, weil es von oben gerollt ist und weil man erste Anfangserfolge sieht, das sich rumspricht und der Kunde und die Abteilung und die Menschen dann merken,
dass man so letztendlich ja wettbewerbsfähig bleibt, die Kundenzufriedenheit erhöht und die internen Abläufe letztendlich auch profitieren.
Also es ist wirklich ein Prozess, der hier eingeleitet werden muss.
Und deswegen habe ich am Anfang gesagt, Religion.
Also man muss auch dran glauben.
Wenn ich mir das so überlege, das passt natürlich ganz klar, dass ich erst mit schnellen, mit kleinen Schritten machen muss, schnelle Erfolge.
Denn würde ja nicht gut zusammenpassen, wenn ich sage, liebes Business, wir wollen schneller werden und jetzt gehen wir erst mal zwei Jahre in Klausur.
Also ich muss ja diese Schnelle gleich von Anfang an zeigen und von Anfang an zeigen, dass ich auch das Thema Schnelligkeit verstanden habe und auch schnell das Feedback bekommen will.
Genau.
Und so, ich sage mal, genau das ist so der Mindset im SAP.
Man macht sehr, also man ist sehr genau, man muss sehr genau sein.
Ja, einfach weil die Verantwortung, das, sage ich mal, das Erfolg des Unternehmens ja auch auf der Plattform, was die Geschäftsprozesse angeht, ein bisschen lastet.
Aber wenn ich quasi auf diese heranke, mich quasi mit dem, mit meinem alten Verhaltens, mit meinem alten Verhalten an das Thema annähere, komme ich damit auch nicht weiter.
Aber was man, was man zusätzlich.
Was man zusätzlich machen sollte, Fehler zulassen, das ist ganz wichtig und gerade in so einem geschäftskritischen Umfeld muss man das Top-Management und halt auch das mittlere Management mit reinholen und ihnen klar machen, dass die müssen das aushalten, wenn man, wenn man sagt, man geht so einen Weg, man will das Unternehmen beschleunigen, agiler werden, dass diese Fehlerkultur und Fehler zulassen akzeptiert wird.
Und dann heißt es, also im schlimmsten Fall ist halt mal ein Fehler in der SAP-Produktion.
Das kann ich natürlich nicht dauerhaft machen, aber die werden natürlich auch passieren.
Und das Schlimmste ist dann, wenn man dann auf dem Weg dahin beim ersten Fehler das Management dann sofort einknickt und dann halt wieder eine Rolle rückwärts macht.
Das kann auch mal.
Wenn man sich vielleicht mal die Mühe macht, zu überlegen, was ist denn in fünf oder in zehn Jahren, ja.
Wenn man uns diese Vorstellung, die SAP ja selbst hat, mal tatsächlich zu eigen machen.
Alle unsere Systeme, die Kernsysteme sind bei SAP.
Wir nutzen nur noch Cloud-ERP, weil es eben diese notwendige Flexibilität, Pay-Per-Use und Anpassungsfähigkeit bietet.
Und auf der anderen Seite nutzen wir über die SAP-Cloud-Plattform eine Entwicklungsumgebung, mit denen wir ganz schnell neue Apps, neue Funktionen, neue Applikationen zur Verfügung machen können.
Spätestens dann ist ja das Ganze, dieser ganze agile Gedanke, dieser ganze DevOps-Gedanke im Prinzip fest vertratet in der IT, die wir nutzen.
Das heißt, da spätestens müssen alle quasi mit diesen Methoden und mit dieser Denkweise und Kultur eigentlich vertraut sein.
Also warum machen wir heute nicht den ersten Schritt und fangen mit den bestehenden Systemen an, diese Kultur zu etablieren, diese Automatisierungsmöglichkeiten zu nutzen und letztendlich die Leute, die Menschen vorzubereiten auf das, was in den nächsten fünf bis zehn Jahren kommen wird.
Ja, und da sieht man dann, dann ist ja Technologie oder technische Veränderungen sind dann der Treiber auch für organisatorische Veränderungen.
Ich habe einen Kunden, der selber auch gerade für sich, der auch in dem Betriebsumfeld ist, der in einem Konzernumfeld das Thema Microsoft eben betreut und der ist jetzt aufgefordert worden, MS-365 in der Cloud für den Konzern nutzbar zu machen, mit einem sehr ambitionierten Zeitplan.
Und der hat gesagt, das ganze Thema kriegen wir nur gestemmt, also nicht nur das Ausrollen, sondern auch den Betrieb nachher, wenn wir anders vorgehen.
Und der setzt eben auch entsprechende Teams auf. Das heißt, da ist eben genau durch den Lieferanten, durch die Technik, in diesem Fall der Microsoft, angetriggert worden, auch organisatorisch Dinge zu verändern an der Stelle.
Und das finde ich schon spannend. Ich bin ja als Betriebswirt eher derjenige, der sagt, naja, die Technik sollte das nicht treiben, aber wenn es in diesen Weg geht, habe ich damit auch kein Problem.
Ja, es ist auf jeden Fall ein Zusammenspiel. Also die Technik, also die technischen Möglichkeiten, die sind schon ein Problem.
Ein Motor, ein Antrieb. Und wie ich sagte, auch die Anforderungen. Das heißt, das, was der Kunde will. Wenn der Kunde immer schneller, beziehungsweise der Wettbewerb immer schneller quasi neue Ideen, neue Funktionen zur Verfügung stellt, dann kann ich dem nicht hinten dranbleiben.
Also wir müssen das vor diesem Hintergrund sehen. Also wir kennen das auch, wir nennen das immer diese Amazon-like User Experience. Das heißt, wenn ich heute gewohnt bin, eine gleichbleibende Qualität, jedes Mal, wenn ich einen Bestellprozess mache,
dann kann ich das tracken, dann kriege ich das am nächsten Tag. Das heißt, ich bin dran gewöhnt, dass eine gewisse Servicequalität und auch Schnelligkeit und ja, Flexibilität an der Stelle geliefert wird.
Und wenn ich dann in die Unternehmen reingucke, dann ist man weit entfernt von dieser User Experience. Da ist die Qualität eben nicht gleichbleibend, weil das kommt auf die Laune des Mitarbeiters an, dem man gerade eine Mail geschickt hat, ob er jetzt das erledigen könne.
Ja, und wenn man das natürlich in Services und auch in der Technik, dann ist das eine gewisse Qualität.
Und wenn man das auch in Software, also Automatisierung und einer anderen Art der Zusammenarbeit, ich sage ja, also mit Slack oder Teams einfach sich gegenseitig einbetten in die Aufgaben und informieren, dann ist das viel einfacher. Dann wird das, diese User Experience eben auch innerhalb der Unternehmen plötzlich zum Standard.
Ja, vielleicht dann noch ein Thema. Wir haben jetzt ja ziemlich viel beleuchtet. Wir haben auf das Thema Mindset abgehoben. Wir haben Automatisierung angesprochen. Wir haben Vorteile geklärt, Rahmenbedingungen.
Wenn ich jetzt als Unternehmen im SAP-Umfeld jetzt dann sagen würde, okay, jetzt möchte ich DevOps starten. Was sind da so eure Tipps oder was sind auch eure Erfahrungen? Wo haben Unternehmen Vorteile erzielt, die man an der Stelle auch weitergeben könnte?
Ja, wieder die kleinen Schritte. Man sucht sich einzelne, also in dem, ich sage mal, im Change Management Prozess Punkte aus, die man stellen, die man mit einfachen Mitteln automatisieren kann.
Man schaut sich auch nochmal die Bereich des Approvals an. Was der Daniele meinte, haben wir, ich sage mal, Change-Typen, die jetzt nicht von zwei oder drei Leuten approved werden müssen, sondern, ich sage mal, die, wo wir so eine Routine und Qualität schon haben, dass wir nur noch in, ich sage mal, bei bestimmten Exceptions ein Approval brauchen.
Aber wenn alles in einem gewissen Rahmen läuft, kann ich das durchautomatisieren, also bei unkritischen Projekten kleineren Anpassungen oder Anpassungen, die regelmäßig gemacht werden.
Ja, die haben ja auch, sind ja auch weniger fehleranfällig und ich dann sage, ich mache nur noch, sage ich mal, manuelle Checks oder tiefere Tests bei Objekten, wo ich weiß, oh, da haben wir jetzt seit zwölf Monaten keine Änderungen mehr vorgenommen, vielleicht die Dokumentation nicht vollständig, dass ich mich hier auf meine bewährten Abläufe verlasse und aber alles, was ich sehe, was regelmäßig wiederkehrend ist, anfange zu automatisieren und das geht auch im SAP.
Dafür gibt es die Tools.
Da ist die Erfahrung da, das lässt sich auch kundenspezifisch entsprechend anpassen.
Also, ich will das vielleicht nochmal so zusammenfassen.
Das hatten wir im Laufe des Gesprächs schon mal, da hast du dir gesagt, geht das überhaupt?
Ich habe letztlich einen Spruch gesehen auf einer Tür, da stand dann, alle sagen, das geht nicht.
Dann kam einer, der wusste das nicht und hat es einfach getan.
Und das kann ich den Unternehmen einfach sagen.
Das kann ich dem Unternehmen einfach nur nahelegen, es einfach auszuprobieren.
Diese Möglichkeiten, die heute schon mit Software, aber auch vielleicht mit einem agilen Coach in der Entwicklungsabteilung sowieso schon sehr stark sich bewährt haben, auch eben zu erweitern auf die Betriebsabteilungen, auf das gesamte Unternehmen und letztendlich in einem Prozess diese Kultur, diese Innovationskultur, diese Freiräume zu schaffen.
Um mehr Output am Ende, also Value für den Kunden auch zu generieren.
Es funktioniert, es funktioniert.
Man muss es einfach nur, man muss damit einfach nur starten.
Und dann noch genügend Rückgrat und Zeit mitbringen, weil es funktioniert sicherlich erstmal nur in kleinen Schritten.
Das heißt, auch die kleinen Schritte brauchen dann die Zeit und die Erfolge insgesamt brauchen eben auch ihre Zeit.
Man hat auch erstmal Rückschritte.
Ja, natürlich braucht man eine gewisse Beharrlichkeit, Geduld.
Wenn man Dinge anders macht, in der Retrospektive wird man dann feststellen können, also welche Fortschritte man am Ende gemacht hat oder dass man vielleicht auch nur noch überlebt als Unternehmen, weil man gelernt hat, schneller und agiler, also anpassungsfähiger zu werden.
Das ist leider, wir kennen ja auch die Namen der Unternehmen, die von ihrer Haltung her, sage ich mal, diese Geschwindigkeit, die, also auch die Innovationszyklen, die wir jetzt,
die wir jetzt in der IT kennen, nicht überlebt haben, also weil sie einfach zu lange an alten Dingen festgehalten haben.
Und das kann für die Zukunft schon der entscheidende Wettbewerbsvorteil sein.
Wir kommen langsam zum Ende.
Das ist so die Zeit, die wir auch immer so, nicht immer so vorgeplant haben für die Dauer von so einem Podcast.
Gibt es noch irgendetwas, was ihr in den letzten 45 Minuten nicht angesprochen habt, was noch wichtig ist, was euch noch auf dem Herzen liegt?
Ja, ich kann eben nur empfehlen, auch im SAP-Umfeld, ja, wagt den Schritt.
Es ist möglich, es ist kein, auch wenn es teilweise ein steiniger Weg ist, aber ja, nach vorne schauen, nicht zu sehr drauf verlassen und sagen,
wir haben das seit 20 Jahren so gemacht und deshalb können wir es nicht ändern.
Es funktioniert definitiv auch im SAP-Umfeld.
Es erweitert für die Leute, die aus der SAP-Welt kommen, wie für mich war es ein ganz anderer, ich sage jetzt nicht keine Offenbarung, aber mal einen ganz anderen Blick, ja.
Man hat doch sehr lange, gerade in den SAP-Organisationen, so ein bisschen im eigenen Saft geschmort, möchte ich sagen, ja.
Und die Welt hat sich da draußen rum gerade in was, was Schnelligkeit und Methoden angeht, doch deutlich verändert.
Ja.
Und da kann die SAP-Welt einiges lernen.
Und ich glaube,
es tut Ihnen gut, sich das zunutze zu machen, welche Möglichkeiten es sich, sage ich mal, so spezielle, so sage ich mal, in den letzten 15 Jahren außerhalb des SAP-Umfeldes sich ergeben haben, ja.
Ja, okay.
Also für mich ist immer überraschend oder erfreulich, wenn ich sehe, wie sich Microsoft verändert hat.
Also das, was man jetzt heute von Microsoft sieht oder merkt, das ist ja nicht mehr das, was man vor fünf oder vor zehn Jahren noch gewohnt war.
Und ich habe den schönen Artikel gelesen, Microsoft, das neue Apple.
Das ist natürlich vielleicht für Microsoft nicht das höchste Lob, aber aus meiner Sicht ist natürlich schon ein Zeichen, wenn wirklich Fachjournalisten mit einem klaren Blick auf die Inhalte auch wirklich das entsprechend darstellen.
Also insofern, vielleicht ist SAP ja in ein, zwei Jahren das neue Microsoft und das neue Apple.
Ja, das werden wir dann sehen.
Also ich denke schon, dass SAP hat auf jeden Fall das verstanden, dass das notwendig ist, dass sie Mittel und Tools und Software, also Lösungen,
dem Kunden an die Hand geben müssen, um eben in dieser neuen Welt auch bestehen können, in dieser volatilen Welt, die geprägt ist von Unsicherheit, von der Notwendigkeit, sich schnell adaptieren zu müssen.
Das Problem von SAP ist, dass sie halt doch sehr lange schon im Markt ist und diese etablierten Systemwelten, Denkweisen, Silos, die wir ja alle angesprochen haben im Podcast, nicht einfach so von heute auf morgen weg zu radieren sind.
Und in jedem Change-Prozess ist ja das Problem, dass jeder nur mitmacht, wenn er sich selbst sicher darin fühlt, also dass er sich nicht selber wegrationalisiert sozusagen.
Und das ist schon ein Dilemma, welches eben auch nur über die Führung oder eben über den Druck, der auch vom Markt herkommt, zu steuern ist.
Und wie gesagt, Microsoft hat es geschafft. Sie haben sich komplett verändert. Viele Kunden, egal in welchen Branchen, in welchen Tätigkeiten sie unterwegs sind,
müssen sich komplett verändern.
Ja, dem kann man sich nicht entziehen. Desto eher man das akzeptiert und nur noch die Frage stellt, wie verändere ich mich und nicht, nein, das brauche ich jetzt erstmal nicht, umso einfacher wird dieser ganze Wandel.
Ja, okay. Also, dann bedanke ich mich für eure Unterstützung an der Stelle, auch für das schnelle Einspringen, Daniele, für den erkannten Kollegen an der Stelle. Mir hat das viel Spaß gemacht. Es sind 50 Minuten jetzt vorbei.
Es kommt mir gar nicht so vor. Also, insofern vielen Dank für die, ich sage mal, spannende Unterhaltung, für die interessante Unterhaltung.
Ja, mir hat es auch viel Spaß gemacht. Vielen Dank, Dirk.
Ich schließe mich an. Danke, Dirk.
Danke.