Un solo proceso de venta en todos los canales

El reemplazo del propio backend legacy es un caso aparte: Sustituir un backend legacy.

Lugar en ODA

En el ODA Canvas, las funciones de CRM pertenecen al dominio Party Management, y la preventa — leads y oportunidades — al componente Lead & Opportunity Management. El CRM sigue siendo el sistema de registro maestro con una personalización mínima. Cada canal — portal de socios, aplicación de ventas, autoservicio — accede a los procesos de backend solo a través de la fachada sobre Enablement & Monetization Platform.

Componentes de la fachada

• Interfaz estándar Un único punto de entrada TM Forum Open API para todos los canales.
• Registro de esquemas Núcleo y extensiones, versiones y contratos; los esquemas y los mappings cambian por configuración.
• Catálogo de productos de datos Los modelos Party, Sales, Quote y Agreement como productos, con un product owner, un data steward y un tech lead.
• Paquete BPMN Reglas B2B fuera del CRM: verificaciones corporativas, requisitos fiscales locales, registros públicos. MEF.DEV BPMN Low-code las ejecuta como procesos versionados con reintentos, compensación y pasos humanos controlados.
• Adaptadores ERP, almacén y billing se conectan a través del punto de entrada, no canal por canal.

Catálogo de productos distribuido

• CRM El catálogo comercial: ProductOffering y precios, leídos mediante TMF620 Product Catalog.
• BSS/OSS telco y no telco Catálogos técnicos de CFS (Customer Facing Service) y RFS (Resource Facing Service), y ejecución mediante TMF641 Service Order y TMF652 Resource Order Management.
• Descomposición Una product order se descompone en órdenes de servicio y de recurso según las relaciones del catálogo, siguiendo el use case de descomposición de órdenes de TM Forum.

Contratos por fase de despliegue

1. Ventas básicas Gestión de ventas, de lead a oportunidad, como fachada basada en BPMN; registros en entidades estándar del CRM; canales a través de un API gateway con OAuth2/JWT y TLS; integración de solo lectura del catálogo comercial.
2. Identificación B2B TMF632 Party, roles de las partes y verificaciones legales previas; creación y vinculación de cuentas mediante las APIs estándar del CRM; inicio del acuerdo; auditoría, registros y notificaciones de eventos.
3. Extensiones Gestión de cotizaciones con reglas CPQ sobre TMF620 Product Catalog; disponibilidad y reserva de MSISDN (Mobile Station International Subscriber Directory Number) cuando se requiera; alineación del catálogo con Product, CustomerFacingService y ResourceFacingService; rendimiento, observabilidad, roles y políticas en la fachada.
4. Opcional Documentos y firma electrónicos, factura electrónica mediante TMF678 Customer Bill Management o fuera de TM Forum; paquetes, políticas de descuento y sincronización del catálogo entre canales; analítica, alertas de SLA, multi-tenancy y APIs de socios; pedidos de productos con descomposición mediante TMF641 Service Order y TMF652 Resource Order Management en un BSS externo.

Junto al CRM y los sistemas legacy

Los procesos Lead-to-Order y Order-to-Cash entre el CRM y el ERP, el almacén y el billing residen fuera del CRM:

• Fiabilidad Políticas de reintento y rollback, pasos de compensación, idempotencia en los adaptadores y las colas.
• Transparencia Registros, trazas, métricas y correlación de solicitudes entre sistemas; auditoría de eventos entrantes y salientes, payloads y decisiones.
• Seguridad OAuth2/JWT, workload identity y control de acceso a nivel de Open API; no se almacenan secretos en el CRM.
• Despliegue En la nube u on-premises, con el orquestador y las colas escalados horizontalmente en Kubernetes.

Este es un escenario objetivo; el alcance se acuerda en el proyecto, fase por fase.

Detalle técnico en platform.mef.dev →