Support-Wissen im Baukastenprinzip: Fälle entstehen, statt geschrieben zu werden

Das Baukastenprinzip zerlegt Support-Wissen in wiederverwendbare Ursache-, Symptom- und Lösungsbausteine, aus denen sich Fälle automatisch statt manuell kombinieren lassen. Wer technische Dokumentation für den Service pflegt, kennt das klassische Gegenmodell: Jede neue Fehlermeldung, jede neue Maschinenvariante und jede neue Kombination aus Ursache und Symptom bedeutet ein neues Dokument, oder, wie es in vielen Unternehmen heißt, einen neuen Fall, die vollständige Beschreibung aus Ursache, Symptom und Lösung zu einem bestimmten Fehlerbild, mit eigenen Metadaten.

Bei ohnehin komplexen Produktportfolios wächst die Zahl dieser Dokumente schnell in die Tausende, und mit ihr der Aufwand, sie bei jeder Änderung konsistent zu halten.

Der Ausweg liegt darin, nicht mehr den fertigen Fall, sondern seine Bestandteile zu pflegen. Drei Bausteine bilden den Kern:

• Ursache: die Beschreibung des Auslösers eines Fehlers oder eines unerwünschten Verhaltens. Sie ist das zentrale Element, dem Symptome und Lösungen zugeordnet werden.
• Symptom: die Beschreibung der Begleiterscheinung, an der ein Fehler erkennbar wird. Auch Fehlermeldungen, der Text, der auf der Bedienoberfläche einer Maschine oder Anlage angezeigt wird, gehören zum Symptom.
• Lösung: die Beschreibung des Prozesses, der die Ursache behebt.

Diese Bausteine werden über klar definierte Beziehungen miteinander verknüpft, statt in jedem einzelnen Fall neu formuliert zu werden. Auch wenn das Symptom oft der erste sichtbare Hinweis für den Anwender ist, beginnt die Pflege sinnvollerweise bei der Ursache. Denn von ihr aus lassen sich beide Beziehungen sauber zuordnen: welches Symptom sie auslöst und welche Lösung sie behebt.

Frei erfunden, nur zur Veranschaulichung: Der Kunde meldet das Symptom „Getriebe macht ungewöhnliche Geräusche“. Dafür kommen unterschiedliche Ursachen und Lösungen infrage. Fehlt Öl, lautet die Lösung: Getriebeöl nachfüllen. Ist ein Zahnrad beschädigt, muss das Getriebe getauscht werden.

Aus einem einzigen Symptom, zwei Ursachen und zwei Lösungen lassen sich so bereits zwei vollständige Fälle kombinieren, ohne dass dafür zwei separate Dokumente geschrieben werden mussten. Genau deshalb entsteht der Fall nicht allein aus dem Symptom, sondern aus der Kombination von Symptom, Ursache und passender Lösung.

Kommt später eine dritte Ursache hinzu, etwa ein verschlissenes Lager, wächst die Zahl der Fälle automatisch mit, ohne dass die bestehenden Bausteine angefasst werden müssen.

Der wichtigste Effekt dieses Prinzips: Eine einmal gepflegte Lösung kann beliebig vielen Fällen zugeordnet werden, ohne dass sie mehrfach existiert. Wird eine Lösung angepasst, gilt die Änderung automatisch für alle Fälle, in denen sie verwendet wird. Das Gleiche gilt für Symptome. Statt Kopien zu pflegen, wird ein Baustein wiederverwendet.

Das wirkt sich auch auf die Übersetzung aus. Jeder Baustein wird nur einmal übersetzt, unabhängig davon, in wie vielen unterschiedlichen Fällen er später vorkommt. Abhängig von der Verwendung lassen sich bei den Ursachen rund 60 bis 70 Prozent der gepflegten Inhalte einsparen.

Unternehmen, die ihre Fälle von Anfang an geschickt in solche Bausteine zerlegen, verschaffen sich damit spürbare Zeit- und Kostenvorteile, vor allem bei Übersetzungskosten und beim Erstellungsaufwand, und profitieren entsprechend davon.

Nicht jeder Baustein gilt überall. Über Zuordnungen zu Produktkategorien oder einzelnen Artikeln lässt sich einschränken, wo eine Ursache, ein Symptom oder eine Lösung tatsächlich zutrifft. Statt für jede Variante ein eigenes Dokument zu schreiben, wird schlicht der Geltungsbereich eines Bausteins gepflegt.

Je nach Art der Beziehung vererbt sich dieser Geltungsbereich auf verwandte Objekte oder eben nicht, je nachdem, wie es fachlich sinnvoll ist.

Neben dem reinen Inhalt lassen sich an den Bausteinen auch Bewertungsmerkmale pflegen: wie wahrscheinlich eine Ursache ist, wie viel Arbeitszeit und Materialkosten eine Lösung erfordert, wie viel Prüfzeit realistisch einzuplanen ist, und wie relevant ein Fall für die öffentlich zugängliche Online-Hilfe ist.

Diese Bewertung ist redaktionelle Arbeit: Sie sorgt später dafür, dass dem Servicemitarbeiter die passenden Fälle in einer sinnvollen Reihenfolge angezeigt werden, unter Berücksichtigung von Wahrscheinlichkeit, Aufwand und Kosten.

