Impacto de un ERP (12)

La Tecnología Informática y de Comunicaciones son tecnologías que no dejan de sorprendernos por su enorme desarrollo en un período muy corto de adopción, se puede vislumbrar un futuro cercano de achatamiento en su evolución y en su capacidad de lanzamiento de nuevos productos. Su rápido desarrollo y la drástica reducción de costos han permitido la masificación de su utilización y la posibilidad de explotar sus ventajas en casi todas las Empresas modernas.
Existen motivos para pensar entonces que los procesos de negocios puedan seguir un proceso de commoditización tanto en su diseño como en su soporte tecnológico. Es hora, más que nunca que las Compañías se focalicen en la aplicación práctica de la tecnología informática y de comunicaciones que generen o fortalezcan sus ventajas competitivas. El desafío de conquistar nuevos mercados a través de la diferenciación de sus productos o servicios o el aumento de la fidelidad de sus clientes deben ser objetivos de toda empresa explotando al máximo las facilidades que nos brinda hoy la Tecnología Informática.

Se podrán liderar los procesos de cambio utilizando las nuevas tecnologías para convertirlas en verdaderas ventajas competitivas o se copiará a los líderes del mercado cuando se transformen en una necesidad competitiva. Lo que no se puede hacer si pretendemos seguir en el negocio, es no hacer nada. Lo interesante de este enfoque es pensar en cómo se lograrán ventajas competitivas que permitan diferenciarse de la competencia en un contexto donde tanto la tecnología como el diseño de los procesos se convierten en commodities, accesibles a todos lo que quieran disponer de ellos. Allí está el verdadero desafío.

La capacidad para seleccionar el ERP más adecuado para su empresa y el logro de los resultados económicos esperados al implementar un modelo completo de procesos no es igual en todas las empresas. Están aquellos que han tenido éxito y los que no, pero la implementación de un ERP es el primer y mayor desafío para los que buscan reales ventajas competitivas.

El primer paso hacia la justificación de una inversión en un ERP deberá ser la identificación de los verdaderos procesos críticos del negocio sobre los cuales la empresa pretende construir sus ventajas competitivas diferenciándose de la competencia. Allí es donde se deberían poner los mayores esfuerzos de creatividad, haciendo uso de todas las facilidades de las mejores prácticas embebidas en el sistema y de ser necesario, integrando software específico a través de programas de integración.

UC en BABOK V2.0 (8)

UNDERLYING COMPETENCIES (UC)
Introducción
Es un área de conocimiento que describe los comportamientos, conocimientos y otras características que soporta el análisis del negocio. Realiza una descripción de de los comportamientos, características, conocimiento y cualidades que soportan las prácticas del análisis del negocio.

Las áreas de competencia relevantes para el análisis del negocio son: Pensamiento analítico y resolución de problemas - Características del comportamiento – Conocimiento del negocio – Técnicas de comunicación – Técnicas de interacción del grupo – Aplicaciones de Software

Pensamiento analítico y resolución de problemas Análisis de la decisión
Propósito: Los analistas de negocio deben ser efectivos en entender el criterio involucrado en tomar una decisión y asistir a otros en tomar mejor las decisiones. Medidas de eficacia: Mediciones del análisis de la decisión exitosa

Aprendizaje
Propósito: Los analistas de negocio deben ser efectivos en aprender acerca de los dominios del negocio, cómo funcionan y cómo se traducen en un entendimiento que permita aprender el negocio. Medidas de eficacia: Mediciones del aprendizaje exitoso

Resolución de problemas
Propósito
El análisis del negocio debe ser efectivo en la resolución de problemas para asegurar que el problema es entendido y que las soluciones tratan ese problema. Medidas de eficacia: Mediciones del análisis de la decisión exitosa

Pensamiento sistémico
Propósito: Los analistas de negocio deben ser efectivos en entender cómo interactúan la gente, los procesos y la tecnología dentro de una organización para crear un sistema como un todo. Medidas de eficacia Mediciones del uso efectivo del pensamiento sistémico

Características del comportamiento Ética
Propósito: El analista de negocio debe ser capaz de comportarse éticamente respecto de las partes interesadas y ser capaz de solucionar problemas que se pueden presentar en los requerimientos. Medidas de eficacia: Mediciones del comportamiento ético

Organizacional Personal
Propósito: Las técnicas de organizacional personal asisten al analista de negocio en administrar tareas e información. Medidas de eficacia: Mediciones de la organización personal

Conocimiento del negocio Principios del negocio y prácticas
Propósito: Los analistas de negocio requieren entender los principios básicos del negocio y mejores prácticas para asegurar que éstos son soportados por las soluciones. Medidas de eficacia: Mediciones de los principios del negocio y prácticas

Conocimiento de la industria
Propósito: Los analistas de negocios deberían tener un entendimiento de la industria de su organización y de los cambios necesarios para mantener la competitividad. Medidas de eficacia: Mediciones del conocimiento de la industria

Conocimiento de la organización
Propósito: El análisis del negocio es asistido por medio del entendimiento de la organización. Medidas de eficacia: Mediciones del conocimiento de la organización

Conocimiento de la solución
Propósito Los analistas de negocio pueden usar su conocimiento sobre soluciones existente para identificar el significado de implementar un cambio. Medidas de eficacia: Mediciones del conocimiento de la solución

Técnicas de comunicación

Comunicación oral
Propósito:  Las técnicas de comunicación oral permiten que los analistas de negocio puedan expresar ideas a una audiencia determinada. Medidas de eficacia: Técnicas de comunicación

Enseñanza
Propósito Las técnicas de enseñanza son necesarias para asegurar que el analista de negocio puede comunicar las técnicas de comunicación y requerimientos; y para que la información comunicada es entendida. Medidas de eficacia: Técnicas de enseñanza

Comunicación escrita
Propósito: Las técnicas de comunicación escrita permiten que los analistas de negocio puedan documentar resultados, requerimientos y otra información necesaria. Medidas de eficacia: Técnicas de comunicación

Técnicas de interacción del grupo Facilidades y negociación
Propósito: Los analistas de negocio facilitan las interacciones entre las partes interesadas que ayudan a resolver los desacuerdos respecto de los requerimientos. Medidas de eficacia: Técnicas de negociación

Liderazgo e influencia
Propósito: Los analistas de negocio deben ser capaces de tener roles formales e informales de liderazgo necesarios para investigar los requerimientos y ayudar a que las partes interesadas puedan soportar un cambio. Medidas de eficacia: Técnicas de liderazgo e influencia

Trabajo en equipo
Propósito: Los analistas de negocio deben ser capaces de trabajar con otros miembros del equipo para plantear las soluciones que pueden ser implementadas de manera efectiva. Medidas de eficacia: Técnicas de trabajo en equipo

Aplicaciones de Software Aplicaciones de propósito general
Propósito: Estas aplicaciones de oficina se usan para documentar y hacer un seguimiento de los requerimientos. Medidas de eficacia: Aplicar el conocimiento en varias herramientas similares – Identificar las principales herramientas del mercado – Uso de las principales características de la herramienta – Uso en las actividades de manejo de requerimientos – Uso en las actividades de seguimiento de cambios de los requerimientos

Aplicaciones Especializadas
Propósito:  Estas aplicaciones soportan el desarrollo de modelos formales, y en algunos casos, su validación e implementación. Medidas de eficacia: Aplicar el conocimiento en varias herramientas similares – Identificar las principales herramientas del mercado – Uso de las principales características de la herramienta – Uso en las actividades de manejo de requerimientos – Uso en las actividades de seguimiento de cambios de los requerimientos

SAV en BABOK V2.0 (7)

SOLUTION ASSESSMENT AND VALIDATION (SAV)
Introducción
Es un área de conocimiento que describe cómo evaluar las soluciones propuestas para determinar la mejor solución que se ajuste a la necesidad del negocio. También, se determinan los cambios en la solución y se evalúan las soluciones. Esta área describe las tareas de análisis de negocio que son realizadas para asegurar que las soluciones cumplen con la necesidad del negocio y para facilitar una implementación exitosa. Una solución consistirá de uno o más componentes, tales como procesos de negocio, estructuras organizacionales, entrenamiento y aplicaciones de software.

