Porque prefiero SureStep y no utilizar Scrum

Sigamos un poco con metodología, actualmente muchos partners se basan en los project managers para definir su metodología de implementación de ERP´s y si somos honestos, esta de moda el uso de Scrum, en mi experiencia (la cual no marca o define una regla inflexible), me he encontrado con proyectos emproblemados donde la base de dichos problema reside en parte por una venta mal realizada (alcance definido incorrectamente) pero que pudiera ser reparable con cierta inversión y aumento en los costos, pero con una ejecución demasiado emproblemada debido a la metodología utilizada.

Scrum

Scrum se basa en el empirismo y el pensamiento Lean. El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado. El pensamiento Lean reduce el desperdicio y se enfoca en lo esencial.

Ahora bien, como dice la metodología Scrum, cambiar el diseño, omitir elementos o no seguir las reglas limita los beneficios y potencialmente lo vuelve inútil.

Una manera fácil de entender el Scrum es verlo como una forma de trabajar en equipo en pequeñas partes a la vez con experimentación continua y ciclos de retroalimentación para aprender y mejorar a medida que se avanza y tiene un marco “ágil” porque se integra un equipo pequeño de personas con las capacidades necesarias para sacar adelante cada sprint.

Ahora bien, la metodología ágil esta pensada para trabajar respondiendo a requerimientos cambiantes y su retroalimentación. Se basa en la idea de que no es necesario saberlo todo de antemano y que se puede aprender y mejorar a medida que se avanza.

La implementación de un ERP no es un proceso de prueba y error, tampoco debería ser de aprendizaje dado que el costo es elevado y los clientes justamente contratan y pagan esos precios porque no pueden dejar su operación en manos de personas sin experiencia ya sea en su propio giro o al menos que conozcan al 100% las capacidades del ERP con consultores que sepan detectar, definir, adecuar y moldear el sistema a sus necesidades.

Gran parte del problema esta generado por Microsoft mismo ya que según el fabricante:

“En los proyectos de Dynamics 365, muchos requisitos están cubiertos por las capacidades listas para usar del producto. Sin embargo, es necesario abordar y priorizar desafíos y tareas específicos en una lista de backlogs de historias de usuario. Una historia de usuario es una breve descripción de una característica o función que el usuario desea o necesita. A partir del backlog, creas planes para cada sprint y les asignas historias de usuario. Durante el sprint, trabajas en las historias de usuario y entregas un software funcional y probado al final. También recibes comentarios de los usuarios y las partes interesadas, y los usas para mejorar el siguiente sprint.”

¿Qué es lo que nos genera esta forma de trabajo?

Bueno, desde mi experiencia personal, genera una expectativa muy alta por parte del usuario de que, dado que el consultor escucho su “historia de usuario”, el sistema hará lo que el pidió, tal cual el lo describió y eso generaliza la problemática dado que, si analizamos la situación, la historia de usuario normalmente se basa en su experiencia actual y no en la necesidad real. Esto puede derivar en que si el usuario esta trabajando con un software hecho a la medida (escenario muy común), su historia de usuario requerirá exactamente ese proceso y siendo Dynamics 365 un software generalista (cubre muchos procesos de muchos tipos de empresa con base en las buenas prácticas de….), entonces lo mas seguro es que no tenga ese proceso exactamente, aquí me remito a un cliente que pidió vale azul en la solicitud para gastos de caja chica con 3 firmas de aprobación.

Si pensamos que haremos “ciclos” de descubrimiento, si el ERP no cubre los vales azules, entonces esto generará un backlog y una solicitud de cambio lo cual disparará un diseño de modificación con un coste. Dado que esto será una práctica recurrente, se irán acumulando backlogs mismos que deberán ser presentados en una reunión de comité para analizar la viabilidad y costo de esos cambios donde el cliente combatirá los costos diciendo que deberían estar incluidos en el proyecto dado que el usuario los solicitó y son esenciales para su operación. El partner discutirá un costo a recuperar y al final se llegará a un acuerdo, se procederá a realizar el desarrollo y finalmente se presentará al usuario quien puede decir que falta o podríamos darnos cuenta de que el desarrollo afecta algún otro backlog subsecuente, recordemos que Scrum establece que:

