Ein Vertriebsprozess in jedem Kanal

Die Ablösung des Legacy-Backends selbst ist ein eigener Fall: Ein Legacy-Backend ablösen.

Platz in ODA

Auf dem ODA Canvas gehören CRM-Funktionen zur Domäne Party Management und der Pre-Sales-Bereich — Leads und Opportunities — zur Komponente Lead & Opportunity Management. CRM bleibt das führende System mit minimaler Anpassung. Jeder Kanal — Partnerportal, Vertriebs-App, Self-Care — erreicht die Backend-Prozesse nur über die Fassade auf der Enablement & Monetization Platform.

Komponenten der Fassade

• Standardschnittstelle Ein TM Forum Open API-Einstiegspunkt für jeden Kanal.
• Schema-Registry Kern und Erweiterungen, Versionen und Verträge; Schemas und Mappings ändern sich per Konfiguration.
• Datenproduktkatalog Party-, Sales-, Quote- und Agreement-Modelle als Produkte, mit Product Owner, Data Steward und Tech Lead.
• BPMN-Paket B2B-Regeln außerhalb des CRM: Unternehmensprüfungen, lokale steuerliche Anforderungen, öffentliche Register. MEF.DEV BPMN Low-code führt sie als versionierte Prozesse mit Wiederholungen, Kompensation und kontrollierten manuellen Schritten aus.
• Adapter ERP, Lager und Billing werden über den Einstiegspunkt angebunden, nicht Kanal für Kanal.

Verteilter Produktkatalog

• CRM Der kommerzielle Katalog: ProductOffering und Preise, gelesen über TMF620 Product Catalog.
• Telco- und Non-Telco-BSS/OSS Technische Kataloge von CFS (Customer Facing Service) und RFS (Resource Facing Service) sowie Ausführung über TMF641 Service Order und TMF652 Resource Order Management.
• Zerlegung Eine Product Order wird entlang der Katalogbeziehungen in Service- und Ressourcenaufträge zerlegt, gemäß dem TM Forum Use Case zur Auftragszerlegung.

Verträge nach Rollout-Phase

1. Kernvertrieb Vertriebsmanagement, vom Lead zur Opportunity, als BPMN-basierte Fassade; Datensätze in Standard-CRM-Entitäten; Kanäle über ein API-Gateway mit OAuth2/JWT und TLS; Integration des kommerziellen Katalogs nur lesend.
2. B2B-Identifikation TMF632 Party, Party-Rollen und rechtliche Vorabprüfungen; Anlage und Verknüpfung von Konten über Standard-CRM-APIs; Anstoß von Vereinbarungen; Audit, Logging und Event-Benachrichtigungen.
3. Erweiterungen Angebotsmanagement mit CPQ-Regeln über TMF620 Product Catalog; Verfügbarkeitsprüfung und Reservierung von MSISDN (Mobile Station International Subscriber Directory Number) bei Bedarf; Abgleich des Katalogs mit Product, CustomerFacingService und ResourceFacingService; Performance, Observability, Rollen und Richtlinien in der Fassade.
4. Optional E-Dokumente und E-Signatur, E-Rechnung über TMF678 Customer Bill Management oder außerhalb von TM Forum; Bundles, Rabattrichtlinien und kanalübergreifende Katalogsynchronisation; Analytics, SLA-Alarme, Multi-Tenancy und Partner-APIs; Produktbestellung mit Zerlegung über TMF641 Service Order und TMF652 Resource Order Management in einem externen BSS.

Neben CRM und Legacy

Lead-to-Order- und Order-to-Cash-Prozesse zwischen CRM und ERP, Lager und Billing laufen außerhalb des CRM:

• Zuverlässigkeit Retry- und Rollback-Richtlinien, kompensierende Schritte, Idempotenz an Adaptern und Queues.
• Transparenz Logs, Traces, Metriken und Korrelation von Anfragen über Systeme hinweg; Audit eingehender und ausgehender Events, Payloads und Entscheidungen.
• Sicherheit OAuth2/JWT, Workload Identity und Zugriffskontrolle auf Open API-Ebene; keine im CRM gespeicherten Secrets.
• Deployment Cloud oder on-premises, mit horizontal skaliertem Orchestrator und Queues auf Kubernetes.

Dies ist ein Zielszenario; der Umfang wird im Projekt Phase für Phase vereinbart.

Technische Details auf platform.mef.dev →