Implizites Wissen
Implizites Wissen ist Erfahrungswissen, das eine Person sicher anwenden, aber nur unvollständig aussprechen oder aufschreiben kann. Der Begriff geht auf Michael Polanyi (1966) zurück und erklärt, warum Befragungen und Dokumente einen Teil des Fachwissens nie erfassen.
In Software-Projekten ist implizites Wissen die wichtigste Erklärung dafür, dass ein [[lastenheft|Lastenheft]] trotz sorgfältiger Erhebung unvollständig bleibt – und ein zentrales Argument für Entwicklungsteams mit eigener Fachkenntnis.
In einfachen Worten
Der Philosoph Michael Polanyi beschrieb 1966, dass Menschen mehr wissen, als sie aussprechen können: Wer sicher Fahrrad fährt, kann die Physik des Gleichgewichts trotzdem kaum erklären. In Fachberufen gilt dasselbe für Kalkulationsregeln, Ausnahmen und eingespielte Handgriffe. Die Organisationsforscher Ikujirō Nonaka und Hirotaka Takeuchi zeigten in den 1990er Jahren, dass sich solches Wissen vor allem durch gemeinsame Erfahrung überträgt und nur zu einem kleinen Teil über Dokumente. Für Software-Projekte hat das eine unbequeme Konsequenz: Ein Lastenheft und die Interviews dahinter erreichen den wertvollsten Teil des Fachwissens strukturell schlecht. Zugänglich wird er über Beobachtung am Arbeitsplatz, über lange Zusammenarbeit – oder über Entwickler, die das Fachgebiet aus eigener Praxis kennen und die richtigen Rückfragen stellen.
Wozu brauche ich das?
Für Unternehmen wird der Begriff an zwei Stellen praktisch: bei Software-Projekten und beim Wissenstransfer im Team. Vor einer Ausschreibung lohnt die Frage, welche Regeln des eigenen Geschäfts nur in den Köpfen erfahrener Mitarbeitender existieren – genau diese Regeln fehlen später im Datenmodell der neuen Software, wenn niemand sie hebt. Beim Generationswechsel gilt dasselbe: Scheidet eine langjährige Kraft aus, verschwindet Wissen, das in keiner Verfahrensanweisung steht. Hospitation, Tandem-Arbeit und dokumentierte Sonderfall-Sammlungen sind die wirksamsten Gegenmittel.
Beispiel aus der Praxis
Ein Elektrogroßhandel bereitet die Ablösung seiner Auftragserfassung vor. In den Anforderungs-Workshops beschreibt der Innendienst den Bestellablauf vollständig und korrekt. Erst eine zweitägige Hospitation zeigt die Lücken: Bei bestimmten Kunden wird die Lieferadresse grundsätzlich telefonisch bestätigt, weil Baustellen kurzfristig wechseln; für einen Produktbereich gilt eine ungeschriebene Mindestbestellmenge; und die erfahrenen Kräfte erkennen fehlerhafte Bestellungen an Mustern, die sie selbst kaum benennen können. Keiner dieser Punkte war im Workshop gefallen; den Beteiligten fielen sie als Alltag schlicht nicht mehr auf.
Wirtschaftlicher Nutzen
Ungehobenes implizites Wissen verursacht zwei Arten von Kosten: Software, die den echten Ablauf verfehlt und Behelfe neben dem System erzwingt, sowie Wissensverlust beim Ausscheiden erfahrener Kräfte. Beide Risiken lassen sich mit überschaubarem Aufwand senken – durch Beobachtung vor Projektbeginn, systematische Sonderfall-Sammlungen und Übergabezeiten mit Doppelbesetzung. Die Investition ist klein im Verhältnis zu den Korrekturen, die ein allein auf Papierwissen gebautes System später verlangt.
Typische Fehler
- Anforderungen ausschließlich über Interviews und Dokumente erhoben – der aussagekräftigste Teil des Fachwissens ist dort nicht enthalten.
- Das Schweigen der Fachabteilung als Vollständigkeit gedeutet – Selbstverständliches wird gerade deshalb nicht genannt.
- Erfahrene Mitarbeitende erst nach der Systemeinführung einbezogen – ihre Einwände kommen dann zu spät und wirken als Widerstand.
- Wissenstransfer auf das Schreiben von Anleitungen reduziert – Erfahrungswissen überträgt sich über gemeinsames Arbeiten, Dokumente ergänzen nur.
- Beim Ausscheiden langjähriger Kräfte keine Übergabezeit eingeplant – mit dem letzten Arbeitstag ist das ungeschriebene Wissen fort.
Worauf achten?
- Vor Software-Projekten Arbeitsplätze beobachten – Nebenlisten, Zettel und Zurufe markieren die Stellen, an denen Wissen am Dokument vorbeiläuft.
- Nach konkreten Vorgängen fragen („Wie lief die letzte Reklamation?") statt nach abstrakten Abläufen.
- Sonderfall-Sammlungen führen: Jeder geklärte Ausnahmefall wird mit Lösung notiert und regelmäßig gesichtet.
- Tandem- und Hospitationsphasen fest einplanen, bei Projekten wie beim Generationswechsel.
- Bei Individualsoftware den Entwicklungspartner danach auswählen, ob er fachkundige Rückfragen stellt – sie gleichen aus, was Dokumente nicht transportieren.
Häufig gestellte Fragen
Was ist implizites Wissen?
Erfahrungswissen, das sich sicher anwenden, aber kaum vollständig in Worte fassen lässt – von Handgriffen über Faustregeln bis zu Ausnahmen, die erfahrene Kräfte automatisch berücksichtigen. Der Begriff stammt vom Philosophen Michael Polanyi (1966).
Warum steht implizites Wissen in keinem Lastenheft?
Weil es den Wissensträgern selbst als nicht erwähnenswert erscheint: Selbstverständliches wird ausgelassen, Abläufe werden idealisiert beschrieben, Behelfe kaum als solche erkannt. Erhebungsformate, die auf dem Aussprechen beruhen, erreichen dieses Wissen deshalb nur teilweise.
Wie lässt sich implizites Wissen sichtbar machen?
Über Beobachtung am Arbeitsplatz, Fragen nach konkreten Einzelfällen statt abstrakten Abläufen, dokumentierte Sonderfall-Sammlungen und längere Tandem-Phasen. Nonaka und Takeuchi beschreiben die Umwandlung in ausgesprochenes Wissen als eigenen, aktiv zu gestaltenden Prozess.
Welche Rolle spielt implizites Wissen bei Software-Projekten?
Eine entscheidende: Software, die allein auf dokumentierten Anforderungen beruht, verfehlt die ungeschriebenen Regeln des Tagesgeschäfts. Teams mit eigener Branchenkenntnis gleichen das aus, weil sie Sonderfälle und Begriffe aus eigener Praxis kennen.