Demand vs. Incident vs. Service Request

Abgrenzung der drei zentralen Tickettypen im IT-Service-Management.

Confluence (Light-Theme + Interaktiv): Lifecycle-Prozess (statisch) Projektprozess (interaktiv)

Demand

Anforderung / Change Request

Eine fachliche Anforderung zur Weiterentwicklung oder Anpassung eines Systems. Der Demand beschreibt was gebaut oder geändert werden soll.

Auslöser Fachbereich oder Projektleitung
Ziel Neue Funktionalität, Prozessanpassung oder Optimierung
Priorität Wird im Demand-Management priorisiert (Backlog)
Ergebnis Transporte (TRs) die ins System importiert werden

Beispiele:

Neues Berichtsfeld in der Finanzbuchhaltung
Anpassung eines Workflows für Freigabeprozesse
Integration einer neuen Schnittstelle
Erweiterung des Berechtigungskonzepts

Incident

Störung / Fehlerticket

Eine ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services. Der Incident beschreibt was kaputt ist und muss so schnell wie möglich behoben werden.

Auslöser Endanwender oder Monitoring-System
Ziel Schnellstmögliche Wiederherstellung des Normalbetriebs
Priorität Nach Dringlichkeit & Auswirkung (P1–P4)
Ergebnis Bugfix-Transport oder Workaround + ggf. Problem-Ticket

Beispiele:

ABAP-Dump beim Buchen einer Rechnung
Schnittstelle liefert falsche Daten
Berechtigungsfehler nach Rollentransport
Performance-Einbruch bei Massenverarbeitung

Service Request

Serviceanfrage / Standardanfrage

Eine Standardanfrage für einen vordefinierten IT-Service. Kein Fehler, keine Neuentwicklung — sondern eine Routinetätigkeit.

Auslöser Endanwender oder Fachbereich
Ziel Durchführung einer Routine-/Standard-Tätigkeit
Priorität Standard-SLA (kein Notfall)
Ergebnis Konfiguration, Berechtigung oder Datenänderung

Beispiele:

Neuen Benutzer anlegen / Berechtigung zuweisen
Customizing-Wert anpassen (Buchungskreis, Werk)
Transport manuell in ein System importieren
Hintergrundjob einplanen oder ändern

Vergleich auf einen Blick

Merkmal	Demand	Incident	Service Request
Was?	Neue Anforderung	Störung / Fehler	Standardanfrage
Dringlichkeit	Geplant (Backlog)	Hoch — ASAP	Normal (SLA)
Wer entscheidet?	Demand Board / PO	Incident Manager	Service Desk
Prozess	Analyse → Design → Entwicklung → Test → Go-Live	Analyse → Diagnose → Fix → Verify	Anfrage → Prüfung → Durchführung
Ergebnis-Typ	Feature-Transporte	Bugfix-Transport / Workaround	Konfig / Berechtigung
ITIL-Kategorie	Change Management	Incident Management	Request Fulfillment
Typischer SLA	Wochen – Monate	Stunden – Tage (P1: <4h)	Tage (3–5 Werktage)

Entscheidungsbaum: Welcher Tickettyp?

Vom Ticket zum Feature — Cloud ALM Lifecycle

Egal ob Incident, Service Request oder Demand — alle drei Tickettypen münden über ein Custom ServiceNow Object in ein Cloud ALM Feature, das den gesamten Umsetzungslebenszyklus steuert.

ServiceNow – Cloud ALM Feature Interface

SAP-Änderung wird in ServiceNow ausgelöst Demand (nach Approval) Service Request (Standard oder Non-Standard) Incident

Assignee wird übernommen Der Bearbeiter aus dem ServiceNow-Ticket wird als Verantwortlicher in das Cloud ALM Feature übertragen, um den SAP-Transport zu implementieren.

Feature wird einem Release zugeordnet Das Feature wird einem Release zugewiesen, das die Deployments orchestriert: Major Minor Project

Umsetzung komplett in Cloud ALM Transport-Erstellung, Deployment ins nächste System, Testing, Dokumentation und Freigabe für Produktion — alles wird in SAP Cloud ALM gesteuert.

ServiceNow-Ticket wird aufgelöst Nach finaler Bestätigung des Features in Cloud ALM wird das ursprüngliche ServiceNow-Ticket automatisch resolved.

Tester Workflow — Feature Processing

Beim Status-Wechsel zu „In Testing“ wird der Tester automatisch per E-Mail informiert und das Testdokument als Referenz an das Feature angehängt. Die Steuerung läuft über Power Automate.