Según la guía BABOK del International Institute of Business Analysis, el Análisis de Negocio (Business Analysis) es “el conjunto de tareas y técnicas utilizadas para trabajar como enlace entre los stakeholders con el fin de entender la estructura, políticas, y operaciones de una organización, y para recomendar soluciones que permitan a la organización alcanzar sus metas”.
Dicho de otro modo, el Business Analysis es la traducción de las necesidades de una organización en los requerimientos técnicos de una solución, especialmente en el campo de las soluciones tecnológicas, como la transformación digital o el desarrollo de apps.
Por lo tanto, el Analista de Negocio (Business Analyst) es un perfil profesional capaz de entender el modelo de negocio, el plan estratégico y de operaciones de la organización y traducirlo en requerimientos técnicos y funcionales concretos. Ser capaz de entender cómo funciona el negocio, sus procesos y los diferentes roles de los profesionales, identificar áreas u oportunidades de mejora y definir las soluciones necesarias teniendo especialmente en cuenta la viabilidad técnica y económica de la propuesta.
El analista de negocio puede ser una persona que desempeñe esta función en exclusiva o puede ser cualquier otro profesional de un área concreta que desempeñe esta función de cara a un momento dado o un proyecto en concreto. Por lo tanto, no importa tanto el puesto o rol que el profesional desempeñe en la organización, sino que lleve a cabo el objetivo del análisis de negocio. En muchas ocasiones estos perfiles son analista+s de sistemas, consultores IT, ingenieros, analistas de procesos, project managers, etc.
La importancia del Business Analysis (BA) reside en la incertidumbre implícita en cualquier proyecto de desarrollo tecnológico, siendo el BA un conjunto de métodos dirigidos a minimizar esta incertidumbre y por lo tanto los riesgos, es decir, se encarga de “aterrizar” al máximo el proyecto antes del inicio de su implantación.
Cualidades del Business Analysis
El Analista de Negocio debe poseer un importante pensamiento analítico orientado a la resolución de problemas, un conocimiento transversal de la compañía, especialmente de las interrelaciones y dependencias entre departamentos, una fuerte habilidad de comunicación y negociación, puesto que en muchas ocasiones le tocará intermediar entre departamentos para facilitarles el encuentro en puntos comunes y, por supuesto, debe tener un amplio conocimiento de las tecnologías disponibles y sus principales características e implicaciones.
Es muy común en organizaciones “tipo” encontrar cómo se generan tensiones entre departamentos al tratar de impulsar un proyecto tecnológico; un caso típico son las tensiones entre departamentos de marketing, innovación y sistemas. Marketing e Innovación ven cómo se solapan en algunas responsabilidades cuando la digitalización se dirige a la comunicación o al desarrollo de producto; Sistemas limita el alcance de los requerimientos al estar orientado a la estabilidad, funcionamiento y seguridad de los sistemas (suele tener una alta aversión al riesgo frente a la visión de innovación por ejemplo). El Business Analyst debe dimensionar, priorizar y ponderar las preocupaciones y objetivos de los diferentes departamentos y encontrar los puntos de encuentro, ofreciendo soluciones equilibradas.
La inversión en Análisis de Negocio impactará muy positivamente en el presupuesto final de implementación dado que minimizará incertidumbre, errores y desviaciones. En muchas ocasiones se realizan descripciones, análisis de requisitos o requerimientos de propuesta muy pobres, donde abundan generalidades, imprecisiones o falta de detalle dando por entendido muchos aspectos que deberían haberse concretado. Este tipo de arranques de proyecto acaban generando multitud de iteraciones, ya que la definición se va realizando a lo largo del proyecto, requiriendo una y otra vez rehacer partes del proceso hasta ajustar la realidad a unas expectativas que no se habían plasmado ni consensuado en un documento.
En tecnología las prisas suelen curiosamente ralentizarlo todo. Es crucial una planificación pormenorizada y una buena documentación para facilitar una comprensión del alcance de un proyecto por parte de todos los participantes y stakeholders.
Un mal análisis de requisitos conduce a procesos de innovación caóticos
Imaginemos mediante un caso bastante común un requerimiento para una plataforma de gestión online, en el que a la primera pantalla que se va a encontrar el usuario la denominamos “Login”. En el análisis de requisitos no se profundiza ni detalla mucho más dando por hecho que un Login no deja de ser una pantalla con un campo “usuario” y otra para la “contraseña”.
Arrancamos la implementación y alguien del departamento de Recursos Humanos apunta que es complejo generar de nuevo claves y contraseñas cuando ya se disponen de claves para otras herramientas y pregunta si no se pueden utilizar las mismas credenciales. Perfectamente lógico, pero se acaba de abrir la puerta a una integración con una tercera herramienta o sistema que habrá que analizar para comprobar si dispone de API, etc.
Por otro, lado alguien pregunta qué sucede si un usuario pierde la clave de acceso. En este caso se plantean diferentes soluciones para recuperar la contraseña (de nuevo más tiempo y más integración), alguien más indica que sería bueno saber en esa pantalla a qué se está accediendo y facilitar en el primer acceso un tutorial u on-boarding que facilite paso a paso la comprensión para el usuario (de nuevo, más ideas, más desarrollo, más recursos necesarios)…
Al final, una funcionalidad muy estándar y aparentemente sencilla puede acabar requiriendo cinco veces más de los recursos presupuestados, solo por haber dado por sentado que era una funcionalidad sencilla y no haber profundizado un poco más. Si este ejemplo lo aplicamos al resto de funcionalidades, algunas de ellas con una complejidad mucho mayor, las desviaciones acaban siendo la tónica general del proyecto y la implementación se convierte en un proceso totalmente caótico del que nadie sabe cómo se va a salir ni cuándo. De ahí que muchos proyectos de tecnología queden estancados, se dilaten o incluso nunca lleguen a ver la luz. Y todo eso suele originarse con un análisis de requerimientos pobre o flojo.
¿Cómo es el proceso de un buen Business Analysis?
Dependerá de la naturaleza y dimensión del proyecto, pero existe un esquema básico que prácticamente todos los proyectos deben seguir:
Definir la necesidad de negocio:
En este punto se evalúa el área, proceso, sus recursos (especialmente los perfiles profesionales y sus roles), las herramientas actuales que están envueltas, la documentación, etc Y se identifican los objetivos perseguidos con el proyecto para el negocio. Es crucial mantener una visión totalmente clara y compartida por el equipo del objetivo del proyecto.
Definir el alcance de la solución:
Implica estudiar y detallar los supuestos y limitaciones: En este punto se trabajan los supuestos y las limitaciones relevantes que pueden influir en el proyecto, por ejemplo aspectos legales, limitaciones técnicas o económicas, etc.
Análisis de Requerimientos:
Entendiendo la necesidad y conociendo el alcance de la solución se procede a elaborar el Análisis de Requerimientos, el documento que recogerá las capacidades declaradas por los diferentes stakeholders para la herramienta. No obstante, el análisis de requerimientos no es solo un repositorio de características, comprende la definición de los requisitos, describiendo el comportamiento de la solución con suficiente detalle para permitir que sean desarrollados. Además, debe priorizar las diferentes características, identificar incompatibilidades, incoherencias, etc. y pulirlas para que la solución, tal y como está descrita, no solo responda de la forma más eficaz a su objetivo si no que además sea totalmente viable.
Planificación de Proyecto:
El analista de negocio junto al Project Manager (en ocasiones ambos perfiles coinciden en la misma persona) deberán desplegar los requerimientos en una planificación de proyecto que permita asignar los recursos necesarios a la ejecución y calendarizar todas las tareas necesarias para su finalización.
Una vez arrancado el proyecto, el Business Analyst debe asesorar a los stakeholders involucrados en el mismo, aportando luz sobre la interpretación de los requerimientos llegado el momento de su implementación así como realizando nuevas evaluaciones a posibles nuevos requerimientos surgidos durante el proyecto.
Hoy en día son muy pocos los proyectos que una vez implementados no requieren de mayor actuación. La mayoría no solo requieren de mantenimiento como actualizaciones forzosas por evolución de sistemas operativos y hardware sobre el que trabajan, mantenimiento del backend o sistemas del proyecto, si no que además desde el primer momento en el que el proyecto es puesto en producción se debe diseñar un “road-map” organizado por versiones evolutivas “objetivo” a lo largo del tiempo. Estas versiones servirán para realizar un BA continuado sobre el proyecto, identificando mejoras, sus requerimientos y priorizándolos para organizar las diferentes futuras versiones.
En definitiva, el Business Analysis vendría a ser el proyecto que realiza un arquitecto previo a la construcción de un edificación, durante su construcción y a lo largo de la vida de la misma. Si bien es cierto que se puede ejecutar una edificación sin arquitecto, su ejecución siempre será mucho más arriesgada e incierta.
Contar con las características, los planos, el presupuesto y, especialmente con el análisis de un buen arquitecto, antes de iniciar la construcción, asegurará la viabilidad de la obra y mejorará notablemente el resultado final.
Guión de un documento de análisis de requisitos básico
A continuación proponemos un esquema muy básico de requerimientos, una herramienta que como mínimo deberá incluir los siguientes apartados para facilitar un estudio y elaboración de propuesta correcto:
1. Título del proyecto.
2. Fecha del documento. Aspecto muy importante ya que este tipo de análisis pueden permanecer tiempo en stand-by, y si se retoman hay que interpretar la información en un contexto temporal ya que las circunstancias o tecnologías pueden haber cambiado mucho dependiendo del tiempo transcurrido.
3. Autor/Responsable del proyecto, cargo y datos de contacto.
4. Descripción general. Definición del alcance general, el contexto del proyecto y del negocio en el que se va a implantar, porque se impulsa, dónde y cómo se utilizará, etc. Debe ayudar a alguien que no sepa nada sobre el proyecto, el negocio ni el sector a aterrizar claramente sobre el proyecto. Evitar generalidades o aspectos ambiguos. Un documento de requerimientos debe ser lo más concreto y directo posible evitando cualquier duda o inconcreción.
5. Objetivo principal del proyecto. ¿Qué debe resolver la solución?
6. Públicos y usuarios del proyecto. Definición de los públicos/usuarios del proyecto y descripción de su rol en relación a la plataforma. Es importante contextualizar cada tipología de usuario (para que alguien que no conozca el negocio pueda hacerse una idea del papel que desempeñan). Es muy útil incluir un diagrama de la relación entre los usuarios (si existen jerarquías, relaciones entre ellos, etc).
7. Áreas o departamentos en los que será implementado. Explicación de las áreas o departamentos en los que se utilizará la herramienta y los procesos en los que intervendrá la solución.
8. Requerimientos funcionales. De forma organizada y bien priorizada cada funcionalidad debe explicarse con el mayor detalle posible. Cada funcionalidad incluirá un título de funcionalidad y una definición precisa de qué debe realizar la herramienta en relación a esta funcionalidad. Si por ejemplo hablamos de una recogida de datos (formulario) debemos indicar los campos exactamente que debe recoger.
Es importante evitar generalidades, ya que pueden dar lugar a diferentes tipos de interpretación. Por ejemplo no es suficiente hablar de “Mapa de Navegación que indicará la ruta desde el punto de origen”, ya que un mapa de navegación puede incluir o no navegación visual, por voz, optimización de rutas, puntos intermedios, rutas sugeridas alternativas, etc. etc. En estos casos es mucho mejor incluir aquello que incluso pueda resultar evidente que dejar puertas abiertas a interpretaciones. Si hay aspectos que no se conocen indicarlo claramente para que se propongan alternativas.
9. Canales. Indicar si la solución se utilizará en dispositivos de escritorio, portátiles, móviles, wereables… esto ayudará a seleccionar las tecnologías y arquitectura técnica idónea para dar solución a los requerimientos.
10. Requerimientos técnicos. En este apartado indicaremos si existen requerimientos técnicos, aquí podemos ser más o menos precisos en función de si existe una tecnología en concreto que se desee utilizar o si se espera que sea el técnico o proveedor quien proponga en base a los requerimientos funcionales. También se deben indicar si existen requerimientos en materia de seguridad, alojamiento de la solución, etc.
11. Dependencias e integraciones técnicas. Indicar si existen dependencias con otras plataformas. Por ejemplo si se desea compartir información con CRM, ERP o implementar servicios o librerías de terceros. En tal caso se debería indicar la tecnología de estas plataformas y adjuntar información sobre las API de las mismas que posibiliten estudiar la complejidad de la integración.
12. Plazo de ejecución. Indicar si existe una fecha límite en la que la herramienta tenga que estar operativa.
13. Presupuesto. Opcionalmente se puede indicar si existe un presupuesto asignado al proyecto. Este dato normalmente no se facilita al proveedor, sin embargo, facilitarlo puede ayudarle a dimensionar el proyecto y proponer alternativas para ajustar los requerimientos a un proyecto ajustado al presupuesto disponible o simplemente descartarlo si entiende que es inviable para su estructura de costes ahorrando tiempo y esfuerzos para las partes.