Bosch Mobility: Weltweite SAP S/4HANA-Transformation mit AI und Hyper-Automation

Die Bosch-Gruppe hat insgesamt ca. 420.000 Mitarbeiter, in 300 bis 400 Standorten in aller Welt, mit zahlreichen Geschäftssektoren wie z.B. Power Tools, Home Comfort oder Bosch Siemens Haushaltsgeräte. Bosch Mobility Solutions ist der größte Geschäftsbereich der Gruppe, mit einem Anteil von ca. 60 Prozent am Gesamtumsatz. Nahezu alle Fahrzeughersteller weltweit sind Kunden des Tier1-Suppliers. Mit über 140 Werken und mehr als 100.000 SAP-Usern zählt die S/4HANA-Transformation bei Bosch Mobility weltweit zu den größten und komplexesten SAP-Projekten. Ziel ist es, alle Standorte per industrialisiertem Rollout zu migrieren und die Basis für digitale Prozesse zu schaffen – mit besonderem Augenmerk auf generativer AI. Treiber dieser digitalen Transformation ist Stephan Brand mit seinem Team. Als Chief Digital Officer versteht er sich als Mittler zwischen Business und IT. Im Interview mit Michael Fuchs (Senior SAP-Analyst, IT-Onlinemagazin) spricht Stephan Brand über die Herausforderungen, den aktuellen Stand und die weiteren Ziele dieses einzigartigen Transformationsprojekts.

 

Gewachsene SAP-Landschaft, hohe Prozessvielfalt

Michael Fuchs: Wie können wir uns so ein Riesenprogramm wie bei Bosch Mobility Solutions vorstellen, gibt es griffige Charakteristika, wie beispielsweise die Anzahl der Standorte, bestehende Systemlandschaften oder sonstige Spezifika?

Stephan Brand: Wir haben im Konzern eine lange Historie mit SAP R/3-Systemen, die historisch gewachsen und stark modifiziert sind – etwa 40 Prozent Modifikationen.. Unsere Aufgabe ist daher, diese Landschaft in kurzer Zeit auf ein primäres SAP S/4HANA-System zu überführen. Allein für Bosch Mobility Solutions umfasst das etwa 140 Standorte und Werke. Bosch Mobility Solutions hat rund 230.000 Mitarbeitende, fast die Hälfte sind SAP-User. In den Werken gibt es klassische kaufmännische Rollen, als auch viele Mitarbeiter in Lager, Logistik und Fertigung. Wir haben eine große Eigenfertigungstiefe. SAP wird dabei bis in die Bandbereitstellung oder die Fertigteilrückmeldung genutzt, eine sehr hohe vertikale Integration also. Die Werke sind hochgradig heterogen, auf Produktivität getrimmt und oft mit über 100 lokalen Applikationen ausgestattet, inklusive MES und spezialisierten Systemen. Machine Learning ist weit verbreitet. Die Integration in den R/3-Systemen ist komplex, viele Schnittstellen – und das alles muss dann in SAP S/4HANA auch laufen.

Ein andere Herausforderung ist unter anderem die hohe Prozessvarianz. Die Prozesse in den Werken unterscheiden sich historisch bedingt sehr stark. Beispielsweise ist der Wareneingang/-ausgang überall auf unterschiedliche Weise umgesetzt.. Ziel ist ein S/4HANA-Template, das Kernprozesse als Bosch-Standard nah am SAP-Standard abbildet – da müssen sich die Werke anpassen, daher ist hierzu auch ein umfassendes Change Management nötig. Zusätzlich laufen Non-SAP-Lösungen wie Siemens, Kinexis oder Babtec parallel. Dieses Gesamtpaket muss im Rahmen einer integrierten S/4HANA-Zielarchitektur ineinandergreifen.

 

Clean-Core-Strategie mit klarer Definition

Michael Fuchs: Die historischen Voraussetzungen hast Du schon genannt – 40 Prozent Modifikationen aus der gewachsenen R/3-Systemlandschaft, große Prozessvielfalt. Wie seid ihr das angegangen?

Stephan Brand: Ein zentraler Punkt war die Entscheidung für eine hybride Architektur. Die S/4HANA Cloud prüfen wir im Konzern, für den großen Fertigungsbereich bei uns ist sie aber noch keine Option, da spezifische Automotive-Funktionalität, Streckengeschäft und produktionsnahe Prozesse nötig sind. Deshalb starteten wir zunächst mit einem S/4-System On-Premise, nach dem Prinzip „keep the core clean“: möglichst nah am Standard, keine echten Modifikationen am Core. Innovationen werden wir über BTP-Erweiterungen in Low-Code-/No-Code-Umgebungen liefern, die schnelle Reaktionen und hohe Flexibilität ermöglichen. Langfristig wollen wir dann modularer werden, wir sind ja auch RISE-with-SAP-Kunde und wollen im Ziel-Szenario in die Private Cloud gehen.

