7.1 Knowledge Management – Ziele, Begriffe und Grundlagen

Kurz erklärt

Knowledge Management sorgt dafür, dass wichtiges Wissen im IT-Betrieb gesammelt, geprüft, strukturiert, auffindbar und nutzbar gemacht wird.

Ziel ist, dass Mitarbeitende, Service Desk, Fachgruppen und Benutzer nicht jedes Problem immer wieder neu lösen müssen.

Gute Wissensnutzung verbessert Supportqualität, verkürzt Bearbeitungszeiten, reduziert Wiederholungsfehler und macht IT-Services stabiler.

Warum Knowledge Management wichtig ist

Im IT-Betrieb entsteht täglich Wissen.

Beispiele:

bekannte Fehlermeldungen,

Workarounds,

Standardlösungen,

Installationsanleitungen,

Betriebsrunbooks,

Eskalationswege,

bekannte Fehler,

Anleitungen für Benutzer,

technische Prüfschritte,

Lessons Learned aus Incidents,

Ergebnisse aus Problem Management,

Änderungen nach Releases,

Sicherheits- und Betriebshinweise.

Wenn dieses Wissen nicht dokumentiert wird, entstehen typische Probleme:

dieselben Fragen werden immer wieder gestellt,

Service Desk analysiert bekannte Fehler jedes Mal neu,

Lösungen hängen von einzelnen Personen ab,

neue Mitarbeitende brauchen länger,

Workarounds werden uneinheitlich angewendet,

Benutzer erhalten widersprüchliche Antworten,

Wissen geht bei Krankheit, Urlaub oder Wechsel verloren,

und Incidents dauern länger als nötig.

Knowledge Management macht Wissen wiederverwendbar.

Ziel von Knowledge Management

Knowledge Management soll sicherstellen, dass richtiges Wissen zur richtigen Zeit für die richtige Zielgruppe verfügbar ist.

Ziele sind:

Wissen auffindbar machen,

Lösungen wiederverwendbar machen,

Bearbeitungszeiten reduzieren,

Fehler bei Standardfällen vermeiden,

Self-Service ermöglichen,

Service Desk entlasten,

Qualität von Antworten verbessern,

neue Mitarbeitende schneller einarbeiten,

Lessons Learned sichern,

und kontinuierliche Verbesserung unterstützen.

Knowledge Management ist kein reines Dokumentationsarchiv.

Es ist ein aktiver Bestandteil des Servicebetriebs.

Wissen ist nicht gleich Dokumentation

Dokumentation kann Wissen enthalten.

Aber nicht jede Dokumentation ist automatisch nützliches Wissen.

Dokumentation	Nutzbares Wissen
irgendwo abgelegt	auffindbar
sehr technisch oder unklar	zielgruppengerecht
veraltet	geprüft und aktuell
ohne Zusammenhang	mit Service, CI oder Prozess verknüpft
nur für Spezialisten verständlich	für passende Zielgruppe verständlich
nicht gepflegt	mit Owner und Review versehen

Beispiel:

Ein 80-seitiges Betriebshandbuch kann wichtig sein.

Für den Service Desk ist aber oft ein kurzer Artikel mit Symptomen, Prüfschritten, Workaround und Eskalationsweg hilfreicher.

Arten von Wissen

Im IT-Betrieb gibt es unterschiedliche Wissensarten.

Wissensart	Beispiel
Benutzerwissen	Anleitung zum Zurücksetzen des Passworts
Service-Desk-Wissen	Prüfschritte bei VPN-Problemen
Fachwissen	technische Analyse einer Datenbankstörung
Betriebswissen	Runbook für Neustart eines Dienstes
Known-Error-Wissen	bekannter Fehler mit Workaround
Change-Wissen	Hinweise nach einem Update
Sicherheitswissen	Umgang mit verdächtigen Mails
Servicewissen	Zuständigkeiten, Supportzeiten und Abhängigkeiten

Diese Wissensarten benötigen unterschiedliche Form, Sprache und Zugriffsbeschränkung.

Explizites und implizites Wissen

Explizites Wissen

ist dokumentiert und kann weitergegeben werden.

Beispiele:

Knowledge-Artikel,

