Transcript

Matthias Uebel: Herzlich Willkommen zu unserer neuen Ausgabe, zum Podcast Business-Transformation mit S/4HANA. Heute wollen wir uns unterhalten, Markus und ich, über die Dos und die Don’ts einer S/4HANA-Einführung. Was berechtigt uns dazu? Für diejenigen, die uns noch nicht kennen: Wir sind die Autoren des Buches „Business Transformation mit S/4HANA“. Wir kommen beide aus der Change-Beratung und haben uns in den letzten Jahren sehr intensiv mit S/4HANA-Transformation beschäftigt. Nicht allein aus der Sicht der Technik, sondern vor allen Dingen aus der Perspektive Organisation und Change-Management. Markus, vielleicht magst du dich ganz kurz vorstellen.

Markus Czeslik: Ja, gerne. Markus Czeslik, ich bin seit mehr als 13 Jahren im Change Management tätig an der Schnittstelle Business Transformation, Change-Kommunikation, Organisationsentwicklung in verschiedenen Branchen. Seit vier Jahren Kollege von Matthias bei mgm, wo der Schwerpunkt etwas stärker in Richtung Digitalisierung gegangen ist. Und da vor allem auch S/4HANA-Projekte. Wir haben zusammen schon einige Kunden begleitet. Und die Erkenntnisse sind dann auch in das Buch eingeflossen, von dem du gerade gesprochen hast, und auch in ein Framework. Darüber wollen wir heute sprechen. 

Matthias Uebel: Ja, vielleicht noch zu mir ganz kurz. Matthias Uebel, ich habe mich in meiner Vergangenheit, mein Leben vor S/4HANA gibt es auch, mit Strategiebildungsprozessen beschäftigt, mit Organisationsentwicklung, Kulturwandel. Heute helfe ich den Unternehmen auf die Erfolgsspur und das durchaus auch noch vor der Entscheidung einer S/4HANA Transformation. Insbesondere dann, wenn sich Unternehmen für einen hochkomplexen Greenfield-Ansatz entscheiden, der einen großen, organisationalen Wandel mit sich bringt. Und darüber wollen wir auch heute sprechen. Viele von den Hörern, die auch schon Erfahrungen haben mit S/4HANA und eine Einführung begleitet haben, wissen, wie wichtig es ist, sich von liebgewonnenen Prozessen zu verabschieden, den gesamten Geschäftsbetrieb zu überdenken, Stakeholder mitzunehmen oder die richtige Strategie zu finden. Die erste Phase fängt an mit einer gemeinsamen Orientierung des Managements. Wir nennen das auch in unserem ADDVALUE Transformation Framework die Alignment-Phase, die SAP übrigens in ihrem Umsetzungs-Framework Activate nicht berücksichtigt.

Da geht es um die Business-Sicht der digitalen Transformation. Was ist unser gemeinsamer digitaler Leitstern? Diese Frage beantworten wir. Damit ist ein Abbild der kollektiv geteilten Vorstellung von Zweck und Richtung der Digitalisierung gemeint. Und da sind wir noch gar nicht bei einer S/4HANA Einführung. Da geht es eher um die Priorisierung von strategischen Zielen und den Gestaltungsinitiativen. Und dann natürlich auch um SAP, um S/4HANA und den Potenzialen, verbunden mit der Frage, inwieweit jetzt SAP hier in die Digitalstrategie einzahlt. Und das sozusagen als grober Abgleich der Anforderungen mit den Chancen und Risiken von SAP, und das auf allen Ebenen. Es geht darum, erstmal ein umfassendes Verständnis für eine Business-Transformation zu erzeugen, insbesondere wenn es um Technologie geht. S/4HANA, was ist das eigentlich? Was sind die Möglichkeiten von S/4HANA? Was bedeutet eine End-to-End-Betrachtung von Prozessen? Was bedeutet eine prozessorientierte Organisation? Und was hat es mit den Veränderungen in den Arbeitsweisen auf sich? Und ich denke mal, ein erstes Don’t wäre zum Beispiel, wenn man SAP allein als Ziel definiert, also SAP-Einführung ist jetzt nicht das Ziel und auch nicht die hohe Effizienz, oder S/4HANA besonders kostensparend einzuführen. Denn S/4HANA ist immer auch ein großes Programm, was mit vielen Kosten natürlich und mit vielen Aufwänden verbunden ist. Deswegen ist das Ziel eher, das Business voranzubringen und die Vorteile von SAP zu nutzen.

