Por qué fracasa una implementación de ERP

Un ERP que se cae no suele caerse de golpe. Se abandona: primero un área que sigue con su Excel «mientras tanto», después un módulo que nadie llena, y al año la empresa está pagando una licencia por un sistema donde solo se emiten facturas.

Y lo que más sorprende al revisar por qué pasó es que casi nunca falló la tecnología.

¿Qué significa que una implementación fracase?

Casi ninguna termina en cancelación. Terminan en una de estas cuatro, que son peores porque nadie las declara fracaso:

• Se usa a la mitad. Entró facturación y nada más. Los módulos de compras e inventario están comprados y apagados.
• Se sigue trabajando por fuera. El sistema se llena al final del día copiando de un cuaderno o de una hoja de cálculo.
• Nadie confía en los números. El reporte existe, pero antes de una reunión importante alguien lo verifica a mano.
• Se duplicó el trabajo. Ahora hay que registrar en el sistema y mantener el Excel, porque el Excel tiene cosas que el sistema no.

La señal más temprana de que un proyecto va a fracasar es que la gente pida seguir usando su archivo «solo por este mes». Ese mes no termina nunca si nadie lo corta.

¿Cuáles son las cuatro causas reales?

Ninguna es técnica, y las cuatro se pueden prevenir antes de firmar.

1. Nadie de la empresa tuvo tiempo asignado

Es la primera y la más cara. El proveedor puede construir el sistema, pero no puede decidir cómo trabaja tu empresa. Alguien de adentro tiene que responder cómo se numera una guía, qué pasa cuando un cliente devuelve mercadería o quién autoriza un descuento.

Si esa persona no tiene horas separadas en su agenda, el proyecto avanza a suposiciones. Y una suposición equivocada no se descubre en la reunión: se descubre en producción, con la operación encima.

2. Se digitalizó el desorden

Un ERP no ordena una operación desordenada, la refleja. Si hoy hay tres formas distintas de registrar la misma venta según quién la haga, el sistema va a heredar las tres o va a imponer una que la mitad del equipo no acepta.

Antes de configurar nada hay que decidir cómo se trabaja de verdad, y esa es una decisión de la empresa, no del proveedor.

3. La migración de datos se subestimó

Es la parte que siempre se calcula de menos. La data vieja llega sucia, duplicada, con clientes escritos de cuatro maneras y productos que ya no existen. Limpiarla lleva más de lo que parece, y hacerlo mal envenena el sistema nuevo desde el primer día.

Pide siempre una muestra real de la data antes de comprometer un plazo, no una descripción. «Tenemos unos 5.000 productos» y ver el archivo con esos 5.000 productos son dos conversaciones distintas.

4. Nadie capacitó a quien lo iba a usar

Se capacita a los jefes y se olvida al almacenero, que es quien va a registrar doscientos movimientos al día. Si para él el sistema es más lento que su cuaderno, va a seguir con el cuaderno, y tiene razón.

¿Cómo se blinda el proyecto antes de firmar?

Cinco cosas por escrito. Ninguna es un favor del proveedor: son condiciones normales de un proyecto serio.

• Un responsable interno con horas asignadas. Con nombre, y con capacidad de decidir sin escalar cada punto.
• Un entregable funcional cada semana. Que puedas abrir y probar, no un informe de avance.
• Alcance escrito y precio cerrado. Para que un cambio se converse antes de ejecutarse y no aparezca en la factura.
• Un mes de convivencia con lo viejo. Sistema y Excel en paralelo, comparando, antes de apagar nada.
• Capacitación a quien opera, no solo a quien dirige. Y con la data real de la empresa dentro, no con ejemplos.

De las cinco, la que más proyectos salva es la segunda. Un proyecto donde no ves nada hasta el final no dura seis semanas: dura lo que dure, y te enteras al final. Con un entregable semanal, un desvío se detecta en la semana dos, cuando todavía cuesta barato corregirlo.

Los proyectos de ERP y sistemas de gestión de Kovensa están estimados en 5 a 6 semanas con migración de la data histórica incluida, con precio cerrado y pagos por hitos contra entregables que ya funcionan.

Conclusión: ¿qué preguntar antes de empezar?

Hay una pregunta que revela más que cualquier propuesta: ¿qué voy a poder ver funcionando en la semana 3, y quién de mi lado tiene que aprobarlo?

Si la respuesta es concreta, el proyecto probablemente llegue. Si es vaga, o si la segunda mitad de la pregunta se queda sin responder, ya sabes cuál de las cuatro causas te va a tocar.

Y si todavía estás decidiendo entre un sistema contratado y uno construido a tu medida, eso lo comparamos en ERP de caja o software a medida.