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