Sourcing im Takt der Entwicklung

Anders als klassische Sourcing-Werkzeuge begleitet die in S/4 Hana verankerte Lösung Direct Material Sourcing for Discrete Manufacturing die Beschaffung von Direktmaterial über die Entwicklungsphasen eines Bauteils hinweg, von der frühen Konstruktion bis zum Serienvertrag.

Direktmaterial folgt einer anderen Logik als indirekter Einkauf. Was in ein Fahrzeug einfließt, entsteht nicht am Verhandlungstisch, sondern in der Konstruktion: Ein Bauteil wird entworfen, als Prototyp gebaut, validiert, bemustert und erst dann in Serie beschafft.

Kosten und Machbarkeit hängen unmittelbar an Designentscheidungen, und jede Änderung an der Stückliste verschiebt die Beschaffung mit. Sourcing ist hier kein nachgelagerter Akt, sondern läuft parallel zur Produktentwicklung, über Programm-Meilensteine hinweg, mit wechselnden Spezifikationen und einer engen Abstimmung zwischen Einkauf, Engineering und Lieferant.

Grenzen klassischen Sourcings

Genau das bildet ein klassisches Sourcing-Werkzeug nicht ab. Es kennt die Ausschreibung, nicht den Entwicklungszyklus dahinter. Für einen Automobilzulieferer, dessen Wertschöpfung an technischer Komplexität und langen Produktlebenszyklen hängt, ist das keine Randfrage:

Ein einziges nicht rechtzeitig beschafftes Teil kann einen Serienanlauf gefährden. Hier lohnt eine Klarstellung, die in der SAP-Community immer wieder für Verwirrung sorgt. Der Begriff „Direct Material Sourcing“ begegnet einem an zwei Stellen, und sie meinen nicht dasselbe.

Zum einen gibt es die Product-Sourcing-Funktionalität innerhalb der SAP Ariba Strategic Sourcing Suite. Sie deckt strategisches Sourcing breit ab und ist dort zu Hause, wo der Prozess primär über die Cloud-Suite läuft. Zum anderen gibt es SAP Direct Material Sourcing for Discrete Manufacturing: eine eigenständige, in SAP S/4 Hana verankerte Anwendung, gebaut für genau die Fertigungsrealität, um die es hier geht. Beide tragen ähnliche Namen, doch sie sitzen an unterschiedlichen Stellen der Landschaft und lösen unterschiedliche Aufgaben.

Materialstamm braucht ERP-Kern

Für einen Zulieferer mit tiefer Fertigungsintegration ist die Unterscheidung keine Wortklauberei, sondern die Weichenstellung des Projekts. Wer Direktmaterial entlang der Stückliste, der Werksstruktur und des Entwicklungszyklus beschaffen will, braucht die Nähe zum ERP-Kern, in dem Materialstamm, Produktionsplanung und Kostenkalkulation ohnehin liegen. Genau diese Nähe ist der Grund, warum bei Multimatic die S/4-basierte Lösung zum Zug kam. Der Kern des Ansatzes ist die Integration. Weil die Anwendung in SAP S/4 Hana verankert ist, greift sie direkt auf das zu, was den Einkauf von Direktmaterial erst steuerbar macht: Materialstamm, Stückliste, Produktionsplanung und Kostenkalkulation sind eng integriert, nicht in eine lose angebundene Nachbarwelt ausgelagert. Bei Multimatic wird die Lösung in der Private Edition betrieben, was den nötigen Spielraum für Customizing und tiefe Integration in die gewachsene Systemlandschaft gibt, den ein reiner Public-Cloud-Ansatz in dieser Form nicht bietet.

Der praktische Unterschied zeigt sich in der Zusammenarbeit. Sourcing, Lieferantenkollaboration und Vertragsanbindung laufen in einem durchgängigen Prozess, und Engineering, Qualität und Nachhaltigkeit arbeiten innerhalb desselben Vorgangs statt darum herum. Die Lösung erlaubt zudem, über Anbindungen an die Produktentwicklung Zeichnungen und Spezifikationen entlang des Sourcing-Prozesses gemeinsam zu bearbeiten, statt sie per Mail und Tabelle hin und her zu schicken.

Jede Insel eine Schnittstelle

Punktlösungen können einzelne Schritte für sich betrachtet gut beherrschen. Doch jede zusätzlich angebundene Insel erzeugt eine neue Schnittstelle und eine neue Stelle, an der Daten verloren gehen. Der Wert der integrierten Lösung liegt darin, genau diese Nähte zu vermeiden, dort, wo Kosten- und Termindruck ohnehin am größten sind.

Roll-outs nie reibungslos

Kein Roll-out dieser Art verläuft reibungslos, und dieser war keine Ausnahme. Der Grund liegt in der Natur von Standardsoftware: Sie wird gegen Annahmen getestet, doch der Endanwender arbeitet anders. Genau an dieser Naht treten im Live-Betrieb Lücken zutage, die vorab niemand sieht. Das Projektteam übernahm hier eine doppelte Rolle. Es trug die in der Praxis gefundenen Anforderungen direkt an SAP heran und trieb Korrekturen voran, die sich auf Produktebene lösen ließen; für alles, was SAP nicht rechtzeitig schließen konnte, entwarf es Workarounds und passte die Geschäftsprozesse an, damit der Zeitplan hielt.

