Beiträge

Themengruppen

Recherche

• Alle Schlagworte
• Alle Beiträge

Service

• Was ist Wissensmangement?
• Open Journal of Knowledge Management
• Artikel-Guidelines
• Newsletter
• Kalender
• Wissensmanagement-Anbieter
• Partner
• Mediadaten

Community

• Autoren
• Wir über uns
• Login/Registrierung
• Blog zur Community of Knowledge

Sponsoren

Potenziale von Prototypen im Wissensmanagement von Entwicklungsprozessen

26. September 2011 von Holger Rhinow, Tilmann Lindberg, Eva Köppen, Prof. Dr. Christoph Meinel

Die Forschung zum Prototyping in Design-geleiteten Entwicklungsprozessen hat bereits eine Vielfalt an Vorteilen und Herausforderungen thematisiert. Fragestellungen, die für das Wissensmanagement relevant sind, werden jedoch bislang kaum bearbeitet. In diesem Artikel möchten wir zeigen, dass gerade im teaminternen Wissensabgleich wie auch im Wissenstransfer Design-Prototypen große Potenziale entfalten, sofern sie in strukturierte Beobachtungsprozesse und Dialoge eingebettet werden.

Dieser Beitrag wurde im Open Journal of Knowledge Management, Ausgabe IV/2011 veröffentlicht.

---

Einleitung

Moderne Innovationsstrategien orientieren sich zunehmend an Erkenntnissen und Methoden aus dem Design (Boland, 2004; Martin, 2009). Design-geleitete Ansätze zeichnen sich aus durch ein Repertoire unterschiedlicher Kreativtechniken, ein nutzerzentriertes Vorgehen, oftmals multidisziplinäre Teamarbeit, iterative Prozessschritte sowie die Erarbeitung von Lösungen anhand von so genannten Design-Prototypen. Design-Prototypen grenzen sich von funktionalen Prototypen insofern ab, als dass sie eine Idee oder ein Erlebnis greifbar machen, ohne dass darin zwangsläufig die technische Umsetzung inbegriffen ist. Die Design-Teams können bereits in einem frühen Stadium Design-Prototypen entwerfen und technische Fragestellungen größtenteils ausblenden. Forschungsergebnisse zeigen, dass die Nutzung von Design-Prototypen einen starken Einfluss auf die Qualität und den Erfolg des Entwicklungsprozesses ausübt (Schrage, 1996).

Organisationen und Mitarbeiter erarbeiten verschiedene Formen von Prototypen und setzen sie an unterschiedlichen Stellen im Designprozess ein, beispielsweise um eine zuvor erstellte komplexe Spezifikation zu erfüllen. Auch wenn die Praktiken des Prototypings in unterschiedlichen Firmenkulturen verschieden ausgeprägt sind und sich nicht verallgemeinern lassen, sind zwei generelle Anwendungsbereiche zu unterscheiden: Innovative Unternehmen tendieren eher dazu, Prototyp-getriebene Spezifikationen abzuleiten, während konservativere Unternehmen zunächst Spezifikationen entwickeln und daraus Prototypen ableiten (Schrage, 1996). Der Unterschied ist fundamental: Im ersten Fall dient der Prototyp dazu, eine Entwicklung explorativ voranzutreiben, im Sinne eines Design-geleiteten Vorgehens. Im zweiten Fall werden möglichst früh Anforderungen fixiert und systematisch mit dem Prototypen abgearbeitet. Unsere Annahme ist, dass der erste Ansatz, also das Prototyp-getriebene, explorative Vorgehen, den Wissenstransfer im Entwicklungsteam und darüber hinaus, an den Schnittstellen zu anderen Bezugsgruppen, erleichtert.

In diesem Prototyp-getriebenen Ansatz sind Design-Prototypen Wissensträger, die im Produktentwicklungsprozess vielfältige und wichtige Funktionen erfüllen können, sofern sie durch den gesamten Entwicklungsprozess genutzt werden. Ihr Zweck erschöpft sich nicht nur allein darin, die Zwischenstadien der Entwicklung zu einem fertigen Produkt zu repräsentieren, vielmehr ermöglichen sie Reflexionsmomente innerhalb des Entwicklungsprozesses, die sowohl einen teaminternen Wissensabgleich als auch einen abteilungs- bzw. organisationsübergreifenden Wissenstransfer unterstützen. Prototypen repräsentieren dabei unterschiedliche Kategorien des Wissens in der Produktentwicklung. Sie können Auskunft geben über Funktionsweisen, ästhetische Aspekte, Bedienbarkeit usw. (Houde & Hill, 1997). Sie helfen dabei, Designkonzepte zu spezifizieren und sie zur besseren Identifikation des eigentlichen Designproblems in Frage zu stellen (Lim et al., 2008). Prototypen nehmen somit unterschiedlichste Funktionen in der Steuerung von Wissensflüssen in Produktentwicklungsprozessen ein.

