Integrando el sistema

 

Nada me preparó para integrar los sistemas de un gigante de los alimentos con los de un gigante de los autoservicios. Esto me llevaría después a donde pocos habían ido antes: a integrar sistemas en tiempos donde la técnica para eso apenas se estaba escribiendo. También me llevaría a un proyecto extremo donde los egos luchaban y los objetivos nos esquivaban.

En los inicios de la década de los 2000, trabajé como desarrollador de software para una de las cien mejores empresas de México, en el área de tecnología de información (TI). Un día en una reunión con del departamento de desarrollo, el gerente de TI nos habló de un proyecto que venía. Una de las grandes cadenas de autoservicios ya no iba a recibir notas de remisión (entrega) en papel, de lo contrario le cobraría al proveedor cien pesos por cada nota en papel que le fuera entregada. Por el contrario, había puesto a disposición un sistema para que le transmitieran electrónicamente esas notas.

“¿Quién quiere hacer este proyecto?”, preguntó. Cuando acordé, yo ya tenía la mano levantada. Fue casi un acto reflejo. El proyecto me resultaba emocionante y de impacto, así que yo quería hacerlo.

“Perfecto”, dijo complacido.

Inicia la aventura

Yo no sabía ni como le iba a hacer y no me importaba, estaba motivado por abordar algo tan interesante. En aquel entonces no había una serie de prácticas estándar para integrar sistemas. Los sistemas tipo ERP, como el que tenía implementado la empresa, eran la respuesta a la necesidad de integrar sistemas internos. Sin embargo, cuando la integración es hacia afuera de la empresa, no puedes exponer al sistema directamente al Internet para que salga a conectarse con otro.



Un ERP es un sistema que administra las funciones principales de una empresa, como el manejo de pedidos, la planeación y control de la producción, las ventas, la contabilidad, inventarios, etc. De modo que, si produces una caja de un artículo en el módulo de producción, este artículo genera costos de producción por ejemplo y se va a formar parte de tu inventario, tu contabilidad, y solo se capturó el dato una sola vez.

Para este requerimiento del autoservicio, los proveedores más pequeños podían optar por cargar una plantilla de Excel con la remisión en un sitio web. Nosotros éramos una empresa grande que hacía muchas entregas diariamente desde y hacia diferentes centros de distribución y almacenes, por lo que era inviable hacer esa carga a mano. Para estos casos, la cadena de autoservicio había creado un Web Service, que es un programa de computadora que vive en la web y que puede ser llamado por otros programas para enviarle o consultarle información.

Primero intercambié ideas con un colega que ha sido uno de mis grandes mentores. Él trabajaba en el área de operaciones de TI. Era un experto bastante vertical, conocía desde las redes de cómputo y las máquinas hasta el software. Me puso en el camino correcto. Usaría integración basada en mensajería como hacían algunos sistemas de integración comerciales de propósito general. Decidí que iba a usar colas persistentes, o sea una fila para formar los mensajes con las remisiones, pero estas filas iban a vivir en una base de datos, así si este sistema de integración se caía, la información no se iba a perder porque no vivía en la memoria.

El software de integración que creé consistía en dos procesos independientes. El primer proceso se conectaba al ERP para obtener las remisiones nuevas y luego ponía cada remisión en un mensaje virtual. Ese mensaje se depositaba en una fila de las que mencioné anteriormente. Una vez formada la remisión en la fila, el proceso se comunicaba con el ERP de nuevo para marcar esa remisión como ya leída y así no la volvería a tomar cuando corriese de nuevo.

El segundo proceso tomaba cada mensaje nuevo de la fila y se lo enviaba al Web Service del autoservicio. Si la respuesta era exitosa, el mensaje se marcaba como cerrado, si había un error, se marcaba como tal para ser reprocesado. Si el error había sido transitorio, como de conexión de red, por ejemplo, un siguiente intento usualmente resolvería las cosas, pero si el error era no transitorio, como por ejemplo datos con formato incorrecto, ninguna cantidad de intentos lo resolvería, por lo que cada mensaje tenía un máximo de intentos antes de expirar. Dejé para una versión posterior una mejora, para distinguir errores transitorios de los no transitorios y así dejar de reintentar estos últimos.