Konkret wurde das an einer Reihe von Anforderungen aus dem Tagesgeschäft: der Sichtbarkeit von Angeboten, die im Namen des Lieferanten erstellt werden; der Behandlung von Währungen mit fünf Nachkommastellen; der Gültigkeit von Preiskonditionen; der Benachrichtigung von Lieferanten zu Verhandlungsdetails.

Cherry Picking für alle

Vier dieser Punkte hat SAP umgesetzt, ein weiterer, die Verhandlung in Lieferantenwährung, ist für ein künftiges Release vorgesehen. Ein Beispiel ragt heraus, im Projekt „Cherry Picking“ genannt: die Möglichkeit, in einem Sourcing-Vorgang mit mehreren Positionen einzelne Positionen gezielt an unterschiedliche Lieferanten zu vergeben, etwa nach Mengen. Auch führende OEMs hatten diese Funktion angefragt; SAP nahm sie daraufhin in einen Standard-Release auf. Was bei einem Kunden als Anforderung begann, steht damit der gesamten Anwenderbasis zur Verfügung.

Wo der Standard nicht griff, entstanden maßgeschneiderte Lösungen, etwa ein strukturiertes Cost-Breakdown-Template als Grundlage für vergleichbare Kostenaufschlüsselungen. So floss die Praxiserfahrung eines Zulieferers zurück in das Produkt. Mehrere Anforderungen wurden Teil des Standards, von dem künftige Anwender profitieren.

Prozessverständnis als Hürde

Die vielleicht wichtigste Erkenntnis des Projekts ist keine technische. Kurz vor Go-live zeigte sich, dass die größte Hürde nicht im Werkzeug lag, sondern im Prozessverständnis: darin, wie unterschiedlich Teams und Standorte denselben Ablauf handhaben. Eine Software führt einen Prozess nur so gut aus, wie er zuvor verstanden, vereinheitlicht und getragen wird.

Genau hier lag ein erheblicher Teil der Arbeit. Kostenstrukturen und Lieferantendaten mussten auf einen gemeinsamen Stand gebracht werden, damit ein Vergleich auf gleicher Basis überhaupt möglich wird, etwa über harmonisierte Standards für die Kostenaufschlüsselung. Verantwortlichkeiten für den End-to-End-Prozess mussten klar zugeordnet, gewachsene Eigenheiten hinterfragt und in eine belastbare, standortübergreifende Arbeitsweise überführt werden. Das ist weniger eine Frage der Konfiguration als eine der Ausrichtung. Wer ein System dieser Reichweite einführt, führt zugleich eine neue Art zu arbeiten ein, und dieser Teil entscheidet mit darüber, ob sich der technische Aufwand am Ende auszahlt.

Ein Werkzeug nicht für jeden

So leistungsfähig die Lösung ist, sie passt nicht zu jedem. Sie ist für Direktmaterial gebaut, nicht für indirekten oder Dienstleistungseinkauf, und sie entfaltet ihren Wert erst dort, wo Größe und Komplexität es rechtfertigen: bei OEMs und anderen Herstellern komplexer, konstruktionsintensiver Produkte, mit tiefen Stücklisten, enger Abstimmung zwischen Entwicklung und Einkauf und einem Lieferantennetz, das solche Prozesse trägt. Für einen kleineren Zulieferer mit überschaubarem Teilespektrum wäre sie überdimensioniert. Diese Einordnung gehört zu jeder seriösen Entscheidung dazu: Nicht jedes Unternehmen braucht dieses Werkzeug, aber die, die es brauchen, brauchen genau dieses.

Wo es passt, zeigen die von SAP über frühe Anwender erhobenen Benchmarks, was möglich ist: bis zu 40 Prozent kürzere Sourcing-Zyklen, 15 Prozent schnellere Time-to-Market für neue Produkte und zwischen zwei und fünf Prozent geringere Direktmaterialkosten. Das sind Benchmarks, keine Ergebniszahlen von Multimatic. Der Zulieferer ist gerade erst live gegangen; belastbare eigene Kennzahlen wird die Zeit nach dem Go-live liefern, nicht der Tag danach.

Prädiktive Szenarien

Mit dem Go-live ist das Fundament gelegt, nicht der Schlusspunkt gesetzt. Die eigentliche Wirkung entsteht erst im Betrieb, wenn aus sauber integrierten Prozessen belastbare Daten werden, Sourcing-Entscheidungen sich auf verlässliche Kosten- und Lieferantenanalysen stützen und aus reaktivem Einkauf schrittweise ein datengetriebener wird.

Prädiktive Szenarien und automatisierte Empfehlungen markieren den Horizont; der Weg dorthin bemisst sich in Monaten. Was dieses Projekt hinterlässt, ist vor allem eine belastbare Grundlage: eine Lösung, die tief genug im System sitzt, um mitzuwachsen, und ein Prozess, der die Praxis so ernst nimmt, dass er sie in das Produkt zurückspiegelt.

Zum Partnereintrag: