Die Bausteine des GSE-Vorgehenskonzeptes – Komplexität mittels einfacher Regeln beherrschen

Winzer, Petra

doi:10.1007/978-3-642-30365-4_4

Petra Winzer²

4018 Accesses

Zusammenfassung

Durch den umfassenden Literaturvergleich (vgl. Kap. 1.4 und 2.3) wurde herausgearbeitet, dass Komplexität mittels einfacher Regeln über das GSE-Vorgehenskonzept zu beherrschen sein soll. Darüber hinaus wurde die Forderung aufgestellt, dass ein universelles Problemlösungskonzept modular aufgebaut sein muss und synergetisch mit dem Denkmodell in Verbindung zu stehen hat. Im Kap. 4 werden in Anlehnung und Erweiterung an Haberfellner et al. 2012, basierend auf den Vergleichsergebnissen verschiedenster Vorgehenskonzepte, vier standardisierte Module entwickelt. Sie bestehen aus einem Analysemodul, einem Zielbildungs- und Gestaltungsmodul sowie einem Projektmanagementmodul. Letzeres kann die drei zuvor genannten Module problemspezifisch kombinieren. Je Modul können fachbezogen entsprechende Methoden und Verfahren eingesetzt werden. Dies wird an Beispielen demonstriert.

Download chapter PDF

Die Literaturanalyse belegte, dass das SE sich gegenwärtig verschiedenster Vorgehenskonzepte bedient (vgl. Abschn. 1.4 und Abschn. 2.3). Hierzu wurden SE-Ansätze, die der Produktentwicklung, der Fabrikgestaltung, des Sicherheitsengineerings sowie der Softwareentwicklung dienen, im Speziellen analysiert. Die Bewältigung der Komplexität der Gegenwart und der Zukunft erfordert jedoch ein generelles, standardisiertes, modular aufgebautes Vorgehenskonzept, welches transdisziplinär nutzbar ist, sowie transparent und rückverfolgbar die Handlungen des Vorgehens nachvollziehen lässt (vgl. Abschn. 2.4). Darüber hinaus konnte die grundlegende Erkenntnis abgeleitet werden, dass ein Vorgehenskonzept nur auf der Basis eines Denkmodells entwickelt werden sollte sowie Denkmodell und Vorgehenskonzept synergetisch verbunden sein müssen. Festgestellt wurde auch, dass das SE ein universeller Ansatz sein muss, um Systeme zielgerichtet zu gestalten. Jedes generelle Vorgehen soll aber mit spezifischen Methoden und Verfahren gekoppelt werden können, um mit der prinzipiellen, generalistischen Problemlösung auch fachspezifische Detaillösungen zu ermöglichen.

Dies verdeutlicht der Designprozess eines Oberstromabnehmers in Abb. 4.1. Obwohl ein gemeinsames Denkmodell in Form eines Metamodells geschaffen wurde (vgl. Abschn. 3.3), sind spezifische Designaufgaben mit bestimmten Methoden zu lösen.

So ist die Statik eines Oberstromabnehmers bei einem O-Bus mit anderen Methoden und Verfahren zu prüfen als die Funktionalitätsprüfung seiner Steuerung. Diese Erkenntnis ist nicht neu (vgl. Lindemann 2005; Lindemann et al. 2009; Gausemeier et al. 2009).

Die Produkte der Gegenwart werden durch interdisziplinäre Teams entwickelt, welche sich auf ein Vorgehen einigen, jedoch ihre speziellen Detaillösungen mit fachspezifischen Methoden erarbeiten müssen. Sie sind mit dem Vorgehenskonzept zu verlinken. Da immer noch verschiedenste Vorgehenskonzepte im SE existieren (vgl. Abschn. 1.4), erfolgt in logischer Konsequenz bislang die Zuordnung von Methoden und Verfahren zu den jeweiligen, fachspezifischen Vorgehenskonzepten. So sortierte FRANKE (vgl. Franke 2002) die Methoden und Verfahren prinzipiell nach den Modulen seines Vorgehenskonzeptes, d. h. dem Analyse-, Synthese-, Bewertungs- und Transfermodul, wie Tab. 4.1 verdeutlicht.

Dagegen ordnete LINDEMANN die Methoden und Verfahren seinem Münchener Vorgehensmodell (vgl. Lindemann 2005) zu.

Um dem entgegenzuwirken und um den transdisziplinären Teams einen einfachen, universellen Problemlösungsansatz anzubieten, wurde für den GSE-Ansatz ein GSE-Vorgehenskonzept erarbeitet. Es besteht aus einem Analyse-, Zielbildungs-, sowie Gestaltungs- und Projektmanagementmodul, wobei den Modulen Methoden und Verfahren zugeordnet sowie problemorientiert über die Phasen des Projektmanagements effizient geplant, umgesetzt und überwacht werden müssen (vgl. Abb. 4.2).

Tab. 4.1 Übersicht über Methoden und Vorgehensweisen (nach Franke 2002, S. 83)

Full size table

In den nachfolgenden Unterkapiteln des Kapitels 4 soll nachgewiesen werden, dass das GSE-Vorgehenskonzept universell ist. Wenn es jedoch mit fachspezifischen Methoden und Verfahren gekoppelt wird, entstehen daraus spezielle, problemfokussierte Module. Die folgenden Ausführungen sollen auch belegen, dass das GSE-Vorgehenskonzept in synergetischer Verbindung mit dem GSE-Denkmodell im GSE-Ansatz steht. Zunächst werden die einzelnen universellen Module des GSE-Vorgehenskonzeptes, d. h. das Analyse-, das Zielbildungs- und das Gestaltungsmodul beschrieben. Aufbauend auf den in Abschn. 2.3 skizzierten Grundstrukturen dieser Module werden in den Abschn. 4.1, 4.2, 4.3 Methoden und Verfahren vorgestellt und zugeordnet, die eine handlungsorientierte Unterstützung geben. Dabei stehen solche Fragen im Mittelpunkt wie:

Welche Methoden und Verfahren stützen die jeweiligen Module?
Wie können die Methoden und Verfahren im Modul oder modulübergreifend kombiniert werden?
Wie sind die Ergebnisse aus den Anwendungen der Methoden und Verfahren in das Denkmodell des GSE-Ansatzes zu integrieren und welche Auswirkungen haben sie?

Die Diskussion möglicher einzusetzender Methoden und Verfahren soll zunächst je Modul, d. h. für das Analyse-, das Zielbildungs- und das Gestaltungsmodul im GSE-Vorgehenskonzept und anschließend für die Phasen des Projektmanagementmoduls erfolgen (vgl. Abschn. 4.4). Festgestellt wurde, dass bei der Anwendung der Module des GSE-Vorgehenskonzeptes die auszuwählenden spezifischen Methoden und Verfahren in einer problemfokussierten zeitlichen und logischen Folge miteinander verbunden werden müssen, wenn der GSE-Ansatz zur Problemlösung in den verschiedensten Bereichen angewendet wird. Somit erfolgt die Kombination des Analyse-, Zielbildungs- und Gestaltungsmoduls nicht sequentiell, sondern iterativ, möglicherweise auch mehrzyklisch in Abhängigkeit von dem zu lösendem Problemfall (vgl. Abschn. 4.5). In diesem Kapitel wird auch an Beispielen ausgeführt, wie der GSE-Ansatz über einen definierten Zeitraum, d. h. den Produktlebenszyklus, in seiner synergetischen Wirkung zwischen GSE-Denkmodell und GSE-Vorgehenskonzept interagieren kann.

Es sollen Anregungen geben werden, welche Methoden und Verfahren wann wie im GSE-Vorgehenskonzept eingesetzt werden könnten, ohne sie im Detail zu beschreiben, weil dies bei EHRLENSPIEL und LINDEMANN bereits zu finden ist (Ehrlenspiel 2003, Lindemann 2005). Darüber hinaus soll grob skizziert werden, welche Auswirkungen Ergebnisse von Methoden und Verfahren auf das GSE-Denkmodell haben. Dieser Aspekt ist von besonderer Bedeutung, weil er die Wechselwirkung zwischen GSE-Denkmodell und GSE-Vorgehenskonzept im GSE-Ansatz verdeutlicht (vgl. Abb. 4.3).

Zum Teil wurde dies bereits schon in Kap. 3 untersucht. Dabei lag jedoch der Fokus mehr darauf, welche Auswirkungen Erkenntnisse aus dem GSE-Denkmodell auf die Planung des Vorgehens im GSE-Ansatz haben. So ergaben sich beim Erstellen von Denkmodellen:

für den Antrieb Gestaltungsansätze für den Rotorstab,
für das mechatronische System ein problemorientierter Lösungsansatz sowie
für das KitVes-System Gestaltungsansätze für die Risikominimierung der Wechselwirkung zwischen dem Seil und der Trommel.

In Kapitel 4 werden diese Beispiele aus Abschn. 3.3 wieder aufgegriffen, um zu zeigen, welche Auswirkungen die Präzisierung des GSE-Vorgehenskonzeptes auf das GSE-Denkmodell haben.

Zusammenfassend ist es Ziel des Kapitels 4, die Module des GSE-Vorgehenskonzeptes detaillierter vorzustellen. Es soll beispielhaft dargestellt werden, wie spezielle Methoden und Verfahren ausgewählt, miteinander gekoppelt und so zur Anwendung gebracht werden können, dass aus dem universellen GSE-Vorgehenskonzept ein spezifischer, fachdisziplinbezogener Problemlösungsansatz entsteht. Dieser wird schrittweise in den nachfolgenden Kapiteln betrachtet, wie es aus der Abb. 4.4 hervorgeht, d. h. für das Analysemodul (rot) in Abschn. 4.1, für das Zielbildungsmodul (grün) in Abschn. 4.2, für das Gestaltungsmodul (braun) in Abschn. 4.3, für das Projektmanagementmodul (grau) in Abschn. 4.4 und die Interaktion des GSE-Denkmodells mit dem GSE-Vorgehenskonzept in Abschn. 4.5.

4.1 Das GSE-Analysemodul und ausgewählte Methoden und Verfahren

Grundsätzlich dient das GSE-Analysemodul der Problemdefinition, welche prinzipiell durch das SE möglich sein muss (Arlt 1999). Die Analyse der Systemelemente, der Wechselbeziehungen der Elemente untereinander sowie der Interaktion mit der Systemumwelt, so wie es HÄUSLEIN vorsieht, ist nicht Gegenstand des GSE-Analysemoduls (vgl. Häuslein 2004). Diese Systemanalyse muss Bestandteil des Workflows zum Erstellen des Denkmodells sein. Zweck der Analyse ist es, so HABERFELLNER, die Situation begreifbar zu machen, d. h. das Problem und seine Ursachen zu verstehen, dieses einem System zuzuordnen sowie strukturiert Informationen zur Problemlösung zu sammeln (vgl. Haberfellner et al. 2012).

Das GSE-Denkmodell ist einerseits Basis für die Analyse. Andererseits muss das Analysemodul (rot) die Analyseergebnisse in das GSE-Denkmodell selbst sowie in das Zielbildungs- und in das Gestaltungsmodul, so wie Abb. 4.5 dargestellt, einfließen lassen.

Das bereits in Abschn. 2.1 dargestellte Beispiel des rutschenden Zuges auf dem Laub verdeutlichte, wie wichtig es ist, die Systemgrenzen eindeutig zu definieren, um zielgerichtet einen Lösungsraum zu fixieren, der es gestattet, optimale Lösungen zu entwickeln. Somit setzt die Problemfindung ein Abbild des Systems – hier im speziellen Fall: Zug, Schiene und Umwelt – zumindest als Black-Box-Modell voraus. Dieses grobe Abbild des Systems kann die Basis für die Analyse sein. Mithilfe des GSE-Analysemoduls ist es in der Folge möglich zu klären, welche möglichen Ursachen in dem betrachteten System zum Rutschen des Zuges führten. Für die detaillierte Problemerkennung des auf Laub rutschenden Zuges, welches Aufgabe des GSE-Analysemodules ist, sind verschiedenste Analysemethoden und -verfahren einsetzbar (vgl. Abb. 4.5). Einige ausgewählte Verfahren sollen nachfolgend auszugsweise erläutert und ihre Interaktion mit dem GSE-Denkmodell beispielhaft skizziert werden.

Grundsätzlich kann unterschieden werden in:

universelle Methoden und Verfahren sowie
spezielle Methoden und Verfahren.

Unter dem Begriff „universelle Methoden und Verfahren“ wird subsummiert, dass diese im Analyse-, im Zielbildungs-, und/oder im Gestaltungsmodul anwendbar und nicht auf einen bestimmten Gegenstand, wie zum Beispiel auf Fehler oder auf Szenarien, bezogen sind. Als Verfahren werden systematische Vorgehensweisen bezeichnet. Methoden umfassen in Erweiterung dessen ein System von Regeln zum zielorientierten Realisieren von theoretischen und praktischen Tätigkeiten (vgl. Winzer 1997, S. 107). Zu universellen Verfahren zählen das Brainstorming, das Brainwriting oder das Mind Mapping. Alle drei Verfahren dienen der strukturierten Sammlung von Meinungen einzelner Gruppenmitglieder, die an der Problemlösung beteiligt sind. Bezogen auf das eben erwähnte Beispiel „Zug“, können die genannten Verfahren systematisch mögliche Ursachen für das Rutschen des Zuges analysieren. In diesem speziellen Einsatzfall werden sie dem GSE-Analysemodul zugeordnet. Wird in dem Problemlösungsprozess für den rutschenden Zug jedoch hinterfragt, welches die wichtigsten Ziele zur Vermeidung des Rutschens der Züge auf dem Laub sind, so können diese drei genannten Verfahren auch im Zielbildungsprozess, d. h. im GSE-Zielbildungsmodul, eingesetzt werden. Sollen weiterführend Gestaltungsideen generiert werden, die das Rutschen des Zuges auf dem Laub verhindern, können die bereits erwähnten Verfahren ebenfalls Anwendung finden. Deshalb werden sie als universelle Verfahren bezeichnet, die im GSE-Ansatz sowohl im Analyse-, im Zielbildungs- und im Gestaltungsmodul zum Einsatz kommen können. Das Herstellen der Beziehung zum GSE-Denkmodell ist dabei besonders wichtig. Für das Beispiel „rutschender Zug auf Laub“ bedeutet das, dass alle Ideen, die im Brainstorming entstanden sind, dem Systemabbild zugeordnet werden müssen. So muss die Idee des Einsatzes eines Laubgebläses sowohl dem „Zug“ wie auch den „Bahngleisen“ einschließlich der Lärmminderungsanalyse zugeordnet und erneut hinterfragt werden, welche Auswirkungen ihre Umsetzung auf das jeweilige Teilsystem hat. Gleiches gilt für die Idee, den Zug schwerer zu gestalten oder Sand auf die Schienen zu streuen. So können die Ideen am Denkmodell geprüft und weiterverfolgt werden. Die Transparenz und Rückverfolgbarkeit der Ergebnisse aus der Anwendung von universellen Verfahren wird nur systematisch über das GSE-Denkmodell generiert, d. h. über das Systemabbild, welches das gemeinsame Systemverständnis des transdisziplinären Teams transparent darstellt. Wird dies vernachlässigt, sind die Ergebnisse der genannten Verfahren schwer nachvollziehbar für Teilnehmer, die nicht an den Workshops teilnahmen. Ihnen ist das Systemabbild, welches als Basis diente, nicht bekannt. Möglicherweise besitzen sie eigene Modelle. So kann es zu Fehlinterpretationen der Ergebnisse kommen, da der Betrachter der Ergebnisse ein anderes Denkmodell hat, welches ebenfalls nicht transparent ist. Wird z. B. nicht der Zug als Teilsystem betrachtet, sondern nur die Interaktion der Teilsysteme „Rad“ und „Schiene“, kommt es mit den eben genannten Verfahren zu ganz anderen Analyseergebnissen. Folglich sind die Ergebnisse, obwohl gleiche Verfahren zum Einsatz kamen, nur begrenzt vergleichbar, weil sie auf unterschiedlichen Denkmodellen basierten.

