Software Quality Management

Introducción a PCMM v2.0 (1)

2012-01-11T04:32:00.000-08:00

El éxito de un organización en el mercado de su negocio está determinado por el éxito de los talentos que posee. La retención de empleados experimentados es algo crítico para el mejoramiento de la productividad.

People CMM (PCMM) V2.0 es una herramienta que ayuda a tratar las características críticas de una persona en la organización. Esta herramienta utiliza la estructura de madurez del proceso de CMM como fundamento, ya que se trata de un modelo de mejores prácticas para la administración y desarrollo de la fuerza de trabajo de una organización. Estas prácticas abarcan campos tales como recursos humanos, gestión del conocimiento, y desarrollo organizacional.

PCMM ayuda a las organizaciones a caracterizar la madurez de sus prácticas de la fuerza de trabajo, establecer un programa de desarrollo de fuerza de trabajo continua, asignar prioridades a las acciones de mejoramiento, integrar el desarrollo de la fuerza de trabajo con el mejoramiento del proceso y establecer una cultura de excelencia.

PCMM consiste de 5 niveles de madurez que establecen el fundamento necesario para el mejoramiento continuo de las competencias individuales, desarrollo de equipos efectivos, motivación para mejorar el performance y formar una fuerza de trabajo de acuerdo a las necesidades de la organización y a los futuros planes de negocios. Lograr cada nivel del modelo de madurez permite institucionalizar un componente diferente de la capacidad de la fuerza de trabajo, resultante de un proceso íntegro de la capacidad de fuerza de trabajo de la organización.

El nivel de madurez representa un nuevo nivel de capacidad organizacional creado por medio de la transformación de uno o más dominios de los procesos organizacionales.

Cada nivel de madurez está formado por áreas de proceso. Cada área de proceso abarca un conjunto de objetivos que constituyen un componente importante de la capacidad de la fuerza de trabajo. Cada área de proceso es descripta en términos de prácticas que contribuyen a satisfacer sus objetivos. La prácticas describen la infraestructura y actividades que contribuyen a la implementación efectiva e institucionalización del área de proceso.

Cada nivel progresivo de PCMM produce una única transformación en la cultura de la organización por medio de prácticas que permiten desarrollar, organizar, motivar y retener su fuerza de trabajo. PCMM establece un sistema integrado de prácticas de fuerza de trabajo que evalúa la madurez respecto de los objetivos de negocio de la organización, performance y necesidades de cambio. El objetivo principal de PCMM es mejorar la capacidad la fuerza de trabajo. Esta capacidad de la fuerza de trabajo puede ser definida como nivel de conocimiento, técnicas, y habilidades del proceso disponibles para realizar las actividades del negocio de la organización. PCMM es un modelo basado en proceso, el cual asume que las prácticas de la fuerza de trabajo son procesos organizacionales estándares que pueden mejorados de manera continua a través de métodos que se utilizaron para mejorar otros procesos de negocio. La filosofía implícita de PCMM puede ser resumida en 10 principios: 1- En organizaciones maduras, la capacidad de la fuerza de trabajo está relacionada al performance del negocio. 2- La capacidad de la fuerza de trabajo es una herramienta competitiva y un origen de la ventaja estratégica

3- La capacidad de la fuerza de trabajo debe ser definida en relación a los objetivos de negocio estratégicos de la organización. 4- El conocimiento cambia el enfoque de los elementos de trabajo en las competencias de las fuerzas de trabajo 5- La capacidad puede ser medida y mejorada en múltiples niveles, incluyendo personas, grupos de trabajo, competencias de las fuerzas de trabajo y organización. 6- Una organización trata de mejorar la capacidad de las competencias de las fuerzas de trabajo que son importantes para su competencia en el negocio. 7- La gerencia operacional es responsable de la capacidad de la fuerza de trabajo. 8- El mejoramiento de la fuerza de trabajo puede ser tratado como un proceso compuesto de procedimientos y prácticas. 9-La organización es responsable de suministrar oportunidades de mejoramiento, mientras que los individuos son responsables de implementarlas 10- La organización debe involucrarse en las prácticas de la fuerza de trabajo y desarrollar nuevas competencias en las fuerzas de trabajo. Respecto de la estructura de PCMM, se puede decir que está compuesta por los siguientes componentes: (1) Niveles de madurez, (2) Areas de proceso, (3) Objetivos y (4) Prácticas.

Las Prácticas representan pautas para satisfacer los objetivos del área de proceso, la cual provee los objetivos y el alcance de un área de proceso. Las áreas de proceso constituyen la forma en la cual la organización es transformada en cada nivel de madurez para producir una nueva capacidad organizacional.

Los niveles de madurez de PCMM son:

Nivel 1 – Initial

Nivel 2 – Managed

Nivel 3 - Defined

Nivel 4 – Predictable

Nivel 5 – Optimizing

Nivel de Madurez 2 – Managed

En este nivel de madurez, los gerentes realizan prácticas básicas de administración de personal como una disciplina de administración repetible. La organización establece una cultura enfocada poder asegurar que la gente cumple con sus compromisos de trabajo. Para lograr este nivel, las organizaciones desarrollan la capacidad de administrar técnicas y performance a nivel unidad. Es difícil implementar prácticas si los gerentes no realizan las prácticas básicas de la fuerza de trabajo necesarias para administrar sus unidades.

Las áreas de Proceso del Nivel 2 son:(1) Staffing - ST, (2) Communication and Coordination - CC, (3) Work Environment - WE, (4) Performance Management – PM, (5) Training and Development – TD y (6) Compensation – CM

Nivel de Madurez 3 – Defined

En este nivel de madurez, se tiene como objetivo ayudar a la organización a obtener una ventaja competitiva, a partir del desarrollo de varias competencias que deben ser combinadas en la fuerza de trabajo para lograr las actividades del negocio. Cada competencia de fuerza de trabajo representa una integración de conocimiento, técnicas y procesos necesarios para lograr que las actividades del negocio contribuyan a la competencia de la organización. Cuando los procesos a ser realizados por cada competencia de la fuerza de trabajo, la organización tiene un nuevo fundamento para desarrollar grupos de trabajo. Los procesos basados en al competencia son la base para definir los roles de los grupos de trabajo y los procesos operativos. Las áreas de Proceso del Nivel 3 son: (1) Competency Analysis - CA, (2) Workforce Planning - WP, (3) Competency Development - CD, (4) Career Development – RD, (5) Competency based Practices – CP,(6) Workgroup Development – WD y (7) Participatory Culture - PC Nivel de Madurez 4 – Predictable

En este nivel de madurez, la organización desarrolla la capacidad creada por la estructura de las competencias de la fuerza de trabajo. La organización es capaz de administrar su capacidad y performance de manera cuantitativa. La organización es capaz de predecir su capacidad para realizar el trabajo debido a que puede cuantificar la capacidad de su fuerza de trabajo y de los procesos basados en la competencia. Para lograr tener una estructura de competencia, las organizaciones deben administrar su capacidad de manera cuantitativa. Dentro de cada unidad o grupo de trabajo, el performance de los procesos basados en la competencia es medido para determinar si se lograron los objetivos de negocio

Las áreas de Proceso del Nivel 4 son: (1) Competency Integration - CI, (2) Empowered Workgroups - EW, (3) Competency based Assets - CA, (4) Quantitative Performance Management – QPM, (5) Organizational Capability Management – OCM y (6) Mentoring - MN En este nivel de madurez, toda la organización está enfocada al mejoramiento continuo. Estos mejoramientos son realizados en la capacidad de los individuos y de los grupos de trabajo, en los procesos basados en al competencia y en las actividades y prácticas de las fuerzas de trabajo. Aunque los individuos y los grupos de trabajo mejoran su performance, la organización debe asegurar que esto se corresponda con los objetivos de la organización.

Las áreas de Proceso del Nivel 5 son: (1) Continuous Workforce Innovation - CWI, (2) Organizational Performance Alignment – OPA y (3) Continuous Capability Improvement – CCI

ERP y Cadena de Valor (13)

2012-01-04T12:33:00.001-08:00

La tecnología basada en la red mueve la información a lo largo de la cadena de valor logística, uniendo grupos separados previamente, que pueden comunicarse más rápida y eficientemente por teléfono, fax o correo electrónico, que cara a cara. Esta tecnología tiene la capacidad de proporcionar información instantáneamente a un coste muy bajo. El ERP de cada compañía se conecta directamente a los sistemas ERP de proveedores y clientes. El EDI ofrece un modelo similar, aunque en el modelo EDI cada empresa debe crear protocolos únicos para cada proveedor o cliente. En un modelo basado en Internet con estándares abiertos, una compañía puede conectar a través de la tecnología basada en la red con cada proveedor y cada cliente.

Debido a que la información es más fácilmente disponible usando la tecnología basada en Internet para conectar ambos, proveedores y clientes, la oportunidad existe para una empresa para crear nuevas estrategias de negocio basadas en transformar una cadena de valor en una red integrada de valor. La razón para esto reside en los atributos únicos de información:

- La información puede ser consumida múltiples veces

- La información puede ser condensada

- El valor de la información cambia con el tiempo y el uso

- La información abre las puertas

Cuantas más empresas estén conectadas a la red integrada, mayor valor hay para cualquier otra empresa en conectarse a esta red. A la vez que los socios de la red integrada aprenden a trabajar juntos mejor, el beneficio del cliente se incrementa a la vez que los costes decrecen y los niveles de servicio mejoran.

Esta dinámica llega ser un círculo vicioso, conduciendo a los miembros de la empresa extendida a mejorar constantemente sus propios procesos internos así como los procesos de la red extendida de empresas. Los miembros de la red extendida se esfuerzan por la eficacia y reducción de costos. A la vez que las compañías adopten los estándares abiertos que incluyen el ERP dentro de las tecnologías Internet, sus arquitecturas de sistemas cambiarán espectacularmente. Se plantea una arquitectura donde en el centro está el sistema ERP de la compañía, que es su motor de transacciones y generador de sus datos internos. Estos datos almacenados en un Datawarehousing, pueden ser cortados y analizados en cualquier número de formas por el software que soporta las decisiones de la compañía, y que ésta utiliza para realizar sus análisis de negocio.

Con la tecnología basada en Internet, la compañía puede transferir información hacia y desde sus clientes, proveedores y socios de negocio. En resumen, la tecnología permite a la empresa utilizar fuentes de investigación externa para sumar calidez y robustez a sus análisis de negocio. La tecnología para soportar las decisiones asiste a los gerentes y a todos los niveles de la organización para tomar decisiones coherentes, dándoles una clara imagen de la información relevante desde ambos sitios, dentro y fuera de la compañía. En un sistema como tal, los datos de fuentes internas/externas pueden ser consolidados y comparados con los objetivos de una compañía como parte del sistema de medida del rendimiento, convirtiendo los datos en información de gestión.

Impacto de un ERP (12)

2011-12-05T06:56:00.001-08:00

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)

2011-12-05T06:51:00.001-08:00

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)

2011-11-05T08:15:00.000-07:00

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)

2011-11-05T08:12:00.000-07:00

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)

2011-10-01T07:26:00.000-07:00

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

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)

2011-10-01T07:21:00.001-07:00

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)

2011-09-03T12:12:00.000-07:00

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)

2011-09-03T12:08:00.001-07:00

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)

2011-08-02T15:45:00.000-07:00

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

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)

2011-08-02T15:41:00.000-07:00

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)

2011-07-02T07:49:00.000-07:00

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)

2011-07-02T07:45:00.000-07:00

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)

2011-06-05T13:59:00.000-07:00

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)

2011-06-05T13:53:00.001-07:00

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)

2011-05-05T12:43:00.000-07:00

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)

2011-05-05T12:42:00.001-07:00

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)

2011-04-05T07:16:00.000-07:00

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)

2011-04-05T07:07:00.000-07:00

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)

2011-03-02T11:32:00.000-08:00

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)

2011-03-02T11:28:00.000-08:00

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)

2011-02-01T07:34:00.001-08:00

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.

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.

SG 2 Peer reviews are performed on selected work products.

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)

2011-02-01T07:31:00.000-08:00

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.

Razones para adoptar un ERP (2)

2011-02-01T07:27:00.000-08:00

Dada la riqueza de los sistemas empresariales en términos de funcionalidad y beneficios potenciales, no debe sorprendernos que algunas organizaciones los adopten. Unas compañías plantean razones técnicas para invertir en sistemas empresariales. Y otras, tienen razones de negocio para la adopción de un sistema ERP. Sea cual sea la razón que las impulsa, tanto las pequeñas como las grandes empresas pueden beneficiarse técnica y estratégicamente de la inversión en sistemas empresariales. Al fin y al cabo, a pesar de las diferencias, las necesidades y oportunidades tecnológicas de las pequeñas empresas son derivaciones de las que enfrentan sus contrapartes de mayor tamaño.

Las grandes compañías también tienen dolores de cabeza debido al mantenimiento de diferentes tipos de sistemas del mismo tipo de aplicación. Boeing, por ejemplo, tenía 14 sistemas para facturación de materiales y 30 sistemas de control de almacén antes de adquirir un ERP.

Razones de negocio

(1) Adecuarse al crecimiento del negocio (2) Adquirir TI con capacidad para manejar multi-lenguajes y multi-monedas (3) Mejorar los procesos informales e ineficientes (4) Ordenar datos y registros por medio de la estandarización (5) Reducir gastos operativos y administrativos del negocio (6) Reducir costos de traslado y falta de inventario (7) Eliminar demoras y errores en completar órdenes de los clientes en negocios emergentes

Además de las mencionadas, las PyMEs tienen las siguientes razones de negocio:

(1) Proveer un apoyo integrado de TI (2) Estandarizar esquemas múltiples de numeración, etiquetación y codificación (3) Estandarizar procedimientos a través de diferentes localizaciones geográficas (4) Presentar una sola cara al cliente (5) Adquirir la capacidad global de capacitado para cumplir (6) Modernizar y agilizar las consolidaciones financieras (7) Mejorar la capacidad global de decisión de la compañía

Razones Técnicas

(1) Solucionar problemas como Y2K y similares (2) Integrar aplicaciones trans funcionales (3) Reemplazar interfaces difíciles de mantener (4) Reducir el mantenimiento de software (5) Eliminar entradas de datos redundantes y errores concurrentes (6) Mejorar el análisis de datos (7) Mejorar la arquitectura de TI (8) Desahogar restricciones de capacidad tecnológica (9) Disminuir costos operativos de TI

Es importante que una empresa considere estas variantes al momento de explicar las motivaciones, impactos y consecuencias de adoptar un ERP.

Introducción al ERP (1)

2011-01-03T12:04:00.000-08:00

En las organizaciones tradicionales, con sistemas informáticos tradicionales nacidos a partir de la década de los 60, los empleados se concentraban en sus tareas funcionales específicas y tenían acceso solamente a una limitada información que provenía del sistema informativo de su departamento. Los viejos sistemas reforzaban el tradicional modelo vertical orientado a funciones específicas – contabilidad, comercial, y producción, construidos uno a uno en forma independiente, con modelos de datos independientes entre sí y con muy poca integración con los otros. Cuando se requería la interacción entre sistemas diferentes, la solución técnica aconsejaba la construcción de una interface. Esto es, para completar un proceso que atravesaba a varias funciones o compartir datos entre distintos modelos de datos se debía construir una interface, habitualmente una pieza de software batch (y más modernamente on-line) que cubría la necesidad, transfiriendo los datos de un lado al otro.

El aumento en la complejidad de los negocios, sumado al hecho de la mayor demanda a los sistemas computarizados sobre nuevas funcionalidades y la complejidad creciente de las interfaces, llevaron a la construcción de verdaderas arquitecturas de sistemas con un alto costo de mantenimiento y muy bajo nivel de calidad en términos de prestación de servicios al usuario final. Al momento de diseñar un Sistema de Información se pretende modelizar el real funcionamiento de una Empresa, pero una vez implementado este define una forma de operar.

El advenimiento de los Sistemas Integrados de Información (ERPs) trajo consigo la posibilidad de concretar una transformación radical de los negocios a través de la revisión integral de sus procesos. Es oportuno rescatar una de las definiciones más precisas y concisas del término “proceso” dentro del ambiente de las empresas, del libro de Hammer y Champy (1993): “Un proceso de negocios es un conjunto de actividades que, a partir de una o más entradas, produce una salida que tiene valor para el cliente”. ¿Qué fue primero? ¿La visión por proceso de los gurúes del estudio de las organizaciones o el advenimiento de los ERP’s por parte de los gurúes de la tecnología informática? Difícil responder a esa pregunta, pero la historia cuenta que durante la década de los 90, ambos conceptos transitaron un camino paralelo hasta conformar una solución única para las organizaciones modernas, orientadas por proceso y soportadas por medio de un Sistema Integrado de Información.

Los empleados que hoy utilizan un ERP tienen acceso a la información de todos los departamentos que participan del proceso completo, de punta a punta y en forma on-line. Rápidamente, el proceso se torna visible. Los empleados entienden cómo su trabajo afecta al trabajo del resto de la organización. Los datos se ingresan al sistema en el momento y en el lugar donde se generan por el responsable de los mismos. Se eliminan las transcripciones y los errores de consistencia de los datos.

La capacidad de un ERP de operar en múltiples lenguajes, utilizando múltiples monedas y adaptándose a las normas legales y fiscales de todos los países donde opera lo convierte en una herramienta poderosa para las Empresas multinacionales que han expandido sus operaciones alrededor del mundo. Las Empresas multinacionales apreciaron rápidamente las ventajas de imponer un sistema (“su sistema”) en Empresas a incorporar, logrando rápidamente información integrada para el control de las mismas y para la adecuada toma de decisiones.

Durante los últimos 30 años se ha producido una rápida expansión y evolución de la tecnología de los Sistemas de Información con una disminución de su coste y una mayor facilidad para incorporarla y difundirla en las organizaciones. Sin embargo, el estado de las aplicaciones de las empresas no ha evolucionado con sus necesidades. La mayor parte tienen aplicaciones muy pobres, con características atrasadas y no hacen sino automatizar algunas de las funciones básicas de la empresa.

Debido a que la aplicación informática servirá a la empresa de apoyo en todas sus acciones y estrategias, es importante que la aplicación sea actualizada para que cubra, lo mejor posible, las necesidades de la empresa. Cuando una empresa decide actualizar su aplicación principal, se debe elegir una teniendo en cuenta los puntos a favor y en contra de cada una de ellas y, teniendo claro qué necesita la empresa en cuestión.

Las grandes y medianas empresas precisan aplicaciones globales que cubran de modo integrado todas las áreas de su actividad (Finanzas, Distribución y Ventas y Producción) y además, otros elementos tecnológicos que son imprescindibles en organizaciones de este volumen como EDI, Intranet, Workflow, etc. que estarán totalmente integrados con la aplicación. Estas aplicaciones son los ERP. Un ERP es una solución, la cual se caracteriza por apoyar los procesos de las áreas operativas de las empresas por medio de múltiples módulos, los cuales se integran entre sí y se ven reflejados en las áreas administrativas financieras, integrando así la información, dando universalidad a la misma, estandarización de sistemas e interfaces con otras aplicaciones. Son sistemas que pueden ayudar a permitir cambios y en la mayoría de los casos funcionales para varias bases de datos y sistemas operativos.

Es un sistema de manejo de la información estructurado que satisface la demanda de soluciones de gestión de empresas, basado en el ofrecimiento de una solución completa que permite a las empresas evaluar, implementar y manejar más fácilmente su negocio.

Los retos de disponer de sistemas apropiados a la nueva economía afectan a todas las empresas, las cuales deben responder a las oportunidades que nacen en la nueva tecnología o bien desaparecerán. Todas las empresas necesitarán la actualización de sus infraestructuras empresariales y cambiar el modo en que trabajan para responder a las necesidades del cliente. Las infraestructuras internas existentes de las empresas de hoy representan una gigantesca inversión en tecnología, en formación, en investigación, en la ingeniería de los negocios que, en algunos casos, ha estado funcionando durante cientos de años.

Las empresas que triunfarán serán aquellas que se apoyen en esta inversión, con inversiones en sistemas ERP, en soluciones e-business que funcionen de forma totalmente integrada.

Actualización de CMMi v1.3 (2)

2011-01-03T11:47:00.000-08:00

ORGANIZATIONAL PROCESS FOCUS -- PROCESS MANAGEMENT (ML3)

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

SG 1 Strengths, weaknesses, and improvement opportunities for the organization’s processes are identified periodically and as needed.

SP 1.1 Establish and maintain the description of process needs and objectives for the organization. SP 1.2 Appraise the organization’s processes periodically and as needed to maintain an understanding of their strengths and weaknesses. SP 1.3 Identify improvements to the organization’s processes and process assets.

SG 2 Process actions that address improvements to the organization’s processes and process assets are planned and implemented.

SP 2.1 Establish and maintain process action plans to address improvements to the organization’s processes and process assets. SP 2.2 Implement process action plans.

SG 3 Organizational process assets are deployed across the organization and process related experiences are incorporated into organizational process assets.

SP 3.1 Deploy organizational process assets across the organization. SP 3.2 Deploy the organization’s set of standard processes to projects at their startup and deploy changes to them as appropriate throughout the life of each project. SP 3.3 Monitor the implementation of the organization’s set of standard processes and use of process assets on all projects. SP 3.4 Incorporate process related experiences derived from planning and performing the process into organizational process assets.

ORGANIZATIONAL PERFORMANCE MANAGEMENT -- PROCESS MANAGEMENT (ML5)

The purpose of Organizational Performance Management (OPM) is to proactively manage the organization’s performance to meet its business objectives.

SG 1 Manage the organization’s business performance using statistical and other quantitative techniques to understand process performance shortfalls and identify areas for process improvement.

SP 1.1 Maintain business objectives based on an understanding of business strategies and actual performance results. SP 1.2 Analyze process performance data to determine the organization’s ability to meet identified business objectives. SP 1.3 Identify potential areas for improvement that could contribute to meeting business objectives.

SG 2 Improvements are proactively identified, evaluated using statistical and other quantitative techniques, and selected for deployment based on their contribution to meeting quality and process performance objectives.

SP 2.1 Elicit and categorize suggested improvements. SP 2.2 Analyze suggested improvements for their possible impact on achieving the organization’s quality and process performance objectives. SP 2.3 Validate selected improvements. SP 2.4 Select and implement improvements for deployment throughout the organization based on an evaluation of costs, benefits and other factors.

SG 3 Measurable improvements to the organization’s processes and technologies are deployed and evaluated using statistical and other quantitative techniques.

SP 3.1 Establish and maintain plans for deploying selected improvements. SP 3.2 Manage the deployment of selected improvements. SP 3.3 Evaluate the effects of deployed improvements on quality and process performance using statistical and other quantitative techniques.

ORGANIZATIONAL PROCESS PERFORMANCE -- PROCESS MANAGEMENT (ML4)

The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.

SG 1 Baselines and models, which characterize the expected process performance of the organization’s set of standard processes, are established and maintained.

SP 1.1 Establish and maintain the organization’s quantitative objectives for quality and process performance, which are traceable to business objectives. SP 1.2 Select processes or subprocesses in the organization’s set of standard processes to be included in the organization’s process performance analyses and maintain traceability to business objectives. SP 1.3 Establish and maintain definitions of measures to be included in the organization’s process performance analyses. SP 1.4 Analyze the performance of the selected processes, and establish and maintain the process performance baselines. SP 1.5 Establish and maintain process performance models for the organization’s set of standard processes.

ORGANIZATIONAL TRAINING -- PROCESS MANAGEMENT (ML3)

The purpose of Organizational Training (OT) is to develop skills and knowledge of people so they can perform their roles effectively and efficiently.

SG 1 A training capability, which supports the roles in the organization, is established and maintained.

SP 1.1 Establish and maintain strategic training needs of the organization. SP 1.2 Determine which training needs are the responsibility of the organization and which are left to the individual project or support group. SP 1.3 Establish and maintain an organizational training tactical plan. SP 1.4 Establish and maintain a training capability to address organizational training needs.

SG 2 Training for individuals to perform their roles effectively is provided.

SP 2.1 Deliver training following the organizational training tactical plan. SP 2.2 Establish and maintain records of organizational training. SP 2.3 Assess the effectiveness of the organization’s training program. PRODUCT INTEGRATION -- ENGINEERING (ML3)

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product.

SG 1 Preparation for product integration is conducted.

SP 1.1 Establish and maintain a product integration strategy. SP 1.2 Establish and maintain the environment needed to support the integration of the product components. SP 1.3 Establish and maintain procedures and criteria for integration of the product components.

SG 2 The product component interfaces, both internal and external, are compatible.

SP 2.1 Review interface descriptions for coverage and completeness. SP 2.2 Manage internal and external interface definitions, designs and changes for products and product components.

SG 3 Verified product components are assembled and the integrated, verified and validated product is delivered.

SP 3.1 Confirm, prior to assembly, that each product component required to assemble the product has been properly identified, behaves according to its description, and that the product component interfaces comply with the interface descriptions. SP 3.2 Assemble product components according to the product integration strategy and procedures. SP 3.2 Evaluate assembled product components for interface compatibility. SP 3.2 Package the assembled product or product component and deliver it to the customer.

Actualización de CMMi V1.3 (1)

2011-01-03T11:41:00.000-08:00

CAUSAL ANALYSIS AND RESOLUTION -- SUPPORT (ML5)

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance.

SG 1 Root causes of selected outcomes are systematically determined.

SP 1.1 Select outcomes for analysis. SP 1.2 Perform causal analysis of selected outcomes and propose actions to address them.

SG 2 Root causes of selected outcomes are systematically addressed.

SP 2.1 Implement selected action proposals developed in causal analysis. SP 2.2 Evaluate the effect of implemented actions on process performance. SP 2.3 Record causal analysis and resolution data for use across projects and the organization.

CONFIGURATION MANAGEMENT -- SUPPORT (ML2)

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

SG 1 Baselines of identified work products are established.

SP 1.1 Identify configuration items, components, and related work products to be placed under configuration management. SP 1.2 Establish and maintain a configuration management and change management system for controlling work products. SP 1.3 Create or release baselines for internal use and for delivery to the customer.

SG 2 Changes to the work products under configuration management are tracked and controlled.

SP 2.1 Track change requests for configuration items. SP 2.2 Control changes to configuration items.

SG 3 Integrity of baselines is established and maintained.

SP 3.1 Established and maintain records describing configuration items. SP 3.2 Perform configuration audits to maintain the integrity of configuration baselines.

DECISION ANALYSIS AND RESOLUTION -- SUPPORT (ML3)

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

SG 1 Decisions are based on an evaluation of alternatives using established criteria.

SP 1.1 Establish and maintain guidelines to determine which issues are subject to a formal evaluation process. SP 1.2 Establish and maintain criteria for evaluating alternatives and the relative ranking of these criteria. SP 1.3 Identify alternative solutions to address issues. SP 1.4 Select evaluation methods. SP 1.5 Evaluate alternative solutions using established criteria and methods. SP 1.6 Select solutions from alternatives based on evaluation criteria.

INTEGRATED PROJECT MANAGEMENT -- PROJECT MANAGEMENT (ML3)

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

SG 1 The project is conducted using a defined process tailored from the organization’s set of standard processes.

SP 1.1 Establish and maintain the project’s defined process from project startup through the life of the project. SP 1.2 Use organizational process assets and the measurement repository for estimating and planning project activities. SP 1.3 Establish and maintain the project’s work environment based on the organization’s work environment standards. SP 1.4 Integrate the project plan and other plans that affect the project to describe the project’s defined process. SP 1.5 Manage the project using the project plan, other plans that affect the project, and the project’s defined process. SP 1.6 Establish and maintain teams. SP 1.7 Contribute process related experiences to organizational process assets.

SG 2 Coordination and collaboration between the project and relevant stakeholders is conducted.

SP 2.1 Manage the involvement of relevant stakeholders in the project. SP 2.2 Participate with relevant stakeholders to identify, negotiate, and track critical dependencies. SP 2.3 Resolve issues with relevant stakeholders.

MEASUREMENT AND ANALYSIS -- SUPPORT (ML2)

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs.

SG 1 Measurement objectives and activities are aligned with identified information needs and objectives.

SP 1.1 Establish and maintain measurement objectives derived from identified information needs and objectives. SP 1.2 Specify measures to address measurement objectives. SP 1.3 Specify how measurement data are obtained and stored. SP 1.4 Specify how measurement data are analyzed and communicated.

SG 2 Measurement results, which address identified information needs and objectives, are provided.

SP 2.1 Obtain specified measurement data. SP 2.2 Analyze and interpret measurement data. SP 2.3 Manage and store measurement data, measurement specifications, and analysis results. SP 2.4 Communicate results of measurement and analysis activities to all relevant stakeholders.

ORGANIZATIONAL PROCESS DEFINITION -- PROCESS MANAGEMENT (ML3)

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.

SG 1 A set of organizational process assets is established and maintained.

SP 1.1 Establish and maintain the organization’s set of standard processes. SP 1.2 Establish and maintain descriptions of lifecycle models approved for use in the organization. SP 1.3 Establish and maintain tailoring criteria and guidelines for the organization’s set of standard processes. SP 1.4 Establish and maintain the organization’s measurement repository. SP 1.5 Establish and maintain the organization’s process asset library. SP 1.6 Establish and maintain work environment standards. SP 1.7 Establish and maintain organizational rules and guidelines for the structure, formation, and operation of teams.

Calidad de los datos - mySAP SCM

2010-12-01T11:11:00.000-08:00

El proceso de abastecimiento consta de los siguientes pasos: 1-Determinación de los requerimientos de materiales, 2-Determinación de la fuentes de suministro, 3-Selección del proveedor, 4-Procesamiento de la orden de compra, 5-Monitoreo de la orden de compra, 6-Recepción de bienes, 7-Verificación de la factura, 8-Procesamiento del pago

Cada uno de estos pasos consta de datos que serán ingresados a través de transacciones. El ingreso incorrecto de ciertos datos en las transacciones puede generar graves problemas. Los usuarios del módulo serán los responsables del ingreso de la información.

Dado que la calidad tiene componentes objetivos y subjetivos es necesario catalogar los requisitos de calidad de datos de los usuarios según unas determinadas dimensiones de calidad. Se intenta definir el concepto de calidad de datos y catalogar las dimensiones de calidad en función de unos determinados criterios, como pueden ser el ciclo de vida de los datos o los tipos de investigación realizadas o simplemente la forma en la que se usan los datos. Pero todos están de acuerdo en que la calidad de datos es un concepto multidimensional que comprende distintos aspectos según las necesidades de los consumidores de datos o de los diseñadores de sistemas, y que se justifica por el hecho de la concepción de calidad que aporta ISO.

Las dimensiones de calidad serían: (1) Facilidad de acceso, (2) Cantidad apropiada de datos, (3) Facilidad de compresión, (4) Credibilidad, (5) Disponibilidad temporal, (6) Objetividad, (7) Seguridad, (8) Facilidad de interpretación, (9) Relevancia y (10) Libres de errores.

CAR y OID en CMMi SVC v1.2 (12)

2010-12-01T10:25:00.001-08:00

CAUSAL ANALYSIS AND RESOLUTION

El propósito de ‘Causal Analysis and Resolution’ (CAR), perteneciente al Nivel de Madurez 5, es identificar las causas de los defectos u otros problemas y tomar la acción preventiva para que no suceda en un futuro. Esta área de proceso (AP) involucra la identificación y análisis de las causas de los defectos u otros problemas y efectuar las acciones correctivas para eliminar las causas y prevenir la ocurrencia de estos tipos de defectos o problemas en un futuro.

Esta AP mejora la calidad y productividad a través de la prevención de incorporación de defectos y ocurrencia de problemas. Algunos defectos o problemas pueden ser encontrados en otros proyectos. Las actividades de CAR son un mecanismo para comunicar las lecciones aprendidas entre los proyectos. Los tipos de defectos u otros problemas encontrados son analizados para identificar las tendencias. También se determinan las causas raíces de los defectos/problemas y las futuras implicaciones de los defectos. El análisis causal puede ser realizando en base a problemas no relacionados a los defectos.

CAR se relaciona con las siguientes AP: QPM, OID y MA.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Determine Causes of Defects and Problems

SP 1.1 - Select Defects and Problems

1.1.1- Gather relevant defect and problem data. 1.1.2- Determine the defects and problems to be analyzed further

SP 1.2 - Analyze Causes

1.2.1- Conduct causal analysis with those responsible for performing the task 1.2.2- Analyze selected defects and other problems to determine their root causes 1.2.3- Group selected defects and other problems based on their root causes 1.2.4- Propose and document actions to be taken to prevent the future occurrence of similar defects and problems

Productos de trabajo típicos

Defect and problem data selected for further analysis (SP 1.1) Action proposal (SP 1.2) Root cause analysis results (SP 1.2)

SG 2 - Address Causes of Defects and Problems

SP 2.1 - Implement Action Proposals

2.1.1- Analyze action proposals and determine their priorities 2.1.2- Select action proposals to be implemented 2.1.3- Create action items for implementing the action proposals 2.1.4- Identify and remove similar defects and problems that may exist in other processes and work products 2.1.5- Identify and document improvement proposals for the organization’s set of standard processes

