¿Qué se espera en el 2014 para el Análisis de Negocio y la Administración de Proyectos?

Tendencias

Recién leí en BA times (http://www.batimes.com/elizabeth-larson/2014-trends-in-business-analysis-and-project-management.html)* un poco tarde por cierto, las tendencias anunciadas ahí para 2014 sobre Análisis de Negocio y Project Management. Les comparto algunas notas acerca de estas tendencias.

En general, la necesidad de Analistas de Negocio y Project Managers como consultores de confianza para la ejecución ya sea de proyectos tradicionales o de proyectos ágiles sigue en aumento. Lo mismo puede decirse de las demandas de herramientas de comunicación eficientes y eficaces para balancear las necesidades de coherencia y seguridad de grupos de trabajo distribuidos:

1. El tema de Agilidad continúa en discusión.
El tema de Agilidad no parece disminuir. Las organizaciones están adoptando Agilidad como metodología de proyectos o al menos están utilizando algunos principios de scrum en sus proyectos. El apetito por grandes proyectos bajo el enfoque de cascada (waterfall) ha ido descendiendo.
Incluso el PMI en la Guía del PMBOK ® – 5 ª edición, lanzada hace un año, identifica diferentes opciones dentro del ciclo de vida de proyectos tomando en cuenta los enfoques de cascada, ágil, y cualquier otro enfoque relacionado. Aun aquellos PMs que no han utilizado el enfoque ágil, se sienten más cómodos con la idea de que muchas de las herramientas y técnicas que les han funcionado bien en el pasado, pueden aplicar en todo tipo de proyectos. Han encontrado, sin importar el enfoque del proyecto, que el descomponer los proyectos en subproyectos o proyectos más pequeños es más fácil de vender y controlar. Saben del costo que representa el definir y controlar muchos proyectos grandes y saben también que sus stakeholders prefieren ver pequeños entregables lo antes posible. No es Agilidad de hecho sino una mayor cantidad de proyectos pequeños que resonará con mayor fuerza entre los stakeholders.
El mundo de análisis de negocio se encuentra igual de entusiasmado al respecto, con la liberación, en 2013, de la Extensión Agil a la Guia BABOK v2.0. Incluso la versión 3.0 del BABOK que saldrá en 2014 tendrá una perspectiva de Agilidad y no será sorpresa si el IIBA anuncia alguna sub certificación de “Practicante Ágil” parecida a la ACP (Agile Certified Practitioner) del PMI.

2. Los Casos de Uso resurgirán, particularmente para proyectos ágiles.
Aunque muchos proyectos tradicionales han favorecido la utilización de los casos de uso en los últimos años, recientemente se ha notado un brote de interés de los casos de uso en proyectos agiles. Normalmente se utilizan las historias de usuario como técnica para documentar a un alto nivel de detalle los requerimientos en un proyecto ágil, sin embargo para poder estimar y planear el sprint, se requiere elaborar en mayor detalle la historia. Muchos equipos ágiles han empezado a darse cuenta que una técnica efectiva para esto, es el caso de uso, la cual proporciona información crítica muy importante con una estructura ideal para documentar la historia de usuario más rápida y completamente.

3. El Análisis de Negocio más enfocado al diseño.
Una tendencia que continuará en 2014 es el concepto de que el trabajo de análisis de negocio involucra Diseño. Mucho del trabajo del analista de negocio es la confección de soluciones, por lo tanto resulta natural pensar que es un trabajo de diseño. En el desarrollo de la versión 3 del BABOK a ser liberada en 2014, El IIBA ha destacado la importancia del “Diseño” y describe el diseño como “la representación utilizable centrada en la solución y en comprender cómo genera valor”.

4. Aumento del uso de la “nube” y la necesidad de análisis de negocio en la elección de soluciones en la nube.
El cómputo en la nube continuará teniendo el atractivo de reducir la inversión en infraestructura y operaciones. Sin embargo, las organizaciones se han sentido especialmente ansiosas acerca de la seguridad y privacidad por tener información de la organización y de los proyectos almacenada fuera de su dominio y expuesta en otros ambientes. La necesidad de hacer que la información esté fácilmente disponible a miembros de equipos distribuidos, va a continuar y superar estas preocupaciones en los próximos años.
A pesar de estas preocupaciones, la disposición de las organizaciones de analizar sus requerimientos de seguridad y alinear esos requerimientos a soluciones potenciales en la nube hará que las características de seguridad aumenten, así como la necesidad de un mayor análisis de todos los requerimientos antes de invertir en nuevas soluciones en la nube. El crecimiento de la nube ha generado una gran cantidad de opciones a las organizaciones de tal forma que con el fin de maximizar la inversión y alcanzar el mayor valor, las organizaciones utilizaran análisis de negocio para evaluar probables soluciones en la nube.

5. Mayor conexión y menos correo electrónico.
La falta de compromiso de los empleados es un tema candente en estos días y los costos son tan importantes en los proyectos en esas organizaciones como lo son para cualquier otra organización en general. Además, muchos si no es que la mayoría de proyectos utilizan grupos de trabajo geográficamente distribuidos haciendo considerable los obstáculos para lograr un mayor compromiso. Se espera que tanto los Project Managers como los Analistas de Negocio inviertan más tiempo y hacer un esfuerzo para conectar con stakeholders y miembros del equipo. Afortunadamente actualmente existen muchas herramientas de comunicación síncronas de audio y video y continúan incrementándose, lo que hará que el uso del correo electrónico sea un medio menos utilizado gradualmente.

6. El análisis de negocio se enfocará en primero comunicar y después documentar.
Mas organizaciones se han dado cuenta de que el analista de negocio genera más valor cuando tiene habilidades excepcionales de escuchar, observar, cuestionar y comprobar las necesidades reales, en lugar de simplemente producir documentación. Estas habilidades también incluyen las de influir en los stakeholders con el fin de lograr la participación que se necesita de ellos para el entendimiento y aceptación de la solución recomendada. Aún más, deben ser capaces de comunicar los resultados del análisis de tal forma que promueva el entendimiento, aceptación y compromiso de los stakeholders.
Cada vez más, las organizaciones optarán por generar sólo la documentación necesaria, dándose cuenta que será más efectiva una mejor comunicación dirigida al grupo de trabajo y/o a los stakeholders que un documento de requerimientos de 500 páginas.

7. Los Project Managers se enfocarán más en la gestión de requerimientos.
El PMI ha mostrado un gran interés en las actividades de requerimientos. La expansión continua de la sección de Recolección de Requerimientos en la Guía PMBOK 5 edición así como la creación de la Comunidad de Practica de Requerimientos del PMI (COP, por sus siglas en inglés) con su gran cantidad de webinars y artículos en gestión de requerimientos ha impulsado a los Project managers a verse inmersos en actividades de requerimientos.

Espero que este resumen de tendencias de 2014 les sea de utilidad y como siempre, les invito a dejar sus comentarios y compartir su opinión. Saludos.

* 2014 Trends in Business Analysis and Project Management escritas por Andrea Brockmeier, PMP, Vicki James, PMP, CBAP, Elizabeth Larson, PMP, CBAP, CSM, and Richard Larson, PMP, CBAP

¿Cuánto gana un Analista de Negocio?

Con frecuencia nos llegamos a hacer esta pregunta: ¿Cuánto gana un analista de negocio? o ¿Cuánto debería ganar? En realidad, así como pasa con otras muchas profesiones, el salario de un analista de negocio se ve influido por una serie de factores que en la mayoría de las veces está fuera de nuestro control. Factores tales como el país, el sector económico, el nivel educativo, la edad, los años de experiencia, el género, etc. han demostrado ser elementos que afectan de un modo u otro la percepción salarial de especialistas y profesionistas y los analistas de negocio no son la excepción.

Recientemente el IIBA® (International Institute of Business Analysis) publicó la encuesta de salarios de Analistas de Negocio de 2013.

Esta encuesta es realizada desde 2009 por el IIBA® y es la primera encuesta de la profesión de Analistas de Negocio realizada y mantenida exclusivamente por el IIBA® para beneficio de los practicantes del análisis de negocio. Está diseñada para obtener información de todas las clases de practicantes de análisis de negocio sin importar su nivel de experiencia o acuerdo de empleo.

He aquí un resumen de esta encuesta, la cual publico aquí para beneficio de mis colegas que me hacen el favor de seguir mis publicaciones en este blog, espero les sea de utilidad.

Encuesta de Salarios 2013 del IIBA® (Salary Survey 2013) – Resumen

El Reporte de la Encuesta de Salarios 2013 incluyó encuestados de más de 60 países a nivel mundial. Los 7 países con mayor participación incluyeron más de 50 encuestados y a esos países se les realizó un análisis de ingresos adicional.

La distribución de los 7 países con mayor participación en la encuesta fue: Estados Unidos (49.7%), Canadá (15.8%), Australia (8.6%), India (4.7%), Reino Unido (4.4%), Nueva Zelanda (4.0%), Sudáfrica (3.5%) y Otros países – México incluido – (9.2%). La participación total fue de 62 países.

Participacion de Paises

Algunos datos adicionales acerca de esta encuesta:

• La encuesta se envió a más de 50,000 profesionales del análisis de negocio, aproximadamente 54% de ellos son miembros del IIBA®.
• La encuesta fue contestada por 2,085 analistas de negocio de los cuales el 74% son miembros el IIBA®.
• Más del 80% de los encuestados contestaron que trabajan de forma remota al menos una parte de su tiempo.
• Solo 14% de los encuestados indicaron que sus jefes esperan más de 40 horas de trabajo a la semana para considerar una retribución salarial completa.
• Más del 89% de los encuestados se encuentran en un rango de edad entre 26 y 55 años, ubicando a la mayoría de ellos entre los 36 y 45 años.
• La distribución de género de los encuestados fue: Hombres 52%, Mujeres 47% con un 1% sin respuesta. Australia, India, y el Reino Unido tienen una mayoría significativa de encuestados hombres.

Distribucion por Género

• En los 7 países de mayor participación, con excepción de India, tienen un nivel educativo de licenciatura. En India la mayoría de los encuestados tiene un nivel educativo de Maestría o MBA.
• La mayoría de las personas encuestadas tienen entre 7 y 10 años de experiencia como analistas de negocio
• Más de la mitad de los encuestados no tiene una certificación en BA o alguna certificación en particular
• Casi el 50% de los encuestados pertenecen a la industria bancaria, de seguros y de tecnología
• Aproximadamente 60% de los encuestados indicaron un incremento salarial durante 2012

Conformación de la Industria

Análisis de Ingresos por país

Estados Unidos

• Salario Promedio anual: $91,512.00 Usd. (El doble del salario promedio en USA)
• Años de Experiencia: Más del 70% de los encuestados tienen entre 4 y 15 años de experiencia
• Edad: Parece haber una interrelación entre la edad y el salario. Hasta los 46-55 años el salario se incrementa en función de la edad. Después empieza a decrecer para los de 55-65 años y mayores de 65 años.
• Nivel de educación: El nivel de educación se relaciona directamente con el salario promedio. Hay una pequeña diferencia entre los diferentes niveles de educación College, Bachelor y Master en incrementos entre ellos del 10% aproximadamente.
• Distribución de Género: 55% mujeres y 44% hombres. El salario promedio de las mujeres está aproximadamente un 7% por debajo del salario de los hombres.
Otros datos
• El salario promedio se incrementó casi en un 10% de la encuesta de 2010, de $82,493 pasó a $91,512. Esto es casi 3 veces el incremento del costo de vida (3.6%) en el mismo período.
• El porcentaje de encuestados hombres se incrementó de un 40.8% en 2010 a un 43.6% en este año.

Australia

• Salario Promedio Anual: $111,949.00 Usd. (más del 30% por arriba del salario promedio australiano)
• Años de Experiencia: Casi el 70% de los encuestados tienen entre 4 y 15 años de experiencia Edad: Hasta los 46-55 años el salario se incrementa en función de la edad. Después empieza a decrecer.
• Nivel de Educación: No relacionado directamente al salario promedio. La experiencia y la edad tienen una gran influencia en los salarios altos
• Distribución de Género: 40% mujeres y 60% hombres. El salario promedio de las mujeres está aproximadamente un 8% por debajo del salario de los hombres

Canadá

• Salario Promedio Anual: $88,985 Usd.
• Años de Experiencia: Más del 70% de los encuestados tienen entre 4 y 15 años de experiencia
• Edad: Hasta los 46-55 años el salario se incrementa en función de la edad. Después empieza a decrecer.
• Nivel de Educación: No relacionado directamente al salario promedio. La experiencia y la edad tienen una gran influencia en los salarios altos
• Distribución de Género: 48% mujeres y 52% hombres. El salario promedio de las mujeres está aproximadamente un 7% por debajo del salario de los hombres

India

• Salario Promedio Anual: $18,086 Usd.
• Años de Experiencia: Más del 90% de los encuestados tienen entre 4 y 15 años de experiencia
• Edad: Los salarios se relacionan directamente con la edad
• Nivel de Educación: Casi un 98% de los encuestados tienen una licenciatura o una maestría. El salario promedio se incrementa 3% con una maestría
• Distribución de Género: 17% mujeres y 83% hombres. El salario promedio de las mujeres está aproximadamente un 36% por debajo del salario de los hombres

Nueva Zelanda

• Salario Promedio Anual: $85,059 Usd.
• Años de Experiencia: Existe mucha variedad en los años de experiencia. Nueva Zelanda tiene los años de experiencia más balanceados dentro de los países analizados. El salario promedio se incremente en función de los años de experiencia.
• Edad: La mayoría de los encuestados estaban entre los 26 y los 55 años de edad. El salario parece incrementarse dentro de las categorías iniciales y no parece estar tan directamente relacionado como en otros países.
• Nivel de Educación: Más del 50% de los encuestados tienen una licenciatura. Hay muy poca diferencia en salario dentro de los diferentes niveles de educación.
• Distribución de Género: 52% mujeres y 48% hombres. El salario promedio de las mujeres está aproximadamente un 9% por debajo del salario de los hombres

Sudáfrica

• Salario Promedio Anual: $57,893 Usd.
• Años de Experiencia: Existe mucha variedad en los años de experiencia. Tiene algún balance entre los años de experiencia donde la mayoría oscila entre 7 y 10 años.
• Edad: La mayoría de los encuestados se encuentran entre los 26 y los 45 años. El salario se relaciona directamente con la edad.
• Nivel de Educación: Más del 50% de los encuestados tienen una licenciatura. Existe una diferencia de aprox. El 12% entre los diferentes niveles de educación.
• Distribución de Género: 52% mujeres y 48% hombres. El salario promedio de las mujeres está aproximadamente un 5% por debajo del salario de los hombres

Reino Unido

• Salario Promedio Anual: $88,745 Usd.
• Años de Experiencia: Existe mucha variedad en los años de experiencia. Tiene algún balance entre los años de experiencia donde la mayoría oscila entre 7 y 10 años.
• Edad: Más del 90% están entre 26 y 55 Años. El salario parece se relaciona con la edad con excepción de un incremento importante en el rango de los 36 – 45 años. Puede ser debido a que en este rango más del 50% trabaja para el Sector Financiero y de Seguros
• Nivel de Educación: Más del 76% de los encuestados tienen una licenciatura. El tipo de industria parece tener un gran impacto en los salarios en lugar del nivel de educación obtenido (Caso del Sector Financiero y de Seguros).
• Distribución de Género: 31% mujeres y 69% hombres. El salario promedio de las mujeres está aproximadamente un 5% por debajo del salario de los hombres

Tendencias generales:

• Los años de experiencia tuvieron una correlación con los niveles de ingresos – el ingreso se incrementó en la medida que los años de experiencia aumentaban
• La educación tuvo también una correlación con los niveles de ingreso pero varió en función del país.
• La edad tuvo una fuerte correlación con los niveles de ingreso – el ingreso se incrementaba en la medida que la edad aumentaba hasta los 55-65 años y mayores donde se nota un decrecimiento del ingreso.
• Los poseedores de alguna certificación al parecer reciben los mayores niveles de ingreso en promedio, pero más de la mitad de los encuestados no señalaron ninguna respuesta a esta pregunta, de tal forma que no fue realizado un análisis detallado de ingresos basado en la certificación.
• Los encuestados hombres generalmente tienen una percepción salarial mayor que las encuestadas mujeres, con pocas excepciones. Esta tendencia deberá continuar – existen ligeras señales que indican que el sesgo de género podría reducirse con los nuevos practicantes que ingresen a la profesión, especialmente en los Estados Unidos.
• El promedio de salario se ha incrementado desde la última encuesta salarial y en algunos países a una tasa mayor que el incremento del costo de la vida.
• El Sector Financiero y de Seguros es el sector más popular en donde se encuentran los encuestados, seguidos del Sector de Tecnologías de Información.

Como siempre, les invito a dejar sus comentarios ya que es muy valioso el compartir su opinión con otros colegas y también conmigo mismo. Saludos.

¿Eres un Analista de Negocio o un Tomador de Pedidos?

(Tomado del artículo Are you a BA or a BOT?, www.modernanalyst.com
– Paul Mulvey)

Existen dos formas de ejecutar el análisis de negocios, cuál de ellas ejecutas tú?BOT4

  • tu única obligación en una junta de trabajo es tomar las notas
  • el negocio espera que escribas exactamente lo que te dijeron que quieren como      solución
  • tus usuarios corrigen tu gramática durante una revisión de documentos en lugar de concentrarse en el problema de negocio que quieren resolver
  • no retas al negocio para encontrar la causa raíz del problema
  • te enfocas en darle al negocio lo que quiere en lugar de entender lo que necesita

Si te has identificado con alguno de estos aspectos, tienes perfil de Tomador de Pedidos. ¡Pero no te espantes!, existen varias formas de evolucionar hacia una posición de analista de negocio desde la posición de tomador de pedidos. Algunas de ellas tienen que ver con la cultura de la organización ya que la organización no se da cuenta de lo que pasa cuando los analistas de negocio son tratados como tomadores de pedidos en lugar de analistas de negocio.

  1. Fallas en corregir el problema real

Supongamos que Ud. Es padre de una adolescente de 14 años y llega diciendo “Necesito un nuevo IPhone”. Los padres de adolescentes son analistas de negocio naturales, entonces cuando cuestionan la solicitud y la respuesta es que el teléfono actual no puede cargar las actualizaciones más recientes. Muy rápido entienden que el problema real no es el teléfono, sino el espacio para almacenar las actualizaciones. Por lo tanto ahora ya tienen una opción adicional – incrementar el espacio de almacenamiento.

Pero yendo más allá – ¿Por qué un teléfono que tiene 4 meses de adquirido tiene problemas de espacio? Cuando realizan la investigación y el análisis encuentran que no es la música la que está demandando gran cantidad de espacio, sino los 3.5Gb de autorretratos (selfies) tomados con la cámara del teléfono. Ahora tienen otra opción: administrar mejor el espacio, migrando las fotografías a una laptop de tal forma que libere espacio en el teléfono y permita que se carguen las últimas actualizaciones eliminando la “necesidad” de comprar un nuevo IPhone. Problema resulto. Resolviste el problema real en lugar de sólo registrar la solicitud de tu usuario (tu hija) e implementarla.

¿Resultado? El analista de negocio a diferencia del tomador de pedidos, proporciona valor a la organización (tu casa) reduciendo costos (meta del negocio).

Ahora imagine lo contrario – solo escuchas a tu usuario y compras el Nuevo IPhone. El problema real no se resuelve y después de comprar el IPhone, estás justo donde empezaste – nuevamente sin espacio para almacenar las actualizaciones del teléfono. Lo que nos lleva al segundo problema del tomador de pedidos, el cual es…

2. Gastas mucho más dinero porque al final, todavía tienes que corregir el problema real   

Si el tomador de pedidos simplemente toma el pedido para el negocio sin entender el problema, gastará más dinero porque tiene al final, necesitará implementar la solución correcta.

Supongamos que el negocio requiere un paquete de software CRM (Customer Relationship Management) para su área de negocio. Entonces, sin entender el problema real (punto de dolor) que están tratando de resolver, se compra el paquete. Entonces como la unidad de negocio encuentra que éste no funciona como su proceso anterior, solicita un proyecto de mantenimiento para adecuar el software (dinero), capacitar en el nuevo software (más dinero), nuevos equipos para mejorar el rendimiento del software (aún más dinero) y entonces al final terminan comprando una herramienta de ventas porque eso era en primer lugar, lo que realmente necesitaban para su proceso de concentración de ventas. Por lo tanto todo el trabajo para poner en funcionamiento el paquete de CRM y la adecuación, fue un desperdicio porque éste realmente no resolvía el problema.

Entonces en lugar de comprar la herramienta de ventas, compraron dos cosas: la herramienta de ventas y el software CRM. Y no solo eso, sino también los costos de adecuación, capacitación y nuevo hardware. Todo esto se pudo haber prevenido si su hubiera realizado un análisis al principio y entender los objetivos de la unidad de negocio en lugar de simplemente registrar lo que deseaban.

3. Los tomadores de pedido tendrán la culpa al final

Cuando tu simplemente registras lo que el negocio pide y no tratas de entender su problema real eventualmente el negocio regresará con el analista y no dirá “Oh, nos equivocamos al pedir un CRM cuando realmente necesitábamos una herramienta de ventas – fue nuestro error”, más bien dirá “Sr. Director General, nuestra unidad de negocio perdió dinero este año porque el analista de negocio creó una solución inutilizable por nosotros para hacer el trabajo.” Y aquí es donde te dan las gracias por haber trabajado en la empresa.

Entonces, ¿cómo quieres evolucionar a ser un analista de Negocio en lugar de ser un Tomador de Pedidos?  

Aunque hay varias formas de ser un mejor analista de negocio y existen una gran cantidad de artículos en internet con una vasta cantidad de tips y recomendaciones, aquí hay 4 en las cuales concentrarse a partir de lo ya comentado en este artículo:

  1. Entender el problema que el negocio quiere resolver. Si no conoces el problema, va a ser bastante difícil resolverlo. Como el IPhone, si el padre no hubiera entendido el problema, la solución no hubiera funcionado. Pregunta ¿Por qué? ¿Cuál es el problema? ¿Cuál es el punto de dolor que estás experimentando en tu área de negocio?
  2. Resolver el problema es realmente importante. Algo que realmente ayuda a ejecutar el trabajo a lo largo de toda la organización es una técnica conocida como Observación en su forma activa. A través de ejecutar las tareas tú mismo, obtendrás la experiencia de vivir el “dolor” que el negocio está experimentando. Tendrás mucha mejor idea de cómo éste afecta al trabajo del usuario del negocio y podrás idear soluciones y formas de realizarlo de manera más eficiente. Hacer las tareas “codo con codo” con el negocio también ayudará a establecer una buen relación con los usuarios de negocio y esto es muy importante para que sientan que estás ahí para ayudarlos y entender sus problemas en lugar de sólo transcribir información y documentarla. El tener a alguien diciéndote cómo algo toma mucho tiempo en lugar de arremargarse las mangas de la camisa e involucrarse con ellos en la forma de cómo ejecutan el trabajo son dos cosas muy diferentes. Mike Rowe en su programa de Dirty Jobs en Discovery Channels hace un estupendo trabajo entendiendo las tareas requeridas para cumplir con el mismo. Observe cómo establece una buena relación con sus usuarios en el show.
  3. Registra tus éxitos y explícaselos al negocio. Muchas veces los ejecutivos no comprenden que un Analista de Negocio es más que un Tomador de Pedidos. Para ser honestos, muchas veces la falta de la percepción de valor que tenemos es nuestra propia culpa – no le mostramos al negocio cómo hemos descubierto el problema real o cómo hemos identificado las alternativas de solución o cómo le hemos ahorrado al negocio X cantidad de dinero. Asegúrate de llevar un registro de lo que has identificado como analista de negocio y cómo has contribuido al éxito de la organización. Si el negocio pregunta por aquel, brillante IPhone de $750 Usd y tu muestras una alternativa de solución al migrar cientos de Gb de fotografías por solo $5 Usd, habrás creado una solución que le ahorró a la compañía $745 Usd, algo que vale la pena difundir y celebrar.
  4. Tener plantillas o patrones puede ayudar tremendamente a hacer las preguntas correctas con el fin de obtener excelentes requerimientos. Cuando tienes una lista enfrente de ti que te ayuda a recordar qué preguntar, te ayudará a llegar a un mejor análisis y ser un mejor analista de negocio.

Seguramente tienes tu propia forma de probar tu valor al negocio de las que aquí se describen. ¡Compártenos tus experiencias! y déjanos tus comentarios.

Evolucionando su carrera de analista de negocio a un nivel empresarial

Tomado de: BA Connection, Octubre 2013. Por: Maureen McVey, CBAP, Head of Learning and Development, IIBA

Arquitectura Empresarial: conjunto coherente de principios, métodos y modelos que son utilizados en el diseño y realización de la estructura organizacional de una empresa, los procesos de negocio, los sistemas de información y la infraestructura.” –Mark Lankorst, Enterprise Architecture at Work: Modeling, Communication and Analysis

En este artículo Maureen McVey no intenta hacer menos el arte del análisis de negocio y explica que existen diversos y diferentes títulos dentro de la familia de puestos de trabajo de la Arquitectura Empresarial: Arquitecto de Negocio, Analista Empresarial, Arquitecto de Soluciones entre otros, y expone su visión de lo que hay detrás de estas posiciones y cuáles son los conocimientos y habilidades requeridas para evolucionar a un nivel de arquitectura.

Dentro de estas habilidades esenciales menciona algunas como: Análisis y Solución de Enterprise ArchitectProblemas, Facilitación, fuertes habilidades de relaciones interpersonales y de consultoría, fuertes habilidades de comunicación, administración de procesos de negocio, liderazgo y pensamiento estratégico.

Indica que el Arquitecto Empresarial es un rol mayor y como su nombre sugiere es responsable del desarrollo, afinación y registro de la organización entera. Asimismo comenta que el valor que el arquitecto empresarial ofrece es optimizar los procesos y tecnología a través de eliminar tecnología redundante y optimizar recursos, y recomienda que para evolucionar a este rol, es importante solicitar participar en proyectos más grandes y complejos idealmente alguno que aborde la necesidad de normalizar los sistemas a lo largo de las diferentes áreas y departamentos de la organización.

Por otro lado, también menciona que existen varios enfoques para abordar las necesidades de la organización en un nivel empresarial y para ello debes entender alguno de las siguientes estructuras de trabajo: TOGAF (The Open Group Architecture Framework), SOA (Service Oriented Architecture); CMMI (Capability Maturity Model Integrated) y El Framwork de Zachman.

Por último, Maurren recomienda algunas lecturas y sitios relacionados:

Libros relacionados a Arquitectura Empresarial:

Sitio: IIBA Online Library (acceso sólo a miembros del IIBA)

  • Enterprise      Business Architecture: The Formal Link between Strategy and Results by Ralph Whittle and Conrad B. Myrick
  • Enterprise      Architecture A to Z: Frameworks, Business Process Modeling, SOA, and      Infrastructure Technology by      Daniel Minoli

Para mejorar sus habilidades políticas:

Webminar:

What’s Your Political Style? Learn Tactics for Career and Company Success presented by Rick Brandon, Ph.D.

Para mejorar su conocimiento acerca de cambio organización y evaluación de la disponibilidad de la organización, mejora de procesos como BPM  (Business Process Management) y Lean Sigma:

Accede este enlace: Best Practices for Better Business Analysis.

Para familiarizarse con: selección y administración de proveedores, benchmarking, crear un business case y afinar sus habilidades de negociación, conocer más acerca de cloud computing y outsourcing, sugiere leer los siguientes libros en la IIBA Online Library.

  • Business      Process Outsourcing: Process, Strategies, and Contracts, Second Edition by  John K. Halvey and Barbara M.      Melby
  • Business      in the Cloud: What Every Business Needs to Know About Cloud Computing by  Michael Hugos and Derek      Hulitzky
  • Practical      Negotiating: Tools, Tactics, & Techniques by  Tom Gosselin

Finalmente aclara que estas sugerencias son sólo algunos pasos fundamentales que puedes tomar en dirección a una posición de analista a nivel “Empresarial” y si estás involucrado en un proyecto de transformación de negocio de gran escala es deseable que cuentes con el apoyo de un mentor en arquitectura empresarial como sugerencia para ir en el camino correcto.

Para mayor información acerca de la carrera del analista de negocio y el rol de arquitecto empresarial visite el:  Career Road Map

Referencia: Fuente: Enterprise Architecture Good Practices Guide, How to Manage the Enterprise Architecture Practice by Jaap Schekkerman

Como siempre les invito a dejar sus comentarios.

Análisis de Negocio Ágil, ¿es esto viable?

logoSGconference4Las condiciones de mercado actuales, en el que se viven cambios rápidos y constantes,  están requiriendo a las compañías acortar los ciclos de vida para la entrega de productos y/o servicios y tener una mayor respuesta a las expectativas de los clientes.

Las metodologías de Desarrollo Ágil están liderando el camino, ayudando a los equipos de desarrollo de software a ajustarse a esta nueva economía. Estas metodologías retan nuestro concepto de mejores prácticas de ingeniería de software, de dirección de proyectos y de cómo liderar nuestros equipos. El movimiento Ágil impacta cada rol en un equipo de proyecto de forma diferente y crea oportunidades de aprender nuevas habilidades y desarrollar nuevas formas de trabajar juntos.

El desarrollo Ágil está teniendo un impacto significativo en la profesión del Analista de Negocio el cual puede jugar un rol clave en un equipo Ágil. Para ser exitoso, primero tiene que cambiar su forma tradicional de pensar acerca de los requerimientos, necesita considerar aprender nuevas habilidades para escribirlos y nuevas técnicas para gestionarlos. El éxito dependerá en gran parte de qué tan bien los Analistas de Negocio se adaptan a estas nuevas formas de trabajo con requerimientos, creación de equipos de trabajo y de colaboración en grupo.

Si te interesa este tema, te invito a votar antes del 30 de septiembre de 2013, por esta ponencia en la Conferencia Virtual de SG que se llevará a cabo el 23 de octubre próximo. Para votar, ¡da click en la imagen de este post!

¿Cuál es la trayectoria profesional del Analista de Negocio? (segunda de tres partes)

Analistas de Negocio Nivel Especialista Avanzado (Advanced Generalist BA)Advanced Business Analysis

Las personas que tienen roles dentro del Nivel Especialista Avanzado típicamente tienen un nivel más senior en la organización y trabajan con más ambigüedad, complejidad y un alcance más empresarial.

Dentro de este nivel se encuentran roles como:

Business Architec

Este individuo trabaja para construir y facilitar la arquitectura de negocio que apalanca las capacidades de la organización y el uso eficiente de los procesos, tecnología, datos y personas alineados a esas capacidades. El arquitecto de negocio define el modelo de negocio actual y futuro e influencía las interconexiones entre los procesos de negocio, tecnología, datos y personas, además, facilita la ejecución de esos componentes para llevar el rendimiento del negocio a lo largo de toda la organización. Él o ella ve patrones en los procesos, datos y tecnología que son comunes a lo largo de la empresa y facilita la ejecución eficiente de la operación del negocio a través de apalancar esos patrones.

BA Project Lead

La persona en este rol, es responsable del trabajo en un proyecto lo suficientemente grande para requerir la participación de varios analistas de negocio. Este individuo lidera el trabajo de otros analistas de negocio directa o indirectamente, con analistas de negocio internos o externos a la organización. El BA Project Lead asegura que el propósito del negocio sea realizado a través del trabajo de análisis de negocio del proyecto y que el mismo tenga la calidad suficiente para alcanzar los objetivos de la solución y entregar el valor de negocio esperado. El BA Project Lead colabora con el director de proyecto (PM) en la planeación y estimación de las actividades de análisis de negocio, el monitoreo de las actividades y procesos de análisis de negocio para una adecuada calidad, el  desarrollo de un plan de comunicación de análisis de negocio, la elaboración de un plan de administración de requerimientos y lograr el consenso y aceptación de esos planes, también aporta ideas a las normas de análisis de negocio que la organización apoya.

BA Program Lead

El BA Program Lead es responsable del trabajo de un programa o de un grupo de proyectos relacionados donde varios esfuerzos de trabajo están agrupados como parte de una iniciativa estratégica. Su función en el programa es llevar la planeación de las actividades de análisis de negocio, calidad de la solución, consistencia de los productos de trabajo y métricas de rendimiento de análisis de negocio. Lidera el trabajo de varios equipos de analistas de negocio directa o indirectamente, con recursos internos o externos. El BA Program Lead asegura que el propósito del negocio sea realizado a través del trabajo de análisis de negocio del programa y que este trabajo tenga la calidad suficiente para satisfacer los objetivos de la solución y entregue el valor de negocio esperado. La persona en este rol ayuda a los interesados (stakeholders) y miembros del equipo a asegurar que las métricas de calidad y rendimiento son parte de la solución, habilitando al dueño de la solución a administrar la solución después de que el programa se termine. Él o ella proporciona los estándares de análisis de negocio que la organización apoya.

BA Practice Leader

El BA Practice Leader es responsable de desarrollar y administrar las prácticas y estándares de análisis de negocio dentro de una organización. Esta persona puede liderar a una comunidad, centro de competencia, centro de práctica o centro de excelencia. Él o ella desarrolla los estándares que la organización apoya para el trabajo de análisis de negocio y asegura que los estándares son seguidos en la organización. Los BA Practice Leaders sirven como expertos internos de análisis de negocio y utilizan su amplia experiencia y recursos externos para la mejora continua de las prácticas de análisis de negocio dentro de la organización. Este rol puede realizar revisiones de calidad del trabajo de análisis de negocio. 

BA Relationship Manager

El BA Relationship Manager supervisa las relaciones entre el grupo de solución/proveedor/TI y el grupo de negocio/unidad/departamento. Él o ella gestionan las relaciones, fuentes de información (pipeline), el portafolio y la entrega de valor de negocio a través de soluciones al grupo de interesados (stakeholders). Este individuo trabaja para facilitar soluciones que no sólo beneficien a los interesados sino a la empresa como un todo.

Strategic Business Analyst

El Strategic Business Analyst trabaja con los líderes de negocio en identificar y aterrizar las iniciativas estratégicas llevándolas de la definición conceptual a la implementación y en la validación de los beneficios y el retorno de la inversión. El individuo en este rol guía la entrega de valor de negocio y la alineación a las iniciativas estratégicas de la organización. Él o ella trabaja en la elaboración de los casos de negocio y portafolios de la empresa para traer soluciones integrales que estén alineadas a la estrategia de la organización. El Strategic Business Analyst también trabaja a un nivel de alta dirección o consejo de administración para analizar los beneficios y riesgos de las potenciales decisiones estratégicas. Un Strategic BA trabaja a lo largo de ciclo completo desde el caso de negocio hasta la validación  de beneficios.

Analistas de Negocio Especializados

Los analistas de negocio especializados, realizan actividades de análisis de negocio utilizando un conjunto de técnicas estrecho. El conjunto de técnicas utilizado se relaciona directamente a un enfoque específico al realizar las actividades de análisis de negocio. Los roles especializados pueden no ser apropiados para todos los tipos de proyectos y alcances en el esfuerzo de trabajo ó pueden ser sólo apropiados para algunas tareas o esfuerzos de trabajo específicos.

Agile Business Analyst

El Agile Business Analyst realiza tareas de análisis de negocio utilizando técnicas que permiten un enfoque de entrega altamente iterativo, de identificación continua de requerimientos y definición de requerimientos just-in-time. El Agile Business Analyst se enfoca en la entrega eficaz de valor de negocio tan rápido como sea posible a través de la aplicación de prácticas ágiles, y principios y pensamiento lean. Algunas técnicas tradicionales de análisis de negocio comúnmente utilizadas en proyectos ágiles son: Acceptance and Evaluation Criteria Definition, Brainstorming, Estimation, Prototyping, Scenarios and Use Cases, Scope Modeling y User Stories. Otras técnicas aplicadas por la persona en este rol incluyen: Dynamic Product Backlog Management, Writing User Stories, Behaviour Driven Development (BDD) and Acceptance Test Driven Development (ATDD). El Análisis y Desarrollo Ágil continua evolucionando; en este momento no hay una lista concreta de técnicas y prácticas ágiles ampliamente utilizadas por la mayoría de los Agile Business Analysts. El Agile Business Analyst puede servir como el Product Owner sustituto; por ejemplo, representando al Product Owner con un equipo de desarrollo remoto. El Análisis de Negocio Ágil requiere de un avanzado nivel de flexibilidad y adaptabilidad en los procesos y técnicas utilizadas para realizar el trabajo. Un Agile Business Analyst también debe de usar la flexibilidad en su estilo de liderazgo, habilidades de facilitación y gestión de expectativas con compañeros y stakeholders.

Business Process Analyst

Un Business Process Analyst se especializa en realizar cambios a las organizaciones a través del análisis, diseño e implementación de los procesos de negocio que mantienen a la organización operando y la gestión de cambios a esos procesos. Los Business Process Analysts tienen competencias profundas para identificar el estado actual de los procesos, elicitar atributos útiles o nocivos para ellos, documentar modelos de los procesos y facilitar a los grupos de stakeholders llegar a consenso con respecto a los diseños de los procesos de negocio. Él o ella es también hábil en identificar impactos y vínculos hacia las estrategias del negocio, la organización y su gente, los datos y sus sistemas, reglas y políticas de negocio así como los activos físicos del negocio. Los Business Process Analysts usan técnicas que permiten la implementación exitosa de los cambios a los procesos de negocio con el fin de resolver problemas o explotar oportunidades. Estos analistas evalúan el impacto de los cambios a los procesos de negocio en las personas, sistemas, operaciones y administración y recomiendan nuevas capacidades de negocio para asegurar la mejora en el rendimiento. Este analista puede también especializarse en y usar modelado de procesos de negocio, herramientas de análisis y diseño de procesos y tecnologías de automatización de gestión de procesos de negocio.

Business Rules Analyst

Un Business Rules Analyst se especializa en realizar cambios a las organizaciones a través del análisis, diseño e implementación de las reglas de negocio que soportan a la organización y sus operaciones, a los procesos y decisiones clave y asimismo la gestión de los cambios a ellas. Un Business Rules Analyst tiene profundas competencias para elicitar, identificar, investigar, definir, documentar, cambiar e implementar reglas de negocio de una manera eficaz y maximizar su uso dentro de los procesos de la organización. Él o ella se especializa en entender cómo las reglas de negocio están determinadas y aplicadas, así como cuáles son las causas que las hacen cambiar y qué problemas y conflictos pueden interferir en su implementación eficaz. Este analista es también hábil en identificar impactos y vínculos a las estrategias de negocio, la organización y su gente, los datos y sistemas y los procesos y políticas de negocio. Los Business Rules Analysts utilizan técnicas que permiten la implementación exitosa de las reglas de negocio para resolver problemas o explotar oportunidades. Los Business Rules Analysts pueden también especializarse en herramientas de gestión y motores de reglas de negocio.

Business Systems Analyst

Un Business Systems Analyst realiza tareas de análisis de negocio a través de la especialización en entender el uso de las tecnologías de información (TI) por el negocio, ayudando a la tecnología a agregar valor al negocio. Él o ella entiende y se siente cómodo con una variedad de arquitecturas y plataformas tecnológicas, entiende de las capacidades de TI y cuales aplicaciones entregan diferentes capacidades en la organización. El Business Systems Analyst puede especializarse en un grupo específico de tecnologías o aplicaciones utilizadas por la organización y las especificaciones de cómo éstas, son utilizadas dentro de la organización. Este analista típicamente trabaja en proyectos integrando a la tecnología con procesos de negocio, reglas de negocio y datos de negocio para satisfacer los requerimientos de negocio.

Functional Business Analyst

Un Functional Business Analyst ejecuta tareas de análisis de negocio a través de la especialización en un producto tecnológico específico y sus características y capacidades funcionales. No son especialistas en procesos de la organización o uso de la tecnología sino en una tecnología específica independiente de la organización. Este analista consulta (interna o externamente) sobre los mecanismos específicos características y funciones de un software específico, comúnmente paquetes de software (COTS – Commercial of the Shelf) o Software ERP (Enterprise Resource Management). El Functional Business  Analyst tiene un profundo conocimiento del producto tecnológico y tiene experiencia en una variedad de contextos de implementación en diferentes organizaciones e industrias. Él o ella ayuda a las organizaciones y stakeholders a definir el uso e integración con otros sistemas e implementar las características y funciones del producto tecnológico para satisfacer los requerimientos de negocio.

Service Request Analyst

Un Service Request Analyst ejecuta tareas de análisis de negocio por medio de la especialización en el soporte a los stakeholders en una aplicación específica de sistemas, mantenimiento del sistema, y el manejo de consultas del usuario y mejoras al sistema. Este analista tiene un profundo conocimiento de una aplicación específica o grupo de aplicaciones que él o ella soportan, cómo los usuarios usan la aplicación y que otros sistemas se integran con la misma. Esta persona puede estar involucrada en proyectos donde los sistemas que él o ella soportan están siendo actualizados, integrados o mejorados como parte de una solución. Un Service Request Analyst puede conocer el uso de la aplicación por la tecnología y el negocio tan bien que él o ella lucha por identificar y articular las verdaderas capacidades que la solución requiere. La mayor parte del trabajo que este rol realiza está relacionado a requerimientos de servicio, consultas y problemas del usuario, requerimientos de mejora y problemas de producción. La complejidad y contexto permanecen dentro de un alcance simple de trabajo. Este perfil es referido con diferentes nombres y títulos en organizaciones y culturas diversas.

Conclusión

Como se puede ver, el análisis de negocio además de ser un rol específico, son un conjunto de prácticas interdisciplinarias que apoyan el trabajo de diferentes especialistas con el fin de hacerlo más eficaz en su ejecución. Visto de esta forma su aplicabilidad es universal, pero… ¿es esta una visión correcta?  ¿Comparten esta visión de la práctica que expresa el IIBA en su modelo de competencias? Les invito a dejar sus comentarios y opiniones.

¿Cuál es la trayectoria profesional del Analista de Negocio? (Parte 1 de 3)

BA Carreer PathConocer la trayectoria profesional para los practicantes del Análisis de Negocio es una importante pieza para la gestión estratégica de talento dentro de las organizaciones y también una herramienta muy útil para los practicantes del análisis de negocio. Los conceptos de trayectoria profesional,  propuestos en el Modelo de Competencias del IIBA – International Institute of Business Analysis esbozados a continuación, son modelos conceptuales que ayudarán a las organizaciones e individuos a entender que trayectoria y opciones de carrera están disponibles para los analistas de negocio.

Los profesionales de análisis de negocio entran a este campo desde una gran variedad de carreras profesionales y de educación. Las competencias y experiencias únicas de cada persona influyen en su habilidad para ser exitosos en el rol.

Las descripciones de los perfiles de analista de negocio que se detallan a continuación, proporcionan una excelente vista conceptual de qué tipo de puesto puede tener un profesional en análisis de negocio con poca o nula experiencia, o de los profesionales que llegan a este rol con mayor experiencia y que pueden encontrar que ya tienen muchas de las competencias que se discuten en este modelo y pueden entrar a la profesión a partir de un rol más especializado o de mayor nivel de experiencia.

La gráfica a continuación, representa la trayectoria profesional típica para un profesional del análisis de negocio.

Trayectoria Profesional BA

Las categorías generales que se manejan en el modelo son: Practicantes Genéricos (que corresponden a los perfiles típicos) y Practicantes Especialistas e Híbridos los cuales pueden ser a cualquier nivel de la organización, trabajando dentro de diversos niveles de detalle y competencias básicas.

Perfiles Genéricos

Analista de Negocio Nivel Principiante (Entry Level BA)

El analista Nivel Principiante es aquella persona nueva en el rol y que ha adquirido el conocimiento a través de alguna exposición previa o capacitación basado en La Guía BABOK® (BABOK® Guide). Él o ella entienden el rol y pueden enumerar y describir las técnicas y tareas más apropiadas. Un analista principiante no tiene experiencia práctica en el rol pero pudo haber estado expuesto al rol gracias a otras experiencias de trabajo. La persona en este rol trabaja bajo estrecha supervisión y/o siguiendo planes y procesos claramente definidos.

Perfil Principiante

Analista de Negocio Nivel Principiante Avanzado (Junior BA)

Un analista Nivel Principiante Avanzado tiene experiencia práctica limitada en el rol y utiliza el conocimiento adquirido en alguna experiencia práctica previa en el rol o capacitación basado en La Guía BABOK®. La persona en esta posición demuestra un conocimiento profundo del rol y de las técnicas y tareas del análisis de negocio. Él o ella típicamente requerirán ayuda de recursos con mayor experiencia para determinar que técnicas usar y cómo proceder para ejecutar exitosamente las funciones de análisis de negocio.

Perfil Principiante Avanzado

Analista de Negocio Nivel Intermedio (Intermediate BA)

Un analista Nivel Intermedio tiene años de experiencia práctica en el rol y trabaja independientemente en tareas y situaciones complejas. Esta persona tiene experiencia en seleccionar las técnicas más apropiadas para realizar las tareas de análisis de negocio en diferentes situaciones. Él o ella tienen una buena experiencia de trabajo en la mayoría, si no en todas, las áreas del análisis de negocio. Este perfil del rol es consistente con las aptitudes requeridas para la designación Certification of Competency in Business Analysis™ (CCBA™).

Perfil Intermedio

Analista de Negocio Nivel Avanzado (Senior BA)

Un analista Nivel Avanzado tiene años de profunda experiencia práctica y reiterada en el rol realizando análisis de negocio en diversas situaciones complejas. La persona en este rol conoce qué técnicas usar y qué influye en el uso de las diversas técnicas para cada tarea. Él o ella trabajan independientemente y pueden planear, supervisar o liderar el trabajo de otros en esfuerzos de trabajo y proyectos grandes. Este analista tiene un conocimiento profundo de la mayoría, si no de todas, las áreas de conocimiento del análisis de negocio. Este practicante es consistente con las aptitudes requeridas para la designación Certified Business Analysis Professional™ (CBAP®).

Perfil Avanzado

Perfiles Especializados

Analista de Negocio Nivel Especialista Avanzado (Advanced Generalist BA)

Un analista Nivel Especialista Avanzado realiza tareas de análisis de negocio a un nivel superior en la organización. Dentro de este nivel caen las categorías de Practicantes Especialistas ó Híbridos. Así como el analista genérico (principiante, principiante avanzado, intermedio y avanzado) el Analista Especialista Avanzado realiza una amplia variedad de actividades de análisis de negocio utilizando una serie de técnicas en diversas circunstancias. El perfil Analista Especialista  Avanzado es una extensión del Nivel Analista de Negocio Avanzado y puede ser comúnmente visto como el siguiente paso en la trayectoria del profesional del análisis de negocio. Estos roles no son la única opción después del Nivel Analista Avanzado pero son roles que mantienen al analista de negocio dentro del dominio del análisis de negocio.

Las personas que tienen roles dentro del Nivel Especialista Avanzado típicamente trabajan con más ambigüedad, complejidad y un alcance más empresarial. Estos perfiles requieren de una avanzada demostración de muchas de las competencias básicas para ejecutar eficazmente. La demostración avanzada de las competencias básicas es vista a través del contexto de cómo la competencia es utilizada; los indicadores de comportamiento permanecen sin cambio mientras el contexto dentro de los cuales la competencia es demostrada llega a ser retador para una ejecución eficaz.

Dentro de este rubro se pueden citar una gran cantidad de especialidades de la industria actual, como son: Business Architect; BA Project Lead; BA Program Lead; BA Practice Lead; Business Relationship Manager; Strategic Business Analyst; Agile Business Analyst; Business Process Analyst; Business Rules Analyst; Business Systems Analyst; Functional Business Analyst y Service Request Analyst. También aquí se clasifican algunos otros que son los roles híbridos como: BA/PM; BA/Tester; BA/Developer; BA/User Experience y existen algunos otros roles más que se traslapan con algunas otras especialidades de la industria como pueden ser el Database Analyst, Enterprise Architec, etc.

En la segunda y tercera parte de este artículo hablaremos con mayor detalle acerca de los perfiles que caen dentro de este rubro de Analista de Negocios Especialista Avanzado.

En que reflexionar

Es importante considerar que el Análisis de Negocio además de ser un rol, es también una disciplina – conjunto de normas establecidas para esta práctica – que  establece una forma de trabajo orientada a entender claramente la necesidad real del negocio y transmitirla adecuadamente a los siguientes en el proceso y que ejecutarán el trabajo y con esto asegurar alcanzar el logro de los objetivos de negocio. Por lo tanto su aplicabilidad en la industria es muy amplia sin importar el rol o profesión que se tenga.

Sus comentarios siempre son bienvenidos, Escríbanme y déjenme conocer su opinión!

¿Qué hace un Analista de Negocio?

EL rol del BAMuchas organizaciones usan el título de “Analista de Negocio” para describir a alguien que puede realizar múltiples roles en un equipo de proyecto (una especie de jugador emergente con habilidades de análisis de requerimientos, dirección de proyectos, desarrollo de software y ejecución de pruebas) ó como un director de proyectos Jr.

¿Cuándo se requiere a un analista de negocio?

El analista de negocio es un rol que se requiere con mayor frecuencia cuando se tiene que actuar como  enlace entre un grupo de stakeholders (cualquier persona o grupo de personas afectados por una iniciativa de negocio en una organización) con el fin de realizar un análisis que permita reducir cuestiones complejas a un nivel de simplicidad más manejable.

Cuando en un proyecto se trabaja con un gran número de stakeholders, es muy probable que estos entren en conflicto y frecuentemente exista confusión respecto a los requerimientos ya que cada stakeholder tiene diferente perspectiva de los problemas que enfrenta en la organización y diferentes prioridades con respecto a la solución.

Un reto importante

Muchas organizaciones no tienen claramente articulada una estrategia o toman decisiones que directamente contradicen los objetivos establecidos por la organización. Con frecuencia los diferentes grupos operativos tienen sus propias estrategias. Aun cuando los ejecutivos piensan que tienen una clara estrategia y están todos de acuerdo en ella, esa estrategia puede, de manera intencional o no, estar mantenida en secreto hacia los empleados y entonces aun cuando existe un entendimiento y acuerdo general de la estrategia, los empleados pueden legítimamente estar en desacuerdo respecto a las tácticas utilizadas para alcanzarla.

La función más importante: entender la necesidad real de la organización

Los problemas complejos nos obligan a descomponer el problema para entender a la organización y cómo sus diferentes componentes, grupos y procesos interactúan. De hecho éste es uno de los significados clave del término “análisis”. Analizamos el negocio con el fin de entender y ayudar a otros a entender cómo la organización está estructurada, cómo el trabajo se realiza y qué sistemas y funcionalidad es requerida para soportar este trabajo.

Desde el punto de vista estratégico, éste es el primer rol esencial del analista de negocio: dar claridad a las decisiones de negocio y asistir a los participantes a entender el rol que juegan respecto de los objetivos de la organización. El analista de negocio debe de estar preparado para actuar como facilitador para ayudar a los stakeholders a superar este reto.

Cuando se actúa como facilitador, un analista de negocio se enfoca primordialmente en ayudar a las personas a entender y articular sus propias metas, objetivos y soluciones. Un buen facilitador utiliza su experiencia como herramienta para ayudar a realizar preguntas comprobatorias diseñadas para descubrir problemas potenciales, sin embargo al final la responsabilidad de encontrar la respuesta correcta recae en los stakeholder del negocio.

La facilitación efectiva es un trabajo duro; tienes que ser eficiente y en asegurar que los conflictos surjan y sean resueltos de manera productiva, que todos los stakeholders tengan la oportunidad de expresar su opinión y que las decisiones se realicen en el mejor interés de la organización y no sólo con base en la opinión de la persona más influyente o con mayor conocimiento del dominio.

Finalmente sin embargo, el rol de facilitador es un rol de soporte y los analistas de negocio que buscan incrementar su autoridad e influencia deben de aprender a actuar también como consultores. No realizamos análisis únicamente para entender a la organización, realizamos análisis de tal forma que podamos utilizar la información colectada para descifrar que cambios requiere la organización con el fin de que que la organización alcance las metas y objetivos que se han establecido y entregar valor a sus stakeholders.

Tú necesitas, como analista de negocio, escuchar con el fin de entender cuáles son las necesidades reales de la organización porque si llegas a proponer algo que no satisface esas necesidades, estarás fallando en la ejecución del rol de analista de negocio.

Funciones del BA2

 

Otra función relevante del analista de negocio: administrar los requerimientos, especificar con calidad y con el suficiente nivel de detalle

Ahora, desde el punto de vista táctico, el analista de negocio debe de ser capaz de tener un adecuado control y administración de los requerimientos así como las habilidades necesarias para describir con precisión el trabajo que se requiere ejecutar para que los que siguen en el proceso (típicamente el equipo de desarrollo, en un proyecto de software) tengan toda la información necesaria para construir los componentes de solución con un adecuado nivel de calidad.

Para esto, el analista de negocio debe de tener las habilidades y conocimientos necesarios para poder especificar los requerimientos con el suficiente nivel de detalle, requerido según el auditorio objetivo al que va dirigido. Esto es, el nivel de especificación del requerimiento no es el mismo para el equipo de desarrollo que para el equipo de procesos o para el grupo de stakeholders. Dependiendo de a quién va dirigida esa especificación, el analista de negocio deberá de modelar los requerimientos de forma tal que el destinatario sea capaz de entender la información proporcionada y poder llegar al consenso y aprobación de lo que se va a construir.

Conclusión

El rol de analista de negocios no es un nuevo rol, ha estado ahí por años, sin embargo las habilidades requeridas han cambiado a lo largo del tiempo y ahora es necesario adquirir o desarrollar nuevas habilidades que le permitan enfrentar los retos que demanda el entorno actual.

Dos funciones básicas: En el plano estratégico, tener las capacidades necesarias para conocer el negocio y entender claramente la necesidad real de la organización en función de la estrategia e iniciativas de negocio. En el plano táctico tener las capacidades necesarias para tener un adecuado control y administración de los requerimientos y poder especificarlos con el suficiente nivel de calidad y de detalle que permitan asegurar que los que siguen en el proceso puedan realizar su trabajo.

Y uds. Amigos, que opinan?. Por favor les invito a dejar los comentarios y observaciones que consideren convenientes.

 

¿Es necesario mejorar los procesos de gestión de requerimientos?

bpi-processmappingDe acuerdo al ensayo de Shelley Cudly “Improving Business Analysis Processes”, solo un 25% de las empresas a nivel mundial operan con un alto nivel de madurez en sus procesos de gestión de requerimientos[1]. Las estadísticas relativas a las razones de porqué los proyectos fallan, apuntan a una abrumadora necesidad de mejora en los procesos de requerimientos y análisis de negocios. Los pobres niveles de madurez indican que las organizaciones no han resuelto el problema de la mejora de los procesos de análisis de negocio[2].


[1] Heembrock, P. Hittin the Mark: The Impact of Requirements Maturity on Project Outcome. IAG Consulting (2009)

[2] 70% de las organizaciones reconocen que los requerimientos son importantes para el éxito del proyecto pero fallan al tomar acciones apropiadas. Ellis, K. Diagnosing Requirements Failure. IAG Consulting (2009)

_________________________

Un mejor resultado de los proyectos es la preocupación principal de todos los involucrados en el trabajo del proyecto. De hecho debería ser la preocupación de la organización entera. La mejora de los procesos es una actitud mental que, una vez adoptada, creará el ambiente que continuamente generará valor y éxito en los proyectos.

La mejora de los proyectos y requerimientos significativa y duradera, no es simplemente el resultado de procesos sólidos sino también del desarrollo de las personas y sus habilidades para soportar esos procesos.

¿Por qué Preocuparse?  

¿Por qué invertir tiempo enfocándose a los requerimientos, las personas y los procesos que los soportan?  Si has leído acerca del tema de requerimientos seguramente te has encontrado con docenas de artículos que explican la fatal situación de los proyectos de tecnología. Se encuentra en todas partes documentación acerca de las fallas de la tecnología y existen muchos intentos de cuantificar la naturaleza de las fallas. Mientras ha habido algunos cuestionamientos acerca de cómo definir las fallas de los proyectos, la evidencia sugiere que es “una incapacidad para producir confiablemente resultados exitosos en los proyectos”[3].


[3] Diversos estudios definen la falla de un proyecto como cualquier desviación de la línea base del proyecto, lo cual podría decirse que desvirtúa los resultados.

_________________________

Planeación y programas mejorados

Mejores requerimientos conducen a una mejor planeación del proyecto, estimación de costos y estructuras de descomposición del trabajo[4] (WBS – por sus siglas en Inglés). Utilizando métodos establecidos de elicitación y una buena relación con los stakeholders conducen a un mejor entendimiento de los requerimientos los cuales requerirán pocos cambios a lo largo del ciclo de vida.


[4] La escasa especificación de los requerimientos es una de las causas de la pobre estimación de los costos del proyecto. Davis, A.M. 201 Principles of Software Development, New York. McGraw Hill. El promedio de proyectos con una pobre especificación de los requerimientos rebasan la cantidad de tiempo esperada en un 200%. Ellis, K. Things You Need to Know About Requirements Planning. IAG (2010)

________________________

Menos gasto / menos costo / menos retrabajo  

El retrabajo en los requerimientos atrasan el proyecto[5]. Los requerimientos descubiertos de forma tardía en el ciclo de vida conducen a excesos en el proyecto, el programa y costos del proyecto[6]. A la inversa, los proyectos con una alta calidad en los requerimientos tienen pocos cambios lo cual resulta en menos retrabajo y menos costos.


[5] Hay un 60% de prima adicional de tiempo y costo a pagar por proyectos con una pobre calidad en los requerimientos. Ellis, K. Assesing the Impact of Poor Requirements on Companies. IAG Consulting (2009).

[6] Los problemas de los requerimientos comprenden el 40% de todos los errores dentro de un proyecto y el costo de arreglar esos errores es muy alto contabilizando de un 70% a un 80% de costos de retrabajo. Leffingwell, D. Calculating your return of investment from more effective requirements management. 26 February 2011. Mientras más tarde se encuentre el error en el ciclo de vida mayor es el costo de reparar el error costando hasta 10 veces más si se corrige durante las pruebas y por encima de 100 veces más una vez que el sistema está en operación. Grady, R. An Economic Decision Model: Insights into Software Project Management. Tener correctos los requerimientos pronto en tu proyecto puede ahorrarte al menos un tercio del presupuesto total del proyecto. Hooks, I & Ferry, K. Customer Center Products: Creating Successful Products through Smart Requirements Management. New York (2001)

__________________________

Calidad en los requerimientos conduce a calidad en el software

Realizar cambios al código debido a requerimientos tardíos, resulta en el deterioro de la calidad del proyecto[7].


[7] Requerimientos faltantes y ambiguos contribuyen con un tercio del total de los defectos del proyecto. Lausen, S & Vinter, O. Preventing Requirements Defects: An Experiment in Process Improvement. Requirements Engineering Journal (2001). Los Procesos de los Requerimientos son la fuente de la mayoría (50% o más) de los problemas de calidad serios. Weinberg, G.M Quality Software Management: Anticipating >change. Dorset House Publishing Company (1997)

_________________________

Otras cosas que considerar

Mejorar el proceso de requerimientos es esencial y si la información anterior no le convence, he aquí algunos otros aspectos a considerar:

La documentación realizada no concuerda con la realidad

Cuando se tiene la documentación suficiente para soportar el esfuerzo de pruebas, esta frecuentemente no concuerda con la solución entregada por TI. ¿Porque? Porque nadie ha manejado los requerimientos después de que fueron inicialmente entregados o lo requerimientos fueron insuficientes o se incorporó información adicional al proyecto fuera del proceso de requerimientos. Con frecuencia los otros procesos del proyecto no están bien sintonizados y no existe una transferencia formal de los requerimientos o no existe una validación del entendimiento de su contenido. Sin una apropiada revisión y validación de los requerimientos y una administración subsecuente de los mismos, las actividades de los desarrolladores no siempre coinciden con lo que se está presentando en la documentación. Los ingenieros de pruebas no saben quién está en lo correcto o que es lo que hay que probar y no tienen tiempo para ordenar todo de forma que se concretan a hacer su mejor esfuerzo.

Muchos defectos en post-producción

Como puede imaginar, lo anterior no asegura que los módulos o las piezas de código serán probados a fondo y verá muchos defectos cuando ese código sea llevado a producción

La necesidad de negocio no se satisface

Algunos defectos no son considerados problema por el equipo de desarrollo (el código fue “diseñado” para hacer eso) pero sí son considerados como defectos por parte del usuario porque el producto no está entregando el valor de negocio que se requiere. El analista de negocio se dedica entonces a tratar de determinar porque algo fue diseñado y no está alineado con la necesidad de negocio y tiene que defender al área de TI, el proceso defectuoso y la entrega no adecuada. Enfrentar a clientes insatisfechos nunca es divertido. Hazlo suficientes veces y tu grupo de TI se ganara una mala reputación.

Conclusión

Cada organización tiene sus historias de proyectos dolorosos y entregas fallidas. Los procesos de proyectos bien sintonizados conducen a más proyectos exitosos, así que la pregunta de fondo es, ¿Por qué no preocuparse por la mejora de los procesos de gestión de los requerimientos?

Como siempre, te invito a dejar tus comentarios y observaciones.

 

¿Es el rol de Analista de Negocio un Nuevo rol?

Puente entre Business y ITMuchas veces el rol de Analista de Negocio – BA por sus siglas en inglés – es percibido como una “nueva profesión”, sin embargo ha estado ahí por décadas. Los analistas de negocio han trabajado por años en muchas organizaciones grandes y pequeñas realizando diferentes actividades tales como consultoría, desarrollo de requerimientos para aplicaciones de software, identificación y mejora de procesos de negocio y apoyando la gestión del cambio cuando las personas, procesos y tecnología en una organización se ven afectados.

Evolución de la profesión de analista de negocio

La profesión de análisis de negocio está cambiando. Innovaciones recientes como la adopción de la gestión de procesos de negocios – BPM por sus siglas en inglés – motores de reglas de negocio, computo en la nube y las plataformas de planeación de recursos empresariales – ERP por sus siglas en inglés – así como nuevas metodologías como las metodologías ágiles para el desarrollo de software  están empujando a la profesión más allá de la tradicional documentación de requerimientos obligándolos a convertirse en consultores más “enterados” respecto de las TI con la finalidad de comprender mejor el papel que la tecnología juega en los negocios. Ahora, los analistas de negocio tienen que pensar en TI como una de las varias formas en que pueden ayudar  crear valor para los stakeholders.

Evolucion del BA

¿Qué se requiere conocer ahora?

Para ser verdaderamente eficaces en el rol, los analistas de negocio deben de comprender una amplia variedad de técnicas de análisis conociendo cómo y cuándo aplicarlas y proporcionar a los stakeholders  una orientación útil para comprender cuales soluciones serán eficaces para su negocio. Los analistas de negocio eficaces requieren tanta educación y entrenamiento y requieren poner tanto tiempo y esfuerzo en perfeccionar sus habilidades como un buen Project manager (PM) o un buen desarrollador de software.

El BA exitoso II

En que reflexionar…

  • El análisis de negocio está aún madurando como una profesión, existe una gran variación entre lo que un analista hace en una organización y lo que hace en otra.
  • Como analista puede que no cuentes con las capacidades requeridas para enfrentar los nuevos retos y será necesario planear tus siguientes pasos con la finalidad de desarrollar estas nuevas capacidades y ser capaz de aportar valor a la organización y seguir siendo atractivo para tus empleadores.
  • Si tu juegas un rol de supervisor y eres responsable de guiar un equipo de analistas de negocio, necesitas entender cómo el rol ha evolucionado y que puedes hacer para ayudar a tus analistas a ejecutar mejor su función. Tendrás que pensar en las actuales habilidades de tu equipo de analistas y evaluar sus capacidades para desarrollarlas con la finalidad de asegurar que aportarán el valor que la organización está esperando que sean capaces de aportar.
  • Las organizaciones durante años han visto el rol del analista de negocio de una forma muy limitada y ahora bajo este nuevo enfoque es posible que se muestren renuentes a permitirte tener un rol mayor y tendrás que esforzarse  en ganar la confianza de tus stakeholders a través de un trabajo más eficiente y estructurado que demuestre que tus nuevas capacidades aportan valor a la organización.

Como siempre agradezco tu participación y comentarios.