Runbook,

Checkliste,

FAQ,

Servicebeschreibung,

Known Error,

Installationsanleitung.

Implizites Wissen

ist in den Köpfen von Personen vorhanden.

Beispiele:

Erfahrung mit einem instabilen System,

bekannte Eigenheiten eines Lieferanten,

typische Fehler nach Updates,

inoffizielle Abhängigkeiten,

bewährte Diagnosewege.

Knowledge Management versucht, wichtiges implizites Wissen in nutzbares explizites Wissen zu überführen.

Wissen muss zielgruppengerecht sein

Nicht jede Zielgruppe benötigt dieselben Informationen.

Zielgruppe	braucht typischerweise
Benutzer	einfache Anleitung, klare Schritte, keine internen Details
Service Desk	Symptome, Prüfschritte, Workaround, Eskalationsweg
Fachteam	technische Details, Logs, Konfigurationen, Ursachen
Management	Risiko, Auswirkungen, Status, Entscheidungspunkte
Security Team	Schutzmaßnahmen, Meldewege, Klassifizierung
Lieferant	technische Nachweise, Versionen, Fehlerbild

Ein Benutzerartikel sollte keine internen Admin-Schritte enthalten.

Ein interner Runbook-Artikel darf technischer und detaillierter sein.

Beispiele für Knowledge-Artikel

Mögliche Artikeltypen:

„VPN verbindet nicht nach Ruhezustand“

„Passwort über Self-Service zurücksetzen“

„Druckwarteschlange sicher neu starten“

„TLS-Zertifikat erneuern“

„Known Error: Client-Version 5.8 verliert Tunnelzustand“

„Runbook: Datenbankdienst kontrolliert neu starten“

„Checkliste: Server nach Update prüfen“

„FAQ: MFA bei neuem Smartphone einrichten“

„Service Desk: Erstdiagnose bei DNS-Problemen“

„Benutzerinformation: Wartungsfenster Mitarbeiterportal“

Wichtig ist, dass Titel und Inhalt Suchbegriffe aus der Praxis berücksichtigen.

Knowledge Base

Eine Knowledge Base ist ein strukturierter Ort für Wissen.

Sie kann enthalten:

Benutzeranleitungen,

interne Supportartikel,

technische Runbooks,

FAQ,

Known Errors,

Workarounds,

Checklisten,

Troubleshooting-Guides,

Servicebeschreibungen,

Release-Hinweise,

Sicherheitsanweisungen.

Das Werkzeug ist nicht entscheidend.

Möglich sind:

ITSM-System,

Wiki,

Self-Service-Portal,

Dokumentationsplattform,

Knowledge-Modul,

internes Handbuch.

Wichtig sind Auffindbarkeit, Aktualität, Qualität und Pflegeverantwortung.

Knowledge Management und Self-Service

Knowledge Management unterstützt Self-Service.

Benutzer können einfache Anliegen selbst lösen, wenn Informationen verständlich bereitstehen.

Beispiele:

Passwort zurücksetzen,

MFA neu einrichten,

WLAN verbinden,

Standardsoftware beantragen,

Drucker hinzufügen,

Status einer Störung prüfen,

häufige Fehlermeldung verstehen.

Self-Service funktioniert nur, wenn Artikel:

leicht auffindbar,

verständlich formuliert,

aktuell,

kurz genug,

und praktisch getestet sind.

Ein schlechter Self-Service erzeugt zusätzliche Rückfragen.

Knowledge Management und Service Desk

Der Service Desk profitiert besonders von guter Wissensbasis.

Nützlich sind:

Standardantworten,

Diagnosefragen,

Prüfschritte,

bekannte Symptome,

Workarounds,

Eskalationskriterien,

Priorisierungshinweise,

Kommunikationsvorlagen,

Links zu Runbooks,

Known Errors,

Serviceinformationen.

Dadurch kann der Service Desk schneller und einheitlicher arbeiten.

Gleichzeitig liefert der Service Desk viele Hinweise, welche Artikel fehlen oder verbessert werden müssen.

Knowledge Management und Incident Management

Incident Management nutzt Wissen zur schnellen Wiederherstellung.

Beispiele:

