Das Posting von Oleg Shilovitsky  PDM. Pre-configured? Painless? hat mich  angeregt, diesen Beitrag zu schreiben. Meinungen, ob es Out-of-the-Box oder auch Turnkey Lösungen geben kann und soll, gibt es mittlerweile zahlreiche. Nur noch nicht von mir (-;

Eigentlich ist die Sache ganz einfach: Ein Begriff wie Out-of-the-Box steht für Standardisierung, und sowohl der Hersteller als der Anwender wird – wenn er bei Verstand ist – nach der Devise verfahren: „So viel Customizing wie nötig, so wenig wie möglich“.

Das Thema ist also in den seltensten Fällen eines für die Farben Schwarz oder Weiß. Jedenfalls kenne ich keine Software selbst für die Textverarbeitung oder was auch immer, bei dem man nicht das Eine oder Andere an seine eigenen Belange anpassen will und kann. Die Frage ist nicht „Ob?“ sondern „In welchem Umfang?“ und vor allem „Wie?“. In jedem Fall haben die Hersteller den Schlüssel in der Hand, ihren Kunden das Leben so einfach wie möglich zu machen, aber auch keine falsche Erwartungshaltung zu wecken.

Wie viel Customizing?

PDM- und PLM-Lösungen sind keine Finanzbuchhaltungs- oder Warenwirtschaftsysteme, deren Verfahren in weiten Teilen durch externe Regularien oder anerkannte Algorithmen bestimmt werden. PDM/PLM soll den Innovationsprozess unterstützen, der von Haus aus eine kreative Angelegenheit ist. Vor allem hier (wo sonst?) werden Unternehmen ihre individuellen und besonderen Fähigkeiten im Wettbewerb beibehalten und ausspielen wollen.

Ein CAD-Datenmanagement wird hoffentlich wenig Anpassung erfordern. Je umfassender jedoch der Innovationsprozess unterstützt werden soll, desto weitreichender werden die gewünschten Anpassungen an individuelle Anforderungen durch den Innovationsprozess des Kunden sein. Vordefinierte „Best Practices“ können einem Unternehmen helfen, aber wenn jedes Unternehmen sich mit Haut und Haaren solchen „Best Practices“ unterordnen würde: Wo bliebe da der Wettbewerbsvorteil?

Wie einfach ist das Customizing?

Wenn man Customizing also nicht wegdefinieren kann, dann soll es bitteschön so einfach und so wartungs- und Release-sicher wie möglich sein. Der Worst Case ist, dass man alles programmieren muss, nur Programmierer die Anpassungen verstehen und pflegen können und dass die Anpassungen beim nächsten Update teuer durchforstet und erneut angepasst werden müssen. Der Best Case sind vordefinierte Stellhebel im System, die es sogar erfahrenen Fachanwendern erlauben, ein System nach ihren Belangen anzupassen. Ein gutes Bespiel sind sogenannte Business Rules, die in weiten Teilen das Systemverhalten beeinflussen, in einer Bibliothek übersichtlich vorgehalten und in einer Form geschrieben werden können, die auch Nicht-Programmierer schnell verstehen und nutzen können.

Falsche Erwartungshaltung?

Welcher Hersteller legt schon gleich den Finger in die Wunde und offenbart seinem potenziellen Kunden über Gebühr, dass individuelle Anforderungen eben auch Geld und Mühe kosten? Wird allerdings ein Projekt an dieser Stelle nicht richtig aufgesetzt, sind Reibung, Zeitverzug und Frustration auf allen Seiten vorprogrammiert. Zaubern kann niemand, und es ist Aufgabe der Profis beim Hersteller oder Berater, den Kunden hier an die Hand zu nehmen. Im Zweifel muss fester gedrückt werden!

Was ist ihre Meinuing: Wann machen Out-of-the-Box Lösungen für den Innovationsprozess Sinn?

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!