Puesta en marcha de ERP y WMS: qué se rompe realmente en la planificación

Un sistema montado sobre un proceso torcido no lo arregla, lo fija en hormigón

Comprar un nuevo WMS o ERP no repara un proceso. Lo fija tal como está, incluidas las colas, los apaños y el circuito de aprobación que ya nadie sabe explicar.

Jan Buba, Senior Consultant e Interim Stream Lead en Logio, describió el resultado este verano en un artículo para la revista especializada IT Systems: «Los procesos se vuelven más rápidos y más caros, pero siguen siendo igual de ineficientes que antes, solo que más difíciles de reparar». Su conclusión tras años de proyectos de rescate es la secuencia, no la tecnología: «Solo cuando enderezamos los procesos y los flujos de información tiene sentido hablar de tecnología».

Esa secuencia es todo el argumento de este texto. Todo lo que sigue es lo que significa «enderezar primero» en la práctica para una empresa que ya ha firmado con un proveedor y tiene una fecha en el contrato.

Si todavía está decidiendo qué sistema comprar, la pregunta previa es si los sistemas que ya utiliza son la restricción. Es un ejercicio aparte: evaluar los sistemas que ya tiene antes de sustituirlos.

Qué tiene que cumplirse antes de fijar una fecha de puesta en marcha

Tres cosas tienen que cumplirse para que una fecha signifique algo: el proceso sobre el papel coincide con el proceso en el pasillo, los datos maestros que hay detrás de ese proceso son legibles y cada campo tiene un responsable con nombre.

La primera es la menos evidente. Toda empresa tiene un proceso descrito en sus directrices y otro distinto funcionando en el almacén, y a menudo los dos solo se cruzan de pasada. Buba llama a la solución realismo de datos: los procesos dejan huellas digitales en los sistemas que ya se utilizan, y esas huellas se pueden reunir en una imagen fiel de lo que ocurre realmente. Esa imagen suele sorprender a la dirección. Pone al descubierto cuellos de botella en lugares en los que todos confiaban y circuitos de aprobación que sobrevivieron a tres reorganizaciones y perdieron su sentido por el camino.

Hágalo antes de congelar la especificación, no después. Una especificación escrita sobre el proceso de papel produce un sistema que automatiza una ficción, y la diferencia aflora en la primera semana de operación real, cuando ya no queda tiempo para rediseñar nada. La misma lógica se aplica a lo que exige al proveedor: la especificación del sistema y la preparación del proveedor es donde el proceso de papel se sustituye por el real.

Datos maestros: el trabajo del que nadie quiere ser responsable

Dimensiones, pesos, tiempos de manipulación y lead times reales de los proveedores deciden si el nuevo sistema pide con sensatez desde el primer día. También son la parte del proyecto para la que nadie se presenta voluntario.

La cadena de fallos es corta y cara. Un palé tiene una altura errónea en el registro maestro. El sistema reserva para él un camión inadecuado. El camión llega, no cabe, bloquea el muelle, el conductor espera y la penalización la paga usted. Nada en esa cadena es un defecto del software.

Lo que cambia tras la automatización es la tasa de error que se puede absorber. Mientras una persona hacía los pedidos, esa persona detectaba la mayoría de sus propios errores antes de que pasara nada. Ponga un motor automático encima de datos rotos y los errores se multiplican a un volumen que nadie tiene capacidad de revisar. Buba lo dice sin rodeos: «Un algoritmo alimentado con desorden devuelve desorden, solo que más rápido y a mayor escala».

Limpiar significa revisar uno por uno los registros sobre los que se apoyan los procesos: materiales, proveedores, clientes, tarifas. En algún sitio eso implica medir físicamente cientos de palés; en otros, unificar unidades, eliminar duplicados o llamar a los proveedores para saber cuánto tarda de verdad su entrega. Ninguna IA ni ningún proveedor de sistemas lo hará por usted.

La parte en la que más se equivocan los proyectos es lo que viene después. Los datos maestros no son un proyecto, son un régimen. Cada campo necesita un responsable y una regla sobre quién lo actualiza y cuándo. Sin eso, una empresa que limpia sus datos antes de la puesta en marcha vuelve a estar donde empezó en dos años, y la segunda limpieza cuesta lo mismo que la primera.

