CMMS con Power BI: cómo diseñar tableros sin distorsionar KPI
Conectá tu CMMS con Power BI sin duplicar datos ni alterar KPI: modelo de datos, patrones de conexión, gobierno del refresh y conciliación hasta la OT.
Integrar un CMMS con Power BI permite cruzar la ejecución del mantenimiento con costos, producción, inventarios y otras fuentes corporativas. El riesgo aparece cuando el modelo de datos, las fórmulas y las fechas de corte no se acuerdan antes de construir los visuales.
La situación es conocida: el CMMS informa un nivel de cumplimiento preventivo y el tablero gerencial muestra otro. Uno cuenta órdenes y el otro tareas; uno excluye cancelaciones y el otro no; uno usa la fecha programada original y el otro la fecha de cierre. La reunión deja de analizar el desvío operativo y empieza a discutir qué cifra es válida.
Power BI no corrige por sí mismo las inconsistencias del dato fuente.
Una arquitectura confiable debe definir qué información se extrae, cómo se relaciona, dónde se calcula cada KPI y cómo se rastrea el resultado hasta los registros que lo originaron.
Cinco decisiones antes de conectar el CMMS con Power BI
Separá la gestión diaria de los análisis que combinan plantas o sistemas.
Documentá qué representa cada fila, las claves estables y el historial necesario.
Evaluá archivo, API o capa intermedia por volumen, latencia, historia y soporte.
Documentá población, fecha, exclusiones, propietario y versión.
Compará una muestra trazable, los casos de borde y la hora de extracción.
Lectura ejecutiva. El CMMS conserva la operación. Power BI se justifica al combinar fuentes, plantas o reglas corporativas, siempre con cálculo y trazabilidad gobernados.
Tablero del CMMS o Power BI: cómo decidir
El reporting del CMMS alcanza para órdenes abiertas, carga diaria, preventivos, materiales e historial del activo cuando se necesita actuar de inmediato.
Power BI se justifica para cruzar ERP y producción, consolidar plantas o unificar series históricas. A cambio, exige extracción, documentación, seguridad y pruebas.
| Criterio | Tablero del CMMS | Power BI | Enfoque combinado |
|---|---|---|---|
| Seguimiento diario | Adecuado para actuar sobre OT y recursos | Puede introducir latencia | CMMS como vista operativa |
| Cruce con ERP o producción | Depende de integraciones disponibles | Adecuado para varias fuentes | BI consolida; cada sistema conserva su proceso |
| Comparación multi-planta | Depende de la configuración | Adecuado para consolidación | Reglas comunes en el modelo semántico |
| Trazabilidad hasta la OT | Directa | Debe diseñarse | Power BI enlaza al registro fuente |
| Administración | Dentro del producto | Requiere BI, IT y Mantenimiento | Responsabilidades documentadas |
Cómo conectar un CMMS con Power BI: archivo, API o capa intermedia
Una prueba puede fallar en operación si depende de tareas manuales. El archivo manual sirve para análisis puntuales; la exportación programada requiere controlar formato e integridad.
La API automatiza cambios selectivos si existen entidades, historial, autenticación, paginación, filtros y límites adecuados. La capa intermedia sirve para varios sistemas, historia o múltiples reportes, pero agrega operación técnica.
| Patrón | Ventaja | Riesgo dominante | Uso razonable |
|---|---|---|---|
| Archivo manual | Baja barrera de entrada | Dependencia de una persona | Prueba o análisis puntual |
| Exportación programada | Automatización simple | Cambios de formato o archivos incompletos | Reporte periódico estable |
| API | Extracción selectiva y controlada | Límites, documentación y mantenimiento | Integración sostenida |
| Capa intermedia | Historia y combinación de fuentes | Mayor carga técnica | Operación multi-planta o varias fuentes |
Validá entidades, frecuencia e historial disponibles antes de diseñar el modelo.
Ver cómo OTEX lo resuelve →Modelo de datos para evitar OT y costos duplicados
Definí qué representa una fila
Una fila puede representar una OT, tarea, hora, repuesto o estado. Como no son equivalentes, deben permanecer en hechos separados conectados a dimensiones compartidas.
Duplicaciones que no parecen duplicados. Tres técnicos y cuatro repuestos no convierten una OT en doce. Contá desde órdenes y agregá horas y materiales desde hechos separados.
El esquema estrella, con hechos y dimensiones separados, es la estructura que Microsoft Learn recomienda para modelar datos en Power BI.
Gobierno de KPI y refresh: una definición compartida
“Cumplimiento preventivo” puede cambiar según unidad, fecha, cierre y tratamiento de cancelaciones. Mantenimiento aprueba la lógica, BI implementa y prueba, e IT asegura fuente y continuidad. La misma disciplina aplica a cualquier indicador de mantenimiento que se comparta entre áreas.
| Campo del diccionario | Definición requerida |
|---|---|
| Propósito | Decisión que debe sostener el indicador |
| Numerador y denominador | Registros y condiciones incluidas |
| Fecha de referencia | Programación, ejecución, cierre o corte |
| Estados y exclusiones | Cancelaciones, pruebas, duplicados y excepciones |
| Granularidad y propietario | Unidad de análisis y área que aprueba la definición |
| Versión y prueba de control | Fecha, motivo, impacto y muestra utilizada para validar |
Qué conviene calcular en cada entorno
OT abiertas, preventivos y costo directo suelen quedar en el CMMS. Costos contables, cumplimiento multi-planta, impacto productivo e historia del backlog pueden requerir Power BI. Si cambia la definición, debe cambiar el nombre.
La frecuencia de actualización depende de la decisión
Los vencimientos pueden requerir cargas intradía; los costos, una carga diaria o posterior al cierre. Import usa la última copia; DirectQuery depende del rendimiento y disponibilidad del origen, según documenta Microsoft Learn.
Advertencias de refresh. Mostrá última carga y zona horaria; contemplá reaperturas, imputaciones tardías, offline y cambios retroactivos. Más frecuencia no corrige una fecha mal definida.
Cómo conciliar Power BI con el CMMS y llegar hasta la OT
Registrá ambas horas para evitar diferencias entre ejecuciones.
Congelá fechas, estados, exclusiones y unidad de análisis.
Compará OT, tareas, activos y movimientos antes de la fórmula.
Segmentá por planta y periodo; probá cancelaciones, reaperturas, reprogramaciones y datos tardíos.
Clasificá la causa y registrá la aprobación funcional y técnica.
Ejemplo multi-planta: la reprogramación cambia el denominador
En un escenario hipotético, tres plantas reprograman de forma distinta. Si Power BI usa la fecha vigente, el tablero también compara prácticas de registro.
| Síntoma | Causa | Corrección | Control |
|---|---|---|---|
| Mayor cumplimiento aparente | La reprogramación traslada el denominador | Definir fecha original o vigente | Auditar OT reprogramadas |
| Más cancelaciones | Se crea una OT nueva para reprogramar | Separar cancelación de replanificación | Revisar motivo y orden sucesora |
| CMMS y Power BI difieren | Usan fechas o estados distintos | Alinear diccionario y corte | Conciliación periódica |
| La serie histórica cambia | La fecha se sobrescribe | Conservar historial o snapshots | Controlar variaciones retroactivas |
La tensión también aparece en permisos de Oil & Gas, ventanas sanitarias o SLA pausados.
Seguridad, adopción y controles antes de producción
Los permisos se definen por rol, planta y detalle. Un enlace a la OT debe revalidarlos en el CMMS.
La adopción exige validadores, canal de diferencias, convivencia, retiro y responsables. Repetí pruebas tras cambios de CMMS, API o modelo.
Ocho errores que debilitan el tablero
Checklist mínimo antes de publicar
Dejá tu email y te lo mandamos, listo para repasar con BI e IT antes de publicar el tablero.
Al enviar tu email aceptás nuestra Política de Privacidad.
Con trazabilidad hasta las OT, la reunión vuelve a causas, riesgos y capacidad de ejecución.
Revisá la arquitectura antes de ampliar el tablero
Si el CMMS y Power BI muestran valores distintos, una revisión técnica de fuente, granularidad, refresh y reglas de cálculo ayuda a identificar la causa antes de extender el reporte a otras plantas o áreas.
