SAP PLM S/4HANA
Inhaltsverzeichnis
SAP PLM unter S/4HANA: Was ändert sich für Produktentwicklung und Engineering?
Wer von SAP ECC auf S/4HANA wechselt, beschäftigt sich früher oder später auch mit den bestehenden PLM-Prozessen. Dabei geht es selten nur um einzelne Funktionen. Über Jahre sind Zusammenhänge zwischen Materialstämmen, Stücklisten, Dokumenten, CAD-Daten, Änderungsnummern, Klassifizierung und Freigaben entstanden. Dazu kommen Schnittstellen und Eigenentwicklungen, die teilweise tief in den Engineering-Prozessen verankert sind.
Die Frage lautet deshalb nicht einfach: Läuft SAP PLM auch unter S/4HANA?
Interessanter ist, welche bestehenden Prozesse weitergeführt werden können, wo SAP neue Ansätze bietet und welche gewachsenen Strukturen man besser nicht unverändert übernimmt.
SAP PLM verschwindet mit S/4HANA nicht
Viele bekannte PLM-Objekte bleiben auch in S/4HANA relevant. Materialien, Stücklisten, Dokumentinfosätze, Klassen, Merkmale und Änderungsstände bilden weiterhin wichtige Bestandteile der Produktbeschreibung.
Das ist gerade für Unternehmen wichtig, die SAP PLM seit vielen Jahren einsetzen. Eine S/4HANA-Transformation bedeutet nicht automatisch, dass die vorhandene Produktstruktur neu aufgebaut werden muss.
Trotzdem verändert sich das Umfeld.
Neue Fiori-Anwendungen kommen hinzu. Das Änderungsmanagement entwickelt sich weiter. Externe PLM-Systeme lassen sich anders integrieren. Engineering und Fertigung können enger miteinander verbunden werden. Gleichzeitig stellt sich bei älteren Eigenentwicklungen die Frage, ob sie noch zur zukünftigen S/4HANA-Architektur passen.
Ein PLM-System sollte deshalb nicht nur technisch konvertiert werden. Es lohnt sich, die dahinterliegenden Prozesse mit zu betrachten.
Material, Stückliste und Dokument bleiben eng miteinander verbunden
Ein großer Teil der Produktinformation steckt nicht in einem einzelnen SAP-Objekt.
Ein Material beschreibt das Produkt oder die Baugruppe. Die Stückliste enthält die Struktur. Zeichnungen und Spezifikationen liegen als Dokumente vor. Klassen und Merkmale ergänzen technische Eigenschaften. Änderungen sorgen dafür, dass neue Produktstände kontrolliert eingeführt werden.
Diese Beziehungen sind auch unter S/4HANA entscheidend.
Gerade bei gewachsenen Systemen findet man allerdings häufig unterschiedliche Vorgehensweisen. Eine Abteilung verknüpft Zeichnungen direkt mit dem Material. Eine andere verwendet Dokumentpositionen in der Stückliste. Bestimmte technische Informationen liegen in der Klassifizierung, andere in kundeneigenen Tabellen oder externen Systemen.
Solche Unterschiede fallen im Tagesgeschäft oft kaum auf. Bei einer S/4HANA-Transformation werden sie plötzlich relevant.
Dann muss geklärt werden, welches System beziehungsweise welches Objekt zukünftig welche Information führen soll.
Welche Zeichnung gehört zum freigegebenen Produktstand, und welches System führt die technischen Merkmale? Klären Sie diese Fragen vor Ihrer S/4HANA-Umstellung. Wir prüfen mit Ihren Fachbereichen die bestehenden Datenstrukturen und legen fest, wie Materialstamm, Stückliste, Dokumente und Klassifizierung künftig zusammenspielen.
Das Änderungsmanagement verdient besondere Aufmerksamkeit
Produktänderungen gehören zu den Prozessen, die bei einer PLM-Betrachtung schnell komplex werden.
Eine Konstruktion wird geändert. Davon sind mehrere Materialien und Stücklisten betroffen. Zeichnungen müssen angepasst werden. Die Produktion soll erst ab einem definierten Zeitpunkt mit dem neuen Stand arbeiten. Einkauf und Qualitätssicherung benötigen ebenfalls Informationen. Vor der Umsetzung muss die Änderung möglicherweise durch mehrere Stellen geprüft und freigegeben werden.
Im klassischen SAP-Umfeld wurden solche Szenarien häufig über Änderungsnummern und Engineering Change Management abgebildet.
Unter S/4HANA kommt mit dem Change Record ein weiterer Ansatz hinzu.
Ein Change Record kann unterschiedliche Änderungsobjekte zusammenfassen und den Änderungsprozess organisatorisch begleiten. Status, Verantwortlichkeiten, Freigaben und Laufwege lassen sich damit stärker in einen gemeinsamen Prozess einbinden.
Für bestehende Systeme ergibt sich daraus eine wichtige Frage: Welche Aufgaben sollen weiterhin über die klassische Änderungsnummer gesteuert werden und wo ist ein Change Record sinnvoll?
Die Antwort hängt vom Prozess ab. Eine rein technische Gültigkeitssteuerung stellt andere Anforderungen als eine Produktänderung, die zunächst bewertet, verschiedenen Fachbereichen vorgelegt und anschließend kontrolliert umgesetzt werden muss.
Deshalb sollte man Change Record und Änderungsnummer nicht nur als zwei alternative SAP-Funktionen betrachten. Sie erfüllen unterschiedliche Aufgaben und können innerhalb eines Änderungsprozesses zusammenspielen.
Vom Engineering in die Fertigung: EBOM und MBOM
Ein weiterer Punkt liegt an der Grenze zwischen Konstruktion und Produktion.
Die Produktstruktur aus dem Engineering entspricht nicht zwangsläufig der Struktur, mit der später gefertigt wird. Die Konstruktion denkt beispielsweise in funktionalen Baugruppen. Die Fertigung benötigt eine Struktur, die zu Montageabläufen, Arbeitsplätzen und Produktionsprozessen passt.
>> Damit entsteht die bekannte Trennung zwischen Engineering BOM und Manufacturing BOM.
Das eigentliche Problem ist dabei selten die einmalige Überführung einer Stückliste.
Schwieriger wird es bei Änderungen.
Wenn die Konstruktion eine Baugruppe ändert, muss nachvollziehbar sein, welche Auswirkungen dies auf die Fertigungsstruktur hat. Neue Komponenten kommen hinzu, andere entfallen oder werden ersetzt. Gleichzeitig darf eine Änderung nicht unkontrolliert in eine bereits laufende Produktion gelangen.
Genau hier zeigt sich, warum PLM und ERP nicht als getrennte Welten betrachtet werden sollten.
Für Unternehmen, die ihre Produktstrukturen bisher über individuelle Programme, Excel-Listen oder manuelle Abstimmungen zwischen Konstruktion und Arbeitsvorbereitung synchronisieren, lohnt sich im S/4HANA-Projekt eine genaue Betrachtung dieses Übergangs.
Was ändert sich bei CAD und SAP ECTR?
In vielen Engineering-Unternehmen beginnt die Produktentstehung nicht in SAP, sondern im CAD-System.
Konstrukteure arbeiten beispielsweise mit Siemens NX, Creo, CATIA, SolidWorks oder Inventor. Die daraus entstehenden Modelle, Zeichnungen und Strukturen müssen anschließend mit SAP-Objekten zusammengebracht werden.
SAP ECTR bildet dafür die Verbindung zwischen Authoring-Systemen und SAP.
Bei einer S/4HANA-Transformation sollte deshalb nicht nur geprüft werden, ob CAD-Dokumente weiterhin geöffnet werden können. Interessanter ist der gesamte Ablauf.
Fragen unserer Kunden:
Wann entsteht ein SAP-Material?
Wer legt den Dokumentinfosatz an?
Wie werden CAD-Strukturen mit SAP-Stücklisten synchronisiert?
Wie erfolgt die Freigabe?
Welche Informationen werden aus dem CAD-System übernommen?
Und was passiert, wenn sich die Konstruktion später ändert?
>> Gerade ältere CAD-Integrationen enthalten häufig kundeneigene Logik. Diese sollte bei der Umstellung separat bewertet werden.
Wenn das führende PLM-System nicht SAP ist
Nicht jedes Unternehmen verwaltet seine Engineering-Strukturen vollständig in SAP.
In vielen Systemlandschaften arbeiten Konstruktion und Produktentwicklung beispielsweise mit Siemens Teamcenter, PTC Windchill, 3DEXPERIENCE oder einem anderen PLM-/PDM-System. SAP übernimmt anschließend die Daten, die für Einkauf, Produktion, Logistik und weitere Geschäftsprozesse benötigt werden.
Dann wird die Systemgrenze zum eigentlichen PLM-Thema.
Fragen unserer Kunden:
Wo wird das Material angelegt?
Welches System führt die Engineering-Stückliste?
Wo findet die Freigabe statt? Welche Änderungsstände werden nach SAP übertragen?
Wer ist für Dokumente verantwortlich?
Und wie wird verhindert, dass dieselbe Information in zwei Systemen unterschiedlich gepflegt wird?
>> Solche Fragen sollten vor der technischen Schnittstellendefinition beantwortet werden.
Eine Integration kann Daten zwischen zwei Systemen übertragen. Sie löst aber keine unklare Datenhoheit.
S/4HANA bietet zusammen mit den aktuellen PLM-Integrationsmöglichkeiten neue Ansätze für solche Architekturen. Das macht eine bestehende Schnittstelle nicht automatisch überflüssig. Es ist aber ein guter Anlass zu prüfen, ob der bisherige Datenaustausch noch zur gewünschten Systemlandschaft passt.
Dokumente sind Teil der Produktstruktur
Zeichnungen, Spezifikationen, Berechnungen, Prüfunterlagen und weitere technische Dokumente begleiten ein Produkt oft über seinen gesamten Lebenszyklus.
Deshalb gehört auch SAP DMS in die PLM-Betrachtung.
Ein Dokumentinfosatz kann mit einem Material verbunden oder innerhalb einer Stückliste verwendet werden. Dokumente lassen sich versionieren, klassifizieren und über Status steuern. Dadurch bleibt die technische Dokumentation mit dem jeweiligen Produktkontext verbunden.
In der Praxis stellt sich häufig weniger die Frage, ob diese Möglichkeiten vorhanden sind. Entscheidend ist, wie einfach die Anwender an die benötigten Dokumente kommen.
Ein Servicetechniker möchte nicht mehrere Suchmasken durchlaufen, um die Unterlagen einer Maschine zu finden. Die Fertigung benötigt die gültigen Dokumente für eine Baugruppe. Ein Projektmitarbeiter möchte die Dokumentation seines Projekts strukturiert sehen.
Genau an solchen Stellen treffen PLM-Struktur und Benutzerführung aufeinander.
Wer gleichzeitig Easy DMS ablöst oder seine DMS-Prozesse unter S/4HANA neu gestaltet, sollte beide Themen deshalb gemeinsam betrachten.
Fiori allein macht noch keinen neuen PLM-Prozess
Mit S/4HANA verändert sich auch die Benutzeroberfläche. Viele Funktionen werden über Fiori bereitgestellt und stärker in den jeweiligen Arbeitskontext eingebunden.
Das ist für gelegentliche Anwender häufig ein deutlicher Fortschritt.
Trotzdem sollte ein bestehender Prozess nicht einfach auf eine neue Oberfläche übertragen werden, ohne ihn vorher zu hinterfragen.
Ein Konstrukteur, der täglich mit umfangreichen Produktstrukturen arbeitet, hat andere Anforderungen als ein Einkäufer, der lediglich eine technische Information zu einem Material benötigt. Ein Änderungskoordinator wiederum muss den Status mehrerer Änderungsobjekte und beteiligter Fachbereiche im Blick behalten.
Die Oberfläche sollte sich an diesen Aufgaben orientieren.
Manchmal reicht eine Standard-Fiori-App. An anderer Stelle wird eine spezialisierte Oberfläche benötigt. Und gelegentlich stellt sich heraus, dass der bisherige Prozess selbst unnötig kompliziert war.
Product Compliance beginnt nicht erst beim Versand
Eine weitere Entwicklung betrifft die Verbindung von PLM und Product Compliance.
Compliance-Anforderungen wurden früher häufig relativ spät im Produktprozess betrachtet. Das Produkt war bereits entwickelt, Materialien und Komponenten waren festgelegt und anschließend wurde geprüft, ob regulatorische Anforderungen erfüllt werden.
Das kann teuer werden.
Wenn erst kurz vor Markteinführung auffällt, dass eine Komponente bestimmte Stoffanforderungen nicht erfüllt oder für einen Zielmarkt nicht geeignet ist, sind Konstruktion und Beschaffung möglicherweise bereits weit fortgeschritten.
Deshalb wird die Verbindung zwischen Produktentwicklung und Compliance wichtiger.
Informationen zu Materialien, Komponenten und Produktstrukturen können bereits während der Entwicklung für Compliance-Prüfungen genutzt werden. Änderungen an einer Stückliste sind damit nicht nur eine technische Frage. Sie können auch Auswirkungen auf Marktgängigkeit, Stoffbeschränkungen oder andere regulatorische Anforderungen haben.
Für Unternehmen aus Chemie, Pharma, Life Sciences, Kosmetik und Lebensmittelindustrie ist diese Verbindung besonders relevant. Aber auch im Maschinenbau und in der Elektronik steigen die Anforderungen an Material- und Produktinformationen.
In der Prozessindustrie sieht PLM anders aus
PLM wird häufig aus Sicht eines Maschinenbauers beschrieben: CAD-Modell, Zeichnung, Material, Stückliste.
Für die Prozessindustrie greift das zu kurz.
Bei einem Chemie-, Pharma-, Kosmetik- oder Lebensmittelunternehmen stehen andere Objekte und Abläufe im Mittelpunkt. Spezifikationen, Rezepturen, Formulierungen, Versuche und Qualitätsdaten spielen eine größere Rolle.
Auch hier muss Produktentwicklung mit den nachfolgenden Prozessen verbunden werden.
Eine entwickelte Rezeptur soll später produziert werden können. Rohstoffe und Spezifikationen müssen zusammenpassen. Qualitätsanforderungen gehören in den Prozess. Gleichzeitig sind regulatorische Informationen zu berücksichtigen.
Damit entsteht eine Prozesskette von der Idee über Rezeptur und Versuch bis zu Produktion, Qualität und Compliance.
Gerade bei einer S/4HANA-Transformation sollte deshalb nicht versucht werden, ein PLM-Konzept aus der diskreten Fertigung einfach auf die Prozessindustrie zu übertragen.
Eigenentwicklungen sind häufig der schwierigere Teil der Migration
Die Standardobjekte sind bei einer S/4HANA-Analyse meist schnell identifiziert.
Aufwendiger wird es bei den Dingen, die über Jahre darum herum entstanden sind.
Eigene Stücklistenprogramme, kundenspezifische Freigaben, Reports, BADIs, User Exits, Workflows, Schnittstellen oder Tabellen gehören in vielen Unternehmen selbstverständlich zum PLM-Alltag. Manche davon bilden Anforderungen ab, die der Standard tatsächlich nicht erfüllt. Andere existieren hauptsächlich deshalb, weil ein Prozess vor vielen Jahren einmal auf diese Weise umgesetzt wurde.
Bei der S/4HANA-Umstellung sollte daher nicht nur gefragt werden, ob eine Entwicklung technisch kompatibel ist.
Die interessantere Frage lautet: Brauchen wir sie noch?
Wo SAP heute andere Möglichkeiten bietet, kann eine Rückkehr zum Standard sinnvoll sein. Wo weiterhin Erweiterungen erforderlich sind, sollte geprüft werden, wie diese zur zukünftigen Erweiterungsstrategie und zum Clean-Core-Ansatz passen.
Ein typisches Szenario aus dem Maschinenbau
Ein Maschinenbauer verwaltet Materialien und Stücklisten in SAP. Die Konstruktion liefert CAD-Daten und Zeichnungen. Änderungen werden über Änderungsnummern gesteuert. Daneben existieren eigene Programme für Stücklistenvergleiche und Freigaben.
Im Rahmen der S/4HANA-Transformation könnte man versuchen, diese Landschaft technisch möglichst unverändert zu übernehmen.
Damit wäre das System zwar migriert. Der eigentliche Prozess wäre aber noch derselbe.
Sinnvoller ist es, an den Übergängen genauer hinzusehen.
Wie gelangt eine Konstruktionsänderung in die Fertigung? Wer bewertet ihre Auswirkungen? Welche Dokumente gehören zum neuen Produktstand? Wann darf die Produktion den geänderten Stand verwenden? Wie sieht der Einkauf, dass sich eine Komponente geändert hat? Und wie lässt sich später nachvollziehen, warum eine Änderung durchgeführt wurde?
Aus diesen Fragen ergibt sich die zukünftige PLM-Architektur wesentlich besser als aus einer Liste vorhandener Transaktionen.
Vor der S/4HANA-Umstellung zuerst die Produktentstehung verstehen
Eine PLM-Bestandsaufnahme sollte deshalb nicht bei Tabellen und Customizing beginnen.
Hilfreicher ist es, ein reales Produkt durch den Prozess zu verfolgen.
Wo entsteht es? Welche Daten werden im Engineering erzeugt? Wann wird ein Material angelegt? Wie entsteht die Stückliste? Wo liegen Zeichnungen und Spezifikationen? Wie werden Änderungen beantragt und freigegeben? Wann gelangen die Daten in Produktion und Einkauf? Welche Informationen werden später für Service, Qualität oder Compliance benötigt?
Danach lässt sich die technische Landschaft wesentlich besser bewerten.
Es wird sichtbar, welche Funktionen tatsächlich benötigt werden, wo Informationen doppelt gepflegt werden und an welchen Stellen Medienbrüche oder manuelle Abstimmungen entstehen.
Erst dann sollte entschieden werden, welche bestehenden SAP-PLM-Funktionen übernommen, welche Prozesse neu gestaltet und welche Erweiterungen weiterhin benötigt werden.
SAP PLM unter S/4HANA ist mehr als eine technische Conversion
Ein funktionierendes PLM lässt sich nicht daran messen, ob Materialstamm, Stückliste und Dokumentinfosatz nach der Migration noch vorhanden sind.
Entscheidend ist, ob Produktinformationen vom Engineering bis in die nachfolgenden Prozesse zuverlässig weitergegeben werden.
S/4HANA bietet dafür die Gelegenheit, gewachsene Strukturen neu zu betrachten. Nicht alles muss verändert werden. Vieles, was sich über Jahre bewährt hat, kann weiter genutzt werden.
Aber dort, wo Engineering und Fertigung nur über manuelle Abstimmungen verbunden sind, Änderungen schwer nachvollziehbar bleiben oder dieselben Produktinformationen in mehreren Systemen gepflegt werden, lohnt sich eine genauere Betrachtung.
smart-plm Aigner unterstützt Unternehmen bei der Weiterentwicklung ihrer SAP-PLM-Prozesse und bei der S/4HANA-Transformation. Dabei betrachten wir nicht nur einzelne SAP-Funktionen, sondern das Zusammenspiel von Produktstruktur, Änderungsmanagement, Dokumenten, Engineering, Produktion und Product Compliance.
Ihr Ansprechpartner
Sie möchten wissen, welche Auswirkungen S/4HANA auf Ihre bestehende SAP-PLM-Landschaft hat?
