02 August 2011

EA en BABOK (4)

ENTERPRISE ANALYSIS (EA)

Introducción

Es un área de conocimiento que describe cómo tomar una necesidad de negocio, refinar y clarificar la definición de esa necesidad; y definir un alcance de la solución que puede ser implementado por medio del negocio. Aquí se hablará de la definición y análisis del problema, desarrollo del caso de negocio, estudios de factibilidad, y la definición de un alcance de la solución.

Esta área de conocimiento consiste de un conjunto de tareas que permiten analizar la situación del negocio para entender los problemas y oportunidades del negocio, evaluar el negocio actual de la empresa y plantear posibles cambios para cumplir con las necesidades del negocio y lograr los objetivos estratégicos.

Las actividades de esta área de conocimiento son: (1) Identificar los problemas de negocio a ser resueltos y oportunidades que cumplan con las necesidades del negocio y lograr los objetivos estratégicos, (2) Determinar la opción de solución más factible, (3) Definir el alcance de la solución y desarrollar el caso de negocio como un nuevo proyecto para implementar la solución del negocio, (4) Evaluar, refinar y validar continuamente la necesidad del negocio y la solución durante el proyecto y (5) Evaluar los beneficios del negocio debido a la solución realizada.

TAREA 1 – Definir la necesidad del negocio

Propósito

Identificar las necesidades del negocio para resolver los problemas de negocio y/o tomar ventaja de nuevas oportunidades de negocio para lograr las metas y los objetivos de la empresa.

Entradas

(1) Business goals and objectives y (2) Business analysis plan for enterprise analysis activities

Técnicas

(1) Análisis Gap y técnicas de descomposición, (2) Análisis de oportunidad y (3) Análisis del problema

Partes interesadas

Todas las partes interesadas del área de negocio

Salidas

(1) Defined business need

TAREA 2 – Determinar las capacidades necesarias para cumplir la necesidad del negocio

Propósito

Identificar las áreas de la empresa que necesitan ser cambiadas para cumplir la necesidad del negocio.

Entradas

(1) Business need y (2) Enterprise architecture

Técnicas

(1) Análisis competitivo y estudios de benchmarking, (2) Documento de análisis, (3) Desarrollo de la arquitectura empresarial y (4) Análisis Gap

Partes interesadas

Todas las partes interesadas del área de negocio

Salidas

(1) Gap in capabilities to meet the business need

TAREA 3 – Determinar la propuesta de solución recomendada

Propósito

Determinar y definir la propuesta de solución para cumplir la necesidad del negocio, definir el alcance de la solución y preparar el caso de negocio.

Entradas

(1) Business need y (2) Gap in capabilities to achieve target state

Técnicas

(1) Métodos de análisis de factibilidad (Brainstorming, análisis de la decisión y factibilidad)

Partes interesadas

Todas las partes involucradas en el estudio de factibilidad

Salidas

(1) Recommended solution approach

TAREA 4 – Definir el alcance de la solución

Propósito

Conceptualizar la solución recomendada para definir el alcance del trabajo y preparar el negocio. El enunciado del alcance de la solución es una base para elaborar el caso de negocio. Este enunciado incluye: descripción del ambiente del negocio, descripción de los requerimientos del negocio y definición del alcance del trabajo.

Entradas

(1) Business need, (2) Updates to current state enterprise architecture, (3) Results of competitive analysis and benchmark studies, (4) Target state architecture, (5) Gap in capabilities to achieve target state y (6) Recommended solution approach

Técnicas

(1) Métodos de análisis de alcance (técnicas de descomposición, modelos de alcance)

Partes interesadas

(1)Ejecutivos, (2) Business process owner, (3) IT managers y (4) Project investment governance group

Salidas

(1)Solution scope (enunciado del alcance, Resultados principales, Propuesta inicial del proyecto; y Suposiciones y restricciones)

TAREA 5 – Desarrollar el caso de negocio

