A cuantos líderes de proyectos o ejecutivos de TI les gustaría que sus proyectos terminaran en tiempo, dentro del presupuesto asignado y dentro del alcance definido…. y además que el producto que genere el proyecto cumpla cabalmente los requerimientos de los usuarios!… parece increible no?
Para todos aquellos que han trabajado en Tecnologías de Información, entenderán que un aspecto crítico de todo proyecto es que, ademas de concluir el proyecto dentro del plan y dentro del presupuesto, éste debe de satisfacer los requerimientos del usuario y de la organización y cuando esto no sucede, el proyecto se considera como un proyecto problema o no exitoso.
Cuando un proyecto se convierte en proyecto problema o no exitoso, pasan una de tres cosas: 1) el proyecto es cancelado definitivamente, 2) el proyecto es redefinido y se replanea con el consecuente incremento en el tiempo, el costo y el alcance con el fin de hacer que el proyecto entregue los resultados esperados, o 3) el proyecto se divide en varias fases las cuales tradicionalmente….. se cumple la primera pero el resto……nunca se cumplen! (algo odiado por los usuarios)
Pues bien este, es un problema mundial!, ha sido tan frecuente esta situación en todo el mundo que la comunidad internacional de profesionales que se dedican a la definición y especificación de requerimientos decidió hacer algo al respecto y crearon el International Institute of Business Analysis (IIBA) con el fin de definir las mejores prácticas para esta función.
Gracias a esta organización, se definieron las etapas, tareas, entregables y técnicas necesarias para ejecutar esta función, las cuales al ser adoptadas por una organización y por los practicantes de análisis de negocios en la organización, se mejora sustancialmente el rendimento de esta función ya que su objetivo principal es asegurar que el producto resultado del proyecto, esté construido de acuerdo a los requerimientos de los usuarios, que esté construido de forma correcta y que satisface las necesidades de la organización.
Muchos de los que nos hemos dedicado a desarrollar soluciones de TI hemos hecho esta función y de hecho somos Analista de Negocios, pero… no lo sabemos! y además la ejecutamos de forma empírica sin contar con técnicas o herramientas para ejecutarla de forma ordenada, con estándares y mejores prácticas.
Las organizaciones de alguna manera se han dado cuenta del problema e incluso han creado áreas dentro de la organización para cubrir esta función, las han llamado de diversas formas: Analistas de Sistemas, Business Partners, Business Representatives, Embajadores, Ingenieros de Procesos, Analistas de Negocios, Arquitectos de Negocios, etc., etc. etc., sin embargo no saben qué es lo que estas personas deben de saber para ejecutar la función, o cuales son las mejores prácticas que tanto la organización como los profesionales que ejecutan la función deben de incorporar para realizar esta tarea de manera eficiente.
Pues bien, el Análisis de Negocios es la visión ampliada de la recolección de requerimientos. Uno de sus principios básicos es cambiar la mentalidad del analista de negocios de que no es un «tomador de pedidos», si no que se convierte en un profesional con los conocimientos (técnicos y de negocios) y competencias (técnicas) necesarias para entender problemas de negocios y proponer soluciones a estos problemas. Su función no es sólo proponer soluciones de TI, sino proponer la solución que requiere la organización haciendo uso de los recursos de la misma esto es, una solución puede abarcar tanto los sistemas de una organización como los procesos o la estructura organizacional. El Analista de Negocios es capaz de proponer soluciones en cualquiera de estos ejes dentro de una organización.
En concreto, el Análisis de Negocios es acerca de entender un problema de negocios, proponer alternativas de solución y definir el alcance de la solución seleccionada considerando todos los recursos de la organización.