La exactitud de los registros de stock es una condición, no un extra

Si hoy sus registros y sus estanterías no coinciden, una migración no zanja la discusión. Traslada la discrepancia a un entorno en el que es mucho más difícil de rastrear, porque ya no se puede saber si una diferencia vino del sistema antiguo, de la propia migración o de las primeras semanas de operación.

Trate la exactitud como una condición para la fecha y no como una tarea dentro de ella. Eso significa un inventario completo lo bastante cerca del cambio como para que las cifras sigan significando algo, una decisión documentada sobre cómo se contabilizan las diferencias encontradas en las primeras semanas y un acuerdo sobre quién puede corregir un registro una vez que el nuevo sistema está en marcha. Las empresas que se saltan este último punto acaban con varias personas corrigiendo en silencio el mismo stock en direcciones distintas.

Hay un detalle de secuencia en el que conviene insistir: haga el recuento antes de la congelación, no durante. Un recuento dentro de la ventana de congelación compite por las mismas personas que deberían estar haciendo pedidos manuales, y los dos trabajos salen mal.

La ventana de congelación: quién pide mientras cambia el sistema

La ventana de congelación es el periodo en el que el sistema antiguo ya no decide y el nuevo todavía no. Alguien tiene que seguir pidiendo durante ese tiempo, y es una decisión de planificación, no de sistemas.

Cuatro preguntas necesitan respuesta antes de confirmar la fecha. Cuánto dura realmente la ventana, contando los días de menor rendimiento tras el cambio y no solo la parada técnica. Quién hace los pedidos manuales y con qué autoridad. Hasta dónde llega el horizonte de aprovisionamiento previo para las referencias con lead times largos. Quién decide sobre las excepciones cuando un proveedor llama con un problema que el procedimiento alternativo no previó.

Dos categorías merecen un tratamiento propio. Las referencias con lead time largo deben cubrirse más allá de la ventana con margen, porque un pedido que falta ahí no se recupera dentro del trimestre. Las promociones previstas dentro de la ventana deberían moverse si el calendario lo permite; una promoción es precisamente la situación en la que el pedido manual tiene menos margen de error y en la que equivocarse sale más caro.

Por qué empeora la previsión justo después de la puesta en marcha

La precisión de la planificación cae tras un cambio de sistema. Es un comportamiento esperado, no un defecto, y los equipos a los que no se avisa de antemano tienden a responder de la peor manera posible.

El mecanismo es corriente. El histórico de ventas se interrumpe en el cambio. La estructura de los datos cambia, a veces de formas que parecen cosméticas y no lo son: otra granularidad del registro de ventas, otra definición de una ubicación de stock, códigos de referencia y ubicación que se corresponden de forma imperfecta entre el sistema antiguo y el nuevo. Un motor de previsión que lee esa costura produce peores cifras durante un tiempo, y cuanto más automática es su reposición, más visible se hace.

La respuesta que lo empeora es reajustar parámetros durante las primeras semanas. Los planificadores ven sugerencias malas, ajustan stocks de seguridad y niveles de servicio para compensar, y cuando los datos se asientan el sistema carga con una capa de correcciones manuales que nadie sabe deshacer. Mantenga disponible el histórico paralelo, diga al equipo de planificación de antemano cuánto dura aproximadamente el periodo degradado y no toque los parámetros hasta que la costura haya quedado atrás.

Aquí se aplica directamente un argumento nuestro anterior: una mejor previsión no acaba por sí sola con las roturas de stock, la ejecución sí. Un cambio de sistema es un problema de ejecución disfrazado de problema de previsión.

Dos buenos sistemas que se ignoran

Un WMS sólido y un TMS sólido sin nada entre ellos no valen el doble. Son el doble de inversión devolviendo una fracción, y el hueco lo llenan personas que vuelven a teclear datos.

El ejemplo de Buba en un departamento de transporte da la medida. Antes de la integración, un gestor de tráfico copiaba los datos del envío de su propio sistema al portal de cada transportista, cada portal con campos distintos y una lógica distinta. Lo que no se podía hacer con clics se perseguía por teléfono y correo: llamar para pedir capacidad, esperar respuestas, volver a insistir y después teclear de nuevo los precios confirmados. Un solo error de tecleo significaba una recogida mal reservada y una ronda de correcciones. Una solicitud corriente podía consumir tres cuartos de hora, la mayor parte en volver a teclear de una ventana a otra.