bekannter Workaround wird angewendet,

Service Desk findet passenden Artikel,

Incident wird mit Knowledge-Artikel verknüpft,

Benutzer erhält geprüfte Anleitung,

wiederkehrender Fehler wird schneller erkannt.

Incident Management liefert auch neues Wissen zurück.

Beispiele:

neue Fehlermeldung,

neuer Workaround,

unklare Anleitung,

falscher Artikel,

fehlender Eskalationsweg,

wiederkehrende Benutzerfrage.

Knowledge Management und Problem Management

Problem Management erzeugt wichtiges Wissen.

Beispiele:

bekannte Ursachen,

Known Errors,

Workarounds,

dauerhafte Lösungen,

beitragende Faktoren,

Lessons Learned,

technische Prüfschritte,

Risikohinweise.

Dieses Wissen sollte nicht nur im Problem Record bleiben.

Es muss so aufbereitet werden, dass Service Desk, Fachgruppen oder Benutzer es nutzen können.

Knowledge Management und Change Enablement

Changes verändern Services und damit auch Wissen.

Nach einem Change müssen möglicherweise aktualisiert werden:

Benutzeranleitungen,

Screenshots,

Menüpfade,

Runbooks,

Known Errors,

Workarounds,

Servicebeschreibungen,

Supportwege,

Monitoringhinweise,

Eskalationsregeln.

Ein Change ist nicht vollständig abgeschlossen, wenn die Technik geändert wurde, aber das Wissen noch den alten Stand zeigt.

Knowledge Management und Release Management

Releases bringen neue oder geänderte Funktionen.

Knowledge Management unterstützt durch:

Release Notes,

Benutzerinformationen,

Service-Desk-Briefings,

bekannte Einschränkungen,

neue Workarounds,

aktualisierte FAQ,

Schulungsunterlagen,

Hinweise auf geänderte Prozesse.

Nach einem Release steigen oft Rückfragen, wenn Wissen nicht rechtzeitig vorbereitet wurde.

Knowledge Management und Service Configuration Management

Configuration-Daten helfen, Wissen besser zuzuordnen.

Beispiele:

Artikel gehört zu einem Service,

Workaround gehört zu einem Known Error,

Runbook gehört zu einem CI,

Anleitung gehört zu einer Anwendungsversion,

Sicherheitsartikel gehört zu einer bestimmten Benutzergruppe.

Ohne Service- oder CI-Bezug sind Knowledge-Artikel schwerer auffindbar und schwerer aktuell zu halten.

Lebenszyklus von Wissen

Wissen sollte einen Lebenszyklus besitzen.

Bedarf erkennen
    ↓
Wissen erfassen
    ↓
Inhalt prüfen
    ↓
Artikel veröffentlichen
    ↓
Artikel nutzen
    ↓
Feedback sammeln
    ↓
Artikel aktualisieren
    ↓
Artikel archivieren oder entfernen

Wissen darf nicht dauerhaft ungeprüft online bleiben.

Veraltetes Wissen kann falsche Handlungen verursachen.

Wissensbedarf erkennen

Wissensbedarf entsteht zum Beispiel durch:

häufige Incidents,

wiederkehrende Benutzerfragen,

neue Services,

neue Releases,

Major Incidents,

bekannte Fehler,

fehlende Runbooks,

neue Mitarbeitende,

Sicherheitsvorfälle,

unklare Eskalationen,

wiederholte Fehlbedienung,

Service-Desk-Rückfragen.

Eine gute Frage ist:

Welche Information hätte den letzten Incident schneller lösbar gemacht?

Wissen erfassen

Wissen kann erfasst werden aus:

gelösten Incidents,

Problem Records,

Known Errors,

Change Records,

Release Notes,

Betriebsdokumentation,

Expertenwissen,

Benutzerfeedback,

Schulungen,

Lieferanteninformationen,

Monitoring-Analysen,

Major-Incident-Reviews,

Lessons Learned.

Wichtig ist, Wissen nicht nur zu sammeln, sondern zu strukturieren und nutzbar zu machen.

Wissen prüfen

Vor Veröffentlichung sollte geprüft werden:

Ist der Inhalt fachlich korrekt?

