La plataforma estaba lista en el cuarto mes. El MVNO se lanzó en el undécimo. Los siete meses intermedios se dedicaron casi por completo a las integraciones: en concreto, a un adaptador de portabilidad numérica que suspendió dos veces la certificación y a una interfaz de aprovisionamiento HLR/HSS con el operador anfitrión que exigió tres rondas de alineación técnica, porque el operador había actualizado su núcleo de red entre la aprobación de las especificaciones y la ventana de pruebas.
El proveedor del BSS no tuvo la culpa. La plataforma funcionaba correctamente desde el cuarto mes. El jefe de proyecto había construido el plan de entrega en torno a los hitos de la plataforma. Las integraciones se trataron como un frente paralelo que iba a « avanzar en paralelo ». Y así fue, hasta que ese frente se convirtió en la ruta crítica y permaneció ahí siete meses.
Es la causa más frecuente de retraso en los lanzamientos de MVNO. También es la que menos se anticipa al arrancar el proyecto. La capacidad de la plataforma es visible y evaluable. El alcance de las integraciones, en cambio, es difuso, depende de terceros con su propio calendario y resulta francamente incómodo de acotar en detalle antes de firmar un contrato. Por eso rara vez se acota bien.
Qué hay que conectar realmente
Un MVNO se sitúa entre la red del operador anfitrión y sus propios abonados. La plataforma BSS gestiona la relación con el abonado — facturación, productos, ciclo de vida — pero no puede operar aislada. Necesita comunicarse con la red del operador, con los sistemas regulatorios, con las plataformas comerciales del MVNO y con la infraestructura operativa. Cada conexión es un proyecto en sí mismo.
Interfaces con la red del operador anfitrión
La integración más crítica es la del HLR/HSS, la base que asocia cada SIM a su perfil de servicio activo en la red anfitriona. Cuando un abonado se activa, cambia de plan o queda suspendido, el BSS del MVNO debe enviar una instrucción de aprovisionamiento al HLR/HSS del operador y recibir la confirmación. No es una simple llamada a una API. La interfaz se apoya en los protocolos de señalización SS7 o Diameter, y el operador aplica su propio proceso de control de cambios. Reservar una franja de pruebas en el calendario de ingeniería de red del operador suele llevar de 6 a 12 semanas desde que se acuerdan las especificaciones técnicas, por rápido que vaya el MVNO por su lado.
Más allá del HLR/HSS puede haber integración con el PCRF para la gestión de políticas de sesión de datos, con el SMS-C para el enrutamiento de mensajes y con una pasarela USSD en los mercados donde el autoservicio por USSD es el estándar. Es el caso de buena parte del África subsahariana y de zonas de Oriente Medio, donde la recarga y la consulta de saldo por USSD son el principal canal de interacción con el abonado.
Interfaces regulatorias
La portabilidad numérica es la incógnita de la mayoría de los proyectos MVNO. En los mercados que la aplican, el MVNO debe integrarse con la cámara de compensación nacional y superar la certificación antes de portar un solo número. Las franjas de certificación se reservan ante el organismo regulador, según su propio calendario. En algunos mercados, la siguiente franja disponible está a 8 o 12 semanas en cualquier momento. Donde la portabilidad es reciente — parte del Golfo, varios mercados africanos — las interfaces son menos maduras y los procesos de certificación más pesados.
El KYC añade otra dependencia. La mayoría de los mercados exige verificar la identidad del abonado en 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 identidad nacionales. Cada proveedor tiene su entorno de pruebas y su proceso de certificación, y ninguno se ajusta al calendario del proyecto.
Sistemas comerciales y de gestión
CRM, ERP, pasarela de pago, gestión de distribuidores: suelen considerarse de menor riesgo porque los equipos técnicos los conocen mejor. Las pasarelas de pago, en particular, parecen sencillas sobre el papel. API REST, bien documentadas. En la práctica, cada proveedor tiene sus propias reglas antifraude, sus requisitos de certificación para un nuevo comercio y un entorno de pruebas que puede comportarse de forma distinta a 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 propios de cada proveedor y no se deducen de la experiencia con otros sistemas de pago.
Roaming
Poner en marcha el roaming exige acuerdos bilaterales con las redes socias, el registro en los sistemas de compensación de la GSMA (TAP/NRTRDE para el clearing, GRX o IPX para el transporte de datos) y pruebas reales con una muestra representativa de socios. Las negociaciones comerciales, la puesta en marcha técnica y las pruebas suman entre cuatro y seis meses para una capacidad de roaming básica. El roaming suele aplazarse a después del lanzamiento para contener el riesgo del calendario inicial. En los MVNO donde pesa en la propuesta de valor — enfoque empresarial, diáspora o doble SIM — esa decisión de secuencia tiene consecuencias comerciales que deben figurar de forma explícita en el plan de proyecto.
Por qué cada categoría de integración falla de una manera distinta
Las interfaces con la red del operador suelen estar bien documentadas — el operador ya lo ha hecho antes — pero dependen del calendario de su organización de ingeniería. El MVNO no puede acelerar el control de cambios interno del operador. La única mitigación es iniciar la alineación técnica antes de lo que parece necesario y colocar una especificación cerrada en la cola del operador antes de fijar el plan de proyecto.
Las integraciones regulatorias fallan por factores fuera del control de todos: disponibilidad de franjas de certificación, cambios de interfaz decididos por el regulador, fallos de prueba que devuelven al final de la cola en lugar de permitir un simple reintento. Los fallos en portabilidad salen especialmente caros porque suelen bloquear el lanzamiento comercial por completo. Un MVNO que no puede portar números entrantes no puede captar abonados de las redes competidoras.
Las integraciones comerciales fallan por otro motivo: la desviación de alcance. La integración con el CRM presentada como « una simple sincronización de datos » se complica cuando el modelo de datos no encaja limpiamente con las fichas de abonado del BSS, o cuando la frecuencia de sincronización requerida genera problemas de rendimiento bajo carga. Las integraciones con el ERP siguen el mismo patrón: requisitos de reporting financiero que parecían claros en la fase de especificación ganan complejidad cuando el tratamiento de ciclos de facturación multiperiodo del BSS se encuentra con la lógica contable del ERP.
Qué significa realmente « conector preintegrado »
Los proveedores de plataformas MVNO presumen habitualmente de amplias bibliotecas de integraciones. Doscientos conectores preintegrados o más es una cifra frecuente en los materiales comerciales. Entender qué significa en la práctica exige preguntas más concretas.
Hay una diferencia real entre:
- un conector construido para un cliente anterior, presente en el código del proveedor y sin desplegar desde entonces
- un conector mantenido de forma activa, certificado contra la versión actual del sistema externo y desplegado en producción en varios clientes
- algo que el proveedor confía en poder construir, a partir de su experiencia con interfaces similares
El primero obliga a un ejercicio de acotación antes incluso de saber si sirve. El segundo puede tratarse como un activo reutilizable. El tercero es un proyecto de integración a medida, con su plazo de entrega y su perfil de riesgo, se describa como se describa en la conversación comercial.
Cuatro preguntas permiten distinguir estas categorías:
- ¿Cuántos despliegues en producción tiene hoy este conector concreto?
- ¿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 de API, ¿quién asume el mantenimiento del conector: el proveedor de la plataforma o el cliente?
- ¿Está este conector incluido en la licencia estándar de la plataforma o se acota y factura por separado en cada implantación?
Para las integraciones críticas del despliegue — aprovisionamiento HLR/HSS, portabilidad numérica, pasarela de pago principal — estas preguntas deben tener respuestas concretas antes de firmar el contrato.
Construir un calendario que se sostenga
La mayoría de los calendarios de proyecto MVNO se construyen en torno a los hitos de entrega de la plataforma. El proveedor conoce su propia capacidad de entrega y se compromete en consecuencia. Los plazos de las integraciones de terceros se estiman, casi siempre con optimismo.
Un calendario construido en torno a las rutas críticas de integración tiene otro aspecto. Estos son rangos realistas para los tipos de integración habituales; la duración real varía según el mercado y el proveedor:
- Interfaz de aprovisionamiento HLR/HSS con el operador anfitrión: de 8 a 14 semanas desde la aprobación de especificaciones hasta la finalización confirmada de las pruebas, según el calendario de ingeniería del operador
- Certificación de portabilidad numérica: de 10 a 20 semanas, según la disponibilidad del regulador y el índice de aprobación a la primera
- Pasarela de pago principal: de 4 a 8 semanas desde el acceso al entorno de pruebas hasta la certificación en producción
- Puesta en marcha del roaming (capacidad bilateral básica): de 16 a 24 semanas desde el acuerdo comercial hasta las pruebas reales
- Integración KYC: de 4 a 10 semanas, muy dependiente del proveedor y del mercado
Un jefe de proyecto que apunte a un lanzamiento en seis meses debe verificar ya en la planificación que la ventana de pruebas del HLR/HSS puede reservarse entre las semanas 6 y 10, que la certificación de portabilidad puede completarse antes del quinto mes y que no se requiere capacidad de roaming en el lanzamiento. Si alguna de esas premisas no se cumple, el calendario tampoco se sostiene.
Due diligence de integraciones antes de arrancar
Estas son las preguntas que sacan a la luz el riesgo de integración antes de comprometer una entrega:
Del lado del operador anfitrión:
- ¿Cuál es el plazo habitual entre el acuerdo de especificaciones técnicas y la disponibilidad de una ventana de pruebas en su HLR/HSS?
- ¿Hay actualizaciones del núcleo de red previstas durante el periodo de implantación?
Sobre las interfaces regulatorias:
- ¿Cuál es la espera actual para una franja de certificación de portabilidad en este mercado?
- ¿Ha modificado el regulador sus interfaces en los últimos dieciocho meses?
Sobre la biblioteca de integraciones del proveedor:
- Para cada integración crítica de este despliegue, ¿cuántas instancias en producción tiene hoy el conector?
- ¿Qué integraciones requieren desarrollo a medida y cuánto añaden al calendario de entrega?
Sobre el roaming:
- ¿Se requiere capacidad de roaming básica en el lanzamiento comercial o puede llegar en un plazo de tres a seis meses?
- ¿Quién gestiona el registro en los sistemas de compensación de la GSMA y el proceso de acuerdos bilaterales?
Cómo aborda esto Avante MVNx Suite
Avante MVNx Suite incluye una biblioteca de conectores preintegrados que cubre interfaces de red de operadores, adaptadores de portabilidad numérica en varios mercados, pasarelas de pago y de dinero móvil, e integraciones de compensación para roaming. La metodología de implantación de Avante contempla una fase de acotación de integraciones antes de cerrar la planificación del proyecto: identifica qué conectores son reutilizables de despliegues anteriores y cuáles exigen desarrollo a medida, y construye calendarios que reflejan las dependencias de terceros y no solo los hitos de la plataforma. Los conectores de la biblioteca de MVNx Suite corresponden a despliegues activos en más de veinte entornos de operador, no a implantaciones puntuales del pasado.
Preguntas frecuentes
¿Por qué las integraciones MVNO tardan más de lo que dice el plan de proyecto?
Normalmente por la combinación de tres cosas. Calendarios de terceros que el proyecto no controla: la cola de ingeniería del operador, la agenda de certificación del regulador, el proceso de aprobación de comercio del proveedor de pagos. Huecos en las especificaciones que solo se ven cuando se examinan las interfaces reales. Y fallos de certificación a la primera, que devuelven al final de la cola en lugar de permitir un reintento inmediato. Cada uno es previsible en abstracto y aun así pilla a los proyectos a contrapié en la práctica.
¿Qué distingue de verdad a un conector preintegrado de una integración a medida?
Un conector preintegrado real ya se ha desplegado en producción, lo mantiene el proveedor contra la versión actual de la API del sistema externo y se configura para un nuevo despliegue en lugar de volver a desarrollarse. Una integración a medida parte de código que nunca se ha desplegado en ese contexto, de modo que el ciclo de desarrollo, pruebas y certificación corre sobre el calendario del proyecto. La diferencia práctica en tiempo de entrega suele ser de 4 a 8 semanas para un conector configurado frente a 8 a 20 semanas para un desarrollo a medida.
¿Cuál es la forma más eficaz de reducir el riesgo de integración antes de arrancar?
Iniciar la alineación de interfaces con el operador y la consulta de certificación de portabilidad antes de firmar el contrato de plataforma. Son dos elementos de plazo largo con dependencias de calendario de terceros, y saber que la siguiente franja de certificación está a catorce semanas es información útil antes de asumir compromisos, no después.