EL QUINCE DE CADA MES
¿Por qué fracasan (o se eternizan) las implantaciones de ERP?
Los primeros meses son esperanzadores: el proyecto avanza, se establecen diferentes equipos de trabajo, se recurre a consultoría externa, se planifican pilotos. De hecho, llegó a desplegarse en entornos limitados.
Pero a mitad de camino aparece un problema típico del sector: una decisión interna que afecta al modelo de negocio. En varios análisis se comenta el choque entre la forma de trabajar del cliente y la lógica estándar del ERP, y cómo ese choque acaba empujando a personalizaciones y complejidad creciente.
A partir de ahí el proyecto entra en una espiral que muchos lectores pueden reconocer:
- Cada “arreglo” abre varios “impactos colaterales” (integraciones, reporting, performance, formación, pruebas).
- Las pruebas se vuelven interminables porque los procesos no quedan estables.
- La organización se cansa: usuarios frustrados, negocio presionando por resultados, TI apagando fuegos.
Tras siete años de esfuerzo y un gasto de varios cientos de millones de euros, se toma la decisión más dura: se cancela el proyecto y se vuelve al viejo ERP que, aunque limitado, estaba perfectamente adaptado a las necesidades del cliente. En comunicaciones públicas se recoge la idea de que los objetivos no eran alcanzables con un “esfuerzo razonable” y que la decisión “no era contra el ERP”, sino contra la viabilidad del enfoque.
Este caso comentado fue real e implicó a una de las mayores cadenas de supermercados del mundo y uno de los ERPs más reconocidos en todos los rankings. Las consecuencias reales de este proyecto cancelado fueron:
- Inversión fallida: Se pierde gran parte de la inversión y además hay que mantener y modernizar el sistema anterior para seguir operando.
- Problemas organizativos: fatiga del cambio, munición para los críticos con el cambio, pérdida de confianza y credibilidad para TI y el Partner. Esto es un patrón habitual; no siempre cuantificable públicamente.
- Oportunidad perdida: años de foco ejecutivo “secuestrado” por el programa y decisiones de negocio pospuestas. También es un patrón habitual.
La enseñanza de este caso es que el ERP no es malo ni la empresa imposible de entender. Se trata más bien de que un ERP es una transformación de reglas de negocio, datos y comportamiento humano; si intentas que el software se adapte completamente a tu empresa, las expectativas son inalcanzables y el sistema se vuelve frágil y más caro.
Este caso, aun siendo real, muestra sólo algunas de las causas que hemos aprendido en los 35 años que nuestra empresa lleva implantando sistemas ERP. A continuación, mostramos un resumen de las más frecuentes.
Cada una de las causas tiene asociadas medidas que se pueden implementar para mitigar las causas.
Causas más frecuentes de los problemas en las implantaciones de ERP
A) Asociadas al cliente
1) Rechazo o falta de compromiso de los usuarios finales
Normalmente, el usuario no rechaza “el ERP”; rechaza pérdida de control, miedo a que sus errores se vuelvan más públicos, sensación de imposición, o simplemente la mayor carga de trabajo durante los meses de implantación. Si la dirección de la empresa no sostiene el cambio, el proyecto se convierte en “un proyecto de TI” y los usuarios lo “aparcan” en su lista infinita de tareas.
Se pueden mencionar algunas señales tempranas de la desconexión de los usuarios con el proyecto:
- Key users delegan reuniones, no preparan casos, “no les da la vida”.
- Se posponen decisiones pequeñas que luego bloquean cadenas enteras.
- Aparecen atajos: Excel paralelo, “ya lo meto luego”, “hazlo tú en el sistema”.
La palanca para mejorar esta falta de compromiso es la implicación efectiva de Dirección. En el fondo, se trata de un problema de liderazgo. También es conveniente trasladar a los usuarios la idea de que se trata de un proyecto conjunto que engloba a las dos organizaciones. Si ese apoyo de la dirección no existe, el proyecto no tiene tracción. La dirección dispone de varias herramientas, típicas de cualquier transformación: compromiso personal, formación, recursos, incentivos, etc.
2) Falta de tiempo para definir o probar
En ocasiones la organización subestima el coste real de tareas del proyecto como:
- Definir requerimientos (impuestos, descuentos, trazabilidad, stocks, permisos, etc)
- Preparar datos (maestros y saldos)
- Ejecución de pruebas y validaciones.
Es indudable que el proyecto necesita apoyo del cliente en definición, supervisión, pruebas y formación. La ausencia de este apoyo puede generar problemas en el proyecto, como una ampliación de plazos y/o trabajos adicionales repercutibles. Otra consecuencia típica final es un “arranque” con fiabilidad baja: errores de datos, integraciones inestables, incidencias funcionales que disparan el soporte y erosionan la confianza.
Estas consecuencias mencionadas pueden ser fácilmente subsanables, estableciendo medidas correctoras como: bloquear agenda de key users, crear un equipo específico de proyecto y posponer el arranque si este no tiene garantías suficientes (un go‑live sin pruebas suele salir más caro que esperar).
El proyecto de implantación compite con el negocio diario. Si entra una adquisición, cambio societario, crisis de liquidez o relevo directivo, el proyecto pierde patrocinio y se queda “a medias”.
El síntoma clave de esta causa es que el responsable del proyecto del cliente deja de decidir; las reuniones se convierten en sesiones meramente informativas, sin autoridad, y las decisiones se van aparcando.
La mejor forma de mitigar este problema es gestionando el proyecto por hitos, a través de los cuales se pueda apreciar los beneficios de cada avance. Si no hay valor visible, el proyecto es el primero en caer cuando cambian las prioridades.
4) Expectativas muy altas (mala gestión de promesas)
En este ámbito hay dos errores comunes que vemos continuamente:
- Esperar que el ERP arregle procesos mal definidos (cuando en realidad los hace más visibles).
- Confundir implantación con mejora de negocio: el software habilita; la mejora requiere rediseño, disciplina y procesos.
En el ejemplo mencionado en la introducción, los objetivos eran ambiciosos. La recomendación para este caso se basa en definir de forma separada las capacidades generales y mejoras esperadas. Suele funcionar concretando en el contrato:
- KPIs de éxito por proceso (calidad percibida por el cliente)
- Qué funcionalidad está definida en el alcance para el “go live” y qué funcionalidad consideramos como “Fase 2”.
- Definir y dejar claro qué es defecto vs mejora, para evitar guerras en garantía.
5) Jefe de proyecto del cliente
El jefe de proyecto del cliente no es un simple coordinador; es el dueño del cambio en la organización. Si no tiene autoridad, capacidad de ordenar prioridades, criterio para decidir y habilidades de comunicación, se generan fricciones, miedo y silencio (nadie escala lo importante).
La forma de gestionar estas situaciones pasa por:
- Escoger una persona con experiencia demostrada y las habilidades necesarias.
- Cierta implicación o al menos seguimiento por parte de la dirección para que esta pueda desbloquear estas situaciones cuando se detectan.
- Formación específica en gestión de proyectos y gestión del cambio.
- Sustitución temprana si hay bloqueo persistente (mejor mes 2 que mes 10).
6) Falta de alineamiento entre áreas de negocio
En ocasiones, las distintas áreas (ventas, compras, logística, finanzas) tienen objetivos contradictorios y el proyecto ERP las obliga a estandarizar procesos que antes cada una gestionaba “a su manera”.
Un ejemplo de esto sería un departamento de ventas que quiere hacer libremente promociones agresivas y flexibilidad en precios que choca con las ideas del departamento financiero de tener control y trazabilidad de todas las decisiones.
En estos casos, el ERP se convierte en un campo de batalla donde cada departamento intenta que el sistema refleje “su” verdad. El proyecto corre, entonces, el riesgo de bloqueo, más por la falta de acuerdo interno que por la incapacidad del software.
Con el fin de mitigar esto, conviene que la empresa estudie bien el alcance de los requerimientos funcionales y la dirección se involucre en la definición de los procesos internos que se van a implantar.
B) Asociadas al proveedor tecnológico
1) Equipo técnico/funcional sin cualificación suficiente
Esta falta de cualificación puede afectar a la gestión del proyecto en tres ámbitos principalmente:
a) Gestión del proyecto deficiente que genera confusión y desconfianza. Comentamos a continuación algunos ejemplos significativos:
- Planes que cambian cada semana sin explicación.
- Crea expectativas sobre funcionalidad que luego no se cumplen y nos llevan a la temida frase: “hay que desarrollar”.
- Documentación insuficiente, en la que se echan en falta tanto decisiones acordadas en las reuniones como la definición acordada de procesos.
b) Puesta en marcha deficiente con el consiguiente impacto económico y reputacional:
- Parametrizaciones mal hechas en aspectos clave como impuestos, stocks, valoración, trazabilidad.
- Integraciones sin control de errores y pruebas suficientes que llevan a casos de pedidos duplicados, mala valoración de stock, etc.
- Datos maestros sin revisar, con clientes duplicados, proveedores inconsistentes, etc.
c) Mantenimiento a largo plazo. Un equipo ineficiente nos puede arrastrar a un costoso mantenimiento del sistema para toda su vida, tanto para el caso de la gestión de los evolutivos como de las posibles migraciones posteriores.
La solución a este problema es fácilmente alcanzable: Conseguir el compromiso del socio tecnológico a través de la utilización de un equipo con la capacidad requerida, incluso contractualmente.
2) Jefe de proyecto del Partner
El efecto directo más frecuente de contar con un Jefe de Proyecto inadecuado es la merma de confianza y disminución de la cooperación entre los equipos de gestión del proyecto. Simplemente se rompe el clima necesario para el éxito. Sin ese clima pueden darse situaciones de ocultación de datos, autoprotección ante el desastre y respuestas emocionales que evitan que se profundice lo suficiente en los requerimientos. El resultado suele ser la aparición de problemas en el go‑live.
La forma de mitigar estos problemas pasa por una gestión del proyecto que se centre en las tareas a través de una exhaustiva metodología de proyecto: revisiones y acuerdos periódicos, formalización de acuerdos en actas, gestión de riesgos, evaluación de temas pendientes, sesiones de pruebas y validaciones completadas y escalado de defectos críticos. Podría llegarse a la sustitución de la jefatura de proyectos si llegase a ser necesario.
3) Metodología inexistente o deficiente (todo se negocia, todo se regatea)
Cuando no hay un buen método, no suele haber un alcance bien definido. Entonces el proyecto se convierte en una negociación constante con frecuentes reclamaciones sobre alcance y una necesidad de acuerdo por cada nueva solicitud. Aparecen las posiciones de fuerza en las que no gana quien tiene razón sino quien tiene una mayor posición de dominio.
La metodología se hace esencial en cualquier proyecto tecnológico para cada una de las fases de este: análisis, seguimiento, cambios de alcance, imprevistos, validaciones, go-live, etc. El método simplemente aporta un carril previsible por el que circular fuera de cualquier incertidumbre.
4) Falta de recursos por parte del Partner
Aunque el equipo sea bueno, si están acometiendo varios proyectos a la vez, la calidad percibida por el cliente no será la deseada.
La sensación de abandono perjudica el clima necesario para la buena gestión de un proyecto.
La mitigación de esto punto es principalmente contractual y operativa. En el contrato debe especificarse una capacidad comprometida (incluso con nombres y roles), un plan de sustituciones, e incluso métricas de servicio (SLA de respuesta en incidencias del proyecto). Esto, junto a unos hitos claros y comprometidos, asociados a un plan de entregas, hará que el proyecto vaya por el camino adecuado.
La vigilancia del cumplimiento de estos compromisos es uno de los puntos más importantes de las reuniones de jefatura de proyecto. Al más mínimo desvío, deben proponerse acciones de corrección o replanificación.
C) Causas mixtas
1) Contrato mal realizado. Ambigüedad equivale a conflicto
En los contratos debe prevalecer la idea de claridad para todos. Debe estar definido todo lo necesario para saber tratar de la mejor forma posible cada discrepancia que se produzca. Esto incluye tener definidos términos como:
- Alcance definido en la oferta vs aquellos GAPS recogidos en el análisis funcional.
- Criterios de aceptación por entregable que defina qué significa que una tarea del proyecto esté “terminada”. Un ejemplo de esto es la validación tras 10 días ante la falta de respuesta de un cliente a una entrega, ampliaciones de plazo ante retrasos en las pruebas, etc.
- Qué es “defecto” vs “mejora”.
- Reglas de cambio de alcance (cómo, cuánto tarda, quién decide).
- Obligaciones del cliente (datos, accesos, disponibilidad, validaciones).
Todo lo anterior hace el proyecto predecible y obliga a las dos partes a una gestión detallada.
2) Incompatibilidad de caracteres entre miembros de ambos equipos
Menos frecuente, pero letal cuando ocurre. La implantación de un ERP exige cientos de pequeñas decisiones y coordinación. Si hay fricción, cualquier decisión, por pequeña que sea, cuesta el triple.
Hay varias formas de mitigar este caso cuando ocurre. La metodología y claridad de los contratos mencionadas en puntos anteriores ayudan, reducen las negociaciones constantes por cualquier cosa.
Otras formas de solucionar esto es separando responsabilidades con el uso, por ejemplo, de matrices RACI, que permite definir y asignar claramente los roles y responsabilidades en cada tarea: Responsable, Aprobador, Consultado e Informado.
En casos extremos, podría llegar a ser conveniente el cambio de interlocutores por el bien común del proyecto.
3) Software inadecuado. Implantación forzada
Esta es de las causas más caras, porque se paga durante años. Si el producto no encaja, obliga a la empresa a elegir entre cambiar procesos de la empresa -con el consiguiente dolor organizativo- o adaptarlo al máximo – lo que implica dolor técnico y económico-.
El caso de la introducción es un ejemplo de desalineación y de cómo el intento de forzar el encaje puede empujar a una gran complejidad.
Nuestra recomendación es muy clara: primero se selecciona el producto más adecuado (fit‑gap), luego se selecciona el partner más capaz.
El “efecto multiplicador” (cuando 2–3 causas coinciden)
Nuestra experiencia de 35 años implantando soluciones ERP nos indica que una sola causa suele ser gestionable; dos o tres juntas pueden llevar a problemas más complejos. Esto es debido al “Efecto Multiplicador” de las fuentes de ineficacia al combinarse entre sí.
Lo cierto es que, con el compromiso de ambas partes, los proyectos siempre llegan a término. Es aquí donde la elección de un buen Partner se hace esencial. Creemos realmente que un buen Partner no es aquel que no tiene ninguna incidencia, sino aquel que las gestiona con compromiso, tiene una visión pro-cliente y simplemente no contempla otra cosa que no sea terminar los proyectos.
A continuación, presentamos algunos ejemplos de consecuencias del efecto multiplicador cuando confluyen dos causas. Cada combinación presenta unos problemas funcionales típicos, un impacto en el presupuesto y un impacto en el plazo:
Falta de tiempo para definir/probar (causa de cliente) y metodología débil (causa de Partner)
- Problemas funcionales típicos: procesos sin cerrar, UAT incompleto y aparición de defectos críticos en el arranque.
- Impacto en presupuesto: más soporte, más retrabajo y más “cambios urgentes”.
- Impacto en plazo: retrasos en cascada por la replanificación constante.
Software inadecuado (causa mixta) y equipo poco cualificado (causa del Partner)
- Problemas funcionales típicos: “parche sobre parche”, inconsistencias y rendimiento pobre.
- Impacto en presupuesto: desarrollo extra y pruebas interminables.
- Impacto en plazo: el plan deja de ser creíble y el go-live se aplaza varias veces.
Rechazo de usuarios (causa de cliente) y contrato ambiguo (causa mixta)
- Problemas funcionales típicos: discusión sobre “qué estaba incluido”, baja adopción del sistema y uso de Excel paralelo.
- Impacto en presupuesto: conflictos por desconfianza, ampliaciones y horas no previstas.
- Impacto en plazo: bloqueo por decisiones y validaciones que se eternizan.
Abandono del interés (causa de cliente) y falta de recursos (causa de Partner)
- Problemas funcionales típicos: se paralizan sesiones de definición o pruebas, se pierde conocimiento, hay rotación de personal y sucesión de fases de abandono temporal del proyecto.
- Impacto en presupuesto: coste por reinicios y pérdida de eficiencia.
- Impacto en plazo: dinámica de abandono y reinicio, con meses perdidos por cada pausa.
Conclusión
La implantación de un ERP tiene peores resultados cuando se gestiona como instalación de software en lugar de como cambio de reglas, datos y comportamiento. También influyen otros factores en el resultado, como liderazgo, tiempo protegido y metodología.
Ningún proyecto está libre de problemas técnicos o errores no detectados. Pero lo cierto es que nuestra experiencia de 35 años implantando sistemas ERP en nuestros clientes nos ha enseñado que, si se cuidan todos los factores determinantes, estos problemas pueden minimizarse.
Mario Pérez Martín
Con más de 20 años de experiencia en el sector TIC, ha implantado y también liderado multitud de proyectos de implantación de diferentes ERP en empresas de diversos sectores. Actualmente gestiona las delegaciones de LIDER IT de la zona norte con más de 100 personas a su cargo y una cartera de más de 600 clientes.