Logo

Por qué fracasan las implementaciones de ERP en México

IS del Norte10 de junio de 20269 min
Por qué fracasan las implementaciones de ERP en México

Hay un dato que la industria del software empresarial prefiere no poner en sus folletos: la mayoría de los proyectos de ERP no entrega lo que prometió. Según el estudio que cites, entre la mitad y tres cuartas partes de las implementaciones 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ó, no en qué se compró.

Este artículo desarma esa estadística. 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 no se instala: se trasplanta.

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 no es la cirugía. 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

El éxito de un ERP no se mide el día que arranca, sino seis meses después: cuando la operación entera confía en el sistema y nadie mantiene registros paralelos "por si acaso".

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 no es si esos riesgos existen —existen—, sino qué los causa y cómo se evitan.

Las seis causas reales del fracaso

Décadas de proyectos fallidos apuntan una y otra vez a las mismas causas. Ninguna es tecnológica.

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 trata como proyecto de sistemas, no de negocio

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, tienes un plan para configurar un software, no 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 no ahorra tiempo: lo pide 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:

FactorEn la práctica
Procesos antes que softwareLevantamiento serio, simplificación y luego configuración
Dirección involucradaEl proyecto es de negocio, con la dirección en la mesa
Estándar primeroSe personaliza solo lo que da ventaja competitiva
Datos limpiosDepuración de catálogos y saldos antes de migrar
Adopción planeadaCapacitación continua, comunicación y acompañamiento post-arranque
Fechas honestasSe sale en vivo cuando las pruebas lo respaldan

Ninguno de estos factores es técnico. Todos son de gestión. Por eso la elección del implementador pesa tanto como la elección del software: el implementador correcto no es el que configura más rápido, sino 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 no es "¿qué hace tu sistema?", sino "¿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 integradores de Intelisis desde 2007. 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 por qué Intelisis funciona para empresas mexicanas 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, estudio sobre sobrecostos y valor entregado en grandes proyectos de TI; estimaciones de Gartner ampliamente citadas sobre la proporción de implementaciones de ERP que no cumplen sus objetivos (55–75%).
Compartir

Artículos Relacionados