Markus Czeslik: Darf ich da kurz reingehen? Genau, ich möchte bestätigen, was du gesagt hast. Du hast viel von Potenzialen gesprochen und ich glaube, das ist von der Denke her ganz wichtig am Anfang, gerade diese Chancen in den Vordergrund zu stellen und nicht, es als technische Notwendigkeit zu sehen. Das Business auch frühzeitig ins Boot zu holen. Und welche Potenziale können da gehoben werden? Mehr in Möglichkeiten denken, in Chancen. Da hilft es auch, einen Helikopterblick einzunehmen. D.h. nicht nur die Binnenperspektive: Was haben wir letztendlich in der Organisation davon, sondern auch den Kunden mit ins Boot zu holen. Beziehungsweise, was wollen denn unsere Kunden überhaupt? Wie sieht das ganze Ökosystem aus, in dem wir uns bewegen? Wie verändert sich unsere Branche? Das wären Fragen, die wir am Anfang stellen und gemeinsam mit dem Kunden erörtern. Den Blick auch aus der Binnenperspektive herauszunehmen auf die eigene Kundenwelt, die ja einer ganz anderen Dynamik unterliegt. Und du hast es gesagt, das sind dann wirklich die großen Fragen, die man erarbeitet, die strategischen Leitlinien. 

Matthias Uebel: Genau. Gerade, weil du es schon angesprochen hast: Innensicht, Außensicht. Wenn man jetzt nochmal auf die Innensicht schaut: Wir kennen ja alle Organisationen, also klassisch organisierte Unternehmen, wo wir ein sehr starkes Siloverhalten vorfinden oder ein starkes Herrschaftswissen etabliert ist. Da geht es darum, dem auch ein wenig entgegenzuwirken, beispielsweise durch Förderung von Kollaboration. Dass wir sehr viele Workshops durchführen oder vielleicht eine Plattform haben, eine Kollaborations- oder eine Lernplattform implementieren, wo wir Themen zur digitalen Transformation diskutieren können. Diese Transparenz, dieser Austausch, gerade auch am Anfang unter den Führungskräften, ist hier besonders wichtig.

Markus Czeslik: Auch in der Kommunikation kann man am Anfang leider sehr viel falsch machen. Wenn man da nur aus der Defensive heraus kommuniziert, dann gewinnt man sicherlich keine Fans, vor allem nicht unter den Führungskräften, die man da schon ganz am Anfang braucht. Man kann, allein schon bevor das Programm überhaupt angefangen hat, schon einiges falsch machen. Und als ersten Punkt würde ich da vor allem sehen, dass man gar nicht die richtigen Leute mit im Boot hat. Meist werden die üblichen Leistungsträger eingebunden, bei denen dann noch drei Programme nebenbei laufen. Da also die richtige Mannschaft erst einmal aufzusetzen, die Wissensträger, die jetzt vielleicht nicht sofort „Hier!“ schreien. Aber von denen man weiß, dass sie in diesem Umfeld einiges an Know-how haben und sehr wichtig sein könnten in diesem Programm. Die frühzeitig mit einzubinden.

Und wenn ich schon Kommunikation gesagt habe, da wird der Flurfunk sehr, sehr früh losgehen, schon in dieser Phase. Das wird gern unterschätzt, dass sich da schnell auch die Sorge verbreitet, Kosteneffizienzprogramm – sowas geht sehr einfach durch die Organisation, dass das eher negativ konnotiert ist. Wie gesagt, nicht aus der Defensive heraus kommunizieren, sondern eher mit den Vorteilen und Chancen für die gesamte Organisation frühzeitig rausgehen. Wobei natürlich der erste Kommunikationsanlass, der muss gut gewählt sein. Man muss da sehr genau abwägen, wann geht man breit in die Kommunikation? Für eine sehr breite Kommunikation ist dieser Zeitpunkt natürlich noch etwas früh, weil vieles einfach nicht bekannt ist. Aber selbst das kann man kommunizieren: Was ist bekannt, welche Entscheidungen sind schon getroffen worden und welche Entscheidungen werden noch getroffen und wann? Was braucht es dafür auch an Daten, an Fakten, an Informationen, um diese Entscheidung treffen zu können?

