Javi Ursua

El ERP y el CRM: cuando el proceso se escribe en el software

Qué hacen realmente estos dos sistemas, qué se decide al configurarlos, qué dicen las cifras que se pueden sostener sobre los sobrecostes, y por qué las implantaciones se tuercen por la organización antes que por el software.

Un ERP se paga dos veces. La primera factura es de licencias, consultoría y horas de proyecto. La segunda es la forma de trabajar que la organización tiene que adoptar para poder usarlo, y no aparece en ningún presupuesto.

Hay una medida vieja y buena de esa desproporción. Erik Brynjolfsson y Lorin Hitt la publicaron en el Journal of Economic Perspectives en el año 2000: mientras un dólar de capital ordinario vale aproximadamente un dólar para los mercados financieros, un dólar de capital en tecnología de la información aparecía correlacionado con del orden de diez dólares de valor bursátil adicional en las grandes empresas estadounidenses entre 1987 y 1994. Su lectura es que, por cada dólar de ordenadores, la empresa había acumulado unos nueve dólares en activos intangibles: procesos rediseñados, formación, formas de trabajar nuevas. Lo resumen con una imagen que sirve para todo este artículo: los costes de ajuste separan el valor de un ordenador parado en el muelle de carga del de uno plenamente integrado en la organización.

Un ERP es ese muelle de carga en su versión más cara.

Los dos sistemas, contados sin el folleto del proveedor

Un ERP —enterprise resource planning— es un sistema que registra las transacciones de una empresa en una base de datos compartida: pedidos, existencias, compras, producción, facturas, cobros, nóminas. Su promesa, la que enunció Thomas Davenport en Harvard Business Review en 1998 y sigue siendo la misma, es la integración sin costuras de toda la información que circula por una compañía.

Su origen explica bastante de cómo funciona. Rondeau y Litteral trazaron esa genealogía en el Production and Inventory Management Journal: cinco etapas encadenadas que van del punto de pedido a la planificación de necesidades de materiales, de ahí a la planificación de recursos de fabricación, y de ahí al ERP. Nació para decidir qué se fabrica y con qué materiales, y fue creciendo hasta abarcar la empresa entera. Por eso un ERP piensa en transacciones y en existencias incluso cuando lo usa una empresa de servicios.

Un CRM —customer relationship management— es más difícil de definir, y no por descuido. Adrian Payne y Pennie Frow, en el Journal of Marketing en 2005, identificaron tres formas distintas de entender el término, desde la estrecha —una solución tecnológica concreta— hasta la estratégica, y defendieron que solo la tercera sirve de algo. Esa ambigüedad sobrevive: cuando dos personas de la misma empresa dicen «el CRM», con frecuencia hablan de dos cosas.

La diferencia práctica entre los dos, y es la que más consecuencias tiene:

El ERP registra lo que ya ha pasado y tiene consecuencias inmediatas si no se registra. Si nadie introduce el albarán, no sale la factura. Si nadie da de alta el material, no se puede comprar. El sistema se alimenta porque el negocio se detiene si no se alimenta.

El CRM registra lo que todavía no ha pasado. Una conversación, una oportunidad, una previsión, un compromiso verbal. Nada se detiene mañana si esa información no entra. Solo entra si alguien decide que entre, y esa decisión hay que sostenerla todos los días durante años.

De ahí sale un fenómeno que cualquiera reconoce: «el CRM que nadie usa» es un género conocido y «el ERP que nadie usa» casi no existe. Con un matiz importante, porque es donde suele estar el problema real: los módulos del ERP que no bloquean nada si están vacíos se comportan exactamente igual que un CRM. Previsiones, motivos de pérdida, seguimiento comercial, causas de una incidencia. Ahí la resistencia aparece igual, y por el mismo motivo.

Configurar un ERP es decidir cómo trabaja la empresa

Una implantación se presenta como un proyecto técnico y se decide en reuniones que parecen técnicas. Lo que se está decidiendo en ellas es otra cosa.

