Häufig stellt sich bei neuen KCS Initiativen die Frage was mit dem bestehenden Wissen, das in allen möglichen technischen Lösungen abgespeichert ist, denn geschehen soll.
Ich habe häufig festgestellt, dass viele Artikel/Dokumente nicht darauf abzielen den Support / das Service zu unterstützen. Das ist aber die Hauptintention von KCS. Zuerst sollte der Bestand daher in Service-relevante und „andere Dokumente“ unterteilt werden.
Kategorisieren Sie zuerst die Dokumente nach Verwendungszweck
Knowledge Artikel die nicht KCS relevant sind
Diese „anderen Dokumente“ könnten bspw. unter folgende Kategorien fallen:
- Produkt Dokumentation
- Service Dokumentation
- Konfigurationsdokumentation
- Verträge
- Policies und Standard
- Handlungsanweisungen
- Frage/Entscheidungs-Bäume
Manche dieser Dokumente können direkt in das ServiceNow Wissensmanagement übernommen werden. Dieses bietet die Möglichkeit mehrere unabhängige Wissensdatenbanken anzulegen. Dabei kann anders kategorisiert werden, andere Prozesse/Workflows hinterlegt werden, und auch eine andere Berechtigungshierarchie (Sichtbarkeit) hinterlegt werden. Damit lassen sich diese „Wissenstöpfe“ komplett unabhängig voneinander betreiben.
Erstellen sie je nach Zweck, Verantwortungshoheit, Zielgruppe, u.ä. mehrere unabhängige Wissensdatenbanken. Dies erleichtert die Verwendung, Administration, und auch bspw. die Auswertung wesentlich.
Sie können natürlich auch in diesen Wissenstöpfen die Prinzipien aus KCS anwenden, und bspw. auf die selben Qualitätskriterien setzen. Sie müssen aber nicht.
Zusätzlich habe ich festgestellt, dass viele dieser Dokumente besser durch „lebende Informationen“ ersetzt werden sollten. Bspw. sollte eine saubere CMDB aufgebaut werden, die mittels Discovery und Service Mapping immer aktuell gehalten wird. Im Service Portfolio Management lassen sich darauf aufbauend noch viele andere Informationen pflegen, die sonst irgendwo in einem Dokument abgelegt wurden. Policies haben einen Lebenszyklus und einen konkreten Bezug, und sind daher im Policy and Compliance Management besser aufgehoben. usw.
KCS relevante Wissens Artikel
Alle Dokumente, die den Support und/oder das Self-Service unterstützen, können natürlich übernommen werden. Allerdings müssen sie den selben Qualitätskriterien unterliegen, die Sie auch für neu zu erstellende Artikel definiert haben. Die Anpassung kann man vor der Übernahme machen, oder sukzessive nachher (A Loop), oder einfach gar nicht. Sie werden sehen, das viele dieser Artikel ohnehin sehr rasch obsolet werden, und „unten rausfallen“. Das meiste davon wird auch niemals verwendet, und ist daher wertlos.
Stecken Sie nicht zu viel Aufwand in die Übernahme von bestehenden Dokumenten. Sortieren Sie diese aus, oder übernehmen Sie diese ohne viel extra Aufwand, und stellen Sie danach mittels Messung der Verwendung, des Feedbacks, der Qualität, etc. fest wie wichtig die Dokumente wirklich sind. Glauben Sie niemanden dass „seine“ Dokumente wichtig sind, wenn er das nicht nachweisen kann. Investieren Sie Ihre Zeit lieber in die Einführung und Verbesserung der KCS Prozesse.
Auch diese Dokumente fallen häufig in die Kategorie „Abzulösen durch strukturierte Information“. Siehe oben CMDB, etc.
Anmerkung:
Bei Firmen die selbst Software programmieren gibt es häufig Lösungen zur Dokumentation der Software, Module, Releases, Funktionen, etc., die direkt in die Entwicklungsumgebung integriert sind. Es bringt wenig zusätzlichen Wert diese Lösungen zu ersetzen, bzw. dieses Wissen zu importieren. Falls diese Wissen für den Support Wert bietet, sollte eine Integration angestrebt werden.