Neue Fallkombinationen entstehen automatisch und regelmäßig im Hintergrund, sobald sich neue Zuordnungen zwischen den Bausteinen ergeben. Bevor eine Änderung freigegeben wird, prüft das Redaktionsteam die betroffenen Fallkombinationen. Ein Report zeigt, welche Fälle ein bearbeiteter Baustein betrifft, inklusive Sprachauswahl und Freigabestatus.

Verliert eine Kombination ihre Grundlage, etwa weil ein zugrunde liegender Baustein sich ändert, zieht das System eine bestehende Freigabe automatisch zurück. So kontrolliert das Redaktionsteam vor der Freigabe, ob die erzeugten beziehungsweise geänderten Fälle fachlich vollständig und korrekt sind.

Entscheidend ist, dass nicht nur theoretisch mögliche Fälle entstehen, sondern Fälle, die im Servicealltag tatsächlich vorkommen. In vielen Unternehmen gibt es dafür bereits einen großen Erfahrungsschatz: bekannte Fehlerbilder, bewährte Lösungswege und Rückmeldungen aus vergangenen Einsätzen. Dieses Wissen bildet die Grundlage für die Pflege der Bausteine.

Was im Feld neu auffällt oder noch fehlt, kann über Rückmeldungen der Servicetechniker gezielt angestoßen und anschließend redaktionell geprüft werden. So wächst die Wissensbasis nicht losgelöst von der Praxis, sondern entlang der Fälle, die im Service wirklich relevant sind.

Wie stark sich das Baukastenprinzip auswirkt, lässt sich an einem einfachen Beispiel zeigen. Werden zehn Ursachen jeweils mit fünf Symptomen und drei möglichen Lösungen kombiniert, entstehen daraus bereits 150 mögliche Fallkombinationen.

In größeren Wissensbeständen wächst dieser Hebel entsprechend weiter: Die Zahl der nutzbaren Fälle steigt deutlich, während der Pflegeaufwand auf die einzelnen Bausteine begrenzt bleibt.

So ein Baukasten aus Ursachen, Symptomen und Lösungen lässt sich nicht in einer losen Sammlung von Dokumenten abbilden. Damit daraus im Service nutzbares Wissen entsteht, müssen Datenstruktur und Systemfunktion zusammenspielen.

Auf der Datenseite

Es reicht nicht, Ursache, Symptom und Lösung als reine Textabschnitte zu behandeln. Jeder Baustein muss ein eigenständiges, referenzierbares Objekt sein. Dazu gehören eigene Metadaten und klar definierte Beziehungen zu anderen Bausteinen.

Der konkrete Gültigkeitsbereich entsteht jedoch erst auf Ebene des Falls beziehungsweise der Fallkombination: Dort wird festgelegt, für welche Produktkategorie, welchen Artikel oder welchen Kontext diese Kombination tatsächlich gilt. Auch Bewertungsmerkmale wie Wahrscheinlichkeit, Aufwand oder Relevanz müssen strukturiert vorliegen, damit sie später ausgewertet und für die Reihenfolge im Service genutzt werden können.

Auf der Systemseite

Hier braucht es die Fähigkeit, aus diesen Beziehungen automatisch passende Fallkombinationen zu bilden und deren Freigabe gezielt zu steuern. Wenn eine Lösung bekannt ist, kann das System daraus außerdem konkrete Handlungen ableiten. Lautet die Lösung zum Beispiel „Motor tauschen“, lässt sich daran eine Schritt-für-Schritt-Anleitung für den Servicetechniker anbinden. So wird aus der Fallkombination nicht nur ein Hinweis auf Ursache und Lösung, sondern eine direkt nutzbare Unterstützung im Serviceeinsatz.

Ohne diese beiden Ebenen bleibt das Baukastenprinzip eine gute Idee auf dem Papier. Praktisch nutzbar wird es erst durch die Datenstruktur und die Systemfähigkeiten dahinter.

Das Baukastenprinzip verändert, wo redaktionelle Arbeit eigentlich stattfindet: nicht mehr beim Schreiben einzelner Fälle, sondern bei der Pflege der Bausteine und bei der Kontrolle der daraus entstehenden Kombinationen.

Ursachen, Symptome und Lösungen lassen sich in der Regel bereits bei der Erfassung fachlich miteinander verknüpfen. Eine umfangreiche Falldatenbank ist dafür initial nicht zwingend erforderlich. Bestehende Fälle können ergänzend analysiert werden, um weitere Muster und Wiederverwendungspotenziale sichtbar zu machen.

Bei einer bestehenden Falldatenbank lohnt sich der Blick darauf, was sich zusammenfassen lässt: welche Symptome eigentlich auf dieselbe Ursache zurückgehen, welche Lösungen sich wiederholen und welche Kategorien sich bündeln lassen. Aus diesen Gemeinsamkeiten entstehen die eigentlichen Wissensbausteine, aus denen sich später neue Fälle kombinieren lassen.

Wer selbst mit wachsender Dokumentenvielfalt kämpft, sollte genau das tun: die eigene Wissensbasis darauf prüfen, wie viele der aktuell gepflegten Dokumente sich auf wiederverwendbare Bausteine zurückführen lassen.

Wer zu diesem Thema tiefer einsteigen oder sich einfach dazu austauschen möchte, ist herzlich eingeladen, sich bei uns zu melden. Wir beschäftigen uns seit über 30 Jahren mit genau solchen Fragestellungen rund um technische Dokumentation und Wissensmanagement.