La sexta parte trató del informe: cómo deja de ser un archivo que montas durante dos días y se convierte en una vista que abres sobre el momento actual. Con ello se completa el panorama que hemos construido a lo largo de seis partes: cuándo una hoja de cálculo deja de ser la respuesta, qué archivo dirige realmente la empresa, la limpieza de los datos antes de migrarlos, el orden en que se migran las cosas, quién ve qué y el fin del informe hecho a mano.

Queda la parte que decide si todo eso da fruto: el primer mes en producción. Y hay algo que sabe cualquiera que haya llevado un proyecto así. La mayoría de las migraciones no fracasan durante la construcción. Fracasan en las primeras semanas de uso. El sistema funciona, los datos están ahí, las pantallas son correctas y, aun así, el trabajo real vuelve discretamente al archivo antiguo. Esta parte trata de por qué ocurre y de un plan que lo evita.

La resistencia no es terquedad, es un cálculo de riesgo

Lo primero con lo que te encuentras en la primera semana es la vacilación del equipo. El error habitual es que el dueño interprete esa vacilación como resistencia al cambio o pereza y responda con presión. Normalmente no es ni una cosa ni la otra.

El empleado que antes abría un archivo y terminaba la tarea en dos minutos ahora necesita diez para aprender el recorrido por la misma pantalla. Desde su posición, está pagando hoy el coste de un beneficio del que le han hablado pero que todavía no ve, y responde ante su jefe por el trabajo de hoy, no por el éxito del proyecto. La vacilación es totalmente racional.

Se intensifica cuando el dueño del archivo antiguo es alguien cuya posición en la empresa se construyó sobre conocerlo. Quien era la única referencia de un archivo puede temer que el sistema vuelva innecesario su papel. Ignorar ese temor no lo elimina; lo vuelve subterráneo. Abordarlo de frente funciona mejor: dale a esa persona un papel declarado en el nuevo esquema como responsable de la calidad de los datos de su área, para que pase de custodiar un archivo a ser la referencia de los propios datos.

El cambio verdadero del primer mes es que el trabajo se ha vuelto visible. Cuando los datos vivían en un archivo, un registro tardío era invisible. En un sistema, quién registró qué y cuándo queda constancia. Eso tranquiliza a quien trabaja con constancia e incomoda a quien está acostumbrado a la flexibilidad, y es mejor decirlo abiertamente en la primera reunión que descubrirlo a las dos semanas.

El regreso silencioso al archivo antiguo

Lo más peligroso del primer mes no ocurre con estruendo. Nadie se opone al sistema en la reunión, pero una copia del archivo antiguo sigue abierta en el equipo de alguien, que registra en ella porque es más rápido, con la intención de pasarlo al sistema al final de la semana. Normalmente no lo hace.

Eso produce el peor resultado posible: dos fuentes de verdad en lugar de una. Antes del proyecto tenías un único archivo impreciso que todos aceptaban como referencia. Ahora tienes un sistema incompleto y un archivo incompleto, y nadie sabe cuál está más actualizado. Estás peor que al principio, y este es uno de los patrones que se tratan en Por qué fracasan los proyectos ERP y cómo hacer que el tuyo tenga éxito.

Las señales aparecen pronto si las buscas: una cifra citada en una reunión que no existe en el sistema, un archivo compartido en el chat del equipo dos semanas después del lanzamiento, un empleado que pide exportar los datos para trabajarlos fuera y nunca los devuelve. No trates ninguna de ellas culpando a la persona. Haz una sola pregunta: ¿qué le daba el archivo que el sistema no le da? La respuesta suele ser un paso que falta, un campo ausente o un recorrido más largo de lo necesario, y todo ello se puede arreglar en días una vez que lo sabes.

Las lagunas que aparecen después del cambio, no antes

Por muy bien que hayas limpiado los datos de antemano, como se explicó en la tercera parte, surgirán lagunas que solo podían descubrirse con la primera transacción real. La lógica es sencilla: el archivo toleraba los vacíos, así que una celda en blanco seguía en blanco y nada te impedía emitir la factura. El sistema exige el campo porque un paso posterior depende de él.

Lo que suele aparecer en esta fase:

  • Fichas incompletas de clientes y proveedores. Un cliente registrado solo por su nombre, sin número fiscal, dirección ni contacto documentado, datos que antes se pedían de palabra cuando hacían falta.
  • Saldos iniciales que no cuadran. La cifra de apertura de un cliente o de un artículo no coincide con lo que dice el archivo antiguo, y la diferencia sale a la luz en el primer extracto.
  • Estados que nunca se clasificaron. Un pedido pendiente, un pago parcial, una devolución que nunca se cerró. En el archivo eran una nota al margen; en un sistema necesitan un estado definido.
  • Varias unidades y precios. Un artículo que se vende por caja y se compra por unidad, con un precio distinto para un nivel de clientes que para otro, todo ello guardado en la cabeza del responsable de ventas en lugar de por escrito.
  • Excepciones sin ninguna regla detrás. Un cliente con condiciones especiales desde hace años sin ningún documento, de modo que nadie sabe cómo definirlo en el sistema ni quién tiene autoridad para aprobarlo.

