Dieses “P”, das ich meine, ist ein treuer Bekannter von uns allen. Es markiert den phonetisch knackigen Anfang von “PLM” und meint natürlich das “Product” in “Product Lifecycle Management”. Scheint mir also schon ein sehr dinghaft bezogenes Konzept zu sein, dieses PLM. Aber das finde ich eben viel zu kurz gegriffen.

 

Ohne “Process” kein “Product”

PLM-Konzepte sind in der Regel produktgetrieben. Sie haben Ihren Ursprung in Entwicklungsabteilungen und hatten in den guten alten Zeiten meist Ihren Ausgangspunkt in der Verwaltung von CAD-Daten. Heute stehen Produktstrukturen, Varianten und Konfigurationen im Brennpunkt. Dazu besitzen (gute) PLM-Konzepte eine sehr präzise Steuerungslogik, um den Reifegrad der Produkte kontinuierlich voranzutreiben – bis zum SOP, wo dann alles “i.O.” sein sollte.

Glücklicherweise sind auch die Zeiten vorbei, in denen dann das Entwicklungsergebnis über die hohe Mauer ‘rüber und der Produktion vor die Füße geworfen wurde. Aber einen deutlichen Bruch in den Konzepten und real existierender Dokumentation muss man dennoch festhalten: Wo finden wir denn die Produktions-, Logistik- und Prüfprozesse (…) ?

 

Nein, die Antwort lautet nicht ERP…

Wenn’s um Arbeitspläne, Lieferpläne, Versorgungskonzepte geht, sind ERP- / PPS- / SCM-Systeme, Leitstände, Kanban-Karten an der Reihe, stimmt’s? – Jein.

Ja: In diesen Systemwelten finden sich die operativ gelebten Abläufe mit Ihren Parametern (Bedarfen, Zeiten, …) und Kennzahlen (Ausbringung, Umschlagshäufigkeit, Liegezeiten, …) wieder.

Nein: In diesen Systemwelten werden die Prozesse aber nicht entwickelt! Denn sie haben nicht die Flexibilität und Beweglichkeit, die es in einer (frühen) Entwicklungsphase braucht (sonst gäbe es ja auch kein PLM).

Jawohl! Entwicklung! Nicht nur Produkte werden aus der Taufe gehoben und Schritt für Schritt zu Reife gebracht, parallel zu ihnen entstehen ebenso Schritt für Schritt die Herstellungsprozesse.

 

Entwicklung hat nicht nur mit Schrauben zu tun, PLM auch nicht

Parallel zur Produktentwicklung – und in enger Abstimmung – werden Prozesse entwickelt. Da wird an der Anlagenbelegung gefeilt, in verketteten Produktionsabläufen an den Taktzeiten und Arbeitsinhalten gedreht, da muss sich eine Werkslogistik Gedanken über Bevorratung und Lieferwege machen usw. usf. – Das alles ist weder neu noch überraschend – meine Frage: Warum dokumentiert man diese Entwicklungsthemen nicht auch ganz selbstverständlich in PLM?

In der Realität der Prozessentwicklung findet man die allgegenwärtigen Excel-Welten vor. Mehr oder minder geregelt werden Abzüge der Entwicklungsstückliste gezogen, umstrukturiert (die berühmte Produktionsstückliste erzeugt, wenn nicht im PLM abgebildet) und gegen die Prozesse gefahren. Prozess-Strukturen werden entworfen, Reihenfolgen definiert, Alternativen eingeplant…

Wenn Sie mich fragen: PLM Kernfunktionalität!

 

Let’s do PPLM!

Ich habe mir vorgenommen, in Zukunft nur noch “PPLM” zu sagen – tun Sie’s auch!

Was ich damit sagen will: Dass wir ganz grundsätzlich die Entwicklung von Produkt und Prozess verknüpfen und dokumentieren müssen. Und wenn wir das einmal geschafft haben, können wir uns auch auslandende Gedanken über Virtuelle Fabriken und durchgängige Informationsflüssen vom Reißbrett bis zur Drehbank machen (hatten wir übrigens schon mal in den 80ern).

