Hace ya más de un año que se publicó la Guía para Análisis de Negocio del PMI (ver artículo), y medio año, aproximadamente en junio de 2018, que se actualizó la certificación de PMI-PBA (Professional Business Analyst) para alinearse, especialmente en cuanto a terminología, con esta Guía. Aprovechando esto, quería reflexionar en este primer artículo del año respecto a la situación actual del Análisis de negocio en las organizaciones.
Por cierto, que desde Netmind estamos preparando una infografía de la Guía, al estilo de las que ya hemos publicado para PRINCE2 Update 2017, o para la Guía del BABOK v3, entre otras. Tenemos muchas ganas de enseñárosla, ¡os avisaremos cuando esté lista! ????
Recordemos que esta certificación apareció en 2016 y surgió para dar respuesta a la necesidad de profesionalizar el análisis de negocio como factor clave de éxito en los proyectos. Según los informes Pulse of the Profession de PMI, los principales motivos de fracaso en los proyectos giran en torno a no aportar el necesario valor para negocio, requisitos incorrectos, prioridades cambiantes o mala comunicación.
Durante este tiempo, PMI ha pasado de los 1.400 certificados en PBA en junio de 2017 en el mundo, a 3.044 certificados actualmente (según la publicación PMI Today de PMI de enero de 2019), por otro lado existen 9.427 personas certificadas en IIBA CBAP (Certified Business Analyst Professional del International Institute of Business Analysis), en la que vendría a ser la otra gran referencia de Business Analysis en el mundo.
Un total, por lo tanto, redondeando, de unas 12500 personas certificadas en las dos certificaciones más reconocidas. ¿Son muchos o pocos? ¿Están estas certificaciones creciendo al ritmo esperado?
Pongamos en contexto estos datos: si vamos al mundo más waterfall, hay actualmente cerca de 900.000 personas certificadas como PMP en el mundo, y en agile, más de 100.000 personas en el mundo certificadas como Product Owner (sumando registros de, por ejemplo, scrum.org y scrumalliance.org). Estoy considerando los datos de Product Owner por su papel como responsable en scrum de maximizar el valor a negocio, y por lo tanto, el rol que cuenta con mayor peso en sus funciones de Business Analysis (ver artículo).
Está claro que las certificaciones no son un reflejo exacto de la situación de la profesión pues muchos profesionales no buscan estar certificados (quizás porque no le ven el valor… la reflexión respecto a porque pasa esto podría dar para otros muchos artículos). Pero aún así, me parecen pocos los analistas de negocio certificados, teniendo en cuenta el consenso existente respecto al análisis de negocio como competencia core en todos los equipos.
¿Por qué hablo de consenso existente? Son muchas las publicaciones en los últimos años que coinciden en esto, pero no me voy muy lejos: por ejemplo, el último informe de Pulse of the Profession de PMI que por cierto se llama “Success in disruptive times- Expanding the Value Delivery Landscape to address the High Cost of Low Performance”, incluye la madurez en la entrega de valor como un factor clave de éxito en los proyectos. A mayor madurez, conciencia y foco, mejores resultados en los proyectos (con independencia de si en nuestra organización trabajamos en agile, waterfall o sistemas híbridos). Para ello, entender cuál es el valor y asegurar que tenemos trazabilidad del valor en los equipos hasta el resultado final, es parte de las funciones de un analista de negocio. Pero también podría referenciar el Chaos Report donde incluye como factores de éxito la relación con negocio y valor, o la encuesta anual a CIOs de Deloitte donde la preocupación por mantener una relación de partnership con negocio y mejorar en el análisis del valor continúan siendo los principales focos.
¿Y por qué pasa esto? Me atrevo a intuir algunas de las causas:
- El Análisis de Negocio no es tanto un título como una competencia core que debería estar presente en todos los equipos. Es habitual que las funciones de análisis de negocio recaigan en diferentes personas dentro de una organización, algunas de ellas con responsabilidades cercanas a la estrategia, otras más cerca de la construcción y entrega de productos. Este hecho, provoca a veces desconocimiento y/o poco interés en profundizar en esta competencia.
- Quizás relacionado con el punto anterior, los equipos se focalizan en mejorar sus capacidades técnicas y de gestión. Tradicionalmente, el desarrollo de las personas en las organizaciones se ha focalizado en esas dos áreas, dejando el desarrollo de las competencias de análisis a la experiencia de cada uno o a hacer lo que nos dictan nuestros frameworks, métodos o herramientas. Se percibe el trabajo de análisis como la definición de requisitos, cuando realmente es un medio, no un fin en sí mismo.
- El concepto análisis de negocio suena en algunos ámbitos, especialmente en algunos sectores agile, a “viejuno”, a waterfall. Tengo varios artículos y conferencias en las que intento justificar por qué no es así, sino todo lo contrario. No hay agile si no se maximiza la entrega de valor a cliente. No hay entrega de valor si no disponemos de maneras de identificar, definir y medir el valor entregado. La competencia en análisis de negocio es clave para cualquier equipo ágil. Existen frameworks agiles como DSDM del Agile Business Consortium que explicita el rol de Analista como necesario en los equipos ágiles, incluso en Scrum es habitual ver algunas figuras dentro de los equipos que trabajan codo con codo con Product Owners para facilitar el acercamiento de los mundos de negocio y de la tecnología. Eso, en definitiva, es el trabajo de analista de negocio.
Quiero acabar este artículo con una definición clave del rol de analista: el analista de negocio es un agente de cambio. Posibilita los cambios en las organizaciones, asegurando que estos cambios aporten el valor esperado (resuelvan la necesidad) al negocio. Para las empresas, invertir en análisis de negocio es una apuesta segura, los datos avalan la mejora en los resultados. Para las personas, formarse en análisis de negocio nos va a ayudar a mejorar en nuestra profesión, con independencia de la función específica que realicemos.