1. Enmarcar la cuestión de la adquisición
La cuestión de la adquisición es cuánto debería pagar hoy un comprador por un negocio de automatización de redes cuya propuesta se extiende desde las operaciones actuales 4G y 5G hasta AI-RAN y la futura arquitectura 6G. La respuesta exige varias valoraciones dentro de una misma transacción. Los ingresos existentes por suscripción y servicios pueden evaluarse mediante contratos, márgenes, retención y conversión de efectivo. Los beneficios operativos para el cliente requieren atribución técnica. La portabilidad requiere evidencia en distintas redes y proveedores. La participación futura en estándares crea una opción cuyas condiciones de ejercicio siguen siendo inciertas.
Un comprador disciplinado comienza con el problema operativo resuelto. La automatización de redes puede mejorar el consumo energético, la capacidad, el rendimiento, la calidad, la gestión de fallos, la productividad de la planificación o de la ingeniería. Cada caso de uso tiene un requisito de datos, un intervalo de decisión, una carga de integración y una consecuencia de fallo diferentes. Un producto que recomienda un cambio de configuración semanal es económica y operativamente distinto de un controlador en bucle cerrado que actúa en segundos.
La tesis de la transacción debe indicar qué casos de uso crean valor, dónde aparece ese valor, quién lo recibe y qué evidencia lo demuestra. El comprador puede entonces comprobar si la empresa objetivo posee un producto, una práctica de integración, datos propios, un flujo de trabajo específico del cliente o un conjunto de componentes de terceros.
Tabla 1. Capas de valor de la automatización de redes y tratamiento de la transacción
| Capa de valor | Evidencia actual | Pregunta principal de diligencia debida | Tratamiento de la transacción |
|---|---|---|---|
| Software contratado | Ingresos recurrentes firmados e historial de renovaciones | ¿Sobreviven los ingresos a los cambios de propiedad y de proveedor? | Valor empresarial base |
| Mejora operativa | KPI de red medidos y efecto en costes | ¿Es el contrafactual creíble y persistente? | Incremento validado o earn-out |
| Desplegabilidad | Despliegues repetidos y registros de integración | ¿Puede el producto funcionar con distintos operadores y stacks tecnológicos? | Prima de portabilidad |
| Datos y modelos | Derechos legales, linaje y reproducibilidad | ¿Puede el comprador continuar con el entrenamiento y la operación? | Valor del activo sujeto a derechos |
| Posición en el ecosistema | Contribuciones a estándares y aceptación por parte de socios | ¿Se traduce la influencia en adopción? | Opción estratégica |
| Preparación para 6G | Arquitectura alineada con los estándares y pruebas | ¿Qué capacidad existe antes del 6G comercial? | Opción con tope y basada en hitos |
Cada capa requiere evidencia, análisis económico y tratamiento del riesgo por separado.
2. Separar el valor actual del valor de opción futuro
El valor actual procede de productos que los operadores despliegan, pagan y renuevan. Incluye ingresos recurrentes por software, ingresos de implementación que respaldan la adopción y beneficios medibles para el cliente que mejoran la renovación o la expansión. El valor de opción futuro procede de capacidades que pueden resultar útiles a medida que maduran las interfaces, las arquitecturas, los acuerdos de espectro y los planes de inversión de los operadores.
La separación evita una tesis circular. Una empresa objetivo no puede justificar un precio elevado mediante un mercado futuro y luego usar el precio como prueba de que ese mercado existe. El comprador debe identificar el producto actual, el cliente actual, la decisión actual y el beneficio económico actual. Las funcionalidades futuras pertenecen a un registro de opciones separado con desencadenantes, condiciones de expiración y requisitos adicionales de capital.
El valor de opción es máximo cuando la plataforma actual genera aprendizaje que sigue siendo útil a lo largo de generaciones de estándares. La capacidad de ingeniería de datos, la gobernanza de modelos, las herramientas de integración y la confianza del operador pueden perdurar. Una afirmación vinculada a una interfaz provisional o a una implementación limitada de un proveedor puede deteriorarse. El comprador debería pagar por capacidad transferible en lugar de por una etiqueta.
3. Comprender el calendario de los estándares
El calendario de los estándares establece límites en torno a la certeza técnica. La Recomendación M.2160 de la UIT-R describe el marco IMT-2030 y seis escenarios de uso. La UIT informó en marzo de 2026 de que se había acordado el borrador de requisitos técnicos de rendimiento para veinte requisitos, incluidos siete nuevos, y de que se espera la aprobación formal en diciembre de 2026. La metodología de evaluación y el trabajo sobre tecnologías candidatas continúan dentro del proceso internacional.
Este calendario importa porque las descripciones comerciales pueden ir por delante de los requisitos técnicos aprobados y de los sistemas desplegables. Una empresa objetivo puede realizar investigación relevante para 6G sin disponer de un producto 6G. También puede crear un valor significativo en las redes actuales mediante técnicas que probablemente persistan en las generaciones futuras.
El equipo de diligencia debida debería elaborar una matriz de estándares. Cada característica material debería asignarse a una especificación aprobada, un elemento en borrador, un concepto de investigación o una implementación propietaria. La matriz debería indicar la interfaz, la versión, la dependencia y el riesgo de cambio previsto. La valoración debería seguir la madurez de la dependencia subyacente.
4. Distinguir los significados de AI-RAN
AI-RAN puede describir el uso de AI para mejorar la red de radio, cargas de trabajo de AI que comparten cómputo de red, o capacidad de red diseñada para dar servicio a aplicaciones de AI. Estas propuestas tienen clientes, activos y economías distintas. Un caso de adquisición debería indicar qué significado se aplica a cada producto.
AI para RAN incluye previsión de tráfico, gestión energética, optimización de movilidad, detección de anomalías, planificación de capacidad y control de parámetros. AI y RAN pueden combinar cargas de trabajo de telecomunicaciones y de cómputo acelerado en una infraestructura común. AI sobre RAN puede referirse a inferencia distribuida o a servicios habilitados mediante el alcance de la red. Una empresa objetivo puede participar en más de una categoría, pero el comprador no debería fusionar sus mercados direccionables.
La documentación de producto, los contratos y los diagramas de despliegue deberían utilizar una terminología coherente. Cuando la dirección utilice una etiqueta amplia, el equipo de diligencia debida debería traducirla a entradas de datos, salidas de modelos, acciones de red, dependencias de hardware, niveles de servicio y unidades facturadas.
5. Mapear la arquitectura de control
La arquitectura de control muestra cómo las observaciones se convierten en acciones. La telemetría puede proceder de células, radios, equipos de usuario, transporte, funciones de núcleo, sistemas de energía y sistemas de soporte operativo. Se normaliza y se somete a gobernanza antes de que los modelos o las políticas la utilicen. Las acciones pueden regresar a través de la gestión de servicios y la orquestación, controladores no en tiempo real, controladores casi en tiempo real o sistemas específicos de proveedores.
La arquitectura de O-RAN distingue entre funciones no en tiempo real y casi en tiempo real, y define interfaces como A1, R1 y E2. Las aplicaciones no en tiempo real pueden respaldar políticas, entrenamiento de modelos y optimización a más largo horizonte. Las aplicaciones casi en tiempo real pueden influir en el comportamiento de la red a intervalos más cortos. La ubicación real de la empresa objetivo en la arquitectura determina los requisitos de latencia, integración y seguridad.
El comprador debería trazar un caso de uso de extremo a extremo. El trazado debería identificar cada fuente de datos, transformación, interfaz, decisión, salvaguarda y acción de red. Los eslabones faltantes revelan dónde los servicios humanos o las herramientas de proveedores establecidos completan el producto.
La diligencia debida sigue una decisión desde la telemetría gobernada, pasando por modelos y políticas, hasta una acción de red reversible.
6. Construir una escalera de evidencia
Una escalera de evidencia evita que una demostración prometedora reciba el mismo peso que una economía de producción repetible. El primer peldaño es la evidencia de simulación o de laboratorio. El segundo es una prueba de campo controlada. El tercero es una prueba en red comercial con alcance definido. El cuarto es un despliegue de producción limitado. El quinto es el rendimiento repetido a lo largo de periodos, regiones, configuraciones y operadores.
Cada peldaño debe registrar quién diseñó la prueba, quién controló la línea base, qué tráfico y hardware se incluyeron, cuánto duró la observación y si se midieron resultados adversos. Los estudios de caso de proveedores y operadores pueden demostrar viabilidad. Requieren una reproducción específica de la transacción antes de respaldar una prima de adquisición significativa.
La evidencia puede moverse tanto hacia abajo como hacia arriba. Un modelo puede funcionar tras el despliegue y degradarse cuando cambian el tráfico, los dispositivos, el software o las configuraciones de radio. La empresa objetivo debe demostrar monitorización, reentrenamiento, aprobación y reversión. El comprador está adquiriendo un sistema de rendimiento, no un resultado de precisión estático.
7. Establecer el contrafactual
El contrafactual es el resultado que se habría producido sin el producto de la empresa objetivo. Puede ser un área de control emparejada, un switchback aleatorizado, un despliegue por fases, un periodo comparable o un modelo de ingeniería. Una simple comparación antes y después puede atribuir erróneamente al software el clima, el tráfico, la renovación de hardware, los cambios de espectro u otra optimización.
El equipo de diligencia debida debe reproducir los cálculos clave a partir de datos brutos o controlados. La empresa objetivo debe revelar exclusiones, periodos faltantes e intervención manual. El análisis debe mostrar tendencia central, distribución y casos de fallo en lugar de un único resultado máximo.
La atribución económica sigue a la atribución técnica. Si un producto reduce la energía por unidad de tráfico, el comprador debe identificar los precios de la electricidad, los estados de los equipos, el crecimiento del tráfico y cualquier coste de hardware necesario. Si mejora el rendimiento, el comprador debe mostrar si el beneficio retrasa el gasto de capital, protege la experiencia del cliente o crea capacidad vendible.
8. Probar la persistencia de los KPI
Las ganancias de rendimiento de la red pueden desvanecerse. Los operadores cambian el software, los patrones de tráfico, las configuraciones de frecuencia, el hardware y las prioridades comerciales. Por lo tanto, la evidencia de una empresa objetivo debe cubrir la persistencia, no solo la mejora inicial.
El comprador debe inspeccionar las curvas de cohortes por sitio, región, caso de uso y tiempo desde el despliegue. Un promedio estable puede ocultar un deterioro en entornos de alta carga o inusuales. El modelo debe registrar con qué frecuencia los ingenieros anulan las recomendaciones y con qué frecuencia se activa la reversión.
La persistencia también influye en los precios. Una mejora de ingeniería puntual puede respaldar ingresos de proyecto. Una optimización monitorizada de forma continua con ganancias duraderas puede respaldar tarifas de software recurrentes o el reparto de beneficios. La economía contractual debe coincidir con el trabajo realizado tras el lanzamiento.
9. Conciliar el rendimiento y la eficiencia espectral
El rendimiento y la eficiencia espectral están relacionados, pero son distintos. Un modelo puede mejorar la tasa que experimentan usuarios seleccionados mientras altera la equidad, la cobertura o el uso de recursos en otros lugares. El comprador debe evitar valorar un porcentaje destacado sin el denominador y el contexto de la red.
El análisis debe separar el rendimiento promedio, mediano y de cola. Debe identificar la carga de celda, las condiciones radioeléctricas, la combinación de dispositivos, el espectro, el planificador, la movilidad y el periodo de medición. El rendimiento durante la congestión puede tener más valor comercial que el rendimiento cuando la capacidad es abundante.
SoftBank y Ericsson informaron en agosto de 2026 de que una prueba de AI-in-RAN en red comercial logró mejoras dependientes de la ubicación, incluidas hasta un 25 por ciento de eficiencia espectral y hasta un 50 por ciento de rendimiento de usuario en enlace descendente, con una mejora media de aproximadamente el 10 por ciento en las ubicaciones evaluadas. Estos resultados de proveedores y operadores demuestran viabilidad. No establecen resultados transferibles a otro objetivo u otra red.
10. Validar la economía energética
La automatización energética puede conmutar capacidad, ajustar estados de radio, coordinar la refrigeración o gestionar la infraestructura del emplazamiento. El beneficio debe medirse frente al tráfico, la cobertura, los niveles de servicio, la configuración del equipo y las condiciones ambientales. Los ahorros energéticos que dependen de nuevas radios o de equipos del emplazamiento deben separarse de los efectos del software.
Los casos publicados de proveedores y operadores reportan resultados significativos en despliegues concretos. Ericsson y Far EasTone reportaron en su caso ahorros diarios de energía de la RAN del 25 por ciento sin efectos adversos en el rendimiento de la red. Otro caso de Ericsson describe un ahorro del 14 por ciento procedente de la gestión energética MIMO asistida por aprendizaje automático. Estos resultados son puntos de referencia útiles y siguen siendo específicos de los entornos indicados.
El modelo de adquisición debe utilizar despliegues objetivo verificados, tarifas locales y la persistencia esperada. Debe deducir los costes de computación, integración, licencias y operación. El beneficio solo puede capitalizarse cuando el operador puede retenerlo y el software tiene un derecho duradero sobre el flujo de caja resultante.
11. Medir la disponibilidad y la resiliencia
Un producto de automatización puede crear valor cuando funciona con normalidad y destruirlo cuando se comporta de forma incorrecta. El análisis de disponibilidad debe abarcar la aplicación, el pipeline de datos, los controladores, las interfaces y la función de red objetivo. El equipo debe revisar los modos de fallo y el tiempo de recuperación.
El despliegue seguro requiere barreras de protección, acciones acotadas, despliegues canario, aprobaciones humanas cuando proceda y reversión automática. Los registros deben permitir a un operador reconstruir por qué se produjo una recomendación o acción. Un modelo que no puede explicarse a nivel operativo aún puede ser utilizable si los controles hacen que su comportamiento sea observable y reversible.
Las garantías de la transacción deben reflejar el control real. El proveedor puede garantizar su software, su seguridad y su conformidad. El operador controla la configuración de la red, la implementación y la aceptación. La responsabilidad compartida debe documentarse en lugar de dejarse a un acuerdo de nivel de servicio genérico.
12. Cuantificar la productividad de ingeniería
La automatización puede reducir los ciclos de planificación, el triaje de alarmas, el ajuste de parámetros y el análisis repetitivo. El valor de la productividad depende de si el tiempo de los ingenieros se elimina, se reasigna o se consume en nuevas tareas de integración y monitorización.
El comprador debe mapear el flujo de trabajo anterior y el flujo de trabajo automatizado. Debe contar las actividades, los traspasos, el tiempo transcurrido, las intervenciones y las excepciones. Un modelo que genera recomendaciones sin integración puede desplazar el trabajo en lugar de eliminarlo.
La productividad también favorece la escala. Un operador puede gestionar una mayor complejidad de red sin un crecimiento proporcional de la plantilla. La valoración debe vincular este efecto con planes de dotación de personal aprobados, la externalización evitada o una entrega más rápida. Las estimaciones no respaldadas deben seguir siendo supuestos de la dirección y no deben presentarse como ahorros observados.
13. Probar la interoperabilidad en producción
La conformidad con una interfaz es necesaria y puede ser insuficiente para la interoperabilidad en producción. Los proveedores pueden implementar funciones opcionales de forma diferente. La semántica de los datos, el rendimiento, la seguridad y los procedimientos operativos pueden variar. El comprador debe distinguir entre alineación con estándares, conformidad en laboratorio, éxito de integración y uso sostenido en producción.
La empresa objetivo debería proporcionar una matriz de despliegue que abarque operador, geografía, proveedor de red, versión de software, interfaz, hardware y caso de uso. El despliegue repetido con un núcleo de producto estable es una evidencia más sólida que múltiples proyectos a medida.
La portabilidad debería medirse por el tiempo de despliegue transcurrido, el esfuerzo de ingeniería, los componentes reutilizados, los defectos de regresión y el rendimiento conservado. Una empresa objetivo que requiere un equipo personalizado grande aún puede ser valiosa como integrador especialista; debería recibir la economía de un integrador en lugar de una prima de producto.
14. Evaluar las dependencias de O-RAN
O-RAN crea una arquitectura para funciones de red radio desagregadas e inteligentes. Los grupos de trabajo cubren la gestión y orquestación de servicios, el controlador no en tiempo real, el controlador casi en tiempo real, las interfaces y los ecosistemas de aplicaciones. La versión 5, completada en junio de 2026, incluyó AI y mejoras en los flujos de trabajo de aprendizaje automático, así como funciones de optimización adicionales.
El comprador debería enumerar de qué especificaciones depende el producto, qué versiones utilizan los clientes y qué funciones siguen siendo específicas del proveedor. Debería identificar si la empresa objetivo vende un rApp, un xApp, un controlador, una plataforma de datos, una capa de aseguramiento o una capacidad de integración.
La participación en estándares puede mejorar la información, la credibilidad y el acceso a socios. No garantiza la adjudicación. La valoración debería basarse en la interoperabilidad en vivo, la aceptación del operador y los contratos comerciales. Las contribuciones a estándares pertenecen al caso de opción estratégica.
15. Analizar la dependencia de proveedores incumbentes
Muchos productos de automatización de red dependen de datos, API, acceso a la configuración o comportamiento del controlador de proveedores incumbentes. Un cambio en la política de acceso, las licencias, la versión de software o la hoja de ruta puede afectar al producto de la empresa objetivo.
El equipo de diligencia debida debería identificar cada dependencia crítica y protección contractual. Debería comprobar si la empresa objetivo dispone de interfaces documentadas, compromisos de soporte, certificación y rutas de escalado. El acceso obtenido mediante ingeniería inversa o no oficial puede generar riesgos de continuidad y legales.
La dependencia no es automáticamente negativa. Una asociación sólida puede acelerar la distribución y la integración. Su valor depende de la durabilidad, la economía, la exclusividad y el tratamiento del cambio de control. El comprador debería modelizar tanto la continuidad como la pérdida de la relación.
16. Auditar los derechos sobre los datos
La telemetría de red puede contener información comercialmente sensible, sensible para la seguridad o personal. La empresa objetivo necesita derechos para acceder a los datos, procesarlos, conservarlos y utilizarlos para el fin contratado. Los derechos para entrenar modelos generales pueden ser más limitados que los derechos para optimizar la red de un cliente.
El registro de datos debería identificar la fuente, el responsable del tratamiento, el encargado del tratamiento, la ubicación, la conservación, la finalidad permitida, el uso en modelos, la compartición y la eliminación. Debería conectar los contratos con los flujos de datos reales. Una declaración amplia de que la empresa objetivo es propietaria de sus datos no debería recibir peso en la valoración sin pruebas.
La adquisición puede cambiar el uso permitido o la contraparte. Las disposiciones de cambio de control, las políticas del operador y los controles de seguridad nacional pueden afectar a la continuidad. El comprador debería obtener consentimientos o estructurar el acceso antes del cierre.
17. Inspeccionar la trazabilidad del modelo
La trazabilidad del modelo registra el código, los datos de entrenamiento, las características, los parámetros, los conjuntos de evaluación, las aprobaciones y las versiones desplegadas. Permite la reproducibilidad y ayuda a determinar qué mejoras corresponden a la sociedad objetivo, al cliente o al proveedor tecnológico.
La sociedad objetivo debe mostrar cómo evita filtraciones entre clientes y protege configuraciones confidenciales. Debe documentar los componentes de modelo de código abierto y de terceros, las licencias y las obligaciones. La infraestructura de entrenamiento e inferencia debe ser identificable y tener costes calculados.
La trazabilidad se convierte en un activo de la adquisición cuando acorta la validación, facilita la auditoría y permite continuar el desarrollo. Una trazabilidad deficiente puede convertir un rendimiento propietario en una afirmación no verificable. El comprador debe condicionar el valor a un registro limpio y utilizable.
18. Revisar MLOps y el control del ciclo de vida
Los modelos de red en producción requieren monitorización, detección de deriva, reentrenamiento, pruebas, promoción, reversión y retirada. Estos procesos deben funcionar para todos los clientes sin generar una carga de versiones inmanejable.
El equipo de diligencia debida debe inspeccionar los roles de aprobación, las pruebas automatizadas, el modo sombra, el despliegue canario y la gestión de incidentes. Debe comparar el proceso documentado con los registros de versiones. Una diapositiva que describe MLOps es menos sólida que la evidencia de cambios de modelo controlados.
El coste del ciclo de vida debe incluirse en el análisis del margen bruto. Los modelos específicos para clientes, el reentrenamiento manual y la intervención frecuente pueden hacer que los ingresos por software declarados sean intensivos en servicios. La previsión debe incluir los recursos de cómputo, ingeniería y aseguramiento necesarios para mantener el rendimiento prometido.
19. Evaluar la ciberseguridad y la cadena de suministro
La automatización de redes está próxima a infraestructuras críticas. Una vulneración podría exponer datos operativos, alterar configuraciones o interrumpir el servicio. La seguridad debe abarcar el desarrollo de software, las dependencias, la identidad, los secretos, los datos, los mecanismos de actualización y el acceso operativo.
El comprador debe revisar la evidencia de desarrollo seguro, la gestión de vulnerabilidades, las pruebas de penetración, el historial de incidentes, las listas de materiales de software y los controles de acceso privilegiado. Debe comprobar si la arquitectura de despliegue limita el radio de impacto y permite una revocación rápida.
Los requisitos nacionales y las políticas de los operadores pueden restringir el alojamiento, las ubicaciones de soporte y la titularidad de proveedores. Estas restricciones pueden afectar el acceso al mercado y el coste de integración. El plan de adquisición debe incluir la remediación de seguridad y la reaprobación por parte de los clientes.
20. Identificar el riesgo de concentración
Las empresas incipientes de software de red suelen depender de un número reducido de operadores, proveedores o geografías. La concentración puede aportar una validación profunda y generar riesgo en la negociación.
El análisis de ingresos debe separar la producción de pago, la prueba de pago, los proyectos, el pass-through y los ingresos no recurrentes. El comprador debe inspeccionar las condiciones de renovación, ampliación, rescisión, aceptación y de trato más favorable. La probabilidad del pipeline debe reflejar el historial de adquisiciones y la preparación para el despliegue.
La concentración técnica importa tanto como la concentración de ingresos. Un producto probado en un stack de red puede requerir un trabajo considerable en otro. La valoración no debería tratar la huella de un único operador como una cuota de mercado general.
21. Normalizar las métricas comerciales
Los ingresos recurrentes anuales deben incluir únicamente la contraprestación recurrente y contratada por un servicio continuado. La implementación, el hardware, el traspaso de costes de la nube y los proyectos de ingeniería deben identificarse por separado. Los ingresos por reparto de beneficios deben evaluarse frente a las disposiciones de medición y resolución de disputas.
El margen bruto debe incluir la ingeniería de despliegue, el soporte al cliente, la computación, el movimiento de datos, las licencias de terceros y el trabajo de ciclo de vida. La capitalización del desarrollo puede hacer que la rentabilidad actual parezca más sólida mientras difiere el coste al balance.
La retención debe distinguir entre la retención de clientes (logo), la de contratos y la de productos. La expansión puede provenir de más celdas, regiones, módulos o beneficios medidos. El comprador debe entender qué unidad impulsa el precio y si crece con el valor entregado.
22. Conectar los beneficios de la red con el flujo de caja
La mejora técnica se convierte en valor de adquisición solo cuando afecta al flujo de caja. El ahorro energético puede reducir los gastos operativos. La mejora de capacidad puede aplazar la inversión en radios o espectro. Una mejor experiencia puede proteger los ingresos o reducir las reclamaciones. Una planificación más rápida puede acelerar el despliegue.
El puente debe identificar el beneficio del operador, la captura contractual del objetivo y el periodo de propiedad del comprador. Un beneficio para el cliente no revierte automáticamente en el proveedor de software. Una evidencia sólida puede respaldar la renovación y el precio, pero el contrato determina los ingresos realizados.
Los beneficios deben descontarse por atribución, persistencia, coste de implementación y reparto. El equipo debe evitar sumar el mismo beneficio tanto a los ahorros del cliente como a los ingresos previstos del objetivo.
Tabla 2. Escalera de evidencia para el valor de la automatización de red
| Etapa de evidencia | Registro obligatorio | Limitación típica | Respuesta de valoración |
|---|---|---|---|
| Simulación o laboratorio | Conjunto de datos, modelo, entorno y resultado reproducible | Realismo de red limitado | Activo de investigación únicamente |
| Prueba de campo controlada | Línea base, control, alcance y resultado firmado | Duración corta o configuración limitada | Valor técnico contingente |
| Prueba en red comercial | Alcance en vivo, salvaguardas y validación del operador | La economía de la prueba puede no repetirse | Valor del hito |
| Producción limitada | Contrato, nivel de servicio y KPI persistente | Concentración de clientes o proveedores | Valor operativo descontado |
| Producción repetible multioperador | Renovaciones, márgenes y evidencia de portabilidad | Riesgos restantes de escala y de mercado | Valor de empresa fundamental |
El valor de adquisición aumenta cuando la evidencia avanza de la posibilidad técnica a unos resultados económicos contractuales y repetibles.
23. Elaborar el cuadro de mando de KPI de automatización
El cuadro de mando debe combinar rendimiento, economía y control. Las medidas de rendimiento incluyen capacidad de procesamiento, eficiencia espectral, energía, disponibilidad y precisión de optimización. Las medidas económicas incluyen coste evitado, esfuerzo de despliegue, margen bruto y renovación. Las medidas de control incluyen anulaciones, reversión, incidentes y exhaustividad de auditoría.
Cada KPI debe identificar la fuente, el responsable, la frecuencia, la línea de base y el umbral. El rendimiento máximo declarado debe mostrarse junto a las medias observadas y a los supuestos de adquisición conservadores. Esto evita que un resultado máximo domine la valoración.
El cuadro de mando debe seguir siendo útil una vez completada la operación. Puede apoyar las prioridades de integración, las pruebas de earn-out y los informes a clientes. Las definiciones deben acordarse antes de la firma, ya que cambiar la medición después del cierre genera disputas.
Las puntuaciones ilustrativas del índice muestran cómo la diligencia debida descuenta una afirmación principal por alcance, persistencia y captura.
24. Modelar la curva de capex
La automatización puede alterar el calendario del gasto de capital en red. Un mejor uso de la capacidad existente puede retrasar la densificación. Una planificación más precisa puede reducir el sobredimensionamiento. La computación compartida o los nuevos controladores pueden requerir capital adicional.
El modelo debe comparar un plan convencional con un plan habilitado por automatización por año. Debe utilizar los mismos supuestos de tráfico, cobertura, espectro y servicio. El capital aplazado debe distinguirse del capital evitado de forma permanente, porque el retraso sigue teniendo valor y un efecto terminal diferente.
Deben incluirse los costes de implementación y computación. Si un modelo requiere computación acelerada en muchos emplazamientos, la curva neta puede diferir materialmente de la de un servicio de optimización centralizado. El comprador debe probar la carga, la energía y el hardware con la arquitectura objetivo.
Supuestos de gestión ilustrativos; la automatización aplaza parte de la densificación, pero requiere inversión en integración y computación.
25. Valorar el negocio actual
El negocio actual puede valorarse mediante un método de flujo de caja descontado, transacciones comparables o múltiplos de ingresos y beneficios, sujeto a disponibilidad y comparabilidad. La previsión debería comenzar con los ingresos contratados y construirse mediante una expansión basada en evidencia.
El comprador debería normalizar las subvenciones de investigación, los proyectos piloto, el hardware y la ingeniería no recurrente. Debería incluir el gasto en productización y cumplimiento necesario para escalar. Una tasa de crecimiento elevada debería estar vinculada a los presupuestos de los operadores, los ciclos de compras y la capacidad de despliegue.
Las empresas comparables pueden combinar software, equipos y servicios. El equipo de la transacción debería ajustar por combinación de negocio, margen, concentración, crecimiento, propiedad intelectual y madurez. Un múltiplo genérico AI o de software puede ocultar la economía de las telecomunicaciones.
26. Asignar precio al valor validado para el cliente
El valor validado para el cliente puede justificar una prima cuando se mide de forma independiente, es repetible y está vinculado a la captura comercial. El comprador puede comparar el valor presente del beneficio para el cliente con las cuotas de suscripción y los costes de cambio.
La prima debería estar limitada por alternativas competitivas y los términos contractuales. Los operadores pueden desarrollar una capacidad similar, obtenerla de proveedores de red o adquirirla de otro proveedor independiente. Las interfaces abiertas pueden ampliar el mercado y reducir las barreras.
La evidencia de beneficios es más sólida cuando los clientes renuevan, amplían y permiten su uso como referencia. El comprador debería hablar directamente con las partes interesadas técnicas, operativas y de compras. El entusiasmo de un equipo de innovación no sustituye un presupuesto de producción.
27. Valorar la portabilidad
La portabilidad reduce la dependencia de un único cliente y de un único stack de proveedores. Puede acelerar el crecimiento de los ingresos y mejorar la relevancia estratégica. Su valor depende de software reutilizable, interfaces estables, incorporación automatizada y evidencia de que el rendimiento se mantiene tras la transferencia.
El equipo debería calcular un coeficiente de portabilidad: la proporción de código, modelos, pruebas y activos de integración reutilizados en el siguiente despliegue. Debería medir el tiempo de despliegue y el esfuerzo de ingeniería. Estas métricas deberían verificarse con los registros de los proyectos.
La prima puede escalonarse. Parte puede pagarse al cierre por despliegues demostrados. La contraprestación adicional puede supeditarse a la aceptación en un nuevo operador o stack. Esto alinea el precio con la transferibilidad materializada.
28. Limitar el valor de la opción 6G
La opción 6G representa el derecho a participar en el gasto y la arquitectura futuros de los operadores. No debería valorarse como ingresos 6G previstos cuando los productos, los plazos y las compras siguen siendo inciertos.
Un registro de opciones puede puntuar la relevancia para los estándares, la reutilización técnica, el acceso a socios, la propiedad intelectual, la inversión requerida y el tiempo hasta la evidencia comercial. El valor debería limitarse por el capital incremental necesario y la probabilidad de ejercicio.
Los hitos pueden incluir estándares aprobados, interfaces aceptadas, pruebas exitosas, presupuestos de operadores y contratos firmados. La contraprestación vinculada a estos eventos protege el potencial al alza del vendedor y el capital del comprador.
29. Construir el puente de valoración
El puente de valoración parte del negocio actual y solo añade valor diferenciado y respaldable. Puede añadir economías de KPI validadas, portabilidad y opciones estratégicas. Resta riesgos de integración, concentración, derechos, ciberseguridad, rendimiento y estándares.
En el caso hipotético, las partes analizan un valor de empresa de USD 300 million. El puente es una ayuda para la decisión, no una opinión de valoración. Los importes muestran cómo el método evita que la narrativa de 6G sostenga la totalidad del precio.
El comprador debe evaluar escenarios a la baja, base y al alza. Cada ajuste necesita un responsable de la evidencia y un tratamiento al cierre. Los riesgos que puedan subsanarse antes de la firma deben ser condiciones. Los riesgos cuyo resultado surja después del cierre deben reflejarse mediante contraprestación contingente o retención.
Supuestos ilustrativos de la dirección en USD millones; la opción de estándares futuros está deliberadamente limitada.
30. Estructurar la contraprestación
El efectivo al cierre debe financiar el valor presente verificado. La reinversión del vendedor puede mantener la alineación cuando los fundadores y líderes técnicos siguen siendo importantes. Los earn-outs pueden remunerar ingresos, despliegue de producción o portabilidad validada después del cierre.
Los earn-outs técnicos exigen definiciones objetivas. El acuerdo debe indicar el alcance de la red, la línea base, los KPI, el período de medición, las condiciones de control, el verificador independiente y las consecuencias de las decisiones del comprador. Un hito vago invita al conflicto.
Los pagos por hitos pueden abordar la incertidumbre sobre estándares y 6G. Deben recompensar resultados dentro de la influencia del vendedor y tener en cuenta la financiación del comprador. Los calendarios prolongados necesitan disposiciones de gobernanza, información y resolución de disputas.
31. Utilizar manifestaciones e indemnizaciones
Las manifestaciones deben cubrir la titularidad, las licencias, los derechos sobre los datos, el uso de código abierto, la seguridad, las declaraciones sobre estándares, los contratos con clientes, los registros de modelos y el cumplimiento normativo. Deben reflejar los hechos revelados y el control real.
Las indemnizaciones específicas o el depósito en garantía pueden abordar problemas identificados de cadena de titularidad, ciberseguridad o consentimiento del cliente. El seguro puede cubrir partes del riesgo y puede excluir el rendimiento prospectivo.
Las afirmaciones técnicas utilizadas en la valoración deben figurar en los registros de diligencia debida y en los anexos de la transacción. El lenguaje de marketing no debe convertirse en una garantía no intencionada, y la evidencia material no debe quedar fuera de los documentos de la operación.
32. Proteger a las personas clave y los conocimientos técnicos
El valor de la automatización de redes puede depender de ingenieros que entiendan los sistemas de los operadores, el comportamiento de los modelos y las vías de integración informales. El comprador debería identificar la concentración de personas clave y las lagunas de documentación.
La retención debería combinar claridad de funciones, incentivos, trayectoria profesional y recursos. Los covenants restrictivos requieren asesoramiento específico por jurisdicción. La transferencia de conocimiento debería medirse mediante documentación completada, pruebas y capacidad de los sucesores.
El modelo operativo debería reducir la dependencia de esfuerzos heroicos. El producto, el despliegue, la ciencia de datos, los estándares y la responsabilidad sobre los clientes deberían contar con líderes responsables y procesos repetibles.
33. Planificar la integración antes de firmar
Las decisiones de integración afectan la credibilidad del producto. Los operadores pueden necesitar aprobar un cambio de titularidad, alojamiento o soporte. Combinar repositorios de código y procesos de seguridad con demasiada rapidez puede interrumpir los lanzamientos.
El primer plan debería preservar la continuidad del servicio, la confianza del cliente, el acceso privilegiado y el enfoque en la hoja de ruta. Los sistemas corporativos pueden integrarse por etapas. La arquitectura de producto solo debería cambiar mediante un plan probado.
Las sinergias deberían identificar responsable, coste, plazo y dependencia. La sinergia de ingresos a través de los canales del comprador requiere habilitación técnica y acceso a compras. La sinergia de costes no debería eliminar la capacidad de ingeniería necesaria para la entrega.
34. Elaborar el plan de los primeros 100 días
Los primeros 100 días deberían validar derechos, compromisos con clientes, lanzamientos de producto, controles de seguridad y líneas base de KPI. El comprador debería congelar un inventario verificado de código, modelos, datos, interfaces y despliegues.
Las reuniones con clientes deberían confirmar la continuidad y los planes de expansión. Los equipos de producto deberían reproducir la evidencia relevante y establecer un estándar de medición común. Los equipos financieros deberían conciliar la calidad de los ingresos y el coste de entrega.
El consejo debería aprobar por separado la hoja de ruta del valor actual y la hoja de ruta de opciones. El capital para el trabajo futuro en estándares debería seguir hitos técnicos y comerciales.
35. Crear un cuadro de mando para el consejo
El cuadro de mando del consejo debería cubrir ingresos recurrentes, renovación, margen bruto, tiempo de despliegue, portabilidad, persistencia de KPI, incidentes, anulaciones y hitos de estándares. Cada medida necesita una definición estable.
El cuadro de mando debería mostrar valores observados, validados por el cliente y del caso de adquisición. Debería distinguir los resultados máximos de los promedios de la flota. Las excepciones deberían permanecer visibles.
La dirección puede utilizar el panel para decidir si escala, subsana o detiene un caso de uso. Una puntuación compuesta no debe ocultar fallos en seguridad, derechos o resiliencia.
Tabla 3. Caso hipotético de transacción y financiación
| Concepto | Supuesto base | Condición de diligencia debida | Respuesta de la transacción |
|---|---|---|---|
| Análisis del valor de empresa | USD 300 million | El negocio actual sustenta la mayor parte del valor | Limitar el efectivo al cierre |
| Ingresos recurrentes contratados | USD 36 million | Revisión de contratos, renovaciones y calidad de ingresos | Entrada de valor base |
| Ajustado EBITDA | USD 8 million | Incluir costes de entrega, computación y ciclo de vida | Normalizar beneficios |
| Valor de KPI validado | Contribución puente de USD 32 million | Reproducción independiente y persistencia | Earn-out o prima |
| Valor de portabilidad | Contribución puente de USD 26 million | Despliegue aceptado en otra pila tecnológica | Pago por hito |
| opción 6G | Contribución limitada USD 18 million | Estándares, prueba piloto e hitos de adopción contractual | Pago diferido de la opción |
| Deducciones por riesgo | USD 21 million | Integración, concentración, derechos y estándares | Ajuste de precio o depósito en garantía |
Únicamente supuestos ilustrativos de la dirección; ningún importe representa datos observados de la empresa ni una opinión de valoración.
36. Establecer el plan de trabajo de la diligencia debida
El plan de trabajo debe integrar la diligencia debida comercial, técnica, operativa, legal, regulatoria, de ciberseguridad y financiera. Los flujos separados deben usar un único registro de afirmaciones para que el mismo beneficio no se acepte en un flujo de trabajo y se cuestione en otro.
Las afirmaciones materiales deben identificar evidencia, propietario, verificador y consecuencia para la transacción. El equipo debe priorizar las afirmaciones que aportan valor: ingresos recurrentes, ahorros para el cliente, portabilidad, derechos y dependencias de opciones futuras.
Las pruebas deben incluir revisión de código y arquitectura, mapeo de derechos sobre datos, reproducción de modelos, muestreo de despliegues, llamadas con clientes y conciliación de contratos. Los hallazgos deben incorporarse a la valoración, las condiciones, los covenants y la integración.
37. Preparar la sala de datos
La sala de datos debe incluir registros de entidades, cesiones de propiedad intelectual, inventario de código fuente, licencias, linaje de modelos, arquitectura, evidencia de seguridad, contratos con clientes, despliegues, estudios de KPI, historial de incidentes, registros financieros y contribuciones a estándares.
La evidencia debe ser atribuible y estar fechada. Las capturas de pantalla y las presentaciones deben enlazar con los registros subyacentes. Los datos de red sensibles para el cliente pueden requerir una revisión controlada en lugar de una divulgación amplia.
La sociedad objetivo debe mantener un registro de alertas con responsables y fechas de cierre. Una sala de datos limpia acorta el tiempo de la transacción y mejora la confianza; no sustituye la evidencia sustantiva.
38. Aplicar una decisión de seguir, revisar el precio o detenerse
Una decisión de seguir adelante exige un negocio actual defendible, derechos utilizables, una integración gestionable y una vía creíble hacia la escala. El reajuste de precio procede cuando el activo sigue siendo útil y las pretensiones de valor superan la evidencia. Una decisión de detenerse procede cuando los derechos críticos, la seguridad, la continuidad del cliente o la atribución técnica no pueden subsanarse.
La decisión debe explicitar la opcionalidad futura. Un comprador puede adquirir un negocio valioso de automatización 5G y, al mismo tiempo, atribuir poco valor a 6G. También puede buscar una alianza o una opción en lugar de adquirir una plataforma inmadura.
Los registros de decisiones deben identificar supuestos y asuntos pendientes. Esto preserva la rendición de cuentas cuando la tecnología y los estándares evolucionan.
Tabla 4. Cuadro de mando del consejo y de la diligencia debida
| Dominio | Evidencia mínima | Señal de alarma | Respuesta a la decisión |
|---|---|---|---|
| Ingresos | Contratos, facturas, renovaciones y puente de margen | Ingresos de prueba presentados como recurrentes | Normalizar o recalcular el precio |
| Impacto en KPI | Línea base, contrafactual, persistencia y validación del cliente | Afirmación de pico sin datos brutos | Excluir el incremento |
| Interoperabilidad | Despliegue repetido en stacks definidos | Integración a medida presentada como producto | Reducir la prima de producto |
| Datos y modelos | Derechos, linaje, reproducibilidad y control del ciclo de vida | Derechos de entrenamiento poco claros | Subsanar antes del cierre |
| Garantía | Desarrollo seguro, control de acceso y evidencia de incidentes | Exposición a infraestructuras críticas | Remediar o detener |
| opción 6G | Mapa de estándares, capacidad reutilizable e hito de adopción | Previsión de ingresos antes de la definición del producto | Limitar y diferir el valor |
Cada dominio requiere evidencia antes de que se le atribuya un valor material.
39. Reconocer las limitaciones
Este marco respalda el análisis de adquisiciones. No determina si un producto es seguro, conforme a la normativa o adecuado para una red específica. Se requiere asesoramiento cualificado técnico, regulatorio, de seguridad, jurídico, fiscal, contable y de valoración.
Los estándares, las interfaces y los planes de los operadores siguen evolucionando. Los resultados publicados por proveedores y operadores son específicos de los despliegues que describen. No deben generalizarse sin reproducirlos.
El caso hipotético demuestra un método. Los ingresos, costes, beneficios, probabilidades, condiciones y valores reales requieren evidencia específica de la transacción. Ninguna cifra del caso constituye una previsión ni una recomendación.
40. Concluir con evidencia antes de la opcionalidad
La automatización de redes puede crear valor medible antes de 6G. Puede reducir el consumo energético, mejorar la capacidad, reforzar la resiliencia y aumentar la productividad de la ingeniería. El valor de adquisición se materializa cuando esos efectos son atribuibles, persistentes, contractualmente capturados y portables.
AI-La actividad de arquitectura y estándares de RAN amplía la oportunidad estratégica. También aumenta la necesidad de definiciones precisas. La alineación con los estándares debe mapearse; la interoperabilidad debe demostrarse; el valor futuro debe escalonarse por fases.
La secuencia disciplinada de la transacción consiste en valorar el negocio operativo actual, verificar los resultados para el cliente, probar la portabilidad, poner precio al riesgo de integración y de derechos, y situar el potencial alcista de 6G detrás de hitos observables. Este enfoque permite al comprador participar en la inteligencia de red futura mientras paga hoy por evidencia que existe hoy.
Referencias
- Unión Internacional de Telecomunicaciones. Requisitos técnicos de rendimiento IMT-2030 para el futuro 6G. 17 de marzo de 2026. https://www.itu.int/hub/2026/03/imt-2030-technical-requirements-for-the-6g-future/
- Unión Internacional de Telecomunicaciones. Portal y proceso de IMT-2030. https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2030/pages/default.aspx
- Unión Internacional de Telecomunicaciones. Recomendación UIT-R M.2160-0: Marco y objetivos generales del desarrollo futuro de las IMT para 2030 y años posteriores. 2023. https://www.itu.int/rec/R-REC-M.2160-0-202311-I
- Unión Internacional de Telecomunicaciones. Programa de trabajo: marco para la arquitectura de red de IMT-2030. https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=23853
- O-RAN Alliance. Grupo de trabajo 2: RIC no en tiempo real e interfaces A1/R1. https://www.o-ran.org/technical-groups/wg2
- O-RAN Alliance. Grupos técnicos. https://www.o-ran.org/technical-groups
- O-RAN Alliance. O-RAN Alliance completó la versión 5 de la especificación. 8 de junio de 2026. https://www.o-ran.org/blog/o-ran-alliance-completed-its-specification-release-5-o-ran-r005
- O-RAN Alliance. 60 documentos técnicos de O-RAN nuevos o actualizados publicados desde marzo de 2025. https://www.o-ran.org/blog/60-new-or-updated-o-ran-technical-documents-released-since-march-2025
- O-RAN Alliance. Prioridades de RAN abiertas e impulsadas por AI. 28 de marzo de 2025. https://mediastorage.o-ran.org/press-release/O-RAN.EC.2025-03-28.PR%20MWC25%20summit%20messages.pdf
- Proyecto de Asociación de Tercera Generación. 3GPP Highlights, número 10. https://www.3gpp.org/images/newsletters/3GPP_Highlights_Issue_10_WEB.pdf
- Ericsson. Far EasTone utiliza AI y aprendizaje automático para el ahorro energético en RAN. 2023. https://www.ericsson.com/en/cases/2023/ericsson-far-eastone
- Ericsson. Mejorando la gestión energética de MIMO con aprendizaje automático y AI. https://www.ericsson.com/en/cases/2019/augmenting-mimo-energy-management-with-machine-learning-and-ai
- Ericsson. Caso de eficiencia energética de Elisa Finland y Ericsson. 2023. https://www.ericsson.com/en/cases/2023/elisa-finland-and-ericsson
- Ericsson y SoftBank. Prueba de AI en RAN en red comercial de Japón. 20 de agosto de 2026. https://www.ericsson.com/en/press-releases/2/2026/softbank-corp-and-ericsson-conduct-japans-first-trial-of-ericsson-ai-in-ran-on-5g-commercial-network
- Ericsson. La RAN se vuelve más inteligente: Ericsson pone AI donde importa. Junio de 2026. https://www.ericsson.com/en/news/2026/6/the-ran-gets-smarter-ericsson-puts-ai-where-it-matters
- Ericsson y KDDI. rApps de optimización de RAN en producción impulsadas por AI. 2026. https://www.ericsson.com/en/cases/2026/kddi-boosts-uplink-with-live-ai-powered-ran-optimization-rapps
- Ericsson y AT&T. Dando forma a las redes del mañana con una red programable. 2025. https://www.ericsson.com/en/cases/2025/shaping-networks-of-tomorrow
- Ericsson y TAWAL. Operaciones de infraestructura energética en Arabia Saudí. 2023. https://www.ericsson.com/en/press-releases/5/2023/tawal-reaps-benefits-of-ericsson-energy-infrastructure-operations-in-saudi-arabia
- SoftBank. AI-RAN: desvelando el futuro de las telecomunicaciones con innovaciones disruptivas. 7 de febrero de 2025, versión 1.1. https://www.softbank.jp/corp/set/data/technology/research/story-event/wp_location/pdf/SoftBank_AI-RAN%20Unveiling%20the%20Future%20of%20Telecom%20with%20Breakthrough%20Innovations_Feb7_2025_Ver.1.1.pdf
- Fundación IFRS. IFRS 3 Combinaciones de negocios. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
- Fundación IFRS. IAS 36 Deterioro del valor de los activos. https://www.ifrs.org/issued-standards/list-of-standards/ias-36-impairment-of-assets/
- Fundación IFRS. NIC 38 Activos intangibles. https://www.ifrs.org/issued-standards/list-of-standards/ias-38-intangible-assets/
- Fundación IFRS. NIIF 13 Medición del valor razonable. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/
Sobre el autor
Chennakeshav (CK) es un ejecutivo de finanzas corporativas y banca de inversión con más de 25 años de experiencia global en originación, estructuración y ejecución de operaciones en M&A, capital de crecimiento y estrategia corporativa. Ha liderado mandatos de creación de valor para fundadores, empresas y fondos —tendiendo un puente entre la visión del consejo de administración y la ejecución práctica y el cierre—.
Su trayectoria abarca Morgan Stanley, HSBC, Lloyds Banking Group, EWEC, empresas del portafolio de ADQ y Emirates Growth Fund, en sectores como TMT, inmobiliario, fintech, deeptech, cleantech, infraestructura y energía. Ha colaborado con directivos de primer nivel, fondos de capital privado y de capital riesgo, fondos soberanos y family offices para financiar captaciones de fondos complejas y empresas en expansión, y ha liderado iniciativas de diligencia debida de M&A, integración posfusión y transformación empresarial para crear valor.
En Matchpoint Partners es socio director y lidera la práctica de finanzas corporativas, M&A y captación de capital de la firma. Tiene un MBA por London Business School, un título de ingeniería por la VTU y un Máster en Derecho (LLM, en curso) por UCL London.
Como mentor activo de startups, CK ejerce de mentor en Techstars, DIFC FinTech Hive, Startup Grind, Founder Institute e IN5, es Entrepreneur Mentor in Residence (EMiR) en London Business School y actúa como jurado en la Copa Mundial del Emprendimiento.
https://www.linkedin.com/in/ckadya/
https://www.matchpoint-partners.com/team/ck-adya.html
Este artículo forma parte de una serie continua sobre la estructura de los mercados privados y alternativos. Las opiniones expresadas son del autor. El artículo tiene carácter meramente informativo, describe la estructura del mercado en términos generales y no constituye asesoramiento de inversión, jurídico, fiscal o regulatorio ni una recomendación respecto de ningún valor, vehículo o contraparte.
