ERP y gestión del cambio: el módulo invisible

Los ERP no fracasan por el software. Fracasan antes, cuando una empresa decide comprar un sistema para no tener que decidir cómo quiere trabajar.

Llevo más de 20 años dentro de proyectos ERP. Primero los sufrí como CIO y después he estado del lado de quien los vende y los implanta. He visto suficientes arranques como para saber que el problema casi nunca está donde lo busca el comité de dirección.

En 2019 acompañé un proyecto en una empresa de distribución alimentaria. El diagnóstico interno era unánime: «el sistema no da». Compras llegaba tarde, el almacén no cuadraba y finanzas cerraba el mes a base de Excel. Cambiaron de ERP. Seis meses después del arranque, el almacén seguía sin cuadrar. La causa era sencilla y nadie quiso verla durante la venta. Había tres maneras distintas de dar de alta un artículo, nadie era responsable del maestro de productos y el jefe de compras aprobaba pedidos por WhatsApp. El sistema nuevo registraba ese desorden con mucha más precisión que el anterior.

Reconozco que yo también lo creí durante años. Pensaba que un buen software ordenaba a la organización. Lo que hace realmente es exponerla.

El cambio tiene coste, aunque no aparezca en la oferta

Prosci, la consultora que más tiempo lleva midiendo esto, publica desde hace más de dos décadas su estudio de buenas prácticas en gestión del cambio. Su conclusión se repite edición tras edición: los proyectos con una gestión del cambio excelente tienen unas seis veces más probabilidades de cumplir sus objetivos que los que la gestionan mal.

Ahora revise cualquier propuesta de implantación que tenga encima de la mesa y busque esa partida. Si existe, suele ser formación de usuarios dos semanas antes del arranque.

Eso se llama curso. La gestión del cambio empieza meses antes, cuando alguien explica a cada área qué va a dejar de hacer, qué va a hacer distinto y quién responde si no funciona.

En la empresa mediana española hay un agravante. Los usuarios clave del proyecto son las mismas personas que sacan adelante la operación diaria. En mi experiencia, si no se libera al menos una cuarta parte de su jornada durante la implantación, el proyecto avanza a ratos y se decide en los pasillos.

Los datos se heredan

Gartner estimó en 2020 que la mala calidad de los datos cuesta a las organizaciones una media de 12,9 millones de dólares al año. En una mediana española la cifra será otra. El mecanismo es el mismo.

Un ERP nuevo migra los datos que le den. Clientes duplicados, artículos sin unidad de medida, el mismo proveedor dado de alta tres veces con nombres ligeramente distintos. (Los datos maestros se los revisa desde antes de implementar un ERP no en el camino)

Lo que antes era un problema escondido en el sistema antiguo pasa a ser un error visible en el nuevo, con trazabilidad y fecha. Y la culpa, por supuesto, se la lleva el software.

El calendario también es una decisión de negocio

Una empresa en la que trabaje arrancó su nuevo ERP en enero de 1999, con un plazo recortado respecto a lo que recomendaban sus propios integradores y a pocas semanas de su temporada fuerte. Los análisis hechos después dieron el resultado: alrededor centenas de pedidos no se pudieron servir para el inicio de la temporada escolar de ese año. El software no fue el problema principal. Lo fueron la fecha y la decisión de arrancar todo a la vez. Cada vez que un comité fija la fecha de arranque antes de cerrar el diseño de procesos, está repitiendo esa decisión a menor escala.

Adaptar el software para no cambiar el proceso

Lidl dedicó siete años y unos 500 millones de euros a implantar un ERP estándar de mercado. En 2018 abandonó el proyecto y volvió a su sistema propio.

La prensa económica alemana atribuyó buena parte del fracaso a una decisión concreta: Lidl valoraba su inventario por precio de compra y el estándar del sistema lo hacía por precio de venta. En lugar de revisar el proceso, se optó por adaptar el software.

Ningún comité de dirección quiere ser el que cambia la forma de valorar el stock. Prefiere pagar para que el software no se entere.

Cada personalización que protege una costumbre se paga tres veces: al desarrollarla, en cada actualización y el día que la persona que la entendía deja la empresa.

Dónde mi tesis no aplica

Hay casos en los que el problema sí es el software. Si su ERP ya no tiene soporte del fabricante, no hay gestión del cambio que lo arregle, por ejemplo:

• SAP ECC 5.0
• SAP Business One 8.x, 9.0
• Microsoft Dynamics AX 2012 R3
• Dynamics NAV 2013, 2016, 2015
• Oracle PeopleSoft / Oracle JD Edwards versiones antiguas
  Infor LN (Baan IV/V)

Entre otros, ya terminaron su soporte normal y extendido, y todavía hay empresas operando sobre él.

Lo mismo ocurre cuando las exigencias fiscales y de facturación electrónica van por delante de lo que el sistema puede cumplir. Ahí cambiar de plataforma es una obligación, no una opción estratégica.

Eso sí, también me he equivocado en sentido contrario. En algún proyecto insistí tanto en ordenar procesos antes de tocar el sistema que la empresa pasó casi dos años esperando una organización perfecta. Hoy lo aplico así: se definen los procesos críticos, no todos, y el resto se corrige con el sistema ya en marcha.

Criterio para decidir

Antes de firmar una implantación, yo haría tres preguntas en el comité de dirección.

• Quién es el dueño de cada dato maestro: clientes, artículos, proveedores y plan de cuentas. Con nombre propio.

• Qué proceso va a cambiar y quién firma ese cambio, aunque moleste a su área.

• Cuántas horas de su propia gente reserva para el proyecto. Las del integrador ya vienen en la oferta.

Si alguna de las tres se queda sin respuesta, el proyecto todavía no tiene fecha de arranque. Tiene fecha de retraso.

• A esto yo sumaría, si tu proyecto de ERP tiene entre seis y siete dígitos de presupuesto DEBE existir el rol de gestor / gerente o líder de cambio.

En resumen: decidir bien es decidir antes.

El software se compra en un mes. Lo demás no se lo puede vender nadie.

---