lunes, 24 de mayo de 2010

¿Que es el Análisis de Negocio? (What is Business Analysis?)

Que es el Análisis de Negocio (What is the Business Analysis)


Es el conjunto de tareas y técnicas utilizadas para trabajar como enlace entre las necesidades de los Stakeholder, además de estructurar los requerimientos, procedimientos y políticas dentro de un a organización
así como las recomendaciones de solución que habiliten a las organización en alcázar sus objetivos y sus metas.

El Análisis de Negocio (Business Analysis) involucra el entendimiento de como la organización funciona para cumplir con su propósitos, y definir las capacidades que una organización requiere para proveer los productos y servicios hacía los Stakeholders externos. En esto se incluye la definición de las metas de la organización, como las metas se conectan a través de objetivos además determinar las acciones que deberá de emprender la organización para alcanzar las metas y objetivos, y definir como la organización interactua de manera interna tanto como externa.

El Análisis de negocio se ejecuta como parte del entendimiento de la situación actual de la organización (as is), la cual servirá como base para la posterior identificación de las necesidades de negocio. En mayor de los casos, sin embargo se ejecuta para definir y validar la solución que se provee a las necesidades, metas y/o objetivos.





El Análisis de Negocio deberá de analizar y sintetizar la información que se provee de un gran numero de personas, tales como clientes, staff, areás de TI y ejecutivos, el Análisis de Negocio es responsable de recopilar las necesidades de los stakeholder y evaluarlas conforme a las metas y objetivos que se persiguen, con ello se espera tener un orden en la implementación en función de las prioridades de la organización además de detectar la complejidad de cada una de las iniciativas que se proponen como parte de la solución.


El trabajo realizado como parte del Análisis de Negocio proveerá un medio de comunicación entre las partes involucradas, por lo que además cumple con la función de traducción entre las mismas, el Análisis de Negocio debe ser capaz de hablar en términos de dominio y términos tecnológicos.


Actividades

Análisis empresarial o Análisis de Negocio: Se enfoca a entender las necesidades claves del negocio, la estrategia así como las iniciativas que permitirán cubrir las necesidades. para lo cual colabora, como soporte a la organización, teniendo como objetivo reducir los costos, proveer información de calidad, habilitar la eficiencia de los equipos de trabajo además de ser un consejero para el cliente final. Para lo cual deberá de utilizar diferentes técnicas de modelado concentrándose en los elementos que dan mayor valor al cliente y removiendo todo aquello que no sea indispensable.

Recopilación de Requerimientos: como parte de las actividades de la Ingeniería de Requerimientos, la recopilación deberá de realizarse con alguna técnica, la finalidad es proveer las necesidades clave de los Stakeholder.

Análisis de requerimientos: esta actividad pocas veces se le da el tiempo requerido y en ocasiones ni siquiera se realiza. El análisis de requerimientos permitirá establecer la arquitectura del negocio(modelo de negocio) y como estos requerimientos serán incorporados a las operaciones de negocio, en este análisis hay que identificar los elementos que participan (entidades de negocio) sus responsabilidades y colaboraciones. Dentro de este análisis se deberá de estipular la prioridad de su implementación, es muy recomendable que dentro de este análisis se colabore con el arquitecto para identificar las características de calidad.



Comunicación de Requerimientos: Es la actividad en la que se dan a conocer los requerimientos y se acuerdan la prioridad de los requerimientos, esta comunicación se llevará en base a la metodología utilizada, la especificación de los requerimientos deberá de acompañarse de los modelos y restricciones que tienen que cumplir, en esta comunicación se provee el detalle de como este será implementado, por lo que se acompañara de las decisiones tecnológicas por parte del Arquitecto o líder técnico.



Evaluación de la solución y validación: Como parte de los acuerdos se deberá de revisar y evaluar con cada uno de los StakeHolder (en base a la matriz RACI) las especificaciones dadas por el Analista, con esta validación se establece la línea base que los equipos de trabajo utilizarán para la implementación.


Conceptos Claves


Domino : Un dominio es la área que se encuentra en análisis. Esta puede corresponder al entorno a la organización o unidades de negocio, en la cual se requiere hacer una mejora, generar eficiencia o documentar sus procesos actuales.


