Migrar datos de Excel a un CMMS: limpieza, mapeo, carga piloto y validación

El proveedor pidió “el Excel de activos”. Lo que sale del servidor de la planta son tres archivos: uno con 1.400 filas donde la columna EQUIPO se escribió a mano libre durante seis años, otro con los preventivos que armó un jefe de mantenimiento que ya no está en la empresa, y un tercero de repuestos donde el mismo rodamiento aparece con cuatro descripciones distintas según quién lo cargó. Nadie sabe si ese material está en condiciones de cargarse, ni cómo se comprobaría que quedó bien.

Migrar datos de Excel a un CMMS no consiste en exportar e importar. Son seis trabajos encadenados —definir el alcance, perfilar, limpiar, mapear, cargar un piloto y validar— y el que determina la calidad del resultado es el mapeo, no la herramienta de importación. Este artículo recorre esos seis pasos con los criterios de decisión de cada uno.

La carga se define en la hoja de mapeo. El botón de importar solo ejecuta lo que alguien decidió antes.

Si todavía estás evaluando si conviene dejar la planilla, esa discusión está resuelta en cuándo migrar de Excel a un CMMS sin perder adopción. Si lo que falta es definir qué datos necesitás tener antes de arrancar el proyecto, el punto de partida es el checklist de datos mínimos para implementar un CMMS. Acá damos por hecho que el sistema ya está elegido y que alguien tiene que entregar un archivo cargable.

Qué incluye una migración de datos y qué no

El primer error de alcance aparece cuando se trata a todos los datos de la planilla como si fueran lo mismo. No lo son, y cada grupo se migra con reglas distintas.

La distinción tiene una consecuencia práctica inmediata: si el maestro de activos entra con duplicados, todo el dato transaccional que se cargue después queda asociado al registro equivocado. Por eso el orden no se negocia. Primero ubicaciones y activos, después repuestos y planes, y recién al final cualquier cosa que tenga fecha.

Paso 1. Congelar el alcance: qué se migra, qué se carga a mano y qué se archiva

Antes de abrir el archivo conviene cerrar una lista de decisiones por dominio. La regla que mejor filtra es simple: si nadie va a mantener ese dato actualizado dentro de seis meses, no entra al sistema.

Esta tabla se llena una sola vez, se firma y deja de discutirse. Cada vez que el alcance se reabre en mitad de la limpieza, el trabajo hecho hasta ahí pierde validez.

Paso 2. Perfilar la planilla antes de tocar un dato

Perfilar es medir el estado del archivo antes de modificarlo. Se hace con Excel, sin herramientas adicionales, y toma menos de una jornada por solapa. La salida no es una opinión sobre la calidad del archivo: es una cuenta.

El resultado de estos seis chequeos es lo que permite estimar el trabajo real. Un maestro de 1.400 filas con 12 % de TAG vacíos y 180 duplicados semánticos no se limpia en una tarde, y saberlo antes de comprometer una fecha de go-live evita la conversación incómoda tres semanas después.

Paso 3. Limpieza: qué duplicado gana y qué se hace con lo que falta

La limpieza tiene dos decisiones que nadie explica y son las que traban el trabajo.

Qué registro gana cuando hay duplicados. La respuesta intuitiva es “el más completo”, y suele ser la equivocada. Si de las tres variantes de la bomba centrífuga una tiene diez OT históricas asociadas y otra tiene la ficha técnica cargada, conviene quedarse con la que arrastra el historial y completarle los campos técnicos desde la otra. Elegir al revés obliga a reasignar registros después, cuando ya están cargados. Criterio práctico: gana el registro con más vínculos, no con más campos.

Qué se hace con un campo obligatorio vacío. Acá hay una sola regla que no admite excepción: no se inventa. Si 200 activos no tienen criticidad asignada, hay tres salidas legítimas —relevarla antes de cargar, cargar un valor por defecto dejando una marca visible de “criticidad sin revisar”, o postergar esos activos a una segunda tanda— y ninguna consiste en que alguien complete la columna a ojo un viernes a la tarde. Una criticidad inventada no se nota en la carga: se nota seis meses después, cuando el plan preventivo se construyó sobre ella. Los criterios para asignarla están desarrollados en el checklist de datos mínimos.

La normalización de nombres y códigos merece una aclaración de alcance. Si la nomenclatura todavía no está definida, la limpieza no puede empezar, porque no hay contra qué normalizar. Lo mismo con las ubicaciones: el destino de la columna SECTOR es una posición dentro de una jerarquía que ya tiene que existir, con los criterios del árbol de activos industriales. Si la planta ya trabaja con una taxonomía de equipos alineada con ISO 14224, ese es el destino natural del mapeo y ahorra la discusión sobre familias de equipos.

Una advertencia sobre cuándo parar. La limpieza no termina cuando el archivo está perfecto, porque no va a estarlo. Termina cuando todos los campos obligatorios están resueltos o marcados, y los duplicados de activos y repuestos están fusionados. Los campos opcionales incompletos se completan en operación; los duplicados, no.

Paso 4. La hoja de mapeo: columna de origen, campo destino, regla

Este es el entregable central de la migración y el que casi nunca se produce. Es una tabla donde cada columna del Excel tiene asignado un campo del CMMS, una regla de transformación y un responsable. Se arma antes de la primera importación y la firman juntos mantenimiento y quien ejecute la carga.