Propósito

Informar a la dirección acerca de la nueva propuesta de proyecto. Esto sirve como base para determinar si la solución del negocio nueva o modificada está autorizada. La información recopilada durante las actividades de análisis de la empresa es utilizada para desarrollar el caso de negocio.

Entradas

(1) Business need, (2) Updates to current state enterprise architecture, (3) Results of competitive analysis and benchmark studies, (4) Target state architecture, (5) Gap in capabilities to achieve target state, (6) Recommended solution approach / feasibility study y (7) Solution scope.

Técnicas

(1) Análisis costo beneficio, (2) Modelos económicos y análisis financiero, (3) Técnicas de estimación del tamaño de la solución propuesta y (4) Matriz FODA

Partes interesadas

(1) Executives, (2) Project investment governance group, (3) Business process owner, (4) IT managers y (5) Senior project manager

Salidas

(1) Business case document (Resumen ejecutivo, Introducción y resumen, Propuesta, Criterios claves de selección, Opciones de solución y alternativas preferidas, Evaluación inicial del riesgo de la solución)

Fase 1 de un ERP (8)

Fase 1 - Integración de la empresa

El ERP nace de la necesidad de hacer a la empresa más competitiva y eficaz, integrando los diferentes departamentos de la misma, es decir, “mejorando su cocina”. El objetivo del negocio es reducir al máximo los costes internos eliminando el trabajo mal organizado y duplicado. El resultado que se obtiene con el sistema ERP es la Gestión de los Procesos, Recursos y la necesidad de aplicar la Calidad en la ejecución.

Cuando una Empresa se encuentra implementando un ERP, se pretende lo siguiente:

• Integrar los procesos financieros con los productivos, logísticos, de ventas, etc., dando mucha importancia a la integración de la información, así como a su flujo entre todos los departamentos y áreas que componen la empresa.

• Saber la situación y estado real de la empresa es el Objetivo, se mira hacia sí misma, se necesita hacerla más productiva y el ERP permite el control de los procesos para conseguirlo.

• Revisar sus propios procesos y de la Organización, haciéndola más eficaz y competitiva, teniendo en mente “Reducir los Costes”.

• Optimizar y mejorar la cadena de suministro pasa por gestionar la utilización de los recursos internos, independientemente de sus socios de negocio o proveedores. Es difícil encontrar procesos de colaboración en esta Fase, fuera de interfaces básicos, tipo EDI.

• Diseñar directrices y procesos en común

• Integrar la información de la empresa, para que el dato sea único, ya que la Arquitectura de los sistemas ERP está normalmente basada en el estándar Cliente-Servidor, en el que una Base de Datos única es utilizada por distintas fuentes de usuarios o sistemas que demandan dicha información y la ejecutan, liberando de esta misión a los sistemas donde reside dicha información.

02 July 2011

RMC en BABOK v2.0 (3)

REQUIREMENT MANAGEMENT AND COMMUNICATION (RMC)(2)

Introducción

Es un área de conocimiento que permite administrar conflictos, resultados y cambios; y asegurar que las partes interesadas y el equipo del proyecto están de acuerdo con el alcance de la solución. Según la complejidad y la metodología del proyecto, esta área de conocimiento puede requerir administrar aprobaciones formales, líneas de base y realizar un seguimiento de las versiones de los documentos de los requerimientos, y hacer un seguimiento de los requerimientos desde su inicio hasta la implementación.

Esta área de conocimiento es un conjunto de actividades y consideraciones para administrar y expresar el resultado del análisis de requerimientos. Es una actividad que se realiza en paralelo a la Planificación del Análisis, Análisis de la Empresa y Análisis de los Requerimientos. Esta actividad incluye el empaquetamiento, seguimiento, manejo y comunicación de los requerimientos a las partes interesadas e implementadores del proyecto.