Creé una aplicación para monitorear estos procesos, ya que todo esto sucede sin necesidad de que exista una interfaz de usuario. En la aplicación monitor se podía ver información de cada mensaje, por ejemplo, su contenido, fecha y hora de creación, fecha de proceso, estatus, etc.

Después de un par de semanas de pruebas de concepto, programación y pruebas unitarias sólidas, comencé a probar la integración de extremo a extremo. Después de un tiempo adicional donde fui refinando y robusteciendo la integración, esta salió a producción exitosamente.

Cuando integras los sistemas de dos empresas, estas forman un tercer sistema virtual al que se le llama Sistema de Información Inter Organizacional (SIIO) porque lo que se envía desde un sistema, aparece en el otro de manera automática, se captura una sola vez en uno de los dos extremos y el otro lo recibe, minimizando el error humano. Estos sistemas al quedar integrados se comportan de alguna manera como si fueran uno solo.

Cada vez que hago una transferencia bancaria, una reservación, una compra en línea u ordeno una pizza, pienso en las integraciones que deben ocurrir detrás para que desde la app se cree un pedido en el sistema central y de ahí este llegue a la pizzería local para ser producido.

Pues la integración fue un éxito. Ese éxito me llevó a hacer otra integración, esta vez más pequeña y ahora entre los proveedores de la empresa y el ERP. En esta ocasión era la empresa la que necesitaba que los proveedores le enviaran las remisiones. Así que desarrollé un sitio web para que los proveedores capturaran ahí la información y luego usé el software de integración que había creado, para enviar los datos al ERP.

El gran proyecto

Al poco tiempo, un colega que estaba trabajando en un proyecto piloto para implementar un software comercial de producción en las plantas de la empresa me invitó, ya que necesitaban integrar este nuevo sistema con el ERP. Esto me llevó a estar durante meses con el equipo del proyecto en la ciudad donde se llevaba a cabo el piloto.

Este es uno de los proyectos más grandes en los que he participado y uno de los más retadores. Había muchas personas de diversas áreas y divisiones de la empresa, concentradas en una ciudad en el norte del país.

El proyecto me trajo muchos aprendizajes, entre ellos grandes lecciones administrativas y de colaboración. Nos mostró la mejor y la peor cara de muchos participantes en todos los niveles, desde la dirección de la empresa hasta los colaboradores que estábamos en sitio. También representó retos personales. A pesar de estar viajando de regreso a casa cada dos o tres semanas, llega un momento en que el trabajo prolongado de días largos y estresantes empieza a generar desgaste.

En retrospectiva, creo que el principal problema fue debido a un error fundamental, la empresa no involucró lo suficiente a la gerencia y a los liderazgos de la planta donde se llevaba el piloto. Por tanto, el proyecto no era visto con buenos ojos por el anfitrión, sino como un mal necesario.

Otro error fue la ausencia de líderes sólidos y presentes. Era un ambiente de mucha presión y la carencia de estos liderazgos permitió que escalaran los conflictos constantes entre colaboradores de la empresa, consultores y proveedores. Todos se pelearon con todos. Había altercados verbales, mofas no solo a espaldas sino también a la cara de otros, reclamos frontales y airados, así como intrigas. Un ambiente tóxico y lleno de incertidumbre. Ni una película del imperio romano llegó a tanto. Una pesadilla.

Las carencias de liderazgo desintegran. Había tribus, cada una siguiendo su propia agenda. Las juntas eran batallas para hacer señalamientos y encontrar culpables en lugar de soluciones.

Por todo esto, llegó un punto en donde el proyecto era un desastre seguro y se le apodaba “las tres carabelas”, aludiendo a las que vinieron con las expediciones del descubrimiento de América. Un grupo de condenados al fracaso. Se llegó incluso a rumorar que cuando querían desgastar a alguien para que dejara la empresa, se le asignaba a este proyecto. Lo cierto es que no dejaban de llegar con cierta frecuencia más integrantes provenientes de oficinas de todos los rincones del país, pero por razones legítimas.

