Cómo calcular el coste de una integración entre sistemas

El primer factor es el punto de entrada y salida de cada sistema. Una interfaz de programación documentada, con entorno de pruebas y versiones estables, reduce mucho la incertidumbre. Cuando solo existe un intercambio de ficheros, acceso directo a base de datos o, en el peor caso, nada en absoluto, hay que construir más y probar más.

Cada entidad que viaja (cliente, artículo, pedido, albarán, factura, existencias) es un flujo con sus propias reglas. Dentro de cada entidad, lo que cuesta no es copiar un campo, sino transformarlo: unidades de medida distintas, códigos de impuestos que no coinciden, direcciones que en un sistema son un campo y en otro cinco, estados de pedido que no tienen equivalencia directa.

• Número de entidades y sentido de cada flujo: unidireccional o bidireccional.
• Campos por entidad y cuántos requieren transformación, no solo copia.
• Tablas de equivalencia que alguien debe mantener: familias, tarifas, almacenes, formas de pago.
• Reglas de conflicto cuando el mismo dato se edita en ambos lados.
• Datos históricos: si hay que migrar lo anterior o solo sincronizar desde una fecha.

Un flujo bidireccional suele costar bastante más que dos unidireccionales, porque obliga a detectar quién cambió qué y a resolver colisiones. Si podéis definir un único sistema maestro por dato, la integración se simplifica.

Sincronizar unas decenas de pedidos al día no se diseña igual que procesar miles de movimientos de stock por hora. El volumen condiciona si basta con una tarea programada, si hace falta una cola de mensajes o si hay que paginar y controlar límites de llamadas del sistema de destino.

• Volumen normal y volumen en picos: campañas, cierres de mes, inventarios.
• Latencia aceptable: ¿basta con cada hora o el dato debe llegar en segundos?
• Carga inicial: la primera sincronización de un catálogo completo puede requerir un procedimiento propio.
• Ventanas en las que el sistema de destino no está disponible por mantenimiento.

Una integración que funciona cuando todo va bien se construye pronto. Lo que lleva tiempo es decidir qué ocurre cuando algo falla, y esa parte es la que evita incidencias a final de mes. Una buena estimación dedica un capítulo propio a la gestión de errores.

• Reintentos automáticos ante caídas temporales, con límites para no saturar el destino.
• Idempotencia: que reenviar el mismo mensaje no cree un pedido duplicado.
• Cola de errores revisable por una persona, con el motivo legible y la opción de reprocesar.
• Validaciones previas: rechazar un artículo sin código fiscal antes de que llegue a la contabilidad.
• Avisos a la persona responsable cuando un flujo lleva tiempo sin moverse.
• Registro de lo enviado y recibido para poder responder a «¿esta factura salió?».

Toda integración abre una puerta entre sistemas. Hay que decidir cómo se autentica cada parte, dónde se guardan las credenciales, qué permisos mínimos necesita la cuenta técnica y si los datos viajan cifrados. Si se mueven datos personales, también qué campos son estrictamente necesarios y dónde se alojan. El proyecto OWASP API Security Top 10 recoge riesgos habituales de las interfaces de programación, como la autorización deficiente a nivel de objeto, y es una buena lista de comprobación para revisar el diseño.

• Cuentas técnicas con permisos limitados a lo que la integración necesita.
• Credenciales en un almacén de secretos, no en ficheros de configuración compartidos.
• Cifrado en tránsito y control de qué registros conservan datos personales y durante cuánto tiempo.
• Rotación de credenciales y revocación si cambia el proveedor que mantiene la integración.

Los sistemas conectados cambian: el fabricante publica una versión nueva de su interfaz, se añade un almacén, se crea una forma de pago o cambia una normativa de facturación. Cada cambio puede afectar a la integración. Conviene presupuestar desde el principio una atención continuada: supervisión de la cola de errores, actualización de dependencias, adaptación a versiones y pequeñas evoluciones.

Una integración bien documentada, con pruebas automáticas de los flujos principales y un panel de estado, cuesta algo más al construirla y bastante menos al mantenerla.

1. Haz el inventario de flujos: entidad, origen, destino, sentido, frecuencia y volumen.
2. Para cada flujo, anota el mecanismo de interfaz disponible en ambos extremos.
3. Cuenta los campos que requieren transformación y las tablas de equivalencia necesarias.
4. Describe las reglas de error: qué se reintenta, qué se rechaza y quién revisa.
5. Añade seguridad, entornos de prueba, carga inicial y documentación como partidas separadas.
6. Estima el mantenimiento anual aparte del desarrollo inicial.
7. Empieza por el flujo de más valor y menos incertidumbre como primera entrega, y recalcula con lo aprendido.

Ejemplo ilustrativo: una empresa quiere pasar pedidos de su tienda online al ERP y devolver existencias y estados de envío. Son tres flujos. Si el ERP ofrece interfaz documentada y la tienda también, el peso estará en las equivalencias de impuestos y portes, y en evitar pedidos duplicados. Si el ERP solo admite ficheros, habrá que añadir control de ficheros parciales y una cola de revisión. El número de flujos es el mismo; el esfuerzo, no.

• ¿La propuesta enumera los flujos y campos, o solo habla de «conectar» sistemas?
• ¿Explica cómo se gestionan errores, duplicados y reprocesos?
• ¿Separa el desarrollo inicial del mantenimiento y los cambios de versión?
• ¿Indica qué supuestos se han hecho sobre las interfaces y qué ocurre si no se cumplen?
• ¿Incluye documentación, pruebas y un modo de supervisar el estado de la integración?

Una propuesta más barata que deja fuera la gestión de errores no es más barata: traslada ese coste a vuestro equipo en forma de correcciones manuales.