Cada parámetro que se fija responde a una pregunta de organización. Quién aprueba un descuento y a partir de qué importe. En qué orden ocurren las cosas: si se puede servir sin crédito verificado, si se puede facturar sin albarán conforme. Qué campos son obligatorios, que es la forma más eficaz que existe de obligar a alguien a hacer algo. Y sobre todo qué queda prohibido, porque el sistema sencillamente no lo permite.

Al terminar, el proceso de la empresa está escrito en un sitio del que después cuesta mucho sacarlo. Escrito, además, con más precisión de la que tenía antes: lo que estaba en la costumbre, en el criterio de una persona veterana y en un par de excepciones que todo el mundo aceptaba, pasa a estar en una configuración.

Hay dos caminos para llegar ahí, y su coste es distinto.

Adoptar el proceso que trae el fabricante —configurar— significa cambiar la forma de trabajar para encajar en lo que el software da por supuesto. Se paga una vez, en discusiones internas, en formación y en el malestar de quien llevaba quince años haciéndolo de otra manera. Es un coste alto, concentrado y visible.

Escribir el proceso propio dentro del software —personalizar— significa modificar el sistema para que se parezca a la empresa. Se paga en el proyecto y se vuelve a pagar en cada actualización, en cada integración y cada vez que alguien tiene que entender por qué esa parte no funciona como en la documentación. Es un coste menor al principio y permanente después.

Sobre cuál de los dos caminos sale mejor hay una opinión oficial y muy poco diplomática. En enero de 2024, los comisionados nombrados por el Gobierno británico para intervenir el Ayuntamiento de Birmingham escribieron al Secretario de Estado sobre la implantación de Oracle que la ciudad acababa de estrellar:

«Es sabido en la gestión del sector público que implantar cualquier sistema de software propietario importante exige adoptar los procesos de buenas prácticas que el sistema proporciona, en lugar de intentar adaptar elementos importantes del sistema a las formas de trabajar actuales e ineficientes. Birmingham no quiso seguir esa sabiduría ganada con esfuerzo, gestionó y lideró mal el programa, ignoró todas las señales de alarma y ha llegado al final inevitable.»

En esa misma carta, los comisionados cifraban en unos 50 millones de libras el coste de volver a implantar el sistema, aparte de un agujero presupuestario de otro orden. En el tercer informe, de octubre de 2025, la reimplantación seguía en marcha con fecha prevista para abril de 2026: algo más de dos años de trabajo para volver al punto de partida. El diseño, esta vez, se firmó ateniéndose a un principio que el documento nombra en inglés y con todas las letras: adopt not adapt. Adoptar, no adaptar.

Hay un detalle que ayuda a calibrar lo que cuesta la otra vía. En la mayor base de datos publicada sobre sobrecostes de proyectos informáticos —5.392 proyectos, de la que hablo en la siguiente sección— el mayor sobrecoste de toda la muestra fue un pequeño trabajo de personalización de un flujo de trabajo presupuestado en 1.500 dólares que terminó costando 425.000.

Salir después es caro por una razón que no es la de siempre

En Cómo elegir una herramienta digital sostengo que el coste de salir de una herramienta se calcula antes de entrar, y que la parte cara no son los datos. En un ERP eso se ve con una claridad incómoda.

Sacar la información es un problema resoluble y con apoyo legal. Lo que no sale en ninguna exportación es el proceso, porque a esas alturas el proceso solo existe dentro del sistema: en su configuración, en los procedimientos que se reescribieron para encajar, en la formación que recibió toda la plantilla y en lo que la gente ya hace sin pensar. Cambiar de ERP obliga a volver a decidir todo lo que se decidió la primera vez, con el añadido de que ahora hay quince años de casos particulares que alguien resolvió y nadie documentó.

Por eso la profundidad del sistema es la variable que gobierna la decisión. Una aplicación de notas es reversible. Una suite corporativa casi no lo es, como cuento en Del ordenador personal a la IA generativa . Un ERP está en el extremo de esa escala.

