Categorías
Metodología

Lecciones aprendidas al aplicar metodologías ágiles en un proyecto de implantación ERP

¿Por qué es tan difícil aplicar metodología ágil en un proyecto de implantación de ERP?, ¿Qué es lo que lo hace tan diferente de un proyecto más tecnológico (web, App,…)?

Estas son algunas de las  reflexiones que hemos compartido en el pasado #beERDays bajo la perspectiva inicial de la charla del pasado D365 Saturday, donde ya comentábamos las opciones de aplicar SCRUM en un proyecto de Dynamics 365, pero ahora con la experiencia de aplicarlo en un proyecto más amplio en #Aenor.

Y es que en muchas ocasiones nos encontramos con que durante la fase comercial, se ha vendido la magia de las metodologías ágiles mediante una serie de slides, que rara vez los decisores entienden en profundidad lo que conlleva. Es aquí, dónde me gustaría comenzar la reflexión, en el momento de empezar el proyecto, cuando el equipo se encuentra con debe aplicar Agile pero nadie antes le ha explicado cómo articularlo en un proyecto real.

Resumen de las lecciones aprendidas al aplicar metodología ágil a un proyecto de implantación de ERP

Deadline vs Proyecto Abierto

Una de las primeras cuestiones que debemos enfrentarnos al comenzar un proyecto de implantación/migración de ERP es sobre el modelo de proyecto, ¿estamos en un proyecto donde tenemos un deadline o en un proyecto abierto sin una fecha fija?.

En la mayoría de las ocasiones, un proyecto de ERP tendrá un deadline debido a la dependencia de los ciclos financieros y la integración con el resto de sistemas del cliente. De modo que, si bien el equipo puede trabajar por sprints, al final el cliente querrá que se implante en una fecha concreta independientemente del estado del backlog y los sprints definidos. Corremos entonces el riesgo de que el cliente pueda malentender que los sprints son pequeñas fases dentro del proyecto y que en la fecha del arranque tendrá “todo”.

Es por eso que debemos hacer entender que en metodologías ágiles el hecho de tener un deadline implica que debemos jugar con el alcance y la capacidad del equipo. Se priorizarán entonces las funcionalidades/requisitos totalmente imprescindibles por encima de aquellos que realmente puedan esperar a después del arranque o bien exista un workaround manual. También podremos ajustar la capacidad del equipo disponible, si bien una vez avanzado el proyecto, no es fácil encajar más miembros en el equipo de forma productiva. Si todo esto no lo explicamos antes de arrancar el proyecto, nos encontraremos en un proyecto clásico de implantación.

Es por eso que debemos enfocarnos en las funcionalidades realmente importantes o que aporten valor. Es muy común que al preguntar a los usuarios éstos quieran todo lo que tenían en el anterior sistema o bien que todo sea automático. En el caso de Dynamics 365 FO, es un producto en cloud en constante actualización donde Microsoft marca el ritmo (concepto One Version), de manera que la aproximación del proyecto debe ser siempre la de implementar el menor número de GAPS posibles. Cualquier funcionalidad que se implemente a medida implica un sobrecoste y una herencia que es probable que en el futuro incluso no sea compatible con el roadmap del producto, pudiendo perder incluso nuevas capacidades del producto.

En muchas ocasiones, adaptarse al producto implicará cambiar el proceso que lleva definido durante muchos años y muy condicionado por el anterior sistema. Por lo que dependerá de la madurez y visión de los Keys users la posibilidad de ajustar los procesos al ERP.

Responsabilidad compartida

Existe una falsa percepción de que simplemente con que el proyecto se apoye por la dirección, el proyecto saldrá adelante. Si bien esto es muy importante, existe una responsabilidad compartida entre los negocios, IT y el proveedor.

Como cliente, estaremos cometiendo un error si lanzamos el proyecto y nos lavamos las manos hasta la fecha de arranque. No debemos confundirnos con que este tipo de proyectos son de IT o del proveedor de turno. Si no conseguimos la implicación de los negocios, del equipo financiero y del equipo de TI del cliente, el proyecto tendrá retrasos o bien será un fracaso. Y es que la implantación de un ERP tiene un impacto en todos los negocios de la empresa y si bien el proveedor puede ser solvente, existe una dependencia muy fuerte de los procesos del cliente y de la colaboración de IT para la extracción de datos, integraciones, …

En mi opinión el proyecto debería estar liderado por Financiero, que será el que defina gran parte del proyecto y el momento de salir a producción. Por otro lado, el equipo de IT debe ser un facilitador dentro del cliente, proporcionando los elementos necesarios al proveedor (datos, entornos, integraciones,…), persiguiendo a negocio, validando los FDD y TDD, identificando riesgo y velando por la buena marcha de los hitos definidos. Por último, los negocios deben colaborar en la definición, aprobación y pruebas de los desarrollos.

La metodología ágil requiere de una implicación constante de los diferentes actores durante todo el proyecto, de modo que cuanto antes los involucremos, menos riesgo tendremos al final del proyecto.

Dependencia con negocio

Un aspecto que diferencia un proyecto ERP de uno tecnológico es la alta dependencia con los negocios, provocando que gran parte de las tareas no se puedan cerrar a expensas del negocio.

