Cuando alguien pregunta cuánto tarda implantar un ERP, la respuesta honesta empieza por otra pregunta: ¿tarda en qué?
Porque hay tres fechas distintas y confundirlas es lo que hace que los proyectos parezcan eternos aunque vayan bien.
Las tres fechas
- Funcionando. El sistema está instalado, configurado y se puede emitir una factura real. Es la fecha que aparece en las propuestas.
- En uso. El equipo lo usa a diario y ya nadie apunta las cosas aparte. Suele estar bastante después.
- Dando información fiable. Los informes cuadran y dirección toma decisiones con ellos. Es la única fecha que de verdad importa y casi nunca se planifica.
Un proyecto que llega a la primera en dos meses puede tardar seis en llegar a la tercera. Eso no es un fracaso: es lo normal, y decirlo de antemano evita la sensación de que algo va mal.
Qué se hace en cada fase
Antes de tocar el programa
Definir procesos, decidir quién aprueba qué, y limpiar datos. Esta fase no la hace el consultor: la hace la empresa, y es la que más se alarga porque compite con el trabajo de todos los días.
Aquí está el retraso más habitual de todos, y no es técnico. Es que nadie tiene tiempo de decidir cómo se numeran las facturas.
Configuración
Plan contable, impuestos, almacenes, listas de precios, usuarios y permisos, plantillas de documentos. Es trabajo de especialista y es bastante predecible en tiempo, si las decisiones de la fase anterior están tomadas.
Migración de datos
Clientes, proveedores, artículos, saldos iniciales. Siempre lleva más de lo previsto, porque siempre hay menos datos limpios de los que la empresa cree. Está en los seis errores que matan una implantación y es el tercero.
Pruebas con datos reales
No con ejemplos: con tus pedidos raros, tu cliente que paga a noventa días y tu producto que se vende por unidades pero se compra por cajas. Aquí es donde aparece lo que falta, y cuanto antes aparezca, más barato sale.
Formación y arranque
Formar por puesto, arrancar por áreas y acompañar las primeras semanas. Los primeros días consumen mucho más apoyo del que nadie presupuesta.
Lo que alarga los proyectos
Por orden de frecuencia, y ninguno es un problema del programa:
- Decisiones que no se toman. Una pregunta pendiente de respuesta bloquea semanas enteras.
- Datos más sucios de lo esperado. Siempre.
- Personalizaciones que aparecen a mitad. «Ya que estamos, ¿podríamos…?» es la frase que más plazos ha roto en la historia de los ERP.
- Vacaciones y cierres. Nadie implanta bien en diciembre ni en el cierre fiscal.
- La persona clave no tiene tiempo. Si quien conoce el negocio está desbordado, el proyecto avanza a su ritmo, no al del consultor.
Lo que lo acorta
- Reducir el alcance inicial. Un área funcionando de verdad vale más que cinco a medias. Y permite aprender antes de comprometerse con el resto.
- Aceptar cómo funciona el programa en vez de replicar las costumbres. Cada personalización evitada son días.
- Una persona del negocio dedicada de verdad, con horas liberadas y no «además de lo suyo».
- Decidir rápido aunque sea imperfecto. Casi todo se puede corregir después; lo que no se puede es avanzar sin decisión.
Cómo leer un plazo en una propuesta
Tres preguntas que conviene hacer antes de firmar:
- «¿Ese plazo incluye la migración de datos?» Muchas veces no, y es la parte que más se alarga.
- «¿Qué tenemos que hacer nosotros y cuántas horas cuesta?» Si la respuesta es vaga, el plazo también lo es.
- «¿Qué pasa si en las pruebas aparece algo que falta?» Va a aparecer. Saber de antemano si eso es un cambio de alcance o está previsto evita la discusión peor del proyecto.
Y una señal de que la propuesta es seria: que el plazo dependa de hitos tuyos y no solo de fechas. «Dos semanas desde que se entreguen los datos limpios» es una promesa honesta. «Listo el 30 de marzo» sin condiciones, no.