El analista de negocio está involucrado en la revisión, elección y diseño de la solución. El analista de negocio conoce el ambiente del negocio y puede evaluar cómo cada solución propuesta impactaría en ese ambiente. El equipo de la solución es responsable de entregar la arquitectura o diseño de una solución al analista de negocio. El analista de negocio es responsable de validar si la solución propuesta cumple con las necesidades del negocio.

Se debe tener en cuenta la interacción con implementaciones SME y la interacción con aseguramiento de la calidad.

TAREA 1 – Evaluar la solución propuesta
 Propósito
Esta tarea tiene como propósito evaluar las soluciones propuestas para determinar el valor que suministra al negocio y realizar recomendaciones respecto de la solución elegida.

Entradas (1) Prioritized, approved business requirements, (2) Solution options, (3) Identified risks and constraints y (4) Organizational RFI/RFQ/RFP standards.

Técnicas Coverage matrix – RFI/RFQ/RFP – Trazabilidad
Partes interesadas Sponsor – Project manager – Operational support - Domain SME – Implementation SME

Salidas (1) Solution design assessment y (2) Solution selection assessment

TAREA 2 – Asignar los requerimientos
Propósito Esta tarea tiene como propósito asignar los requerimientos a las liberaciones y/o componentes de la solución. Esta tarea asegura que las opciones de liberación son diseñadas de manera de maximizar el valor del negocio dando las opciones y alternativas generadas por el equipo de diseño.

Descripción La asignación de requerimientos consiste en determinar cuándo y por medio de qué solución será cumplido el requerimiento. El valor del negocio de un requerimiento será afectado cuando éste se cumpla. La asignación debe ser revisada y cambiada. Esta asignación no puede ser realizada hasta que los resultados de la solución han sido definidos.

Entradas (1) Solution design y (2) Validated requirements

Técnicas Técnicas de priorización – Trazabilidad

Partes interesadas End user - Sponsor – Project manager – Operational support - Domain SME – Implementation SME – Quality assurance

Salidas (1) Allocated requirements

TAREA 3 – Determinar la buena voluntad organizacional
Propósito Determinar la buena voluntad organizacional para operar la nueva solución.

Entradas (1) Business architecture y (2) Solution scope

Técnicas Análisis de las fortalezas de un cambio – Análisis del impacto de las partes interesadas

Partes interesadas Sponsor – Project manager – Operational support - Domain SME – Implementation SME

Salidas (1) Organizational readiness assessment

TAREA 4 – Determinar los requerimientos de transición
Propósito Esta tarea tiene como propósito definir las capacidades necesarias para la transición a la nueva solución.

Entradas (1) Deployed solution, (2) Solution design y (3) Organizational readiness assessment

Técnicas Reglas de negocio – Modelo de datos – Modelos de proceso y modelos organizacionales

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

Salidas (1) Transition requirements

TAREA 5 – Validar la solución
Propósito Esta tarea tiene como propósito validar que una solución construida cumple las necesidades del negocio y determinar la respuesta más apropiada a los defectos identificados.

Entradas (1) Constructed solution, (2) Prioritized and validated requirements y (3) Quality assurance

Técnicas Análisis de la causa raíz – Prueba de aceptación del usuario – Informe de los defectos y resultados

Partes interesadas End user - Sponsor – Project manager – Operational support - Domain SME – Implementation SME – Quality assurance – Regulator

Salidas (1) Validated solution, (2) Identified defects y (3) Mitigating actions

TAREA 6 – Evaluar el performance de la solución
Propósito Esta tarea tiene como propósito evaluar el valor de la solución dentro de la organización para entender el valor e identificar oportunidades de mejora.

Entradas (1) Business requirements, (2) Deployed solution y (3) Deployed solution performance metrics

Técnicas Análisis costo beneficio – Focus group – Observación – Retrospectiva – Cuestionarios

Partes interesadas Sponsor - Operational support - Domain SME – Regulator – End user

Salidas (1) Solution performance assessment

FCE de un ERP (11)

Un sistema de información para la gestión ERP se puede definir como una aplicación de gestión empresarial que integra el flujo de información, consiguiendo así mejorar los procesos en distintas áreas (financiera, de operaciones, marketing, logística, comercial, recursos humanos).
El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, tiempos rápidos de respuesta a sus problemas así como un eficiente manejo de información que permita la toma oportuna de decisiones y disminución de los costos totales de operación.

Los factores críticos de éxito (FCE) de un ERP
1- Planificación estratégica de las tecnologías de la información (TI)
Ayuda a asegurar que las metas de desarrollo de las TI estén alineadas con las necesidades de la organización

2- Compromiso ejecutivo
Buena disposición de la alta dirección con el principal encargado del sistema y asignación de recursos requeridos para el buen desarrollo de la implantación

3- Gestión de proyecto
Planear, coordinar y controlar las distintas actividades que se van a realizar dentro del proyecto

4- Habilidades en TI
Son necesarias para configurar y mantener sistemas de información que apoyen a la organización. La falta de éstas es un impedimento para la integración de modernas TI

5- Habilidades en procesos de negocio
Representan las destrezas para entender cómo opera el negocio y para predecir el impacto de una decisión o acción en el resto de la empresa. Son una herramienta fundamental para la implantación de un ERP

6- Entrenamiento en el ERP
Proceso de enseñanza a los diversos grupos de usuarios para utilizar eficientemente el sistema ERP en sus actividades diarias. Es reconocido como un factor clave en la implantación exitosa de un sistema ERP

7- Aprendizaje
Es una fuente de ventaja competitiva razonable. Las competencias de aprendizaje son antecedentes de la mejora del rendimiento de la empresa luego de la implantación del ERP

8- Predisposición al cambio
La implantación de un sistema ERP implica cambios a gran escala que pueden ser resistidos por los empleados de la organización. Desarrollar estrategias es un factor clave para la exitosa implantación del ERP.

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.

Fase 2 de un ERP (9)

Fase 2 - Integración con nuestros Socios de Negocio. ERP extendido.

Una vez que los sistemas son capaces de controlar y gestionar los recursos de la Empresa, los sistemas ERP se preparan para romper las fronteras de la misma y empezar la colaboración con nuestros socios de negocio y, en general, con el entorno que nos rodea.

El ERP, en el paradigma de la integración, se transforma técnicamente para relacionarse con otros sistemas que lo rodean, incorporando en algunos casos dentro del mismo ERP sistemas de integración de Aplicaciones (sistemas EAI) e incluso sistemas de Gestión de procesos de negocio (BPM).

Se necesita buscar usuarios fuera de las fronteras de la empresa, ya sean Clientes, Proveedores, Co-fabricantes, o cualquier Socio de Negocio. Se modernizan los canales de entrada y salida de la información, se integran con portales y se convierten poco a poco en sistemas que tienen que ser compartidos, y que a su vez, utilizan la información de otros sistemas que son la fuente de la misma. De este modo, el ERP se extiende y se prepara para una arquitectura capaz de materializar la colaboración, modificando sus cimientos de Cliente-Servidor y complementándose con sistemas y arquitecturas orientadas a dar y usar servicios de otras aplicaciones y sistemas. Es decir, los ERP se hacen compatibles con arquitecturas SOA.

La empresa que pasa a esta Fase de sistemas va buscando distintas directrices para su negocio:

* La rentabilidad y competitividad se basa en la OPTIMIZACIÓN de los recursos y procesos de la Empresa, ya que se supone que ya están transformados y perfectamente controlados.

* Una de las herramientas para alcanzar esa optimización es el uso de Internet para obtener y dar información de forma más ágil, acortando los tiempos de espera en los procesos donde se ven involucrados recursos que no son de la Empresa.

* La apertura de la empresa empieza introduciendo a los Socios más cercanos a los procesos de la misma. Por otro lado, la información se comparte y se transmite hacia los sistemas de nuestros socios, consiguiendo transacciones que rompen las fronteras del sistema ERP.

