CAFM Wissensmanagement

Störungsmanagement (Incident Management): Das System muss Störungen/Tickets erfassen und deren Bearbeitung vom Eingang bis zur Lösung steuern. Eingehende Störungsmeldungen (z. B. via Self-Service-Portal, E-Mail oder Hotline) werden kategorisiert und können nach hinterlegten Regeln automatisch einer Support-Gruppe zugewiesen werden (z. B. „Netzwerk-Team“ bei Netzwerkstörung). Service-Level-Agreements (SLAs) sollen hinterlegt werden können, sodass Reaktions- und Lösungszeiten überwacht werden (z. B. Warnung bei SLA-Verletzung). Das Modul soll Eskalationen unterstützen, falls eine Störung nicht innerhalb definierter Fristen gelöst wird (automatische Benachrichtigung höherer Ebenen). Außerdem sollten Vorfälle priorisiert werden können (kritisch, hoch, normal, gering) mit entsprechenden Bearbeitungsworkflows.

Übersichten für Anfragende: Benutzer, die eine Störung gemeldet haben, sollen eine Übersicht ihrer offenen und gelösten Tickets einsehen können. Das System zeigt für jedes Ticket den Status in verständlicher Form (z. B. neu, in Bearbeitung, gelöst, geschlossen) und idealerweise ein Diagramm oder eine Timeline des Bearbeitungsstands. Führungskräfte oder Teamleiter sollen Einblick in alle Tickets ihres Bereichs erhalten können, um sicherzustellen, dass nichts liegenbleibt.

Wissensdatenbank & Problemmanagement: Wiederkehrende oder komplexe Probleme sollen im Modul als Problem erfasst und verwaltet werden. Für jedes Problem kann die Ursache, Workaround und Lösung dokumentiert werden. Das System soll ermöglichen, dass gelöste Probleme in eine Wissensdatenbank bzw. FAQ überführt werden. D.h. Support-Mitarbeiter wie auch Endanwender können in einer Wissenssammlung nach bekannten Lösungen suchen, bevor neue Tickets erstellt werden. Diese Wissensartikel sollten mit Schlagworten und Kategorien versehen sein.

Änderungsmanagement (Change Management): Es muss möglich sein, Change Requests zu erstellen und nach einem definierten Workflow zu bearbeiten. Änderungen können direkt eingegeben werden oder aus einem bestehenden Incident/Problem heraus initiiert werden (Verknüpfung der Datensätze). Das System soll den gesamten Freigabeprozess für Änderungen unterstützen – von der Beschreibung, Risiko- und Impactanalyse, über die Genehmigung durch ein Change Advisory Board (CAB) bis zur Umsetzung und abschließenden Bewertung. Jeder Change sollte mit den betroffenen Configuration Items in der CMDB verknüpft sein, um Historie je CI aufzubauen.

Konfigurationsmanagement (CMDB): Eine CMDB-Funktionalität ist integraler Bestandteil[85]. Das Modul soll ermöglichen, alle wichtigen CIs (z. B. Hardware-Komponenten, Software, Dokumentationen, Verträge, Standorte) zu erfassen, inkl. ihrer Attribute (Hersteller, Typ, Version, Standort, Besitzer etc.) und Beziehungen (z. B. „Server X hostet Anwendung Y“, „Drucker Z gehört zu Standort A“). Änderungen an CIs (durch Change Management) sollten versioniert nachverfolgt werden können. Die CMDB bildet das Herz des Wissensmanagements, da sie das Wissen über die Infrastruktur bereitstellt.

Selbstservice-Portal: Das System soll ein Self-Service-Interface für Endanwender bieten. Dort können Nutzer Störungen melden, Serviceanfragen stellen (z. B. „neue Software beantragen“), den Status ihrer aktuellen Anfragen sehen und in einer FAQ/Wissensdatenbank nach Lösungen suchen. Das Portal sollte intuitiv und möglichst einfach gehalten sein (ggf. mit kurzen Formularen), damit die Hemmschwelle niedrig ist. Optional könnten hier auch vordefinierte Lösungswege angeboten werden (z. B. „Passwort zurücksetzen“ als automatisierter Prozess).

