El reto de integrar un ERP empieza antes de la tecnología

En el ERP, el precio de un producto es 87. En el CRM, 91. En la hoja de cálculo del equipo comercial, 89.

Los tres sistemas funcionan. Ninguno está caído. Cada uno puede mostrar de dónde obtuvo su número y una API puede transportar cualquiera de los tres sin perder un decimal.

El problema empieza cuando llega un pedido y alguien debe decidir cuál precio representa el acuerdo con el cliente.

La escena expone una distinción que suele perderse durante una integración ERP: mover un dato no equivale a ponerse de acuerdo sobre su significado. La interfaz puede ser correcta y el proceso seguir roto.

Pensemos en un pedido que atraviesa ecommerce, ERP, WMS y finanzas. La tienda lo acepta. El ERP confirma inventario. El almacén no consigue reservar el producto. Finanzas, entretanto, recibe la instrucción de facturar.

Desde tecnología, los servicios están disponibles y los mensajes fueron entregados. Desde operaciones, hay un cliente esperando, una factura que quizá no debió emitirse y varias personas tratando de reconstruir qué ocurrió.

Ese tipo de fallo deja pocas alertas técnicas. Se hace visible en otro lugar: un pedido detenido, una conciliación al final del mes, inventario que existe en pantalla pero no donde se necesita, o una persona que copia valores entre sistemas para que el trabajo continúe. La integración está online. La empresa, por unos minutos o por varios días, opera alrededor de ella.

En mayo de 2024, Birmingham City Council presentó un informe para reimplementar Oracle Fusion Cloud ERP. El documento oficial no atribuye el problema a una sola causa. Habla de configuración defectuosa, falta de rediseño de procesos, pruebas insuficientes y gestión del cambio insuficiente durante la implementación inicial.

Las consecuencias tampoco quedaron confinadas al área de TI. El Council documentó transacciones financieras contabilizadas de forma incorrecta, reporting financiero y de recursos humanos por debajo de los requisitos mínimos, procesos de Oracle que no habían sido adoptados de manera efectiva, baja madurez en patrocinio y propiedad de procesos, y trabajo aislado entre equipos funcionales.

En 2023 llegó a estimar que completar la implementación funcional costaría alrededor de £100 millones. Hay una cifra menos espectacular y quizá más útil para entender el daño cotidiano: el informe de 2024 calculó que los arreglos y procedimientos manuales añadían £3,2 millones anuales solamente en finanzas, y más de £5 millones al incluir recursos humanos y compras.

Conviene leer el caso completo. El mismo Council sostuvo que Oracle todavía podía cubrir sus requisitos y que cambiar de producto implicaría buena parte del mismo trabajo. La respuesta propuesta incluyó nuevos procesos de punta a punta, responsables claros, gobierno y cambio organizacional, además de la reimplementación técnica.

El diagnóstico no fue «el ERP no funciona». Fue bastante más incómodo: la organización había intentado cambiar su operación sin conseguir que ese cambio se volviera práctica compartida.

La investigación de Maclean’s sobre Target Canada reconstruyó otro tipo de ruptura. La compañía abrió su operación canadiense con un nuevo entorno de SAP y una cadena de suministro que dependía de datos de producto recién cargados. Parte de esos registros contenía dimensiones en unidades incorrectas o en el orden equivocado, monedas erróneas, información incompleta y descripciones deficientes.

Para el software, aquellos valores eran datos. Para una tienda o un centro de distribución, determinaban cuántas unidades cabían en un estante, cómo debía moverse una caja o qué inventario estaba disponible.

El resultado era una contradicción física: podía haber producto dentro de la red y, al mismo tiempo, estantes vacíos donde el cliente esperaba encontrarlo. SAP no necesitaba inventar el error. Bastaba con procesar fielmente una representación defectuosa del negocio.

Target cerró sus operaciones en Canadá en 2015 después de una expansión marcada por fallas estratégicas, de velocidad, surtido, datos y ejecución.

El valor del caso está en otro punto. Incluso una plataforma empresarial capaz de coordinar miles de movimientos ejecutará decisiones equivocadas si sus datos maestros describen mal el mundo físico.

No todas las divergencias terminan en una reimplementación pública o en el cierre de una operación nacional.

Un caso publicado por Excellis describe cómo Trinseo mantenía precios y datos maestros de clientes en SAP y Salesforce. La información requería actualizaciones manuales en ambos sistemas. Distintas funciones descargaban, cargaban y daban formato a archivos para cumplir controles; una conciliación anual de clientes podía tomar semanas, y algunos pedidos esperaban días mientras alguien confirmaba un precio.

Excellis, el proveedor que realizó la integración, publicó el caso. Su relato documenta un patrón operativo concreto: la ausencia de una autoridad compartida sobre precios y datos maestros trasladaba la coordinación diaria a las personas.

Cuando dos sistemas no comparten autoridad sobre un dato, las personas se convierten en la capa de integración.

El trabajo se completa. Por eso el problema puede durar años. Pero funciona porque alguien recuerda revisar, copiar, preguntar, esperar y corregir.

