Este documento presenta una formación en análisis de negocios. Explica brevemente qué es el análisis de negocios y el papel del analista de negocios. Luego describe los pasos clave en la planificación del análisis de requisitos de un proyecto, incluida la identificación de la información y las personas involucradas, el formato de documentación y la priorización del trabajo. Finalmente, presenta tendencias en el campo y un itinerario de formación propuesto.

1. Presentación de
Formación en Business
Analysis
20 septiembre de 2013

2. Presentación de Formación en Business Analysis
1. ¿Qué es Business Analysis?
2. El papel del analista de
negocio
3. Planificación del Análisis
4. Itinerario de formación TSystems

3. Presentación de Formación en Business Analysis
1. ¿Qué es Business Analysis?
2. El papel del analista de
negocio
3. Planificación del Análisis
4. Tendencias
5. Itinerario de formación TSystems

4. Qué es Business Analysis
“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
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.
4

5. Qué es Business Analysis
Necesidades de Negocio
Soluciones tecnológicas
Mejor
comunicación
con partners
Desarrollo de
aplicaciones
Selección de
paquete de
software
Mejora en
eficiencia
Personalización
de paquete
Adaptación a
Nuevo mercado
Data
Warehouse
Toma de
decisiones
5

6. Roles en la definición de requisitos
Conocimiento
tecnológico
Conocimiento de Negocio
Analista
de
negocio
Experto
en la
materia
Equipo
técnico
6

7. Participantes y roles en el proyecto
7

8. Participantes y roles en el proyecto
Dirección
Ejecutivo o Patrocinador
Inicia el proyecto
Proporciona recursos / financiación al proyecto
Toma las decisiones de alto nivel
Aprueba el alcance
Asegura alineamiento objetivos de proyecto con organización
Account Manager / Product Manager
Define los requisitos globales del product
Define el enfoque de marketing del product
Trabaja con el cliente para formular los requisitos
Project Manager
Selecciona el equipo adecuado para el proyecto
Crea el plan de proyecto y el cronograma
Monitoriza y controla el progreso
Asegura que el alcance definido refleja los objetivos
Gestiona los cambios y el presupuesto
8

9. Participantes y roles en el proyecto
Expertos en la materia (SMEs)
Expertos del área de negocio
Usuarios clave
Arquitecto de Negocio
Planificador Estratégico
Product Manager
Proporcionan los objetivos de
proyecto, problemas y riesgos desde la
perspectiva del negocio
Establecen prioridades para los requirimientos
de negocio
Proporcionan expertise técnico
Diseñan la solución técnica
9

10. Participantes y roles en el proyecto
Expertos en la materia (SMEs)
Arquitecto de Sistemas
Analista programador
Administrador de redes
Administrador de BD
Diseñador gráfico
Diseñador de UI
Reponsable de Seguridad TI
10

11. Participantes y roles en el proyecto
Personal de soporte
Documentalista
Especialista en usabilidad
Facilitador
Aseguramiento de calidad
Testing
11

12. Ciclo de vida del proyecto
8.
Conduct postimplementation review
7.
Implement
the solution
1.
Plan the project
2.
Scope the project
Project Life
Cycle
3.
Elicit, analyze
and document
requirements
6.
Test the
solution
12

13. Papel del analista de negocio en un proyecto
8.
Conduct postimplementation review
1.
Plan the project
Análisis - “QUÉ”
7.
Implement
the solution
2.
Scope the project
Project Life
Cycle
3.
Elicit, analyze
and document
requirements
6.
Test the
solution
5.
Build or
buy the
4.
Design a
13
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
14

15. “Requisito”
Lista para la compra





Pan
Cereales
Leche
Mantequilla
Zumo de naranja
15

16. Características de los requisitos
Completo
Correcto
No ambiguo
Verificable
Necesario
Factible
Priorizado
16

17. Componentes de los requisitos
Componentes
principales de
los requisitos
17

18. Categorías de requisitos
Requisitos de negocio
Necesidades esenciales del negocio
independientes de la implementación
Requisitos funcionales
(y no funcionales)
Implementación de necesidades
específicas:
Para el software:
Comportamientos observables
Requisito técnicos
Para procesos manuales:
Descripciones detalladas de
procedimientos implementación del
Requisitos en la
Software, hardware y redes para
soportar las necesidades del negocio.
Los requisitos de negocio se descubren;
los requisitos funcionales se diseñan.
18

19. Categorías de requisitos
8.
Conduct postimplementation review
Requisitos del
negocio
1.
Plan the project
7.
Implement
the solution
2.
Scope the project
Project Life
Cycle
Requisitos funcionales (y nofuncionales)
3.
Elicit, analyze
and document
requirements
6.
Test the
solution
Requisitos técnicos
5.
Build or
buy the
4.
Design a
19