PPLM-Systeme können parallele Strukturen miteinander verknüpfen und abgleichen. Das gilt für Entwicklungs- und Produktionsstücklisten genauso wie für Stücklisten und Prozessstrukturen.

 

Es lohnt sich

Haben wir einmal diesen Zusammenhang aufgebaut, machen wir uns das Leben gleich deutlich leichter. Nehmen wir als Beispiel nur das derzeitige Schreckensbild von der überbordenden Produktvarianz, die ja auch auf der Prozessseite abgefangen werden will: Im PPLM haben wir eine Konfigurationslogik, die Produkt- und Prozessvarianten ansteuert. D.h. wir können konsistente Konfigurationen beider Sichtweisen erzeugen und abprüfen (alle Teile in der Montage verplant? im Versorgungsplan? usw.).

Die Potenziale standardisierter Produkt- und Prozessbausteine hebe ich mir sogar lieber für einen eigenen Blog-Eintrag auf…

 

Die Möglichkeiten sind da – wir müssen’s nur tun. In diesem Sinne – die besten Wünsche für ein prozessorientiertes 2011!

Vorweg: es geht in diesem Beitrag nicht um Normteile oder andere Dinge, die Produkte standardisieren, sondern um solche, die festlegen, auf welche Art und Weise Produkte entwickelt werden. Das ist ein weites Feld, angefangen bei der Frage, wer den Standard vorgibt, etwa das eigene Unternehmen, der Kunde, Normungsgremien usw. bis hin zu Frage, was standardisiert wird wie z.B. Verfahrensabläufe, Benennungskataloge, oder Nummerungsysteme.

Die meisten von uns werden bestimmte Standards lieben und andere hassen. Die guten sind die, die mir persönlich erkennbar nützen, etwa weil sie mir helfen, mich leichter zurechtzufinden. Und die schlechten sind eben solche, die eher hinderlich für meine Aufgaben sind.

Gute Standards stellen einfach „Best Practices“ dar. Bei schlechten Standards erkennen die Anwender, dass man das anders und besser machen kann. Gute Standards fallen nicht vom Himmel und selbst jahre- oder jahrzehntelange Gremienarbeit ist keine Erfolgsgarantie, siehe den „Standard for the Exchange of Product model data“ (ISO 10303 STEP).

Jeder Entwickler macht eigentlich nicht anders als einen Standard für eine gewünschte Funktion zu schaffen. Als Entwickler von gewarteter „Standard“ PLM-Software haben wir die Aufgabe, Standards für die Produktentwicklung zu schaffen. Das ist anspruchsvoll, denn jede Produktentwicklung lebt davon, abseits ausgetretener Pfade Innovatives zu schaffen. PLM-Projekte und PLM-Software greifen unter Umständen tief in die Art und Weise ein, wie Unternehmen und  Mitarbeiter Produkte entwickeln. Im Unterschied zu bloßen Regelwerken, wie sie in vielen Unternehmen anzutreffen sind, ist die Standardisierung  gleich in die Werkzeuge eingebaut, die die Anwender nutzen. Je feinkörniger hier die Vorgaben sind, desto schwieriger wird es, die Bedürfnisse der Anwender praxisgerecht zu erfüllen.

Zusammenfassend meine Meinung:

1. Gute Standards stellen Best Practices dar, deren Nutzen  für Anwender offensichtlich ist.
2. Standards zu entwickeln ist schwierig. Der Schlüssel zum Erfolg liegt in der Fähigkeit, Standards beruhend auf Erfahrungen in nicht zu kurzen und nicht zu langen Abständen zu verbessern.
3. Standards haben auch in der Produktentwicklung ihre Berechtigung. Sie helfen z.B., Compliance-Richtlinien zu beachten, über Abteileingen und Disziplinen hinweg besser zu kommunizieren und Zeit dadurch zu sparen, dass man das Erfahrungswissen anderen nutzen kann.
4. Standardisierung in der Produktentwicklung erfordert besondere Umsicht: Schließlich sollen Kreativität und Flexibilität nicht unter die Räder kommen.

(claim token 9CRX6ENYMPWC)