1. 21. Der Produktentwicklungszyklus

Produktentwicklung, wie sie in Industrieunternehmen betrieben wird, kann in Phasen beschrieben werden, die mit dem Handlungszyklus des Menschen nach diesem Prozessmodell korrespondieren. Diese Phasen verbinden die Reiche der REGELN und der RESSOURCEN in ihrer Ausprägung als Prozess zur Erstellung von Fertigungsdokumentation.

Dieses Kapitel wendet wie die folgenden zwei Kapitel die Grundsätze des in Kapitel 19 beschriebenen Handlungszyklus beispielhaft auf konkrete Alltagssituationen an. Leser, die sich für die beschriebenen Anwendungsgebiete nicht interessieren, sollten mit dem Kapitel 24 oder 25 fortfahren.

Die Firmenleitung repräsentiert das Interesse des Reiches der PERSONALITÄT, die einen Auftrag eines Kunden annimmt oder eine eigene Produktentwicklung gemeinsam mit dem Marketing entscheidet. Der Pol der Umwelt im Handlungszyklus ist die Welt der Fertigung innerhalb der gleichen Firma oder als Fremdvergabe. Die Erstellung produktionsreifer Fertigungsdokumentation entspricht dem Handlungsakt.
Die ressourciellen Aspekte werden durch die Gesetzmäßigkeiten der Technologie und Produktion repräsentiert, die bei der Umsetzung der Anforderungen im Design zu berücksichtigen sind.

Man kann den Handlungszyklus auch zwischen „Entwicklung“ und „Produktion“ anwenden, was den Bereich der Technologie umfassen würde. In diesem Falle wäre die Produktion ein Bereich echter Ressourcen.

Wie im Handlungszyklus sind zur Konkretisierung des Modells auf die betreffende Anwendung die Instanzen der Triadenelemente zu definieren, an denen entlang die Prozessphasen im aktiven und im passiven Pfad laufen. Siehe dazu die folgende Abbildung:

Anforderungen

Die Instanz „Anforderungen“ entspricht dem Subjekt des Regelreiches. Sie enthält die vertraglich zugesicherten Eigenschaften des Produktes, wie sie in der Regel in Form eines Lastenheftes vorliegen. Diese Anforderungen sind nie vollständig, da die Einhaltung von Normen und der Stand der Technik vorausgesetzt werden, ohne sie vollständig zu spezifizieren. Sie enthalten aber immer die speziellen Besonderheiten des zu entwickelnden Produktes. Oft enthalten die Lastenhefte auch Vorschriften bestimmter Design-Features, die die Entwicklung einschränken, weil die eigentliche Aufgabe des Produktes evtl. auch durch innovative Lösungen besser erfüllt werden kann. Diese Anteile können prozesstechnisch direkt der Phase 4 „Systementwurf“ zugeordnet werden, müssen aber trotzdem die Phasen 2 und 3 durchlaufen, weil deren Bedingungen von den vorgeschriebenen Design-Features erfüllt werden müssen. Ein theoretisch sauberes Lastenheft muss nur Anforderungen enthalten und die Lösungen dem Entwicklungsprozess überlassen.

Bedingungen

Diese Instanz entspricht dem Objekt des Regelreiches und stellt dementsprechend den Anforderungen einschränkende (nicht-ressourcielle) Bedingungen gegenüber. Das sind in der Regel Normen, Sicherheits-anforderungen, Zuverlässigkeit, Wartbarkeit, Entsorgungsregeln, ergonomische Regeln, betriebsinterne Regeln usw. Kosten, technologische Ressourcen und menschliche Ressourcen werden hier noch nicht betrachtet, da diese prozesstechnisch erst nach Abschluss der Entwicklung bekannt sind.

Sollen diese Parameter im Rahmen eines „simultaneous-engineering“ parallel mitkalkuliert werden, sind die entsprechenden Phasen der Entwicklung und der Technologie zu simulieren und im Rahmen der Vorkalkulation zu ermitteln. Dies wäre ein eigenständiger Nebenprozess über alle Folgephasen. Soll die Produktion an Ressourcen der eigenen Firma gebunden bleiben, wird das hier festgeschrieben.

Konzept

Als Synthese von Anforderungen und Bedingungen entsteht das Konzept als Instanz aller Vorgaben für die Entwicklung. Diese Instanz entspricht etwa dem Pflichtenheft. Zusätzlich zu den Anforderungen der ersten Instanz sind hier alle einschränkenden Bedingungen mit berücksichtigt. Das interne Know-how muss fehlende Inhalte im Lastenheft ergänzen. Evtl. vorgegebene Design-Features sind in das Konzept zu integrieren. Ansonsten sollte das Konzept die Art der Umsetzung im Design möglichst offen lassen. Der Anspruch an Vollständigkeit an das Konzept ist so groß, dass eine Vergabe der Entwicklung an Fremdfirmen möglich wäre. Mit der Erstellung des Konzeptes sind alle Aufgaben definiert, die im Reich der RESSOURCEN durch die Produktentwicklung entsprechend der numerologischen Regeln 4-6 zu konkretisieren sind. Wenn möglich, sind mehrere praktikable Konzeptvarianten der Entwicklung zur Entscheidung zu übergeben.

