Author: Roland Drewinski

Lean Compliance

Regelkonformität in der Produktentwicklung

Vor eine paar Monaten habe ich zu dem Thema Compliance einen Beitrag im Produktdatenjournal veröffentlicht. Das Thema ist „heiß“. So sieht beispielsweise die Ernst & Young Studie „Strategic Business Risk: 2008 – The Top 10 Risks for Global Business“ das Thema Compliance die Liste der zehn wichtigsten Unternehmensrisiken anführen. Versäumen Unternehmen, bestimmte Regeln einzuhalten, kann dies den Ausschluss von bestimmten Märkten und Ausschreibungen bedeuten („No data, no market“) oder durch die Produkthaftung substantielle juristische und finanzielle Folgen nach sich ziehen.

Dass dies mittlerweile sehr konkrete Risiken sind, bemerken wir bei vielen Unternehmen, in denen wir zu tun haben – eindrucksvoll zu sehen, welchen Stellenwert das Thema bekommen hat!

Zwar ist beispielsweise die ISO 9000 ein alter Hut, aber die aktuellen Dokumentations- und Qualitätsmanagementvorschriften  stellen heute deutlich konkretere Anforderungen an die Entwicklungsprozesse. Die Maschinenrichtlinie, FDA Vorschriften, die ISO/TS 16949 usw. lassen dabei zusammengenommen keine Branche verschont.

Fluch oder Segen?

Wie gehen Unternehmen damit um? Die Gefahr ist groß, sich vom Regen unter die Traufe zu stellen, stülpt man abstrakte Compliance-Anforderungen schematisch den eigenen Prozessen über. Wie kennen Beispiele, wo der Entwicklungsprozess sich durch eine Unzahl an Formularen dramatisch verlangsamt hat. Dabei behaupte ich: Viele Compliance-Vorschriften  sind im Kern für die Produktentwicklung ein Segen, weil sie auf eine „Good Manufacturing Practice“ zielen: transparente Prozesse und jederzeit einfach nachvollziehbare Ergebnisse. Ist das „ob“ keine Frage mehr, sollte das „wie“ umso sorgfältiger hinterfragt werden. Segensreich wird das Ganze nur dann, wenn

  • die Vorschriften „richtig“, d.h. passend zu den eigenen Prozessen und so schlank wie möglich interpretiert werden. In vielen Fällen lässt sich das „wie“ aus den Regelwerken oft nicht klar ableiten. Hier sind Unternehmen leider auf sehr dünn gesätes Expertenwissen angewiesen.
  • keine separaten Mechanismen verwendet werden, sondern Quality Gates, Deliverables, das Änderungs- und Konfigurationsmanagement usw. zum Diener zweier Herrn gemacht werden: des eigentlichen PEP und der Compliance-Anforderungen. Selbstredend bieten sich hier PLM Plattformen an …

Mein Fazit: Für Compliance-Berater, die Unternehmen aufzeigen,  wie sie so zwei Fliegen mit einer Klappe schlagen können, brechen goldene Zeiten an.

Das Ende der (PLM) Geschichte?

CONTACT hat eine der größten Studien der letzten Jahre im deutschsprachigen Raum zum Thema Product Lifecycle Management (PLM) unterstützt. Von August bis September 2010 wurden durch RAAD Research dazu über 300 Führungskräfte, d. h. IT-Leiter, Entwicklungsleiter und Controlling-Verantwortliche aus der Fertigungsindustrie interviewt. Die Ergebnisse unter dem Titel „PLM – Entwicklung und Potenziale in Deutschland 2010“ liegen nun vor. Details finden sich z.B. hier.

Ein Ergebnis ist mir dabei besonders aufgefallen, fast bin ich versucht zu sagen „sauer aufgestoßen“. Die Zahlen in der Grafik stehen nur exemplarisch für weitere, unter dem

Strich ziemlich positive Einschätzungen der Situation rund um das Thema PLM. Frei nach Francis Fukuyama stehen wir danach kurz vor dem Ende der (PLM) Geschichte und sollten uns als Hersteller, Berater und PLM Beauftragte in den  Unternehmen demnächst besser nach anderen Aufgaben umsehen.

Nun haben wir und vielleicht auch Sie einen guten Einblick in die Praxis. Dabei ist mit Allem zu rechnen, aber nur in schönen Ausnahmefällen mit einer umfassenden, inhaltlich belastbaren und vom Management unterstützten PLM Strategie! Woher kommt also die Diskrepanz? Meine Vermutung: Das Thema PLM wird immer noch recht eng ausgelegt und die Verbindung von Entwicklung und Produktion mittels freigegebener Artikeln, Zeichnungen und  Stücklisten als der wesentliche PLM Baustein gesehen. Sinngemäß hätten die Interviewten demnach an den „Spatz in der Hand“, aber nicht an die Taube auf dem Dach gedacht.

Ich finden, die Zahlen oben sind eine schöne Provokation und ein Weckruf, noch besser für die Potentiale der PLM Idee verbunden mit modernen Entwicklungsmethoden, Werkzeugen und Schnittstellen zu werben. Oder ist die Idee doch schon viel weiter in der Praxis angekommen und die Zahlen sind der Tendenz nach stimmig?

Standards in der Produktentwicklung: Fluch oder Segen?

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)