Request-to-Service (R2S) ist der horizontale End-to-End-Prozess von der eingehenden Anfrage bis zur SLA-Berichterstattung — die Service-Wertschöpfungsstrecke neben Order-to-Cash und Source-to-Pay. Aus unserer Erfahrung in über 1.200 Beratungsprojekten der Dreher Consulting wissen wir: Im DACH-Mittelstand scheitert R2S nicht an fehlenden Tools, sondern am überdimensionierten ITIL-Rollenmodell. Anders als ITIL-Lehrbücher suggerieren, ist R2S kein reines ITSM-Thema, sondern das service-seitige Pendant zu O2C und S2P.
Was ist Request-to-Service? Definition und Abgrenzung
Request-to-Service ist der End-to-End-Prozess von der eingehenden Service-Anfrage über Klassifikation, Genehmigung und Erfüllung bis zur SLA-Berichterstattung und Rückkopplung in die Kennzahlen. Der häufige Fehler im Mittelstand: R2S wird auf den Service-Desk-Ticket-Lifecycle verkürzt und damit von der Wertschöpfungslogik abgekoppelt.
Request-to-Service umfasst alle Aktivitäten von der ersten Service-Anfrage über die Klassifikation als Service Request versus Incident, die Genehmigung bei kostenrelevanten Anfragen, die standardisierte Erfüllung über einen Servicekatalog, die Closure und die Auswertung gegen SLA und XLA. Die ITIL 4 Service Request Management Practice beschreibt die Praktik für vordefinierte, nutzerinitiierte Anfragen — der Bezeichnungswechsel von Request Fulfilment (ITIL v3) zu Service Request Management (ITIL 4) ist die Standardreferenz.
Methodisch verankert das APQC Process Classification Framework die Service-Erbringung in Kategorie 5.0 (Deliver Services) als eigenständige End-to-End-Prozessgruppe — getrennt von der Produktauslieferung. ISO/IEC 20000-1:2018 deckt das Service-Request-Management als normativen Anker ab.
Drei Begriffe sollten Geschäftsführerinnen und Geschäftsführer auseinanderhalten:
- Request-to-Service (R2S) — der gesamte horizontale Prozess vom eingehenden Antrag bis zur SLA-Berichterstattung; service-seitiges Pendant zu O2C und S2P.
- Service Request Management (SRM) — die ITIL-4-Praktik für die Bearbeitung vordefinierter Anfragen; methodischer Baustein im R2S.
- Incident Management — die Behandlung ungeplanter Störungen; klar abgegrenzt nach dem ITIL-Prinzip „give me something" (Request) versus „fix something" (Incident).
In Porters Wertschöpfungskette (Porter, 1985) ist R2S die horizontale Verzahnung der Primäraktivität Service mit den Operations — die Strecke, an der vertikale Linienorganisationen am häufigsten zerbrechen.
Warum Request-to-Service 2026 im DACH-Mittelstand neu relevant ist
Steigender Servicedruck, zunehmende KI-Nutzung im Self-Service und der Reifedruck aus Digitalisierungsprojekten machen R2S 2026 zur Chefsache. Wer Service-Anfragen weiter in HR-, IT- und Facility-Silos bearbeitet, verliert die Steuerung über Servicequalität und Erfüllungszeiten.
Erstens steigt der Servicedruck im Mittelstand. Die Bitkom-Studie Digitalisierung der Wirtschaft 2025 weist 53 Prozent der Unternehmen mit Problemen bei der Bewältigung ihrer Digitalisierung aus. In unseren Mandaten sehen wir, dass diese Defizite genau dort sichtbar werden, wo der R2S-Prozess nicht durchgängig dokumentiert ist.
Zweitens verändert die KI-Adoption die Anfragestruktur. Laut derselben Bitkom-Studie nutzen rund 41 Prozent der Unternehmen aktiv KI-Funktionen. Self-Service-Portale beantworten Routine-Anfragen wie Passwort-Reset zunehmend autonom — die menschliche Bearbeitung verschiebt sich auf komplexere, kostenrelevante Anfragen. In unseren R2S-Mandaten bei DACH-Dienstleistern beobachten wir, dass die Self-Service-Quote deutlich steigt, sobald der Servicekatalog auf wenige Anfragetypen konsolidiert ist.
Drittens setzt der DSAG-Investitionsreport 2026 die Tool-Diskussion unter Wirtschaftlichkeits-Druck. 42 Prozent der DACH-SAP-Anwender planen S/4HANA On-Premises, 38 Prozent setzen ihr IT-Budget gezielter ein. Investitionen folgen nicht Visionen, sondern Integrierbarkeit — der Rahmen für eine pragmatische R2S-Toolentscheidung statt eines ITIL-Vollausbaus.
Die R2S-Methodik im Überblick — vier Phasen, ein Process Owner
Wir setzen Request-to-Service im DACH-Mittelstand in vier nummerierten Phasen auf — Intake und Klassifikation, Genehmigung und Triage, Erfüllung und Closure, SLA-Reporting und Insight. Über alle vier Phasen muss eine Prozesseigentümerschaft laufen: der R2S-Owner. Ohne diese Rolle entstehen Funktionsgrenzen statt Wertschöpfungsstrecken.
Methodisch hat sich in der vendor-neutralen Prozess- und ERP-Beratung die folgende vierstufige Vorgehensweise bewährt:
- Phase 1 — Intake und Klassifikation. Aufnahme der Anfrage über Self-Service-Portal, E-Mail oder Telefon, Klassifikation als Service Request oder Incident und Zuordnung zu einem Eintrag im Servicekatalog. Hier wird das Anfrage-Datenmodell entschieden — welche Felder sind Pflicht, welche optional, in welchem System geführt. ServiceNow Service Request Management beschreibt diesen Schritt als strukturierten Eingangsprozess.
- Phase 2 — Genehmigung und Triage. Bewertung anhand vordefinierter Genehmigungs- und Qualifizierungsprozesse, Eskalation an Finanzabteilung oder Fachbereich bei kostenrelevanten Anfragen (z. B. Notebook-Beschaffung), Zuordnung zu einem Owner. Der Atlassian Service Request Management Guide dokumentiert diese Genehmigungsmechanik als Standard-Workflow.
- Phase 3 — Erfüllung und Closure. Standardisierte Bearbeitung über automatisierte oder manuelle Workflows, Bereitstellung des Service, Bestätigung an die Nutzerin oder den Nutzer und formale Closure. Aus unseren 1.200+ Projekten wissen wir, dass mehr als die Hälfte der Verlustpunkte in dieser Phase an der Schnittstelle Service-Desk zu Fachbereich entstehen.
- Phase 4 — SLA-Reporting und Insight. Auswertung gegen Service Level Agreements (Response Time, Resolution Time, Anteil termingerechter Anfragen) und Experience Level Agreements (XLA) — Drei-Fragen-Mikrofeedback nach Closure, Rückspielung in die Kennzahlen-Kette First Contact Resolution, Mean Time to Fulfil, SLA-Compliance, XLA-Score. Erst wenn diese Kette geschlossen ist, entsteht aus R2S eine Steuerungsgrundlage.
Über allen vier Phasen muss ein R2S-Owner mit End-to-End-Verantwortung stehen — typischerweise auf Geschäftsleitungsebene. Die Owner-Frage muss vor jeder Tool-Diskussion geklärt sein.
Praxisbeispiel: Service-Desk-Konsolidierung bei einem DACH-Dienstleister
Bei einem mittelständischen IT-Dienstleister mit rund 380 Beschäftigten waren drei parallele Service-Desks für IT, HR und Facility entstanden — jeder mit eigenem Ticketsystem, eigenem Servicekatalog und eigener SLA-Logik. Aus unserer Erfahrung ein typisches Muster im DACH-Mittelstand: nicht ein fehlendes Tool, sondern drei zu viele.
In unseren R2S-Mandaten bei DACH-Dienstleistern beobachten wir, dass die Mitarbeiter-Schnittstellen typischerweise an drei Stellen reißen — Intake-zu-Klassifikation, Triage-zu-Erfüllung und Erfüllung-zu-SLA-Reporting. Der Bitkom-Befund von 53 Prozent Digitalisierungs-Problemen bildet diese Mikrobruchstellen auf Makro-Ebene ab.
Der Dienstleister mit 380 Beschäftigten rief uns, weil die Mean Time to Fulfil auf über 4,5 Werktage gestiegen war und die Self-Service-Quote unter 15 Prozent lag. Drei Service-Desks (IT, HR, Facility) hatten eigene Wege. Die Trovarit-Studie ERP in der Praxis 2024/25 bestätigt: Schnittstellen-Reife bleibt ein Kernkriterium der Anwenderzufriedenheit.
Wir haben den Fall in sieben Wochen aufgenommen: Prozesserhebung über Interviews und Ticket-Auswertung, Swim-Lane-Modellierung, Identifikation der Bruchstellen, Konsolidierung auf einen gemeinsamen Servicekatalog mit drei Service-Linien und Reduktion auf 22 Anfragetypen. Die Genehmigungs-Workflows wurden mit den Fachbereichsleitungen neu kalibriert.
Die Lösung war kein neues System. Die Geschäftsführung hat einen R2S-Owner auf Ebene der Bereichsleitung benannt, der gemeinsam mit den drei Service-Linien-Verantwortlichen einen Soll-Prozess festgelegt hat. Die Mean Time to Fulfil sank in zwei Quartalen auf 1,8 Werktage; die Self-Service-Quote stieg auf 58 Prozent. Das System-Update folgte erst danach — auf Basis eines aus dem konsolidierten Prozess hervorgegangenen Lastenhefts.
Was Request-to-Service-Leitfäden verschweigen
Drei Punkte, die in den meisten Request-to-Service-Leitfäden selten ausgesprochen werden, aus unseren 1.200+ Beratungsprojekten aber regelhaft den Unterschied zwischen Erfolg und Abbruch entscheiden. Anders als ITIL-Lehrbücher suggerieren, sind die kritischen Themen organisatorisch — nicht technisch.
1. R2S ist der mittelstandsspezifische E2E-Geschäftsprozess — kein reines ITSM-Thema
In den meisten Online-Leitfäden wird Request-to-Service als ITIL-Praktik beschrieben — eingebettet in einen Service-Desk-Tool-Kontext. Diese Verengung verkennt die mittelstandsspezifische Realität: R2S ist horizontal mit Order-to-Cash und Source-to-Pay verzahnt — Genehmigungen laufen über das ERP, Kostenbuchungen ebenso, Kundenkommunikation häufig über CRM. APQC PCF und ISO/IEC 20000 stützen diese E2E-Sicht. Wir empfehlen, R2S im Lastenheft explizit gegen O2C und S2P abzugrenzen, bevor ein ITSM-Tool ausgewählt wird.
2. Drei Bruchstellen, die kein Tool repariert
Aus unserer Erfahrung entstehen mehr als die Hälfte der R2S-Verlustpunkte an Funktionsgrenzen, nicht innerhalb einer Funktion. Erstens die Intake-zu-Klassifikation-Schnittstelle: Wenn Service Request und Incident nicht trennscharf klassifiziert sind, läuft die Triage falsch. Zweitens die Triage-zu-Erfüllung-Schnittstelle: Ohne benannten Owner pro Service-Linie bleiben Anfragen liegen. Drittens die Erfüllung-zu-SLA-Reporting-Schnittstelle: Wenn Service-Desk-Tool und ERP getrennte Datenmodelle führen, werden SLA und Kostenbuchung doppelt gepflegt. Diese drei Bruchstellen bearbeiten wir in einem Workshop mit Swim-Lanes — bevor irgendein neues Tool ausgewählt wird.
3. XLA statt nur SLA — Experience Level Agreement als die wirklich zählende Steuerungsgröße
SLAs messen, ob der Prozess gelaufen ist (Response Time, Resolution Time). XLAs messen, ob die Nutzerin oder der Nutzer den Service als hilfreich empfunden hat. Im Mittelstand bedeutet das nicht eine 80-Indikator-CSAT-Plattform, sondern ein Drei-Fragen-Mikrofeedback nach Closure. Wir sehen in unseren Mandaten, dass XLA-Daten regelhaft Anfragetypen offenlegen, deren SLA grün ist, aber deren Nutzererlebnis rot — genau dort liegen die Stellhebel für die nächste Iteration des Servicekatalogs.
Unsere Einordnung
Request-to-Service ist ein Organisations-, kein Tool-Thema. Wer den R2S-Owner benennt, die drei Bruchstellen analysiert und SLA durch XLA ergänzt, hat die schwierigen 80 Prozent erledigt. Die ITSM-Tool-Auswahl folgt anschließend dem konsolidierten Lastenheft.
Anwendung in den Dreher-Branchen
Der R2S-Zuschnitt unterscheidet sich zwischen IT-Dienstleistern, Industrieunternehmen mit Field Service und Verwaltungs- bzw. Shared-Service-Organisationen. Wir kalibrieren die vier Phasen branchenspezifisch — kurze Erfüllungszyklen und Self-Service im IT-Servicebereich, Field-Service-Einsatz und Ersatzteilanforderung in der Industrie, Enterprise Service Management über HR, Facility und Legal in der Verwaltung.
Bei IT-Dienstleistern dominiert die Self-Service-Quote als zentrale Steuerungsgröße. Im Anlagen- und Maschinenbau hat R2S als Field-Service-Prozess eine andere Logik: Anfrage über Kundenportal, Disposition über Field Service Management, Ersatzteil-Anforderung über das ERP, Closure mit Servicebericht — das Servicegeschäft wächst hier als eigene Säule neben dem Neugeschäft. In Verwaltungs- und Shared-Service-Organisationen weitet sich R2S auf Enterprise Service Management aus — HR, Facility und Legal laufen über einen gemeinsamen Servicekatalog. Aus unserer Erfahrung reduziert diese Konsolidierung Lizenzkosten und vermeidet Tool-Wildwuchs.
Häufig gestellte Fragen
Request-to-Service ist der End-to-End-Prozess der Servicebereitstellung von der eingehenden Anfrage bis zur SLA-Berichterstattung und umfasst typischerweise IT-, HR- und Facility-Services. Order-to-Cash ist die Strecke ab Auftragseingang bis zum Zahlungseingang. R2S und O2C sind horizontale Geschwister-Prozesse mit unterschiedlichen Wertschöpfungslogiken. Das APQC-Framework trennt sie in eigene Prozessgruppen. Wer beide Prozesse gleichsetzt, schneidet ein R2S-Projekt fälschlicherweise auf die Auftragsabwicklung zu.
In unseren 1.200+ Projekten empfehlen wir, den R2S-Owner auf Geschäftsleitungsebene oder direkt darunter anzusiedeln — operativ häufig bei der Leitung Service oder bei einer Rolle „Head of Service Operations". Wichtig ist die End-to-End-Befugnis: Der Owner muss Änderungen am Servicekatalog, an Genehmigungs-Workflows und an der SLA-Logik genehmigen können. Eine fragmentierte Owner-Struktur über IT-, HR- und Facility-Silos funktioniert für R2S nicht — die Schnittstellen zerbrechen genau dort. Aus unserer Erfahrung lässt sich der R2S-Owner gut mit dem O2C-Owner und dem S2P-Owner in einer Process-Owner-Runde koordinieren.
Aus unseren R2S-Mandaten bei DACH-Dienstleistern empfehlen wir, mit einem rund 20 Einträge umfassenden Servicekatalog zu starten — nicht mit einer 200-Service-CMDB. Im Mittelstand werden typischerweise nur 20 bis 30 Anfragetypen wirklich regelmäßig benutzt; jeder weitere Katalogeintrag erhöht den Pflegeaufwand ohne Nutzererlebnis-Gewinn. Wir konsolidieren in der Vor-Tool-Phase auf maximal 25 Einträge, drei Prioritätsstufen und einen Process Owner — anschließend wird der Katalog auf Basis tatsächlicher Anfragehäufigkeit iterativ erweitert. Anders als ITIL-Lehrbücher suggerieren, ist die Katalog-Größe kein Reife-Indikator — die Self-Service-Quote und der XLA-Score sind die belastbaren Steuerungsgrößen.
Nächste Schritte
Vor jeder ITSM-Tool- oder Lastenheft-Diskussion lohnt sich eine kurze Vorklärung: Wer ist der R2S-Owner? Wie sehen die vier Phasen heute aus? Wo liegen die drei typischen Bruchstellen? Wer diese Vorklärung überspringt, baut einen Servicekatalog, den niemand führt.
Wenn Sie diese Themen vertiefen möchten, empfehlen wir unsere Leistungen im Prozessmanagement und die ERP-Beratung. Ergänzend die Wiki-Beiträge zu Order-to-Cash, Lead-to-Cash und Source-to-Pay. Ein Erstgespräch vereinbaren Sie über die Kontaktseite.
30 Minuten mit Dreher Consulting
Eine strukturierte Vorklärung Ihres Request-to-Service — R2S-Owner, die vier Phasen und die drei typischen Bruchstellen, anbieterneutral aus über 1.200 Projekten im DACH-Mittelstand.
