SAP-S/4HANA-Einführung – Erfahrungen und Erfolgsfaktoren am Beispiel Airbus Defence and Space

Shownotes

Diskutierte Fragen:

Welche Beweggründe gibt es für eine SAP-S4/HANA-Einführung? Ist es die technische Notwendigkeit der Überführung von R3 auf S/4 allein? Oder die stringente Umsetzung einer IT-Strategie? Oder gibt es Bedarf aus dem Business?

Welchen Scope kann die Einführung haben? Ist es der reine Fokus auf die Finanzprozesse? Oder das Ziel ein vollintegriertes System zu schaffen?

Welches Vorgehen kann man wählen? Welche Rolle spielen dabei eine heterogene Systemlandschaft oder heterogene Geschäftsmodelle? Wie entscheidet man zwischen „make" oder „buy"?

SAP-Standard oder -Customizing? Welche Vorteile bietet die SAP Model Company? Welche Wichtigkeit hat ein klares Verständnis vom eigenen Geschäftsmodell und der zukünftigen Steuerung?

Welche Stolperfallen gibt es? Welche Golden Rules können helfen? Was gibt es beim Business Case und einem schlagkräftigen Staffing zu beachten?

Wie sehr eignet sich SAP S/4HANA für die Steuerung eines Unternehmens? Was kann das System leisten und was nicht?

Weiterführende Links:

Airbus

CTcon: Steuerungsrahmen

CTcon: Steuerungslogik

CTcon: SAP-S/4HANA-Transformation

Management-Podcast von CTcon (Folge 5): "SAP-Controlling in der Praxis - Einführung einer konzernübergreifenden Margenanalyse"

Management-Podcast von CTcon (Folge 4): "Digitale Transformation in der CFO-Funktion - Entwicklungen in Steuerung und Controlling"

Transkript anzeigen

00:09:11: Sprecherin: Zielführung starten - der Managementpodcast von CTcon.

00:19:24: Dr. Christan Bungenstock: Guten Tag liebe Hörer, herzlich begrüße ich Sie bei unserem Management Podcast Zielführung starten. Ich bin Christian Bungenstock und Partner bei CTcon in Düsseldorf. Gemeinsam navigieren wir heute erneut durch ein Management relevantes Thema aus der Unternehmenssteuerung, Erfahrungen und Erfolgsfaktoren einer erfolgreichen S/4HANA Einführung. Unterwegs sind wir mit Simon Lüke und Sjard Hammer. Simon Lüke verantwortet die ERP Work Streams in der S/4HANA Transformation bei Airbus Defence and Space seit einigen Jahren.

00:49:14: Dr. Christan Bungenstock: Die Division ist auf die militärische Luftfahrt, Raumfahrtsysteme, Satelliten und Kommunikationstechnologien spezialisiert. Simon überblickt in seiner Rolle den gesamten Projektpart der S/4HANA Einführung. Sjard Hammer ist Partner bei CTcon in München. Seit 2004 berät er für uns führende Konzerne in Themen der Unternehmenssteuerung. Seine Erfahrung, diese auch bei einer notwendigen IT Transformation stärker in den Fokus zu setzen, schafft ein Ergebnis, das deutlich mehr bietet als die alleinige technische Migration.

01:25:23: Sjard Hammer: Simon, wir kennen uns nun schon seit mehr als zwölf Jahren und ich freue mich sehr, dass wir uns heute mal wieder treffen und über ein sehr spannendes Thema sprechen. Es gibt wahrscheinlich nur sehr, sehr wenige Unternehmen, die sich aktuell mit dem Thema überhaupt nicht beschäftigen, sondern glaube ich, beschäftigt sehr, sehr viele Unternehmen in irgendeiner Weise. Und worum geht es?

01:45:00: Sjard Hammer: Es geht um die Einführung von S/4HANA. Was war eigentlich der wesentliche Beweggrund oder Auslöser, dass ihr die S/4HANA Einführung bei euch gestartet habt? Wie ist die denn auf die Agenda gesprungen? Hatte das mehr technische Gründe, also die Notwendigkeit, oder die Überführung von R/3 auf S/4 oder dass die IT sehr stringent ihre IT-Strategie umsetzen wollte? Oder kam das, kam der Bedarf eher aus dem Business, weil man einfach gesagt hat, ich möchte besser irgendwie das Geschäft gespiegelt haben und Nutzung neuer Möglichkeiten und Funktionalitäten? Was war bei euch der Auslöser?

02:20:18: Simon-Oliver Lüke: Sjard vielen Dank. Ich freue mich, dass wir das Gespräch heute haben hier. In der Tat war bei uns der ursprüngliche Auslöser eher von der Technik Seite von der IT Abteilung, weil wir sehr viele unterschiedliche SAP, aber auch andere Systeme gehabt haben mit einer sehr heterogenen Nutzung, auch für die Leute, die das Geschäft noch her machen. Aber das war der ursprüngliche Startpunkt vor inzwischen sieben, acht Jahren sogar. Das ist schon länger her und was wir noch her gemacht haben, ist, dass wir sozusagen im Jahr 2017 noch her uns überlegt haben, die ganzen Investitionen, die damit verbunden sind, den Aufwand für die Firma, um nur ein Upgrade von der eins, zu einer Softwareversion zu machen, war dann einfach für die Firma einfach eine zu geringe Return on Investment. Das heißt, wir haben uns dann überlegt, ob wir, wenn wir nicht schon so viel Geld in die Hand nehmen, ob wir denn nicht wirklich auch businessmäßig da mehr drauf gucken und Prozessoptimierung und Prozessharmonisierung auch machen wollen.

03:16:21: Sjard Hammer: Okay, da schließe ich ja eigentlich eine fundamentale zusätzliche Eingangsfrage an, nämlich die Scope Frage. Ist es der reine Fokus auf die Finanzprozesse oder soll es schlussendlich ein voll integriertes System sein, wo man dann auch anderen Funktionen die Möglichkeit gibt, ihre Möglichkeiten auszuspielen, wie die Supply Chain, dass man das auch abbildet? Wie, für was habt ihr euch entschieden?