Las cifras que aguantan una pregunta, y las que no

Circulan mucho porcentajes del tipo «entre el 50 % y el 75 % de las implantaciones de ERP fracasan». Cuando se busca el estudio detrás, casi siempre aparecen encuestas de consultoras con muestra autoseleccionada, o una cita que remite a otra cita. No publico ninguna de ellas.

Lo que sí existe es un trabajo revisado por pares y con los datos a la vista. Bent Flyvbjerg y cinco coautores publicaron en el Journal of Management Information Systems en 2022 el análisis de 5.392 proyectos de TI terminados entre 2002 y 2014, en 66 países, del sector público y del privado, por un total de 56.500 millones de dólares. De la muestra, 1.612 son proyectos de ERP: el tipo más numeroso de todos. Sus cifras de sobrecoste, medido como coste real dividido entre coste estimado:

Los autores hacen notar que el sobrecoste de los ERP se diferencia de forma estadísticamente significativa del de los demás tipos de proyecto, y se diferencia a la baja. Comparados con los proyectos de cadena de suministro o con la categoría general, los ERP se portan mejor de lo que su reputación sugiere.

El hallazgo que importa no está en la media. Está en la forma de la distribución: los sobrecostes no se reparten como una campana, sino según una ley de potencia, con una cola larga que empieza justo donde se dobla el presupuesto. Traducido: los sobrecostes pequeños son frecuentes y anodinos, y de vez en cuando aparece uno que se lleva la empresa por delante. Quien planifica suponiendo una distribución normal está subestimando esa posibilidad de forma sistemática, y es lo que los autores señalan como el error de fondo de la profesión entera.

El mecanismo que proponen para explicarlo encaja exactamente con lo que es un ERP: la interdependencia entre componentes. Un problema en una pieza desencadena reacciones en cadena en las que dependen de ella. Un sistema cuyo argumento de venta es que todo está conectado con todo es, por construcción, un sistema donde un fallo local se propaga.

Y dos advertencias que dan los propios autores, que conviene retener porque van en la dirección incómoda: los proyectos cancelados no están en los datos —de esos no se puede seguir el coste final— y las organizaciones que comparten información sobre sus proyectos suelen ser las que mejor los gestionan. La muestra es optimista.

Un fracaso con las cuentas públicas

En febrero de 2018, Revlon puso en marcha en Estados Unidos un nuevo ERP de SAP. Lo que ocurrió después está contado por la propia compañía en el informe anual que presentó a la SEC en marzo de 2019, que es donde conviene leer estas historias, porque ahí mentir tiene consecuencias.

Su planta de Oxford, en Carolina del Norte, sufrió interrupciones en el nivel de servicio que afectaron a su capacidad de fabricar producto terminado y de servir pedidos a grandes clientes dentro y fuera del país. La compañía estima unos 64 millones de dólares de ventas netas que no pudo servir durante 2018 y 53,6 millones de dólares de cargos adicionales, en buena parte para remediar la caída del servicio. Declaró además una debilidad material en su control interno sobre la información financiera, principalmente relacionada con la implantación, y concluyó que su control interno no era efectivo.

Lo más instructivo del documento son las tres causas que la propia empresa enumera. La primera, no haber hecho una evaluación continua de riesgos que identificara lo que la implantación ponía en peligro. La segunda, no haber mantenido un número suficiente de personas formadas que entendieran las responsabilidades que tenían asignadas y respondieran de ellas. La tercera es consecuencia de las dos anteriores: los controles de proceso no se diseñaron ni se operaron de forma consistente, y por eso dejaron de registrarse bien el inventario, las cuentas a cobrar, las ventas y el coste de ventas.

Ninguna de las tres habla del software. Las tres hablan de riesgo, de personas y de procesos.

Lo que decide la dirección y no se puede delegar

De todo lo anterior salen cinco decisiones que no son técnicas, por mucho que se tomen en una reunión con gente técnica delante.