Ist die Zielgruppe klar?

Ist der Artikel verständlich?

Sind Schritte vollständig?

Sind Risiken genannt?

Sind Screenshots aktuell?

Gibt es Sicherheits- oder Datenschutzprobleme?

Ist der Artikel mit Service oder CI verknüpft?

Ist ein Owner eingetragen?

Gibt es ein Review-Datum?

Ungeprüfte Artikel können mehr Schaden als Nutzen verursachen.

Wissen veröffentlichen

Bei Veröffentlichung ist wichtig:

passender Titel,

klare Suchbegriffe,

sinnvolle Kategorie,

Zielgruppe,

Zugriffsschutz,

Version oder Gültigkeit,

Owner,

Veröffentlichungsdatum,

Review-Datum,

Verknüpfung zu Service, CI, Known Error oder Change.

Ein Artikel muss so veröffentlicht werden, dass er im richtigen Moment gefunden wird.

Wissen nutzen

Wissen sollte aktiv in Prozesse eingebunden sein.

Beispiele:

Service Desk sucht beim Ticketstart nach Artikeln,

Ticketformular schlägt passende Artikel vor,

Benutzer erhalten Self-Service-Vorschläge,

Known Errors sind mit Incidents verknüpft,

Change-Abschluss verlangt Knowledge-Prüfung,

Problem-Abschluss verlangt Workaround- oder Known-Error-Dokumentation.

Ungenutztes Wissen veraltet schneller.

Feedback sammeln

Feedback hilft, Knowledge-Artikel zu verbessern.

Mögliche Signale:

Artikel wird häufig genutzt,

Artikel wird selten gefunden,

Benutzer bewerten Artikel schlecht,

Service Desk ergänzt immer wieder dieselbe Erklärung,

Artikel löst das Problem nicht,

Suchbegriffe führen zu keinem Treffer,

Artikel ist nach Release veraltet,

Schrittfolge ist unklar.

Feedback sollte einfach möglich sein.

Wissen aktualisieren

Artikel müssen aktualisiert werden, wenn sich etwas ändert.

Auslöser:

Change,

Release,

neuer Known Error,

gelöster Known Error,

neue Version,

neuer Menüpfad,

geänderte Zuständigkeit,

geänderter Workaround,

Sicherheitswarnung,

Benutzerfeedback,

neue Screenshots,

geänderter Service.

Ein Artikel ohne Pflegeverantwortung veraltet meist schnell.

Wissen archivieren

Nicht mehr gültige Artikel sollten archiviert oder entfernt werden.

Beispiele:

alter Workaround gilt nicht mehr,

Service wurde abgeschaltet,

Version ist nicht mehr im Einsatz,

Known Error wurde behoben,

Anleitung bezieht sich auf alte Oberfläche,

Sicherheitsanweisung wurde ersetzt.

Archivierung kann sinnvoll sein, wenn spätere Nachvollziehbarkeit wichtig ist.

Veraltete Artikel sollten aber nicht mehr als aktuelle Lösung erscheinen.

Qualitätsmerkmale guter Knowledge-Artikel

Ein guter Artikel ist:

fachlich korrekt,

aktuell,

klar strukturiert,

verständlich,

zielgruppengerecht,

auffindbar,

mit Service oder CI verknüpft,

mit Owner versehen,

risikoarm anwendbar,

getestet,

und regelmäßig überprüft.

Ein guter Artikel beantwortet nicht alles.

Er beantwortet genau das, was die Zielgruppe in dieser Situation braucht.

Struktur eines Supportartikels

Ein Service-Desk-Artikel kann enthalten:

Titel,

Kurzbeschreibung,

Symptome,

betroffener Service,

Zielgruppe,

Voraussetzungen,

Prüfschritte,

Lösung oder Workaround,

Abbruchkriterien,

Eskalationsweg,

Risiken,

verwandte Artikel,

Owner,

Review-Datum.

Nicht jeder Artikel benötigt alle Felder.

Die Struktur muss zum Zweck passen.

Struktur eines Benutzerartikels

Ein Benutzerartikel sollte besonders verständlich sein.

Mögliche Struktur:

Was ist das Problem?