Prototypen: Drei Anwendungsbereiche

Trotz ihrer potentiell relevanten und fruchtbaren Rolle sind Prototypen im Wissensmanagement von Produktentwicklungsprozessen noch wenig bearbeitet worden. Eine zentrale Einsicht aus Sicht des Wissensmanagements ist, dass Prototypen selten explizit Wissen darstellen, sondern es eher implizit verkörpern. Das Wissen, das hinter einem technischen Modell, einer simulierten Interaktion oder einem so genannten Look-and-Feel-Objekt steht, ist für den uninformierten Betrachter selten unmittelbar nachvollziehbar und eindeutig (Houde & Hill, 1997). Prototypen bieten ihren Betrachtern Interpretations- und Reflexionsspielräume, die eine kontrollierte Weitergabe von Wissen, wie zum Beispiel bei Dokumentationen, verhindern. Was Prototypen auf den ersten Blick für das Wissensmanagement wenig nutzbar erscheinen lässt, ist auf den zweiten Blick ein Faszinosum, das viele Chancen bietet: Der implizite Charakter von Prototypen bietet eine unmittelbare Erfahrbarkeit und Interpretationsmöglichkeit, die bei klassischen Dokumentationen nur mit viel Übersetzungs- und Erklärungsaufwand möglich ist. Wissen, das bei Dokumentationen bereits gefiltert und analytisch zergliedert worden ist, findet sich bei Prototypen in unzerteilter Form vor und ist für Beobachter unmittelbarer, aber eben auch impliziter erkennbar. Die daraus ermöglichten Formen der Wissenskommunikation bieten Chancen sowohl für die Steuerung der Wissensprozesse im Produktentwicklungsprozess als auch für die Kommunikation des späteren Produktkonzeptes zu Dritten innerhalb und außerhalb der Organisation. Dies stellen wir in den folgenden Abschnitten dar.

Grundannahme unserer Argumentation ist, dass Prototypen Kommunikationsagenten sind, die Kommunikation zwischen Subjekten in direkter und indirekter Form ermöglichen. Darauf aufbauend unterscheiden wir drei Anwendungsbereiche von Design-Prototypen für das Wissensmanagement von Produktentwicklungsprozessen:

1. Der Prototyp als Agent zum Abgleich von Wissen innerhalb des Design-Teams (Beobachtung erster Ordnung)
2. Der Prototyp als Agent zum Abgleich von Wissen gegenüber Nutzergruppen (Beobachtung zweiter Ordnung)
3. Der Prototyp als Agent zum Transfer von Wissen gegenüber Dritten (Beobachtung dritter Ordnung)

Im Folgenden werden wir diese drei Bereiche genauer beschreiben.

1) Der Prototyp als Agent zum Abgleich von Wissen innerhalb des Design-Teams (Beobachtung erster Ordnung)

Zunächst bestehen unterschiedliche abstrakte Ideen und Vorstellungen innerhalb des Design-Teams darüber, wie mögliche Produkte, Services und Lösungen aussehen könnten. Iterative Prototyping-Sequenzen innerhalb des Designprozesses unterstützen das Design-Team dabei, ihre Ideen greifbar und möglichst konkret darzustellen. Der Design-Prototyp ist ein vorläufiges Ergebnis eines gegenseitigen Wissensabgleichs. Das Team bringt verschiedene Ideen ein und trifft eine Auswahl, die sich durch Gestaltung eines Prototyps für alle Teilnehmer konkretisiert. Oftmals wird erst mit Fertigstellung des ersten Prototyps für alle erkennbar, inwiefern tatsächlich Einigkeit über die vereinbarte Idee innerhalb des Teams besteht, bzw. inwiefern mehr oder weniger unterschiedliche implizite Designvorstellungen vorliegen. An dieser Stelle ist der Prototyp im Sinne von Schön ein Reflexionsmoment für seine Gestalter, also ein Agent, der zurückkommuniziert (Schön, 1983). Oftmals entzündet sich unmittelbar nach der Gestaltung des Prototyps eine notwendige Diskussion darüber, ob individuelle Erwartungen möglicherweise enttäuscht oder bestätigt wurden und ob Missverständnisse bezüglich der abstrakten Design-Vision bestehen. Der Prototyp provoziert diejenigen, die sich mit ihren Ideen nicht wieder finden, ihr Wissen und ihre Erwartungen offen zu legen.


