# 7.5 Knowledge Management im Zusammenspiel mit Incident, Problem und Change > **Kurz erklärt** > > Knowledge Management wirkt nicht isoliert. > > Es verbindet Wissen aus Incident Management, Problem Management, Change Enablement, Release Management, Service Desk und Service Configuration Management. > > Ziel ist, dass Erfahrungen, Lösungen, Workarounds, Known Errors, Runbooks und Benutzerinformationen im richtigen Moment verfügbar sind. --- **Warum das Zusammenspiel wichtig ist** Im IT-Betrieb entsteht Wissen ständig während der Arbeit. Beispiele: - ein Incident wird gelöst, - ein Workaround wird gefunden, - ein Problem wird analysiert, - ein Known Error wird dokumentiert, - ein Change verändert einen Service, - ein Release bringt neue Funktionen, - ein Benutzerartikel wird nach Rückfragen verbessert, - ein Major Incident erzeugt Lessons Learned. Wenn dieses Wissen nicht in Knowledge Management einfließt, geht es verloren. Dann entstehen typische Probleme: - gleiche Incidents werden immer wieder neu analysiert, - Service Desk nutzt veraltete Informationen, - Workarounds stehen nur in einzelnen Tickets, - Benutzer erhalten widersprüchliche Antworten, - Knowledge-Artikel passen nicht mehr zur aktuellen Version, - Known Errors sind nicht auffindbar, - Changes verändern Services, aber Artikel bleiben alt, - und Verbesserungen werden nicht dauerhaft übernommen. --- **Grundidee des Zusammenspiels** Incident tritt auf ↓ Service Desk nutzt vorhandenes Wissen ↓ fehlendes oder falsches Wissen wird erkannt ↓ Problem Management analysiert wiederkehrende Ursachen ↓ Known Error oder Workaround entsteht ↓ Knowledge Management macht dieses Wissen nutzbar ↓ Change oder Release setzt dauerhafte Lösung um ↓ Knowledge-Artikel, Runbooks und FAQ werden aktualisiert ↓ zukünftige Incidents werden schneller gelöst oder vermieden Knowledge Management ist damit ein Lernkreislauf im IT-Betrieb. --- **Zusammenspiel mit Incident Management** Incident Management nutzt Knowledge, um Services schneller wiederherzustellen. Nützlich sind: - bekannte Symptome, - Standardlösungen, - Workarounds, - Known Errors, - Prüfschritte, - Eskalationsregeln, - Benutzerinformationen, - Runbooks, - Service-Desk-Artikel. Beispiel: Ein Benutzer meldet, dass VPN nach dem Ruhezustand nicht mehr verbindet. Der Service Desk findet einen Knowledge-Artikel mit: - betroffenem VPN-Client, - Prüfschritten, - Workaround, - Eskalationskriterien, - Verknüpfung zum Known Error. Dadurch muss der Incident nicht neu analysiert werden. --- **Incident Management liefert Wissen zurück** Incidents zeigen, welches Wissen fehlt oder verbessert werden muss. Beispiele: - neuer Fehler tritt auf, - bekannter Workaround funktioniert nicht mehr, - Artikel ist unverständlich, - Suchbegriff fehlt, - Eskalationsweg ist falsch, - Benutzer stellen immer dieselbe Frage, - Service Desk ergänzt immer wieder dieselbe Erklärung, - Artikel passt nicht zur aktuellen Version. Diese Erkenntnisse sollten in Knowledge Management zurückfließen. Ein gelöster Incident kann also Auslöser für einen neuen oder verbesserten Knowledge-Artikel sein. --- **Wann aus einem Incident ein Knowledge-Artikel entstehen sollte** Ein Knowledge-Artikel ist sinnvoll, wenn: - der Incident wahrscheinlich wieder auftreten wird, - die Lösung wiederverwendbar ist, - ein Workaround gefunden wurde, - Service Desk künftig schneller reagieren kann, - Benutzer eine Anleitung benötigen, - eine Fehlermeldung häufig vorkommt, - eine Eskalation klar geregelt werden muss, - oder der Fall für neue Mitarbeitende hilfreich ist. Nicht jeder einzelne Incident benötigt einen eigenen Artikel. Aber wiederkehrende oder typische Fälle sollten dokumentiert werden. --- **Zusammenspiel mit Problem Management** Problem Management erzeugt besonders wertvolles Wissen. Beispiele: - Ursachenanalyse, - bekannte Ursachen, - beitragende Faktoren, - Known Errors, - Workarounds, - dauerhafte Lösungen, - Risiken, - Lessons Learned, - wiederkehrende Muster. Dieses Wissen darf nicht nur im Problem Record bleiben. Es muss so aufbereitet werden, dass es im Service Desk, in Fachgruppen oder im Self-Service genutzt werden kann. --- **Problem Management liefert Known Errors** Ein Known Error sollte in Knowledge Management nutzbar gemacht werden. Ein guter Known-Error-Artikel enthält: - Fehlerbild, - betroffener Service, - betroffene Version, - Ursache oder wahrscheinliche Ursache, - Workaround, - Risiken, - Einschränkungen, - Eskalationskriterien, - dauerhafte Lösung, - Status, - Problem-Verknüpfung, - Review-Datum. Dadurch kann Incident Management neue Incidents schneller zuordnen. --- **Knowledge Management unterstützt Problem Management** Knowledge Management hilft Problem Management durch: - historische Artikel, - bekannte Workarounds, - häufig genutzte Lösungen, - Suchanfragen ohne Treffer, - wiederkehrende Service-Desk-Fragen, - schlecht bewertete Artikel, - Hinweise auf Knowledge-Lücken, - Nutzungsauswertungen, - Verknüpfungen zu Incidents. Beispiel: Ein Workaround-Artikel wird sehr häufig genutzt. Das kann ein Hinweis sein, dass ein Problem weiterhin offen ist und eine dauerhafte Lösung benötigt. --- **Zusammenspiel mit Change Enablement** Changes verändern Services, Systeme, Prozesse und Benutzeroberflächen. Dadurch kann Wissen veralten. Nach einem Change müssen möglicherweise aktualisiert werden: - Benutzerartikel, - FAQ, - Service-Desk-Artikel, - Runbooks, - Known Errors, - Workarounds, - Screenshots, - Menüpfade, - Eskalationswege, - Servicebeschreibungen, - Monitoringhinweise, - CMDB-Verknüpfungen. Ein Change ist nicht vollständig abgeschlossen, wenn die technische Änderung umgesetzt wurde, aber das Wissen noch den alten Zustand beschreibt. --- **Knowledge-Prüfung im Change-Abschluss** Beim Abschluss eines Changes sollte geprüft werden: - Welche Artikel sind betroffen? - Haben sich Schritte, Screenshots oder Menüpfade geändert? - Gibt es neue Fehlermeldungen? - Wurde ein Known Error behoben? - Ist ein Workaround noch gültig? - Muss ein Benutzerartikel erstellt werden? - Muss der Service Desk informiert werden? - Muss ein Runbook angepasst werden? - Muss ein Artikel archiviert werden? Diese Prüfung sollte Teil der Change-Nachbereitung sein. --- **Beispiel: Change macht Wissen veraltet** **Situation** Eine Anwendung erhält eine neue Oberfläche. **Problem** Der Self-Service-Artikel beschreibt noch die alte Menüführung. **Folge** Benutzer finden die Funktion nicht und erstellen Tickets. **Verbesserung** Change Enablement ergänzt eine Pflichtprüfung: > Welche Knowledge-Artikel, FAQ und Screenshots müssen vor oder nach dem Change aktualisiert werden? --- **Zusammenspiel mit Release Management** Releases bringen neue oder geänderte Funktionen. Knowledge Management unterstützt Releases durch: - Release Notes, - Benutzerinformationen, - FAQ, - Service-Desk-Briefings, - Known Errors, - bekannte Einschränkungen, - neue Workarounds, - aktualisierte Runbooks, - Schulungsunterlagen. Ein Release ohne Knowledge-Vorbereitung führt häufig zu unnötigen Rückfragen. --- **Release-Wissen vor Veröffentlichung vorbereiten** Vor einem Release sollte geklärt werden: - Was ändert sich für Benutzer? - Welche Funktionen sind neu? - Welche Funktionen ändern sich? - Welche bekannten Einschränkungen bestehen? - Welche Artikel müssen aktualisiert werden? - Welche Fragen werden Benutzer wahrscheinlich stellen? - Welche Informationen benötigt der Service Desk? - Welche Known Errors sind relevant? - Welche Workarounds sind freigegeben? Gute Release-Kommunikation reduziert Incidents nach der Einführung. --- **Zusammenspiel mit Service Desk** Der Service Desk ist gleichzeitig Nutzer und Lieferant von Wissen. Er nutzt Knowledge für: - schnelle Antworten, - Standardlösungen, - Workarounds, - Eskalation, - Benutzerkommunikation, - Ticketdokumentation. Er liefert Knowledge zurück durch: - Feedback zu Artikeln, - Hinweise auf fehlende Inhalte, - wiederkehrende Fragen, - neue Fehlerbilder, - Suchbegriffe aus der Praxis, - Rückmeldungen von Benutzern. Der Service Desk sollte deshalb aktiv in Knowledge Management eingebunden sein. --- **Service Desk als Qualitätsfilter** Der Service Desk erkennt schnell, ob Wissen im Alltag funktioniert. Typische Rückmeldungen: - Artikel wird nicht gefunden, - Titel passt nicht zur Benutzersprache, - Schritte sind unklar, - Screenshot ist veraltet, - Workaround funktioniert nicht, - Eskalationsweg stimmt nicht, - Artikel ist zu lang, - Artikel enthält zu viele interne Details, - Benutzer verstehen die Anleitung nicht. Diese Rückmeldungen sollten regelmäßig ausgewertet werden. --- **Zusammenspiel mit Self-Service** Self-Service nutzt Knowledge, damit Benutzer einfache Anliegen selbst lösen können. Geeignet sind: - FAQ, - Benutzeranleitungen, - Statusinformationen, - bekannte sichere Workarounds, - Servicebeschreibungen, - Request-Formulare, - Passwort- und MFA-Hilfen, - Softwarekatalog, - Onboarding-Anleitungen. Self-Service braucht besonders klare Sprache. Interne Diagnoseschritte oder sicherheitskritische Informationen gehören nicht ungeprüft in Benutzerartikel. --- **Self-Service liefert Wissen zurück** Self-Service-Daten zeigen, was Benutzer wirklich suchen. Wichtige Signale: - häufige Suchanfragen, - Suchanfragen ohne Treffer, - häufig geöffnete Artikel, - schlechte Bewertungen, - hohe Formularabbrüche, - viele Tickets nach Artikelaufruf, - wiederkehrende Begriffe aus Benutzertexten. Diese Daten helfen, Knowledge-Artikel, FAQ und Formulare zu verbessern. --- **Zusammenspiel mit Service Configuration Management** Service Configuration Management liefert Kontext zu Wissen. Wichtige Verknüpfungen: - Artikel zu Service, - Artikel zu Configuration Item, - Known Error zu betroffener Version, - Runbook zu Anwendung oder Server, - Workaround zu Problem Record, - Benutzerartikel zu Servicekatalogeintrag, - Release Notes zu Anwendungsversion. Ohne Service- oder CI-Bezug sind Knowledge-Artikel schwerer auffindbar und schwerer aktuell zu halten. --- **Beispiel: Knowledge und CI-Verknüpfung** Ein Artikel beschreibt einen VPN-Fehler. Sinnvolle Verknüpfungen: - Service: VPN-Zugang, - CI: VPN-Client-Version, - CI: VPN-Gateway, - CI: Identity Provider, - Problem Record, - Known Error, - geplanter Change. Dadurch kann der Artikel bei passenden Incidents automatisch vorgeschlagen oder schneller gefunden werden. --- **Zusammenspiel mit Information Security Management** Sicherheitswissen muss besonders sorgfältig gepflegt werden. Beispiele: - Phishing melden, - verlorenes Gerät melden, - MFA-Probleme, - Passwortregeln, - verdächtige Anmeldung, - Sicherheitsvorfall-Prozess, - Umgang mit sensiblen Daten, - sichere Dateiablage, - Meldewege, - Verhalten bei Verdacht auf Kompromittierung. Sicherheitsartikel müssen verständlich sein. Sie dürfen aber keine internen Schutzmechanismen unnötig offenlegen. --- **Sicherheitsrelevante Knowledge-Artikel** Bei sicherheitsrelevanten Artikeln ist zu prüfen: - Wer darf den Artikel sehen? - Sind interne Details geschützt? - Ist die Anleitung missbrauchssicher? - Gibt es klare Meldewege? - Ist der Inhalt fachlich freigegeben? - Ist der Artikel aktuell? - Ist ein Review-Datum gesetzt? - Sind Datenschutzanforderungen berücksichtigt? Falsches Sicherheitswissen kann zu hohen Risiken führen. --- **Zusammenspiel mit Continual Improvement** Knowledge Management liefert viele Hinweise für Verbesserungen. Beispiele: - häufige Suchanfragen ohne Treffer, - viele Tickets trotz Self-Service-Artikel, - häufig genutzte Workarounds, - schlecht bewertete Artikel, - veraltete Runbooks, - fehlende Knowledge-Verknüpfungen, - wiederkehrende Benutzerfragen, - viele Eskalationen wegen fehlender Prüfschritte. Diese Erkenntnisse sollten in Continual Improvement einfließen. --- **Knowledge als Verbesserungsquelle** Ein sinnvoller Verbesserungsablauf: Knowledge-Daten auswerten ↓ Lücken und Qualitätsprobleme erkennen ↓ Verbesserungsmaßnahme definieren ↓ Owner und Termin festlegen ↓ Artikel, Formular oder Prozess verbessern ↓ Wirkung messen ↓ Ergebnis in Continual Improvement übernehmen Knowledge Management ist damit nicht nur Dokumentation, sondern auch Verbesserungsarbeit. --- **Wissen im Lebenszyklus eines Incidents** Benutzer meldet Störung ↓ Service Desk sucht passenden Artikel ↓ Artikel liefert Prüfschritte oder Workaround ↓ Incident wird gelöst oder eskaliert ↓ Ticket wird mit Artikel verknüpft ↓ Feedback zum Artikel wird dokumentiert ↓ Knowledge-Artikel wird bei Bedarf verbessert So wird jeder Incident zu einer möglichen Quelle für besseres Wissen. --- **Wissen im Lebenszyklus eines Problems** Wiederkehrende Incidents werden erkannt ↓ Problem Record wird erstellt ↓ Ursache oder wahrscheinliche Ursache wird analysiert ↓ Known Error wird dokumentiert ↓ Workaround wird erstellt ↓ Service Desk erhält Knowledge-Artikel ↓ dauerhafte Lösung wird verfolgt ↓ Artikel wird nach Lösung aktualisiert oder archiviert Problem Management und Knowledge Management arbeiten hier besonders eng zusammen. --- **Wissen im Lebenszyklus eines Changes** Change wird geplant ↓ betroffene Artikel und Runbooks werden identifiziert ↓ Service Desk und Benutzerinformationen werden vorbereitet ↓ Change wird umgesetzt ↓ Wissen wird aktualisiert ↓ alte Artikel werden angepasst oder archiviert ↓ Feedback nach Change wird ausgewertet So verhindert Change Enablement, dass veraltetes Wissen im Betrieb bleibt. --- **Wissensverknüpfungen** Gute Knowledge-Arbeit nutzt Verknüpfungen. Mögliche Verknüpfungen: - Knowledge-Artikel zu Incident, - Knowledge-Artikel zu Problem, - Known Error zu Workaround, - Workaround zu Service, - Runbook zu CI, - Benutzerartikel zu Servicekatalog, - Artikel zu Change, - Artikel zu Release, - Artikel zu Sicherheitsmeldung. Verknüpfungen verbessern Auffindbarkeit, Auswertung und Pflege. --- **Rollen im Zusammenspiel** | Rolle | Beitrag zu Knowledge Management | |---|---| | **Service Desk** | nutzt Artikel, gibt Feedback, erkennt Wissenslücken | | **Fachteam** | liefert technische Inhalte und prüft Richtigkeit | | **Problem Management** | liefert Known Errors, Ursachen und Workarounds | | **Change Management** | sorgt für Aktualisierung nach Changes | | **Release Management** | liefert Release Notes und neue Informationen | | **Service Owner** | prüft fachliche Richtigkeit und Benutzerwirkung | | **Security Team** | prüft sicherheitsrelevante Inhalte | | **Knowledge Owner** | verantwortet Pflege, Review und Qualität | Rollen können je nach Organisation unterschiedlich benannt sein. Wichtig sind klare Verantwortlichkeiten. --- **Knowledge Owner** Ein Knowledge Owner sorgt dafür, dass ein Artikel aktuell und korrekt bleibt. Aufgaben: - fachliche Prüfung, - Review, - Feedback bewerten, - Änderungen einarbeiten, - veraltete Inhalte archivieren, - Zielgruppe prüfen, - Zugriffsschutz prüfen, - Verknüpfungen pflegen. Ohne Knowledge Owner veralten wichtige Artikel schnell. --- **Service Owner** Der Service Owner hilft zu klären: - welche Benutzerinformationen nötig sind, - welche Servicebeschreibung korrekt ist, - welche Auswirkungen ein Known Error hat, - welche Kommunikation freigegeben ist, - welche Artikel für den Service wichtig sind, - welche Inhalte nach Changes angepasst werden müssen. Service Owner verbinden technische Informationen mit Service- und Benutzerperspektive. --- **Fachteams** Fachteams liefern technisches Wissen. Beispiele: - Logauswertung, - Ursache, - Konfigurationsdetails, - technische Risiken, - sichere Workarounds, - Runbooks, - Abbruchkriterien, - Rollback-Hinweise, - technische Prüfungen nach Changes. Fachteams sollten Wissen so aufbereiten, dass Service Desk oder Benutzer es passend nutzen können. --- **Wissen für verschiedene Zielgruppen aufbereiten** Ein technischer Sachverhalt kann mehrere Wissensformen benötigen. Beispiel: Zertifikatsproblem **Benutzerartikel** - aktuelle Einschränkung, - was Benutzer tun können, - wo Statusinformationen stehen. **Service-Desk-Artikel** - Symptome, - betroffener Service, - Eskalationsweg, - freigegebene Kommunikation. **Fachteam-Runbook** - Zertifikat prüfen, - Zertifikat erneuern, - Dienst testen, - Monitoring prüfen, - CMDB aktualisieren. Ein Artikel für alle Zielgruppen ist oft nicht sinnvoll. --- **Wissensqualität im Zusammenspiel** Wissensqualität bedeutet: - richtige Information, - richtige Zielgruppe, - richtige Detailtiefe, - richtige Sichtbarkeit, - richtige Verknüpfung, - aktueller Stand, - klarer Owner, - regelmäßiger Review. Ein fachlich richtiger Artikel kann trotzdem schlecht sein, wenn er für die Zielgruppe unverständlich ist. Ein gut geschriebener Artikel kann gefährlich sein, wenn er veraltet ist. --- **Kennzahlen für das Zusammenspiel** Mögliche Kennzahlen: | Kennzahl | mögliche Aussage | |---|---| | Incidents mit verknüpftem Knowledge-Artikel | Nutzung im Service Desk | | häufig genutzte Artikel | wichtige Supportthemen | | Suchanfragen ohne Treffer | Wissenslücken | | Artikel ohne Owner | Pflegeproblem | | Artikel ohne Review-Datum | Aktualitätsrisiko | | Tickets trotz Self-Service-Artikel | Artikel nicht hilfreich oder Problem weiterhin häufig | | Known Errors ohne Artikel | Wissen fehlt im Support | | Changes ohne Knowledge-Prüfung | Risiko veralteter Artikel | | schlechte Artikelbewertungen | Qualitätsproblem | Kennzahlen müssen mit Feedback und fachlicher Bewertung kombiniert werden. --- **Wissen aus Major Incidents** Major Incidents liefern besonders wichtige Erkenntnisse. Nach einem Major Incident sollte geprüft werden: - Welche Informationen haben gefehlt? - Welche Runbooks waren hilfreich? - Welche Artikel waren veraltet? - Welche Kommunikation war unklar? - Welche Workarounds wurden genutzt? - Welche Known Errors entstanden? - Welche Benutzerinformationen müssen verbessert werden? - Welche Lessons Learned gehören in Knowledge Management? Ein Major Incident Review ohne Knowledge-Aktualisierung verschenkt Lernpotenzial. --- **Wissen aus Failed Changes** Auch fehlgeschlagene Changes liefern wertvolles Wissen. Zu prüfen ist: - War das Runbook ausreichend? - War der Rollback beschrieben? - Waren Tests vollständig? - Gab es fehlende Abhängigkeiten? - War Service Desk informiert? - Müssen Change-Vorlagen verbessert werden? - Muss ein neuer Knowledge-Artikel entstehen? - Muss ein Known Error dokumentiert werden? Failed Changes sollten nicht nur technisch korrigiert, sondern auch wissensseitig ausgewertet werden. --- **Wissen aus Releases** Nach Releases sollte beobachtet werden: - Welche Fragen stellen Benutzer? - Welche Incidents entstehen? - Welche Artikel werden häufig aufgerufen? - Welche Suchbegriffe führen zu keinem Treffer? - Welche Screenshots sind veraltet? - Welche Known Errors sind neu? - Welche FAQ fehlt? So kann Knowledge Management schnell auf reale Benutzerfragen reagieren. --- **Praxisbeispiel: VPN-Problem** **Incident Management** Benutzer melden VPN-Abbrüche. **Problem Management** Mehrere Incidents zeigen dasselbe Muster. Ursache ist eine fehlerhafte Client-Version. **Knowledge Management** Ein Known-Error-Artikel wird erstellt. Er enthält: - Fehlerbild, - betroffene Version, - Prüfschritte, - Workaround, - Eskalationskriterien, - geplanten Change. **Change Enablement** Neue Client-Version wird ausgerollt. **Nachbereitung** Knowledge-Artikel wird aktualisiert oder archiviert. --- **Praxisbeispiel: MFA-Self-Service** **Beobachtung** Viele Tickets entstehen wegen neuem Smartphone. **Knowledge Management** Benutzerartikel wird erstellt: - MFA auf neuem Smartphone einrichten, - Screenshots, - Hinweis bei fehlendem Zugriff, - Ticketlink. **Service Desk** Tickets enthalten bessere Informationen. **Continual Improvement** Suchbegriffe und Formular werden verbessert. **Nutzen** Weniger Standardtickets und bessere Benutzererfahrung. --- **Praxisbeispiel: Change veraltet Runbook** **Situation** Nach einem Update ändert sich der Neustartprozess eines Dienstes. **Problem** Das alte Runbook beschreibt noch die frühere Reihenfolge. **Risiko** Administratoren führen im Störungsfall falsche Schritte aus. **Verbesserung** Change-Abschluss enthält künftig: - betroffene Runbooks prüfen, - Knowledge Owner informieren, - Review-Datum setzen, - alte Version archivieren. --- **Praxisbeispiel: Major Incident** **Situation** Ein zentraler Dienst fällt aus. **Review zeigt** - Service Desk hatte keinen passenden Artikel, - Eskalationsweg war unklar, - Statusmeldung musste improvisiert werden, - Runbook für Wiederherstellung war veraltet. **Knowledge-Verbesserungen** - Service-Desk-Artikel erstellen, - Major-Incident-Kommunikationsvorlage ergänzen, - Runbook aktualisieren, - Known Error dokumentieren, - Service Map verlinken. --- **Typische Fehler** **Fehler 1** Knowledge Management wird getrennt von Incident, Problem und Change betrieben. --- **Fehler 2** Gelöste Incidents erzeugen kein wiederverwendbares Wissen. --- **Fehler 3** Problem Management dokumentiert Known Errors, aber der Service Desk findet sie nicht. --- **Fehler 4** Workarounds bleiben nur in Tickets. --- **Fehler 5** Changes aktualisieren Knowledge-Artikel nicht. --- **Fehler 6** Releases erzeugen neue Benutzerfragen, aber keine FAQ. --- **Fehler 7** Service Desk Feedback wird nicht bearbeitet. --- **Fehler 8** Knowledge-Artikel sind nicht mit Services oder CIs verknüpft. --- **Fehler 9** Sicherheitsartikel sind entweder zu offen oder zu stark eingeschränkt. --- **Fehler 10** Major-Incident-Lessons-Learned werden nicht in Knowledge übernommen. --- **Fehler 11** Artikel werden an Kennzahlen gemessen, aber nicht fachlich geprüft. --- **Fehler 12** Niemand ist verantwortlich für Pflege und Review. --- **Checkliste Incident zu Knowledge** - [ ] wiederkehrendes Fehlerbild erkannt - [ ] Lösung oder Workaround dokumentiert - [ ] passende Suchbegriffe ergänzt - [ ] Zielgruppe festgelegt - [ ] Service oder CI verknüpft - [ ] Eskalationsweg beschrieben - [ ] Risiken genannt - [ ] Knowledge-Artikel im Ticket verknüpft - [ ] Feedback aus Ticket berücksichtigt - [ ] Problem Management informiert, falls Muster erkennbar --- **Checkliste Problem zu Knowledge** - [ ] Known Error dokumentiert - [ ] Ursache oder wahrscheinliche Ursache beschrieben - [ ] Workaround beschrieben oder als nicht verfügbar gekennzeichnet - [ ] betroffene Versionen genannt - [ ] betroffene Services und CIs verknüpft - [ ] Service Desk Artikel erstellt - [ ] Benutzerinformation geprüft - [ ] dauerhafte Lösung oder Change vermerkt - [ ] Review-Datum gesetzt - [ ] Artikel nach Lösung aktualisiert oder archiviert --- **Checkliste Change zu Knowledge** - [ ] betroffene Artikel identifiziert - [ ] Benutzerartikel geprüft - [ ] Service-Desk-Artikel geprüft - [ ] Runbooks geprüft - [ ] Screenshots geprüft - [ ] Menüpfade geprüft - [ ] Known Errors geprüft - [ ] Workarounds geprüft - [ ] Service Desk informiert - [ ] Artikel nach Umsetzung aktualisiert - [ ] veraltete Artikel archiviert - [ ] Knowledge-Prüfung im Change Record dokumentiert --- **Checkliste Release zu Knowledge** - [ ] Release Notes erstellt - [ ] neue Funktionen beschrieben - [ ] geänderte Funktionen beschrieben - [ ] bekannte Einschränkungen dokumentiert - [ ] FAQ vorbereitet - [ ] Service Desk gebrieft - [ ] Benutzerkommunikation vorbereitet - [ ] neue Known Errors dokumentiert - [ ] alte Workarounds geprüft - [ ] Suchanfragen nach Release ausgewertet - [ ] Artikel nach Feedback verbessert --- **Checkliste Knowledge-Qualität im Zusammenspiel** - [ ] Artikel besitzt Owner - [ ] Review-Datum vorhanden - [ ] Zielgruppe klar - [ ] Service oder CI verknüpft - [ ] Problem oder Known Error verknüpft, falls relevant - [ ] Change oder Release verknüpft, falls relevant - [ ] Risiken und Grenzen beschrieben - [ ] Eskalationsweg klar - [ ] Zugriffsschutz passend - [ ] Feedbackmöglichkeit vorhanden - [ ] Nutzung wird ausgewertet - [ ] veraltete Inhalte werden archiviert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker stehen häufig genau dort, wo wichtiges Wissen entsteht. Im Arbeitsalltag bedeutet das: - Lösungen aus Incidents dokumentieren, - wiederkehrende Fehler an Problem Management melden, - Workarounds sicher beschreiben, - Known Errors technisch prüfen, - Runbooks für Betriebsaufgaben erstellen, - nach Changes Artikel aktualisieren, - Service Desk mit Prüfschritten unterstützen, - Configuration Items verknüpfen, - Benutzerwissen technisch korrekt vorbereiten, - und Lessons Learned in nutzbare Dokumentation übertragen. Gute Wissensarbeit macht technischen Betrieb stabiler, schneller und weniger abhängig von Einzelpersonen. --- **Zusammenfassung** > Incident liefert Erfahrung > ↓ > Problem Management erkennt Ursachen und Known Errors > ↓ > Knowledge Management macht Wissen nutzbar > ↓ > Service Desk verwendet Artikel im Alltag > ↓ > Change und Release verändern Services > ↓ > Knowledge wird aktualisiert > ↓ > Self-Service stellt Benutzerwissen bereit > ↓ > Feedback und Kennzahlen zeigen Lücken > ↓ > Continual Improvement verbessert Inhalte und Prozesse --- **Merksätze** > Knowledge Management verbindet Lernen mit täglichem IT-Betrieb. > Incidents liefern Hinweise auf fehlendes oder falsches Wissen. > Problem Management liefert Known Errors, Ursachen und Workarounds. > Changes und Releases müssen Knowledge aktualisieren. > Service Desk Feedback ist eine der wichtigsten Quellen für Wissensqualität. > Knowledge ohne Service- oder CI-Bezug ist schwerer nutzbar. > Lessons Learned sind nur wertvoll, wenn sie in nutzbares Wissen überführt werden. --- **Verwandte Seiten** - 7.1 Knowledge Management – Ziele, Begriffe und Grundlagen - 7.2 Knowledge-Artikel, Runbooks und FAQ - 7.3 Known Errors, Workarounds und Wissensnutzung im Service Desk - 7.4 Self-Service und Benutzerwissen - 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 - PeopleCert – ITIL Practice Guide: Service Configuration Management - PeopleCert – ITIL Practice Guide: Continual Improvement - ITIL Foundation – Version 5 **Ergänzende Praxiseinordnung** - Knowledge-Centered Service als verbreiteter Praxisansatz für Wissensarbeit im Support **Einordnung** Die dargestellten: - Schnittstellen, - Informationsflüsse, - Rollenhinweise, - Checklisten, - Praxisbeispiele, - und Qualitätskriterien sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Knowledge-Prozessschnittstelle, - Artikelpflicht nach jedem Incident, - Review-Frequenz, - Verknüpfungsregel, - Rollenmatrix, - oder Toolintegration für alle Organisationen vor. Die konkrete Umsetzung muss an: - Services, - Zielgruppen, - Supportmodell, - Knowledge-Werkzeuge, - Sicherheitsanforderungen, - Problem Management, - Change-Modell, - Release-Modell, - Service Configuration Management, - 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