Systementwurf

Der Systementwurf bzw. das Grundsatzdesign des Produktes leitet sich in diesem Modell im Gegensatz zu vorherrschenden Meinungen nicht aus dem Konzept ab. Er beantwortet die Fragen des Konzeptes auf eine spezielle Weise. Zwischen Frage und Antwort befindet sich jedoch der aus dem Kapitel 4 bekannte tiefe Graben. Die Polarität der Logik kehrt sich um. Während das Konzept von den Kundenwünschen bestimmt war, wird das Design von der zu Verfügung stehenden Technologie bestimmt. Dies ist ein starker Machtfaktor, der im Management nicht immer berücksichtigt wird. Leitende Angestellte gehen oft von einer Durchgängigkeit oder „Umsetzung“ der Anforderungen in Lösungen aus. Faktisch werden aber die Anforderungen gegen die möglichen Lösungen gespiegelt. Auch bei der Softwareproduktion ist es eine Fiktion, eine sprachliche Beschreibung eindeutig in einen logischen Algorithmus umzusetzen. Schon eine Zustandsmaschine oder ein Regler lässt sich auf viele verschiedene Arten programmieren.
Bei den Hardwareanteilen eines Produktes ist das Problem noch offensichtlicher. Nicht nur prozesstechnisch sondern auch praktisch werden viele Neuentwicklungen bis zur Konzeptphase als „neu“ gehandhabt, in der Designphase aber als Anpassentwicklung bestehender Projekte abgewickelt. Ein weiteres Problem sind Nichtliniearitäten zwischen der Komplexität des Konzeptes und des Designs. Diese verursachen oft ungeplante Mehraufwendungen in beträchtlicher Höhe. Es ist sehr einfach, für ein Produkt zehn kompatible Varianten zu konzipieren. Die Kosten für das Design könnten dadurch explodieren. Der Systementwurf spiegelt also die im Konzept fixierten Vorgaben gegen die Realität und formuliert die Designgrundsätze. Die Sprache des Systementwurfs ist so gestaltet, dass interne und externe Systemgrenzen transparent und verständlich werden und dass eine Anschlussfähigkeit an das Konzept geprüft werden kann.

Systemarchitektur

Diese Instanz ist die Hauptinstanz des Entwurfs. Es werden alle Lösungen vollständig beschrieben und den beteiligten Subsystemen zugeteilt. Alle Umsetzungsbedingungen der beteiligten Systeme werden berücksichtigt. Schnittstellenbeschreibungen und Anwendungsbedingungen werden formuliert. Die Entwurfssprache entspricht den Entwurfswerkzeugen und Designwelten und ist eindeutig in Fertigungsdokumentation übertragbar.

Fertigungsdokumentation/Prototyp

Die Herstellung der Fertigungsdokumentation entspricht dem Formelement der Triade der RESSOURCEN und dem Handlungsakt des Menschen. Sie erzeugt die Produktionsvorschriften für die gewählte Fertigungstechnologie und steht dementsprechend am Übergang zur „Umwelt“ der Entwicklung, der Technologie. Gegebenenfalls entsteht ein Prototyp als Testträger.

Beschreibung der Phasen :

Die Phasen des Modells werden typischerweise sequentiell in aufsteigender Reihenfolge durchlaufen. Im passiven Pfad werden durch Tests pro Instanz die Ergebnisse des aktiven Pfades bestätigt. Kann die Bestätigung auf einer Testebene nicht erfolgen, fließt die Aktivität in der betreffenden Instanz auf die aktive Seite. Kann im aktiven Pfad eine Triade nicht erfolgreich abgeschlossen werden, gelten die Regeln der Inversion, d. h. die jeweils vorherige Triade wird in ihrem aktiven Pfad erregt und muss ihre Entscheidungen revidieren. Sind z. B. vertraglich zugesicherte Eigenschaften nicht normgerecht oder nicht sicher umzusetzen, ist der Vertrag mit dem Kunden oder die Produktidee des Marketings in Frage gestellt.

Lastenhefterstellung (1)