Abb.1: Der Prototyp als Reflexionsmoment innerhalb des Design-Teams

Konkret gesagt: Es ist bequem und möglich, sich auf eine gemeinsame Idee zu einigen, in dem man sie in einem möglichst abstrakten Umfeld belässt. Sobald jedoch ein manifester Prototyp entsteht, konfrontiert sich das Team gegenseitig mit möglicherweise divergierenden Erwartungen und Spielräumen. Fällt meine Interpretation der Idee nicht mehr in diesen Spielraum, wird es mir nun deutlich vor Augen geführt und ich muss mich entweder in der Diskussion für meine Interpretation und meine Erwartung einsetzen oder lasse mich von einer anderen Erwartung überzeugen. Oder ich erfahre, dass die unterschiedlichen Erwartungen im Team sich nicht vereinbaren lassen. Auch dies wäre eine mögliche Erkenntnis, die ich aus der Beobachtung des Prototyps ziehen kann. Auch nonverbale Abstimmungen können die Folge sein, in dem der Prototyp einvernehmlich weiterentwickelt wird, ohne dass dafür stets Begründungen geliefert werden.

2) Der Prototyp als Agent zum Abgleich von Wissen gegenüber Nutzergruppen (Beobachtung zweiter Ordnung)

Die Beobachtung zweiter Ordnung ist dem internen Wissensabgleich nachgestellt. Geht man davon aus, dass sich das Team auf eine vorläufige Interpretation der Idee in Form eines Prototyps einigen konnte, kann es nun zu einer Beobachtung der Nutzer kommen, bzw. von Klienten, Kunden oder anderen Ratsuchenden, die im Fokus der Arbeit des Design-Teams stehen (Rambow & Bromme, 2000). Dazu wird der Prototyp überreicht und zur Interpretation freigegeben. Die Nutzer beobachten und interpretieren den Prototypen, in dem sie beispielsweise damit interagieren oder für sie offene Fragen aufwerfen.


Abb. 2: Der Prototyp wird Nutzergruppen vorgestellt um deren Reaktionen zu beobachten

Aus diesen Interpretationen kann das Design-Team Rückschlüsse daraus ziehen, welche Design-Vision der Prototyp gegenüber den Nutzern letztendlich entfaltet, und wie diese von der ursprünglichen Vision der Designer differiert. Ebenso ist es denkbar, dass das Feedback der Nutzer dem Team Aufschluss darüber liefert, inwiefern ihre Design-Vision möglicherweise fehlgeleitet ist und überarbeitet werden muss. Die Kommunikation mit externen Nutzern über Prototypen kann unterschiedliche Ziele haben. So kann es sinnvoll sein, bereits sehr unvollständige Prototypen einem Feedback auszusetzen, um die generelle Akzeptanz zur Funktion und Idee zu erfahren.

Weiterentwickelte Prototypen können den Kunden und Nutzern vorgestellt werden, um zu erfahren, ob diese die Bedienbarkeit, die Ästhetik oder bereits konkrete Funktionalitäten verstehen und annehmen. Die aus diesem Feedback-Prozess gewonnenen Einsichten müssen vom Design-Team auf sinnvolle Weise erfasst und innerhalb des Teams kommuniziert werden, damit sich daraus entsprechende Handlungsempfehlungen ableiten lassen mit denen der Prototyp weiter entwickelt wird.


Abb. 1: Rückschlüsse aus der Nutzerbeobachtung werden am Prototyp reflektiert

3) Der Prototyp als Agent zum Transfer von Wissen gegenüber Dritten

Die spätere Übersetzung der Design-Prototypen in fertige Produkte und Services ist in hohem Maße von Stakeholdern abhängig, die nicht an der Entwicklung der Ideen beteiligt waren (etwa Vorgesetzte, Marketingfachleute, nachgelagerte Entwickler etc.). Hier braucht es einen strukturierten Transfer des relevanten impliziten Wissens von Seiten des Design-Teams. Die Gefahr besteht, dass unterschiedliche Interpretationen, sofern sie nicht thematisiert werden, dazu führen, dass durchdachte Ideen abgelehnt werden, weil das Management oder die Entwicklung nicht erkennt, welche Ideen und Erwartungen damit verknüpft sind: „Good ideas may be rejected by ill-informed executives based on what is perceived as inadequate execution of the prototype.“ (Schrage, 2006, S.7). Die Thematisierung des relevanten impliziten Wissens kann durch den finalen Design-Prototypen unterstützt werden, sofern er die relevanten Entscheidungen aus dem Designprozess thematisiert, also möglichst vollständig abbildet. Der finale Design-Prototyp muss daher nicht allein als reine Form überzeugen, sondern insbesondere die im Designprozess erarbeiteten Begründungsketten, die zu bestimmten Entscheidungen geführt haben, offen legen.

