La plataforma estaba lista en el mes cuatro. El OMV (Operador Móvil Virtual) entró en funcionamiento en el mes once. Los siete meses intermedios se dedicaron casi por completo a integraciones: específicamente, a un adaptador de portabilidad numérica que no pasó las pruebas de certificación dos veces, y a una interfaz de aprovisionamiento HLR/HSS con el operador de red móvil (ORM) anfitrión que requirió tres rondas de alineación técnica porque el ORM había actualizado su red central entre la firma de la especificación y la ventana de pruebas.
El proveedor de BSS no tuvo la culpa. La plataforma en sí funcionaba correctamente desde el mes cuatro. El gestor del proyecto había construido el plan de entrega en torno a los hitos de la plataforma. Las integraciones se trataron como un flujo de trabajo que "se ejecutaría en paralelo". Y así fue, hasta que el flujo de trabajo paralelo se convirtió en la ruta crítica y se mantuvo así durante siete meses.
Esta es la fuente más común de retrasos en el lanzamiento de un OMV. También es la que menos se anticipa al inicio del proyecto. La capacidad de la plataforma es visible y evaluable. El alcance de la integración es difuso, depende de terceros con sus propios cronogramas y es genuinamente desagradable de detallar antes de firmar un contrato. Por lo tanto, tiende a no evaluarse adecuadamente.
Qué necesita conectarse realmente
Un OMV se sitúa entre la red del ORM anfitrión y sus propios suscriptores. La plataforma BSS gestiona la relación con el suscriptor (facturación, productos, ciclo de vida), pero no puede operar de forma aislada. Necesita comunicarse con la red del ORM, con los sistemas regulatorios, con las plataformas comerciales del OMV y con la infraestructura operativa. Cada conexión es un proyecto independiente.
Interfaces de red del ORM
La integración más crítica es el HLR/HSS: la base de datos que asigna cada SIM a su perfil de servicio activo en la red anfitriona. Cuando un suscriptor se activa, cambia su plan o es suspendido, el BSS del OMV debe enviar una instrucción de aprovisionamiento al HLR/HSS del ORM y recibir confirmación. Esta no es una simple llamada a una API. La interfaz utiliza protocolos de señalización SS7 o Diameter, y el ORM tiene su propio proceso de control de cambios de ingeniería. Reservar un espacio de prueba en el calendario de ingeniería de red del ORM suele llevar de 6 a 12 semanas después de acordar la especificación técnica, independientemente de lo rápido que esté lista la parte del OMV.
Más allá del HLR/HSS, puede haber integración PCRF para la gestión de políticas de sesiones de datos, SMS-C para el enrutamiento de mensajes y pasarela USSD para mercados donde el autoservicio basado en USSD es estándar. Esto incluye la mayor parte del África subsahariana y partes de Oriente Medio, donde las recargas y consultas de saldo basadas en USSD son el principal canal de interacción del suscriptor.
Interfaces regulatorias
La portabilidad numérica es el comodín en la mayoría de los proyectos OMV. En los mercados con portabilidad numérica móvil, el OMV debe integrarse con la cámara de compensación nacional y completar las pruebas de certificación antes de portar el número de cualquier suscriptor. Los espacios de certificación se reservan a través del organismo regulador en su propio calendario. En algunos mercados, el próximo espacio disponible está a 8 o 12 semanas de distancia en cualquier momento dado. En los mercados donde la portabilidad numérica es relativamente reciente (partes del Golfo, varios mercados africanos), las interfaces son menos maduras y los procesos de certificación más complejos.
El KYC añade otra dependencia. La mayoría de los mercados exigen la verificación de la identidad del suscriptor en el momento de la activación, y el enfoque técnico varía: carga de documentos con revisión manual, verificación biométrica en tiempo real o integración con bases de datos de identidad nacionales. Cada proveedor tiene su propio entorno de pruebas (sandbox) y proceso de certificación, y estos no se rigen por el cronograma del proyecto del OMV.
Sistemas comerciales y de negocio
CRM, ERP, pasarelas de pago, sistemas de gestión de distribuidores: estos tienden a considerarse de menor riesgo porque los equipos tecnológicos involucrados están más familiarizados con ellos. Las pasarelas de pago, en particular, parecen sencillas sobre el papel. APIs REST, bien documentadas. En la práctica, cada proveedor de pagos tiene sus propias reglas contra el fraude, sus propios requisitos de certificación para nuevos comerciantes y un sandbox que puede comportarse de manera diferente al entorno de producción. En los mercados donde el dinero móvil es el principal canal de recarga (M-Pesa, Orange Money, MTN MoMo), las especificaciones de integración y los procesos de aprobación son específicos del proveedor y no se pueden asumir a partir de la experiencia previa con otros sistemas de pago.
Roaming
Configurar el roaming requiere acuerdos bilaterales con redes asociadas, registro en los sistemas de compensación de la GSMA (TAP/NRTRDE para compensación, GRX o IPX para transporte de datos) y pruebas en vivo con un conjunto representativo de redes asociadas. Las negociaciones comerciales, la configuración técnica y las pruebas combinadas tardan de cuatro a seis meses para una capacidad básica de roaming. A menudo, el roaming se aplaza para después del lanzamiento para gestionar el riesgo inicial del cronograma. Para los OMV en los que es fundamental para su propuesta (enfocados en empresas, en la diáspora o con doble SIM), esta es una decisión de secuenciación con consecuencias comerciales que debe ser explícita en el plan del proyecto, no implícita.
Por qué las diferentes categorías de integración fallan de distintas maneras
Las interfaces de red del ORM suelen estar bien documentadas (el ORM ya lo ha hecho antes), pero dependen del calendario de la organización de ingeniería del ORM. El OMV no puede acelerar el proceso de control de cambios interno del ORM. La única mitigación es comenzar la alineación técnica antes de lo que parece necesario y colocar una especificación completa en la cola del ORM antes de que se finalice el plan general del proyecto.
Las integraciones regulatorias fallan por factores ajenos al control de cualquiera: disponibilidad de espacios de certificación, cambios en la interfaz realizados por el organismo regulador, fallos en las pruebas que requieren una nueva posición en la cola en lugar de una simple repetición de la prueba. Los fallos en la portabilidad numérica son particularmente costosos porque normalmente bloquean por completo el lanzamiento comercial. Un OMV que no puede portar números no puede captar suscriptores de las redes de la competencia.
Las integraciones comerciales fallan por una razón diferente: la desviación del alcance. La integración del CRM que era "una simple sincronización de datos" se vuelve más compleja cuando el modelo de datos no se asigna limpiamente a los registros de suscriptores del BSS, o cuando la frecuencia de sincronización requerida crea problemas de rendimiento bajo carga. Las integraciones de ERP siguen el mismo patrón: los requisitos de informes financieros que parecían claros en la etapa de especificación adquieren complejidad cuando el manejo de los ciclos de facturación multiperiodo del BSS se encuentra con la lógica contable del ERP.
Qué significa realmente "integración preconstruida"
Los proveedores de plataformas OMV afirman rutinariamente tener grandes bibliotecas de integración. Es común ver 200 o más integraciones preconstruidas en los materiales del proveedor. Entender lo que esto significa en la práctica requiere hacer preguntas más específicas.
Hay una diferencia real entre:
- Un conector construido para la implementación de un cliente anterior, que se encuentra en la base de código del proveedor, y que no se ha implementado desde entonces.
- Un conector mantenido activamente, certificado contra la versión actual del sistema externo, implementado en producción en múltiples clientes.
- Algo que el proveedor confía en poder construir, basándose en su experiencia con interfaces similares.
El primero requiere un ejercicio de evaluación antes de que nadie sepa si es adecuado para su propósito. El segundo puede tratarse como un activo reutilizable. El tercero es un proyecto de integración personalizado con un cronograma de entrega y un perfil de riesgo, independientemente de cómo se describa en la conversación de ventas.
Cuatro preguntas que distinguen entre estas categorías:
- ¿Cuántas implementaciones en producción actuales tiene este conector específico?
- ¿Contra qué versión de la API del sistema externo está certificado y cuándo se actualizó por última vez?
- Cuando el sistema externo publica un cambio en la API, ¿quién es responsable del mantenimiento del conector: el proveedor de la plataforma o el cliente?
- ¿Está incluido este conector en la licencia estándar de la plataforma o se evalúa y presupuesta por separado para cada implementación?
Para las integraciones críticas para el despliegue (aprovisionamiento HLR/HSS, portabilidad numérica, pasarela de pago principal), estas preguntas deben tener respuestas específicas antes de firmar el contrato.
Construyendo un cronograma que refleje la realidad
La mayoría de los cronogramas de proyectos OMV se construyen en torno a los hitos de entrega de la plataforma. El proveedor de la plataforma conoce su propia capacidad de entrega y presupuesta en consecuencia. Los cronogramas de integración de terceros se estiman, por lo general, de manera optimista.
Un cronograma construido en torno a las rutas críticas de integración se ve diferente. Rangos realistas para tipos de integración comunes (las duraciones reales varían según el mercado y el proveedor):
- Interfaz de aprovisionamiento HLR/HSS con el ORM anfitrión: de 8 a 14 semanas desde la firma de la especificación hasta la finalización confirmada de las pruebas, dependiendo del calendario de ingeniería del ORM.
- Certificación de portabilidad numérica: de 10 a 20 semanas, dependiendo de la disponibilidad del organismo regulador y de la tasa de aprobación al primer intento.
- Pasarela de pago principal: de 4 a 8 semanas desde el acceso al sandbox hasta la certificación en producción.
- Configuración de roaming (capacidad bilateral básica): de 16 a 24 semanas desde el acuerdo comercial hasta las pruebas en vivo.
- Integración KYC: de 4 a 10 semanas, dependiendo en gran medida del proveedor y del mercado.
Un gestor de proyectos que trabaje para un lanzamiento a 6 meses necesita verificar en la etapa de planificación que la ventana de pruebas de HLR/HSS se pueda reservar entre las semanas 6 y 10, que la certificación de portabilidad numérica se pueda completar antes del mes 5 y que no se requiera capacidad de roaming en el lanzamiento. Si alguna de esas suposiciones no se cumple, el cronograma tampoco se cumplirá.
Debida diligencia de integración antes del inicio del proyecto
Estas son las preguntas que revelan el riesgo de integración antes de asumir un compromiso de entrega:
Del lado del ORM:
- ¿Cuál es el tiempo de espera típico desde el acuerdo de la especificación técnica hasta la disponibilidad de la ventana de pruebas en su HLR/HSS?
- ¿Están previstas actualizaciones de la red central durante el periodo de implementación?
En las interfaces regulatorias:
- ¿Cuál es el tiempo de espera actual para un espacio de certificación de portabilidad numérica en este mercado?
- ¿Ha realizado el organismo regulador cambios en la interfaz en los últimos 18 meses?
En la biblioteca de integración del proveedor de la plataforma:
- Para cada integración crítica en este despliegue, ¿cuántas instancias de producción actuales tiene el conector?
- ¿Qué integraciones requieren un desarrollo a medida y qué añade eso al cronograma de entrega?
Sobre el roaming:
- ¿Se requiere capacidad de roaming básica en el lanzamiento comercial o puede seguir en un plazo de tres a seis meses?
- ¿Quién gestiona el registro de compensación de la GSMA y el proceso de acuerdo bilateral?
Cómo Avante MVNx Suite aborda esto
Avante MVNx Suite incluye una biblioteca de conectores preconstruidos que cubren interfaces de red de ORMs, adaptadores de portabilidad numérica en múltiples mercados, pasarelas de pago y dinero móvil, e integraciones de compensación de roaming. La metodología de implementación de Avante incluye una fase de evaluación de la integración antes de que se finalice la planificación del proyecto, para identificar qué conectores son reutilizables de implementaciones anteriores y cuáles requieren un desarrollo a medida, y para construir cronogramas que reflejen las dependencias de los calendarios de terceros en lugar de solo los hitos de la plataforma. Los conectores en la biblioteca de integración de MVNx Suite representan despliegues activos en más de 20 entornos de operadores, no implementaciones históricas aisladas.
Preguntas frecuentes
¿Por qué las integraciones de los OMV tardan más de lo que indica el plan del proyecto?
Por lo general, es una combinación de tres cosas. Cronogramas de terceros que el proyecto no puede controlar: la cola de ingeniería del ORM, el calendario de certificación del organismo regulador, el proceso de aprobación de comerciantes del proveedor de pagos. Brechas en las especificaciones que solo se hacen visibles cuando se examinan las interfaces reales de los sistemas. Y fallos de certificación al primer intento, que reinician la posición en la cola en lugar de permitir un reintento inmediato. Cada uno de estos factores es predecible en abstracto, pero aún así logra tomar por sorpresa a los proyectos en la práctica.
¿Qué distingue realmente a un conector preconstruido de una integración personalizada?
Un verdadero conector preconstruido se ha implementado en producción antes, es mantenido por el proveedor de la plataforma con la versión actual de la API del sistema externo y se puede configurar para un nuevo despliegue en lugar de volver a desarrollarse. Una integración personalizada comienza a partir de un código que no se ha implementado en ese contexto, lo que significa que el ciclo de desarrollo, prueba y certificación se ejecuta en el cronograma del proyecto. La diferencia práctica en el tiempo de entrega suele ser de 4 a 8 semanas para un conector configurado frente a las 8 a 20 semanas para un desarrollo a medida.
¿Cuál es la forma más efectiva de reducir el riesgo de integración antes del inicio del proyecto?
Comience la alineación de la interfaz del ORM y la consulta de certificación de portabilidad numérica antes de firmar el contrato de la plataforma. Ambos son elementos de largo plazo con dependencias de cronogramas de terceros, y descubrir que el próximo espacio de certificación disponible está a 14 semanas de distancia es información útil antes de hacer compromisos en el proyecto, no después.