SP 2.2 - Evaluate the Effect of Changes

2.2.1- Measure the change in the performance of the project's defined process or of subprocesses as appropriate 2.2.2- Measure the capability of the project's defined process or of subprocesses, as appropriate

SP 2.3 - Record Data

Productos de trabajo típicos

Action proposals selected for implementation (SP 2.1) Improvement proposals (SP 2.1) Measures of performance and performance change (SP 2.2) Causal analysis and resolution records (SP 2.3)

ORGANIZATIONAL INNOVATION AND DEPLOYMENT

El propósito de ‘Organizational Innovation and Deployment’ (OID), perteneciente al Nivel de Madurez 5, es seleccionar y desplegar las mejoras de innovación que permiten mejorar las tecnologías y procesos de la organización. Estas mejoras están asociadas a los objetivos de calidad y de performance del proceso. Estos objetivos incluyen lo siguiente: (1) calidad del producto mejorada, (2) aumento de la productividad, (3) disminución del tiempo del ciclo, (4) mayor satisfacción del cliente o usuario final, (5) disminución del tiempo de entrega y (6) disminución de los tiempos de adaptación de nuevas tecnologías y necesidades del negocio.

OID se relaciona con las siguientes áreas de proceso: DAR, MA, OPP y OT.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Select Improvements

SP 1.1 - Collect and Analyze Improvement Proposals

1.1.1- Collect process- and technology-improvement proposals 1.1.2- Analyze the costs and benefits of process- and technology-improvement proposals as appropriate 1.1.3- Identify the process- and technology-improvement proposals that are innovative 1.1.4- Identify potential barriers and risks to deploying each process- and technology-improvement proposal 1.1.5- Estimate the cost, effort, and schedule required for deploying each process- and technology-improvement proposal. 1.1.6- Select the process- and technology-improvement proposals to be piloted before broadscale deployment. 1.1.7- Document the results of the evaluation of each process- and technology-improvement proposal. 1.1.8- Monitor the status of each process- and technology-improvement proposal.

SP 1.2 - Identify and Analyze Innovations

1.2.1- Analyze the organization's set of standard processes to determine areas in which innovative improvements would be most helpful. 1.2.2- Investigate innovative improvements that may improve the organization's set of standard processes. 1.2.3- Analyze potential innovative improvements to understand their effects on process elements and predict their influence on the process. 1.2.4- Analyze the costs and benefits of potential innovative improvements 1.2.5- Create process- and technology-improvement proposals for those innovative improvements that would result in improving the organization's processes or technologies 1.2.6- Select the innovative improvements to be piloted before broadscale deployment. 1.2.7- Document results of evaluations of innovative improvements

SP 1.3 - Pilot Improvements

1.3.1- Plan the pilots. 1.3.2 - Review and get relevant stakeholder agreement on plans for the pilots. 1.3.3- Consult with and assist those performing the pilots. 1.3.4- Perform each pilot in an environment that is characteristic of the environment present in a broadscale deployment. 1.3.5- Track pilots against their plans. 1.3.6- Review and document the results of pilots.

SP 1.4 - Select Improvements for Deployment

1.4.1- Prioritize candidate process and technology improvements for deployment. 1.4.2- Select the process and technology improvements to be deployed 1.4.3- Determine how each process and technology improvement will be deployed 1.4.4- Document the results of the selection process.

Productos de trabajo típicos

Analyzed process- and technology-improvement proposals (SP 1.1) Candidate innovative improvements (SP 1.2) Analysis of proposed innovative improvements (SP 1.2) Pilot evaluation reports (SP 1.3) Documented lessons learned from pilots (SP 1.3) Process and technology improvements selected for deployment (SP 1.4)

SG 2 - Deploy Improvements

SP 2.1- Plan the Deployment

2.1.1- Determine how each process and technology improvement must be adjusted for organization-wide deployment. 2.1.2- Determine the changes needed to deploy each process and technology improvement. 2.1.3- Identify strategies to address potential barriers to deploying each process and technology improvement 2.1.4- Establish measures and objectives for determining the value of each process and technology improvement with respect to the organization’s quality and process-performance objectives 2.1.5- Document the plans for deploying selected process and technology improvement 2.1.6- Review and get agreement with relevant stakeholders on the plans for deploying selected process and technology improvement 2.1.7- Revise the plans for deploying selected process and technology improvement as necessary

SP 2.2 - Manage the Deployment

2.2.1- Monitor the deployment of process and technology improvements using the deployment plans. 2.2.2- Coordinate the deployment of process and technology improvements across the organization. 2.2.3- Quickly deploy process and technology improvements in a controlled and disciplined manner as appropriate. 2.2.4- Incorporate process and technology improvements into organizational process assets as appropriate. 2.2.5- Coordinate the deployment of process and technology improvements into the projects' defined processes as appropriate. 2.2.6- Provide consulting, as appropriate, to support deployment of process and technology improvements. 2.2.7- Provide updated training materials to reflect the improvements to organizational process assets. 2.2.8- Confirm that the deployment of all process and technology improvements is completed 2.2.9- Determine whether the ability of the defined process to meet quality and process-performance objectives is adversely affected by the process and technology improvement, and take corrective action as necessary. 2.2.10- Document and review results of process- and technology-improvement deployment

SP 2.3 - Measure Improvement Effects

2.3.1- Measure the actual cost, effort, and schedule for deploying each process and technology improvement. 2.3.2- Measure the value of each process and technology improvement. 2.3.3- Measure the progress toward achieving the organization's quality and process-performance objectives. 2.3.4- Analyze the progress toward achieving the organization's quality and process-performance objectives and take corrective action as needed. 2.3.5- Store the measures in the organization’s measurement repository.

Productos de trabajo típicos

Deployment plans for selected process and technology improvements (SP 2.1) Updated training materials (SP 2.2) Documented results of process- and technology-improvement deployment activities (SP 2.2) Revised process- and technology-improvement measures, objectives, priorities, and deployment plans (SP 2.2) Documented measures of the effects resulting from the deployed process and technology improvements (SP 2.3)

OPP y QPM en CMMi SVC v1.2 (11)

2010-11-10T06:04:00.000-08:00

ORGANIZATIONAL PROCESS PERFORMANCE

El propósito de ‘Organization Process Performance’ (OPP), perteneciente al Nivel de Madurez 4, es establecer y mantener un entendimiento cuantitativo del performance del conjunto de procesos estándares de la organización, de acuerdo a los objetivos de calidad y de performance del proceso. Esta área de proceso tiene el propósito de suministrar datos acerca del performance del proceso, líneas de base y modelos para administrar cuantitativamente los proyectos de la organización.

El performance del proceso es una medida de los resultados actuales logrados por un proceso. El performance del proceso está caracterizado por las mediciones del proceso (esfuerzo, tiempo del ciclo, eficacia en la eliminación de defectos, etc.) y del producto (confiabilidad, densidad del defecto, capacidad, tiempo de respuesta y costo).

Las mediciones de la organización consisten de mediciones de proceso y producto que pueden ser usadas para caracterizar el performance actual de los procesos de los proyectos de la organización.

Los modelos de performance del proceso son usados para representar el performance actual y pasado del proceso; y predecir los futuros resultados del proceso. OPP se relaciona con las siguientes áreas de proceso: CAM, SSM, MA y QPM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Establish Performance Baselines and Models

SP 1.1 - Select Processes

SP 1.2 - Establish Process Performance Measures

1.2.1- Determine which of the organization’s business objectives for quality and process performance should be addressed by the measures. 1.2.2- Select measures that provide appropriate insight into the organization’s quality and process performance 1.2.3- Incorporate selected measures into the organization’s set of common measures. 1.2.4- Revise the set of measures as necessary

SP 1.3 - Establish Quality and Process-Performance Objectives

1.3.1- Review the organization’s business objectives related to quality and process performance 1.3.2- Define the organization’s quantitative objectives for quality and process performance 1.3.3- Define the priorities of the organization’s objectives for quality and process performance. 1.3.4- Review, negotiate, and obtain commitment for the organization’s quality and process-performance objectives and their priorities from relevant stakeholders. 1.3.5- Revise the organization’s quantitative objectives for quality and process performance as necessary.

SP 1.4 - Establish Process Performance Baselines

1.4.1- Collect measurements from the organization’s projects. 1.4.2- Establish and maintain the organization’s process-performance baselines from collected measurements and analyses 1.4.3- Review and get agreement with relevant stakeholders about the organization's process-performance baselines. 1.4.4- Make the organization's process-performance information available across the organization in the organization's measurement repository. 1.4.5- Compare the organization’s process-performance baselines to associated objectives. 1.4.6- Revise the organization’s process-performance baselines as necessary.

SP 1.5 - Establish Process Performance Models

1.5.1- Establish process-performance models based on the organization’s set of standard processes and the organization’s process-performance baselines. 1.5.2- Calibrate process-performance models based on the organization’s past results and current needs. 1.5.3- Review process-performance models and get agreement with relevant stakeholders. 1.5.4- Support the projects’ use of the process-performance models. 1.5.5- Revise process-performance models as necessary.

Productos de trabajo típicos

List of processes or subprocesses identified for process-performance analyses (SP 1.1) Definitions of selected measures of process performance (SP 1.2) Organization's quality and process-performance objectives (SP 1.3) Baseline data on the organization’s process performance (SP 1.4) Process-performance models (SP 1.5)

QUANTITATIVE PROJECT MANAGEMENT

El propósito de ‘Quantitative Project Management’ (QPM), perteneciente al Nivel de Madurez 4, es administrar cuantitativamente el proceso definido del proyecto para lograr los objetivos de performance del proceso y de calidad.

Para la implementación de esta área de proceso, la organización debe tener un conjunto de procesos estándar establecidos y relacionado a las ventajas del proceso organizacional, así como repositorio de las mediciones realizadas. El proceso definido del proyecto es un conjunto de subprocesos que forman una estructura de actividades del proyecto.

El performance del proceso es una medición de los resultados logrados del actual proceso. Este performance está caracterizado por mediciones de proceso (p.e esfuerzo, tiempo del ciclo y eficacia en la eliminación de defectos) y mediciones de producto (p.e confiabilidad, densidad del defecto y tiempo de respuesta).

QPM se relaciona con las siguientes áreas de proceso: CAM, SSM, CAR, IPM, MA, OID, OPD, OPP y PMC.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Quantitatively Manage the Project

SP 1.1 - Establish the Project’s Objectives

1.1.1- Review the organization's objectives for quality and process performance 1.1.2- Identify the quality and process performance needs and priorities of the customer, suppliers, end users, and other relevant stakeholders. 1.1.3- Identify how quality and process performance is to be measured. 1.1.4- Define and document measurable quality and process-performance objectives for the project. 1.1.5- Derive interim objectives for each lifecycle phase, as appropriate, to monitor progress toward achieving the project’s objectives. 1.1.6- Resolve conflicts among the project’s quality and process-performance objectives 1.1.7- Establish traceability to the project’s quality and process-performance objectives from their sources. 1.1.8- Define and negotiate quality and process-performance objectives for suppliers 1.1.9- Revise the project’s quality and process-performance objectives as necessary

SP 1.2 - Compose the Defined Process

1.2.1- Establish the criteria to use in identifying which subprocesses are valid candidates for use. 1.2.2- Determine whether the subprocesses that are to be statistically managed, and were obtained from organizational process assets are suitable for statistical management 1.2.3- Analyze the interaction of subprocesses to understand relationships among subprocesses and measured attributes of the subprocesses. 1.2.4- Identify the risk when no subprocess is available that is known to be capable of satisfying quality and process-performance objectives

SP 1.3 - Select Subprocesses to be Statistically Managed

1.3.1- Identify which of the project’s quality and process-performance objectives will be statistically managed. 1.3.2- Identify criteria to be used in selecting subprocesses that are the main contributors to achieving identified quality and process-performance objectives and for which predictable performance is important. 1.3.3- Select subprocesses to be statistically managed using selection criteria. 1.3.4- Identify product and process attributes of selected subprocesses to be measured and controlled.

SP 1.4 - Manage Project Performance

1.4.1- Periodically review the performance and capability of each subprocess selected to be statistically managed to appraise progress toward achieving the project’s quality and process-performance objectives. 1.4.2- Periodically review actual results achieved against established interim objectives for each phase of the project lifecycle to appraise progress toward achieving the project’s quality and process-performance objectives 1.4.3- Track suppliers results for achieving their quality and process-performance objectives. 1.4.4- Use process-performance models calibrated with obtained measures of critical attributes to estimate progress toward achieving the project’s quality and process-performance objectives. 1.4.5- Identify and manage risks associated with achieving the project’s quality and process-performance objectives. 1.4.6- Determine and document actions needed to address deficiencies in achieving the project’s quality and process-performance objectives.

Productos de trabajo típicos

The project’s quality and process-performance objectives (SP 1.1) Criteria used to identify which subprocesses are valid candidates for inclusion in the project’s defined process (SP 1.2) Candidate subprocesses for inclusion in the project’s defined process (SP 1.2) Subprocesses to be included in the project’s defined process (SP 1.2) Identified risks when selected subprocesses lack a process-performance history (SP 1.2)

Quality and process-performance objectives to be addressed by statistical management (SP 1.3) Criteria used in selecting which subprocesses will be statistically managed (SP 1.3) Subprocesses to be statistically managed (SP 1.3) Identified process and product attributes of selected subprocesses that should be measured and controlled (SP 1.3)

Estimates (predictions) of the achievement of the project’s quality and process-performance objectives (SP 1.4) Documentation of risks in achieving the project’s quality and process-performance objectives (SP 1.4) Documentation of actions needed to address deficiencies in achieving project objectives (SP 1.4)

SG 2 - Statistically Manage Subprocess Performance

SP 2.1 - Select Measures and Analytic Techniques

2.1.1- Identify common measures from the organizational process assets that support statistical management. 2.1.2- Identify additional measures that may be needed for this instance to cover critical product and process attributes of the selected subprocesses. 2.1.3- Identify the measures that are appropriate for statistical management. 2.1.4- Specify the operational definitions of measures, their collection points in subprocesses, and how the integrity of measures will be determined. 2.1.5- Analyze the relationship of identified measures to the objectives of the organization and its projects, and derive objectives that state target measures or ranges to be met for each measured attribute of each selected subprocess. 2.16- Instrument the organizational or project support environment to support collection, derivation, and analysis of statistical measures. 2.17- Identify appropriate statistical analysis techniques that are expected to be useful in statistically managing the selected subprocesses. 2.1.8- Revise the measures and statistical analysis techniques as necessary.

SP 2.2 - Apply Statistical Methods to Understand Variation

2.2.1- Establish trial natural bounds for subprocesses having suitable historical performance data 2.2.2- Collect data, as defined by the selected measures, on subprocesses as they execute 2.2.3- Calculate the natural bounds of process performance for each measured attribute 2.2.4- Identify special causes of variation 2.2.5- Analyze special causes of process variation to determine the reasons why the anomaly occurred 2.2.6- Determine the corrective action to be taken when special causes of variation are identified 2.2.7- Recalculate natural bounds for each measured attribute of the selected subprocesses as necessary

SP 2.3 - Monitor the Performance of Selected Subprocesses

2.3.1- Compare quality and process-performance objectives to the natural bounds of the measured attribute. 2.3.2- Monitor changes in quality and process-performance objectives and the process capability of the selected subprocess. 2.3.3- Identify and document deficiencies in subprocess capability. 2.3.4- Determine and document actions needed to address deficiencies in subprocess capability.

SP 2.4 - Record Statistical Management Data

Productos de trabajo típicos

Definitions of measures and analytic techniques to be used to statistically manage subprocesses (SP 2.1) Operational definitions of measures, their collection points in subprocesses, and how the integrity of measures will be determined (SP 2.1) Traceability of measures back to the project’s quality and process-performance objectives (SP 2.1) Instrumented organizational support environment that support automatic data collection (SP 2.1)

Collected measurements (SP 2.2) Natural bounds of process performance for each measured attribute of each selected subprocess (SP 2.2) Process performance compared to the natural bounds of process performance for each measured attribute of each selected subprocess (SP 2.2)

Natural bounds of process performance for each selected subprocess compared to its established (derived) objectives (SP 2.3) The process capability of each subprocess (SP 2.3) The actions needed to address deficiencies in the process capability of each subprocess (SP 2.3) Statistical and quality management data recorded in the organization’s measurement repository (SP 2.4)

Kaizen - mySAP SCM

2010-11-10T06:03:00.001-08:00

La estrategia de Kaizen es el concepto de mayor importancia en la administración japonesa- la clave del éxito competitivo japonés. Los dos pilares que sustentan Kaizen son los equipos de trabajo y la ingeniería industrial, que se emplean para mejorar los procesos productivos. De hecho, Kaizen se enfoca a la gente y a la estandarización de los procesos. Su práctica requiere de un equipo integrado por personal de producción, mantenimiento, calidad, ingeniería, compras y demás empleados que el equipo considere necesario.

Kaizen significa “mejoramiento continuo” como un todo en la vida personal, hogareña, social y en el trabajo. Esto se encuentra en la industria, en la agricultura, en el gobierno, en la educación o en su propia vida personal.

Los objetivos de Kaizen son: (1) Reducir las pérdidas, (2) Mejorar la calidad, (3) Reducir los tiempos de entrega, (4) Aumentar la satisfacción del trabajador y (5) Aumentar la satisfacción del cliente

Kaizen es una propuesta de equipo orientada a resultados y que permite un rápido mejoramiento continuo. La aplicación de Kaizen implica que los empleados realicen mejoramientos dentro de un área o proyecto específico de manera inmediata. A través de esta participación, los empleados obtienen conocimientos y entienden las herramientas de Kaizen y aprenden cómo implementarlas para así dar a la compañía un marco competitivo con mayores beneficios económicos.

El Modelo de implementación de Kaizen está organizado en 4 etapas:

Etapa 1 – Inicio y Demostración de la propuesta Kaizen: Crear la estrategia, visión y estructura organizacional para implementar el proceso Kaizen. Esta etapa se caracteriza por un gran y significativo mejoramiento en las áreas del modelo.

Etapa 2 – Modelizar y practicar el proceso Kaizen: Desarrollar áreas piloto dentro de los modelos de clase mundial a ser imitados por otras áreas. Alinear e integrar las estructuras y metas de la organización con el proceso Kaizen. Durante esta etapa, el proceso traslada los eventos de alto nivel de mejoramiento a una cultura sostenida del mejoramiento continuo.

Etapa 3 – Estandarizar y Ampliar el proceso de Kaizen: Ampliar el proceso Kaizen estandarizado a todos los sistemas y niveles de la organización. Alinear e integrar las estructuras y metas de la organización al proceso Kaizen.

Etapa 4 –Sistematizar el proceso Kaizen: Difundir el proceso Kaizen en todas las partes de la organización, incluyendo vendedores y distribuidores. Kaizen impacta en los elementos estratégicos de una organización. La capacidad de la organización de responder a las demandas competitivas se reafirma en forma constante.

Todo lo mencionado anteriormente puede ser aplicado al proceso de abastecimiento, el cual consta de los siguientes pasos: 1-Determinación de los requerimientos de materiales, 2-Determinación de la fuentes de suministro, 3-Selección del proveedor, 4-Procesamiento de la orden de compra, 5-Monitoreo de la orden de compra, 6-Recepción de bienes, 7-Verificación de la factura, 8-Procesamiento del pago

Cada uno de estos puede ser analizado, cambiado y/o mejorado para de esta forma contribuir a los objetivos de la empresa. Este mejoramiento puede incluir añadir nuevas aplicaciones a las existentes en módulo MM.

Stock especiales externos - mySAP SCM

2010-10-06T10:25:00.000-07:00

Se tienen stocks especiales externos pertenecientes a un proveedor o cliente que se almacenan en su empresa. En el Sistema están disponibles los siguientes tipos de stocks especiales externos: (1) Consignación en proveedor, (2) Embalaje retornable para transporte, (3) Stock para pedido de cliente y (4) Stock para proyecto. Puesto que estos stocks especiales están ubicados en su propia empresa, se gestionan a nivel de almacén.

Estos stocks especiales pueden asignarse a tres tipos de stocks diferentes: (1) Stock de libre utilización, (2) Stock en control de calidad y (3) Stock bloqueado Todos los tipos de stocks pueden inventariarse.

Consignación en proveedor

Este tipo de stocks comprende material en consignación perteneciente al proveedor que se almacena en sus dependencias. Los stocks de artículos en consignación del proveedor están disponibles para la planificación de necesidades de material.

Embalaje retornable para transporte

Medio de embalaje retornable (como palets o containers) con el que pueden transportarse las mercancías entre proveedores y clientes. Al ser propiedad del proveedor, no está incluido en el stock valorado del cliente.

Stock para pedido de cliente

Es el stock que se utiliza para un pedido de cliente. Se asigna directamente a un pedido de cliente. Los componentes sólo pueden utilizarse para fabricar material solicitado por el cliente y sólo puede entregarse el producto terminado al cliente mediante un pedido de cliente.

Stock para proyecto

Es la cantidad de un material que se retiene en stock para la conclusión de un proyecto. El stock para proyecto se asigna a un elemento del plan de la estructura del proyecto (elemento PEP). Los componentes sólo pueden retirarse para ese elemento PEP.

SST y SSM en CMMi SVC V1.2 (10)

2010-10-06T07:44:00.001-07:00

SERVICE SYSTEM TRANSITION

El propósito de ‘Service System Transition’ (SST), perteneciente al Nivel de Madurez 3, es realizar componentes nuevos o actualizados del sistema de servicio mientras se administra su efecto en el suministro del servicio. Esta área de proceso trata todos los aspectos de planificación, comunicación, manejo, despliegue y confirmación que los componentes del sistema de servicio realizan en la transición al ambiente de suministro. El alcance de esta área de proceso abarca los nuevos componentes y los cambios de los existentes.

Los aspectos críticos de una transición de sistema de servicio incluye lo siguiente: (1) Control de la configuración de los componentes del sistema de servicio, (2) Administración de las interfaces internas y externas, (3) Despliegue de los componentes del sistema de servicio en el ambiente de entrega, (4) Aceptación de las partes interesadas de los componentes nuevos o revisados del sistema de servicio y (5) Administración de los impactos de la transición.

SST se relaciona con las siguientes áreas de proceso: IRP, SC, SD, SSD, CAR y CM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 – Prepare the Service System Transition

SP 1.1 – Analyze Service System Transition Needs

1.1.1- Establish a baseline of the current service system, if it has not been done previously. 1.1.2-Analyze the current service system as it operates within the current delivery environment. 1.1.3- Analyze the service system components that are proposed for transition (e.g., the post-transition or to-be service system) for potential compatibility, functionality, or interface issues. 1.1.4- Identify and mitigate potential issues.

SP 1.2 – Develop Service System Transition Plans

1.2.1- Define the deployment approach for each specific service system transition 1.2.2- Determine the cost, resources, and schedule required for transition of the service system to a new or changed operational state 1.2.3- Identify relevant stakeholders for transition activities. 1.2.4- Develop a service system transition plan. 1.2.5- Obtain stakeholder commitment to the plan 1.2.6- Establish a baseline of the transition plan. 1.2.7- If new or significantly changed essential functions are part of a transition, ensure that the service continuity plan is refreshed to include the new functionality.

SP 1.3 – Prepare Stakeholders for Changes

1.3.1- Establish and maintain a transition notification strategy. 1.3.2- Implement the notification strategy to keep relevant stakeholders informed about scheduled changes in services and service availability during the transition. 1.3.3- Establish and maintain a transition training strategy. 1.3.4- Implement the training strategy.

Productos de trabajo típicos

Compatibility analysis of current and post-transition service systems (SP 1.1) Issues to be addressed and risks to be mitigated associated with the transition (SP 1.1) Plans for service system transition (SP 1.2) Transition notification strategy (SP 1.3) Transition training strategy (SP 1.3)

SG 2 – Deploy the Service System

SP 2.1 – Deploy Service System Components

2.1.1- Confirm that service system components to be deployed are placed under configuration control as appropriate 2.1.2- Install the service system into the delivery environment. 2.1.3- Validate service system components in the delivery environment. 2.1.4- In the case of service system component retirement, archive the service system components appropriately and remove them from the delivery environment

SP 2.2 – Assess and Control the Impact of the Transition

2.2.1- Use data gathering methods to obtain input from relevant stakeholders about the deployment 2.2.2- Proactively communicate information about deployment impacts 2.2.3- For significant impacts, refer to the tactical plan for details about how and when deployment backout or rollback should be performed. 2.2.4- Continue to assess and control impacts until deployment issues are resolved. 2.2.5- Conduct a post-deployment review.

Productos de trabajo típicos

Installation records (SP 2.1) Deployment evaluation artifacts (SP 2.1) Post deployment review (SP 2.2) Deployment assessment artifacts (SP 2.2)

STRATEGIC SERVICE MANAGEMENT

El propósito de ‘Strategic Service Management’ (SSM), perteneciente al Nivel de Madurez 3, es establecer y mantener servicios estándares que se correspondan con las necesidades estratégicas y planes. Esta área de proceso tiene como objetivo tener información necesaria para la toma de decisiones estratégicas acerca del conjunto de servicio estándares que tiene la organización. Los servicios estándares son descriptos en un catálogo que está orientado a las necesidades de información de los clientes.

SST se relaciona con las siguientes áreas de proceso: IRP, SD, SSD, OPD, PMC y REQM Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 – Establish Strategic Needs and Plans for Standard Services

SP 1.1 – Gather and Analyze Relevant Data

1.1.1 - Gather and analyze data on the organization’s capabilities. 1.1.2 - Gather and analyze data on the organization’s strategic needs. 1.1.3 - Describe the organization’s capabilities and strategic needs. 1.1.4 - Communicate the descriptions to relevant stakeholders

SP 1.2 – Establish Plans for Standard Services

1.2.1 - Confirm strategic business objectives 1.2.2 -Recommend requirements for standard services based on strategic business objectives, the organization’s capabilities, and strategic needs. 1.2.3 - Identify needed actions on standard services 1.2.4 - Review and get agreement from relevant stakeholders on the standard services to be established and maintained

Productos de trabajo típicos

Analyzed data on the organization’s capabilities (SP 1.1) Analyzed data on strategic needs (SP 1.1) Descriptions of the organization’s capabilities (SP 1.1) Descriptions of strategic needs (SP 1.1)

Descriptions of strategic business objectives (SP 1.2) Prospective service descriptions (SP 1.2) Analysis of service system needs (SP 1.2) Decision or approval packages for selected services (SP 1.2) Plans for standard services (SP 1.2)

SG 2 – Establish Standard Services

SP 2.1 – Establish Properties of Standard Services and Service Levels

2.1.1 - Select standard services 2.1.2 - Specify the critical attributes of each service 2.1.3 - Determine common and variable parts of standard services. 2.1.4 - Organize services into service lines as needed 2.1.5 - Define service levels. 2.1.6 - Establish tailoring criteria as appropriate

SP 2.2 – Establish Descriptions of Standard Services

2.2.1 - Develop the descriptions of standard services for all relevant users 2.2.2 - Conduct peer reviews on the descriptions with relevant stakeholders. 2.2.3 - Revise the descriptions as necessary. 2.2.4 - Store the descriptions in a location and medium where all intended users have access

Productos de trabajo típicos

Critical attributes of standard services (SP 2.1) Organization’s set of standard service levels (SP 2.1) Templates for service level agreements (SLAs) (SP 2.1) Tailoring criteria (SP 2.1) Common and variable parts of standard services (SP 2.1) Grouping of services into service lines (SP 2.1)

Descriptions of services (SP 2.2) Service catalog or menu (SP 2.2) Adjunct materials such as instructions for delivery staff, sales force instructions, proposal and pricing information, and contracting information (SP 2.2)

SC y SSD en CMMI SVC V1.2 (9)

2010-09-02T10:16:00.000-07:00

SERVICE CONTINUITY

El propósito de ‘Service Continuity’ (SC), perteneciente al Nivel de Madurez 3, es establecer y mantener planes para asegurar la continuidad de los servicios durante la irrupción de las operaciones. La continuidad del servicio es el proceso que consiste en preparar la mitigación de irrupciones en la entrega del servicio. Las practicas de esta área de proceso describen como preparar los sistemas de servicios y los recursos para asegurar un nivel crítico mínimo del servicio pueda continuar si se produce un riesgo significativo.

Esta área de proceso se puede aplicar a nivel organizacional y a nivel proyecto. La irrupción de un servicio es una situación que involucra un evento que hace imposible que el proveedor del servicio realice su negocio.

SC abarca el desarrollo, prueba y mantenimiento de los planes de continuidad del servicio. SC se relaciona con las siguientes áreas de proceso: SD, DAR, OT, PP y RSKM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 – Identify Essential Service Dependencies

SP 1.1 - Identify and Prioritize Essential Functions

1.1.1- Identify and prioritize the essential services of the organization. 1.1.2- Identify the essential functions on which services rely. 1.1.3- Analyze the criticality of providing those functions and the impact to services if the essential functions cannot be performed. 1.1.4- Prioritize the list of essential functions that must be provided despite a significant disruption.

SP 1.2 - Identify and Prioritize Essential Resources

1.2.1- Identify and document internal and external dependencies. 1.2.2- Identify and document key personnel and their roles in relation to service delivery. 1.2.3- Identify and document organizational and relevant stakeholder responsibilities. 1.2.4- Identify and document resources required by essential functions to ensure continuity. 1.2.5- Prioritize resources based on an evaluation of impact from their loss or from lack of access. 1.2.6- Ensure safety provisions are made for personnel, both internal and external, within the delivery environment and for organizational supporting functions. 1.2.7- Ensure that records and databases are protected, accessible, and usable in an emergency.

Productos de trabajo típicos

A business impact analysis (SP 1.1) Orders of succession (SP 1.2) Delegations of authority (SP 1.2) Directory of critical personnel with contact information (SP 1.2) Data and systems required to support identified essential service functions (SP 1.2) Records of service agreements and contracts (SP 1.2) Records of legal operating charters (e.g., articles of incorporation, authorization by local, state, or national government agencies) (SP 1.2) Personnel benefit balances, payroll, and insurance records (SP 1.2) List of internal and external resources required (SP 1.2) List of dependencies and interdependencies of resources (SP 1.2)

SG 2 – Prepare for Service Continuity

SP 2.1 – Establish Service Continuity Plans

2.1.1- Identify and document threats and vulnerabilities to ongoing service delivery. 2.1.2- Document the service continuity plan. 2.1.3- Review the service continuity plan with relevant stakeholders 2.1.4- Ensure that secure storage and access methods exist for the service continuity plan and critical information and functions needed to implement the plan. 2.1.5- Ensure that vital data and systems are adequately protected. 2.1.6- Document the acceptable service level agreed to by the customer for when a shift between the normal delivery environment and the recovery environment (e.g., site affected by disruption, alternate site) is necessary. 2.1.7- Plan for returning to normal working conditions. 2.1.8- Develop procedures for implementing the service continuity plan. 2.1.9- Revise the service continuity plan as necessary.

SP 2.2 – Establish Service Continuity Training

2.2.1- Develop a strategy for conducting service continuity training. 2.2.2- Develop and document service continuity training for each category of threat and vulnerability to service delivery. 2.2.3- Review service continuity training material with relevant stakeholders 2.2.4- Revise the training material as needed to reflect changes in the service continuity plan and feedback on training effectiveness.

SP 2.3 – Provide and Evaluate Service Continuity Training

2.3.1- Deliver training that covers the execution of the service continuity plan to appropriate personnel. 2.3.2- Maintain records of those who successfully complete service continuity training. 2.3.3- Solicit feedback on how well service continuity training prepared those who will execute the service continuity plan. 2.3.4- Analyze training feedback and document suggested improvements to the service continuity plan and service continuity training.

Productos de trabajo típicos

Formal statement of who has the authority to initiate and execute the service continuity plan (SP 2.1) List of communication mechanisms needed to initiate the execution of the service continuity plan (SP 2.1) List of threats and vulnerabilities that could impede the ability of the organization to deliver services (SP 2.1) List of alternate resources and locations that support the organization’s essential functions (SP 2.1) Documentation of the recovery sequence (SP 2.1) List of key personnel’s roles and responsibilities (SP 2.1) List of stakeholders and the methods used for communicating with them (SP 2.1) Documented methods for handling security-related material, as appropriate (SP 2.1)

Service continuity training material (SP 2.2) Training records (SP 2.3) Evaluations of training effectiveness by students and training specialists (SP 2.3) Suggested improvements to the service continuity plan (SP 2.3)

SG 3 – Verify and Validate the Service Continuity Plan

SP 3.1 – Prepare for the Verification and Validation of the Service Continuity Plan

3.1.1- Develop a plan for conducting service continuity verification and validation. 3.1.2- Review with relevant stakeholders the verification and validation plan, including evaluation methods and the environments and other resources that will be needed. 3.1.3- Determine the procedures and criteria for verification and validation of the service continuity plan. 3.1.4- Identify changes to the service continuity plan from the preparation for verification and validation.

SP 3.2 Verify and Validate the Service Continuity Plan

Prepare the environment to conduct verification and validation. 2. Conduct verification and validation of the service continuity plan. 3. Record the results of verification and validation activities

