El corazón tecnológico de cualquier empresa es su ”sistema core”. Sobre este sistema funcionan los procesos críticos de la operación. Por lo general son sistemas de legado, que llevan años, si no décadas, funcionando. En un banco el core es el sistema transaccional. En una empresa de retail es el de inventarios. En una telco son los sistemas de billing. En un aerolínea es el sistema de reservas, etc….
Muchas empresas sueñan con cambiar su sistema core para aprovechar las oportunidades que ofrece la tecnología moderna. Pero pocas empresas se atreven a hacerlo. Hay muchos años invertidos en desarrollos e integraciones sobre estos sistemas. El riesgo de dañar lo que funciona bien es muy alto y no hay certeza de que lo nuevo vaya a funcionar perfectamente.
En el entretanto se genera una discusión profunda entre negocio e IT, que va escalando rápidamente. Para competir exitosamente, el negocio necesita desplegar nuevos productos y funcionalidades que se soportan sobre el sistema core de la empresa. Pero IT tiene problemas para responder a la velocidad que requiere el negocio. En algunos casos el requerimiento es prácticamente imposible de implementar. En otros, hacerlo toma demasiado tiempo y se pierden oportunidades de negocio.
Hay una solución tecnológica que resuelve (en parte) el problema
A la luz de la necesidad, las grandes casas de software han diseñado una solución a este problema. Se trata de la “capa media” o “bus de integración”. La capa media simplifica la conexión con el core. Una analogía para entender como funciona un bus de integración es un sistema universal de conectores. Este sistema se conecta una sola vez a la pared, pero es posible conectarle diferentes tipos de enchufe. De patas redondas, planas, de 2 o 3 patas, etc….
La idea tecnológica es desacoplar las integraciones realizadas sobre el sistema core y llevarlas a este nuevo sistema. Con la configuración correcta, se puede pasar a una arquitectura basada en servicios que genera muchísima flexibilidad tecnológica. Obviamente estos sistemas son costosos y complejos de implementar. Pero son una salida viable al problema tecnológico. No obstante, como casi todo lo que sucede en tecnología empresarial, el problema no es necesariamente tecnológico.
Metodologías ágiles
No importa si se desarrolla sobre el sistema core o sobre la capa media, el problema subyacente sigue existiendo. Es complejo desarrollar nuevas funcionalidades sobre uno u otro sistema. Las demoras e imposibilidades siguen existiendo. Hay también un problema de priorización. Requerimientos de todo tipo empiezan a acumularse sobre IT.
Todo esto hace que sea necesario cambiar el modelo sobre el cual opera la relación entre negocio e IT. En el pasado la relación operaba sobre el método “cascada”. Bajo este principio, el negocio genera el requerimiento, e IT trabaja en un solo envión hasta que tiene todo completo. En ese momento, la probabilidad dice que el resultado no será exactamente lo que el negocio esperaba. Pero es difícil echarse para atrás, ya hay inversiones y trabajo invertido en la solución. Así que nadie queda contento con el resultado.
Por fortuna existen los métodos ágiles. Bajo el principio de agilidad es posible ir construyendo, y probando, el requerimiento en sucesivas iteraciones. Esto evita que se terminen invirtiendo grandes recursos en desarrollos que no van en camino de satisfacer al cliente.
Muchas empresas están probando kanban o scrum para implementar métodos ágiles. Algunas exitosamente. La mayoría con problemas. El secreto del éxito en realidad no está en el método, cualquiera de los dos sirve perfectamente. Pero hay que cambiar la expectativa de quien solicita el requerimiento.
MVPs – Productos Mínimos Viables
Las metodologías ágiles funcionan muy bien cuando se combinan con principios lean. El requerimiento o funcionalidad esperada debe ser viable desde las primeras iteraciones. Es decir que el objetivo final debe ser posible, con ciertas concesiones, desde las fases iniciales del desarrollo. De lo contrario se convierte en una forma disfrazada del método cascada, y por ende genera la misma frustración y problemas de ese método. Este es, en mi experiencia, el error mas común de quienes implementan métodos ágiles.
Como decía, los requerimientos deben ser viables desde muy temprano en el ciclo. Viable significa que el producto puede ser usado por el cliente y entrega su valor, aunque lo haga con ciertas concesiones. Un sistema transaccional debe permitir hacer la transacción completa, aunque su interfaz no sea la adecuada. Un sistema de inventarios debe llevar el inventario, aunque no tenga todo el detalle necesario. Las iteraciones se usan para ir puliendo el producto final, incluyendo solo aquellas características que son críticas para la satisfacción del usuario.
Obviamente, usar métodos ágiles exige que el diálogo entre negocio e IT sea radicalmente diferente. No es únicamente la frecuencia de la interacción. También el contenido es importante. La labor de especificación y priorización toma prioridad en el proceso. En las organizaciones en donde el negocio solo le pasa la pelota a IT y se olvida del requerimiento, el método está condenado a fallar. Nunca es un problema solo de IT. El problema en realidad reside en quien requiere. IT es solo un habilitador/ejecutor.
Ágil es una obligación de una transformación digital,
No me canso de decirlo. Quien debe liderar la transformación digital debe estar mas del lado del negocio que del lado tecnológico. Recordemos que el esfuerzo de transformación lleva a eliminar la fricción entre cliente y compra, con la ayuda de la tecnología. Quien requiere es el cliente o mejor, su representante interno en la organización, que en mi mundo se llama mercadeo o su equivalente.
Con los requerimientos de mercadeo muy bien especificados, IT puede desarrollar su labor. Las sucesivas iteraciones llevan a que el cliente final reciba el valor esperado desde las etapas muy tempranas del esfuerzo. De manera transparente para el cliente, al interior de la organización existirán numerosos problemas. Pasos que hay que hacer a mano, complejidades de interface, ajustes y dolores que se van solucionando paso a paso con cada iteración.
El esfuerzo vale la pena. Solo con la reducción o eliminación de la discusión entre IT y negocio hay valor suficiente para ser capturado. Pero la aceleración en la generación de valor para el cliente es el mayor beneficio. El propósito de la transformación es ser diferente, no hay mejor argumento de venta.