Matthias Uebel: Ich bin da bei dem Gedanken, den du jetzt gerade beschrieben hast, Kommunikation. Ich würde noch einen Schritt zurückgehen. Denn gerade was die Zusammenarbeit zwischen dem Business und der IT angeht, da braucht es auch eine gewisse Vorarbeit. Und wir machen ja die Erfahrung, dass gerade jetzt, in unseren Projektanfragen, die IT zu uns kommt und sagt: „Könnt ihr uns helfen? Wir haben vor, eine S/4HANA-Transformation oder Migration durchzuführen, und wir sehen uns da in einer etwas schwierigen Rolle, also in einer, sagen wir mal, klassischen Rolle.“ Das ist häufig so, dass IT als Dienstleister betrachtet wird, nach dem Motto, die IT soll die Welt retten und ist für die gesamte IT zuständig. Ist sie natürlich, aber man muss sagen, eine S/4HANA-Transformation ist kein IT-Projekt, kein reines IT-Projekt. Sondern es geht eher darum, gemeinsam mit dem Business zu einer gemeinsamen digitalen Agenda zu kommen. Also schon im Vorfeld einer solchen S/4HANA-Transformation das Business mitzunehmen und dem Business, aus Sicht der IT, auf Augenhöhe zu begegnen. D.h. gemeinsam Business-Prozesse zu optimieren, aber auch die entsprechenden geeigneten Applikationen zu identifizieren und entsprechend bereitzustellen. Nochmal: Wichtig ist, S/4HANA ist nicht die Lösung für die strategischen Problemstellungen, Aufgaben oder Zielstellungen, sondern liefert einen wichtigen Beitrag zur gesamten Transformation. Wenn wir das jetzt mal umdrehen, gerade, was diese Anfangsphase angeht, wenn wir fragen: Was sollte man auf jeden Fall vermeiden? Was fällt dir dazu ein?

Markus Czeslik: Ja, die Dinge, die ich schon gesagt habe, die richtigen Leute an Bord holen. Vielleicht auch, das Thema nicht auf die lange Bank schieben, weil eine extreme Dynamik in den verschiedensten Branchen herrscht. Wirklich sich darüber klar sein: Zu Beginn können nicht alle Fragen beantwortet werden, das muss man gemeinsam erörtern. Und da bringt es nichts, Vorprojekt und Vorprojekt und Konzept und Konzept aneinanderzureihen, sondern sehr früh alle an Bord holen. Klar, Investitionen klären, das Budget klären und dann wirklich schauen: Was sind Ressourcen, die uns unterstützen können? Einerseits haben viele auch negative Vorerfahrungen mit vergleichbaren Programmen. Davon muss man sich dann auch lösen oder überlegen, wie man es denn anders angehen kann. Und gleichzeitig gibt es natürlich, gerade in großen Organisationen, diesen Programm-Overload, wo man nicht einfach nochmal wieder ein neues S/4HANA-Projekt drüberstülpen kann. Das muss wirklich gut durchdacht und geplant sein. Aber möglichst früh anfangen mit diesen Überlegungen und sich vor Entscheidungen nicht drücken, sondern die Dinge angehen.

