Pregúntale a un arquitecto de sistemas de una empresa con muchos años de SAP dónde están los puntos frágiles y la respuesta llega rápido: la interfaz que falla la víspera del cierre contable, el archivo que alguien corrige a mano antes de reenviarlo, el sistema de planta que nadie quiere actualizar por miedo a romper todo lo demás. TI suele ser el área que mejor entiende el problema de integración y la que menos margen tiene para resolverlo.
En la mayoría de los casos no falta talento. Falta plataforma. Cada hora dedicada a sostener conexiones frágiles es una hora que no llega a los proyectos que pide el negocio. En este artículo verás cómo se forma esa deuda, por qué no aparece en el presupuesto y qué cambia cuando SAP BTP pasa a ocupar el centro de la arquitectura. Si prefieres empezar por la visión general de la plataforma, lee qué es SAP BTP.
Cómo crece la red de integraciones sin que nadie la diseñe
Ninguna empresa planea tener decenas de integraciones punto a punto. Llegan de una en una: el CRM necesita datos de clientes, el operador logístico necesita recibir pedidos, el banco necesita archivos de pago, la planta necesita reportar la producción. Cada conexión resuelve el problema de ese momento con la tecnología y las personas de ese momento. Años después, el resultado es una maraña que nadie diseñó como un todo y que tiene cuatro rasgos conocidos:
- Frágil: un cambio de versión, de campo o de certificado interrumpe flujos que nadie sabía que dependían de ese punto.
- Opaca: no existe una visión de extremo a extremo de por dónde viajan los datos, y diagnosticar un error empieza por averiguar qué interfaz falló.
- Costosa de mantener: cada conexión tiene su propia lógica, su propio manejo de errores y, muchas veces, una sola persona que la conoce.
- Difícil de escalar: una nueva filial, un nuevo canal o un nuevo socio exigen otra conexión hecha a medida.
Los sistemas legados sin APIs modernas agravan el cuadro. Siguen en operación porque reemplazarlos es demasiado arriesgado, y cada integración con ellos se convierte en una excepción a la regla.
Por qué la deuda de integración no aparece en el presupuesto
La deuda técnica rara vez tiene una línea propia en el presupuesto de TI. Se diluye en horas de desarrollo dedicadas a incidentes, en proyectos que se retrasan porque el equipo tuvo que apagar incendios y en pruebas que se alargan porque nadie sabe con certeza qué puede afectar un cambio.
Además está el costo más difícil de medir: lo que la empresa deja de hacer. Cuando buena parte del tiempo del equipo se va en mantener lo que ya existe, las nuevas demandas hacen fila y TI termina vista como un cuello de botella, cuando en realidad carga con una arquitectura que ya no acompaña a la operación. Para llevar esta conversación a la dirección, conviene convertir lo invisible en indicadores:
- Incidentes por interfaz y tiempo medio hasta el diagnóstico
- Horas de soporte frente a horas dedicadas a proyectos nuevos
- Proyectos postergados o replanificados por dependencias de integración
- Integraciones que solo una persona sabe mantener
Un hub gobernado en lugar de decenas de conexiones aisladas
SAP BTP le propone a TI dejar de gestionar conexiones aisladas para gestionar un ecosistema conectado. El papel central lo asume SAP Integration Suite, el servicio de integración de la plataforma: los flujos entre sistemas SAP y no SAP pasan por un único punto de control, con reglas de gobierno definidas por la propia TI.
En el día a día, el equipo cuenta con una consola de monitorización con el estado de cada flujo, alertas automáticas cuando algo falla, con la trazabilidad necesaria para ubicar el mensaje, el paso y la causa, y conectores preconstruidos para aplicaciones SAP y sistemas de terceros. Las nuevas integraciones se suman sin rediseñar las que ya están en producción.
La ganancia se acumula con la reutilización. Cuando conectores, mapeos y manejo de errores siguen un estándar, cada nueva integración parte de algo que ya funciona y los plazos tienden a bajar proyecto tras proyecto. La documentación deja de vivir en la cabeza de alguien y pasa a formar parte de la plataforma.
Legado y clean core: modernizar sin tocar lo que funciona
No todo sistema legado puede, o debe, reemplazarse ahora. Con adaptadores estándar, los datos y las funciones de esos sistemas se exponen como APIs modernas mientras la aplicación legada sigue operando tal como está. El resto de la arquitectura habla con una API documentada y no con un formato propietario que solo entendía el proveedor original.
La misma lógica vale para los desarrollos a medida. El entorno de desarrollo y el modelo de extensibilidad de SAP BTP permiten crear aplicaciones, reglas y flujos de trabajo junto al ERP, no dentro de él. Es el principio de clean core: la lógica a medida queda fuera del núcleo, el sistema de registro se mantiene estable y auditable, y cada actualización resulta más sencilla y menos arriesgada.
Dónde se nota primero el impacto
Un sistema de planta sin APIs, integrado sin migración
En un caso reportado por Grupo Intelsis, un sistema de manufactura con 15 años de uso y sin APIs nativas se conectó mediante un adaptador estándar. Los datos de producción empezaron a llegar al ERP y a los tableros de gestión en tiempo real, sin riesgo para el sistema legado y sin un proyecto de reemplazo.
Aprobaciones que salen del correo
En otro caso reportado por Grupo Intelsis, un grupo empresarial gestionaba las aprobaciones de compras, viajes e inversiones de capital por correo electrónico, llamadas telefónicas y consultas manuales en SAP. Los procesos pasaron a flujos digitales con reglas, notificaciones y trazabilidad. El primer flujo estuvo listo en 5 semanas; cada uno de los siguientes tomó de 2 a 3 semanas, porque reutilizó los patrones del primero.
APIs para el ecosistema de socios
Un tercer caso reportado por Grupo Intelsis es el de un distribuidor que empezó a ofrecer a sus distribuidores asociados consultas de stock, estado de pedidos y condiciones comerciales directamente desde SAP. Los servicios se expusieron mediante la capa de gestión de APIs de SAP BTP, con control de acceso, límites de consumo y monitorización. Incorporar a un nuevo socio pasó de tomar semanas a tomar horas.
Del soporte a la arquitectura: qué cambia para el equipo
El primer cambio es el control. Con cada flujo visible en tiempo real, los incidentes se detectan antes de que llamen los usuarios, y la deuda baja de forma gradual: cada conexión punto a punto que pasa al hub queda documentada y monitorizada. Escalar ya no significa construir desde cero, porque una nueva filial, un nuevo canal o un nuevo socio reutilizan conectores y patrones existentes.
El segundo cambio está en el tipo de trabajo. Menos horas apagando incendios liberan al equipo para la arquitectura y para lo que piden las áreas de negocio: un cierre contable más rápido y consistente para finanzas, ERP, CRM y logística conectados para el área comercial, y una operación que acompaña el crecimiento. La diferencia rara vez está en tener un equipo más grande o más presupuesto. Está en trabajar sobre la plataforma adecuada.
Miremos juntos tu arquitectura
Si tu equipo dedica más tiempo a sostener integraciones que a entregar proyectos, una sesión técnica breve suele bastar para mapear los puntos críticos y diseñar un primer paso realista. Grupo Intelsis es SAP Gold Partner y combina arquitectura en SAP BTP con la operación de entornos SAP, incluidos Basis y hosting. Si tiene sentido para ti, conversa con nuestro equipo.