03:41:16: Simon-Oliver Lüke: Das ist sehr witzig, dass du das fragst, weil in der Tat, wenn man SAP hört, haben wir auch am Anfang sehr viel das Feedback bekommen, was sollen wir denn da? Das macht doch die Finance-Abteilung. Und das ist natürlich nicht so, also die ganze Power von so einem integrierten System wie SAP S/4HANA, aber davor war das auch nicht anders.

04:01:03: Simon-Oliver Lüke: Kommt natürlich erst dadurch zustande, wenn wirklich alles integriert funktioniert. Insofern ist das grob natürlich alles. Also von Finanzen, Commercial Management hin zu Einkauf, Logistik, Produktion, Qualitätsmanagement wirklich die ganze Bandbreite dessen, was wir im Geschäft benötigen, um unsere Produkte an die Kunden zu liefern, die wir liefern.

04:23:03: Sjard Hammer: Und für welche Art des Angangs habt ihr euch dann entschieden? Bei Airbus Defence and Space habt ihr ja eine ganze Vielfalt, einen ganzen Blumenstrauß. Wenn ich mal schaue an die vielen Gesellschaften und Steuerungseinheiten, die ihr habt. Ihr operiert in ganz vielen verschiedenen Geschäftsmodellen, bietet entsprechend auch ganz andere Produkte, Services oder Lösungen an, oftmals gibt es auch sensible Daten und Informationen mit hoher Sicherheits- oder Sensibilitätsstufen und wie du es eben ja auch schon erzählt hast, die heterogene System Welt ist ja auch noch da.

04:56:13: Sjard Hammer: Also irgendwie muss man da ja ein Anpack kriegen, habt ihr die Unternehmen oder Geschäftsmodelle geclustert und wie habt ihr das angestellt? Welchen Angang habt ihr da gewählt?

05:05:13: Simon-Oliver Lüke: Das war natürlich am Anfang so ein bisschen Catch-22, wie man das denn so sagt. Also wirklich eine sehr schwierige Fragestellung am Anfang wie wir das Aufsetzen und das haben wir auch nicht in einem Tag hinbekommen.

05:16:17: Simon-Oliver Lüke: Also wir haben relativ lange uns überlegt, wo man das Ganze aufsetzen kann. Die Aspekte waren natürlich einmal in der Tat, wir machen das ja nicht zum Selbstzweck, sondern dafür, dass wir unsere Geschäfte besser abwickeln wie vorher. Und in der Tat, wir haben ein sehr heterogenes Geschäftsportfolio. Wir haben wirklich klassische industrielle Produktion, also Flugzeuge, Satellitenbau, viele Servicegeschäfte, natürlich auch Überholung, Servicegeschäfte, wo wir auch wirklich digitale Produkte verkaufen, also eine große Bandbreite im Portfolio, die halt wichtig ist, abzudecken.

05:52:06: Simon-Oliver Lüke: Und wir müssen die Balance auch hinbekommen, dass wir eben nicht ein "one fits it all" Prozess-Setup und Systeme haben, weil diese Geschäftsmodelle brauchen einfach unterschiedliche Prozesse. Und das war schon eine Schwierigkeit am Anfang. Auf der anderen Seite, was wir auch gemerkt haben, ist, dass die das Aufsetzen von so einem Projekt sehr wichtig ist, um zu verhindern, dass wir jetzt nicht klassisch eine Aufnahme von, es ist machen wir rennen durch die ganze Firma, fragen unterschiedlich Abteilung, Geschäfte, wie macht ihr es heute? Wie wollen wir es morgen machen? Weil diese Art der Projektabwicklung, das kann man an der Presse ja auch viel sehen gibt es ja die bekannten Verdächtigen großen Retailfirmen zum Beispiel, die ihre Projekte auch Stück weit einfach abbrechen mussten, weil die schon hunderte von Millionen bei so was investiert haben. Das haben wir natürlich am Anfang gesehen und gewusst und haben so gut wie möglich wie das damals, wie wir das 2017, 2018 aufgesetzt haben, versucht zu berücksichtigen.

06:56:13: Simon-Oliver Lüke: Das heißt, wir haben sehr stark darauf gebaut, die Möglichkeiten, weil die SAP selber hat das ja auch erkannt als Softwareprovider, dass diese Art der Projekte auch nicht gut für das Image der SAP ist. Wenn viele Projekte in der Presse stehen, dass die abgebrochen werden, ist das halt nicht gut. Und SAP hat schon sehr viel gemacht, diese sogenannten Accelerator.

07:16:20: Simon-Oliver Lüke: Es gibt da auch sogenannte Model Companies, die natürlich nicht Plug and Play sind, aber die schon sehr viele Elemente von Reuse mitbringen und auch die Kosten einfach reduzieren durch den Aufwand, das Ganze zu implementieren. Und das mussten wir halt balancieren, auch mit sogenannten, mit den Geschäftsmodellen. Also wir haben sozusagen unterschiedliche Business Types festgelegt, die eigentlich unseren Geschäftsmodellen entsprechen. Dass ist so was wie "Engineer to Order" "Manufacture to Stock", diese klassischen Geschäftsmodelle, dass man das auch in Prozesse und neue Systemfeatures am Ende des Tages umsetzt, was auch natürlich standard Vorgehensweise ist.

07:56:06: Sjard Hammer: Und wie habt ihr euch dann aufgeteilt, intern und extern? Wo habt ihr euch Verstärkung gesucht, bei welchen Themen habt ihr gesagt, nein, das soll inhouse bleiben? Da müsst ihr euch als Unternehmen maßgeblich mit beschäftigen.

08:08:06: Simon-Oliver Lüke: Die Frage ist natürlich auf theoretischer Natur, weil man kann sich natürlich viel wünschen, aber leider, wie auch in anderen Teilen des Lebens ist das nämlich kein Wunschkonzert. Also natürlich haben wir uns überlegt, was wir selber machen wollen und was bei von außen ist.