20. Presentación de Formación en Business Analysis
1. ¿Qué es Business Analysis?
2. El papel del Analista de
Negocio
3. Planificación del Análisis
4. Tendencias
5. Itinerario de formación TSystems

21. Papel del analista de negocio
Requisitos en la transición
(implementación)
Definir el alcance y el área de
negocio
8.
Conduct postimplementation review
1.
Plan the project
Obtener los requisitos
Analizar y documentar los
requisitos
2.
Comunicar los requisitos
Scope the project
7.
Implement
the solution
Project Life
Cycle
3.
Elicit, analyze
and document
requirements
6.
Test the
solution
Identificar una solución
Verificar que la solución resuelve las necesidades
5.
Build or
buy the
4.
Design a
21

22. Papel del analista de negocio
Definir el alcance y el área de negocio
Obtener los requisitos
Analizar y documentar los requisitos
Comunicar los requisitos
Identificar una solución
Verificar que la solución resuelve las necesidades
Requisitos en la transición (implementación)
22

23. Definir el Alcance del Proyecto
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 estudio
El 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 proyecto
Sólo se puede realizar un plan preciso si se tiene una clara
definición del alcance del proyecto
23

24. Definir el Alcance del Proyecto
Tareas
Clarificar el propósito y
objetivos del proyecto
Identificar unidades
organizativas involucradas
Identificar interfaces
Determinar qué procesos de
negocio están dentro y fuera
del alcance
Identificar asunciones,
riesgos, problemas y
oportunidades
Establecer el sistema para
mantener la información del
proyecto
Habilidades
Facilitación
Habilidad para documentar
alcance en términos de
negocio
Técnicas de documentación
24

25. Definir el Alcance del Proyecto
Restricciones
Visión global de valor de la empresa
Asunciones
Business Drivers Externos
Visión
Misión
Valores
Mercados
Productos
Cadena
de Valor
Clientes
Organización
Partners /Alianzas
Stakeholders
Expectativas
25

26. Definir el Alcance del Proyecto
Cadena de Valor
Planificación Estratégica
Sistemas de Información
RRHH
Finanzas
I+D
Gestión
Catálogo
Matriculación
Planificación
del curso
26
Entrega
Servicio
al Alumno

27. Definir el Alcance del Proyecto
Diagramas de contexto
STUDENT
MANAGER
INSTRUCTOR
Training
SchedulingPr
oject
MEETING ROOM
RESERVATION
SYSTEM
STUDENT
27

28. Gestión del alcance
8.
Conduct post-implementation
review
1.
Plan the project
7.
Implement
the solution
2.
Scope the project
Change Control
Process
3.
Elicit, analyze
and document
requirements
6.
Test the
solution
5.
Build or
buy the
solution
4.
Design a
solution
28

29. Obtener requisitos
Tareas
Habilidades
• Descubrir de dónde sacar los
requisitos
• Decidir el enfoque para
obtenerlos
• Obtener TODOS los requisitos
a nivel detallado
• Priorizar requisitos
• Preguntar las preguntas
adecuadas
• Escucha activa
• Técnicas de entrevista
• Técnicas de facilitación
• Técnicas de registro de
información y documentación
• Habilidad para categorizar los
requisitos
29

30. Obtener requisitos
Alta intensidad de comunicación
Entrevistas
Workshops
Interacción, proactividad, escucha
activa, …
Equilibrar expectativas
Negocio
Financieras
Tecnológicas
Seguridad…
30

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

32. Obtener requisitos
Hay muchos “estándares”
EPD
UML
BPMN
ISO
IDEF1X
…pero en este punto es
prioritario asegurar la
claridad de cara al negocio
por sobre la adecuación al
estándar
32

33. Analizar y documentar los requisitos
Tareas
Habilidades
• 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
• Habilidades de Análisis
• Compresió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
33

34. El paquete de requisitos y especificaciones
Tabla de Contenidos
Requisitos Funcionales
Clases de Usuario/Actores
Alcance del área de Diseño
Workflows
Funcionalidad del Sistema
Definición de datos
Requisitos del Interfaz de Usuario
Inicio del Proyecto
Enfoque y Metodología
Alcance del Proyecto
Propósito
Objetivos
Problemas y Oportunidades
Riesgos de negocio
Asunciones
Interacciones externas
Procesos a alto nivel
Items en el alcance
Stakeholders del proyecto y expectativas
Reglas y directrices sobre los requisitos
Requisitos No Funcionales
Requisitos de Rendimiento y Disponibilidad
Requisitos de Seguridad
Requisitos de Calidad
Requisitos Técnicos
Requisitos Hardware
Requisitos Software
Diseño de procesos técnicos
Diseño de base de Datos
Conversión de datos
Requisitos sobre interfaces externas
Restricciones técnicas
Glosario de términos
Requisitos de Negocio
Procesos de Negocio
Requisitos de Datos
Entidades
Atributos
Relaciones
Reglas de Negocio
Anexos
Proceso de Gestión de Cambios
Registro de Revisiones
Abreviaturas y acrónimos aprobados
Temas pendientes
34

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
•
•
•
•
35
Habilidades
Reuniones eficaces
Presentaciones formales
Escritura de
emails, memos, informes de
estado
Dirigir y documentar reuniones
de revisión de requisitos

