Programa de Formación en Business Analysis

Presentación de Formación en Business Analysis

20 septiembre de 2013

1.¿Qué es Business

Analysis?

2.El papel del analista de

negocio

3.Planificación del Análisis

4.Itinerario de formación T-

Systems



Analysis?


negocio


4.Tendencias


Systems


4

“Business Analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals”

IIBA BABOK® V2.0

Qué es Business Analysis

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 implementar soluciones técnicas.

5

Qué es Business Analysis

Necesidades de Negocio

Soluciones tecnológicas

Toma de decisiones

Adaptación a Nuevo mercado

Mejora en eficiencia

Mejor comunicació

n con partners

Data Warehouse

Personalización de paquete

Selección de paquete de

software

Desarrollo de aplicaciones

Requisitos Validados

Solución Verificada

6

Experto

en la materi

a

Equipo técnico

Analista de

negocio

Roles en la definición de requisitos

Conocimiento de Negocio

Conocimiento tecnológico

7

Participantes y roles en el proyecto

8

Dirección

Ejecutivo o PatrocinadorInicia el proyectoProporciona recursos / financiación al proyectoToma las decisiones de alto nivelAprueba el alcanceAsegura alineamiento objetivos de proyecto con organización

Account Manager / Product ManagerDefine los requisitos globales del productDefine el enfoque de marketing del productTrabaja con el cliente para formular los requisitos

Project ManagerSelecciona el equipo adecuado para el proyectoCrea el plan de proyecto y el cronogramaMonitoriza y controla el progresoAsegura que el alcance definido refleja los objetivosGestiona los cambios y el presupuesto


9

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

Proporcionan los objetivos de proyecto, problemas y riesgos desde la perspectiva del negocioEstablecen prioridades para los requirimientos de negocioProporcionan expertise técnicoDiseñan la solución técnica

Expertos en la materia (SMEs)


10

Arquitecto de SistemasAnalista programadorAdministrador de redesAdministrador de BDDiseñador gráficoDiseñador de UIReponsable de Seguridad TI

Expertos en la materia (SMEs)


11

DocumentalistaEspecialista en usabilidadFacilitadorAseguramiento de calidadTesting

Personal de soporte


12

Ciclo de vida del proyecto

8.Conduct post-

implementation review

1. Plan the project

2. Scope the project

3. Elicit, analyze and document requirements

4. Design asolution

5. Build orbuy thesolution

6.Test thesolution

7.Implement

the solution

Project LifeCycle

13

8.Conduct post-


1. Plan the project



4. Design asolution


6.Test thesolution

7.Implement

the solution

Project LifeCycle

Papel del analista de negocio en un proyecto

Análisis - “QUÉ”

Diseño - “CÓMO”

14

Qué es un requisito

Una condición o capacidad que necesita un interesado para solucionar un problema o alcanzar un objetivo.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.Una representación documentada de una condición o capacidad como en (1) o (2).

IIBA BABOK® v2.0

15

Lista para la compra

Pan Cereales Leche Mantequilla Zumo de naranja

“Requisito”

16

CompletoCorrectoNo ambiguoVerificableNecesarioFactiblePriorizado

Características de los requisitos

17

Componentes principales de los requisitos

Componentes de los requisitos

18

Requisitos de negocioRequisitos funcionales (y no funcionales)

Requisito técnicos

Necesidades esenciales del negocio independientes de la implementaciónImplementación de necesidades específicas:

Para el software: Comportamientos observables

Para procesos manuales:Descripciones detalladas de procedimientosRequisitos en la implementación del Software, hardware y redes para soportar las necesidades del negocio.

Categorías de requisitos

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

19

8.Conduct post-


1. Plan the project



4. Design asolution


6.Test thesolution

7.Implement

the solution

Project LifeCycle

Categorías de requisitos

Requisitos del negocio

Requisitos funcionales (y no-funcionales)

Requisitos técnicos


Analysis?

2.El papel del Analista de

Negocio


4.Tendencias


Systems


21

Papel del analista de negocio

8.Conduct post-


1. Plan the project



4. Design asolution


6.Test thesolution

7.Implement

the solution

Project LifeCycle

Verificar que la solución resuelve las necesidades

Identificar una solución

Obtener los requisitos

Analizar y documentar los requisitosComunicar los requisitos

Definir el alcance y el área de negocio

Requisitos en la transición (implementación)

22

Papel del analista de negocio

Definir el alcance y el área de negocioObtener los requisitosAnalizar y documentar los requisitosComunicar los requisitos Identificar una soluciónVerificar que la solución resuelve las necesidadesRequisitos en la transición (implementación)

23