* Los canales de acceso a la información se diversifican y se rompen con la única entrada del cliente a la aplicación, intensificando el acceso Web, debido a que este medio facilita la comunicación y la colaboración con usuarios y procesos que no están dentro de la Empresa.

* Mientras las empresas intentan pasar de la fase uno a la dos, descubren los desafíos que conlleva esta última fase y que la forma tradicional de hacer las cosas debe cambiar. Los sistemas de información son conductores del negocio, y el uso de comunicaciones más ágiles hace, por ejemplo, que ocurran hechos como el conflicto del canal de venta (caso muy estudiado donde empresas principalmente de bienes de Equipo, con una marca fuerte, aumentan tanto las ventas por el canal Internet que se plantean romper con su canal tradicional de ventas). Ahora, la empresa no debe optimizar sólo un parámetro del negocio, sino que tiene que poner múltiples valores en juego, conseguir ser mejor que la competencia sólo puede hacerse si es capaz de dar un paso más allá del actual y romper con la forma tradicional de pensar.

En la actualidad, vemos que las grandes compañías se están moviendo en esta fase, mientras que las PyMES parecen estar alejadas de la utilización de este tipo de herramientas. Las pymes se tienen que comunicar e interrelacionar sus procesos con grandes organizaciones, necesitando también incorporarse a este cambio frenético hacia otra forma de entender las relaciones de negocio. Esto permite que los gestores de todo tipo de empresas se fijen en cómo mejorar y optimizar los procesos, más que en el control propio en sí, lo que favorece un aumento de su eficacia y competitividad, a la vez que se agiliza la inversión en sistemas de información, de ahí que la evolución en los departamentos de TI hacia nuevas tecnologías últimamente nos parezca más acelerada.

La ampliación y transformación de los sistemas de información, del ERP hacia distintos Procesos globales, depende del tipo de relación entre las empresas. Dependiendo del tipo de proceso con los que nos relacionamos con otras compañías, existen distintos aplicativos que han ido trasformando y ampliando el núcleo del ERP que hasta ahora conocíamos hacia distintos Procesos globales, que se pueden resolver con las siguientes soluciones:

* SCM (Supply Chain Management) Sistemas para la gestión de la Cadena de Suministro.

* CRM (Customer Relationship Management) Sistemas para la Gestión de la Relación con los Clientes.

* SRM (Supplier Relationship Management) Sistemas para la Gestión de la Relación con los Proveedores.

* PDM (Product Data Management) o PLM (Product Livecycle Management) Sistema para la Gestión del Producto y su ciclo de vida, desde su diseño, hasta su venta y servicio de posventa, pasando por su fabricación.

El ERP en sí no muere, sino que se embebe dentro de estos sistemas globales como una pieza más de una maquinaria que cada vez es más ágil, eficiente y compleja. El facilitador de esta transformación del ERP se empezó a ver materializado en el año 2000 y, hoy en día, las empresas se están transformando a medida que son capaces de tener control e información de la propia empresa. Estos Sistemas son los que catalizan los cambios hacia un mundo más globalizado desde el punto de vista más general, pero transforman los departamentos de IT moviéndolos hacia el negocio, de ahí que, en el mundo de las tecnologías de la Información, mencionamos procesos de gobierno y transformación del IT (IT Governance). Sólo hace falta mirar nuestro entorno, sobre todo a las grandes empresas, para ver cómo los departamentos de IT salen del gobierno de la Dirección Financiera y se alinean o gobiernan desde áreas críticas para el negocio, como las áreas de logística y ventas, o simplemente se convierten en áreas de negocio en sí.

La transformación y evolución de los sistemas es tan acelerada que muchas empresas se plantean gestionar los aspectos de las tecnologías relacionados con el negocio, y separan la operación y construcción técnica de los mismos, sacándolos de la empresa, lo que hace que cada vez escuchemos más la necesidad de tercerizar (Outsourcing) los sistemas de información, lo que también está transformando el negocio de los Servicios tecnológicos y la consultoría.

ELIC en BABOK V2.0 (5)

ELICITATION (ELIC)

Introducción

Es un área de conocimiento que describe cómo se trabaja con las partes interesadas para determinar las necesidades y asegurar que fueron bien entendidas. Los requerimientos de la extracción es una tarea clave del análisis del negocio. Debido a que los requerimientos sirven de base para la solución de las necesidades del negocio, es necesario que los requerimientos estén completos, claros, correctos y consistentes.

TAREA 1 – Preparar la extracción

Propósito

Asegurar que todos los recursos necesarios están organizados y planificados para realizar las actividades de extracción.

Entradas

(1) Stakeholder list, (2) Stakeholder roles and responsibilities designation, (3) Business analysis plans for elicitation, (4) Defined business problem/opportunity, (5) Solution scope y (6) Business case

Partes interesadas

Project manager – Business analyst – Business and technical representative

Salidas

(1) Scheduled resources y (2) Supporting materials

TAREA 2 – Realizar la extracción

Propósito

Cumplir con las partes interesadas para obtener información respecto de sus necesidades.

Entradas

(1) Supporting materials, (2) Organizational standards, (3) Requirements management plan, (4) Defined business problem/opportunity, (5) Solution scope y (6) Business case

Partes interesadas

Participants - Business analyst – Project manager - Technical requirements

Salidas

(1) Elicitation activity results, (2) Assumptions, constraints, risks, issues, (3) Documentation based on technique

TAREA 3 – Documentar los resultados de la actividad de extracción

Propósito

Registrar la información suministrada por las partes interesadas para usarla en el análisis.

Entradas

(1) Elicitation activity results

Partes interesadas

Business analyst

Salidas

(1) Stated requirements

TAREA 4 – Confirmar los resultados de la extracción

Propósito

Validar que los requerimientos expresados por las partes interesadas coinciden con el entendimiento y las necesidades de las partes interesadas.

Entradas

(1) Stated requirements

Partes interesadas

Business analyst – Interviewers – Observed person

Salidas

(1) Validated stated requirements

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.

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.

BAMP en BABOK V2.0 (2)

BUSINESS ANALYSIS PLANNING AND MONITORING (BAPM)

Introducción

Es un área de conocimiento que determina las actividades necesarias para realizar el análisis del negocio. Abarca la identificación de las partes interesadas, la selección de las técnicas de análisis del negocio, el proceso que administrará los requerimientos y cómo evaluar el avance del trabajo ante cambios necesarios. La planificación del análisis del negocio es un dato de entrada principal para el plan de proyecto. El gerente de proyecto es responsable de organizar y coordinar las actividades del análisis del negocio con las necesidades del resto del equipo del proyecto.

Esta área de conocimiento define las tareas asociadas con la planificación y monitoreo de las actividades del análisis del negocio durante el proceso de requerimientos. El análisis del negocio permite identificar las partes interesadas, definir los roles y responsabilidades, desarrollar estimaciones de las tareas del análisis del negocio, planificar la comunicación de los requerimientos, planificar cómo serán aprobados, evaluados y priorizados los requerimientos, determinar qué proceso de requerimientos será utilizado, y determinar las métricas que serán utilizadas para monitorear el trabajo del análisis del negocio. Esta área permite el monitoreo y reporte acerca del trabajo realizado para asegurar que el trabajo de los requerimientos produce los resultados esperados.

TAREA 1 – Planificar la propuesta de análisis del negocio

Propósito

Planificar cómo será planteado el trabajo del análisis del negocio. Hasta que esto no se conozca, no se podrá entender lo siguiente: naturaleza del trabajo terminado en cada área de conocimiento, resultados que se obtendrán, tareas que se terminarán, técnicas utilizadas en los requerimientos establecidos, contenido y formato de los requerimientos, nivel de detalle y formalidad de los requerimientos, método de priorización de requerimientos y métricas usadas en los trabajos del análisis del negocio.

Entradas

(1)Defined business problem/opportunity y (2) Organizational standards

Técnicas

(1)Expert judgment

