En logística existe un concepto que todo el mundo entiende de inmediato: la "última milla" es el tramo final de la entrega — el que va del centro de distribución a la puerta del cliente. Es, casi siempre, el tramo más caro, más impredecible y más difícil de controlar de toda la cadena, aunque sea el más corto en distancia.
El mantenimiento de activos tiene exactamente el mismo problema, solo que casi nadie lo llama así. Existe una orden de trabajo, perfectamente planificada, con su activo asociado, su plan preventivo y su prioridad definida dentro de un sistema corporativo robusto. Y existe, en algún punto entre esa pantalla y la realidad, un técnico parado frente a un equipo, con una llave de tuercas en la mano, que tiene que ejecutar ese trabajo, dejar evidencia de que lo hizo y — si trabaja para un contratista externo — demostrarle a alguien que el servicio se cumplió a cabalidad. Ese tramo final es la última milla del mantenimiento. Y es, casi siempre, el tramo que los grandes sistemas de gestión de activos nunca terminaron de resolver.
Lo que SAP, Maximo y Oracle hacen realmente bien
Vale la pena decirlo con claridad antes de seguir: SAP Plant Maintenance, IBM Maximo y Oracle Fusion Cloud Maintenance son sistemas serios, probados en operaciones industriales de enorme escala, y no existen por accidente. Resuelven un problema real y difícil — la planificación de activos, presupuestos, jerarquías de mantenimiento y cumplimiento normativo a nivel de toda una corporación, muchas veces con miles de equipos distribuidos en distintos países. Ese es un trabajo distinto, y lo hacen bien.
El problema no es la calidad de esos sistemas. El problema es dónde termina su alcance real.
Dónde termina el alcance de un ERP de mantenimiento
Estos sistemas fueron diseñados desde la perspectiva de la organización interna de mantenimiento de la empresa dueña del activo: el planificador que arma la orden, el presupuesto que la autoriza, el inventario de repuestos que la respalda. Todo eso vive dentro de la lógica corporativa del sistema, y todo eso funciona razonablemente bien mientras el trabajo se quede dentro de esa organización.
Pero una porción enorme del mantenimiento real no se ejecuta con personal interno. Se subcontrata: climatización, ascensores, protección contra incendios, electromecánica, jardinería industrial, limpieza técnica, y decenas de especialidades más que terminan en manos de un contratista externo que no tiene, y nunca va a tener, un usuario dentro de ese sistema corporativo. El ERP genera la orden. Después de eso, lo que pasa en terreno — quién fue, cuándo llegó, qué hizo, si cumplió el SLA, si el cliente firmó conforme — ocurre fuera de la vista del sistema que planificó el trabajo.
El caso Maximo: contratos sí, desempeño operativo en vivo no
Este no es un argumento abstracto. Es, de hecho, un punto documentado sobre uno de los sistemas más robustos de la categoría: IBM Maximo administra bien los contratos con proveedores externos — los términos, las condiciones, los acuerdos marco. Lo que no entrega de forma nativa es el desempeño operativo en vivo de esos contratos: para tener una vista completa de qué está haciendo realmente un contratista en un momento dado, hay que combinar información que vive en más de un sistema distinto.
Maximo gestiona el contrato. No gestiona, por sí solo, la ejecución diaria del contratista en terreno — eso vive en otro lugar, o en ningún lugar sistematizado en absoluto.
Esa es la brecha de la última milla, descrita con precisión: el contrato está en el sistema. La ejecución no.
Qué es exactamente "la última milla" en mantenimiento
Concretamente, la última milla del mantenimiento es todo lo que ocurre entre que una orden de trabajo se crea y que ese trabajo queda demostrado como completado a satisfacción de quien lo pidió. Incluye, como mínimo:
- Que la orden llegue de forma clara al técnico o cuadrilla correcta, con la información que necesita para ejecutarla.
- Que exista una forma de saber, en tiempo real, si esa cuadrilla ya llegó, está en curso o terminó.
- Que el cierre del trabajo quede acompañado de evidencia — fotos, checklist, mediciones — y no solo de un estado cambiado a "resuelto".
- Que exista una firma o conformidad del cliente o del responsable del activo, con valor probatorio si después hay una disputa de facturación o de cumplimiento de SLA.
- Que toda esa información quede trazada en un solo lugar, no repartida entre un grupo de WhatsApp, una carpeta de PDFs y la memoria del supervisor.
Ninguno de esos cinco puntos es exótico. Son, literalmente, la definición operativa de "el trabajo se hizo bien". Y sin embargo, son exactamente los puntos que un sistema de planificación corporativa — construido para presupuestar y programar mantenimiento interno — no fue diseñado para resolver.
Por qué esta brecha existe, y por qué no es un descuido
No es que SAP, Maximo u Oracle "se olvidaron" de la última milla. Es que resolverla bien requiere un producto con una lógica distinta: pensado para el técnico que trabaja con una app en el teléfono, muchas veces sin conexión estable, dentro de una cuadrilla que puede estar atendiendo contratos de varios clientes distintos el mismo día. Adaptar un ERP de planificación corporativa a ese uso es posible en teoría, pero en la práctica implica proyectos de configuración largos, equipos de consultoría especializados y curvas de adopción que no encajan con la realidad de un contratista de tamaño mediano que necesita operar mañana, no en seis meses.
Esa fricción no es un defecto oculto de estos sistemas — es la consecuencia lógica de haber sido diseñados para otro problema, y resuelto ese problema muy bien.
Quién vive esta brecha todos los días
Esta brecha la sienten dos tipos de organizaciones, desde extremos opuestos de la misma orden de trabajo:
Las empresas de servicio y contratistas la viven cuando reciben una orden de un cliente que administra sus activos en un sistema grande, y no tienen — ni deberían necesitar — una licencia dentro de ese sistema para poder despachar su cuadrilla, cotizar el trabajo y entregar un certificado firmado. Terminan improvisando ese flujo entero por fuera: WhatsApp para coordinar, Excel para llevar el estado, PDF por correo para el cierre.
Los administradores de propiedades y activos la viven desde el otro lado: su equipo interno planifica bien dentro del ERP corporativo, pero una parte importante del trabajo real la ejecutan contratistas externos que quedan fuera de esa visibilidad. El resultado es el mismo problema que describe la cita sobre Maximo: para saber qué está pasando de verdad con un proveedor externo, hay que ir a buscar la información a otro lado.
Cerrar la brecha sin reemplazar lo que ya funciona
La respuesta razonable a esta brecha no es reemplazar un sistema corporativo que cumple bien su función de planificación y presupuesto — sería un proyecto enorme y, para la mayoría de las organizaciones, una mala inversión. La respuesta es reconocer que la última milla necesita una capa distinta, construida específicamente para la ejecución en terreno por parte de contratistas y cuadrillas externas: dispatch móvil, evidencia fotográfica, checklist digital, certificado de conformidad firmado por el cliente, y visibilidad en vivo de qué está pasando con cada contrato, sin depender de que alguien reporte manualmente al final del día.
Ese es exactamente el espacio en el que Prexira está diseñado para operar: no como reemplazo del sistema de planificación corporativa, sino como la capa que cubre el tramo final que ese sistema nunca llegó a alcanzar. Hoy, esto significa que Prexira funciona junto a esos sistemas — de forma independiente, no conectada técnicamente a ellos — cubriendo el lado de la ejecución mientras el ERP corporativo sigue cubriendo el lado de la planificación.
La brecha es real, y es más común de lo que parece
Cada vez que una orden de trabajo pasa de una pantalla de planificación a un técnico real, hay una última milla que recorrer. La mayoría de las organizaciones — tanto las que contratan mantenimiento como las que lo prestan — la resuelven hoy con herramientas improvisadas, precisamente porque el sistema que planificó el trabajo no llega hasta ahí. Nombrar esa brecha es el primer paso para dejar de aceptarla como algo inevitable, y empezar a tratarla como lo que es: un problema de producto, con una solución de producto.