Wen betrifft es?

Was kann ich selbst tun?

Schritt-für-Schritt-Anleitung,

erwartetes Ergebnis,

wann muss ich ein Ticket erstellen?

welche Informationen soll ich im Ticket angeben?

Link zu weiterem Support.

Benutzerartikel sollten keine unnötigen internen Fachbegriffe enthalten.

Struktur eines Runbooks

Ein Runbook ist eine betriebliche Schritt-für-Schritt-Anleitung.

Mögliche Inhalte:

Zweck,

betroffener Service,

Voraussetzungen,

benötigte Berechtigungen,

Sicherheits- oder Risiko-Hinweise,

genaue Schritte,

Prüfpunkte,

erwartete Ergebnisse,

Abbruchkriterien,

Rollback,

Eskalation,

Dokumentation nach Durchführung.

Runbooks sind besonders wichtig für wiederkehrende technische Betriebsaufgaben.

Titel und Suchbegriffe

Der Titel sollte so gewählt werden, dass Benutzer oder Service Desk den Artikel finden.

Ungeeignet:

Fehler 0x80231-A Spezialfall

Besser:

VPN verbindet nach Ruhezustand nicht mehr

Ungeeignet:

Authentifizierungsproblem Anwendung X

Besser:

Anmeldung im Mitarbeiterportal schlägt fehl

Ein Artikel kann zusätzlich Synonyme oder typische Fehlermeldungen enthalten.

Artikel kurz und praktisch halten

Zu lange Artikel werden oft nicht gelesen.

Besser sind:

klare Überschriften,

kurze Schritte,

konkrete Beispiele,

Tabellen bei Varianten,

Hinweise auf Risiken,

Links zu tieferer Dokumentation.

Ein Artikel sollte nicht versuchen, ein ganzes Handbuch zu ersetzen.

Für tiefe technische Details kann auf Runbooks oder Fachteamdokumentation verwiesen werden.

Wissensfreigabe

Nicht jeder Artikel darf ohne Prüfung veröffentlicht werden.

Freigabe kann erforderlich sein bei:

Sicherheitsanweisungen,

Workarounds mit Risiko,

Benutzerkommunikation,

Anleitungen mit Administratorrechten,

Datenschutzbezug,

Änderungen an kritischen Services,

rechtlichen oder vertraglichen Aussagen.

Die Freigabe muss aber zum Risiko passen.

Zu viel Freigabeaufwand verhindert schnelle Wissensnutzung.

Zugriffsschutz

Knowledge-Artikel können unterschiedliche Sichtbarkeit haben.

Beispiele:

Sichtbarkeit	Beispiel
öffentlich für Benutzer	MFA einrichten
intern für Service Desk	Prüfschritte bei VPN-Störung
nur Fachteam	Datenbank-Restart-Runbook
vertraulich	Sicherheitsvorfall-Prozess
Management	Risiko- und Statusübersicht

Zu viele Einschränkungen verhindern Nutzen.

Zu wenig Einschränkung kann Sicherheitsrisiken erzeugen.

Knowledge Owner

Ein Knowledge Owner ist verantwortlich für Inhalt und Aktualität eines Artikels.

Aufgaben:

fachliche Korrektheit prüfen,

Review durchführen,

Änderungen einarbeiten,

veraltete Inhalte entfernen,

Feedback bewerten,

Gültigkeit bestätigen,

verwandte Artikel prüfen.

Ohne Owner veralten Artikel häufig.

Review-Datum

Ein Review-Datum zeigt, wann ein Artikel überprüft werden muss.

Besonders wichtig bei:

sicherheitsrelevanten Artikeln,

Workarounds,

Known Errors,

Benutzeranleitungen mit Screenshots,

Runbooks,

Artikeln zu kritischen Services,

Lieferantenabhängigkeiten.

Ein Artikel kann auch vor dem Review-Datum aktualisiert werden, wenn ein Change oder Release den Inhalt verändert.

Wissensqualität messen

Mögliche Kennzahlen:

Kennzahl	mögliche Aussage
häufig genutzte Artikel	wichtiges Wissen
schlechte Bewertungen	Artikel unklar oder falsch
Suchanfragen ohne Treffer	Wissenslücke
Artikel ohne Owner	Pflegeproblem
Artikel ohne Review	Aktualität unsicher
Tickets trotz Artikel	Artikel nicht auffindbar oder nicht hilfreich
Workarounds ohne Artikel	Wissen nicht verfügbar
alte Artikel mit hoher Nutzung	Risiko veralteter Informationen

Kennzahlen müssen mit Feedback und Kontext bewertet werden.

Knowledge Management und KCS

Viele Organisationen orientieren sich an Ansätzen wie Knowledge-Centered Service (KCS).

Grundidee:

Wissen entsteht während der Arbeit,

Lösungen werden beim Bearbeiten von Tickets erfasst,

Artikel werden durch Nutzung verbessert,

Wissen wird nicht erst nachträglich als Zusatzaufgabe gepflegt.

Wichtig:

KCS ist ein Praxisansatz und nicht identisch mit ITIL.

Er kann Knowledge Management sinnvoll ergänzen.

Wissen während der Arbeit erfassen

Gute Praxis ist:

Wenn ein Incident gelöst wird, prüfe, ob Wissen dokumentiert werden sollte.

Wenn ein Artikel fehlt, erstelle einen Entwurf.

Wenn ein Artikel falsch ist, markiere oder korrigiere ihn.

Wenn ein Workaround genutzt wird, verknüpfe ihn.

Wenn ein Known Error entsteht, veröffentliche passende Informationen.

Wenn ein Release kommt, aktualisiere relevante Artikel.

Wissen sollte dort entstehen, wo die Arbeit stattfindet.

Typische Fehler

Fehler 1

Knowledge Base wird als Ablage für alte Dokumente genutzt.

Fehler 2

Artikel haben keinen Owner.

Fehler 3

Artikel werden veröffentlicht, aber nie überprüft.

Fehler 4

Benutzerartikel sind zu technisch.

Fehler 5

Interne Runbooks sind für Benutzer sichtbar.

Fehler 6

Workarounds stehen nur in Tickets.

Fehler 7

Known Errors werden nicht mit Artikeln verknüpft.

Fehler 8

Service Desk nutzt vorhandenes Wissen nicht.

Fehler 9

Suchbegriffe passen nicht zur Sprache der Benutzer.

Fehler 10

Nach Changes und Releases werden Artikel nicht aktualisiert.

Fehler 11

Feedback wird gesammelt, aber nicht bearbeitet.

Fehler 12

Veraltete Artikel bleiben als aktuelle Lösung sichtbar.

Praxisbeispiel: VPN-Fehler

Situation

Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung.

Problem

Der Service Desk erklärt den Workaround jedes Mal neu.

Knowledge Management

Ein Artikel wird erstellt mit:

Symptomen,

betroffener Clientversion,

Prüfschritten,

Workaround,

Eskalationsweg,

Known-Error-Verknüpfung.

Nutzen

Neue Incidents werden schneller gelöst.

Der Service Desk arbeitet einheitlicher.

Praxisbeispiel: MFA-Einrichtung

Situation

Viele Benutzer erstellen Tickets zur MFA-Einrichtung.

Analyse

Der Self-Service-Artikel ist schwer auffindbar und zu technisch.

Verbesserung

neuer Titel mit Benutzerbegriffen,

klare Schritt-für-Schritt-Anleitung,

Screenshots,

Abschnitt „Wann muss ich ein Ticket erstellen?“,

Link direkt im Serviceportal.

Nutzen

Weniger Tickets und bessere Benutzererfahrung.

Praxisbeispiel: Change macht Artikel veraltet

Situation

Nach einem Release ändern sich Menüpfade im Mitarbeiterportal.

Problem

Der alte Knowledge-Artikel zeigt falsche Schritte.

Folge

Benutzer erstellen Tickets, obwohl die Funktion vorhanden ist.

Verbesserung

Change-Abschluss enthält künftig die Prüfung betroffener Knowledge-Artikel.

Praxisbeispiel: Runbook fehlt

Situation

Ein Dienst muss regelmäßig kontrolliert neu gestartet werden.

Problem

Nur ein erfahrener Administrator kennt die genaue Reihenfolge.

