Management Kritischer Situationen

Kritische Situationen in der Produktentwicklung? Bei Kritischen Situationen² mag man gemeinhin an Beinahe-Abstürze von Flugzeugen, Schiffshavarien mit dramatischen Rettungsaktionen, medizinische Notfälle oder unvorhergesehene Ereignisse bei extremen Expeditionen denken. Die Arbeitsumgebung von Entwicklungsingenieuren scheint dagegen für Außenstehende von der geschäftigen Routine spezialisierter Technokraten geprägt und gänzlich unverdächtig hinsichtlich Kritischer Situationen zu sein. Eigentlich wirkt Entwicklungsarbeit sogar eher langweilig, zumindest aus der Sicht von Drehbuchautoren der Vorabendserien — ansonsten gäbe es längst Fernsehserien mit Titeln wie: „Dr. Blank — der Ingenieur, dem die Kunden vertrauen“. In diesem Buch wollen wir diesen Eindruck revidieren. Zum Verständnis der Zielsetzung des Buches soll zuvor geklärt werden, was eine „Kritische Situation“ ist, und insbesondere was „Kritische Situationen in der Produktentwicklung“ sind.

Angesichts der weitreichenden Festlegungen, die in der Produktentwicklung für den gesamten Produktlebenslauf getroffen werden, wundert es nicht, dass schon von Beginn industrieller Produktentwicklung vielfältige Anstrengungen unternommen wurden, Risiken und Fehler in der Entwicklungsarbeit zu reduzieren. Im ersten Teil dieses Kapitels wird ein Überblick über die bekanntesten Ansätze zur Unterstützung der Produktentwicklung gegeben (Abschn. 3.1). Anschließend werden die auf die Produktentwicklung gerichteten Ansätze in den Gesamtzusammenhang von Untersuchungen menschlicher Arbeit eingeordnet (Abschn. 3.2). Der Stand der Forschung bei der Zusammenführung der primär technisch und organisatorisch orientierten Ansätze aus der Produktentwicklung mit den vorwiegend den Menschen ins Zentrum stellenden Ansätzen aus der Arbeitspsychologie wird im dritten Teil dieses Kapitels dargestellt (Abschn. 3.3). Damit wird in diesem Kapitel ein kursorischer Überblick über den Stand der Forschung zur Unterstützung von Entwicklungsarbeit im Speziellen, zur Erfassung von Arbeitsprozessen im Allgemeinen und zur interdisziplinären Forschung von Konstruktionswissenschaftlern und Psychologen bei der Untersuchung von Produktentwicklungsprozessen im Besonderen gegeben.

In diesem Kapitel wird die Methodik dargestellt, die notwendig ist, um die organisatorischen, technischen und vor allem psycho-sozialen Prozesse von Konstruktionsarbeit erfassen zu können und damit einer wissenschaftlichen Analyse zugänglich zu machen. Ergebnisse, die auf der dargestellten Methodik beruhen, werden in den Kapiteln 5 bis 9 dargestellt.

Nicht nur in der Produktentwicklung, auch bei jeder anderen Form von Problemlösen geben die Ziele die Richtung der Problembearbeitung vor, oder wie Dörner es formuliert: „Ziele sind gewissermaßen die Leuchtfeuer für das Handeln.“ (1989, S. 74). Ziele sind demnach von besonderer Auswirkung für die Auswahl und den Verlauf von Handlungen; damit sind Zielanalysen und Zielentscheidungen, im Folgenden zusammengefasst auch Zielelaboration genannt, per definitionem Kritische Situationen.

Produktinnovation gilt als ein wichtiger Baustein wirtschaftlichen Erfolges. Dabei wird die Suche nach erfolgreichen neuen Entwicklungen, nach genialen Lösungen aktueller und zukünftiger Produkte als die wichtigste Aufgabe und herausragende Leistung des Entwicklers gesehen. Es scheint geradezu der Inbegriff des Verständnisses der Tätigkeit „Konstruieren“ zu sein, neue Lösungen zu suchen und umzusetzen, weshalb Konstruieren als eine besonders kreative Tätigkeit eingeschätzt wird. Doch wie bereits in den vergangenen Kapiteln deutlich wurde, werden während der Entwicklungsarbeit nicht permanent neue Lösungen geschaffen. Und viele Lösungen betreffen nicht notwendigerweise Funktionsforderungen, sondern den Bereich „Design to X“ mit Anforderungen wie Ergonomieverbesserung, Kostensenkung, etc. Aber wie sehen solche Prozesse aus, in denen neue Lösungen gefunden werden? — oder aber auch nicht....