Dieses Beispiel verdeutlicht, dass die skizzierten universellen Verfahren einerseits eine zwingende Interaktion mit dem GSE-Denkmodell voraussetzen, andererseits sowohl im GSE-Analyse-, GSE-Zielbildungs-, als auch im GSE-Gestaltungsmodul einsetzbar sind. Diese genannten universellen Verfahren sind branchenunabhängig, d. h. sie sind nicht nur anwendbar für die Gestaltung von Verkehrssystemen, wie hier im Beispiel „rutschender Zug auf Laub“ dargestellt, sondern auch für die Entwicklung neuer Dienstleistungen, für das Re-Engineering eines mechatronischen Systems oder die Umgestaltung eines Unternehmens, um nur einige Beispiele zu nennen.

Zusammenfassend sind universelle Methoden und Verfahren sowohl im GSE-Analyse, GSE-Zielbildungs- und im GSE-Gestaltungsmodul einsetzbar, als auch branchen- sowie gegenstandsunabhängig nutzbar.

Was sind nun spezielle Methoden und Verfahren?

Spezielle Methoden und Verfahren für das GSE-Analysemodul sind durch drei Merkmale beschreibbar:

a)
Sie dienen nur der Problemerkennung, d. h. sie sind nur im GSE-Analysemodul einsetzbar. Beispiele hierfür sind die Q7-Werkzeuge, wie das Histogramm, das Pareto-Diagramm, das Korrelationsdiagramm oder das Datensammelblatt, um nur einige zu nennen.
b)
Sie dienen nur der Analyse eines ganz speziellen Sachverhaltes oder Gegenstandes, z. B. :
- der Analyse von Fehlern über Fehlersammelkarten, Fehlerbäume oder der Fehlzustandsart- und Auswirkungsanalyse (FMEA) oder
- der Analyse von Kundenanforderungen über die Conjoint-Analyse,
- das Kano-Modell oder
- der Analyse von Ursachen-Wirkungsketten, über das Flussdiagramm oder das Ishikawa-Diagramm.
c)
Sie sind nur in einer spezifischen Branche einsetzbar. Beispiele hierfür sind:
- die Analyse der Zuverlässigkeit von Sicherheitsgurten (Automobilbranche),
- die Analyse der Witterungsbeständigkeit von Asphalt (Baubranche) oder
- die Analyse der Zugfestigkeit von Stoffen (Textilindustrie).

Zusammenfassend dienen die speziellen Methoden und Verfahren, welche im GSE-Analysemodul zum Einsatz kommen, entweder der Problemerkennung oder/und der Analyse eines ganz speziellen Sachverhaltes, oder/und sie sind nur für eine spezifische Branche einsetzbar.

Auch für die speziellen Methoden und Verfahren des GSE-Analysemoduls gilt, dass diese zwingend mit dem GSE-Denkmodell in Verbindung gebracht werden müssen, wie Abb. 4.6 auszugsweise für die Q7-Werkzeuge darstellt.

Ist es das Ziel, dass die Analyseergebnisse weiter verwendet, bzw. durch Dritte nicht an der Analyse beteiligte Personen nachvollziehbar sein sollen, dann müssen die Analyseergebnisse mit dem GSE-Denkmodell, so wie in Abb. 4.6, in Verbindung gebracht werden. Über das Denkmodell kann die unbeteiligte Person die Analyseergebnisse verstehen und weiter verwenden. So können, wie in Abb. 4.6 dargestellt, die erhobenen Daten eindeutig einem Systemelement oder einer Systemsicht zugeordnet werden.

Gleiches gilt für das Pareto-Diagramm oder das Korrelationsdiagramm, welche Wechselwirkungen zwischen Systemelementen oder Systemsichten darstellen können. Auch diese sind über das GSE-Denkmodell eindeutig zu definieren und gegebenenfalls zu präzisieren.

Nachfolgend sollen die Interaktionen von speziellen Methoden und Verfahren des GSE-Analysemoduls mit dem GSE-Denkmodell an drei Sachverhalten skizziert werden, d. h.:

1.
der Analyse von Fehlern,
2.
der Ermittlung von Kundenanforderungen sowie
3.
der Analyse von Ursache- u. Wirkungsketten.

Beispiel 1: Die Darstellung der Wechselwirkungen zwischen GSE-Analysemodul und GSE-Denkmodell am Beispiel spezieller Verfahren zur Fehleranalyse

Die Analyse von Fehlern in einem System kann mit unterschiedlichsten Methoden und Verfahren erfolgen, sei es mit der Fehlersammelkarte, mit der Fehlerbaumanalyse oder mit FMEA. Fehler sind definiert als nicht erfüllte, festgelegte Forderungen (DIN EN ISO 9000:2008).

Der Nachweis über den Grad der Erfüllung von Forderungen setzt ein Denkmodell voraus, welches die Anforderungen in Korrelation mindestens zum System, weiterführend auch zu den Systemelementen bzw. deren Wechselwirkung, stellt. Das wird durch das GSE-Denkmodell, welches mit DeCoDe erstellt wurde, garantiert. Erfüllt eine Komponente oder eine Funktion des betrachteten Systems die Anforderungen nicht, kann so der Fehler detektiert und genauer beschrieben werden.

Wie sieht dies bei der FMEA, einer Methode zur Analyse, Bewertung und Beseitigung von Fehlern aus?

Die Norm zur FMEA (vgl. DIN EN 60812-2006) fordert, dass zunächst die verschiedensten Systembestandteile mit ihren Merkmalen, Leistungen, Aufgaben und Funktionen dokumentiert sowie die logische Verknüpfung zwischen den Systembestandteilen festgehalten werden müssen. Bisher schreibt die Norm dazu keinen standardisierten Input vor. Diesen kann das mit DeCoDe erstellte GSE-Denkmodell geben (vgl. Abb. 4.7).

Ist die Anforderungssicht im GES-Denkmodell fehlerhaft oder im Systemabbild nicht mit der Komponenten-, Funktions- und Prozesssicht verknüpft, so ist dies ein Indiz für potentielle Fehler. Deren Ursachen können über die Wechselbeziehungen zwischen den Systemsichten, z. B. Funktion-Komponentensicht oder Funktion-Prozesssicht, aber auch innerhalb der Systemsicht erkannt werden. Folglich bildet das GSE-Denkmodell den Input für die genannten Schritte, d. h. die Fehlerdefinition, die Ermittlung der potentiellen Ursachen und die Entwicklung von Ideen für abzuleitende Maßnahmen, wie in Abb. 4.8 zusammenfassend dargestellt wird.

Eingangsinformationen für die FMEA aus DeCoDe:

Beschreibung der Merkmale über Komponenten oder Funktionen (1) (vgl. Abb. 4.8),
Beschreibung der potentiellen Fehler als Nichterfüllung von Anforderungen (2) (vgl. Abb. 4.8),
Identifizieren der potentiellen Fehlerursachen über Wechselbeziehungen zwischen den Systemelementen (3) (vgl. Abb. 4.8).

Ausgangsinformationen der FMA für DeCoDe:

Beschreibung der Kritizität von Funktionen und Komponenten über die Risiko-Prioritätszahl (RPZ) (4) (vgl. Abb. 4.8)
Anpassung des Systemmodells gemäß der getroffenen Maßnahmen (5) (vgl. Abb. 4.8).

Durch die FMEA ist die Kritizität des potentiellen Fehlers mit seinen möglichen Ursachen über eine Risikoprioritätszahl zu bewerten (vgl. Punkt 4 aus Abb. 4.8). Das bildet die Basis für die Entwicklung von Maßnahmen zu zielgerichteten Veränderungen des Systems. Diese Maßnahmen wiederum müssen logischerweise zu einer Anpassung der Systemmodellierung führen, d. h. einer Veränderung des GSE-Denkmodells. Somit entsteht ein präzisiertes GSE-Denkmodell, welches die ursprünglich identifizierten Fehler nunmehr vermeidet.

Durch diese skizzierte Vorgehensweise der Kopplung der FMEA mit dem GSE-Denkmodell wird deutlich, dass durch die systembasierten, standardisierten Input- und Output-Informationen diese Methode effizienter einsetzbar wird. Soll ein Team potentielle Fehler mithilfe der FMEA bewerten, muss sich dieses Team nicht selbst ein Systemabbild schaffen, sondern kann sich eines bereits entwickelten GSE-Denkmodells, z. B. von einem Antrieb, bedienen. Auf dieser Basis ist es nun möglich, die sich im Nutzungsprozess lösende Steckverbindung, welche die Stromversorgung für den Antrieb sichern sollte, genauer zu analysieren. Die von dem Team entwickelten Ergebnisse können anschließend in das bereits bestehende Modell „Antrieb“ wieder zurückgeführt werden. Die mithilfe der FMEA eingeleiteten Verbesserungsmaßnahmen sind über das präzisierte Systemmodell „Antrieb“ nachvollziehbar.

Beispiel 2: Die Analyse der Kundenanforderung im Wechselspiel mit dem GSE-Denkmodell

Kundenanforderungen können mithilfe der Conjoint Analyse oder dem Kano-Modell, um nur zwei Methoden zu nennen, analysiert werden. Es sind spezielle Analysemethoden, die dem GSE-Analysemodul prinzipiell zuordenbar sind. Nachfolgend soll eine Möglichkeit dargestellt werden, wie die Kundenanforderungen in Kopplung mit dem GSE-Denkmodell systematischer analysiert werden können.

Kundenanforderungen sind Teilaspekte der Anforderungssicht des generischen Systemmodellansatzes. Als Kunde wird in diesem speziellen Fall der Endkunde verstanden. Andere Stakeholder wie Verbände, der Gesetzgeber etc., können auch Anforderungen generieren, die ebenfalls Teil der Anforderungssicht sind. Diese werden bei dem nachfolgenden Beispiel nicht betrachtet.

Soll analysiert werden, ob die Kundenanforderungen erfüllt werden oder nicht, bedarf es auch hier ihrer eindeutigen Zuordnung zu den jeweiligen anderen Sichten des Systemmodells. Da sich Kundenanforderungen über den Prozess der Leistungserbringung verändern können, ist eine zeitbezogene Zuordnung zum Systemansatz erforderlich, wie Abb. 4.9 darstellt.

An den jeweiligen Kundenkontaktpunkten (siehe Abb. 4.9) kann über das entsprechende Systemmerkmal zu einem ganz bestimmten Zeitpunkt der Grad der Erfüllung der Kundenanforderung spezifiziert werden. Dies setzt voraus, dass über den gesamten Zeitraum der Bewertung der Kundenanforderung das gleiche Systemmodell angewandt wird. Nur so können kontinuierlich Kundenanforderungen bewertet werden (Fiedrich 2010; Schlüter 2011; Schlüter und Sochacki 2012; Nicklas et al. 2011).

Beispiel 3: Die Analyse von Ursache-Wirkungs-Ketten in Wechselwirkungen mit dem Denkmodell

Ursache-Wirkungsketten sind über Flussdiagramme, aber auch sehr einfach über das Ishikawa Diagramm darzustellen. Mithilfe des Ishikawa Diagramms können ein Problem charakterisiert und potentielle Ursachen sowie mögliche Wirkungen auf das Problem in Form von Fischgräten veranschaulicht werden (vgl. Brüggemann und Bremer 2012). Im Allgemeinen charakterisiert das Ishikawa Diagramm fünf mögliche Ursachenfelder für das Problem. Das sind der Mensch, die Maschine, das Material, die Mitwelt oder die Methode. Dieses Ursache-Wirkungsdiagramm ist auch koppelbar mit dem Denkmodell des GSE-Ansatzes. So lässt sich das Verrutschen der Fußmatte und ihres Verklemmens mit dem Gaspedal (Fokus Online 2011) mit dem Systemmodell sehr einfach beschreiben (Abb. 4.10).

Mögliche Ursachen für das Verrutschen der Fußmatte können das Anfahren, das plötzliche Bremsen, das Verrutschen beim Ein- und Aussteigen etc. sein. Dies sind alles Unterprozesse des Nutzungsprozesses (Prozesssicht des GSE-Denkmodells). Ein weiterer Ursachenkomplex kann über die Art und Weise der Verankerung der Fußmatte mit dem Fahrzeug oder des Abstands des Gaspedals zum Fußraum gegeben sein. Dies ist über die Komponenten-Komponenten-Sicht im GSE-Denkmodell abbildbar. Durch die Funktionssicht, d. h. die Vernetzung von Brems- und Festigkeitsfunktion, ist ein weiterer Ursachenkomplex ableitbar. Die systematische Verknüpfung des Ishikawa Diagramms mit dem GSE-Denkmodell wird in Abb. 4.11 zusammenfassend schematisch veranschaulicht.

Somit ist eine strukturiertere Analyse möglich. Es ergeben sich aber auch Ideen zur Verbesserung des Denkmodells, wie Abb. 4.12 am Beispiel von Toyota darstellt.

Zusammenfassend verdeutlichen alle drei Beispiele, wie spezielle Analysemethoden und –verfahren, die dem GSE-Analysemodul zuordenbar sind, durch ihre Kopplung mit dem GSE-Denkmodell systematischer durchgeführt werden und nachvollziehbare Ergebnisse erzielen können. Das GSE-Denkmodell, genutzt als Input für die Methoden und Verfahren des GSE-Analysemoduls, ermöglicht eine schnelle fachübergreifende Verständigung über die Ausgangslage. Das ist möglich, weil ein bereits vorhandenes Abbild des Systems, welches erarbeitet wurde, verwendet werden kann. Nach erfolgter Analyse, so wie die Beispiele sie darstellen, können die Analyseergebnisse wiederum in das Systemabbild eingefügt werden. Dies führt folgerichtig zu Veränderungen des Systemabbildes. Durch einen Vergleich des Systemabbildes zum Zeitpunkt t₀ vor der Analyse mit dem nach der Analyse zum Zeitpunkt t_n kann die Systemveränderung nachvollziehbar gestaltet werden.

4.2 Das GSE-Zielbildungsmodul und ausgewählte Methoden und Verfahren

Ziele entstehen aus priorisierten und z. T. modifizierten Anforderungen an Systeme. HABERFELLNER charakterisiert den Zweck der Zielbildung als systematische Zusammenfassung von Absichten, die der Lösungssuche zugrunde gelegt werden (vgl. Haberfellner et al. 2012, S. 77). Aufgabe des Zielbildungsmoduls des GSE-Ansatzes ist es, aus der Anforderungsvielfalt genau die wichtigsten Anforderungen abzuleiten, um daraus Ziele zu bilden. Ziele können, wie in der Abb. 4.13 veranschaulicht, Eingangsinformationen für das Analysemodul (rot) sein. Sie sind aber auch Input für das Gestaltungsmodul (braun) oder auch für das Projektmanagementmodul im Rahmen des Projektcontrollings (grau).

