Produktionssysteme

Produktentwicklung als selbstorganisierender Geschäftsprozess

Dr.-Ing. Reinhard Schmitt

Dr.-Ing. Mathias Zagel

Karlsruhe

Jede Stunde »echter« Entwicklungstätigkeit erfordert inzwischen zwei Stunden Kommunikations-, Koordinations- und Dokumentationsaufwand. In Anbetracht einer immer globaler agierenden Wirtschaft, der wachsenden Fragmentierung erforderlichen Spezialwissens und der Tendenz zu immer anspruchsvolleren Produkten und Kundenmärkten wird dieser Zusatzaufwand weiter steigen.

Hinzu kommt, dass die Beteiligten immer häufiger das Gefühl haben, trotz ausführlicher Geschäftsprozessbeschreibungen und detaillierter Projektpläne den Überblick und damit die Kontrolle über die Entwicklungsabläufe zu verlieren. Fakt ist, dass etablierte Arbeits- und Kommunikationsparadigmen inzwischen überfordert sind.

In den letzten Jahren wurde zunehmend der Eindruck vermittelt, Produktentwicklung sei im Wesentlichen eine logische Abfolge der »richtigen« Arbeitsschritte. Die erfolgreiche Formalisierung und Effizienzsteigerung von Geschäftsprozessen in anderen Unternehmensbereichen bestärkte viele Firmen in ihrem Bestreben, auch kreativ-konzeptionelle Abläufe über ausgefeilte Prozessmodelle sowie den Einsatz von Workflow- und Projektmanagement-Lösungen »in den Griff« zu bekommen. Der Wunsch nach Beherrschbarkeit und Reproduzierbarkeit ist für Geschäftsprozesse mit hohem Vernetzungsgrad bei zeitlicher Stabilität der Vernetzung durchaus sinnvoll und geeignet (Bild 1). Dasselbe gilt für Abläufe mit hoher Veränderlichkeit der Vernetzung bei niedrigem Vernetzungsgrad. Produktentwicklung weist jedoch – insbesondere in verteilten Umgebungen – sowohl einen hohen Vernetzungsgrad als auch eine hohe zeitliche Veränderlichkeit der Vernetzung auf. Deshalb ist dort ein gegenteiliger Effekt zu beobachten: Je intensiver die Formalisierungsbemühungen, desto stärker die Tendenz zur Bildung von Informationsschwarzmärkten. Klärungen werden außerhalb formaler Prozesse vorgenommen, weil Termine anders nicht zu halten sind. Die zweite Seite der gleichen Medaille zeigt: Unter Zeitdruck werden Prozesse pro forma eingehalten, obwohl weder Qualität noch Reifegrad der dokumentierten Arbeitsergebnisse freigabewürdig sind. In beiden Fällen kommt es zwangsläufig zu Unvereinbarkeiten in den Arbeitsergebnissen. Hohe Fehlleistungszeiten und -kosten sind die Folge.

Anzeige

Die Produktentwicklung ist in ihrem Wesen ein kreativer Wertschöpfungsprozess, der sich in seinen Eigenschaften substanziell von anderen Geschäftsprozessarten unterscheidet (Bild 2). Erkennbare Arbeitsstrukturen bilden sich erst mit der Zeit heraus und entwickeln sich ständig weiter. Folglich sind die auszuführenden Tätigkeiten und deren Vernetzung über Prozessmodelle oder Projektpläne allenfalls abstrakt beschreibbar. Ebenso ist eine operative Steuerung mit herkömmlichen Ansätzen des Prozess- oder Projektmanagements unmöglich, da sich die resultierende Komplexität »von Natur aus« nur über ein sehr hohes Maß an Selbstorganisation bewältigen lässt.

Ein Produktentwickler betrachtet seine Arbeit als eine kontinuierliche Abfolge von Entscheidungen. Diese Entscheidungen fixieren oder verändern geometrische, funktionale und materialspezifische Variablen, die als Produktparameter bezeichnet werden können. Seine Entscheidungsfreiheit wird jedoch eingeschränkt, denn er ist von weiteren Produktparametern abhängig, über deren Ausprägung andere Produktentwickler oder Vertreter vor- beziehungsweise nachgelagerter Phasen im Produktlebenszyklus (mit-) entscheiden, zum Beispiel das Marketing, der Vertrieb, der Einkauf, die Produktionsplanung oder der Kunden-Service. Häufig sind zur Festlegung endgültiger Parameterwerte sehr dynamische Abstimmungsvorgänge erforderlich.
Untersuchungen bei einem Schienenfahrzeughersteller ergaben, dass für ein Triebzugfahrwerk (Bild 3) etwa 80 Produktparameter frühzeitig und konsequent zwischen allen Beteiligten abzustimmen sind, um ein konsistentes Fahrwerkkonzept zu gewährleisten. Ferner zeigte sich, dass für die Abstimmung dieser Parameter keine Dokumente erforderlich sind, denn es genügt, dass die Projektbeteiligten die entsprechenden Parameter als eigenständige Informationsobjekte behandeln und untereinander parameterbasiert kommunizieren. Zu ähnlichen Ergebnissen kommt ein weltweit führender Hersteller elektronischer Komponenten für die Automobilindustrie, der seinen Produktentwicklungsprozess über rund 140 Parameter steuert.

Diese Erkenntnisse macht sich das Software-Werkzeug consentor zunutze. Dieses unterstützt Produktentwickler und Beteiligte aus vor- und nachgelagerten Phasen des Produktlebenszyklus sowohl bei der Erfassung abstimmungsrelevanter Parameter als auch bei der Zuordnung einzubeziehender Personen zu diesen Parametern. Dabei werden die Abhängigkeitsbeziehungen zwischen den Parametern von den Beteiligten über eine neuartige Vernetzungsmethode selbst festgelegt. Die so vorgenommene Vernetzung der Parameter erzeugt selbstorganisiert ein abteilungs-, standort- und gegebenenfalls unternehmensübergreifendes Beziehungsgeflecht zwischen den Projektbeteiligten, wobei der Grad der Vernetzung individuell gestaltbar ist und der Intensität keine Grenzen gesetzt sind.

Nicht nur die Parameter als eigenständige Informationsobjekte und Netzwerkelemente, sondern auch die Verknüpfungen zwischen ihnen sind hochgradig veränderlich. Parameter, die anfangs als vermeintlich abstimmungsrelevant erfasst wurden, verschwinden wieder, weil keine Abhängigkeitsbeziehungen zu ihnen aufgebaut wurden. Dafür tauchen im Verlauf des Entwicklungsprozesses zusätzliche Parameter auf, die als relevant eingestuft werden. Gleiches gilt für Verknüpfungen zwischen den Parametern. Anfangs vermutete Abhängigkeitsbeziehungen werden wieder gekappt und stattdessen neue Beziehungen aufgebaut. Mit jedem Parameter ist ein (unter Umständen wiederholt durchzuführender) Entscheidungsvorgang verbunden: Parameterwert erstmalig festlegen, infolge neuer Erkenntnisse ändern oder an veränderte Werte verknüpfter Parameter anpassen. Bei der Festlegung oder Änderung eines Parameterwertes werden nicht nur die Personen informiert, die diesem Parameter unmittelbar zugeordnet sind, sondern auch jene Beteiligte oder Betroffene, die »ihren« Parameter wegen eines Abhängigkeitsverhältnisses mit dem betreffenden Parameter direkt verknüpft haben. Die consentor-Software initiiert automatisch notwendige Abstimmungsprozesse und bezieht nur tatsächlich betroffene Personen in diese mit ein (Bild 4). Das mit der Zeit entstehende Gebilde aus Kommunikations- und Arbeitsstrukturen kann einen beliebig hohen Komplexitätsgrad annehmen, denn das zugrunde liegende Vernetzungsprinzip ist denkbar simpel. Es beruht auf einem Grundprinzip der Schwarmintelligenz: »Sei flexibel und achte darauf, was Dein Nachbar tut!«.

Abstimmungsprozesse in Netzwerken brauchen Raum und Möglichkeit für Austausch und Diskussion. Hierfür stehen parameterspezifische Foren zur Verfügung, so dass die bislang über E-Mail zu führenden Abstimmungsvorgänge auf eine wirksamere Kommunikations- und Kooperationsplattform verlagert werden. Ebenso wie bei der parameterbasierten Initiierung von Abstimmungsvorgängen werden nur solche Personen an einer Diskussion beteiligt, die einem Parameter entweder direkt zugeordnet oder diesem unmittelbar »benachbart« sind. Auf diese Weise wird sichergestellt, dass zu den laufenden Diskussionen nur Personen beitragen, die tatsächlich etwas zu sagen haben.

