9. Service Request Management 9.1 Ziele und Grundlagen des Service Request Management Kurz erklärt Service Request Management beschäftigt sich mit der strukturierten Bearbeitung von Service Requests. Ein Service Request ist keine Störung. Stattdessen handelt es sich um eine geplante, standardisierte und vom Benutzer angeforderte Serviceleistung. Ziel ist es, Anfragen schnell, nachvollziehbar, möglichst automatisiert und mit gleichbleibender Qualität bereitzustellen. Was ist Service Request Management? Service Request Management ist eine ITIL Practice zur Bearbeitung von standardisierten Benutzeranfragen. Dabei geht es nicht um die Behebung eines Fehlers, sondern um die Bereitstellung einer gewünschten Leistung. Typische Beispiele: neues Benutzerkonto Passwort zurücksetzen Software installieren VPN-Zugang beantragen Gruppenberechtigung anfordern Drucker bereitstellen Notebook bestellen Mobiltelefon austauschen Zugriff auf einen Fileserver beantragen neue virtuelle Maschine bereitstellen Alle diese Vorgänge können geplant und standardisiert abgewickelt werden. Was ist ein Service Request? Ein Service Request ist eine formelle Anfrage eines Benutzers oder einer autorisierten Person nach einer definierten Serviceleistung. Ein Service Request kann sich beispielsweise beziehen auf: Bereitstellung Änderung Zugriff Information Beratung Genehmigung Ersatz Standardleistung Wichtig: Ein Service Request ist keine Störung. Es funktioniert nichts falsch. Der Benutzer benötigt lediglich eine Leistung der IT. Ziele des Service Request Management Die wichtigsten Ziele sind: standardisierte Bearbeitung schnelle Bereitstellung hohe Servicequalität geringe Bearbeitungszeit klare Verantwortlichkeiten nachvollziehbare Dokumentation möglichst hohe Automatisierung Entlastung des Service Desk hohe Benutzerzufriedenheit Je standardisierter ein Request ist, desto einfacher kann er automatisiert werden. Warum Service Requests wichtig sind In vielen Unternehmen bestehen die meisten Tickets nicht aus Incidents. Stattdessen entstehen täglich zahlreiche Standardanfragen. Beispiele: neues Passwort zusätzlicher Monitor Softwarelizenz Berechtigung neues Smartphone VPN-Zugang Microsoft-365-Lizenz Druckerinstallation Würde jede Anfrage individuell bearbeitet, entstünde unnötiger Aufwand. Standardisierte Abläufe sorgen für: kürzere Bearbeitungszeiten, geringere Fehlerquote, bessere Planbarkeit, gleichbleibende Qualität. Incident oder Service Request? Diese beiden Begriffe werden häufig verwechselt. Incident Service Request ungeplante Störung geplante Anfrage Service funktioniert nicht wie erwartet Benutzer wünscht eine Leistung Ziel ist Wiederherstellung Ziel ist Bereitstellung häufig hoher Zeitdruck meist planbare Bearbeitung kann Major Incident werden wird normalerweise nicht eskaliert Beispiele für Incidents Outlook startet nicht VPN funktioniert nicht Server ausgefallen WLAN nicht erreichbar Drucker druckt nicht Anmeldung schlägt fehl Datenbank antwortet nicht Alle diese Fälle beschreiben eine Störung. Beispiele für Service Requests neues Notebook bestellen zweiter Monitor VPN-Zugang beantragen neue Software installieren Benutzerkonto anlegen Gruppenmitgliedschaft ändern Berechtigung erweitern neues Mobiltelefon Shared Mailbox erstellen Lizenz freischalten Hier funktioniert nichts falsch. Der Benutzer benötigt lediglich eine zusätzliche Leistung. Typische Kategorien von Service Requests Service Requests lassen sich beispielsweise einteilen in: Hardware Software Benutzerkonten Berechtigungen Netzwerk Telefonie Cloud-Dienste Mobile Geräte Drucker Informationen Beratung Standardänderungen Eine sinnvolle Kategorisierung erleichtert Automatisierung und Auswertung. Warum Standardisierung wichtig ist Je ähnlicher Requests bearbeitet werden, desto einfacher lassen sie sich: dokumentieren, automatisieren, messen, verbessern, delegieren. Standardisierung sorgt außerdem dafür, dass verschiedene Mitarbeiter zum gleichen Ergebnis gelangen. Service Request oder Change? Nicht jeder Service Request ist gleichzeitig ein Change. Beispiel: Ein Benutzer beantragt Microsoft Office. Die Installation erfolgt nach einem freigegebenen Standardverfahren. Für den Benutzer handelt es sich um einen Service Request. Im Hintergrund kann die Bereitstellung über einen bereits genehmigten Standard Change erfolgen. Service Request oder Incident? Ein Benutzer meldet: "Ich kann Outlook nicht öffnen." → Incident Ein Benutzer meldet: "Bitte installieren Sie Outlook auf meinem neuen Notebook." → Service Request Der Unterschied liegt nicht im Programm, sondern im Ziel der Anfrage. Wer darf Service Requests stellen? Je nach Organisation können Requests gestellt werden von: Mitarbeitern Führungskräften Administratoren externen Dienstleistern Fachbereichen Kunden automatisierten Systemen Häufig gelten dabei Berechtigungen. Nicht jeder Benutzer darf jede Leistung anfordern. Serviceportal als Einstieg Viele Unternehmen verwenden ein zentrales Serviceportal. Dort können Benutzer: Requests auswählen, Formulare ausfüllen, Genehmigungen verfolgen, Status einsehen, Knowledge-Artikel lesen, den Bearbeitungsstand prüfen. Dadurch sinkt die Anzahl telefonischer Anfragen erheblich. Self-Service und Service Requests Viele Requests eignen sich hervorragend für Self-Service. Beispiele: Passwort zurücksetzen Software auswählen Drucker installieren VPN beantragen Mobilgerät registrieren Dadurch können Benutzer viele Aufgaben selbst durchführen. Typischer Ablauf eines Service Requests Benutzer │ ▼ Request stellen │ ▼ Prüfung │ ▼ Genehmigung (falls notwendig) │ ▼ Bearbeitung │ ▼ Bereitstellung │ ▼ Benutzer informiert │ ▼ Request schließen Nicht jeder Request benötigt eine Genehmigung. Request oder Information? Auch reine Informationsanfragen können Service Requests sein. Beispiele: Wie richte ich VPN ein? Welche Software darf ich nutzen? Wo finde ich das Handbuch? Wie beantrage ich ein Notebook? Oft genügt hierbei bereits ein passender Knowledge-Artikel. Priorität bei Service Requests Service Requests besitzen ebenfalls Prioritäten. Diese unterscheiden sich jedoch häufig von Incident-Prioritäten. Beispiel: Ein neues Notebook kann durchaus wichtig sein, stellt aber normalerweise keinen Incident dar. Prioritäten orientieren sich häufig an: Dringlichkeit geschäftlicher Bedeutung Lieferzeit Termin Genehmigungen Servicequalität Auch für Service Requests können Ziele definiert werden. Beispiele: Bereitstellung innerhalb von drei Arbeitstagen Passwort innerhalb von zehn Minuten Notebook innerhalb von fünf Arbeitstagen Softwareinstallation innerhalb eines Arbeitstages Diese Ziele können Bestandteil eines SLA oder Servicekatalogs sein. Dokumentation Jeder Request sollte nachvollziehbar dokumentiert werden. Mindestens: Antragsteller Datum gewünschte Leistung Kategorie Priorität Bearbeiter Genehmigungen Bereitstellung Abschluss Eine gute Dokumentation erleichtert spätere Auswertungen. Automatisierung Viele Service Requests lassen sich vollständig automatisieren. Beispiele: Passwort zurücksetzen Benutzerkonto erstellen Gruppenmitgliedschaft ändern Software verteilen VM bereitstellen Lizenz aktivieren Automatisierung reduziert: Wartezeiten, Fehler, Bearbeitungskosten. Vorteile des Service Request Management Für Benutzer: schnelle Bearbeitung transparente Prozesse klare Zuständigkeiten nachvollziehbarer Status Für die IT: weniger manueller Aufwand bessere Planbarkeit standardisierte Abläufe bessere Messbarkeit einfachere Automatisierung Praxisbeispiel Ein Mitarbeiter beginnt nächste Woche im Unternehmen. Benötigt werden: Benutzerkonto E-Mail Notebook VPN Microsoft 365 Gruppenberechtigungen Anstatt sechs einzelne Tickets manuell zu bearbeiten, existiert ein standardisierter Onboarding-Request. Alle notwendigen Aufgaben werden automatisch angestoßen. Dadurch sinkt der Bearbeitungsaufwand erheblich. Typische Fehler Fehler 1 Incidents werden als Service Requests erfasst. Fehler 2 Service Requests werden unnötig individuell bearbeitet. Fehler 3 Es existieren keine Standardabläufe. Fehler 4 Genehmigungen fehlen oder erfolgen zu spät. Fehler 5 Benutzer kennen das Serviceportal nicht. Fehler 6 Statusinformationen fehlen. Fehler 7 Standardleistungen werden nicht automatisiert. Fehler 8 Dokumentation ist unvollständig. Checkliste Service Request Request korrekt kategorisiert gewünschte Leistung eindeutig beschrieben Antragsteller berechtigt Genehmigung geprüft Standardverfahren vorhanden Bearbeitung dokumentiert Benutzer informiert Request abgeschlossen Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker bearbeiten im Arbeitsalltag häufig mehr Service Requests als Incidents. Typische Aufgaben sind: Benutzerkonten anlegen, Berechtigungen vergeben, Software installieren, Hardware bereitstellen, Standardänderungen durchführen, Benutzer unterstützen, Requests dokumentieren, Automatisierungen entwickeln. Je besser Service Requests standardisiert sind, desto mehr Zeit bleibt für komplexe technische Aufgaben. Zusammenfassung Benutzer benötigt eine definierte Leistung ↓ Service Request erfassen ↓ Kategorie bestimmen ↓ Genehmigung prüfen ↓ Standardverfahren anwenden ↓ Leistung bereitstellen ↓ Benutzer informieren ↓ Request dokumentieren und schließen Merksätze Ein Service Request ist keine Störung. Service Requests beschreiben standardisierte Leistungen. Standardisierung ist die Grundlage für Automatisierung. Gute Serviceportale entlasten den Service Desk. Service Request Management erhöht Servicequalität und Benutzerzufriedenheit. Verwandte Seiten 9.2 Request Model und Standard Requests 9.3 Genehmigungen und Freigabeverfahren 9.4 Erfüllung, Automatisierung und Self-Service 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management Incident Management Knowledge Management Service Level Management Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Request Management ITIL Foundation – Version 5 Einordnung Die dargestellten Beispiele, Kategorien, Abläufe und Empfehlungen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine einheitlichen Request-Kategorien oder Genehmigungsabläufe vor. Die konkrete Umsetzung richtet sich nach den angebotenen Services, der Organisationsstruktur und den Geschäftsanforderungen. Behandelter Framework-Stand: ITIL Version 5 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance Fachlicher Stand: August 2026 9.2 Request Model und Standard Requests Kurz erklärt Wiederkehrende Service Requests sollten nicht jedes Mal neu geplant werden. Stattdessen werden sie mithilfe von Request Models standardisiert. Ein Request Model beschreibt den vollständigen Ablauf eines bestimmten Service Requests – von der Anforderung über Genehmigungen bis zur Bereitstellung und Dokumentation. Dadurch werden Bearbeitungszeiten verkürzt, Fehler reduziert und Automatisierungen ermöglicht. Was ist ein Request Model? Ein Request Model ist eine dokumentierte Vorlage für einen wiederkehrenden Service Request. Es beschreibt: den genauen Ablauf, erforderliche Informationen, Genehmigungen, Bearbeitungsschritte, beteiligte Teams, Kommunikation, Abschlusskriterien. Jeder gleichartige Request wird möglichst nach demselben Modell bearbeitet. Ziele eines Request Models Ein Request Model soll: Bearbeitung standardisieren, Qualität erhöhen, Bearbeitungszeit verkürzen, Fehler vermeiden, Verantwortlichkeiten festlegen, Genehmigungen eindeutig regeln, Automatisierung ermöglichen, Dokumentation vereinfachen, Servicequalität verbessern. Warum Request Models wichtig sind Ohne festgelegte Abläufe entscheidet jeder Bearbeiter unterschiedlich. Dadurch entstehen häufig: unterschiedliche Bearbeitungszeiten, unterschiedliche Ergebnisse, fehlende Informationen, unnötige Rückfragen, doppelte Arbeiten, fehlende Genehmigungen. Ein Request Model sorgt dafür, dass alle Beteiligten nach denselben Regeln arbeiten. Bestandteile eines Request Models Ein vollständiges Request Model enthält typischerweise: Name des Requests, Beschreibung, Kategorie, Zielgruppe, Voraussetzungen, erforderliche Angaben, Genehmigungen, Bearbeitungsschritte, beteiligte Teams, Automatisierungen, Kommunikation, Abschlusskriterien, Dokumentation. Je komplexer ein Request ist, desto ausführlicher sollte das Modell sein. Beispiel: Softwareinstallation Ein mögliches Request Model: Software beantragen │ ▼ Lizenz prüfen │ ▼ Genehmigung Vorgesetzter │ ▼ Software automatisch verteilen │ ▼ Installation prüfen │ ▼ Benutzer informieren │ ▼ Request schließen Der Ablauf bleibt für alle gleich. Was sind Standard Requests? Ein Standard Request ist ein häufig wiederkehrender Service Request mit einem definierten Ablauf. Typische Beispiele: Passwort zurücksetzen Benutzerkonto anlegen Monitor bestellen VPN-Zugang beantragen Software installieren Gruppenmitgliedschaft ändern Drucker bereitstellen E-Mail-Postfach erweitern Mobiltelefon bestellen Shared Mailbox erstellen Für Standard Requests existiert normalerweise bereits ein Request Model. Eigenschaften eines Standard Requests Ein Standard Request ist: wiederkehrend, dokumentiert, planbar, risikoarm, standardisiert, nachvollziehbar, häufig automatisierbar. Dadurch kann die Bearbeitung weitgehend unabhängig vom Bearbeiter erfolgen. Nicht jeder Request ist ein Standard Request Einige Anforderungen sind individuell. Beispiele: Einführung einer neuen Fachanwendung komplexe Netzwerkanpassung außergewöhnliche Hardwarebeschaffung individuelle Spezialsoftware neue Cloud-Architektur Solche Anforderungen benötigen häufig eine individuelle Planung. Request Models und Servicekatalog Ein Servicekatalog beschreibt, welche Leistungen angeboten werden. Ein Request Model beschreibt, wie eine bestimmte Leistung erbracht wird. Beispiel: Servicekatalog: Microsoft 365 Request Model: Microsoft-365-Lizenz für neuen Mitarbeiter bereitstellen. Informationen des Benutzers Ein gutes Request Model legt fest, welche Informationen der Benutzer angeben muss. Beispiele: Name Abteilung Kostenstelle Standort gewünschte Software Gerät gewünschter Termin Begründung Ansprechpartner Fehlende Informationen führen häufig zu Verzögerungen. Pflicht- und optionale Angaben Nicht alle Informationen sind immer erforderlich. Beispiel: Pflichtfelder: Benutzer Software Gerät Optionale Angaben: gewünschter Installationstermin Bemerkungen Projektname Dadurch bleiben Formulare übersichtlich. Genehmigungen im Request Model Viele Standard Requests benötigen Genehmigungen. Beispiele: Vorgesetzter Kostenstellenverantwortlicher Informationssicherheit Softwareverantwortlicher Lizenzmanager Datenschutz Das Request Model definiert eindeutig, wann welche Genehmigung erforderlich ist. Genehmigungsfreie Requests Nicht jeder Request benötigt eine Freigabe. Beispiele: Passwort zurücksetzen Knowledge-Artikel aufrufen Druckertreiber herunterladen Standardsoftware installieren (wenn bereits genehmigt) FAQ nutzen Dadurch sinkt der Bearbeitungsaufwand erheblich. Bearbeitungsschritte definieren Ein Request Model beschreibt jeden Bearbeitungsschritt. Beispiel: Request prüfen Genehmigung einholen Lizenz reservieren Software verteilen Installation kontrollieren Benutzer informieren Dokumentation aktualisieren Request schließen Jeder Bearbeiter kennt dadurch den vollständigen Ablauf. Verantwortlichkeiten Für jeden Schritt sollte klar sein, wer verantwortlich ist. Beispiele: Aufgabe Verantwortlich Request prüfen Service Desk Genehmigung Vorgesetzter Lizenzverwaltung Lizenzmanagement Softwareverteilung Client Management Abschluss Service Desk Dadurch entstehen keine unklaren Zuständigkeiten. Automatisierung Viele Schritte können automatisiert werden. Beispiele: Formular prüfen Genehmigung versenden Benutzerkonto erstellen Gruppenmitgliedschaft vergeben Software installieren E-Mail versenden Ticket schließen Dokumentation ergänzen Automatisierung reduziert manuelle Tätigkeiten erheblich. Kommunikation Auch die Kommunikation sollte standardisiert werden. Beispiele: Eingangsbestätigung Genehmigung angefordert Bearbeitung begonnen Bereitstellung abgeschlossen zusätzliche Informationen benötigt Request erfolgreich abgeschlossen Benutzer kennen dadurch jederzeit den aktuellen Stand. Bearbeitungszeiten Für Standard Requests können Zielzeiten definiert werden. Beispiele: Request Zielzeit Passwort zurücksetzen 15 Minuten Softwareinstallation 1 Arbeitstag Benutzerkonto 4 Stunden Monitor bestellen 3 Arbeitstage VPN-Zugang 1 Arbeitstag Diese Zeiten dienen als Orientierung für Servicequalität und Planung. Request Models regelmäßig überprüfen Ein Request Model sollte regelmäßig überprüft werden. Mögliche Fragen: Sind die Bearbeitungsschritte noch aktuell? Stimmen die Genehmigungen? Gibt es neue Automatisierungen? Haben sich Systeme geändert? Gibt es häufige Rückfragen? Entstehen unnötige Wartezeiten? Ein veraltetes Request Model führt schnell zu Fehlern. Versionierung Änderungen an Request Models sollten nachvollziehbar sein. Dokumentiert werden können: Versionsnummer Änderungsdatum Bearbeiter Grund der Änderung betroffene Schritte Dadurch bleibt nachvollziehbar, welcher Ablauf aktuell gültig ist. Praxisbeispiel Ein neuer Mitarbeiter beginnt am Montag. Der Service Request: "Neuer Mitarbeiter" startet automatisch: Benutzerkonto E-Mail Microsoft 365 VPN Gruppenmitgliedschaften Notebook Monitor Mobiltelefon Berechtigungen Jede Aufgabe wird automatisch an das zuständige Team weitergeleitet. Der gesamte Ablauf basiert auf einem einzigen Request Model. Typische Fehler Fehler 1 Für häufige Requests existiert kein Request Model. Fehler 2 Bearbeiter arbeiten nach unterschiedlichen Abläufen. Fehler 3 Genehmigungen sind nicht eindeutig geregelt. Fehler 4 Zu viele unnötige Pflichtfelder. Fehler 5 Bearbeitungsschritte sind unvollständig dokumentiert. Fehler 6 Automatisierungen werden nicht genutzt. Fehler 7 Verantwortlichkeiten sind unklar. Fehler 8 Veraltete Request Models werden weiterhin verwendet. Checkliste Request Model Request eindeutig beschrieben Kategorie festgelegt Zielgruppe definiert Voraussetzungen beschrieben Pflichtinformationen festgelegt Genehmigungen geregelt Bearbeitungsschritte dokumentiert Verantwortlichkeiten festgelegt Automatisierungen berücksichtigt Kommunikation definiert Abschlusskriterien beschrieben Version dokumentiert Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker arbeiten täglich mit Request Models. Typische Aufgaben: Standardsoftware bereitstellen, Benutzerkonten anlegen, Berechtigungen vergeben, Hardware vorbereiten, Automatisierungen entwickeln, Dokumentationen pflegen, Request Models verbessern, Bearbeitungszeiten optimieren. Gut gepflegte Request Models sparen im Arbeitsalltag erhebliche Zeit und sorgen für eine gleichbleibend hohe Servicequalität. Zusammenfassung Wiederkehrenden Request identifizieren ↓ Request Model erstellen ↓ Informationen und Genehmigungen festlegen ↓ Bearbeitung standardisieren ↓ Automatisierung nutzen ↓ Leistung bereitstellen ↓ Benutzer informieren ↓ Request dokumentieren und abschließen Merksätze Standard Requests sollten immer nach einem Request Model bearbeitet werden. Ein Request Model beschreibt den gesamten Bearbeitungsablauf. Standardisierung ermöglicht Automatisierung. Gute Request Models reduzieren Fehler und Bearbeitungszeit. Klare Verantwortlichkeiten verbessern die Servicequalität. Verwandte Seiten 9.1 Ziele und Grundlagen des Service Request Management 9.3 Genehmigungen und Freigabeverfahren 9.4 Erfüllung, Automatisierung und Self-Service 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management Service Level Management Knowledge Management Continual Improvement Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Request Management ITIL Foundation – Version 5 Einordnung Die dargestellten Request Models, Bearbeitungsschritte, Zielzeiten und Beispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine festen Request Models oder Standardabläufe vor. Organisationen entwickeln diese entsprechend ihrer Services, Sicherheitsanforderungen und Geschäftsprozesse. Behandelter Framework-Stand: ITIL Version 5 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance Fachlicher Stand: August 2026 9.3 Genehmigungen und Freigabeverfahren Kurz erklärt Nicht jeder Service Request darf sofort ausgeführt werden. Viele Leistungen verursachen Kosten, verändern Berechtigungen oder beeinflussen Sicherheit und Compliance. Deshalb benötigen bestimmte Requests vor der Bearbeitung eine oder mehrere Genehmigungen. Ziel ist es, Risiken zu reduzieren, Verantwortlichkeiten eindeutig festzulegen und gleichzeitig unnötige Wartezeiten zu vermeiden. Warum Genehmigungen notwendig sind Genehmigungen stellen sicher, dass eine angeforderte Leistung berechtigt, sinnvoll und zulässig ist. Sie helfen dabei: unberechtigte Zugriffe zu verhindern, Kosten zu kontrollieren, Sicherheitsrichtlinien einzuhalten, gesetzliche Vorgaben umzusetzen, Verantwortlichkeiten nachzuweisen, Änderungen nachvollziehbar zu dokumentieren. Eine Genehmigung bedeutet dabei nicht automatisch eine lange Bearbeitungszeit. Gut definierte Standardprozesse können Genehmigungen weitgehend automatisieren. Was ist eine Genehmigung? Eine Genehmigung ist die formelle Zustimmung einer berechtigten Person oder Stelle zur Durchführung eines Service Requests. Die Genehmigung bestätigt beispielsweise: der Benutzer darf die Leistung erhalten, Budget steht zur Verfügung, Sicherheitsanforderungen sind erfüllt, Unternehmensrichtlinien werden eingehalten, Risiken sind akzeptiert. Erst danach beginnt – sofern erforderlich – die eigentliche Bearbeitung. Nicht jeder Request benötigt eine Genehmigung Viele Standardleistungen können ohne zusätzliche Freigabe bereitgestellt werden. Beispiele: Passwort zurücksetzen Entsperren eines Benutzerkontos Abrufen eines Knowledge-Artikels Installation bereits freigegebener Standardsoftware Download eines Druckertreibers Hier würde eine zusätzliche Genehmigung lediglich den Prozess unnötig verzögern. Wann Genehmigungen sinnvoll sind Eine Genehmigung ist häufig erforderlich bei: neuer Software kostenpflichtigen Lizenzen zusätzlicher Hardware erweiterten Berechtigungen Administratorrechten VPN-Zugängen Cloud-Ressourcen neuen Benutzerkonten Zugriff auf sensible Daten Änderungen an sicherheitskritischen Systemen Je höher Risiko oder Kosten, desto wichtiger wird eine Freigabe. Typische Genehmigungsstellen Je nach Organisation können unterschiedliche Stellen beteiligt sein. Beispiele: Anfrage Genehmigung Notebook Vorgesetzter Softwarelizenz Lizenzmanagement Administratorrechte Informationssicherheit SAP-Berechtigung Fachbereich Cloud-Ressourcen Kostenstellenverantwortlicher VPN-Zugang Vorgesetzter oder IT-Sicherheit Mobiltelefon Einkauf oder Kostenstelle Die zuständige Stelle sollte im Request Model eindeutig definiert sein. Einfacher Genehmigungsprozess Ein typischer Ablauf: Benutzer stellt Request │ ▼ Genehmigung erforderlich? │ ┌────┴────┐ │ │ Nein Ja │ │ ▼ ▼ Bearbeitung Genehmigung │ │ └────┬────┘ ▼ Bereitstellung │ ▼ Request schließen Nicht jeder Request durchläuft denselben Ablauf. Mehrstufige Genehmigungen Komplexere Requests können mehrere Freigaben benötigen. Beispiel: Ein Administratorzugang wird beantragt. Mögliche Reihenfolge: Vorgesetzter Informationssicherheit Systemverantwortlicher Erst nach allen Genehmigungen beginnt die technische Umsetzung. Parallele Genehmigungen Nicht alle Freigaben müssen nacheinander erfolgen. Sind Genehmigungen unabhängig voneinander, können sie parallel eingeholt werden. Vorteile: kürzere Bearbeitungszeit, weniger Wartezeiten, bessere Planbarkeit. Dies wird von vielen ITSM-Systemen unterstützt. Genehmigungsregeln Ein Request Model sollte eindeutig festlegen: Wer genehmigt? Wann wird genehmigt? Welche Kriterien gelten? Wann entfällt eine Genehmigung? Was passiert bei einer Ablehnung? Gibt es Vertretungsregelungen? Welche Fristen gelten? Klare Regeln vermeiden Rückfragen und Verzögerungen. Genehmigung ist keine technische Prüfung Die Genehmigung beantwortet in erster Linie organisatorische Fragen. Beispiele: Ist die Software notwendig? Ist Budget vorhanden? Darf der Benutzer den Zugriff erhalten? Ist die Anfrage nachvollziehbar? Die technische Umsetzung erfolgt anschließend durch die zuständigen IT-Teams. Ablehnung eines Requests Nicht jeder Request wird genehmigt. Mögliche Gründe: fehlendes Budget, unzureichende Begründung, Sicherheitsrisiko, fehlende Berechtigung, Lizenz nicht verfügbar, Richtlinie verbietet die Leistung, falscher Antrag. Eine Ablehnung sollte dokumentiert und nachvollziehbar begründet werden. Vertretungsregelungen Genehmigungen dürfen nicht von einzelnen Personen abhängig sein. Deshalb sollten Vertretungen definiert werden. Beispiele: Abwesenheit wegen Urlaub, Krankheit, Dienstreise, organisatorische Änderungen. Fehlende Vertretungen führen häufig zu langen Bearbeitungszeiten. Fristen für Genehmigungen Viele Organisationen definieren Zielzeiten. Beispiele: Genehmigung Zielzeit Vorgesetzter 1 Arbeitstag Lizenzmanagement 4 Stunden Informationssicherheit 2 Arbeitstage Einkauf 3 Arbeitstage Werden Fristen überschritten, kann eine Erinnerung oder Eskalation erfolgen. Automatische Genehmigungen Einige Requests können automatisch genehmigt werden. Beispiele: Standardsoftware innerhalb einer Abteilung zweiter Monitor nach Unternehmensrichtlinie Passwort zurücksetzen Druckertreiber installieren Voraussetzung ist, dass alle Regeln bereits definiert wurden. Bedingte Genehmigungen Manche Genehmigungen hängen von Bedingungen ab. Beispiele: Hardwarewert über 1.000 Euro Administratorrechte länger als 24 Stunden Zugriff auf personenbezogene Daten Software außerhalb des Standardportfolios Sind die Bedingungen nicht erfüllt, entfällt die zusätzliche Freigabe. Genehmigungen dokumentieren Jede Genehmigung sollte nachvollziehbar gespeichert werden. Typische Informationen: Genehmiger Datum Entscheidung Bemerkung Version des Requests eventuelle Auflagen Dadurch bleibt später nachvollziehbar, warum eine Leistung bereitgestellt wurde. Genehmigungen und Compliance Viele gesetzliche oder interne Vorgaben verlangen dokumentierte Genehmigungen. Beispiele: ISO/IEC 27001 Datenschutz Informationssicherheitsrichtlinien interne Compliance-Vorgaben Lizenzmanagement Finanzvorgaben Eine fehlende Dokumentation kann später zu Problemen bei Audits führen. Genehmigungen und Least Privilege Das Prinzip der minimalen Berechtigung spielt eine wichtige Rolle. Benutzer sollen nur die Rechte erhalten, die sie tatsächlich benötigen. Deshalb benötigen insbesondere folgende Requests häufig zusätzliche Genehmigungen: Administratorrechte Datenbankzugriffe Domänenadministration Firewall-Änderungen Cloud-Administrationsrechte Zugriff auf personenbezogene Daten Temporäre Berechtigungen Nicht jede Berechtigung muss dauerhaft vergeben werden. Beispiele: Administratorrechte für einen Tag Projektzugriff für vier Wochen Testumgebung bis Projektende externer Zugriff bis Wartungsende Nach Ablauf sollte die Berechtigung automatisch entzogen werden. Genehmigungen regelmäßig überprüfen Genehmigungsprozesse sollten regelmäßig bewertet werden. Fragen dabei: Gibt es unnötige Freigaben? Entstehen lange Wartezeiten? Werden Genehmigungen häufig abgelehnt? Können Schritte automatisiert werden? Stimmen Verantwortlichkeiten noch? Haben sich Richtlinien geändert? Ein effizienter Prozess schützt die Organisation, ohne die Benutzer unnötig auszubremsen. Praxisbeispiel Ein Entwickler benötigt Administratorrechte auf seinem Notebook. Der Ablauf: Entwickler stellt Request. Vorgesetzter bestätigt die Notwendigkeit. Informationssicherheit prüft das Risiko. IT vergibt die Berechtigung. Die Rechte gelten nur für zwei Wochen. Nach Ablauf werden sie automatisch entfernt. So bleiben Sicherheit und Nachvollziehbarkeit gewährleistet. Typische Fehler Fehler 1 Jeder Request benötigt dieselben Genehmigungen. Fehler 2 Genehmigungen sind nicht dokumentiert. Fehler 3 Vertretungen fehlen. Fehler 4 Genehmigungen verzögern Standardleistungen unnötig. Fehler 5 Ablehnungen werden nicht begründet. Fehler 6 Administratorrechte werden dauerhaft vergeben. Fehler 7 Genehmigungsregeln sind unklar. Fehler 8 Abgelaufene Berechtigungen werden nicht entfernt. Fehler 9 Genehmigungen erfolgen außerhalb des ITSM-Systems und sind später nicht nachvollziehbar. Fehler 10 Genehmigungsprozesse werden nie überprüft oder verbessert. Checkliste Genehmigungen Genehmigung erforderlich? Genehmiger eindeutig definiert Antrag vollständig Voraussetzungen erfüllt Fristen berücksichtigt Vertretung vorhanden Entscheidung dokumentiert Benutzer informiert Bereitstellung durchgeführt Request abgeschlossen Checkliste Berechtigungs-Requests Benutzer eindeutig identifiziert Berechtigung notwendig Least-Privilege-Prinzip eingehalten Genehmigung dokumentiert Ablaufdatum definiert (falls erforderlich) Protokollierung aktiviert regelmäßige Überprüfung geplant Entzug nach Ablauf vorgesehen Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker setzen viele genehmigte Service Requests technisch um. Typische Aufgaben: Benutzerkonten erstellen, Gruppenberechtigungen vergeben, Administratorrechte einrichten, Software bereitstellen, Hardware ausgeben, Dokumentationen pflegen, Genehmigungen prüfen, zeitlich begrenzte Berechtigungen verwalten. Dabei müssen technische Umsetzung und dokumentierte Genehmigung immer zusammenpassen. Zusammenfassung Benutzer stellt Request ↓ Genehmigung erforderlich? ↓ Genehmiger prüfen Anfrage ↓ Freigabe oder Ablehnung ↓ Bereitstellung der Leistung ↓ Dokumentation ↓ Benutzer informieren ↓ Request abschließen Merksätze Nicht jeder Service Request benötigt eine Genehmigung. Genehmigungen schützen Sicherheit, Budget und Compliance. Standardleistungen sollten möglichst automatisiert freigegeben werden. Administratorrechte sollten zeitlich begrenzt vergeben werden. Genehmigungen müssen nachvollziehbar dokumentiert sein. Verwandte Seiten 9.1 Ziele und Grundlagen des Service Request Management 9.2 Request Model und Standard Requests 9.4 Erfüllung, Automatisierung und Self-Service 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management Information Security Management Service Level Management Knowledge Management Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Request Management PeopleCert – ITIL Practice Guide: Information Security Management ITIL Foundation – Version 5 Einordnung Die dargestellten Genehmigungsprozesse, Beispiele und Rollen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine festen Genehmigungsstufen oder Freigabeworkflows vor. Organisationen definieren diese anhand ihrer Sicherheitsrichtlinien, Compliance-Anforderungen und Geschäftsprozesse. Behandelter Framework-Stand: ITIL Version 5 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance Fachlicher Stand: August 2026 9.4 Erfüllung, Automatisierung und Self-Service Kurz erklärt Ein zentrales Ziel des Service Request Management ist es, Service Requests möglichst schnell, zuverlässig und mit gleichbleibender Qualität zu erfüllen. Dies wird durch standardisierte Abläufe, Self-Service-Portale und Automatisierungen erreicht. Je weniger manuelle Tätigkeiten notwendig sind, desto schneller erhalten Benutzer die gewünschte Leistung und desto mehr Zeit bleibt der IT für komplexe Aufgaben. Was bedeutet Request Fulfilment? Request Fulfilment beschreibt die eigentliche Bearbeitung und Bereitstellung einer angeforderten Serviceleistung. Nachdem alle notwendigen Informationen vorliegen und erforderliche Genehmigungen erfolgt sind, beginnt die Umsetzung. Typische Tätigkeiten sind: Benutzerkonto erstellen, Software installieren, Berechtigungen vergeben, Hardware bereitstellen, Lizenz aktivieren, virtuelle Maschine erstellen, Cloud-Service bereitstellen, Drucker einrichten, VPN-Zugang konfigurieren. Ziel ist eine schnelle und fehlerfreie Bereitstellung. Ziele der Request-Erfüllung Eine gute Request-Erfüllung soll: schnell erfolgen, reproduzierbar sein, möglichst fehlerfrei ablaufen, dokumentiert werden, Benutzer informieren, Standards einhalten, Automatisierung nutzen, Ressourcen effizient einsetzen. Die eigentliche Bearbeitung sollte möglichst keine improvisierten Einzelschritte enthalten. Standardisierte Abläufe Standardisierte Prozesse sorgen dafür, dass identische Requests immer gleich bearbeitet werden. Beispiele: gleiches Installationsverfahren, identische Benutzerkonten, einheitliche Gruppenstrukturen, definierte Softwarepakete, standardisierte Hardware. Dadurch sinken: Fehler, Rückfragen, Bearbeitungszeit, Einarbeitungsaufwand. Automatisierung im Service Request Management Viele wiederkehrende Aufgaben eignen sich hervorragend zur Automatisierung. Beispiele: Benutzerkonto anlegen Passwort zurücksetzen Gruppenmitgliedschaften vergeben Lizenz aktivieren Software verteilen E-Mail-Postfach erstellen Drucker verbinden Cloud-Ressourcen bereitstellen virtuelle Maschinen erzeugen Zertifikate anfordern Automatisierungen werden häufig über ITSM-Systeme, Identity-Management-Lösungen oder Workflow-Plattformen umgesetzt. Vorteile der Automatisierung Automatisierung bietet zahlreiche Vorteile: schnellere Bearbeitung, geringere Fehlerquote, gleichbleibende Qualität, geringere Kosten, höhere Skalierbarkeit, bessere Nachvollziehbarkeit, Entlastung des Service Desk, kürzere Wartezeiten für Benutzer. Automatisierung ersetzt dabei nicht die Verantwortung für den Prozess. Grenzen der Automatisierung Nicht jeder Request kann vollständig automatisiert werden. Beispiele: individuelle Fachsoftware, komplexe Netzwerkänderungen, Sonderhardware, außergewöhnliche Berechtigungen, Projekte, sicherheitskritische Entscheidungen. Hier bleibt eine manuelle Prüfung erforderlich. Self-Service Beim Self-Service führt der Benutzer bestimmte Aufgaben selbst durch. Die IT stellt dafür geeignete Werkzeuge bereit. Beispiele: Passwort zurücksetzen, Software auswählen, VPN beantragen, Hardware bestellen, Knowledge-Artikel nutzen, Status eines Requests verfolgen, Standardsoftware installieren. Dadurch werden Service Desk und Fachabteilungen entlastet. Self-Service ist mehr als ein Formular Ein modernes Self-Service-Portal bietet häufig: Servicekatalog, Suchfunktion, Knowledge Base, Bestellportal, Genehmigungsstatus, Request-Historie, FAQ, Downloads, Chatbot, Statusseite. Der Benutzer soll möglichst viele Aufgaben selbst erledigen können. Der Servicekatalog Der Servicekatalog bildet die Grundlage vieler Self-Service-Portale. Er beschreibt: angebotene Leistungen, Voraussetzungen, Bearbeitungszeiten, Kosten (falls vorhanden), Zielgruppen, Genehmigungen, Ansprechpartner. Benutzer sollen ohne technisches Detailwissen erkennen können, welche Leistung sie benötigen. Benutzerfreundliche Formulare Ein gutes Formular ist: verständlich, kurz, logisch aufgebaut, mobil nutzbar, barrierefrei, fehlervermeidend. Nur notwendige Informationen sollten abgefragt werden. Zu viele Pflichtfelder führen häufig zu Abbrüchen. Dynamische Formulare Viele ITSM-Systeme unterstützen dynamische Formulare. Beispiel: Wählt der Benutzer: "Notebook" erscheinen automatisch weitere Felder: Modell, Dockingstation, Monitor, Tasche. Wählt der Benutzer: "Software" erscheinen stattdessen: Produkt, Version, Lizenz, Betriebssystem. Dadurch bleiben Formulare übersichtlich. Workflow-Automatisierung Ein Workflow steuert den gesamten Ablauf eines Requests. Beispiel: Request │ ▼ Genehmigung │ ▼ Benutzerkonto │ ▼ Gruppenmitgliedschaft │ ▼ Softwareinstallation │ ▼ Benutzer informieren │ ▼ Request schließen Jeder Schritt wird automatisch an die nächste zuständige Stelle übergeben. Automatische Benachrichtigungen Während der Bearbeitung können automatisch Nachrichten versendet werden. Beispiele: Request eingegangen, Genehmigung erforderlich, Genehmigung erfolgt, Bearbeitung begonnen, Rückfrage, Bereitstellung abgeschlossen, Request geschlossen. Dadurch muss der Benutzer nicht ständig nachfragen. Identity Management Viele Benutzer-Requests betreffen Identitäten und Berechtigungen. Identity-Management-Systeme können beispielsweise: Benutzerkonten erstellen, Gruppen verwalten, Rollen vergeben, Berechtigungen entziehen, Kennwörter zurücksetzen, Konten deaktivieren. Dadurch lassen sich viele Standard-Requests vollständig automatisieren. Zero-Touch Provisioning Bei standardisierten Arbeitsplätzen kann die Bereitstellung nahezu vollständig automatisiert erfolgen. Beispiel: Ein neuer Mitarbeiter wird im HR-System angelegt. Automatisch entstehen: Benutzerkonto, E-Mail-Adresse, Microsoft-365-Lizenz, Gruppenmitgliedschaften, VPN-Zugang, Multifaktor-Authentifizierung, Notebook-Konfiguration. Die IT muss nur noch kontrollieren oder ausliefern. Automatisierung mit Workflows Workflow-Systeme können verschiedene Werkzeuge miteinander verbinden. Beispiele: ITSM-System, Active Directory, Microsoft Entra ID, Microsoft 365, VMware, Hyper-V, Cloud-Plattform, Lizenzverwaltung, E-Mail-System, Inventarisierung. Ein einziger Request kann dadurch zahlreiche Systeme automatisch steuern. Fehlerbehandlung Auch automatisierte Prozesse benötigen Fehlerbehandlung. Mögliche Situationen: Lizenz nicht verfügbar, Genehmigung fehlt, Benutzer existiert bereits, Active Directory nicht erreichbar, Netzwerkproblem, Cloud-Dienst gestört. In solchen Fällen sollte der Workflow kontrolliert anhalten und den zuständigen Bearbeiter informieren. Rollback Automatisierungen sollten möglichst rückgängig gemacht werden können. Beispiele: Benutzerkonto entfernen, Gruppenmitgliedschaften löschen, Software deinstallieren, Lizenz freigeben, VM löschen. Dadurch lassen sich Fehler einfacher korrigieren. Protokollierung Jede automatische Bearbeitung sollte nachvollziehbar sein. Typische Informationen: Zeitpunkt, gestarteter Workflow, beteiligte Systeme, Bearbeitungsschritte, Fehler, Abschluss, Verantwortlicher, Versionsstand. Eine vollständige Protokollierung erleichtert Fehleranalyse und Audits. Überwachung automatisierter Prozesse Automatisierungen müssen überwacht werden. Beispiele: Workflow erfolgreich abgeschlossen? Genehmigung erhalten? Software installiert? Lizenz vergeben? Benutzer informiert? Fehlermeldung aufgetreten? Nicht erkannte Fehler können dazu führen, dass Requests unvollständig bearbeitet werden. Self-Service und Knowledge Base Viele Requests lassen sich bereits durch passende Informationen lösen. Beispiele: VPN einrichten, Drucker verbinden, Outlook konfigurieren, MFA aktivieren, WLAN nutzen. Findet der Benutzer die Lösung selbst, muss kein Ticket erstellt werden. Chatbots und virtuelle Assistenten Viele Serviceportale integrieren Chatbots. Sie können: Fragen beantworten, passende Knowledge-Artikel finden, Requests aufnehmen, Formulare starten, Bearbeitungsstatus anzeigen. Komplexe Anfragen werden bei Bedarf an den Service Desk weitergeleitet. Messung der Servicequalität Auch Self-Service und Automatisierung sollten gemessen werden. Beispiele: Bearbeitungszeit, Automatisierungsquote, Self-Service-Nutzung, Anzahl manueller Eingriffe, Fehlerquote, Benutzerzufriedenheit, Erfolgsquote der Workflows, Anzahl abgebrochener Formulare. Diese Kennzahlen helfen, den Service kontinuierlich zu verbessern. Praxisbeispiel Ein neuer Mitarbeiter wird eingestellt. Der Vorgesetzte startet im Self-Service-Portal den Request: Neuer Mitarbeiter Automatisch werden: Genehmigung geprüft, Benutzerkonto erstellt, Microsoft-365-Lizenz vergeben, VPN eingerichtet, Gruppenmitgliedschaften gesetzt, Notebook vorbereitet, E-Mail versendet. Der Service Desk muss den Ablauf lediglich überwachen. Typische Fehler Fehler 1 Standard-Requests werden weiterhin vollständig manuell bearbeitet. Fehler 2 Self-Service-Portale sind unübersichtlich. Fehler 3 Automatisierungen besitzen keine Fehlerbehandlung. Fehler 4 Genehmigungen werden nicht automatisch berücksichtigt. Fehler 5 Benutzer erhalten keine Statusinformationen. Fehler 6 Workflows werden nicht überwacht. Fehler 7 Rollback-Möglichkeiten fehlen. Fehler 8 Knowledge-Artikel sind veraltet. Fehler 9 Zu viele unnötige Formularfelder erschweren die Nutzung. Fehler 10 Automatisierungen werden nach Änderungen nicht getestet. Checkliste Self-Service Servicekatalog vorhanden Formulare verständlich Knowledge Base integriert Status jederzeit sichtbar mobile Nutzung möglich Suchfunktion vorhanden häufige Requests verfügbar Benutzerfeedback möglich Checkliste Automatisierung Standardprozess definiert Workflow dokumentiert Genehmigungen integriert Fehlerbehandlung vorhanden Rollback möglich Protokollierung aktiv Monitoring eingerichtet Tests durchgeführt Verantwortlicher benannt Dokumentation aktuell Bedeutung für Fachinformatiker für Systemintegration Fachinformatiker entwickeln, betreiben und überwachen häufig automatisierte Serviceprozesse. Typische Aufgaben: Workflows erstellen, Benutzerkonten automatisieren, Softwareverteilung verwalten, Berechtigungen vergeben, Identity-Management pflegen, Fehler analysieren, Automatisierungen testen, Self-Service-Portale verbessern. Gut geplante Automatisierungen reduzieren Routinearbeiten erheblich und erhöhen gleichzeitig die Servicequalität. Zusammenfassung Benutzer stellt Service Request ↓ Self-Service oder Service Desk ↓ Genehmigungen prüfen ↓ Workflow starten ↓ Automatisierte Bereitstellung ↓ Benutzer informieren ↓ Protokollieren ↓ Request abschließen Merksätze Standardisierte Requests eignen sich besonders für Automatisierung. Self-Service entlastet den Service Desk. Automatisierung benötigt Monitoring und Fehlerbehandlung. Gute Workflows verkürzen Bearbeitungszeiten erheblich. Jede Automatisierung muss nachvollziehbar dokumentiert werden. Verwandte Seiten 9.1 Ziele und Grundlagen des Service Request Management 9.2 Request Model und Standard Requests 9.3 Genehmigungen und Freigabeverfahren 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management Knowledge Management Service Level Management Continual Improvement Quellen und Versionsstand Offizielle Grundlagen PeopleCert – ITIL Practice Guide: Service Request Management PeopleCert – ITIL Practice Guide: Knowledge Management ITIL Foundation – Version 5 Einordnung Die dargestellten Beispiele, Workflows, Self-Service-Funktionen und Automatisierungen sind herstellerneutrale Praxisempfehlungen. ITIL schreibt weder bestimmte Portale noch konkrete Automatisierungsplattformen vor. Die technische Umsetzung hängt von den eingesetzten ITSM-, Identity-Management- und Workflow-Systemen der jeweiligen Organisation ab. Behandelter Framework-Stand: ITIL Version 5 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance Fachlicher Stand: August 2026 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