SP 3.3 - Analyze Results of Verification and Validation

3.3.1- Compare actual to expected results of service continuity plan verification and validation. 3.3.2- Evaluate whether restoration to agreed service levels or some other planned state was achieved or not. 3.3.3- Document recommendations for improving the service continuity plan. 3.3.4- Document recommended improvements to the verification and validation of the service continuity plan. 3.3.5- Collect improvement proposals for services or service system components as appropriate based on the analyses of results. 3.3.6- Provide information on how defects can be resolved (including verification methods, criteria, and the verification environment) and initiate corrective action.

Productos de trabajo típicos

Verification and validation plan for assuring service continuity (SP 3.1) Evaluation methods used for verification and validation (SP 3.1) Description of environments necessary to conduct verification and Validation (SP 3.1) Verification and validation procedures (SP 3.1) Criteria for what constitutes successful verification and validation (SP 3.1)

Roster of personnel and stakeholders involved in service continuity verification and validation (SP 3.2) Results of service continuity plan verification and validation (SP 3.2)

Verification and validation analysis reports (SP 3.3) Improvement recommendations for the service continuity plan (SP 3.3) Verification and validation improvement recommendations (SP 3.3)

SERVICE SYSTEM DEVELOPMENT

El propósito de ‘Service System Development’ (SSD), perteneciente al Nivel de Madurez 3, es analizar, diseñar, desarrollar, verificar y validar los sistemas de servicios, incluyendo los componentes del servicio, para satisfacer los acuerdos de servicio actuales y anticipados.Esta área de proceso es aplicable a todos los aspectos de un sistema de servicio. Se puede aplicar a nuevos sistemas de servicios y a cambios de los sistemas de servicios actuales.

Un sistema de servicio es una combinación integrada e interdependiente de los componentes del sistema de servicio que satisface los requerimientos de las partes interesadas.

Un componente de sistema de servicio es un proceso, producto de trabajo, persona, producto, cliente u otro recurso necesario para que el sistema de servicio tenga valor. SSD se relaciona con las siguientes áreas de proceso: SD, SST, SSM, DAR, OID y REQM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 – Develop and Analyze Stakeholder Requirements

SP 1.1 – Develop Stakeholder Requirements 1.1.1- Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces. 1.1.2- Transform stakeholder needs, expectations, constraints, and interfaces into stakeholder requirements 1.1.3- Define constraints for verification and validation

SP 1.2 – Develop Service System Requirements

1.2.1- Develop requirements and express them in the terms necessary for service and service system design. 1.2.2- Derive requirements that result from solution selections and design decisions. 1.2.3- Establish and maintain relationships among requirements for consideration during change management and requirements allocation. 1.2.4- Allocate the requirements to service system components. 1.2.5- Identify interfaces both external and internal to the service system. 1.2.6- Develop requirements for the identified interfaces.

SP 1.3 – Analyze and Validate Requirements

1.3.1- Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate 1.3.2- Develop a detailed operational concept that defines the interaction of the service system, end users, and the environment, and that satisfies operational, maintenance, support, and disposal needs. 1.3.3- Establish and maintain a definition of required functionality. 1.3.4- Analyze requirements to ensure that they are necessary, sufficient, and balance stakeholder needs and constraints. 1.3.5- Validate requirements to ensure the resulting service system will perform as intended in the user’s environment

Productos de trabajo típicos

Customer requirements (SP 1.1) End-user requirements (SP 1.1) Customer and end-user constraints on the conduct of verification and validation (SP 1.1) Staffing level constraints Evaluation (SP 1.1)

Derived requirements with relationships and priorities (SP 1.2) Service requirements (SP 1.2) Service system requirements (SP 1.2) Requirement allocations (SP 1.2) Design constraints (SP 1.2) Interface requirements (SP 1.2) Skill-level requirements (SP 1.2)

Operational concepts, use cases, activity diagrams, and timeline scenarios (SP 1.3) Service system and service system component installation, training, operational, maintenance, support, and disposal concepts (SP 1.3) New requirements (SP 1.3) Functional architecture (SP 1.3) Requirements defects reports and proposed changes to resolve (SP 1.3) Assessment of risks related to requirements (SP 1.3) Record of analysis methods and results (SP 1.3)

SG 2 – Develop Service System

SP 2.1 – Select Service System Solutions

2.1.1- Establish defined criteria for selection. 2.2.2- Develop alternative solutions. 2.2.3- Select the service system solutions that best satisfy the criteria established

SP 2.2 – Develop the Design

2.2.1- Develop a design for the service system 2.2.2- Ensure that the design adheres to allocated requirements 2.2.3- Document the design 2.2.4- Design interfaces for the service system components using established criteria 2.2.5- Evaluate whether the components of the service system should be developed, purchased, or reused based on established criteria

SP 2.3 – Ensure Interface Compatibility

2.3.1- Review interface descriptions for coverage and completeness. 2.3.2- Manage internal and external interface definitions, designs, and changes for service system components.

SP 2.4 – Implement the Service System Design

2.4.1- Use effective methods to implement the service system design. 2.4.2- Adhere to applicable standards and criteria. 2.4.3- Conduct peer reviews of selected service system components. 2.4.4- Perform standalone testing of service system components as appropriate. 2.4.5- Revise the service system as necessary

SP 2.5 – Integrate Service System Components

2.5.1- Ensure the readiness of the integration environment. 2.5.2- Confirm that each service system component required for integration has been properly identified, functions according to its description, and that all interfaces comply with their interface descriptions. 2.5.3- Evaluate the assembled service system for interface compatibility, functionality, and performance.

Productos de trabajo típicos

Alternative solution screening criteria (SP 2.1) Selection criteria (SP 2.1) Service system component selection decisions and rationale (SP 2.1) Documented relationships between requirements and service system components (SP 2.1) Documented solutions, evaluations, and rationale (SP 2.1)

Service system architecture (SP 2.2) Service system component and consumable designs (SP 2.2) Skill descriptions and details of the staffing solution (e.g., allocated from available staff, hired as permanent or temporary staff) (SP 2.2) Interface design specifications and control documents (SP 2.2) Criteria for design and service system component reuse (SP 2.2) Results of make-or-buy analyses (SP 2.2)

Categories of interfaces with lists of interfaces per category (SP 2.3) Table or mapping of interface relationships among service system components and the external environment (SP 2.3) List of agreed interfaces defined for each pair of service system components when applicable (SP 2.3) Reports from meetings of the interface control working group (SP 2.3) Action items for updating interfaces (SP 2.3) Updated interface description or agreement (SP 2.3)

Implemented service system components (SP 2.4) Training materials (SP 2.4) User, operator, and maintenance manuals (SP 2.4) Procedure descriptions (SP 2.4) Records of new hires and staff transfers (SP 2.4) Records of communications about organizational changes (SP 2.4)

Service system integration sequence with rationale (SP 2.5) Documented and verified environment for service system integration (SP 2.5) Service system integration procedures and criteria (SP 2.5) Exception reports (SP 2.5) Assembled service system components (SP 2.5) Interface evaluation reports (SP 2.5) Service system integration summary reports (SP 2.5) Staffing plans that show the sequence of where and when staff members are provided (SP 2.5)

SG 3 – Verify and Validate Service Systems

SP 3.1 – Prepare for Verification and Validation

3.1.1- Select the components to be verified and validated and the verification and validation methods that will be used for each. 3.1.2- Establish and maintain the environments needed to support verification and validation. 3.1.3- Establish and maintain verification and validation procedures and criteria for selected service system components.

SP 3.2 – Perform Peer Review

3.2.1- Determine what type of peer review will be conducted 3.2.2- Establish and maintain peer review procedures and criteria for the selected service system components and work products. 3.2.3- Define requirements for the peer review 3.2.4- Establish and maintain checklists to ensure that service system components and work products are reviewed consistently 3.2.5- Develop a detailed peer review schedule, including dates for peer review training and for when materials for peer reviews will be available. 3.2.6- Prepare for the peer review 3.2.7- Ensure that the service system component or work product satisfies the peer review entry criteria and make the component or work product available for review to participants early enough to enable them to adequately prepare for the peer review. 3.2.8- Assign roles for the peer review as appropriate 3.2.9- Conduct peer reviews on selected service system components and work products, and identify issues resulting from the peer review 3.2.10- Conduct an additional peer review if the defined criteria indicate the need. 3.2.11- Ensure that exit criteria for the peer review are satisfied. 3.2.12- Record and store data related to the preparation, conduct, and results of peer reviews. 3.2.13- Analyze peer review data

SP 3.3 – Verify Selected Service System Components

3.3.1- Perform verification of selected service system components and work products against their requirements. 3.3.2- Record the results of verification activities. 3.3.3- Identify action items resulting from the verification of service system components and work products. 3.3.4- Document the “as-run” verification method and deviations from the available methods and procedures discovered during its performance. 3.3.5- Analyze and record the results of all verification activities

SP 3.4 – Validate the Service System

3.4.1- Perform functional and nonfunctional validation on selected service system components to ensure that they are suitable for use in their intended delivery environment 3.4.2- Analyze the results of validation activities

Productos de trabajo típicos

Lists of the service system components selected for verification and validation (SP 3.1) Verification and validation methods for each selected component (SP 3.1) Verification and validation environment (SP 3.1) Verification and validation procedures (SP 3.1) Verification and validation criteria (SP 3.1)

Peer review schedule (SP 3.2) Peer review checklist (SP 3.2) Entry and exit criteria for service system components and work products (SP 3.2) Criteria for requiring another peer review (SP 3.2) Peer review training material (SP 3.2) Service system components selected for peer review (SP 3.2) Peer review results, including issues and action items (SP 3.2) Peer review data (SP 3.2)

Verification results and logs (SP 3.3) Verification reports (SP 3.3) Analysis report (e.g., statistics on performance, causal analysis of nonconformance, comparison of the behavior between the real service system and models, trends) (SP 3.3) Trouble reports (SP 3.3) Change requests for verification methods, criteria, and the environment (SP 3.3)

Validation reports and results (SP 3.4) Validation cross-reference matrix (SP 3.4) Validation deficiency reports and other issues (SP 3.4) Change requests for validation methods, criteria, and the environment (SP 3.4) User acceptance (i.e., sign off) for service delivery validation (SP 3.4) Focus group reports (SP 3.4)

Stock especiales propios - mySAP SCM

2010-09-02T10:12:00.000-07:00

Stocks pertenecientes a la empresa que se guardan con el proveedor o el cliente. En el Sistema están disponibles los siguientes tipos de stocks especiales propios: (1) Stock de material facilitado al proveedor, (2) Stock en consignación en el cliente y (3) Stock de embalajes en el cliente. Puesto que estos stocks especiales no están ubicados en su propia empresa, se gestionan a nivel de centro y no a nivel de almacén.

Son posibles dos tipos de stocks: (1) Stock de libre utilización y (2) Stock en control de calidad. Todos los tipos de stocks pueden inventariarse.

Stock de material facilitado al proveedor

Stocks propios que se facilitan al proveedor (subcontratista) para fabricar un producto para el que se ha realizado un pedido. Sin embargo, este stock todavía es propiedad de su empresa. Este stock está disponible para la Planificación de necesidades.

Stock en consignación en el cliente

Se trata del material en consignación que pertenece a la empresa y que está almacenado en las dependencias del cliente. Este stock no está disponible para la Planificación de necesidades.

En la Gestión de stocks, se pueden contabilizar los siguientes movimientos de mercancías (con anulación): Entrada inicial de stocks (clases de movimiento 561, 563), Traspaso de centro a centro en una etapa (301), Traspaso de material a material (309). El resto de movimientos de mercancías se procesa mediante el componente Ventas (SD-SLS).

Stock de embalajes en el cliente

Se trata de materiales de embalaje o medios de transporte (por ejemplo, palets o cajones de embalaje) que su empresa suministra a un cliente y que deben ser devueltos. El stock de embalajes en el cliente no está disponible para la planificación de necesidades.

El resto de movimientos de mercancías se procesa mediante el componente Ventas (SD-SLS). Para estos tipos de stocks se deberá considerar la planificación respecto de la disponibilidad de materiales y el control de los mismos.

Generación de lotes - mySAP SCM

2010-08-03T06:29:00.000-07:00

La estructura del registro maestro de materiales le permite gestionar stocks de un material por valor a nivel de centro o a nivel de empresa y por cantidad hasta nivel de almacén. En determinadas condiciones, puede ser necesario realizar más subdivisiones en un material y gestionar lotes. No puede garantizarse siempre que algunas características de materiales sean exactamente iguales en la fabricación. Por ejemplo, no se puede garantizar que un color determinado tenga siempre la misma degradación. No se pueden evitar unas diferencias mínimas entre lotes de fabricación. Se debe ser capaz de identificar de manera única cada uno de los lotes de fabricación del mismo material y gestionarlos por separado en el inventario.

Los materiales que requieren una identificación muy precisa, por ejemplo, los productos farmacéuticos, se identifican y gestionan en stock no sólo en función del número de material, sino también en función del número de lote. Mediante la gestión de lotes, se pueden gestionar no sólo lotes de fabricación propia sino también lotes de fabricación de proveedores como entidades independientes. Se puede complementar la gestión de lotes estándar con la gestión de estados de lotes.

Para poder gestionar lotes de un material en stock, antes es preciso indicar en el registro maestro de materiales que el material se gestionará en lotes en el centro especificado. Para ello, se debe fijar el indicador de sujeción a lotes en el registro maestro de materiales (por ejemplo, en la vista Compras o Almacén).

Si un material está sujeto a la gestión en lotes, todas las cantidades de dicho material deben asignarse a un lote. Cada lote de material se identifica con un número de lote único, con el cual se gestiona. Este número lo ingresa el usuario (asignación de números externa) o bien lo asigna el sistema de manera automática.

Se puede definir la asignación de números para lotes a varios niveles: (1) De manera única a nivel de cliente para un material, (2) De manera única a nivel de material y (3) De manera única a nivel de centro. En el Sistema R/3 estándar, los números se asignan a los materiales individuales a nivel de centro.

Para cada lote, existen dos tipos de datos:

• Datos generales del lote (por ejemplo, fecha de caducidad, fecha de la última entrada de mercancías), que se definen en el registro maestro de lote. El registro maestro de lote se aplica a todos los almacenes en los que se encuentra el lote. A este nivel no se gestionan stocks.

• Datos de stock, gestionados por separado para cada almacén en los que se emplaza el lote. Por ejemplo, si el lote C1 de un material se distribuye entre dos almacenes, se hace un seguimiento de la cantidad de stocks en cada almacén.

Tanto el registro maestro de lote como los datos de stock del lote se crean automáticamente durante la primera entrada de mercancías. Por este motivo, no es necesario crear estos datos manualmente. Sin embargo, si desea definir datos específicos para un lote, como la fecha de caducidad, debe actualizar manualmente los datos del lote.

Los siguientes stocks se gestionan por separado a nivel de lote: (1) Stock de libre utilización, (2) Stock no libre, (3) Stock en control de calidad, (4) Stock bloqueado, (5) Stock en traslado y (6) Stock bloqueado de devoluciones

Cuando se ingresan movimientos de mercancías para materiales sujetos a lote, se debe ingresar el número de lote además del número de material. Si se desconoce el número de lote, se puede buscar el lote utilizando las características necesarias.

La Gestión de Lotes conlleva la realización de controles periódicos respecto de los materiales existentes y de los posibles pedidos. De esta forma, se podrá predecir las entregas a tiempo respecto de los pedidos establecidos y evitar las entregas atrasadas.

OT y RSKM en CMMi SVC V1.2 (8)

2010-08-03T06:28:00.000-07:00

ORGANIZATIONAL TRAINING

El propósito de ‘Organizational Training’ (OT), perteneciente al Nivel de Madurez 3, es desarrollar las técnicas y conocimiento de la gente que cumple roles de manera eficiente y efectiva. OT incluye entrenamiento relacionado a los objetivos de negocio estratégicos y para cumplir con las necesidades de entrenamiento táctico necesarias para el proyecto y para el grupo de soporte. Los grupos del proyecto y de soporte son responsables de identificar y tratar las necesidades de entrenamiento específico.

Un programa de entrenamiento organizacional involucra lo siguiente: (1) Identificar el entrenamiento necesario, (2) Obtener y suministrar el entrenamiento que tratan las necesidades del proyecto, (3) Establecer y mantener la capacidad de entrenamiento, (4) Establecer y mantener los registros de entrenamiento y (5) Evaluar la eficacia del entrenamiento.

Un entrenamiento efectivo requiere de la evolución de las necesidades, planificación, diseño instructivo y medios de entrenamiento. Los principales componentes del entrenamiento incluyen: (1) programa de desarrollo de entrenamiento administrado, (2) planes documentados, (3) personal con conocimiento apropiado y (4) mecanismos para medir la efectividad del programa de entrenamiento.

La identificación de las necesidades de entrenamiento del proceso está basada en las técnicas que son necesarias para efectuar el conjunto de procesos estándares de la organización.

OT se relaciona con las siguientes áreas de proceso: OPD, PP y DAR.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Establish an OT Capability

SP 1.1 - Establish Strategic Training Needs

1.1.1- Analyze the organization’s strategic business objectives and process improvement plan to identify potential future training needs. 1.1.2- Document the strategic training needs of the organization. 1.1.3- Determine the roles and skills needed to perform the organization’s set of standard processes. 1.1.4- Document the training needed to perform the roles in the organization’s set of standard processes. 1.1.5- Document the training needed to maintain the safe, secure and continued operation of the business. 1.1.6- Revise the organization’s strategic needs and required training as necessary.

SP 1.2 - Determine Which Training Needs Are the Responsibility of the Organization

1.2.1- Analyze the training needs identified by projects and support groups. 1.2.2- Negotiate with projects and support groups on how their training needs will be satisfied. 1.2.3- Document the commitments for providing training support to projects and support groups.

SP 1.3 - Establish an OT Tactical Plan

1.3.1- Establish the content of the plan. 1.3.2- Establish commitments to the plan. 1.3.3- Revise the plan and commitments as necessary.

SP 1.4 - Establish a Training Capability

1.4.1- Select appropriate approaches to satisfy organizational training needs. 1.4.2- Determine whether to develop training materials internally or to acquire them externally. 1.4.3- Develop or obtain training materials. 1.4.4- Develop or obtain qualified instructors. 1.4.5- Describe the training in the organization's training curriculum. 1.4.6- Revise training materials and supporting artifacts as necessary.

Productos de trabajo típicos

Training needs (SP 1.1) Assessment analysis (SP 1.1) Common project and support group training needs (SP 1.2) Training commitments (SP 1.2) Organizational training tactical plan (SP 1.3) Training materials and supporting artifacts (SP 1.4)

SG 2 - Provide Necessary Training

SP 2.1 - Deliver Training

2.1.1- Select those will receive the training necessary to perform their roles effectively. 2.1.2- Schedule the training, including any resources, as necessary 2.1.3- Conduct the training. 2.1.4- Track the delivery of training against the plan.

SP 2.2 - Establish Training Records

2.2.1- Keep records of all students who successfully complete each training course or other approved training activity as well as those who are unsuccessful 2.2.2- Keep records of all staff who are waived from training. 2.2.3- Keep records of all students who successfully complete their required training. 2.2.4- Make training records available to the appropriate people for consideration in assignments.

SP 2.3 - Assess Training Effectiveness

2.3.1- Assess in-progress or completed projects to determine whether staff knowledge is adequate for performing project tasks. 2.3.2- Provide a mechanism for assessing the effectiveness of each training course with respect to established organizational, project, or individual learning (or performance) objectives. 2.3.3- Obtain student evaluations of how well training activities met their needs.

Productos de trabajo típicos

Delivered training course (SP 2.1) Training records (SP 2.2) Training updates to the organizational repository (SP 2.2) Training-effectiveness surveys (SP 2.3) Training program performance assessments (SP 2.3) Instructor evaluation forms (SP 2.3) Training examinations (SP 2.3)

RISK MANAGEMENT

El propósito de ‘Risk Management’ (RSKM), perteneciente al Nivel de Madurez 3, es identificar problemas potenciales antes que ocurran, identificar las actividades de manejo del riesgo que pueden ser planeadas e invocadas para mitigar los impactos de los objetivos logrados.

El manejo de riesgos es un proceso continuo importante para la administración y trata los problemas que pueden impedir el logro de los objetivos. Una propuesta continua de manejo de riesgo anticipa y mitiga riesgos que tienen un impacto crítico en el proyecto.

El manejo de riesgo puede ser dividido en 3 partes: (1) Definición de una estrategia de manejo del riesgo, (2) Identificación y análisis del riesgo; y (3) Manejo de los riesgos identificados.

RSKM se relaciona con las siguientes áreas de proceso: SC, DAR, PMC y PP.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Prepare for RSKM

SP 1.1 - Determine Risk Sources and Categories

1.1.1- Determine risk sources 1.1.2- Determine risk categories

SP 1.2 - Define Risk Parameters

1.2.1- Define consistent criteria for evaluating and quantifying risk likelihood and severity levels. 1.2.2- Define thresholds for each risk category. 1.2.3- Define bounds on the extent to which thresholds are applied against or within a category

SP 1.3 - Establish a RSKM Strategy

Productos de trabajo típicos

Risk source lists (external and internal) (SP 1.1) Risk categories list (SP 1.1) Risk evaluation, categorization, and prioritization criteria (SP 1.2) Risk management requirements (e.g., control and approval levels, and reassessment intervals) (SP 1.2) Project risk management strategy (SP 1.3)

SG 2 - Identify and Analyze Risks

SP 2.1 - Identify Risks

2.1.1- Identify the risks associated with cost, schedule, and performance 2.1.2- Review environmental elements that may impact the project 2.1.3- Review all elements of the work breakdown structure as part of identifying risks to help ensure that all aspects of the work effort have been considered 2.1.4- Review all elements of the project plan as part of identifying risks to help ensure that all aspects of the project have been considered 2.1.5- Document the context, conditions, and potential consequences of each risk 2.1.6- Identify the relevant stakeholders associated with each risk

SP 2.2 - Evaluate, Categorize, and Prioritize Risks

2.2.1- Evaluate identified risks using defined risk parameters 2.2.2- Categorize and group risks according to defined risk categories 2.2.3- Prioritize risks for mitigation

Productos de trabajo típicos

List of identified risks, including the context, conditions, and consequences of risk occurrence (SP 2.1) List of risks and their assigned priority (SP 2.2)

SG 3 - Mitigate Risks

SP 3.1 - Develop Risk Mitigation Plans

3.1.1- Determine the levels and thresholds that define when a risk becomes unacceptable and triggers the execution of a risk mitigation plan or a contingency plan 3.1.2- Identify the person or group responsible for addressing each risk 3.1.3- Determine the cost and benefits of implementing the risk mitigation plan for each risk 3.1.4- Develop an overall risk mitigation plan for the project to orchestrate the implementation of individual risk mitigation and contingency plans. 3.1.5- Develop contingency plans for selected critical risks in the event their impacts are realized.

SP 3.2 - Implement Risk Mitigation Plans

3.2.1- Monitor risk status 3.2.2- Provide a method for tracking open risk-handling action items to closure 3.2.3- Invoke selected risk-handling options when monitored risks exceed defined thresholds 3.2.4- Establish a schedule or period of performance for each risk-handling activity that includes a start date and anticipated completion date. 3.2.5- Provide a continued commitment of resources for each to allow the successful execution of risk-handling activities 3.2.6- Collect performance measures on risk-handling activities

Productos de trabajo típicos

Documented handling options for each identified risk (SP 3.1) Risk mitigation plans (SP 3.1) Contingency plans (SP 3.1) List of those responsible for tracking and addressing each risk (SP 3.1) Updated list of risk status (SP 3.2) Updated assessments of risk likelihood, consequence, and thresholds (SP 3.2) Updated list of risk-handling options (SP 3.2) Updated list of actions taken to handle risks (SP 3.2) Risk mitigation plans of risk handling options (SP 3.2) Updated list of action taken to handle risks (SP 3.2) Risk mitigation plans (SP 3.2)

OPD y OPF en CMMi SVC V1.2 (7)

2010-07-02T10:58:00.001-07:00

ORGANIZATIONAL PROCESS DEFINITION

El propósito de ‘Organizacional Process Definition’ (OPD), perteneciente al Nivel de Madurez 3, es establecer y mantener un conjunto de ventajas del proceso organizacional y estándares de ambiente de trabajo. Una librería de ventajas del proceso de la organización es una colección de ítems utilizada por la gente y en los proyectos de la organización. Esta colección de ítems incluye descripciones de proceso y elementos de proceso, descripciones de los modelos del ciclo de vida, guía para realizar un proceso, documentación relacionada al proceso y datos.

Las ventajas del proceso organizacional son utilizadas para realizar la implementación del proceso definido. Los estándares del ambiente de trabajo son utilizados para crear el ambiente de trabajo del proyecto. Un proceso estándar está compuesto de otros procesos o elementos de proceso. Un elemento de proceso es la principal unidad de definición del proceso y describe las actividades y tareas necesarias para realizar el trabajo. La arquitectura del proceso suministra reglas para conectar los elementos del proceso pertenecientes a un proceso estándar. El conjunto de procesos estándares de la organización puede incluir varias arquitecturas de proceso.

OPD se relaciona con las siguientes áreas de proceso: SSM y OPF.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Establish Organizational Process Assets

SP 1.1 - Establish Standard Processes

1.1.1- Decompose each standard process into constituent process elements to the detail needed to understand and describe the process. 1.1.2- Specify the critical attributes of each process element. 1.1.3- Specify the relationships among process elements. 1.1.4- Ensure that the organization's set of standard processes adheres to applicable policies, standards, and models. 1.1.5- Ensure that the organization’s set of standard processes satisfies process needs and objectives of the organization. 1.1.6- Ensure that there is appropriate integration among processes that are included in the organization’s set of standard processes. 1.1.7- Document the organization's set of standard processes. 1.1.8- Conduct peer reviews on the organization's set of standard processes. 1.1.9- Revise the organization's set of standard processes as necessary.

SP 1.2 - Establish Lifecycle Model Descriptions

1.2.1- Select lifecycle models based on the needs of projects and the organization. 1.2.2- Document descriptions of lifecycle models. 1.2.3- Conduct peer reviews on lifecycle models. 1.2.4- Revise the descriptions of lifecycle models as necessary.

SP 1.3 - Establish Tailoring Criteria and Guidelines

1.3.1- Specify selection criteria and procedures for tailoring the organization's set of standard processes 1.3.2- Specify the standards for documenting the defined processes. 1.3.3- Specify the procedures used for submitting and obtaining approval of waivers from the organization’s set of standard processes. 1.3.4- Document tailoring guidelines for the organization's set of standard processes. 1.3.5- Conduct peer reviews on the tailoring guidelines. 1.3.6- Revise tailoring guidelines as necessary.

SP 1.4 - Establish the Organization’s Measurement Repository

1.4.1- Determine the organization's needs for storing, retrieving, and analyzing measurements. 1.4.2- Define a common set of process and product measures for the organization's set of standard processes. 1.4.3- Design and implement the measurement repository. 1.4.4- Specify the procedures for storing, updating, and retrieving measures. 1.4.5- Conduct peer reviews on the definitions of the common set of measures and procedures for storing, updating and retrieving measures. 1.4.6- Enter the specified measures into the repository. 1.4.7- Make the contents of the measurement repository available for use by the organization and projects as appropriate. 1.4.8- Revise the measurement repository, the common set of measures, and procedures as the organization’s needs change.

SP 1.5 - Establish the Organization’s Process Asset Library

1.5.1- Design and implement the organization’s process asset library, including the library structure and support environment. 1.5.2- Specify criteria for including items in the library. 1.5.3- Specify procedures for storing, updating and retrieving items. 1.5.4- Enter selected items into the library and catalog them for easy reference and retrieval. 1.5.5- Make the items available for use by the projects. 1.5.6- Periodically review the use of each item 1.5.7- Revise the organization’s process asset library as necessary.

SP 1.6 - Establish Work Environment Standards

1.6.1- Evaluate commercially-available work environment standards appropriate for the organization. 1.6.2- Adopt existing work environment standards and develop new ones to fill gaps based on the organization’s process needs and objectives.

SP 1.7 - Establish Rules and Guidelines for Integrated Teams

1.7.1- Establish and maintain empowerment mechanisms to enable timely decision making. 1.7.2- Establish rules and guidelines for structuring and forming integrated teams 1.7.3- Define the expectations, rules, and guidelines that guide how integrated teams work collectively. 1.7.4- Maintain the rules and guidelines for structuring and forming integrate teams 1.7.5- Establish and maintain organizational guidelines to help team members balance their team and home organization responsibilities

Productos de trabajo típicos

Organization's set of standard processes (SP 1.1) Descriptions of lifecycle models (SP 1.2) Tailoring guidelines for the organization's set of standard processes (SP 1.3) Definition of the common set of product and process measures for the organization’s set of standard processes (SP 1.4) Design of the organization’s measurement repository (SP 1.4) Organization's measurement repository (SP 1.4) Organization’s measurement data (SP 1.4) Design of the organization’s process asset library (SP 1.5) The organization's process asset library (SP 1.5) Selected items to be included in the organization’s process asset library (SP 1.5) The catalog of items in the organization’s process asset library (SP 1.5) Work environment standards (SP 1.6) Rules and guidelines for structuring and forming integrated teams (SP 1.7)

ORGANIZATIONAL PROCESS FOCUS

El propósito de ‘Organizacional Process Focus’ (OPF), perteneciente al Nivel de Madurez 3, es planear e implementar el mejoramiento del proceso organizacional basado en el entendimiento de las fortalezas y debilidades de los procesos de la organización y de las ventajas del proceso. Los procesos de la organización incluyen todos los procesos utilizados en la organización y en sus proyectos.

El mejoramiento del proceso ocurre dentro del contexto de las necesidades de la organización y es utilizado para tratar los objetivos de la organización. Algunas de las posibles mejoras son: (1) propuestas de mejoramiento del proceso, (2) medición de los procesos, (3) lecciones aprendidas de la implementación de los procesos y (4) resultados de la evaluación de los procesos y de las actividades de evaluación del producto.

Las ventajas del proceso organizacional son usadas para describir, implementar y mejorar los procesos de la organización. OPF se relaciona con OPD.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Determine Process Improvement Opportunities

SP 1.1 - Establish Organizational Process Needs

1.1.1- Identify policies, standards, and business objectives that are applicable to the organization's processes. 1.1.2- Examine relevant process standards and models for best practices. 1.1.3- Determine the organization’s process-performance objectives. 1.1.4- Define the essential characteristics of the organization’s processes. 1.1.5- Document the organization’s process needs and objectives. 1.1.6- Revise the organization’s process needs and objectives as needed.

SP 1.2 - Appraise the Organization’s Processes

1.2.1- Obtain sponsorship of the process appraisal from senior management. 1.2.2- Define the scope of the process appraisal. 1.2.3- Determine the method and criteria to be used for the process appraisal. 1.2.4- Plan, schedule, and prepare for the process appraisal.. 1.2.5- Conduct the process appraisal. 1.2.6- Document and deliver the appraisal’s activities and findings

SP 1.3 - Identify the Organization's Process Improvements

1.3.1- Determine candidate process improvements. 1.3.2- Prioritize candidate process improvements. 1.3.3- Identify and document the process improvements to be implemented. 1.3.4- Revise the list of planned process improvements to keep it current.

Productos de trabajo típicos

Organization’s process needs and objectives (SP 1.1) Plans for the organization's process appraisals (SP 1.2) Appraisal findings that address strengths and weaknesses of the organization's processes (SP 1.2) Improvement recommendations for the organization's processes (SP 1.2) Analysis of candidate process improvements (SP 1.3) Identification of improvements for the organization's processes (SP 1.3)

SG 2 - Plan and Implement Process Actions

SP 2.1 - Establish Process Action Plans

2.1.1- Identify strategies, approaches, and actions to address the identified process improvements. 2.1.2- Establish process action teams to implement the actions. 2.1.3- Document process action plans. 2.1.4- Review and negotiate process action plans with relevant stakeholders. 2.1.5- Review process action plans as necessary.

SP 2.2 - Implement Process Action Plans

2.2.1- Make process action plans readily available to relevant stakeholders. 2.2.2- Negotiate and document commitments among process action teams and revise their process action plans as necessary. 2.2.3- Track progress and commitments against process action plans. 2.2.4- Conduct joint reviews with process action teams and relevant stakeholders to monitor the progress and results of process actions. 2.2.5- Plan pilots needed to test selected process improvements. 2.2.6- Review the activities and work products of process action teams. 2.2.7- Identify, document, and track to closure issues when implementing process action plans. 2.2.8- Ensure that results of implementing process action plans satisfy the organization’s process improvement objectives.

Productos de trabajo típicos

The organization's approved process action plans (SP 2.1) Commitments among process action teams (SP 2.2) Status and results of implementing process action plans (SP 2.2) Plans for pilots (SP 2.2)

SG 3 - Deploy Organizational Process Assets and Incorporate Experiences

SP 3.1 - Deploy Organizational Process Assets