36. Identificar la solución
Tareas
Habilidades
• 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
• 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
36

37. Verificar que la solución cubre las necesidades
Tareas
Habilidades
• 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
• 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.
37

38. Verificar que la solución cubre las necesidades
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 requisitos
Asegura que el paquete de requisitos tiene
suficiente nivel de detalle desde el punto de vista
de TI y de QA
Es aconsejable que el Analista esté involucrado
en algún grado en la prueba del software.
38

39. Verificar que la solución cubre las necesidades
39

40. Qué hace un buen analista de negocio
Debe ser un gran comunicador
Atención al detalle, tanto en la investigación como en el
registro y documentación
Conocimientos sobre organización
Conocimiento sobre la tecnología
Capaz de manejar gran cantidad de información en diversos
formatos
Enfocado al cliente
Flexible
Preparado con una gran caja de herramientas para
descubrir los requisitos
40

41. Presentación de Formación en Business Analysis
1. ¿Qué es Business Analysis?
2. El papel del Analista de
Negocio
3. Planificación del Análisis
4. Tendencias
5. Itinerario de formación TSystems

42. Planificación del análisis
1. Identificar la información necesaria
2. Identificar las personas y organizaciones
3.
4.
5.
6.
7.
involucradas
Determinar formato de la información de
requisitos
Determinar el tipo de proyecto
Estimar el tiempo requerido
Priorizar el trabajo en función de los objetivos y
riesgos
Definir las herramientas de análisis
42

43. 1. Información necesaria
Documentación de
los procesos
existente
Políticas y
Procedimientos
Table of Contents
Entrevistas con
agentes externos
Functional requirements
User classes/Actors
Design area scope
Workflows
System functionality
Data definitions
User interface requirements
Performance requirements
Security requirements
Quality requirements
Project initiation
Project approach or methodology
Project scope
Project statement of purpose
Project objectives
Project problems/opportunities
Business risks
Project assumptions
Project external interactions
High level processes
Items not in scope
Project stakeholders
Requirements rules/guidelines
Technical requirements
Hardware requirements
Software requirements
Design flows
Database design
Data conversion requirements
External interface requirements
Technical constraints
Glossary
Business requirements
Business processes
Data requirements
Entities
Attributes
Relationships
Business rules
Documentación de
Software existente
Appendix
Change Control Process
Revision log
Approved abbreviations and acronyms
Outstanding questions/issues
Entrevistas con los
SMEs
Entrevistas con el
equipo técnico
Sistema de gestión
de cambios actual
43

44. 1. Información necesaria
Además el analista de negocio debe mantener
información sobre:
Actas de reuniones, entrevistas y sesiones de
trabajo
Informes, formularios y otras plantillas de
documentación e información
Calendario y asignaciones.
44

45. 2. Personas / Organizaciones involucradas
Director de
Proyecto
Miembre del
equipo técnico
Subject Matter
Expert
Analista de
Negocio
Miembro del
equipo técnico
Subject Matter
Expert
Informac. De
negocio
Subject Matter
Expert
45

46. 3. Formato de los requisitos
Antes de iniciar el proceso de toma de datos, la
estructura de los documentos de requisitos debe
estar acordada.
Texto/text estructurado
Data model (ERD)
Descomposición de procesos
Diagrama de Flujo
Diagramas de Casos de Uso
Prototipos
Table of Contents
Project initiation
Project approach or methodology
Project scope
Project statement of purpose
Project objectives
Project problems/opportunities
Business risks
Project assumptions
Project external interactions
High level processes
Items not in scope
Project stakeholders
Requirements rules/guidelines
Glossary
Business requirements
Business processes
Data requirements
Entities
Attributes
Relationships
Business rules
46
Functional requirements
User classes/Actors
Design area scope
Workflows
System functionality
Data definitions
User interface requirements
Performance requirements
Security requirements
Quality requirements
Technical requirements
Hardware requirements
Software requirements
Design flows
Database design
Data conversion requirements
External interface requirements
Technical constraints
Appendix
Change Control Process
Revision log
Approved abbreviations and acronyms
Outstanding questions/issues