Rollen und Benachrichtigungen: Das Modul muss ein Rollenmodell unterstützen, das typische ITIL-Rollen abbildet (z. B. First-Level-Support, Second-Level, Problem Manager, Change Manager). Aufgaben im Workflow sollen diesen Rollen bzw. zugeordneten Teams zugewiesen werden können. Bei neuen Tickets oder Aufgaben muss das System Benachrichtigungen (E-Mail oder In-App) versenden. Die Empfänger sollen direkt sehen, welche Aufgaben noch offen sind. Zudem muss die Abstimmung zwischen parallelen oder seriellen Aufgaben möglich sein (z. B. Genehmigungen nacheinander).

Grafische Prozessübersicht: Für komplexe Vorgänge (Changes, größere Incidents) wäre es hilfreich, wenn das System einen grafischen Prozessverlauf anzeigen kann. ITIL-Prozesse haben oft mehrere Phasen; eine Diagrammansicht, die den aktuellen Status (markiert) und vorherige/nächste Schritte (ausgegraut) zeigt, erleichtert allen Beteiligten die Orientierung.

Berichte und Service Levels: Das Modul soll Berichte bieten, z. B. Anzahl Tickets pro Monat, durchschnittliche Lösungszeit, SLA-Einhaltungsquote, häufigste Ursachen etc. Dies dient dem Problem Management und der Qualitätskontrolle. Service Level Monitoring soll integriert sein (Warnungen bei drohendem SLA-Bruch). Eine Integration mit einem Monitoring-System wäre von Vorteil, um automatisch Tickets zu erzeugen, wenn ein Systemalarm auftritt (event management, gehört zu ITIL).

Incident-to-Problem Process: Der Ablauf, in dem Incidents zu Problems führen und daraus Lösungen entstehen, muss abgebildet sein. Das heißt, wenn ähnliche Störungen gehäuft auftreten, sollte der Prozess vorsehen, dass ein Problem Ticket eröffnet wird, Root Cause Analysis betrieben wird und ein Known Error eingetragen wird. Nach Implementierung eines Fixes (ggf. via Change) werden alle offenen Incidents geschlossen mit Hinweis auf die Lösung. Das System muss diese Verknüpfungen (mehrere Incidents -> ein Problem -> ggf. Change) ermöglichen und den Prozess technisch unterstützen.

Kontinuierliche Verbesserung: Im Sinne von ITIL und ISO 20000 soll der Prozess so gestaltet sein, dass aus jedem größeren Incident oder Change Lessons Learned ins System zurückfließen. Das System sollte z. B. nach Abschluss eines Changes einen Review-Prozess unterstützen (CAB Meeting, Dokumentation was gut lief/schief lief) und dieses Wissen festhalten. Ebenso sollte die Wissensdatenbank kontinuierlich wachsen – ein Prozess, der z. B. vorsieht, dass Support-Mitarbeiter nach Lösung eines neuen Typs von Störung einen FAQ-Artikel erstellen.

Integration in CAFM/ERP-Prozesse: Obwohl ITIL-Prozesse primär IT-bezogen sind, kann es Integration mit anderen Bereichen geben. Z. B. wenn ein Incident eine Facility-Störung ist (Klimaanlage ausgefallen), sollte er ggf. ins Instandhaltungsmodul überführt werden. Oder Changes können Investitionen auslösen (neue Hardware bestellen, was den Einkaufsprozess anstößt). Das Modul sollte also mit anderen Prozessen interagieren können, z. B. durch Übergabe eines Requests an das Webshop-Modul oder Verknüpfung eines Konfigurationsobjekts mit einem Asset im Inventar.

Service Level Management Prozess: Das System muss Prozesse haben, um Service Level Agreements (SLAs) mit internen Kunden oder externen Dienstleistern zu verwalten. Dazu gehört, dass bei Ticket-Eröffnung gleich der passende SLA (Reaktions-/Lösungszeit) gezogen wird und der Prozess überwacht die Einhaltung. Bei Verstößen sollte ein definierter Prozess folgen (z. B. Eskalation, Bericht an Management, ggf. Vertragsstrafen dokumentieren).

ISO 20000/9001 Audit Trail: Alle ITIL-Prozesse sollten so implementiert sein, dass ein externer Auditor den Ablauf nachvollziehen kann. Das heißt, das System muss alle relevanten Informationen vorhalten (Tickets, Zeitstempel, Verantwortliche, Kommunikation). Prozessual sollten regelmäßige Audits oder Reviews möglich sein, wofür das System Reports bereitstellen kann (z. B. „Alle Changes der letzten 12 Monate mit Dauer und Ergebnis“). Dies unterstützt die Organisation bei einer möglichen ISO 20000 Zertifizierung (IT-Service-Management) und allgemein bei der Qualitätssicherung.