netmind - introducción al business analysis

F O C U S Q U A L I T Y E X P E R I E N C E

Profesionalizando el análisis de negocio

Barcelona, febrero 2011

Oscar [email protected]

Profesionalizando el Análisis de Negocio

Introducción . ¿Qué es Análisis de Negocio?G ió d l Al D ióGestión del Alcance, Documentación y Verificación de los requisitosPlanificación del AnálisisTendencias

1® netmind, We Know IT, KnowIT y OfficeMind son marcas registradas por netmind, sl

Qué es el análisis de negocio

Un Analista de Negocio es un profesional que actúa como enlace entre el negocio, que tienen un problema o desea alcanzar un objetivo, y el equipo tecnológico que conoce cómo


g qimplementar soluciones técnicas.

Qué es el análisis de negocio

Necesidades de Negocio Soluciones tecnológicas

Mejora en eficiencia

Mejor comunicación con partners

Selección de paquete de software

Desarrollo de aplicaciones


Toma de decisiones

Adaptación a Nuevo mercado

Data Warehouse

Personalización de paquete

Roles en la definición de requisitos

Conocimiento de Negocio Conocimiento tecnológico

Expertoen la

materia

Equipo técnico

Analista de

negocio


Ciclo de vida del proyecto

8.Conduct post-

implementation review

1. Plan the project

2. Scope the project

3. Eli it l6

7.Implement

the solution

Project LifeCycle


Elicit, analyze and document requirements

4. Design asolution

5. Build orbuy thesolution

6.Test thesolution

8.Conduct post-


1. Plan the project

Papel del analista de negocio en un proyecto



3. Elicit, analyze and document

6.Test the

7.Implement

the solution

Project LifeCycle

Análisis - “QUÉ”


requirements

4. Design asolution


solution

Diseño - “CÓMO”

Qué es un requisito

1. Una condición o capacidad que necesita un interesado para solucionar un problema o alcanzar un objetivo.

2. Una condición o capacidad que debe cumplir o poseer una solución o componente de una solución para satisfacer un contrato, un estándar, una especificación u otros documentos formales impuestos.

3. Una representación documentada de una condición o ( ) ( )


capacidad como en (1) o (2).

IIBA BABOKTM v2.0

“Requisito”

Lista para la compra

PanCerealesLecheMantequillaZumo de naranja


Características de los requisitos

CompletoCCorrectoConcreto (No ambiguo)VerificableNecesario


FactiblePriorizado

Componentes de los requisitos

Componentes principales de los requisitos


Requisitos de negocio Necesidades esenciales del negocio independientes de la implementación

Categorías de requisitos

Requisitos funcionales (y no funcionales)

Requisito técnicos

Implementación de necesidades específicas:

Para el software: Comportamientos observables

Para procesos manuales:Descripciones detalladas de procedimientos

Requisitos en la implementación del Software,


hardware y redes para soportar las necesidades del negocio.

Los requisitos de negocio se descubren; los requisitos funcionales se diseñan.

8.Conduct post-


1. Plan the project

Categorías de requisitos




6.Test the

7.Implement

the solution

Project LifeCycle

Requisitos del negocio


requirements

4. Design asolution


solution

Requisitos funcionales (y no-funcionales)

Requisitos técnicos

Participantes y roles en el proyecto


Dirección

Dirección GeneralPromotor del ProyectoPromotor del ProyectoDirección del Proyecto


Expertos en la materia

Expertos del área de negocio Usuarios claveUsuarios claveArquitecto de NegocioPlanificador EstratégicoProduct Manager


Equipo técnico

Arquitecto de SistemasAnalista programadorAnalista programadorAdministrador de redesAdministrador de BDDiseñador gráficoDi ñ d d UI


Diseñador de UIReponsable de Seguridad TI

Soporte

DocumentalistaEspecialista enEspecialista en usabilidadFacilitadorAseguramiento de calidad


calidad

Introducción

