# 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: - den genauen Ablauf, - erforderliche Informationen, - Genehmigungen, - Bearbeitungsschritte, - beteiligte Teams, - Kommunikation, - Abschlusskriterien. Jeder gleichartige Request wird möglichst nach demselben Modell bearbeitet. --- **Ziele eines Request Models** Ein Request Model soll: - Bearbeitung standardisieren, - Qualität erhöhen, - Bearbeitungszeit verkürzen, - Fehler vermeiden, - Verantwortlichkeiten festlegen, - Genehmigungen eindeutig regeln, - Automatisierung ermöglichen, - Dokumentation vereinfachen, - Servicequalität verbessern. --- **Warum Request Models wichtig sind** Ohne festgelegte Abläufe entscheidet jeder Bearbeiter unterschiedlich. Dadurch entstehen häufig: - unterschiedliche Bearbeitungszeiten, - unterschiedliche Ergebnisse, - fehlende Informationen, - unnötige Rückfragen, - doppelte Arbeiten, - fehlende Genehmigungen. 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: - Name des Requests, - Beschreibung, - Kategorie, - Zielgruppe, - Voraussetzungen, - erforderliche Angaben, - Genehmigungen, - Bearbeitungsschritte, - beteiligte Teams, - Automatisierungen, - Kommunikation, - Abschlusskriterien, - Dokumentation. Je komplexer ein Request ist, desto ausführlicher sollte das Modell sein. --- **Beispiel: Softwareinstallation** Ein mögliches Request Model: ```text 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: - Passwort zurücksetzen - Benutzerkonto anlegen - Monitor bestellen - VPN-Zugang beantragen - Software installieren - Gruppenmitgliedschaft ändern - Drucker bereitstellen - E-Mail-Postfach erweitern - Mobiltelefon bestellen - Shared Mailbox erstellen Für Standard Requests existiert normalerweise bereits ein Request Model. --- **Eigenschaften eines Standard Requests** Ein Standard Request ist: - wiederkehrend, - dokumentiert, - planbar, - risikoarm, - standardisiert, - nachvollziehbar, - häufig automatisierbar. Dadurch kann die Bearbeitung weitgehend unabhängig vom Bearbeiter erfolgen. --- **Nicht jeder Request ist ein Standard Request** Einige Anforderungen sind individuell. Beispiele: - Einführung einer neuen Fachanwendung - komplexe Netzwerkanpassung - außergewöhnliche Hardwarebeschaffung - individuelle Spezialsoftware - neue Cloud-Architektur 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: - Name - Abteilung - Kostenstelle - Standort - gewünschte Software - Gerät - gewünschter Termin - Begründung - Ansprechpartner Fehlende Informationen führen häufig zu Verzögerungen. --- **Pflicht- und optionale Angaben** Nicht alle Informationen sind immer erforderlich. Beispiel: Pflichtfelder: - Benutzer - Software - Gerät Optionale Angaben: - gewünschter Installationstermin - Bemerkungen - Projektname Dadurch bleiben Formulare übersichtlich. --- **Genehmigungen im Request Model** Viele Standard Requests benötigen Genehmigungen. Beispiele: - Vorgesetzter - Kostenstellenverantwortlicher - Informationssicherheit - Softwareverantwortlicher - Lizenzmanager - Datenschutz Das Request Model definiert eindeutig, wann welche Genehmigung erforderlich ist. --- **Genehmigungsfreie Requests** Nicht jeder Request benötigt eine Freigabe. Beispiele: - Passwort zurücksetzen - Knowledge-Artikel aufrufen - Druckertreiber herunterladen - Standardsoftware installieren (wenn bereits genehmigt) - FAQ nutzen Dadurch sinkt der Bearbeitungsaufwand erheblich. --- **Bearbeitungsschritte definieren** Ein Request Model beschreibt jeden Bearbeitungsschritt. Beispiel: - Request prüfen - Genehmigung einholen - Lizenz reservieren - Software verteilen - Installation kontrollieren - Benutzer informieren - Dokumentation aktualisieren - Request schließen 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: - Formular prüfen - Genehmigung versenden - Benutzerkonto erstellen - Gruppenmitgliedschaft vergeben - Software installieren - E-Mail versenden - Ticket schließen - Dokumentation ergänzen Automatisierung reduziert manuelle Tätigkeiten erheblich. --- **Kommunikation** Auch die Kommunikation sollte standardisiert werden. Beispiele: - Eingangsbestätigung - Genehmigung angefordert - Bearbeitung begonnen - Bereitstellung abgeschlossen - zusätzliche Informationen benötigt - Request erfolgreich abgeschlossen 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: - Sind die Bearbeitungsschritte noch aktuell? - Stimmen die Genehmigungen? - Gibt es neue Automatisierungen? - Haben sich Systeme geändert? - Gibt es häufige Rückfragen? - Entstehen unnötige Wartezeiten? Ein veraltetes Request Model führt schnell zu Fehlern. --- **Versionierung** Änderungen an Request Models sollten nachvollziehbar sein. Dokumentiert werden können: - Versionsnummer - Änderungsdatum - Bearbeiter - Grund der Änderung - betroffene Schritte Dadurch bleibt nachvollziehbar, welcher Ablauf aktuell gültig ist. --- **Praxisbeispiel** Ein neuer Mitarbeiter beginnt am Montag. Der Service Request: > "Neuer Mitarbeiter" startet automatisch: - Benutzerkonto - E-Mail - Microsoft 365 - VPN - Gruppenmitgliedschaften - Notebook - Monitor - Mobiltelefon - Berechtigungen 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** - [ ] Request eindeutig beschrieben - [ ] Kategorie festgelegt - [ ] Zielgruppe definiert - [ ] Voraussetzungen beschrieben - [ ] Pflichtinformationen festgelegt - [ ] Genehmigungen geregelt - [ ] Bearbeitungsschritte dokumentiert - [ ] Verantwortlichkeiten festgelegt - [ ] Automatisierungen berücksichtigt - [ ] Kommunikation definiert - [ ] Abschlusskriterien beschrieben - [ ] Version dokumentiert --- **Bedeutung für Fachinformatiker für Systemintegration** Fachinformatiker arbeiten täglich mit Request Models. Typische Aufgaben: - Standardsoftware bereitstellen, - Benutzerkonten anlegen, - Berechtigungen vergeben, - Hardware vorbereiten, - Automatisierungen entwickeln, - Dokumentationen pflegen, - Request Models verbessern, - Bearbeitungszeiten optimieren. 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** - 9.1 Ziele und Grundlagen des Service Request Management - 9.3 Genehmigungen und Freigabeverfahren - 9.4 Erfüllung, Automatisierung und Self-Service - 9.5 Zusammenspiel mit Incident, Change, Knowledge und Service Level Management - Service Level Management - Knowledge Management - Continual Improvement --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Service Request Management - ITIL Foundation – Version 5 **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