Zsolt erklärt: Was ist eigentlich Concurrent Engineering?

Die Idee des „Concurrent Engineering„, der simultanen Entwicklung von Produkten, beruht auf der Idee, dass frühzeitig viele an der Produktentstehung Beteiligte in die Gestaltung einbezogen werden. Wenn die gesamte verfügbare „Schwarmintelligenz“ parallel mitwirkt, wird es weniger späte und teure Konstruktionsänderungen geben. Das Produkt wird schneller und hochwertiger fertig gestellt.

Wie sieht das in der Praxis aus?

Wenn mehrere Gruppen gleichzeitig auf eine gültige Entwicklungsversion eines Produktes zugreifen, funktioniert es beispielsweise folgendermaßen:
Die Baugruppe X besteht aus zwei Unterbaugruppen, X.1 und X.2. Projektbeteiligter A reserviert sich X.1, B reserviert sich X.2. Idealerweise steht ein PDM-System zu Verfügung, die genannten Unterbaugruppen werden ausgecheckt. Auschecken heißt, nur A oder B dürfen auf die geblockten Baugruppen und Teile schreibend zugreifen und aus Performancegründen wird aus dem PDM-Archiv die gesamte Baugruppe auf dem jeweiligen Arbeitsrechner lokal zur Verfügung gestellt. A sieht die Änderungen von B nur, wenn „seine“ lokale Kopie aktualisiert wird und umgekehrt.

Ein Dilemma ist, wenn A an X.2.1 etwas ändern muss. Das geht nicht, eine Datei kann nur einmal zum Schreiben zur Verfügung gestellt werden. B müsste diesen Teil „seines“ Konstruktionsbereiches wieder einchecken, damit A die benötigte Funktionsänderung durch Auschecken von X.2.1 vornehmen kann.

Lange Zeit dachte ich, das ist „Concurrent Engineering“, simultanes Konstruieren. Die Parallelität hat hier aber offensichtlich system-bedingt starke Einschränkungen. Es kann nicht parallel an demselben Objekt gearbeitet werden, es wird nur paralleler Sichtzugriff gewährt und die unmittelbare Aktualität der lokalen Kopie ist auch nicht gewährleistet.

Im Grunde genommen handelt es sich hier nur um die Technik der (idealerweise durch PDM) kontrollierten Kopie. Es wird mit der Technik des Aus- und Eincheckens vermieden, dass Duplikate entstehen.

Ist das wirklich parallel, synchron, simultan, „concurrent“ ?

Die ideale Welt ist in dem folgenden Bild beschrieben. Es gibt nur eine Quelle der Wahrheit, auf die mehrere Projektbeteiligte simultan lesend oder schreibend zugreifen und immer sofort den aktuellen Status sehen beziehungsweise zum Bearbeiten zur Verfügung gestellt bekommen.

Es ist gut, immer mal wieder „über den Tellerrand“, in andere Domänen, zu schauen. Das Phänomen der Teamarbeit gibt es nicht nur bei der Entwicklung mechanischer Systeme, es gibt sie schon lange in der Softwareentwicklung.
Bekanntlich werden fast alle CAD– und PDM-Systeme verteilt entwickelt, beispielsweise in Boston (USA), Cambridge (UK) und Pune (Indien) gleichzeitig, also gut über den Globus und Zeitzonen verteilt. Hier hilft agiles Projektmanagement und Werkzeuge wie GitHub von Microsoft oder Git von Linus Thorwald, dem „Vater“ von Linux. Hier wird mit den Techniken des „Branching“ und „Merging“, des Verzweigens und der Vereinigung, gearbeitet.

Viele Köche verderben den Brei, sagt der Volksmund. In der Domäne der Entwicklung von CAD- und PDM-Software gilt das nicht mehr, offensichtlich wird das Chaos der gleichzeitigen Entwicklung durch viele Beteiligte, von überall und jederzeit, beherrscht.

Offensichtlich werden hier auch nicht mehr ausschließlich Wasserfall-orientierte Projektmethodik angewandt. Agile Methoden fördern Teamarbeit, holen„das Beste“ in einer definierten Zeit aus dem Potential des Teams heraus. Im Teamwettbewerb werden die besten Ideen produziert.

Eine dieser Gestaltungsbausteine ist „Design Thinking“. Kern ist ein Sprint, der aus fünf Stufen besteht:

• Verstehen
• Lösung skizzieren
• Entscheiden
• Prototyp erstellen
• Testen

Mehr zu diesem Sprintszenario beispielsweise hier

Das spielen wir mal an einem einfachen Beispiel aus unserer Domäne, der Entwicklung, durch. Machen wir mal so einen Design Sprint.

Stufe 1:

Was gibt es für Probleme mit der vorliegenden Konstruktion?

Das Gerät, das verbessert werden soll, ist ein Bohrständer.

Das Problem: Die Bohrplatte wird beim Durchbohren so häufig beschädigt, dass sie sehr schnell Schrott ist.

Stufe 2:
Drei Konstrukteure werden beauftragt, eine oder mehrere Lösungen zu skizzieren, sich für die beste zu entscheiden und jeweils ein virtueller Prototyp in CAD zu erstellen.

Es entstehen unabhängig voneinander diese drei Vorschläge.

Variante 1 sieht im Problembereich ein Langloch vor und schlägt wegen Festigkeitsschwächung eine Steife an der Aufnahme des Bohrständers vor.
Variante 2 schlägt drei Bohrungen im Problembereich vor.
Variante 3 schlägt das Einbringen einer extra Stahlplatte, einer „Opferplatte“ vor, die gelegentlich ersetzt wird, wenn sie zu sehr „ausgefranst“ ist.

Stufe 3:

Das Projektteam stellt fest, dass eine optimale Lösung im Vereinigen von Ideen aus Varianten 1 und 3 entstehen kann. Diese soll gefertigt und dem Auftraggeber zum Testen und Bewerten gegeben werden.

Stufe 4:

Hoppla, in einem klassischen CAD System sind jetzt drei unabhängige Modelle, drei Datensätze, drei Baugruppen mit unterschiedlichen Parts entstanden.

In diesem einfachen Beispiel ist das schnell nachmodelliert, aber was ist, wenn die Konstruktion viel komplexer ist?

Es geht auch anders, hier ein Fallbeispiel:

In Onshape, der Cloud-basierende SaaS-CAD- & PDM-Lösung von PTC, habe ich mit Ralf Steck und Georg von Vietinghoff folgendes durchgespielt.

Ausgehend von einer Version „V1″ haben wir drei Konstruktionsverzweigungen entstehen lassen. Wir drei, das Projektteam, haben von drei verschiedenen Orten, Friedrichshafen, Köln und Hamburg, die vorhin skizzierten Änderungen im Onshape Part Studio durchgeführt.

• Ralf: Drei Löcher
• Zsolt: Langloch und Versteifung
• Georg: Opferplatte mit Ausfräsung

Die optimalen Features wurden nach diesem Design Sprint wieder mit einem einfachen Mausklick zu einer neuen Version vereinigt.

Das Ganze funktioniert nur deswegen, da Onshape kompromisslos für die Cloud  entwickelt wurde. Es gibt keine Dateien, sondern nur EINE Konstruktionsdatenbank, auf die von überall, jederzeit, von beliebigen berechtigten Personen zugegriffen werden kann.
Wer sich hier für Details interessiert, kann dies gerne im Blogartikel „Zsolt erklärt: Onshape unter die Haube geschaut“ nachlesen.

Ziehen alle gleichzeitig oder zeitnah am gleichen Strang, ist das Ergebnis besser als wenn das Seil einfach nur im Team von A nach B gereicht wird.

 

Ich dachte mal, wir hätten bisher schon optimales Concurrent Engineering gehabt.
Das, was in dem Versuch aufgezeigt wurde, ist ein wichtiger, neuer Baustein für wirkliches paralleles Arbeiten. Technik bleibt nie stehen. Concurrent Engineering ist neu definiert.

Diese Technik des wirklichen simultane Konstruierens hat einen großen Mehrwert bei komplexen neuen Entwicklungen, wie bei diesem Bugfahrwerk eines Bausatz- Flugzeugs.

Ryley Karl von Darkaero aus Michigan erklärt in diesem LinkedIn-Beitrag, wie bei der Optimierung dieser Entwicklung Verzweigen und Vereinigen genutzt wurde.

Die beschriebene Technik revolutioniert die CAD Konstruktion in der Fähigkeit wirklich simultan an einer Entwicklung und Entwicklungsalternativen zu arbeiten. Concurrent Engineering ist jetzt ein Stück mehr simultane Entwicklung.

 

 

Quelle des Beispiels Bohrständer:
Das Konstruktionsbeispiel Bohrständer hat mir freundlicherweise Georg von Vietinghoff von Inneo Solutions zur Verfügung gestellt.