Bevor die Auswahl und der Einsatz der in Abb. 4.13 schematisch dargestellten Methoden und Verfahren im Rahmen des GSE-Zielbildungsmoduls beschrieben wird, sollen zuvor die wesentlichen Wege skizziert werden, die zum Ableiten von Zielen im Rahmen des GSE führen können. Die Zielbildung erfolgt in der Interaktion mit dem Denkmodell. Ziele, welche das wichtigste Ergebnis des Zielbildungsprozesses sind, entsprechen priorisierten und zum Teil präzisierten Anforderungen, die gleichzeitig eine standardisierte Sicht im Systemmodell des GSE-Ansatzes sind. Daher begründet sich die dominierende Interaktion des Zielbildungsmoduls des GSE-Vorgehenskonzeptes mit dem GSE-Denkmodell.

Grundsätzlich kann die Zielbildung im GSE-Vorgehenskonzept über drei wesentliche, in Abb. 4.14 veranschaulichte, Wege erfolgen:

1.
Durch das Ermitteln der Stakeholder und deren Anforderungen an ein System werden, gestützt durch verschiedenste Methoden, Ziele abgeleitet.
2.
Durch das Herausfiltern nicht erfüllter Anforderungen erfolgt die Zielbildung unmittelbar. Dieses kann:
1. a)
  direkt aus dem Denkmodell herausgefiltert oder
2. b)
  basierend auf Methoden und Verfahren über den Lebenszyklus des Systems analysiert werden.
3.
Durch anforderungsrelevante Ereignisse, die im Laufe des Lebenszyklus‘ eines Systems auftreten können, ist das Ableiten von nicht erkannten Anforderungen bzw. das Präzisieren bereits vorhandener Anforderungen möglich. Auch dazu sind spezielle Methoden und Verfahren erforderlich.

Nachfolgend werden diese Wege im Einzelnen zur Generierung der erforderlichen Eingangsinformationen für das GSE-Zielbildungsmodul mit den möglich anwendbaren Methoden und Verfahren beschrieben. Abschließend erfolgt eine Kurzcharakteristik möglicher Methoden, die Ziele direkt aus den Ausgangsinformationen des GSE-Denkmodells im GSE-Zielbildungsmodul generieren können.

Zu 1. Die Zielbildung auf der Basis der ermittelten Stakeholder und deren Anforderungen

Dieser Weg zur Ableitung von Eingangsinformationen für das GSE-Zielbildungsmodul umfasst folgende wichtige Schritte:

1.
Das Ermitteln und das Priorisieren der Stakeholder.
2.
Das Erheben der Anforderungen der Stakeholder.
3.
Das Vergleichen der Anforderungen und das Erkennen von Widersprüchlichkeiten und Dopplungen.
4.
Das Wichten und Bewerten der Anforderungen.

Die Ergebnisse aus diesen Schritten gehen einerseits in das in Abb. 4.15 rechts dargestellte GSE-Denkmodell ein. Sie dienen dem Erstellen der Anforderungssicht.

Andererseits sind diese Resultate Eingangsinformationen für das GSE-Zielbildungsmodul, um diese zu bewerten und den Grad der Erfüllung von Anforderungen, d. h. die Ziele, zu fixieren.

Grundsätzlich können gegenwärtige und zukünftige, auch nicht ausgesprochene Anforderungen von Stakeholder in diesem Prozess Input sein. Die hierfür geeigneten Methoden und Verfahren erfassen häufig nur Teilaspekte. So werden gegenwärtige und zukünftige Stakeholder über den Stakeholder-Radar ermittelt (vgl. Abb. 4.16).

Dagegen erfolgt das Erheben bestehender und zukünftiger Anforderungen zum Beispiel über Markt- und Fokusgruppenanalysen. Andere Methoden und Verfahren, wie beispielsweise das Anforderungsmanagement, ermitteln nicht nur Anforderungen, sondern vergleichen, werten und wichten diese.

Wieder andere Methoden und Verfahren fokussieren sich nur auf eine Gruppe von Stakeholdern, wie den Kunden im Kansei Engineering (vgl. Schütte 2002). Dabei werden noch nicht ausgesprochene Anforderungen des Kunden erfasst (vgl. Abb. 4.17). Ist es Ziel, mit dem neu zu entwickelnden Produkt den Kunden zu begeistern, reicht das Ermitteln bereits bestehenden Anforderungen nicht aus. Es sind in diesem Fall auch die potentiellen bzw. die noch nicht ausgesprochenen Anforderungen zu erheben, so wie es das Kansei Engineering ermöglicht.

Eine andere Gruppe von Methoden und Verfahren prognostiziert Anforderungen und vergleicht sie mit den Gegenwärtigen. Stellvertretend hierfür sei die Szenariotechnik genannt, wie in Abb. 4.18 dargestellt. Auf der Basis gegenwärtiger und zukünftiger Anforderungen leitet GAUSEMEIER mittels Szenarien Ziele für das Produkt Engineering ab.

Keine dieser genannten Methoden und Verfahren erfasst gleichzeitig alle Stakeholder sowie deren gegenwärtige und zukünftige, latente bzw. bestehende Anforderungen. Somit können all diese Informationen nicht vergleichend betrachtet, gewichtet und bewertet werden, um sie als Eingangsinformation in den Zielbildungsprozess des GSE-Vorgehenskonzeptes direkt einfließen lassen zu können. Aus diesem Grund ist es immer erforderlich, verschiedenste Methoden und Verfahren, wie in diesem Abschnitt skizziert, so miteinander zu verbinden, dass ein effizienter Zielbildungsprozess möglich wird.

Zu 2. Das Ermitteln nicht erfüllter Anforderungen als Eingangsinformation für das GSE-Zielbildungsmodul

Nicht erfüllte Anforderungen können aus dem GSE-Denkmodell abgeleitet und unmittelbar als Eingangsinformationen im GSE-Zielbildungsmodul Verwendung finden. Da das GSE-Denkmodell die Anforderungssicht direkt mit der Komponenten-, Funktions- und Prozesssicht in Verbindung bringt, ist erkennbar, welche Anforderungen nicht durch Komponenten und/oder Funktionen sowie Prozesse erfüllt sind. Durch das Selektieren genau dieser Anforderungen können Eingangsinformationen direkt aus dem GSE-Denkmodell für das GSE-Zielbildungsmodul gewonnen werden. Hierfür gibt es zwei grundsätzliche Varianten:

A)
Das Ermitteln von nicht erfüllten Anforderungen unmittelbar beim Erstellen des GSE-Denkmodells.
B)
Die gezielte Suche von nicht erfüllten Anforderungen im Verlauf des Lebenszyklus‘ eines Systems.

Beide Varianten sollen nachfolgend an ausgewählten Beispielen veranschaulicht werden.

Variante A

Über das GSE-Denkmodell können nicht erfüllte Anforderungen gezielt ermittelt werden, wenn das Denkmodell mithilfe der DeCoDe-Tools (Sitte und Winzer 2011) erstellt wurde. Sie sind Eingangsinformation für das GSE-Zielbildungsmodul. Der Grad des Erfüllens dieser Anforderungen muss ebenfalls im Zielbildungsprozess fixiert werden, wie das nachfolgende Beispiel des Re-Designs einer Sitzlehne demonstriert. Einer ihrer Hersteller hatte die Aufgabe, ein neues Subsystem für die Lehnenwinkeleinstellung zu entwickeln (vgl. Abb. 4.19).

Das neu zu entwickelnde Teilsystem sollte elektrische Energie in rotatorische, mechanische Energie umwandeln. Bei dem Erstellen des GSE-Denkmodells wurde festgestellt, dass es für diese Umwandlungsfunktion kein Subsystem bzw. Komponenten gab, wie die Abb. 4.20 veranschaulicht.

Aus diesem Grund erfolgte für genau diese Anforderung branchenübergreifend die Suche nach einem passenden Subsystem, wie Abb. 4.21 darstellt.

Das neue Subsystem wurde erneut in das Abbild des Systems eingefügt. Im Ergebnis konnte über das präzisierte Denkmodell nachgewiesen werden, dass nun die Anforderungen erfüllt sind.

Zusammenfassend zeigt dieses Beispiel, dass es mithilfe des GSE-Denkmodells über die direkte Vernetzung der Anforderungssicht mit der Komponenten-, Prozess- und Funktionssicht möglich ist, nachzuweisen, welche Anforderungen bereits erfüllt, bzw. welche noch nicht erfüllt sind. Nicht erfüllte Anforderungen finden automatisch Eingang in den GSE-Zielbildungsprozess, so wie das Beispiel des Antriebs für die Sitzlehne verdeutlicht.

Variante B

Nicht erfüllte Anforderungen können nicht nur, wie eben dargestellt, im Produktentwicklungsprozess sondern über den gesamten Lebenszyklus eines Produktes oder eines Systems detektiert werden. Diese werden dann als Fehler oder Reklamation bezeichnet. Ziel des Fehler- bzw. Reklamationsmanagement ist es, die Fehler bzw. Reklamationen, d. h. die nicht erfüllten Anforderungen, die im Lebenszyklus eines Systems erkannt werden, zu beseitigen. Sein Grundprinzip stellt nachfolgende Abb. 4.22 dar.

Nicht erfüllte Anforderungen im Lebenszyklus eines Systems können sehr schnell ermittelt werden, wenn es gelingt, sie mit dem GSE-Denkmodell zu vergleichen. Dabei muss aber auch das Abbild des Systems über den Lebenszyklus präzisiert werden.

Zu 3. Die Zielbildung auf der Basis des Ermittelns neuer bzw. des Präzisierens bestehender Anforderungen bedingt durch das Entstehen von anforderungsrelevanten Ereignissen

Bisher wurden nur Fälle beschrieben, in denen nicht erfüllte Anforderungen direkt Eingang in den GSE-Zielbildungsprozess fanden. Im Verlauf eines Systemlebens können Ereignisse (anforderungsrelevante Ereignisse) entstehen, aus denen sich völlig neue, bisher nicht erkannte Anforderungen ergeben oder Anforderungen präzisiert bzw. erweitert werden müssen (Schlund 2011). Aus ihnen dürfen nicht unmittelbar Ziele abgeleitet werden, weil sie zunächst mit den bisherigen Zielen zu vergleichen sind. Erst auf Grund dieses Vergleichs kann festgestellt werden, ob die ursprünglichen Ziele nur zu präzisieren oder grundsätzlich zu verändern sind. Folglich stellen sie nur eine weitere Eingangsinformation für das GSE-Zielbildungsmodul dar, welches dadurch erneut angestoßen und wiederholt durchlaufen werden muss. Dieser Fall entspricht dem dritten, in Abb. 4.14 dargestellten Weg zur Gewinnung von Eingangsinformationen für das GSE-Zielbildungsmodul.

Die nicht erkannten Anforderungen oder die Präzisierung bereits bestehender Anforderungen können sich über den Produktlebenszyklus immer wieder ergeben, gestützt durch das Ideenmanagement oder durch Poka Yoke, wie Abb. 4.23 verdeutlicht wird.

Im Verlauf eines Produktlebens kann es erneut zu Problemen kommen, die sich aus Störungen, Reklamationen, Garantieansprüchen oder Beschwerden ergeben. Lassen sich aus diesen Ereignissen neue Anforderungen ableiten bzw. tragen sie zur Präzisierung bestehender Anforderungen bei, werden sie als anforderungsrelevante Ereignisse bezeichnet. Im Gegensatz zu SCHLUND (vgl. Schlund 2011), wird der Fehler nicht als anforderungsrelevantes Ereignis bezeichnet. Der Fehler kann nur definiert werden, wenn zuvor eine Anforderung fixiert war, welche bereits in den Zielbildungsprozess einging und nun im Verlauf des Lebenszyklus‘ des Systems festgestellt werden musste, das diese Anforderung nicht erfüllt ist. Folglich muss der Fehler direkt in den GSE-Zielbildungsprozess Eingang finden und dann beseitigt werden. Ganz anders verhält es sich mit den im Verlauf des Produktlebenszyklus‘ ermittelten neuen bzw. präzisierten Anforderungen, wie Abb. 4.23 veranschaulicht.

Wenn ein Antrieb einer logistischen Anlage für den Transport von Gütern bis zu 10 kg ausgelegt ist und ein Kunde aber Waren bis zu 25 kg mit dieser Anlage transportieren möchte, muss nun durch ihren Hersteller entschieden werden, ob ein Re-Design erforderlich ist. Das kann über den GSE-Zielbildungsprozess durch den Vergleich mit den anderen, bereits bestehenden Anforderungen entschieden werden. Es erfordert aber immer ein Spiegeln der anforderungsrelevanten Ereignisse am GSE-Denkmodell, welches für dieses Beispiel im Abschn. 3.3 beschrieben wurde. Der Input, welcher für die Zielbildung aus dem Evaluierungsprozess veränderter Systeme – Ausgangsinformation des Gestaltungsmoduls – entsteht, wird ausführlicher im Abschn. 4.3 erläutert.

Bisher wurden die drei Möglichkeiten zur Ermittlung der Eingangsinformationen für das GSE-Zielbildungsmodul beschrieben. Diese umfassen:

1.
die Ermittlung der Stakeholder und deren Anforderungen,
2.
das Eliminieren nicht erfüllter Anforderungen sowie
3.
das Erkennen neuer bzw. das Präzisieren bestehender Anforderungen auf der Basis von anforderungsrelevanten Ereignissen.

Die hierfür erforderlichen Methoden und Verfahren wurden in diesem Zusammenhang ebenfalls dargestellt. Jedoch können weitere Methoden und Verfahren direkt in den GSE-Zielbildungsprozess integriert werden, um die Anforderungen zu priorisieren, zu wichten, zu werten und darauf aufbauend Ziele abzuleiten. Eine entsprechende Auswahl hierfür wird nachfolgend skizziert.

Methoden und Verfahren, die im Rahmen des GSE-Zielbildungsmoduls eingesetzt werden können

Klassische Methoden, welche im Zielbildungsprozess Anwendung finden, sind u. a.:

die Delphi-Methode,
die Conjoint-Analyse,
die Konsistenzmatrix,
die Mind Map,
das Quality Function Deployment (QFD) bzw. das House of Quality, aber auch
das Requirements Engineering.

Während die Delphi-Methode über Expertenbefragungen das Priorisieren von Anforderungen und von Zielen ermöglicht, werden Zielkonflikte über die Konsistenzmatrix herausgefiltert. Sich widersprechende Anforderungen bzw. Zielkonflikte können auch über die klassische Mind Map ermittelt werden (vgl. Lindemann 2005). Ein Priorisieren von Anforderungen ist ebenfalls über das House of Quality möglich (vgl. Abb. 4.24).

Die eingangs formulierten Anforderungen können über Produktvergleiche, aber auch über den Stand der Umsetzung in technische Merkmale geprüft werden. Das ist die Basis für eine entsprechende Zielbildung. Jedoch fokussiert die QFD ausschließlich auf Kundenforderungen und spiegelt sie nur an technischen Merkmalen wider, um so den Grad der Zielerreichung darzustellen.

Die klassische Delphi-Methode und die Konsistenzmatrix konzentrieren sich auf das Priorisieren der Anforderungen und somit auf den Zielbildungsprozess.