08:25:14: Simon-Oliver Lüke: Vom Prinzip her war die Idee, dass wir sagen, alles was wirklich Prozessdesign ist und also was Geschäftsverständnis erfordert, auf der einen Seite bis hin zu dem sogenannten Customizing, also dem standard konfigurieren des Systems. Das wollten wir eigentlich in house machen und alles, was darüber hinaus sogenannte Enhancements. Also wirklich klassische Programmierarbeiten sind, was eher tendenziell eher one time sind, das wollen wir vom Prinzip her outsourcen.

08:54:24: Simon-Oliver Lüke: Das war ursprünglich die Idee. Warum rede ich da in der Vergangenheitsform, natürlich deswegen, weil wir nacher gemerkt haben, dass wir die Leute einfach nicht haben. Also wir haben die das Know how nicht. Also heißt nicht, dass wir nicht unbedingt nicht genügend Leute haben, sondern wir brauchen eben auch das Know how, was die S/4HANA Software eben anbetrifft. Und das haben natürlich ganz wenige bei uns in der Firma, weil das ein neues Produkt ist.

09:19:12: Simon-Oliver Lüke: Und insofern mussten wir leider davon ein Stück weit Abstand nehmen und haben sehr viele systemnahe Aktivitäten auch weiter outsourcen müssen, obwohl wir das eigentlich gar nicht wollten.

09:31:12: Sjard Hammer: Und mittlerweile, ein paar Jahre später, würdest du sagen, da habt ihr jetzt aber schon so einen Hub erfahren? Ihr kennt jetzt das System auch schon ein bisschen besser, habt ihr da intern wie die Skills jetzt mit aufbauen können?

09:43:07: Simon-Oliver Lüke: Wir haben in der Tat die letzten Jahre natürlich Skills aufgebaut und auch Erfahrung gesammelt. Das reicht aber trotzdem nicht aus. Also so große Projekte nun mal so ein bisschen Gefühl zu bekommen. Wir haben ungefähr 200, 300 Leute, die an diesem Projekt arbeiten, ungefähr um eine Größenordnung zu kriegen und nicht alle unbedingt Fulltime natürlich. Aber wir haben schon gemerkt, dass da Know how aufgebaut wurde.

10:06:16: Simon-Oliver Lüke: Aber wir haben auch gemerkt, dass es nicht genug ist. Also wir haben nach wie vor zu viel an Beratern. Nicht das wir was prinzipiell gegen Berater haben. Deswegen bin ich natürlich heute auch hier. Aber oftmals sind es einfach zu viele Berater.

10:20:16: Sjard Hammer: Ich schwenk da mal ein bisschen zurück. Viele unserer Klienten berichten, dass sie mit dem Anspruch standard first erst mal ins Rennen gehen und daran eigentlich auch festhalten wollen.

10:30:20: Sjard Hammer: Die Gründe sind eher so, dass der noch sehr präsent ist aus der R/3 Welt, dass das ganze Customizing sehr kostenintensiv war und zeitintensiv und irgendwie mit der Zeit. Wenn man ein paar Jahre vergehen, ist das eigentlich immer mehr eine Blackbox. Man weiß eigentlich gar nicht mehr, welche Logiken dahinter stecken. Das ist so ein Thema, was ich immer wieder höre.

10:49:14: Sjard Hammer: Auch der Vorwurf der Inflexibilität, steht da auch immer wieder im Raum. Wie du eben berichtet hast, gibt es ja so Methoden oder Möglichkeiten über die Model Company, dass so ein bisschen wenigstens eine Blaupause da bestehen. Also wie weit würdest du denn dieses Thema zwischen Standard kann ich durchsetzen und eigentlich zum Schluss lande ich doch beim sehr detaillierten und individuellen Customizing? Wie würdest du denn so eine Frage beantworten?

11:15:02: Simon-Oliver Lüke: Ja, also ich glaube, es hat eine sehr große Umstellung gegeben in der Softwareindustrie in Summe und natürlich auch bei der Einführung hin von individueller Software zu wirklich Standardsoftware. Das merkt man überall in der Industrie, da ist SAP natürlich nicht ausgenommen. Wahrscheinlich ist SAP der Komplexität geschuldet, tendenziell eher eine der Software, die sogar am Ende der ganzen Kette ist, wenn man die ganzen anderen Software Tools anbetrifft.

11:41:15: Simon-Oliver Lüke: Office Pakete, Smartphones usw. usw., da ist die Standardisierung schon viel, viel weiter vorangekommen als es bei SAP zum Beispiel der Fall ist. Die SAP pusht da sehr stark, natürlich auch selber, wollen sehr gerne in die Cloud gehen, was auch nicht unbedingt alle Klienten natürlich gerne wollen. Insofern hat sich wirklich auch was bei der Software Einführung verändert. Die Schwierigkeit aus unserer Sicht ist halt, dass es wenige Firmen, Projektleiter als auch natürlich Beratung gibt, die das verinnerlicht haben.

12:16:03: Simon-Oliver Lüke: Hat auch kommerzielle Gründe, weil natürlich viele immer Geld verdienen wollen und insofern die Standardisierung ist bis auf den Anwender der Software nicht unbedingt in jedermanns Interesse, weil die Berater verdienen natürlich gutes Geld damit. Insofern haben wir natürlich auch mit der Standardsoftware angefangen, gerade mit der Model Company und was wir eben auch im Haus gemerkt haben, dass viele Kollegen am Anfang schon relativ viel Training gebraucht haben, um zu verstehen, was die Model Company wirklich ist.

12:48:19: Simon-Oliver Lüke: Und wir merken nach wie vor heute, weil wir natürlich auch Fluktuation im Team haben, dass das sehr, sehr wichtig ist, das präsent zu halten, weil die Nichtnutzung dieser standard Model Company accelerator Elemente. Für viele ist das erst mal nur Powerpoint. Die gucken sich das an, sagen ja ja eine schöne Werbebroschüre von der SAP, Haken dran weiter. War bei R/3 auch schon so.

13:09:14: Simon-Oliver Lüke: Das ist es aber nicht. Ich glaube, das wirkliche Verständnis, was eine Standardsoftware ist und wie man die auch implementiert, ist extrem wichtig für den Erfolg oder Misserfolg, auch wirtschaftlicher, aus wirtschaftlicher Sicht gesehen dafür. Natürlich war es bei uns auch so, dass wir viel Diskussion gehabt haben, ob diese Model Company wirklich passt. Und wir haben so einen Spruch geprägt, dass die Model Company für 80 % der Firmen für 80 % der Prozesse passt, was schon eine immense Kosteneinsparung ist, wenn man für diesen Bereich, wo es passt wirklich auch die, die diese Elemente benutzt, weil da ist da ist Training sofort mit dabei.

