SHM Bedarfsrouting: Kompaktübersicht
Leitfrage: Wer ist der Bedarfsträger und woher kommt der Bedarf?
Die drei Bedarfstypen auf einen Blick
| Merkmal |
Typ 1: Extern |
Typ 2: Intern (Fast Track) |
Typ 3: Service-Lifecycle |
| Bedarfsträger |
Ämter, Dienststellen außerhalb DIGIT |
DIGIT-Mitarbeiter als Nutzer |
SO, ISB, SOR, DIGIT-Leitung |
| Beispiele |
Bauamt, Sozialamt, Ordnungsamt |
Personalabteilung DIGIT, Sekretariat |
Service Owner für eigenen Service |
| Eintrittskanal |
SHM |
SHM (Self-Service) |
Direkt SOR/DPM |
| Prozess |
Regelweg (Schritt 0 + Prüfungen 1-3) |
Fast Track (3 Schritte) |
Kein SHM-Routing |
| SHM-Aufwand |
2-4 Stunden |
10-15 Minuten |
0 (nur Information) |
| Steckbrief |
Vollständig |
Reduziert |
Vom Bedarfsträger |
Entscheidungsbaum: Welcher Typ?
BEDARF GEHT EIN
│
▼
┌─────────────────────────────────────────────────────┐
│ Wer ist Bedarfsträger? │
└─────────────────────────────────────────────────────┘
│
├── Externes Amt/Dienststelle ──────────────► TYP 1 (Regelweg)
│ (Bauamt, Sozialamt, etc.)
│
├── DIGIT-Mitarbeiter als Nutzer ───────────► TYP 2 (Fast Track)
│ (Personalabteilung, Sekretariat)
│
└── SO/ISB/SOR/Leitung ─────────────────────► TYP 3 (Bypass)
(für eigenen Service/Fachbereich) → Kein SHM-Routing!
Typ 2: Fast Track im Detail (10-15 Min.)
| Schritt |
Dauer |
Frage |
Ergebnis |
| 1. Basistriage |
3-5 min |
Ist es ein valider Bedarf im DIGIT-Scope? |
Valide → weiter / Unklar → Rückfrage |
| 2. Routing |
5-7 min |
Gibt es einen bestehenden Service? |
Ja → direkt an SO / Nein → DPM-INTERN |
| 3. Minimaldoku |
3-5 min |
Nur bei ROUTE-DPM-INTERN |
SHM-Einschätzung (2-3 Sätze) |
Typ 3: Wann ist SHM NICHT zuständig?
SHM routet nicht, wenn der Bedarf aus dem Service-Lifecycle kommt:
| Auslöser |
Bedarfsträger |
Weg |
SHM-Rolle |
| SO erkennt Change-Bedarf (aus Review) |
Service Owner |
SO führt Change durch |
Keine |
| SO erkennt Redesign-Bedarf |
Service Owner |
SO → SOR → DPM |
Info bei Stakeholder-Auswirkung |
| Service-Ablösung geplant |
SO/SOR |
SO → SOR → DPM |
Stakeholder-Kommunikation |
| Sicherheitsanforderung |
ISB |
ISB → SOR/SO |
Ggf. Stakeholder-Kommunikation |
| Strategische Initiative |
DIGIT-Leitung/MB |
MB → DPM |
Frühzeitige Einbindung |
Merksatz: Wenn ein SO etwas an seinem eigenen Service ändern will, ist das Typ 3 – nicht Typ 2!
Häufige Grenzfälle
| Situation |
Einschätzung |
Typ |
| DIGIT-Personalabteilung braucht neue Software |
DIGIT-MA als Nutzer |
Typ 2 |
| Personalamt der Stadt braucht neue Software |
Externes Amt |
Typ 1 |
| Stabsstelle Digital möchte Miro |
Interner Nutzer (obwohl nicht direkt DIGIT) |
Typ 2 |
| SO möchte sein DMS modernisieren |
SO für eigenen Service |
Typ 3 |
| Stakeholder beschwert sich → SO erkennt Redesign |
Initial extern, dann SO-Erkenntnis |
Typ 1 → Typ 3 |
SHM-Aufgaben je Typ
| Typ |
SHM macht... |
SHM macht NICHT... |
| Typ 1 |
Vollständige Bewertung, User Stories, Steckbrief |
– |
| Typ 2 |
Fast Track (3 Schritte), Minimaldoku |
Vollständige Bedarfserhebung |
| Typ 3 |
Stakeholder-Kommunikation (wenn informiert) |
Routing, Bedarfsbewertung |
Kurzreferenz: Status-Werte
| Status |
Bedeutung |
Typ |
an_dpm_uebergeben |
Externer Bedarf an DPM (vollständig) |
Typ 1 |
an_dpm_uebergeben_intern |
Interner Bedarf an DPM (reduziert) |
Typ 2 |
in_klaerung_intern |
Fast Track: Rückfrage an Einreichenden |
Typ 2 |
an_spm_uebergeben |
Change an Service Owner |
Typ 1 oder 2 |
Version 1.0 | Stand: 29.01.2025 | Quelle: shm_bedarfsbewertung.yaml v1.3, shm_interne-bedarfe-routing.yaml v2.0
