Hay un dato que la industria del software empresarial prefiere no poner en sus folletos: muchos proyectos de ERP no entregan lo que prometieron. Terminan fuera de presupuesto, fuera de tiempo o, peor, con un sistema que la empresa nunca llega a usar de verdad.
Lo notable es que ese número casi nunca se explica por el software. Los ERP modernos son productos maduros, probados en miles de empresas. Cuando un proyecto fracasa, la causa está casi siempre en cómo se implementó.
Este artículo recorre esas causas. Si tu empresa está evaluando un ERP, o ya tiene un proyecto en marcha que avanza con dificultad, entender estas causas vale más que cualquier comparativa de funcionalidades.
La metáfora del trasplante
Un ERP se parece más a un trasplante que a una instalación.
Instalar es lo que haces con una impresora. La conectas, descargas el controlador y funciona igual en cualquier oficina del mundo. Un ERP es otra cosa: es un órgano nuevo que llega a un cuerpo que ya tiene años funcionando con sus propios ritmos, sus propias mañas y sus propios anticuerpos.
Y como en cualquier trasplante, el riesgo principal es el rechazo.
Una empresa puede comprar el mejor sistema del mercado, contratar la implementación, migrar los datos y encender el switch. Si la organización rechaza el órgano —si la gente sigue trabajando en sus hojas de Excel, si los procesos del sistema no corresponden a los procesos reales, si nadie confía en los números que arroja—, el trasplante fracasó aunque la cirugía haya salido "bien".
Punto clave
Qué significa realmente que un ERP fracase
Los fracasos espectaculares —proyectos cancelados, demandas al proveedor— son la minoría y salen en las noticias. La mayoría de los fracasos son silenciosos, y por eso más peligrosos: la empresa paga el sistema completo y recibe una fracción de su valor.
Un proyecto de ERP fracasó cuando ocurre cualquiera de estas cosas:
- El sistema arrancó, pero nadie lo usa bien. La captura es incompleta, los inventarios del sistema no coinciden con los del almacén y las decisiones se siguen tomando con Excel.
- El costo final duplicó o triplicó lo presupuestado, casi siempre por adecuaciones y retrabajos que nadie anticipó.
- El calendario se volvió ficción. Lo que iba a tomar seis meses lleva dos años y todavía no hay fecha de salida.
- El sistema opera, pero amarrado con alambre: tantos parches y excepciones que cada actualización es una crisis.
La consultora McKinsey, junto con la Universidad de Oxford, estudió miles de proyectos grandes de tecnología y encontró que en promedio exceden su presupuesto en 45% y entregan 56% menos valor del previsto. El ERP es el caso típico de ese patrón. La pregunta útil es qué causa esos riesgos y cómo se evitan.
Las seis causas reales del fracaso
Décadas de proyectos fallidos apuntan una y otra vez a las mismas seis causas, y todas son de gestión.
Causa 1: Se automatiza el caos
Michael Hammer, el padre de la reingeniería de procesos, lo escribió en 1990 en un artículo que sigue vigente: el error clásico de las empresas es usar tecnología para acelerar procesos que nunca debieron existir en esa forma.
Si tu proceso de compras requiere cuatro firmas, dos de ellas por costumbre, implementar un ERP sin cuestionarlo te da exactamente eso: cuatro firmas electrónicas. El caos, pero más rápido y más caro.
Por eso toda implementación seria empieza con un levantamiento de procesos: documentar cómo opera la empresa de verdad —no como dice el manual—, decidir qué se simplifica y solo entonces configurar el sistema. Cuando un proveedor quiere saltarse esta etapa para "ahorrar tiempo", está sembrando la causa número uno del fracaso. Si no tienes claro dónde duele tu operación, conviene empezar por identificar los puntos de dolor de tu empresa antes de tocar cualquier sistema.
Causa 2: Se deja en manos del área de sistemas
Cuando la dirección general delega el ERP al área de sistemas y se desentiende, el proyecto queda huérfano. Sistemas puede resolver lo técnico, pero no puede decidir cómo debe operar ventas, ni obligar a producción a cambiar su forma de trabajar, ni arbitrar cuando dos áreas quieren procesos incompatibles.
Un ERP redefine cómo trabaja la empresa entera. Esas decisiones son de dirección. Los proyectos donde el director general está presente en los comités, destraba conflictos y comunica por qué importa el cambio tienen una probabilidad de éxito radicalmente distinta de aquellos donde la dirección solo firma el cheque.
Causa 3: Personalización excesiva
Suena paradójico, pero personalizar de más es una de las formas más caras de fracasar. Cada adecuación que aleja el sistema de su versión estándar cuesta tres veces: cuando se desarrolla, cuando se prueba y cada vez que el sistema se actualiza durante los siguientes diez años.
La pregunta correcta ante cada "es que nosotros lo hacemos diferente" es incómoda pero necesaria: ¿esta diferencia es una ventaja competitiva real o solo una costumbre? Si es ventaja, se personaliza y se paga con gusto. Si es costumbre, es más barato cambiar el proceso que cambiar el sistema. Las empresas que personalizan todo terminan pagando por blindar sus malos hábitos.
Causa 4: Los datos sucios se mudan a la casa nueva
Migrar datos es como una mudanza: es la única oportunidad real de tirar lo que no sirve. Catálogos de clientes con duplicados, productos dados de alta tres veces con claves distintas, saldos que nadie ha conciliado en años.
Cuando esa limpieza no se hace, el sistema nuevo nace contaminado. Y el efecto es letal para la adopción: la primera vez que un gerente consulta un reporte y encuentra un número que sabe incorrecto, deja de confiar en el sistema. Recuperar esa confianza cuesta diez veces más que limpiar los datos a tiempo.
Causa 5: La adopción se da por sentada
Aquí muere la mayor cantidad de proyectos. La empresa invierte meses en configurar el sistema y reserva tres días para capacitar a la gente que lo va a usar ocho horas diarias.
Las personas no se resisten al cambio por necedad: se resisten porque nadie les explicó qué gana la operación, porque el sistema les exige más captura que antes sin que vean el beneficio, o porque temen que la automatización los vuelva prescindibles. Ese factor humano tiene su propia lógica y merece su propio plan; lo tratamos a fondo en cómo modernizar sin perder talento.
La regla práctica: si tu plan de implementación dedica menos del 20% del esfuerzo a capacitación, comunicación y acompañamiento, tu plan alcanza para configurar un software y se queda corto para cambiar una empresa.
Causa 6: El calendario manda sobre la realidad
"Tenemos que salir en enero porque empieza el ejercicio fiscal." Las fechas elegidas por política y no por preparación producen arranques forzados: se sale en vivo con módulos a medias, con pruebas incompletas y con la gente a medio capacitar, porque mover la fecha "se vería mal".
Un arranque prematuro pide tiempo prestado, con intereses. Los errores que las pruebas hubieran detectado en un ambiente controlado aparecen en producción, frente a clientes y con la facturación en juego.
Señales tempranas de que tu proyecto está en riesgo
Si ya tienes un proyecto en marcha, estas señales predicen problemas con meses de anticipación:
- Nadie de dirección general asiste a los comités del proyecto.
- El levantamiento de procesos duró días en lugar de semanas, o no existió.
- La lista de personalizaciones crece cada mes en lugar de reducirse.
- No hay un responsable interno del proyecto con tiempo asignado; todos lo atienden "además de su chamba".
- La limpieza de datos se pospuso "para después del arranque".
- La capacitación está planeada como un evento único y no como un proceso.
- La fecha de salida es inamovible sin importar el avance real.
Tres o más señales no garantizan el fracaso, pero sí garantizan que el proyecto necesita una corrección de rumbo ahora, cuando todavía es barata.
Cómo se ve una implementación que sí llega a puerto
Los factores de éxito son el espejo de las causas de fracaso, y conviene decirlos en positivo:
| Factor | En la práctica |
|---|---|
| Procesos antes que software | Levantamiento serio, simplificación y luego configuración |
| Dirección involucrada | El proyecto es de negocio, con la dirección en la mesa |
| Estándar primero | Se personaliza solo lo que da ventaja competitiva |
| Datos limpios | Depuración de catálogos y saldos antes de migrar |
| Adopción planeada | Capacitación continua, comunicación y acompañamiento post-arranque |
| Fechas honestas | Se sale en vivo cuando las pruebas lo respaldan |
Los seis factores son de gestión. Por eso la elección del implementador pesa tanto como la elección del software: el implementador correcto es el que tiene la experiencia —y la honestidad— para sostener estas disciplinas cuando el proyecto se pone difícil.
La pregunta correcta antes de empezar
Si estás evaluando un ERP, la pregunta que más conviene hacerle a cualquier proveedor es "¿cómo vas a evitar que mi proyecto sea parte de la estadística?". La respuesta te dirá más que cualquier demostración: si habla de levantamiento de procesos, de adopción y de datos, estás ante alguien que ha vivido proyectos reales; si solo habla de módulos y funcionalidades, ya sabes qué esperar.
En IS del Norte llevamos implementando tecnología empresarial desde 1999 y somos Socio de Valor Intelisis. Hemos visto de cerca por qué los proyectos fracasan y, sobre todo, qué disciplina se requiere para que no lo hagan. Si quieres entender cómo se ve ese enfoque aplicado a tu operación, puedes leer qué es Intelisis y cómo se integra con tus otros sistemas o conversar directamente con nuestro equipo.
Fuentes: Michael Hammer, "Reengineering Work: Don't Automate, Obliterate" (Harvard Business Review, 1990); McKinsey & Company y Universidad de Oxford, "Delivering large-scale IT projects on time, on budget, and on value" (2012), análisis de más de 5,400 proyectos de TI.
