Beneficios del Análisis de Negocio

Beneficios del Análisis de Negocio

Comenzare por enmarcar los los principales problemas que tenemos día a día, durante el desarrollo de un proyecto y que en un gran porcentaje, está asociado a la ausencia de las mejores prácticas de Análisis de Negocio, en el siguiente análisis de causa raíz podemos ver las principales causas de falla en los proyectos.

                      

 ¿Cuantas veces hemos sido cómplices de una estimación inadecuada, en donde generalmente se comprometen fechas o entregables, aun no teniendo claro el alcance proyecto?, Está es una de las primeras malas practicas que se tienen en el desarrollo de software y que a menudo se traduce en las largas horas laborales (re-trabajo y esfuerzo mal orientado), absorbiendo los riegos del mismo. Cuando dicho problema pudo haber sido mitigado en gran medida, si tan solo se hubiera hecho un análisis mucho más certero a las necesidades reales del negocio.

En la siguiente imagen del cono de Incertidumbre podemos observar que tanto riesgo se tiene el comprometer el proyecto si este no cuenta con los requerimientos de negocio detectados y aprobados.

"Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre.  Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x. El comprometerlo al principio del cono, hacen que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo de ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto. 

Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello. Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo"

• La probre definición de los requerimientos entre el negocio y el área de TI trae como consecuencia un 66% de probabilidad de fracaso
• Las compañías que tiene un proceso débil para la toma de requerimientos tiene tres veces mas proyectos fallidos que exitosos
• La compañías pagan un bono extra de alrededor del 60% en tiempo y presupuesto cuando sus proyectos no cuentan con prácticas de requerimientos.
• La gran mayoría de proyectos no utilizan recursos con suficientes habilidades de análisis de negocio para el desarrollo de los proyectos, trasladando el costo a fases posteriores del análisis, donde el costo se multiplica hasta por 10x para la corrección de fallas.
• Si las personas y procesos para realizar análisis de requerimientos están solamente en el promedio, más que en la excelencia, esta deficiencia de excelencia puede consumir aproximadamente el 41% del pre supuesto asignado del proyecto.
• Standish group ha reportado que los proyecto a gran escala tipicamente se pasan al rededor de 189% en su presupuesto y 222% en el tiempo de entrega, donde los principales factores se debe a las prácticas empleadas para la toma de requerimientos

"It’s a myth that the average analyst can be assigned any project. The evidence here: an average analyst will fail to achieve process reengineering objectives over 60% of the time. Average analysts do not deal well with process change objectives. Their requirements discovery process appears to be fundamentally different than that used by elite analysts. Excellence comes through a rethinking of how requirements are  done."

fuente Project Failure - Dan Galorath, Business Analysis Benchmark

Una combinación entre la mejora de las practicas de Análisis de Negocio y la mejora en los procesos de negocio (CMMi, ISO 9000) han probado, que dan enormes diferencias en la productividad del desarrollo de sistemas dando como resultado los siguientes numeros:

• 67% de reducción en el costo de re-trabajo

• del 30% al 40% de reducción en los tiempos de desarrollo

• 90% reducción en defectos

• 350% incremento de la productividad de los equipos de trabajo

funte  Getting Business Requeriments Right

Un estudio del SEI (Software Engineering Institute) encontró que el factor mas importante para mejorar el desarrollo de sistemas, es como la compañía aplica las disciplinas de Recopilación y Administración de los requerimientos.

Por o anterior y para alcanzar los beneficios, debemos de centrar los esfuerzos en el alcance del proyecto (Visión), involucrar los stakeholders correspondientes y organizar y clasificar los requerimientos con el fin de evitar las ambigüedades y las deficiencias de comunicación de las necesidades de negocio.

Los siguientes factores son vital para el éxito del proyecto

• Tener una metodología disciplinada y repetible para controlar las sesiones de recopilación de requerimientos
• Tener a los Stakeholder correctos e involucrarlos solo en las funcionalidades en los que participen (ser eficientes con los tiempos)
• Utilizar un estrategia modular que permita establecer las responsabilidades y colaboraciones de cada servicio de negocio a implementar
• Contar con herramientas para documentar los requerimientos de manera rápida y validar con los stakeholders.
• Establecer un proceso de autorización (sign-off) en el cual se acuerden los requerimientos funcionales y no funcionales de las líneas bases que serán implementadas