3.1.1- Deploy organizational process assets across the organization 3.1.2- Document changes to organizational process assets. 3.1.3- Deploy changes that were made to organization process assets across the organization 3.1.4- Provide guidance and consultation on the use of the organizational process assets.

SP 3.2 – Deploy Standard Processes

3.2.1- Identify projects in the organization that are starting up. 3.2.2- Identify active projects that would benefit from implementing the organization’s current set of standard processes. 3.2.3- Establish plans to implement the organization’s current set of standard processes on the identified projects. 3.2.4- Assist projects in tailoring the organization’s set of standard processes to meet their needs. 3.2.5- Maintain records of tailoring and implementing processes on the identified projects. 3.2.6- Ensure that the defined processes resulting from process tailoring are incorporated into plans for process-compliance audits. 3.2.7- As the organization’s set of standard processes are updated, identify which projects should implement the changes. SP 3.3 – Monitor the Implementation 3.3.1- Monitor projects ‘use of the organization’s process assets and changes to them. 3.3.2- Review selected process artifacts created during the life of each project. 3.3.3- Review results of process-compliance audits to determine how well the organization’s set of standard processes has been deployed 3.3.4- Identify, document, and track to closure issues related to implementing the organization’s set of standard processes.

SP 3.4 - Incorporate Experiences into Organizational Process Assets

3.4.1- Conduct periodic reviews of the effectiveness and suitability of the organization’s set of standard processes and related organizational process assets relative to the organization’s business objectives. 3.4.2- Obtain feedback about the use of the organizational process assets. 3.4.3- Derive lessons learned from defining, piloting, implementing, and deploying the organizational process assets. 3.4.4- Make lessons learned available to people in the organization as appropriate. 3.4.5- Analyze measurement data obtained from the use of the organization's common set of measures. 3.4.6- Appraise the processes, methods, and tools in use in the organization and develop recommendations for improving the organizational process assets. 3.4.7- Make the best use of the organization's processes, methods, and tools available to people in the organization as appropriate. 3.4.8- Manage process improvement proposals. 3.4.9- Establish and maintain records of the organization's process improvement activities.

Productos de trabajo típicos

Plans for deploying organizational process assets and changes to them across the organization (SP 3.1) Training materials for deploying organizational process assets and changes to them (SP 3.1) Documentation of changes to organizational process assets (SP 3.1) Support materials for deploying organizational process assets and changes to them (SP 3.1) The organization’s list of projects and the status of process deployment on each (SP 3.2) Guidelines for deploying the organization’s set of standard processes on new projects (SP 3.2) Records of tailoring and implementing the organization’s set of standard processes (SP 3.2) Results of monitoring process implementation on projects (SP 3.3) Status and results of process-compliance audits (SP 3.3) Results of reviewing selected process artifacts created as part of process tailoring and implementation (SP 3.3) Process improvement proposals (SP 3.4) Process lessons learned (SP 3.4) Measurements of organizational process assets (SP 3.4) Improvement recommendations for organizational process assets (SP 3.4) Records of the organization's process improvement activities (SP 3.4) Information on organizational process assets and improvements to them (SP 3.4)

Inventario - mySAP SCM

2010-07-02T10:57:00.003-07:00

Este componente permite elaborar un inventario de los stocks en almacén de su empresa para el balance. Para tal fin, pueden aplicarse varios procesos.

En este Sistema, el inventario puede realizarse tanto para el stock propio como para un stock especial. Sin embargo, el inventario del stock propio y el del stock especial (p. ej, stock en consignación en el cliente, stock externo de artículos en consignación del proveedor o embalaje en préstamo) deben considerarse por separado (en distintos documentos para inventario).

Además, el stock puede dividirse en tipos de stocks. En el sistema estándar, se puede realizar un inventario de los siguientes tipos de stocks: (1) Stock de libre utilización en el almacén, (2) Stock en control de calidad y (3) Stock bloqueado.

Si la gestión de estados de lotes se encuentra activada, el primer tipo de stocks abarca tanto el stock de libre utilización como el stock no libre. El inventario de los dos tipos de stocks mencionados puede realizarse en una única operación. Para aquellos materiales que han de ser objeto de inventario, se crea una posición por cada tipo de stocks en el documento para inventario.

El inventario se realiza a nivel de almacén. En cada almacén, se crea un documento para inventario independiente. Si un material no existe en un almacén, esto significa que nunca ha tenido lugar ningún movimiento de mercancías para el material en el almacén. El material, por lo tanto, no ha tenido nunca ningún stock en este almacén. El material no existe a nivel de stock en el almacén. En consecuencia, no es posible hacer inventario del material en dicho almacén. Lo anterior no debe confundirse con un material que haya sufrido un movimiento de mercancías y cuya cantidad de stock en el almacén sea en la actualidad cero. En este caso se debe llevar a cabo un inventario, ya que los datos de almacén no se borran cuando la cantidad de stock en almacén es cero.

El Sistema R/3 soporta los siguientes procesos de inventario: (1) Inventario en día fijado, (2) Inventario permanente, (3) Inventario cíclico y (4) Inventario por muestreo.

Inventario en día fijado (1): En un inventario en día fijado, todos los stocks de la empresa se cuentan físicamente en la fecha clave de balance. En tal caso, debe contarse todo el material. Durante el recuento, debe bloquearse todo el almacén para los movimientos de material.

Inventario permanente (2): En el proceso de inventario permanente, los stocks se cuentan permanentemente a lo largo del ejercicio. En tal caso, es importante asegurarse de que todo el material se cuenta físicamente al menos una vez durante el ejercicio.

Inventario cíclico (3): El inventario cíclico es un método de inventario en el que el inventario se cuenta a intervalos regulares durante el ejercicio. Dichos intervalos (o ciclos) dependen del indicador de inventario cíclico establecido en los materiales. El Método de inventario cíclico permite contar más a menudo las posiciones de alta rotación que las posiciones de baja rotación.

Inventario por muestreo (4): En el Inventario por muestreo, los stocks de la empresa seleccionados aleatoriamente se cuentan físicamente en la fecha clave de balance. Si las desviaciones entre el resultado del recuento y el stock teórico son suficientemente pequeñas, se supone que los stocks teóricos para el resto de stocks son correctos.

Actualización del Sistema de información para logística (SIL)

El inventario está conectado al Sistema de información para logística (SIL). Cuando se actualizan diferencias de inventario en SIL, se visualizan según una cantidad y un valor. Las posiciones de inventario se agregan a nivel de número de inventario, de centro, de almacén y de material. Si precisa información más detallada sobre las diferencias de inventario en el SIL, puede acceder directamente a la lista de diferencias de inventario desde el SIL y continuar el análisis a nivel de posición.

Restricciones

La compensación de diferencias de inventario está sujeta a ciertas restricciones temporales:

1.El período contable se fija de modo automático durante el recuento. Por lo tanto, las diferencias de inventario deben compensarse en el mismo período o, si se permiten compensaciones en el período anterior, en el período siguiente.

2.El ejercicio se fija especificando una fecha planificada de recuento de inventario al crear un documento para inventario. Todas las contabilizaciones posteriores en dicho documento deben realizarse en este ejercicio y/o en el primer período del siguiente ejercicio, si se permiten contabilizaciones en el período anterior.

El manejo de inventario implica efectuar un control de los materiales y actualización de los sistemas que manejan dicha información, ya que esto contribuye a la evaluación de la situación y a la toma de decisiones.

DAR e IMP en CMMi SVC V1.2 (6)

2010-06-02T09:44:00.000-07:00

DECISION ANALYSIS AND RESOLUTION

El propósito de ‘Decisión Analysis and Resolution’ (DAR), perteneciente al Nivel de Madurez 3, es analizar las posibles decisiones usando un proceso de evaluación formal que evalúa las alternativas identificadas y el criterio establecido.

Esta área de proceso involucra establecer pautas para determinar qué resultados estarán sujetos a un proceso de evaluación formal. Este proceso de evaluación formal es una propuesta estructurada que permite evaluar las soluciones alternativas y un criterio establecido para determinar una solución al problema planteado.

Un proceso de evaluación formal implica las siguientes acciones: (1) Establecer un criterio para evaluar las alternativas, (2) Identificar las soluciones alternativas, (3) Seleccionar métodos para evaluar las alternativas, (4) Evaluar las soluciones alternativas usando el criterio establecido y los métodos; y (5) Seleccionar las soluciones recomendadas.

DAR se relaciona con las siguientes áreas de proceso: IPM y RSKM. Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Evaluate Alternatives

SP 1.1 - Establish Guidelines for Decision Analysis

1.1.1- Establish guidelines for when to use a formal evaluation process 1.1.2- Incorporate the use of the guidelines into the defined process as appropriate.

SP 1.2 - Establish Evaluation Criteria

1.2.1- Define the criteria for evaluating alternative solutions. 1.2.2- Define the range and scale for ranking the evaluation criteria. 1.2.3- Rank the criteria. 1.2.4- Assess the criteria and their relative importance. 1.2.5- Evolve the evaluation criteria to improve their validity. 1.2.6- Document the rationale for the selection and rejection of evaluation criteria.

SP 1.3 - Identify Alternative Solutions

1.3.1- Perform a literature search. 1.3.2- Identify alternatives for consideration in addition to those that may be provided with the issue. 1.3.3- Document the proposed alternatives.

SP 1.4 - Select Evaluation Methods

1.4.1- Select the methods based on the purpose for analyzing a decision and on the availability of the information used to support the method. 1.4.2- Select evaluation methods based on their ability to focus on the issues at hand without being overly influenced by side issues. 1.4.3- Determine the measures needed to support the evaluation method.

SP 1.5 - Evaluate Alternatives

1.5.1- Evaluate the proposed alternative solutions using the established evaluation criteria and selected methods. 1.5.2- Evaluate assumptions related to the evaluation criteria and the evidence that supports the assumptions. 1.5.3- Evaluate whether uncertainty in the values for alternative solutions affects the evaluation and address these uncertainties, as appropriate. 1.5.4- Perform simulations, modeling, prototypes, and pilots as necessary to exercise the evaluation criteria, methods, and alternative solutions. 1.5.5- Consider new alternative solutions, criteria, or methods if the proposed alternatives do not test well; repeat the evaluations until alternatives do test well. 1.5.6- Document the results of the evaluation.

SP 1.6 - Select Solutions

1.6.1- Assess the risks associated with implementing the recommended solution. 1.6.2- Document the results and rationale for the recommended solution.

Productos de trabajo típicos

Guidelines for when to apply a formal evaluation process (SP 1.1) Documented evaluation criteria (SP 1.2) Rankings of criteria importance (SP 1.2) Identified alternatives (SP 1.3) Selected evaluation methods (SP 1.4) Evaluation results (SP 1.5) Recommended solutions to address significant issues (SP 1.6)

INTEGRATED PROJECT MANAGEMENT El propósito de ‘Integrated Project Management’ (IPM), perteneciente al Nivel de Madurez 3, es establecer y administrar el proyecto; y la participación de las partes interesadas de acuerdo al proceso definido e integrado que está basado en el conjunto de procesos estándares de la organización. El proceso definido e integrado es denominado proceso definido del proyecto.

La implementación y el manejo del proceso definido del proyecto son descriptos en el plan de proyecto. Ciertas actividades pueden ser efectuadas en otros planes. Esta área de proceso trata la coordinación de todas las actividades asociadas a los proyectos. Estas actividades son: (1) Actividades de Desarrollo, (2) Actividades de Servicio, (3) Actividades de adquisición y (4) Actividades de Soporte. IPM se relaciona con las siguientes áreas de proceso: PP, PMC, OPD y MA.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Use the Project’s Defined Process

SP 1.1 - Establish the Project’s Defined Process

1.1.1- Select a lifecycle model from those available in organizational process assets. 1.1.2- Select standard processes from the organization's set of standard processes that best fit the needs of the project. 1.1.3- Tailor the organization’s set of standard processes and other organizational process assets according to tailoring guidelines to produce the project’s defined process. 1.1.4- Use other artifacts from the organization's process asset library as appropriate. 1.1.5- Document the project's defined process. 1.1.6- Conduct peer reviews of the project's defined process. 1.1.7- Revise the project's defined process as necessary.

SP 1.2 - Use Organizational Process Assets for Planning Project Activities

1.2.1- Use the tasks and work products of the project's defined process as a basis for estimating and planning project activities 1.2.2- Use the organization’s measurement repository in estimating the project’s planning parameters.

SP 1.3 - Establish the Project’s Work Environment

1.3.1- Plan, design and install a work environment for the project. 1.3.2- Provide ongoing maintenance and operational support for the project’s work environment. 1.3.3- Maintain the qualification of components of the project’s work environment. 1.3.4- Periodically review how well the work environment is meeting project needs and supporting collaboration, and take action as appropriate.

SP 1.4 - Integrate Plans

1.4.1- Integrate other plans that affect the project with the project plan. 1.4.2- Incorporate into the project plan the definitions of measures and measurement activities for managing the project. 1.4.3- Identify and analyze product and project interface risks. 1.4.4- Schedule the tasks in a sequence that accounts for critical development factors and project risks. 1.4.5- Incorporate the plans for performing peer reviews on the work products of the project's defined process. 1.4.6- Incorporate the training needed to perform the project’s defined process in the project’s training plans. 1.4.7- Establish objective entry and exit criteria to authorize the initiation and completion of the tasks described in the work breakdown structure (WBS). 1.4.8- Ensure that the project plan is appropriately compatible with the plans of relevant stakeholders. 1.4.9- Identify how conflicts will be resolved that arise among relevant stakeholders.

SP 1.5 - Manage the Project using the Integrated Plans

1.5.1- Implement the project’s defined process using the organization's process asset library. 1.5.2- Monitor and control the project’s activities and work products using the project’s defined process, project plan, and other plans that affect the project. 1.5.3- Obtain and analyze the selected measures to manage the project and support the organization’s needs. 1.5.4- Periodically review and align the project’s performance with the current and anticipated needs, objectives, and requirements of the organization, customer, and end users, as appropriate.

SP 1.6- Establish Integrated Teams

1.6.1- Establish and maintain the project’s shared vision 1.6.2- Establish and maintain the integrated team structure 1.6.3- Establish and maintain each integrated team 1.6.4- Periodically evaluate the integrated team structure and composition.

SP 1.7 - Contribute to the Organizational Process Assets

1.7.1- Propose improvements to organizational process assets. 1.7.2- Store process and product measures in the organization’s measurement repository. 1.7.3- Submit documentation for possible inclusion in the organization’s process asset library 1.7.4- Document lessons learned from the project for inclusion in the organization’s process asset library. 1.7.5- Provide process artifacts associated with tailoring and implementing the organization’s set of standard processes in support of the organization’s process monitoring activities.

Productos de trabajo típicos

The project’s defined process (SP 1.1) Project estimates (SP 1.2) Project plans (SP 1.2) Equipment and tools for the project (SP 1.3) Installation, operation, and maintenance manuals for the project work environment (SP 1.3) User surveys and results (SP 1.3) Usage, performance, and maintenance records (SP 1.3) Support services for the project’s work environment (SP 1.3) Integrated plans (SP 1.4) Work products created by performing the project’s defined process (SP 1.5) Collected measures and status records or reports (SP 1.5) Revised requirements, plans, and commitments (SP 1.5) Integrated plans (SP 1.5) Documented shared vision (SP 1.6) List of team members assigned to each integrated team (SP 1.6) Integrated team charters (SP 1.6) Periodic integrated team status reports (SP 1.6) Proposed improvements to organizational process assets (SP 1.7) Actual process and product measures collected from the project (SP 1.7) Documentation (SP 1.7) Process artifacts associated with tailoring and implementing the organization’s set of standard processes on the project (SP 1.7)

SG 2 - Coordinate and Collaborate with Relevant Stakeholders

SP 2.1 - Manage Stakeholder Involvement

2.1.1- Coordinate with relevant stakeholders who should participate in project activities. 2.1.2- Ensure work products that are produced to satisfy commitments meet the requirements of the recipient. 2.1.3- Develop recommendations and coordinate actions to resolve misunderstandings and problems with requirements.

SP 2.2 - Manage Dependencies

2.2.1- Conduct reviews with relevant stakeholders. 2.2.2- Identify each critical dependency. 2.2.3- Establish need dates and plan dates for each critical dependency based on the project schedule. 2.2.4- Review and get agreement on commitments to address each critical dependency with those responsible for providing the work product and those receiving the work product or performing or receiving the service. 2.2.5- Document critical dependencies and commitments. 2.2.6- Track critical dependencies and commitments and take corrective action as appropriate.

SP 2.3 - Resolve Coordination Issues

2.3.1- Identify and document issues. 2.3.2- Communicate issues to relevant stakeholders. 2.3.3- Resolve issues with relevant stakeholders. 2.3.4- Escalate to appropriate managers those issues not resolvable with relevant stakeholders. 2.3.5- Track the issues to closure. 2.3.6- Communicate with relevant stakeholders on the status and resolution of the issues.

Productos de trabajo típicos

Agendas and schedules for collaborative activities (SP 2.1) Documented issues (SP 2.1) Recommendations for resolving relevant stakeholder issues (SP 2.1) Defects, issues, and action items resulting from reviews with relevant stakeholders (SP 2.2) Critical dependencies (SP 2.2) Commitments to address critical dependencies (SP 2.2) Status of critical dependencies (SP 2.2) Relevant stakeholder coordination issues (SP 2.3) Status of relevant stakeholder coordination issues (SP 2.3)

Reservas - mySAP SCM

2010-06-02T09:40:00.001-07:00

Este componente de Reservas permite efectuar una orden al almacén para disponer de materiales listos para la toma de material en una fecha posterior y con un propósito determinado. Esto simplifica y acelera el proceso de entrada de mercancías. Varios departamentos pueden solicitar una reserva de salida de mercancías para varios objetos de imputación (como centros de coste, órdenes, activos fijos, etc.).

El objetivo de una reserva es asegurar que el material esté disponible cuando se necesite. También sirve para simplificar y acelerar el proceso de salida de mercancías y para preparar las tareas en el momento de la salida de mercancías. También es importante que la Planificación de necesidades de material tenga en cuenta las reservas, es decir, que se consigan a tiempo los materiales necesarios si éstos no están en stock. Es posible gestionar tanto salidas de mercancías planificadas como salidas de mercancías no planificadas.

En una reserva se almacena la información importante para la salida de mercancías y para la planificación de necesidades, por ejemplo: (1) ¿Qué? (¿qué material?), (2) ¿Cuánto? (¿qué cantidad?), (3) ¿Cuándo? (¿para qué fecha de necesidad?), (4) ¿De dónde? (¿de qué centro o almacén?) y (5) ¿A dónde? (¿a qué destinatario o cliente?)

Un documento de reserva consiste en una cabecera y, al menos, una posición. La cabecera contiene datos generales sobre la reserva (creador, clase de movimiento, imputación). Las posiciones describen los movimientos individuales planificados (material, cantidad, fecha de necesidad).

Puede crearse una reserva para un único objetivo, es decir, en una reserva solamente se puede introducir una clase de movimiento y un objeto de imputación (por ejemplo, un centro de coste). El sistema realiza reservas a nivel de centro o almacén. En relación a los materiales sujetos a lotes, también pueden crearse reservas a nivel de lote.

El Sistema R/3 soporta reservas manuales y automáticas. Las reservas manuales las introduce el usuario directamente. Las reservas automáticas las genera el Sistema R/3 automáticamente. Existen dos tipos de reservas automáticas:

Reservas para órdenes, grafos y elementos PEP: Al crear una orden, un grafo o un proyecto, los componentes del almacén quedan automáticamente reservados.

Reservas de traslados: Si se emplea la planificación de necesidades por punto de pedido a nivel de almacén y el stock disponible está por debajo del punto de pedido, el sistema genera una reserva de traslado en el centro para la cantidad de reaprovisionamiento.

Las reservas automáticas no pueden tratarse manualmente. Por ejemplo, no es posible modificar directamente reservas para una orden. Deben modificarse los componentes de la orden. Luego, el sistema actualizará la reserva de forma automática.

Al introducir una reserva, se producen los siguientes eventos en el sistema:

a)El sistema crea un documento de reserva que sirve de comprobante de la orden.

b)En el registro maestro de materiales, el stock total y el stock de libre utilización del material permanecen intactos. El stock reservado se ve incrementado en la cantidad reservada.

c)En la planificación de necesidades de material, el stock disponible se ve reducido en la cantidad reservada. Esto se refleja en la lista de necesidades/stocks actual. La reserva requiere efectuar una entrada en el fichero de petición de planificación de necesidades.

Existen dos funciones que permiten visualizar el stock reservado:

Resumen de stocks a nivel de centro: Cuando se utiliza esta función, el sistema visualiza todo el stock de material reservado a nivel de centro. En el resumen de stocks, puede seleccionar Entorno / Reservas para visualizar una lista de las reservas de material.

Lista de necesidades/stocks actual: Al utilizar esta función, el sistema lista todas las reservas de material pendientes a nivel de centro, junto con la cantidad reservada para cada uno.

La planificación de materiales es un factor importante en el tema de reservas, ya que permite predecir el material existente y el necesario para abastecer los diferentes pedidos.

Traspasos - mySAP SCM

2010-05-06T11:55:00.001-07:00

Si un material sufre modificaciones a lo largo del tiempo, de tal modo que deja de corresponder a las características definidas en el registro maestro de materiales para coincidir con las características de un número de material distinto, debe realizar un traspaso de material a material. Esto ocurre a menudo, por ejemplo, en el caso de la industria química y farmacéutica.

Un traspaso de material a material tiene como resultado una cantidad trasladada que se gestiona en un número de material diferente. Para el material receptor ya debe existir un registro maestro de materiales. Ambos materiales deben gestionarse en la misma unidad de medida de almacén si se desea realizar un traspaso de material a material.

Un traspaso de este tipo siempre se realiza en una etapa y sin planificación previa. La contabilización sólo puede realizarse del stock de libre utilización del material de salida al stock de libre utilización del material receptor.

Para ingresar un traspaso de material a material, se realizan los siguientes pasos: (1) Seleccionar Gestión de stocks / Movimiento de mercancías / Traspaso, (2) Ingresar los datos de cabecera y seleccionar la clase de movimiento Traspaso / Material a material, (3) Ingresar el número del material receptor e ingresar las posiciones y (4) Verificar los datos de la pantalla de resumen y contabilizar el documento.

La cantidad trasladada se deduce del stock de libre utilización del material de salida y se contabiliza en el stock de libre utilización del material receptor. Para cada posición introducida, se crean dos posiciones de documento de material, es decir: (1) Una posición para el material de salida y (2) Una posición para el material receptor.

Se crea un documento contable paralelo al documento de material. El registro maestro de materiales de salida determina el valor del traspaso.

Respecto del tema traspasos, se recomienda efectuar un control del emisor y del receptor, para así evitar futuros problemas. Esto permitirá evaluar el proceso de comunicación interna que posee la empresa.

SD y CAM en CMMi SVC V1.2 (5)

2010-05-06T11:52:00.001-07:00

SERVICE DELIVERY

El propósito de ‘Service Delivery’ (SD), perteneciente al Nivel de Madurez 2, consiste en suministrar servicios según los acuerdos del servicio. Esta área de proceso abarca los siguientes procesos: (1) Establecer y mantener los acuerdos de servicio, (2) Preparar y mantener una propuesta de suministro del servicio, (3) Prepara el suministro del servicio, (4) Suministrar el servicio, (5) Recibir y procesar las solicitudes de servicio y (6) Mantener los sistemas de servicios.

El suministro del servicio abarca el establecimiento y mantenimiento del acuerdo escrito con los clientes. Un acuerdo de servicio describe el servicio a ser entregado al cliente, los objetivos del servicio, y las responsabilidades del proveedor del servicio, cliente y usuario final. Este acuerdo puede abarcar varios servicios o varios clientes.

Esta área de proceso establece una relación entre el proveedor del servicio y sus clientes y los usuarios finales mientras se cumpla con las necesidades de estas 3 partes. El cliente es la parte responsable de aceptar el servicio o autorizar el pago.

SD se relaciona con las siguientes áreas de proceso: SSD, SST, CM y PMC. Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta área de proceso son:

SG 1 – Establish Service Agreements

SP 1.1 – Analyze existing Agreements and Service Data

1.1.1- Review available customer and end-user need data 1.1.2- Review concerns of service delivery and support personnel. 1.1.3- Review existing service agreements and supplier agreements. 1.1.4- Review available current service data and service system designs. 1.1.5- Analyze the capability to supply requested services.

SP 1.2 – Establish the Service Agreements

1.2.1- Define the structure and format of the service agreement 1.2.2- Define, negotiate, and obtain agreement on a draft service agreement. 1.2.3- Publish the service agreement and make it available to service providers, customers, and end users, as appropriate 1.2.4- Review and revise the service agreement on a periodic and event driven basis as appropriate.

Productos de trabajo típicos

Customer descriptions of plans, goals, and service needs (SP 1.1) Results of customer and end-user satisfaction surveys and questionnaires (SP 1.1) Results of assessments of provider capability to meet customer needs (SP 1.1) Service agreement (SP 1.2)

SG 2 – Prepare for Service Delivery

SP 2.1 – Establish the Service Delivery Approach

2.1.1- Define criteria for determining service requests. 2.1.2- Define categories for service requests and criteria for categorizing service requests. 2.1.3- Describe how responsibility for processing service requests is assigned and transferred. 2.1.4- Identify one or more mechanisms that customers and end users can use to submit service requests. 2.1.5- Identify requirements on the amount of time defined for the fulfillment of service requests in the service agreement. 2.1.6- Determine the resource requirements for service delivery as required. 2.1.7- Review, refine, or enhance stakeholder communication mechanisms (e.g., notices, status reports, dashboards) as necessary. 2.1.8- Document the service delivery approach. 2.1.9- Review and get agreement with relevant stakeholders on the approach for delivering each separately identifiable service. 2.1.10- Revise the approach for delivering services as necessary.

SP 2.2 – Prepare for Service System Operations

2.2.1- Confirm that the appropriate service system’s components and tools are operational. 2.2.2- Evaluate the results of confirming service system component readiness and determine what corrective action is needed. 2.2.3- Review the service level requirements in the service agreements and ensure that proper thresholds are set in service system monitoring tools. 2.2.4- Develop, review, or refine service delivery procedures 2.2.5- Ensure that necessary resources are available for performing service delivery activities and tasks 2.2.6- Ensure that necessary resources are available for performing service delivery activities and tasks 2.2.7- Ensure that any necessary consumables are available for service delivery

SP 2.3 – Establish a Request Management System

2.3.1- Ensure that the request management system allows the reassignment and transfer of requests among groups 2.3.2- Ensure that the request management system allows the storage, update, and retrieval of request management information 2.3.3- Ensure that the request management system enables data reporting that is useful to the fulfillment of requests. 2.3.4- Maintain the integrity of the request management system and its contents 2.3.5- Maintain the request management system as necessary Maintain the request management system as necessary.

Productos de trabajo típicos

Service delivery approach (i.e., approach to request management and service system operations) (SP 2.1) Contact and roster lists (SP 2.1) Service request criteria (SP 2.1) Internal status reporting templates (e.g., dashboards) (SP 2.1) External status reporting templates (e.g., service request completion notices) (SP 2.1) Monitoring tool thresholds validation report (SP 2.2) Operating procedures validation report (SP 2.2) Consumables (e.g., paper media, magnetic media) validation report (SP 2.2) Logs of consumable acquisition and use (SP 2.2) Service delivery logs and receipts (SP 2.2) Results from demonstrated service system operation (SP 2.2) A request management system with controlled work products (SP 2.3) Access control procedures for the request management system (SP 2.3)

SG 3 – Deliver Service

SP 3.1 – Receive and Process Service Requests

3.1.1- Receive service requests and ensure each request is within the scope of the service agreement. 3.1.2- Record information about the service request 3.1.3- Categorize and analyze the service request. 3.1.4- Determine which resources are required to resolve the service request 3.1.5- Determine actions that must be taken to satisfy the service request 3.1.6- Plan the actions further as appropriate. 3.1.7- Monitor the status of service requests as appropriate until they are fulfilled as described in the service agreement 3.1.8- Review service request status and resolution, and confirm results with relevant stakeholders. 3.1.9- Close the service request and record the actions taken and results

SP 3.2 – Operate the Service System

3.2.1- Operate service system components according to service system procedures 3.2.2- Perform operations support activities (e.g., revise thresholds). 3.2.3- Manage the critical dependencies and paths of the service delivery schedules according to operating procedures 3.2.4- Manage and control the security of service delivery 3.2.5- Perform low-level monitoring of service system components using monitoring and data collection tools as appropriate 3.2.6- As appropriate, perform the activities needed to fulfill service requests or resolve service incidents according to the service agreement 3.2.7- Communicate the status of service requests until closed. 3.2.8- Collect customer satisfaction information immediately after services are delivered or service requests are fulfilled.

SP 3.3 – Maintain in Service System

3.3.1- Review maintenance requests and prioritize requests based on criteria identified when establishing the service delivery approach 3.3.2- Analyze impacts on service systems and services delivery. 3.3.3- Develop a plan to implement maintenance. 3.3.4- Release maintenance notifications to relevant stakeholders. 3.3.5- Update service system documentation as appropriate. 3.3.6- Implement and test corrective or preventive maintenance according to the plan and operating procedures. 3.3.7- Submit maintenance documentation and configuration changes to a configuration management repository.

Productos de trabajo típicos

Request management record (SP 3.1) Action proposal (SP 3.1) Customer satisfaction data (SP 3.1) End user receipts confirming request fulfillment (SP 3.1) List of services delivered (SP 3.2) Service logs (SP 3.2) Performance reports and dashboards (SP 3.2) Log of corrective actions (SP 3.2) Customer satisfaction data (SP 3.2) Request management database record (SP 3.2) Corrective or preventive maintenance change requests (SP 3.3) Maintenance notifications (SP 3.3) Preventive maintenance schedules (SP 3.3)

CAPACITY AND AVAILABILITY MANAGEMENT

El propósito de (CAM), perteneciente al Nivel de Madurez 3, consiste en asegurar el performance del sistema de servicio y asegurar que los recursos son suministrados y utilizados de manera efectiva para cumplir con los requerimientos del servicio.

Esta área de proceso involucra lo siguiente: (1) Establecer y mantener una estrategia de manejo de capacidad y disponibilidad, (2) Suministrar y ubicar, de manera apropiada, los recursos necesarios, (3) Monitorear, analizar, entender e informar sobre las demandas actuales y futuras de servicios, uso de recursos, capacidad, performance del sistema de servicio y disponibilidad del servicio; y (4) Determinar acciones correctivas para asegurar la capacidad y disponibilidad apropiada teniendo en cuenta el balanceo de costos, recursos necesarios y oferta/demanda.

En el contexto de servicios, la “capacidad” puede referirse a la cantidad máxima de entrega de servicios o número máximo de solicitudes de servicios que un sistema de servicios puede manejar de manera exitosa dentro de un período de tiempo fijo. La “disponibilidad” es el grado en el cual alguna cosa es accesible y útil cuando es necesario.

CAM se relaciona con las siguientes áreas de proceso: IRP, SC, SD, SSM y PP. Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta área de proceso son:

SG 1 - Prepare for Capacity and Availability Management

SP 1.1 - Establish a Capacity and Availability Management Strategy

1.1.1 - Document resource and service use, performance, and availability. 1.1.2- Estimate future resource and service capacity and availability requirements. 1.1.3- Develop a capacity strategy that meets service requirements, meets the demand for resources and services, and addresses how resources are provided, used, and allocated. 1.14- Develop an availability strategy that meets service requirements and addresses delivering a sustained level of availability. 1.1.5- Document monetized costs and benefits of the strategy and any assumptions. 1.1.6- Periodically revise the strategy.

SP 1.2 - Select Measures and Analytic Techniques

1.2.1- Identify measures from organizational process assets that support capacity and availability management objectives. 1.2.2- Identify and specify additional measures that may be needed to support achieving capacity and availability management objectives for the service. 1.2.3- Analyze the relationship between identified measures and service requirements, and derive objectives that state specific target measures or ranges to be met for each measured attribute.

SP 1.3 - Establish Service System Representations

1.3.1- Collect measurements on the use of resources and services and the current service levels delivered. 1.3.2- Establish and maintain descriptions of the normal use of service resources and service system performance. 1.3.3- Establish and maintain service system representations from collected measurements and analyses. 1.3.4- Review and get agreement with relevant stakeholders about the descriptions of the normal use of service resources, service system performance, and service system representations. 1.3.5-. Make available the descriptions of the normal use of service resources, service system performance, and service system representations. 1.3.6- Establish and maintain thresholds associated with demand, workload, use of service resources, and service system performance to define exception conditions in the service system and breaches or near breaches of service requirements.

Productos de trabajo típicos

Capacity and availability management strategy (SP 1.1) Operational definitions of capacity and availability measures (SP 1.2) Traceability of capacity and availability measures to service requirements (SP 1.2) Tools to support collection and analysis of capacity and availability data (SP 1.2) Target measures or ranges to be met for selected measured attributes (SP 1.2) Representations of resource and service use (SP 1.3) Representations of service levels (SP 1.3) Data on the use of resources and services (SP 1.3) Data on current service levels delivered (SP 1.3) Thresholds that define exception conditions and breaches (SP 1.3)

