Por qué migrar el ERP a la nube no resuelve tu problema de procesos

Hay una promesa que se repite en todas las reuniones de migración de ERP. "Cuando estemos en la nube, todo esto será más sencillo." No lo será. La nube cambia dónde corre el software, no cómo trabaja tu empresa.

Si hoy el pedido de compra pasa por tres aprobaciones por correo, una hoja de Excel paralela y una llamada de teléfono, seguirá pasando por lo mismo tras la migración. Solo que ahora corre en servidores de Fráncfort en vez de en una máquina del sótano.

La nube es un lugar, no una decisión de proceso

Migrar a la nube resuelve problemas reales. Dejas de gestionar hardware. Tienes copias de seguridad gestionadas, escala elástica, actualizaciones sin parar la operación. Eso vale la inversión. Pero es un problema de infraestructura.

Tu problema, casi siempre, es otro. Es el comercial que aprueba crédito por instinto. Es el stock que diverge del sistema porque nadie registra las devoluciones en el momento adecuado. Es el cierre de mes que tarda dos semanas porque la mitad de los asientos viven en hojas sueltas.

Ninguna de estas cosas mejora por cambiar de servidor. El ERP, local o en la nube, es el espejo de tus procesos. Si el proceso es confuso, el espejo devuelve confusión con mejor uptime.

El error del levantamiento "as-is" perezoso

La migración típica empieza con un levantamiento de los procesos actuales. El objetivo declarado es "replicar lo que ya tenemos". Aquí es donde el proyecto muere antes de empezar.

Replicar lo que ya tienes significa codificar décadas de excepciones, atajos y "siempre lo hemos hecho así" en un sistema nuevo y caro. El resultado es un Frankenstein personalizado que nadie consigue actualizar después.

El caso de Lidl es el ejemplo público más citado. La cadena trabajó años en un nuevo sistema de gestión de stock basado en SAP. El proyecto se canceló en 2018 tras cientos de millones invertidos. Uno de los motivos reportados: Lidl insistió en adaptar el software a su modelo de inventario a coste de adquisición, en vez de adaptar el proceso al estándar. El software se dobló hasta romperse.

Veinte años antes, Hershey hizo el camino opuesto y falló por las prisas. Puso ERP, CRM y gestión de cadena de suministro a entrar en producción a la vez, justo antes de Halloween, sin tiempo para estabilizar los procesos. No consiguió despachar pedidos que tenía en almacén. La migración estaba técnicamente hecha; la operación se paró igual.

Lo que tienes que hacer antes de tocar la nube

El orden correcto es incómodo porque es más lento al principio. Primero entiendes los procesos. Luego decides cuáles valen la pena, cuáles cortas y cuáles alineas al estándar del software. Solo entonces migras.

• Mapea los procesos reales, no los del manual. El proceso real es lo que la gente hace a las cinco de la tarde de un viernes con un cliente enfadado al teléfono.
• Para cada excepción personalizada, pregunta por qué. La mitad de las veces la respuesta es una regla que ya nadie necesita.
• Decide qué adaptas al estándar. Personalización cara hoy es deuda técnica que te ata a un proveedor mañana.
• Limpia los datos antes de migrar. Datos sucios en un sistema nuevo son datos sucios, punto.
• Define quién es dueño de cada proceso. Sin dueño, nadie defiende el cambio cuando el equipo se resiste.

La resistencia interna es el verdadero proyecto

La parte técnica de una migración es la más previsible. APIs, integraciones, ventanas de cutover: todo eso tiene manuales. Lo que no tiene manual son las personas que hicieron el proceso antiguo durante quince años y lo conocen mejor que cualquier consultor.

Los estudios clásicos de gestión del cambio son consistentes en este punto. La mayoría de los programas de transformación no falla por tecnología. Falla por ejecución, alineación y adhesión de las personas. La HBR lo resume bien en el trabajo de Sirkin, Keenan y Jackson sobre los factores duros del cambio.

Imagina el escenario típico: el responsable de almacén recibe un sistema nuevo que le obliga a registrar cada movimiento en el momento, en vez de al final del turno. Para él, el sistema nuevo es más trabajo, no menos. Si no le muestras el porqué y no ajustas el proceso a la realidad de la planta, vuelve a la hoja de Excel paralela. Y tu ERP en la nube pasa a ser un archivo muerto y caro.

¿Y la nube, vale la pena?

Vale. Pero por los motivos correctos. Migra a la nube para dejar de gestionar infraestructura, para tener elasticidad y para integrar más fácilmente con el resto de tu stack digital. No migres esperando que el cambio de servidor reorganice tu operación.

La secuencia que funciona es sencilla de decir y dura de hacer. Ordena el proceso. Limpia los datos. Alinea a las personas. Después conecta la nube. Quien invierte este orden paga dos veces: una en la migración y otra deshaciendo la migración.

El buen software no arregla una operación mala. Solo la hace más rápida a la hora de romperse. La pregunta correcta nunca fue "nube o local". Fue "¿nuestros procesos merecen ser automatizados tal y como están?". En la mayoría de los casos, la respuesta honesta es no, y ahí es donde el proyecto empieza de verdad.