Solución: La solución es un cambio al estado actual de una organización que se hace con el fin de cumplir con los metas u objetivos de la organización, resuelve un problema o se toma ventaja de una área de oportunidad. El alcance de la solución mas corta que el alcance del dominio dentro del cual se requiere ser implementada, y sirve como base del alcance del proyecto (implementación de sus componentes).
Ejemplos de soluciones están: Desarrollo de aplicaciones a la medida, COTS (commercial off the shelf) productos disponibles en venta, mejora de procesos de negocio, establecer el governance del negocio (Reglas de Negocio), entre otras soluciones...
Requerimientos: 1 .- Una condición que necesita el stakeholder para resolver o alcanzar un objetivo, 2.- Una condición o capacidad que debe de proveer la solución o componente para satisfacer un contrato, estándar, especificación o cualquier otra formalidad impuesta.

El Termino "requerimiento" is uno de los que genera mas discusión dentro la comunidad de Análisis de Negocio, hay muchos debates entre lo que debe o debería de considerarse un requerimiento, y cuales son las características que debe de tener el mismo. Sin embargo en lo que todos concuerdan es que el requerimiento debe de ser bien entendido por todos los involucrados, estar libre de ambigüedad, tener un nivel de abstracción de acuerdo a la audiencia, este puede describir aspectos presentes, pasados o futuros que deben de cumplirse con el fin de lograr los objetivos.





martes, 11 de mayo de 2010

Determinar los Objetivos de la Iniciativa

Como parte de la primer sesión de trabajo es entender la iniciativa, en relación a los objetivos de la organización, llevándose a cabo con el champion de la iniciativa

[Champion es la persona que empuja con los sponsors la iniciativa y que tiene claro la visión de la misma para con los objetivos organización]

Para obtener información de valor se recomienda apoyarse de un cuestionario.
Ejmeplo:

¿Cuáles son los objetivos organizacionales que se buscan con la iniciativa?

¿Este objetivo es parte de los objetivos estratégicos del la Organización ?

¿Qué fue lo que motivo a crear dicha iniciativa?

¿El objetivo está marcado como: Corto, Mediano o Largo plazo?

¿Cuáles son las metas del negocio necesarias para alcanzar el objetivo (puntos que se deben de cubrir)?

¿Cuál es la geografía donde aplica las metas?

¿Como esperan medir los resultados?

¿Quienes o que áreas se involucran y que nivel (Alta, media, baja)?

¿Que hace falta a los servicios actuales para alcanzar las metas del negocio?

¿Cuáles son las restricciones existentes?

¿Cuáles son las Fortalezas, Oportunidades, Debilidades y Riesgos que se tienen hoy en día (SOWT)?

Si del resultado de la entrevista hay dudas o no es claro la visión, hay que sugerir hacer un estudio de los objetivos estratégicos de la organización y utilizar una técnica diferente por ejemplo la de "Pareto" para encontrar cual es el significado de la iniciativa y el valor esperado.

de otra manera, cualquier esfuerzo aplicado será tiempo y costo mal invertido

Al empezar a entender cual es valor que tiene la iniciativa para con el negocio, sabremos como orientar las entrevistas o talleres con los siguientes stakeholder

recomiendo lean un poco sobre Objetivos Organizacionales



Caso de Uso


En la ingeniería de desarrollo de software, el Caso de uso (Use case) es la especificación por excelencia que se utiliza para comunicar los requerimientos funcionales del cliente hacia los equipos de desarrollo y pruebas, teniendo como autor de ello a los Analistas de Sistemas.

Historia

Ivar Jacobson utilizaba una técnica para capturar los escenarios de negocio; estos escenarios describen la interacción entre el actor y el sistema para cumplir un objetivo de negocio.

En 1986 con la integración de Rational Unified Process se establecieron los Casos de uso como estándar para especificación de los requerimientos funcionalidades de un sistema, eventualmente hubieron otros autores que colaboraron en la mejora de esta técnica, en los cuales se incluyen Kurt Bittner, Alistair Cockburn, Gunnar Overgaard y Geri Schneider.

Enfoque del Caso de Uso

El Caso de uso se enfoca a describir una actividad o funcionalidad del dominio(negocio), que es llevada a cabo dentro de un sistema de software.

La narrativa describe paso a paso la comunicación que tiene un actor y las respuestas que provee el sistema, con el fin de conseguir el objetivo
La actividad del dominio, también se le puede señalar como transacción de negocio, con ello se pueden establecer el alcance que deberá de especificarse en el Caso de uso.

Al narrar un escenario de negocio, es evidente que dicha narrativa deberá de estar expresada en lenguaje natural del dominio, por lo que deberá de ser entendible para el actor quien ejecuta, el caso de uso debe de estar libre de cualquier detalle de implementación, solución tecnológica o de usabilidad.
Un escenario o flujo de negocio persigue una y sola una actividad específica dentro del contexto del dominio, dentro de este flujo se incorporan los conceptos de negocio (entidades), relaciones y detalles que el propio domino establece para alcanzar el objetivo.