Risiko

Bei Abwesenheit wird der Dienst falsch neu gestartet.

Knowledge Management

Ein Runbook wird erstellt mit:

Voraussetzungen,

Schritten,

Prüfungen,

Abbruchkriterien,

Rollback,

Eskalationsweg.

Nutzen

Die Aufgabe wird sicherer und wiederholbarer.

Checkliste Knowledge-Artikel erstellen

Checkliste Benutzerartikel

einfache Sprache

keine unnötigen internen Begriffe

klare Schrittfolge

Screenshots aktuell, falls verwendet

Suchbegriffe der Benutzer berücksichtigt

Voraussetzungen genannt

erwartetes Ergebnis beschrieben

Ticketweg erklärt

keine vertraulichen internen Informationen enthalten

Checkliste interner Supportartikel

bekannte Symptome beschrieben

betroffene Services oder CIs verknüpft

Prüfschritte enthalten

Workaround beschrieben

Abbruchkriterien genannt

Eskalationskriterien definiert

Known Error verknüpft, falls vorhanden

Risiken beschrieben

Owner und Review-Datum vorhanden

Checkliste Knowledge-Pflege

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker besitzen viel praktisches Betriebswissen.

Dieses Wissen ist besonders wertvoll, wenn es dokumentiert und nutzbar gemacht wird.

Im Arbeitsalltag bedeutet das:

Lösungen aus Incidents als Wissen sichern,

wiederkehrende Fehler als Artikel dokumentieren,

technische Runbooks schreiben,

Workarounds sauber beschreiben,

bekannte Risiken nennen,

Service Desk mit Prüfschritten unterstützen,

nach Changes Dokumentation aktualisieren,

und veraltete Artikel melden oder korrigieren.

Gute Wissensarbeit spart nicht nur Zeit.

Sie macht IT-Betrieb zuverlässiger und weniger abhängig von Einzelpersonen.

Zusammenfassung

Wissensbedarf erkennen
↓
Wissen während der Arbeit erfassen
↓
Zielgruppe und Zweck festlegen
↓
Artikel strukturiert erstellen
↓
fachlich prüfen
↓
veröffentlichen und auffindbar machen
↓
in Incident, Problem, Change und Service Desk nutzen
↓
Feedback auswerten
↓
Artikel aktualisieren oder archivieren
↓
Wissensqualität kontinuierlich verbessern

Merksätze

Wissen ist nur wertvoll, wenn es gefunden, verstanden und genutzt wird.

Eine Knowledge Base ist kein Ablageort für beliebige Dokumente.

Benutzer, Service Desk und Fachteam benötigen unterschiedliche Detailtiefe.

Workarounds gehören nicht nur ins Ticket, sondern in nutzbare Knowledge-Artikel.

Nach Changes und Releases muss Wissen aktualisiert werden.

Veraltetes Wissen kann neue Incidents verursachen.

Gute Wissensarbeit reduziert Abhängigkeit von Einzelpersonen.

Verwandte Seiten

7.2 Knowledge-Artikel, Runbooks und FAQ

7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk

7.4 Self-Service und Benutzerwissen

7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change

Incident Management

Problem Management

Change Enablement

Release Management

Service Configuration Management

Continual Improvement

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Knowledge Management

PeopleCert – ITIL Practice Guide: Incident Management

PeopleCert – ITIL Practice Guide: Problem Management

PeopleCert – ITIL Practice Guide: Change Enablement

PeopleCert – ITIL Practice Guide: Release Management

ITIL Foundation – Version 5

Ergänzende Praxiseinordnung

Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support

Einordnung

Die dargestellten:

Artikeltypen,

Checklisten,

Rollenhinweise,

Lebenszyklusmodelle,

Qualitätskriterien,

und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

Knowledge-Artikel-Vorlage,

Review-Frequenz,

Knowledge-Base-Struktur,

Rollenverteilung,

KCS-Nutzung,

oder Toolauswahl

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

Services,

Zielgruppen,

Supportmodell,

Sicherheitsanforderungen,

Knowledge-Werkzeuge,

Datenqualität,

Organisation,

Change-Modell,

und verfügbare Fähigkeiten

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026