Las dos filas destacadas son las que revelan si el mapeo está bien hecho. Un campo destino obligatorio sin columna de origen significa que hay relevamiento pendiente en planta, y conviene saberlo antes de comprometer una fecha. Una columna de origen sin campo destino puede ser información descartable —o puede ser el filtro que evita cargar 90 equipos que ya no existen—.

Reglas de transformación frecuentes en mantenimiento

Estas seis conversiones aparecen en prácticamente todas las planillas de mantenimiento y conviene resolverlas en el archivo de origen, no durante la importación.

Las frecuencias merecen una revisión de fondo más allá del formato: una migración es un buen momento para confirmar que los planes que se están cargando siguen teniendo sentido, con los criterios de un plan de mantenimiento preventivo. Migrar un preventivo vencido hace tres años solo lo hace visible en una pantalla nueva.

Paso 5. Carga piloto: qué subconjunto elegir y qué mirar

El piloto de datos no es lo mismo que el piloto operativo del proyecto. El piloto operativo elige un área de la planta para arrancar a trabajar; el piloto de datos elige un subconjunto para comprobar que el mapeo funciona, y puede correrse semanas antes.

La composición importa más que el volumen. Un subconjunto útil incluye una familia de equipos con su jerarquía completa hasta el nivel que se decidió mantener, sus repuestos asociados, al menos un plan preventivo con disparador de calendario y otro con disparador por uso, y algún activo de los “difíciles”: el que tiene el nombre más sucio, el que no tiene TAG, el que está duplicado. Cargar los primeros 300 registros de la solapa no prueba nada, porque comparten los mismos defectos entre sí.

Cada error encontrado en el piloto se corrige en la hoja de mapeo, no en el archivo cargado. Corregir a mano el registro cargado deja el error intacto para la tanda completa.

Paso 6. Validar la carga: cómo se comprueba y cuándo se acepta

Esta es la parte que más se saltea y la que decide si el sistema arranca con datos confiables. Validar no es “mirar si se ve bien”. Son tres comprobaciones con criterios de aceptación definidos de antemano.

Qué hacer con el historial de la planilla

Diez años de OT en Excel no se migran ni se tiran: se clasifican. Hay tres destinos posibles y la elección depende de para qué se va a usar el dato, no de cuánto cuesta cargarlo.

Cualquier cosa que se migre necesita quedar marcada con su origen. El motivo es concreto: el MTBF y el cumplimiento del preventivo del primer trimestre van a mezclar registros cargados a mano desde una planilla —con fechas aproximadas y duraciones estimadas— con registros capturados en campo al cerrar la OT. Si el tablero no permite separar unos de otros, el primer análisis de indicadores de mantenimiento va a estar describiendo la calidad de la planilla vieja en lugar de la operación actual. Con una marca de origen, esa distorsión se filtra; sin ella, se discute en una reunión.

De acá en adelante el criterio cambia: lo que se registra en cada intervención nueva ya no depende de qué había en el Excel, sino de lo que el equipo defina como historial técnico útil por activo.

El delta: qué pasa entre la foto de datos y el arranque

Entre el día que se exporta el archivo y el día que el sistema abre pasan semanas. En esas semanas la planta sigue funcionando: se dan de alta dos equipos, se cambia la ubicación de otro, se cierran cuarenta OT en la planilla vieja. Ese diferencial es el delta, y si nadie lo administra reaparece como inconsistencias el primer mes.

La ventana de doble carga —planilla y sistema al mismo tiempo— conviene acotarla y anunciarla con fecha. Cuándo cerrar definitivamente las planillas anteriores es una decisión del arranque, tratada en la guía de implementación sin frenar la operación.

Errores de migración que se repiten en planta

Después de la carga: que el desorden no vuelva

Una migración limpia se degrada en seis meses si nada impide que vuelvan los duplicados. Cuatro decisiones, tomadas en la misma semana del arranque, sostienen el trabajo: que solo un rol pueda dar de alta activos y repuestos, que el alta pida los campos obligatorios en vez de permitir guardar incompletos, que exista una revisión periódica de altas recientes, y que cada dominio de datos tenga una persona responsable de su calidad.

El régimen permanente de reglas, catálogos y validaciones es un tema propio y excede a la migración. Lo que sí pertenece al cierre del proyecto es que esas cuatro definiciones queden asignadas antes de que el equipo empiece a usar el sistema todos los días, porque después compiten con la operación. La disciplina de carga tiene su propia dinámica, tratada en adopción del CMMS en el equipo técnico.

Una migración se puede dar por cerrada cuando se cumplen cuatro condiciones: la hoja de mapeo está completa y firmada, la conciliación de conteos cierra, los activos críticos están revisados campo por campo y la prueba funcional se completó sin tocar el dato migrado. Si alguna falta, lo que hay es un archivo cargado, no un maestro validado.

El reparto de trabajo también conviene dejarlo explícito antes de empezar. Las decisiones son del cliente —alcance, criticidad, nomenclatura, qué duplicado gana, qué histórico entra— porque esa información no está en el archivo y no hay forma de deducirla desde afuera. La ejecución —transformación, carga, reporte de rechazos, conciliación— es donde un equipo de implementación ahorra semanas. Confundir los dos lados es lo que produce maestros cargados que técnicamente funcionan y que nadie usa.