SG 2 - Monitor and Analyze Capacity and Availability

SP 2.1 - Monitor and Analyze Capacity

2.1.1- Monitor the use of service resources against thresholds, descriptions of normal use, and service system performance. 2.2.2- Monitor service response times. 2.1.3- Identify breaches of thresholds and exception conditions 2.1.4- Determine the corrective action to be taken. 2.1.5- Estimate future changes (either growth or reduction) in the use of resources and services. 2.1.6- Store capacity and availability data, specifications, analysis results, and monitoring data.

SP 2.2 - Monitor and Analyze Availability

2.2.1- Monitor availability, reliability, and maintainability against their requirements. 2.2.2- Analyze trends in availability, reliability, and maintainability. 2.2.3- Identify breaches of availability, reliability, and maintainability requirements. 2.2.4- Determine the corrective actions to be taken.

SP 2.3 - Report Capacity and Availability Management Data

2.3.1- Report the performance and use of resources and services. 2.3.2- Report exception conditions in the service system and breaches of service requirements. 2.3.3- Report data from monitoring against growth estimates in resource and service use. 2.3.4- Report the availability, reliability, and maintainability of resources and services.

Productos de trabajo típicos

Service resource use data (SP 2.1) Growth analysis of service use (SP 2.1) List of resources not used as estimated (SP 2.1) Alarm data (SP 2.2) Availability data (SP 2.2) Reliability data (SP 2.2) Maintainability data (SP 2.2) Service system performance reports (SP 2.3) Service resource use reports (SP 2.3) Service resource use projections (SP 2.3) Service availability reports (SP 2.3)

REQM y SAM en CMMi SVC V1.2 (4)

2010-04-04T10:56:00.000-07:00

REQUIREMENTS MANAGEMENT

EL propósito de ‘Requirements Management’ (REQM), perteneciente al Nivel de Madurez 2, es administrar los requerimientos de los productos y de los componentes del producto del proyecto. Permite identificar las inconsistencias entre estos requerimientos y los productos de trabajo y planes del proyecto.

Los procesos de manejo de requerimientos administran todos los requerimientos recibidos o generados en el proyecto, incluyendo los requerimientos técnicos y no técnicos. Todos los requerimientos que el cliente y proveedor del servicio han aprobado son tratados en esta área de proceso. Esta área de proceso es implementada y genera requerimientos del cliente y del contrato que serán administrados por los procesos de manejo de requerimientos.

Parte de la administración de requerimientos consiste en documentar los cambios de los requerimientos y mantener la relación bidireccional de trazabilidad entre los requerimientos originales y todos los requerimientos de los componentes del producto y del producto.

Todos los proyectos tienen requerimientos. En el caso de las actividades de mantenimiento, los cambios del producto o de los componentes del producto están basados en los cambios de los actuales requerimientos, en el diseño o en la implementación. Los cambios de los requerimientos pueden ser documentados en las solicitudes de cambio del cliente o pueden tomar la forma de nuevos requerimientos recibidos del proceso de desarrollo de requerimientos.

REQM se relaciona con las siguientes áreas de proceso: SSD, SSM, CM, PMC, PP y RSKM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Manage Requirements

SP 1.1 – Understand Requirements

1.1.1- Establish criteria for distinguishing appropriate requirements providers. 1.1.2- Establish objective criteria for the evaluation and acceptance of requirements. 1.1.3- Analyze requirements to ensure that established criteria are met. 1.1.4- Reach an understanding of requirements with requirements provider so that project participants can commit to them.

SP 1.2 - Obtain Commitment to Requirements

1.2.1- Assess the impact of requirements on existing commitments. 1.2.2- Negotiate and record commitments.

SP 1.3 - Manage Requirements Changes

1.3.1- Document all requirements and requirements changes that are given to or generated by the project. 1.3.2- Maintain a requirements change history including the rationale for changes. 1.3.3- Evaluate the impact of requirement changes from the standpoint of relevant stakeholders. 1.3.4- Make requirements and change data available to the project.

SP 1.4 - Maintain Bidirectional Traceability of Requirements

1.4.1- Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented. 1.4.2- Maintain requirements traceability from a requirement to its derived requirements and allocation to functions, interfaces, objects, people, processes, and work products. 1.4.3- Generate a requirements traceability matrix.

SP 1.5 - Identify Inconsistencies between Project Work and Requirements

1.5.1- Review project plans, activities, and work products for consistency with requirements and changes made to them. 1.5.2- Identify the source of the inconsistency 1.5.3- Identify changes that must be made to plans and work products resulting from changes to the requirements baseline. 1.5.4- Initiate corrective actions.

Productos de trabajo típicos

Lists of criteria for distinguishing appropriate requirements providers (SP 1.1) Criteria for evaluation and acceptance of requirements (SP 1.1) Results of analyses against criteria (SP 1.1) A set of approved requirements (SP 1.1) Requirements impact assessments (SP 1.2) Documented commitments to requirements and requirements changes (SP 1.2) Requirements status (SP 1.3) Requirements database (SP 1.3) Requirements decision database (SP 1.3) Requirements traceability matrix (SP 1.4) Requirements tracking system (SP 1.4) Documentation of inconsistencies between requirements and project plans and work products, including sources and conditions (SP 1.5) Corrective actions (SP 1.5)

SUPPLIER AGREEMENT MANAGEMENT

El propósito de ‘Supplier Agreement Management’ (SAM), perteneciente al Nivel de Madurez 2, consiste en administrar la adquisición de productos y servicios por parte de proveedores.

Esta área de proceso trata la adquisición de productos, servicios, y componentes de servicios y productos que pueden ser entregados al cliente del proyecto o incluidos en el sistema de servicio. Estas prácticas de las áreas de proceso pueden ser usadas para otros propósitos que benefician al proyecto.

SAM involucra las siguientes actividades: (1) Determinar el tipo de adquisición, (2) Seleccionar los proveedores, (3) Establecer y mantener acuerdos con los proveedores, (4) Ejecutar los acuerdos con los proveedores, (5) Monitorear los procesos de los proveedores seleccionados, (6) Evaluar los productos de trabajo de los proveedores seleccionados, (7) Aceptar la entrega de los productos adquiridos y (8) Asegurar una transición exitosa de los productos adquiridos en el proyecto.

CAM se relaciona con las siguientes áreas de proceso: SSD, PMC y REQM. Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta área de proceso son:

SG 1 – Establish Supplier Agreement

SP 1.1 – Determine Acquisition Type

SP 1.2 – Select Suppliers

1.2.1- Establish and document criteria for evaluating potential suppliers. 1.2.2- Identify potential suppliers and distribute solicitation material and requirements to them. 1.2.3- Evaluate proposals according to evaluation criteria. 1.2.4- Evaluate risks associated with each proposed supplier. 1.2.5- Evaluate proposed suppliers’ ability to perform the work. 1.2.6- Select the supplier.

SP 1.3 – Establish Supplier Agreements

1.3.1- Revise the requirements (e.g., product requirements, service level requirements) to be fulfilled by the supplier to reflect negotiations with the supplier when necessary. 1.3.2- Document what the project will provide to the supplier. 1.3.3- Document the supplier agreement. 1.3.4- Periodically review the supplier agreement to ensure it accurately reflects the project’s relationship with the supplier and current risks and market conditions. 1.3.5- Ensure that all parties to the supplier agreement understand and agree to all requirements before implementing the agreement or any changes. 1.3.6- Revise the supplier agreement as necessary to reflect changes to the supplier’s processes or work products. 1.3.7- Revise the project’s plans and commitments, including changes to the project’s processes or work products, as necessary to reflect the supplier agreement.

Productos de trabajo típicos

List of the acquisition types that will be used for all products and product components to be acquired (SP 1.1) Market studies (SP 1.2) List of candidate suppliers (SP 1.2) Preferred supplier list (SP 1.2) Trade study or other record of evaluation criteria, advantages and disadvantages of candidate suppliers, and rationale for selection of suppliers (SP 1.2) Solicitation materials and requirements (SP 1.2) Statements of work (SP 1.3) Contracts (SP 1.3) Memoranda of agreement (SP 1.3) Licensing agreement (SP 1.3)

SG 2 – Satisfy Supplier Agreements

SP 2.1 – Execute the Supplier Agreement

2.1.1- Monitor supplier progress and performance (e.g., schedule, effort, cost, technical performance) as defined in the supplier agreement. 2.1.2- Conduct reviews with the supplier as specified in the supplier agreement. 2.1.3- Conduct technical reviews with the supplier as defined in the supplier agreement. 2.1.4- Conduct management reviews with the supplier as defined in the supplier agreement. 2.1.5- Use the results of reviews to improve the supplier’s performance and to establish and nurture long-term relationships with preferred suppliers 2.1.6- Monitor risks involving the supplier and take corrective action as necessary

SP 2.2 – Monitor Selected Supplier Processes

2.2.1- Identify the supplier processes that are critical to the success of the project. 2.2.2- Monitor the selected supplier’s processes for compliance with requirements of the supplier agreement. 2.2.3- Analyze the results of monitoring the selected processes to detect issues as early as possible that may affect the supplier’s ability to satisfy the requirements of the supplier agreement. 2.2.4- Determine and document actions needed to resolve detected issues

SP 2.3 – Evaluate Selected Supplier Work Products

2.3.1- Identify the work products that are critical to the success of the project and that should be evaluated to help detect issues early. 2.3.2- Evaluate the selected work products. 2.3.3- Determine and document actions needed to address deficiencies identified in the evaluations.

SP 2.4 – Accept the Acquired Product

2.4.1- Define the acceptance procedures. 2.4.2- Review and obtain agreement from relevant stakeholders on the acceptance procedures before the acceptance review or test. 2.4.3- Verify that the acquired products satisfy their requirements. 2.4.4- Confirm that the nontechnical commitments associated with the acquired products are satisfied. 2.4.5- Document the results of the acceptance review or test. 2.4.6- Establish an action plan and obtain supplier agreement to take action to correct acquired products that do not pass their acceptance review or test. 2.4.7- Track action items to closure.

SP 2.5 – Ensure Transition of Products

2.5.1- Ensure that there are facilities to receive, store, integrate, and maintain the acquired products, as appropriate. 2.5.2- Ensure that appropriate training is provided for those involved in receiving, storing, integrating, and maintaining acquired products. 2.5.3- Ensure that acquired products are stored, distributed, and integrated according to the terms and conditions specified in the supplier agreement or license.

Productos de trabajo típicos

Supplier progress reports and performance measures (SP 2.1) Supplier review materials and reports (SP 2.1) Action items tracked to closure (SP 2.1) Product and documentation deliveries (SP 2.1) List of processes selected for monitoring or rationale for nonselection (SP 2.2) Activity reports (SP 2.2) Performance reports (SP 2.2) Performance curves (SP 2.2) Discrepancy reports (SP 2.2) List of work products selected for evaluation or rationale for nonselection (SP 2.3) Activity reports (SP 2.3) Discrepancy reports (SP 2.3) Acceptance procedures (SP 2.4) Acceptance review or test results (SP 2.4) Discrepancy reports or corrective action plans (SP 2.4) Transition plans (SP 2.5) Training reports (SP 2.5) Support and maintenance reports (SP 2.5) Descriptions of how ongoing support obligations, such as warranties and licenses, will be satisfied (SP 2.5)

Traslados - mySAP SCM

2010-04-04T08:28:00.001-07:00

En una empresa, los movimientos de mercancías no sólo se dan en forma de entrada de mercancías y de salida de mercancías. Según la organización de la empresa (como por ejemplo, almacenamiento descentralizado) y su política de ventas, también podría resultar necesario un traslado interno. Pueden darse traslados en tres niveles diferentes: (1) Traslado de sociedad a sociedad, (2) Traslados de centro a centro y (3) De almacén a almacén (dentro del mismo centro)

Traslado de sociedad a sociedad: El traslado de sociedad a sociedad corresponde a un traslado de centro a centro, cuando ambos centros pertenecen a diferentes sociedades.

Traslado de centro a centro: Un traslado de centro a centro no sólo provoca una modificación de la cantidad de stocks en ambos centros; si se asignan ambos centros a ámbitos de valoración distintos, también se crea un documento contable. Esta clase de traslado sólo puede realizarse desde el stock de libre utilización del centro suministrador hasta el stock de libre utilización del centro receptor. Los traslados de centro a centro son relevantes para la planificación de necesidades, dado que ésta opera a nivel de centro.

De almacén a almacén (dentro del mismo centro): Un traslado de almacén a almacén dentro del mismo centro provoca simplemente la actualización de las cantidades de stock de ambos almacenes. El valor de stocks no se modifica y el evento no es relevante para Finanzas. Un traslado de almacén a almacén puede realizarse para todo tipo de stocks.

Traspasos y traslados: Diferencias

En el Sistema R/3 es posible contabilizar tanto traslados como traspasos. Los traspasos se diferencian de los traslados en que los traspasos no están relacionados con un movimiento de mercancías físico. Por lo general, implican una modificación del tipo de stocks, el número de lote o el número de material. Un ejemplo de traspaso es la liberación de inspección en el stock propio de la empresa.

Procedimientos del traslado

Existen tres procedimientos diferentes para realizar un traslado: (1) Traslado mediante traspaso utilizando un procedimiento en una etapa, (2) Traslado mediante traspaso utilizando un procedimiento en dos etapas y (3) Traslado mediante pedido de traslado

Los traslados y los traspasos consisten en una "salida de mercancías" de un punto de salida y una "entrada de mercancías" en un punto de recepción. Un traslado de almacén a almacén o de centro a centro puede contabilizarse en una o en dos etapas. La ventaja del procedimiento en una etapa es que se introduce una sola operación en el sistema.

Por otra parte, el procedimiento en dos etapas le permite controlar los stocks en tránsito. Después de contabilizar la salida de mercancías en el punto de salida, el stock aparece "en traslado" en el punto de recepción y se gestiona como tal en el sistema. El procedimiento en dos etapas también es necesario si los usuarios tienen autorizaciones únicamente para sus propios centros.

Para realizar un traslado de centro a centro de un material valorado por separado en el punto de recepción, debe utilizarse el procedimiento en una etapa o un pedido de traslado.

Traslados y traspasos mediante la función de determinación de stocks Si desea tomar material para traspasos y traslados de varios almacenes y stocks de acuerdo con una estrategia concreta, el Sistema R/3 puede darle soporte por medio de la Determinación de stocks.

Respecto del tema traslado, se recomienda efectuar un control del emisor y del receptor, para así evitar futuros problemas. Esto permitirá evaluar el proceso de comunicación interna que posee la empresa.

PP y PPQA en CMMi SVC V1.2 (3)

2010-03-03T04:59:00.000-08:00

PROJECT PLANNING

El propósito de ‘Project Planning’ (PP), perteneciente al Nivel de Madurez 2, consiste en establecer y mantener los planes que se definen en las actividades del proyecto. Esta área de proceso involucra lo siguiente: (1) Desarrollo del plan de proyecto, (2) Interacción con las partes interesadas, (3) Obtener la conformidad respecto del plan y (4) Mantenimiento del plan.

La planificación comienza con los requerimientos que definen el producto y el proyecto. La planificación del proyecto incluye el desarrollo y mantenimiento de los planes de todos los procesos adquiridos incluidos los procesos que requieren una interacción proveedor-cliente. También incluye establecer y mantener un plan para la transición al producto adquirido.

El plan de proyecto necesita ser revisado para poder administrar los cambios que se realizan en los requerimientos. Estos cambios pueden afectar las estimaciones de la planificación del proyecto, los presupuestos, riesgos, tareas del proyecto, recursos y confirmaciones. PP se relaciona con las siguientes áreas de proceso: CAM, SD, SSD, SSM, MA, REQM y RSKM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Establish Estimates

SP 1.1 – Establish the Project Strategy

1.1.1- Identify the objectives of the project and the capabilities it intends to provide. 1.1.2- Identify the approach used to achieve the objectives or provide the capabilities. 1.1.3- Document business considerations 1.1.4- Identify major resources needs. 1.1.5- Identify stakeholders that will play major roles in the project. 1.1.6- Identify the agreement types to be used. 1.1.7- Identify risks and how those risks may be allocated to various stakeholders. 1.1.8- Identify the approach used to maintain safety and security in the project. 1.1.9- Review the project strategy with senior management and obtain its agreement. 1.1.10- Revise the project strategy as necessary.

SP 1.2 - Estimate the Scope of the Project

1.2.1- Develop a WBS (Work Breakdown Structure) based on the project strategy. 1.2.2- Define the work packages in sufficient detail so that estimates of project tasks, responsibilities, and schedule can be specified. 1.2.3- Identify product or product components to be externally acquired. 1.2.4- Identify work products to be reused.

SP 1.3 - Establish Estimates of Work Product and Task Attributes

1.3.1- Use appropriate methods to determine the attributes of the work products and tasks to be used to estimate resource requirements 1.3.2- Estimate the attributes of work products and tasks.

SP 1.4 - Define Project Life Cycle

SP 1.5 – Estimate Effort and Cost

1.5.1- Collect models or historical data to be used to transform the attributes of work products and tasks into estimates of labor hours and costs. 1.5.2- Include supporting infrastructure needs when estimating effort and cost. 1.5.3- Estimate effort and cost using models and historical data.

Productos de trabajo típicos

Project strategy (SP 1.1) Task descriptions (SP 1.2) Work package descriptions (SP 1.2) WBS (SP 1.2) Technical approach (SP 1.3) Size and complexity of tasks and work products (SP 1.3) Estimating models (SP 1.3) Attribute estimates (SP 1.3) Project lifecycle phases (SP 1.4) Estimation rationale (SP 1.5) Project effort estimates (SP 1.5) Project cost estimates (SP 1.5)

SG 2 - Develop a Project Plan

SP 2.1 - Establish the Budget and Schedule

2.1.1- Identify major milestones. 2.1.2- Identify schedule assumptions. 2.1.3- Identify constraints 2.1.4- Identify task dependencies. 2.1.5- Define the budget and schedule. 2.1.6- Establish corrective action criteria.

SP 2.2 - Identify Project Risks

2.2.1- Identify risks. 2.2.2- Document risks 2.2.3- Review and obtain agreement with relevant stakeholders on the completeness and correctness of documented risks. 2.2.4- Revise risks, as appropriate.

SP 2.3 - Plan Data Management

2.3.1-Establish requirements and procedures to ensure privacy and security of data. 2.3.2- Establish a mechanism to archive data and to access archived data. 2.3.3- Determine the project data to be identified, collected, and distributed. 2.3.4- Determine the requirements for providing access to and distribution of data to stakeholders. 2.3.4- Decide which project data and plans require version control or more stringent levels of configuration control and establish mechanisms to ensure project data are controlled.

SP 2.4 - Plan the Project’s Resources

2.4.1- Determine process requirements. 2.4.2- Determine requirements for communication mechanisms. 2.4.3- Determine staffing requirements. 2.4.4- Determine facility, equipment, and component requirements. 2.4.5- Determine other continuing resource requirements.

SP 2.5 - Plan Needed Knowledge and Skills

2.5.1- Identify the knowledge and skills needed to perform the project. 2.5.2- Assess the knowledge and skills available. 2.5.3- Select mechanisms for providing needed knowledge and skills. 2.5.4- Incorporate selected mechanisms into the project plan.

SP 2.6 - Plan Stakeholder Involvement

SP 2.7 – Establish the Project Plan

2.7.1- Document the project plan. 2.7.2- Include, reference and reconcile the results of planning activities as appropriate. 2.7.3- Review the project plan with relevant stakeholders and get its agreement. 2.7.4- Revise the project plan as necessary.

Productos de trabajo típicos

Project schedules (SP 2.1) Schedules dependencies (SP 2.1) Project budget (SP 2.1) Identified risks (SP 2.2) Risk impacts and probability of occurrence (SP 2.2) Risk priorities (SP 2.2) Data management plan (SP 2.3) Master list of managed data (SP 2.3) Data content and format description (SP 2.3) List of data requirements for acquirers and suppliers (SP 2.3) Privacy requirements (SP 2.3) Security requirements (SP 2.3) Security procedures (SP 2.3) Mechanisms for data retrieval, reproduction, and distribution (SP 2.3) Schedule for the collection of project data (SP 2.3) List of project data to be collected (SP 2.3) Work packages (SP 2.4) WBS task dictionary (SP 2.4) Staffing requirements based on project size and scope (SP 2.4) Critical facilities and equipment list (SP 2.4) Process and workflow definitions and diagrams (SP 2.4) Project administration requirements list (SP 2.4) Status reporting templates (SP 2.4) Inventory of skill needs (SP 2.5) Staffing and new hire plans (SP 2.5) Databases (SP 2.5) Training Plans (SP 2.5) Stakeholder involvement plan (SP 2.6) Overall project plan (SP 2.7)

SG 3 - Obtain Commitment to the Plan v SP 3.1 - Review Plans that Affect the Project

SP 3.2 - Reconcile Work and Resource Levels

SP 3.3 - Obtain Plan Commitment

3.3.1- Identify needed support and negotiate commitments with relevant stakeholders. 3.3.2- Document all organizational commitments, both full and provisional, ensuring the appropriate level of signatories. 3.3.3- Review internal commitments with senior management as appropriate. 3.3.4- Review external commitments with senior management as appropriate. 3.3.5- Identify commitments regarding interfaces between project elements and other projects and organizational units so that these commitments can be monitored.

Productos de trabajos típicos

Record of the reviews of plans that affect the project (SP 3.1) Revised methods and corresponding estimating parameters (SP 3.2) Renegotiated budgets (SP 3.2) Revised schedules (SP 3.2) Revised requirements list (SP 3.2) Renegotiated stakeholder agreements (SP 3.2) Documented requests for commitments (SP 3.3) Documented commitments (SP 3.3)

PROCESS AND PRODUCT QUALITY ASSURANCE

El propósito de ‘Process and Producto Quality Assurance’ (PPQA), perteneciente al Nivel de Madurez 2, es cumplir con objetivos del staff y de la dirección respecto de procesos y productos de trabajo asociados.

PPQA se desarrolla por medio de las siguientes actividades: (1) Evaluar objetivamente los procesos y productos de trabajo realizados y a los que se les aplicó descripciones de proceso, estándares y procedimientos; (2) Identificar y documentar las no conformidades, (3) Suministrar datos actualizados al staff y a la dirección acerca de los resultados de las actividades de aseguramiento de la calidad y (4) Asegurar que las no conformidades fueron tratadas.

PPQA da soporte en la entrega de productos y servicios de alta calidad. Las prácticas de PPQA aseguran que los procesos planeados son implementados, mientras que las prácticas de Service System Development (SSD) aseguran que son satisfechos los requerimientos especificados.

El aseguramiento de la calidad comienza en las primeras del proyecto para establecer planes, procesos, estándares y procedimientos que agregarán valor al proyecto y permitirán satisfacer los requerimientos del proyecto y las políticas organizacionales.

PPQA se aplica a evaluaciones de productos, procesos, evaluaciones actividades que no son proyecto y productos de trabajo. PPQA se relaciona con SSD.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Objectively Evaluate Processes and Work Products

SP 1.1 - Objectively Evaluate Processes

1.1.1- Promote an environment that encourages employee participation in identifying and reporting quality issues. 1.1.2- Establish and maintain clearly stated criteria for evaluations. 1.1.3- Use the stated criteria to evaluate performed processes for adherence to process descriptions, standards, and procedures. 1.1.4- Identify each noncompliance found during the evaluation. 1.1.5- Identify lessons learned that could improve processes for future products.

SP 1.2 - Objectively Evaluate Work Products

1.2.1- Select work products to be evaluated based on documented sampling criteria if sampling is used. 1.2.2- Establish and maintain clearly stated criteria for the evaluation of selected work products. 1.2.3- Use the stated criteria during the evaluations of selected work products. 1.2.4- Evaluate selected work products at selected periods in their lifetime as appropriate including before and during delivery to the customer. 1.2.5- Perform in-progress or incremental evaluations of selected work products against process descriptions, standards, and procedures. 1.2.6- Identify each case of noncompliance found during evaluations. 1.2.7- Identify lessons learned that could improve processes for future products.

Productos de trabajo típicos

Evaluation reports (SP 1.1) Noncompliance reports (SP 1.1) Corrective actions (SP 1.1) Evaluation reports (SP 1.2) Noncompliance reports (SP 1.2) Corrective actions (SP 1.2) SG 2 - Provide Objective Insight

SP 2.1 - Communicate and Ensure Resolution of Noncompliance Issues 2.1.1- Resolve each noncompliance with the appropriate members of the staff if possible. 2.1.2- Document noncompliance issues when they cannot be resolved in the project. 2.1.3- Escalate noncompliance issues that cannot be resolved in the project to the appropriate level of management designated to receive and act on noncompliance issues. 2.1.4- Analyze noncompliance issues to see if there are quality trends that can be identified and addressed. 2.1.5- Ensure that relevant stakeholders are aware of results of evaluations and quality trends in a timely manner. 2.1.6- Periodically review open noncompliance issues and trends with the manager designated to receive and act on noncompliance issues. 2.1.7- Track noncompliance issues to resolution.

SP 2.2 - Establish Records

2.2.1- Record process and product quality assurance activities in sufficient detail so that status and results are known. 2.2.2- Revise the status and history of quality assurance activities as necessary.

Productos de trabajo típicos

Corrective action reports (SP 2.1) Evaluation reports (SP 2.1) Quality trends (SP 2.1) Evaluation logs (SP 2.2) Quality assurance reports (SP 2.2) Status reports of corrective actions (SP 2.2) Reports of quality trends (SP 2.2)

Entrega posterior - mySAP SCM

2010-03-03T04:57:00.000-08:00

En la verificación de facturas basada en la entrada de mercancías, se pueden contabilizar entradas de mercancías como entregas posteriores para entradas de mercancías anteriores haciendo referencia al documento de entrada de mercancías original. En este proceso, el sistema copia el número de documento modelo original (MSEG-LFBNR) al documento de material nuevo, actualizando de este modo el enlace entre las entradas de mercancías y la factura correspondiente.

Las entregas posteriores son útiles, si, por ejemplo:

• Se anula una entrada de mercancías después de que haya introducido la factura correspondiente y, a continuación, se desea contabilizar otra entrada de mercancías • Se contabiliza una devolución y se desea introducir la entrada de mercancías siguiente con referencia al documento de devolución para que el enlace con la factura permanezca intacto.

Se puede usar la función de entrega posterior para las actividades de la empresa siguientes: Entrada de mercancías (clase de movimiento 101): En este caso, se contabiliza otra entrada de mercancías para un pedido (por ejemplo, en caso de entregas parciales o entregas adicionales).

Devolución (clase de movimiento 122): En este caso, contabilice otra entrada de mercancías después de que haya introducido una devolución

Anulación de la entrada de mercancías (clase de movimiento 102): En este caso, contabilice otra entrada de mercancías después de que haya anulado una entrada de mercancías.

Para contabilizar una entrega posterior, llame la transacción Enjoy MIGO para la contabilización de movimientos de mercancías y seleccione Entrega posterior. Las entregas posteriores pueden generar una actualización en la planificación de materiales. Este tipo de información sirve de referencia para la evaluación de los proveedores y las futuras toma de decisiones.

MA y PM en CMMI SVC v1.2 (2)

2010-02-05T13:41:00.001-08:00

MEASUREMENT AND ANALYSIS (MA)

El propósito de ‘Measurement and Analysis’ (MA), perteneciente al Nivel de Madurez 2, es desarrollar y sostener una capacidad de medición que es utilizada para dar soporte a las necesidades de información de la dirección. El staff requerido para implementar una capacidad de medición puede o no requerir de un programa aparte. La capacidad de medición puede estar integrada a los proyectos u otras funciones organizacionales.

La medición y análisis de los componentes de un producto, suministrado por un proveedor, son esenciales para la administración de la calidad y costos del proyecto. MA se relaciona con las siguientes áreas de procesos: SSD, OPD, PMC, PP y QPM.

Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Align Measurement and Analysis Activities

SP 1.1 - Establish Measurement Objectives 1.1.1- Document information needs and objectives. 1.1.2- Prioritize information needs and objectives. 1.1.3- Document, review and update measurement objectives. 1.1.4- Provide feedback for refining and clarifying information needs and objectives as necessary. 1.1.5- Maintain traceability of measurement objectives to identified information needs and objectives.

SP 1.2 - Specify Measures 1.2.1- Identify candidate measures based on documented measurement objectives. 1.2.2- Maintain traceability of measures to measurement objectives. 1.2.3- Identify existing measures that already address measurement objectives. 1.2.4- Specify operational definitions for measures. 1.2.5- Prioritize, review and update measures.

SP 1.3 - Specify Data Collection and Storage Procedures 1.3.1- Identify existing sources of data that are generated from current work products, processes, or transactions. 1.3.2- Identify measures for which data are needed, but are not currently available. 1.3.3- Specify how to collect and store the data for each required measure. 1.3.4- Create data collection mechanisms and process guidance. 1.3.5- Support automatic collection of data as appropriate and feasible. 1.3.6- Prioritize, review, and update data collection and storage procedures. 1.3.7- Update measures and measurement objectives as necessary.

SP 1.4 - Specify Analysis Procedures 1.4.1- Specify and prioritize the analyses to be conducted and the reports to be prepared. 1.4.2- Select appropriate data analysis methods and tools. 1.4.3- Specify administrative procedures for analyzing data and communicating results. 1.4.4- Review and update the proposed content and format of specified analyses and reports. 1.4.5- Update measures and measurement objectives as necessary. 1.4.6- Specify criteria for evaluating the utility of analysis results and for evaluating the conduct of measurement and analysis activities.

Productos de trabajo típicos

Measurement objetives (SP 1.1) Specifications of base and derived measures (SP 1.2) Data collection and storage procedures (SP 1.3) Data collection tools (SP 1.3) Analysis specifications and procedures (SP 1.4) Data analysis tools (SP 1.4) SG 2 - Provide Measurement Results

SP 2.1 - Obtain Measurement Data 2.1.1- Obtain data for base measures. 2.1.2- Generate data for derived measures. 2.1.3- Perform data integrity checks as close to the source of data as possible.

SP 2.2 - Analyze Measurement Data 2.2.1- Conduct initial analyses, interpret results, and draw preliminary conclusions. 2.2.2- Conduct additional measurement and analysis as necessary, and prepare results for presentation. 2.2.3- Review initial results with relevant stakeholders. 2.2.4- Refine criteria for future analyses.

SP 2.3 - Store Data and Results 2.3.1- Review the data to ensure their completeness, integrity, accuracy, and currency. 2.3.2- Store data according to data storage procedures. 2.3.3- Make stored contents available for use only to appropriate groups and personnel. 2.3.4- Prevent stored information from being used inappropriately.

SP 2.4 - Communicate Results 2.4.1- Keep relevant stakeholders informed of measurement results in a timely manner. 2.4.2- Assist relevant stakeholders in understanding results.

Productos de trabajo típicos

Base and derived measurement data sets (SP 2.1) Results of data integrity tests (SP 2.1) Analysis results and draft reports (SP 2.2) Stored data inventory (SP 2.3) Delivered reports and related analysis results (SP 2.4) Contextual information or guidance to help interpret analysis results (SP 2.4)

PROJECT MONITORING AND CONTROL

El propósito de ‘Project Monitoring and Control’ (PMC), perteneciente al Nivel de Madurez 2, es suministrar un entendimiento del avance del proyecto y de las acciones correctivas que pueden efectuarse cuando existen desviaciones del performance del proyecto respecto de lo planificado.

El plan del proyecto es la base para monitorear las actividades, comunicar el estado de las mismas, y efectuar las acciones correctivas. El avance es determinado por medio de la comparación del producto de trabajo actual y los atributos de la tarea. Cuando el estado actual tiene un desvío significativo respecto de los valores esperados, se efectúan acciones correctivas que pueden incluir la re-planificación, la cual puede incluir la revisión del plan original, estableciendo nuevos acuerdos o incluyendo actividades de mitigación en el plan actual.

PMC se relaciona con las siguientes áreas de proceso: CAM, MA y PP. Los objetivos específicos (SG), prácticas específicas (SP) y subprácticas de esta AP son:

SG 1 - Monitor the Project Against the Plan

SP 1.1 - Monitor Project Planning Parameters 1.1.1- Monitor progress against the schedule. 1.1.2- Monitor the project's cost and expended effort. 1.1.3- Monitor the attributes of work products and tasks. 1.1.4- Monitor resources provided and used. 1.1.5- Monitor the knowledge and skills of project personnel. 1.1.6- Document significant deviations in project planning parameters.

SP 1.2 - Monitor Commitments 1.2.1- Regularly review commitments (both external and internal). 1.2.2- Identify commitments that have not been satisfied or are at significant risk of not being satisfied. 1.2.3- Document the results of commitment reviews.

SP 1.3 - Monitor Project Risks 1.3.1- Periodically review the documentation of risks in the context of the project’s current status and circumstances. 1.3.2- Revise the documentation of risks as additional information becomes available. 1.3.3- Communicate the risk status to relevant stakeholders.