Der Aktivitätsimpuls richtet sich auf die vollständige Erfassung aller äußeren Anforderungen, die im zu entwickelnden Produkt umzusetzen sind. „Außen“ meint hier die Forderungen des Kunden oder des Marketing, soweit diese in der Lage sind, ihre Vorstellungen zu beschreiben. In der Regel sind diese Vorstellungen unvollständig. Oft sind dem Besteller einer Entwicklung technische Voraussetzungen und Verknüpfungen nicht bekannt. Entscheidend ist es, die Idee oder das Problem zu verstehen, das mit dem Produkt gelöst werden soll. Das Risiko einer unvollständigen Beschreibung der Anforderung liegt formal beim Kunden oder beim Marketing, ist aber in dieser Phase möglichst zu minimieren, ohne zu viel Know-how zu verraten. Im Zuge der fortschreitenden Entwicklung sind dem Besteller von Entwicklungen aktuelle Märkte, aber oft nicht neueste technologische Möglichkeiten bekannt. Innovation und Alleinstellung beginnt in dieser Phase ggf. mit Aufklärung des Kunden über neue und möglichst exklusive Lösungsmöglichkeiten.

Ermittlung einschränkender Bedingungen (2)

Entsprechend der Objekt-Qualität der „2“ im Reich der REGELN wird der Inhalt des Lastenheftes in dieser Phase mit allen möglichen einschränkenden Bedingungen (außer ressourcieller Bedingungen) konfrontiert. Es wird für jede Lastenheftforderung die Entscheidung getroffen, ob diese akzeptiert werden kann oder zurückgewiesen werden muss. Für jede einschränkende Bedingung aus Normen und aus dem Lastenheft selbst wird geprüft, ob diese bei Umsetzung der Lastenheftforderungen eingehalten werden kann. Wenn diese Prüfungen negativ sind, wird der Impuls über Phase 11 und 12 an Phase 1 zurückgeführt. Ggf. erfolgt eine neue Verhandlungsrunde. Die verbleibenden und akzeptierten Widersprüche zwischen Anforderungen und Bedingungen werden in Phase 3 übergeben. Die Inhalte dieser und der folgenden Phasen müssen für den Kunden nicht zwangsläufig transparent gemacht werden.

Pflichtenhefterstellung (3)

In der Phase der Pflichtenhefterstellung nach diesem Modell werden möglichst viele Konzeptvarianten beschrieben, die eine Umsetzung der Anforderungen nach Phase 1 unter den Bedingungen der Phase 2 erlauben. Alle Konzeptvarianten werden durch Einbeziehung firmeninternen Know-hows bezüglich der Anforderungen und Bedingungen vervollständigt. Kann keine konzeptionelle Lösung gefunden werden, die für Auftraggeber und Auftragnehmer akzeptabel ist, wird der Prozess hier abgebrochen. D. h., die Qualität der Bearbeitung dieser ersten drei Phasen noch vor dem Vertragsabschluss beeinflusst maßgeblich das Realisierungsrisiko des Projektes.

Definition Designgrundsätze (4)

In dieser Phase erfolgt die Entscheidung der Umsetzung eines der Konzepte aus Phase 3 durch Zuordnung von grundsätzlichen Designlösungen, Produktionstechnologien und Ressourcen. Die Motivation des Regelreiches wird hier zur Handlung des RESSOURCEN-Reiches. Das Gesetz des Konzeptes wird zur Energie der Gestaltung in Form von Bereitstellung von Entwicklungsbudgets. Die Umsetzung des gewählten Konzeptes beginnt, indem die gewählte Lösung als Systementwurf in der Sprache der Systementwickler beschrieben wird.

Die Lösungsdetails werden mit numerischen Identifizierungen versehen und ggf. Subsystemen zugeordnet.
Die Identifizierungen werden verwendet, um in den Dokumenten der Phase 3 nachträglich von den Anforderungen auf die entsprechenden Lösungsdetails zu referenzieren und deren vollständige Umsetzung zu garantieren und ggf. nachzuweisen. Damit wird der Graben überbrückt, der die Anforderungen von den Lösungen trennt und eine Verfolgung der Umsetzung der Anforderungen im Bereich der Umsetzung im Design erschwert. Gleichzeitig dienen die Identifizierungen der Lösungsdetails zur Kontrolle von deren Umsetzung und Testung in den folgenden Phasen.

Designplanung (5)

Die Phase 5 ist nach den numerologischen Grundsätzen der Triade der Gegenentwurf zu Phase 4 und gleichzeitig der Beginn der Dynamisierung des Projektes. Hier werden dem Systementwurf die Bedingungen der Entwicklung gegenübergestellt und im Rahmen einer Planung aufgelöst. Typische Aufgaben sind die Differenzierung der Designaufgaben, die Ressourcenbereitstellung, die Zeitplanung und die Dokumentation der Detail-Entwürfe in den Subsystemen. Die Identifizierungen der Lösungsdetails aus Phase 4 werden übernommen und weiter ausdifferenziert. Es entstehen in der Regel Stromlaufpläne, Architekturdokumente, Logik-Schemata, mechanische Übersichts- und Zusammenbauzeichnungen.

