Technik 6.3: Such-Technologie für KCS
Wie Suchen ein integraler Bestandteil der KCS-Lösungsschlaufe ist, ist es wichtig, Technik zur Verfügung zu stellen, die Mitarbeitern erlaubt, effektiv in der Wissensdatenbank zu suchen. Ob zutreffend oder nicht, Nutzer geben oft ihrer Such-Technologie die Schuld für ihre Schwierigkeiten, relevante Inhalte zu finden. Wenn Nutzer der Suche nicht vertrauen, ist es wahrscheinlicher, dass sie nicht verstehen, was wir kollektiv wissen, seltener Inhalte überprüfen und verbessern, wenn sie ihn benutzen und mehr doppeltes Wissen erstellen.
Suchmaschinen werden entwickelt, relevante Inhalte auf Basis einer Anfrage zu liefern. Suchmaschinen werden die Dokumente, die sie liefern aus der Grundlage dessen sortieren, wie eng sie die Passung des Dokuments und der Anfrage kalkulieren. Wenn die Suche gut funktioniert, werden die relevantesten Dokumente oben in der Ergebnis-Liste angezeigt.
In ihrer einfachsten Form suchen Suchmaschinen nach wortwörtlichen Übereinstimmungen zwischen Worten in der Anfrage und dem Dokument. Suchmaschinen können verfeinert werden, und beispielsweise einfache Variationen der Suchbegriffe (beispielsweise „rennen“ und „rennt“), irreguläre Variationen („rennen“ und „rannte“), Synonyme („rennen“ und „laufen“) oder Konzepte („ein Programm laufen lassen“ entspricht „ein Programm ausführen“) zusammengebracht werden.
Nach Relevanz oder Rangordnung zu sortieren ist sehr wichtig, weil Nutzer selten mehr als die ersten paar Antworten beachten (allerhöchstens die ersten paar Ergebnisseiten). Also werden Dokumente, die weiter unten einsortiert sind effektiv von den Suchergebnissen ausgeschlossen.
Relevanz-Ranglisten können verschiedene Faktoren nutzen um die Passung zwischen einer Anfrage und einem Dokument zu schätzen. Beispielsweise:
- Wie viele der Suchbegriffe tauchen in dem Dokument auf?
- Wie oft tauchen die Begriffe auf?
- Wie selten oder bedeutsam sind die Suchbegriffe in dem durchsuchten Dokument (Beispiel: „0x32562“ ist einzigartiger als „Fehler“, also wird die Anfrage „Fehler 0x32563“ eine genauere Passung zu „Code 0x32562“ haben als zu „Fehler -135“)
- Wie nahe die Suchbegriffe zueinander auftauchen
- Die Verortung der Suchbegriffe; beispielsweise werden Begriffe im Titel als wichtiger eingeschätzt, als Begriffe, die im Text vergraben sind. Das Consortium schlägt vor, dass es eine gute Praxis ist, Passungen in der Problem- und Umgebungsbeschreibung höher zu gewichten als Passungen im Lösungs- oder Ursachen-Bereich, weil wir davon ausgehen, dass der Nutzer die Lösung oder Ursache noch nicht kennt.
- Die Passung der Konzepte (nicht nur der Suchbegriffe selbst), die in den Suchbegriffen und Dokumenten vorkommen
- Die angenommene Qualität oder der Ruf des Dokuments, basierend auf der Verknüpfungszahl, Bewertung, Alter der letzten Überprüfung oder ähnlichen Faktoren
Auch wenn es so viele Algorithmen wie Hersteller gibt, sollte die Suchqualität an dem Erfolg, den Anwender beim Navigieren der Wissensdatenbank haben, gemessen werden.
Es ist wichtig zu verstehen wie Suchmaschinen funktionieren, damit Trainer und Coaches alle Wissen-Beitragenden und Anwender bezüglich der besten Artern, die Suche zu benutzen, beraten können. Zum Beispiel: sollten wir viele oder wenige Begriffe verwenden? Sollten wir Sätze und natürliche Sprache benutzen oder nur Stichpunkte? Wie sensibel ist die Suche für bestimmte Wörter, oder reichen generelle Konzepte? Coaches müssen darauf vorbereitet sein, technik-bezogene Aspekte der Suche zu demonstrieren und dazu Rückmeldung zu geben.
„Suche“ im Service: Was anders ist
Die Natur der menschlichen Sprache macht Suchen in jedem Bereich schwierig. Wenn wir beispielsweise von „Akt“ sprechen, meinen wir eine Handlung, den Teil eines Theaterstücks oder ein Bild? Und ist „Auflaufen“ einfach das Eintreffen an einem Ort oder ein Navigationsfehler in einem Boot? Menschen unterscheiden unterbewusst in Konflikt stehende Bedeutungen aufgrund des Kontexts, aber Kontext lässt sich nur schwer in Maschinen programmieren.
Internet-Suchmaschinen machen sich die Struktur des Internets selbst zunutze, sowie das Verhalten der Nutzer, um die Relevanz zu erhöhen. Mit über 100 Millionen Webseiten und hunderten Millionen täglichen Nutzern der Suchmaschinen, kann sich die Internetsuche eines unvorstellbar riesigen Datensatzes bedienen. Leider haben KCS-Wissensdatenbanken weder die Struktur, noch das Nutzungsvolumen des Internets, sodass Herangehensweisen aus dem Internet bei ihnen nicht gut funktionieren. Wir hören oft „kann das nicht einfach wie Google funktionieren?“. Da Organisations-Wissensdatenbanken nicht das Aktivitäts-Volumen dafür haben, ist unsere Antwort „nein.“
Wenn Suchen ohnehin schon schwer sind, sind die es im Service doppelt. Nutzer kennen einige der Symptome ihres Problems und wissen vielleicht auch ein wenig darüber, wann und wo ihr Problem auftaucht, aber sie wissen nicht wirklich, nach welcher Antwort sie suchen. Das ist die Grundlage für die Behauptung des Consortiums, dass die Suche zuerst in den Problem- und Umgebungs-Abschnitten durchgeführt werden sollte, zumindest bei Artikeln, die die vorgeschlagene KCS-Struktur nutzen. Die Such-technologie muss außerdem Leute unterstützen, die etwas über die Lösung oder Ursache eines Problems wissen und ihnen erlauben in den Lösungs- und Ursachen-Feldern zu suchen.
Die gute Nachricht ist: Themenbereiche sind begrenzt. Leute werden bei einer Internet-Suche alles Mögliche fragen, aber in KCS-Wissensdatenbanken fragen sie normalerweise nach Ausnahmen, die in einem begrenzten Produkt- und Dienstleistungsbereich auftauchen. Das erleichtert das „Akt“-Problem, wenn die Technologie davon zu profitieren weiß.
Schlüssel-Überlegungen zur Such-Technologie
Die Verfeinerung der Such-Technologie, die für eine nachhaltige KCS-Umsetzung benötigt wird, hängt von der Größe unserer Wissensdatenbank, der Komplexität des Themenbereichs (bspw. Wie subtil können die Nuancen zwischen nicht als doppelt geltenden Artikeln sein), der Technikaffinität und dem Durchhaltevermögen unserer Anwender ab. Generell reicht sehr einfache Technik für eine Wissensdatenbank mit weniger als 1.000 Artikeln, während Sammlungen mit mehr als 10.000 Artikeln in einem hoch-technischen Bereich die Grenzen der aktuellen Such-Technologien erreichen.
Hier sind einige Bedenken für die Auswahl einer Such-Technologie:
- Ist es wichtig, andere Ressourcen zeitgleich durchsuchen zu können? In anderen Worten, sollte eine einzelne Suche reichen um Ergebnisse aus Dokumentationen, Gemeinschafts-Foren und Fehlermeldungen anzuzeigen?
- Soll ein einzelner Suchbegriff reichen oder müssen wir Synonyme oder konzept-basierte Suchen unterstützen? Benötigt die Größe und Komplexität unserer Themenbereiche noch fortgeschrittenere Herangehensweisen um Resultate zu erzielen?
- Wie viel Aufwand bedeutet die Such-Technologie für den Inhaltsentwickler, der Inhalte erfasst, strukturiert und verbessert? Müssen sie die Metadaten oder Schlüsselbegriffs-Felder sorgfältig ausfüllen oder wird die Suche diese Inhalte automatisch bearbeiten? Kann Wissen in „Gesprächsgeschwindigkeit“ erfasst werden?
- Welche Berichte können wir erhalten, um die Inhaltsentwicklung in der Entwicklungsschlaufe voranzutreiben, insbesondere um Selbsthilfe-Lücken zu schließen?
- Welche Optionen hat das KCS-Programm-Team oder ein anderes Team, um die Sucherfahrung zu verfeinern und steuern? Welche Berichte stehen ihnen hierzu zur Verfügung?
Planung für laufende Bemühungen und Such-Verfeinerung
Fortgeschrittene Such-Werkzeuge liefern teilweise exzellente Nutzererfahrungen und sind in einigen Fällen der einzige Weg, KCS am Laufen zu halten. Aber sie erfordern einen stetigen Aufwand, um sie zu pflegen und anzupassen. Da sich KCS-Inhalte mit der Zeit verändern und weiterentwickeln, muss das auch die Suche.
Den Instandhaltungs-Aufwand einzuplanen ist ein Schlüssel-Element der Prozessintegrations-Praxis in der Entwicklungsschlaufe. Allgemein sollte eine Person die als oder mit der KCS-Programmleitung in enger Abstimmung mit den Wissens-Entwicklern in engem Austausch steht, für diese stetige Verbesserung der Endnutzer-Erfahrung verantwortlich sein. Der Fehler, diese Aufgabe nicht einzuplanen kann ein smartes Werkzeug schnell in ein dummes verwandeln.
Die folgenden Aufgaben sollten immer wieder zyklisch durchgeführt werden:
Schwächen der Sucherfahrung identifizieren
Quellen beinhalten:
- Informelle Unterhaltungen mit Wissensarbeitern
- Such-Analysen – Ausschau nach „Keine Übereinstimmungen gefunden“-Anfragen halten
- Ein Überblicks-Prozess, der die Ergebnisse häufiger Anfragen evaluiert
Aktiv werden
- Gibt es eine Wissenslücke? Sagt dem Themenexperten Bescheid!
- Gibt es mehrere Artikel mit verschiedenen Lösungen, die für einen Satz Symptome geliefert werden? Das liegt häufig daran, dass die Umgebungsbeschreibungen keine Charakteristika enthalten, die die Artikel voneinander unterscheiden. Nutzt dies als ein Beispiel für die Coaches und KCS-Profis, um herauszustellen, wie wichtig es ist, diese unterscheidenden Charakteristika in den Artikel aufzunehmen.
- Ist der Inhalt schwer lesbar oder nicht im Kontext des Fragenden? Findet heraus, warum das nicht automatisch in der Lösungsschlaufe behoben wird und korrigiert das. Überlegt auch, ob ihr das Wörterbuch der Suchmaschine überarbeiten solltet oder eine Konzept-Karte einfügen solltet, um die Lücken zwischen den verschiedenen Begriffen der Anwender zu überbrücken.
- Tauchen wichtige oder entscheidende Artikel nicht oben in der Ergebnisliste auf? Baut Such-Verfeinerungs-Optionen wie „Bester Tipp“, „organisierte Antworten“ oder andere Arten, die Inhalte (hauptsächlich aus der Entwicklungsschlaufe) besser sichtbar zu machen, ein.
- Haben Fragende Schwierigkeiten, in bestimmten wichtigen Bereichen mit den Suchergebnissen Probleme zu lösen? Überlegt wert-steigernde Entwicklungsschlaufen-Inhalte wie Multimedien, „aktive“ Inhalte oder diagnostische KCS-Artikel, die sich zu einem Lösungsweg verknüpfen, zu erstellen.
Die Effektivität der Aktionen einschätzen
- Stellt sicher, dass das grundlegende Problem behoben wurde, indem ihr dieselben Methoden noch einmal anwendet, die euch auf das Problem ursprünglich aufmerksam gemacht haben.