El asset manager de una cartera privada de infraestructura eléctrica lleva al comité de inversiones la propuesta de reposición del ejercicio: doce transformadores de distribución, cuatrocientos ochenta mil euros, plazo de ejecución dieciocho meses. La CFO recibe la propuesta con calma y hace las tres preguntas que se hacen siempre. Por qué doce. Por qué ahora. Por qué estos doce y no otros. La respuesta del asset manager combina antigüedad del activo —instalados entre dos mil cuatro y dos mil siete—, horas de servicio acumuladas en torno a las ciento cuarenta mil por unidad y la valoración cualitativa habitual de fin de vida útil. La CFO responde con una frase que no se le rebate: la antigüedad no es fallo, ni las horas son degradación; presente un criterio de decisión defendible, no una partida de nacimiento. La propuesta se aplaza al siguiente ejercicio. La misma conversación se ha repetido, con matices, en tres ejercicios consecutivos.

La CAPEX de reposición es una de las líneas más cuestionadas del presupuesto anual de un operador privado y, paradójicamente, una de las peor defendidas por el dato operativo. El argumento "está viejo, hay que sustituir" colapsa en cuanto la dirección financiera lo compara con una alternativa razonable: continuar operando y presupuestar el correctivo asociado. Lo que separa una propuesta aprobada de una propuesta aplazada no es el importe, ni el estilo de la presentación, ni la elocuencia del asset manager. Es la granularidad del dato de mantenimiento que sostiene la propuesta.

Los cuatro datos que la CFO informada realmente pide

Una propuesta CAPEX de reposición defendible se apoya en cuatro puntos de dato específicos, cada uno de los cuales aísla una parte de la incertidumbre que la dirección financiera necesita cerrar antes de firmar. El primero es el histórico de fallos por activo individual, no por clase. Doce transformadores del mismo modelo no fallan igual: uno puede haber acumulado seis intervenciones en los últimos treinta y seis meses mientras otro no ha requerido correctivo relevante desde la instalación. La propuesta que trata a los doce como una unidad indistinguible pierde la conversación en el primer minuto. La propuesta que llega con la curva de fallos por activo, ordenada de peor a mejor, permite a la CFO ver qué se está sustituyendo y qué se está posponiendo dentro del mismo lote.

El segundo es la tendencia del coste de intervención por activo en los últimos cuatro a ocho trimestres. Un activo cuyo coste operativo trimestral está creciendo de forma sostenida —tanto en horas de intervención como en materiales— señala una degradación medible que la reposición corta. Un activo cuyo coste se mantiene estable, aunque tenga la misma antigüedad nominal, no justifica reposición desde la lectura del gasto. Sin esta serie temporal por activo, la propuesta es una hipótesis; con ella, es una lectura.

El tercero es la modelización del impacto aguas abajo. Un transformador que alimenta a un único punto de baja criticidad y un transformador que alimenta a un sector productivo con SLA duro no valen lo mismo aunque técnicamente sean el mismo modelo con la misma antigüedad. La propuesta que integra topología de red y criticidad de destino permite ordenar la reposición por impacto de continuidad, no por edad de la placa de características.

El cuarto es el benchmark con activos comparables dentro de la propia cartera. Si los doce candidatos a sustituir están peor que otros cuarenta transformadores del mismo tipo y del mismo perfil operativo, la propuesta gana solidez estadística; si están peor que veinte pero mejor que otros veinte, la lista de doce hay que renegociarla. Sin comparación intra-cartera, la CFO no tiene manera de calibrar si la selección es la correcta.

Por qué el GMAO tradicional no produce estos cuatro datos

En una operativa donde el GMAO actual captura intervenciones como texto libre, con identificadores de activo inconsistentes entre nave y oficina, y sin una taxonomía de criticidad coherente entre plantas, ninguno de los cuatro puntos anteriores puede reconstruirse en tiempo razonable. El asset manager se enfrenta entonces a tres caminos, todos malos. Fabricar las cifras a partir de estimaciones —peligroso, porque la CFO informada las detecta—. Presentar una propuesta cualitativa —aplazada por definición—. O encargar un estudio externo que produzca el dato ausente —caro, lento y con dependencia total del proveedor externo—. Ninguno de los tres construye capacidad para el año siguiente; en el ejercicio próximo, la misma conversación vuelve a bloquearse en el mismo punto.

Lo que un despliegue modular acumula para este momento

En Maptainer trabajamos con este perfil de operador desde la arquitectura modular: M01 inventario con criticidad tipificada, M02 correctivo con coste vinculado al activo específico, M03 preventivo con planificado versus ejecutado y M04 lecturas y captura firmada en campo. Ninguno de los cuatro módulos, aisladamente, produce el dato que sostiene una CAPEX de reposición defendible; los cuatro combinados durante dieciocho a veinticuatro meses sí. La propuesta CAPEX del tercer año es la consecuencia natural de haber capturado, con estructura, todo el correctivo, el preventivo, la lectura de operación y la trazabilidad de campo durante los dos años anteriores. La conversación con la CFO deja de ser una defensa de la partida presupuestaria y se convierte en una revisión conjunta de una serie de datos que ambas partes reconocen.

El KPI real del asset manager

El KPI real del asset manager no es la disponibilidad, que es un objetivo permanente, ni el coste unitario por activo, que es una consecuencia. Es la fracción de propuestas CAPEX aprobadas en primera presentación. Ese ratio depende menos del importe solicitado y más de la profundidad del dato que respalda cada petición. El asset manager que eleva ese ratio del cuarenta al setenta por ciento en dos ejercicios no ha aprendido a presentar mejor; ha construido, con paciencia modular, la base de datos que hoy responde a las preguntas que la CFO lleva haciendo desde el primer ejercicio. La CFO que aplaza no es difícil: está esperando exactamente el dato que el asset manager tendría que haber anticipado, y ese dato solo se acumula si la plataforma operativa lo ha estado capturando con la estructura correcta desde el arranque.