Gängige Wissensmanagement-Ansätze (wie Erfassung von »Lessons Learned«, Experten-Communities und Unternehmens-Wikis) erfordern über die operative Entwicklungsarbeit hinaus einen Zusatzaufwand, der von den Beteiligten als nicht unmittelbar nützlich für die eigene Arbeit erachtet wird. Demgegenüber erfasst consentor entscheidendes und entscheidungsrelevantes Wissen prozessbegleitend ohne Zusatzaufwand für die am Entwicklungsprozess Beteiligten. Über parameterorientierte Suchfunktionen lässt sich dieses Wissen bedarfsorientiert wieder auffinden und nutzen:

Für Rollback-Szenarien während des laufenden Entwicklungsprojektes (zum Beispiel Revidierung von Entscheidungen und Rückgriff auf früher diskutierte, jedoch verworfene Entwicklungsalternativen).

Für Ursachenforschung, Auswirkungsanalyse und Verfolgung der Änderungsfortpflanzung als Bestandteile des Änderungsmanagements.

Als »Best Practice« für ähnliche Aufgabenstellungen in der Zukunft.

Die consentor-Lösung ergänzt gängige Ansätze und IT-Systeme des Geschäftsprozess- und Projektmanagements auf komplementäre Weise (Bild 5).

Anknüpfungspunkte zu formalen Prozessabläufen und entsprechenden Geschäftsanwendungen ergeben sich beispielsweise im Änderungsmanagement. Stellen die Beteiligten im Zuge ihrer Arbeit fest, dass der Wert eines Anforderungsparameters nicht haltbar ist, dann ist ein formaler Änderungsprozess im hierfür vorgesehenen System auszulösen. Ähnliches gilt für die formale Prüfung und Freigabe von Dokumenten, in denen Parameter und deren Werte dokumentiert werden. Ferner kann es aus Gründen der Durchgängigkeit hilfreich sein, Parameter in consentor direkt mit Dokumenten, Artikelstammdaten oder Sachmerkmalleisten in den jeweiligen Geschäftsanwendungen zu verknüpfen (Bild 6).

Das hier vorgestellte Konzept konzentriert die Kooperation in verteilten Umgebungen auf abstimmungsrelevante Inhalte und steigert die Ergebniswirksamkeit durch ein höheres Maß an Selbstorganisation bei gleichzeitig möglichem Abbau von Formalismen. Dadurch werden die Abstimmungsvorgänge beschleunigt sowie der Kommunikations- und Managementaufwand zugunsten des Zeitanteils fachlicher Aufgaben reduziert. Ein weiterer Vorteil parameterbasierter Kommunikation und Kooperation besteht in der Vermeidung ungewollten Know-how-Abflusses, der bei der unternehmensübergreifenden Weitergabe von Dokumenten zwangsläufig entsteht. In consentor werden lediglich Parameterdaten mitgeteilt, die der Empfänger in seinen eigenen Wissenskontext »einbaut«. Die Kontextinformationen der Senderseite bleiben dort, wo sie hingehören. Der unter finanziellen Gesichtspunkten maßgebliche Effekt resultiert aus einer deutlichen Steigerung der Ergebnisqualität und der damit verbundenen Reduzierung der Fehlleistungskosten. Durch die konsequente Erfassung und Verknüpfung abstimmungsrelevanter Inhalte sowie die daraus resultierende Transparenz bei der Änderungsfortpflanzung und durch die Hinterlegung dieser Inhalte mit entscheidungsrelevantem Wissen sowie die automatische Einbeziehung aller relevanten Personen über die technische Vernetzung werden zwangsläufig weniger Fehler gemacht. -fr-

Anzeige

Das könnte Sie auch interessieren

Anzeige

Plantafeln

Weigang unterstützt jetzt auch Scrum

Schneller als erwartet beginnen deutsche Unternehmen damit, Scrum als methodisches Konzept für das agile Projektmanagement einzusetzen. Allen anderen voran sind es die Automobil- und Fahrzeugbauer, die sich damit anfreunden.

mehr...
Anzeige

CAD/CAM-Software

Die Spinne verschwindet

Die Spinne im Logo von Delcam war ein markantes Symbol des britischen Herstellers. Nach der Übernahme durch Autodesk im Februar 2014 ging nicht nur die Eigenständigkeit verloren, sondern auch viele Mitarbeiter haben das Unternehmen verlassen.

mehr...