Negocio vs tecnologíaR i iRequisitoRolesCiclo de vida





Papel del analista de negocio

8.Conduct post-


1. Plan the project

Requisitos en la transición (implementación)




6.Test the

7.Implement

the solution

Project LifeCycle

Obtener los requisitos

Analizar y documentar los requisitos

Comunicar los requisitos

Definir el alcance y el área de negocio


requirements

4. Design asolution


solution

Verificar que la solución resuelve las necesidades

Identificar una solución

Definir el Alcance del ProyectoLa definición y documentación del alcance de los requerimientos es la MEJOR forma de

El Analista de Negocio debe trabajar con el Project manager durante las fases de inicio del proyecto para definir el alcance de los requerimientos o el área de estudioEl Analista de Negocio debe entender POR QUÉ el proyecto existe y cuales son los objetivos del proyecto

qasegurar el éxito del proyecto


cuales son los objetivos del proyecto.TODAS las unidades organizativas deben estar de acuerdo sobre el alcance del proyectoSólo se puede realizar un plan preciso si se tiene una clara definición del alcance del proyecto

Definir el Alcance del Proyecto

TareasClarificar el propósito y objetivos del

HabilidadesFacilitación

proyectoIdentifiar unidades organizativas involucradasIdentificar interfacesDeterminar qué procesos de negocio están dentro y fuera del alcanceIdentificar asunciones, riesgos,

Habilidad para documentar alcance en términos de negocioTécnicas de documentación


Identificar asunciones, riesgos, problemas y oportunidadesEstablecer el sistema para mantener la información del proyecto


Visión global de valor de la empresaRestricciones

VisiónMisiónValores

Business Drivers Externos

MercadosProductos

Cadena de Valor Clientes

Asunciones


Organización

Partners /Alianzas

Stakeholders

Expectativas


Cadena de Valor

Finanzas

RRHH

Sistemas de Información

Planificación Estratégica


I+D GestiónCatálogo Matriculación Servicio

al AlumnoEntregaPlanificación del curso

Data Flow Definition (DFD)


Training Scheduling

Project

INSTRUCTORSTUDENT

MANAGER

( )


STUDENTMEETING

ROOM RESERVATION

SYSTEM

8.Conduct post-


1. Plan the project

Gestión del alcance


3. Eli it l6

7.Implement

the solution

Change Control Process


Elicit, analyze and document requirements

4. Design asolution


6.Test thesolution

Obtener requisitos

TareasDescubrir de dónde sacar los

HabilidadesPreguntar las preguntas adecuadas

requisitosDecidir el enfoque para obtenerlosObtener TODOS los requisitos a nivel detalladoPriorizar requisitos

Escucha activaTécnicas de entrevistaTécnicas de facilitaciónTécnicas de registro de información y documentaciónHabilidad para categorizar los requisitos


requisitos

Obtener requisitos

Alta intensidad de comunicaciónEntrevistasWorkshopsWorkshopsInteracción, proactividad, escucha activa, …

Equilibrar expectativasNegocioFinancierasTecnológicasSeguridad


Seguridad…

Obtener requisitos

• Es necesario establecer un lenguaje común entre el g jnegocio y el equipo técnico


Obtener requisitos

• Hay muchos “estándares”• EPD• UML• BPMN• ISO• IDEF1X

…pero en este punto es prioritario asegurar la


prioritario asegurar la claridad de cara al negocio por sobre la adecuación al estándar

Analizar y Documentar los requisitos

TareasAnalizar cada requisito. Clarificar d d b i it bi

HabilidadesHabilidades de Análisis

dudas sobre requisitos ambiguosDeterminar el mejor formato para comunicar los requisitosDeterminar el nivel de detalle apropiadoNormalizar e instaurar directrices sobre documentaciónRealizar una documentación

Compresión de las metodologías de desarrollo de sistemasCompresión de las técnicas de análisis y de documentaciónUtilización de diferentes técnicas de documentación


