Wiki source code of NOC Use Case
Version 1.1 by Dimitri Rupp on 2026/06/11 11:00
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | {{toc/}} |
| 2 | |||
| 3 | |||
| 4 | = NOC Use Case — Projekt RedPath = | ||
| 5 | |||
| 6 | Sales Order: RedPath Owner: Dimitri Rupp — Application Manager SPL Tele Status: Aktiv · MVP-Phase (BCA Phase 1) Stand: 21.05.2026 · BCA-Kickoff erfolgt am 18.05.2026 BVL-Status der Seite: 1 (Strategie, Steckbrief, Stakeholder) · 0.5 (laufende Klärungen — siehe Abschnitt 13) | ||
| 7 | |||
| 8 | |||
| 9 | == 1. Executive Summary == | ||
| 10 | |||
| 11 | Das Projekt RedPath automatisiert das 24/7-Störungs-Ticketing und das Dispatching von Außendienst-Technikern für die Mobilfunk-Tower-Wartung der SPL Tele Group. Über die RPA-Plattform UiPath wird der heute manuell — durch ein ausgelagertes NOC in Serbien — betriebene Prozess auf einen unattended Software-Roboter überführt, der direkt mit dem hauseigenen Ticketsystem RIMO und mit (% class="recall-entity-class" id="rab-highlight-tutorial-id" recall-entity-id="4101b63b-72bb-4681-9f27-5ab65b81cfd8" style="position:relative; z-index:6" %)Microsoft(%%) Teams interagiert. | ||
| 12 | |||
| 13 | |||
| 14 | **Strategischer Treiber:** Unabhängigkeit vom externen NOC, Eliminierung manueller Copy-/Paste-Tätigkeiten, durchgängiger Audit-Trail im RIMO-Ticket, robuste 24/7-Verfügbarkeit. | ||
| 15 | |||
| 16 | |||
| 17 | **Kommerzieller Rahmen Jahr 1:** ca. €63.000–65.000 (BCA-Service ~~€20.000–22.000 + UiPath-Lizenzen ~~€43.000). Stop-Loss €6.000 nach der MVP-Decision. | ||
| 18 | |||
| 19 | |||
| 20 | **Timeline: **60 Arbeitstage / 10 Kalenderwochen. Projektstart 11.05.2026, Kickoff 18.05.2026, Go-Live geplant 17.07.2026. | ||
| 21 | |||
| 22 | |||
| 23 | ---- | ||
| 24 | |||
| 25 | == 2. Geschäftlicher Hintergrund & Pain Points == | ||
| 26 | |||
| 27 | === 2.1 Ausgangslage === | ||
| 28 | |||
| 29 | SPL Tele betreibt für ihre Mobilfunk-Tower-Kunden ein 24/7-Incident-Management. Eingehende Störungs-Meldungen müssen erfasst, im RIMO-Ticketsystem angelegt, priorisiert, gegen Lagerbestand und Standort-Daten geprüft und an dienst-habende Techniker eskaliert werden. Aktuell läuft dieser Prozess weitgehend manuell über einen externen Dispatch-Dienstleister. | ||
| 30 | |||
| 31 | === 2.2 Pain Points (heute) === | ||
| 32 | |||
| 33 | |=Pain Point|=Wirkung | ||
| 34 | |Manuelles „Copy & Paste" von E-Mail-Inhalt in RIMO|Hoher Personalaufwand, Fehlerquote | ||
| 35 | |Externes NOC in Serbien|Abhängigkeit, Sprache, Skill-Volatilität, Datenschutz-Spannungsfeld | ||
| 36 | |Heterogene Eingangskanäle|E-Mail (Templates und Freitext) plus eine einzige Kunden-API | ||
| 37 | |Manuelle Telefon-Eskalation bei Prio 0/1|Nicht skalierbar, nachts fehleranfällig | ||
| 38 | |Keine durchgängige Audit-Spur|Schwer rekonstruierbar bei Pönalen-Disputen | ||
| 39 | |||
| 40 | === 2.3 Strategische Ziele === | ||
| 41 | |||
| 42 | 1. Qualität vor Geschwindigkeit — fehlerhafte Ticket-Anlagen verursachen Pönalen durch Endkunden | ||
| 43 | 1. Unabhängigkeit vom externen NOC — höchste Priorität | ||
| 44 | 1. Skalierbarkeit — weitere Optimierungen folgen erst nach stabilem MVP | ||
| 45 | |||
| 46 | |||
| 47 | |||
| 48 | |||
| 49 | == 3. Projekt-Steckbrief == | ||
| 50 | |||
| 51 | |=Position|=Wert | ||
| 52 | |Sales Order|RedPath | ||
| 53 | |Use Case|24/7 Incident Ticketing & Dispatch Automation für Mobilfunk-Tower-Service | ||
| 54 | |Projektleitung|Dimitri Rupp (Application Manager SPL Tele) | ||
| 55 | |Operativer Sponsor|Christian Richter (Head of IT & Digital Transformation), Kristijan Galik | ||
| 56 | |Strategischer Sponsor|David Planner (CDO) — nur Decision Gates M2 + M5 | ||
| 57 | |Process Owner|Michael Scheiber (Business Unit Owner) | ||
| 58 | |RIMO Application Owner|Christian Bauch | ||
| 59 | |Externer Partner|BCA Solutions (Budapest / Nürnberg) — UiPath Gold Partner | ||
| 60 | |RPA-Plattform|UiPath | ||
| 61 | |Zielsystem|RIMO (in-house Ticketing, primär UI-Automation, API selektiv) | ||
| 62 | |Plattform-Basis|Microsoft 365 (Graph API für Mail + Teams) | ||
| 63 | |Projektdauer|60 Arbeitstage (~~12 Kalenderwochen) + 5 SPL-interne Vorlauftage | ||
| 64 | |Investitionsrahmen|~~€63.000–65.000 (Jahr 1) | ||
| 65 | |Stop-Loss|€6.000 nach MVP-Decision (M2) | ||
| 66 | |Projektsprache|Englisch (BCA-Interface), Deutsch (SPL-intern) | ||
| 67 | |||
| 68 | |||
| 69 | |||
| 70 | ---- | ||
| 71 | |||
| 72 | == 4. Stakeholder-Verzeichnis == | ||
| 73 | |||
| 74 | === SPL Tele intern === | ||
| 75 | |||
| 76 | |=Rolle|=Person|=Frequenz | ||
| 77 | |Projektleitung|Dimitri Rupp|— | ||
| 78 | |Operativer Sponsor|Christian Richter|wöchentlich | ||
| 79 | |Operativer Sponsor (Co-Lead)|Kristijan Galik|wöchentlich | ||
| 80 | |Strategischer Sponsor|David Planner (CDO)|nur M2 + M5 | ||
| 81 | |Process Owner / BU Owner|Michael Scheiber|bi-wöchentlich | ||
| 82 | |RIMO Application Owner|Christian Bauch|bei Bedarf | ||
| 83 | |IT Security / DPO / M365 Admin|Christian Richter, Miguel Olbrich|Compliance | ||
| 84 | |||
| 85 | === BCA Solutions (UiPath Gold Partner) === | ||
| 86 | |||
| 87 | |=Rolle|=Person|=Kontakt | ||
| 88 | |Head of Automation — Single Point of Contact|Bernadett Borsos|[[bernadett.borsos@bca.hu>>mailto:bernadett.borsos@bca.hu]], +36 70 310-4869 | ||
| 89 | |BCA Consultant|Edit Selmeczi|— | ||
| 90 | |BCA Senior Consultant|Tibor Glazer|— | ||
| 91 | |BCA Senior Consultant|Balint Kulcsar|— | ||
| 92 | |||
| 93 | === Kommunikationsregeln === | ||
| 94 | |||
| 95 | * Single Channel SPL ↔ BCA: Dimitri ↔ Bernadett | ||
| 96 | * Weekly Status Sync mit Christian Richter (ab KW 20) | ||
| 97 | * David Planner ausschließlich für Decision Points M2 + M5 | ||
| 98 | * Eskalations-Ladder: T1 Dimitri/Bernadett · T2 → Christian Richter · T3 → David Planner | ||
| 99 | |||
| 100 | |||
| 101 | |||
| 102 | ---- | ||
| 103 | |||
| 104 | == 5. Ist-Prozess (heute · manuell) == | ||
| 105 | |||
| 106 | Der heutige Ablauf wird vollständig manuell durch das ausgelagerte Dispatch-Team in Serbien ausgeführt. RIMO wird über die Web-GUI per Copy-/Paste bedient. | ||
| 107 | |||
| 108 | Prozess-Schritte (vereinfacht): | ||
| 109 | |||
| 110 | 1. Mail/API-Eingang — Dispatcher liest manuell die Störungsmeldung | ||
| 111 | 1. Pflichtfelder-Prüfung — vollständig? Bei „nein" → Klärungsschleife mit Kunde | ||
| 112 | 1. Plausibilitätscheck — Site ↔ Bundesland abgleichen | ||
| 113 | 1. Dublettenprüfung — gleiches Ticket schon offen? | ||
| 114 | 1. Lagerstand-Check — über RIMO-WebGUI | ||
| 115 | 1. Location-Info-Prüfung — Adresse, Erreichbarkeit | ||
| 116 | 1. Priorisierung — Prio 0–4 setzen, Time Limit aus Kunden-Mail übernehmen | ||
| 117 | 1. Bei Prio 0/1: Diensthabenden in GUI suchen, Teams-/Telefon-Anruf manuell, Retry-Schleife | ||
| 118 | 1. Bei Prio 2–4: Auf Techniker-Rückmeldung warten | ||
| 119 | 1. Textbausteine für Kundenmail manuell zusammensetzen | ||
| 120 | 1. Versand & Protokollierung im Ticket | ||
| 121 | |||
| 122 | |||
| 123 | |||
| 124 | Detailliertes Swim-Lane-Diagramm: Datei RedPath_02_Prozess_IST.drawio in der Liefermappe. | ||
| 125 | |||
| 126 | |||
| 127 | |||
| 128 | == 6. Soll-Prozess (UiPath-automatisiert) == | ||
| 129 | |||
| 130 | Der Software-Roboter übernimmt die kompletten Standardfälle. Ein Mensch wird ausschließlich für die Manual Clarification Queue benötigt — bei mehrdeutigem Input. | ||
| 131 | |||
| 132 | === 6.1 Modulare Workflow-Module (REFramework-konform) === | ||
| 133 | |||
| 134 | 1. Intake & Parsing — Outlook/Graph-Subscription, API-Listener, Template-Erkennung | ||
| 135 | 1. Validation & Plausibility — Pflichtfelder, Site↔Region-Match | ||
| 136 | 1. RIMO Crosscheck & Ticketing — Dublettenprüfung, Ticketanlage, Feldmapping | ||
| 137 | 1. Stock & Location Checks — Lagerbestand, Erreichbarkeit | ||
| 138 | 1. Priority Engine — Kundenspezifische Strategie (siehe Abschnitt 8) | ||
| 139 | 1. Dispatch & Adaptive Card Escalation — Teams Adaptive Card, Retry-Logik | ||
| 140 | 1. Customer Communication — Textbaustein-basierter Mail-Versand | ||
| 141 | |||
| 142 | === 6.2 Adaptive-Card-Eskalation (Prio 0/1) === | ||
| 143 | |||
| 144 | Der Bot platziert keine VoIP-Anrufe. Stattdessen — entschieden und freigegeben: | ||
| 145 | |||
| 146 | |||
| 147 | 1. Bot ermittelt diensthabenden Techniker für die Region | ||
| 148 | 1. Bot postet eine Microsoft-Teams-Adaptive-Card über Microsoft Graph API | ||
| 149 | 1. Card enthält: Site-Nummer, Fehlerart, Priorität, Buttons „I'm on it" / „Cannot take this", Link zum RIMO-Ticket | ||
| 150 | 1. Push-Notification weckt den Techniker | ||
| 151 | 1. Bot lauscht über Webhook auf die Card-Response | ||
| 152 | 1. Annahme → Bot schreibt RIMO-Zeiteintrag „on the way", Flow geht weiter | ||
| 153 | 1. Ablehnung oder Timeout (Default 5 Min, konfigurierbar) → nächster Techniker | ||
| 154 | 1. Alle Techniker exhausted → Eskalation an Supervisor-Channel + Transaction-Flag | ||
| 155 | 1. Parallelität: Bot bearbeitet weiteren Intake während die Eskalations-Schleife läuft | ||
| 156 | |||
| 157 | |||
| 158 | |||
| 159 | Detailliertes Soll-Diagramm: Datei RedPath_03_Prozess_SOLL.drawio. | ||
| 160 | |||
| 161 | |||
| 162 | |||
| 163 | == 7. Solution Architecture == | ||
| 164 | |||
| 165 | === 7.1 Queue-Topologie (UiPath Orchestrator) === | ||
| 166 | |||
| 167 | |=Queue|=Zweck|=Producer|=Consumer | ||
| 168 | |IntakeQueue|Ein Item pro eingehender Mail/API-Call|Intake-Watcher (Graph-Subscribe, API-Listener)|Main Processing Robot | ||
| 169 | |EscalationQueue|Prio-0/1-Dispatch-Loop mit Retry|Main Robot nach Priority Decision|Escalation Robot (oder paralleler Folder) | ||
| 170 | |ResponseQueue|Triggered wenn Techniker RIMO-Status „completed" setzt|RIMO-Watcher (Polling oder Webhook)|Customer-Comms Robot | ||
| 171 | |ManualClarificationQueue|Items, die der Bot nicht verarbeiten kann|jedes Modul auf Klärungspfad|Dispatcher (Action Center) | ||
| 172 | |||
| 173 | === 7.2 Komponenten-Übersicht === | ||
| 174 | |||
| 175 | * UiPath Orchestrator (Cloud oder On-Prem — TBD) | ||
| 176 | * 2 Unattended Robots — Main Processor + Escalation Processor (parallel) | ||
| 177 | * 1 Automation Test Robot — synthetische End-to-End-Tests post Go-Live | ||
| 178 | * 1 Developer License — Named User | ||
| 179 | * Credential Vault — UiPath Asset oder Azure Key Vault (TBD) | ||
| 180 | * Outbound Mailbox (noreply / response) | ||
| 181 | * Service-E-Mail-Account (Automation@…) für UiPath | ||
| 182 | * Microsoft 365 Tenant — Exchange Online, Teams, Graph API | ||
| 183 | |||
| 184 | === 7.3 RIMO-Integration === | ||
| 185 | |||
| 186 | RIMO hat eine beschränkte interne API — der Scope reicht nicht für vollständige Abdeckung. UI-Automation bleibt der primäre Integrations-Modus. API wird selektiv für lese-lastige Operationen (z. B. Ticket-Lookup über Source-ID) genutzt, wo Endpunkte verfügbar sind. | ||
| 187 | |||
| 188 | |||
| 189 | Architektur-Prinzip: Alle RIMO-Interaktionen (API + UI) werden hinter einer Abstraktion gekapselt, sodass eine zukünftige API-Erweiterung nicht in die Business-Logik durchschlägt. | ||
| 190 | |||
| 191 | |||
| 192 | |||
| 193 | == 8. Priorisierungslogik (Prio 0–4) == | ||
| 194 | |||
| 195 | === 8.1 Prio-Stufen & SLA-Fenster === | ||
| 196 | |||
| 197 | |=Stufe|=Beschreibung|=Time-Window | ||
| 198 | |Prio 0|Höchste Eskalation (bei Huawei nicht vorhanden)|sofort | ||
| 199 | |Prio 1 / Climb|Höhenarbeit|3,5 h | ||
| 200 | |Prio 1 / non-Climb|Bodenarbeit|3,5 h | ||
| 201 | |Prio 2 / Climb| |5,5 h | ||
| 202 | |Prio 2 / non-Climb| |5,5 h | ||
| 203 | |Prio 3 / Climb| |24 h | ||
| 204 | |Prio 3 / non-Climb| |24 h | ||
| 205 | |Prio 4 / non-Climb| |> 72 h | ||
| 206 | |||
| 207 | |||
| 208 | |||
| 209 | Das tatsächliche Time Limit wird in jeder Störungs-Mail vom Kunden mitgegeben und ist für SPL führend. | ||
| 210 | |||
| 211 | === 8.2 Konfigurierbarkeit pro Kunde (FR-012) === | ||
| 212 | |||
| 213 | Die Priorisierungs-Strategie pro Kunde ist ohne Code-Deployment konfigurierbar — empfohlen als YAML oder UiPath Asset. Audit-Trail im RIMO-Ticket bei jeder Priorisierungs-Entscheidung: Zeitstempel, angewandte Strategie, Input-Werte, Mapping-Regel, Output-Priorität, Quell-Mail-Referenz. | ||
| 214 | |||
| 215 | |||
| 216 | Begleit-Dokumente: RedPath_06_Priorisierungslogik_Vorschlag.md v0.3 und RedPath_07_Priorisierung_DecisionTree.drawio v0.3. | ||
| 217 | |||
| 218 | |||
| 219 | |||
| 220 | == 9. Kunden & Eingangskanäle == | ||
| 221 | |||
| 222 | |=Kundentyp|=Eingangsweg|=Besonderheit | ||
| 223 | |Huawei (Hauptkunde)|E-Mail (Template)|Übermittelt Spare Parts direkt in der Mail | ||
| 224 | |Hutchison (Hutch)|Direkte API zu RIMO|Generiert Ticket-Entwurf vorab | ||
| 225 | |Magenta, Nokia, Nomad, OMV|E-Mail (standardisiert/Freitext)|— | ||
| 226 | |Colt, FON, DFAC (kleinere Kunden)|E-Mail|— | ||
| 227 | |||
| 228 | t ca. 10–12 Kunden in Scope. Telefonische Störungs-Meldungen kommen praktisch nicht mehr vor. | ||
| 229 | |||
| 230 | |||
| 231 | |||
| 232 | == 10. Success Metrics & KPIs == | ||
| 233 | |||
| 234 | Baselines werden in WP1 mit David Planner finalisiert. | ||
| 235 | |||
| 236 | |||
| 237 | |=KPI|=Ziel|=Definition | ||
| 238 | |Bearbeitungszeit Eingang → Ticketanlage|< 5 Min|Zeit von Mail/API-Eingang bis RIMO-Ticket angelegt | ||
| 239 | |Anteil Manual Queue|< 10 %|Anteil Incidents, die menschliche Klärung benötigen | ||
| 240 | |Eskalations-Erfolgsquote (1. Anlauf)|> 80 %|Prio 0/1 erreicht diensthabenden Techniker beim ersten Versuch | ||
| 241 | |Bot-Verfügbarkeit (24/7)|> 99,5 %|Unattended Runtime Stability | ||
| 242 | |||
| 243 | |||
| 244 | |||
| 245 | |||
| 246 | == 11. Timeline, Workpackages & Milestones == | ||
| 247 | |||
| 248 | === 11.1 Workpackages === | ||
| 249 | |||
| 250 | |=WP|=Inhalt|=Dauer|=Verantwortung | ||
| 251 | |WP1|Plan & Setup|5 Tage|SPL intern | ||
| 252 | |WP2|Build MVP|20 Tage (3 Wochen)|BCA Phase 1 | ||
| 253 | |WP3|Decision Point|2–3 Tage|SPL Leadership | ||
| 254 | |WP4|Build Full Implementation|25 Tage (3 Wochen)|BCA Phase 2 | ||
| 255 | |WP5|Go-Live + Hypercare + Prüfen|10 Tage (2 Wochen)|BCA + SPL Ops | ||
| 256 | |||
| 257 | === 11.2 Milestones === | ||
| 258 | |||
| 259 | |=Milestone|=Datum|=Inhalt | ||
| 260 | |M1 — Kickoff|18.05.2026|BCA-Kickoff vor Ort in Wolkersdorf (erledigt) | ||
| 261 | |M2 — MVP-Decision|08.06.2026|Go/No-Go für Phase 2 — Stop-Loss-Punkt | ||
| 262 | |M3 — Feature Complete|03.07.2026|Vollumfang implementiert | ||
| 263 | |M4 — Go-Live|06.07.2026|Produktiv-Start | ||
| 264 | |M5 — Hypercare-Ende|17.07.2026|Abnahme & Projektabschluss | ||
| 265 | |||
| 266 | === 11.3 Operating Cadences === | ||
| 267 | |||
| 268 | * Montag 08:00 — Weekly Status Sync (Dimitri + Christian) | ||
| 269 | * Dienstag + Donnerstag 10:00 (ab KW 21) — BCA Delivery Sync (Dimitri + Bernadett) | ||
| 270 | * Freitag Nachmittag — Sprint Review (alle Sprint-Mitglieder) | ||
| 271 | * Bi-wöchentlich — Process Owner Check-in (Dimitri + Scheiber) | ||
| 272 | * M2 + M5 — Steering Decision Gate mit David Planner | ||
| 273 | |||
| 274 | |||
| 275 | |||
| 276 | |||
| 277 | == 12. Definition of Done (DoD) == | ||
| 278 | |||
| 279 | * Standardfälle (E-Mail & API) werden automatisiert verarbeitet | ||
| 280 | * Pflichtfeld-Prüfung mit sauberer Fehlermeldung / Queue | ||
| 281 | * Plausibilitätscheck implementiert (mindestens Warnflag) | ||
| 282 | * Crosscheck / Dubletten-Erkennung über Ursprungs-Ticketnummer, keine Doppelanlage | ||
| 283 | * RIMO-Ticketanlage und Feldmapping korrekt | ||
| 284 | * Lagerstand-Check über RIMO-WebGUI inkl. Ticketvermerk | ||
| 285 | * Location-Checks inkl. Ticketvermerk | ||
| 286 | * Prio 0/1: Dienst-habenden ermitteln, Teams-Adaptive-Card, Wiederholung bis Zeiteintrag | ||
| 287 | * Kundenrückmeldung via Textbausteine wird korrekt versendet und protokolliert | ||
| 288 | * Runbook + Monitoring + Alerting vorhanden | ||
| 289 | |||
| 290 | === Testfall-Kategorien === | ||
| 291 | |||
| 292 | * Happy Paths — vollständige E-Mail/API, Prio 2–4 | ||
| 293 | * Prio 0/1 — Weckschleife, Reaktion nach mehreren Versuchen | ||
| 294 | * Dubletten — wiederholter Eingang gleicher Ursprungs-Ticketnummer | ||
| 295 | * Fehlerfälle — fehlende Felder, Plausi-Mismatch, RIMO-Timeout, Teams nicht verfügbar | ||
| 296 | * Edge Cases — Formatabweichungen, Sonderzeichen, mehrere Bauteile/Mengen | ||
| 297 | |||
| 298 | |||
| 299 | |||
| 300 | |||
| 301 | == 13. Risiken & Gegenmaßnahmen == | ||
| 302 | |||
| 303 | |=#|=Risiko|=Wahrscheinlichkeit|=Impact|=Maßnahme | ||
| 304 | |R1|UI-Änderungen in RIMO brechen Bot|mittel|hoch|Stabile Selektoren, Regression-Tests, Release-Abstimmung | ||
| 305 | |R2|MFA/SSO erschwert Bot-Login|mittel|hoch|Service Accounts + Conditional Access für Bot, Credential Vault | ||
| 306 | |R3|Teams-Automatisierung eingeschränkt|niedrig|mittel|Adaptive-Card-Pattern statt VoIP, Fallback definiert | ||
| 307 | |R4|Datenqualität / Template-Drift|hoch|mittel|Template-Versionierung, Unclassified-Queue, Monitoring | ||
| 308 | |R5|DSGVO / AVV mit Kunden nicht konform|niedrig|hoch|Frühe DSGVO-Folgenabschätzung in Phase 1 | ||
| 309 | |R6|RedPath-Inkohärenz bei späterem RIMO-Ablöse-Szenario|mittel|mittel|Architektur-Robustheit via RIMO-REST-API statt UI-Automation erhöhen, Prozesswissen als migrationsrelevantes Asset sichern | ||
| 310 | |||
| 311 | |||
| 312 | |||
| 313 | |||
| 314 | == 14. Kommerzielle Größenordnung == | ||
| 315 | |||
| 316 | === Indikative UiPath-Lizenz-Aufstellung (BCA-Angebot, 1-Jahres-Term) === | ||
| 317 | |||
| 318 | |=Produkt|=Menge|=List Price|=Indicative Discounted | ||
| 319 | |UiPath Uni Platform Standard|1|€30.000|€19.500 | ||
| 320 | |UiPath Uni Unattended Robot|2|€20.000|€18.000 | ||
| 321 | |UiPath Uni Pro Named User (Developer)|1|€4.400|€3.960 | ||
| 322 | |UiPath Uni Automation Test Robot|1|€2.000|€1.760 | ||
| 323 | |Total| |€56.400|€43.260 | ||
| 324 | |||
| 325 | === Service-Aufwand BCA === | ||
| 326 | |||
| 327 | * Phase 1 (MVP): ~~€6.000 (fix price) | ||
| 328 | * Phase 2 (Full Implementation): ~~€14.000–16.000 | ||
| 329 | * BCA-Service gesamt: ~~€20.000–22.000 | ||
| 330 | |||
| 331 | |||
| 332 | |||
| 333 | Gesamtrahmen Jahr 1: ~~€63.000–65.000 | ||
| 334 | |||
| 335 | |||
| 336 | |||
| 337 | == 15. Out of Scope (Saying No) == | ||
| 338 | |||
| 339 | Das RedPath-MVP umfasst nicht: | ||
| 340 | |||
| 341 | |||
| 342 | * Auto-Priorisierung aus Fehlercodes (keine Regel-Tabelle vorhanden) | ||
| 343 | * Tatsächliche Teams-VoIP-Anrufe (Adaptive Card ist der Pattern) | ||
| 344 | * Umgehung der Manual-Clarification-Queue bei mehrdeutigem Input | ||
| 345 | * Freitext-generierte Kundenkommunikation (nur Textbausteine) | ||
| 346 | * Persistierung personenbezogener Daten außerhalb des RIMO-Ticket-Scopes | ||
| 347 | * Training mit historischen Daten (klassisch regelbasiert konfiguriert) | ||
| 348 | |||
| 349 | |||
| 350 | |||
| 351 | |||
| 352 | == 16. Stand & nächste Schritte (per 21.05.2026) == | ||
| 353 | |||
| 354 | === Erledigt === | ||
| 355 | |||
| 356 | * Lastenheft v1.0 (14.04.2026) | ||
| 357 | * Solution Design Brief v1.1 (Englisch, für BCA) | ||
| 358 | * Liefermappe RedPath 00–15 (Stand 07.05.2026) | ||
| 359 | * BCA-Vertragsverhandlung (KW 20) | ||
| 360 | * BCA-Kickoff (Mo 18.05.2026, Wolkersdorf) | ||
| 361 | * Process Owner identifiziert (Michael Scheiber) | ||
| 362 | * RIMO Application Owner identifiziert (Christian Bauch) | ||
| 363 | |||
| 364 | === In Arbeit (Sprint 1, KW 21–23) === | ||
| 365 | |||
| 366 | * RIMO-API-Discovery (DevTools-Self-Discovery) | ||
| 367 | * Detailliertes Design-Dokument (Design First — vor Code-Beginn freizugeben) | ||
| 368 | * Infrastruktur-Setup (VM, Service-Account, VPN, UiPath-Robot-Install) | ||
| 369 | * Mapping-Tabellen (Region/Bundesland, Fehlerarten, Textbausteine) | ||
| 370 | * Sign-Off Priorisierungs-Logik durch Michael Scheiber | ||
| 371 | |||
| 372 | === Decision Gate M2 (08.06.2026) === | ||
| 373 | |||
| 374 | * Go/No-Go für Phase 2 | ||
| 375 | * Stop-Loss-Punkt — bei No-Go: €6.000 BCA verbrannt, keine Production-Lizenzen aktiviert | ||
| 376 | |||
| 377 | |||
| 378 | |||
| 379 | |||
| 380 | == 17. Referenzen & verwandte Dokumente == | ||
| 381 | |||
| 382 | === Liefermappe RedPath (intern) === | ||
| 383 | |||
| 384 | * RedPath_00_README.md — Einstieg in die Mappe | ||
| 385 | * RedPath_01_Analyse_und_offene_Punkte.md — Lastenheft-Analyse, BVL-Status | ||
| 386 | * RedPath_02_Prozess_IST.drawio — Ist-Prozess Flussdiagramm | ||
| 387 | * RedPath_03_Prozess_SOLL.drawio — Soll-Prozess Flussdiagramm | ||
| 388 | * RedPath_04_Projektplan.md — Lean-Plan, 5 Workpackages, 5 Milestones | ||
| 389 | * RedPath_05_Optimierungsvorschlaege.md — Quick-Wins + strategische Empfehlungen | ||
| 390 | * RedPath_06_Priorisierungslogik_Vorschlag.md — Decision Tree Prio 0–4 | ||
| 391 | * RedPath_07_Priorisierung_DecisionTree.drawio — Visualisierung | ||
| 392 | * RedPath_08_Solution_Design_Brief_for_BCA_EN.pdf — BCA-Einstiegspunkt | ||
| 393 | * RedPath_12_RIMO_Endpoint_Catalog.xlsx — RIMO API-Endpoint-Katalog | ||
| 394 | * RedPath_15_Project_Control_Check_Christian.pdf — Master-Tracking | ||
| 395 | * Lastenheft_RPA_StoerungsTicketing_Dispatch_24x7NOC.pdf — Ursprungs-Lastenheft v1.0 | ||
| 396 | * SPL_BCA_proposal_202605_v1.pdf — BCA-Angebot | ||
| 397 | |||
| 398 | === Verwandte Wiki-Seiten === | ||
| 399 | |||
| 400 | * SPL TELE WIKI → AI - RPA - Automatisierungen → UiPath → Erste Einstellungen in UiPath Studio | ||
| 401 | * SPL TELE WIKI → AI - RPA - Automatisierungen → Fuhrpark | ||
| 402 | * SPL TELE WIKI → AI - RPA - Automatisierungen → KI Server | ||
| 403 | |||
| 404 | |||
| 405 | |||
| 406 | |||
| 407 | == 18. Versionierung dieser Seite == | ||
| 408 | |||
| 409 | |=Version|=Datum|=Autor|=Änderung | ||
| 410 | |v1.0|21.05.2026|Dimitri Rupp|Erstanlage nach BCA-Kickoff vom 18.05.2026 | ||
| 411 | |||
| 412 | ---- | ||
| 413 | |||
| 414 | {{include reference="IT-Wiki.Makros.Verwandte-Themen.WebHome"/}} | ||
| 415 | |||
| 416 | ---- | ||
| 417 | **Status:** Migriert — Team-Review ausstehend · **Owner:** //(festlegen)// · **Letzter Review:** 2026-06-11 | ||
| 418 |