Programa de Formación en Business Analysis
Upcoming SlideShare
Loading in...5
×
 

Programa de Formación en Business Analysis

on

  • 589 views

Programa de Formación en Business Analysis elaborado por netmind para la empresa T-Systems.

Programa de Formación en Business Analysis elaborado por netmind para la empresa T-Systems.

Statistics

Views

Total Views
589
Views on SlideShare
589
Embed Views
0

Actions

Likes
0
Downloads
25
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Programa de Formación en Business Analysis Programa de Formación en Business Analysis Presentation Transcript

  • Presentación de Formación en Business Analysis 20 septiembre de 2013
  • 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
  • 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
  • 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
  • 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
  • Roles en la definición de requisitos Conocimiento tecnológico Conocimiento de Negocio Analista de negocio Experto en la materia Equipo técnico 6
  • Participantes y roles en el proyecto 7
  • 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
  • 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
  • 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
  • Participantes y roles en el proyecto Personal de soporte Documentalista Especialista en usabilidad Facilitador Aseguramiento de calidad Testing 11
  • 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
  • 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”
  • 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
  • “Requisito” Lista para la compra      Pan Cereales Leche Mantequilla Zumo de naranja 15
  • Características de los requisitos Completo Correcto No ambiguo Verificable Necesario Factible Priorizado 16
  • Componentes de los requisitos Componentes principales de los requisitos 17
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Definir el Alcance del Proyecto Diagramas de contexto STUDENT MANAGER INSTRUCTOR Training SchedulingPr oject MEETING ROOM RESERVATION SYSTEM STUDENT 27
  • 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
  • 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
  • Obtener requisitos Alta intensidad de comunicación Entrevistas Workshops Interacción, proactividad, escucha activa, … Equilibrar expectativas Negocio Financieras Tecnológicas Seguridad… 30
  • Obtener requisitos Es necesario establecer un lenguaje común entre el negocio y el equipo técnico 31
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Verificar que la solución cubre las necesidades 39
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • -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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Gracias por su atención! Presentación de Formación en Business Analysis 20 septiembre de 2013