El flujo principal describe los pasos que el actor sigue para lograr el objetivo de una actividad, sin tener problema alguno para alcanzarlo.

Los flujos alternos serán aquellos pasos requeridos para completar la misma tarea, pero que por ciertas condiciones o restricciones, requieren de un tratamiento especial para lograr el objetivo

Los flujos de excepción son todos aquellos pasos que se realizan a consecuencia del incumplimiento de reglas de negocio, y por lo cual no permiten concluir la tarea, terminando en un punto distinto al planteado por la actividad de negocio.

El estilo con el que especifica el Caso de uso puede variar, en cuanto su redacción y terminología utilizada, esto se debe principalmente a las habilidades y destreza que tiene el analista para plasmar en el Caso de uso, como los requerimientos del negocio.

Sin embargo esta diversidad de redacción puede presentar dudosas interpretaciones a los diferentes tipos de audiencia que utiliza la información.

Por otro lado el nivel de abstracción puede variar, estando a juicio de la persona que lo especifica, sin embargo el nivel de detalle esperado, para cuando la información pase a los equipos de desarrollo y pruebas, debe de ser completa y sin ambigüedad de términos

Condiciones Inicíales

Condición previa que debe cumplirse para que pueda llevarse la ejecución del Caso de uso, recordando que el Caso de uso describe el escenario de una actividad de dominio, por lo que, las condiciones deberán de establecerse con el mismo enfoque.

Las condiciones establecen el estado previo de los conceptos de dominio que serán utilizados dentro de la narrativa de los flujos que describe el Caso de uso

Por ejemplo que el actor este autenticado en el sistema, puede quedar como parte de las guías de uso del sistema, ya que puede no tener valor respecto a la actividad de dominio que pueda describir.

Si por algún motivo no se puede establecer una condición previa desde el contexto de negocio, podrá ser valido el colocar:
"El sistema se encuentra en espera de... " (ver Ejemplo).

Condiciones Finales

Las condiciones finales, son aquellas que están delimitadas por el objetivo propio del Caso de uso, en particular la condición deberá de proveer un valor al actor que lo ejecuta, en estás se incluyen los estados finales de los conceptos de dominio.

Para el caso de los flujos que terminen en algo diferente que el objetivo, como son los flujos de excepción, se deberá indicar en la narrativa.

Flujos

Describen las posibles rutas por las cuales se logra el objetivo o se indican las excepciones




Limitaciones del Caso de uso
El caso de uso se enfoca a detallar la interacción que tiene un actor vs el sistema, desde una perspectiva de negocio, por ende, no provee de manera explícita las cualidades de servicios (Requerimientos no funcionales), además, con el nivel de abstracción que debe de tener el Caso de uso, no se espera que haya especificación de formulas, algoritmos, transformaciones, contratos de comunicación entre sistemas y otros. Para todo lo anterior el proyecto deberá de crear un documento suplementario, con el objetivo de completar los comportamientos y características del sistema esperados por el cliente.
  • Plantilla de Caso de uso: la plantilla no asegura la legibilidad o entendimiento de lo que se requiere transmitir, esto tiene una dependencia directa con las habilidades de quien escribe los flujos del caso de uso, además de la mecánica para acotar la operación que se pretende describir.
  • Interpretación del Caso de uso: existe una curva de aprendizaje por parte, tanto de los usuarios como de las personas que no hayan seguido un estándar; dejando a cada grupo de lectores su propia interpretación lo que dificulta el entendimiento del negocio.
  • Completitud de requerimiento del sistema: El caso de uso provee un 60% de los requerimientos a implementarse, considerando que el nivel de abstracción esta orientado a la perspectiva del negocio. Debido a ello, los equipos de trabajo (Desarrollo, Pruebas) deben de complementar las funcionalidades observadas en el Caso de uso, con la información de los anexos, modelos de dominio, diagramas e información suplementaria; y con esto cumplir con las expectativas del cliente. El Caso de uso será el artefacto a utilizar para encontrar toda la información que está asocia (relacionada); esto está dado por la trazabilidad.

Ejemplo


Caso de Uso Retirar efectivo del ATM (Automatic Teller Machine)
Objetivo El actor retira efectivo de su cuenta de bancaria
Pre-condición El ATM se encuentra en estado de espera de una nueva transacción

1.- El Casos de uso inicia cuando el cliente inserta su tarjeta en la ranura del ATM.

2.- El ATM lee el código de la cinta magnética de la tarjeta del cliente.

