Wie wir arbeiten: von den Zielen des Betreibers bis zu Releases nach dem Go-live

Was jede Phase umfasst

Phase	Arbeiten
Technische Releases (MVP)	Projektmanagement; Analyse und Design; Infrastruktur-Deployment; Build und Konfiguration; Integration; SIT (System Integration Testing); Planung von Cut-over und Migration; Wissenstransfer
Go-live-Release	Projekt- und Change-Management; Analyse und Design; Einrichtung von Infrastruktur und CI/CD; Integration; UAT (User Acceptance Testing); Cut-over; Migration; Schulung
Nach dem Go-live	Change-Management; Support auf vier Ebenen; Support für Infrastruktur und CI/CD; Change Requests; Sanity-Tests; Hypercare

Es kann mehrere technische Releases geben, jedes durchläuft SIT; das Go-live-Release durchläuft die UAT Ihres Teams. Nach dem Go-live – so viele Releases, wie das Geschäft braucht.

Wer was tut

Zwei Teams führen das Projekt: Ihres – das des Betreibers oder des Partners, der Ihr BSS liefert – und unseres. Die Aufteilung wird am ersten Tag festgelegt und ändert sich von Phase zu Phase nicht.

Ihr Team	MEF.DEV
Legt Ziele und Umfang fest	Untersucht die aktuellen Geschäftsprozesse und die Legacy-Landschaft, schlägt einen Transformationsplan für Ihre Geschäftsziele vor
Legt die Funktionen fest	Ordnet sie den Anforderungen an Sicherheit, Regulierung und Plattform zu
Formuliert Anforderungen	Hält Zeitplan und Fristen ein, erläutert die Kosten
Baut Geschäftslogik und Omnichannel auf Low-code	Backend, Services und Sicherheit des Backend-IT-Betriebs
Verfolgt Fortschritt, Engpässe und Änderungen	Codegenerierung, begleitete Umsetzung, Hosting von Anwendungs-Plugins in einem Kubernetes-Cluster
Orchestriert danach Änderungen und Weiterentwicklung selbst	Schulung, technischer Support, Bearbeitung von Störungen und neuen Anfragen

Beide Teams entwickeln gemeinsam. Der Rollout auf der Plattform umfasst mandantenfähiges Konfigurationsmanagement, Release-Management mit Versionierung und Rollback sowie die Verwaltung von Benutzerkonten.

Drei Projektebenen

• Management. Projektmanagement, Implementierung, Governance und Reporting – eines für das gesamte Programm.
• Programm. Für eine Betreibergruppe ist jede Landesgesellschaft ein eigenes Projekt nach derselben Vorlage: Das erste legt die Lösung fest, die nächsten wiederholen sie.
• Umsetzung. Infrastruktur-Deployment, mehrere technische Releases, das Go-live-Release und die Releases danach.

Arbeitsstränge und Rollen

Stränge, in denen beide Teams arbeiten: Management, Konfiguration, funktionale Anforderungen, Integration, nicht-funktionale Anforderungen, QA, Datenmigration, Schulung, CI/CD und Infrastruktur-Deployment. Auf unserer Seite: ein Projektmanager, ein BSS-Ingenieur, ein Business-Analyst, das Entwicklungsteam, ein Ingenieur für Datenmigration, BSS DevOps und Infra DevOps. Jede Seite hat eine Architektur-Governance: Ihre end-to-end, unsere für die Integrationsarchitektur.

Wie wir das Risiko der Umstellung senken

• Funktionstests der Legacy-Dienste – Kunden- und Auftragsmanagement, Charging, Rechnungsstellung, Provisioning – in Probeläufen vor dem Cut-over und erneut nach dem Go-live.
• Leistungsschwellen für IT Ops – ab dem Cut-over.
• E2E-Integration und -Tests nach einem Reifegradmodell.
• SLA- und KPI-Metriken – während der Stabilisierung nach dem Cut-over und darüber hinaus.
• Der Betreiber entscheidet über die Umstellung. Jedes Release geht nach Ihren Change-Management-Regeln in Produktion, mit Version und Rollback.

Wie wir mit Legacy arbeiten

• Reverse Engineering. Wir bilden das Verhalten des Legacy-Systems zuerst nach und dokumentieren es, statt es anzunehmen.
• Planung nach dem kritischen Pfad. Den Zeitplan bestimmt die Kette der Abhängigkeiten zwischen Teams und Systemen.
• Design nach einem Referenzmodell. Domänen und Entitäten folgen der Praxis des TM Forum; Datenschemata, Services und Dokumentation werden aus den Modellen generiert.
• Agile und automatisierte Tests. Kleine Pakete hinter Feature Flags wachsen zu größeren Funktionen zusammen.
• DevOps nach ITIL-Prozessen. Automatisiertes Deployment und Monitoring, ausgerichtet auf die Nutzung von Diensten und Entitäten.

Die Plattform arbeitet auch neben dem BSS eines anderen Anbieters: Anwendungen und Kanäle rufen sie über TM Forum Open API auf, und die Netzschicht sowie das OSS werden über unseren Teil erreicht. Entwicklung, Umsetzung und Support laufen unter einem Qualitätssystem nach ISO 9001.

Um das Gespräch zu beginnen, beantworten Sie den Fragebogen für Betreiber: einige Fragen zu Ihrem Unternehmen, Ihrem Kundenstamm, den Integrationspunkten und der Migration, damit wir eine erste Schätzung vorbereiten können. Vertiefende Fragen sind optional, oder wir gehen sie gemeinsam durch.