Entwicklungsmanagement: Mit hervorragenden Produkten zum Markterfolg

Entwicklungsmanagement

Ulrich Holzbaur

Entwicklungsmanagement Mit hervorragenden Produkten zum Markterfolg

Mit 97 Abbildungen und 53 Tabellen

123

Professor Dr. Ulrich Holzbaur Hochschule für Technik und Wirtschaft Aalen Beethovenstraße 1 73430 Aalen Deutschland [email protected]

ISBN 978-3-540-39516-4 Springer Berlin Heidelberg New York

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet ¨ uber http://dnb.d-nb.de abrufbar. Dieses Werk ist urheberrechtlich gesch¨ utzt. Die dadurch begr¨ undeten Rechte, insbesondere die der ¨ bersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der FunkU sendung, der Mikroverfilmung oder der Vervielf¨ altigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielf¨ altigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zul¨ assig. Sie ist grunds¨ atzlich verg¨ utungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten w¨ aren und daher von jedermann benutzt werden d¨ urften. Herstellung: LE-TEX Jelonek, Schmidt & V¨ ockler GbR, Leipzig Einbandgestalltung: WMX Design GmbH, Heidelberg SPIN 11851349

43/3100YL - 5 4 3 2 1 0

Gedruckt auf s¨ aurefreiem Papier

Vorwort Die systematische Planung und Entwicklung neuer Produkte, Dienstleistungen und Problemlösungen wird für die kommenden Jahrzehnte ein entscheidender Wettbewerbsfaktor zwischen Betrieben und Staaten, und eine Voraussetzung für die Nachhaltigkeit unseres Wirtschaftens sein. Entwicklungsmanagement erlaubt dem Unternehmen, selbst erfolgreich zu sein und durch Wertschöpfung zum Erfolg der Gesellschaft beizutragen. „Wie kommt man zu so etwas?“ Diese Frage stellt sich fast jeder Benutzer einmal, wenn er ein fertiges Produkt als Ergebnis eines Entwicklungsprozesses sieht. Den Produktionsprozess selbst können wir uns meist noch vorstellen, aber wie kommt man darauf, ein solches Produkt zu entwickeln? „Wie haben die das geschafft?“ wird nicht nur bei fertigen Computersystemen sondern auch bei Konsum- und Investitionsgütern, Serviceprodukten und Veranstaltungen gefragt. Mit dem richtigen Produkt in der richtigen Qualität zur rechten Zeit am Markt zu sein, ist eines der wichtigsten Kriterien für den Unternehmenserfolg. Die kontinuierliche Neuentwicklung und Verbesserung von Produkten hält nicht nur die Wirtschaft – regional und global – am Laufen, sondern gibt auch die Möglichkeit, quantitatives durch qualitatives Wachstum zu ersetzen und eine nachhaltige Entwicklung zu erreichen. Die Entwicklung von Produkten braucht aber nicht nur die Genialität des Erfinders und die Kompetenz des Ingenieurs, sondern auch die leitende Hand des Managers, der den Entwicklungsprozess zielgerichtet zu einem auf dem Markt erfolgreichen Produkt führt. Wegen der Innovativität des Entwicklungsprozesses unterscheidet sich das Management von Entwicklungen stark vom klassischen Management. Wer Unternehmen zum Erfolg führen will, braucht sowohl Managementkompetenz als auch Verständnis für Entwicklungsprojekte und ihre Besonderheiten. Planung und Bau eines Hauses sind anschaulich, aber bei komplexen Systemen, Software und Dienstleistungsprodukten ist der Entwicklungsprozess eine vielschichtige Angelegenheit. Kenntnis der Technik oder Betriebswirtschaft allein hilft nicht. Die Produktentwicklung steht im Spannungsfeld zwischen technischen Möglichkeiten und Marktanforderungen, zwischen Wirtschaftlichkeit und Qualität, zwischen Termindruck und Mitarbeitermotivation. Gegenseitige Schuldzuweisungen wie „Marketing verspricht dem Kunden das Blaue vom Himmel“, „Die Entwicklung braucht immer viel zu lang“, „Management lässt uns hängen“, „Marketing kann unsere tollen Entwicklungen dem Kunden nicht vermitteln“, „Die Entwicklung spielt nur rum“ gefährden den Unternehmenserfolg. Aber auch dort, wo Entwick-

vi

Vorwort

lungen nicht nach außen verkauft, sondern als Strategie oder System intern genutzt werden, sind Qualität, Effizienz und Schnelligkeit gefragt. Dabei hat „Entwicklung“ in den unterschiedlichen Bereichen wie Hardware, Software, Konzeption und Dienstleistung zwar verschiedene Schwerpunkte aber allgemein gültige Prinzipien. In den letzten Jahrzehnten wurden Einkauf und Vertrieb, Kostenrechnung und Controlling optimiert, weil sie formalisierbar und allgemeingültig sind. Der Einkauf stellt die Ressourcen für die Erstellung eines Produkts bereit, der Vertrieb soll das Produkt absetzen und das Controlling sichert die kostengünstige Erstellung. Das Unternehmen lebt von und identifiziert sich durch seine Wertschöpfung, d.h. durch die Produkte, die es der Gesellschaft zur Verfügung stellt. Dazu dient die Produktion – ein durchoptimierter Bereich mit bedrohlichem internationalem Konkurrenzdruck – und die Produktentwicklung, wo Kundennähe und Kenntnisse, Kreativität und Systematik die wichtigsten Wettbewerbsfaktoren sind. Entwicklung ist der Schlüssel zum Unternehmenserfolg im dritten Jahrtausend. Optimale Entwicklung bedeutet mehr als die effiziente Durchführung von Entwicklungsprojekten: Das Unternehmen muss an der effektiven Entwicklung und Vermarktung attraktiver Produkte orientiert sein – von der Forschung bis zur Leistungserstellung. Wenn Sie die Verantwortung für die Entwicklung eines Produkts oder Konzepts tragen, sollten Sie prüfen, ob dafür die folgenden Aussagen gelten: • Es ist egal, wann die Lösung fertig ist, Zeit spielt keine Rolle. • Es ist egal, wie viel die Lösung kostet, Geld spielt keine Rolle. • Fehler haben keine Konsequenzen, Qualität spielt keine Rolle. • Das Ergebnis wird nur von den Entwicklern selbst genutzt. • Niemand ist auf das Ergebnis angewiesen. • Sollten Änderungen kommen, wird das Ganze neu entwickelt. Wenn Sie alle diese Fragen mit „ja“ beantworten, können Sie viel Zeit, Geld und Ärger sparen, indem Sie diesen Leitfaden nicht durcharbeiten und konsequent das geplante Produkt nicht entwickeln. Wenn Sie aber die Fragen mit „nein“ beantworten, müssen Sie einige Prinzipien beachten, um nicht Zeit und Geld zu verschwenden und Karriere und Unternehmen zu riskieren. Projektmanagement ist in Großprojekten selbstverständlich, in kleineren Projekten hat man aber häufig nicht die Kapazität für ein dediziertes Projektmanagementteam. Aber selbst ein Projekt, das von den Kosten her vernachlässigbar ist, kann gravierende Auswirkungen für eine Organisation haben: Die Konsequenzen von Flops oder Fehlfunktionen sind nicht an den Entwicklungsaufwand gekoppelt. Das Risiko eines Flops kann durch systematische Entwicklung verringert werden. Entwicklung ohne Projektcharakter und ohne Qualitätsansprüche gibt es nicht, die für Großprojekte geeigne-

Vorwort

vii

ten Methoden müssen jedoch für kleinere Projekte maßvoll angepasst werden. Bei Entwicklungsprojekten geht es nicht nur darum, gegebene Anforderungen umzusetzen – “wer macht wann was womit?“, sondern erst einmal diese Anforderungen festzustellen – „wozu machen wir was wie?“. Die Prinzipien systematischer Entwicklung müssen angewandt werden, wenn materielle oder immaterielle Produkte entwickelt werden. Selbst bei der Entwicklung einer Strategie oder bei der Planung eines Events gelten dieselben Grundsätze, damit systematisch ein hochwertiges Ergebnis entwickelt wird. Softwareentwicklung gehorcht denselben Prinzipien, hat aber ein extrem breites Spektrum, da sehr viele Personen in Beruf, Ausbildung und Freizeit Software entwickeln, auch außerhalb der klassischen Informatik-Abteilungen und unabhängig von einer Informatik-Ausbildung. Auch das Customizing von Anwendungen und die Erstellung von Datenbanken müssen nach den Grundprinzipien der Softwareentwicklung erfolgen. Dienstleistungen und Konzepte – mit oder ohne Softwareanteil – müssen ebenso systematisch entwickelt werden. Eine ganz besondere Klasse von Entwicklungsprojekten sind solche, bei denen es um eine Konzeption geht. „Ich brauche bis Montag eine Idee – ausgearbeitet und umsetzbar, setzen Sie sich mal zusammen“ So beginnen viele Entwicklungsprojekte. Und so ist auch das Scheitern vorprogrammiert, wenn der Verantwortliche das Ganze nicht systematisch und strukturiert angeht. Ob für einen internen oder externen Kunden – eine gute Konzeption oder Strategie zu entwickeln, kann die Zukunft der Organisation bedeuten. Durch intelligente Entwicklungen kann das Verhältnis zwischen Nutzen und Aufwand um den schon fast sprichwörtlichen „Faktor vier“ und in vielen Fällen um einen Faktor 10 verbessert werden – zum Nutzen von Mensch und Umwelt. Gemeinsam ist allen Entwicklungsvorhaben die starke Bedeutung der Modellbildung: Modelle dienen der Dokumentation, Analyse und Kommunikation von Ideen. Die Bedeutung für den Unternehmenserfolg und die Beteiligung von Kunden, Forschern, Implementieren und Interessenten machen aus dem Entwicklungsmanagement eine wichtige und herausfordernde Aufgabe. Dieser Leitfaden vermittelt denjenigen, die für eine Entwicklung verantwortlich sind, die Grundlagen des Managements von Entwicklungen in angemessener Form und passendem Umfang. Entwicklungsmanagement wird zur Zeit in dieser Breite nicht als einheitliches Vorgehen gesehen. Wenn man aber die Ansätze und Methoden aus Hardware, Software, Konzeptionen und Dienstleistungen zusammennimmt, entsteht eine Breite und Tiefe, die

viii

Vorwort

alle diese Bereiche entscheidend voranbringen kann. Deshalb sollen auch die Beispiele aus den verschiedensten Bereichen dazu dienen, das Allgemeine zu erkennen, genauso wie wir in der Betriebswirtschaft oder Physik die allgemeingültigen Grundlagen mit speziellen Beispielen verdeutlichen. Die Umsetzung in den eigenen Bereich – abhängig von Produkt, Technologie, Anwendung, Organisation und Kunde – ist dann eine Frage der Spezialisierung. Das Ziel dieses Buches ist nicht, Manager zu Entwicklern oder Ingenieure zu Buchhaltern umzuschulen, sondern beide zu befähigen, Produktentwicklung im Unternehmen erfolgreich zu planen und durchzuführen. Schwerpunkte wurden bei denjenigen Aspekten gesetzt, die für den Erfolg eines Produkts kritisch sind. Ich hoffe, dass dadurch Entwicklungen zielgerichteter und schneller ablaufen und bessere Problemlösungen schneller zur erfolgreichen Anwendung kommen. Mein Dank geht an alle Kollegen und Kameraden, Kommilitonen und Freunde, Mitarbeiter und Auftraggeber, Studenten und Partner aus den vielen Projekten für die wertvollen Erfahrungen, die ich mit ihnen gemeinsam machen durfte und für die Informationen aus den verschiedensten Bereichen. Viele Kollegen und Diplomanden an der Hochschule Aalen, Partner und Kunden aus der Arbeit im Rahmen der Steinbeis-Stiftung für Wirtschaftsförderung und als Berater, Mitstreiter aus ehrenamtlichen Projekten, und die Diskussion mit Freunden haben zu der hier vorgestellten gesamtheitlichen Sicht auf die Entwicklung von Produkten im allgemeinsten Sinne beigetragen. Ein besonderer Dank geht an meine Frau Martina und unsere Söhne Alexander und Christian für die Korrekturen und viele wertvolle Hinweise und Ideen, sowie an Dr. Martina Bihn und Barbara Karg vom Springer-Verlag für die professionelle Betreuung und die gute Kooperation. Wenn hier und im Folgenden von Kunden und Mitarbeitern, Managern und Entwicklern etc. die Rede ist, so sind hiermit auch die Damen gemeint, da es sich um Rollen handelt. Ich bin sicher, dass Entwicklungsmanagerinnen auch ohne umständliche Wortkonstruktionen dieses Buch erfolgreich nutzen und umsetzen werden.

Aalen, im Oktober 2006 Ulrich Holzbaur

Inhaltsverzeichnis 1 Einführung 1.1 Entwicklung 1.2 Produkt 1.3 Produktentwicklung 1.4 Entwicklungsprojekte 1.5 Methoden und Modelle 1.6 Ziel und Nutzung

1 2 7 11 18 21 27

2 Produktentwicklung 2.1 Produkt 2.2 Produkt und Lebenszyklus 2.3 Engineering 2.4 Anforderungen 2.5 Spezifikation 2.6 Entwurf 2.7 Qualität und Risiko 2.8 Testen und Lernen 2.9 Spezielle Bereiche

31 32 44 49 57 62 65 81 88 89

3 Projektmanagement 3.1 Projekte managen 3.2 Projektorganisation 3.3 Projektplanung 3.4 Projektsteuerung und Abschluss 3.5 Management mehrerer Projekte 3.6 Management spezieller Projekttypen

91 91 101 107 127 137 140

4 Entwicklung als Projekt 4.1 Entwicklungsprozess 4.2 Vorgehensmodelle 4.3 Aufgaben im Entwicklungsprojekt

145 145 149 151

5 Management der Entwicklung 5.1 Entwicklung und Management 5.2 Grundlagen für das Management 5.3 Qualitäts- und Risikomanagement 5.4 Information, Kommunikation und Wissen 5.5 Management von Entwicklungsprojekten 5.6 Management der Entwicklung im Unternehmen

159 159 162 171 180 185 195

x

Inhaltsverzeichnis

6 Entwicklung in speziellen Produktbereichen 6.1 Physische Produkte 6.2 Intelligente Systeme 6.3 Software 6.4 Konzepte und Systeme 6.5 Dienstleistungen 6.6 Dokumentationen

205 206 215 221 231 237 251

7 Methoden und Modelle 7.1 Modellbasiertes Problemlösen 7.2 Modelle 7.3 Modellierung 7.4 Mathematische Modelle 7.5 Strukturierte Systemanalyse

253 253 257 268 279 291

8 Literatur

295

1

Einführung Erfolg durch gute Produkte

In diesem Kapitel betrachten wir die Bedeutung, die Grundlagen und einzelnen Komponenten des Entwicklungsmanagements und die dafür notwendigen Begriffe. Eine Organisation hat Erfolg, wenn sie etwas bietet, was für jemand anderen ein Problem löst. Diese Lösung kann ein Produkt oder eine Dienstleistung sein. Der Erfolg der Organisation beruht darauf, dass sie diese Lösung „hat“ und auf dem Markt anbietet. Egal, ob diese Lösung im Prinzip seit Jahrtausenden existiert oder durch eine spontane Erfindung, einen genialen Geistesblitz entstanden ist, sie muss durch einen Entwicklungsprozess auf die Bedürfnisse des Kunden angepasst werden, damit sie erfolgreich ist. Diese Entwicklung von Problemlösungen – meist in Form von Produkten – und die Verbesserung des Kundennutzes durch Innovationen bildet den Schüssel zum Erfolg der Organisation. Die Vermarktung und Realisierung der Produkte sind nicht nur gleich wichtig, sie müssen auch mit der Entwicklung zusammenpassen. Ebenso muss die Entwicklung Ergebnisse liefern, welche die Organisation umsetzen und absetzen kann. Erst die Realisierung und Vermarktung führt zum Erfolg in Form von Gewinn oder Wertsteigerung. Management von Entwicklungsprojekten muss sicherstellen, dass das angestrebte Ergebnis erzielt wird und die gestellten Anforderungen an Projekt und Ergebnis erfüllt werden. Der Erfolg von Entwicklungsprojekten zeigt sich erst viel später: wenn das entwickelte Produkt produziert und auf dem Markt eingeführt wird. Ein Entwicklungsprojekt muss vielfältigen Anforderungen gerecht werden. Die Anforderungen können folgende Bereiche betreffen: • Endprodukt: Die Anforderungen des Kunden an das Endprodukt betreffen Qualität und Preis. Unter dem Schlagwort Qualität werden dabei alle Ansprüche an das Produkt verstanden, neben den direkt zum Nutzen betragenden Eigenschaften und Funktionen sind hier Sekundärnutzen, Sicherheit, Bedienbarkeit und vieles andere gefragt. Außerdem wünscht der Kunde einen günstigen Preise beziehungsweise ein gutes PreisLeistungs-Verhältnis. • Entwicklungsergebnis: Die Anforderungen des Unternehmens an das Produkt als Entwicklungsergebnis umfassen neben der Erfüllung der Kundenanforderungen die Umsetzbarkeit, Produzierbarkeit, Marktfähigkeit und das Potential für die Weiterentwicklung des Produkts.

2

1 Einführung

• Projekt: Die Anforderungen an ein erfolgreich durchgeführtes Projekt

betreffen nicht nur ein gutes Produkt, sondern auch die Einhaltung der Vorgaben an das Projektvorgaben (Termin, Kosten, Personal) und allgemeine Projektergebnisse wie Lerneffekt und Imagegewinn. Die Entwicklung ist der entscheidende Faktor zur Umsetzung der Potentiale aus Forschung und Erfahrung in einen Erfolg der Organisation. Das im Unternehmen vorhandene Potential und Wissen wird über die Produktentwicklung in marktfähige Produkte und damit in Umsatz und Gewinn umgesetzt. Potential: Know-How, Forschung, Infrastruktur Entwicklung Erfolg: Gewinn, Wertsteigerung, Kunde und Stakeholder

Abbildung 1-1: Erfolgsfaktor Entwicklung Aufgrund dieser zentralen Stellung hat Entwicklungsmanagement viele Schnittstellen und Reibungspunkte. Entwicklungs-Management darf keine Konfrontation sein: „hie Entwickler – hie Manager“. Entwickler müssen sich und andere managen, Manager müssen im Groben an der Entwicklung teilhaben, bei der Entwicklung von Konzepten und Systemen auch selbst aktiv teilnehmen. Die gemeinsame Sprache und das gemeinsame Interesse müssen überwiegen. Management ist nicht nur innerhalb des Entwicklungsprojekts gefragt, sondern auch nach außen: die organisatorische Einbettung des Projekts und die langfristige Wechselwirkung zwischen dem Unternehmen und seinen Projekten sind wesentliche Erfolgsfaktoren. Entwicklungsmanagement ist mehr als das Management von Entwicklungsprojekten; die Aufgabe, das Produktspektrum des Unternehmens und damit seine Wertschöpfung kontinuierlich zu verbessern, ist die wichtigste strategische Aufgabe im Unternehmen. Selbst in Unternehmen. die vielleicht nach eigener Meinung keine Entwicklung haben, werden Entwicklungsprojekte für Lösungen, Verfahren, Werkzeuge und Strategien durchgeführt.

1.1 Entwicklung Systematisches Schaffen eines neuen Systems Der Begriff Entwicklung ist so vielfältig und die Bedeutung der Produktentwicklung so umfangreich, dass er zunächst einer Klärung und Abgrenzung wert ist.

1.1 Entwicklung

3

1.1.1 Begriff Entwicklung ist eine schöpferische Tätigkeit Schaut man im Lexikon oder im Buchkatalog, so findet man zum Begriff Entwicklung zunächst vor allem die Entwicklung des Kindes, des Menschen, der Menschheit, von Organisationen und Nationen, die Entwicklung von Kunst, Kultur und Wissenschaft, die Entwicklung des Denkens und von Konflikten – also den Prozess der individuellen oder kollektiven Evolution eines realen oder virtuellen Objekts. Entwicklung wird hier als kontinuierlicher Prozess gesehen im Gegensatz zum plötzlichen Entstehen oder der Schöpfung. Die Annahme, dass diese Evolution auf ein Ziel hin gerichtet sei, bezeichnet man als teleologisch. Die Entwicklung des Flugzeugs führt von Ikarus über die Gebrüder Wright zum Airbus. Ein System kann sich autonom entwickeln. Persönlichkeitsentwicklung und Organisationsentwicklung werden aber als Prozesse gesehen, die nicht nur passieren, sondern aktiv gesteuert werden. Entwicklungshilfe versucht, die Entwicklung „unterentwickelter“ Kulturen und Völker von außen zu steuern. Dem gegenüber hat der Betriebswirt, Ingenieur oder Naturwissenschaftler den zweiten Ansatz: Wenn er etwas entwickelt, so setzt er Anforderungen in eine Konzeption um, er entwickelt die Lösung zu einem Problem. Auch hier findet ein Entwicklungsprozess, eine Folge von Transformationen statt, aber zielgerichtet, geplant und kreativ auf ein Produkt hin arbeitend. Das Ergebnis der Entwicklung ist ein Konzept oder eine Realisierung eines – materiellen oder immateriellen – Produkts, das es in dieser Form vorher nicht gegeben hat. Das Objekt verändert sich also nicht nur in seinen Parametern oder Bestandteilen, sondern aus einer Vorgabe (Forderungen) entsteht ein Produkt oder zumindest eine Beschreibung eines Produkts. Viele Fachautoren definieren natürlich Entwicklung aus Ihrem jeweiligen Blickfeld. So wird im mechanischen Bereich teilweise zwischen Entwicklung und Konstruktion unterschieden, und teilweise einer der Begriffe synonym für beide Tätigkeiten gewählt. Im Softwarebereich wird die Implementierung, Integration und Testen mit einbezogen. Damit kann Entwicklung sehr vielfältig sein: die Entwicklung eines Softwareprogramms führt direkt zum Endprodukt, an die Entwicklung eines Bauteils schließt sich die Produktion an. Wie vielfältig der Begriff Entwicklung ist, zeigt auch ein Blick in ein Lexikon oder ein Wörterbuch und die vielen möglichen Übersetzungen beispielsweise ins Englische.

4

1 Einführung

Tabelle 1-1: Übersetzungsmöglichkeiten für das Wort „Entwicklung“ construction deployment design development dynamics engineering evolution evolvement formation generation improvement movement processing progression trend

elaboration growth

Gemeinsam ist diesen Entwicklungen, dass durch einen geplanten und gezielten Prozess etwas geschaffen wird, was den anfangs gemachten Forderungen entspricht. Was aus Sicht des Außenstehenden als Schöpfung erscheint, ist aber eine Abfolge von Schritten, ein Prozess oder ein Projekt. Dabei ist das Ergebnis nicht von vorne herein gegeben: der Wunsch, verkorkte Weinflaschen öffnen zu können, kann zum klassischen Korkenzieher mit einer Schraube, zu komplexeren Mechaniken oder zur Verwendung von Druckluft führen. Korkenzieher Die Anforderungen an einen Korkenzieher sind recht einfach: Er soll es ermöglichen, aus einer Flasche den Korken herauszuziehen. Dabei ist die Hauptanforderung, dass man nur soviel Kraft braucht, wie die meisten Menschen haben, und dass weder Flasche noch Wein oder Umgebung Schaden leiden. Je nach Nutzer kommen noch verschiedene Anforderungen dazu. Der Primärnutzen „Flasche öffnen“ kann von Sekundärnutzen wie Design oder Ausgefallenheit und Nebenbedingungen wie schonender Behandlung des Weins oder automatisiertem Öffnen ergänzt werden. Lösungsansätze Die Kraft, die den Korken aus der Flasche zieht, greift am Korken an. Sie kann vom Menschen selbst kommen, dies ist beim klassischen Korkenzieher, einer Schraube an einem Griff der Fall. Hauptaugenmerk liegt darin, dass der Korken sauber herausgezogen wird. Um die notwendige Kraft zu verringern können verschiedene Mechanismen der Kraftübertragung (Hebel, Schraube, Zahnrad, Seilzug, Druck) oder Speicherung (Feder, Zug, Schwungrad) eingesetzt werden. Alternativ dazu kann die Reibung zwischen Korken und Flasche verringert oder der Korken durch Druck aus der Flasche gepresst oder durch Unterdruck angesaugt werden. Je nach Anforderungen der Zielgruppe kann jedes Prinzip mehr oder weniger aufwändig umgesetzt werden: an Material, Design und Preis sind dabei kaum Grenzen gesetzt.

Diese Semideterminiertheit oder Semiteleologie – man weiß nicht, was rauskommt, aber man weiß, was das Ergebnis leisten muss – ist die spannende Anforderung an Entwicklungen. Zielgerichtete Kreativität, verlässli-

1.1 Entwicklung

5

che Spontaneität, kontinuierliche Innovation, kreative Routine, etc. diese Polaritäten machen ein Entwicklungsprojekt erfolgreich und spannend. Entwicklung im hier betrachteten Sinne ist also der Prozess der zielgerichteten Schaffung eines Produktes (Systems) aufgrund von Vorgaben. Diese Entwicklung ist ein schöpferischer Prozess, bei dem auf verschiedenen Stufen Ideen kreativ eingebracht werden und etwas Neues geschaffen wird. Im Bereich Dienstleistung ist durchaus eine Abgrenzung der Entwicklung gegenüber einem beliebigen Projekt notwendig. Sie ergibt sich daraus, dass ein Produkt Objekt eines Vertrags sein kann (Kauf einer Ware, Beauftragung einer Dienstleistung) und damit hinreichend genau beschrieben sein muss. Die eigentliche Leistungserbringung kann durchaus ein Projekt sein, dem aber die Entwicklung vorgelagert ist. Das Ergebnis der Entwicklung ist immer eine exakte Beschreibung des Produkts, an die sich dann die Realisierung (Produktion, Dienstleistungserstellung) anschließt. Anforderungen an das Entwicklungsergebnis kommen also (zumindest) von zwei Seiten: • dem Kunden, der Anforderungen an das Produkt hat, und • den realisierenden Organisationseinheiten (Produktion etc.), die Anforderungen an die Realisierbarkeit des Produkts haben. 1.1.2

Bedeutung Nachhaltige Entwicklung im doppelten Sinne

Die Bedeutung der Entwicklung liegt zum einen im mikroökonomischen Bereich, wo die Firma durch die Produktentwicklung die Basis zur Leistungserstellung legt, zum andern im makroökonomischen, wo Produktentwicklungen die Entwicklung der Volkswirtschaft national und international voranbringt und die Voraussetzung für Wachstum und Nachhaltige Entwicklung ist. Betriebswirtschaftlich Für eine Firma sind Produkte wichtig, da sie die Basis der Wertschöpfung sind. Dies gilt nicht nur für materielle Produkte, die produziert, gelagert, transportiert und verkauft werden, sondern auch für Konzepte und Dienstleistungen. Gerade der Anbieter einer Dienstleistung muss ja diese als Produkt kommunizieren können. Die Produktentwicklung erlaubt es der Firma, für den Kunden attraktive Produkte anzubieten. Der Innovationsprozess liefert regelmäßig die Basis für neue Marktsegmente und neue Wertschöpfung. Ein Unternehmen, das

6

1 Einführung

nicht seine Produkte (bzw. Dienstleistungen oder Kombinationen davon) weiterentwickelt, wird vom Markt verdrängt. Volkswirtschaftlich Inlandsprodukt und Wertschöpfung beruhen auf Produkten – in dem hier betrachteten Sinne, der Güter und Dienstleistungen umfasst. Mit Ausnahme des primären Bereichs werden alle Produkte vorher entwickelt, und selbst im primären Bereich werden zum Beispiel in der Landwirtschaft – nicht erst seit der Entwicklung der Gentechnik – Produkte systematisch durch Züchtung entwickelt. Betrachtet man die wichtigsten Erfindungen so stellt man fest, dass fast alle Produkt eines Entwicklungsprozesses sind, der lange vor dem populär festgelegten Erfindungstermin begann und mit der offiziellen Erfindung in eine bis heute fortwährende Phase fortgesetzter Verbesserungen eintrat. Selbst bei Erfindungen wie dem Buchdruck oder dem Transistor gibt es Vorarbeiten und folgte der Erfindung eine Verbesserung bezüglich vieler Qualitätsmerkmale. Erfindung ist der Startschuss, meist auch der Durchbruch. Der Nutzen für die Wirtschaft und für einzelne Unternehmen kam oft viel später als Folge von vielen Entwicklungsschritten. (Hier ist der Begriff der Entwicklung des Produkts im Sinne von evolutionärer Weiterentwicklung zu sehen, der aber durchaus auf Schritten der Entwicklung im hier betrachteten Sinne basiert.) Die Entwicklung der Menschheit ist geprägt durch Innovationen. Aber nicht die abstrakte Entdeckung und die einmalige Erfindung führten zu den Umwälzungen, mit denen Feuer und Eisen, Dampfkraft und Elektronik ihre Zeitalter geprägt haben. Es war die Flächenwirkung, die von der Weiterentwicklung von Produkten – und meist auch der zugehörigen Infrastruktur – ausging. Elektrizität Elektrizität ist als Phänomen schon lange bekannt. Solange aber die Elektrizität noch eine amüsante Partyunterhaltung war, hatte sie keinerlei Einfluss auf die Geschichte. Erst Entwicklungen wie Telegraph, Generator, Motor und Glühbirne brachten den Stein ins Rollen. Die Entwicklung ging parallel mit der Entwicklung der notwendigen Infrastruktur für die Erzeugung und Verteilung von elektrischem Strom und für die Telekommunikation. Und die Elektronik hat nicht nur selbst ein breites Anwendungsgebiet, sondern brachte auch vielfältige Möglichkeiten, elektrischen Strom einzusetzen. Die auf dem Halbleitereffekt basierende Computertechnik wurde durch die Miniaturisierung in vielen Bereichen selbstverständlich.

1.2 Produkt

7

Nachhaltigkeit Nicht nur Wachstum, sondern auch die Nachhaltige Entwicklung (Sustainable Development) erfordern neue Produkte und Dienstleistungskonzepte. Dabei geht es zum einen um ressourcensparende, umweltfreundliche, erschwingliche und sozial verträgliche Produkte an sich, zum anderen um die Entwicklung von Produkt- und Dienstleistungskonzepten, die den Nutzen in den Vordergrund stellen und gemeinsam mit der zugehörigen Infrastruktur eine Nachhaltige Entwicklung in den Bereichen Ökologie, Ökonomie und Soziales ermöglichen.

1.2 Produkt Produkt ist, was ein Kunde brauchen kann „Das Ergebnis der Entwicklung ist ein neues Produkt“ diese Aussage ist nur insofern hilfreich, als dass sie Entwicklung von Tätigkeiten wie Veranstalten oder Forschen abgrenzt. Der Unterschied zwischen Entwicklung und Produktion liegt darin, dass das Produkt vorher schon fest beschrieben war. 1.2.1

Produkt als Lösung

Was soll nun entwickelt werden? „Wir brauchen eine Lösung.“ Das ist der Ausgangspunkt eines Entwicklungsprojekts. Entweder ausgehend von einem Problem (negativ) oder von einer Vision (positiv): der aktuelle Zustand soll verändert werden, zu entwickeln ist der neue Zustand. Das ist meist mehr als reine Produktentwicklung, es ist eine Strategieentwicklung und Problemlösung, die zu einem Objekt (Produkt) führt. Deshalb sind Entwicklungsprojekte sehr vielfältig. Ob man für einen einzelnen Kunden einen hochspezialisierten Handhabungsroboter entwickelt oder für einen Massenmarkt einen universellen Serviceroboter, spielt im Entwicklungsprozess eine wichtige Rolle. Übergeordnet kann dabei noch die Entwicklung eines neuen Produktionskonzepts (z.B. „Losgröße eins“) oder die Neupositionierung einer Firma (z.B. Erschließung des Marktes „private Kunden“) sein. Die Entwicklung einer Software, die dem Roboter das Sehen und Navigieren erlaubt, einer Hardware, die das Greifen von zerbrechlichen Teilen erlaubt, oder einer Marke, die dem Roboter einen unverwechselbaren Namen gibt, können Teil dieses Problemlösungsprozesses sein. Produkte können Artikel sein, auch eine Dienstleistung oder Reservierung, auch beliebige Kombinationen solcher Produkte sind wieder ein Produkt. Finanzderivate sind z.B. Optionen, d.h. Rechte, ein Produkt später zu einem bestimmten Preis zu kaufen oder zu verkaufen. Die Kombination eines Pro-

8

1 Einführung

dukts (Hardware wie ein Fahrrad oder ein Gebäude, Software, Dienstleistung) mit einer umfassenden Garantie, einer Schulung und einem Wartungsvertrag macht daraus ein neues Produkt. Tabelle 1-2: Produkte (in verschiedenen Konkretisierungsebenen) Aalreuse Bauwerk Buch Dachmarke Erlebniswochenende Finanzprodukt Hardware Interface Legierung Medien Nussknacker Portal Prozesse Risikomanagement Skript Spiel System Veranstaltung Vorlesung Wetterprognose

Anlage Bebauungsplan Buchhaltungssystem Datenbank Event Flugzeug Identifikation Kommunikationsnetz Leitbild Medikament ÖPNV-Konzept Präsentationen Prozessstruktur Seminar Software Sprache Tourismusangebot Verfahren Waage Zeichensystem

Aufzug Behandlungsmethode Buchreihe Dienstleistung Fabrikplanung Forschungskonzept Infrastruktur Konzept Managementsystem Museumskonzept Organisation Produktionsprozess Reparatur Sensor Softwareanpassung Strategie Transportsystem Versicherung Website Zugangskontrolle

Automat Brücke Business-Plan Dissertation Fahrzeug Gerät Ingenieurbau Kühlschrank Marketing-Konzept Netzwerk Plan Programm Reservierungssystem Serviceprodukt Sparplan Studiengang Uhr Videodokumentation Wettbewerb Zytostatikum

Das Ergebnis einer Entwicklung ist im Allgemeinen ein Produkt – allerdings in verschiedenen Konkretisierungen. Die Entwicklung kann das fertige Produkt liefern, aber meist wird ein Produktionsprozess – der auch räumlich und zeitlich sehr variabel sein kann – nachgeschaltet. Das Ergebnis der Entwicklung ist also „nur“ eine exakte Beschreibung des Produkt und zwar eine so exakte Beschreibung, dass die nachgelagerte Realisierung, Produktion, Vervielfältigung oder Umsetzung eindeutig ist. Blueprint Der Begriff Blueprint steht im englischen Sprachraum für das Ergebnis einer Entwicklung: eine Blaupause, die nun als Basis für die Implementierung dienen kann. Im Deutschen müssen wir hier mit Wörtern wie Plan, Konstruktion, Konzept, Produkt vorlieb nehmen, die leider alle mehrdeutig sind.

1.2 Produkt

1.2.2

9

Problemlösung

Der Ausgangspunkt „wir brauchen eine Lösung“ stellt sich meist in der Form „wir haben ein Problem“. Der ganze Prozess der Problemlösung beginnt mit der Entscheidung, sich um dieses Problem zu kümmern. Dazu muss entweder das Problem selbst relevant sein, oder die Problemlösung Vorteile versprechen. Im Standardfall verspricht das als Problemlösung entstehende Produkt einen Vorteil, weil es dafür Nachfrager geben wird. Diese Entscheidung ist der erste Schritt der Entwicklung. Sie wird auf Grund von strategischen Betrachtungen und Kosten-Nutzen-Überlegungen, Gewinnbetrachtungen und Analysen des Produktportfolios getroffen. Machbarkeit, Kapazitäten und Potentiale sowie die Betrachtung von Konkurrenz und Markt spielen ebenfalls eine Rolle. Die Entscheidung kann ganzheitlich oder in mehreren Schritten (Filtern) ablaufen. Die eigentliche Entwicklung beginnt mit der Problemanalyse und einer Systemanalyse des gesamten Problemkomplexes. Die anschließende Anforderungsanalyse beschreibt die Leistungen des Produkts aus Kundensicht. Das Design legt die Eigenschaften des Produkts fest und in der Implementierung und Realisierung wird das Produkt konkret. Auch einfache Produkte können zu vielfältigen Problemlösungen führen und können sich im Laufe der Zeit entwickeln. Hier ist also den vielfältigen Erfindungs- und Entwicklungsprojekten ein Prozess überlagert, in dem sich das Produkt – im anderen Sinne des Wortes – entwickelt. Büroklammer Eine Büroklammer sieht ganz einfach aus und ist auch relativ einfach zu fertigen. Die Entwicklung zu diesem Produkt führte aber über viele Stufen. Heute ist die Vielzahl der angebotenen Produkte unübersehbar. Für die verschiedensten Anforderungen gibt es geeignete Büroklammern in den unterschiedlichsten Preissegmenten. Die Anforderungen an Büroklammern unterscheiden sich bezüglich der Haltefunktion (Festigkeit und Haltbarkeit, Anzahl der Klemmvorgänge, Zahl und Beschaffenheit der zu klammernden Blätter, Schutz des zu klammernden Papiers, Schließkraft), des Materials und der damit verbundenen Oberflächenbeschaffenheit und Korrosionsschutz, des Aussehens und der Gestaltung (Form, Farbe, Größe, Optik, Haptik) und natürlich des Preises.

1.2.3

Produkteinteilung

Um dem Begriff des Produkts in seiner Gesamtheit näher zu kommen, gehen wir aus von Produktbegriff der Norm ISO 9001. Diese unterscheidet

10

1 Einführung

zwischen Hardware, verfahrenstechnischen Produkten, Software und Dienstleistungen. Tabelle 1-3: Produktkategorien nach ISO 9001 Gruppe nach ISO 9001 Hardware Verfahrenstechnische Produkte Software Dienstleistungen

Erklärung Alle individuell identifizierbaren materiellen Produkte Alle kontinuierlichen Produkte: Schüttgüter, Flüssigkeiten, Gase Programme und Organisationsanweisungen, Informationen, Wissen persönliche Dienstleistungen, Konzepte und immaterielle Produkte

Beispiel nach ISO 9000 mechanischer Motor Schmiermittel Rechnerprogramm, Wörterbuch Transport, Event, Lehre

Die folgende Graphik soll die vielfältigen Arten von Produkten klassifizieren. Dabei ist eine Unterscheidung nach materiell und immateriell schnell getroffen, die verschiedenen Produkte haben aber auch einen unterschiedlichen Grad an Realisierbarkeit als „Gut“ im wirtschaftlichen Sinne, das gespeichert oder gelagert werden kann. Gut/Ware Software und Information

Hardware und verfahrenstechnische Produkte

immateriell Dienstleistung

materiell Verfahren Konzept/Prozess

Abbildung 1-2: Produkte Das Produkt muss Objekt eines Vertrags sein können. • Kauf einer Ware (Maschine, Lebensmittel) bzw. • Beauftragung einer Dienstleistung (Veranstaltung, Reparatur, Schulung). Die Bereitstellung des Produkts erfordert dessen Entwicklung und die Befähigung des Herstellers zur Leistungserbringung. Sie besteht in der • Bereitstellung von Infrastruktur für die Leistungserbringung, • Befähigung der Mitarbeiter oder Sicherstellen der nötigen Zuarbeit, • Bereitstellen der benötigten Materialien, Sicherstellen der Versorgung,

1.3 Produktentwicklung

11

• Herstellung oder Beschaffung der notwendigen Vorstufen, • Sicherstellen der Verfügbarkeit von Personal und Material zum Zeitpunkt

der Leistungserbringung. Natürlich sieht diese Befähigung bei einem mehr oder weniger lagerfähigen physischen Produkt (Maschine, Lebensmittel) ganz anders aus als bei einer Dienstleistung (Veranstaltung, Reparatur, Schulung). 1.2.4

Produktlinie

Ein Produkt ist ein genau spezifiziertes Objekt oder eine genau spezifizierte Dienstleistung, die mit einer bestimmten Bezeichnung bzw. Warenummer eindeutig gekennzeichnet ist. Wenn wir im Folgenden von einem Produkt „Handy“ oder „Haarschnitt“ reden, so ist damit eine ganze Produktklasse gemeint. Diese Klasse kann aus verschiedenen Produktlinien bestehen. Produktlinien sind eine Zusammenfassung von ähnlichen Produkten, die unter derselben Bezeichnung (Marke) hergestellt und vertrieben werden und aus Sicht des Kunden eine „Linie“ bilden. Dabei haben die Produkte einer Linie die wesentlichen differenzierenden Merkmale gemeinsam, unterscheiden sich aber in anderen Merkmalen, z.B. in der Größe. Die gemeinsame Verwendung von Teilen, Baugruppen und Elementen kann über die Produktlinie hinausgehen, so können im Rahmen eines Plattformkonzepts wichtige Komponenten in verschiedenen Produktlinien durchaus gleich sein.

1.3 Produktentwicklung Nur Produkte schaffen Werte Die Produktentwicklung ist ein wichtiger Teil des Produktentstehungsprozesses. Das Schlagwort „Time to Market“ charakterisiert die Aufgabe, ein Produkt nicht nur gut, kundengerecht und preiswert zu entwickeln, sondern es auch rechtzeitig auf den Markt zu bringen.

12

1 Einführung

Marketing Problem Idee Technik

Anforderungen

Entwurf

Spezifikation

Produk-

tion

Absatz

Unterstützung, Infrastruktur, Logistik, Beschaffung, Personal

Abbildung 1-3: Entwicklung im betrieblichen Leistungserstellungsprozess 1.3.1 Entwicklungsanstoß

Typischerweise werden Einzelprodukte im Kundenauftrag entwickelt. Eine interne Entwicklung ist an anonymen zukünftigen Kunden orientiert. Sie erfordert Marktforschung als Basis. Die Auftragsentwicklung entwickelt ein Produkt speziell für einen Kunden, daran schließt sich eine Einzel- oder Mengenfertigung an. Produkte für einen anonymen Markt werden typischerweise in Serie gefertigt. Daneben kann natürlich versucht werden, ein für einen einzelnen Kunden entwickeltes Produkt marktfähig zu machen bzw. als Basis einer Entwicklung zu nehmen. Tabelle 1-4: Einzel- und Serienprodukt anonym und kundenspezifisch kundenspezifisch: Kundenauftrag anonym: Marketing-Analyse

Einzelprodukt Anlagenbau, Individualsoftware, Dienstleistung Individualisierte Produkte

Serie Entwicklung für den Produzenten, B2B Massenprodukte, Standardsoftware, B2C

1.3.2 Prozess

Entwicklungsprojekte sind in den Lebenszyklus und den Prozess der kontinuierlichen Verbesserung (KVP) von Produkt und Unternehmen eingebunden. Entwicklung ist ein linearer Prozess, Zyklen kommen durch Iterationen, evolutionäre Entwicklung, Änderungen in Anforderungen und Technologie. Der Prozess der kontinuierlichen Verbesserung erfolgt in mehreren Schritten, die je nach Autor und Schule verschieden benannt werden. Gemeinsam ist ihnen der Wechsel zwischen konzeptionellen Phasen (Planung, Reflektion) und dem Realitätsbezug in beiden Richtungen: Beeinflussung

1.3 Produktentwicklung

13

der Realität (Umsetzung, Implementierung) und Beobachten der Realität (Messen, Prüfen, Analysieren). Das wohl wichtigste Modell ist der PDCA-Zyklus (Deming-Zyklus) plan Planung

do Umsetzung

(re-) act Reaktion

check Überprüfung

Abbildung 1-4: KVP und PDCA Im Rahmen des PDCA-Zyklus werden Projekte initiiert und umgesetzt. Die folgende Grafik verdeutlicht den Zusammenhang von Produktlebenszyklus und Entwicklungszyklus. Sie gibt damit auch den Zusammenhang der zugeordneten Prozesse. Die Analyse im Rahmen des Produktlebenszyklus ist Ausgangspunkt für eine neue Entwicklung, die Ihrerseits in der Einführung des neuen Produkts mündet. Integration

operativer Einsatz

Produktion

Entwicklung Anforderungen

Entwicklungszyklus

Produktlebenszyklus

Initiierung

Überprüfung

Probleme, Verbesserungsmöglichkeiten

Abbildung 1-5: Innovations- und Lebenszyklus 1.3.3

Scope des Begriffs Entwicklung

Der Begriff Entwicklung wird auch in unterschiedlichem Umfang gebraucht. Je nach Branche werden Vorphasen (Anforderungsanalyse) und Abschlussphasen (Test) integriert.

14

1 Einführung

Tabelle 1-5: Verschiedene Begriffe (scope) von Entwicklung Umfang Entwicklung im ganz engen Sinne Entwicklung (Bedarfsgetrieben) Entwicklung (Wissensgetrieben) Entwicklung im weiteren Sinne Entwicklung im weitesten Sinne

Prinzip vom Entwurf zur exakten Produktbeschreibung von der Spezifikation zur exakten Produktbeschreibung von der Idee zur exakten Produktbeschreibung von der Anforderung zum fertigen Produkt vom Problem zur Lösung

Ausgangspunkt Entwurf

typische Ergebnisse Code Zeichnung Prototyp Spezifikation Code Zeichnung Prototyp Idee, Erfindung, Code wissenschaftliche Zeichnung Ergebnisse Prototyp Anforderungen gestestetes Produkt Fertigungsvorgaben Dokumentation Fragestellungen, Problemlösungen, Marktanalysen dokumentierte, eingeführte Produkte

Noch weiter gehen die Phasen, wenn wir den Lebenszyklus von der Grundlagenentwicklung zur Serienreife betrachten: • Grundlagenentwicklung, Machbarkeitsstudie • Demonstrationssystem • Prototyp • Entwicklungsmuster • Produktionsreife • Serienreife 1.3.4

Kundenorientierung

Ein wichtiger Faktor des Unternehmenserfolgs ist die Ausrichtung von Produkten und Dienstleistungen am Kunden und die Integration des Kunden in den Produktentstehungsprozess. Kundenrollen Es gibt für ein Unternehmen in den allerseltensten Fällen „den“ Kunden. Verschiedene Organisationen und Individuen sind Kunden des Unternehmens. Verschiedene Produkte oder Marken werden auf unterschiedlichen Märkten für verschiedene Kundengruppen differenziert. Außerdem gibt es bei einem einzelnen Kaufprozess noch mehrere Kundenrollen wie Bedarfsträger, Kostenträger und Nutzer. Und bei vielen Produkten hat das Unternehmen keinen Kontakt zum Endverbraucher, sondern es sind Weiterverarbeiter oder Handelsunternehmen dazwischengeschaltet.

1.3 Produktentwicklung

15

Qualität In der Entwicklung spielt die Qualitätssicherung eine wichtige Rolle. Viele der beim Projektmanagement genannten Konzepte wie Phaseneinteilungen, Meilensteine, Audits und Reviews, eine strukturierte und fortlaufende Dokumentation sowie die Verifikation und Validierung auch von Zwischenergebnissen sind essentielle Teile des Qualitätssicherungsprozesses. Ganzheitliche Konzepte Ein ganzheitlicher Ansatz unter Einbeziehung ökonomischer und ökologischer Aspekte und möglicher Wechselwirkungen mit endogenen (von außen beeinflussten) Größen ist anzustreben. Dabei sollten nicht nur technische und monetäre Kriterien, sondern je nach Art des Problems auch ökologische (Auswirkungen auf die Umwelt), ergonomische und soziologische (Auswirkungen auf die Beteiligten) Gesichtspunkte berücksichtigt werden. Kunde als Mitarbeiter Bei der Entwicklung spielt der Kunde eine wichtige Rolle. Er macht nicht nur Vorgaben sondern ist auch – persönlich oder über Marktanalysen – als Mitentwickler und Mitentscheider im gesamten Prozess eingebunden. Besonders wichtig ist die Einbindung bei Anforderungsanalyse und Design. Der Kunde übernimmt aber auch im restlichen Produktlebenszyklus wichtige Rollen. Nicht nur als Betreiber und Bediener sondern auch durch die Übernahme von Funktionen wie Montage und Installation, Instandhaltung, Kooperation bei Dienstleistungen, Ersatz und Entsorgung. Diese Aktivitäten des Kunden müssen bei der Entwicklung berücksichtigt werden: teilweise kann eine Aktivität des Kunden umfangreiche Funktionalität im Gerät und Dienstleistung ersetzen, andererseits ist die Übernahme von Bedienerfunktionen durch das Gerät ein Beitrag zu Komfort und Sicherheit. 1.3.5

Innovation, Forschung, Entdeckung

Innovation und Entwicklung, Forschung und Entdeckung sind eng miteinander verbunden. Erkennt man bei einem Forschungsprojekt die Möglichkeit, eine Entdeckung in Form eines Produkts zu nutzen, so geht das Forschungsprojekt in eine Entwicklung über. Entwicklung und Forschung Die Entwicklung ist aber nicht nur dadurch gekennzeichnet, dass sie etwas Neues mit Anwendung wissenschaftlicher Methoden schafft, sondern auch dadurch, dass dies zielgerichtet geschieht. Dies soll der folgende Würfel charakterisieren:

16

1 Einführung

Innovativität Bastelei

Forschung Entdeckung

Spielerei

Entwicklung

Aufbereitung Routine

Wissenschaftlichkeit

Validierung

Ergebnisorientierung

Abbildung 1-6: Entwicklung = Wissenschaft +Innovation + Ergebnis Entwicklung, Erfindung und Entdeckung Eine Entdeckung kann in einen Prozess vieler Entwicklungsschritte eingebunden sein, z.B. um Geräte oder Verfahren zu entwickeln, die für die Entdeckung notwendig sind. Anderseits kann eine Entdeckung Ausgangspunkt von Erfindungen und Entwicklungen sein. Zwischen Erfindungen und Entdeckungen gibt es einen wesentlichen Unterschied: Erfunden wird etwas Neues, entdeckt wird etwas Vorhandenes. Das mag in den Naturwissenschaften und der Technik klar sein: Ein physikalischer Effekt wird entdeckt (Photovoltaischer Effekt), eine erklärende Theorie dazu wird entwickelt und darauf aufbauend kann ein Gerät oder System (Photozelle) entwickelt werden. Mathematische Sätze sind Entdeckungen eines Zusammenhangs, die zugehörigen Theorien und Begriffsbildungen werden entwickelt, darauf aufbauend können Verfahren (z.B. GPS, MP3) entwickelt werden. Auch in anderen Wissenschaften ist die Beobachtung (Entdeckung) realer Phänomene der Ausgangspunkt. Die Entwicklung von Begriffssystemen und Theorien baut darauf auf und kann auch zur Vorhersage neuer Phänomene führen. Der Erfinder oder Entwickler nutzt im Allgemeinen die den Effekt erklärende allgemeingültige Theorie, Anknüpfungspunkt ist aber häufig der spezielle beobachtete (entdeckte) Effekt. Während der Erfinder (erstmalige Umsetzung in ein Produkt) auf einem Effekt aufbauen kann, wird die Theorie die Basis für den Entwickler sein, um das Produkt systematisch zu verbessern.

1.3 Produktentwicklung

1.3.6

17

Teile und Ganzes

Die Produktentwicklung ist häufig strukturiert, sie kann Komponenten oder Teilkonzepte beinhalten. Ein Produkt muss ja nichts homogenes sein, sondern es besteht aus Komponenten und hat unter Umständen weitere Teile, Zubehör, Infrastruktur, Dokumentation und Konzeptionen, die ebenfalls entwickelt werden müssen. Teilprodukte können sein: • eigentliches Produkt und Teile (Komponenten) davon, • Steuerungs- und Bedienungssoftware, • Bedienungseinrichtungen und Schnittstellen, • Sicherheits- und Überwachungseinrichtungen, • Nutzungs-, Betriebs- und Wartungsinfrastruktur, • Dokumentation (für Installation, Betrieb, Wartung), • Verpackung (Transport, Lagerung, Schutz), • Marke, Name und Image des Produkts. Feuerwehrauto Ein Feuerwehrauto ist nicht nur ein Nutzfahrzeug, es ist bei Kindern und Erwachsenen emotional belegt. Komponenten der Entwicklung eines Feuerwehrfahrzeugs • Fahrzeug mit Aufbauten und Bedienungseinrichtungen • Funk, Navigation, Sicherheits- und Überwachungseinrichtungen • Wartungsinfrastruktur und Dokumentation mit Schulung • Infrastruktur: Das Feuerwehrauto hat einen Nutzen, weil für die Feuerwehr eine geeignete Infrastruktur zur Verfügung steht. Meldung, Alarmierung, Personal, Straßen und Wasseranschlüsse sind notwendig.

1.3.7

Entwicklung - Kunst oder Wissenschaft?

Entwicklung ist sicher eine Tätigkeit mit hohem kreativem Anteil, aber auch mit analytischen Komponenten. Sie ist aber im Allgemeinen auch Projekt. Für die Entwicklung bieten sich verschiedene Paradigmen als Muster für das generelle Herangehen an. Je nach Branche, Produkt und Innovationsgrad kann die eine oder andere Analogie durchaus hilfreich sein: • Kunst: Entwicklung ist kreativ und schafft ein neues Produkt. • Wissenschaft: Entwicklung schafft systematisch neues Wissen. • Handwerk: Entwicklung ist individuell. • Manufaktur: Entwicklungen sind ähnlich, aber nie gleich. • Produktion, Fertigung: Ein Ergebnis wird in Schritten erstellt.

18

1 Einführung

1.4 Entwicklungsprojekte Produkte fallen nicht vom Himmel

Die Entwicklung von Software, Hardware, Dienstleistungen und eingebetteten bzw. integrierten Systemen ist ein entscheidender Faktor zum Erfolg von Unternehmen. Geschwindigkeit bei der Markteinführung (Time to Market), Sicherheit, Betriebs- und Wartungskosten und Lebenszykluskosten (LCC = Life Cycle Costs, TCO = Total Cost of Ownership) spielen eine größere Rolle als eine möglichst billige Herstellung oder gar ein sparsames Entwicklungsprojekt. Entwicklung bedeutet immer ein Projekt mit einer kreativen Komponente und einem immateriellen Ergebnis. Der Projektfortschritt lässt sich dabei weder exakt überwachen noch erzwingen. 1.4.1

Entwicklung als Projekt

Ein Projekt ist eine Aufgabe, die innovativ ist, mit begrenzten Ressourcen auskommen muss, und eine Abweichung von den üblichen Organisationsstrukturen erfordert. Entwicklungsprojekte sind klassische Beispiele von Projekten. Wichtig sind hier die Phaseneinteilung und eine Beachtung der frühen Phasen, in denen zunächst die Anforderungen (Requirements) und Systemkonzepte (Spezifikation) festgelegt werden. Ergebnis = Produkt des Entwicklungsprozesses, Qualität bezüglich aller Anforderungen

Ressourcen = Aufwand, vor allem Personalaufwand

Zeit = Termin für die Fertigstellung und Umsetzung

Abbildung 1-7: Magisches Projektdreieck im Entwicklungsprojekt Dabei werden im Entwicklungsprojekt die Weichen für die Zukunft gestellt, und das Projektergebnis hat eine starke Wirkung auf die Gesamtkosten. Generell ist die Auswirkung von Abweichungen im Projektdreieck in Entwicklungsprojekten dadurch gekennzeichnet, dass die Konsequenzen von

1.4 Entwicklungsprojekte

19

Qualitätsmängeln und Zeitverschiebungen überproportional sind gegenüber Kostenüberschreitungen. Da die Entwicklung erst die Basis für das folgende Geschäft (Produktion, Implementierung, Dienstleistung, Event etc.) ist, sind die Folgen von Terminverzögerungen und Qualitätsmängeln extrem. Tabelle 1-6: Exemplarische Konsequenzen bei Projektabweichungen R T

Q

Erhöhung der Entwicklungskosten Verlängerung der Entwicklungsdauer Projektziel verfehlt, schlechtere Qualität

optimistisch direkte Kostenwirkung

pessimistisch Projektabbruch, Konkurs Verzögerung, Ergebnis ist überholt verspäteter Markteintritt, Fehlschlag bei zeitkritiKonventionalstrafe schen Projekten geringerer Ertrag Fehlschlag (Produkt/ Markt), Haftung (zivil-/ strafrechtlich)

Das folgende Beispiel (angelehnt an [Reinertsen]) soll zeigen, wie sich die verschiedenen Fehler auswirken. Dabei können die Konsequenzen von Verzögerungen und Fehlern je nach Markt und Einsatzgebiet beliebig groß werden. 1 Prozent Auf- 1 Prozent Prowandsüberduktkostenschreitung überschreitung

1 Prozent Leistungsdefizit

1 Monat Verspätung bei der Auslieferung/ Markteinführung

1 Fehler, der zu Schäden/ Rückrufaktionen führt

Abbildung 1-8: Einfluss der Projektparameter auf den Lebenszyklusgewinn Dies begründet die hohe Verantwortung und den teilweise hohen Aufmerksamkeitswert, den Entwicklungsprojekte haben. Aufgrund der hohen Sichtbarkeit und leichten Überprüfbarkeit stehen Termine dabei meist im Fokus der Aufmerksamkeit, während Qualität und Kosten schwieriger zu überwachen sind.

20

1.4.2

1 Einführung

Projektmanagement Projekte laufen nicht von selbst

Das Management von Entwicklungsprojekten bietet die Grundlage für den allgemeineren Bereich des Entwicklungsmanagements. Die folgenden Stichworte charakterisieren die Aufgaben des Projektmanagements und werden in den folgenden Kapiteln vertieft: • Projekt und Projektmanagement, magisches Projektdreieck, Phasen, • Rahmenbedingungen, Projektauftrag, Stakeholder, • Kundenforderungen, Requirements, Spezifikation, • Projektstruktur, Arbeitsstrukturplan, Arbeitspakete, Phasenkonzepte, • Projektplanung, Terminplanung, Ressourcenplanung, Schätzung, • Implementierung, Ergebniscontrolling, Validierung, • Projektüberwachung, Projektcontrolling, Arbeitswerte, Projektsteuerung, • Projektlebenszyklus, Änderungsmanagement. 1.4.3

Entwicklungsprojektmanagement

Management von Entwicklungsprojekten muss sicherstellen, dass das angestrebte Ergebnis erzielt und die gestellten Anforderungen an Projekt und Ergebnis erfüllt werden. Der Erfolg von Entwicklungsprojekten zeigt sich erst viel später: wenn das entwickelte Produkt produziert und auf dem Markt eingeführt wird. Ziele bzw. Anforderungen können sein: • Projekt: Termineinhaltung, Kostenobergrenze, Personalobergrenze, • Entwicklungsergebnis: Umsetzbarkeit, Produzierbarkeit, Marktreife, • Endprodukt: Qualität, Kosten, Marktfähigkeit. 1.4.4

Vielfalt der Entwicklungsprojekte

Das Spektrum von Entwicklungsprojekten kann vom systematischen Umsetzen von Anforderungen im Rahmen einer kurzen Besprechung bis zu Entwicklungsprojekten von einem Dutzend Jahren gehen. Auch ohne diese Extremfälle reicht das typische Spektrum von Entwicklungsprojekten über mehrere Zehnerpotenzen in Dauer, Aufwand und Auswirkungen.

1.5 Methoden und Modelle

21

Tabelle 1-7: Spektrum der Entwicklungsprojekte Kriterium: Laufzeit Personen Aufwand Kosten Finanzielle Konsequenzen Anzahl Kunden

1.4.5

Minimal einige Stunden eine Person einige Personenstunden ehrenamtliche Tätigkeit, Papier und Bleistift einige tausend €

Maximal ca. einige Jahre hundert Mitarbeiter hundert Personenjahre einige Millionen €

einer

viele Millionen

beliebig hoch

Entwicklungsmanagement

Die Beziehung zwischen Entwicklung und Management beschränkt sich natürlich nicht nur auf das Management von Entwicklungsprojekten. Weitere Aspekte sind: • Management der Entwicklung, • Management von Entwicklungsbereichen (Abteilungen ...), • Integration der Entwicklung in das gesamte Unternehmen, • Planung des Produktportfolios. Entwicklungsmanagement in einem ganz anderen Sinne ist das Management der Entwicklung der Firma, das aber letztendlich auf der systematischen Entwicklung des Leistungsportfolios beruht.

1.5 Methoden und Modelle So exakt wie möglich, so formal wie nötig.

Die Entwicklung baut auf Modellen auf, die sowohl als Modell des zu entwickelnden Produkts, als auch als Modelle von Einsatzumgebung und Anforderungen eine wichtige Rolle spielen. Die Entwicklung kann man als eine Folge von Modelltransformationen und die Planung als die Modellierung einer zukünftigen Situation betrachten. 1.5.1

Modellbasiertes Problemlösen

Die Lösung von Problemen (Aufgaben, Entscheidungen) mit Hilfe von Modellen spielt im Entwicklungsprozess eine wichtige Rolle.

22

1 Einführung

Produkt

Problem

Modell des Problems

Modell der Anforderungen

Modell des Produkts

Modell der Lösung

Abbildung 1-9: Modellbasiertes Problemlösen Eine Anwendung davon davon ist die Sicht der Entwicklung als Umsetzung (Transformation) von Modellen: konkreteres Modell von Problem/Aufgabe

abstrakteres Modell von Problem/Aufgabe

implementierungsnäheres Modell von Lösung/Produkt

abstrakteres Modell von Lösung/Produkt

Abbildung 1-10: Produktentwicklung und modellbasierte Problemlösung Dabei beinhaltet der Entwicklungsprozess eine Hierarchie von Modellen, Modelltransformationen und Lösungsschritten Eine andere Sicht ist die, dass wir – beispielsweise in den frühen Entwicklungsphasen oder bei der Validierung - anhand des Modells Aussagen über das reale System („die Realität“) erhalten wollen. Das Modell dient dann dazu, eine Aussage über das Modell durch formale Manipulation des Modells zu erhalten. Die Umsetzung in eine Aussage über die Realität benötigt dann wieder den Zusammenhang zwischen Modell und Realität (die Semantik des Modells).

1.5 Methoden und Modelle

Reales System

23

Validierung

Modellbildung Modell des Systems

Eigenschaften des Systems

Interpretation Analyse

Aussagen über das System im Modell

Abbildung 1-11: Modellbasierter Erkenntnisgewinn Diese beiden Sichtweisen von Problemlösung und Erkenntnisgewinn sind einander gleichwertig: man kann die Aussage über das Realsystem als Lösung einer Frage und andererseits die Bestimmung einer Lösung als Aussage über das System betrachten. Entwicklungsmanagement und Modelle Die Entwicklung selbst kann man als eine Reihe von Modelltransformationen sehen, bei denen das Anforderungsmodelle (der vage Wunsch des Kunden) in ein realisierbares Modell (Zeichnung, Computerprogramm) umgesetzt wird. Modelle spielen aber in vielen anderen Bereichen eine Rolle: • Anforderungsanalyse, • Modellierung der Schnittstellen und der Einsatzsituationen, • Alle Arten von Simulation und Methoden der Validierung und Verifikation von Entwicklungsergebnissen, • Modelle des Managements und als Basis der Planung und Steuerung, • Nutzer-, Kunden- und Wirtschaftsmodelle als Basis des Marketing. Modelle sind Basis für • Strukturierung (Strukturfindung, Strukturanalyse, Strukturschaffung), • Kommunikation (Austausch von Informationen über ein Objekt), • Simulation, informelle, formale und mathematische Analyse, • Dokumentation, systematische Ablage, Konfigurationsmanagement, • Verifikation und Validierung, • Planung (ein Plan ist ein Modell der Zukunft). Die Beschreibung von Umgebung und Anforderungen als Basis und die schrittweise Verfeinerung von Entwurfsmodellen sind die essentiellen Punkte jeder Entwicklung.

24

1 Einführung

Da das Ausgangsmodell (Anforderungsmodell, Requirements, Spezifikation) die einzige Schnittstelle zur Realität des Nutzers ist, ist dieses Modell für den Erfolg des Entwicklungsprojekts besonders wichtig. Die Modellierung beginnt mit dem Erfassen (Sammeln, Verstehen) des Problems in einem mentalen (internen) Modell. Die Modelle von Problem, Zustand und Lösung werden nun in geeigneter Form explizit gemacht. Dies kann durch Text, Graphen oder formale Modelle geschehen. Über Spezifikation und Entwurf wird das Modell des Zielsystems (Produkts) immer konkreter bis zur Realisierung. Danach spielen Modelle für das Testen und die Dokumentation weiterhin eine wichtige Rolle. Reservierungssystem Als Beispiel betrachten wir ein Zugangskontroll- und Reservierungssystem beispielsweise für ein Wellness-Bad oder ein Reisebüro. Ein wichtiger Punkt beim Entwurf des Systems sind die Buchungen und Reservierungen, die mit dem System durchgeführt werden: Wesentlich ist die Frage: was sind buchbare Objekte? Was soll reserviert werden können? Was wird reserviert, abgerechnet, bezahlt? Ein weiterer entscheidender Punkt ist der Ablauf der Reservierung und Buchung mit Mehrfachkäufen und Warenkorb, der Identifikation von Käufer und Nutzer (bei Dienstleistungen ein wesentlicher Aspekt) und der Bezahlung.

Modelle im Entwicklungsprozess Für die Entwicklung sind auch noch andere Modelle wichtig: • Phasen und Zyklen, Ablaufmodelle (Phasenmodelle), • Kostenmodelle, Schätzungs- und Prognosemodelle, • Kommunikationsmodelle, • Modellierung der Modellstruktur für Wissens-, Konfigurations- und Dokumentenmanagement. Diese werden wir in den folgenden Kapiteln betrachten, wenn es um den Entwicklungsprozess und die Planung, Organisation und Überwachung von Entwicklungsprojekten geht. Verschiedene Typen von Entwicklung benötigen verschiedene Modelle. Für den Entwickler und den Manager ist es wichtig, die Vielfalt der Modelle zu kennen, um das richtige auszuwählen. 1.5.2 Mathematik

Wenn eine Berechnung, Analyse, Simulation oder Optimierung angestrebt wird, müssen die oben angesprochenen Modelle in mathematische Modelle

1.5 Methoden und Modelle

25

umgesetzt werden, Generell nützt die Mathematik aber immer nur so viel, wie das Modell hergibt. Mathematische Modelle Analytische und algebraische Modelle spielen in der Entwicklung eine zentrale Rolle, da sie universell einsetzbar sind. Die Modelle der Mathematik im engeren Sinne, in denen Zahlen und Formeln vorkommen, können mit den Methoden der Analysis und Algebra, aber auch durch numerische (z.B. die in Tabellenkalkulationsprogrammen enthaltenen Solver) oder experimentelle Verfahren (z.B. Monte-Carlo-Simulation) gelöst werden. Daneben gibt es spezielle mathematische Modelle, die auf Disziplinen wie der Theorie dynamischer Systeme, Graphentheorie, Optimierungs- und Spieltheorie, Stochastik oder Komplexitäts- und Chaostheorie aufbauen. Prozessmodelle Prozesse transformieren eine Eingabe/Vorgabe in eine Ausgabe/Ergebnis. Bei der Prozessmodellierung wollen wir die internen Abläufe beschreiben, dazu verwenden wir eine Abfolge von Funktionen (Prozessen, Aktivitäten) und Ereignissen. Graphen Graphen sind anschauliche aber formal, mathematisch und mit dem Computer einfach zu bearbeitende Modelle. Graphen bestehen aus zwei Arten von Elementen: Knoten und Pfeile. Durch die Bewertung von Knoten oder Pfeilen, im Allgemeinen mit reellen Zahlen, lassen sich verschiedenste reale Zusammenhänge modellieren. Wichtige Beispiele dazu sind Entfernungskarten, Kapazitätsnetzwerke, Netzplantechnik und die quantitative Flussanalyse. Durch qualitative Werte lassen sich Abläufe, Flüsse, Prozesse und viele andere Modelle anschaulich darstellen. 1.5.3

Modellaspekte

Die wichtigsten Aspekte in der Entwicklung sind Prozesse und Produkte. Prozesse Prozesse sind in Technik und Management zentral. Zur Beschreibung dynamischer Abläufe in Organisationen und komplexen Systemen eigenen sich Prozessmodelle eher als die klassischen Methoden wie Differentialgleichungen. Ziel der Prozessmodellierung ist, Abläufe zu beschreiben und transparent zu machen, Schwachstellen aufzudecken und die Abläufe soweit sinnvoll fest-

26

1 Einführung

zulegen bzw. zu automatisieren. Dabei kann es sich um Prozesse in Hardware oder Software, in technischen oder natürlichen Systemen, oder bei der Erstellung von Produkten und Dienstleistungen handeln. In der Prozessmodellierung im Unternehmen werden zunächst diejenigen Prozesse modelliert, die für das Unternehmen am wichtigsten sind, d.h. die einen großen Anteil an der Wertschöpfung haben: Auftragsabwicklung, Leistungserbringung, Produktentwicklung, Marketing und Umweltkontakte. Produkte Die Möglichkeiten, Produkte zu modellieren, sind so vielfältig wie die Produkte und die Modellierungsmethoden. Hier soll keine Liste oder Tabelle aufgebaut werden, die ja immer unvollständig blieben müsste. Es soll einfach daran erinnert werden, dass ein gutes Modell auch die Anregung für neue Methoden oder neue Ansätze sein kann. Ein allgemeines Modell kann durch Änderungen zu anderen Lösungskonzepten oder Produkten führen. Durch eine allgemeinere Sicht kann die Problemlösung auf eine andere Basis gestellt werden oder die vorhandene Technologie zur Lösung anderer Probleme eingesetzt werden.

Tabelle 1-8: Innovationen alte Lösung neue Lösung

altes Problem Verbesserung horizontale Innovation

neues Problem vertikale Innovation Erfindung

Produktion Für eine systematische Produkterstellung muss auch die Produktion beschrieben werden. Dabei geht es vor allem und die Prozesse und Abläufe. Im Laufe der Entwicklung, der Test, der Produktionsvorlaufphase und der Produktion werden die Vorgaben für die Abläufe detaillierter und exakter. Im Laufe der Produktion ergibt sich durch die Lerneffekte eine Verbesserung der Prozesse. Entwicklung Die Beschreibung des Entwicklungsprozesses ist die Basis für die systematische Durchführung. Dazu dienen die Vorgehensmodelle und Prozessmodelle und die Modelle des Kapitels „Entwicklung als Projekt“. Die Zusammenhänge und Schnittstellen zwischen Bereichen und Aufgaben werden wir in den folgenden Kapiteln beschreiben und modellieren.

1.6 Ziel und Nutzung

27

1.6 Ziel und Nutzung Produktnutzen aus diesem Buch 1.6.1

Ziele des Buchs

Dieses Buch will einen Leitfaden für das Entwicklungsmanagement geben, auch für solche Projekte, in denen sich ein umfangreiches Projektmanagement mit dediziertem Projektmanager nicht lohnt, die aber zur erfolgreichen Durchführung die Methoden des Engineering und des Projektmanagements in ihren Grundzügen benötigen. Für größere Projekte sind umfangreichere Maßnahmen des Projektmanagements notwendig, die Grundprinzipien bleiben aber dieselben. Alle klassischen Bereiche von Management und Technik, für die es schon Dutzende von Büchern gibt, wurden konsequent ausgeblendet, da ein Leitfaden für das Entwicklungsmanagement sonst mehrere tausend Seiten umfassen würde. Das Buch will eine Hilfe für diejenigen Entwickler sein, die es manchmal zu spät merken, dass sie Hardware, Software oder Konzepte entwickeln, und die keine Zeit für ein umfangreiches Kursprogramm in Engineering und Projektmanagement haben. Es soll vor allem denjenigen helfen, die als Ingenieure, Kaufleute oder Techniker plötzlich vor der Aufgabe stehen, ein Entwicklungsteam zu leiten, und in kurzer Zeit („möglichst gestern“) ein neues, innovatives, preisgünstiges, marktgerechtes, bekanntes, fehlerfreies, sicheres, umweltfreundliches, ressourcensparendes, benutzerfreundliches, zum Spektrum der Firma passendes dem Stand der Technik entsprechendes Produkt entwickeln sollen. Das Buch soll nicht zuletzt eine Überlebenshilfe für alle Unternehmen sein, in denen Produkte entwickelt werden. Nicht nur für die Softwareschmieden und Maschinenbauer, die schon erkannt haben, welche bedeutende Rolle die Entwicklung für Innovation und Fortbestand ihrer Unternehmen spielen; sondern vor allem für diejenigen, bei denen die Entwicklung im fast noch überschaubaren Rahmen stattfindet, und nicht zuletzt auch für die Zukunftssparten von den intelligenten Systemen bis hin zu Dienstleistungen in ihren verschiedensten Ausprägungen. Die Entwicklung von Konzepten und vermittelbaren Produkten wird in allen Bereichen immer wichtiger. Nur wenn die Methoden des Entwicklungsmanagements auch bei kleinen Projekten im sinnvollen Umfang eingesetzt werden, ist die Zeit, die in solche Aufgaben investiert wird, sinnvoll eingesetzt.

28

1.6.2

1 Einführung

Zielgruppen

Das Buch wendet sich an alle, die ein Interesse daran haben, dass in ihrem Einflussbereich bessere Produkte oder Konzepte schneller und sicherer entwickelt werden. Damit sind die Entwickler und Manager, aber auch alle Stakeholder gemeint, die von der Entwicklung profitieren: • Projektleiter, Projekt- und Arbeitspaketverantwortliche, • Geschäftsführer, Entwicklungsleiter und andere Führungskräfte, • Leiter und Mitarbeiter von Teams mit Entwicklungsaufgaben: Entwicklungsteams, Konzeptteams, Strukturgruppen, und ähnlichem, • Marketingabteilungen und alle, die vom Entwicklungsergebnis betroffen sind und zu dessen Erfolg beitragen möchten, wie Vertrieb und Einkauf, • Firmen als Entwicklungsleitfaden oder Projektmanagementhandbuch, • Unternehmensberater und Dozenten mit Themen wie Marketing, Innovation, Strategie, Technik, Qualität, Projekt- und Prozessmanagement, • Schüler, Studenten, Wissenschaftler und ihre Betreuer, • alle, die Produkte oder Konzepte entwickeln oder ändern, • alle, die in ihrem Aufgabenbereich bessere Ergebnisse sicherer erzielen wollen. 1.6.3

Scope

Das Spektrum von Entwicklungsprojekten kann wie besprochen vom systematischen Umsetzen von Anforderungen im Rahmen einer kurzen Besprechung bis zu Entwicklungsprojekten von einem Dutzend Jahren gehen. Die Vielfalt der Produkte wurde bereits angesprochen und soll hier noch einmal visualisiert werden: Materielle Produkte Verfahren Hardware Medien

Immaterielle Produkte Konzepte

Infrastruktur Systeme

Software

Modelle

Dienstleistungen

Abbildung 1-12: Vielfalt der Produkte 1.6.4

Aufbau des Buches

Das Buch ist nach Phasen und Aufgaben aufgebaut, nicht nach des Arten der Entwicklung. Wer für spezielle Arten der Entwicklung oder spezielle

1.6 Ziel und Nutzung

29

Anwendungsbereiche Hinweise sucht, sei auf das vorletzte Kapitel und die Beispiele verwiesen. Die Kapitel über Produkt-Entwicklung und Projektmanagement stellen die jeweiligen Grundlagen bereit, danach wird gezeigt, wie Entwicklung als Projekt abläuft. Zentral ist das Kapitel Entwicklungs-Management, in dem nicht nur die Leitung von Entwicklungsprojekten sondern alle Managementaspekte der Entwicklung und ihrer Einbettung in den Produktentstehungsprozess betrachtet werden. Das Kapitel über „Spezielle Bereiche“ geht nicht nur auf die produktspezifischen Eigenschaften der wichtigsten Produktentwicklungen ein, sondern gibt auch weitere Beispiele. Dem Leser werden auch Erfahrungen und Fehler aus anderen Produktbereichen durchaus Anregungen geben. Das Kapitel Methoden und Modelle schließt mit grundlegenden Darstellungen das Ganze ab. Tabelle 1-9: Aufbau und Leitfragen 1 2 3 4 5 6 7

Kapitel Einführung Produktentwicklung Projektmanagement Entwicklung als Projekt Entwicklungs-Management Spezielle Bereiche Methoden und Modelle

1.6.5

Kernfrage Um was geht’s? Wie wird ein Produkt entwickelt? Wie wird ein Prozess oder Projekt geleitet? Wie läuft eine Produktentwicklung ab? Wie leitet man eine Entwicklung? Was ist bei speziellen Produkten zu beachten? Wie wird ein Produkt oder Prozess beschrieben?

Nutzungshinweise

Sie können dieses Buch natürlich von der ersten bis zur letzten Seite lesen. Aber je nachdem, aus welchem Interesse oder aufgrund welcher Probleme Sie das Buch lesen und wie viel Zeit Sie investieren wollen, sind bestimmte Teile für Sie wichtig: • als Projektleiter oder Produktverantwortlicher, • als CEO, Entwicklungs-Leiter, Marketing- oder Vertriebsleiter, • wenn Sie ein Entwicklungsprojekt starten wollen, • als Entwickler in einem Projekt, • im Rahmen einer Vorlesung Entwicklungsmanagement Die Kapitel Entwicklung (Grundlagen der Produktentwicklung und Entwicklung als Projekt) und Projektmanagement liefern die Basis für das zentrale Kapitel Management von Entwicklungsprojekten. Die projektübergreifenden Aspekte sind auch für den Projektleiter unverzichtbar, da sie für ihn die Rahmenbedingungen liefern.

30

1 Einführung

Die Fallstudien beleuchten einzelne Punkte. Sie sind teils als Analogien und Metaphern, teils aber auch als konkrete Beispiele ausgelegt. Die Grundideen und Probleme des Entwicklungsmanagements sind in allen Bereichen ähnlich, lassen sich aber an Beispielen anschaulich darstellen und übertragen. (Die Fähigkeit zu Abstraktion und Analogie ist ja für Entwickler und Manager gleichermaßen wichtig.). Das Kapitel „Spezielle Bereiche“ stellt eine Fallsammlung von spezifischen Punkten dar. Als Entwicklungsmanager kann man auch von Ideen, Erfahrungen und Fehlern aus anderen Bereichen lernen. Empfohlene Vorgehensweisen, auch im Sinne eines Kurses, sind durch die Pfade beschrieben. Dabei gehen wir von zwei Schwerpunkten aus: der Arbeit im Projekt (als Projektleiter, Mitarbeiter, Teilverantwortliche) oder die Aufgaben in der Linie (als Entwicklungsleiter und in allen Bereichen mit Schnittstellen zur Entwicklung). Wer schon Erfahrungen hat, kann die entsprechenden Teile überfliegen. Das Kapitel Methoden kann als Grundlage oder zur Vertiefung vor der praktischen Umsetzung verwendet werden. Einleitung Methoden und Modelle Entwicklung Projektmanagement Entwicklungsprojekte Entwicklungs-Projekt-Management Entwicklungsmanagement spezielle Produkt-Typen Methoden und Modelle Projektaufgaben Start des eigenen Entwicklungs-Projekts

Abbildung 1-13: Vorgehensweisen

Linienaufgaben, Aufbau des eigenen Entwicklungsteams/-unternehmens

2

Produktentwicklung Wie kommt man zu einem Produkt?

Basis des erfolgreichen Entwicklungsmanagements ist das Verständnis für die Entwicklung von Produkten auf einem hinreichenden Abstraktionsniveau. In diesem Kapitel betrachten wir die Entwicklung eines Produkts von der fachlichen und inhaltlichen Seite. Dazu müssen wir uns zunächst mit dem Produkt selbst beschäftigen und mit den Gründen, das Produkt zu entwickeln: der Problemlösung und dem Kunden. Das fachliche Vorgehen und dessen Grundlagen, der Stand der Wissenschaft, Know-How und Engineering bilden den Kern des Entwicklungsprozesses. Da jede Entwicklung auf Modellen beruht, ist für dieses Kapitel das Thema Modelle als Basis oder Ergänzung sinnvoll. Modelle sind für die Abbildung verschiedener Objekte wichtig, sie bilden ab: • das Gesamtsystem, in das das Produkt eingebettet ist, • das Gesamtproblem, für das das Produkt eine Lösung darstellt, • die Umgebung des Produkts als Basis für Anforderungen und Test, • die Anforderungen an das zu entwickelnde Produkt, • das zu entwickelnde Produkt auf den verschiedenen Entwicklungsstufen: Spezifikation, Entwurf, Implementierung, Test, • die Erstellung (Produktion, Implementierung, Installation) des Produkts und die Erbringung der Leistung beim Kunden. Entwicklung ist im Untenehmen die Umsetzung der Möglichkeiten (aus der Technologie, Forschung) in Produkte, die vom Markt nachgefragt werden. Technologie (Befähiger)

Entwicklung

Markt (Nachfrage)

Abbildung 2-1: Einbettung der Entwicklung Im Folgenden geht es um die eher statischen Aspekte und Methoden. Entwicklung ist aber immer ein Fortschreiten, so dass die Vorgehensweisen (Projekt, Prozess) schon hier mit aufscheinen.

32

2 Produktentwicklung

2.1 Produkt Ein Produkt soll ein Problem lösen

Produkt ist alles, was das Unternehmen (Lieferant) bearbeitet, und der Kunde braucht. Dies können physische Objekte (materiell), Informationen oder Dienstleistungen (immateriell) sein. 2.1.1

Produkt und Problemlösung

Das Produkt wird von einem Kunden genutzt, weil er einen Vorteil (Nutzen) davon hat bzw. weil durch das Produkt ein Problem für ihn gelöst wird. Produktklassen Ein Produkt ist ganz generell ein Ergebnis einer Tätigkeit oder eines Prozesses. Außerdem kann ein Prozess neben den beabsichtigten Produkten auch unbeabsichtigte (und häufig unerwünschte) Ergebnisse (Koppelprodukte, Abfall, Nebenerscheinungen) haben. Produkte können sein: • materielle Produkte wie − Hardware (individuell identifizierbare Stücke, assembled products), − verfahrenstechnische Produkte (mengenmäßig erfassbare Produkte), • immaterielle Produkte wie − Software, Daten, Entwürfe, Wissen, − Dienstleistungen, • oder Kombinationen davon. Beispiele aus dem breiten Spektrum der möglichen Produkte sind:

Tabelle 2-1: Produkte Bereich Hardware (identifizierbare physische Produkte) Mengengüter Software Systemanpassung Infrastruktur Dienstleistungen Immaterielle Produkte Konzepte Verfahren

Beispiele Geräte, Maschinen, Mechatronik, Systeme, Bauwerke, Nahrungsmittel, Fahrzeuge Chemikalien, Schüttgüter, Flüssigkeiten, Teig Programme, Datenbanken, Lexika Customizing, Systemeinführung Netzwerk, Transportsystem Finanzprodukt, Serviceprodukte Event, Veranstaltung, Forschung Strategie, Plan, Marketing-Konzept Produktion, Organisation, Managementsysteme

2.1 Produkt

33

Anforderungen und Ergebnisse Eine Anforderung (Requirement) ist eine Fähigkeit, die das Produkt haben soll oder muss. Im Allgemeinen wird dies in eine oder mehrere Eigenschaften des Produkts übersetzt. Die jeweilige Fähigkeit ist eine Eigenschaft des Produkts in seiner Umgebung, sie kann als eine mögliche Reaktion des Produkts auf seine Umwelt beschrieben werden. Einfache Eigenschaften (Farbe, Gewicht, Länge) sind durch Messprozesse wohl definiert. Komplexere Eigenschaften müssen entsprechend beschrieben werden. Anforderungen an ein Produkt oder eine Problemlösung können von verschiedenen interessierten Parteien kommen. Wenn wir also im Folgenden vom Kunden sprechen, so sind damit meist implizit auch alle Anspruchsgruppen (Stakeholder) gemeint. Problemlösung und Nutzen Ein wichtiger Begriff im Zusammenhang mit Entwicklung und Qualität ist die Anforderung. Sie ist Ausgangspunkt und Erfolgskriterium der Entwicklung. Anforderungen an Produkte entstehen dadurch, dass das Produkt einen bestimmten Nutzen bringen soll. Der Bedarf entsteht dadurch, dass das Nichtvorhandensein des Nutzens ein Problem (zumindest einen weniger befriedigenden Zustand) darstellt. Das allerwichtigste an der Entwicklung ist die Erfassung des Nutzens für den Kunden. Unabhängig davon, ob wir von der Seite der Problemlösung („hier ist das Problem – wie kann ich es mit einem Produkt lösen“) oder der Seite des vorhandenen Produkt („hier ist das Produkt, wer hat das dazu passende Problem?“) kommen, muss das Produkt, um erfolgreich zu sein, für den Käufer des Nuten bringen. Es muss ein für ihn hinreichend wichtiges Problem lösen. Dabei ist eine ganzheitliche Sicht notwendig. Personenaufzug Die Idee der Problemlösung wird durch folgendes Beispiel deutlich: In einem Hochhaus häufen sich die Klagen über lange Wartezeiten vor dem Aufzug (Fahrstuhl). Die erste Idee ist, einen dritten Aufzug parallel zu den vorhandenen einzubauen, um damit die Kapazitätsengpässe zu überwinden. Das dies mit sehr hohen Kosten verbunden ist, kommt die zweite Idee der Modifikation der Steuerung, um mit einer intelligenten Steuerung die Wartzeiten zu verkürzen. Eine Analyse soll zeigen, wie lange die Wartezeiten sind. Das Ergebnis ist, dass nicht die objektiv verlorene Zeit, sondern die subjektive Langeweile beim Warten das Problem ist.

34

2 Produktentwicklung

Daraufhin werden vor den Aufzügen Spiegel angebracht, so dass die Wartenden ihre Garderobe in Ordnung bringen und damit die Wartezeit sinnvoll nutzen konnten. Schlagartig hören die Beschwerden auf. Durch Optimierung und intelligente Systeme (z.B. Berücksichtigung des – unter Umständen zeitabhängigen – Benutzungsverhaltens) lassen sich die Wartezeiten wirklich effizient reduzieren. Das Beispiel soll aber zeigen, dass auch unkonventionelle Lösungen und weiche Faktoren eine wichtige Rolle spielen.

Lebenszykluskosten und Nutzen Die Lebenszykluskosten LCC des Produkts sind ein wichtiges Entscheidungskriterium für den Kunden und das wichtigste Argument für qualitativ hochwertige Produkte. Das Hauptproblem bei der Bestimmung absoluter Werte ist die Abgrenzung. Die "richtige" Abgrenzung ist aber für den Vergleich nicht so entscheidend wie die Konsistenz. Analog dazu sollte man den Lebenszyklusnutzen eines Produkts betrachten. 2.1.2

Kunde

Den „typischen“ Kunden gibt es nicht. Kunden sind Individuen. Verschiedene Personen (und Institutionen) spielen als Kunden verschiedene Rollen. Arten Kunden können auf verschiedene Art in den Entwicklungsprozess eingebunden sein. Je nach Produkt treten die Kunden vor oder nach der Entwicklung in Erscheinung, im zweiten Fall müssen Anforderungen von einem „internen Kunden“ kommen. Sie spielen auch als Kunde verschiedene Rollen, als Geldgeber oder Nutzer des Produkts oder des Entwicklungsergebnisses, und sind entsprechen in der Entwicklung zu berücksichtigen. Je nachdem, ob eine Entwicklung vom einzelnen Endkunden, einem vorhandenen Markt oder von den vorhandenen technischen Möglichkeiten initiiert und getrieben wird, bezeichnet man die Entwicklung als • Kundenbezogen: Der Kunde beauftragt die Entwicklung. • Marktbezogen: Die Entwicklung geschieht in Erwartung eines Absatzmarktes, der Markt kann aktuell vorhanden oder potentiell – d.h. durch das Produkt und die Marketing-Aktivitäten zu schaffend – sein. • Technologiegetrieben: Eine neue Technologie erlaubt die Entwicklung neuer Produkte. Damit eine Entwicklung zu einem Erfolg führt, muss natürlich sowohl ein Markt (aktuell, potentiell oder individuelle) als auch die notwendige Technologie (als vorhandener Stand der Technik oder als Ergebnis der Forschung) vorhanden sein.

2.1 Produkt

35

Der Ablauf und die Wechselwirkung mit dem Kunden ist dabei unterschiedlich: Den Standardablauf Kundenproblem – Entwicklung – Lösung haben wir bereits kennen gelernt. Kunde hat ein Problem

Produkt als Problemlösung

Kunde braucht das Produkt

Lieferant entwickelt ein Produkt

Lieferant produziert ein Produkt

Abbildung 2-2: Kundenbezogene Entwicklung Falls es keinen individuellen Kunden gibt, muss das Marketing die Anforderungen des Marktes formulieren. Lieferant entwickelt ein Produkt

Lieferant produziert ein Produkt

Marketing

Vertriebskanäle

Markt: anonymer Bedarf

Kunde: Individuum

Abbildung 2-3: Marktbezogene Entwicklung Falls die Entwicklung von den Potentialen des Unternehmens ausgeht, besteht die Aufgabe des Marketing daraus, den Markt für das noch nicht existierende Produkt zu analysieren. F&E: neue Möglichkeiten

Lieferant entwickelt Produkt Marketing

Markt: Akzeptanz

Lieferant produziert Produkt Vertriebskanäle

Kunde: Bedarf

Abbildung 2-4: Technologiegetriebene Entwicklung

36

2 Produktentwicklung

Kunde

Vertrieb

Produktion

Entwicklung

Marketing

Kunde

Die Einbindung des Kunden geschieht also auf verschiedene Arten. Im Idealfall werden aber immer seine Wünsche und Anforderungen durch das Marketing aufgenommen und durch das fertige Produkt erfüllt.

Abbildung 2-5: Kunde und Entwicklungsprozess Rollen des Kunden Wenn es um Absatz, Umsatz, Qualität, Produktnutzen, Wertschöpfung oder Verkaufsstrategie geht, müssen wir diese über den Kunden des jeweiligen Produkts definieren. Dies betrifft materielle und immaterielle Güter und Dienstleitungen. Dazu ist es notwendig, sich mit dem Begriff Kunde auseinander zusetzen, um nicht Überlegungen in die falsche Richtung anzustellen. Dies ist insbesondere dort wichtig, wo wir uns über neue Konzepte Gedanken machen. Bezüglich zweier Aspekte müssen wir das einfache Konzept eines Kunden differenzieren: 1. bezüglich der verschiedenen Rollen beim Kaufprozess und der Kaufentscheidung, 2. bezüglich der verschiedenen Stufen bei der Nutzung und Weitergabe des Produkts. Der Spruch "der Wurm muss dem Fisch schmecken, aber nicht dem Angler" ist zwar - aus Sicht des Anglers - richtig, aber der Angler trifft die Kaufentscheidung. Aus Sicht eines Händlers für Angelköder stellt sich die Sache also etwas komplexer dar: „der Köder muss den Angler überzeugen“. Bezüglich der Rollen können wir unterscheiden: • Bedarfsträger: Das Produkt ist für die Erfüllung seiner Aufgaben notwendig, er hat den letztendlichen (mittelbaren) Vorteil aus dem Einsatz. Er initiiert den Kauf und will, dass das Produkt beschafft wird. • Entscheider: Er fällt die Entscheidung ob und was (auch bei wem) gekauft wird. Dabei kann die Entscheidung, was bei wem beschafft wird, delegiert werden. • Kostenträger: Er trägt die Kostenverantwortung für die Beschaffung des Produkts. Er bzw. seine Kostenstelle bezahlt das Produkt.

2.1 Produkt

37

• Einkäufer: Er führt den unmittelbaren Einkauf (kaufmännische und

juristische Handlungen) durch. • Nutzer: Er nutzt das Produkt, d.h. hat einen unmittelbaren Vorteil aus

dessen Einsatz. • Bediener: Er setzt das Produkt unmittelbar ein, d.h. er hat Kontakt mit

dem Produkt und bearbeitet es. Er sorgt dafür, dass der durch den Kauf des Produkts angestrebte Nutzen erreicht wird. • Unterstützer: Er sorgt für den notwendigen Voraussetzungen und Rahmenbedingungen (Organisation, Ressourcen, Infrastruktur, Installation, Betrieb, Wartung) für den Einsatz des Produkts. • Objekt: Im Falle einer Dienstleistung steht das Objekt der Dienstleistung im Mittelpunkt des Leistungserbringungsprozesses. Das Objekt kann eine Person sein (beispielsweise beim Arzt oder Friseur, als Teilnehmer einer Veranstaltung, in Bildung und Training, als Objekt einer Sicherheitsüberwachung), aber ebenso ein Lebewesen oder ein materielles oder immaterielles Gut. Diese Rollen treten typischerweise innerhalb der kaufenden Organisation auf und werden durch Stellen, Organisationen oder Personen wahrgenommen. Selbstverständlich können mehrere Rollen durch dieselbe Person ausgefüllt werden, beispielsweise wenn Sie Hunger bekommen, in die Bäckerei gehen und von eigenem Geld eine Semmel kaufen, die Sie sofort selbst verzehren. Die Ansprüche und Erwartungen der unterschiedlichen Personen sind im Allgemeinen verschieden. Dies ist beim Marketing zu berücksichtigen. Das folgende Beispiel soll die verschiedenen Rollen des Kunden bei einem Kauf verdeutlichen. Kundenrollen beim Kinderbuch Die Mutter B (Bedarfsträger) möchte, dass das Kind N (Nutzer) etwas über die heimischen Pflanzen erfährt. Opa K (Kostenträger) möchte seinem Enkel das Buch schenken und schickt seine Nichte E (Einkäufer, Entscheider) in den Laden, um ein Buch über heimische Pflanzen zu kaufen, das Geld dazu gibt er ihr mit. E bringt K das Buch, das N dann zum Geburtstag bekommt, und das der Vater D (Bediener) dem Kind dann vorliest. Alle Beteiligten haben andere Ansprüche an das Produkt: B: Das Buch soll informativ sein. N soll die heimischen Pflanzen kennenlernen, damit es mehr Freude an Spaziergängen und am Naturkundeunterricht hat. B möchte sich auch selbst über Heilpflanzen informieren. N: Das Buch soll interessant sein. Es soll auch die Nutzung der Pflanzen als Nahrungsmittel erklären. Die Bilder sollen so sein, dass man sie für die Freunde fotokopieren kann.

38

2 Produktentwicklung

K: Das Buch soll repräsentativ sein und Zeichnungen der Pflanzen enthalten. Das Kind und die Eltern sollen sich über das Buch freuen. E: Das Buch soll K, der sie beauftragt hat, gefallen. Außerdem muss das Geld, das ihr K gegeben hat, für das Buch reichen, vom Rest darf E sich ein Taschenbuch kaufen. E findet, dass das Buch auch Bäume enthalten sollte. D: Das Buch soll interessant zu lesen sein und auch die wissenschaftlichen Bezeichnungen enthalten.

Eine weitere wichtige Unterscheidung ist die zwischen dem direkten Kunden und dem Endverbraucher. Wie im Beispiel von Angler und Fisch haben Zwischenhändler und Veredler andere Prioritäten. Regionenmarke Bei der Entwicklung einer Regionenmarke sind zwei Gruppen von Kunden zu berücksichtigen: • direkte Kunden sind die Zeichennutzer, die das Zeichen für ihre Produkte nutzen (im einfachsten Fall das Label auf ihren Produkten anbringen). Durch den Imagenutzen der Marke wollen sie eine Erhöhung von Absatz oder Preis. • Endkunden sind die Verbraucher, die Produkte der Regionenmarke kaufen (im einfachsten Fall die Produkte mit dem Label einkaufen). Für sie ist wichtig, dass die Marke Qualitätskriterien zusagt und einhält.

Produktnutzen - das was der Kunde will Qualität ist Erfüllung der Erwartungen des Kunden. Dazu gehört zunächst einmal die Abwesenheit von Fehlern bzw. Abweichungen (defensive Definition von Qualität). Darüber hinaus muss der maximale Produktnutzen für den Kunden erreicht werden (offensive Definition von Qualität). Bezüglich des Produktnutzens unterscheiden wir Primär- und Sekundärnutzen: • Primärnutzen oder Grundnutzen eines Produkts ist die eigentliche Funktion, die ein Produkt zu erfüllen hat. • Sekundärnutzen oder Zusatznutzen eines Produkts sind alle Effekte, die zwar gewünscht, aber nicht Primärnutzen sind. Der Primärnutzen ist derjenige Nutzen für den das Produkt entworfen wurde und durch das es ein bestimmtes Bedürfnis erfüllt. Sekundärnutzen kann sein: • Weitere mögliche Nutzung des Produkts (z.B. im Privatbereich). • Prestige (Kauf einer Luxusmarke) oder Sicherheit. • Reduktion von Umweltbelastungen oder sozialen Effekten durch das Produkt oder den Produktionsprozess. • Demonstration von bestimmten Haltungen oder Meinungen (Kauf oder Boykott bestimmter Marken, Stand der Technik).

2.1 Produkt

39

• Demonstration von sozialen oder ökologischen Einstellungen (Kauf ein-

heimischer Marken, von Gütern aus fairem Handel oder aus umweltfreundlicher Produktion). Bei der Kaufentscheidung spielen sowohl Primär- als auch Sekundärnutzen eine Rolle: Während der Primärnutzen bei der Entscheidung maßgebend ist, ob ein Kauf getätigt wird, ist der Sekundärnutzen meist für die Kaufentscheidung und die Auswahl von Marke oder Typ maßgebend. Mobiltelefon (Handy) Primär dient ein Telefon der Kommunikation. Der Nutzen besteht darin, mit anderen Personen in Kontakt treten zu können (aktiv anrufen oder passiv angerufen werden). Funktionen, die dies unterstützen sind z.B. integrierte Adressbücher oder Kalender. Die Kommunikation wird beim Handy auch durch die Textübertragung (SMS) übernommen, wobei dieser Sekundärnutzen SMS teilweise zum Primärnutzen wurde. Für die Nutzung sind die zur Verfügung stehenden Dienste und die vorhandene Infrastruktur Voraussetzungen. Daneben kann ein schnurloses Telefon als Modeartikel oder Innovation für das Image wichtig sein. Es kann auch andere Funktionen beinhalten wie Uhr, Wecker, Spiele, Navigation, Dokumentation, Rechner und Funktionen eines Computers.

Stakeholder Der Begriff Stakeholder beschreibt alle Anspruchsgruppen, d.h. alle Individuen, Organisationen oder Gruppen, die Ansprüche irgendwelcher Form an die Unternehmung haben. Die Stakeholder sind eine sehr ausgedehnte Gruppe, letztendlich haben alle gesellschaftlichen Gruppen und alle Individuen einen Anspruch auf Einhaltung normativer Regeln und Sicherheit vor Risiken. Event Bei einem Event gib es die vielfältigsten Anspruchsgruppen. Neben den eigentlichen Kunden, den zahlenden Besuchern und VIP, spielen Zaungäste und Presse eine Rolle. Verwaltung und Ordnungsamt, Polizei und Anwohner stellen Restriktionen an die Umweltbelastung durch Verkehr, Müll und Lärm. Die Sponsoren wollen wahrgenommen werden und vom positiven Image der Veranstaltung profitieren. Je nach Art der Musik können sich gesellschaftliche Gruppen durch das Auftreten oder die Texte gestört fühlen. Je nach Art der Anreise sind auch die Träger des ÖPNV und die Anbieter und Nutzer überregionaler Verkehrsverbindungen vom Event betroffen (Stau).

40

2 Produktentwicklung

Infrastruktur In vielen Fällen braucht der Nutzer zum Produkt auch eine Infrastruktur um das Produkt nutzen zu können. Dazu kann die Versorgung mit Energie, Roh-, Hilfs- und Betriebsstoffen oder mit Informationen gehören. Andere Produkte brauchen zum Einsatz Wege oder andere Transportmöglichkeiten oder begleitende Dienstleistungen. Zwischen Produkt und Infrastruktur gibt es vielfältige Wechselwirkung, die durch die ökologische Prinzipien der Koevolution beschrieben werden können. Dabei kann sich ein System durchaus im Sinne der Chaostheorie in die eine oder andere Richtung bewegen, so dass auch hier Prognosen sehr schlecht möglich sind (insbesondere wenn konkurrierende Systeme teilweise gemeinsamen und teilweise konkurrierenden Infrastrukturen nutzen).

Tabelle 2-2: Beispiel zu Produkt und Infrastruktur Produkt Elektrogerät PKW/LKW Omnibus/Straßenbahn/Bahn Mobiltelefon (Handy) Finanzdienstleistungen Tourismus

Infrastruktur Elektrisches Stromnetz Straßennetz ÖPNV-Netz (das z.T. das Straßennetz nutzt) Mobilfunknetz, Dienste Vertriebsstruktur (Filialnetz, Call-Center, Internet) Touristische Infrastruktur

Die soziale Akzeptanz eines Produkts und der zugehörigen Infrastruktur wird stark durch den Produktnutzen (für Individuum und Gesellschaft) und die Kosten der Infrastruktur (für die Gesellschaft und Betroffene) beeinflusst. Dabei spielt die Kommunikation von Risiken und Nutzen eine wichtige Rolle. Gesellschaftliche Probleme und der Bedarf nach normativ-ethischen Entscheidungen ergeben sich dann, wenn bei Nutzergruppe und Betroffene unterschiedlich sind (Mobilfunk, Straßenbau) oder die individuellen Nutzer sich nicht für die kollektiven Auswirkungen (Ressourcenverbrauch, Emissionen) verantwortlich fühlen 2.1.3

Markt und Marketing Produkte brauchen Kunden

Entwicklung hat immer einen – wenn auch anonymen – Kunden im Auge. Die klassischen Überlegungen zu Absatzmarkt, Preis und Absatz, die für vorhandene Produkte richtig sind, müssen für die Entwicklung um strategische Überlegungen zur Produktgestaltung ergänzt werden.

2.1 Produkt

41

Bedarf und Nachfrage Bei der Betrachtung des Markts ist auch wichtig, wie die Ausführung des Produkts (Qualität, Preis) Bedarf und Nachfrage beeinflusst. Zunächst ist es wichtig, zwischen dem Bedarf (Bedürfnis) und der konkreten Nachfrage zu unterschieden. Die Kaufbereitschaft nimmt im Allgemeinen mit dem Preis ab. Menge

Bedarf: wie viele brauchen das Produkt? Nachfrage: wie viele sind bereit, das Produkt zu kaufen? Preis

Abbildung 2-6: Bedarf und Nachfrage: Preis-Absatz-Funktion Wenn der Kundennutzen bzw. die Qualität durch höheren Preis steigt weil das Produkt besser wird und höhere Qualität einen höheren Preis kostet können der Bedarf und sogar die Nachfrage mit dem Preis steigen. Im Allgemeinen sind die Kurven auch nicht linear. Menge

Bedarf: wie viele brauchen das Produkt?

Nachfrage: wie viele sind bereit, das Produkt zu kaufen? Qualität, Preis

Abbildung 2-7: Bedarf und Nachfrage bei mit dem Preis steigender Qualität Diese Art der Betrachtung ist aus Sicht der Entwicklung praktischer, als das Gleichgewicht von Angebot und Nachfrage bei einem fiktiven Preis. Wir können nämlich abschätzen, welche Funktionalität und Qualität sich noch lohnt (die reale Kurve hat eher Sprungstellen, da für bestimmte Kundengruppen das Überschreiten von Minimalforderungen notwendig ist).

42

2 Produktentwicklung

Die Auswirkungen dieser Preis/Qualitäts-Absatz-Kurve auf Umsatz und Ertrag sind ein Thema der Betriebswirtschaft. Kunde und Partner Mit zunehmender Komplexität von Produkten (im Sinne von ganzheitlichen Problemlösungen für den Kunden, nicht einer komplexen Technik des materiellen Produkts) wird die Beziehung zwischen Lieferant und Kunde notgedrungen enger. Die daraus entstehende Bindung zwischen Kunde und Lieferant muss zu einem partnerschaftlichen Verhältnis führen. Der gegenseitige Informationsfluss spielt dabei eine wichtige Rolle. Dies gilt nicht nur für externe, sondern auch für den internen Kunden, d.h. Teile der Organisation, die Produkte von einem anderen Teil benötigen. Orientierung am richtigen Kunden Wichtig ist auch die Konzentration auf die richtigen – auch zukünftigen – Kunden und Technologien. In einer Studie über Technologiesprünge bemerkt [Christensen]: „Precisely because these firms listened to their customers,... they lost their position of leadership“. Gemeint ist damit der Effekt, dass die existierenden Kunden und die vorhandene Technologie sich in eine bestimmte Richtung (und eventuell in eine Sackgasse) entwickeln, während innovative Technologien und Märkte deren Bedeutung übernehmen. Klassisches Beispiel ist der Wirt, der mit seinem Stammtisch altert und irgendwann die Wirtschaft schließt. Hier müssen Management und Marketing auf Veränderungen vorbereitet sein und auf Informationen über neue Technologien und Märkte achten. Dazu gehören auch die bereits erwähnte Projektauswahl und die Beachtung des Innovationsgrads im Projektportfolio. 2.1.4

Umfang der Entwicklung

Bei der Entwicklung ist es wichtig, den Umfang abzuklären und auch die nachfolgenden Schritte zu betrachten. Entwicklung und Realisierung Jedes Produkt wird dem Kunden zur Verfügung gestellt. Dazu muss es unter Umständen erst realisiert werden: • Produktion von materiellen Produkten und Übergabe an den Kunden, • Übergabe (evtl. nach Vervielfältigung) von immateriellen Produkten, gegebenenfalls mit einem materiellen Träger, • Realisierung von Dienstleistungen. Die Idee, nun die Übergabe des Entwicklungsergebnisses als Abschluss der Entwicklungsaufgabe zu sehen, ist theoretisch bestechend und vereinfacht

2.1 Produkt

43

die Konzeption des Begriffs „Entwicklung“. In diesem Kontext ist die Produktion, Fertigung oder Vervielfältigung (als Organisationseinheit) der Kunde der Entwicklung. Damit ist das Entwicklungsergebnis dasjenige Produkt des Entwicklungsprozesses, das von einer durchführenden Organisation als Basis für die Realisierung (Erstellung, Produktion, Vervielfältigung, Erbringen der Dienstleistung) genommen werden kann. Diese Sicht der Entwicklung erfordert dann aber, dass alle Anforderungen aus der Produktrealisierung als Anforderungen an das Produkt konsequent aufgenommen werden. Sie mag zum Verständnis des Entwicklungsprozesses beitragen, im Sinne eines am Markt erfolgreichen „Produkts“ wollen wir aber als „Produkt“ weiterhin das betrachten, was der Kunde bekommt. Abgrenzung Der Umfang von „Entwicklung“ kann unterschiedlich sein, so dass wir mehrere Stufen unterscheiden können:

Tabelle 2-3: Projektumfang in Abhängigkeit vom Scope Umfang Entwicklung (0) im engsten Sinne Entwicklung (1) im engen Sinne (Bedarfsgetrieben) Entwicklung (1) im engen Sinne (Wissensgetrieben) Entwicklung (2) Entwicklung (3) im weiteren Sinne Entwicklung (4) im weitesten Sinne Entwicklung (5) im weitesten Sinne

Prinzip vom Entwurf zur exakten Produktbeschreibung von der Spezifikation zur exakten Produktbeschreibung von der technischen Idee zur exakten Produktbeschreibung von der Anforderung zur exakten Produktbeschreibung vom Problem zur Lösung vom Problem zum fertigen Produkt vom Problem zur dauerhaften Lösung

Phasen (Prinzip) Kernentwicklung Entwurf + Entwicklung (0) Anwendungssuche + Entwicklung (0) Anforderungsanalyse + Spezifikation + Entwicklung (1) Problemanalyse + Entwicklung (2) + Verifikation Entwicklung (3) + Realisierung + Validierung Entwicklung (4) + Weiterentwicklung/Pflege

Diese Abgrenzung der Aufgaben (wobei auch andere Abgrenzungen möglich sind) ist wichtig für die Projektplanung, die Festlegung der Verantwortungen und für die Definition der organisatorischen Schnittstellen.

44

2 Produktentwicklung

2.2 Produkt und Lebenszyklus Das Produkt lebt

Lebenszyklus kann im Umfeld der Produktentwicklung und im Rahmen eines Produktes verschiedenes bedeuten. Deshalb werden auch in der Literatur ganz verschiedene Lebenszyklusmodelle betrachtet: • Lebenszyklus einer Produktlinie bzw. eines Produkts (als Kategorie), • Lebenszyklus einer Produktinstanz (d.h. eines individuellen Objekts), • Lebenszyklus einer Innovation (gegebenenfalls mehrerer Produkte). Diese verschiedenen Lebenszyklen haben jeweils für Management und Entwicklung unterschiedliche Bedeutungen. Tabelle 2-4: Aspekte von Lebenszyklen für Produktklassen Objekt Beispiele Entwicklungsorientiert: Produkt XZ-Handy AB-99 (spezifisch) SW BuHa 2007 3.2 Produktinstanz einzelnes Handy, SW- Installation Innovation Mobiltelefon mit SMS Fuzzy Logik Marktorientiert Produkt XZ-Handy AB-99 (spezifisch) SW XY-BuHa 2007 3.2 Produktlinie XZ_Handy AB SW XY-BuHa Produkt Handy (allgemein) Buchhaltungs-SW Innovation Mobiltelefon mit SMS Fuzzy Logik Kundenorientiert Produktinstanz einzelnes Handy, SW- Installation Produktlinie Handy-Familie XZ/AB SW der Firma XY Gesellschaftsorientiert Produktinstanz einzelnes Handy, SW- Installation Innovation Mobiltelefon mit SMS Fuzzy Logik

Bedeutung für Produktentstehungsprozess, Kostenrahmen Produktionsprozess, Kosten/Gewinn des Verkaufs Erfolg der Innovation, Nutzen der F&E-Ergebnisse Erfolg des Produkts, Gewinn des Unternehmens Erfolg des Unternehmens, Betriebs- und Vertriebsstruktur Erfolg der Branche, Unternehmenslandschaft Nutzen der Innovation, Erfolg der Branche Kaufentscheidung Kompatibilität bei Upgrade und Wechsel, Erfahrungen Gesellschaftliche Auswirkung und Akzeptanz Veränderung der Wirtschaftsstruktur

2.2 Produkt und Lebenszyklus

2.2.1

45

Lebenszyklus von Produkten und Produktlinien

Der Lebenszyklus eines Produkts oder Produktklasse geht von der Idee über die Vermarktung bis zum Ende des Produkts. Der klassische Marketing-Lebenszyklus wird durch verschiedene Lücken (gaps) beim Übergang in andere Kundengruppen, durch die Charakteristika von Marktattraktivität und Marktwachstum und durch die Lernkurve für die Produkte (Erfahrung und Massenfertigung führen zu Preisdruck) ergänzt. Lebenszyklus und Innovation Neue Produkte, die auf Innovationen beruhen, haben einen dedizierten Lebenszyklus, da sich die Innovation erst etablieren muss. Auch Innovationen haben einen solchen Lebenszyklus, der durch mehrere Produkte laufen kann. Ein Produkt kann durch ein „besseres“ oder „schlechteres“ Produkt ersetzt werden: Wichtig ist die Erfüllung der Kundenanforderungen. Wenn durch eine neuere Technologie oder eine neueres Produkt seine Anforderungen besser erfüllt werden, wechselt der Kunde. Die folgenden drei Modelle können das Ablösen einer Technologie (oder eines Produkts) durch eine neue erklären: • Die neue Technologie ist besser und erfüllt damit die Anforderungen des Kunden – bei vergleichbarem Preis – besser. In dieser Situation kann es aber auch passieren, dass die Kunden beim alten Produkt bleiben, das ihre Anforderungen erfüllt, aber keinen Wechsel (Umstellung/Einarbeitung) erfordert. Damit kann die Innovation fehlschlagen. • Die neue Technologie ist besser und erfüllt damit die Anforderungen des Kunden – bei vergleichbarem Preis – besser. Durch die steigenden Ansprüche der Kunden findet ein Wechsel statt. • Die neue Technologie ist zwar nicht besser, aber sie erfüllt die Anforderungen des Kunden bei einem besseren Preis-Leistungs-Verhältnis, evtl. auch nur mit weniger Lebenszyklus-Aufwand (Beschaffung, Betrieb, Energieversorgung, Wartung, Entsorgung). Der Kunde wechselt zur „schlechteren“ Technologie. (Von [Christensen] wurde dies u.A. am Beispiel der Festplattentechnologien aufgezeigt).

46

2 Produktentwicklung

klassisch: Technologiedurchbruch

klassisch: steigende Ansprüche Ansprüche

alte

neue Technologie alte

disruptiv: effiziente Technologie

Ansprüche

neue Technologie

alte

Ansprüche

neue Technologie

Abbildung 2-8: Technologiedurchbrüche Makroökonomische Betrachtung Makroökonomisch verändert der Lebenszyklus eines allgemeinen Produkts (meist basierend auf einer Innovation) wie der Dampfmaschine, der Elektrizität oder dem PC die gesamte Struktur der Wirtschaft. Hier gelten Prinzipien wie Konkurrenz, ökologische Nischen, Verdrängung und Sukzession, die aus der Ökologie bekannt sind. Auch die Wechselwirkung mit der Infrastruktur ist ein wichtiger Aspekt. 2.2.2

Entwicklungsschritte/Lebenszyklus

Das eingangs betrachtete Modell können wir noch verfeinern und so zu den wesentlichen Modellen der Entwicklung im Lebenszyklus kommen. Dabei unterschieden wir verschiedene Arten der Einbettung der Entwicklung je nachdem, ob das Produkt für einen Kunden oder für einen Markt entwickelt wird: Kundenauftrag Kunde Problem

Anforderungen

Entwurf

Implementierung

Produktion Kunde

Abbildung 2-9: Entwicklung im Kundenauftrag

2.2 Produkt und Lebenszyklus

47

Serienprodukt Marketing Problem Idee Technik

Anforderungen

Entwurf

Implementierung

Realisierung Marketing Vertrieb Kunde

Abbildung 2-10: Entwicklung für Serienprodukte Technologiegetriebene Entwicklung Forschung Idee Technik

Anforderungen

Entwurf

Implementierung

Realisierung Marketing

Marketing

Vertrieb Kunde

Abbildung 2-11: Entwicklung nach dem Push-Prinizip

Forschung Idee Technik

Anforderungen Kunde

Entwurf

Implementierung

Realisierung Kunde

Abbildung 2-12: Technologiegetriebe Entwicklung im Kundenauftrag Weiterentwicklung Häufig ist eine Entwicklung nicht eine Neuentwicklung auf der „Grünen Wiese“ sondern eine Weiterentwicklung. Im weitesten Sinne gehört hierzu auch die Pflege und Weiterentwicklung von Produkten (insbesondere bei Softwareprodukten).

48

2 Produktentwicklung

Y2K Das Jahr-2000-Problem, von Informatikern kurz Y2K genannt, entstand durch Computerprogramme, bei denen Jahreszahlen mit zwei Ziffern abgespeichert wurden. Das Problem wurde Ursache bzw. Auslöser für eine gewaltige Anstrengung. Der Anlass lag darin, dass bei Beginn der Softwareentwicklung Speicherplatz knapp war und deshalb Daten möglichst in kompakter Form abgespeichert wurden. Deshalb wurden großenteils Jahreszahlen nur in Form der letzten beiden Ziffern abgespeichert. Bei der Weiterentwicklung von Programmen wurde dieses Entwurfsprinzip übernommen, damit beispielsweise die Datenübernahme einfacher war. Erst mit der Jahrtausendwende tauchte das Problem auf, dass die Speicherung nicht eindeutig war und die Arithmetik falsche Ergebnisse lieferte.

2.2.3

Lebenszyklus des individuellen Produkts

Die Lebenszykluskosten (LCC) eines individuellen Produkts wurden bereits beim Thema Nutzen für den Kunden betrachtet. Für verschiedene Interessen sind verschiedene Arten der Lebenswegbetrachtung einer Produktlinie bzw. einer Produktinstanz entscheidend: • Für das Unternehmen: der Lebensweg von der Idee zur Markeinführung und der gesamte Marketing-Lebenszyklus. • Für den Nutzer: von der Kaufentscheidung zur Entsorgung (TCO: Total Cost of Ownership). • Für die Gesellschaft: von der Rohstoffbeschaffung bis zur Entsorgung (von der Wiege bis zur Bahre). LCC sind ein wichtiges Entscheidungskriterium für den Kunden und das wichtigste Argument für qualitativ hochwertige Produkte. 2.2.4

Forschung und Innovation

Forschung kann Teil des Entwicklungsprozesses sein oder diesen initiieren. Ziel wissenschaftlichen Arbeitens ist das Gewinnen neuer Erkenntnisse. Dabei werden Hypothesen gebildet und diese an Theorie und Realität überprüft. Prinzipielles Vorgehen der Forschung kann induktiv oder deduktiv sein. Weiteres zum Thema Forschung werden wir im Kapitel Forschung als Dienstleistung betrachten.

2.3 Engineering

49

Theoretischer Rahmen, Begriffswelt Theorie

Deduktion

Induktion

Realität Experiment

Aussage über die Realität

Abbildung 2-13: Forschung zwischen Theorie und Realität 2.2.5

Geistiges Eigentum

Ein wichtiger Aspekt im Lebenszyklus ist der Schutz des im Produkt investierten Aufwands in Form von Ideen und Überlegungen, den man als geistiges Eigentum zusammenfasst. Wichtiger Punkt bei Entwicklungen aller Art ist die Frage, ob und wie dieses geistige Eigentum geschützt ist (juristisch und faktisch) und welche Maßnahmen (Geheimhaltung, Eintragung als Patent, Marke, Gebrauchsmuster) zum Schutz getroffen werden sollen. Dabei geht es zum einen um den Schutz des geistigen Eigentums für das Unternehmen (gegenüber Konkurrenten) zum andern aber auch (intern) um die Frage der Rechte am geistigen Eigentum (z.B. Arbeitnehmererfindungen) und der Sicherheit vor Weitergabe sensibler Informationen. Die Frage lautet aber auch umgekehrt: Wo werden durch meine Produkte die Rechte anderer verletzt? Wer ein Produkt entwickelt, baut auf wissenschaftlichen Erkenntnissen und auf vorangegangenen Entwicklungen auf und muss sicherstellen, dass er nicht bewusst oder unbewusst das geistige Eigentum anderer verletzt oder sich solchen (berechtigten oder unberechtigten) Vorwürfen aussetzt. Da diese Probleme insbesondere im internationalen Kontext sehr komplex sind, sollte das Unternehmen bzw. der Entwickler im Zweifelsfall einen kompetenten Rechtsanwalt fragen. Wichtig ist, für diese Fragen und auch für die damit zusammenhängenden Probleme der Sicherheit von Informationen im Unternehmen sensibel zu sein.

2.3 Engineering Ingenieure als Vorbild

Das ingenieurmäßige strukturierte Vorgehen in einzelnen begründeten Schritten dient als Vorbild für den Entwicklungsprozess. Andere Analogien

50

2 Produktentwicklung

oder Metaphern wie Kunst, Handwerk und Fertigung passen nur in wenigen Fällen. 2.3.1

Vorgehensmodelle Entwicklung muss systematisch sein

Auch wenn wir uns im Moment den Ablauf des Entwicklungsprojektes nicht im Detail betrachten wollen, müssen wir uns an der fortschreitenden Verfeinerung in den Phasen der Entwicklung orientieren. Hier soll das Vorgehenskonzept nur kurz zum Aufzeigen des zeitlichen Zusammenhangs dienen. Ausführlich wird der Ablauf von Entwicklungsprojekten in den folgenden Kapiteln beschrieben. VDI 2221 Die VDI-Richtlinie „Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte“ beschriebt das Vorgehen bei der Entwicklung in sieben Arbeitsschritten. Dabei wird starker Wert auf die bei technischen Systemen und Produkten übliche Modularisierung gelegt. Unter Umständen müssen die entsprechenden Phasen auch mehrfach (iterativ oder über verschiedene Modulhierarchien) durchlaufen werden. Die folgende Darstellung orientiert sich sehr stark an der Norm: 1. Anforderungsanalyse: Dieser Arbeitsschritt ist notwendig, um die Anforderungen zu klären und zu präzisieren. Dazu gehören das Zusammentragen aller verfügbaren Informationen und das Erkennen von Informationslücken, das Überprüfen und Ergänzen der externen Anforderungen, das Hinzufügen unternehmensinterner Anforderungen sowie das Formulieren der Aufgabenstellung aus der Sicht des Konstrukteurs einschließlich bereits möglicher und notwendiger Strukturierungen. 2. Entwurf von Funktionen und Struktur: Hier erfolgt das Ermitteln von Funktionsschemen, und der wesentlichen, von dem zu entwickelnden Produkt zu erfüllenden Teilfunktionen (Hauptfunktionen). Deren Gliederung und Kombination zu Strukturen bildet die Grundlage zum Suchen nach Lösungen für das Gesamtprodukt. 3. Prinzipien und Struktur: Hier werden für alle Funktionen (oder zuerst für die wesentlichen Teilfunktionen) Lösungsprinzipien gesucht. Hierzu müssen in einem ersten Schritt physikalische, chemische und andere Effekte ausgewählt werden. Anschließend müssen diese Effekte durch sogenannte wirkstrukturelle Festlegungen realisiert werden. Diese Festlegungen bilden das Lösungsprinzip. Die für Teilfunktionen gefundenen Lösungsprinzipien müssen anschließend entsprechend den Funktionsstrukturen zur Wirkstruktur verknüpft werden.

2.3 Engineering

51

4. Modularisierung: In diesem Arbeitsschritt wird die prinzipielle Lösung in realisierbare Module gegliedert, bevor deren weitere - in der Regel arbeitsaufwendige – Konkretisierung erfolgt. 5. Konkretisierung der Module: Hier erfolgt ein wichtiger Konkretisierungs- bzw. Realisierungssprung durch Gestalten der für die Produktoptimierung maßgebenden Module. Hierbei hat es sich als zweckmäßig erwiesen, den Konkretisierungs- und Vollständigkeitsgrad der geometrischen, stofflichen und programmtechnischen Festlegung nur so weit zu treiben, dass ein Erkennen und Auswählen eines Gestaltungsoptimums möglich wird. Es wird hierbei auch von einem Vorgestalten oder Grobgestalten gesprochen. 6. Endgestalten (Festlegung der Module): Hier werden die bereits vorentworfenen Module durch weitere Detailangaben, durch Gestalten und Ergänzen noch nicht bearbeiteter Gruppen und Elemente sowie durch Verknüpfen aller Gruppen und Teile endgültig festgelegt. Es wird bei diesem Schritt auch von einem Endgestalten oder Feingestalten gesprochen. 7. Ausarbeitung: Dieser Arbeitsschritt dient dem Ausarbeiten der vom Entwicklungs- und Konstruktionsbereich zu verantwortenden Ausführungsund Nutzungsangaben. Dieser Schritt überlappt insofern den vorhergehenden, weil in diesem bereits wesentliche Festlegungen zur fertigungstechnischen Realisierung sowie zum Produktgebrauch getroffen wurden. Allen genannten Arbeitsschritten ist gemeinsam, dass bei ihnen jeweils mehrere Lösungsvarianten untersucht gegebenenfalls in Mustern bzw. Prototypen erprobt und anschließend beurteilt werden müssen. Solche Auswahl-. Optimierungs- und Entscheidungsschritte müssen in allen Arbeitsschritten durchgeführt werden. Sie wurden im generellen Vorgehensplan nicht gesondert aufgeführt. Es sei betont, dass die sieben Schritte je nach Komplexität der Aufgabenstellung noch in weitere Arbeitsschritte untergliedert werden. Phasenkonzepte Phasenkonzepte sind nicht nur für das Projektmanagement wichtig. Ein Entwicklungsprozess vollzieht sich in mehreren Stufen in denen sich der Schwerpunkt von den Anforderungen aus externer Sicht zu den Eigenschaften des Produkts verschiebt und in denen immer mehr Details (Funktion, Material, Methoden, Schnittstellen, Implementierung) festgelegt werden. Jede Ebene der Konkretisierung des Produkts entspricht einer Phase im Entwicklungsprozess. (Dass diese Phasen sich auch hervorragend als Basis der Projektplanung eigenen ist ein positiver Nebeneffekt.)

52

2 Produktentwicklung

Jede Phase ist durch Entscheidungen gekennzeichnet, die sowohl das Produkt als auch das Vorgehen (Entwicklung und Management) betreffen. Sukzessive Verfeinerung In der sukzessiven Verfeinerung werden die Hauptaspekte zunächst grob festgelegt. Diese Festlegungen dienen dann als Basis für weitere Verfeinerungen und als Vorgabe für detaillierte Spezifikationen und Entwürfe. Dabei können die verschiedenen Aspekte parallel oder nacheinander eingeführt werden. Anforderungen und Spezifikation der Komponenten bzw. Aspekte

Betrachtung der Verfeinerung

Entwurf der Komponenten bzw. Aspekte Auswirkungen auf Gesamtstruktur und die Gesamtheit der Komponenten und Aspekte. Weitere zu betrachtende Aspekte in der Verfeinerung.

Abbildung 2-14: Sukzessive Verfeinerung Hierarchische Verfeinerung Wenn sich die Sukzessive Verfeinerung auf Komponenten (Teilsysteme) bezieht, in die das Gesamtprodukt (System) hierarchisch heruntergebrochen wird, kommen wir zu hierarchischen Verfeinerung (hierarchischer Entwurf, hierarchische Planung). Dabei kann der Begriff Teilsystem ein physisches Teilsystem meinen, es können aber auch Komponenten von Systemen (HW, SW) oder von Dienstleistungen als Teile in der Hierarchie vorkommen. Spezifikation: was soll das System leisten?

Betrachtung der Teilsysteme

Entwurf der Prinzipien: wie soll das System funktionieren? Entwurf der Struktur: wie soll das System aufgebaut sein? wie wirken die Teilsysteme zusammen?

Abbildung 2-15: Sukzessive Verfeinerung und Modularisierung

2.3 Engineering

53

Fünf Phasen Ein ganz generelles Modell der Entwicklung ist das Modell der 5 Phasen, das bereits implizit mehrfach verwendet wurde. Es gibt verschiedene Phasenmodelle mit verschiedenen Bezeichnungen und unterschiedlicher Anzahl der Phasen. Die wichtigsten und leider an ehesten vernachlässigte Schritte des Entwicklungsprozesses sind diejenigen am Anfang und Ende, da sie am nächsten zum Kunden liegen (siehe V-Modelle). Sie sind selten Inhalt der jeweiligen Fachdisziplin des Entwicklers (Ingenieurs, Dienstleisters). Wichtig ist die generelle Verwendung, Definition und Kommunikation eines Modells. Anforderung: WOZU ist es da? Spezifikation: WAS soll es leisten? Entwurf: WIE soll es sein?

Test IST es korrekt? richtig? Implementierung SO wird es sein.

Abbildung 2-16: 5-Phasen-Modell als Grundmodell Fahrzeug Am Beispiel der Entwicklung eines Fahrzeugs wollen wir die verschiedenen Begriffe klären. Dabei können wir uns hier die generelle Entwicklung eines Automobiltyps (Modell xy der uvw-Klasse der Marke abc), eines individuellen Fahrzeugs oder auch die Auswahl eines Fahrzeugs durch ein Individuum vorstellen. Anforderungen Die Anforderungen beschrieben, was der Kunde benötigt: z.B. Platz für 6 Personen, Ladefläche von mindestens 2 m² (noch besser: Ansprüche an den Laderaum), Erreichbare Geschwindigkeit, Treibstoffverbrauch,... Auch der Sekundärnutzen und gestalterische Ansprüche können hier festgelegt werden. Spezifikation Mit der Spezifikation wird beschrieben, welche Eigenschaften das Fahrzeug hat: z.B.: 100 PS, Vierradantrieb, drei Sitzreihen, Anzahl Türen, ... Hier sind überprüfbare und messbare Vorgaben wichtig.

54

2 Produktentwicklung

Entwurf Mit dem Entwurf wird das Fahrzeug so genau beschrieben, dass jedem klar ist, wie das Fahrzeug nachher aussehen und funktionieren wird: z.B. Form der Karosserie, Art und Lage von Motor, Getriebe, Bremssystem, Innenraum, ... Implementierung Damit wird das Fahrzeug als Produkt festgelegt, in Form von Zeichnungen, später als Prototyp. Test Tests werden auf den verschienen Ebenen und in allen Phasen vorgenommen. Beispiele sind FEM-Berechnungen, Simulationen, Crash-Tests, Umwelttests (inkl. EMV), Probefahrten, Testfahrten.

2.3.2

Modelltransformation

Den Entwicklungsprozess kann man nun als eine Folge von Lösungsschritten betrachten, wobei die Modelle immer mehr von problemorientierten zu implementierungsorientierten gehen. problemnahes Modell der Aufgabe

implementierungsnahes Modell der Lösung (Produkt)

Umsetzungsphase formales (abstraktes) Modell der Aufgabe

Implementierungsphase Lösungsphase

formales (abstraktes) Modell der Lösung

Abbildung 2-17: Entwicklung als Modelltransformation Der Weg von der Anforderung zum fertigen Produkt führt auch noch über Schritte der Validierung und Verifikation, so dass wir den Prozess der Entwicklung ganz global folgendermaßen darstellen können: Modell der Aufgabe

Geprüfte Lösung

Entwicklungsphase Modell der Lösung

Implementierungsphase Implementierung

ungeprüfte Lösung

Abbildung 2-18: Modellbasiertes Problemlösen und Testen

2.3 Engineering

55

Dies lässt sich jetzt auf das V-Modell übertragen: reales Problem

Modelle des Problems Modelle der Lösung

reale Lösung

Problem Lösung Problemanalyse Umsetzung Anforderungsanalyse Abnahme Spezifikation Validierung Definition Verifikation Tests Entwurf Test gegen Implementierung das Modell Modelltransformationen

Abbildung 2-19: Entwicklung im V-Modell als Modelltransformation 2.3.3

Konzepte

Wenn man sich mit Entwicklung befasst, muss man zumindest einige generelle Konzepte betrachten, die typisch und hilfreich für das Vorgehen bei der Entwicklung sind. Sie sind übertragbar auf viele Bereiche: • Lösungsraum: Betrachte die Menge der Lösungen als einen Raum. • Modularisierung: Strukturiere die Lösung hierarchisch. • Schichtenmodelle: Trenne verschiedene Abstraktionsebenen. • Virtuelle Systeme: Behandle bestimmte Komponenten als Black-Box. • Standardisierung: Lege für bestimmte Probleme Lösungsvorgaben fest. • Plattformkonzepte: Finde gemeinsame Basiskomponenten. • Wiederverwendung: Finde gemeinsam nutzbare Komponenten. Lösungsraum Die Idee des Lösungsraums beschreibt die zu findende Lösung als ein Element einer mathematisch beschreibbaren Struktur. Diese Struktur kann ein mehrdimensionaler Raum (kartesisches Produkt, z.B. in der Morphologischen Box) aber auch ein Graph oder eine Menge von Funktionen sein. Virtuelle Systeme und Schichten Der Ansatz der Virtuellen Systeme kommt aus der Informatik, kann aber auch in anderen Bereichen angewandt werden. Die Komplexität der Informationsverarbeitung ist so hoch, dass man nicht vom Transistor bis zur Konsequenz der auf der Information bauenden Entscheidungen alles gleich-

56

2 Produktentwicklung

zeitig überblicken kann. Um die betrachteten Ausschnitte zu systematisieren, wurden verschiedene Modelle entwickelt. Die wichtigsten sind: • Schichtenmodelle des Rechners (HW, Betriebssystem, Anwendungsprogramme). Jede Schicht liefert bestimmt Dienste (Funktionalitäten). • Begriff der Virtuellen Maschine: eine Black-Box, die bestimmte Funktionalitäten liefert und durch Ihre Schnittstellen definiert ist. • Schichtenmodelle für die Kommunikation (z.B. OSI), Gerätebedienung und die Verarbeitung z.B. in Bild-, Sprach- und Textverarbeitung. • Schichten der Programmiersprachen und Compiler (Maschine, Assembler, Hochsprache, 4GL). • Modularisierungskonzepte für die Programmentwicklung (Unterprogrammtechnik, Module, Objektorientierung). • Ebenen der Informationsverdichtung für die Entscheidungsunterstützung. • Schichtenmodell der Semiotik: Syntax - Semantik – Pragmatik. Standards und Plattformkonzepte Ein wichtiger Aspekt in der Produktentwicklung ist, Gemeinsamkeiten in den Produkten zu erkennen und zu nutzen. Dies kann durch Standardisierung und Nutzung gemeinsamer Komponenten bis hin zu Plattformen auf verschiedenen Ebenen und Stufen der Produktentstehung geschehen. So können nicht nur Teile, sondern auch Entwürfe, Konzepte und Werkzeuge produktübergreifend genutzt und mehrfach verwendet werden. 2.3.4

Dokumentation

Die Dokumentation ist eine wichtige Aufgabe im Rahmen der Entwicklung. Dokumentenmanagement Im Projekt müssen der Status von Projekt und Entwicklung, aber auch Entscheidungen und deren Grundlagen systematisch dokumentiert werden. Dokumente spielen auch als Basis von Reviews und als Ausgangspunkt der jeweils folgenden Entwicklungsschritte eine wichtige Rolle. Konfigurationsmanagement Das Konfigurationsmanagement verwaltet die zu den verschiedenen Entwicklungsständen und Produktvarianten gehörenden Dokumente und erlaubt es, Dokumente und Produkte einander zuzuordnen. Konfigurationsmanagement wird um so wichtiger, je vielfältiger die Produkte sind. Ursachen für Varianten sind beispielsweise: • verschiedene Kunden und Märkte (auch regional), • verschiedene Produkte, verschiedener Funktionsumfang, • zeitliche Abfolge von Entwicklung, Produktion, Weiterentwicklung.

2.4 Anforderungen

57

Das Konfigurationsmanagement erlaubt die Zuordnung zwischen • Anforderungen, Spezifikationen und vertraglichen Regelungen, • Entwurfsdokumenten und Projektdaten, • Versionsdaten von Entwicklung, Entwicklungsumgebung und Produkt, • Graphiken zu Spezifikation, Entwurf und Implementierung, • Dateien in anderen Formaten und auf anderen Datenträgern, • Testdaten und Testdokumenten, • Implementierungsdaten (Produktion, Werkzeuge) und Endprodukt.

2.4 Anforderungen Es klingt trivial: Das Entwicklungsergebnis soll die Anforderungen erfüllen

In der Anforderungsanalyse wird untersucht, welche Anforderungen das zu entwickelnde Produkt erfüllen soll. Das kann man sich in der Form vorstellen, dass man das Problem analysiert, welches das Produkt für den Kunden löst (Soll-Ist-Analyse). Die Anforderungsanalyse muss systematisch alle Anforderungen erfassen. 2.4.1

Anforderungsanalyse und Kriterien

Eine Anforderungsanalyse ist nicht nur eine Sammlung von Wünschen. Anforderungen können sich beziehen auf • Funktionen und Eigenschaften: was? • Mengen und Größen: wie viel? • Aufgabe und Zweck wozu? • Nutzer und Bediener: für wen? • Bedeutung und Priorisierung der Anforderung: wie wichtig? Die Anforderungsanalyse darf nicht nur den Bediener oder Käufer betrachten, sondern muss alle Kundenrollen und auch die vom Produkt betroffenen, möglichen Anspruchsgruppen (Stakeholder) sowie gesetzliche und andere Forderungen berücksichtigen. Eine Gewichtung der Anforderungen ist wichtig. Dabei ist zumindest zu unterschieden nach Muss-, Soll- und Kann-Kriterien. Die Einordnung der Kriterien ist ein wichtiger Schritt. Muss-Kriterien Ein Muss-Kriterium ist eine absolute Forderung an das Ergebnis, deren Nichterfüllung zum Ausschluss führt. Man kann sie auch als Killer-Kriterien bezeichnen. Diese Kriterien dienen im Entwicklungsprozess als Entscheidungsgrundlage.

58

2 Produktentwicklung

Für Muss-Kriterien sollte festgelegt sein, welche Konsequenzen ihre Nichterfüllung hat. Es ist auch hier besonders darauf zu achten, dass Muss-Kriterien richtig formuliert (insbesondere quantifiziert und lösungsneutral) sind. Soll-Kriterien Ein Soll-Kriterium ist eine wichtige Anforderung, die entscheidungsrelevant ist. Diese Kriterien können im Entwicklungsprozess als Auswahlkriterien z.B. bei Nutzwertanalysen verwendet werden. Bei Soll-Kriterien sollte eine Priorisierung oder Gewichtung erfolgen, damit man im Entwicklungsprozess zwischen konkurrierenden Anforderungen sinnvoll abwägen kann. Die Entwicklung kann ja nur dann im Sinne des Kunden zwischen verschiedenen Forderungen abwägen, wenn sie Informationen über deren Wichtigkeit hat. Dies ist auch innerhalb der Entwicklung wichtig, damit nicht Verbesserungen an der einen Stelle mit überproportionalen Verschlechterungen an einer anderen Stelle bezahlt werden. Kann-Kriterien Ein Kann-Kriterium ist eine Forderung, deren Einhaltung zwar positiv gesehen, aber nicht gefordert wird. Diese Kriterien können als Auswahlkriterien herangezogen werden, wenn verschiedenen Alternativen die Muss-Kriterien vollständig und die Soll-Kriterien gleichmäßig erfüllen. Es sollte auch darauf geachtet werden, ob solche Kriterien nicht für bestimmte Entscheidungsträger, Kunden oder Stakeholder als Soll-Kriterium relevant sind. 2.4.2

Requirements

Das Ergebnis der Anforderungsanalyse ist eine Zusammenstellung von Anforderungen (Requirements). Anforderungen bilden (implizit oder explizit, direkt oder indirekt) die Basis des Vertrags zwischen Kunde und entwickelndem Unternehmen. Wie formal die Identifizierung und Verfolgung der Anforderungen geschieht, ist von der Bedeutung abhängig. Anforderungen müssen folgende Kriterien erfüllen: • Sie müssen klar formuliert sein. Dies stellt Anforderungen an die Sprache und nötigenfalls an die Modelle, die zur Beschreibung der Anforderungen verwendet werden. Verwendete Begriffe und Modellkomponenten sind zu klären. • Sie müssen als ganzes die Anforderungen aller Kunden- und Anspruchsgruppen beschreiben und die gesamte Information aus der Anforderungsanalyse beinhalten (Vollständigkeit).

2.4 Anforderungen

59

• Sie müssen widerspruchsfrei sein. Eigenschaften oder Anforderungen

dürfen sich nicht direkt (widersprüchliche Werte) oder indirekt (Unmöglichkeit der Realisierung) widersprechen. • Sie sollen lösungsneutral formuliert sein, d.h. keine Entwicklungs- oder Implementierungsentscheidungen vorwegnehmen, die nicht wirklich notwendig sind. • Sie sollen überprüfbar (operationalisierbar) und möglichst größenmäßig erfassbar (quantifizierbar) sein. Dies kann z.B. durch Angabe eines Mess-, Prüf- oder Testverfahrens erfüllt werden. Es muss klar festgelegt sein, wann eine Anforderung erfüllt ist. • Sie sollen redundanzfrei sein. Jede Eigenschaft oder Anforderung sollte nur an einer Stelle beschrieben werden. Ansonsten ist die Gefahr, dass bei Änderungen Widersprüche auftauchen, sehr groß. • Sie sollen begründet und bewertet sein. Durch diese Hintergrundinformation kann der Entwickler Abwägungen im Sinne des Kunden treffen. An die Beschreibung der Anforderungen sind ebenfalls Kriterien zu stellen: • Sie sollen identifizierbar sein, z.B. durch ein (hierarchisches) Nummernsystem. Die erlaubt die Zuordnung von Entwicklungsentscheidungen zu zugrunde liegenden Anforderungen und die Überprüfung der Erfüllung aller Forderungen. • Sie sollen einem Konfigurations- und Änderungsmanagement unterliegen. Änderungen von Anforderungen müssen mit dem Kunden verhandelt und an die Entwickler weitergegeben werden. Als ein Beispiel für die Anforderungsanalyse sollen hier die beim Thema Schätzung betrachteten Begriff Präzision, Richtigkeit und Genauigkeit betrachtet werden. Sie zeigen, dass Anforderungen an „Genauigkeit“ durchaus nicht offensichtlich sind, sondern von der Art der Nutzung und den Anforderungen abhängen. Dies gilt sowohl im Rahmen der Produktentwicklung (siehe auch das spätere Beispiel zu den Qualitätsfaktoren einer Uhr) als auch für Schätzungen im Projekt (siehe auch das spätere Beispiel zum Thema Genauigkeit von Schätzungen). Präzision, Richtigkeit und Genauigkeit Während die Präzision eines Messgeräts die interne Konsistenz (Wiederholgenauigkeit) beschreibt, beschreibt die Richtigkeit die Übereinstimmung mit dem wahren Wert. Je nach Anwendungsbereich sind diese Eigenschaften verschieden wichtig: Während die Präzision durch Wiederholung erhöht werden kann, kann die Richtigkeit durch Kalibrierung erhöht werden.

60

2 Produktentwicklung

wahrer Wert

wahrer Wert hohe Präzision geringe Richtigkeit

wahrer Wert

geringe Präzision geringe Richtigkeit wahrer Wert

geringe Präzision hohe Präzision hohe Richtigkeit geringe Richtigkeit

hohe Präzision hohe Richtigkeit hohe Genauigkeit

Abbildung 2-20: Genauigkeit als Anforderung

Das folgende klassische Beispiel zeigt, wie die Anforderungen die Lösbarkeit eines Problems beeinflussen: Die Quadratur des Kreises Die klassische Aufgabe besteht darin, nur mit Zirkel und Lineal ein Quadrat zu konstruieren, das die gleiche Fläche hat, wie ein gegebener Kreis mit gegebenem Durchmesser. Diese Aufgabe ist alt, sie hat viele interessante Entwicklungen beflügelt. Wir würden nun vielleicht folgendermaßen vorgehen (Entwurf): • Konstruiere ein Dreieck, dessen Grundseite der Umfang und dessen Höhe der Radius des Kreises sind. • Konstruiere dazu ein Rechteck mit gleichem Flächeninhalt. • Konstruiere zu diesem Rechteck ein Quadrat gleichen Flächeninhalts. Das, was sich am einfachsten anhört, ist die Schwierigkeit: Der Umfang des Kreises kann nicht mit elementaren Methoden (Zirkel und Lineal) exakt gezeichnet werden. Ohne diese Bedingung ist die Aufgabe trivial: zu einem Durchmesser d ist der Umfang u = π∗d beliebig genau zu bestimmen. Für die meisten Anwendungen reicht sogar die auch mit Zirkel und Lineal einfach zu konstruierende Näherung 22/7 für π mit einem Fehler von nur 0,02%.

2.4.3

Shareholders

Wichtig ist, sich nicht nur mit dem aktuellen Kunden, sondern mit zukünftigen Kunden und mit aktuellen und zukünftigen Anspruchsgruppen zu be-

2.4 Anforderungen

61

schäftigen. Dazu gehört auch, gesellschaftliche, wirtschaftliche, technische und politische Entwicklungen im Auge zu behalten. Tourismuskarte Im Rahmen der Entwicklung einer Kundenkarte für eine Tourismusdestination ist meist die erste Frage: „was soll rein?“ Bei der Frage nach der Finanzierung können dann verschiedene Modelle diskutiert werden, z.B. nach dem Motto „wer zahlt wie viel Prozent von was?“. Ein anderer Ansatz besteht in der Frage, wer welche Interessen an diesem Produkt hat. Hier muss beachtet werden, dass der eigentliche Kundenkreis für die Einrichtung der Karte aus den potentiellen Teilnehmern, also Betreibern von Touristischen Einrichtungen, Verbänden, Gastronomen und Verkehrsunternehmen besteht. So können z.B. in einer Matrix die Stakeholder (Anspruchgruppen) und ihre Interessen identifiziert, ihr Nutzen quantifiziert und damit auch mögliche Kostenträger festgelegt werden. Der Ansatz „WER hat WAS davon“ und „WER bringt WAS ein“ erlaubt so eine systematischere Konzeption.

2.4.4

Aufwand und Wichtigkeit

Die vollständige Erfüllung aller Wünsche und Anforderungen ist zu einem vertretbaren Preis selten möglich. Deshalb müssen die Anforderungen gewichtet werden, da eine Übererfüllung einzelner Anforderungen zwar zu hohen Kosten aber kaum zu einem höheren Nutzen für den Kunden führt. Die Methode QFD (Quality Funktion Deployment) erfasst daher die Anforderungen des Kunden und versucht, den Produktnutzen quantitativ zu erfassen. Dann werden Produktnutzen für den Kunden und Aufwand für die Erfüllung gegenübergestellt, um durch eine ausgewogene Erfüllung der Anforderungen ein optimales Preis-Leistungs-Verhältnis zu erzielen. Noch besser als in dem bei QFD verwendeten Profil lassen sich Kosten und Nutzen bzw. Erfüllungsgrad (dem ja ein Aufwand entspricht) und Bedeutung (der ja dem Nutzen entspricht) in einem Portfolio gegenüberstellen. Jede Übererfüllung (zu hohe Kosten) oder Untererfüllung (Unzufriedenheit) von Anforderungen verschlechtert die Kosten-Nutzen-Relation.

62

2 Produktentwicklung

Erfüllungsgrad, Aufwand für die Erfüllung des Kriteriums

Übererfüllung „overengineering“

Unzureichende Erfüllung Qualitätsprobleme Bedeutung des Kriteriums für den Kunden (Nutzen)

Abbildung 2-21: Abweichung von Nutzen und Aufwand Bei einer Abweichung vom Gleichgewicht zwischen der aktuellen Qualität und der Wertschätzung durch den Kunden gibt es mehrere mögliche Reaktionen: Entweder eine produktbezogene Reaktion durch Anpassung der Qualität bzw. der Aufwände oder eine kundenbezogene Reaktion im Rahmen des Marketing (Kommunikation, Marktsegment). Tabelle 2-5: Reaktionen bei Abweichung von Nutzen und Aufwand Übererfüllung

Untererfüllung

Qualitätsbezogen Reduziere die (vergeudeten) Aufwände

Kundenbezogen Erhöhe die Wertschätzung durch den Kunden (Bewusstmachen). Kläre die Kunden über die Bedeutung dieses Qualitätsfaktors auf. Suche ein passendes Kundensegment. Verbessere die Qualität Suche ein passendes Kundensegment. Kläre die Kunden über die Bedeutung dieses Qualitätsfaktors auf.

2.5 Spezifikation Beschreibe, was du willst, und du kriegst, was du brauchst

Die Spezifikation dient dazu, die Leistungen des Produkts zu beschreiben. Es ist sehr wichtig, dabei die Gesamtheit der Leistungen zu erfassen und gleichzeitig keine Implementierungsdetails vorwegzunehmen.

2.5 Spezifikation

63

Die Spezifikation legt das Produkt fest – nicht in seiner Ausführung sondern in seinen Eigenschaften, Merkmalen und Leistungen, in seinem Systemverhalten bzw. in seiner Reaktion auf die Umwelt. In den späteren Entwicklungsphasen werden dann die Details des Produkt immer feiner beschrieben (spezifiziert), bis die einzelnen Teile oder Komponenten so genau beschrieben sind, dass sie aufgrund der Beschreibung eindeutig implementiert und realisiert (produziert, gekauft) werden können. 2.5.1

Grundlagen der Spezifikation

Die Spezifikation beschreibt die Eigenschaften des zukünftigen Systems. Sie ist also ein Modell. Das Problem, eine gute Spezifikation zu schreiben liegt darin, das ganze lösungsneutral zu formulieren. Dort liegt auch ein Erfolgsrezept, das analog zum sachorientierten Verhandeln [Fischer/Ury] die Ziele konsequent in den Vordergrund stellt: Mit dem Paradigma „Ziele statt Positionen“ wird bei einer Spezifikation festgelegt „was soll erreicht werden“ und nicht das „wie“. Damit bleiben Entscheidungen frei, die zu einer Optimierung oder erst zum Erreichen des Ziels notwendig sind. Sich widersprechende Positionen können durchaus aus miteinander verträglichen Zielen abgeleitet sein. Nur wenn die Ziele, Aufgabe oder Problemstellung hinreichend allgemein beschrieben ist, kann eine optimale Lösung gefunden werden. Diese allgemeine Formulierung erfordert Abstraktionsvermögen, Kreativität und die Fähigkeit zur Modellierung. Tabelle 2-6: Spezifikation Ist in der Spezifikation festzulegen: Leistung Merkmal, Eigenschaft Systemverhalten

Gehört nicht zur Spezifikation (außer wenn vom Kunden explizit gefordert): Methode der Leistungserreichung Fertigungsverfahren, Material Verwendete Technologie

Die Spezifikation beschreibt ein Modell des zu erstellenden Systems. Dabei sind die Methoden zur Beschreibung und Erstellung von Spezifikationen so vielfältig wie die im entsprechenden Kapitel beschriebenen Modelle. 2.5.2

Spezifikationstechniken

Eine Spezifikation ist ein Modell des Endsystems, das sich auf dessen Systemverhalten und Leistungen konzentriert. Je nach Produkt und Kunde werden Spezifikationen verschieden ausfallen. Die Spezifikationstechniken ent-

64

2 Produktentwicklung

sprechen den verschiedenen Modellierungstechniken. Hier seien nur einige der wichtigsten Klassen genannt. Black Box Black-Box-Modelle sind der Prototyp von Spezifikationen. Sie geben nur das Systemverhalten an, ohne die Implementierung festzulegen. Dabei darf man nicht nur den physischen „schwarzen Kasten“ im Auge haben. Jede Beschreibung einer Eigenschaft durch einen Messprozess ist im systemtheoretischen Sinne ein Input-Output-Verhalten. So könnte man das Gewicht eines Körpers als die Antwort beschrieben, die man (von der Systemkomponente Waage) bekommt, wenn man den Körper auf die Waage legt. Man sollte diese Idee der I-O-Reaktion nicht übertreiben, aber sie hilft, das ganze allgemeiner zu sehen, was bei Entwicklungsprojekten häufig sehr hilfreich ist. Das zu erstellende System kann (bzw. muss im Allgemeinen sogar) auch durch seine Dynamik beschrieben werden. Use Case Use Cases sind ein spezieller Fall von Black-Box-Modellen: der Benutzer agiert in einer Rolle mit dem Produkt und bekommt eine bestimmte Reaktion. Vor allem für Software ist diese nutzerbezogene Sicht hilfreich. In einer bestimmten Rolle interagiert ein Objekt (Person, Nutzer, System) mit dem Produkt. Dabei muss das Produkt eine bestimmte Reaktion (im allgemeinsten Sinne) zeigen. Im Softwarebereich kann dies im einfachsten Fall ein Input-Output-Verhalten sein. Reaktion kann Kommunikation auf den verschiedenen Ebenen sein. Dabei kann entweder eine informelle Kommunikation oder eine durch Protokolle festgelegte Kommunikation stattfinden. Die Reaktion kann auch die Veränderung des Objekts sein, z.B. bei der Erbringung einer Dienstleistung. White-Box-Modelle White-Box-Modelle beschrieben die Struktur, im Allgemeinen in Form von Hierarchien und Modulen. Auch Flussdiagramme oder Prozessmodelle können eingesetzt werden. Universelle Modelle Es gibt viele Ansätze, ein generelles Spezifikationsmodell zu entwickeln und umzusetzen. Leider sind diese Modelle entweder nur für einen ganz bestimmten eingeschränkten Einsatzzweck (Objekt und/oder Technologie) verwendbar oder sie sind für die praktische Anwendung viel zu komplex.

2.6 Entwurf

65

Die gesamte Vielfalt der für die Spezifikation einsetzbaren Modelle geht ja über die im Kapitel „Modelle“ betrachtete Vielfalt hinaus und es ist schwer – außer der grundlegenden und für den praktischen Einsatz selten verwendbaren mathematischen Formelsprache – einen allgemeinen Modellierungsrahmen zu verwenden. Dort wo dies z.B. in Form von Graphen versucht wird, ist deren Syntax und Semantik so variabel, dass man kaum von einem formalen Modell reden kann.

2.6 Entwurf Viele Wege führen zum Ergebnis – kurze und langwierige

Die Prinzipien des Entwurfs sind wohl für die Entwicklung und für dieses Buch die spannendste Herausforderung, da der Entwurf und die im Entwurf verwendeten Prinzipien neben dem Projektmanagement und der Gesamtsystematik am ehesten einer Verallgemeinerung zugänglich sind. Anforderungen: Kundenspezifisch

Spezifikation: Vielfalt der Modelle

Entwurf Umsetzung vom WAS ins WIE

Implementierung: Vielfalt der Technologien

Abbildung 2-22: Entwurf im Prozessmodell der Entwicklung Die hohe Komplexität des Entwurfsprozesses kommt daher, dass die aus den Anforderungen abgeleitete Spezifikation (WAS wollen wir) nun umgesetzt werden muss in eine Implementierung (WIE wird es gemacht). Der Entwurf ist der herausforderndste Teil des Produktentstehungsprozesses und der flexibelste und kreativste. Aufgrund der Komplexität und Kreativität ist der Entwurf wohl die fehleranfälligste Phase. Andererseits steht der Entwurf in der Fehlerfortpflanzung noch so weit vorne, dass Fehler immense Auswirkungen haben können. Deshalb ist der Entwurf ein kritischer Punkt in der Produktentwicklung. Nussknacker Das Beispiel des Nussknackers soll zeigen, wie vielfältig und wichtig die Entscheidungen in der Entwurfsphase sind. Bei der Erarbeitung der Zielsetzung geht es zunächst darum, welche Aufgaben der Nussknacker zu lösen hat.

66

2 Produktentwicklung

Geht es um einzelne Nüsse oder Massen? Ist der Einsatz im Privatbereich, in Handwerk und Küche, oder in einem industriellen System? Wie ist der Durchsatz, welche Nüsse werden verarbeitet und welche Qualitätsanforderungen werden an die Trennung gestellt? Nun geht es darum, verschiedene Lösungsansätze zu finden und zu kombinieren. Neben den klassischen mechanischen Ansätzen wie Hebel und Keil, kann man auch den Innendruck (durch Druckluft, Hitze, äußeren Unterdruck) einsetzen. Die Art der Materialien, Energiezufuhr und der Zu- und Abtransport des Materials (inklusive des Positionierens) sind weitere essentielle Entscheidungen. Das Ergebnis kann vom Faustkeil bis zur Industrieanlage variieren.

2.6.1

Vorgehensweisen

Bereits im vorigen Kapitel hatten wir die verschiedenen Vorgehensweisen bei der Entwicklung von Produkten betrachtet. Sukzessive Verfeinerung und evolutionäre Entwicklung In diesem Fall werden die wichtigsten Aspekte simultan bestimmt aber mit zunehmender Genauigkeit. Die Aspekte oder Komponenten werden zunächst grob (Größenordnung, Art) und später exakter bestimmt. Dies hat den Vorteil, dass zum jeweiligen Entscheidungszeitpunkt die anderen Aspekte ebenfalls bestimmt sind. Die sukzessive Verfeinerung kann auch zu einem iterativen Verfahren nach Art der evolutionären Entwicklung führen:

Ergebnis

Realisierung

Analyse Spezifikation Konkretisierung Entwurf

Abbildung 2-23: Prinzip der evolutionären Entwicklung

2.6 Entwurf

67

Hierarchische und komponentenweise Entscheidung Ein Entwurf kann hierarchisch geschehen, indem die Entwurfsentscheidungen entsprechend strukturiert werden. Eine analoge Möglichkeit besteht darin, die Entscheidungen zu einzelnen Aspekte jeweils nacheinander zu treffen. Dies geht schneller. Hier ist die Entscheidung über die Reihenfolge wichtig, da die zuerst getroffenen Entscheidungen die anderen beeinflussen oder sogar massiv einschränken. Kommunikationssystem Der Entwurf eines technischen Kommunikationssystems beinhaltet viele Entscheidungen, die teilweise voneinander abhängen und teilweise entkoppelt werden können. Wichtige Entscheidungsmeilensteine sind: • Medium, Träger und Frequenzbereich (z.B. Kabel , IR oder Funk), • Topologie: Punkt-zu-Punkt, Netz, Zellulär, • Analog/Digital (analoges Telefonnetz, ISDN, VOIP), • Vernetzung und Protokolle (z.B.: CSMA). Schichtenmodelle (z.B. OSI) dienen der Entkopplung der Entscheidungen bezüglich Diensten und Netzen. Als Beispiele seien die Telefondienste (Telefonfestnetz, Mobilfunk) genannt.

Unabhängige Entscheidungen Häufig werden im Projekt verschiedene Teams gebildet, die jeweils einen Aspekt bearbeiten. Hier ist die Gefahr der fehlenden Abstimmung sehr hoch. Der Verantwortliche hat dafür zu sorgen, dass die Entscheidungen abgestimmt sind und sich keine Widersprüche ergeben. Die Synchronisation durch Meilensteine und gemeinsame Meetings kann hier helfen. Eine Strukturierung des Produkts ist hierfür unabdingbar, insofern haben wir hier Parallelen zum hierarchischen Entscheiden. Das Ganze kann aber nur funktionieren, wenn vorhandene Wechselwirkungen (ein wechselwirkungsfreier Entwurf ist eine Illusion) berücksichtigt werden und die Kommunikation zwischen den Teams funktioniert. Wichtig ist, dass der Projektleiter den aktuellen Planungs- und Entscheidungsstand kennt und allen Beteiligten zugänglich macht. In einer Planung geht es nicht nur darum „wie sieht das Konzept gerade aus?“ sondern auch darum „wie fix ist das Konzept?“. Event Die Planung einer umfangreicheren Veranstaltung ist in den frühen Phasen ein typisches Entwicklungsprojekt. Die wichtigsten Entscheidungen sind: • Zielsetzung, Größenordnung, Stil, Zielgruppe, Erlebnisfaktoren, Budget,

68

2 Produktentwicklung

• Highlight, Erlebnis, Raum, Termin, Akteure, Besucherkreis. Nach diesen Entscheidungen, die selbstverständlich abgestimmt werden müssen, steht die Konzeption des Events und die Umsetzungsplanung.

2.6.2

Entwurf und Design Design – Gestaltung – Formgebung

Design hat in der Entwicklung die Bedeutung einer bestimmten Phase bzw. einer bestimmten Menge von Aufgaben, die von der lösungsneutralen Vorgabe zu einer Produktkonzeption führt. Ganz klar ist der Begriff Design im Software-Engineering geregelt, dort umfasst er den Entwurf der Struktur der Software (Module, Schnittstellen). In der Entwurfsphase müssen alle Anforderungen an das Produkt berücksichtigt und umgesetzt werden. Dies geht über das von physischen Produkten bekannte „Design“ im Sinne einer ansprechenden Gestaltung oder Formgebung weit hinaus. Meist verbindet man dieses Design mit Begriffen wie künstlerisch oder optisch, wobei Design im Gegensatz zur Kunst zweckorientiert ist, und es auch haptisches oder akustisches Design gibt. Die optische Gestaltung betrifft aber nicht nur das ansprechende Aussehen des Produkts, es geht auch um die Ergonomie und Handhabbarkeit von Produkten. Design und Gestaltung können einen Sekundärnutzen darstellen, sie sind aber auch wichtige Hilfsmittel der Kommunikation. So kann durch Design, insbesondere Farbgebung, der Nutzer in Form einer intuitiven Führung gelenkt werden und Bedienungsanleitungen überflüssig werden. Farbliches, akustisches und haptisches Design sind auch für die Benutzbarkeit wichtig. Dabei ist sowohl die ganzheitliche Wahrnehmung als auch die gegenseitige Ergänzung der Sinneseindrücke bei wahrnehmungseingeschränkten Personen zu beachten. Es kann auch für das positive Gefühl des Nutzers entscheidend sein. Design beim Auto Im Zusammenhang mit einem Auto denkt man bei Design zunächst an die Formgebung der Karosserie. Aber auch die Ergonomie der Bedienelemente (Armaturenbrett) ist ein wichtiger Faktor für die Nutzung. Weitere Aspekte sind: Haptik (Bedienelemente, Sitze), Akustik (Motor, Klang beim Schließen der Türen), Olfaktorik (z.B. der typische Geruch eines neuen Autos).

Das Prinzip „form follows function“ drückt aus, dass beim Entwicklungsprozess die Funktion und der Kundennutzen im Vordergrund stehen und sich die Gestaltung als Konsequenz dieser Anforderungen ergibt.

2.6 Entwurf

69

Brücke Der Bau einer Brücke kann fast als Prototyp des Entwicklungsprozesses bei Nichtkonsumgütern gesehen werden. Eine der wichtigsten Fragen beim Entwurf der Brücke ist die grundlegende Art der Konstruktion. Diese ist sowohl für die technische Umsetzung als auch für die ästhetische Wirkung entscheidend. Die Art der Brücke wird durch Zweck und Grund („warum braucht man hier eine Brücke“), Last, Untergrund, Art und Belastbarkeit der Lager bestimmt. Technisch gesehen ist die Kernfrage: „was trägt diejenigen Teile der Brücke, die nicht direkt aufliegen“. Daneben spielen gestalterische und ästhetische Aspekte, Anforderungen an den Bau (Nutzung des überbauten Raums) und die Anforderungen von Anwohnern und Umwelt eine wichtige Rolle.

2.6.3 Designentscheidungen

Im Laufe des Entwurfsprozesses sind viele Entscheidungen zu treffen. Wichtig ist, diese Entwicklungen explizit wahrzunehmen und zu treffen. Dabei müssen nach der Art und Bedeutung der Entwicklung diese Entscheidungen mehr oder weniger ausführlich vorbereitet, durch optimierende Verfahren unterstütz und entsprechend dokumentiert werden. Möglichkeiten für die Unterstützung der Entwurfsentscheidungen sind: • formale Verfahren (im Team oder mit Kunde, Team und Management), • schriftliche Dokumentation der Entscheidung und der Kriterien, • quantitative Methoden zur Entscheidungsfindung. 2.6.4 Entwurfsprozess

Den Entwurfsprozess können wir in Teilschritten zusammenfassen: • Zusammenstellen der Möglichkeiten (Kombinationen), • Auswahl vernünftiger (formal: zulässiger) Kombinationen, • Auswahl der optimalen Kombination. Die folgende Graphik soll diese Phasen visualisieren:

70

2 Produktentwicklung

Basis

Kombination Auswahl

Abbildung 2-24: Entwicklung als Prozess der Kombination und Auswahl Diese Entwurfsschritte können auch mehrmals durchlaufen werden (hierarchisch oder iterativ), wenn zunächst ein Grobkonzept erstellt und dieses dann systematisch verfeinert wird. Auch dabei gibt es wieder mehrere Möglichkeiten des Vorgehens, im wesentlichen die sukzessive Verfeinerung und die komponentenweise Entscheidung. Lutherbibel Eine Übersetzung ist keine mechanische 1:1-Umsetzung, sondern hat viel mit einem Entwicklungsprojekt zu tun. Alternativen werden untersucht und ausgewählt, und was nachher klar und logisch erscheint, ist das Ergebnis vieler Entscheidungen nicht nur bezüglich der Wortwahl sondern auch bezüglich Quellenverwendung, Stil und der Abwägung zwischen sinngemäßer und wörtlicher Übersetzung. Martin Luther beschreibt Probleme bezüglich seiner Bibelübersetzung ins Deutsche in seinem “Sendbrief vom Dolmetschen”, aus dem Jahre 1530: “Ich habe mich des geflissen im Dolmetschen, dass ich rein und klar Deutsch geben möchte. Und ist uns oft begegnet, dass wir vierzehn Tage, drei, vier Wochen haben ein einziges Wort gesucht und gefragt, haben´s dennoch zuweilen nicht gefunden. Im Hiob arbeiteten wir also, M. Philipps, Aurogallus und ich, dass wir in vier Tagen zuweilen kaum drei Zeilen fertigen konnten. Lieber, nun es verdeutscht und bereit ist, kann´s ein jeder lesen und meistern; läuft einer jetzt mit den Augen durch drei oder vier Blätter und stößt nicht einmal an, wird aber nicht gewahr, welche Wacken und Klötze da gelegen sind, da er jetzt über hin gehet, wie über ein gehobeltes Brett, da wir haben schwitzen müssen und uns ängstigen, ehe denn wir solche Wacken und Klötze aus dem Wege räumten, auf dass man könnte so ein daher gehen. Es ist gut pflügen, wenn der Acker gereinigt ist; aber den Wald und die Stöcke ausrotten und den Acker zurichten, da will niemand an. ... [Luther]

2.6 Entwurf

71

2.6.5 Kombinationstechniken

Von den beiden Schritten der Kombination und der Auswahl, ist die Kombination eher entwurfsspezifisch, Auswahlverfahren sind auch im Management und anderen Bereichen weit verbreitet. Morphologischer Kasten Der Morphologische Kasten erlaubt die Zusammenstellung und Kombination verschiedener Merkmale. Er enthält für jede Komponente der Problemlösung eine Zeile, die Komponente kann dabei auch ein Teil, Aspekt oder ein Parameter des Problems bzw. der Lösung sein. Für die jeweilige Komponente der Problemlösung werden in der Zeile verschiedene Lösungsansätze (Ausprägungen) zusammengestellt.

Tabelle 2-7: Morphologischer Kasten Parameter A B C

Ausprägungen, Ansätze

Das Aufstellen erfolgt in zwei Schritten: • Ausfüllen der Matrix durch Auffinden möglichst vieler Lösungskomponenten (Aspekte, Parameter) und Lösungsvorschläge (Ansätze, Ausprägungen), • Zusammenstellen der möglichen Lösungen durch Auswahl von Kombinationen je einer Ausprägung pro Komponente/Aspekt. Komponenten können sein: • Problemaspekte/Lösungsaspekte, • Teile/Komponenten (Hardware/Software/Organisation), • Entscheidungen. Wichtig ist, dass diese Problemlösungskomponenten • vollständig sind (d.h. die Summe aller Zeilen beschriebt die Lösung), • unabhängig (im logischen Sinne) sind (d.h. keine Zeile ist Teillösung einer anderen Zeile). Dabei ist darauf zu achten, dass in allen Zeilen möglichst viele Lösungsvorschläge stehen. Die folgenden Beispiele sollen das Prinzip verdeutlichen:

72

2 Produktentwicklung

Kaffeemaschine Verschiedene Mechanismen für Erhitzung des Kaffees, Dosieren, Trennen und Warmhalten können kombiniert werden. Tabelle 2-8: Morphologischer Kasten für konstruktive Lösung Kaffeemaschine Ausprägungen Eingabe Tastatur Sprache Tasten Drehknopf Handauflegen EingabeMenü Befehle frei fest implizit steuerung WasserHeizspirale Heizplatte DurchlaufHeißwassererhitzung erhitzer füllung KaffeeManuell Ventil Schnecke Schöpfer Schöpfrad zufuhr Trennen Papier/ Keramik/ MetallSchlitz Schwer- FliehPulver – Stofffilter Porzellan gitter kraft kraft Kaffee Ökologie minimaler maximale maximale hohe ErMinimaler MaterialLanglebig Zerlegbar- satzteilEnergieverbrauch keit keit quote verbrauch Geringer Isolierung Fuzzy Re- WärmeVorgeSolarEnergiegelung pumpe heiztes wärme verbrauch Wasser MarktFirmen Singles Familien RestauÖkosegment rants Freaks Nun können die zueinander passenden und gewünschten Ausprägungen kombiniert werden

Das System lässt sich auch auf Systeme und Dienstleistungen anwenden. Managementsystem Auch hier sind z.B. beim Entwurf eines Projekt- oder Umweltmanagementsystems verschiedene Aspekte zu kombinieren. Tabelle 2-9: Morphologischer Kasten für ein Managementsystem Ausprägungen Institution Abteilung Stabsstelle Ausschuss Projektteam Initiierung Eigeninitiative Einsatzplan Nachfrage Hierarchieebene top obere mittlere untere Charakteristik Stab Linie Kompetenz Anordnung Richtlinie Beratung Einfluss Zentralisation zentral dezentral

Die Auswertung des Morphologischen Kastens und Lösungsfindung geschieht nun anhand der eingetragenen Zeilen. Anhand der Matrix kann

2.6 Entwurf

73

1. Erkannt werden, welche Lösungskomponenten verträglich sind, 2. Erkannt werden, für welche Komponenten noch wenige Lösungsmöglichkeiten bekannt sind, so dass die Problemlösung darauf konzentriert werden kann, 3. Eine optimale Kombination zusammengestellt werden. Die Auswertung und Lösungsfindung erfolgt in mehreren Schritten: 1. Aufstellung von Bewertungskriterien, 2. Bestimmung der Wichtigkeit von Parametern, 3. Auswahl der wichtigsten Parameter ( 2 -3 ), 4. Auswahl der besten Kombination innerhalb dieser Parameter, 5. Sukzessive Hinzunähme weiterer Parameter nach ihrer Wichtigkeit. Durch diese Heuristik erzielt man zwar nicht die "optimale", aber eine brauchbare Lösung. Selbstverständlich muss man die in 4. ausgewählte Kombination anpassen, wenn dies aufgrund der weiteren Parameter nötig erscheint. Morphologische Matrix Die Morphologische Matrix (2-dimensional) bzw. der Morphologische Würfel (3-dimensonal) entsprechen dem Morphologischen Kasten bei Aufgaben mit nur zwei bzw. drei Parametern. Damit ist die Morphologische Matrix auch gut für den Problemlösungsschritt der Auswahl einer optimalen Kombination bei zwei Parametern geeignet. Die Morphologische Matrix ist schon sehr stark problemlösungsorientiert. Für verschiedene Komponenten der Problemlösung werden jeweils verschiedene Lösungsansätze zusammengestellt. Die Entsprechung ist dabei die, dass jeder Kombination der Ausprägungen ein Element der Matrix entspricht. Als Beispiel können wir auch die oben gegeben betrachten sobald alle bis auf zwei (bzw. drei) Parameter in ihren Ausprägungen festgelegt sind. Ein weiteres Beispiel aus dem Dienstleitungsbereich ist: Weiterbildungsveranstaltung Hier können wir in der Konzeption durch Reduktion der Kriterien auf die beiden Kriterien Dauer und Zielgruppe vom Kasten zur Tabelle übergehen. Jedes Matrixelement entspricht einer Kombination von Ausprägungen.

74

2 Produktentwicklung

Tabelle 2-10: Morphologischer Kasten für Weiterbildungsveranstaltung Zielgruppe Top ManaFührungsSachbearStudenten Dauer gement kräfte beiter ein Abend ein Tag Wochenende Woche Reihe abends

Aus dem technischen Bereich betrachten wir ein Beispiel mit exemplarischen Realisierungen: Thermometer Hier können wir uns auf die Kriterien Messprinzip (physikalischer Effekt) und Anzeige konzentrieren Jedes Matrixelement entspricht einer Kombination von Ausprägungen, exemplarische handelsübliche Anwendungen oder Prinzipien sind angegeben. Tabelle 2-11: Morphologischer Kasten für ein Thermometer Messprinzip Ausdehnung Elektrische Chemische Strahlung Anzeige Eigenschaften Eigenschaften direkt Galilei-TherFarbanzeige mometer verstärkt QuecksilberElektrisches thermometer Thermometer analog BimetallThermoThermothermometer element sonde digital BimetallFunk-TherPhasenFieberbinär schalter mometer wechsel messgerät

2.6.6

Entscheidungstechniken

Die Entscheidungstechniken, die im Entwurf angewandt werden, entsprechen denen, die auch in anderen Situation in Management und Technik verwendet werden. Nutzwertanalyse (Scoring-Verfahren) Als Beispiel sei hier die Nutzwertanalyse als Methode zum Vergleich von verschiedenen Alternativen bzw. Lösungsmöglichkeiten beschrieben. Sie ermöglicht Entscheidungen nach dem Maximalprinzip (die Alternative mit dem größten Nutzwert wird gewählt). Das Problem bei der Nutzwertanalyse ist, dass sie durch die Qualitativität zwar Exaktheit suggeriert, aber durch die vergebenen Werte (Gewichtung, Bewertung) extrem subjektiv ist. Deshalb ist es wichtig, Gewichtungen und Bewertungen möglichst objektiv und

2.6 Entwurf

75

im Team zu vergeben. Der Vorteil ist, dass die Nutzwertanalyse ein eindeutiges Optimum – wenn es ein solches gibt – ermittelt und andernfalls zumindest eine Pareto-optimales Ergebnis liefert (siehe das Kapitel über Optimierung). Das grundlegende Vorgehen ist folgendermaßen: • Zusammenstellen von Bewertungskriterien, • Gewichtung der Bewertungskriterien, • Bewertung der Alternativen mit Punkten (auf einer gegebenen Skala), • Bestimmung der gewichteten Gesamtbewertung. Die Erstellung der Nutzwertanalyse erfolgt in folgenden Schritten: 1. Definition der Kriterien und der Skalen für die Bewertung, 2. Gewichtung G der einzelnen Kriterien entsprechend ihrer Bedeutung, 3. Bestimmung der Bewertungsfaktoren B der Alternativen nach der Erfüllung der Kriterien, 4. Berechnung der Einzelbewertungszahlen Z aus Z = G x B, 5. Addition der Einzelbewertungszahlen zur Gesamtbewertung (Summe), 6. Auswahl derjenigen Variante, welche die höchste Gesamtbewertungszahl erreicht hat und damit im Rahmen der vorgegebenen Kriterien am besten geeignet ist. Zusammenfassend ergibt sich die folgende Tabelle: Tabelle 2-12: Nutzwertanalyse (Scoring-Verfahren) Prinzip Kriterien Kriterium 1 Kriterium 2 Kriterium ... Summe Bewertungszahlen

Gewicht G1 G2 G

Alternative1 B11 B11∗G1 B12 B12∗G2 B B∗G

Alternative2 B21 B21∗G1 B22 B22∗G2 B B∗G

Summe

Summe

Die Nutzwertanalyse ist als Entscheidungstechnik sehr stark abhängig von der Qualität der (subjektiv) ausgewählten Kriterien und deren Gewichtung. Vorteile dieser Methode sind die Flexibilität des Zielsystems und die direkte Vergleichbarkeit der Alternativen. Die Durchführung sollte eingebettet sein in die folgenden Schritte: • Vorgehen klären: Ist das Ergebnis definitiv oder nur eine Ausgangsbasis? Verpflichtet sich die Gruppe bzw. der Auftraggeber auf das Ergebnis? • Fakten sammeln und diskutieren, Kriterien aufstellen, Vor- und Nachteile der Alternativen aufzeigen. • Kriterien auf Vollständigkeit prüfen, KO-Kriterien aufstellen, Gewichtung und Spreizung der Variablen diskutieren und festhalten.

76

2 Produktentwicklung

• Matrix aufstellen, Nutzwertanalyse wie oben beschrieben durchführen. • Ergebnis zur Diskussion stellen und Konsens herstellen.

Quantitative Verfahren Quantitative Verfahren der Optimierung basieren auf Modellen von Produkt und Nutzung. Damit kann man sich nicht nur eine Auswahl unter Alternativen treffen, sondern mit analytischen Modellen auch optimale Werte für beschreibende Parameter bestimmen. Neben den klassischen Verfahren des Operations Research sind in weniger exakt modellierbaren Situationen auch Evolutionsstrategien und Methoden der Künstlichen Intelligenz einsetzbar. 2.6.7

Kreativitätstechniken Innovation braucht Kreativität

Kreativitätstechniken (kreativitätsfördernde Methoden) sind eng mit Problemlösungstechniken verwandt. Die Betonung liegt aber mehr auf der Konstruktion von Lösungen und der Synthese, d.h. der "Künstler"-Phase oder der Phase des "Grünen Huts", nicht so sehr bei der Analyse oder der Entscheidung. Die hier vorgestellten "Kreativitätstechniken" dienen der Förderung des kreativen Problemlösungsprozesses durch Kreativitätsförderung und Strukturierung. Zur Förderung der individuellen Kreativität gibt es viele Bücher und Übungen. Wie bei der Problemlösung ist auch beim Einsatz von Kreativitätstechniken die "richtige" Ausgangsfragestellung enorm wichtig. Deshalb sollte auch die Frage nach der Aufgabe, nach dem Ziel bzw. nach dem wirklichen Problem durch geeignete Techniken unterstützt werden (z.B. morphologische Matrix für Ziele). Brainstorming Brainstorming, Metaplan und Brainwriting dienen vor allem der synergetischen Integration einer Gruppe von Personen. Wenn ein Team Ideen von Mitgliedern aufnimmt und konstruktiv weiterentwickelt, so kann die Teamleistung deutlich besser sein als die individuelle Problemlösung. Brainstorming kann unstrukturiert oder mehr oder weniger strukturiert erfolgen. Wichtige Erfolgskriterien sind auf jeden Fall: • Jeder sollte Ideen frei und spontan äußern und alle Ideen positiv aufnehmen. • Auch offensichtlich absurde Ideen sollen eingebracht werden, da sie als Keimzelle für Folgeideen dienen können. • Kritik ist vollständig untersagt. Die analytisch-kritische Bewertung muss in einer späteren Phase erfolgen. Wer Kritikpunkte hat, kann diese für

2.6 Entwurf

77

sich als Basis für verbesserte Vorschläge nutzen und diese Ideen dann ebenfalls einbringen. • Ideen gehören nicht dem einzelnen. Wichtig ist es, Stichworte aufzunehmen und weiterzuentwickeln. Ergebnisse sind Ergebnisse der Gruppe. • Alle Ideen sollten schriftlich festgehalten werden. Metaplan-Technik Als Ergänzung zum Brainstorming und um dieses etwas strukturierter zu machen kann an einer Tafel gearbeitet werden. Wichtig ist, dass wie bei Brainstorming neue Ideen und Begriffe eingebracht werden. Dies kann durch Anschreiben an eine Tafel oder durch Anheften eines Kärtchens geschehen. Kärtchen haben den großen Vorteil, dass man sie im laufenden Prozess und zum Abschluss gruppieren und umgruppieren kann. So können Gruppen, Klassen und Begriffe bottom-up geschaffen werden. Jeder erklärt kurz den eingebrachten Begriff bzw. die Idee. Während dieser Zeit können andere Teilnehmer ihre Ideen schriftlich festhalten, an der Tafel anheften und sie später erläutern. Die später beschriebenen Mind Maps kann man als eine Strukturierungsmethode ansehen, die gegenüber der Metaplantechnik viel stärker hierarchisch und top-down orientiert ist. Durch geeignete graphische Gliederung können auch aus Metaplan-Lösungen Mind Maps entstehen. Brainwriting - Methode 635 Das Kürzel 635 kommt daher, dass bei dieser Methode 6 Personen jeweils 3 Ideen in jeweils 5 Minuten aufschreiben und dann jeweils weitergeben. Da jede Person auf jedem Zettel ihre Ideen niederlegen soll, heißt dies, dass in 6 "Runden" gearbeitet wird. Zuerst schreibt jeder Teilnehmer 3 Ideen auf seinen Zettel. In den folgenden Runden schreibt jeder 3 Ideen (assoziative Weiterentwicklungen der Ideen) auf und jeder gibt seinen Zettel weiter. Dies wird so oft gemacht, bis jeder wieder den eigenen Zettel erhält. Damit sind auf jedem Zettel die Ideen von allen 6 Personen festgehalten. Für die jeweils 3 Ideen von jeweils 6 Personen bietet sich als Arbeitsunterlage ein Formular mit 3 Spalten und 6 Zeilen an.

Tabelle 2-13: Formular zur Methode 635 Thema/Problem 1 2 ... 6

78

2 Produktentwicklung

Da jeder der Teilnehmer 5 Minuten Zeit hat, benötigt die Phase der Ideensammlung 30 Minuten. Sind mehr oder weniger als 6 Teilnehmer beteiligt, empfiehlt es sich, trotzdem 6 Runden durchzuführen. Assoziationstechniken und Spornfragen Die Grundidee dabei ist, einen Ausgangspunkt für Assoziationen schaffen. Dazu wird ein Begriff als "Keim" verwendet. Dabei kann die geistige Verknüpfung frei sein, oder sich an Konstruktionsprinzipien des Begriffes orientieren. Bei der Reizwortmethode wird die Intuition durch Assoziationen angeregt. Aus dem Reizwort (im Allgemeinen ein gegenständlicher Begriff ohne erkennbare Beziehung zum Problem) werden Eigenschaften, Attribute und Funktionen hergeleitet, die dann auf das zu behandelnde Problem übertragen werden, bzw. es werden Beziehungen zum Problem gesucht und daraus Lösungsansätze abgeleitet. Die Anregung kann auch durch physische Objekte geschehen. Der Moderator kann geeignete Objekte (vom Reiskorn bis zum Spielzeugauto) mitbringen und austeilen. Das Finden neuen Ideen kann auf der Basis bekannter Ideen auch aufgrund von Spornfragen angeregt werden, die das Denken in eine neue, oft ungewohnte Richtung lenken sollen. Diese Spornfragen gehen von acht Prinzipien aus: • Vergrößerung: Was könnte man hinzufügen? Wie kann man es vervielfachen? Wie geht´s größer? • Verkleinerung: Was könnte man wegnehmen? Wie geht´s kleiner? • Umgruppierung: Was kann man verändern? Was kann man anders zusammenstellen? • Kombination: Kann man Ideen zusammenführen? • Umkehrung: Was kann man umkehren? Wie setzen wir rückwärts statt vorwärts an? Wie könnte man das Gegenteil erreichen? • Substitution: Können wir andere Ziele, Bedingungen, Methoden voraussetzen? Wie können wir was anders machen? • Zweckentfremdung: Ist die Absicht realistisch? Können wir etwas anderes ins Auge fassen? • Nachahmung: Was ist so ähnlich? Was lässt sich nachbilden? Woraus kann man lernen? Bionik Das Finden von Ideen wird durch die Anregung von Konstruktionsprinzipien der Natur bezogen. Allgemeiner können Funktionsprinzipien übernommen und auch auf nicht-mechanische Entwicklungen übertragen werden.

2.6 Entwurf

79

Dabei empfiehlt es sich, die Gruppe immer wieder ein Tier oder eine Pflanze vorschlagen zu lassen. Nicht nur an bekannt extremen Tieren wie Elefant oder Hai entzündet sich die Kreativität, sondern gerade auch an bekannten aber wenig beachteten Tieren wie Blattlaus oder Tausendfüßlern oder an Pflanzen und Früchten (bzw. Eiern und Raupen bei Tieren). Die Analogie zu Problemlösungen sollte auch nicht zu eng gesehen werden, das natürliche Vorbild dient dann eher als Reizbegriff. Bekannte Anwendungsbeispiele sind Konstruktionsprinzipien der Mechanik wie Verstrebungen und Röhren. Graphisch orientierte Methoden Graphisch orientierte Methoden, insbesondere Netze sind der Prototyp der Verbindung von formal-symbolisch-begrifflichem und assoziativ-intuitiven Problemlösen. Durch die - meist informelle - graphische Strukturierung und die assoziative Nutzung der Anordnung (Topologie) kann ein Netz mit Begriffen eine sehr reichhaltige Vielfalt an Bedeutungen (Semantik) bekommen. Auch die bereits beschriebenen Portfolios nutzen die graphische Anordnung in der Ebene um Situationen und Zusammenhänge klar zu machen. Semantische Netze Die aus der Künstlichen Intelligenz bekannten Semantischen Netze können im Bereich der Kreativitätssteigerung eingesetzt werden, da sie Begriffe formal korrekt und trotzdem anschaulich verbinden. Eine Kombination mit anderen Kreativitätsmethoden bietet sich an, um das Semantische Netz zu erweitern und wachsen zu lassen. Mind Maps Mind Maps können nicht nur zur Kreativitätsförderung, sondern auch zur Problemstrukturierung und Analyse von Zusammenhängen sowie zur Dokumentation und Protokollierung eingesetzt werden. Für eine ausführliche Darstellung siehe das Standardwerk [deBono] und die umfangreiche Literatur. Ausgehend von einem Kernbegriff, der das Problem charakterisiert, werden in mehreren Stufen Begriffe abgeleitet, die zur gesamtheitlichen Erfassung des Problems und damit zur Lösung hin führen. Die abgeleiteten Begriffe werden in einer hierarchischen graphischen Struktur mit Ästen und Unterästen dargestellt. Dabei können auch formale und graphische Symbole verwendet werden.

80

2 Produktentwicklung

Ökotourismus Bei der Entwicklung eines Konzepts zum umweltfreundlichen Tourismus ist es wichtig, die verschiedenen Aspekte und Möglichkeiten zu betrachten. Dazu bieten sich mind maps an.

Einkauf Verpflegung

Rad ÖPNV

Anreise

Kultur Transport

Konsum Unterkunft

Konsum

intern

Natur Gastronomie

WIE

Aktivitäten

Umweltorientierter Tourismus Marketing

WOZU

Nachhaltigkeit

Wabe und Gitter Die Wabe kann - ähnlich wie das Netz - als Basis für eine Sequenz von Assoziationen dienen. Dabei wird durch die Wabenform - ebenso wie durch ein sechseckiges Netz- eine gewisse Struktur vorgegeben. Begonnen wird mit der zentralen Wabe, gearbeitet wird in konzentrischen Schichten. Die Assoziation ist dann nicht mehr so frei, dafür wird aber durch den Zwang zur Strukturierung - zur Einhaltung der Zahl 6 - einerseits ein Ausufern vermieden und andererseits ein "Nach-Denken" über weitere mögliche Punkte erreicht. Qualitätskriterien Bei der Zusammenstellung von Qualitätskriterien für ein Produkt kann die Wabe eingesetzt werden um systematisch Begriffe zu assoziieren. Die Wabe (in der Praxis mit mehr Zellen) wird natürlich für ein Hardware-System anders aussehen als für eine Dienstleistung und für jedes System andere Schwerpunkte haben.

2.7 Qualität und Risiko

81

V a lid ie ru n g A u sfa ll R edu nda nz

T e sts F e h le rfr e ih e it

S ic h e r h e it

A k z e p ta n z F u n k tio n

T o le r a n z

Q u a litä t

B e d ie n u n g

K u nde F le x ix b ilitä t

N u tz e r A n fo r d e ru n g e n

E ffiz ie n z

S c h n ittste lle

m a n in th e lo o p V a lid ie ru n g

2.7 Qualität und Risiko Qualität ist Erfüllung der Ansprüche und Abwesenheit von Risiko

Der Begriff Qualität ist mit dem Thema Entwicklung eng verbunden. Ziel der Entwicklung ist ja, ein „gutes“ Produkt zu entwickeln und der systematische Entwicklungsprozess soll „Qualität“ garantieren. 2.7.1

Qualität Qualität ist, wenn der Kunde zurückkommt und nicht das Produkt

Die Ansprüche des Kunden steigen generell. Während im industriellen Umfeld die Kunden zunehmend qualitätsorientiert werden, ist im Massenmarkt die „geiz ist geil“-Variante und eine Schnäppchenmentalität zu beobachten. Dies bedeutet aber nur, dass der Kunde Produkte möglichst billig möchte, er ist gegen Mängel deshalb nicht toleranter. Qualitätsbegriffe Die unterschiedlichen Qualitätsbegriffe sollen hier am Anfang stehen. Wer über Qualität redet, muss sich klar werden, was er darunter versteht. Die Definition des Begriffs Qualität kann nämlich aus verschiedenen Richtungen erfolgen. Wichtige Ansätze sind: • transzendent: Qualität ist hier ein Grundbegriff, der keiner Erklärung bedarf. Er ist umfassend und konsensfähig wie z.B. der Begriff "gut". Qualität kann im transzendenten Ansatz weder exakt definiert noch gemessen werden, sondern nur aus der Erfahrung beurteilt werden. Qualität ist hier auch ein Synonym für hohe Standards. • produktbezogen/merkmalsbezogen: Qualität lässt sich hier aus der Gesamtheit der Merkmale eines Produkts bestimmen, Qualität ist die (wert-

82

2 Produktentwicklung

freie) Gesamtheit der Merkmale. Qualität ist im merkmalsbezogenen Ansatz eine präzise messbare Größe. • nutzenbezogen/kundenbezogen: Qualität ist hier die Eignung eines Produkt für den Nutzer. Qualität bedeutet im nutzenbezogenen Ansatz die Zufriedenheit des Kunden mit dem Produkt. Sie wird durch den Nutzer festgelegt ("fitness for use") und üblicherweise über die Kundenzufriedenheit gemessen. • ökonomisch: Qualität bedeutet hier ein optimales Verhältnis von Kosten und Nutzen. Qualität bedeutet im ökonomischen Ansatz einen geforderten Nutzen zu einem akzeptablen Preis oder besser noch die für den jeweiligen Kunden (Präferenzfunktion) optimale Kombination von Nutzen und Aufwand (Kosten). • sicherheitsbezogen: Qualität ist die Abwesenheit von Produkteigenschaften, die zu einem Fehler (Abweichen vom gewünschten Verhalten) führen können. Dies schränkt den Qualitätsbegriff scheinbar ein, da die Definition aber alle Kundenanforderungen betrifft, umfasst sie die nutzenbezogene Definition und erweitert sie explizit um den Risikoaspekt. • prozessbezogen: Qualität wird hier nicht definiert, sondern man geht davon aus, dass sie durch die richtige Erstellung des Produkts entsteht ("right the first time"). Qualität bedeutet im prozessbezogenen Ansatz die Beachtung aller Randbedingungen, die für die Herstellung eines "guten" Produkts notwendig sind. Die Definition von Qualität der DIN-Normen ist eine Kombination aus merkmalsbezogenem (formal) und nutzenbezogenem Ansatz: „Qualität ist die Gesamtheit aller Eigenschaften und Merkmale eines Produkts oder einer Tätigkeit, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse beziehen“. Qualitätsanforderungen sind nicht absolut. Erfordernisse ergeben sich aus dem Verwendungszweck bzw. dem Umgang, wie zum Beispiel (siehe Kundenrollen): • Benutzung, Anwendung, • Bedienung, Einrichtung, • Weiterentwicklung, Pflege, Anpassung. Erfordernisse oder Anforderungen sind ganzheitlich zu sehen, sie können anwenderspezifisch, anwendungsspezifisch, herstellerspezifisch, betreiberspezifisch sein oder sich aus Konventionen, Regeln, Standards, Normen und Gesetzen ableiten.

2.7 Qualität und Risiko

83

Qualitätsmerkmale Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. Der Begriff Qualität ist also hier wertfrei, aber auf die Erfüllung der Anforderungen gerichtet. Allgemein wird Qualität als Werturteil verstanden, d.h. als „gut“. Die Qualität hängt aber von den Anforderungen ab, die an das Produkt gestellt werden. Die Erfordernisse werden vom Auftraggeber bzw. späteren Anwender (externe Anforderungen) und vom Hersteller selbst (interne Anforderungen) vorgegeben. Qualität bedeutet also die externen und internen Anforderungen optimal zu erfüllen. Um dies beurteilen zu können, werden die Merkmale des Produkts betrachtet. Ein Merkmal ist nach DIN eine Eigenschaft, die eine quantitative oder qualitative Unterscheidung eines Produkts oder einer Tätigkeit aus einer Gesamtheit ermöglicht. Die DIN-Norm unterscheidet somit zwei Arten von Qualitätsmerkmalen: • Ein qualitatives Merkmal ist ein Merkmal, dessen Werte einer Skala zugeordnet sind, auf der keine Abstände definiert sind. − Ein Nominalmerkmal ist ein qualitatives Merkmal, für dessen Werte keine Ordnungsbeziehung besteht, also ein Element einer nicht geordneten Menge. Für Nominalmerkmale gibt es typischerweise keine Skala oder nur eine teilweise (partiell) geordnete Skala. Typische Beispiele sind Farbe, Geschlecht, Namen. − Ein Ordinalmerkmal ist ein qualitatives Merkmal, für dessen Werte eine Ordnungsbeziehung besteht, also ein Element einer Skala: Eine Skala ist geordneter Wertebereich. Für Ordinalmerkmale besteht also auf der Skala eine Ordnung, d.h. für zwei Punkte x und y gilt entweder x > y, x = y oder x < y. Typische Beispiele für Ordinalmerkmale sind Bewertungen und Notenskalen. • Ein quantitatives Merkmal ist ein Merkmal, dessen Werte einer Skala zugeordnet sind, auf der Abstände definiert sind. Eine solche Skala nennt man Kardinalskala, Für Kardinalmerkmale ist eine Subtraktion definiert, und damit sind die Abstände zwischen zwei Wertepaaren vergleichbar. Typischerweise werden Kardinalmerkmale auf die Menge der (natürlichen, ganzen oder reellen) Zahlen abgebildet. Die Unterscheidung dieser Merkmale ist für die Verwendung von statistischen Verfahren und die Interpretation von Statistiken und graphischen Darstellung immens wichtig. So sind Rangbildungen nur für Ordinal- und Kardinalmerkmale und Mittelwerte nur für Kardinalmerkmale sinnvoll.

84

2.7.2

2 Produktentwicklung

Entwicklung und Fehler

Wie die Qualität kann man auch Fehler zum einen auf da Produkt und zum anderen auf den Produktentstehungsprozess beziehen. Im Rahmen des Produktentstehungsprozesses ist die Bedeutung der Produktion (Leistungserbringung) zwar offensichtlicher, die Entwicklung spielt aber wegen des großen Einflusses eine wichtige Rolle. Bezüglich des Produkts kann man analog zu den Qualitätsdefinition interne (absolute) Fehler als Abweichung der Produkteigenschaften vom Soll (Vorhandensein von Fehlern) und evidente (operative) Fehler als Abweichungen im Produktverhalten (Auftreten von Fehlern) unterscheiden. Fehlerwahrscheinlichkeiten Zwei grundlegende Philosophien im Umgang mit Fehlern könnte man im Prinzip so beschrieben „Fehler sind nicht erlaubt“ und „Fehler gibt’s immer“. Der Nullfehler-Ansatz findet seine Umsetzung im TQM und im sogenannten „Six Sigma“, wo aber durchaus Fehlerraten von 0,000 003 = 0,0003% betrachtet werden. Six Sigma kommt daher, dass man einen „Abstand“ vom Fehlerbereich vom sechsfachen der Standardabweichung Sigma fordert, aber noch eine Schwankung des Prozesses von eineinhalb Sigma annimmt. Damit wird die Wahrscheinlichkeit eines Fehlers durch das 4,5-Quantil der Normalverteilung N0,1(4,5) = 3 ∗ 10-6 bestimmt. Fehlerraten spielen besonders bei Massenprodukten und in Form von Wahrscheinlichkeiten bei sicherheitsrelevanten Produkten eine Rolle. Wichtig ist dabei auch die Schwelle, ab der eine Abweichung von den Ansprüchen der Kunden als Fehler betrachtet wird. Für Kennzahlen ist dabei auch die Zeit bzw. Zahl anzugeben, auf die sich die Fehlerrate bezieht. Fehlerwahrscheinlichkeiten Im Zusammenhang mit Fehlerwahrscheinlichkeiten kommt es stark auf die Basis, die betrachtete Grundmenge und Zeit, an. Beispiele dazu: Eine Fehlerwahrscheinlichkeit von 10-9 pro Sekunde entspricht grob 0,03 pro Jahr also einem Erwartungswert von einem Fehler in 30 Jahren). Dies kann bei sicherheitsrelevanten Teilen bereits zu viel sein. Eine Fehlerwahrscheinlichkeit von 10-6 (entsprechend 1 ppm) pro Mensch entspricht hochgerechnet auf die Erdbevölkerung einem Erwartungswert von (zur Zeit) siebentausend Personen. Eine (dimensionslose) Fehlerrate von 10-6 (Zeiteinheiten pro Zeiteinheit) entspricht in einem Jahr einer Ausfalldauer von einer halben Stunde oder einem monatlichen Ausfall von fünf Minuten. Dies kann bei kritischen Versorgungssystemen zu viel sein.

2.7 Qualität und Risiko

85

Außerdem multipliziert sich die Fehlerwahrscheinlichkeit (z.B. bei einem Produkt) mit der Zeit (Nutzungsdauer) und Zahl (Anzahl der Nutzer). Die Fehlerwahrscheinlichkeit von 10-9 pro Stunde ergibt bei einer Million Nutzern und einer Lebensdauer von 30 Jahren einen Erwartungswert von 262 Fehlern.

Für Fehler gibt es wie für jede andere semantisch bedeutende Aussage in einem realen System keine „Wahrscheinlichkeit Null“ im Sinne einer mathematischen Sicherheit. Ein Nullfehler-Ansatz bedeutet lediglich, dass keinerlei bekannte oder vermeidbare Fehlerquellen akzeptiert werden. Eine „Wahrscheinlichkeit Null“ gibt es in der Realität nicht, es geht darum, Fehlerursachen und Auswirkungen systematisch zu eliminieren. Fehlerquellen Neben technischen Fehlerquellen muss auch das Verhalten des Benutzer und seiner Umwelt berücksichtigt werden. Dies wird z.B. im Fischgrätendiagramm dargestellt. Als Hilfsmittel für die Strukturierung können dabei die Grundelemente vorgegeben werden (z.B. 6M = Mensch, Maschine, Methode, Mitwelt, Management, Material). Mensch

Maschine

Methode Fehlerquellen

Mitwelt

Material

Management

Abbildung 2-25: Fischgrätendiagramm zu Fehlerquellen (6M) Auf der anderen Seite gibt es auch das Problem des „Overengineering“, nicht nur im Hinblick auf die Sicherheit sondern wie bereits oben betrachtet im Hinblick auf alle Kundenforderungen. Sicherheitsforderungen und die Einhaltung von Fehlerwahrscheinlichkeiten müssen wie jede andere Anforderung analysiert und erfüllt werden. Komplexe Verfahren zur Fehlervermeidung können durch die komplizierte Bedienung für die Sicherheit kontraproduktiv sein. Verfahren und Einrichtungen können zu komplex sein und werden deshalb übersprungen oder umgangen. Maßnahmen, die in der einen Bedienungssituation korrekt sind, können in einer anderen Situation gefährlich sein.

86

2.7.3

2 Produktentwicklung

Risikomanagement

Hier soll nur kurz auf das Produktrisiko aus Sicht der Entwicklung eingegangen werden. Produktrisiko Das Produktrisiko umfasst alle Risiken (Gefahren), die vom Produkt und seiner Anwendung ausgehen können. Dabei ist neben der sachgemäßen Anwendung (ursprünglicher Einsatzzweck) auch die unsachgemäße Anwendung (Bedienfehler, Vorsatz) und die Anwendung für andere Zwecke (Verändern oder Überschreiten des Einsatzzwecks) auszugehen. Eine Gefahr besteht nicht nur darin, dass das Produkt seinen Zweck nicht erfüllt, es können darüber hinaus umfangreiche Gefahren und Folgerisiken eintreten. Das Produktrisiko kann mit dem Risikomanagementprozess (siehe Management) oder der nachfolgend betrachteten FMEA behandelt werden. Warnhinweise in Verbindung mit dem Produkt mögen zwar juristisch manchmal sinnvoll sein, den Produktnutzen erhöhen sie aber nicht. Software-Risiko Der folgende Warnhinweis wurde von der Finanzverwaltung für ihr elektronisches Steuererklärungssystem herausgegeben. 4. Warnung DIE SOFTWARE IST NICHT FEHLERTOLERANT UND WURDE NICHT FÜR EINE VERWENDUNG IN GEFAHRENTRÄCHTIGER UMGEBUNG ENTWICKELT ODER HERGESTELLT, IN DER STÖRUNGSFREIER BETRIEB ERFORDERLICH IST, WIE Z.B. IN NUKLEARTECHNISCHEN EINRICHTUNGEN, FLUGZEUGNAVIGATIONS- ODER KOMMUNIKATIONSSYSTEMEN, IN DER FLUGSICHERUNG, IN MASCHINEN ZUR DIREKTEN LEBENSERHALTUNG ODER IN WAFFENSYSTEMEN, IN DENEN EIN AUSFALL DER TECHNOLOGIE DIREKT ZU TODESFÄLLEN, PERSONENSCHÄDEN ODER SCHWERWIEGENDEN SCHÄDEN AN SACHEN ODER UMWELT FÜHREN WÜRDE.

FMEA Die Fehler-Möglichkeits- und Einfluss-Analyse (failure mode effect analysis) ist eine Methode der Qualitätssicherung und des Risikomanagements. Sie kann für Produkte und Prozesse angewandt werden. Dabei werden die möglichen Fehler bzw. Fehlerquellen gewichtet mit ihren Wahrscheinlichkeit, ihren Konsequenzen und der Wahrscheinlichkeit einer rechtzeitigen Entdeckung.

2.7 Qualität und Risiko

87

Für jeden der drei Aspekte gibt es eine Skala von 1 bis 10. • Auftretenswahrscheinlichkeit E: 1 = unwahrscheinlich, 10 = hoch, • Bedeutung/Auswirkung B: 1 = kaum wahrnehmbar, 10 = äußerst schwer, • Entdeckungswahrscheinlichkeit E: 1 = hoch, 10 = unwahrscheinlich. Aus diesen drei Kenngrößen wird durch Multiplikation eine Kennzahl (Risikoprioritätszahl RPZ) berechnet, die es erlaubt, die verschiedenen identifizierten Fehlerquellen einzuschätzen. Die FMEA wird üblicherweise in einer Tabelle dargestellt Tabelle 2-14: FMEA-Tabelle Art

2.7.4

A Auftretenswahrscheinlichkeit

B Bedeutung Auswirkung

E Entdeckungswahrscheinlichkeit

RPZ = A∗B∗E Risikoprioritätszahl

Entscheidungen

Während der Entwicklung muss der Entwickelnde eine Vielzahl von Entscheidungen treffen. Viele davon betreffen auch den Bereich Qualität, Risiko und Sicherheit. Dabei geht es häufig um eine Abwägung nicht nur im technischen Bereich, sondern auch zwischen technisch machbarem und wirtschaftlich vertretbarem. Die Naturwissenschaften und Technik können die Größe des Risikos, seine Auswirkungen und die Wahrscheinlichkeiten für die Konsequenzen bestimmen. Die Kostenrechnung kann die Kosten und Nutzen einer Maßnahme berechnen. Die Abwägung, welche Risiken eingegangen werden und welche Qualität sinnvoll ist, ist aber nicht durch die Technik oder durch das Marketing entscheidbar, sondern sie erfordert eine ethische Betrachtung. Es sind nämlich nicht nur objektive Fakten zu berücksichtigen, sondern ebenfalls Normen und Werte und die gesellschaftliche Akzeptanz von Risiken. Je nach ethischem Ansatz kann die Entscheidung verschieden ausfallen, wenn z.B. eine kleine Gruppe ein hohes Risiko (oder eine zusätzliche Belastung) zugunsten eines Nutzens für die Allgemeinheit oder eine andere Gruppe tragen soll oder wenn für einen Nutzen für eine bestimmte Gruppe die Allgemeinheit oder eine andere Gruppe eine einmalige oder kontinuierliche Belastung oder ein Risiko tragen soll.

88

2 Produktentwicklung

Dabei ist außerdem zu berücksichtigen, dass nicht nur die Umsetzung des Entwicklungsergebnisses sondern auch der Verzicht darauf durchaus Belastungen und Risiken beinhalten (bzw. diese dann eben nicht verhindern oder reduzieren) kann.

2.8 Testen und Lernen Nicht nur aus Fehlern wird man klug 2.8.1

Testen

Einer der wichtigsten Entwicklungsschritte ist das systematische Testen des Entwicklungsergebnisses auf den verschiedenen Ebenen bis hin zum fertigen Produkt. Diese verschiedenen Möglichkeiten der Überprüfung (Simulation, Rapid Prototyping, Versuche) werden wir im Folgenden noch kennenlernen. Wichtig ist festzuhalten, dass die Überprüfung von Entwurfsentscheidungen in jeder Stufe ein wichtiges Kriterium systematischer Entwicklung ist. Der Test bezieht sich auf das Entwicklungsergebnis, kann aber auch das individuelle Produkt betreffen. Dies bedeutet, dass eine Überprüfung des Entwicklungsergebnisses auf verschiedenen Ebenen bzw. Stufen erfolgt: • Realprodukt: Tests am fertigen Produkt (Nullserienprüfung, Stichproben oder vollständige Prüfung), • Produkt-Modell (Validierung bzw. Verifikation von Konzeption und Entwurf): allgemeine Beschreibung, Prototyp, Labormuster, Nullserienprodukt, Emulation, Simulationsmodell, • Realumgebung: Test innerhalb der späteren Einsatzbedingungen, • Umgebungs-Modell: Ersetzung der realen Einsatzbedingung durch: allgemeine Beschreibung, Schnittstellen-Simulation, eingeschränkten Einsatz, Testumgebung. Tabelle 2-15: Tests in der Produktentwicklung Reales Produkt Modell des Produkts

Realumgebung Einsatz Einsatz von Prototypen

Modellumgebung Versuch, Test Simulation

2.9 Spezielle Bereiche

2.8.2

89

Informationsquellen

Um Erfahrungen über mögliche Verbesserungsmöglichkeiten (auch positive Eigenschaften, Fehler, Probleme) zu bekommen, bieten sich neben dem Testen andere Informationsquellen an: • Auswertung von Erfahrungsberichten, • Auswertung von Rückmeldungen im Rahmen des Beschwerdemanagements und von Kundenbefragungen. Dabei ist zu berücksichtigen, dass die Rückmeldungen teilweise nur eine bestimmte Gruppe von Personen, Einsatzbereichen und Problemen berücksichtigen.

2.9 Spezielle Bereiche Produkt kann vieles sein

Die seitherige Darstellung hat versucht, das Gemeinsame im Entwicklungsprozess herauszuarbeiten. Auf die verschiedenen Bereiche werden wir im vorletzten Kapitel eingehen. Die folgende Übersicht soll kurz Spezifika der einzelnen Produktbereiche anreißen. Tabelle 2-16: Spezielle Bereiche der Entwicklung Produkt Mechanik, Elektronik

Wichtige Stichworte zur Entwicklung Entwicklung und Konstruktion, Hardwareentwicklung, Maschinenbau, Engineering Verfahrenstechnische Produkte Synthese, Prozessentwicklung Mechatronik, Sensorik, Intelli- Integrierte Systementwicklung genz (Hardware und Software) Daten, Information, Wissen Forschung, Recherche, Beratung Software, Programme Software Engineering Dienstleistungen Dienstleistungsentwicklung, service engineering Veranstaltungen, Events Eventmanagement, Erlebniskonzeption Systeme, Konzepte, Strukturen Systementwicklung, Beratung Dokumente Dokumentation, Forschung, Schriftstellerische Arbeit

3

Projektmanagement Management bedeutet Verantwortung für Ergebnisse

Die Entwicklung von Produkten ist ein Projekt und muss als Projekt organisiert werden. In diesem Kapitel betrachten wir das Management, allerdings mit Blick auf die im Folgenden zu betrachtenden Produktentwicklung. Schwerpunkt wird deshalb das Projektmanagement sein. Management bedeutet nicht, wie häufig zitiert wird, „in Sekundenschnelle die falsche Entscheidung zu treffen“. Management besteht nicht darin, mit 200 km/h auf eine Mauer zuzurasen und schnell zu entscheiden, ob man rechts oder links dran vorbeifährt. Es besteht darin, rechtzeitig die Prinzipien und Strategien zu entwickeln, damit eine solche Risikosituation von vorne herein ausgeschlossen oder zumindest vermieden wird. Management spiegelt sich also weniger in der operativen Hektik mit Aktionismus und Ad-hoc-Entscheidungen wieder, sondern in der weisen Voraussicht, der Planung und in der Schaffung geeigneter Strukturen. Der Manager muss die Voraussetzungen schaffen, dass sein Team die gegebenen Aufgaben lösen und die Aufträge erfüllen kann: Planen und Vorgaben machen, Rückkopplungsschleifen implementieren, sowie Ressourcen und Prozessstrukturen bereitstellen. Eine komplette Planung ist unmöglich, „kein Plan überlebt den ersten Feindkontakt“. Risikomanagement und Flexibilität sind deshalb wichtig und sie erfordern stabile Planungen.

3.1 Projekte managen Projektmanager sind andere Manager

Der Projektansatz hat das Ziel, das Ergebnis (Ziel des Projekts) sicher und günstig zu erreichen, insbesondere die • Kostenexplosion zu bekämpfen, • Unsicherheit zu reduzieren. Auch mit Projektansatz kann dieses Ziel nur erreicht werden, wenn • die Mitarbeiter fähig und motiviert sind, • die Ressourcen ausreichen, • das Projekt richtig geführt wird. Projekte zu managen bedeutet: • einmalige Aufgaben vorzubereiten, zu planen, abzuschätzen und zu organisieren, • diese Aufgaben im Team zielgerichtet durchzuführen, mit den Beteiligten zu kommunizieren,

92

3 Projektmanagement

• die Aufgabenerfüllung zu überwachen und die Zielerreichung sicher-

zustellen, • das Projekt erfolgreich abzuschließen und zur Zufriedenheit aller zu be-

endigen. 3.1.1 Projekt

Ein Projekt ist eine Aufgabe, die abgeschlossen, einmalig und komplex ist. Die folgende Definition orientiert sich an DIN 69901: Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist wie z.B.: • Zielvorgaben (Anforderungen an Projekt und Produkt), • zeitliche, personelle oder andere Begrenzungen (Einschränkungen), • Abgrenzung gegen andere Vorhaben (Wohldefiniertheit), • projektspezifische Organisation (Team, Projektleiter), • Ziel (innovative Aufgabe, neuartiges Ergebnis), • Weg der Zielerreichung (neue Methoden), • Beschränkung (Unsicherheit und knappere Vorgaben bezüglich Termin und Ressourcen). Das Projekt ist gekennzeichnet durch die Kriterien • Neuigkeit: im Ergebnis (Ziel) oder in der Art der Zielerreichung (Weg), • Komplexität: in Ergebnis und Zielerreichung, • Unsicherheit durch Erstmaligkeit, • Begrenzungen und knappe Vorgaben bezüglich Termin und Ressourcen. Neuartigkeit, Komplexität und Unsicherheit beziehen sich auf die drei Kernfaktoren des Projektmanagements: • Ergebnis (Qualität, Projektziel) und Ziel (Aufgabe, Ergebnis), • Weg der Zielerreichung (neue Methoden), • Termine (Zieltermin und Pünktlichkeit). Ziel, Vision, Mission Ein Projekt hat eine klare Aufgabe. Diese Aufgabe kann man auf verschiedenen Ebenen definieren: • Ziel: Ein Ziel wird in Form eines überprüfbaren Kriteriums (Zielvorgabe) gegeben: was muss erreicht werden? • Vision: Die Vision des Projekts beschreibt eine positive Änderung für die Zukunft: was soll besser werden? • Mission: Die Mission beschreibt die zu lösenden Probleme bzw. die durchzuführenden Aufgaben: Was soll ausgeführt werden? • Aufgaben: Die Aufgaben sind konkrete Tätigkeiten, die ausgeführt werden müssen: Was muss getan werden?

3.1 Projekte managen

93

• Aufgabenabgrenzung (scope): Die Aufgabenabgrenzung legt Rahmen

und Schnittstellen des Projekts fest: Was gehört dazu und was nicht? • Deliverables, Ergebnisse: Die Ergebnisse sind Produkte des Projekts, die

am Ende (im Allgemeinen physisch) abgeliefert werden müssen: Was muss vorliegen? Die Definition und Abgrenzung des Projekts und seiner Aufgaben, insbesondere seiner Vision, ist wichtig für den Erfolg des Projekts. Nur mit klaren Visionen und Aufgaben können Ressourcen erlangt und zugeordnet werden und kann das Projekt vernünftig abgegrenzt und geführt werden. Management Es ist Aufgabe des Managers, für die Erfüllung dieser für den Projekterfolg wichtigen Voraussetzungen zu sorgen: Sie sind nicht von vorne herein gegeben, sondern müssen erarbeitet werden: • Definition und Initiierung des Projekts. Konzeption, Zielsetzung und Abgrenzung des Projekts (wer das Ziel nicht kennt, wird es nie erreichen), • Planung und Anforderung von Ressourcen (Ressourcen bekommt man nicht geschenkt), • Planung, Qualifizierung und Motivation der Mitarbeiter (gute Leute wachsen nicht auf Bäumen), • Planung, Organisation und Überwachung des Projekts (von selbst klappt gar nichts). Projekte bewirken eine vorübergehende organisatorische Änderung und Neufestlegung von Kompetenzen im Unternehmen. Projektdreieck Das "magische" Projektdreieck wird durch die Ecken gebildet, die das Projekt beschreiben: Ergebnis: Ziele, Qualität, Produkte

Ressourcen: Aufwand, Personal

Zeit: Termine, Pünktlichkeit

Abbildung 3-1: Magisches Projektdreieck Die Determinanten des Projekts sind die Ecken des Projektdreiecks: • Qualität, Ergebnis (qualitativ und quantitativ),

94

3 Projektmanagement − Ziele: Vision, Endprodukt, Projektergebnis, − Wertschöpfung: positiver Beitrag des Projekts, − Qualität: Maß der Zielerreichung, Produktqualität,

• Ressourcen, − Geld: Kosten für die Ressourcen am Markt oder intern, − Zeit: Arbeitszeit, Produkt aus Personal und Zeit, − Infrastruktur, Hardware, Software, Informationen, − Personal: Ausbildung, Kenntnis, Motivation, Verfügbarkeit, • Termin, − Zeit: Kalenderzeit (Monate, Tage), − Termineinhaltung: Exaktheit, Wahrscheinlichkeit von Verzögerungen.

Keine Ecke des Projektdreiecks kann alleine geändert werden, ohne die beiden anderen zu beeinflussen. Das Projektdreieck wird berücksichtigt bei • Planung: keine Ecke kann alleine geplant werden, • Controlling: Überwachung macht nur Sinn in der Relation der Ecken, • Steuerung: Eingriffe müssen alle Ecken und ihre Wechselwirkungen berücksichtigen. Projektmanager Ein guter Projektmanager ist nicht nur der „Chef“ des Projektteams, sondern auch der Vertreter des Projekts nach außen. So muss der Projektleiter eine Reihe von Eigenschaften besitzen, um erfolgreich zu sein. Die Erfolgsfaktoren des Projektmanagers liegen in einer ganzheitlichen Kombination von • Fachkompetenz: Fachwissen, Sachwissen, Faktenwissen, Metawissen, • Methodenkompetenz: Kenntnis der Methoden, Anwendungskompetenz, Problemlösungskompetenz, • Sozialkompetenz: Umgang mit Menschen, Verantwortung und Durchsetzungsfähigkeit, • Eigenkompetenz: persönliche Kompetenz, Motivation, Selbstmanagement. Ein Projektleiter, der nur Methoden anwendet und im stillen Kämmerlein Kennzahlen und Netzpläne analysiert hat seinen Job ebenso verfehlt wie einer, der nur am Hemdzipfel der Geschäftsführung hängt um eigene Leistungen hervorzuheben und den Termin für den Absprung nicht zu verpassen. Für diese Manager gilt der Spruch „wer meint, dass ein Projektleiter Projekte leitet, meint auch, dass ein Zitronenfalter Zitronen faltet“. Ein guter Projektleiter führt sein Team, setzt Ziele und sorgt für deren Erreichen. Gleichzeitig vertritt er das Projekt nach außen und sorgt für die nö-

3.1 Projekte managen

95

tigen Ressourcen und Kompetenzen. In der Sicht des Magischen Projektdreiecks muss der Projektleiter das Dreieck nach außen positionieren und nach innen umsetzen. 3.1.2

Einflusskriterien erfolgreicher Projektarbeit

Nicht nur technische, messbare Größen (hard factors), sondern auch menschliche und externe Faktoren sind entscheidend für den Erfolg der Projektarbeit. Hard factors Diese Faktoren sind meist quantitativ messbar, zumindest aber exakt fassbar. • Produkteigenschaften, Art des Produkts (Zielsystem), Größe (Umfang des Zielsystems). • Projekteigenschaften bezüglich der Aufgabe, Innovationsgrad (innovativ, einmalig, repetitiv, wohldefiniert), Auftraggeber (Fachabteilung, externer Kunde) und Größe (Aufwand, finanzieller Umfang). • Projekteigenschaften bezüglich Art und Eigenschaften der Durchführung (Management), Umfeld (Firma, Managementstruktur, Werkzeuge, Team, Linienorganisation). • Erfahrung der Mannschaft und Ausbildung bezüglich Aufgabe, Technik, Methoden, Werkzeugen , Projektarbeit, Teamarbeit. • Rahmenbedingungen (Ressourcen und Restriktionen): − Verfügbare Ressourcen: Zeit, Geld, Personal, Tools, − Organisation: Regeln, Struktur und Zugriff, − Festlegung und Flexibilität von Termine und Kosten. • Rahmenbedingungen der Organisation: − Qualitätsmanagement, − Dokumentation, sonstige Richtlinien (Kunde, Firma), − Maß der Einbindung von Unterauftragnehmern, − Einsatz von Managementtechniken und Projektmanagement. Soft factors Die weichen qualitativen Faktoren sind für das Projekt und seinen Erfolg genauso wichtig wie die harten Faktoren. • Menschliche Faktoren, Motivation, • Umgang miteinander, Kommunikation. Stakeholder Der Begriff Stakeholder beschreibt alle Anspruchsgruppen, d.h. alle Individuen, Organisationen oder Gruppen, die Ansprüche irgendwelcher Form an

96

3 Projektmanagement

die Unternehmung bzw. das Projekt haben. Dabei sind für den Einfluss von Stakeholdern zwei Faktoren wichtig: • Betroffenheit: Der Stakeholder ist durch das Projekt betroffen bzw. hat ein Interesse an dem Projekt und ist motiviert, Einfluss auf das Projekt zu nehmen. • Einfluss: Der Stakeholder hat die Macht, das Projekt zu beeinflussen. Dabei können direkte Einwirkungen, Einfluss auf die Ressourcenvergabe, die Beeinflussung der öffentlichen Meinung oder Netzwerke eine Rolle spielen. Die Stakeholder sind eine sehr ausgedehnte Gruppe, letztendlich haben alle Gruppen und alle Individuen einen Anspruch auf Einhaltung normativer Regeln und Sicherheit vor Risiken. • Wo sind Projektbeteiligte, Kunden, Auftragnehmer? • Wo sind sonstige Mitspieler oder Gruppen mit Kontakt zum Projekt? • Wer hat Nutzen von dem Projekt? • Wer fühlt sich durch das Projekt bzw. das Ergebnis bedroht? • Wer hat Nutzen von dem Projekt und kann das Projekt unterstützen? • Wer kann das Projekt oder das Ergebnis negativ beeinflussen? Interne und externe Faktoren Projekte können an internen und externen Faktoren scheitern. Selbst dann, wenn von internen Gründen gesprochen wird, liegen häufig deren Ursachen in projekt-exteren Versäumnissen. Projektinterne Probleme können mangelnde Kompetenz und Motivation der Mitarbeiter, mangelnde Kommunikation und Kooperation im Projektteam. Diese können durch unklare oder wechselnde Zielsetzung und Kompetenzzuordnung, unzureichende Ressourcen oder Infrastruktur oder fehlende externe Ansprechpartner verursacht sein. Das Zauberwort „Sie sind jetzt Projektleiter“ entbindet denjenigen, der es ausspricht nicht von der Verantwortung, das Projekt zu initiieren, dem Projektleiter die nötigen Kompetenzen zu verschaffen, das Projekt mit Ressourcen und Personal auszustatten und selbst als Ansprechperson (Machtpromotor) zur Verfügung zu stehen. Der designierte Projektleiter hat zunächst die Pflicht, Ziele und Kompetenzen zu klären. 3.1.3

Die frühen Phasen

Die frühen Phasen sind extrem wichtig, da hier Weichen gestellt und zentrale Entscheidungen getroffen werden. Dabei geht es nicht nur allein um die Erstellung des Projektplans, sondern auch um die Festlegung von Kommu-

3.1 Projekte managen

97

nikations- und Entscheidungsverfahren und um die Positionierung des Projekts nach innen und außen. In den frühen Phasen sind die externe Führung und die Stakeholder noch am Projekt interessiert und es bestehen Verhandlungsmöglichkeiten. Im Gegensatz zu den spektakulären Aktionen am Ende des Projekts verlaufen diese Aktivitäten allerdings in Ruhe und hinter den Kulissen. Hier bietet sich das Beispiel der Brandbekämpfung an: Brandvorbeugung ist wenig spektakulär aber extrem wirksam und wirtschaftlich effizient. Wenn die Feuerwehr ausrücken muss, ist mehr geboten, aber es zeigt, dass etwas schief gelaufen ist. Das Projektteam muss beim Projektstart gemeinsam klären: • Arbeitsziele (generelle u. spezifische Inhalte, zeitlicher Rahmen), • Verteilung der erforderlichen Rollen/Funktionen, • Spielregelungen für die Gesprächsführung, • Festlegen der Berichterstattung. Einfluss der frühen Phasen Die frühen Phasen lassen sich auch an wenigsten strukturieren und formal beschreiben. Außerdem werden hier Probleme noch nicht so intensiv wahrgenommen. Hier werden aber bezüglich aller drei Ecken des Projektdreiecks Weichen gestellt: • Das Ergebnis wird als Ziel festgelegt. Dies hat Auswirkungen auf die Einhaltung der Qualität des Ergebnisses. • Der Ressourcenbedarf (Aufwand) wird häufig unterschätzt, auch die zur Verfügung stehenden Ressourcen (Zeit) werden überschätzt. Da die Festlegung der Mittel (Aufwand, Kosten) bereits in den frühen Phasen geschieht (nach 20% der Zeit sind 80% der Kosten festgelegt), ergeben sich gegen Ende Schwierigkeiten mit den Ressourcen. • Die zur Verfügung stehende Zeit erscheint lang, auch durch Unterschätzen der später anfallenden Arbeiten. Durch unklare und spontane Festlegung von Zielen, Mitteln und Methoden wird eine Neudefinition notwendig, was zu Problemen mit der Einhaltung des Termins führt. Die frühen Phasen, die Aktivitäten zu Beginn des Projekts, sind für den Projekterfolg entscheidend wichtig. Festlegungen und Entscheidungen der frühen Phasen Die Entscheidungen und Festlegungen in den frühen Projektphasen betreffen zum einen Inhaltliches (Ziel, Aufgabe), zum andern auch die Rahmenbedingungen und Organisation.

98

3 Projektmanagement

Vision, Mission und Ergebnis, Anforderungen, Erwartungen, Qualitätsanspruch

Ressourcen, Stakeholder, Promotoren, Mittel

Termine, Zeitdruck, Terminfestlegung

Abbildung 3-2: Festlegungen im Magischen Projektdreieck Der Projektleiter bzw. das Projektteam muss diese Fragen möglichst früh (mit Projektstart) klären. • Ziel, Vision, Mission, Aufgabe und Ergebnisse: Wo soll es hingehen? Was ist das Ziel des ganzen? Wozu dient die Arbeit? Was muss getan werden? Welche Ergebnisse werden erwartet? Die Projektziele leiten sich aus strategischen Zielen ab und werden in konkrete Aufgaben und Aufträge umgesetzt. Die Zielvorgabe ist für die Planung wichtig. Am Anfang muss das Ziel klar sein. • Promotoren und Stakeholder: Wer unterstützt das Projekt? Wer hat Interesse an dem Projekt? In den frühen Phasen können Promotoren und Stakeholder gewonnen werden, die am Start des Projekts Interesse haben. • Ressourcen: Woher kommen Ressourcen und wer ist dafür verantwortlich? Welche Ressourcen (Personal, Material, Geld) stehen zur Verfügung? Wie sicher und knapp sind die Ressourcen? In den frühen Phasen müssen die Ressourcen verhandelt und gegen die Ziele abgewogen werden. Nur in den frühen Phasen ist ein Verhandlungsspielraum zur Anpassung des Projektdreiecks. • Mögliche Lösungsansätze: Wie kann das Ziel erreicht werden? Nach welchen Prinzipien wollen wir vorgehen? Welche Methoden sollen verwendet werden? (Inhaltlich, Entscheidungsfindung, Entwicklung und Management). • Termine: Welche Termine sind vorgegeben? Wie fest sind externe Termine und Endtermin? Wie sicher sind Termine, von denen das Projekt abhängt? Auch bezüglich der Termine sind Änderungen nach den frühen Phasen schwer möglich. • Organisation: Die Organisation wird zu Beginn festgelegt und nach Bedarf verfeinert. Dazu gehört: Art der Organisation, Einbindung in die externe Aufbauorganisation, Interne Aufbauorganisation incl. Projektleitung und Leitungsteam, Einbindung in die externe Ablauforganisation, Festlegung der internen Ablauforganisation, Spielregeln und Systeme der Entscheidungsfindung.

3.1 Projekte managen

99

• Verantwortlichkeiten für Ressourcen, Termine, Ergebnisse, Qualitäts-

sicherung, Externe Kommunikation. • Kommunikation im Gesamtprojekt (Projektteam, Teil-Verantwortliche),

projektbezogene externe Kommunikation (Auftragnehmer, Lieferanten, externe Mitarbeiter), Kommunikation zum Kunden, projektexterne Kommunikation in die Organisation und organisationsexterne Kommunikation (Öffentlichkeit, Firmen, Behörden) nach Art, Verantwortung und Kompetenzen. Projektplan Die Projektplanung wird zu Beginn festgelegt und strukturiert, und im Laufe des Projekts verfeinert. Hier ist es besonders wichtig, einen guten Ausgleich zwischen einer exakten und einer flexiblen Planung zu schaffen, da die zukünftigen Aufgaben und Aufwände noch nicht genau bekannt sind. Deshalb muss neben der Planung auch die Verfeinerung der Planung geplant werden. • Ergebnis: Festlegung des Ziels und der Methoden zur Zieldefinition (z.B. Anforderungsanalyse, Marktstudie), Festlegung der Qualitätskriterien, Fortschrittskontrolle und Prüfmethoden. • Ressourcen: Schätzung der Kosten und der benötigten Ressourcen, Festlegung der Anforderungen an Personal, Planung der Verfeinerungsschritte im Arbeitsstrukturplan, Planung der Kostenkontrolle und Verfahren bei Abweichungen. • Termin: Festlegung der Termine, Planung der Terminüberwachung. Dabei ist bei der gesamten Projektplanung das Projektdreieck zu beachten. Auch die Planung der Projektüberwachung, des Berichtswesens und der Verfahren zur Anpassung des Plans muss das Projektdreieck und die internen und externen Beteiligten berücksichtigen. Bedeutung der frühen Phasen Die Konsequenzen (Kosten) von Fehlern werden um so gravierender, je länger der Zeitraum zwischen Fehlerursache und Fehlerentdeckung ist. Die folgende Skizze soll (ohne Anspruch auf quantitative Gültigkeit) verdeutlichen, dass die Fehlerkosten mit dem Abstand zwischen Verursachung und Entdeckung des Fehlers exponentiell anwachsen:

100

3 Projektmanagement

F ehlerkosten 10000 1000 100 10 1 E ntstehu ng b zw . E ntdecku ng des F ehlers

Abbildung 3-3: Anwachsen der Fehlerkosten (Prinzip) 3.1.4

Projektmanagement-Werkzeuge

Ein Projektmanager muss die Methoden des Projektmanagements einsetzen können. Dazu wird er durch Werkzeuge unterstützt. Papier und Bleistift Neben dem Kopf des Projektmanagers sind Papier und Bleistift das wichtigste Werkzeug des Projektmanagements. Skizzen, Planungen und Berechnungen können damit effizient und flexibel erstellt und kommuniziert werden. Tabellenkalkulation Tabellenkalkulationsprogramme erlauben nicht nur das systematische Aufstellen und leichte Ändern von Arbeitsstruktur-, Zeit- Personal- und Kostenplanungen, sie erlauben durch die Veränderung von Parametern „what-if“Analysen, in denen die Auswirkungen von Änderungen simuliert werden. Projektmanagement-Software Es gibt viele verschiedene Programme für das Projektmanagement. Diese unterschieden sich in Umfang und Funktionalität, aber auch im Schwerpunkt. Im Allgemeinen bauen sie auf einer Datenbank (im einfachen Fall einer Tabellenkalkulation oder Datei) auf und erlauben, die Daten mit den Methoden des Projektmanagements (Netzplantechnik, Ressourcenberechnung, Personalplanung) zu verknüpfen und auszuwerten. Das grundlegende Datenmodell einer Projektmanagement-Software sollte den Arbeitsstrukturplan bzw. Netzplan abbilden und die Zuordnung von Ressourcen ermöglichen. Eine Anbindung an externe Systeme (z.B.: Buchhaltung, ERP-System) erlaubt es, Daten zu Kosten und Personal in die Buchführung bzw. Kosten- und Leistungsrechnung des Unternehmens zu übernehmen bzw. von dort zu übernehmen.

3.2 Projektorganisation

101

Projekt mit allgemeinen Informationen

Verknüpfung VorgängerNachfolger für den Netzplan

Vorgang mit Termin, Dauer, ...

Zuordnung

Arbeitspaket mit Aufwänden, ...

Interne Struktur, externe Verknüpfung

Zuordnung

Ressource mit Kosten, Kapazität, ...

Hierarchische Verknüpfung im Arbeitsstrukturplan bzw. Projektstrukturplan

Abbildung 3-4: Grundlegende Datenbankstruktur Projektmanagement

3.2 Projektorganisation Solange alles von selbst läuft, braucht man keine Organisation

Solange alles von selbst läuft, braucht man keine Organisation, und nimmt sie meist auch nur als zusätzlichen Aufwand wahr. Um aber die Basis zu schaffen, damit es „von selbst“ läuft, und um immer dann, wenn etwas nicht automatisch läuft, eine Richtlinie für das Handeln zu haben, braucht man organisatorische Regelungen. Es ist wichtig, diese festzulegen und Strukturentscheidungen zu treffen bevor sie benötigt werden. Bei der Projektorganisation unterscheiden wir: • Externe Organisation, Einbettung: wie ist das Projekt in die Organisation des Unternehmens (Linienorganisation) eingebaut? • Interne Organisation: − Aufbauorganisation, Struktur: Wer macht was? − Ablauforganisation, Prozesse: Wie passiert was? Aufbau- und Ablauforganisation des Projekts sind von der Linienorganisation im Unternehmen unabhängig. 3.2.1 Externe Organisation

Die Einbindung in die Linienorganisation des Unternehmens kann auf verschiedene Arten erfolgen: • Einflussorganisation, • Task force (temporäre Einheit),

102

3 Projektmanagement

• Matrixorganisation, • Projektabteilung.

Task force Diese klassische Projektorganisation kommt dann zum Tragen, wenn ein Projekt bearbeitet werden muss, das vom Umfang her die komplette Mitarbeit vieler Teilnehmer erfordert. Die Projektmitglieder werden für die Dauer dieses einmaligen Projekts aus der Linienorganisation herausgelöst. Durch die neue organisatorische Struktur identifizieren sich die Mitarbeiter schnell mit dem Projekt – auf Kosten der Linie, die aber unter Umständen ihren Einfluss behält und das Ganze damit auch gefährden kann. Das Projekt muss dafür auch zeitlich begrenzt sein, was zusätzlich zum externen einen hohen internen Termindruck aufbaut. Einflussorganisation Die Einflussorganisation kommt dann zum Tragen, wenn (meist einmalig) ein Projekt bearbeitet werden muss, für das Mitarbeiter teilweise zugeordnet werden. Die Projektmitglieder verbleiben in der Linienorganisation. Die Projektleitung hat nur eine koordinierende Funktion, sie kann aber im Rahmen der Aufbauorganisation des Unternehmens Linienvorgesetzte eines Teils der Projektmitarbeiter sein. Diese Art von Projekt kann schnell – meist zu schnell – initiiert werden, die Gefahr eines Scheiterns ist aber durch die fehlende Einbindung auch hoch. Die Einflussorganisation kann dann erfolgreich sein, wenn die Stellung des Projektleiters oder seines Machtpromotors so hoch ist oder das Projekt in der Organisation als so wichtig angesehen wird, dass das Projekt auch die notwendigen Mitarbeiter und andere Ressourcen bekommen. Matrix Die Matrixorganisation wird eingeführt, wenn regelmäßig Projekte bearbeitet werden. Es findet eine Aufgaben- und Kompetenzverteilung zwischen Projekt und Linie statt: • Projekt: was, wann: kurzfristige (im Rahmen der Projektlaufzeit) Gewinnerwirtschaftung und Projektdurchführung. • Linie: wer, wie: Personalbereitstellung für das Projekt und langfristige Personalentwicklung und Know-How-Sicherung. Die Matrixorganisation erfordert die Einführung und Aufrechterhaltung von Regeln für die Bereitstellung und Abrechnung von Personal. Wenn die Konkurrenz zwischen Projekt und Linie positiv und kreativ ist, kann diese Form von Projektdurchführung sehr effizient sein.

3.2 Projektorganisation

103

Projektabteilung Wenn regelmäßig Projekte mit wechselnden Inhalten bearbeitet werden ("Routineprojekte") kann eine eigene Projektabteilung innerhalb der Aufbauorganisation des Unternehmens eingerichtet werden. Der Projektleiter ist dann Linienvorgesetzter seiner Mitarbeiter, zumindest des Kernteams. Der Vorteil ist, dass sowohl die Fachkompetenz als auch die Projektkompetenz in dieser Abteilung vorhanden sind. Meist gilt dies aber nur für die Kernfunktionen, so dass Mitglieder anderer Abteilungen ebenfalls ins Projekt eingebunden werden müssen. Ein zweiter Grund für eine Projektabteilung sind Projekte, deren Dauer und Größe eine organisatorische Anpassung sinnvoll oder gar zwingend machen. Ab einer bestimmten Größe ist eine Abteilung, Profit Center oder gar eine eigene Firma sinnvoll, letzteres insbesondere bei mehreren Projektträgern (joint venture). 3.2.2

Aufbauorganisation

Bezüglich der Organisation des Projekts unterscheiden wir die oben betrachtete Einbindung des Projekts innerhalb des Unternehmens und die interne Projektstruktur (Aufbauorganisation des Projekts). Projektstruktur Die interne Projektstruktur wird im Allgemeinen durch eine hierarchische Aufteilung in Aufgabenbereiche (Teilverantwortliche) und Teilprojekte gegeben. Die externen Funktionen sind Ansprechpartner, Verantwortungsträger und Entscheider bezüglich der Zuteilung von Ressourcen. Verantwortungsbereiche im Projekt Jede Führungsebene ist im Projekt für die ihr übertragenen Aufgaben eigenverantwortlich. Wichtige Aufgaben der einzelnen Beteiligten in ihren jeweiligen Rollen sind: • Top Management (Geschäftsleitung und Vorgesetze, indirekt auch Kunde, Promotoren und Stakeholder): Sie sind Träger und Kostenträger des Projekts. Ihre Aufgabe ist die Initiierung und Ausstattung des Projekts, Beteiligung der Projektleiter am operativen Planungsprozess und die Information der Projektleitung über aktuell relevante projektbezogene Plandaten (Finanzierung, Kosten, Investitionen, Termine). • Projektverantwortlicher (Promotor, Sponsor): Er initiiert das Projekt und vertritt das Projekt beim Top Management. Er schlägt Kernteam und Projektleitung vor und informiert über alle projektbezogenen Plandaten. Er ist zuständig für Aufgaben und Probleme, die nicht innerhalb des Pro-

104

•

•

•

•

3 Projektmanagement

jekts gelöst werden können wie Ausstattung des Projekts mit den notwendigen notwendigen Ressourcen, Abstimmung mit den Linienvorgesetzten der Projektmitglieder. Projektleiter: Der Projektleiter ist verantwortlich für die unternehmerische Durchführung des Projekts, er ist verantwortlich für die sinnvolle Festlegung und das Erreichen der gestellten Ziele. Er muss seinem Linienvorgesetztem und dem Projektverantwortlichen regelmäßig berichten und sich mit den beteiligten Linienvorgesetzten abstimmen, Er hat Informationsanspruch auf alle projektrelevanten Tatbestände. Intern ist er der Leiter des Projekts und für alle projektinternen Entscheidungen verantwortlich. Das Kernteam (Projektleitungsteam) ist verantwortlich für die jeweiligen fachlichen Teilgebiete (Technik, Kaufmännisches, Vertrieb/Marketing, Projektsteuerung). Das erweiterte Projektteam ist verantwortlich für die jeweils zugeordneten übergreifenden Aufgaben wie Planung, Organisation, Controlling (Projektmanager) Qualitätsmanagement (Qualitätssicherung), Logistik, Informationsmanagement (DV, Kommunikation, Projektinformationen), Konfigurationsmanagement, Produktion, Materialwirtschaft etc. Die Teilprojekt-Verantwortliche (Arbeitspakete der oberen Ebene) und Arbeitspaketverantwortliche sind verantwortlich für die jeweiligen Teile des Arbeitsstrukturplans (WBS, Work Breakdown Structure). Diese Teile können vom jeweiligen AP-Verantwortlichen wie ein Projekt geplant, durchgeführt und überwacht werden.

Projektleiter Der Projektleiter ist die zentrale Funktion des Projekts. Er ist "mister project", der von innen und außen mit dem Projekt identifiziert wird. Die folgenden Rollen und Aufgaben können im Umfeld "Projektmanagement" unterschieden werden. Sie werden in einer oder mehreren Personen vereinigt, die je nach Firmengepflogenheiten die Namen "Projektleiter" und/ oder "Projektmanager" bekommen. • Promotor (Machtpromotor, Fachpromotor des Projekts), • Projektverantwortlicher (gegenüber Geschäftsleitung und Kunde), • Projektmultiplikator (externe Rolle, Sprecher nach außen), • Projektleiter (gegenüber Projektmitarbeitern), • Projektmanager (Planer, Abwickler, Organisator, Macher, Controller), • Projektmultiplikator (interne informelle Rolle, Sprecher von innen). Dabei ist die Äquivalenz von Verantwortung und Kompetenzen ein wichtiger Schlüsselfaktor für den Erfolg des Projekts.

3.2 Projektorganisation

105

Neben Organisation und Führung werden vielseitige Anforderungen an den Projektleiter gestellt: • Katalysator und Förderer nach innen: "why not" statt "yes but", Promotor für Ideen, • Filter nach oben: kein "management by gear-wheels" (erhöhte Drehzahl bei Druck von oben), • Puffer nach außen: gegen Störungen und anmaßende Firmenbürokratie (Regenschirmfunktion), • trotz Filter- und Pufferfunktion angemessene Information der Mitarbeiter: Informationsmanagement (Informationsvorsprung nicht als Machtmittel missbrauchen), • faire und berechenbare Persönlichkeit (weder "bester Kumpel" noch "Kaiser und Gott"), • Frustrationstoleranz. Eskalationsprinzip Eine wichtige Basis des Projektmanagements ist das rollenbasierte Eskalationsprinzip: • Problemlösung auf einer möglichst niedrigen Hierarchieebene, • Beachtung der funktionalen Autorität (Rollen im Projekt), • Eskalation in wohldefinierten Einzelschritten. Jede Problemlösung sollte auf der niedrigsten Hierarchie des Projektstrukturplans (Arbeitspaketverantwortliche) geschehen. Rollenbasiertheit ist deshalb wichtig, weil die Projektmitarbeiter und insbesondere Funktionsträger ja oft in andere Hierarchien eingebunden sind. Nur wenn diese Problemlösung nicht funktioniert wird auf die höhere Ebene zugegangen (Eskalation) oder über die Linie eine Problemlösung angestrebt. Projektpyramide Häufig wird ein Projekt als Pyramide mit verschiedenen Führungsebenen dargestellt. Der Projektleiter steht dann an der Spitze, die Projektorganisation ist gegeben durch das Leitungsteam und die Arbeitspaketverantwortlichen. Der Projektleiter (bzw. das Projekt als ganzes) ist aber auch vielen Externen Rechenschaft schuldig und hat die Interessen vieler Anspruchsgruppen zu berücksichtigen. So ergibt sich ein starker Einfluss auf das Projekt, der durch eine umgekehrte Pyramide dargestellt werden kann. Im ungünstigsten Fall einer Einflussorganisation ist jeder Projektmitarbeiter Basis einer solchen umgekehrten Pyramide, auf der dessen Vorgesetzen und die Anspruchsgruppen gegenüber dem Arbeitspaket und gegenüber der Person stehen.

106

3 Projektmanagement

Rahmenbedingungen Anspruchsgruppen Unternehmenshierarchie Vorgesetzte und Leiter übergeordneter Projekte Projektleiter Projekthierarchie mit Projektteam Teilprojektleitern Arbeitspaketverantwortlichen ...

Abbildung 3-5: Projektpyramiden 3.2.3

Ablauforganisation und Berichtswesen

Das Projekt ist eine mögliche Form der Ablauforganisation. Trotzdem muss innerhalb des Projekts der Ablauf festgelegt werden. Im Vordergrund steht Frage "WER macht WANN WAS". Für den Erfolg des Projekts sind die Informationen entscheidend. Informationswege im Projekt betreffen die Information der Mitarbeiter und das Berichten im Projekt. Ablaufplanung Zusammengefasst wird: • Zeitliche Komponente: Phasen und Teilphasen bzw. Arbeitspakete (Ablauforganisation): WAS und WANN, • Personelle Komponente: Rollen und Aufgaben innerhalb des Projekts (Aufbauorganisation): WER. Berichtswesen Neben den Kommunikationswegen ist auch die Verantwortung für die Kommunikation zu regeln (Bringpflicht/Holpflicht: push/pull). Die Berichtswege müssen sich an der Projektstruktur orientieren. Das Berichtswesen muss beinhalten: • Informationen über abgeschlossene und in Bearbeitung befindliche Arbeitspakete und Meilensteine, • Informationen über abgeflossene Mittel und getätigte Mittelfestlegungen, • Informationen über außergewöhnliche Ereignisse und Probleme. Die Ablauforganisation wird während der Projektplanung festgelegt.

3.3 Projektplanung

107

3.3 Projektplanung Gute Planung ist der Schlüssel zum Erfolg

Die Planung des Projekts basiert auf der Arbeitspaketstruktur (Work Breakdown Structure, WBS) und den Meilensteinen. Auf dem WBS (Arbeitsstrukturplan) basieren die Netzpläne und Kostenschätzungen. 3.3.1 Zielsetzung

Das Wichtigste am Projekt sind die Projektziele. Sie sind schließlich der Grund, dass das Projekt durchgeführt wird. Die Definition von Projektzielen bedeutet auch, festzulegen, wie das Projekt die Gesamtziele der Organisation unterstützt. Die unterschiedlichen Arten von Zielen haben wir bereits betrachtet. Daneben kommen verschiedene Arten von Zielaspekten: monetäre Ziele (Gewinn), Image, Gewinn an Know-How oder Erkenntnissen. Die verschiedenen Ziele müssen bei der Projektplanung unterschiedlich berücksichtigt werden: • Vision: Änderung für die Zukunft: Umsetzung in konkrete Ziele, • Ziel: Überprüfbare Vorgabe: Umsetzung in Deliverables und Aufgaben, • Mission: Durchzuführenden Aufgaben: Aufnahme in Arbeitsstrukturplan, • Aufgaben: Aufnahme in Arbeitsstrukturplan, • Deliverables, Ergebnisse: Umsetzung in den Arbeitstrukturplan, • Terminvorgaben: Aufnahme in Projektdreieck und Netzplan, • Terminrestriktionen: Aufnahme in den Terminplan/Netzplan, • Ressourcenvorgaben: Aufnahme in Projektdreieck und Ressourcenplan, • Qualitätsforderungen: Aufnahme in Projektdreieck und Ergebnisplan. Wichtig ist die Erfassung aller Anforderungen an das Projekt (und natürlich an das Projektergebnis, also beispielsweise das zu entwickelnde Produkt). Neben Vision, Mission und Aufgaben ist auch die Abgrenzung des Projekts (Scope) eine wichtige Vorgabe für die Projektplanung. Es muss klar gesagt werden, welche Aufgaben zum Projekt gehören bzw. welche nicht, und welche Zuarbeiten von Externen (Kunde, Träger) erwartet werden. 3.3.2 Arbeitsstruktur

Arbeitspakete (AP) sind nach DIN 69901 „nicht mehr unterteilte Elemente eines Projektstrukturplans“. Diese theoretische Betrachtung lässt außer Acht, dass ein Arbeitsstrukturplan etwas Dynamisches ist. Der Arbeitsstrukturplan wird ja im Laufe des Projekts aufgrund der gewonnenen Erkenntnisse verfeinert. Deshalb ist es sinnvoll, alle Elemente des Arbeits-

108

3 Projektmanagement

strukturplans als Arbeitspakete zu bezeichnen. Außerdem ist es hilfreich, zwischen Arbeitsstrukturplan (aufgabenorientiert im Sinne der Work Breakdown Structure) und Projektstrukturplan (organisationsorientiert) zu unterschieden. Arbeitsstrukturplan Der Arbeitsstrukturplan (Work Breakdown Structure, WBS) gliedert die Gesamtaufgabe bis hinunter zum Arbeitspaket der untersten Ebene. Für jedes Arbeitspaket gibt es einen Verantwortlichen. Die Abarbeitung des Arbeitspakets sollte wie ein Projekt geplant werden (Aufteilung, Phasen, Planung und Kontrolle). Alles über Projektmanagement gesagte trifft also im Kleinen auf den Arbeitspaketverantwortlichen als Manager des Projekts "Abarbeitung des Arbeitspakets" mit der in der AP-Beschreibung genannten Zielsetzung (und dem Gesamtsystem im Hintergrund) zu. Der Arbeitsstrukturplan zeigt die Struktur der zu leistenden Arbeit in Form von hierarchisch geordneten Arbeitspaketen. Er kann nach Funktionen oder Teilen gegliedert sein: • Produktorientiert, • Funktionsorientiert, • Tätigkeitsorientiert, • Geräteorientiert, • Phasenorientiert. Meist werden diese Prinzipien in verschiedenen Ebenen des Arbeitsstrukturplans kombiniert. Diese Gliederung ist wichtig für die • Ressourcenplanung, • Zuordnung von Verantwortung (Vergabe von Unteraufträgen), • Planung und Kontrolle (Netzplan, Projekt-Planung/-Überwachung). Die Arbeitspakete werden im Allgemeinen nach einer Dezimalstruktur (mit oder ohne Dezimalpunkt) nummeriert: Dass dabei maximal 9 Teilpakete für jedes Arbeitspaket möglich sind, dient der Übersichtlichkeit. Der Arbeitsstrukturplan kann auch graphisch mittels einer hierarchischen Kästchenstruktur wie bei einem Organigramm oder in einer halbgraphischen Darstellung durch eingerückte Listen bzw. durch Einrücken des Textes aufbereitet werden. Beim Einsatz in einem Tabellenkalkulationssystem kann diese Methode auch verwendet werden, um aggregierte Berechnungen vorzunehmen.

3.3 Projektplanung

109

Projekt 1

2

3

4

11

12

41

42

43

121

122

421

422

423

Abbildung 3-6: Graphische Darstellung WBS mit Dezimalgliederung Bei Verwendung in einem Tabellenkalkulationsprogramm können gleichzeitig die Aufwände von Arbeitspaketen in der WBS-Struktur aufaddiert werden. Tabelle 3-1: WBS mit Dezimalgliederung in Tabellenform (Auszug) AP-Nummer 4

Bezeichnung

Aufwand 127

41 42

21 75 421 422 423

14 25 36

43

31 431 432

5

14 16 111

weitere Informationen zu den Arbeitspaketen (Ressourcen, Aufwände, Kosten, Termine)

Arbeitspakete Die in der Hierarchie über den Arbeitspaketen (der untersten Ebene) liegenden Ebenen werden selbst auch als Arbeitspakete bezeichnet. Alternative Bezeichnungen sind (in abnehmender Hierarchie): • Teilprojekt (Ebene unter der Ebene des Projekts), • Teilaufgabe (allgemeine Bezeichnung), Arbeitspaket, • Vorgang (Arbeitspaket der untersten Ebene, Bezeichnung im Netzplan). Folgende Kriterien sollte ein sinnvolles Arbeitspaket erfüllen: • wohldefinierte Ziele und Aufgaben, • wohldefiniertes Ergebnis in Form eines Abschlussdokuments, einer Abschlusspräsentation oder am besten eines Reviews bzw. Audits,

110

3 Projektmanagement

• wohldefinierte Voraussetzungen, • zuordenbar an eine Person oder an eine einfach zu definierende Gruppe.

Aufstellen des Arbeitsstrukturplans Im Arbeitsstrukturplan wird die gesamte innerhalb eines Projekts zu leistende Arbeit in Arbeitspakete heruntergebrochen. Dabei kann sich diese Aufteilung an verschiedenen Prinzipien orientieren (siehe Abschnitt Gliederungsprinzipien): Die Arbeitspakete der obersten Ebene werden nun wieder verfeinert, indem man die Aufgabe wieder in Teilaufgaben zerlegt. Dabei ist wichtig, dass nichts weggelassen wird und dass Tätigkeiten, die als Schnittstelle zwischen zwei Arbeitspaketen liegen, einem Arbeitspaket zugeordnet werden. Dies kann eines der beiden betroffenen oder ein zusätzliches Arbeitspaket sein. Besonders wichtig werden diese Schnittstellen und die Konsistenz des Arbeitsstrukturplans dann, wenn mehrere Personen oder gar Gruppen an einem Projekt arbeiten. Für das Aufstellen des Arbeitsstrukturplans sollte man zunächst viel mit Bleistift und Papier arbeiten. Im Allgemeinen wird der aufstellte Plan mehrmals modifiziert, bis er eine solide Basis für die Planung abgibt. Auch wird der Arbeitsstrukturplan im Laufe der Zeit vertieft und verändert werden. Vorgehen

Das Vorgehen bei der Aufstellung kann top-down oder bottom-up erfolgen: • Aufstellen bottom-up: Beginnt mit dem Sammeln aller notwendigen Tätigkeiten, Strukturierung und Zusammenfassung. Für jedes Arbeitspaket ist dabei die Frage zu stellen: was brauche ich noch dazu? • Aufstellung top-down: Strukturiert von oben nach unten: Ausgehend von Haupttätigkeitsbereichen und Hauptkomponenten. Die Reihenfolge der obersten Ebenen kann variieren (Produkt - Aufgabenbereich - Phase). top – down: Zerlegung

Abbildung 3-7: Vorgehen top-down und bottom-up

bottom – up: Zusammenfassung

3.3 Projektplanung

111

Ein Arbeitsstrukturplan kann prinzipiell gegliedert werden nach: • Phasen (Angebot, Vorbereitung, Entwurf, Durchführung, Produktion, Dokumentation, Einführung, Auslieferung), • Tätigkeiten (Entwerfen, Produzieren, Experimentieren, Schreiben, Planen, Kommunizieren, Erstellen), • Ergebnissen (Spezifikationen, Teilergebnisse, Software, Dokumentation), • Produkten und Komponenten (physische Teile, Teilgeräte, Komponenten, Teilfunktionen, Modulen). Soweit Tätigkeiten einem Teilprodukt (Gerät, Modul, Schnittstelle) sinnvoll zugeordnet werden können, sollten sie dort angesiedelt werden. Arbeiten, die sich gegenseitig ergänzen (substituieren) sollten zusammenfassbar sein. WBS Radar Für die Entwicklung eines Radarsystems lassen sich die Arbeitsstrukturpläne nach den verschiedenen Gliederungsprinzipien folgendermaßen aufbauen:

Radar

Signalverarbeitung

Empfänger

System

Datenverarbeitung

Sender BenutzerSchnittstellen

Antenne

ComputerSchnittstellen

Abbildung 3-8: WBS Radar Teileorientiert

Radar

System

Mecha nik

Hardware

Elektronik

HochFrequenz

Software

Signalverarbeitung

Datenverarbeitung

Abbildung 3-9: WBS Radar Tätigkeitsorientiert

Je nach Größe, Struktur des Projekts, Zielen und Hauptschwerpunkten sollten die Gliederungsprinzipien auf den verschiedenen Ebenen eingesetzt werden. Ziele der Gliederung können sein:

112

3 Projektmanagement

• Modularisierung des Objekts, Wiederverwendung von Teilen, Kostenzu-

rechnung zu einzelnen Teilen, • Modularisierung der Aufgabe (eventuell mit Unterauftragnehmern,

Fremdvergabe bzw. Steuerung von verschiedenen Kostenstellen), • Kaufmännisches Projektcontrolling (Überwachung von Kosten und Er-

gebnissen über die Zeit), • Projektmäßiges Controlling (Erfassung der Ergebnisse, des Entwick-

lungsstands und der zugehörigen Aufwände). Je nach Zielsetzung eignet sich diejenige WBS-Struktur am besten, die jeweils die gewünschte Art der Zusammenfassung liefert. Überprüfung des WBS

Eine wichtige Überprüfung für Arbeitsstrukturpläne ist die unabhängige Zusammenstellung einer Liste von Tätigkeiten und Entscheidungen. Für diese Tätigkeiten bzw. Entscheidungen ist beispielsweise zu fragen: • In welchem AP wird diese Tätigkeit durchgeführt? Sind alle beteiligten Personen im AP berücksichtigt? • In welchem AP werden die notwendigen Materialien und Informationen beschafft? Welches AP entwickelt die notwendigen Teile? Welches AP stellt die notwendigen Dokumente zur Verfügung? • Welche AP nutzen die Ergebnisse dieses AP? Wohin wird das Ergebnis kommuniziert? • In welchem AP sind die zugehörigen Aktivitäten für Projekt- und Qualitätsmanagement? Sind die Anforderungsanalyse und Test in diesem oder einem anderen AP beinhaltet? Dies ist im Sinne eines Tests zu sehen: Wenn hier vergessene APs auftauchen, muss der WBS überarbeitet werden. Größe von Arbeitspaketen Die Größe von Arbeitspaketen der untersten Ebene wird in der Literatur und in der Praxis verschieden angegeben. Dies liegt zum Teil auch daran, dass in Großprojekten die Arbeitspakete vom Arbeitspaketverantwortlichen (Person oder Firma) selbst wieder als Projekt geplant und entsprechend herunter gebrochen werden und dort selbst bei einer größeren Tiefe des Arbeitsstrukturplans noch große Pakete übrig bleiben. Eine Arbeitspaketgröße von 1 MJ (Personenjahr) oder 100 000 € macht bei großen Projekten einen Sinn, kleine Projekte können ja durchaus selbst in dieser Größe sein. Als Minimalgröße für die Arbeitspakete kann man 1 MT (Personentag) und bei Sachmitteln 1000 € ansetzten. In der Regel sollten die Arbeitspakete umfangreicher sein. Generell kann man sagen, dass mit der Größe des Projekts so-

3.3 Projektplanung

113

wohl die Anzahl und Tiefe der Arbeitspakete als auch die Größe der Arbeitspakete anwachsen. 3.3.3

Schätzungen

In allen Phasen des Projekts müssen Schätzungen gemacht werden, insbesondere bei der Planung für Zeiten, Aufwand, Personalbedarf und Kosten. Auch im technischen Bereich sind Abschätzungen für Belastungen und technische Größen notwendig. Schätzungen sind immer mit Unsicherheit behaftet. Ziel ist aber, diese Unsicherheit zu kennen, wenn möglich zu minimieren und auf jeden Fall sinnvoll damit umzugehen. Einen Faktor 50% bei der Schätzung von Aufwänden für Projekte muss man ohne Vorkenntnisse einkalkulieren, allein der Faktor bei der Produktivität von Personal ist teilweise höher. Nur durch entsprechende Vorkenntnisse und eine Anpassung des Projektdreiecks an die Erfahrungen im Laufe des Projekts kann ein Projekt im Rahmen der Schätzungen für das Projektdreieck abgeschlossen werden. Die beste Basis für Schätzungen ist Erfahrung, am besten in Form von Daten. Sind solche nicht vorhanden, können Modelle als Basis von Schätzungen dienen. Der schlechteste Ratgeber sind politische Entscheidungen (meist als „strategische Überlegungen“ bezeichnet), in denen das geschätzt wird, was das jeweilige Management als Basis seiner Entscheidung hören möchte. Wichtig bei Schätzungen ist eine Systematik. Egal ob eine Schätzung auf Grund von Erfahrung (Expertenwissen), statistischen Verfahren oder Modellen vorgenommen wird, die Annahmen und Methoden müssen klar definiert sein und dokumentiert werden. Sinnvoll ist, mehrere unabhängige Schätzungen zu kombinieren. Dies kann z.B. durch mehrere Schätzer in Form einer mehrphasigen Schätzung (Schätzklausur) geschehen. Dazu gibt zunächst jeder Teilnehmer einen Schätzwert an. Anschließend geben diejenigen Personen mit dem kleinsten und größten Schätzwert die jeweiligen Begründungen für ihre Werte. Ein weiterer Informationsaustausch kann folgen. Dies gibt für alle Beteiligten zusätzliche Informationen, so dass in der zweiten Runde die Treffsicherheit deutlich verbessert wird. Schätzung Das folgende Beispiel gibt einen guten Einblick in die Methodik und Genauigkeit von Schätzungen. Die Aufgabe sei: „Schätzen Sie die Geldmenge an Münzen in diesem Raum“.

114

3 Projektmanagement

Im Allgemeinen wird implizit angenommen, dass die Menge „möglichst genau“ zu schätzen ist. Die Aufgabe, den wahren Wert nicht zu unterschreiten (mit der Auflage, die Differenz bezahlen zu müssen) liefert natürlich andere Werte, analog bei Überschreitung. Solche systematischen Fehler können auch durch mehrfaches Schätzen nicht eliminiert werden. Obwohl typischerweise die einzelnen Personen Geldmengen zwischen 0 und 20€ im Geldbeutel haben und sich die Schätzungen (pro Person heruntergerechnet) zwischen 1€ und 20€ bewegen, ergibt sich selbst bei relativ kleinen Gruppen (ca. 20 Personen) ein stabiler Mittelwert zwischen 3€ und 4€. Die Schätzung kann verbessert werden, wenn man eine zweiphasige Schätzmethode anwendet.

Methodik und Einflüsse Eine Schätzung ist nichts absolutes, sondern abhängig vom jeweiligen Informationsstand. Dabei kann man von folgenden Einflüssen ausgehen: 1. Die Schätzung wird im Laufe der Zeit immer genauer, da die Information zunimmt. 2. Die Schätzung wird genauer, wenn ein Teil des zu Schätzenden bereits realisiert ist. Sie ist abgeschlossen, wenn das zu Schätzende abgeschlossen und dokumentiert ist (Reporting, Controlling). 3. Eine Schätzung gibt nicht nur einen wahrscheinlichsten Wert, sondern eine Wahrscheinlichkeitsverteilung oder ein Vertrauensintervall, in dem der Wert mit hinreichender Wahrscheinlichkeit liegen wird. 4. Eine Schätzung kann nicht aussagekräftiger sein als die Definition und die Messmethode für die zu schätzende Größe (Restunsicherheit). Eine Schätzung (Prognose) sollte immer mit einem Verlässlichkeitsintervall (Prognosekorridor) angegeben werden. Dafür bieten sich die bekannten Prinzipien an: • Grenzen: Es wird zusätzlich zum wahrscheinlichsten Wert eine obere und untere Grenze geschätzt. • Varianzen: Es wird zusätzlich zum Mittelwert eine Varianz bzw. Standardabweichung geschätzt. Ober- und Untergrenzen ergeben sich - je nach angestrebter Verlässlichkeit - aus dem Mittelwert zuzüglich/abzüglich eines Vielfachen der Standardabweichung. Ein Intervall kann aus den Quantilen bzw. Vielfachen der Varianzen gebildet werden. • Quantile: Es werden zu gegebenen Irrtumswahrscheinlichkeiten Quantile geschätzt oder aus den Standardabweichungen berechnet. • Fuzzy: Die Prognose wird als linguistische Variable angegeben, d.h. den einzelnen Schätzwerten werden Plausibilitäten zugeordnet. (Plausibilitätsintervalle).

3.3 Projektplanung

115

Jede Schätzung legt nun einen Schätzkorridor fest, in dem sich der zu schätzende Wert bewegen wird. Durch die zunehmende Information wird der Schätzkorridor im Laufe der Zeit enger, die Obergrenze sinkt, die Untergrenze steigt an. Der Erwartungswert kann im Schätzkorridor variieren. Bei einem Schätzfehler müssen die Grenzen nach außen korrigiert werden. Aufgrund der Zeitverzögerungen durch das Berichtswesen, erreicht der Schätzwert den wahren Wert erst eine gewisse Zeit nach Projektende.

Schätzkorridor (max)

Korrektur der Schätzung

Schätzwert Schätzkorridor (min)

Verbesserung der Schätzung

Projektende

Projektabschluss

Termin der Schätzung

Abbildung 3-10: Entwicklung der Schätzkorridors Es ist wichtig, die Schätzungen und die Schätzintervalle zu aktualisieren und die notwendigen Konsequenzen zu ziehen. Dazu müssen die Schätzungen so aktualisiert werden, dass zu den jeweiligen Entscheidungszeitpunkten Schätzungen optimaler Qualität vorliegen. Werden die Schätzungen aus einzelnen Schätzungen zusammengefasst, so ist ein hinreichender Vorlauf zu planen. Die möglichst frühzeitige Anpassung von Schätzungen und das Erkennen von "Driften" ist eine wichtige Aufgabe des Projektcontrollings. Solche Schätzungen betreffen das gesamte Projektdreieck: Termine: Meilensteintrendanalyse, Kosten: Mittelabflusskontrolle, Mittelfestlegung, Qualität: Qualitätsüberwachung: Performance und Qualitätsmerkmale des Produkts. Präzision, Richtigkeit und Genauigkeit Bei Schätzungen spielen die bereits als Produkteigenschaften betrachteten Begriffe Präzision, Richtigkeit und Genauigkeit eine wichtige Rolle.

116

3 Projektmanagement

Während die Präzision als interne Abweichung durch zufällige Fehler mit statistischen Verfahren einfach festgestellt und gemessen und durch Wiederholung verbessert werden kann, basiert die Richtigkeit auf der Übereinstimmung mit der Realität. wahrer Wert

Schätzung (Verteilung)

geringe Präzision und Richtigkeit

hohe Präzision, aber geringe Richtigkeit

hohe Richtigkeit, aber geringe Präzision

hohe Präzision und Richtigkeit hohe Genauigkeit

Abbildung 3-11: Präzision und Richtigkeit von Schätzungen Geringe Richtigkeit beruht auf einer systematischen Abweichung zwischen Messung und Realität. Solche systematischen Fehler können im Gegensatz zu den zufälligen Schwankungen (geringe Präzision) nur durch unabhängige Schätzprinzipien erkannt und verbessert werden. Dies korreliert mit dem Problem der Verifikation (interne Syntax) und Validierung (externe Semantik) bei Modellen und Spezifikationen. Tabelle 3-2: Genauigkeit von Schätzungen Bedeutung geringe Schwankung Richtigkeit Erwartungstreue BrauchVerlässlichbarkeit keit Präzision

Verbesserung Mehrere Schätzungen, Wiederholung, Aufteilung (WBS) Verschiedenen Schätzprinzipien, Anpassung, Erfahrungsdatenbank Begriffsklärung, Modellierung, Konsensbildung

Analogie Modell Syntax, Verifikation Semantik, Validierung Pragmatik

3.3.4 Zeitplanung

Termine sind in Projekten am ehesten sichtbar. Terminverzug ist immer einen klare Sache und auch leicht kommunizierbar. Mangelnde Qualität, Risiken, zu hoher Ressourcenverbrauch und Kostenüberschreitungen sind dagegen viel weniger deutlich unmittelbar sichtbar.

3.3 Projektplanung

117

Deshalb sind Projekttermine immer stark unter Beobachtung. Sie haben auch den Vorteil, dass sie sich z.B. durch Meilensteine leicht definieren lassen. Ziel Ziel der Zeitplanung ist, festzustellen, in welcher Zeit das Projekt abgearbeitet werden kann. Die Netzplantechnik bestimmt die kürzest mögliche Zeit und die kritischen Pfade. Darüber hinaus werden die Aufgaben zu Zeitintervallen zugeordnet und es werden Fertigstellungstermine für die Aufgaben festgelegt. Diese Fertigstellungstermine und weitere wichtige Termine – insbesondere Schnittstellen nach außen – werden im Meilensteinplan festgelegt. Arche Noah Der Bau der Arche Noah wird gerne als Bespiel für die Zeitplanung genommen. Einige Eigenschaften sind typisch für Projekte: Es ist klar, dass der Bau rechtzeitig vor der Sintflut fertig werden musste, der Termin ist also klar. Die Aufgaben sind stark arbeitsteilig, da beispielsweise die Holzbearbeitung für Rumpf und Planken parallel erfolgen konnte, andererseits können die Aufbauten erst nach der Fertigstellung des Rumpfs montiert werden. Auch die Auswahl und Sammlung der Tiere und Pflanzen konnte parallel zu Bau der Arche erfolgen. Die rechtzeitige Initiierung der einzelnen Aufgaben ist also ein wichtiger Erfolgsfaktor.

Häufig wird bei Zeitplänen die Vorlaufphase (Projektinitiierung) nicht berücksichtigt, da sie ja zu Zeitpunkt der Planerstellung schon abgeschlossen ist. Im Rahmen einer termingebundenen Arbeit ist aber die Berücksichtigung und Nutzung von Vorlaufzeiten und Nacharbeiten extrem wichtig. Dies gilt insbesondere für die Projektplanung selbst und die Angebotsbearbeitung. Die Angebotsbearbeitung ist selbst ein Teilprojekt und entsprechend zu planen. Phasenkonzepte Eine der wichtigsten und einfachsten Methoden der Zeitplanung ist die Einteilung des Projekts in Phasen. Phasenkonzepte (Phasenmodelle) liefern hierfür allgemeine Vorgaben, die dann für das spezielle Projekt angepasst werden müssen. Phasenkonzepte teilen Elemente des Projekts zu Phasen eines standardisierten Ablaufes ein. Vorgehensmodelle stellen Elemente des Projektmanagements und der Objektbearbeitung zu Prozessen und Phasen eines standardisierten Ablaufes zusammen. Die einfachste und wohl wichtigste Methode zur Gliederung eines Projekts ist die zeitliche Einteilung in aufeinander folgende Phasen. Der Abschluss

118

3 Projektmanagement

jeder Phase ist der Beginn der nächsten und gleichzeitig ein Meilenstein im Vorgehen. Als frühe Beispiele von Phasenmodellen könnte man die Abläufe „Suchen Sammeln - Bergen - Lagern – Verwerten“ bei Sammlern bzw. „Aufsuchen Nachstellen - Erlegen – Inbesitznahme - Bergen“ bei Jägern betrachten. Der Phasenablauf macht den Projektbeteiligten klar, welche Aufgaben anstehen und was ihre Aufgaben und Rollen sind. Ein allgemeines Phasenmodell der Problemlösung konnte etwa so aussehen: • Zielsetzung (Definition der gewünschten Eigenschaften des zu erreichenden Zustands und der zugehörigen Zielkriterien), • Ist-Analyse (Analyse der Ausgangssituation), • Soll-Konzeption (konkrete Umsetzung des Ziels, Definition des Soll-Zustands), • Umsetzungskonzept (Planung der Übergangs vom Ist- zum Soll-Zustand), • Umsetzung (Durchführung des Übergangs vom Ist- zum Soll-Zustand), • Überprüfung (Prüfung des ereichten Zustands auf Erreichung des Ziels). Projektorientiert könnte ein Phasenmodell folgendermaßen aussehen: • Projektinitiierung und Definition, • Projektplanung, • Projektumsetzung, • Projektabschluss und Evaluierung. Vorgehensmodelle Vorgehensmodelle gliedern den Verlauf eines Projekts in Teilabschnitte (Phasen, die sich aber möglicherweise auch überlappen) mit zugehörigen Aufgaben und Methoden. Sie sind neben der Aufgabenteilung und den Phasenkonzepten eine der elementaren Methoden des Projektmanagements. Sie legen nicht nur den Ablauf fest, sondern geben parallele Bearbeitungspfade (z.B. für die Objektbearbeitung, Management, Qualitätssicherung, Testen) vor. Vorgehensmodelle sind immer auf eine bestimmte Art von Projekt ausgerichtet.

3.3 Projektplanung

119

Jagd Das Phasenkonzept „Aufsuchen - Nachstellen - Erlegen – Inbesitznahme – Bergen“ gilt allgemein für die Jagd. Die Jagd mit Fallen bringt bereits ein anderes Phasenkonzept. Abhängig von den zur Verfügung stehenden Waffen und Kommunikationsmitteln bzw. von Fallen, von den räumlichen Bedingungen und der Art und Häufigkeit des bejagten Wilds ergeben sich bestimmte Jagdmethoden. Sobald eine Arbeitsteilung z.B. beim Aufscheuchen, Hetzen, Abfangen oder bei der Vorbereitung des Bergens bzw. Verwertens auftritt, liegt ein Vorgehensmodell vor.

Meilensteine Meilensteine sind terminlich festgelegte Zeitpunkte. Sie müssen durch ein nachprüfbares Ergebnis definiert sein. Das Ergebnis kann formalisiert werden in Form von Kriterien wie • Review, Präsentation, Überprüfung eines Ergebnisses, • Abnahme eines Ergebnisses oder Dokuments, • erfolgreicher Abschluss eines Tests, • Ende einer Phase. Ein Meilenstein ist abgearbeitet bzw. die Phase ist abgeschlossen, wenn das Ergebnis endgültig fertig und abgenommen bzw. geprüft ist. Meilensteine müssen immer wohldefiniert sein, d.h. es muss klar sein, welches Ergebnis oder Kriterium zum Meilenstein erfüllt sein muss. Ein Kriterium wie "sechs Wochen gearbeitet" definiert weder ein Phasenergebnis noch einen gültigen Meilenstein. Die Erschöpfung von Ressourcen (Zeit, Geld, Entwicklermonate, Nutzungsdauer) impliziert nicht das Erreichen des Meilensteins. (Wenn ich von Ulm in 6 Stunden nach Hamburg will und in Hannover geht nach 6 Stunden der Sprit aus, bin ich deshalb noch nicht am Ziel.) Meilensteine im Projekt können insbesondere sein: • Abnahme von Dokumenten und anderen Deliverables, • Phasenabschlüsse. Am günstigsten sind Reviews bzw. Audits als Meilensteine. Diese können formal geschehen (mit festgelegten Inhalten, Abläufen und Kriterien) oder auch einfach in der Form einer Präsentation. Meilensteine sind auch nach außen relevant: • die Bezahlung orientiert sich an Meilensteinen (milestone payment plan), • Festlegungen und Festschreibung werden durch den Meilenstein verbindlich (Wasserfallkonzept: mit Erreichen eines Meilensteins werden die bis dahin gemachten Ergebnisse, Entscheidungen und Dokumente unwiderruflich festgeschrieben). Wichtige Meilensteine sind Zwischentermine, bei denen Dritte Ergebnisse, Informationen oder Materialien brauchen oder bei denen Ergebnisse, Infor-

120

3 Projektmanagement

mationen oder Materialien von Dritten benötigt werden. Dritte können hier andere Teilprojekte und Arbeitspakete, Auftraggeber, Unterauftragnehmer, Projektbeteiligte und Stakeholder, oder andere Teams und Abteilungen sein. Auf die Funktion von Meilensteinen als Entscheidungspunkte (Zäsuren, Gates) für die Entscheidung über Abbruch oder Fortsetzung des Projekts werden wir noch eingehen. Selbst wenn im Projekt kein Netzplan aufgestellt wird, sollte ein Meilensteinplan erstellt werden. Dieser kann auf dem Arbeitsstrukturplan basieren. Als Basis dafür eignet sich auch eine einfache Phaseneinteilung der Arbeit. Beispiele für Meilensteine Je nach Art der Arbeit können die zu verwendenden Meilensteine verschieden ausfallen. Ein Meilenstein kann beispielsweise im Abschluss eines wichtigen oder zeitkritischen Arbeitspakets bestehen. Bei Entwicklungsprojekten hat es sich im Rahmen der Qualitätssicherung bewährt, Phasen durch formale Prüfungen der Ergebnisse (Reviews) abzuschließen. Wichtig ist, dass damit nicht die Abarbeitung einer Zeitspanne oder das Ausdrucken eines Dokuments, sondern eine kritische Überprüfung und Akzeptierung der Ergebnisse (möglichst durch den jeweiligen Nutzer) als Kriterium genommen wird. Mögliche Meilensteine im Software Engineering sind: • Angebot erstellt (wenn dies nicht detaillierter aufgegliedert wird), • Auftrag erteilt (auch Vorstufen wie Letter of Intent), • Aufgabenbeschreibung abgeschlossen (Projektpräsentation), • Bedarfsanalyse abgeschlossen (Requirements Review), • Algorithmen, grundlegende Datenstrukturen und Schnittstellen definiert, • Spezifikation abgeschlossen (Specification Review), • Entwurf abgeschlossen (Preliminary Design Review), • Programmentwurf abgeschlossen (Program Design Review), • Testdaten beschafft (Durchsprache mit Kunde), • Codierung abgeschlossen (Code Review), • Integration abgeschlossen (Interne Vorführung), • Tests abgeschlossen (Verifikation, Test Review), • Dokumentation fertiggestellt (Testleser, Dokumentenabnahme), • Präsentation vor Nutzer (Acceptance Review), • Nutzertest erfolgreich (Validierung, Acceptance Test).

3.3 Projektplanung

121

Grundlagen der Netzplantechnik Der Netzplan baut auf folgenden Prinzipien auf: • Es gibt eine Nachfolger-Beziehung zwischen den Vorgängen. • Eine Tätigkeit kann erst begonnen werden, wenn die als Voraussetzung notwendigen Tätigkeiten abgeschlossen sind. Dies ist im Allgemeinen richtig, eine konsequente Befolgung dieses Prinzips erfordert allerdings eine sehr hohe Detaillierung des Netzplans (Phasenvorlauf, Bestellungen, Einarbeitung, parallele Tätigkeiten, Dauertests, Nacharbeiten) und ist in der Praxis nicht durchführbar (aus der daraus folgenden Überlappung ergeben sich stille Reserven). Aus den mit Zeitdauern versehenen Arbeitspaketen und dem Wissen, welches Arbeitspaket auf welchen anderen basiert, kann der Netzplan aufgestellt werden. Dazu wird zunächst festgestellt, welche Arbeitspakete für ihren Beginn die Beendigung welches anderen Arbeitspakets voraussetzen. Hier zeigt sich, ob der Definition der Arbeitspakete im Arbeitsstrukturplan sinnvoll war, gegebenenfalls müssen Arbeitspakete zu Vorgängen zusammengefasst oder unterteilt werden. Die Berechnung der Dauer liefert früheste und späteste Anfangs- und Endtermine, Puffer (Schlupf-) Zeiten und den kritischen Pfad. Weitere zusätzliche Beschränkungen ergeben sich durch die verfügbaren Ressourcen. Der Netzplan liefert z.B. ein Personalgebirge und wenn aus Kapazitätsgründen nicht alle Tätigkeiten parallel ausgeführt werden können, sind Modifikationen notwendig. Generell müssen im Netzplan berücksichtigt werden: • Vorgänge = Prozesse ( = Arbeitspakete ), • Ereignisse = Zustände ( = Meilensteine ). Im Graphen haben wir: • Knoten = Ecken (in der mathematischen Beschreibung die Grundmenge, in der graphischen Darstellung flächige oder punktförmige Objekte), • Kanten = Pfeile (in der mathematischen Beschreibung eine Relation auf der Grundmenge, in der graphischen Darstellung Linien zwischen den Knoten). Damit ergeben sich verschiedene Kombinationsmöglichkeiten:

122

3 Projektmanagement

Tabelle 3-3: Arten von Netzplänen Art

Basis

Umsetzung der Basis- Ergänzung elemente (duale Elemente) Vorgangs- Vorgänge, Prozesse (Vorgänge) Zustände (Ereignisse, Meilensteipfeilnetz- Prozesse werden abgebildet als ne) werden abgebildet als Knoten werk: Pfeile. (Ende bzw. Anfang von Pfeilen) Ereignis- Ereignisse, Ereignisse (MeilenProzesse (Vorgänge) werden knotenMeilensteine) werden abge- abgebildet als Pfeile, die die netzwerk steine bildet als Knoten Knoten verbinden Vorgangs- Vorgänge, Prozesse (Vorgänge) Logische Folgebeziehungen knotenProzesse werden abgebildet als werden abgebildet als Pfeile zwinetzwerk Knoten schen den Knoten Ereignispfeilnetzwerke werden in der Praxis nicht verwendet.

Das Vorgangsknotennetzwerk Von den vielen Möglichkeiten, Netzpläne zu definieren und zu verwenden, sei hier das deterministische Vorgangsknotennetzwerk mit Vorwärts- und Rückwärtsrechnung angesprochen. Die folgende kurze Darstellung soll die Grundlagen erläutern, für weiterführende Details sei auf die umfangreiche Literatur verwiesen. Der Rechenvorgang teilt sich auf in eine erste Rechenphase (hier: Vorwärtsrechung), in der die Terminierung ausgehend von Start vorgenommen wird und die zweite Phase, in der in der entgegengesetzen Richtung gerechnet und so Pufferzeiten bestimmt werden. Ausgehend vom Netzplan wird zunächst die Vorwärtsrechnung durchgeführt. Ausgangspunkt und frühester Anfangstermin aller Knoten ohne Vorgänger ist der Startzeitpunkt, z.B. T = 0. Dann wird für jeden Knoten folgende Rechnung durchgeführt: • Frühester Anfangstermin FAT: zu diesem Termin kann der Knoten aufgrund der notwendigen Vorarbeiten frühestens begonnen werden. Er ist der späteste Wert unter allen (frühesten) Endterminen der Vorgängerknoten: FAT = max FET (über alle Vorgänger). • Frühester Endtermin FET: zu diesem Zeitpunkt kann der Knoten frühestens fertig sein. Er ergibt sich als Summe aus dem (frühesten) Anfangstermin und der Dauer des Knotens: FET = FAT + DAUER. Wenn die Vorwärtsrechnung abgeschlossen ist, kennt man die minimale Dauer des Projekts. Sie ist der (früheste) Endtermin des spätesten Knoten. Nun kann man sich diesen Wert oder eine für das Projekt sinnvolle Dauer vorgeben, um die analoge Rückwärtsrechnung zu starten. Als Ausgangs-

3.3 Projektplanung

123

punkt wird nun der Endtermin genommen, er ist spätester Endtermin aller Knoten ohne Nachfolger. Analog zu FET und FAT berechnet man nun die spätesten Anfangs- und Endtermine SAT und SET. Tabelle 3-4: Richtungen der Netzplanberechnung Richtung vorwärts

ausgehend von Start (FAT)

rückwärts

Ende (SET)

Terminierung Basisformeln früheste FET = FAT + Dauer FAT = max FET(Vorgänger) späteste SAT = SET – Dauer SET = min SAT(Nachfolger)

Dadurch erhält man für jedes Element des Netzplans (d.h. für jedes betrachtete Arbeitspaket AP) folgende Werte: • MAXDAUER = SET – FAT ist die maximal verfügbare Zeit. • PUFFER = MAXDAUER – DAUER ist die Pufferzeit (Schlupf), die bei der Bearbeitung dieses Knotens verfügbar ist. Arbeitspakete ohne Pufferzeit (PUFFER = 0) heißen kritisch, sie bilden den sogenannten kritischen Pfad im Projekt. Wird die Pufferzeit eines Knoten verbraucht, werden dadurch im Allgemeinen andere Knoten kritisch. Wegen der oben genannten Zusammenhänge gilt PUFFER = SAT – FAT = SET – FET. Gantt-Diagramm Eine graphische Darstellung des Netzplans ist das Gantt-Diagramm. Hier bekommt die horizontale Achse die Bedeutung der Zeit. Die Balken stellen die Arbeitspakete (Vorgänge) dar und erhalten als Länge die jeweilige Dauer und als Position die geplante Anfangszeit (üblicherweise FAT). Das Gantt-Diagramm veranschaulicht den zeitlichen Ablauf sehr gut, es wird aber bezüglich der Abhängigkeiten zwischen Vorgängen (Arbeitspaketen) sehr schnell unübersichtlich. Gantt-Diagramme können mit Graphik-Programmen, ProjektmanagementSoftware oder basierend auf Tabellen dargestellt werden.

Tabelle 3-5: Einfaches Gantt-Diagramm auf Tabellenbasis 1 V1 V2 V3 V4

2

3

4

5

6

7

8

9

10 11

Zeit

124

3 Projektmanagement

Personalauslastung Der Netzplan hat den Nachteil, dass er die Personalauslastung und die Nutzung von anderen Projektressourcen nicht berücksichtigt. Er macht nur Sinn, wenn alle Vorgänge, die von der Logik her parallel ablaufen können, auch vom den Ressourcen (Personal, Maschinen) her parallel laufen können. Aus dem Netzplan kann man nun aber das Personalgebirge ermitteln, personalkritische Bereiche feststellen und diese dann entzerren.

Tabelle 3-6: Personalgebirge auf Tabellenbasis 6 5 4 3 2 1 1

2

3

4

5

6

7

8

9

10

12

12

13

14

Prozesse, die sich mit der Netzplantechnik gut einplanen lassen oder die den Einsatz der Netzplantechnik notwendig machen können, sind solche, die lange Zeiten mit logischen Abhängigkeiten, Vorlaufzeiten oder geringer Personalauslastung beinhalten. Wenn die Arbeit von einer einzigen Person ausgeführt wird und diese über die Dauer mit der jeweiligen Tätigkeit voll ausgelastet ist, so führt der Ausgleich der Personalauslastung dazu, dass die Gesamtdauer gleich der Summe der Einzeldauern wird. Die Netzplantechnik kann dann nur noch die logische Reihenfolge zwischen Arbeitspaketen überwachen. Wenn sich Vorgänge (Arbeitspakete) verschieben lassen, kann man das Personalgebirge entzerren und die Auslastung glätten. Tabelle 3-7: Personalgebirge auf Tabellenbasis geglättet 6 5 4 3 2 1 1

2

3

4

5

6

7

8

9

10

12

12

13

14

3.3 Projektplanung

3.3.5

125

Ressourcenplanung

Ziel der Ressourcenplanung ist, die benötigten Ressourcen insgesamt und in ihrer zeitlichen Verteilung zu ermitteln. Daraus können dann die Projektkosten ermittelt werden. Die Planung basiert auf unsicheren Werten, gute Schätzungen können nur die Genauigkeit erhöhen und das Risiko vermindern. Personalaufwand Basis der Kostenschätzung ist das Produkt aus Zeit und Personalmenge. Der "Mann-Monat" (kleinere Einheit Entwickler-Tag, ETg) mag als Produktivitätsmaß umstritten sein, als Kostenmaß ist er recht brauchbar (Gehaltsdifferenzen sind meist kleiner als Produktivitätsdifferenzen). Auch hier muss man sich über das verwendete Modell und die Basis der Rechnungseinheit Gedanken machen. Die Abschätzung des Personalaufwands für ein Projekt erfordert Erfahrung und Disziplin. Die Aufteilung von Aufgaben (Arbeitsstrukturplan) hilft, Aufgaben besser abschätzen zu können (bessere Übersichtlichkeit und höhere Anschaulichkeit der Aufgabe, statistischer Ausgleich von Fehlern). Ein systematischer Fehler muss aber vermieden werden, indem zu Beginn der Schätzung klar die Basis der Zeit definiert wird. So muss zwischen Anwesenheitszeit, ungestörter Arbeitszeit und Produktivitätszeit unterschieden werden. Besonders wichtig ist dies bei Prozessen mit Kundenkontakt, die Vor- und Nachbereitung erfordern. Aufwände im Hobby- und professionellen Bereich Ein System, das man „an einem Nachmittag“ programmiert oder manuell fertigt, kann nicht mit einem halben Tag Aufwand entwickelt werden. Die folgende kleine Beispielrechnung soll die Differenz zwischen einer "schnellen Lösung" und einem systematischen Entwicklungsprojekt verdeutlichen: Der „Nachmittag“ rückblickend (intensiver Einsatz von 13h bis 21h) 8 Std. Fertigung /Codierung hochgerechnet auf Entwicklungszeit (Faktor 5) 40 Std. 1 Std. ungestörte Arbeitszeit entspricht Anwesenheit (Faktor 2 bis 10) 80 Std. Dies sind bei 8 Std. (brutto) pro Tag 10 Tage

Die Aufwände für das gesamte Projekt können als Summe der Teilaufwände über den Arbeitstrukturplan ermittelt werden. Dabei ist es wichtig, die Aufwände und die vorhandenen Ressourcen realistisch einzuschätzen. Eine wichtige Grundlage dafür ist, Aufwände und Ressourcen mit demselben Maßstab zu messen, also entweder Arbeitstage oder Stunden zu verwenden. Eine Schätzung mit Stunden verführt leicht dazu, die Netto-Arbeitszeit (produktive Arbeitszeit) aufzuaddieren und dann mit

126

3 Projektmanagement

einer Arbeitszeit von 8 bis 10 Stunden abzudividieren. Dabei werden gerne Ressourcenfresser vergessen, so dass der entstehende Zeitplan sehr schnell nicht eingehalten werden kann. Typische Ressourcenfresser sind: • Notwendige Pausen (Kaum jemand kann 10 Stunden am Stück konzentriert hochwertige geistige Arbeit leisten), • Notwendige projektinterne Kommunikation (Besprechungen, Vorträge), • Externe (auch firmeninterne) Störungen im privaten und dienstlichen Bereich (Kunden, Vorgesetzte, Kollegen, Mitarbeiter, Freunde, Familie), • Notwendige Hilfstätigkeiten (Materialbeschaffung, Wartung, Installation, Sicherung, Dokumentation), • Wegezeiten und Wartezeiten (Bibliothek, Datenbanken, Logistik), • Notwendige Tätigkeiten im Laufe des Tages, der Woche, des Jahres (Verwaltungsarbeit, Archivierung). Hier ist es hilfreich, sich vor Erstellung des Arbeitsstrukturplans Gedanken darüber zu machen, ob die Arbeitspakete in Netto-Stunden oder BruttoStunden geschätzt werden und ob die Umrechnung in Tage, Wochen und Jahre auf der Basis von Standard-Arbeitnehmerdaten (z.B. 5-Tage-Woche) erfolgen soll oder ob Urlaubszeiten und Wochenenden explizit mitgezählt werden. Dies betrifft dann insbesondere die Umrechnung von Ressourcen auf Kalenderdaten. Ressourcenplan Für den endgültigen Ressourcenplan müssen Bedarf und zur Verfügung stehende Ressourcen auch im zeitlichen Verlauf gegenübergestellt und abgeglichen werden. Dies betrifft nicht nur die Gesamtsumme an Ressourcen und Zeit, sondern auch die zeitliche Verteilung in Personalgebirge und Liquiditätsplanung. 3.3.6 Projektplan

Zur Erstellung des endgültigen Projektplanes muss im magischen Projektdreieck der Bedarf an Ressourcen und Zeit, der sich aus den Anforderungen an das Projektziel ergibt, abgeglichen werden mit den zur Verfügung stehenden Ressourcen und der zur Verfügung stehenden Zeit. Alternativ kann aus den zur Verfügung stehenden Ressourcen und der zur Verfügung stehenden Zeit das erreichbare Ziel abgeleitet werden. Nun muss im magischen Projektdreieck ein Ausgleich erreicht werden, bei dem das Ziel mit den Vorgaben an Ressourcen und Termin erreicht werden kann.

3.4 Projektsteuerung und Abschluss

127

gefordertes Ergebnis

mögliches Ergebnis benötigte Ressourcen

verfügbare Ressourcen

verfügbare Zeit

benötigte Zeit

Abbildung 3-12: Magisches Projektdreieck zwischen Ziel und Machbarkeit

3.4 Projektsteuerung und Abschluss Das Projekt soll gut laufen

Ein Projekt ist nicht nur zu planen, sondern laufend zu überwachen und durch geeignete Steuerungsmaßnahmen zum Erfolg zu bringen. Schätzungen müssen laufend angepasst werden und die Planung wird im Laufe der Zeit besser und genauer. 3.4.1

Projekt-Controlling Übersicht

Die Projekt-Planung und Überwachung kann man vergleichen mit einer Autofahrt: • Die Planung legt fest: Abfahrttermin, Zwischenstationen mit Terminen, Stationen zum Tanken, Endstation und Ankunftstermin • Eine Überwachung betrifft: − Termine und Meilensteine: „wann bin ich wo?“ − Ressourcen: Sprit, Spritverbrauch in Relation zu zurückgelegter und verbleibender Entfernung, Extrapolation „wie weit reicht der Sprit?“ − Ergebnisse: Meilensteine und Fahrtstrecke (z.B. bei Umleitungen), zurückgelegte Entfernung und Restentfernung, erreichte Stationen. Die Planung sagt also, wann man wo sein möchte, das Controlling überwacht diese Größen im Zusammenhang. Allgemein gilt: Die Daten des Projekts müssen erfasst und mit der Planung verglichen werden. Daraufhin erfolgen Reaktionen. Das ganze führt zu einem Regelkreis.

128

3 Projektmanagement R ückmeldung, N euplanung

P rojekt – P lan (S O L L -M odell)

Z ielüberprüfung und Anpassung

B erichtswesen F eststellen des IS T Z ustands (M odell)

SOLLIS T Vergleich

F eststellen von Abweichungen E ntscheidung

klassischer operativer R egelkreis

P rojekt (S ystem, R ealität

operative Umsetzung der M aßnahmen

Abbildung 3-13: Controlling-Regelkreise im Projekt 3.4.2

Projektüberwachung

Im Rahmen des Projektdreiecks ist jeder der drei Eckpunkt zu planen und zu überwachen. Überwachung von Qualität und Fertigstellungsgrad (Leistung)

Überwachung des Ressourcenverbrauchs (Kosten)

Überwachung der Termine (Meilensteine)

Abbildung 3-14: Controlling im Projektdreieck Überwachung im Projektdreieck Die Überwachung wird erleichtert, wenn man die Schätzungen auf APEbene durchgeführt hat und dort überwachen kann: Termine: Meilensteine und AP-Dauern im Netzplan Kosten: Mittel (Ressourcen) als Summe der Mittel der APs Qualität: Performance und Qualitätsmerkmale ergeben sich aus den Teilen Für in Arbeit befindliche AP kann die Schätzung angepasst werden: Die Relation zwischen den Schätzungen für das AP und den dem derzeitigen Fertigstellungsgrad entsprechenden Dauer, Kosten und Ergebnissen gibt einen Hinweis auf die noch zu erwartenden Dauer, Kosten und Ergebnisse. Dabei ist die Extrapolation nicht immer so einfach oder eindeutig.

3.4 Projektsteuerung und Abschluss

129

Problem der Extrapolation Die Vorhersage von Ressourcenverbrauch oder Terminen aus dem Abarbeitungsgrad ist nicht eindeutig. Noch weniger können Termine und Ressourcen einfach linear extrapoliert werden, da viele verschiedene Effekte wie Synergien, Sättigung oder Rückkopplungen („adding manpower to a late projects makes it even later“) auftreten können. Verschiedene Möglichkeiten einer linearen Extrapolation zeigt das folgende Diagramm. y 100%

Ny

A n

a Nx

t

Ty

Üy ü

Tx

Plan

Üx R

100%

x

Abbildung 3-15: Extrapolation von Projektparametern Welche Art der Extrapolation sinnvoll ist, hängt von den Ursachen der Abweichung und den Möglichkeiten der Korrektur ab: Tabelle 3-8: Ergebnisse und Sinn der Extrapolationen Symbol R a, A n, N t, T ü, Ü A Nx, Tx, Üx Ny, Ty, Üy

Bedeutung Reale Beobachtung aufholen

Sinnvoll wenn ... Abweichung Ist – Soll ist signifikant und nicht durch Messung/Berichtswesen verursacht. Abweichung war durch einmalige Ereignisse verursacht und kann intern kompensiert werden. normale Fort- Abweichung war Folge eines einmaligen Ereigsetzung nisses (Ausreißer, externe Störung). Trend (proAbweichung ist gültig für das gesamte Projekt portional) (systematischer Fehler). ÜberDurch Terminkollisionen, Personalwechsel, ... proportional ergibt sich ein überproportionaler Effekt. Ziel erreicht Abweichung konnte kompensiert werden. x erreicht Projekt wird bei x = 100% beendet. y erreicht Projekt wird bei y = 100% beendet.

130

3 Projektmanagement

3.4.3 Terminüberwachung

Die Terminüberwachung basiert auf Meilensteinen. Meilensteintrendanalyse Die Meilensteintrendanalyse dient dazu, die Plantermine für Meilensteine zu überwachen. Dazu werden zu jedem Überwachungstermin die geplanten Termine für die Meilensteine eingetragen und graphisch verbunden.

Tgeplant 5 4

5 4 3

4 3

2 1

2 1

3 2

5

5

4 3

4 3

5

2

1 t=0 t=0

heute

Zeit T

Abbildung 3-16: Meilensteintrendanalyse Das Vorgehen lässt sich anhand der folgenden Schritte beschreiben: • Meilensteine (Erwartete, d.h. nach dem momentanen Wissensstand ge-

plante Termine TE = Tgeplant ) gegen die Zeitachse nach oben abtragen. • Immer zum jeweiligen Meldezeitpunkt TH (heute, d.h. zum aktuellen Datum der Bearbeitung) den momentan geplanten Termin TE eintragen. => Alles bewegt sich über der Winkelhalbierenden, da ein Meilenstein entweder erreicht ist (TE = TH) und damit nicht mehr weitergeführt wird oder in der Zukunft (TE > TH) liegt. • Abhängigkeiten eintragen. Bei Verschiebung einer Voraussetzung verschieben sich die davon abhängigen Projekte. Die Verschiebung der Nachfolger ist normalerweise kleiner als die der Vorgänger (Puffer, Kapazitätsverlagerung). • Blockierte Zeiten (Ferien, Volllast anderer Projekte) sind mit einzutragen. Sie können bewirken, dass gegebenenfalls Verschiebungen der Nachfolger größer sind als die der Vorgänger.

3.4 Projektsteuerung und Abschluss

131

Wichtig bei der Anwendung der Meilensteintrendanalyse ist: • Regelmäßiges Eintragen und Überprüfen der Meilensteintermine erlaubt eine frühe Reaktion. Wenn der Bearbeiter selbst die Meilensteintrendanalyse durchführt, gehört natürlich die notwendige Kritikfähigkeit und Selbsterkenntnis dazu. Andernfalls braucht man ein funktionierendes Berichtswesen. • Frühe Reaktion auf Verschiebungen und Trend muss im gesamten magischen Projektdreieck erfolgen: Neuplanung der Termine, Umwerteilung von Ressourcen, Anpassung der Ziele. • Durch die Meilensteintrendanalyse ist eine spätere Überprüfung möglich, man kann Kausalzusammenhänge aufzeigen und hat es leichter, zu zeigen wo eine Verzögerung verschuldet und verursacht wurde. Projektdauer Warum dauern Projekte mindestens so lang wie die Schätzung? Dafür gibt es im wesentlichen folgende Gründe: • Die Dauer von Projekten hat eine unsymmetrische Verteilungskurve. In der Theorie der Stochastik addieren sich viele kleine Abweichungen in etwa zu einer Normalverteilung auf. Große und eher unwahrscheinliche Überschreitungen ergeben aber eher eine Poisson-Verteilung. • Projekte werden aus politischen Gründen meist zu knapp geschätzt und deshalb meist überschritten. Nach Überschreiten des Termins werden Kompromisse bei Qualität und Ressourcen gemacht, um das Projekt überhaupt noch abzuschließen. • Die zur Verfügung stehende Zeit wird durch die Projektmitarbeiter ausgeschöpft, da eine frühere Fertigstellung nicht belohnt wird. Die Gründe für das Ausschöpfen der zur Verfügung stehenden Zeit können in Perfektionismus, in der Erfüllung aller Projektaufgaben (im Gegensatz zum schnellen Abwürgen des zeitlich überzogenen Projekts) oder in rationalen Reaktionen auf externe Ursachen liegen. Bei früherer Fertigstellung gibt es mehr Motivation, weiter zu machen als das Ergebnis abzugeben. Einige Gründe seien angeführt: • Das Projektergebnis ist nie „fertig“. Deshalb kann verbleibende Zeit meist in die Verbesserung des Ergebnisses investiert werden. (Perfektionsstreben, Parkinson-Prinzip). • Projektmitarbeiter und Projektleiter, die ein Projekt vor der Zeit abschließen, machen sich selbst „arbeitslos“. • Bei früherer Abgabe gibt es noch Zusatzwünsche des Kunden, von Management oder Marketing, die zu Änderungsaufwand, Qualitätsproblemen (interne Konsistenz, Systemstabilität, unabgestimmte Anforderungen, fehlende Tests) und Konfigurationsproblemen führen.

132

3 Projektmanagement

• Bei früherer Fertigstellung droht eine Korrektur der Schätzung. Wer ein

Projekt früher abschließt muss damit rechnen, dass seine Schätzungen beim nächsten Mal nach unten korrigiert werden. • Die notwendigen lessons learned müssen aufgearbeitet werden. Dies ist natürlich insbesondere bei erfolgreichen Projekten notwendig. Bei Misserfolg kommen die lessons learned von „oben“; viel wichtiger ist es aber, aus erfolgreichen Projekten zu lernen. • Notwendige Abschlussarbeiten werden gemacht, bei Zeitüberschreitung werden diese nicht gemacht (d.h. Projekte werden immer zu knapp geschätzt und bei Überschreitung gestutzt). • Die Zeit kann für U-Boot-Projekte und Werkzeugentwicklung (Tools, Checklisten für das Projektmanagement und das Projekt, z.B. Entwicklungswerkzeuge) genutzt werden, was die Organisation über das einzelne Projekt hinaus zum Erfolg bringt. Die Konsequenzen für das Management von Projekten liegen vor allem in der großen Bedeutung eines ehrlichen Umgangs zwischen den oberen Managementebenen bzw. den Auftraggebern des Projekts und den Projektverantwortlichen und Projektmitgliedern. 3.4.4 Kostencontrolling

Bei der Kostenüberwachung ist es wichtig, nicht nur die angefallenen Kosten mit den geplanten Kosten zu vergleichen. Man muss diese in Relation zu Ergebnissen und Terminen sehen. Mittelfestlegung und Mittelabfluss Die Mittelfestlegung erfolgt in einer viel früheren Phase als der Mittelabfluss. Der Projektfortschritt lässt sich nicht am Mittelabfluss messen. Kriterium ist die fertiggestellte Arbeit. Dabei ist das 90%-Syndrom zu beachten: Mitarbeiter tendieren dazu, die Arbeit als "fast fertig" zu betrachten. die entspricht den Aussagen der Pareto-Regel: 80 % des Erfolgs kann man mit 20 % des Aufwands erreichen, die anderen 20% des Projekts müssen aber ebenfalls erledigt werden. Messung des Projektfortschritts Um die Kosten im Verlauf des Projekts überwachen zu können, muss eine auf Arbeitspaketen basierende Schätzung vorliegen. Dabei muss man Kosten, Ergebnisse und Termine zueinander in Verhältnis setzen.

3.4 Projektsteuerung und Abschluss

133

Die Rückmeldung der AP-Verantwortlichen darf nicht nur die angefallenen Kosten beinhalten, sondern muss umfassen: • Abarbeitungsgrad von Arbeitspaketen (prozentualer Projektfortschritt, begonnene und abgearbeitete Teilpakete), • Angefallener Personalaufwand und Sachkosten pro Arbeitspaket, • Geplante Termine (Meilensteine, Fertigstellung) und voraussichtliche Entwicklung von Terminen, Ergebnis und Ressourcen. Dabei reicht der Vergleich von angefallenen und geplanten Kosten nicht aus, um den Kostenverlauf zu überwachen, da eine Abweichung verschiedene Gründe hat, deren Überlagerung zur Verschleierung von Problemen führen kann (die entgegengesetzte Richtung unten stehender Veränderungen ist ebenfalls möglich, aber seltener): • Bestellungen bzw. Beauftragungen wurden später getätigt. • Arbeitspakete verzögern sich als ganzes (werden später begonnen). • Die Fertigstellung von Arbeitspaketen verzögert sich (da nicht das geplante Personal eingesetzt wurde oder aufgrund von Problemen). • Die Kosten für Arbeitspakete steigen aufgrund von Preissteigerungen oder externer Vergabe. Die ganz oder teilweise fertig gestellten Arbeitspakete sind mit dem zur Fertigstellung geplanten Aufwand (Leistungswert) zu gewichten, um einen Vergleich mit der Planung zu haben. Damit ergeben sich folgende wichtige Kennzahlen für jedes Arbeitspaket: • Gesamtwert = geplante Kosten = SOLL-Kosten. • Leistungswert = Fertigstellungsgrad = Summe der fertig gestellten AP bewertet mit geplanten Kosten. Der Leistungswert (Earned Value) ist die wichtigste Messzahl für den bereits erreichten Projektfortschritt. Dafür werden die fertig gestellten Arbeitspakete (ganz oder prozentual) mit den in der Planung angesetzten Kosten (Wert des AP) bewertet. • Technischer Fertigstellungsgrad = Leistungswert / Gesamtwert. • Mittelabfluss = bis zum Stichtag angefallene Kosten. • Kaufmännischer Fertigstellungsgrad = Mittelabfluss / Gesamtwert. • Kostenstatus = Mittelabfluss / Leistungswert = kaufmännischer Fertigstellungsgrad / technischer Fertigstellungsgrad. • Kostenüberschreitung = Kostenstatus - 100%. Genauso lassen sich Kennzahlen mit den zum Stichtag geplanten und angefallenen Kosten/Ressourcen und Leistungswerten bestimmen, insbesondere: • Kostenüberschreitung = Mittelabfluss - zum Stichtag geplanter Mittelabfluss. • Terminverzögerung = Stichtag - Termin, an dem die zum Stichtag erbrachte Leistung hätte erbracht werden sollen.

134

3 Projektmanagement

Ampelmethoden im Projektcontrolling Um den Verlauf des Projekts zu überwachen, ist eine stetige Rückmeldung über die verschiedenen Stufen des Projekt- bzw. Arbeitsstrukturplans notwendig. Dabei können aktuelle Arbeiten und zukünftige Planungen mit einem Ampelsystem (rot/gelb/grün) bewertet werden. Die Inhalte sind dieselben wie oben beim Controlling, werden nun aber stärker zusammengefasst. Bei der Prognose ist dabei zu beachten, dass eine realistische Vorhersage absolut notwendig ist, um die Zukunftsprognose abgeben zu können. Wenn es noch keine Indizien gibt, dass die Projektentwicklung vom Plan abweicht, ist der Prognosestatus „grün“.

Tabelle 3-9: Status und Prognose im Ampelverfahren Q Ergebnis R Ressourcen T Termin

Status Erreichtes Ergebnis und abgearbeitete Arbeitspakete bis jetzt Verbrauchte Ressourcen in Relation zu Zeit und Ergebnis Einhaltung der Meilensteine bis jetzt

Prognose Erreichbares Ergebnis aus heutiger Sicht Einhaltbarkeit von Kosten und Ressourcenplänen Einhaltbarkeit des Terminplans

Neben den Ampelfarben können auch Symbole, Ikons oder Smilies in den entsprechenden Farben verwendet werden. Wichtig ist, dass die Rückmeldung durch die Verantwortlichen selbst abgegeben wird: dadurch wird die Rückmeldung selbst zu einem wichtigen Teil des Controlling-Prozesses. Die Wirksamkeit wächst, wenn dies in der Gruppe gemacht wird und jeder Verantwortliche seinen Status mit einem Satz erläutert. Für ein Projekt mit 7 Teilprojekten mit insgesamt 30 Arbeitspaketen der nächsten Ebene kann so in weniger als zehn Minuten eine effektive und effiziente Rückmeldung eingeholt und die kritischen Stellen im Projekt identifiziert werden. 3.4.5

Projektsteuerung

Im Rahmen des Projektdreiecks ist jeder der drei Punkte des Projektdreiecks Objekt von Steuerungsmaßnahmen. Termine: Terminanpassung, Beschleunigung, Kosten: Erhöhung der Mittel und Mitarbeiterzahl, Fremdvergabe, Qualität: Anpassung von Zielkriterien und Qualitätsmerkmalen.

3.4 Projektsteuerung und Abschluss

135

Maßnahmen Ungleichgewichte im Projektdreieck können verschiedene Ursachen haben, und erfordern deshalb verschiedene Maßnahmen. Ursachen und Maßnahmen können T (Zeitverbrauch), R (Ressourcenverbrauch) und Q (Erfüllungsgrad) betreffen. Die Steuerung sollte möglichst frühzeitig erfolgen. Basis sind die einzelnen abgearbeiteten und in Arbeit befindlichen Arbeitspakete und die auf allen Informationen basierenden Schätzungen für Termine, Kosten und Qualität des Ergebnisses. Als primär zu betrachtende bzw. zu adaptierende Parameter (A) kommen Terminschätzung, Kostenschätzung und zu erwartendes Ergebnis in Frage. Q: Anpassung des Leistungsumfangs Technische Änderungen

R: Anpassung der Kosten Änderung der Ressourcenverteilung

T: Anpassung der Termine Beschleunigung / Verzögerung

Abbildung 3-17: Steuerungsmaßnahmen im Projektdreieck Dabei ist klar, dass jede Änderung im Projektdreieck auch die anderen Ecken betrifft und eine Steuerung nur in der Gesamtsicht sinnvoll ist. Beispiele von Ursachen und Maßnahmen Die folgende Tabelle soll mögliche Ursachen und Korrekturmaßnahmen von Abweichungen im Rahmen des Projektdreiecks erläutern. Diagnose und Korrektur sind dabei möglichst früh vorzunehmen. Die Abgrenzung + (viel) und – (wenig) steht hier als Platzhalter für erkannte Abweichungen in Zeitverbrauch (Terminablauf, Zeitüberschreitung), Ressourcenverbrauch und Zielerreichung. Die Vorzeichen sind unabhängig davon, ob die jeweilige Abweichung gut oder schlecht ist. Die Symbole können für Paare wie 40% - 60%, 20% - 30% aber auch 80% - 120% stehen (die = = steht für gleiche Werte, insofern steht z.B. + - - auch für + = = etc.).

136

3 Projektmanagement

Tabelle 3-10: Ursache und Maßnahme bei Projektabweichungen T R Q Ursache = = = von den Daten her o.k. Fertigmeldung nach Termin

Maßnahme wachsam bleiben

A

prüfe Berichtswesen

→ T

- + + zu hoher Mitarbeitereinsatz Mittelabfluss statt Erfüllungsgrad

Termin korrigieren Erfüllungsgrad prüfen

- + - zu hoher Mitarbeitereinsatz Aufgabe unterschätzt Kürzungen im Budget - - + Idealfall: Projekt läuft prima 90%-Syndrom

Projekt straffen Schätzung korrigieren Projektplanung anpassen Planung anpassen Erfüllungsgrad prüfen

+ + - Verzug, Probleme Änderungen der Anforderung restriktive Fertigmeldungen

Projektdreieck anpassen Projektdreieck anpassen Projektfortschritt prüfen

+ - + Projekt läuft günstiger Aufgabe überschätzt Laufzeit statt Erfüllungsgrad

Erfüllungsgrad prüfen Schätzung korrigieren Erfüllungsgrad prüfen

+ - - Verzug, Projekt zieht sich Mitarbeitermangel Mangel an Qualifikation Externe Verkürzung der Termine

Termin anpassen Mitarbeiter hinzunehmen Projektdreieck anpassen Projektplanung anpassen

3.4.6

→

→ R R RQT QRT → QRT QRT → R RT → T TR TRQ TRQ

Projektabschluss Ende gut – alles gut

Der Abschluss von Projekten wird leider häufig vernachlässigt. Er ist aber ein wichtiger Erfolgsfaktor für das aktuelle und die nachfolgenden Projekte. Notwendig ist eine Auswertung jedes Projekts bezüglich der • Organisation und Abläufe: − was war hilfreich, positiv? − was war kritisch, gefährlich? − welche Strukturen sollten geschaffen werden? • Methoden: − was war hilfreich? − was war kritisch? − was lieferte richtige Ergebnisse? − welche Verfahren müssen korrigiert werden?

3.5 Management mehrerer Projekte

137

• Kosten: − Nachkalkulation, − Ursachenanalyse, − Identifikation von Kostentreibern. • Kenntnissen, Bedarf an − Personal, − Ausbildung/Schulung/Training.

Die Nachkalkulation und die Dokumentation von Erfolgen und Problemen dienen nicht nur der Beurteilung des Projekterfolgs, sie sind auch für zukünftige Projekte wichtig. Hilfreich ist ein Formular oder eine Checkliste für die wichtigsten Projektdaten und für eine Gegenüberstellung von Planung und Ergebnis. Damit kann eine Erfahrungsdatenbank aufgebaut werden. Beim Abschluss ist auch die Würdigung der Mitarbeiter und ihre Wiedereingliederung in die Linie ein wichtiger Prunkt.

3.5 Management mehrerer Projekte Ein Unternehmen – viele Projekte

Ein Projekt kommt selten alleine. Projekte folgen aufeinander oder bedingen einander. Projekte können als Aufgabe des Unternehmens in ähnlicher Art aufeinander folgen oder parallel zueinander abgewickelt werden. Vor-Projekt

Projekt

Folge-Projekt

Übergeordnete Aufgabe Projekt

(Gesamtprojekt) Projekt

Projekt

Projekt Projekt

Projekt Projekt

Momentanes Projekt-Portfolio

Zeit

Abbildung 3-18: Multiprojektmanagement und Projektportfolio 3.5.1

Multi-Projekt-Management

Der einfachste Fall des Managements mehrerer Projekte ist der Fall paralleler Projekte. Falls diese Projekte nur die Ressourcen (Personal, Projektleiter)

138

3 Projektmanagement

gemeinsam haben, ist es meist eine Frage der Koordination und der Priorisierung. Insbesondere bei Projekten nach dem Matrix- oder Einflussprinzip ergeben sich Konflikte bezüglich des Zugriffs auf das Personal. Hier muss ein Manager einer geeigneten höheren Ebene für Richtlinien für die Priorisierung sorgen. Die Problematik ist im Grunde dieselbe wie die zwischen Projekten und Linienfunktionen. Andere Wechselwirkungen basieren meist auf zeitlichen Abhängigkeiten (Zuliefererfunktion, gemeinsame Meilensteine), diese können in einem gemeinsamen Netzplan abgebildet werden. Im Extremfall sind die Projekte als Arbeitspakete eines übergreifenden Projekts zu sehen und entsprechend auch mit den Projektmanagement-Werkzeugen zu bearbeiten. Verknüpfungen zwischen Projekten können sich auch durch Maßnahmen und Entscheidungen von Kunden, Management oder Stakeholdern ergeben. 3.5.2

Management wiederkehrender Projekte Alles schon mal da gewesen – nur nicht in dieser Form

Die Begriffe wiederkehrend (repetitiv) und Projekt scheinen sich auszuschließen. Deshalb wird auch häufig in der Literatur davon ausgegangen, dass ein Projekt wirklich "einzigartig" ist. Trotzdem gibt es in der Praxis viele Projekte mit repetitivem (wiederholendem) oder gar Routine-Charakter. Gerade im Bereich Entwicklung ist dies ein wichtiger Punkt. Wir wollen ja nicht immer „das Rad neu erfinden“, sondern die Erfahrung als Erfolgsfaktor nutzen. Tabelle 3-11: Projekt und Routine Aufgabe, Objekt Anlage Produkt Veranstaltung Forschung Prüfungsarbeit Neue Strukturen Baumaßnahme

Aspekt der Einzigartigkeit: ganz neues System /Produkt neuartige Produkte neue Art oder Größe neue Methoden aus Sicht des Prüflings aus Sicht des Unternehmens aus Sicht des Bauherrn

Routineaspekt: im Rahmen der Produktlinie im Rahmen der Produktlinie ähnlich wie Vorgänger Fortführung aus Sicht des Prüfers aus Sicht des Beraters aus Sicht des Architekten

3.5 Management mehrerer Projekte

139

Wenn sich Projekte (in einem abstrakten Sinne) wiederholen, können einige Maßnahmen zur Effizienzsteigerung im Projektmanagement dienen: • Projektdokumentation, Dokumentation des Ablaufs im Projektdreieck, Festhalten von Schätzverfahren und Besprechungsergebnissen (Schätzung und politisch/taktische Werte differenzieren), • Projektauswertung bezüglich der verwendeten Methoden, • Projektmanagementhandbuch und Checklisten, • Projektparametrisierung. Projektmanagement-System Die Einführung von standardisierten Prozessen für die Abwicklung von Projekten ist ein wesentlicher Schritt zu Steigerung von Effektivität und Effizienz und ein wesentliches Kriterium der „Professionalisierung“ von Projektarbeit. Bei ähnlich wiederkehrenden Projekten empfiehlt sich die Festlegung von Organisation, Abläufen und Methoden im Projekt. Damit geht das Projektmanagement in ein Prozessmanagement über. Die Vorgaben werden sinnvollerweise in einem Projektmanagement-Handbuch zusammengestellt, daneben können für Planung und Durchführung Checklisten erstellt werden. Projektparametrisierung Wenn qualitative und quantitative Daten der Projekte in einer Datenbank hinterlegt sind, können daraus projektübergreifend Erfahrungen gewonnen werden. Aus einer Erfahrungsdatenbank ist (z.B. mittels linearer Regression) die Identifikation möglich von • typischen Dauern und Aufwänden für in ähnlicher Form wiederkehrende Aufgaben, • kostenrelevanten Parametern (cost drivers) und funktionalen Abhängigkeiten zwischen Aufgaben und Ressourcen/Dauern, • Effizienzfaktoren. Eine kontinuierliche Überprüfung und Anpassung dieser Parametrisierung ist notwendig. 3.5.3

Projektportfolio

Das Projektportfolio dient der (graphischen) Darstellung, welche Projekte im Moment aktuell (in Bearbeitung, in Planung) sind. Dazu werden zwei Parameter auf den Achsen einer graphischen Darstellung abgetragen bzw. als Komponenten der Portfolio-Matrix verwendet. Wichtig sind solche Para-

140

3 Projektmanagement

meter, die für die strategische Überlegung im Rahmen des Multiprojektmanagements entscheidend sind. Wichtige Parameter und Überlegungen für das Projektportfolio sind: • Laufzeit: Wie lange (seltener: ab wann) laufen die Projekte? Eine graphische Darstellung der Laufzeit führt statt des Portfolios zu einer dem Gantt-Diagramm ähnlichen Darstellung. • Innovation/Innovativität: Wie innovativ ist das Projekt? Haben wir immer Projekte, die uns weiterbringen? • Bedeutung: Wie wichtig ist das jeweilige Projekt. Wo liegen die wichtigen Projekte? • Gewinn/Cash Flow: Welchen Gewinn wirft das Projekt voraussichtlich ab? Haben wir immer Projekte, die uns finanzieren? • Größe/Personalauslastung: Welche Projekte brauchen wie viel Personal? Dahinter steht die Frage, ob die Organisation alle Projekte bewältigen kann und ob sie ausgelastet ist. Diese Projektgröße bietet sich auch als Größe eines Kreises in einem Portfolio mit zwei anderen Achsen an. 3.5.4 Organisationsstrukturen

Das Unternehmen muss sich eine Struktur geben, um parallele und nacheinander ablaufende Projekte durchzuführen. Dies betrifft die im Folgenden noch ausgiebig betrachtete Problematik der Einbindung in die Linienorganisation und die Schnittstelle zwischen den Projekten. Ein wesentlicher Beitrag dazu ist das an anderer Stelle betrachtete Matrixmanagement.

3.6 Management spezieller Projekttypen Beim Projektmanagement ist auch die Art des Projekts zu beachten, Strukturen und Managementmethoden sind an die Größe und Formalität der Aufgabe anzupassen. 3.6.1 Team-Projekte

Projektmanagement und Teamarbeit sind so eng miteinander verknüpft, dass man bei Projekten normalerweise von Projektteams ausgeht. Teamarbeit bedeutet aber auch die Kooperation und Aufgabenverteilung im Team. Typische Projektteams in mittleren Projekten sind so groß, dass die Teammitglieder sich gegenseitig kennen und somit die formale Projektstruktur durch informelle Kommunikation und Vernetzung unterstützt wird.

3.6 Management spezieller Projekttypen

3.6.2

141

Großprojekte

Für Großprojekte gibt es ein dediziertes Projektmanagement-Team und Unterstützung durch Software. Ab einer bestimmten Größe wird ein formelles Berichtswesen unabdingbar, da die Projektleitung nicht mehr alle Arbeitspakete überblickt. Dabei ist zu berücksichtigen, dass das Berichtswesen zum einen Informationen filtert und zum anderen Zeitverzögerungen verursacht. Wenn möglich sollten regelmäßige Treffen zumindest der Arbeitspaketverantwortlichen der nächsten Ebene/n stattfinden. 3.6.3

Ein-Personen-Projekte

Nach der Definition des Projekts erfordert dieses die Beteiligung mehrerer Stellen. Aber auch Aufgaben, die nur von einer Person bearbeitet werden, können ein Projekt sein: Kriterien für ein Projekt – auch wenn es nur von einer Person bearbeitet wird – sind: • die abgegrenzte und wohldefinierte Aufgabe mit − einem klaren (von außen gegeben oder selbst gesetzten) Ziel und − einem Kriterium dafür, wann die Arbeit abgeschlossen ist, • eine Beschränkung des Projekt durch − einen vorgegebenen Endtermin und − eine Beschränkung der personellen und finanziellen Ressourcen. Das Kriterium „Änderung der Organisationsform“ kann hier so interpretiert werden, dass von der üblichen Einteilung des Tages oder der Zuordnung von Arbeit abgewichen wird. Das erfordert vom Mitarbeiter mehr Planungsaufwand als die bloße 40-stündige Anwesenheit pro Woche. Selbstmanagement und Selbstdisziplin sind wichtige Voraussetzungen für die Durchführung von Einpersonenprojekten. Projektplanung und Zeitplanung sind vor allen dafür wichtig, zeitkritische Tätigkeiten rechtzeitig zu initiieren. Ein-Personen-Projekte begleiten uns vielleicht nicht von der sprichwörtlichen „Wiege zur Bahner“ aber zumindest vom spielerischen – aber gezielten – Bauprojekten in der frühen Jugend bis zu Projekten im Hobbybereich oder der Urlaubsplanung in allen Altersstufen oder zur Erstellung eines Testaments. Auch im Beruf sind viele Aufgaben als Ein-Personen-Projekte zu organisieren. Im Bereich der Aus- und Weiterbildung sind schriftliche Hausarbeiten und Berichte weit verbreitete Aufgaben mit Projektcharakter, und auch die Vorbereitung auf Prüfungen wird sinnvoller weise als Projekt organisiert.

142

3 Projektmanagement

Magisches Projektdreieck für Prüfungen Prüfungsarbeiten werden nicht immer in Form einer (schriftlichen oder mündlichen) Abschlussprüfung abgelegt, sondern viel wichtiger in Form eines Produkts, das als Werk, Arbeit, Probe oder ähnliches bezeichnet wird. Dabei kann es sich um ein physisches Produkts (Meisterstück, Prototyp, Werkstück), eine abschließenden Leistung (Vorführung, Lehrprobe, Präsentation) oder eine schriftliche Dokumentation (Abschlussarbeit, Dissertation) handeln. Das Projekt beinhaltet die Entwicklung und Umsetzung. Im magischen Dreieck stellt sich dies folgendermaßen dar: • Q: Welchen Anspruch haben wir an das Ergebnis? Wie ist die angepeilte Note? Was sind Erfolgskriterien? Welche Ergebnisse werden erwartet? Wie sollen Erkenntnisse abgesichert werden? Welche „deliverable items“ werden erwartet? Wer prüft und wer vergibt die Note? Welche Dokumentation in welcher Form? Ist eine Publikation vorgesehen? • R: Welcher Aufwand wird erwartet? Wer ist im Team? Wie ist die Verfügbarkeit eventuell mitarbeitender Personen? Wie ist das Team organisiert? Wie ist die Last gemäß Arbeitsstrukturplan? Welche Arbeitspakete sind Ressourcenfresser? • T: Was sind formale Anforderungen? Ausgabe-, Abgabe- und Vortrags-Termine. Wann werden Prüfungstermine bekannt gegeben? Wie sieht der Zeitplan aus? Sind die Meilensteine realistisch? Werden sie überwacht? Haben wir genügend Puffer? Welche Zeiten stehen zur Verfügung? Wie viel Zeit geben wir Projektpartnern (Betreuer, Kollegen, Prüfer) für ihre Reaktion?

3.6.4

U-Boot-Projekte

Ein spezieller Fall von Projekten sind die sogenannten U-Boot-Projekte: Projekte, die offiziell nicht existieren, sondern sich „unter der Oberfläche“ bewegen. Diese Unsichtbarkeit bedeutet, dass sie auch offiziell nicht gemanagt werden. Damit gibt es eine offizielle und eine inoffizielle ManagementSeite. Offiziell wird das Projekt ignoriert. Als Verantwortlicher kann man vor allem eines tun: den Raum schaffen für Kreativität. Weiter ist wichtig, zu kontrollieren, dass U-Boot-Projekte nicht aus dem Ruder laufen, zu viel Ressourcen verbrauchen oder für negative Stimmung im Unternehmen sorgen. Der Raum für solche Projekte sollte aber in jeder Organisation vorhanden sein, da sie im Allgemeinen eine positive Auswirkung auf Klima und Weiterentwicklung des Unternehmens haben. Schiebepuzzle Die folgende Metapher von Tom de Marco [de Marco, Spielräume] soll zeigen, dass wir im Projekt und im Produkt Spielräume brauchen:

3.6 Management spezieller Projekttypen

143

Ein scharf kalkulierender Mitarbeiter hatte festgestellt, dass im Schiebepuzzle „nur“ 15 Teile benutzt werden, aber 16 Plätze vorhanden sind. Dies führte zu einem „verbesserten“ Puzzle, in dem nun der Platz „optimal“ ausgenützt ist. 1

15

9

8

1

15

9

8

14

2

3

12

14

2

3

12

5

13

6

7

5

13

6

7

10

11

4

16

10

11

4

Das neue Schiebepuzzle ist nun natürlich keines mehr. Das, was in der naiven Ansicht als Verschwendung erscheint, gibt den Puzzleteilen erst die notwendigen Bewegungsmöglichkeiten.

Inoffiziell muss das Projekt geleitet werden. Wie in ehrenamtlichen Projekten ist auch hier das Problem, dass die Mitarbeiter hoch motiviert sind, solange sie sich mit den Zielen identifizieren. Sowohl die offiziellen Linienvorgesetzten als auch die inoffiziellen und informellen Leiter von U-Boot-Projekten sollten eines bedenken: Die Mitarbeiter arbeiten in solchen Projekten freiwillig mit. Sie könnten in dieser Zeit natürlich für die Firma Arbeitsleistung in offiziellen Projekten oder Routineaufgaben bringen (Die Frage, warum ihnen diese Aufgaben nicht lohnender erscheinen, ist berechtigt). Sie könnten aber auch genauso gut in dieser Zeit Kaffee trinken oder sich um die Aufstellung der Möbel (im Büro oder zuhause), den nächsten Urlaub oder einen neuen Job Gedanken machen. Damit zeigt sich auch der Zwiespalt, in dem der Linienvorgesetzte steckt: Zum Stolz über das Erreichte gesellt sich der (ausgesprochene oder unausgesprochene) Vorwurf „haben deine Leute so viel Zeit übrig?“. Dieses Problem hat der Kollege mit der demotivierten Mannschaft nicht, da das Ergebnis der durch Frust vergeudeten Zeit nie gemessen wird. Wie jemand damit und mit der Fangfrage „haben Sie davon was gewusst?“ umgeht, ist Frage der Führungspersönlichkeit und des Führungsstils des Individuum und der Unternehmenskultur. Sowohl die Motivation als auch die informelle Kommunikation von Mitarbeitern wirken sich auf die Produktivität eines Unternehmens viel kräftiger aus als ein kleiner abgezweigter Prozentsatz an Anwesenheitszeit. Jeder Manager hat aber darauf zu achten, dass solche Projekte (die parallel oder ganz unabhängig von den Aufgaben im Unternehmen liegen können) bei

144

3 Projektmanagement

Mitarbeitern, Führungskräften und Teams nicht zu wichtig und umfangreich werden. Auf jeden Fall sollten die fachlichen Erfahrungen aus solchen Projekten und die Information, wer als informeller Führer erfolgreich war, genutzt werden.

4

Entwicklung als Projekt Entwicklung „ist“ nicht, sie wird gemacht

Die Entwicklung eines Produkts ist ein Prozess, der im Allgemeinen wegen seiner Einmaligkeit als Projekt durchgeführt wird. In diesem Kapitel betrachten wir den Ablauf des Entwicklungsprojekts und seine Phasen.

4.1 Entwicklungsprozess Von der Idee zum Konzept

Es ist wichtig, am Anfang des Entwicklungsprojekts die Ziele der Entwicklung klar herauszuarbeiten und allen Beteiligten zu vermitteln. Die Klärung der Zielsetzung hat hohe Relevanz und zwar in zwei Richtungen: • Anforderungen, die der Träger (Organisation) an das Projekt hat, und • Anforderungen, die der Kunde an das Produkt und das Projekt hat. Entwicklungsprojekte scheitern meist daran, dass zu Beginn die Zielsetzungen und Rahmenbedingungen nicht klar definiert und kommuniziert wurden. Probleme, die „im“ Projekt auftraten, sind meist durch Fehler beim Start des Projekts oder durch externe Einflüsse verursacht. 4.1.1

Entwicklungsziele

Entwicklungsziele können sein: • Finanzielle Ziele. Ziel kann ein direkter Gewinn durch die Durchführung des Entwicklungsprojekts oder ein Gewinn durch das entwickelte Produkt (Produktion, Verkauf, Vermietung, Leistungserbringung, Lizenzvergabe, Franchising) sein. • Wissenschaftlich-technische Ergebnisse und Erkenntnisse aus der Durchführung des Entwicklungsprojekts. • Image und Technologieführerschaft durch das neue Produkt und durch die Erkenntnisse aus dem Entwicklungsprozess. • Problembehebung durch die Entwicklung eines Produkts als Problemlösung. • Termin und Ressourcen sind Restriktion und kein eigentliches Ziel der Entwicklung. Der Termin kann zum Ziel werden, wenn ein Entwicklungsergebnis zu einem bestimmten Zeitpunkt vorliegen muss. • Anforderungen an das Produkt können Qualität und Eigenschaften des Produkts, Preis des Produkts (Kosten der Rohstoffe, Produktion), und mögliche Parameter der Produkterstellung (Geschwindigkeit, Kosten, Flexibilität) umfassen.

146

4 Entwicklung als Projekt

Die Anforderung des Kunden an das Produkt sind recht klar: Ein gutes Produkt, rechtzeitig verfügbar, preisgünstig und mit möglichst wenig eigenem Aufwand. Tabelle 4-1: Anforderungen an ein Entwicklungsprojekt Anforderungen an das Projekt

von der Entwicklungsabteilung Erfolgreiche Ergebnisse: hochwertiges Produkt, Erkenntnisse, Qualifizierung der Mitarbeiter

an das Produkt

Qualitativ hochwertig, erfolgreich, imageträchtig.

4.1.2

von Träger, Firma, internen Kunden Erfolgreiche Ergebnisse: Produkt, Einhaltung von Budget und Zeitrahmen. Erfahrungsgewinn, keine negativen Einflüsse auf die eigene Organisation. Hochwertig, imageträchtig, leicht und preiswert zu produzieren, erfolgreich auf dem Markt.

vom externen Kunden Gutes Ergebnis rechtzeitig und preisgünstig. Keine Beeinträchtigung der eigenen Arbeit. Problemlösung und Qualität. Einzelanforderungen wie Preis, Stabilität, Sicherheit.

Zielorientiertes Vorgehen

Die Vorgabe von Zielen und von Anforderungen an ein Entwicklungsprojekt ist wichtig. Wenn die Ziele klar sind, kann man sich daran orientieren. Dabei müssen sowohl die Produktanforderungen (Requirements) als auch die Anforderungen an das Entwicklungsergebnis und an das Entwicklungsprojekt berücksichtigt werden. Nur dann kann ein Entwicklungsprojekt zielgerichtet geplant und durchgeführt werden und können die richtigen Prioritäten in Produkt und Projekt gesetzt werden. In Analogie zu Lean Produktion oder Lean Management könnte man auch ein Lean Development formulieren: „klare Anforderungen zielorientiert umsetzen.“ Lean Development bedeutet dann, dass sowohl im Entwicklungsprojekt als auch im Entwicklungsergebnis effizient auf das Ziel hin gearbeitet wird und überflüssiger Ballast vermieden wird. Lean Development: effiziente und schlanke Entwicklung Klare Ziele für das Projekt

Klare Anforderungen an das Produkt

Planung in den frühen Phasen

Effiziente Entwicklung

Erfolgreiche Produkte

Abbildung 4-1: Lean Development durch zielorientiertes Vorgehen

4.1 Entwicklungsprozess

147

Das folgende Beispiel schildert eine gelungene zielorientierte Lösung. Hubbrücke Eine Hubbrücke ist nicht ungewöhnliches. Die folgende Entwicklung (aus [Meyer, Wehrlen et.al.] zeigt, wie Vorgaben systematisch umgesetzt werden: Projektinitialisierung Am Nachmittag des 24. September 1993 staute sich ein Hochwasser der Saltina an der Brücke zwischen Brig und Glis, deckte die Straßen der Altstadt mit seinem Geröll zu und verursachte damit neben zwei Todesopfern Schäden in beträchtlicher Höhe. Zur Verhinderung weiterer solcher Schäden wurde als Weltneuheit eine sich bei Hochwasser automatisch hebende Brücke errichtet. Erarbeitung der Zielsetzung Das Projekt der neuen Hubbrücke musste die folgenden Grundsätze einhalten: • ausnützen des Übels selber zur Lösung des Problems • auf Fremdenergie verzichten • einfache Mechanik für Betriebssicherheit und Lebensdauer • Minimierung von Unterhalt und Wartung So entstand das folgende Konzept: Bei Hochwasser wird sich die Saltina dank eines Gegengewicht-Systems, bestehend aus Stahlbrücke und Wasserbehälter, ihren Weg selber freischaffen. Sobald das Hochwasser einen kritischen Pegel erreicht, beginnt sich der Wasserbehälter durch eine dafür vorgesehene Öffnung im Damm zu füllen. Der Behälter, der als Gegengewicht dient, wird schwerer als die Brücke und hebt sie mittels eines Flaschenzugs in wenigen Minuten und ohne Fremdenergie aus dem Bachbett. Da für die Hubbrücke nur einfache mechanische Komponenten verwendet werden, bedarf es für Wartung und Unterhalt keiner Spezialisten. Die vier Brückenecken sind über vier um eine Windentrommel gewickelte Stahlseile mit den vier Ecken des Behälters verbunden. Der Behälter selbst kann durch drei unabhängige Quellen gespeist werden (Reservoir, Netz der Trinkwasserversorgung der Stadt und automatisch im Falle eines Hochwassers) Der gesamte Hub inklusive der Behälterfüllung dauert ungefähr sechs Minuten. Um die Brücke in ihren ursprünglichen Zustand zurückzuversetzen, muss der Behälter ausgepumpt werden, wozu zwei Personen eine Stunde benötigen.

4.1.3

Schrittweises Vorgehen Entwicklungsphasen und Entscheidungszäsuren

Die Phasen im Laufe des Entwicklungsprojekt sowie die Phasenmodelle und Meilensteine wurden bereits aufgezeigt und werden im folgenden Kapitel über Vorgehensmodelle ausführlich dargestellt. Die Meilensteine vor allem am Ende der Projektphasen sind nicht nur Punkte für die inhaltliche Überprüfung und Festlegung, sondern auch wich-

148

4 Entwicklung als Projekt

tige Entscheidungspunkte (Zäsuren, Gates) im Projekt. Durch eine konsequente Beachtung dieses Stufenprinzips mit Phasen und Meilensteine in einem geplanten schrittweisen Vorgehen mit definierten Zäsuren und Kriterien werden Risiken minimiert und Chancen optimal genutzt. (In [Cooper] wird dafür die Bezeichnung „Stage-Gate“ eingeführt und verwendet.) Dazu sollten schon in den frühen Phasen Kriterien festgelegt werden, wann ein Projekt fortgeführt bzw. abgebrochen wird. Es muss auch kommuniziert werden, dass und wann Projekte abgebrochen werden. Den Vorteil von dynamischen Entscheidungen veranschaulicht ein Beispiel im Kapitel Management. Im Entwicklungsprojekt kommt dazu noch die im Laufe der Entwicklung zunehmende Information. Entscheidungszäsuren sind vor allem in den frühen Phasen wichtig, um eine systematische Auswahl von Projekten zu treffen und eine optimale Abwägung zwischen den Chancen und Risiken einer neuen Entwicklung zu erhalten. Die konsequente Einführung und Beachtung von Abbruchkriterien an wohldefinierten Meilensteinen erlaubt es auch, Risiken einzugehen, da die Folgen begrenzt und abschätzbar ist. Dies erfordert eine Unternehmenskultur, in der ein abgebrochenes Projekt als ein sinnvoller Versuch gesehen wird und nicht als Misserfolg. 4.1.4

Einflussfaktoren

Der Produktentstehungsprozess ist in Abhängigkeit von den Randbedingungen unterschiedlich. Die folgende Morphologische Matrix gibt einen kleinen Eindruck davon. Tabelle 4-2: Morphologischer Kasten für Entwicklungsprojekte Produkt Kunde Auftrag Auftraggeber Innovationsgrad

HW

SW

System

Individuell Konkret (Auftragsbezogen) extern Forschung Anpassung Neuentwicklung

Konzept Dienstleistung Massenmarkt Vorleistung (für den Markt) intern Verbesse- Modifikarung tion

4.2 Vorgehensmodelle

149

4.2 Vorgehensmodelle Vorgehensmodelle sind Wegweiser, keine Gleise

Vorgehensmodelle beschreiben eine Konzeption für den Ablauf eines Projekts. Die Grundlagen haben wir bereits beim Projektmanagement (Phasenkonzept) und bei der Entwicklung (strukturiertes Vorgehen) betrachtet. Nun gilt es, diese beiden zu integrieren um zu einem Vorgehensmodell für Entwicklungsprojekte zu kommen. 4.2.1

Phasenmodelle

Das Phasenmodell oder Phasenkonzept ist der zentrale Punkt für die Projektabwicklung bei Entwicklungsprojekten. Es erlaubt eine erste Gliederung der gesamten Aufgabe. Die Phasen sind charakterisiert durch • Tätigkeiten (incl. Entscheidungen) und • Ergebnisse (insb. Entwürfe, Dokumente und Programme). Wichtig ist die Antwort auf die Frage: Was ist das Ergebnis, wenn eine Phase abgeschlossen ist? • Was haben wir? Welche produktbezogenen Ergebnisse und Erkenntnisse, Produkte, Dokumente und sonstigen Objekte liegen vor? • Wo stehen wir? Welchen Wissenstand haben wir? Welche Entscheidungen können getroffen werden oder werden getroffen? Wasserfallprinzip Nach dem Wasserfallprinzip wird die jeweilige Phase abgeschlossen und ein Dokument als Basis für die folgende Phase erstellt. Ein Rückkehren in die vorangegangene Phase ist nicht mehr möglich (Wasserfall). Als Abschluss der Phasen sind im Allgemeinen Reviews vorgesehen. Reviews sind formale Besprechungen von Ergebnissen (z.B. Dokumenten). Damit werden entweder offene Probleme besprochen oder (Entwurfs-) Entscheidungen verabschiedet. Reviews sind wichtig als Feedback (Rückkopplung), damit nicht "ins Blaue hinein" entwickelt wird. Sie sind eine wichtige vertrauensbildende Maßnahmen zwischen Kunde und Entwickler. Fünf Phasen Als ein einfaches Beispie eines Vorgehensmodells können die bereits betrachteten Fünf Phasen dienen. Damit dies ein Vorgehensmodell wird, müssen außerdem die in jeder Phase zu bearbeitenden Aufgaben, die zu erstellenden Dokumente und übergreifende Aufgaben beschrieben werden.

150

4 Entwicklung als Projekt

Phasenübergreifende Aktivitäten Anforderungsanalyse

Spezifikation

Entwurf

Implementierung

Test

Management-Aktivitäten

Abbildung 4-2: Prozesse im Fünf-Phasen-Modell 4.2.2

V-Modell

Der Begriff V-Modell hat in der Entwicklung zwei Bedeutungen: Das V-Modell des Bundes zur IT-Entwicklung Das V-Modell ist ein Vorgehensmodell für die Entwicklung von Systemen, insbesondere für die Entwicklung von Software und softwareorientierten Systemen (Hardware-Software-Systeme). Es beschriebt das Zusammenspiel von Phasen und Dokumenten Das Vorgehensmodell ist vor allem im öffentlichen Bereich verbreitet und wird in der Industrie als interne Vorgabe verwendet. Das Vorgehensmodell beschreibt die Aktivitäten (Tätigkeiten) und Produkte (Ergebnisse), die während der Entwicklung von integrieren Systemen durchzuführen bzw. zu erstellen sind. Daneben werden Methoden und Anforderungen an Werkzeuge beschrieben. Das Vorgehensmodell ist aufgrund seiner breiten Gültigkeit extrem umfassend und muss für den speziellen Typ von Entwicklung und danach für das spezielle Entwicklungsprojekt durch Auswahl und Spezifizierung der konkret anzuwendenden Methoden, durchzuführenden Tätigkeiten und zu erstellenden Dokumente angepasst werden (tailoring). Das V-Modell besteht aus vier Submodellen: • Systemerstellung (eigentlicher Entwicklungsprozess), • Qualitätssicherung, • Konfigurationsmanagement, • Projektmanagement. Orthogonal dazu gibt es jeweils durchnummerierte Phasen, Aktivitäten und Produkte. so besteht die Systemerstellung aus dem Aktivitäten • Systemanforderungsanalyse, • Systementwurf, • Anforderungsanalyse, • Grobentwurf, • Feinentwurf,

4.3 Aufgaben im Entwicklungsprojekt • • • •

151

Implementierung, Integration, Systemintegration, Überleitung in die Nutzung.

Das V-Modell von Böhm für die Software-Entwicklung Das V-Modell von [Böhm] stellt die Entwicklungsphasen eines SoftwareProdukts den Test- (Validierungs-, Verifikationsphasen) gegenüber. Die VForm ergibt sich aus dem herablaufenden Entwurfs- und dem nach oben verlaufenden Test-Ast. Durch die V- (oder U-) Darstellung wird der Zusammenhang zwischen Entwicklungsphasen und Testphasen deutlicher. Dabei können für die Phasen verschiedene Einteilungen oder Bezeichnungen gewählt werden. Problemanalyse

Nutzung

Anforderungen

Abnahme

Spezifikation

Validierung

Entwurf

Verifikation

Feinentwurf

Test Implementierung/Prototyping

Abbildung 4-3: Grundprinzip V-Modell Durch die Gegenüberstellung von Problem- und Entwurfsmodellen (Anforderungen, Spezifikationen, Entwurfsdokumente) und Testphasen wird klar, gegen welche Modelle getestet wird. Sollten Probleme beim Testen auftreten, müssen die betroffenen Dokumente und alle davon abhängigen überarbeitet, neu umgesetzt und getestet werden.

4.3 Aufgaben im Entwicklungsprojekt Entwicklung als eine Abfolge von Aufgaben

Die meisten der im Entwicklungsprojekt anfallenden Aktivitäten haben wir im Kapitel Entwicklung betrachtet. Hier geht es um eine projektorientierte Sicht.

152

4.3.1

4 Entwicklung als Projekt

Angebotsbearbeitung

Die Bearbeitung des Angebots ist diejenige Phase des Gesamtprojekts, in der die Weichen für den zukünftigen Erfolg oder Misserfolg des Projekts gestellt werden. Angebotsbearbeitung ist • ein Teil des Projekts, in dem das Entwicklungsprojekt zu großen Teilen definiert wird und in dem es sich entschiedet, ob das nachfolgende Entwicklungsprojekt Erfolg haben kann, • selbst ein Projekt. (Da nicht jedes Angebot zu einem Auftrag führt, werden im Unternehmen viel mehr Angebotsprojekte bearbeitet als Entwicklungsprojekte.) Angebotsprojekte sind für den Erfolg des Unternehmens wichtig. Hier wird das Entwicklungsprojekt im Rahmen des Projektdreiecks festgelegt. Falls Angebotsprojekte nicht vom Kunden bezahlt werden, müssen die Kosten des Angebotsprojekts (und anteilig die Kosten von nicht erfolgreichen Angeboten) vom Entwicklungsprojekt oder der nachfolgenden Produktion erwirtschaftetet werden. Häufig ist der designierte Projektleiter des Entwicklungsprojekts (falls er überhaupt schon bekannt ist) in dieser Phase nicht Leiter des Angebotsprojekts. Wichtig ist, dass er ein Mitspracherecht hat, und dass die Angebotsbearbeitung als Projekt organisiert wird. Wichtige Fragen zur Angebotsaufforderung sind: • Hat der Kunde klare Vorstellungen? • Ist die Aufgabe klar beschrieben? • Ist das eine Lösung für die Probleme des Kunden? • Welche Folgeeffekte wird die Lösung haben? • Ist die Lösung technisch machbar? • Ist der Aufwand zu bewältigen? • Lohnt das Projekt den Aufwand der Angebotsbearbeitung? Projektmanagement für die Angebotsbearbeitung Die Angebotsbearbeitung ist als Projekt zu planen. Wichtig und kritisch ist die starke Interaktion mit dem Kunden und den ausführenden Abteilungen (bzw. Unterauftragnehmer). Dazu müssen die Verantwortlichkeiten, Informationsflüsse, Mitwirkungshandlungen und Entscheidungsregeln für die Angebotsbearbeitung festgelegt werden. Die Festlegung der wichtigsten Meilensteine und eine Meilensteintrendanalyse sind für die Terminplanung und -überwachung notwendig. Die Terminüberwachung ist im Angebotsprojekt besonders wichtig, da hier häufig auf

4.3 Aufgaben im Entwicklungsprojekt

153

Zuarbeit und Entscheidungen interner (Kalkulation, Marketing, Entwicklung, Forschung, Geschäftsleitung) und externer (Kunden, Kostenträger, Zulieferer, Unterauftragnehmer, Dienstleister) Beteiligter gewartet werden muss. Kostenschätzung Basis für Angebotsbearbeitung und Kostenschätzung ist das Verständnis für die Leistungsbeschreibung. Vollständigkeit, Klarheit und Widerspruchsfreiheit der Leistungsbeschreibung sind Voraussetzung dafür, dass ein sinnvolles Angebot abgegeben werden kann. Unklarheiten im Angebot führen später zu Problemen und zusätzliche Punkte verursachen hohe Kosten, die der oben dargestellten Steigerung der Fehlerkosten pro Phase unterliegen. Schätzung und Unsicherheit Eine Schätzung besteht immer aus gemachten Annahmen und resultierenden Schätzwerten, am besten in Form von Schwankungsintervallen, Bandbreiten (Standardabweichung) oder Vertrauensgrenzen. Eine Zahl allein ohne die zugrundeliegenden Annahmen zu nennen ist gefährlich. Auch ein design-to-cost erfordert Kostenschätzungen, da die Relation zwischen Ergebnis und Kosten immer benötigt wird. Diese Kostenschätzungen sollen technisch vertretbar und realisierbar sein. Häufig wird eher ein „estimate-to-cost“ betrieben: die Schätzung wird so lange manipuliert, bis das gewünschte Ergebnis herauskommt. Abweichungen nach unten sind dann aber vom Management zu verantworten, nicht vom Projekt. Anforderungsanalyse Ein großer Teil der Anforderungsanalyse findet in der Angebotsphase statt. Anforderungen wurden bereits betrachtet. Im Entwicklungsprojekt ist es wichtig, die Anforderungen aller Kundengruppen in allen Rollen zu erfassen. Anforderungen müssen genau beschrieben, quantifiziert und operationalisiert werden. Manchmal sind nicht die offensichtlichen Qualitätsfaktoren die für den Nutzen wichtigen, sondern die Anforderungen ergeben sich aus der jeweiligen Nutzung des Produkts durch den Kunden (vergleich dazu z.B. die oben betrachtete Anforderung „Genauigkeit“).

154

4 Entwicklung als Projekt

Anforderungen an eine Uhr Die grundlegende Anforderung an ein Uhr ist zunächst einmal, die Zeit anzugeben oder Zeitintervalle zu messen. Auf den ersten Blick denken wir hier an die Genauigkeit (zufällige und systematische Schwankungen, Unabhängigkeit von Umwelteinflüssen), etwa die mittlere Abweichung zwischen angezeigter und wahrer Zeit. Wichtig ist aber die Konstanz (eine kleine aber regelmäßige Abweichung führt zu einer linearen Relation zwischen angezeigter und wahrer Zeit, die durch Kompensation ausgeglichen werden kann und so eine sehr hohe Genauigkeit ergibt) und Zuverlässigkeit (die wichtigste Eigenschaft einer Uhr ist, dass sie nicht stehen bleibt, dies ist z.B. bei einem Wecker besonders wichtig).

Kostenfaktoren Alle Qualitätsfaktoren wirken sich auf die Kosten aus, da sie Restriktionen an die Entwicklung darstellen. Die Maßnahmen und Vorhaltungen für die Erreichung von Qualität wirken sich aber kostenmindernd auf spätere Phasen (Abnahme, Wartung, Modifikation) aus. Kostentreiber neben den direkten Kernanforderungen können sein: • Qualitätsforderungen (Ausfallsicherheit, Korrektheit), • Leistungsparameter (Durchschnitts-, Spitzen- und Mindestwerte), • Komfort in Bedienung, Installation, Instandhaltung, • Flexibilität in Nutzung und Produkt. Spezifikationen Als Ausgangsbasis für ein Angebot kann eines der folgenden Dokumente genommen werden: • Pflichtenheft (Anforderungen aus der Sicht des Kunden), • Lastenheft (Beschreibung der Leistungen des Systems), • Gemeinsam erarbeitete Requirements als eine Liste mit operationalisierten Anforderungen, • Integrierte Spezifikation in Zusammenarbeit zwischen Kunde und Auftragnehmer. Wichtige Punkte für die Angebotsabgabe Mit dem Angebot legt sich der Anbieter fest. Alles, was unklar formuliert ist, wird später zur Machtfrage und der Kunde sitzt am längeren Hebel. Vor Angebotsabgabe sollte man sich über den Kunden, ähnliche Projekte, ähnliche Entwicklungen und Meinungen von Kollegen informieren. Im Angebot sollte man • alle Leistungen spezifizieren und abgrenzen. Kriterien für die Abnahme und Grenzen des Leistungsumfangs feststellen, • nicht im Angebotspreis enthaltene Leistungen getrennt ausweisen,

4.3 Aufgaben im Entwicklungsprojekt • • • • • •

155

Kundenmitwirkungen und -beistellungen mit Terminen festhalten, Voraussetzungen und Zusammenhänge festschreiben, Änderungsverfahren und Verantwortlichkeiten festlegen, Kosten und Konditionen differenzieren, für zusätzliche Änderungen und Optionen Preise und Kriterien angeben, kaufmännisch/juristische Punkte wie Zahlungsmodalitäten, Fristen, Haftung mit aufnehmen (Wechselwirkungen).

4.3.2 Phasenbezogene Aufgaben Alles hat seine Zeit

Im Folgenden betrachten wir – an das Fünf-Phasen-Modell angelehnt – die wichtigsten Aufgaben im Entwicklungsprojekt. Dazu kommt die dem eigentlichen Entwicklungsprojekt vorgelagerte Angebotsbearbeitung, die als eigenständiges Projekt (durchaus mit Entwicklungscharakter) oder Teil des Entwicklungsprojekts betrachtet werden kann. Planung der Entwicklungsphasen Für das Projektmanagement ist vor allem wichtig, den Ablauf der Phasen und auch mögliche Überlappungen (simultaneous engineering) oder Schleifen (Iterationen) zu berücksichtigen. Das Projekt weicht dadurch vom theoretischen Modell der sukzessive aufeinander folgenden Phasen (Wasserfallmodell) deutlich ab. Bei iterativen Modellen (Evolutionsmodell) muss der Projektablauf an die Zyklen angepasst werden. Auch Zyklen in Folge von Tests müssen einkalkuliert werden. Dies stellt die Projektplanung vor große Herausforderungen, da die Anzahl der Iterationen von vorne herein nicht bekannt oder planbar ist. Aufgaben in den Entwicklungsphasen Die phasenspezifischen Aufgaben im Entwicklungsprojekt ergeben sich durch die oben beschriebenen Aufgaben in den einzelnen Phasen der Entwicklung. 4.3.3 Phasenübergreifende Aufgaben Querschnittsaufgaben sind notwendig – und manchmal lästig

Neben den phasenorientierten Aufgaben, die sich stark an den Stufen des Entwicklungsprojekts orientieren gibt es – neben dem bereits betrachteten Projektcontrolling – Aufgaben, die über die ganze Laufzeit des Projekts relevant sind.

156

4 Entwicklung als Projekt

Projektmanagement Selbstverständlich ist Projektmanagement eine übergreifende Aufgabe. Es ist aber vor allem auch wichtig, gemeinsame Strukturen und Regeln zu schaffen, zu kommunizieren und umzusetzen, nötigenfalls durchzusetzen. Dazu gehören vor allem Kommunikation und das Berichtswesen. Zu Projektbeginn muss das Projektmanagementsystem festgelegt werden. Dazu gehört die Art der Planung, Vorgaben für Projektpläne und Berichte und für das Berichtswesen bzw. die gesamte interne und externe Kommunikation. Entwicklungsrichtlinien In kleineren Projekten oder Gruppen genügen kurze Vorgaben für die Umsetzung des Entwicklungsprozesses und für die Festlegung der zu verwendenden Modelle und Methoden. In größeren Projekten und größeren Gruppen sind formale Richtlinien für den Entwicklungsprozess notwendig. Die Entwicklungsrichtlinien legen fest: • zu verwendende Phasenmodelle und Vorgehensmodelle, • Methoden für Anforderungsanalyse, Entwurf, Implementierung und Test, • Dokumentations-Richtlinien, Dokumentenmanagement, • Qualitätssicherung, Qualitätsmanagement, • Konfigurations-Richtlinien, Konfigurationsmanagement. Diese Richtlinien können je nach Verständnis des Unternehmens und Einsatz des Vorgehensmodells aus dem Vorgehensmodell (z.B. V-Modell) abgeleitet sein, Teile des Vorgehensmodells beinhalten oder – wenn sie ganz umfangreich gesehen werden – das Vorgehensmodell beinhalten und sogar Regeln zur Anwendung des Vorgehensmodells geben. Konfigurationsmanagement und Änderungsdienst Entwicklung ist Änderung. Nicht nur ein der evolutionären Entwicklungen, sondern auch im V-Modell, müssen Änderungen in allen Ebenen der Spezifikationen gepflegt werden. Die Verantwortung für Abweichungen Angebot – Spezifikation – Produkt bei Änderungen liegt beim Ersteller (Vertragsmanagement). Hier ist ein systematisches und konsequentes Konfigurationsmanagement und ein rigider Änderungsdienst mit einer Kontrollinstanz (Change Control Board) notwendig. Dabei sind die Änderungen auch bezüglich ihres Risikos für das Endprodukt und das Projekt zu bewerten. Konfigurationsmanagement

Durch das Vorhandensein mehrer Varianten, durch das Fortschreiten im Entwicklungsprozess, und durch auftretenden Änderungen aufgrund von

4.3 Aufgaben im Entwicklungsprojekt

157

Kundenwünschen oder bedingt durch Entwicklung und Verifikation entsteht das Problem der Zuordnung bzw. Zuordenbarkeit zwischen • Anforderungen und Spezifikationsdokumenten, • Entwurfsdokumenten und Implementierungsunterlagen, • Graphiken zu Spezifikation, Entwurf und Implementierung, • Produkt- und Produktionsunterlage, • Testdaten und Testdokumenten, • (ausgelieferten) Produkten. Hierzu ist ein Konfigurationsmanagement notwendig, das die eindeutige Identifikation jeder Variante jedes dieser Objekte erlaubt und genau diese Zuordnung möglich macht. Reviews und Präsentationen In Präsentationen wird ein Entwicklungsstand dem Kunden (oder auch dem Management) vorgestellt. Vorteile gegenüber der schriftlichen Dokumentation (die auch abgegeben werden muss, aber erläutert werden kann) sind: • Der Adressatenkreis ist bekannt, ein persönlicher Kontakt mit den Zuhörern ist möglich. • Die Zielsetzung ist gegeben, die Nebenbedingungen und der Entwicklungsstand sind zum Zeitpunkt der Präsentation bekannt und fix. • Rückfragen sind möglich, auf das Verständnis der Zuhörer kann eingegangen werden. • Dynamik und Parallelität (mehrere Medien) statt linearem Text erleichtert die Vermittlung komplexer Zusammenhänge und Abläufe. • Die Adressaten sind an einem gemeinsamen Ort und können sich eine gemeinsame Meinung bilden. • Gemeinsame Aussagen (statements) der Adressaten sind möglich – auch in Abstimmung mit den Präsentierenden. Deshalb sind Reviews und Präsentationen als Mittel der Kommunikation und als formale Kriterien und Meilensteine wichtig. Paperware Der größte Teil des Entwicklungsergebnisses ist die Dokumentation – auf Papier oder in elektronisch lesbarer Form. Paperware als Ergänzung zu Hardware und Software umfasst nicht nur die Produktbeschreibung in Form von für die Implementierung bzw. Produktion geeigneten Plänen (blueprints), sondern auch die produktbegleitende Dokumentation für Nutzung, Installation, Weiterentwicklung, Wartung und ähnliches und auch die Entwicklungsdokumentation (technische Dokumentation, Dokumentation von Entwicklungsschritten, Phasenergebnissen und Entscheidungen) sowie die Projektdokumentation.

5

Management der Entwicklung Entwicklung braucht Führung

In diesem Kapitel betrachten wir Managementaspekte der Entwicklung. Dabei geht es um Managementaspekte von Entwicklungsprojekten, und um das übergreifende Management, das sich auf mehrere Entwicklungsprojekte, die Entwicklungsabteilung und die Entwicklung als strategische Aufgabe innerhalb eines Unternehmens beziehen kann. Diese Kapitel liefert – wie die anderen auch – keine Patentrezepte, denn das was in dem einen Unternehmen richtig ist, kann in einer andern Situation das falscheste sein. Und was vor zehn Jahren in einem erfolgreichen amerikanischen Unternehmen eingesetzt wurde, bietet keine Garantie für einen Erfolg hier und morgen.

5.1 Entwicklung und Management Führung und Verantwortung 5.1.1

Entwicklungsmanagement

Bei der Betrachtung des Managements der Entwicklung müssen wir die verschiedenen Sichten auf die Entwicklung im Auge behalten. Für eine erfolgreiche Entwicklung ist das Entwicklungsprojekt der Kern, aber nur in den seltensten Fällen steht das Entwicklungsprojekt ganz isoliert da. Es ist innerhalb des Unternehmens sowohl in ein technologisches Umfeld als auch in eine Produktlinie einzuordnen. Dabei bringt die Entwicklungsabteilung das Know-How ein, das durchaus bei andersgearteten Produkten für andersgeartete Kunden erworben worden sein kann. Der Vertrieb bringt die kundenund branchenspezifischen Kenntnisse bezüglich der Anforderungen ein. Unternehmer, Unternehmensmanagement Marketing/Vertrieb Manager der Entwicklungsabteilung Manager einer Produktlinie Manager eines Entwicklungsprojekts

Abbildung 5-1: Sichten auf die Entwicklung

160

5 Management der Entwicklung

Marketing/Vertriebsmanager Kunde Branche

Linienmanager Entwicklung, Know-How, Technologie

Produktmanager: Produktlinie

Produkt

Manager des Entwicklungsprojekts: Projekt, Engineering

Abbildung 5-2: Sichten auf das Produkt Das folgende Diagramm stellt die notwendigen Voraussetzungen für eine erfolgreiche Entwicklung dar. Dabei ist die Hierarchie der Organisation auf den Kopf gestellt, da verdeutlicht werden soll wie die oberen Hierarchieebenen es den unteren Ebenen ermöglichen, ihre Aufgabe zu erfüllen. Die jeweilig übergeordnete Hierarchieebene muss Ressourcen (Finanzmittel, Personal, Infrastruktur, Ausbildung) und die Organisation zur Verfügung stellen, damit die untere Hierarchieebene ihre Aufgaben erfüllen kann. Management von Entwicklungsprojekten Management parallel ablaufender Entwicklungsprojekte: Ressourcen und Koordination

Management sequentiell ablaufender Entwicklungsprojekte: Wissen und Erfahrungen

Management der Entwicklungsabteilung Planung und Kontrolle der Entwicklung

Organisation der Entwicklung

Management der Entwicklung im Unternehmen Planung und Koordination der Entwicklungsaktivitäten

Organisation und Prozesssteuerung der Entwicklungsaktivitäten

Abbildung 5-3: Aufeinander aufbauende Aufgabenstrukturen

5.1 Entwicklung und Management

161

Auch die Tatsache, dass an das Management selbst von verschiedenen Stakeholden und Shareholdern Ansprüche gestellt werden, ergibt die aus dem Projektmanagement bekannte doppelte Pyramide. Markt Stand der Forschung und Technik Shareholder Stakeholder Unternehmensleitung Bereichsleitung Projektverantwortliche Projektleitung Teilverantwortliche Vertrieb/Marketing, Kaufmännisches, Technik Teilprojekt- und AP-Verantwortliche Entwicklung Mitarbeiter Projekt/Vertrieb

Abbildung 5-4: Doppelte Projektpyramide für Entwicklungsprojekte 5.1.2

Managementaspekte des Projektmanagements

Das Projektmanagement haben wir ausführlich betrachtet. Wir kommen hier im Kapitel Management nochmals darauf zurückkommen, weil es ein „Projektmanagement über dem Projektmanagement“ gibt. Diese Punkte wurden im Kapitel Projektmanagement bereits erwähnt, aber sie betreffen den Top- oder Linienmanager noch mehr als den eigentlichen Projektmanager. Viele Projekte scheitern nicht an unzureichender Methodenkenntnis oder mangelndem Teamgeist, sondern an Problemen der externen Kommunikation, unklaren Zielsetzungen und unrealistischen Zielvorgaben. Das Management initiiert die Projekte. Hier liegt dann auch die Verantwortung für eine klare und klar kommunizierte Zielsetzung und realistische Zielvorgaben im magischen Projektdreieck. Optimitis In [Weinberg] wird das Ignorieren des Magischen Dreiecks humorvoll beschrieben: » ... most serious occupational disease is known as optimitis. ... It is an inflammation of the optimization nerve, that part of the nervous systems which responds to such request as “Give us the minimum cost solution” “Get it done in the shortest possible time” “We must do it in the best possible way”.

162

5 Management der Entwicklung

In a healthy individual, the optimization nerve receives such requests and sends an impulse to the mouth to respond “What are you willing to sacrifice?”. In the diseased individual, however, this neural pathway is interrupted, and the mouth utters some distorted phrases like “Yes, boss. Right away, boss.” «

5.2 Grundlagen für das Management Ziele setzen und führen

Zu den Managementgrundlagen zählen wir die Themen Zielsetzung, Führung, Entscheidung und Organisation. Wir werden zunächst den Managementprozess als ganzes betrachten, und die Themenbereich Führung und Unternehmensbild vertiefen. Den zweiten Schwerpunkt bildet die Betriebswirtschaft, da wirtschaftliche Entscheidungen die Grundlage des Managementprozesses sind. 5.2.1

Management

Klassischerweise ist ein Manager jemand, der ein Unternehmen führt, ohne Eigentümer zu sein. Damit grenzt sich Management vom Unternehmertum ab. Der Manager agiert als professioneller Führer einer Organisation im Auftrag und im Sinne der Eigentümer. Kompakt könnte man folgendermaßen gegen das Unternehmertum abgrenzen: „Management ist die Erreichung fremder Ziele mit fremden Mitteln auf eigenen Wegen.“ Grundfunktionen Die Aufgaben des Managements werden von [Ulrich/Fluri] zu vier Grundfunktionen zusammengefasst: • Unternehmens-Philosophie, -Ethik und -Politik, • Unternehmensplanung und Kontrolle, • Organisation und Führung, • Führungskräfteentwicklung. Während die beiden mittleren Gruppen klassische Bereiche sind, sind die äußeren beiden Grundfunktionen im Sinne einer nachhaltigen Entwicklung des Unternehmens notwendig. Grundaufgaben Unabhängig von den genannten Funktionen, nimmt das Management die folgenden Grundaufgaben direkt oder durch entsprechende Systeme wahr: • Informieren, Informations- und Wissensmanagements, • Entschieden, Entscheidungsstrukturen und -prinzipien,

5.2 Grundlagen für das Management

163

• Umsetzen, Weisungsstrukturen und Ressourcenbereitstellung.

Jede Entscheidung (Auswahlentscheidung oder Strukturentscheidung) erfordert Informationen als Basis und muss –um wirksam zu werden – umgesetzt werden (inklusive der notwendigen Kontroll- und Regelungsaktivitäten). Wichtig ist auch, dass nicht nur die Entscheidung unter gegebenen Kriterien, sondern auch das Setzen von Zielen und Kriterien betrachtet wird. Dabei können wir Planen und Organisieren als Entscheiden betrachten, das auf das zukunftsorientiertes Gestalten und Auswählen von Strukturen gerichtet ist. Managementebenen Zusätzlich zu den oben betrachteten Managementfunktionen und den Hierarchieebenen kann man verschiedene Ebenen oder Stufen unterscheiden (nach [Ulrich/Fluri]): • Normatives Management: Aufbau unternehmungspolitischer Potentiale, Setzen ethischer Ziele. • Strategisches Management: Aufbau strategischer Potentiale, langfristige Planung und Positionierung, Berücksichtigung des sich entwickelnden und (re)agierenden Umfelds. • Taktisches Management: Aufbau betrieblicher Potentiale, mittelfristige Planung, Steuerung der externen Aktivitäten in Wechselwirkung mit dem Umfeld (Kunden). • Operatives Management: Unmittelbare Steuerung des Wertschöpfungsprozesses, Steuerung der internen Aktivitäten und der Wertschöpfung. Diese sind zu den vier Grundfunktionen orthogonal, d.h. jede der Grundfunktionen muss in jeder der Ebenen umgesetzt werden, wobei die nachhaltigkeitsorientierten Funktionen eher – aber nicht ausschließlich – den normativen und strategischen Ebenen zuzuordnen sind. Managementprozess Den Kernprozess des Managements könnte man – in Ergänzung des PDCAZyklus (Plan-Do-Check-Act) durch die folgenden Aufgaben und Fragen beschreiben:

Tabelle 5-1: Managementprozess Aufgabe Ziele festlegen Probleme identifizieren Aus Problemen Wünsche machen Lösungsmöglichkeiten sammeln

Kernfrage WAS WOLLEN WIR? WAS IST NICHT GUT? WAS KÖNNTE BESSER SEIN ? WIE KÖNNTE ES GELÖST WERDEN ?

164

Aufgabe Nebenbedingungen Kriterien sammeln Lösungsansätze sammeln Lösung auswählen Lösungsweg planen Umsetzung planen Umsetzung durchführen Lösung prüfen Lösung verbessern

5 Management der Entwicklung

Kernfrage WAS MUSS MAN BEACHTEN ? WAS WOLLEN WIR ERREICHEN? WAS KÖNNEN WIR TUN ? WAS SOLLEN WIR TUN ? WIE SOLLEN WIR ES TUN ? WIE WERDEN WIR ES TUN ? TUN WIR DAS? HABEN WIR DAS RICHTIGE GETAN ? WAS WOLLEN WIR NUN?

Einflüsse Durch die Organisation sollen die primären Ziele des Unternehmens erreicht werden. Daraus leiten sich die Sekundärziele für die Organisation ab, die Basis für die Festlegung der Organisationsstrukturen sind. Interessenten, die die Entscheidungen der Entscheidungsträger beeinflussen wollen, sind: • Eigentümer (Shareholder), die letztendlich ihre Entscheidungskompetent weitergeben und eine Entscheidung im Sinne des Unternehmenserfolgs wollen. • Unternehmensleitung (top management) und alle übergeordneten Entscheidungsträger (Manager), die für die jeweiligen Entscheidungen verantwortlich sind, und auch eigene Ziele haben. • Interessierte Kreise (Stakeholder), die von den Entscheidungen betroffen sind. Hierzu gehören auch die Mitarbeiter, die direkt (Weisungen, Ressourcenzuweisung) oder indirekt (Unternehmenserfolg) betroffen sind. Führung, Motivation und Macht Führung setzt die Ziele und Entscheidungen um und bewegt Menschen dazu, im Sinne der Vorgaben zu handeln. Sie baut auf der Motivation der Geführten und der Macht der Führenden auf. Der Begriff Motivation beschreibt den Antrieb eines Individuums für eine bestimmte Handlung. Diese kann intrinsisch (aufgrund eigener Ziele) oder extrinsisch (Einfluss anderer Personen oder Systeme) sein. Macht ist die Möglichkeit, den eigenen Willen auch gegen den Widerstand anderer durchzusetzen. Eine insbesondere im Zusammenhang mit Projekten besonders wichtige Form ist die funktionale Autorität: Die inhaltlich beschränkte Macht beruht auf einer Aufgabe und dem Recht, zur Erfüllung dieser Aufgabe Weisungen zu erteilen.

5.2 Grundlagen für das Management

165

Mitarbeiter und ihre Motivation sind ein entscheidender Faktor zum Erfolg des Unternehmens. Obwohl eine einfache Theorie sicher nicht ausreicht, das Verhalten eines Individuums oder einer Gruppe zu erklären, gibt es einige Grundtheorien zur Erklärung des menschlichen Verhaltens, insbesondere der Motivation, die jeder, der sich mit Management beschäftigt, kennen sollte: • Maslowsche Bedürfnispyramide: Der Mensch hat eine Hierarchie von Bedürfnissen, deren Erfüllung Basis der Motivation ist. Relevant wird jeweils das niedrigste noch nicht erfüllte Niveau. • X-Y-Theorie: Stellt das Menschenbild eines mündigen motivieren Mitarbeiters dem eines passiven Mitarbeiters gegenüber, der angetrieben, motiviert und überwacht werden muss. • Motivations- und Hygiene-Faktoren: Motivations-Faktoren können durch ihre Gewährung motivieren, während die Hygiene-Faktoren (meist in Form der Abwesenheit entsprechender Demotivationsfaktoren) notwendig sind, um Motivation gedeihen zu lassen. Unternehmensbild Die Unternehmensidentität (Unternehmensbild, Corporate Identity) ist die Gesamtheit aller Merkmale, die ein Unternehmen bestimmen. Unternehmensphilosophie ist nach [Drucker] die Gesamtheit der Annahmen des Unternehmens über die Umwelt. Die Unternehmensphilosophie ist ein Modell dessen was das Unternehmen in seinem Umfeld sein soll und wofür es da ist. Die Unternehmensziele werden von der Geschäftsleitung unter Einbeziehung der Mitarbeiter festgelegt und im Rahmen der Unternehmensleitlinien festgeschrieben und publiziert. Sie bilden den Rahmen für alle Firmenaktivitäten. Das Unternehmensleitbild wird insbesondere im Qualitätsleitbild (Qualitätspolitik) des Unternehmens umgesetzt. Dabei werden nicht nur Visionen und Ziele festgelegt, sondern auch implizit oder explizit Prioritäten gesetzt. Unabhängig oder ergänzend zum Unternehmen kann auch ein einzelnes Produkt, eine Produktgruppe oder die gesamte Produktpalette eines Unternehmens ein Image haben. Ein besonderer Fall von Unternehmensidentität oder Produktimage sind Marken. Organisation Organisation stellt die Basis für die Unternehmensführung zur Verfügung.

166

5 Management der Entwicklung

Der Begriff Organisation kann als Struktur oder als Tätigkeit verstanden werden: • Organisation als Struktur: die Organisationsstruktur des Unternehmens. • Organisation als Tätigkeit des Strukturierens (organisieren). • Organisation als Synonym für die Institution als ganzes. Für das Management liegt der Schwerpunkt in der Aufgabe des Organisierens. Dazu ist die Kenntnis der Ziele und Komponenten der Organisationsstruktur notwendig. Wir unterscheiden zwischen den beiden Komponenten: • Die "statischen" Aufbauorganisation regelt die Struktur des Unternehmens, hierarchische Unterstellung und Weisungsbefugnisse. Sie legt die Beziehungen im Unternehmen langfristig fest. • Die "dynamischen" Ablauforganisation legt fest, wie Prozesse und Projekte ablaufen, wie Entscheidungsprozesse ablaufen und wie Informationen weiterzugeben sind. Sie legt für anfallende Aufgaben die dynamischen Abläufe aufgaben- und prozessbezogen fest. Die Entscheidungen, die im Rahmen der Organisation getroffen werden, kann man im Hinblick auf ihre Relevanz für die Organisation folgendermaßen klassifizieren: • Objektentscheidungen (operative Entscheidung), die die Ausführung bestimmter Tätigkeiten betreffen, • Kommunikationsentscheidungen, die die Weitergabe, Verbreitung oder Anforderung von Informationen betreffen, • Organisationsentscheidungen, die als Metaentscheidung die Entscheidungen anderer (im Allgemeinen untergeordneter) Stellen beeinflussen sollen. Diese nachgeordneten Entscheidungen können wieder Objekt-, Kommunikations- oder Organisationsentscheidungen sein. Aus den oben beschriebenen Aufgaben leiten sich folgende Aufgaben ab: • Aufgaben zuordnen: Die operativen Aufgaben und die oben genannten Entscheidungen müssen letztendlich Personen zugeordnet werden. • Verantwortlichkeiten zuordnen: Mit der Entscheidungskompetenz muss auch die Verantwortung zugeordnet werden. • Kommunikationswege strukturieren: Der Informationsfluss und die Weitergabe von Wissen müssen organisiert werden. • Ressourcenzuordnung systematisieren: Der Zugriff auf Ressourcen (Personal, Material, Maschinen, Finanzen) muss vom Prinzip her festgelegt werden. • Span of control kalibrieren: Die Anzahl der Instanzen (Stellen, Personen) auf die ein einzelner Entscheidungsträger direkt einwirkt, soll in einer vernünftigen Größenordnung liegen.

5.2 Grundlagen für das Management

5.2.2

167

Managementwerkzeuge

Es gibt eine Unzahl von Managementwerkzeugen und zugrundeliegenden Ideen. Managementwerkzeuge dienen zum • Erkennen und Aufzeigen von Entwicklungen (Trends), Problemen und Handlungsalternativen (Analyse), • Finden von möglichen Lösungen und nicht offensichtlichen Handlungsalternativen (Synthese), • Erkennen optimaler Alternativen und Auswählen von Entscheidungen, Treffen und Umsetzen von Entscheidungen, • Problemlösen auf operativer und strategischer Ebene. Diese Aufgaben können durchaus in Analogie zum Entwicklungsprozess gesehen werden. Dies wird auch im Abschnitt über Strategieentwicklung deutlich werden. Managementwerkzeuge können quantitativ oder qualitativ sein, häufig sind sie graphisch (unterstützt). Die Menge der Werkzeuge ist immens, hier wollen wir nur allgemeine Werkzeuge ansprechen, soweit sie für das Projektmanagement und den Projektmanager brauchbar sind. Graphische Darstellungen Viele Managementwerkzeuge diesen der Visualisierung, um damit im Team bessere Entscheidungen zu treffen. Die verschiedenen Darstellungen dienen der Visualisierung von • Konzepten, • Zusammenhängen, • statistischen, empirischen oder planerischen Daten. Die kreativitätsfördernden Effekte von graphischen Darstellungen (für das Individuum und insbesondere in Gruppen) wurden bereits im Kapitel Kreativitätstechniken betrachtet. Darstellung numerischer Größen

Numerische Größen können insbesondere in Tabellen dargestellt werden. Als graphische Darstellung bieten sich Spinnenrad und Portfolio an. Strukturen Durch vorgegeben Darstellungsformen (z.B. Wabe und Fischgräte) und durch Vorgabe von Begriffen (z.B. die 6M: Mensch – Maschine – Material – Mitwelt – Methode – Management) lassen sich Gedanken strukturieren (siehe Kreativitätstechnik). Allerdings darf dies das Denken nicht behindern oder zu sehr in vorgegebene Bahnen lenken.

168

5 Management der Entwicklung

Matrixdiagramm Das Matrix- oder Portfolio-Diagramm ist eine halbgraphische formalisierte Darstellung von Zusammenhängen zwischen zwei Variablen bzw. der Abhängigkeit einer dritten Variable (die z.B. durch die Größe eines Kreises oder durch Symbole dargestellt wird) von zwei unabhängigen Variablen. Matrixeinträge können sein: • Zahlen (Werte, Bewertungen), • Symbole einer definierten Menge, • Begriffe oder Skizzen. Nutzwertanalyse Ein Beispiel für ein quantitatives Verfahren ist die im Kapitel Entwicklung bereits beschriebene Nutzwertanalyse. Genau genommen ist sie halb-quantitativ, da die zugrundeliegenden Größen subjektiv bestimmt werden. Sie ist aber als Entscheidungsunterstützung zur Auswahl zwischen Alternativen recht brauchbar. 5.2.3 Betriebswirtschaft Ohne Moos nix los

Betriebswirtschaftliche Grundlagen sind für den Manager unentbehrlich, da er wirtschaftliche Entscheidungen zu fällen hat. Die Betriebswirtschaft liefert die theoretische Basis für die Entscheidungen des Unternehmers und des Managers. Rechnungswesen Das Rechnungswesen umfasst zwei Hauptbereiche: • Buchführung: sie umfasst externe finanzielle Vorgänge zwischen Unternehmen und Umwelt. Die zentralen Begriffe sind das Nettovermögen des Unternehmens sowie Ertrag und Aufwand. Der Gewinn ist in der Buchführung der Überschuss des Ertrags über den Aufwand bzw. die Änderung des Nettovermögens • Kosten- und Leistungsrechung: sie dient der internen Erfassung und Kontrolle der Wertschöpfung im Unternehmen. Grundbegriffe der Kostenund Leistungsrechnung sind Kosten bzw. Leistung, die den Wertverbrauch bzw. Wertzuwachs bei der Leistungserbringung darstellen. Dem Gewinn entspricht hier das Betriebsergebnis, das ist der Überschuss des Geldwerts der abgesetzten Leitungen über die Kosten.

5.2 Grundlagen für das Management

169

Gewinn und Erfolg Ziel eines jeden wirtschaftlichen Unternehmens ist es, langfristig Erfolg zu erzielen. Aus betriebswirtschaftlicher Seite ist die Herstellung der Verbrauch von Unternehmensressourcen (Material, Personaleinsatz, letztendlich also von Geld) zur Erzeugung des Produkts (Aufwand), der Absatz dient dazu, für das Produkt wieder Geld zu erlösen (Ertrag). Diese beiden Seiten spielen auch beim Aufbau des Managements eine Rolle: Verbesserung des Ertrags und Verringerung der Aufwände. Unternehmenserfolg Ertrag Erlös aus der Leistungserbringung (Veräußerung der Produkte)

Aufwand Kosten zur Erstellung der Leistungen (Produkte)

Abbildung 5-5: Komponenten des Unternehmenserfolgs Kostenrechnung Die Kostenrechnung dient als Grundlage für die wichtigen betrieblichen Entscheidungen. Sie soll dem Unternehmer zeigen, wo welche Kosten und Erträge warum anfallen. • Vollkostenrechnung: Alle Kosten werden erfasst und verteilt, dadurch lässt sich erkennen, welche Produkte und Bereiche wie viel Gewinn erwirtschaftet haben. Die Kosten werden eingeteilt nach: − Kostenarten (Betriebsabrechung), − Kostenstellen, − Kostenträger (Betriebsabrechungsbogen). • Die Teilkostenrechung ist ein entscheidungsorientierter Ansatz: Ausgangspunkt ist die Frage, ob eine Aktivität (Produktion, Projekt) sinnvoller weise durchgeführt wird, d.h. ob diese Aktivität einen positiven Beitrag zum Gesamtergebnis liefert. Dazu betrachtet die Teilkostenrechnung (auch Deckungsbeitragsrechnung oder Direct Costing) zu jeder Aktivität die direkten, d.h. aktivitätsabhängigen Kosten. Kernbegriff ist der Deckungsbeitrag, d.h. derjenige Beitrag, den eine Aktivität zum Gesamterfolg des Unternehmens leistet. Mit dem Deckungsbeitrag wird dabei zwischen den beiden Möglichkeiten verglichen, eine Aktivität auszuführen oder zu unterlassen. Basis der Entscheidung ist die Auswirkung dieser Entscheidung auf den betrieblichen Erfolg. Dabei ist sowohl auf der Seite der Erlöse als auch auf der Seite der Kosten zu fragen, welche Beträge sich durch diese Aktivität ergeben. Wenn man diese Aktivität als eine kleine zusätzliche Aktivität im Rahmen der gesamten betrieblichen

170

5 Management der Entwicklung

Aktivitäten betrachtet, muss man also Grenzerlös und Grenzkosten bestimmen. − Erlösseite: Erlös wird als feste Größe angenommen (keine Substitution oder Sättigung). − Kostenseite: betrachtet werden nur die variablen Kosten, genau genommen die Grenzkosten bezüglich der jeweiligen Aktivität (auch Lohnkosten, Geldbeschaffungskosten und ähnliches müssen in variable und fixe Anteile aufgeteilt werden). − Deckungsbeitrag = Beitrag zum Gesamtergebnis (Bruttoerfolg) = Umsatzerlös – Grenzkosten. 5.2.4

Normative Aspekte

Management setzt Ziele und leitet die Umsetzung. Dabei ist der Manager – im Gegensatz zu weisungsgebundenen Mitarbeitern – relativ frei. Um so mehr ist er selbst verantwortlich und deshalb spielen für ihn die normativen Vorgaben eine wichtige Rolle. Recht Für das Management der Entwicklung spielen verschiedenartige juristische Aspekten eine Rolle. Schwerpunkte liegen zum einen bezüglich des Produkts vor allem im weiten Feld des Patent- und Urheberrechtrecht und der Produkthaftung und zum anderen in dem Bereich, der die Produkterstellung und das Verhältnis zwischen Unternehmen und Mitarbeitern regelt wie Arbeitsrecht und die Sicherheitsgesetzgebung. Nicht zuletzt regelt das Gesetz auch die Spielregeln zwischen den Teilnehmern am Markt. Für weitere rechtliche Grundlagen sei [Zerres/Zerres] empfohlen. Ethik Ethische Aspekte spielen in Management und Betriebswirtschaft eine wichtige Rolle. Im Bereich Entwicklung kommt die Frage nach den Auswirkungen des Produkts hinzu. Bei ethischen Betrachtungen geht es nicht darum, sachlich-wissenschaftlich die Fakten darzustellen, sondern diese Tatsachen zu bewerten. Diese Bewertung kann nicht allein wissenschaftlich begründet werden, sondern basiert auf ethischen Prinzipien (Werte, Regeln, Gesetze, Verantwortung). Beispiele für ethische Überlegungen liegen nicht nur im unternehmerischen Bereich, sondern auch in Bereich wie Tests und Produkteinführung: „Kann ich es verantworten, das Produkt anzuwenden/nicht anzuwenden?“ Als Beispiele dafür können Medikamente und Behandlungsmethoden, Sicherheits-

5.3 Qualitäts- und Risikomanagement

171

relevante Teilen und Informationsverarbeitung, aber auch Verfahren und Methoden bei Dienstleistungen sein.

5.3 Qualitäts- und Risikomanagement No risk no fun?

Qualität und Risiko sind nicht nur als Produktaspekte entscheidend. Es ist auch eine wichtige Aufgabe des Entwicklungsmanagements, die Managementsysteme für Qualität und Risiko zu installieren und die Voraussetzungen zu schaffen. Der Schwerpunkt liegt nicht auf der Qualitätsprüfung sondern auf der Ausrichtung der gesamten Organisation an Qualität. 5.3.1

Qualität nach ISO 9000

"Qualität ist, wenn der Kunde wiederkommt und nicht das Produkt". Dieser Spruch drückt die beiden wesentlichen Aspekte des Begriffs Qualität aus: • die Freiheit von Fehlern, • die Zufriedenheit des Kunden. Dabei kann das betrachtete Produkt ein physisches Produkt oder eine immaterielle Schöpfung, ein Konzept oder eine Dienstleistung sein. Übersicht Die Norm ISO 9001 beschreibt die Anforderungen an Qualitätsmanagementsysteme. Die frühere Abstufung in die ISO-Normen 9001, 9002 (ohne Entwicklung) und 9003 (ohne Produktion) entfiel mit der Einführung der neuen ISO 9001:2000. Hier liegt gerade für das Entwicklungsmanagement ein wichtiger Punkt, da Unternehmen mit einer Zertifizierung nach ISO 9002 ja per definitionem keine eigene (Produkt-) Entwicklung hatten und damit diese Aspekte wegfielen, obwohl durchaus Entwicklungsaspekte in bestimmten Bereichen vorhanden sein konnten. Nach der neuen Norm hat das Unternehmen alle notwendigen Schritte im Produktentstehungsprozess zu betrachten. Die Struktur der Norm orientiert sich an den wichtigsten Prozessen in der Produktentstehung. Die Gliederung ist folgendermaßen: 0. Einleitung 1. Anwendungsbereich 2. Verweise 3. Begriffe 4. Anforderungen an das Qualitätsmanagementsystem 5. Verantwortung der Leitung 6. Ressourcenmanagement

172

5 Management der Entwicklung

7. Prozessmanagement 8. Bewertung, Analyse und Verbesserung Dabei entsprechen die letzten vier Punkte den Prozessen. Sie müssen explizit ausgearbeitet und gelebt werden: 5. Verantwortung der Leitung Qualitätspolitik Beurteilung 6. Ressourcenmanagement Personal, Material Infrastruktur

8. Bewertung, Analyse, Verbesserung Auditierung Evaluierung

7. Prozessmanagement Betrieblicher Leistungserstellungsprozess (Produktrealisierung) Planung, Entwicklung, Produktion Auftragsabwicklung

Abbildung 5-6: Kernprozesse der ISO 9001 Qualitäts-Prinzipien Die Norm zum Qualitätsmanagement basiert auf den folgenden Prinzipien: • Kundenfokussierte Organisation, • Führungsstärke, systematisches Managementvorgehen, • Involvierung der Mitarbeiter, • Prozessorientierung, sachliches Entscheidungsverfahren, • Lieferantenverhältnisse zum gegenseitigen Vorteil, • Kontinuierliche Verbesserung. Prozessmodell Der Grundprozess ist der Leistungserbringungsprozess des Unternehmens, der die Wertschöpfung bringt. Dieser und die ergänzenden bzw. vor-/und nachgelagerten Prozesse sowie die parallelen und übergeordneten Prozesse sind zu modellieren: • Leistungserbringungsprozess, • Führungsprozess, Managementprozess, Leitungsprozess, • Unterstützungsprozess, Ressourcenzuführungsprozess, Supportprozess, • Verbesserungsprozess mit Prüfung, Bewertung, Analyse, Verbesserung.

5.3 Qualitäts- und Risikomanagement

173

Prozessmanagement Die Prozesse des Unternehmens stehen im Mittelpunkt. Prozessmanagement (Process Management) umfasst: • Kundenbezogene Prozesse, Analyse der Kundenbelange, • Design und Entwicklung, • Beschaffung, • Produktions- und Dienstleistungsprozess Erzeugung, • Distribution, • Steuerung bei Abweichungen, • Kundendienst/Service oder Dienstleistungen nach Auftragserfüllung. Verantwortung der Leitung Die Verantwortung der obersten Leitung wird noch mehr betont. Sie ist in allen Systemen Grundvoraussetzung für die Anerkennung eines Qualitätsmanagementsystems. Die Verantwortung der obersten Leitung (Management Responsibility) umfasst: • Kundenbedürfnisse und -forderungen, • Qualitätspolitik, Qualitätsziele und -planung, • Qualitätsmanagementsystem und Bewertung durch das Management Ressourcenmanagement Ressourcen sind Voraussetzung für die Erstellung der Leistung. Die Bereitstellung der Ressourcen ist eine wichtige Aufgabe des Managements und sowohl direkte (Maschine, Material, Mitarbeiter, Methode) als auch indirekte (Motivation) Voraussetzung für Qualität. Ressourcenmanagement umfasst: • personelle Ressourcen, • materielle Ressourcen, • andere Ressourcen: − Informationen, − Infrastruktur, Arbeitsumfeld. Bewertung, Analyse und Verbesserung Der kontinuierliche Verbesserungsprozess (KVP) mit den Teilen Bewertung, Analyse und Verbesserung (Measurement, Analysis and Improvement) umfasst: • Prüfen und Bewerten, • Analysieren der Ergebnisse und Daten, • Verbesserungen.

174

5 Management der Entwicklung

Die kontinuierliche Verbesserung lässt sich als eine Iteration zwischen modellbasierter Planung (Plan), Umsetzung der Planung in der Realität (Do) und der integrierenden Überprüfung (Check) mit steuernder Reaktion (Act) sehen: Modell plan = Ausgangsmodell (re-) act = Steuerung

Realität do = Implementierung Verbesserung

check = Messung, Prüfung

Abbildung 5-7: KVP: PDCA-Zyklus zwischen Modell und Realität 5.3.2 Qualitätsmodelle

Neben der Norm ISO 9001 gibt es weitere wichtige Konzepte und Modelle zum Qualitätsmanagement. Daneben sind für die Entwicklung die im folgenden Kapitel betrachteten Reifegradmodelle wichtig. TQM Total Quality Management (TQM) ist weniger ein System als vielmehr die Grundhaltung, Qualität in den Mittelpunkt der Firmenaktivitäten zu stellen. Dazu gehört vor allem, dass alle Mitarbeiter – angefangen bei der obersten Leitung – Qualität als oberstes Ziel betrachten und eine nachhaltige Strategie über kurzfristige Ziele setzten. Die wichtigsten Elemente sind: • Orientierung am Kunden und an der Qualität des Produkts und der Prozesse, • Stetige Verbesserung der Leistung, Integration aller Mitarbeiter in den Verbesserungsprozess, • Integration von Kundenorientierung und Qualitätsorientierung in die Firmenstrategie (Unternehmenspolitik, Leitbild, Unternehmensidentität), • Einbindung der Mitarbeiter durch Kommunikation, Ausbildung, Anerkennung und Übertragung von Kompetenz und Verantwortung, • Bereitstellung der Ressourcen und Promotoren zur Erreichung von Qualität und zur stetigen Verbesserung, • Identifikation, Verbesserung und Verkürzung der wichtigen Geschäftsprozesse in Produktion und Management, • Identifikation, Messung und Berücksichtigung der Meinung von Kunden, Mitarbeitern und Öffentlichkeit.

5.3 Qualitäts- und Risikomanagement

175

Eine konsequente Qualitätsorientierung umfasst folgende Punkte: • Kundenorientierung: Qualität orientiert sich an den Ansprüchen des Kunden. Dabei sind alle Kunden (und im Weiteren alle Anspruchsgruppen) in den verschiedenen Rollen zu berücksichtigen. • Qualität des Produkts: Als transzendente Größe im Sinne eines "guten" oder "optimalen" Produkts oder durch eine hochwertige, konstante und garantierte Ausprägung der qualitätsbestimmenden Merkmale. • Qualität der Prozesse: Eine Erhöhung von Qualität und der Zufriedenheit von Kunden, Mitarbeitern und Anspruchsgruppen ist nur durch Beachtung und Verbesserung aller Prozesse möglich. • Ressourcen: Die Ressourcen für die Erzeugung und Gewährleistung von Qualität müssen bereitgestellt werden. TQM wird unglaubwürdig, wenn mit Hinweis auf Kosten notwendige Ressourcen verweigert werden. • Promotoren: Verbesserungen müssen auch gegen interne und externe Widerstände durchgesetzt werden können. • Messung: Qualität und Qualitätsverbesserungen sollten mit objektiven (Produkteigenschaften) und subjektiven (Kundenzufriedenheit) Kriterien gemessen und beurteilt werden. • Mitarbeitereinbindung: Die Einbindung aller Mitarbeiter erfordert Kommunikation, Ausbildung, Anerkennung, Kompetenz und Verantwortung. • Image: Die Messung der Zufriedenheit und der Meinung nicht nur des Kunden, sondern auch anderer Anspruchsgruppen ist wichtig. • Shareholder und Stakeholder: Neben der Leistungserstellung für den Kunden sind Wertschöpfung und gesellschaftliche Verantwortung wichtige Aufgaben des Unternehmens. Deshalb spielen neben den Kunden und Mitarbeiter auch die gesellschaftlichen Anspruchsgruppen und die Geldgeber eine wichtige Rolle. EFQM Das Modell für Umfassendes Qualitätsmanagement der EFQM (European Foundation for Quality Management) arbeitet nach dem Prinzip der Selbstbewertung und kennt als Grundelemente die Befähiger (Voraussetzungen, enabler) und die Ergebnisse (results).

176

5 Management der Entwicklung

Mitarbeiterorientierung Führung Management

Politik und Strategie Ressourcen

Kundenzufriedenheit Prozesse

Mitarbeiterzufriedenheit gesellschaftliche Verantwortung

Befähiger

Geschäftsergebnisse

Ergebnisse

Abbildung 5-8: EFQM-Modell Die Elemente der Selbstbewertung umfassen: • Führung: Verhalten aller Führungskräfte, um das Unternehmen zu umfassender Qualität zu führen, • Politik und Strategie: Festlegung von Daseinszweck, Wertesystem, Leitbild und strategischer Ausrichtung des Unternehmens sowie die Art und Weise der Verwirklichung dieser Aspekte, • Mitarbeiterorientierung: Umgang des Unternehmens mit Mitarbeitern, • Ressourcen: Ressourceneinsatz des Unternehmens zur Unterstützung der Unternehmenspolitik und -strategie, • Prozesse: Identifikation, Überprüfung und Anpassung von Prozessen, um eine ständige Verbesserung der Geschäftstätigkeit zu gewährleisten. • Kundenzufriedenheit: Leistung im Hinblick auf die Zufriedenheit der externen Kunden, • Mitarbeiterzufriedenheit: Leistung im Hinblick auf die Zufriedenheit der Mitarbeiter, • Gesellschaftliche Verantwortung: Leistung im Hinblick auf die Erfüllung der Bedürfnisse und Erwartungen der Öffentlichkeit insgesamt (stakeholder). Wahrnehmung, Einstellung und Maßnahmen des Unternehmens zu Lebensqualität, Umwelt und Erhaltung der globalen Ressourcen, • Geschäftsergebnisse: Leistung im Hinblick auf die geplanten Unternehmensziele und die Erfüllung der Bedürfnisse und Erwartungen aller finanziell am Unternehmen Beteiligten (shareholder value) sowie bei der Verwirklichung der geplanten Geschäftsziele. 5.3.3

Prozessfähigkeit und Reifegradmodelle

Prozessfähigkeit bedeutet die Fähigkeit einer Organisation zur sicheren Beherrschung eines Prozesses. Dies kann sich auf kontinuierliche Parameter wie Abweichungen oder aber auf die Wahrscheinlichkeit von Fehlern beziehen. Ein Modell zu Prozessfähigkeit oder Prozessreife erfordert zumindest

5.3 Qualitäts- und Risikomanagement

177

die Betrachtung statistischer Effekte (stochastische Prozesse) und zufälliger Abweichungen. Dabei müssen wie beim Begriff Genauigkeit die kurzfristigen Schwankungen des Prozesses (interne Genauigkeit, Varianz) und die langfristigen Schwankungen (Konstanz) betrachtet werden. Bei Prozessen mit quantitativen Größen und einer stochastischen Verteilung kann die Prozessfähigkeit mit den Methoden der Statistik und mit Maßen wie der Standardabweichung (z.B. im Model Six Sigma) modelliert werden. Solche Prozessfähigkeitsmodelle werden vor allem in der Produktion und der Erbringung von quantitativ beurteilbaren Dienstleitungen angewandt – deshalb muss die Möglichkeit der Prozessreife auch in der Entwicklung von Serienprodukten und Dienstleistungen mit berücksichtigt werden. Die Entsprechung der Prozessfähigkeit bei Entwicklungsprozessen oder anderen nicht quantitativ erfassbaren Prozessen sind Reifegradmodelle. Reifegradmodelle (Maturity Models) messen die Fähigkeiten (Prozessfähigkeit) einer Organisation bezüglich der betrachteten Prozesses. Die Einschätzung geht dabei von einem grundlegenden Prozess, der nicht beherrscht ist und nur zufällig oder durch Nachbesserungen zum Erfolg führt über einen beherrschten und sicheren Prozess bis zur lernenden Organisation, in der der Prozess selbst verbessert wird. Eine grundlegende Einteilung in Stufen gibt die folgende Tabelle: Tabelle 5-2: Reifegrade Bezeichnung Optimierend

Gesteuert

Definiert

Wiederholbar Initial

Charakteristikum adaptiv, selbstlernend, ganzheitlich

Kriterien und Werkzeuge

Qualitätsmanagementsystem Kontinuierliche Verbesserung Veränderungsmanagement Verantwortung der obersten Leitung Standardisierung der Entwicklung quantitativ begründet Qualitätsplanung Interne Reviews und Selbstbeurteilung Standardisierung der Projekte qualitativ definiert, Qualitätsmanagement systematische Prozesse, Regelmäßige Management-Reviews Prozessfähigkeit Prozessstandards erfahrungsbasiert, Qualitätssicherung messbar, dokumentiert Ausbildung, Standardisierung Projektmanagementgrundlagen unvorhersagbar, unkon- Qualitätsprüfung trolliert, informell Experiment, Learning by doing

178

5 Management der Entwicklung

Für die Organisation ist zunächst der Reifegrad realistisch zu beurteilen, darauf aufbauend müssen Maßnahmen zur Erhöhung des Reifegrads geplant und umgesetzt werden. Diese bestehen in der Analyse von Prozessen und Fehlerursachen, Optimierung der Prozesse, Einführung von übergeordneten (Meta) Prozessen zur Prozessverbesserung (KVP), Bereitstellung von Ressourcen und Berücksichtigung der Prozessfähigkeitsaspekte durch das Management und der Qualifizierung der Mitarbeiter auf allen Ebenen. 5.3.4

Risikomanagementsystem

Risikomanagement spielt im Entwicklungsprozess (analog zu den verschiedenen Anwendungen der FMEA) und im Management in verschiedenen Aspekten eine Rolle: • Unternehmensrisiko: Alle Risiken (finanziell, juristisch) aus der unternehmerischen Tätigkeit, die die Wertschöpfung und Wertentwicklung im Unternehmen gefährden. • Produktrisiko: Fehler im Produkt, Mangelnde Erfüllung der Anforderungen oder Schädigung bzw. Gefährdung des Nutzers oder des Umfelds. • Projektrisiko: Negatives Abweichen vom Projektdreieck (Qualitätsrisiko, Kostenrisiko, Terminrisiko, Versagensrisiko). • Entwicklungsrisiko: Abweichung vom Ziel oder Nichterreichen der Anforderungen im Laufe des Entwicklungsprozesses, • Prozessrisiko bei der Produktion. Risikomanagementprozess Der Risikomanagementprozess umfasst die Phasen Identifikation (durch technische Analyse oder aufgrund von Erfahrungen), Analyse und Bewertung und Bewältigung.

Tabelle 5-3: Risikomanagementprozess Phase Hauptfrage Identifikation welche Risiken gibt es? Analyse wie wichtig sind die Risiken? Bewältigung was muss man gegen das Risiko tun?

Ergebnis Risikoinventar Risikoportfolio Risikomaßnahmen

Risikoportfolio Das Risikoportfolio stellt die erkannten und bewerteten Risiken dar. Die Risiken werden mit ihrer Wahrscheinlichkeit und ihren Auswirkungen bewertet und in einem zweidimensionalen Diagramm (Portfolio) dargestellt. Dadurch wird nicht nur der Erwartungswert berücksichtigt, sondern auch die

5.3 Qualitäts- und Risikomanagement

179

Auswirkungen. Die zu ergreifenden Maßnahmen richten sich nach der Wahrscheinlichkeit und der Schwere des Risikos. Mögliche Maßnahmen sind: • Minimieren: Reduktion der Wahrscheinlichkeit oder der Folgen. • Vorbeugen und Erkennen: Installation von Frühwarnsystemen, Bestimmung von Indikatoren für mögliche kritische Trends. • Vermeiden: Ausweichen, Änderungen, Produktlinie aufgeben. • Vermindern: Technische Änderungen, Substitution, personelle und organisatorische Maßnahmen. • Begrenzen und Verteilen: Risikoüberwälzung, Risikoverlagerung, Risikostreuung (regionale, objektbezogene oder personenbezogene Streuung), Vertragsgestaltung, Phasenkonzepte und Abbruchkriterien. • Verbesserungen: Kleine Folgen mit hohen Wahrscheinlichkeiten sind eher eine Aufgabe für ein KVP-Programm (Initiierung eines kontinuierlichen Verbesserungsprozesses). • Versichern: Vor allem für Risiken mit hohen Folgen (kritisch für das Unternehmen) und kleinen Wahrscheinlichkeiten (Prämie). • Tragen: bewusste Entscheidung, ein kalkulierbares Risiko einzugehen. Potentieller Schaden existenzgefährdend

leicht tragbar („peanuts“)

Versichern

Tragen 0 ausgeschlossen

Vermeiden

Verbessern

Wahrscheinlichkeit des Eintretens

sicher 1

Abbildung 5-9: Risikoportfolio mit typischen Maßnahmen Als weitere Komponenten sind Krisenmanagement und Notfallmanagement zu betrachten und die Vorbereitung einer (internen und externen) Kommunikation für eingetretene Notfälle.

180

5 Management der Entwicklung

5.4 Information, Kommunikation und Wissen Wissen ist Macht

Eine der Kernaufgaben des Managements ist die Kommunikation. Dabei geht es nicht nur um die Kommunikation der Ziele und Strategien, sondern auch um die Einrichtung von Informations- und Wissensmanagement im Unternehmen. 5.4.1 Informationsmanagement

Informationsmanagement soll die Strukturen schaffen, dass Informationen und Wissen im Unternehmen dort zur Verfügung stehen, wo sie gebraucht werden. Dabei soll diese Formulierung nicht dazu verleiten, anzunehmen, der Bedarf sein bekannt oder derjenige, der eine Information brauchen kann, wisse dies. (Dieses gegenseitige Bedingen von Metawissen und Vorwissen ist ähnlich der im Kapitel Modellierung betrachteten Problematik von Modell und Modellbildung.) Eine der Hauptaufgabe des Informationsmanagements ist, Bedarfe zu erkennen, auch wenn sie nicht explizit nachgefragt werden und Informationen dorthin zu leiten, wo sie voraussichtlich gebraucht werden. Informationsmanagement ist als strategische Aufgabe im Unternehmen wichtig, es setzt sich bis zum operativen Berichtswesen in Projekten und zur Kommunikation in Team fort. Gestaltung des Informationsmanagements Um ein Informationsmanagement in einem Unternehmen oder einem Projekt als System aufzubauen, sind folgende Komponenten zu gestalten: • Informationsflüsse gestalten, und den Fluss von Informationen intern fördern und extern steuern, • Informationsbedarf kennen lernen und seine Erfassung systematisieren, • Informationen beschaffen, die gebraucht werden oder nützlich sind, • Informationen gezielt bereitstellen und verteilen, • Kommunikation intern und extern strukturieren und initiieren, • Strukturen schaffen, damit obige Prozesse systematisch laufen und die Aktivitäten zuverlässig und regelmäßig stattfinden. Gestaltung der Informationsprozesse Die Hauptfrage bei der Gestaltung der Informationsprozesse ist: „Wer informiert wen wann wie worüber?“ Die Initiierung des Informationsprozesses kann durch Anbieter (push) oder Nachfrager (pull) der Information geschehen und kann regelmäßig (auf

5.4 Information, Kommunikation und Wissen

181

Grund von Terminen, Planung, Meilensteinen) oder situationsabhängig geschehen. Damit gibt es folgende Möglichkeiten: • PUSH: Die Information wird von Anbieter (der die Information hat) an den Nutzer (der die Information nach Ansicht des Anbieters braucht oder gemäß den festgelegten Regeln die Information bekommt) gegeben. Beispiele: − Teilnehmer teilt einem Kollegen seine Telefonnummer mit. − Telefonzentrale schickt jedem angeschlossenen Teilnehmer die Information, dass die Person X eine neue Telefonnummer hat. − Telefonzentrale gibt regelmäßig ein Telefonverzeichnis heraus. − Anschlussinhaber X schickt ausgewählten Personen die Information, welche (evtl. neue) Telefonnummer er hat. − A schickt N den aktuellen Statusbericht bei Erreichen eines Termins (Kalenderzeit, Meilenstein) oder einer kritischen Situation. • PULL: Der Nachfrager N (der eine Information braucht) ruft diese beim Anbieter oder an einer Stelle, wo dieser die Information abgelegt hat, ab. Beispiele: − N fragt einen Kollegen nach dessen Telefonnummer. − N fragt bei der Telefonzentrale nach, was die aktuelle Telefonnummer der Person X ist. − N schaut im Telefonbuch nach der Telefonnummer einer Person X. − N besorgt sich ein aktuelles Telefonverzeichnis. − N fragt bei der Telefonzentrale nach, welche neuen oder geänderten Telefonnummern vorliegen. − N fragt routinemäßig (Kalenderzeit, Meilenstein) oder aus gegebenem Anlass (Situation) bei A den aktuellen Status ab. Diese Frage der Auslösung von Informationsprozessen ist auch eine Basis der Führungsprozesse, auch für die verschiedenen Strategien des „Management-by-XY“. Ein Management by Exception beispielsweise kann ja nur funktionieren, wenn die Information, dass ein kritischer Zustand droht, rechtzeitig weitergegeben wird. Führung kann nur funktionieren, wenn die Führung den Zustand des Systems kennt und die Geführten die aktuellen Ziele und Randbedingungen kennen. Informationsmanagement im Projekt Auch innerhalb des Projekts ist Informationsmanagement eine wichtige Aufgabe. Projektmitarbeiter und Leitung brauchen Informationen, sie dürfen aber von der Informationsmenge nicht erschlagen werden. Deshalb ist eine geeignete Filterung und Verdichtung der Information anzustreben.

182

5 Management der Entwicklung

Wichtig sind klare Spielregeln für die Information im Projekt: Wer informiert wen wann wie worüber? Dabei bedeutet das „wann“ üblicherweise nicht einen Zeitpunkt, sondern Anlässe; und das Informieren kann push (A informiert B) oder pull (A informiert sich bei B) sein. 5.4.2

Wissensmanagement Wenn die Firma wüsste, was die Firma weiß

Wissensmanagement befasst sich mit der Organisation und Strukturierung des Wissens im Unternehmen mit dem Ziel, dieses Wissen im Unternehmen zugänglich zu machen und zu nutzen und die Verknüpfung von Wissen und die Entstehung neuen Wissens zu unterstützen. Wissensmanagement ist kein Selbstzweck sondern soll das, was das Unternehmen eigentlich ausmacht erhalten und zur Verfügung stellen. Wissensverarbeitende Systeme als Produkt werden wir später betrachten. Wissen im Unternehmen Ziel des Wissensmanagements ist, das in der Organisation vorhandene Wissen optimal zu nutzen und die Entstehung neuen Wissens zu fördern. Das Wissen kann vorhanden sein als • Explizites Wissen: formal festgehalten, strukturiert und dokumentiert als Faktenwissen oder Strukturwissen, • Implizites Wissen: informell festgehalten und weitergegeben als stilles oder vages Wissen. Das Hauptproblem ist, die Angebotsseite (Wissensträger) und die Nachfrageseite (Wissensbedarf) zusammenzubringen, da im Allgemeinen die Nachfrageseite nicht weiß, welchen Wissensbedarf sie eigentlich hat (Unwissenheit bedeutet auch, nicht zu wissen, was man nicht weiß) und den Wissensbedarf nicht formulieren kann (Um eine Frage formulieren zu können, ist Basiswissen notwendig, zur Wechselwirkung zwischen Begriffen/Modellen und Erfahrungen siehe das Kapitel Modellbildung). Dazu sind folgenden Aufgaben zu lösen • Erfassung des Wissensangebots, − Informationssammlung (als Basis), − Erfassung der Wissensschwerpunkte in der Organisation, • Erfassen des vorhandenen Wissens, − Informationssammlung (als Basis), − Wissensmodellierung, Wissensrepräsentation, − Erfassung und Repräsentation von Metawissen, • Schaffung von Zugriffsmechanismen und -möglichkeiten, • Erfassung des Wissensbedarfs,

5.4 Information, Kommunikation und Wissen

183

• Schaffung eines Umfelds zur Verbreitung und Nutzung des Wissens, − DV-technisch: Hardware, Software, Vernetzung, Zugriffsverfahren,

Metadatenbanken, − Organisatorisch: Abläufe, Unternehmensphilosophie, Zeit, • Weiterentwicklung des Wissens, − Methodisierung der Informationssammlung, − Motivation zur Weitergabe von Wissen, − Methodisierung des Wissenserwerbs, Lernverfahren. Das Problem des gemeinsamen Codes in der Informationsverarbeitung wird durch das Problem des gemeinsamen Metawissens in der Wissensverarbeitung ergänzt: • Datenaustausch erfordert gemeinsamen Code (Syntax). • Informationsaustausch erfordert gemeinsamen Code (Syntax) und gemeinsame Begriffe (Semantik) für die Information und die Informationscodierung. • Wissensaustausch erfordert gemeinsamen Code und Metacode (Syntax) für Wissen und Wissensstrukturierung, gemeinsame Begriffssysteme (Semantik) und gemeinsame Vorstellungen über die Nutzung des Wissens (Pragmatik). Die Umsetzung des Wissensmanagements erfolgt nicht nur durch formale und DV-gestützte Maßnahmen, sondern auch informell. Dabei sind Faktoren wie die Unternehmenskultur und die Bereitstellung von Zeiten für die Kommunikation wichtig. Semantische Netze Eine sehr allgemeine und vom speziellen Zweck unabhängige Modellierung von Informationen und Wissen ist mit einem Semantischen Netz möglich. Das semantische Netz als Basis der Datenmodellierung besteht aus • Begriffen (Objekte, Klassen), • Beziehungen (zwischen Begriffen). Die Beziehungen gelten dabei nicht nur zwischen Entitäten (Objekte), es werden auch Beziehungen zwischen Klassen und spezielle Beziehungen, die sich auf die Klassenhierarchie beziehen, modelliert. Beispiele sind die Beziehungen: • ist: Die Beziehung einer (Teil-) Klasse zu jeder (Ober-) Klasse, der sie angehört: A ist eine Spezialisierung von B, B verallgemeinert A, B umfasst A. • ist ein: Die Beziehung eines Individuums (Instanz) zu einer Klasse, der es angehört: a ist ein Individuum vom Typ A, a ist ein Beispiel zu A, A beinhaltet das Element a.

184

5 Management der Entwicklung

• ist Teil von: Die physische Beziehung zwischen physischen oder logi-

schen Teilen eines Objekts und dem Objekt: x ist Teil von y, x ist Komponente von y, x ist Aspekt von y, y enthält x. • hat Attribut, ist: Die Beziehung zwischen einem Objekt und einer seiner Eigenschaften: x hat ein Attribut p, p ist eine Eigenschaft von x, x ist p. Eine wichtige Rolle spielt die Vererbung von Relationen und Attributen (Existenz und Ausprägung) von einer Oberklasse auf die Objekte ihrer Teilklasse. Möbel Möbel sind ein beliebtes Beispiel der objektorientierten Modellierung und der Semantik. Die Klasse Möbel hat ein Attribut Zweck, das vererbt wird. In einzelnen Teilklassen wird das Attribut ausgeprägt, so hat die Klasse Stuhl den Zweck „drauf sitzen“. Die Eigenschaft „hat Beine“ ist mit „ja“ und die „Anzahl Beine“ ist beim Stuhl mit „vier“ voreingestellt, andere Ausprägungen sind durchaus denkbar.

Wissensmanagement im Unternehmen Das Unternehmen bekommt einen Auftrag, weil es schon Wissen hat. Wenn wir uns die Frage stellen, warum eine bestimmte Firma oder Person ein bestimmtes Produkt entwickelt oder warum wir ihr einen Auftrag geben, so ist die Antwort: „die kann das“. Dieses Können beruht auf Können und Wissen über • Produkt und Technik (was), • Kunde und Anwendung (für wen), • Vorgehen (wie). Kollektives Wissen (Irgendjemand in der Firma kann das/weiß das.) ist nicht genug. Derjenige, der eine Anfrage bzw. einen Auftrag bearbeitet muss das Wissen identifizieren (finden) können. Vom formalen intelligenten System bis zur informellen Kaffeerunde gibt es viele Lösungsansätze, um den Fluss von Wissen im Unternehmen zu fördern. Wissensbilanzen sind nicht so sehr – wie kaufmännische oder Ökobilanzen – Inventare oder Zusammenfassungen von Strömen, sondern eine Zusammenfassung, wie Wissen im Unternehmen generiert, kommuniziert und verwendet wird.

5.5 Management von Entwicklungsprojekten

5.4.3

185

Lessons Learned Nach dem Projekt ist vor dem Projekt

Einer der Erfolgsfaktoren einer Organisation, die sich mit Entwicklungsprojekten beschäftigt, ist, aus den durchgeführten Projekten zu lernen. Eine systematische Erfassung der Projektdaten und eine Auswertung im Verlauf und am Ende des Projekts sind dafür hilfreich. Basis dafür ist das Berichtswesen. Die wichtigsten Punkte haben wir beim Thema Abschluss von Projekten schon betrachtet. Bei Entwicklungsprojekten kommt hinzu, dass auch die Wiederverwendung von Entwicklungsergebnissen auf allen Ebenen (Modelle aller Art, Anforderungen, Spezifikationen, Entwürfe, Module, Testdaten und Testumgebungen) ermöglicht wird. Erfahrungen werden aber auch informell durch Berichte (storytelling) weitergeben und sind dadurch nicht nur ein Teil des Wissensmanagements sondern auch der Unternehmenskultur.

5.5 Management von Entwicklungsprojekten Effektivität durch Effizienz

Wir wollen das Management von Entwicklungen mit den beiden Ausgangspunkten Markt und Technologie nicht als hierarchisches „von oben aus zwei Richtungen“ sehen, sondern Marketing und Technik als Befähiger betrachten, die es dem Unternehmen ermöglichen, mit neuen Produkten erfolgreich zu werden. Die gemeinsame Basis (hier nicht als Basis eingezeichnet) muss aber ein Top Management sein, das es erlaubt, die Voraussetzungen dafür zu schaffen. Management Projekt Entwicklung Nutzen Kunde

Technik

bringt die Spezifika ein

Objekt

Abbildung 5-10: Entwicklungsprojekt zwischen Kunde und Technik

186

5 Management der Entwicklung

5.5.1 Entwicklungsprojektmanagement Entwicklungsprojekte zielgerichtet leiten

Das Management von Entwicklungsprojekten ist der Kern des Entwicklungsmanagements und dessen operative Umsetzung und Voraussetzung. Aus Sicht des Managements geht es vor allem darum, die richtigen Rahmenbedingungen (Vorgaben, Richtlinien, Ressourcen, Personal, KnowHow, Infrastruktur, Informationen) zu schaffen. Aspekte Ganz wichtig ist, bei Entwicklungsprojekten die verschiedenen Aspekte ganzheitlich im Auge zu behalten. • Technische Aspekte: Technologie, Innovation, Art des Produkts, Produktvielfalt, Stand der Forschung und Technik. • Marktaspekte und Kundenorientierung: Art und Dynamik von Anwendungsbereichen, Märkten und Kunden. • Projektmanagement: Projektart und Einbettung. • Mitarbeiterführung: Führungsstile und Mittel, Ressourcen. Jeweils drei dieser Aspekte können zu einem Würfel (Cube), zwei zu einem Portfolio (Matrix) zusammengestellt werden, wobei Technologie und Markt immer Kernaspekte sind. Einflussfaktoren auf das Management Ein einheitliches Entwicklungsprojekt und ein allgemeingültiges Management dazu gibt es nicht. Vielmehr müssen die allgemeingültigen Grundprinzipien angewandt und je nach Projektart umgesetzt werden. Die wichtigsten Einflussparameter auf das Management von Entwicklungsprojekten beschreibt der folgende Morphologische Kasten.

Tabelle 5-4: Morphologischer Kasten für Entwicklungsprojekte Produkt Auftrag Bedeutung Innovationsgrad Umfang Einbettung Kapazität Kunde

HW SW intern hoch Forschung

System

Dienstleistung Konzept extern durchschnittlich gering Anpassung Verbesse- ModifikaNeuentwicklung rung tion hoch durchschnittlich gering Stab Einfluss Matrix Ausgliederung vorhanden knapp sehr knapp Individuell Massenmarkt

5.5 Management von Entwicklungsprojekten

187

Dynamisches Stufenprinzip Für das Management von Entwicklungsprojekten ist ein stufenweises Vorgehen ein wichtiger Erfolgsfaktor. Meilensteine und Phasenkonzepte haben wir bereits ausgiebig betrachtet. Meilensteine sind dabei wichtige Entscheidungspunkte (Zäsuren, Gates) aus Sicht des Managements. Gerade in Entwicklungsprojekten, wo die Information über Machbarkeit, Schwierigkeiten und Probleme, Chancen und Möglichkeiten im Laufe des Projekts stark anwachsen, sind Meilensteine und Phasenkonzepte zur Strukturierung des Projekts immens wichtig. Das Dynamische Stufenprinzip setzt sich aus Projektphasen und Entscheidungspunkten zusammen. Dabei sollten schon in den frühen Phasen Kriterien festgelegt werden, an welchen Meilensteinen die Entscheidungen getroffen werden, ob ein Projekt fortgeführt bzw. abgebrochen wird. Es soll auch geplant werden, wie ein gezieltes Abbrechen oder Herunterfahren des Projektes auszusehen hat. Durch das Dynamische Stufenprinzip wird es also ermöglicht, Chancen zu nützen und Projektphasen kontrolliert zu beginnen und andererseits durch gezieltes Abbrechen (Optimales Stoppen) Risiken zu reduzieren. Den Unterschied zwischen dynamischen und statischen Entscheidungen veranschaulicht das folgende Beispiel: Dynamische Entscheidungen Sie dürfen mit einem Würfel fünf Mal würfeln und sich jedes Mal entscheiden, ob Sie den Wurf behalten oder nicht. Welche maximale erwartete Augenzahl ist nun durch optimales Stoppen zu erreichen? Wenn Sie von vorneherein festlegen, nach welchen Wurf Sie stoppen, ist die erwartete Augenzahl wie beim einmaligen Würfeln 3,5. Die Wahrscheinlichkeit, eine Augenzahl von 1, 2 oder 3 zu bekommen, ist hier 50%. Die Strategie, jeweils nur eine 6 zu akzeptieren, führt zu einem Erwartungswert von etwa 4,8. Die Wahrscheinlichkeit, eine Augenzahl von 1, 2 oder 3 zu bekommen, ist hier ca. 24%. Die Strategie, alles besser als 3 (4 oder besser) sofort zu akzeptieren, führt zu einem Erwartungswert von etwa 4,9. Die Wahrscheinlichkeit, eine Augenzahl von 1, 2 oder 3 zu bekommen, ist hier aber nur ca. 3%. Durch dynamische Optimierung lässt sich die optimale Entscheidung leicht berechnen: Bei den ersten drei Würfen werden die 5 und die 6 und beim vierten Wurf selbstverständlich auch die 4 akzeptiert. Damit ergibt sich eine erwartete Augenzahl von 5,13. Die Wahrscheinlichkeit, eine Augenzahl von 1, 2 oder 3 zu bekommen, ist dabei ca. 8%. Gegenüber dem einfachen Erwartungswert von 3,5 haben wir immerhin eine Steigerung (Überschuss) von 37%, 40% und im letzen Fall von 47%.

188

5.5.2

5 Management der Entwicklung

Methoden für Entwicklungsprojekte

Im Allgemeinen gelten für Entwicklungsprojekte dieselben ManagementPrinzipien wie in allen Projekten oder sonstigen Management-Aufgaben. Die Einmaligkeit jedes Produkts, die Komplexität und die notwendige Kreativität in der Entwicklung bewirken aber deutliche Unterschiede zu klassischen Planungen. Die Verantwortung des Managements umfasst die Strukturierung, Planung der Planung, Systemvorgaben und Rahmenvorgaben für die Entwicklung. Vorgehensmodelle Vorgehensmodelle als Basis der Projektstrukturierung wurden bereits betrachtet. Eine der wichtigsten Aufgaben des Entwicklungsmanagements ist, einen Konsens über das Vorgehen herbeizuführen und ein strukturiertes Vorgehen nach einem gemeinsamen Grundmodell zu ermöglichen (notfalls auch durchzusetzen). Aufgabe des Managements, ist, ein Modell für das Vorgehen zu spezifizieren und umzusetzen. Dabei muss dies nicht nur die Aussage beinhalten „wir brauchen ein Modell“ oder ein Vorgehensmodell verordnen, sondern das Modell muss gemeinsam entwickelt werden, damit es lebt. Nach dem Motto „Kein Modell ist auch ein Modell“ wird das Projekt beim Fehlen eines Vorgehensmodells durch implizite Annahmen, Tradition, Macht und Chaos beherrscht. Arbeitsstrukturplan und Zeitplan Arbeitstrukturplan und Zeitplan (Netzplan, Gantt-Diagramm) sind wichtige Planungsinstrumente. Da der Arbeitsstrukturplan im Laufe der Zeit verfeinert wird, müssen Vorgaben für die Tiefe und den Gültigkeitsgrad von Arbeitsstrukturplänen und Zeitplänen gemacht werden. Ein Konfigurationsund Änderungsmanagement analog zum technischen ist auch für die Projektpläne notwendig. Das Projektmanagement muss rechtzeitig Konsens über die Art der Strukturierung des Projekts schaffen. Nicht nur der eigentliche Netzplan und Terminplan, sondern auch deren Struktur sind wichtige Erfolgsfaktoren. Die für den Arbeitsstrukturplan zu verwendenden Strukturierungsprinzipien beeinflussen dessen Brauchbarkeit für Planung, Aufgabenverteilung, Zuordnungen von Verantwortung und für das Projektcontrolling. Ihre Festlegung ist deshalb eine wichtige Managemententscheidung. Der Arbeitsstrukturplan kann nach Produktfunktionen (Leitungskategorien des Produkts), Arbeitsfunktionen (Tätigkeitskategorien, ausführende Organisationseinheiten), Phasen oder Teilen gegliedert sein. Weitere Glieder-

5.5 Management von Entwicklungsprojekten

189

ungsmöglichkeiten gibt es nach den Teilen (Modulen, Komponenten, Funktionen) des Produkts. Je nach Prinzip ist die Struktur für Planung, Delegation und Controlling, für Technik oder kaufmännische Aufgaben besser oder schlechter geeignet. Als Grundprinzip kann gelten: Soweit Tätigkeiten einem Teilprodukt (Gerät, Modul, Schnittstelle) sinnvoll zugeordnet werden können, sollten sie dort angesiedelt werden. Arbeiten, die sich gegenseitig ergänzen (substituieren) sollten zusammenfassbar sein. Dadurch werden bei Verschiebungen zwischen Arbeitspaketen die Differenzen auf einer möglichst niederen Ebene abgefangen. Bordradar Arbeitsstrukturpläne Für ein Radar haben wir die Struktur des WBS bereits betrachtet. Als Gliederungsprinzipien für die Software kann man die (kundenorientierten) Funktionalitäten nehmen.

Flugzeug Radar Software Luft-Boden (A2G)

Luft-Luft (A2A) Luftraumanzeige

Kollisionswarnung

Wetter

Geländekarte

Navigation

Landehilfe

Abbildung 5-11: WBS Radar Aufgabenorientiert Aus Sicht der Entwicklung scheint es günstiger, Module mit gleicher interner Funktionalität zusammenzufassen, z.B.: Tracking (Punktverfolgende Verfahren) gegenüber Mapping (abbildende Verfahren). Dies lässt sich sogar teilweise auf die Hardware übertragen. Flugzeug Radar Software Punkte verfolgen (analytisch)

Abbilden (pixelorientiert) Luftraumanzeige

Geländekarte

Wetter

Kollisionswarnung

Navigation

Landehilfe

Abbildung 5-12: WBS Radar SW-funktionsorientiert

Eine wichtige Aufgabe des Projektmanagements ist die Überprüfung des Arbeitsstrukturplans auf Konsistenz und Vollständigkeit. Im Sinne eines Tests sollte stichprobenartig für bestimmte wichtige Ergebnisse (deliverables), Informationen und Entscheidungen die Frage nach dem zugehörigen Arbeitspaket gestellt werden.

190

5 Management der Entwicklung

Im Hinblick auf die Zeitplanung ist die Definition von Phasen und Meilensteinen als Entscheidungszäsuren in der Entwicklung wichtig. Für Meilensteine sind Vorgaben nötig wie: • Wie viele und wie geartete Meilensteine (Review, Phasenübergang, Entscheidungszäsur, externe Schnittstellen) sollen eingesetzt werden? • Wie wird das Bestehen eines Meilensteins definiert und wer entscheidet (Kriterien, Entscheider)? • Wie werden nicht bestandene Meilensteine behandelt (Schleife, Zurückstellung, Puffer)? Aufwandsschätzung Das Problem der Schätzung und der Schätzkorridore (Prognosekorridor) wurde bereits besprochen und wird im Kapitel Modelle auch noch statistisch untermauert. Aus Managementsicht ist hier als erstes die Forderung nach einer Schätzkultur zu stellen. Es gibt keine realistische Schätzung, die immer zutrifft, und insbesondere keine realistische Schätzung, die nie überschritten wird. Bei einer Normalverteilung ist die Wahrscheinlichkeit, dass das Ergebnis über dem Mittelwert liegt, 50%. Wer eine Schätzung will, die nur in 1% der Fälle überschritten werden bekommt den Mittelwert mit einem Zuschlag von mehr als dem doppelten der Standardabweichung. Schätzung und Sicherheit Sie werfen zwei Würfel und multiplizieren die Augenzahl. Das Ergebnis – dessen Verteilung der Aufwandsverteilung bei Projekten nicht unähnlich ist – soll geschätzt werden. Wegen der Unabhängigkeit der Würfe ist der Erwartungswert des Produkts das Quadrat des Erwartungswerts eines Wurfes. Die korrekten Schätzwerte bzw. Grenzen sind, wenn Sie: den Erwartungswert/Mittelwert wollen: 12,25 den Median (50-%-Quantil) wollen: 10 die wahrscheinlichsten Werte wollen 6 und 12 25% Über-/Unterschreitungswahrscheinlichkeit akzeptieren: 5 und 18 Mittelwert +/- Standardabweichung (µ±σ) wollen 3 und 21 10% Über-/Unterschreitungswahrscheinlichkeit akzeptieren: 2 und 25 keine Über-/Unterschreitung akzeptieren: 1 und 36 Mittelwert +/- dreifache Varianz (µ±3σ) wollen -15 und 39

Als Verantwortlicher muss man sich die Frage stellen, welche Schätzung man will und welche Fehler man bereit ist zu akzeptieren. Dies sollte auch kommuniziert werden, denn nur wenn alle Beteiligten am Schätzprozess ein

5.5 Management von Entwicklungsprojekten

191

gemeinsames Verständnis haben, können die Daten vernünftig interpretiert werden. Aufwandsmodelle

Eine wichtige Hilfe bei der Schätzung sind Modelle. Modelle können helfen, basierend auf wirtschaftlichen und technischen Zusammenhängen und aufgrund von Erfahrungen die Aufwände (benötigte Ressourcen) und Kosten sicherer und genauer zu schätzen. Analog kann man auch erzielbare Preise modellbasiert schätzen. Das grundlegende Vorgehen dabei ist, die wichtigsten Einflussfaktoren (Kostentreiber) zu identifizieren und dann die Abhängigkeit der Kosten von diesen Faktoren zu bestimmen. Diese Abgängigkeit der Kosten K von den Parametern x, y, ... wird durch ein Gesetz (Formel) ausgedrückt wie beispielsweise: • Linear: K = C0 + C1 x. Dies ist das klassische Modell mit Fixkosten C0 und variablen Kosten C1 wobei der Kostenparameter (Kostentreiber) x eine Menge (Anzahl) oder Größe (Komponentenzahl, Volumen, Gewicht) aber auch eine Eigenschaft (Qualität, Betriebsparameter, Verbrauch) sein kann. • Multilinear (additiv): K = C0 + C1 x + C2 y ... Dieses Model passt dann, wenn sich die Aufwände addieren, als z.B. wenn die Kostenparameter jeweils die Kosten beispielsweise einer Komponente oder eines Teilprozesses beeinflussen. α β • Additiv: K = C0 + C1 x + C2 y ... Dieses Model passt dann, wenn sich die Aufwände addieren, und die Kostenparameter die Kosten der Komponenten bzw. Teilprozesse nichtlinear beeinflussen. α β • Multiplikativ: K = C x y ... Dieses Modell passt dann, wenn verschiedene Kostenparameter die Kosten des Produkts als Ganzes proportional beeinflussen. α β • Multiplikativ parametrisch: K = C1C2C3 ... x y ... wobei die Konstanten C in Abhängigkeit von bestimmten Attributen des Produkts oder Prozesses gesetzt werden. Beispielsweise ist im SW-Kostenmodell CoCoMo die Kernvariable x die Anzahl der Zeilen Code, der Parameter α und die 20 verschiedenen Parameter C hängen von den Einsatzbedingungen der SW und den Anforderungen der SW-Entwicklung ab. Mit den Methoden der Statistik (bzw. neuronalen Netzen) kann für vorgegebene Daten die Gesetzmäßigkeit hergeleitet werden. Dabei wird man im praktischen Fall der Einfachheit und Stabilität halber mit einem multilinearen Ansatz mit den aus der Erfahrung wichtigsten Parametern starten.

192

5.5.3

5 Management der Entwicklung

Management in den Projektphasen Das Ziel bleibt, die Aufgaben variieren

Die Managementaufgaben orientieren sich an den Entwicklungs- und den darüber hinausgehenden Projektphasen wie Angebotsbearbeitung und Projektabschluss und -auswertung, die wir an anderer Stelle betrachten. Vorbereitung Die frühen Phasen – Projektdefinition, Projektinitiierung und Projektplanung – sind entscheidend für den Projekterfolg. Dazu gehört bei Auftragsprojekten auch die Angebotsbearbeitung. Neben der Ideenfindung und der geistigen Vorwegnahme des Entwicklungsprojekts werden hier durch Festlegung von Ziel, Ressourcen (Budget, Personal) und Terminen die wichtigen Weichen gestellt. Der Manager von Entwicklungsprojekten befindet sich in dieser Phase im Allgemeinen in einer Zwickmühle: Zum einen muss er sein Projekt erfolgreich durchführen und braucht dazu die benötigten Ressourcen und die notwendige Zeit. Er muss also mit Auftraggeber, Projektinitiator, Kunde bzw. Geschäftsleitung verhandeln, um die nötigen Ressourcen und Zeiten zu bekommen und das Projektergebnis im Rahmen des Möglichen festzulegen. Zum andern will er das Projekt aber auch initiieren – um Ideen umzusetzen, Erfolge zu erzielen, Gewinn zu machen oder sein Team auszulasten – d.h. er will den Projektauftrag bekommen, und durch das Interesse am Projekt ist seine Verhandlungsposition geschwächt. Das Projekt muss aber im magischen Projektdreieck so festgelegt werden, dass es wohldefiniert und machbar ist, anderenfalls kann auch durch das beste Projektmanagement das gegebene Ziel nicht mit den gegebenen Ressourcen und Terminen erreicht werden. Dazu gehört insbesondere, dass Anforderungen und Kriterien sauber (exakt, stabil, widerspruchsfrei) beschrieben werden. Spezifikationsphasen Auf dem Weg von der Anforderung zum Entwurf ist es wichtig, die Entscheidungen strukturiert ablaufen zu lassen und für die Konsistenz über die einzelnen Phasen und Dokumente zu sorgen. Bei den Modelltransformationen dürfen Anforderungen nicht verloren gehen. Wichtige Entwurfsentscheidungen und Alternativen sollten mit Risiken (mögliche Fehlschläge, Variation der Performanz, Chancen und Wahrscheinlichkeiten) bewertet werden.

5.5 Management von Entwicklungsprojekten

193

Produktion und Abnahme Die Abnahme ist ein kritischer und juristisch bedeutender Schritt. Bei Entwicklungen, die zu einem einzelnen Produkt, einer Software oder einer Anlage führen und bei Dienstleistungen ist die Abnahme der klar definierte Punkt, an dem der Kunde bestätigt, dass das Entwicklungsergebnis seinen Anforderungen entspricht. Bei Entwicklungen, die in Serienprodukte münden, ist der entscheidende Punkt der Produktionsstart (SOP= Start of Production). 5.5.4

Management des Entwicklungsprozesses Produkte kommen nicht von selbst und selten alleine

Ungeachtet der formalen Definition haben alle Projekte wie bereits betrachtet einen repetitiver Charakter. Dieser Aspekt hilft dabei und macht es lohnenswert, für den Entwicklungsprozess über die Vorgehensmodelle hinaus eine Prozessgestaltung vorzunehmen, die im Qualitätsmanagement- oder Entwicklungshandbuch dokumentiert oder mittels eines Softwaresystems implementiert werden kann. Damit kommt Nutzen der Erfahrung und einer darauf basierenden Standardisierung zum Tragen. Je ähnlicher die Projekte sind, um so lohnender wird eine Standardisierung und eine Implementierung von Strukturen. Die Prozessstrukturen haben einen Managementaspekt (inklusive der organisatorischen und kaufmännischen Vereinheitlichung) und einen technischen Aspekt (z.B. die Wiederverwendung von Modellen und Modulen). Die Implementierung von Prozessen umfasst: • Projektmanagementstrukturen wie Standards für Arbeitsstrukturpläne, Netzpläne, organisatorische Vorgaben und Genehmigungsverfahren, Vorgehensmodelle, Meilensteine und Abbruchkriterien, Budgetierung und Berichtswesen. • Entwicklungsmethoden, Objektmodelle und Analyse-, Spezifikations-, Entwicklungs- und Testrichtlinien. • Richtlinien für Konfigurations- und Dokumentenmanagement, Projektauswertung, Strukturen für Produktlinien und Plattformkonzept. • Prozessgestaltung und Prozessdokumentation. 5.5.5

Angebotsbearbeitung

Das Management der Angebotsbearbeitung entscheidet häufig über den Erfolg eines Entwicklungsprojekts. In dieser Phase sind neben der Entwicklung viele Unternehmensbereiche beteiligt, häufig auch relativ hohe Managementebenen.

194

5 Management der Entwicklung

Ein Problem tritt auf, wenn der zukünftige Projektleiter nicht verantwortlich in diese Phase eingebunden ist. Genau genommen müsste er danach ein eigenes internes Angebot machen, wobei die Differenz an demjenigen hängen bleibt, der den externen Auftrag akquiriert hat. Dies ist ein Problem der Projektabwicklung in der jeweiligen Firma. Wichtig ist, dass das Projekt "Angebotsbearbeitung" als Projekt organisiert ist. Wenn die Produktentwicklung Projektcharakter hat, hat dies das zugehörige Angebot erst recht. In der Angebotsentwicklung müssen die Projektdreiecke aus Entwicklungssicht (was machbar ist), Kundensicht (was gewünscht wird) und Vertriebssicht (wie das Projekt zustande kommen kann) gegeneinander abgeglichen und zu einem gemeinsamen Projekt integriert werden. Angebotsbearbeitung und Kalkulation Basis ist das Verständnis für die Leistungsbeschreibung. Die Vollständigkeit, Klarheit und Widerspruchsfreiheit der Leistungsbeschreibung ist eine Voraussetzung dafür, dass ein sinnvolles Angebot abgegeben werden kann. Unklarheiten im Angebot führen später zu Problemen durch zusätzliche Entwicklungen. Auch die Durchführung von Schätzungen ist ein wichtiger Erfolgsfaktor. Hier ist eine gewisse Schätzkultur für das Unternehmen wichtig. Schätzwerte ohne explizit gemachte Annahmen lassen sich durch Argumente wie Management-Overhead, Dokumentation, Sicherheit, Komfort, Umfang, Wartung, Personal leicht um einen Faktor 2 bis 10 nach oben oder unten korrigieren. Der verantwortliche Manager muss sich hüten, geschönte, zu optimistische oder zu anspruchsvolle Schätzungen zu akzeptieren. Kostenschätzungen müssen technisch vertretbar und realisierbar sein, andernfalls müssten Abweichungen vom Management verantwortet werden. Alle Qualitätsfaktoren wirken sich auf die Kosten aus, da sie Restriktionen an die Entwicklung darstellen. Diese Maßnahmen und Vorhaltungen für die Erreichung von Qualität wirken sich aber kostenmindernd auf spätere Phasen (Abnahme, Wartung, Modifikation) aus und sollten nicht einer kurzfristigen Optimierung zum Opfer fallen. Spezifikationen Im Laufe der Angebots- und Auftragsbearbeitung werden verschiedene Dokumente erstellt, die als Ausschreibung, Pflichtenheft, Anforderungsliste, Lastenheft, Leistungsbeschreibung, Spezifikation, Produktbeschreibung, etc. bezeichnet werden. Die Auswahl der Bezeichnung für und die Verwendung von Dokumenten im Prozess der Angebotserstellung und Auftragsvergabe ist letztendlich auch eine Sache des Kunden und seiner Prozesse.

5.6 Management der Entwicklung im Unternehmen

195

Da diese Begriffe sehr unterschiedlich benutzt werden, muss im Projekt gemeinsam mit dem Kunden (und intern zwischen Vertrieb/Marketing und Entwicklung) festgelegt werden: • wer für die Erstellung und Fortführung (Änderungsmanagement, Genehmigungen, Änderungsdienst, Konfigurationsmanagement) der Dokumente verantwortlich ist, • was die Dokumente enthalten, wie die Inhalte zu beschreiben sind (Modelle, Sprachen) und welche Anforderungen an die Dokumente zu stellen sind (Formalität, Verifikation, Validierbarkeit), • welche rechtliche und finanzielle Bedeutung die Dokumente haben. Wichtig für den Erfolg des Projekts ist auch, die Alternativen mit dem Kunden zu klären, insbesondere die Frage, welche Anforderungen notwendig (muss), entscheidend (soll) oder wünschenswert (kann) sind. Erfolgsfaktoren Alles, was in der Angebotsphase unklar formuliert ist und nicht an operationalisierbaren Kriterien festgemacht wurde, kann später zur Machtfrage werden: Eine häufige Aussage ist dann "Im Prinzip dachten wir damals, wir könnten das so auslegen, dass wir das nicht machen müssen, aber Sie wissen ja, der Kunde sitzt am längeren Hebel", aber genau das hätte man bei Angebotsabgabe auch wissen können. Vor Angebotsabgabe sollte sich das Management über den Kunden, bereits erfolgte Entwicklungen ähnlicher Projekte, ähnliche Entwicklungen und Projekte im eigenen Hause und die Meinungen von Kollegen informieren. Die Anforderungen an Angebote wurden bereits betrachtet. Das Management muss sicherstellen, dass diese Punkte betrachte werden: • Vollständigkeit und Abgrenzung, Kosten und Konditionen, • Kundenmitwirkungen, Schnittstellen und Änderungsverfahren, • Preise und Kriterien für Änderungen und Optionen, • Kaufmännische und juristische Punkte, • Berücksichtigung des wirtschaftlichen und politische Umfelds auf allen Ebenen bei beiden beteiligten Partnern, • technische Machbarkeit und strategische Bedeutung.

5.6 Management der Entwicklung im Unternehmen Entwicklung ist Strategie

Im Folgenden betrachten wir das Entwicklungsmanagement aus Sicht des Unternehmens bzw. der Unternehmensleitung. Dabei geht es um das bereits zu Anfang des Kapitels betrachtete Management, die strategische Ausrich-

196

5 Management der Entwicklung

tung und Positionierung des eigenen Unternehmens und um die Organisation der Entwicklung. Die strategische Frage „wie definieren und positionieren wir uns als Unternehmen?“ muss auch bezüglich der Art der Positionierung betrachtet werden. Wichtige Entscheidungen bezüglich der Frage der Positionierung betreffen: • Problemlösung oder Technologie? • Produkt oder Marktsegment? • Kunden oder Branchen? Je nachdem, wie das Unternehmen seine eigene Rolle sieht, wird auch das Wechselspiel von Strategie, Marketing und Entwicklung gewichtet und ausgeprägt. 5.6.1

Management von Entwicklungsbereichen Die Linie als Heimat für das Personal

Aufgabe des Managements ist die Schaffung und Bereitstellung geeigneter Strukturen, Ressourcen und Instrumente. Dabei ist die Aufgabe der Linie, für den langfristigen Aufbau von Personalkompetenz und Know-How zu sorgen. Projektportfolio Aus Sicht der Entwicklung ist das Projektportfolio wichtig für die Planung der Auslastung, aber insbesondere für die Weiterentwicklung von Produkten und Know-How. Entwicklungsprojekt Machbarkeitsstudie Angebot

Weiterentwicklung Service

Entwicklungsprojekt Machbarkeitsstudie Angebot

Weiterentwicklung Service Entwicklungsprojekt

Momentanes Projektportfolio

Zeit

Abbildung 5-13: Projektportfolio in der Entwicklung Zu jedem Zeitpunkt ergibt sich ein momentanes Produktportfolio mit verschiedenen Projekten. Diese können nach Kriterien wie Größe (Personalein-

5.6 Management der Entwicklung im Unternehmen

197

satz, Ressourcen, erwarteter Umsatz), Terminen (Dauer, Laufzeit), Grad der Innovativität (Forschung, Neuentwicklung, Anpassung, Modifikation, Weiterentwicklung), strategischer Bedeutung für das Unternehmen und die Entwicklungsabteilung (Know-How-Gewinn, Folgeprojekte), Markt (Attraktivität, Wachstum, eigene Position) oder nach dem Inhalt des Entwicklungsprojekts (Art des Produkts, Haupttechnologie, Markt) klassifiziert werden. So entsteht eine Portfolio-Matrix, die einen schnellen Überblick über die Entwicklungsprojekte erlaubt. Welche Parameter als Basis des (oder der) Portfolios genommen werden, hängt vom Zweck und vom jeweiligen Unternehmen ab. Das Portfolio im folgenden Beispiel erlaubt es, die Balance zwischen Know-How-Zuwachs in der Entwicklung (technologische Nachhaltigkeit) und dem erwarteten Gewinn aus den entwickelten Produkten (finanzielle Nachhaltigkeit) zu halten sowie unattraktive Projekte, die Kapazität binden, zu erkennen und zu gegebenenfalls zu eliminieren. Know-How-Gewinn

Größe der Kreise gibt den Projektumfang an

Monetärer Gewinn

Abbildung 5-14: Projektportfolio (Beispiel) 5.6.2

Managementstrukturen

Das wichtigste an einem Entwicklungsmanagementsystem ist, Strukturen zu entwickeln und Verantwortlichkeiten festzulegen: diese sollen nicht als Betonmauern, sondern als Landkarte gesehen werden. Doppelarbeit und Lücken in der Verantwortung treten gerne genau an den für die Entwicklung zentralen Punkten auf: Kundennutzen und Systemkonzept. Wichtig sind dabei folgende Prinzipien: • strategisch und zukunftorientiert: welche Probleme, Lösungen, Produkte, Systeme, Technologien und Prozesse werden in Zukunft wichtig sein? • operativ und marktorientiert: wie schaffen wir es, unseren Kunden schnell, günstig und hochwertig Problemlösungen anzubieten?

198

5 Management der Entwicklung

Für die Strukturierung der Entwicklung bzw. des Unternehmens stehen verschiedene Möglichkeiten zur Auswahl: • fachlich/technisch orientiert (Kompetenzen, Know-How, Aktivitäten), • kunden-/marktorientiert (Branchen, Bereiche, Key Accounts), • produkt- bzw. produktlinienorientiert. 5.6.3

Qualität

Qualität entsteht nicht durch das einzelne Projekt sondern durch einen ganzheitlichen Ansatz in der Linie. Qualitätsmanagement ist eine Selbstverpflichtung des Managements gegenüber Kunden und Mitarbeitern. Qualität und Excellence Qualität muss von der obersten Leitung gewollt und gelebt werden. Dabei ist Qualität das, was vom Unternehmen versprochen wird. Durch die Qualitätspolitik legt das Unternehmen auch fest, worauf es Wert legt. Gleichzeitig „die Besten und Umsatzstärksten, die Schnellsten und Flexibelsten, die Innovativsten und Verlässlichsten, die Zuverlässigsten und Billigsten, die Arbeitnehmerfreundlichsten und Verantwortlichsten, die Ertragsstärksten und Beliebtesten“ zu sein, geht einfach nicht. Priorisierung ist ein wichtiger Erfolgsfaktor. Wer als Unternehmensleitung die Qualität dem Kosten- oder Zeitdruck des Kunden opfert, kann nicht später die Mitarbeiter für schlechte Qualität verantwortlich machen. Der Spruch „Qualitätsmanagement ist Schutz der Qualität vor dem Management“ hat eine wichtige Komponente: Mitarbeiter wollen mit ihrer Tätigkeit zufrieden und auf das Ergebnis stolz sein (man kann dies durch aus als „Spaß an der Arbeit“ im positiven Sinne sehen). Sie wollen also gute Ergebnisse erzielen. Dies muss durch die vorgesetzten Ebenen und unterstützenden Prozesse gefördert werden. Qualitätsfördernde Faktoren (Prozesse, Ressourcen, Ausbildung) dürfen nicht zugunsten firmenexterner Prioritäten wie Kundenwunsch (Termin, Änderungen) und firmeninterner projektexterner Ziele (Kostendruck, Personalknappheit) vernachlässigt werden. Vom Projekt zum Prozess Entwicklung soll nicht jedes Mal ein „ab-initio“-Projekt sein, das bei Null anfängt. Der Erfolg des Unternehmens beruht ja darauf, dass man mit ähnlichen Projekten Erfahrung hat. Ein erster Beitrag dazu sind die im Kapitel „Management sich wiederholender Projekte“ betrachteten Methoden. Deshalb ist es wichtig, den Produktentstehungsprozess zu strukturieren. Den Kern des Qualitätsmanagementsystems macht die Gestaltung der Prozesse aus. Im Bereich Entwicklung sind Vorgehensmodelle und Phasenkon-

5.6 Management der Entwicklung im Unternehmen

199

zepte ein wichtiger Ausgangspunkt. Sie beschreiben auch die anzuwendenden Regeln für Prozesse und Dokumente. Die Strukturierung des Entwicklungsprozesses selbst haben wir bereits beschrieben. Aufgabe des Managements ist es, dies Strukturen zu implementieren: beschreiben, umsetzen, leben. Wichtig ist auch die Festlegung von Strukturen, Phasen, Meilensteinen, Dokumentationsrichtlinien und eine klare Kommunikation d. Dazu gehören Begriffe und die Sicherstellung der einheitlichen Verwendung. 5.6.4 Ressourcenzuordnung und Priorisierung

Eine der wichtigsten Managementaufgaben ist für eine Priorisierung der anstehenden Aufgaben und der Verteilung von Ressourcen zu sorgen. Dabei steht nicht die operative Zuordnung von Mitteln (Budget) und Priorisierung im Mittelpunkt, sondern die Schaffung von Systemen und Prinzipien zur Entscheidung dieser Fragen. Projektauswahl Die Auswahl der zu bearbeitenden Aufträge oder internen Projekte darf nicht nach dem „Windhundprinzip“ erfolgen. Wenn keine langfristige Planung möglich ist, muss ein Puffer geschaffen werden, damit kurzfristig auftauchende Chancen genutzt werden können. Zumindest die Bearbeitung von Angeboten muss möglich sein, um sich nicht wichtige Chancen entgehen zu lassen. Da Projektportfolio ist ein Hilfsmittel, um die Auswahl der aufzunehmenden Projekte zu planen. Shareholder Value und Return on Investment Eine Methode für die Auswahl der Projekte liegt in ihrer Rendite, die Kennzahl dafür ist die Rendite, Return on Investment (ROI). Der Zusammenhang mit dem Shareholder Value sei kurz exemplarisch skizziert: Ein Anteilseigener (shareholder, z.B. Aktionär) gibt der Firma Geld und erwartet dafür eine Rendite, d. h. einen Mehrwert oder Gewinn für sein eingesetztes Kapital. Unabhängig davon, ob dieser Gewinn (z.B. Dividende) ausgeschüttet wird oder zur Wertsteigerung (Kursteigerung) des Unternehmens beiträgt, der erwartete Gewinn muss die erwartete Rendite erwirtschaften. Damit kann ein Projekt nur gestartet werden, wenn das Projektergebnis mindestens die vorgegebene Rendite erwirtschaftet. Der Renditefaktor (Return on Investment) ist dabei diejenige Zinsfaktor, mit dem man die Investitionen und Auszahlungen des Projekt verzinsen müsste, um am Schluss eine ausgeglichene Zahlungsbilanz zu haben.

200

5 Management der Entwicklung

Je nach dem Verhältnis von Eigenkapital (für das Rendite erwirtschaftet werden muss) und Fremdkapital (für das Zinsen gezahlt werden müssen) und den für diese beiden Arten von Kapital zu erwartenden Zinsen bestimmt sich der notwendige Renditefaktor für Projekte. Beurteilung eines Projekts nach dem ROI In der Firma sei je hälftig Eigenkapital, für das die Shareholder eine Verzinsung von 12% erwarten und Fremdkapital, für das 8% zu zahlen sind. Ein Projekt habe eine Erfolgswahrscheinlichkeit von 80% und erfordere jeweils 1 Mio. € in den Jahren 1, 2, 3 und 4, der Rückfluss sei im Jahr 5. Wie viel sollte das Projekt versprechen? Die Verzinsung muss 10% sein, also muss der erwartete Rückfluss 1,1+1,1²+1,1³ +1,14 = 5,1 Mio. € betragen. Wegen des Risikos von 20% sollte der im positiven Fall zu erwartende Rückfluss also 5,1/0,8 = 6,4 Mio. € betragen.

Das Beispiel zeigt auch, dass Risiko und Zeitpunkt des Ertrags in die Berechnung eingehen müssen. Die Gefahr bei solchen Kriterien ist, dass dadurch nur Massenprojekte ausgewählt werden, die keinen Wissenszuwachs in das Unternehmen bringen und keine zukunftsträchtigen Technologien oder Märkte erschließen. Damit findet eine zu starke Konzentratration („Festfressen“) auf kurzfristig gewinnbringende Projekte und Produkte statt, und es werden strategisch wichtige Entwicklungen vernachlässigt. Diese Strategie einer kurzfristigen Optimierung ist für das Unternehmen nicht nachhaltig. 5.6.5 Schnittstellen

Das Management ist dafür zuständig, dass die Schnittsellen zwischen den einzelnen Bereichen funktionieren. Dabei ist das Gesamtmanagement in der Verantwortung, durch die Organisation die Voraussetzungen zu schaffen, während die Verantwortlichen für die Entwicklung die Kommunikation, Aufgabenverteilung und Verantwortung zwischen den kooperierenden Bereichen umsetzen müssen. Im Folgenden betrachten wir die wichtigsten Funktionsbereiche und ihre Schnittstellen. Forschung Die Kooperation zwischen Forschung und Entwicklung wird durch eine zweiseitige Beziehung gekennzeichnet: • pull: Die Entwicklung benötigt Erkenntnisse, die von der Forschung geschaffen werden. • push: die von der Forschung gefundenen Erkenntnisse werden in der Entwicklung umgesetzt.

5.6 Management der Entwicklung im Unternehmen

201

Ein wichtiger Punkt im Entwicklungsmanagement ist die Frage, wie die Forschung eingebunden ist. Hier geht es nicht nur um die oben betrachteten Schnittstellen, sondern um die organisatorische Einbindung von Produktentwicklung, strategischer Entwicklung, angewandter Forschung und Grundlagenforschung. Für das Unternehmen ist es wichtig, alle Bereiche abzudecken. Ob eine Grundlagen- oder angewandte Forschung notwendig ist, oder ob die Verfolgung aktueller Entwicklungen durch Publikationen, Tagungen und Seminare ausreicht, hängt vom Unternehmen, seiner Technologie und der Forschung in den relevanten Bereichen ab. Zentrale Forschungsabteilungen bündeln die Kompetenz und sind für kleinere Unternehmen die einzige Möglichkeit, eine Abteilung mit forschungsrelevanten Aufgaben zu installieren. Sie bergen aber die Gefahr einer Trennung und Entfremdung von den Entwicklungsabteilungen. Von der Seite des Managements ist die Bewertung und Ressourcenausstattung der Forschung ein wichtiges und häufig strittiges Thema. Dabei kann eine entwicklungsorientierte Forschung als Profit Center laufen, was aber die Gefahr der Konzentration auf kurzfristig gewinnbringende Aufgaben und die Vernachlässigung strategischer Konzepte mit sich bringt. Den Erfolg von grundlagenorientierter Forschung kann man an Publikationen oder Patenten festmachen, was aber nicht zum Erfolg des Unternehmens beiträgt. Hier muss das Management für die Forschungsbereiche einen Kompromiss zwischen den beiden Gefahren „Publish or perish“ bzw. „Patente um jeden Preis“ einerseits und der Rolle als Handlanger von Entwicklung und Produktion andererseits finden. Die Erfahrungen und Rückkopplungen aus Entwicklungsprojekten sind für die Forschung wichtig. Marketing und Vertrieb Je nach Art von Produkt, Kunde und Auftrag sind Marketing und Vertrieb in die Produktentwicklung in den Phasen Vorbereitung, eigentliche Entwicklung, Markteinführung und Pflege eingebunden. Die verschiedenen Arten der Einbindung wurden bereits betrachtet. Produktion In der Produktion werden die Entwicklungsergebnisse in Produkte umgesetzt. Dies kann eine klassische Fertigung bei physischen Produkten (siehe auch das folgende Kapitel) sein, bei Software und Dienstleistungen ist die Leistungserbringung analog zu betrachten.

202

5 Management der Entwicklung

Der entscheidende Meilenstein in der Kooperation zwischen Entwicklung und Produktion ist der Beginn der Fertigung (SOP; Start of Produktion). Hauptaufgaben mit Entwicklungsrelevanz sind: • Bis zum SOP: Änderungswesen, Freigaben, Werkzeugbau, Testgeräte, • Ab dem SOP: Produktionsunterstützung, Änderungswesen. Beschaffung und Logistik Die Materialwirtschaft stellt die für die Erbringung der Leistung (Produkt, Dienstleistung) erforderlichen Materialien zur Verfügung und ist damit in der Leistungserbringungsphase in ähnlicher Weise vom Entwicklungsergebnis betroffen wie die Produktion. Materialkosten

Die Entwicklung stellt die Weichen für die Beschaffungskosten beim Endprodukt. Kriterien der Beschaffung an Teile können sein • günstige Teile (geringer Preis), • einfache Teile (geringe Komplexität, Sicherheit), • Mehrfachteile (Katalogteile, Standards), • Mengeneffekte (Vorteile durch Einheitlichkeit). Ein wichtiger, auch von der Entwicklung zu beachtender Punkt ist der Hebeleffekt der Beschaffungskosten: Je geringer die Fertigungstiefe bzw. die eigene Wertschöpfung ist, um so wichtiger werden die Kosten von extern beschafften Rohstoffen, Halbfertigteilen und Dienstleistungen. Beschaffung für die Entwicklung

Ein anderes Thema ist die Beschaffung von Material, das in der Entwicklung benötigt wird. Schnelligkeit und Flexibilität sind hier gefordert. Beschaffungsrichtlinien, die für Serienprodukte aufgrund der hohen Stückzahlen sinnvoll sind, können bei Entwicklungsprojekten ins Gegenteil umschlagen: nicht die Kostenersparnis, sondern Schnelligkeit, Zuverlässigkeit und Flexibilität zählen. 5.6.6

Der optimale Entwicklungsmanager Die Vision des Entwicklungsmanagers

Einen optimalen Manager für Entwicklungsprojekte und Entwicklungsbereiche gibt es nicht, da dafür die Aufgaben, Randbedingungen und Teams viel zu verschieden sind. Eigenschaften Ein Entwicklungsprojektmanager braucht einige Eigenschaften, die der Linienmanager nicht in dem Umfang braucht. Sie ergeben sich aus dem Span-

5.6 Management der Entwicklung im Unternehmen

203

nungsfeld von Projekt und Prozess sowie von Technik und Wirtschaftlichkeit. Eine rein administratives Verständnis von Management ist hier fehl am Platze. Wichtig für jeden Projektmanager ist, sich auf keine feste Rolle und Technik zu fixieren, sondern situationsangepasst aber berechenbar zu agieren und diejenige Methode wählen, die der momentanen Situation hinsichtlich Projekt, Kunde und Mitarbeitern am besten angemessen ist, nicht diejenige, die gerade am bequemsten ist. Diese Rollenwechsel werden von außen oder durch die Mitarbeiter initiiert. Auch wenn Sie ihrem Team kooperatives Arbeiten gestattet haben, tragen Sie immer die Verantwortung dafür. Rollen und Führung Mögliche Rollen des Entwicklungsmanagers sind: • Chef: der Leiter eines Teams, der als Externer die Entscheidungen trifft, • Teamchef: der Leiter eines Teams, der als Teammitglied die Entscheidungen trifft, • Trainer oder Coach: fördert die Weiterentwicklung seiner Mitarbeiter, • Moderator: gestaltet den Prozess, • Controller: überwacht den Prozess, • Chief Developer: der leitende Entwickler. Diese Rolle ist gefährlich, wenn der Projektleiter sich darauf konzentriert, der „beste“ oder „fitteste“ Entwickler im Team zu sein. Aufgabe des Entwicklungsmanagers ist es nicht, mehr Fachkompetenz als seine Teammitglieder zu haben, sondern die Fachkompetenz seiner Teammitglieder zu fördern und optimal einzusetzen und für den Projekterfolg zu nutzen. Egal welche Rolle Sie ausfüllen (hoffentlich nicht spielen); die Verantwortung tragen Sie selbst. Immer. Nicht Leistungen fordern, die man selbst nicht bereit ist zu bringen (Kants kategorischer Imperativ). Wer mit einem kooperativen Stil nicht leben kann, soll entsprechend führen. Ein pseudo-kooperativer Stil „Solange ihr das entscheidet, was ich will, machen wir das, was ihr entscheidet“ ist nur feige. Das gilt für alle Ebenen, für Individuen, Teams, und auch für untergeordnete Manager. Lassen Sie auch nicht zu, dass untergeordnete Manager Verantwortung „rückdelegieren“. Entwicklung Wie entwickelt sich ein optimaler Entwicklungsmanager? Der Ausgangspunkt, also woher der Entwicklungsmanager kommt, spielt eine wichtige Rolle, da sie das Selbstverständnis und die Sicht auf den Entwicklungsprozess prägt:

204

5 Management der Entwicklung

• Technik: der Entwicklungsmanager, der die Fachkompetenz für das Pro-

dukt mitbringt (sofern das bei der Komplexität der Produkte möglich ist), hat einen Vorteil, was die Beurteilung von Entwicklungsschritten und Ergebnissen betrifft. • Management: Führung und Zielsetzung sind entscheidend für eine effiziente Entwicklung. Projektmanagement ist für das Management von Entwicklungsprojekten ein wichtiger Erfolgsfaktor. • Betriebswirtschaft: Die betriebswirtschaftlichen Kenntnisse sind ein guter Ausgangspunkt, um die Entwicklung erfolgsorientiert zu planen. • Forschung: In hochtechnologischen Bereichen ist die Einsicht in die Grundlagen und die Fähigkeit zur Forschung ein wichtiger Erfolgsfaktor für die Entwicklung. • Marketing, Vertrieb: Um auf dem Markt erfolgreiche Produkte zu entwickeln, ist die Sicht des Kunden wichtig. Alle Komponenten sind wichtig, ihre Bedeutung variiert gemäß den Einflussparametern der Entwicklungsprojekte. Wichtig sind Selbstmanagement, Interesse und die Bereitschaft zu lebenslangem Lernen (lifelong learning).

6

Entwicklung in speziellen Produktbereichen Es gibt viele Arten von Produkten

Ungeachtet der bis jetzt herausgestellten gemeinsamen Grundprinzipien gibt es bei der Entwicklung von Produkten durchaus spezifische Aspekte. In diesem Kapitel betrachten wir die Entwicklung bezogen auf spezielle Produktbereiche. Wir spannen dabei den Bogen von den materiellen Produkten über Software zu Dienstleistungen und zu Produkten, die nicht genau in den klassischen Rahmen passen. Dabei hat ein Produkt im Allgemeinen Beziehungen zu verschiedenen Produktkategorien. Es geht dabei nicht darum, das Produkt und seine Entwicklung in eine bestimmte Schublade zu stecken, sondern gerade darum, durch Beleuchten der verschiedenen Aspekte ein optimales Entwicklungsmanagement zu ermöglichen. Tabelle 6-1: Produktkategorien Gruppe nach ISO 9001 Verfahrenstechnische Produkte Hardware Software

Kategorien Physische Produkte Intelligente Systeme Software Systeme und Konzepte Allgemeine Dienstleistungen

Dienstleistungen

Veranstaltungen und Tourismus Dokumente und Kunst Modelle

Ungeachtet der Zwischenkategorien kann dadurch ein Produkt grob klassifiziert werden, inwieweit welche Aspekte des Produkts und damit der Entwicklung eine Rolle spielen. Da bei den meisten Produkten Hardware, Software, Dienstleitung und Erlebnisaspekte eine Rolle spielen, lassen sie sich in einem Spinnendiagramm entsprechend charakterisieren.

206

6 Entwicklung in speziellen Produktbereichen

Hardware

Software/Modell

Dokumentation

Dienstleistung

Erlebnis

Abbildung 6-1: Verschiedene Schwerpunkte in Produkten

6.1 Physische Produkte Produkte, die man anfassen kann

Physische oder materielle Produkte sind all diejenigen Produkte, bei denen das materielle Objekt die Hauptsache ist. Zwar brauchen immaterielle Produkte auch einen Träger, das essentielle ist aber dort nicht die materielle Realisierung. Natürlich gibt es einen fließenden Übergang: an einem Wörterbuch ist vor allem die Information wichtig, das Produkt ist aber die physische Realisierung auf Papier oder in elektronischer Form (CD, elektronisches Gerät). Der Begriff Hardware meint in seiner ursprünglichen Bedeutung und auch in der Norm ISO 9001 mehr als das, was man im Deutschen im Allgemeinen darunter versteht, nämlich nur Computer-Hardware im Gegensatz zur Software. Er bezeichnet alle physischen (materiellen) individuell identifizierbaren Produkte, von der Schraube bis zum Containerschiff. Parallel dazu bezeichnet der Begriff „verfahrenstechnische Produkte“ all das, was nicht gezählt, sondern als Menge produziert und genutzt wird. Von Aalreuse bis Zytostatika Die Spanne von der Aalreuse zu den Zytostatika zeigt nicht nur die Breite materieller Produkte von der einfachen mechanischen Konstruktion bis zu komplexen biochemischen Wachstumshemmern für die Krebsbehandlung. Sie zeigt auch einen Zeitunterschied: während Fischreusen bereits in der Steinzeit gebaut wurden, ist die Entwicklung von Zytostatika ein junges Feld.

6.1 Physische Produkte

207

Physische Produkte und ihre Entwicklung werden hier relativ knapp abgehandelt, da diese Art von Entwicklung die historische Basis methodischen Entwickelns darstellt und die Entwicklungsmethodik großteils auf derjenigen für mechanische Produkte aufbaut. Daher sind die vorangegangenen Kapitel im Vorgehen und in den Modellen stark an den anschaulichen und greifbaren physischen Produkten orientiert. 6.1.1

Hardware

Eine wichtige Rolle bei der Entwicklung physischer Produkte spielt die Konstruktion. Hardware-Entwicklung ist die klassische Entwicklung und hat den gesamten Bereich der Ingenieurwesens und des Entwicklungsmanagements geprägt. Deshalb kommen viele Prinzipien und Begriffe im Entwicklungsmanagement aus der Entwicklung mechanischer Produkte, und auch die Literatur hierzu ist umfangreich. Computer-Hardware Der englische Begriff hardware bezeichnet eigentlich Eisenwaren. Im Computer bezeichnet Hardware im Gegensatz zur Software die physischen Teile des Computers. Diese Grenze ist aber auch variabel, da ja auch die Teile (z.B. Mikroprozessoren) eine eigene Software (Mikroprogrammierung) haben. Je nach Fortschritt der Technologie und Systemanforderungen können • Aufgaben, die in Software implementiert wurden, in die Hardware übernommen werden („Silizium-Implementierung“) und effizienter ausgeführt werden (Arithmetik, Signalverarbeitung, Controllerfunktionen), • Hardwarelösungen durch Mikroprogrammierung flexibler gemacht werden. Damit kann derselbe Chip verschiedene Funktionen übernehmen und je nach Aufgabenbereich können problemangepasste Programmiersprachen eingesetzt werden.

Die Vielfalt der physischen Produkte lässt sich zunächst durch die grobe Charakterisierung nach der Nutzung darstellen: • Investitionsgüter werden zur längerfristigen Nutzung beschafft. Im industriellen Umfeld werden sie direkt oder indirekt zur Produktion anderer Güter oder zur Erbringung von Dienstleistungen eingesetzt (z.B. Maschinen). • Konsumgüter sind zur direkten Nutzung (Konsum) vorgesehen. Daneben gibt es weitere Kategorisierungen: Nach der Menge an hergestellten Gütern unterscheiden wir Einzelprodukte und Massenprodukte. Massenprodukte werden in einem industriellen Fertigungsprozess (Serienproduktion) hergestellt.

208

6 Entwicklung in speziellen Produktbereichen

Von der Art des Verbrauchs können wir Mengen- und Einzelverbrauchsgüter den Nichtverbrauchsgütern gegenüberstellen. Nichtverbrauchsgüter sind Investitionen, die für einen längeren Zeitraum angeschafft werden (beispielsweise die Investitionsgüter). Auch Investitions- bzw. Nichtverbrauchsgüter können als Massenprodukte hergestellt sein, wichtig ist die Einschätzung durch den Kunden. Maschine Der Begriff der Maschine wird z.B. in der EU-Maschinenrichtlinie folgendermaßen festgelegt (wobei der Gültigkeitsbereich der Richtlinie Ergänzungen und Einschränkungen hat): ... eine Gesamtheit von miteinander verbundenen Teilen oder Vorrichtungen, von denen mindestens eines beweglich ist, sowie gegebenenfalls von Betätigungsgeräten, Steuer- und Energiekreisen usw., die für eine bestimmte Anwendung, wie die Verarbeitung, die Behandlung, die Fortbewegung und die Aufbereitung eines Werkstoffes zusammengefügt sind.

Maschinen können sowohl Investitionsgüter (z.B. Produktionsanlagen) als auch Konsumgüter (Gebrauchsgeräte) sein. 6.1.2

Systems Engineering

Systems Engineering oder Systemtechnik ist das ingenieurmäßige Vorgehen bei der Entwicklung und Verbesserung komplexer Systeme. Dabei baut das Systems Engineering auf zwei Grundlagen auf: • einem systematischen Prozess der Entwicklung, gekennzeichnet durch Phasen mit zugehörigen Entscheidungen und Dokumenten (Vorgehensmodell), • dem systemtheoretischen Ansatz, das zu entwickelnde Produkt als System zu betrachten, seine Einbettung in übergeordnete Systeme zu berücksichtigen, und beides entsprechend zu modellieren und so einer mathematischen Analyse zugänglich zu machen. Ein ganzheitlicher Ansatz berücksichtigt auch Nutzer, Personal, Einbettung, Lebenszykluskosten, Alternativen, Rückwirkungen und Folgeeffekte. Intelligente Heckleuchte Für jeden neuen Fahrzeigtyp werden die Heckleuchten (Signalleuchten) entwickelt. Der Rahmen für die Entwicklung von Heckleuchten ist vorgegeben durch • die gesetzlich vorgeschriebenen lichttechnischen Anforderungen, • die Kundenanforderungen bezüglich Mechanik und Styling, • den Stand der Technik und das Know-how des Herstellers.

6.1 Physische Produkte

209

Auf der Grundlage der Daten des Fahrzeugs wird ein Konzept modelliert und simuliert. Parallel zur Konkretisierung erfolgt die Überprüfung der möglichen Fertigungstechnologie, eventuell von Prototypen. Bei konventionellen Glühlampen ist eine Zeit von ca. 200 ms notwendig, um die Glühwendel so weit zu erwärmen, dass sie Licht mit der geforderten Helligkeit aussendet. LEDs (Licht emittierende Dioden) benötigen keine Aufwärmphase. Durch die Verwendung von LEDs lässt sich also bei einer Geschwindigkeit von 180 km/h der Bremsweg um 10 m verkürzen. Die Entwicklung einer intelligenten Bremsleuchte geht noch weiter: durch Sensoren kann festgestellt werden, ob eine Vollbremsung droht (Sensoren, Situationsbeurteilung), ob der Fahrer eine Vollbremsung vorhat (schlagartig Fuß vom Gas nehmen) oder ob das Fahrzeug plötzlich abgebremst wird (Sensoren direkt in der Leuchte), bevor das Bremspedal betätigt wird. Dadurch lässt sich die Vorwarnzeit weiter steigern. Dies erfordert nun aber eine simultane Entwicklung von Heckleuchte, Sensorik und intelligenten Systemen.

Bei elektrischen oder elektronischen Produkten wird eine parallele aber integrierte Entwicklung der einzelnen Komponenten notwendig. Je nach der Bedeutung von Elektronik bzw. Mechanik für den Kundennutzen liegt dabei der Fokus bei der Elektronik (mit paralleler Gehäuseentwicklung) oder Mechanik (mit paralleler Entwicklung von elektrischen Teilen). GPS GPS soll hier als Beispiel für die Elektronik betrachtet werden. Das Global Positioning System braucht nicht nur den Empfänger, sondern eine immense Infrastruktur. Der größte Teil des Aufwandes steckt in den Satelliten und in deren Synchronisation. Der GPS-Empfänger muss nur noch die Signale von vier Satelliten empfangen und die Zeitdifferenzen auswerten. Der Rest ist eine einfache trigonometrische Rechnung. Die Funktionalität ist durch das System vorgegeben. Für das Gesamtprodukt sind die mechanischen (Gehäuse, Bedienung) und elektrischen (Energieversorgung, Anzeige) Teile vor allem bezüglich des Kundennutzens wichtig.

6.1.3

Entwicklung

Für die Entwicklung von individuellen physischen Produkten ist der Prozess des Entwurfs und der Konstruktion der mechanischen Teile zentral. Für elektr(on)ische Produkte sind daneben auch Layout-Prozesse zu betrachten.

210

6 Entwicklung in speziellen Produktbereichen

Entwurf und Konstruktion Systematisches Entwerfen hat bei mechanischen Produkten wohl die längste Tradition. Wichtig beim Entwurf ist die Erfassung der Anforderungen und deren Umsetzung. Dabei werden neben den Wirkprinzipien der Mechanik auch andere Bereiche der Physik herangezogen und hydraulische, pneumatische, elektrische, magnetische, optische, akustische und thermische Wirkungen genutzt. Entwurf einer Uhr Das Grundprinzip einer Uhr ist ein nach einem systematischen Gesetz (idealerweise linear) ablaufender und lang anhaltender Vorgang (die lange Dauer kann auch durch Periodizität, d.h. regelmäßige Wiederholung ersetzt werden). Nur so kann die Uhr mit vernünftigem Aufwand kalibriert und genutzt werden. So wird beispielsweise eine Sanduhr so geformt, dass durch das Fliessen des Sandes eine konstante Veränderung der Höhe eintritt, damit ist während eines Durchlaufs die Zeit gut messbar. Die Wiederholung des Prozesses erlaubt das Messen längerer Zeitintervalle. Bei der Pendeluhr, Armbanduhr und Quarzuhr dient ein periodischer Vorgang (Schwingung) als Basis der Zeitmessung. Er ist so kurz, dass nur seine Vielfachen betrachtet werden müssen. Die „Funkuhr“ ist nur ein Empfänger für eine zentrale Uhr. Die zweite wichtige Komponente ist die Benutzerschnittstelle und die zur Verfügung gestellten Funktionen (Anzeige, Stellen, Alarm, Schaltfunktion, ...).

Methodisches Entwerfen und Konstruieren ist ein wichtiger Schritt im Produktenstehungsprozess bei mechanischen Produkten. Der Entwurfsprozess kann hier stark systematisiert werden, da die physikalischen und kausalen Zusammenhänge zwischen Komponenten logisch und klar sind. Wichtige Schritte sind die Suche nach Lösungsansätzen anhand von Wirkprinzipien, Lösungsprinzipien und Ordnungsprinzipien. Hier sei auf die Fachliteratur (siehe z.B. [Ehrenspiel]) verwiesen. Im Bereich Elektronik steht zwischen dem Entwurf und der physischen Implementierung das Layout z.B. vom Leiterplatten oder Chips. Design Design bedeutet in der Übersetzung einfach den Entwurf bzw. Entwurfsprozess, hat aber auch eine spezielle Bedeutung, nämlich die bewusste Gestaltung eines Objekts, vor allem bezüglich Form und Farbe. Dieser Begriff von Design spielt vor allem bei materiellen Produkten eine Rolle. Im Deutschen wird der Begriff Design häufig für künstlerische Aspekte benutzt. Das Design kann auch Informationen transportieren, und eine Warn-

6.1 Physische Produkte

211

funktion oder Werbungsfunktion (emotionale Ansprache) haben. Bei physischen Produkten kann das Design verschiedene Aspekte betreffen: • optisch: Das optische Erscheinungsbild ist im Allgemeinen das wichtigste. Vor allem die optische Wahrnehmung der Form (Design im engeren Sinne), die Farbe und Oberfläche (matt, Glanz) spielen für die Wahrnehmung durch das Auge eine wichtige Rolle. Industriedesign spielt bei Maschinen ebenso eine Rolle wie bei Konsumgütern. Meist wird Design – vor allem auch deshalb, weil es photographiert und als Druck oder in elektronischer Form abgebildet werden kann – auf die optische Komponente bzw. die Form reduziert. • akustisch: Der Klang bzw. das Geräusch unterstützt beim Betrieb und bei der Bewegung des Produkts die Wahrnehmung und er spielt bei der Bedienung insbesondere als Rückmeldung von Handhabung und als Warnsignal eine Rolle. Beispiele für akustisches Design sind der Klick der Kamera oder des Drehmomentschlüssels oder das Motoren-/Auspuffgeräusch eines Autos. • haptisch: Die Wahrnehmung durch Körperkontakt, vor allem durch die Hand, spielt bei Maschinen und Geräten eine wichtige Rolle. Alle Arten von Griffen werden entsprechend gestaltet, um den Benutzer zu unterstützen. Das haptische Design ist eine wichtige Komponente der Ergonomie. • olfaktorisch: Die Wahrnehmung von Gerüchen ist meist unbewusst. Dies kann aber nicht nur bei Nahrungsmitteln, sondern z.B. auch bei Autos (Innenraum) eine wichtige Rolle spielen. Für das Thema Design im Produktentstehungsprozess sei z.B. auf [Reese] verwiesen. 6.1.4

Prototyping und Produktion

Physische Produkte werden produziert. Dabei unterscheiden wir im Allgemeinen zwischen der Produktion oder Fertigung (Urformen, Umformen) der Teile und der Montage, in der die gefertigten Teile zusammengefügt werden. Randbedingungen müssen bei der Entwicklung beachtet und rechtzeitig geplant und realisiert werden. • Planung der Fertigungs- und Montageschritte, Entwicklung und Bau der Maschinen und Werkzeuge, • Planung und Beschaffung von Rohstoffen, Einkauf, Materialwirtschaft, Bedarfsplanung. Die Randbedingungen unterscheiden sich nach der Zahl und Vielfalt der zu fertigenden Güter (Einzelfertigung, Serienfertigung, Massenfertigung). Da-

212

6 Entwicklung in speziellen Produktbereichen

bei gibt es bei Produkten, die in höherer Stückzahl gefertigt werden, verschiedene Stufen auf dem Weg vom Entwicklungsergebnis zur Fertigung des Endprodukts: • Prototypen, die meist mit anderen als den für die Serienproduktion vorgesehenen Verfahren gefertigt werden. • Produktionsvorbereitung und Nullserie mit den für die Serienproduktion vorgesehenen Verfahren, aber mit geringerem Umfang. • Serienreife und Serienproduktion. Da die Realisierung (Produktion) unter Umständen umfangreiche Vorbereitungen erfordert und lange Zeit braucht, ist es wichtig, für die Überprüfung der Entwicklungsergebnisse auf Prototypen zurückgreifen zu können. Während Simulation bestimmte Aspekte des Entwicklungsprodukts überprüfen sind Prototypen physische Produkte, die bezüglich der betrachteten Eigenschaften mit dem Endprodukt hinreichend gut übereinstimmen. Relevante Eigenschaften eines Prototypen können sein: • Gewicht/Masse, Volumen, Form, Oberflächenbeschaffenheit, • mechanische oder elektrische Schnittstellen, Schnittstellenverhalten, • Energieverbrauch oder Energieabgabe, • Kraftaufnahme, Verformung, • Form als Basis für den weiteren Produktionsprozess. Die letzte Eigenschaft dient dabei nicht mehr der Nutzung des Prototypen zur Überprüfung des Entwicklungsergebnisses sondern als Basis für die Herstellung von Werkzeugen (Formen) für die Fertigung. In dieser Nutzungsform dient Prototyping der Beschleunigung des Produkterstellungsprozesses durch schnelles Bereitstellen von Ausgangsformen (rapid prototyping). 6.1.5

Prozesstechnische Produkte

Prozesstechnische Produkte sind Produkte, die nicht individuell (als Stück) identifiziert werden, sondern als Masse (Flüssigkeit, Schüttgut) gefertigt und (abgesehen von der notwendigen Portionierung und Verpackung) auch so genutzt werden. Die wachsende Bedeutung prozesstechnischer Produkte in der Industrie liegt in der zunehmenden Arbeitsteilung entlang des Produktentstehungsprozesses. Bei prozesstechnischen Produkten spielt das Produktionsverfahren (Prozess) eine wichtige Rolle, so dass die Entwicklung des Produkts die Entwicklung des Produktionsprozesses als zentrale Aufgabe beinhaltet. Der Produktionsprozess kann grob beschrieben werden durch einerseits die Rezeptur und Mischung der Ausgangsstoffe und andererseits das zu verwendende Verfahren.

6.1 Physische Produkte

213

Industrielle Produkte Genauso wie heute statt Mehl und Brot verschiedene Zwischenstufen wie Backmischungen oder Backlinge existieren, gibt es in der Industrie verfahrenstechnische Produkt als Zwischenstufen. UHU Der Markenname UHU steht heute als Synonym für Haushaltsklebstoffe. Kleben hat als Verfahren zum Verbinden von Teilen im industriellen Bereich an Bedeutung immens zugenommen. Die Stabilität von Klebeverbindungen erlaubt den Einsatz in vielen Bereichen. dazu werden Klebstoffe gezielt entwickelt. Anforderungen an Klebstoffe umfassen den Klebeprozess (Geschwindigkeit, Genauigkeit, Beherrschbarkeit), die Klebeverbindung (Festigkeit, Kraft, verbindbare Stoffe) und Ihre Haltbarkeit (Zeit, Lastwechsel, Temperatur, Schwankungen) sowie Aspekte von Qualitäts- Umwelt- und Gesundheitsschutz bei der Verarbeitung.

Auch die Entwicklung solcher Zwischenstufen als Rohstoffe für die Weiterverarbeitung wie Granulate, Legierungen, Folien erfordert denselben systematischen Prozess von der Zielsetzung bis zur Produktion. Folien Folien sind ein prozesstechnisches Produkt, das als solches (in geeigneten Einheiten) verkauft oder (mehrheitlich) in anderen Produkten eingesetzt wird. Bei Folien spielt das Rohmaterial, die Urformung und nachfolgende Umformprozesse gleichermaßen eine Rolle für die Eigenschaften. An diesem Beispiel können wir zeigen, dass für wichtige geforderte Eigenschaften durchaus auch die Umkehrung in geeigneten Anwendungsgebieten eine sinnvolle Forderung sein kann: Forderung: Gegenteil: Anwendungsgebiet: langlebig verrottend Medizin, Abfallaspekt undurchlässig durchlässig Filter, Stoffe (atmungsaktiv) weitere Gegensatzpaare sind: feuerhemmend – brennbar, durchsichtig – undurchsichtig, stabil – flexibel, fest – weich, stabil – zerreißbar.

Medikamente Medikamente sind wichtige Beispiele verfahrenstechnischer Produkte. Das vorher über Zusammensetzung und Prozess gesagte gilt auch hier. Neben den eigentlichen Produkteigenschaften des Medikaments (Wirkstoff, Entwicklung bzw. Entdeckung im Rahmen der Arzneimittelforschung) spielt dabei die Galenik eine wichtige Rolle: Die Kombination von Wirksubstanz und Hilfsstoffen ergibt die Darreichungsform (Formulierung). Diese beein-

214

6 Entwicklung in speziellen Produktbereichen

flusst wesentliche Wirkungsfaktoren des Medikaments, die bei der Entwicklung zu berücksichtigen sind: • Umgang mit kleinsten Stoffmengen (Dosierung), • Transport zum und Verbleib am Ort des Wirkens (räumliche Verfügbarkeit im Körper), • Zeitliche Abgabe des Wirkstoffs (zeitliche Verfügbarkeit), • Haltbarkeit und Konservierung des Arzneimittels. Dies zeigt exemplarisch die Komplexität des Produkts Medikament. Aspirin Als Stoff ist die Salicylsäure schon lange in Benutzung. Fiebersenkende Mittel wurden aus Weide (Salix, namengebend für Salicylsäure) und Mädesüß (Spirea, namensgebend für Aspirin), die beide an feuchten Orten wachsen, gewonnen. Aspirin ist Acetylsalicylsäure, die von Bayer entdeckt und als Marke angemeldet wurde. Als Produkt ist ASPIRIN in verschiedenen Darreichungsformen als Tablette, Granulat, Brausetablette oder Kautablette erhältlich, auch in Kombination z.B. mit Vitamin C oder Koffein. Der Stoff führt also zu einer Vielzahl von Produkten.

Ein wichtiges Problem bei der Entwicklung verfahrenstechnischer Produkte ist die Abschätzung und der Nachweis der Wirkung bzw. Funktionalität. Neben statistischen (Fehler erster und zweiter Art) ergeben sich z.B. bei Medikamenten auch ethische Fragestellungen bei der Erprobung und beim Einsatz. 6.1.6

Managementaspekte

Der Produktentstehungsprozess bei physischen Produkten ist dadurch gekennzeichnet, dass eine der Entwicklung nachgelagerte und von ihr deutlich getrennte Produktionsphase das physisches Produkt erzeugt. Dadurch entsteht eine Schnittstelle. Die zeitliche und räumliche Trennung führt zu Informationsverlusten und Abstimmungsproblemen. Konstruktion, Werkzeugbau, Einkauf und Fertigung sind für die Qualität und den Preis des Endprodukts entscheidend und müssen entsprechend ganzheitlich berücksichtigt werden. Arbeitsumgebung, Infrastruktur und Computerunterstützung sind für den Erfolg wichtig. Die Material- und Herstellungskosten spielen eine wichtige Rolle beim Preis. Durch ein Abweichen von einem reinen Wasserfallmodell (Simultaneous Engineering) kann die Gesamtzeit von Entwicklung und Produktion (time to market) beschleunigt werden. Das Zusammenspiel zwischen Mana-

6.2 Intelligente Systeme

215

ger, Entwickler, Designer und Fertigung ist wichtig und muss durch organisatorische Maßnahmen unterstützt werden. Die beiden Schnittstellen zum Kunden, Marketing und Vertrieb spielen je nach Art des Produkts eine unterschiedliche Rolle. Die im Kapitel Entwicklung betrachteten unterschiedlichen Abläufe sind als Basis zu nehmen, um den Prozess vom (individuellen oder allgemeinen) Kundenwunsch bis um fertigen an den Kunden ausgelieferten Produkt optimal zu gestalten. Dabei muss berücksichtigt werden, dass sich durch sich ändernde Technologien (in Produkt und Fertigung) und Ansprüche (von Kunde und Stakeholdern) die Anforderung an das Produkt und an den Prozess ändern können. Es ist die Verantwortung des Managements, je nach Produkt (von Aalreuse bis Zytostatika oder von der Schokolade bis zum Flugzeug) die Aufbau- und Ablauforganisation so zu gestalten, dass der gesamte Produktentstehungsprozess im Sinne von Kunden und Unternehmen optimal und flexibel ist.

6.2 Intelligente Systeme Intelligente Entwicklung – Clevere Produkte

Künstliche Intelligenz ist nur ein Aspekt intelligenter Systeme, nämlich dort, wo dem System selbst Intelligenz zugeschrieben werden soll. Wichtiger sind aber integrierte und eingebettete Systeme (embedded systems), in denen die Integration von Hardware und Software zu einem intelligenten Verhalten des Systems und damit zu optimalem Kundennutzen führt. Zur künstlichen Intelligenz besteht ein fließender Übergang nach dem Motto „Künstliche Intelligenz ist immer das, was Computer noch nicht können“. Im Sinne unserer Klassifizierung sind solche Systeme wegen der deutlichen Bedeutung der mechanischen und elektronischen Komponenten physische Produkte, also „Hardware“. 6.2.1

KI-Systeme

Künstliche Intelligenz (KI, Artificial Intelligence, AI) bedeutet, einem System ein dem Menschen ähnliches Problemlösungsverhalten zu geben. Im klassischen Bereich war dies auf Computer (mit ihren Ein-Ausgabegeräten) eingeschränkt, eine viel wichtigere Produktklasse eröffnet sich aber durch das Zusammenspiel von Methoden (Künstliche Intelligenz, Heuristiken), Software und Hardware (Sensoren, Aktoren). Menschliches Verhalten nachzubilden bedeutet immer auch, menschliche Fehler zuzulassen. Dadurch, dass der Bereich exakt spezifizierbarer und algorithmisch lösbarer Probleme verlassen wird, ergeben sich immer Auf-

216

6 Entwicklung in speziellen Produktbereichen

gaben, für die das verwendete Verfahren nicht optimal oder nicht angemessen ist. Ein gutes Beispiel dafür sind optische Täuschungen, die vom menschlichen Auge und Gehirn so verarbeitet werden, wie es sich im Laufe der Evolution als optimal ergeben hat. Lernen und Adaption Intelligenz beinhaltet insbesondere die Fähigkeit, zu lernen – auf den verschiedensten Abstraktionsebenen: • Parameterlernen: ein (numerischer) Parameter wird gelernt (der Parameter beschreibt ein Attribut eines Objekt der Realität) oder angepasst (der Parameter beschriebt einen Aspekt des Systemverhaltens). • Modellierung: Anpassen, Finden oder Schaffen von Strukturen und Modellen der Realität oder des Systemverhaltens. • Reflektion: Betrachtung des eigenen Problemlösungs-, Lern- und Modellbildungsverhaltens. Expertensysteme und Wissensverarbeitung Eigentlich gehören Expertensysteme in den Bereich Software-Entwicklung. Da sie aber häufig Komponenten intelligenter Systeme sind, sollen sie hier besprochen werden. Expertensysteme sind Systeme, die das Wissen von menschlichen Experten enthalten, um damit ein Problemlösungsverhalten zu erzielen, das dem eines Menschen angenähert ist. Dies beinhaltet die Fähigkeit, Wissen zu verarbeiten und aus unsicheren Daten und Zusammenhängen Schlüsse zu ziehen. Trivialfall der Wissensrepräsentation Als ein ganz triviales Beispiel, wie explizite Wissensrepräsentation auch die Verständlichkeit von Programmen verbessern kann, betrachten wir die folgenden Berechnungen: Y = 0,159664 ∗X und Y = 0,157080 ∗ X und deren explizite Gegenstücke: UmStProzentSatz = 19; UmStSatz = UmStProzentSatz / 100 Brutto_in_Netto = UmStSatz / (1+UmStSatz) Nettobetrag = Bruttobetrag ∗ Brutto_in_Netto PI = 3,141593, Vollkreis_rad = 2 ∗ PI, Vollkreis_grad = 360, grad_in_rad = Vollkreis_rad / Vollkreis_grad, Radius = 3 \\ hier als Konstante gegeben Kreisabschnittsfläche = Radius ∗ Radius ∗ grad_in_rad ∗ Winkel_grad Dies ist zwar ein klassisches Beispiel des Software-Engineering, aber es erlaubt, die Berechnungen des Programms nachzuvollziehen. Änderungen (z.B. im Radius oder der Umsatzsteuer, Übergang von Grad zu anderen Systemen) sind leicht umzusetzen.

6.2 Intelligente Systeme

217

Knowledge Engineering Den Kernpunkt der Entwicklung von Expertensystemen stellt das Knowledge Engineering dar: das Erfassen, Modellieren und Testen von Expertenwissen. Expertensystem-Entwicklung ist kein linearer, sondern ein zyklischer Prozess, bei dem die Schritte Wissensakquisition, Implementierung und Testen unter Umständen sehr oft durchlaufen werden müssen. Die Wissensakquisition, d.h. das Erfassen und Strukturieren von Wissen, erfolgt durch Interviews und Durchspielen von Fällen mit dem Experten. Das Wissen wird formalisiert und modelliert, zum Beispiel durch die graphische Niederlegung in Semantischen Netzen (Begriffe und Beziehungen), in Ablaufdiagrammen (Problemlösungsverhalten) und in Regeln. Dieses formalisierte Wissen kann zunächst mit den Experten diskutiert und dann in das Expertensystem implementiert werden. Für den späteren Einsatz des Expertensystems ist es wichtig, dass das System den Nutzern gegenüber "richtig" funktioniert. Dies setzt ein korrektes Wissen, eine dem Expertenvorgehen angemessene Ablaufsteuerung und eine benutzerfreundliche Schnittstelle voraus. All dies kann man bei komplexen Aufgaben nicht auf einen Schlag erreichen. Vielmehr wird man zunächst einen oder mehrere Prototypen entwickeln, die dann laufend getestet und verbessert werden. Das Thema rapid prototyping ist also bei intelligenten Systemen besonders wichtig, wobei hier sowohl das Verhalten als auch die Benutzerschnittstelle Objekt eines Prototyps sein können. Im Bereich der Expertensysteme ist eine vollständige Spezifikation des Systems nicht möglich, so dass das Testen und Verbessern des Systems ein wichtiger Teil des Entwicklungszyklus ist. So geht im Laufe des Entwicklungszyklus ein Prototyp allmählich durch Verbesserungen in das operationelle System über. Dabei soll das System sowohl vom Knowledge Engineer und vom Experten als auch von möglichst vielen zukünftigen Nutzern getestet werden. Das Durcharbeiten von praktischen Fällen (Konsultationen) kann zunächst anhand des nur auf dem Papier festgehaltenen Wissens, danach anhand des Prototyps und zuletzt mit dem fertigen System geschehen. Für die Bewertung sollten typische Problemfälle bereits während der Wissensakquisition erfasst und mit dem erwarteten Problemlösungsverhalten zusammen festgelegt werden. Auf diese Weise hat man objektive Vorgaben für die Beurteilung des fertigen Systems.

218

6 Entwicklung in speziellen Produktbereichen

Identifikationssysteme Eines der klassischen Einsatzgebiete von Expertensystemen ist die Klassifikation, die auch als Basis für Diagnose, Beratung oder Wartung/Reparatur eine notwendige Aufgabe ist. Dabei wird ein Objekt oder Ereignis einer von mehreren Klassen zugeordnet. Anwendungen gehen von der Pilzbestimmung bis zur Lagebeurteilung. Das Wissen liegt meist in der Form „Fakt Ÿ Phänomen“ und „Phänomen Ÿ Beobachtung“ vor. Erst Erfahrungswissen erlaubt es, von den eventuell unsicheren Beobachtungen in Ihrer Gesamtheit auf die Fakten (in diesem Fall die Zugehörigkeit zu einer Klasse bzw. die Eigenschaften des Objekts) zu schließen. Danach kann eine weitere Stufe aufgrund des Expertenwissens abwägen, welche der Konsequenzen „Fakt Ÿ Maßnahme“ ausgewählt werden. Bei der Identifikation wird nicht nur auf die Klasse, sondern auf ein bestimmtes Individuum geschlossen.

Informationsintegration Ein wichtiger Aspekt der Intelligenz ist es, mit scheinbar widersprüchlichen Informationen klarzukommen. Der wichtigste Punkt dabei ist, aus widersprüchlichen Informationen nicht beliebige Schlussfolgerungen zu ziehen: Eine widersprüchliche Information kann ja immer auf die Aussage „0=1“ bzw. „wahr = falsch“ reduziert und damit formal jede beliebige Aussage hergeleitet werden. Dazu muss das System Widersprüche erkennen und bewerten können. Klassische Beispiele beruhen auf beispielsweise auf Rundungen (π=3,14 gegenüber π=3,141592), Verallgemeinerungen (alle Vögel können fliegen, Strauße sind Vögel, Strauße können nicht fliegen) oder unklare Begriffsverwendungen (UFO = „noch nicht identifizierbares Flugobjekt“ gegenüber UFO = „Raumschiff mit kleinen grünen Männchen“). Eine weitaus anspruchsvollere Aufgabe ist dann, aus inkonsistenten Daten oder auch nur aus verschiedenartigen Daten vernünftige Folgerungen zu ziehen und vernünftige Aussagen und Werte abzuleiten (information fusion). Diese Aufgabe ist nicht nur im Produkt wichtig, sie hat auch in Managementsystemen (Planung, Controlling) immense Bedeutung. Vorgehen Ein generelles Vorgehen bei der Erstellung intelligenter Systeme lässt sich nur sehr grob angeben, da jede Aufgabe andere Aspekte hat und andere Methoden erfordert. Generell ist zu sagen, dass es sich hier immer um eine Software-Entwicklung handelt, für die dieselben Prinzipien des SoftwareEngineering gelten wie für jede andere Software auch. Unterschiede ergeben sich dort, wo Lernfähigkeit (Adaptivität) gefordert ist, Systemeigenschaft ist, oder die Basis des intelligenten Verhaltens bildet. Hier spielen natürlich

6.2 Intelligente Systeme

219

die Lernzyklen eine wichtige Rolle. Das Testen ist bei intelligenten Systemen noch wichtiger als bei konventionellen Systemen, da heuristische Methoden und Intelligenz kaum formalisierbar sind. Die wichtigsten Schritte zur Erstellung eines KI-Systems kann man folgendermaßen zusammenfassen: • Modellierung der realen Welt und der Aufgabenstellung: Das Problem und der relevante Teil der Welt müssen modelliert werden. Als Basis der Computerimplementierung muss das Modell der Realität geeignet formalisiert werden. Auch die Aufgabenstellung, die häufig nur vage beschrieben ist, muss exakt beschrieben werden, dazu können z.B. Fallbeispiele mit der zu erreichenden Lösung gesammelt werden. • Modellierung menschlichen Problemlösens: Das menschliche Problemlösungsverhalten kann als Basis dienen. Dazu muss es - ähnlich wie bei Expertensystemen - analysiert werden. • Bestimmung, Auswahl und Test geeigneter Heuristiken: Sofern exakte Verfahren nicht verfügbar oder zu aufwändig sind, müssen Heuristiken bestimmt werden. Basis dafür können das menschliche Problemlösungsverhalten, exakte Lösungen einfacherer Probleme oder Vereinfachungen von exakten Lösungen sein. Die Heuristiken müssen ausgiebig getestet werden. • Lernen und Test: Falls das System adaptiv ist, muss es Lösungsmuster bekommen, an denen es lernen kann. Der Test muss grundsätzlich mit anderen als den gelernten Aufgaben erfolgen. • Einsatz und Modifikation/Adaption: Ein intelligentes System ist niemals fertig. Die Anpassung kann entweder automatisch intern (adaptives System), automatisch extern (durch ein überwachendes System) oder durch Software-Modifikationen (wie bei jedem anderen Software-System) geschehen. 6.2.2

Integrierte Systeme

In integrierten Systemen bilden Hardware (im weitesten Sinne, Maschine, Sensoren und Aktoren) und Software eine Einheit. Integrierte Systeme als Produkt Die Entwicklung integrierter Systeme muss daher Mechanik, Elektronik und Software (sowie gegebenenfalls Elektrik, Hydraulik und Pneumatik) integriert betrachten. Es ist nicht damit getan, die Komponenten zu entwickeln, sondern die wichtigste Aufgabe liegt in der Systementwicklung und der an die Teilentwicklungen anschließende Systemintegration.

220

6 Entwicklung in speziellen Produktbereichen

Wichtige Teilbereiche sind: • Roboter und Autonome Systeme, die sich selbstständig bewegen und selbstständig Aufgaben ausführen können, • Mechatronische Systeme mit Sensoren und Aktoren, • Intelligente Sensoren, • Fuzzy Controller als Prototypen intelligenter Systeme. Automatische Diagnose und Wartung Die Instandhaltung eines Produkts oder Systems stellt die Qualität (Zuverlässigkeit, Verfügbarkeit) des Produkt über einen längeren Zeitraum sicher (siehe auch das Kapitel über Dienstleistungen). Eine automatische vorbeugende Wartung oder eine automatische Diagnose mit anschließender Wartung (automatisch oder systeminitiiert durch den Menschen) trägt wesentlich zur Sicherheit und Lebensdauer eines Systems bei. Vor allem die regelmäßige Überprüfung kann in das Produkt integriert werden Dies gilt für mechanische Teile ebenso wie für Software. Wichtige Komponenten dabei sind die Zustandsüberwachung, Fehlererkennung und die Initiierung von Maßnahmen wie Warnung oder Notabschaltung. Ein generell zu beachtender Aspekt bei Diagnosesystemen sind Fehler auf verschiedenen Niveaus. Zum einen gibt es bei jeder Reaktion auf erkannte Abweichungen (Fehler im betrachteten Objekt) das bekannte Problem des Fehlers 1. und 2. Art: Was passiert bei einem Fehlalarm? Welche Konsequenzen hat eine ignorierte Abweichung? Hier muss schon in der Entwicklung zwischen den Konsequenzen abgewägt werden. Das Ziel ist nicht die Minimierung der Falschalarmrate oder die Entdeckung aller Fehler, sondern eine Optimierung des Systemverhaltens. Zum anderen stellt sich die Frage nach dem Vertrauen in Fehlermeldungen: „Warum soll der Nutzer der Fehlermeldung eines Systems vertrauen, das offenbar fehlerhaft ist?“ 6.2.3

Managementaspekte

Aus der Komplexität des Produkts ergibt sich eine besondere Verantwortung bei der Anforderungsanalyse und Spezifikation, da das Systemverhalten meist nicht vollständig spezifizierbar ist. Dies ist auch bei der Vertragsgestaltung und bei Haftungsregelungen zu berücksichtigen. Die Entwicklungsmethodik ist meist evolutionär und am Rande der Forschung, die Entwickler müssen interdisziplinär arbeiten. Solche Entwicklungsprojekte haben ein hohes Maß an Risiko und Unsicherheit.

6.3 Software

221

Ein wichtiger Erfolgsfaktor ist die Arbeitsumgebung, insbesondere Entwicklungs- und Testumgebungen. Bei der Zeit- und Ressourcenplanung ist zu berücksichtigen, dass die Klärung von Kundenanforderungen und Systemkonzept viel Zeit verbraucht, bevor mit der Teilentwicklung (häufig als „eigentliche“ Entwicklung wahrgenommen) begonnen werden kann. Wer aber die frühen Phasen, Spezifikation und Systemkonzeption zu oberflächlich macht, wird dies in der Integration durch erhöhte Zeit und Kosten oder durch ein nutzloses System büßen.

6.3 Software Die Seele des Computers

Im engeren Sinne bedeutet Software ein Programm, das auf einem Computer lauffähig ist – gemeinsam mit der gesamten dazu notwendigen Dokumentation, Daten und Infrastruktur. Dies beschreibt auch die Definition: (IEEE Standard) „Software: Computer programs, procedures, rules, and possibly associated documentations and data pertaining to the operation of a computer system“. In der ISO 9000 wird der Begriff sogar noch weiter gefasst: auch codiertes Wissen, z.B. in Form von Wörterbüchern gehört dazu. Für die Entwicklung von Softwareprodukten gibt es verschiedene Vorgehensweisen. Eine zentrale Rolle spielen: • Schnittstellendefinition, Systemverhalten, Nutzung, • Systemstruktur, Modularisierung, Objekte, • Datenflüsse, Prozesse und Datenstrukturen. 6.3.1 Software und Programme Basis der Software ist ein Programm Softwareentwicklung - heute noch eine Aufgabe? Wenn man heute Studenten mit dem Problem Programmierung konfrontiert, ist die verbreitete Meinung "dafür studieren wir nicht, dafür gibt es Programmierer". Wenn man Absolventen befragt, hat der größte Teil schon mal ein Makro geschrieben, eine HTML-Seite erstellt oder ein Datenerfassungsprogramm modifiziert. Die modernen Sprachen machen es leicht, zu programmieren, sie verführen aber auch dazu, schnell und flüchtig lauffähige Systeme zu erstellen –ohne Struktur und Dokument. Hier liegt eine besondere Verantwortung für den Manager, weil viele solche Aufgaben nicht als Projekt initiiert und geplant werden und weil die Aufgabe „Softwareentwicklung“ auf die „Programmierung“ reduziert wird. Die vorgelagerte Analyse und Spezifikation und die nachgelagerte Integration und Test sind vom

222

6 Entwicklung in speziellen Produktbereichen

Aufwand aber jeweils etwa doppelt so umfangreich wie die Programmierung und von der Zeit her nehmen sie sogar einen noch größeren Teil des Produktentstehungsprozesses ein. Software für die Balanced Scorecard Eine Balanced Scorecard in Software zu implementieren, ist an sich kein Problem: Man nehme die Daten und stelle sie richtig dar. Die Probleme und Aufgaben liegen im Detail: • Definition der Schnittstelle zu den Systemen des Unternehmens und zur Erfassung der notwendigen Daten. • Auswahl der Kennzahlen, Definition der Kennzahlen bezüglich Objekt- und Zeitbezug. Beschaffung der Daten und Programmierung der Schnittstellen • Möglichkeiten der Auswahl von Kennzahlen und Datenquellen durch den Benutzer • Automatisierung der Erfassung und Aktualisierung. • Weiterleitung an Stellen, Personen und Systeme, Darstellung in geeignetem Kontext. Als Beispiel soll hier die relativ klare Kenngröße Umsatz dienen: neben den Objekten und Organisationseinheiten, die zu erfassen sind, ist auch der Zeitraum (Generierung, Tätigung, Erfassung, Meldung) des Umsatzes entscheidend.

Programm und Code An dieser Stelle soll kurz auf die Frage „Was ist ein Programm?“ eingegangen werden. Die anfängliche Definition einer Folge von Anweisungen ist längst nicht mehr sinnvoll, die allgemeinste Definition des „von einem Computer ausführbaren Modells“ ist sehr abstrakt. Um den Begriff der Ausführbarkeit zu verfeinern kann man fordern, dass das Programm in einer für den Computer verständlichen Form vorliegt, damit ist im Normalfall eine Programmiersprache gemeint. Dies führt uns nicht nur auf die Frage „Was ist eine Programmiersprache?“ sondern auch darauf, wie Programmiersprachen selbst entwickelt werden.

6.3 Software

223

Programmiersprache Eine Programmiersprache ist definiert durch Ihre Syntax (Sprachregeln) und Semantik (Bedeutung von in der Sprache erstellten Elementen für den ausführenden Computer). Auch eine Programmiersprache wird entwickelt und ist damit – in Form der Dokumentation (Syntax und Semantik) und umgesetzt in einen Compiler – ein Produkt. Das Programm ist ein Modell dessen, was beschrieben/ gelöst/implementiert werden soll, die Sprache dient dazu, dies zu beschreiben. Eine Programmiersprache ist eine Sprache, die von einem Computer verstanden wird, d.h. eine Syntax und Semantik für Modelle, für die es einen Compiler oder Interpreter gibt. Anforderungen an Programmiersprachen 1. Umfang der durch die Programmiersprache implementierbaren Funktionalität (ideal: Maschinensprache), 2. Paradigmenbezug: Umfang der unterstützten Konzepte der Programmierung und des Software-Engineering (ideal: alle denkbaren Konzepte), 3. Realmodell: Umfang der direkt ausdrückbaren Konzepte der Realität (ideal: Sprachverstehen und Interpretation natürlicher Sprache + Lernfähigkeit + Verstehen und Interpretation von Bildern und Graphiken), 4. Strukturierung, Klarheit, Erlernbarkeit (etwa ideal: natürliche Sprache + mathematischer Formalismus), 5. Einfachheit und Erlernbarkeit (ideal: wenige Elemente, nah an der natürlichen Sprache), 6. Leichte Erstellung eines Übersetzers (ideal: Maschinensprache). Erstellung einer Programmiersprache 1. Syntax: Was sind zulässige Programme dieser Sprache? 2. Rechnersemantik: Was macht der Computer aufgrund eines Programms bzw. seiner Teile (z.B. Anweisungen)?

Modelltransformation Im Bereich Software ist der Aspekt der Modelltransformation besonders hervorstechend, da ja auch das fertige Programm „nur“ ein Modell ist, allerdings eines, das auf einem Computer ablauffähig ist. Moderne Programmiersprachen versuchen, anwendungsnähere Modelle compilierbar zu machen und so dem Menschen die letzten computernahen Modelltransformationen im Entwicklungsprozess zu ersparen. 6.3.2

Software Engineering

Hauptaufwand bei der Entwicklung von Software ist nicht das Programmieren, sondern das Spezifizieren, Finden der Lösung, und das Testen. Dies gilt zumindest dann, wenn die Spezifikation und Entwurf einigermaßen ver-

224

6 Entwicklung in speziellen Produktbereichen

nünftig gemacht wurde: normal ist eine Verteilung von 40 : 20 : 40 für Analyse/Spezifikation/Entwurf : Programmierung : Integration/Test. Prinzipien Einige der wichtigen Prinzipien aus dem Software Engineering seien angeführt, für Details sei auf die Fachliteratur (z.B. [Balzer]) verwiesen: • Phasenmodelle, • top-down- /bottom-up-Entwicklung, • Strukturierung, Modularisierung, Hierarchisierung, • Datenkapselung, Information Hiding (Geheimnisprinzip), • Datenabstraktionen, abstrakte Datentypen (Objekte), • Inkrementelle/evolutionäre Entwicklung, • Prozedurale, funktionale, deklarative, objektorientierte Programmierung, • Modelle, Modellierungsmethode (z.B. Unified Modelling Language), • Integrierte Dokumentation. Konfigurationsmanagement Das Konfigurationsmanagement ist bei SW besonders wichtig, da SW leicht änderbar ist und zwischen Entwicklungsergebnis und Nutzung nur wenige und wenig aufwändige Schritte liegen. Ursachen für Varianten können sein: • verschiedene Nutzer, Nutzungsumgebungen und Einsatzbedingungen, • unterschiedlicher Funktionsumfang, • verschiedene Betriebssysteme, Plattformen oder Schnittstellen, • verschiedene Versionen von Sprache und Entwicklungsumgebung, • verschiedene Sprachen (z.B. deutsch-englisch) für die Bedienung, • zeitliche Abfolge und unterschiedliche Entwicklungsstände. Das Konfigurationsmanagement stellt die Zuordnung sicher zwischen • Anforderungs- und Spezifikationsdokumenten, • Entwurfsdokumenten, • Code und ausführbaren Programmen, • Testdaten, Testumgebungen und Testdokumenten, • Nutzerdokumentation und weiteren Dokumentationen. Phasenkonzepte Phasenkonzepte wurden bereits betrachtet. Sie spielen in der Softwareentwicklung eine wichtige Rolle. Durch die leichte Änderbarkeit von Software ist ein Konzept für die Phasen, Dokumente und Meilensteine eine wichtige Voraussetzung für strukturierte und systematische Entwicklung und hohe Qualität. Besondere Bedeutung hat das bereits betrachtete V-Modell.

6.3 Software

225

Problemanalyse

Betrieb

Anforderungen

Abnahme

Spezifikation

Validierung

Entwurf

Verifikation

Programm Code

Programmtest Modultest

Software-Integration (evtl. HW-SW-Integration)

Abbildung 6-2: V-Modell für Software 6.3.3

SW-Qualität

Qualität bei Software hat viele Aspekte: • Brauchbarkeit (in der Realität, Funktionalität, Zufriedenheit), • Korrektheit (bezüglich der Spezifikation und Anforderungsanalyse), • Zuverlässigkeit (Ausfallsicherheit, Fehlerfreiheit), • Flexibilität und Änderbarkeit (bezüglich Einsatzbedingungen, Plattform), • Ergonomie und Erlernbarkeit (für erfahrene Nutzer und Neulinge). Gegebene Erfordernisse an und der jeweilige Umgang mit der Software bestimmen die Qualitätsanforderungen. 6.3.4

Strukturierte Datenflussmodellierung

Die strukturierte Analyse (Strctured Analysis [deMarco]) ist ein wichtiges Instrument für Analyse, Spezifikation und Entwurf datenverarbeitender Systeme. Das Datenflussmodell der Structured Analysis besteht aus drei Elementen: • dem eigentlichen Datenflussdiagramm (data flow diagram, DFD) mit Datenobjekten und Verarbeitungsknoten, • dem Wörterbuch (data dictionary, DD) mit der Beschreibung der Syntax und Semantik der Datenobjekte, • den Beschreibungen der Verarbeitungsknotenfunktionen (mini specifications, MSP). Datenflussdiagramm Das Datenflussdiagramm (DFD) eines Prozesses bzw. einer Verarbeitungsfunktion enthält alle Datenflüsse, die in dem jeweiligen Prozess verwendet

226

6 Entwicklung in speziellen Produktbereichen

werden. Die Datenflüsse müssen in Verarbeitungsknoten erzeugt werden und werden dort genutzt. Wir haben also zwei Hauptelemente: • statische Knoten: Verarbeitungsknoten, Endknoten und Speicher, • dynamische Datenflüsse und eventuell dynamische Kontrollflüsse. Als Informationsträger (Datenobjekte), deren Datenstruktur im DD beschrieben ist, kommen dabei infrage: • dynamische Datenflüsse (data flow), • statische Speicher (data stores). Elemente eines Datenflussdiagramms sind damit: • Verarbeitungsknoten (Nodes): Dies sind die regulären Knoten im DFD und seinen Verfeinerungen. Sie stellen die Funktionen (Transformationen, Prozesse) des Systems (bzw. seiner Komponenten) dar. • Endknoten (Terminators): Dies sind die Schnittstellen des DFD zur Außenwelt. Die externen Beziehungen und Datenflüsse zwischen Endknoten werden nicht modelliert. • Datenflüsse (Data Flows): Sie beschreiben die zwischen den Knoten ausgetauschten Daten. • Speicher (Stores): In ihnen werden Daten abgelegt. Die Strukturen der Speicher werden ebenfalls im DD beschrieben. Mit Hilfe der Verfeinerungen oder der Transformationsregeln der Kurzbeschreibungen kann überprüft werden, dass alle eingehenden Daten verwendet und alle ausgehenden Daten erzeugt wurden. Terminalknoten

Verarbeitungsknoten

Verarbeitungsknoten

Terminalknoten

Verarbeitungsknoten Datenspeicher

Abbildung 6-3: Datenflussdiagramm Eine mögliche Erweiterung des DFD um Kontrollflüsse, die nicht Daten sind, sondern Ereignisse auslösen (triggern), führt zum Kontrollflussdiagramm (Control Flow Diagram, CFD).

6.3 Software

227

Wörterbuch (Data Dictionary) Das Data Dictionary (DD) beschreibt die Struktur und Bedeutung der Daten. Es enthält alle Daten mit • Aufbau und Struktur (Syntax), • Inhalt und Bedeutung (Semantik). Die Struktur des Data Dictionary werden wir im Kapitel Modelle kennen lernen. Verarbeitungsfunktionen Die Verarbeitungsknotenfunktion (mini specification, MSP) beschreibt die Regeln, dach denen die in einen elementaren Verarbeitungsknoten eingehenden Datenflüsse in die ausgehenden Datenflüsse transformiert werden. Dabei fordert die Konsistenzregel, dass alle • eingehenden Daten verwendet werden – sonst wären sie überflüssig, • ausgehenden Daten erzeugt (also z.B. berechnet) werden – sonst könnten sie nicht verwendet werden. Daneben kann die Verarbeitungsfunktion auch Ereignisse auslösen, deren Weiterleitung dann im Kontrollflussdiagramm beschrieben wird. Die Beschreibung dazu kann z.B. in Form von Zustands-Übergangs-Diagrammen (state transition diagrams), Entscheidungstabellen oder Petri-Netzen geschehen. Hierarchie Ein wichtiger Punkt bei der Modellierung der Datenflüsse ist die Verfeinerung. Dabei wird gleichzeitig das DFD und das DD verfeinert. Aus jedem Knoten wird ein DFD, das aber keine Endknoten hat. Vielmehr gehen die Datenflüsse nach außen und müssen - gegebenenfalls mit den im DD gegebenen Strukturen - den Datenflüssen des übergeordneten DFD entsprechen. Es gibt also zwei Möglichkeiten, die Funktion eines Verarbeitungsknotens zu beschreiben: • Durch die hierarchische Verfeinerung. In diesem Fall wird die Funktion eines Verarbeitungsknotens durch sein DFD beschrieben, wobei die Datenflüsse anhand des DD konsistent verfeinert werden. • Durch die Funktonbeschreibung in der MSP. Diese muss für elementare (nicht weiter verfeinerte) Knoten angegeben werden, für alle anderen kann sie angegeben werden.

228

6 Entwicklung in speziellen Produktbereichen

6.3.5 Prozessmodelle

Für Software-Implementierungen sind die dynamischen Abläufe meist noch wichtiger als die Datenflüsse. Deshalb ist die Modellierung der Prozesse essentiell. Der Prozess besteht aus einer Abfolge von Aktivitäten (Funktionen). Die Aktivitäten bewirken Änderungen in den Daten bzw. Objekten. Ein Ereignis entspricht der Zustandsänderung bei einem oder mehreren Objekten. Ereignisse sind Ergebnisse (Endereignis) von Funktionen und lösen Funktionen aus (Anfangsereignis). Tabelle 6-2: Ereignisse und Prozesse Zeitbezug Zustandsbezug

Prozess (Aktivität) Zeitdauer Transformations-Prozess

Ereignis Zeitpunkt, Termin Zustandsänderung

Prozesse können mit verschiedenen Modellen beschrieben werden. Ein im Softwarebereich wichtiges Modell ist die Ereignis-Prozess-Kette EPK, wobei zu den im Kapitel Modell betrachteten Möglichkeiten der Prozessbeschreibung (Zusammenführung/Verzweigung, UND/ODER) noch die Beschreibung der betroffenen Objekte/Daten und Stellen/Akteuren dazukommt. Aktivität Zustand

Objekt

Aktivität

Ereignis Zustandsübergang Prozess = Aktivität Transformation des Objekts Ereignis

Zustand

Objekt

Ereignis

Abbildung 6-4: Ereignis-Prozess-Kette mit Objekten Um Software zu erstellen, werden zunächst die Prozesse im System analysiert. Typischerweise startet die Prozessmodellierung von Unternehmen bei denjenigen Prozessen, die für die Organisation am wichtigsten sind, d.h. die einen großen Anteil an der Wertschöpfung haben: Auftragsabwicklung,

6.3 Software

229

Leistungserbringung, Produktentwicklung, Marketing und Umweltkontakte. Bei technischen Prozessen kann man entweder von einer Black-Box (Schnittstellenverhalten) ausgehen und darauf basierend die internen Prozesse (top-down bzw. outside-in) modellieren oder die Prozesse ausgehend von den wichtigsten Kernprozessen (charakteristische Funktionalität) nach außen (bottom-up bzw. inside-out) modellieren. 6.3.6

Datenbanken

Datenbanken spielen nicht nur als Produkt oder Komponente eine wichtige Rolle. Auch in Entwicklung und Management sind sie ein unverzichtbares Werkzeug. Datenbanken verwalten • Daten: codierte Information, • Informationen: Aussagen über die reale Welt, • Wissen: Information zusammen mit dem Bezug zur Realität. Suchen, Auswerten

Speichern, Ablegen

DB (konzeptuell) DBMS DB (physisch)

DB (physisch)

Abbildung 6-5: Datenbank und Datenbank-Managementsystem Datenmodellierung Die Datenmodellierung dient zur Darstellung und Strukturierung der Informationen. Dabei steht im Gegensatz zur Dynamik der Prozesse und der Datenflüsse die statische Sicht der Datenstruktur und der Dateninhalte im Vordergrund. Datenmodellierung geschieht auf einer abstrakten Ebene durch semantische Netze. Konkreter und datenbanknäher ist die Darstellung in Entity-Relationship-Modellen. Eine sehr allgemeine und vom speziellen Zweck unabhängige Modellierung von Informationen und Wissen ist mit einem Semantischen Netz möglich. (Semantische Netze in informeller Form wurden bereits im Kapitel Kreativitätstechniken betrachtet.) Das semantische Netz als Basis der Datenmodellierung besteht aus • Begriffen (Objekte, Klassen), • Beziehungen (zwischen Begriffen).

230

6 Entwicklung in speziellen Produktbereichen

Die Beziehungen gelten dabei nicht nur zwischen Entitäten (Objekte), es werden auch Beziehungen zwischen Klassen und spezielle Beziehungen, die sich auf die Klassenhierarchie beziehen, modelliert. Datenbankmodelle Datenbankmodelle können nach der Abstraktionsebene und dem Modellkonzept unterschieden werden. Die Modellierung der Datenbank geschieht in folgenden Stufen: • Modell der Realität (allgemein, z.B. mittels semantischem Netz), • konzeptuelles Modell (konzeptuelles Schema), • Datenbank (konkrete Modellierung mit der durch das Datenbanksystem vorgegebenen Syntax). Außerdem erhalten wir nach der Abstraktionsebene die folgenden Schemata (Ebenen): • Benutzersichten: Zusammenstellung derjenigen Daten und Zusammenhänge, die für den jeweiligen Benutzer in der jeweiligen Situation relevant sind. • Konzeptuelle Ebene: Modellhafte Darstellung der Struktur der Daten. • Physische Ebene: Realisierung auf dem Rechner, Speicherung. Der zentrale Begriff der Entität (Entity) kann dabei jeden Eintrag in die Datenbank, d.h. jeden im Modell relevanten Begriff bedeuten. Dieser kann ein reales oder abstraktes Objekt, aber auch beispielsweise ein Konzept, einen Zusammenhang oder ein Ereignis beschreiben. 6.3.7

Managementaspekte

„Software ist flexibel und kann alles.“ Darin liegt das Hauptproblem: hohe Anforderungen, hohe Vielfalt, ungenaue Spezifikation, Zeitdruck und Adhoc-Änderungen. Software ist auch häufig Teil von Hardware und Systemen oder Komponente oder Hilfsmittel von Dienstleistungen Kunde Bei Software ist es besonders wichtig, die verschiedenen Kundenrollen zu differenzieren. Bedarfsträger, Kostenträger und Entscheider, Betreiber (der Software selbst und von benötigter Hardware und Infrastruktur), Benutzer und Bediener haben verschiedene Anforderungen und verschiedene Vorstellungen von der Software. Auftragsentwicklung und Massenprodukte stellen jeweils eigene Anforderungen an den Entwicklungsprozess. Am häufigsten ist aber Software Teil des Produkt, sie stellt dessen Funktionalität sicher, ohne dass sich der Kunde direkt für diese Leistung interes-

6.4 Konzepte und Systeme

231

siert: Eigentlich ist dem Kunden die Software egal, er will eine bestimmte Funktion.

6.4 Konzepte und Systeme Konzeption: Allgegenwärtig und häufig ignoriert

Dieses Kapitel ist wohl das allgemeingültigste, weil die Entwicklung von Konzepten und Systemen in jeder Organisation immer wieder stattfindet. Hier betrachten wir Systeme, die nicht durch Hardware oder Software implementiert sind bzw. in denen weder die Hardware/Software noch der Dienstleistungsaspekt dominiert. Abläufe, Entscheidungen, Informationswege können dabei natürlich auch in Software oder Hardware umgesetzt (implementiert) werden. Wichtig ist der Entwicklungsansatz: Systemstrukturen und Systeme fallen nicht vom Himmel, sie sind Produkt eines Entwicklungsprozesses. Ein systematisches Vorgehen vermeidet Fehler. 6.4.1

Systementwicklung Strukturen werden gefunden oder geschaffen

Die Entwicklung und Einführung von Systemen in einer Organisation ist für die Betroffenen immer ein Projekt, auch wenn die durchführende Organisation (Berater) dies regelmäßig in ähnlicher Form durchführt. Als Systeme kommen in Betracht: • Managementsysteme, organisatorische und kaufmännische Systeme (für Umwelt-, Qualitäts-, Risiko- oder Projekt-Management, Buchhaltung oder Kostenrechnung, Aufbauorganisation), • Systeme der Information und Kommunikation, DV-Systeme, • Technische Systeme mit organisatorischem Anteil (Transport, Produktionssysteme, Anlagen). Organisatorische Systeme Systeme sind wichtig, um Prozessen eine Struktur zu geben. Menschen sind der wichtigste Bestandteil von Organisationen. Auch Managementsysteme müssen systematisch entwickelt werden. Dabei sind die generellen Phasen für die Entwicklung organisatorischer Systeme (Managementsysteme) etwa: • Zielsetzung, • Konzeption des Managementsystems, • Definition, Anpassung,

232

6 Entwicklung in speziellen Produktbereichen

• Umsetzung und Dokumentation (Managementhandbuch), • Implementierung, Inkraftsetzung, • Test, Überprüfung.

Agenda 21 Struktur Dieses Beispiel kommt aus dem ehrenamtlichen Bereich, in dem neben den in der Wirtschaft zu betrachtenden Effizienzbetrachtungen auch die Motivation der Beteiligten und die vielfältigen Stakeholder eine wichtige Rolle spielen. Nach einer autonomen Phase war eine Unzufriedenheit der Bürger mit den Strukturen festzustellen. In verschiedenen Phasen der Strukturentwicklung und – Anpassung aufgrund von geänderten Rahmenbedingungen entwickelte ein dafür einberufenes ehrenamtliches Strukturteam die organisatorische Struktur für den Prozess. Die Funktion der Stellen und ihre Benennung war ein wichtiger Punkt, da er das Selbstverständnis dokumentiert und die Kommunikation nach außen erleichtert. Wichtige Strukturelemente wurden mit „Agenda-Parlament“, „Agenda-Gruppen“, „Agenda-Rat“ und „Agenda-Büro“ und der Funktion der jeweiligen Sprecher gefunden.

Auch die Entwicklung von Managementsystemen (System als solches, Instanz) und von allgemeinen Systemkonzepten (Modellen) oder Zertifizierungsrichtlinien (Meta-Modellen) ist eine Entwicklungsaufgabe. Grüner Aal Um für Schulen die Aufwände für die Einführung und Zertifizierung eines Umweltmanagementsystems zu erleichtern, wurde durch die Hochschule Aalen ein Umweltmanagementsystem für Schulen entwickelt. Vorgaben waren: • Anspruch und Qualität wie das EU-System EMAS, Berücksichtigung aller Punkte der Norm ISO 140001, • Leichte Umsetzung durch die Schulen, vertretbarer Aufwand (insbesondere geringe Kosten) für Implementierung und Zertifizierung, • Gleichberechtigte Berücksichtigung von direkten Umweltauswirkungen (Energie, ...) und indirekten Umweltauswirkungen (Umweltbildung, Einfluss auf die Schüler). Die Entwicklung erfolgte in mehreren Projekten gemeinsam mit dem Umweltamt der Stadt. Dazu wurden parallel die Richtlinien (Kriterien, Meta-Modell), eine exemplarische Dokumentation (Vorlage, Modell) und das Umweltmanagement für eine konkrete Schule (Instanz) entwickelt. Die wechselseitige Rückkopplung der drei Teilbereiche führte zu einer schnellen Konvergenz von Anspruch (Kriterien) und Machbarkeit (Umsetzung).

6.4 Konzepte und Systeme

233

Regelsysteme Systeme von Regeln sind für das Management („management by ...“, Managementsysteme), im Rechtssystem (gesetzliche und untergesetzliche Regelwerke) und in der Betriebswirtschaft (z.B. Prinzipal-Agent) wichtig. Leider wird dieser Bereich häufig nicht als Entwicklungsaufgabe gesehen, sondern im Wechselspiel von Stakeholdern (Lobbies) und Gremien entwickelt. Wichtige Punkte der Entwicklung von Regelsystemen sind: • Ziele: Was wollen wir wie gestalten? • Anforderungen: Aus wessen Sicht muss was geregelt werden? • Entwurf: Welche Prinzipien sollen zu Grunde gelegt werden? • Implementierung: Welche Regeln werden konkret festgelegt? • Verifikation: Ist das System vollständig und widerspruchsfrei? • Validierung: Kann das Regelsystem in die Realität umgesetzt werden? Wird durch das Regelsystem das gewünschte Ziel erreicht? Welche (Rück-) Wirkungen und (Ausweich-) Reaktionen bewirkt das Regelsystem? Technische Regelsysteme (Regelkreise) werden im Kapitel Dynamische Systeme betrachtet, den Regelkreis des Controllings haben wir bereits kennen gelernt. Infrastruktur Die Bedeutung der Infrastruktur für Produkte wurde bereits betrachtet. Infrastrukturen müssen aber geplant werden. Sie entwickeln sich zwar im Allgemeinen dezentral, aber ohne eine Koordination besteht die Gefahr von Inselbildungen. DV-System Die Einführung oder Modifikation eines Datenverarbeitungssystems ist eine Aufgabe, die in Firmen relativ häufig ist, aber durchaus nicht als Routineaufgabe bezeichnet werden kann. Sie hat wenig mit der vorher betrachteten Softwareentwicklung zu tun. In Ergänzung zu den allgemeinen Phasenmodellen sollen deshalb hier die wichtigen Phasen und Zäsuren der Einführung bzw. Umstellung eines Informationsverarbeitenden Systems vorgestellt werden. Dies kann auch als Basis für andere Systemeinführungen dienen: • Vorphase: Idee, Machbarkeitsanalyse, Informationsbeschaffung ∇ Entscheidung über Projektstart: Sinn und Ziele • Analysephase: Ist-Analyse, Schwachstellenanalyse ∇ Entscheidung über Bedarf, Weiterführung des Projekts

234

6 Entwicklung in speziellen Produktbereichen

• Konzeptphase: Soll-Konzept, Grobspezifikation, Pflichtenheft ∇

Entscheidung über Machbarkeit, Weiterführung des Projekts

• Spezifikationsphase Lastenhefte ∇

Entscheidung über Art des Systems und Art der Realisierung

• Realisierungsphase: Implementierung, Installation ∇

Entscheidung: Freigabe, Beginn der Tests

• Testphase, Abnahmetest, Betriebstest ∇

Entscheidung: Vorläufige Abnahme, Beginn der Nutzung

• Inbetriebnahmephase ∇

Entscheidung: Abnahme des Systems, Beginn der Nutzung

• Nutzungsphase, Laufender Betrieb, Wartung, Fehlerbehebung, Verbesse-

rungen, Anpassungen ∇ Entscheidung: Beendigung der Nutzung • Umstellungsphase: Auswahl und Entwicklung Neusystem, Migration. 6.4.2 Modellentwicklung Entwicklung, Beratung, Führung: auf´s Modell kommt´s an

Modellentwicklung kann ein Auftrag oder Teil eines übergeordneten Projekts sein. Der Aspekt der Modelltransformation macht Modellbildung zu einem essentiellen Teil von Entwicklungsprojekten aller Art. Der gesunde Verstand ist nach [Descartes] die bestverteilte Sache der Welt, da jeder meint, er hätte genügend viel davon. Dieser Spruch gilt umso mehr für die Abstraktionsfähigkeit und die Modellbildung. Aus einer Menge konkreter Sachverhalte ein abstraktes Modell zu bauen, fällt uns leicht – so lang das Ergebnis nicht zu abstrakt sein soll. Ein Modell kann üblicherweise nicht als fertiges Produkt verkauft werden. Meist ist die Modellierung Teil einer Aufgabe – sie es eine Beratung oder Dienstleistung oder Teil einer Entwicklung. Am wichtigsten und offensichtlichsten wird die Aufgabe der Modellierung dort, wo das Modell Basis des Produkts (Landkarte, Buch) oder der Dienstleistung (Beratung, Training, Wissensvermittlung) ist. Es gibt – von Trivialfällen abgesehen – keine exakten Modelle. Das Modell muss also zielgerichtet sein und das enthalten, was für den zu erreichenden Zweck notwendig ist. 6.4.3 Methodenentwicklung

Die Entwicklung einer Methode oder eines Verfahrens kann Teil einer übergeordneten Entwicklung oder einer Beratung oder aber auch eine eigenständige Entwicklungsaufgabe sein.

6.4 Konzepte und Systeme

235

Heuristiken Eine Methode zu entwickeln, erfordert die Abwägung zwischen Machbarkeit und Exaktheit, zwischen Allgemeingültigkeit und Sicherheit. Mathematische Methoden sind exakt, dafür stimmt aber das beschreibende Modell meist nicht hinreichend mit der Realität überein. Heuristiken und Verfahren der Künstlichen Intelligenz sind zwar bewusst nicht immer „richtig“ oder „optimal“ dafür aber „gut“ und „stabil“. Beispiele für Heuristiken findet man überall dort, wo aufgrund der Komplexität exakte Verfahren nicht eingesetzt werden können. So muss eine komplette Tourenplanung bei 100 Knoten größenordnungsmäßig 99! = 10156 Touren berücksichtigen. Bei 1 ms Rechenzeit pro Route sind das 3·10145 Jahre Rechenzeit. (Wie unfassbar groß diese Zahl ist wird daran klar, dass sie dem 10136-fachen Alter der Sonne entspricht.) Ein einfacher Algorithmus (nächste Nachbarn) braucht größenordnungsmäßig 100² Schritte und mit Verbesserungsroutinen ca. 100³ Schritte. Dies sind dann aber unter obiger Annahme 1000 Sekunden bzw. 17 Minuten.

Strategieentwicklung Die Entwicklung von Strategien ist Aufgabe des Managements, sie kann durch Mitarbeiter und Berater unterstützt werden. Sie ist ein zentraler Erfolgsfaktor, daher ist eine systematische Entwicklung notwendig. Bei der Strategieentwicklung ist es besonders wichtig, wirklich bei den primären Zielen der jeweiligen Einheit anzusetzen. Die Strategie muss dann die Ziele, interne Möglichkeiten und externe Einflüsse und Gegebenheiten optimal verbinden. Festlegung der Ziele (Strategische Ziele, ggf. Zielhierarchie ) Analyse Problem und Umwelt, Prognose Umweltmonitoring

Analyse Zustand und interne Potentiale

Feststellung Potentiale, Chancen, Risiken Konzeptentwicklung, Alternativenentwicklung, Auswahlprozess (Bewertung, Entscheidung) Kommunikation, Umsetzungsplanung, Implementierung

Abbildung 6-6: Strategieentwicklungsprozess

Potentialentwicklung

236

6 Entwicklung in speziellen Produktbereichen

Finanzprodukte Bei Finanzprodukten haben wir zwei mögliche Betrachtungsweisen: • Auszahlung gegen Einzahlung + Preis für Transaktion, • Auszahlung gegen Preis. Insbesondere unter dem stochastischen Aspekt (Einzahlungen und Auszahlungen können zufällig sein), ist die erste Betrachtungsweise besser. Generell sind zu betrachten: • Zahlungsströme (Einzahlung, Auszahlung, Transaktionskosten) und • Wahrscheinlichkeiten. Das ganze kann auf Bankprodukte, Versicherung, Bankdienstleistung angewendet werden. Lotterie Betrachten wir eine einfache Lotterie, bei der gegen einen Einsatz von 1€ zehn Münzen geworfen werden dürfen. Kommt zehnmal Kopf erhält der Spieler 1000€. Im Mittelwert ist die Auszahlung 1000€/1024 = 0,977€, wir machen also pro Spieler einen mittleren Gewinn von 0,023€. Ganz anders stellt sich das ganze unter Berücksichtigung von Steuern und dem zu erzielenden Gewinn dar. Risikobetrachtung Die Wahrscheinlichkeit, einen bestimmten Betrag auszahlen zu müssen, ist über die Binomialverteilung und angenähert über die Poisson-Verteilung berechenbar. Bei 1000 Spielern ist die Chance, gar nichts oder nur einen Gewinn auszuschütten, jeweils ca. 37%. Mit einer Wahrscheinlichkeit von ca. 25 % müssen wir zwei Gewinne oder mehr ausschütten. Normalerweise trägt dieses Risiko der Unternehmer. Wollen wir dieses Risiko versichern, so kostet die Versicherung sicher mehr als die zu erwartenden Auszahlungen. Unter diesen Voraussetzungen müssen wir einen deutlich geringeren Gewinn ausloben, der seinerseits die Attraktivität der Lotterie schmälert. Nur wenn die Anzahl der Teilnehmer genügend groß ist, lohnt sich eine Lotterie.

Markenentwicklung Wir haben die Marke im Verlauf des Entwicklungsprozesses kennen gelernt, als ein Begriffsfeld, das ein Produkt oder eine Produktlinie in den Augen des Kunden charakterisiert. Die Marke selbst ist kein materielles Produkt, sondern begleitet dieses, sie ist aber – zumindest aus Sicht des Marketing oder einer Agentur – ein zu entwickelndes Produkt. Die Markenentwicklung ist im Gesamtprozess der Produktentwicklung ebenso ein Teilprozess wie die Softwareentwicklung für eine Steuerung oder die Entwicklung einer Sicherheitseinrichtung für das Produkt.

6.5 Dienstleistungen

237

Dachmarke Als Beispiel der Entwicklung einer Marke betrachten wir die Entwicklung einer Dachmarke für eine Region. Dies kann eine Regionenmarke (Marke für die Region als ganzes) oder Regionalmarke (Marke für die Produkte der Region) sein. Damit ergeben sich die Anforderungen der verschiedenen Kundengruppen: • Touristiker und Gastronomen für die Regionenmarke, • Regionalvermarkter und regionale Produzenten für die Regionalmarke. Zur Marke gehört nun die Darstellung (Wortmarke als Begriff, eventuell mit Slogan, Bildmarke als graphische Darstellung, Kombination als Wort-BildMarke) und die Abgrenzung der Marke (Nutzungsrecht). Daneben sind organisatorische Fragen wie Inhalt, Träger, Festlegung und Überwachung der Kriterien und Nutzungsbedingungen zu klären und die Marke entsprechend zu verankern (Rechte, Bekanntheit, Image).

6.4.4

Managementaspekte

Da im Laufe des Entwicklungsprozesses von Konzeptionen sehr viel Wissen geschaffen wird, das vorher auch von der Struktur her nicht bekannt war, ist es hier – wie bei den später betrachteten Modellen – sehr schwierig, im vorne herein die Aufgabe oder ihre Erfolgskriterien formal festzulegen. Eine zu frühe und restriktive Festlegung von Kriterien engt die Möglichkeiten ein und verbaut mögliche kreative Lösungen. Besonders gefährlich ist es, Ergebnisse anstelle von Zielen vorzugeben.

6.5 Dienstleistungen Dienstleistung, Produkt des dritten Jahrtausends

Dienstleistungen spielen in einer modernen Gesellschaft eine immer wichtigere Rolle. Dabei können diese Dienstleistungen alleine oder ergänzend zu bzw. gemeinsam mit materiellen Produkten (hybride Dienstleistungen) auftreten. Für die systematische Entwicklung von Dienstleistungsprodukten hat sich der Begriff Service Engineering etabliert. Das Problem bei Dienstleistungen ist, dass sie nicht gelagert werden können, sondern direkt vor Ort (häufig im Kontakt mit dem Kunden) erbracht werden müssen. Die Leistungserbringung erfordert Kontakt mit dem Kunden (oder von ihm gestellten Produkten oder Personen) und kann erst zu diesem Zeitpunkt geleistet werden. Damit erfolgt im Gegensatz zur klassischen Produktion bei einer Dienstleistung zuerst der Absatz (Auftrag, Vertrag) und dann die Implementierung des Produkts. Dies bedingt auch, bei einer Abnahme das Problem, dass bei Leistung die Dienstleistung vollständig

238

6 Entwicklung in speziellen Produktbereichen

erbracht ist und nicht mehr rückgängig gemacht werden kann. (Hier bietet sich als Ausweg die Abnahme von Teilleistungen oder Probearbeiten an.) Die Dienstleistung wird also erst „verkauft“ und dann „produziert“. Allerdings muss eine Dienstleistung, damit sie überhaupt abgesetzt, kommuniziert und verkauft werden kann, als Objekt, d.h. als Produkt entwickelt sein. Dies kann und muss in unterschiedlichen Detaillierungsstufen geschehen, da der Kunde im Allgemeinen nur ein allgemein umrissenes Problem hat. Im Gegensatz zum physischen Produkt, das als individuelles Objekt vorlegt und nur konzeptionell in verschiedenen Allgemeinheitsgraden (Produkt, Produktlinie) existiert, ist bei einem Dienstleistungsangebot der Grad der Flexibilität sehr variabel. Je allgemeiner die Beschreibung der Dienstleistung und des Problems ist, um so besser und flexibler muss der Dienstleister sein. Diese Flexibilität muss dem nachfragenden Kunden auch kommuniziert und muss von ihm honoriert werden. Die Flexibilität betrifft aber nicht nur die zeitliche und räumliche Komponente der Dienstleistung und des Objekts, sondern vor allem die – noch schwerer kommunizierbare – Allgemeingültigkeit und Abstraktion des Dienstleistungsangebots. Transportdienstleistung Am Beispiel der Dienstleitung „Transport“ kann man die verschiedenen Stufen der Allgemeingültigkeit und Differenzierung in den verschiedenen Komponenten darstellen. • Ort: nur von A nach B – flexibel – Verteilungsnetz regional eingeschränkt – global • Objekt: nur Personen, Tiere, Güter, Post ... – universell • Zeit: fixe Zeiten (Fahrplan) – flexibel eingeschränkte Zeiten (5x8) – Vollabdeckung (7x24) • Leistung Zur Verfügung Stellen von Transportraum – gesamte Abwicklung Frachtführer – gesamte Speditionsdienstleistungen Diese Flexibilität ist ein Merkmal der Dienstleitung und verursacht Kosten.

Diese Allgemeingültigkeit spiegelt sich auch in den verschiedenen Bezeichnungen und Zulassungskriterien für Dienstleistungen wieder. Tabelle 6-3: Beispiele für verschiedene Niveaus bei Dienstleitungen allgemein/flexibel Unternehmensberatung DV-Beratung Handwerk Kfz-Wartung Lehre und Unterricht

speziell (Beispiele) DV-Beratung, Personalberatung EDV-Auswahl, Homepage-Programmierung Handwerksähnliche Arbeiten, Minderhandwerk Auspuffwechsel, Ölstandprüfung Nachhilfe, Tastaturtraining, Paukkurse

6.5 Dienstleistungen

239

Eine Dienstleistung muss als Produkt entwickelt werden. Nur dann kann der Kunde die Dienstleistung nachfragen. Da die Dienstleistung nicht vorher beurteilt und je nach Komplexität auch vorher nicht genau beschrieben werden kann, ist eine klare Konzeption (Model) und das Verständnis für die Bedürfnisse des Nutzers wichtig. Markenbildung hilft hier, Vertrauen zu schaffen. Dienstleistungen können als eignständiges Produkt oder in Verbindung mit anderen Produkten (aller Art, also auch wieder von Dienstleitungen) auftreten: • Dienstleistung als Produkt, • Dienstleistung als Produktkomponente, • Produktbegleitende Dienstleistungen. 6.5.1

Entwicklung von Dienstleistungen

Eine Dienstleistung erfordert ein Objekt. Dies können der Kunde oder seine Mitarbeiter, materielle oder immaterielle Objekte aus dem Besitz des Kunden oder neutrale Personen bzw. Objekte sein. Dienstleister

Auftragnehmer Dienstleistungsauftrag

Kunde

Erbringer der Leistung Erbringung der Dienstleistung

Auftraggeber

Objekt der Dienstleistung

Abbildung 6-7: Struktur von Dienstleistungen Wichtig ist, die Anforderungen zu verstehen, den Nutzen für den Kunden und die an den Objekten zu verrichtende Tätigkeiten zu verstehen, daraus ein Konzept zu erstellen, und die Abläufe und Interaktion mit Objekten klarzustellen. Für die Leistungserbringung ist es wichtig, das Potential bereitzustellen und zwar in Form von Personal, Infrastruktur und Sachmitteln. Knowledge-Box Der Wissenswürfel (Knowledge-Box [Biermann]) fasst die wichtigsten Komponenten einer Dienstleistung ähnlich den Kernfragen der Logistik zusammen: • WHO: Kunde der Leistung (wer entscheidet und bezahlt), • WHAT: Art und Objekt der Leistung,

240

6 Entwicklung in speziellen Produktbereichen

• WHEN: Zeitpunkt der Leistungserbringung, • WHERE: Ort der Leistungserbringung. Notwendigkeit des physischen

Kontakts oder von Fernleistungen (Teledienste), • HOW: Art der Leistungserbringung (Kundensicht) und der Leistungserstellung (Sicht des Leistenden: Entwicklung, Vorstufen, Arbeitsteilung), • WHY: Grund der Dienstleistung aus Unternehmenssicht: Produkteigenschaft (gegen Bezahlung) oder Unterstützung für andere Produkte/Ziele. Know What Know Know Know Know How Who Why Where Know When

Abbildung 6-8: Wissenswürfel für Dienstleistungen Erlebnisorientierung Erlebnisorientierung ist nicht ein Ausdruck einer „Spaßgesellschaft“ sondern eine essentielle Komponente menschlichen Lebens. Erlebnisorientierung spielt in mehreren Beziehungen eine Rolle: • Erlebnis als Produkt: Das Erlebnis wird als solches vermarktet und vom Kunden bezahlt. Der finanzielle Erfolg kommt aus dem Gegenwert des Erlebnisses. • Erlebnis als Produktkomponente: Das Erlebnis ist Teil einer Dienstleistung. Ein indirekter Effekt ist beispielsweise, dass das Erlebnis Teil des Kaufprozesses (Kauferlebnis) ist. • Erlebnis als Kommunikation: Erlebnisorientierung dient dazu, Informationen zu vermitteln. Dies basiert darauf, dass bei einem Kommunikationsprozess nicht nur die reine Information sondern das Gefühl und die Einstellung zum Sender und zur Nachricht eine Rolle spielt. Die Entwicklung von Erlebnisorientierung muss berücksichtigen, dass wie bei jedem Produkt das allgemeine Produkt und die individuelle Produktinstanz sukzessive entwickelt und geleistet werden. Dies gilt zwar für alle Produkte und Dienstleistungen, spielt aber beim Erlebnis eine besondere Rolle, da das Erlebnis stark vom Kunden und dessen Interaktion abhängt: „Das Erlebnis entsteht im Kopf des Beobachters“.

6.5 Dienstleistungen

241

Tabelle 6-4: Allgemeine und spezifische Produkte und Erlebnisse Allgemeines Produkt Physische Produkte Dienstleistung Erlebnis generell Tourismus Event, Kunst, Sport Lehrveranstaltung, Kursmodul

6.5.2

Individuelles Produkt für bestimmten Ort, Zeit, Situation Produktion und Lieferung einer physischen Instanz Erbringung der Dienstleistung für einen individuellen Kunden (spezifischer) Erleben der Situation durch einen individuellen Kunden abhängig von Ort, Zeit, Aktionen, Personen Besuch eines Orts (location) durch einen individuellen Kunden mit oder ohne Führung. Erleben der Veranstaltung, Aufführung, ... durch den Besucher (vergleiche das Kapitel Kunst) Lehrveranstaltung/Seminar mit einen konkreten Zuhörerkreis, Ambiente und Anspruch (Ziel)

Klassische Dienstleistungen

Unter dem Thema klassische oder traditionelle Dienstleistungen, grenzen wir Dienstleistungen, Informationsbereitstellung und Logistik ab gegen Produkte wie Beratung, Event, Kunst und Lehre. Die Grenze ist natürlich fließend und die Arten von Dienstleistungen können kombiniert werden, was sogar den Erfolg von Dienstleistungen erhöht: Integrierte Dienstleistungen („aus einer Hand“) bieten dem Kunden einen Vorteil, da er nur einen Ansprechpartner hat (Reduktion des Aufwands) und sich nicht um die Schnittstellen zwischen den Aufträgen kümmern muss (Reduktion des Risikos). Dienst am Kunden Die Prototypen der Dienstleistung, die für eine Kunden eine direkte Dienstleistung erbringen, wie Friseure, Handwerker, Ärzte oder Lehrer, sind bekannt und selbsterklärend. Die Dienstleistungen sind teilweise durch gesetzliche oder interne Regeln festgeschrieben. Die genaue Gestaltung von einzelnen Dienstleistungen sollte aber Objekt einer systematischen Konzeption sein. Die verschiedenen Kundenrollen spielen hier eine wichtige Rolle. Der Rahmen für die Produktentwicklung ist häufig durch traditionelle Konzepte der Dienstleistung vorgegeben, aber durch intelligente Konzepte und eine systematische Entwicklung lassen sich neue Felder erschließen oder klassische Bereiche durch lukrative Angebote ergänzen.

242

6 Entwicklung in speziellen Produktbereichen

Information Information an sich ist keine Dienstleistung, sie ist als Produkt eher dem Umfeld Software (nichtmateriell) zuzuordnen. Die Beschaffung (Recherche) und Bereitstellung von Information (Informieren) ist aber eine Dienstleistung. Sofern es sich bei der zu beschaffenden Information nicht nur um Daten handelt, sondern um Wissen, besteht ein Problem darin, dass der Kunde zuvor noch nicht weiß, welche Information er braucht. Die Hilfe zur Fragestellung und die Begriffsabgrenzung sind deshalb ebenso wichtig. Erst mit der Zeit wird die Wissensstruktur klar (vergleiche die Ausführungen zum Wechselspiel zwischen Modell und Erfahrung im Kapitel Modellbildung). Logistik und Handel Hier betrachten wir Dienstleistungen die nicht mit der physischen Veränderung eines Produkts zu tun haben, wohl aber mit meist physischen (auch abstrakten) Produkten, Waren und Gütern. Dabei können wir zwei Bereiche unterscheiden: • Transport und Logistik (Schwerpunkt auf der Transformation), • Handel und Markt (Schwerpunkt auf dem Eigentumsübergang). Logistik

Logistik bedeutet eine Transformation des Objekts in Raum (Transport), Zeit (Lagerung) und Ordnung (Sortierung). Logistik als Dienstleistung kann sich aus diesen Komponenten Transport, Lagerung und Sortierung zusammensetzen. Das Logistikprodukt muss als ganzes betrachtet werden. Dabei ist festzulegen, welche Teile der gesamten Logistikkette abgedeckt werden sollen. Markt

Ein Markt ist eine Dienstleistung, bei der ein Marktbetreiber die Angebotsseite und Nachfrageseite für ein Gut (Ware) zusammenbringt. Dabei stehen nicht die logistischen Aspekte im Vordergrund, sondern der Übergang des Eigentums vom Anbieter (Verkäufer) zum Nachfrager (Käufer). Dies kann physisch oder virtuell sein: • physisch-physisch: Käufer, Verkäufer und Ware sind auf dem Marktplatz präsent, • physisch-virtuell: Käufer und Verkäufer treffen sich, die Ware ist nicht auf dem Marktplatz, • virtuell-virtuell: Käufer und Verkäufer treffen sich nicht. Wer einen Marktplatz entwickeln und anbieten will, muss sich klar sein, dass hier eine zweistufige Kundenstruktur vorliegt:

6.5 Dienstleistungen

243

Tabelle 6-5: Rollen beim Marktplatz Rolle bei der Bezüglich des geTransaktion handelten Gutes Angebotsseite Anbieter, Lieferant, Verkäufer NachfrageNachfrager, seite, Kunde Kunde, Käufer

Bezüglich des Marktes Implementierer des Marktplatzes als Dienstleister (Betreiber, seltener als Verkäufer/ Vermieter eines fertigen Marktplatzes) Anbieter, der für die Möglichkeit der Präsenz auf dem Marktplatz bezahlt (seltener der Nachfrager).

Handel

Beim Handel liegt im Gegensatz zur Logistik der Schwerpunkt darauf, dass als Dienstleistung eine Ware (Gut) beschafft, vorgehalten und an den Kunden verkauft wird. Der Handelstreibende (Kaufmann) ist also typischerweise Eigentümer der Ware. Der Nutzen für den Kunden liegt nicht nur in dem Produkt selbst, sondern in dessen Verfügbarkeit. Schrauben und Montage Die Bereitstellung von Montagematerialien durch industrielle Dienstleister hat neben den Aspekten eines Handels wichtige Logistikkomponenten. Für den Kunden spielt die rechzeitige und verlässliche Verfügbarkeit des Produkts eine viel wichtigere Rolle als der Preis, da die Beschaffung oder die Folgen eines eventuellen Fehlens (z.B. einer Schraube) viel höhere Kosten verursachen kann als das Produkt selbst kostet.

Instandhaltung als Dienstleistung Die Instandhaltung eines Produkts oder Systems kann teilweise oder ganz mit dem Produkt gekoppelt sein oder eine eigenständige Dienstleistung darstellen. Die Instandhaltung eines Produkts oder Systems stellt die Qualität (Zuverlässigkeit, Verfügbarkeit) des Produkts über einen längeren Zeitraum sicher. Die Instandhaltung beinhaltet folgende Maßnahmen: • Wartung: vorbeugende Maßnahmen zur Erhaltung des Sollzustands, • Inspektion: Überprüfung des Zustands, • Instandsetzung. Wiederherstellung des Soll-Zustands. Wartung ist die Bezeichnung für Maßnahmen zur Bewahrung des Sollzustandes eines Systems. Neben Hardwaresystemen, bei denen Verschleiß auftritt, müssen auch Softwaresysteme gewartet werden (Erhaltung der Funktionalität).

244

6 Entwicklung in speziellen Produktbereichen

Wartung kann im System folgende Aufgaben haben: • Vorbeugung und Korrektur von negativen Veränderungen am System, • Beseitigung von im Laufe des Betriebs erkannten Fehlern, • Anpassung an veränderte Einsatzbedingungen (Schnittstellen), • Verbesserung von Eigenschaften, Anpassung an gestiegene Anforderungen. Der Entwurf der Instandhaltung als Dienstleistung kann generell über die Beauftragung im Einzelfall oder über Rahmenverträge gehen. Auslöser sind dann: • Inspektion: Regelmäßige (Inspektionsintervalle nach Kalenderzeit, Laufzeit oder erbrachter Leistung) oder durch bestimmte Ereignisse (z.B. spezielle Systemzustände) ausgelöste Überprüfung. • Wartung: Regelmäßige (Wartungsintervalle nach Kalenderzeit, Laufzeit oder erbrachter Leistung) oder durch bestimmte Ereignisse (Systemzustand, Ergebnis einer Inspektion) ausgelöste Maßnahmen zur Erhaltung oder Verbesserung des Systemzustands. • Instandsetzung, Reparatur: Durch Fehler ausgelöste Wiederherstellung des Sollzustands. Instandhaltung als Dienstleistung geht von dem Gedanken aus, dass der Kunde das System möglichst ungestört nutzen will. Das Versprechen hinter der Instandhaltung ist: „365 Tage und 24 Stunden Verfügbarkeit“, meist „24/7“ d.h. „7 Tage in der Woche 24 Stunden am Tag“. Je höher die Verfügbarkeit sein soll, um so aufwändiger wird die Instandhaltung. Instandhaltung als Dienstleistung kann dem Kunden ein bestimmtes Niveau an Verfügbarkeit sicherstellen, ohne dass er sich um die für ihn optimale Abwägung zwischen Wartung und Inspektion einerseits und Instandsetzung im Fehlerfall andererseits kümmern muss. Durch Bereitstellen von Ersatzfunktionen (Ersatzgerät, überbrückende Leistungen, Pufferung bzw. Speicherung) kann der Dienstleister die angestrebte Verfügbarkeit im Allgemeinen sogar noch viel einfacher erreichen. 6.5.3

Beratung und Entwicklung Wissen schaffen als Auftrag

Wichtige Komponenten der Beratung wie Auftragsentwicklung und Entwicklung von Systemen und Konzepten wurden bereits behandelt. Beratung beinhaltet aber mehr, sie hat vor allem Entscheidungskomponenten. Beratung Beratung als Produkt ist sehr komplex und noch schlechter beschreibbar als andere. Die prinzipielle Dienstleistung eines Steuerberaters kann man sich

6.5 Dienstleistungen

245

noch vorstellen, zumindest wenn man darunter die Erstellung der Steuererklärung versteht. Eine komplexe Beratung, Unternehmensberatung oder technische Beratung ist aber als Produkt schwerer abgrenzbar. Dies zeigen auch die klassischen Witze: „Ein Unternehmensberater ist jemand, der sich deine Uhr leiht und dir gegen ein Honorar sagt, wie spät es ist.“ Die Informationen, wo die Probleme im Unternehmen liegen, können nur aus dem Unternehmen selbst kommen. Die Strukturierung, Abstraktion und Lösungsfindung ist im Nachhinein gesehen scheinbar trivial. Umso schwerer und wichtiger ist es, Inhalt und Qualität einer solchen Dienstleistung zu beurteilen und zu kommunizieren. Forschung Forschung kann Teil des Entwicklungsprozesses sein. Forschung ist wie Entwicklung eine spezielle Art Dienstleistung. Ziel wissenschaftlichen Arbeitens ist die Gewinnung neuer Erkenntnisse. Für die Planung der Arbeit ist ein Phasenkonzept wichtig. Wir wollen hier kein allgemeingültiges Phasenkonzept aufstellen, sondern mit einfachen Phasenkonzepten starten.

Tabelle 6-6: Phasenkonzepte wissenschaftlicher Arbeit Allgemein • Sammlung, Strukturierung • Hypothesenbildung • Modellierung • Überprüfung der Hypothese • Analyse der Konsequenzen Induktive Hypothesenbildung • Beobachtungen (Daten) • Hypothese als Generalisierung • Überprüfung der Hypothese • Einbindung in Theorie

Aufgabenbasiert • Aufgabenstellung • Vorbereitung • Durchführung • Auswertung • Dokumentation Deduktive Hypothesenbildung • Allgemeine Theorie • Hypothese als Anwendung • Experimentelle Überprüfung • Anpassung der Theorie

Entwicklung als Dienstleistung Auch die Entwicklung von Produkten und Konzepten kann als Dienstleistung erbracht werden. Dabei besteht ein fließender Übergang von der Produktentwicklung (ohne Produktion) und Softwareerstellung bis zur reinen Ideenentwicklung (Produkte, Marken). Letztendlich kann ja jeder Schritt des Produktentstehungsprozesses, jedes Arbeitspaket als Auftrag vergeben werden.

246

6 Entwicklung in speziellen Produktbereichen

Bei Entwicklung als Dienstleistung ist wichtig, dass die Informationen über Kundenanforderungen und Einsatzbedingungen, Implementierungsbedingungen und Markteinschränkungen nicht verloren gehen bzw. dass die Anforderungen an das Entwicklungsergebnis so klar beschrieben werden können, dass die Lösung auch umgesetzt werden kann. 6.5.4

Veranstaltungen Erlebnis als Produkt und Komponente

Die bereits betrachtete Erlebnisorientierung wird als Teil des Produkts und des Kaufs, als Mittel der Kommunikation und als Produkt immer wichtiger. Veranstaltungen sind ein Beispiel für Dienstleistung, sie zeichnen sich aber dadurch aus, dass die Leistung Veranstaltung für eine größere Anzahl Kunden erbracht wird. Evententwicklung Die Organisation eines Events ist eine wichtige und verantwortungsvolle Aufgabe. Sie kann aber nur zum Erfolg führen, wenn das Event selbst systematisch konzipiert wurde. Die Entwicklung eines Eventkonzepts geht aus von dem Nutzen, den man aus dem Event ziehen möchte und leitet die Anforderungen an das Event ab. Nun müssen die verschiedenen prinzipiellen Möglichkeiten zusammengestellt und kombiniert werden und eine Entscheidung für die Gestaltung des Events muss getroffen werden. Dabei muss sich das Event an den Eventzielen, der Unternehmensstrategie und den Rahmenbedingungen der Veranstaltung orientieren. Events Planung und Durchführung von Veranstaltungen ist für Unternehmen und andere Institutionen in vielerlei Hinsicht wichtig. Beispiele solcher Veranstaltungen sind: • eigenständige kommerzielle oder nichtkommerzielle Veranstaltungen (Sport, Kultur, Tourismus, Edutainment), • Veranstaltungen im Rahmen der Tätigkeit einer Organisation (Feste, Tage der offenen Tür), • Seminare, Tagungen, Versammlungen, Sitzungen. Typisch für Veranstaltungen ist: • Direktes Produkt ist die Veranstaltung selbst. • Das Produkt kann weder gelagert noch nachgebessert werden. • Der Nutzen entsteht teilweise erst nach der Veranstaltung. • Das Erlebnis lebt von der (Re-) Aktion der Beteiligten.

6.5 Dienstleistungen

247

Der Erfolg hängt von vielen subjektiven Faktoren ab. Der Hauptaufwand liegt in der Planung und Vorbereitung. Im Allgemeinen sind viele Personen mit eingebunden. Bei Veranstaltungen spielt die Logistik eine sehr große Rolle. Veranstaltungen sind einmaliger Ereignisse mit hohem Risiko. In der Vorbereitung ist auch das Umfeld zu planen. Die Evententwicklung (Entwicklung des Eventkonzepts und der Eventplanung) ist nur ein Teil des Eventmanagements, dessen Ziel ja das Event selbst ist. • • • • • •

Ergebnis = Event-Konzept

Ressourcen = Planungsaufwand

Zeit = Termin für die Vorlage der Konzeption

Abbildung 6-9: Magisches Projektdreieck der Evententwicklung Anforderungen Anforderungen an das Event kommen von verschiedenen Seiten: durch die große Öffentlichkeitswirkung des Events gibt es viele Anspruchsgruppen. Stakeholder Bei der Entwicklung eines Events müssen die Anforderungen der Stakeholder (Anspruchsgruppen) wie Bürger, Kommune und deren Vertreter, Nachbarn und Vereine, Interessengruppen, Berufsverbände, Gewerkschaften, Firmen, Lieferanten, Kunden und Presse betrachtet werden. Wichtig ist, interessierte Gruppen (Stakeholders) zu identifizieren und ihre Anforderungen an das Event, ihre Wünsche und Ängste, Einflussmöglichkeiten und Nutzen für das Event zu erfassen. Die Erfassung der Ziele von Stakeholdern ist wichtig, um aus potentiellen Gegnern möglichst Verbündete oder Unterstützer zu machen. Gerade bei einem Event, das vom Erleben lebt, können Misstöne um Umfeld oder Vorfeld verheerende Auswirkungen haben. Organisatoren und Träger Träger einer Veranstaltung ist entweder eine Organisation (Unternehmen, Verein, Behörde) bzw. eine Unterorganisation (Betrieb, Abteilung, Gruppe) oder eine Gruppe von Organisationen. Im zweiten Fall ist genau zu klären,

248

6 Entwicklung in speziellen Produktbereichen

wer welche Rolle hat. Auch die juristische Form und die Rechte und Pflichten in diesem Vorhaben sind zu klären. Die beteiligten Unternehmen bilden durch dieses „joint venture“ meist automatisch eine GbR (Gesellschaft bürgerlichen Rechts) für die Durchführung der Veranstaltung. Auch innerhalb der Organisation gibt es verschieden Gruppen von Interessierten (Stakeholders): • alle Ebenen des Managements (über und unter derjenigen Ebene, die als Träger auftritt), • alle Mitarbeiter des Bereichs, der Verantwortung für das Event trägt, • alle Mitarbeiter im ausführenden Bereich, die die Arbeit machen oder davon tangiert sind (z.B. dadurch dass sie die Arbeit der für das Event eingeplanten Mitarbeiter übernehmen), • alle Mitarbeiter im Marketing und sonstigen Bereichen, die sich (hoffentlich positive) Auswirkungen vom Event versprechen. 6.5.5

Tourismus und Gastronomie

Die Hauptkomponenten des Tourismus-Angebots sind Reise und Aufenthalt, die Dienstleistung ist gekennzeichnet durch die Bindung an einen bestimmten Raum (Destination als Gebiet, Ort, Haus). Daneben gibt es Kombinationen mit anderen Komponenten, beispielsweise Erlebnisgastronomie oder Bildungstourismus. Kochrezept Wie entwickelt man ein Kochrezept? Im Allgemeinen wird evolutionär vorgegangen, d.h. es wird ein vorhandenes Rezept modifiziert oder vorhandene Rezepte kombiniert. Anforderungen an ein Gericht können sein: regional, saisonal, ökologisch, preiswert, fettarm, vitaminreich, schmackhaft. Ebenso können bestimmte Geschmacksrichtungen, Kalorien- und Nährstoffgehalt, Größe, Haltbarkeit, Servierbedingungen (Tellergericht, Buffet, fingerfood, ...) oder Anlässe vorgegeben werden. Da sich die Erfüllung vieler dieser Anforderungen aus den Zutaten (Rohstoffen) und der Zubereitungsart (Prozess) herleiten lässt, kann man bei der Entwicklung in dieser Reihenfolge vorgehen. So lässt sich eine Morphologische Matrix aus essentiellen Zutaten und Zubereitung aufbauen, die auch bei der Gestaltung einer Menüfolge (Prinzip der Abwechslung) genutzt werden kann.

6.5.6

Darstellende Kunst und Erlebnis

Die darstellenden Künste bauen ebenso wie die Lehre auf einem zweistufigen Entwicklungskonzept auf: Auf der allgemeinen Erstellung des Stücks

6.5 Dienstleistungen

249

baut eine zweite Phase der konkreten (auf einen bestimmten Zeitpunkt, Raum und Zielgruppe bezogenen) Implementierung auf. Hier handelt es sich nicht um die Abfolge von Entwicklung und Produktion, sondern um eine zweistufige Entwicklung. Insbesondere in der zweiten Stufe ist die Eventkonzeption gefragt. Tabelle 6-7: Produkt und Umsetzung Allgemeine Spezifikation: unabhängig von Ort und Zeit Stück, Drehbuch Autor Komposition (Lied, Oper) Komponist Drehbuch, Vorlage – Film Autor – Regisseur Objekte der Bildende Kunst Künstler (Lehr-) Buch Autor

Spezielle Spezifikation: für bestimmten Ort, Zeit, Publikum Aufführung Regisseur Aufführung Dirigent, Chorleiter Kinovorführung (speziell: Premiere) Betreiber Ausstellung, Präsentation (Vernissage) Aussteller (Vor-) Lesung Dozent

Umwelttheater Als Beispiel sei hier die Entwicklung eines Theaterstücks zu einem Thema aus dem Bereich Umwelt dargestellt [Vortisch]: • erster thematischer Umgang mit dem Thema anhand des Grundrepertoires • neue Sichtweise durch die körper- und bewegungsorientierte Darstellung des Themas (Reflexion) • Erweiterung des Grundrepertoires durch Theatermaterialien und Musik (Aktion) • erste Ideen und Inspiration für eigene szenische Bilder (Reflexion) • das Grundrepertoire zum Spezialgebiet: Wasser, Energie, Abfall usw. (Aktion) Man erkennt hier ein Phasenkonzept und die sukzessive Konkretisierung.

6.5.7 Lehre und Edutainment

Jede Lehreinheit vom kurzen Vortrag bis zum 10-semestrigen Kurs sollte systematisch aufgrund der Anforderungen aller Kunden entwickelt werden. Dabei ist für den Vortragenden der Kunde primär der Zuhörer (Kursteilnehmer), sekundär der Beauftragende (Kursträger). Für eine komplexere Ausbildungsstruktur sind auch die zukünftigen Arbeitgeber der Auszubil-

250

6 Entwicklung in speziellen Produktbereichen

denden und die Träger der Bildungseinrichtung als wichtige Kunden (oder Anspruchsgruppen) zu berücksichtigen. Lehrveranstaltung und Präsentation Auch für die Vorbereitung eines Vortrags, einer Unterrichtseinheit oder einer Lehrveranstaltung sind die Konzepte des Entwicklungsmanagements hilfreich. Klare Ziele in Form des zu erwerbenden Wissens bzw. der Kompetenzen und eine Abstufung der Kriterien MUSS - SOLL – KANN bilden die Basis der Planung. Sich über die Ziele klar zu werden bedeutet auch: • Eigene Ziele kennen: Was will ich erreichen? Wofür mache ich mir die Arbeit? Nach welchen Kriterien werde ich bewertet? Welche Informationen, Wissen, Kompetenzen und Einstellungen will ich vermitteln? • Ziele des Zuhörers analysieren: Warum kommt er? Wofür zahlt er bzw. investiert er seine Zeit? Was erwartet er? Was nützt ihm? Was muss er nach der Veranstaltung mitnehmen? • Ziele des Veranstalters/Trägers analysieren: Wozu organisiert er den Vortrag? Wofür zahlt er das Honorar? Was müssen die Zuhörer aus seiner Sicht an Informationen, Wissen, Kompetenzen und Einstellungen vermittelt bekommen? Welche Erfolgskriterien sind für ihn relevant? Curricularentwicklung Für alle Arten übergeordneter Entwicklung von Einheiten wie Vortragsreihen, Kurse und Studiengänge oder ganzer Bildungssysteme ist ein analoges Vorgehen notwendig. 6.5.8

Managementaspekte

Die systematische Produktentwicklung kann hier nicht das Produkt, sondern nur die Produktkategorie festlegen. Sie muss den Erbringer der Dienstleistung und die Unterstützer (Backoffice, Support) zur Leistungserbringung befähigen. Bei Dienstleistungen sind die zeitliche Planung (wegen der fehlenden Lagerungsmöglichkeit) und die Preisgestaltung immens wichtig. In der Kontrahierungspolitik wird versucht, durch frühe Festlegung des Kunden eine verlässliche Basis für die Erbringung der Dienstleistung zu schaffen, damit die Kapazitäten an den Bedarf angepasst werden können. Da Dienstleistungen mit Menschen als Objekt zu tun haben (meist der Kunde, aber auch im Fall einer an einer anderen Person erbrachten Dienstleistung) spielen persönliche Aspekte eine extrem wichtige Rolle.

6.6 Dokumentationen

251

6.6 Dokumentationen Zwischen Kunst und Kommerz

Dokumente spielen nicht nur als Ergebnis des Entwicklungsprojekts eine Rolle, sie sind auch eigenständige Produkte. 6.6.1

Dokumente Das Papier ist das Produkt

Nicht nur in der Wissenschaft spielen Publikationen als Abschluss eines Projekts und Dokumentation der Leistung eine wichtige Rolle. Die Produktdokumentation ist in allen Bereichen wichtig, teilweise ist das Dokument aber auch das eigentliche eigenständige Produkt, z.B. ein Buch. Wir haben also zwei prinzipielle Arten: • Ergebnisse von Forschung, Recherchen, Entwicklungen, • Handbücher und Technische Dokumentationen als Teil materieller oder immaterieller Produkte. Ein eigenständiges Dokument wird nicht – wie eine Spezifikation oder Konstruktion – als Basis der physischen Produktrealisierung genommen, sondern „nur“ mit einem materiellen Träger versehen oder als Information zur Verfügung gestellt. Damit sind an ihre Ausrichtung an Markt und Zielgruppe ganz andere Anforderungen zu stellen, als an entwicklungsbegleitende Dokumente: solche Dokumente sind ein eigenständiges Produkt. Dokumente können im Pull-Prinzip (Aussendung, Aufführung, Verteilen) oder im Push-Prinzip (Bereitstellung auf einem Server, Abruf, Anforderung) verbreitet (implementiert) werden. Ob man hinter einem Buch nur das immaterielle Produkt oder auch die physische Implementierung sieht, hängt sicher auch von Inhalt und Form ab. 6.6.2

Film, Ton, Kunst

Kunst ist dort Entwicklung, wo ein Dokument oder eine Konzeption erstellt wird. In der Bildenden Kunst haben wir ganz klar ein Produkt. In der bereits bei den Veranstaltungen betrachteten darstellenden Kunst haben wir den zweistufigen Prozess, in dem zunächst ein Konzept als Produkt entwickelt und dieses dann als Erlebnis entwickelt und umgesetzt wird.

252

6 Entwicklung in speziellen Produktbereichen

Video zur Geologie Für einen Lehrvideo „Geologie und Wirtschaft“ wurden zunächst Ideen gesammelt, wie die Geologie die Ökologie und Ökonomie beeinflusst. Aus den verschiedenen Strukturierungsprinzipien (Rohstoffe, Industriezweige, Produkte, Geologische Schichten) wurde ein didaktisch sinnvolles Konzept entwickelt, das die verschienen geologischen Altersstufen mit jeweils einem Hauptmedium (Erz, Wasser, Sand) und einem prototypischen Produkt kombiniert. Anschließend wurden die wichtigsten Abläufe (jeweils von der geologischen Grundlage über Rohstoff und Verarbeitung zum Produkt und dessen Einsatz) aufbereitet. Dreharbeiten und Schnitt schließen das ganze ab.

Ein weiterer interessanter und wichtiger Bereich ist die Bildende Kunst, die ja physische Produkte hervorbringt. Allerdings sind die Kriterien und Entwicklungsschritte andere als bei der Hardware. Ein fließender Übergang ist durch Begriffe wie „Industriedesign“ oder „Gebrauchskunst“ gegeben und künstlerische Gestaltung und Zielorientierung müssen sich durchaus nicht ausschließen. 6.6.3

Managementaspekte

Die hier betrachteten Bereiche wurden seither eher weniger als Objekte formaler Entwicklungsprozesse gesehen. Durch steigende Qualitätsanforderungen nimmt hier der Aspekt systematischer Entwicklung zu. Durch die Integration von Kreativität und Systematik entstehen herausfordernde Aufgaben. Eine Überreglementierung wirkt aber eher hemmend.

7

Methoden und Modelle Struktur als Grundlage der Entwicklung

Die Entwicklung baut auf Modellen auf. Dies können sein: • Modelle des zu entwickelnden Produkts auf verschiedenen Abstraktionsbzw. Konkretisierungsstufen, • Modelle von Einsatzumgebung, Schnittstellen und Anforderungen, • Modelle des Entwicklungsprozesses. In diesem Kapitel betrachten wir die Grundlagen der Modellbildung sowie einige allgemeine Modelle und Systembetrachtungen, die für Produkte und Management gleichermaßen wichtig sind. Die im Folgenden dargestellten Methoden sind nicht auf die Entwicklung beschränkt. Diese Methoden können im Management ebenso eingesetzt werden. Dies beruht zum einen darauf, dass Projektplanung und Strategiekonzeption auch als Entwicklungsprojekte betrachtet werden können, zum anderen darauf, dass diese Methoden so allgemein sind, dass sie einen breiten Einsatzbereich zur Konzeption und Problemanalyse haben. Der allgemeine Ansatz ist dabei das modellbasierte Problemlösen.

7.1 Modellbasiertes Problemlösen Abstraktion löst den Gordischen Knoten

Sowohl Entwicklung als auch Management beschäftigen sich auf verschiedenen Abstraktionsebenen mit zwei Arten von Problemen: • Entscheidungen (z.B. Auswahl zwischen Alternativen oder Wahl eines geeigneten Parameters oder Verfahrens), • Strukturschaffung (Konzeption einer Struktur für ein existierendes oder zu schaffendes Objekt. Dabei soll nicht nur die explizite Strukturinstanz, sondern die Art der Struktur und das Strukturierungsprinzip festgelegt werden). Beide Arten von Aufgaben erfordern Modelle, wobei die Strukturschaffung viel komplexer ist. Zum einen beinhaltet ihr Ergebnis ja Modelle für Entscheidungsprozesse und diese wiederum Modelle für Entscheidungen, zum andern ist das Ergebnis einer Entscheidung ein einfaches Element (im Extremfall ja/nein, in komplexeren Fällen eine oder mehrer Zahlen) während Strukturentscheidungen Netze, Graphen mit einer Kombination von verschiedenen Beziehungen, Dynamik auf verschiedenen Zeitskalen und Szenarien beinhalten können.

254

7 Methoden und Modelle

Modelle in Management und Entwicklung Wir betrachten zwei Beispiele für die verschiedenen Abstraktionsebenen aus den Bereichen Management (Strukturierung einer Firma) und Entwicklung (Entwurf eines Autos). Die am einfachsten strukturierten Entscheidungen betreffen die Bestimmung vom Merkmalen oder Zahlen nach einem Baukastenprinzip: Die Struktur ist vorgegeben, die „Kästchen“ sind nur noch auszufüllen: • Wer leitet die Abteilung A3.2? Wer genehmigt Dienstreisen? • Aus welchem Material soll das Lenkrad sein? Wie viel PS sollen unsere Motoren haben? Strukturentscheidungen betreffen das Modell des Objekts, sie überschreiten das „Kästchendenken“ und erlauben neue Prinzipien. Der Abstraktion sind dabei nach oben keine Grenzen gesetzt: • Stablinienstrukturen oder Matrixmanagement → wie wollen wir führen? • Elektromotor, steer-by-wire, Luftkissen → was ist für uns „ein Auto“? • Vernetze cost center statt Hierarchien → was ist „eine Firma“? • Plattformkonzepte und Mobilitätskonzepte → was ist unser Produkt?

Problemlösung erfordert ein Modell. Beispiele zum Vorgehen bei der Problemlösung sind: • Probleme mit Hilfe der Mathematik zu lösen, • Probleme mit Hilfe des Computers (inkl. Simulation) zu lösen, • kognitive Problemlösung (Nachdenken), • kommunikative Problemlösung (Unterhaltung, Diskurs). 7.1.1

Modelle und Systeme

Wir wollen nun eine vorläufige Erklärung der mit der Modellbildung zusammenhängenden Begriffe geben. Dazu stellen wir einige Aussagen über Systeme und Modelle nebeneinander.

Realität System

Modell

Abbildung 7-1: System und Modell

Mathematisches System

7.1 Modellbasiertes Problemlösen

255

• Ein System ist ein Teil der Realität, charakterisiert durch die Gesamtheit

seiner Teile und die zwischen ihnen herrschenden Beziehungen (Relationen). Der Begriff des Systems stellt schon eine Abstraktion dar, da die Abgrenzung eines Teils der Realität ja nur gedanklich erfolgt. • Ein Modell ist ein abstrahiertes und mehr oder weniger formalisiertes Bild (Abbild) eines Ausschnitts und Teilaspekts der Realität, das dazu dient, Ergebnisse über das Realsystem zu erhalten. − Das Modell ist realitätsbezogen, d.h. nur durch seinen Bezug zur Realität von Bedeutung (andernfalls haben wir ein allgemeingültiges von der Realität unabhängiges mathematisches System). − Das Modell ist zielgerichtet, d.h. zu einem bestimmten Zweck erstellt. Das Modell dient dazu, Probleme effizienter zu lösen oder Ergebnisse einfacher zu bekommen, als dies unter Benutzung des Realsystems möglich wäre, wobei sich Problemlösung und Ergebnis auf das Realsystem übertragen lassen. − Ein Modell ist eine formale Repräsentation (Darstellung) eines Systems. Das Modell stellt alle für den Zweck des Modells wichtigen Zusammenhänge dar. • Unter einem mathematischen System versteht man ein mathematisches Modell für eine Klasse von Systemen. Ein mathematisches System bezieht sich im Gegensatz zum Modell nicht auf ein bestimmtes Realsystem sondern auf abstrakte Begriffe und hat deshalb keine oder nur eine sehr abstrakte Semantik. Das mathematische System steht also zwischen mathematischen Strukturen (ohne jegliche Semantik) und Modellen (mit Semantik). 7.1.2

Problemlösungsprozess

Wir wollen die Modellbildung im Kontext der Problemlösung betrachten. Anhand des Modells wird eine Modellösung erarbeitet, die dann in die Realität umgesetzt (implementiert) wird. Die Problemlösung wird im Problemlösungsdiagramm in einzelne Schritte aufgeteilt: • Modellierung (Modellbildung): Sie erzeugt aus der Aufgabenstellung (bzw. der Realität) ein Modell. • Problemmodellierung: Formulierung des realen Problems (Fragestellung, Zielsetzung) im Rahmen des Modells. • Lösung: Innerhalb des Modells wird das Problem dann (mit mehr oder weniger formalen Methoden) analysiert und gelöst. Ein Modell der Lösung wird erstellt.

256

7 Methoden und Modelle

• Implementierung: Sie setzt diese Modelllösung in die Realität um und

liefert damit die Lösung für das Ausgangsproblem.

Reale Lösung

Reales Problem Modellbildung Problem-Modell

Implementierung Lösung

Lösungs-Modell

Abbildung 7-2: Modellbasiertes Problemlösen Programme als Modelle Die Softwareentwicklung ist ein klassisches Beispiel für Modelltransformation und auch für den Versuch, diese zu automatisieren. So kann in einfachen Fällen aus „fast natürlichsprachigen“ Beschreibungen Code generiert werden. Ein Programm kann gesehen werden als ein Modell, dass auf einem Computer ausführbar ist. Damit wird die automatische Transformierbarkeit einer Spezifikation in Maschinencode (durch Compiler und/oder Interpreter) zum Kriterium für ein Programm, auch eine „fast natürlichsprachige“ oder eine graphische Beschreibung oder eine Sammlung von repräsentativen Falldaten kann zur Programmierung eines Computers dienen.

7.1.3

Andere Modelle

Für den Entwicklungsprozess sind natürlich neben Objektmodellen und Modellen als Produkt auch noch ganz andere Modelle wichtig: • Phasen und Zyklen, Ablaufmodelle (Phasenmodelle), • Kostenmodelle, • Kommunikationsmodelle in Projekt und Linie, • Konfigurations- und Dokumentenmanagement: Metamodellierung, Modellierung der Modellstruktur. Diese wurden bereits in den einzelnen Kapiteln zum Entwicklungsprozess und zur Planung, Organisation und Überwachung von Entwicklungsprojekten betrachtet.

7.2 Modelle

257

7.2 Modelle So abstrakt wie nötig

Verschiedene Typen von Entwicklung benötigen verschiedene Modelle. Für den Entwickler und den Manager ist es wichtig, die Vielfalt der Modelle zu kennen, um das richtige auszuwählen. Auch die Beschreibung des Entwicklungsprozesses und des Managementprozesses beruhen auf Modellen. 7.2.1

Modellvielfalt

Die Modellierung, d.h. die Umsetzung realer Gegebenheiten in formale Beschreibungen spielt eine wichtige Rolle in der Systementwicklung, da Spezifikationen und ihre korrekte Umsetzung eine wichtige Rolle spielen. Man kann Entwicklung auffassen als einen Teilschritt des modellbasierten Problemlösens, bei dem die Problemlösung darin besteht, das Problemmodell in ein Produktmodell umzusetzen und das Problem anhand dieses Modells zu lösen. Eine entscheidende und häufig vernachlässigte Rolle beim Problemlösen spielt die Auswahl des Modells. Wer die Vielfalt der Modelle nicht kennt und anzuwenden weiß, läuft Gefahr, in ausgetretenen Gleisen zu marschieren und Alternativen zu übersehen. Wenn man sich nicht die Vielfalt der Klassen möglicher Modelle und Strukturen vor Augen hält, wird man dazu tendieren, alle Systeme in eine einzige (bekannte und gewohnte) Struktur abzubilden, und so das Problem bzw. System der vorgegebenen Struktur oder Modellklasse anzupassen. Dies bewirkt eine Anpassung des Modells (der modellierten Realität) an den Formalismus (Klasse des Modells) und kann dazu führen, dass bestimmte Aspekte der Realität nicht wahrgenommen werden. Diese Anpassung der (wahrgenommenen) Realität an das (durch seine Struktur vorgegebene) Modell verzerrt die Realität und führt zu einer in der Realität unbefriedigenden Lösung (Prokrustes-Methode). 7.2.2

Klassifikationskriterien

Es gibt sehr viele Kriterien oder Aspekte, nach denen man Modelle und Modellklassen charakterisieren kann. Diese Kriterien sind zum Teil überlappend oder nur für spezielle Klassen von Modellen gültig. Die Kriterien lassen sich einteilen nach • Darstellung (Syntax), • Bezug zur Realität (Semantik), • Nutzung (Pragmatik) des Modells.

258

7 Methoden und Modelle

Syntax Modelle können - ohne Bezug zur dargestellten Realität - nach der Explizitheit, der Art der Darstellung und nach dem Grad der Formalisierung und Abstraktheit charakterisiert werden. Die formalen Modelle unterscheiden sich nach den verwendeten Symbolen und nach dem verwendeten Formalismus (z.B. Graphen, Texte oder abstrakte Symbole). Wir werden des bei den Modelklassen und Charakteristika ausführlich betrachten. Semantik Nach dem semantischen Inhalt der Modelle können wir Modelle zunächst einmal danach klassifizieren, welches reale System oder Problem betrachtet wird. Wir können aber auch eine Einteilung danach vornehmen, welcher Ausschnitt des Systems betrachtet wird, und was die wichtigsten Aspekte oder Perspektiven sind, die berücksichtigt wurden. Ein Modell kann ja niemals "alles" abbilden und die Arten der Einschränkung sind vielfältig. Pragmatik Nach der geplanten Nutzung des Modells können wir grob unterscheiden: • Beschreibungsmodelle: Monitor-, Erklärungs- oder Vorhersagemodelle, • Gestaltungsmodelle: optimierend oder Entwurfsmodelle für etwas noch zu Schaffendes. Der Zweck des Modells (Nutzen) ist unabhängig von der Art des Modells. Allerdings eignen sich spezielle Typen von Modellen besser für bestimmte Zwecke als andere, so dass der Zweck des Modells Ausgangspunkt der Modellierung sein muss. Nach dem Zweck des Modells können wir deskriptive (beschreibende) Modelle, kausale (erklärende) Modelle, prognostizierende (vorhersagende) Modelle, optimierende (Entscheidungs-) Modelle und normative Modelle unterscheiden. • Deskriptive Modelle beschreiben die Realität, d.h. sie geben Antwort auf die Fragen "was ist?", "wie ist was aufgebaut?" und "wie passiert was?". • Kausale Modelle versuchen, die Realität zu erklären, d.h. Antwort auf die Frage "warum passiert was?" zu geben. • Prognostizierende Modelle sollen die Rektion von Systemen vorhersagen, also Antwort auf die Frage "was wird passieren?" geben. Sie sollen auch in Form von what-if-Analysen dazu dienen, verschiedene Alternativen zu bewerten.

7.2 Modelle

259

• Optimierende Modelle und Entscheidungsmodelle sollen unter verschie-

denen Alternativen die beste herausfinden oder gute Lösungen eines Problems finden, also Antwort auf die Frage "was ist am besten?" geben. • Normative Modelle sollen dazu dienen ethische Kriterien zu beschreiben und aufzustellen, d.h. Antwort auf Fragen vom Typ "was soll sein?" oder "was ist wünschenswert?" geben. Ziegenproblem Ein gutes Modell (Sicht auf die Dinge) ist die halbe Lösung. Zum sogenannten Ziegenproblem wurde jahrelang gestritten, das folgende Modell führt aber recht zwingend auf den richtigen Schluss. Bei einem Quiz ist der Preis in einer von drei Schachteln versteckt. Nachdem der Kandidat sich für eine der Schachteln entschieden hat, öffnet der Quizmaster eine der anderen, und zwar eine leere. Sie haben Schachtel a gewählt, der Quizmaster hat Schachtel b geöffnet und zeigt, dass diese leer ist. Was ist zu tun? Jede Schachtel enthält a priori den Gewinn mit Wahrscheinlichkeit 1/3. Wenn der Gewinn in Schachtel a ist und der Proband tippt Schachtel a, ist die bedingte Wahrscheinlichkeit, dann eine der beiden anderen Schachteln zu öffnen, jeweils ½ (Gesamtwahrscheinlichkeit jeder der Schachteln ist 1/6). Wenn der Gewinn in Schachtel b oder c ist und der Proband tippt Schachtel a, wird die jeweils dritte Schachtel geöffnet, die bedingte Wahrscheinlichkeit diese dritte Schachtel zu öffnen, ist also 100%. (Gesamtwahrscheinlichkeit der Schachtel ist 1/3). Wenn Schachtel a getippt wurde, ergibt sich also folgender Wahrscheinlichkeitsbaum:

Ausgangssituation: a getippt Gewinn in a p = 1/3 öffne b p=1/6

öffne c p=1/6

Gewinn in b p = 1/3 öffne c p=1/3

Gewinn in c p = 1/3 öffne b p=1/3

Da nun durch den Quizmaster die Schachtel b geöffnet wurde, fallen die grau unterlegten Ergebnisse weg. Man sieht nun, dass bei dem Ergebnis „a getippt, b geöffnet“, die Wahrscheinlichkeit für „Gewinn in c“ doppelt so hoch ist. Wechseln ist also die richtige Strategie. Ein Analogmodell dazu, in dem z.B. 98 von 100 Schachteln geöffnet werden, ist intuitiv schnell verständlich.

260

7.2.3

7 Methoden und Modelle

Modellcharakteristika

Im Folgenden stellen wir Charakterisierungen von Modellen zusammen. Die Kenntnis der gesamten Modellpalette ist wichtig für die Auswahl des "richtigen" Modells, das alle "wichtigen" Aspekte darstellen kann. Explizitheit Nach dem Grad der Explizitheit unterscheiden wir interne und externe Modelle: Der Begriff internes oder mentales Modell beschreibt die Informationen und Vorstellungen über das reale System oder Problem, die jemand "im Kopf hat", d.h. ein Modell, das nur "implizit" vorhanden ist. Durch explizite Festlegung in irgendeiner Form (verbal, symbolisch, materiell) wird daraus ein explizites externes Modell. Das interne Modell ist nur eine Vorstellung, wenn wir im Folgenden von Modellen reden meinen wir die (eigentlichen) externen Modelle. Darstellung Nach der Darstellung unterscheiden wir zunächst einmal materielle und immaterielle Modelle. Bei einem materiellen Modell wird der Informationsgehalt des Modells durch seine materielle Beschaffenheit beeinflusst. Ein immaterielles Modell hängt nicht von der Beschaffenheit des Trägers (Papier, Elektronische Medien) ab. Materielle Modelle bilden Systeme mit Hilfe materieller Zustände und Strukturen ab. Materielle Modelle können maßstäblich (Schiffs- Flugzeugmodelle, Manöver), analog (mit ähnlichen Wirkungsgefüge) oder symbolisch-ikonisch (Urnenmodell, Schachspiel) sein. Immaterielle Modelle sind nicht durch das Darstellungsmedium, sondern durch einen Formalismus festgelegt. Sie können unterschieden werden in • informelle Modelle wie Texte, • geometrische Modelle, • formal-mathematische (inkl. logische) Modelle. Materielle Modelle können offensichtlich nach dem verwendeten Material, dem Darstellungsmedium klassifiziert werden. Dies kann zum Beispiel Holz, Metall, Plastik oder Papier, aber auch ein größeres (Modell-) System der Realität sein. Immaterielle Modelle haben immer eine materielle Darstellung (Repräsentationen), beispielsweise das Papier, auf dem sie gedruckt sind oder der Speicher, in dem sie abgelegt sind. Obwohl hier das Medium keine wichtige Rolle spielt, können wir für ein spezielles Modell je nach Art des Darstellungsmediums und des für die Problemlösung verwendeten Mediums zum Beispiel Papiermodelle (d.h. auf Papier geschriebene oder gezeichnete Mo-

7.2 Modelle

261

delle) und Computerrepräsentationen (Speicherung und Verarbeitung in elektronischer Form) unterscheiden. Formalisierung und Abstraktion Hier müssen wir unterscheiden zwischen • der Abstraktion, die das Maß der Verallgemeinerung (essentielles Modell) und der logischen Zusammenfassung des Modells angibt, • der Formalisierung, mit der gemessen wird, wie exakt die Semiotik (Syntax = Zusammenhänge und Semantik = Bedeutung der Modellkomponenten) festgelegt ist, • der Allgemeingültigkeit, die angibt, für wie viele konkrete reale Situationen das Modell verwendbar ist. Bezüglich der Formalisierung unterscheiden wir die formalen Modelle, die aus Symbolen mit einer wohldefinierten Syntax und Semantik bestehen, gegenüber den informellen Modellen, bei denen keine formalen Nebenbedingungen gelten oder die Beziehungen zwischen den Zeichen und zur Realität durch Intuition, Assoziation oder Analogie klar sind. Ein formales Modell (z.B. mathematisches Modell) hat bestimmt formale Bedingungen (Syntax) zu erfüllen. Bei einem informellen Modell (z.B. freier Text) unterliegt die Modellbeschreibung keinen formalen Beschränkungen (außer denen der niedrigen Ebenen wie Rechtschreibung oder Zeichensätzen). Nach dem Grad der Abstraktion haben wir eine Skala, die von Maßstabsmodellen bis zu abstrakt-symbolischen Modellen reicht. • Analogmodelle und maßstäbliche Modelle. Bei maßstäblichen Modellen ist das Originalsystem in einem bestimmten Verhältnis abgebildet. Bei Analogmodellen werden andere Wirkungsmechanismen verwendet, die aber zu denselben Effekten führen. (Mechanik, Physik, ...) • Prämodelle sind solche Modelle, die durch verschiedene meist unzusammenhängende Bilder, Texte, Beispiele und durch Verweise auf Allgemeinwissen und Vorkenntnisse beschrieben sind, und die viel vages Wissen und implizite Annahmen enthalten. • Anschaulich-ikonische Modelle wie Bilder, Texte und Symbole verwenden zwar mehr oder weniger abstrakte Darstellungen, aber so, dass die Bedeutung dieser Ikonen oder Symbole intuitiv ohne zusätzliche Erläuterungen und ohne formale Syntax und Semantik klar wird. • Abstrakt-symbolische Modelle haben eine formale Syntax. Formale Modelle sind immer abstrakt-symbolisch. Für die Entwicklung sind nicht nur die formalen Spezifikationsmodelle sondern auch anschauliche Analogmodelle extrem wichtig. Insbesondere in den frühen Phasen und in Entwicklungsschritten, die Kreativität fordern, sind

262

7 Methoden und Modelle

informelle Modelle wichtig. Auch in den verschiedenen Entwicklungsmethoden spielen Analogien und Abstraktionen eine wichtige Rolle. Gleichnis Ein Gleichnis vermittelt eine Information mittels einer Analogie. Damit ist es eine effiziente Art von Modell – für eine Tatsache oder ein Verhalten. Bekannt sind die Gleichnisse der Bibel wie z.B. das vom Senfkorn oder vom verlorenen Schaf. Mit einem Gleichnis oder Analogmodell können komplexe Zusammenhänge in den Erfahrungsbereich des Empfängers übertragen und so leichter vermittelt werden. Die Idee, den Erfahrungsbereich des Empfängers (Kunde, Techniker, Nutzer, Manager) zu nutzen, kann in vielen Situationen hilfreich sein. Eine besondere Art ist das „Management by Storytelling“ in dem wünschenswerte Verhaltensweisen exemplarisch aufgezeigt werden.

Nach dem Allgemeinheitsgrad unterschieden wir generische und spezifische Modelle. Der Abstraktionsgrad des Modells bestimmt, wie groß die Menge derjenigen realen Situationen ist, auf die das Modell anwendbar ist. Der Grad der Allgemeinheit eines Modells reicht von generischen Modellen, die aus wenigen Aussagen bestehen und sehr viele Systeme und Probleme beschreiben können, bis zum spezifischen Modell, das genau ein reales Problem in einem realen System mit Angabe aller Werte und Festlegung aller Strukturen beschreibt. Ein generisches Modell ist im Extremfall eine Modellklasse mit Parametern, Freiheiten und Unsicherheiten (in Struktur und Größen). Ein spezifisches (spezielles) Modell ist Modell für ein ganz spezielles reales System bzw. Problem ohne Freiheitsgrade. Modellschwerpunkte Die Frage der Modellschwerpunkte muss bezüglich des Realsystems nach Aspekten (systembezogen) und Perspektiven (betrachterbezogene Sichten) gestellt werden. Daneben kann der Schwerpunkt der Modellierung in der Struktur oder im Verhalten des Systems liegen. Die möglichen Aspekte (Systemschwerpunkte) und Perspektiven (Betrachtersichten) hängen stark vom realen System und von der verwendeten Modellklasse ab. Je nach den Aspekten, die im Modell hauptsächlich berücksichtigt werden, unterscheiden wir bei formalen Modellen die objekt-, struktur-, zustands-, fluss- und ablauf-orientierten Modelle. Aber auch andere Einteilungen sind notwendig. So kann man Probleme unter politischen, wirtschaftlichen, finanziellen, ökologischen und kulturellen Aspekten betrachten, was jeweils einem anderen Realweltausschnitt entspricht. Die

7.2 Modelle

263

zuletzt genannte Einteilung ist eher dem Realsystem als dem Modell zugeordnet, steht also zwischen Perspektiven und Aspekten. Perspektiven sind Blickweisen auf das Realsystem, bestimmen also einen Ausschnitt des Systems oder Problems. Mögliche Perspektiven eines Betriebs sind z.B. die Informationsverarbeitung, Ressourcenverbrauch, Personal und Finanzen. Die folgenden Einteilungen gelten hauptsächlich für formale Modelle, sie können aber auch auf viele informelle Modelle angewendet werden. • Verhaltensorientierte Modelle: Dabei wird vor allen auf das Verhalten des zu modellierenden Systems Wert gelegt, zum Beispiel auf sein Anregungs-Antwort-Verhalten. Beispiele sind Input-Output-Modelle und Black-Box-Modelle. • Zustands- und eigenschaftsorientierte Modelle: Dabei wird auf die Beschreibung des Zustands, der Eigenschaften und der Veränderungen des Modells Wert gelegt. Übergänge, Bewegungsgesetze und Kennzahlen charakterisieren solche Modelle. Beispiele sind Automaten und Modelle der analytischen Systemtheorie. • Strukturmodelle: In solchen Modellen wird auf Teile und Struktur des Systems, sowie auf Beziehungen, Abhängigkeiten und Flüsse innerhalb des Systems Wert gelegt. Beispiele sind Netze, Flussdiagramme der Structured Analysis und hierarchische Darstellungen. Diese Modelle können auch (mehrfach) geschachtelt sein: ein Strukturmodell kann aus verhaltens-, zustands- und eigenschaftsorientierten Teilmodellen bestehen und ein verhaltens-, zustands- oder eigenschaftsorientiertes Modell kann wieder in ein Strukturmodell aufgebrochen werden. Im Entwicklungsprozess verändern die Modelle ihre Aspekte. Während Anforderungen verhaltensorientiert sind, werden in der Spezifikation Beschreibungen des Objekts gefordert. Für Entwurf und Implementierung sind interne Strukturmodelle unabdingbar. Waage Eine Waage hat für den Käufer die Aspekte Genauigkeit, Skala (Maximum, Einteilung), Maximalgewicht, räumliche Anordnung des Wiegeguts, Art der Anzeige bzw. Dokumentation. Daneben spielen Aspekte der Stabilität, Ausfallsicherheit, Geschwindigkeit und Ästhetik eine Rolle. Die Spezifikation leitet eine Beschreibung der Leistungen des Waage ab, im Entwurf werden die Wiegeprinzipien (Hookesches Gesetz, Hebelgesetz, Piezoeffekt) und Mechanismen des Wiegens, Beladens und Ablesens und ihre Zusammenwirkung festgelegt. Für eine Balkenwaage ist beispielsweise das Messprinzip einfach: G∗l = G´∗l´ mit den Gewichten G und Hebelarmen l. Alle bekannten Werte können verändert werden.

264

7 Methoden und Modelle

Die Einschwinggeschwindigkeit in die Ruhelage und Genauigkeit hängt von vielen anderen Faktoren ab (Lage des Schwerpunkts gegenüber dem Drehpunkt, Trägheitsmoment der Waage, ... )

Dieses Modell veranschaulicht das Wägeprinzip: Hebelgesetz

Dieses Modell erklärt, warum die Waage zur Ruhe (in einen Gleichgewichtszustand) kommt.

Nun können die detaillierte Entwicklung und die Konstruktion folgen.

Die Unterscheidung nach den eingesetzten Methoden zur Problemlösung ergibt Kriterien, die auf der Darstellung, der Abstraktion, dem Schwerpunkt und der Komplexität. Zur Problemlösung können formal-mathematische Methoden inklusive der numerischen Verfahren, experimentell-simulierende Methoden inklusive der mechanischen Experimente und Computersimulationen und symbolische Methoden eingesetzt werden. Die Modelle können aber auch intuitiv-analog (assoziativ) ausgewertet werden. Häufig wird ein Modell im einfachen Fall exakt ausgewertet, die Übertragung auf eine komplexere Realität erfolgt durch Analogieschluss. Strukturierung Nach der Art und Stärke der Strukturierung eines Modells können wir flache Modelle ohne Struktur gegen hierarchische und mehrschichtige Modelle abgrenzen. Je nach Art, Anzahl und Verknüpfung von Untermodellen sind viele Arten der Strukturierung denkbar. Die Hierarchie kann sich auf reale Objekte (Zerteilung eines Objekts) oder auf abstrakte Klassen (Klassifizierung) beziehen. Ökonomie und Wetterprognose Ein klassisches Beispiel für die Verknüpfung von Makro- und Mikromodellen bietet die Ökonomie. Auf der Mikro-Ebene (BWL) entscheidet jeder Haushalt autonom, die globalen Randbedingungen sind gegeben, das ganze ist einfach modellierbar. Auf der Makro-Ebene (VWL) sind die Entscheidungen durch Funktionen gegeben, die Entwicklung der globalen Parameter wird untersucht. Ähnlich ist es beim Wetter, wo die lokalen Bedingungen mittels der Hydrodynamik einfach zu beschreiben sind und die globalen Systeme (Hoch, Tief, Zyklon) vom Prinzip her klar sind.

7.2 Modelle

265

In beiden Fällen braucht man für jede Aggregationsebene andere Modelle und Verfahren; ein Gesamtsystem ist auch theoretisch weder beschreib- noch berechenbar und die Kopplung der verschiedenen Dimensionen gibt die typischen Effekte der Chaostheorie. Bei der Entwicklung eines Prognosesystems kann daher kein allgemeines „general system“ entwickelt werden, vielmehr müssen Dimensionen, Zeit und Aggregation dem Zweck angepasst werden.

7.2.4

Modellierung spezieller Aspekte

Modelle können wir auch danach charakterisieren, ob und wie bestimmte Aspekte wie Zeit, Unsicherheit und Entscheidungen berücksichtigt werden. Den Themenbereich Optimierung werden wir später betrachten. Zeit Je nachdem ob die zeitliche Veränderung des Systems und seines Umfelds berücksichtigt wird, unterscheiden wir statische (zeitunabhängige) und dynamische (zeitabhängige, z.B. sequentielle) Modelle. Realzeit Bei Software ist oftmals einen „Antwort in Realzeit“ erforderlich. Wichtig ist dabei nicht eine absolute Geschwindigkeit, sondern das Einhalten von Reaktionszeiten. So soll ein Fahrzeug bei einer Lenkbewegung oder einer drohenden Kollision in kürzester Zeit reagieren, auch wenn das System gerade Teile seiner internen Datenbank (z.B. einer Karte für die Navigation) neu lädt.

Auch in einem dynamischen Modell kann das zu modellierende System durchaus in (stationärer) Ruhe sein, wichtig ist, dass explizite Zeitabhängigkeiten vorkommen und modelliert werden. Zwischen den dynamischen Modellen, in denen die Entwicklung des Systems (i.a. durch ein Entwicklungsgesetz) modelliert wird, und den statischen Modellen stehen die kinematischen Modelle, in denen nur vorgegebene Zeitabhängigkeiten beschrieben werden. Fahrzeugdynamik Das zeitliche Verhalten eines Fahrzeugs kann zum einen mittels eines Weg-ZeitDiagramms (Fahrtstrecke, Beschleunigungsverhalten) beschrieben werden. Wenn man sich für das Schwingungs- oder Kippverhalten des Fahrzeugs (Elchtest), Details von Abläufen beim Lenken, Bremsen und Beschleunigen (z.B. für einen Tempomat oder für steer-by-wire) interessiert, sind feinere Modele notwendig (vergleiche dazu die Modelle des Fahrzeugs). Ein Modell zur Optimierung eines Lenkservos muss andere Parameter berücksichtigen als das Lenkmodell für einen Fahrsimulator.

266

7 Methoden und Modelle

Unsicherheit Je nach dem Grad der Vorhersagbarkeit des Systems und der Sicherheit, mit der Aussagen über das System gemacht werden können, unterscheiden wir deterministische und stochastische Modelle sowie Modelle unter Unsicherheit. In deterministischen Modellen kann der Zustand des Systems (zumindest theoretisch) exakt vorhergesagt werden. In stochastischen Modellen spielt der Zufall eine Rolle. Modelle unter Unsicherheit berücksichtigen die Tatsache, dass bestimmte Teile oder Eigenschaften des Modells nicht exakt bestimmt sind oder nicht genau bestimmt werden können. Ausbildungssimulator An einem Ausbildungssimulator (bzw. einem Planspiel) können wir die Bedeutung von Unsicherheit im System verdeutlichen. In Abhängigkeit vom Ziel des Trainings müssen die Zusammenhänge zwischen Aktionen und Zustandsänderungen verschieden implementiert werden: • deterministisch = verlässlich – für eine erste Einführung • stochastisch = realistisch – für ein fortgeschrittene Einführung • trainerorientiert = didaktisch – für ein effizientes Training Beispielweise müssen in einem Fahrsimulator für Kfz folgende Situationen modelliert werden: • Verkehrsteilnehmer missachtet Vorfahrt. • Straße ist rutschig. • Kind läuft in die Straße. • Benzinuhr ist defekt und Tank ist leer. • Ladung beginnt zu verrutschen. Eine verlässliche Modellierung der Vorfahrtsregeln ist für den Anfang notwendig, um die Regeln richtig zu lernen. In einer realistischen Simulation könnte man eine Missachtung der Vorfahrt mit einer kleinen Wahrscheinlichkeit einbauen, das Trainingsziel wird aber am besten dann erreicht, wenn der Trainer gezielt kritische Situationen herbeiführt, auch wenn diese in der Realität nur selten auftauschen. Die Stochastik muss also angepasst sein an die Kenntnisse des Trainees und an die Ziele des Trainings.

Nach der Art der Unsicherheit im Modell kann man Modelle mit Unschärfe (Fuzzyness, Plausibilität), parametrische Modelle und Modelle mit subjektiven Wahrscheinlichkeiten und Risiko unterscheiden. Während bei parametrischen Modellen ein (bestimmbarer) Parameter zur Systembeschreibung frei gelassen wird, wird bei Modellen mit Unschärfe die Schwankung, die aufgrund von fehlendem Wissen, prinzipieller Unsicherheit, sprachlicher

7.2 Modelle

267

Unschärfe oder Plausibilitätsbetrachtungen ins Spiel kommt, explizit modelliert. Bei Modellen mit subjektiver Wahrscheinlichkeit wird eine solche Unschärfe wie eine (stochastische) Wahrscheinlichkeit behandelt. Freiheiten in einem Modell bedeuten Parameter oder andere freie (d.h. noch nicht getroffene) Entwurfsentscheidungen, die im Modell noch unsicher und variabel sind. Normalereise denkt man bei Freiheiten und Parametern an Zahlen, ein Modell kann darüber hinaus aber sogar strukturelle oder funktionale Freiheiten und Unsicherheiten haben. • Bei Modellen mit struktureller Unsicherheit ist die Struktur des Modells selbst, z.B. die Teile und ihr gegenseitiger Einfluss noch variabel. • Bei Modellen mit funktionaler Unsicherheit ist der funktionale Zusammenhang zwischen Größen unsicher. • In den eigentlichen parametrischen Modellen sind einer oder mehrere numerische Parameter noch offen, so dass anstelle einer festen Zahl ein Parameter steht. • In festen (fixen, parameterfreien) Modellen sind alle Konstanten, Abhängigkeiten und Funktionen festgelegt. Zahlen und Größen Zahlen und Größen können entweder diskret oder kontinuierlich modelliert werden. Diskrete Modellierung bedeutet, dass für eine Größe endlich oder abzählbar unendlich viele mögliche Werte zur Verfügung stehen, die alle voneinander einen Mindestabstand haben. Beispiele sind die natürlichen oder ganzen Zahlen oder beliebige Mengen mit endlich vielen Elementen. Eine kontinuierlich modellierte Größe kann als Wert jede (i.a. reelle) Zahl in einem gegebenen Intervall annehmen. Beispiele sind die reellen Zahlen oder Teilintervalle wie das Intervall [0,1] aller reellen Zahlen zwischen 0 und 1. Beispiele für Größen, die kontinuierlich oder diskret modelliert werden können sind: • Zeit (Zeitpunkte, Dauern) und Raum (Position, Ausdehnung, Bewegung) • Zustände (Temperatur) und Eigenschaften (Gewicht, Preis) • Objekte (Produkte, Autos, Menschen) • Flüsse und Bestände (Material, Energie, Geld, Güter) Lagerhaltungssystem Ein Lagerhaltungssystem kann mit kontinuierlichen oder diskreten Modellen beschrieben werden. Das reale System und die Inventur (Schnittstelle zwischen Modell und Realität) sind auf jeden Fall diskret.

268

7 Methoden und Modelle

Bei Massenprodukten bietet sich eine kontinuierliche Modellierung an. Beispielsweise wird bei der Bestimmung optimaler Bestellzeitpunkte oder Losgrößen ein kontinuierliches Modell verwendet (z.B. in der Andlerschen Losgrößenformel). Nachfrage und Lieferung können deterministisch oder stochastisch (nach Menge und Zeit) modelliert werden.

7.3 Modellierung Vom Vagen zum Formalen und Exakten

Im Folgenden betrachten wir den Prozess der Modellbildung in seinen verschiedenen Stufen. Die prinzipiellen Vorgehensweisen bei der Modellbildung lassen sich danach charakterisieren, welcher Aspekt des Modells im Vordergrund steht. Danach können wir folgende Prinzipien unterscheiden: • Objektorientiert, Strukturorientiert, • Funktionsorientiert, I/O-Orientiert, • Datenflussorientiert, Datenstrukturorientiert, Algorithmenorientiert. Der Unterschied liegt vor allem im Paradigma, welche Aspekte des Modells bevorzugt betrachtet werden. Gemeinsam ist allen ein phasenorientiertes Vorgehen, das von einer sehr vagen Prämodellierung bis zur Erstellung und Validierung des Modells geht. Mit der fortschreitenden Ausprägung, Anpassung und Verbesserung überlagern sich diese Phasen der Modellbildung zu einem zyklischen Modell. Im Folgenden stellen wir ein Phasenmodell für die Modellbildung vor, das Anhaltspunkte für das Vorgehen und für die Beurteilung des Arbeitsfortschritts gibt. 1. Prämodellierung: Informationsgewinnung, Systemanalyse, Begriffsbildung, Abgrenzung von System und Modell, Feststellen des Problems, 2. Modellauswahl: Auswahl von Modellklasse und Repräsentationsmechanismus, Festlegen von Freiheitsgraden, 3. Eigentliche Modellierung: Ausarbeitung des Modells, Bestimmen von Struktur und Parametern, 4. Analysen, weitere Verbesserung und Verfeinerung des Modells, 5. Verifikation und Validierung, Überprüfung. Jede der Stufen kann auch wieder zurück zu einer der vorigen Stufen führen.

7.3 Modellierung

269

7.3.1 Prämodellierung

Mit Prämodellierung bezeichnen wir den Prozess, in dem das „interne Modell“ im Kopf des Modellierers wächst und Information und Wissen über das Objekt ohne Formalisierung gesammelt wird. Informationsgewinnung Die Informationsgewinnung und Systemanalyse steht konzeptuell am Anfang des Modellbildungsprozesses. Dass man auf diese Aktion immer wieder zurückkommt liegt daran, dass der Bedarf an Informationen über das System und die Fähigkeit zur Interpretation und Repräsentation von Informationen mit fortschreitender Konkretisierung und Verfeinerung des Modells ebenfalls fortschreitet. Informationsgewinnung besteht im Sammeln von (Mess-) Ergebnissen über das zu modellierende System aus allen möglichen Quellen (direkte Messungen, Information aus der Literatur oder von Dritten, Vorwissen). Die Interpretation ist schon wieder modellabhängig, d.h. sie wird durch das vorhandene Wissen des Modellierers beeinflusst. Dabei muss dieses Modell nicht eine enge Modellklasse sein, auch das Denkmodell des Modellierers (seine Sicht auf die Welt) beeinflusst die Modellierung, auch wenn dieses Modell "Kausalität", "naturwissenschaftliches Vorgehen" oder "holistisches Vorgehen" heißt. Abgrenzung von System und Modell Die erste Stufe bei der Erstellung eines Modells ist die Bestimmung des zu lösenden Problems bzw. die Abgrenzung des zu betrachtenden Systems. Wenn wir ein Bild malen oder eine Photographie machen wollen, müssen wir uns zuerst darüber klar werden, was Inhalt des Bilds sein soll. Genauso wie für ein Projekt die zu lösende Aufgabe beschrieben oder für ein Unternehmen der Geschäftszweck definiert werden muss, muss für das Modell der Zweck definiert und der "scope", d.h. die relevanten Aufgaben abgegrenzt werden. Dies wird zu oft vergessen und dann wird das Modell kritisiert, weil es "wichtige Probleme nicht berücksichtigt". Ein Modell zu fordern, das zur Lösung aller Probleme in einem bestimmten Bereich eingesetzt werden kann, ist in etwa so sinnvoll wie ein Photo der Zugspitze in Originalgröße zu bestellen. Die Abgrenzung externer Objekte und Größen gegen interne Objekte, Größen und Strukturen bestimmt, welche Größen im Rahmen des Modells betrachtet und welche vernachlässigt werden. Ebenso wird festgelegt, was beeinflussbar und was nicht beeinflussbar ist, d.h. was als Konstante angesehen wird und was vom System beeinflusst wird. Dabei kann eine Konstante durchaus auch eine Funktion der Zeit sein (z.B. das Wetter in den

270

7 Methoden und Modelle

meisten Modellen) verknüpft (z.B. der des Modells diese Steuerkurve) nicht beeinflussbar sind.

oder eine Funktion, die Systemparameter miteinender Steuersatz). Wichtig ist die Annahme, dass im Rahmen Konstante (also z.B. der Temperaturverlauf oder die durch Modellparameter oder den Entscheidungsträger

Mensch-Maschine-Schnittstelle Eine einfache Sicht auf die Entwicklung definiert die Mensch-Maschine Schnittstelle, z.B. Lokomotive – Lokführer. In einem komplexen eingebetteten System muss die Maschine (Flugzeug) gemeinsam mit dem Bediener (Pilot) und anderen Systemen (Leitsysteme, Fluglotse) gesehen werden.

Vor dem Entstehen einer neuen Struktur geht ein System (hier das Prämodell) typischerweise durch eine Chaosphase. Dieses „kreative Chaos“ fördert die Bildung neuer konzeptueller Strukturen. 7.3.2

Begriffsbildung

Mit zunehmender Information über das System entsteht ein Modell des Systems, das nun als Basis für weitere Analysen genommen wird. Es werden Konzepte, Teilsysteme und Effekte im System beobachtet und mit Begriffen bezeichnet. Diese Begriffe dienen als Basis der Kommunikation und der Analyse. Ob diese Begriffe sinnvoll sind, zeigt sich im Verlauf der Modellierung. Bei Systemen, in denen Menschen involviert sind, müssen auch die von den Beteiligten verwendeten Begriffe und Benennungen gelernt werden, um sie für Fragen und Dokumentationen zu nutzen. Hier liegt ein klassisches Bootstrap-Problem (Ei-Henne-Problem) vor, das nur in mehreren Iterationszyklen gelöst werden kann. Modellwissen basiert auf Informationen Begriffe basieren auf Erfahrungen und dem Modell

Realität

Analyse, Experimente, Fragen

Modell

Begriffe

Abbildung 7-3: Begriffsbildung und Wissen

Modellwissen und Begriffe sind notwendig um Fragen zu stellen und Analysen durchzuführen

7.3 Modellierung

271

7.3.3 Modellwahl

In der Modellwahl wird die Modellklasse festgelegt. Dazu dienen die im Kapitel über Modelle besprochenen Kriterien, der Modellierer muss natürlich die verschiedenen Klassen und Analysemöglichkeiten kennen, um ein für die Problemlösung günstiges Modell anzusetzen. Die Auswahl der Modellklasse und Repräsentation muss sich nach dem Zweck des Modells, nach der Form der geplanten Analyse und Auswertung des Modells, dem realen System (aus der Systemabgrenzung) und der zur Verfügung stehenden oder beschaffbaren Information richten. Bei der Auswahl von Modellen muss ein Kompromiss zwischen Flexibilität und Effizienz, sowie zwischen Lösbarkeit und Realitätsnähe gefunden werden. Bei einem flexiblen Modell, das "alles" berücksichtigen kann, dauert es viel länger, zu einem stabilen und befriedigenden Modell zu kommen, als bei einem einfachen Modell, das schnell an die reale Situation angepasst ist. Die Möglichkeit, ein Problem geschlossen zu lösen und der Wunsch, alle Nebenbedingungen der Realität zu berücksichtigen, schließen sich im Allgemeinen gegenseitig aus. Hier muss ein Kompromiss gefunden werden, wobei viel von dieser Entscheidung durch die Wahl der Modellklasse beeinflusst wird. Das Problem ist auch hier, dass als Basis dieser Entscheidung Vorkenntnisse vorhanden sein müssen. Um die Modellklasse festlegen zu können, muss Wissen über das System da sein, besser wären Erfahrungen mit dem Modell, d.h. Erfahrungen, wie sich das gegebene Problem mit der gewählten Modellklasse (und wie mit den zur Auswahl stehenden Klassen) modellieren und lösen lässt (Bootstrap-Problem analog zu dem bei der Begriffsbildung Betrachteten). Dies darf aber keinesfalls dazu führen, dass später das Problem ans Modell angepasst wird.

Modellierung und Modellauswahl basieren auf Informationen (Messung, Antwort)

Wahrnehmung der Realität

Analyse, Experimente, Fragen

Informationen und Wahrnehmung basieren auf dem ausgewählten Modell

Modellwahl, Begriffsbildung

Abbildung 7-4: Modellwahl und Wahrnehmung Im Rahmen der Modellwahl werden auch schon erste Entscheidungen zur Bestimmung der Freiheitsgrade getroffen. Die Modellklasse und die ge-

272

7 Methoden und Modelle

wählte Struktur legen fest, welche Größen fest vorgegeben und welche variabel sind, und ob die Größen stochastisch, unsicher, fix oder freie Parameter sind. 7.3.4

Modellierung und Parameterbestimmung

Die eigentliche Modellierung erfolgt in mehreren Schritten und führt vom Prämodell über das essentielle Modell zum physi(kali)schen Modell bzw. vom generischen zum spezifischen Modell. Die schrittweise Verfeinerung (stepwise refinement) von Modellen ist besonders in strukturorientierten Methoden ausgeprägt. Dies spiegelt sich auch in Bezeichnungen wie Top-Down-Analyse, Strukturierte Analyse (Structured Analysis) oder HIPO (Hierarchical-Input-Process-Output) wieder. Bei anderen Modellklassen geht es mehr um die Verfeinerung von Details oder um die Anpassung und exakte Bestimmung von Systemparametern (Systemidentifikation). Die endgültige Modellierung führt vom essentiellen Kernmodell zum physischen Modell des realen Systems. Ein Modell kann auch bottom-up vom Kern her wachsen, indem zunächst wichtige Teile oder Aspekte modelliert und dieses Modell dann erweitert bzw. modifiziert wird. Auch durch Integration verschiedener Teilmodelle oder Aspekte kann das Modell bottom-up konstruiert werden. 7.3.5

Analyse und Verbesserung

„Nobody is perfect“ und ein erstes Modell erst recht nicht. Deshalb spielt die Kritik und iterative Verbesserung bei der Modellierung eine wichtige Rolle. Modellanalyse Die Analyse von Modellen ist nicht nur für die Auswertung von fertigen Modellen wichtig, sie ist auch ein zentraler Schritt bei der Erstellung von Modellen. Sowohl bei der schrittweisen Adaption eines Modells an die Realität als auch bei der Reduktion von Supermodellen ist es wichtig, Teilmodelle zu untersuchen. Diese Analyse führt dann zu Entwurfsentscheidungen wie dem Vernachlässigen, Zusammenfassen, Vereinfachen von Teilsystemen, Zusammenhängen und Effekten oder sie initiiert eine tiefere Untersuchung eines Teilmodells, dessen Bedeutung für das Gesamtproblem deutlich geworden ist. Diese schrittweise Reduktion des Supermodells ähnelt dem Vorgehen beim Auflösen von Gleichungssystemen, wo nach und nach Variablen als Funktion anderer Variablen ausgedrückt (nach diesen aufgelöst) werden bis das

7.3 Modellierung

273

resultierende System eine übersichtliche handliche Form, im Idealfall die der geschlossenen Lösung, hat. Iterationsschritte Die Konsequenzen solcher Analysen können natürlich auf die Modellauswahl und Modellanpassung zurückwirken. Analysen und die mit ihnen verbundenen Schwierigkeiten können zum Weglassen von unwichtigen Teilen und Strukturen (z.B. von Verbindungen aus den jeder-mit-jedem-Netzen eines ersten Modellansatzes), zur Modifikation des Modells (Änderung von Parametern, Ersetzen von Parametern durch Funktionen oder Zufallsvariablen, Diskretisierung einer Variablen) und der Modellklasse (Übergang zu dynamischen Systemen, Wahl eines anderen Materials), sowie zu weiteren Analysen oder zur Aufstellung weiterer Teilmodelle (Untermodelle) führen. Jeder Entscheidungsschritt im Rahmen der Modellbildung und Analyse kann zu einem kleinen Problemlösungsprozess mit eigenen Modellen führen. Modellbeurteilung und Modellkritik Die Überprüfung und Kritik eines einmal aufgestellten Modells ist ausgesprochen wichtig, da der Mensch dazu tendiert, alles zu akzeptieren, was plausibel ist. Modellkritik muss nichts Negatives sein, die Kritik an einem Modell oder Beurteilung des Modells, soll konstruktiv und am Zweck des Modells orientiert sein. Ein Modell, an dem Kritik nicht möglich ist, weil es keine Anknüpfungspunkte für Kritik und Überprüfung und keine Testmöglichkeiten gegenüber der Realität hat, ist nutzlos, weil es nichts über die Realität aussagt. Ein Modell, das nicht kritisiert und angepasst wird, bietet keine Gewähr für die nötige Realitätsnähe. Modellkritik muss sich am Zweck des Modells orientieren. Dabei steht primär der Nutzen des Modells im Vordergrund, d.h. die Frage in wie fern das Modell für die Problemlösung brauchbar ist. Sekundäre Beurteilungsmerkmale sind: • Exaktheit, Formalität, Einhaltung und Verständlichkeit der Syntax, • Lesbarkeit, Klarheit der Semantik, • Flexibilität des Modells und • weitere Eigenschaften, die die Nützlichkeit des Modells beeinflussen. Wichtig bei der Modellkritik ist auch die Analyse des Gültigkeitsbereichs von Modellen. Es ist sicherzustellen, dass das Modell nur in den Bereichen eingesetzt wird, wo es gültig ist. Unzulässige Extrapolationen bringen falsche Ergebnisse, die innerhalb des Modells nicht falsifiziert werden können. Ein typisches Beispiel dafür sind Proportionalitätsbereiche: Genauso wenig wie die Helligkeit einer Glühbirne mit der Spannung oder die Länge

274

7 Methoden und Modelle

eines Fadens mit der spannenden Kraft beliebig ansteigt, ist es möglich, eine Arbeit, die 3 Mann in 2 Tagen (je 8 Stunden) erledigen, von 3000 Mann in einer Minute erledigen zu lassen. Ziele der Modellkritik können sein: • Verbesserung eigener Modelle: Modellkritik kann Schwachpunkte aufdecken. Diese können durch Modifikation des Modells oder durch Aufstellung eines Supermodells behoben werden. Es kann auch notwendig sein, diese Schwachpunkte in der Anwendung des Modells zu berücksichtigen, indem das Modell für bestimmte Probleme nicht verwendet wird. • Analyse fremder Modelle: Bevor man ein Modell verwendet, sollte man sicherstellen, dass das Modell für das gegebene Problem gültig ist. Dies kann durch Verbesserung des fremden Modells geschehen und damit zu einem neuen Modellbildungszyklus führen. Auch die Ergebnisse aus fremden Modellen sollten einer Analyse und Kritik unterzogen werden. • Aufstellung von Supermodellen (Metamodellen), die das betrachtete Modell beurteilen, es in einen größeren Zusammenhang einbetten, oder seinen Gültigkeitsbereich erweitern. 7.3.6 Verifikation und Validierung

Die Überprüfung eines Modells spielt auch im Qualitätsmanagement eine wichtige Rolle (Verifikation der Entwicklungsergebnisse). Die Kriterien, die an ein Modell zu stellen sind, lassen sich in die Ebenen Syntax, Semantik und Pragmatik einteilen. Dem entsprechen die drei Hauptkriterien an Modelle: Widerspruchsfreiheit, Gültigkeit (Realitätsbezug) und Nutzen und die Überprüfungsschritte Verifikation (formale Konsistenzprüfung), Validierung (Prüfung der Gültigkeit für die Realität) und Nutzenanalyse (Bewertung des Nutzens). Tabelle 7-1: Kriterien an Modelle Ebenen der Semiotik Syntax Semantik Pragmatik

Kriterien an Modelle

Überprüfungsschritte

Widerspruchsfreiheit Verifikation (Konsistenzprüfung) Gültigkeit (Realitätsbezug) Validierung (Realitätstest) Nutzen Nutzenanalyse

Verifikation Die Widerspruchsfreiheit eines Modells bedeutet eine formale Konsistenz innerhalb des Modells. Dabei sind formale syntaktische Bedingen und logi-

7.3 Modellierung

275

sche Nebenbedingungen zu erfüllen. Widerspruchsfreiheit schließt auch semantische Konsistenz ein, d.h. Bedingungen, die aufgrund der Bedeutung der Elemente des Modells erfüllt sein müssen (z.B. Beziehungen zwischen Größen und Objekten). Validierung Die Bedingung der Gültigkeit bedeutet, dass das Modell die Realität darstellen muss. Die Beziehung des Modells zur Realität muss also dargestellt sein (wohldefinierte Semantik des verwendeten Modells) und muss mit der Realität übereinstimmen. Die Gültigkeit eines Modells kann nicht formal bewiesen werden. Ein Test der Gültigkeit ist durch Vergleich mit der Realität (Experiment), durch Vorhersage von Versuchsergebnissen und Vergleich mit den realen Ergebnissen möglich. Fehler bewirken eine Ablehnung des Modells (Falsifizierung). Ein Modell, das nichts über den Ausgang von Experimenten vorhersagt (bzw. alle möglichen Ausgänge erklären kann), ist nicht falsifizierbar (und im Sinne der Wissenschaft nutzlos). Die richtige Vorhersage des Ausgangs eines Experiments ist allerdings noch kein Beweis für die Richtigkeit des Modells. Möglichkeiten der Überprüfung sind: reales Experiment (mit dem Problem, das System hinreichend zu isolieren), Gedankenexperiment/Simulation, Mathematische Analysen und Numerische Analysen. Das Prinzip ist dasselbe, wenn man Gedankenexperiment, Simulation, Experimentalumgebung jeweils als Modelle der Realität ansieht. Eine weitere Testmöglichkeit ist die Anwendung des Modells auf bekannte Fälle und Extremfälle (extrem einfache Fälle, extreme Dimensionen, Grenzübergänge). Gute Fragen sind: "was folgt aus dem Modell?", "welche Gegenbeispiele dazu gibt es?", "was wurde vergessen?". Die Modellkritik muss sich aber im Rahmen der Aufgaben und Ziele des Modells halten. Nutzen Der Nutzen des Modells besteht in der Ableitbarkeit richtiger Entscheidungen, Folgerungen und Lösungen. Der Nutzen eines Modells erweist sich an der Anwendung, die auf den Problemlösungsprozess folgt. Überprüfungsschritte und formale Kriterien können zwar Hinweise auf die Brauchbarkeit des Modells geben, und eine gewissenhafte Modellbildung bietet auch die beste Gewähr für ein brauchbares Modell, die Nützlichkeit kann aber letztendlich nur durch die Anwendung selbst – die Problemlösung und die Verständlichkeit und Brauchbarkeit für andere – beurteilt werden.

276

7 Methoden und Modelle

Fehler Eine Fragestellung, die im Zusammenhang mit Tests betrachtet wird, spielt auch bei der Verifikation, Validierung und Falsifizierung von Modellen eine wichtige Rolle: das Thema der Fehler erster und zweiter Art. Bei jedem Test, dessen Ergebnis Annahme oder Ablehnung einer Hypothese ist, gibt es ja zwei Möglichkeiten, Fehler zu machen. Durch die Ablehnung einer richtigen Hypothese und durch die Annahme einer falschen. Auf die Modellbildung bezogen bedeutet dies: • entweder die Ablehnung (Falsifizierung) oder Modifikation eines an sich richtigen Modells aufgrund einer Abweichung zwischen Vorhersage und Messergebnis (im weitesten Sinne) oder aufgrund zu hoher Ansprüche an das Modell, • oder das Akzeptieren (Verifikation, Validierung) eines noch nicht hinreichend guten Modells aufgrund zufälliger guter Übereinstimmung zwischen Vorhersage und Messergebnis (im weitesten Sinne) oder aufgrund zu niedriger Ansprüche an das Modell. 7.3.7

Ausprägung generischer Modelle

Wir haben im Abschnitt über Modellklassen im Kapitel Modelle generische und spezifische Modelle unterschieden. Ein generisches Modell ist eine Modellklasse mit Parametern und Freiheitsgraden, die von numerischen Parametern bis zur speziellen Form von Strukturen und Funktionen oder zur Frage des Vorhandenseins von Teilen reichen können. Ein spezifisches (spezielles) Modell dagegen ist ein Modell für ein ganz spezielles reales System. Der Übergang vom generischen Modell zum speziellen Modell ist ein weiterer Prozess, der parallel zu den Schritten der Modellbildung geht. Er entspricht der Repräsentation des Zuwachses an Information über das spezielle Realsystem im Modell. 7.3.8

Essentielle und physische Modelle

Gerade bei komplexen Systemen ist in den ersten Phasen der Modellbildung ein hohes Maß an Abstraktion erforderlich. Um zum Kern des Modells zu gelangen, muss man zuerst einmal alles das vernachlässigen, was nicht "eigentlich" zum System gehört. Abgrenzung Ein Modell, das implementierungsabhängige Details, Sonderfälle und Ausnahmen nicht berücksichtigt, heißt logisches oder essentielles Modell. Der Gegensatz zum essentiellen Modell ist das physische (oder physikalische) Modell, das (im Extremfall) sämtliche Details beinhaltet. Dies können

7.3 Modellierung

277

implementierungsabhängige Details, Ausnahmen, Rückkopplungen außerhalb des Modells, Fehler und sehr unwahrscheinliche Ereignisse sein. Beispiele für Inhalte des physischen Modells sind: Die Zuordnung von Funktionen zu Personen oder Maschinen in einer Firma, zufällige Personalunionen, Ausnahmefälle in einem Ablauf durch externe Störungen (Stromausfall durch Blitzeinschlag in einer Fabrik), Erschöpfung von Ressourcen (etwa dass dem Autofahrer das Benzin ausgeht oder bei einer Schreibmaschine ein Farbbandwechsel notwendig wird), externe (extrinsische) Rückwirkungen, Fehler im System, kriminelle Eingriffe (Diebstahl, Sabotage) – alles unter der Voraussetzung, dass diese Themen nicht gerade essentielle Inhalte des Modells sind. (Ein Modell zur Risikoanalyse wird gerade einige der oben betrachteten „Ausnahmen“ als essentielle Teile beinhalten.) Wenn wir vom Modellbildungsprozess ausgehen, könnten wir auch einfach sagen, dass das essentielle Modell dasjenige Modell ist, welches das beschreibt, was der Modellierer für essentiell hält. Erweitertes Problemlösungsdiagramm Bei der Modellierung komplexer Systeme stehen wir hier vor einem wichtigen Problem: zum einen kann ein einigermaßen komplexes Problem nicht vollständig modelliert werden. Zum andern sind aber gerade in komplexen Systemen die Effekte durch nicht-essentielle Verknüpfungen so stark, dass sie das Verhalten des gesamten Systems entscheidend beeinflussen. Für dieses Problem gibt es keine optimale Lösung, da man von vorne herein nicht feststellen kann, welche Zusammenhänge im endgültigen System einen Einfluss auf die Qualität der Problemlösung haben. Die geschlossene Behandlung des kompletten physischen Systems ist nicht möglich. Somit bleibt nur ein stufenweises Vorgehen bei der Problemlösung übrig: 1. Lösen des Problems im (oder in mehreren) essentiellen Modell. Dies führt zu einer essentiellen (konzeptionellen) Lösung. 2. Überprüfen und Verbessern der Lösung anhand des physischen Modells. Dies führt zu folgendem erweiterten Problemlösungsdiagramm:

278

7 Methoden und Modelle

reales Problem

reale Lösung physisches Modell des Problems

physisches Modell der Lösung

essentielles Modell des Problems

essentielles Modell der Lösung

Abbildung 7-5: Erweitertes Problemlösungsdiagramm Im Allgemeinen hat man nun zu einem Problem oder System mehrere essentielle Modelle für die relevanten Aspekte und Perspektiven, entsprechend erhält man mehrere Lösungen, die dann zu integrieren sind. Automodelle Modellierung legt unsere Sicht der Dinge fest und wird auch durch unsere Sicht beeinflusst. Was ein passendes „Modell“ ist, hängt weniger vom Objekt als vom Ziel des Modells ab. Modelle Automodelle kennen wir als Spielzeug, Hobbyobjekt oder für die professionelles Entwicklung und Tests. Die Anforderungen an Aussehen und Funktion sind sehr unterschiedlich. Das Flussmodelle (Benzin, Abgas), Zustandmodell (stehen, fahren), Transformationsmodell (Energie in Nutzen) oder mechanische Modell (Federung als einfache dynamische Systeme mit Masse, Feder und Dämpfungsgliedern) sind nur einige wenige der möglichen formalen Modelle. Mathematische Modelle und CAD-Modelle sind weitere Möglichkeiten.

Flussmodelle (Transformation): Benzin

Zustandsmodell (Übergänge) steht

Abgas

starten

anhalten Treibstoff

Transportleistung

fährt

7.4 Mathematische Modelle

279

Dynamisches System:

Strukturmodell: Karosserie Antrieb

Lenkung

dh/dt=F/m F=-Dh D1

D2

Abbildung 7-6: Einfachste Modelle eines Kfz

7.4 Mathematische Modelle Mathematik – gemeinsame Sprache von Ingenieur und Manager

Nicht umsonst spielt die Mathematik in der Ausbildung von Ingenieuren und Managern eine zentrale – wenn auch manchmal ungeliebte – Rolle: mathematische Modelle sind der zentrale Zugang zur exakten Beschreibung, Dokumentation, Kommunikation und Validierung von Systemen. Die im vorigen Kapitel betrachteten Modelle müssen in mathematische Modelle umgesetzt werden, wenn eine Berechnung, Analyse, Simulation oder Optimierung angestrebt wird. Generell nützt die Mathematik aber nur so viel, wie das Modell hergibt. 7.4.1 Funktionen

Mathematische Modelle spielen vom Dreisatz bis zur Kombinatorik eine wichtige Rolle. Ein zentraler Begriff ist die Funktion, da funktionale Abhängigkeiten eine wichtige Basis von Modellierung und Entwicklung sind. Viele Zusammenhänge werden in Form von Funktionen dargestellt. Die übliche Darstellungsweise y=f(x), die jeder Variable x einen Wert y zuordnet, ist bekannt. Funktionen sind zwischen allgemeinen Mengen, in Strukturen der Algebra und in der Analysis (Infinitesimalrechnung) modellierbar. Dem entsprechend sind analytische, algebraische, numerische (z.B. die in Tabellenkalkulationsprogrammen enthaltenen Lösungsprogramme) oder experimentelle Verfahren (z.B. Monte-Carlo-Simulation) zur Lösung einsetzbar. Wer eine Funktion verwendet, sollte sich immer klar machen: • Ist es wirklich eine Funktion, oder gibt es zu einem x mehrere Werte y? Die richtige Darstellung wäre dann die einer Relation R(x,y). • Ist es wirklich die richtige Richtung, oder gilt eher x=g(y)? • Gibt es eine dritte Variable z, so dass der wahre Zusammenhang durch x=w(z) und y=u(x) beschrieben wird? • Von welchen anderen Parametern hängt y ab? Ist f zeitabhängig?

280

7.4.2

7 Methoden und Modelle

Dynamische Systeme Alles fließt – oder verändert sich

Nur in den seltensten Fällen ist eine statische Betrachtung hinreichend für den Entwurf und die Beurteilung von Systemen. Veränderungen spielen eine wichtige Rolle und müssen berücksichtigt werden. In statischen Systemen sind alle betrachteten Größen zeitunabhängig, bei dynamischen Systemen betrachten wir zeitabhängige Variablen (das System selbst muss nicht zeitabhängig sein). Dabei gibt es zwei prinzipielle Arten der Beschreibung: • Die Zeitabhängigkeit der Variablen wird explizit angeben. Dies kann z.B. als Funktion x = f(t) geschehen. In diesem Fall geht es darum, die Zeitabhängigkeit zu modellieren und Folgerungen daraus zu ziehen. Im Bereich der Mechanik ist dies die Kinematik. • Die zugrunde liegenden Gesetze oder Mechanismen werden beschreiben. Dies kann z.B. als Gleichung der Form dx/dt = g(x) geschehen. Diese Bewegungsgleichungen werden aus Mechanismen des Systems hergeleitet, wie z.B. der Wirkung von Kräften (Beschleunigung = Kraft/Masse) oder Raten, mit denen sich Größen verändern (Sparrate = Einkommen - Konsum). Im Bereich der Mechanik ist dies die Dynamik, wir sprechen generell von einer dynamischen Beschreibung. Eine besondere Rolle spielen stationäre Lösungen, bei Ihnen hat die dynamische Beschreibung eine zeitunabhängige Lösung. Diese wird häufig auch als Gleichgewicht bezeichnet, da die Summe der wirkenden Mechanismen verschwindet und so keine Veränderungen in den betrachteten Variablen eintritt. Stationarität ist eine Frage des betrachteten Modells, insbesondere der betrachteten Variablen und der räumlichen und zeitlichen Skalen. Ausgangspunkt bei der Betrachtung allgemeiner dynamischer Systeme ist der Begriff der Transformation. Notwendige Basis dafür ist der Begriff des Zustands. Der Zustand eines Systems erlaubt Aussagen über das System und über seine weitere Entwicklung. Die Transformation baut darauf auf: im einfachsten Fall lässt sich der Zustand zu einem späteren Zeitpunkt aus dem aktuellen Zustand bestimmen: S(t+d) = T(S(t), d, t). Dynamik und Stabilität Stabilität und dynamisches Verhalten sind grundlegende Probleme in Produkten, sowohl in technischer Hinsicht als auch vom Verhalten von Systemen und Menschen. Wir betrachten im Folgenden das einfachste Modell eines dynamischen Systems, das durch eine Differenzen- oder Differentialgleichung beschrieben wird: ds/dt = A∗s bzw. sn+1 = s n + A∗s n

7.4 Mathematische Modelle

281

Stabilität Eine einfache Definition von Stabilität in dynamischen Systemen ist, dass bei einer Störung das System zum Ruhezustand zurückkehrt. In linearen Systemen (Übergangsgleichung ds/dt=A∗s bzw. sn+1=sn+A∗sn) ist dies wegen der Lösung s(t)=eAt∗s0 bzw. sn=(1+A)n∗s0 genau dann gegeben, wenn Re(A)<0 bzw. |1+A|<1. Für reelle A bedeutet dies als notwendige Voraussetzung A < 0, die sogenannte negative Rückkopplung. Bei A >0 erhalten wir das exponentielle Wachstum s(t)= s0∗eAt bzw. sn= s0∗ (1+A)n. 1200 1000 800 600 400 200 0 1

2

3

4

5

6

7

8

Abbildung 7-7: Exponentielles Wachstum ex Damit kann bei der Analyse und beim Entwurf von rückgekoppelten Systemen das Grundprinzip beschrieben werden. Regelung und Steuerung Regelung und Steuerung beruhen in der Technik und im Management auf ähnlichen Prinzipien. In der Technik spricht man von Steuerung, wenn in ein System extern eingegriffen wird, von Regelung, wenn dies aufgrund von Rückmeldungen (Beobachtung) des Systems erfolgt. Eine Regelung bewirkt also einen Regelkreis und damit ein dynamisches System einer höheren Ebene. Das Grundprinzip, einen Regler aus den beiden Teilen Beobachtung und Steuerung aufzubauen ist bewährt und führt in vielen Fällen zu optimalen Regelungen (principle of observation and control). Die Beobachtung selbst ist im Allgemeinen keine reine Messung sondern eine dynamische Bestimmung (besser: Schätzung) des Systemzustands (Filterung).

282

7 Methoden und Modelle

Aktoren

System

Steuerung

Schätzung des Systemzustands

Sensoren

Messung, Beobachtung

Abbildung 7-8: Regelungstechnisches Grundmodell Man in the loop Ein wichtiger Aspekt von Steuerungsmodellen ist der beeinflussende Mensch. Regelkreise, in die Menschen eingebunden sind, müssen das Verhalten und die Reaktionszeit des Menschen berücksichtigen. Physiologie und Psychologie liefern hier wichtige Hinweise, die z.B. in Form von Ergonomie und Fehlertoleranz zu berücksichtigen sind. 7.4.3

Prozesse

Prozesse sind in Technik und Management zentral. Zur Beschreibung dynamischer Abläufe in Organisationen und komplexen Systemen eigenen sich Prozessmodelle eher als die klassischen Methoden wie Differentialgleichungen. Ziel der Prozessmodellierung ist, Abläufe zu beschreiben und transparent zu machen, Schwachstellen aufzudecken und die Abläufe soweit sinnvoll festzulegen bzw. zu automatisieren. Dabei kann es sich um Prozesse in Hardware oder Software, in technischen oder natürlichen Systemen, oder bei der Erstellung von Produkten und Dienstleistungen handeln. Prozesse transformieren eine Eingabe/Vorgabe in eine Ausgabe/Ergebnis. Bei der Prozessmodellierung wollen wir die internen Abläufe beschreiben, dazu verwenden wir eine Abfolge von Funktionen (Prozessen, Aktivitäten) und Ereignissen. Ein Ereignis entspricht der Zustandsänderung bei einem oder mehreren Objekten. Ereignisse sind Ergebnisse (Endereignis) von Funktionen und lösen Funktionen aus (Anfangsereignis). Dabei entsprechen Prozesse und Ereignisse den im Projektmanagement betrachteten Vorgängen und Ereignissen. Die Frage, was Prozess und was Ereignis ist, hängt auch hier von der Modellierung (z.B. der betrachteten Zeitskala) ab.

7.4 Mathematische Modelle

283

Tabelle 7-2: Ereignisse und Aktivitäten Zeitbezug Zustandsbezug

Aktivität, Funktion Zeitdauer Transformationsprozess

Ereignis Zeitpunkt, Termin Zustandsänderung

Prozesse können durch graphische Darstellung in Form von Graphen mit Knoten und Kanten oder in Form von Petri-Netzen mit zwei Typen von Knoten beschrieben werden. Aktivität

Aktivität

Aktivität

Aktivität

Ereignis Aktivität

Aktivität Ereignis

Ereignis

Abbildung 7-9: Prozess als Graph mit Aktivitäten oder Petri-Netz

Zustand

Objekt

Ereignis = Übergang

Prozess = Transformation

Zustand

Objekt

Abbildung 7-10: Ereignis und Prozess im Graphen Ein Beispiel der Prozessmodellierung sind Ereignis-Prozess-Ketten (EPK): Ein Ereignis oder mehrere Ereignisse in UND, ODER oder XOR-Verknüpfung stoßen einen oder mehrere Prozesse an. Als Ergebnis eines oder mehrere Prozesse ergeben sich wieder eines oder mehrere Ereignisse.

284

7 Methoden und Modelle

Ereignis

Prozess

Ereignis

Prozess

.

Ereignis

Prozess

Ereignis

Prozess

Ereignis

Ereignis

Prozess

Ereignis

Prozess

Abbildung 7-11: Exemplarische Verknüpfungen in einer E-P-Kette Typischerweise startet die Prozessmodellierung bei den Hauptprozessen. Das sind zum einen essentielle Prozesse und zum anderen diejenigen Prozesse, die für die Gesamtfunktion des Systems am wichtigsten sind. Danach wird top-down verfeinert und es werden gleichzeitig parallele Prozesse (Seiteneffekte, Hilfsprozesse) modelliert, wenn diese wichtig werden. In der Prozessmodellierung im Unternehmen werden zunächst diejenigen Prozesse modelliert, die für das Unternehmen am wichtigsten sind, d.h. die einen großen Anteil an der Wertschöpfung haben: Auftragsabwicklung, Leistungserbringung, Produktentwicklung, Marketing und Umweltkontakte. 7.4.4

Optimalität

Die Lösung von Optimierungsaufgaben ist nicht nur eine mathematische Aufgabe. Viel wichtiger ist die korrekte Bestimmung und Modellierung von • Zielen, Zielkriterien, Zielfunktionen, • funktionalen Zusammenhängen zwischen Variablen und Ergebnis, • zulässigen Bereichen (Randbedingungen). Optimierung von Funktionen Wenn es nur darum geht, eine Funktion einer kontinuierlichen Veränderlichen zu optimieren, liefert die klassische Analysis gute Hilfsmittel. Das Kriterium für ein freies Optimum einer Funktion f(x) ist, dass deren Ableitungen df/dx verschwinden, d.h. es gilt df/dx=0. Dies findet sich z.B. im Prinzip vom verschwindenden Grenznutzen wieder.

7.4 Mathematische Modelle

285

Optimalität und ökonomisches Prinzip Sowohl in der Produktentwicklung als auch in der Implementierung (Produktion) und hinsichtlich der späteren Nutzung des Produkts sind Kosten und Nutzen abzuwägen. Diese Abwägungen finden statt zwischen: • Nutzen/Ertrag gegenüber Aufwand/Kosten/Ressourcenverbrauch, • Entwicklungsaufwand gegenüber Produktionskosten, • Produktnutzen/Fehlersicherheit gegenüber Kosten/Gewicht/Volumen, • Funktionsumfang gegenüber Bedienbarkeit. Die Optimalität hängt davon ab, was wir wollen. Dies kann sein: • maximaler Nutzen (Ertrag) bei vorgegebenem Aufwand (Kosten), • minimaler Aufwand (Verbrauch) bei vorgegebenem Nutzen (Ertrag), • maximale Differenz (Gewinn) zwischen Nutzen und Aufwand, • maximales Verhältnis (Quotient) zwischen Nutzen und Aufwand. Daneben spielt der Begriff der Pareto-Optimalität eine wichtige Rolle: Eine Lösung p heißt Pareto-optimal wenn es keine Lösung gibt, die in allen Komponenten des Zielfunktionsvektors mindestens so gut ist wie p und in mindestens einer Komponente echt besser ist. Nehmen wir hier als Zielfunktionsvektor (q1,q2) = (Ertrag, -Nutzen), so bedeutet Pareto-Optimalität von (p1,p2), dass es keine Lösung (x1,x2) gibt, die mit weniger Aufwand einen größeren Ertrag (oder mit gleichem Aufwand einen größeren Ertrag oder mit weniger Aufwand einen gleichen Ertrag) liefert. Die Lösung ist also sowohl bei vorgegebenen Ressourcen als auch bei vorgegebenem Ertrag optimal. Für alle Lösungen (x1,x2) ≠ (p1,p2), gilt entweder x1< p1 oder x2 < p2. Im folgenden Schaubild sind die Punkte eingezeichnet, die nach den verschiedenen Begriffen optimal sind: • maxN: Maximaler Nutzen ist charakterisiert durch die waagerechte Grenzlinie: es gibt keinen Punkt mit höherem Nutzen (dN/dK=0) • minK: Minimale Kosten sind charakterisiert durch die senkrechte Grenzlinie: es gibt keinen Punkt mit geringeren Kosten (dK/dN=0) • maxQ: Maximaler Quotient Nutzen/Kosten ist charakterisiert durch die Gerade durch den Punkt 0-0: die maximale Steigung bedeutet ein maximales Verhältnis. Gleichzeitig ist die Gerade durch den Ursprung Tangente an die Kurve (dN/dK=N/K). • maxD: Maximale Differenz Nutzen-Kosten ist charakterisiert durch die Parallele zur Winkelhalbierenden (dN/dx=dK/dx, dN/dK=1). • P: Pareto-optimale Punkte sind alle diejenigen Punkte, bei denen es keinen besseren Punkt (weniger Kosten und mehr Nutzen) gibt.

286

7 Methoden und Modelle

Nutzen N maxD: N-K

P

maxN

P maxQ:N/K Paretooptimale Bereiche minK Kosten K

Abbildung 7-12: Optimalitätsbegriffe Man erkennt hier, was sich auch nachrechnen lässt: maxD, maxQ, maxN und minK sind Pareto-optimale Punkte. Ist außerdem die Menge der zulässigen Punkte konvex, so ist die Menge der Pareto-optimalen Punkte gerade der Bogen von minK bis maxN, die Punkte maxD und maxQ liegen dazwischen. Aus Sicht der Produktentwicklung und des Managements sollte also genau überlegt werden, was eigentlich "optimal" bedeutet. Insbesondere sollten Nebenbedingungen in Frage gestellt werden. 7.4.5 Graphen

Graphen sind anschauliche aber formal, mathematisch und mit dem Computer einfach zu bearbeitende Modelle. Graphen bestehen aus zwei Arten von Elementen: Knoten und Pfeile. Dabei spricht man bei einem gerichteten Graphen von Pfeilen, beim ungerichteten Graphen, bei dem die Richtung des Pfeils keine Rolle spielt, von Kanten. Tabelle 7-3: Modell und Darstellung der graphentheoretischen Elemente Mathematisches Modell Darstellung

Knoten Grundmenge K Punkt oder flächiges Objekt

Pfeil Relation (k1,k2) zwischen den Elementen von K Linie (mit Pfeil zur Kennzeichnung der Richtung)

7.4 Mathematische Modelle

287

Die Grundelemente werden graphisch folgendermaßen dargestellt: Knoten e1

Pfeil (e1,e2)

Knoten e2

Abbildung 7-13: Grundelemente der Graphentheorie Aus dieser einfachen Relation lassen sich Vorgänger und Nachfolgerrelationen, in ungerichteten Graphen die Verbindungsrelation ableiten. Die Relation „ist verbunden mit“ ist transitiv, reflexiv und symmetrisch und erlaubt somit die Einteilung des Graphen in Zusammenhangskomponenten. Durch die Bewertung von Knoten oder Pfeilen, im Allgemeinen mit reellen Zahlen, lassen sich verschiedenste reale Zusammenhänge modellieren. Wichtige Beispiele dazu sind Entfernungskarten, Kapazitätsnetzwerke, Netzplantechnik und die quantitative Flussanalyse. Durch qualitative Werte lassen sich Abläufe, Flüsse, Prozesse und viele andere Modelle anschaulich darstellen. 13

A

C 7

3 B

5

11

5 D

Abbildung 7-14: Karte als Modell. Pfeilbewertungen können Entfernungen, Zeiten, Flüssen, Kapazitäten ... sein 7.4.6 Stochastik

Zufällige Ereignisse und ihre Kombination sind sowohl bezüglich des Produkts und seines Einsatzes als auch bezüglich des Entwicklungsprojektmanagements wichtig. Wir betrachten einige einfache Modelle, die als Analogie oder für einfache Näherungen dienen können. Sie sollen vor allem für die Bedeutung des Zufalls sensibel machen. Für exakte Beschreibungen sei auf die umfangreiche Literatur verwiesen. Zufall und Wahrscheinlichkeiten Um den Zufall analysieren zu können, betrachten wir zufällige Ereignisse. Die Wahrscheinlichkeit p eines Ereignisses können wir als die Chance defi-

288

7 Methoden und Modelle

nieren, dass dieses Ereignis eintritt. Anschaulich gesprochen ist bei sehr vielen Versuchen die relative Anzahl der Eintritte etwa diese Wahrscheinlichkeit p. Die Wahrscheinlichkeit, dass ein Ereignis nicht eintritt, ist p*=1-p, da die Wahrscheinlichkeiten des sicheren Ereignisses p+p*=1 ist. Ein unmögliches Ereignis hat Wahrscheinlichkeit p=0. Liegen mehrere Elementarereignisse vor, über die sonst nichts bekannt ist (und nur dann!), so gibt man jedem dieselbe Wahrscheinlichkeit. Ein Ereignis mit m Elementen bei insgesamt N Elementen hat dann die Wahrscheinlichkeit p = m/N. Diese Gesamtanzahl N der Elemente und die Anzahl m der Elemente zu einem bestimmten Ereignis werden z.B. mit Hilfe der Kombinatorik (kombinatorische Modelle) bestimmt. Von einer empirischen Wahrscheinlichkeit sprechen wir, wenn wir bei N Versuchen in der Realität m-mal das Eintreten des Ereignisses beobachtet haben. Dann setzen wir die empirische Wahrscheinlichkeit gleich der relativen Häufigkeit p = m/N. Wir betrachten dies am Beispiel der Lottozahlen: Die Wahrscheinlichkeit für einen Sechser im Lotto ist aufgrund der Kombinatorik p=1/13 983 816. Wenn von 36 Millionen Spielern 3 einen Sechser haben, ist die empirische Wahrscheinlichkeit p=1/120 00 000. Im Allgemeinen werden Wahrscheinlichkeiten aufgrund komplexerer Modelle oder Verteilungsannahmen hergeleitet. Kombination von Ereignissen Die einfachsten Kombinationen zufälliger Ereignisse sind die UND- und die ODER-Verknüpfung. Eine UND-Verknüpfung tritt ein, wenn beide Ereignisse eintreten, die ODER-Verknüpfung dann, wenn mindestens eines der Ereignisse eintritt. Unter der Annahme, dass die beiden Ereignisse unabhängig sind, gilt: Die Wahrscheinlichkeit, dass beide Ereignisse eintreten (UND-Verknüpfung) ist das Produkt der Ausgangswahrscheinlichkeiten. pA UND B = pA · pB Damit ergibt sich für das Ereignis, dass mindestens ein Ereignis eintritt (ODER) die Wahrscheinlichkeit pA ODER B = 1-pBEIDE NICHT =1-pWEDER A NOCH B = 1-pNICHT A·pNICHT B = 1- (1-pA)·(1-pB) = pA + pB - pA·pB. Dies ist die sogenannte Siebformel, die auch für die Kombination mehrerer Ereignisse entsprechend gilt. Nur wenn sich die Ereignisse gegenseitig ausschließen (oder pA·pB vernachlässigt werden kann), kann man die Wahrscheinlichkeiten addieren. Diese Kombinationen entsprechen in der Technik parallel bzw. seriell angeordneten Elementen, je nach Sichtweise und Funktion.

7.4 Mathematische Modelle

289

Die Voraussetzung der Unabhängigkeit muss genau geprüft werden, sollten Ereignisse nicht unabhängig sein, müssen bedingte Wahrscheinlichkeiten berücksichtigt werden. Sicherheitseinrichtungen Sicherheit ist immer ein stochastisches Phänomen. Neben technischen Aspekten bringt das Verhalten der beteiligten Personen Unsicherheit ein. Neben der direkten Behandlung des Phänomens sind auch Fragen wir die Konsequenzen von Fehlern 1 und 2. Art (Fehlalarm), die Umgehung des Systems (Zwangsläufigkeit), Konsequenzen von Sicherheitsgefühl durch höhere Risikobereitschaft, Verlagerung des schwächsten Glieds oder intensivere Nutzung zu betrachten. Redundante Systeme Wenn der Ausfall eines Systems zu kritischen Zuständen führt, die nicht zu tolerieren sind, kann ein zweites (redundantes) System eingebaut werden. Ist p die Ausfallwahrscheinlichkeit des Systems, so ist die Wahrscheinlichkeit für den Ausfall beider Systeme p². Wenn das System ein (Rechen- oder Steuer-) Ergebnis liefert, kann bei abweichenden Ergebnissen häufig nicht entschieden werden, welches Ergebnis falsch ist. Die Wahrscheinlichkeit für ein widersprüchliches Ergebnis ist 2·p. In diesem Fall wird ein drittes System parallel geschaltet, und nach der Mehrheit entschieden. Bei Berechnungen liegt echte Redundanz nur dann vor, wenn nicht nur die Hardware, sondern auch die Software (inkl. Betriebssystem) und Berechnungsmethoden (Algorithmen) unabhängig voneinander sind.

Warteschlangen und Puffer Die folgende Überlegung hat wichtige Konsequenzen für technische Geräte und Systemauslegungen, sie ist aber auch für das Management und die Kapazitätsauslegung von Projekten und Organisationen wichtig. Wir betrachten ein sehr einfaches Modell: Zwei Einheiten (Schalter) für vier Bedarfsträger. Jeder Bedarfsträger hat zu jedem Zeitpunkt eine Nachfragewahrscheinlichkeit von 50%. Nachfragewahrscheinlichkeit 50%

Bediener mit Kapazität 2 „im Mittel ausgelastet“

Abbildung 7-15: Ausgangsmodell Bediener

290

7 Methoden und Modelle

Aus diesem einfachen Model, ergibt sich folgende Auslastung: Tabelle 7-4: Auslastung des durchschnittlich ausgelasteten Bedieners Anzahl Nachfragen Effekt

0 leer

Wahrscheinlichkeit

1/16= 6%

1 unterausgelastet 4/16= 25%

2 3 exakt aus- überlastet gelastet 6/16= 4/16= 38% 25%

4 zweifach überlastet 1/16= 6%

Konsequenz: Dieses Element ist im Mittel zu fast 1/3 der Zeit nicht ausgelastet und zu fast 1/3 überlastet. Genauere Berechnungen können mit der Warteschlangentheorie durchgeführt werden. Wichtig ist aber, das Prinzip beim Entwurf von Systemen und im Management zu beachten, wo Überlast zu Verzögerungen und Fehlern und Unterlast zu überhöhten Kosten führen. 7.4.7

Dimensionen und Maßeinheiten

Die Betrachtung der Dimensionen und Maßeinheiten ist von der Wissenschaftsdisziplin her eher der Physik zuzuordnen, sie ist aber auch im Ingenieurwesen und in der Betriebswirtschaft unerhört wichtig. Die Analyse von Dimensionen erlaubt die Überprüfung von Zusammenhängen. Disziplin bei der Verwendung von Maßeinheiten ist für Technik und Management unerlässlich. Insbesondere bei elektronischen (analogen und digitalen) Systemen, die ja keine Maßeinheiten beinhalten, ist die richtige Interpretation der Werte (Analogwert wie 2,5V oder Digitalwert wie 10000100) als Zahl mit Größenordnung und Dimension extrem wichtig. Die Interpretation als Zahl sagt, ob der Wert 132, 33 oder -0,03 ist, die Maßeinheit sagt, ob z.B. bei Geldmengen $ oder € vorliegen bzw. ob der Druck in Pascal, bar oder psi ausgedrückt wird. Prozentzahlen „Prozent von was?“ Das mag trivial erscheinen, in Wirklichkeit ist diese Frage zentral. Bei einer Umfrage kann ein Prozentsatz bezogen sein auf z.B. „die Befragten“, „die Teilnehmer“, „diejenigen, die diese Frage beantwortet haben“, oder „diejenigen, die zu der Frage eine Meinung hatten“. Noch komplexer wird die Situation, wenn Mehrfachnennungen (Mehrfachkäufe, Mehrfachnutzung,) möglich sind.

7.5 Strukturierte Systemanalyse

291

7.5 Strukturierte Systemanalyse Struktur als Grundlage

Es gibt viele Methoden, mit denen ein System strukturiert modelliert wird. Die meisten bauen auf einer Hierarchie von Modellen (sukzessive Verfeinerung) auf. Ein Beispiele ist die HIPO-Methode (Hierarchische Input-Process-Output Modelle). Grundmodell der SA ist neben der hierarchischen Modellierung von Verarbeitungsknoten und Flüssen das modellbasierte Vorgehen (analog zum erweiterten Problemlösungsdiagramm): • Physisches Istmodell, • Ideales Istmodell, • Ideales Sollmodell, • Physisches Sollmodell. 7.5.1

Flussmodellierung

Flussdiagramme stellen die Flüsse von Material, Personal oder Information (Daten) durch ein System dar. Diese Modellierungsmethode kommt aus der Strukturierten Systemanalyse [DeMarco]. Sie darf nicht mit den manchmal als Flussdiagramme bezeichneten Programmablaufplänen verwechselt werden, bei denen die Aktivität durch die Knoten des Planes läuft. Solche Kontrollflussdiagramme sind Spezialfälle der betrachteten Prozessmodellierung, da in einem Programmablauf (Kontrollfluss) zu jedem Zeitpunkt (Schritt) genau ein Vorgang (Prozess) aktiv ist. Anwendungen von Flussdiagrammen können sein: • Materialfluss (Produkte, Stoffe, Ressourcen und Schadstoffe, oder allgemeiner von Materie), • Energiefluss (in technischen oder natürlichen biotischen und abiotischen Systemen), • Personalfluss (als Personalressource, Besucher, Bildungssysteme), • Geldfluss (Zahlungsströme, Wertflüsse, mikro- und makro-ökonomisch), • Informationsfluss (Daten, Information, Wissen). Die Flussmodellierung geht davon aus, dass Materialien in einem Prozess oder Informationen in einem informationsverarbeitenden System (also auch einer Organisation) weder aus dem Nichts entstehen noch für das Nichts produziert werden. Die Flüsse werden also nur transformiert. Das Flussmodell der Structured Analysis besteht aus den drei bereits bei der Datenflussmodellierung betrachteten Elementen: • dem eigentlichen Flussdiagramm (flow diagram, FD), • dem Lexikon (data dictionary, DD) mit der Beschreibung der Objekte, • den Beschreibungen der Verarbeitungsfunktionen/Transformationen.

292

7 Methoden und Modelle

7.5.2 Flussdiagramm

Das Flussdiagramm (FD) enthält alle Flüsse, die in dem jeweiligen Prozess verwendet werden. Die Flüsse müssen in Verarbeitungsknoten erzeugt werden und werden dort gebraucht. Der Aufbau ist analog zu den bereits betrachteten Datenflussdiagrammen. Elemente eines Flussdiagramms sind: • Verarbeitungsknoten (Nodes): Dies sind die regulären Knoten im FD und seinen Verfeinerungen. • Endknoten (Terminators): Dies sind die Schnittstellen des FD zur Außenwelt. Die Beziehungen und Flüsse zwischen Endknoten werden nicht modelliert. • Flüsse (Flows): Die Flüsse fließen zwischen den Knoten. Sie transportieren die betrachteten Objekte (Materie/Energie/Daten). • Speicher (Stores): In ihnen werden die Objekte längerfristig gespeichert. Die Strukturen der Speicher werden ebenfalls im DD beschrieben. Mit Hilfe der Verfeinerungen oder der Transformationsregeln der Kurzbeschreibungen kann überprüft werden, dass alle eingehenden Flüsse (Materie/ Energie/Daten) verwendet und alle ausgehenden Flüsse erzeugt wurden. Dabei kann die Erhaltung der Masse bzw. Energie als Kontrolle diesen. Terminalknoten

Terminalknoten Verarbeitungsknoten, Prozess

Verarbeitungsknoten, Prozess

Speicher

Verarbeitungsknoten, Prozess

Abbildung 7-16: Flussdiagramm Brauerei Das folgende Flussdiagramm soll nur ganz grob (und ohne Darstellung der eigentlich wichtigen Flüsse) die Idee des Flussdiagramms am Beispiel Bier Brauen klar machen.

7.5 Strukturierte Systemanalyse

Mälzerei

293

Hopfen-Lieferant

Maische ansetzen Brunnen

Auslieferung

Bier vergären

Bierkeller

Auslieferungslager Bier abfüllen

Die Datenflüsse sind: Malz, Wasser, Hopfen, Maische, Sud, Bier, Flaschen. Dort, wo Verarbeitungsfunktionen innerhalb der Lager essentiell sind (Nachgärung, Sortieren und Verpacken) ist statt der Lager ein Verarbeitungsknoten einzusetzen.

Im Flussdiagramm geht es um die Flüsse zwischen den Prozessen, nicht um deren zeitliche Abfolge oder Aktivierungslogik. Eine mögliche Erweiterung des FD um Kontrollflüsse, die nicht Daten sind, sondern Ereignisse auslösen (triggern), führt zum Kontrollflussdiagramm (Control Flow Diagram, CFD). Die quantitative Analyse der Flussdiagramme kann z.B. zu Stromanalysen führen. Sie sind wichtig, um die Bedeutung der einzelnen Ströme abschätzen und für die Entwicklung angemessen berücksichtigen zu können. Schiffsbau Im folgenden Flussdiagramm wird Wert auf die Flüsse gelegt. Die Verarbeitungsknoten können entsprechend „xxx bauen“ heißen.

Rumpf Schiff

Holz Takelage

Stoff

Der Fluss Holz des angenommenen übergeordneten Flussdiagramms wurde hier geteilt.

7.5.3

Data Dictionary

Das Wörterbuch (Begriffsverzeichnis, Data Dictionary, DD) beschreibt die Struktur der Objekte. Dies können physische Objekte oder Daten sein.

294

7 Methoden und Modelle

Die Struktur kann dabei aus folgenden Elementen bestehen: • Summe: A = B + C: das Element A besteht aus den Elementen B und C. Beispiel: Schiff = Rumpf + Antrieb. • Selektion: ein mit [B] gekennzeichnetes Element kann vorkommen, muss aber nicht. Beispiel: Schiff = Rumpf + [Steuerung] + Antrieb. • Alternative: A = B | C: das Element A ist entweder ein Element vom Typ B oder eines vom Typ C. Beispiel: Antrieb = Motor | Segel | Ruder. • Sequenz: A = {B}: das Element A besteht aus mehreren Elementen B Beispiel: Liste = {Listenelemente}. Diese Strukturelemente sind gut geeignet, um einfache strukturelle Beziehungen zwischen Objekten zu modellieren. Komplexere Zusammenhänge werden in Semantischen Netzen modelliert. 7.5.4

Hierarchie

Ein wichtiger Punkt bei der Modellierung der Flüsse ist die Verfeinerung. Dabei werden analog zur Betrachtung bei den Datenflussdiagrammen gleichzeitig das FD und das DD verfeinert. Aus jedem Knoten wird so ein Flussdiagramm der nächsten Ebene, das aber keine Endknoten hat, vielmehr gehen die Flüsse nach außen und müssen – gegebenenfalls mit den im DD gegebenen Strukturen – den Flüssen des übergeordneten Flussdiagramms entsprechen. Damit kann ein komplexes System über mehrere Hierarchieebenen in einfache Teile (Funktionen) zerlegt werden. Dies wird nicht nur bei der Analyse, sondern auch im Entwurf des Systems (über die bereits betrachteten Stufen des essentiellen und physischen Modells) genutzt. Damit lässt sich über die Flussmodellierung ein Systementwurf als Folge von Modelltransformationen vom physischen Problemmodell (Ausgangsproblem, Aufgabenstellung) über die essentiellen Modelle bis zum physischen Lösungsmodell (realisiertes und implementiertes Entwicklungsergebnis) betrachten.

8

Literatur

Arnold, R., Bauer, C.-O.: Qualität in Entwicklung und Konstruktion. Verlag TÜV Rheinland, 1992 Balzert, H.: Lehrbuch der Software-Technik – Software-Entwicklung. Spektrum, Heidelberg, 1996 Balzert, H.: Lehrbuch der Software-Technik – Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum, Heidelberg, 1998 Bäumler, E: Auf der Suche nach der Zauberkugel. Vom großen Abenteuer der modernen Arzneimittelforschung. Econ, München 1984 Behrendt, S. et.al.: Innovationen zur Nachhaltigkeit. Springer, Berlin, 1998 Bell, E.T.: Mathematics - Queen & Servant of Science. Microsoft Press, Redmond, 1989 Biermann, T.: Dienstleistungs-Management. Hanser, München, 1999 Böhm, B.W.: Software Engineering Economics. Prentice-Hall, 1981 Boy, J., Dudek, C., Kuschel, S.: Projektmanagement. Gabal, Offenbach, 2000 Braun, H.-J.: Die 101 wichtigsten Erfindungen der Weltgeschichte. C.H.Beck, München, 2005 Brehler, R., Steinwachs, H.O.: Management im Konstruktionsbüro. Verlag moderne Industrie, Landsberg/Lech, 1990 Bullinger, H.-J., Scheer, A.-W.: Service Engineering, Springer, Berlin, 2003 Burghardt, M.: Projektmanagement. Publicis, Erlangen, 2002 Christensen, C.M. Raynor, M.E.: Marktorientierte Innovation. campus, Frankfurt, 2003 Christensen, C.M.: The Innovator’s Dilemma. Harper Business, New York, 2003 Cooper, R.G.: Winning at new Products. Accelerating the Process from Idea to Launch. Perseus Publishing. Cambridge MA, 2001 (d: Top oder Flop in der Produktentwicklung, Wiley VCH, Weinheim 2002) Davis, P.J., Park, D.: No Way – The Nature of the Impossible. W.H.Freeman, New York, 1987 De Bono, E.: Laterales Denken für Führungskräfte. Rowohlt, Reinbeck, 1972 De Bono, E.: Serious Creativity – die Entwicklung neuer Ideen durch die Kraft lateralen Denkens. Schäffer-Poeschel, 1996

296

8 Literatur

De Marco, T., Lister, T.: Wien wartet auf Dich – der Faktor Mensch im DVManagement. (Orig: Peopleware – Productive Projects and Teams) Hanser, München, 1999 De Marco, T., Lister, T.:Bärentango. Mit Risikomanagement Projekte zum Erfolg führen. Hanser, München 2003 De Marco, T.: Spielräume. Hanser, München 2001 De Marco, R.: The Deadline. Dorset House, New York, 1997 (d: Der Termin. Hanser, München 1997) De Marco, T.: Warum ist Software so teuer? Und andere Rätsel des Informationszeitalters. Hanser, München 1997 De Marco, T.: Software-Projektmanagement. Wolfram's Fachverlag, 1989 Descartes, R. Abhandlung über die Methode des richtigen Vernunftgebrauchs (Orig.: Discours de la méthode pour bien conduire sa raison et chercher la vérité dans les sciences, 1637) Reclam, Stuttgart, 1961 Dixit, A.K., Nalebuff, B.J.: Spieltheorie für Einsteiger – Strategisches Know-How für Gewinner. Schäffer Poeschel, Stuttgart, 1995 Drucker, P.F.: Management im 21. Jahrhundert. Econ, München, 1999 Ehrlenspiel, K.: Integrierte Produktentwicklung. Hanser, München, 2003 Ewert, W. et al: Handbuch Projektmanagement öffentliche Dienste. Sachbuchverlag Keller, Bremen, 1996 Fisher, W.T., Ury, W., Patton, B.M.: Das Harvard-Konzept – Klassiker der Verhandlungstechnik (Orig: Getting to Yes), Campus-Verlag, 2003 Freemann-Bell, G., Balkwill, J.: Management in Engineering. Prentice Hall Europe, 1996 Geier, M.: Die kleinen Dinge der großen Philosophen, Piper, Hamburg, 2001 Goldratt, E. et.al: Das Ergebnis. campus, Frankfurt, 2001 Hannagan, T.: Management Concepts and Practices. Prentice Hall/Pearson, Harlow, 1998 Herstatt, C., Verworm, B. (Hrsg.): Management der frühen Innovationsphasen. Gabler, Wiesbaden, 2003 Hillman, D, Gibbs, D.: Genial! Die 100 genialen Erfindungen des 20. Jahrhunderts ohne die unser Alltag nicht mehr vorstellbar ist. vgs, Köln 1998 Hofenbeck, W.: Allgemeine Betriebswirtschafts- und Managementlehre. Verlag moderne Industrie, Landsberg, 1998 Holzbaur, U. et.al.: Eventmanagement. Springer, Heidelberg, 2001 Holzbaur, U.: Management, Kiehl, Ludwigshafen, 2001

8 Literatur

297

Karlöf, B.: Effizienz – Die Balance zwischen Kundennutzen und Produktivität. REFA München, Hanser, 1999 Kessler, H., Winkelhofer, G.: Projektmanagement. Springer, Berlin, 2002 Keyser, H.: Tourism Development. Oxford Southern Africa, Cape Town, 2002 Kranz, G.: Failure is Not an Option. Berkeley Publishing group, New York, 2000 Krichbaum, J.: Deutsche Standards, Ed. Weitbrecht, Stuttgart, 1988 Krichbaum, J.: Made in Germany. dtv, München 1997 Lehner, F.: Wissensmanagement. Hanser, München, 2006 Lung, E.: Nonprofit-Management. Ernst Reinhardt Verlag, München, 1998 Luther, M. Martin Luthers Werke, Kritische Gesamtausgabe, 30, 2, 636, 15 ff. nach Vogt-Luerssen, M.: http://www.asn-ibk.ac.at/bildung/faecher/geschichte/maike/mluther/sprueche.htm Madauss, B.J.: Handbuch Projektmanagement. Schäffer Poeschel, Stuttgart, 2000 Magreta, J.: Basic Management. dtv, München, 2004 Mangold, P. IT-Projektmanagement kompakt. Spektrum, Heidelberg, Berlin, 2002 Mehrmann, E., Wirtz, T.: Effizientes Projektmanagement. Erfolgreich Konzepte entwickeln und realisieren, ECON-Praxis. 2001 Meyer, O., Werlen, M., Pfammatter, C., Eyer, E.: Die Hubbrücke "Saltina" in Brig-Glis. Schweizer Ingenieur und Architekt Nr.50, 11.Dezember 1997 nach: http://www.rhone.ch/cygnus/siahub.htm Meyner, E.A.: Berichte und Protokolle schreiben. Düsseldorf, ECON Moore, G.: Crossing the Chasm. Harper Collins, New York, 1999 Neumann, K., Morlok, M: Operations Research, Hanser, München, 2002 Newman D.G., Lavelle J.P.: Essentials of Engineering Economic Analysis. Engineering Press, 1998 Page, S.J., Dowling, R.K.: Ecotourism. Prentice Hall/Pearson, Harlowe, 2002 Page-Jones, M.: Praktisches DV-Projektmanagement. Hanser, 1991 Pahl, G., Beitz, W: Konstruktionslehre – Methoden und Anwendungen. Springer, Berlin, 1997 Pantenburg, V.: Wernher von Siemens – Abenteuer Elektrizität. Ensslin Laibling, Reutlingen, 1966, Patzak, G.: Systemtechnik – Planung komplexer innovativer Systeme -

298

8 Literatur

Springer, Berlin, 1982 Petroski, H.: Invention by Design. Harvard University Press, London, 2002 Petroski, H.: To Engineer is Human. Random house, New York, 1992 Platz, J., Schmelzer, H.J.: Projektmanagement in der industriellen Forschung und Entwicklung, Springer, 1986 Polya, G.: How To Solve It. Princeton University Press, Princeton NJ, 1973 Probst, G.J.B., Gomez, P.: Die Praxis des ganzheitlichen Problemlösens. Haupt, Bern, 1999 Probst, G.J.B., Gomez, P.: Vernetztes Denken, Ganzheitliches Führen in der Praxis. Gabler, 2002 Project Management Institute (ed.): A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project Management Institute, 2004 Reese, J. (Hrsg): Der Ingenieur und seine Designer – Entwurf technischer Produkte im Spannungsfeld zwischen Konstruktion und Design. Springer, Berlin, 2005 Reinertsen, D.G.: Die neuen Werkzeuge der Produktentwicklung. Hanser, München, 1998 Reiter, W.: Projektmanagement für Einzelkämpfer. Hoffmann und Campe, Hamburg, 2004 Schawel, C. Billing, F.: Top 100 Management Tools. Gabler, Wiesbaden, 2004 Schelle, H.: Projekte zum Erfolg führen. dtv, 2004 Schleiken, T., Winkelhofer, G. (Hrsg.): Unternehmenswandel mit Projektmanagement. Lexika-Verlag, Würzburg, 1997 Schultz von Thun, F.: Miteinander reden: Störungen und Klärungen. Rowohlt, Reinbeck,1988 Schultz von Thun, F., Ruppel, J., Stratmann, R.: Miteinander reden- Kommunikationspsychologie für Führungskräfte. Rowohlt, Reinbeck, 2003 Teidscheid, P.: Nachhaltige Produkt- und Dienstleistungsstrategien in der Informationsgesellschaft. Erich Schmidt Verlag, Berlin, 2001 Thorvalds, L., Diamond, D.: Just for Fun. Hanser, München, 2001 Ulrich, P., Fluri, E.: Management. UTB Haupt, Bern, 1996 Utterback, J.M:: Mastering the Dynamics of Innovation. Harvard Business School Press, Boston, 1994 Versteegen, G. (Hrsg.): Risikomanagement in IT-Projekten. Springer, Berlin, Heidelberg, 2003

8 Literatur

299

Vester, F.: Unsere Welt, ein vernetztes System. dtv, 1983 Vortisch, S.: Theater mit der Umwelt – was es heißt, Stücke für die Umwelterziehung zu erarbeiten. in: Wessel, J., Gesing, H. (Hrsg.): UmweltBildung Spielend die Umwelt entdecken. Luchterhand, 1995. S. 176 - 203 Wallmüller, E.: Risikomanagement für IT- und Software-Projekte. Hanser, München, 2004 Weinberg, G.M.: The Secrets of Consulting. Dorset House Publishing, NY, 1983 Weizsäcker, E.U. von, Lovins, A.B., Hunter Lovins L.: Faktor Vier – Doppelter Wohlstand – halbierter Naturverbrauch. Knaur, München, 1997 Wysocki, R.K.: Effective Project Management. Wiley, Indianapolis, 2003 Yourdon, E.: Death March The complete Software Developer´s Guide to Surviving „Mission Impossible“ Projects. Prentice Hall, 1997

Privacy Statement MetaPress is committed to respecting data-protection regulations. This statement informs you of the steps we take to protect your rights. By personal data we mean (a) the details you provide us via our forms, e.g. your email address, all ordering and billing information, such as postal addresses and payment details, and (b) all data captured in authentication and tracking logs. By using our site and by registering for any of our services or products, you accept that such personal data will be gathered and stored in our databases. We will maintain appropriate safeguards to ensure the security, integrity and privacy of your personal data. We do not share personal data with other companies for marketing or similar purposes. This data will be used by MetaPress to provide you with the services and products you have ordered. We may also occasionally use it to inform you of new services and products related to those you have ordered and of changes and activities within MetaPress. By registering for services and products in MetaPress, you agree to MetaPress using your email address in this way. Authentication and tracking logs will be used to produce usage statistics. This information does not contain any personally identifiable information. MetaPress reserves the right to have logs and databases analyzed by external service providers, in which case every effort will be made to protect the security, integrity and privacy of the data. Please note that we take no responsibility for personal data posted on any open forums or message boards. Disclaimer MetaPress cannot take responsibility for information found on third party Web sites outside its control. While we attempt to provide links only to third-party Web sites that comply with all applicable laws and regulations and our standards, please understand that the content on these third-party Web sites is subject to change without notice to MetaPress. We therefore cannot be responsible for, and accept no liability for, any information or opinion contained in any third-party web site.