Zweitens haben wir konzernweit definiert, was ein Prozess ist. Auf der technischen Transaktionsebene reden wir im Konzern heute alle über das Gleiche. Für Prozessketten wie Order-to-Cash oder Produce-to-Stock gibt es eine Toolchain für saubere Dokumentation, Trainings-, Testentwicklung und Referenzierung für Optimierungen, auch für zukünftige AI-Anwendungen, dazu sage ich später noch etwas.

Ein dritter wesentlicher Punkt war für uns, eine eigene Vorgehensweise zu entwickeln, wie wir Projekte umsetzen. Wir haben über 300 Projekte jährlich, kleinere und größere, und auch nicht nur mit Bezug zu SAP S/4HANA. Unsere Vorgehensweise bezeichnen wir als Stagecape-Model, mit den Stationen Design, Build, Deploy, Run. Wir erstellen die Prozessdefinition, und treffen die Entscheidungen zur Zielarchitektur und führen auch den Roll-out durch. Aber wo sind die Übergabepunkte, wenn ich Design und Build mache, an eine Deployorganisation? Was muss ich liefern? Also klassische Fragen wie in einem Implementierungsprojekt oder in der Softwareentwicklung. Wir steuern das über eine integrierte Toolchain von Signavio über ServiceNow, über Tricentis, oder was auch immer SAP und andere Anbieter liefern. Das ist für uns ein entscheidender Mehrwert und unterstützt uns bei einer industriellen Abwicklung der Projekte.

 

Migrationsstrategie: „Lean Greenfield“ als Mittelweg

Michael Fuchs: Damit kommen wir zur Migrationsstrategie: Greenfield kommt bei euch nicht in Frage, Brownfield würde bedeuten auch vieles zu zementieren, was in der Historie entwickelt wurde, aber nicht zukunftsfähig ist. Also bleibt im Prinzip eine hybride Variante, mit dem Ziel Cloud ganz klar vor Augen?

Stephan Brand: Absolut. Wir machen „Lean Greenfield“. Dazu schauen wir uns die Prozesse an, wie sie in den R/3-Systemen sind. Unterstützt übrigens durch ein Process Mining, in das wir viel investiert haben – weil es ja an einer Dokumentation der R/3-Historie mangelte. Damit prüfen wir die bestehenden Prozesse in den Altsystemen, entfernen Varianten und implementieren den de-facto-Standard. Lean Greenfield bedeutet, dass wir Altes nicht einfach kopieren (Brownfield), sondern prüfen, ob Prozesse in S/4HANA laufen sollen, auf der SAP BTP erweitert oder in Non-SAP-Lösungen ausgelagert werden.

Unser Fokus liegt auf Standardisierung – der Bosch-Mobility-Standard für alle Werke. Wenn ich über Standard rede, dann nehmen wir natürlich alle Möglichkeiten der Konfiguration, des Customizings oder an User Exits mit, die SAP bietet. So verschlanken wir unsere Prozesse. Iterativ optimieren wir bestehende Abläufe, eliminieren unnötige Schritte – beispielsweise im Extended Warehouse Management (EWM) das viel mächtiger ist als die klassische Lagerhaltung. Wir setzen dabei auf die Kernprinzipien Standardisierung, Harmonisierung, saubere Dokumentation und ein durchgängiger Integrations-Layer, um die enorme Prozess- und Systemvielfalt beherrschbar zu machen. Auch könnten ohne diese Basis eine Automatisierung oder AI-Szenarien nicht umgesetzt werden.

 

Datenqualität als Teil der Organisation

Michael Fuchs: Was natürlich mit Prozessen aus der Vergangenheit und der Heterogenität mitwächst, sind die Daten. Wie kriegt ihr denn das Thema Datenqualität in den Griff?

Stehan Brand: Wir haben erstmal klare Verantwortlichkeiten zugewiesen. Logistik, Einkauf, Vertrieb, die haben die Verantwortung für ihre Prozesse – das macht ein Prozessmanager. Für die übergeordneten Prozessketten, Order-to-Cash, Purchase-to-Pay, Budget-to-Perform usw. liegen wir mit einem Prozesskettenmanager quer darüber und stellen hier durchgängige Abläufe sicher. Das machen wir in einem kollaborativem Umfeld. Wir haben dafür sogenannte Prozesstische definiert, an denen der Prozesskettenmanager, die Prozessmanager, Architekten, das Business und vielleicht auch SAP-Berater die Entscheidung über das Prozessdesign fällen. Das ist die Prozessseite.

