CONTACT Software Blog

PLM Kollaboration – neu gedacht

Neulich schrieb ich in beyondplm.com über Wie lässt sich PLM-Kollaboration vereinfachen?. Heute möchte ich einen anderen Blickwinkel einnehmen und darüber sprechen, wie das PLM-Kollaborationskonzept überdacht werden kann. Weshalb ich glaube, dass dies interessant sein könnte? Meiner Meinung nach ist die Industrie für Unternehmenssoftware durchdrungen vom Prozess der Anwenderorientierung. Das bedeutet, dass viele Technologien in die Unternehmen gelangen, die sich im Anwenderbereich bewährt haben. PLM ist von diesem Prozess nicht ausgenommen. Das Thema Zusammenarbeit könnte ein guter Ausgangspunkt für einen solchen Neuansatz sein. Zur Verdeutlichung habe ich das folgende Diagramm erstellt.

Ich denke an drei grundlegende Aktivitäten: Kommunikation, Kollaboration und Prozess-Management. Diese möchte ich nacheinander diskutieren.

Kommunikation

Dies ist der unkomplizierteste Teil. In meinen Augen stellt die Kommunikation heute die grundlegende Aktivität überhaupt in einer Organisation dar. Ich habe von Mitarbeitern gehört, dass die Organisation praktisch nur per E-Mail erfolgt. Neue Technologien und das Web bieten alternative Kommunikationswege (z. B. Instant Messaging, Blogs, Foren usw.). Trotzdem ist E-Mail sehr stark und alle ehrgeizigen Pläne, E-Mails zu ersetzen, sind bisher gescheitert.

Kollaboration

Ich habe das Wort “ Kollaboration” verwendet, um Tools zu identifizieren, mit denen Mitarbeiter Daten gemeinsam nutzen können. Es gibt “synchrone” und “asynchrone” Tools, die bei der Zusammenarbeit von Mitarbeitern verwendet werden können. Neue Web-Tools (z. B. Wikis) dringen durch das Internet in diesen Bereich ein. Ich bin der Auffassung, dass dies interessante Perspektiven bietet, um Daten gemeinsam zu nutzen.

Prozess-Management

Organisationen werden im Wesentlichen von Prozessen bestimmt. Verschiedene Geschäftsprozesse können die Aktivitäten der Mitarbeiter bestimmen und formalisieren und Ziele und Systeme zur Leistungsmessung definieren. Der wichtige Aspekt beim Prozess-Management ist, dass die Mitarbeiter dies auch annehmen. Sehr häufig bindet ein Unternehmen erhebliche Ressourcen, um ein Prozess-Management-System einzusetzen und zu implementieren. Trotzdem wird das System am nächsten Tag von Mitarbeitern, die E-Mails versenden, missbraucht. So entscheiden sie sich gegen die komplizierten Verfahren des Prozess-Managements.

Weg von Räumen hin zu Kanälen

Ich glaube, Unternehmen verabschieden sich von der Welt der Datenbanken und wechseln zu Netzwerken. Diesen Punkt habe ich schon früher aufgegriffen, und zwar in PLM-Netzwerk-Effekt und Single Point of Truth. Allmählich beginnen die Unternehmen zu verstehen, dass die Zentralisierung durch Datenbanken an Grenzen stößt. Die Internet-Erfahrung zeigt eindeutig, dass die Organisation in Netzwerken sehr viel leistungsstärker sein kann. Als ich über diese Abstraktion nachdachte, kam ich zu dem Schluss, dass sich eine nicht unbedeutende Bewegung vom Konzept der „Räume“, das für die PLM-Collaboration in den vergangenen 10-15 Jahren vorherrschend war, hin zum Konzept der „Kanäle“ vollzieht. Die Art wie Kanäle organisiert werden, kann der Rationalisierung von Kommunikation und Prozessen in Unternehmensorganisationen einen innovativen Schub geben. Ich kann mir vorstellen, dass bestehende und neue Unternehmen in diesem Bereich innovativ sein werden. Lassen Sie mich nur einige Beispiele anführen – Cisco Quad, Salesforce.com Chatter, Yammer, Vuuch. Dies ist meine Auswahlliste von innovativen Firmen in diesem Bereich.

Schlussfolgerungen

Die Kundenforderung, die Zusammenarbeit in Unternehmen neu zu überdenken, wird bedeutende Auswirkungen darauf haben, wie sich die PLM-Kollaboration in den kommenden drei bis fünf Jahren entwickelt. Die Schnittstelle von Prozess-Management, Kommunikation und herkömmlichen Kollaborations-Tools ist ein guter Ausgangspunkt für eine Revision all dessen, was wir bisher über PLM-Kollaboration wussten.

Alles Gute, Oleg

(Hinweis: Dies ist eine Übersetzung des Beitrags How To Reset PLM Collaboration aus Oleg Shilovitskys Blog Beyond PLM. Übersetzung und Abdruck mit freundlicher Genehmigung des Autors. Ohne Gewähr für die Richtigkeit der Übersetzung.)

Zu viel CAD, zu wenig PLM?