Durante la fase de definición podemos encontrarnos con reuniones con muchos interlocutores, donde cada uno aporte una visión sesgada de su negocio y que además no sean decisores. Es por eso que debemos identificar desde el principio del proyecto a los Key users de cada negocio. ¿Cúantos Key Users debemos tener? Cuantos menos, mejor. ¿Qué perfil debe tener el Key User? Deben ser personas que tengan una visión amplia de los procesos de su negocio e incluso del resto de la casa, ágiles a la hora de responder y con capacidad de decisión.

Otros de los factores de un Key user es que deben tener disponibilidad casi en exclusiva al proyecto. Esto, que es algo muy complicado de conseguir, es uno de los factores que afectarán claramente al progreso del proyecto.

Del lado del proveedor, se debe identificar todas aquellas dependencias con negocio durante todo el proyecto y marcar fechas límite para cada una de ellas. Estas fechas no deben ser amplias, ni deben esperarse al final del proyecto, ya que se debe trabajar con los Key users durante todo el proyecto. Por ejemplo, no podemos esperar que los Key Users nos proporcionen todas las plantillas de cargas de datos perfectas al final del proyecto.

Como parte de IT, tendremos que asegurarnos que los Key Users cumplen con sus compromisos y que al mismo tiempo los proveedores proponen un buen planteamiento de proyecto.

Una de las experiencias que hemos aprendido en Aenor es que debe quedar claro desde el principio qué se espera de un Key User y cuales son sus responsabilidades. Aunque se pueda explicar al inicio del proyecto, los usuarios no son plenamente conscientes de las implicaciones hasta pasado un tiempo del proyecto.

Hitos & Sprints

A la hora de montar la planificación del proyecto, debido a la gran dependencia con otros sistemas y dependencia con tareas de negocio, decidimos trabajar con la dirección con modelo waterfall basado en releases e hitos parciales basada en el backlog previamente trabajado.

Cada uno de los hitos tenía como objetivo adelantar los riesgos de la puesta en producción y comenzar con la adopción del nuevo sistema por parte de los usuarios.

Durante la construcción del backlog, utilizamos LCS como sistema de gestión del ciclo de desarrollo de Dynamics 365. El problema que nos encontramos fue que por cada funcionalidad nos aparecieron una gran cantidad de tareas a realizar generando sprints inmanejables. En realidad estas tarea había que realizarlas, pero se volvía complicado poder realizar un seguimiento y planificación para cientos de historias de usuario. Al mismo tiempo, nos encontrábamos con que los consultores no eran capaces de cerrar historias de usuario debido a las dependencias con negocio o incluso IT.

De modo que decidimos separar el backlog en dos, una parte relacionada con el equipo funcional dejaría de utilizar sprints para trabajar en un modelo KANBAN y por otro lado seguir trabajando por sprints con el equipo de desarrollo.

Comunicación

Comunicación, comunicación y más comunicación.  No me estoy refiriendo solo a reuniones de seguimiento o a el uso de herramientas como Teams, si no a cómo debemos conseguir que fluya la información entre los negocios, los business partners, DP’s y el equipo.

En nuestro caso, nuestro proyecto está compuesto por más de 30 personas agrupados en tres equipos diferentes (IT AENOR, CRM y ERP), por lo que la comunicación y el seguimiento del proyecto se hace vital para llegar al deadline.

No existe una receta mágica para todos los proyectos, en nuestro caso hemos aplicado lo siguiente:

  • Por un lado, hemos incorporado las figuras de Business Partners, personas con un perfil funcional y un conocimiento de los procesos de la casa y los sistemas IT. Estas personas están presentes en todas las reuniones ayudando a cerrar funcionales, validar y comunicar al resto del equipo.
  • Hacemos reuniones semanales con los actores más decisores del proyecto (DP’s, BP, Scrum Master y los Leads de equipo) con el objetivo de revisar cada uno de los bloques del proyecto a nivel funcional/técnico y posibles riesgos.
  • Por otro lado, el equipo de trabajo sigue con las liturgias normales de agile (daily, sprint planning, sprint review y retro). A estas dailies se suman los business partners y el DP, identificando riesgos o gaps de información.
  • Como elemento adicional diferenciador, en nuestro caso hemos conseguido un ambiente en el que los diferentes miembros hablan entre ellos de forma rápida y transversal sin necesidad de reuniones ni jerarquías.

Clave: Scrum Master

Aplicar Agile requiere de cierto grado de madurez del equipo, por lo que si no tenemos esa madurez nos encontraremos con un problema serio al intentar aplicarlo. No me refiero solo a que el equipo entienda los conceptos, si no a que debe interiorizarlo de forma natural.

En nuestro caso incorporamos una figura de Scrum Master que ayuda a los diferentes equipos a aplicar la metodología SCRUM de forma adecuada y facilita que los equipos se centren en lo importante y entiendan el trabajo a realizar.

Debemos ser conscientes que el Scrum Master no es un jefe de proyecto. A la hora de gestionar el proyecto, (en nuestro caso) es el DP el que marca las prioridades, el Scrum Master le ayuda a definir los sprints y asegura que el equipo entiende las historias de usuario implementándolas en los diferentes sprints.

Pero no solo debe entender la metodología el equipo, también debe entenderla los DP’s, gerentes, negocio y dirección.

Por Mario Cortés

Especializado en proporcionar una visión tecnológica a las estrategias digitales de las compañías. Con más de 15 años de experiencia como consultor en el mundo de la tecnología, se ha centrado en aportar soluciones de colaboración y de negocio.
Galardonado como Microsoft Most Valuable Professional en Office 365 desde el 2011 al 2018, he participado en múltiples conferencias y artículos tecnológicos.

Deja una respuesta