Partes interesadas (1)Business analyst, (2) Domain subject matter expert, (3) End user, (4) Implementation subject matter expert, (5) Operation support, (6) Project manager, (7) Quality assurance y (8) Sponsor.

TAREA 2 – Realizar el análisis de las partes interesadas

Propósito

Esta tarea abarca la identificación de las partes interesadas, es decir quién puede ser impacto por la propuesta o quién comparte una necesidad de negocio. Esta tarea incluye la determinación de las partes interesadas, el análisis de la influencia de las partes interesadas y aprobar la autoridad.

Entradas

(1)Organizational standards and process assets y (2)Identified need from sponsor

Técnicas

(1)Stakeholder analysis (Stakeholder influence analysis, Stakeholder role analysis)

Partes interesadas

(1)Business analyst, (2) Customer, (3) Domain subject matter expert, (4) End user, (5) Implementation subject matter expert, (6) Operation support, (7) Project manager, (8) Quality assurance, (9) Regulator y (10) Sponsor.

Salidas

(1)Stakeholder list y (2) Stakeholder roles and responsibility designation

TAREA 3 – Planificar las actividades del análisis del negocio

Propósito

Esta tarea documentará los pasos o actividades de la planificación de requerimientos que deben ser terminadas durante el análisis del negocio. Se definirá cada tarea y suministrará una herramienta de gestión para las actividades del análisis de negocio que permiten medir el avance de cada tarea.

Las actividades ejecutadas durante la etapa del proyecto y la forma en que son ejecutadas determinan la calidad y el tiempo de los requerimientos. El analista de negocio debe seleccionar un conjunto de actividades de requerimientos. También, se deben definir los tipos de recursos necesarios para terminar cada actividad.

Entradas

(1)Stakeholder list, (2) Stakeholder roles and responsibility designation y (3) Organizational standards

Técnicas

(1)Descomposión y (2) Técnicas de estimación (analogía, bottom up, paramétrico, rolling wave, análisis histórico, Delphi, expert judgment)

Partes interesadas

(1) Business analyst, (2) Domain subject matter expert, (3) End user, (4) Implementation subject matter expert, (5) Operation support, (6) Project manager, (7) Quality assurance y (8) Sponsor.

Salidas

(1)Business analysis plan (Descripción del alcance del trabajo, Resultados de Work Breakdown Structure, Lista de actividades, Estimación de cada actividad y tarea)

TAREA 4 – Planificar la comunicación del análisis del negocio

Propósito

Un plan de comunicación de requerimientos documenta las intenciones de comunicaciones acerca de los resultados de las actividades del análisis del negocio. Estas actividades incluyen cómo recibir, distribuir, acceder y actualizar la información de análisis del negocio relacionada a las partes interesadas y los medios de comunicación que cada parte interesada estará involucrada en las actividades del análisis del negocio.

Entradas

(1)Stakeholder list, (2) Stakeholder roles and responsibility designation y (3) Business analysis plan

Técnicas

(1)Análisis de los requerimientos de comunicación y (2) Análisis de los medios de comunicación

Partes interesadas

(1)Business analyst,(2)Customer,(3)Domain subject matter expert,(4)End user,(5) Implementation subject matter expert,(6)Operation support,(7)Project manager,(8)Quality assurance,(9)Regulator y(10)Sponsor.

Salidas

(1)Business analysis communications

TAREA 5 – Planificar el proceso de administración de requerimientos

Propósito

El propósito de esta área de conocimiento es seleccionar un proceso para planificar y monitorear los requerimientos del proyecto. También, permite asegurar que el proceso seleccionado es el adecuado para el proyecto.

Entradas

(1)Organizational standards and process assets y (2)Business Analysis Plan

Técnicas

(1)Sistema de control de cambios,(2)Sistema de manejo de la configuración y (3) Sistema de trazabilidad

Partes interesadas

(1)Business analyst,(2)Domain subject matter expert,(3)End user,(4)Implementation subject matter expert,(5)Operation support,(6)Project manager,(7)Quality assurance y (8)Sponsor.

Salidas

(1) Requeriments management plan

TAREA 6 – Planificar, monitorear e informar acerca del performance del análisis del negocio

Propósito

El propósito de esta área de conocimiento es planificar y monitorear el trabajo durante el proyecto. Esta tarea ayuda a identificar y documentar las métricas necesarias relacionadas a un proceso o producto. Es importante que todas las partes interesada estén de acuerdo con las métricas a utilizar.

Entradas

(1)Organizational performance standards,(2)Actual performance metrics,(3)Business Analysis Plan,(4)Requirements management plan

Técnicas

(1) Análisis de varianza,(2)Recopilación, compilación y presentación de información del performance,(3)Re-planificación,(4)Sistema de manejo de la configuración y (5) Análisis del proceso

Partes interesadas

(1)Business analyst,(2)Domain subject matter expert,(3)End user,(4)Implementation subject matter expert,(5)Operation support,(6)Project manager,(7)Quality assurance y (8)Sponsor.

Salidas

(1)Business analysis performance assessment,(2)Lessons learned documentation y (3) Process improvement recommendations

Comprobación de un ERP (6)

Las características que distinguen a un ERP de cualquier otro software empresarial, es que deben de ser sistemas integrales, modulares y adaptables.

• Integrales, porque permiten controlar los diferentes procesos de la compañía entendiendo que todos los departamentos de una empresa se relacionan entre sí, es decir, que el resultado de un proceso es punto de inicio del siguiente. Por ejemplo, en una compañía, el que un cliente haga un pedido representa que se cree una orden de venta que desencadena el proceso de producción, de control de inventarios, de planificación de distribución del producto, cobranza, y por supuesto sus respectivos movimientos contables. Si la empresa no usa un ERP, necesitará tener varios programas que controlen todos los procesos mencionados, con la desventaja de que al no estar integrados, la información se duplica, crece el margen de contaminación en la información y se crea un escenario favorable para malversaciones. Con un ERP, el operador simplemente captura el pedido y el sistema se encarga de todo lo demás, por lo que la información no se manipula y se encuentra protegida.

• Modulares. Los ERP entienden que una empresa es un conjunto de departamentos que se encuentran interrelacionados por la información que comparten y que se genera a partir de sus procesos. Una ventaja de los ERP, tanto económica como técnicamente es que la funcionalidad se encuentra dividida en módulos, los cuales pueden instalarse de acuerdo con los requerimientos del cliente. Ejemplo: ventas, materiales, finanzas, control de almacén, recursos humanos, etc.

• Adaptables. Los ERP están creados para adaptarse a la idiosincrasia de cada empresa. Esto se logra por medio de la configuración o parametrización de los procesos de acuerdo con las salidas que se necesiten de cada uno. Por ejemplo, para controlar inventarios, es posible que una empresa necesite manejar la partición de lotes pero otra empresa no. Los ERP más avanzados suelen incorporar herramientas de programación de 4ª Generación para el desarrollo rápido de nuevos procesos. La parametrización es el valor añadido fundamental que se debe hacer con cualquier ERP para adaptarlo a las necesidades concretas de cada empresa.

Introducción a BABOK v2.0 (1)

BUSINESS ANALYSIS BODY OF KNOWLEDGE (BABOK) V2.0

INTRODUCCION

BABOK 2.0 describe áreas de conocimiento del Análisis de Negocio, sus actividades y tareas asociadas; y las técnicas necesarias para que su ejecución sea efectiva. Esta guía tiene como finalidad identificar las áreas de conocimiento del análisis de negocio que están organizadas y aceptadas como buenas prácticas.

BABOK describe una idea general de cada área de conocimiento y la lista de actividades y tareas asociadas. También, describe y define el análisis de negocio como una disciplina que puede ser realizada por personas con distintos roles (analista de sistemas, analista de procesos, gerente de proyecto, gerente de producto, desarrollador, analista de QA, arquitecto de negocio, consultor, etc).

El análisis de negocio es un conjunto de tareas y técnicas utilizadas para entender la estructura, políticas y operaciones de una organización, y recomendar soluciones que permiten a la organización alcanzar sus objetivos.

