Bramvia — Business Central Experts
Los 7 errores más caros al implantar un ERP (y cómo evitarlos)
Los proyectos de ERP no fracasan por el software: fracasan por 7 errores que se repiten — alcance vago, replicar lo antiguo, migrar todo el histórico… Con su antídoto.
Respuesta corta: los proyectos de ERP rara vez fracasan por elegir mal el software. Fracasan por errores de planteamiento: alcance vago en el contrato, querer replicar el sistema antiguo, migrar todo el histórico, personalizar antes de conocer el estándar, probar con datos de demostración, formar a los usuarios la última semana, y no definir qué significa "terminado". Los siete se evitan antes de firmar, no durante el proyecto — y evitarlos cuesta exactamente cero euros.
Vamos uno a uno, con su antídoto.
1. Firmar un alcance vago
"Implantación de ERP" como objeto del contrato es el origen de la mayoría de disputas. Cada requisito no escrito se convertirá en negociación con el proyecto a medias, cuando cambiar de proveedor ya no es opción.
Antídoto: exige el desglose por partes con entregables y criterios de aceptación escritos, y la lista explícita de lo que NO incluye. Un proveedor serio la tiene; uno que improvisa, la evita. Las preguntas exactas que hacer, aquí.
2. Querer replicar el sistema antiguo
"Que funcione como el de antes, pero moderno" es pedir que el proyecto cueste el doble y aporte la mitad. Si replicas tus procesos de 2010, pagas un sistema nuevo para trabajar como hace quince años.
Antídoto: por cada proceso, la pregunta no es "¿cómo lo hacemos hoy?" sino "¿cómo lo hace el estándar y por qué seríamos distintos?". El estándar de un ERP maduro condensa las prácticas de decenas de miles de empresas — la carga de la prueba está en apartarse de él.
3. Migrar todo el histórico "por si acaso"
Diez años de movimientos multiplican el coste de migración, alargan las pruebas y ensucian el sistema nuevo con datos que nadie consultará.
Antídoto: migra maestros, saldos y lo operativo abierto; el histórico antiguo queda en solo lectura en el sistema viejo o en un archivo consultable. Es la decisión individual que más abarata un proyecto — está en nuestra checklist de migración.
4. Personalizar antes de conocer el estándar
Encargar desarrollos en la semana uno, para descubrir en el mes cuatro que la mitad ya existía como funcionalidad estándar o como app del ecosistema.
Antídoto: regla de tres pasos — primero estándar, luego app existente del marketplace, y solo al final desarrollo propio. Y cuando se desarrolla, como extensión limpia, jamás modificando la base: la diferencia no se ve en la demo, se ve en cada actualización durante diez años.
5. Probar con datos de demostración
Todo funciona con los 50 clientes de ejemplo. Los problemas viven en TUS datos: el cliente con tres direcciones de envío, el descuento raro de 2019, la referencia con dos unidades de medida.
Antídoto: las pruebas de aceptación se hacen con tus datos migrados y tus casos incómodos — incluyendo un cierre de mes completo en el entorno de pruebas antes del arranque. Es la prueba que más fallos detecta, y la que más proyectos se saltan por ir con prisa.
6. Formar a los usuarios la última semana
El sistema arranca, la gente no sabe usarlo, se improvisan atajos en Excel "mientras tanto" — y seis meses después el ERP es un sistema caro que nadie usa del todo. La adopción fallida es el fracaso más caro y el más silencioso.
Antídoto: usuarios clave involucrados desde las pruebas (no invitados al final), formación con datos reales sobre los procesos de cada puesto, y soporte reforzado el primer mes con un canal claro de dudas.
7. No definir qué significa "terminado"
Sin criterio de finalización, el proyecto entra en la agonía del "casi": el proveedor lo da por hecho, tú ves flecos, la relación se agría y los pagos se disputan.
Antídoto: cada parte del proyecto con su criterio de aceptación medible, y el pago ligado a esa aceptación. Es nuestra forma de trabajar — ninguna parte se factura hasta que la aceptas — y aunque otro proveedor no la ofrezca, exigir criterios de aceptación escritos te protege igual.
El patrón común
Los siete errores comparten raíz: decisiones aplazadas. Todo lo que no se decide antes de firmar se decide durante el proyecto — con menos poder de negociación, más presión de calendario y el contador de horas corriendo. La preparación no alarga el proyecto: lo acorta.
Preguntas frecuentes
¿Cuál es el error más caro de los siete? La adopción fallida (nº 6): puedes ejecutar bien los otros seis y aun así acabar con un sistema que la gente esquiva. Y no se arregla con más software, sino con formación y usuarios implicados desde el principio.
¿Qué porcentaje de proyectos de ERP fracasa? Las cifras del sector varían según qué se cuente como fracaso (abandono, sobrecoste, plazos). Lo relevante: casi todos los estudios coinciden en que las causas dominantes son de gestión y alcance, no técnicas — exactamente los errores de esta lista.
¿Estos errores aplican también si vengo de Excel? Todos menos el 3 (no hay histórico que migrar). El 2 se transforma: en vez de replicar el sistema antiguo, la tentación es replicar las hojas de cálculo. Más sobre ese salto aquí.
¿Cómo sé si mi proveedor actual está cometiendo estos errores? Pide hoy mismo tres documentos: el alcance con exclusiones, los criterios de aceptación por fase y el plan de pruebas con tus datos. Lo que no exista en papel, no existe. Y si el proyecto ya está torcido, hacemos segunda opinión y rescate.
¿Estás por firmar o en medio de un proyecto con dudas? Revisamos tu propuesta o tu proyecto gratis y sin compromiso — te diremos qué está bien, qué falta y qué preguntar.