3.- El ATM solicita al cliente que ingrese su clave de identificación.

4.- El cliente ingresa los dígitos de su clave personal.

5.- El ATM verifica que la clave del cliente es correcta

6.- El ATM solicita al cliente que seleccione la transacción de una lista dada.

7.- El cliente solicita "retirar de efectivo".

8.- El ATM solicita al cliente que escoja de una lista la cantidad que desea retirar.

9.- El cliente selecciona la cantidad desea para retirar.

10.- El cliente confirma el retiro de efectivo al ATM.

11.- El ATM verifica que la cantidad a retirar no excede a saldo de la cuenta bancaria.

12.- El ATM dispensa la cantidad del efectivo solicitada por la ranura de salida de efectivo.

13.- El ATM registra el nuevo saldo de la cuenta bancaria del cliente por disposición de efectivo.

14.- El ATM imprime el recibo de retiro al cliente.

15.- El ATM solicita al cliente la terminación de operación de una lista de opciones

16.- El cliente selecciona el cierre de operación en el ATM.

17.- EL ATM regresa la tarjeta del cliente.

Fin de Caso de Uso


Flujos Alternos

2a.- El lector del ATM, no reconoce el código de la tarjeta introducida por el cliente. (Flujo de Excepción)

2a.1 El ATM regresa la tarjeta del cliente.

Fin de Flujo


5a.- El ATM detecta que el código ingresado por el cliente no es válido (Flujo de Alterno)

5a.1.- El ATM llevará la contabilidad de intentos de validación de la clave que ha ingresado el cliente.

5a.2.- El flujo continúa en el paso 3 del flujo principal.


5a.1a.- EL ATM detecta que se há realizado el tercer intento en la validación de la Clave del cliente sin exito (Flujo de Excepción)

5a.1a.1.- El ATM envía al cliente un mensaje de que la tarjeta fue retenida

5a.1a.2.- El ATM envía al cliente un mensaje con un número telefónico para seguimiento de retención de tarjeta

Fin de Flujo

.

.

. (Continúan otros flujos )



Lecturas recomendadas:

domingo, 9 de mayo de 2010

Quien son los Stakeholders

Cuando se comienza una iniciativa una de la primeras actividades a realizar es identificar a los Stakeholders.

Los Stakeholder son todas las personas involucradas directamente o indirecta a la iniciativa, para ello podemos utilizar el esquema del radar donde los ubicáremos y determinaremos el nivel de influencia que tienen hacia iniciativa.



Todo Stakeholder deberá de tener una responsabilidad dentro de la iniciativa, para ello debemos de crear un matriz (RACI) para ubicar nivel de responsabilidad y participación

RACI Matrix
Describe los roles que los Stakeholder que se involucran en las actividades de Análisis
Teniendo una o mas responsabilidades según las actividades o entregables

  • [R] Responsable de realizar el trabajo de especificación de los requerimientos
  • [A] (Acccountable) Responsable de la tomar las decisiones (solo uno)
  • [C] Requiere ser consultado para revisar la prioridades y dar las entradas
  • [I] Informarse de los resultado de cada actividad o entrega

(Ejemplo)
Change, Request, Process
RACI
Executive SponsorA
Business AnalystR
Project ManagerC
DeveloperC
TesterI
Application ArchitectC
Data ModelerC
Infrastructure AnalystC
Business ArchitectC
End UserI
Otros StakeholderR,C,I

Por el recuadro anterior podemos concluir que los requerimientos, si bien son definidos por algunas personas, estos deberán de ser consultados, validados e informados a los demás stakeholders, con el objetivo de que todos estén enterados y de acuerdo respecto a los requerimientos

Principalmente los requerimientos deberán de validar su factibilidad con los stakeholders respectivos

El contar con la matriz, proporcionará agilidad para obtener los requerimientos del usuario ademas, conocer quien deberá de tener la decisión de aprobar los requerimientos.

Hay una gran cantidad de proyectos que quien define los requerimientos no es el mismo de quien los aprobará, por lo que en dicho caso se recomienda levantar un riesgo (critico) y proponer que se delegue la autorización de la aprobación, o bien, quien va aprobar el requerimiento sea quien lo defina, con el fin de que el tiempo empleado se realmente efectivo.

Este problema es conocido como la deficiencia de involucramiento del usuario en la iniciativa, que en varios reportes y benchmark son de los primeros factores de fracaso de los proyectos.

(Fuente: Standish Group Chaos Report, IAG BA Bechmark full report)

Plan de estrategia del Análisis de Negocio- parte 2 -