Requerimientos y soluciones Una “solución” cumple con una necesidad de negocio, por medio de la resolución de problemas o permite que la organización tome ventaja de una oportunidad. Una solución puede ser subdividida en componentes, incluyendo sistemas de información que los soporten, procesos que los administren y gente que los opere. El análisis de negocio ayuda a que la organización defina la solución óptima a sus necesidades, dando un conjunto de restricciones (tiempos, presupuesto, regulaciones, etc.) dentro de las cuales opera la organización.

Alcance de la soluciónEs el conjunto de capacidades que una solución debe soportar para cumplir con las necesidades del negocio.

Proyecto de la solución

Es el trabajo necesario para desarrollar e implementar una solución en particular.

La definición y gestión del alcance de la solución se diferencia de la gestión del proyecto.

Requerimiento

Es una condición o capacidad necesaria para resolver un problema o lograr un objetivo. También, debe ser cumplida por medio de una solución o componente de solución para satisfacer un contrato, estándar, especificación, u otro documento formal.

Niveles de requerimiento Requerimientos del negocio -> son enunciados generales de las metas, objetivos o necesidades de la empresa. Se describen las razones de inicio del proyecto, futuros logros del proyecto y métricas para medir el éxito del proyecto.

Requerimientos de las partes interesadas  son enunciados de las necesidades de una parte interesada determinada o de una clase de parte interesada. Se describe las necesidades de las partes interesadas y cómo interactúan éstas con la solución.

Requerimientos de la solución: describe las características de una solución que cumple los requerimientos del negocio y los requerimientos de las partes interesadas.

Requerimientos funcionales: describe el comportamiento y la información que la solución administrará. Describe las capacidades que el sistema realizará en términos de comportamientos u operaciones.

Requerimientos no funcionales: hace referencia a las condiciones que no se relacionan con el comportamiento o funcionalidad de la solución, sino que describe las condiciones ambientales en que se ejecutará la solución o las características de calidad que tendrán los sistemas.

Requerimientos de implementación: describe las capacidades que la solución debe tener para facilitar la transición del estado actual de la empresa al estado futuro.

Estructura de BABOK

Tarea (1)

Es una parte esencial del trabajo que debe ser realizado como parte del análisis de negocio. Las tareas deben ser realizadas de manera formal o informal. Una tarea tiene las siguientes características: (1) se obtiene un resultado o salida y (2) es terminada.

Técnica (2)

Las técnicas describen cómo realizar las tareas en circunstancias específicas. Una tarea puede tener una o varias técnicas asociadas. Una técnica debe tener por lo menos una tarea asociada. Las técnicas se pueden aplicar a varias áreas de conocimiento.

Entradas/Salidas (3)

Una entrada representa la información necesaria para empezar una tarea. Las entradas pueden ser generadas como resultado del alcance del análisis de negocio. También, pueden ser generadas por medio de una tarea de análisis del negocio.

Una salida es el resultado del trabajo descripto en una tarea y es producida por una única tarea. Una salida específica puede ser creada o mantenida por una única tarea, aunque una tarea puede tener varias salidas.

Área de Conocimiento (4)

El área de conocimiento agrupa un conjunto de tareas relacionadas y técnicas. No es una metodología. Se definen qué áreas de negocio se deben conocer para efectuar el proceso de análisis.

Las áreas de procesos de BABOK son: (1) Business Analysis Planning and Monitoring, (2) Requirement Management and Communication, (3) Enterprise Analysis, (4) Elicitation, (5) Requirements Analysis, (6) Solution Assessment and Validation y (7) Underlying Competencies.

Ventajas del uso de un ERP (5)

Las ventajas del uso de un ERP son:

- Implantación del producto-solución de forma efectiva, estable y en el menor tiempo posible: beneficios marcados en plazo.

- Facilidad de mantenimiento.

- Garantía de futuras migraciones. Producto estándar.

- Flexibilidad y rapidez de respuesta ante la evolución y continuas nuevas exigencias del mercado. Parametrización (será exclusiva para cada negocio, incluso dentro de una misma empresa (vende coches y flores)).

- Incorporación de algo de organización en los procesos de negocio al revisarlos para adecuar los parámetros a las necesidades de la empresa.

- Interfaz de usuario amigable.

- Ayuda en línea y apoyo al rendimiento (AIR).

- Documentación extensa y detallada.

- El ERP incluye módulos de calidad.

- Multi-idioma.

- Multi-empresa

- Soluciones orientadas a apoyar la toma de decisiones. EIS.

- Soporta muchos usuarios.

- Diseño basado en objetos.

Además, los ERP tienen módulos especializados en un sector (resuelven la problemática, necesidades, de un sector) y otros módulos comunes como tesorería que se adecuan a cada compañía. Asimismo, hay países estándar que son semejantes y otros que tienen problemas específicos (la ñ es España, la letra de cambio que no existe en EEUU) y para los que se crean paquetes especiales.

Estas son algunas de las ventajas que puede aportar la implantación de un ERP en la empresa:

o Automatización de procesos empresariales

o Estar al día de las tareas realizadas

o Protección de información privilegiada

o Mayor flujo de información en la empresa

o Llevar el control de las actividades de la empresa

Con la implantación de una solución ERP la empresa obtendrá unas oportunidades de mejora:

o Agilizará los flujos de datos en la empresa, integrando la información en tiempo real.

o Minimizará el tiempo de respuesta a clientes y proveedores.

o Delegará las decisiones en los niveles adecuados, manteniendo el adecuado control de gestión.

o Garantizará la disponibilidad de información de soporte a la toma de decisiones.

o Facilitará el proceso de planificación empresarial, ya que permiten obtener información consolidada del grado de consecución de los objetivos definidos.

La implantación de una solución ERP a menudo impulsa los cambios organizativos internos. Al incluir en su funcionalidad las mejores prácticas empresariales, resultado de la experiencia en múltiples implantaciones en diversas empresas, facilitan la estandarización y simplificación de los procesos de negocio. El uso de una solución ERP adecuada a las necesidades y características de su empresa se convierte en una ventaja competitiva.

Componentes de éxito de un ERP (4)

Los elementos que avalan el éxito de los ERP son:

- Estándar. Es un estándar, no está hecho a medida para una empresa en cuestión. Resuelve los problemas de una empresa estándar.

- Altas prestaciones, modularidad (dividido en módulos: finanzas, ventas, etc. y con módulos para problemáticas concretas).

- Integrado: La información que actualice una función fluye automáticamente a todos los registros de las funciones relacionadas. Elimina redundancia y permite mayor precisión. La información sólo se introduce una vez.

- Software fabricado con nuevas tecnologías (inabordables a nivel técnico y financiero por una empresa)

- Funcionamiento con distinto HW (DEC, HP, IBM, etc.).

- Multiplataforma (funcionan sobre varios servidores: Windows NT/2000, HP 9000, AS/400, etc.).

- Soporte (a dudas, etc.).

- Futuro (fabricados por empresas solventes, que no van a desaparecer en breve, se da un cierto periodo mínimo de vida).

- Mantenimiento. Se debe pagar, anualmente, una cantidad que varía entre el 12 y el 18% del precio del producto antes de aplicarle posibles descuentos, para tener disponible las actualizaciones que desarrolle el proveedor, las soluciones a posibles fallos, etc.

- Mejora continua de los sistemas de información: la empresa fabricante, mejora el producto constantemente mediante nuevas versiones del mismo según las necesidades del mercado. Crecen con las necesidades de la empresa

- Utiliza la arquitectura Cliente-Servidor.

- Amplia implantación en empresas: ya han sido probados en organizaciones similares, habiéndose modificado los parámetros necesarios para adaptarlo al tipo de empresa que interesa. Además, gracias a los desarrollos que se han hecho y se hacen en base a las necesidades de otras empresas del sector, sabemos qué camino toman éstas.

- Disponen de herramientas de desarrollo propias.

- Permiten optimizar los recursos de la empresa.

- Cubren todas las áreas de negocio (Ventas, Logística, Producción, etc.)