Auch die Methoden und Verfahren des Requirements Engineering können im Rahmen des Zielbildungsmoduls eingesetzt werden. Grundsätzlich umfasst das Requirements Engineering das Erfassen, Systematisieren, Strukturieren, Bewerten, Umsetzen und Kontrollieren von Anforderungen. Während das Umsetzen und Kontrollieren von Anforderungen in die Gestaltungsphase einzuordnen ist, gehören das Ermitteln, Strukturieren, Systematisieren und Bewerten von Stakeholdern und deren Anforderungen in den Zielbildungsprozess des GSE-Ansatzes. Das Requirements Engineering ist vergleichbar mit dem klassischen Zielbildungsprozess und den dort eingesetzten Methoden und Verfahren, so wie es LINDEMANN (vgl. Lindemann 2005) beschreibt. Es ist jedoch allgemein bekannt, dass sich Anforderungen im Laufe eines Produktlebenszyklus‘ ändern. Wie wird diese Veränderung erfasst? Welche Auswirkungen hat dies auf den Zielbildungsprozess und welche auf den Gestaltungsprozess? Wie werden neue, im Verlauf des Produktlebenszyklus entstehende Anforderungen erhoben, fixiert und in die Zielbildung eingebunden? Die Beantwortung dieser Fragen setzt voraus, dass das GSE-Zielbildungsmodul über den Produktlebenszyklus permanent in Wechselwirkung mit dem GSE-Analyse- und dem GSE-Gestaltungsmodul sowie dem GSE-Denkmodell stehen muss. Wie dies erfolgen kann, soll in Kap. 5 weiter ausgeführt werden.

In diesem Kapitel wurden Methoden und Verfahren dargestellt, die einerseits zur Gewinnung von Eingangsinformationen für das GSE-Zielbildungsmodul dienen und andererseits direkt im Zielbildungsprozess zur Anwendung kommen können. Im folgenden Kapitel soll näher darauf eingegangen werden, wie die Ausgangsinformationen des GSE-Zielbildungsmoduls nun im GSE-Gestaltungsmodul weiter verarbeitet werden.

4.3 Das GSE-Gestaltungsmodul und ausgewählte Methoden und Verfahren

Die Aufgabe des GSE-Gestaltungsmoduls ist es, Systeme neu zu entwickeln oder bestehende Systeme zu modifizieren. HABERFELLNER unterteilt die Systemgestaltung in die Architekturgestaltung, d. h. die Erarbeitung der grundsätzlichen Systemarchitektur, und die Konzeptgestaltung, welche die konkrete Ausgestaltung der ausgewählten Architektur umfasst (vgl. Haberfellner et al. 2012, S. 131). Folglich führen Gestaltungsergebnisse immer zur Veränderung des Systemmodells und setzen somit ein Systemmodell, sei es ein Black-Box- oder ein mittels DeCoDe-Tools erstelltes Modell, voraus.

Das GSE-Gestaltungsmodul steht nicht nur mit dem GSE-Denkmodell sondern auch mit dem Analyse- und Zielbildungsmodul des GSE-Vorgehenskonzeptes in Verbindung, wie Abb. 4.25 zeigt.

Die Eingangsinformationen für das GSE-Gestaltungsmodul können über mehrere Pfade entstehen:

1.
Sie werden direkt aus dem GSE-Denkmodell abgeleitet.
2.
Sie ergeben sich aus dem Analysemodul.
3.
Sie werden über das Zielbildungsmodul generiert.
4.
Sie entstehen im Verlauf der Projektrealisierung als notwendige Projektanpassung.

Die beiden ersten Möglichkeiten zur Ableitung von Eingangsinformationen für das GSE-Gestaltungsmodul wurden bereits in den vorangegangen Abschnitten beschrieben. Dennoch sollen zwei Beispiele dies kurz in Erinnerung rufen.

Zu 1. Das Ableiten von Eingangsinformationen für das GSE-Gestaltungsmodul aus dem GSE-Denkmodell

Ergeben sich Widersprüche zwischen Funktionen beim Erstellen des GSE-Denkmodells mittels der DeCoDe-Tools, so dienen diese direkt als Eingangsinformation für das GSE-Gestaltungmodul, wie das nachfolgende Beispiel zeigt.

Die Datenverarbeitungsfunktion bei einem PC wird über einen Prozessor realisiert. Dabei entsteht Wärme. Sie kann die Verarbeitungsfunktion, d. h. das Verarbeiten von Daten, stören. Folglich ist eine neue Funktion zur Ableitung von Wärme erforderlich. Diese kann direkt die Eingangsinformation für einen Gestaltungsprozess sein, zum Beispiel für die Gestaltung eines Lüfters, der diese Wärmeableitungsfunktion übernimmt. Somit wird bei dem Erstellen des GSE-Denkmodells mithilfe der DeCoDe-Tools für den PC über die Funktions-Funktionsmatrix eine Eingangsinformation für das GSE-Gestaltungsmodul erzeugt (vgl. Hartmann et al. 2011a).

Zu 2. Das Generieren von Eingangsinformationen für das GSE-Gestaltungsmodul über das GSE-Analysemodul

Auf der Basis der Abbildung des KitVes-Systems mithilfe des GSE-Denkmodells (vgl. auch Abschn. 3.3) konnte durch die detaillierte Analyse der Wechselwirkungen zwischen Komponenten mittels der MTTF festgestellt werden, dass das Seil nicht durch die Zugkräfte des Drachens sondern durch dessen Auf- und Abwickeln auf Trommeln am stärksten beansprucht wird (vgl. Abb. 4.26).

Die aus der MTTF gewonnenen Analyseergebnisse gingen direkt in den GSE-Gestaltungsprozess ein, wo neue Lösungsvarianten für die Gestaltung der Trommeln gesucht wurden; eine von ihnen stellt Abb. 4.27 dar.

Zu 3. Das Ableiten von Eingangsinformationen für das GSE-Gestaltungsmodul, welche aus dem GSE-Zielbildungsprozess entstehen

Dies entspricht dem idealisierten Weg, d. h. das GSE-Gestaltungsmodul wird nur angestoßen, wenn zuvor Ziele über das GSE-Zielbildungsmodul fixiert wurden. Für diese Variante werden nachfolgend ausgewählte Methoden und Verfahren beschrieben, die hier zum Einsatz kommen können. Dabei gibt es Methoden und Verfahren, die im Analyse-und Zielbildungs- wie im Gestaltungsmodul zur Anwendung kommen können, wie die Delphi-Methode, die Mind Map, das Brainstorming oder das Brainwriting, um nur einige zu nennen. Andere Methoden und Verfahren sind übergreifend über das Analyse-, Zielbildungs- und Gestaltungsmodul einsetzbar. So ermöglicht die FMEA sequentiell die Analyse von Fehlern, das Ableiten von Zielen über die Risikoprioritätszahl und das Ableiten von Gestaltungsmaßnahmen als ein Ergebnis des Gestaltungsprozesses. Auch die QFD kann sowohl für die Analyse wie für die Zielbildung und die Gestaltung eingesetzt werden. Zeigt das Dach des House of Quality Widersprüche zwischen technischen Merkmalen auf, so ist das eine wichtige Eingangsinformation für den Gestaltungsprozess, der mit speziellen Methoden und Verfahren, wie zum Beispiel TRIZ, eingeleitet werden kann (Wang et al. 2005).

Zusammenfassend ist einzuschätzen, dass das Gewinnen von Eingangsinformationen für das GSE-Gestaltungsmodul anwendungsfallspezifisch über folgende drei Pfade möglich ist, d. h. über:

das GSE-Denkmodell,
das GSE-Analysemodul oder
das GSE-Zielbildungsmodul.

Wenn die Grundprinzipien des systematischen Denkens und Handelns, wie z. B. das Grundprinzip der Strukturierung oder das Grundprinzip vom Ganzen zum Detail in das GSE-Vorgehenskonzept einfließen, so sollten zunächst das System analysiert und Ziele für die Gestaltung des Systems abgeleitet werden, bevor mit dem Gestaltungsprozess selbst begonnen wird. Doch in der Praxis kann das häufig nicht chronologisch stattfinden, zumal – wie in Abschn. 4.1 nachgewiesen – schon einige Analysemethoden, wie z. B. die FMEA spezifische Analyse-, Zielbildungs- und Gestaltungsansätze in einem Methodenkomplex beinhalten. Somit bekommt das Gestaltungsmodul des GSE-Ansatzes Input über das GSE-Denkmodell. Es kann aber über die Analyse und auch direkt über das GSE-Zielbildungsmodul Eingangsinformationen erhalten. Der Input über das GSE-Zielbildungsmodul sollte der bevorzugte Informationszugang für das GSE-Gestaltungsmodul sein. Das GSE-Gestaltungsmodul selbst bedient sich ebenfalls spezieller Methoden und Verfahren. Diese lassen sich aufgabenspezifisch unter Anwendung der Grundprinzipien des systematischen Denkens und Handelns kombinieren. Nun kann das GSE-Gestaltungsmodul, wie in Abschn. 2.3 schon kurz skizziert, durch zahlreiche Methoden und Verfahren unterstützt werden.

Umfassende Ausführungen hierzu sind auch bei LINDEMANN, HABERFELLNER, EHRLENSPIEL, FRANKE, GAUSEMEIER und PAHL et al. zu finden (Lindemann 2005; Lindemann et al. 2009; Haberfellner et al. 2012; Ehrlenspiel 2003; Franke 2002; Gausemeier et al. 2009; Pahl et al. 2005). Aus diesem Grund werden nachfolgend ausgewählte Methoden und Verfahren kurz vorgestellt, die bei den einzelnen Teilschritten des GSE-Gestaltungsmoduls Anwendung finden können.

Doch zuvor sollen die Schritte beschrieben werden, die Bestandteil dieses Moduls sind.

Zum GSE-Gestaltungsmodul gehören folgende Teilschritte:

die Definition des Lösungsraumes,
die Generierung von Lösungsideen,
die Entwicklung und Auswahl der Lösungsvarianten,
ihre Umsetzung und
die Evaluierung des Umsetzungsprozesses.

Die Definition des Lösungsraumes erfolgt in starker Interaktion mit dem GSE-Denkmodell. Das ist einerseits der Startpunkt für die Eingrenzung des Lösungsraumes, wie Abb. 4.28 darstellt.

Darauf aufbauend muss der Lösungsraum transparent begrenzt werden (vgl. Abb. 4.29), damit die zu entwickelnden Lösungsideen beherrschbar bleiben.

Erst danach empfiehlt es sich, spezielle Methoden und Verfahren für das Entwickeln, die Auswahl, die Umsetzung und die Evaluierung von Lösungsideen auszuwählen und im GSE-Gestaltungsmodul anzuwenden. Beispielhaft wird dies nachfolgend für diese Teilschritte des GSE-Gestaltungsmoduls skizziert.

Methoden und Verfahren zur Generierung von Lösungsideen

Die klassischen Methoden wie Brainstorming, Brainwriting und Mind-Mapping sind nicht nur für das Analyse- oder Zielbildungsmodul einsetzbar, sie sind auch für das Generieren von neuen Gestaltungslösungen geeignet. Ist es z. B. Ziel, den Computer für das Jahr 2040 zu entwickeln, dann können mithilfe der progressiven Abstraktion oder der Synektik schon erste Ideen generiert werden, wie ein mögliches Produktsystem aussehen könnte. Dieses ist aber grundsätzlich in seinen vier Sichten zu modellieren, d. h. in der Anforderungs-, der Komponenten-, der Funktions- und der Prozesssicht.

Methoden und Verfahren zur Entwicklung und Auswahl von Lösungsvarianten

Mithilfe der 635-Methode (Dahms 2010) können nun die einzelnen Lösungsvarianten grob und mithilfe der Six Hats (Jensen et al. 2000) im Detail bewertet werden. Auf dieser Basis kann die beste Gestaltungslösung ausgewählt und das dazugehörige GSE-Denkmodell sehr schnell präzisiert werden. Kommt es dort zu Widersprüchen zwischen Funktionen oder Komponenten, sind diese über die TRIZ-Methodik nach ALTSCHULER lösbar (Yamashina et al. 2002). Dadurch entstehen neue oder verbesserte Lösungsvarianten. Sie sind erneut zu bewerten. Die Bewertung kann auch mithilfe der Delphi-Methode (Häder 2009) oder durch den Einsatz des Morphologischen Kastens (Eversheim et al. 2006) erfolgen.

Methoden und Verfahren bei der Umsetzung und Evaluierung von Gestaltungslösungen

Bei der Umsetzung und Evaluierung der ausgewählten Gestaltungslösungen können ebenfalls verschiedenste Methoden und Verfahren zum Einsatz kommen, die bereits im GSE-Analyse- und/ oder GSE-Zielbildungsmodul zur Anwendung kamen, wie zum Beispiel das Ishikawa–Diagramm, welches die Ursache-Wirkungskette der Gestaltungslösung darstellen kann. Die FMEA ist auch geeignet, um Fehler die bei der Evaluierung der Gestaltungslösung gefunden werden, zielgerichtet zu beseitigen. Simulationstools oder das Rapidprototyping sowie der Musterbau und DoE (Design of Experiments) sind Methoden und Verfahren, die helfen können, Gestaltungslösungen zu evaluieren.

Die genannten bzw. die in der Literatur dargestellten Methoden und Verfahren (vgl. Haberfellner et al. 2012; Lindemann et al. 2009; Ehrlenspiel 2003; Pahl et al. 2005 etc.) können nicht eindeutig einem der vier Teilschritte im GSE-Gestaltungsmodul zugeordnet werden. Durch die Anwendung der Grundprinzipien des systematischen Denkens und Handelns im Gestaltungsmodul sind diese je nach Gestaltungsaufgabe kombinierbar. Wie dies im Detail realisiert werden kann, soll folgendes Beispiel demonstrieren: Im Rahmen des SFB 696 „Logistic on Demands“ war es Ziel des Teilprojektes B3 einen Methoden-Workflow zur Erhöhung der Zuverlässigkeit mechatronischer Systeme in den frühen Phasen der Produktentwicklung zu generieren (Künne und Richard 2009). Das ist eine reine Gestaltungsaufgabe. Im Ergebnis der Forschungsarbeiten konnte das Systemmodell für mechatronische Systeme, das mithilfe des GSE-Denkmodells unter Anwendung der DeCoDe-Tools generiert wurde (vgl. auch Abschn. 3.3), zielgerichtet mit Simulationstools, die der Gestaltung des Systemmodells dienten, verbunden werden. Dieses Grundprinzip stellt Abb. 4.30 dar.

Den grundsätzlichen Methoden-Workflow der die Simulationswerkzeuge des GSE-Gestaltungsmoduls mit dem GSE-Denkmodell so koppelt, dass die Zuverlässigkeit des Antriebs in bestimmten Situationen getestet werden kann, stellt Abb. 4.31 dar.

Dieser Methoden-Workflow diente der Optimierung des Antriebes für einen Rollenförderer. Dazu wurde zunächst der Antrieb in Wechselwirkung mit dem Rollenförderer in Form eines Systemmodells mithilfe der DeCoDe-Tools abgebildet. In den frühen Phasen der Produktentstehung musste nachgewiesen werden, dass der Antrieb bei einer bestimmten Last, die das Gurtband transportiert, ein ganz bestimmtes Drehmoment erzeugen kann. Der Grad der Erfüllung dieser Anforderung kann in den frühen Phasen der Produktentstehung nur über entsprechende Simulationstools nachgewiesen werden. Diese Ergebnisse sind in der nachfolgenden Grafik zu finden (vgl. Abb. 4.32).

Das Simulationstool – „ESB“ – weist nach, dass die Realisierung der entsprechenden Anforderungen, d. h. ein Drehmoment erzeugen und unter Volllast anfahren, über den entwickelten Antrieb möglich wird. Gleichzeitig konnte über die Simulation der Beweis erbracht werden, dass das Anlaufmoment durch die Anpassung der Rotorstäbe verändert werden kann (vgl. Abb. 4.33).