SP 1.4 - Monitor Data Management 1.4.1- Periodically review data management activities against their description in the project plan. 1.4.2- Identify and document significant issues and their impacts. 1.4.3- Document results of data management activity reviews.

SP 1.5 - Monitor Stakeholder Involvement 1.5.1- Periodically review the status of stakeholder involvement. 1.5.2- Identify and document significant issues and their impacts 1.5.3- Document the results of stakeholder involvement status reviews.

SP 1.6 - Conduct Progress Reviews 1.6.1- Regularly communicate status on assigned activities and work products to relevant stakeholders. 1.6.2- Review the results of collecting and analyzing measures for controlling the project. 1.6.3- Identify and document significant issues and deviations from the plan. 1.6.4- Document change requests and problems identified in work products and processes. 1.6.5- Document the results of reviews. 1.6.6- Track change requests and problem reports to closure.

SP 1.7 - Conduct Milestone Reviews 1.7.1- Conduct milestone with relevant stakeholders at meaningful points in the project’s schedule, such as the completion of selected stages 1.7.2- Review commitments, the plan, the status, and risks of the project. 1.7.3- Identify and document significant issues and their impacts. 1.7.4- Document results of the review, action items, and decisions. 1.7.5- Track action items to closure.

Productos de trabajo típicos

Records of project performance (SP 1.1) Records of significant deviations (SP 1.1) Records of commitment reviews (SP 1.2) Records of project risk monitoring (SP 1.3) Records of data management (SP 1.4) Records of stakeholder involvement (SP 1.5) Documented project review results (SP 1.6) Documented milestone review results (SP 1.7) SG 2 - Manage Corrective Action to Closure

SP 2.1 - Analyze Issues 2.1.1- Gather issues for analysis. 2.1.2- Analyze issues to determine need for corrective action.

SP 2.2 - Take Corrective Action 2.2.1- Determine and document the appropriate actions needed to address the identified issues. 2.2.2- Review and get agreement with relevant stakeholders on the actions to be taken. 2.2.3- Negotiate changes to internal and external commitments.

SP 2.3 - Manage Corrective Action 2.3.1- Monitor corrective actions for their completion. 2.3.2- Analyze results of corrective actions to determine the effectiveness of the corrective actions. 2.3.3- Determine and document appropriate actions to correct deviations from planned results from performing corrective actions.

Productos de trabajo típicos

List of issues requiring corrective actions (SP 2.1) Corrective action plans (SP 2.2) Corrective action results (SP 2.3)

Salidas de mercancías - mySAP SCM

2010-02-05T13:39:00.000-08:00

Utilizando este componente, se puede contabilizar una toma de material, una salida de materiales o un envío de mercancías a un cliente (sin intervención del componente Expedición de SD). Una salida de mercancías comporta una reducción del stock en almacén.

El sistema de Gestión de stocks soporta las clases siguientes de salidas de mercancías:

Toma de material para órdenes de fabricación - Desguace y toma de material para muestreo - Devoluciones al proveedor - Otras clases de puesta a disposición interna del material - Entregas a proveedores sin intervención del componente Expedición de SD

Salida de mercancías sin referencia

Si no existe ningún documento de referencia, porque no se ha planificado la salida de mercancías (por ejemplo, en caso de solicitud urgente de un material), se introduce la salida de mercancías sin referencia. Si desea dar salida a los componentes de una lista de materiales, puede indicar la lista de materiales.

Respecto de la salida de mercancías, se espera efectuar una entrega a tiempo que cumpla con los plazos establecidos para evitar entregas posteriores. Esto puede generar una actualización en la planificación de materiales. Este tipo de información sirve de referencia para la evaluación de los proveedores y las futuras toma de decisiones.

Overview sobre CMMI SVC V1.2 (1)

2010-01-01T08:41:00.001-08:00

El modelo Capability Maturity Model Integration for Services (CMMi – SRV) tiene el propósito de suministrar prácticas efectivas que contribuyen al performance, satisfacción del cliente y confiabilidad de la comunidad económica.

CMMi for Service tiene 24 áreas de proceso que abarcan las áreas de proceso de administración de proyecto, administración del proceso y soporte. Existen 6 áreas de procesos que tratan las prácticas de servicios, las cuales son: (1) Service Continuity, (2) Services Delivery, (3) Service System Development, (4) Services System Transition y (5) Strategic Service Management.

Todas las prácticas de las áreas de proceso incluyen actividades con el proveedor. Estas actividades son: (1) Determinación del proveedor, (2) Desarrollo del acuerdo del proveedor, (3) Administración de las soluciones adquiridas (productos o servicios)

Los Componentes del Modelo CMMi son: (1) Areas de Proceso, (2) Enunciado del propósito, (3) Nota Introductoria, (4) Areas de Proceso relacionadas, (5) Objetivos Específicos, (6) Objetivos Genéricos, (7) Objetivo Genérico y el Resumen de la Práctica, (8) Prácticas Específicas, (9) Productos de Trabajo Típicos, (10) Subprácticas, (11) Prácticas Genéricas y (12) Elaboraciones de la Práctica Genérica.

El Area de Proceso es un grupo de prácticas relacionadas que cuando son implementadas logran satisfacer un conjunto de objetivos para el mejoramiento del área de proceso.

Las 24 áreas de procesos son: (1) Service Continuity (SC), (2) Services Delivery (SD), (3) Service System Development (SSD), (4) Services System Transition (SST), (5) Strategic Service Management (SSM), (6) Causal Analysis and Resolution (CAR) (7) Configuration Management (CM), (8) Decision Analysis and Resolution (DAR), (9) Integrated Project Management (IPM), (10) Measurement and Analysis (MA), (11) Organizational Innovation and Deployment (OID), (12) Organizational Process Definition (OPD), (13) Organizational Process Focus (OPF), (14) Organizational Process Performance (OPP), (15) Organizational Training (OT), (16) Project Monitoring and Control (PMC), (17) Project Planning (PP), (18) Process and Product Quality Assurance (PPQA), (19) Quantitative Project Management (QPM), (20) Requirements Management (REQM), (21) Risk Management (RSKM), (22) Incident Resolution and Prevention (IRP), (23) Supplier Agreement Management (SAM) y (24) Capacity and Availability Management (CAM)

El Enunciado del Proceso describe el propósito del área de proceso y es un componente informativo. La Nota Introductoria de un área de proceso describe los principales conceptos que abarca el área de proceso y es un componente informativo. Las Areas de Proceso relacionadas enumeran las referencias respecto de áreas de proceso relacionadas y establece las relaciones entre las áreas de proceso. Esta es una sección informativa.

Los Objetivos Específicos describen las características únicas que deben satisfacer las áreas de proceso. Un objetivo específico es un componente del modelo requerido y es usado para determinar si un área de proceso está satisfecho. El enunciado del objetivo específico es sólo componente requerido del modelo.

Los Objetivos Genéricos son llamados “Genéricos” debido a que el mismo enunciado del objetivo se aplica a distintas áreas de proceso. Un objetivo genérico describe las características que se deben presentar para institucionalizar los procesos que implementa un área de proceso. Este objetivo es componente del modelo requerido y es utilizado para determinar si un área de proceso está satisfecha. El enunciado del objetivo genérico es sólo componente requerido del modelo. El título de un objetivo genérico y algunas notas asociadas al objetivo son considerados componentes informativos del modelo.

Los objetivos genéricos son componentes del modelo requerido que se aplican a todas las áreas de proceso. Todos los objetivos genéricos y prácticas genéricas son usadas en la representación continua.

El Objetivo Genérico y el Resumen de la Práctica suministran un resumen general de los objetivos específicos, los cuales son requeridos como componentes, y de las prácticas específicas, las cuales son componentes esperados. Ambos son componentes informativos.

Las Prácticas Específicas describen las actividades que resultan del logro de los objetivos específicos de un área de proceso. Una práctica específica consiste en la descripción de una actividad que es considerada importante para alcanzar el objetivo específico asociado. Una práctica específica es un componente esperado del modelo. El enunciado de la práctica específica es sólo componente esperado del modelo. El título de una práctica específica y algunas notas asociadas a la práctica específica son considerados componentes informativos del modelo.

Los Productos de Trabajo Típicos enumeran las salidas o resultados de una práctica específica. El producto de trabajo típico es un componente informativo del modelo. Una Subpráctica es una descripción detallada que suministra una guía para interpretar e implementar una práctica genérica o específica. Las subprácticas son un componente informativo que provee ideas que pueden ser útiles para el mejoramiento de procesos.

Las Prácticas Genéricas son llamadas “genéricas” debido a que la misma práctica se aplica a varias áreas de proceso. Una práctica genérica es la descripción de una actividad que importante para alcanzar el objetivo genérico asociado. Una práctica genérica es un componente esperado del modelo. El enunciado de la práctica genérica es sólo componente esperado del modelo. El título de una práctica genérica y algunas notas asociadas a la práctica son considerados componentes informativos del modelo.

La Elaboración de una Práctica Genérica aparece después de la práctica genérica en un área de proceso para suministrar una guía de cómo la práctica genérica sería aplicada al área de proceso. Esta elaboración de una práctica genérica es un componente informativo del modelo.

Este modelo tiene AP (áreas de proceso) en donde los Objetivos Genéricos (GG) y las Prácticas Genéricas (GP) aparecen al final de cada AP. Los Objetivos Genéricos involucran que cada objetivo suministra un fundamento para el próximo. Por lo tanto, se realizan las siguientes conclusiones: 1- Un proceso administrado es un proceso realizado. 2- Un proceso definido es un proceso administrado. 3- Un proceso administrado cuantitativamente es un proceso definido. 4- Un proceso optimizado es un proceso administrado cuantitativamente.

GG1 – Perfomed process GG2 – Managed process GG3 – Defined process GG4 – Quantitatively managed process GG5 – Optimizing process

Lograr GG1 en un AP es equivalente a decir que se lograron los objetivos específico del AP. Lograr GG2 en un AP es equivalente a decir que se administra el performance de los procesos asociados a un AP. Lograr GG3 en un AP implica que existe un proceso estándar organizacional que puede ser desarrollado a medida y que surge del uso del proceso. Lograr GG4 o GG5 en un AP es factible pero puede no ser económico, en situaciones donde el AP es un negocio crítico. Cada Objetivo Genérico (GG) está formado por Prácticas Genéricas (GP) y subprácticas asociadas.

GG 1 – Archive Specific Goals GP 1.1 Perform Specific Practices GG 2 - Institutionalize a Managed Process GP 2.1 - Establish an Organizational Policy GP 2.2 – Plan the Process GP 2.3 – Provide Resources GP 2.4 – Assign Responsibility GP 2.5 – Train People GP 2.6 - Manage Configurations GP 2.7 – Identify and Involve Relevant Stakeholders GP 2.8 – Monitor and Control the Process GP 2.9 – Objectively Evaluate Adherence GP 2.10 - Review Status with Higher Level Management GG 3 - Institutionalize a Defined Process GP 3.1 – Establish a Defined Process GP 3.2 – Collect Improvement Information GG4 - Institutionalize a Quantitatively Managed Process GP 4.1 – Establish Quantitative Objectives for the Process GP 4.2 – Stabilize Subprocess Performance GG5 - Institutionalize a Optimizing Process GP 5.1 – Ensure Continuous Process Improvement GP 5.2 – Correct Root Causes of Problems

Los Niveles de CMMi son usados para describir la evolución de una organización que desea mejorar los procesos; y desarrollar y mantener sus productos y servicios. CMMi considera 2 alternativas de mejoramiento: 1- Las organizaciones mejoran sus procesos según el área o áreas de proceso seleccionadas por la organización. 2- Las organizaciones mejoran un conjunto de procesos relacionados por medio del manejo de un conjunto de áreas de procesos.

Estas 2 alternativas están asociadas a 2 tipos de niveles que se corresponden con las siguientes representaciones: 1- Representación Continua: se usa el término “Nivel de Capacidad” 2- Representación por Etapas: se usa el término “Nivel de Madurez”

Para lograr un Nivel, la organización debe satisfacer todos los objetivos del área de proceso o del conjunto de áreas de procesos. Ambas representaciones tienen formas de implementar el mejoramiento de procesos para alcanzar los objetivos del negocio. Estas representaciones tienen el mismo contenido esencial y el mismo modelo de componentes. Ambas representaciones tienen los mismos componentes (p.e: áreas de proceso, objetivos específicos y prácticas específicas) y estos componentes tienen la misma jerarquía y configuración. Este modelo permite proponer el mejoramiento de procesos y valoraciones usando 2 tipos de enfoques: (1) Continuo y (2) Por Etapa.

El Enfoque Continuo permite que una organización pueda seleccionar un área de proceso o grupo de áreas de procesos y mejorar los procesos. Este enfoque utiliza los niveles de capacidad para caracterizar el mejoramiento relacionado a un área de proceso. Este enfoque permite que una organización pueda mejorar diferentes procesos por distintas razones y entender las dependencias entre las áreas de proceso.

El Enfoque por Etapa utiliza conjuntos de áreas de proceso predefinidas para definir un mejoramiento en la organización. Este mejoramiento está caracterizado por los niveles de madurez. Cada nivel de madurez suministra un conjunto de áreas de proceso que caracterizan distintos comportamientos de la organización. Este enfoque suministra, por etapa, una manera sistémica y estructurada para proponer el mejoramiento del proceso basado en el modelo. El logro de cada etapa asegura una infraestructura de proceso adecuada y sirve de fundamento para la próxima etapa. Este enfoque prescribe un orden para la implementación de las áreas de proceso de acuerdo a los niveles de madurez. El logro de cada nivel de madurez asegura un mejoramiento y sirve de fundamento para el próximo nivel de madurez.

Representación Continua

Esta representación tiene un enfoque basado en la capacidad del área de proceso y es medida por medio de los niveles de capacidad numerados de 0 a 5. El Nivel de Capacidad consiste de un objetivo genérico y sus prácticas genéricas relacionadas, las cuales están relacionadas a un área de proceso y permiten mejorar los procesos de la organización asociados a esa área de proceso. Esta representación permite que la organización seleccione las áreas de proceso o conjunto de áreas de proceso interrelacionadas que más pueden beneficiar a la organización y a sus objetivos de negocio. En esta representación las áreas de proceso están organizadas en categorías.

Las 4 Categorías de las Areas de Proceso de CMMI son: (1) Process Management, (2) Project Management, (3) Service Establishment and Delivery y (4) Support.

Categoría 1: ‘PROCESS MANAGEMENT’ Esta categoría abarca las actividades relacionadas con la definición, planificación, asignación de recursos, implementación, monitoreo, control, medición y mejora de procesos. Las AP de “Process Management” son: OPF, OPD, OT, OPP y OID.

Categoría 2: ‘PROJECT MANAGEMENT’ Esta categoría abarca las actividades relacionadas con planificación, monitoreo y control del proyecto. Las AP de “Project Management” son: PP, PMC, REQM, IPM, RSKM, QPM, CAM, SAM y SC.

Categoría 3: ‘SERVICE ESTABLISHMENT AND DELIVERY’ Esta categoría abarca las actividades relacionadas a los servicios. Las AP de ‘Service’ son: IRP, SD, SSD, SST y SSM.

Categoría 4: ‘SUPPORT’ Esta categoría abarca los procesos que son usados en el contexto de realización de otros procesos. Las AP de ‘Support’ son: CM, PPQA, MA, DAR y CAR.

Una vez que las áreas de procesos fueron elegidas, se debe seleccionar el nivel de capacidad. Los niveles de capacidad y las prácticas y objetivos genéricos soportan el mejoramiento de los procesos asociados a las áreas de proceso en particular.

Los Niveles de Capacidad permiten mejorar los procesos de una determinada área de proceso. Los Niveles de Capacidad son: (0) Incomplete, (1) Performed, (2) Managed, (3) Defined, (4) Quantitatively Manager y (5) Optimizing.

Los Niveles de Capacidad 2 a 5 usan los mismos términos y objetivos genéricos (GG2 a GG5) debido a que cada uno de estos objetivos genéricos y prácticas genéricas reflejan el significado de los Niveles de Capacidad en términos de objetivos y prácticas que se pueden implementar.

Nivel de Capacidad 0 – Incomplete

Un proceso Incompleto es aquel que fue efectuado parcialmente o no realizado. Uno o más objetivos específicos de un área de procesos no son satisfechos y los objetivos genéricos no existen en este nivel, ya que no hay una razón para institucionalizar un proceso realizado de manera parcial.

Nivel de Capacidad 1 – Performed

Un proceso de nivel de capacidad 1 está caracterizado como un “Performed process”, el cual consiste de un proceso que satisface los objetivos específicos del área de proceso. Este proceso soporta y permite hacer el trabajo necesario para producir los productos de trabajo. La aplicación de la institucionalización ayuda asegurar el mantenimiento de las mejoras realizadas.

Nivel de Capacidad 2 – Managed

Un proceso de nivel de capacidad 2 está caracterizado como un “Managed process”, el cual consiste de un proceso realizado (Nivel de Capacidad 1) que tiene una infraestructura básica que soporta el proceso. Es un proceso planificado y ejecutado de acuerdo con la política de la empresa, llevado a cabo por gente que controla los resultados obtenidos, es monitoreado, controlado y revisado; y es evaluado de acuerdo a la descripción del proceso.

Nivel de Capacidad 3 – Defined

Un proceso de nivel de capacidad 3 está caracterizado como un “Defined process”, el cual consiste en un proceso administrado (Nivel de Capacidad 2) que está basado en un conjunto de procesos estándares de la organización que considera las pautas de la organización. Una diferencia entre el nivel de capacidad 2 y 3 es el alcance de los estándares, descripciones del proceso y procedimientos. En el nivel de capacidad 2, los estándares, descripciones del proceso y procedimientos pueden ser bastante distintos en cada instancia específica del proceso. En el nivel de capacidad 3, los estándares, descripciones del proceso y procedimientos de un proyecto están de acuerdo al conjunto de procesos estándares de la organización.

En un proceso definido, se determina lo siguiente: (1) Propósito, (2) Datos de Entrada, (3) Criterios de entrada, (4) Actividades, (5) Roles, (6) Mediciones, (7) Pasos de la Verificación, (8) Salidas y (9) Criterio de éxito. En este nivel, los procesos son administrados usando un entendimiento de las interrelaciones de las actividades del proceso y mediciones detalladas del proceso, sus productos de trabajo y servicios.

Nivel de Capacidad 4 - Quantitatively Managed

Un proceso de nivel de capacidad 4 está caracterizado como un “Quantitatively Managed process”, el cual consiste de un proceso definido (Nivel de Capacidad 3) que es controlado usando la estadística y otras técnicas cuantitativas. Los objetivos cuantitativos de calidad y el performance del proceso son establecidos y utilizados como criterio para la administración del proceso. La calidad y el performance del proceso son entendidos en términos estadísticos y son administrados durante toda la vida del proceso.

Nivel de Capacidad 5 - Optimizing

Un proceso de nivel de capacidad 5 está caracterizado como un “Optimizing process”, el cual consiste de un proceso administrado cuantitativamente (Nivel de Capacidad 4) que es mejorado en base a las causas de variación del proceso. El proceso de optimización consiste en mejorar continuamente el rango de performance del proceso.

Los Niveles de Capacidad 2 a 5 usan los mismos términos y los mismos Objetivos Genéricos (2 a 5). Los Niveles de Capacidad de un área de proceso son alcanzados a través de la aplicación de prácticas genéricas o alternativas de los procesos asociadas a un área de proceso.

Representación Por Etapas

Esta representación tiene un enfoque basado en la madurez de la organización y es medida por medio de los niveles de madurez numerados del 1 al 5. Un Nivel de Madurez consiste de prácticas específicas y genéricas relacionadas a un conjunto de áreas de procesos predefinido que mejora el performance de la organización. Este Nivel de Madurez permite pronosticar el performance de la organización respecto de una disciplina dada o de un conjunto de disciplinas.

Los Niveles de Madurez son medidos por medio del logro de objetivos genéricos y específicos asociados a cada conjunto predefinido de áreas de procesos Los Niveles de Madurez se aplican al mejoramiento de procesos de la organización teniendo en cuenta varias áreas de proceso. Los Niveles de Madurez son: (1) Initial, (2) Managed, (3) Defined, (4) Quantitatively Managed y (5) Optimizing.

En esta representación, las áreas de procesos son organizadas en niveles de madurez y se indica qué áreas de proceso implementar para lograr cada nivel de madurez. Los Objetivos Genéricos que se aplican a cada área de proceso están predeterminados. El Objetivo Genérico (GG2) se aplica al Nivel de Madurez 2 y el Objetivo Genérico 3 (GG3) se aplica a los Niveles de Madurez 3, 4 y 5. En esta representación solamente se usan GG2 y GG3.

Para alcanzar el nivel de madurez 2, todas las áreas de proceso asignadas al nivel de madurez 2 deben lograr el nivel de capacidad 2 o más. Para alcanzar el nivel de madurez 3, todas las áreas de proceso asignadas a los niveles de madurez 2 y 3 deben lograr el nivel de capacidad 3 o más. Para alcanzar el nivel de madurez 4, todas las áreas de proceso asignadas a los niveles de madurez 2, 3 y 4 deben lograr el nivel de capacidad 3 o más. Para alcanzar el nivel de madurez 5, todas las áreas de proceso deben lograr el nivel de capacidad 3 o más.

Nivel de Madurez 1 – Initial

En este nivel de madurez, los procesos son ad hoc. La organización no tiene un ambiente estable que soporte los procesos. El éxito en estas organizaciones depende de la competencia de la gente y no del uso de procesos. Este nivel de madurez produce servicios y productos que exceden el presupuesto y no cumplen con lo requerido. Las organizaciones de nivel de madurez 1 están caracterizadas por el abandono de procesos en momentos de crisis y por una incapacidad de repetir éxitos anteriores.

Nivel de Madurez 2 – Managed

En este nivel de madurez, los proyectos de la organización tienen asegurado que los procesos están planeados y ejecutados de acuerdo a la política de la empresa, que los proyectos tienen la gente necesaria para efectuar los controles de los resultados obtenidos, y para que los procesos sean monitoreados, controlados y revisados. En el nivel de madurez 2, el estado de los productos de trabajo y el suministro de servicios son puntos definidos a tener en cuenta durante la administración. Los productos de trabajo son controlados. Los productos de trabajo y los servicios satisfacen las descripciones específicas del proceso, estándares y procedimientos.

Las áreas del Proceso del Nivel 2 son: IRP, CM, MA, PMC, PP, PPQA, REQM, SAM y SD

Nivel de Madurez 3 – Defined

En el nivel de madurez 3, los procesos están caracterizados y entendidos, y están descriptos en estándares, procedimientos, herramientas, técnicas y métodos. El conjunto de procesos estándares de la organización, los cuales son base del nivel de madurez 3, es establecido y mejorado en todo momento. Estos procesos estándares son usados para establecer consistencia en los proyectos de la organización.

En este nivel 3, los procesos son administrados usando un entendimiento de las interrelaciones de las actividades del proceso y medidas detalladas del proceso, sus productos de trabajo y servicios. Los procesos son determinados de manera cualitativa.

Una distinción entre los niveles de madurez 2 y 3 es el alcance de los estándares, descripciones del proceso, y procedimientos. En el nivel de madurez 2, los estándares, descripciones del proceso y los procedimientos puede ser distintos para cada instancia específica del proceso. En el nivel de madurez 3, los estándares, descripciones del proceso y los procedimientos para un proyecto son a medida.

En el nivel de madurez 3, los procesos son más descriptos que en el nivel de madurez 2. Un proceso definido define propósito, entradas, criterio de entrada, actividades, roles, mediciones, pasos de verificación, salidas y criterio de salida. En el nivel de madurez 3, los procesos son administrados usando las interrelaciones de las actividades del proceso y las mediciones detalladas del proceso, sus productos de trabajo y sus servicios. Los Objetivos Genéricos de GG3 se aplican a cada área de Proceso del Nivel 4.

Las áreas del Proceso del Nivel 3 son: CAM,IPM,SC,SSD,DAR,SST,OPD,OPF,OT,RSKM y SSM.

Nivel de Madurez 4 - Quantitatively Managed

En el nivel de madurez 4, la organización y los proyectos establecen objetivos cuantitativos de calidad y performance del proceso; y lo usan como criterio para la administración de procesos. Los objetivos cuantitativos están basados en las necesidades del cliente, usuarios finales, organización e implementadores del proceso. La calidad y el performance del proceso son entendidos en términos estadísticos y son administrados durante la vida de los procesos.

Para los subprocesos seleccionados, se recopilan las mediciones detallas del performance del proceso y son analizadas de manera estadística. Las mediciones de calidad y de performance del proceso son incorporadas al repositorio de medición de la organización que se utiliza en la toma de decisiones. Las causas especiales de variación son identificadas y las fuentes de las causas especiales son corregidas para prevenir futuras ocurrencias. En este nivel 4, el performance de los procesos es controlado usando la estadística y otras técnicas cuantitativas.

Una distinción entre los niveles de madurez 3 y 4 es el poder predecir el performance del proceso. En el nivel de madurez 4, el performance de los procesos es controlado usando técnicas estadísticas y se puede predecir de manera cuantitativa. En el nivel de madurez 3, los procesos se pueden predecir solo de manera cualitativa.

Los Objetivos Genéricos de GG4 se aplican a cada área de Proceso del Nivel 4. Las áreas del Proceso del Nivel 4 son: OPP y QPM.

Nivel de Madurez 5 - Optimizing

En el nivel de madurez 5, una organización mejora continuamente sus procesos basados en un entendimiento cuantitativo de las causas de variación de los procesos. Este nivel de madurez encara un mejoramiento continuo del performance del proceso a través de un proceso innovativo y de mejoras técnicas. Los objetivos del mejoramiento del proceso cuantitativo son establecidos, revisados respecto de los objetivos de negocio y usados como criterio en el mejoramiento de procesos.

En este nivel de madurez, la organización mejora continuamente sus procesos basados en un entendimiento cuantitativo de las causas de variación de los procesos. El nivel de madurez 5 está enfocado respecto del proceso de mejoramiento continuo a través de nuevos mejoramientos técnicos. Los objetivos de mejoramiento cuantitativo de los procesos son establecidos y revisados de manera continua según los objetivos de negocio de la organización. Estos objetivos de mejoramiento son utilizados como criterio en el manejo de mejoramiento de procesos.

Una distinción clara entre los niveles de madurez 4 y 5 es el tipo de variación del proceso. En el nivel de madurez 4, la organización se ocupa de causas de la variación del proceso y suministra una predicción estadística de los resultados. Aunque los procesos pueden producir resultados predecibles, los resultados pueden ser insuficientes para el logro de los objetivos establecidos. En el nivel de madurez 5, la organización se ocupa de las causas de la variación del proceso y del cambio de los procesos para mejorar el performance del proceso y lograr los objetivos cuantitativos de mejora de procesos.

Los Objetivos Genéricos GG5 se aplican a cada área de Proceso del Nivel 5. Las áreas del Proceso del Nivel 5 son: CAR y OID

De esta forma, la empresa deberá tomar la decisión acerca de qué representación implementar para el logro de sus objetivos. Dicha implementación implica un estudio preliminar acerca de las ventajas y desventajas de implementar este modelo, teniendo en cuenta tiempos, costos y recursos necesarios.

Otras entradas de mercancias - mySAP SCM

2010-01-01T08:40:00.001-08:00

Además de las entradas de mercancías descritas previamente, pueden introducirse entradas de mercancías sin hacer referencia a otro documento. Estas entradas de mercancías se introducen seleccionando Movimiento de mercancías / Entrada de mercancías / Otros.

Se pueden ingresar los siguientes tipos de entradas de mercancías:

• Entrada inicial de stocks: Mediante este movimiento de mercancías, puede transferir los stocks teóricos desde un sistema existente hasta el Sistema R/3 la primera vez que implemente el componente Gestión de stocks.

• Entradas de mercancías externas sin pedido: Si su empresa no utiliza el componente Compras de MM, una entrada externa se introduce como una entrada de mercancías varias. Podrá planificar un movimiento de este tipo con una reserva.

• Entradas de mercancías internas sin orden de fabricación: Si su empresa no utiliza el componente Órdenes de fabricación de PP, una entrada desde producción se introduce como una entrada de (otras) mercancías varias. Podrá planificar un movimiento de este tipo con una reserva.

• Entradas de mercancías de subproductos: Las entradas de mercancías de subproductos pueden introducirse también como entradas de mercancías varias

• Entregas gratuitas: Si se recibe una entrega gratuita de un proveedor para la que no realizó ningún pedido, deberá introducir la entrada de mercancías como entrada de (otras) mercancías varias.

• Devoluciones del cliente: Incluso sin entrega de devoluciones, es posible contabilizar devoluciones de un cliente en el stock bloqueado de devoluciones.

El ingreso de mercaderías implica un control de la calidad de los materiales recibidos, un control del tiempo de entrega establecido, una evaluación del servicio de los proveedores y un análisis de datos referentes a situaciones ya planteadas (por ejemplo, entregas atrasadas realizadas por un determinado proveedor).

Notas de Crédito - mySAP SCM

2009-12-04T10:18:00.000-08:00

Cuando se reduce una factura, el sistema crea una factura y una nota de crédito (NC) simultáneamente. El monto del ítem ingresado en la factura es distribuido, ya que el sistema sol contabiliza el monto mostrado en la cuenta GR/IR clearing. La creación de una NC limpia la cuenta clearing.

Cuando se contabiliza la NC, la cantidad total facturada en la historia de la orden de compra (OC) es reducida por medio de la cantidad de la OC. La cantidad máxima del crédito es la cantidad que a sido facturada. En una recepción de bienes )GR), el sistema asume que una NC es reversa de la GR. Esto significa que la NC es liquidada usando la cuenta GR/IR clearing.

Los movimientos de cuenta realizados cuando se contabiliza una NC son realizados de acuerdo a las reglas utilizadas para contabilizar una factura. El sistema contabiliza en las mismas cuentas, pero con signo contrario. Los documentos de factura pueden ser cancelados si fueron contabilizados de manera incorrecta. Existen 2 casos: (1) Cancelar la factura (el sistema genera automática mente una NC) y (2) Cancelar la NC (el sistema genera automáticamente la factura).

Cuando se crea una reversa de la factura, el sistema crea una NC basada en los datos del documento de factura. El sistema determina automáticamente la cantidad y el monto de la NC a partir de la factura. Para revertir parte de una factura, se debe ingresar una NC manualmente. No se puede revertir un documento revertido.

CSI - ITIL V3

2009-12-04T10:15:00.000-08:00

Las Metas de CSI son alinear y re-alinear continuamente los servicios de TI a las necesidades cambiantes del Negocio identificando e implementando mejoras a los servicios de TI que soportan los procesos de Negocios.

CSI significa buscar la manera de mejorar:

Efectividad de los procesos, Eficiencia y Efectividad respecto a los costos

Es importante entender que es lo que se debe medir, por qué se está midiendo y definir los resultados deseados contra los cuales comparar las mediciones realizadas.

Los Objetivos de CSI son:

- Revisar, analizar y hacer recomendaciones sobre oportunidades de mejora en cada una de las fases del ciclo de vida: Service Strategy, Service Design, Service Transition y Service Operations.

- Revisar y analizar los resultados y logros de los niveles de servicio. - Identificar e implementar actividades específicas para mejorar la calidad de los servicios de TI.

- Mejorar la efectividad respecto a los costos.

- Utilizar métodos de Gestión de la calidad aplicables para soportar las actividades de mejora continua.

El “Valor para el Negocio” permite:

- Incrementar las competencias de la Organización

- Integración entre las personas y los procesos

- Reducción de la redundancia incrementa el rendimiento del Negocio

- Minimizar la pérdida de oportunidades

- Asegurar el cumplimiento de regulaciones, lo que minimiza los costos y reduce los riesgos

- Reaccionar rápidamente ante los cambios

Rol de la Gobernabilidad de TI (IT Governance) a lo largo de todo el Ciclo de Vida de los Servicios

Las organizaciones internas de TI deben transformarse en proveedores de servicios de TI efectivos y eficientes o dejarán de ser relevantes para el negocio. Este objetivo continuo e incesante respecto a generar cada vez más valor para el negocio con una mayor eficiencia interna está en el corazón de CSI.

Gobernabilidad Empresarial (Enterprise governance) Considera el panorama completo, ya que asegura que las metas estratégicas estén alineadas y se alcance una Gestión correcta.

Gobernabilidad Corporativa (Corporate governance) Promueve equidad, transparencia y a contabilidad a nivel corporativo.

Gobernabilidad de TI (IT governance) Responsabilidad de la Junta Directiva y Alta Gerencia. “Parte integral de la Gobernabilidad Empresarial que consiste de liderazgo, estructuras organizacionales y procesos que aseguran que las organizaciones de TI soporten y extiendan las estrategias y objetivos de la Organización”

Modelos de Gobernabilidad

– Basilea II: Gobernabilidad para el sector financiero – SOX (Sarbanes Oxley): Gobernabilidad Corporativa (USA) – CLERP 9: Gobernabilidad Corporativa (Australia) – King Report: Gobernabilidad Corporativa (South Africa) Modelo PDCA

