Con relación a la implementación uno de los desafíos visibles hoy se deben a cómo los equipos de proyecto aplican estrategias de recopilación de requerimientos de negocio en las implementaciones de ERP. Los equipos de proyecto normalmente se limitan a un solo enfoque y no tienen en cuenta los desafíos asociados con el método de recopilación de requisitos seleccionado.

Vamos recrear una conversación entre usted, en su rol de cliente y un consultor que trabaja con usted para desarrollar algunos cambios de software para su software industrializado licenciado a un proveedor. El consultor puede tomar dos enfoques para reunir los requisitos:

Opción # 1: “¿Qué le gustaría?”

Una pregunta abierta que generará una gran cantidad de comentarios de usted el cliente. Sin embargo, esa pregunta comunica varios mensajes subyacentes que usted puede asumir:

  • Usted como el cliente obtendrá una solución personalizada. Los cambios de software requieren un esfuerzo mínimo.
  • Puede ser que el consultor no tenga suficiente conocimiento de su negocio como para hacerle una recomendación.
  • Usted como cliente sabe exactamente lo que quiere.
  • El consultor parezco estar más enfocado en el cliente.

Opción # 2: “Aquí está la funcionalidad del producto tal como viene. Por favor, explique por qué esto no es suficiente”

Una pregunta que comunica varios mensajes subyacentes:

  • Usted como el cliente no puede conseguir lo que quiere. No se harán cambios en el software.
  • Puede ser que el consultor no tenga suficiente conocimiento de su negocio – especialmente si no sabía de las lagunas de antemano.
  • Usted como cliente puede ponerse a la defensiva por no ser tratado adecuadamente como la parte interesada clave.
  • El consultor parece estar menos centrado en el cliente.

Ambas opciones son enfoques válidos para reunir los requerimientos de negocio del ERP. Sin embargo, los desafíos visibles hoy se deben a cómo los equipos de proyecto aplican estrategias de recopilación de requisitos a las implementaciones de ERP. Los equipos de proyecto normalmente se limitan a un solo enfoque y no tienen en cuenta los desafíos asociados con el método de recopilación de requisitos seleccionado.

Métodos múltiples para conocer requerimientos del ERP

Sobre la base de mi experiencia, hay tres estrategias principales para reunir los requerimientos de negocio para el ERP

Requerimientos de negocio para customizar el ERP

Requerimientos de negocio para customizar el ERP

Estrategia impulsada por los requerimientos negocio

Una estrategia puramente basada en los requerimientos de negocio se centra en definir todos los requisitos del negocio independientemente de las limitaciones organizativas y tecnológicas.

Este es el método más utilizado hoy en día. Es un enfoque más lento y será necesario mayor tiempo de los usuarios empresariales para articular los requisitos. Se puede anticipar la recolección de los requerimiento de negocio sin valor añadido, si hay un proceso previo en el que se filtren los que no son de valor añadido.

Estrategia impulsada por la solución

En el otro extremo del espectro, una estrategia basada en soluciones puras que se centra en los requisitos de negocio que no se pueden cumplir con la funcionalidad entregada.

Este enfoque es muy popular en las implementaciones de ERP rápidas y requiere la menor cantidad de tiempo de los usuarios empresariales. Sin embargo, las actividades de implementación deben ajustarse al software empresarial industrializado. Esto podría tener un impacto significativo en la aceptación y en los procesos de la organización porque los diseños de software ERP se basan en un conjunto de requisitos impulsados por el mercado y no en los requisitos específicos de un cliente individual.

Estrategia impulsada por la configuración

La estrategia basada en la configuración se sustenta en la premisa “El nuevo sistema necesita hacer lo que el sistema actual hace hoy”.

Puede ser una situación en la que un cliente simplemente necesite un sistema de reemplazo porque el existente está cerca del final de su licencia y puede convertirse en software descontinuado y sin soporte.

Comenzar con lo que el cliente sabe ayuda a agilizar la recolección de requisitos. El tiempo del usuario se minimiza porque el área de tecnología puede proporcionar información sobre las capacidades y la configuración del sistema empresarial existente. Sin embargo, este enfoque presentará requisitos de superficie basados en las limitaciones existentes del sistema, así como en los requisitos empresariales legados sin valor agregado.