Die Drehmoment-Schlupf-Kennlinie (M/s-Kennlinie) der Beispielmaschine zeigt, dass das Anlaufmoment M_A geringer ist als das geforderte Nennmoment M_N. So wird deutlich, dass dieser Motor nicht in der Lage ist, das erforderliche Moment zu liefern. Anstatt den aktuellen Maschinentyp durch einen leistungsstärkeren auszutauschen, was zu einer noch größeren Überdimensionierung für den Normalbetrieb führen würde, kann über Veränderungen am Rotor (Tiefstab- oder Doppelkäfig-Läufer) die Kennlinie der Maschine derart angepasst werden, dass sie im Anlaufbereich höher verläuft und somit das Anlaufmoment vergrößert (neues Anlaufmoment M_A′, siehe Abb. 4.33) und die Anforderung M_A > M_N erfüllt wird. Diese Veränderung der Rotorstäbe musste dann wieder im GSE-Denkmodell abgebildet werden. Im Verlaufe der Modifikation des Rollenförderers kam eine neue Anforderung hinzu, nämlich die Erzeugung von Stoßfreiheit. Dieses ist mit der Momentenwelligkeit über den Antrieb auszugleichen. Hierfür ist ein entsprechendes Simulationstool – FLUX – notwendig, um zu überprüfen, ob genau diese Anforderung in den frühen Phasen der Produktmodifikation realisiert worden ist.

Die am Beispiel skizzierte Schrittfolge lässt sich über folgenden Workflow von Abb. 4.34 verallgemeinern.

Dieser Workflow verdeutlicht, dass zunächst ein Abbild des Antriebes mithilfe des GSE-Denkmodells generiert wurde. Das ergab entsprechende Inputs für die Anwendung von Simulationstools. Die Ergebnisse der Simulationstools, wie z. B. die Veränderung der Rotorstäbe, führten in Folge zu neuen Anforderungen, bzw. zu Veränderungen des Systemmodells. Neue Anforderungen machten wiederum Simulationen erforderlich und führten zu Veränderungen des GSE-Denkmodells. Somit konnte im Verlauf des Gestaltungsprozesses nachvollziehbar nachgewiesen werden, warum und weshalb sich welche Funktionen, Komponenten und Prozesse im Wechselspiel mit den Anforderungen ändern. Das Beispiel zeigt, wie Simulationstools als Gestaltungsinstrumente in den frühen Phasen der Produktentstehung sinnvoll mit dem GSE-Ansatz gekoppelt werden können. Dies ist nur möglich, wenn die Informations- bzw. Datenstruktur der Simulationstools systematisch, strukturiert und standardisiert in das Denkmodell überführt werden.

Aus diesem Grund fand das GSE-Denkmodell mit seinen vier Ansichten, d. h. der Anforderungs-, der Komponenten-, Funktions- und Prozesssicht in diesem Fall Anwendung. Es konnte nachgewiesen werden, dass dies ein gangbarer Weg ist, um rückverfolgbar, transparent, in transdisziplinären Teams mechatronische Produktsysteme zu gestalten.

Zusammenfassend kann auch für das GSE-Gestaltungsmodul festgestellt werden, dass es zahlreiche Methoden und Verfahren gibt, die einerseits Eingangsinformationen für das GSE-Gestaltungsmodul generieren und die andererseits gezielt die einzelnen Schritte im GSE-Gestaltungsmodul unterstützen. Diese Schritte sind nicht zyklisch, sondern werden von der spezifischen Gestaltungsaufgabe und den zum Einsatz kommenden Grundprinzipien des systematischen Denkens und Handelns determiniert. Folglich sind die Methoden und Verfahren im GSE-Gestaltungsmodul iterativ miteinander zu verknüpfen, um die Grundprinzipien des systematischen Denkens und Handelns, im Speziellen das Grundprinzip der kritischen Reflexion, aber auch das Grundprinzip vom Groben zum Detail und das Grundprinzip der Neutralität zu beachten. Die Kombination von Gestaltungsmethoden mit dem GSE-Denkmodell ist beliebig erweiterbar und je Branche bzw. Einsatzfall zu modifizieren. Dies beweisen verschiedene Untersuchungen von OTT, RIEKHOF und MÜLLER (vgl. Schlund 2011). Diese Quellen belegen, dass die Ergebnisse dieser Methoden systematisch das Systemmodell vervollständigen, sofern es gelingt, sie wieder im Denkmodell des GSE-Ansatzes abzulegen. Im Rahmen des GSE-Gestaltungsmoduls muss nicht das gesamte Systemmodell, sondern nur die entsprechenden Teile verändert bzw. präzisiert werden. Diese Möglichkeit verdeutlicht das in Abschn. 4.2 dargestellte Beispiel der Sitzlehne, wo das Teilsystem „Sitzlehneneinstellung“ gestaltet wurde. Der GSE-Ansatz sieht zwingend vor, dass neben den Veränderungen eines Teilsystems auch erforderliche Anpassungen des Gesamtsystems zu untersuchen und umzusetzen sind. Das GSE-Denkmodell ermöglicht eine schnelle Prüfung und Selektion der Verbindung des Teilsystems mit dem Gesamtsystem. Folglich steht das Gestaltungsmodul in ständiger Interaktion mit dem Denkmodell des GSE-Ansatzes.

Wie dieser Gestaltungsprozess systematisch geplant, durchgeführt und umgesetzt werden kann, soll im nächsten Abschnitt erläutert werden.

4.4 Das GSE-Projektmanagementmodul

In Abschn. 2.3 wurde dargestellt, dass im Rahmen des Vorgehenskonzeptes des GSE-Ansatzes das GSE-Analyse-, das GSE-Zielbildungs- und das GSE-Gestaltungsmodul über das GSE-Projektmanagementmodul in ihrer zeitlich logischen Folge zu planen, zu realisieren und zu kontrollieren sind. In den Abschn. 4.1, 4.2 und 4.3 erfolgte die Beschreibung der universellen standardisierten Module des GSE-Vorgehenskonzeptes in ihrem grundsätzlichen Zusammenwirken mit ausgewählten Methoden und Verfahren. Wie diese Module jedoch in ihrer zeitlich logischen Folge mithilfe des GSE-Projektmanagementmoduls und dessen auswählbaren Methoden und Verfahren zu kombinieren sind, soll in diesem Kapitel vom Grundsatz her skizziert werden. Dabei ist es Aufgabe des GSE-Projektmanagementmoduls, wie in Abb. 4.35 dargestellt, die Interaktionen zwischen dem GSE-Denkmodell und den standardisierten, universellen Modulen des GSE-Vorgehenskonzeptes problemlösungsspezifisch zu planen und erfolgreich umzusetzen. So umfasst dieses Modul alle Aufgabenfelder des Projektmanagements, so wie es HABERFELLNER beschreibt.

Er sieht das Projektmanagement als Summe aller organisatorischen und dispositiven Maßnahmen an, die zur Planung, Führung, Überwachung und Steuerung von Problemlösungsprojekten in inhaltlicher, zeitlicher und kostenmäßiger Sicht (vgl. Haberfellner et al. 2012, S. 165) genutzt werden. Darin muss der Umgang mit den Ressourcen eingeschlossen sein.

Somit ist das Projektmanagement ein sehr wichtiger Bestandteil des GSE-Vorgehenskonzeptes, der einen effizienten Problemlösungsprozess sichern muss. Die Phasen des Projektmanagements, d. h. die Planungs-, die Durchführungs- und die Kontrollphase sind nicht additiv nacheinander geschaltet. Sie überlagern sich, wie Abb. 4.36 grob skizziert, über die Zeit (vgl. auch Lehner 2001; Eversheim et al. 1999). Die Projektdefinitionsphase, die das klassische Projektmanagement vorsieht, (vgl. auch Abschn. 2.3) ist nicht erforderlich, weil über das GSE-Denkmodell das Projekt definiert und mithilfe des GSE-Zielbildungsmodules die Projektziele fixiert werden.

In jede einzelne Phase des Projektmanagements der Abb. 4.37 müssen folglich zeitlich differenziert Informationen aus dem GSE-Denkmodell sowie dem GSE-Analyse-(roter Pfeil), dem GSE-Zielbildungs-(grüner Pfeil) und GSE-Gestaltungsmodul (gelber Pfeil) eingehen. Gleiches gilt in umgekehrter Richtung, d. h. die Informationen aus den Phasen des Projektmanagements wirken sich planend, steuernd und kontrollierend auf die problemspezifische, GSE-Modul-kombinierende Anwendung der Methoden und Verfahren aus (vgl. Abb. 4.37).

Über das Projektmanagement ist also, wie Abb. 4.37 darstellt, die Interaktion zwischen den einzelnen Modulen des GSE-Vorgehenskonzeptes, also dem GSE-Analyse-, den GSE-Zielbildungs- und dem GSE-Gestaltungsmodul sowie zwischen dem Denkmodell des GSE- Konzeptes in ihrer zeitlich logischen Folge zu planen, umzusetzen und zu kontrollieren. Dabei sind die Grundprinzipien des systematischen Denken und Handelns (vgl. auch Abschn. 1.3) einzubinden. Das Grundprinzip vom Groben zum Detail, das HABERFELLNER favorisiert, ermöglicht es z. B., den Überblick über größere Projekte zu behalten (vgl. Haberfellner et al. 2012). Das gilt auch für die Umsetzung des Grundprinzips der minimalen Modelle. Letzteres kann z. B. mit der Dokumentation der Projektergebnisse gekoppelt werden. Dabei soll, wie bereits erwähnt, als minimale Dokumentation die Veränderung des GSE-Denkmodells im Projektverlauf fixiert werden. Grundsätzlich sind die in Abschn. 1.3 dargestellten Grundprinzipien des systematischen Denkens und Handelns von der konkreten Problemlösung abhängig, die mithilfe des GSE-Ansatzes gelöst werden soll (vgl. auch Kap. 5). Diese sind problemlösungsorientiert im Rahmen der Planungsphase auszuwählen und bei der Projektdurchführung und -kontrolle zwingend zu beachten.

Nachfolgend werden zunächst die einzelnen Phasen des GSE-Projektmanagementmoduls sowie möglich einsetzbare Methoden und Verfahren kurz vorgestellt. Anschließend erfolgt die Beschreibung von Verfahren, die über alle Phasen des GSE-Projektmanagementmoduls anzuwenden sind, da in jeder dieser Phasen sowie phasenübergreifend interdisziplinäre Teams über Informations- und Kommunikationsverfahren zu steuern und zu lenken sind.

Die Phasen des Projektmanagements im GSE-Vorgehenskonzept und mögliche einsetzbare Methoden und Verfahren

In der Projektplanungsphase wird entschieden, welche Module des GSE-Vorgehenskonzeptes wie, wann, mit welchen Methoden und Verfahren sowie welchen Kapazitäten zum Einsatz kommen. Es wird auch festgelegt, wie und wann das GSE-Denkmodul genutzt bzw. präzisiert wird sowie welche Prinzipien des systematischen Denkens und Handelns angewendet werden sollen (vgl. Abb. 4.38).

Als Ergebnis der Planungsphase kann ein Balkenplan entstehen, wie dies Abb. 4.39 im Grundsatz zeigt.

Die GSE-Module wurden in dieser Abbildung nur mit einem Grundprinzip des systematischen Denkens und Handels – dem Grundprinzip des diskursiven Vorgehens – gekoppelt. Es kommt nur eine Planungsmethode, nämlich der Balkenplan, zum Einsatz. Andere Planungsmethoden sind die Netzplan- oder Listentechnik. Diese Methoden werden der Terminplanung als einer speziellen Planungsart, wie Abb. 4.40 darstellt, zugeordnet.

Bei der Planung von GSE-Projekten können neben der Terminplanung prinzipiell folgende Planungsarten zur Anwendung kommen:

der Projektstrukturplan,
die Aufwandsabschätzung,
die Einsatzmittelplanung,
die Personalplanung und
die Kostenplanung.

Der Einsatz der Planungsarten ist abhängig von der Größe des GSE-Projektes. Jede Planungsart bedient sich spezifischer Methoden und Verfahren, wie beispielhaft an der Terminplanung dargestellt (vgl. auch Haberfellner et al. 2012).

Nachdem die Projektplanung abgeschlossen wurde, sollte die Projektdurchführung beginnen. Häufig erfolgt aber eine gleitende Projektierung von Projekten, d. h. Projektplanung und Projektdurchführung werden sequentiell durchgeführt.

Ziel der Projektdurchführung ist die ständige Suche nach dem bestmöglichen Weg zur Umsetzung des Projektplanes im Rahmen des angedachten GSE-Projektes (vgl. Abb. 4.41).

Zur Projektdurchführung gehört die Projektdokumentation. Grundsätzlich ist die Projektdurchführung mit dem Projektcontrolling permanent verbunden. Bei der Umsetzung des Problemlösungsprojektes ist ständig über einen Soll-Ist-Vergleich zu prüfen, inwieweit die Projektziele tatsächlich erreicht werden und inwieweit der Projektplan eingehalten wird bzw. dieser zu präzisieren ist.

Folgende Methoden und Verfahren unterstützen bei der Projektdurchführung:

Projektübersicht,
Kick-Off Meeting,
Projektbesprechung,
Projektstatusberichte,
Projektreview,
Testberichte,
Befragung,
Risikobeurteilung und
Öffentlichkeitsarbeit.

Projektbesprechungen, Statusberichte etc. sind mit Daten und Fakten zu unterstützen. Dazu muss der konkrete Projektverlauf, d. h. der Stand der Umsetzung der geplanten, zeitlich und logisch gekoppelten GSE-Module, geprüft werden. Hilfreich hierfür sind folgende Methoden und Verfahren:

Interview,
Fragebogen,
Dauerbeobachtung,
Selbstaufschreibung,
Fremdaufnahme sowie
Multimomentaufnahme.

So kann z. B. über die tägliche Selbstaufschreibung nachvollzogen werden, wie ein Projekt, welches mithilfe des GSE-Ansatzes umgesetzt werden soll, geplant, durchgeführt und realisiert wurde. Dabei können ebenfalls Ideen zur Verbesserung des Ablaufes, aber auch Probleme skizziert werden, die z. B. beim Aufbau oder der Aktualisierung des GSE-Denkmodells entstanden. Die Abb. 4.42 skizziert noch einmal grundsätzlich die enge Verzahnung von Projektdurchführung und Projektcontrolling.

Die Projektkontrolle ist ein permanenter Prozess, der sich über alle Projektphasen erstreckt (vgl. Abb. 4.43). Sie dient, wie bereits hervorgehoben, der Überwachung der Projektziele und des Projektplanes. Die Größe des GSE-Projekts bestimmt die einzusetzenden Methoden und Verfahren der Projektkontrolle.

Die Projektkontrolle ist quantitativ und qualitativ nachvollziehbar zu gestalten. Aus diesem Grund sind folgende Dinge Voraussetzung für eine effiziente Projektkontrolle:

Klar definierte Ziele, die schriftlich fixiert, nachvollziehbar, messbar, widerspruchsfrei, vollständig realisierbar, allen Beteiligten bekannt und akzeptiert sind. Das muss durch das GSE-Zielbildungsmodul und das GSE-Denkmodell garantiert werden.
Ein gut strukturierter Projektplan mit festgelegten Projekt-Kontrollpunkten und eine lückenlose Projektdokumentation.

Sind diese Bedingungen gegeben, kann eine Projektkontrolle erfolgreich durchgeführt werden.

Methoden und Verfahren, die die Projektkontrolle unterstützen sind:

die Projektbesprechung,
die Projektbegehung,
die Befragung,
das Projektaudit und
das Projektreview.