- Metodología y herramientas para la implantación del producto. La existencia de una metodología y unas herramientas probadas en la implantación del ERP en otras empresas, ayuda a minimizar errores, a garantizar el plazo, éxito del producto.

- Trazabilidad: el ERP permite que seguir el proceso de fabricación de un producto concreto (quién trae las materias primas, quién ha trabajado, etc.).

Actualización de CMMi SVC v1.3 (6)

CAPACITY AND AVAILABILITY MANAGEMENT -- PROJECT & WORK MGMT (ML3)The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements.

SG 1 Preparation for capacity and availability management is conducted.

SP 1.1 Establish and maintain a strategy for capacity and availability management. SP 1.2 Select measures and analytic techniques to be used in managing the capacity and availability of the service system. SP 1.3 Establish and maintain service system representations to support capacity and availability management.

SG 2 Capacity and availability are monitored and analyzed to manage resources and demand.

SP 2.1 Monitor and analyze capacity against thresholds. SP 2.2 Monitor and analyze availability against targets. SP 2.3 Report capacity and availability management data to relevant stakeholders.

INCIDENT RESOLUTION AND PREVENTION SVC ESTABLISHMENT & DELIVERY (ML3)

The purpose of Incident Resolution and Prevention (IRP) is to ensure timely and effective resolution of service incidents and prevention of service incidents as appropriate.

SG 1 Preparation for incident resolution and prevention is conducted.

SP 1.1 Establish and maintain an approach to incident resolution and prevention. SP 1.2 Establish and maintain an incident management system for processing and tracking incident information.

SG 2 Individual incidents are identified, controlled, and addressed.

SP 2.1 Identify incidents and record information about them. SP 2.2 Analyze individual incident data to determine a course of action. SP 2.3 Resolve incidents. SP 2.4 Manage the status of incidents to closure. SP 2.5 Communicate the status of incidents.

SG 3 Causes and Impacts of selected incidents are analyzed and addressed.

SP 3.1 Analyze the underlying causes of selected incidents. SP 3.2 Establish and maintain solutions to respond to future incidents. SP 3.3 Establish and apply solutions to reduce the occurrence of selected incidents

SERVICE CONTINUITY -- PROJECT & WORK MGMT (ML3)

The purpose of Service Continuity (SCON) is to establish and maintain plans to ensure continuity of services during and following any significant disruption of normal operations.

SG 1 The essential functions and resources on which services depend are identified and documented.

SP 1.1 Identify and prioritize the essential functions that must be performed to ensure service continuity. SP 1.2 Identify and prioritize the essential resources required to ensure service continuity.

SG 2 Preparations are made for service continuity.

SP 2.1 Establish and maintain service continuity plans that enable the organization to resume performing essential functions. SP 2.2 Establish and maintain training for service continuity. SP 2.3 Provide and evaluate training in the execution of the service continuity plan.

SG 3 The service continuity plan is verified and validated.

SP 3.1 Prepare for the verification and validation of the service continuity plan. SP 3.2 Verify and validate the service continuity plan. SP 3.3 Analyze the results of verifying and validating the service continuity plan.

SERVICE DELIVERY -- SVC ESTABLISHMENT & DELIVERY (ML2)

The purpose of Service Delivery (SD) is to deliver services in accordance with service agreements.

SG 1 Service agreements are established and maintained.

SP 1.1 Analyze existing service agreements and service data to prepare for expected new agreements. SP 1.2 Establish and maintain the service agreement.

SG 2 Preparation for service delivery is conducted.

SP 2.1 Establish and maintain the approach to be used for service delivery and service system operations. SP 2.2 Confirm the readiness of the service system to enable the delivery of services. SP 2.3 Establish and maintain a request management system for processing and tracking request information.

SG 3 Services are delivered in accordance with service agreements.

SP 3.1 Receive and process service requests in accordance with service agreements. SP 3.2 Operate the service system to deliver services in accordance with service agreements. SP 3.3 Maintain the service system to ensure the continuation of service delivery.

SERVICE SYSTEM DEVELOPMENT ADDITION - SVC ESTABLISHMENT & DELIVERY (ML3)

The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements.

SG 1 Stakeholder needs, expectations, constraints, and interfaces are collected, analyzed, and transformed into validated service system requirements.

SP 1.1 Collect and transform stakeholder needs, expectations, constraints, and interfaces into prioritized stakeholder requirements. SP 1.2 Refine and elaborate stakeholder requirements to develop service system requirements. SP 1.3 Analyze and validate requirements, and define required service system functionality and quality attributes.

SG 2 Service system components are selected, designed, implemented, and integrated.

SP 2.1 Select service system solutions from alternative solutions. SP 2.2 Develop designs for the service system and service system components. SP 2.3 Manage internal and external interface definitions, designs, and changes for service systems. SP 2.4 Implement the service system design. SP 2.5 Assemble and integrate implemented service system components into a verifiable service system.

SG 3 Selected service system components and services are verified and validated to ensure correct service delivery.

SP 3.1 Establish and maintain an approach and an environment for verification and validation. SP 3.2 Perform peer reviews on selected service system components. SP 3.3 Verify selected service system components against their specified requirements. SP 3.4 Validate the service system to ensure that it is suitable for use in the intended delivery environment and meets stakeholder expectations.

SERVICE SYSTEM TRANSITION -- SVC ESTABLISHMENT & DELIVERY (ML3)

The purpose of Service System Transition (SST) is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.

SG 1 Preparation for service system transition is conducted.

SP 1.1 Analyze the functionality, quality attributes, and compatibility of the current and future service systems to minimize impact on service delivery. SP 1.2 Establish and maintain plans for specific transitions of the service system. SP 1.3 Prepare relevant stakeholders for changes in services and service systems.

SG 2 The service system is deployed to the delivery environment.

SP 2.1 Systematically deploy service system components into the delivery environment based on transition planning. SP 2.2 Assess the impacts of the transition on stakeholders and service delivery, and take appropriate corrective action.

STRATEGIC SERVICE MANAGEMENT -- SVC ESTABLISHMENT & DELIVERY (ML3)

The purpose of Strategic Service Management (STSM) is to establish and maintain standard services in concert with strategic needs and plans.

SG 1 Strategic needs and plans for standard services are established and maintained.

SP 1.1 Gather and analyze data about the strategic needs and capabilities of the organization. SP 1.2 Establish and maintain plans for standard services.

SG 2 A set of standard services is established and maintained.

SP 2.1 Establish and maintain properties of the organization’s set of standard services and service levels. SP 2.2 Establish and maintain descriptions of the organization’s defined standard services.

Actualización de CMMi ACQ v1.3 (5)

AGREEMENT MANAGEMENT -- PROJECT MANAGEMENT (ML2)

The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.

SG 1 The terms of the supplier agreement are met by both the acquirer and the supplier. SP 1.1 Perform activities with the supplier as specified in the supplier agreement. SP 1.2 Select, monitor, and analyze supplier processes. SP 1.3 Ensure that the supplier agreement is satisfied before accepting the acquired product. SP 1.4 Manage invoices submitted by the supplier.

ACQUISITION REQUIREMENTS DEVELOPMENT -- ACQUISITION ENGINEERING (ML2)

The purpose of Acquisition Requirements Development (ARD) is to elicit, develop, and analyze customer and contractual requirements.

SG 1 Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

SP 1.1 Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle. SP 1.2 Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements.

SG 2 Customer requirements are refined and elaborated into contractual requirements.

SP 2.1 Establish and maintain contractual requirements, which are based on the customer requirements. SP 2.2 Allocate contractual requirements to supplier deliverables.

SG 3 Requirements are analyzed and validated.

SP 3.1 Establish and maintain operational concepts and associated scenarios. SP 3.2 Analyze requirements to ensure they are necessary and sufficient. SP 3.3 Analyze requirements to balance stakeholder needs and constraints. SP 3.4 Validate requirements to ensure that the resulting product performs as intended in the end user’s environment.

ACQUISITION TECHNICAL MANAGEMENT - ACQUISITION ENGINEERING (ML3)

The purpose of Acquisition Technical Management (ATM) is to evaluate the supplier’s technical solution and to manage selected interfaces of that solution.

