La mayoría de los operadores que han evaluado seriamente un cambio de plataforma han hecho alguna versión del mismo cálculo: cuánto cuestan al año el equipo y la infraestructura actuales, frente a lo que pagarían en tarifas por un sistema de gestión de puntos de recarga (CPMS).
Esa comparación tiene un punto ciego. Los mayores costes de mantener un CPMS propio no aparecen en ningún presupuesto. No figuran en la partida de plantilla, ni en la factura de infraestructura en la nube, ni en el gasto de cumplimiento normativo. Se acumulan en lo que no llegó a construirse, en los puntos de vista que nunca se tuvieron en cuenta y en la distancia entre dónde está hoy la operación y dónde podría estar.
La mayoría de las plataformas propias se crearon cuando las alternativas comerciales aún no eran lo bastante maduras como para confiarles las operaciones principales. El razonamiento original sigue siendo válido; lo que ha cambiado es el cálculo y, en concreto, los costes que nunca figuraron en ninguna partida presupuestaria. Hemos acompañado cambios de plataforma con algunos de los mayores operadores de puntos de recarga (CPO) de Europa. Lo que descubren los operadores, una y otra vez, es que la comparación que venían haciendo dejaba fuera los costes que más importan.
El trabajo que siempre va primero
Mantener un CPMS propio significa que su equipo de ingeniería asume obligaciones recurrentes que ninguna plataforma comercial absorbe por usted. Actualizaciones de protocolos, recertificaciones de pagos, ciclos de cumplimiento normativo: todo ello entra en el backlog como trabajo programado, por delante de todo lo demás, porque los plazos los fijan el mercado y los reguladores, no su equipo de producto.
Esas obligaciones crecen con la escala: cada nuevo mercado, cada fabricante de hardware añadido, cada jurisdicción con su propio calendario de cumplimiento amplía el perímetro que hay que mantener. La capacidad del equipo para mantenerlo no crece al mismo ritmo.
El coste real no son las horas en sí, sino lo que desplazan. El trabajo que se aplaza es precisamente el que haría avanzar el negocio. El sprint de cumplimiento se ve en el tablero. La iniciativa de la hoja de ruta que desplazó, no.
Su negocio tal y como ya podría ser
Su operación podría ser ya muy distinta si el mantenimiento no hubiera pasado siempre por delante. Funcionalidades que llevan dieciocho meses en la hoja de ruta. Una capacidad comercial aplazada al siguiente ciclo, y luego al siguiente. Herramientas para clientes que su equipo sabría construir, pero para las que no tiene capacidad disponible ni para empezar.
Nada de esto aparece en una auditoría, porque nunca existió. Puede revisar todo lo que se construyó. No hay forma de revisar lo que no se construyó.
Parte de lo que se aplazó es hoy una capacidad estándar entre los operadores con los que usted compite. Otra parte se está convirtiendo en una expectativa comercial en los mercados donde opera. La hoja de ruta aplazada no genera ninguna partida de coste visible; sus efectos se manifiestan en las capacidades que le faltan cuando una oportunidad comercial las requiere.
Descubra en qué punto está su operación con el benchmark de CPMS propio.
Las referencias que solo llegan de fuera
Los equipos internos desarrollan una experiencia real en su propia operación. Con el tiempo, esa experiencia trae consigo un efecto más difícil de ver desde dentro: una desviación de las referencias. Sin puntos de comparación externos, la percepción del equipo sobre qué es difícil, qué es normal y qué es realmente exclusivo de su red se vuelve hacia dentro, lo que lleva a sobrestimar de forma persistente lo particulares que son sus requisitos. Una lógica de facturación a medida que parece insustituible. Casos especiales de hardware que parecen excepcionalmente complejos. Requisitos de flujo de trabajo que parecen demasiado específicos para que una plataforma estándar pueda cubrirlos.
Los operadores que han hecho la transición describen después, de forma sistemática, la misma constatación: la mayor parte de lo que parecía una complejidad propia e insustituible era la complejidad normal de gestionar una red grande. La gestión del firmware de una docena de fabricantes de hardware, la lógica de facturación por niveles para contratos de flotas B2B, las estructuras personalizadas de credenciales de itinerancia: resultan ser retos que decenas de otros operadores en la misma plataforma ya han resuelto. Las soluciones existían. Simplemente no se veían desde dentro.
Los operadores que trabajan con una plataforma comercial presente en 200+ redes adquieren unas referencias que, por su propia estructura, no están al alcance de una sola operación: qué han resuelto ya las redes comparables, qué capacidades se están convirtiendo en requisitos del mercado antes de aparecer en un pliego de licitación, hacia dónde se dirige el sector antes de que llegue el cambio. Una operación aislada, por bien gestionada que esté, no puede acumularlas.
El conocimiento concentrado en muy pocas personas
Todo CPMS propio tiene un pequeño grupo de ingenieros que guardan la verdadera memoria del sistema, concentrada por antigüedad y circunstancias más que por diseño. Saben por qué una regla de facturación está fijada en el código. Saben qué cambió el parche de firmware de 2021 y qué dejó sin resolver. Saben qué caso especial de hardware requiere una solución alternativa que nunca se documentó formalmente.
El código que mantienen también ha acumulado años de decisiones tomadas bajo presión operativa: elecciones que tenían sentido en su momento, pero cuyo efecto combinado hace que cada cambio futuro suponga algo más de esfuerzo del que debería. McKinsey estima que la deuda técnica representa entre el 20 y el 40 % del valor de todo el patrimonio tecnológico, una sobrecarga creciente que rara vez aparece en una partida concreta antes de convertirse en una limitación.
Cualquier código de gran tamaño construido durante años bajo presión operativa desarrolla de forma natural este tipo de carga invisible. La fragilidad que produce es un riesgo para la continuidad del negocio, no solo un problema técnico. Cuando esos ingenieros se van (por rotación, mejores oportunidades o el cansancio acumulado tras años en modo mantenimiento), el conocimiento no se transfiere limpiamente. La brecha de conocimiento suele aparecer cuando la operación menos puede asumirla: durante una migración, una adquisición o un sprint de cumplimiento que nadie había presupuestado.
Si este patrón le resulta familiar, la conversación sobre una prueba de concepto (PoC) empieza por su arquitectura actual.
Una brecha que no deja de crecer
Cada uno de estos costes tiene su propio peso. Su efecto combinado es otra cosa.
Como AMPECO se mantiene como una única plataforma para sus 200+ operadores a la vez, cada capacidad que se lanza llega a todos ellos al mismo tiempo: diagnóstico de averías asistido por IA, gestión dinámica de tarifas, integraciones de gestión de la energía, capacidades que se están convirtiendo en requisitos estándar en los mercados de sus clientes. Para un operador con plataforma propia, cada una entra en el backlog como algo que evaluar, definir, priorizar y, finalmente, construir, en solitario y con un equipo ya ocupado en ponerse al día.
El primer año se trata de una o dos funcionalidades. En el tercer año, la brecha es considerable: un conjunto de capacidades a las que sus competidores tienen acceso y a las que su equipo aún no ha llegado en el backlog. En el quinto año, la cuestión es qué puede ofrecer su negocio y qué no: qué modelos comerciales puede admitir, qué requisitos del mercado puede cumplir y qué tiene capacidad de construir su equipo de ingeniería cuando clientes y competidores avanzan más rápido de lo que su backlog permite.
La sobrecarga de ponerse al día, la hoja de ruta aplazada, la falta de referencias entre redes, la deuda técnica que se acumula: no se suman sin más. Interactúan y se refuerzan: la sobrecarga de ponerse al día consume la capacidad que permitiría despejar el backlog; el backlog aplazado impide el trabajo de hoja de ruta que reduciría esa sobrecarga. La brecha entre una operación con desarrollo propio y otra que funciona sobre una plataforma comercial diseñada para absorber estos costes de forma centralizada no se mantiene estable con el tiempo.
Lo que ven los operadores que conocen ambos lados
Los operadores que han hecho esta transición con AMPECO no conocieron estos costes en teoría. Los reconocieron a posteriori: en las capacidades que no sabían que existían, en los problemas que no sabían que otros ya habían resuelto, en la hoja de ruta que empezó a avanzar a los pocos meses del cambio porque por fin se había despejado la cola de mantenimiento.
La constatación siempre es la misma: no sabían lo que era posible, porque nadie dentro de una única operación puede ver el panorama completo de lo que operaciones similares ya han resuelto.
Antes de llegar a esas conclusiones, conviene plantearse algunas preguntas internamente:
- ¿Qué porcentaje de su capacidad de ingeniería se dedicó a actualizaciones de protocolos, cumplimiento normativo o recertificaciones de pagos en los últimos doce meses?
- ¿Cuántas iniciativas de la hoja de ruta se han aplazado más de dos veces?
- Si los ingenieros que mejor conocen la plataforma se marcharan mañana, ¿cuánto tardaría en verse afectada la operación?
- ¿Qué capacidades comerciales que los competidores en plataformas comerciales ya ofrecen no ha construido usted en los últimos dos años?
Esa constatación puede llegar antes de que la brecha crezca, o después. La diferencia entre esos dos momentos es importante: no por urgencia, sino porque el equipo de ingeniería aún tiene capacidad para liderar la transición en lugar de limitarse a absorberla.
Siga leyendo:
Desarrollar un CPMS propio ya no se justifica: el enfoque estratégico de por qué ha cambiado el cálculo, escrito para la alta dirección y el consejo de administración.
Siempre a la zaga: por qué los equipos de ingeniería de un CPMS propio no pueden adelantarse: la razón estructural de la sobrecarga de mantenimiento, por qué aumentar la plantilla no la resuelve y qué cambia cuando la cola de obligaciones pasa a la plataforma.