Una noche, una colega se sintió muy triste cuando supo que no iba a poder regresar a casa el siguiente fin de semana para estar con sus hijos, después de varias semanas en sitio. Tuvo que tomarse un momento fuera de la sala de trabajo de la planta. Eso nos rompió el corazón.

Por nuestra parte, en el equipo de desarrollo de software, trabajábamos después del horario regular en el cuarto de guerra de la planta, en una sala de juntas del hotel, como de nueve o diez de la noche hasta altas horas de la madrugada, prácticamente todos los días. También trabajábamos sábados y domingos, aunque en un horario más amable. Éramos el equipo que más trabajaba. En los fines de semana, desde la sala de juntas del hotel, veíamos como pasaban integrantes de otros equipos saliendo hacia una playa cercana. Meses después, cuando por fin pude dormir cinco horas, se me hizo que había descansado demasiado bien.

Eran tales los cambios de dirección diaria que enfrentábamos en el equipo de desarrollo, que se generaba un círculo vicioso: un software con un ritmo de modificaciones diario y por tanto inmaduro, que generaba a su vez errores y por tanto correcciones, más los cambios que se nos iban solicitando.

En un punto, el director general de la empresa ordenó una revisión de expedientes y de evaluación de la capacidad de todos y cada uno de los colaboradores que trabajábamos en el proyecto, para ver si éramos aptos. El disgusto que generó esto, no ayudó nada por supuesto, solo vino a sumarse a la baja moral que ya predominaba.

Invité a mis colegas de TI a dar lo mejor por nosotros y por el equipo, no por nadie más. “Aquí es donde vemos de qué estamos hechos”, les dije.

Cuando empecé a trabajar en aquella empresa, así como en ese proyecto, por ningún lado en mis aspiraciones apareció jamás el director general, solo mi realización profesional.

Después de varios cambios de gerente, de una pausa de meses y de un reinicio acompañado de otras reestructuras y rediseños, el proyecto se concluyó exitosamente.

Un desarrollador del ERP quien programaba en un lenguaje propietario y anquilosado me preguntó: “Esta herramienta que hiciste, fue algo no convencional para integrar sistemas ¿no?”. Por lo visto pensaba que yo había recurrido a una solución “creativa”. Nada más lejos de la realidad. Si bien, como dije, no había mejores prácticas, la técnica usada era coherente. En aquella época pocos, aún dentro de TI, comprendían lo que estaba haciendo.

Cambio de aires

Al poco tiempo dejé la empresa para irme a una multinacional de servicios de tecnologías de la información que trabajaba con las grandes marcas del mundo.

Por nada cambiaría lo vivido en el proyecto de la empresa que dejé. Los aprendizajes, las personas, todo lo adquirido ha sido valioso en lo profesional y en lo personal.

Al poco tiempo, el director y cofundador de la empresa proveedora que hizo el software de producción, me contactó por Facebook para invitarme a trabajar. Fue durante el apogeo de aquella red social, donde los amigos de la infancia se reencontraban y los conocidos recientes se mantenían en contacto.

“Necesitamos a alguien que sepa como integrar ERPs con nuestros productos y pensé en ti”, me dijo.

Tuvimos una serie de conversaciones sobre la oferta laboral y finalmente me fui a esa empresa. Ahí, en colaboración con varias personas, desarrollamos una plataforma de integración y trabajé liderando proyectos de este tipo para muchos clientes de la empresa alrededor del mundo, durante una década, lo que me llevó por varios rincones del planeta.

Para entonces ya existía un libro que es canon de los patrones de integración de sistemas y en el que había estado basándome. El tiempo nos dio la razón en cuanto al diseño a mi mentor y a mí.


El año pasado, la exempresa nos requirió para un proyecto de actualización de sus integraciones. Hace tiempo deje el desarrollo de software, así que era poco probable que estuviera ahí, sin embargo, los altos mandos me requirieron como uno de los administradores de ese proyecto. Bueno, vayamos por la segunda vuelta, me dije.

Imagen: Pete Linforth