Die Projektkontrolle im Rahmen des GSE-Ansatzes kann dann sehr erfolgreich sein, wenn je Projektphase festgelegt wird, mit welchen Methoden und Verfahren problemspezifisch die Aufgabe gelöst werden soll. Dabei sind an den fixierten Key-Points die Systemveränderungen über das GSE-Denkmodell zu dokumentieren. Folglich kann am Ende der Projektlaufzeit genau nachvollzogen werden, warum und weshalb das GSE-Denkmodell des spezifischen Systems verändert und genau diese Lösung favorisiert und umgesetzt wurde. Dieses abstrakte Vorgehen soll im Abschn. 4.5 an einigen ausgewählten Beispielen praktisch veranschaulicht werden.

Doch bevor dies geschieht, soll noch auf Methoden und Verfahren eingegangen werden, die phasenübergreifend, d. h. über die Phasen der Projektplanung, -durchführung und –kontrolle, eingesetzt werden können.

Phasenübergreifend einsetzbare Methoden und Verfahren des Projektmanagements im GSE-Vorgehenskonzept

Grundsätzlich sind in allen Phasen des Projektmanagements Informationen auszutauschen und zu kommunizieren, es gilt aber auch zu entscheiden. Diese Methoden und Verfahren können phasenübergreifend im GSE-Projektmanagementmodul eingesetzt werden, wie Abb. 4.44 darstellt.

In allen Projektphasen ist inner- und außerhalb des Projektteams zu kommunizieren (vgl. Abb. 4.45 und 4.46).

Die in Abb. 4.46 zusammengefassten Methoden und Verfahren müssen sichern, dass die Kommunikationsergebnisse der verschiedensten Gruppen, die an dem GSE-Projekt arbeiten, zusammenpassen.

Die Erfahrung aus den Projekten KitVes und PromeSys sowie Teilprojekt B3 im SFB 696 zeigen, dass es besonders hilfreich ist, wenn diese Kommunikationstechniken mit dem GSE-Denkmodell gekoppelt werden. Das bedeutet, wenn es zu Veränderungen kommt, ist im Ergebnis der Videokonferenz z. B. zu fixieren, welche Relationen zwischen den Komponenten oder den Funktionen im Detail geändert werden sollen (Abb. 4.47).

In Problemlösungsprojekten sind immer Entscheidungen zu treffen. Als dafür geeignete Methoden werden empfohlen (Kuster et al. 2011):

der morphologische Kasten,
die Bionik,
das Pro und Contra Spiel,
die Delphi-Methode,
die ABC-Analyse,
der Entscheidungsbaum sowie
die Portfolio-Methode.

Wenn es gelingt, das GSE-Denkmodell weiter zu vervollkommnen (vgl. auch Abschn. 3.4), können Teile der Entscheidungsmethoden und -verfahren mit diesem gekoppelt werden. Das setzt voraus, dass das GSE-Denkmodell nicht nur die Relationen zwischen den Systemsichten, d. h. der Anforderungs-, der Komponenten-, der Funktions- und der Prozesssicht sowie innerhalb der Sichten darstellt, sondern dass diese Relationen über Merkmalswerte bewertet bzw. attribuiert werden. Da dies gegenwärtig noch nicht der Fall ist, müssen die Projekte, die mithilfe des GSE-Ansatzes umgesetzt und mit den oben genannten Entscheidungsmethoden und -verfahren gekoppelt werden zu dokumentieren.

Um die Rückverfolgbarkeit und Transparenz zu gewährleisten, sind die Entscheidungsergebnisse im GSE-Denkmodell fest zu halten.

GSE-Denkmodell und GSE-Vorgehenskonzept gleichen sich bisher noch nicht automatisch ab. Im Verlauf der Projektdurchführung und -kontrolle müssen folglich die Ergebnisse des Vorgehens durch das Team immer wieder in das GSE-Denkmodell eingepflegt und je Projektphase dokumentarisch festgehalten werden. Die Projektdokumentation umfasst somit die Sichten des GSE-Denkmodells an unterschiedlichen Zeitpunkten des Projektfortschrittes.

Für die projektphasenübergreifende Steuerung von Informationen können in GSE-Projekten die in Abb. 4.48 im Überblick dargestellten Softwarelösungen eingesetzt werden.

Zusammenfassend ist zu betonen, dass die Methoden und Verfahren, die allgemeingültig im Projektmanagement Anwendung finden, auch im Rahmen des GSE-Ansatzes zum Einsatz kommen können. Dabei wurde deutlich, dass im Projektverlauf die Projektergebnisse immer wieder im Systemmodell, d. h. im GSE-Denkmodell, zu fixieren sind. Somit entstehen zeitdeterminierte Dokumente des GSE-Denkmodells während der Realisierung des GSE-Vorgehenskonzeptes. Wie dies im Detail realisiert werden kann, soll im nachfolgenden Abschn. 4.5 beispielhaft skizziert werden.

4.5 Die Interaktion der Module des GSE-Vorgehenskonzeptes und die Konsequenzen für die Systemmodellierung

In den Abschn. 4.1, 4.2, 4.3 und 4.4 wurden die einzelnen Module des GSE-Vorgehenskonzeptes vorgestellt. Im Ansatz konnten Wechselwirkungen zwischen dem GSE-Analyse-, dem GSE-Zielbildungs-, dem GSE-Gestaltungs- und dem GSE-Projektmanagementmodul skizziert werden. Die nachfolgenden zwei Beispiele sollen verdeutlichen, wie alle GSE-Module des Vorgehenskonzeptes miteinander, fallspezifisch modifiziert, interagieren können.

In Abschn. 3.3 konnte beispielhaft nachgewiesen werden, dass das GSE-Denkmodell universell nutzbar ist und modular aufgebaut konnte.

Dies erfolgte für:

den Antrieb,
die mechatronischen Systeme und
das KitVes-System.

Der gleiche Nachweis fehlt noch für das GSE-Vorgehenskonzept. Er soll in diesem Abschnitt beispielhaft für:

die risikoarme Entwicklung des KitVes-System und
den Prozess der Felddaten-Rückführung in den Konstruktions- und Entwicklungsprozess anhand von mechatronischen Systemen erfolgen.

Die Interaktion von GSE-Denkmodell und GSE-Vorgehenskonzept wird dabei in diesem Kapitel nur grob beschrieben, um die Auswirkungen des Vorgehens auf das Systemmodell sowie mögliche Verbesserungen des GSE-Ansatzes zu veranschaulichen. Die Synergien zwischen beiden sollen im Detail Schwerpunkt des Kap. 5 sein.

1. Beispiel: Darstellung der interagierenden Module des GSE-Vorgehenskonzeptes für das KitVes-System

Wie bereits in Abschn. 3.3 skizziert, war es Aufgabe des Projektes „KitVes“, ein neues Produktsystem für die Nutzung von Windenergie zu entwickeln sowie die dabei entstehenden Risiken zu bewerten und beherrschbar zu gestalten.^{Footnote 1} Als Lösungsvariante diente ein KitVes-System, welches auf einem Schiff zum Einsatz kommen sollte. Hierfür wurden Höhenwinde in 500-2000 Metern genutzt, indem die Windenergie durch das KitVes-System in elektrische Energie umgewandelt wird. Das Grundprinzip ist in Abb. 4.49 dargestellt.

Ziel des Projektes war es, das KitVes-System für die Energiegewinnung auf Schiffen so risikoarm zu gestalten, dass dabei alle Phasen des Produktlebenszyklus‘ mit Beachtung finden. So entstand zu Beginn des Projektes die Idee, den GSE-Ansatz zu nutzen, um einerseits für das transdisziplinäre Entwicklungsteam ein gemeinsames GSE-Denkmodell (vgl. auch Abschn. 3.3) zu schaffen und andererseits über die Phasen des Produktlebenszyklus die Anforderungen, welche an das KitVes-System gestellt werden, zu erfassen, zu systematisieren und über entsprechende Quality Gates, wie es Abb. 4.50 veranschaulicht ist, abzubilden.

An den Quality Gates sollten die neu entstandenen, veränderten oder weggefallenen Anforderungen in das GSE-Denkmodell des KitVes-Systems eingebunden sowie die Wechselwirkung zwischen den Komponenten, Funktionen und Prozessen präzisiert werden. Es stellte sich jedoch bald heraus, dass allein das KitVes-System aus über 200 Komponenten bestand und die gegenwärtige Rechnerunterstützung bei der Erstellung des GSE-Denkmodells an Grenzen stieß. Aus diesem Grund wurde der Untersuchungsgegenstand eingegrenzt. Dabei half die Anwendung von Grundprinzipien des systematischen Denkens und Handelns, wie z. B. das Grundprinzip vom Groben zum Detail sowie das Grundprinzip der minimalen Modelle. So fokussierte sich das internationale Team auf den Nachweis, dass der Drachen tatsächlich Windenergie in elektrische Energie umsetzen kann und dass dies zuverlässig bzw. risikoarm erfolgt. Im Ergebnis der Zielpräzisierung (erste Iterationsschleife im GSE-Vorgehenskonzept) wurde der Untersuchungsgegenstand eingegrenzt und das betrachtete Teilsystem skizziert (vgl. Abb. 4.51).

Nachdem das Ziel von der zuverlässigen Gestaltung des KitVes-Systems auf die Risikobewertung der Kite-Steering-Komponenten eingegrenzt worden ist, war es nun Aufgabe des Projektteams zielgerichtete Methoden und Verfahren auszuwählen, die geeignet sind für die Risikoanalyse, -bewertung und –minimierung. Die auszuwählenden Methoden sollten sich mit dem GSE-Denkmodell koppeln lassen, welches mit den DeCoDe-Tools erstellt wurde. Dieser Nachweis der Kopplung erfolgte durch die Verbindung der MTTF mit dem GSE-Denkmodell für das KitVes-System im Abschn. 4.3. Eine weitere Forderung war, dass die auszuwählenden Methoden und Verfahren im Wesentlichen dem internationalen Team bekannt sein sollten, d. h. dass alle Teammitglieder in der Lage sein sollten, ohne großen Schulungsaufwand die Risikoanalyse, -bewertung und -gestaltung der Kite-Steering Unit durchzuführen zu können. Dementsprechend wurden die in Abb. 4.52 dargestellten Methoden und Verfahren zur Risikoanalyse und -bewertung ausgewählt. Sie sind dem GSE-Analysenmodul zuordenbar.

Grundsätzlich bildet das GSE-Denkmodell Input für die jeweilige Methode. Sein Input wiederum sind die Methodenergebnisse (vgl. Abb. 4.52).

In einem nächsten Schritt musste eine logische Folge der Kombinationen der Methoden und Verfahren zur Risikoanalyse und Bewertung sowie zur Risikominimierung als Grundüberlegung entwickelt werden. Dies ist Teil der Projektplanung. Die Abb. 4.53 stellt das Grundprinzip der logischen Kombination von Methoden und Verfahren in der Risikoanalyse-Bewertung und Gestaltung für die Kite-Steering Unit in Kopplung mit dem GSE-Denkmodell dar.

In einem Folgeschritt plante das Projektteam die zeitlich logische Folge der Kombination der einzelnen Schritte. Dies ist ebenfalls Teil der Projektplanung.

Abbildung 4.54 zeigt, wie mithilfe einfacher Methoden der Projektplanung die zeitlich logische Folge der Kopplung von GES-Analysen-, GSE-Zielbildungs- und GSE-Gestaltungsmodulen erfolgen kann. In mehreren Workshops wurden dann, wie bereits in Abschn. 3.3 beschrieben, die einzelnen Sichten des GSE-Denkmodells für das KitVes-System generiert. Aus diesem Grund wird es in diesem Abschnitt ausgeklammert, weil dieses GSE-Denkmodell des KitVes-Systems (vgl. auch Abschn. 3.3), wie in Abb. 4.55 dargestellt, Input ist für die Anwendung der Methoden zur Risikoanalyse und Bewertung der Kite-Steering Unit.

In Auswertung dessen wurde die Kite-Steering Unit so gestaltet, dass die Risiken minimiert werden konnten. Dies wiederum hatte Veränderungen des GSE-Denkmodells zur Folge. Jede Gestaltungslösung verändert das Abbild der ursprünglichen Kite-Steering Unit. Über die Anwendung der Lebenszykluskosten-Analyse konnten nun die einzelnen Gestaltungslösungen vergleichend betrachtet und bewertet sowie dem Entwickler-Team Entscheidungshilfen für die weitere Vervollkommnung des KitVes-Systems für Schiffe zur Verfügung gestellt werden.

Das Projektentwicklungsteam, welches sich aus Vertretern unterschiedlichster Länder der europäischen Union zusammensetzte, hatte durch die gemeinsame Anwendung des GSE-Ansatzes die Möglichkeit, zielgerechte Lösungen zu entwickeln. Diese basierten auf einem vereinheitlichten und standardisierten Systemmodell. Durch diesen sicher sehr aufwändigen Modellierungsprozess konnte sichergestellt werden, dass die Elemente des KitVes-Systems eindeutig bezeichnet, beschrieben und von den Teammitgliedern der unterschiedlichsten Wissenschaftsdisziplinen auf gleiche Weise verstanden und angewendet wurden. Im Verlaufe der Anwendung der Methoden zur Risikoanalyse und -bewertung und -gestaltung wurde deutlich, dass sich der Aufwand bei der Datenerhebung minimieren lässt. Einmal erfasste Daten können in dem Systemabbild hinterlegt werden und sofort für die weitere Verwendung zur Verfügung stehen. Das setzt jedoch voraus, dass einerseits die Systemabbilder über die DeCoDe-Tools das GSE-Denkmodell immer wieder präzisiert und andererseits je Projektphase zu bestimmten Zeitpunkten archiviert werden. Über den Vergleich der Systemmodelle je Zeitpunkt, was gegenwärtig nur manuell und noch nicht rechnerunterstützt möglich ist, kann nachvollziehbar der Nachweis der Risikominimierung erbracht werden. Die Systemveränderung ist ebenfalls verfolgbar, d. h. die Frage, warum und weshalb die Kite-Steering Unit verändert werden musste. Das ist sehr schnell möglich und für nicht beteiligte Personen über diesen Ansatz gut verständlich aufbereitet, wie die Workshops mit der EU-Kommission belegen.

Zusammenfassend stellt das Beispiel des KitVes-Systems anschaulich dar, wie die einzelnen Module des GSE-Vorgehenskonzeptes interagieren und projektspezifisch mithilfe des GSE-Projektmanagementmoduls geplant, durchgeführt und umgesetzt werden können. So entsteht über die Anwendung der Module des GSE-Vorgehenskonzepts ein spezifisches Vorgehen, welches genau angepasst ist an die spezielle Problemlösung, hier die Gestaltung eines risikoarmen KitVes-Systems.

Selbstverständlich war bei der Lösung der Aufgabe eine Ressourcen- und Kapazitätsplanung mit eingebunden. Auf diese wurde bei der Darstellung des Sachverhaltes in Abb. 4.54 verzichtet, um das Wesentliche zu skizzieren, d. h. die problemspezifische Kombination von GSE-Zielbildungs-, GSE-Analyse und GSE-Gestaltungsmodulen. Abbildung 4.49 und 4.51 zeigen, dass durch die Anwendung des Grundprinzips vom Groben zum Detail bzw. des Grundprinzips der Mehrfachverwendbarkeit zwei Zielbildungsphasen kurz nacheinander geschaltet wurden. Da die risikominimierende Gestaltung des KitVes-Systems über den Produktlebenszyklus den Projektrahmen gesprengt hätte, wurde somit eine Zielpräzisierung vorgenommen (2. Phase). Es konnte eingeschätzt werden im Rahmen des Workshops, dass die Kite-Steering Unit das Teilsystem ist, welches mit dem höchsten Risiko behaftet ist. Aus diesem Grund wurde genau für diese Unit die Risikominimierung als Ziel formuliert. Folglich konnten in den weiteren Schritten im Laufe der Projektlaufzeit von zwei Jahren die Risikoanalyse, die -Bewertung und die Veränderung – also die risikoarme Gestaltung der Kite-Steering Unit – erfolgen. Das Beispiel bestätigt, dass die Anwendung der standardisierten Module im GSE-Vorgehenskonzept sehr hilfreich ist, um Projektteams, die arbeitsteilig in großen räumlichen Entfernungen an einer Problemlösung arbeiten, zielorientiert zum Ergebnis zu führen. Das Ergebnis zeigt auch, dass spezifische Methoden und Verfahren aus dem GSE-Analyse-, GSE-Zielbildungs- und GSE-Gestaltungsmodulen ausgewählt und mit dem GSE-Denkmodell gekoppelt werden können. Durch die Verbindung mit dem standardisierten Systemmodell wird der Informationsinput und -output je Methode ebenfalls standardisiert.