Vor einiger Zeit habe ich in Oleg Shilovitskys Blog folgendes goldwertes Zitat von Al Dean gelesen, der das Online-Magazin “Develop 3D” herausgibt:

PLM is easy to define. It’s 3 things. A product. Its lifecycle. And Managing it. It doesn’t need anymore fucking definition.

Oder, um es mit einem Kanzlerwort zu sagen: Entscheidend ist, was hinten rauskommt. Nämlich ein Produkt aus der Fabrik (und natürlich wann, in welcher Qualität, und zu welchen Kosten). Welche “PLM-Werkzeuge” (vom Karteikasten bis zur Enterprise-PLM-Lösung) man einsetzt, um das zu erreichen, ist dabei wichtig, aber sekundär. Diese Werkzeuge können gut oder schlecht, kostengünstig oder teuer sein, und die beteiligten Personen gut oder schlecht bei ihrer Arbeit unterstützen. Fatal ist es jedenfalls, wenn die Wahl des Werkzeugs den Prozess behindert, oder mit zusätzlicher Komplexität belastet. Optimal ist es, wenn die jeweils passenden Werkzeuge an den richtigen Stellen eingesetzt werden können.

Da hat Thomas Teger möglicherweise nicht ganz unrecht. Zudem ist das Nachdenken über “PLM” oft nur ein Nachdenken über CAD und wie man mit CAD-Daten umgeht. Das ist ein wichtiger Teil von PLM, denn natürlich haben CAD und CAE (für 3D/Mechanik, aber auch andere Disziplinen, die leider oft vergessen werden) eine Revolution bei der Entwicklung von Produkten bewirkt. Aber eben nur ein Teil. Die wichtigsten Funktionen von PLM-Software sind (ohne, dass das eine “fucking definition” sein soll):

Kollaboration: Zusammenarbeit im Virtuellen ermöglichen (also z.B. Teamwork mit CAD-Daten)
Daten”herstellung” rationalisieren: hierher gehören CAD-Systeme und andere Tools, mit denen die Dokumentationserstellung und Absicherung digitalisiert und vereinfacht wird.
und nachgelagerte Prozesse (Fertigung, Einkauf, …) mit Daten versorgen: das ist der eigentliche Sinn von PLM

Für das, was “hinten rauskommen” soll, ist Punkt 3 das Entscheidende. Was nützt eine Fertigungszeichnung, die aus einem parametrischen 3D-Modell entstanden ist, wenn sie niemand ausdruckt und zur Werkbank bringt? Und, um den Gedanken weiterzuspinnen, wenn die Zeichnung auf der Werkbank liegt, was nützen Parametrik und 2D/3D-Assoziativität eines CAD-Systems, um Änderungen zu transportieren?

Moderne CAD-Systeme rationalisieren und erleichtern die Erstellung vollständiger und informationsreicher Dokumentation. Dafür ist aber eine gewisse zusätzliche Komplexität erforderlich (Stichworte Parametrik, “Links” und Referenztechnik), die für die der Entwicklung nachgelagerten Prozesse allerdings irrelevant ist. Diese Komplexität muss in einer PLM-Strategie berücksichtigt werden, aber diese daran auszurichten hieße, das Pferd vom Schwanz her aufzuzäumen. Zudem geht Produktentwicklung natürlich weit darüber hinaus, Geometriedaten oder zum Beispiel Schaltpläne zu erzeugen. Man schaue nur auf die zahllosen Dokumente, Excel-Sheets, Software-Tools und Papierberge, die für Auslegungen, Kostenschätzung usw. verwendet und produziert werden.

Außerdem gibt es auch nicht “ein CAD für alle Fälle”: für das Geometriemodell des Produkts mag das eine System optimal sein, für einzubauende Komponenten und für die Nachbearbeitung von Bauteilgeometrie zur Vorbereitung von Berechnung oder NC-Programmierung ein weiteres. Die optimale Kombination scheitert aber zu oft daran, dass Geometriedaten nicht (oder nur sehr mühsam) zwischen CAD-Systemen ausgetauscht werden können. Unter diesem Gesichtspunkt ist der aktuelle Trend zur Direktmodellierung (Siemens’ “Synchronous”-Technologie, Autodesk mit “Fusion” und neuerdings PTC mit seiner neuen “Creo”-Produktreihe – aber auch kleinere Anbieter wie Spaceclaim und Kubotek) bemerkenswert: die sich abzeichnende Möglichkeit die “nackte” B-Rep-Geometrie in einem anderen Tools als dem Erzeugungssystem zwanglos weiter bearbeiten zu können, hat das Potential, die CAD-Silos aufzulösen.

Was bleibt, ist den Menschen, die “PLM” leisten, eine Plattform zu geben, mit der sie sich so organisieren können, dass die Ziele in der Produktentwicklung erreicht werden.

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:

Gute Standards stellen Best Practices dar, deren Nutzen für Anwender offensichtlich ist.
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.
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.
Standardisierung in der Produktentwicklung erfordert besondere Umsicht: Schließlich sollen Kreativität und Flexibilität nicht unter die Räder kommen.

(claim token 9CRX6ENYMPWC)