eJournals PROJEKTMANAGEMENT AKTUELL 14/2

PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
61
2003
142 GPM Deutsche Gesellschaft für Projektmanagement e. V.

Projektintegrierte Know-how-Sicherung

61
2003
Jörg Longmuß
Manfred Mühlfelder
Projektintegriertes Wissensmanagement ist erforderlich zur Unterstützung des Wissensflusses und der Kommunikation in Projektteams und der Ergebnissicherung für zukünftige Projekte. Nachdem der Versuch, unternehmensweite, einheitliche Wissensmanagementsysteme für die Projektarbeit aufzubauen, oft die Erwartungen der Auftraggeber nicht erfüllt hat, konzentriert sich der hier vorgestellte Aufsatz auf dezentrale, praktische Vorgehensweisen, welche ohne zusätzliche Investitionen in Informations- und Kommunikationstechnik umsetzbar sind, schon bei der Bewältigung der Alltagsarbeit unmittelbar nützlich sind und die auf einen praktischen Mehrwert von Wissensmanagementaktivitäten für jeden einzelnen Projektmitarbeiter setzen. Er zielt darauf ab, die Motivation der Beteiligten zu einem selbst gesteuerten Wissensmanagement zu erhöhen. Deshalb wird gezielt auf die Know-how-Sicherung in Projekten mit Schwerpunkt auf der Produktentstehung fokussiert. Anhand eines praktischen Beispiels aus der Konsumgüterindustrie wird dargestellt, wie dies mittels einer „Baseline“ realisiert werden kann.
pm1420022
22฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Projektintegrierte฀ Know-how-Sicherung Praktisches฀Wissensmanagement฀in฀der฀Produktentstehung Jörg฀Longmuß,฀Manfred฀Mühlfelder Projektintegriertes฀Wissensmanagement฀ist฀erforderlich฀zur฀Unterstützung฀des฀Wissensflusses฀und฀der฀Kommunikation฀in฀Projektteams฀und฀der฀Ergebnissicherung฀für฀zukünftige฀ Projekte.฀Nachdem฀der฀Versuch,฀unternehmensweite,฀einheitliche฀Wissensmanagementsysteme฀für฀die฀Projektarbeit฀aufzubauen,฀oft฀die฀Erwartungen฀der฀Auftraggeber฀nicht฀erfüllt฀ hat,฀konzentriert฀sich฀der฀hier฀vorgestellte฀Ansatz฀auf฀dezentrale,฀praktische฀Vorgehensweisen,฀welche฀ohne฀zusätzliche฀Investitionen฀in฀Informations-฀und฀Kommunikationstechnik฀ umsetzbar฀sind,฀schon฀bei฀der฀Bewältigung฀der฀Alltagsarbeit฀unmittelbar฀nützlich฀sind฀und฀ die฀auf฀einen฀praktischen฀Mehrwert฀von฀Wissensmanagementaktivitäten฀für฀jeden฀einzelnen฀Projektmitarbeiter฀setzen.฀Er฀zielt฀darauf฀ab,฀die฀Motivation฀der฀Beteiligten฀zu฀einem฀ selbst฀gesteuerten฀Wissensmanagement฀zu฀erhöhen. Deshalb฀wird฀gezielt฀auf฀die฀Know-how-Sicherung฀in฀Projekten฀mit฀Schwerpunkt฀auf฀der฀ Produktentstehung฀fokussiert.฀Anhand฀eines฀praktischen฀Beispiels฀aus฀der฀Konsumgüterindustrie฀wird฀dargestellt,฀wie฀dies฀mittels฀einer฀„Baseline“฀realisiert฀werden฀kann. 1฀ Probleme฀des฀konventionellen฀Wissensmanagements฀für฀Projektarbeit 1.1฀ Was฀ist฀„konventionelles“฀Wissensmanagement? Das Problem ist allseits bekannt: Je stärker in Projekten gearbeitet wird, desto weniger eindeutig ist der Ort im Unternehmen, an dem entstandenes Wissen nach Abschluss der Arbeiten wieder auffindbar ist (zur generellen Frage des Wissensmanagements in Projekten siehe z. B. [1, 2]). Umso wichtiger ist es, zu Beginn, während des Verlaufs und am Ende eines Projektes den Wissensstand und die Projekterfahrungen zu sammeln und auszuwerten. Diese Auswertungen sind eine entscheidende Wissensquelle, die für zukünftige und parallel laufende Projekte zur Verfügung steht, sowohl auf der Ebene der Fachprozesse (technisches Fachwissen) als auch auf der Ebene des Projektmanagements (Steuerungswissen). Die Diskussion um Wissensmanagement im Projektmanagement allgemein und speziell in der Produktentstehung ist bislang überwiegend auf zentralisierte Systeme und Methoden konzentriert. Abb. 1 zeigt eine solche konventionelle Wissensmanagement-Strategie, die auf die zentrale Redaktion des fachlichen Inputs der einzelnen Fachabteilungen (z. B. Marketing, Entwicklung, Produktionsplanung, Einkauf etc.) durch eine Stabsfunktion (z. B. in der Funktion eines „Chief Knowledge Officer“) setzt. Die operativen Mitarbeiter können dann in der unternehmensweiten Wissensplattform nach Daten, Berichten und Personen mit Spezialkenntnissen suchen und die Ergebnisse für ihre eigene Arbeit nutzen. Diese Herangehensweise an das Thema „Wissensmanagement“ war in den letzten Jahren am meisten verbreitet, vor allem in solchen Unternehmen, die nach Inhalten für ihr neu und teuer geschaffenes Intranet suchten. Beispiele für konventionelles Wissensmanagement sind:  Sammlung und Standardisierung von Methoden, Arbeits- und Geschäftsprozessen mit dem Ziel des unternehmensweiten Transfers und der Adaptation von „best practices“,  zentrale Wissensdatenbanken, z. B. zur Archivierung von Versuchsberichten, Qualifikationsprofilen von Experten etc.,  anwendungsorientierte Wissensverarbeitung: data mining, collaborative filtering, profiling, agent based information retrieval etc. Die Erfahrung zeigt, dass eine solche konventionelle Wissensmanagementstrategie die Bereitschaft der Mitarbeiter zur Aufbereitung ihres Wissens nicht fördert (vergleiche z. B. [3, 4]). Dies hat mehrere Gründe:  Zum Ersten werden in den Projektbudgets meist keine oder nur geringe Ressourcen für Wissensmanagementaktivitäten eingeplant. Die Mitarbeiter haben oft keine Zeit, ihr Wissen zu dokumentieren und anderen zur Verfügung zu stellen.  Zum Zweiten besteht für die Projektmitarbeiter kein Anreiz, ihr Wissen so aufzubereiten, dass es in anderen Projekten wieder verwendbar ist. Aufgrund des Einmaligkeitscharakters von Problemen in der Projektabwicklung wird am Nutzen von Wissensmanagement als Mehrwert sowohl für die eigene Arbeit als auch für das Unternehmen gezweifelt. 22฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3  Zum Dritten besteht bei einigen dieser Ansätze die Gefahr, dass zum vorgesehenen Zeitpunkt der Dokumentation wichtige Mitarbeiter nicht mehr greifbar oder gemachte Erfahrungen nicht mehr präsent sind. Der Zusatzaufwand der Mitarbeiter zur Bereitstellung von Wissensinhalten muss daher oft durch Bonus- und Anreizsysteme und/ oder einen umfangreichen Ressourceneinsatz erkauft werden (z. B. Beschäftigung von externen Wissensredakteuren, Ausfallzeiten für Wissensaufbereitung und -dokumentation etc.). Vor allem aber zeigt die Praxis, dass zentral abgelegtes Unternehmenswissen meist nur wenig nachgefragt wird und daher aus betrieblicher Sicht ebenso unwirtschaftlich ist wie z. B. ein schlecht gepflegtes Materiallager. Dies liegt unter anderem daran, dass sich jedes Unternehmen nach Beginn einer Wissensmanagementinitiative ein Mengenproblem einhandelt. Anfangs wird jeder Eintrag in die Wissensdatenbank als weiterer Baustein des Unternehmenswissens gefeiert. Je umfangreicher die Wissenssammlung jedoch dann wird, desto aufwändiger wird die Suche nach dem „richtigen“ Wissen und umso geringer ist die Wahrscheinlichkeit, in begrenzter Zeit das benötigte Wissen zu finden. 1.2฀ Das฀Problem฀der฀Kontextbindung: ฀Explizites฀und฀ implizites฀Wissen Das hauptsächliche Problem konventionellen Wissensmanagements aber liegt nicht nur und nicht vor allem in einer möglicherweise unzureichenden Umsetzung der Lehrbuchinhalte in die Praxis; es hat auch zumindest einen strukturellen Grund: die Vernachlässigung der Kontextbindung von Wissen. Ohne eine Kenntnis des Umfeldes, in dem Wissen entstanden ist und seine Bedeutung erhalten hat, und der dazugehörigen Lerngeschichte ist seine Relevanz für ein neues Problem kaum abschätzbar [5]. In diesem Zusammenhang ist die Unterscheidung zwischen explizitem und implizitem Wissen wichtig. Explizites Wissen ist nicht personengebunden und liegt z. B. in Form von Dokumenten und Zeichnungen vor. Implizites Wissen hingegen liegt in den Köpfen jedes Mitarbeiters und wird z. B. als „persönliche Erfahrung“ oder als „Gespür für Sachverhalte“ bezeichnet. Daher ist implizites Wissen auch nur schwer an neue oder jüngere Kollegen ohne die entsprechende eigene Erfahrung vermittelbar. Jedes neu entstandene Wissen liegt zunächst implizit vor. Erst durch zusätzliche Aktivitäten wird es von seinem Kontext befreit und aus dem konkreten Anwendungszusammenhang herausgelöst. Es wird damit zu explizitem Wissen. Abb. 2 zeigt diesen Prozess der Umwandlung von implizitem in explizites Wissen und seine Rückwandlung durch Re-Kontextualisierung und Internalisierung. Ein Beispiel für diesen Transformationsprozess ist die Anfertigung eines Versuchsberichts unter Angabe des Verfahrens und der Ergebnisse. Wird der Kontext des Versuchs, z. B. die aufwändige Programmierung der Messprozedur oder das mühsame Ausmerzen von Fehlerquellen in der Durchführung, nicht mit dokumentiert, bleibt das explizit dokumentierte Wissen unvollständig und wird unter Umständen nutzlos, weil die Umstände, unter denen ein Versuchsergebnis erzielt worden ist, gedanklich nicht mehr nachvollzogen werden können. Je weiter Wissen aus dem ursprünglichen Kontext entfernt wird, desto abstrakter und umfangreicher wird seine Darstellung. Entsprechend ist es sehr aufwändig, dieses Wissen zu verstehen und es in einer anderen als der Entstehungssituation zu nutzen. In der Projektarbeit kann dies zum Problem werden, da die Rahmenbedingungen ständigen Veränderungen unterworfen sind und daher der Kontext jeweils einmaligen ������������������������� ����������������������������������������������������� ����������� ����������� ��������������������������������� ��������������������������� ����������� ��� ������������������������� ����������������������������������������������������� ����������� ����������� ��������������������������������� ��������������������������� ����������� ��� ������������������������� ��������������������������������������������������� � ����������� ����������� ��������������������������������� ��������������������������� ����������� ��� Abb.฀1: ฀Zentralisiertes฀Wissensmanagement ����������������� � � � ������ � � � ������ � � � ������� � ����������� � � � �������� � � � �������� � � � ��������� � ���������� � ��������� ����������� ��������� � �� � � � ������������������ � ���������� � ������� ����������� ��������� ����������� ���������� ���������������� � ������� ��������� � �� � � � ������������������ � Abb.฀2: ฀Wissensdiffusion฀nach฀Brödner฀[5] 24฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Charakter hat. Ein neues Produkt wird nur einmal in einer ganz bestimmten Marktkonstellation und unter bestimmten technologischen Voraussetzungen von einem einzigartigen Projektteam entwickelt. Soll ein ähnliches Produkt unter anderen Ausgangsbedingungen entwickelt werden und kann das neue Projektteam dabei auf explizites Wissen der Vorgänger zurückgreifen (z. B. Zeichnungen, Pflichtenhefte etc.), so lassen sich möglicherweise Problemlösungen kopieren und wieder verwenden. Die Übertragung dieses Wissens auf die eigene Problemstellung ist jedoch daran gebunden, dass die Nachfolger auch den ursprünglichen Kontext mitgeliefert bekommen, um bestimmte Entscheidungen und technische Lösungen überhaupt verstehen zu können. Als Fazit dieser kurzen Betrachtungen bleibt demnach festzuhalten, dass ein „konventionelles“, zentralistisches Wissensmanagement insgesamt wenig zum Unternehmenserfolg beiträgt, da das aufwändig gesammelte Wissen nur relativ begrenzt verwertbar ist und von den Mitarbeitern nur unzureichend für die eigene Projektarbeit genutzt werden kann, weil sein Entstehungskontext nicht mehr zugänglich ist. Es bedarf daher neuer Methoden, die das Wissensmanagement in die Projektarbeit integrieren und die Übertragbarkeit von Lösungen auf neue Probleme in ähnlichen Projekten unter Vermittlung des jeweiligen Kontextes ermöglichen. 2฀ Lösungsstrategie: ฀Projektintegriertes฀Wissensmanagement 2.1฀ Ausrichtung฀an฀der฀Projektebene Aus diesen Erfahrungen ergibt sich ein Bedarf an Konzepten und Lösungen für die Verlagerung des Wissensmanagements aus zentralen Stabsfunktionen in die operative Prozess- und Projektebene. Die Mitarbeiter dort sollten dazu berechtigt und qualifiziert werden, ihr Wissen selbst zu managen, da vor allem in der fachlichen und inhaltlichen Auseinandersetzung mit anderen Wissensträgern neue Ideen für innovative Projekte und effiziente Arbeitsprozesse entstehen. Die Verlagerung auf die operativen Einheiten zielt darauf ab, dass die Schritte zur Aufarbeitung, Speicherung und Weitergabe von Wissen gleichzeitig möglichst unmittelbar dem eigenen Arbeitsfortschritt im Projekt dienen. Dass dieses Wissen dann nicht mehr unbedingt in unternehmenseinheitlicher Form vorliegt, wird im Interesse der problemnahen Einsetzbarkeit in der Praxis in Kauf genommen. 2.2฀ Know-how-Sicherung฀in฀der฀Projektarbeit Im Gegensatz zu den eingangs beschriebenen konventionellen Konzepten ist es nach unseren Erfahrungen hilfreich,  Projektprozesse so zu strukturieren, dass möglichst viel Wissen „automatisch“ explizit wird, und  sich im Interesse von Verfahrensökonomie und Wiederverwendbarkeit auf solches Wissen zu beschränken, das ohnehin, z. B. in Form von Projektdokumenten, technischen Zeichnungen, Kontrollberichten, Berechnungen etc., explizit gemacht werden muss. Es geht also im Kern um eine unmittelbare Know-how- Sicherung für die Projektarbeit. Soll sie erfolgreich sein, darf dies nicht vor allem neue IT-Systeme, zusätzliche Routinen und neue Dokumente bedeuten. Vielmehr sollten die Systeme, Routinen und Dokumente, die ohnehin zur Gestaltung der Prozesse eingesetzt, durchgeführt bzw. angefertigt werden müssen, so gestaltet sein, dass das damit erworbene bzw. darin enthaltene Wissen leicht archiviert, verteilt und anderen zugänglich gemacht werden kann. Bereits übliche und erprobte Methoden der Prozessbeschreibung und Prozesssicherung sind zu ergänzen/ überarbeiten, ohne ein grundsätzlich neues Feld zu bestellen. Der zusätzliche Aufwand ist dann relativ gering. Im Gegenzug unterstützt ein solches projektintegriertes Wissensmanagement das Projektteam dabei, die Arbeitsprozesse zu strukturieren. Unter diesem Blickwinkel fordert Wissensmanagement keinen Zusatzaufwand, sondern die Beachtung von Standards eines guten Projektmanagements. Der entscheidende Vorteil ist, dass der Kontext insgesamt, aber auch die konkreten Formate (z. B. Lastenhefte, Vorlagen für Reporte, Zielkosten-Aufstellungen, Meilenstein-Checklisten) nicht nur innerhalb eines Projekts, sondern auch projektübergreifend allen Beteiligten vertraut sind. Gleichzeitig wird damit, auch wenn es nur ein Nebeneffekt ist, eine zusätzliche Motivation zur Einhaltung verabredeter Prozesse geschaffen. Dabei ist informationstechnische Unterstützung, etwa Auswahl und Einsatz von Software für das Dokumentenmanagement, zwar hilfreich (siehe z. B. [6]), aber nicht das Allheilmittel. Sie ist gut geeignet zum Sammeln und Aufbereiten von Informationen, weniger gut zur Kommunikation expliziten Wissens, aber kaum nutzbar, um das implizite Wissen, das in der Alltagsarbeit entsteht, für nachfolgende oder parallele Projekte nutzbar zu machen. 2.3฀ Die฀Bedeutung฀einfacher฀Instrumente฀im฀ Projektalltag Wissen sollte also bereits bei seiner Entstehung im Projektverlauf kenntlich gemacht und so aufbereitet werden, dass es später von Personen, die nicht an seiner Entstehung unmittelbar beteiligt waren, möglichst problemlos gefunden, verstanden und eingesetzt werden kann. Dabei ist einfachen Lösungen der Vorzug gegenüber komplexen, d. h. unternehmensweiten zu geben, die ohne großen Aufwand in den Arbeitsablauf integriert werden können und bei denen die „Absender“ den „Adressaten“ klar vor Augen haben. Da die Mitarbeiter in ihrem Arbeitsalltag beide Rollen innehaben, können sie so das Wissen in seinem Kontext verstehen und es für die eigene Tätigkeit nutzbar machen. Eine „80 %“-Variante, welche die wesentlichen Anforderungen erfüllt, aber einfach eingerichtet, geändert und ggf. ohne Verlust wieder abgeschafft werden kann, ist dafür oft effektiver als eine auf Vollständigkeit bedachte „100 %“-Lösung, die jedoch bei geringfügiger Änderung der Rahmenbedingungen unbrauchbar wird. Als positive Beispiele mögen dienen:  Bei einem Hersteller von Kleinserien-Blechteilen, bei dem es immer wieder Kommunikationsschwierigkeiten in der Fertigungskette gab (Konstruktion, Etap- 24฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 pen der Werkzeugerstellung, Umformen, Finishing), wurde eine „Werkzeug-Akte“ eingeführt, die jedes Teil bzw. jede Kleinserie über den gesamten Prozess begleitet. In dieser Akte werden alle relevanten Informationen (z. B. Verständnis-, Fertigungs- und Einsatzprobleme) objektbezogen zusammengefasst und ausgewertet. Dieses Wissen steht dann der Konstruktionsabteilung für das nächste Vorhaben zur Verfügung [7].  Um auf Probleme in der Produktion schneller und effektiver reagieren zu können, wurden in einem Unternehmen alle Fertigungs- und Montagebereiche mit Digitalkameras ausgerüstet. In Verbindung mit dem firmeneigenen Intranet können so alle Schwierigkeiten mit minimalem Aufwand für die Dokumentation und minimaler Zeitverzögerung an die Konstruktion zurückgemeldet werden [7].  In der Entwicklungsabteilung für lichttechnische Geräte eines Automobilherstellers tauchten immer wieder Nachfragen auf, welche Leuchte mit welcher Lampe (nach Hersteller und Produktnummer getrennt) ausgestattet wird. Eine einfache Tabelle, in der die Zuordnung fortgeschrieben wurde, erleichterte vor allem Neueinsteigern in der Abteilung, die mit der Betreuung von Serienteilen beauftragt wurden, die Auswahl des richtigen Leuchtmittels für die verschiedenen Varianten. Diese Strategie der einfachen Instrumente soll im Folgenden exemplarisch für die Know-how-Sicherung in Produktentstehungsprojekten dargestellt werden. Das bedeutet in diesem Kontext nicht nur die Weitergabe des Wissens von einem abgeschlossenen zu einem Nachfolgeprojekt, sondern auch Quermitteilungen von einem laufenden zu anderen Projekten, die sich in frühen Phasen befinden und von den neuesten Erfahrungen lernen wollen. Für diesen Zweck wird im Folgenden ein Instrument vorgestellt, das sich in Produktentstehungsprozessen bereits bewährt hat: die „Baseline“. 3฀ Die฀„Baseline“: ฀Eine฀strukturierte฀Dokumentation฀ des฀Projektstarts฀als฀Grundlage฀für฀den฀Produktentstehungsprozess Produkte werden üblicherweise entwickelt anhand eines - meist schrittweise konkretisierten - Lastenheftes mit allen technischen Spezifikationen, häufig noch ergänzt um eine Finanzkalkulation. Bei komplexen Produkten ist es sinnvoll, dies mit einer strukturierten Dokumentation aller darüber hinausgehenden Zielgrößen, Vereinbarungen und Annahmen bereits zum Projektstart zu verknüpfen. Dieses als „Baseline“ bezeichnete Dokument findet unter verschiedenen Bezeichnungen im Management von Produktentstehungsprozessen zunehmend Anwendung. In ihr wird der Ausgangspunkt eines Projektes mitsamt den darin enthaltenen Annahmen dokumentiert, und zwar: nach außen: die formellen Verträge mit dem Kunden (bei externen Auftraggebern) bzw. der Projektauftrag (bei internem Auftraggeber) einschließlich des gesamten (ggf. nicht expliziten) Vereinbarungsstandes über Lastenheft und Angebot hinaus; nach innen: die Zusammenfassung der eigenen Annahmen, Zielgrößen, Unsicherheiten (! ), Pläne und des eigenen Kenntnisstandes. Die Daten der „Baseline“ stellen das „Fleisch auf den Knochen“ des Projektmanagement-Handbuchs dar: Sie beinhalten Zusatzinformationen zu den technischen und betriebswirtschaftlichen Zahlen in den Lastenheften und den Controlling-Sheets. Dabei entsprechen sich ökonomische und technische Betrachtungen und sind ineinander überführbar: Die angestrebten Produktmerkmale führen zu einer bestimmten Kostenkalkulation und einem entsprechenden Budget; umgekehrt lassen sich technische Eigenschaften des Produkts aus den ökonomischen Randbedingungen heraus bestimmen. Mit Hilfe der „Baseline“ werden alle grundlegenden Annahmen zusammengeführt, die das Projekt kennzeichnen. Die „Baseline“ ist jedoch nicht mit dem Lasten- oder Pflichtenheft identisch. Sie erhebt nicht deren Anspruch auf Detailtiefe und Vollständigkeit, sondern konzentriert sich eher auf die Erfassung des Projekt- und Produktumfeldes. Außerdem ist sie ein „lebendes“ Dokument“, d. h., sie liegt nicht zu einem bestimmten Zeitpunkt in abschließender Form vor, sondern wird während des Produktentstehungsprozesses kontinuierlich fortgeschrieben, erweitert und ergänzt. Die „Baseline“ dient dem Abgleich unterschiedlicher Informationsstände und -quellen, Denkmodelle und Herangehensweisen der beteiligten Abteilungen und Hierarchiestufen. Damit hilft sie, auch implizites Wissen aus den Köpfen der Mitarbeiter herauszuholen und die persönlichen, durchaus unterschiedlichen (Vor-)Erfahrungen schriftlich festzuhalten. Am folgenden Praxisbeispiel sollen die grundlegende Struktur und einige konkrete Punkte einer „Baseline“ erläutert und in ihrer Funktion verdeutlicht werden. 3.1฀ Beispiel: ฀„Baseline“฀für฀eine฀Produktreihe฀im฀ Haushaltsbereich Die hier vorgestellte „Baseline“ wurde für Projekte der Produktentwicklung (im Unterschied zur Vorentwicklung) im Bereich der „weißen Ware“, d. h. aufwändigerer Konsumgüter im Haushaltsbereich, entwickelt. Sie ist in Frageform aufgebaut und enthält insgesamt über 150 Fragen, von denen in Abb. 3 einige für verschiedene Bereiche exemplarisch dargestellt sind. Der Produktentstehungsprozess, der ihr zugrunde liegt, besteht aus den drei Hauptphasen  Konzeptentwurf,  Konzeptabsicherung und  Serienentwicklung. Die erste Formulierung der „Baseline“ findet hauptsächlich während der Konzeptabsicherung über die einzelnen Meilensteine hinweg statt und wird während der Serienentwicklung fortgeführt und überarbeitet. Dazu wird sie in Tabellenform so angelegt, dass Revisionen schnell und übersichtlich durchgeführt werden können und leicht erkennbar und nachvollziehbar sind (siehe Abb. 4). Diese hier vorgestellte „Baseline“ ist als Format mit wenigen Änderungen für verschiedene Haushaltsgeräte einsetzbar. Allerdings ist die Weiterverwendung der dokumentierten Informationen und Erfahrungen, also des gewonnenen Wissens, in vieler Hinsicht nur innerhalb konkreter Produktreihen möglich, da sich z. B. Wäschetrockner und Geschirrspülmaschinen in den meisten Features zu stark unterscheiden. 26฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 3.2฀ Einsatz฀der฀„Baseline“฀im฀Projektalltag Die „Baseline“ ist ein zentrales Projektdokument, dessen aktueller Stand als mitgeltende Unterlage in verschiedenen Genehmigungsphasen eines Projekts durch die Entscheider verwendet werden kann. Sie kann neben den internen Adressaten (z. B. Projektsteuerkreis) auch externe Entwicklungspartner (z. B. Zulieferunternehmen, Kunden) ansprechen. Wenn z. B. aus Geheimhaltungsgründen einzelne Teile besonders vertraulich behandelt werden müssen, können verschiedene Varianten der „Baseline“ existieren. Sie gewährleistet einen Projektstart auf Grundlage des im Moment verfügbaren Wissens, und zwar unter ausdrücklicher Kennzeichnung der Unsicherheit, also des noch nicht vorhandenen Wissens. Sie ist gleichzeitig Ausgangspunkt für „Change Management“ bez. Konstruktionsänderungen, da sie die Bezugsgröße für alle ������������� ������������������������� �������������������� ����������������������������� ����������������������������������� ������������������������������������������������������������������������ ����� ���������������������� ��������������������� ����������������������������������������������������������������� ����������������������������������������������������������������� ������������������������������������������������������������������� ����� �������������������������� ���������������������������������������������������������������������� ������������������������������������������������������ ����� ���������������������������������������������� ���� ��������������������������� ��������������� ������������������������������������������������������� ����� ���������������������������� ��������������������������������������������������������� ������������������������������������������������������� ����� ����������������������������� ������������� ����� �������������� ������������������������������������ ������������������������������������������������������������� ���������������������������������������������� ����� ����� ���������� ������������������������������������������������������������������������ ������������ ������������������������������������������������������������������������������������ ������������� ����������������������������������������������������������������������������� ����������������� ������������������������������������������������������������������������ ������������������������������������������� ���������������������������������������������������������������������������� Abb.฀3: ฀Auszug฀aus฀einer฀„Baseline“ 26฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Formen von Weiterentwicklung und Änderungen darstellt. Außerdem ermöglicht sie, die Weiterentwicklung und Veränderung von Kundenwünschen zu erkennen und ein konsequentes „Claim Management“ bezüglich der Leistungserbringung und -vergütung zu realisieren. Im laufenden Projekt kann der augenblickliche Entwicklungsstand ständig mit der „Baseline“ abgeglichen werden. Dabei sind verschiedene Arten von Inhalten zu unterscheiden:  Annahmen, die das Projektumfeld beschreiben (z. B. Kundenpräferenzen im Konsumgüterbereich, Vorstellungen und vermutete Änderungswünsche des Auftraggebers im Anlagen- und Zulieferbereich, Wechselkurse etc.);  Aufwandsabschätzungen, die Einfluss auf die Projektplanung haben (z. B. Zeit- und Ressourcenpläne);  Ziele, bei denen eine Änderung des augenblicklichen Entwicklungsstandes angestrebt wird. Die Erwartung, dass diese Änderungen im angestrebten Umfang auch eintreten, ist häufig sogar entscheidend für den Entschluss, das Projekt überhaupt durchzuführen. Beispiele dafür sind Zielkosten, die im Projektverlauf erreicht werden sollen („target costing“), Zielgewichte, Volumengrenzen etc.;  offene Fragen und unsichere Annahmen, die bewusst in die „Baseline“ aufgenommen werden. Dazu gehört z. B. die vorläufige Bestimmung von Lieferanten, die bei Projektbeginn noch nicht feststehen. Die Konkretisierung dieser unsicheren Annahmen kann entscheidende Informationen für die Projektleitung liefern. Es gilt dabei zu beobachten, inwieweit sich bestimmte Annahmen als realistisch erwiesen haben, welche Ziele wie weitgehend erreicht werden konnten, welche Fragen evtl. noch konkretisiert bzw. korrigiert werden müssen etc. Je nach Art der verwendeten Software können Planungsdaten sogar überhaupt nicht geändert werden, ohne den Grund der Änderung festzuhalten. Damit wird aber gleichzeitig und praktisch ohne gesonderten Aufwand das im Laufe des Projekts gewonnene Wissen explizit und projektspezifisch festgehalten. Zweckmäßigerweise wird eine solche „Baseline“ nicht nur für ein einzelnes Projekt angelegt, sondern in einer Standardstruktur auf Grundlage eines Referenz- Produktentstehungsprozesses (siehe z. B. [8]) bereitgestellt, die für alle vergleichbaren Projekte im Unternehmen (z. B. die verschiedenen Entwicklungsreihen von Waschmaschinen oder Berechnungsprogrammen, Nahverkehrszügen oder Autositzen) verwendbar ist. Damit spart sie im Multi-Projektmanagement Arbeit und schafft Transparenz: Fragen müssen nur einmal ausgearbeitet werden, einheitliche Berichtsformate erleichtern den Überblick über die Gesamtheit der Projekte, und die Einarbeitungszeit von Mitarbeitern bei einem Wechsel von einem Projekt in ein anderes wird kürzer. 3.3฀ Die฀„Baseline“฀als฀Wissensquelle฀für฀das฀ laufende฀Projekt฀und฀für฀folgende฀Projekte Das Anlegen und kontinuierliche Verfolgen einer solchen „Baseline“ sind also, in Übereinstimmung mit den Thesen aus dem Abschnitt 2, kein Aufwand, der eine zusätzliche „Wissensmanagement-Aktivität“ darstellt. Sie ist vielmehr vor allem ein Instrument für eine transparente Definition und Verfolgung eines Projekts. Gleichzeitig ist sie aber ein zentrales Dokument für die Know-how-Sicherung: Sind die „Baseline“-Strukturen der einzelnen Projekte identisch, können sowohl die ursprünglichen Annahmen im weitesten Sinne als auch deren Änderungen zwischen den Projekten in ihrem ursprünglichen Kontext verglichen bzw. beim Start neuer Projekte direkt genutzt werden. Ferner lassen sich die Änderungen (und die Gründe für die Änderungen, die ohnehin in den Projektbesprechungen klarzustellen sind) in einem einheitlichen Format darstellen. Der entscheidende Vorteil einer „Baseline“ besteht darin, dass das Format, in dem die Änderungsdokumentationen eines laufenden Projekts abgelegt werden, mit dem Format übereinstimmt, in dem die Ausgangssituation für ein neues Projekt beschrieben wird. Es können also Start-, Zwischen- und Endpunkte vorangegangener Projekte direkt verglichen werden und es können korrigierte Annahmen über  den Startpunkt,  den Endpunkt bzw.  eine Extrapolation der Differenz zwischen ursprünglichen Annahmen und den zu Projektende vorhandenen Größen in das neue Projekt eingestellt werden. Datum Angabe/ Wert Grund/ Anmerkung … … 3.2.2 Wo sehen wir Änderungsrisiken/ -chancen im Lastenheft? … … … Überarbeitung I … … … Überarbeitung II … … … 3.2.3 … Abb.฀4: ฀Aufbau฀der฀„Baseline“฀in฀Tabellenform฀ 28฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 29฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Da diese „lessons learned“ nicht unbedingt alle an einem Projekt beteiligten Fachbereiche und Abteilungen betreffen, können sie auch abteilungsspezifisch zugeschnitten werden (also z. B. in Form von Informationen über erzielte Lieferantenrabatte oder neue Layouts der Fertigungsanlagen). Damit ist auch eine Möglichkeit geschaffen, das gewonnene Wissen adressatenspezifisch auszuwählen und zu kommunizieren. 3.4฀ Gezieltes฀Einspeisen฀in฀die฀Organisation฀nötig Um das gewonnene Wissen in der Organisation wirksam werden zu lassen, sind entsprechende Vorgänge im Ablauf jedes neuen Produktentstehungsprojektes ausdrücklich vorzusehen:  Die Fachfunktionen sollen für ihren Input in der Projektdefinition (d. h. in die „Baseline“ des neuen Projekts) eine Analyse des Wissenszuwachses in vorhergehenden bzw. weiter fortgeschrittenen, parallel stattfindenden Projekten vornehmen.  In der Projektdefinition fließen die „lessons learned“ der Vorgängerprojekte in die „Baseline“ ein. Deren Grundstruktur dient als Schema zur Einordnung der vorhandenen Annahmen und Erfahrungen. Diese können dann beim „Kick off“ aufgearbeitet werden und in die konkrete Gestaltung und Ausstattung des neuen Projekts einfließen.  Im laufenden Projekt kann auf die Erfahrungen anderer Projekte durch die Verfolgung deren Entwicklungslinien, ausgehend von deren „Baseline“, zurückgegriffen werden. So wird mit Hilfe der „Baseline“ eine projektspezifische Sicherung von Erfahrungswissen erreicht. Projektmitarbeiter können ihr Wissen, das sie während der Projektbearbeitung erwerben, miteinander in Beziehung setzen und den jeweiligen Wissenszuwachs bewerten. Manche unsichere Annahmen zu Projektbeginn erweisen sich als tragfähig, andere als falsch, andere nur unter bestimmten Rahmenbedingungen als gültig. Durch den direkten Vergleich zweier Projekte anhand ihrer „Baselines“ können Rückschlüsse darüber gezogen werden, welche Maßnahmen zu welchen Resultaten geführt haben. Doppelarbeit kann vermieden und Prozessschritte abgekürzt werden. Die „Baseline“ dient dabei gleichzeitig als Referenz für den Wissenszuwachs und als definierte Schnittstelle zwischen verschiedenen Projekten im Sinne eines strategischen Wissensmanagements.  Literatur [1]฀Heisig,฀P.: ฀Erfahrung฀sichern฀und฀Wissen฀transferieren: ฀ Wissensmanagement฀im฀Projektmanagement.฀In: ฀Projektmanagement,฀4/ 1998,฀S.฀3-10 [2]฀Diesterer,฀G.: ฀Wissensmanagement฀in฀Projekten.฀In: ฀Projektmanagement฀4/ 2000,฀S.฀30 [3]฀Schindler,฀M.; ฀Eppler,฀M.: ฀Vom฀Debriefing฀zum฀kontinuierlichen฀Erfahrungslernen.฀In: ฀Organisationsentwicklung฀1,฀ 2002,฀S.฀58-71 [4]฀Longmuß,฀J.; ฀Mühlfelder,฀M.: ฀Wissensmanagement฀in฀ der฀Produktentstehung฀-฀Von฀der฀zentralen฀Wissensverwaltung฀zu฀zirkulierenden฀Wissensströmen.฀In: ฀Unternehmen฀der฀Zukunft฀3/ 2001,฀IAW฀+฀FIR,฀Aachen฀2001 [5]฀Brödner,฀P.; ฀Helmstädter,฀E.; ฀Widmaier,฀B.฀(Hrsg.): ฀Wissensteilung฀-฀Zur฀Dynamik฀von฀Innovation฀und฀kollektivem฀ Lernen฀(Zur฀Einführung).฀München฀und฀Mering฀1999 [6]฀Frank,฀U.; ฀Schönert,฀S.฀: ฀Wissensmanagement฀in฀Projekten.฀In: ฀Projektmanagement฀aktuell฀4/ 2001,฀S.฀25-33 [7]฀Thoben,฀K.-D.; ฀Weber,฀F.; ฀Wunram,฀M.: ฀Towards฀Pragmatic฀Approaches฀for฀Knowledge฀Management.฀In: ฀Engineering฀-฀Theory฀and฀Industrial฀Applications.฀In: ฀International฀Conference฀on฀Engineering฀Design.฀ICED,฀Glasgow฀ 2001 [8]฀Longmuß,฀J.: ฀Integrating฀Design฀Processes฀in฀an฀SE- Environment.฀In: ฀International฀Design฀Conference฀-฀Design฀ 2002.฀Dubrovnik฀2002 Schlagwörter Know-how-Sicherung,฀Erfahrungssicherung฀in฀Projekten,฀ Produktentstehungsprozess,฀Produktentwicklung,฀Wissensmanagement Autor Dr.-Ing.฀Jörg฀Longmuß฀ist฀Konstruktionstechniker฀und฀Senior-Berater฀bei฀ der฀Berliner฀Unternehmensberatung฀ GITTA฀mbH.฀Zu฀seinen฀Arbeitsgebieten฀gehört฀das฀Projektmanagement฀in฀ Industrie฀und฀Forschung฀mit฀Schwerpunkt฀Organisations-฀und฀Teamentwicklung.฀Er฀hat฀in฀verschiedenen฀ Unternehmen฀die฀Einführung฀bzw.฀Erneuerung฀von฀PM- Standards฀und฀das฀Erarbeiten฀von฀Produktentstehungsplänen฀begleitet. Anschrift GITTA฀mbH Kreuzbergstr.฀37/ 38 D-10965฀Berlin Tel.: ฀0฀30/ 7฀85฀20฀82 E-Mail: ฀longmuss@gittambh.de Autor Dipl.฀Psych.฀Manfred฀Mühlfelder฀ist฀ wissenschaftlicher฀Mitarbeiter฀am฀ Institut฀für฀Arbeitswissenschaft฀(IAW)฀ der฀RWTH฀Aachen.฀Schwerpunkte฀ seiner฀Tätigkeiten฀sind฀die฀humanorientierte฀Analyse,฀Bewertung฀und฀ Gestaltung฀von฀Produktentstehungsprozessen.฀Im฀Rahmen฀des฀vom฀Bundesministerium฀für฀Bildung฀und฀Forschung฀(bmb+f)฀geförderten฀Leitvorhabens฀INVITE฀(http: / / www.invite.de)฀hat฀er฀ sich฀vertieft฀mit฀dem฀Aspekt฀„Wissensmanagement฀in฀der฀ Produktentstehung“฀am฀Beispiel฀der฀Automobilindustrie฀ auseinander฀gesetzt. Anschrift IAW฀der฀RWTH฀Aachen Bergdrisch฀27 D-52062฀Aachen Tel.: ฀02฀41/ 8฀09฀94฀73 E-Mail: ฀m.muehlfelder@iaw.rwth-aachen.de