Das wiederum ermöglicht eine schnelle Weiterverwertung der entstandenen Daten, aber auch ihre Rückverfolgbarkeit ist gegeben. Obwohl die Interaktion von GSE-Denkmodell und GSE-Vorgehenskonzept an diesen Beispielen nur skizziert wurde, wird deutlich, dass es zwingend erforderlich ist, ein rechnerunterstütztes GSE-Denkmodell zu entwickeln. Durch eine potentielle Rechnerunterstützung des GSE-Denkmodells können standardisierte Daten für die Verarbeitung im GSE-Vorgehenskonzept bereitgestellt, aktualisiert und überdies verschiedene Zeitpunkte ihrer Präzisierung vergleichbar gestaltet werden. Nur so ist eine durchgängige Rückverfolgbarkeit und Transparenz zu gewährleisten.

2. Beispiel: Nutzung des Vorgehenskonzeptes des GSE-Ansatzes für die Felddatenrückführung von mechatronischen Systemen in den Konstruktions- und Entwicklungsprozess

Felddaten, das sind sämtliche Daten und Informationen, die unmittelbar nach der Phase der Generierung der Produktidee entstehen, wie Abb. 4.56 zeigt.

Aus ihnen können Aussagen (Merkmale und Merkmalswerte) abgeleitet werden, die Rückschlüsse gestatten, inwieweit das entwickelte Produktsystem die Anforderungen erfüllt. Die effektive Nutzung von Felddaten setzt ihre strukturierte Erfassung und Klassifizierung voraus. Tatsache ist jedoch, dass je nach Einsatzzweck die Daten bereits unterschiedlich strukturiert vorliegen. Das führt zu einer ungenauen Weiterverarbeitung bzw. unvollständigen Erfassung von Felddaten (vgl. Delonga 2007). Hinzu kommt eine Vielzahl unterschiedlicher Klassifikationsmerkmale. Anhand der Strukturierung von Fehlern, als Beispiel der Untermenge Felddaten, zeigt dies nachfolgende Tab. 4.2.

Tab. 4.2 Fehler, deren Bedeutung und Ursachen (Winzer und Künne 2009, S. 546)

Full size table

Tabelle 4.2 verdeutlicht, dass die Fehlerursachen nicht einheitlich standardisiert sind. Eine Zuordnung von Fehlern zu den Anforderungen, zu den Komponenten, zu den Funktionen und Prozessen findet nicht statt. Dies ist jedoch eine notwendige Bedingung, um Daten bzw. Informationen – Fehler sind solche – in den frühen Phasen der Produktentstehung wieder zurückzuführen. Edler (Edler 2001, S. 34) macht für die unvollständige Nutzung von Felddaten drei Arten von Defiziten verantwortlich, d. h.:

methodische Defizite,
systematische Defizite und
Defizite der Integration.

Zu den methodischen Defiziten gehört in erster Linie die fehlende ganzheitliche Betrachtung der Felddatennutzung. Es beginnt bei der Erfassung, der Strukturierung sowie der Klassifizierung der Felddaten und gipfelt in ihrer gezielten Auswertung in den zugehörigen Phasen des Produktlebenszyklus‘. So herrscht oft Unkenntnis darüber, für welche Zwecke die erhobenen Daten eingesetzt werden können. Gerade die Nutzung von Felddaten durch die Methoden der Produktentwicklung erfordert jedoch eine eindeutige Information bezüglich des erhobenen Sachverhaltes (vgl. Braunholz 2006). So stehen zum heutigen Zeitpunkt insbesondere bei mechatronischen Systemen lediglich lückenhafte Fehlerauswertesysteme zur Verfügung (vgl. PromeSys 2006). Aufgrund des Zeitversatzes zwischen Erhebung der Felddaten und ihrer Nutzbarmachung innerhalb der Produktentwicklung werden häufig Informationen nicht eindeutig abgelegt und sind so schwer dem Produktmodell zuordenbar. Ansätze wie sogenannte Fehlerwörterbücher (vgl. Ebener 1996, S. 92) bzw. Mapping Tables (vgl. Edler 2001, S. 62) für Felddatenerfassung, adressieren zwar dieses Problem, berücksichtigen jedoch nur Teilaspekte. Systematische Defizite beziehen sich auf das Fehlen durchgängiger Informations- und Ablagesysteme, welche anhand vereinheitlichter Vorgaben die Erfassung und Nutzung der Felddaten auf einer gemeinsamen Datenbasis ermöglichen. Die Mängel der Integration beziehen sich auf die Schnittstellen sowohl zwischen Felddaten und den Methoden ihrer Nutzung, als auch zwischen den einzelnen Methoden selbst. Am Beispiel „Fehler“ zeigt Abb. 4.57 auszugsweise verschiedene Betrachtungsfelder ausgewählter Methoden und Felddaten.

Keine der dargestellten Methoden, d. h. FTA, FMEA und ETA des präventiven Qualitätsmanagements, erlaubt eine durchgängige Betrachtung von den Ursachen bis hin zu den Auswirkungen der Fehler. Der Fehlerbaum – Fault Tree Analysis – FTA stellt die Fehlerursache und deren erforderliche Kombination zur Fehlerentstehung einschließlich der zugrundeliegenden Wahrscheinlichkeiten ihres Auftretens dar. Die Ereignisablaufanalyse – Event Tree Analysis – ETA, untersucht ein mögliches Ereignis eines Systems sowie seine potentiellen Auswirkungen auf das Gesamtsystem (DIN 25419 1985). Die Fehlzustandsart- und Auswirkungsanalyse – FMEA – betrachtet potentielle Fehler mitsamt ihrer Ursache und möglicher Auswirkungen, jedoch nicht die Ursachen und Auswirkungsketten. Die gegenwärtige Praxis des Erfassens von Felddaten berücksichtigt nicht ausreichend die Beziehung zwischen den verschiedenen Ursachen und Auswirkungen. Somit bleiben bei einer isolierten Anwendung der genannten Methode jeweils Teilaspekte unberücksichtigt.

Nachfolgendes Beispiel skizziert das theoretisch geschilderte Problem aus praktischer Sicht.

Die Falschsortierung eines Förderguts in einer logistischen Anlage kann folgende Ursachen haben:

Ausfall des Sensors durch Lockerung der Anschlüsse,
Positionierungsprobleme des Fördergutes oder
Blockierung des Lichtstrahls.

Im Folgeschritt sind im Detail zu prüfen, welche Anforderungen:

an die Anschlüsse,
an die Positionierung und
an den Lichtstrahl selbst gestellt wurden.

In diesem speziellen Fall zeigte sich, dass das Fördergut nicht in einem bestimmten Winkel auf dem Sorter gefördert wurde, d. h. das Fördergut lag außerhalb der vorgesehenen Merkmalsgrenzen. Somit wurde im Nutzungsprozess deutlich, dass das Fördergut nicht richtig positioniert war, es somit zur Blockierung des Lichtstrahles kam. Die Anforderung „fehlerfreies Sortieren“ steht in diesem Fall im Zusammenhang mit dem Lichtsensor (Komponente), der Funktion „Positionieren des Fördergutes“ und dem Prozess „Transportieren des Fördergutes“, welcher ein Teilprozess des Nutzungsprozesses ist. So entstand die Verbindung von Anforderung, Komponente, Funktion und Prozess. Dieser kann nur erstellt werden, wenn die Felddaten in einem kausalen Zusammenhang zum GSE-Denkmodell mithilfe der DeCoDe-Tools gebracht werden, wie Abb. 4.58 beweist.

Auf der Basis der Hypothese, d. h. dass alle Felddaten über das GSE-Denkmodell mit Anforderungen verknüpfbar sind, wurde für die Rückführung von Felddaten in den Konstruktion- und Entwicklungsprozess der folgende logische Ablauf konzipiert, der aus Abb. 4.59 hervorgeht.

Die Felddaten, welche z. B. mit dem Fehlermanagement, der QFD oder dem PLM erfasst wurden, können so den Anforderungen (rot), den Komponenten (blau) sowie den Funktionen und Prozessen (jeweils grau in der Abb. 4.59 dargestellt) zugeordnet werden und strukturiert in den Konstruktions- und Entwicklungsprozess einfließen. So sind in der Folge konstruktive Veränderungen, bzw. Anforderungspräzisierungen möglich. Der praktische Nachweis hierfür erfolgte zunächst für die Rückführung von Versuchsdaten in den Konstruktions- und Entwicklungsprozess. Der methodische Grundansatz des geplanten Vorgehens (vgl. Abb. 4.60) für ein Unternehmen der Automobilindustrie war die Basis für die konkrete Projektplanung.

Die im Rahmen des Versuches gewonnenen Messergebnisse wurden dem Produktmodell (GSE-Denkmodell) zugeordnet. Da einige Merkmalswerte des Versuches nicht den ursprünglichen Anforderungen entsprachen, mussten Ursachenanalysen mithilfe geeigneter Methoden – hier im Speziellen der FMEA – dies klären. Die Ergebnisse der Methode flossen wiederum in das Denkmodell ein und führten zu dessen Veränderung. Da das Denkmodell mithilfe des PromeSys-Portals abgebildet wurde, konnte durch diese Rechnerunterstützung das Denkmodell schnell aktualisiert werden. Abbildung 4.61 stellt das methodische Vorgehen in Kopplung mit der rechnerunterstützten Präzisierung des Denkmodells über das PromeSys-Portal im Grundsatz dar.

Das modifizierte GSE-Vorgehenskonzept zur Versuchsdatenrückführung in die frühen Phasen der Konstruktion und Entwicklung machte resümierend deutlich, dass die Messwerte genauso strukturierbar sind wie das Systemmodell, d. h. das GSE-Denkmodell. Im vorliegenden Fall wurde das GSE-Denkmodell mithilfe der DeCoDe-Tools erstellt. Somit erfolgte das Modellieren des Systems in der Anforderungs-, der Komponenten-, der Funktions- und der Prozesssicht. Messwerte bestehen immer aus Merkmalswerten in unterschiedlichster Ausprägung. Diese sind ebenfalls den Systemelementen bzw. deren Relation im GSE-Denkmodell zuzuordnen. Zurzeit hat das GSE-Denkmodell noch keine standardisierten Attribuierungen der Systemelemente und ihrer Relationen. Deshalb war es in diesem speziellen Fall erforderlich, über das Vorgehenskonzept Ideen für die Attribuierung des Systemmodells zu generieren, um eine Lösung herbeizuführen. Zukünftig müsste dies durch das GSE-Denkmodell vorgegeben und standardisiert sein. Das Beispiel der Versuchsdatenrückführung zeigt ebenfalls, dass die Module des GSE-Vorgehenskonzeptes in unterschiedlicher zeitlicher und logischer Folge miteinander kombiniert werden können. Abbildung 4.62 abstrahiert das skizzierte Vorgehen über einen Balkenplan (eine Methode, die in der Planung von Projekten Anwendung findet).

Der Vergleich dieser Vorgehensweise mit der der Risikominimierung des KitVes-Systems verdeutlicht, dass sich beide GSE-Vorgehenskonzepte in der Kombination der Module unterscheiden, jedoch die Module analog sind. Somit ist ein Vorgehen für eine Problemlösung mit universellen, standardisierten Modulen so planbar, dass eine individuelle Problemlösung zielgerichtet möglich wird. Diese beiden Beispiele zeigen des Weiteren, dass die standardisierten Module des GSE-Vorgehenskonzeptes problemlösungsspezifisch mit spezifischen Methoden und Verfahren ergänzt werden können. Sie verdeutlichen ebenfalls, dass im Rahmen des GSE-Vorgehenskonzeptes die Grundprinzipien des systematischen Denkens und Handelns nahtlos und problembezogen integrierbar sind. Sie helfen bei der systematischen Problemlösung und beim Erstellen eines gut strukturierten Projektplanes. Die Planung der Art und Weise der Kopplung der einzelnen Module des GSE-Vorgehenskonzeptes, ihrer Umsetzung und die Kontrolle ihrer Wirksamkeit kann mit den Methoden des Projektmanagements effizient umgesetzt werden. Auch das veranschaulichen der beiden Beispiele für das KitVes-System und der Versuchsdatenrückführung.

Im folgenden Kap. 5 sollen nun noch einmal detaillierter die Wechselwirkung zwischen dem GSE-Denkmodell und dem GSE-Vorgehenskonzept an Beispielen betrachtet werden. Der permanente Abgleich zwischen GSE-Denkmodell und GSE-Vorgehenskonzept – so die These – unterstützt die effizientere Anwendung des GSE-Ansatzes.

Wie dies im Detail möglich ist, soll nachfolgend in Kap. 5 betrachtet werden.

Notes

1.
www.Kitves.com

Literatur