13:45:09: Simon-Oliver Lüke: Also das sind auch sogenannte Test Scripts mit dabei, das heißt, wenn man User Stories schreiben möchte, da kommen wir vielleicht später noch drauf zu, wenn man das immer im agile Ansatz macht. Da kann man sehr, sehr viel einfach benutzen aus diesem Gesamtpaket, was die SAP an der Stelle anbietet und wenn man das halt gut benutzt, dann kann man wirklich sich eine Menge Zeit und Geld sparen.

14:10:05: Simon-Oliver Lüke: Die Diskussion intern ist natürlich eine ganz andere, weil die Nutzer oder die Kollegen, die natürlich noch jeden Tag irgendwas abliefern müssen, also die Nutzer der Software, meine ich. Die müssen auch nicht das Verständnis haben, wie diese Standard Software funktioniert und was das für die Einführung heißt. Die kommen natürlich mit deren. Ich habe heute eine Software, die macht irgendwas und bitte, die neue Software soll das gleich an der Stelle machen.

14:35:03: Simon-Oliver Lüke: Da kommt die Diskussion natürlich dann hoch, wo wir nach wie vor jeden Tag natürlich Diskussion haben. Nein, ich muss aber diese sieben Prozessschritte machen und wenn ich das in fünf Schritten mache, dann passt das aber nicht, weil irgendwas nicht funktioniert. Das heißt, der Rückschritt auf das, was wirklich die Business Requirements sind, das, was ich wirklich inhaltlich, geschäftlich erreichen möchte, das hat nichts mit einer technischen Diskussion logischerweise zu tun, sondern mit wirklichem Change Management, was auch 50 % des Erfolgs noch herausmacht an der Stelle.

15:05:13: Sjard Hammer: Das glaube ich auch. Das ist auch unsere Beobachtung. Man muss erst mal eine eindeutige Klarheit haben über das eigene Steuerungskonzept. Wie will ich mein Geschäft steuern, meine Managementeinheiten steuern? Wie erfolgt eigentlich die Wertschöpfung? Welche End-to-End Prozesse gibt es? Wie sieht eigentlich eine Ergebnisrechnung aus? Brauche ich eine Produkt-Erfolgsrechnung und oder eine Kunden- Erfolgsrechnung? Wie verlaufen eigentlich interne Verrechnung? Ich glaube, da muss man erst mal extrem viel Klarheit haben.

15:32:07: Sjard Hammer: Und wenn man mal unter die Motorhaube schaut und danach das ergründet, dann merkt man, dass diese Klarheit oftmals gar nicht existiert oder zumindest mal einer Aktualisierung bedarf.

15:44:07: Simon-Oliver Lüke: Wir haben das natürlich auch ein Stück weit machen müssen und kein Unternehmen hat natürlich auf dem Level, was eine Softwareentwicklung braucht, irgendeine Beschreibung, wie diese ganzen Prozesse aussehen. Es ist ja nicht nur bei Finance, bei den Beispielen, die du gesagt hast, sondern das ist ja überall, das ist in der Logistik-Abwicklung, im Einkauf, bei all diesen Prozessen, das heißt, auf dem Detaillierungsgrad gibt es natürlich das nicht, und es ist auch nicht ökonomisch, für irgendeine Firma das zu machen.

16:09:17: Simon-Oliver Lüke: Ja, es gibt natürlich einige Firmen, die sind prozessorientierter, einige etwas weniger. Aber auf dem Level, das zu machen, ist es einfach nicht ökonomisch. Das heißt, den Ansatz, den wir gemacht haben, ist, dass wir wieder zurückgehend auf den Ansatz, dass wir die Standard sogenannten Best Practices oder Model Companies benutzen, dass wir das als Startpunkt genommen haben, weil dort die Beschreibung schon sehr detailliert da ist und dann immer sogenannte Delta Dokumente geschrieben haben, was wir denn darüber hinaus benötigen.

16:36:05: Simon-Oliver Lüke: Also die 20 %, die darüber hinaus notwendig sind. Und das hat uns eigentlich sehr stark geholfen. Und genau diese Diskussion, nach der du gefragt hast, zu führen auf einem Level, die auch, der auch konkret genug ist, sowohl hinsichtlich inhaltlicher geschäftlicher Aspekte als auch hinsichtlich was heißt denn das für das System? Weil diese Diskussion zu führen in einem theoretisch abstraktem Kontext, welches Steuerungsmodell brauche ich, welche Logistikprozesse brauche ich usw.. Wenn man das nur auf Powerpoint macht, hilft es halt nicht viel. Unserer Erfahrung nach ist diese Verbindung gleich zu sagen, das mit der Model Company zu machen sehr hilfreich, weil man dann gleich schon weiß, was die Standardprozesse sind und was sie on top brauchen. Auch wenn ich das losgelöst machen würde, würde es heißen, dass ich denn diese vielleicht manchmal ein bisschen akademische Diskussion wiederum umsetzen muss, was das heißt für die Software am Ende des Tages.

17:29:05: Sjard Hammer: Korrekt. Jetzt hatten wir eben so zwei Themen kurz gestriffen. Das, was mir auch oft begegnet ist Mensch, das überfordert mich. Jetzt haben wir auch noch Zeitdruck, jetzt migriere ich das System von R/3 auf S/4 und dann schauen wir mal. Das war jetzt ja nicht euer Anspruch, so wie ich es verstanden habe. Was waren denn zum Schluss so neue Funktionalitäten, wo es man dann auch sichtbar und greifbar gemacht hat dem User. Mensch, jetzt hast du doch Ergebnisrechnung oder Deckungsbeitrag Schema oder Margen Analyse neue Strukturen. Wie war das bei euch? Was war sozusagen der greifbare Mehrwert, den ihr den den Anwender mit an die Hand geben konntet?

