El problema nunca fue conectar los sistemas entre sí
Pregunte a cualquiera que haya dirigido un proyecto de integración y le describirá la misma frustración. En la superficie parece técnico, pero en el fondo, rara vez lo es.
«Nunca fue la tecnología», afirma Caspar, CEO de Alumio. «Siempre fueron las personas dentro de la organización. El responsable de TI que no quería abrir las puertas o que no tenía una visión clara de cómo encajaba todo».
La fontanería en sí solía ser rutinaria. A menudo se vendía la idea de que los sistemas heredados eran difíciles de conectar, pero la realidad era más sencilla. «El software antiguo se vendía como si conectarse a él fuera increíblemente difícil», dice Caspar. «Casi siempre se reducía a lo mismo: un archivo en un servidor o una conexión SOAP. Y yo pensaba: alguien ha hecho esto mucho más complicado de lo necesario».
Si el trabajo técnico era manejable, la dificultad residía en otro lugar. Residía en la organización y en lo que ocurría después de que la integración entrara en funcionamiento.
Cómo es realmente la dependencia de la integración
Cuando una empresa construye una integración a medida, no solo obtiene una integración funcional. Hereda una serie de dependencias que rara vez tiene en cuenta en ese momento.
La primera es la dependencia del desarrollador. La lógica reside en la cabeza de un solo programador o en un código que solo él entiende. Cuando se marcha, el conocimiento se va con él. Esto se conoce a menudo como riesgo de dependencia del personal clave: el peligro de que el conocimiento crítico resida en una sola persona. Caspar lo ha visto más de una vez en empresas medianas. «Tenían todo construido por una sola persona, y esa persona se fue». Los sistemas siguieron funcionando, pero nadie dentro de la empresa los entendía ya.
La segunda es la dependencia entre los propios sistemas. Las conexiones punto a punto se enredan con el tiempo hasta que un sistema no puede ser reemplazado sin romper los demás. Cambiar un ERP deja de ser un proyecto para convertirse en un riesgo que nadie quiere asumir.
La tercera es la dependencia del pasado. Como el cambio parece peligroso, las empresas siguen utilizando una arquitectura que ya se les ha quedado pequeña. «Las empresas no se preguntaban cómo sentar unas bases sobre las que pudieran construir año tras año», dice Caspar. «Simplemente lo reconstruían, y luego lo volvían a reconstruir unos años después».
La factura llega más tarde, y no es solo dinero
El coste de la dependencia de la integración es fácil de ignorar porque no aparece como una partida específica. Surge lentamente, de formas difíciles de rastrear hasta su origen.
Caspar describe conexiones de gestión de almacenes que fallan cada pocas semanas y permanecen inactivas durante una hora o más cada vez. Equipos enteros no pueden trabajar hasta que vuelven a funcionar. Lo que destaca no es la interrupción, sino que la empresa ha llegado a tratarla como algo normal. El alojamiento aparece en una vaga factura de la nube. El tiempo de inactividad se traduce en horas perdidas. Ninguna de las dos cosas se etiqueta como «dependencia», pero ambas son reales.
Por eso la conversación ha ido más allá de TI. Los inversores y compradores hacen una serie de preguntas diferentes. ¿Quién puede mantener esto si el equipo actual se marcha? ¿Qué está realmente documentado? ¿Cuánto le costaría a un comprador hacerse cargo de esto? La arquitectura de integración se ha convertido en parte de la diligencia debida, y el trabajo a medida no documentado es una de las cosas que se señalan. La consecuencia práctica es que profesionalizar la capa de integración ya no es solo una mejora de TI. Es parte de hacer que una empresa sea transferible, y arrastra al propietario y al director financiero a una discusión que antes pertenecía solo a TI. Las mismas preguntas surgen desde el otro lado de la mesa durante la integración posterior a la fusión.
Pero el costo más profundo es el tiempo. “En realidad, solo hay un enemigo para cualquier empresa, y es el tiempo”, afirma Caspar. “Si el dinero no es la limitación, la situación se vuelve más peligrosa, porque la gente acepta que las cosas tarden más de lo necesario”. Una empresa que no puede moverse a la velocidad de su mercado tiene un problema grave, y la dependencia es lo que la ralentiza.
Eliminar las dependencias que generan las integraciones personalizadas
La respuesta no es crear mejores integraciones personalizadas. Es evitar, desde el principio, las dependencias que estas generan. Eso significa cambiar dónde reside la lógica de integración, no qué tan bien esté escrita.
Aquí es donde una plataforma de integración como servicio (iPaaS) cambia el panorama. Alumio iPaaS es una solución nativa en la nube, basada en configuración que conecta los sistemas empresariales a través de una capa central, en lugar de utilizar enlaces personalizados únicos entre cada par de sistemas. Cada conexión se establece mediante ajustes estructurados en lugar de escribirse desde cero. Esto funciona con un conector preconfigurado cuando existe, y con la propia API del sistema cuando no es así. Alumio también ofrece un transformador de código para los desarrolladores que prefieran resolver un caso excepcional mediante programación. El punto no es que la plataforma conecte las cosas con mayor elegancia, sino lo que permite eliminar.
Al implementar esa capa de integración central, la lógica de cada conexión reside en un lugar visible y gobernado, en lugar de estar solo en la cabeza de un desarrollador. Cuando se realiza un pedido en la tienda online, este se dirige al ERP, actualiza el inventario y activa el proceso de cumplimiento. La empresa puede ver y modificar ese flujo sin depender de quien lo haya creado originalmente. Se puede reemplazar un sistema sin que los demás colapsen. El conocimiento permanece en la organización.
Hay un compromiso que vale la pena aclarar. Adoptar una plataforma implica estandarizar, y estandarizar significa renunciar a parte de la libertad a medida que ofrecen los desarrollos personalizados. Para las empresas convencidas de que sus procesos son totalmente únicos, esto puede parecer una limitación. En la práctica, es todo lo contrario: es lo que les permite cambiar un sistema sin tener que renegociar toda su arquitectura.
Por qué la dependencia es ahora una cuestión estratégica
Nada de esto es estático. El mismo patrón que comenzó extrayendo la lógica del código sigue evolucionando. Caspar ha observado cómo el terreno ha cambiado bajo este problema desde que fundó Alumio, y su lectura es que sigue moviéndose en la misma dirección.
“Fundamos Alumio para sacar la tecnología del código”, dice Caspar. “Ahora la tecnología ya no está en el código; está en una capa visual. El siguiente paso es que la capa visual importe cada vez menos. Se convierte en una cuestión de negocio”. La infraestructura técnica pasa a un segundo plano y la decisión estratégica cobra protagonismo.
La IA es donde esto se vuelve concreto. La promesa es que los modelos y agentes actuarán sobre los datos empresariales: responderán preguntas sobre existencias, activarán un nuevo pedido, conciliarán una factura o prepararán un informe. Eso solo funciona si los datos subyacentes están completos, actualizados y cuentan con los permisos necesarios, y si existe un registro de qué se movió, a dónde y por qué.
Una organización cuya lógica de integración reside solo en la cabeza de un desarrollador no puede dar a un sistema de IA acceso fiable a sus propias operaciones. Tampoco puede auditar posteriormente lo que ese sistema hizo realmente. La IA no elimina la dependencia de la integración; aumenta su precio. Las empresas que obtendrán un valor real de la IA son aquellas que hicieron que sus flujos de datos fueran visibles y gobernados antes de necesitarlo. Una capa de integración gobernada es ahora un cimiento, no una comodidad.
Las empresas que ven esto con antelación ganan margen de maniobra. Pueden adoptar nuevos sistemas, responder al mercado y poner sus datos a trabajar sin tener que reconstruir los cimientos cada vez. Aquellas que siguen reconstruyendo integraciones personalizadas heredan la misma dependencia de integración que sus predecesoras y la pagan con la única moneda que ninguna empresa recupera. Desmantelarla más tarde implica pasar por una migración de sistemas heredados.
Dónde reside hoy su lógica de integración
El cambio en la forma en que las empresas conectan sus sistemas se reduce a una sola modificación en lo que intentan adquirir. Durante años, el objetivo fue lograr una conexión funcional. Ahora, el objetivo es la libertad de cambiar sin tener que pedir permiso al pasado. No son lo mismo. La diferencia radica en la dependencia en sí misma. Reside en el desarrollador que posee el conocimiento, en los sistemas tan entrelazados que es imposible separarlos y en decisiones tomadas hace años que nadie se atreve a cuestionar.
Ninguna de esas dependencias se anuncia a sí misma. Permanecen en silencio dentro de un entorno que sigue funcionando. Entonces, una persona clave se marcha, un inversor hace una pregunta difícil o un cambio en el mercado exige una adaptación que la arquitectura no puede absorber. Para entonces, el coste ya no es teórico. En ese punto, la diferencia es evidente: una empresa que ha hecho visible y gestionable su lógica de integración puede avanzar; una que no lo ha hecho, solo puede observar.
El punto de partida práctico es más sencillo de lo que parece. Identifique dónde reside realmente su lógica de integración y pregúntese quién podría modificarla mañana si la persona que la creó ya no estuviera. Esa simple pregunta saca a la luz la dependencia que la mayoría de las empresas han dejado de notar y convierte un riesgo invisible en algo sobre lo que se puede actuar. Eliminarla no requiere desmantelar todo de golpe. Requiere decidir, deliberadamente, que la próxima conexión que cree no será una pieza más que solo una persona comprende.
La integración nunca fue la parte difícil. Lo difícil es lo que queda después. Las empresas que actúan en consecuencia ahora son las que podrán seguir avanzando cuando realmente importe.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