Von der Tätigkeit des Analysierens wird in der Produktentwicklung aber auch in anderen Lebensbereichen in unterschiedlichem Zusammenhang gesprochen. Probleme, Situationen, Lösungen werden analysiert, in der Finanzwelt gibt es den Beruf des Analysten, welcher mehr oder weniger erfolgreich Geldanlagen empfiehlt. Als Denkprozess bedeutet Analysieren die Zerlegung eines Gegenstandes in seine Elemente, im Gegensatz zur Synthese, wo es um das Zusammensetzen von Elementen geht. Analysieren im ursprünglichen Wortsinne von Zerlegen stellt einen basalen Denkvorgang dar, der allerdings nur einen Teil des Vorgangs umfasst, den wir in einem Arbeitsprozess unter Analysieren verstehen. Im Arbeitsschritt „Analysieren“ kommt es vielmehr auf den Wechsel von Analyse- und Synthesedenkprozessen an, um Zusammenhänge verstehen und Erkenntnisse gewinnen zu können. In der Produktentwicklung ist das Analysieren einer Konstruktion ein wichtiger Arbeits schritt, um den Zustand sowie mögliche Konsequenzen einer vorliegenden Konstruktion in Bezug auf den zu erreichenden Zielzustand festzustellen. Die grundlegende Frage ist, ob es sich bei der analysierten Konstruktion um eine Lösung für das gestellte Problem handelt, d.h. ob alle geforderten Eigenschaften vorliegen. Streng genommen ist die Konstruktion erst dann eine „Lösung“, wenn diese Beurteilung positiv bestanden ist. Wir wollen dennoch den eingeführten Begriff der „Lösungsanalyse“ für die Analyse von Konstruktionen verwenden, auch wenn sie zum Ergebnis haben kann, dass ein Lösungsvorschlag keine Lösung darstellt.

Konflikte sind Bestandteile unseres täglichen Lebens und damit auch des Arbeitslebens. Im Allgemeinen wird ein Konflikt als ein Zustand definiert, welcher durch unterschiedliche Meinungen, Interessen, Werthaltungen, Pläne, Absichten, Ziele und/oder Handlungstendenzen zwischen zwei oder mehreren sozialen Einheiten gekennzeichnet ist. Dabei ist es durchaus möglich, dass nur einer der Aktoren die Unvereinbarkeit erlebt, sich beeinträchtigt fühlt und entsprechend handelt (Glasl 1996). Jedoch implizieren Gegensätzlichkeiten zwischen Aktoren noch keinen Konflikt, erst die Beeinträchtigung eines Aktors und die daraus resultierende Frustration ist Voraussetzung für das Vorliegen eines Konfliktes. Natürlich kann auch ein Individuum innerhalb seines eigenen kognitiven Systems widerstreitende Gefühle, Kognitionen oder Ziele haben, in solchen Fällen spricht die Psychologie von intrapsychischen Konflikten. Wenn wir uns an dieser Stelle ausschließlich mit interpersonalen (also Konflikten zwischen Personen dergleichen Gruppe) und intergruppalen Konflikten (Konflikten zwischen Arbeitsgruppen, Abteilungen, Funktionseinheiten) beschäftigen, soll damit nicht die Bedeutung intrapsychischer Konflikte negiert werden, aber für die hier vorliegende Thematik ist die Konzentration auf interpersonale Konflikte beabsichtigt.

Störungen stellen Kritische Situationen in der Produktentwicklung dar, deren Ursachen nicht unmittelbar dem Problemlöseprozess, sondern wie bei Konfliktsituationen, dem sozialen Kontext der Produktentwicklungsarbeit zuzuordnen sind. Es geht also nicht um den Bereich von Störungen in komplexen Systemen, der sich auf die Sicherheit technischer Anlagen bezieht, wo Störungsmanagement letztlich Fehleranalyse und Fehlerbeseitigung ist.

Erfolg von Produktentwicklung wird gerne mit dem Markterfolg des entwickelten Produktes begründet. Doch auf den späteren Produkterfolg wirken viele weitere Einflüsse aus Bereichen außerhalb der Entwicklungsabteilungen ein. So beeinflussen beispielsweise Marktentwicklungen und unvorhergesehene Trends, Werbestrategien, Preispolitik, Vertriebsstrukturen und viele andere Faktoren ebenfalls den Erfolg, liegen jedoch in der Regel außerhalb der Gestaltungsmöglichkeiten des Entwicklungsteams. Daher wird die Gleichsetzung von Markterfolg und Entwicklungsleistung der tatsächlichen Leistung eines Entwicklungsteams selten gerecht. Der Erfolg und damit die Leistung eines Entwicklungsteams ist treffender durch die Qualität des Problemlöseprozesses innerhalb der Entwicklung definiert. Bei einer Betrachtung des gesamten Entwicklungsprozesses sind Vergleiche mit anderen Entwicklungsprojekten und damit Evaluationen der Entwicklungsleistung prinzipiell schwierig, da sich zumindest die konkrete Problemstellung, meist aber die Rahmenbedingungen wie auch die Entwicklungsteams verändern. Die Anzahl der Variablen ist hoch und lässt sich für eine wissenschaftliche Untersuchung von Erfolgsfaktoren nicht konstant halten: Sogar die Voraussetzungen des einzelnen Entwicklers, zum Beispiel seine Erfahrung, werden sich von Projekt zu Projekt verändern.