18:04:05: Simon-Oliver Lüke: Um so ein bisschen den, die Change Entwicklung und ein bisschen in Augenschein zu nehmen, haben wir natürlich gemerkt, dass diese positiv, dass dieses positive Feedback relativ spät kommt, weil im Rahmen so eines Deployments natürlich sehr viel Angst auch bei den Kollegen da ist, weil natürlich, man muss jeden Tag seinen Job machen, man muss jeden Tag was abliefern und man möchte natürlich keine Steine in den Weg gelegt bekommen, wenn eine neue Software da ist.

18:33:24: Simon-Oliver Lüke: Das ist ja häufig auch der Fall, muss man fairerweise auch sagen, dass einfach irgendwas deployt wird. Die Leute werden nicht gefragt, werden nicht involviert und das haben wir bei uns in der Firma früher auch schon gehabt und das hat natürlich viel Ungemach erzeugt. Das heißt, das positive Feedback kam ehrlicherweise meistens sechs Monate, zwölf Monate nachdem wir das Deployment gemacht haben, weil sich dann so ein bisschen (geschüttelt und gesetzt), genau so ein bisschen, der Dust hat sich gesettelt sozusagen genau und da haben wir konkrete Beispiele gehabt, zum Beispiel bei dem Thema Umsatz Legung, also Result Analysis, was natürlich sehr viel Diskussion im Vorfeld war.

19:14:19: Simon-Oliver Lüke: Aber wenn ich dann doch mal irgendwas auf Knopfdruck machen kann, mehr oder minder, was es denn wirklich ist, wenn ich das richtig konfiguriert habe und die ganzen inhaltlichen Diskussionen umgesetzt habe. Technische Features. Da gab es dann schon oh, das ist ja wirklich besser als das vorher war, weil die manuellen Schritte vorher einfach weniger sind. Also da haben wir sehr viel positive Erfahrung gesammelt.

19:33:05: Simon-Oliver Lüke: Eine andere Möglichkeit haben wir auch im Controlling auch gesammelt, wenn man unterschiedliche Szenarien rechnen möchte. Unterschiedliche Bewertungswelten zwischen lokal, also Local Gaap HGB im Deutschen und IFRS haben möchte. Wenn ich da Parallelwelten brauche und auch Szenarien machen möchte, wenn ich das denn systembasiert mache, dann geht das natürlich alles viel schneller. Wo viel früher mit Excel gemacht werden musste, das sich Umbewertung von Hand oder zumindest teilweise unterstützt machen möchte.

20:03:00: Simon-Oliver Lüke: Wir haben da einen Modul COGM auch von der SAP benutzt. Da haben wir jetzt auch mal positives Feedback bekommen, nach dem Motto, oh, das war toll, dass ich das wirklich jetzt automatisiert machen kann und nicht alles manuell sozusagen oder stückweit manuell machen muss. Aber so was kommt meistens schon eine Ecke später.

20:21:00: Sjard Hammer: Stichwort Governance System. Also wir hatten es eben, es gibt SAP Standards über die Model Company usw. hast du gesprochen.

20:28:18: Sjard Hammer: Auf der einen Seite gibt es die Business Specifics, das sind so für mich so die zwei Achsen und auf der anderen Seite stelle ich mir vor, auch in einem sehr heterogenen Unternehmen, wie ihr es nun mal seid, braucht es vielleicht aber auch eine Governance, die vielleicht sogar darüber geschaltet ist und das verbindet, weil man braucht einen formalen Charakter ja auch, um Klarheit zu erzeugen auf der einen Seite in der Dokumentation, aber auch wenn wieder Neues, eine neue Management-Einheit dazu kommt, dass man nicht wieder das Rad neu erfindet, sondern sagt, Mensch, das hatten wir doch schon. Und jetzt nutzt doch die Vorteile, die wir hatten. Habt ihr auch über solche Mechanismen nachgedacht? Habt ihr die auch eingeführt oder wie seid ihr mit diesem Thema umgegangen?

21:06:18: Simon-Oliver Lüke: Also die Governance ist natürlich super wichtig, um zu verhindern zum einen, dass man, wenn man schon Standardsoftware benutzt, dass man auch bei einer Standardsoftware bleibt und nicht dann doch nach zwei, drei Jahren, drei, vier, fünf Jahren des Projektes sieht, dass man doch alles wieder verbogen hat auf der einen Seite und auf der anderen Seite, selbst wenn man das Template einmal gebaut hat, dass es dann zwei Jahre später in der Benutzung den auch wieder verbogen ist. Das hat sozusagen den Aspekt sowohl innerhalb des Projektes als auch auf der anderen Seite während der normalen Laufzeit (Im Betrieb). Genau. Und wir haben auf beiden Dimensionen in der Governance natürlich gelegt. Am Projekt war das die Ambition, auch von unserem Vorstand am Anfang recht hoch muss man sagen, die haben gesagt, ihr müsst auf alle Fälle die Standards Software benutzen.

21:52:03: Simon-Oliver Lüke: Jede Abweichung soll sofort zu uns kommen und die Ambition war da am Anfang sehr hoch, muss man fairerweise sagen, dass natürlich diese Abweichung vom Standard auf einem Detaillierungsgrad sind, die irgendwann auf so einer Flugebene nicht mehr managebar sind. Das heißt, wir haben da natürlich eine Governance eingeführt mit einer sogenannten Design Authority oder einem Team, die halt nach Prozessen geclustert ist also Order to Cash, Purchase to Pay und diese diese Art von Prozesscluster. Und diese Teams bzw. dann ein Governance Body was die Teams zusammenführt, haben wir regelmäßige Entscheidungssitzungen um zu sagen, ob wir vom Standard abweichen wollen oder nicht.

22:32:03: Sjard Hammer: Und das war in der Implementierung aber jetzt auch Change Request sage ich mal Stichwort auch jetzt in der Betriebsphase?