El coste de sistemas desconectados rara vez llega a contabilidad bajo ese nombre. Aparece repartido entre horas manuales, conciliación, retrabajo, errores operativos, pedidos retrasados, inventario inmovilizado y decisiones tomadas con cifras dudosas.

Primero se paga en trabajo duplicado. Ventas actualiza el CRM, finanzas vuelve a cargar el dato en el ERP y operaciones conserva una hoja propia porque necesita una vista que ninguno de los dos ofrece. Después llega la conciliación: comparar archivos, rastrear cambios y decidir cuál registro conservar.

Los errores viajan más lejos. Un precio incorrecto se convierte en una orden detenida; una unidad de medida mal definida, en espacio de almacén mal calculado; una reserva que no se libera, en inventario que parece disponible aunque ya no puede venderse. Allí aparecen el retrabajo, el tiempo de ciclo y el capital atrapado.

La dirección recibe el efecto final. Si ventas, inventario y finanzas reportan cifras distintas, una reunión ejecutiva termina discutiendo qué número es confiable antes de discutir qué decisión tomar.

IBM reunió en 2026 varias investigaciones sobre este problema. Según un estudio de IBM Institute for Business Value, 43% de los COO consultados consideró la calidad de datos su principal prioridad relacionada con datos.

Otra investigación citada por IBM encontró que más de una cuarta parte de las organizaciones encuestadas estimaba pérdidas superiores a USD 5 millones al año por mala calidad de datos; 7% reportaba USD 25 millones o más.

Estas cifras dimensionan una categoría más amplia: inconsistencias entre fuentes, datos faltantes, baja trazabilidad y decisiones basadas en información defectuosa. IBM señala, además, por qué el coste se subestima: sus efectos se distribuyen entre sistemas, equipos y periodos de tiempo. La causa nace en un registro; el gasto aparece después, en otra cuenta y bajo otro nombre.

La primera etapa de una integración ERP no es escribir una API.

Antes de elegir middleware, diseñar endpoints o reemplazar una plataforma, la organización debe resolver cuatro decisiones que la arquitectura luego hará cumplir.

Significado. ¿Qué quiere decir «disponible», «reservado», «despachado», «facturado» o «completado»? Dos áreas pueden usar la misma palabra para momentos distintos del proceso.

Autoridad. ¿Qué sistema puede crear o modificar cada dato? ¿Quién responde por su calidad? Declarar un sistema de registro ayuda poco si una hoja de cálculo sigue teniendo la última palabra cuando hay una excepción.

Secuencia. ¿Qué debe ocurrir antes de confirmar el siguiente paso? ¿Qué confirmación se espera? ¿Qué pasa si un evento llega tarde, dos veces o fuera de orden? La idempotencia, en lenguaje de negocio, empieza por decidir qué acciones pueden repetirse sin duplicar una venta, un cobro o un movimiento de inventario.

Excepción. ¿Cómo se detecta una divergencia, quién la recibe, cuánto puede esperar y cómo se reconcilia? Un proceso diseñado únicamente para el camino ideal termina delegando todos los casos reales a una bandeja, un chat o una persona que sabe cómo arreglarlo.

Estas decisiones pertenecen al modelo operativo: conectan responsabilidades, reglas, información y tecnología. La arquitectura les da forma técnica; no puede tomarlas en nombre de la empresa.

Hay una tentación comprensible cuando los sistemas no coinciden: comprar una herramienta de integración, sustituir el ERP o automatizar el paso manual. Las tres opciones pueden ser correctas. También pueden acelerar el problema.

Una API hará más rápido el movimiento de un dato ambiguo. Un ERP nuevo heredará definiciones que nadie depuró. Una automatización retirará a la persona que hoy detecta, aunque sea tarde, que dos valores no cuadran.

Por eso un diagnóstico operativo debe seguir el trabajo real, no solamente el diagrama oficial. ¿Dónde se vuelve a digitar información? ¿Qué conciliaciones se hacen antes de cerrar el mes? ¿Qué archivo aparece cuando un pedido se atasca? ¿Quién decide cuando el ERP y el CRM discrepan? ¿Qué ocurre con el cliente mientras llega esa respuesta?

Excel no es necesariamente el enemigo. A veces es la evidencia más honesta de una regla que el sistema nunca incorporó o de una responsabilidad que la organización no asignó. Eliminar la hoja sin entender la función que cumple puede borrar el síntoma visible y dejar intacta la causa.

La secuencia de trabajo debería ser: proceso, datos, responsabilidad, excepciones, arquitectura y, finalmente, API.

Ese orden no garantiza una integración sin fallos. Sí permite distinguir un problema de transporte de uno de significado, un error de configuración de una decisión ausente y una excepción técnica de una operación que nunca definió qué hacer.

Si hoy una persona mantiene alineados el ERP, el CRM, el WMS y una hoja de cálculo, la pregunta inicial no es cómo sacarla del proceso. Es qué decisión está tomando cada vez que los sistemas no coinciden.

Cuando dos sistemas no coinciden, ¿quién decide hoy cuál representa la realidad?