“Durante el sprint, trabajas en las historias de usuario y entregas un software funcional y probado al final. También recibes comentarios de los usuarios y las partes interesadas y los usas para mejorar el siguiente sprint.”

El problema que yo veo es que un ERP no es una serie de pedazos de operación separados, es un flujo constante de procesos que entrega un resultado después de muchas operaciones, por eso los ciclos son “order to cash” o “procure to pay”.

Un ciclo order to cash puede implicar desde crear al lead y la oportunidad, manejo de listas de precios y descuentos, control de disponibilidad de inventario, adquisición de productos y/o servicios, precios de compra, si son productos, recepción en almacenes, lotes, series, ubicaciones, picks, preparaciones, selección, entrega parcial o total, logística de entrega, facturación parcial o total, cobros parciales o totales, descuentos, impuestos, contabilidad, reportes, etc.

Como puede observarse, se debe analizar el ciclo completo, ver las interacciones entre departamentos, analizar la cobertura del ERP y las mejoras que podemos proponer y, finalmente, obtener el resultado el cual podría ser incluso un reporte contable definido por la dirección del cliente, si tratamos de “romper” el proceso completo en pequeños pedazos vamos en contra de los procesos integrados de un ERP como cuando se crea una factura que genera una disminución de almacén, afectación de costo de ventas, costeo de producto, generación de cuenta por cobrar y provisión de impuestos en un solo clic por lo que debemos ver el proceso como un todo y no partes separadas.

En las metodologías Scrum y Ágil se pueden encontrar algunos retos:

• Requiere un alto nivel de compromiso e implicación por parte de los usuarios y las partes interesadas.
• Puede resultar difícil estimar y planificar el alcance, el tiempo y el presupuesto del proyecto.
• Puede resultar difícil mantener la calidad y la coherencia en varios sprints y lanzamientos.
• Puede resultar complicado integrar y coordinar con otros equipos y sistemas.

Cascada o Estándar según SureStep

Según Microsoft, la metodología de cascada es una forma de trabajo tradicional y estructurada que sigue una secuencia clara y predefinida de fases. Se basa en la idea de que hay que saberlo todo de antemano y que no se puede volver a una fase anterior una vez que se ha terminado.

Es una metodología común para implementar aplicaciones empresariales. Es un enfoque lineal y no iterativo que ejecuta el proyecto de una sola vez.

Puntos importantes que veo en esta metodología:

• Tenemos un alcance definido.
• Si se define correctamente, se cuenta con desarrollos acotados.
• Se disminuye la “juntitis” ya que se cuenta con definición de cada tema y los consultores saben cual es el resultado requerido.
• Dado que existe un alcance y un documento de solución definido, no hay cambios constantemente.
• Si, es mas largo el proceso, pero esto evita gran cantidad de problemas de implementación causados por “Se basa en la idea de que no es necesario saberlo todo de antemano y que se puede aprender y mejorar a medida que se avanza”.

La metodología estándar de SureStep se basa en esta cascada y nos permite determinar desde el principio las necesidades del cliente, las necesidades del negocio, el alcance de los trabajos y si tenemos buenos consultores, las mejoras y cambios de proceso requeridos para aprovechar mejor la inversión, aunque esto es difícil dado que algunos partners o lideres de proyecto, alientan el escenario de “levanta pedidos” que significa tomar todo lo que diga el cliente y plasmarlo tal cual en el ERP dejando  de lado el ofrecimiento y capacitación de las mejores prácticas para explotar correctamente la herramienta, ¿un ejemplo? El catalogo de cuentas enorme con 5 cuentas de papelería, una por cada centro de costos dejando de lado el uso de dimensiones.

Finalmente, Scrum es una metodología diseñada primordialmente para el desarrollo de software, para crear ese software, en el caso de un ERP, ya está creado así que desde mi punto de vista podría utilizarse Scrum para los desarrollos a realizar en el proyecto de implementación, pero no para la implementación como tal y eso en dependencia de que este correctamente definido el alcance del desarrollo y su integración al proceso estándar del ERP.