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

Ciclo de vida de un ERP (7)

El ciclo de vida del ERP puede ser clasificado en 4 etapas. Los factores comunes que conducen el proceso de implementación del ERP son 4:

Gerenciamiento de la información (1)

Procesos de reingeniería conocidos como BPR (Business Process Reenginering)(2)

Gerenciamiento de proyectos (Project Management) (3)

Gerenciamiento del Cambio (Change Management) (4)

Gerenciamiento de la información en proyecto ERP (1)

La selección del “vendedor” del ERP es un tema crítico dentro del rubro de gerenciamiento de la información. Hay muchos productos cada uno con su filosofía de negocio. Cada empresa tiene diferentes objetivos al tomar la decisión de implementar un ERP y, sin embargo, le es muy difícil definir los criterios objetivos por los cuáles decidir por un paquete de software, una firma proveedora y un implementador del sistema de gestión. Una ayuda puede ser la herramienta de Evaluación de Evaluando ERP.

Reingeniería de procesos de negocios (BPR) (2)

La reingeniería de procesos es un abordaje holístico que puede brindar un vínculo entre la estrategia competitiva de una organización con su gente y con los procesos. Este enlace se mejora usando la tecnología de información y comunicaciones. La diferencia de la reingeniería de procesos de otros abordajes es que BPR cambia radicalmente el modo en que una organización trabaja. Se consiguen importantes mejoras aunque es muy difícil una buena ejecución.

El ERP es un habilitar clave para BPR por la inclusión de “las mejores prácticas” las que, a largo plazo, son estructuradas por los vendedores de ERP mediante la acumulación de conocimiento. La característica fundamental de BPR puede entenderse con claridad si se comparara con otra práctica conocida como Total Quality Management (TQM). Mientras la reingeniería de procesos consiste en la implementación de un cambio radical de una sola vez para obtener un gran resultado, el TQM es un proceso de mejora continua que nunca termina.

Gerenciamiento de Proyectos (3)

El gerenciamiento de proyectos incluye el planeamiento, organización, dirección, control de las actividades y motivación de lo que se considera el más caro de los recursos de un proyecto: La gente, las personas. Esto significa que se deberá tomar una firme posición para:

Por ejemplo, el uso de un diagrama de Gantt puede ayudar a observar los progresos del proyecto y compartir objetivos en común. Muchos implementadores de ERP usan el diagrama de Gantt como una herramienta de soporte para evaluar los avances. Elegir el equipo de proyecto y el líder es crítico para el éxito de la función de gerenciamiento y administración. La selección debería basarse en la capacidad de los individuos para manejar los recursos, el tiempo, con una alta motivación y con mente abierta para las tareas que atañen a funciones horizontales.

Gerenciamiento del Cambio (Change Management) (4)

Davenport define a los recursos humanos como uno de los mayores habilitadores de cambios radicales. Las empresas se construyen y funcionan con personas, y por eso es difícil excluirlas de los cambios organizacionales. Uno de los errores más comunes, es que las compañías se concentran mucho en las mediciones “hard” y prestan poca atención a temas no tan fáciles de medir, como por ejemplo, actitudes, valores, sentimientos y puntos de vista.

El cambio organizacional se relaciona con los recursos humanos para aumentar las ganancias y reducir los riesgos de la reingeniería de procesos. El éxito de un proyecto de reingeniería normalmente incluye un programa de cambio para considerar los aspectos de las personas.

La estrategia de recursos humanos consiste en tres aspectos:

1-Cultura: incluye comportamientos, sistemas, procedimientos y políticas

2-Personas: comprende el poder de autogestión y personal de soporte para permitir a todos los niveles participar en el cambio.

3-Estructura organizacional: considera el mejor estilo organizacional para maximizar el talento, conocimiento y la utilización de recursos.

Una de las dificultades de los recursos humanos en una implementación de ERP es la brecha entre los que apoyan el cambio y quienes se resisten. Mientras la reingeniería es descripta con una mala reputación porque se enfoca en los despidos y fuerza los retiros para aumentar las ganancias, no todos los miembros de una empresa aprecian los beneficios de una implementación de ERP.