RA en BABOK v2.0 (6)

REQUIREMENTS ANALYSIS (RA)

Introducción

Es un área de conocimiento que determina cómo elaborar la definición de la solución que permita al equipo del proyecto diseñar una solución que cumpla con las necesidades del negocio y de las partes interesadas. Para hacer esto se debe analizar el estado inicial de los requerimientos de las partes interesadas para asegurar que son los correctos, evaluar el estado actual del negocio para identificar y recomendar mejoras, y, por último, verificar y validar los resultados.

TAREA 1 – Priorizar los requerimientos

Propósito

No todos los requerimientos tienen la misma importancia. La priorización de los requerimientos permite asegurar que el análisis y la implementación están enfocados en los requerimientos críticos.

Entradas

(1) Business case, (2) Stated requirements y (3) Stakeholder analysis

Técnicas

Análisis Moscow (los requerimientos se clasifican en las categorías de ‘debe’, ‘sería’, ‘podría’ y ‘no será’) – Análisis Kano – Tiempos y presupuesto – Votación

Partes interesadas

Sponsor – Project manager – Domain SME – Implementation SME

Salidas

(1) Prioritized requirements

TAREA 2 – Organizar los requerimientos

Propósito

El propósito de organizar los requerimientos consiste en crear un conjunto de vistas de requerimientos que sean comprensivos, completos, consistentes y entendidos por las partes interesadas incluyendo los expertos de dominio del negocio, usuarios del negocio, diseñadores de la solución, desarrolladores, integradores y equipo de prueba.

Descripción

En este caso se pretende crear una estructura organizada de los requerimientos e identificar la interrelación entre los requerimientos y sus dependencias.

Entradas

(1) Business case, (2) Solution scope, (3) Stated requirements y (4) Organizational standards

Elementos

Seleccionar el método para organizar los requerimientos – Determinar el nivel de requerimiento – Documentar las dependencias e interrelaciones de los requerimientos

Técnicas

Descomposición jerárquica – Escenarios y casos de uso - Otras técnicas (Reglas de negocio, modelos de datos, modelo de eventos, análisis de objetivos, métricas e informes, modelo organizacional, personas y perfiles de usuario, modelo de procesos, prototipos, escenarios y casos de uso)

Partes interesadas

Business analyst – Customer- Domain Subject matter expert (SME) – End user – Implementation Subject matter expert (SME) – Operational support – Project manager – Quality assurance – Regulator – Sponsor

Salidas

(1) Organized requirements

TAREA 3 – Especificar y modelar los requerimientos

Propósito

Esta tarea tiene como propósito documentar los requerimientos de varias formas usando una combinación de enunciados, matrices diagramas y modelos formales en un lenguaje natural.

Entradas

(1) Requirements

Técnicas

Matriz de documentación – Tabla o árbol de decisión

Partes interesadas

Business analyst – Customer - Domain SME – End user - Implementation SME – Operational support – Project manager – Quality assurance – Regulator – Sponsor

Salidas

(1) Modeled and Specified requirements

TAREA 4 – Determinar las suposiciones y restricciones

Propósito

Esta tarea tiene como propósito identificar las suposiciones realizadas y restricciones identificadas durante el análisis de requerimientos que impactarán en el diseño de la solución.

Entradas

(1) Elicitation results (suposiciones y restricciones)

Técnicas

Administración del riesgo

Partes interesadas

Implementation SME

Salidas

(1) Documented assumptions and constraints

TAREA 5 – Verificar los requerimientos

Propósito

Esta tarea permite evaluar los requerimientos para verificar que cumplen las especificaciones de calidad. Esta tarea asegura que los requerimientos están definidos y estructurados, así como que la solución del equipo de desarrollo puede ser usada en el diseño, desarrollo e implementación de la solución.

Entradas

(1) Requirements artifacts

Técnicas

Lista de verificación – Walkthrough

Partes interesadas

Business analyst – Customer - Domain SME – End user - Implementation SME – Operational support – Project manager – Quality assurance – Regulator – Sponsor

Salidas

(1) Verified requirements

TAREA 6 – Validar los requerimientos

Propósito

No todos los requerimientos tienen la misma importancia. La priorización de los requerimientos permite asegurar que el análisis y la implementación están enfocados en los requerimientos críticos.

Entradas

(1) Business case y (2) Verified requirements

Técnicas