Arlt G (1999) Systemansatz eines produkt- und ablauforientierten Qualitätsmanagements durch Integration der Systemtechnik. VDI-Verl. Düsseldorf
Google Scholar
Algedri J (1998) Integriertes Qualitätsmanagement-Konzept für die kontinuierliche Qualitätsverbesserung. Dissertation, Universität Kassel, Kassel: Institut für Arbeitswissenschaft
Google Scholar
Braunholz H (2006) Werkzeugentwicklung für informationsflussorientierte Prozessmodelle. Shaker Verlag GmbH, Aachen
Google Scholar
Brüggemann H, Bremer P (2012) Grundlagen Qualitätsmanagement. Von den Werkzeugen über Methoden zum TQM. Vieweg+Teubner, Wiesbaden
Google Scholar
BITKOM, Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.: Fehlerklassifikation für Software – Leitfaden. http://www.bitkom.org/de/themen_gremien/55109_50074.aspx. Zugegriffen: 26. Mai 2009
Bubb H, Schmidtke H (1993) Systemergonomie. In: Schmidtke, H. (Hrsg) Ergonomie, 3. Aufl. München, Wien, Hanser, S 305–458
Google Scholar
Dahms M (2010) Motivieren, delegieren, kritisieren: Die Erfolgsfaktoren der Führungskraft. Gabler, Wiesbaden
Book Google Scholar
Delonga M (2007) Zuverlässigkeitsmanagementsystem auf Basis von Felddaten. Dissertation, Universität Stuttgart, Stuttgart
Google Scholar
Deutsches Institut für Normung (1985) Begriffe der Annahmestichprobenprüfung. Berlin: Beuth (Begriffe der Qualitätssicherung und Statistik/DIN, 31)
Google Scholar
Deutsches Institut für Normung (1995) Software-Fehler und ihre Beurteilung durch Lieferanten und Kunden. Berlin: Beuth (Informationstechnik/Normenausschuß Informationsverarbeitungssysteme (NI) im DIN Deutsches Institut für Normung e.V., 66271)
Google Scholar
DIN 25419 (1985) Ereignisablaufanalyse
Google Scholar
DIN EN ISO 9000 Qualitätsmanagementsysteme – Grundlagen und Begriffe (12.2008); Beuth Verlag
Google Scholar
DIN EN 60812 (2006) Analysetechniken für die Funktionsfähigkeit von Systemen: Verfahren für die Fehlzustandsart- und -auswirkungsanalyse (FMEA); entsprechend IEC 60812:2006. Beuth-Verlag, Berlin
Google Scholar
Ebner C (1996) Ganzheitliches Verfügbarkeits- und Qualitätsmanagement unter Verwendung von Felddaten. Springer, Berlin
Google Scholar
Edler A (2001) Nutzung von Felddaten in der qualitätsgetriebenen Produktentwicklung und im Service. IPK, Berlin
Google Scholar
Ehrlenspiel K (2003) Integrierte Produktentwicklung. Denkabläufe, Methodeneinsatz, Zusammenarbeit, 2. Aufl. Hanser, München
Google Scholar
Ellouze W (2007) Entwicklung eines Modells für ein ganzheitliches Fehlermanagement – Ein prozessorientiertes Referenzmodell zum effizienten Fehlermanagement
Google Scholar
Eversheim W, Schuh G (Hrsg) (1999) Produktion und Management 4. Betrieb von Produktionssystemen. Springer, Berlin
Google Scholar
Eversheim W, Liestmann V, Winkelmann K (2006) Anwendungspotenziale ingenieurwissenschaftlicher Methoden für das Service Engineering. In: Bullinger H, Scheer A (Hrsg) Service Engineering. Springer, Berlin, S 423–442
Google Scholar
Fiedrich S (2010) KuWiss – Einsatz einer unternehmensspezifischen Methodik zur kontinuierlichen Messung der Kundenstimme im Baukastensystem. In: Winzer P (Hrsg) Entwicklungen im Wuppertaler Generic-Management-Konzept. Shaker, Aachen, S 19–32
Google Scholar
Fokus Online (2011) ToyotaRückruf für 400000 Hybrid-Autos. http://www.focus.de/auto/news/toyota-rueckruf-fuer-400-000-hybrid-autos_aid_478330.html. Zugegriffen: 26. Juli 2011
Franke H (2002) Variantenmanagement in der Einzel- und Kleinserienfertigung: Mit 33 Tabellen. Hanser, München
Google Scholar
Gausemeier J, Plass C, Wenzelmann C (Hrsg) (2009) Zukunftsorientierte Unternehmensgestaltung: Strategien, Geschäftsprozesse und IT-Systeme für die Produktion von morgen. Hanser, München, Wien
Google Scholar
Geiger IK, Pifko C (2009) Projektmanagement – Zertifizierung nach IPMA(3.0)-Ebenen D und C. Grundlagen und Kompetenzelemente, Methoden und Techniken mit zahlreichen Beispielen, 2. überarb. Aufl. Ausg. U0039. Compendio Bildungsmedien, Zürich
Google Scholar
Gogoll A (1996) Untersuchung der Einsatzmöglichkeiten industrieller Qualitätstechniken im Dienstleistungsbereich. IPK, Berlin
Google Scholar
Haberfellner R, Vössner S, Weck OL, de Fricke E (2012) Systems Engineering. Grundlagen und Anwendung. Orell Füssli, Zürich
Google Scholar
Hacker W (1986) Fehlhandlungen und Handlungsfehler. In: Ulich E (Hrsg) Arbeitspsychologie – Psychische Regulation von Arbeitstätigkeiten, Schriften zur Arbeitspsychologie, Nr. 41. Stuttgart: Huber, S 417–456
Google Scholar
Häder M (2009) Delphi-Befragungen: Ein Arbeitsbuch. VS, Verl. für Sozialwiss., Wiesbaden
Google Scholar
Hartmann C, Riekhof F, Winzer P (2011a) DeCoDe+X – Methodenverknüpfung und Systemmodellierung zur Unterstützung der Risikobeurteilung in den frühen Phasen der Produktentwicklung. Proceedings TTZ 2011 - 25.Tagung Technische Zuverlässigkeit. 11./12.05.2011, Leonberg
Google Scholar
Hartmann C, Riekhof F, Winzer P (2011b) Anforderungsgerechte Produktentwicklung über den gesamten Produktlebenszyklus. GQW- Tagung 2011. 01./02.03.2011, Bonn. In: Petersen B, Raab V (Hrsg) Qualitätskommunikation. Shaker, Aachen
Google Scholar
Hartmann C, Winzer P (2011) DeCoDe + X in KitVes. Using the demand compliant design in the development of a solution for harvesting high-altitude winds for energy generation on vessels. QMOD 2011
Google Scholar
Häuslein A (2004) Systemanalyse: Grundlagen, Techniken, Notierungen. VDE-Verl. Berlin
Google Scholar
Herrmann A (1996) Nachfrageorientierte Produktgestaltung. Ein Ansatz auf Basis der „means-end“-Theorie. Gabler, Wiesbaden
Google Scholar
IEEE 1044-1993 (1993) IEEE standard classification for software anomalies. New York
Google Scholar
Jensen F, Bowe S (2000) A 6-hats based team formation strategy: development and comparison with an MBTI based approach
Google Scholar
Künne B, Richard T (Hrsg) (2009) Sonderforschungsbereich 696. Forderungsgerechte Auslegung von intralogistischen Systemen – Logistics on Demand. Finanzierungsantrag (Fortsetzung) 07/2010 bis 06/2014. Dortmund
Google Scholar
Kuster J, Huber E, Lippmann R, Schmid A, Schneider E, Witschi U, Wüst R (2011) Handbuch Projektmanagement. Springer, Berlin
Book Google Scholar
Lehner JM (2001) Praxisorientiertes Projektmanagement. Grundlagenwissen an Fallbeispielen illustriert, 1. Aufl. Gabler, Wiesbaden
Google Scholar
Lex A, Winzer P, Sitte J (2004) Generic management design – a method of collecting knowledge systematically during the developing process. In: IMEKO (Hrsg) 8th international symposium on measurement and quality control in production
Google Scholar
Lindemann U (2005) Methodische Entwicklung technischer Produkte: Methoden flexibel und situationsgerecht anwenden. Springer, Berlin
Google Scholar
Lindemann U, Maurer M, Braun T (2009) Structural complexity management: an approach for the field of product design. Springer, Berlin
Book Google Scholar
Lolling A (2003) Analyse der menschlichen Zuverlässigkeit bei Kommissioniertätigkeiten. Aachen, Shaker
Google Scholar
Müller N, Schlund S, Winzer P (2010) Modellierung komplexer mechatronischer Systeme anhand des Demand Compliant Design. In: Jumar U, Schnieder E, Diedrich C (Hrsg) Entwurf komplexer Automatisierungssysteme. Ifak, Magdeburg
Google Scholar
Nicklas JP, Schlüter N, Winzer P (2011) Measurement of customer satisfaction in business networks. In: Jaca C (Hrsg) Proceedings QMOD conference on quality and service sciences 2011. Servicios de Publicationes Universidad de Navarra, Pamplona, S 1321–1336
Google Scholar
Orendi G (1993) Systemkonzept für die phasenneutrale Fehlerbehandlung als Voraussetzung für den Einsatz präventiver Qualitätssicherungsverfahren. Ein Beitrag zur Qualitätssicherung im Maschinen- und Anlagenbau; 93/11: Shake
Google Scholar
Ott S, Winzer P (2007) Cultivating knowledge methodically: improving analysis resolution with DeCoDe and FMEA. In: Proceedings of QMOD 2007
Google Scholar
Pahl G, Beitz W, Feldhusen J, Grote K (2005) Pahl/Beitz Konstruktionslehre: Grundlagen erfolgreicher Produktentwicklung Methoden und Anwendung. Springer, Berlin
Google Scholar
PromeSys (2006) BMBF- Forschungsprojekt: Prozesskettenorientiertes Regelkreismodell für ein nachhaltiges robustes Design mechatronischer Systeme. Online verfügbar unter http://www.promesys.org/projekt/problemstellung
Riekhof F (2010) Methodische Rückführung von Versuchsdaten in die Produktentwicklung und Validierung der Methodik am Beispiel eines Sitzlehneneinstellers. Masterthesis [unveröffentlicht], Fachgebiet für Produktsicherheit und Qualitätswesen, Bergische Universität Wuppertal
Google Scholar
Riekhof F, Winzer P (2010) Produktqualität und Q-Gates. MobileLifeCampus, Wolfsburg. http://www.sjf.tuke.sk/kbakp/Documents/DeCoDe-PLC-Methodenkopplung.pdf. Zugegriffen: 03. Mai 2013
Riekhof F (2011) Ansatz zur systematischen Versuchsdatenrückführung in die Produktentwicklung. In: Petra Winzer (Hrsg) Berichte zum Generic-Management. Shaker Verlag GmbH
Google Scholar
Riekhof F, Hartmann C, Winzer P (2011) DeCoDe+X Methodenverknüpfung und Systemmodellierung zur Unterstützung der Risikobeurteilung in den frühen Phasen der Produktentwicklung. 25.TTZ. Leonberg
Google Scholar
Rigby LV (1970) The nature of human error. In: Annual technical conference transactions of the ASQC. American society for quality control, Milwaukee
Google Scholar
Rinne H (1995) Statistische Methoden der Qualitätssicherung. Hanser Verlag, 3. Aufl. München
Google Scholar
Rosendahl J, Kulig S, Schlund S, Winzer P (2009) Methodenworkflow zur Entwicklung mechatronischer Systeme. In: Künne B, Tillmann W, Crostack H-A (Hrsg) Forderungsgerechte Auslegung von intralogistischen Systemen. Logistics on Demand. Verl. Praxiswissen, Dortmund, S 63–79
Google Scholar
Schütte S (2002) Designing feelings into products. Integrating Kansei Engineering methodology in product development. Inst. of Technology Univ., Linköping
Google Scholar
Schlund S, Winzer P (2010) DeCoDe-Modell zur anforderungsgerechten Produktentwicklung. In: Bandow G (Hrsg) „Das ist gar kein Modell!“. Gabler, Wiesbaden
Google Scholar
Schlund S (2011) Anforderungsaktualisierung in der Produktentwicklung: Entwicklung einer Methodik zur Aktualisierung von Anforderungen durch die Einbindung anforderungsrelevanter Ereignisse. Shaker, Aachen
Google Scholar
Schlüter N (2011) Kundenzufriedenheitsmessungen in Netzwerken. In: Winzer P (Hrsg) Anforderungsgerechte Produkt- und Dienstleistungsentwicklung im Rahmen des Wuppertaler Generic-Management-Konzeptes. Shaker, Aachen, S 1–18
Google Scholar
Schlüter N, Sochacki S (2012) Qualitative Netzwerkanalyse hinsichtlich der Anwendbarkeit von KuWiss-Netz. In: Winzer P (Hrsg) Generic Systems Engineering als Basis für die Weiterentwicklung des WGMK-Modells. Shaker, Aachen
Google Scholar
Sitte J, Winzer P (2005) Demand compliant design of robotic system. In: Gu J, Liu PX (Hrsg) 2005 international conference on mechatronics and automation. IEEE, Piscataway, S 1953–1958
Google Scholar
Sitte J, Winzer P (2006) Evaluation of a new complex system design method on a mechatronic automotive product. In: Moacyr Trés da Costa Dória (Hrsg) 2006 international engineering management conference. Engineering management: The human-technology interface, 17–20 September 2006, Mercure Hotel, Salvador Rio Vermelho, Bahia, Brazil, S 278–282
Google Scholar
Sitte J, Winzer P (2011) Systemmodellierung im Fokus von Generic Systems Engineering. In: Gesellschaft für Systems Engineering e.V. (Hrsg) Tag des Systems Engineering
Google Scholar
Swain AD, Guttmann HE (1983) Handbook of human reliability analysis with emphasis on nuclear power plant applications. Final report – NUREG/CR-1278. (Hrsg) U.S. Nuclear Regulatory Commission. Washington D.C
Google Scholar
VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (2006) VDI/VDE-Richtlinie 2650, Blatt 2 – Anforderungen an Selbstüberwachung und Diagnose in der Feldinstrumentierung – Allgemeine Fehler und Fehlerzustände von Feldgeräten, Berlin: Beuth
Google Scholar
Wang H, Chen GLZWH (2005) Algorithem of integrating QFD and TRIZ for the innovative design process. Int J Computer Appl Technol 23:41–52
Google Scholar
Willing M, Riekhof F, Winzer P (2011) Reliabilitiy in early product development phases. Using the DeCoDe+X approach for a data-based discussion of design decisions. In: Proceedings of QMOD 2011, San Sebastian, 29–31. August
Google Scholar
Winzer P (1997) Chancen zur umfassenden Unternehmensgestaltung. Methodischer Ansatz zur qualitäts-, human- und ökologieorientierten Gestaltung von Arbeits- und Fabriksystemen. Habil.-Schr.–Berlin, Techn. Univ., 1996. Lang, Frankfurt am Main (Europäische HochschulschriftenReihe 5, Volks- und Betriebswirtschaft, Bd 2189)
Google Scholar
Winzer P (Hrsg) (2012) PromeSys. Abschlussbericht zu „Prozesskettenorientiertes Regelkreismodell für ein nachhaltiges robustes Design mechatronischer Systeme”. Projektträger für das BMBF – Forschungszentrum Karlsruhe, Produktion und Fertigungstechnologie (PTKA-PFT), Förderkennzeichen 02PG1323. Shaker, Aachen
Google Scholar
Winzer P, Künne B (2009) Felddaten als Indikatoren für den Einsatz von Entwicklungsmethoden. (Field Data as Indicator for the Application of Product Developement Methods). Allgemeine Angaben zum Teilprojekt B9. In: Bernd Künne und Tim Richard (Hrsg) Sonderforschungsbereich 696. Forderungsgerechte Auslegung von intralogistischen Systemen – Logistics on Demand. Finanzierungsantrag (Fortsetzung) 07/2010 bis 06/2014, Dortmund, S 541–578
Google Scholar
Yamashina H, Ito T, Kawada H (2002) Innovative product developement process by integrating QFD and TRIZ. Int J Prod Res 40:1031–1050
Article MATH Google Scholar
Zielasek G (1995) Projektmanagement. Erfolgreich durch Aktivierung aller Unternehmensebenen. Springer, Berlin
Google Scholar
Zimolong B (1990) Fehler und Zuverlässigkeit. In: Hoyos CG, Zimolong B (Hrsg) Enzyklopädie der Psychologie – Ingenieurpsychologie. Göttingen: Verlag für Psychologie Hogrefe, S 313–345
Google Scholar

Download references

Author information

Authors and Affiliations

FB D – Abt. Sicherheitstechnik, FG Produktsicherheit und Qualitätswesen, Bergische Universität Wuppertal, Gaußstr. 20, 42119, Wuppertal, Deutschland
Petra Winzer

Authors

Petra Winzer
View author publications
You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Petra Winzer .

Rights and permissions

Reprints and permissions

Copyright information

About this chapter

Cite this chapter

Winzer, P. (2013). Die Bausteine des GSE-Vorgehenskonzeptes – Komplexität mittels einfacher Regeln beherrschen. In: Generic Systems Engineering. Springer Vieweg, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-30365-4_4

Download citation

DOI: https://doi.org/10.1007/978-3-642-30365-4_4
Published: 25 July 2013
Publisher Name: Springer Vieweg, Berlin, Heidelberg
Print ISBN: 978-3-642-30364-7
Online ISBN: 978-3-642-30365-4
eBook Packages: Computer Science and Engineering (German Language)

Publish with us

Policies and ethics