Request-to-Fulfill(R2F)
Vom Antrag im Serviceportal bis zur bestätigten Bereitstellung: wie der Request-to-Fulfill-Prozess abläuft, woran er gemessen wird und wo Standardanfragen unnötig lange warten.
Auch bekannt als: R2F · Request to Fulfill · Request-to-Fulfil · Service Request Management · Request Fulfilment · Serviceanforderung
Was ist Request-to-Fulfill?
Request-to-Fulfill (R2F) ist der End-to-End-Prozess vom Antrag auf einen IT-Service bis zu seiner bestätigten Bereitstellung. Er umfasst die Auswahl eines Angebots im Servicekatalog oder Self-Service-Portal, die fachliche und gegebenenfalls kaufmännische Genehmigung, die Erfüllung – etwa Zugriffsrechte, Hardware, Softwarelizenzen oder die IT-Ausstattung neuer Mitarbeitender, teils über den Einkauf –, die Übergabe mit Bestätigung durch den Antragsteller und den Abschluss des Antrags. Das Value-Stream-Modell IT4IT und die ITIL-Praxis Service Request Management beschreiben diesen Ablauf; im Alltag entscheidet er darüber, wie schnell Mitarbeitende arbeitsfähig sind.
Startet mit
Ein Mitarbeitender oder eine Führungskraft beantragt einen Service aus dem Servicekatalog.
Endet mit
Der Service ist bereitgestellt, vom Antragsteller bestätigt und der Antrag geschlossen.
Typische Phasen
- 1
Antrag über Servicekatalog
Im Self-Service-Portal wählt der Antragsteller ein Katalogangebot und füllt das zugehörige Formular aus. Katalogeintrag und Formular legen fest, welche Daten, Genehmigungen und Erfüllungsschritte folgen.
- Katalogangebot gewählt
- Antrag eingereicht
- Antrag vervollständigt
- Antrag klassifiziert
- 2
Genehmigung
Je nach Service geben Vorgesetzte, Kostenstellenverantwortliche oder Dateneigentümer den Antrag frei. Kritische Berechtigungen benötigen zusätzliche Prüfungen.
- Genehmigung angefordert
- Rückfrage gestellt
- Antrag genehmigt
- Antrag abgelehnt
- 3
Erfüllung
Fulfilment-Aufgaben werden an die zuständigen Teams verteilt oder automatisiert ausgeführt: Berechtigung vergeben, Software verteilen, Gerät aus dem Lager bereitstellen oder über eine Bestellung beschaffen.
- Erfüllungsaufgabe erstellt
- Aufgabe zugewiesen
- Berechtigung vergeben
- Bestellung ausgelöst
- Gerät konfiguriert
- 4
Übergabe & Abschluss
Der Service wird übergeben, der Antragsteller bestätigt die Bereitstellung, und der Antrag wird geschlossen – bei Bedarf mit Zufriedenheitsabfrage.
- Service übergeben
- Bereitstellung bestätigt
- Antrag geschlossen
Geschäftsobjekte und Systeme
Diese Objekte hinterlässt der Prozess in den Quellsystemen – mit Zeitstempeln, Verantwortlichen und Beziehungen untereinander.
- Serviceantrag
- Der Antrag mit Antragsteller, Katalogangebot, Priorität, SLA und Status von eingereicht bis geschlossen.
- Katalogangebot
- Ein Eintrag im Servicekatalog mit Formular, Genehmigungsregel und hinterlegtem Erfüllungsablauf.
- Genehmigung
- Freigabe oder Ablehnung durch eine verantwortliche Person, mit Zeitpunkt und Begründung.
- Erfüllungsaufgabe
- Ein Arbeitsschritt für ein Team oder eine Automatisierung, mit Zuweisung, Wartezeit und Ergebnis.
- Bestellung
- Beschaffung von Hardware oder Lizenzen, wenn der Bedarf nicht aus Bestand gedeckt werden kann.
- Konfigurationselement
- Das bereitgestellte Gerät, die Lizenz oder die Berechtigung, wie sie in der CMDB erfasst wird.
Typische Quellsysteme
- IT-Service-Management-Plattformen (z. B. ServiceNow, Jira Service Management, BMC Helix)
- Identity- und Access-Management
- Software-Verteilung und Endgeräteverwaltung
- ERP- oder Einkaufssystem für Bestellungen
Kennzahlen, die sich messen lassen
- Durchlaufzeit je Katalogangebot
- Zeit vom eingereichten Antrag bis zur bestätigten Bereitstellung.
- SLA-Erfüllung
- Anteil der Anträge, die innerhalb der vereinbarten Servicezeit erfüllt sind.
- Genehmigungsdauer
- Wartezeit zwischen Anforderung und Entscheidung einer Freigabe.
- Automatisierungsgrad
- Anteil der Erfüllungsaufgaben, die ohne manuellen Eingriff ablaufen.
- Wiedereröffnungsquote
- Anteil der Anträge, die nach dem Schließen erneut geöffnet oder nachgebessert werden.
Typische Probleme
Warten auf Freigaben
Mehrstufige Genehmigungen und Rückfragen machen oft den größten Teil der Durchlaufzeit aus, obwohl die eigentliche Erfüllung schnell erledigt wäre.
Standardanfragen mit Handarbeit
Wiederkehrende Anträge wie Zugriffsrechte oder Softwareinstallationen laufen trotz klarer Regeln über manuelle Aufgaben und Teamwechsel.
Die Beschaffung als Blackbox
Sobald ein Gerät bestellt werden muss, endet die Sicht des Service-Desks. Wie lange Bestellung, Lieferung und Wareneingang dauern, steht in einem anderen System.
Uneinheitliche Wege pro Katalogangebot
Formulare werden unvollständig eingereicht, Aufgaben zwischen Teams weitergereicht oder Schritte außerhalb des Tools erledigt – derselbe Service läuft jedes Mal anders.
So analysiert Noreja Request-to-Fulfill
Ein Serviceantrag zerfällt in Genehmigungen, mehrere Erfüllungsaufgaben und manchmal eine Bestellung im Einkaufssystem – mit eigenen Zeitstempeln und Verantwortlichen. Ein flacher Eventlog mit dem Antrag als Fall-ID zeigt nur die Gesamtdauer. Noreja verbindet Antrag, Aufgaben, Bestellung und Konfigurationselement im Event Knowledge Graph und macht so sichtbar, ob die Zeit in der Freigabe, im Fulfilment-Team oder in der Lieferung verloren geht.
Für jedes Katalogangebot wird der vorgesehene Erfüllungsablauf als erwartete Reihenfolge modelliert. So fällt auf, wo Genehmigungen übersprungen, Aufgaben doppelt angelegt oder Anträge geschlossen werden, bevor der Service tatsächlich bereitsteht.
Fragen, die Noreja beantwortet
- Welche Katalogangebote verfehlen ihre SLAs am häufigsten?
- Wie viel der Durchlaufzeit entfällt auf Genehmigungen und Rückfragen?
- Welche Standardanfragen eignen sich für eine vollständige Automatisierung?
- Wie lange warten Anträge mit Beschaffung auf Bestellung und Lieferung?
- Wo werden Aufgaben mehrfach zwischen Teams weitergereicht?
- Wie schnell ist die IT-Ausstattung neuer Mitarbeitender zum Eintrittstag bereit?
Passende Agents aus der Minerva Agent Library
Häufige Fragen zu Request-to-Fulfill
Was ist der Request-to-Fulfill-Prozess?
Request-to-Fulfill (R2F) ist der End-to-End-Prozess vom Antrag auf einen IT-Service bis zu seiner bestätigten Bereitstellung. Er umfasst Antrag über den Servicekatalog, Genehmigung, Erfüllung – etwa Berechtigungen, Hardware oder Software –, Übergabe und Abschluss.
Was ist der Unterschied zwischen Request-to-Fulfill und Issue-to-Resolution?
Request-to-Fulfill behandelt geplante Anforderungen an einen Standardservice, etwa ein neues Notebook oder eine Berechtigung. Issue-to-Resolution beschreibt die Bearbeitung von Störungen und Kundenservice-Tickets, bei denen etwas nicht funktioniert und wiederhergestellt werden muss.
Welche KPIs sind im Request-to-Fulfill wichtig?
Typische Kennzahlen sind die Durchlaufzeit je Katalogangebot, die SLA-Erfüllung, die Genehmigungsdauer, der Automatisierungsgrad der Erfüllungsaufgaben und die Wiedereröffnungsquote.
Kann man Process Mining im IT-Service-Management einsetzen?
Ja. Anträge, Genehmigungen, Aufgaben und Statuswechsel hinterlassen Zeitstempel und Zuständigkeiten in der ITSM-Plattform, Bestellungen im ERP. Process Mining zeigt daraus den tatsächlichen Ablauf je Service, Wartezeiten zwischen Teams und Kandidaten für die Automatisierung.
Demo-Cases mit ausgearbeiteter Analyse
End-to-End-Prozesse, die wir mit Findings, Ursachen und Maßnahmen durchgespielt haben – teils mit Berührungspunkten zu Request-to-Fulfill.
Deinen Prozess kausal verstehen — sprich mit uns
Schließe dich Unternehmen an, die mit intelligenter Prozessanalyse Wachstum und Effizienz neu definieren.