Matthias Uebel: Kommen wir zu den nächsten Phasen. Wir haben die jetzt mal zusammengefasst. Im ADDVALUE Transformation Framework sprechen wir von der Develop-Phase bis zur Verify-Phase. Wenn man das jetzt auf das SAP-Activate-Modell spiegelt, ist das die Discover-, die Prepare- und die Explore-Phase. Und das sind gewissermaßen alles die Tätigkeiten bis zur eigentlichen technischen Umsetzung, die dann als Realize-Phase bezeichnet und entsprechend fortgesetzt wird. Was ist der Inhalt dieser drei Phasen? Das Aufstellen des Projektteams, eine vernünftige Programmplanung, das Prototyping, eine technische Transitionsplanung und vor allem die Fit-Gap-Analyse, das Delta Design, also die Abweichung vom Standard. Das ist auch der Schlüssel zum technischen Projekterfolg, wo definiert wird, wie die Kundenanforderungen an das S/4HANA-System denn aussehen, beziehungsweise wie hoch der Deckungsgrad mit den SAP Standardprozessen ist. Und parallel dazu, das ist auch unsere Aufgabe als Change-Manager oder aus der Perspektive des Change-Managements, geht es darum, diesen Prozess der Transformation zu begleiten. Wir wissen, wie erfolgsrelevant Change Management ist, vor allem in einer Greenfield-Einführung. Und das wissen auch viele Kunden von uns. Da geht es im Wesentlichen darum, erstmal die Mitarbeiter, die Führungskräfte auf die Transformationsreise schrittweise vorzubereiten, sie mitzunehmen, gewissermaßen an das System auch heranzuführen. Vor allen Dingen sie vorzubereiten auf ganz neue Arbeitssituationen, die sich dann ergeben. Es wird sich viel verändern, ob das Rollen sind, die Aufgabenstellungen, die Verantwortungsbereiche.

Fangen wir an mit den Dos und den Dont’s zu dieser Phase. Da sollte man aufsetzen, wo das Unternehmen und die Mitarbeiter, die Führungskräfte stehen, das heißt sehr stark auch das Thema organisationale Readiness, die Veränderungsbereitschaft der Organisation zu betrachten, schon in einer sehr frühen Phase, wo man noch gar nicht über die Programm-Readiness spricht und es erst um vorbereitende Tätigkeiten geht. Aber wo man sich schon anschaut: Wie weit ist denn meine Organisation in Bezug auf eine solche Veränderung, also signifikanten Wandel, vor dem wir hier stehen?

Markus Czeslik: Genau da sind wir sehr stark in einem analytischen Teil, tatsächlich auch Analyse der Change Impacts. Was verändert sich denn in welcher Dimension im Alltag der Anwender? Da hilft auch immer die Frage: Was passiert, wenn nichts passiert, wenn wir nichts machen? Also einen gewissen Leidensdruck erhöhen oder aufzeigen, damit auch Bewegung entsteht. Ich denke, aus Führungssicht ist da einiges zu tun. Die müssen auch diese klassische Change-Kurve bedienen können, Widerstände aufnehmen, mit Information füllen, gewisse Tiefs, die es unweigerlich geben wird. Wobei ich immer sage: Eine Führungskraft ist gar nicht in der Lage, Menschen zu motivieren. Das muss aus ihnen dann selbst herauskommen. Aber sie ist sehr wohl dazu in der Lage, Menschen zu demotivieren. Zum Beispiel, indem sie ihre Wissensträger nicht einbezieht, indem sie eher Rückmeldungen ignoriert oder kritische Fragen überhört. Oder wenn sich strategische Botschaften widersprechen innerhalb des Managements. Es kann auch sein, dass Abteilungen in ganz unterschiedliche Richtungen wollen. Da gibt es ja auch eine Vernetzung untereinander, einen Austausch – das muss man immer berücksichtigen. Wenn das Management nicht mit möglichst einer Stimme spricht, wird es einfach schwierig mit der Motivation. In einigen Unternehmen gibt es Change-Botschafter, Change Agents schon aus anderen Projekten, die man dann mit einsetzen kann. Solche Rollen gehen immer in zwei Richtungen: Wir nutzen diese Netzwerke natürlich vor allem als Informationsweg, als Kommunikator in die Organisation. Wo steht das Projekt gerade? Was muss der Anwender letztendlich wissen? Aber dann auch als Feedbackgeber: Wo treten gerade Probleme auf? Wo sind viele Nachfragen? Wo herrscht Skepsis? Dass man das Ohr an der Schiene hat, damit man wirklich frühzeitig diese Stimmung aufnehmen und zurückspiegeln kann. Um dann auch gegenzusteuern oder bestimmte Maßnahmen zu intensivieren, Kommunikationsmaßnahmen, Workshops durchzuführen, wo offene Fragen zu klären sind.