Realizar una documentación completa de los requisitosCategorizar y empaquetar los requisitos

El paquete de requisitos y especificiaciones

Tabla de Contenidos

Inicio del ProyectoEnfoque y MetodologíaAlcance del Proyecto

Requisitos FuncionalesClases de Usuario/ActoresAlcance del área de DiseñoAlcance del Proyecto

PropósitoObjetivosProblemas y OportunidadesRiesgos de negocioAsuncionesInteracciones externasProcesos a alto nivelItems en el alcance

Stakeholders del proyecto y expectativasReglas y directrices sobre los requisitos

Glosario de términos

Requisitos de NegocioProcesos de NegocioRequisitos de Datos

Alcance del área de DiseñoWorkflowsFuncionalidad del SistemaDefinición de datosRequisitos del Interfaz de Usuario

Requisitos de Rendimiento y DisponibilidadRequisitos de SeguridadRequisitos de Calidad

Requisitos TécnicosRequisitos HardwareRequisitos SoftwareDiseño de procesos técnicosDiseño de base de DatosConversión de datosRequisitos sobre interfaces externas

Requisitos No Funcionales


EntidadesAtributosRelaciones

Reglas de Negocio

Requisitos sobre interfaces externasRestricciones técnicas

AnexosProceso de Gestión de CambiosRegistro de RevisionesAbreviaturas y acrónimos aprobadosTemas pendientes

Comunicar lo requisitos

TareasActuar como vínculo entre el

HabilidadesReuniones eficaces

negocio y el equipo técnicoTrabajo conjunto con el Project ManagerDirigir revisiones de requisitosPresentar requisitos para su aprobación

Presentaciones formalesEscritura de emails, memos, informes de estadoDirigir y documentar reuniones de revisión de requisitos


Identificar la Solución

TareasRecomendar cambios en los

HabilidadesComprensión del problema de

procesosAsesorar en el diseño de automatización de procesosAsesorar en la selección y adquisición de softwareAsesorar en el desarrollo de un plan de implantación

negocioComprensión a alto nivel de los procesos de desarrollo de softwareTécnicas para la evaluación de paquetes de softwareTécnicas de estimación de costes y beneficios


pCreación de Business Case

Verificar que la solución cubre las necesidades

TareasAsesorar en el desarrollo de casos de

HabilidadesComprensión a alto nivel de

testRevisar los diseños técnicosSoportar los test de aceptaciónInformar sobre defectos y variaciones respecto a los requisitos

conceptos de diseño de sistemasConocimiento de los principios de usabilidad de softwareCompresión de las técnicas y principios de testingHabilidad para escribir y revisar casos de test.



La finalización de los requisitos incluye asegurar que éstos sean estables y están correctamenteque éstos sean estables y están correctamente construidos. El Analista debe entender e influir sobre el proceso de testing, porque:

Mejora la calidad del paquetes de requisitosAsegura que el paquete de requisitos tiene suficiente nivel de detalle desde el punto de vista de TI y de QA


detalle desde el punto de vista de TI y de QAEs aconsejable que el Analista esté involucrado en algún grado en la prueba del software.



Qué hace un buen analista de negocio

Debe ser un gran comunicadorAtención al detalle, tanto en la investigación como en el registro yAtención al detalle, tanto en la investigación como en el registro y documentaciónConocimientos sobre organizaciónConocimiento sobre la tecnologíaCapaz de manejar gran cantidad de información en diversos formatos


Enfocado al clienteFlexiblePreparado con una gran caja de herramientas para descubrir los requisitos




Planificación del análisis

1. Identificar la información necesaria2 Identificar las personas y organizaciones involucradas2. Identificar las personas y organizaciones involucradas3. Determinar formato de la información de requisitos4. Determinar el tipo de proyecto5. Estimar el tiempo requerido6. Priorizar el trabajo en función de los objetivos y riesgos


7. Definir las herramientas de análisis