Nada de esto demuestra que la migración haya fracasado. Es su primer beneficio real: el sistema dejó al descubierto lo que el archivo ocultaba. Pero gestionarlo exige disciplina. Registra cada punto en una sola lista declarada, con la persona responsable de la respuesta y una fecha para cerrarlo. Si gestionas cada caso por separado en una conversación aparte, volverá el mes siguiente con otra forma.

Una formación impartida una sola vez no basta

El patrón más repetido en los proyectos con dificultades es una formación dada en una única sesión el día del lanzamiento, a la que asisten todos y que recorre el sistema entero de principio a fin. Después todos vuelven a su puesto habiendo olvidado la mayor parte, porque lo oyeron antes de necesitarlo.

La alternativa que funciona se apoya en tres principios:

  • Forma en el rol, no en el sistema. El contable no necesita las pantallas del almacén y el responsable de ventas no necesita la configuración de permisos. Cada equipo aprende el recorrido que hará a diario, más corto y mucho más enfocado.
  • Repite tras una semana de uso. La segunda sesión es la que de verdad rinde, porque las preguntas que surgen en ella son reales, sacadas del trabajo diario y no hipotéticas. Y las preguntas que se repiten entre equipos te dicen exactamente dónde una pantalla no está clara.
  • Documenta con imágenes, no con texto. Una página por rol con los pasos en orden y capturas de pantalla, colgada en la pared o enviada a todos. La mayoría de las preguntas después del lanzamiento son de memoria, no de comprensión.

También necesitas en cada equipo a una persona a la que se pregunte primero, porque un empleado pregunta a un compañero antes de abrir una incidencia de soporte. Ese papel informal acorta el tiempo de respuesta más que cualquier canal de soporte externo. Este tipo de gestión del cambio no es exclusivo de dejar atrás las hojas de cálculo, y lo tratamos como parte de las fases de implantación en Cómo implantar un ERP con éxito.

La visión de Origami

Consideramos el día del lanzamiento como la mitad de un proyecto, no su final. Un sistema no arraiga en una empresa solo por funcionar; arraiga cuando se convierte en el camino más corto para terminar el trabajo del día. Cada día que el camino antiguo sigue siendo más rápido que el nuevo es un día que trabaja en silencio contra el proyecto.

Por eso, en el primer mes mantenemos una lista declarada de observaciones con fechas de cierre, y medimos el uso real y no las impresiones: quién inicia sesión, qué transacciones se registran en el momento en que ocurren y en qué pantalla se atasca la gente. Es lo que aplicamos al construir sistemas a medida como parte de nuestros servicios, porque corregir un pequeño atasco en su primera semana cuesta una hora, mientras que corregirlo al cabo de dos meses cuesta la confianza de todo un equipo.

Un plan de treinta días

Este es un plan que puedes aplicar tal como está, y su rasgo más importante es que cada etapa tiene un final declarado:

  • Días 1 a 7: funcionamiento en paralelo acotado. El trabajo se registra tanto en el sistema como en el archivo antiguo por una única razón: comparar. Al final de la semana toma una pequeña muestra, compara las dos cifras y anota cada diferencia por su causa y no por su tamaño.
  • Día 8: el archivo antiguo pasa a ser de solo lectura. Es el paso más importante de todo el plan. El archivo sigue disponible para consultarlo y nadie escribe en él. Sin una fecha de cierre declarada, el funcionamiento en paralelo continúa indefinidamente y siempre termina con la victoria del archivo antiguo porque es más cómodo.
  • Días 8 a 14: segunda formación y cierre de lagunas. Una sesión corta por equipo sobre las preguntas que realmente surgieron, y el cierre de los cinco primeros puntos de la lista de lagunas.
  • Días 15 a 21: medir el uso. Revisa quién usa de verdad el sistema y quién no, y por cada transacción registrada tarde, pregunta por qué. Lo que aprendes es una señal de lo claro que es el recorrido, no de la disciplina individual.
  • Días 22 a 30: estabilizar y revisar. Cierra las observaciones pendientes, saca el primer informe mensual solo desde el sistema y siéntate media hora con los responsables de equipo para identificar qué sigue ocurriendo fuera del sistema y por qué.

La medida honesta del éxito no es la satisfacción del equipo en una encuesta ni el número de pantallas en uso. Es un único momento: alguien deja de abrir el archivo antiguo sin que nadie se lo pida. En ese punto el sistema ya no es un proyecto que gestionas: es la forma en que trabaja la empresa.

Cierre de la serie

A lo largo de siete partes hemos recorrido todo el camino: las señales de que una hoja de cálculo ha superado su límite, el inventario que te dice qué archivo es en realidad tu sistema, la limpieza de los datos, el orden en que se migran las cosas, la configuración de permisos, la conversión del informe hecho a mano en una vista en vivo y, por último, la superación del primer mes.

La conclusión que merece la pena conservar es esta. Excel es una herramienta excelente, y el problema nunca fue la herramienta sino lo que se le pedía que cargara. Pasar a un sistema es menos una mejora técnica que la decisión de que los datos de la empresa pertenecen a la empresa y no a un archivo ni a una persona. Y empieza con un pequeño paso: abre el archivo que dirige hoy tu empresa y pregúntate quién lo actualiza, cuándo y qué pasa si esa persona no está.

Fuentes