22:38:03: Simon-Oliver Lüke: Richtig. Und wir haben beides parallel laufen lassen, weil natürlich in der Implementierung deutlich größere Volumina einfach kommen von diesen. Da haben wir also wirklich hunderte von sogenannten Gaaps gehabt zum Standard hin, die wir da entscheiden mussten. Und das kann man nicht in unserem regulären Meeting machen, was wir einmal die Woche mit zwei Stunden machen, das geht natürlich nicht. Im Projekt ist das deutlich mehr. Wenn man noch im laufenden Geschäft ist, ist das natürlich oder sollte das deutlich weniger sein und dann kann man das einfach abwickeln.

23:08:11: Sjard Hammer: Simon, jetzt kommt natürlich die die Frage aller Fragen in Anführungsstriche. Wenn du jetzt mal innehältst und reflektierst, was sind A. Stolperfallen, die wehtun und die man mit viel Achtsamkeit und Aufmerksamkeit unbedingt vermeiden sollte und B. dann umgedreht, welche fünf bis sechs Punkte würdest du zusammenfassend als Tipps, Erfolgsfaktoren oder Golden Rules all denjenigen mitgeben, die gerade in der S/4HANA Einführung anstarten oder schon mitten drin sind aber jetzt gerade in diesem, wahrscheinlich kennst du das auch, in so einer Phase sind, wo man dann doch ein bisschen Frustration und Verzweiflung vielleicht spürt. Was kannst du denjenigen mitgeben?

23:47:16: Simon-Oliver Lüke: Es gibt natürlich, muss man fairerweise sagen, die Stolperfallen sind nacher unsere Golden Rules geworden. Die meisten fallen natürlich wieder besseren Wissens oftmals trotzdem reingefallen sind. Was auch immer interessant ist, man hat immer viel Ambition am Anfang und häufig muss man als Firma leider dann doch viel selber lernen.

24:08:06: Simon-Oliver Lüke: Das muss man fairerweise sagen. Ich glaube, das Allerwichtigste ist, dass man diese Projekte so staffed mit Projektmitarbeitern, die wirklich das Geschäft verstehen. Das merken wir, dass es wichtig ist, dass wir ein durchmischten Team haben, ein multifunctional Team, wo wir sowohl Kollegen haben, die die Software gut kennen und die Technik der Software als auch Kollegen, die das Geschäftsmodell wirklich verstehen.

24:33:07: Simon-Oliver Lüke: Weil nur dann sind die Teams in der Lage zu verstehen, was die Requirements sind und wie ich die wirklich technisch umsetze. Wenn man das eine nur und das andere nicht hat, egal in welche Richtung, ist man entweder nur theoretisch und kann das nacher nicht umsetzen. Oder aber man hat Leute, die Technik verstehen und bauen komplexe Lösungen, die aber nicht an die Business, für die Business Requirements hinschauen.

24:56:18: Simon-Oliver Lüke: Das heißt, das ist ein ganz wichtiger Erfolgsfaktor, was auch sehr wichtig ist, wenn man sich überlegt, dass man ja sehr viel Geld in solche Programme steckt und da auch ein Return von haben will. Ist es wichtig zu verstehen, dass man. Ich nenne das immer ein Sweet Spot hat zwischen dem Design, was man macht und damit auch verbundenen Kosten.

25:20:04: Simon-Oliver Lüke: Sowohl das Design selber zu machen. Da kommen ja hunderte von Arbeitssitzungen zusammen, hunderte von Stunden laufen dabei auf. Das kostet eine Menge Geld und was man dann noch ja daraus haben möchte, das heißt wirklich aktiv zu überlegen, wie viel Geld möchte ich in die Hand nehmen, für wie viel spezifisches Design diesen sogenannten Sweet Spot zu finden?

25:43:20: Simon-Oliver Lüke: Zwischen wie weit gehe ich weg vom Standard? Was kostet das und was ist der Return fürs Geschäft? Kommt wieder zurück zu dem Thema Multifunktionales Team. Ist sehr wichtig, sich da am Anfang vorher Gedanken zu machen, dass ich nicht einfach los laufe, ich mache as is und to be, dann kostet das 100 Millionen. Und die Wahrscheinlichkeit, dass ich dann das Projekt abbreche, was einfach nicht ökonomisch ist, ist dann an der Stelle sehr hoch.

26:07:23: Simon-Oliver Lüke: Ein Business Case zu rechnen ist natürlich auch immer wichtig. Das haben wir natürlich auch am Anfang gemacht und der hat sich natürlich auch weiterentwickelt über die Zeit, das ist klar. Wir haben sozusagen dreimal diesen Business Case inzwischen upgedatet. Das ist wichtig zu tun. Unsere Erfahrung ist an der Stelle auch, dass man da auch die Balance hinbekommt zwischen nicht sich zu vergeistigen in Details, die nachher keine reale Rolle mehr spielen, aber trotzdem konkret genug ist, um selber eine Vorstellung zu haben und auch das Management zu überzeugen, was ich denn wirklich auch finanziell erreichen möchte mit dem Ganzen. Das ist auch sehr wichtig und zum Schluss, was wichtig ist bei solchen Projekten ist auch Durchhaltevermögen zu haben innerhalb der Firma, weil diese, je nach Größe der Firma sind das im Vergleich zu den normalen Aktivitäten innerhalb einer Firma, ist das nichts, was man innerhalb von einigen Wochen einigen Monaten macht. In Firmengrößen wie der unseren dauert das halt Monate, Jahre, mehrere Jahre.

27:12:09: Simon-Oliver Lüke: Und es ist wichtig zu versuchen, so gut wie möglich eine Stringenz da zu behalten. Natürlich dreht sich die Welt immer weiter, das ist ganz klar und man muss da als Firma darauf reagieren. Natürlich, das ist auch klar, weil es viele, viele unterschiedliche Einflussfaktoren gibt. Aber wichtig ist, dass die Firma und natürlich auch dann das Senior Executive Team auch klar ist, was es erreichen möchte und da auch längere Zeit dahinter steht.

27:38:13: Simon-Oliver Lüke: Wenn das eine Initiative von einer Person ist, sei es im Vorstand oder auch im mittleren Management, was einmal angeschoben wird und nicht die Stringenz hat, dann ist es auch zum Scheitern verurteilt.