1. Información necesaria

Políticas y Procedimientos

Documentación de los procesos

existente

Entrevistas con agentes externos

Documentación de Software

existente

existente

Table of Contents

Project initiationProject approach or methodologyProject scope

Project statement of purpose Project objectives Project problems/opportunitiesBusiness risks Project assumptions Project external interactionsHigh level processesItems not in scope

Project stakeholders Requirements rules/guidelines

Glossary

Business requirementsBusiness processesData requirements

EntitiesAttributesRelationships

Business rules

Functional requirementsUser classes/ActorsDesign area scopeWorkflowsSystem functionalityData definitions User interface requirementsPerformance requirementsSecurity requirementsQuality requirements

Technical requirementsHardware requirementsSoftware requirementsDesign flowsDatabase designData conversion requirementsExternal interface requirementsTechnical constraints

AppendixChange Control ProcessRevision logApproved abbreviations and acronymsOutstanding questions/issues


Entrevistas con el equipo técnico Sistema de

gestión de cambios actual

Entrevistas con los SMEs

1. Información a recoger

Además el analista de negocio debe mantener información sobre:información sobre:

Actas de reuniones, entrevistas y sesiones de trabajoInformes, formularios y otras plantillas de documentación e informaciónCalendario y asignaciones.


Director de

2. Personas / Organizaciones involucradas

Analista de Negocio

Director de Proyecto

Subject Matter Expert


Miembre del equipo técnico

Miembro del equipo técnico


Expert


Informac. De negocio

3. Formato de los requisitos

Antes de iniciar el proceso de toma de datos, la estructura de los documentos de requisitos debe

Table of Contents

Project initiationProject approach or methodologyProject scope

Project statement of purpose Project objectives Project problems/opportunitiesBusiness risks Project assumptions Project external interactionsHigh level processesItems not in scope

Project stakeholders Requirements rules/guidelines

Glossary

Business requirementsBusiness processesData requirements

Functional requirementsUser classes/ActorsDesign area scopeWorkflowsSystem functionalityData definitions User interface requirementsPerformance requirementsSecurity requirementsQuality requirements

Technical requirementsHardware requirementsSoftware requirementsDesign flowsDatabase designData conversion requirementsExternal interface requirementsTechnical constraints

estructura de los documentos de requisitos debe estar acordada.

Texto/text estructuradoData model (ERD)Descomposición de procesosDiagrama de Flujo


qEntitiesAttributesRelationships

Business rules

AppendixChange Control ProcessRevision logApproved abbreviations and acronymsOutstanding questions/issues

Diagrama de FlujoDiagramas de Casos de UsoPrototipos

4. Tipo de proyecto

El tipo de proyecto determina el trabajo a realizar por el analista de negocio:

DesarrolloE-Commerce

Desarrollo de una nueva aplicación

Data Warehouse

Nuevo desarrollo de

negocio


Selección de paquete de

softwareParametrizaciónde un paquete

Evolución de aplicación

5. Dedicación y calendario

Es importante determinar los esfuerzos y plazos de forma precisa analizando variables como:de forma precisa, analizando variables como:

Número de procesos a alto nivelNúmero de entidades a alto nivelPersonas y perfiles necesariosPersonal y grupos a entrevistar / comunicar


…

6. Asignar prioridades

El análisis de riesgos de negocio y del proyecto facilitan que el analista de negocio permanezcafacilitan que el analista de negocio permanezca enfocado en el área adecuadaLos objetivos de los stakeholders son el auténtico drive del analista


7. Herramientas de análisis

NecesariasProcesador de textos

“Nice to Have”Modelado de datos

Herramienta de diagramación gráficaE-mailHoja de cálculoSistema de seguimiento de i id i

Modelado de procesosGestión de requerimientosTesting


incidencias

Amenzas en el uso de Equipos Virtuales

atio

n

ust

bSa

tisfa

ctio

n

Cla

rity