SG 1 Supplier technical solutions are evaluated to confirm that contractual requirements continue to be met.

SP 1.1 Select supplier technical solutions to be analyzed and analysis methods to use. SP 1.2 Analyze selected supplier technical solutions. SP 1.3 Conduct technical reviews with the supplier as defined in the supplier agreement.

SG 2 Selected interfaces are managed.

SP 2.1 Select interfaces to manage. SP 2.2 Manage selected interfaces.

ACQUISITION VALIDATION - ACQUISITION ENGINEERING (ML3)

The purpose of Acquisition Validation (AVAL) is to demonstrate that an acquired product or service fulfills its intended use when placed in its intended environment.

SG 1 Preparation for validation is conducted.

SP 1.1 Select products and product components to be validated and validation methods to be used. SP 1.2 Establish and maintain the environment needed to support validation. SP 1.3 Establish and maintain procedures and criteria for validation.

SG 2 Selected product and product components are validated to ensure they are suitable for use in their intended operating environment.

SP 2.1 Perform validation on selected products and product components. SP 2.2 Analyze results of validation activities. ACQUISITION VERIFICATION - ACQUISITION ENGINEERING (ML3)

The purpose of Acquisition Verification (AVER) is to ensure that selected work products meet their specified requirements.

SG 1 Preparation for verification is conducted.

SP 1.1 Select work products to be verified and verification methods to be used. SP 1.2 Establish and maintain the environment needed to support verification. SP 1.3 Establish and maintain verification procedures and criteria for the selected work products.

SG 2 Peer reviews are performed on selected work products.

SP 2.1 Prepare for peer reviews of selected work products. SP 2.2 Conduct peer reviews of selected work products and identify issues resulting from these reviews. SP 2.3 Analyze data about the preparation, conduct, and results of the peer reviews.

SG 3 Selected work products are verified against their specified requirements.

SP 3.1 Perform verification on selected work products. SP 3.2 Analyze results of all verification activities.

SOLICITATION AND SUPPLIER AGREEMENT DEVELOPMENT -- PROJECT MGMT (ML2)

The purpose of Solicitation and Supplier Agreement Development (SSAD) is to prepare a solicitation package, select one or more suppliers to deliver the product or service, and establish and maintain the supplier agreement.

SG 1 Preparation for solicitation and supplier agreement development is performed.

SP 1.1 Identify and qualify potential suppliers. SP 1.2 Establish and maintain a solicitation package that includes the requirements and proposal evaluation criteria. SP 1.3 Review the solicitation package with relevant stakeholders to obtain commitment to the approach. SP 1.4 Distribute the solicitation package to potential suppliers for their response and maintain the package throughout the solicitation.

SG 2 Suppliers are selected using a formal evaluation.

SP 2.1 Evaluate proposed solutions according to documented proposal evaluation criteria. SP 2.2 Establish and maintain negotiation plans to use in completing a supplier agreement. SP 2.3 Select suppliers based on an evaluation of their ability to meet specified requirements and established criteria.

SG 3 Supplier agreements are established and maintained.

SP 3.1 Establish and maintain a mutual understanding of the agreement with selected suppliers and end users based on acquisition needs and the suppliers’ proposed approaches. SP 3.2 Establish and maintain the supplier agreement.

Razones para no adoptar un ERP (3)

Por supuesto, no todas las organizaciones adoptan sistemas empresariales, aun cuando tengan uno o varios de los motivos listados en el punto anterior. Algunas compañías deciden usar sólo ciertos módulos de un sistema empresarial, dependiendo de sus sistemas heredados o de los nuevos desarrollos. Otras, por diversas razones, abandonan la implementación o uso de estos sistemas.

La falta de “adaptación de características funcionales” entre las necesidades de la compañía y la oferta disponible en el mercado es una de las razones para no adoptar, implementar parcialmente o abandonar la integración de un ERP. La incompatibilidad obedece a que la mayoría de los módulos de manufactura de los sistemas ERPs han sido desarrollados para manufactura de partes discretas, por lo que no soportan algunos procesos de ciertas industrias.

Por ejemplo, los ERPs tienen dificultad para adaptarse a los procesos de industrias como la de alimentos y papel o a proyectos de la industria aeroespacial. Esta clase de compañías deciden modificar el ERP o adoptar sólo algunos módulos. Otra razón para rechazar un ERP obedece al crecimiento de la compañía, su flexibilidad estratégica y la descentralización en la toma de decisiones. A veces el ERP no está capacitado para mantener el ritmo de crecimiento de la empresa. Asimismo, las compañías que continuamente cambian su estructura organizacional, su modelo de negocio y, particularmente, aquellas que no operan verticalmente pueden encontrar inadaptables los ERPs como una solución empresarial.

Un tercer factor para no adoptar sistemas ERPs se refiere a la disponibilidad de alternativas para integrar sistemas. El almacenamiento de datos es una suma de tecnologías que sirve para integrar datos de múltiples fuentes para su análisis. La utilidad del almacenamiento de datos como estrategia de integración está limitada por la calidad de los sistemas fuente.

Otra alternativa a los sistemas empresariales implica la re-arquitectura de los sistemas internos alrededor de capas de middleware (software que funciona como intérprete entre dos aplicaciones incompatibles), con el objeto de aislar los sistemas de aplicaciones de los almacenes de “datos maestros”.

Algunos consultores comentan que la re-arquitectura de sistemas por medio de middleware es una alternativa viable a los sistemas empresariales cuando la empresa está satisfecha con la funcionalidad de sus sistemas y quiere sólo mejorar la integración del software y enriquecer la interface del usuario. Esta estrategia es utilizada en la industria de servicios financieros, donde los sistemas empresariales han hecho pocas incursiones, a diferencia de los sistemas administrativos. Las razones para no adoptar un ERP generalmente confluyen en los puntos antes mencionados.

Asimismo, se deben agregar los costos, ventaja competitiva y resistencia al cambio. Algunos analistas refieren que el miedo a perder una ventaja competitiva es la mayor razón para no implementar un ERP. El argumento es que si una compañía está segura de que la manera en que opera es la mejor, no aceptará adaptarse a las “mejores prácticas” incluidas en el ERP. Así es que si una compañía clama que ha perdido ventaja competitiva desde la adopción de un ERP, está diciendo que hace las cosas de diferente manera –mejor-- que el ERP. La cuestión consiste en averiguar si la negativa a adaptarse refleja “valor añadido por mejores prácticas” en la organización o una costosa ineficiencia que la organización no está dispuesta a abandonar.

Actrualización de CMMi DEV v1.3 (4)

SUPPLIER AGREEMENT MANAGEMENT -- PROJECT MANAGEMENT (ML2)

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products and services from suppliers.

SG 1 Agreements with the suppliers are established and maintained.

SP 1.1 Determine the type of acquisition for each product or product component to be acquired. SP 1.2 Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria. SP 1.3 Establish and maintain supplier agreements.

SG 2 Agreements with suppliers are satisfied by both the project and the supplier.

SP 2.1 Perform activities with the supplier as specified in the supplier agreement. SP 2.2 Ensure that the supplier agreement is satisfied before accepting the acquired product. SP 2.3 Ensure the transition of acquired products from the supplier.

TECHNICAL SOLUTION -- ENGINEERING (ML3)

The purpose of Technical Solution (TS) is to select, design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate.

SG 1 Product or product component solutions are selected from alternative solutions.

SP 1.1 Develop alternative solutions and selection criteria. SP 1.2 Select the product component solutions based on selection criteria.

SG 2 Product or product component designs are developed.

SP 2.1 Develop a design for the product or product component. SP 2.2 Establish and maintain a technical data package. SP 2.3 Design product component interfaces using established criteria. SP 2.4 Evaluate whether the product components should be developed, purchased, or reused based on established criteria.

SG 3 Product components, and associated support documentation, are implemented form their designs.

SP 3.1 Implement the designs of the product components. SP 3.2 Develop and maintain the end-use documentation.

VALIDATION -- ENGINEERING (ML3)

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