27:51:13: Sjard Hammer: Das glaube ich auf jeden Fall auch. Also Backing ist wichtig und langer Atem ist wichtig. Wie geht man damit um? Weil ich würde sagen, bei den meisten Projekten gibt es einfach auf Projektverzögerungen. Wie schafft man es da stark im Wind zu stehen und trotzdem nicht umzufallen?

28:05:09: Simon-Oliver Lüke: Das ist bei uns natürlich auch so gewesen, dass wir bei vielen Projekten Verzögerungen gehabt haben. Und natürlich ist es so, dass die Wahrnehmung der Projekte, die Verzögerungen haben, deutlich größer ist als die Projekte, die man mehr oder minder erfolgreich abwickelt. Das sehen wir natürlich auch. Wir haben ein Projekt gehabt, was uns sehr viel graue Haare bereitet hat und sehr viel Geld gekostet hat, wo wir natürlich gemerkt haben, dass wir an der Stelle ja wie du so schön gesagt haast, wirklich sehr hart im Wind gestanden haben.

28:32:19: Simon-Oliver Lüke: Ich glaube, das Wichtige an der Stelle ist immer, das Auge dafür zu haben, wo man auch mal mutig vorangehen kann. Das ist, natürlich geht es immer darum, dass man ein Business continuity sieht, dass man jetzt nichts macht, wo nachher am Ende des Tages irgendwas nicht funktioniert. Insofern ist es wichtig, Erfahrung auch an Bord zu haben, dass man weiß, es kann jetzt nicht sein, dass sich in meinem Lager, dass das Lager stillsteht, wenn ich etwas auslagern muss, das meine Produktion stillsteht.

28:59:10: Simon-Oliver Lüke: So viel Sachverstand muss in meinem Projekt sein, dass ich weiß, wann habe ich Gefahr, dass irgendwas stillsteht. Aber ich kann durchaus auch mal Sachen verschieben, später machen sogenannte Nice to have Elemente. Ich glaube, das ist an der Stelle wichtig, dass man das auch nutzt, um das Management auch zu überzeugen. Weil auch bei uns kam immer mal, ist das der richtige Weg?

29:23:17: Simon-Oliver Lüke: Dann haben wir Internal Auditors natürlich vorbeigeschickt bekommen, die sich das angeschaut haben, externe Auditors natürlich auch, um Wissen auch von draußen reinzukriegen, eine externe Perspektive zu bekommen. Was ist völlig normal und immer, immer hilfreich. Aber das Wichtige ist halt, dass man gut genug die Inhalte wirklich versteht, um das einschätzen zu können. Weil man muss fast jeden Tag Entscheidungen treffen, die dazu führen könnten, dass halt mal etwas stillsteht. Das was man in der Presse liest, da sieht man natürlich immer nur die großen Projekte, die wirklich Ärger bereitet haben, das muss man vorher kommen sehen und auch austesten und wirklich ein gutes Risikomanagement an der Stelle haben. Und immer einen Plan B.

30:04:17: Sjard Hammer: Eben hast du auch nochmal MFTs angesprochen, multifunctional Teams braucht viele verschiedene Expertisen und Motivation an Bord. Jetzt frage ich auch nochmal eine persönliche Frage, was findest du so persönlich, so spannend an dem Thema auch nach der Zeit jetzt? Du kommst ja sehr stark aus dem Controlling und bist jetzt mehr aus meiner Sicht herangerückt in das Dreieck IT, Business und Controlling. Was motiviert dich immer noch? Was macht dir immer noch daran Spaß an dem an dem Thema?

30:30:05: Simon-Oliver Lüke: Also das Spannende bei diesem Job, und ich bin ja innerhalb unseres ERP-Programmes sozusagen die, der Functional Lead oder die Design Authority, wie das auch manchmal genannt wird. Das heißt, mit meinem Team kümmere ich mich halt darum, wie das Design des Systems aussehen soll. Ich glaube, da gibt es zwei Hauptmotivatoren sozusagen für mich. Einmal ist es der tägliche Umgang mit den unterschiedlichsten Menschen und damit auch Inhalten. Also wirklich die die Gänze einer Firma, so komplex sie ist, vor Augen zu haben, und zu sehen, von Kundenauftragseingang über Programm, Projektmanagement, Einkauf, Qualitätsprozesse, Produktionsprozesse, Lagerprozesse usw. usw. das gesamte vor Augen haben ist schon eine große Herausforderung, aber auch super interessant.

31:17:20: Simon-Oliver Lüke: Und das ist glaube ich für mich und auch für das Team immer eine große Motivation, in der Lage zu sein, als Teil eines Teams das so zu sehen. Das hat man nicht häufig gerade in großen Industriefirmen ist die Chance immer groß, dass man ein kleines Rädchen in einem ganz großen Getriebe ist und da nicht, die den Überblick hat.

31:37:16: Simon-Oliver Lüke: Und das ist, glaube ich, für das Team als auch für mich persönlich die Motivation, das weiter voranzutreiben. Eine zweite Motivation, die ist sehr spezifisch. Vielleicht für uns als Firma, obwohl andere Firmen das natürlich auch haben, ist, wenn man einen sehr starken, eine sehr starke Historie von Akquisitionen hat und Firmen Zusammenführung, was ja in der europäischen Luft und Raumfahrtindustrie bekanntermaßen der Fall ist, kommt man automatisch mit einer sehr heterogenen System- und Prozesswelt zusammen.

32:11:07: Simon-Oliver Lüke: Und das zusammenzuführen, um am Ende des Tages bessere Produkte für die Kunden zu liefern, das ist eigentlich die andere Motivation. Weil wenn man sieht, wie wir in der Vergangenheit Produkte geliefert haben, wie wir in der Lage sind, das hinzubekommen. Das sind immer technisch super interessante Produkte. Die Luft- und Raumfahrt hat mich schon als kleines Kind interessiert und das ist nach wie vor immer noch eine super große Motivation.

32:32:07: Simon-Oliver Lüke: Aber die Art und Weise, wie wir das vielleicht geliefert haben, war eigentlich vielleicht nicht optimal. Und was wir jetzt gemerkt haben, ist, wenn wir jetzt langsam zusammenrücken. Man kann als große Firma so viel mehr machen und das Potenzial auszunutzen, wirklich auf dieser wirklich Grasnarben-Ebene und da auch einen Mehrwert für die Firma zu schaffen, ist eigentlich die zweite große Motivation.