Res

ults

Invo

lvem

ent


Inno

va Tru

Job

-90% -80% -80% -60% -50% -47%

Fuente: Dr. Karen Slobel Lojeski. When virtual distance is relatively high:

El proceso de análisis

¿Qué metodología utilizaremos?E á l k h ld f ili i d ll ?¿Están los stakeholders familiarizados con ella?

¿Están claros todos los roles y responsabilidades?¿Está el proceso ajustado a ESTE proyecto?¿Están todo los entregables id tifi d ?


identificados?




Tendencias en el mercado

Más del 80% de los proyectos de implantación de software no consiguen los objetivos establecidossoftware no consiguen los objetivos establecidos en su principioCreciente especialización de los roles dentro del proyectoEquipos de desarrollo off site, off shore, subcontratados


subcontratadosUso de Metodología

The International Institute of Business Analysis (IIBA)

Organización profesional para los analistas de negocionegocio

Creada en Toronto (Canadá) Octubre 2003

Proporciona un foro para compartir conocimientoDesarrolla y mantiene estándares

BABOK™ (Business analysis body of k l d )


knowledge)Primera versión en Enero 2005

www.theiiba.org

The IIBA

VisiónLa asociación líder mundial para los profesionales analistas de negocio

MisiónDesarrollar y mantener estándares para


y pla práctica del análisis de negocio y para la certificación de sus practicantes

Qué es el BABOK

Recopila la suma de conocimientos dentro de la profesión de analista de negocioprofesión de analista de negocio

Capacidades asociadas, actividades y tareas

Refleja las prácticas comúnmente aceptadas

Gestionado y mejorado por los profesionales que lo aplican


BABOK: Contenido

IntroducciónPlanificación y seguimientoPlanificación y seguimientoObtención de requisitosGestión y comunicación de requisitosAnálisis de la empresaAnálisis de los requisitos


Evaluación y validación de la soluciónCompetencias subyacentesTécnicas

Certificaciones para analistas de negocio

Certified Business Analysis Professional (CBAP) –IIBAIIBA

Más de 1.000 profesionales certificadosEn el mercado desde el año 2006Experiencia mínima 5 años

BA Associate and BA Professional -B2T


Más de 4.000 profesionales certificadosEn el mercado desde el año 2002Es necesario probar experiencia para ser BA Professional

Nuestro papel

Co-fundadores del IIBA Partner exclusivo


Co-autores del BABOKPropietarios de las certificaciones BAA y BAP

Formadores certificadosDistribuidores de las certificaciones BAA y BAP

Oferta de Cursos

Cursos “Core” de Análisis de negocio y Certificación Courses for Business Analysis & Certification

Essential Skills for Business Analysis (4 días)Essential Skills for Business Analysis (4 días)

Detailing Business Data Requirements (3 días)

Detailing Process and Business Rule Requirements (3 días)

Otros cursos especializadosFacilitating Requirements for Business Analysis (3 días)

Requirements Validation (2 días)

Developing a Business Analysis Work Plan (3 días)


Developing a Business Analysis Work Plan (3 días)

Seminarios técnicos y de GestiónOverview of Business Analysis (Medio día)

Developer’s Introduction to Business Analysis (1 días)

• Iniciada en 2002• Prueba el conocimiento del

Business Analyst Certification

Business Analist y sus habilidades para REALIZAR el análisis

• Creado para ser “algo más” que un simple certificado de cumplimientos


• Más de 4.000 certificados

Resultados esperados

Soluciones orientadas al negocio/Métodos/enfoques consistentes entre grupos

Éxito en los proyectosProcesos repetibles


Menor coste en los proyectos y resultados de mayor calidad

Notas y preguntas


F O C U S Q U A L I T Y E X P E R I E N C E

BABOKBABOK Profesionalizando el análisis de negocio

Muchas gracias por su atenciónÓscar Santos

[email protected]

netmind - introducción al business analysis

Documents