Designabschluss (6)

In der Phase 6, die dem Handlungsakt des Menschen im Handlungszyklus entspricht, werden die Dokumente erstellt, die die Herstellung des entwickelten Produktes ermöglichen. Zusätzlich entsteht die erforderliche Produkt-dokumentation für Anwender und Wartungspersonal. Die Form des Reiches der RESSOURCEN entsteht.

Modultest (7)

Mit Phase 7 beginnt die Dynamik der Wahrnehmung des in Phase 6 Geschaffenen. Die Herstellung eines Prototyps oder ersten Serienmusters wird hier vorausgesetzt, aber nicht als Bestandteil des Entwicklungsprozesses betrachtet. Die Aufgabe dieser und aller folgender Phasen ist es, durch Tests die Gültigkeit der Ergebnisse der gegenüber-liegenden Phasen der betreffenden Instanzen nachzuweisen. Der Modultest dient demnach zum Nachweis der Korrektheit der Fertigungsdokumentation. Implizit wird die Qualität der Umsetzung der Fertigungsdokumentation beim Bau des Prototyps und der beteiligten Technologien getestet. Der Modultest muss ausschließlich auf Basis der Fertigungsdokumentation durchführbar sein. Er beinhaltet typischerweise Sichtprüfungen, Montagetests, Verdrahtungstests und den Test elementarer Funktionen. Bei erfolgreichen Tests wird mit Phase 8 fortgefahren. Ist der Modultest nicht erforderlich, muss Phase 6 auf der anderen Seite der Instanz „Fertigungsdokumentation“
wiederholt werden.

Funktionstest (8)

Der Funktionstest weist die in der Phase der Designplanung (5) beschriebenen Teilfunktionen in den Subsystemen nach.

Systemtest (9)

Der Systemtest weist die in der Phase der Designgrundsätze (4) beschrieben Funktionen der Subsysteme nach. Bis zum Systemtest sind die Testaufgaben auf das Design bezogen. Sie weisen die korrekte Umsetzung der Lösung der Anforderungen im Design nach.

Integrationstest (10)

Der Integrationstest weist die im Pflichtenheft (3) beschrieben Anforderungen des Produktes nach. Von hier an sind die Tests auf das Lastenheft bezogen. Sie weisen die Erfüllung der Anforderungen an das Produkt nach.

Konformitätstest (11)

Der Konformitätstest weist die Einhaltung der in der Phase 2 definierten einschränkenden Bedingungen , insbesondere der Erfüllung von Standards und Vorschriften, nach.

Performance- und Akzeptanztests (12)

Die Performancetests weisen die im Lastenheft geforderten Anforderungen im Umfeld der geplanten Anwendung nach, soweit diese noch nicht Gegenstand von Tests gewesen sind. Spezielle vom Kunden geforderte Akzeptanztests sind der letzte Baustein für den Nachweis der Vertragserfüllung. Mit Erfüllung dieser Tests ist der Zyklus der Produktentwicklung abgeschlossen. Die Serienproduktion oder ggf. die anschließenden Service- und Wartungszyklen wären in separaten Prozesszyklen zu planen und durchzuführen.

Durch Anwendung der Idee der Reiche auf die Produktentwicklung kann der Blick auf die Qualität der einzelnen Entwicklungsphasen geschärft werden. Es ist zu erkennen, dass die innere Logik einer Produktentwicklung der numerologischen Logik der Widerspruchslösung über zwei verbundene Triaden folgt. Es wird deutlich, dass die Bearbeitung der Anforderungen nach anderen logischen Regeln erfolgt als die Erarbeitung von Lösungen im Design. Die logische Grenze, an der eine Transformation von Anforderungen in Lösungen erfolgen muss, wird sichtbar. Die Idee einer logischen Durchgängigkeit von der Anforderung bis zur Lösung wird zu einer Fiktion. Mit diesem Modell steigen die Chancen, den Entwicklungsprozess als Spiegelungsprozess von Anforderungen an Lösungen zu verstehen und zu organisieren. Im Zuge sich immer schneller entwickelnder Technologien wächst das Reservoir von Lösungen schneller als die Produktentwicklung. Aus einer forschungsnahen Entwicklung vergangener Zeiten wird mehr und mehr eine Projektierung im Sinne einer Selektion passender verfügbarer Lösungen. Einer effizienten personen-unabhängigen Verwaltung von Know-how als Katalog verfügbarer Lösungen kommt daher eine immer größere Bedeutung zu. Die Organisation der Produktentwicklung sollte die Bipolarität von Anforderungen und Lösungen berücksichtigen.