9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management Kurz erklärt Service Request Management arbeitet nicht isoliert. Es steht in engem Zusammenhang mit anderen ITIL Practices. Erst das Zusammenspiel mit Incident Management, Change Enablement, Knowledge Management, Service Level Management, Information Security Management und Continual Improvement ermöglicht eine schnelle, sichere und qualitativ hochwertige Bearbeitung von Service Requests. Jede Practice liefert Informationen oder Leistungen, die den gesamten Request-Prozess unterstützen. Warum das Zusammenspiel wichtig ist Ein Service Request besteht selten nur aus einer einzelnen Tätigkeit. Beispiel: Ein neuer Mitarbeiter benötigt: Benutzerkonto, Microsoft-365-Lizenz, VPN, Notebook, Gruppenberechtigungen, Mobiltelefon. Für die Bereitstellung arbeiten häufig mehrere Teams und Practices zusammen. Das Service Request Management koordiniert dabei den gesamten Ablauf. Zusammenspiel der Practices Service Request │ ▼ Genehmigungen │ ▼ Knowledge nutzen │ ▼ Incident vermeiden │ ▼ Changes ausführen │ ▼ Service bereitstellen │ ▼ Servicequalität messen │ ▼ Verbesserungen umsetzen Die Practices arbeiten parallel und ergänzen sich gegenseitig. Service Request Management und Incident Management Diese beiden Practices werden häufig verwechselt. Der wichtigste Unterschied: Incident Management Service Request Management Störung beheben Service bereitstellen ungeplantes Ereignis geplante Anfrage Ziel: Wiederherstellung Ziel: Erfüllung einer Anforderung häufig hoher Zeitdruck planbare Bearbeitung Trotzdem arbeiten beide eng zusammen. Wenn ein Incident zum Request wird Manchmal stellt sich während der Bearbeitung heraus, dass gar keine Störung vorliegt. Beispiel: Benutzer meldet: "Ich kann Photoshop nicht benutzen." Analyse: Photoshop wurde nie installiert. Es liegt keine Störung vor. Der Incident wird geschlossen. Anschließend wird ein Service Request für die Softwareinstallation erstellt. Wenn ein Request zum Incident wird Auch das Gegenteil ist möglich. Beispiel: Ein Benutzer beantragt VPN. Während der Bereitstellung fällt auf: Der VPN-Gateway ist ausgefallen. Jetzt liegt zusätzlich ein Incident vor. Der Service Request bleibt bestehen, die technische Störung wird jedoch separat als Incident bearbeitet. Parallele Bearbeitung Ein Service Request und ein Incident können gleichzeitig existieren. Beispiel: Request: neues Notebook Incident: Softwareverteilung funktioniert nicht Beide Vorgänge besitzen unterschiedliche Ziele, können sich jedoch gegenseitig beeinflussen. Verknüpfung von Tickets Viele ITSM-Systeme ermöglichen Verknüpfungen. Beispiel: Service Request │ ├──────── Incident │ ├──────── Change │ ├──────── Knowledge Article │ └──────── Configuration Item Dadurch bleiben Zusammenhänge nachvollziehbar. Service Request Management und Change Enablement Viele Requests führen zu Änderungen an der IT-Umgebung. Beispiele: Software installieren, Benutzerkonto erstellen, Firewallregel hinzufügen, virtuelle Maschine bereitstellen, Cloud-Service aktivieren. Nicht jede dieser Änderungen benötigt jedoch einen eigenen Change. Standard Changes Viele Service Requests werden über bereits genehmigte Standard Changes umgesetzt. Beispiele: Office installieren Gruppenmitgliedschaft vergeben Notebook bereitstellen Benutzerkonto anlegen Der Benutzer bemerkt davon häufig nichts. Für ihn bleibt es ein Service Request. Normale Changes Größere Anforderungen können zusätzlich einen normalen Change benötigen. Beispiel: Ein Fachbereich benötigt eine neue Unternehmenssoftware. Der Service Request startet den Prozess. Die technische Einführung erfolgt anschließend kontrolliert über Change Enablement. Service Request Management und Knowledge Management Knowledge Management unterstützt Service Requests in nahezu jeder Phase. Beispiele: Benutzer findet die Lösung selbst. Service Desk nutzt einen Knowledge-Artikel. Automatisierung greift auf Dokumentation zurück. Runbooks beschreiben die Bereitstellung. Je besser die Wissensbasis, desto schneller erfolgt die Bearbeitung. Knowledge vor Ticket Idealerweise prüft der Benutzer bereits vor der Ticketerstellung, ob ein passender Knowledge-Artikel existiert. Beispiele: VPN einrichten Outlook konfigurieren Drucker verbinden MFA aktivieren Dadurch werden viele Requests vollständig vermieden. Neue Knowledge-Artikel Auch Service Requests können neue Dokumentationen erzeugen. Beispiele: häufige Rückfragen neue Software neue Cloud-Dienste neue Standardhardware neuer Bereitstellungsprozess Wissen sollte kontinuierlich erweitert werden. Runbooks Viele Standard Requests besitzen ein Runbook. Ein Runbook beschreibt: Voraussetzungen, Reihenfolge, Prüfungen, Dokumentation, Abschluss. Dadurch arbeiten alle Bearbeiter nach demselben Verfahren. Service Request Management und Service Level Management Auch Service Requests besitzen häufig Serviceziele. Beispiele: Notebook innerhalb von fünf Arbeitstagen Benutzerkonto innerhalb von vier Stunden Passwort innerhalb von zehn Minuten Software innerhalb eines Arbeitstages Service Level Management überwacht, ob diese Ziele erreicht werden. Kennzahlen Typische Kennzahlen: Bearbeitungszeit Wartezeit auf Genehmigung Automatisierungsquote Anzahl offener Requests durchschnittliche Bereitstellungszeit Benutzerzufriedenheit Self-Service-Nutzung Wiedereröffnungen Diese Kennzahlen helfen bei Verbesserungen. Service Request Management und Information Security Management Viele Requests betreffen Sicherheitsaspekte. Beispiele: Administratorrechte VPN Multifaktor-Authentifizierung Cloud-Zugriffe Gruppenmitgliedschaften Datenbankberechtigungen Information Security Management definiert häufig die notwendigen Anforderungen. Least Privilege Service Requests sollten möglichst nach dem Prinzip der geringsten Berechtigung umgesetzt werden. Benutzer erhalten nur die Rechte, die sie tatsächlich benötigen. Dadurch sinkt das Sicherheitsrisiko. Rezertifizierung Manche Berechtigungen werden regelmäßig überprüft. Beispiele: Administratorrechte Projektzugriffe externe Benutzer Cloud-Rollen Nicht mehr benötigte Berechtigungen werden entfernt. Service Request Management und Service Configuration Management Viele Requests verändern Configuration Items. Beispiele: Notebook ausgeben Server bereitstellen virtuelle Maschine erzeugen Software installieren Zertifikat erneuern Nach der Bereitstellung sollten die entsprechenden Configuration-Daten aktualisiert werden. Warum Configuration-Daten wichtig sind Nur aktuelle Daten ermöglichen: korrekte Inventarisierung, Incident-Analyse, Problem Management, Change Enablement, Lizenzverwaltung, Sicherheitsprüfungen. Service Requests verändern häufig genau diese Informationen. Service Request Management und Supplier Management Externe Lieferanten können an der Bearbeitung beteiligt sein. Beispiele: Notebooklieferung Mobiltelefon Cloud-Service Softwarelizenz Hardwarewartung Lieferzeiten externer Partner beeinflussen häufig die gesamte Bearbeitungsdauer. Service Request Management und Continual Improvement Jeder Request liefert Verbesserungspotenzial. Beispiele: unnötige Genehmigungen, schlechte Formulare, fehlende Automatisierung, veraltete Knowledge-Artikel, lange Bearbeitungszeiten, wiederkehrende Rückfragen. Diese Erkenntnisse fließen in Continual Improvement ein. Verbesserungsmöglichkeiten Typische Maßnahmen: Formular vereinfachen Genehmigungen reduzieren Workflow automatisieren Knowledge erweitern Serviceportal verbessern Bearbeitungszeiten verkürzen Kommunikation verbessern Kleine Verbesserungen können große Wirkung entfalten. Zusammenspiel im Onboarding Ein Beispiel: Neuer Mitarbeiter │ ▼ Service Request │ ▼ Genehmigungen │ ▼ Benutzerkonto │ ▼ Microsoft 365 │ ▼ VPN │ ▼ Notebook │ ▼ CMDB aktualisieren │ ▼ Benutzer informieren Mehrere Practices arbeiten dabei gleichzeitig zusammen. Praxisbeispiel Ein neuer Mitarbeiter beginnt nächste Woche. Der Request löst automatisch aus: Benutzerkonto, E-Mail, Microsoft 365, Notebook, VPN, Gruppen, Teams, Mobiltelefon. Währenddessen: Knowledge liefert Installationsanleitungen. Configuration Management dokumentiert neue Geräte. Service Level Management misst die Bearbeitungszeit. Information Security prüft Berechtigungen. Continual Improvement sammelt Kennzahlen. Der Benutzer erlebt einen einzigen zusammenhängenden Service. Typische Fehler Fehler 1 Incidents und Requests werden verwechselt. Fehler 2 Service Requests aktualisieren keine Configuration-Daten. Fehler 3 Knowledge wird nicht genutzt. Fehler 4 Genehmigungen verzögern Standardleistungen. Fehler 5 Automatisierungen fehlen. Fehler 6 Serviceziele werden nicht gemessen. Fehler 7 Information Security wird zu spät eingebunden. Fehler 8 Bearbeitung erfolgt außerhalb des ITSM-Systems. Fehler 9 Self-Service wird kaum genutzt. Fehler 10 Verbesserungspotenziale werden nicht ausgewertet. Checkliste Zusammenspiel Request korrekt klassifiziert Incident ausgeschlossen Knowledge genutzt Genehmigungen durchgeführt Change erforderlich? Configuration-Daten aktualisiert Sicherheitsanforderungen erfüllt Serviceziel überwacht Benutzer informiert Verbesserungen dokumentiert Checkliste Automatisierung Workflow vorhanden Genehmigungen integriert Knowledge eingebunden Configuration aktualisiert Benutzer informiert Fehler protokolliert Monitoring vorhanden Dokumentation aktuell Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker arbeiten täglich an den Schnittstellen verschiedener ITIL Practices. Im Arbeitsalltag bedeutet dies: Service Requests technisch umsetzen, Incidents von Requests unterscheiden, Standard Changes anwenden, Configuration-Daten pflegen, Knowledge erweitern, Sicherheitsvorgaben einhalten, Automatisierungen entwickeln, Prozesse kontinuierlich verbessern. Erst das Zusammenspiel aller Practices ermöglicht einen professionellen und effizienten IT-Service. Zusammenfassung Benutzer stellt Service Request ↓ Knowledge und Self-Service unterstützen ↓ Genehmigungen prüfen ↓ Standard Change nutzen (falls erforderlich) ↓ Service bereitstellen ↓ Configuration aktualisieren ↓ Servicequalität messen ↓ Verbesserungen umsetzen Merksätze Service Request Management arbeitet niemals isoliert. Incidents beheben Störungen – Service Requests stellen Leistungen bereit. Knowledge und Automatisierung beschleunigen die Bearbeitung. Configuration-Daten müssen nach der Bereitstellung aktuell sein. Continual Improvement verbessert auch Service Requests kontinuierlich. Verwandte Seiten 9.1 Ziele und Grundlagen des Service Request Management 9.2 Request Model und Standard Requests 9.3 Genehmigungen und Freigabeverfahren 9.4 Erfüllung, Automatisierung und Self-Service Incident Management Change Enablement Knowledge Management Service Configuration Management Service Level Management Information Security Management Continual Improvement Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Request Management PeopleCert – ITIL Practice Guide: Incident Management PeopleCert – ITIL Practice Guide: Change Enablement PeopleCert – ITIL Practice Guide: Knowledge Management PeopleCert – ITIL Practice Guide: Service Configuration Management PeopleCert – ITIL Practice Guide: Service Level Management PeopleCert – ITIL Practice Guide: Information Security Management PeopleCert – ITIL Practice Guide: Continual Improvement ITIL Foundation – Version 5 Einordnung Die dargestellten Zusammenhänge, Beispiele und Praxisempfehlungen orientieren sich an den ITIL-Practices. Die konkrete technische Umsetzung hängt von den eingesetzten ITSM-Systemen, Automatisierungsplattformen, Identity-Management-Lösungen und organisatorischen Prozessen der jeweiligen Organisation ab. Behandelter Framework-Stand: ITIL Version 5 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance Fachlicher Stand: August 2026