32:55:00: Sjard Hammer: Ja, kann ich sehr gut nachvollziehen. Lass uns gerne in die Schlussrunde gehen. Ich würde mich noch für zwei Antworten interessieren. A. Wie sehr eignet sich deiner Meinung nach S/4HANA zur Steuerung des Unternehmens? Du hast ja vorhin gesprochen. Die überwiegende Zahl der operativen Geschäftsprozesse sind schon darin abgebildet. Ob es jetzt Purchase to Pay ist oder to cash oder plan to produce.

33:19:11: Sjard Hammer: Wie blickst du daneben aber auf Steuerungsprozesse und Steuerungsinformationen? Wieso ziert sich da S/4 ein. Was kann das System leisten und auf der anderen Seite aber auch nicht?

33:29:11: Simon-Oliver Lüke: Das ist eine sehr gute Frage und da darf man sich auch keine Illusionen machen S/4HANA ist schlichtweg nicht geeignet, um ein Unternehmen zu steuern. Das muss man auch so sagen, sondern im Prinzip was ist an erster Stelle ist es eine Software zur Abwicklung von Prozessen im ersten Schritt.

33:47:13: Simon-Oliver Lüke: Natürlich gibt es da Planungselemente. Das ich Programme planen kann, ich kann meine Produktion planen. Das ist aber alles sehr operativ natürlich, und dafür ist es ja auch gedacht. Deswegen ja auch Enterprise Resource Planning. Das ist auf einmal sehr granulare Ebene, dass ich für Teams Kapazitätsplanung machen kann usw. Das ist natürlich Steuerung oftmals nicht in dem Verständnis, dass ich wie groß auch die Firma ist, sie wirklich von einer gewissen Flug-Ebene steuern möchte.

34:20:01: Simon-Oliver Lüke: Da kann SAP S/4HANA natürlich helfen und ist die Basis des Ganzen. Aber die Steuerung ist natürlich ein Level, was da drüber sozusagen gedanklich liegt. Also man muss sich, wie du am Anfang auch schon gesagt hast, immer darüber Gedanken machen, was das Steuerungsmodell ist, was das Geschäftsmodell ist, was das Ganze braucht im ersten Schritt, um dann zu überlegen, wie ich denn die Prozesse nutze und designe, die im Prinzip darunter liegen.

34:46:01: Simon-Oliver Lüke: Da muss man sich halt klar sein, dass Geschäftssteuerung und Unternehmenssteuerung ist nichts, was man direkt in SAP macht. Aus meiner Erfahrung nach. Man kann Elemente davon machen. Wie gesagt ganz operative, praktische Planung. Ich kann Projektplanung machen, ich kann Kapazitätsplanung machen usw. usw. aber das ist keine Unternehmenssteuerung in dem Sinne.

35:07:15: Sjard Hammer: Ja, da sind wir glaube ich einer Meinung. Was wir beobachten ist, dass viele Klienten die HANA Welt, sage ich immer, nur anreichern, um performante Analysen oder Reporting Welten darauf satteln. Wenn man dann auch noch über zukünftig Planungsmodule sprichst, dann kommt natürlich die SAC glaube ich noch mal ins Spiel usw.. Ich glaube inhaltlich schätzen wir das sehr ähnlich ein, dass S/4 alleine nicht ausreicht, um ein Unternehmen abseits der operativen Ebene gut zu steuern.

35:38:19: Simon-Oliver Lüke: Genau. Ich glaube, was an der Stelle halt wirklich wichtig ist, dass man ich nenne das mal Eingriffspunkte gut genug versteht. Wenn ich ein Unternehmen steuern möchte und die Steuerungsaspekte gut kenne, dass ich mir dann überlege, wenn ich zum Beispiel merke, dass bestimmte Produkte einfach zu niedrig margig sind, weil sich doch so viele technische Probleme auftun bei der Auslieferung, was auch immer das die ursprünglich verkaufte Marge nicht mehr noch die ist, die ich noch wirklich erwirtschaftete, dann muss ich halt gut genug verstehen, was heißt denn das auf operative Prozesse bezogen? Also brauche ich da in meinem Qualitätsmanagementmodul einfach eine andere Logik, wie ich meine Quality Inspections zum Beispiel mache? Oder hat das damit zu tun, dass ich eine andere Logik habe, wie ich meine Bill of Material in die Produktion einstreue?

36:30:05: Simon-Oliver Lüke: Ich glaube, das sind diese Eingriffspunkte, die man gut verstehen muss, um zu sehen, wie ich die Unternehmenssteuerung auf einer gewissen höheren Ebene wirklich auch operativ noch einsteuer und das Feedback auch wieder zurückbekomme. Aber das Zusammenspiel ist meiner Erfahrung nach das Wichtige.

36:46:05: Sjard Hammer: Mensch Simon, jetzt ist die Zeit super schnell verflogen. Sprechen schon, glaube ich, über eine halbe Stunde.

36:53:01: Sjard Hammer: Ich kann nur sagen Herzlichen Dank für die vielen spannenden Einblicke rund um das Thema S/4HANA Einführung bei Airbus Defence and Space. Ihr seid schon ein ganzes Stück gegangen. Eure Reise ist aber auch noch nicht ganz beendet. Von daher wünsche ich euch weiter gutes Gelingen und viel Erfolg und bin mir sicher, dass ihr gemäß eurem alten Claim "We make it fly" zum Fliegen bringt und erfolgreich abschließt. Alles Gute dafür und bis bald.

37:21:01: Dr. Christian Bungenstock: Bald geht es weiter mit unserem Podcast Zielführung starten. Neues Wissen und spannende Routen. Sie wollen keine Folge mehr verpassen? Abonnieren Sie uns bei Apple Podcast, Amazon Music, Spotify, YouTube und anderen mehr. Wir freuen uns auf viele weitere Expertenrunden in Ihrer Begleitung.

37:54:12: Sprecherin: Das war "Zielführung starten", der Management-Podcast von CTcon.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.