Quién es el dueño de cada proceso, con nombre y apellidos, y no es el departamento de sistemas. Sistemas implanta; quien decide cómo se aprueba un pedido es quien responde de que los pedidos se aprueben bien.

Cuánto se adopta y cuánto se adapta, decidido antes y por escrito. Es la decisión con más consecuencias económicas de todo el proyecto y es la que más se toma sobre la marcha, caso por caso, en la sala de al lado.

Qué información tiene que existir y estar limpia antes de arrancar. En Birmingham, dos años después del desastre, «limpiar datos de mala calidad» seguía figurando entre los riesgos vivos de la reimplantación.

Qué significa terminado. El día del arranque no es el final: es el día en que empieza la parte que decide el resultado. Un proyecto que se declara cerrado al arrancar deja la adopción sin dueño justo cuando la adopción es todo lo que queda.

Y el orden entre adopción y desarrollo. Seguir ampliando un sistema que la gente todavía no usa multiplica la inversión sin multiplicar el retorno, y produce el efecto contrario al buscado: cada módulo nuevo añade una razón más para seguir trabajando por fuera.

Conviene saber, además, que la resistencia no siempre es lo que parece. Existe trabajo empírico que muestra que los equipos autogestionados y los ERP son difíciles de combinar en la práctica, porque el sistema trae dentro un reparto de decisiones que puede contradecir el que la organización tenía. Cuando alguien se resiste a usar una pantalla, a veces se está resistiendo a perder una decisión que era suya.

Qué añade la inteligencia artificial, y qué no

Los grandes fabricantes están incorporando asistentes dentro de estos sistemas. Lo que hacen bien es real y se nota: preguntar en lenguaje natural en lugar de construir un informe, redactar el resumen de una cuenta, proponer el siguiente paso de una gestión, encontrar el dato sin saber en qué pantalla vive. Para quien tiene que usar un ERP sin querer aprendérselo, eso vale mucho.

Lo que no cambia es de dónde sale la respuesta. Un asistente lee lo que hay dentro del sistema, y lo que hay dentro del sistema depende de la adopción que se consiguió. Un modelo que resume el estado de la cartera comercial a partir de un CRM que la mitad del equipo no rellena produce un resumen preciso de una realidad que no existe, y lo produce con la misma seguridad con la que produciría uno bueno. El mecanismo por el que eso ocurre está en Por qué un modelo alucina, y qué hacer con eso .

La economía tampoco cambia. Los mismos autores del dato con el que abre este artículo publicaron en 2018 el argumento de la curva en J: las tecnologías de propósito general exigen inversiones complementarias —procesos rediseñados, productos nuevos, formación— que son intangibles, se miden mal y se pagan antes de que llegue ningún beneficio. Por eso la productividad medida cae al principio y sube más tarde. Es exactamente lo que ya pasaba con el ERP, veinte años después y con otro nombre. Y es la razón por la que la IA le renta más a quien ya tenía el proceso bajo control, un patrón que aparece también fuera de las empresas y que cuento en Quien más gana con la IA es quien ya sabía hacerlo .

Hay una cosa que sí es nueva y merece atención. Un ERP configurado es opaco pero auditable: la regla está escrita en alguna parte y alguien puede ir a leerla. Cuando la recomendación la produce un modelo, no hay regla que leer. El proceso sigue estando escrito en el software, y ahora además está escrito donde no se puede consultar. Para cualquier decisión con consecuencias —un crédito, un precio, una prioridad— eso convierte la trazabilidad en un requisito de diseño y no en una cuestión de confianza.

Cómo se sabe que ha terminado

Una implantación termina el día en que nadie recuerda cómo se hacía antes. Hasta ese día conviven dos procesos: el que está escrito en el sistema y el que la gente ejecuta de verdad, con sus hojas de cálculo paralelas, sus correos y sus llamadas. Los dos funcionan, y el segundo gana siempre, porque es el que produce el trabajo mientras el primero produce informes.

Ese es el trabajo caro, es el que no cabe en el contrato con el proveedor y es el único que no puede hacer nadie de fuera.

Fuentes