Cómo reemplazar planillas sin detener la operación

Hay un momento en la vida de una empresa en que las planillas que alguna vez fueron la solución se convierten en el problema. El archivo pesa demasiado y tarda en abrir. Dos personas no pueden editar al mismo tiempo sin que aparezcan versiones en conflicto. Las fórmulas que alguien armó hace tres años se rompen sin que nadie sepa por qué, y la única persona que las entiende ya no trabaja en la empresa.

Llegado ese punto, reemplazar las planillas por un sistema de gestión ya no es una opción: es una necesidad. Pero el miedo a detener la operación durante la transición —o a implementar un sistema que el equipo rechace— posterga la decisión meses, a veces años, mientras las planillas siguen degradándose.

Esta es la historia de una empresa que hizo esa transición sin detener la operación un solo día. No porque tuvieran un método infalible, sino porque siguieron tres principios que cualquiera puede aplicar.

Principio 1: No reemplazar todo de una vez

El error más común al migrar de planillas a un sistema es intentar reemplazar todas las planillas al mismo tiempo. La lógica parece razonable: si vas a implementar un sistema nuevo, que cubra todo desde el primer día. Pero en la práctica, ese enfoque produce exactamente lo que se quiere evitar: parálisis operativa, datos inconsistentes, y un equipo que abandona el sistema nuevo y vuelve a las planillas viejas.

La empresa de esta historia tomó el camino opuesto: migró de a una planilla por vez, empezando por la que generaba más dolor.

La planilla elegida era la de seguimiento de pedidos. Cada pedido pasaba por múltiples estados —recibido, en preparación, despachado, entregado, facturado— y cada cambio de estado requería que alguien actualizara manualmente la planilla. Con veinte pedidos diarios, era manejable. Con sesenta, el equipo pasaba más tiempo actualizando estados que gestionando los pedidos. Además, como la planilla era un archivo compartido, solo una persona podía editarla a la vez: si alguien se olvidaba de cerrarla al terminar, el resto del equipo quedaba bloqueado hasta que apareciera el dueño del archivo.

Esa planilla se migró primero. Durante la migración, las demás planillas —inventario, facturación, clientes— siguieron funcionando como siempre. El equipo no tuvo que aprender un sistema completo: aprendió una sola funcionalidad nueva, la que más les dolía mantener en Excel. La adopción fue inmediata porque el sistema resolvía un problema que todos sufrían a diario.

Recién cuando esa primera migración estuvo estable —tres semanas sin incidentes—, se migró la siguiente planilla. La transición completa tomó cuatro meses, pero la operación nunca se detuvo. Para una discusión más amplia sobre cuándo es el momento de abandonar las planillas, el artículo sobre cuándo dejar de usar planillas ofrece criterios concretos para tomar esa decisión.

Principio 2: Limpiar los datos antes de migrarlos

Las planillas que llevan años de uso acumulan inconsistencias que quienes trabajan con ellas todos los días ya no ven. Clientes con el nombre escrito de tres maneras distintas según quién los ingresó. Fechas en formatos que varían —a veces día/mes/año, a veces mes/día/año—. Campos que deberían ser numéricos pero contienen texto porque alguien escribió "pendiente" en lugar de dejar la celda vacía. Productos que en una hoja se llaman de una manera y en otra de otra.

Migrar esos datos sin limpiarlos primero es trasladar el desorden de un lugar a otro. La empresa dedicó dos semanas a limpiar los datos de la planilla de pedidos antes de migrarlos al sistema nuevo. El proceso fue simple pero metódico:

1. Identificar y unificar los valores de cada columna que debían ser consistentes: nombres de clientes, códigos de producto, estados de pedido. Para cada columna, se definió un conjunto de valores válidos y se reemplazaron las variantes por el valor canónico.

2. Detectar y corregir los datos faltantes. Campos obligatorios vacíos, pedidos sin cliente asignado, fechas de entrega sin completar. Algunos se pudieron completar con información de otras fuentes; otros se marcaron como "a revisar" y se dejaron fuera de la migración inicial.

3. Eliminar las filas duplicadas. Pedidos que aparecían dos veces porque alguien los había copiado de otra hoja, o porque una importación anterior había fallado a la mitad y se había vuelto a ejecutar sin limpiar los registros parciales.