Después de conectar a los transportistas mediante API, el gestor hace el mismo trabajo: lanza la licitación, elige el transportista, negocia las condiciones. El tecleo repetido ha desaparecido. La solicitud sale desde una sola interfaz, los precios vuelven uno al lado del otro y los estados de los envíos pasan entre sistemas por sí solos. Decenas de minutos por solicitud pasaron a ser unos pocos, y el mismo equipo gestiona varias veces más trabajo sin sumar a nadie.

La pregunta relevante durante una puesta en marcha es cuáles de estos traspasos piensa dejar manuales y si alguien ha calculado lo que significa esa decisión al día. El trabajo de integración que se recorta del alcance en el segundo mes suele volver como una línea permanente de plantilla. Delimitarlo bien es la tarea del acompañamiento a la integración y la puesta en marcha.

El Excel en la sombra: cómo fracasa en silencio una puesta en marcha seis semanas después

El fallo peligroso no es el del día del cambio. Es el que aflora en la sexta semana, cuando los informes dejan de coincidir con nada.

Así ocurre. Un gestor que lleva años haciendo el trabajo a su manera, y haciéndolo bien, oye «nuevo sistema» y lo traduce para sí como «quieren sustituirme». Por fuera hace clic donde le dicen. En casa, en un cajón, sigue llevando su hoja de cálculo de siempre, porque es lo único en lo que confía. El sistema oficial funciona entonces con datos incompletos mientras la verdad real vive en un archivo privado, y la inversión muere ahí sin que nadie informe de una incidencia.

La lectura de Buba merece conservarse: «La resistencia al cambio no es mala voluntad, es una reacción humana normal, y se puede trabajar con ella». En la práctica funcionan tres cosas. Implicar a las personas de la operación en el diseño de la solución en lugar de presentársela terminada, porque quien decidió cómo debía ser su propia pantalla la defenderá ante sus compañeros. Hacer operación en sombra, el sistema antiguo y el nuevo en paralelo, el tiempo suficiente para que la gente compruebe que puede fiarse del nuevo. Y asegurarse de que cada gestor oye, y se cree, que su puesto no desaparece, sino que cambia: de volver a teclear cifras entre ventanas a gestionar excepciones.

La cuarta cosa es presupuestaria. La gestión del cambio tiene que estar en el presupuesto y en el calendario desde el primer día, no como un añadido blando que se recorta cuando el hardware se pasa de presupuesto. Si falta esa línea en su plan, no es un plan para una puesta en marcha, es un plan para una instalación. La implantación y gestión del cambio es la parte que más a menudo se infrafinancia y la que más a menudo decide el resultado.

Hay una regla de diseño relacionada: «Un sistema en el que nadie puede ver por dentro no se ganará la confianza de la operación». Si un usuario no puede averiguar por qué el sistema propuso lo que propuso, mantendrá su hoja de cálculo, y tendrá razón.

Cuándo aplazar la puesta en marcha

Tres situaciones hacen que un aplazamiento salga más barato que un arranque.

Los datos maestros no están limpios en las referencias que generan la mayor parte de su facturación. No en todas las referencias, en las que se mueven. Si las referencias A todavía tienen pesos estimados o lead times que nadie ha verificado, las primeras semanas de pedidos automáticos generarán más trabajo que el proceso antiguo.

La ventana de congelación no tiene responsable. Si nadie sabe decir quién pide qué durante el cambio y con qué autoridad, no tiene un plan de cambio de sistema, tiene una fecha.

La fecha cae en su pico estacional. Poner en marcha seis semanas antes del periodo de más actividad del año significa que la curva de aprendizaje y el pico recaen sobre las mismas personas al mismo tiempo.

Aplazar no es gratis, y el argumento contrario merece ser escuchado. Dos sistemas en paralelo cuestan dinero real en licencias, mantenimiento y atención; un retraso de tres meses suele significar perder a personas de la implantación que conocen su proyecto; los hitos contractuales pueden llevar penalizaciones. La decisión es una comparación entre dos costes, no un principio, y la versión honesta de esa comparación se hace antes de anunciar la fecha al negocio, no dos semanas antes del cambio.