Structured Walkthrough – Estudios de factibilidad – Criterio de aceptación – Métricas e Informes – Prototipos

Partes interesadas

Business analyst – Customer - Domain SME – End user - Implementation SME – Operational support – Project manager – Quality assurance – Regulator – Sponsor Salidas

(1) Validated requirements y (2) Evaluation criteria

Fase 3 de un ERP (10)

Fase 3 - La Red de Colaboración.

La evolución de los sistemas SCM, CRM, SRM y PLM hace que la Empresa se haga más competitiva a medida que es más colaborativa con sus proveedores, clientes y, en definitiva, con todos los que son su razón de ser. El movimiento hacia el paradigma de la Red de Colaboración, caracterizado por el inevitable e implacable acercamiento hacia nuestros Clientes, hace que el ejecutor del negocio sea la propia Gestión del Cliente.

La paradoja es que los sistemas que se despliegan no son distintos que en la fase anterior, y aunque su mejora será técnica de cara a ser más efectivos, su filosofía, funcionamiento y módulos son los mismos que las empresas de software nos están ofreciendo ahora. El futuro no está en los sistemas en sí, sino en la forma de interconectarnos para crear esa Red de Colaboración. Mencionar que esta interconexión no es física solamente, lo importante es la lógica, los procesos que incorporemos para que el traspaso de información sea eficiente, y aún más importante, con quien nos conectamos, es decir nuestros Socios de Negocio. Para ser competitivos, nuestros Proveedores, Co-fabricantes y en definitiva Socios tienen que serlo también, eso implica no sólo ser buenos en la ejecución de sus actividades, sino también ágiles en trasmitir cambios en la Cadena de Información, ya que si un eslabón se rompe la cadena no funciona frente a la competencia.

No es importante tener el mejor producto, sino que salga a tiempo y que cubra mejor las necesidades del que lo compra. Esto planteará el cambio en la forma de hacer las cosas y en los socios tradicionales que teníamos, e incluso en los proveedores de sistemas de información y consultoría, los cuales tienen que entender también este cambio. Se forma así toda una cadena implacable y compleja, donde el cliente de mi cliente, mis colaboradores y sus colaboradores en el diseño de sus productos o servicios, se tienen que transformar al mismo ritmo que nuestra Empresa se transforma. Se debe conseguir que la información se trasmita de extremo a extremo lo más rápidamente posible, creando una red de comunicaciones compleja que, aunque invisible, es la que hará que mi producto llegue antes al mercado y, sobre todo, con la mejor ventaja competitiva: el Producto está hecho tal y como quiere mi Cliente, ya que él ha influido y colaborado en su transformación.

El centro del negocio es el mismo Cliente, y los sistemas de información tienen que estar preparados para que lo que el cliente quiere, para que sus modificaciones de producto, sus gustos y tendencias, se transmitan más rápido en mi Red que en la de la competencia, y así conseguir aumentar el mercado y crecer.

Los sistemas de información en sí no varían prácticamente en funcionalidad frente a los de la fase 2, sino que tienen que dotarse de la tecnología necesaria, alineándose a procesos de negocio que traspasan la frontera de la misma empresa y que hacen realidad la creación de una Red de colaboración del valor cada vez más compleja, en la que los contenidos y la información tiene que ser mejor que la de nuestros competidores. El cliente esta “rondando” nuestros sitios Web y nuestra cadena de información con un extraordinario nivel de intimidad, y la empresa tiene que ser capaz de adaptarse a lo que nos llega desde el Cliente, pensando en sistemas con un dialogo interactivo para conocer lo que realmente quiere y mejorando nuestra habilidad para dárselo. Esto es lo que moverá, en un futuro no muy lejano, a la empresa a ser mejor.

Los gestores del negocio no deberían preocuparse por si un proceso interno va bien, los sistemas les facilitan esa información e, incluso, lanzarán mecanismos para que se corrijan. Tienen que estar preparados para innovar y capturar nuevos mercados y aumentar su market share. Nuestro Cliente es el motivo y centro de nuestra actividad. Mejorar nuestra oferta de productos o servicios a su gusto (aunque tengamos que hacer los negocios de otra forma), obtener sus necesidades reales y satisfacerles es el objetivo que mueve a la Colaboración empresarial a través de la Red, y la que nos hará más competitivos.

Resumiendo: ERP = Procesos Estándar + Adaptables + Integrados + Base de Datos única.