La definición y documentación del alcance de los requerimientos es la MEJOR forma de asegurar el éxito del proyecto

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.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

24

TareasClarificar el propósito y objetivos del proyectoIdentificar unidades organizativas involucradasIdentificar interfacesDeterminar qué procesos de negocio están dentro y fuera del alcanceIdentificar asunciones, riesgos, problemas y oportunidadesEstablecer el sistema para mantener la información del proyecto


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

25


VisiónMisiónValores

Business Drivers Externos

MercadosProductos

Cadena de Valor

Clientes

Organización

Partners /Alianzas

Visión global de valor de la empresa

Stakeholders

Expectativas

Restricciones

Asunciones

26


Cadena de Valor

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

al Alumno

Finanzas

RRHH

Sistemas de Información

Planificación Estratégica

EntregaPlanificación

del curso

27

Training SchedulingPr

oject

INSTRUCTOR

STUDENT

STUDENT

MANAGER

MEETING ROOM RESERVATION

SYSTEM

Diagramas de contexto


28

8.Conduct post-implementation

review

1. Plan the project



4. Design asolution


6.Test thesolution

7.Implement

the solution

Change Control Process

Gestión del alcance

29

Obtener requisitos

Tareas• Descubrir de dónde sacar

los requisitos• Decidir el enfoque para

obtenerlos• Obtener TODOS los

requisitos a nivel detallado• Priorizar requisitos

Habilidades

Preguntar las preguntas adecuadas

Escucha activaTécnicas de entrevistaTécnicas de facilitaciónTécnicas de registro de

información y documentación

Habilidad para categorizar los requisitos

30

Alta intensidad de comunicación

EntrevistasWorkshopsInteracción, proactividad, escucha activa, …

Equilibrar expectativasNegocioFinancierasTecnológicasSeguridad…

Obtener requisitos

31

Es necesario establecer un lenguaje común entre el negocio y el equipo técnico

Obtener requisitos

32

Hay muchos “estándares”

EPDUMLBPMNISOIDEF1X

…pero en este punto es prioritario asegurar la claridad de cara al negocio por sobre la adecuación al estándar

Obtener requisitos

33

Analizar y documentar los requisitos

Tareas• Analizar cada requisito.

Clarificar dudas sobre requisitos ambiguos

• Determinar el mejor formato para comunicar los requisitos

• Determinar el nivel de detalle apropiado

• Normalizar e instaurar directrices sobre documentación

• Realizar una documentación completa de los requisitos

• Categorizar y empaquetar los requisitos

HabilidadesHabilidades de AnálisisCompresión de las

metodologías de desarrollo de sistemas

Compresión de las técnicas de análisis y de documentación

Utilización de diferentes técnicas de documentación

34

El paquete de requisitos y especificaciones

Tabla de Contenidos

Inicio del ProyectoEnfoque y MetodologíaAlcance 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

EntidadesAtributosRelaciones

Reglas de Negocio

Requisitos FuncionalesClases de Usuario/ActoresAlcance 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 externasRestricciones técnicas

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

Requisitos No Funcionales

35

Comunicar los requisitos

Tareas• Actuar como vínculo entre el

negocio y el equipo técnico• Trabajo conjunto con el

Project Manager• Dirigir revisiones de

requisitos• Presentar requisitos para su

aprobación

HabilidadesReuniones eficacesPresentaciones formalesEscritura de emails, memos,

informes de estadoDirigir y documentar reuniones

de revisión de requisitos

36

Identificar la solución

Tareas• Recomendar cambios en los

procesos• Asesorar en el diseño de

automatización de procesos• Asesorar en la selección y

adquisición de software• Asesorar en el desarrollo de

un plan de implantación

Habilidades

Comprensión del problema de negocio

Comprensión a alto nivel de los procesos de desarrollo de software

Técnicas para la evaluación de paquetes de software

Técnicas de estimación de costes y beneficios

Creación de Business Case

37

Verificar que la solución cubre las necesidades

Tareas• Asesorar en el desarrollo de

casos de test• Revisar los diseños técnicos• Soportar los test de

aceptación• Informar sobre defectos y

variaciones respecto a los requisitos

Habilidades

Comprensión a alto nivel de conceptos de diseño de sistemas

Conocimiento de los principios de usabilidad de software

Compresión de las técnicas y principios de testing

Habilidad para escribir y revisar casos de test.

38

La finalización de los requisitos incluye asegurar que é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 QAEs aconsejable que el Analista esté involucrado en algún grado en la prueba del software.


39


40

Debe ser un gran comunicadorAtenció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 formatosEnfocado al clienteFlexiblePreparado con una gran caja de herramientas para descubrir los requisitos

Qué hace un buen analista de negocio

1.¿Qué es Business Analysis?