Cuál es el mejor

Cada enfoque de recopilación de requisitos tiene sus fortalezas y desafíos. Este hecho no los invalida. Lo que se requiere es la correcta aplicación de estos métodos para alentar – no obligar – a los clientes a maximizar su inversión ERP.

Buenas Prácticas: Uso de métodos múltiples para conocer los requerimientos de negocio

¿Hay una manera de considerar lo mejor de cada enfoque y crear una estrategia que tome completas ventajas del software ERP a implementar?

¿Qué pasaría si se pudieran traer diferentes enfoques para complementar y elaborar progresivamente (iterar) las necesidades del negocio?

Este es el objetivo del enfoque combinado: aprovechar diferentes técnicas en el proceso en las que pueden generar el mayor valor.

El equipo del proyecto reúne las necesidades empresariales desde diferentes perspectivas que le permiten crear un conjunto de definiciones de requisitos globales. Finalmente, el enfoque eliminará naturalmente los requisitos de negocios sin valor añadido. Revisemos cómo ejecutar un enfoque combinado para la recopilación de requisitos.

Iteración # 1 – Escuchar al cliente

En la primera iteración se utiliza el enfoque basado en los requerimiento para reunir los requisitos de alto nivel. La diferencia en la aplicación de este enfoque es el nivel o grado que se ejecuta en esta iteración.

El objetivo es recopilar suficientes requisitos empresariales que permitan al equipo del proyecto desarrollar un sistema competente para la modelización de soluciones empresariales. Un concepto clave aquí es que el cliente necesita sentir que están siendo escuchado y comprometido, pero no se les promete una solución personalizada. El equipo del proyecto debe ser capaz de desarrollar un sistema que asegure al cliente que el software empaquetado apoyará su negocio.

Centrarse en la recopilación de los escenarios empresariales principales y datos relevantes permitirá al equipo del proyecto producir una solución realista para utilizar durante el modelado de la solución empresarial.

Iteración # 2 – Conducir al cliente

Aquí, en esta iteración el equipo del proyecto pasa de escuchar a liderar una solución de negocio.

Durante el modelado de la solución empresarial, el equipo del proyecto demostrará la capacidad del software empaquetado para respaldar los principales escenarios empresariales para sus clientes. Durante el modelado el equipo también se centra en recopilar excepciones a los escenarios estándares de procesos empresariales definidos.

Es de destacar que esta actividad proporcionará la oportunidad de validar los requisitos del negocio y la configuración del software durante el proceso de recopilación de requisitos.

Iteración # 3 – Negociar con el cliente

Esta iteración final es una confirmación de que están definidos todos los requerimientos de negocio de valor agregado y se han tratado todas las excepciones y escenarios empresariales.

La configuración de los sistemas legados del cliente no sólo es otra fuente de validación, sino que también puede ser la primera iteración de definir los requisitos de migración de datos heredados.

Resumen

Una de las técnicas clave que el equipo del proyecto puede usar para detectar y resolver conflictos de requerimientos de negocio es reunir los mismos desde diferentes perspectivas.

Interactuar para definir sus necesidades de negocio desde diferentes perspectivas, naturalmente, identificará posibles conflictos.

Comenzar con un enfoque basado en los requerimientos de negocio establece las bases para la recopilación de requisitos eficaces, así como promueve la colaboración. A continuación, la adopción de un enfoque basado en soluciones permite al equipo de proyecto identificar rápidamente los límites del software empresarial empaquetado. En tercer lugar, la utilización del enfoque basado en la configuración proporciona una validación de los resultados de las actividades impulsadas por los requisitos y por las soluciones. Y, finalmente, teniendo un enfoque basado en los resultados se asegura de que se soportan los resultados de negocio deseados.

Fuente: Grady Brett Beaubouef

Traducido y adaptado por la División consultoría de EvaluandoERP.com

 
Share This
Suscríbase a nuestras novedades

Suscríbase a nuestras novedades

¿está interesado en nuestros contenidos de ERP? Suscríbase para nuestros newsletter y no deje de estar informado.

¡Listo, ya está suscripto!