El esfuerzo de limpieza fue proporcional al beneficio: los datos que entraron al sistema nuevo eran consistentes desde el primer día, lo que evitó que el equipo encontrara errores apenas empezó a usar la herramienta —el escenario que con más frecuencia genera rechazo y vuelta atrás—.

Principio 3: Que el equipo vea el beneficio antes de sentir la obligación

La resistencia al cambio no se vence con capacitación ni con comunicación interna. Se vence cuando la persona que va a usar el sistema nuevo descubre que le resuelve un problema concreto que sufre todos los días.

La empresa aplicó esto de una manera deliberada: durante las primeras dos semanas posteriores a cada migración, el sistema nuevo funcionaba en paralelo con la planilla vieja. El equipo podía usar el que prefiriera. Nadie estaba obligado a migrar.

Lo que ocurrió fue que, en menos de una semana, el equipo dejó de usar la planilla vieja voluntariamente. No porque alguien se los pidiera, sino porque el sistema nuevo era objetivamente mejor para la tarea que estaban haciendo: no se bloqueaba, no requería buscar la versión más reciente del archivo, no los obligaba a recordar qué fórmula calcular. La planilla vieja quedó como respaldo durante esas dos semanas, y después se archivó sin que nadie protestara.

Esta estrategia de adopción voluntaria solo funciona si el sistema nuevo es efectivamente mejor para quien lo usa. Si la migración se hace para beneficiar a la gerencia —reportes más fáciles, mejor visibilidad— pero le complica la vida a quien opera, la adopción voluntaria fracasa y hay que recurrir a la imposición, con el costo cultural que eso implica.

El artículo sobre cuándo una planilla de Excel deja de ser suficiente detalla señales de que las planillas están frenando a la empresa y no solo molestando a quien las opera. Y si la empresa ya decidió migrar pero el proceso que está digitalizando es caótico, conviene leer antes sobre el error de digitalizar un mal proceso sin mejorarlo primero: migrar el caos de Excel a un sistema nuevo no resuelve el caos.

Lo que no funcionó (y lo que se corrigió)

No todo salió bien a la primera. Dos cosas fallaron y requirieron ajuste.

La primera fue subestimar la cantidad de datos históricos que el equipo necesitaba consultar. La planilla de pedidos tenía tres años de registros, y aunque la mayoría eran irrelevantes para la operación diaria, los vendedores consultaban pedidos de meses atrás para verificar acuerdos con clientes, resolver disputas sobre precios y preparar propuestas de renovación. La migración inicial solo incluyó los pedidos activos —los de los últimos tres meses— y dejó los históricos en la planilla vieja. En la práctica, los vendedores terminaban abriendo la planilla vieja varias veces por día para consultar datos que no estaban en el sistema nuevo. La solución fue migrar también los pedidos históricos, aunque sin el mismo nivel de limpieza: se aceptó que algunos datos antiguos tuvieran pequeñas inconsistencias a cambio de que los vendedores dejaran de necesitar la planilla vieja.

La segunda fue la integración con otros sistemas. La planilla de pedidos se alimentaba, en parte, de datos que venían de la plataforma de facturación. Durante la migración, esos datos se migraron manualmente, pero nadie se ocupó de automatizar la conexión para que, en adelante, los datos nuevos fluyeran automáticamente entre ambos sistemas. A las pocas semanas, los datos del sistema nuevo ya estaban desactualizados respecto de la plataforma de facturación, y alguien del equipo —el mismo que antes actualizaba la planilla— empezó a actualizar manualmente el sistema nuevo. El ciclo se estaba repitiendo. La solución fue implementar una integración automática entre ambos sistemas, que se construyó después de la migración principal pero que era, en realidad, parte indispensable del proyecto.

La lección de estos tropiezos es que migrar de planillas a un sistema no termina cuando los datos están en el sistema nuevo. Termina cuando el sistema nuevo está integrado con las demás herramientas que usa la empresa y cuando el equipo dejó de necesitar las planillas viejas para hacer su trabajo. Cualquier cosa menos que eso es una migración incompleta que va a requerir una segunda vuelta.

Reemplazar planillas sin detener la operación es posible. Requiere paciencia, requiere migrar de a una, requiere limpiar los datos antes de moverlos, y requiere que el sistema nuevo sea objetivamente mejor para quien lo usa. Si esas condiciones se cumplen, la operación no se detiene: simplemente deja de depender de un archivo que ya no daba abasto.