Wissensmanagement-Pilot mit eigenen Daten aufsetzen: Der Schritt-für-Schritt-Fahrplan

Warum ein Pilot mit Beispieldaten niemanden wirklich überzeugt

Viele Wissensmanagement-Projekte starten mit einer Demo-Umgebung voller generischer Musterdaten: eine Beispielzeichnung, drei erfundene Störungsmeldungen, ein Handbuch von der Stange. Das wirkt in der ersten Präsentation überzeugend, aber sobald ein Instandhalter die erste eigene Frage stellt, etwa nach der Fehlerhistorie einer bestimmten Presse, bricht die Illusion zusammen. Ein Hydraulikhersteller aus dem Bergischen Land hat genau das erlebt: Die Geschäftsführung war nach der ersten Demo begeistert, die Werkstatt nach dem ersten eigenen Test skeptisch, weil das System die eigene Anlage schlicht nicht kannte.

Ein Pilot, der am Ende wirklich überzeugen soll, muss deshalb von der ersten Stunde an mit echten Daten arbeiten, auch wenn das mehr Vorbereitung kostet als ein vorkonfiguriertes Szenario. Der Mehraufwand lohnt sich, weil die Rückmeldung aus der Praxis dann sofort belastbar ist und nicht erst nach einem zweiten, teureren Anlauf.

Schritt eins: die zwei bis drei Datenquellen finden, die wirklich tragen

Der größte Fehler beim Aufsetzen eines Piloten ist der Versuch, gleich alles anzubinden, das ERP, das MES, zehn Jahre Schichtbücher und die technische Doku auf einmal. Das verzögert den Start um Monate und liefert am Ende trotzdem kein sauberes Ergebnis. Erfolgreicher sind Piloten, die mit zwei bis drei Quellen beginnen, die im Alltag tatsächlich häufig nachgeschlagen werden, etwa die Wartungshistorie einer Anlagenklasse und die dazugehörigen technischen Zeichnungen.

Bei der Auswahl hilft eine einfache Frage an die Mannschaft: Wonach wird heute am häufigsten gesucht, und wie lange dauert diese Suche im Schnitt. Die Antworten zeigen fast immer, welche zwei Quellen den größten Hebel haben, lange bevor eine IT-Abteilung eine vollständige Systemlandkarte gezeichnet hat.

Schritt zwei: aufräumen, bevor überhaupt indexiert wird

Rohdaten aus zehn Jahren Betrieb enthalten fast immer Dubletten, veraltete Versionsstände und handschriftliche Notizen, die nur eine Person entziffern kann. Wer diese Daten ungefiltert in den Wissens-Hub kippt, bekommt zwar schnell Ergebnisse, aber auch schnell Misstrauen, sobald ein Mitarbeiter auf eine längst überholte Anleitung stößt. Eine kurze Aufräumrunde vor dem Import zahlt sich fast immer aus.

Diese Aufräumrunde muss nicht perfekt sein, sie muss nur die gröbsten Fehlerquellen beseitigen. Aus der Praxis hat sich eine kurze Checkliste bewährt, die ein Pilotteam in ein bis zwei Arbeitstagen abarbeiten kann.

• Dokumente mit erkennbar veraltetem Versionsstand aussortieren oder klar markieren
• Dubletten aus verschiedenen Ablagen zusammenführen, statt beide zu behalten
• Handschriftliche Vermerke, wo möglich, in Textform übertragen
• Zuständigkeiten je Datenquelle benennen, damit spätere Fragen einen Ansprechpartner haben
• Zugriffsrechte einmal grundsätzlich klären, bevor der Kreis der Nutzer wächst

Schritt drei: ein enger Kreis testet, bevor der Rollout beginnt

Ein Pilot ist kein Rollout im Kleinen, sondern ein bewusst eng gehaltener Test mit fünf bis zehn Personen, die täglich mit den angebundenen Daten arbeiten. Diese Gruppe liefert in zwei bis drei Wochen mehr belastbares Feedback als eine unternehmensweite Ankündigung, weil sie das System an echten Fragen misst, nicht an einer Präsentationsfolie. Wie aus diesen ersten Testwochen später eine überzeugende Demo für Entscheider wird, entscheidet sich genau in dieser Phase.

Wichtig ist, dass die Testgruppe bewusst gemischt ist: erfahrene Kollegen, die das Wissen im Kopf haben, und neuere Kollegen, die es dringend brauchen. Nur so zeigt sich, ob der Hub tatsächlich Wissen zugänglich macht, das vorher nur in einzelnen Köpfen steckte.

Schritt vier: Feedback einsammeln, nachschärfen, dann erst skalieren

Nach den ersten Wochen zählt nicht die Anzahl der Logins, sondern ob konkrete Fragen schneller beantwortet wurden als vorher. Diese Auswertung sollte in feste Kennzahlen münden, bevor der Kreis der Nutzer erweitert wird, wie im Detail im Beitrag zu KPIs für den Pilotenerfolg beschrieben.

Ein kurzes Gespräch mit den Testnutzern nach drei Wochen bringt oft mehr zutage als jede Umfrage, weil Rückfragen direkt gestellt und Missverständnisse sofort ausgeräumt werden können.