Allerdings ist auch der finale Design-Prototyp eine notwendige, aber keine hinreichende Bedingung für einen erfolgreichen Wissenstransfer. Vielmehr sollte sich an ihn ein strukturierter Dialog zwischen dem Design-Team und den Stakeholdern anknüpfen. Aus unserer Sicht liefert der finale Design-Prototyp als Manifestation die entscheidende Grundlage für einen solchen Dialog. Der Dialog dient nicht nur dazu, Missverständnisse zu thematisieren, sondern auch die Expertise der Stakeholder zu nutzen, um Feedback zu dem Design-Prototyp einzuholen. Die Rückkopplung mag dazu dienen, den Design-Prototyp nun im Hinblick auf seine technische Machbarkeit oder auch seine Wirtschaftlichkeit zu thematisieren und sich nicht allein auf die Nutzerperspektive zu beschränken. Hier findet der Übergang von einem Designprozess zum eigentlichen Entwicklungsprozess statt, die beide als Teil eines Innovationsprozesses zu verstehen sind. Der Design-Prototyp ist ein nützliches Tool, um relevantes implizites Wissen an dieser wichtigen Schnittstelle zu thematisieren.


Abb. 4: Die Wissensübergabe aus dem Designprozess erfolgt auf Basis des Prototypen und der Erläuterung seiner Entwicklungsstufen

Fazit und Ausblick

Die frühe Gestaltung von Design-Prototypen in Innovationsprozessen unterstützt teaminterne, wie auch abteilungs- und organisationsübergreifende Wissensmanagementprozesse. Der Prototyp kann den Wissensabgleich zwischen Team-Mitgliedern in einer frühen Design-Phase befördern, er kann zudem einen Wissensabgleich mit den Nutzergruppen einleiten sowie einen Wissenstransfer zu Stakeholdern im weiteren Entwicklungsprozess ermöglichen. Dieses zeigen auch unsere Beobachtungen und erste Befragungen mit Experten. In allen drei Anwendungsbereichen ist der Design-Prototyp allerdings nicht selbsterklärend, sondern auf die Einbettung in einen strukturierten Dialog angewiesen. Prototypen erleichtern insbesondere die Kommunikation und Thematisierung impliziten Wissens, welches bei klassischen Kommunikationsmedien im Wissensmanagement inhärent ausgelassen wird. Dies macht sie zu interessanten, allerdings auch herausfordernden Instrumenten für das Wissensmanagement. Ihre Verwendung bedarf einer genaueren Erforschung.

Literatur

Boland, Richard (2004): Managing as Designing, Stanford: Stanford Press.
Houde, Stephanie & Hill, Charles (1997): What do Prototypes Prototype?, in: Handbook of Human-Computer Interaction, M. Helander, T.Ê Landauer, and P. Prabhu (eds.), Amsterdam: Elsevier Science.
Lim et al., (2008): The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Trans. Comput.-Hum. Interact., Vol. 15, No. 2., pp. 1-27
Martin, Roger (2009): The Design of Business, Boston: Harvard Business Press.
Rambow. Riklef & Bromme, Rainer (2000): Was Schöns Reflective Practitioner durch die Kommunikation mit Laien lernen könnte, in: H.G. Neuweg (Hrsg.), Wissen-Können-Reflexion. Ausgewählte Verhältnisbestimmungen, Innsbruck: Studienverlag.
Schön, Donald (1983): The Reflective Practitioner, London: Ashgate.
Schrage, Michael (2006): Cultures of Prototyping, Online-Version (http://hci.stanford.edu/publications/bds/10-Schrage.pdf, zuletzt aufgerufen am 21.9.2011).

Anmerkung zu den Illustrationen

Die Illustrationen in diesem Text sind von Birgit Jobst, Industriedesignerin und Stipendiatin am Hasso-Plattner Institut in Potsdam, gestaltet worden.

About

Die Autoren Holger Rhinow, Eva Köppen und Tilmann Lindberg sind Stipendiaten im Design Thinking Research Program am Hasso-Plattner-Institut in Potsdam. Sie befassen sich in ihrer Forschung mit Fragen der Integration des Design-Thinking-Ansatzes in Organisationen. Der Autor Prof. Dr. Christoph Meinel ist Geschäftsführer am Hasso-Plattner-Institut in Potsdam und Projektleiter innerhalb des Design Thinking Research Programs. Weitere Informationen finden Sie unter: http://www.hpi.uni-potsdam.de/forschung/design_thinking_research_program/programm.html 



Lizenziert unter einer Creative-Commmons Lizenz