Die Prozesse generieren natürlich dann Daten, die Governance-Funktion für die Datenqualität liegt bei Logistik, Einkauf, Vertrieb, etc.  Darunter liegt eine Data-Lake-Architektur, in der wir Daten persistent sammeln, konsumierbar machen, auf die Anforderungen der Fachbereiche oder für Analysen zuschneiden. Das geht bei uns also Hand in Hand.

 

Einsatz von AI und Erwartungen an SAP

Michael Fuchs: Du hast das Thema AI schon angesprochen, hierzu eine Doppelfrage: was bedeutet das Thema AI, auch Generative AI, für euch bei Bosch Mobility? Und was ist in Bezug auf AI eure Erwartung an SAP?

Stephan Brand: Wir unterscheiden zwischen Use AI und Make AI: Make AI bedeutet, künstliche Intelligenz in Produkte zu integrieren – etwa beim autonomen Fahren oder bei neuen Formen der Fahrzeuginteraktion. Das ist jedoch nicht mein Fokus. Ich konzentriere mich auf Use AI, also den Einsatz von künstlicher Intelligenz für die Business User: etwa mit einem Office Companion, der den Arbeitsalltag unterstützt, oder mit Lösungen wie SAP Joule als digitalem Assistenten in der SAP-Welt. Unsere weltweite AI-Community umfasst über tausend Experten. Diese vernetzen wir über AI Days, die wir global veranstalten – der Launch im Juli war mit über tausend Teilnehmern ein großer Erfolg. Seither touren wir durch die Regionen: Indien, China, Japan, Europa. Ziel ist, Kompetenzen zu bündeln und Use Cases zentral voranzutreiben, statt dass jeder Bereich eigene Plattformen aufbaut und Proofs of Concept versanden. Wir haben bereits über 2.000 Use Cases identifiziert, die wir nun im Ideation Funnel priorisieren. Dabei konzentrieren wir uns auf die großen Themen, bei denen wir eigene Entwicklungen auf gemeinsamen Plattformen vorantreiben.

Zu der zweiten Frage: Wenn ich fünf Jahre vorausblicke – 2030 – ist unsere S/4-Transformation abgeschlossen, wir haben tausende Prozessschritte in einem standardisierten SAP S/4HANA, das als stabiles Book of Records läuft. Alle Werke und Zentralfunktionen sind umgestellt, SAP R/3 ist abgeschaltet. Darüber liegen SAP BTP- und Cloud-Innovationen: Prozesse sind über Agents weitgehend automatisiert. Der User greift im Sinne von Human-in-the-Loop nur noch ein, wenn Ausnahmefälle auftreten und ihn sein digitaler Companion deswegen anchattet. Eine Herausforderung für SAP ist nun, das so zu gestalten, dass ein wirklich komplettes Bild daraus wird. Damit das gelingt, muss SAP die Entwicklung entsprechender Skills vorantreiben – etwa „Auftrag anlegen“ als Skill eines Auftragsagenten – und Frameworks liefern, mit denen sich diese Agenten managen lassen. Denn in der Prozesskette müssen Auftrags-, Logistik- oder Finance-Agenten deterministisch agieren, basierend auf sauberen Prozessmodellen. Dafür sorgen wir auf unserer Seite mit S/4HANA als klar dokumentiertem Book of Records mit verlässlichen und plausiblen Daten.

 

Hyper-Automation über Agenten-Frameworks

Ich sehe darin eine sehr gute Kooperation, weil wir als Unternehmen viele Impulse einbringen und gleichzeitig Neues ausprobieren können. Zum Abschluss noch eine kurze Bilanz: Wir haben derzeit zwei S/4-Piloten in Wrozław, Polen, und in Budweis, Tschechien. Der zweite Pilot in Budweis hat bereits die ersten User, die nun ihre Erfahrungen mit S/4 HANA sammeln. Zudem laufen erste Agenten-Szenarien, die zeigen, dass echter Mehrwert entsteht. Mit Blick auf die Zahlen vom Anfang: Wir haben tausende SAP-User und tausende Prozesse. Einen konkreten Euro-Wert kann ich nicht nennen, aber das Potenzial von Hyper-Automation über Agenten-Frameworks ist enorm. Das macht den S/4-Business Case deutlich attraktiver – weg von einer reinen Infrastrukturmaßnahme hin zu einem echten Business Case. Für uns ist das ein vielversprechendes Signal für die Zukunft.

Michael Fuchs: Dann Dir vielen Dank für das ausgesprochen spannende Gespräch, wir könnten sicherlich noch stundenlang weiterreden – das bietet uns noch genügend Gesprächsstoff für ein Update in der Zukunft.