Actividades a desempeñar durante el Análisis de Negocio

  • Obtener el contexto del Negocio y de la iniciativa
    • Identificar la Arquitectura de la organización: sus unidades, clientes, proveedores así como sus responsabilidades y colaboraciones
    • Identificar las políticas, procedimientos y formatos que son o serán parte de la iniciativa
  • Identificar los objetivos organizacionales para con la iniciativa
  • Idetinficar los Stakeholders que se involucran en la iniciativa
    • Definir los Roles, responsabilidades y autoridades de los Stakeholders
    • Analizar la posición que tiene el Stakeholder respecto a la iniciativa
    • Identificar las necesidades de cada uno de los Stakeholder
    • Identificar el compromiso de colaboración para determinar las necesidades
      • Determinar el nivel de Autoridad (RACI Matrix)
  • Verificar el alineamiento de las necesidades para con el objetivo de la organización
  • Identificar la complejidad de las necesidades
    • numero de Stakeholder
    • numero de áreas de negocio afectadas
    • numero de sistemas de negocio involucrados
    • cantidad y naturaleza de riesgos
    • numero de recursos técnicos requeridos
  • Identificar los componentes (Funcionales /Modulares y Soporte) de la iniciativa

Decisión de estrategia a seguir en la iniciativa

  • Estrategia orientada a la Planeación - Esta estrategia esta orientada a minimizar la incertidumbre y asegurar que definición esta completa antes de ser implementada, Waterfall y Business process re-enguneering son estrategias típicas orientadas a la planeación, está estrategia se recomendada para proyectos muy estables y de complejidad sea baja.

  • Orientada al cambio - esta técnica se enfoca a entregables en un tiempo corto y que son e valor para el negocio, se estipulan iteraciones las cuales pueden tener mayor incertidumbre de cambio, esta técnica es preferible cuando el sistema busca una solución de manera incremental, la autorización de los requerimientos se encuentra en una sola persona y además es participante activo dentro del equipo, metodologías ágiles pueden ser ejemplos de estrategias orientadas al cambio, dentro de está estrategia puede tomarse la decisión de llevar documentación ligera, sin embargo el experiencia de los miembros de proyecto deberá de ser alta. y con mucha disciplina en procesos de desarrollo e integración continua

(fuente BABOK 2.0)

sábado, 8 de mayo de 2010

Plan de estrategia del Análisis de Negocio- parte 1 -

Se resume las actividades y tareas a realizar durante el análisis de negocio, este se deberá de llevar antes de entrar a una etapa formal de "Inception"

Contexto:
Se trata de llevar una iniciativa nueva dentro del negocio y el análisis se solicita a un tercero

1.- Evaluar los procesos actuales para la captura de los Requerimientos

  • Entender los procesos actuales y sus objetivos que persigue
  • Revisar la metodología y estándares que aplica el negocio para la toma de requerimientos
  • Evaluar las prácticas que se utilizarán en base al tipo de proyecto
  • Definir la estrategia a seguir para el análisis de negocio
  • Si no existen estándares el Business Analyst debe de asegurar colocarlos con el Stakeholder correspondiente particularmente con el PM o con el equipo de trabajo

2.- Información Inicial

  • Business Needs - las necesidades del negocio se obtendrán del problema o del área de oportunidad que se tienen en el negocio, hay que ubicar el riesgo asociado a cada una de las necesidades así como los tiempos en los que deberán de implementarse

  • Juicio Experto - Hay que ubicar los expertos de dominio y asegurar que las necesidades sean ubicadas en su contexto, los expertos pueden provenir de varias fuentes como Stakeholders, centro de competencias, consultores o grupos de la industria

  • Procesos Organizacionales: estos procesos pueden ser útiles para definir la estrategia del análisis de negocio, pueden incluir metodologías para el proceso de cambios tales como COBIT, Sarbanes-Oxley otros, las plantillas y estándares que pueden ser guía para la personalización del la iniciativa

3.- Acuerdos de operación
  • Formalizar el nivel de detalle de la documentación a entregarse que puede ir desde la entrega de documentos formales hasta la comunicación informal, el apropiado nivel de detalle que deberá de contener dichos documentos, esta formalización deberá de llevar a cabo en la definición de la estrategia
  • Establecer el proceso para la aprobación de los requerimientos
  • Establecer el proceso de Control de Cambio (CCB) y el criterio para ejecutarlo
  • Documentación requerida para transferencia de conocimiento
  • Priorizar los Requerimientos (Identificación de componentes de la iniciativa y su orden de implementación)
  • Comunicación con los Stakeholders
(Continuara... parte2)