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:

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:

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:

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:

Würde jede Anfrage individuell bearbeitet, entstünde unnötiger Aufwand.

Standardisierte Abläufe sorgen für:

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

Alle diese Fälle beschreiben eine Störung.

Beispiele für Service Requests

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:

Eine sinnvolle Kategorisierung erleichtert Automatisierung und Auswertung.

Warum Standardisierung wichtig ist

Je ähnlicher Requests bearbeitet werden,

desto einfacher lassen sie sich:

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:

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:

Dadurch sinkt die Anzahl telefonischer Anfragen erheblich.

Self-Service und Service Requests

Viele Requests eignen sich hervorragend für Self-Service.

Beispiele:

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:

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:

Servicequalität

Auch für Service Requests können Ziele definiert werden.

Beispiele:

Diese Ziele können Bestandteil eines SLA oder Servicekatalogs sein.

Dokumentation

Jeder Request sollte nachvollziehbar dokumentiert werden.

Mindestens:

Eine gute Dokumentation erleichtert spätere Auswertungen.

Automatisierung

Viele Service Requests lassen sich vollständig automatisieren.

Beispiele:

Automatisierung reduziert:

Vorteile des Service Request Management

Für Benutzer:

Für die IT:

Praxisbeispiel

Ein Mitarbeiter beginnt nächste Woche im Unternehmen.

Benötigt werden:

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

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker bearbeiten im Arbeitsalltag häufig mehr Service Requests als Incidents.

Typische Aufgaben sind:

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

Quellen und Versionsstand

Offizielle Grundlagen

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:

Jeder gleichartige Request wird möglichst nach demselben Modell bearbeitet.

Ziele eines Request Models

Ein Request Model soll:

Warum Request Models wichtig sind

Ohne festgelegte Abläufe entscheidet jeder Bearbeiter unterschiedlich.

Dadurch entstehen häufig:

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:

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:

Für Standard Requests existiert normalerweise bereits ein Request Model.

Eigenschaften eines Standard Requests

Ein Standard Request ist:

Dadurch kann die Bearbeitung weitgehend unabhängig vom Bearbeiter erfolgen.

Nicht jeder Request ist ein Standard Request

Einige Anforderungen sind individuell.

Beispiele:

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:

Fehlende Informationen führen häufig zu Verzögerungen.

Pflicht- und optionale Angaben

Nicht alle Informationen sind immer erforderlich.

Beispiel:

Pflichtfelder:

Optionale Angaben:

Dadurch bleiben Formulare übersichtlich.

Genehmigungen im Request Model

Viele Standard Requests benötigen Genehmigungen.

Beispiele:

Das Request Model definiert eindeutig,

wann welche Genehmigung erforderlich ist.

Genehmigungsfreie Requests

Nicht jeder Request benötigt eine Freigabe.

Beispiele:

Dadurch sinkt der Bearbeitungsaufwand erheblich.

Bearbeitungsschritte definieren

Ein Request Model beschreibt jeden Bearbeitungsschritt.

Beispiel:

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:

Automatisierung reduziert manuelle Tätigkeiten erheblich.

Kommunikation

Auch die Kommunikation sollte standardisiert werden.

Beispiele:

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:

Ein veraltetes Request Model führt schnell zu Fehlern.

Versionierung

Änderungen an Request Models sollten nachvollziehbar sein.

Dokumentiert werden können:

Dadurch bleibt nachvollziehbar,

welcher Ablauf aktuell gültig ist.

Praxisbeispiel

Ein neuer Mitarbeiter beginnt am Montag.

Der Service Request:

"Neuer Mitarbeiter"

startet automatisch:

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

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich mit Request Models.

Typische Aufgaben:

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

Quellen und Versionsstand

Offizielle Grundlagen

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:

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:

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:

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:

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:

  1. Vorgesetzter
  2. Informationssicherheit
  3. 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:

Dies wird von vielen ITSM-Systemen unterstützt.

Genehmigungsregeln

Ein Request Model sollte eindeutig festlegen:

Klare Regeln vermeiden Rückfragen und Verzögerungen.

Genehmigung ist keine technische Prüfung

Die Genehmigung beantwortet in erster Linie organisatorische Fragen.

Beispiele:

Die technische Umsetzung erfolgt anschließend durch die zuständigen IT-Teams.

Ablehnung eines Requests

Nicht jeder Request wird genehmigt.

Mögliche Gründe:

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:

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:

Voraussetzung ist, dass alle Regeln bereits definiert wurden.

Bedingte Genehmigungen

Manche Genehmigungen hängen von Bedingungen ab.

Beispiele:

Sind die Bedingungen nicht erfüllt, entfällt die zusätzliche Freigabe.

Genehmigungen dokumentieren

Jede Genehmigung sollte nachvollziehbar gespeichert werden.

Typische Informationen:

Dadurch bleibt später nachvollziehbar, warum eine Leistung bereitgestellt wurde.

Genehmigungen und Compliance

Viele gesetzliche oder interne Vorgaben verlangen dokumentierte Genehmigungen.

Beispiele:

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:

Temporäre Berechtigungen

Nicht jede Berechtigung muss dauerhaft vergeben werden.

Beispiele:

Nach Ablauf sollte die Berechtigung automatisch entzogen werden.

Genehmigungen regelmäßig überprüfen

Genehmigungsprozesse sollten regelmäßig bewertet werden.

Fragen dabei:

Ein effizienter Prozess schützt die Organisation, ohne die Benutzer unnötig auszubremsen.

Praxisbeispiel

