Fase 1
Sus fuentes y su taxonomía
Revisamos una muestra de cada fuente, fijamos la especificación de entrada y validamos con su equipo las categorías de causa.
Confiabilidad de activos · Python en el navegador
fiabilidad
por Hernán Elías Sánchez · parte de su portafolio Control de gestión, construido como software
Un modelo que cruza las detenciones de una planta con su plan y su ejecución de mantenimiento, muestra dónde la mantención no está funcionando y propone un plan ajustado, con cada cambio justificado.
Equipos que fallan aunque se mantengan
Una planta registra cerca de 100.000 detenciones al año, pero nadie las cruza con lo que hace mantenimiento. Así no se sabe si una mantención sirvió, si se cambian piezas que todavía tenían vida o si una pieza falla antes de lo que promete el fabricante.
Este recorrido muestra, con una planta de ejemplo, qué haría el modelo con sus datos y qué recibiría al final. Son cinco pasos y toma unos tres minutos.
- 1 Usted entrega lo que ya tiene
- 2 Separamos lo relevante del ruido
- 3 Respondemos cuatro preguntas
- 4 Proponemos un plan ajustado
- 5 Lo que recibe
Comenzar el recorrido ↓ Probar con mis archivos
🔒 Todo corre dentro de su navegador o de su propio equipo: los archivos de la planta no se envían a ningún servidor.
Paso 1 de 5
Usted entrega lo que ya tiene
Cuatro archivos que hoy salen del sistema de mantenimiento (por ejemplo, SAP PM) y del registro de turnos. No hay que ordenarlos a mano: el modelo los valida y, si algo no calza, dice exactamente qué fila y qué columna revisar.
Las fuentes adicionales (horómetros, repuestos, inspecciones en terreno…) se suman con el mismo método: una especificación por archivo y su llave de cruce.
Paso 2 de 5
Separamos lo relevante del ruido
La mayoría de las detenciones son microparadas. Filtramos las que importan y clasificamos cada una en una taxonomía cerrada, acordada con su equipo: el modelo nunca inventa una categoría.
¿Por qué se detuvo? Eventos relevantes por causa
Paso 3 de 5
Respondemos cuatro preguntas
Cruzamos fallas, plan y órdenes de trabajo componente por componente. Cada respuesta trae la evidencia: qué componente, qué fecha y qué OT.
Paso 4 de 5
Proponemos un plan ajustado, cambio por cambio
¿Cuánto duran de verdad las piezas?
La vida de referencia mezcla la del fabricante con la observada en su planta. Con pocas fallas manda la del fabricante; con muchas, manda la realidad (así un caso aislado no cambia el plan).
Dónde mirar primero
Paso 5 de 5
Lo que recibe
Cada entregable que pide el proyecto ya existe en este demo, con datos de ejemplo. Con sus datos, la diferencia es que la taxonomía y las reglas se ajustan con su equipo.
| Entregable | Qué es | Véalo en el demo |
|---|---|---|
| Script ejecutable del modelo | Corre con cada nuevo antecedente, en la terminal o en el navegador | Probarlo aquí · código |
| Especificación de archivos de entrada | Columnas, tipos y llaves de cada archivo, con validación automática | especificación |
| Taxonomía validada | Categorías cerradas de causa, con sus palabras clave | taxonomía de ejemplo |
| Catálogo de reglas extensible | Cada regla con sus parámetros; sumar una no cambia el modelo | reglas · cómo funcionan |
| Informe de observaciones | Brechas, prioridades por componente y vida útil por tipo | Se descarga al analizar (informe.md) |
| Plan de mantenimiento propuesto | Mismo formato que su plan, con cada cambio justificado | Se descarga al analizar (plan_mantenimiento_ajustado.csv) |
| Documentación | Uso, modelo, reglas y módulo LLM | README y docs |
Pruébelo
Analice la planta de ejemplo en vivo o cargue sus cuatro CSV. La primera vez se descarga Python al navegador (unos 6 MB) y el análisis toma segundos.
Se reconocen por el nombre: catalogo_componentes, plan_mantenimiento,
mantenciones_ejecutadas y eventos_denegacion. Columnas en la
especificación de entradas.
🔒 Ecosistema cerrado: el análisis corre con Python dentro de esta pestaña. Los archivos se leen en su equipo y no se envían a ningún servidor.
Resultado
Brechas
Componentes prioritarios
Cada falla pesa 3, cada OT no ejecutada o atrasada 1, y los recambios redundantes 2 por componente.
Plan ajustado: cambios propuestos
Vida útil por tipo de componente
Cola de revisión
Cómo trabajaríamos
Fase 2
Modelo sobre sus datos
Reglas calibradas con sus tolerancias, brechas, observaciones y plan ajustado, con pruebas automatizadas y una muestra revisada en terreno.
Fase 3
Más fuentes y seguimiento
Sumamos las fuentes pendientes y, si sirve, un tablero en Power BI para seguir las brechas mes a mes.
Cada fase cierra con un entregable usable y documentado. El LLM es opcional: si se usa, corre en un modelo local y solo revisa los textos que las reglas no alcanzan a clasificar.
Para el equipo técnico
- Ingesta y validación: cada archivo se revisa contra su especificación; si algo no cumple, se rechaza con la lista de problemas antes de analizar.
- Filtrado: solo los eventos de 15 minutos o más (parámetro configurable).
- Clasificación con taxonomía cerrada: palabras clave con un puntaje de confianza. Lo que no alcanza la confianza mínima va a la cola de revisión.
- Cruce: fallas, plan y OT por componente; la edad de cada pieza se mide desde su último recambio o correctiva.
- Cuatro reglas de brecha: mantención no ejecutada o atrasada; falla hasta 15 días después de una mantención; recambio con menos del 60% de la vida útil consumida y sin fallas; falla antes de la vida útil nominal.
- Plan ajustado: alarga los recambios redundantes, acorta la inspección y propone recambio preventivo donde la pieza falla antes de tiempo. La vida de referencia mezcla la nominal con la observada por credibilidad.
Python sin dependencias: el mismo código corre en los tests, en la terminal y en esta página con Pyodide. Con los datos de ejemplo, los tests exigen encontrar exactamente las 226 brechas sembradas: ni una de menos, ni una de más. El módulo LLM (Ollama local) está en docs/llm.md.
Portafolio
Control de gestión, construido como software · sitios de Hernán Elías Sánchez: cada uno muestra una parte del mismo oficio.
La vitrina
centinela
Reportes Power BI de control de gestión, personas, compensaciones, pricing, capital de trabajo, contratistas y mantenimiento, con datos sintéticos, el modelo y el DAX a la vista.
El taller
consulta
SQL, perfilado y gráficos sobre CSV, Parquet o Excel, sin que el archivo salga de tu equipo.
El manual
cartilla
Python y pandas para quien viene de Excel, con ejemplos que se ejecutan en el navegador.
El modelo Estás aquí
fiabilidad
Mantenimiento contra fallas: cuatro brechas detectadas y un plan ajustado con cada cambio justificado.
Acerca de
Soy Ingeniero Civil Industrial con 8 años en control de gestión. En Abastible trabajé con SAP PM para controlar la ejecución de mantenimiento de contratistas y en Gruman tuve a cargo la planificación y el personal de mantención. Este modelo junta ambas miradas: el plan, lo que de verdad se ejecutó y lo que siguió fallando.