Ist Ihr Wissensmanagement branchenunabhängig übertragbar? Worauf es bei der Datenbasis ankommt

Der Unterschied zwischen einem Einzelfall und einem Produkt

Ein Spritzgussbetrieb aus Ostwestfalen und ein Anlagenbauer aus Baden-Württemberg haben auf den ersten Blick wenig gemeinsam: andere Maschinen, andere Materialien, andere Fachsprache. Trotzdem sollte ein Wissensmanagement-System bei beiden mit vergleichbarem Aufwand funktionieren, wenn es wirklich branchenunabhängig aufgebaut ist. Funktioniert es nur beim ersten Kunden gut, liegt das meist nicht an der Software, sondern daran, dass die Datenstruktur zu eng an dessen Sprachgebrauch und Ablagelogik angelehnt wurde.

Der Test ist einfach: Lässt sich der Pilot beim zweiten, völlig andersartigen Kunden in vergleichbarer Zeit aufsetzen wie beim ersten, oder muss die Grundlogik jedes Mal neu erfunden werden? Nur im ersten Fall handelt es sich um ein Produkt.

Warum starre Kategorien branchenspezifisch scheitern

Ein häufiger Fehler ist, Wissensinhalte entlang starrer, fest programmierter Kategorien zu ordnen, die für eine Branche passen und für die nächste nicht. Ein Kategoriebaum, der für Spritzguss gedacht ist, mit Begriffen wie Werkzeugwechsel und Schwindungswerten, hilft einem Blechverarbeiter kaum weiter. Übertragbar wird ein System erst, wenn es Inhalte nicht über starre Kategorien, sondern über Beziehungen zwischen Anlage, Bauteil, Störung und Lösung erschließt, unabhängig davon, wie diese Begriffe im jeweiligen Betrieb benannt werden.

Diese Beziehungslogik lässt sich einmal sauber bauen und dann pro Kunde mit dessen eigener Terminologie befüllen, statt für jeden neuen Betrieb eine neue Grundstruktur zu entwerfen.

Was bei jedem Pilotkunden neu ist, und was nicht

Bei jedem neuen Pilotkunden ändern sich die Inhalte fast vollständig, die Fachbegriffe, die Anlagentypen, die Art der Störungen. Was sich nicht ändern sollte, ist die Grundarchitektur darunter: wie Dokumente verknüpft, wie Rechte vergeben und wie Suchergebnisse gewichtet werden. Wird diese Trennung sauber eingehalten, sinkt die Einrichtungszeit für jeden weiteren Pilotkunden spürbar, weil nur noch die Inhalte, nicht mehr die Logik neu aufgebaut werden müssen.

Der Wechsel von einem Referenzkunden zu mehreren Pilotkunden gleichzeitig ist deshalb weniger eine technische als eine organisatorische Übung, wie auch im Beitrag zum Aufsetzen eines Piloten mit eigenen Daten beschrieben.

Woran man Übertragbarkeit vor dem Kauf erkennt

Für einen Interessenten ist die Übertragbarkeit schwer von außen zu prüfen, weil jede Demo naturgemäß mit gut vorbereiteten Daten läuft. Ein verlässliches Zeichen ist trotzdem sichtbar: Kann der Anbieter erklären, welche drei Schritte notwendig sind, um das System auf eine völlig neue Branche umzustellen, und wie lange diese Schritte dauern? Wenn diese Antwort ausweichend bleibt, ist die Übertragbarkeit meist noch nicht erprobt, sondern nur behauptet.

Eine konkrete Zeitangabe, etwa zwei bis drei Wochen bis zum ersten nutzbaren Zustand bei neuen Daten, ist ein deutlich verlässlicheres Signal als eine allgemeine Aussage zur Flexibilität der Software.

• Trennung von Grundarchitektur und branchenspezifischem Inhalt konkret erklärbar
• Feste Zeitangabe für die Einrichtung bei einem neuen, fachfremden Datensatz
• Keine hartcodierten Branchenbegriffe in der Suchlogik
• Beziehungen zwischen Anlage, Bauteil und Störung statt starrer Kategoriebäume
• Mindestens ein zweiter, andersartiger Pilotkunde als Nachweis

Was das für die aktuelle Pilotphase bedeutet

Für Betriebe, die jetzt einen Pilot starten, lohnt sich ein Blick auf die zugrundeliegende Struktur, nicht nur auf die Demo-Oberfläche. Ein System, das explizit für mehrere unterschiedliche Branchen ausgelegt ist, spart auf Sicht Zeit, weil spätere Erweiterungen, etwa auf weitere Werke oder Tochtergesellschaften, nicht wieder bei null beginnen. Wie sich dieser Erfolg dann objektiv nachweisen lässt, zeigt der Beitrag zu Kennzahlen für den Pilotenerfolg.