Las cuatro etapas del ciclo de Deming son: 'Plan, Do, Check, Act' luego de las cuales una etapa de consolidación previene que el circulo tenga retrocesos. La meta de CSI usando el ciclo de Deming es la mejora continua.

El ciclo es soportado por un enfoque orientado por procesos para gestionar que los procesos estén definidos y se estén usando, que las actividades estén siendo medidas para cumplir con los valores esperados, y que los resultados de las mismas estén siendo auditados para validar y proponer mejoras al proceso.

Planificación de Iniciativas de Mejora (Plan: Establece los objetivos de mejora (Gap analysis)

Implementación de la Iniciativa de Mejora (Do): Desarrollo e implementación del proyecto

Gestión de Procesos (Check): Compara las mejoras implementadas contra las medidas que establecen el éxito

Mejoras (Act): Implementación de las mejoras a los servicios y Procesos de Gestión de los Servicios Actuales

Modelo CSI

Resumen de los 6 pasos

1- Adoptar una Visión: Alineación entre las estrategias del Negocio y TI

2- Evaluar la situación actual (foto del lugar donde se encuentra la organización en estos momentos): Negocio, Organización, Gente, Procesos, y Tecnología

3- Entender y acordar las prioridades respecto a las mejoras: Metas específicas y plazo manejable

4- Detallar plan de CSI para alcanzar una calidad superior: Desarrollar e implementar procesos de ITSM

5- Verificar que las mediciones y métricas se encuentren en su sitio: Asegurar los logros y el cumplimiento

6- Asegurar que el “momentum” para mejoras de calidad se mantenga: Incorporar los Cambios (y la cultura)

Líneas base

Un punto importante de comienzo para destacar las mejoras es el establecer una línea base como referencia para comparaciones futuras. Las líneas base también se utilizan para establecer un punto inicial de referencia para determinar si un servicio o proceso necesita ser mejorado. Se debe establecer a cada nivel: Metas y Objetivos estratégicos, Madurez táctica de los procesos, Métricas operacionales, y KPIs. Si no se establecieron al comienzo, la primera medición de esfuerzos se transforma en la línea base.

Métricas

Existen tres tipos de métricas para CSI:

• Métricas de las tecnologías: Basadas en los componentes y las aplicaciones (performance, disponibilidad, etc.) • Métricas de los Procesos: KPI’s y actividades (salud de los procesos) • Métricas de los Servicios

KPIs dan respuesta sobre calidad, performance, valor y cumplimiento de seguir los procesos

CSI puede usar esas métricas como dato de entrada para identificar oportunidades de mejora para cada proceso.

TM y APM en ITIL V3

2009-11-01T08:19:00.000-08:00

Gestión Técnica (Technical Management)

Rol del Technical Management

- Custodio del conocimiento técnico y experiencia: Provee recursos actuales para soportar el Ciclo de Vida de la Gestión de los Servicios - Garantiza el balance entre el nivel de habilidades, utilización y costo: Provee una guía para Operaciones sobre cómo llevar adelante las operaciones de tecnología de la mejor forma posible

Objetivos del Technical Management

Asistir en la planificación, implementación y mantenimiento de infraestructuras estables mediante: Topologías técnicas bien diseñadas, Uso de las habilidades técnicas adecuadas y Uso de las habilidades técnicas en forma eficiente y rápida

Gestión de la Aplicación

Rol del Application Management

Objetivos del Application Management

- Ayuda a identificar requerimientos funcionales y de gestión, asiste en el diseño e implementación, y en el soporte continuo y mejoras en las aplicaciones a través de: - Un buen diseño, efectividad en los costos y resilencia - Disponibilidad de la funcionalidad requerida - Uso de las habilidades técnicas adecuadas - Uso de las habilidades técnicas en forma eficiente y rápida

Bloqueo de facturas - mySAP SCM

2009-11-01T08:17:00.000-08:00

Cuando se ingresa una factura, el sistema propone valores específicos que provienen de los acuerdos de compras o de la GR (recepción de bienes). Si un ítem de la factura varía respecto de los valores default del sistema, entonces se debe intentar encontrar la causa de la varianza. Se pueden asignar los límites de tolerancia para cada tipo de varianza. Si se acepta una varianza, el sistema controla que esté dentro de los límites de tolerancia. Si no está d entro de los límites, el sistema emite un mensaje. Se puede contabilizar la factura, pero no es bloqueada para el pago. Si el límite de tolerancia es excedido, el sistema emite un mensaje. Se puede contabilizar la factura, pero es automáticamente bloqueada para el pago.

El bloqueo de la factura se aplica a todos los ítems de una factura. Si un único ítem de la factura muestra una factura, toda la factura es bloqueada. Una factura bloqueada se libera en un paso aparte antes que pueda ser pagada. Las razones de bloqueo de una factura pueden ser: (1) varianza en la cantidad, (2) varianza en el precio, (3) varianza de la cantidad y precio de la OC y (4) varianza de la fecha. Las tolerancias de estas varianzas se definen en el Customizing. Para cada límite de tolerancia, se debe decidir si el sistema controla la varianza. Si uno de los límites es excedido, la factura es bloqueada.

Una factura recibida después de la GR implica un control de precio promedio variable y recio estándar. Una factura recibida antes de la GR implica que el sistema contabiliza la varianza del precio en la cuenta GR/IR clearing. En las facturas con / sin referencia a una OC se deben mantener distintos límites de tolerancia.

Una factura bloqueada debe ser liberada para e pago en un paso separado. Esta liberación puede ser manual o automática. En la liberación automática, el sistema controla cada razón de bloqueo para ver si son válidas. En l liberación manual, se muestra una lista de facturas bloqueadas. Cuando se libera una factura, se puede cambiar la fecha de pago.

AM y SD en ITIL V3

2009-10-02T10:07:00.000-07:00

Access Management (AM)

Los objetivos de AM son: - Proveer permisos a los usuarios para permitir el uso de un servicio o grupo de servicios - Habilita la ejecución de políticas y acciones

Se plantean los siguientes conceptos básicos:

Acceso: Nivel y alcance de la funcionalidad o datos que el usuario puede utilizar. Identidad: Información distintiva única de cada individuo. Derechos: Conjunto actual de permisos de acceso (privilegios). Servicios de Grupos de Servicio: Acceso a un conjunto de servicios o grupo de usuarios, sin acceso individual a servicios particulares. Servicios de Directorio (Directory Services): Herramienta para administrar accesos y derechos.

Rol en Access Management

Service Desk

- Solicita acceso a los servicios - Actúa como un primer filtro - Chequea la validez - Ejecuta actividades simples, escala otras

Technical & Applications Management

- Service Design: garantiza que se incluyen tareas relacionadas con la gestión de accesos a lo largo del ciclo de vida de los servicios. - Service Transition: testea los controles diseñados. - Service Operations: administra el acceso a los sistemas dentro de su área de control y trabaja con los incidentes y problemas relacionados con los accesos. - IT Operations Management: asegura que se utilicen procedimientos de Operaciones estándar (SOPs, Standard Operations Procedures).

Gestión del Service Desk

Rol del Service Desk (SD)

- Es una unidad funcional que actúa como punto único de contacto (SPOC, Single Point of Contact) para la interacción entre los usuarios de TI y los servicios en el trato diario. - Aumenta la Accesibilidad (SPOC para los usuarios); y Calidad y tiempo de respuesta para los requerimientos - Mejora servicio, percepción y satisfacción del cliente; y Trabajo en equipo y comunicaciones - Reduce los impactos negativos en el Negocio - Provee información de Gestión más significativa

Los objetivos del SD son los siguientes:

- Retornar a los niveles de servicio normales a la brevedad - Registrar todos los requerimientos relevantes - Proveer el primer nivel de soporte - Resolver incidentes - Escalar - Mantener informados a los usuarios - Cerrar todos los requerimientos resueltos

Estructura Organizacional del SD

- Service Desk Local - Service Desk Centralizada - Service Desk Virtual - “Follow the Sun” Combinación de service desks en distintos puntos geográficos - Grupos Especializados o Envío de requerimientos relacionados con un servicio particular o Permite una resolución más rápida - Ambiente de Trabajo o Luz natural suficiente y gran cantidad de espacio o Control de acústica adecuado o Entorno placentero o Espacio de descanso separado

Staffing del Service Desk

- Niveles de Personal: Asegurar la cantidad correcta de personal para los niveles de demanda. - Niveles de Habilidades: Asegurar los niveles y rangos correctos de habilidades. - Capacitación: Asegurar que los conocimientos del personal sean actuales. - Retención: Pérdidas significativas pueden ser disruptivas: llevan a servicios in consistentes. - Super Usuarios: Actúan como vínculo entre TI en general y el Service Desk.

Métricas del Service Desk

- Evaluar la performance de la SD a intervalos regulares - Evaluar estado, madurez, eficiencia y eficacia - Análisis y métricas detalladas como ser: o Porcentaje de resoluciones en la primera línea de soporte o Tiempo promedio para la resolución de un incidente o Tiempo promedio para escalar un incidente o Tiempo promedio para revisar y cerrar una llamada resuelta o La cantidad de llamadas perdidas durante un período de tiempo en el día o durante la semana o Porcentaje de clientes o usuarios actualizados dentro de los tiempos preestablecidos - Encuesta de Satisfacción al Cliente

Verificación de Facturas - mySAP SCM

2009-10-02T10:03:00.001-07:00

Las transacciones MR1M / MIRO permiten realzar el ingreso de un documento (orden de compra, recepción de bienes, factura) basado en verificación de factura. La verificación de factura (VF) controla las facturas entrantes para asegurar el contenido, precio y contabilización. La VF puede procesar facturas que no tuvieron su origen en el abastecimiento de material y opera en conjunción con los componentes de compras y manejo de inventario.

Por cada factura entrante, la VF crea un documento de factura en MM y un documento de factura en FI. Estos documentos actualizan los datos en MM FI. Se puede contabilizar una factura entrante con referencia a una orden de compra (OC), servicio o recepción de bienes (GR). El sistema sugiere los ítems de la factura de acuerdo a la referencia ingresada.

La contabilización de la factura implica que la cuenta GR/IR es compensada y que la cuenta del proveedor es acreditada.

El sistema propone todos los ítems de la OC que satisfacen un criterio y que están listos para ser liquidados. Se pueden agregar varios ítems a la factura. Antes de contabilizar la factura, se pueden simular los movimientos contables realizados.

Existen 2 tipos de VF: (1) basada en la OC (MIRO) y (2) basada en la GR (MR1M). En la verificación basada en la OC, el sistema genera un ítem de factura para cada ítem de la OC y propone la cantidad a liquidar. En la verificación basada en la GR, se tiene asignado el indicador ‘GR based IV’ en la OC y no se ingresa la factura hasta que al menos se contabiliza una GR. Se crea un ítem de factura para cada entrega parcial. Durante el ingreso de la factura se establecen algunos de los siguientes datos: impuesto, condiciones de pago y/o moneda extranjera.

La categoría de imputación contable se usa para definir el tipo de imputación contable. Esta categoría controla si se puede contabilizar una GR o una recepción de factura. Se pueden contabilizar facturas que no tienen referencia a una OC / entrega. En el caso de una factura con referencia, el sistema no propone algunos valores default, debido a que no se pueden determinar algunos ítems de la OC. En el caso de factura con ítems sin referencia, el sistema no puede copiar información de la OC.

En la verificación in background, se ingresa el encabezado y detalles sin algunos ítems. La factura es verificada usando un programa específico.

RF y PM en ITIL V3

2009-09-02T15:44:00.001-07:00

Request Fulfillment (RF)

Los objetivos del RF son:

- Proporcionar un canal para solicitar y recibir Servicios estándar - Proporcionar información sobre disponibilidad y como obtener servicios - Almacena y provee componentes requeridos como servicios - Ayuda brindando información general

Los requerimientos de servicios ocurren a menudo, por lo cual se puede diseñar un flujo de proceso para incluir todas las etapas necesarias para cumplimentar el pedido.

Los requerimientos de servicio suelen satisfacerse mediante la implementación de un cambio estándar.

Rol

Los requerimientos de servicios son responsabilidad del Service Desk, quien monitorea, escala, da curso y generalmente cumplimenta los requisitos del usuario. El personal de Service Desk y de Incident Management administran los requerimientos de servicios.

Problem Management (PM)

Los objetivos del PM son:

- Administrar el ciclo de vida de todos los problemas - Prevenir problemas y sus incidentes asociados - Eliminar incidentes recurrentes - Minimizar el impacto de los incidentes que no se pueden prevenir

Modelos de Problemas

- Los incidentes pueden volver a ocurrir por problemas subyacentes activos o latentes - La creación de registros de Errores Conocidos en la KEDB asegura un mejor diagnóstico - Similar a los Modelos de Incidentes

Error Conocido (Known Error): Entender la causa raíz de un tema o falla (sin tener necesariamente la solución definitiva) y tener la documentación para referencias futuras que ayuden a restaurar los servicios en forma más eficiente.

Base de Datos de Errores Conocidos (Known Error Database): Almacenamiento para el conocimiento previo de los requerimientos y errores conocidos, y como fueron resueltos para ayudar a un diagnóstico más rápido si ocurren.

El rol del Problem Manager es el siguiente: - Vínculo con todos los grupos de resolución de problemas - Dueño y protector de la KEDB - Responsable de la inclusión de todos los Errores Conocidos - Responsable del cierre formal de los registros de los problemas - Vínculo con los proveedores, contratistas, etc - Coordina, conduce, documenta y da seguimiento a todas las actividades de revisión

Planes de Facturación - mySAP SCM

2009-09-02T15:43:00.000-07:00

Los planes de facturación permiten programar las fechas para la creación de la facturas relacionados al abastecimiento de materiales o servicios independientes. Se listan las fechas en las cuales se desean crear y pagar las facturas. El sistema crea las facturas automáticamente sobre la base de los datos de la orden de compra, de modo de realizar el pago al proveedor. Se puede ingresar la factura, manual o automáticamente, aun plan de facturación.

Las condiciones para trabajar con un plan de facturación son: (1) Mantener las asignaciones en Customizig para compras, (2) El ítem de la orden de compra debe tener una imputación contable y (3) Usar la verificación de facturas.

Existen 2 clases de planes de facturación: (1) Periódico, el cual puede ser usado para las transacciones de abastecimiento y determina que las fechas de las facturas sean generadas automáticamente cuando se crea un plan de facturación; y (2) Parcial, el cual se usa para facturar el abastecimiento de material o servicio donde la liquidación es efectuada en etapas o para facturar las etapas individuales de un proyecto. El valor del ítem de la orden de compra es dividido de acuerdo a las fechas individuales del plan.

Para utilizar el plan de facturación con liquidación automática, se debe asignar el indicador ‘Eval Receipt Sett’ en el registro maestro de material antes de crear la framework order (FO).

Los pasos para crear un plan de facturación son: (1) Crear una orden de compra con tipo FO, (2) Ingresar material / servicio, cantidad precio y categoría de imputación contable; y (3) Asignar los indicadores GR, Invoice, ERS.

Para la liquidación se deben tener asignados los siguientes indicadores ‘Eval Receipt Sett’ en el registro maestro de material e ‘Invoice’ en el registro maestro de proveedor.

El código de impuesto es un pre-requisito para la liquidación automática y se asigna en el ítem del plan de facturación. Liquidación significa generar facturas necesarias con el pago teniendo en cuenta lo financiero.

IM y EM - ITIL V3

2009-08-03T06:55:00.000-07:00

Incident Management (IM)

Los objetivos de IM son: - Retornar a la situación de operación normal a la brevedad - Minimizar el impacto en la operación del Negocio - Mantener los niveles óptimos de Calidad y Disponibilidad del Servicio

El Alcance está definido de la siguiente forma: - Cualquier evento que genera o puede llegar a generar una disrupción en un servicio - Requerimientos registrados o reportados por personal técnico - No todos los eventos son Incidentes

Modelos de Incidentes Métodos acordados compuestos de pasos predefinidos para el manejo de un proceso Garantiza que los incidentes “estándar” se manejen de una forma predefinida – Actividades para preservar las evidencias – Plazo de Ejecución y umbrales – Procedimientos de Escalación – Responsabilidades

Plazos de EjecuciónDeben ser acordados para todas las etapas – Basados en los objetivos de respuesta y resolución: SLA, OLA – Se debieran usar herramientas para automatizar los plazos y escalamientos – Los grupos de soporte deben estar informados

Incidentes GravesMenor plazo de Ejecución y mayor urgencia. Incidente con mayor impacto o prioridad: Potencial impacto en el Negocio.

Las actividades de la Gestión del incidente son: 1- Identificación del incidente 2- Registración 3- Categorización 4- Priorización 5- Diagnóstico inicial 6- Escalación 7- Investigación y desarrollo 8- Resolución y recuperación 9- Cierre

IM utiliza métricas para el monitoreo y reporte. Esto sirve para determinar la efectividad y eficiencia. Las métricas serían: - Cantidad total de incidentes - Desglose de incidentes por etapa - Cantidad de incidentes aún sin solución - Cantidad y porcentaje de incidentes graves - Costo promedio por incidente, etc.

Los desafíos de IM son: - Habilidad para detectar los incidentes en forma temprana - Asegurar que todos los incidentes se registren - Disponibilidad de la Información: Problemas y Errores Conocidos - Integración con: • Relaciones entre CI’s y el historial • SLM: para evaluar correctamente el impacto y prioridad • SLM: para usar procedimientos de escalación definidos

Las principales actividades del Incident Manager son: - Es responsable por la efectividad y eficiencia - Genera información de gestión - Administra el trabajo del personal de soporte a Incidentes (1er & 2do nivel) - Monitorea la efectividad del proceso y recomienda mejoras - Desarrolla y mantiene los sistemas para la gestión de incidentes (IMS, Incident Management systems) - Gestiona los Incidentes graves - Desarrolla y mantiene los procesos y procedimientos

Event Management (EM)

Los objetivos de EM son: - Detectar y analizar eventos - Determinar acciones de control apropiadas - Automatizar actividades de la Gestión de Operaciones - Ser el punto de contacto para la ejecución de procesos y actividades - Comparar la performance y el comportamiento actual frente a los estándares del diseño y los SLAs

Existen tipos de eventos diferentes:

- Indicación de operación normal: Notificación de cuando se completó un trabajo planificado, Un usuario que accede a una aplicación y Un e-mail que se despacha a su casilla

- Indicación de excepción: Un usuario que trata de acceder con una clave incorrecta, Un procesador que está trabajando por encima del umbral establecido y Escaneo de PC que indica un software no autorizado

- Indicación de una operación inusual pero no excepcional: Una situación que puede requerir un monitoreo más cuidadoso

Rol del Event Manager

Dado que los eventos ocurren en distintos contextos y por diferentes razones, no es necesaria la figura de un Event Manager. Las actividades se delegan a las Gerencias del Service Desk o de Operaciones de TI.

- Service Desk: Comunicación (Informar a quien corresponda) e Investigación y resolución de eventos (Escalar al equipo de Operaciones apropiado).

- Service Design: Clasificar y Definir: motores de correlación y respuestas automáticas

- Service Transition: Garantizar el funcionamiento apropiado y correcto de los eventos generados y sus respuestas.

- Service Operation: Ejecutar la Gestión de eventos para los sistemas bajo su control

- Technical & Application Management: Involucrados en lo que respecta a los Incidentes y problemas relacionados con los eventos

Inventario Físico - mySAP SCM

2009-08-03T06:51:00.000-07:00

El inventario físico (IF) es realizado en base a las unidades de manejo de stock. Estas unidades son una parte no divisible de un stock de material en donde existe un libro de inventario separado. Se define a través de: material, planta, almacén, tipo de stock, lote y stock especial.

Los pasos de un inventario físico son: (1) Crear los documentos de inventario físico, (2) Ingresar el conteo y (3) Contabilizar la diferencia de inventario. En la creación de los documento de IF (Paso 1 – transacción MI01) se deben seleccionar los stocks a contar y crear los documentos de IF. Algunos de los datos del documento de IF son: planta y almacén del conteo, fecha del conteo, materiales a contar, tipos de stock a contar, estado del ítem (procesado, contado, contabilizado o recontado), estado del documento de IF y otros. Los ítem del documento de IF son asignados a un grupo de material.

Existe un número de IF en el encabezado del documento, el cual facilita la selección de los documentos de IF a ser procesados durante el ingreso de los datos del conteo, la contabilización de las diferencias y evaluaciones. En un documento de IF se pueden realizar los siguientes cambios: encabezado del documento, ítem no contado, ingreso de nuevos ítems y borrado/eliminación del documento.

En el ingreso del conteo (Paso 2 – transacción MI04) se plantean las siguientes situaciones: imprimir los documentos de IF, ingresar los resultados del conteo, determinar las diferencias de inventario y actualizar los resultados del conteo. La diferencia de inventario surge de la diferencia entre el resultado del conteo y el libro de inventario. Esta diferencia se establece en la lista de diferencia (cantidad contada, libro de inventario, diferencia de cantidad, diferencia de suma).

La contabilización de la diferencia de inventario (Paso 3) se realiza por medio de las listas de diferencia y de transacciones separadas.El IF permite contabilizar documentos de material y documentos contables. La diferencia de inventario permite especificar la razón de la diferencia de inventario, las tolerancias respecto de las diferencias de inventario y puede ser contabilizada en el mismo período o en el siguiente período contable.

Cuando se ingresan los resultados de conteo, el sistema determina el actual libro de inventario. El bloqueo de movimientos de bienes pertenece a una unidad de manejo de stock y se realiza por medio de los siguientes indicadores: (1) Indicado ‘Posting Block’ (documento de IF) y (2) Indicador ‘Physical Inventory Book’ (registro maestro de material – tab storage location).

El bloqueo del stock de la compañía se realiza a nivel planta / almacén. El bloque del stock especial se realiza a nivel planta, almacén, stock especial, orden o proyecto. El libro de inventario se puede congelar, lo cual se realiza en el documento de IF en el momento del conteo. Para ello, se utiliza el indicador ‘Freze Book Inventory’. Para la actualización del libro de inventario se asignan los indicadores ‘Freeze Book Inventory’ y ‘Adjust Book Inventory’. Además, los resultaos del conteo son ingresados en el documento de IF.La diferencia de inventario cambia a través de la suma del movimiento de bienes. El sistema controla la fecha del movimiento de bienes. Los pasos del IF se pueden combinar y pueden ser realizados en sesiones batch input.

Los documentos de IF se pueden crear de las siguientes formas: manualmente, ingreso de conteo, ingreso de conteo y contabilización de diferencia, sesiones batch input, sesiones batch input con datos de conteo transferidos, sesiones batch input con datos de conteo trasferido y diferencia de inventario contabilizada. Un error ocurrido durante el muestreo de inventario puede deberse a la extrapolación del conteo del stock completo.

Stock Transfer - mySAP SCM

2009-07-05T15:28:00.001-07:00

El stock transfer consiste en una eliminación de material de un almacén a otro. Esta transferencia pede tener lugar dentro de un misma planta o entre 2 plantas. Las transferencias de stock implican un movimiento físico de bienes, el cual se realiza por medio de un procedimiento de uno o dos pasos. Estas trasferencias suceden en diferentes niveles organizacionales: (1) entre almacenes, (2) entre plantas y (3) códigos de compañía.

La transferencia de stock entre 2 almacenes ocurre dentro de una planta. La transferencia de stock entre 2 plantas ocurre cuando estas plantas pertenecen a un código de compañía. La transferencia de stock de un código de compañía a otro sucede en el caso de plantas asignadas a diferentes códigos de compañía.

En la transferencia de stock de almacén a almacén de puede efectuar un procedimiento de uno o dos pasos. En el procedimientos de un paso se ingresa una única transacción en el sistema, se usa para todos los tipos de stock, genera un documento de material que contiene el ítem de envío y el ítem de recepción; y no genera un documento contable debido a que el material transferido es administrado en la misma planta y tiene la misma fecha de contabilización.

En los procedimientos de 2 pasos se tiene la transferencia de un stock de uso irrestricto a otro stock de uso irrestricto. En el almacén de recepción, la cantidad está incluida en el stock de ese almacén como ‘sotck in transfer’. Se generan 2 documentos (envío de bienes / renoval from storage y recepción de bienes / place in storage). Cuando el material es eliminado del almacén, éste es contabilizado en el ‘stock in transfer’.

En la transferencia de stock de planta a planta , éstas solo pueden ser contabilizadas fuera del stock de uso irrestricto. Este tipo de transferencia tiene un procedimientote uno o dos pasos. En el procedimiento de un solo paso, el envío de bienes y recepción de bienes son contabilizadas en un único documento. En el procedimiento de 2 pasos, se determina que cuando se elimina el material del almacén, se especifica la planta de recepción del material y los niveles organizacionales de envío. Este tipo de transferencia de stock afecta MRP y la contabilidad financiera.

La orden de transporte del stock sin entrega involucra el manejo de inventario y compras en la planta de recepción. Se ingresa un envío de bienes referentes a esta orden de transporte de stock. La cantidad contabilizada es administrada como ‘stock in transit’ en la planta de recepción.

En el envío de bienes en la orden de transporte de stock se generan un documento de material y un documento contable. La cantidad es contabilizada fuera de la planta de envío. En la planta de recepción, el material no es parte del stock de uso irrestricto. Es registrado como stock en tránsito a nivel planta. No es posible contabilizar la recepción de bienes en un stock bloqueada debido a que el stock en tránsito ya está valuado.

En caso de daño de los bienes durante el transporte, se deben informar los problemas para así corregir la cantidad de stock en tránsito.

SACM y RDM en ITIL V3

2009-07-05T15:22:00.000-07:00

Service Asset & Configuration Management (SACM)

El objetivo de SACM consiste en “definir y controlar los componentes de Servicios e Infraestructura para mantener los registros precisos de la configuración existente”. Esto permite a la organización: - El cumplimiento de los requerimientos de Gobernabilidad corporativa - Controlar la Base de Activos - Optimizar costos - Permite realizar cambios y releases en forma efectiva - Ayuda a ser más expeditivo en la resolución de incidentes y problemas

Modelo Lógico: Requerido de los servicios, activos e infraestructura mediante el registro de las relaciones entre los CI.

Categorías de CI: Existen las siguientes categorías de CI: CIs del Ciclo de Vida del Servicio, CIs de Servicios, CIs de la Organización, CIs Internos y CIs Externos.

Configuration Management System (CMS)

El CMS contiene toda la información relacionada con la Gestión de la Configuración y los Activos de Servicios.

- Librerías seguras - Depósitos seguros - Librería Definitiva de Medios - Piezas de repuesto (Spares) definitivas. - Línea base de Configuración (Configuration Baseline) - Estado Actual de Configuración (Snapshot)

Rol del Service Asset Manager en SACM

- Implementa las políticas y estándares para la Gestión de Activos de Servicios - Evalúa los sistemas de Gestión de Activos existentes y diseña, implementa y gestiona los sistemas nuevos. - Establece los procesos, planes estándar y procedimientos para la Gestión de Activos - Promueve el conocimiento - Gestiona el reclutamiento y capacitación del personal - Evalúa herramientas para la Gestión de Activos (requerimientos de presupuesto, recursos, tiempos y especificaciones técnicas) - Implementa procesos, principios y planes de Gestión de Activos - Acuerda sobre convenciones de nombres y CIs - Define interfaces con otros procesos - Suministra reportes del tipo gerencial, de análisis de impacto y del estado de los activos. - Promueve el crecimiento y cambios - Gobernabilidad: Auditorías y acciones correctivas

Rol del Configuration Manager en SACM

- Implementa las políticas y estándares para la Gestión de la Configuración - Evalúa los sistemas de Gestión de la Configuración existentes y diseña, implementa y gestiona los sistemas nuevos o mejorados. - Establece los procesos para la Gestión de la Configuración - Promover el conocimiento de los procedimientos para la Gestión de la Configuración - Gestiona el reclutamiento y capacitación del personal - Evalúa herramientas para la Gestión de la Configuración - Implementar procesos, principios y planes de Gestión de la Configuración - Acuerdo sobre convenciones de nombres y CIs - Define interfaces con otros procesos - Suministra reportes del tipo gerencial, de análisis de impacto y del estado de la configuración - Promueve el crecimiento y cambios - Gobernabilidad: Auditorías y acciones correctivas Rol del Configuration Analyst en SACM

- Propone el Alcance de los procesos de Gestión de la Configuración y de los Activos - Capacita a Especialistas y otro personal relacionado con el proceso - Participa en la planificación e implementación de SACM - Participa en la definición de procesos y procedimientos de SACM - Gestiona Activos y CMS, librerías, códigos y datos comunes - Define interfase con la Gestión de Cambios - Identifica los CIs afectados - Audita la Configuración - Crea y actualiza las librerías de los Proyectos y sistemas de CM - Líneas Base: Acepta productos de terceros y crea las líneas base internas para releases - Mantiene el estado de los proyectos y genera reportes - Monitorea potenciales problemas

Rol del Configuration Administrator / Librarian en SACM

- Custodio y guardián de la información de SACM

Rol del CMS / Administrator en SACM

- Evalúa las herramientas de SACM - Monitorea el performance y capacidad de los sistemas de SACM - Realiza una administración técnica y soporte - Garantiza la integridad y operatividad de los sistemas CM.

Rol del Configuration Control Board en SACM

- Define la línea base de los servicios - Revisa los cambios en la configuración de los servicios - Genera requerimientos de cambios

Release & Deployment Management (RDM)

El objetivo del RDM es “establecer los planes de liberación e instalación (release & deployment) para garantizar que los cambios que se generen en los proyectos del negocio y los clientes estén alineados con estas actividades”. También permite lo siguiente: - Permitir la construcción, instalación, testeo y puesta en producción del paquete liberado - Brindar un nuevo servicio (o modificado) de acuerdo a los requerimientos acordados - Garantizar la transferencia de conocimiento a los clientes y usuarios - Garantizar la transferencia de conocimiento y habilidades al personal de soporte y operaciones - Minimizar impactos negativos no planificados en los servicios en producción - Mejorar el grado de Satisfacción de los Stakeholders

Rol del Release and Deployment Manager en RDM

Responsable de la planificación, diseño, construcción, configuración y testeo del software o hardware necesario para la creación de un paquete de release para la provisión de, o cambio a, un Servicio específico.

Sus responsabilidades son: - Gestionar el proceso de releases de punta a punta - Actualizar los sistemas SKMS y SACM/CMDB - Coordinar los equipos para construir, testear y liberar - Generar reportes de avance: – Diseño, construcción y configuración de los paquetes – Aceptación de los Releases – Planificación de la puesta en producción (Rollout) – Testeo de los Releases – Firmas de Aceptación – Comunicación y entrenamiento – Auditoría del Pre-release – Instalación del Hardware – Almacenamiento del Software para su trazabilidad y auditoría – Release, distribución e Instalación

Rol del Release Packaging and Build Manager en RDM

Administra el flujo de trabajo (establece los requerimientos, diseños, construcción, testeo, implementación, operación y optimización) para proveer aplicaciones e infraestructuras que cumplan con los requerimientos de diseño de los Servicios.

Sus responsabilidades son: - Establece la configuración final de los releases - Construye la versión final del release a entregar - Testea la versión final antes del testeo independiente - Establece y reporta los errores conocidos más importantes y sus workarounds - Brinda información para la firma de la aceptación de la implementación

Rol del Deployment

Sus principales responsabilidades son: - Entrega física final - Coordinar documentación y comunicaciones - Planear la instalación - Brindar guía y soporte técnico y de las aplicaciones - Proveer Feedback - Registrar las métricas para los SLA

SM y CH en ITIL V3

2009-06-02T08:03:00.000-07:00

Gestión de Proveedores (Suppliers Management - SM)

Los objetivos del SM son: - Obtener valor por el dinero pagado a proveedores y contratistas - Alineación de los UC con los acuerdos y objetivos planteados - Gestionar las relaciones y performance de los Proveedores - Negociar, acordar y gestionar los contratos con los proveedores a lo largo del ciclo de vida - Mantener las políticas de proveedores, y la base de datos de proveedores y contratos (SCD, Supplier & Contract Database)

El rol del Supplier Manager es el siguiente:

- Realiza SLAs, contratos, acuerdos, etc. - Actualización de base de datos de Proveedores y Contratos (SCD, Supplier & Contracts Database) - Evaluación y Revisión de riesgos - Evita conflictos

Change Management (CHM)

El objetivo del CHM es garantizar que los cambios se registren, evalúen, autoricen, prioricen, planifiquen, testeen, implementen, documenten y revisen de una forma controlada.

El alcance de CHM abarca lo siguiente: - Cambios a la línea base de Activos de Servicio (Cartera de Servicios) e Items de Configuración (CMDB) a lo largo de todo el Ciclo de Vida de los Servicios - Se debieran definir aquellos cambios al alcance fuera del proceso de Cambios de Servicios

Las actividades del Proceso de CHM son: - Planificación y Control de Cambios - Agenda de Cambios y releases - Comunicaciones - Decisiones y autorizaciones de los Cambios - Asegurar que existan Planes correctivos - Mediciones y control - Reportes de Gerencia - Comprensión del Impacto del Cambio - Mejora Continua

Las actividades del Proceso para gestionar cambios puntuales son las siguientes: - Crear y registrar cambio - Revisar RFC y propuesta para el cambio - Filtrar los cambios - Valoración y evaluación del cambio - Autorización - Actualización de Planes - Coordinar la Implementación del cambio - Revisión y cierre

Métricas Clave de CHM

Medidas para las Salidas

- Cantidad de errores, problemas, incidentes e interrupciones causadas por cambios incorrectos - Cantidad de especificaciones inadecuadas y Evaluaciones de impacto incompletas - Cambios no autorizados - Porcentaje de reducción (cambios no autorizados, o tiempos, esfuerzos y costos de los cambios) - Porcentaje de mejora (predicciones de tiempos, esfuerzos y costos) - Retrabajo requerido por especificaciones de cambios inadecuadas

Carga de Trabajo

- Frecuencia de los cambios (por servicio, área de negocio, etc.) - Cantidad de cambios

Medidas del Proceso

- Satisfacción de la gente con la velocidad, claridad o facilidad de uso - Cantidad y porcentaje de cambios que usan el proceso formal de cambios - Cantidad de RFCs registrados usando herramientas automáticas - Tiempo para completar un cambio (desde el inicio a la completitud) - Utilización del personal - Costos versus presupuesto

Los desafíos de CHM son los siguientes:

- Cantidad y variedad de interfaces - Falta de integración de los procesos y disciplinas que impactan en ST - Diferencias y dependencias inherentes de los elementos - Estabilidad del ambiente productivo frente al tiempo de respuesta para el negocio - Alcanzar un balance entre Pragmatismo y Burocracia - Fomentar la Estandardización, simplificación y compartir el conocimiento - Permitir los Programas de Cambio para el Negocio - Encontrar “Champions” - Gestionar el impacto en tiempo y presupuesto - Intereses de los Stakeholders versus la Gestión del Riesgo - Gestionar el Riesgo versus Asumir el Riesgo - Reportes efectivos (riesgos y gobernabilidad)

Rol del Change Manager en CHM

- RFCs: recibir, registrar y determinar prioridades (Rechazar los incompletos y los impracticables) - Llama a reuniones urgentes - Dirige las reuniones - Coordina desarrollos, testeos e implementaciones - Actualiza el registro de cambios - Revisa los cambios implementados - Revisa los RFCs principales - Analiza los registros de cambios (tendencias / problemas) - Cierra RFCs - Genera reportes de Gestión

Rol de la Autoridad para el Cambio en CHM

- Nivel de autorización que se juzga de acuerdo al tipo, tamaño o riesgo del cambio - La Autoridad Delegada pude existir con un nivel de autorización. Se tienen un conjunto parámetros relacionados con: riesgos para el Negocio, implicancia financiera y alcance del cambio

Rol del Change Advisory Board en CHM

- Está compuesta de acuerdo al cambio que se considera en la reunión y puede variar en el transcurso de una misma reunión - Debería involucrar a los proveedores - Se debería considerar las Visiones de los usuarios y clientes - Incluye: Problem Manager, Service Level Manager y Personal de Relaciones con el Cliente

Reservas - mySAP SCM

2009-06-02T08:01:00.000-07:00

La reserva es el requerimiento del almacén para tener material para un movimiento de bienes lista para una fecha posterior y para un propósito en particular. Permite simplificar y acelerar el proceso de ingreso y ayuda a preparar el envío e bienes. La reserva permite preplanear el envío de bienes y las transferencias contables.

La creación de una reserva puede ser manual (MB21 y se usa en MIGO) o automáticamente. No se pueden mostrar o mantener reservas automáticas. No se puede cambiar una reserva de una orden de manera directa, ya que los componentes debe ser cambiados en la orden. El sistema actualiza la reserva de manera automática.

La reserva tiene un encabezado con los datos generales y al menos un ítem con los movimientos planeados individualmente. En una reserva solo se puede ingresar un tipo de movimiento y crear una imputación contable. No se puede cambiar estos 2 ingresos después de la contabilización. Cuando se crea una reserva, se puede hacer referencia a otra reserva. El sistema sugiere los ítems de la reserva y se pueden seleccionar los ítems que se desean copiar.

El indicador ‘Movement Allowed’ permite impedir un movimiento de bienes que será contabilizado en un ítem de reserva. Para cada planta, se puede asignar este indicador cuando se crea una reserva de los ítems. Se puede activar o desactivar el indicador para todos los ítems. El indicador ‘Final Issue’ permite especificar el envío de la cantidad total reservada durante el envío de bienes.

La evaluación de las reservas se pueden hacer a través de los siguientes informes: (1) Lista de reserva en el manejo de inventario, (2) Gestión de reserva, (3) Lista de selección de reserva, (4) Control de la disponibilidad, (5) Control de las partes faltantes y otros.

El control de la disponibilidad puede ser estático o dinámico. En el control de disponibilidad estática se tienen en cuenta los stocks existentes en el momento del ingreso. Se realiza de manera automática y no se pueden realizar asignaciones en el sistema. Abarca el stock que afecta la planta, el almacén y a nivel stock especial.

En el control de disponibilidad dinámica se tiene en cuenta que los stocks existentes físicamente en un almacén pueden ser controlados desde el punto de vista de MRP (Material Requirements Planning). Este control se puede usar en el manejo de inventario o en el ingreso de una venta u orden de producción. Se pueden tener en cuenta los envíos o recepciones planeadas. Este control se relaciona con el control de partes faltantes, lo cual significa que un requerimiento actual no puede abarcar el stock existente.

En las reservas se pueden contabilizar los movimientos de bienes solo si está asignado el indicador ‘Movement allowed’.

El control de disponibilidad dinámica tiene en cuenta los stocks en el momento del ingreso y futuros envíos/recepciones.

Good Issue - mySAP SCM

2009-05-04T07:21:00.000-07:00

El envío de bienes (Good Issue), por medio de la transacción MIGO, es un movimiento donde un material retirado, consumo de material o envío de material es contabilizado a un cliente. Es un movimiento de bienes dirigido a una reducción de stock. En el envío de bienes se puede seleccionar: Reservation, PO u Order.

El envío de bienes no planeados plantea las siguientes situaciones: (1) Envío de bienes sin referencia, (2) Muestreo y (3) Descarte.

En el envío sin referencia se tiene un tipo de movimiento, el cual determina que datos acerca de la imputación contable se tienen que especificar. Las transacciones que reducen el stock son contabilizadas cuando los bines ordenados son retornados a los proveedores. En el muestreo solo una pequeña cantidad de material recibe inspección de calidad, es controlada y probada. Para asegurar que la cantidad a ser controlada es eliminada del stock, se contabiliza un muestreo. El reintegro del muestreo no resulta de una actualización de consumo. En el descarte se ingresa una contabilización de descarte si un material o puede ser usado. Esto es posible para cada tipo de stock y es ingresado como envío de bienes sin referencia.

El envío de bienes con referencia plantea las siguientes situaciones: (1) Envío de bienes con referencia a una reserva y (2) Envío de bienes con referencia a una orden. En el envío de bienes con referencia a una reserva se tiene una provisión de material a través de una reserva. La referencia a una reserva permite simplificar el ingreso de movimiento de bienes. Esta referencia es necesaria para las cantidades retiradas a ser actualizadas en la reserva. Un retiro con referencia a un ítem de reserva solo es posible si el indicador ‘Movement Allowed’ ha sido asignado al ítem. No es posible cambiar un movimiento de bienes con referencia a una reserva usando MIGO.

En el envío de bienes con referencia a una orden, las cantidades requeridas de los componentes son reservadas de manera automática. En la determinación del stock se usan estrategias basadas en asignaciones para el material retirado del envío de bienes y transferencia de stock. Se determina la secuencia de los almacenes y stocks para los cuales es retirado el material deseado.

El stock negativo ocurre cuando se contabiliza el envío de material con una cantidad mayor a la cantidad del libro. Desde lo físico, no existe el stock negativo pero se puede trabajar con el mismo (stock bloqueado y stock de uso irrestricto). Se establece en el registro maestro de material y está permitido a nivel área de valuación, almacén, planta, stock especial y material (para cada planta).

SCOM e ISM en ITIL V3

2009-05-04T07:16:00.000-07:00

Gestión de la Continuidad del Servicio (Service Continuity Management - SCOM)

Los objetivos de SCOM son: (1) Mantener los Servicios de Continuidad de TI y los Planes de Recuperación de TI, (2) Completar el Análisis de Impacto del Negocio (BIA, Business Impact Analysis), (3) Conducir evaluaciones y gestión de riesgos de manera regular, (4) Proveer consejos y guías a todas las áreas, (5) Establecer los mecanismos apropiados para cumplir con los objetivos acordados en cuanto a la continuidad del negocio, (6) Evaluar impacto de los cambios sobre los planes de continuidad y recuperación de los servicios de TI, (7) Implementar medidas para la mejora de la disponibilidad de los servicios, (8) Gestión de Contratos para la provisión de las capacidades necesarias para la recuperación, mediante el proceso de gestión de los proveedores

Conceptos Básicos: Iniciación, Requerimientos y estrategia, Implementación y Operación

Rol del ITSCM Manager: - Implementar y mantener los procesos de ITSCM de acuerdo con los procesos de BCM • Planes, riesgos y actividades • Análisis de Impacto del Negocio • Evaluación y Gestión de Riesgos • Comunicación y creación de conciencia - Desarrollo y mantenimiento de la estrategia para la continuidad • Evaluación de problemas potenciales de continuidad del servicio • Gestión del Plan de Continuidad de los Servicios mientras se encuentra en operación • Desarrollo y gestión de planes de ITSCM • Garantizar la preparación de todas las áreas de TI • Contratos de Servicios de recuperación con terceras partes - Agenda de testeo de TI • Revisiones de calidad, conformidad con las normas y post mortem - Evaluación del impacto de los cambios en la continuidad y los planes asociados

Gestión de la Seguridad de la Información (Information Security Management - ISM)

Los objetivos de ISM son: confidencialidad, integridad, disponibilidad, y autenticidad y no repudio.

Confidencialidad: Solo se puede acceder a la información por aquellos que estén autorizados.

Integridad: La información es completa, precisa y está protegida contra modificaciones no autorizadas.

Disponibilidad: La información está disponible y puede ser usada cuando se la necesita.

Autenticidad y no repudio: Los intercambios de información entre las partes son confiables.

Conceptos Básicos - Entorno de Seguridad - Política de Seguridad de la Información - Sistema de Gestión de la Seguridad de la Información (ISMS, Information Security Management System) - ISO 27001 - Gobernabilidad de la Seguridad Rol del Security Manager - Desarrollar y mantener Políticas de Seguridad de la Información y de soporte • Comunicar y publicar • Obligar al cumplimiento (adherencia) • Promover la educación y brindar el conocimiento sobre temas relacionados con la seguridad - Diseñar Planes y controles relacionados con la Seguridad • Desarrollar y documentar Procedimientos para operar y mantener los controles de Seguridad • Mantener, revisar y auditar - Asistir en el Análisis del Impacto del Negocio • Identificar y clasificar Activos de TI y de Información (Configuration Items) y el nivel de control y protección requeridos • Análisis y Gestión de los riesgos relacionados con la seguridad • Ejecutar Pruebas de seguridad - Monitorear y administrar los Incumplimientos e Incidentes • Reportar, analizar y reducir el impacto y volumen de los incidentes de seguridad • participar en las revisiones de seguridad - Asegurar confidencialidad, integridad y disponibilidad de los servicios a los niveles acordados en los SLAs y requerimientos reglamentarios • Evaluar impacto de los cambios respecto a la seguridad: CAB • Acceso de partners y proveedores externos sujetos a lo acordado • Persona de Referencia para problemas relacionados con la Seguridad

Good Receipt - mySAP SCM

2009-04-01T06:58:00.000-07:00

La recepción de bienes (Good Receipt - GR), por medio de la transacción MIGO, es un movimiento de bienes en donde se contabiliza la recepción de bienes de un proveedor externo y de una producción. La recepción de bienes permite aumentar el stock de almacén.

Los bienes entregados debido a una orden de compra (OC) permiten ingresar una recepción de bienes con referencia a la OC. La recepción implica una verificación de lo siguiente: entrega del material, cantidad entregada y bienes en su ciclo de vida.

La recepción de bienes genera un documento de material y un documento contable. El documento de material genera información sobre el material entregado y la cantidad respectiva. El documento contable genera información sobre los efectos contables del movimiento de material.

La transacción MIGO tiene las siguientes áreas: (1) ‘Overview tree’ para seleccionar los documentos de material, (2) ‘Header data’ con información del documento de material entero, (3) ‘Item overview’ con la lista de ítems del documento y (4) ‘Item Detail Data’ con información detallada del ítem.

Los movimientos de bienes se especifican por medio de un tipo de movimiento, el cual permite diferenciar los movimientos de bienes y determina que cuenta de stock / consumo son actualizadas en Contabilidad Financiera. Los tipos de movimiento pueden ser: GR, Good Issues, Transfer Posting y otros.

La recepción de bines plantea los siguientes casos: (1) GR sin referencia, (2) GR con referencia, (3) Retorno de entrega, retornos y cancelación, (4) Indicador de entrega completa y tolerancias; y (5) control de los datos de la GR para la OC.

GR sin referencia consiste en ingresar los movimientos de bienes sin referencia a otro documento (OC, orden de producción o reservas).

GR con referencia es una GR planificada en donde se ingresa: (1) Qué material, (2) cuándo es la fecha de entrega, (3) qué cantidad, (4) desde qué proveedor o planta y (5) qué lugar de destino.

En la devolución de entrega se determina el material incorrecto que fue entregado o que la calidad del material entregado es insuficiente. Por lo tanto, se devuelve el material al proveedor. La devolución de material valuado reduce el stock tanto en cantidad como en valor.

En la entrega subsiguiente se planeta que si el proveedor envía una entrega subsiguiente después de la devolución de entrega, se puede ingresar una GR como una devolución de entrega.

La OC a devolver tiene que ver con la devolución de entrega de material a un proveedor externo. No se crea una referencia a la OC.

La cancelación hace referencia o no a un documento de material.

Para los movimientos de bienes se pueden definir diferentes unidades de ingreso (unidad base de medida, unidad el precio de la orden y otras).

La fecha de entrega se controla si los bienes son entregados antes o después. Si la fecha de entrega es alcanzada, el stock bloqueado de GR puede ser liberado. Para prevenir los bienes que son aceptados en una entrega demorada, se debe especificar la fecha de GR lo más tarde posible en la OC.

CM y AM en ITIL V3

2009-04-01T06:50:00.000-07:00

Gestión de la Capacidad (Capacity Management – CM)

Los objetivos de CM son:

- Generar y mantener actualizado el Plan de Capacidad - Proveer consejos y guías en cuanto a Capacidad y performance - Asegurar el cumplimiento de las metas de performance de los servicios - Resolver los incidentes y problemas relacionados con performance y capacidad - Evaluar el impacto de los cambios respecto a capacidad y performance - Implementar medidas para mejorar la performance de los Servicios

‘Balancing Act’

La capacidad y performance de los servicios de TI y sistemas debiera de hacer juego con las demandas acordadas del negocio en la forma más efectiva respecto al costo y tiempo.

Business Capacity Management

Se focaliza en los requerimientos actuales y futuros del negocio, transforma necesidades del negocio y planes en requerimientos de servicio e infraestructura de TI, asegurando que los mismos sean cuantificados, diseñados, planificados e implementados en el tiempo necesario para ello.

Service Capacity Management

Se focaliza en la entrega de los servicios actuales que soportan el negocio, su gestión, control y predicción de la performance y capacidad en producción, uso operacional de los servicios de TI y cargas de trabajo.

Component Capacity Management

Se focaliza en la infraestructura de TI que soporta la provisión de los servicios, si gestión, control y predicción de la performance, utilización y capacidad de cada uno de los componentes de la tecnología de TI.

Rol del Capacity Manager

- Garantizar la Capacidad de TI adecuada

o Entender los requerimientos de Capacidad, uso y capacidad o Estimación de tamaño para los nuevos servicios y sistemas (requerimientos futuros) o Generación y revisión del plan de Capacidad

- Alinear de manera correcta la capacidad con la demanda

- Optimizar la capacidad existente

- Establecer los niveles de monitoreo apropiados mediante:

o Análisis y reporte de Performance o Resolución de Incidentes y Problemas o Optimización de Performance y recursos o Evaluación de Performance y costo o Evaluación de la demanda futura o Evaluación del impacto de los cambios

- Estimación de tamaño para los nuevos servicios y sistemas

o Evaluación de técnicas, hardware y software nuevo o Testeo de Performance o Reportes relacionados con el SLA (efectos de la demanda en cuanto a los niveles de servicio para la performance) o Determinación de Niveles de servicio mantenibles con costos justificables o Recomendaciones para la Optimización - Persona de Referencia para los problemas de Capacidad y performance o Reportes de Gestión: uso actual, tendencias y estimaciones a futuro

Gestión de la Disponibilidad (Availability Management - AM)

La gestión de la disponibilidad debiera asegurar que se proveen los niveles de disponibilidad acordados, realizar mediciones y monitoreos que garanticen el cumplimiento de los niveles de disponibilidad en forma consistente. También permite mejorar la disponibilidad de la infraestructura de TI, los servicios y la organización de soporte.

Los objetivos de AM son:

- Generar y mantener el Plan de Disponibilidad - Proveer consejos y guías al resto de las áreas sobre los temas de disponibilidad - Garantizar que se cumplan los objetivos de disponibilidad - Diagnosticar y resolver incidentes y problemas relacionados con la disponibilidad - Evaluar el impacto de los cambios respecto al plan de disponibilidad - Garantizar medidas proactivas para mejorar la disponibilidad de los servicios

Elementos clave:

• Actividades Reactivas • Actividades Proactivas • Niveles Inter-conectados: • Disponibilidad de Servicios • Disponibilidad de Componentes • Cuatro Aspectos: • Disponibilidad (Availability) • Confiabilidad (Reliability) • Mantenibilidad (Maintainability) • Capacidad de Servicio (Serviceability)

Rol del Availability Manager

Participa en el diseño de la infraestructura de TI

- Diseño de servicios nuevos - Sistemas de Gestión de Eventos - Confiabilidad, Facilidad de Mantenimiento y Nivel de Servicio - Criterios de diseño de Disponibilidad y recuperación

Monitoreo del alcance del nivel de disponibilidad de TI actual

- Garantizar los niveles de disponibilidad respecto a los SLAs - Investigación y diagnóstico de incidentes y problemas - Mejora de los Servicios de disponibilidad para optimizar la disponibilidad

Responsable de garantizar que el proceso de Gestión de la Disponibilidad se revise, audite y cambie de acuerdo al plan de mejora continua

- Crear, mantener y revisar el Plan de disponibilidad - Agenda de testeo de la disponibilidad - Testeo de cambios importantes en el negocio Evalúa el impacto de los cambios en el Plan de Disponibilidad

- Participar de las reuniones de CAB

Garantiza los niveles de disponibilidad de TI a costos justificables

Evaluación y Gestión del riesgo

SLM y SCAM en ITIL V3

2009-03-02T04:07:00.000-08:00

Service Level Management (SLM)

Los objetivos del SLM son:

- Garantizar un entendimiento claro entre el cliente y TI - Garantizar actividades proactivas para mejorar los niveles de servicio - Mejorar la satisfacción del cliente

Alcance

• Desarrollar relaciones con el Negocio • Negociar y acordar requerimientos actuales (SLA) y requerimientos futuros (SLR) • Desarrollar y Gestionar Objetivos alineados entre los SLA (OLA) • Revisar los contratos con la Gestión de Proveedores • Prevenir de forma proactiva fallas de los Servicios • Reportar y administrar Servicios • Plan de Mejora de los Servicios (SIP, Service Improvement Plan)

Service Level Management (SLM): Un canal de comunicación y relacionamiento con los representantes apropiados del cliente y del Negocio

Service Level Agreement (SLA): Acuerdo escrito entre un proveedor de servicios de TI y el cliente(s) de TI, donde se definen los objetivos clave de Servicio y las responsabilidades de ambas partes.

Operational Level Agreement (OLA): Acuerdo entre un proveedor de servicios de TI y otra parte de la misma organización que asiste en la provisión de los servicios. Contrato Subyacente (UC, Underpinning Contract): Contrato formal entre un proveedor de servicios de TI y una tercera parte.

Actividades de los Procesos

- Determinar, negociar, documentar y acordar los requerimientos para servicios nuevos o modificaciones. - Monitoreo y medición de los logros de performance de los servicios para todos los servicios operacionales respecto a los objetivos. - Recopilación, medición y mejora de la satisfacción del cliente. - Generación de reportes de servicio, realización de revisiones y promoción de mejoras dentro de un plan de mejora de los servicios - Revisión de los acuerdos del nivel del servicio, determinación del servicio. - Desarrollo y documentación de los contratos y relaciones con el negocio, clientes y partes interesadas. - Desarrollo, mantenimiento y operación de procedimientos para el acceso, toma de acciones y resolución de quejas, informando las mismas. - Suministro de la información de gestión apropiada para ayudar en la gestión de performance y en la demostración de los logros del servicio. - Actualización de las plantillas de documentos de SLM y estándares.

Métricas clave de SLM

Reducción de porcentajes en:

- Objetivos no alcanzados de los SLA - Objetivos en riesgo de los SLA - Incumplimiento de SLA (UC) - Incumplimiento de SLA (OLA)

Aumento de porcentajes en percepción y satisfacción del Cliente respecto a los alcances dentro del SLA

– Revisiones de los servicios – Respuestas de la encuesta de satisfacción del cliente

Desafíos del SLM

- Ser un proveedor de servicios para el Negocio - Ser atractivo para el Negocio - Identificar Cartera de Servicios Interna - Definir Catálogo de Servicios - Definir las relaciones del departamento de TI - Identificar las relaciones contractuales - Plan de Mejora de los Servicios

Rol del Service Level Manager

- Estar atento a los cambios de las necesidades del negocio - Identificar, entender y documentar requerimientos de Servicios actuales y futuros - Producción/mantenimiento de Cartera de Servicios, Catálogo de Servicios y Cartera de Aplicaciones - Garantizar el alineamiento entre los UC y los objetivos de los SLA y SLR - Desarrollar relaciones y comunicaciones con los stakeholders, clientes y usuarios clave - Ser responsable de la medición, registro, análisis y mejora de la satisfacción del cliente.

Service Catalogue Management (SCM)

El objetivo del SCM es administrar la información actualizada que se encuentra en el Catálogo de Servicios y brindar el Estado, interfaces y dependencias de los servicios que se ejecutan en el ambiente productivo

Catálogo de Servicios: Se compone del Catálogo de servicios del negocio y del Catálogo de Servicios Técnicos.

Catálogo de Servicios del Negocio: Interfase con las unidades y proceso del negocio y los servicios de TI que los soportan.

Catálogo de Servicios Técnicos: Interfase con los equipos de soporte, proveedores y gestión de la configuración.

Rol del Service Catalogue Manager

Es responsable de generar y mantener el Catálogo de Servicios, incluyendo:

- Registrar los Servicios nuevos y existentes en el Catálogo de Servicios - Garantizar que la información existente en el Catálogo de Servicios sea precisa y esté actualizada - Garantizar que la información existente en el Catálogo de Servicios y la Cartera de Servicios sea consistente - Garantizar que la información existente en el Catálogo de Servicios esté protegida adecuadamente y respaldada

Las actividades clave para el proceso de SCM debieran incluir:

- Definición del servicio - Cartera de servicio y Catálogo de servicios - Catálogo de servicios del negocio - Catálogo de servicios técnicos - Alineación con el negocio y los procesos del negocio

Release Procedure - mySAP SCM

2009-03-02T04:05:00.000-08:00

Los documentos de compras externos (órdenes de compra, contratos, scheduling agreement y solicitudes de cotización) y las solicitudes de compra (SC) que cumplen condiciones, se consideran documentos aprobados por medio de un procedimiento de liberación. La aprobación implica el uso de una transacción de liberación a través de un código de liberación. Esta liberación puede ser cancelad con el mismo código.

El proceso de aprobación es reproducido por medio del procedimiento de liberación. Los objetivos de este proceso son: (1) Verificar material, cantidad y fecha de entrega; (2) Verificar la imputación contable y la fuente de abastecimiento.

Los documentos de compras externos, solo para procedimientos con clasificación, son liberadas a nivel cabecera, ya que la liberación a nivel ítem no es posible. Respecto de la SC, se puede decir que no se puede bloquear una SC completa y los ítems bloqueadas no pueden ser convertidos en OC.

La liberación de la SC puede tener 2 casos posibles: (1) con clasificación y (2) sin clasificación. La liberación con clasificación permite liberar ítem por ítem o de manera completa. La libración sin clasificación permite liberar a nivel ítem.

Las SC pueden ser liberadas de 2 maneras: (1) individual o (2) colectiva. En la liberación individual (ME54) se libera ítem por ítem o el documento entero. En la liberación colectiva (ME55) se liberan todos los ítems de la SC o todas las SC por medio del código de liberación.

La OC puede ser liberada de manera individual (ME29N) o colectiva (ME28).

El indicar de liberación de la SC determina lo siguiente: (1) si se puede cambiar el ítem, (2) si se determina una nueva estrategia en los cambios, (3) si se cancelan las liberaciones previas y (4) si una solicitud de cotización u OC puede ser creada con referencia al ítem.

El indicador de liberación de los documentos de compras externos determina lo siguiente: (1) si se puede cambiar el documento, (2) si se determina una nueva estrategia en los cambios, (3) si se cancelan las liberaciones previas y (4) si el documento de compras es transmitido.

La estrategia de liberación define los códigos de liberación que serán usados y el orden en el cual son dadas las aprobaciones. La imputación de la estrategia de liberación está basada en el criterio de liberación y se aplica a una SC / documento de compras externo.

El criterio de liberación especifica la estrategia de liberación a ser aplicada, lo que determina si un documento es bloqueado o no. Cuando un documento es creado cambiado, el sistema verifica si todos los criterios son satisfechos antes que el documentos sea bloqueado.

SPM y FM en ITIL V3

2009-02-02T04:24:00.000-08:00

Gestión de la Cartera de Servicios en ITIL V3

La SPM (Service Portfolio Management) es responsable de la cartera de servicios que está compuesta por: - Línea de Servicios (Service Pipeline): Servicios a ser desarrollados - Catálogo de Servicios (Service Catalogue): Servicios ofrecidos y consumidos por los Clientes - Servicios retirados (Retired Services)

La Cartera de Servicios está formada por servicios en cualquier etapa de suc ciclo de vida.

Los objetivos del SPM son: - Aplicar Prácticas comparables para Administrar las Carteras de Servicios - Maximizar el Valor mientras se gestionan los riesgos y costos

El valor para el negocio se determina por la prestación de un mejor servicio, y las experiencias del cliente; y comienza con la documentación de los servicios.

SPM permite: • Demostrar valor mediante la habilidad de anticipar los cambios • Mantener la trazabilidad hacia la estrategia y la planificación

SPM es un conjunto de procesos dinámico y continuo con los siguientes métodos de trabajo:

Definir: Inventario de servicios, asegurar el caso de Negocio y validar la información de la cartera

Analizar: Maximizar el valor de la cartera; alinear, priorizar y balancear la oferta con la demanda

Aprobar: Ultimar la cartera propuesta, autorizar los servicios y recursos Asignar: Comunicar las decisiones, asignar los recursos y preparar para desarrollar los servicios

• Definir

Establecer la cartera de Servicios, Recolectar datos de Servicios existentes y propuestos

• Analizar

Establecer el “Objetivo Estratégico”

Responder a las preguntas que determinan las salidas del SPM: ¿Cuáles son los objetivos a largo plazo de la Organización de Servicios? ¿Cuáles servicios son requeridos para alcanzar esos objetivos? ¿Qué Capacidades y Recursos son requeridas para alcanzar esos Servicios? ¿Cómo lo haremos?

• Aprobar

Finalizar y autorizar el plan para los nuevos Servicios y Recursos

• Asignar

Listar las acciones y decisiones de acuerdo a lo presupuestado - Comunicar de forma clara a la organización

• Actualizar

Concepto de Actualizar: cuando se están considerando revisiones del SPM Situaciones de cambios que invalidan los cálculos y conocimientos previos Cambios de regulaciones que hacen cambiar los requerimientos del Negocio y de los Servicios

Roles en SPM

Product Manager

• Gestiona los Servicios como un producto a lo largo del Ciclo de Vida • Coordina, está enfocado, y es dueño del Catálogo de Servicios • Trabaja junto a los Business Relationship Managers: Se focalizan en la Cartera de los Clientes • Es reconocido como la persona que conoce sobre las Líneas de Servicio • Evalúa nuevas oportunidades en el mercado, modelos operativos, tecnologías, y las nuevas necesidades de los clientes.

Gestión Financiera (Financial Management – FM)

‘La Gestión Financiera cuantifica el valor de los Servicios de TI, de los Activos que soportan la provisión de los Servicios, y las calificaciones de las proyecciones operacionales, en términos financieros’.

Objetivos del FM

Brinda al Negocio y a TI de las cuantificaciones:

- En términos financieros - Valor de los servicios de TI - Valor de los activos subyacentes que sirven para proveer los servicios - Calificaciones de las proyecciones operacionales

Trabaja junto con el Negocio y TI para:

- Identificar; - Documentar; - Acordar el valor de los Servicios recibidos; - Permitir un modelo de Gestión por Demanda

Aporta valor al negocio esforzándose en:

- Analizar, empaquetar, comercializar y entregar servicios - Entender y controlar factores relacionados con al oferta y la demanda - Proveer servicios a un costo razonable

Conceptos Básicos

La valuación del servicio es un Cálculo Financiero y asignación de un valor monetario requerido por el negocio y TI para la prestación de Servicios basados en el valor de los Servicios acordados.

Los Modelos de demanda anticipan el uso por parte del Negocio, y cómo soportará TI por medio de la Información financiera de la oferta y la demanda orientada a Servicios. El modelo identifica el costo total de utilización, predice implicaciones financieras de demanda futura del servicio e identifica requerimientos que pagan los servicios.

La Gestión de la Cartera de Servicios se usa para tomar decisiones si un servicio se debe proveer internamente.

La Optimización de la provisión de Servicios sirve para hacer servicios más competitivos en términos de costo o calidad.

La confianza en la Planificación provee una extrapolación financiera y la calificación de la demanda futura esperada, focalizándose en la variación de la oferta y la demanda.

El análisis de la inversión en servicios obtiene una indicación del valor para el Ciclo de Vida completo de un Servicio basado en

– El valor recibido – Los costos incurridos durante el ciclo de vida del servicio

La contabilidad permite identificación y seguimiento de los costos o inversiones de capital orientados a Servicios. Se obtiene un mejor rendimiento y detalle en cuanto a la provisión y consumo de servicios. Se genera información que será utilizada en los procesos de planificación.

Cumplimiento de Normas

Muestra que se emplean prácticas de contabilidad consistentes y apropiadas. Pueden usarse COBIT, ISO/IEC 20000, Basilea II (Requerimiento mínimo de capital, Revisiones de supervisores y disciplina del mercado).

El análisis de la dinámica de los costos variables se usa para identificar el cambio marginal en los costos por unidad resultante de agregar o restar una o más unidades incrementales a un servicio.

El proveedor analiza y comprende la medida de:

– Variables que impactan en el costo del Servicio – Sensibilidad de los elementos que varían y – Cambios incrementales en los elementos relacionados

Rol del IT Financial Manager

- Asiste para Identificar, documentar, y acordar el valor de los Servicios para el Negocio - Participa en las actividades de Modelo de la Demanda - Provee la información de costos para la Gestión de la Cartera de Servicios - Mantiene el cumplimiento de las regulaciones en lo que refiere a los temas financieros

ME21N en mySAP SCM

2009-02-02T04:22:00.000-08:00

La transacción ME21N de mySAP SCM permite crea órdenes de compra (OC), las cuales pueden o no tener una referencia. Los ítems de la OC con referencia hacen mención a OC, Solicitudes de Compra, Cotizaciones/Solicitudes de Cotización o Contratos. Si se tienen un proceso de abastecimiento con documentos precedentes a la OC, se creará una OC con referencia a estos documentos. Los documentos precedentes podrían ser los siguientes: Solicitud de Compra, Solicitud de Cotización o Contrato. En los documentos precedentes, los datos del ítem y del encabezado son copiados a partir del documento precedente a la OC. Las OC sin referencia tienen valores default.

La OC es una solicitud formal para un proveedor que suministra bienes o servicios en condiciones establecidas en la OC. La recepción de bienes y la factura se hacen en base a la OC. Se especifica si el material es entregado a stock o consumo directo.

Las áreas de la OC son: (1) Header, (2) Item overview, (3) Item Detail y (4) Documet overview. Algunos de los datos del encabezado son: número del documento, fecha de la OC, moneda, proveedor, término de pago y otros. Algunos de los datos del ítem son: número de material, cantidad, fecha de entrega, precio de la OC y otros. Para cada ítem, el sistema actualiza el documento y el número del ítem. El document overview permite ver o cambiar una SC u OC.

La inspección de calidad es considerada en el RMM, OC y material document.