Matthias Uebel: Ich denke, um auch eine intrinsische Motivation bei den Mitarbeitern zu steigern, gehört dazu, dass wir, aus Sicht des Change Managements, dafür sorgen müssen, dass wir einen hohen Grad der Beteiligung an diesem Projekt haben und einen starken Austausch zwischen den Key Usern, zwischen den Usern, zwischen den Führungskräften. Das muss man ein Stück weit anstoßen. Ansonsten kommt da sehr viel von den Leuten selbst und von den Mitarbeitern, die neugierig sind, die Fragen haben. Da braucht man Experten, die dann diese Fragen letztendlich beantworten. 

Es gibt vielleicht noch einen anderen Punkt, der für uns besonders wichtig ist, gerade in dieser Vorphase oder besser gesagt, nach den Fit-Gap-Analysen, wo man die Abweichung der Standards feststellt und festschreibt. Das sind die sogenannten Change Impact Assessments. Und da geht es um die Frage: Was bedeutet eigentlich diese Systemanpassung für verschiedene Ebenen der Organisation? Fangen wir an mit den Prozessen. Was ändert sich an den Prozessen? Und damit sind nicht nur die Massenprozesse gemeint, sondern auch die Frage: Welche Varianten von Prozessen gibt es? Und wie groß ist die Flexibilität in ihrer Ausführung? Wir beschäftigen uns da sehr stark mit dem Bereich des Prozessmanagements und in dem Kontext natürlich mit der Organisation. Die Frage, welche Rollen, welche Verantwortlichkeiten gibt es? Wer übt sie aus? Was verändert sich dort? Welche Arbeitsweisen sind zukünftig sinnvoll? Wie arbeiten künftig die Geschäftseinheiten zusammen, auch im Hinblick auf eine End-to-End-Digitalisierung? Und welche Regeln gibt es, insbesondere in Hinblick auf die Daten-Governance? Also wie halten wir es mit der Datendisziplin? 

Markus Czeslik: Und die Vorteile nicht vergessen. Wir reden ja auch immer davon, welche Vorteile zieht man letztendlich daraus, welche Use Cases gibt es für den Anwender? Das muss man sich separat anschauen, auf die Benefits einzugehen, die zu analysieren und dann in Euro und Cent umzurechnen, was es an Zeit einspart, an Aufwänden. Darauf wird gar nicht so viel Fokus gelegt. Also wirklich nochmal die Benefits hervorheben und kommunizieren, ohne natürlich zu große Erwartungen zu wecken, zu blühende Landschaften zu versprechen. Das ist immer noch ein Thema, das meines Erachtens stiefmütterlich behandelt wird.

Matthias Uebel: Ja, absolut. Wenn wir jetzt mal uns auf die Don’t-Seite gehen, was sollte man auf jeden Fall vermeiden? Da würden mir zum Beispiel zwei Sachen einfallen. Erstens: Natürlich niemals die Mitarbeiter und Führungskräfte vergessen. Es zahlt sich aus, sich über ein ganz breites Beteiligungskonzept Gedanken zu machen. Und der zweite Punkt, der mir noch einfällt zu den Don’ts: Unterschätzen Sie nicht die Wirkung eines professionellen Change Managements, gerade was die Wirkung von Maßnahmen angeht. Es reicht nicht, einem Best Practice stur zu folgen, sondern es geht immer darum zu gucken: Wie wirken sich die Maßnahmen aus, die ich da angewandt habe? Also immer ein Review machen, immer zu schauen, wie kommen gewisse Kommunikationsmaßnahmen an? Change Management richtet sich nicht nach einem Drehbuch, sondern ist oftmals situativ, wenn ich zum Beispiel an das Stakeholder Management oder an zielgruppenspezifische Kommunikation denke. Und der Punkt ist, weil auch viele sagen: „Na gut, das kann ja auch der Programm-Manager machen“, das ist nicht so. Bei Programm-Managern richtet sich der Fokus nach Effizienz, nach Programmplanung und Umsetzung. Und der Change Manager richtet sich eher nach der Frage: „Was läuft vielleicht nicht so gut? Und wo müssen wir noch entsprechende Change-Maßnahmen anwenden?“