Ein Entwickler benötigt Administratorrechte auf seinem Notebook.

Der Ablauf:

  1. Entwickler stellt Request.
  2. Vorgesetzter bestätigt die Notwendigkeit.
  3. Informationssicherheit prüft das Risiko.
  4. IT vergibt die Berechtigung.
  5. Die Rechte gelten nur für zwei Wochen.
  6. 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

Checkliste Berechtigungs-Requests

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker setzen viele genehmigte Service Requests technisch um.

Typische Aufgaben:

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

Quellen und Versionsstand

Offizielle Grundlagen

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:

Ziel ist eine schnelle und fehlerfreie Bereitstellung.

Ziele der Request-Erfüllung

Eine gute Request-Erfüllung soll:

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:

Dadurch sinken:

Automatisierung im Service Request Management

Viele wiederkehrende Aufgaben eignen sich hervorragend zur Automatisierung.

Beispiele:

Automatisierungen werden häufig über ITSM-Systeme, Identity-Management-Lösungen oder Workflow-Plattformen umgesetzt.

Vorteile der Automatisierung

Automatisierung bietet zahlreiche Vorteile:

Automatisierung ersetzt dabei nicht die Verantwortung für den Prozess.

Grenzen der Automatisierung

Nicht jeder Request kann vollständig automatisiert werden.

Beispiele:

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:

Dadurch werden Service Desk und Fachabteilungen entlastet.

Self-Service ist mehr als ein Formular

Ein modernes Self-Service-Portal bietet häufig:

Der Benutzer soll möglichst viele Aufgaben selbst erledigen können.

Der Servicekatalog

Der Servicekatalog bildet die Grundlage vieler Self-Service-Portale.

Er beschreibt:

Benutzer sollen ohne technisches Detailwissen erkennen können, welche Leistung sie benötigen.

Benutzerfreundliche Formulare

Ein gutes Formular ist:

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:

Wählt der Benutzer:

"Software"

erscheinen stattdessen:

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:

Dadurch muss der Benutzer nicht ständig nachfragen.

Identity Management

Viele Benutzer-Requests betreffen Identitäten und Berechtigungen.

Identity-Management-Systeme können beispielsweise:

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:

Die IT muss nur noch kontrollieren oder ausliefern.

Automatisierung mit Workflows

Workflow-Systeme können verschiedene Werkzeuge miteinander verbinden.

Beispiele:

Ein einziger Request kann dadurch zahlreiche Systeme automatisch steuern.

Fehlerbehandlung

Auch automatisierte Prozesse benötigen Fehlerbehandlung.

Mögliche Situationen:

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:

Dadurch lassen sich Fehler einfacher korrigieren.

Protokollierung

Jede automatische Bearbeitung sollte nachvollziehbar sein.

Typische Informationen:

Eine vollständige Protokollierung erleichtert Fehleranalyse und Audits.

Überwachung automatisierter Prozesse

Automatisierungen müssen überwacht werden.

Beispiele:

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:

Findet der Benutzer die Lösung selbst, muss kein Ticket erstellt werden.

Chatbots und virtuelle Assistenten

Viele Serviceportale integrieren Chatbots.

Sie können:

Komplexe Anfragen werden bei Bedarf an den Service Desk weitergeleitet.

Messung der Servicequalität

Auch Self-Service und Automatisierung sollten gemessen werden.

Beispiele:

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:

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

Checkliste Automatisierung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker entwickeln, betreiben und überwachen häufig automatisierte Serviceprozesse.

Typische Aufgaben:

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

Quellen und Versionsstand

Offizielle Grundlagen

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:

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:

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:

Nicht jede dieser Änderungen benötigt jedoch einen eigenen Change.

Standard Changes

Viele Service Requests werden über bereits genehmigte Standard Changes umgesetzt.

Beispiele:

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:

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:

Dadurch werden viele Requests vollständig vermieden.

Neue Knowledge-Artikel

Auch Service Requests können neue Dokumentationen erzeugen.

Beispiele:

Wissen sollte kontinuierlich erweitert werden.

Runbooks

Viele Standard Requests besitzen ein Runbook.

Ein Runbook beschreibt:

Dadurch arbeiten alle Bearbeiter nach demselben Verfahren.

Service Request Management und Service Level Management

Auch Service Requests besitzen häufig Serviceziele.

Beispiele:

Service Level Management überwacht,

ob diese Ziele erreicht werden.

Kennzahlen

Typische Kennzahlen:

Diese Kennzahlen helfen bei Verbesserungen.

Service Request Management und Information Security Management

Viele Requests betreffen Sicherheitsaspekte.

Beispiele:

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:

Nicht mehr benötigte Berechtigungen werden entfernt.

Service Request Management und Service Configuration Management

Viele Requests verändern Configuration Items.

Beispiele:

Nach der Bereitstellung sollten die entsprechenden Configuration-Daten aktualisiert werden.

Warum Configuration-Daten wichtig sind

Nur aktuelle Daten ermöglichen:

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:

Lieferzeiten externer Partner beeinflussen häufig die gesamte Bearbeitungsdauer.

Service Request Management und Continual Improvement

Jeder Request liefert Verbesserungspotenzial.

Beispiele:

Diese Erkenntnisse fließen in Continual Improvement ein.

Verbesserungsmöglichkeiten

Typische Maßnahmen:

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:

Währenddessen:

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

Checkliste Automatisierung

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich an den Schnittstellen verschiedener ITIL Practices.

Im Arbeitsalltag bedeutet dies:

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

Quellen und Versionsstand

Offizielle Grundlagen

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