SG 1 Preparation for validation is conducted.

SP 1.1 Select products and product components to be validated and validation methods to be used. SP 1.2 Establish and maintain the environment needed to support validation. SP 1.3 Establish and maintain procedures and criteria for validation.

SG 2 The product or product components are validated to ensure they are suitable for use in their intended operating environment.

SP 2.1 Perform validation on selected products and product components. SP 2.2 Analyze results of validation activities.

VERIFICATION -- ENGINEERING (ML3)

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

SG 1 Preparation for verification is conducted.

SP 1.1 Select work products to be verified and verification methods to be used. SP 1.2 Establish and maintain the environment needed to support verification. SP 1.3 Establish and maintain verification procedures and criteria for the selected work products.

SG 2 Peer reviews are performed on selected work products.

SP 2.1 Prepare for peer reviews of selected work products. SP 2.2 Conduct peer reviews of selected work products and identify issues resulting from these reviews. SP 2.3 Analyze data about the preparation, conduct, and results of the peer reviews.

SG 3 Selected work products are verified against their specified requirements.

SP 3.1 Perform verification on selected work products. SP 3.2 Analyze results of all verification activities.

GENERIC GOALS

GG 1 Achieve Specific Goals

The specific goals of the process area are supported by the process by transforming identifiable input work products into identifiable output work products.

GP 1.1 Perform the specific practices of the process area to develop work products and provide services to achieve the specific goals of the process area.

GG 2 Institutionalize a Managed Process

The process is institutionalized as a managed process.

GP 2.1 Establish and maintain an organizational policy for planning and performing the process. GP 2.2 Establish and maintain the plan for performing the process. GP 2.3 Provide adequate resources for performing the process, developing the work products, and providing the services of the process. GP 2.4 Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process. GP 2.5 Train the people performing or supporting the process as needed. GP 2.6 Place selected work products of the process under appropriate levels of control. GP 2.7 Identify and involve the relevant stakeholders of the process as planned. GP 2.8 Monitor and control the process against the plan for performing the process and take appropriate corrective action. GP 2.9 Objectively evaluate adherence of the process and selected work products against the process description, standards, and procedures, and address noncompliance. GP 2.10 Review the activities, status, and results of the process with higher level management with the appropriate visibility into the process.

GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

GP 3.1 Establish and maintain the description of a defined process. GP 3.2 Collect process related experiences derived from planning and performing the process to support the future use and improvement of the organization’s processes and process assets.

Actualización de CMMi DEV v1.3 (3)

PROJECT MONITORING AND CONTROL -- PROJECT MANAGEMENT (ML2)

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

SG 1 Actual project performance and progress are monitored against the project plan.

SP 1.1 Monitor actual values of project planning parameters against the project plan. SP 1.2 Monitor commitments against those identified in the project plan. SP 1.3 Monitor risks against those risks identified in the project plan. SP 1.4 Monitor the management of project data against the project plan. SP 1.5 Monitor stakeholder involvement against the project plan. SP 1.6 Periodically review the project’s progress, performance, and issues. SP 1.7 Review the project’s accomplishments and results at selected project milestones.

SG 2 Corrective actions are managed to closure when the project’s performance or results deviate significantly from the plan.

SP 2.1 Collect and analyze issues and determine corrective actions to address them. SP 2.2 Take corrective action on identified issues. SP 2.3 Manage corrective actions to closure.

PROJECT PLANNING -- PROJECT MANAGEMENT (ML2)

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

SG 1 Estimates of project planning parameters are established and maintained.

SP 1.1 Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. SP 1.2 Establish and maintain estimates of work product and task attributes. SP 1.3 Define project lifecycle phases on which to scope the planning effort. SP 1.4 Estimate the project’s effort and cost for work products and tasks based on estimation rationale.

SG 2 A project plan is established and maintained as the basis for managing the project.

SP 2.1 Establish and maintain the project’s budget and schedule. SP 2.2 Identify and analyze project risks. SP 2.3 Plan for the management of project data. SP 2.4 Plan for resources to perform the project. SP 2.5 Plan for knowledge and skills needed to perform the project. SP 2.6 Plan the involvement of identified stakeholders. SP 2.7 Establish and maintain the overall project plan.

SG 3 Commitments to the project plan are established and maintained.

SP 3.1 Review all plans that affect the project to understand project commitments. SP 3.2 Adjust the project plan to reconcile available and estimated resources. SP 3.3 Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

PROCESS AND PRODUCT QUALITY ASSURANCE -- SUPPORT (ML2)

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

SG 1 Adherence of the performed process and associated work products to applicable process descriptions, standards, and procedures is objectively evaluated.

SP 1.1 Objectively evaluate selected performed processes against applicable process descriptions, standards, and procedures. SP 1.2 Objectively evaluate selected work products against applicable process descriptions, standards, and procedures.

SG 2 Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

SP 2.1 Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers. SP 2.2 Establish and maintain records of quality assurance activities.

QUANTITATIVE PROJECT MANAGEMENT -- PROJECT MANAGEMENT (ML4)

The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project to achieve the project’s established quality and process performance objectives.

SG 1 Preparation for quantitative management is conducted.

SP 1.1 Establish and maintain the project’s quality and process performance objectives. SP 1.2 Using statistical and other quantitative techniques, compose a defined process that enables the project to achieve its quality and process performance objectives . SP 1.3 Select subprocesses and attributes critical to evaluating performance and that help to achieve the project’s quality and process performance objectives. SP 1.4 Select measures and analytic techniques to be used in quantitative management.

SG 2 The project is quantitatively managed.

SP 2.1 Monitor the performance of selected subprocesses using statistical and other quantitative techniques. SP 2.2 Manage the project using statistical and other quantitative techniques to determine whether or not the project’s objectives for quality and process performance are being satisfied. SP 2.3 Perform root cause analysis of selected issues to address deficiencies in achieving the project’s quality and process performance objectives.

REQUIREMENTS DEVELOPMENT -- ENGINEERING (ML3)

The purpose of requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

SG 1 Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

SP 1.1 Elicit stakeholder needs, expectations, constraints and interfaces for all phases of the product lifecycle. SP 1.2 Transform stakeholder needs, expectations, constraints and interfaces into prioritized customer requirements.

SG 2 Customer requirements are refined and elaborated to develop product and product component requirements.

SP 2.1 Establish and maintain product and product component requirements, which are based on the customer requirements. SP 2.2 Allocate the requirements for each product component. SP 2.3 Identify interface requirements.

SG 3 The requirements are analyzed and validated.

SP 3.1 Establish and maintain operational concepts and associated scenarios. SP 3.2 Establish and maintain a definition of required functionality and quality attributes. SP 3.3 Analyze requirements to ensure that they are necessary and sufficient. SP 3.4 Analyze requirements to balance stakeholder needs and constraints. SP 3.4 Validate requirements to ensure the resulting product will perform as intended in the user’s environment.

REQUIREMENTS MANAGEMENT -- PROJECT MANAGEMENT (ML2)

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

SG 1 Requirements are managed and inconsistencies with plans and work products are identified.

SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements. SP 1.2 Obtain commitment to requirements from project participants. SP 1.3 Manage changes to requirements as they evolve during the project. SP 1.4 Maintain bidirectional traceability among requirements and work products. SP 1.5 Ensure that project plans and work products remain aligned with the requirements.

RISK MANAGEMENT -- PROJECT MANAGEMENT (ML3)

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

SG 1 Preparation for risk management is conducted.

SP 1.1 Determine risk sources and categories. SP 1.2 Define parameters used to analyze and categorize risks and to control the risk management effort. SP 1.3 Establish and maintain the strategy to be used for risk management.

SG 2 Risks are identified and analyzed to determine their relative importance.

SP 2.1 Identify and document risks. SP 2.2 Evaluate and categorize each identified risk using defined risk categories and parameters, and determine its relative priority.

SG 3 Risks are handled and mitigated as appropriate to reduce adverse impacts on achieving objectives.

SP 3.1 Develop a risk mitigation plan in accordance with the risk management strategy. SP 3.2 Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.