Los requerimientos son analizados, documentados, administrados y comunicados a las partes interesadas. Un análisis de negocio efectivo debe presentar los requerimientos en un formato y estructura adecuado a su audiencia respectiva. Los requerimientos de comunicación es un aspecto importante del análisis del negocio debido a que se pretende que las partes interesadas tengan un entendimiento en común respecto de los requerimientos.

TAREA 1 – Administrar el alcance de la solución de los requerimientos

Propósito

Administrar los cambios en el caso de negocio, alcance de la solución y requerimientos.

Entradas

(1)Stakeholder list, (2) Stakeholder roles and responsibilities designation, (3) Requirements y (4) Requirements management plan

Técnicas

(1) Línea de base, (2) Sistema de control de cambio, (3) Manejo de la configuración y repositorio y (4) Administración de los conflictos de requerimientos

Partes interesadas

(1) Sponsor, (2) Project manager y (3) Business domain subject matter expert

Salidas

(1) Approved requirements, (2) Decisions made, (3) Modified requirements y (4) Approved change to solution/requirements scope.

TAREA 2 – Administrar la trazabilidad de los requerimientos

Propósito

Crear y mantener relaciones entre los requerimientos y otros componentes de la solución.

Entradas

(1) Requirements, (2) Other solution components y (3) Test cases and procedures

Técnicas

(1) Sistema de trazabilidad

Partes interesadas

(1) Business analyst, (2) Quality assurance y (3) Implementation SME

Salidas

(1) Traced requirements y (2) Incomplete requirements

TAREA 3 – Mantener los requerimientos para su re-utilización

Propósito

Aumentar la eficiencia del desarrollo e implementación del software y el aumento de soluciones después del despliegue por medio de la re-utilización de requerimientos existentes.

Entradas

(1) Implemented requirements

Técnicas

(1) Sistema de manejo de configuración y repositorio

Partes interesadas

(1) Business analyst

Salidas

(1) Maintained/reusable requirements

TAREA 4 – Preparar el paquete de requerimientos

Propósito

Esta tarea abarca las consideraciones que deben ser tratadas cuando se inventa un plan para crear un paquete de requerimientos. Los requerimientos pueden ser presentados en varios formatos. Esta tarea requiere el trabajo necesario para decidir que formato es el apropiado para el proyecto y las partes interesadas. Los requerimientos serán presentados en un formato que sea entendido por la persona que revisa.

La presentación de los requerimientos en el formato apropiado es responsabilidad del analista. Se trata de una tarea crítica de análisis del negocio que le permite a las partes interesadas obtener un entendimiento y aprobar los requerimientos. En las metodologías ágiles, los resultados de los requerimientos y/o un paquete de requerimientos no son creados. Los requerimientos de estos proyectos son documentados y recomendados por medio de una metodología y de productos de trabajo informales.

Entradas

(1) Stakeholder analysis, (2) Requirements y (3) Requirements techniques

Técnicas

Ninguna

Partes interesadas

(1) Project sponsor, (2) Business representative, (3) Technical team, (4) Quality assurance, (5) Security personnel, (6) Governing agencies/bodies y (7) Outside customers/suppliers

Salidas

(1) Requirements package y (2) Requirements deliverables

TAREA 5 – Comunicar los requerimientos

Propósito

Comunicar los requerimientos es un aspecto importante del análisis del negocio, ya que se pretende lograr un entendimiento de las partes interesadas respecto de los requerimientos. Esta comunicación es esencial, ya que las partes interesadas representan gente de distintas áreas de conocimiento.

Entradas

(1) Requirements y (2) Business analysis communication plan

Técnicas

(1) RFI, RFQ, RFP, (2) Requirements presentation, (3) Requirements reviewing y (4) Requirements conflicts

Partes interesadas

All

Salidas

(1) Communicated Requirements, (2) List of agreed upon amendments to requirements, (3) List of actions for the business analyst, (4) Outstanding issues, (5) Technical team action items y (6) Approved requirements