Las integraciones que nadie cotizó: por qué tu ERP se va a sobrecosto

La pregunta que nadie hace en la junta

Preguntá a tu CFO cuánto costó la implementación del ERP. Después preguntá cuánto costaron las integraciones que aparecieron después. La primera cifra está en un contrato. La segunda, casi siempre, está dispersa en órdenes de cambio que nadie sumó.

Ese es el hueco. El sobrecosto de un ERP rara vez nace en la ejecución: nace en el contrato que se firmó antes de que alguien preguntara qué sistemas tienen que hablar entre sí, quién construye cada interfaz y quién la sostiene cuando el proyecto termina.

El dato que confirma el patrón

La firma de consultoría Panorama Consulting Group publicó el 28 de septiembre de 2026 un análisis sobre las declaraciones de trabajo (SOW) de proyectos ERP que pone nombre al problema. Su 2026 ERP Report encuentra que más de un cuarto de las organizaciones superó su presupuesto de proyecto, y que la causa principal citada es "necesidades adicionales de tecnología".

Vale ser preciso con ese número: es un dato sobre presupuesto total, no una estadística sobre integraciones en particular. Pero la explicación de la firma apunta directo a las costuras entre sistemas. Un SOW puede nombrar los sistemas que deben conectarse a la plataforma nueva sin especificar quién construye cada interfaz ni quién la soporta después de la salida a producción. Y el costo de esa ambigüedad, dice, tiende a aparecer durante las pruebas.

Las integraciones y la conversión de datos son, según ese análisis, las áreas con más probabilidad de interrumpir la operación cuando la responsabilidad no está clara. Y deja una frase que cualquier director de TI debería tatuarse: todo lo que el contrato deja indefinido se cotiza después, a la tarifa del proveedor y en el calendario del proveedor.

Por qué el CTO es quien paga la cuenta

El SOW es un documento técnico. Por eso se manda a TI "para que lo revise". El problema es que esa revisión rara vez mide lo que importa: no si la lista de sistemas conectados está completa, sino si cada interfaz tiene dueño de construcción y dueño de soporte.

Hay una razón estructural. El equipo de TI revisa el SOW contra cómo cree que funciona la empresa, no contra cómo funciona de verdad. Cómo se mueve un pedido entre el e-commerce y el ERP, qué regla aplica el POS cuando la pasarela de pago responde tarde, qué dato del sistema legacy nadie documentó nunca. Todo eso vive en la memoria de las personas, no en el contrato.

Cuando el proyecto avanza, la interfaz que nadie cotizó tiene que construirse igual. Y ahí aparece la orden de cambio: más costosa, más lenta, y con la empresa en la posición más débil para negociar, porque ya firmó y ya empezó.

Qué es una integración bien cotizada

La diferencia no es pagar más al inicio. Es sacar la ambigüedad del contrato. En términos accionables, una integración bien cotizada cumple cinco condiciones:

1. Interfaz por interfaz, con nombre y apellido. No "integración con el CRM", sino qué dato viaja, en qué dirección y con qué frecuencia.
2. Dos dueños por cada interfaz. Quién la construye y quién la soporta después de la salida a producción. Si el soporte no tiene dueño, no está cotizado.
3. El dato de origen sucio como partida propia. Si el sistema viejo exporta datos inconsistentes, limpiarlos es un paquete presupuestado, no un "detalle de implementación".
4. Límites de fase con rango de precio. Qué entra en la fase uno, qué queda para después y cuánto costaría cada borde. Sin eso, el alcance se expande sin control.
5. Responsabilidades del cliente por escrito. Qué tiene que poner la empresa (accesos, gente, decisiones) y qué pasa si se atrasa.

Ninguna de estas cinco cosas es exótica. Todas caben en un SOW. El problema es que casi ninguna llega a estar ahí, porque el documento se escribe para cerrar la venta, no para sobrevivir a la operación.

El costo no termina en el go-live

Una integración mal definida es el inicio de una deuda que se paga todos los meses. Lo que quedó mal conectado hay que mantenerlo, alguien tiene que entenderlo cada vez que se rompe, y la lógica de negocio queda viviendo en la cabeza de quien la escribió. Ahí es donde el sobrecosto del ERP se convierte en costo operativo permanente.

Por eso la conversación no es "cómo ahorramos en la implementación", sino "cómo cerramos el hueco antes de firmar". En una empresa de 50 a 500 empleados en LatAm no hay dato regional específico que citar, y no vamos a inventarlo. Hay, en cambio, una analogía razonable: la misma ambigüedad que la firma identifica globalmente golpea más fuerte donde el equipo interno ya está al tope de su capacidad y no puede absorber integraciones no planificadas.

Ese es exactamente el trabajo que Byxel firma bajo su modelo de Ingeniería de Autor: entrar a definir qué interfaces existen, quién responde por cada una y qué costaría cerrarlas bien desde el inicio, en vez de aprender sobre el presupuesto del cliente.

Para seguir leyendo: por qué mantener las integraciones a mano cuesta todos los meses y por qué la autoría con revisión senior importa.

¿Estás revisando un SOW con integraciones sin dueño claro, o ya pagaste una que nadie cotizó? Escribinos por WhatsApp y en una llamada revisamos qué interfaces quedaron fuera del contrato y cuánto costaría cerrarlas bien desde el inicio.