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 Zielgruppe festgelegt Problem oder Thema klar beschrieben betroffener Service genannt Symptome oder Anlass beschrieben Voraussetzungen genannt Schritte verständlich formuliert erwartetes Ergebnis genannt Risiken oder Einschränkungen beschrieben Eskalationsweg angegeben verwandte Artikel verknüpft Owner eingetragen Review-Datum gesetzt 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 Artikel mit hohem Nutzungsgrad geprüft schlecht bewertete Artikel überprüft Suchanfragen ohne Treffer ausgewertet Artikel ohne Owner bereinigt Artikel ohne Review-Datum geprüft veraltete Artikel archiviert Artikel nach Changes aktualisiert Artikel nach Releases aktualisiert Feedback bearbeitet doppelte Artikel zusammengeführt 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