47. 4. Tipo de proyecto
El tipo de proyecto determina el trabajo a realizar por el
analista de negocio:
Desarrollo de
una nueva
aplicación
Desarrollo
E-Commerce
Nuevo
desarrollo de
negocio
Data
Warehouse
Evolución de
aplicación
Parametrización de
un paquete
47
Selección de
paquete de
software

48. 5. Dedicación y calendario
Es importante determinar los esfuerzos y plazos de forma
precisa, analizando variables como:
Número de procesos a alto nivel
Número de entidades a alto nivel
Personas y perfiles necesarios
Personal y grupos a entrevistar / comunicar
…
48

49. 6. Asignar prioridades
El análisis de riesgos de negocio y del proyecto
facilitan que el analista de negocio permanezca
enfocado en el área adecuada
Los objetivos de los stakeholders son el auténtico
drive del analista
49

50. 7. Herramientas de análisis
“Nice to Have”
Necesarias
• Procesador de textos
• Herramienta de
diagramación gráfica
• E-mail
• Hoja de cálculo
• Sistema de seguimiento
de incidencias
•
•
•
•
50
Modelado de datos
Modelado de procesos
Gestión de requerimientos
Testing

51. -80%
-60%
Involvement
Job Satisfaction
-80%
Results
Trust
-90%
Clarity
Innovation
Amenazas en el uso de Equipos Virtuales
-50%
-47%
Fuente: Dr. Karen Slobel Lojeski. When virtual distance is relatively high:
51

52. El proceso de análisis
¿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?
52

53. Presentación de Formación en Business Analysis
1. ¿Qué es Business Analysis?
2. El papel del analista de
negocio
3. Planificación del Análisis
4. Tendencias
5. Itinerario de formación TSystems

54. Tendencias en el mercado
Más del 80% de los proyectos de implantación de
software no consiguen los objetivos establecidos
en su principio
Creciente especialización de los roles dentro del
proyecto
Equipos de desarrollo off site, off shore,
subcontratados
Uso de Metodología
54

55. The International Institute of Business Analysis
(IIBA)
Organización profesional para los analistas
de negocio
Creada en Toronto (Canadá) Octubre 2003
Proporciona un foro para compartir
conocimiento
Desarrolla y mantiene estándares
BABOK™ (Business analysis body of
knowledge)
Primera versión en Enero 2005
www.theiiba.org
55

56. The IIBA
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
56

57. Qué es el BABOK
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
57

58. BABOK: Contenido
Introducción
Planificación y seguimiento
Obtención de requisitos
Gestión y comunicación de requisitos
Análisis de la empresa
Análisis de los requisitos
Evaluación y validación de la solución
Competencias subyacentes
Técnicas
58

59. Certificaciones para analistas de negocio
Certified Business Analysis Professional (CBAP) –
IIBA
Más de 1.000 profesionales certificados
En el mercado desde el año 2006
Experiencia mínima 5 años
BA Associate and BA Professional -B2T
Más de 4.000 profesionales certificados
En el mercado desde el año 2002
Es necesario probar experiencia para ser BA
Professional
59

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
60

61. Business Analyst Certification
• 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
61

62. Resultados esperados
Soluciones orientadas al negocio
Métodos/enfoques consistentes entre grupos
Éxito en los proyectos
Procesos repetibles
Menor coste en los proyectos y
resultados de mayor calidad
62

63. Presentación de Formación en Business Analysis
1. ¿Qué es Business Analysis?
2. El papel del analista de
negocio
3. Planificación del Análisis
4. Tendencias
5. Itinerario de formación TSystems

64. Itinerario de formación
JIS 402
JIS 412
Manual
Autoestudio
Manual
Autoestudio
http://bit.ly/12U0De7
http://bit.ly/10NvNlU
Tutoría
Examen
Tutoría
Examen
http://bit.ly/15p74HO
24 horas
4 horas
4 horas
24 horas
Examen
Examen
Examen
Examen
Essential Skills
for Business
Analysis
http://bit.ly/17EHVOh
64
Use Case
Modeling and
Solution
Requeriments

65. Itinerario de formación
Algunos datos
Cursos
Exámenes
2 cursos presenciales de
24 horas cada uno
4 exámenes realizados a través de la
web de B2T (en inglés)
Tutorías examen
Documentación
2 tutorías presenciales de
4 horas cada una
Cada alumno recibirá 4 manuales (en
inglés)
Total formación
Certificación
56 horas de formación presencial
Business Analysis Associate
de B2T
24 horas de auto-estudio
65

66. Gracias por su
atención!
Presentación de Formación en
Business Analysis
20 septiembre de 2013