2.El papel del Analista de

Negocio


4.Tendencias


Systems


42

1. Identificar la información necesaria2. 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 riesgos7. Definir las herramientas de análisis

Planificación del análisis

43

Entrevistas con agentes externos

1. Información necesaria

Políticas y Procedimientos

Entrevistas con el equipo técnico

Sistema de gestión de cambios actual

Entrevistas con los SMEs

Documentación de Software existente

Documentación de los procesos

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

44

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

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

1. Información necesaria

45

Analista de Negocio

Director de Proyecto

Subject Matter Expert



Miembre del equipo técnico

Miembro del equipo técnico

Informac. De negocio

2. Personas / Organizaciones involucradas

46

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

Texto/text estructuradoData model (ERD)Descomposición de procesosDiagrama de FlujoDiagramas de Casos de UsoPrototipos

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

3. Formato de los requisitos

47

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

4. Tipo de proyecto

DesarrolloE-Commerce

Desarrollo de una nueva aplicación

Selección de paquete de

softwareParametrización de un paquete

Evolución de aplicación

Data Warehouse

Nuevo desarrollo de

negocio

48

Es importante determinar los esfuerzos y plazos 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…

5. Dedicación y calendario

49

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

6. Asignar prioridades

50

7. Herramientas de análisis

Necesarias• Procesador de textos• Herramienta de

diagramación gráfica• E-mail• Hoja de cálculo• Sistema de

seguimiento de incidencias

“Nice to Have”

Modelado de datosModelado de procesosGestión de

requerimientosTesting

51

Amenazas en el uso de Equipos Virtuales

Inno

vatio

n

Trus

t

Job

Satis

facti

on

Clar

ity Resu

lts

Invo

lvem

ent

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

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

52

¿Qué metodología utilizaremos?¿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 identificados?

El proceso de análisis


Analysis?


negocio


4.Tendencias


Systems


54

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

Tendencias en el mercado

55

Organización profesional para los analistas de negocio

Creada en Toronto (Canadá) Octubre 2003

Proporciona un foro para compartir conocimientoDesarrolla y mantiene estándares

BABOK™ (Business analysis body of knowledge)Primera versión en Enero 2005

www.theiiba.org

The International Institute of Business Analysis (IIBA)

56

Visión

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

Misión

Desarrollar y mantener estándares para la práctica del análisis de negocio y para la certificación de sus practicantes

The IIBA

57

Recopila la suma de conocimientos dentro de la profesió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

Qué es el BABOK

58

IntroducciónPlanificación y seguimientoObtención de requisitosGestión y comunicación de requisitosAnálisis de la empresaAnálisis de los requisitosEvaluación y validación de la soluciónCompetencias subyacentesTécnicas

BABOK: Contenido

59

Certified Business Analysis Professional (CBAP) – IIBA

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

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

Certificaciones para analistas de negocio

60

Papel de netmind

Co-fundadores del IIBA Co-autores del BABOK Propietarios de las

certificaciones BAA y BAP

Partner exclusivo Formadores certificados Distribuidores de las

certificaciones BAA y BAP

61

• Iniciada en 2002• Prueba el conocimiento del

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

Business Analyst Certification

62

Soluciones orientadas al negocioMétodos/enfoques consistentes entre gruposÉxito en los proyectosProcesos repetibles

Resultados esperados

Menor coste en los proyectos y resultados de mayor calidad


Analysis?


negocio


4.Tendencias

5.Itinerario de formación

T-Systems


64

Itinerario de formación

JIS 402Essential Skills

for Business Analysis

http://bit.ly/17EHVOh

24 horas

JIS 412Use Case

Modeling and Solution

Requerimentshttp://bit.ly/15p74HO

24 horas

ExamenExamen

TutoríaExamen

4 horas

Examen Examen

TutoríaExamen

4 horas

ManualAutoestudio

http://bit.ly/12U0De7

ManualAutoestudio

http://bit.ly/10NvNlU

http://bit.ly/17EHVOh

http://bit.ly/15p74HO

http://bit.ly/12U0De7

http://bit.ly/10NvNlU

65

Algunos datos

Itinerario de formación

Cursos2 cursos presenciales de 24 horas cada uno

Tutorías examen2 tutorías presenciales de4 horas cada una

Total formación56 horas de formación presencial

24 horas de auto-estudio

Exámenes

4 exámenes realizados a través de la web de B2T (en inglés)

DocumentaciónCada alumno recibirá 4 manuales (en inglés)

CertificaciónBusiness Analysis Associate de B2T

Gracias por su atención!


20 septiembre de 2013

Programa de Formación en Business Analysis

Technology

Transcript of Programa de Formación en Business Analysis