¿Es posible ser agil y global al mismo tiempo?

Por: Mario Alberto de la Cruz Hernández

En un mundo con inagotable incertidumbre, como es el que nos está tocando vivir, un sinfín de cambios, y volviendo prácticamente imposible hacer una planeación a mediano o largo plazo. ¿Es posible aplicar metodologías ágiles a implementaciones de IT globales? ¿En varios países? ¿En diferentes idiomas? ¿Con la expectativa de los usuarios de contar con todo para ayer?

Respira. La respuesta es ¡Sí!

LA PROBLEMÁTICA DE UNA IMPLEMENTACIÓN DE SISTEMAS GLOBAL El día de hoy les platicaré el caso de la ejecución global de un Sistema de seguimiento de productividad en el área de Compras para una empresa global que, afortunadamente, ¡es mexicana!

RETOS POR ENFRENTAR EN ESTE PROYECTO En la mayoría de las empresas a nivel mundial, el área de Compras tiene un objetivo claro: Conseguir ahorros en las adquisiciones y negociaciones que se hacen con los diferentes proveedores. En la nueva manera de trabajar, las áreas de Compras también tienen otras responsabilidades, como lo es el incremento en el Capital de Trabajo, la ventaja tecnológica y competitiva, eficiencia laboral, gestión de riesgos, adición de Valor, etc. Aun así, el objetivo primordial sigue siendo la consecución de ahorros para la empresa. Dentro de la dinámica actual de trabajo, es necesario contar con una herramienta tecnológica que permita medir de manera consistente y confiable los ahorros que está teniendo el área de Compras, y la cual le de visibilidad para hacer las correcciones correspondientes en cualquier etapa del año. Esta empresa presenta retos considerables: ✓ Presencia en más de 33 países. ✓ 5 idiomas oficiales de trabajo (Español, Inglés, Francés, Portugués y Chino). ✓ 4 continentes (con sus diferentes husos horarios).

Partes interesadas en diferentes países buscando obtener información de la herramienta de diferente manera, y con diferentes procesos. Además de que esta empresa ya había estado usando por un tiempo una herramienta para medición de ahorros. Sólo que dicha herramienta tenía más de 10 años de antigüedad, por lo que no aprovechaba la nueva tecnología disponible en el mercado (SaaS, acceso a través de web browser y de aplicación móvil, Etc.). En su momento, era como contar con un Cadillac del año, pero era momento de renovar el auto.

MANERA ÁGIL DE ABORDAR LA IMPLEMENTACIÓN DE ESTE SISTEMA Teniendo en cuenta todas las complicaciones que puede tener una liberación global, de acuerdo a las características y los retos ya mencionados, tomamos la decisión de hacer una implementación ágil con el enfoque Lean. A diferencia de Scrum, Lean me permite hacer liberaciones cuando estas hagan sentido al negocio, en lugar de estar sujetas a una calendarización de sprints. Además, Lean me permitió tomar varias ventajas de la situación que tenía el equipo asignado al proyecto: La gente no estaba muy familiarizada con procesos ágiles. No hacía sentido contar con iteraciones rígidas, ya que los siguientes requerimientos a implementar saldrían de la propia operación (las épicas no se definirían en su totalidad desde el principio, como buen proyecto ágil), además de que estos seguramente cambiarían de país a país. Lean me permitió eliminar cuellos de botellas en el proyecto. Los bloques de trabajo fueron asignados cuando la capacidad estuvo disponible (el equipo no estaba asignado 100% al proyecto). La priorización del trabajo la hicimos “just in time” (JIT). Y finalmente, no quisimos caer en la tentación de mantener la aplicación en la “zona de confort” y que operará como venía haciendo la aplicación anterior. Quisimos que la nueva solución apoyara la disrupción en la Operación de Compras en todas las Unidades de Negocio donde opera esta empresa. Los requerimientos iniciales que configuramos en el backlog del producto fueron aquellos que estaban embebidos en la aplicación que ya estaba operando. Esto se debió a los siguientes motivos: Son los requerimientos con los que la mayoría de los usuarios están de acuerdo en implementar. Son los más fáciles de probar, ya que están validados en la aplicación previa, y sólo es cuestión de replicarlos. Así que con eso en mente, procedimos a armar el backlog inicial del producto.

EJECUCIÓN DEL PROYECTO Para el desarrollo del proyecto decidimos manejar la implementación de la siguiente manera. El MVP (Minimum Viable Product) será el nuevo sistema, con la funcionalidad definida en la aplicación anterior. Aprovechando la metodología Lean, definimos no hacer el lanzamiento de la primera versión hasta asegurar que la funcionalidad estaba totalmente replicada. Previo al lanzamiento, se hizo una validación de la aplicación con los diferentes especialistas, trabajando en conjunto con el Product Owner (principalmente con el equipo de México y Estados Unidos, que son las Operaciones más grandes que tiene esta compañía). Ya que todo estaba validado y probado, se hizo el decomiso de la herramienta previa para hacer una migración de datos de datos hacia la nueva aplicación. Después de hacer el primer deploy, se procedió a recolectar las historias de usuario y las épicas de los nuevos requerimientos con todos los especialistas de las diferentes Unidades de Negocio. En conjunto con el Product Owner, se determinó la priorización de los nuevos requerimientos, y cuando era el mejor momento para lanzarlos (los sprints de lanzamiento eran variables, no fijos como en Scrum).

GOBERNABILIDAD DEL PROYECTO Teniendo en cuenta que son más de 250 usuarios a nivel global los que tiene esta aplicación. Lo importante es definir la gobernabilidad del proyecto. La asignación de roles fue de la siguiente manera: Yo fungí de Team Lead, debido a mi expertise en procesos ágiles y a la experiencia que tengo en proyectos. El Product Owner: Contamos con la facilidad de que uno de los patrocinadores más importantes del proyecto estuvo muy involucrado en el desarrollo del mismo, además de que es una persona con mucho conocimiento en procesos de Compras, por lo que dicha persona tomó este rol. Un consultor que estuvo asignado por parte de la empresa contratada fungió como Architecture Owner. Esta decisión fue tomada dado la experiencia de este consultor en esta tecnología, así como en análisis encargado a este consultor del ecosistema de tecnología existente en la Empresa. Por la naturaleza de este proyecto, se designaron varios Especialistas en los equipos de Compras de las diferentes Unidades de Negocio, los cuales colaboraban con el Product Owner para las definiciones de las épicas y las prioridades del backlog. Finalmente, todos los miembros de los equipos de Compras fueron Team Members en este proyecto

RESULTADOS OBTENIDOS Y LECCIONES APRENDIDAS La Metodología Lean nos permitió tener varias ventajas en este proyecto, que de otra manera no hubiéramos podido aprovechar con otras maneras de trabajar: Nos permitió trabajar con un equipo no dedicado al 100% al proyecto, pudimos hacer el reemplazo de la aplicación en un periodo de 8 semanas para el MVP, y los otros requerimientos fueron integrados cuando fueron necesitados por el negocio, a la vez que fuimos capaces de lograr una alineación del proceso de negocio entre todas las Unidades de negocio. Con dichas lecciones aprendidas, en la misma empresa estamos ejecutando otros proyectos con la misma metodología. Y seremos capaces de determinar en el futuro si podemos replicarla a la realidad de otros departamentos en esta Empresa.