Kommen wir zur dritten Phase. Wenn wir das ACTIVATE Framework zugrunde legen, also von SAP das Activate Framework, da folgen jetzt die Phasen Realize und Deploy. Da geht es ja im Wesentlichen darum, die technische Konfiguration zu realisieren, möglicherweise auch agile Projektmanagement-Praktiken einzusetzen. Da geht es um die Durchführung von technischen Integrationstests, um Datenmigration, die Vorbereitung des Cut-over, auch die Vorbereitung der Infrastruktur. Da ist eine Menge zu tun auf der IT-Seite. Aber auch Lern-Designs, Trainingskonzepte entsprechend umzusetzen, Trainings-Prozesse zu organisieren. Dazu gehört auch, Lernfortschritte nachzuvollziehen. Und dann sind wir wieder bei dem Thema Change-Management, letztendlich sehr nah an den Usern, Key Usern und Trainern zu sein und entsprechend Lernfortschritte nachzuvollziehen. Natürlich auch die gesamte Qualifizierung eng zu begleiten.

Marku Czeslik: Da passiert sehr viel gerade im Kontext des Lernens. Man darf nicht vergessen, dass man die Trainings sehr, sehr früh vorbereiten muss, schon einige Monate vor GoLive muss man erst einmal den Trainingsbedarf analysieren mit den Führungskräften, die ihre Leute gut kennen. Wo sind noch Lücken? Wo kann man Teams zusammenfassen zu Schulungen? Was hat bisher in vergleichbaren Projekten gut funktioniert? Wo will man neue Wege beschreiten? Dass man nicht diese Standardtrainings anbietet, sondern möglichst die in den Alltag einbettet, sehr User-nah am Arbeitsplatz, angepasst auf sein spezifisches Profil. Es ist natürlich wesentlich mehr Aufwand, aber es führt aus unserer Erfahrung deutlich mehr zum Erfolg. Auch da die Key User einzubinden, macht Sinn, diese Schulungen vom User für andere User zu konzipieren und durchzuführen. Tandems bieten sich natürlich auch an, mit einem Key User, der das Unternehmen, die Lernkultur, seine Kollegen gut kennt. Dann auch mit einem SAP-Experten, der diesen fachlichen Hintergrund hat und in die Tiefe einsteigen kann bei fachlichen Rückfragen. Es gibt verschiedenste Möglichkeiten. Aber das Wichtigste ist einfach, sehr früh anzufangen mit der Konzeption der Trainings. Das ist ein ganz wichtiger Punkt in diesen Phasen bis GoLive, kombiniert natürlich mit den Tests, wo man sehr früh eine Teststrategie festlegen muss. Da werden neben den Key Usern noch weitere Test User benötigt. Das ist sehr ressourcenintensiv kurz vor GoLive, wo man merkt, dass die Spannungskurve hoch geht. Da müssen wir sehr intensiv dranbleiben als Change Manager.

Jetzt gehen wir davon aus, dass auch einige Dinge rund laufen. Du weißt, ich bin sehr optimistisch veranlagt. Und das ist dann der Höhepunkt, der GoLive, den man entsprechend lange vorbereitet hat. Und so, wie man im negativen Fall Fingerpointing vermeiden sollte, sollte man, wenn es gut läuft, nicht vergessen, Erfolgs-Storys zu schreiben, zu kommunizieren – und diesen Höhepunkt wirklich zu feiern. Es wird dann meist von der Geschäftsführung ein Brief rausgeschickt, maximal: „Toll gemacht“, Schulterklopfen. Da muss man diese Wertschätzung auch zeigen und dem Team Respekt zollen für die lange Arbeit. Es sind ja meist Projekte, die über Jahre gehen. Ich erlebe es dann oft, dass die Spannungskurve ganz nach unten geht, komplett abfällt. Und das ist völlig natürlich, dass man mal einen Moment innehält. Ich weiß, dass das in diesem schnelllebigen Geschäft nicht so gern betont wird.

Matthias Uebel: Ja, auf jeden Fall. Und weil du es jetzt gerade so sagst: Pausen machen ist immer wichtig, und das gilt natürlich auch für uns. Deswegen wollen wir jetzt hier auch eine Pause machen in unserer Podcast-Reihe. Ich denke, wir haben den Hörern doch einiges mit auf den Weg geben können zu den Dos and Don’ts einer S/4HANA-Transformation. Ich bedanke mich fürs Zuhören und bis zum nächsten Mal.

Markus Czeslik: Danke auch von mir. Danke dir, Matthias und bis zum nächsten Mal.

Matthias Uebel: Ciao.