mejorando procesos para proporcionar mejores servicios

CMMI® para Servicios, Versión 1.3

CMMI-SVC, V1.3

Equipo de Producto CMMI

Mejorando procesos para proporcionar mejores servicios

Noviembre 2013

INFORME TÉCNICO

TECHNICAL REPORT

CMMI Institute-2013-TR-001

CMMI Institute Unlimited distribution subject to the copyright

http://cmmiinstitute.com/

Copyright 2013 CMMI Institute

NO WARRANTY

THIS CMMI INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CMMI

INSTITUTE MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED,

AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR

PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF

THE MATERIAL. THE CMMI INSTITUTE DOES NOT MAKE ANY WARRANT OF ANY KIND

WITH RESPECT FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT

INFRINGEMENT.

TO THE MAXIMUM EXTENT ALLOWED BY LAW, EXCEPT AS EXPRESSLY SET FORTH IN

ANY SCHEDULE, ATTACHMENT, OR EXHIBIT, THE CMMI INSTITUTE SPECIFICALLY

DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY,

REGARDING OR RELATING TO THE STANDARD CMMI® APPRAISAL METHOD FOR

PROCESS IMPROVEMENT (SCAMPISM) A, B, AND C, VERSION 1.3a: METHOD DEFINITION

DOCUMENT, OR ANY MATERIALS OR SERVICES FURNISHED OR PROVIDED TO

COMPANY UNDER THIS AGREEMENT, INCLUDING ALL IMPLIED WARRANTIES OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE NONINFRINGEMENT,

USAGE OF TRADE, AND COURSE OF DEALING OR PERFORMANCE WITH RESPECT TO

THE STANDARD CMMI® APPRAISAL METHOD FOR PROCESS IMPROVEMENT

(SCAMPISM) A, B, AND C, VERSION 1.3a: METHOD DEFINITION DOCUMENT AND ANY

OTHER MATERIALS AND SERVICES WITH RESPECT TO THE USE OF ANY OF THE

FOREGOING

Use of any trademarks in this report is not intended in any way to infringe on the rights of the

trademark holder.

Internal use. Permission to reproduce this document and to prepare derivative works from this

document for internal use is granted, provided the copyright and “No Warranty” statements are

included with all reproductions and derivative works.

External use. This document may be reproduced in its entirety, without modification, and freely

distributed in written or electronic form without requesting formal permission. Permission is required

for any other external and/or commercial use. Requests for permission should be directed to the CMMI

Institute at [email protected].

CMMI para Servicios, Versión 1.3

Prefacio i

Prefacio

Los modelos CMMI® (Capability Maturity Model® Integration) son

colecciones de buenas prácticas que ayudan a las organizaciones a

mejorar sus procesos. Estos modelos son desarrollados por equipos de

producto con miembros procedentes de la industria, el gobierno, y el

Software Engineering Institute (SEI).

Este modelo, denominado CMMI para Servicios (CMMI-SVC), proporciona

un conjunto completo e integrado de guías para prestar mejores servicios.

Propósito

El modelo CMMI-SVC proporciona guías para aplicar las buenas prácticas

de CMMI en organizaciones proveedoras de servicios. Las buenas

prácticas del modelo se centran en las actividades para proveer servicios

de calidad a clientes y usuarios finales. CMMI-SVC integra conjuntos de

conocimientos que son esenciales para proveedores de servicios.

El modelo CMMI-SVC V1.3 es una colección de buenas prácticas de

servicios procedentes del gobierno y la industria que se ha generado a

partir de la Arquitectura y Marco1 CMMI V1.3. CMMI-SVC está basado en

las Bases del Modelo CMMI o CMF (esto es, componentes de modelo

comunes a todos los modelos y constelaciones CMMI2) e incorpora el

trabajo que realizaron organizaciones de servicios para adaptar CMMI a su

uso en el sector de servicios.

CMMI-SVC proporciona un conjunto completo de buenas prácticas para

prestar servicios. CMMI para Desarrollo (CMMI-DEV) puede utilizarse

como referencia para desarrollar el sistema de servicio, el cual da soporte a

la prestación de servicios [SEI 2010a]. En los casos en los que el sistema

de servicio sea grande y complejo, el modelo CMMI-DEV puede utilizarse

eficazmente para desarrollar dicho sistema (véase la definición de “sistema

de servicio” en el glosario).

1 El Marco CMMI es la estructura básica que organiza los componentes de CMMI y los combina en constelaciones y modelos

CMMI. 2 Una constelación es una colección de componentes de CMMI que se utilizan para construir modelos, materiales de

capacitación, y documentos relacionados con evaluaciones para un área de interés (p. ej., desarrollo, adquisición, servicios).


Prefacio ii

Reconocimientos

Muchas personas competentes han participado en el desarrollo del

Conjunto de Productos CMMI V1.3. Los tres grupos principales han sido el

Comité de Dirección de CMMI, el Equipo de Producto, y el Comité de

Control de Configuración (CCB).

El Comité de Dirección guio y aprobó los planes del Equipo de Producto,

asesoró en los problemas importantes del proyecto CMMI, y aseguró la

involucración de una diversidad de comunidades interesadas.

El Comité de Dirección supervisó el desarrollo de la constelación de

Servicios, reconociendo la importancia de proporcionar buenas prácticas a

los proveedores de servicios.

El Equipo de Producto escribió, revisó, actualizó, debatió y acordó la

estructura y el contenido técnico del Conjunto de Productos CMMI,

incluyendo los materiales del marco, de los modelos, de capacitación, y de

evaluación. Las actividades de desarrollo se basaron en varias entradas.

Estas entradas incluyeron una “Especificación-A” y unas guías específicas

para cada entrega que proporcionó el Comité de Dirección, los modelos

fuente, las peticiones de cambio recibidas de la comunidad de usuarios, y

las aportaciones recibidas de pilotos y otras partes interesadas.

El CCB es el mecanismo oficial para controlar los cambios a los modelos

CMMI, los documentos relacionados con evaluaciones, y la capacitación

“Introducción a CMMI”. Como tal, este grupo asegura la integridad del

conjunto de productos a lo largo de su vida, por medio de revisar todos los

cambios propuestos a la línea base y aprobar únicamente aquellos que

resuelvan problemas identificados y cumplan los criterios de la siguiente

entrega.

En el Apéndice C se encuentra el listado de los miembros de los grupos

involucrados en el desarrollo de CMMI-SVC V1.3.

Audiencia

La audiencia de CMMI-SVC incluye a cualquiera interesado en la mejora

de procesos en el entorno de un proveedor de servicios. Tanto si está

familiarizado con el concepto de Modelos de Capacidad y Madurez como si

busca información para comenzar a mejorar sus procesos de servicio,

CMMI-SVC le será útil. Este modelo también está previsto para

organizaciones que quieran usar un modelo de referencia para evaluar sus

procesos de servicio3.

3 Una evaluación es un examen de uno o más procesos realizada por un equipo de profesionales capacitados utilizando un

modelo de referencia (p. ej., CMMI-SVC) como base para determinar fortalezas y debilidades.


Prefacio iii

Organización de este documento

Este documento está organizado en tres partes principales:

Primera Parte: Acerca de CMMI para Servicios.

Segunda Parte: Metas Genéricas y Prácticas Genéricas, y las Áreas de

Proceso.

Tercera Parte: Apéndices y Glosario.

Primera Parte: Acerca de CMMI para Servicios, comprende cinco capítulos:

Capítulo 1, Introducción, ofrece una visión amplia de CMMI y de la

constelación de Servicios, los conceptos de mejora de procesos, y la

historia de los modelos utilizados para la mejora de procesos y distintos

enfoques para la mejora de procesos.

Capítulo 2, Componentes del Área de Proceso, describe todos los

componentes de las áreas de proceso de CMMI-SVC4.

Capítulo 3, Uniéndolo Todo, ensambla los componentes del modelo,

explica los conceptos de niveles de madurez y niveles de capacidad, y

expone conceptos importantes sobre servicios.

Capítulo 4, Relaciones entre Áreas de Proceso, explica el significado e

interacciones entre las áreas de proceso de CMMI-SVC.

Capítulo 5, Utilizando los Modelos CMMI, describe vías de adopción y

uso de CMMI-SVC para la mejora de procesos y la comparativa de

prácticas en organizaciones proveedoras de servicios.

Segunda Parte: Metas Genéricas y Prácticas Genéricas y las Áreas de

Proceso, contiene todos estos componentes de modelo CMMI requeridos y

esperados. También contiene componentes informativos relacionados,

incluyendo subprácticas, notas, ejemplos, y ejemplos de productos de

trabajo.

La Segunda Parte contiene 25 secciones. La primera sección contiene las

metas y prácticas genéricas. Las restantes 24 secciones se corresponden

con cada una de las áreas de proceso de CMMI-SVC.

Para facilitar la búsqueda de áreas de proceso, se han organizado

alfabéticamente por sus acrónimos en inglés. Cada sección contiene

descripciones de metas, buenas prácticas, y ejemplos.

Tercera Parte: Apéndices y Glosario, comprende cuatro secciones:

Apéndice A: Referencias, contiene referencias que se pueden utilizar

para localizar fuentes de información documentadas, tales como

informes, modelos de mejora de procesos, estándares de la industria, y

libros relacionados con CMMI-SVC.

Apéndice B: Acrónimos, define los acrónimos utilizados en el modelo.

4 Un área de proceso es un conjunto de prácticas relacionadas en un área que, cuando se implementan conjuntamente,

satisfacen un conjunto de metas consideradas importantes para lograr una mejora en esa área. Este concepto se desarrolla

en detalle en el Capítulo 2.


Prefacio iv

Apéndice C: Participantes en el Proyecto CMMI Versión 1.3, contiene

las listas de los miembros de los equipos que han participado en el

desarrollo de CMMI-SVC V1.3.

Apéndice D: Glosario, define muchos de los términos utilizados en

CMMI-SVC.

Cómo utilizar este documento

Tanto si se está iniciando en la mejora de procesos o en CMMI, como si ya

está familiarizado con CMMI, la Primera Parte puede ayudarle a entender

por qué CMMI-SVC es el modelo a utilizar para mejorar sus procesos de

servicio.

Lectores que se inician en la mejora de procesos

Si se está iniciando en la mejora de procesos o en el concepto de Modelo

de Capacidad y Madurez (CMM®), sugerimos que lea primero el Capítulo 1.

El Capítulo 1 contiene una visión general de la mejora de procesos que

explica de qué trata CMMI.

A continuación, ojee la Segunda Parte, que incluye las metas y prácticas

genéricas, y las metas y prácticas específicas, para hacerse una idea del

alcance de las buenas prácticas que contiene el modelo. Preste especial

atención al propósito y a las notas introductorias al comienzo de cada área

de proceso.

En la Tercera Parte, consulte las referencias del apéndice A y seleccione

fuentes adicionales cuya lectura considere que pueda ser beneficiosa antes

de seguir adelante con el uso de CMMI-SVC. Lea los acrónimos y el

glosario para familiarizarse con la terminología de CMMI. Finalmente,

vuelva y lea los detalles de la Segunda Parte.

Lectores con experiencia en mejora de procesos

Si se está iniciando en CMMI, pero tiene experiencia con otros modelos de

mejora de procesos, tales como CMM Software o International

Organization for Standardization (ISO) 9001, reconocerá inmediatamente

numerosas similitudes en sus estructuras y contenidos [ISO 2008c].

Recomendamos que lea la Primera Parte para entender lo que distingue a

CMMI de otros modelos de mejora de procesos. Si tiene experiencia con

otros modelos, puede que quiera seleccionar qué secciones leer primero.

Lea la Segunda Parte prestando atención a las buenas prácticas que

pueda reconocer de otros modelos que ya haya utilizado. Identificar

material con el que esté familiarizado le permitirá entender qué es nuevo,

qué se mantiene, y qué le resulta familiar de los otros modelos que ya

conoce.

A continuación, revise el glosario para entender las diferencias de

terminología que pudiera haber respecto a los modelos de mejora de

procesos que conoce. Muchos conceptos se repiten, pero pueden llamarse

de forma distinta.


Prefacio v

Lectores familiarizados con CMMI

Si ha consultado o utilizado antes algún modelo CMMI, reconocerá

rápidamente los conceptos tratados y las buenas prácticas expuestas.

Como siempre, las mejoras que el Equipo de Producto CMMI ha realizado

a la versión 1.3 de CMMI estuvieron guiadas por las aportaciones de los

usuarios. Las peticiones de cambio se consideraron, analizaron, e

implementaron minuciosamente.

Algunas mejoras significativas que puede encontrar en CMMI-SVC V1.3

son:

Las áreas de proceso de alta madurez se han mejorado

significativamente para reflejar buenas prácticas de la industria,

incluyendo una nueva meta específica y varias nuevas prácticas

específicas en el área de proceso que cambió su nombre de

Innovación y Despliegue Organizativos (OID) a Gestión del

Rendimiento Organizativo (OPM).

Se hicieron mejoras en la arquitectura del modelo que simplifican el uso

de múltiples modelos.

El área de proceso Resolución y Prevención de Incidencias (IRP) se

reorganizó y clarificó

Las definiciones del glosario y la terminología del modelo se mejoraron

para aumentar la claridad, precisión, y usabilidad del modelo,

incluyendo la sustitución de “proyecto” por términos más significativos

para servicios, tales como “trabajo” o “grupo de trabajo”.

Se eliminaron las metas y prácticas genéricas de los niveles 4 y 5 así

como los niveles de capacidad 4 y 5 para centrar apropiadamente la

alta madurez en el logro de objetivos de negocio, lo cual se consigue

aplicando los niveles de capacidad 1-3 a las áreas de proceso de alta

madurez (Análisis Causal y Resolución, Gestión Cuantitativa de

Trabajos, Gestión del Rendimiento Organizativo, y Rendimiento

Organizativo de Procesos).

Para una lista más completa y detallada de las mejoras, véase

http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/.

Información adicional y sugerencias del lector

El Apéndice A contiene una lista con muchas fuentes de información

acerca de CMMI que también están publicadas en el sitio web de CMMI –

http://www.sei.cmu.edu/cmmi/.

Cualquier sugerencia para mejorar CMMI será bien recibida. Para más

información sobre cómo proponer sugerencias, vaya al sitio web de CMMI

en http://www.sei.cmu.edu/cmmi/tools/cr/. Si tiene alguna pregunta acerca

de CMMI, envíe un correo electrónico a cmmi-comments@ sei.cmu.edu.


Sobre la Versión en Español i

Sobre la Versión en Español

El proyecto de traducción del modelo CMMI para Servicios surgió durante la presentación de la

traducción del modelo CMMI para Desarrollo al español, que se celebró el 4 de junio de 2012 en las

instalaciones de la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información del

Ministerio de Industria, Energía y Turismo de España. En el acto de presentación, Eileen Forrester

(Gerente de Producto de CMMI) solicitó la colaboración de los asistentes para continuar la labor y

traducir CMMI para Servicios.

Aprovechando la gran cantidad de texto que es común a ambos modelos, desde un principio se pensó

en un equipo reducido que, entre otras cosas, ayudaría a mejorar la consistencia del resultado final. Este

equipo ha estado compuesto por:

- Autora: Eileen Forrester (CMMI Institute)

- Traductor: Ricardo Panero Lamothe (Efyca Quality Consulting)

- Revisor: José María Álvarez Palomo (Universidad de Málaga)

- Verificador: Giuseppe Magnani (Business Strategy)

Partiendo del trabajo realizado por el equipo de traducción de CMMI para Desarrollo, liderado por la

Cátedra de Mejora de Procesos de la Universidad Politécnica de Madrid, el equipo de traducción de

CMMI para Servicios ha realizado un trabajo que consta de tres partes bien diferenciadas: traducir las

áreas de proceso específicas de CMMI para Servicios, completar las adaptaciones específicas de CMMI

para Servicios en el resto del modelo, y realizar cambios y mejoras al texto proveniente de la traducción

de CMMI para Desarrollo.

Entre los cambios más importantes que hay entre el texto original en inglés de CMMI para Desarrollo y

el de CMMI para Servicios destaca la sustitución de “project” (proyecto) por “work” (trabajo) o “work

group” (grupo de trabajo). Para evitar ambigüedades, las áreas de proceso PP-WP, PMC-WMC, IPM-

IWM, y QPM-QWM se han traducido en plural. Por ejemplo, “Planificación del Proyecto” ha pasado a

traducirse como “Planificación de Trabajos” para hacer explícito que no se trata de planificar el trabajo

en general, sino de planificar cada uno de los trabajos (o proyectos en CMMI para Desarrollo) que

aborda la organización.

Algunos cambios significativos con respecto a la traducción de CMMI para Desarrollo son el uso del

término “organizativo” en lugar de “de la organización” para distinguir “organizational” de

“organization’s” con el fin de evitar la ambigüedad; el uso del término “suministrador” en lugar de

“proveedor” con objeto de distinguir claramente “supplier” de “provider”; el uso del término

“problema” en lugar de “cuestión” para traducir “issue”; y el uso del término “capacitación” en lugar de

“formación” para traducir “training”.


Sobre la Versión en Español ii

Agradecimientos

La traducción de CMMI para Servicios al castellano no hubiera sido posible sin la ayuda de muchas

personas que han contribuido de uno u otro modo a este proyecto.

En primer lugar queremos agradecer al equipo de traducción de CMMI para Desarrollo, liderado

por Gonzalo Cuevas, José A. Calvo-Manzano, y Tomás San Feliu, cuyo trabajo ha servido de base

para todos los textos que hay en común entre CMMI para Desarrollo y CMMI para Servicios.

Mike Konrad (SEI) y Manuel Díaz Rodríguez (Universidad de Málaga) jugaron un papel

importante al inicio del proyecto en la decisión de llevarlo a cabo.

Lisa S. Huckfield (Universidad de Málaga) ayudó a interpretar algunos de los términos en inglés

que tenían mayor dificultad.

Joaquín Pablo Barrera Nielsen y el equipo PQS de AtoS SI participaron en la validación del texto

traducido identificando problemas en el primer borrador del texto completo.

Deen Blash (CMMI Institute) ayudo en la comunicación y en la identificación e involucración de

algunas partes interesadas.

Sandra Cepeda y Martha Cepeda (Cepeda Systems & Software Analysis, Inc.) y Jorge Ruiz

(EnevaSys) participaron en las tareas de validación aportando su punto de vista sobre algunos

términos a fin de posibilitar que el texto se entienda mejor en los países americanos de habla

hispana.

Ulises Arranz (Accenture), Francisco Santos (Everis) y Sonia de la Fuente (Mnemo) dieron su

apoyo al proyecto de distintas maneras.

Ramiro Carballo (Caelum) y Katie Tarara (CMMI Institute) ayudaron a difundir el resultado y a

organizar la presentación oficial de esta traducción en Madrid.

Por último, pero no por ello menos importante, queremos agradecer a nuestras familias el

tiempo que no les hemos podido dedicar y la paciencia que han tenido con nosotros durante

todos estos meses.

Equipo de traducción CMMI para Servicios v1.3 Noviembre de 2013


Sobre la Versión en Español iii

Patrocinadores

Efyca Quality Consulting

Efyca Quality Consulting es una compañía especializada en alta

madurez de CMMI y su misión es optimizar la eficiencia y la calidad

por medio del uso de buenas prácticas de la industria, incluyendo

CMMI, Lean manufacturing, Six sigma, ToC, y PMBoK.

El objetivo de Efyca al patrocinar este trabajo es ayudar a difundir las buenas prácticas de CMMI para

Servicios a los usuarios de habla hispana, de tal forma que puedan utilizar esta traducción como base

para obtener mejores resultados en sus labores de mejora de procesos.

Para Efyca la calidad va mucho más allá de conseguir un certificado que poder mostrar a los clientes. La

calidad está vinculada a la eficiencia porque la calidad de un producto está fuertemente influenciada por

el proceso que se utiliza para producirlo, por lo que mejorar la eficiencia del proceso también redunda

en una mejora de la calidad.

Tanto es así que la propia labor de traducción ha estado apoyada en muchas de las prácticas de CMMI

que han ayudado a optimizar la eficiencia y la calidad del resultado. Entre otras, éstas se han utilizado

para definir el proceso de traducción (IWM), descomponer el texto, estimar el trabajo y planificarlo

(QWM, WP), definir la estrategia de integración (PI), medir el esfuerzo (más de 500 horas) y la

productividad, y monitorizar y controlar el trabajo (MA, WMC), gestionar las versiones del texto y los

cambios en el diccionario de términos (CM, REQM), decidir sobre qué texto de CMMI-DEV se reutiliza y

cuál se traduce de nuevo (TS), y verificar y validar el resultado (VER, VAL).

Para más información sobre Efyca puede consultar la página www.efyca.com. Adicionalmente, si tiene

alguna sugerencia para mejorar esta traducción puede enivar un correo a [email protected].


Sobre la Versión en Español iv

Universidad de Málaga

El Departamento de Lenguajes y Ciencias de la Computación de la Universidad de

Málaga se fundó en el año 1989 tras la división del Departamento de Informática

que existió hasta aquel año. Desde entonces el departamento ha experimentado un

crecimiento constante hasta contar actualmente con más de 90 profesores en sus

diferentes categorías, 25 investigadores en formación y más 50 personas

contratadas en proyectos de investigación y de transferencias tecnológica.

En la actualidad el Departamento de Lenguajes y Ciencias de la Computación es un departamento de un

gran tamaño que comprende tres áreas de conocimiento, Lenguajes y Sistemas Informáticos, Ciencias de

la Computación e Ingeniería Telemática y desarrolla una actividad intensa en múltiples campos, la

docencia, la investigación y la transferencia de tecnología al mundo empresarial.

El Departamento y se encarga de la docencia de la mayor parte de las asignaturas relacionadas con la

Informática de la Universidad de Málaga tanto en titulaciones de Grado como en programas de Máster,

incluyendo varias asignaturas en inglés en los grados de Ingeniería Informática.

Dentro del Departamento existen 5 grupos de investigación, de los cuales GISUM (Grupo de Ingeniería

del Software de la Universidad de Málaga) se centra en aspecto

s relacionados con la Ingeniería del Software en múltiples aspectos, desde métodos formales a

metodologías y entornos de desarrollo. Su trabajo está avalado por numerosas publicaciones en revistas

y congresos científicos de reconocido prestigio tanto nacionales como internacionales.

Tecnocom

Tecnocom es una multinacional del sector TIC que cotiza en la bolsa

de Madrid del año 1987 y con más de 6000 empleados, está entre las

más grandes compañías TIC del mercado Español, con una fuerte

presencia regional que incluye tanto España, Portugal como Latino América. Tecnocom pertenece a la

Getronics Workspace Alliance, que abarcar los mercados europeos, americanos y asiáticos y da servicio

en activos de TI a más de 6 millones de usuarios a nivel mundial.

Tecnocom cuenta entre sus clientes a las principales compañías del sector financiero, igualmente da

servicios a importante unidades del Gobierno y a la mayoría de las empresas del IBEX 35.

Tecnocom ofrece una amplia variedad de servicios y soluciones avanzadas, a lo largo de todo el espectro

de los servicio TIC. De hecho, Tecnocom es líder mundial en soluciones de medios de pago y sistemas

bancarios, contando en la actualidad con servicios que gestionan más de 90 millones de tarjetas de

crédito en Europa (España, Inglaterra, Irlanda y Portugal) y LatinoAmerica.


Sobre la Versión en Español v

Tecnocom es de los proveedores más importantes en servicios de Outsourcing en el mercado español,

disponiendo de una amplísima experiencia en servicios de gestión de aplicación, gestión de

infraestructuras y BPO’s, gracias a su estrategia de Centros de Delivery y Centros de Excelencia ubicados

en España, Portugal, México, Colombia, Perú, Chile y Paraguay. Nuestro modelo de centros tienen un

enfoque Nearshore y gestionado a través de modelos certificados en CMMi5 constelación de Desarrollo

y Servicios.

Accenture

Accenture es una compañía global de consultoría de gestión, servicios

tecnológicos y outsourcing, que cuenta con más de 275.000

profesionales trabajando en más de 200 ciudades en 56 países y

sirviendo clientes de más de 120 países. Combinando su experiencia,

sus capacidades en todos los sectores y áreas de negocio, y su investigación con las compañías de más

éxito del mundo, Accenture colabora con sus clientes para ayudarles a convertir sus organizaciones en

negocios y administraciones públicas de alto rendimiento.

Coritel, líder en gestión de soluciones tecnológicas, es la compañía del

grupo Accenture en España especializada en servicios de desarrollo y

mantenimiento de aplicaciones, desde su fundación en 1984. Su

Centro de Desarrollo en España, creado en 1992, cuenta con más de 1300 profesionales en Barcelona,

Bilbao, Madrid, Málaga, Sevilla, Valencia y Zaragoza, y es una referencia nacional y mundial en CMMI

desde 2003, cuando fue la primera organización en obtener CMM L5 en España, siendo desde entonces

pionera en las renovaciones periódicas de acuerdo a las diversas evoluciones del modelo, mostrando su

alta madurez como organización de servicios tecnológicos. Este viaje de mejora continua está

produciendo resultados tangibles en cuanto a mejora de productividad, competitividad y eficiencia en el

desarrollo de proyectos y servicios, creando una estructura y cultura de pensamiento sistémico y

estadístico, para conseguir los objetivos de sus clientes mejorando el rendimiento de los servicios. Los

más de 20 años de experiencia del Centro, su alta madurez, la total integración cultural con la mejora de

rendimiento de procesos, acelerada con CMMI y Lean Six Sigma, posiciona al centro en la aportación de

valor diferencial a los clientes de Accenture en España y en Europa.

El grupo Accenture colabora estrechamente con el CMMI Institute (y antes con el Software Engineering

Institute) en las distintas versiones del modelo en español, a través de sus equipos de Delivery

Excellence. Para más información, www.accenture.es y www.coritel.es


Contenidos vi

Contenidos

Prefacio i

Propósito i

Reconocimientos ii

Audiencia ii

Organización de este documento iii

Cómo utilizar este documento iv

Lectores que se inician en la mejora de procesos iv

Lectores con experiencia en mejora de procesos iv

Lectores familiarizados con CMMI v

Información adicional y sugerencias del lector v

Sobre la Versión en Español i

Agradecimientos ii

Patrocinadores iii

Efyca Quality Consulting iii

Universidad de Málaga iv

Tecnocom iv

Accenture v

Primera Parte: Acerca de CMMI para Servicios 1

1 Introducción 2

Acerca de la mejora de procesos 2

Acerca de los Modelos de Capacidad y Madurez 3

Evolución de CMMI 5

Marco CMMI 6

CMMI para Servicios 7

2 Componentes del Área de Proceso 9

Áreas de proceso esenciales y modelos CMMI 9

Componentes requeridos, esperados, e informativos 9

Componentes requeridos 9

Componentes esperados 9

Componentes informativos 10

Componentes asociados a la Segunda Parte 10

Áreas de proceso 11

Declaraciones de propósito 11

Notas introductorias 12

Áreas de proceso relacionadas 12

Metas específicas 12

Metas genéricas 12

Resúmenes de metas y prácticas específicas 13


Contenidos vii

Prácticas específicas 13

Ejemplos de productos de trabajo 13

Subprácticas 13

Prácticas genéricas 14

Elaboraciones de prácticas genéricas 14

Extensiones 14

Componentes informativos de soporte 15

Notas 15

Ejemplos 15

Referencias 16

Esquema de numeración 16

Convenciones tipográficas 16

3 Uniéndolo Todo 20

Entendiendo los niveles 20

Estructura de las representaciones continua y por etapas 21

Entendiendo los niveles de capacidad 24

Nivel de capacidad 0: Incompleto 24

Nivel de capacidad 1: Realizado 24

Nivel de capacidad 2: Gestionado 24

Nivel de capacidad 3: Definido 25

Avanzando a través de los niveles de capacidad 25

Entendiendo los niveles de madurez 26

Nivel de madurez 1: Inicial 27

Nivel de madurez 2: Gestionado 27

Nivel de madurez 3: Definido 28

Nivel de madurez 4: Gestionado cuantitativamente 29

Nivel de madurez 5: En optimización 29

Avanzando a través de niveles de madurez 30

Áreas de proceso 32

Representación equivalente 35

Logrando la alta madurez 39

Entendiendo los conceptos clave en el uso de CMMI para Servicios 39

Servicio 39

Sistema de servicio 40

Acuerdo de servicio 42

Petición de servicio 42

Incidencia en el servicio 43

Proyecto, grupo de trabajo, y trabajo 45

4 Relaciones entre Áreas de Proceso 48

Relaciones que rigen Establecimiento y Prestación de Servicios 50

Relaciones que rigen Gestión de Servicios 50

5 Utilizando los Modelos CMMI 52

Adoptando CMMI 52

Su programa de mejora de procesos 53

Selecciones que influyen en su programa 53


Contenidos viii

Modelos CMMI 54

Utilizando las evaluaciones CMMI 55

Requisitos de evaluaciones CMMI 55

Métodos de evaluación SCAMPI 56

Consideraciones sobre evaluaciones 56

Capacitación sobre CMMI 57

Segunda Parte: Metas Genéricas y Prácticas Genéricas y las Áreas de Proceso 59

Metas Genéricas y Prácticas Genéricas 60

Visión general 60

Institucionalización de procesos 60

Proceso Realizado 60

Proceso Gestionado 61

Proceso Definido 61

Relaciones entre procesos 62

Metas genéricas y prácticas genéricas 63

GG 1 Lograr las metas específicas 63

GG 2 Institucionalizar un proceso gestionado 64

GG 3 Institucionalizar un proceso definido 118

Aplicación de las prácticas genéricas 125

Áreas de proceso que dan soporte a las prácticas genéricas 125

Gestión de Capacidad y Disponibilidad 132

Análisis Causal y Resolución 149

Gestión de Configuración 158

Análisis de Decisiones y Resolución 170

Resolución y Prevención de Incidencias 179

Gestión Integrada de Trabajos 196

Medición y Análisis 215

Definición Organizativa de Procesos 232

Enfoque Organizativo en Procesos 245

Gestión del Rendimiento Organizativo 259

Rendimiento Organizativo de Procesos 277

Capacitación Organizativa 290

Aseguramiento de Calidad de Procesos y Productos 301

Gestión Cuantitativa de Trabajos 308

Gestión de Requisitos 328

Gestión de Riesgos 335

Gestión de Acuerdos De Suministro 350


Contenidos ix

Continuidad del Servicio 363

Prestación de Servicios 377

Desarrollo del Sistema de Servicio 397

Transición del Sistema de Servicio 425

Gestión Estratégica de Servicios 436

Monitorización y Control de Trabajos 446

Planificación de Trabajos 456

Apéndices 481

Apéndice A: Referencias 482

Fuentes relacionadas con Aseguramiento/Seguridad de la Información 486

Apéndice B: Acrónimos 488

Apéndice C: Participantes en el Proyecto CMMI Versión 1.3 493

Comité de Dirección de CMMI 493

Miembros del Comité de Dirección 493

Miembros Ex-Oficio del Comité de Dirección 494

Soporte al Comité de Dirección 494

Grupo Asesor de CMMI para Servicios 494

Equipo de Coorinación de CMMI V1.3 495

Comité de Control de Configuración de CMMI V1.3 495

Equipo del Núcleo del Modelo CMMI V1.3 496

Equipo de Traducción de CMMI V1.3 496

Equipo de Alta Madurez de CMMI V1.3 497

Mini Equipo de Adquisiciones de CMMI V1.3 497

Mini Equipo de Servicios de CMMI V1.3 497

Equipo de Actualización de SCAMPI de CMMI v1.3 498

Equipos de Capacitación de CMMI V1.3 498

Equipo de capacitación sobre ACQ y DEV 498

Equipo de Capacitación sobre SVC 499

Equipo de Calidad de CMMI V1.3 499

Apéndice D: Glosario 500


1

Primera Parte: Acerca de CMMI para Servicios


Introducción 2

1 Introducción

El sector de servicios contribuye significativamente al crecimiento

económico mundial. Guiar el desarrollo y la mejora de madurez de las

prácticas de servicios contribuye de forma clave al desempeño de los

proveedores de servicios y a la satisfacción de clientes. El modelo CMMI®

para Servicios (CMMI-SVC) se ha diseñado para empezar a cubrir esa

necesidad.

CMMI-SVC contiene 24 áreas de proceso. De esas áreas de proceso, 16

son áreas de proceso esenciales, 1 es un área de proceso compartida, y 7

son áreas de proceso específicas de servicios que incluyen 1 extensión

(véase el Capítulo 2 para más información sobre extensiones)5.

Todas las prácticas de CMMI-SVC se centran en actividades del proveedor

de servicios. Siete áreas de proceso se centran en prácticas específicas de

servicios, abordando los procesos para la gestión de capacidad y

disponibilidad, continuidad del servicio, prestación de servicios, resolución

y prevención de incidencias, transición del servicio, desarrollo del sistema

de servicio, y gestión estratégica de servicios.

Acerca de la mejora de procesos

Investigando cómo ayudar a que las organizaciones desarrollen y

mantengan productos y servicios de calidad, el Software Engineering

Institute (SEI) ha identificado varias dimensiones en las que una

organización puede centrarse para mejorar su actividad. La Figura 1.1

ilustra las tres dimensiones críticas en las que las organizaciones

habitualmente se centran: las personas, los procedimientos y métodos, y

las herramientas y equipos.

5 Un área de proceso esencial es un área de proceso que está presente en todos los modelos CMMI. Un área de proceso

compartida está presente en al menos dos modelos CMMI, pero no en todos.


Introducción 3

Figura 1.1: Las tres dimensiones críticas

¿Qué es lo que mantiene todo unido? Son los procesos que se utilizan en

su organización. Los procesos le permiten alinear la forma en que realiza

su actividad. Le permiten abordar la escalabilidad y le proporcionan una

manera de incorporar conocimientos acerca de cómo hacer las cosas

mejor. Los procesos le permiten aprovechar sus recursos y analizar las

tendencias de su actividad.

Esto no quiere decir que las personas y la tecnología no sean importantes.

Vivimos en un mundo donde la tecnología cambia a una velocidad

increíble. Del mismo modo, habitualmente las personas trabajan para

varias compañías a lo largo de su vida profesional. Vivimos en un mundo

dinámico. Enfocarse en procesos proporciona la infraestructura y

estabilidad necesarias para hacer frente a un mundo siempre cambiante y

maximizar la productividad de las personas y el uso de la tecnología para

ser competitivos.

La fabricación reconoció hace mucho la importancia que tienen la eficacia y

eficiencia de los procesos. Hoy en día, muchas organizaciones en los

sectores de la fabricación y los servicios reconocen la importancia de tener

procesos de calidad. Los procesos ayudan a los miembros de la

organización a cumplir objetivos de negocio, facilitándoles trabajar de

forma más inteligente, no más dura, y de un modo más consistente. Los

procesos eficaces también proporcionan un medio para introducir y utilizar

nuevas tecnologías de una forma que permita cumplir mejor los objetivos

de negocio de la organización.

Acerca de los Modelos de Capacidad y Madurez

Un Modelo de Capacidad y Madurez (Capability Maturity Model®, CMM

®),

incluyendo CMMI, es una representación simplificada de la realidad. Los

CMMs contienen los elementos esenciales de los procesos eficaces. Estos


Introducción 4

elementos se basan en los conceptos desarrollados por Crosby, Deming,

Juran y Humphrey.

En la década de 1930, Walter Shewhart comenzó a trabajar en la mejora

de procesos con sus principios de control estadístico de la calidad

[Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming

[Deming 1986], Phillip Crosby [Crosby 1979] y Joseph Juran [Juran 1988].

Watts Humphrey, Ron Radice y otros los ampliaron y comenzaron a

aplicarlos al software en su trabajo para IBM (International Business

Machines) y en el SEI [Humphrey 1989]. El libro de Humphrey, Managing

the Software Process6, proporciona una descripción de los principios

básicos y conceptos en los que están basados muchos de los Modelos de

Capacidad y Madurez (CMMs®).

A partir de la premisa de la gestión de procesos, “la calidad de un sistema

o un producto está altamente influenciada por la calidad del proceso

empleado para desarrollarlo y mantenerlo”, el SEI ha definido CMMs que

materializan esta premisa. La convicción en esta premisa se ha observado

en los movimientos de calidad de todo el mundo, como se puede

evidenciar por el conjunto de estándares de la International Organization

for Standardization/International Electrotechnical Commission7 (ISO/IEC).

Los CMMs se centran en mejorar los procesos en una organización.

Contienen elementos esenciales para la eficacia de los procesos en una o

más disciplinas, y describen un camino evolutivo de mejora desde

procesos ad hoc e inmaduros a procesos disciplinados y maduros con

calidad y eficacia mejoradas.

Al igual que otros CMMs, los modelos CMMI proporcionan una guía de uso

para desarrollar procesos. Los modelos CMMI no son procesos ni

descripciones de proceso. Los procesos reales utilizados en una

organización dependen de muchos factores, incluyendo dominios de

aplicación y estructura y tamaño de la organización. En concreto, es

habitual que no haya una correspondencia biunívoca entre las áreas de

proceso de un modelo CMMI y los procesos que se utilicen en su

organización.

El SEI creó el primer CMM concebido para organizaciones de software y lo

publicó en el libro, The Capability Maturity Model: Guidelines for Improving

the Software Process8 [SEI 1995].

Hoy en día, CMMI es una aplicación de los principios introducidos hace

casi un siglo a este ciclo interminable de mejora de procesos. El valor de

este enfoque de mejora de procesos se ha confirmado a lo largo del

tiempo. Las organizaciones han experimentado un aumento de la

productividad y calidad, una mejora del tiempo de ciclo, y unos plazos y

presupuestos más precisos y predecibles [Gibson 2006].

6 Gestionando el Proceso de Software (N. del T.)

7 Organización Internacional de la Normalización/Comisión Electrotécnica Internacional (N del T.)

8 El Modelo de Capacidad y Madurez: Guías para Mejorar los Procesos de Software (N. del T.)


Introducción 5

Evolución de CMMI

El proyecto de Integración de CMM® se constituyó para resolver el

problema de usar varios CMMs. La combinación de modelos seleccionados

en un marco de mejora único estaba prevista para ser utilizada por

organizaciones que buscaran la mejora de procesos a nivel empresarial.

Desarrollar un conjunto de modelos integrados supuso más que la simple

combinación de los materiales de los modelos existentes. Utilizando

procesos que fomentan el consenso, el Equipo del Producto de CMMI creó

un marco que da cabida a varias constelaciones.

El primer modelo a desarrollar fue CMMI para Desarrollo (entonces

denominado simplemente “CMMI”). La Figura 1.2 ilustra los modelos que

condujeron a la versión 1.3 de CMMI.

Figura 1.2: Historia de los CMMs9

Inicialmente, CMMI fue un modelo que combinaba tres modelos fuente:

Capability Maturity Model for Software (SW-CMM) v2.0 draft C, Systems

Engineering Capability Model (SECM) [EIA 2002a], e Integrated Product

Development Capability Maturity Model (IPD-CMM) v0.98.

9 EIA 731 SECM es el estándar 731 de la “Electronic Industries Alliance”, o el Systems Engineering Capability Model. INCOSE

SECAM es el Modelo de Evaluación de Capacidad de Ingeniería de Sistemas del International Council on Systems

Engineering [EIA 2002a].


Introducción 6

Estos tres modelos fuente se seleccionaron por su exitosa adopción o su

prometedor enfoque para mejorar los procesos de una organización.

El primer modelo CMMI (V1.02) se diseñó para ser utilizado por

organizaciones de desarrollo que buscaran la mejora de procesos a nivel

empresarial. Se liberó en el año 2000. Dos años más tarde, se liberó la

versión 1.1, y cuatro años después se de esto se liberó la versión 1.2.

En el tiempo en que se liberó la versión 1.2, se estaban planificando otros

dos modelos CMMI. Debido a esta expansión planeada, el nombre del

primer modelo CMMI tuvo que cambiarse y pasar a ser CMMI para

Desarrollo, y el concepto de constelaciones fue creado.

El modelo CMMI para Adquisición se liberó en 2007. Como fue elaborado a

partir del modelo CMMI para Desarrollo Versión 1.2, también se designó

con la Versión 1.2. Dos años más tarde se liberó el modelo CMMI para

Servicios. Fue construido sobre los otros dos modelos, así que también se

designó con la Versión 1.2.

En 2008 se realizaron planes para comenzar a desarrollar la Versión 1.3,

que aseguraría la consistencia entre los tres modelos y mejoraría el

material de alta madurez. Las versiones 1.3 de CMMI para Adquisición

[Gallagher 2011, SEI 2010b], CMMI para Desarrollo [Chrissis 2011] y CMMI

para Servicios [Forrester 2011, SEI 2010a] se liberaron en noviembre de

2010.

Marco CMMI

El Marco CMMI proporciona la estructura necesaria para crear modelos,

capacitación, y componentes de evaluación CMMI. Para posibilitar el uso

de varios modelos dentro del Marco CMMI, los componentes de modelo se

clasifican como comunes a todos los modelos CMMI o aplicables a un

modelo específico. El material común se llama “Bases del Modelo CMMI”10

o “CMF”.

Los componentes del CMF forman parte de todos los modelos generados a

partir del Marco CMMI. Dichos componentes se combinan con material

aplicable a un área de interés (p. ej., adquisición, desarrollo, servicios) para

producir un modelo.

Una “constelación” se define como una colección de componentes de

CMMI que se utilizan para construir modelos, materiales de capacitación, y

documentos relacionados con evaluaciones para un área de interés (p. ej.

adquisición, desarrollo, servicios). El modelo de la constelación de

Servicios se denomina “CMMI para Servicios” o “CMMI-SVC”.

10

CMMI Model Foundation (N. del T.)


Introducción 7

CMMI para Servicios

CMMI-SVC surge de conceptos y prácticas de CMMI y de otros estándares

y modelos centrados en servicios, incluyendo los siguientes:

Information Technology Infrastructure Library (ITIL)

ISO/IEC 20000: Information Technology—Service Management

Control Objectives for Information and related Technology (CobiT)

Information Technology Services Capability Maturity Model (ITSCMM)

No se requiere estar familiarizado con estos y otros estándares y modelos

orientados a servicios para entender CMMI-SVC, ni este modelo se ha

estructurado de forma que pretenda ajustarse a ninguno de ellos. Sin

embargo, conocer otros estándares y modelos puede proveer un

entendimiento más rico de CMMI-SVC.

El modelo CMMI-SVC cubre las actividades requeridas para establecer,

prestar y gestionar servicios. Según se define en el contexto de CMMI, un

servicio es un producto intangible no-almacenable. El modelo CMMI-SVC

ha sido desarrollado para ser compatible con esta amplia definición.

Las metas y prácticas de CMMI-SVC son, por tanto, potencialmente

relevantes a cualquier organización interesada en prestar servicios,

incluyendo empresas en sectores tales como defensa, tecnologías de la

información (TI), salud, finanzas, y transporte. Los primeros usos de CMMI-

SVC incluyen organizaciones que prestan servicios tan variados como

capacitación, logística, mantenimiento, servicios a refugiados, cuidado de

jardines, bibliotecas, investigación, consultoría, auditoría, verificación y

validación independiente, recursos humanos, gestión financiera, salud, y

servicios de TI.

El modelo CMMI-SVC contiene prácticas que cubren la gestión de trabajos,

la gestión de procesos, el establecimiento de servicios, la prestación y

soporte a los servicios, y los procesos de soporte. El modelo CMMI-SVC

comparte una buena parte del material con los modelos CMMI de otras

constelaciones. Por tanto, quienes estén familiarizados con otras

constelaciones de CMMI encontrarán familiar la mayor parte del contenido

CMMI-SVC.

Al utilizar este modelo, use su juicio profesional y el sentido común para

interpretarlo para su organización. Esto es, aunque las áreas de proceso

descritas en este modelo ilustren comportamientos que se consideran

buenas prácticas para la mayoría de proveedores de servicios, todas las

áreas de proceso y prácticas deberían interpretarse utilizando un

conocimiento en profundidad de CMMI-SVC, las restricciones

organizativas, y el entorno del negocio.

Las organizaciones interesadas en evaluar y mejorar sus procesos de

desarrollo de sistemas de prestación de servicios pueden utilizar el modelo

CMMI-DEV. Este enfoque se recomienda especialmente para

organizaciones que ya estén utilizando CMMI-DEV o que deban desarrollar

y mantener sistemas de prestación de servicios complejos. Sin embargo, el

modelo CMMI-SVC proporciona un enfoque simplificado alternativo para


Introducción 8

evaluar y mejorar el desarrollo de sistemas de servicio que puede ser más

apropiado en ciertos contextos.


Componentes del Área de Proceso 9

2 Componentes del Área de Proceso

En este capítulo se describen los componentes que se encuentran en cada

área de proceso y en las metas genéricas y prácticas genéricas. Entender

estos componentes es crítico para utilizar eficazmente la información de la

Segunda Parte. Si no está familiarizado con la Segunda Parte, antes de

leer este capítulo puede ojear la sección de “Metas Genéricas y Prácticas

Genéricas” y un par de secciones de áreas de proceso para hacerse una

idea general de su contenido y disposición.

Áreas de proceso esenciales y modelos CMMI

Todos los modelos CMMI se generan a partir del Marco CMMI. Este marco

contiene todas las metas y prácticas que se utilizan para producir los

modelos CMMI que pertenecen a constelaciones CMMI.

Todos los modelos CMMI contienen 16 áreas de proceso esenciales. Estas

áreas de proceso cubren conceptos básicos que son fundamentales para la

mejora de procesos en cualquier área de interés (esto es, adquisición,

desarrollo, servicios). Parte del material de las áreas de proceso esenciales

es el mismo en todas las constelaciones. Otros materiales podrían

ajustarse para abordar un área de interés específica. Por consiguiente, los

materiales de las áreas de proceso esenciales podrían no ser exactamente

iguales.

Componentes requeridos, esperados, e informativos

Los componentes de modelo se agrupan en tres categorías –requeridos,

esperados, e informativos– que indican cómo deben ser interpretados.

Componentes requeridos

Los componentes requeridos son componentes de CMMI que son

esenciales para lograr la mejora de procesos en un área de proceso

determinada. Este logro debe haberse implementado de forma visible en

los procesos de la organización. En CMMI, los componentes requeridos

son las metas específicas y genéricas. En las evaluaciones, la satisfacción

de metas se utiliza como base para decidir si un área de proceso se ha

satisfecho o no.

Componentes esperados

Los componentes esperados son componentes de CMMI que describen las

actividades que son importantes para lograr un componente requerido de

CMMI. Los componentes esperados guían a quienes implementan mejoras



o realizan evaluaciones. En CMMI, los componentes esperados son las

prácticas específicas y genéricas

Para poder considerar una meta satisfecha, sus prácticas, tal y como están

descritas, o prácticas alternativas aceptables, deben estar presentes en los

procesos planeados e implementados de la organización.

Componentes informativos

Los componentes informativos son componentes de CMMI que ayudan a

comprender a los usuarios del modelo los componentes de CMMI

requeridos y esperados. Estos componentes pueden ser recuadros con

ejemplos, explicaciones detalladas, u otras informaciones útiles. Las

subprácticas, notas, referencias, títulos de metas, títulos de prácticas,

fuentes, ejemplos de productos de trabajo, y elaboraciones de prácticas

genéricas son componentes de modelo informativos.

El material informativo desempeña un papel importante para entender el

modelo. A menudo es imposible describir adecuadamente el

comportamiento que se requiere o se espera de una organización

utilizando sólo la declaración elemental de la meta o la práctica. El material

informativo del modelo proporciona información necesaria para lograr

entender correctamente las metas y las prácticas, por lo que no puede ser

ignorado.

Componentes asociados a la Segunda Parte

Los componentes de modelo asociados a la Segunda Parte se resumen en

la Figura 2.1 para ilustrar sus relaciones.

Figura 2.1: Componentes de modelo de CMMI



Las siguientes secciones proporcionan descripciones detalladas de los

componentes de modelo de CMMI.

Áreas de proceso

Un área de proceso es un grupo de prácticas relacionadas dentro de un

área que, cuando se implementan conjuntamente, satisface un conjunto de

metas que se consideran importantes para mejorar esa área (véase la

definición de “área de proceso” en el glosario).

Las 24 áreas de proceso se presentan a continuación por orden alfabético

de su acrónimo en inglés:

Gestión de Capacidad y Disponibilidad (CAM)

Análisis Causal y Resolución (CAR)

Gestión de Configuración (CM)

Análisis de Decisiones y Resolución (DAR)

Resolución y Prevención de Incidencias (IRP)

Gestión Integrada de Trabajos (IWM)

Medición y Análisis (MA)

Definición Organizativa de Procesos (OPD)

Enfoque Organizativo en Procesos (OPF)

Gestión del Rendimiento Organizativo (OPM)

Rendimiento Organizativo de Procesos (OPP)

Capacitación Organizativa (OT)

Aseguramiento de Calidad de Procesos y Productos (PPQA)

Gestión Cuantitativa de Trabajos (QWM)

Gestión de Requisitos (REQM)

Gestión de Riesgos (RSKM)

Gestión de Acuerdos de Suministro (SAM)

Continuidad del Servicio (SCON)

Prestación de Servicios (SD)

Desarrollo del Sistema de Servicio (SSD)11

Transición del Sistema de Servicio (SST)

Gestión Estratégica de Servicios (STSM)

Monitorización y Control de Trabajos (WMC)

Planificación de Trabajos (WP)

Declaraciones de propósito

La declaración de propósito describe el propósito del área de proceso y es

un componente informativo.

11

El área de proceso SSD es una “extensión”.



Por ejemplo, la declaración de propósito del área de proceso Definición

Organizativa de Procesos es “El propósito de Definición Organizativa de

Procesos (OPD) es establecer y mantener un conjunto utilizable de activos

de proceso organizativos, estándares de entorno de trabajo, y reglas y

guías para los equipos”.

Notas introductorias

La sección de notas introductorias del área de proceso describe los

conceptos principales cubiertos en el área de proceso, y es un componente

informativo.

Un ejemplo de notas introductorias del área de proceso Monitorización y

Control de Trabajos es “Se llevan a cabo acciones correctivas cuando el

estado real se desvía significativamente con respecto a los valores

esperados, según sea apropiado”.

Áreas de proceso relacionadas

La sección de áreas de proceso relacionadas enumera las referencias a

áreas de proceso relacionadas y refleja las relaciones de alto nivel entre las

áreas de proceso. La sección de áreas de proceso relacionadas es un

componente informativo.

Un ejemplo de referencia que se encuentra en la sección de áreas de

proceso relacionadas del área de proceso Planificación de Trabajos es

“Para más información sobre identificar y analizar riesgos y mitigar riesgos,

consúltese el área de proceso Gestión de Riesgos”

Metas específicas

Las metas específicas describen las características únicas que deben estar

presentes para satisfacer el área de proceso. Las metas específicas son

componentes de modelo requeridos y se utilizan en las evaluaciones para

ayudar a determinar si se satisface o no el área de proceso (véase la

definición de “meta específica” en el glosario).

Por ejemplo, una meta específica del área de proceso Gestión de

Configuración es “Se establece y se mantiene la integridad de las líneas

base”.

Sólo son componentes de modelo requeridos las declaraciones de metas

específicas. El título de la meta especifica (precedido por el número de

meta) y las notas relacionadas con la meta se consideran componentes de

modelo informativos.

Metas genéricas

Las metas genéricas se denominan “genéricas” porque la misma

declaración de meta se aplica a varias áreas de proceso. Una meta

genérica describe las características que deben estar presentes para

institucionalizar los procesos que implementan el área de proceso. Las

metas genéricas son componentes de modelo requeridos y se utilizan en

las evaluaciones para determinar si se satisface el área de proceso (para



una descripción más detallada de las metas genéricas, consúltese la

sección de Metas Genéricas y Prácticas Genéricas en la Segunda Parte.

Véase la definición de “meta genérica” en el glosario).

Un ejemplo de meta genérica es “El proceso está institucionalizado como

un proceso definido”.

Sólo son componentes de modelo requeridos las declaraciones de metas

genéricas. El título de la meta genérica (precedido por el número de meta)

y las notas relacionadas con la meta se consideran componentes de

modelo informativos.

Resúmenes de metas y prácticas específicas

El resumen de metas y prácticas específicas proporciona un resumen de

alto nivel de las metas específicas y prácticas específicas. El resumen de

las metas y prácticas específicas es un componente informativo.

Prácticas específicas

Una práctica específica es la descripción de una actividad que se considera

importante para lograr la meta específica asociada. Las prácticas

específicas describen las actividades que se esperan para lograr como

resultado la meta específica de un área de proceso. Las prácticas

específicas son componentes de modelo esperados (véase la definición de

“práctica específica” en el glosario).

Por ejemplo, una práctica específica del área de proceso Monitorización y

Control de Trabajos es “Monitorizar los compromisos con respecto a lo que

se identificó en el plan de trabajo”.

Sólo son componentes de modelo esperados las declaraciones de las

prácticas específicas. El título de la práctica específica (precedido por el

número de práctica) y las notas relacionadas con la práctica específica se

consideran componentes de modelo informativos.

Ejemplos de productos de trabajo

La sección de ejemplos de productos de trabajo enumera una muestra de

resultados de la práctica específica. Los ejemplos de productos de trabajo

son componentes de modelo informativos (véase definición de “ejemplo de

producto de trabajo” en el glosario).

Así, un ejemplo de producto de trabajo para la práctica específica

“Monitorizar parámetros de planificación del trabajo” en el área de proceso

Monitorización y Control de Trabajos es “Registros de desviaciones

significativas”.

Subprácticas

Las subprácticas son descripciones detalladas que orientan en la

interpretación e implementación de las prácticas específicas o genéricas.

Las subprácticas pueden estar redactadas como si fuesen preceptivas,

pero realmente son componentes informativos que sólo intentan dar ideas



que puedan ser útiles para la mejora de procesos (véase la definición de

“subpráctica” en el glosario).

Por ejemplo, una subpráctica de la práctica específica “Realizar Acciones

Correctivas” en el área de proceso Monitorización y Control de Trabajos es

“Determinar y documentar las acciones apropiadas que se necesitan para

abordar los problemas identificados”.

Prácticas genéricas

Las prácticas genéricas se llaman “genéricas” porque la misma práctica se

aplica a varias áreas de proceso. Las prácticas genéricas asociadas a una

meta genérica describen las actividades que se consideran importantes

para lograr la meta genérica y contribuyen a la institucionalización de los

procesos asociados al área de proceso. Las prácticas genéricas son

componentes de modelo esperados (véase la definición de “práctica

genérica” en el glosario).

Por ejemplo, una práctica genérica de la meta genérica “El proceso está

institucionalizado como un proceso gestionado” es “Proporcionar recursos

adecuados para realizar el proceso, desarrollar los productos de trabajo, y

proporcionar los servicios del proceso”.

Solo son componentes de modelo esperados las declaraciones de

prácticas genéricas. El título de la práctica genérica (precedido por el

número de práctica) y las notas relacionadas con la práctica se consideran

componentes de modelo informativos.

Elaboraciones de prácticas genéricas

Las elaboraciones de prácticas genéricas aparecen después de las

prácticas genéricas para orientar sobre la forma en que las prácticas

genéricas pueden aplicarse de forma única a un área de proceso. Las

elaboraciones de prácticas genéricas son componentes de modelo

informativos (véase la definición de “elaboración de práctica genérica” en el

glosario).

Por ejemplo, una elaboración de práctica genérica que aparece después de

la práctica genérica “Establecer y mantener una política organizativa para

planificar y realizar el proceso” para el área de proceso Planificación de

Trabajos es “Esta política establece las expectativas organizativas sobre

estimar parámetros de planificación, realizar compromisos internos y

externos, y desarrollar el plan para gestionar el trabajo”.

Extensiones

Las extensiones son componentes de modelo claramente resaltadas que

contienen información de interés para usuarios concretos. Las extensiones

pueden ser material informativo, prácticas específicas, metas específicas, o

un área de proceso completa que extienda el alcance del modelo o enfatice

un aspecto concreto sobre su uso. En este documento, todas las

extensiones están relacionadas con el área de proceso Desarrollo del

Sistema de Servicio.



El área de proceso Desarrollo del Sistema de Servicio es una extensión.

Otro ejemplo de extensión es la referencia que se hace en la subpráctica 6

de la práctica específica 1.1 del área de proceso Gestión Integrada de

Trabajos, “Realizar revisiones entre pares del proceso definido para el

trabajo”. La extensión establece “Para más información sobre realizar

revisiones entre pares, consúltese el área de proceso Desarrollo del

Sistema de Servicio”.

Componentes informativos de soporte

En muchas partes del modelo, se necesita información adicional para

describir un concepto. Este material informativo se proporciona por medio

de uno de los siguientes componentes:

Notas.

Ejemplos.

Referencias.

Notas

Las notas son textos que pueden acompañar a casi cualquier otro

componente de modelo. Éstas proporcionan detalles, antecedentes, o

justificaciones. Las notas son componentes de modelo informativos.

Por ejemplo, una nota que acompaña la práctica específica “Implementar

las propuestas de acción” en el área de proceso Análisis Causal y

Resolución es “Sólo los cambios para los que se demuestre su valor se

deberían considerar para su implementación general”.

Ejemplos

Los ejemplos son componentes que constan de texto, y frecuentemente de

una lista de elementos, usualmente dentro de un recuadro, que pueden

acompañar a casi cualquier otro componente, y que proporcionan uno o

más ejemplos para clarificar un concepto o actividad descrita. Los ejemplos

son componentes de modelo informativos.

El siguiente es un ejemplo que acompaña la subpráctica “Documentar los

problemas de no conformidad cuando no puedan resolverse dentro del

grupo de trabajo” bajo la práctica específica “Comunicar y resolver

problemas de no conformidad” en el área de proceso Aseguramiento de

Calidad de Procesos y Productos”.

Algunos ejemplos de formas de resolver no conformidades dentro del grupo de trabajo son:

Corregir la no conformidad.

Cambiar las descripciones de proceso, estándares, o procedimientos que se

incumplieron.

Obtener una excepción para cubrir la no conformidad.



Referencias

Las referencias son enlaces a información adicional o más detallada en

áreas de proceso relacionadas, y pueden acompañar a casi cualquier otro

componente de modelo. Las referencias son componentes de modelo

informativos (véase la definición de “referencia” en el glosario).

Por ejemplo, una referencia que acompaña a la práctica específica

“Componer el proceso definido” en el área de proceso Gestión Cuantitativa

de Trabajos es “Para más información sobre establecer activos de proceso

organizativos, consúltese el área de proceso Definición Organizativa de

Procesos”.

Esquema de numeración

Las metas específicas y genéricas se numeran secuencialmente. Cada

meta específica comienza con el prefijo “SG” (p. ej., SG 1). Cada meta

genérica comienza con el prefijo “GG” (p. ej., GG 2).

Las prácticas específicas y genéricas también se numeran

secuencialmente. Cada práctica específica comienza con el prefijo “SP”,

seguido por un número en la forma “x.y” (p. ej., SP 1.1). La x es el mismo

número que el de la meta a la que pertenece la práctica específica. La y es

el número de secuencia de la práctica específica dentro de la meta

específica.

Un ejemplo de numeración de práctica específica se encuentra en el área

de proceso Planificación de Trabajos. La primera práctica específica se

numera SP 1.1 y la segunda SP 1.2.

Cada práctica genérica comienza con el prefijo “GP”, seguido por un

número de la forma “x.y” (p. ej., GP 1.1).

La x corresponde al número de la meta genérica. La y es el número de

secuencia de la práctica genérica dentro de la meta genérica. Por ejemplo,

la primera práctica genérica asociada con GG 2 se numera GP 2.1 y la

segunda GP 2.2.

Convenciones tipográficas

Las convenciones tipográficas utilizadas en este modelo se han diseñado

para permitirle identificar y seleccionar fácilmente los componentes de

modelo, presentándolos en formatos que le permitan encontrarlos

rápidamente en la página.

Las Figuras 2.2, 2.3 y 2.4 son páginas de ejemplo extraídas de las áreas

de proceso de la Segunda Parte; en ellas se muestran los distintos

componentes de las áreas de proceso, etiquetados de forma que los pueda

identificar. Obsérvese que la tipografía de los componentes es distinta, de

forma que se pueda identificar fácilmente cada uno.



Figura 2.2: Página de ejemplo de análisis de decisiones y resolución.



Figura 2.3: Página de ejemplo de resolución y prevención de incidencias.



Figura 2.4: Página de ejemplo de metas genéricas y prácticas genéricas


Uniéndolo Todo 20

3 Uniéndolo Todo

Una vez presentados los componentes de los modelos CMMI, es necesario

comprender cómo encajarlos para satisfacer sus necesidades de mejora de

procesos. En este capítulo se presenta el concepto de niveles y se muestra

cómo se organizan y utilizan las áreas de proceso. Asimismo, se tratan

algunos conceptos clave que son significativos para aplicar el modelo

CMMI en el contexto de trabajos relacionados con servicios.

CMMI-SVC no especifica que un grupo de trabajo o una organización

deban seguir un flujo de proceso concreto o que se tengan que prestar un

cierto número de servicios por día o lograr ciertos objetivos de rendimiento.

El modelo especifica que un grupo de trabajo o una organización deben

tener procesos que aborden las prácticas relativas a servicios. Para

determinar si sus procesos están bien establecidos o no, el grupo de

trabajo o la organización hace corresponder dichos procesos con las áreas

de proceso de este modelo.

La correspondencia entre procesos y áreas de proceso posibilita que la

organización haga el seguimiento de su progreso con respecto al modelo

CMMI-SVC a medida que actualiza o crea procesos. No espere que exista

una correspondencia biunívoca entre cada una de las áreas de proceso de

CMMI-SVC y los procesos de su organización o grupo de trabajo.

Entendiendo los niveles

Los niveles se utilizan en CMMI-SVC para describir el camino evolutivo

recomendado para una organización que quiera mejorar los procesos que

se utilizan para proporcionar servicios. Los niveles también pueden ser el

resultado de la actividad de calificación en las evaluaciones12

. Las

evaluaciones se pueden aplicar a organizaciones enteras, a divisiones, o a

unidades organizativas más pequeñas, incluido grupos de trabajo

relacionados.

CMMI permite dos caminos de mejora que usan niveles. Un camino

permite a las organizaciones mejorar de forma incremental los procesos

que corresponden a un área de proceso concreta (o grupo de áreas de

proceso) seleccionada por la organización. El otro camino permite a las

organizaciones mejorar un conjunto de procesos relacionados abordando

incrementalmente conjuntos sucesivos de áreas de proceso.

12

Para más información sobre evaluaciones, consúltese Appraisal Requirements for CMMI y el Standard CMMI Appraisal

Method for Process Improvement Method Definition Document [SEI 2011a, SEI 2011b].


Uniéndolo Todo 21

Estos dos caminos de mejora se asocian con los dos tipos de niveles:

niveles de capacidad y niveles de madurez. Estos niveles se corresponden

con dos enfoques para la mejora de procesos denominados

“representaciones”. Las dos representaciones se denominan “continua” y

“por etapas”. Si se utiliza la representación continua se logran “niveles de

capacidad”. Si se utiliza la representación por etapas se logran “niveles de

madurez”.

Para alcanzar un nivel concreto, la organización debe satisfacer todas las

metas del área de proceso o del conjunto de áreas de proceso que son el

objeto de la mejora, independientemente de si se trata de niveles de

capacidad o de madurez.

Ambas representaciones proporcionan caminos para mejorar sus procesos

con el fin de lograr objetivos de negocio, y ambas proveen los mismos

contenidos esenciales y utilizan los mismos componentes de modelo.

Estructura de las representaciones continua y por etapas

La Figura 3.1 ilustra las estructuras de las representaciones continua y por

etapas. Las diferencias entre las estructuras son sutiles, aunque

significativas. La representación por etapas utiliza niveles de madurez para

caracterizar el estado global de los procesos de la organización con

respecto al modelo como un todo, mientras que la representación continua

utiliza niveles de capacidad para caracterizar el estado de los procesos de

la organización con respecto a un área de proceso concreta.


Uniéndolo Todo 22

Figura 3.1: Estructura de las representaciones continua y por etapas

Cuando compare estas dos representaciones, puede que le sorprenda su

similitud. Muchos de los componentes de ambas son comunes (p. ej.,

áreas de proceso, metas específicas, prácticas específicas), y estos

componentes tienen la misma jerarquía y configuración.

Lo que no resulta tan evidente en la perspectiva de alto nivel de la Figura

3.1 es que la representación continua se centra en la capacidad del área

de proceso medida según niveles de capacidad, y la representación por

etapas se centra en la madurez global medida según niveles de madurez.

Esta dimensión de CMMI (la dimensión de capacidad/madurez) se utiliza

para realizar comparativas y actividades de evaluación, así como para

guiar las labores de mejora de la organización.

Los niveles de capacidad se aplican a los logros de mejora de procesos de

la organización en áreas de proceso concretas. Estos niveles son un medio

para mejorar incrementalmente los procesos asociados a un área de

proceso determinada. Los cuatro niveles de capacidad se numeran de 0 a

3.

Los niveles de madurez se aplican a logros de mejora de procesos de una

organización transversales a varias áreas de proceso. Estos niveles son un

Áreas de Proceso

Niveles de Capacidad

Representación Continua

Prácticas Genéricas

Metas Genéricas Metas Específicas

Prácticas Específicas

Niveles de Madurez

Representación por Etapas

Prácticas Genéricas

Metas Genéricas Metas Específicas

Prácticas Específicas

Áreas de Proceso


Uniéndolo Todo 23

medio para mejorar los procesos asociados a un conjunto de áreas de

proceso determinado (esto es, un nivel de madurez). Los cinco niveles de

madurez se numeran de 1 a 5.

La Tabla 3.1 compara los cuatro niveles de capacidad con los cinco niveles

de madurez. Observe que los nombres de dos de los niveles son los

mismos en ambas representaciones (esto es, Gestionado y Definido). Las

diferencias son que no existe nivel de madurez 0; que no hay niveles de

capacidad 4 y 5; y que en el nivel 1, los nombres utilizados en el nivel de

capacidad 1 y el nivel de madurez 1 son distintos.

Tabla 3.1: Comparación entre niveles de capacidad y niveles de madurez

Nivel Representación continua

Niveles de capacidad

Representación por etapas

Niveles de madurez

Nivel 0 Incompleto

Nivel 1 Realizado Inicial

Nivel 2 Gestionado Gestionado

Nivel 3 Definido Definido

Nivel 4 Gestionado cuantitativamente

Nivel 5 En optimización

La representación continua se ocupa de seleccionar tanto un área de

proceso concreta a mejorar como el nivel de capacidad deseado para esa

área de proceso. En este contexto, es importante conocer si un proceso se

ha realizado o está incompleto. Por tanto, al punto de partida de la

representación continua se le da el nombre de “Incompleto”.

La representación por etapas se ocupa de seleccionar varias áreas de

proceso a mejorar dentro de un nivel de madurez; su interés principal no es

que los procesos individuales se realicen o estén incompletos. Por tanto, al

punto de partida de la representación por etapas se le da el nombre de

“Inicial”.

Tanto los niveles de capacidad como los niveles de madurez proporcionan

formas de mejorar los procesos de una organización y de medir cuánto

pueden mejorar y mejoran dichos procesos. No obstante, sus estrategias

de mejora de procesos son distintas.


Uniéndolo Todo 24

Entendiendo los niveles de capacidad

Para dar soporte a quienes utilicen la representación continua, todos los

modelos CMMI reflejan niveles de capacidad en su diseño y contenido.

Los cuatro niveles de capacidad, siendo cada uno de los cuales una capa

de la base para la continua mejora de procesos, se designan utilizando

números de 0 al 3:

0. Incompleto

1. Realizado

2. Gestionado

3. Definido

Se logra un nivel de capacidad de un área de proceso cuando se

satisfacen todas sus metas genéricas hasta ese nivel. El hecho de que los

niveles de capacidad 2 y 3 utilicen los mismos términos que las metas

genéricas 2 y 3 es intencionado porque cada una de estas metas y

prácticas genéricas refleja el significado de los niveles de capacidad de las

metas y prácticas (para más información sobre metas y prácticas

genéricas, véase la sección Metas Genéricas y Prácticas Genéricas en la

Segunda Parte). A continuación se describe brevemente cada uno de los

niveles de capacidad

Nivel de capacidad 0: Incompleto

Un proceso incompleto es un proceso que no se realiza o se realiza

parcialmente. Al menos una de las metas específicas del área de proceso

no se satisface, y no existen metas genéricas para este nivel, ya que no

hay ninguna razón para institucionalizar un proceso realizado parcialmente.

Nivel de capacidad 1: Realizado

Un proceso de nivel de capacidad 1 se caracteriza como un proceso

realizado. Un proceso realizado es un proceso que logra que se lleve a

cabo el trabajo que se necesita para producir productos de trabajo; las

metas específicas del área de proceso se satisfacen.

Aunque el nivel de capacidad 1 da como resultado mejoras importantes,

esas mejoras pueden perderse con el tiempo si no se institucionalizan. La

aplicación de la institucionalización (las prácticas genéricas de CMMI en los

niveles de capacidad 2 y 3) ayuda a asegurar que las mejoras se

conserven.

Nivel de capacidad 2: Gestionado


gestionado. Un proceso gestionado es un proceso realizado que se

planifica y ejecuta acorde a políticas; que emplea personas cualificadas

que disponen de recursos adecuados para producir resultados controlados;

que involucra a las partes interesadas relevantes; que se monitoriza,


Uniéndolo Todo 25

controla y revisa; y para el que se evalúa el cumplimiento de su descripción

de proceso.

La disciplina de procesos reflejada en el nivel de capacidad 2 ayuda a

asegurar que las prácticas existentes se mantienen en periodos de mayor

presión.

Nivel de capacidad 3: Definido


definido. Un proceso definido es un proceso gestionado que se adapta a

partir del conjunto de procesos estándar de la organización de acuerdo a

las guías de adaptación de la organización; tiene una descripción de

proceso que se mantiene; y contribuye con activos relacionados con

procesos a los activos de proceso organizativos.

Una diferencia crítica entre los niveles de capacidad 2 y 3 es el alcance de

los estándares, las descripciones de proceso, y los procedimientos. En el

nivel de capacidad 2, los estándares, las descripciones de procesos, y los

procedimientos pueden ser muy distintos en cada instancia específica del

proceso (esto es, en cada grupo de trabajo concreto). En el nivel de

capacidad 3, los estándares, las descripciones de proceso, y los

procedimientos para un trabajo se adaptan a partir del conjunto de

procesos estándar de la organización para ajustarse a un grupo de trabajo

o unidad organizativa concreta, y son, por tanto, más consistentes, excepto

por las diferencias que permiten las guías de adaptación.

Otra diferencia crítica es que, en el nivel de capacidad 3, los procesos

habitualmente se describen de forma más rigurosa que en el nivel de

capacidad 2. Un proceso definido establece claramente el propósito, las

entradas, los criterios de entrada, las actividades, los roles, las medidas,

los pasos de verificación, las salidas, y los criterios de salida. En el nivel de

capacidad 3, los procesos se gestionan de forma más proactiva utilizando y

entendiendo las interrelaciones entre las actividades del proceso y las

medidas detalladas del proceso y sus productos de trabajo.

Avanzando a través de los niveles de capacidad

Los niveles de capacidad de un área de proceso se logran aplicando las

prácticas genéricas o alternativas adecuadas a los procesos asociados a

esa área de proceso.

Alcanzar el nivel de capacidad 1 en un área de proceso es equivalente a

decir que los procesos asociados a esa área de proceso son procesos

realizados.


decir que existe una política que establece que se realizará el proceso.

Existe un plan para realizarlo, se proporcionan recursos, se asignan

responsabilidades, se proporciona capacitación para realizarlo, se

controlan los productos de trabajo seleccionados relacionados con la

ejecución del proceso, etcétera. En otras palabras, un proceso de nivel de


Uniéndolo Todo 26

capacidad 2 puede planificarse y monitorizarse de la misma forma que

cualquier trabajo o actividad de soporte.


decir que existe un proceso estándar organizativo asociado a esa área de

proceso, el cual puede adaptarse a las necesidades del trabajo. En este

punto, los procesos en la organización se definen y aplican de forma más

consistente porque se basan en procesos estándar organizativos.

Una vez que la organización ha alcanzado el nivel de capacidad 3 en las

áreas de proceso que ha seleccionado para la mejora, puede continuar su

camino de mejora abordando áreas de proceso de alta madurez

(Rendimiento Organizativo de Procesos, Gestión Cuantitativa de Trabajos,

Análisis Causal y Resolución, y Gestión del Rendimiento Organizativo).

Las áreas de proceso de alta madurez se centran en mejorar el

rendimiento de aquellos procesos que ya estén implementados. Las áreas

de proceso de alta madurez describen la utilización de técnicas

estadísticas y otras técnicas cuantitativas para mejorar los procesos

organizativos y de los grupos de trabajo, de forma que el logro de objetivos

de negocio se mejore.

Cuando se continúa en el camino de mejora de esta forma, la organización

puede obtener mayores beneficios seleccionando en primer lugar las áreas

de proceso OPP y QWM, y llevando dichas áreas de proceso a los niveles

de capacidad 1, 2 y 3. Haciendo esto, los grupos de trabajo y las

organizaciones alinean mejor la selección y análisis de procesos con sus

objetivos de negocio.

Después de alcanzar el nivel de capacidad 3 en las áreas de proceso OPP

y QWM, la organización puede continuar su camino de mejora

seleccionando las áreas de proceso CAR y OPM. Haciendo esto, la

organización analiza el rendimiento del negocio utilizando técnicas

estadísticas y otras técnicas cuantitativas para determinar deficiencias de

rendimiento, e identifica y despliega mejoras de proceso y tecnológicas que

contribuyan a cumplir los objetivos de calidad y rendimiento de procesos.

Los grupos de trabajo y la organización utilizan el análisis causal para

identificar y resolver problemas que afecten al rendimiento y promover la

difusión de buenas prácticas.

Entendiendo los niveles de madurez

Para dar soporte a quienes utilicen la representación por etapas, todos los

modelos CMMI reflejan niveles de madurez en su diseño y contenido. Un

nivel de madurez consta de las prácticas específicas y genéricas

relacionadas con un conjunto predefinido de áreas de proceso que mejoran

el rendimiento global de la organización.

El nivel de madurez de la organización proporciona una forma de

caracterizar su rendimiento. La experiencia ha demostrado que las

organizaciones logran los mejores resultados cuando en cada momento

centran sus labores de mejora de procesos en un número manejable de


Uniéndolo Todo 27

áreas de proceso, y que dichas áreas requieren mayor sofisticación a

medida que la organización mejora.

Un nivel de madurez es una plataforma evolutiva definida para la mejora de

procesos organizativa. Cada nivel de madurez madura un subconjunto

importante de los procesos de la organización, preparándola para pasar al

siguiente nivel de madurez. Los niveles de madurez se miden por el logro

de las metas genéricas y específicas asociadas a cada uno de los

conjuntos predefinidos de áreas de proceso.

Los cinco niveles de madurez, siendo cada uno de los cuales una capa de

la base para la continua mejora de procesos, se designan utilizando

números de 1 al 5:

1. Inicial.

2. Gestionado.

3. Definido.

4. Gestionado cuantitativamente.

5. En optimización.

Recuerde que los niveles de madurez 2 y 3 utilizan los mismos términos

que los niveles de capacidad 2 y 3. Esta consistencia de terminología es

intencionada porque los conceptos de niveles de madurez y niveles de

capacidad son complementarios. Los niveles de madurez se utilizan para

caracterizar la mejora organizativa relativa a un conjunto de áreas de

proceso, y los niveles de capacidad caracterizan la mejora organizativa

relativa a un área de proceso concreta.

Nivel de madurez 1: Inicial

En el nivel de madurez 1, los procesos son generalmente ad hoc y

caóticos. La organización generalmente no proporciona un entorno estable

de soporte a los procesos. El éxito en estas organizaciones depende de la

competencia y heroicidad de las personas de la organización, y no del uso

de procesos probados. A pesar de este caos, las organizaciones de nivel

de madurez 1 a menudo proporcionan servicios que funcionan, pero con

frecuencia superan los presupuestos y plazos documentados en sus

planes.

Las organizaciones con nivel de madurez 1 se caracterizan por una

tendencia a comprometerse en exceso, a abandonar sus procesos en

momentos de crisis, y a no ser capaces de repetir sus éxitos.

Nivel de madurez 2: Gestionado

En el nivel de madurez 2, los grupos de trabajo establecen las bases para

que la organización se convierta en un proveedor de servicios eficaz, por

medio de institucionalizar procesos seleccionados de Gestión de Proyectos

y Trabajos, Soporte, y Establecimiento y Prestación de Servicios. Los

grupos de trabajo definen una estrategia de servicio, crean planes de

trabajo, y monitorizan y controlan el trabajo para asegurar que los servicios


Uniéndolo Todo 28

se prestan según lo planeado. El proveedor de servicios establece

acuerdos con clientes y desarrolla y gestiona los requisitos del cliente y

contractuales. Se institucionaliza la gestión de configuración y el

aseguramiento de calidad de procesos y productos, y el proveedor de

servicios también desarrolla la competencia para medir y analizar el

rendimiento de procesos.

También en el nivel de madurez 2, se gestionan los grupos de trabajo, los

trabajos, los procesos, los productos de trabajo, y los servicios. El

proveedor de servicios asegura que los procesos se planifican conforme a

las políticas. Para ejecutar el proceso, el proveedor de servicios

proporciona recursos adecuados, asigna responsabilidades para llevarlo a

cabo, capacita a las personas en el proceso, y asegura que los productos

de trabajo designados del proceso se pongan bajo niveles apropiados de

gestión de configuración. El proveedor de servicios identifica e involucra a

las partes interesadas relevantes, y periódicamente monitoriza y controla el

proceso. Se evalúa periódicamente el cumplimiento del proceso, y el

rendimiento del proceso se comparte con la dirección. La disciplina de

procesos que refleja el nivel de madurez 2 ayuda a asegurar que las

prácticas existentes se conserven durante los periodos bajo presión.

Nivel de madurez 3: Definido

En el nivel de madurez 3, los proveedores de servicios utilizan procesos

definidos para gestionar el trabajo. Éstos integran las doctrinas de gestión

de proyectos y trabajos con las buenas prácticas de servicios, tales como

la continuidad del servicio y la resolución y prevención de incidencias,

dentro del conjunto de procesos estándar. El proveedor de servicios

verifica que los productos de trabajo seleccionados cumplan sus requisitos,

y valida que los servicios cubran las necesidades del cliente y el usuario

final. Estos procesos están bien caracterizados y se entienden, y están

descritos por medio de estándares, procedimientos, herramientas, y

métodos.

El conjunto de procesos estándar de la organización, el cual es la base del

nivel de madurez 3, se establece y se mejora a lo largo del tiempo. Estos

procesos estándar se utilizan para establecer la consistencia en toda la

organización. Los grupos de trabajo establecen sus procesos definidos

adaptando el conjunto de procesos estándar de la organización siguiendo

las guías de adaptación (véase la definición de “conjunto de procesos

estándar de la organización” en el glosario).

Una diferencia crítica entre los niveles de madurez 2 y 3 es el alcance de

los estándares, las descripciones de proceso, y los procedimientos. En el

nivel de madurez 2, los estándares, las descripciones de proceso, y los

procedimientos pueden ser muy distintos en cada instancia específica del

proceso (esto es, uso por parte de un grupo de trabajo concreto). En el

nivel de madurez 3, los estándares, las descripciones de proceso, y los

procedimientos de trabajo se adaptan a partir del conjunto de procesos

estándar de la organización para adecuarse al grupo de trabajo o unidad

organizativa y, por tanto, son más consistentes, salvo por las diferencias

que permiten las guías de adaptación.


Uniéndolo Todo 29

Otra diferencia crítica es que, en el nivel de madurez 3, los procesos

habitualmente se describen de forma más rigurosa que en el nivel de

madurez 2. Un proceso definido establece claramente su propósito,

entradas, criterios de entrada, actividades, roles, medidas, pasos de

verificación, salidas, y criterios de salida. En el nivel de madurez 3, los

procesos se gestionan más proactivamente utilizando y entendiendo las

interrelaciones entre las actividades del proceso y las medidas detalladas

del proceso, sus productos de trabajo, y sus servicios.

En el nivel de madurez 3, la organización mejora aún más los procesos

relacionados con las áreas de proceso del nivel de madurez 2. Para lograr

el nivel de madurez 3, es necesario aplicar las prácticas genéricas

asociadas a la meta genérica 3 que no se abordaron en el nivel de

madurez 2.

Nivel de madurez 4: Gestionado cuantitativamente

En el nivel de madurez 4, los proveedores de servicios establecen objetivos

cuantitativos para la calidad y el rendimiento de procesos, y los utilizan

como criterios de gestión de procesos. Los objetivos cuantitativos se basan

en las necesidades del cliente, los usuarios finales, la organización, y los

implementadores del proceso. La calidad y el rendimiento de procesos son

entendidos en términos estadísticos y se gestionan durante la vida de los

procesos.

Para subprocesos seleccionados, se recogen y analizan estadísticamente

medidas específicas de rendimiento de procesos. Cuando se seleccionan

los subprocesos a analizar, es crítico entender las relaciones entre distintos

subprocesos y el impacto que tienen sobre el logro de objetivos de calidad

y rendimiento de procesos. Este enfoque ayuda a asegurar que la

monitorización de subprocesos y la utilización de técnicas estadísticas y

otras técnicas cuantitativas se apliquen donde globalmente tengan más

valor para el negocio. Las líneas base y los modelos de rendimiento de

procesos pueden utilizarse para ayudar a establecer objetivos de calidad y

rendimiento de procesos que ayuden a lograr objetivos de negocio.

Una diferencia crítica entre los niveles de madurez 3 y 4 es la

predictibilidad del rendimiento de procesos. En el nivel de madurez 4, el

rendimiento de procesos se controla utilizando técnicas estadísticas y otras

técnicas cuantitativas, y las predicciones se basan, en parte, en el análisis

estadístico de datos de proceso detallados.

Nivel de madurez 5: En optimización

En el nivel de madurez 5, la organización mejora continuamente sus

procesos basándose en entender de forma cuantitativa sus objetivos de

negocio y necesidades de rendimiento. La organización utiliza un enfoque

cuantitativo para entender la variación inherente en el proceso y las causas

de los resultados del proceso.

El nivel de madurez 5 se centra en mejorar continuamente el rendimiento

de los procesos mediante mejoras de proceso y tecnológicas incrementales

e innovadoras. Los objetivos de calidad y rendimiento de procesos de la


Uniéndolo Todo 30

organización se establecen, se actualizan continuamente para reflejar los

cambios en los objetivos de negocio y el rendimiento organizativo, y se

utilizan como criterios para gestionar la mejora de procesos. Los efectos de

las mejoras de procesos desplegadas se miden utilizando técnicas

estadísticas y otras técnicas cuantitativas, y se comparan con los objetivos

de calidad y rendimiento de procesos. Los procesos definidos, el conjunto

de procesos estándar de la organización, y las tecnologías de soporte son

objetivos para las actividades de mejora medibles.

Una diferencia crítica entre los niveles de madurez 4 y 5 es el enfoque en

gestionar y mejorar el rendimiento organizativo. En el nivel de madurez 4,

la organización y los grupos de trabajo se centran en entender y controlar

el rendimiento a nivel de subproceso y en utilizar los resultados para

gestionar proyectos. En el nivel de madurez 5, la organización se preocupa

por el rendimiento organizativo global utilizando datos recogidos de varios

grupos de trabajo. El análisis de los datos identifica deficiencias o brechas

en el rendimiento. Esas brechas se utilizan para dirigir la mejora de

procesos organizativa que genere mejoras en el rendimiento medibles.

Avanzando a través de niveles de madurez

Las organizaciones pueden lograr mejorar progresivamente su madurez si

primero logran el control a nivel de grupos de trabajo y prosiguen hasta el

nivel más avanzado –mejora continua de procesos transversal a la

organización– utilizando para tomar decisiones tanto datos cualitativos

como cuantitativos.

Dado que la mejora organizativa de madurez se asocia con la mejora en el

rango de resultados que se espera que pueda lograr la organización, la

madurez es una forma de predecir, en líneas generales, los resultados de

los siguientes trabajos de la organización. Por ejemplo, en el nivel de

madurez 2, la organización ha mejorado desde ad-hoc a disciplinada

estableciendo una buena gestión de servicios. A medida que la

organización logra las metas genéricas y específicas del conjunto de áreas

de proceso en un nivel de madurez, aumenta su madurez organizativa y

cosecha los beneficios de la mejora de procesos. Dado que cada nivel de

madurez constituye una base para el siguiente nivel, intentar saltarse

niveles de madurez usualmente es contraproducente.

Al mismo tiempo, advierta que las labores de mejora de procesos deberían

centrarse en las necesidades de la organización en el contexto

empresarial, y que las áreas de proceso en los niveles de madurez más

altos pueden abordar las necesidades actuales de una organización o de

un grupo de trabajo.

Por ejemplo, se aconseja que las organizaciones que quieran pasar de

nivel de madurez 1 a nivel 2 establezcan un grupo de procesos, el cual es

tratado por el área de proceso Enfoque Organizativo en Procesos del nivel

de madurez 3. Aunque el grupo de procesos no es una característica

necesaria para que la organización obtenga el nivel de madurez 2, puede

que sea útil como parte de su estrategia para lograr el nivel de madurez 2.


Uniéndolo Todo 31

A veces esta situación se caracteriza por el establecimiento de un grupo de

procesos de nivel de madurez 1 para que la organización de nivel de

madurez 1 emprenda el nivel de madurez 2. Las actividades de mejora de

procesos en el nivel de madurez 1 pueden depender fundamentalmente de

los conocimientos y competencias de los miembros del grupo de procesos

mientras se establece una infraestructura de soporte a la mejora más

disciplinada y extendida.

Las organizaciones pueden establecer mejoras de proceso en cualquier

momento, incluso antes de estar preparadas para avanzar al nivel de

madurez donde se recomiende la práctica específica. Sin embargo, en

estos casos las organizaciones deberían entender que el éxito de estas

mejoras está en riesgo porque no se ha completado la base para su

adecuada institucionalización. Los procesos sin una base apropiada

pueden fallar en el momento en que más se necesiten –bajo presión.

Un proceso definido, que es característico de organizaciones de nivel de

madurez 3, puede ponerse en gran riesgo si las prácticas de gestión del

nivel 2 son deficientes. Por ejemplo, la gerencia podría comprometerse con

unos plazos mal planificados o fallar al controlar los cambios a los

requisitos en la línea base. De forma similar, muchas organizaciones

recopilan prematuramente datos detallados característicos del nivel de

madurez 4 y después se dan cuenta que los datos no pueden interpretarse

por haber inconsistencias en las definiciones de los procesos y en las

mediciones.


Uniéndolo Todo 32

Áreas de proceso

Las áreas de proceso se ven de forma distinta en las dos representaciones.

La Figura 3.2 compara perspectivas sobre el uso de las áreas de proceso

en la representación continua y en la representación por etapas.

Figura 3.2: Áreas de proceso en la representación continua y por etapas

La representación continua permite que la organización elija dónde centrar

sus labores de mejora de procesos, eligiendo las áreas de proceso, o

Área de Proceso 1

Área de Proceso 2

Área de Proceso 3

Área de Proceso 4

Área de Proceso N

CL1 CL2 CL3

Áre

as d

e P

roceso S

ele

ccio

nadas

Niveles de capacidad a alcanzar

Continua

Perfil de objetivos

Por Etapas

= Grupo de áreas de proceso seleccionadas para su mejora para lograr el nivel de madurez 3

Nivel de Madurez Seleccionado

Nivel de Madurez 5

Nivel de Madurez 4

MA

PPQA

WMC

REQM

SAM

Nivel de Madurez 3

CM

SD

Nivel de Madurez 2

WP


Uniéndolo Todo 33

conjuntos de áreas interrelacionadas, que más beneficien a la organización

y a sus objetivos de negocio. Aunque existen algunas limitaciones sobre lo

que una organización puede elegir debido a las dependencias entre áreas

de proceso, la organización tiene una libertad considerable para

seleccionarlas.

Para dar soporte a quienes utilicen la representación continua, las áreas de

proceso se organizan en cuatro categorías: Gestión de Procesos, Gestión

de Proyectos y Trabajos, Establecimiento y Prestación de Servicios, y

Soporte. Estas categorías enfatizan algunas de las relaciones clave que

existen entre las áreas de proceso.

A veces se hace referencia a una agrupación informal de áreas de proceso:

áreas de proceso de alta madurez. Las cuatro áreas de proceso de alta

madurez son: Rendimiento Organizativo de Procesos, Gestión Cuantitativa

de Trabajos, Gestión del Rendimiento Organizativo, y Análisis Causal y

Resolución. Estas áreas de proceso se centran en mejorar el rendimiento

de los procesos implementados más estrechamente relacionados con los

objetivos de negocio de la organización.

Una vez seleccionadas las áreas de proceso, debería seleccionar cuánto

quiere madurar los procesos asociados a dichas áreas de proceso (esto es,

seleccionar el nivel de capacidad apropiado). Los niveles de capacidad y

las metas y prácticas genéricas dan soporte a la mejora de los procesos

asociados a áreas de proceso concretas. Por ejemplo, la organización

puede querer alcanzar el nivel de capacidad 2 en un área de proceso y el

nivel de capacidad 3 en otra. A medida que la organización alcanza un

nivel de capacidad, establece el objetivo del siguiente nivel de capacidad

en alguna de estas misma áreas, o decide extender su visión y abordar un

número mayor de áreas de proceso. Una vez que alcanza el nivel de

capacidad 3 en la mayoría de las áreas de proceso, la organización puede

centrar su atención en las áreas de proceso de alta madurez y acreditar la

capacidad de cada una hasta el nivel de capacidad 3.

La selección de una combinación de áreas de proceso y niveles de

capacidad habitualmente se describe con un “perfil de objetivos”. El perfil

de objetivos define qué áreas de proceso se abordarán y el objetivo de

nivel de capacidad para cada una. Este perfil gobierna qué metas y

prácticas abordará la organización en sus labores de mejora de procesos.

La mayoría de las organizaciones, como mínimo, aspiran al nivel de

capacidad 1 para todas las áreas de proceso que seleccionan, lo que

requiere que se logren todas las metas específicas de dichas áreas. Sin

embargo, las organizaciones que aspiran a niveles de capacidad más altos

que el 1 se concentran en institucionalizar los procesos seleccionados en la

organización por medio de implementar metas y prácticas genéricas.

La representación por etapas proporciona un camino de mejora desde el

nivel de madurez 1 al nivel de madurez 5 que implica lograr las metas de

las áreas de proceso que hay en cada nivel de madurez. Para dar soporte

a quienes utilicen la representación por etapas, las áreas de proceso se

agrupan por niveles de madurez, indicando qué áreas de proceso se deben

implementar para alcanzar cada nivel de madurez.


Uniéndolo Todo 34

Por ejemplo, en el nivel de madurez 2, existe un conjunto de áreas de

proceso que la organización utilizaría para orientar la mejora de procesos

hasta lograr todas las metas de todas esas áreas de proceso. Una vez que

se ha logrado el nivel de madurez 2, la organización centrará sus labores

en las áreas de proceso del nivel de madurez 3, y así sucesivamente. Las

metas genéricas que se aplican en cada área de proceso también están

predeterminadas. La meta genérica 2 se aplica al nivel de madurez 2, y la

meta genérica 3 se aplica a los niveles de madurez 3 a 5.

La Tabla 3.2 proporciona una lista de las áreas de proceso de CMMI-SVC y

de sus categorías y niveles de madurez asociados.

Tabla 3.2 Áreas de proceso, categorías, y niveles de madurez

Área de proceso Categoría Nivel de madurez

Gestión de Capacidad y

Disponibilidad (CAM)

Gestión de Proyectos y Trabajos 3

Análisis Causal y

Resolución (CAR)

Soporte 5

Gestión de

Configuración (CM)

Soporte 2

Análisis de Decisiones y

Resolución (DAR)

Soporte 3

Resolución y Prevención

de Incidencias (IRP)

Establecimiento y Prestación de

Servicios

3

Gestión Integrada de

Trabajos (IWM)


Medición y Análisis (MA) Soporte 2

Definición Organizativa

de Procesos (OPD)

Gestión de Procesos 3

Enfoque Organizativo en

Procesos (OPF)


Gestión del Rendimiento

Organizativo (OPM)


Rendimiento

Organizativo de

Procesos (OPP)


Capacitación

Organizativa (OT)



Uniéndolo Todo 35

Aseguramiento de

Calidad de Procesos y

Productos (PPQA)

Soporte 2

Gestión Cuantitativa de

Trabajos (QWM)


Gestión de Requisitos

(REQM)


Gestión de Riesgos

(RSKM)


Gestión de Acuerdos de

Suministro (SAM)


Continuidad del Servicio

(SCON)


Prestación de Servicios

(SD)


Servicios

2

Desarrollo del Sistema

de Servicio (SSD)13


Servicios

3

Transición del Sistema

de Servicio (SST)


Servicios

3

Gestión Estratégica de

Servicios (STSM)


Servicios

3

Monitorización y Control

de Trabajos (WMC)


Planificación de

Trabajos (WP)


Representación equivalente

La representación equivalente es un modo de comparar los resultados de

utilizar la representación continua con los de la representación por etapas.

En esencia, si la mejora de las áreas de proceso seleccionadas se mide

utilizando los niveles de capacidad de la representación continua, ¿en qué

nivel de madurez se traduce este trabajo?, ¿es posible la traducción?

Hasta este momento no habíamos tratado en detalle las evaluaciones de

procesos. El método SCAMPISM 14

se utiliza para evaluar a las

13

El área de proceso SSD es una “extensión”.


Uniéndolo Todo 36

organizaciones que utilizan CMMI, y uno de los resultados de la evaluación

es la calificación [SEI 2011a, Ahern 2005]. Si en la evaluación se utiliza la

representación continua, la calificación es un “perfil de niveles de

capacidad”. Si en la evaluación se utiliza la representación por etapas, la

calificación es una “calificación de nivel de madurez” (p. ej., nivel de

madurez 3).

Un perfil de niveles de capacidad es una lista de áreas de proceso y el

nivel de capacidad logrado en cada una. Este perfil posibilita que la

organización siga el nivel de capacidad en cada área de proceso. El perfil

se denomina “perfil de logros” cuando representa el progreso real de la

organización en cada área de proceso. De forma alternativa, el perfil se

denomina “perfil de objetivos” cuando representa los objetivos de mejora

de procesos planeados por la organización.

La Figura 3.3 ilustra una combinación del perfil de objetivos y el de logros.

La zona sombreada de cada barra representa los niveles logrados. La zona

no sombreada representa lo que queda por conseguir para cumplir el perfil

de objetivos.

Figura 3.2: Ejemplo de combinación de perfil de objetivos y de logros

Un perfil de logros, cuando se compara con un perfil de objetivos, posibilita

que la organización planifique y siga su progreso en cada área de proceso

14

El método SCAMPI (Standard CMMI Appraisal Method for Process Improvement, o método de evaluación estándar CMMI

para la mejora de procesos) se describe en el capítulo 5.


Uniéndolo Todo 37

seleccionada. Cuando se utiliza la representación continua, es aconsejable

el mantenimiento de los perfiles de niveles de capacidad.

La secuenciación de objetivos es una sucesión de perfiles de objetivos que

describe el camino de mejora de procesos a seguir por la organización.

Cuando se construyen perfiles de objetivos, la organización debería prestar

atención a las dependencias entre prácticas genéricas y áreas de proceso.

Si una práctica genérica depende de un área de proceso, bien para llevar a

cabo la práctica genérica o para proporcionar un producto de trabajo

requerido, dicha práctica genérica podría ser mucho menos eficaz en caso

de que el área de proceso no esté implementada15

.

Aunque son muchas las razones para utilizar la representación continua,

las calificaciones que consisten en perfiles de niveles de capacidad tienen

una capacidad limitada para comparar de forma general a la organización

con otras organizaciones. Se pueden utilizar perfiles de niveles de

capacidad si cada organización selecciona las mismas áreas de proceso;

no obstante, los niveles de madurez se han utilizado durante años para

comparar organizaciones, y ya proporcionan conjuntos predefinidos de

áreas de proceso.

La representación equivalente se creó por esta causa. La representación

equivalente permite a una organización que utilice la representación

continua convertir un perfil de niveles de capacidad en una calificación de

nivel de madurez asociada.

La forma más eficaz de trazar la representación equivalente es

proporcionar una secuencia de perfiles de objetivos, siendo cada perfil

equivalente a una calificación de nivel de madurez de la representación por

etapas reflejada en las áreas de proceso enumeradas en el perfil de

objetivos. El resultado es una secuenciación de objetivos que es

equivalente a los niveles de madurez de la representación por etapas.

La Figura 3.4 muestra un resumen de los perfiles de objetivos que se

deben lograr cuando se utiliza la representación continua para que sean

equivalentes a los niveles de madurez 2 a 5. Cada área sombreada en las

columnas de nivel de capacidad representa un perfil de objetivos

equivalente a un nivel de madurez.

15

Para más información sobre las dependencias entre prácticas genéricas y áreas de proceso, véase la Tabla 6.2 en la sección

de Metas Genéricas y Prácticas Genéricas de la Segunda Parte.


Uniéndolo Todo 38

Nombre Abrev. ML CL1 CL2 CL3

Gestión de Configuración CM 2

Perfil de Objetivos

2

Medición y Análisis MA 2

Aseguramiento de Calidad Procesos y Productos

PPQA 2

Gestión de Requisitos REQM 2

Gestión de Acuerdos de Suministro SAM 2

Prestación de Servicios SD 2

Monitorización y Control de Trabajos WMC 2

Planificación de Trabajos WP 2

Gestión de Capacidad y Disponibilidad CAM 3

Perfil de Objetivos 3

Análisis de Decisiones y Resolución DAR 3

Resolución y Prevención de Incidencias IRP 3

Gestión Integrada de Trabajos IWM 3

Definición Organizativa de Procesos OPD 3

Enfoque Organizativo en Procesos OPF 3

Capacitación Organizativa OT 3

Gestión de Riesgos RSKM 3

Continuidad del Servicio SCON 3

Desarrollo del Sistema de Servicio16

SSD 3

Transición del Sistema de Servicio SST 3

Gestión Estratégica de Servicios STSM 3

Rendimiento Organizativo de Procesos OPP 4

Perfil de Objetivos 4 Gestión Cuantitativa de Trabajos QWM 4

Análisis Causal y Resolución CAR 5

Perfil de Objetivos 5 Gestión del Rendimiento Organizativo OPM 5

Figura 3.4: Perfiles de objetivos y representación equivalente

Las reglas siguientes resumen la representación equivalente:

Para lograr el nivel de madurez 2, todas las áreas de proceso

asignadas al nivel de madurez 2 deben lograr un nivel de capacidad 2 o

3.


asignadas a los niveles de madurez 2 y 3 deben lograr el nivel de

capacidad 3.


asignadas a los niveles 2, 3, y 4 deben lograr el nivel de capacidad 3.

16

Esta área de proceso es una “extensión SSD”.


Uniéndolo Todo 39

Para alcanzar el nivel de madurez 5, todas las áreas de proceso deben

lograr el nivel de capacidad 3.

Logrando la alta madurez

En la representación por etapas, se alcanza la alta madurez cuando se

logran los niveles de madurez 4 o 5. Lograr el nivel de madurez 4 implica

implementar todas las áreas de proceso de los niveles de madurez 2, 3, y

4. Del mismo modo, lograr el nivel de madurez 5 implica implementar todas

las áreas de proceso de los niveles de madurez 2, 3, 4, y 5.

En la representación continua, se alcanza la alta madurez utilizando el

concepto de representación equivalente. La alta madurez equivalente al

nivel de madurez 4 por etapas de la representación equivalente se alcanza

cuando se logra el nivel de capacidad 3 en todas las áreas de proceso

excepto Gestión del Rendimiento Organizativo (OPM) y Análisis Causal y

Resolución (CAR). La alta madurez equivalente al nivel de madurez 5

utilizando la representación equivalente se alcanza cuando se logra el nivel

de capacidad 3 en todas las áreas de proceso.

Entendiendo los conceptos clave en el uso de CMMI para Servicios

Los conceptos y términos explicados hasta ahora, tales como áreas de

proceso, niveles de capacidad, y representación equivalente son comunes

a todos los modelos CMMI. Sin embargo, existen algunos términos que son

especialmente significativos en el modelo CMMI para Servicios. Aunque

todos ellos están definidos en el glosario, cada uno emplea palabras que

pueden cubrir rangos de posibles significados dependiendo de las distintas

circunstancias de los usuarios, y, por tanto, merecen un tratamiento

adicional para asegurar que el material del modelo que incluye estos

términos no se malinterprete.

Servicio

Probablemente el más importante de estos términos sea la misma palabra

“servicio”, que en el glosario se define como un producto que es intangible

y no almacenable. Aunque esta definición captura de forma precisa el

significado que se pretende de la palabra “servicio”, no resalta algunas de

las posibles sutilezas o malinterpretaciones de este concepto en el

contexto de CMMI.

El primer punto a resaltar es que, dada esta definición, un servicio es un

tipo de producto. Mucha gente piensa rutinariamente que productos y

servicios son dos categorías mutuamente excluyentes. Sin embargo, en los

modelos CMMI productos y servicios no son categorías disjuntas: un

servicio se considera como una clase especial de producto. Se puede

asumir que cualquier referencia a productos también se refiere a servicios.

Si en el contexto de CMMI necesita una categoría de productos que no

sean servicios, puede que encuentre útil el término “bienes”, tal y como se

utiliza comúnmente en la frase “bienes y servicios” (por razones históricas,


Uniéndolo Todo 40

partes de los modelos CMMI aún utilizan ocasionalmente la frase

“productos y servicios”. Sin embargo, siempre se pretende con este uso

recordar al lector explícitamente que los servicios están incluidos en la

exposición).

Un segundo punto de confusión se da entre servicios y procesos,

especialmente porque ambos términos se refieren a entidades que son de

naturaleza intangible y no almacenable, y porque ambos conceptos están

intrínsecamente vinculados. Sin embargo, en los modelos CMMI los

procesos son actividades, mientras los servicios son resultados útiles de

realizar dichas actividades. Por ejemplo, una organización que proporcione

servicios de capacitación realiza procesos (actividades) de capacitación

que pretenden dejar en un estado de mayores conocimientos a los

receptores de la capacitación. Este estado útil de las cosas (esto es, tener

mayores conocimientos) es el servicio que el proveedor de capacitación

presta o intenta prestar. Si los procesos de capacitación se realizan pero

los receptores no acaban con mayores conocimientos (quizás debido a que

la capacitación no esté bien diseñada, o porque los receptores no tengan

previamente algunos conocimientos requeridos), entonces el servicio –el

resultado útil– no se ha prestado realmente. Los servicios son los

resultados de los procesos (realizados como parte de un conjunto de

recursos), no los procesos en sí.

Finalmente, un punto de posible confusión sobre el significado de la

palabra “servicio” será evidente para quienes tengan experiencia en

tecnologías de la información, y especialmente quienes estén

familiarizados con disciplinas como la arquitectura orientada a servicios

(SOA) o el software como servicio (SaaS). En el contexto del software,

habitualmente se piensa en los servicios con métodos, componentes o

bloques de construcción de un sistema automatizado más amplio, en lugar

de en los resultados producidos por dicho sistema. En los modelos CMMI,

los servicios son resultados útiles intangibles y no almacenables que se

proveen mediante la operación de un sistema de servicio, el cual puede

tener o no componentes automatizados. Para resolver completamente esta

posible confusión, es necesario entender el concepto de sistema de

servicio.

Sistema de servicio

Un servicio se provee mediante la operación de un sistema de servicio, el

cual se define en el glosario como una combinación integrada e

interdependiente de los recursos que lo componen que satisface los

requisitos del servicio. El uso de la palabra “sistema” en “sistema de

servicio” podría sugerir a alguien que los sistemas de servicio son un tipo

de tecnologías de la información, y que deben constar de hardware,

software, y otros componentes de TI convencionales. Esta interpretación es

demasiado restrictiva. Aunque es posible que algunos componentes de

sistema de servicio sean implementados con tecnologías de la información,

también es posible disponer de un sistema de servicio que utilice poca

cantidad de tecnologías de la información o ninguna en absoluto.


Uniéndolo Todo 41

En este contexto, la palabra “sistema” debería interpretarse en su sentido

más amplio de “grupo de elementos que interactúan regularmente o

interdependientemente formando una unidad completa”, una definición

habitual de diccionario. Además, los sistemas creados por personas

usualmente tienen un propósito unificador, así como una capacidad de

operar o comportarse de forma prevista. Un sistema de entrega de

paquetes, un sistema de atención médica, o un sistema educativo son

ejemplos a considerar de sistemas de servicio compuestos de una gran

variedad de recursos integrados e interrelacionados.

Algunos usuarios aún podrían tener problemas con esta interpretación

porque podrían pensar que su forma de prestar servicios no es sistemática,

no implica “componentes” identificables, o es demasiado pequeña o difícil

como para ser vista desde la perspectiva de sistemas. Aunque puede que

esta dificultad sea cierta en algunos casos de organizaciones proveedoras

de servicios con prácticas relativamente inmaduras, parte de la dificultad

también puede deberse a una interpretación demasiado restrictiva de la

palabra “recursos” en la definición de sistema de servicio.

La extensión completa del sistema de servicio abarca todo lo que se

requiere para la prestación de servicios, incluyendo productos de trabajo,

procesos, herramientas, instalaciones, elementos consumibles, y recursos

humanos. Parte de estos recursos pueden pertenecer a clientes o

suministradores, y parte pueden ser transitorios (en el sentido de que sólo

forman parte del sistema de servicio durante un tiempo limitado). Pero

todos estos recursos pasan a formar parte del sistema de servicio si se

necesitan de algún modo para posibilitar la prestación de servicios.

Debido a este amplio rango de tipos de recurso incluidos y a las

interrelaciones entre ellos, un sistema de servicio puede ser algo grande y

complejo, con extensas instalaciones y componentes tangibles (p. ej. un

sistema de servicio para atención médica, un sistema de servicio para

transporte). Alternativamente, un sistema de servicio podría ser algo que

principalmente conste de personas y procesos (p. ej. para un servicio

independiente de verificación y validación). Dado que las organizaciones

proveedoras de servicios que utilicen el modelo CMMI-SVC deben tener al

menos recursos tanto del tipo personas como del tipo procesos, todas

deberían ser capaces de utilizar exitosamente el concepto de sistema de

servicio.

Los proveedores de servicios que no estén acostumbrados a pensar en sus

métodos, herramientas, y personal de prestación de servicios desde una

amplia perspectiva de sistemas, pueden necesitar dedicar algún esfuerzo a

reajustar su concepto de prestación de servicios para acomodarlo a esta

perspectiva. Los beneficios de hacer esto, no obstante, son muchos, ya

que se harán visibles por vez primera los recursos y las dependencias

entre recursos que son críticos y antes pasaban desapercibidos. Este

conocimiento posibilita que la organización proveedora de servicios mejore

eficazmente sus operaciones a lo largo del tiempo sin verse sorprendida ni

malgastar recursos por abordar un problema de forma incompleta.


Uniéndolo Todo 42

Acuerdo de servicio

Un acuerdo de servicio es la base para el mutuo entendimiento entre un

proveedor de servicios y un cliente acerca de lo que esperan de su relación

mutua. El glosario define un “acuerdo de servicio” como un registro

vinculante y por escrito de una promesa de intercambio de valor entre un

proveedor de servicios y un cliente. Los acuerdos de servicio pueden

presentarse con una amplia variedad de formas que van desde los simples

menús publicados de los servicios y sus precios, hasta recibos o señales

en letra pequeña con referencias a términos y condiciones descritas en otra

parte, o documentos compuestos complejos que se incluyan como parte de

un contrato legal. Cualquiera que sea su contenido, es esencial que los

acuerdos de servicio se registren de un modo accesible y entendible tanto

para el proveedor como para el cliente, de forma que los malentendidos se

minimicen.

La “promesa de intercambio de valor” implica que cada parte del acuerdo

se compromete a proporcionar a la otra parte o partes algo que necesita o

quiere. Una situación habitual es que el proveedor de servicios preste los

servicios necesarios y el cliente page dinero a cambio, pero son posibles

otros tipos de acuerdo. Por ejemplo, un acuerdo de nivel de operación

(OLA) entre organizaciones de la misma empresa puede requerir

únicamente que la organización cliente notifique a la organización

proveedora de servicios que se necesitan ciertos servicios. Los acuerdos

de servicio para servicios públicos que proporcionan gobiernos, agencias

municipales, y organizaciones sin ánimo de lucro pueden simplemente

documentar los servicios que están disponibles, e identificar qué pasos

tienen que seguir los usuarios finales para obtener dichos servicios. En

algunos casos, lo único que el proveedor de servicios necesita o quiere del

cliente o usuario final es la información específica que se necesita para

poder prestar el servicio.

Véanse las definiciones de “acuerdo de servicio”, “acuerdo de nivel de

servicio”, “cliente” y “usuario final” en el glosario.

Petición de servicio

Incluso si hay un acuerdo de servicio, los clientes y usuarios finales deben

ser capaces de notificar al proveedor de servicios sus necesidades de

instancias específicas de prestación de servicios. En el modelo CMMI-SVC,

estas notificaciones se denominan “peticiones de servicio”, y pueden

comunicarse de cualquier modo concebible, incluyendo encuentros cara-a-

cara, llamadas telefónicas, cualquier tipo de medios escritos, e incluso

señales no verbales (p. ej. pulsando un botón para pedir una parada en un

autobús).

Independientemente de cómo se comunique, una petición de servicio

identifica uno o más servicios deseados que quien origina la petición

espera encontrar dentro del alcance de un acuerdo de servicio existente. A

menudo estas peticiones son generadas a lo largo del tiempo por clientes y

usuarios finales a medida que surgen sus necesidades. En este sentido,

las peticiones de servicio son acciones deliberadas esperadas que forman


Uniéndolo Todo 43

parte de la prestación de servicios de manera esencial; son los eventos

desencadenantes primordiales que originan la ocurrencia de una

prestación de servicios (por supuesto, es posible que quien origina la

petición esté equivocado acerca de si la petición entra o no en el alcance

real del acuerdo de servicio).

A veces hay peticiones específicas de servicio que se incorporan

directamente en los mismos acuerdos de servicio. Incorporar estas

peticiones de servicio en un acuerdo de servicio es frecuente en el caso de

servicios que tienen que realizarse periódica o continuamente a lo largo del

tiempo (p. ej. un servicio de limpieza con un cronograma específico de

limpieza esperado, un servicio de gestión de redes que deba proveer un

99,9% de disponibilidad durante la vida del acuerdo de servicio). Incluso en

estas situaciones, se pueden generar peticiones de servicio ocasionales

cuando sea necesario, y el proveedor de servicios debería estar preparado

para prestar servicios en respuesta a ambos tipos de peticiones.

Incidencia en el servicio

Incluso con la mejor planificación, monitorización, y prestación de servicios,

pueden ocurrir eventos no intencionados que no se desean. Algunas

instancias de prestación de servicios pueden tener niveles de rendimiento o

de calidad menores de lo esperado o aceptable, o pueden fallar

completamente. El modelo CMMI-SVC se refiere a estas dificultades como

“incidencias en el servicio”. El glosario define “incidencia en el servicio”

como una indicación de una interferencia real o potencial en un servicio. La

expresión abreviada “incidencia” se utiliza en lugar de “incidencia en el

servicio” cuando el contexto deje claro su significado.

Al igual que las peticiones, las incidencias requieren algún tipo de

reconocimiento y respuesta por parte del proveedor de servicios, pero a

diferencia de éstas, las incidencias son eventos no intencionados, a pesar

de que algunos tipos de incidencia sí se pueden anticipar. Tanto si se

anticipan como si no, el proveedor de servicios debe resolver las

incidencias de alguna forma. En algunos tipos de servicio y de

organizaciones proveedoras, las peticiones de servicio y las incidencias se

gestionan y resuelven por medio de procesos, personal, y herramientas

comunes. El modelo CMMI-SVC es compatible con este tipo de enfoque,

pero no lo requiere, ya que no es apropiado para todos los tipos de

servicio.

El uso de la palabra “potencial” en la definición de incidencia en el servicio

es deliberado y significativo; quiere decir que las incidencias no siempre

implican una interferencia real o un fallo en la prestación de servicios. Las

indicaciones de que un servicio podría haber sido insuficiente o fallido

también son incidencias, ya que son indicadores de que éste puede ser

insuficiente o fallido en el futuro (las quejas de clientes son un ejemplo casi

universal de este tipo de incidencias porque son siempre indicadores de

que la prestación de servicios puede haber sido inadecuada). Este aspecto

de las incidencias a menudo se pasa por alto, pero es importante: no

abordar y resolver interferencias potenciales en los servicios, con


Uniéndolo Todo 44

frecuencia conduce a que finalmente se produzcan interferencias reales, y

a que los acuerdos de servicio posiblemente se incumplan.


Uniéndolo Todo 45

Proyecto, grupo de trabajo, y trabajo

Los modelos CMMI a menudo se refieren a las entidades organizativas que

están en la base de las labores de mejora de procesos. Estas entidades

son los puntos focales de la organización para crear valor, gestionar

trabajo, adaptar procesos, y realizar evaluaciones. En CMMI-SVC, estas

entidades se denominan “grupos de trabajo”, mientras que en CMMI-DEV y

CMMI-ACQ estas entidades se denominan “proyectos”. El glosario define

ambos términos y sus interrelaciones mutuas, pero no explica por qué se

necesitan dos términos.

Quienes tengan experiencia previa utilizando los modelos CMMI-DEV o

CMMI-ACQ, o quienes piensen en su trabajo rutinariamente como parte de

un estilo de trabajo organizado en proyectos, pueden preguntarse por qué

el término “proyecto” no es suficiente por sí mismo. El glosario de CMMI

define “proyecto” como conjunto gestionado de actividades y recursos

interrelacionados, incluyendo personas, que proporciona uno o más

productos o servicios a un cliente o usuario final. Las notas de la definición

explican que un proyecto tiene un comienzo (esto es, el arranque del

proyecto) y un final, y que habitualmente opera siguiendo un plan. Estas

notas son características del proyecto según muchas definiciones, así que

¿dónde está el problema? ¿por qué podría haber dificultades al utilizar

términos como “planificación de proyectos” o “gestión de proyectos” en

algunas organizaciones proveedoras de servicios?

Una razón simple es que los proyectos también tienen un final previsto

además de un comienzo previsto; tales labores se centran en acometer un

objetivo antes de un plazo determinado. Aunque algunos servicios siguen

el mismo patrón, muchos otros se prestan a lo largo del tiempo sin un final

esperado (p. ej. servicios municipales habituales, servicios de empresas

que esperen ofrecerlos de forma indefinida). Los proveedores de servicios

en estos contextos son reacios por naturaleza a describir su trabajo de

prestación de servicios como un proyecto según esta definición.

En los modelos CMMI anteriores (V1.2), la definición de “proyecto” se

cambió deliberadamente para eliminar esta limitación (esto es, que los

proyectos tienen un final definido o previsto), en parte para permitir que se

apliquen fácilmente al rango completo de tipos de servicio. Sin embargo, el

cambio hizo surgir más preguntas y objeciones que las que resolvió cuando

fue interpretado por muchos usuarios (incluso de algunos contextos de

servicios), así que el significado limitado se ha restaurado en la V1.3: ahora

los proyectos deben tener un final esperado.

Para organizaciones que no estructuren sus personas y otros recursos en

proyectos con finales esperados, o que sólo lo hacen en parte de su

trabajo, el problema original permanece. Todas las prácticas comunes de

CMMI se utilizan tanto si el trabajo se planifica con un final esperado como

si no, pero ¿cómo podemos denominar a una entidad organizativa

fundamental que implemente las prácticas de CMMI si no es un proyecto?

¿Cómo podemos referirnos a la aplicación de prácticas de un área de

proceso tal como planificación de proyectos si no estamos hablando de

proyectos?


Uniéndolo Todo 46

La solución de CMMI V1.3 es introducir nuevos términos que se benefician

de los dos sentidos distintos de la palabra “proyecto”: un conjunto de

recursos (incluyendo personas), y un conjunto de actividades realizadas

por personas. CMMI-DEV y CMMI-ACQ siguen utilizando el término

“proyecto” en ambos sentidos, debido a que este uso refleja la naturaleza

habitual de las labores de desarrollo y adquisición. CMMI-SVC reemplaza

“proyecto” por “grupo de trabajo” (cuando se refiere estrictamente a un

conjunto de recursos incluyendo personas) o por “trabajo” (cuando se

refiere a un conjunto de actividades, o un conjunto de actividades y

recursos asociados). El glosario define “grupo de trabajo” como conjunto

gestionado de personas y otros recursos asignados que proporciona uno o

más productos o servicios a un cliente o usuario final. La definición no dice

nada sobre el tiempo de vida esperado del grupo de trabajo. Por

consiguiente, un proyecto (en el primer sentido) puede considerarse como

un tipo de grupo de trabajo, uno cuyo trabajo se planea que tenga un final

esperado.

Las organizaciones proveedoras de servicios pueden, por tanto,

estructurarse en grupos de trabajo (sin limitaciones temporales) o en

proyectos (con limitaciones temporales), dependiendo de la naturaleza del

trabajo, y muchas organizaciones harán ambas cosas en distintos

contextos. Por ejemplo, el desarrollo de un sistema de servicio puede

realizarlo un proyecto, y la prestación de servicios puede realizarla un

grupo de trabajo.

El glosario también alude a que el grupo de trabajo puede contener grupos

de trabajo, puede sobrepasar fronteras organizativas, y puede aparecer en

cualquier nivel de la organización. Es posible que un grupo de trabajo se

defina simplemente como miembros de la organización con un propósito

concreto en común (p. ej. todos los que realicen un tipo de tarea concreta),

tanto si el grupo está representado en algún lugar del organigrama como si

no.

Al final, claro está, las organizaciones utilizarán cualquier terminología que

les sea cómoda, familiar, y útil, y el modelo CMMI-SVC no requiere que

este enfoque cambie. Sin embargo, todos los modelos CMMI necesitan una

forma conveniente para referirse claramente a agrupaciones

fundamentales de recursos que organizan el trabajo para lograr objetivos

significativos. En contraste con otros modelos CMMI, el modelo CMMI-SVC

utiliza específicamente el término “grupo de trabajo” en lugar de “proyecto”

para este propósito, y utiliza el término “trabajo” para otros sentidos de la

palabra “proyecto” incluyendo sentidos combinados. Por ejemplo, un “plan

de proyecto” se llama “plan de trabajo” en CMMI-SVC (en unos pocos

casos la palabra “proyecto” se ha mantenido en el modelo CMMI-SVC para

referirse explícitamente a auténticos proyectos).

De forma consistente con este uso, los títulos de algunas áreas de proceso

esenciales importantes en CMMI-SVC son distintos a los de CMMI-DEV y

CMMI-ACQ: Planificación de Trabajos, Monitorización y Control de

Trabajos, Gestión Integrada de Trabajos, y Gestión Cuantitativa de

Trabajos (Planificación de Proyectos, Monitorización y Control de

Proyectos, Gestión Integrada de Proyectos, y Gestión Cuantitativa de


Uniéndolo Todo 47

Proyectos). A pesar de estas diferencias en la terminología de distintas

constelaciones, Gestión Integrada de Trabajos y Gestión Integrada de

Proyectos cubren esencialmente el mismo material y se consideran la

misma área de proceso en las tres constelaciones de CMMI; lo mismo

aplica a las otras áreas de proceso emparejadas.


Relaciones entre Áreas de Proceso 48

4 Relaciones entre Áreas de Proceso

En este capítulo se describen las relaciones clave que hay entre las áreas

de proceso con el fin de ayudarle a ver la mejora de procesos desde el

punto de vista del proveedor de servicios y cómo algunas áreas de proceso

dependen de la implementación de otras áreas de proceso.

Las relaciones entre áreas de proceso, incluyendo la información y los

artefactos que fluyen desde unas áreas de proceso hacia otras –ilustradas

por las descripciones y figuras de este capítulo– le ayudarán a obtener una

visión más amplia de la implementación y mejora de procesos.

Las iniciativas de mejora de procesos exitosas deben estar regidas por los

objetivos de negocio de la organización. Por ejemplo, un objetivo de

negocio habitual es reducir el tiempo que se necesita para prestar un

servicio. El objetivo de mejora de procesos derivado de éste podría ser

mejorar los procesos de gestión de incidencias. Dichas mejoras se

asientan en las buenas prácticas de las áreas de proceso Prestación de

Servicios y Resolución y Prevención de Incidencias.

Aunque en este capítulo ciertas áreas de proceso se agrupan con objeto de

simplificar la exposición sobre sus relaciones, a menudo las áreas de

proceso interactúan y tienen efectos entre ellas, independientemente de su

grupo, categoría o nivel. Por ejemplo, el área de proceso Análisis de

Decisiones y Resolución (un área de proceso de Soporte en el nivel de

madurez 3) contiene prácticas específicas que abordan el proceso de

evaluación formal que se usa en el área de proceso Continuidad del

Servicio (un área de proceso de Establecimiento y Prestación de Servicios

en el nivel de madurez 3) para la selección de las funciones que sean

esenciales para la organización y deban estar cubiertas por un plan de

continuidad del servicio.

Conocer las relaciones clave que existen entre las áreas de proceso de

CMMI le ayudará a aplicar CMMI de forma útil y productiva. Las relaciones

entre áreas de proceso se describen con mayor detalle en las referencias

de cada área de proceso, y específicamente en la sección de Áreas de

proceso relacionadas de cada área de proceso en la Segunda Parte. Para

más información sobre las referencias, consúltese el Capítulo 2.



Las áreas de proceso del modelo CMMI-SVC tienen numerosas

interrelaciones que están basadas en la transferencia o compartición de

información, productos de trabajo, y otros recursos entre sus prácticas

asociadas. Esta sección se centra en identificar sólo aquellas relaciones

que abarquen áreas de proceso específicas de servicios. Estas relaciones

se entienden mejor asociándolas por funcionalidad a dos grupos distintos

que van más allá de los niveles de madurez y de las categorías de área de

proceso:

Establecimiento y prestación de servicios.

Gestión de servicios.

Las relaciones entre áreas de proceso se ilustran en los siguientes

diagramas que, por cuestiones de claridad, se centran en las dependencias

clave. No se muestran todas las posibles interacciones entre áreas de

proceso, ni todas las áreas de proceso. Las áreas de proceso que se han

omitido en estos diagramas (principalmente las áreas de proceso de

Gestión de Procesos y de Soporte) tienen relaciones potenciales con todas

las áreas de proceso que sí se muestran, y su inclusión haría difícil

centrarse en las relaciones clave de CMMI-SVC.



Relaciones que rigen Establecimiento y Prestación de Servicios

La Figura 4.1 muestra las áreas de proceso asociadas al establecimiento

de las capacidades de prestación de servicios regido por los requisitos de

los acuerdos de servicio con los clientes, así como a la prestación de

servicios.

Figura 4.1: Relaciones clave entre las áreas de proceso de

Establecimiento y Prestación de Servicios

Todas las áreas de proceso que se muestran en este diagrama están en la

categoría de Establecimiento y Prestación de Servicios. Observe que el

área de proceso Prestación de Servicios ocupa en estas relaciones un

papel central.

Relaciones que rigen Gestión de Servicios

La Figura 4.2 muestra las áreas de proceso asociadas a la gestión de

servicios a nivel de grupo de trabajo. La mayoría de áreas de proceso que

se muestran en este diagrama son de la categoría Gestión de Proyectos y

Trabajos, con la excepción de Prestación de Servicios. La razón de que

este diagrama se refiera a “gestión de servicios” en vez de a “gestión de

trabajos” es que el área de proceso Prestación de Servicios contribuye



tanto a Gestión de Proyectos y Trabajos como a Establecimiento y

Prestación de Servicios, pero en un modelo CMMI sólo puede pertenecer a

una categoría de áreas de proceso. El nombre “gestión de servicios”

expresa mejor el alcance completo del contenido de la figura que el nombre

de una única categoría de áreas de proceso.

Figura 4.2: Relaciones clave entre áreas de proceso de Gestión de

Servicios


Utilizando los Modelos CMMI 52

5 Utilizando los Modelos CMMI

En la actualidad, la complejidad de los servicios requiere de una visión

integrada de cómo funcionan las organizaciones. CMMI puede reducir el

coste de la mejora de procesos entre distintas empresas que dependan de

múltiples funciones o grupos para lograr sus objetivos.

Para lograr esta perspectiva integrada, el Marco CMMI incluye terminología

común, componentes de modelo comunes, métodos de evaluación

comunes, y materiales de capacitación comunes. Este capítulo describe la

forma en que las organizaciones pueden utilizar el Conjunto de Productos

CMMI, no sólo para mejorar su calidad, reducir sus costes y optimizar sus

plazos, sino también para calibrar el grado en el que está funcionando su

programa de mejora de procesos.

Adoptando CMMI

La investigación ha demostrado que el paso inicial más importante para la

mejora de procesos es establecer un soporte organizativo por medio de un

fuerte patrocinio de la dirección. Para obtener este patrocinio, a menudo es

beneficioso exponer los resultados de rendimiento que otras

organizaciones ha experimentado al utilizar CMMI para mejorar sus

procesos [Gibson 2006].

Para más información sobre resultados de rendimiento de CMMI,

consúltese el sitio web del SEI en

http://www.sei.cmu.edu/cmmi/research/results/.

El directivo, una vez se ha comprometido como patrocinador de la mejora

de procesos, debe estar involucrado activamente en la labor de mejora de

procesos basada en CMMI. Las actividades que realiza el patrocinador de

la dirección incluyen, aunque no se limitan a:

Influir para que la organización adopte CMMI.

Seleccionar a las mejores personas para que gestionen la labor de

mejora de procesos.

Monitorizar personalmente la labor de mejora de procesos.

Ser un defensor y portavoz visible de la labor de mejora de procesos.

Asegurar que estén disponibles los recursos adecuados para posibilitar

que la labor de mejora de procesos tenga éxito.

Una vez se disponga de suficiente patrocinio de la dirección, el siguiente

paso es establecer un grupo de procesos fuerte y técnicamente

competente que represente a las partes interesadas relevantes con el fin

de guiar las labores de mejora de procesos [Ahern 2008].



Para una organización cuya misión sea prestar servicios de calidad, el

grupo de procesos podría incluir a representantes de las distintas

disciplinas de la organización y a otros miembros seleccionados en base a

las necesidades de negocio que dirijan la mejora. Por ejemplo, un

administrador de sistemas puede centrarse en el soporte con tecnologías

de la información, mientras que un representante de marketing puede

centrarse en integrar las necesidades de los clientes. Ambos miembros

podrían realizar importantes contribuciones al grupo de procesos.

Una vez que su organización decide adoptar CMMI, la planificación puede

comenzar usando un enfoque de mejora como el modelo IDEALSM

(Iniciar,

Diagnosticar, Establecer, Actuar y Aprender17

) [McFeeley 1996]. Para más

información acerca del modelo IDEAL, consúltese el sitio web del SEI en

http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm.

Su programa de mejora de procesos

Utilice el Conjunto de Productos CMMI para ayudar a establecer el

programa de mejora de procesos de su organización. Utilizar el conjunto de

productos para este propósito podría ser un proceso relativamente

informal, que implique entender y aplicar a su organización las buenas

prácticas de CMMI. También podría ser un proceso formal, que implique

capacitación abundante, creación de la infraestructura de mejora de

procesos, realización de evaluaciones, y demás.

Selecciones que influyen en su programa

Para aplicar CMMI a la mejora de procesos en su organización debe

seleccionar tres cosas:

1. Seleccionar una parte de la organización.

2. Seleccionar un modelo.

3. Seleccionar una representación.

Seleccionar los grupos de trabajo que estarán involucrados en el programa

de mejora de procesos es crítico. Si selecciona un grupo muy grande,

puede que sea demasiado para la labor inicial de mejora. La selección

también debería tener en cuenta la homogeneidad en la organización, los

productos, y los trabajos (esto es, si todos los miembros de los grupos son

expertos en la misma disciplina, si trabajan en la misma línea de productos

o línea de negocio, etc.).

Seleccionar un modelo apropiado también es esencial para el éxito del

programa de mejora de procesos. El modelo CMMI-DEV se centra en las

actividades para desarrollar productos y servicios de calidad. El modelo

CMMI-ACQ se centra en las actividades para iniciar y gestionar la

17

Initiating, Diagnosing, Establishing, Acting, and Learning (N. del T.)



adquisición de productos y servicios. El modelo CMMI-SVC se centra en

las actividades para proporcionar servicios de calidad a clientes y usuarios

finales. Al seleccionar el modelo se debería considerar, según sea

apropiado, el interés principal de la organización, los proyectos o los

grupos de trabajo, y los procesos necesarios para satisfacer los objetivos

de negocio. Para seleccionar el modelo apropiado también deberían

considerarse los procesos del ciclo de vida (p. ej., concepción, diseño,

manufactura, despliegue, operaciones, mantenimiento, eliminación) en los

que se concentre la organización.

Seleccione la representación (niveles de capacidad o de madurez) que se

ajuste a su concepto de mejora de procesos. Independientemente de cuál

elija, puede seleccionar casi cualquier área de proceso o grupo de áreas de

proceso para guiar la mejora, pero para hacer la selección deberían

tenerse en cuenta las dependencias entre áreas de proceso.

A medida que avanzan los planes y actividades de mejora de procesos, se

deben realizar otras selecciones importantes, incluyendo si se hará o no

una evaluación, qué método de evaluación debería utilizarse, qué grupos

de trabajo deberían evaluarse, cómo se debería asegurar la capacitación

del personal, y qué miembros del personal se deberían capacitar.

Modelos CMMI

Los modelos CMMI describen buenas prácticas que las organizaciones han

encontrado productivas y útiles para lograr sus objetivos de negocio.

Independientemente de su organización, debe utilizar su criterio profesional

al interpretar las buenas prácticas de CMMI para su situación,

necesidades, y objetivos de negocio.

Palabras como “adecuado”, “apropiado” o “según se necesite” en una meta

o una práctica reafirman este uso de su criterio. Estas palabras se utilizan

para actividades que pueden no tener la misma relevancia en todas las

situaciones. Interprete estas metas y prácticas para que funcionen en su

organización.

Aunque las áreas de proceso describen las características de una

organización que está comprometida con la mejora de procesos, debe

interpretar las áreas de proceso utilizando un conocimiento en profundidad

de CMMI, de su organización, del entorno de negocio, y de las

circunstancias específicas implicadas.

A medida que empiece a utilizar un modelo CMMI para mejorar los

procesos de su organización, haga corresponder sus procesos reales con

las áreas de proceso de CMMI. Esta correspondencia posibilita juzgar al

inicio, y seguir después, el grado en que su organización satisface el

modelo CMMI que esté usando, así como identificar oportunidades de

mejora.

Para interpretar las prácticas es importante considerar el contexto global en

el cual se utilizan, y determinar el grado en el que las prácticas satisfacen

las metas del área de proceso en dicho contexto. Los modelos CMMI no



prescriben ni sugieren qué procesos son los correctos para la organización

o el grupo de trabajo. En su lugar, CMMI describe los criterios mínimos

necesarios para planificar e implementar los procesos que la organización

ha seleccionado para su mejora en base a los objetivos de negocio.

Para adecuarse a las necesidades de distintas organizaciones y grupos de

trabajo, las prácticas de CMMI utilizan a propósito frases imprecisas, tales

como “partes interesadas relevantes”, “según sea apropiado”, y “según se

necesite”. Las necesidades concretas de un grupo de trabajo también

pueden variar en distintos puntos del ciclo de vida del trabajo.

Utilizando las evaluaciones CMMI

A muchas organizaciones les aporta valor medir su progreso realizando

evaluaciones con el fin de obtener una calificación del nivel de madurez o

un perfil de logros de niveles de capacidad. Habitualmente, estos tipos de

evaluación se realizan por uno o más de los siguientes motivos:

Para determinar cómo se equiparan los procesos de la organización

con las buenas prácticas de CMMI e identificar áreas en las que se

pueden realizar mejoras.

Para informar a clientes y suministradores externos acerca de cómo se

equiparan los procesos de la organización con las buenas prácticas de

CMMI.

Para cumplir los requisitos contractuales de uno o más clientes.

Las evaluaciones de las organizaciones que utilizan el modelo CMMI

deben ajustarse a los requisitos definidos en el documento Appraisal

Requirement for CMMI (ARC)18

[SEI 2011b]. Las evaluaciones se centran

en identificar oportunidades de mejora y comparar los procesos de la

organización con las buenas prácticas de CMMI.

Los equipos evaluadores utilizan el modelo CMMI y un método de

evaluación conforme con ARC para guiar su evaluación de la organización

y su reporte de conclusiones. Los resultados de la evaluación son

utilizados (p. ej. por un grupo de procesos) para planificar mejoras en la

organización.

Requisitos de evaluaciones CMMI

El documento Appraisal Requirements for CMMI (ARC) describe los

requisitos de los distintos tipos de evaluación. Una evaluación comparativa

completa es definida como evaluación Clase A. Los métodos menos

formales son definidos como Clase B o Clase C. El documento ARC se

diseñó para contribuir a mejorar la consistencia entre los métodos de

evaluación, y para ayudar a entender las ventajas e inconvenientes de los

18

Requisitos de Evaluaciones CMMI (N. del T.)



distintos métodos a los desarrolladores de métodos de evaluación, a los

patrocinadores, y a los usuarios.

Dependiendo del propósito de la evaluación y de la naturaleza de las

circunstancias, se puede preferir una clase a las otras. A veces es

apropiado hacer una autoevaluación, una evaluación inicial, un examen

superficial o mini-evaluación, o una evaluación externa; en otros casos es

apropiado hacer una evaluación comparativa formal.

Un método de evaluación concreto se declara como evaluación ARC Clase

A, B, o C en función del conjunto de requisitos ARC que el desarrollador

del método abordó mientras lo diseñaba.

Hay más información disponible acerca de ARC en sitio web del SEI

http://www.sei.cmu.edu/cmmi/toos/appraisals/.

Métodos de evaluación SCAMPI

El método de evaluación SCAMPI A es el método aceptado de forma

generalizada para realizar evaluaciones ARC Clase A utilizando modelos

CMMI. El documento Method Definition Document19

(MDD) del SCAMPI A

define reglas para asegurar que las calificaciones de las evaluaciones sean

consistentes [SEI 2011a]. Para poder hacer comparativas con otras

organizaciones, las evaluaciones deben asegurar que las calificaciones

sean consistentes. El logro de un nivel de madurez concreto, o la

satisfacción de un área de proceso, debe significar lo mismo en todas las

organizaciones evaluadas.

La familia de evaluaciones SCAMPI incluye los métodos de evaluación

Clases A, B, y C. El método de evaluación reconocido oficialmente y el más

riguroso es el SCAMPI A. Es el único método que puede producir una

calificación comparativa de calidad. Los métodos de evaluación SCAMPI B

y C proporcionan a la organización información de mejora que, incluso

siendo menos formal que la que resulta de una evaluación SCAMPI A,

ayuda a la organización a identificar oportunidades de mejora.

Hay más información disponible acerca de los métodos SCAMPI en el sitio

web del SEI en http://www.sei.cmu.edu/cmmi/tools/appraisals/.

Consideraciones sobre evaluaciones

Una evaluación basada en CMMI está afectada por la elección de:

El modelo CMMI.

El alcance de la evaluación, incluyendo la unidad organizativa a

evaluar, las áreas de proceso de CMMI a investigar, y el nivel de

madurez o los niveles de capacidad a evaluar.

El método de evaluación.

19

Documento de Definición del Método (N. del T.)

http://www.sei.cmu.edu/cmmi/toos/appraisals/



El líder y los miembros del equipo evaluador.

Los participantes en la evaluación seleccionados de entre las entidades

evaluadas para las entrevistas.

Los resultados de la evaluación (p. ej. calificaciones, hallazgos de

instanciación específicos).

Las restricciones de la evaluación (p. ej. tiempo disponible in situ).

El MDD de SCAMPI permite seleccionar opciones predefinidas para su uso

en las evaluaciones. Estas opciones de evaluación están diseñadas para

ayudar a las organizaciones a alinear CMMI con sus necesidades y


Los planes y resultados de las evaluaciones CMMI siempre deberían incluir

una descripción de las opciones de evaluación, el alcance del modelo, y el

alcance organizativo seleccionados. Esta documentación confirma si la

evaluación cumple o no los requisitos para hacer comparativas.

Para organizaciones que quieran evaluar varias funciones o grupos, el

enfoque integrado de CMMI posibilita algunas economías de escala en la

capacitación sobre el modelo y la evaluación. Un método de evaluación

puede proporcionar resultados separados o combinados para múltiples

funciones.

Los siguientes principios de las evaluaciones CMMI son iguales a los

utilizados en otros modelos de mejora de procesos:

Patrocinio de la dirección20

.

Foco en los objetivos de negocio de la organización.

Confidencialidad de las entrevistas.

Uso de un método de evaluación documentado.

Uso de un modelo de referencia de procesos (p. ej. un modelo CMMI).

Enfoque colaborativo de equipo.

Foco en acciones para mejorar los procesos.

Capacitación sobre CMMI

Tanto si su organización se está iniciando en la mejora de procesos como

si ya está familiarizada con modelos de mejora de procesos, la

capacitación es un factor clave para que la organización sea capaz de

adoptar CMMI. El SEI y su Red de Socios proporcionan un conjunto inicial

de cursos, aunque puede que su organización quiera complementar dichos

cursos con instrucción propia. Este enfoque permite que su organización se

centre en las áreas que proporcionen mayor valor para el negocio.

El SEI y su Red de Socios ofrecen el curso introductorio, Introducción a

CMMI para Servicios. El SEI también ofrece capacitación avanzada a

20

La experiencia ha demostrado que el factor crítico que más influye en el éxito de la mejora de procesos y las evaluaciones es

el patrocinio de la dirección.



quienes planeen estar involucrados más profundamente en adoptar o

evaluar CMMI –por ejemplo, a quienes van a guiar la mejora formando

parte del grupo de procesos, a quienes van a liderar las evaluaciones

SCAMPI, y a quienes van a impartir el curso Introducción a CMMI para

Servicios.

En sitio web del SEI en http://www.sei.cmu.edu/training/ dispone de

información actualizada acerca de capacitación sobre CMMI.

http://www.sei.cmu.edu/training/


59

Segunda Parte: Metas Genéricas y Prácticas Genéricas y las Áreas de

Proceso



METAS GENÉRICAS Y PRÁCTICAS GENÉRICAS

Visión general

Esta sección describe detalladamente todas las metas genéricas y

prácticas genéricas de CMMI — que son componentes de modelo que

abordan directamente la institucionalización de procesos. A medida que

aborde las áreas de proceso, puede consultar los detalles sobre todas las

prácticas genéricas en esta sección.

Las elaboraciones de prácticas genéricas aparecen después de la práctica

genérica para orientar sobre cómo puede aplicarse la práctica genérica de

forma única a las áreas de proceso.

Institucionalización de procesos

Institucionalizar es un concepto importante en la mejora de procesos.

Cuando se menciona en las descripciones de metas genéricas y de

prácticas genéricas, implica que el proceso está arraigado en la forma de

realizar el trabajo y que existe compromiso y consistencia para realizar

(esto es, ejecutar) el proceso.

En periodos bajo presión, un proceso institucionalizado tiene más

probabilidades de que se mantenga. Sin embargo, cuando los requisitos y

objetivos del proceso cambian, puede que también sea necesario cambiar

la implementación del proceso para asegurar que siga siendo eficaz. Las

prácticas genéricas describen las actividades que abordan estos aspectos

de la institucionalización.

El grado de institucionalización está incorporado en las metas genéricas y

se expresa por medio de los nombres de proceso asociados a cada meta,

como se indica en la Tabla 6.1.

Tabla 6.1 Metas genéricas y nombres de proceso

Meta Genérica Progresión de Procesos

GG 1 Proceso Realizado

GG 2 Proceso Gestionado

GG 3 Proceso Definido

La progresión en la institucionalización de procesos se caracteriza en las

descripciones de cada proceso que siguen.

Proceso Realizado

Un proceso realizado es un proceso que logra que se lleve a cabo el

trabajo que se necesita para satisfacer las metas específicas del área de

proceso.



Proceso Gestionado

Un proceso gestionado es un proceso realizado que se planifica y ejecuta

acorde a políticas; que emplea personas cualificadas que disponen de

recursos adecuados para producir resultados controlados; que involucra a

las partes interesadas relevantes; que se monitoriza, controla y revisa; y

para el que se evalúa el cumplimiento de su descripción de proceso.

El proceso puede estar instanciado por un grupo de trabajo, o por una

función organizativa. Quienes gestionan el proceso se preocupan de su

institucionalización y del logro de otros objetivos establecidos para el

proceso, tales como objetivos de costes, plazos, y calidad. El control que

proporciona un proceso gestionado ayuda a asegurar que el proceso se

conserva durante periodos bajo presión.

Los requisitos y objetivos del proceso son establecidos por la organización.

En puntos definidos, el estado de los productos de trabajo y servicios es

visible para la gerencia (p. ej., en los principales hitos y en la finalización de

las principales tareas). Se establecen compromisos, y se actualizan según

se necesite, entre quienes realizan el trabajo y las partes interesadas

relevantes. Los productos de trabajo se revisan con las partes interesadas

relevantes y se controlan. Los productos de trabajo y servicios satisfacen

sus requisitos especificados.

Una diferencia crítica entre un proceso realizado y un proceso gestionado

es el grado en que el proceso se gestiona. Un proceso gestionado se

planifica (el plan puede formar parte de un plan más amplio), y la ejecución

del proceso se gestiona con respecto al plan. Se realizan acciones

correctivas cuando los resultados y ejecución reales se desvían

significativamente del plan. Un proceso gestionado logra los objetivos del

plan y está institucionalizado para una ejecución consistente.

Proceso Definido

Un proceso definido es un proceso gestionado que se adapta a partir del

conjunto de procesos estándar de la organización siguiendo las guías de

adaptación de la organización; que tiene de una descripción de proceso

que se mantiene; y que contribuye a los activos de proceso organizativos

con experiencias relacionadas con procesos.

Los activos de proceso organizativos son artefactos relacionados con la

descripción, implementación, y mejora de procesos. Estos artefactos son

activos porque se desarrollan o adquieren para cumplir objetivos de

negocio de la organización, y porque representan una inversión de la

organización que se espera que proporcione valor para el negocio

actualmente y en el futuro.

El conjunto de procesos estándar de la organización, que es la base del

proceso definido, se establece y mejora a lo largo del tiempo. Los procesos

estándar describen qué elementos de proceso fundamentales se esperan

en los procesos definidos. Los procesos estándar también describen qué

relaciones hay (p. ej., el orden, las interfaces) entre estos elementos de

proceso. La infraestructura a nivel de organización para dar soporte al uso



actual y futuro del conjunto de procesos estándar de la organización se

establece y se mejora a lo largo del tiempo (véase la definición de “proceso

estándar” en el glosario).

El proceso definido de un grupo de trabajo proporciona la base para

planificar, realizar, y mejorar las tareas y actividades del trabajo. Un mismo

trabajo puede tener más de un proceso definido (p. ej., uno para desarrollar

el producto y otro para probarlo).

Un proceso definido establece claramente lo siguiente:

Propósito.

Entradas.

Criterios de entrada.

Actividades.

Roles.

Medidas.

Pasos de verificación.

Salidas.

Criterios de salida.

Una diferencia crítica entre un proceso gestionado y un proceso definido es

el alcance de la aplicación de las descripciones de proceso, estándares y

procedimientos. Para un proceso gestionado, las descripciones de proceso,

estándares, y procedimientos son aplicables a un grupo de trabajo o

función organizativa concreta. Como resultado, los procesos gestionados

de dos grupos de trabajo de la misma organización pueden ser distintos.

Otra diferencia crítica es que el proceso definido se describe más

detalladamente y se realiza más rigurosamente que el proceso gestionado.

Esta diferencia supone que la información de mejora es más fácil de

entender, analizar, y utilizar. Por último, la gestión del proceso definido se

basa en el conocimiento adicional que se obtiene al entender las

interrelaciones entre las actividades del proceso y las medidas detalladas

del proceso, sus productos de trabajo y sus servicios.

Relaciones entre procesos

Las metas genéricas se desarrollan para que cada meta proporcione la

base de la siguiente. Por tanto, se pueden extraer las siguientes

conclusiones:

Un proceso gestionado es un proceso realizado.

Un proceso definido es un proceso gestionado.

Así, aplicándolas secuencialmente y en orden, las metas genéricas

describen un proceso que, desde proceso realizado hasta proceso definido,

cada vez está más institucionalizado.

Lograr la GG 1 en un área de proceso equivale a decir que se logran las

metas específicas del área de proceso.



Lograr la GG 2 en un área de proceso equivale a decir que se gestiona la

ejecución de los procesos asociados al área de proceso. Hay una política

que indica que el proceso se realizará. Existe un plan para realizarlo. Se

dispone de recursos, se asignan responsabilidades, se proporciona

capacitación sobre cómo realizarlo, se controlan los productos de trabajo

seleccionados de la ejecución del proceso, etcétera. En otras palabras, el

proceso se planifica y monitoriza del mismo modo que cualquier otro

trabajo o actividad de soporte.

Lograr la GG 3 en un área de proceso equivale a decir que existe un

proceso estándar organizativo que, al adaptarlo, dará como resultado el

proceso que se utilizará. Un resultado de la adaptación podría ser no

cambiar nada en el proceso estándar. En otras palabras, el proceso a

utilizar y el proceso estándar pueden ser idénticos. Utilizar el proceso

estándar “tal y como está” es una adaptación porque la elección ha sido

que no hace falta modificar nada.

Cada área de proceso describe varias actividades, algunas de las cuales

se realizan repetidamente. Se puede necesitar adaptar la forma en que se

realiza una de estas actividades para dar cabida a nuevas capacidades o

circunstancias. Por ejemplo, puede haber un estándar para desarrollar u

obtener capacitación organizativa que no considere la capacitación basada

en web. Para preparar el desarrollo u obtención de un curso basado en

web, puede que se necesite adaptar el proceso estándar para tener en

cuenta los retos y beneficios concretos de este tipo de capacitación.

Metas genéricas y prácticas genéricas

Esta sección describe todas las metas genéricas y prácticas genéricas, así

como sus subprácticas, notas, ejemplos, y referencias asociadas. Las

metas genéricas están organizadas en orden numérico, GG 1 a GG 3. Las

prácticas genéricas también están organizadas en orden numérico bajo la

meta genérica a la que dan soporte.

GG 1 Lograr las metas específicas

El proceso da soporte a las metas específicas del área de proceso por medio de transformar productos de trabajo identificables de entrada en productos de trabajo identificables de salida.

GP 1.1 Realizar las prácticas específicas

Realizar las prácticas específicas del área de proceso para

desarrollar productos de trabajo y proporcionar servicios para

lograr las metas específicas del área de proceso.

El propósito de esta práctica genérica es producir los productos de trabajo

y prestar los servicios que se esperan al realizar (esto es, ejecutar) el

proceso. Estas prácticas se pueden realizar de manera informal, sin seguir

una descripción documentada de proceso o un plan. El rigor con que estas



prácticas se realizan depende de las personas que gestionan y realizan el

trabajo, y puede variar considerablemente.

GG 2 Institucionalizar un proceso gestionado

El proceso está institucionalizado como un proceso gestionado.

GP 2.1 Establecer una política organizativa

Establecer y mantener una política organizativa para planificar y

realizar el proceso.

El propósito de esta práctica genérica es definir las expectativas

organizativas para el proceso y hacerlas visibles a los miembros de la

organización que estén afectados. En general, la dirección es responsable

de establecer y comunicar los principios rectores, directrices y expectativas

de la organización.

No todas las directrices de la dirección llevarán la etiqueta de “políticas”. Lo

que se espera de esta práctica genérica es que existan directrices

organizativas apropiadas, independientemente de cómo se llamen o se

comuniquen.

Elaboración CAR

Esta política establece las expectativas organizativas sobre identificar y

abordar sistemáticamente el análisis causal de los resultados

seleccionados.

Elaboración CM

Esta política establece las expectativas organizativas sobre establecer y

mantener líneas base, seguir y controlar cambios a los productos de

trabajo (bajo gestión de configuración), y establecer y mantener la

integridad de líneas base. Esta política debería abordar la autorización e

implementación de cambios de emergencia.

Elaboración DAR

Esta política establece las expectativas organizativas sobre analizar

selectivamente posibles decisiones utilizando un proceso de evaluación

formal que evalúe alternativas identificadas frente a criterios establecidos.

La política también debería proporcionar orientación sobre qué decisiones

requieren un proceso de evaluación formal.

Elaboración IRP

Esta política establece las expectativas organizativas sobre establecer un

enfoque para la resolución y prevención de incidencias; identificar,

controlar y tratar las incidencias; y, para incidencias seleccionadas,

determinar soluciones temporales o abordar sus causas subyacentes.

Elaboración IWM


mantener el proceso definido para el trabajo desde el inicio y a lo largo del

ciclo de vida del trabajo, utilizar el proceso definido para gestionar el



trabajo, y coordinar a las partes interesadas relevantes y colaborar con

ellas.

Elaboración MA

Esta política establece las expectativas organizativas sobre alinear los

objetivos y actividades de medición con las necesidades de información

identificadas y con los objetivos de los grupos de trabajo, organizativos, o

de negocio, y sobre proporcionar resultados de medición.

Elaboración OPD


mantener un conjunto de procesos estándar para su uso en la

organización, poner a disposición de toda la organización los activos de

proceso organizativos, y establecer reglas y guías para los equipos.

Elaboración OPF

Esta política establece las expectativas organizativas sobre determinar

oportunidades de mejora de procesos para los procesos que estén en uso,

y sobre planificar, implementar y desplegar mejoras de procesos en toda la

organización.

Elaboración OPM

Esta política establece las expectativas organizativas sobre analizar el

rendimiento del negocio de la organización utilizando técnicas estadísticas

y otras técnicas cuantitativas para determinar carencias de rendimiento, e

identificar y desplegar mejoras de procesos y tecnológicas que contribuyan

a cumplir los objetivos de calidad y rendimiento de procesos.

Elaboración OPP


mantener líneas base de rendimiento de procesos y modelos de

rendimiento de procesos para el conjunto de procesos estándar de la

organización.

Elaboración OT

Esta política establece las expectativas organizativas sobre identificar las

necesidades estratégicas de capacitación de la organización y proporcionar

esa capacitación.

Elaboración PPQA

Esta política establece las expectativas organizativas sobre evaluar

objetivamente si los procesos y los productos de trabajo asociados

cumplen las descripciones de proceso, estándares, y procedimientos

aplicables, y sobre asegurar que las no-conformidades se traten.

Esta política también establece las expectativas organizativas sobre que el

aseguramiento de calidad procesos y productos esté implantado en todos

los trabajos. El aseguramiento de calidad de procesos y productos debe

ser suficientemente independiente de quien gestiona el grupo de trabajo



para proporcionar objetividad al identificar y reportar problemas de no

conformidad.

Elaboración QWM

Esta política establece las expectativas organizativas sobre utilizar técnicas

estadísticas y otras técnicas cuantitativas y datos históricos: al establecer

objetivos de calidad y rendimiento de procesos, al componer el proceso

definido para el trabajo, al seleccionar atributos de subprocesos que son

críticos para entender el rendimiento de procesos, al monitorizar el

rendimiento de los subprocesos y del trabajo, y al realizar análisis de

causas raíces para abordar deficiencias de rendimiento de procesos. En

concreto, esta política establece las expectativas organizativas sobre el uso

de medidas, líneas base, y modelos de rendimiento de procesos.

Elaboración REQM

Esta política establece las expectativas organizativas sobre gestionar

requisitos e identificar inconsistencias entre los requisitos y planes de

trabajo y productos de trabajo.

Elaboración RSKM

Esta política establece las expectativas organizativas sobre definir

estrategias de gestión de riesgos e identificar, analizar, y mitigar los

riesgos.

Elaboración SAM

Esta política establece las expectativas organizativas sobre establecer,

mantener, y satisfacer acuerdos de suministro.

Elaboración SCON

Esta política establece las expectativas organizativas sobre establecer un

plan de continuidad del servicio que posibilite reanudar servicios clave

después de una alteración significativa en la prestación de servicios,

proveer capacitación sobre la ejecución del plan, y verificar y validar el

plan.

Elaboración SD

Esta política establece las expectativas organizativas sobre definir un

enfoque de prestación de servicios, establecer acuerdos de servicio,

procesar peticiones de servicio, y prestar servicios.



Extensión SSD

Elaboración SSD

Esta política establece las expectativas organizativas para:

Recopilar necesidades de las partes interesadas, formular

requisitos de servicio y de componentes de sistema de servicio, y

analizar y validar dichos requisitos.

Realizar el ciclo iterativo en el que, se seleccionan soluciones para

el sistema de servicio, se desarrollan diseños del sistema de

servicio y de componentes de sistema de servicio, se gestiona la

compatibilidad de los interfaces, se implementan los diseños del

sistema de servicio, y se integran componentes de sistema de

servicio.

Establecer y mantener métodos, procedimientos, criterios y

entornos de verificación y validación; realizar revisiones entre

pares; y verificar los productos de trabajo seleccionados.

Elaboración SST

Esta política establece las expectativas organizativas sobre planificar,

implementar, y gestionar la transición de los componentes de sistema de

servicio al entorno de prestación de servicios.

Elaboración STSM


mantener un conjunto de servicios estándar para su uso en la organización

y poner las descripciones de servicio estándar a disposición de toda la

organización.

Elaboración WMC

Esta política establece las expectativas organizativas sobre monitorizar el

progreso y rendimiento del trabajo frente al plan de trabajo, y gestionar las

acciones correctivas hasta su cierre cuando los resultados o ejecución

reales se desvíen significativamente del plan.

Elaboración WP

Esta política establece las expectativas organizativas sobre estimar

parámetros de planificación, realizar compromisos internos y externos, y

desarrollar el plan para gestionar el trabajo.

GP 2.2 Planificar el proceso

Establecer y mantener el plan para realizar el proceso.

El propósito de esta práctica genérica es determinar qué se necesita para

realizar el proceso y para lograr los objetivos establecidos, preparar un plan

para realizar el proceso, preparar una descripción del proceso, y acordar el

plan con las partes interesadas relevantes.



Las implicaciones prácticas de aplicar la práctica genérica son distintas

para cada área de proceso.

Por ejemplo, la planificación descrita en esta práctica genérica aplicada al área de proceso

Monitorización y Control de Trabajos puede llevarse a cabo completamente con los

procesos del área de proceso Planificación de Trabajos. Sin embargo, esta práctica

genérica, aplicada al área de proceso Planificación de Trabajos, establece la expectativa de

que se planifique el propio proceso de planificación de trabajos.

Por consiguiente, esta práctica genérica puede reforzar expectativas

establecidas en otras partes de CMMI o establecer nuevas expectativas

que se deberían abordar.

Para más información sobre establecer y mantener planes que definan las

actividades de los trabajos, consúltese el área de proceso Planificación de

Trabajos.

Establecer un plan incluye documentar el plan y una descripción de

proceso. Mantener el plan incluye actualizarlo para reflejar acciones

correctivas o cambios en requisitos u objetivos.

El plan para realizar el proceso habitualmente incluye:

Descripción del proceso.

Estándares y requisitos para los productos de trabajo y los servicios del proceso.

Objetivos específicos para la ejecución del proceso y sus resultados (p. ej. calidad,

escala temporal, tiempo de ciclo, uso de recursos).

Dependencias entre actividades, productos de trabajo, y servicios del proceso.

Recursos (p. ej. financiación, personas, herramientas) que se necesitan para realizar el

proceso.

Asignaciones de responsabilidad y autoridad.

Capacitación que se necesita para realizar y dar soporte al proceso.

Productos de trabajo a controlar y nivel de control a aplicar.

Requisitos de medición para explicar la ejecución del proceso, sus productos de

trabajo, y sus servicios.

Involucración de las partes interesadas relevantes.

Actividades para monitorizar y controlar el proceso.

Actividades para evaluar objetivamente el proceso.

Actividades de revisión del proceso y los productos de trabajo por parte de la gerencia.

Subprácticas

1. Definir y documentar el plan para realizar el proceso.

Este plan puede ser un documento independiente, formar parte de un documento más

general, o estar distribuido entre varios documentos. Para el caso en el que el plan se

distribuya entre varios documentos, asegurar que se preserva una imagen coherente

de quién hace qué. Los documentos pueden estar en papel o en formato electrónico.

2. Definir y documentar la descripción del proceso.



Las descripciones de proceso, que incluyen estándares y procedimientos relevantes,

pueden formar parte del plan para realizar el proceso o pueden estar referenciadas en

el plan.

3. Revisar y acordar el plan con las partes interesadas relevantes.

Para proporcionar confianza a las partes interesadas relevantes, esta revisión del plan

incluye revisar que el proceso planificado satisface las políticas, planes, requisitos, y

estándares aplicables.

4. Actualizar el plan según se necesite.

Elaboración CAM

Este plan para realizar el proceso de gestión de capacidad y disponibilidad

puede formar parte de (o estar referenciado por) el plan de trabajo, el cual

se describe en el área de proceso Planificación de Trabajos.

Elaboración CAR

Este plan para realizar el proceso de análisis causal y resolución puede

formar parte de (o estar referenciado por) el plan de trabajo, el cual se

describe en el área de proceso Planificación de Trabajos. Este plan es

distinto de las propuestas de acción y las acciones descritas en varias

prácticas específicas de esta área de proceso. El plan al que se refiere la

práctica genérica aborda el proceso global del grupo de trabajo de análisis

causal y resolución (puede que adaptado a partir del proceso estándar que

mantiene la organización). Por contra, las propuestas de acciones de

proceso y las acciones asociadas abordan las actividades necesarias para

abordar una causa raíz específica bajo estudio.

Elaboración CM

Este plan para realizar el proceso de gestión de configuración puede


describe en el área de proceso Planificación de Trabajos.

Elaboración DAR

Este plan para realizar el proceso de análisis de decisiones y resolución



Elaboración IRP

Este plan para realizar el proceso de resolución y prevención de

incidencias puede formar parte de (o estar referenciado por) el plan de

trabajo, el cual se describe en el área de proceso Planificación de Trabajos.

Este plan habitualmente se basa en una estimación del volumen y tipo de

incidencias en el servicio.

Elaboración IWM

Este plan para realizar el proceso de gestión integrada de trabajos unifica

las planificaciones de los procesos de planificación trabajos y

monitorización y control de trabajos. La planificación para realizar las

prácticas de planificación dentro de Gestión Integrada de Trabajos se



aborda como parte de planificar el proceso de planificación de trabajos.

Este plan para realizar las prácticas de monitorización y control dentro de

Gestión Integrada de Trabajos puede formar parte (o estar referenciado

por) el plan de trabajo, el cual se describe en el área de proceso

Planificación de Trabajos.

Elaboración MA

Este plan para realizar el proceso de medición y análisis puede formar

parte de (o estar referenciado por) el plan de trabajo, el cual se describe en

el área de proceso Planificación de Trabajos.

Elaboración OPD

Este plan para realizar el proceso de definición organizativa de procesos

puede formar parte de (o estar referenciado por) el plan de mejora de

procesos de la organización.

Elaboración OPF

Este plan para realizar el proceso de enfoque organizativo en procesos,

que a menudo se denomina “el plan de mejora de procesos”, difiere de los

planes de acciones de proceso descritos en las prácticas específicas de

esta área de proceso. El plan al que hace referencia esta práctica genérica

aborda planificar globalmente todas las prácticas específicas de esta área

de proceso, desde establecer las necesidades de procesos organizativas

hasta incorporar en los activos de proceso organizativos las experiencias

relacionadas con procesos.

Elaboración OPM

Este plan para realizar el proceso de gestión del rendimiento organizativo

difiere de los planes de despliegue descritos en una práctica específica de

esta área de proceso. El plan al que hace referencia esta práctica genérica

aborda planificar globalmente todas las prácticas específicas de esta área

de proceso, desde mantener los objetivos de negocio hasta evaluar los

efectos de las mejoras. Por contra, los planes de despliegue a los que se

hace referencia en la práctica específica abordarían la planificación que se

necesita para desplegar mejoras seleccionadas.

Elaboración OPP

Este plan para realizar el proceso de rendimiento organizativo de procesos

puede formar parte de (o estar referenciado por) el plan de mejora de

procesos de la organización, el cual se describe en el área de proceso

Enfoque Organizativo en Procesos. También podría documentarse en un

plan separado que describa únicamente el plan del proceso de rendimiento

organizativo de procesos.

Elaboración OT

Este plan para realizar el proceso de capacitación organizativa difiere del

plan táctico de capacitación organizativa descrito en una práctica

específica de esta área de proceso. El plan al que hace referencia esta

práctica genérica aborda la planificación global de todas las prácticas

específicas de esta área de proceso, desde establecer las necesidades



estratégicas de capacitación hasta evaluar la eficacia de la capacitación

organizativa. Por contra, el plan táctico de capacitación organizativa, al que

hace referencia la práctica específica de esta área de proceso, aborda la

planificación periódica de la impartición de la capacitación ofrecida.

Elaboración PPQA

Este plan para realizar el proceso de aseguramiento de calidad de

productos y procesos puede formar parte de (o estar referenciado por) el

plan de trabajo, el cual se describe en el área de proceso Planificación de

Trabajos.

Elaboración QWM

Este plan para realizar el proceso de gestión cuantitativa de trabajos puede


describe en el área de proceso Planificación de Trabajos.

Elaboración REQM

Este plan para realizar el proceso de gestión de requisitos puede formar



Elaboración RSKM

Este plan para realizar el proceso de gestión de riesgos puede formar parte

de (o estar referenciado por) el plan de trabajo, el cual se describe en el

área de proceso Planificación de Trabajos. El plan al que hace referencia

esta práctica genérica aborda la planificación global de todas las prácticas

específicas de esta área de proceso. En concreto, este plan proporciona el

enfoque global para la mitigación de riesgos, pero es distinto de los planes

de mitigación de riesgos (incluyendo los planes de contingencia) de los

riesgos específicos. Por contra, los planes de mitigación de riesgos a los

que se hace referencia en las prácticas específicas de esta área de

proceso abordan elementos más concretos, tales como los niveles que

desencadenan las actividades para manejar los riesgos.

Elaboración SAM

Algunas secciones de este plan para realizar el proceso de gestión de

acuerdos de suministro pueden formar parte de (o estar referenciadas por)

el plan de trabajo, el cual se describe en el área de proceso Planificación

de Trabajos. Sin embargo, otras secciones del plan a menudo residen

fuera del grupo de trabajo, en grupos tales como el de gestión de contratos.

Elaboración SCON

Este plan para realizar el proceso de continuidad del servicio puede formar


el área de proceso Planificación de Trabajos. Alternativamente, este plan

puede formar parte de un plan de continuidad del negocio más amplio que

se mantenga a nivel organizativo.

En cualquier caso, el plan para realizar el proceso de continuidad del

servicio difiere de los planes de continuidad del servicio descritos en una



práctica específica de esta área de proceso. El plan al que hace referencia

esta práctica genérica aborda planificar globalmente todas las prácticas

específicas de esta área de proceso, desde identificar y priorizar las

funciones esenciales hasta analizar los resultados de verificación y

validación. Por contra, los planes de continuidad del servicio a los que hace

referencia una de las prácticas específicas de esta área de proceso

abordan el modo en que se recuperan los servicios clave después de una

alteración significativa en la prestación de servicios.

Elaboración SD

Este plan para realizar el proceso de prestación de servicios puede formar



Extensión SSD

Elaboración SSD

Este plan para realizar el proceso de desarrollo del sistema de servicio

puede formar parte de (o estar referenciado por) el plan de trabajo, el

cual se describe en el área de proceso Planificación de Trabajos.

Elaboración SST

El plan global de transición del sistema de servicio puede formar parte de

(o estar referenciado por) el plan de trabajo, el cual se describe en el área

de proceso Planificación de Trabajos. Adicionalmente, la planificación

asociada a una transición del sistema de servicio concreta habitualmente

se aborda en un plan de transición del sistema de servicio.

Este plan para realizar el proceso de transición del sistema de servicio

difiere de los planes de transición del sistema de servicio descritos en una

práctica específica de esta área de proceso. El plan al que hace referencia

esta práctica genérica aborda planificar globalmente todas las prácticas

específicas de esta área de proceso, desde analizar las necesidades de

transición del sistema de servicio hasta evaluar y controlar los impactos de

la transición. Por contra, los planes de transición del sistema de servicio a

los que hace referencia la práctica específica de esta área de proceso

abordan la planificación de transiciones del sistema de servicio específicas.

Elaboración STSM

Este plan para realizar el proceso de gestión estratégica de servicios difiere

de los planes para los servicios estándar descritos en las prácticas

específicas de esta área de proceso. El plan al que hace referencia esta

práctica genérica aborda la planificación global de todas las prácticas

específicas de esta área de proceso.



Elaboración WMC

Este plan para realizar el proceso de monitorización y control de trabajos



Elaboración WP

Para más información sobre las relaciones entre la práctica genérica 2.2 y

el área de proceso Planificación de Trabajos, consúltese la tabla 6.2.

GP 2.3 Proporcionar recursos

Proporcionar recursos adecuados para realizar el proceso,

desarrollar los productos de trabajo, y proporcionar los servicios

del proceso.

El propósito de esta práctica genérica es asegurar que los recursos que se

necesitan para realizar el proceso definidos en el plan están disponibles

cuando hacen falta. Los recursos incluyen financiación, instalaciones

físicas apropiadas, personas cualificadas, y herramientas apropiadas

adecuadas.

La interpretación del término “adecuadas” depende de muchos factores

que pueden cambiar a lo largo del tiempo. La falta de recursos adecuados

puede abordarse incrementando los recursos o eliminando requisitos,

restricciones, y compromisos.

Elaboración CAM

Algunos ejemplos de recursos proporcionados son:

Herramientas de análisis remoto.

Herramientas de monitorización.

Elaboración CAR


Sistemas de gestión de bases de datos.

Herramientas de modelado de procesos.

Paquetes de análisis estadístico.

Métodos y técnicas de análisis (p. ej. diagramas de Ishikawa o de espina de pescado,

análisis de Pareto, histogramas, estudios de capacidad de proceso, gráficos de

control).

Elaboración CM


Herramientas de gestión de configuración.

Herramientas de gestión de datos.

Herramientas de archivo y reproducción.




Elaboración DAR


Simuladores y herramientas de modelado.

Herramientas de prototipado.

Herramientas para realizar encuestas.

Elaboración IRP


Herramientas de atención a usuarios.

Herramientas de análisis remoto.

Herramientas automatizadas de monitorización.

Sistemas de gestión de incidencias.

Elaboración IWM


Paquetes de seguimiento y reporte de problemas.

Software colaborativo (groupware).

Videoconferencia.

Bases de datos de decisión integradas.

Entornos integrados de soporte al producto.

Elaboración MA

Personal con competencias apropiadas da soporte a las actividades de

medición y análisis. Puede existir un grupo de medición con ese rol.


Paquetes estadísticos.

Paquetes de soporte a la recogida de datos por medio de redes.

Elaboración OPD

Habitualmente, un grupo de procesos gestiona las actividades de definición

organizativa de procesos. Este grupo habitualmente se dota de un núcleo

de profesionales cuya principal responsabilidad es coordinar la mejora de

procesos organizativa.



Este grupo está soportado por propietarios de procesos y por personas con competencias

en distintas disciplinas tales como:

Gestión de proyectos.

Gestión de servicios.

Las disciplinas de servicio apropiadas.

Gestión de configuración.

Aseguramiento de calidad.




Herramientas de construcción de páginas web y navegadores.

Elaboración OPF



Herramientas de mejora de procesos.

Herramientas de construcción de páginas web y navegadores.

Software colaborativo (groupware).

Herramientas de mejora de la calidad (p. ej. diagramas causa-efecto, diagramas de

afinidad, diagramas de Pareto).

Elaboración OPM

Algunos ejemplos de recursos proporcionados incluyen las siguientes herramientas:

Paquetes de simulación.


Paquetes estadísticos.

Modelado dinámico de sistemas.

Suscripciones a bases de datos y publicaciones tecnológicas en línea.


Elaboración OPP

Puede que, para establecer las líneas base de rendimiento de procesos del

conjunto de procesos estándar de la organización, sean necesarias

competencias especiales en estadística y otras técnicas cuantitativas.





Modelos de dinámica de sistemas.



Paquetes de seguimiento de problemas.

Elaboración OT


Expertos en la materia.

Diseñadores de curricula.

Diseñadores de cursos.

Instructores.

Administradores de capacitación.

Puede que sea necesario disponer de instalaciones especiales para la

capacitación. Cuando es necesario, las instalaciones que se requieren para

las actividades del área de proceso Capacitación Organizativa se

desarrollan o se compran.


Instrumentos para analizar las necesidades de capacitación.

Estaciones de trabajo a utilizar durante la capacitación.

Herramientas de diseño de cursos.

Paquetes para desarrollar materiales a presentar.

Elaboración PPQA


Herramientas de evaluación.

Herramientas de seguimiento de no conformidades.

Elaboración QWM

Para definir las técnicas analíticas a utilizar en la gestión cuantitativa,

puede que se necesiten competencias especiales en estadística y su

aplicación al análisis del rendimiento de procesos. También puede que se

necesiten competencias especiales para analizar e interpretar las medidas

que resulten de los análisis estadísticos; sin embargo, los equipos tienen

que ser suficientemente competentes como para ser capaces de entender

a nivel básico su rendimiento de procesos a medida que realizan su trabajo

diario.





Paquetes de control de estadístico de procesos y control de calidad.

Guiones y herramientas que ayuden a los equipos a analizar su propio rendimiento de

procesos con un mínimo de ayuda adicional por parte de expertos.

Elaboración REQM


Herramientas de seguimiento de requisitos.

Herramientas de trazabilidad.

Elaboración RSKM


Bases de datos de gestión de riesgos.

Herramientas de mitigación de riesgos.


Herramientas de modelado y simulación.

Elaboración SAM


Lista de suministradores preferentes.

Herramientas de seguimiento de requisitos.

Programas de gestión de proyectos y planificación.

Elaboración SCON

La continuidad del servicio se basa en obtener recursos que deben ser

especiales y adecuados. Para asegurar la continuidad de las operaciones

del sistema de servicio en caso de alteraciones significativas, se deberían

identificar, comprar, y preparar de antemano ubicaciones remotas, redes

seguras, instalaciones, y equipamientos. Para preparar a los responsables

de implementar el plan de continuidad del servicio, puede que sean

necesarias instalaciones de capacitación especiales y recursos

relacionados. Finalmente, puede que sea necesario desarrollar o comprar

instalaciones, equipamientos y recursos especiales de pruebas para

verificar y validar la preparación de la continuidad del servicio.




Mecanismos y redes de respaldo de comunicaciones.

Utilidades de respaldo y restauración de ficheros.

Puestos de trabajo a utilizar durante la capacitación.


Herramientas de gestión de pruebas.

Elaboración SD

La prestación de servicios requiere operar un sistema de servicio apropiado

que incluya personal capacitado, infraestructura, herramientas, procesos,

consumibles, y otros recursos. Además, la operación del sistema de

servicio impone una necesidad constante de recursos adecuados. Por

ejemplo, con el tiempo puede que sea necesario actualizar, reemplazar, o

eliminar componentes del sistema de servicio; puede que sea necesario

recapacitar, aumentar, rotar o reducir el personal de prestación de

servicios; y puede que sea necesario reponer consumibles para asegurar

que los servicios se presten conforme a los acuerdos de servicio.

Puede que sea necesario desarrollar o comprar parte de los componentes

de sistema de servicio, y esta restricción puede que requiera de la

obtención de recursos que se describe en las áreas de proceso Desarrollo

del Sistema de Servicio y Gestión de Acuerdos de Suministro.


Sistemas de gestión de peticiones.

Herramientas automáticas de monitorización.



Extensión SSD

Elaboración SSD


Herramientas de especificación de requisitos.



Herramientas de definición y seguimiento de escenarios.

Herramientas de especificación de diseños.

Herramientas de fabricación y ensamblaje.

Herramientas de gestión de pruebas.

Herramientas de generación de casos de prueba.


Instalaciones y entornos de prueba.

Elaboración SST


Personal de soporte a la transición.

Herramientas de instalación y despliegue.

Mecanismos de suspensión y de recuperación.

Elaboración STSM

Las prácticas de gestión estratégica de servicios habitualmente son

gestionadas por directivos, planificadores estratégicos, gerentes de cartera

de servicios, gerentes de producto, o gerentes de línea de productos


Fuentes de datos sobre necesidades y capacidades estratégicas.

Herramientas de gestión documental o de gestión de configuración.

Técnicas de gestión de servicios.

Elaboración WMC


Sistemas de seguimiento de costes.

Sistemas para reportar esfuerzos.

Sistemas de seguimiento de acciones.

Programas de gestión de proyectos y planificación.

Elaboración WP

Para planificar el trabajo puede que sean necesarias competencias,

equipamientos, e instalaciones especiales.



Las competencias especiales para planificación de trabajos pueden incluir:

Estimadores experimentados

Planificadores.

Expertos técnicos en las áreas aplicables (p. ej. dominio del producto, tecnología).


Programas de hoja de cálculo.

Modelos de estimación.

Paquetes de gestión de proyectos y planificación.

GP 2.4 Asignar responsabilidades

Asignar responsabilidades y autoridades para realizar el proceso,

desarrollar los productos de trabajo, y proporcionar los servicios

del proceso.

El propósito de esta práctica genérica es asegurar que sobre la ejecución

del proceso y el logro de los resultados especificados se efectúa una

rendición de cuentas durante toda la vida del proceso. Las personas

asignadas deben tener una autoridad apropiada para llevar a cabo las

responsabilidades que tengan asignadas.

Se pueden asignar responsabilidades utilizando descripciones detalladas

de trabajo o documentos vivos, tales como el plan para realizar el proceso.

La asignación dinámica de responsables es otra forma legítima de

implementar esta práctica genérica, siempre y cuando la asignación y

aceptación de responsabilidades esté asegurada durante toda la vida del

proceso.

Subprácticas

1. Asignar la responsabilidad y autoridad global para realizar el proceso.

2. Asignar responsabilidades y autoridades para realizar las tareas

específicas del proceso.

3. Confirmar que las personas que tienen asignadas responsabilidades y

autoridades las entienden y las aceptan.

Elaboración IRP

Se asignan responsabilidades tanto para el primer nivel de gestión de

incidencias en el servicio (p. ej. atención a usuarios) como para el segundo

nivel de gestión (p. ej. grupos de soporte organizados por sistema,

plataforma, función, tecnología).

Elaboración PPQA

Se asignan responsabilidades a quienes puedan realizar evaluaciones de

aseguramiento de calidad de procesos y productos con independencia y

objetividad suficientes como para que estén protegidos de subjetividades o

prejuicios.



Elaboración SCON

Se asignan responsabilidades al equipo (o grupo de trabajo) de gestión de

respaldo de la organización para que, en caso de alteraciones

significativas, tomen el control de las responsabilidades de gestión.

Elaboración SD

Se asignan responsabilidades para establecer acuerdos de servicio,

aceptar peticiones de servicio, comunicar información sobre el estado (p.

ej. por parte de atención a usuarios), operar y mantener el sistema de

servicio, procesar las peticiones de servicio, y resolver incidencias en el

servicio (p. ej. por parte de grupos de soporte organizados por servicio,

plataforma, función, tecnología).

Extensión SSD

Elaboración SSD

Para sistemas de servicio que tengan un diseño complejo, o una

mezcla de personas, hardware y software, o componentes de varios

suministradores, designar a un líder o arquitecto jefe para que

supervise la solución técnica del sistema de servicio y que tenga

autoridad sobre las decisiones de diseño ayuda a mantener la

consistencia en el diseño del sistema de servicio y en su evolución.

Elaboración SST

Se asignan responsabilidades para planificar, implementar, y gestionar la

transición. Adicionalmente, las actividades de notificación a las partes

interesadas se asignan explícitamente, de modo que se asegure la

comunicación abierta y la participación. Se realizan asignaciones para

revertir y suspender en caso de transiciones que no sea exitosas.

GP 2.5 Capacitar a las personas

Capacitar a las personas que realizan o dan soporte al proceso

según se necesite.

El propósito de esta práctica genérica es asegurar que las personas tengan

las habilidades y competencias necesarias para realizar o dar soporte al

proceso.

Se proporciona capacitación apropiada a quienes van a realizar el trabajo.

Se proporciona capacitación general para orientar a las personas que

interactúan con quienes realizan el trabajo.

El auto-estudio, la capacitación auto dirigida, la instrucción programada auto regulada, la

capacitación formalizada en el puesto de trabajo, la tutorización, y la capacitación formal y

en aulas son ejemplos de métodos para proporcionar capacitación.



La capacitación da soporte a que el proceso se ejecute con éxito al

establecer un entendimiento del proceso común e impartir las habilidades y

conocimientos que se necesitan para realizarlo.

Para más información sobre desarrollar las habilidades y conocimientos de

las personas de modo que puedan realizar sus roles eficaz y

eficientemente, consúltese el área de proceso Capacitación Organizativa.

Elaboración CAM

Algunos ejemplos de temas de capacitación son:

Roles, responsabilidades, y autoridad del personal de gestión de capacidad y

disponibilidad.

Estándares, procedimientos, y métodos de gestión de capacidad y disponibilidad.

Elaboración CAR

Un ejemplo de tema de capacitación es:

Métodos de gestión de calidad (p. ej. análisis de causas raíces).

Elaboración CM


Roles, responsabilidades, y autoridad del personal de gestión de configuración.

Estándares, procedimientos y métodos de gestión de configuración.

Sistemas de biblioteca de configuración.

Elaboración DAR


Análisis de decisiones formales.

Métodos para evaluar soluciones alternativas frente a criterios.

Elaboración IRP


Criterios sobre incidencias en el servicio.

Interacción entre quienes reportan incidencias en el servicio y quienes están afectados

por ellas.

Sistemas de gestión de incidencias.

Técnicas de análisis (p. ej. diagramas de Ishikawa o espina de pescado, análisis de

Pareto, histogramas).



Elaboración IWM


Adaptación del conjunto de procesos estándar de la organización para que cumpla las

necesidades del trabajo.

Procedimientos de gestión del trabajo en base al proceso definido para el trabajo.

Uso del repositorio de mediciones de la organización.

Uso de activos de proceso organizativos.

Gestión integrada.

Coordinación entre grupos.

Resolución de problemas en grupo.

Construcción de la visión compartida del grupo de trabajo.

Construcción de equipos.

Elaboración MA


Técnicas estadísticas.

Procesos de recogida de datos, análisis, y reporte.

Desarrollo de mediciones relacionadas con objetivos (p. ej. Meta Pregunta Métrica).

Elaboración OPD


CMMI y otros modelos de referencia de procesos y de mejora de procesos.

Procesos de planificación, gestión, y monitorización.

Modelado y definición de procesos.

Desarrollo de procesos estándar adaptables.

Desarrollo de estándares de entorno de trabajo.

Ergonomía.

Elaboración OPF


CMMI y otros modelos de referencia de mejora de procesos.

Planificación y gestión de mejora de procesos.

Herramientas, métodos, y técnicas de análisis.

Modelado de procesos.

Técnicas de facilitación.

Gestión del cambio.



Elaboración OPM


Análisis de coste beneficio.

Planificación, diseño y realización de pilotos.

Transición tecnológica.

Gestión del cambio.

Elaboración OPP


Modelado de procesos y de mejora de procesos.

Métodos estadísticos y otros métodos cuantitativos (p. ej. modelos de estimación,

análisis de Pareto, gráficos de control).

Elaboración OT


Análisis de necesidades de conocimientos y habilidades.

Diseño de cursos.

Técnicas de instrucción (p. ej. capacitador de capacitadores).

Cursos de repaso sobre una materia.

Elaboración PPQA


Dominio de aplicación.

Relaciones con clientes.

Descripciones de proceso, estándares, procedimientos, y métodos para el trabajo.

Objetivos, descripciones de proceso, estándares, procedimientos, métodos, y

herramientas de aseguramiento de calidad.

Elaboración QWM


Análisis básicos cuantitativos (incluyendo estadísticos) que ayuden a analizar el

rendimiento de procesos, a utilizar datos históricos, y a identificar cuando está

justificado realizar acciones correctivas.

Modelado y análisis de procesos.

Selección, definición y, recogida de datos de medición de procesos.



Elaboración REQM



Definición, análisis, revisión, y gestión de requisitos.

Herramientas de gestión de requisitos.

Gestión de configuración.

Negociación y resolución de conflictos.

Elaboración RSKM


Conceptos y actividades de gestión de riesgos (p. ej. identificación, evaluación,

monitorización, y mitigación de riesgos).

Selección de medidas de mitigación de riesgos.

Elaboración SAM


Regulaciones y prácticas de negocio relacionadas con negociación y trabajo con

suministradores.

Planificación y preparación de adquisiciones.

Adquisición de productos comerciales.

Evaluación y selección de suministradores.

Negociación y resolución de conflictos.

Gestión de suministradores.

Pruebas y transición de productos adquiridos.

Recepción, almacenaje, utilización, y mantenimiento de productos adquiridos.

Elaboración SCON


Sistemas de servicio y sus componentes.

Funciones de negocio y recursos que se utilizan para dar soporte a la operación del

sistema de servicio (y, por tanto, a la prestación de servicios).

Contenidos del plan de continuidad del servicio.

Actividades relevantes de preparación frente a desastres locales, regionales o

nacionales.



Elaboración SD


Roles, responsabilidades, y autoridades del personal de prestación de servicios.

Estándares, procedimientos, y métodos sobre acuerdos de servicio, peticiones de

servicio, y prestación de servicios.

Sistemas de gestión de peticiones.

Otros componentes de sistema de servicio.

Extensión SSD

Elaboración SSD


Conocimientos especializados en dominios de servicio concretos.

Definición, análisis, recabado, especificación, modelado, y seguimiento de

requisitos.

Métodos de diseño.

Patrones comunes de diseño de componentes e interfaces del sistema de

servicio.

Estándares (p. ej. sobre productos, seguridad, factores humanos, protección,

entregas, medio ambiente).

Métodos, herramientas, e instalaciones para integración.

Principios, estándares, métodos, herramientas, e instalaciones de

verificación y validación.

Preparación y procedimientos sobre revisiones entre pares.

Facilitación de reuniones.

Elaboración SST


Planificación y monitorización de transiciones.

Estrategias de notificación de transiciones.

Enfoques de reversión y suspensión.

Proceso de revisión post-despliegue.



Elaboración STSM


Técnicas de planificación estratégicas, tales como planificación de escenarios, DAFO,

y análisis de necesidades.

Técnicas de investigación de mercado.

Planificación y gestión de productos.

Gestión de carteras.

Comunicación de marketing.

Elaboración WMC


Monitorización y control de trabajos.

Gestión de riesgos.

Gestión de datos.

Elaboración WP


Estimación.

Elaboración de presupuestos.

Negociación.

Identificación y análisis de riesgos.

Gestión de datos.

Planificación.

Programación en el tiempo.

GP 2.6 Controlar los productos de trabajo

Poner los productos de trabajo seleccionados bajo los niveles de

control apropiados.

El propósito de esta práctica genérica es establecer y mantener la

integridad de los productos de trabajo del proceso seleccionados (o sus

descripciones) durante su vida útil.

Los productos de trabajo se identifican específicamente, junto con las

especificaciones de los niveles de control apropiados, en el plan para

realizar el proceso.

Para diferentes productos de trabajo y momentos distintos son apropiados

niveles de control diferentes. Para algunos productos de trabajo, puede que

sea suficiente mantener un control de versiones, de forma que se sepa cuál

es la versión del producto de trabajo en uso en un momento dado, pasado

o presente, y que los cambios se incorporen de forma controlada. El control

de versiones usualmente está bajo el control exclusivo del propietario del

producto de trabajo (que puede ser un individuo, un grupo, o un equipo).



A veces, puede ser crítico poner los productos de trabajo bajo gestión de

configuración formal o de línea base. Este tipo de control incluye definir y

establecer líneas base en puntos predeterminados. Estas líneas base se

revisan y aprueban formalmente, y sirven como base para el desarrollo

posterior de los productos de trabajo designados.

Para más información sobre establecer y mantener la integridad de los

productos de trabajo por medio de identificar la configuración, controlar la

configuración, registrar el estado de la configuración, y las auditorías de

configuración, consúltese al área de proceso Gestión de Configuración.

Es posible tener niveles de control adicionales entre el de control de

versiones y el de gestión de configuración formal. Un mismo producto de

trabajo identificado puede estar bajo niveles de control diferentes en

momentos distintos.

Elaboración CAM

Algunos ejemplos de productos de trabajo puestos bajo control son:

Registros de gestión de capacidad y disponibilidad.

Informes de gestión de capacidad y disponibilidad.

Elaboración CAR


Propuestas de acción.

Propuestas de acción seleccionadas para implementar.

Registros de análisis causal y resolución.

Elaboración CM

Debería haber suficientes niveles de control para cumplir las necesidades

de negocio, mitigar el riesgo de fallos, y abordar la criticidad de los

servicios.


Listas de acceso.

Informes de situación de los cambios.

Copias de la base de datos de peticiones de cambios.

Actas de reuniones del CCB.

Líneas base archivadas.

Puntos de contacto clave para la prestación de servicios.

Elaboración DAR


Guías sobre cuándo aplicar los procesos de evaluación formal.

Informes de evaluación que contengan soluciones recomendadas.



Elaboración IRP


Registros de gestión de incidencias.

Informes de resolución y prevención de incidencias.


Descripción e instrucciones sobre soluciones temporales.

Copias de la base de datos de incidencias.

Elaboración IWM


Proceso definido para el trabajo.

Planes de trabajo.

Otros planes que afecten al trabajo.

Planes integrados.

Mediciones reales de proceso y de producto recogidas del trabajo.

Visión compartida.

Estructura del equipo.

Estatutos de los equipos.

Elaboración MA


Objetivos de medición.

Especificación de medidas base y derivadas.

Procedimientos de recogida y almacenamiento de datos.

Conjuntos de datos de medición base y derivados.

Resultados de análisis e informes preliminares.

Herramientas de análisis de datos.

Elaboración OPD


Conjunto de procesos estándar de la organización.

Descripciones de modelos de ciclo de vida.

Guías de adaptación para el conjunto de procesos estándar de la organización.

Definiciones del conjunto de medidas comunes de producto y de proceso.

Datos de medición de la organización.

Reglas y guías para estructurar y constituir equipos.



Elaboración OPF


Propuestas de mejora de procesos.

Planes de acciones de proceso aprobados de la organización.

Materiales de capacitación utilizados para desplegar activos de proceso organizativos.

Guías para desplegar el conjunto de procesos estándar de la organización en nuevos

trabajos o grupos de trabajo.

Planes para las evaluaciones de los procesos de la organización.

Elaboración OPM


Lecciones aprendidas documentadas sobre la validación de mejoras.

Planes de despliegue.

Medidas, objetivos, y prioridades de mejora actualizadas.

Documentación sobre procesos y materiales de capacitación actualizados.

Elaboración OPP


Objetivos de calidad y rendimiento de procesos de la organización.

Definiciones de medidas de rendimiento de procesos seleccionadas.

Datos de línea base sobre el rendimiento de procesos de la organización.

Modelos de rendimiento de procesos.

Elaboración OT


Plan táctico de capacitación organizativa.

Registros de capacitación.

Materiales de capacitación y artefactos de soporte.

Formularios de evaluación de instructores.

Elaboración PPQA


Informes de no conformidad.

Registros e informes de evaluación.



Elaboración QWM


Subprocesos a incluir en el proceso definido para el trabajo.

Definiciones operativas de las medidas, sus puntos de recogida dentro del subproceso,

y de cómo se determinará la integridad de las medidas.

Mediciones recogidas.

Elaboración REQM


Requisitos.

Matriz de trazabilidad de requisitos.

Elaboración RSKM


Estrategia de gestión de riesgos.

Elementos de riesgo identificados.

Planes de mitigación de riesgos.

Elaboración SAM


Declaraciones de trabajo.

Acuerdos de suministro.

Memorandos de acuerdo.

Subcontratos.

Lista de suministradores preferentes.

Elaboración SCON


Plan de continuidad del servicio.

Material utilizado para capacitar al personal sobre el plan de continuidad del servicio.

Registros de capacitación.

Procedimientos y criterios de verificación y validación.

Informes de verificación y validación.

Elaboración SD


Acuerdos de servicio.

Informes de prestación de servicios y gestión de peticiones.

Base de datos de gestión de peticiones.



Extensión SSD

Elaboración SSD


Requisitos de las partes interesadas.

Arquitectura del sistema de servicio.

Requisitos del servicio, el sistema de servicio, los componentes de sistema

de servicio, y los interfaces.

Diseños del sistema de servicio, los componentes de sistema de servicio, y

los interfaces.

Criterios para reutilizar diseños y componentes de sistema de servicio.

Especificación de habilidades y soluciones de asignación de personal.

Diseños implementados (p. ej. procedimientos operativos, componentes

consumibles fabricados).

Evaluaciones de componentes de sistema de servicio integrados.

Estrategia de integración de componentes de sistema de servicio.

Procedimientos y criterios de integración.



Material de capacitación sobre revisiones entre pares.

Datos sobre revisiones entre pares.

Documentación de usuario, instalación, entrega, gestión de incidencias, y

mantenimiento.

Elaboración SST


Plan de transición.

Informes de análisis del sistema de servicio.

Informes y registros de despliegue.

Evaluaciones de transiciones e informes de revisión post-despliegue.

Elaboración STSM


Conjunto de descripciones de servicio estándar de la organización.

Descripciones de niveles de servicio.

Guías de adaptación para el conjunto de servicios estándar de la organización.



Elaboración WMC


Cronogramas de trabajo con estados.

Datos de medición y análisis del trabajo.

Informes sobre el valor realizado.

Elaboración WP


Estructura de descomposición del trabajo.

Plan de trabajo.

Plan de gestión de datos.

Plan de involucración de las partes interesadas.

GP 2.7 Identificar e involucrar a las partes interesadas relevantes

Identificar e involucrar a las partes interesadas relevantes del

proceso según lo planificado.

El propósito de esta práctica genérica es establecer y mantener la

involucración que se espera de las partes interesadas relevantes durante la

ejecución del proceso.

Involucre a las partes interesadas relevantes tal y como se describe en un

plan apropiado de involucración de partes interesadas. Involucre

apropiadamente a las partes interesadas en actividades tales como:

Planificación.

Decisiones.

Compromisos.

Comunicaciones.

Coordinación.

Revisiones.

Evaluaciones.

Definición de requisitos.

Resolución de problemas y cuestiones.

Para más información sobre planificar la involucración de las partes

interesadas, consúltese el área de proceso Planificación de Trabajos.

El objetivo de planificar la involucración de las partes interesadas es

asegurar que se llevan a cabo las interacciones que el proceso necesita,

así como evitar que una cantidad excesiva de grupos e individuos

afectados dificulte la ejecución del proceso.



Algunos ejemplos de partes interesadas que podrían constituir partes interesadas

relevantes de tareas específicas, dependiendo del contexto, son: individuos, equipos,

gerentes, clientes, suministradores, usuarios finales, personal de operación y de soporte,

otros grupos de trabajo, y reguladores gubernamentales.

Subprácticas

1. Identificar a las partes interesadas relevantes para este proceso y su

apropiada involucración.

Las partes interesadas relevantes se identifican de entre los suministradores de

entradas al proceso, los usuarios de sus salidas, y los que realizan sus actividades.

Una vez que se ha identificado a las partes interesadas relevantes, se planifica el nivel

apropiado de su involucración en las actividades del proceso.

2. Compartir estas identificaciones con los planificadores del trabajo u

otros planificadores, según sea apropiado.

3. Involucrar a las partes interesadas relevantes según lo planificado.

Elaboración CAM

Algunos ejemplos de actividades para involucrar a las partes interesadas relevantes son:

Revisar informes y resolver problemas de gestión de capacidad y disponibilidad.

Trabajar estrechamente con las partes interesadas cuando no sea posible influir

directamente sobre la demanda del uso de recursos.

Elaboración CAR


Realizar análisis de causas.

Evaluar propuestas de acción.

Elaboración CM


Establecer líneas base.

Revisar informes del sistema de gestión de configuración y resolver los problemas.

Evaluar el impacto de los cambios en los elementos de configuración.

Realizar auditorías de configuración.

Revisar los resultados de las auditorías de gestión de configuración.



Elaboración DAR


Establecer guías sobre qué problemas están sujetos a procesos de evaluación formal.

Definir los problemas que se van a abordar.

Establecer criterios de evaluación.

Identificar y evaluar alternativas.

Seleccionar métodos de evaluación.

Seleccionar soluciones.

Elaboración IRP


Establecer el enfoque de resolución y prevención de incidencias.

Identificar incidencias en el servicio y registrar información sobre éstas.

Analizar incidencias en el servicio para determinar el mejor modo de proceder.

Revisar los resultados de las acciones para resolver las incidencias en el servicio.

Elaboración IWM


Resolver problemas sobre la adaptación de los activos de proceso organizativos.

Resolver problemas entre el plan de trabajo y otros planes que afecten al trabajo.

Revisar el progreso y rendimiento del trabajo para alinearlo con necesidades, objetivos,

y requisitos actuales y proyectados.

Crear la visión compartida del grupo de trabajo.

Definir la estructura de equipos para el grupo de trabajo.

Completar los equipos.

Elaboración MA


Establecer objetivos y procedimientos de medición.

Evaluar datos de medición.

Proporcionar realimentación significativa a quienes sean responsables de suministrar

los datos en bruto de los que dependan los análisis y resultados.



Elaboración OPD


Revisar el conjunto de procesos estándar de la organización.

Revisar los modelos de ciclo de vida de la organización.

Resolver problemas relacionados con las guías de adaptación.

Evaluar las definiciones del conjunto de medidas comunes de proceso y de producto.

Revisar los estándares de entorno de trabajo.

Establecer y mantener mecanismos de apoderamiento.

Establecer y mantener reglas y guías organizativas para estructurar y constituir

equipos.

Elaboración OPF


Coordinarse y colaborar en las actividades de mejora de procesos con los propietarios

de procesos, quienes realicen o realizarán el proceso, y las organizaciones de soporte

(p. ej. personal de capacitación, representantes de aseguramiento de calidad).

Establecer las necesidades y objetivos de procesos organizativos.

Evaluar los procesos de la organización.

Implementar planes de acciones de proceso.

Coordinarse y colaborar en la ejecución de pilotos para probar las mejoras

seleccionadas.

Desplegar activos de proceso organizativos y cambios a los activos de proceso

organizativos.

Comunicar los planes, el estado, las actividades, y los resultados relacionados con

planificar, implementar, y desplegar mejoras de proceso.

Elaboración OPM


Revisar propuestas de mejora que pudieran contribuir a cumplir los objetivos de

negocio.

Proporcionar realimentación a la organización sobre la preparación, el estado, y los

resultados de las actividades de despliegue de mejoras.

La realimentación habitualmente engloba lo siguiente:

Informar a quienes enviaron propuestas de mejora acerca de qué hay que hacer con

cada una de sus propuestas.

Comunicar regularmente los resultados de comparar el rendimiento frente a los


Informar regularmente a las partes interesadas relevantes acerca de los planes y el

estado de la selección y el despliegue de mejoras.

Preparar y distribuir resúmenes de las actividades de selección y despliegue de

mejoras.



Elaboración OPP


Establecer los objetivos de calidad y rendimiento de procesos de la organización y sus

prioridades.

Revisar y resolver problemas sobre las líneas base de rendimiento de procesos de la

organización.

Revisar y resolver problemas sobre los modelos de rendimiento de procesos de la

organización.

Elaboración OT


Establecer un entorno colaborativo para analizar las necesidades de capacitación y la

eficacia de la capacitación para asegurar que se cubran las necesidades de

capacitación de la organización.

Identificar necesidades de capacitación.

Revisar el plan táctico de capacitación organizativa.

Evaluar la eficacia de la capacitación.

Elaboración PPQA


Establecer criterios para evaluar objetivamente procesos y productos de trabajo.

Evaluar procesos y productos de trabajo.

Resolver problemas de no conformidad.

Seguir los problemas de no conformidad hasta su cierre.

Elaboración QWM


Establecer los objetivos del trabajo.

Resolver problemas entre los objetivos de calidad y rendimiento de procesos del

trabajo.

Seleccionar las técnicas analíticas que se van a utilizar.

Identificar y gestionar los riesgos sobre la consecución de los objetivos de calidad y

rendimiento de procesos del trabajo.

Identificar las acciones correctivas que deberían realizarse.



Elaboración REQM


Resolver problemas sobre la comprensión de los requisitos.

Evaluar el impacto de los cambios a los requisitos.

Comunicar la trazabilidad bidireccional.

Identificar inconsistencias entre requisitos, planes de trabajo, y productos de trabajo.

Elaboración RSKM


Establecer un entorno colaborativo para analizar libre y abiertamente los riesgos.

Revisar la estrategia de gestión de riesgos y los planes de mitigación de riesgos.

Participar en las actividades de identificación, análisis, y mitigación de riesgos.

Comunicar e informar sobre el estado de la gestión de riesgos.

Elaboración SAM


Establecer criterios para evaluar suministradores potenciales.

Revisar suministradores potenciales.

Establecer acuerdos de suministro.

Resolver problemas con suministradores.

Revisar el desempeño de los suministradores.

Elaboración SCON


Identificar funciones y recursos esenciales que den soporte a la prestación de

servicios.

Revisar el plan de continuidad del servicio.

Revisar materiales de capacitación.

Verificar y validar productos.

Elaboración SD


Establecer acuerdos de servicio.

Enviar peticiones de servicio.

Revisar informes de gestión de peticiones de servicio y resolver problemas.

Revisar el resultado de las acciones para resolver las peticiones de servicio.



Extensión SSD

Elaboración SSD

Algunos ejemplos de actividades para involucrar a las partes interesadas

relevantes son:

Revisar y evaluar si los requisitos son adecuados para cumplir las

necesidades, expectativas, restricciones, e interfaces.

Establecer modelos y escenarios operativos.

Establecer requisitos de servicio y de sistema de servicio.

Evaluar costes, plazos, necesidades de recursos previstos, y riesgos.

Desarrollar soluciones alternativas y criterios de selección.

Obtener aprobaciones para las especificaciones de interfaz y las

descripciones de diseño externas.

Desarrollar la arquitectura del sistema de servicio.

Evaluar las alternativas de desarrollo, compra, o reutilización para los

componentes de sistema de servicio.

Implementar el diseño.

Revisar que las descripciones de interfaz sean completas.

Establecer la estrategia, procedimientos, y criterios para integrar el sistema

de servicio.

Integrar y ensamblar componentes de sistema de servicio.

Seleccionar los componentes de sistema de servicio que se van a verificar y

validar.

Establecer los métodos, procedimientos, y criterios de verificación y

validación.

Revisar los resultados de verificar y validar los componentes de sistema de

servicio.

Resolver los problemas identificados durante la verificación y validación con

los clientes o usuarios finales.

Elaboración SST


Planificar y monitorizar las transiciones del sistema de servicio.

Notificar a las partes interesadas sobre el estado y los problemas de la transición.

Revisiones post-despliegue.



Elaboración STSM


Confirmar objetivos de negocio.

Revisar el conjunto de servicios estándar de la organización.

Revisar las descripciones de los servicios estándar.

Revisar los niveles de servicio de la organización.

Resolver problemas sobre las guías de adaptación.

Elaboración WMC


Evaluar el trabajo frente al plan.

Revisar compromisos y resolver problemas.

Revisar riesgos del trabajo.

Revisar actividades de gestión de datos.

Revisar el estado y el progreso del trabajo.

Gestionar acciones correctivas hasta su cierre.

Elaboración WP


Establecer estimaciones.

Revisar y resolver problemas sobre la completitud y corrección de los riesgos del

trabajo.

Revisar planes de gestión de datos.

Establecer planes de trabajo.

Revisar planes de trabajo y resolver los problemas sobre el trabajo y sobre los

recursos.

GP 2.8 Monitorizar y controlar el proceso

Monitorizar y controlar el proceso frente al plan de realización del

proceso, y realizar las acciones correctivas apropiadas.

El propósito de esta práctica genérica es realizar la monitorización y control

directo del proceso en el día a día. El proceso se mantiene apropiadamente

visible para que se puedan realizar las acciones correctivas apropiadas

cuando sea necesario. Monitorizar y controlar el proceso puede implicar

que se midan atributos apropiados del proceso o los productos de trabajo

producidos por el proceso.

X044 Para más información sobre desarrollar y mantener una competencia

de medición que se use para dar soporte a las necesidades de información

de la gerencia, consúltese el área de proceso Medición y Análisis.

Para más información sobre proporcionar información sobre el progreso y

rendimiento del trabajo de modo que se puedan realizar las acciones



correctivas apropiadas cuando el progreso y rendimiento del trabajo se

desvíen significativamente del plan, consúltese el área de proceso

Monitorización y Control de Trabajos.

Subprácticas

1. Evaluar el progreso y rendimiento reales frente al plan para realizar el

proceso.

Se evalúan el proceso, sus productos de trabajo, y sus servicios.

2. Revisar los logros y resultados del proceso frente al plan para realizar

el proceso.

3. Revisar las actividades, estado, y resultados del proceso con el nivel

de gestión que sea inmediatamente responsable del proceso, e

identificar problemas.

Estas revisiones están previstas para, en base a monitorizar y controlar el proceso en

el día a día, proporcionar visibilidad apropiada del proceso al nivel inmediato de

gestión, y se complementan con revisiones periódicas y desencadenadas por eventos

con niveles de gestión superiores, tal y como se describe en la GP 2.10.

4. Identificar y evaluar los efectos de las desviaciones significativas con

respecto al plan para realizar el proceso.

5. Identificar problemas en el plan para realizar el proceso y en la

ejecución del proceso.

6. Realizar acciones correctivas cuando los requisitos y objetivos no se

satisfagan, cuando se identifiquen problemas, o cuando el progreso se

desvíe significativamente del plan para realizar el proceso.

Se deberían considerar los riesgos inherentes antes de realizar cualquier acción

correctiva.

Algunas acciones correctivas pueden ser:

Realizar reparaciones para corregir productos de trabajo o servicios defectuosos.

Cambiar el plan para realizar el proceso.

Ajustar recursos, incluyendo personas, herramientas, y otros recursos.

Negociar cambios a los compromisos establecidos.

Asegurar los cambios a los requisitos y objetivos que deben ser satisfechos.

Poner fin a la labor.

7. Seguir las acciones correctivas hasta su cierre.



Elaboración CAM

Algunos ejemplos de medidas y productos de trabajo utilizados para monitorizar y controlar

son:

Cantidad total de horas de cliente perdidas al mes debido a interrupciones del servicio

normal por causas asociadas a la gestión de capacidad y disponibilidad.

Cantidad de horas perdidas por cliente y mes debido a interrupciones del servicio

normal por causas asociadas a la gestión de capacidad y disponibilidad.

Porcentaje de requisitos de tiempo de respuesta no cumplidos debidos a causas

asociadas a la gestión de capacidad y disponibilidad.

Precisión de las predicciones sobre tendencias en el uso de recursos.

Elaboración CAR


son:

Número de resultados analizados.

Cambios en la calidad o el rendimiento de procesos por cada instancia del proceso de

análisis causal y resolución.

Cronograma de actividades para implementar una propuesta de acción seleccionada.

Elaboración CM


son:

Número de cambios a los elementos de configuración.

Número de auditorías de configuración realizadas.

Cronograma de las actividades del CCB o de las auditorías.

Elaboración DAR


son:

Ratio de coste-beneficio de utilizar procesos de evaluación formales.

Cronograma para la ejecución de un estudio de contraprestaciones.



Elaboración IRP


son:

Datos sobre capacidad, rendimiento del sistema de servicio, y disponibilidad, que

señalen incidencias potenciales en el servicio.

Número de incidencias en el servicio recibidas.

Tiempo de resolución de incidencias en el servicio comparados con los tiempos de

resolución definidos en el acuerdo de nivel de servicio.

Número de transferencias entre grupos de soporte antes de que se resuelva una

incidencia en el servicio.

Cronograma para implementar una propuesta de acción que evite la recurrencia de una

clase de incidencias en el servicio.

Elaboración IWM


son:

Número de cambios al proceso definido para el trabajo.

Plazo y esfuerzo para adaptar el conjunto de procesos estándar de la organización.

Tendencias en problemas de coordinación entre interfaces (esto es, cuántos se

identifican y cuántos se cierran).

Cronograma para las actividades de adaptación del trabajo.

Utilización y eficacia de la visión compartida del grupo de trabajo.

Utilización y eficacia de la estructura de equipos.

Utilización y eficacia de los estatutos de los equipos.

Elaboración MA


son:

Porcentaje de grupos de trabajo que usan medias de progreso y rendimiento.

Porcentaje de objetivos de medición abordados.

Cronograma para la recogida y revisión de datos de medición.

Elaboración OPD


son:

Porcentaje de grupos de trabajo que utilizan arquitecturas de proceso y elementos de

proceso del conjunto de procesos estándar de la organización.

Densidad de defectos de cada elemento de proceso del conjunto de procesos estándar


Cronograma para el despliegue de un proceso o un cambio a un proceso.



Elaboración OPF


son:

Número de propuestas de mejora de procesos remitidas, aceptadas, o implementadas.

Nivel de madurez de CMMI o nivel de capacidad obtenido.

Cronograma para el despliegue de un activo de proceso organizativo.

Porcentaje de los grupos de trabajo que utilizan el conjunto actual de procesos

estándar de la organización (o una versión adaptada del conjunto actual).

Tendencias de problemas asociados a la implementación del conjunto de procesos

estándar de la organización (esto es, cuántos problemas se identifican, cuántos se

cierran).

Progreso hacia el logro de las necesidades y objetivos de procesos.

Elaboración OPM


son:

Cambios en la calidad y rendimiento de procesos relacionados con objetivos de

negocio.

Cronograma para implementar y validar una mejora.

Cronograma para las actividades de despliegue de una mejora seleccionada.

Elaboración OPP


son:

Tendencias en el rendimiento de procesos de la organización con respecto a cambios

en los atributos de productos de trabajo y tareas (p. ej. aumento de tamaño, esfuerzo,

plazos, calidad).

Cronograma para recoger y revisar las medidas que se van utilizar para establecer una

línea base de rendimiento de procesos.

Elaboración OT


son:

Número de cursos de capacitación impartidos (p. ej. planificados frente a reales).

Calificaciones de evaluaciones post-capacitación.

Calificaciones de encuestas de calidad sobre el programa de capacitación.

Cronograma para realizar capacitación.

Cronograma para desarrollar un curso.



Elaboración PPQA


son:

Diferencia entre las evaluaciones objetivas de proceso planificadas y las realizadas.

Diferencia entre las evaluaciones objetivas de productos de trabajo planificadas y las

realizadas.

Cronograma para las evaluaciones objetivas.

Elaboración QWM


son:

Perfil de los atributos de subproceso cuyo rendimiento de procesos proporcione

información sobre el riesgo de, o que contribuyan de forma clave a lograr los objetivos

del trabajo (p. ej. cuántos se han seleccionado para monitorizar con técnicas

estadísticas, cuántos se monitorizan actualmente, cuántos tienen un rendimiento de

procesos estable).

Número de causas especiales de variación identificadas.

Cronograma para las actividades de recogida de datos, análisis, y reporte dentro de un

ciclo de medición y análisis en lo que respecta a actividades de gestión cuantitativa.

Elaboración REQM


son:

Volatilidad de requisitos (porcentaje de requisitos modificados).

Cronograma para la coordinación de requisitos.

Cronograma para el análisis de un cambio propuesto a los requisitos.

Elaboración RSKM


son:

Cantidad de riesgos identificados, gestionados, seguidos, y controlados.

Exposición a riesgos y cambios a la exposición a riesgos de cada riesgo evaluado, y

como resumen, porcentaje de reserva de gestión.

Cantidad de cambios en los planes de mitigación de riesgos (p. ej. procesos, plazos,

financiación).

Ocurrencia de riesgos no previstos.

Volatilidad en la categorización de riesgos.

Comparación del esfuerzo e impacto de mitigación estimados frente a los reales.

Cronograma para las actividades de análisis de riesgos.

Cronograma para las acciones de una mitigación específica.



Elaboración SAM


son:

Número de cambios realizados a los requisitos para el suministrador.

Variación en costes y plazos con respecto al acuerdo de suministro.

Cronograma para seleccionar un suministrador y establecer un acuerdo.

Elaboración SCON


son:

Número de cambios realizados a la lista de funciones y recursos identificados como

esenciales para la prestación de servicios.

Costes, plazos, y esfuerzos empleados en asegurar la continuidad del servicio.

Porcentaje de personas capacitadas en el plan de continuidad del servicio que deban

volver a capacitarse.

Estado de los informes de problema de verificación y validación del plan de continuidad

del servicio (esto es, cuánto tiempo ha estado abierto cada informe de problema).

Elaboración SD


son:

Tiempo dedicado a preparar el acuerdo de servicio.

Cantidad de peticiones de servicio recibidas.

Tiempo dedicado a resolver peticiones de servicio comparado con el tiempo definido en

el acuerdo de nivel de servicio.

Cantidad de transferencias entre grupos de soporte antes de que una petición de

servicio se haya resuelto.



Extensión SSD

Elaboración SSD

Algunos ejemplos de medidas y productos de trabajo utilizados para monitorizar y

controlar son:

Coste, plazo, y esfuerzo empleado en rehacer el trabajo.

Densidad de defectos en las especificaciones de requisitos.

Cronograma de actividades para desarrollar un conjunto de requisitos.

Porcentaje de requisitos abordados en el diseño del sistema de servicio o el

diseño de un componente de sistema de servicio.

Tamaño y complejidad del sistema de servicio, los componentes de sistema

de servicio, las interfaces, y la documentación.

Densidad de defectos en los productos de trabajo de diseño e integración.

Tendencias en los informes de problema de evaluación de la integración (p.

ej. cuántos se escriben, cuántos se cierran).

Edad de los informes de problema de evaluación de la integración (esto es,

durante cuánto tiempo ha estado abierto cada informe de problema).

Perfiles de verificación y validación (p. ej. cantidad de verificaciones y

validaciones planificadas y realizadas, cantidad de defectos encontrados).

Cantidad de defectos detectados por categoría de defectos.

Tendencias en los informes de problema de verificación y validación (p. ej.

cuántos se escriben, cuántos se cierran).

Estado de los informes de problema de verificación y validación (esto es,

durante cuánto tiempo ha estado abierto cada informe de problema).

Cronograma para realizar actividades específicas de requisitos, diseño,

integración, verificación, y validación.

Elaboración SST


son:

Tiempo de transición planificado frente al real.

Cantidad de incidencias en el servicio recibidas relacionadas con transiciones.

Cantidad de instancias inesperadas de suspensión y reversión, incluyendo magnitud de

la alteración en la prestación del sistema de servicio.

Resultados de revisiones post-despliegue y encuestas a las partes interesadas.



Elaboración STSM


son:

Porcentaje de contratos que utilizan el conjunto de servicios estándar de la

organización.

Número de peticiones de cliente que incumplen los niveles de servicio definidos.

Frecuencia de uso de servicios concretos.

Cronograma para desarrollar un cambio a una descripción de servicio.

Elaboración WMC


son:

Número de acciones correctivas abiertas y cerradas.

Cronograma con estados para la recogida, análisis, y reporte mensual de datos

financieros.

Número y tipos de revisiones realizadas.

Cronograma de revisiones (planificadas frente a reales y fechas límite retrasadas).

Cronograma para recoger y analizar datos de monitorización.

Elaboración WP


son:

Número de revisiones al plan.

Variación de costes, plazos, y esfuerzos por cada revisión del plan.

Cronograma para desarrollar y mantener los planes del programa.

GP 2.9 Evaluar el cumplimiento objetivamente

Evaluar objetivamente si el proceso y los productos de trabajo

seleccionados cumplen la descripción, estándares, y

procedimientos del proceso, y abordar las no conformidades.

El propósito de esta práctica genérica es asegurar de forma creíble que el

proceso y los productos de trabajo seleccionados han sido implementados

según se planificó y cumplen la descripción del proceso, estándares, y

procedimientos (véase la definición de “evaluar objetivamente” en el

glosario).

Para más información sobre evaluar objetivamente procesos y productos

de trabajo, consúltese el área de proceso Aseguramiento de Calidad de

Procesos y Productos.

Habitualmente, el cumplimiento lo evalúan personas no directamente

responsables de gestionar o realizar las actividades del proceso. En

muchos casos, el cumplimiento lo evalúan personas de dentro de la

organización, pero externas al proceso o grupo de trabajo, o personas



externas a la organización. Como resultado, se puede proporcionar un

aseguramiento creíble del cumplimiento incuso durante periodos en los que

el proceso está bajo presión (p. ej. cuando la labor está retrasada, cuando

la labor supera el presupuesto).

Elaboración CAR

Algunos ejemplos de actividades revisadas son:

Determinar causas de los resultados.

Abordar causas de defectos.

Algunos ejemplos de productos de trabajo revisados son:

Propuestas de acción seleccionadas para su implementación.

Registros de análisis causal y resolución.

Elaboración CM


Establecer líneas base.

Seguir y controlar cambios.

Establecer y mantener la integridad de las líneas base.


Archivos de líneas base.

Base de datos de peticiones de cambio.

Elaboración DAR


Evaluar alternativas utilizando criterios y métodos establecidos.


Guías sobre cuándo aplicar procesos de evaluación formal.

Informes de evaluación que contengan soluciones recomendadas.

Elaboración IRP


Establecer el enfoque de resolución y prevención de incidencias.

Identificar incidencias en el servicio y registrar información sobre éstas.

Comunicar el estado de las incidencias en el servicio.




Base de datos de incidencias en el servicio.

Soluciones temporales.


Registros de incidencias en el servicio.

Elaboración IWM


Establecer, mantener, y utilizar el proceso definido para el trabajo.

Coordinarse y colaborar con partes interesadas relevantes.

Utilizar la visión compartida del grupo de trabajo.

Organizar equipos.


El proceso definido para el trabajo.

Planes de trabajo.

Otros planes que afecten al trabajo.

Estándares de entorno de trabajo.

Declaraciones de visión compartida.

Estructura de equipos.

Estatutos de los equipos.

Elaboración MA


Alinear actividades de medición y análisis.

Proporcionar resultados de medición.


Especificaciones de medidas base y derivadas.

Procedimientos de recogida y almacenamiento de datos.

Resultados de análisis e informes preliminares.

Elaboración OPD


Establecer activos de proceso organizativos.

Determinar reglas y guías para estructurar y constituir equipos.




Conjunto de procesos estándar de la organización.

Descripciones de modelos de ciclo de vida.

Guías de adaptación para el conjunto de procesos estándar de la organización.

Datos de medición de la organización.

Reglas y guías de apoderamiento para personas y equipos.

Elaboración OPF


Determinar oportunidades de mejora de procesos.

Planificar y coordinar actividades de mejora de procesos.

Desplegar el conjunto de procesos estándar de la organización al inicio de los grupos

de trabajo.


Planes de mejora de procesos.

Planes de acciones de proceso.

Planes de despliegue de procesos.

Planes de evaluación de los procesos de la organización.

Elaboración OPM


Analizar datos de rendimiento de procesos para determinar la capacidad de la

organización para cumplir los objetivos de negocio identificados.

Seleccionar mejoras utilizando análisis cuantitativo.

Desplegar mejoras.

Medir la eficacia de las mejoras desplegadas utilizando técnicas estadísticas y otras

técnicas cuantitativas.


Propuestas de mejora.

Planes de despliegue.

Medidas, objetivos, prioridades, y planes de despliegue de mejoras actualizados.

Documentación de procesos y material de capacitación actualizados.

Elaboración OPP


Establecer líneas base y modelos de rendimiento de procesos.




Líneas base de rendimiento de procesos.


Definición de las medidas de rendimiento de procesos seleccionadas.

Elaboración OT


Identificar necesidades de capacitación y hacer que la capacitación esté disponible.

Proporcionar la capacitación que se necesita.


Plan táctico de capacitación organizativa.

Materiales de capacitación y artefactos de soporte.

Formularios de evaluación de instructores.

Elaboración PPQA


Evaluar objetivamente procesos y productos de trabajo.

Seguir y comunicar problemas de no conformidad.



Registros e informes de evaluación.

Elaboración QWM


Gestionar el trabajo cuantitativamente utilizando objetivos de calidad y rendimiento de

procesos.

Gestionar subprocesos seleccionados del proceso definido para el trabajo.


Composiciones del proceso definido para el trabajo.

Definiciones operativas de las medidas.

Informes de análisis de rendimiento de procesos.

Mediciones recogidas.



Elaboración REQM


Gestionar requisitos.

Asegurar que los planes de trabajo, los productos de trabajo, y los requisitos estén

alineados.


Requisitos.


Elaboración RSKM


Establecer y mantener una estrategia de gestión de riesgos.

Identificar y analizar riesgos.

Mitigar riesgos.



Planes de mitigación de riesgos.

Elaboración SAM


Establecer y mantener acuerdos de suministro.

Satisfacer los acuerdos de suministro.


Plan de gestión de acuerdos de suministro.

Acuerdos de suministro.

Elaboración SCON


Establecer un plan de continuidad del servicio.

Realizar capacitación sobre el plan de continuidad del servicio.

Verificar y validar el plan de continuidad del servicio.



Materiales de capacitación.

Métodos, procedimientos, y criterios de verificación y validación.



Elaboración SD


Establecer acuerdos de servicio.

Procesar peticiones de servicio.

Mantener el sistema de servicio.



Enfoque de prestación de servicios.



Extensión SSD

Elaboración SSD


Recopilar necesidades de las partes interesadas.

Formular y analizar requisitos de servicio, de sistema de servicio, y de

componentes.

Seleccionar soluciones para el sistema de servicio.

Desarrollar los diseños del sistema de servicio y los componentes de

sistema de servicio.

Asegurar la compatibilidad de interfaces.

Implementar diseños del sistema de servicio.

Integrar y ensamblar componentes de sistema de servicio.

Verificar y validar el sistema de servicio.

Realizar revisiones entre pares.


Requisitos de servicios, de sistemas de servicio, y de componentes.

Requisitos de interfaz.

Arquitectura del sistema de servicio.

Diseños del sistema de servicio, componentes de sistema de servicio, e

interfaces.

Criterios para reutilización de diseños y componentes de sistema de servicio.

Especificación de habilidades y soluciones de asignación de personal.

Diseños implementados (p. ej. procedimientos operativos, componentes

consumibles fabricados).

Evaluaciones de componentes de sistema de servicio integrados.

Estrategia de integración de componentes de sistema de servicio.

Procedimientos y criterios de integración.



Material de capacitación sobre revisiones entre pares.

Datos sobre revisiones entre pares.

Documentación de usuario, instalación, entrega, gestión de incidencias, y

mantenimiento.

Elaboración SST


Planificar transiciones.

Capacitar sobre transiciones.

Actividades de despliegue, incluyendo validación y evaluación.




Plan de transición del sistema de servicio.

Registros de instalación.

Informe de revisión post-despliegue.

Elaboración STSM

Un ejemplo de actividad a revisar es el establecimiento de servicios estándar organizativos.


Conjunto de servicios estándar de la organización.

Descripciones de los servicios estándar.

Descripciones de los niveles de servicio.

Guías de adaptación para el conjunto de servicios estándar de la organización.

Elaboración WMC


Monitorizar el progreso y rendimiento del trabajo frente al plan de trabajo.

Gestionar acciones correctivas hasta su cierre.


Registros de progreso y rendimiento del trabajo.

Resultados de revisiones de proyecto.

Elaboración WP


Establecer estimaciones.

Desarrollar el plan de trabajo.

Obtener compromisos con el plan de trabajo.


Estructura de descomposición del trabajo.

Plan de trabajo.

Plan de gestión de datos.

Plan de involucración de partes interesadas.

GP 2.10 Revisar el estado con los niveles de gestión superiores

Revisar las actividades, estado, y resultados del proceso con los

niveles de gestión superiores, y resolver los problemas.

El propósito de esta práctica genérica es proporcionar visibilidad apropiada

sobre el proceso a los niveles de gestión superiores.



Los niveles de gestión superiores incluyen a aquellos niveles de gestión de

la organización por encima del nivel de gestión inmediatamente

responsable del proceso. En concreto, los directivos pueden estar incluidos

en los niveles de gestión superiores. Estas revisiones son para quienes

proporcionan las políticas y guías generales del proceso, y no para quienes

realizan la monitorización y control del proceso en el día a día.

Distintos gerentes tienen distintas necesidades de información acerca del

proceso. Estas revisiones ayudan a asegurar que se puedan realizar

decisiones informadas sobre la planificación y realización del proceso. Por

tanto, se espera que estas revisiones sean tanto periódicas como

desencadenadas por eventos.

Elaboración IRP

Los niveles de gestión superiores se mantienen informados acerca del

estado de las incidencias en el servicio significativas, incluyendo los

resultados de las soluciones temporales y las actividades de prevención.

Elaboración OPF

Habitualmente estas revisiones tienen la forma de sesiones informativas

que el grupo de procesos y los equipos de acciones de proceso presentan

al comité de dirección.

Algunos ejemplos de temas a presentar son:

Estado de las mejoras que los equipos de acciones de proceso están desarrollando.

Resultados de pilotos.

Resultados de despliegues.

Estado del cronograma sobre el logro de hitos significativos (p. ej. preparación para

una evaluación, progreso hacia el logro de un objetivo organizativo de nivel de

madurez o de perfil de niveles de capacidad).

Elaboración OPM


que los responsables de mejora del rendimiento presentan a los niveles de

gestión superiores.


Áreas de mejora identificadas a partir de analizar el rendimiento actual comparado con

los objetivos de negocio.

Resultados de las actividades de recabado y análisis de mejoras de procesos.

Resultados de actividades de validación (p. ej. pilotos) comparados con los beneficios

esperados.

Datos de rendimiento después del despliegue de mejoras.

Costes, plazos, y riesgos de los despliegues.

Riesgos de no lograr los objetivos de negocio.



Elaboración REQM

Los cambios propuestos a los compromisos externos a la organización se

revisan con los niveles de gestión superiores para asegurar que se pueden

cumplir todos los compromisos.

Elaboración RSKM

Para proporcionar visibilidad sobre la exposición a los riesgos potenciales

del trabajo y las acciones correctivas apropiadas, se realizan de forma

periódica y desencadenada por eventos revisiones del estado de los

riesgos del trabajo con los niveles de gestión apropiados.

Habitualmente, estas revisiones incluyen un resumen de los riesgos más

críticos, los parámetros de riesgo claves (tales como la probabilidad y

consecuencia de los riesgos), y el estado de las labores para mitigar los

riesgos.

Elaboración SCON


que se presentan a los niveles de gestión superiores.


Identificación de cambios significativos en las funciones de negocio y en los recursos

esenciales para la prestación de servicios.

Estado de los preparativos para la continuidad del servicio, incluyendo las actividades

de capacitación.

Problemas y resultados de verificación y validación.

Elaboración SST

Se mantienen informados a los niveles de gestión superiores acerca del

estado de las transiciones, incluyendo los intentos exitosos y fallidos de

transición, y los resultados de los despliegues.

GG 3 Institucionalizar un proceso definido

El proceso está institucionalizado como un proceso definido.

GP 3.1 Establecer un proceso definido

Establecer y mantener la descripción de un proceso definido.

El propósito de esta práctica genérica es establecer y mantener una

descripción del proceso adaptada a partir del conjunto de procesos

estándar de la organización que aborde las necesidades de una

instanciación específica. La organización debería disponer de procesos

estándar que cubran el área de proceso, así como de guías para adaptar

estos procesos estándar de forma que se pueda dar cabida a las

necesidades de los grupos de trabajo o funciones organizativas. Con un

proceso definido se reduce la variabilidad en la forma de realizar los

procesos en toda la organización, y se posibilita que los activos de

proceso, datos, y aprendizaje se compartan eficazmente.



Para más información sobre establecer el proceso definido para un trabajo,

consúltese el área de proceso Gestión Integrada de Trabajos.

Para más información sobre establecer procesos estándar y establecer

criterios y guías de adaptación, consúltese el área de proceso Definición

Organizativa de Procesos.

Las descripciones del proceso definido proporcionan la base para

planificar, realizar, y gestionar las actividades, productos de trabajo, y

servicios asociados al proceso.

Subprácticas

1. Seleccionar de entre el conjunto de procesos estándar de la

organización aquellos procesos que cubran el área de proceso y

cumplan mejor las necesidades del grupo de trabajo o función

organizativa.

2. Establecer el proceso definido adaptando los procesos seleccionados

conforme a las guías de adaptación de la organización.

3. Asegurar que el proceso definido aborda apropiadamente los objetivos

de proceso de la organización.

4. Documentar el proceso definido y los registros de adaptación.

5. Actualizar la descripción del proceso definido según se necesite.

GP 3.2 Recopilar experiencias relacionadas con procesos

Recopilar experiencias relacionadas con procesos derivadas de

planificar y realizar el proceso para dar soporte al uso y mejora

futuros de los procesos y activos de proceso de la organización.

El propósito de esta práctica genérica es recopilar experiencias

relacionadas con procesos, incluyendo información y artefactos derivados

de planificar y realizar el proceso. Algunos ejemplos de experiencias

relacionadas con procesos son los productos de trabajo, las medidas, los

resultados de medición, las lecciones aprendidas, y las mejoras de

procesos sugeridas. La información y artefactos se recopilan de forma que

puedan incorporarse a los activos de proceso organizativos y ponerse a

disposición de quienes estén planificando y realizando los mismos

procesos o procesos similares (o vayan a hacerlo). La información y

artefactos se almacenan en el repositorio de mediciones de la organización

y la biblioteca de activos de proceso de la organización.

Algunos ejemplos de información relevante son el esfuerzo dedicado a las distintas

actividades, los defectos inyectados o corregidos durante una actividad concreta, y las

lecciones aprendidas.

Para más información sobre contribuir a los activos de proceso

organizativos, consúltese el área de proceso Gestión Integrada de

Trabajos.

Para más información sobre establecer activos de proceso organizativos,

consúltese el área de proceso Definición Organizativa de Procesos.



Subprácticas

1. Almacenar medidas de procesos y productos en el repositorio de

mediciones de la organización.

Las medidas de procesos y productos son principalmente aquellas medidas que están

definidas en el conjunto de medidas comunes para el conjunto de procesos estándar


2. Remitir documentación para su inclusión en la biblioteca de activos de

proceso de la organización.

3. Documentar lecciones aprendidas sobre el proceso para su inclusión

en la biblioteca de activos de proceso de la organización.

4. Proponer mejoras a los activos de proceso organizativos.

Elaboración CAR

Algunos ejemplos de experiencias relacionadas con procesos son:


Cantidad de propuestas de acción que están abiertas y por cuánto tiempo.

Informes de situación de las propuestas de acción.

Elaboración CM


Tendencias en los estados de los elementos de configuración.

Resultados de auditorías de configuración.

Informes de antigüedad de peticiones de cambio.

Elaboración DAR


Número de alternativas consideradas.

Resultados de evaluaciones.

Soluciones recomendadas para abordar problemas significativos.

Elaboración IRP


Tendencias en la cantidad de tiempo que se requiere para resolver incidencias en el

servicio.

Cantidad de accesos al sistema de gestión de incidencias y para qué propósitos (p. ej.

identificar una solución temporal para una incidencia conocida).

Resultados de aplicar soluciones temporales e implementar propuestas de acción.



Elaboración IWM


Proceso definido para el trabajo.

Cantidad de opciones de adaptación ejercitadas por el grupo de trabajo al crear su

proceso definido.

Tendencias en los problemas de coordinación de interfaces (esto es, cuántos se

identifican, cuántos se cierran).

Cantidad de veces que los miembros del grupo de trabajo acceden a la biblioteca de

activos de proceso por activos relacionados con la planificación de trabajos.

Registros de gastos relacionados con mantener reuniones cara a cara frente a

mantener reuniones utilizando equipamientos para colaboración, tales como

teleconferencia y videoconferencia.

Visión compartida del grupo de trabajo.

Estatutos de equipos.

Elaboración OPD


Lecciones aprendidas remitidas a la biblioteca de activos de proceso de la

organización.

Datos de medición remitidos al repositorio de mediciones de la organización.

Estado de las peticiones de cambio remitidas para modificar el proceso estándar de la

organización.

Registro de peticiones de adaptación no estándar.

Elaboración OPF


Criterios utilizados para priorizar mejoras de procesos candidatas.

Hallazgos de evaluaciones que traten sobre fortalezas y debilidades de los procesos de

la organización.

Estado de las actividades de mejora con respecto al cronograma.

Registros de adaptar el conjunto de procesos estándar de la organización e

implementarlo en trabajos identificados.

Elaboración OPM


Lecciones aprendidas recogidas al analizar los datos de rendimiento de procesos

comparados con los objetivos de negocio.

Medidas documentadas de los costes y beneficios resultantes de implementar y

desplegar mejoras.

Informe que compare procesos de despliegue similares para identificar el potencial de

mejora de la eficiencia.



Elaboración OPP


Líneas base de rendimiento de procesos.

Porcentaje de datos de medición que se rechazan por inconsistencias con las

definiciones de las mediciones de rendimiento de procesos.

Elaboración OT


Resultados de encuestas sobre la eficacia de la capacitación.

Resultados de evaluar el rendimiento del programa de capacitación.

Evaluaciones de cursos.

Requisitos de capacitación proporcionados por un grupo de asesores.

Elaboración PPQA


Registros de evaluación.

Tendencias de calidad.


Informes de situación de acciones correctivas.

Informes de coste de la calidad para el trabajo.

Elaboración QWM


Registros de datos sobre gestión cuantitativa de trabajos, incluyendo resultados de las

revisiones periódicas del rendimiento real de los subprocesos seleccionados para su

gestión con respecto a los objetivos intermedios establecidos para el trabajo.

Mejoras sugeridas a los modelos de rendimiento de procesos.

Elaboración REQM



Cantidad de cambios a requisitos sin financiación después de marcar una línea base.

Lecciones aprendidas al resolver requisitos ambiguos.

Elaboración RSKM


Parámetros de riesgo.

Categorías de riesgo.

Informes de situación de riesgos.



Elaboración SAM


Resultados de revisiones de suministradores.

Estudios de contraprestaciones utilizados para seleccionar suministradores.

Historial de revisiones de acuerdos de suministro.

Informes de rendimiento de suministradores.

Elaboración SCON


Historial de revisiones de la lista de amenazas y vulnerabilidades que podrían alterar

significativamente la prestación de servicios.

Exposición al riesgo de alteraciones significativas en el servicio.

Cambios en la exposición al riesgo.

Costes asociados con las actividades de continuidad del servicio.

Informes de análisis de verificación y validación.

Elaboración SD


Cantidad de problemas que se han elevado relacionados con los términos del acuerdo

de servicio (siguiendo su implementación).

Medidas de utilización, disponibilidad, y rendimiento de los componentes de sistema de

servicio.

Tendencias en los plazos para responder a las peticiones de servicio.

Revisiones de los resultados de las respuestas a peticiones de servicio.



Extensión SSD

Elaboración SSD


Lista de requisitos de servicio o de sistema de servicio que son ambiguos.

Cantidad de requisitos introducidos en cada fase del ciclo de vida del

trabajo.

Lecciones aprendidas del proceso de asignación de requisitos.

Resultados de los análisis de desarrollo, compra, o reutilización.

Densidad de defectos de diseño.

Resultados de aplicar nuevos métodos y herramientas.

Registros de la recepción de componentes de sistema de servicio, informes

de excepción, confirmación del estado de la configuración, y resultados de

comprobar la preparación.

Porcentaje total del esfuerzo de desarrollo dedicado a la integración del

sistema de servicio (real hasta la fecha más estimado para completar).

Defectos encontrados en el sistema de servicio y el entorno de pruebas

durante la integración, verificación, y validación del sistema.

Registros de revisiones entre pares que incluyan el tiempo de realización y

el tiempo medio de preparación.

Elaboración SST


Artefactos de evaluación de despliegues.

Resultados de revisiones y lecciones aprendidas post despliegue.

Elaboración STSM


Peticiones de nuevos servicios por parte de los clientes.

Preguntas de los clientes para clarificar las descripciones de los servicios.

Estado de las peticiones de cambio remitidas para modificar los servicios estándar de

la organización.

Registro de peticiones de adaptación no estándar.

Elaboración WMC


Registros de desviaciones significativas.

Criterios para determinar qué constituye una desviación.

Resultados de acciones correctivas.



Elaboración WP


Estructura de la biblioteca de datos del trabajo.

Estimaciones de atributos del trabajo.

Impacto y probabilidad de ocurrencia de los riesgos.

Aplicación de las prácticas genéricas

Las prácticas genéricas son componentes que pueden aplicase a todas las

áreas de proceso. Piense en las prácticas genéricas como recordatorios.

Tienen el propósito de recordarle que haga las cosas bien, y son

componentes del modelo esperados.

Por ejemplo, considere la práctica genérica “Establecer y mantener el plan

para realizar el proceso” (GP 2.2). Cuando se aplica al área de proceso

Planificación de Trabajos, esta práctica genérica le recuerda que hay que

planificar las actividades implicadas en la creación del plan de trabajo.

Cuando se aplica al área de proceso Capacitación Organizativa, la misma

práctica genérica le recuerda que hay que planificar las actividades

implicadas en el desarrollo de habilidades y conocimientos de las personas


Áreas de proceso que dan soporte a las prácticas genéricas

Aunque las metas genéricas y prácticas genéricas son los componentes de

modelo que abordan directamente la institucionalización de un proceso en

toda la organización, muchas áreas de proceso abordan de forma similar la

institucionalización dando soporte a la implementación de las prácticas

genéricas. Conocer estas relaciones le ayudará a implementar las prácticas

genéricas eficazmente.

Tales áreas de proceso contienen una o más prácticas específicas que, al

implementarse, también pueden implementar completamente una práctica

genérica, o generar un producto de trabajo que se utiliza para implementar

una práctica genérica.

Un ejemplo es el área de proceso Gestión de Configuración y la GP 2.6

“Poner los productos de trabajo seleccionados bajo los niveles apropiados

de control”. Para implementar la práctica genérica en una o más áreas de

proceso, podría optar por implementar, total o parcialmente, el área de

proceso Gestión de Configuración.

Otro ejemplo es el área de proceso Definición Organizativa de Procesos y

la GP 3.1 “Establecer y mantener una descripción del proceso definido”.

Para implementar esta práctica genérica en una o más áreas de proceso,

antes debería implementar, total o parcialmente, el área de proceso

Definición Organizativa de Procesos, con objeto de establecer los activos



de proceso organizativos que se necesitan para implementar la práctica

genérica.

La tabla 6.2 describe (1) las áreas de proceso que dan soporte a la

implementación de prácticas genéricas, y (2) las relaciones recursivas

entre las prácticas genéricas y las áreas de proceso que están

estrechamente relacionadas. Es importante recordar ambos tipos de

relaciones durante la mejora de procesos para aprovecharse de las

sinergias naturales que existen entre las prácticas genéricas y sus áreas de

proceso relacionadas.



Tabla 6.2 Relaciones entre prácticas genéricas y áreas de proceso

Práctica genérica Papel del área de proceso en la implementación de la práctica genérica

Modo en que la práctica genérica se aplica recursivamente a su(s) área(s) de proceso relacionada(s)

21

GP 2.2

Planificar el

Proceso

Planificación de Trabajos: El proceso de planificación de trabajos puede implementar completamente la GP 2.2 de todas las áreas de proceso, salvo posiblemente la de las áreas de proceso organizativas y la de la propia área de Planificación de Trabajos.

La GP 2.2 aplicada al proceso de planificación de trabajos puede caracterizarse como “planificar la planificación” y cubre la planificación de las actividades de planificación de trabajos.

GP 2.3

Proporcionar

Recursos

GP 2.4

Asignar

Responsabilidades

Planificación de Trabajos: La parte del proceso de planificación de trabajos que implementa la SP 2.4 de Planificación de Trabajos“ da soporte a la implementación de las GP 2.3 y GP 2.4 de todas las áreas de proceso, salvo posiblemente las de las áreas de proceso organizativas, y quizás el inicio de la propia área de Planificación de Trabajos, por medio de identificar los procesos, roles, y responsabilidades necesarios para que se asegure la disponibilidad de personal, instalaciones, equipamientos, y otros activos apropiados.

GP 2.5

Capacitar a las

Personas

Capacitación Organizativa: El proceso de capacitación organizativa da soporte a la implementación de la GP 2.5 de todas las áreas de proceso por medio de poner a disposición de quienes van a realizar o dar soporte al proceso capacitación que aborde las necesidades de capacitación estratégicas o de toda la organización

Planificación de Trabajos: La parte del proceso de planificación de trabajos que implementa la SP 2.5 de Planificación de Trabajos “Planificar los conocimientos y habilidades que se necesitan”, y los procesos de capacitación organizativa, dan soporte a la implementación completa de la GP 2.5 de todas las áreas de proceso, salvo posiblemente para la de las áreas organizativas.

La GP 2.5 aplicada al proceso de capacitación organizativa cubre la capacitación para realizar las actividades de capacitación organizativa, la cual aborda las habilidades que se requieren para gestionar, crear, y llevar a cabo capacitación.

21

Cuando la relación entre una práctica genérica y un área de proceso es menos directa, el riesgo de confusión es menor; por

tanto, no describimos todas las relaciones recursivas en la tabla (p. ej. para las prácticas genéricas 2.3, 2.4 y 2.10).





21

GP 2.6

Controlar los

Productos de

Trabajo

Gestión de Configuración: El proceso de gestión de configuración puede implementar por completo la GP 2.6 de todas las áreas de proceso.

La GP 2.6 aplicada al proceso de gestión de configuración cubre los cambios y el control de versiones de los productos de trabajo producidos por las actividades de gestión de configuración.

GP 2.7

Identificar e

Involucrar a las

Partes Interesadas

Relevantes

Planificación de Trabajos: La parte del proceso de planificación de trabajos que implementa la SP 2.6 de Planificación de Trabajos “Planificar la involucración de las partes interesadas”, puede implementar por completo el tramo de identificación de partes interesadas (primeras dos subprácticas) de la GP 2.7 de todas las áreas de proceso, salvo posiblemente la de las áreas organizativas.

Monitorización y Control de Trabajos: La parte del proceso de monitorización y control que implementa la SP 1.5 de Monitorización y Control de Trabajos “Monitorizar la involucración de las partes interesadas”, puede ayudar a implementar la tercera subpráctica de la GP 2.7 de todas las áreas de proceso, salvo posiblemente la de las áreas organizativas.

Gestión Integrada de Trabajos: La parte del proceso de gestión integrada de trabajos que implementa la SP 2.1 de Gestión Integrada de Trabajos “Gestionar la involucración de las partes interesadas”, puede ayudar a implementar la tercera subpráctica de la GP 2.7 de todas las áreas de proceso, salvo posiblemente la de las áreas organizativas.

La GP 2.7 aplicada al proceso de planificación de trabajos cubre la involucración de las partes interesadas relevantes para las actividades de planificación de trabajos.

La GP 2.7 aplicada al proceso de monitorización y control de trabajos cubre la involucración de las partes interesadas relevantes para las actividades de monitorización y control de trabajos.

La GP 2.7 aplicada al proceso de gestión integrada de trabajos cubre la involucración de las partes interesadas relevantes para las actividades de gestión integrada de trabajos.





21

GP 2.8

Monitorizar y

Controlar el

Proceso

Monitorización y Control de Trabajos: El proceso de monitorización y control de trabajos puede implementar por completo la GP 2.8 de todas las áreas de proceso, salvo posiblemente la de las áreas organizativas.

Medición y Análisis: Para todos los procesos, el área de proceso Medición y Análisis proporciona una guía general sobre medir, analizar, y registrar información que puede utilizarse para establecer medidas para monitorizar el rendimiento de procesos.

La GP 2.8 aplicada al proceso de monitorización y control de trabajos cubre la monitorización y control de las actividades de monitorización y control de trabajos.

GP 2.9 Evaluar el

Cumplimiento

Objetivamente

Aseguramiento de Calidad de Procesos y Productos: El proceso de aseguramiento de calidad de procesos y productos puede implementar por completo la GP 2.9 de todas las áreas de proceso (excepto quizás la de la propia área de Aseguramiento de Calidad de Procesos y Productos).

La GP 2.9 aplicada al proceso de aseguramiento de calidad de procesos y productos cubre la evaluación objetiva de las actividades y productos de trabajo seleccionados de aseguramiento de calidad.

GP 2.10

Revisar el Estado

con los Niveles de

Gestión

Superiores

Monitorización y Control de Trabajos: La parte del proceso de monitorización y control de trabajos que implementa la SP 1.6 de Monitorización y Control de Trabajos “Realizar revisiones de progreso” y la SP 1.7 “Revisar revisiones de hitos” da soporte a la implementación de la GP 2.10 de todas las áreas de proceso, salvo posiblemente la de las áreas organizativas, quizás por completo, dependiendo de la involucración en estas revisiones de los niveles de gestión superiores.





21

GP 3.1

Establecer un

Proceso Definido

Gestión Integrada de Trabajos: La parte del proceso de gestión integrada de trabajos que implementa la SP 1.1 de Gestión Integrada de Trabajos “Establecer el proceso definido”, puede implementar por completo la GP 3.1 de todas las áreas de proceso, salvo posiblemente la de las áreas de proceso organizativas.

Definición Organizativa de Procesos: Para todos los procesos, el proceso de definición organizativa de procesos establece los activos de proceso organizativos que se necesitan para implementar la GP 3.1.

La GP 3.1 aplicada al proceso de gestión integrada de trabajos cubre el establecimiento de un proceso definido para las actividades de gestión integrada de trabajos.

GP 3.2

Recopilar

Experiencias

Relacionadas con

Procesos

Gestión Integrada de Trabajos: La parte del proceso de gestión integrada de trabajos que cubre la SP 1.7 de Gestión Integrada de Trabajos “Contribuir a los activos de proceso organizativos”, puede implementar parcial o totalmente la GP 3.2 de todas las áreas de proceso, salvo posiblemente la de las áreas organizativas.

Enfoque Organizativo en Procesos: La parte del proceso de enfoque organizativo en procesos que implementa la SP 3.4 de Enfoque Organizativo en Procesos “Incorporar experiencias a los activos de proceso organizativos” puede implementar parcial o completamente la GP 3.2 de todas las áreas de proceso.

Definición Organizativa de Procesos: Para todos los procesos, el proceso de definición organizativa de procesos establece los activos de proceso organizativos que se necesitan para implementar la GP 3.2.

La GP 3.2 aplicada al proceso de gestión integrada de trabajos cubre la recopilación de experiencias relacionadas con procesos derivadas de planificar y realizar las actividades de gestión integrada de trabajos.

Teniendo en cuenta las dependencias que las prácticas genéricas tienen

con estas áreas de proceso, y dado que la visión que proporcionan estas

áreas de proceso es más holística, estas áreas de proceso a menudo se

implementan de forma temprana, total o parcialmente, antes o

concurrentemente con la implementación de las prácticas genéricas

asociadas.



También hay unas pocas situaciones en las que el resultado de aplicar una

práctica genérica a un área de proceso concreta podría dar como resultado

que el área de proceso completa sea redundante, pero, de hecho, no es

así. Puede ser natural pensar que aplicar la GP 3.1 “Establecer un proceso

definido” a las áreas de proceso Planificación y Control de Trabajos y

Monitorización y Control de Trabajos tenga el mismo resultado que la

primera meta específica de Gestión Integrada de Trabajos “Utilizar el

proceso definido para el trabajo”.

Aunque es cierto que existe cierto solapamiento, la aplicación de la práctica

genérica a estas dos áreas de proceso proporciona el proceso definido que

cubre las actividades de planificación de trabajos y monitorización y control

de trabajos. Estos procesos definidos no tienen por qué cubrir las

actividades de soporte (p. ej. gestión de configuración), otros procesos de

gestión de trabajos (p. ej. gestión integrada de trabajos), u otros procesos.

Por el contrario, el proceso definido para el trabajo, proporcionado por el

área de proceso Gestión Integrada de Trabajos, cubre todos los procesos

apropiados.


Gestión de Capacidad y Disponibilidad (CAM) 132

GESTIÓN DE CAPACIDAD Y DISPONIBILIDAD

Un área de proceso de Gestión de Proyectos y Trabajos en el nivel de madurez 3

Propósito

El propósito de Gestión de Capacidad y Disponibilidad (CAM) es asegurar

que el rendimiento del sistema de servicio sea eficaz y que los recursos se

provean y utilicen eficazmente para dar soporte a los requisitos del servicio.


El área de proceso Gestión de Capacidad y Disponibilidad implica

establecer y mantener la capacidad y disponibilidad a un coste razonable y

utilizando los recursos eficientemente. Las actividades de gestión de

capacidad y disponibilidad se pueden realizar en distintos niveles de la

organización, incluso de forma transversal a varios servicios.

El área de proceso Gestión de Capacidad y Disponibilidad engloba las

siguientes actividades:

Establecer y mantener una estrategia de gestión de capacidad y

disponibilidad.

Proporcionar y asignar recursos de forma apropiada.

Monitorizar, analizar, comprender, e informar de la demanda de

servicios, el uso de recursos, la capacidad, el rendimiento del sistema

de servicio, y la disponibilidad del servicio actuales y futuros.

Determinar acciones correctivas para asegurar que la capacidad y

disponibilidad sean apropiadas, a la vez que se equilibran los costes

con los recursos necesarios y la oferta con la demanda.

“Capacidad” es el grado en que una cosa puede dar soporte, mantener,

procesar, o producir otra. En el contexto de servicios, la capacidad puede

referirse a la máxima cantidad de servicios prestados, o al máximo número

de peticiones de servicio que un sistema de servicio puede manejar con

éxito en un periodo de tiempo determinado. La capacidad es un atributo de

calidad. Las definiciones y mediciones de capacidad pueden variar para

distintos tipos de servicio y de sistemas de servicio, y pueden estar

establecidas en el acuerdo de servicio. Adicionalmente, las definiciones y

medidas de capacidad pueden derivarse de los acuerdos de servicio, en

lugar de estar reflejadas en ellos. Aunque el acuerdo de servicio no tenga

requisitos de capacidad explícitos, de él se pueden derivar implícitamente

requisitos de capacidad para el servicio o sistema de servicio. Para algunos

servicios, la capacidad puede consistir en el máximo tamaño, volumen, o

capacidad productiva de los componentes de sistema de servicio.



Algunos ejemplos de capacidad son:

Número de vehículos que requieren mantenimiento que pueden recibirse en unas

instalaciones de mantenimiento dentro de un periodo de 24 horas.

Número de formularios de solicitud de préstamo que pueden procesarse dentro de un

periodo de 8 horas.

Tamaño o volumen de un disco.

Metros cuadrados de suelo que pueden limpiarse por hora.

Cantidad de kilos que un camión puede acarrear de una vez.

Cantidad total de fluido que puede absorber un componente de sistema de servicio.

Número de llamadas por día que puede manejar un servicio de atención telefónica.

Número de evaluaciones que se pueden realizar en un año.

Como parte del establecimiento de la estrategia de gestión de capacidad y

disponibilidad se determina lo siguiente:

Recursos que son apropiados para su gestión.

Aspectos del sistema de servicio que afectan a la disponibilidad del

servicio y deberían ser medidos, monitorizados, analizados, y

gestionados.

Algunos ejemplos de recursos son el personal, el hardware, la potencia eléctrica, y el

espacio disponible.

“Disponibilidad” es el grado en el que se puede acceder y utilizar una cosa

cuando se necesita. En el contexto de servicios, la disponibilidad puede

referirse al conjunto de momentos, lugares, y otras circunstancias en los

que se van a prestar los servicios, se van a satisfacer las peticiones de

servicio, o tienen que ser válidos otros aspectos del acuerdo. La

disponibilidad es un atributo de calidad. Distintos grupos de trabajo pueden

tener definiciones y medidas diferentes para la disponibilidad de distintos

tipos de servicio y sistemas de servicio y para distintas perspectivas de la

disponibilidad (p. ej. perspectiva de negocio, perspectiva de usuarios

finales, perspectiva del cliente, perspectiva del proveedor de servicios).

Definir la disponibilidad requiere entender la forma en que los componentes

de sistema de servicio dan soporte a los requisitos de disponibilidad del

servicio, los cuales pueden haberse definido en el acuerdo de servicio.

Adicionalmente, tanto los requisitos de disponibilidad como sus medidas

pueden depender y afectar a otros requisitos de atributos de calidad

estrechamente relacionados, como la mantenibilidad, la fiabilidad, la

sostenibilidad, y la seguridad.



Algunos ejemplos de componentes de sistema de servicio para los que podría ser necesario

prestar atención a su disponibilidad son:

Equipamiento de anestesia.

Personal de cafetería.

Suministros de mantenimiento.

Componentes de transporte (p. ej. taxis, autobuses, camiones, conductores).

Personal de centro de atención telefónica.

Evaluadores líder.

La disponibilidad es uno de los indicadores más visibles de la calidad de un

servicio a los ojos de los usuarios finales y clientes. En algunos servicios,

para gestionar la disponibilidad es importante entender las relaciones que

existen entre ésta y atributos tales como la fiabilidad y mantenibilidad.

La disponibilidad de los servicios puede depender de:

La disponibilidad de los componentes de sistema de servicio.

La robustez frente a fallos del sistema de servicio.

La calidad del mantenimiento realizado al sistema de servicio.

La calidad del soporte proporcionado al sistema de servicio.

La eficacia de los procesos de servicio.

Las prácticas de seguridad.

La “gestión de capacidad” se centra en cuál es la mejor forma de

proporcionar recursos con objeto de cumplir los requisitos del servicio. La

“gestión de disponibilidad” se centra en proporcionar un nivel de

disponibilidad sostenido que permita cumplir los requisitos del servicio. Sin

embargo, a alto nivel, muchas de las buenas prácticas para gestionar la

capacidad y la disponibilidad son suficientemente parecidas como para

poder combinarlas, y llegan a estar estrechamente entrelazadas. La

gestión de capacidad proporciona los medios para conseguir una

disponibilidad sostenida que cumpla los requisitos del servicio. (Para

algunos servicios, también proporciona capacidad de reserva así como de

recuperación).

La producción del servicio y su consumo simultáneo es una de las

características únicas de los servicios. Esta característica de los servicios

supone algunos retos para la gestión de su capacidad y disponibilidad. Si

cuando se presenta la demanda no hay capacidad y disponibilidad para

proporcionar los servicios, el cliente tiene que esperar, lo que supone

costes de uno u otro tipo (p. ej. menor satisfacción de clientes, negocio

perdido por clientes se cansan de esperar, penalizaciones económicas). El

exceso de capacidad también puede suponer costes, en caso de que la

demanda estimada no se produzca (p. ej. coste del personal en nómina sin

carga de trabajo, costes de adquisición del excedente de capacidad).



Algunos ejemplos de retos en la gestión de capacidad son:

Proporcionar habitaciones de hotel suficientes y del tipo adecuado para satisfacer la

demanda, y no acabar con reservas duplicadas o con habitaciones vacías.

Proporcionar encargados de equipaje en un aeropuerto que sean suficientes para la

cantidad de viajeros, sin que haya demasiados ni que estén desocupados.

Algunos ejemplos de retos en la gestión de disponibilidad son:

Asegurar que se prestan servicios de jardinería, se mantiene el equipamiento de

jardinería, y que el personal de jardinería puede tomarse días libres (p. ej. vacaciones,

excedencias anuales) tal y como se haya definido en los acuerdos relevantes.

Monitorizar la fiabilidad del equipamiento de jardinería y del personal (p. ej. la ratio de

ausencias de los miembros del personal de jardinería).

Determinar acciones correctivas cuando la disponibilidad del servicio esté por debajo

de los niveles establecidos en el acuerdo de servicio.

La gestión de capacidad y disponibilidad incluye establecer

representaciones del sistema de servicio y utilizar dichas representaciones

para lo siguiente:

Dar soporte a la negociación de acuerdos de servicio apropiados.

Planificar.

Tomar decisiones.

Considerar acciones correctivas.

Proporcionar y asignar recursos para cumplir los requisitos del servicio

actuales y futuros.

Las “representaciones del sistema de servicio”, tales como modelos,

simulaciones, diagramas, mapas, y prototipos, pueden ayudar a entender

cómo se va a comportar el sistema de servicio en función de los volúmenes

y tipos de trabajo. Estas representaciones pueden construirse por medio de

hojas de cálculo, herramientas (p. ej. paquetes de simulación) comerciales

(COTS), o herramientas desarrolladas a medida. Para algunos servicios,

las representaciones pueden conocerse como líneas base históricas,

análisis de tendencias, modelos analíticos, análisis de tiempos de espera

en cola, modelos de simulación, modelos estadísticos (p. ej. modelos de

regresión, modelos de series temporales), modelos causales (p. ej. redes

probabilísticas), o dimensionamiento de aplicaciones.

El alcance de la gestión de capacidad y disponibilidad puede incluir a un

sistema de servicio o a varios sistemas de servicio. Si el proveedor de

servicios opera con varios sistemas de servicio, los procesos de gestión de

capacidad y disponibilidad pueden realizarse de forma independiente para

cada sistema de servicio individual, pero, en este caso, la organización

podría obtener un valor inferior.




Para más información sobre identificar, controlar, y tratar incidencias,

consúltese el área de proceso Resolución y Prevención de Incidencias.

Para más información sobre establecer y mantener planes para asegurar la

continuidad del servicio durante y después de una alteración significativa

en la operativa ordinaria, consúltese el área de proceso Continuidad del

Servicio.

Para más información sobre mantener el sistema de servicio, consúltese el

área de proceso Prestación de Servicios.

Extensión SSD

Para más información sobre desarrollar el sistema de servicio, consúltese

el área de proceso Desarrollo del Sistema de Servicio.

Para más información sobre establecer las necesidades y planes

estratégicos de los servicios estándar, consúltese el área de proceso

Gestión Estratégica de Servicios.

Para más información sobre especificar medidas, consúltese el área de

proceso Medición y Análisis.

Para más información sobre establecer la estrategia de servicio y

desarrollar un plan de trabajo, consúltese el área de proceso Planificación

de Trabajos.

Resumen de Metas y Prácticas Específicas

SG 1 Preparar la gestión de capacidad y disponibilidad

SP 1.1 Establecer una estrategia de gestión de capacidad y disponibilidad

SP 1.2 Seleccionar medidas y técnicas de análisis

SP 1.3 Establecer representaciones del sistema de servicio

SG 2 Monitorizar y analizar la capacidad y disponibilidad

SP 2.1 Monitorizar y analizar la capacidad

SP 2.2 Monitorizar y analizar la disponibilidad

SP 2.3 Informar acerca de la gestión de capacidad y disponibilidad

Prácticas específicas por meta

SG 1 Preparar la gestión de capacidad y disponibilidad

Se prepara la gestión de capacidad y disponibilidad.

Preparar la gestión de capacidad y disponibilidad incluye las siguientes

actividades:

Establecer y mantener una estrategia para gestionar la capacidad y

disponibilidad con objeto de cumplir los requisitos del servicio.

Seleccionar medidas y técnicas de análisis para dar soporte a los

objetivos de gestión de capacidad y disponibilidad.

Establecer y mantener representaciones del sistema de servicio para

conocer la capacidad, disponibilidad, y rendimiento del sistema de



servicio actuales (esto es, describir la capacidad, disponibilidad, y

niveles de servicio normales).

Se pueden establecer y mantener umbrales para definir qué condiciones

del sistema de servicio son excepcionales, percatarse de que se incumplen

o casi se incumplen los requisitos de sistema de servicio, e identificar

incidencias en el servicio. Además de conocer la capacidad y disponibilidad

del sistema de servicio actuales, la capacidad, disponibilidad, y los niveles

de servicio se estiman en base a las tendencias en el uso de recursos de

servicio, el rendimiento del sistema de servicio, y los requisitos esperados

del servicio.

SP 1.1 Establecer una estrategia de gestión de capacidad y disponibilidad

Establecer y mantener una estrategia de gestión de capacidad y

disponibilidad.

Los requisitos de servicio, los análisis de tendencias de fallos y de

peticiones de cambio, el uso actual de recursos, y el rendimiento del

sistema de servicio son la base de la estrategia de gestión de capacidad y

disponibilidad. Las representaciones del sistema de servicio pueden ayudar

a desarrollar la estrategia de gestión de capacidad y disponibilidad. La

estrategia puede abordar los usos mínimo, máximo, y medio del servicio

(esto es, de los recursos de servicio), en el corto, medio, y largo plazo,

según sea apropiado para la duración del servicio.

Para algunos servicios, puede que sea apropiado identificar, planificar, y

gestionar que haya capacidad adicional o recursos de reserva disponibles

para dar respuesta a aumentos de demanda repentinos e inesperados.

Para algunos tipos de servicio, la gestión de la obsolescencia de ciertos

recursos y servicios es un factor a considerar en la estrategia de gestión de

capacidad y disponibilidad.

La documentación de diseño del sistema de servicio puede ayudar a

determinar los recursos y aspectos del sistema de servicio a medir,

monitorizar, analizar, y controlar. Sin embargo, puede que la

documentación de diseño no esté disponible, o que no refleje con exactitud

y de forma global todos los aspectos del entorno de servicio en vivo que

afectan a la capacidad y disponibilidad. Por tanto, es importante monitorizar

y analizar los datos de capacidad y disponibilidad reales. Las estrategias

de servicio, la información sobre la prestación de servicios y su

monitorización en el día a día, y los requisitos del servicio en los acuerdos

de servicio actuales pueden ayudar a estas determinaciones.

Para más información sobre establecer acuerdos de servicio, consúltese el


Para más información sobre preparar la transición del sistema de servicio,

consúltese el área de proceso Transición del Sistema de Servicio.

Para más información sobre establecer servicios estándar, consúltese el

área de proceso Gestión Estratégica de Servicios.



La estrategia para la gestión de capacidad y disponibilidad puede reflejar

factores tales como las restricciones originadas por las limitaciones de

financiación del cliente, y la aceptación por parte del cliente de ciertos

riesgos relacionados con la capacidad y disponibilidad.

Puede que el proveedor de servicios no tenga influencia o control para

ajustar la demanda y los recursos, pero aun así debería formular la

estrategia que cumpla mejor los requisitos del servicio. Si el proveedor de

servicios puede influir en la demanda y los recursos o controlarlos para

ajustarlos, la estrategia puede ser más sofisticada que en las situaciones

en las que el proveedor de servicios no pueda ejercer tal influencia o

control.


1. Estrategia de gestión de capacidad y disponibilidad.

Subprácticas

1. Documentar el uso de recursos y servicios, el rendimiento, y la

disponibilidad.

2. Estimar los futuros requisitos de capacidad y disponibilidad de

recursos y servicios.

3. Desarrollar una estrategia de capacidad que cumpla los requisitos del

servicio, cubra la demanda de recursos y servicios, y aborde el modo

en que los recursos se proporcionan, utilizan, y asignan.

4. Desarrollar una estrategia de disponibilidad que cumpla los requisitos

del servicio y aborde que se provea un nivel de disponibilidad

sostenido.

Para algunos servicios puede que sea apropiado incluir en la estrategia un

cronograma de pruebas de disponibilidad, una estrategia de mantenimiento del

sistema de servicio, y paradas del servicio planificadas.

Para más información sobre preparar la continuidad del servicio,

consúltese el área de proceso Continuidad del Servicio.

Para más información sobre mantener el sistema de servicio,

consúltese el área de proceso Prestación de Servicios.

Para más información sobre preparar la transición del sistema de

servicio, consúltese el área de proceso Transición del Sistema de

Servicio.

5. Documentar los costes y beneficios económicos de la estrategia y los

supuestos que haya.

6. Actualizar periódicamente la estrategia.

También puede que sea necesario actualizar la estrategia en respuesta a eventos.




Seleccionar las medidas y técnicas de análisis a utilizar para

gestionar la capacidad y disponibilidad del sistema de servicio.

Las medidas especificadas para gestionar la capacidad y disponibilidad

pueden requerir que se recojan datos de negocio, datos financieros, datos

de servicio, datos técnicos, datos sobre el uso de recursos de servicio,

datos de rendimiento, y cualquier otro dato sobre la capacidad y

disponibilidad del sistema de servicio. Los objetivos de medición y la

selección de medidas y técnicas analíticas para gestionar la capacidad y

disponibilidad están fuertemente influenciados por el acuerdo de servicio y

por las propiedades específicas del sistema de servicio.

Al seleccionar las medidas también hay que considerar a qué actividades

se va dar soporte, los requisitos de información, y el modo en que se va a

utilizar la información. Los acuerdos de suministro deberían reflejar o dar

soporte a las medidas y técnicas analíticas seleccionadas, según sea

apropiado.



Para más información sobre alinear las actividades de medición y análisis,

consúltese el área de proceso Medición y Análisis.

Para más información sobre establecer acuerdos de suministro, consúltese

el área de proceso Gestión de Acuerdos de Suministro.

Algunos ejemplos de medidas de disponibilidad son:

Porcentaje de disponibilidad dentro de las horas acordadas (esta disponibilidad puede

ser del servicio en general o de un componente de servicio).

Porcentaje falta de disponibilidad dentro de las horas acordadas (esta falta de

disponibilidad puede ser del servicio en general o de un componente de servicio).

Duración de la parada debida a un fallo (habitualmente minutos, horas, u horas por

semana).

Frecuencia de fallos.

Alcance del impacto (p. ej. número de usuarios afectados, número de minutos en que

los usuarios perdieron productividad, número de transacciones o funciones de negocio

vitales que no se procesaron o llevaron a cabo, número de servicios de aplicación con

dificultades).

Tiempo de respuesta del sistema de servicio a las incidencias en el servicio, tiempos

de respuesta de las transacciones, y tiempos de respuesta de los servicios (estos

tiempos de respuesta pueden medir la capacidad o la disponibilidad).

Fiabilidad (p. ej. número de paradas en el servicio, tiempo medio entre fallos, tiempo

medio entre incidencias en el servicio).



Algunos ejemplos de medidas de capacidad son:

Uso de recursos de servicio que están limitados.

Uso de componentes de servicio.

Recursos de servicio que están limitados y sin usar.

Componentes de servicio sin usar.

Capacidad productiva (p. ej. número de usuarios concurrentes, número de

transacciones a procesar).

Tamaños de cola (máximo y medio).

Cantidad de recursos de un tipo concreto o de recursos específicos que estén en uso

en un momento determinado (este uso puede monitorizarse según el calendario)


1. Definiciones operativas de las medidas de capacidad y disponibilidad.

2. Trazabilidad de las medidas de capacidad y disponibilidad a los

requisitos del servicio.

3. Herramientas para dar soporte a la recogida y análisis de los datos de


4. Valores o rangos de valores a alcanzar por los atributos seleccionados

que se miden.

Subprácticas

1. Identificar medidas dentro de los activos de proceso organizativos que

den soporte a los objetivos de gestión de capacidad y disponibilidad.

2. Identificar y especificar medidas adicionales que puedan ser

necesarias para dar soporte a la consecución de los objetivos de

gestión de capacidad y disponibilidad para el servicio.

3. Analizar la relación entre las medidas identificadas y los requisitos del

servicio, y derivar objetivos que establezcan valores o rangos

específicos a alcanzar por las medidas para cada atributo que se

mide.

Este análisis puede servir de entrada a la descripción de los servicios y niveles de

servicio estándar.

Para más información sobre establecer servicios estándar, consúltese

el área de proceso Gestión Estratégica de Servicios.

SP 1.3 Establecer representaciones del sistema de servicio

Establecer y mantener representaciones del sistema de servicio

para dar soporte a la gestión de capacidad y disponibilidad.

Las representaciones del sistema de servicio permiten conocer cómo se

comportará el sistema de servicio con unos volúmenes y tipos de trabajo

determinados. Este conocimiento se utiliza para tomar decisiones acerca

de la asignación de recursos, los cambios en el sistema de servicio, los



acuerdos de servicio, y otros aspectos de la gestión y la prestación de

servicios.

Para muchos servicios, la demanda fluctúa ampliamente. La gestión de

servicios cuando existe una demanda que fluctúa ampliamente es uno de

los retos característicos que son únicos de los servicios. Dependiendo de

los patrones de fluctuación, las representaciones pueden centrarse en

intervalos pequeños o medianos de tiempo (p. ej. por hora del día para la

planificación de turnos de trabajo, día de la semana, mes del año) o para

intervalos mayores de tiempo (p. ej. estaciones del año, semestres, años).

El crecimiento esperado en el uso de recursos de servicio se formula

utilizando los datos recogidos de capacidad y disponibilidad, los requisitos

de servicio estimados, y las representaciones del sistema de servicio.

Los objetivos de medición y las propiedades específicas del sistema de

servicio determinan la naturaleza y el alcance de una representación del

sistema de servicio (los objetivos de medición están crucialmente

influenciados por el acuerdo de servicio). La naturaleza de una

representación del sistema de servicio también está influenciada por la

experiencia, los datos históricos, las habilidades para modelar, y el uso

actual de recursos.

Para más información sobre establecer objetivos de medición y especificar

procedimientos de análisis, consúltese el área de proceso Medición y

Análisis.

Las representaciones se pueden utilizar para analizar el impacto de las

peticiones de cambio que puedan afectar a la disponibilidad y capacidad.

Las representaciones también se pueden utilizar para caracterizar el rango

de demanda futura que puede satisfacerse, así como el impacto que los

niveles de servicio requeridos tienen sobre el sistema de servicio. Antes de

establecer representaciones del futuro comportamiento o rendimiento del

sistema de servicio, se deberían establecer descripciones del uso del

sistema de servicio y el rendimiento del sistema de servicio que son

normales.



Algunos ejemplos de representaciones de sistema de servicio que dan soporte a la gestión

de capacidad y disponibilidad son:

En un hospital proveedor de dos tipos de recursos de cuidado de la salud, las

representaciones gráficas que muestren la mezcla de los dos tipos con restricciones y

parámetros que indiquen cuál podría ser la mejor forma de asignar los dos recursos.

Análisis de tiempos de espera en cola para los cajeros de un banco.

Programas de planificación de vehículos.

Simulación modelando tasas de llegada de transacciones frente a configuraciones de

recursos específicas (p. ej. cajeros de banco, servidores de red).

Análisis de tendencias en la disponibilidad, fiabilidad, y mantenibilidad de los


Análisis de impacto de los fallos en los componentes de sistema de servicio.

Pruebas de carga que generen la demanda que se espera sobre los recursos de un

sistema de servicio, y aseguren que los componentes de sistema de servicio pueden

satisfacer el acuerdo de servicio.

Análisis en árbol de fallos y análisis de puntos únicos de fallo.

Las representaciones del sistema de servicio pueden establecerse para

ayudar a desarrollar el acuerdo de servicio y las descripciones de los

servicios y niveles de servicio estándar.





Las representaciones del sistema de servicio se pueden establecer

mientras se diseña el sistema de servicio. No obstante, incluso si se tiene

mucho cuidado al diseñar y desarrollar el sistema de servicio para asegurar

que puede cumplir los requisitos del servicio bajo un amplio rango de

condiciones operativas, la gestión y prestación de servicios deberían

admitir los niveles requeridos de rendimiento y calidad del sistema de

servicio durante la transición y la operación.

Extensión SSD

Para más información sobre desarrollar el sistema de servicio, consúltese


Las representaciones del sistema de servicio se mantienen durante todo el

ciclo de vida del servicio.

Las representaciones del sistema de servicio generalmente no son iguales

que las líneas base y los modelos de rendimiento de procesos establecidas

en Rendimiento Organizativo de Procesos (OPP) de los niveles 4 y 5.

Varias cosas distinguen las representaciones de las líneas base y los

modelos de rendimiento:

Los modelos y líneas base de rendimiento en OPP implican utilizar

técnicas estadísticas para ayudar a entender el rendimiento o el



rendimiento predicho de los procesos. Habitualmente no es necesario

desarrollar las representaciones del sistema de servicio de este modo.

No hace falta que las representaciones establecidas en CAM se basen

en datos recogidos a partir del uso de los procesos estándar de la

organización.

OPP se centra en las líneas base y modelos de rendimiento de

procesos. Además de los datos de proceso, las representaciones del

sistema de servicio de CAM se centran en datos, personas, y otras

partes del sistema de servicio, tales como la infraestructura y los

sistemas automatizados, que no son datos de proceso.

Las representaciones del sistema de servicio se establecen

específicamente para dar soporte al análisis de la capacidad y

disponibilidad. Este alcance está más restringido que el alcance de las

prácticas de OPP.

Para más información sobre establecer líneas base y modelos de

rendimiento, consúltese el área de proceso Rendimiento Organizativo de

Procesos.

Aunque no es requerido para la gestión de capacidad y disponibilidad, las

representaciones proporcionan oportunidades de utilizar técnicas

estadísticas tales como la gestión estadística de procesos. Estas técnicas

pueden utilizarse para gestionar cuantitativamente el rendimiento y la

calidad de un servicio, así como para mejorar la capacidad del sistema de

servicio.

Para más información sobre gestionar cuantitativamente los trabajos para

lograr los objetivos de calidad y rendimiento de procesos establecidos para

el trabajo, consúltese el área de proceso Gestión Cuantitativa de Trabajos.


1. Representaciones del uso de recursos y servicios.

2. Representaciones de los niveles de servicio.

3. Datos sobre el uso de recursos y servicios.

4. Datos sobre los niveles de servicio prestados actualmente.

5. Umbrales que definen las condiciones excepcionales e

incumplimientos.

Subprácticas

1. Recopilar mediciones sobre el uso de recursos y servicios y los niveles

de prestación de servicios actuales.

2. Establecer y mantener descripciones sobre el uso de recursos de

servicio y el rendimiento del sistema de servicio que son normales.

Para algunos servicios, puede que sea aconsejable establecer diagramas de flujo de

sistemas generales con objeto de identificar el sistema de servicio y sus procesos

antes de determinar la capacidad actual del sistema de servicio, para lo que puede

hacer falta determinar la capacidad de los componentes de sistema de servicio.



3. Establecer y mantener representaciones del sistema de servicio a

partir de las mediciones recopiladas y sus análisis.

Para algunos servicios, puede que sea aconsejable estimar la capacidad del sistema

de servicio cuando hay picos de carga de trabajo.

4. Revisar y acordar con las partes interesadas relevantes las

descripciones sobre el uso de recursos de servicio que es normal, el

rendimiento del sistema de servicio, y las representaciones del sistema

de servicio.

5. Hacer disponibles las descripciones del uso de recursos de servicio

que es normal, el rendimiento del sistema de servicio, y las

representaciones del sistema de servicio.

6. Establecer y mantener umbrales asociados con la demanda, carga de

trabajo, uso de recursos de servicio, y rendimiento del sistema de

servicio para definir qué condiciones son excepcionales en el sistema

de servicio y qué son incumplimientos o casi-incumplimientos de los

requisitos del servicio.

Habitualmente los umbrales se establecen por debajo del nivel en el que ocurren las

condiciones excepcionales o los incumplimientos de los requisitos del servicio, de

forma que se puedan realizar acciones correctivas que eviten el incumplimiento del

requisito del servicio, la sobreutilización de recursos, o el bajo rendimiento del sistema

de servicio.

SG 2 Monitorizar y analizar la capacidad y disponibilidad

La capacidad y disponibilidad se monitorizan y analizan con objeto de gestionar los recursos y la demanda.

La contribución de cada componente de sistema de servicio al

cumplimiento de los requisitos del servicio se analiza con objeto de

gestionar con éxito la capacidad y disponibilidad de los servicios. El uso

eficiente de recursos se gestiona de acuerdo a la estrategia de gestión de

capacidad y disponibilidad, que se desarrolla con el fin de cumplir los

requisitos del servicio. Para una organización de servicios podría no ser

posible influir en la demanda de servicios, y la frase “gestionar los recursos

y la demanda” no implica hacerlo. El uso eficiente de recursos puede incluir

tanto respuestas reactivas como proactivas. Las respuestas proactivas son

posibles en situaciones en las que el proveedor de servicios pueda influir

en la demanda.

Los datos reales de capacidad y disponibilidad se monitorizan

regularmente. Estos datos reales también se comparan regularmente con

umbrales, descripciones de uso normal y esperado, y objetivos de negocio.

Estas comparaciones identifican condiciones excepcionales en el sistema

de servicio, incumplimientos o casi-incumplimientos de los requisitos del

servicio, y cambios en los patrones de uso de los recursos del sistema de

servicio que puedan indicar tendencias. Por ejemplo, la monitorización

regular del uso real de recursos de servicio frente a su estimación de uso

podría revelar un próximo incumplimiento de los requisitos del servicio.



SP 2.1 Monitorizar y analizar la capacidad

Monitorizar y analizar la capacidad frente a los umbrales.

Se documenta el uso de cada recurso de servicio, así como el uso de cada

recurso por cada servicio (es decir, el grado o nivel en que cada servicio

utiliza un recurso de servicio determinado). Se analiza el impacto que los

fallos de los componentes de servicio tienen sobre los recursos.

Para algunos servicios, puede que sea apropiado monitorizar el uso de

capacidad adicional o recurso “de reserva”, y determinar si se necesitan

acciones correctivas tales como ajustes en la provisión de recursos, ajustes

en los umbrales, o ajustes a las descripciones del uso de recursos de

servicio y el rendimiento del sistema de servicio que son normales.

Se puede identificar una necesidad de realizar acciones correctivas como

resultado de monitorizar y analizar la capacidad y disponibilidad, o en

respuesta a incidencias en el servicio, peticiones de cambios, cambios a

los requisitos del servicio (actuales y futuros), o para mejorar el rendimiento

del sistema de servicio o evitar incumplimientos del acuerdo de servicio.

Para más información sobre especificar procedimientos de recogida y

almacenamiento de datos, consúltese el área de proceso Medición y

Análisis.


1. Datos sobre el uso de recursos de servicio.

2. Análisis del crecimiento en el uso de servicios.

3. Lista de recursos que no se están usando como se estimó.

Subprácticas

1. Monitorizar el uso de recursos de servicio frente a los umbrales, las

descripciones de qué uso es normal, y el rendimiento del sistema de

servicio.

Para más información sobre monitorizar los parámetros del plan de

trabajo, consúltese el área de proceso Monitorización y Control de

Trabajos.

2. Monitorizar los tiempos de respuesta del servicio.

3. Identificar incumplimientos de los umbrales y condiciones

excepcionales.

Los incumplimientos en los umbrales y las condiciones excepcionales pueden

constituir o ser indicadores de una incidencia.


consúltese el área de proceso Resolución y Prevención de

Incidencias.

Para más información sobre operar el sistema de servicio, consúltese

el área de proceso Prestación de Servicios.

4. Determinar las acciones correctivas a realizar.



Las acciones correctivas incluyen ajustar los recursos y servicios para evitar

problemas de rendimiento o para mejorar el rendimiento del servicio. Los ajustes

pueden automatizarse, realizarse manualmente, o ambas cosas.

Algunos ejemplos de acciones correctivas son:

Reequilibrar la carga de trabajo entre los distintos recursos.

Mejorar los procesos del sistema de servicio para permitir mayor productividad, eficiencia, y eficacia.

Mejorar el diseño del sistema de servicio, por ejemplo utilizando nuevas tecnologías que permitan mayor productividad, eficiencia o eficacia.

Añadir capacidad al sistema de servicio, por ejemplo añadir enfermeras, servidores, o líneas telefónicas.

Realizar ajustes para optimizar y mejorar la capacidad o el rendimiento del sistema de servicio.

Ajustar los requisitos del servicio.

Mejorar el uso de recursos de servicio por medio de técnicas de gestión de la demanda.

Extensión SSD

Para más información sobre desarrollar el sistema de servicio,

consúltese el área de proceso Desarrollo del Sistema de Servicio.

Para más información sobre gestionar acciones correctivas hasta su

cierre, consúltese el área de proceso Monitorización y Control de

Trabajos.

5. Estimar futuros cambios (tanto incrementos como reducciones) en el

uso de recursos y servicios.

Los análisis de tendencias, el modelado analítico, el modelado de simulaciones, los

modelos de línea base, y el dimensionamiento de aplicaciones son algunos métodos y

herramientas para estimar el comportamiento del sistema de servicio.

Las estimaciones de aumentos en el uso de recursos pueden basarse en datos

recogidos sobre capacidad y disponibilidad, estimaciones de requisitos del servicio, y

representaciones del sistema de servicio.

6. Almacenar datos, especificaciones, resultados de análisis, y datos de

monitorización sobre capacidad y disponibilidad.

SP 2.2 Monitorizar y analizar la disponibilidad

Monitorizar y analizar la disponibilidad frente a los objetivos.

El sistema de servicio debe monitorizarse para evitar fallos en el sistema

de servicio y dar soporte a la disponibilidad del sistema. Como mínimo, hay

que monitorizar la disponibilidad. Puede que sea apropiado monitorizar

otros atributos de calidad, dependiendo del tipo de servicio que se provea.

Para muchos de los tipos de sistema de servicio, otros atributos de calidad

para los que puede que sea apropiada su monitorización son la fiabilidad y

la mantenibilidad. También se puede monitorizar la robustez del sistema de



servicio a los fallos en los componentes de sistema de servicio e identificar

los impactos de fallos concretos en la disponibilidad del sistema de

servicio.


1. Datos sobre alarmas.

2. Datos sobre disponibilidad.

3. Datos sobre fiabilidad.

4. Datos sobre mantenibilidad.

Subprácticas

1. Monitorizar la disponibilidad, la fiabilidad, y la mantenibilidad frente a

sus requisitos.

2. Analizar las tendencias en la disponibilidad, la fiabilidad, y la

mantenibilidad.

Para algunos servicios, puede que también sea aconsejable realizar análisis sobre

tendencias de los fallos.

3. Identificar incumplimientos en los requisitos de disponibilidad,

fiabilidad, y mantenibilidad.



Incidencias.

4. Determinar las acciones correctivas a realizar.





Trabajos.

SP 2.3 Informar acerca de la gestión de capacidad y disponibilidad

Informar a las partes interesadas relevantes acerca de los datos de


Se proporcionan a las partes interesadas relevantes informes que resumen

la información sobre capacidad y disponibilidad. Estos informes dan

soporte a la monitorización frente al acuerdo de servicio y a las revisiones

del servicio. La forma en que se reportan los datos tiene una fuerte

influencia sobre cuánto beneficio se deriva de la gestión de capacidad y

disponibilidad.

Para más información sobre monitorizar el trabajo con respecto al plan,

consúltese el área de proceso Monitorización y Control de Trabajos.

Los acuerdos de servicio y los acuerdos de suministro pueden definir la

información a reportar, a quién debería entregarse, y cómo se proporciona

(p. ej. formato, nivel de detalle, distribución, medio). La información debería

ser apropiada para la audiencia, lo que significa que debería ser inteligible



(p. ej. no demasiado técnica), y podría requerir abordar varias perspectivas.

Estas perspectivas pueden incluir la del negocio, la del usuario final, la del

cliente, o la del proveedor de servicios.

Los informes de capacidad y disponibilidad pueden ser periódicos u

ocasionales, dependiendo de qué establece el acuerdo de servicio. Para

algunos servicios, reportar se puede simplificar mucho si se usan bases de

datos que ofrezcan funcionalidades de generación automática de informes.

Se deberían cumplir los estándares de la organización para los informes, y

se deberían utilizar herramientas y técnicas estándar, cuando existan, para

permitir integrar y consolidar el contenido de los informes.



Para más información sobre establecer procesos estándar, consúltese el

área de proceso Definición Organizativa de Procesos.



La disponibilidad habitualmente se reporta como un porcentaje. Además de

reportar la disponibilidad, algunos proveedores de servicios reportan

también la fiabilidad (p. ej. fiabilidad del servicio, fiabilidad de los

componentes de sistema de servicio) porque el acuerdo de servicios lo

requiere. El acuerdo de servicio también puede requerir que se reporte la

mantenibilidad y otros atributos de calidad.


1. Informes de rendimiento del sistema de servicio.

2. Informes de uso de recursos de servicio.

3. Previsiones de uso de recursos de servicio.

4. Informes de disponibilidad del servicio.

Subprácticas

1. Reportar sobre el rendimiento y el uso de recursos y servicios.

2. Reportar sobre las condiciones excepcionales en el sistema de

servicio y los incumplimientos en los requisitos del servicio.

3. Reportar sobre los datos de monitorizar el uso de recursos y servicios

frente a las estimaciones de crecimiento.

4. Reportar sobre la disponibilidad, fiabilidad, y mantenibilidad de los

recursos y servicios.


Análisis Causal y Resolución (CAR) 149

ANÁLISIS CAUSAL Y RESOLUCIÓN

Un área de proceso de Soporte en el nivel de madurez 5

Propósito

El propósito de Análisis Causal y Resolución (CAR) es identificar las

causas de los resultados seleccionados y actuar para mejorar el



El análisis causal y resolución mejora la calidad y la productividad al evitar

la introducción de defectos o problemas y al identificar e incorporar

apropiadamente las causas del mejor rendimiento de procesos.

El área de proceso Análisis Causal y Resolución engloba las siguientes

actividades:

Identificar y analizar las causas de los resultados seleccionados. Los resultados seleccionados pueden representar defectos y problemas cuya ocurrencia futura puede prevenirse o éxitos que pueden implementarse en los grupos de trabajo o en la organización.

Realizar acciones para llevar a cabo:

o La eliminación de las causas y la prevención de la futura recurrencia de esos tipos de defectos y problemas.

o El análisis proactivo de los datos para identificar problemas potenciales y prevenir su ocurrencia.

o La incorporación de las causas de los éxitos al proceso con objeto de mejorar en el futuro el rendimiento del proceso.

No es rentable confiar en la detección de los defectos y problemas después

de que se hayan introducido. Es más eficaz prevenir los defectos y

problemas integrando las actividades del Análisis Causal y Resolución

dentro de cada fase del ciclo de vida del trabajo.

Dado que pueden haberse encontrado previamente resultados similares en

otros trabajos o en fases o tareas anteriores del trabajo en curso, las

actividades de Análisis Causal y Resolución son mecanismos para

comunicar las lecciones aprendidas entre los grupos de trabajo.

Los tipos de resultados encontrados se analizan para identificar

tendencias. Basándose en el entendimiento del proceso definido y en cómo

está implementado, se determinan las causas raíces de estos resultados y

sus implicaciones futuras.

Dado que no es práctico realizar el análisis causal sobre todos los

resultados, se contraponen las inversiones estimadas frente a los retornos

estimados de calidad, productividad, y tiempo de ciclo para determinar qué

resultados se seleccionan.



Los procesos de medición y análisis ya deberían estar desplegados. Las

medidas definidas existentes pueden utilizarse, aunque en algunos casos,

para analizar los efectos de un cambio de proceso, pueden ser necesarias

nuevas definiciones de mediciones, redefiniciones, o definiciones

clarificadas.

Para más información sobre alinear las actividades de medición y análisis y

proporcionar resultados de medición, consúltese el área de proceso

Medición y Análisis.

Las actividades del Análisis Causal y Resolución proporcionan un

mecanismo para que los grupos de trabajo evalúen sus procesos a nivel

local y busquen mejoras que puedan implementarse.

Cuando se considera que las mejoras son eficaces, la información se

remite a nivel organizativo para su potencial despliegue en los procesos

organizativos.

Las prácticas específicas de esta área de proceso se aplican a un proceso

que se ha seleccionado para ser gestionado cuantitativamente. El uso de

las prácticas específicas de esta área de proceso puede añadir valor en

otras situaciones, pero puede que los resultados no proporcionen el mismo

grado de impacto sobre los objetivos de calidad y rendimiento de procesos






Para más información sobre seleccionar e implementar mejoras a

desplegar, consúltese el área de proceso Gestión del Rendimiento

Organizativo.





SG 1 Determinar las causas de los resultados seleccionados

SP 1.1 Seleccionar los resultados a analizar

SP 1.2 Analizar las causas

SG 2 Abordar las causas de los resultados seleccionados

SP 2.1 Implementar las propuestas de acción

SP 2.2 Evaluar los efectos de las acciones implementadas

SP 2.3 Registrar los datos del análisis causal




SG 1 Determinar las causas de los resultados seleccionados

Las causas raíces de los resultados seleccionados se determinan sistemáticamente.

Una causa raíz es un elemento inicial en una cadena causal que conduce a

un resultado de interés.

SP 1.1 Seleccionar los resultados a analizar

Seleccionar los resultados a analizar.

Esta actividad podría ser activada por un evento (reactiva), o podría

planificarse periódicamente, por ejemplo al inicio de una nueva fase o tarea

(proactiva).


1. Datos a utilizar en el análisis inicial.

2. Datos resultantes del análisis inicial.

3. Resultados seleccionados para análisis adicionales.

Subprácticas

1. Recoger datos relevantes.

Algunos ejemplos de datos relevantes son:

Defectos notificados por clientes o usuarios finales.

Defectos notificados por equipos de servicio.

Defectos encontrados en la verificación del servicio.

Medidas de productividad que son mayores de lo esperado.

Informes de problema que requieran acciones correctivas de la gestión del proyecto.

Problemas de capacidad del proceso.

Mediciones de capacidad productiva, uso, o tiempo de respuesta de recursos.

Llamadas a atención a usuarios, por tiempo y categoría de incidencia.

Disponibilidad del sistema de servicio inadecuada.

Problemas de cumplimiento del servicio o de satisfacción con el servicio.

2. Determinar qué resultados analizar más a fondo.

Cuando se determina qué resultados se analizarán más a fondo hay que considerar

su origen, impacto, frecuencia de ocurrencia, similitud, el coste analizarlos, el tiempo y

los recursos necesarios, las consideraciones de seguridad, etc.



Algunos ejemplos de métodos para seleccionar resultados son:

Análisis de Pareto

Histogramas

Diagramas de cajas y bigotes para atributos

Análisis de modos y efectos de fallos (FMEA)

Análisis de causa y efectos (p. ej. análisis de modos y efectos de fallos para el diseño del sistema de servicio que se está desarrollando, análisis de modos y efectos de fallos del proceso de desarrollo del sistema de servicio o el proceso de prestación de servicios)

3. Definir formalmente el alcance del análisis, incluyendo una definición

clara de la mejora necesaria o esperada, las partes interesadas

afectadas, el objetivo afectado, etc.

Para más información sobre analizar posibles decisiones utilizando un

proceso de evaluación formal que evalúe las alternativas identificadas

con respecto a criterios establecidos, consúltese el área de proceso

Análisis de Decisiones y Resolución.

SP 1.2 Analizar las causas

Realizar el análisis causal de los resultados seleccionados y

proponer acciones para abordarlos.

El propósito de este análisis es definir las acciones que abordarán los

resultados seleccionados por medio de analizar los resultados relevantes y

generar propuestas de acción a ser implementadas.


1. Resultados de los análisis de las causas raíces.

2. Propuesta de acción.

Subprácticas

1. Llevar a cabo el análisis causal con quienes son responsables de

realizar la tarea.

El análisis causal se realiza, habitualmente mediante reuniones, con quienes

entienden el resultado seleccionado bajo estudio. Habitualmente los que mejor

entienden el resultado seleccionado son los responsables de realizar la tarea. El

análisis es más eficaz cuando se realiza sobre datos en tiempo real, tan cerca como

sea posible del evento que desencadenó el resultado.



Algunos ejemplos de cuándo realizar el análisis causal son:

Cuando un subproceso estable no cumpla sus objetivos especificados de calidad y rendimiento de procesos, o cuando un subproceso necesite ser estabilizado.

Durante la tarea, siempre y cuando los problemas justifiquen una reunión de análisis causal.

Cuando un producto de trabajo muestre una desviación imprevista respecto a sus requisitos.

Cuando el rendimiento de procesos exceda las expectativas.

Al comienzo de una nueva fase o tarea.

Para más información sobre realizar análisis de causas raíces,

consúltese el área de proceso Gestión Cuantitativa de Trabajos.

2. Analizar los resultados seleccionados para determinar sus causas

raíces.

Analizar las líneas base y los modelos de rendimiento de procesos puede ayudar a

identificar causas raíces potenciales

Dependiendo del tipo y el número de resultados, puede que sea beneficioso

examinarlos de varias formas con objeto de asegurar que se investiguen todas las

causas raíces potenciales. Considere examinar tanto resultados individuales como

resultados agrupados.

Algunos ejemplos de métodos para determinar causas raíces son:

Diagramas de causa efecto (espina de pescado).

Hojas de comprobación.

3. Combinar los resultados seleccionados en grupos en base a sus

causas raíces.

En algunos casos, los resultados pueden estar influenciados por múltiples causas

raíces.

Algunos ejemplos de grupos o categorías de causas son:

Capacitación y habilidades inadecuadas.

Interrupción de las comunicaciones.

No tener en cuenta todos los detalles de una tarea.

Cometer errores en los procedimientos manuales (p. ej., al mecanografiar).

Proceso deficiente.

Cuando sea apropiado, buscar tendencias o síntomas dentro de o entre los grupos.

4. Crear una propuesta de acción que documente las acciones a realizar

para prevenir la ocurrencia futura de resultados similares, o para

incorporar a los procesos las buenas prácticas.

Los modelos de rendimiento de procesos pueden dar soporte al análisis de coste

beneficio de las propuestas de acción mediante la predicción de los impactos y el

retorno de la inversión.



Algunos ejemplos de acciones preventivas propuestas son cambiar:

El proceso en cuestión.

La capacitación.

Las herramientas.

Los métodos.

Los productos de trabajo.

Algunos ejemplos de incorporación de buenas prácticas son:

Crear listas de comprobación de la actividad, las cuales refuerzan la capacitación o la comunicación sobre problemas comunes y técnicas para prevenirlos.

Cambiar un proceso de tal forma que se eviten los pasos propensos a errores.

Automatizar todo o parte de un proceso.

Reordenar las actividades del proceso.

Añadir pasos al proceso, tales como reuniones de inicio de tarea con objeto de revisar los problemas comunes y las acciones para prevenirlos.

Una propuesta de acción usualmente documenta:

Autor de la propuesta de acción.

Descripción del resultado que se va a abordar.

Descripción de la causa.

Categoría de la causa.

Fase identificada.

Descripción de la acción.

Tiempo, coste, y otros recursos requeridos para implementar la propuesta de acción.

Beneficios esperados de implementar la propuesta de acción.

Coste estimado de no resolver el problema.

Categoría de la propuesta de acción.

SG 2 Abordar las causas de los resultados seleccionados

Las causas raíces de los resultados seleccionados se abordan sistemáticamente.

Los grupos de trabajo que operan de acuerdo a un proceso bien definido

analizan sistemáticamente dónde se necesitan mejoras, e implementan

cambios al proceso para abordar las causas raíces de los resultados

seleccionados.

SP 2.1 Implementar las propuestas de acción

Implementar las propuestas de acción seleccionadas que se

desarrollaron en el análisis causal.

Las propuestas de acción describen las tareas necesarias para abordar las

causas raíces de los resultados analizados con el fin de, o bien prevenir o



reducir la ocurrencia o recurrencia de resultados negativos, o bien

incorporar los éxitos obtenidos. Se desarrollan e implementan planes de

acción para las propuestas de acción seleccionadas. Sólo se deberían

considerar para su implementación general los cambios para los que se

demuestre su valor.


1. Propuestas de acción seleccionadas para su implementación.

2. Planes de acción.

Subprácticas

1. Analizar las propuestas de acción y determinar sus prioridades.

Algunos criterios para priorizar las propuestas de acción son:

Implicaciones de no abordar el resultado.

Coste de implementar mejoras de proceso para abordar el resultado.

Impacto esperado sobre la calidad.

Se pueden utilizar los modelos de rendimiento de procesos para ayudar a identificar

interacciones entre distintas propuestas de acción.

2. Seleccionar las propuestas de acción a implementar.





3. Crear planes de acción para implementar las propuestas de acción

seleccionadas.

Algunos ejemplos de información proporcionada en un plan de acción son:

Persona responsable de la implementación.

Descripción detallada de la mejora.

Descripción de las áreas afectadas.

Personas que tienen que mantenerse informadas del estado.

Cronograma.

Coste empleado.

Próxima fecha en la que se revisará el estado.

Justificación de las decisiones clave.

Descripción de las acciones de implementación.

4. Implementar los planes de acción.

Para implementar los planes de acción, se deberían realizar las siguientes tareas:

Hacer asignaciones.

Coordinar a las personas que hacen el trabajo.

Revisar los resultados.



Seguir las acciones hasta su cierre.

Para cambios particularmente complejos, se pueden llevar a cabo experimentos.

Algunos ejemplos de experimentos son:

Utilizar temporalmente un proceso modificado.

Utilizar una nueva herramienta.

Las acciones pueden asignarse a los miembros del equipo de análisis causal, a los

miembros del grupo de trabajo, o a otros miembros de la organización.

5. Buscar causas similares que puedan existir en otros procesos y

productos de trabajo, y actuar según sea apropiado.

SP 2.2 Evaluar los efectos de las acciones implementadas

Evaluar los efectos sobre el rendimiento de procesos de las

acciones implementadas.

Para más información sobre seleccionar medidas y técnicas de análisis,

consúltese el área de proceso Gestión Cuantitativa de Trabajos.

Una vez que el proceso modificado se despliega sobre todo un grupo de

trabajo, se evalúa el efecto de los cambios para verificar que el cambio al

proceso ha mejorado el rendimiento de procesos.


1. Análisis del rendimiento de procesos y de cambios de rendimiento de

procesos.

Subprácticas

1. Medir y analizar el cambio de rendimiento de procesos para los

procesos o subprocesos del trabajo afectados.

Esta subpráctica determina si el cambio seleccionado ha influido positivamente en el

rendimiento de procesos y en qué medida.

Un ejemplo de un cambio de rendimiento de procesos para un servicio sería un cambio en la capacidad prevista que tiene el diseño para cumplir los objetivos de calidad y rendimiento de procesos.

Otro ejemplo podría ser un cambio en el coste de prestar los servicios después de cambiar un subproceso con objeto de integrar componentes de sistema de servicio que se han actualizado. Este cambio de rendimiento debería determinarse monitorizando el servicio prestado antes y después de hacer la mejora, y comparando estadísticamente estas diferencias (p. ej. mediante el contraste de hipótesis). En un gráfico de control estadístico de procesos, este cambio de rendimiento se representaría por una mejora en la media, una reducción de la dispersión, o ambas cosas.

Las técnicas estadísticas y otras técnicas cuantitativas (p. ej., contraste de hipótesis)

pueden utilizarse para comparar las líneas base antes y después, y así evaluar la

significatividad estadística del cambio.



2. Determinar el impacto del cambio en el logro de los objetivos de

calidad y rendimiento de procesos del trabajo.

Esta subpráctica determina si el cambio seleccionado ha influido positivamente en la

capacidad que tiene el grupo de trabajo para cumplir sus objetivos de calidad y

rendimiento de procesos, por medio de entender el modo en que los cambios en los

datos de rendimiento de procesos han afectado a los objetivos. Los modelos de

rendimiento de procesos pueden ayudar en la evaluación prediciendo los impactos y

el retorno de la inversión.

3. Determinar y documentar acciones apropiadas si las mejoras de

proceso o de subproceso no han dado como resultado los beneficios

esperados.

SP 2.3 Registrar los datos del análisis causal

Registrar los datos de análisis causal y resolución para utilizarlos

entre los grupos de trabajo y la organización.


1. Registros del análisis causal y resolución.

2. Propuestas de mejora organizativas.

Subprácticas

1. Registrar los datos del análisis causal y hacerlos accesibles para que

otros grupos de trabajo puedan hacer cambios de proceso apropiados

y lograr resultados similares.

Registrar lo siguiente:

Datos sobre los resultados que se analizaron.

Justificación de las decisiones.

Propuestas de acción de las reuniones de análisis causal.

Planes de acción resultantes de las propuestas de acción.

Coste de las actividades de análisis y resolución.

Medidas de los cambios de rendimiento de procesos del proceso definido

resultante de las resoluciones.

2. Remitir las propuestas de mejora de procesos a la organización

cuando las acciones implementadas sean eficaces para el grupo de

trabajo, según sea apropiado.

Cuando las mejoras se consideren eficaces, la información se puede remitir a nivel

organizativo para su posible inclusión en los procesos organizativos.

Para más información sobre seleccionar mejoras, consúltese el área

de proceso Gestión del Rendimiento Organizativo.


Gestión de Configuración (CM) 158

GESTIÓN DE CONFIGURACIÓN


Propósito

El propósito de Gestión de Configuración (CM) es establecer y mantener la

integridad de los productos de trabajo mediante la identificación de

configuración, el control de configuración, el registro del estado de la

configuración, y las auditorías de configuración.


El área de proceso Gestión de Configuración engloba las siguientes

actividades:

Identificar la configuración de los productos de trabajo seleccionados

que componen líneas base en puntos de tiempo determinados.

Controlar los cambios a los elementos de configuración.

Construir, o proporcionar especificaciones para construir, productos de

trabajo a partir del sistema de gestión de configuración.

Mantener la integridad de las líneas base.

Proporcionar datos precisos sobre el estado y la configuración actual a

los desarrolladores, usuarios finales, y clientes.

Los productos de trabajo que se ponen bajo gestión de configuración

incluyen los productos que se entregan al cliente, los productos de trabajo

internos designados, los productos adquiridos, las herramientas, y los otros

elementos que se utilizan para crear y describir dichos productos de trabajo

(véase la definición de “gestión de configuración” en el glosario).



Algunos ejemplos de productos de trabajo que se pueden poner bajo gestión de

configuración son:

Documentación de arquitectura y datos de diseño del sistema de servicio.

Diagramas.

Especificaciones de productos.

Software.

Herramientas y guiones de prueba.

Compiladores.

Ficheros de datos de producto.

Publicaciones técnicas de producto.


Versiones autorizadas de software controlado e información y documentación asociada

sobre licencias.

Repositorios de información sobre activos.

Planes.

Descripciones de proceso.

Requisitos.

Puede que sea necesario que los productos adquiridos sean puestos bajo

gestión de configuración tanto por el suministrador como por el adquiriente.

En los acuerdos de suministro se deberían establecer estipulaciones sobre

la realización de la gestión de configuración. Se deberían establecer y

mantener métodos para asegurar que los datos estén completos y sean

consistentes.



La gestión de configuración de los productos de trabajo se puede realizar a

distintos niveles de detalle. Los elementos de configuración se pueden

descomponer en componentes de configuración y unidades de

configuración. En esta área de proceso se utiliza únicamente el término

“elemento de configuración”. Por tanto, en estas prácticas “elemento de

configuración” puede interpretarse como “componente de configuración” o

como “unidad de configuración” según sea apropiado (véase la definición

de “elemento de configuración” en el glosario).

Las líneas base proporcionan una base estable para la evolución continua

de los elementos de configuración.

Las líneas base se añaden al sistema de gestión de configuración a

medida que se desarrollan. Por medio del control de configuración, la

gestión de cambios, y las funciones de auditoría de configuración de

gestión de configuración se controlan y monitorizan sistemáticamente los

cambios a las líneas base y la entrega de productos de trabajo construidos

a partir del sistema de gestión de configuración.



Esta área de proceso no solo se aplica para gestionar la configuración de

los productos del grupo de trabajo, sino que también se aplica para

gestionar la configuración de productos de trabajo organizativos, tales

como los estándares, los procedimientos, las bibliotecas de reutilización, y

los otros activos de soporte compartidos.

La gestión de configuración se centra en el control riguroso de aspectos de

gestión y aspectos técnicos de los productos de trabajo, incluyendo los

productos y servicios entregados.

Esta área de proceso cubre las prácticas para realizar la función de gestión

de configuración, y es aplicable a todos los productos de trabajo que se

ponen bajo gestión de configuración.

Para las líneas de producto y los servicios estándar, la gestión de

configuración puede implicar consideraciones adicionales, ya que se

comparten transversalmente activos esenciales entre los servicios y los

sistemas de servicio y entre las distintas versiones de los activos

esenciales y los componentes de sistema de servicio (véase la definición

de “línea de producto” en el glosario).


Para más información sobre monitorizar el trabajo con respecto al plan y

gestionar las acciones correctivas hasta su cierre, consúltese el área de

proceso Monitorización y Control de Trabajos.

Para más información sobre desarrollar planes de trabajo, consúltese el

área de proceso Planificación de Trabajos.


SG 1 Establecer líneas base

SP 1.1 Identificar elementos de configuración

SP 1.2 Establecer un sistema de gestión de configuración

SP 1.3 Crear o liberar líneas base

SG 2 Seguir y controlar los cambios

SP 2.1 Seguir las peticiones de cambio

SP 2.2 Controlar los elementos de configuración

SG 3 Establecer la integridad

SP 3.1 Establecer registros de gestión de configuración

SP 3.2 Realizar auditorías de configuración


SG 1 Establecer líneas base

Se establecen líneas base de productos de trabajo identificados.

En esta meta específica se cubren las prácticas específicas para

establecer líneas base. Las prácticas específicas bajo la meta específica

Seguir y controlar los cambios sirven para mantener las líneas base. Las

prácticas específicas bajo la meta específica Establecer la integridad

documentan y auditan la integridad de las líneas base.



SP 1.1 Identificar los elementos de configuración

Identificar los elementos de configuración, componentes, y

productos de trabajo relacionados que se van a poner bajo gestión

de configuración.

La identificación de configuración consiste seleccionar y especificar lo

siguiente:

Productos entregados al cliente.

Productos de trabajo internos designados.

Productos adquiridos.

Herramientas y otros activos primordiales del entorno de trabajo.

Otros elementos utilizados para crear y describir estos productos de

trabajo.

Los elementos de configuración pueden incluir el hardware, los equipos, y

los activos tangibles, así como el software y la documentación. La

documentación puede incluir especificaciones de requisitos y

documentación de interfaces. También se pueden incluir otros documentos

que sirvan para identificar la configuración del producto o servicio, tales

como los resultados de pruebas.

Un “elemento de configuración” es una entidad designada para su gestión

de configuración, la cual puede constar de varios productos de trabajo

relacionados que forman una línea base. Esta agrupación lógica facilita su

identificación y control de acceso. La selección de productos de trabajo

para su gestión de configuración debería estar basada en criterios

establecidos durante la planificación.


1. Elementos de configuración identificados.

Subprácticas

1. Seleccionar los elementos de configuración y los productos de trabajo

de los que se componen en base a criterios documentados.

Algunos ejemplos de criterios para seleccionar elementos de configuración a un nivel apropiado de producto de trabajo son:

Productos de trabajo que dos o más grupos pueden utilizar.

Productos de trabajo que se espera que cambien con el tiempo, ya sea por errores o por cambios en los requisitos.

Productos de trabajo que dependan entre sí (es decir, que un cambio en uno de ellos obligue a cambiar los otros).

Productos de trabajo críticos para el éxito del trabajo.



Algunos ejemplos de productos de trabajo que pueden formar parte de un elemento de configuración son:

Diseño.

Planes y procedimientos de prueba.

Resultados de pruebas.

Descripciones de interfaz.

Diagramas.

Código fuente.

Herramientas (p. ej. compiladores).


Requisitos.

La declaración del caso de negocio, la lógica de negocio, o el valor de negocio.

2. Asignar identificadores únicos a los elementos de configuración.

3. Especificar características importantes de cada elemento de

configuración.

Algunos ejemplos de características de los elementos de configuración son el autor, el tipo de documento o fichero, el lenguaje de programación para ficheros de código fuente, y el propósito que cumple el elemento de configuración.

4. Especificar cuándo se pone bajo gestión de configuración cada

elemento de configuración.

Algunos ejemplos de criterios para determinar cuándo poner los productos de trabajo bajo gestión de configuración son:

Momento en que el producto de trabajo esté listo para probar.

Etapa del ciclo de vida del proyecto o servicio.

Grado de control que se desea sobre el producto de trabajo.

Limitaciones de coste y plazos.


5. Identificar el propietario responsable de cada elemento de

configuración.

6. Especificar las relaciones entre los elementos de configuración.

Incorporar los tipos de relaciones que existen entre los elementos de configuración (p.

ej. padre-hijo, dependencia) a la estructura de gestión de configuración (p. ej. base de

datos de gestión de configuración) ayuda a gestionar los efectos y los impactos de los

cambios.

SP 1.2 Establecer un sistema de gestión de configuración

Establecer y mantener un sistema de gestión de configuración y

gestión de cambios para controlar los productos de trabajo.

Un sistema de control de configuración incluye medios de almacenamiento,

procedimientos, y herramientas para acceder al sistema. Un sistema de



gestión de configuración puede constar de varios subsistemas con distintas

implementaciones que sean apropiadas para cada entorno de gestión de

configuración.

En algunos dominios de servicio, CM se centra en la documentación de

versiones y el control de cambios.

Un sistema de gestión de cambios incluye medios de almacenamiento,

procedimientos, y herramientas para registrar y acceder a las peticiones de

cambio.


1. Sistema de gestión de configuración con productos de trabajo

controlados.

2. Procedimientos de control de acceso al sistema de gestión de

configuración.

3. Base de datos de peticiones de cambio.

Subprácticas

1. Establecer un mecanismo para gestionar varios niveles de control.

La selección del nivel de control habitualmente se basa en los objetivos del trabajo, el

riesgo, y los recursos. Los niveles de control pueden variar en función del ciclo de vida

del proyecto o servicio, el tipo de sistema que se esté desarrollando, y los requisitos

específicos del trabajo.

Algunos ejemplos de niveles de control son:

No controlado: cualquier persona puede hacer cambios.

Trabajo en curso: los autores controlan los cambios.

Liberado: una autoridad designada autoriza y controla los cambios, y cuando se realizan cambios se notifica a las partes interesadas relevantes.

Los niveles de control pueden ir desde un control informal que simplemente registre

los cambios realizados durante el desarrollo de los elementos de configuración, hasta

un control de configuración formal que utilice líneas base que sólo se pueden cambiar

mediante un proceso formal de gestión de configuración.

2. Proporcionar control de acceso para asegurar que los accesos al

sistema de gestión de configuración estén autorizados.

3. Almacenar y recuperar elementos de configuración del sistema de

gestión de configuración.

4. Compartir y transferir elementos de configuración entre los niveles de

control del sistema de gestión de configuración.

5. Almacenar y recuperar versiones archivadas de los elementos de

configuración.

6. Almacenar, actualizar, y recuperar registros de gestión de

configuración.



7. Crear informes de gestión de configuración a partir del sistema de


8. Preservar los contenidos del sistema de gestión de configuración.

Algunos ejemplos de funciones para preservar el sistema de gestión de configuración son:

Copia de seguridad y restauración de ficheros de gestión de configuración.

Archivo de ficheros de gestión de configuración.

Recuperarse de los errores de gestión de configuración.

9. Actualizar la estructura de gestión de configuración según se necesite.

SP 1.3 Crear o liberar líneas base

Crear o liberar líneas base para uso interno y para la entrega al

cliente.

Una línea base se representa mediante la asignación de un identificador a

un elemento o colección de elementos de configuración y entidades

asociadas en un momento concreto. A medida que el producto o servicio

evoluciona, se pueden utilizar varias líneas base para controlar el

desarrollo y las pruebas (véase la definición de “línea base” en el glosario).

Algunos ejemplos de tipos de líneas base son:


Riesgos identificados.

Niveles de servicio y uso de recursos actuales.

Plan operativo.

Cronogramas.


1. Líneas base.

2. Descripciones de líneas base.

Subprácticas

1. Antes de crear o liberar líneas base de elementos de configuración,

obtener la autorización del CCB22

.

2. Crear o liberar líneas base sólo a partir de elementos de configuración

en el sistema de gestión de configuración.

3. Documentar el conjunto de elementos de configuración que están

contenidos en una línea base.

4. Hacer que el conjunto de líneas base esté disponible fácilmente.

22

Comité de Control de Configuración por sus siglas en inglés (N. del T)



SG 2 Seguir y controlar los cambios

Los cambios a los productos de trabajo bajo gestión de configuración se siguen y se controlan.

Las prácticas específicas bajo esta meta específica sirven para mantener

las líneas base después de haberlas establecido en las prácticas

específicas bajo la meta específica Establecer líneas base.

SP 2.1 Seguir las peticiones de cambio

Seguir las peticiones de cambio a los elementos de configuración.

Las peticiones de cambio no sólo abordan requisitos nuevos o modificados

sino también fallos y defectos en los productos de trabajo.

Las peticiones de cambio se analizan para determinar el impacto que el

cambio tendrá sobre el producto de trabajo, los productos de trabajo

relacionados, el presupuesto, y los plazos.


1. Peticiones de cambio.

Subprácticas

1. Iniciar peticiones de cambio y registrarlas en la base de datos de

peticiones de cambio.

2. Analizar el impacto de los cambios y correcciones propuestas en las

peticiones de cambio.

Los cambios se evalúan mediante actividades que aseguren que éstos son

consistentes con todos los requisitos técnicos y del trabajo.

El impacto de los cambios se evalúa más allá de los requisitos del trabajo o el

contrato. Cambiar un elemento utilizado en varios productos puede resolver un

problema inmediato a la vez que causa un nuevo problema en otras aplicaciones.

Se evalúa el impacto de los cambios sobre los planes de entrega.

3. Categorizar y priorizar las peticiones de cambio.

Las peticiones urgentes se identifican y remiten a la autoridad competente para ese

tipo de peticiones si fuese apropiado.

Los cambios se asignan a futuras líneas base.

4. Revisar con las partes interesadas relevantes y obtener su acuerdo

sobre las peticiones de cambio que se abordarán en la siguiente línea

base.

Realizar la revisión de peticiones de cambio con participantes apropiados. Registrar

qué hay que hacer con cada petición de cambio y la justificación de la decisión,

incluyendo los criterios de éxito, un breve plan de acción si es apropiado, y las

necesidades que el cambio cubre o deja de cubrir. Realizar las acciones que se

decidió hacer e informar a las partes interesadas relevantes de los resultados.

5. Seguir el estado de las peticiones de cambio hasta su cierre.



Las peticiones de cambio introducidas en el sistema deberían manejarse de forma

eficiente y oportuna. Una vez procesada la petición de cambio, es crítico cerrarla con

las acciones apropiadas aprobadas tan pronto como sea factible. Dejar las acciones

abiertas da como resultado listas de estados más largas de lo necesario, lo que a su

vez resulta en mayores costes y más confusión.

SP 2.2 Controlar los elementos de configuración

Controlar los cambios a los elementos de configuración.

Se mantiene el control sobre la configuración de la línea base de productos

de trabajo. Este control incluye seguir la configuración de cada elemento de

configuración, aprobar una nueva configuración en caso necesario, y

actualizar la línea base.


1. Historial de revisiones de los elementos de configuración.

2. Archivos de líneas base.

Subprácticas

1. Controlar los cambios a los elementos de configuración a lo largo de la

vida del producto o servicio.

2. Obtener la autorización apropiada antes de introducir en el sistema de

gestión de configuración los elementos de configuración cambiados.

Por ejemplo, la autorización puede venir del CCB, del gerente del proyecto o servicio, o del cliente.

3. Registrar en el sistema de gestión de configuración la entrada y salida

de elementos de configuración con objeto de incorporar los cambios

de forma que se mantenga la corrección e integridad de los elementos

de configuración.

Algunos ejemplos pasos para registrar entradas y salidas son:

Confirmar que las actualizaciones estén autorizadas.

Actualizar los elementos de configuración.

Archivar la línea base reemplazada y recuperar la nueva línea base.

Comentar los cambios realizados al elemento.

Enlazar los cambios con los productos de trabajo relacionados, tales como requisitos, acuerdos de servicio, planes operativos, y cronogramas.

4. Realizar revisiones para asegurar que los cambios no hayan causado

efectos no deseados en las líneas base (p. ej. asegurar que los

cambios no hayan comprometido la seguridad o la protección del

sistema).

5. Registrar los cambios a los elementos de configuración y su

justificación según sea apropiado.

Si se acepta un cambio propuesto en un producto de trabajo, se establece un plazo

para incorporarlo en el producto de trabajo y en las otras áreas afectadas.



Los mecanismos de control de configuración se pueden adaptar a las categorías de

cambios. Por ejemplo, las consideraciones de aprobación podrían ser menos

exigentes si se tratase de cambios a componentes que no afectan a otros

componentes.

Los elementos de configuración modificados se liberan después de revisar y aprobar

los cambios de configuración. Los cambios no son oficiales hasta que no se liberan.

SG 3 Establecer la integridad

Se establece y se mantiene la integridad de las líneas base.

La integridad de las líneas base, establecidas por los procesos asociados

con la meta específica Establecer líneas base, y mantenidas por los

procesos asociados con la meta específica Seguir y controlar los cambios,

se aborda con las prácticas específicas bajo esta meta específica.

SP 3.1 Establecer registros de gestión de configuración

Establecer y mantener registros que describan los elementos de

configuración.


1. Historial de revisiones de elementos de configuración.

2. Registro de cambios.

3. Registros de peticiones de cambio.

4. Estado de los elementos de configuración.

5. Diferencias entre líneas base.

Subprácticas

1. Registrar acciones de gestión de configuración con suficiente detalle

como para que se conozca el contenido y estado de cada elemento de

configuración y se puedan recuperar versiones anteriores.

2. Asegurar que las partes interesadas relevantes tengan acceso y

conozcan el estado de configuración de los elementos de

configuración.

Algunos ejemplos de actividades para comunicar el estado de configuración son:

Proporcionar permisos de acceso a usuarios finales autorizados.

Hacer que las copias de líneas base estén disponibles de inmediato para los usuarios finales autorizados.

Avisar automáticamente a las partes interesadas relevantes cuando se registre la entrada o salida de cambios, o cuando se tomen decisiones sobre peticiones de cambio.

3. Especificar la última versión de las líneas base.

4. Identificar las versiones de los elementos de configuración que

constituyen una línea base concreta.

5. Describir las diferencias entre líneas base consecutivas.



6. Actualizar el estado y la historia (esto es, cambios, otras acciones) de

cada elemento de configuración según se necesite.

SP 3.2 Realizar auditorías de configuración

Realizar auditorías de configuración para mantener la integridad de

las líneas base de configuración.

Las auditorías de configuración confirman que las líneas base y

documentación resultantes se ajustan a un estándar o requisito

especificado. Pueden existir registros relacionados con elementos de

configuración en varias bases de datos o sistemas de gestión de

configuración. En tales casos, para asegurar que la información sobre los

elementos de configuración sea precisa, consistente, y completa, las

auditorías de configuración deberían cubrir las otras bases de datos según

sea apropiado (véase la definición de “auditoría de configuración” en el

glosario).

Algunos ejemplos de tipos de auditoría son:

Auditorías de configuración funcionales (FCA): Auditorías realizadas para verificar que

el desarrollo de un elemento de configuración se ha completado satisfactoriamente,

que el elemento ha cumplido las características funcionales y los atributos de calidad

especificados en la línea base funcional o asignada, y que sus documentos operativos

y de soporte están completos y son satisfactorios.

Auditorías de configuración físicas (PCA): Auditorías realizadas para verificar que un

elemento de configuración, tal como está construido, cumple con la documentación

técnica que lo define y lo describe.

Auditorías de gestión de configuración: Auditorías realizadas para confirmar que los

registros de gestión de configuración y los elementos de configuración están

completos, son consistentes, y son precisos.


1. Resultados de auditorías de configuración.

2. Acciones.

Subprácticas

1. Evaluar la integridad de las líneas base.

2. Confirmar que los registros de gestión de configuración identifican

correctamente a los elementos de configuración.

3. Revisar la estructura y la integridad de los elementos en el sistema de


4. Confirmar que los elementos en el sistema de gestión de configuración

están completos, son correctos, y son consistentes.

El contenido del sistema de gestión de configuración estará completo y será correcto y

consistente dependiendo de los requisitos establecidos en el plan y las decisiones

sobre qué hacer con cada petición de cambio aprobada.



5. Confirmar que se cumplen los estándares y procedimientos aplicables

de gestión de configuración.

6. Seguir las acciones de las auditorías hasta su cierre.


Análisis de Decisiones y Resolución (DAR) 170

ANÁLISIS DE DECISIONES Y RESOLUCIÓN


Propósito

El propósito de Análisis de Decisiones y Resolución (DAR) es analizar las

posibles decisiones utilizando un proceso de evaluación formal que evalúe

alternativas identificadas frente a criterios establecidos.


El área de proceso Análisis de Decisiones y Resolución implica establecer

guías para determinar qué problemas deberían estar sujetos a un proceso

de evaluación formal y aplicar los procesos de evaluación formal a dichos

problemas.

Un proceso de evaluación formal es un enfoque estructurado para evaluar

soluciones alternativas frente a criterios establecidos con el fin de

determinar una solución recomendada.

Un proceso de evaluación formal engloba las siguientes acciones:

Establecer los criterios para evaluar alternativas.

Identificar soluciones alternativas.

Seleccionar métodos para evaluar alternativas.

Evaluar soluciones alternativas utilizando los criterios y métodos

establecidos.

Seleccionar soluciones recomendadas a partir de las alternativas

identificadas basándose en los criterios de evaluación.

En lugar de utilizar la frase “soluciones alternativas para abordar

problemas” en esta área de proceso se utilizan uno o dos términos más

cortos: “soluciones alternativas” o “alternativas”.

Un proceso de evaluación formal reduce la naturaleza subjetiva de la toma

de decisiones y aumenta la probabilidad de seleccionar una solución que

cumpla las múltiples demandas de las partes interesadas relevantes.

Aunque la aplicación principal de esta área de proceso es a temas

técnicos, los procesos de evaluación formal pueden aplicarse a muchos

problemas no técnicos, particularmente cuando se planifica el trabajo. Los

problemas que tienen múltiples soluciones alternativas y múltiples criterios

de evaluación se prestan a un proceso de evaluación formal.

Son ejemplos habituales de procesos de evaluación formal:

Estudios de contraprestaciones de equipamiento o de software

Comparaciones de capacidades potenciales de servicios que se van a desarrollar



Durante la planificación, se identifican los problemas específicos que

requieren un proceso de evaluación formal. Algunos problemas habituales

son la selección entre distintas alternativas de diseño o de arquitectura, la

utilización de componentes reutilizables o de componentes comerciales

(COTS), la selección de suministradores, los entornos de soporte de

ingeniería o las herramientas asociadas, los entornos de prueba, las

alternativas de entrega, y la logística y producción. También puede

utilizarse un proceso de evaluación formal para decidir si desarrollar o

comprar, para el desarrollo de los procesos de fabricación, y para la

selección de los lugares de distribución, entre otras decisiones.

Se crean guías para decidir cuándo utilizar procesos de evaluación formal

para abordar problemas no planificados. Con frecuencia, las guías sugieren

el uso de procesos de evaluación formal cuando los problemas estén

asociados con riesgos de impacto medio o alto, o cuando los problemas

afecten a la capacidad para lograr los objetivos del trabajo.

Definir bien un problema ayuda a definir el alcance de las alternativas a

considerar. El alcance correcto (esto es, ni demasiado amplio ni demasiado

reducido) favorecerá la toma de una decisión apropiada para resolver el

problema definido.

Los procesos de evaluación formal pueden variar en cuanto a formalidad,

tipo de criterios, y métodos empleados. Las decisiones menos formales

pueden analizarse en pocas horas, utilizan pocos criterios (p. ej., eficacia,

coste de implementación), y concluyen con un informe de una o dos

páginas. Las decisiones más formales pueden requerir planes separados,

meses de trabajo, reuniones para desarrollar y aprobar criterios,

simulaciones, prototipos, pilotos, y documentación extensa.

En un proceso de evaluación formal se pueden utilizar tanto criterios

numéricos como no numéricos. Los criterios numéricos utilizan pesos para

reflejar la importancia relativa de los criterios. Los criterios no numéricos

utilizan una escala de valores subjetiva (p. ej., alto, medio, bajo). Las

decisiones más formales pueden requerir un estudio completo de

contraprestaciones.

Un proceso de evaluación formal identifica y evalúa soluciones alternativas.

La eventual selección de una solución puede implicar actividades iterativas

de identificación y evaluación. Partes de las alternativas identificadas

pueden combinarse, las alternativas pueden modificarse por tecnologías

emergentes, y durante el periodo de evaluación puede variar la situación

de negocio de los suministradores.

Una alternativa recomendada se acompaña de la documentación de los

métodos seleccionados, los criterios, las alternativas, y la justificación de la

recomendación. La documentación se distribuye a las partes interesadas

relevantes; ésta proporciona un registro del proceso de evaluación formal y

su justificación, que es útil para otros grupos de trabajo que se encuentren

con problemas similares.

Mientras que algunas de las decisiones tomadas a lo largo del trabajo

implican utilizar un proceso de evaluación formal, otras no lo hacen. Como



se mencionó anteriormente, deberían establecerse guías para determinar

qué problemas estarían sujetos a un proceso de evaluación formal.




más información sobre identificar y analizar riesgos y mitigar riesgos,

consúltese el área de proceso Gestión de Riesgos.


SG 1 Evaluar Alternativas

SP 1.1 Establecer guías para el análisis de decisiones

SP 1.2 Establecer criterios de evaluación

SP 1.3 Identificar soluciones alternativas

SP 1.4 Seleccionar métodos de evaluación

SP 1.5 Evaluar soluciones alternativas

SP 1.6 Seleccionar soluciones


SG 1 Evaluar alternativas

Las decisiones se basan en evaluar alternativas utilizando criterios establecidos.

En cualquier momento pueden identificarse problemas que requieren un

proceso de evaluación formal. El objetivo debería ser identificar los

problemas cuanto antes para maximizar el tiempo disponible para

resolverlos.

SP 1.1 Establecer guías para el análisis de decisiones

Establecer y mantener guías para determinar qué problemas están

sujetos a un proceso de evaluación formal.

No todas las decisiones son lo suficientemente significativas como para

requerir un proceso de evaluación formal. La elección entre lo trivial y lo

realmente importante no es clara si no hay una orientación explícita. Si una

decisión es significativa o no depende del trabajo y de las circunstancias, y

se determina por medio de guías establecidas.



Algunas guías habituales para determinar cuándo se requiere un proceso de evaluación

formal son:

La decisión está directamente relacionada con problemas que tienen un riesgo de

impacto medio o alto.

La decisión está relacionada con cambios en productos de trabajo bajo gestión de

configuración.

La decisión causaría retrasos en los plazos superiores a un cierto porcentaje o a una

cantidad de tiempo.

La decisión afecta a la capacidad del grupo de trabajo para lograr sus objetivos.

El coste del proceso de evaluación formal es razonable en comparación con el impacto

de la decisión.

Existe una obligación legal durante una licitación.

Cuando requisitos de atributos de calidad que son contrapuestos pueden producir

soluciones para el sistema de servicio significativamente diferentes.

Para más información sobre evaluar, categorizar, y priorizar los riesgos,


Algunos ejemplos de actividades en las que se puede utilizar un proceso de evaluación

formal son:

Seleccionar elementos que se van a incluir en las descripciones de servicio estándar.

Seleccionar, rescindir, o renovar suministradores.

Seleccionar la capacitación para los miembros del grupo de trabajo.

Seleccionar un enfoque para el soporte continuo (p. ej. recuperación tras desastres,

niveles de servicio).


1. Guías sobre cuándo aplicar un proceso de evaluación formal.

Subprácticas

1. Establecer guías para determinar cuándo utilizar un proceso de

evaluación formal.

2. Incorporar el uso de guías en el proceso definido, según sea

apropiado.

Para más información sobre establecer el proceso definido para un

trabajo, consúltese el área de proceso Gestión Integrada de Trabajos.

SP 1.2 Establecer criterios de evaluación

Establecer y mantener los criterios para evaluar alternativas y la

valoración relativa de dichos criterios.

Los criterios de evaluación proporcionan la base para evaluar las

soluciones alternativas. Los criterios se valoran de tal modo que los

criterios con mayor valoración ejerzan mayor influencia en la evaluación.



Esta área de proceso está referenciada desde muchas otras áreas de

proceso del modelo, y desde muchos contextos en los que se puede utilizar

un proceso de evaluación formal. Por lo tanto, en algunas situaciones

puede ocurrir que los criterios ya hayan sido definidos como parte de otro

proceso. Esta práctica específica no sugiere que se tenga que volver a

realizar el desarrollo de criterios por segunda vez.

Un buen enunciado del problema a abordar y la decisión a tomar permite

que se enfoque el análisis que hay que realizar. Un enunciado así también

ayuda a definir criterios de evaluación que minimicen la posibilidad de que

las decisiones se sobreentiendan o de que se olviden las razones que

sirvieron para tomarlas. Las decisiones basadas en criterios que están

explícitamente definidos y establecidos eliminan barreras de las partes

interesadas para aceptarlas.


1. Criterios de evaluación documentados.

2. Valoración de la importancia de los criterios.

Subprácticas

1. Definir los criterios para evaluar las soluciones alternativas.

Los criterios deben ser trazables a los requisitos, escenarios, supuestos del caso de

negocio, objetivos de negocio, u otras fuentes documentadas.

Algunos tipos de criterios a considerar son:

Limitaciones tecnológicas.

Impacto medioambiental.

Riesgos.

Valor para el negocio.

Impacto sobre las prioridades.

Coste total de la propiedad y coste del ciclo de vida.

2. Definir el rango y la escala para valorar los criterios de evaluación.

Se pueden establecer escalas de importancia relativa de los criterios de evaluación

con valores no numéricos o con fórmulas que relacionen el parámetro de evaluación

con un peso numérico.

3. Valorar los criterios.

Los criterios se valoran de acuerdo al rango y escala definidos con objeto de reflejar

las necesidades, objetivos, y prioridades de las partes interesadas relevantes.

4. Evaluar los criterios y su importancia relativa.

5. Evolucionar los criterios de evaluación para mejorar su validez.

6. Documentar la justificación para seleccionar y rechazar criterios de

evaluación.

Puede que la documentación sobre los criterios de selección y su justificación sean

necesarias para argumentar soluciones o para su futura referencia y uso.



SP 1.3 Identificar soluciones alternativas

Identificar soluciones alternativas para abordar los problemas.

Se puede obtener un abanico más amplio de alternativas solicitando

aportaciones a tantas partes interesadas como sea conveniente. Las

aportaciones de partes interesadas que tengan diferentes habilidades y

experiencia pueden ayudar a que los equipos identifiquen y aborden

supuestos, restricciones, y sesgos. Las sesiones de tormenta de ideas

pueden promover alternativas innovadoras por medio de rápidas

interacciones y realimentaciones.

Puede que no se aporten suficientes soluciones candidatas para su

análisis. A medida que avance el análisis, deberían añadirse otras

alternativas a la lista de soluciones candidatas potenciales. Generar y

considerar varias alternativas al inicio de un proceso de análisis de

decisiones y resolución incrementa la probabilidad de que se tome una

decisión aceptable y de que se comprendan las consecuencias de la

decisión.


1. Alternativas identificadas.

Subprácticas

1. Realizar una búsqueda bibliográfica.

Una búsqueda bibliográfica puede descubrir lo que otros han realizado, tanto dentro

como fuera de la organización. Esta búsqueda puede permitir entender más

profundamente el problema, las alternativas a considerar, las barreras para la

implementación, los estudios existentes de contraprestaciones, y las lecciones

aprendidas en decisiones similares.

2. Identificar otras alternativas a considerar además de las alternativas

que pudieron proporcionarse con el problema.

Los criterios de evaluación son un eficaz punto de partida para identificar alternativas.

Los criterios de evaluación identifican las prioridades de las partes interesadas

relevantes y la importancia de los retos técnicos, logísticos, o de otro tipo.

Combinar atributos clave de alternativas existentes puede generar alternativas

adicionales que a veces son más sólidas.

Solicite alternativas a las partes interesadas relevantes. Se pueden utilizar sesiones

de tormenta de ideas, entrevistas, y grupos de trabajo para descubrir alternativas

eficazmente.

3. Documentar las alternativas propuestas.

SP 1.4 Seleccionar métodos de evaluación

Seleccionar métodos de evaluación.

Los métodos para evaluar soluciones alternativas con respecto a criterios

establecidos van desde simulaciones hasta el uso de modelos

probabilísticos y la teoría de decisiones. Estos métodos deberían

seleccionarse minuciosamente. El nivel de detalle de un método debería



estar en consonancia con el coste, plazos, rendimiento, e impacto de los

riesgos.

Aunque puede que un único método de evaluación sea suficiente para

muchos problemas, algunos problemas pueden requerir de varios métodos.

Por ejemplo, las simulaciones pueden ampliar un estudio de

contraprestaciones para determinar qué alternativa de diseño es la que

mejor cumple un criterio determinado.


1. Métodos de evaluación seleccionados.

Subprácticas

1. Seleccionar métodos en base al propósito que tiene analizar la

decisión y a la disponibilidad de información que se necesita para

utilizar el método.

Por ejemplo, los métodos utilizados para evaluar una solución cuando los requisitos están pobremente definidos pueden ser diferentes de los métodos utilizados cuando los requisitos están bien definidos.

Algunos métodos de evaluación habituales son:

Modelado y simulación.

Estudios de ingeniería.

Estudios de fabricación.

Pruebas.

Estudios de costes.

Estudios de oportunidades de negocio.

Encuestas.

Extrapolaciones basadas en experiencias de campo y en prototipos.

Revisiones y comentarios de usuarios finales.

Juicios proporcionados por un experto o grupos de expertos (p. ej. método Delphi).

2. Seleccionar los métodos de evaluación en base a su capacidad para

centrarse en los problemas en cuestión y no dejarse influir demasiado

por problemas secundarios.

Los resultados de las simulaciones pueden quedar distorsionados por actividades

aleatorias en la solución que no están directamente relacionadas con los problemas

en cuestión.

3. Determinar las medidas necesarias para dar soporte al método de

evaluación.

Considerar el impacto en costes, plazos, rendimiento, y riesgos.

SP 1.5 Evaluar soluciones alternativas

Evaluar las soluciones alternativas utilizando criterios y métodos

establecidos.



Evaluar las soluciones alternativas implica analizar, debatir, y revisar.

Algunas veces se necesitan ciclos iterativos de análisis. Para sustanciar la

valoración y las conclusiones, puede que sea necesario realizar análisis de

soporte, experimentación, prototipos, pilotos, o simulaciones.

Con frecuencia, la importancia relativa de los criterios es imprecisa y su

efecto total sobre la solución no es manifiesto hasta que se realiza el

análisis. En los casos en los que las valoraciones resultantes difieran en

cantidades relativamente pequeñas, puede que no esté clara cuál es la

mejor selección de entre las soluciones alternativas. Debería fomentarse

realizar cuestionamientos de los criterios y supuestos.


1. Resultados de la evaluación.

Subprácticas

1. Evaluar las soluciones alternativas propuestas utilizando los criterios

de evaluación establecidos y los métodos seleccionados. .

2. Evaluar los supuestos relacionados con los criterios de evaluación y

las evidencias que dan soporte a los supuestos.

3. Evaluar si las incertidumbres en la valoración de las soluciones

alternativas afectan o no a la evaluación, y abordar estas

incertidumbres según sea apropiado.

Por ejemplo, si la valoración cambia entre dos valores, ¿es la diferencia lo

suficientemente significativa como para cambiar la solución final en su conjunto? ¿El

cambio en la valoración representa un riesgo de alto impacto? Para abordar estos

aspectos pueden realizarse simulaciones, estudios adicionales, o pueden modificarse

los criterios de evaluación, entre otras cosas.

4. Realizar simulaciones, modelos, prototipos, y pilotos, según se

necesite, para poner en práctica los criterios de evaluación, los

métodos, y las soluciones alternativas.

Los criterios no probados, su importancia relativa, y los datos o funciones de soporte

pueden ser la causa de que se cuestione la validez de las soluciones. Los criterios y

sus prioridades y escalas relativas pueden probarse con ensayos frente a un conjunto

de alternativas. Estos ensayos de un conjunto escogido de criterios permiten evaluar

cuál es el impacto acumulado de los criterios sobre una solución. Si los ensayos

revelan problemas, podrían considerarse criterios o alternativas distintas para evitar

sesgos.

5. Considerar nuevas soluciones alternativas, criterios, o métodos si las

alternativas propuestas no pasan la prueba; repetir las evaluaciones

hasta que las alternativas pasen la prueba.

6. Documentar los resultados de la evaluación.

Documentar la justificación de que se agreguen nuevas alternativas o métodos y de

los cambios en los criterios, así como los resultados de las evaluaciones intermedias.



SP 1.6 Seleccionar soluciones

Seleccionar soluciones a partir de las alternativas en base a los

criterios de evaluación.

La selección de soluciones implica ponderar los resultados de la evaluación

de las alternativas. Se deberían evaluar los riesgos asociados a la

implementación de las soluciones.


1. Soluciones recomendadas para abordar problemas significativos.

Subprácticas

1. Evaluar los riesgos asociados a la implementación de la solución

recomendada.

Para más información sobre identificar y analizar riesgos y mitigar

riesgos, consúltese el área de proceso Gestión de Riesgos.

A menudo las decisiones tienen que realizarse con información incompleta. Puede

haber un riesgo sustancial asociado a la decisión por la existencia de información

incompleta.

Cuando las decisiones tienen que tomarse de acuerdo a unos plazos específicos,

puede que no se disponga del tiempo ni de los recursos necesarios para recoger toda

la información. Por consiguiente, las decisiones con riesgo realizadas con información

incompleta pueden requerir un nuevo análisis posterior. Los riesgos identificados

deberían ser monitorizados.

2. Documentar y comunicar a las partes interesadas relevantes los

resultados y la justificación de la solución recomendada.

Es importante registrar tanto el motivo de que se haya seleccionado una solución

como el de que se hayan rechazado otras.


Resolución y Prevención de Incidencias (IRP) 179

RESOLUCIÓN Y PREVENCIÓN DE INCIDENCIAS

Un área de proceso de Establecimiento y Prestación de Servicios en el nivel de madurez 3

Propósito

El propósito de Resolución y Prevención de Incidencias (IRP) es asegurar

que las incidencias en el servicio se resuelvan a tiempo y de forma eficaz y

que las incidencias en el servicio se eviten según sea apropiado.


El área de proceso Resolución y Prevención de Incidencias engloba las


Identificar y analizar incidencias en el servicio.

Iniciar acciones específicas para tratar las incidencias.

Monitorizar el estado de las incidencias, seguir el progreso del estado

de las incidencias, y escalarlas según se necesite.

Identificar y analizar las causas subyacentes de las incidencias.

Identificar soluciones temporales que hagan posible la continuidad del

servicio.

Iniciar acciones específicas para abordar las causas subyacentes o

para proporcionar soluciones temporales.

Comunicar el estado de las incidencias a las partes interesadas

relevantes.

Validar con las partes interesadas relevantes que las resoluciones de

las incidencias son completas.

En esta área de proceso y en otras áreas del modelo en las que el contexto

deje claro su significado el término “incidencia” se utiliza para hacer

referencia a una “incidencia en el servicio”. El término “incidencia en el

servicio” se utiliza en el glosario y en otras partes del modelo para

diferenciar a este término específicamente definido del uso habitual de la

palabra “incidencia” (véase la definición de “incidencia en el servicio” en el

glosario).

Las incidencias son eventos que, si no se tratan, pueden llegar a causar el

incumplimiento de los compromisos de servicio adoptados por la

organización proveedora. Por tanto, la organización proveedora de

servicios debería tratar las incidencias de una manera oportuna y eficaz,

conforme a los términos del acuerdo de servicio.

Tratar las incidencias puede incluir las siguientes actividades:

Eliminar una o varias causas subyacentes.

Minimizar el impacto de una incidencia.

Monitorizar la condición o serie de eventos que causan la incidencia.



Proporcionar una solución temporal.

Las incidencias pueden ser la causa o la indicación de interrupciones o

interrupciones potenciales en un servicio.

Algunos ejemplos de interrupciones en un servicio son: que una aplicación de software no

funcione durante las horas de operativa normal, que un ascensor se estropee, que una

habitación de un hotel se reserve dos veces, y que una maleta se pierda en un aeropuerto.

Algunos ejemplos de interrupciones potenciales en un servicio son: que un componente de

un equipo resistente a fallos se estropee, que una cola en la caja de un supermercado

tenga más de 3 personas, y que un centro de llamadas no tenga suficiente personal.

Las quejas de los clientes son un tipo especial de interrupción potencial.

Una queja indica que el cliente percibe que el servicio no cumple sus

expectativas, incluso si el cliente está equivocado con respecto a lo se

establece en el acuerdo. Por tanto, las quejas deberían ser gestionadas

como incidencias, y están dentro del alcance del área de proceso

Resolución y Prevención de Incidencias.

Todas las incidencias tienen una o más causas subyacentes,

independientemente de si el proveedor de servicios es consciente o no de

la causa. Por ejemplo, cada caída de sistema tiene una causa subyacente,

ya sea una fuga de memoria, una base de datos corrupta, o un error del

operador.

La causa subyacente de una incidencia es la condición o el evento que

contribuye a que una o más incidencias ocurran. No todas las causas

subyacentes tienen como resultado incidencias de forma inmediata. Por

ejemplo, un defecto en una parte de un sistema que no se use

frecuentemente puede no producir incidencias durante mucho tiempo.

Las causas subyacentes pueden ser cualquiera de las siguientes:

Causas raíces controlables por el proveedor de servicios y que pueden

y deben ser eliminadas.

Condiciones positivas o negativas en un servicio que pueden o no ser

eliminadas.

Condiciones que el proveedor de servicios no puede cambiar (p. ej.

condiciones climáticas).

Los términos causa subyacente y causa raíz (según se describe en el área

de proceso Análisis Causal y Resolución) no son sinónimos. Una causa

raíz es un tipo de causa subyacente que inicia la cadena causal de un

resultado de interés. Normalmente no buscamos la causa de una causa

raíz, y normalmente, cuando abordamos la causa raíz, esperamos lograr la

mayor reducción en la ocurrencia de incidencias.

A veces, por razones prácticas o económicas no somos capaces de

abordar la causa raíz, y en su lugar nos centramos en otras causas

subyacentes no raíces. Del mismo modo, no siempre tiene sentido

económico eliminar todas las causas subyacentes. En algunas



circunstancias puede que sea más eficaz tratar las incidencias con

soluciones temporales o simplemente resolverlas de una en una.

Las prácticas eficaces para resolver incidencias comienzan por el

desarrollo de un proceso de tratamiento de incidencias con el cliente, los

usuarios finales, y otras partes interesadas relevantes que reportan

incidencias. Las organizaciones pueden disponer de una colección de

incidencias, causas subyacentes de incidencias, y soluciones temporales

conocidas, así como de actividades separadas aunque relacionadas

diseñadas para crear acciones de tratamiento de las incidencias

seleccionadas y de sus causas subyacentes. Procesar todas las

incidencias y analizar las incidencias seleccionadas y sus causas

subyacentes con objeto de definir enfoques de tratamiento son dos

actividades de refuerzo que pueden realizarse en paralelo o

secuencialmente.

Así, el área de proceso Resolución y Prevención de Incidencias tiene tres

metas específicas. La meta Preparar la resolución y prevención de

incidencias ayuda a asegurar que se establece un enfoque para resolver

las incidencias de manera oportuna y, cuando sea posible, evitarlas

eficazmente. Las prácticas específicas de la meta Identificar, controlar, y

tratar cada incidencia se utilizan para tratar y cerrar incidencias a medida

que ocurren, a menudo aplicando soluciones temporales u otras acciones

definidas en la meta Analizar y tratar las causas e impactos de las

incidencias seleccionadas.


Para más información sobre monitorizar y analizar la capacidad y

disponibilidad, consúltese el área de proceso Gestión de Capacidad y

Disponibilidad.



Para más información sobre determinar las causas de los resultados

seleccionados, consúltese el área de proceso Análisis Causal y

Resolución.

Para más información sobre seguir y controlar los cambios, consúltese al

área de proceso Gestión de Configuración.

Para más información sobre identificar y analizar riesgos y mitigar riesgos,


Para más información sobre proporcionar información sobre el trabajo en

curso de modo que se puedan realizar las acciones correctivas apropiadas

cuando el rendimiento se desvíe significativamente con respecto al plan,





SG 1 Preparar la resolución y prevención de incidencias

SP 1.1 Establecer un enfoque para la resolución y prevención de incidencias

SP 1.2 Establecer un sistema de gestión de incidencias

SG 2 Identificar, controlar, y tratar cada incidencia

SP 2.1 Identificar y registrar incidencias

SP 2.2 Analizar los datos de cada incidencia

SP 2.3 Resolver incidencias

SP 2.4 Monitorizar el estado de las incidencias hasta su cierre

SP 2.5 Comunicar el estado de las incidencias

SG 3 Analizar y tratar las causas e impactos de las incidencias seleccionadas

SP 3.1 Analizar las incidencias seleccionadas

SP 3.2 Establecer soluciones para responder a futuras incidencias

SP 3.3 Establecer y aplicar soluciones para reducir la ocurrencia de incidencias


SG 1 Preparar la resolución y prevención de incidencias

Se lleva a cabo la preparación de la resolución y prevención de incidencias.

Establecer y mantener un enfoque para asegurar que las incidencias se

resuelven y se evitan de manera oportuna y eficaz, con objeto de asegurar

que los términos del acuerdo de servicio se cumplan.

SP 1.1 Establecer un enfoque para la resolución y prevención de incidencias

Establecer y mantener un enfoque para la resolución y prevención

de incidencias.

El enfoque para la resolución y prevención de incidencias describe las

funciones organizativas implicadas en la resolución y prevención de

incidencias, los procedimientos empleados, las herramientas de soporte

utilizadas, y la asignación de responsabilidades durante el ciclo de vida de

las incidencias. Este enfoque habitualmente se documenta.

A menudo, el tiempo del que se dispone para tratar completamente una

incidencia está definido antes de empezar la prestación de servicios y está

documentado en el acuerdo de servicio.

En muchos dominios de servicios, el enfoque para la resolución y

prevención de incidencias implica una función denominada “atención a

usuarios”, “mostrador de servicio”, o de muchas otras formas. Esta función

habitualmente es la que se comunica con el cliente, acepta las incidencias,

aplica las soluciones temporales, y trata las incidencias. Sin embargo, esta

función no está presente en todos los dominios de servicios.

Adicionalmente, otros grupos funcionales se incluyen rutinariamente en el

tratamiento de las incidencias según sea apropiado.






1. Enfoque de gestión de incidencias.

2. Criterios de incidencias.

Subprácticas

1. Definir criterios para determinar qué es una incidencia.

Para ser capaces de identificar incidencias válidas, se definen criterios que permiten a

los proveedores de servicios determinar qué es una incidencia y qué no lo es.

Habitualmente también se definen criterios para diferenciar la gravedad y la prioridad

de cada incidencia.

2. Definir categorías para las incidencias así como criterios para

determinar a qué categorías pertenece cada incidencia.

Disponer de un conjunto de categorías, niveles de gravedad, y otros criterios para

asignar tipos a las incidencias facilita su resolución. Estos criterios predeterminados

pueden posibilitar que la priorización, asignación, y escalación sean rápidas y

eficientes.

En función del servicio, las categorías de incidencias apropiadas varían. Como ejemplo, las categorías de incidencias de seguridad en las TI incluyen:

Sondeos o escaneos de sistemas internos o externos (p. ej. redes, aplicaciones web, servidores de correo).

Accesos de administrador o con privilegios (esto es, root) a cuentas, aplicaciones, servidores, redes, etc.

Ataques distribuidos de denegación del servicio, alteraciones a sitios web, código malicioso (p. ej. virus).

Ataques internos u otras formas de uso inadecuado de recursos (p. ej. compartir contraseñas).

Pérdida de datos de carácter personal.

Se establecen criterios que hacen posible que el personal de servicio identifique las

incidencias importantes rápida y fácilmente.

Algunos ejemplos de enfoques para el nivel de gravedad de las incidencias son:

Crítica, alta, media, baja.

Escalas numéricas (p. ej. 1-5, siendo 1 la más alta).

3. Describir cómo se asigna y transfiere la responsabilidad del

procesamiento de las incidencias.

La descripción puede incluir:

Quién es responsable de abordar las causas subyacentes de las incidencias.

Quién es responsable de monitorizar y seguir el estado de las incidencias.

Quién es responsable de seguir el progreso de las acciones relacionadas con las incidencias.

Procedimientos de escalado.

Cómo se asigna y se transfiere la responsabilidad de todos estos elementos.



4. Identificar uno o más mecanismos para que los clientes y usuarios

finales puedan reportar incidencias.

Estos mecanismos explican la forma en que los grupos e individuos pueden reportar

incidencias.

5. Definir métodos y adquirir herramientas a utilizar para la gestión de

incidencias.

6. Describir el modo de notificar a todos los clientes y usuarios finales

relevantes que puedan estar afectados por una incidencia reportada.

El modo de comunicarse con los clientes y usuarios finales habitualmente se

documenta en el acuerdo de servicio.

7. Definir criterios para determinar los niveles de gravedad y prioridad,

así como las categorías de acciones y respuestas que pueden

realizarse en base a los niveles de gravedad y prioridad.

Algunos ejemplos de respuestas en función del nivel de gravedad y prioridad son: actuar inmediatamente a corto plazo, repetir la capacitación o actualizar la documentación, y retrasar la respuesta hasta más adelante.

8. Identificar requisitos en el acuerdo de servicio acerca del tiempo

disponible que está definido para resolver las incidencias.

A menudo, antes de empezar la prestación de servicios se definen y documentan en

el acuerdo de servicio los tiempos mínimo y máximo disponibles para resolver las

incidencias.

Para más información sobre establecer acuerdos de servicio,


9. Documentar los criterios que definen cuándo deberían cerrarse las

incidencias.

No todas las causas subyacentes de las incidencias tienen que tratarse, ni todas las

incidencias tienen que tener soluciones temporales. Las incidencias no deberían

cerrarse hasta que se cumplan los criterios documentados.

A menudo se utilizan códigos de cierre para clasificar cada incidencia. Estos códigos

son útiles cuando se analizan los datos en mayor profundidad.

SP 1.2 Establecer un sistema de gestión de incidencias

Establecer y mantener un sistema de gestión de incidencias para

procesar y seguir la información sobre las incidencias.

Un sistema de gestión de incidencias incluye los medios de

almacenamiento, los procedimientos, y las herramientas de acceso al

sistema de gestión de incidencias. Estos medios de almacenamiento,

procedimientos, y herramientas pueden automatizarse, pero no es

necesario automatizarlos. Por ejemplo, los medios de almacenamiento

podrían consistir en un sistema de archivos en el que se almacenen

documentos. Los procedimientos pueden documentarse en papel, y las

herramientas pueden ser herramientas manuales o instrumentos para

realizar el trabajo sin ayuda automatizada.



Se debería disponer de una colección de datos históricos que cubran

incidencias tratadas, causas subyacentes de incidencias, enfoques

conocidos para tratar incidencias, y soluciones temporales con objeto de

dar soporte a la gestión de incidencias.


1. Un sistema de gestión de incidencias con productos de trabajo

controlados.

2. Procedimientos de control de acceso para el sistema de gestión de

incidencias.

Subprácticas

1. Asegurar que el sistema de gestión de incidencias permite escalarlas y

transferirlas entre los grupos.

Puede que sea necesario transferir o escalar incidencias entre grupos por motivo de

que el grupo que introdujo la incidencia puede no ser el más adecuado para realizar

las acciones para tratarla.

2. Asegurar que el sistema de gestión de incidencias permite almacenar,

actualizar, recuperar, y reportar información de incidencias que sea útil

para resolver y prevenir las incidencias.

Algunos ejemplos de sistema de gestión de incidencias son:

Archivos físicos indexados de quejas de clientes y sus resoluciones.

Software para seguir los errores o los problemas.

Software de atención a usuarios.

3. Mantener la integridad del sistema de gestión de incidencias y su

contenido.

Algunos ejemplos de mantenimiento de la integridad del sistema de gestión de incidencias son:

Realizar copias de seguridad y restaurar ficheros de incidencias.

Archivar ficheros de incidencias.

Recuperarse de errores en las incidencias.

Mantener la seguridad para evitar accesos no autorizados.

4. Mantener el sistema de gestión de incidencias según se necesite.

El mantenimiento debería incluir eliminar la información obsoleta y consolidar la

información redundante que se acumula a lo largo del tiempo.

SG 2 Identificar, controlar, y tratar cada incidencia

Cada incidencia se identifica, se controla, y se trata.

Este objetivo se centra gestionar las incidencias individuales a medida que

ocurren con objeto de restaurar el servicio o de resolver las incidencias tan

rápido como sea posible. La gestión de incidencias individuales puede

incluir que se gestionen varias incidencias relacionadas por medio de

acciones centradas en completar o restaurar una prestación de servicios



que ya esté afectada. Las prácticas comprendidas en esta meta incluyen

las interacciones entre los que reportan incidencias y los que están

afectados por ellas. El procesamiento y seguimiento de los datos tiene

lugar en estas prácticas hasta que la incidencia se ha tratado y cerrado.

Tratar incidencias puede incluir recopilar y analizar datos para buscar

incidencias potenciales, o simplemente esperar a que los usuarios finales o

los clientes reporten incidencias.

Las prácticas específicas de esta meta también pueden depender de las

prácticas de la meta Analizar y tratar las causas e impactos de las

incidencias seleccionadas. Las prácticas en aquella meta se utilizan para

identificar y definir el rango de enfoques que está disponible para tratar

incidencias concretas que se utiliza en esta meta.

A menudo las incidencias involucran a productos de trabajo bajo gestión de

configuración.



SP 2.1 Identificar y registrar incidencias

Identificar incidencias y registrar información sobre ellas.

Los problemas de capacidad, rendimiento, o disponibilidad a menudo

señalan incidencias potenciales.



Disponibilidad.


1. Registro de gestión de incidencia.

Subprácticas

1. Identificar las incidencias que están dentro del alcance.

Algunos ejemplos de cómo se pueden identificar incidencias son:

Incidencias que el cliente reporta a atención a usuarios por teléfono.

Incidencias que el usuario final reporta por medio de un formulario web.

Incidencias detectadas por un sistema automático de detección.

Incidencias derivadas del análisis de anomalías en los datos recogidos.

Monitorización y análisis de fuentes de información externas (p. ej. fuentes de RSS, servicios de noticias, sitios web).

2. Registrar información sobre la incidencia.

Al registrar la información sobre una incidencia, registrar información suficiente para

dar soporte a las actividades de análisis y resolución.



Algunos ejemplos de información sobre incidencias que se registra son:

Nombre e información de contacto de la persona que reporta la incidencia.

Descripción de la incidencia.

Categorías a las que pertenece la incidencia.

Fecha y hora en las que se produjo la incidencia, y fecha y hora en las que se reportó.

Elementos de la configuración involucrados en la incidencia.

Código e información de cierre.

Características relevantes de la situación en la que se produjo la incidencia.

3. Categorizar la incidencia.

Utilizando las categorías establecidas en el enfoque de resolución y prevención de

incidencias, asignar las categorías relevantes a la incidencia en el sistema de gestión

de incidencias. Comunicar el estado de la incidencia a quienes la reportaron posibilita

que el proveedor de servicios pueda confirmar la información sobre la incidencia de

forma temprana.

SP 2.2 Analizar los datos de cada incidencia

Analizar los datos de cada incidencia para determinar un curso de

acción.

Puede que el mejor curso de acción sea no hacer nada, tratar la incidencia

como un caso único, aumentar la monitorización de otras incidencias,

educar al usuario final, o emplear una solución temporal u otra solución

conocida reutilizable establecida previamente para tratar incidencias

similares.

El análisis comprendido en esta práctica se centra en resolver las

incidencias a medida que ocurren por medio de un curso de acción que sea

suficientemente oportuno y eficaz como para cubrir las necesidades

inmediatas de la petición de servicio. Consúltese la meta Analizar y tratar

las causas e impactos de las incidencias seleccionadas cuando, para

mitigar incidencias futuras, se requieran análisis y acciones en mayor en

profundidad.


1. Informe de incidencias importantes.

2. Informe de asignación de incidencias.

Subprácticas

1. Analizar los datos sobre la incidencia.

Para incidencias conocidas, el análisis puede realizarse simplemente seleccionando el

tipo de incidencia. Para incidencias importantes, puede que haga falta constituir un

equipo de resolución separado para analizar la incidencia.

2. Determinar qué grupo es el más adecuado para realizar las acciones

para tratar la incidencia.



La selección del grupo más adecuado para realizar las acciones para tratar la

incidencia puede depender de distintos factores, incluyendo el tipo de incidencia, las

localizaciones implicadas, y la gravedad.

Algunos ejemplos de grupos que tratan con tipos distintos de incidencias son:

Un equipo de cuidado de la salud que trata con resultados médicos adversos.

Un grupo de soporte de red que trata con incidencias de conectividad a la red.

Un grupo de atención a usuarios que trata con incidencias relacionadas con contraseñas.

3. Determinar las acciones que se deberían realizar para tratar la

incidencia.

Algunos ejemplos de acciones son:

Reemplazar un componente roto.

Notificar o recordar los procedimientos correctos a los clientes, usuarios finales, o al personal de prestación de servicios.

Publicar anuncios (p. ej. nota de prensa, respuesta a los medios, boletín, notificación a clientes o a otras partes interesadas relevantes).

4. Planificar las acciones a realizar.

SP 2.3 Resolver incidencias

Resolver incidencias.

Las incidencias se resuelven siguiendo el curso de acción determinado por

el análisis de cada incidencia. Es posible que el curso de acción

seleccionado inicialmente no sirva para resolver la incidencia o que la

resuelva parcialmente, en cuyos casos puede que sea necesario realizar

análisis y acciones adicionales.

Aplicar soluciones temporales u otras soluciones reutilizables previamente

establecidas puede reducir significativamente el impacto de las incidencias,

que de otra forma se tratarían caso por caso. El uso de soluciones

reutilizables ya conocidas para resolver incidencias ayuda a reducir el

tiempo que se necesita para resolverlas, y también puede mejorar la

calidad de las resoluciones. Es esencial establecer un repositorio único que

contenga todas las soluciones reutilizables previamente establecidas. Este

repositorio puede utilizarse para determinar rápidamente la solución

reutilizable apropiada que hay que utilizar en incidencias similares.


1. Registro de gestión de incidencias actualizado.

Subprácticas

1. Tratar la incidencia utilizando el mejor curso de acción.

El mejor curso de acción puede emplear una solución temporal u otra solución

reutilizable previamente establecida, si hay una disponible.

2. Gestionar las acciones hasta que el impacto de la incidencia llegue a

un nivel aceptable.



3. Registrar las acciones y el resultado.

4. Revisar las acciones realizadas que dieron como resultado cambios en

el sistema de servicio con objeto de determinar si son necesarias

acciones adicionales que aseguren la trazabilidad a los requisitos.

SP 2.4 Monitorizar el estado de las incidencias hasta su cierre

Monitorizar el estado de las incidencias hasta su cierre.

A lo largo de toda la vida de la incidencia, su estado debería registrarse,

seguirse, escalarse según se necesite, y cerrarse.






1. Registros de gestión de incidencias cerradas.

Subprácticas

1. Documentar las acciones y monitorizar y seguir las incidencias hasta

que se cumplan los términos del acuerdo de servicio y se satisfaga a

quien reportó la incidencia según sea apropiado.

Monitorizar las respuestas a quienes reportaron la incidencia, así como el modo en

que se trató la incidencia hasta que se resolvió a la satisfacción del cliente o la

organización.

2. Escalar las incidencias según se necesite.

Para asegurar su resolución, las incidencias deberían seguirse, y escalarse según se

necesite, a lo largo de toda su vida. Puede que el escalado sea necesario cuando las

partes interesadas relevantes no estén satisfechas con la resolución, o cuando la

resolución sea urgente o requiera de procesos o recursos no estándar.

3. Revisar la resolución y confirmar los resultados con las partes

interesadas relevantes.

Confirmar que las causas subyacentes se trataron con éxito puede que implique

confirmar con la persona que reportó la incidencia u otras personas involucradas en el

análisis de la incidencia que las acciones realizadas, de hecho, dieron como resultado

que la incidencia dejó de ocurrir. Puede que parte del resultado de tratar una

incidencia sea el nivel de satisfacción que tiene el cliente.

Una vez que la incidencia se ha tratado, se confirma que el servicio vuelve a cumplir

los términos del acuerdo de servicio.

4. Cerrar las incidencias que cumplen los criterios de cierre.

SP 2.5 Comunicar el estado de las incidencias

Comunicar el estado de las incidencias.

Cuando se prestan servicios, la comunicación es un factor crítico,

especialmente cuando se producen incidencias. La comunicación con la



persona que reportó la incidencia, y posiblemente con quienes se vean

afectados por ésta, debería tenerse en cuenta a lo largo de toda la vida del

registro de la incidencia en el sistema de gestión de incidencias. Los

usuarios y clientes bien informados son más comprensivos y pueden

ayudar a que las incidencias se traten con éxito.

Puede que sea apropiado que el personal que resuelve las incidencias y el

que presta los servicios se comuniquen y coordinen para evitar que las

acciones de resolución de incidencias interfieran con la prestación de

servicios en curso.

Habitualmente, los resultados de las acciones se revisan con la persona

que reportó la incidencia para verificar que, de hecho, las acciones

resolvieron la incidencia a la satisfacción de quien la reportó.


1. Registros de comunicación con los clientes y usuarios finales.

2. Informes de situación.

SG 3 Analizar y tratar las causas e impactos de las incidencias seleccionadas

Las causas e impactos de las incidencias seleccionadas se analizan y se tratan.

Esta meta se centra en la reducción del impacto o la ocurrencia de

incidencias futuras. Las prácticas en esta meta cubren el análisis de

incidencias seleccionadas para definir cómo tratar en el futuro incidencias

similares. El resultado de este análisis se envía de vuelta a quienes

controlan y tratan las incidencias, y puede también conducir a que se eviten

ciertos tipos de incidencia.

Todas las incidencias tienen una o más causas subyacentes que

desencadenan su ocurrencia. El tratamiento de la causa subyacente de los

tipos de incidencia seleccionados puede reducir la probabilidad de que

haya interferencias en el servicio, disminuir la carga de trabajo del

proveedor de servicios, o mejorar el nivel de servicio.

Se pueden identificar causas subyacentes para incidencias que ya hayan

ocurrido y para tipos de incidencias que son posibles aunque nunca hayan

ocurrido.

Algunos ejemplos son: analizar la causa de un error en la entrega o de una parada del

sistema, y monitorizar el uso que un software hace de la memoria pare detectar fugas de

memoria tan pronto como sea posible.

La causa raíz de una incidencia es a menudo distinta de la causa

subyacente inmediata. Por ejemplo, una incidencia puede estar causada

por un componente de sistema defectuoso (la causa subyacente), mientras

que la causa raíz de la incidencia puede ser el proceso subóptimo de

selección de suministradores. Para permitir distintas soluciones posibles,

que van desde soluciones temporales hasta evitar completamente una

clase de incidencias relacionadas, esta área de proceso utiliza el término



“causa subyacente” de forma flexible, desde las causas o condiciones

inmediatas hasta las causas raíces más profundas.



Resolución.

SP 3.1 Analizar las incidencias seleccionadas

Analizar las causas subyacentes de las incidencias seleccionadas.

El propósito de realizar el análisis causal de las incidencias es determinar

el mejor curso de acción para tratar incidencias en el futuro, de forma que

sus impactos se minimicen con la mayor eficacia. Aunque frecuentemente

es deseable prevenir completamente las incidencias, otros objetivos de

negocio pueden limitar el punto hasta el que la prevención de incidencias

es eficaz. En algunos casos, puede que responder a ciertas incidencias

después de que ocurran a través de soluciones reutilizables sea más eficaz

que intentar empezar por reducir o evitar su ocurrencia. Por tanto, un

posible curso de acción es no tratar nunca las causas subyacentes y

continuar atendiendo a las incidencias después de que ocurran mediante el

uso de soluciones temporales y otras soluciones reutilizables, ya sean

soluciones recién establecidas o soluciones actualizadas.

A menudo, el análisis de incidencias involucra productos de trabajo que

están bajo gestión de configuración.

Es esencial establecer un único repositorio que contenga todas las

incidencias conocidas, sus causas subyacentes, y los enfoques para tratar

dichas causas subyacentes. Este repositorio puede utilizarse para

determinar rápidamente las causas de las incidencias que están

relacionadas.




1. Informe de las causas subyacentes de las incidencias.

2. Actividades de análisis causal documentadas.

Subprácticas

1. Identificar las causas subyacentes de las incidencias.



Algunos ejemplos de enfoques para identificar causas subyacentes de las incidencias son:

Analizar las incidencias que los clientes han reportado a atención a usuarios.

Monitorizar el sistema de servicio para identificar incidencias potenciales.

Analizar las tendencias en el uso de recursos.

Analizar las fortalezas y debilidades del sistema de servicio.

Analizar los tiempos medios entre fallos y la disponibilidad del sistema de servicio.

Analizar fuentes externas de información, tales como alertas, fuentes de noticias, y sitios web.



2. Registrar información sobre las causas subyacentes de una incidencia

o grupo de incidencias.

Cuando se registra información sobre las causas subyacentes de una incidencia,

registrar información suficiente como para dar soporte adecuado al análisis causal y

resolución.

Algunos ejemplos de información a registrar son:

Incidencias afectadas o potencialmente afectadas por una causa subyacente.

Elementos de configuración implicados.

Características relevantes de la situación en la que las incidencias se produjeron o podrían producirse.

3. Realizar los análisis causales con las personas responsables de

realizar las tareas relacionadas.

Para las causas subyacentes de las incidencias importantes, el análisis puede requerir

la constitución de un equipo separado que analice la causa subyacente.



Resolución.

4. Determinar el mejor enfoque global para abordar las incidencias

seleccionadas en el futuro.

Este enfoque puede incluir realizar cambios en el sistema de servicio que reduzcan o

eviten que ocurran incidencias similares, que limiten el impacto de incidencias

parecidas por medio de soluciones reutilizables, o que combinen algunos de estos

enfoques.

SP 3.2 Establecer soluciones para responder a futuras incidencias

Establecer y mantener soluciones para responder a futuras

incidencias.

Las soluciones reutilizables, tales como las soluciones temporales, son

mecanismos importantes que permiten dar continuidad a la prestación de

servicios a pesar de que ocurran incidencias (una solución temporal es una



solución subóptima desarrollada y desplegada para un cierto tipo de

incidencias que, sin embargo, es suficientemente eficaz como para que se

use mientras se desarrolla y despliega una solución mejor). Por tanto, es

importante que las soluciones temporales y otras soluciones reutilizables

se documenten y que, antes de utilizarlas para tratar incidencias con

clientes y usuarios finales, se confirme su eficacia.


1. Descripciones e instrucciones sobre soluciones reutilizables.

2. Contribuciones a la recopilación de soluciones temporales para

incidencias.

3. Resultados de verificar soluciones temporales.

Subprácticas

1. Determinar cuál es el grupo más adecuado para establecer y

mantener una solución reutilizable.

El grupo debería ser el más adecuado para definir la solución reutilizable, describir los

pasos necesarios, y comunicar esta información de forma apropiada.

2. Planificar y documentar la solución reutilizable.

3. Verificar y validar la solución reutilizable para asegurar que trata la

incidencia de forma eficaz.

4. Comunicar a las partes interesadas relevantes la solución reutilizable.

SP 3.3 Establecer y aplicar soluciones para reducir la ocurrencia de incidencias

Establecer y aplicar soluciones para reducir la ocurrencia de

incidencias seleccionadas.

Después de que el análisis determine las causas subyacentes de las

incidencias, si existen acciones a realizar, éstas se planifican y ejecutan.

Planificar incluye determinar quién actuará, cuándo, y cómo. Toda esta

información se documenta en una propuesta de acción. La propuesta de

acción es utilizada por quienes actúan para tratar las causas subyacentes

de las incidencias, y las acciones son gestionadas hasta su cierre. El

resultado final será la reducción de la ocurrencia de las incidencias

seleccionadas.



2. Contribución a la recopilación de enfoques conocidos para abordar

una causa subyacente de incidencias.

3. Registro de gestión de incidencia actualizado.

Subprácticas

1. Determinar qué grupo es el más adecuado para tratar la causa

subyacente.



El grupo más adecuado para tratar la causa subyacente puede depender del tipo de

causa subyacente, de los elementos de configuración implicados, y de la gravedad de

las incidencias relevantes.

Algunos ejemplos de grupos y departamentos que se encargan de tipos distintos de causas subyacentes son:

Un grupo de soporte de red que se encarga de problemas de red.

Un equipo de soporte de un servidor UNIX que se encarga de problemas de configuración del servidor.

Un departamento de recursos humanos que maneja problemas de privacidad.

Un departamento legal que controla problemas relacionados con la propiedad intelectual, la revelación de información, y la pérdida de datos.

Un departamento de relaciones públicas que es responsable de problemas relacionados con la reputación de la organización.

2. Determinar las acciones a llevar a cabo para tratar la causa

subyacente.

Al analizar las incidencias estándar, las acciones de tratamiento de dichas incidencias

estándar pueden documentarse por medio de un plan de acción estándar. Si la

incidencia no es estándar, debería realizarse una búsqueda en el historial de

incidencias recogidas y tratadas y de problemas conocidos para ver si la incidencia

está relacionada con otras. Para permitir este tipo de análisis, estos datos deberían

ser mantenidos, y de esta forma ahorrar tiempo y apalancar el esfuerzo.

Algunos ejemplos de acciones a realizar para tratar las causas subyacentes son:

Reemplazar un componente roto.

Capacitar a los usuarios o al personal que presta los servicios.

Corregir un defecto de software.

No tratar la causa subyacente si encargarse de las incidencias es más barato o menos arriesgado que tratar su causa subyacente.





3. Documentar en una propuesta de acción las acciones a realizar.

4. Verificar y validar la propuesta de acción para asegurarse de que trata

eficazmente la causa subyacente.

5. Comunicar la propuesta de acción a las partes interesadas relevantes.

6. Tratar la causa subyacente implementando la propuesta de acción

resultante del análisis de las causas subyacentes de la incidencia.

A menudo las acciones invocadas en una propuesta de acción incluirán mantener o

cambiar el sistema de servicio.





Extensión SSD



7. Gestionar las acciones hasta que la causa subyacente se haya

tratado.

Gestionar las acciones puede incluir escalar las incidencias seleccionadas según sea

apropiado.

Algunos ejemplos de criterios de escalado son:

Cuando el impacto de las incidencias seleccionadas sobre la organización o sobre el cliente sea grande.

Cuando tratar la causa subyacente de las incidencias seleccionadas conlleve un tiempo o esfuerzo considerables.

8. Registrar las acciones y el resultado.

Para dar soporte al futuro análisis de incidencias parecidas, se registran en el sistema

de gestión de incidencias las acciones utilizadas para tratar la causa subyacente de

las incidencias seleccionadas y los resultados de esos enfoques.


Gestión Integrada de Trabajos (IWM) 196

GESTIÓN INTEGRADA DE TRABAJOS


Propósito

El propósito de Gestión Integrada de Trabajos (IWM) es establecer y

gestionar el trabajo y la involucración de las partes interesadas relevantes

de acuerdo a un proceso integrado y definido que se adapta a partir del

conjunto de procesos estándar de la organización.


Gestión Integrada de Trabajos engloba las siguientes actividades:

Establecer al inicio del trabajo el proceso definido mediante la

adaptación del conjunto de procesos estándar de la organización.

Gestionar el trabajo utilizando el proceso definido.

Establecer el entorno de trabajo para el trabajo siguiendo los

estándares de entorno de trabajo de la organización.

Establecer equipos a los que asignar las tareas para acometer los

objetivos del trabajo.

Utilizar y contribuir a los activos de proceso organizativos.

Posibilitar que, durante el trabajo, las inquietudes de las partes

interesadas relevantes se identifiquen, se tengan en cuenta y, cuando

sea apropiado, se aborden.

Asegurar que las partes interesadas relevantes (1) realizan sus tareas

de manera coordinada y oportuna; (2) abordan sus requisitos, planes,

objetivos, problemas, y riesgos; (3) cumplen sus compromisos; (4) e

identifican, siguen, y resuelven los problemas de coordinación.

El proceso definido e integrado que se adapta a partir del conjunto de

procesos estándar de la organización se denomina proceso definido para el

trabajo.

La gestión del esfuerzo, coste, plazos, personal, riesgos, y de otros

factores del trabajo está ligada a las tareas del proceso definido para el

trabajo. La implementación y gestión del proceso definido para el trabajo

habitualmente se describe en el plan de trabajo. Ciertas actividades

pueden estar cubiertas por otros planes que afecten al trabajo, tales como

el plan de aseguramiento de calidad, la estrategia de gestión de riesgos, y

el plan de gestión de configuración.

Puesto que el proceso definido para cada grupo de trabajo se adapta a

partir del conjunto de procesos estándar de la organización, habitualmente

hay poca variabilidad entre los grupos de trabajo, y los grupos de trabajo

pueden compartir fácilmente activos de proceso, datos, y lecciones

aprendidas.



Esta área de proceso también aborda la coordinación de todas las actividades asociadas

con el trabajo tales como:

Actividades de desarrollo (p. ej. desarrollo de requisitos, diseño, verificación).

Actividades de servicio (p. ej. prestación, atención a usuarios, operaciones, contacto

con clientes).

Actividades de adquisición (p. ej. licitación, monitorización del acuerdo, transición a

operaciones).

Actividades de soporte (p. ej. gestión de configuración, documentación, marketing,

capacitación).

Las interfaces e interacciones en el trabajo que se producen entre distintas

partes interesadas relevantes internas y externas se planifican y gestionan

para asegurar la calidad e integridad del esfuerzo global. Las partes

interesadas relevantes participan, según sea apropiado, en la definición del

proceso definido y el plan para hacer el trabajo. Se realizan periódicamente

revisiones e intercambios con las partes interesadas relevantes para

asegurar que los problemas de coordinación reciben atención apropiada, y

que todos los involucrados en el trabajo están apropiadamente al corriente

de la situación, los planes, y las actividades (véase la definición de “parte

interesada relevante” en el glosario). Al definir el proceso para el trabajo se

crean interfaces formales, según se necesite, para asegurar que haya una

coordinación y colaboración apropiadas.

Esta área de proceso es aplicable a cualquier estructura organizativa,

incluyendo grupos de trabajo estructurados como organizaciones lineales,

organizaciones matriciales, o equipos. La terminología debería

interpretarse apropiadamente según sea la estructura organizativa de la

que se trate.


Extensión SSD

Para más información sobre realizar revisiones entre pares, consúltese el

área de proceso Desarrollo del Sistema de Servicio.




Para más información sobre establecer y mantener un conjunto utilizable

de activos de proceso organizativos, estándares de entorno de trabajo, y

reglas y guías para equipos, consúltese el área de proceso Definición









SG 1 Utilizar el proceso definido para el trabajo

SP 1.1 Establecer el proceso definido

SP 1.2 Utilizar los activos de proceso organizativos para planificar los trabajos

SP 1.3 Establecer el entorno de trabajo

SP 1.4 Integrar los planes

SP 1.5 Gestionar el trabajo utilizando los planes integrados

SP 1.6 Establecer equipos

SP 1.7 Contribuir a los activos de proceso organizativos

SG 2 Coordinarse y colaborar con las partes interesadas relevantes

SP 2.1 Gestionar la Involucración de las Partes Interesadas

SP 2.2 Gestionar las Dependencias

SP 2.3 Resolver los Problemas de Coordinación


SG 1 Utilizar el proceso definido para el trabajo

El trabajo se lleva a cabo utilizando un proceso definido adaptado a partir del conjunto de procesos estándar de la organización.

El proceso definido para el trabajo incluye a aquellos procesos dentro del

conjunto de procesos estándar de la organización que aborden todos los

procesos necesarios para adquirir, desarrollar, mantener, o entregar el

producto.

SP 1.1 Establecer el proceso definido

Establecer y mantener el proceso definido desde el inicio y durante

el trabajo.

Para más información sobre establecer activos de proceso organizativos y

establecer el repositorio de mediciones de la organización, consúltese el


Para más información sobre desplegar activos de proceso organizativos y

desplegar procesos estándar, consúltese el área de proceso Enfoque

Organizativo en Procesos.

El proceso definido para el trabajo se compone de procesos definidos que

forman un ciclo de vida integrado y coherente.

El proceso definido para el trabajo debería cumplir los requisitos

contractuales, las necesidades operativas, las oportunidades, y las

restricciones. Se diseña con el fin de ajustarse lo mejor posible a las




Un proceso definido para el trabajo está basado en los siguientes factores:


Compromisos.

Necesidades y objetivos de procesos organizativos.

El conjunto de procesos estándar de la organización y las guías de

adaptación.

El entorno operativo.

El entorno de negocio.

El entorno de prestación de servicios.

Adicionalmente, la descripción del proceso definido debería estar basada

en los servicios que el grupo de trabajo va a prestar, incluyendo tanto a los

servicios estándar que han sido adaptados, como a los servicios que son

únicos.

Establecer un proceso definido al inicio del trabajo ayuda a asegurar que el

personal y las partes interesadas relevantes implementan el conjunto de

actividades que son necesarias para establecer el conjunto inicial de

requisitos y planes para el trabajo de forma eficiente. A medida que

progresa el trabajo, la descripción del proceso definido se elabora y

actualiza para cumplir mejor los requisitos del servicio y las necesidades y

objetivos de procesos de la organización. Asimismo, a medida que el

conjunto de procesos estándar de la organización cambia puede que sea

necesario actualizar el proceso definido.


1. El proceso definido para el trabajo.

Subprácticas

1. Seleccionar un modelo de ciclo de vida de entre los disponibles en los

activos de proceso organizativos.

Algunos ejemplos de características del trabajo que podrían afectar a la selección de modelos de ciclo de vida son:

Tamaño o complejidad del trabajo.

Estrategia del trabajo.

Experiencia y familiaridad del personal con la implementación del proceso.

Restricciones tales como el nivel de servicio y el tiempo de ciclo.

Claridad de los requisitos.

Expectativas del cliente.

2. Seleccionar de entre el conjunto de procesos estándar de la

organización los procesos estándar que mejor se ajusten a las


Las organizaciones que definen servicios estándar usualmente tendrán sistemas de

servicio estándar que posibilitan la prestación de dichos servicios. Cualquier proceso

que forme parte de un sistema (o sistemas) de servicio relevante de la organización



es un buen candidato a ser tenido en cuenta al seleccionar los procesos estándar

para la prestación de servicios.

3. Siguiendo las guías de adaptación, adaptar el conjunto de procesos

estándar de la organización y otros activos de proceso organizativos

para producir el proceso definido para el trabajo.

A veces, los modelos de ciclo de vida y los procesos estándar disponibles no son

adecuados para un trabajo concreto. En esas circunstancias, el grupo de trabajo

debería pedir la aprobación para desviarse de lo que la organización requiere. Las

excepciones se proporcionan con este fin.

Puede que parte de la adaptación sea ajustar el conjunto de medidas comunes y

especificar medidas adicionales para cubrir las necesidades de información del grupo

de trabajo.

4. Utilizar otros artefactos de la biblioteca de activos de proceso de la

organización según sea apropiado.

Los otros artefactos pueden ser:

Documentos de lecciones aprendidas.

Plantillas.

Documentos de ejemplo.

Modelos de estimación.

5. Documentar el proceso definido para el trabajo.

El proceso definido para el trabajo cubre todas las actividades de establecimiento y

prestación de servicios del trabajo y sus interfaces con las partes interesadas

relevantes.

Algunos ejemplos de actividades de un trabajo son:

Planificación.

Monitorización.

Gestión de suministradores.

Aseguramiento de calidad.

Gestión de riesgos.

Análisis de decisiones y resolución.

Gestión de requisitos.

Gestión de incidencias.

Desarrollo y soporte del sistema de servicio.

6. Realizar revisiones entre pares del proceso definido para el trabajo.

Extensión SSD

Para más información sobre realizar revisiones entre pares, consúltese


7. Actualizar el proceso definido para el trabajo según se necesite.



SP 1.2 Utilizar los activos de proceso organizativos para planificar los trabajos

Utilizar los activos de proceso organizativos y el repositorio de

mediciones para estimar y planificar los trabajos.



Si hay resultados de actividades previas de planificación y ejecución

disponibles, utilizarlos para predecir el alcance relativo y los riesgos de la

labor que se está estimando.


1. Estimaciones del trabajo.

2. Planes de trabajo.

Subprácticas

1. Utilizar las tareas y productos de trabajo del proceso definido para el

trabajo como base para estimar y planificar los trabajos.

Una base para desarrollar un plan realista es entender las relaciones que existen

entre las tareas y los productos de trabajo del proceso definido para el trabajo, y entre

los roles que las partes interesadas relevantes tienen que realizar.

2. Utilizar el repositorio de mediciones de la organización para estimar

los parámetros de planificación del trabajo.

Esta estimación habitualmente incluye:

Datos históricos apropiados de este trabajo o de trabajos similares.

Similitudes y diferencias entre el trabajo actual y los trabajos cuyos datos históricos se van a utilizar.

Datos históricos validados.

Razonamiento, supuestos, y justificación utilizados para seleccionar datos históricos.

Algunos ejemplos de parámetros que se tienen en cuenta por sus similitudes y diferencias son:

Atributos de productos de trabajo y tareas.


Sistema de servicio y componentes de sistema de servicio.

Entorno de operaciones o entorno de prestación de servicios.

Experiencia de las personas.



Algunos ejemplos de datos contenidos en el repositorio de mediciones de la organización son:

Tamaño de los productos de trabajo u otros atributos de los productos de trabajo.

Esfuerzo.

Coste.

Plazos.

Dotación de personal.

Tiempo de respuesta.

Capacidad del servicio.

Desempeño de los suministradores.

Calidad.

SP 1.3 Establecer el entorno de trabajo

Establecer y mantener el entorno de trabajo en base a los

estándares de entorno de trabajo de la organización.

El entorno de trabajo apropiado para un trabajo comprende la

infraestructura de instalaciones, herramientas, y equipo que la gente

necesita para realizar sus tareas eficientemente con el fin dar soporte a los

objetivos de negocio y del servicio. El entorno de trabajo estándar y sus

componentes se mantienen dentro de los niveles de rendimiento y

fiabilidad de entorno de trabajo que se indican en los estándares de

entorno de trabajo de la organización. Según se necesite, el entorno de

trabajo o alguno de sus componentes puede desarrollarse internamente o

adquirirse a fuentes externas.

El entorno de trabajo debería abarcar todos los espacios en los que opere

el grupo de trabajo. Este entorno de trabajo incluye los espacios de trabajo

que no están bajo el control directo o la propiedad de la organización (p. ej.

entregar productos o prestar servicios en las instalaciones del cliente).

Extensión SSD La verificación y validación del sistema de servicio puede incluir tanto la

evaluación inicial como la evaluación continua del entorno de trabajo en el que

se prestan los servicios.

Para más información sobre preparar la verificación y validación,


Para más información sobre establecer estándares de entorno de trabajo,

consúltese la práctica específica Establecer estándares de entorno de

trabajo en el área de proceso Definición Organizativa de Procesos.


1. Equipamientos y herramientas para el trabajo.

2. Manuales de instalación, operación, y mantenimiento del entorno de

trabajo.

3. Encuestas a usuarios y sus resultados.



4. Registros de uso, rendimiento, y mantenimiento.

5. Servicios de soporte al entorno de trabajo.

Subprácticas

1. Planificar, diseñar, e instalar el entorno de trabajo.

Como en cualquier otro producto, los aspectos críticos del entorno de trabajo están

dirigidos por los requisitos. La funcionalidad y los atributos de calidad del entorno de

trabajo se exploran con el mismo rigor que si se tratase de cualquier otro proyecto de

desarrollo de productos.

Puede que sea necesario realizar compromisos entre atributos de calidad, costes, y riesgos. Son ejemplos de cada uno:

Las consideraciones sobre atributos de calidad pueden incluir la comunicación oportuna, la seguridad, la protección, y la mantenibilidad.

Los costes pueden incluir las inversiones de capital, la capacitación, una estructura de soporte; el desmantelamiento y eliminación de entornos existentes; y la operación y mantenimiento del entorno.

Los riesgos pueden incluir las alteraciones en el flujo de trabajo.

Algunos ejemplos de equipos y herramientas son:

Software ofimático.

Software de soporte a la toma de decisiones.

Herramientas de gestión de proyectos.

Herramientas de gestión de servicios.

Herramientas de gestión de requisitos.

Herramientas de gestión de incidencias y peticiones.

Equipamiento de pruebas y de evaluación.

2. Proporcionar mantenimiento y soporte operativo continuos al entorno

de trabajo.

El mantenimiento y soporte al entorno de trabajo puede ser realizado por

competencias de dentro de la organización o contratadas fuera de la misma.

Algunos ejemplos de enfoques de mantenimiento y soporte son:

Contratar a personas para realizar mantenimiento y soporte.

Capacitar a personas para realizar mantenimiento y soporte.

Subcontratar el mantenimiento y el soporte.

Convertir a usuarios en expertos de las herramientas seleccionadas.

3. Mantener la calificación de los componentes del entorno de trabajo.

Los componentes incluyen a los que se necesitan para dar soporte a la prestación de

servicios, el software, las bases de datos, el hardware, las herramientas, los equipos

de pruebas, y la documentación apropiada. La calificación de un entorno de

prestación de servicios incluye auditar el cumplimiento de los requisitos y normativas

de seguridad del entorno y sus componentes. La calificación del software incluye las

certificaciones apropiadas. La calificación del hardware y de los equipos de pruebas



incluye los registros de calibración y ajuste y la trazabilidad a los estándares de

calibración.

4. Revisar periódicamente el grado en el que el entorno de trabajo cubre

las necesidades de los trabajos y da soporte a la colaboración, y

actuar según sea apropiado.

Algunos ejemplos de acciones que podrían realizarse son:

Añadir nuevas herramientas.

Adquirir redes, equipos, capacitación, y soporte adicionales.

SP 1.4 Integrar los planes

Integrar el plan de trabajo con otros planes que afecten al trabajo

para describir el proceso definido para el trabajo.

Para más información sobre preparar la gestión de capacidad y


Disponibilidad.

Para más información sobre preparar la resolución y prevención de

incidencias, consúltese el área de proceso Resolución y Prevención de

Incidencias.

Para más información sobre establecer planes de continuidad del servicio,

consúltese el área de proceso Continuidad del Servicio.

Para más información sobre establecer activos de proceso organizativos, y

concretamente el repositorio de mediciones de la organización, consúltese

el área de proceso Definición Organizativa de Procesos.

Para más información sobre establecer necesidades organizativas de

procesos y determinar oportunidades de mejora de procesos, consúltese el

área de proceso Enfoque Organizativo en Procesos.



Esta práctica específica amplía las prácticas específicas sobre establecer y

mantener el plan de trabajo con objeto de abordar actividades de

planificación adicionales, tales como constituir el proceso definido para el

trabajo, coordinarse con las partes interesadas relevantes, utilizar los

activos de proceso organizativos, incorporar los planes de las revisiones

entre pares, y establecer los criterios objetivos de entrada y salida para las

tareas.

El plan de trabajo debería incluir planes para el desarrollo del sistema de

servicio y para la prestación de servicios, según sea apropiado.

El desarrollo del plan de trabajo debería tener en cuenta las necesidades,

objetivos, y requisitos de la organización, los clientes, los suministradores,

y los usuarios finales, tanto actuales como previstos, según sea apropiado.


1. Planes integrados.



Subprácticas

1. Integrar en el plan de trabajo los otros planes que afecten al trabajo.

Algunos ejemplos de otros planes que afectan al plan de trabajo son:

Planes de aseguramiento de calidad.


Planes de verificación y validación.

Planes de transición a operaciones y soporte.

Planes de comunicación.

Estrategia de gestión de capacidad y disponibilidad.


Enfoque de gestión de incidencias.

2. Incorporar en el plan de trabajo las definiciones de las medidas y las

actividades de medición para gestionar el trabajo.

Algunos ejemplos de medidas que podrían incorporarse son:

Conjunto de medidas comunes de la organización.

Medidas adicionales específicas del trabajo.

Para más información sobre desarrollar y mantener una competencia

de medición que se use para dar soporte a las necesidades de

información de la gerencia, consúltese el área de proceso Medición y

Análisis.

3. Identificar y analizar los riesgos de interfaces entre productos y grupos

de trabajo.

Para más información sobre identificar y analizar riesgos, consúltese el

área de proceso Gestión de Riesgos.

Algunos ejemplos de riesgos de interfaces entre productos y grupos de trabajo son:

Descripciones de interfaz incompletas.

Falta de herramientas, suministradores, o equipos de pruebas.

Falta de componentes comerciales (COTS)

Interfaces inadecuadas o ineficaces entre equipos.

Interfaces inadecuadas entre productos y servicios.

4. Planificar las tareas en una secuencia que tenga en cuenta los

factores críticos del desarrollo y la prestación y los riesgos del trabajo.

Algunos ejemplos de factores considerados en la planificación incluyen:

Tamaño y complejidad de las tareas.

Necesidades del cliente y de los usuarios finales.

Disponibilidad de recursos críticos.

Disponibilidad de personal clave.



5. Incorporar los planes para realizar las revisiones entre pares de los

productos de trabajo del proceso definido para el trabajo.

Extensión SSD



6. Incorporar la capacitación que se necesita para realizar el proceso

definido para el trabajo a los planes de capacitación de los grupos de

trabajo.

Esta tarea habitualmente incluye negociar con el grupo de capacitación organizativo

qué soporte va a proporcionar.

7. Establecer criterios objetivos de entrada y salida para autorizar el inicio

y terminación de las tareas descritas en la estructura de

descomposición del trabajo (EDT).

Para más información sobre estimar el alcance del trabajo, consúltese


8. Asegurar que el plan de trabajo es apropiadamente compatible con los

planes de las partes interesadas relevantes.

Habitualmente se revisa la compatibilidad del plan y de los cambios al plan.

9. Identificar cómo se van a resolver los conflictos que surjan entre las

partes interesadas relevantes.

SP 1.5 Gestionar el trabajo utilizando los planes integrados

Gestionar el trabajo utilizando el plan de trabajo, los otros planes

que afectan al trabajo, y el proceso definido para el trabajo.




procesos, desplegar activos de proceso organizativos, y desplegar

procesos estándar, consúltese el área de proceso Enfoque Organizativo en

Procesos.








1. Productos de trabajo creados al realizar el proceso definido para el

trabajo.

2. Medidas recogidas (esto es, reales) y registros o informes de

situación.



3. Requisitos, planes, y compromisos actualizados.

4. Planes integrados.

Subprácticas

1. Implementar el proceso definido utilizando la biblioteca de activos de

proceso de la organización.

Habitualmente esta tarea incluye las siguientes actividades:

Incorporar al grupo de trabajo artefactos de la biblioteca de activos de proceso de la organización según sea apropiado.

Utilizar lecciones aprendidas de la biblioteca de activos de proceso de la organización para gestionar el trabajo.

2. Monitorizar y controlar las actividades del trabajo y los productos de

trabajo utilizando el proceso definido para el trabajo, el plan de trabajo,

y los otros planes que afectan al trabajo.

Habitualmente esta tarea incluye las siguientes actividades:

Utilizar los criterios definidos de entrada y salida para autorizar el inicio y la terminación de tareas.

Monitorizar las actividades que pudieran afectar significativamente a los valores reales de los parámetros de planificación del trabajo.

Seguir los parámetros de planificación del trabajo utilizando umbrales medibles que desencadenen la investigación y las acciones apropiadas.

Monitorizar los riesgos de las interfaces entre grupos de trabajo.

Gestionar los compromisos internos y externos en base a los planes de las tareas y los productos de trabajo del proceso definido para el trabajo.

Se logra mayor visibilidad sobre el rendimiento y mejor control del trabajo si se

comprenden las relaciones entre las tareas y los productos de trabajo del proceso

definido para el trabajo y los roles que las partes interesadas relevantes desempeñan,

y si se dispone de mecanismos de control bien definidos (p. ej. revisiones entre

pares).

3. Obtener y analizar las mediciones seleccionadas para gestionar el

trabajo y dar soporte a las necesidades de la organización

Para más información sobre obtener y analizar datos de mediciones,


4. Revisar y alinear periódicamente el rendimiento del servicio con las

necesidades, objetivos, y requisitos actuales y previstos de la

organización, el cliente, y los usuarios finales, según sea apropiado.

Esta revisión incluye el alineamiento con las necesidades y objetivos de procesos

organizativos.



Algunos ejemplos de acciones para lograr el alineamiento son:

Cambiar el cronograma y ajustar apropiadamente otros parámetros de planificación y riesgos del trabajo.

Cambiar los requisitos o los compromisos como respuesta a cambios en las oportunidades del mercado o en las necesidades del cliente y los usuarios finales.

Poner fin al trabajo.

5. Abordar las causas de los problemas seleccionados que puedan

afectar a los objetivos del trabajo.

Los problemas que requieren acciones correctivas se determinan y analizan como se

describe en la práctica específica Analizar problemas y realizar acciones correctivas

del área de proceso Monitorización y Control de Trabajos. Según sea apropiado, el

grupo de trabajo puede revisar periódicamente los problemas encontrados en otros

trabajos o en fases previas del trabajo, y realizar análisis causales de problemas

seleccionados para determinar cómo evitar la recurrencia de problemas que puedan

afectar significativamente a los objetivos del trabajo. Debería evaluarse la eficacia de

los cambios a los procesos que se implementen como resultado de las actividades del

análisis causal para asegurar que dichos cambios han evitado la recurrencia y han

mejorado el rendimiento.

SP 1.6 Establecer equipos

Establecer y mantener equipos.

El grupo de trabajo se gestiona utilizando equipos que reflejan las reglas y

guías de la organización para estructurar, constituir, y operar equipos

(véase la definición de “equipo” en el glosario).

La visión compartida del grupo de trabajo se establece antes de que se

establezca la estructura del equipo, la cual puede estar basada en la EDT.

En organizaciones pequeñas, la organización completa y las partes

interesadas relevantes externas pueden ser tratadas como un equipo.

Para más información sobre establecer y mantener reglas y guías

organizativas para estructurar, constituir, y operar equipos, consúltese la

práctica específica Establecer reglas y guías para los equipos en el área de

proceso Definición Organizativa de Procesos.

Incluir a las partes interesadas relevantes en un equipo es una de las

mejores formas de asegurar que haya coordinación y colaboración.

Cuando el grupo de trabajo sea proveedor de un servicio, un equipo podría

ser responsable del desarrollo y mantenimiento global del servicio, y otro

de la prestación del servicio. En caso de varios servicios críticos en que

cada servicio requiera un conjunto de habilidades, el personal asociado con

cada servicio puede constituir su propio equipo con objeto de asegurar que

la prestación de dicho servicio sea exitosa y continua (o que se responda a

las peticiones ocasionales o se resuelvan las incidencias de manera

oportuna según sea apropiado).

En un entorno de cliente que requiera la coordinación entre varias

organizaciones de desarrollo de servicios o de prestación de servicios, es



importante establecer un equipo con representación de cada una de las

partes que afecten al éxito global. Este modelo ayuda a asegurar que la

colaboración entre organizaciones sea eficaz, incluyendo que la resolución

de problemas de coordinación sea oportuna.


1. Visión compartida documentada.

2. Lista de miembros asignados a cada equipo.

3. Estatutos de los equipos.

4. Informes de situación periódicos de los equipos.

Subprácticas

1. Establecer y mantener la visión compartida del grupo de trabajo.

Al crear la visión compartida, es crítico entender las interfaces entre el grupo de

trabajo y las partes interesadas externas al grupo de trabajo. La visión debería

compartirse con las partes interesadas relevantes para conseguir su acuerdo y su

compromiso.

2. Establecer y mantener la estructura del equipo.

La EDT, los costes, los plazos, los riesgos del trabajo, los recursos, las interfaces, el

proceso definido para el trabajo, y las guías organizativas son evaluadas con objeto

de establecer una estructura de equipo apropiada, que incluya responsabilidades,

autoridades, e interrelaciones en el equipo.

3. Establecer y mantener cada equipo.

Establecer y mantener equipos engloba elegir en cada equipo los líderes y miembros

del equipo y establecer los estatutos del equipo. También engloba proporcionar los

recursos necesarios para acometer las tareas asignadas al equipo.

4. Evaluar periódicamente la estructura y composición del equipo.

Los equipos deberían monitorizarse para detectar si hay falta de alineación entre

distintos equipos, gestión incorrecta de interfaces, o asignación incorrecta de tareas a

los miembros del equipo. Realizar acciones correctivas cuando el desempeño del

equipo no cumpla las expectativas.

SP 1.7 Contribuir a los activos de proceso organizativos

Contribuir a los activos de proceso organizativos con experiencias

relacionadas con procesos.

Para más información sobre establecer activos de proceso organizativos, el

repositorio de mediciones de la organización, y la biblioteca de activos de

proceso de la organización, consúltese el área de proceso Definición


Para más información sobre incorporar experiencias a los activos de

proceso organizativos, consúltese el área de proceso Enfoque Organizativo

en Procesos.



Esta práctica específica aborda la contribución a los activos de proceso

organizativos con información procedente de los procesos del proceso

definido para el trabajo.


1. Mejoras propuestas a los activos de proceso organizativos.

2. Medidas reales de procesos y productos recogidas al realizar el

trabajo.

3. Documentación (p. ej. descripciones de proceso ilustrativas, planes,

módulos de capacitación, listas de comprobación, lecciones

aprendidas).

4. Artefactos de proceso asociados con la adaptación e implementación

para el trabajo del conjunto de procesos estándar de la organización.

Subprácticas

1. Proponer mejoras a los activos de proceso organizativos.

2. Almacenar medidas de proceso y de producto en el repositorio de


Para más información sobre obtener datos de mediciones, consúltese

el área de proceso Medición y Análisis.

Para más información sobre monitorizar los parámetros del plan de

trabajo, consúltese el área de proceso Monitorización y Control de

Trabajos.

Para más información sobre planificar la gestión de datos, consúltese


Estas medidas de proceso y de producto habitualmente incluyen:

Datos de planificación.

Datos de replanificación.

Algunos ejemplos de datos registrados por el grupo de trabajo son:

Descripciones de tareas.

Supuestos.

Estimaciones.

Estimaciones actualizadas.

Definiciones de datos y medidas registrados.

Medidas.

Información de contexto que relacione las medidas con las actividades realizadas y con los productos de trabajo producidos.

Información asociada necesaria para reconstruir las estimaciones, evaluar si son razonables, y derivar estimaciones para nuevos trabajos.

3. Enviar la documentación para su posible inclusión en la biblioteca de

activos de proceso de la organización.



Algunos ejemplos de documentación son:

Descripciones de proceso ilustrativas.

Módulos de capacitación.

Planes ilustrativos.

Listas de comprobación y plantillas

Configuraciones de herramientas.

4. Documentar las lecciones aprendidas durante el trabajo para su

inclusión en la biblioteca de activos de proceso de la organización.

5. Proporcionar artefactos de proceso asociados a la adaptación e

implementación del conjunto de procesos estándar de la organización

para dar soporte a las actividades de monitorización de procesos de la

organización.

Para más información sobre las actividades que la organización realiza

para conocer el grado en que los grupos de trabajo nuevos y

existentes han desplegado los procesos estándar, consúltese la

práctica específica Monitorizar la implementación en el área de

proceso Enfoque Organizativo en Procesos.

SG 2 Coordinarse y colaborar con las partes interesadas relevantes

Se lleva a cabo la coordinación y colaboración entre las partes interesadas relevantes.

SP 2.1 Gestionar la involucración de las partes interesadas

Gestionar la involucración con el trabajo de las partes interesadas

relevantes.

La involucración de las partes interesadas relevantes se gestiona conforme

al plan integrado y al proceso definido para el trabajo.

El acuerdo de suministro proporciona la base para gestionar la

involucración con el trabajo del suministrador. Los acuerdos de suministro

(p. ej. acuerdos entre agencias y entre compañías, memorandos de

entendimiento, memorandos de acuerdo) que el grupo de trabajo establece

con otras organizaciones interesadas, que pueden ser proveedoras o

receptoras de productos o servicios, proporcionan la base para su

involucración.

Estos acuerdos son particularmente importantes cuando los servicios

prestados por el grupo de trabajo se integran en un contexto de prestación

de servicios más amplio.

Para más información sobre planificar la involucración de las partes

interesadas y obtener el compromiso con el plan, consúltese el área de

proceso Planificación de Trabajos.


1. Agendas y cronogramas de las actividades de colaboración.



2. Recomendaciones para resolver problemas con las partes interesadas

relevantes.

3. Problemas documentados (p. ej. problemas con las partes interesadas

y los requisitos, arquitectura, y diseño del sistema de servicio).

Subprácticas

1. Coordinarse con las partes interesadas relevantes que deben

participar en las actividades del trabajo.

Las partes interesadas relevantes ya deberían estar identificadas en el plan de

trabajo.

2. Asegurar que los productos de trabajo que se producen para satisfacer

los compromisos cumplen con los requisitos de los receptores.

Extensión SSD

Para más información sobre verificar y validar el sistema de servicio,


Los productos de trabajo que se producen para satisfacer los compromisos pueden

ser servicios.

Esta tarea habitualmente incluye:

Revisar, demostrar, o probar, según sea apropiado, cada producto de trabajo producido por las partes interesadas relevantes.

Revisar, demostrar, o probar, según sea apropiado, cada producto de trabajo producido por el grupo de trabajo para otros grupos de trabajo con representantes de los grupos de trabajo que lo reciben.

Resolver problemas relacionados con la aceptación de productos de trabajo.

3. Desarrollar recomendaciones y coordinar acciones para resolver

malentendidos y problemas con los requisitos.

SP 2.2 Gestionar las dependencias

Participar con las partes interesadas relevantes en identificar,

negociar, y seguir las dependencias críticas.


1. Defectos, problemas, y acciones resultantes de las revisiones con las


2. Dependencias críticas.

3. Compromisos para abordar las dependencias críticas.

4. Estado de las dependencias críticas.

Subprácticas

1. Realizar revisiones con las partes interesadas relevantes.

2. Identificar cada dependencia crítica.



3. Establecer para cada dependencia crítica la fecha en que se necesita

y la fecha planificada en base al cronograma del trabajo.

4. Revisar y acordar los compromisos para abordar cada dependencia

crítica con los responsables de proporcionar o recibir los productos de

trabajo o de realizar o recibir los servicios.

5. Documentar las dependencias críticas y los compromisos.

La documentación de compromisos habitualmente incluye:

Describir el compromiso.

Identificar quién se comprometió.

Identificar quién es responsable de satisfacer el compromiso.

Especificar cuándo se satisfará el compromiso.

Especificar los criterios que determinan si se ha satisfecho el compromiso.

6. Seguir las dependencias críticas y los compromisos y realizar acciones

correctivas según sea apropiado.

Para más información sobre monitorizar compromisos, consúltese el

área de proceso Monitorización y Control de Trabajos.

El seguimiento de dependencias críticas habitualmente incluye:

Evaluar el efecto que tendría completar tardía o tempranamente por su impacto sobre futuras actividades e hitos.

Siempre que sea posible, resolver problemas reales y potenciales con quienes sean responsables.

Escalar a quien sea apropiado los problemas reales y potenciales que no puedan resolverse por el individuo o grupo responsable.

SP 2.3 Resolver los problemas de coordinación

Resolver los problemas con las partes interesadas relevantes.

Algunos ejemplos de problemas de coordinación son:

Defectos en los requisitos y el diseño del sistema de servicio.

Dependencias críticas y compromisos con retraso.

Problemas a nivel de producto.

Falta de disponibilidad de recursos o personal críticos.


1. Problemas de coordinación con las partes interesadas relevantes.

2. Estado de los problemas de coordinación con las partes interesadas

relevantes.

Subprácticas

1. Identificar y documentar problemas.

2. Comunicar los problemas a las partes interesadas relevantes.



3. Resolver los problemas con las partes interesadas relevantes.

4. Escalar a los gerentes apropiados los problemas que no puedan

resolverse con las partes interesadas relevantes.

5. Seguir los problemas hasta su cierre.

6. Comunicarse con las partes interesadas relevantes acerca del estado

y la resolución de los problemas.


Medición y Análisis (MA) 215

MEDICIÓN Y ANÁLISIS


Propósito

El propósito de Medición y Análisis (MA) es desarrollar y mantener una

competencia de medición que se usa para dar soporte a las necesidades

de información de la gerencia.


El área de proceso Medición y Análisis engloba las siguientes actividades:

Especificar los objetivos de medición y análisis para alinearlos con las

necesidades de información y con los objetivos del trabajo, de la

organización, o del negocio.

Especificar medidas, técnicas de análisis, y mecanismos para recoger

datos, almacenarlos, difundirlos, y realimentar.

Implementar las técnicas de análisis y los mecanismos para recoger

datos, difundirlos, y realimentar.

Proporcionar resultados objetivos que puedan utilizarse para tomar

decisiones bien fundadas y para realizar las acciones correctivas

apropiadas.

Integrar las actividades de medición y análisis en los procesos del trabajo

da soporte a:

Planificar y estimar objetivamente.

Seguir el progreso y el rendimiento reales frente a los planes y

objetivos establecidos.

Identificar y resolver problemas relacionados con el proceso.

Proporcionar una base para incorporar en el futuro la medición en

procesos adicionales.

El personal requerido para implementar la competencia de medición puede

o no estar vinculado a un programa separado de la organización. La

competencia de medición puede estar integrada en grupos de trabajo

individuales o en otras funciones de la organización (p. ej., aseguramiento

de calidad).

El foco inicial de las actividades de medición es el nivel de grupo de

trabajo. Sin embargo, la competencia de medición puede demostrarse útil

para abordar las necesidades de información de la organización y de toda

la empresa. Para minimizar que se rehaga el trabajo a medida que la

organización madura, las actividades de medición soportadas por esta

capacidad deberían dar soporte a las necesidades de información de



múltiples niveles, incluyendo el de negocio, el de unidad organizativa, y el

de grupo de trabajo.

Los grupos de trabajo pueden almacenar datos y resultados específicos del

trabajo en un repositorio específico del grupo de trabajo, pero cuando los

datos se vayan a utilizar ampliamente o se vayan a analizar para

determinar tendencias o hacer comparativas, éstos se pueden ubicar en el

repositorio de mediciones de la organización.

Para gestionar eficazmente la calidad y los costes del trabajo es

fundamental medir y analizar los componentes de producto proporcionados

por los suministradores. Es posible que, mediante una gestión cuidadosa

de los acuerdos de suministro, a partir de los datos se obtenga

conocimiento que ayude a analizar el desempeño de los suministradores.

Los objetivos de medición se derivan de las necesidades de información

que provienen de los objetivos del trabajo, la organización, o el negocio. En

éste área de proceso, cuando se utiliza el término “objetivos” sin el

calificador “de medición”, se está refiriendo a los objetivos del trabajo, de la

organización, o del negocio.


Extensión SSD

Para más información sobre desarrollar y analizar los requisitos de las

partes interesadas, consúltese el área de proceso Desarrollo del Sistema

de Servicio.

Para más información sobre establecer y mantener la integridad de los

productos de trabajo por medio de identificar la configuración, controlar la

configuración, registrar el estado de la configuración, y las auditorías de


Para más información sobre establecer el repositorio de mediciones de la

organización, consúltese el área de proceso Definición Organizativa de

Procesos.

Para más información sobre gestionar el trabajo cuantitativamente para



Para más información sobre monitorizar los parámetros del plan de trabajo,


Para más información sobre establecer estimaciones, consúltese el área de




Resumen de metas y prácticas específicas

SG 1 Alinear las actividades de medición y análisis

SP 1.1 Establecer objetivos de medición

SP 1.2 Especificar medidas

SP 1.3 Especificar procedimientos de recogida y almacenamiento de datos

SP 1.4 Establecer procedimientos de análisis

SG 2 Proporcionar resultados de medición

SP 2.1 Obtener mediciones

SP 2.2 Analizar mediciones

SP 2.3 Almacenar los datos y los resultados

SP 2.4 Comunicar los resultados


SG 1 Alinear las actividades de medición y análisis

Los objetivos de medición y actividades de medición se alinean con las necesidades de información y objetivos identificados.

Las prácticas específicas de esta meta específica pueden abordarse de

forma simultánea o en cualquier orden.

Cuando se establecen objetivos de medición, los expertos a menudo

prevén cuáles serán los criterios necesarios para especificar las medidas y

los procedimientos de análisis. También consideran simultáneamente las

restricciones impuestas por los procedimientos de recogida y

almacenamiento de datos.

Con frecuencia es importante especificar los análisis esenciales a llevar a

cabo antes de ocuparse de los detalles de la especificación de mediciones,

la recogida de datos, o el almacenamiento.

SP 1.1 Establecer objetivos de medición

Establecer y mantener objetivos de medición derivados de las

necesidades de información y objetivos identificados.

Los objetivos de medición documentan los fines para los que se realizan la

medición y análisis, y especifican los tipos de acciones que se pueden

llevar a cabo en base a los resultados de los análisis de datos. Los

objetivos de medición también pueden identificar el cambio que se desea

en el comportamiento como resultado de implementar una actividad de

medición y análisis.

Los objetivos de medición pueden estar limitados por los procesos

existentes, los recursos disponibles, o por otras consideraciones de

medición. Puede que haga falta sopesar si el valor del resultado es

proporcional a los recursos empleados en hacer el trabajo.

Las modificaciones a las necesidades de información y objetivos

identificados pueden, a su vez, ser consecuencia del proceso y los

resultados de la medición y análisis.



Algunas fuentes de necesidades de información y objetivos son:

Incidencias recurrentes o complejas.

Planes de trabajo.

Monitorización del rendimiento del trabajo.

Entrevistas a gerentes y otras personas que tengan necesidades de información.

Objetivos de gestión establecidos.

Planes estratégicos.

Planes de negocio.

Requisitos formales u obligaciones contractuales.

Problemas de gestión o técnicos recurrentes o complejos.

Experiencias de otros grupos de trabajo o entidades organizativas.

Comparativas con empresas del sector.

Planes de mejora de procesos.

Algunos ejemplos de objetivos de medición son:

Proporcionar visibilidad sobre las fluctuaciones en los plazos y el progreso.

Proporcionar visibilidad sobre el tamaño real comparado con el planeado.

Identificar crecimientos no planeados.

Evaluar la eficacia de la detección de defectos durante el ciclo de vida de desarrollo del

producto.

Determinar el coste de corregir los defectos.

Proporcionar visibilidad sobre los costes reales comparados con los planeados.

Evaluar el progreso de los suministradores con respecto al plan.

Evaluar la eficacia al mitigar vulnerabilidades en el sistema de información.

Extensión SSD



de Servicio.

Para más información sobre mantener la trazabilidad bidireccional entre los

requisitos, consúltese el área de proceso Gestión de Requisitos.

Para más información sobre monitorizar los parámetros del plan de trabajo,


Para más información sobre establecer estimaciones, consúltese el área de



1. Objetivos de medición.

Subprácticas

1. Documentar las necesidades de información y los objetivos.



2. Priorizar las necesidades de información y los objetivos.

Puede que no sea ni posible ni deseable someter a medición y análisis todas las

necesidades de información identificadas inicialmente. También puede que sea

necesario establecer prioridades teniendo en cuenta la limitación de recursos

disponibles.

3. Documentar, revisar, y actualizar los objetivos de medición.

Considere minuciosamente los propósitos y usos proyectados de la medición y

análisis.

Los objetivos de medición se documentan, se revisan por la gerencia y otras partes

interesadas relevantes, y se actualizan según se necesite. Todo esto posibilita la

trazabilidad con las actividades de medición y análisis subsiguientes, y ayuda a

asegurar que los análisis abordarán adecuadamente las necesidades de información y

los objetivos identificados.

Es importante que los usuarios de los resultados de la medición y análisis estén

involucrados en el establecimiento de los objetivos de medición y en la decisión sobre

planes de acción. También puede ser apropiado involucrar a quienes proporcionan los

datos de medición.

4. Proporcionar realimentación para refinar y clarificar las necesidades de

información y los objetivos según se necesite.

Las necesidades de información y los objetivos identificados pueden refinarse y

clarificarse como resultado de establecer los objetivos de medición. Las descripciones

iniciales de necesidades de información pueden ser ambiguas. Pueden surgir

conflictos entre las necesidades y los objetivos existentes. Los valores concretos

establecidos para una medida existente pueden no ser realistas.

5. Mantener la trazabilidad entre los objetivos de medición y las

necesidades de información y los objetivos identificados.

Siempre debería haber una buena respuesta a la pregunta, “¿por qué estamos

midiendo esto?”

Evidentemente, los objetivos de medición también pueden cambiar para reflejar la

evolución de las necesidades de información y los objetivos.

SP 1.2 Especificar medidas

Especificar medidas para abordar los objetivos de medición.

Los objetivos de medición se traducen en medidas precisas y

cuantificables.

La medición del trabajo habitualmente se puede trazar hasta una o varias

categorías de la información medida. Estas categorías incluyen la

continuidad del servicio, la capacidad, la disponibilidad, el rendimiento del

servicio, y la calidad del servicio.

Las medidas pueden ser de tipo base o derivada. Los datos para las

medidas base se obtienen por medición directa. Los datos para las

medidas derivadas provienen de otros datos, habitualmente combinando

dos o más medidas base.



Algunos ejemplos de medidas base de uso común son:

Estimaciones y medidas reales de los tamaños de los productos de trabajo (p. ej.,

número de páginas).

Estimaciones y medidas reales del esfuerzo y el coste (p. ej., número de horas

persona).

Medidas de calidad (p.ej. número de defectos por gravedad).

Medidas de seguridad de la información (p. ej. número de vulnerabilidades

identificadas en el sistema).

Calificaciones en las encuestas de satisfacción de clientes.

Algunos ejemplos de medidas derivadas de uso común son:

Valor realizado.

Índice de rendimiento en plazos.

Densidad de defectos.

Cobertura de revisiones entre pares.

Cobertura de pruebas o de verificación.

Medidas de fiabilidad (p. ej. tiempo medio entre fallos).

Medidas de calidad (p. ej. número de defectos por gravedad / número total de

defectos).

Medidas de seguridad de la información (p. ej. porcentaje de las vulnerabilidades del

sistema mitigadas).

Tendencias en la satisfacción de clientes.

Las medidas derivadas se expresan habitualmente por medio de ratios,

índices compuestos, u otras medidas agregadas de síntesis. A menudo son

más fiables desde el punto de vista cuantitativo y su interpretación es más

significativa que las medidas base utilizadas para generarlas.

Hay relaciones directas entre las necesidades de información, los objetivos

de medición, las categorías de medición, las medidas base, y las medidas

derivadas. Esta relación directa se representa en la Tabla MA. 1 por medio

de algunos ejemplos comunes para el trabajo de los servicios.



Tabla MA.1: Ejemplo de relaciones entre mediciones

Ejemplo de

objetivo de

trabajo,

organizativo, o

de negocio

Necesidad de

información

Objetivo de medición

Categoría de la

información

medida

Ejemplos de

medidas base

Ejemplos de

medidas

derivadas

Proporcionar la

continuidad del

servicio

acordada

¿Pueden recuperarse los servicios de los desastres o de

las grandes alteraciones dentro de los

plazos acordados?

Proporcionar visibilidad sobre si los planes de continuidad

del servicio se ejecutarán de forma

exitosa para proveer la continuidad del

servicio acordada

Continuidad del servicio

Número de servicios con pruebas de

recuperación fallidas

Número total de servicios en el

catálogo de servicios

Ratio de confianza en la continuidad del

servicio

Proporcionar

capacidad

apropiada para

cubrir las

necesidades de

negocio

Prevenir

incidencias

relacionadas

con la

capacidad

¿Hay suficientes recursos (o

demasiados) para cubrir la demanda de

servicios?

Proporcionar visibilidad sobre

utilización de recursos, recursos ociosos, y

capacidad inadecuada para cubrir la

demanda

Capacidad

Número total de peticiones de

servicio

Horas disponibles del

personal del proveedor de

servicios

Tiempo de servicio

Tiempo de servicio medio

Uso del personal del proveedor de

servicios

Proporcionar

servicios con

costes

eficientes

¿Se está proporcionando

un servicio competitivo

mediante una planificación de

capacidad precisa?

Proporcionar

visibilidad sobre los

gastos debidos a la

capacidad no

planificada

Capacidad

Gasto total

debido a la

capacidad no

planificada

Coste total de

los recursos

Porcentaje del

coste de los

recursos de

servicio

originado por

capacidad no

planificada

Mejorar el nivel

de calidad en el

servicio

¿Está mejorando el

nivel de calidad en el servicio?

Proporcionar

visibilidad sobre si la

calidad del servicio

que se está prestando

está mejorando por

medio de observar

cuántos errores se

repiten

Calidad del

servicio

Número total de

errores que se

repiten

Número total de

errores

Ratio de errores

que se repiten



Ejemplo de

Objetivos del

Trabajo, de la

Organización o

del Negocio

Necesidad de

Información

Objetivo de la

Medición

Categorías de

la Información

Medida

Ejemplo de

Medidas Base

Ejemplos de

Medidas

Derivadas

Proporcionar

servicios

eficaces

¿Cuál es la

eficacia de los

servicios?

Proporcionar

visibilidad sobre qué

porcentaje de

peticiones de servicio

se están rehaciendo

Rendimiento del

servicio

Número de

peticiones de

servicio

rehechas

Número total de

peticiones de

servicio

Ratio de

servicios

rehechos

Proporcionar la

apropiada

disponibilidad

de servicios

acordada

¿Se está

proporcionando

la apropiada

disponibilidad

de servicios

acordada?

Proporcionar

visibilidad sobre la

disponibilidad de los

servicios

Disponibilidad Tiempo de

servicio

acordado

Tiempo sin

servicio

Disponibilidad

¿Es el servicio

tan fiable como

se acordó?

Proporcionar

visibilidad sobre la

fiabilidad del servicio

Disponibilidad Tiempo

disponible (en

horas)

Total de tiempo

sin servicio (en

horas)

Número de

paradas en el

servicio (el

servicio normal

se interrumpe)

Fiabilidad como

tiempo medio

entre fallos

(MTBF)


1. Especificaciones de las medidas base y derivadas.

Subprácticas

1. Identificar medidas candidatas en base a los objetivos de medición

documentados.

Los objetivos de medición se traducen en medidas. Las medidas candidatas

identificadas se clasifican y especifican por nombre y unidad de medida.

2. Mantener la trazabilidad de las medidas con los objetivos de medición.



Se identifican las interdependencias entre las medidas candidatas para posibilitar la

validación posterior de los datos y los análisis candidatos que dan soporte a los

objetivos de medición.

3. Identificar medidas existentes que aborden actualmente los objetivos

de medición.

Puede que actualmente existan especificaciones para las medidas, quizás

establecidas anteriormente para otros propósitos o en alguna otra parte de la

organización.

4. Especificar definiciones operativas para las medidas.

Las definiciones operativas se establecen en términos precisos y sin ambigüedades.

Abordan dos criterios importantes:

Comunicación: ¿qué se ha medido?, ¿cómo fue medido?, ¿cuáles fueron las unidades de medida? y ¿qué está incluido o excluido?

Repetibilidad: a partir de la misma definición ¿se pueden obtener los mismos resultados al repetir la medición?

5. Priorizar, revisar, y actualizar las medidas.

Para determinar si son apropiadas, las especificaciones propuestas para las medidas

se revisan con los usuarios finales potenciales y con otras partes interesadas

relevantes. Las prioridades se establecen o se cambian, y las especificaciones de las

medidas se actualizan según se necesite.

SP 1.3 Especificar procedimientos de recogida y almacenamiento de datos

Especificar el modo de obtener y almacenar los datos de medición.

Especificar explícitamente los métodos de recogida ayuda a asegurar que

se recojan de forma apropiada los datos correctos. Esta especificación

también puede contribuir a clarificar más a fondo las necesidades de

información y los objetivos de medición.

Prestar la debida atención a los procedimientos de almacenamiento y de

recuperación ayuda a asegurar que los datos estén disponibles y

accesibles para su futuro uso.


1. Procedimientos de recogida y almacenamiento de datos.

2. Herramientas de recogida de datos.

Subprácticas

1. Identificar las fuentes de datos existentes que se generan a partir de

los productos de trabajo, procesos, o transacciones actuales.

Las fuentes de datos existentes pueden haberse identificado cuando se especificaron

las medidas. Pueden existir mecanismos de recogida apropiados con independencia

de que se hayan recogido o no los datos pertinentes.

2. Identificar las medidas para las que se necesitan datos que no se

encuentran disponibles en la actualidad.



3. Especificar el modo de recoger y almacenar los datos para cada

medida requerida.

Se especifica explícitamente qué, cómo, dónde, y cuándo se recogerán y

almacenarán los datos para asegurar que sean válidos y dar soporte a su posterior

uso encaminado a analizar y documentar.

Habitualmente algunas cuestiones a considerar son:

¿Se han determinado la frecuencia de recogida y los puntos en el proceso en los que se harán las mediciones?

¿Se han establecido los plazos que se requieren para trasladar los resultados de medición desde los puntos de recogida hasta los repositorios, las otras bases de datos, o los usuarios finales?

¿Quién es el responsable de obtener los datos?

¿Quién es el responsable del almacenamiento, recuperación, y seguridad de los datos?

¿Se han desarrollado o adquirido las herramientas de soporte necesarias?

4. Crear mecanismos de recogida de datos y guías de proceso.

Los mecanismos de recogida y almacenamiento de datos están bien integrados con

otros procesos de trabajo normal. Los mecanismos de recogida de datos pueden

incluir formularios y plantillas manuales o automatizados. Los responsables de realizar

el trabajo disponen de una orientación clara y concisa sobre los procedimientos

correctos. Se proporciona capacitación, según se necesite, para clarificar los procesos

requeridos de recogida completa y precisa de los datos y para minimizar la carga de

quienes proporcionan y registran los datos.

5. Dar soporte a la recogida automática de datos según sea apropiado y

factible.

Algunos ejemplos de este soporte automatizado son:

Registros de actividad con marcas temporales.

Análisis estático o dinámico de artefactos.

6. Priorizar, revisar, y actualizar los procedimientos de recogida y


Los procedimientos propuestos se revisan con las personas responsables de

proporcionar, recoger, y almacenar los datos para determinar si éstos son apropiados

y factibles, Estas personas también pueden tener puntos de vista útiles sobre el modo

de mejorar los procesos existentes, o ser capaces de sugerir otras medidas o análisis

útiles.

7. Actualizar las medidas y objetivos de medición según se necesite.

SP 1.4 Establecer procedimientos de análisis

Especificar el modo de analizar y comunicar los datos de

medición.

Especificar con antelación los procedimientos de análisis asegura que se

llevarán a cabo y se difundirán los análisis apropiados que abordan los



objetivos de medición documentados (y, por tanto, las necesidades de

información y los objetivos en los cuales se basan). Este enfoque también

sirve para comprobar que, de hecho, se recogerán los datos necesarios.

Los procedimientos de análisis deberían tener en cuenta la calidad (p. ej.,

vigencia, fiabilidad) de todos los datos que entren en un análisis (ya sea

desde el grupo de trabajo, desde el repositorio de mediciones de la

organización, o desde otra fuente). La calidad de los datos debería ser

tenida en cuenta para ayudar en la selección del procedimiento de análisis

apropiado y en la evaluación de los resultados de los análisis.


1. Especificaciones y procedimientos de análisis.

2. Herramientas de análisis de datos.

Subprácticas

1. Especificar y priorizar los análisis que se van a realizar y los informes

que se van a preparar.

Desde el principio, preste atención a los análisis que se van a realizar y a la manera

en que se informará sobre los resultados. Estos análisis e informes deberían cumplir

los siguientes criterios:

Los análisis abordan explícitamente los objetivos de medición documentados.

La presentación de los resultados es claramente entendible por las audiencias a las que van dirigidos.

Puede que sea necesario establecer prioridades para los recursos disponibles.

2. Seleccionar métodos y herramientas apropiados de análisis de datos.

Algunos problemas habituales a considerar son:

Elección de técnicas de presentación visual y otras técnicas de presentación (p. ej. diagramas de tarta, de barras, histogramas, diagramas de radar, gráficos de líneas, diagramas de dispersión, tablas).

Elección de estadísticos descriptivos apropiados (p. ej. media aritmética, mediana, moda).

Decisiones sobre los criterios de muestreo estadístico cuando sea imposible o innecesario examinar todos los datos.

Decisiones sobre cómo manejar el análisis en caso de que haya elementos de datos que falten.

Selección de herramientas de análisis apropiadas.

La estadística descriptiva se utiliza habitualmente en los análisis de datos para:

Examinar las distribuciones de las medidas especificadas (p. ej. tendencia central, grado de variación, puntos de datos que muestren una variación inusual).

Examinar las interrelaciones entre las medidas especificadas (p. ej. comparaciones de defectos por fase del ciclo de vida del producto, comparaciones de defectos por componente de producto).

Mostrar cambios a lo largo del tiempo.



Para más información sobre el modo apropiado de utilizar técnicas

estadísticas y de entender la variación, consúltense las prácticas

específicas Seleccionar medidas y técnicas de análisis y Monitorizar el

rendimiento de los subprocesos seleccionados en el área de proceso

Gestión Cuantitativa de Trabajos.

3. Especificar los procedimientos administrativos para analizar los datos

y comunicar los resultados.

Algunos problemas habituales a considerar son:

Identificar las personas y grupos responsables de analizar los datos y presentar los resultados.

Determinar los plazos para analizar los datos y presentar los resultados.

Determinar la forma de comunicar los resultados (p. ej., informes de progreso, circulares, informes escritos, reuniones con el personal).

4. Revisar y actualizar el contenido y formato propuestos de los análisis e

informes especificados.

Todo el contenido y formato propuestos está sujeto a revisión y corrección, incluyendo

los métodos y herramientas analíticas, los procedimientos administrativos, y las

prioridades. Las partes interesadas relevantes consultadas deberían incluir a usuarios

finales, patrocinadores, analistas de datos, y proveedores de datos.

5. Actualizar las medidas y objetivos de medición según se necesite.

De la misma forma en que las necesidades de medición dirigen los análisis de datos,

la clarificación de los criterios de análisis puede afectar a la medición. Las

especificaciones de algunas medidas pueden detallarse con mayor profundidad

partiendo de las especificaciones establecidas para los procedimientos de análisis de

datos. Es posible que otras medidas se demuestren innecesarias o que se reconozca

la necesidad de medidas adicionales.

Especificar el modo en que se analizarán y difundirán las medidas también puede

conducir a la necesidad de refinar los propios objetivos de medición.

6. Especificar los criterios para evaluar la utilidad de los resultados de los

análisis y para evaluar la ejecución de las actividades de medición y

análisis.

Los criterios para evaluar la utilidad de los análisis podrían abordar el grado en que:

Los resultados se proporcionan de manera oportuna, son inteligibles, y se utilizan para tomar decisiones.

No cuesta más realizar el trabajo que lo que justifica el beneficio que produce.



Los criterios para evaluar la ejecución de la medición y análisis podrían abordar el grado en que:

La cantidad de datos que faltan o el número de inconsistencias marcadas está por encima de los umbrales especificados.

Hay sesgo en la selección de la muestra (p. ej. para evaluar la satisfacción sólo se encuesta a usuarios finales satisfechos, para determinar la productividad global sólo se evalúan grupos de trabajo sin éxito)

Los datos de medición son repetibles (p. ej. estadísticamente fiables).

Se han satisfecho los supuestos estadísticos (p. ej. sobre la distribución de los datos, sobre si son apropiadas las escalas de medición).

SG 2 Proporcionar resultados de medición

Se proporcionan resultados de medición que abordan las necesidades de información y los objetivos identificados.

La razón principal para llevar a cabo la medición y análisis es abordar las

necesidades de información identificadas, derivadas de los objetivos del

trabajo, la organización, y el negocio. Los resultados de medición basados

en evidencias objetivas pueden ayudar a monitorizar el progreso y el

rendimiento, a satisfacer las obligaciones documentadas en acuerdos de

suministro, a tomar decisiones técnicas y de gestión bien fundadas, y a

hacer posible que se realicen acciones correctivas.

SP 2.1 Obtener mediciones

Obtener los datos de medición especificados.

Se obtienen los datos necesarios para el análisis y se comprueba que sean

completos e íntegros.


1. Conjuntos de datos de medición base y derivados.

2. Resultados de las pruebas de integridad de datos.

Subprácticas

1. Obtener datos para las medidas base.

Se recogen datos según se necesite para las medidas base utilizadas con anterioridad

y las medidas base recién especificadas. Los datos existentes se recogen de los

registros del trabajo o de cualquier otra parte de la organización.

2. Generar datos para medidas derivadas.

Se calculan nuevos valores para todas las medidas derivadas.

3. Realizar comprobaciones de integridad de datos tan cerca de la fuente

de los datos como sea posible.

Todas las mediciones están sujetas a errores al especificar o registrar los datos.

Siempre es mejor identificar dichos errores y las fuentes de los datos que falten lo

más pronto posible en el ciclo de medición y análisis.



Las comprobaciones pueden incluir búsquedas de datos que falten, valores de datos

fuera de límites, y patrones y correlaciones inusuales entre las medidas. Es

particularmente importante hacer lo siguiente:

Comprobar y corregir inconsistencias en clasificaciones hechas a juicio de personas (esto es, determinar con qué frecuencia se hacen clasificaciones diferentes a partir de la misma información, también llamada “fiabilidad entre codificadores”).

Examinar empíricamente las relaciones que existen entre las medidas que se utilizan para calcular medidas derivadas adicionales. Al hacer esto se puede asegurar que no se pasan por alto diferencias importantes y que las medidas derivadas expresan el significado que se desea (también llamada “validez de criterio”).

SP 2.2 Analizar mediciones

Analizar e interpretar datos de medición.

Se analizan datos de medición según lo planeado, se realizan análisis

adicionales según se necesite, se revisan los resultados con las partes

interesadas relevantes, y se toma nota de las actualizaciones necesarias

para análisis futuros.


1. Resultados de los análisis e informes preliminares.

Subprácticas

1. Llevar a cabo análisis iniciales, interpretar los resultados, y perfilar las

conclusiones preliminares.

Los resultados de los análisis de datos rara vez son evidentes. Se deberían establecer

explícitamente criterios para interpretar los resultados y perfilar las conclusiones.

2. Llevar a cabo mediciones y análisis adicionales según se necesite y

preparar los resultados para su presentación.

Los resultados de los análisis planeados pueden sugerir (o requerir) análisis

adicionales no previstos. Además, para completar adecuadamente los análisis

planeados, estos análisis pueden identificar la necesidad de detallar medidas

existentes, de calcular medidas derivadas adicionales, o incluso de recoger datos para

medidas base adicionales. Análogamente, la preparación de los resultados iniciales

para su presentación puede identificar la necesidad de análisis adicionales no

previstos.

3. Revisar los resultados iniciales con las partes interesadas relevantes.

Antes de diseminarlos y comunicarlos ampliamente, puede que sea apropiado revisar

las interpretaciones iniciales de los resultados y la forma en que éstos se presentan.

Revisar los resultados iniciales antes de publicarlos puede evitar malas

interpretaciones innecesarias, y puede conducir a mejoras en los análisis y la

presentación.

Las partes interesadas relevantes con las que realizar la revisión incluyen a los

usuarios finales proyectados, los patrocinadores, los analistas de datos, y los

proveedores de datos.



4. Refinar los criterios para futuros análisis.

A base de realizar análisis y preparar resultados, a menudo se aprenden lecciones

que pueden mejorar futuras labores. Análogamente, pueden aparecer modos de

mejorar las especificaciones de medición y los procedimientos de recogida de datos,

así como ideas para refinar las necesidades de información y objetivos identificados.

SP 2.3 Almacenar los datos y los resultados

Gestionar y almacenar los datos de medición, las especificaciones

de medición, y los resultados de los análisis.

Almacenar información relacionada con mediciones posibilita que ésta se

utilice de manera oportuna y económica en forma de datos y resultados

históricos. La información también se necesita con el fin de proporcionar el

contexto suficiente para interpretar los datos, los criterios de medición, y los

resultados de los análisis.

La información almacenada habitualmente incluye:

Planes de medición.

Especificaciones de medidas.

Conjuntos de datos que se recogieron.

Informes de análisis y presentaciones.

Periodo de conservación para los datos almacenados

La información almacenada contiene o hace referencia a otra información

necesaria para comprender e interpretar las medidas y para evaluar si son

razonables y aplicables (p. ej. especificaciones de medición utilizadas en

distintos trabajos cuando se comparan grupos de trabajo).

Habitualmente no es necesario almacenar conjuntos de datos derivados

que puedan recalcularse. Sin embargo, puede que sea apropiado

almacenar resúmenes basados en medidas derivadas (p. ej., diagramas,

tablas de resultados, informes escritos).

Si se pueden reconstruir eficientemente, no es necesario almacenar de

forma separada los resultados de los análisis intermedios.

Para más información sobre establecer un sistema de gestión de


Para más información sobre establecer el repositorio de mediciones de la

organización, consúltese la práctica específica Establecer el repositorio de

mediciones de la organización en el área de proceso Definición



1. Inventario de datos almacenados.



Subprácticas

1. Revisar los datos para asegurar que sean completos, íntegros,

precisos, y actuales.

2. Almacenar los datos conforme a los procedimientos de


3. Permitir acceder a los contenidos almacenados únicamente a los

grupos y miembros del personal apropiados.

4. Evitar que la información almacenada se utilice de forma inapropiada.

Controlar el acceso a los datos y capacitar a las personas para utilizar los datos de forma apropiada son ejemplos de formas de evitar el uso inapropiado de los datos y la información relacionada.

Algunos ejemplos de uso inapropiado de los datos son:

Revelar información proporcionada confidencialmente.

Malinterpretar en base a información incompleta, fuera de contexto, o engañosa.

Utilizar medidas para evaluar indebidamente el desempeño individual o para valorar a los grupos de trabajo.

Cuestionar la integridad de las personas.

SP 2.4 Comunicar los resultados

Comunicar a todas las partes interesadas relevantes los resultados

de las actividades de medición y análisis.

Los resultados del proceso de medición y análisis se comunican a las

partes interesadas relevantes de una manera que sea oportuna y que sirva

para dar soporte a la toma de decisiones y ayudar a realizar acciones

correctivas.

Las partes interesadas relevantes incluyen a los usuarios finales

proyectados, a los patrocinadores, a los analistas de datos, y a los

proveedores de datos.


1. Informes entregados y resultados de análisis relacionados.

2. Información contextual u orientaciones que ayuden a interpretar los

resultados de los análisis.

Subprácticas

1. Mantener informadas a las partes interesadas relevantes sobre los

resultados de mediciónde manera oportuna.

En la medida de lo posible, y como parte de la forma de hacer negocios, los usuarios

de los resultados de medición se mantienen involucrados personalmente en el

establecimiento de objetivos y en la decisión sobre los planes de acción de medición y

análisis. Regularmente, se pone al corriente a los usuarios sobre el progreso y los

resultados intermedios.



Para más información sobre realizar revisiones de progreso,


2. Ayudar a las partes interesadas relevantes a entender los resultados.

Los resultados se comunican de una forma clara y concisa que es apropiada para las

partes interesadas relevantes. Los resultados se entienden, son fáciles de interpretar,

y están ligados claramente a las necesidades de información y objetivos identificados.

Con frecuencia, los datos analizados no son evidentes para los profesionales que no

son expertos en medición. La comunicación de resultados debería ser clara en cuanto

a:

Cómo y por qué se especificaron las medidas base y derivadas.

Cómo se obtuvieron los datos.

Cómo interpretar los resultados en base a los métodos de análisis de datos utilizados.

Cómo abordan los resultados las necesidades de información.

Algunos ejemplos de acciones realizadas para ayudar a entender los resultados son:

Debatir los resultados con las partes interesadas relevantes.

Proporcionar antecedentes y explicaciones en un documento.

Realizar sesiones informativas con los usuarios

Proporcionar capacitación sobre la forma apropiada de utilizar y entender los resultados de medición.


Definición Organizativa de Procesos (OPD) 232

DEFINICIÓN ORGANIZATIVA DE PROCESOS

Un área de proceso de Gestión de Procesos en el nivel de madurez 3

Propósito

El propósito de Definición Organizativa de Procesos (OPD) es establecer y

mantener un conjunto utilizable de activos de proceso organizativos,

estándares de entorno de trabajo, y reglas y guías para los equipos.


Los activos de proceso organizativos posibilitan que la ejecución de

procesos sea consistente en toda la organización y proporcionan una base

para que la organización obtenga beneficios acumulados a largo plazo

(véase la definición de “activos de proceso organizativos” en el glosario).

La biblioteca de activos de proceso de la organización da soporte al

aprendizaje y a la mejora de procesos, al permitir compartir las buenas

prácticas y las lecciones aprendidas transversalmente en la organización

(véase la definición de “activos de proceso organizativos” en el glosario).

El conjunto de procesos estándar de la organización también describe las

interacciones estándar con los suministradores. Las interacciones con los

suministradores se caracterizan por los siguientes elementos habituales:

entregables que se esperan de los suministradores, criterios de aceptación

aplicables a dichos entregables, estándares (p. ej., estándares de

arquitectura y de tecnología), e hitos y revisiones de progreso estándar.

Los grupos de trabajo adaptan el “conjunto de procesos estándar” de la

organización para crear sus procesos definidos. Otros activos de proceso

organizativos se utilizan para dar soporte a la adaptación e implementación

de procesos definidos. Los estándares de entorno de trabajo se utilizan

para guiar en la creación de entornos de trabajo. Las reglas y guías para

los equipos se utilizan para ayudar a estructurarlos, constituirlos, y

operarlos.

Un “proceso estándar” se compone de otros procesos (esto es,

subprocesos) o elementos de proceso. Un “elemento de proceso” es la

unidad fundamental (esto es, atómica) de la definición de procesos que

describe las actividades y tareas para realizar el trabajo de manera

consistente. La arquitectura de procesos proporciona las reglas para

conectar los elementos de proceso de un proceso estándar. El conjunto de

procesos estándar de la organización puede incluir múltiples arquitecturas

de proceso.

(Véanse las definiciones de “proceso estándar”, “arquitectura de procesos”,

“subproceso”, y “elemento del proceso” en el glosario).



Los activos de proceso organizativos pueden organizarse de muchas formas, dependiendo

de cómo se implemente el área de proceso Definición Organizativa de Procesos. Algunos

ejemplos son:

Las descripciones de los modelos de ciclo de vida pueden formar parte del conjunto de

procesos estándar de la organización o pueden documentarse por separado.

El conjunto de procesos estándar de la organización puede almacenarse en la

biblioteca de activos de proceso de la organización o almacenarse de forma separada.

Un único repositorio puede contener tanto las mediciones como la documentación

relacionada con el proceso, o ambas pueden almacenarse por separado.


Para más información sobre establecer y mantener los servicios estándar

conforme a las necesidades y planes estratégicos, consúltese el área de

proceso Gestión Estratégica de Servicios.

Para más información sobre desplegar activos de proceso organizativos,

consúltese el área de proceso Enfoque Organizativo en Procesos.


SG 1 Establecer activos de proceso organizativos

SP 1.1 Establecer procesos estándar

SP 1.2 Establecer descripciones de modelos de ciclo de vida

SP 1.3 Establecer criterios y guías de adaptación

SP 1.4 Establecer el repositorio de mediciones de la organización

SP 1.5 Establecer la biblioteca de activos de proceso de la organización

SP 1.6 Establecer estándares de entorno de trabajo

SP 1.7 Establecer reglas y guías para los equipos


SG 1 Establecer activos de proceso organizativos

Un conjunto de activos de proceso organizativos se establece y se mantiene.

SP 1.1 Establecer procesos estándar

Establecer y mantener el conjunto de procesos estándar de la

organización.

Los procesos estándar se pueden definir en distintos niveles de una

empresa y se pueden relacionar de forma jerárquica. Por ejemplo, en una

empresa puede haber un conjunto de procesos estándar que las

organizaciones individuales de la empresa (p. ej., una división, una

ubicación) adaptan con el fin de establecer su conjunto de procesos

estándar. El conjunto de procesos estándar también puede adaptarse para

cada una de las áreas de negocio, líneas de producto, o servicios estándar

de la organización. De esta manera, el conjunto de procesos estándar de la

organización puede referirse a los procesos estándar establecidos a nivel

de organización y a los procesos estándar que pueden establecerse a

niveles inferiores, aunque puede que algunas organizaciones tengan un



único nivel de procesos estándar (véanse las definiciones de “proceso

estándar” y “conjunto de procesos estándar de la organización” en el

glosario).

Puede que hagan falta varios procesos estándar para abordar las

necesidades de los diferentes dominios de aplicación, modelos de ciclo de

vida, metodologías, y herramientas. El conjunto de procesos estándar de la

organización contiene elementos de proceso (p. ej. un elemento para

estimar el tamaño de los productos de trabajo) que pueden interconectarse

de acuerdo a una o más arquitecturas de proceso que describan las

relaciones entre los elementos de proceso.

El conjunto de procesos estándar de la organización habitualmente incluye

procesos técnicos, de gestión, administrativos, de soporte, y organizativos.

El conjunto de procesos estándar de la organización debería cubrir

conjuntamente todos los procesos necesarios para la organización y los

grupos de trabajo, incluyendo aquellos abordados por las áreas de proceso

en el nivel de madurez 2.


1. Conjunto de procesos estándar de la organización.

Subprácticas

1. Descomponer cada proceso estándar en elementos de proceso

constituyentes hasta llegar a un detalle suficiente para comprender y

describir el proceso.

Cada elemento de proceso cubre un conjunto de actividades estrechamente

relacionadas. Las descripciones de elementos de proceso pueden ser plantillas para

cumplimentar, partes para completar, abstracciones para refinar, o descripciones

completas que se adaptan o se utilizan sin modificarlas. Estos elementos se describen

con un detalle tal que el proceso, una vez definido completamente, pueda ser

realizado consistentemente por personas con capacitación y habilidades apropiadas.

Algunos ejemplos de elementos de proceso son:

Plantilla para generar estimaciones de tamaño de producto de trabajo.

Descripción de la metodología de diseño de productos de trabajo.

Metodología adaptable para revisiones entre pares.

Proceso adaptable de resolución de incidencias.

Plantilla para crear acuerdos de servicio.

Plantilla para llevar a cabo revisiones de gestión.

Plantillas o flujos de tareas embebidos en herramientas de flujos de trabajo.

Descripción de métodos para precalificar a suministradores como preferentes.

2. Especificar los atributos críticos de cada elemento de proceso.



Algunos ejemplos de atributos críticos son:

Roles del proceso.

Estándares aplicables.

Procedimientos, métodos, herramientas, y recursos aplicables.

Objetivos de rendimiento de procesos.

Criterios de entrada.

Entradas.

Puntos de verificación (p. ej. revisiones entre pares).

Salidas.

Interfaces.

Criterios de salida.

Medidas del producto y del proceso.

3. Especificar las relaciones entre los elementos de proceso.

Algunos ejemplos de relaciones son:

Orden de los elementos de proceso.

Interfaces entre los elementos de proceso.

Interfaces con procesos externos.

Interdependencias entre los elementos de proceso.

Las reglas que describen las relaciones entre los elementos de proceso se denominan

“arquitectura de procesos”. La arquitectura de procesos cubre los requisitos y las

guías esenciales. Las especificaciones detalladas de estas relaciones son seguidas

por las descripciones de los procesos definidos adaptados a partir del conjunto de

procesos estándar de la organización.

4. Asegurar que el conjunto de procesos estándar de la organización

cumple las políticas, estándares, y modelos aplicables.

El cumplimiento de los estándares y modelos de proceso aplicables habitualmente se

demuestra estableciendo la correspondencia entre el conjunto de procesos estándar

de la organización y los estándares y modelos de proceso relevantes. Esta

correspondencia es una entrada útil para hacer futuras evaluaciones.

5. Asegurar que el conjunto de procesos estándar de la organización

satisface las necesidades y objetivos de procesos de la organización.


procesos, consúltese el área de proceso Enfoque Organizativo en

Procesos.

6. Asegurar que la integración entre los procesos incluidos en el conjunto

de procesos estándar de la organización es apropiada.

7. Documentar el conjunto de procesos estándar de la organización.

8. Llevar a cabo revisiones entre pares sobre el conjunto de procesos

estándar de la organización.



Extensión SSD



9. Actualizar el conjunto de procesos estándar de la organización según

se necesite.

Algunos ejemplos de cuándo puede ser necesario actualizar el conjunto de procesos estándar de la organización son:

Cuando se identifican mejoras a los procesos.

Cuando los datos de análisis causal y resolución indican que se necesita un cambio en el proceso.

Cuando se seleccionan propuestas de mejora de procesos para su despliegue en toda la organización.

Cuando se actualizan las necesidades y objetivos de procesos de la organización.

SP 1.2 Establecer descripciones de modelos de ciclo de vida

Establecer y mantener descripciones de los modelos de ciclo de

vida aprobados para su uso en la organización.

Se pueden desarrollar modelos de ciclo de vida para diferentes clientes o

distintas situaciones, ya que un único modelo de ciclo de vida puede no ser

apropiado para todas las situaciones. Los modelos de ciclo de vida se

utilizan frecuentemente para definir las fases del trabajo. La organización

también puede definir modelos de ciclo de vida diferentes para cada tipo de

producto o servicio que entrega.


1. Descripciones de modelos de ciclo de vida.

Subprácticas

1. Seleccionar modelos de ciclo de vida en base a las necesidades de los

grupos de trabajo y de la organización.

La selección de un modelo de ciclo de vida de servicio depende de las características

del servicio y del entorno. Algunos proveedores de servicios definen fases del ciclo de

vida en base a las definiciones de sus servicios estándar.

Algunos ejemplos de conjuntos de fases que pueden componer un ciclo de vida de servicios son:

Planificar, definir, habilitar, y mantener.

Definición de alcance, planificación, ejecución, y terminación.

Estrategia, diseño, transición, operación, y mejora.

A menudo, dominios de servicio individuales tienen asociados implícitamente ciclos de

vida que implican puntos de comunicación, evaluación, y decisión. Las descripciones

de estos puntos pueden incluirse en el conjunto de descripciones de modelos de ciclo

de vida aprobados para su uso en la organización.



Algunos ejemplos de modelos de ciclo de vida utilizados para desarrollar un sistema de servicio son:

Cascada.

Espiral.

Evolutivo.

Incremental.

Iterativo.

2. Documentar las descripciones de los modelos de ciclo de vida.

Los modelos de ciclo de vida pueden documentarse como parte de las descripciones

del proceso estándar de la organización o pueden documentarse por separado.

3. Realizar revisiones entre pares sobre los modelos de ciclo de vida.

Extensión SSD



4. Actualizar las descripciones de los modelos de ciclo de vida según se

necesite.

SP 1.3 Establecer criterios y guías de adaptación

Establecer y mantener criterios y guías de adaptación para el


Los criterios y las guías de adaptación describen:

La forma de utilizar el conjunto de procesos estándar de la

organización y los activos de proceso organizativos para crear

procesos definidos.

Los requisitos que deben satisfacer los procesos definidos (p. ej., el

subconjunto de activos de proceso organizativos que son esenciales

para cualquier proceso que se defina).

Las opciones que se pueden ejercer y los criterios para seleccionarlas.

Los procedimientos que deben seguirse para realizar y documentar la

adaptación del proceso.

Algunos ejemplos de motivos para realizar adaptaciones son:

Adaptar el proceso a un nuevo servicio o tipo de cliente.

Detallar más la descripción del proceso, de forma que el proceso definido resultante

pueda llevarse a cabo.

Adaptar el proceso a un uso o a una clase de usos similares.

La flexibilidad para adaptar y definir procesos se equilibra con asegurar de

forma apropiada que los procesos sean consistentes en toda la

organización. La flexibilidad es necesaria para abordar variables

contextuales, tales como el dominio; la naturaleza del cliente; los

compromisos entre los costes, los plazos, y la calidad; la dificultad técnica



del trabajo; y la experiencia de las personas que implementan el proceso.

Es necesario que haya consistencia en toda la organización para que los

estándares organizativos, los objetivos, y las estrategias se aborden de

forma apropiada, y para que los datos de proceso y las lecciones

aprendidas se puedan compartir.

Adaptar es una actividad crítica que permite cambiar los procesos de forma

controlada por las necesidades específicas de un grupo de trabajo o de

una parte de la organización. Generalmente los procesos y elementos de

proceso que estén directamente relacionados con objetivos críticos de

negocio deberían definirse como obligatorios, pero los procesos y

elementos de proceso que sean menos críticos o que sólo afecten

indirectamente a los objetivos de negocio pueden permitir una adaptación

mayor.

El grado de adaptación podría también depender del modelo de ciclo de

vida del grupo de trabajo, del uso de suministradores, y de otros factores.

Los criterios y guías de adaptación pueden permitir que un proceso

estándar se use “tal como está”, sin ninguna adaptación.


1. Guías de adaptación para el conjunto de procesos estándar de la

organización.

Subprácticas

1. Especificar criterios de selección y procedimientos para adaptar el


Algunos ejemplos de criterios y procedimientos son:

Criterios para seleccionar modelos de ciclo de vida entre los aprobados por la organización.

Criterios para seleccionar elementos de proceso dentro del conjunto de procesos estándar de la organización.

Procedimientos para adaptar los modelos de ciclo de vida y los elementos de proceso seleccionados, con objeto de adecuarlos a las características y necesidades del proceso.

Procedimientos para adaptar las medidas comunes de la organización para que aborden necesidades de información.

Algunos ejemplos de adaptación son:

Modificar un modelo de ciclo de vida.

Combinar elementos de modelos de ciclo de vida distintos.

Modificar elementos de proceso.

Sustituir elementos de proceso.

Reordenar elementos de proceso.

2. Especificar los estándares que se utilizan para documentar los

procesos definidos.



3. Especificar los procedimientos que se utilizan para proponer y obtener

la aprobación de excepciones al conjunto de procesos estándar de la

organización.

4. Documentar las guías de adaptación del conjunto de procesos


5. Llevar a cabo revisiones entre pares sobre las guías de adaptación.

Extensión SSD



6. Actualizar las guías de adaptación según se necesite.

SP 1.4 Establecer el repositorio de mediciones de la organización

Establecer y mantener el repositorio de mediciones de la

organización.

Para más información sobre utilizar el repositorio de mediciones de la

organización para planificar los trabajos, consúltese la práctica específica

Utilizar los activos de proceso organizativos para planificar los trabajos en

el área de proceso Gestión Integrada de Trabajos.

El repositorio contiene medidas relacionadas con el conjunto de procesos

estándar de la organización, tanto de producto como de proceso. También

contiene o referencia a la información necesaria para comprender e

interpretar las medidas, y para evaluar si son razonables y aplicables. Por

ejemplo, las definiciones de las medidas se utilizan para comparar medidas

similares de procesos distintos.


1. Definición del conjunto de medidas comunes de producto y de proceso

para el conjunto de procesos estándar de la organización.

2. Diseño del repositorio de mediciones de la organización.

3. Repositorio de mediciones de la organización (esto es, estructura del

repositorio, entorno de soporte).

4. Datos de mediciones de la organización.

Subprácticas

1. Determinar las necesidades de almacenar, recuperar, y analizar


2. Definir un conjunto de medidas comunes de proceso y de producto


Las medidas en el conjunto común se seleccionan por su capacidad para proporcionar

visibilidad sobre los procesos que son críticos para lograr los objetivos de negocio y

centrarse en los elementos de proceso que impacten significativamente en los costes,

plazos, y rendimiento dentro de los grupos de trabajo y en toda la organización. El

conjunto de medidas comunes puede ser distinto para diferentes procesos estándar.



Las medidas definidas incluyen a las relacionadas con la gestión de acuerdos,

algunas de las cuales podrían tener que ser recogidas por los suministradores.

Las definiciones operativas de las medidas especifican los procedimientos para

recoger datos válidos y los puntos del proceso en los que se recogerán los datos.

Algunos ejemplos de clases de medida utilizadas comúnmente son:

Estimaciones de tamaño del producto de trabajo (p. ej. páginas).

Estimaciones de esfuerzo y coste (p. ej. horas persona).

Medidas reales de tamaño, esfuerzo, y coste.

Medidas de calidad (p. ej. número de incidencias reportadas).

Cobertura de revisiones entre pares.

Cobertura de pruebas.

Medidas de fiabilidad (p. ej. tiempo medio entre fallos).

3. Diseñar e implementar el repositorio de mediciones.

Algunas funciones del repositorio de mediciones son:

Dar soporte a que se comparen e interpreten los datos de medición entre los

trabajos.

Proporcionar suficiente contexto como para permitir que un nuevo grupo de

trabajo identifique y acceda rápidamente a los datos de trabajos similares

almacenados en el repositorio.

Posibilitar que los grupos de trabajo mejoren la precisión de sus estimaciones

utilizando sus propios datos y otros datos históricos.

Ayudar a entender el rendimiento de procesos.

Dar soporte a la gestión estadística de procesos o subprocesos según se

necesite.

4. Especificar procedimientos para almacenar, actualizar, y recuperar

medidas.


almacenamiento de datos, consúltese el área de proceso Medición y

Análisis.

5. Llevar a cabo revisiones entre pares sobre las definiciones del

conjunto de medidas comunes y los procedimientos para

almacenarlas, actualizarlas, y recuperarlas.

Extensión SSD



6. Introducir las medidas especificadas en el repositorio.

Para más información sobre especificar medidas, consúltese el área

de proceso Medición y Análisis.



7. Poner los contenidos del repositorio de mediciones a disposición de la

organización y de los grupos de trabajo para su uso según sea

apropiado.

8. A medida que cambien las necesidades de la organización, actualizar

el repositorio de mediciones, el conjunto de medidas comunes, y los

procedimientos.

Algunos ejemplos de cuándo puede ser necesario actualizar el conjunto de medidas comunes son:

Al añadir nuevos procesos.

Al actualizar los procesos y ser necesarias nuevas medidas.

Al requerirse mayor granularidad en los datos.

Al requerirse mayor visibilidad dentro del proceso.

Al eliminar medidas.

SP 1.5 Establecer la biblioteca de activos de proceso de la organización

Establecer y mantener la biblioteca de activos de proceso de la

organización.

Algunos ejemplos de elementos a almacenar en la biblioteca de activos de proceso de la

organización son:

Políticas organizativas.


Procedimientos (p. ej. procedimiento de estimación).

Planes de desarrollo.

Planes de adquisición.

Planes de aseguramiento de calidad.

Materiales de capacitación.

Ayudas al proceso (p. ej. listas de comprobación).

Informes de lecciones aprendidas.


1. Diseño de la biblioteca de activos de proceso de la organización.

2. Biblioteca de activos de proceso de la organización.

3. Elementos seleccionados para su inclusión en la biblioteca de activos

de proceso de la organización.

4. Catálogo de los elementos de la biblioteca de activos de proceso de la

organización.

Subprácticas

1. Diseñar e implementar la biblioteca de activos de proceso de la

organización, incluyendo su estructura y el entorno de soporte.

2. Especificar los criterios para incluir elementos en la biblioteca.



Los elementos se seleccionan basándose principalmente en su relación con el


3. Especificar procedimientos para almacenar, actualizar, y recuperar

elementos.

4. Incorporar los elementos seleccionados en la biblioteca y clasificarlos

para facilitar su consulta y recuperación.

5. Poner los elementos a disposición de los grupos de trabajo para su

uso.

6. Revisar periódicamente el uso de cada elemento.

7. Actualizar la biblioteca de activos de proceso de la organización según

se necesite.

Algunos ejemplos sobre cuándo puede ser necesario actualizar la biblioteca son:

Al añadir nuevos elementos.

Al eliminar elementos.

Cuando cambian las versiones actuales de los elementos.

SP 1.6 Establecer estándares de entorno de trabajo

Establecer y mantener los estándares de entorno de trabajo.

Los estándares de entorno de trabajo permiten que la organización y los

grupos de trabajo se beneficien de herramientas, capacitación, y

mantenimiento comunes, así como ahorrar costes por volumen de compra.

Los estándares de entorno de trabajo abordan las necesidades de todas

las partes interesadas, y consideran factores como la productividad, coste,

disponibilidad, seguridad, así como factores como la salud, protección, y

ergonomía en el puesto de trabajo. Los estándares de entorno de trabajo

pueden incluir guías de adaptación y el uso de excepciones que permitan

adaptar el entorno de trabajo a las necesidades del grupo de trabajo.

Algunos ejemplos de estándares de entorno de trabajo son:

Procedimientos para operar, proteger, y asegurar el entorno de trabajo del cliente en el

que trabaja el proveedor de servicios.

Procedimientos para operar, proteger, y asegurar el entorno de trabajo.

Hardware y software estándar de los puestos de trabajo.

Software de aplicación estándar y guías para adaptarlo.

Equipos de producción y de calibración estándar.

Proceso para solicitar y aprobar las adaptaciones o las excepciones.


1. Estándares de entorno de trabajo.

Subprácticas

1. Evaluar los entornos de trabajo estándar disponibles comercialmente

que sean apropiados para la organización.



2. Adoptar entornos de trabajo estándar existentes y desarrollar nuevos

entornos para cubrir las carencias en base a las necesidades y

objetivos de procesos de la organización.

SP 1.7 Establecer reglas y guías para los equipos

Establecer y mantener reglas y guías organizativas para

estructurar, constituir, y operar los equipos.

Las reglas operativas y guías para los equipos definen y controlan el modo

en que se crean e interactúan entre sí los equipos con el fin de cumplir los

objetivos. Los miembros del equipo deberían entender los estándares de

trabajo y participar siguiendo dichos estándares.

Al establecer reglas y guías para los equipos, asegúrese de que éstas

cumplen todas las normativas o leyes locales y nacionales que puedan

afectar al uso de equipos.

Estructurar equipos implica definir el número de equipos, el tipo de cada

uno, y el modo en que cada equipo de la estructura se relaciona con los

demás. Constituir equipos implica definir los estatutos de cada equipo,

asignarles sus miembros y líderes, y proporcionar recursos a cada equipo

con objeto de acometer el trabajo.


1. Reglas y guías para estructurar y constituir equipos.

2. Reglas operativas para los equipos.

Subprácticas

1. Establecer y mantener mecanismos de apoderamiento que faciliten la

toma de decisiones de manera oportuna.

En un entorno de equipos exitosos se establecen canales claros de responsabilidad y

autoridad por medio de documentar y desplegar guías organizativas que definan

claramente el modo en que se apodera a los equipos.

2. Establecer y mantener reglas y guías para estructurar y constituir

equipos.

Los activos de proceso organizativos pueden ayudar al grupo de trabajo a estructurar e implementar equipos. Algunos de estos activos son:

Guías para establecer líneas de comunicación, autoridad, y escalado.

Guías para estructurar equipos.

Guías para constituir equipos.

Guías sobre autoridad y responsabilidad en los equipos.

Criterios para seleccionar los líderes de equipo.

3. Definir las expectativas, reglas, y guías que orientan sobre el modo en

que los equipos trabajan colectivamente.



Estas reglas y guías establecen prácticas organizativas para que haya coherencia entre los equipos y pueden incluir:

El modo en que se establecen y mantienen las interfaces entre los equipos.

El modo en que se aceptan y transfieren las asignaciones.

El modo en que se accede a los recursos y a las entradas.

El modo en que se realiza el trabajo.

Quién comprueba, revisa, y aprueba el trabajo.

El modo en que se aprueba el trabajo.

El modo en que se entrega y se comunica el trabajo.

Quién supervisa a quién.

Cuáles son los requisitos (p. ej., costes, plazos, estado del rendimiento), las medidas, y los métodos de reporte.

Qué medidas y métodos de reporte de progreso se usan.


Enfoque Organizativo en Procesos (OPF) 245

ENFOQUE ORGANIZATIVO EN PROCESOS


Propósito

El propósito de Enfoque Organizativo en Procesos (OPF) es planificar,

implementar, y desplegar mejoras de proceso organizativas en base a un

conocimiento en profundidad de las fortalezas y debilidades actuales de los

procesos y activos de proceso de la organización.


Los procesos de la organización incluyen a todos los procesos que la

organización y sus grupos de trabajo utilizan. Las mejoras candidatas a los

procesos y activos de proceso de la organización se obtienen de diversas

fuentes, incluyendo las mediciones de procesos, las lecciones aprendidas

al implementar los procesos, los resultados de las evaluaciones de

procesos, los resultados de las actividades de evaluación de productos y

servicios, los resultados de evaluar la satisfacción de los clientes, los

resultados de las comparativas frente a los procesos de otras

organizaciones, y las recomendaciones realizadas por otras iniciativas de

mejora dentro de la organización.

La mejora de procesos tiene lugar en el contexto de las necesidades de la

organización y se utiliza para abordar los objetivos de la organización. La

organización promueve que las personas que realizan los procesos

participen en las actividades de mejora de procesos. La responsabilidad de

facilitar y gestionar las actividades de mejora de procesos, incluyendo

coordinar para que participen otras personas, se asigna habitualmente al

grupo de procesos. La organización proporciona a largo plazo el

compromiso y los recursos que se requieren para patrocinar a este grupo y

para asegurar que el despliegue de mejoras se haga de manera oportuna y

eficaz.

Se requiere una planificación cuidadosa para asegurar que las labores de

mejora de procesos de toda la organización se gestionen e implementen

adecuadamente. Los resultados de la planificación de la mejora de

procesos se documentan en un plan de mejora de procesos.

El “plan de mejora de procesos de la organización” aborda la planificación

de evaluaciones, la planificación de acciones de proceso, la planificación

de pilotos, y la planificación de despliegues. Los planes de evaluación

describen la cronología y los plazos de la evaluación, su alcance, los

recursos necesarios para realizarla, el modelo de referencia con respecto

al que se evaluará, y la logística de la evaluación.

Los planes de acciones de proceso usualmente son un resultado de las

evaluaciones, y documentan el modo en que se implementarán las mejoras

dirigidas a corregir las debilidades descubiertas en la evaluación. A veces



es necesario probar en un grupo reducido las mejoras descritas en el plan

de acciones de proceso antes de desplegarlas en toda la organización. En

estos casos, se genera un plan de piloto.

Al desplegar una mejora se crea un plan de despliegue. El plan describe

cuándo y cómo se va a desplegar la mejora en toda la organización.

Los activos de proceso organizativos se utilizan para describir,

implementar, y mejorar los procesos de la organización (véase la definición

de “activos de proceso organizativos” en el glosario).





SG 1 Determinar oportunidades de mejora de procesos

SP 1.1 Establecer necesidades de procesos organizativas

SP 1.2 Evaluar los procesos de la organización

SP 1.3 Identificar las mejoras de proceso de la organización

SG 2 Planificar e implementar acciones de proceso

SP 2.1 Establecer planes de acciones de proceso

SP 2.2 Implementar planes de acciones de proceso

SG 3 Desplegar activos de proceso organizativos e incorporar experiencias

SP 3.1 Desplegar activos de proceso organizativos

SP 3.2 Desplegar procesos estándar

SP 3.3 Monitorizar la implementación

SP 3.4 Incorporar experiencias a los activos de proceso organizativos


SG 1 Determinar oportunidades de mejora de procesos

Periódicamente y según se necesite se identifican fortalezas, debilidades, y oportunidades de mejora para los procesos de la organización.

Se pueden determinar fortalezas, debilidades, y oportunidades de mejora

en relación a estándares o a modelos de procesos, tales como el modelo

CMMI o el estándar ISO. Las mejoras de proceso deberían seleccionarse

para abordar las necesidades de la organización.

Pueden surgir oportunidades de mejora de procesos como resultado de

que haya cambios en los objetivos de negocio, los requisitos legales y

normativos, y los resultados de los estudios comparativos.

SP 1.1 Establecer necesidades de procesos organizativas

Establecer y mantener la descripción de las necesidades y

objetivos de procesos para la organización.

Los procesos de la organización operan en un contexto de negocio que

debería ser comprendido. Los objetivos de negocio, las necesidades, y las

restricciones de la organización determinan las necesidades y los objetivos



de los procesos de la organización. Habitualmente, los problemas

relacionados con la satisfacción de clientes, las finanzas, la tecnología, la

calidad, los recursos humanos, y el marketing son consideraciones

importantes para los procesos.

Las necesidades y objetivos de procesos de la organización cubren aspectos que incluyen:

Características de los procesos.

Objetivos de rendimiento de procesos, tales como el plazo de comercialización y la

calidad entregada.

Eficacia de los procesos.


1. Necesidades y objetivos de procesos de la organización.

Subprácticas

1. Identificar políticas, estándares, y objetivos de negocio que sean

aplicables a los procesos de la organización.

Algunos ejemplos de estándares son:

ISO/IEC 12207:2008 Systems and Software Engineering – Software Life Cycle Processes [ISO 2008a]

ISO/IEC 15288:2008 Systems and Software Engineering – System Life Cycle Processes [ISO 2008b]

ISO/IEC 27001:2005 Information technology – Security techniques – Information Security Management Systems – Requirements [ISO/IEC 2005]

ISO/IEC 14764:2006 Software Engineering – Software Life Cycle Processes – Maintenance [ISO 2006b]

ISO/IEC 20000 Information Technology – Service Management [ISO 2005b]

Assurance Focus for CMMI [DHS 2009]

NDIA Engineering for System Assurance Guidebook [NDIA 2008]

Resiliency Management Model [SEI 2010c]

2. Examinar las buenas prácticas en los estándares y modelos de

procesos relevantes.

3. Determinar los objetivos de rendimiento de procesos de la

organización.

Los objetivos de proceso se pueden expresar de forma cuantitativa o cualitativa.

Para más información sobre establecer objetivos de medición,


Para más información sobre establecer objetivos de calidad y

rendimiento de procesos, consúltese el área de proceso Rendimiento

Organizativo de Procesos.



Algunos ejemplos de objetivos de rendimiento de procesos son:

Lograr un valor determinado en la valoración de la satisfacción de los clientes.

Reducir en un porcentaje determinado las tasas de incidencias.

Cerrar mensualmente un número determinado de incidencias.

Lograr un tiempo de ciclo determinado para una actividad dada.

Mejorar la productividad en un porcentaje determinado.

Simplificar el flujo de trabajo de aprobación de requisitos.

Mejorar la calidad de los productos entregados al cliente.

4. Definir las características esenciales de los procesos de la

organización.

Las características esenciales de los procesos de la organización se determinan en

base a:

Los procesos que actualmente se están usando en la organización.

Los estándares impuestos por la organización.

Los estándares que imponen normalmente los clientes de la organización.

Algunos ejemplos de características de procesos son:

Nivel de detalle.

Notación de procesos.

Granularidad.

5. Documentar las necesidades y objetivos de procesos de la

organización.

6. Actualizar las necesidades y objetivos de procesos de la organización

según se necesite.

SP 1.2 Evaluar los procesos de la organización

Evaluar los procesos de la organización periódicamente y según

se necesite para mantener el conocimiento de sus fortalezas y

debilidades.

Las evaluaciones de procesos pueden realizarse por las siguientes razones:

Para identificar los procesos a mejorar.

Para confirmar el progreso y hacer visibles los beneficios de la mejora de procesos.

Para satisfacer las necesidades de una relación cliente-suministrador.

Para motivar y facilitar que se acepten.

La aceptación que se obtiene durante una evaluación de procesos puede

mermarse significativamente si después no se continúa con un plan de

acción basado en la evaluación.




1. Planes para las evaluaciones de procesos de la organización.

2. Hallazgos de la evaluación que traten sobre las fortalezas y

debilidades de los procesos de la organización.

3. Recomendaciones de mejora para los procesos de la organización.

Subprácticas

1. Obtener el patrocinio de la dirección para la evaluación de procesos.

El patrocinio de la dirección incluye el compromiso de disponer de los gerentes y el

personal durante el proceso de evaluación y de proporcionar recursos y financiación

para analizar y comunicar los hallazgos de la evaluación.

2. Definir el alcance de la evaluación de procesos.

Las evaluaciones de procesos se pueden realizar en toda la organización o en una

parte menor, como podría ser un único grupo de trabajo o área de negocio.

El alcance de la evaluación de procesos aborda:

Definición de la organización (p. ej. ubicaciones, áreas de negocio) cubierta por la evaluación.

Identificación de los grupos de trabajo y funciones de soporte que representarán a la organización durante la evaluación.

Procesos que se van a evaluar.

3. Determinar el método y los criterios que se van a utilizar para evaluar

los procesos.

Las evaluaciones de procesos se pueden realizar de muchas maneras. Éstas

deberían abordar las necesidades y los objetivos de la organización, los cuales

pueden cambiar con el tiempo. Por ejemplo, la evaluación puede basarse en un

modelo de procesos tal como el modelo CMMI, o en un estándar nacional o

internacional tal como el ISO 9001 [ISO 2008c]. Las evaluaciones también se pueden

basar en comparativas con otras organizaciones en las que se identifiquen prácticas

que puedan contribuir a mejorar el rendimiento de la organización. Las características

del método de evaluación pueden variar, incluyendo su duración y el esfuerzo, la

composición del equipo evaluador, y el método y profundidad de la investigación.

4. Planificar, programar, y preparar la evaluación de procesos.

5. Realizar la evaluación de procesos.

6. Documentar y entregar las actividades y hallazgos de la evaluación.

SP 1.3 Identificar las mejoras de proceso de la organización

Identificar mejoras a los procesos y a los activos de proceso de la

organización.


1. Análisis de mejoras de proceso candidatas.

2. Identificación de mejoras para los procesos de la organización.



Subprácticas

1. Determinar mejoras de proceso candidatas.

Habitualmente, para determinar mejoras de proceso candidatas se hace lo siguiente:

Medir los procesos y analizar los resultados de medición.

Revisar que los procesos sean eficaces y adecuados.

Evaluar la satisfacción de los clientes.

Revisar las lecciones aprendidas al adaptar el conjunto de procesos estándar de la organización.

Revisar las lecciones aprendidas al implementar los procesos.

Revisar las propuestas de mejora de proceso enviadas por los gerentes, el personal, y las partes interesadas relevantes de la organización.

Solicitar información sobre mejora de procesos a los gerentes y a otros líderes de la organización.

Examinar los resultados de las evaluaciones de procesos y de otras revisiones relacionadas con procesos.

Revisar los resultados de las iniciativas de mejora de la organización.

2. Priorizar las mejoras de proceso candidatas.

Los criterios para priorizar son:

Tener en cuenta el coste y esfuerzo estimados para implementar las mejoras de proceso.

Evaluar las mejoras esperadas frente a los objetivos y prioridades de mejora de la organización.

Determinar las barreras potenciales a las mejoras de proceso y desarrollar estrategias para superarlas.

Algunos ejemplos de técnicas que ayudan a determinar y priorizar las mejoras que se van a implementar son:

Un análisis de coste-beneficio que compare el coste y esfuerzo estimados de implementar las mejoras de proceso con sus beneficios asociados.

Un análisis de carencias que compare las condiciones actuales en la organización con las condiciones óptimas.

Un análisis de campos de fuerza de las mejoras potenciales para identificar las barreras potenciales y las estrategias para superarlas.

Un análisis de causa-efecto para proporcionar información sobre los efectos potenciales de las distintas mejoras que después pueden compararse.

3. Identificar y documentar las mejoras de proceso que se van a

implementar.

4. Actualizar la lista de mejoras de proceso planificadas para mantenerla

vigente.



SG 2 Planificar e implementar acciones de proceso

Se planifican e implementan acciones de proceso que abordan mejoras a los procesos y activos de proceso de la organización.

Para que la implementación de mejoras tenga éxito, hace falta que los

propietarios de procesos, los que los realizan, y las organizaciones de

soporte participen en la planificación e implementación de acciones de

proceso.

SP 2.1 Establecer planes de acciones de proceso

Establecer y mantener planes de acciones de proceso que aborden

las mejoras a los procesos y activos de proceso de la

organización.

Establecer y mantener planes de acciones de proceso habitualmente engloba a los

siguientes roles.

Comités de dirección que establecen las estrategias y supervisan las actividades de

mejora de procesos.

Grupos de proceso que facilitan y gestionan las actividades de mejora de procesos.

Equipos de acciones de proceso que definen e implementan las acciones de proceso.

Propietarios de procesos que gestionan el despliegue.

Profesionales que realizan el proceso.

Involucrar a las partes interesadas ayuda a obtener su aceptación de las

mejoras de proceso y aumenta la probabilidad de que el despliegue sea

eficaz.

Los planes de acciones de proceso son planes de implementación

detallados. Estos planes difieren del plan de mejora de procesos de la

organización en que están enfocados en las mejoras que fueron definidas

para abordar las debilidades que usualmente se descubren en las

evaluaciones.


1. Planes de acciones de proceso aprobados de la organización.

Subprácticas

1. Identificar estrategias, enfoques, y acciones para abordar las mejoras

de proceso identificadas.

Los cambios nuevos, no probados, e importantes se pilotan antes de incorporarlos al

uso normal.

2. Establecer equipos de acciones de proceso para implementar las

acciones.

Los equipos y personas que realizan acciones de mejora de procesos se llaman

“equipos de acciones de proceso”. En los equipos de acciones de proceso

habitualmente se incluye a propietarios de procesos y a quienes realizan los procesos.

3. Documentar los planes de acciones de proceso.



Los planes de acciones de proceso habitualmente cubren:

Infraestructura de mejora de procesos.

Objetivos de mejora de procesos.

Mejoras de procesos a abordar.

Procedimientos para planificar y seguir las acciones de proceso.

Estrategias para pilotar e implementar las acciones de proceso.

Responsabilidad y autoridad para implementar las acciones de proceso.

Recursos, plazos, y asignaciones para implementar las acciones de proceso.

Métodos para determinar la eficacia de las acciones de proceso.

Riesgos asociados a los planes de acciones de proceso.

4. Revisar y negociar con las partes interesadas relevantes los planes de

acciones de proceso.

5. Actualizar los planes de acciones de proceso según se necesite.

SP 2.2 Implementar planes de acciones de proceso

Implementar los planes de acciones de proceso.


1. Compromisos entre los equipos de acciones de proceso.

2. Estado y resultados de implementar los planes de acciones de

proceso.

3. Planes para los pilotos.

Subprácticas

1. Poner a disposición de las partes interesadas relevantes los planes de


2. Negociar y documentar los compromisos entre los equipos de

acciones de proceso y actualizar sus planes de acciones de proceso

según se necesite.

3. Seguir el progreso y los compromisos frente a los planes de acciones

de proceso.

4. Realizar revisiones conjuntas entre los equipos de acciones de

proceso y las partes interesadas relevantes para monitorizar el

progreso y los resultados de las acciones de proceso.

5. Planificar los pilotos que se necesiten para probar las mejoras de

proceso seleccionadas.

6. Revisar las actividades y productos de trabajo de los equipos de


7. Identificar, documentar, y seguir hasta su cierre los problemas

encontrados al implementar los planes de acciones de proceso.



8. Asegurar que los resultados de implementar los planes de acciones de

proceso satisfacen los objetivos de mejora de procesos de la

organización.

SG 3 Desplegar activos de proceso organizativos e incorporar experiencias

Los activos de proceso organizativos se despliegan en toda la organización y las experiencias relacionadas con procesos se incorporan a los activos de proceso organizativos.

Las prácticas específicas bajo esta meta específica describen actividades

continuas. Durante el ciclo de vida del trabajo pueden surgir nuevas

oportunidades de sacar partido de los activos de proceso organizativos y

de cambiarlos. La organización debería dar soporte continuamente al

despliegue de procesos estándar y de otros activos de proceso

organizativos, particularmente al empezar nuevos trabajos.

SP 3.1 Desplegar activos de proceso organizativos

Desplegar activos de proceso organizativos en toda la

organización.

El despliegue de activos de proceso organizativos o de cambios en los

mismos debería realizarse de forma ordenada. Puede que en algunas

partes de la organización no sea apropiado (p. ej. por los requisitos de las

partes interesadas, o por la fase del ciclo de vida que actualmente se esté

implementando) el uso de algunos activos de proceso organizativos o de

cambios en los mismos. Por tanto, es importante que se involucren en el

despliegue a quienes estén ejecutando o vayan a ejecutar los procesos, así

como a otras funciones de la organización (p. ej. capacitación,

aseguramiento de calidad) según se necesite.




1. Planes para desplegar en toda la organización activos de proceso

organizativos y cambios en los mismos.

2. Materiales de capacitación para desplegar activos de proceso

organizativos y cambios en los mismos.

3. Documentación de los cambios en los activos de proceso

organizativos.

4. Materiales de soporte para desplegar activos de proceso organizativos

y cambios en los mismos.

Subprácticas

1. Desplegar activos de proceso organizativos en toda la organización.



Algunas actividades que habitualmente se realizan como parte del despliegue de activos de proceso son:

Identificar los activos de proceso organizativos que deberían adoptar quienes realizan los procesos.

Determinar cómo distribuir (p.ej. por medio de un sitio web) los activos de proceso organizativos.

Identificar cómo comunicar los cambios en los activos de proceso organizativos.

Identificar los recursos (p. ej. métodos, herramientas) que se necesitan para dar soporte al uso de los activos de proceso organizativos.

Planificar el despliegue.

Ayudar a quienes utilizan los activos de proceso organizativos.

Asegurar que hay capacitación disponible para quienes utilizan los activos de proceso organizativos.

Para más información sobre establecer una competencia de

capacitación organizativa, consúltese el área de proceso Capacitación

Organizativa.

2. Documentar cambios en los activos de proceso organizativos.

La documentación de cambios en los activos de proceso organizativos tiene dos

objetivos principales:

Posibilitar que los cambios se comuniquen.

Entender las relaciones que hay entre los cambios en los activos de proceso organizativos y los cambios en el rendimiento y los resultados de los procesos.

3. Desplegar en toda la organización los cambios que se hayan hecho en

los activos de proceso organizativos.

Algunas actividades que habitualmente se realizan como parte del despliegue de cambios son:

Determinar qué cambios son apropiados para las personas que realizan los procesos.

Planificar el despliegue.

Organizar el soporte necesario para que la transición de los cambios tenga éxito.

4. Guiar y aconsejar acerca del uso de activos de proceso organizativos.

SP 3.2 Desplegar procesos estándar

Desplegar el conjunto de procesos estándar de la organización en

los grupos de trabajo a su inicio y desplegar cambios en los

mismos según sea apropiado durante el trabajo.

Es importante que los nuevos grupos de trabajo utilicen procesos probados

y eficaces para realizar las actividades críticas tempranas (p ej.

planificación de trabajo, recepción de requisitos, obtención de recursos).

Los grupos de trabajo también deberían actualizar periódicamente sus

procesos definidos para incorporar los últimos cambios realizados en el

conjunto de procesos estándar de la organización cuando los cambios les



beneficien. Esta actualización periódica ayuda a asegurar que todos los

trabajos obtengan todos los beneficios de lo que han aprendido otros

grupos.

Para más información sobre establecer procesos estándar y establecer

criterios y guías de adaptación, consúltese el área de proceso Definición



1. Lista de trabajos de la organización y situación del despliegue de

procesos en cada uno (esto es, trabajos existentes y planificados).

2. Guías para desplegar en nuevos trabajos el conjunto de procesos


3. Registros de adaptar e implementar el conjunto de procesos estándar


Subprácticas

1. Identificar grupos de trabajo en la organización que estén empezando.

2. Identificar grupos de trabajo activos que se beneficiarían al

implementar el conjunto de procesos estándar de la organización

actual.

3. Establecer planes para implementar en los trabajos identificados el


4. Ayudar a los grupos de trabajo a adaptar el conjunto de procesos

estándar de la organización para que cumpla sus necesidades.

Para más información sobre establecer el proceso definido para un

trabajo, consúltese el área de proceso Gestión Integrada de Trabajos.

5. Mantener registros de las adaptaciones y la implementación de

procesos en los trabajos identificados.

6. Asegurar que los procesos definidos que resulten de la adaptación se

incorporen en los planes de las auditorías de cumplimiento de

procesos.

Las auditorías de cumplimiento de procesos son evaluaciones objetivas de los

trabajos frente a sus procesos definidos para el trabajo.

7. A medida que se actualice el conjunto de procesos estándar de la

organización, identificar los grupos de trabajo que deberían

implementar los cambios.

SP 3.3 Monitorizar la implementación

Monitorizar la implementación del conjunto de procesos estándar

de la organización y el uso de activos de proceso en todos los

trabajos.

Al monitorizar la implementación la organización se asegura que el

conjunto de procesos estándar y otros activos de proceso de la

organización se han desplegado de forma apropiada en todos los grupos



de trabajo. Monitorizar la implementación también ayuda a que la

organización entienda mejor los activos de proceso organizativos que se

están utilizando y en qué parte de la organización se utilizan. La

monitorización también ayuda a establecer un contexto amplio para

interpretar y utilizar medidas de proceso y de producto, lecciones

aprendidas, e información sobre mejoras obtenida de los grupos de trabajo.


1. Resultados de monitorizar la implementación de procesos en el

trabajo.

2. Estado y resultados de las auditorías de cumplimiento de procesos.

3. Resultados de revisar los artefactos de proceso seleccionados

creados al adaptar e implementar procesos.

Subprácticas

1. Monitorizar el uso de activos de proceso organizativos y de cambios

en los mismos por parte de los grupos de trabajo.

2. Revisar los artefactos de proceso seleccionados creados durante la

vida del trabajo.

Al revisar artefactos de proceso seleccionados creados durante la vida del trabajo se

asegura que todos los grupos de trabajo están utilizando de forma apropiada el


3. Revisar los resultados de las auditorías de cumplimiento de procesos

para determinar el grado de despliegue del conjunto de procesos


Para más información sobre evaluar procesos objetivamente,

consúltese el área de proceso Aseguramiento de Calidad Procesos y

Productos.

4. Identificar, documentar, y seguir hasta su cierre los problemas

relacionados con la implementación del conjunto de procesos estándar


SP 3.4 Incorporar experiencias a los activos de proceso organizativos

Incorporar experiencias relacionadas con procesos derivadas de

planificar y realizar el proceso a los activos de proceso

organizativos.


1. Propuestas de mejora de procesos.

2. Lecciones aprendidas sobre procesos.

3. Mediciones de los activos de proceso organizativos.

4. Recomendaciones de mejora para los activos de proceso

organizativos.

5. Registros de las actividades de mejora de procesos de la

organización.



6. Información sobre activos de proceso organizativos y mejoras a los

mismos.

Subprácticas

1. Realizar revisiones periódicas de la eficacia y conveniencia del

conjunto de procesos estándar de la organización y los activos de

proceso organizativos relacionados con respecto a las necesidades y

objetivos de procesos derivados de los objetivos de negocio de la

organización.

2. Obtener realimentación acerca del uso de los activos de proceso

organizativos.

3. Derivar lecciones aprendidas a partir de definir, pilotar, implementar, y

desplegar activos de proceso organizativos.

4. Poner las lecciones aprendidas a disposición de las personas de la

organización según sea apropiado.

Puede que sea necesario realizar acciones para asegurar que las lecciones

aprendidas se utilicen de forma apropiada.

Algunos ejemplos de uso inapropiado de lecciones aprendidas son:

Evaluar el desempeño de las personas.

Juzgar los resultados del rendimiento de procesos.

Algunos ejemplos de cómo evitar el uso inapropiado de las lecciones aprendidas son:

Controlar el acceso a las lecciones aprendidas.

Educar a las personas acerca del uso apropiado de las lecciones aprendidas.

5. Analizar los datos de medición obtenidos al utilizar el conjunto de

medidas comunes de la organización.

Para más información sobre analizar datos de mediciones, consúltese

el área de proceso Medición y Análisis.

Para más información sobre establecer el repositorio de mediciones de

la organización, consúltese el área de proceso Definición Organizativa

de Procesos.

6. Evaluar los procesos, métodos, y herramientas en uso en la

organización y desarrollar recomendaciones para mejorar los activos

de proceso organizativos.

Habitualmente esta evaluación incluye:

Determinar qué procesos, métodos, y herramientas pueden usarse potencialmente en otras partes de la organización.

Evaluar la calidad y eficacia de los activos de proceso organizativos.

Identificar mejoras candidatas a los activos de proceso organizativos.

Determinar el cumplimento del conjunto de procesos estándar de la organización y de las guías de adaptación.



7. Poner a disposición de las personas de la organización según sea

apropiado los mejores procesos, métodos, y herramientas.

8. Gestionar las propuestas de mejora de procesos.

Las propuestas de mejora de procesos pueden abordar tanto mejoras a procesos

como mejoras tecnológicas.

Las actividades para gestionar las propuestas de mejora de procesos habitualmente incluyen:

Solicitar propuestas de mejora de procesos.

Recopilar propuestas de mejora de procesos.

Revisar propuestas de mejora de procesos.

Seleccionar qué propuestas de mejora de procesos se van a implementar.

Seguir la implementación de las propuestas de mejora de procesos.

Las propuestas de mejora de procesos se documentan según sea apropiado en forma

de peticiones de cambio a los procesos o de informes de problema.

Algunas propuestas de mejora de procesos pueden incorporarse a los planes de

acciones de proceso de la organización.

9. Establecer y mantener registros de las actividades de mejora de



Gestión del Rendimiento Organizativo (OPM) 259

GESTIÓN DEL RENDIMIENTO ORGANIZATIVO


Propósito

El propósito de Gestión del Rendimiento Organizativo (OPM) es gestionar

proactivamente el rendimiento de la organización para cumplir sus



El área de proceso Gestión del Rendimiento Organizativo hace posible

gestionar el rendimiento organizativo analizando iterativamente los datos

agregados de proyectos o trabajos, identificando carencias en el

rendimiento respecto a los objetivos de negocio, y seleccionando y

desplegando mejoras para subsanar las carencias.

En esta área de proceso, el término “mejora” incluye todas las mejoras de

proceso y mejoras tecnológicas incrementales e innovadoras, incluyendo

las mejoras realizadas en los entornos de trabajo. Una “mejora” se refiere a

cualquier idea que pudiera cambiar los procesos de la organización, su

tecnología, y su rendimiento para cumplir mejor los objetivos de negocio de

la organización así como los objetivos de calidad y rendimiento de

procesos asociados.

Algunos objetivos de negocio que esta área de proceso podría abordar

son:

Mejorar la calidad del producto (p. ej., funcionalidad, atributos de

calidad).

Aumentar la productividad.

Aumentar la eficiencia y eficacia del proceso.

Aumentar la regularidad en el cumplimiento de presupuestos y plazos.

Reducir el tiempo de ciclo.

Aumentar la satisfacción de clientes y usuarios finales.

Reducir el tiempo de desarrollo o producción que se necesita para

cambiar la funcionalidad, añadir nuevas características, o adaptarse a

nuevas tecnologías.

Mejorar el rendimiento de una cadena de suministro que englobe a

varios suministradores.

Mejorar el uso de los recursos en toda la organización.

La organización analiza los datos de rendimiento de producto y de proceso

de los trabajos para determinar si es capaz de cumplir los objetivos de

calidad y rendimiento de procesos. Las líneas base y los modelos de

rendimiento de procesos desarrollados utilizando los procesos de

Rendimiento Organizativo de Procesos se utilizan como parte del análisis.



Los procesos de Análisis Causal y Resolución también pueden utilizarse

para identificar áreas potenciales de mejora o propuestas de mejora

específicas.

La organización identifica y solicita proactivamente mejoras incrementales

e innovadoras desde dentro de la organización y desde fuentes externas,

tales como las académicas, las de inteligencia competitiva, y las mejoras

que se han implementado con éxito en otros lugares.

Hacer realidad las mejoras y sus efectos sobre los objetivos de calidad y

rendimiento de procesos depende de la capacidad para identificar, evaluar,

implementar, y desplegar con eficacia mejoras a los procesos y tecnologías


Hacer realidad las mejoras y sus efectos beneficiosos también depende del

compromiso del personal para identificar y evaluar las posibles mejoras y

para mantener el foco en una planificación a largo plazo que incluya la

identificación de innovaciones.

Las propuestas de mejora se evalúan y validan para determinar su eficacia

en el entorno de destino. En base a esta evaluación, las mejoras que se

van a desplegar en nuevos trabajos y en trabajos en curso se priorizan y se

seleccionan. El despliegue se gestiona de acuerdo al plan de despliegue y

los datos de rendimiento se analizan utilizando técnicas estadísticas y otras

técnicas cuantitativas para determinar los efectos que tiene la mejora sobre

los objetivos de calidad y rendimiento de procesos.

Este ciclo de mejora optimiza continuamente los procesos organizativos en

base a los objetivos de calidad y rendimiento de procesos. Los objetivos de

negocio se revisan periódicamente para asegurar que están actualizados y

los objetivos de calidad y rendimiento de procesos se actualizan según sea

apropiado.

El área de proceso Enfoque Organizativo en Procesos no incluye ningún

supuesto sobre la base cuantitativa para identificar las mejoras ni sus

resultados esperados. Esta área de proceso amplía las prácticas de

Enfoque Organizativo en Procesos centrándose en la mejora de procesos

basada en entender cuantitativamente el conjunto de procesos y

tecnologías estándar de la organización y la calidad y rendimiento de

procesos que se espera de ellos.

Las prácticas específicas de esta área de proceso son aplicables a

organizaciones cuyos trabajos se gestionen cuantitativamente. Usar las

prácticas específicas de esta área de proceso puede añadir valor en otras

situaciones, pero los resultados podrían no proporcionar el mismo grado de

impacto sobre los objetivos de calidad y rendimiento de procesos de la

organización.


Para más información sobre identificar las causas de los resultados

seleccionados y realizar acciones para mejorar el rendimiento de procesos,

consúltese el área de proceso Análisis Causal y Resolución.




proceso de evaluación formal que evalúe las alternativas identificadas con

respecto a criterios establecidos, consúltese el área de proceso Análisis de

Decisiones y Resolución.




Para más información sobre planificar, implementar, y desplegar mejoras

de proceso organizativas en base a entender en profundidad las fortalezas

y debilidades actuales de los procesos y activos de proceso de la

organización, consúltese el área de proceso Enfoque Organizativo en

Procesos.

Para más información sobre establecer objetivos de calidad y rendimiento

de procesos y establecer líneas base y modelos de rendimiento de

procesos, consúltese el área de proceso Rendimiento Organizativo de

Procesos.

Para más información sobre proporcionar capacitación, consúltese el área

de proceso Capacitación Organizativa.


SG 1 Gestionar el rendimiento de negocio

SP 1.1 Mantener los objetivos de negocio

SP 1.2 Analizar datos de rendimiento de procesos

SP 1.3 Identificar áreas de mejora potenciales

SG 2 Seleccionar mejoras

SP 2.1 Recabar mejoras sugeridas

SP 2.2 Analizar mejoras sugeridas

SP 2.3 Validar mejoras

SP 2.4 Seleccionar e implementar mejoras para su despliegue

SG 3 Desplegar mejoras

SP 3.1 Planificar el despliegue

SP 3.2 Gestionar el despliegue

SP 3.3 Evaluar los efectos de la mejora


SG 1 Gestionar el rendimiento del negocio

El rendimiento del negocio de la organización se gestiona utilizando técnicas estadísticas y otras técnicas cuantitativas para entender las carencias en el rendimiento de procesos y para identificar áreas de mejora de procesos.

La gestión del rendimiento del negocio requiere:

Mantener los objetivos de negocio de la organización.

Entender la capacidad de la organización para cumplir los objetivos de

negocio.

Mejorar continuamente los procesos relacionados para lograr los




La organización utiliza líneas base de rendimiento de procesos definidas

con el fin de determinar si los objetivos de negocio de la organización

actuales y previstos se están cumpliendo. Las carencias en el rendimiento

de procesos se identifican y se analizan para determinar áreas potenciales

de mejora de procesos.



Procesos.

A medida que la organización mejora su rendimiento de procesos o que

cambian las estrategias de negocio se identifican nuevos objetivos de

negocio y se derivan los objetivos de calidad y rendimiento de procesos

asociados.

La meta específica 2 trata sobre recabar y analizar las mejoras sugeridas

que aborden las carencias en la consecución de los objetivos de calidad y


SP 1.1 Mantener los objetivos de negocio

Mantener los objetivos de negocio en base a entender las

estrategias de negocio y los resultados del rendimiento real.

Los datos de rendimiento organizativo, caracterizados por las líneas base

de rendimiento de procesos, se utilizan para evaluar si los objetivos de

negocio son realistas y están alineados con las estrategias de negocio.

Una vez que la dirección ha actualizado y priorizado los objetivos de

negocio, puede que sea necesario crear o mantener objetivos de calidad y

rendimiento de procesos y volver a comunicarlos.


1. Objetivos de negocio actualizados.

2. Objetivos de calidad y rendimiento de procesos actualizados.

3. Aprobación de los objetivos de negocio y de los objetivos de calidad y

rendimiento de procesos actualizados por parte de la dirección.

4. Comunicación de todos los objetivos actualizados.

5. Medidas de rendimiento de procesos actualizadas.

Subprácticas

1. Evaluar los objetivos de negocio periódicamente para asegurar que

estén alineados con las estrategias de negocio.

La dirección es responsable de conocer el mercado, establecer las estrategias de

negocio, y establecer los objetivos de negocio.

Dado que las estrategias de negocio y el rendimiento de la organización evolucionan,

los objetivos de negocio deberían revisarse periódicamente para determinar si deben

actualizarse. Por ejemplo, un objetivo de negocio podría eliminarse si los datos de

rendimiento de procesos muestran que el objetivo de negocio se está cumpliendo con

regularidad a lo largo del tiempo, o si la estrategia de negocio asociada ha cambiado.



2. Comparar los objetivos de negocio con los resultados de rendimiento

de procesos actuales para asegurar que son realistas.

Los objetivos de negocio pueden poner el listón demasiado alto para motivar una

mejora real. Utilizar líneas base de rendimiento de procesos ayuda a equilibrar los

deseos con la realidad.

Si no se dispone de líneas base de rendimiento de procesos, se pueden utilizar

técnicas de muestreo para desarrollar en poco tiempo una base cuantitativa para la

comparación.

3. Priorizar los objetivos de negocio en base a criterios documentados,

tales como la capacidad de conseguir nuevos negocios, retener a los

clientes existentes, o conseguir otras estrategias de negocio claves.

4. Mantener los objetivos de calidad y rendimiento de procesos para

abordar los cambios en los objetivos de negocio.

Los objetivos de negocio y los objetivos de calidad y rendimiento de procesos

habitualmente evolucionarán con el tiempo. A medida que se logran los objetivos

existentes, éstos se monitorizarán para asegurar que se siguen cumpliendo, al tiempo

que se identifican y gestionan nuevos objetivos de negocio y sus objetivos de calidad

y rendimiento de procesos asociados.

Xd19 Para más información sobre establecer objetivos de calidad y



5. Actualizar las medidas de rendimiento de procesos para alinearlas con

los objetivos de calidad y rendimiento de procesos.

Para más información sobre establecer medidas de rendimiento de


Procesos.

SP 1.2 Analizar datos de rendimiento de procesos

Analizar los datos de rendimiento de procesos para determinar la

capacidad de la organización para cumplir los objetivos de

negocio identificados.

Los datos que resulten de aplicar las medidas de rendimiento de procesos,

que se definieron utilizando los procesos de Rendimiento Organizativo de

Procesos, se analizan para crear líneas base de rendimiento de procesos

que ayuden a entender cuál es la capacidad actual de la organización.

Comparar las líneas base de rendimiento de procesos con los objetivos de

calidad y rendimiento de procesos ayuda a que la organización determine

su capacidad para cumplir los objetivos de negocio. Estos datos

habitualmente son recogidos desde el nivel de datos de rendimiento de

procesos de los grupos de trabajo o proyectos con el fin de posibilitar el

análisis organizativo.


1. Análisis de la capacidad actual frente a los objetivos de negocio.

2. Carencias de rendimiento de procesos.



3. Riesgos asociados al logro de los objetivos de negocio.

Subprácticas

1. Comparar periódicamente los objetivos de calidad y rendimiento de

procesos con las líneas base de rendimiento de procesos actuales con

objeto de evaluar la capacidad de la organización de cumplir sus


Por ejemplo, si el tiempo de ciclo es una necesidad critica de negocio, la organización

puede recoger muchas medidas de tiempo de ciclo. Los datos globales de rendimiento

sobre tiempo de ciclo deberían compararse con los objetivos de negocio para

entender si el rendimiento esperado satisfará los objetivos de negocio.

2. Identificar las carencias en las que el rendimiento de procesos real no

satisfagan los objetivos de negocio.

3. Identificar y analizar los riesgos asociados con no lograr los objetivos

de negocio.

4. Comunicar a la dirección de la organización los resultados de los

análisis de rendimiento de procesos y de riesgos.

SP 1.3 Identificar áreas de mejora potenciales

Identificar áreas de mejora potenciales que pudieran contribuir al

logro de los objetivos de negocio.

Las áreas de mejora potenciales se identifican mediante el análisis

proactivo con el fin de determinar las áreas que pudieran tratar las

carencias en el rendimiento de procesos. Los procesos de Análisis Causal

y Resolución se pueden utilizar para diagnosticar y resolver causas raíces.

El resultado de esta actividad se usa para evaluar y priorizar las mejoras

potenciales, y puede dar como resultado mejoras sugeridas incrementales

o innovadoras según se describe en la meta específica 2.


1. Áreas de mejora potenciales.

Subprácticas

1. Identificar áreas de mejora potenciales en base a analizar las

carencias en el rendimiento de procesos.

Las carencias en el rendimiento incluyen incumplir los objetivos de productividad,

tiempo de ciclo, o satisfacción de clientes. Algunos ejemplos de áreas de mejora a

tener en cuenta son: la tecnología del producto, la tecnología de procesos, la

contratación y el desarrollo del personal, las estructuras de los equipos, la selección y

gestión de suministradores, y otras infraestructuras organizativas.

2. Documentar la justificación de las áreas de mejora potenciales,

incluyendo referencias a los objetivos de negocio y a los datos de

rendimiento de procesos aplicables.

3. Documentar los costes y beneficios previstos asociados a tratar las

áreas de mejora potenciales.



4. Comunicar el conjunto de áreas de mejora potenciales para su

posterior evaluación, priorización, y uso.

SG 2 Seleccionar mejoras

Se identifican mejoras proactivamente, se evalúan utilizando técnicas estadísticas y otras técnicas cuantitativas, y se seleccionan para su despliegue en base a su contribución al logro de los objetivos de calidad y rendimiento de procesos.

Las mejoras que se van a desplegar en toda la organización se

seleccionan de entre las mejoras sugeridas cuya eficacia ha sido evaluada

en el entorno de despliegue destino. Estas mejoras sugeridas se recaban y

remiten desde toda la organización para tratar las áreas de mejora

identificadas en la meta específica 1.

Las evaluaciones de mejoras sugeridas se basan en:

Conocer cuantitativamente la calidad y rendimiento de procesos

actuales de la organización.

Satisfacer los objetivos de calidad y rendimiento de procesos de la

organización.

Estimar los costes e impactos de desarrollar y desplegar mejoras, los

recursos, y la financiación disponible para el despliegue.

Estimar los beneficios en la calidad y rendimiento de procesos

resultante de desplegar las mejoras.

SP 2.1 Recabar mejoras sugeridas

Recabar y categorizar mejoras sugeridas.

Esta práctica se centra en recabar mejoras sugeridas, e incluye categorizar

las mejoras sugeridas como incrementales o innovadoras.

Las mejoras incrementales generalmente se originan por quienes hacen el

trabajo (es decir, usuarios de los procesos o de la tecnología). Implementar

y desplegar mejoras incrementales puede ser sencillo y económico. Las

mejoras sugeridas incrementales se analizan, pero, si se seleccionan,

puede que no requieran de una validación rigurosa o de un piloto. Las

mejoras innovadoras tales como nuevos procesos o procesos rediseñados

son más transformadoras que las mejoras incrementales.

Las mejoras innovadoras con frecuencia surgen de una búsqueda

sistemática de soluciones a problemas concretos de rendimiento o de

oportunidades para mejorar el rendimiento. Estas mejoras se identifican por

quienes tienen capacitación y experiencia en la evolución de determinadas

tecnologías, o por aquellos cuyo trabajo consiste en seguir el rendimiento o

contribuir directamente a aumentarlo.

Se pueden encontrar innovaciones externamente monitorizando

activamente innovaciones utilizadas en otras organizaciones o

documentadas en publicaciones de investigación. También se pueden

encontrar innovaciones internamente (p. ej., examinando las lecciones

aprendidas de los proyectos). Las innovaciones están motivadas por la



necesidad de lograr los objetivos de calidad y rendimiento de procesos, la

necesidad de mejorar las líneas base de rendimiento, o por el entorno

externo del negocio.

Algunos ejemplos de mejoras incrementales son:

Añadir un elemento a una lista de comprobación de revisión entre pares.

Aunar la revisión técnica y la revisión de gestión en una sola revisión para

suministradores.

Incorporar una solución temporal de incidencias.

Sustituir un nuevo componente.

Llevar a cabo actualizaciones menores en una herramienta

Algunas mejoras sugeridas pueden recibirse en forma de propuestas (p. ej.

una propuesta de mejora organizativa surgida de una actividad de análisis

causal y resolución). Estas mejoras sugeridas vendrán ya analizadas y

documentadas antes de entrar en los procesos de Gestión del Rendimiento

Organizativo. Cuando se reciben mejoras sugeridas en forma de

propuestas, las propuestas se revisan para comprobar que son completas

y se evalúan como parte del proceso de selección para su implementación.

La búsqueda de mejoras puede implicar que se busque fuera de la

organización, que se deriven innovaciones de los grupos que usan los

procesos de Análisis Causal y Resolución, que se utilice la inteligencia

competitiva empresarial, o que se analice el rendimiento organizativo

actual.


1. Mejoras sugeridas incrementales.

2. Mejoras sugeridas innovadoras.

Subprácticas

1. Recabar mejoras sugeridas.

Estas sugerencias documentan mejoras potenciales a los procesos y las tecnologías.

Las sugerencias pueden ser remitidas por los gerentes y el personal de la

organización, así como por los clientes, los usuarios finales, y los suministradores. La

organización también puede buscar mejoras sugeridas en las comunidades

académica y tecnológica. Algunas mejoras sugeridas pueden haberse implementado

a nivel de grupo de trabajo o proyecto antes de ser propuestas para la organización.



Algunos ejemplos de fuentes de mejoras son:

Hallazgos y recomendaciones de las evaluaciones de procesos.

Los objetivos de calidad y rendimiento de procesos de la organización.

Análisis de datos sobre problemas con clientes y usuarios finales así como sobre satisfacción de los clientes y usuarios finales.

Resultados de las labores comparativas de procesos y productos.

Eficacia medida de las actividades de proceso.

Eficacia medida de los entornos de trabajo.

Ejemplos de mejoras que fueron adoptadas con éxito en otros lugares.

Realimentación sobre mejoras previas.

Ideas espontáneas de la gerencia y el personal.

Propuestas de mejora de los procesos de Análisis Causal y Resolución resultado de las acciones implementadas que hayan demostrado su eficacia.

Análisis de datos sobre qué calidad es aceptable.

Análisis de medidas de rendimiento del sistema de servicio y medidas de prestación de servicios.

Análisis del rendimiento de los grupos de trabajo y el rendimiento organizativo comparado con los objetivos de calidad y productividad.

Para más información sobre desplegar activos de proceso

organizativos e incorporar experiencias, consúltese el área de proceso

Enfoque Organizativo en Procesos.

2. Identificar las mejoras sugeridas como incrementales o innovadoras.

3. Investigar mejoras innovadoras que puedan mejorar los procesos y las

tecnologías de la organización.

Investigar mejoras innovadoras habitualmente engloba:

Estar al corriente de trabajos técnicos destacados y tendencias tecnológicas.

Buscar mejoras innovadoras disponibles en el mercado.

Recopilar propuestas de mejora innovadoras de los grupos de trabajo y de la organización.

Revisar los procesos y tecnologías usados externamente y compararlos con los procesos y tecnologías usados en la organización.

Identificar áreas en las que se hayan utilizado con éxito mejoras innovadoras, y revisar los datos y documentación sobre las experiencias al utilizar estas mejoras.

Identificar mejoras que integren nuevas tecnologías en los productos y entornos de trabajo.

SP 2.2 Analizar mejora sugeridas

Analizar el impacto potencial que las mejoras sugeridas tienen

sobre el logro de objetivos de calidad y rendimiento de procesos




Las mejoras sugeridas son mejoras incrementales e innovadoras que se

analizan y que pueden seleccionarse para su validación, implementación, y

despliegue en toda la organización.


1. Propuestas de mejora sugeridas.

2. Mejoras seleccionadas para su validación.

Subprácticas

1. Analizar los costes y beneficios de las mejoras sugeridas.

Los modelos de rendimiento de procesos proporcionan información sobre el efecto en

la capacidad y rendimiento de procesos que tienen los cambios al proceso.

Para más información sobre establecer modelos de rendimiento de


Procesos.

Las mejoras sugeridas que tengan una relación coste/beneficio elevada o que no

mejorarían los procesos de la organización se pueden rechazar.

Algunos criterios para evaluar los costes y beneficios son:

Contribución al logro de los objetivos de calidad y rendimiento de procesos de la organización.

Efecto sobre la mitigación de riesgos de los grupos de trabajo y riesgos organizativos identificados.

Capacidad para responder con rapidez a cambios en los requisitos del trabajo, las situaciones del mercado, y el entorno de negocio.

Efecto sobre los procesos relacionados y sus activos asociados.

Coste de definir y recopilar datos que den soporte a la medición y análisis de las mejoras de procesos y tecnologías.

Esperanza de vida de la mejora.

2. Identificar las barreras potenciales y los riesgos de desplegar cada

mejora sugerida.

Algunos ejemplos de barreras al desplegar mejoras son:

Posicionamientos territoriales y localistas.

Justificaciones de negocio poco claras o débiles.

Ausencia de beneficios y éxitos visibles a corto plazo.

Falta de claridad sobre lo que se espera de cada persona.

Demasiados cambios a un mismo tiempo.

Falta de involucración y soporte de las partes interesadas relevantes.



Algunos ejemplos de factores de riesgo que afectan al despliegue de las mejoras son:

Compatibilidad de la mejora con los procesos, valores, y cualificación de los potenciales usuarios finales existentes.

Complejidad de la mejora.

Dificultad para implementar la mejora.

Capacidad de demostrar el valor de la mejora antes de desplegarla globalmente.

Justificación por anticipado de grandes inversiones en áreas tales como herramientas y capacitación.

Incapacidad para superar la “resistencia a la tecnología” cuando haya una base instalada de usuarios finales amplia y madura que esté usando con éxito la implementación actual.

3. Estimar el coste, el esfuerzo, y los plazos requeridos para

implementar, verificar, y desplegar cada mejora sugerida.

4. Seleccionar las mejoras sugeridas que se validan y que podrían

implementarse y desplegarse en base a las evaluaciones.





5. Documentar en una propuesta de mejora los resultados de la

evaluación de cada mejora sugerida seleccionada.

La propuesta debería incluir una descripción del problema, un plan para implementar

la mejora (incluyendo costes y plazos, tratamiento de riesgos, métodos para evaluar la

eficacia en el entorno de destino), y los criterios cuantitativos de éxito para evaluar los

resultados reales del despliegue.

6. Determinar el detalle de los cambios que se necesitan para

implementar la mejora y documentarlos en la propuesta de mejora.

7. Determinar el método de validación que se utilizará antes del

despliegue global del cambio y documentarlo en la propuesta de

mejora.

Determinar el método de validación incluye definir los criterios cuantitativos de éxito que se utilizarán para evaluar los resultados de la validación.

La mayoría de las mejoras innovadoras se pilotarán, dado que las innovaciones, por definición, representan un cambio importante con alto impacto. Se pueden utilizar según sea apropiado otros métodos de validación, incluyendo el modelado y simulación.

8. Documentar los resultados del proceso de selección.

Los resultados del proceso de selección usualmente incluyen:

Decisión de qué hay que hacer con cada mejora sugerida.

Justificación de qué hay que hacer con cada mejora sugerida.



SP 2.3 Validar mejoras

Validar las mejoras seleccionadas.

Las mejoras seleccionadas se validan conforme a sus propuestas de

mejora respectivas.

Algunos ejemplos de métodos de validación son:

Debates con las partes interesadas, quizás en el contexto de una revisión formal.

Demostraciones de prototipos.

Pilotos de las mejoras sugeridas.

Modelado y simulación.

Se pueden llevar a cabo pilotos para evaluar los cambios significativos que

afecten a mejoras no probadas, de alto riesgo, o innovadoras, antes de que

se desplieguen globalmente. No todas las mejoras necesitan la rigurosidad

de un piloto. Se definen y utilizan criterios para seleccionar las mejoras que

han de pilotarse. La necesidad de pilotar la mejora vendrá determinada por

factores tales como el riesgo, la naturaleza transformadora del cambio, o el

número de áreas funcionales afectadas.

Se pueden poner a disposición del piloto documentos de proceso

esbozados o con correcciones anotadas.


1. Planes de validación.

2. Informes de evaluación de la validación.

3. Lecciones aprendidas documentadas de la validación.

Subprácticas

1. Planificar la validación.

Los criterios de éxito cuantitativos documentados en la propuesta de mejora pueden

ser útiles cuando se planifica la validación.

Los planes de validación para las mejoras seleccionadas que han de pilotarse

deberían incluir a los grupos de trabajo que son objeto, las características del trabajo,

los plazos para reportar los resultados, y las actividades de medición.

2. Revisar y acordar los planes de validación con las partes interesadas

relevantes.

3. Consultar y ayudar a quienes realizan la validación.

4. Para las mejoras seleccionadas que se van a pilotar, crear una

implementación de prueba conforme al plan de validación.

5. Realizar cada validación en un entorno que sea similar al entorno en el

que se realizará el despliegue global.

6. Seguir la validación frente a los planes de validación.

7. Revisar y documentar los resultados de la validación.



Los resultados de la validación se evalúan utilizando los criterios cuantitativos

definidos en la propuesta de mejora.

Revisar y documentar los resultados de los pilotos habitualmente engloba las siguientes actividades:

Revisar los resultados del piloto con las partes interesadas.

Decidir si hay que poner fin al piloto, rehacer la implementación de la mejora, replanificar y continuar con el piloto, o proceder con el despliegue.

Actualizar la decisión sobre qué hay que hacer con las propuestas de mejora asociadas al piloto.

Identificar y documentar nuevas propuestas de mejora según sea apropiado.

Identificar y documentar las lecciones aprendidas y los problemas encontrados en el piloto, incluyendo la realimentación del equipo de mejora y los cambios a la mejora.

SP 2.4 Seleccionar e implementar mejoras para su despliegue

Seleccionar e implementar mejoras para su despliegue en toda la

organización en base a evaluar los costes, beneficios, y otros

factores.

La selección de mejoras sugeridas para su despliegue está basada en las

ratios coste/beneficio en relación a los objetivos de calidad y rendimiento

de procesos, los recursos disponibles, y los resultados de las actividades

de evaluación y validación de las propuestas de mejora.






1. Mejoras seleccionadas para su despliegue.

2. Documentación y capacitación de proceso actualizadas.

Subprácticas

1. Priorizar las mejoras para su despliegue.

La prioridad de una mejora se basa en evaluar su ratio estimada de coste/beneficio en

relación a los objetivos de calidad y rendimiento de procesos en comparación con las

líneas base de rendimiento. El retorno de inversión se puede utilizar como base para

la comparación.

2. Seleccionar las mejoras que se van a desplegar.

La selección de mejoras para su despliegue se basa en las prioridades, los recursos

disponibles, y los resultados de las actividades de evaluación y validación de las

propuestas de mejora.

3. Determinar el modo de desplegar cada mejora.



Algunos ejemplos sobre dónde se pueden desplegar mejoras son:

Entornos de trabajo singulares o comunes.

Líneas de servicio.

Servicios de la organización.

Grupos organizativos.

4. Documentar los resultados del proceso de selección.

Los resultados del proceso de selección habitualmente incluyen:

Los criterios de selección para las mejoras sugeridas.

Las características de los trabajos a los que están destinadas.

La decisión de qué hay que hacer con cada propuesta de mejora.

La justificación de qué hay que hacer con cada propuesta de mejora.

5. Revisar cualquier cambio que se necesite para implementar las

mejoras.

Algunos ejemplos de cambios que se necesitan para desplegar una mejora son:

Descripciones de proceso, estándares, y procedimientos.

Entornos de trabajo.

Formación y capacitación.

Habilidades.

Compromisos existentes.

Actividades existentes.

Soporte continuo a los usuarios finales.

Cultura y características organizativas.

6. Actualizar los activos de proceso organizativos.

La actualización de los activos de proceso organizativos habitualmente incluye revisarlos,

conseguir que se aprueben, y comunicarlos.

Para más información sobre establecer activos de proceso

organizativos, consúltese el área de proceso Definición Organizativa

de Procesos.

SG 3 Desplegar mejoras

Se despliegan mejoras medibles a los procesos y tecnologías de la organización, y se evalúan utilizando técnicas estadísticas y otras técnicas cuantitativas.

Una vez que se han seleccionado las mejoras para su despliegue, se crea

y ejecuta un plan de despliegue. Se gestiona el despliegue de las mejoras

y los efectos de las mejoras se miden y evalúan para determinar el grado

en que contribuyen al cumplimiento de los objetivos de calidad y




Si la mejora desplegada implica cambios significativos al sistema de

servicio, entonces el despliegue probablemente incluirá prácticas

requeridas en Transición del Sistema de Servicio.

Para más información sobre desplegar componentes de sistema de

servicio, consúltese el área de proceso Transición del Sistema de Servicio.

SP 3.1 Planificar el despliegue

Establecer y mantener planes de despliegue de las mejoras

seleccionadas.

Los planes de despliegue de las mejoras seleccionadas se pueden incluir

en el plan de gestión del rendimiento organizativo, en las propuestas de

mejora, o en documentos de despliegue separados.

Esta práctica específica complementa la práctica específica Desplegar los

activos de proceso organizativos del área de proceso Enfoque Organizativo

en Procesos e incorpora el uso de datos cuantitativos para guiar el

despliegue y para determinar el valor de las mejoras.

Para más información sobre desplegar activos de proceso organizativos e

incorporar experiencias, consúltese el área de proceso Enfoque

Organizativo en Procesos.


1. Planes de despliegue de las mejoras seleccionadas.

Subprácticas

1. Determinar el modo en que cada mejora debería ajustarse para su

despliegue.

Las mejoras identificadas en un contexto limitado (p.ej., una propuesta de mejora

individual) podrían necesitar modificaciones para poder ser aplicadas en una parte

seleccionada de la organización.

2. Identificar las estrategias para tratar las barreras potenciales para el

despliegue de cada mejora que se definieron en las propuestas de

mejora.

3. Identificar los trabajos a los que se destina el despliegue de la mejora.

No todos los trabajos son buenos candidatos para todas las mejoras. Por ejemplo, las

mejoras pueden estar destinadas sólo a proyectos de software, a proyectos de

integración de componentes comerciales (COTS), o a trabajos de prestación de

servicios.

4. Establecer medidas y objetivos para determinar el valor de cada

mejora en relación a los objetivos de calidad y rendimiento de


Las medidas pueden basarse en los criterios cuantitativos de éxito documentados en

la propuesta de mejora o derivarse de los objetivos organizativos.



Algunos ejemplos de medidas para determinar el valor de una mejora son:

Mejora medida en el rendimiento de procesos del trabajo o la organización.

Tiempo para recuperar el coste de la mejora.

Número y tipos de riesgos del trabajo o riesgos organizativos mitigados por la mejora de proceso o tecnología.

Tiempo medio requerido para dar respuesta a los cambios en los requisitos del trabajo, las situaciones del mercado, y el entorno de negocio.

Para más información sobre alinear las actividades de medición y

análisis y proporcionar resultados de medición, consúltese el área de


5. Documentar los planes de despliegue de las mejoras seleccionadas.

Los planes de despliegue deberían incluir a las partes interesadas relevantes, las

estrategias de riesgo, los trabajos a los que se destinan, las medidas del éxito, y los

plazos.

6. Revisar y acordar con las partes interesadas relevantes los planes de

despliegue de las mejoras seleccionadas.

Las partes interesadas relevantes incluyen al patrocinador de la mejora, a los grupos

de trabajo que son objeto de la mejora, a las organizaciones de soporte, etc.

7. Actualizar los planes de despliegue de las mejoras seleccionadas

según se necesite.

SP 3.2 Gestionar el despliegue

Gestionar el despliegue de las mejoras seleccionadas.

Esta práctica específica se puede solapar con la práctica específica

Implementar las propuestas de acción en el área de proceso Análisis

Causal y Resolución (p. ej. cuando el análisis causal y resolución se utiliza

organizativamente o transversalmente a varios grupos de trabajo).


1. Materiales de capacitación actualizados (para reflejar las mejoras

desplegadas).

2. Resultados documentados de las actividades de despliegue de

mejoras.

3. Medidas de mejora, objetivos, prioridades, y planes de despliegue

actualizados.

Subprácticas

1. Monitorizar el despliegue de las mejoras utilizando los planes de

despliegue.

2. Coordinar el despliegue de las mejoras en toda la organización.

Coordinar el despliegue incluye las siguientes actividades:

Coordinar las actividades de los grupos de trabajo, grupos de soporte, y grupos organizativos para cada mejora.



Coordinar las actividades de despliegue de mejoras relacionadas.

3. Desplegar las mejoras de manera controlada y disciplinada.

Algunos ejemplos de métodos para desplegar mejoras son:

Desplegar mejoras incrementalmente en vez de en un único despliegue.

Proporcionar consultoría de manera amplia a los primeros en adoptar la mejora en lugar de capacitación formal actualizada.

4. Coordinar el despliegue de las mejoras sobre los procesos definidos

para el trabajo según sea apropiado.

Para más información sobre desplegar activos de proceso

organizativos e incorporar experiencias, consúltese el área de proceso

Enfoque Organizativo en Procesos.

5. Proporcionar consultoría según se apropiado para dar soporte al

despliegue de las mejoras.

6. Proporcionar materiales de capacitación actualizados o desarrollar

paquetes de comunicación que reflejen las mejoras a los activos de

proceso organizativos.

Para más información sobre proporcionar capacitación, consúltese el

área de proceso Capacitación Organizativa.

7. Confirmar que el despliegue de todas las mejoras se ha completado

de acuerdo al plan de despliegue.

8. Documentar y revisar los resultados del despliegue de mejoras.

La documentación y revisión de resultados incluye:

Identificar y documentar las lecciones aprendidas.

Revisar las medidas, objetivos, prioridades, y planes de despliegue de las mejoras.

SP 3.3 Evaluar los efectos de la mejora

Evaluar los efectos que las mejoras desplegadas tienen sobre la

calidad y el rendimiento de procesos utilizando técnicas

estadísticas y otras técnicas cuantitativas.




Esta práctica específica se puede solapar con la práctica específica

Evaluar el efecto de las acciones implementadas en el área de proceso

Análisis Causal y Resolución (p. ej. cuando el análisis causal y resolución

se aplique organizativamente o transversalmente a varios grupos de

trabajo).


1. Medidas documentadas de los efectos que resultan de las mejoras

desplegadas.



Subprácticas

1. Medir los resultados de cada mejora una vez que ha sido

implementada en los trabajos que son objeto de la mejora utilizando

para ello las medidas definidas en los planes de despliegue.

2. Medir y analizar el progreso hacia el logro de los objetivos de calidad y

rendimiento de procesos de la organización utilizando para ello

técnicas estadísticas y otras técnicas cuantitativas, y realizar acciones

correctivas según se necesite.

Para más información sobre establecer objetivos de calidad y

rendimiento de procesos y establecer líneas base y modelos de




Rendimiento Organizativo de Procesos (OPP) 277

RENDIMIENTO ORGANIZATIVO DE PROCESOS


Propósito

El propósito de Rendimiento Organizativo de Procesos (OPP) es establecer

y mantener un conocimiento cuantitativo del rendimiento de los procesos

seleccionados de entre el conjunto de procesos estándar de la

organización con el fin de dar soporte al logro de los objetivos de calidad y

rendimiento de procesos, y proporcionar datos, líneas base, y modelos de

rendimiento de procesos con los que gestionar cuantitativamente los

trabajos de la organización.


El área de proceso Rendimiento Organizativo de Procesos engloba las


Establecer objetivos cuantitativos organizativos de calidad y

rendimiento de procesos a partir de los objetivos de negocio

(véase la definición de “objetivos de calidad y rendimiento de

procesos” en el glosario).

Seleccionar los procesos o subprocesos para los análisis de


Establecer definiciones de las medidas a utilizar en los análisis

de rendimiento de procesos (véase la definición de “rendimiento

de procesos” en el glosario).

Establecer las líneas base de rendimiento de procesos y los

modelos de rendimiento de procesos (véase las definiciones de

“líneas base de rendimiento de procesos” y “modelos de

rendimiento de procesos” en el glosario).

La recogida y análisis de datos y la creación de líneas base y modelos de

rendimiento de procesos se pueden llevar a cabo a distintos niveles de la

organización, incluyendo a nivel de trabajos concretos o de conjuntos de

trabajos relacionados según sea apropiado en base a las necesidades de

los trabajos y la organización.

Las medidas comunes de la organización constan de medidas de proceso

y medidas de producto que se pueden utilizar para caracterizar el

rendimiento real de los procesos en los trabajos de la organización. Al

analizar las mediciones resultantes, se puede establecer una distribución o

un rango de resultados que caracterice el rendimiento esperado del

proceso cuando se utiliza para realizar un trabajo concreto.

Medir la calidad y el rendimiento de los procesos puede implicar combinar

medidas existentes para obtener medidas derivadas adicionales que



proporcionen una visión más a fondo de la eficiencia y eficacia global a

nivel de trabajo concreto o a nivel de organización. El análisis a nivel de

organización puede utilizarse para estudiar la productividad, mejorar

eficiencias, e incrementar la capacidad productiva de todos los trabajos de

la organización.

El rendimiento de procesos esperado se puede utilizar para establecer los

objetivos de calidad y rendimiento de procesos para el trabajo y como línea

base con la que comparar el rendimiento real. Esta información se utiliza

para gestionar cuantitativamente los trabajos. Cada trabajo que se gestiona

cuantitativamente, a su vez, proporciona resultados reales de rendimiento

que pasarán a formar parte de los activos de proceso organizativos que se

pondrán a disposición de todos los grupos de trabajo.

Los modelos de rendimiento de procesos se utilizan para representar el

rendimiento pasado y actual del proceso y para predecir los resultados

futuros. Por ejemplo, los defectos latentes en el producto entregado

pueden predecirse utilizando mediciones de atributos de producto de

trabajo, tales como la complejidad, y mediciones de atributos de proceso,

tales como el tiempo de preparación de las revisiones entre pares.

Cuando la organización tiene suficientes medidas, datos, y técnicas

analíticas sobre las características críticas del proceso, producto, y

servicio, ésta es capaz de hacer lo siguiente:

Determinar si los procesos se comportan consistentemente o tienen

tendencias estables (esto es, si son predecibles).

Identificar procesos cuyo rendimiento esté dentro de los límites

naturales que son coherentes entre los distintos trabajos y que

potencialmente pudieran agregarse.

Identificar procesos que muestren un comportamiento inusual (p. ej.

esporádico, impredecible).

Identificar aspectos de los procesos que puedan mejorarse en el


Identificar la implementación del proceso que funciona mejor.

Esta área de proceso se interrelaciona y da soporte a la implementación de

otras áreas de proceso de alta madurez. Los activos que se establecen y

mantienen como parte de implementar esta área de proceso (p. ej. las

medidas a utilizar para caracterizar el comportamiento de los subprocesos,

las líneas base de rendimiento de procesos, los modelos de rendimiento de

procesos) son entradas a los procesos de gestión cuantitativa de trabajos,

análisis causal y resolución, y gestión del rendimiento organizativo, dando

soporte a los análisis descritos allí. Los procesos de gestión cuantitativa de

trabajos proporcionan los datos de calidad y rendimiento de procesos que

se necesitan para mantener los activos descritos en esta área de proceso.




Para más información sobre asegurar que el rendimiento del sistema de

servicio sea eficaz y que los recursos se provean y utilicen eficazmente

para dar soporte a los requisitos del servicio, consúltese el área de proceso

Gestión de Capacidad y Disponibilidad.

Para más información sobre establecer y mantener servicios estándar



Para más información sobre especificar medidas, obtener datos de

mediciones, y analizar mediciones, consúltese el área de proceso Medición

y Análisis.

Para más información sobre gestionar proactivamente el rendimiento de la

organización para que logre sus objetivos de negocio, consúltese el área






SG 1 Establecer líneas base y modelos de rendimiento

SP 1.1 Establecer objetivos de calidad y rendimiento de procesos

SP 1.2 Seleccionar procesos

SP 1.3 Establecer medidas de rendimiento de procesos

SP 1.4 Analizar el rendimiento y establecer líneas base de rendimiento de procesos

SP 1.5 Establecer modelos de rendimiento de procesos


SG 1 Establecer líneas base y modelos de rendimiento

Se establecen y mantienen líneas base y modelos que caracterizan el rendimiento de procesos que se espera del conjunto de procesos estándar de la organización.

Antes de establecer líneas base y modelos de rendimiento de procesos, es

necesario determinar los objetivos de calidad y rendimiento de procesos

para esos procesos (práctica específica Establecer objetivos de calidad y

rendimiento de procesos), qué procesos son adecuados para su medición

(práctica específica Seleccionar procesos), y qué medidas son útiles para

determinar el rendimiento de procesos (práctica específica Establecer

medidas de rendimiento de procesos).

Las tres primeras prácticas de esta meta están interrelacionadas y

frecuentemente se necesitan ejecutar de forma simultánea e iterativa con

objeto de seleccionar los objetivos de calidad y rendimiento de procesos,

los procesos, y las medidas. A menudo, seleccionar un objetivo de calidad

y rendimiento de procesos, un proceso, o una medida será una restricción

para seleccionar los demás. Por ejemplo, si se selecciona un objetivo de

calidad y rendimiento de procesos relacionado con los defectos en las



entregas al cliente, casi con total seguridad será necesario que se

seleccionen los procesos de verificación y las medidas relacionadas con

defectos.

El propósito de esta meta es proporcionar los modelos y las líneas base de

rendimiento de procesos que los grupos de trabajo necesiten para llevar a

cabo la gestión cuantitativa de trabajos. Muchas veces, estas líneas base y

modelos son recopilados o creados por la organización, pero hay

circunstancias en las que un grupo de trabajo puede necesitar crear sus

propias líneas base y sus propios modelos. Estas circunstancias incluyen

trabajos no cubiertos por las líneas base y modelos de la organización. En

estos casos, el grupo de trabajo sigue las prácticas de esta meta para crear

sus líneas base y sus modelos.

SP 1.1 Establecer objetivos de calidad y rendimiento de procesos

Establecer y mantener los objetivos cuantitativos de calidad y

rendimiento de procesos de la organización, los cuales son

trazables a los objetivos de negocio.

Los objetivos de calidad y rendimiento de procesos de la organización se

pueden establecer a distintos niveles de la estructura organizativa (p. ej.

área de negocio, línea de producto, función, proyecto, trabajo), así como a

distintos niveles en la jerarquía de procesos. Al establecer los objetivos de

calidad y rendimiento de procesos, considere lo siguiente:

Trazabilidad a los objetivos de negocio de la organización.

Rendimiento histórico de los procesos o subprocesos seleccionados en

contexto (p. ej., en proyectos, en trabajos).

Distintos atributos de rendimiento de procesos (p. ej., calidad del

producto, productividad, tiempo de ciclo, tiempo de respuesta).

Variabilidad inherente o límites naturales de los procesos o

subprocesos seleccionados.

Los objetivos de calidad y rendimiento de procesos de la organización

enfocan y dirigen las actividades de análisis de rendimiento de procesos y

de gestión cuantitativa de trabajos. Sin embargo, cabe señalar que la

consecución de los objetivos de calidad y rendimiento de procesos que

sean significativamente diferentes de la capacidad del proceso actual

requiere el uso de técnicas que se encuentran en Análisis Causal y

Resolución y en Gestión del Rendimiento Organizativo.


1. Objetivos de calidad y rendimiento de procesos de la organización.

Subprácticas

1. Revisar los objetivos de negocio de la organización relacionados con

la calidad y rendimiento de procesos.



Algunos ejemplos de objetivos de negocio son:

Entregar los productos a tiempo y dentro del presupuesto.

Mejorar la calidad del producto en un porcentaje específico dentro de un periodo de tiempo específico.

Mejorar la productividad en un porcentaje específico dentro de un periodo de tiempo específico.

Mantener las calificaciones de satisfacción de clientes.

Mejorar el plazo de comercialización de nuevos productos o servicios en un porcentaje específico dentro de un periodo de tiempo específico.

Reducir la funcionalidad diferida del producto en un porcentaje específico dentro de un periodo de tiempo específico.

Reducir la tasa de devoluciones de productos en un porcentaje específico dentro de un período de tiempo específico.

Reducir el coste total de propiedad del cliente en un porcentaje específico dentro de un periodo de tiempo específico.

Disminuir el coste de mantenimiento del legado de productos en un porcentaje específico dentro de un periodo de tiempo específico.

2. Definir los objetivos cuantitativos de calidad y rendimiento de procesos


Los objetivos de calidad y rendimiento de procesos se pueden establecer para

mediciones de proceso o de subproceso (p. ej., esfuerzo, tiempo del ciclo, eficacia en

la eliminación de defectos), así como para las mediciones de producto (p. ej.,

fiabilidad, densidad de defectos) y para las mediciones de servicios (p. ej., capacidad,

tiempos de respuesta), según sea apropiado.

Algunos ejemplos de objetivos de calidad y rendimiento de procesos son:

Lograr un valor deseado para la tasa de defectos no eliminados, la productividad, la duración, la capacidad, o el coste.

Mejorar en un porcentaje específico de la línea base de rendimiento de procesos y dentro de un periodo de tiempo específico la tasa de defectos no eliminados, la productividad, la duración, la capacidad, o el rendimiento en costes.

Mejorar en un porcentaje específico de la línea base de rendimiento de procesos y dentro de un período de tiempo específico el rendimiento del acuerdo de nivel de servicio.

3. Definir prioridades para los objetivos de calidad y rendimiento de


4. Revisar, negociar, y obtener el compromiso de las partes interesadas

relevantes con los objetivos de calidad y rendimiento de procesos de

la organización y sus prioridades.

5. Actualizar los objetivos cuantitativos de calidad y rendimiento de

procesos de la organización según se necesite.



Algunos ejemplos sobre cuándo deberían actualizarse los objetivos cuantitativos de calidad y rendimiento de procesos de la organización son:

Cuando cambien los objetivos de negocio de la organización.

Cuando cambie el conjunto de procesos estándar de la organización.

Cuando la calidad y rendimiento de procesos reales difieran significativamente de los objetivos

SP 1.2 Seleccionar procesos

Seleccionar los procesos o subprocesos de entre el conjunto de

procesos estándar de la organización que se incluirán en los

análisis de rendimiento de procesos de la organización y mantener

su trazabilidad con los objetivos de negocio.



El conjunto de procesos estándar de la organización consta de un conjunto

de procesos estándar que se descomponen en subprocesos.

Habitualmente no es posible, ni útil, ni está justificado económicamente

aplicar técnicas de gestión estadística a todos los procesos o subprocesos

del conjunto de procesos estándar de la organización. La selección de los

procesos o subprocesos se basa en los objetivos de calidad y rendimiento

de procesos de la organización, los cuales se derivan de los objetivos de

negocio, según se describe en la práctica específica anterior.


1. Lista de procesos o subprocesos identificados para el análisis de

rendimiento de procesos con la justificación de su selección que

incluya la trazabilidad a los objetivos de negocio.

Subprácticas

1. Establecer los criterios a utilizar para seleccionar subprocesos.



Algunos ejemplos de criterios que se pueden utilizar para seleccionar procesos o subprocesos para el análisis de rendimiento de procesos a nivel de organización son:

El proceso o subproceso está fuertemente relacionado con objetivos de negocio claves.

El proceso o subproceso ha demostrado estabilidad en el pasado.

Actualmente hay datos históricos válidos disponibles que son relevantes para el proceso o subproceso.

El proceso o subproceso generará datos con frecuencia suficiente como para permitir la gestión estadística.

El proceso o subproceso contribuye de manera importante a la calidad y rendimiento de procesos.

El proceso o subproceso es importante para predecir la calidad y rendimiento de procesos.

El proceso o subproceso es un factor importante para entender los riesgos asociados con el logro de objetivos de calidad y rendimiento de procesos.

La calidad de las medidas y de las mediciones asociadas al proceso o subproceso (p. ej. error del sistema de medición) es adecuada.

Hay disponibles múltiples atributos medibles que caracterizan el comportamiento del proceso o subproceso.

2. Seleccionar los subprocesos y documentar la justificación de su

selección.

Algunos ejemplos de enfoques para identificar y evaluar alternativas de subprocesos como parte de una selección son:

Análisis causal.

Análisis de sensibilidad.





3. Establecer y mantener la trazabilidad entre los subprocesos

seleccionados, los objetivos de calidad y rendimiento de procesos, y

los objetivos de negocio.

Algunos ejemplos de cómo se puede expresar la trazabilidad son:

Correspondencia entre los subprocesos y los objetivos de calidad y rendimiento de procesos.

Flujo descendente de objetivos (p. ej. Gran Y a X Vital, planificación Hoshin).

Cuadro de mando balanceado.

Despliegue de la función calidad (Quality Function Deployment / QFD).

Meta Pregunta Métrica (Goal Question Metric).

Documentación de un modelo de rendimiento de procesos.



4. Actualizar la selección según se necesite.

Puede que sea necesario actualizar la selección cuando:

Las predicciones de los modelos de rendimiento de procesos tengan demasiada variación como para ser útiles.

Los objetivos de calidad y rendimiento de procesos cambien.

El conjunto de procesos estándar de la organización cambie.

La calidad y rendimiento de procesos subyacente cambie.

SP 1.3 Establecer medidas de rendimiento de procesos

Establecer y mantener definiciones de las medidas a incluir en los

análisis de rendimiento de procesos de la organización.




1. Definiciones de medidas de rendimiento de procesos seleccionadas

con una justificación de su selección que incluya la trazabilidad a los

procesos o subprocesos seleccionados.

Subprácticas

1. Seleccionar medidas que reflejen atributos apropiados de los procesos

o subprocesos seleccionados para proporcionar visibilidad sobre la

calidad y rendimiento de procesos de la organización.

A menudo es útil definir varias medidas para un mismo proceso o subproceso para

entender el impacto de los cambios al proceso y evitar la sub-optimización. Además, a

menudo es útil establecer medidas, tanto para los atributos de proceso como los de

producto, del proceso y subproceso seleccionado, así como para sus entradas,

salidas, y recursos consumidos (incluyendo las personas y sus habilidades).

El paradigma Meta Pregunta Métrica es un enfoque que se puede utilizar para

seleccionar medidas que ayuden a entender los objetivos de calidad y rendimiento de

procesos de la organización. A menudo es útil analizar cómo se pueden lograr estos

objetivos de calidad y rendimiento de procesos en base al conocimiento sobre el

rendimiento de procesos que proporcionan las medidas seleccionadas.

Algunos ejemplos de criterios utilizados para seleccionar las medidas son:

Relación de las medidas con los objetivos de calidad y rendimiento de procesos de la organización.

Cobertura que proporcionan las medidas sobre la vida del producto o servicio.

Visibilidad que proporcionan las medidas sobre el rendimiento de procesos

Disponibilidad de las medidas.

Frecuencia con la que se pueden recoger las observaciones de las medidas.

Grado en el que se pueden controlar las medidas cambiando el proceso o subproceso.

Grado en el que las medidas representan el punto de vista de los usuarios finales sobre lo que significa un proceso eficaz.



2. Establecer definiciones operativas de las medidas seleccionadas.

Para más información sobre especificar medidas, consúltese el área

de proceso Medición y Análisis.

3. Incorporar las medidas seleccionadas al conjunto de medidas

comunes de la organización.



de Procesos.

4. Actualizar el conjunto de medidas según se necesite.

Las medidas se evalúan periódicamente en cuanto a la continuidad de su utilidad y

capacidad para indicar la eficacia de procesos.

SP 1.4 Analizar el rendimiento y establecer líneas base de rendimiento de

procesos

Analizar el rendimiento de los procesos seleccionados, y

establecer y mantener las líneas base de rendimiento de procesos.

Las medidas seleccionadas se analizan para caracterizar el rendimiento de

los procesos o subprocesos seleccionados que se ha logrado en los

trabajos. Esta caracterización se utiliza para establecer y mantener las

líneas base de rendimiento de procesos (véase la definición de “línea base

de rendimiento de procesos” en el glosario). Estas líneas base se utilizan

para determinar los resultados esperados del proceso o subproceso

cuando se utiliza para un conjunto de trabajos bajo un conjunto dado de

circunstancias.

Las líneas base de rendimiento de procesos se comparan con los objetivos

de calidad y rendimiento de procesos de la organización para determinar si

los objetivos de calidad y rendimiento de procesos se están logrando.

Las líneas base de rendimiento de procesos son una medición del

rendimiento del conjunto de procesos estándar de la organización a

distintos niveles de detalle. Los procesos que las líneas base de

rendimiento de procesos pueden abordar son:

Secuencia de procesos conectados.

Procesos que cubran toda la vida del trabajo.

Procesos para desarrollar productos de trabajo individuales.

Puede haber varias líneas base de rendimiento de procesos para

caracterizar el rendimiento de los subgrupos de la organización.



Algunos ejemplos de criterios utilizados para categorizar los subgrupos son:

Línea de producto o servicio estándar.

Línea de negocio.

Dominio de la aplicación.

Complejidad.

Tamaño del equipo.

Tamaño del producto de trabajo.

Elementos de proceso dentro del conjunto de procesos estándar de la organización.

Adaptar el conjunto de procesos estándar de la organización puede afectar

significativamente a que los datos sean comparables al incluirlos en las

líneas base de rendimiento de procesos. Al establecer las líneas base se

deberían considerar los efectos de la adaptación. Dependiendo de la

adaptación que se permita, pueden existir líneas base de rendimiento

diferentes para cada tipo de adaptación.





1. Análisis de datos de rendimiento de procesos.

2. Datos de línea base sobre el rendimiento de procesos de la

organización.

Subprácticas

1. Recopilar las mediciones seleccionadas de los procesos y


Se registra el proceso o subproceso en uso cuando se toma la medición con objeto de

hacer posible su uso posterior.


almacenamiento de datos de mediciones, consúltese el área de


2. Analizar las medidas recogidas y establecer una distribución o rango

de resultados que caracterice el rendimiento de procesos esperado

cuando los procesos o subprocesos seleccionados se utilizan para

realizar un conjunto de trabajos.

Este análisis debería incluir la estabilidad del proceso o subproceso relacionados, y

los impactos que tienen los factores asociados y el contexto. Los factores

relacionados incluyen entradas al proceso y otros atributos que pueden afectar a los

resultados obtenidos. El contexto incluye el contexto de negocio (p. ej., el dominio) y

las adaptaciones significativas realizadas al conjunto de procesos estándar de la

organización.

Siempre que sea posible se deberían utilizar mediciones de subprocesos de trabajos

estables; otros datos pueden no ser fiables.



3. Establecer y mantener las líneas base de rendimiento de procesos a

partir de las mediciones recogidas y de los análisis.




Las líneas base de rendimiento se derivan a partir de analizar las medidas recogidas

para establecer una distribución o rango de resultados que caractericen el rendimiento

esperado de los procesos o subprocesos seleccionados cuando se utilizan en trabajos


4. Revisar y obtener el acuerdo de las partes interesadas relevantes

sobre las líneas base de rendimiento de procesos.

5. Poner la información sobre el rendimiento de procesos a disposición

de toda la organización en el repositorio de mediciones de la

organización.

Las líneas base de rendimiento de procesos de la organización son utilizadas por los

grupos de trabajo para estimar los límites naturales del rendimiento de procesos.

6. Comparar las líneas base de rendimiento de procesos con sus

objetivos asociados de calidad y rendimiento de procesos para

determinar si se están logrando dichos objetivos.

Estas comparaciones deberían utilizar técnicas estadísticas más allá de una simple

comparación de la media para evaluar el grado en que se logran los objetivos de

calidad y rendimiento de procesos. Si los objetivos de calidad y rendimiento de

procesos no se están logrando se deberían considerar acciones correctivas.



Resolución.

Para más información sobre planificar e implementar acciones de

proceso, consúltese el área de proceso Enfoque Organizativo en

Procesos.

Para más información sobre analizar datos de rendimiento e identificar

áreas de mejora potenciales, consúltese el área de proceso Gestión

del Rendimiento Organizativo.

7. Actualizar las líneas base de rendimiento de procesos según se

necesite.

Algunos ejemplos sobre cuándo puede ser necesario actualizar las líneas base de rendimiento de procesos de la organización son:

Cuando cambien los procesos.

Cuando cambien los resultados de la organización.

Cuando cambien las necesidades de la organización.

Cuando cambien los procesos de los suministradores.

Cuando cambien los suministradores.



SP 1.5 Establecer modelos de rendimiento de procesos

Establecer y mantener los modelos de rendimiento de procesos


Las organizaciones de alta madurez generalmente establecen y mantienen

un conjunto de modelos de rendimiento de procesos con varios niveles de

detalle y que cubren un rango de actividades que son comunes a toda la

organización y abordan los objetivos de calidad y rendimiento de procesos

de la organización (véase la definición de “modelo de rendimiento de

procesos” en el glosario). Bajo determinadas circunstancias, los grupos de

trabajo pueden necesitar crear sus propios modelos de rendimiento de

procesos.

Los modelos de rendimiento de procesos se utilizan para estimar o predecir

el valor de una medida de rendimiento de procesos a partir de los valores

de otras mediciones de proceso, producto, y servicio. Estos modelos de

rendimiento de procesos habitualmente utilizan mediciones de proceso y

de producto recogidas durante la vida del servicio para estimar el progreso

en la consecución de los objetivos de calidad y rendimiento de procesos

que no pueden medirse hasta más adelante en la vida del servicio.

Los modelos de rendimiento de procesos se utilizan como sigue:

La organización los utiliza para estimar, analizar, y predecir el

rendimiento de procesos asociado a los procesos en el conjunto de

procesos estándar de la organización y a los cambios en éstos.

La organización los utiliza para evaluar el retorno (potencial) de la

inversión de las actividades de mejora de procesos.

Los grupos de trabajo los utilizan para estimar, analizar, y predecir el

rendimiento de procesos de sus procesos definidos.

Los grupos de trabajo los utilizan para seleccionar los procesos o

subprocesos que se usan.

Los grupos de trabajo los utilizan para estimar el progreso hacia la

consecución de los objetivos de calidad y rendimiento de procesos.

Estas medidas y modelos se definen para proporcionar conocimiento sobre

las características críticas de los procesos y productos que son relevantes

para los objetivos de calidad y rendimiento de procesos de la organización,

y para proporcionar la habilidad de predecirlas.

Algunos ejemplos de modelos de rendimiento de procesos son:

Modelos de dinámica de sistemas

Modelos de regresión.

Modelos de complejidad.

Modelos de simulación de eventos discretos.

Modelos de simulación Monte Carlo.







1. Modelos de rendimiento de procesos.

Subprácticas

1. Establecer modelos de rendimiento de procesos basados en el

conjunto de procesos estándar y en las líneas base de rendimiento de


2. Calibrar los modelos de rendimiento de procesos en base a los

resultados pasados y a las necesidades actuales.

3. Revisar los modelos de rendimiento de procesos y obtener el acuerdo

de las partes interesadas relevantes.

4. Dar soporte a los grupos de trabajo en el uso de los modelos de


5. Actualizar los modelos de rendimiento de procesos según se necesite.

Algunos ejemplos sobre cuándo puede ser necesario actualizar los modelos de rendimiento de procesos son:

Cuando cambien los procesos.

Cuando cambien los resultados de la organización.

Cuando cambien los objetivos de calidad y rendimiento de procesos de la organización.


Capacitación Organizativa (OT) 290

CAPACITACIÓN ORGANIZATIVA


Propósito

El propósito de Capacitación Organizativa (OT) es desarrollar las

habilidades y conocimientos de las personas para que puedan desempeñar

sus roles eficaz y eficientemente.


Capacitación Organizativa aborda la capacitación impartida para dar

soporte a los objetivos estratégicos de negocio de la organización y para

cubrir las necesidades de capacitación tácticas transversales a varios

grupos de trabajo y grupos de soporte. Las necesidades de capacitación

que los grupos de trabajo y grupos de soporte identifican para cubrir sus

necesidades individuales se manejan a nivel de grupo de trabajo y de

grupo de soporte y están fuera del alcance del área de proceso

Capacitación Organizativa.

Para más información sobre planificar los conocimientos y habilidades que

se necesitan, consúltese el área de proceso Planificación de Trabajos.

Un programa de capacitación organizativa engloba las siguientes

actividades:

Identificar las necesidades de capacitación que tiene la organización.

Obtener y proporcionar capacitación para abordar dichas necesidades.

Establecer y mantener una competencia de capacitación.

Establecer y mantener registros de capacitación.

Evaluar la eficacia de la capacitación.

Capacitar eficazmente requiere que se evalúen las necesidades, la

planificación, el diseño de cursos, y los medios de capacitación apropiados

(p. ej. cuadernos de ejercicios, software), así como un repositorio de datos

de proceso sobre capacitación. Como proceso organizativo, los

componentes principales de la capacitación incluyen un programa de

desarrollo de la capacitación, planes documentados, personal con dominio

apropiado de las disciplinas y otras áreas de conocimiento, y mecanismos

para medir la eficacia del programa de capacitación.

La identificación de necesidades de capacitación sobre procesos está

basada principalmente en las habilidades que se necesitan para llevar a

cabo el conjunto de procesos estándar de la organización.





Ciertas habilidades se pueden impartir eficaz y eficientemente con medios

distintos al aprendizaje en aula (p.ej. tutoría informal). Otras habilidades

requieren medios de aprendizaje más formales, como son las clases en

aula, la capacitación basada en web, el auto-estudio guiado, o mediante un

programa formalizado de aprendizaje en el trabajo. La elección de medios

de aprendizaje formales o informales empleados para cada situación

debería estar basada en la evaluación de las necesidades de capacitación

y en las carencias en el desempeño que hay que abordar. El término

“capacitación” en esta área de proceso se utiliza de manera amplia para

incluir todas estas opciones de aprendizaje.

El éxito de la capacitación se demuestra por la disponibilidad de

oportunidades para adquirir las habilidades y conocimientos que se

necesitan para realizar actividades empresariales nuevas y en curso.

Las habilidades y conocimientos pueden ser técnicos, organizativos, o

contextuales. Las habilidades técnicas se refieren a la capacidad de utilizar

los equipos, herramientas, materiales, datos, y procesos que un trabajo o

proceso requiere. Las habilidades organizativas están relacionadas con el

comportamiento dentro y conforme a la estructura organizativa del

personal, los roles y responsabilidades, y los principios y métodos

operativos generales. Las habilidades contextuales son la autogestión, la

comunicación, y las habilidades interpersonales que se necesitan para

realizar el trabajo con éxito en el contexto organizativo y social de los

grupos de trabajo y los grupos de soporte.











SG 1 Establecer una competencia de capacitación organizativa

SP 1.1 Establecer necesidades estratégicas de capacitación

SP 1.2 Determinar las necesidades de capacitación que son responsabilidad de la organización

SP 1.3 Establecer un plan táctico organizativo de capacitación

SP 1.4 Establecer una competencia de capacitación

SG 2 Proporcionar capacitación

SP 2.1 Impartir capacitación

SP 2.2 Establecer registros de capacitación

SP 2.3 Evaluar la eficacia de la capacitación




SG 1 Establecer una competencia de capacitación organizativa

Se establece y se mantiene una competencia de capacitación, la cual da soporte a los roles de la organización.

La organización identifica la capacitación requerida para desarrollar las

habilidades y conocimientos que se necesitan para realizar las actividades

de la empresa. Una vez que se identifican las necesidades, se desarrolla

un programa de capacitación para abordarlas.

SP 1.1 Establecer necesidades estratégicas de capacitación

Establecer y mantener las necesidades estratégicas de

capacitación de la organización.

Las necesidades estratégicas de capacitación abordan los objetivos de

desarrollo de capacidades a largo plazo para cubrir carencias significativas

en los conocimientos, introducir nuevas tecnologías, o implantar grandes

cambios en los comportamientos. La planificación estratégica

habitualmente considera plazos de dos a cinco años vista.

Algunos ejemplos de fuentes de necesidades estratégicas de capacitación son:

Los procesos estándar de la organización.

El plan estratégico de negocio de la organización.

El plan de mejora de procesos de la organización.

Iniciativas a nivel de empresa.

Evaluación de habilidades.

Análisis de riesgos.

Gestión de adquisiciones y suministradores.


1. Necesidades de capacitación.

2. Análisis de evaluaciones.

Subprácticas

1. Analizar los objetivos estratégicos de negocio de la organización y el

plan de mejora de procesos para identificar necesidades de

capacitación potenciales.

2. Documentar las necesidades estratégicas de capacitación de la

organización.



Algunos ejemplos de categorías de necesidades de capacitación son:

Análisis y documentación de procesos.

Ingeniería (p. ej. análisis de requisitos, diseño, pruebas, gestión de configuración, aseguramiento de calidad).

Selección y gestión de suministradores.

Construcción de equipos.

Gestión (p. ej. estimación, seguimiento, gestión de riesgos).

Liderazgo.

Recuperación tras desastres y continuidad de las operaciones.

Habilidades de comunicación y negociación.

Prestación de servicios.

3. Determinar los roles y habilidades que se necesitan para llevar a cabo

el conjunto de procesos estándar de la organización.

4. Documentar la capacitación que se necesita para desempeñar los

roles en el conjunto de procesos estándar de la organización.

5. Documentar la capacitación que se necesita para mantener la

seguridad, protección, y continuidad de las operaciones del negocio.

6. Actualizar las necesidades estratégicas de la organización y la

capacitación requerida según se necesite.

SP 1.2 Determinar las necesidades de capacitación que son responsabilidad de

la organización

Determinar las necesidades de capacitación que son

responsabilidad de la organización y las que son responsabilidad

de los grupos de trabajo y grupos de soporte individuales.



La capacitación organizativa, además de las necesidades de capacitación

estratégicas, aborda los requisitos de capacitación comunes a varios

grupos de trabajo y grupos de soporte. Los grupos de trabajo y grupos de

soporte son los principales responsables de identificar y abordar sus

necesidades de capacitación. El personal de capacitación organizativa solo

es responsable de abordar las necesidades de capacitación transversales

a los grupos de trabajo y grupos de soporte (p. ej. capacitación en entornos

de trabajo comunes a varios grupos de trabajo). Sin embargo, en algunos

casos el personal de capacitación organizativa podría abordar necesidades

de capacitación adicionales específicas de los grupos de trabajo y grupos

de soporte, según se negocie con ellos, en el contexto de los recursos de

capacitación disponibles y las prioridades de capacitación de la

organización.




1. Necesidades de capacitación comunes a grupos de trabajo y grupos

de soporte.

2. Compromisos de capacitación.

Subprácticas

1. Analizar las necesidades de capacitación identificadas por los grupos

de trabajo y grupos de soporte.

El análisis de necesidades de los grupos de trabajo y grupos de soporte pretende

identificar necesidades comunes que a nivel de organización se abordan de forma

más eficiente. Estas actividades de análisis de necesidades se utilizan para anticipar

las futuras necesidades de capacitación que son percibidas antes a nivel de grupo de

trabajo y grupo de soporte.

2. Negociar con los grupos de trabajo y grupos de soporte la forma de

satisfacer sus necesidades de capacitación.

El soporte que proporciona el personal de capacitación de la organización depende de

los recursos de capacitación disponibles y de las prioridades de capacitación de la

organización.

Algunos ejemplos de capacitación que los grupos de trabajo o grupos de soporte realizan de forma apropiada son:

Capacitación en el dominio de aplicación o dominio del servicio de los trabajos.

Capacitación en herramientas y métodos que únicamente utilizan los grupos de trabajo o grupos de soporte.

Capacitación en seguridad, protección, y factores humanos.

3. Documentar compromisos sobre el soporte de capacitación que se

proporciona a los grupos de trabajo y grupos de soporte.

SP 1.3 Establecer un plan táctico organizativo de capacitación

Establecer y mantener un plan táctico organizativo de

capacitación.

El plan táctico organizativo de capacitación es el plan para impartir la

capacitación que es responsabilidad de la organización y es necesaria para

que los individuos realicen sus roles de forma eficaz. Este plan aborda la

ejecución de la capacitación a corto plazo, y se ajusta periódicamente

como respuesta a los cambios (p. ej. en necesidades, en recursos) y las

evaluaciones de eficacia.


1. Plan táctico organizativo de capacitación.



Subprácticas

1. Establecer el contexto del plan.

El plan táctico organizativo de capacitación habitualmente contiene:

Necesidades de capacitación.

Temario de la capacitación.

Cronogramas basados en las actividades de capacitación y en sus dependencias.

Métodos utilizados para capacitar.

Requisitos y estándares de calidad para los materiales de capacitación.

Tareas, roles, y responsabilidades de capacitación.

Recursos necesarios incluyendo herramientas, instalaciones, entornos, dotación de personal, habilidades, y conocimientos.

2. Establecer compromisos con el plan.

Para que el plan sea eficaz es esencial que los compromisos de los responsables de

implementar y dar soporte al plan se documenten.

3. Actualizar el plan y los compromisos según se necesite.

SP 1.4 Establecer una competencia de capacitación

Establecer y mantener una competencia de capacitación que

aborde las necesidades organizativas de capacitación.






1. Materiales de capacitación y artefactos de soporte.

Subprácticas

1. Seleccionar enfoques apropiados para satisfacer las necesidades

organizativas de capacitación.

La selección de enfoques de capacitación puede estar afectada por muchos factores,

incluyendo los conocimientos específicos de la audiencia, los costes, los plazos, y el

entorno de trabajo. La selección de un enfoque requiere que se consideren cuáles son

los medios para proporcionar habilidades y conocimientos de la forma más eficaz

posible teniendo en cuenta las restricciones.



Algunos ejemplos de enfoques de capacitación son:

Capacitación en el aula.

Enseñanza asistida por ordenador.

Auto-estudio guiado.

Programas formales de prácticas profesionales y de orientación.

Videos con moderador.

Clases magistrales.

Seminarios informales durante el almuerzo.

Capacitación en el trabajo estructurada.

2. Determinar si se van a desarrollar internamente los materiales de

capacitación o si se van a adquirir externamente.

Determinar los costes y beneficios de desarrollar materiales de capacitación y de

adquirir capacitación externamente.

Algunos ejemplos de criterios que se pueden utilizar para determinar el modo más eficaz de adquirir conocimientos o habilidades son:

Utilidad para los objetivos del trabajo u objetivos de rendimiento o de procesos.

Disponibilidad de tiempo para preparar la ejecución del proyecto.

Utilidad para los objetivos de negocio.

Disponibilidad de habilidades internamente.

Disponibilidad de fuentes externas de capacitación.

Algunos ejemplos de fuentes externas de capacitación son:

Capacitación impartida por el cliente.

Cursos de capacitación disponibles comercialmente.

Programas académicos.

Conferencias profesionales.

Seminarios.

3. Desarrollar u obtener materiales de capacitación.

La capacitación puede impartirla el grupo de trabajo, los grupos de soporte, la

organización, o una organización externa. El personal de capacitación de la

organización coordina la adquisición e impartición de capacitación con independencia

de la fuente.

Algunos ejemplos de material de capacitación son:

Cursos.

Enseñanza asistida por ordenador.

Videos.

4. Desarrollar u obtener instructores cualificados, diseñadores de cursos,

o mentores.



Se pueden definir criterios para identificar, desarrollar, y calificar a las personas que

desarrollan e imparten capacitación internamente, de modo que se asegure que

tienen los conocimientos y habilidades de capacitación necesarios. El desarrollo de

cursos, incluyendo los de auto estudio y de capacitación en línea, debería involucrar a

personas con experiencia en diseño de cursos. En caso de capacitación externa, el

personal de capacitación de la organización puede investigar el modo en que el

proveedor de capacitación determina qué instructores impartirán la capacitación. Esta

selección de instructores cualificados también puede ser un factor para seleccionar o

continuar utilizando un proveedor de capacitación.

5. Describir la capacitación en el currículo de capacitación de la

organización.

Algunos ejemplos de información proporcionada en las descripciones de capacitación de cada curso son:

Temas cubiertos por la capacitación.

Audiencia a la que va dirigida.

Prerrequisitos y preparación para participar.

Objetivos de la capacitación.

Duración de la capacitación.

Planes de las lecciones.

Criterios para completar el curso.

Criterios para aceptar excepciones a la capacitación.

6. Actualizar los materiales de capacitación y artefactos de soporte según

se necesite.

Algunos ejemplos en los que puede ser necesario actualizar los materiales de capacitación y artefactos de soporte son:

Cambios en las necesidades de capacitación (p. ej. cuando una nueva tecnología asociada con el tema de capacitación está disponible).

La evaluación de una capacitación identifica que se necesita un cambio (p. ej. encuestas de evaluación de la eficacia de la capacitación, evaluación del rendimiento de los programas de capacitación, formularios de evaluación de instructores).

SG 2 Proporcionar capacitación

Se proporciona capacitación a los individuos para que realicen sus roles de forma eficaz.

Cuando se seleccionan a las personas que se van a capacitar, se debería

tener en cuenta:

Conocimientos previos de la población objetivo de partícipes de la

capacitación.

Prerrequisitos de conocimientos previos para recibir la capacitación.

Habilidades y capacidades que las personas necesitan para

desempeñar sus roles.



Necesidad de capacitación interdisciplinar para todas las disciplinas,

incluyendo la gestión de proyectos o de servicios.

Necesidad de que los gerentes dispongan de capacitación en los

procesos organizativos apropiados.

Necesidad de capacitación sobre los principios básicos de todas las

disciplinas o servicios apropiados para dar soporte al personal en

gestión de calidad, gestión de configuración, y otras funciones de

soporte relacionadas.

Necesidad desarrollar competencias en áreas funcionales críticas.

Necesidad de mantener las competencias y cualificaciones del

personal para operar y mantener los entornos de trabajo comunes a

varios trabajos.

SP 2.1 Impartir capacitación

Impartir capacitación siguiendo el plan táctico organizativo de

capacitación.


1. Curso de capacitación impartido.

Subprácticas

1. Seleccionar a las personas que recibirán la capacitación que necesitan

para realizar sus roles de forma eficaz.

La capacitación pretende impartir conocimientos y habilidades a las personas que

realizan los distintos roles en la organización. Algunas personas ya tienen los

conocimientos y habilidades necesarios para realizar bien sus roles designados. Estas

personas pueden eximirse de la capacitación, pero teniendo cuidado de no abusar de

las excepciones.

2. Planificar la capacitación, incluyendo los recursos, según se necesite

(p. ej. instalaciones, instructores).

La capacitación debería planificarse y programarse. Se proporciona capacitación que

directamente dé soporte a las expectativas de desempeño en el trabajo. Por tanto, la

capacitación óptima se produce de forma que sea oportuna, teniendo en cuenta las

expectativas inminentes del trabajo a desempeñar.

Estas expectativas de desempeño a menudo incluyen:

Capacitación sobre uso de herramientas especializadas.

Capacitación sobre procedimientos que son nuevos para la persona que los va a realizar.

3. Impartir la capacitación.

Si la capacitación es impartida por una persona, entonces la debería impartir un

profesional de capacitación apropiado (p. ej. instructores experimentados, mentores).

Si es posible, la capacitación se imparte en lugares que se asemejen mucho al

entorno de trabajo, e incluye actividades para simular situaciones de trabajo reales.

Este enfoque incluye la integración de herramientas, métodos, y procedimientos para

desarrollar competencias. La capacitación se vincula a las responsabilidades del



puesto de forma que, en un plazo razonable después de impartir la capacitación, las

actividades del puesto u otras experiencias externas refuercen lo aprendido.

4. Seguir la impartición de capacitación frente al plan.

SP 2.2 Establecer registros de capacitación

Establecer y mantener los registros de capacitación organizativa.

Esta práctica se aplica a la capacitación impartida a nivel organizativo.

Establecer y mantener los registros de la capacitación promovida por los

grupos de trabajo o grupos de soporte es responsabilidad de cada grupo

de trabajo o grupo de soporte individual.


1. Registros de capacitación.

2. Actualizaciones de capacitación en el repositorio organizativo.

Subprácticas

1. Registrar a todos los alumnos que completan con éxito cada curso de

capacitación u otras actividades de capacitación aprobadas, así como

a los que no los completan con éxito.

2. Registrar a todas las personas eximidas de la capacitación.

Se debería documentar la justificación de que las excepciones se acepten, y tanto el

gerente responsable como el gerente de la persona eximida deberían aprobar las

excepciones.

3. Mantener los registros de todos los alumnos que completaron con

éxito su capacitación requerida. .

4. Poner los registros de capacitación a disposición de las personas

apropiadas para que los tengan en cuenta en las asignaciones.

Los registros de capacitación pueden ser parte de una matriz de habilidades

desarrollada por la organización de capacitación con objeto de ofrecer un resumen de

la experiencia y los estudios de las personas así como de la capacitación promovida

por la organización.

SP 2.3 Evaluar la eficacia de la capacitación

Evaluar la eficacia del programa de capacitación de la

organización.

Debería existir un proceso para determinar la eficacia de la capacitación

(esto es, el grado en el que la capacitación cubre las necesidades de la

organización).



Algunos ejemplos de métodos utilizados para evaluar la eficacia de la capacitación son:

Pruebas en el contexto de la capacitación.

Encuestas a los participantes después de la capacitación.

Encuestas de satisfacción a los gerentes que incluyan los efectos post-capacitación.

Mecanismos de evaluación incluidos en el software de capacitación.

Se pueden realizar mediciones para evaluar los beneficios de la

capacitación frente a los objetivos, tanto de los grupos de trabajo como de

la organización. Se debería prestar especial atención a la necesidad de

distintos métodos de capacitación, tales como los equipos de capacitación

como unidades de trabajo integrales. En caso de que se utilicen, los

objetivos de desempeño en el trabajo o en los procesos deberían ser

inequívocos, observables, verificables, y compartidos con los participantes

en el curso. Los resultados de la evaluación de la eficacia de la

capacitación deberían utilizarse para actualizar el material de capacitación,

según lo descrito en la práctica específica Establecer una competencia de

capacitación.


1. Encuestas de eficacia de la capacitación.

2. Evaluaciones del rendimiento del programa de capacitación.

3. Formularios de evaluación de instructores.

4. Exámenes.

Subprácticas

1. Evaluar el trabajo en curso o el completado para determinar si los

conocimientos del personal son adecuados para realizar sus tareas.

2. Proporcionar un mecanismo para evaluar la eficacia de cada curso de

capacitación con respecto a los objetivos, organizativos, del grupo de

trabajo, o individuales, de aprendizaje (o de desempeño) establecidos.

3. Obtener de los alumnos evaluaciones del grado en el que las

actividades de capacitación cubren sus necesidades.


Aseguramiento de Calidad de Procesos y Productos (PPQA) 301

ASEGURAMIENTO DE CALIDAD DE PROCESOS Y PRODUCTOS


Propósito

El propósito de Aseguramiento de Calidad Procesos y Productos (PPQA)

es proporcionar al personal y a la gerencia un conocimiento objetivo de los

procesos y de sus productos de trabajo asociados.


El área de proceso Aseguramiento de Calidad de Procesos y Productos

engloba las siguientes actividades:

Evaluar objetivamente los procesos y productos de trabajo realizados

frente a las descripciones de proceso, los estándares, y los

procedimientos aplicables.

Identificar y documentar los problemas de no conformidad.

Proporcionar realimentación sobre los resultados de las actividades de

aseguramiento de calidad al personal y a la gerencia.

Asegurar que se aborden los problemas de no conformidad.

El área de proceso Aseguramiento de Calidad de Procesos y Productos da

soporte a la entrega de productos de alta calidad, proporcionando de forma

apropiada al personal y a todos los niveles de gerencia de los grupos de

trabajo visibilidad dentro de los procesos y productos de trabajo asociados,

así como realimentación sobre éstos durante todo el trabajo.

Las prácticas en el área de proceso Aseguramiento de Calidad de

Procesos y Productos aseguran que los procesos planificados se

implementan, mientras que las prácticas en el área de proceso de

Desarrollo del Sistema de Servicio aseguran que se satisfacen los

requisitos especificados. En ocasiones, estas dos áreas de proceso

pueden abordar los mismos productos de trabajo, pero desde perspectivas

distintas. Los grupos de trabajo deberían aprovechar este solapamiento

para minimizar la duplicación de esfuerzos, pero teniendo cuidado de

mantener las perspectivas separadas.

La objetividad en las evaluaciones de aseguramiento de calidad de

procesos y productos es crítica para el éxito del trabajo (véase la definición

de “evaluar objetivamente” en el glosario). La objetividad se logra tanto por

la independencia como por la utilización de criterios. A menudo se utiliza

una combinación de métodos que proporcionan evaluaciones frente a

criterios por parte de personas que no han producido el producto de

trabajo. Los métodos menos formales se pueden utilizar para proporcionar

cobertura amplia en el día a día. Los métodos más formales se pueden

utilizar periódicamente para asegurar la objetividad.



Algunos ejemplos de formas para realizar evaluaciones objetivas son:

Auditorías formales realizadas por organizaciones de aseguramiento de calidad

separadas organizativamente.

Revisiones entre pares, las cuales se pueden realizar con distintos niveles de

formalidad.

Revisión en profundidad del trabajo en el lugar donde se realiza (esto es, auditorías “en

el puesto”).

Revisiones distribuidas y comentarios de productos de trabajo.

Comprobaciones de proceso integradas en los procesos, tales como procesos a

prueba de fallos cuando se realizan de forma incorrecta (p. ej., Poka-Yoke).

Tradicionalmente, la objetividad es proporcionada por un grupo de

aseguramiento de calidad que es independiente del grupo de trabajo. Sin

embargo, en algunas organizaciones otros enfoques podrían ser

apropiados para implementar el rol de aseguramiento de calidad de

procesos y productos sin ese tipo de independencia.

Por ejemplo, en una organización con una cultura abierta, orientada a la calidad, el rol de

aseguramiento de calidad de procesos y productos se puede realizar, parcial o

completamente, entre pares, y la función de aseguramiento de calidad se puede integrar en

el proceso. Para organizaciones pequeñas, este enfoque integrado podría ser el más viable.

Para garantizar la objetividad, si el aseguramiento de calidad está

integrado en el proceso, se deberían abordar varios problemas. Todos los

que realicen actividades de aseguramiento de calidad deberían capacitarse

en aseguramiento de calidad. Los que realicen actividades de

aseguramiento de calidad para un producto de trabajo deberían ser

personas distintas a las directamente involucradas en el desarrollo o

mantenimiento del producto de trabajo. Se debería disponer de un canal

independiente para informar al nivel apropiado de gestión organizativa, de

tal manera que se puedan escalar problemas de no conformidad según se

necesite.

Por ejemplo, si se implementan revisiones entre pares como método objetivo de evaluación,

se deberían abordar los siguientes problemas:

Que los miembros estén capacitados y que se asignen roles a las personas que

asistan a la revisión entre pares.

Que se asigne el rol de realizar el aseguramiento de calidad a un miembro de la

revisión entre pares que no haya generado el producto de trabajo.

Que haya listas de comprobación basadas en descripciones de proceso, estándares, y

procedimientos y estén disponibles para dar soporte a la actividad de aseguramiento

de calidad.

Que los problemas de no conformidad se registren como parte del informe de la

revisión entre pares y se sigan y escalen fuera del grupo de trabajo cuando sea

necesario.



El aseguramiento de calidad debería comenzar en las fases tempranas del

trabajo con objeto de establecer los planes, procesos, estándares, y

procedimientos que añadirán valor al trabajo y de satisfacer los requisitos

del trabajo y las políticas organizativas. Quienes realicen las actividades de

aseguramiento de calidad participan en establecer los planes, procesos,

estándares, y procedimientos con el fin de asegurar que éstos se ajusten a

las necesidades del trabajo y que se podrán usar cuando se realicen las

evaluaciones de aseguramiento de calidad. Adicionalmente, se designan

los procesos que serán evaluados durante el trabajo y sus productos de

trabajo asociados. Esta designación puede basarse en muestreos o en

criterios objetivos que sean consistentes con las políticas organizativas, los

requisitos del trabajo, y las necesidades del grupo de trabajo.

Cuando se identifican problemas de no conformidad, si es posible, primero

se abordan y resuelven a nivel de grupo de trabajo. Los problemas de no

conformidad que no puedan resolverse dentro del grupo de trabajo se

escalan para que se resuelvan a un nivel de gestión apropiado.

Esta área de proceso se aplica a las evaluaciones de las actividades y

productos de trabajo del grupo de trabajo así como a las actividades y

productos de trabajo organizativos (p. ej. grupo de procesos, capacitación

organizativa). Para las actividades y productos de trabajo organizativos, el

término “grupo de trabajo” debería interpretarse de forma apropiada.


Extensión SSD

Para más información sobre verificar los componentes de sistema de

servicio seleccionados, consúltese el área de proceso Desarrollo del



SG 1 Evaluar objetivamente los procesos y productos de trabajo

SP 1.1 Evaluar objetivamente los procesos

SP 1.2 Evaluar objetivamente los productos de trabajo

SG 2 Proporcionar un conocimiento objetivo

SP 2.1 Comunicar y resolver problemas de no conformidad

SP 2.2 Establecer registros




SG 1 Evaluar objetivamente los procesos y productos de trabajo

Se evalúa objetivamente que los procesos y sus productos de trabajo asociados cumplen las descripciones de proceso, estándares, y procedimientos aplicables.

SP 1.1 Evaluar objetivamente los procesos

Evaluar objetivamente los procesos realizados seleccionados con

respecto a las descripciones de proceso, estándares, y


Para que el trabajo tenga éxito es crítico que haya objetividad en las

evaluaciones de aseguramiento de calidad. Se debería definir una

descripción de la cadena de reporte de aseguramiento de calidad y el

modo en que ésta asegura la objetividad.


1. Informes de evaluación.

2. Informes de no conformidad.

3. Acciones correctivas.

Subprácticas

1. Promover un entorno (creado como parte de la gestión de trabajos)

que incentive que el personal participe en identificar y comunicar

problemas de calidad.

2. Establecer y mantener criterios claramente indicados para las

evaluaciones.

La finalidad de esta subpráctica es proporcionar criterios, basados en las necesidades

de negocio, tales como:

Qué se evaluará.

Cuándo o con qué frecuencia se evaluará un proceso.

Cómo se llevará a cabo la evaluación.

Quién debería estar involucrado en la evaluación.

3. Utilizar los criterios indicados para evaluar si los procesos realizados

seleccionados cumplen las descripciones de proceso, estándares, y

procedimientos.

4. Identificar cada no conformidad encontrada durante la evaluación.

5. Identificar lecciones aprendidas que pudieran mejorar los procesos.

SP 1.2 Evaluar objetivamente los productos de trabajo

Evaluar objetivamente los productos de trabajo seleccionados con

respecto a las descripciones de proceso, estándares, y






2. Informes de no conformidad.


Subprácticas

1. Seleccionar los productos de trabajo que se van a evaluar en base a

criterios de muestreo documentados si se utiliza muestreo.

Los productos de trabajo pueden incluir servicios producidos por un proceso, sea el

destinatario de este servicio interno o externo al grupo de trabajo u organización.

2. Establecer y mantener criterios claramente establecidos para evaluar

los productos de trabajo seleccionados.

La finalidad de esta subpráctica es proporcionar criterios, basados en las necesidades

de negocio, tales como:

Qué se evaluará en la evaluación de un producto de trabajo.

Cuándo o con qué frecuencia se evaluará un producto de trabajo.

Cómo se llevará a cabo la evaluación.

Quién debe estar involucrado en la evaluación.

3. Utilizar los criterios establecidos para evaluar los productos de trabajo

seleccionados.

4. Evaluar los productos de trabajo seleccionados en los momentos

seleccionados.

Algunos ejemplos de cuándo pueden evaluarse los productos de trabajo con respecto a las descripciones de proceso, estándares, o procedimientos son:

Antes de entregarlos al cliente.

Mientras se entregan al cliente.

Incrementalmente, cuando sea apropiado.

5. Identificar cada caso de no conformidad encontrado durante las

evaluaciones.

6. Identificar lecciones aprendidas que pudieran mejorar los procesos.

SG 2 Proporcionar un conocimiento objetivo

Los problemas de no conformidad se siguen y se comunican de forma objetiva, y se asegura su resolución.

SP 2.1 Comunicar y resolver problemas de no conformidad

Comunicar los problemas de calidad y asegurar la resolución de

los problemas de no conformidad con el personal y los gerentes.

Los problemas de no conformidad son situaciones identificadas en las

evaluaciones que reflejan una falta de cumplimiento de los estándares,

descripciones de proceso, o procedimientos aplicables. El estado de los

problemas de no conformidad proporciona un indicador de las tendencias



de calidad. Los problemas de calidad incluyen los problemas de no

conformidad y los resultados de los análisis de tendencias.

Si los problemas de no conformidad no pueden resolverse dentro del grupo

de trabajo, utilizar los mecanismos de escalación para asegurar que el nivel

de gestión apropiado pueda resolver el problema. Seguir los problemas de

no conformidad hasta que se resuelvan.


1. Informes de acciones correctivas.


3. Tendencias de calidad.

Subprácticas

1. Si es posible resolver cada no conformidad con los miembros

apropiados del personal.

2. Documentar los problemas de no conformidad cuando no puedan

resolverse dentro del grupo de trabajo.

Algunos ejemplos de formas de resolver una no conformidad dentro del grupo de trabajo son:

Corregir la no conformidad.

Cambiar las descripciones de proceso, estándares, o procedimientos que se incumplieron.

Obtener una excepción para cubrir la no conformidad.

3. Escalar los problemas de no conformidad que no puedan resolverse

dentro del grupo de trabajo al nivel de gestión apropiado que esté

designado para recibir y actuar sobre problemas de no conformidad.

4. Analizar los problemas de no conformidad para ver si hay tendencias

de calidad que se puedan identificar y abordar.

5. Asegurar que las partes interesadas relevantes están al corriente de

los resultados de las evaluaciones y de las tendencias de calidad de

manera oportuna.

6. Revisar periódicamente con el gerente designado para recibir y actuar

sobre los problemas de no conformidad los problemas abiertos de no

conformidad y las tendencias.

7. Seguir los problemas de no conformidad hasta que se resuelvan.

SP 2.2 Establecer registros

Establecer y mantener un registro de las actividades de

aseguramiento de calidad.


1. Registros de evaluación.

2. Informes de aseguramiento de calidad.



3. Informes de situación de las acciones correctivas.

4. Informes de tendencias de calidad.

Subprácticas

1. Registrar las actividades de aseguramiento de calidad de procesos y

productos con suficiente detalle como para que el estado y los

resultados se conozcan.

2. Actualizar el estado y la historia de las actividades de aseguramiento

de calidad según se necesite.


Gestión Cuantitativa de Trabajos (QWM) 308

GESTIÓN CUANTITATIVA DE TRABAJOS


Propósito

El propósito de Gestión Cuantitativa de Trabajos (QWM) es gestionar

cuantitativamente los trabajos con el fin de lograr sus objetivos

establecidos de calidad y rendimiento de procesos.


El área de proceso Gestión Cuantitativa de Trabajos engloba las siguientes

actividades:

Establecer y mantener los objetivos de calidad y rendimiento de

procesos del trabajo.

Componer un proceso definido para el trabajo que ayude a lograr los

objetivos de calidad y rendimiento de procesos del trabajo.

Seleccionar los subprocesos y atributos que son críticos para entender

el rendimiento de los procesos y que ayudan a lograr los objetivos de

calidad y rendimiento de procesos del trabajo.

Seleccionar las medidas y técnicas de análisis que se van a utilizar en

la gestión cuantitativa.

Monitorizar el rendimiento de los subprocesos seleccionados utilizando

técnicas estadísticas y otras técnicas cuantitativas.

Gestionar el trabajo utilizando técnicas estadísticas y otras técnicas

cuantitativas para determinar si los objetivos de calidad y rendimiento

de procesos del trabajo se están logrando o no.

Realizar análisis de causas raíces de los problemas seleccionados

para abordar deficiencias en el logro de los objetivos de calidad y


Los activos de proceso organizativos que se usan para lograr la alta

madurez, incluyendo los objetivos de calidad y rendimiento de procesos,

los procesos seleccionados, las medidas, las líneas base, y los modelos,

son establecidos mediante los procesos de rendimiento organizativo de

procesos y son utilizados dentro de gestión cuantitativa de trabajos. El

grupo de trabajo puede utilizar los procesos de rendimiento organizativo de

procesos para definir objetivos, medidas, líneas base, y modelos

adicionales según se necesite con objeto de analizar y gestionar el

rendimiento de manera eficaz. Las medidas, mediciones, y otros datos que

resulten de los procesos de gestión cuantitativa de trabajos se incorporan

en los activos de proceso organizativos. De esta forma, la organización y

sus grupos de trabajo consiguen beneficiarse de los activos mejorados por

el uso.



El proceso definido para el trabajo es un conjunto de subprocesos

interrelacionados que forman un proceso para el trabajo integrado y

coherente. Las prácticas de Gestión Integrada de Trabajos describen el

establecimiento del proceso definido para el trabajo por medio de

seleccionar y adaptar los procesos partiendo del conjunto de procesos

estándar de la organización (véase la definición de “proceso definido” en el

glosario).

Las prácticas de Gestión Cuantitativa de Trabajos, a diferencia de las

prácticas de Gestión Integrada de Trabajos, ayudan a entender

cuantitativamente el rendimiento esperado de los procesos o subprocesos.

Este entendimiento es utilizado como base para establecer el proceso

definido para el trabajo por medio de evaluar los procesos o subprocesos

para el trabajo y seleccionar aquellos que mejor logren los objetivos de

calidad y rendimiento de procesos.

Asimismo, para implementar con éxito esta área de proceso es importante

establecer relaciones eficaces con los suministradores. El establecimiento

de relaciones eficaces puede incluir establecer objetivos de calidad y

rendimiento de procesos para los suministradores, determinar las medidas

y técnicas analíticas a utilizar para conocer el progreso y el desempeño de

los suministradores, y monitorizar el progreso hacia el logro de dichos

objetivos.

Un elemento fundamental de la gestión cuantitativa es poder confiar en las

predicciones (esto es, la capacidad para predecir con precisión el grado en

el que el grupo de trabajo puede cumplir los objetivos de calidad y

rendimiento de procesos del trabajo). Los subprocesos que se van a

gestionar por medio de técnicas estadísticas y otras técnicas cuantitativas

se eligen en base a la necesidad de disponer de predictibilidad en el


Otro elemento fundamental de la gestión cuantitativa es entender la

naturaleza y el grado de variación experimentada en el rendimiento de los

procesos y darse cuenta de cuándo el rendimiento real del trabajo no es

adecuado para lograr los objetivos de calidad y rendimiento de procesos

del trabajo.

Por tanto, la gestión cuantitativa incluye pensar de forma estadística y usar

diferentes técnicas estadísticas de forma correcta (véase la definición de

“gestión cuantitativa” en el glosario).

Se utilizan técnicas estadísticas y otras técnicas cuantitativas para

entender el rendimiento real de los procesos o para predecirlo. Dichas

técnicas se pueden aplicar en varios niveles, desde enfocarse en

subprocesos individuales hasta analizar abarcando varias fases del ciclo de

vida y funciones de soporte. Las técnicas no estadísticas proporcionan un

conjunto de enfoques menos riguroso aunque útil que, junto con las

técnicas estadísticas, ayudan al grupo de trabajo a entender si se están

logrando o no los objetivos de calidad y rendimiento de procesos y a

identificar las acciones correctivas que se necesitan.



Esta área de proceso se aplica a la gestión de un proyecto o un conjunto

de trabajos. La aplicación de estos conceptos a la gestión de otros grupos

y funciones puede ayudar a vincular los diferentes aspectos del

rendimiento dentro de la organización con el fin de proporcionar una base

que equilibre y reconcilie las prioridades enfrentadas para abordar un

conjunto más amplio de objetivos de negocio.

Algunos ejemplos de otros grupos y funciones que pudieran beneficiarse del uso de éste

área de proceso son:

Funciones de aseguramiento de calidad o control de calidad.

Definición y mejora de procesos.

Funciones internas de investigación y desarrollo.

Funciones de identificación y gestión de riesgos.

Funciones de exploración de tecnologías.

Investigación de mercado.

Evaluación de la satisfacción de los clientes.

Seguimiento y reporte de problemas.



















Para más información sobre gestionar proactivamente el rendimiento de la

organización para que logre sus objetivos de negocio, consúltese el área


Para más información sobre establecer y mantener un entendimiento

cuantitativo del rendimiento de los procesos seleccionados dentro del

conjunto de procesos estándar de la organización con objeto de dar

soporte al logro de los objetivos de calidad y rendimiento de procesos, y



proporcionar datos, líneas base, y modelos de rendimiento de procesos

para gestionar cuantitativamente los trabajos de la organización,

consúltese el área de proceso Rendimiento Organizativo de Procesos.

Para más información sobre gestionar la adquisición de productos y

servicios a los suministradores, consúltese el área de proceso Gestión de

Acuerdos de Suministro.






SG 1 Preparar la gestión cuantitativa

SP 1.1 Establecer los objetivos del trabajo

SP 1.2 Componer el proceso definido

SP 1.3 Seleccionar subprocesos y atributos


SG 2 Gestionar el trabajo cuantitativamente

SP 2.1 Monitorizar el rendimiento de los subprocesos seleccionados

SP 2.2 Gestionar el rendimiento del trabajo

SP 2.3 Realizar análisis de causas raíces


SG 1 Preparar la gestión cuantitativa

Se lleva a cabo la preparación de la gestión cuantitativa.

Las actividades de preparación incluyen establecer los objetivos

cuantitativos del trabajo, componer un proceso definido para el trabajo que

pueda ayudar a lograr dichos objetivos, seleccionar los subprocesos y

atributos que son críticos para entender el rendimiento y lograr los

objetivos, y seleccionar las medidas y técnicas de análisis que den soporte

a la gestión cuantitativa.

Puede que sea necesario repetir estas actividades cuando cambien las

necesidades y las prioridades, cuando el rendimiento de procesos se

entienda mejor, o como parte de la mitigación de riesgos o de las acciones

correctivas.

SP 1.1 Establecer los objetivos del trabajo

Establecer y mantener los objetivos de calidad y rendimiento de


Al establecer los objetivos de calidad y rendimiento de procesos del

trabajo, piense en qué procesos se incluirán en el proceso definido para el

trabajo y en qué indican los datos históricos acerca del rendimiento de

dichos procesos. Estas consideraciones, junto con otras como la capacidad

técnica, le ayudarán a establecer objetivos del trabajo realistas.

Los objetivos de calidad y rendimiento de procesos del trabajo se

establecen y se negocian a un nivel de detalle apropiado (p. ej.,



componentes de producto individuales, subprocesos, grupos de trabajo)

con el fin de hacer posible una evaluación global de los objetivos y los

riesgos a nivel del grupo de trabajo. A medida que el trabajo progresa, los

objetivos del trabajo se pueden actualizar según se conoce el trabajo y éste

se hace más predecible, así como para reflejar los cambios en las

necesidades y prioridades de las partes interesadas relevantes.


1. Los objetivos de calidad y rendimiento de procesos del trabajo.

2. Evaluación del riesgo de no lograr los objetivos del trabajo.

Subprácticas

1. Revisar los objetivos de calidad y rendimiento de procesos de la

organización.

Esta revisión asegura que los miembros del grupo de trabajo entienden el contexto de

negocio más amplio en el que opera el trabajo. Los objetivos de calidad y rendimiento

de procesos del trabajo se desarrollan en el contexto de estos objetivos organizativos

de carácter más general.

Xd19 Para más información sobre establecer objetivos de calidad y



2. Identificar las necesidades y prioridades de calidad y rendimiento de

procesos del cliente, los suministradores, los usuarios finales, y otras


Habitualmente, la identificación de necesidades de las partes interesadas relevantes

comenzará de forma temprana (p. ej., durante el desarrollo de la estrategia de

servicio). Posteriormente, las necesidades se recaban, analizan, refinan, priorizan, y

equilibran en mayor medida durante el desarrollo de los requisitos de las partes

interesadas y el sistema de servicio.

Algunos ejemplos de atributos de calidad y rendimiento de procesos para los que se podrían identificar necesidades y prioridades son:

Duración.

Predictibilidad.

Fiabilidad.


Disponibilidad.

Continuidad del servicio.

3. Definir y documentar los objetivos medibles de calidad y rendimiento

de procesos del trabajo.

Definir y documentar los objetivos del trabajo incluye:

Incorporar los objetivos organizativos de calidad y rendimiento de procesos que sean apropiados.



Documentar los objetivos que reflejen las necesidades y prioridades de calidad y rendimiento de procesos del cliente, los usuarios finales, y las otras partes interesadas relevantes.

Determinar cómo se logrará cada objetivo.

Revisar los objetivos para asegurar que son suficientemente específicos, medibles, alcanzables, relevantes, y que tienen un plazo determinado.

Algunos ejemplos de atributos de calidad medibles son:

Tiempo medio entre fallos.

Número y gravedad de los defectos del producto entregado.

Uso de recursos críticos.

Número y gravedad de las reclamaciones de los clientes sobre el servicio proporcionado.

Algunos ejemplos de atributos de rendimiento de procesos medibles son:

Tiempo de ciclo.

Porcentaje de tiempo dedicado a rehacer el trabajo.

Porcentaje de defectos eliminados por las actividades de verificación de productos (quizás por tipos de verificación, tales como revisión entre pares y pruebas).

Tasa de defectos no detectados.

Número y gravedad de defectos encontrados (o incidencias comunicadas) en el año siguiente a la entrega del producto (o al inicio del servicio).

Algunos ejemplos de objetivos de calidad y rendimiento de procesos del trabajo son:

Mantener el volumen de peticiones de cambio pendientes por debajo de un valor deseado.

Mejorar la velocidad en un entorno Ágil hasta un valor deseado en una fecha concreta.

Reducir el tiempo no productivo en un x% antes de una fecha determinada.

Mantener la desviación en los plazos por debajo de un porcentaje especificado.

Reducir el coste total del ciclo de vida en un porcentaje especificado antes de una fecha determinada.

Reducir las incidencias en los servicios prestados al cliente en un 10% sin afectar al coste.

4. Derivar objetivos intermedios para monitorizar el progreso hacia el

logro de los objetivos del trabajo.

Se pueden establecer objetivos intermedios para los atributos de las fases del ciclo de

vida, los hitos, los productos de trabajo, y los subprocesos seleccionados.

Dado que los modelos de rendimiento de procesos caracterizan las relaciones entre

atributos de producto y de proceso, estos modelos se pueden utilizar para ayudar a

derivar objetivos intermedios que guíen al grupo de trabajo en el logro de sus

objetivos.

5. Determinar el riesgo de no lograr los objetivos de calidad y rendimiento

de procesos del trabajo.



El riesgo depende de los objetivos establecidos, de la arquitectura del producto, del

proceso definido para el trabajo, de la disponibilidad de conocimientos y habilidades

necesarios, etc. Se pueden utilizar líneas base y modelos de rendimiento de procesos

para evaluar la probabilidad de lograr un conjunto de objetivos y para proporcionar

orientación al negociar los objetivos y los compromisos. La evaluación del riesgo

puede involucrar a varias partes interesadas y puede realizarse como parte de la

resolución de conflictos descrita en la siguiente subpráctica.

6. Resolver los conflictos entre los objetivos de calidad y rendimiento de

procesos (p. ej., si un objetivo no puede lograrse sin comprometer a

otros).

Los modelos de rendimiento de procesos pueden ayudar a identificar conflictos y a

asegurar que la resolución de unos conflictos no introduce nuevos conflictos o riesgos.

Resolver conflictos engloba a las siguientes actividades:

Establecer prioridades relativas para los objetivos.

Considerar objetivos alternativos teniendo en cuenta las estrategias de negocio a largo plazo así como las necesidades a corto plazo.

Involucrar en la decisión de soluciones de compromiso a los clientes, los usuarios finales, la dirección, los gerentes de los grupos de trabajo, y las otras partes interesadas relevantes.

Revisar los objetivos según se necesite para reflejar los resultados de la resolución de conflictos.

7. Establecer la trazabilidad entre los objetivos de calidad y rendimiento

de procesos y sus fuentes.

Algunos ejemplos de fuentes de objetivos son:

Requisitos.


Objetivos de calidad y rendimiento de procesos del cliente.

Objetivos de negocio.

Conversaciones con clientes y clientes potenciales.

Estudios de mercado.

Arquitectura del producto.

Un ejemplo de método para identificar y trazar estas necesidades y prioridades es el Despliegue de la Función Calidad (QFD23).

8. Definir y negociar objetivos de calidad y rendimiento de procesos para

los suministradores.

9. Actualizar los objetivos de calidad y rendimiento de procesos según se

necesite.

23

Quality Function Deployment (N. del T.)



SP 1.2 Componer el proceso definido

Utilizando técnicas estadísticas y otras técnicas cuantitativas,

componer un proceso definido que haga posible que el trabajo

logre sus objetivos de calidad y rendimiento de procesos.

Para más información sobre establecer el proceso definido, consúltese el

área de proceso Gestión Integrada de Trabajos.





Procesos.

Componer el proceso definido para el trabajo va más allá de la selección y

adaptación descritas en el área de proceso Gestión Integrada de Trabajos.

También incluye identificar alternativas para uno o más procesos o

subprocesos, analizar el rendimiento cuantitativamente, y seleccionar las

alternativas que puedan ayudar más a que el proyecto logre sus objetivos

de calidad y rendimiento de procesos.


1. Criterios utilizados para evaluar las alternativas para el trabajo.

2. Subprocesos alternativos.

3. Subprocesos a incluir en el proceso definido del trabajo.

4. Evaluación de los riesgos de no lograr los objetivos del trabajo.

Subprácticas

1. Establecer los criterios a utilizar para evaluar las alternativas de

proceso para el trabajo.

Los criterios se pueden basar en:

Objetivos de calidad y rendimiento de procesos.

Disponibilidad de datos de rendimiento de procesos y relevancia de los datos para evaluar una alternativa.

Experiencia con una alternativa o con alternativas similares para la composición.

Existencia de modelos de rendimiento de procesos que se puedan utilizar para evaluar una alternativa.

Estándares de líneas de producto.

Servicios y niveles de servicio estándar.

Modelos de ciclo de vida.


Leyes y normativas.

2. Identificar procesos y subprocesos alternativos para el trabajo.

La identificación de alternativas puede incluir uno o más de los siguientes puntos:



Analizar las líneas base organizativas de rendimiento de procesos para identificar subprocesos candidatos que pudieran ayudar a lograr los objetivos de calidad y rendimiento de procesos del trabajo.

Identificar los subprocesos del conjunto de procesos estándar de la organización así como los procesos adaptados de la biblioteca de activos de proceso que pudieran ayudar a lograr los objetivos.

Identificar procesos de fuentes externas (p. ej. otras organizaciones, congresos profesionales, investigación académica).

Ajustar el nivel o profundidad con la que se aplica un subproceso (tal y como se describe en la siguiente subpráctica con más detalle en).

Ajustar el nivel o profundidad con la que se aplican los subprocesos, puede incluir las

siguientes opciones:

Número y tipo de revisiones entre pares a realizar y cuándo realizarlas.

Cantidad de esfuerzo o duración dedicados a tareas concretas.

Número y selección del personal involucrado.

Niveles de cualificación requeridos para realizar tareas específicas.

Aplicación selectiva de técnicas especializadas de construcción o verificación.

Decisiones sobre reutilización y estrategias de mitigación de riesgos

asociadas.

Los atributos del proceso y del producto que se van a medir.

Frecuencia de muestreo para los datos de gestión.

Para más información sobre utilizar los activos de proceso

organizativos para planificar trabajos, consúltese el área de proceso

Gestión Integrada de Trabajos.

3. Analizar la interacción entre los subprocesos alternativos para

entender qué relaciones hay entre los subprocesos, incluyendo sus

atributos.

Un análisis de interacciones permitirá conocer las fortalezas y debilidades relativas de

cada alternativa concreta. Este análisis puede estar soportado por una calibración de

los modelos de rendimiento de procesos de la organización a partir de los datos de

rendimiento de procesos (p. ej., caracterizada según las líneas base de rendimiento

de procesos).

Podrían ser necesarios modelos adicionales si los modelos de rendimiento de

procesos existentes no pudiesen abordar las relaciones significativas entre los

procesos alternativos bajo consideración y hubiese un riesgo elevado de no lograr los

objetivos.

4. Evaluar los subprocesos alternativos frente a los criterios.

Utilizar los datos históricos, las líneas base, y los modelos de rendimiento de

procesos, según sea apropiado, para ayudar a evaluar las alternativas frente a los

criterios. Estas evaluaciones pueden incluir el uso del análisis de sensibilidad,

particularmente si hay situaciones de alto riesgo.



Para más información sobre evaluar alternativas, consúltese el área de

proceso Análisis de Decisiones y Resolución.

5. Seleccionar los subprocesos alternativos que mejor cumplan los

criterios.

Puede que sea necesario realizar las actividades descritas en las subprácticas

anteriores varias veces hasta poder confiar en que se han identificado las mejores

alternativas disponibles.

6. Evaluar el riesgo de no lograr los objetivos de calidad y rendimiento de


Puede que un análisis de los riesgos asociados con la alternativa de proceso definido

seleccionada conduzca a identificar nuevas alternativas a evaluar, así como a

identificar áreas que requieran una mayor atención de la gerencia.



SP 1.3 Seleccionar subprocesos y atributos

Seleccionar los subprocesos y atributos que son críticos para

evaluar el rendimiento y ayudar a lograr los objetivos de calidad y


Algunos subprocesos son críticos porque su rendimiento influye o

contribuye significativamente al logro de los objetivos del trabajo. Estos

subprocesos pueden ser buenos candidatos para su monitorización y

control utilizando técnicas estadísticas u otras técnicas cuantitativas según

se describe en la primera práctica específica de la segunda meta

específica.

Además, algunos atributos de estos subprocesos pueden servir como

indicadores anticipados del rendimiento de procesos que se puede esperar

de los subprocesos que están más adelante en el flujo, y se pueden utilizar

para evaluar el riesgo de no lograr los objetivos del trabajo (p. ej. utilizando

los modelos de rendimiento de procesos).

Los subprocesos y los atributos que desempeñan un papel así de crítico

podrían haberse identificado anteriormente como parte del análisis descrito

en la práctica específica previa.

Para proyectos pequeños, y en circunstancias en las que las que los

subprocesos de un trabajo no generen datos con suficiente frecuencia

como para dar soporte a la realización de inferencias estadísticas con

sensibilidad suficiente, aún puede ser posible entender el rendimiento si se

examina el rendimiento de procesos de forma transversal a iteraciones,

equipos, o trabajos similares.


1. Criterios utilizados para seleccionar subprocesos cuya contribución

sea clave para lograr los objetivos del trabajo.

2. Subprocesos seleccionados.



3. Atributos de los subprocesos seleccionados que ayudan a predecir el

futuro rendimiento del trabajo.

Subprácticas

1. Analizar el modo en que se relacionan entre sí los subprocesos, sus

atributos, otros factores, y los resultados de rendimiento del trabajo.

Los análisis de causas raíces, los análisis de sensibilidad, o los modelos de

rendimiento de procesos pueden ayudar a identificar los subprocesos y atributos que

más contribuyen a lograr determinados resultados de rendimiento (y a la variación en

dichos resultados), o que son indicadores útiles de la futura consecución de

resultados de rendimiento.



Resolución.

2. Identificar los criterios a utilizar para seleccionar los subprocesos cuya

contribución sea clave para lograr los objetivos de calidad y


Algunos ejemplos de criterios utilizados para seleccionar subprocesos son:

Existencia de una fuerte correlación con resultados de rendimiento abordados por los objetivos del trabajo.

Importancia de la estabilidad en el rendimiento de los subprocesos.

Que el bajo rendimiento del subproceso esté asociado con serios riesgos para el trabajo.

Que uno o más atributos del subproceso sean entradas clave de los modelos de rendimiento de procesos utilizados para el trabajo.

Que el subproceso se ejecutará con suficiente frecuencia como para proporcionar datos suficientes para el análisis.

3. Seleccionar los subprocesos utilizando los criterios identificados.

Los datos históricos, los modelos, y las líneas base de rendimiento de procesos

pueden ayudar a evaluar los subprocesos candidatos frente a los criterios de

selección.



4. Identificar los atributos de producto y de proceso que se monitorizarán.

Estos atributos podrían haberse identificado como parte de realizar las subprácticas

previas.

Los atributos que permiten conocer el rendimiento actual o futuro de los subprocesos

son candidatos a su monitorización, tanto si están asociados a subprocesos bajo el

control del grupo de trabajo como si no. Además, alguno de estos mismos atributos

pueden desempeñar otros papeles, (p. ej. ayudar a monitorizar el progreso y el

rendimiento del trabajo, según se describe en Monitorización y Control de Trabajos

[WMC]).



Algunos ejemplos de atributos de producto y de proceso son:

Esfuerzo empleado para realizar el subproceso.

Velocidad a la que se lleva a cabo el subproceso.

Porcentaje de cumplimiento del acuerdo de nivel de servicio.


Recursos o materiales consumidos a la entrada del subproceso

Nivel de cualificación de los miembros del personal que realizan los subprocesos.

Calidad del entorno de trabajo utilizado para realizar el subproceso.

Volumen de salidas del subproceso (p. ej. productos de trabajo intermedios).

Atributos de calidad de las salidas del subproceso (p. ej. fiabilidad, facilidad de prueba).


Seleccionar las medidas y técnicas de análisis que se utilizarán

para gestionar cuantitativamente.





1. Definición de las medidas y técnicas de análisis que se utilizarán para

gestionar cuantitativamente.

2. Trazabilidad desde las medidas hacia los objetivos de calidad y


3. Objetivos de calidad y rendimiento de procesos de los subprocesos

seleccionados y sus atributos.

4. Líneas base y modelos de rendimiento de procesos a utilizar por el

grupo de trabajo.

Subprácticas

1. Identificar dentro de los activos de proceso organizativos las medidas

comunes que dan soporte a la gestión cuantitativa.



de Procesos.


rendimiento, consúltese el área de proceso Rendimiento Organizativo

de Procesos.

Las líneas de producto, los servicios estándar, y los niveles de servicio u otros

criterios de estratificación pueden ser categorías de medidas comunes.

2. Identificar las medidas adicionales que puedan ser necesarias para

cubrir los atributos críticos de producto y de proceso de los




En algunos casos, las medidas pueden estar orientadas a la investigación. En tales

casos estas medidas deberían estar identificadas explícitamente.

3. Identificar las medidas que se van a utilizar para gestionar los

subprocesos.

Al seleccionar las medidas, tener en mente las siguientes consideraciones:

Las medidas que agregan datos de múltiples fuentes (p. ej., diferentes

procesos, fuentes de entrada, entornos) o a lo largo del tiempo (p. ej., a nivel

de fase) pueden ocultar problemas subyacentes, dificultando la identificación

y resolución de problemas.

En trabajos a corto plazo, puede que sea necesario agregar de forma

transversal datos de instancias similares de un proceso con objeto de

posibilitar el análisis de su rendimiento de procesos a la vez que se continúa

utilizando datos desagregados para dar soporte a los trabajos individuales.

La selección no debería limitarse sólo a medidas de nivel de servicio o de

rendimiento. Las “medidas de análisis” (p. ej., ratios de llegada de

transacciones, nivel de cualificación del personal, tendencias en el uso de

recursos concretos del sistema de servicio) pueden proporcionar mayor

información sobre el rendimiento de procesos.

4. Especificar las definiciones operativas de las medidas, sus puntos de

recogida en los subprocesos, y el modo en que se determinará la

integridad de las medidas.

5. Analizar las relaciones entre las medidas identificadas y los objetivos

de calidad y rendimiento de procesos del trabajo, y derivar a nivel de

subproceso objetivos de calidad y rendimiento de procesos que

establezcan límites (p. ej., umbrales, rangos) a cumplir por cada

atributo medido de cada subproceso seleccionado.

Algunos ejemplos de objetivos de calidad y rendimiento de procesos derivados a nivel de subproceso son:

Mantener la velocidad de revisión del código entre 75 y 100 líneas de código por hora.

Mantener las sesiones de captura de requisitos por debajo de tres horas.

Mantener la velocidad de prueba por encima de un número específico de casos de prueba por día.

Mantener los niveles de retrabajo por debajo de un porcentaje específico.

Mantener la productividad en la generación de casos de uso por día.

Mantener la complejidad del diseño (tasa de invocaciones) por debajo de un umbral específico.

6. Identificar las técnicas estadísticas y otras técnicas cuantitativas que

se van a utilizar para gestionar cuantitativamente.

En la gestión cuantitativa, el rendimiento de procesos de los subprocesos

seleccionados se analiza utilizando técnicas estadísticas y otras técnicas cuantitativas

que ayudan a caracterizar la variación del subproceso, identificar cuándo ocurre un

comportamiento estadístico inesperado, reconocer cuándo es excesiva una variación,



e investigar las causas. Algunos ejemplos de técnicas estadísticas que se pueden

utilizar en el análisis del rendimiento de procesos son los gráficos de control, el

análisis de regresión, el análisis de varianza, y el análisis de series temporales.

Se pueden obtener beneficios para el trabajo si se analiza el rendimiento de los

subprocesos que no se han seleccionado por su impacto en el rendimiento del trabajo.

Se pueden identificar técnicas estadísticas y otras técnicas cuantitativas para abordar

estos subprocesos también.

Las técnicas estadísticas y otras técnicas cuantitativas algunas veces implican utilizar

presentaciones gráficas que ayuden a visualizar las asociaciones que existen entre

los datos y los resultados de los análisis. Tales presentaciones pueden ayudar a

visualizar el rendimiento de procesos y su variación a lo largo del tiempo (es decir,

tendencias), a identificar problemas u oportunidades, y a evaluar los efectos de

factores concretos.

Algunos ejemplos de presentaciones gráficas son:

Gráficos de dispersión.

Histogramas.

Gráficos de cajas y bigotes.

Gráficos de ejecución.

Diagramas de Ishikawa.

Algunos ejemplos de otras técnicas utilizadas para el análisis del rendimiento de procesos son:

Hojas de conteo.

Esquemas de clasificación (p. ej. Clasificación Ortogonal de Defectos).

7. Determinar qué líneas base y qué modelos de rendimiento de

procesos pueden ser necesarios para dar soporte a los análisis

identificados.

En algunas situaciones, el conjunto de líneas base y modelos proporcionado tal y

como describe el área de proceso Rendimiento Organizativo de Procesos puede ser

inadecuado para dar soporte a la gestión cuantitativa de trabajos. Esta situación

puede suceder cuando los objetivos, los procesos, las partes interesadas, los niveles

de cualificación, o el entorno del trabajo sean diferentes de los proyectos para los que

fueron establecidas las líneas base y modelos.

A medida que el trabajo progresa, los datos del trabajo pueden servir como un

conjunto de datos más representativo para establecer un conjunto de líneas base o

modelos de rendimiento de procesos que no estén no disponibles o que sean

específicos para el trabajo.

El contraste de hipótesis, comparando los datos del trabajo con los datos históricos

anteriores, puede confirmar la necesidad de establecer líneas base y modelos

adicionales específicos para el trabajo.

8. Instrumentar el entorno de soporte organizativo o del trabajo para dar

soporte a la recogida, derivación, y análisis de las medidas.



Esta instrumentación está basada en:

La descripción del conjunto de procesos estándar de la organización.

La descripción del proceso definido para el trabajo.

Las capacidades del entorno de soporte organizativo o del trabajo.

9. Actualizar las medidas y las técnicas de análisis estadístico según se

necesite.

SG 2 Gestionar el trabajo cuantitativamente

El trabajo se gestiona cuantitativamente.

Gestionar el trabajo cuantitativamente implica usar técnicas estadísticas y

otras técnicas cuantitativas para:

Monitorizar los subprocesos seleccionados utilizando técnicas

estadísticas y otras técnicas cuantitativas.

Determinar si se están cumpliendo o no los objetivos de calidad y


Llevar a cabo los análisis de causas raíces de los problemas

seleccionadas para abordar las deficiencias.

SP 2.1 Monitorizar el rendimiento de los subprocesos seleccionados

Monitorizar el rendimiento de los subprocesos seleccionados

utilizando técnicas estadísticas y otras técnicas cuantitativas.

El propósito de esta práctica específica es utilizar técnicas estadísticas y

otras técnicas cuantitativas para analizar la variación del rendimiento de los

subprocesos y determinar las acciones que se necesitan para lograr los

objetivos de calidad y rendimiento de procesos de cada subproceso.


1. Límites naturales del rendimiento de procesos de cada atributo de

subproceso seleccionado.

2. Las acciones que se necesitan para abordar las deficiencias en la

estabilidad o capacidad de cada subproceso seleccionado.

Subprácticas

1. Recopilar los datos de los subprocesos a medida que se ejecutan

según lo definido por las medidas seleccionadas.

2. Monitorizar la variación y la estabilidad de los subprocesos

seleccionados y abordar las deficiencias.

Este análisis implica evaluar las mediciones en relación a los límites naturales

calculados para cada medida seleccionada, e identificar los valores anormales u otras

señales de comportamiento potencial no aleatorio, determinar sus causas y evitar o

mitigar los efectos de su recurrencia (esto es, abordar las causas especiales de

variación).

En estos análisis, tener en cuenta si hay suficientes datos y o si se producen cambios

en el rendimiento de procesos que pudieran afectar a la capacidad de lograr o

mantener la estabilidad.



Las técnicas de análisis para identificar valores anormales o señales incluyen los

gráficos de control estadístico de procesos, los intervalos de predicción, y el análisis

de varianza. Algunas de estas técnicas implican el uso de presentaciones gráficas.

Otras deficiencias a considerar en el rendimiento de procesos incluyen situaciones en

las que la variación sea demasiado elevada como para poder confiar en la estabilidad

del subproceso, o demasiado importante como para poder evaluar la capacidad

(subpráctica siguiente) de lograr los objetivos establecidos para cada atributo

seleccionado.

3. Monitorizar la capacidad y el rendimiento de los subprocesos

seleccionados y abordar las deficiencias.

El propósito de esta subpráctica es identificar las acciones a realizar para ayudar a

que el subproceso logre sus objetivos de calidad y rendimiento de procesos.

Asegúrese de que el rendimiento del subproceso sea estable en relación a las

medidas seleccionadas (subpráctica previa) antes de comparar su capacidad con los

objetivos de calidad y rendimiento de procesos.

Algunos ejemplos de acciones que se pueden realizar cuando el rendimiento de un subproceso seleccionado no logra satisfacer sus objetivos son:

Mejorar la implementación del subproceso existente para reducir su variación o mejorar su rendimiento (esto es, abordar las causas comunes de variación).

Identificar e implementar un subproceso alternativo identificando y adoptando nuevos elementos de proceso, subprocesos, y tecnologías que puedan ayudar a alinearse mejor con los objetivos.

Identificar riesgos y estrategias de mitigación de riesgos para cada deficiencia en la capacidad del subproceso.

Renegociar o volver a derivar objetivos para cada atributo de subproceso seleccionado, de forma que el subproceso pueda lograrlos.

Algunas acciones pueden implicar el uso de análisis de causas raíces, que se

describe más adelante en la SP 2.3.



Trabajos.

SP 2.2 Gestionar el rendimiento del trabajo

Gestionar el trabajo utilizando técnicas estadísticas y otras

técnicas cuantitativas para determinar si se lograrán o no los





Para más información sobre gestionar el rendimiento del negocio,

consúltese el área de proceso Gestión del Rendimiento Organizativo.

Esta práctica específica utiliza varias entradas con el fin de predecir si se

lograrán los objetivos de calidad y rendimiento de procesos del trabajo. En

base a esta predicción, se identifican y gestionan los riesgos asociados a



no lograr los objetivos de calidad y rendimiento de procesos del trabajo, y

se definen las acciones para abordar las deficiencias según sea apropiado.

Las entradas clave para este análisis incluyen los datos de estabilidad y

capacidad de los subprocesos individuales obtenidos en la práctica

específica previa, así como los datos de rendimiento obtenidos

monitorizando otros subprocesos, los riesgos, y el progreso de los

suministradores.


1. Predicciones de los resultados que se lograrán en relación a los


2. Presentaciones gráficas y tabulaciones de datos de otros

subprocesos, los cuales dan soporte a la gestión cuantitativa.

3. Evaluación de los riesgos de no lograr los objetivos de calidad y


4. Acciones que se necesitan para abordar las deficiencias en el logro de

los objetivos del trabajo.

Subprácticas

1. Revisar periódicamente el rendimiento de los subprocesos.

Los datos de estabilidad y capacidad obtenidos al monitorizar los subprocesos

seleccionados, según se describe en la SP 2.1, son una entrada clave para entender

la capacidad global que tiene el grupo de trabajo para lograr los objetivos de calidad y


Además, los subprocesos no seleccionados por su falta de impacto en los objetivos

del trabajo aun así pueden crear problemas o riesgos para el trabajo, y por tanto

puede ser deseable que estos subprocesos se monitoricen en alguna medida. Las

técnicas analíticas que implican el uso de presentaciones gráficas también pueden

demostrarse útiles para entender el rendimiento a nivel de subproceso.

2. Monitorizar y analizar el progreso de los suministradores hacia el logro

de sus objetivos de calidad y rendimiento de procesos.

3. Revisar y analizar periódicamente los resultados reales logrados frente

a los objetivos intermedios establecidos.

4. Utilizar los modelos de rendimiento de procesos calibrados con los

datos del proyecto para evaluar el progreso hacia el logro de los


Los modelos de rendimiento de procesos se utilizan para evaluar el progreso en el

logro de los objetivos que no se pueden medir hasta una fase posterior en el ciclo de

vida del trabajo. Los objetivos pueden ser tanto objetivos intermedios como objetivos

generales.



Un ejemplo sería utilizar modelos de rendimiento de procesos para predecir los defectos latentes en los productos de trabajo en fases posteriores o en el producto entregado.

La calibración de los modelos de rendimiento de procesos se basa en los resultados

obtenidos al realizar las actividades descritas en las subprácticas y prácticas

específicas previas.

5. Identificar y gestionar los riesgos asociados con el logro de los




Algunos ejemplos de fuentes de riesgos son:

Subprocesos que tengan un rendimiento o capacidad inadecuados.

Suministradores que no logren sus objetivos de calidad y rendimiento de procesos.

Falta de visibilidad de la capacidad de los suministradores.

Inexactitudes en los modelos de rendimiento de procesos que se utilizan para predecir el rendimiento.

Deficiencias en el rendimiento de procesos predicho (progreso estimado).

Otros riesgos identificados asociados con las deficiencias identificadas.

6. Determinar e implementar las acciones que se necesitan para abordar

las deficiencias en el logro de los objetivos de calidad y rendimiento de


El propósito de esta subpráctica es identificar e implementar el conjunto adecuado de

acciones, los recursos, y los plazos para devolver al grupo de trabajo a la senda que

conduce a lograr sus objetivos.

Algunos ejemplos de acciones que se pueden realizar para abordar las deficiencias en el logro de los objetivos del trabajo son:

Cambiar los objetivos de calidad y rendimiento de procesos para que estén dentro del rango que se espera en el proceso definido.

Mejorar la implementación del proceso definido.

Adoptar nuevos subprocesos y tecnologías que tengan el potencial para satisfacer los objetivos y gestionar los riesgos asociados.

Identificar los riesgos y las estrategias de mitigación de riesgos para las deficiencias.

Poner fin al trabajo.

Algunas acciones pueden implicar el uso del análisis de causas raíces, el cual se

aborda en la siguiente práctica específica.



Trabajos.



Cuando las acciones correctivas den lugar a cambiar los atributos o medidas

relacionados con factores ajustables de un modelo de rendimiento de procesos, el

modelo se puede utilizar para predecir los efectos de las acciones. Cuando se lleven a

cabo acciones correctivas críticas en situaciones de alto riesgo, se puede crear un

modelo de rendimiento de procesos para predecir los efectos de los cambios.

SP 2.3 Realizar análisis de causas raíces

Realizar análisis de causas raíces de los problemas seleccionados

para abordar las deficiencias en el logro de los objetivos de

calidad y rendimiento de procesos del grupo de trabajo.

Los problemas a abordar incluyen deficiencias en la estabilidad y

capacidad de los subprocesos, y deficiencias en el rendimiento con

respecto a sus objetivos.

Es mejor realizar los análisis de causas raíces de los problemas

seleccionados poco después de que se identifique el problema por primera

vez, mientras el suceso sea lo suficientemente reciente como para poder

investigarlo minuciosamente.

La formalidad y el esfuerzo requeridos para un análisis de causas raíces

pueden variar considerablemente y pueden venir determinados por factores

tales como las partes interesadas que estén involucradas; el riesgo o la

oportunidad de que estén presentes; la complejidad de la situación; la

frecuencia con que la situación pudiera repetirse; la disponibilidad de datos,

líneas base, y modelos que puedan ser utilizados para el análisis; y la

cantidad de tiempo que haya pasado desde los sucesos que

desencadenaron la deficiencia.

En el caso de un subproceso que presente demasiada variación, se realice

muy de vez en cuando, e involucre a partes interesadas diferentes, podría

llevar varias semanas o meses identificar las causas raíces.

Del mismo modo, el rango de esfuerzo y plazos para determinar, planificar,

e implementar las acciones a realizar puede variar significativamente.

Con frecuencia resultará difícil determinar cuánto tiempo se necesita a

menos que se lleve a cabo un análisis inicial de las deficiencias.








1. Subprocesos y mediciones y análisis de rendimiento (incluyendo

análisis estadísticos) registrados en el repositorio de mediciones de la

organización.

2. Presentaciones gráficas de los datos utilizados para entender los

subprocesos y el rendimiento y las tendencias en el rendimiento.



3. Causas raíces identificadas y acciones potenciales a llevar a cabo.

Subprácticas

1. Realizar análisis de causas raíces, según sea apropiado, para

diagnosticar deficiencias en el rendimiento de procesos.

Las líneas base y los modelos de rendimiento de procesos se utilizan para

diagnosticar las deficiencias; identificar posibles soluciones; predecir el rendimiento

futuro del trabajo y los procesos; y evaluar acciones potenciales según sea apropiado.

El uso de modelos de rendimiento de procesos para predecir el futuro rendimiento del

trabajo y los procesos se describe en una subpráctica de la práctica específica previa.

2. Identificar y analizar acciones potenciales.

3. Implementar las acciones seleccionadas.

4. Evaluar el impacto de las acciones sobre el rendimiento del

subproceso.

Esta evaluación del impacto puede incluir evaluar la significatividad estadística de los

impactos que resulten de las acciones llevadas a cabo para mejorar el rendimiento de

procesos.


Gestión de Requisitos (REQM) 328

GESTIÓN DE REQUISITOS


Propósito

El propósito de Gestión de Requisitos (REQM) es gestionar los requisitos

de los productos y componentes de producto y asegurar que dichos

requisitos estén alineados con los planes de trabajo y los productos de

trabajo.


Los procesos de gestión de requisitos gestionan todos los requisitos

recibidos o generados por el grupo de trabajo, incluyendo tanto los

requisitos técnicos como los no técnicos así como los requisitos impuestos

al trabajo por la organización.

En particular, en el área de proceso Gestión de Requisitos se tratan todos

los requisitos que el cliente y el proveedor de servicios han aprobado. Los

requisitos del cliente para los servicios a menudo se identifican en

acuerdos escritos creados antes o durante el establecimiento de la

prestación de servicios. El cliente puede ser interno o externo a la

organización proveedora de servicios.

En todas las áreas de proceso, cuando se utilizan los términos “producto” y

“componente de producto”, se entiende que también incluyen a los

servicios, los sistemas de servicio, y sus componentes.

Los procesos de gestión de requisitos deberían fomentar la comunicación

abierta sin que haya represalias.

Las fuentes y consideraciones para los requisitos del servicio incluyen a las

metas y objetivos de rendimiento relacionados con la misión (que se

encuentran en los planes estratégicos), los problemas identificados al

monitorizar los niveles de rendimiento y niveles de servicio, las

restricciones identificadas al seleccionar soluciones de diseño, y los

requisitos derivados de diseñar el sistema de servicio (p. ej. fiabilidad,

mantenibilidad, disponibilidad, soportabilidad, seguridad y salud,

operaciones de la misión, coste del ciclo de vida, gestión de la

obsolescencia).

Otras consideraciones que afectan a los requisitos del servicio pueden

surgir de los acuerdos del cliente con otros suministradores (p. ej. contratos

marco con clientes, acuerdos de nivel operativo, memorandos de

entendimiento, subcontratos).

El grupo de trabajo realiza los pasos apropiados para asegurar que el

conjunto de requisitos aprobados se gestiona para dar soporte a las

necesidades de planificación y ejecución del trabajo. Cuando un grupo de

trabajo recibe requisitos de un proveedor de requisitos aprobado, éstos se



revisan con dicho proveedor para resolver los problemas y para evitar

malentendidos antes de que los requisitos se incorporen en los planes de

trabajo. Una vez que el proveedor y el receptor de los requisitos llegan a un

acuerdo, se obtiene un compromiso con los requisitos por parte de los

participantes en el trabajo. El grupo de trabajo gestiona los cambios a los

requisitos a medida que evolucionan e identifica las inconsistencias que

ocurran entre los planes, los productos de trabajo, y los requisitos

Una parte de la gestión de requisitos es documentar los cambios a los

requisitos y su justificación así como mantener la trazabilidad bidireccional

entre los requisitos fuente, todos los requisitos de producto y de

componente de producto, y otros productos de trabajo especificados

(véase la definición de “trazabilidad bidireccional” en el glosario).

Todos los productos y servicios tienen requisitos. En el caso de actividades

de mantenimiento, los cambios se basan en cambiar los requisitos, el

diseño, o a la implementación existentes. Los cambios a los requisitos, si

los hay, pueden ser documentados mediante peticiones de cambio del

cliente o de los usuarios finales, o pueden tomar la forma de nuevos

requisitos recibidos desde el proceso de desarrollo de requisitos.

Independientemente de su fuente o de su forma, las actividades de

mantenimiento dirigidas por los cambios a los requisitos son gestionadas

consecuentemente.


Extensión SSD



de Servicio.




Para más información sobre establecer las líneas base y seguir y controlar

los cambios, consúltese al área de proceso Gestión de Configuración.






Para más información sobre establecer y mantener planes que definan los

trabajos, consúltese el área de proceso Planificación de Trabajos.




SG 1 Gestionar requisitos

SP 1.1 Entender los requisitos

SP 1.2 Obtener el compromiso con los requisitos

SP 1.3 Gestionar los cambios a los requisitos

SP 1.4 Mantener la trazabilidad bidireccional entre los requisitos

SP 1.5 Asegurar que los productos de trabajo y los requisitos estén alineados


SG 1 Gestionar requisitos

Se gestionan los requisitos y se identifican las inconsistencias con los planes y productos de trabajo.

El grupo de trabajo mantiene un conjunto de requisitos vigente y aprobado

durante la vida del proyecto haciendo lo siguiente:

Gestionando todos los cambios a los requisitos.

Manteniendo las relaciones entre los requisitos, los planes, y los

productos de trabajo.

Asegurando que los requisitos, los planes, y los productos de trabajo

estén alineados.

Realizando acciones correctivas.

Si se implementan las áreas de proceso Prestación de Servicios, Gestión

Estratégica de Servicios, o Resolución y Prevención de Incidencias, sus

procesos generarán requisitos de las partes interesadas que también se

gestionan con los procesos de gestión de requisitos

Para más información sobre gestionar acciones correctivas hasta su cierre,


SP 1.1 Entender los requisitos

Entender el significado de los requisitos con los proveedores de

requisitos

A medida que el trabajo evoluciona y se derivan requisitos, todas las

actividades o disciplinas recibirán requisitos. Para evitar que haya un caos,

se establecen criterios para designar los canales o fuentes oficiales

apropiados desde las que se reciben requisitos. Quienes reciben requisitos

los analizan con el proveedor para asegurar que se llega a un

entendimiento mutuo y compartido de su significado. El resultado de estos

análisis y diálogos es un conjunto de requisitos aprobados.


1. Listas de criterios para distinguir qué proveedores de requisitos son

apropiados.

2. Criterios para evaluar y aceptar requisitos.

3. Resultados de los análisis con respecto a los criterios.

4. Un conjunto de requisitos aprobados.



Subprácticas

1. Establecer criterios para distinguir qué proveedores de requisitos son

apropiados.

2. Establecer criterios objetivos para evaluar y aceptar requisitos.

Extensión SSD

Para más información sobre analizar y validar requisitos, consúltese el


La falta de criterios de evaluación y de aceptación a menudo da lugar a una

verificación inadecuada, a rehacer el trabajo con un coste elevado, o al rechazo del

cliente.

Algunos ejemplos de criterios de evaluación y de aceptación son:

Claramente y correctamente establecidos.

Completos.

Consistentes entre sí.

Identificados unívocamente.

Consistentes con la arquitectura del sistema de servicio y las prioridades de los atributos de calidad.

Apropiados para su implementación.

Verificables (esto es, se pueden probar).

Trazables.

Alcanzables.

Vinculados al valor para el negocio.

Identificados por el cliente como prioritarios.

3. Analizar los requisitos para asegurar que se cumplen los criterios

establecidos.

4. Alcanzar un entendimiento con los proveedores de los requisitos

acerca de éstos, de forma que los participantes se puedan

comprometer con ellos.

SP 1.2 Obtener el compromiso con los requisitos

Obtener de los participantes el compromiso con los requisitos.

Para más información sobre monitorizar compromisos, consúltese el área

de proceso Monitorización y Control de Trabajos.

La práctica específica anterior se ocupó de llegar a un entendimiento con

los proveedores de requisitos. Esta práctica específica se ocupa de los

acuerdos y compromisos entre quienes llevan a cabo las actividades

necesarias para implementar los requisitos. Los requisitos evolucionan a lo

largo del trabajo. A medida que los requisitos evolucionan, esta práctica

específica asegura que los participantes se comprometen con los requisitos

vigentes y aprobados así como con los cambios resultantes en los planes

de trabajo, las actividades, y los productos de trabajo.




1. Evaluaciones de impacto de los requisitos.

2. Compromisos con los requisitos y los cambios a los requisitos

documentados.

Subprácticas

1. Evaluar el impacto que tienen los requisitos sobre los compromisos

existentes.

Se debería evaluar el impacto sobre los participantes cuando los requisitos cambian o

al inicio de un nuevo requisito.

2. Negociar y registrar los compromisos.

Los cambios a los compromisos existentes deberían negociarse antes de que los

participantes se comprometan con un nuevo requisito o un cambio

SP 1.3 Gestionar los cambios a los requisitos

Gestionar los cambios a los requisitos a medida que evolucionan.



Los requisitos se cambian por diversos motivos. A medida que cambian las

necesidades y el trabajo se desarrolla, es posible que se tengan que

realizar cambios a los requisitos existentes. Es esencial gestionar estas

extensiones y cambios de forma eficiente y eficaz. Para analizar

eficazmente el impacto de los cambios, es necesario que se conozca la

fuente de cada requisito y se documente la justificación del cambio. Puede

que el grupo de trabajo quiera seguir las medidas apropiadas de volatilidad

de requisitos para juzgar si es necesario un enfoque nuevo o actualizado

para controlar los cambios.


1. Peticiones de cambio a los requisitos.

2. Informes de impacto de los cambios a los requisitos.

3. Estado de los requisitos.

4. Base de datos de requisitos.

Subprácticas

1. Documentar todos los requisitos y cambios a los requisitos que el

grupo de trabajo recibe o genera.

2. Mantener un historial de cambios que incluya la justificación de los

mismos.

Mantener el historial de cambios ayuda seguir la volatilidad de los requisitos.

3. Evaluar el impacto que tienen los cambios a los requisitos desde el

punto de vista de las partes interesadas relevantes.

4. Poner los requisitos y los datos de los cambios a disposición del grupo

de trabajo.



SP 1.4 Mantener la trazabilidad bidireccional entre los requisitos

Mantener la trazabilidad bidireccional entre los requisitos y los

productos de trabajo.

Con esta práctica específica se intenta mantener la trazabilidad

bidireccional entre los requisitos (véase la definición de “trazabilidad

bidireccional” en el glosario). Cuando los requisitos se gestionan bien, se

puede establecer la trazabilidad desde un requisito fuente hasta sus

requisitos de más bajo nivel y de vuelta desde estos requisitos de más bajo

nivel hasta sus requisitos fuente. Esta trazabilidad bidireccional ayuda a

determinar si todos los requisitos fuente se han abordado por completo y si

todos los requisitos de menor nivel pueden trazarse hasta una fuente

válida.

La trazabilidad de los requisitos también cubre las relaciones con otras

entidades tales como productos de trabajo intermedios y finales, cambios

en la documentación de diseño, y planes de pruebas. La trazabilidad puede

cubrir relaciones horizontales, tales como relaciones entre interfaces, así

como relaciones verticales. La trazabilidad es particularmente necesaria al

evaluar el impacto que los cambios a los requisitos tienen sobre los

trabajos y productos de trabajo.

En un entorno de servicios, debería poder trazar los requisitos de las partes

interesadas hasta los elementos del servicio prestado y del sistema de

servicio que lo soporta que fueron desarrollados a partir de dichos

requisitos o de otros requisitos derivados de los requisitos de las partes

interesadas. A la inversa, los elementos del servicio prestado y del sistema

de servicio que lo soporta deberían ser trazables hacia atrás hasta los

requisitos de las partes interesadas que éstos satisfacen.

Algunos ejemplos de aspectos a considerar sobre la trazabilidad son:

Alcance de la trazabilidad: los límites dentro de los cuales es necesaria la trazabilidad.

Definición de trazabilidad: los elementos que necesitan relaciones lógicas.

Tipo de trazabilidad: cuándo se necesita trazabilidad horizontal y vertical.

Entorno de servicio integrado: El alcance de la trazabilidad aplicada a una organización

en la que los productos o elementos de producto tangibles son elementos integrales de

los servicios y los servicios son el elemento primordial de la organización.

La trazabilidad bidireccional no siempre está automatizada. Ésta se puede

llevar a cabo manualmente utilizando hojas de cálculo, bases de datos, u

otras herramientas comunes.


1. Matriz de trazabilidad de los requisitos.

2. Sistema de seguimiento de los requisitos.

Subprácticas

1. Mantener la trazabilidad de los requisitos para asegurar que se

documenta la fuente de los requisitos de menor nivel (esto es,

derivados).



2. Mantener la trazabilidad de los requisitos desde un requisito hasta sus

requisitos derivados y a sus productos de trabajo asignados.

Los productos de trabajo para los cuales se puede mantener la trazabilidad incluyen la

arquitectura del sistema de servicio, los componentes de sistema de servicio, las

iteraciones (o incrementos) del desarrollo, las funciones, las interfaces, los objetos, las

personas, los procesos, y otros productos de trabajo.

3. Generar una matriz de trazabilidad de requisitos.

Una matriz de trazabilidad puede tener en un eje la lista de los requisitos de las partes

interesadas y los requisitos derivados. El otro eje puede listar todos los componentes

de sistema de servicio, incluyendo las personas y los consumibles. Las intersecciones

entre filas y columnas indicarían a qué partes del sistema de servicio aplica un

requisito concreto.

SP 1.5 Asegurar que los productos de trabajo y los requisitos estén alineados

Asegurar que los planes y los productos de trabajo permanezcan

alineados con los requisitos

Esta práctica específica detecta inconsistencias entre los requisitos y los

planes de trabajo y productos de trabajo y emprende las acciones

correctivas para resolverlas.


1. Documentación sobre inconsistencias entre los requisitos y los planes

de trabajo y productos de trabajo, incluyendo las fuentes y

condiciones.


Subprácticas

1. Revisar si los planes de trabajo, las actividades, y los productos de

trabajo son consistentes con los requisitos y los cambios que éstos

han tenido.

2. Identificar la fuente de las inconsistencias (si existieran).

3. Identificar cualquier cambio que debiera realizarse en los planes y

productos de trabajo como resultado de cambiar la línea base de los

requisitos.

4. Iniciar cualquier acción correctiva que se necesite.


Gestión de Riesgos (RSKM) 335

GESTIÓN DE RIESGOS


Propósito

El propósito de Gestión de Riesgos (RSKM) es identificar problemas

potenciales antes de que ocurran de modo que, a lo largo de la vida del

producto o trabajo, se puedan planificar e invocar actividades de manejo de

riesgos según se necesite para mitigar los impactos adversos sobre el

logro de objetivos.


La gestión de riesgos es un proceso continuo y orientado hacia el futuro

que constituye una parte importante de la gestión de trabajos. La gestión

de riesgos debería abordar los problemas que podrían poner en peligro que

se logren los objetivos críticos. Un enfoque de gestión continua de riesgos

anticipa y mitiga de forma eficaz los riesgos cuyos impactos sobre el

trabajo pudieran ser críticos.

Una gestión de riesgos eficaz incluye identificar los riesgos temprana y

enérgicamente por medio de colaborar e involucrar a las partes interesadas

relevantes según se describe en el plan de involucración de las partes

interesadas descrito en el área de proceso Planificación de Trabajos. Se

necesita un fuerte liderazgo entre todas las partes interesadas relevantes

para establecer un entorno en el que se puedan divulgar y discutir los

riesgos libre y abiertamente.

La gestión de riesgos debería considerar fuentes de riesgo tanto internas

como externas, así como técnicas y no técnicas relacionadas con costes,

plazos, rendimiento, y otros aspectos. Es importante detectar los riesgos

temprana y enérgicamente porque habitualmente es más fácil, menos

costoso, y menos perjudicial hacer cambios y corregir tareas durante las

fases iniciales del ciclo de vida, en lugar de hacerlo en las fases

posteriores.

Por ejemplo, las decisiones relacionadas con la arquitectura del sistema de

servicio a menudo se toman de forma temprana antes de conocer por

completo el impacto que éstas puedan tener, y por tanto se deberían

considerar de forma minuciosa las implicaciones del riesgo que tienen tales

opciones.

Los estándares de la industria pueden ayudar en el momento de

determinar el modo de prevenir o mitigar los riesgos específicos

comúnmente encontrados en una industria concreta. Ciertos riesgos

pueden gestionarse o mitigarse proactivamente revisando las buenas

prácticas y lecciones aprendidas de la industria.

La gestión de riesgos se puede dividir en las siguientes partes:



Definir una estrategia de gestión de riesgos.

Identificar y analizar los riesgos.

Manejar los riegos identificados, incluyendo implementar planes de

mitigación de riesgos según se necesite.

Según se presenta en las áreas de proceso Planificación de Trabajos y

Monitorización y Control de Trabajos, las organizaciones se pueden centrar

inicialmente en identificar los riesgos para ser conscientes de los mismos y

reaccionar a medida que se materialicen. El área de proceso Gestión de

Riesgos describe la evolución de estas prácticas específicas hasta la

planificación, prevención, y mitigación sistemática de los riesgos a fin de

minimizar proactivamente los impactos que tienen sobre el trabajo.

Aunque el énfasis principal del área de proceso Gestión de Riesgos es el

grupo de trabajo, estos conceptos también se pueden aplicar para

gestionar los riesgos organizativos.





Servicio.





Para más información sobre monitorizar riesgos, consúltese el área de


Para más información sobre identificar riesgos y planificar la involucración

de las partes interesadas, consúltese el área de proceso Planificación de

Trabajos.


SG 1 Preparar la gestión de riesgos

SP 1.1 Determinar fuentes y categorías de riesgo

SP 1.2 Definir parámetros de riesgo

SP 1.3 Establecer una estrategia de gestión de riesgos

SG 2 Identificar y analizar riesgos

SP 2.1 Identificar riesgos

SP 2.2 Evaluar, categorizar, y priorizar los riesgos

SG 3 Mitigar riesgos

SP 3.1 Desarrollar planes de mitigación de riesgos

SP 3.2 Implementar planes de mitigación de riesgos




SG 1 Preparar la gestión de riesgos

Se lleva a cabo la preparación para gestionar los riesgos.

Prepararse para gestionar los riesgos por medio de establecer y mantener

una estrategia para identificar, analizar, y mitigar los riesgos.

Habitualmente esta estrategia se documenta en un plan de gestión de

riesgos. La estrategia de gestión de riesgos aborda las acciones

específicas y el enfoque de gestión que se utilizan para aplicar y controlar

el programa de gestión de riesgos. La estrategia habitualmente incluye

identificar las fuentes de riesgo, el esquema que se utiliza para categorizar

los riesgos, y los parámetros que se utilizan para evaluar, restringir, y

controlar los riesgos para manejarlos eficazmente.

SP 1.1 Determinar fuentes y categorías de riesgo

Determinar las fuentes y las categorías de riesgo.

Identificar las fuentes de riesgo proporciona una base para examinar de

forma sistemática las situaciones que cambian a lo largo del tiempo con el

fin de descubrir circunstancias que afecten a la capacidad del grupo de

trabajo de lograr sus objetivos. Las fuentes de riesgo son tanto internas

como externas al trabajo. A medida que el trabajo avanza, se pueden

identificar fuentes de riesgo adicionales. Establecer categorías para los

riesgos proporciona un mecanismo para recopilarlos y organizarlos,

además de asegurar que los gerentes escruten y presten atención de

forma apropiada a los riesgos que pudieran tener consecuencias serias

sobre el logro de los objetivos del trabajo.


1. Listas de fuentes de riesgo (externas e internas).

2. Lista de categorías de riesgo.

Subprácticas

1. Determinar las fuentes de riesgo.

Las fuentes de riesgo son los factores fundamentales que causan riesgos en los

trabajos o la organización. Hay muchas fuentes de riesgo, tanto internas como

externas al grupo de trabajo. Las fuentes de riesgo identifican dónde pueden

originarse los riesgos.



Algunas fuentes de riesgo internas y externas habituales son:

Requisitos inciertos.

Labores sin precedentes (p. ej., estimaciones no disponibles).

Diseño no factible.

Requisitos de atributos de calidad contrapuestos que afecten a la selección y al diseño de la solución del sistema de servicio.

Decisiones de arquitectura que afecten a los requisitos de atributos de calidad (p. ej. de capacidad y disponibilidad) del sistema de servicio, o a los objetivos de negocio.

Tecnología no disponible.

Estimaciones de plazos o asignaciones no realistas.

Personal y habilidades inadecuados.

Problemas de costes o de financiación.

Subcontratistas cuya capacidad sea incierta o inadecuada.

Suministradores cuya capacidad sea incierta o inadecuada.

Comunicación inadecuada con los clientes reales o potenciales o con sus representantes.

Alteraciones en la continuidad de las operaciones.

Restricciones reglamentarias (p. ej. seguridad, protección, medio ambiente)

Muchas de estas fuentes de riesgo son aceptadas sin planificarlo adecuadamente. La

identificación temprana de fuentes de riesgo tanto internas como externas puede

conducir a identificar riesgos de forma temprana. Los planes de mitigación de riesgos

se pueden implementar en etapas tempranas para prevenir que los riesgos ocurran o

para reducir las consecuencias cuando ocurren.

2. Determinar las categorías de riesgo.

Las categorías de riesgo son “botes” que se utilizan para recopilar y organizar los

riesgos. Identificar las categorías de riesgo ayuda a consolidar las futuras actividades

de los planes de mitigación de riesgos.

Al determinar las categorías de riesgo se pueden considerar los siguientes factores:

Fases del ciclo de vida del trabajo.

Tipos de proceso utilizados.

Tipos de producto utilizados.

Riesgos de gestión trabajos (p. ej., riesgos contractuales, riesgos de presupuesto, riesgos de plazos, riesgos de recursos).

Riesgos de desempeño técnico (p. ej. riesgos relacionados con atributos de calidad, riesgos de soportabilidad).

Se puede utilizar una taxonomía de riesgos para proporcionar un marco de trabajo

para determinar las fuentes y las categorías de riesgo.

SP 1.2 Definir parámetros de riesgo

Definir los parámetros que se utilizan para analizar y categorizar

los riesgos y para controlar la labor de gestión de riesgos.



Algunos parámetros para evaluar, categorizar, y priorizar los riesgos son:

Probabilidad del riesgo (esto es, probabilidad de que el riesgo ocurra).

Consecuencia del riesgo (esto es, impacto y gravedad de que el riesgo

ocurra).

Umbrales para desencadenar las actividades de gestión.

Los parámetros de riesgo se utilizan para proporcionar criterios comunes y

consistentes a fin de comparar los riesgos que se van a gestionar. Sin

estos parámetros es difícil medir la gravedad de un cambio no deseado

causado por un riesgo y priorizar las acciones requeridas para planificar la

mitigación del riesgo.

Los grupos de trabajo deberían documentar los parámetros que se utilizan

para analizar y categorizar los riesgos a fin de que estén disponibles como

referencia durante el trabajo, ya que las circunstancias cambian a lo largo

del tiempo. Al utilizar estos parámetros, los riesgos se pueden volver a

categorizar y analizar fácilmente cuando se producen cambios.

El grupo de trabajo puede utilizar técnicas como el análisis de modos y

efectos de fallos (FMEA) para examinar los riesgos de fallos potenciales en

el sistema de servicio o en los procesos de prestación de servicios

seleccionados. Estas técnicas pueden ayudar a proporcionar una disciplina

de trabajo con los parámetros de riesgo.


1. Criterios de evaluación, categorización, y priorización de riesgos.

2. Requisitos de gestión de riesgos (p. ej. niveles de control y

aprobación, intervalos de revaluación).

Subprácticas

1. Definir criterios consistentes para evaluar y cuantificar los niveles de

probabilidad y gravedad de los riesgos.

El uso de criterios consistentes (p. ej., intervalos de probabilidades, niveles de

gravedad) permite que los impactos de los diferentes riesgos se entiendan de una

misma forma, que se escruten a un nivel apropiado, y que la gerencia les preste la

atención prestablecida. Al gestionar riesgos dispares (p. ej. seguridad del personal

frente a contaminación ambiental), es importante asegurar que el resultado final sea

consistente (por ejemplo, un riesgo de contaminación ambiental de impacto alto es

igual de importante que un riesgo de seguridad del personal de impacto alto). Una

forma de proporcionar una base común para comparar riesgos dispares es asignar

valores económicos a los riesgos (p.ej., mediante un proceso de valoración monetaria

de los riesgos).

2. Definir umbrales para cada categoría de riesgo.

Para cada categoría de riesgo se pueden establecer umbrales que determinen si los

riesgos son aceptables o no, las prioridades de los riesgos, o los niveles para

desencadenar las acciones para gestionarlos.



Algunos ejemplos de umbrales son:

Se podrían establecer umbrales a fin de involucrar a la dirección cuando los costes excedan un 10 por ciento del objetivo o cuando los índices de rendimiento en costes (CPI) caigan por debajo de 0,95.

Se podrían establecer umbrales para los plazos a fin de involucrar a la dirección cuando los índices de rendimiento en plazos (SPI) caigan por debajo de 0,95.

Podrían establecerse umbrales de rendimiento a fin de involucrar a la dirección cuando los elementos clave especificados (p. ej., uso del procesador, tiempos medios de respuesta) superen el 125 por ciento de lo previsto en el diseño.

3. Establecer límites para definir los umbrales que se aplican en las

categorías.

Apenas hay restricciones sobre qué riesgos se evalúan de forma cuantitativa o

cualitativa. Definir límites (o condiciones de frontera) se puede usar para ayudar a

definir el alcance de la labor de gestión de riesgos evitando que se empleen excesivos

recursos. Los límites pueden incluir que se excluya una fuente de riesgos de una

categoría. Estos límites también pueden excluir las condiciones que ocurran con una

frecuencia inferior a una dada.

SP 1.3 Establecer una estrategia de gestión de riesgos

Establecer y mantener la estrategia que se utiliza para gestionar

los riesgos.

Una estrategia de gestión de riesgos exhaustiva aborda elementos tales

como:

El alcance de la labor de gestión de riesgos.

Los métodos y herramientas que se utilizan para identificar los riesgos,

analizarlos, mitigarlos, monitorizarlos, y comunicarlos.

Las fuentes de riesgo específicas del trabajo.

La forma en que los riesgos se van a organizar, categorizar, comparar,

y consolidar.

Los parámetros que se utilizan para realizar acciones en los riesgos

identificados, incluyendo la probabilidad, la consecuencia, y los

umbrales.

Las técnicas de mitigación de riesgos que se van a utilizar, tales como

prototipos, pilotos, simulación, diseños alternativos, o desarrollos

evolutivos.

La definición de las medidas de riesgos que se utilizan para monitorizar

el estado de los riesgos.

Los intervalos de tiempo para monitorizar o revaluar los riesgos.

La estrategia de gestión de riesgos debería estar guiada por una visión

común de qué es el éxito que describa qué resultados futuros del trabajo se

desean en términos de producto entregado, su coste, y su adecuación a la

tarea. La estrategia de gestión de riesgos a menudo está documentada en

un plan de gestión de riesgos de la organización o el grupo de trabajo. Esta



estrategia se revisa con las partes interesadas relevantes para promover

que se comprometan y la entiendan.

Una estrategia de gestión de riesgos debería ser desarrollada en etapas

tempranas del ciclo de vida del trabajo a fin de que los riesgos relevantes

sean identificados y gestionados proactivamente. La temprana

identificación y evaluación de riesgos críticos permite que el grupo de

trabajo formule estrategias de manejo de riesgos y ajuste la definición del

trabajo y la asignación de recursos en base a los riesgos críticos.


1. Estrategia de gestión de riesgos.

SG 2 Identificar y analizar riesgos

Los riesgos se identifican y analizan para determinar su importancia relativa.

El nivel de un riesgo afecta a los recursos que se asignan para manejarlo y

al momento en el que se requiere atención apropiada por parte de la

gerencia.

El análisis de riesgos implica identificar los riesgos a partir de las fuentes

internas y externas, y evaluar cada riesgo identificado para determinar su

probabilidad y sus consecuencias. Categorizar los riesgos, en base a

evaluarlos según las categorías de riesgo establecidas y los criterios

desarrollados en la estrategia de gestión de riesgos, proporciona la

información que se necesita para manejarlos. Los riesgos que están

relacionados se pueden agrupar para posibilitar que el manejo sea eficiente

y que los recursos de gestión de riesgos se usen eficazmente.


Identificar y documentar los riesgos.

Identificar los problemas potenciales, los peligros, las amenazas, y las

vulnerabilidades que podrían afectar negativamente a los trabajos o a los

planes es la base para una gestión de riesgos sólida y exitosa. Los riesgos

se deberían identificar y describir de forma comprensible antes de que se

puedan analizar y gestionar apropiadamente. Los riesgos se documentan

con una descripción concisa que incluya el contexto, las condiciones, y las

consecuencias de la ocurrencia del riesgo.

La identificación de riesgos se debería realizar mediante un enfoque

organizado y minucioso a fin de buscar riesgos de no lograr los objetivos

que sean probables o realistas. Para que sea eficaz, la identificación de

riesgos no debería intentar abordar cada posible suceso. El uso de las

categorías y parámetros desarrollados en la estrategia de gestión de

riesgos y las fuentes de riesgo identificadas puede proporcionar la

disciplina y agilidad que son apropiadas para la identificación de riesgos.

Los riesgos identificados constituyen una línea base para iniciar las

actividades de gestión de riesgos. Los riesgos se deberían revisar

periódicamente para reexaminar posibles fuentes de riesgo y condiciones

cambiantes a fin de descubrir fuentes y riesgos que se omitieron



previamente o que no existían la última vez que la estrategia de gestión de

riesgos se actualizó.

La identificación de riesgos se centra en identificar riesgos, no en asignar

culpables. Los resultados de las actividades de identificación de riesgos

nunca deberían ser usados por la gerencia para evaluar el desempeño

individual.

Se utilizan muchos métodos para identificar riesgos. Algunos métodos habituales de

identificación son:

Examinar cada elemento de la estructura de descomposición del trabajo.

Llevar a cabo una evaluación de riesgos utilizando una taxonomía de riesgos.

Entrevistar a expertos en la materia.

Revisar las labores de gestión de riesgos de productos similares.

Examinar los documentos o bases de datos de lecciones aprendidas.

Examinar las especificaciones de diseño y los requisitos del acuerdo.


1. Lista de riesgos identificados, incluyendo el contexto, las condiciones,

y las consecuencias de la ocurrencia de los riesgos.

Subprácticas

1. Identificar los riesgos asociados con los costes, los plazos, y el

rendimiento.

Los riesgos asociados con los costes, los plazos, el rendimiento, y los otros objetivos

de negocio se deberían examinar para entender el efecto que producen sobre los

objetivos del trabajo. Se pueden descubrir riesgos candidatos que estén fuera del

alcance de los objetivos del trabajo pero que sean vitales para los intereses del

cliente. Por ejemplo, los riesgos de costes de desarrollo, costes de adquisición de

productos, costes de productos de repuesto (o de sustitución), y costes de retirada (o

de eliminación) de productos tienen implicaciones en el diseño.

El cliente puede no haber considerado el coste total de mantener un producto

operativo o de utilizar el servicio que se le presta. El cliente debería estar informado

de este tipo de riesgos, aunque puede que no sea necesario gestionarlos de forma

activa. Los mecanismos para tomar estas decisiones se deberían examinar a nivel de

trabajo y de organización y poner en práctica si se considera apropiado,

especialmente para los riesgos que afecten a la capacidad del grupo de trabajo de

verificar y validar el producto.

Además de los riesgos de costes identificados previamente, se pueden incluir otros

riesgos de costes asociados con los niveles de financiación, las estimaciones de

financiación, y los presupuestos distribuidos.

También se deberían considerar los riesgos asociados con los acuerdos de servicio,

tales como las dependencias de suministro, los procesos del cliente, y los niveles de

servicio no realistas.

Los riesgos de plazos pueden incluir los riesgos asociados con las actividades

planificadas, los eventos clave, y los hitos.



Los riesgos de rendimiento pueden incluir riesgos asociados con:

Interrupciones en el servicio.

Cumplir los niveles de servicio.

Impactos de los procesos del cliente.

Requisitos.

Análisis y diseño.

Aplicación de tecnología nueva.

Tamaño físico.

Forma.

Peso.

Manufactura y fabricación.

Comportamiento y operación del sistema de servicio con respecto a la funcionalidad o a los atributos de calidad.

Verificación.

Validación.

Atributos de mantenimiento del rendimiento.

Los atributos de mantenimiento del rendimiento son aquellas características que

permiten que el producto o servicio en uso proporcione el rendimiento requerido, tal

como mantener el rendimiento de la protección y seguridad.

Hay riesgos que no encajan en las categorías de costes, plazos, o rendimiento, sino

que pueden asociarse a otros aspectos de las operaciones de la organización.

Algunos ejemplos de estos otros riesgos incluyen los relacionados con:

Dependencias con recursos provistos por el cliente (p. ej. equipamiento, instalaciones).

Capacidad de recuperación operativa.

Dependencias con los suministradores.

Exceso de depender de personas clave.

Huelgas.

Fuentes de suministro decrecientes.

Tiempo de ciclo tecnológico.

Competencia.

2. Revisar los elementos ambientales que puedan afectar al trabajo.

Entre los riesgos que se olvidan con frecuencia están los riesgos que supuestamente

están fuera del alcance del grupo de trabajo (esto es, el grupo de trabajo no controla

si ocurren pero puede mitigar su impacto). Estos riesgos pueden tener que ver con la

climatología o los desastres naturales, los cambios políticos, y los fallos en las

telecomunicaciones.

3. Revisar todos los elementos de la estructura de descomposición del

trabajo como parte de identificar los riesgos para ayudar a asegurar

que se han tenido en cuenta todos los aspectos del trabajo.



4. Revisar todos los elementos del plan de trabajo como parte de

identificar los riesgos para ayudar a asegurar que se han tenido en

cuenta todos aspectos del trabajo.

Para más información sobre identificar riesgos, consúltese el área de


5. Documentar el contexto, las condiciones, y las consecuencias

potenciales de cada riesgo.

Las descripciones de los riesgos normalmente se documentan en un formato estándar

que contiene el contexto, las condiciones, y las consecuencias de la ocurrencia de los

riesgos. El contexto del riesgo proporciona información adicional acerca del riesgo, tal

como el marco temporal relativo del riesgo, las circunstancias o condiciones que

rodean al riesgo que han provocado la preocupación, y cualquier duda o

incertidumbre.

6. Identificar a las partes interesadas relevantes asociadas a cada riesgo.

SP 2.2 Evaluar, categorizar, y priorizar los riesgos

Evaluar y categorizar cada riesgo identificado utilizando las

categorías y los parámetros de riesgo definidos, y determinar su

prioridad relativa.

La evaluación de los riesgos es necesaria para asignar a cada riesgo

identificado su importancia relativa y se utiliza para determinar cuándo se

requiere la atención apropiada por parte de la gerencia. A menudo es útil

agrupar riesgos en base a sus interrelaciones y desarrollar opciones a nivel

agregado. Cuando se crea un riesgo agregado a partir de un conjunto de

riesgos de más bajo nivel, se debería tener cuidado para asegurar que no

se ignoren riesgos importantes en el nivel más bajo.

Colectivamente, las actividades de evaluación, categorización, y

priorización de riesgos a veces se denominan “evaluación de riesgos” o

“análisis de riesgos”.


1. Lista de riesgos y sus prioridades asignadas.

Subprácticas

1. Evaluar los riesgos identificados utilizando los parámetros de riesgo

definidos.

Se evalúa y se asignan valores a cada riesgo conforme a los parámetros de riesgo

definidos, entre los cuales se puede incluir a la probabilidad, la consecuencia (esto es,

gravedad, impacto), y los umbrales. Los valores asignados a los parámetros de riesgo

se pueden integrar para producir medidas adicionales, tales como la exposición al

riesgo (esto es, la combinación de probabilidad y consecuencia), las cuales pueden

utilizarse para priorizar los riesgos con objeto de manejarlos.

Con frecuencia se utiliza una escala de tres a cinco valores para evaluar tanto la

probabilidad como la consecuencia.



Por ejemplo, la probabilidad puede categorizarse como remota, improbable, probable, altamente probable, o casi certeza.

Algunos ejemplos de categorías para la consecuencia son:

Baja.

Media.

Alta.

Despreciable.

Marginal.

Significativa.

Crítica.

Catastrófica.

Frecuentemente se utilizan valores de probabilidad para cuantificar la certeza.

Generalmente las consecuencias están relacionadas con costes, plazos, impacto

medioambiental, o medidas de personas (p. ej., horas laborales perdidas, gravedad de

la lesión).

La evaluación de riesgos es a menudo una tarea difícil y que consume tiempo. Para

evaluar riesgos y adquirir confianza en la priorización puede que se requieran

experiencias o técnicas de grupo específicas. Además, puede que haga falta revaluar

las prioridades a lo largo del tiempo. Para proporcionar una base que permita

comparar los impactos de que se realicen los riesgos identificados, las consecuencias

de los riesgos se pueden traducir a unidades monetarias.

2. Categorizar y agrupar los riesgos de acuerdo a las categorías de

riesgo definidas.

Los riesgos se clasifican por medio de las categorías de riesgo definidas,

proporcionando un medio para revisarlos en base a su fuente, taxonomía, o

componente. Los riesgos relacionados o equivalentes se pueden agrupar para

manejarlos de forma eficiente. Las relaciones causa-efecto entre riesgos relacionados

se documentan.

3. Priorizar los riesgos para su mitigación.

Se establece una prioridad relativa para cada riesgo en base a los parámetros de

riesgo asignados. Se deberían utilizar criterios claros para determinar la prioridad de

los riesgos. La priorización de los riesgos ayuda a determinar las áreas más eficaces

en las cuales los recursos de mitigación de riesgos se pueden aplicar con el mayor

impacto positivo sobre el trabajo.

SG 3 Mitigar riesgos

Los riesgos se gestionan y mitigan según sea apropiado para reducir los impactos adversos sobre el logro de los objetivos.

Los pasos para manejar los riesgos incluyen desarrollar opciones para

manejarlos, monitorizar riesgos, y realizar las actividades de manejos de

riesgos cuando los umbrales definidos se sobrepasan. Los planes de

mitigación de riesgos se desarrollan e implementan para riesgos

seleccionados a fin de reducir proactivamente el impacto potencial de la



ocurrencia del riesgo. Planificar la mitigación de riesgos también puede

incluir los planes de contingencia para abordar el impacto de los riesgos

seleccionados que a pesar de los intentos para mitigarlos puedan ocurrir.

Los parámetros de riesgo utilizados para desencadenar las actividades de

manejo de riesgos están definidos en la estrategia de gestión de riesgos.

SP 3.1 Desarrollar planes de mitigación de riesgos

Desarrollar planes de mitigación de riesgos conforme a la

estrategia de gestión de riesgos.

Un componente crítico de planificar la mitigación de riesgos es desarrollar

líneas de acción alternativas, soluciones temporales, y puntos de

recuperación, así como una línea de acción recomendada para cada riesgo

crítico. El plan de mitigación de riesgos para un riesgo dado incluye las

técnicas y métodos utilizados para evitar, reducir, y controlar la

probabilidad de que ocurra el riesgo, el grado del daño producido en caso

de que ocurra (a veces llamado “plan de contingencia”), o ambos. Los

riesgos se monitorizan y, si se sobrepasan los umbrales establecidos, los

planes de mitigación de riesgos se despliegan para devolver la tarea

afectada a un nivel de riesgo aceptable. Si el riesgo no pudiera mitigarse,

se podría invocar a un plan de contingencia. Con frecuencia, tanto los

planes de mitigación de los riesgos como los de contingencia se generan

sólo para los riesgos seleccionados en los que las consecuencias de los

riesgos sean altas o inaceptables. Puede que otros riesgos sean

aceptables y simplemente se monitoricen.

Las opciones para tratar los riesgos habitualmente incluyen alternativas tales como:

Evitar el riesgo: cambiar o reducir los requisitos a la vez que se siguen cumpliendo las

necesidades del usuario final.

Controlar el riesgo: llevar a cabo actividades para minimizar los riesgos.

Transferir el riesgo: reasignar requisitos para reducir los riesgos.

Monitorizar el riesgo: vigilar y revaluar periódicamente los cambios que se han

asignado a los parámetros de riesgo.

Aceptar el riesgo: reconocer el riesgo pero no realizar ninguna acción.

A menudo, especialmente para riesgos de alto impacto, se deberían

generar varios enfoques para manejar un riesgo.

Por ejemplo, en el caso de un evento que altere la continuidad de las operaciones, algunos

enfoques que se podrían establecer para manejar el riesgo son:

Recursos de reserva para responder a las alteraciones.

Listas de equipos de respaldo disponibles.

Respaldo para el personal clave.

Planes para probar los sistemas de respuesta para emergencias.

Procedimientos de emergencia publicados.

Listas distribuidas de contactos clave y recursos de información para emergencias.



En muchos casos, los riesgos son aceptados o vigilados. Generalmente el

riesgo se acepta cuando se juzga que es demasiado bajo para mitigarlo

formalmente, o cuando parezca que no existe ninguna manera viable de

reducirlo. Si un riesgo se acepta, se debería documentar la justificación.

Los riesgos se vigilan cuando hay un umbral definido objetivamente,

verificable, y documentado (p. ej. del coste, el plazo, el rendimiento, la

exposición al riesgo) que active el plan de mitigación de riesgos o invoque

a un plan de contingencia.

Para más información sobre evaluar alternativas y seleccionar soluciones,

consúltese el área de proceso Análisis de Decisiones y Resolución.

Se deberían considerar de forma temprana las demostraciones de

tecnología, los modelos, las simulaciones, los pilotos, y los prototipos como

parte de planificar la mitigación de riesgos.


1. Opciones documentadas para manejar cada riesgo identificado.

2. Planes de mitigación de riesgos.

3. Planes de contingencia.

4. Lista de personas responsables de seguir y manejar cada riesgo.

Subprácticas

1. Determinar los niveles y los umbrales que definen cuándo un riesgo

pasa a ser inaceptable y que activan la ejecución del plan de

mitigación de riesgos o el plan de contingencia.

El nivel de riesgo (obtenido a partir de un modelo de riesgos) es una medida que

combina la incertidumbre de lograr un objetivo con las consecuencias de no lograrlo.

Los niveles y los umbrales de riesgo que acotan los costes, los plazos, o el

rendimiento planificados o aceptables se deberían comprender y definir claramente

con el fin de proporcionar un medio con el cual el riesgo sea comprensible.

Categorizar los riesgos adecuadamente es esencial para asegurar que las prioridades

en base a la gravedad y las respuestas de la gerencia asociadas sean apropiadas. Se

pueden emplear varios umbrales para iniciar distintos niveles de respuesta de la

gerencia. Habitualmente, los umbrales para ejecutar los planes de mitigación de

riesgos se establecen de tal forma que éstos se alcancen antes de que se ejecuten

los planes de contingencia.

2. Identificar a la persona o al grupo responsable de tratar cada riesgo.

3. Determinar para cada riesgo los costes y los beneficios de

implementar el plan de mitigación de riesgos.

Las actividades de mitigación de riesgos se deberían examinar en cuanto a los

beneficios que proporcionan frente a los recursos que requieren. Al igual que en

cualquier otra actividad de diseño, puede que sea necesario desarrollar planes

alternativos así como evaluar los costes y beneficios de cada una de las alternativas.

Se selecciona para su implementación el plan más apropiado.



4. Desarrollar un plan general de mitigación de riesgos para el trabajo a

fin de coordinar la implementación de los planes individuales de

mitigación y contingencia de cada riesgo.

Puede que no sea asequible abordar el conjunto completo de planes de mitigación de

riesgos. Se debería realizar un análisis de contraprestaciones para priorizar los planes

de mitigación de riesgos que se van a implementar.

5. Para los riesgos críticos seleccionados, desarrollar planes de

contingencia en el caso de que se realicen los impactos.

Los planes de mitigación de riesgos se desarrollan y se implementan según se

necesite para reducir de forma proactiva los riesgos antes de que se conviertan en

problemas. Es posible que a pesar de todos los esfuerzos algunos riesgos sean

inevitables y se conviertan en problemas que afecten al trabajo. Se pueden desarrollar

planes de contingencia para los riesgos críticos a fin de describir las acciones que un

grupo de trabajo puede adoptar para afrontar el impacto de que ocurran. La intención

es definir un plan proactivo para manejar el riesgo. El riesgo se reduce (mitigación) o

se trata (contingencia). En cualquier caso el riesgo se gestiona.

Parte de la literatura de gestión de riesgos considera los planes de contingencia como

un sinónimo o subconjunto de los planes de mitigación de riesgos. Estos planes

también se pueden tratar de forma conjunta como planes de manejo de riesgos o

como planes de acción de riesgos.

SP 3.2 Implementar planes de mitigación de riesgos

Monitorizar periódicamente el estado de cada riesgo e implementar

el plan de mitigación de riesgos según sea apropiado.

Con objeto de controlar y gestionar eficazmente los riesgos durante el

trabajo, siga un programa proactivo para monitorizar regularmente los

riesgos y el estado y resultados de las acciones de manejo de riesgos. La

estrategia de gestión de riesgos define los intervalos en los que se

deberían volver a revisar los estados de los riesgos. Esta actividad puede

dar como resultado el descubrimiento de nuevos riesgos o de nuevas

opciones de manejo de riesgos que pueden requerir que se replanifique y

se reevalúe. En cualquiera de ambos casos, los umbrales de aceptabilidad

asociados al riesgo se deberían comparar con el estado del riesgo a fin de

determinar la necesidad de implementar un plan de mitigación de riesgos.


1. Listas actualizadas de estados de los riesgos.

2. Evaluaciones actualizadas de la probabilidad, la consecuencia, y los

umbrales de los riesgos.

3. Lista actualizada de las opciones de manejo de riesgos.

4. Lista actualizada de las acciones realizadas para manejar los riesgos.

5. Planes de mitigación de riesgos de las opciones de manejo de riesgos.



Subprácticas

1. Monitorizar el estado de los riesgos.

Después de que se inicie un plan de mitigación de riesgos, el riesgo se continúa

monitorizando. Los umbrales se evalúan para comprobar la ejecución potencial de un

plan de contingencia.

Se debería emplear un mecanismo de monitorización.

2. Proporcionar un método para seguir hasta su cierre las acciones

individuales abiertas de manejo de riesgos.



Trabajos.

3. Invocar las opciones de manejo de riesgos seleccionadas cuando los

riesgos monitorizados excedan los umbrales definidos.

A menudo el manejo de riesgos solamente se realiza para riesgos considerados como

altos y medios. La estrategia de manejo de riesgos para un riesgo determinado puede

incluir el uso de técnicas y métodos para evitar, reducir, y controlar la probabilidad del

riesgo, el grado del daño sufrido en caso de que ocurra el riesgo, o ambas cosas. En

este contexto, el manejo de riesgos incluye tanto los planes de mitigación de riesgos

como los planes de contingencia.

Las técnicas de manejo de riesgos se desarrollan para evitar, reducir, y controlar el

impacto adverso sobre los objetivos del trabajo y para conseguir resultados

aceptables si se producen impactos. Las acciones generadas para manejar un riesgo

requieren que se aumenten de forma apropiada la carga de los recursos y los plazos

en los planes y en las líneas base de los plazos. Esta replanificación debería tener

muy en cuenta los efectos producidos sobre las actividades o iniciativas de trabajo

adyacentes o dependientes.

4. Establecer un cronograma o un período de realización para cada

actividad de manejo de riesgos que incluya una fecha de inicio y una

fecha prevista de finalización.

5. Comprometer de forma continuada los recursos para cada plan que

permitan que las actividades de manejo de riesgos se ejecuten con

éxito.

6. Recopilar medidas de rendimiento sobre las actividades de manejo de

riesgos.


Gestión de Acuerdos de Suministro (SAM) 350

GESTIÓN DE ACUERDOS DE SUMINISTRO


Propósito

El propósito de Gestión de Acuerdos de Suministro (SAM) es gestionar la

adquisición de productos y servicios a suministradores.


El alcance de esta área de proceso aborda la adquisición de productos,

servicios, y componentes de producto y de servicio que pueden ser

entregados al cliente del servicio o ser incluidos en un producto o un

sistema de servicio. Las prácticas de esta área de proceso también se

pueden utilizar para otros propósitos que beneficien al servicio (p.ej. para

comprar consumibles).

Esta área de proceso no se aplica en todos los contextos en los que se

adquieren componentes comerciales (COTS), pero sí se aplica en los

casos en que se hagan modificaciones a los componentes (COTS)

comerciales, gubernamentales, o al software gratuito cuyo valor para el

trabajo sea significativo o que representen un riesgo significativo.

En todas las áreas de proceso, cuando se utilizan los términos “producto” y

“componente de producto”, sus significados también abarcan los servicios,

los sistemas de servicio, y sus componentes.

El área de proceso Gestión de Acuerdos de Suministro engloba las


Determinar el tipo de adquisición.

Seleccionar suministradores.

Establecer y mantener acuerdos con los suministradores.

Ejecutar los acuerdos de suministro.

Aceptar la entrega de los productos adquiridos.

Asegurar que se haga con éxito la transición de los productos

adquiridos.



Algunos ejemplos de productos tangibles e intangibles que el grupo de trabajo puede

adquirir para que formen parte del servicio prestado al cliente o formen parte del sistema de

servicio son:

Mantenimiento de una parte especializada del equipamiento por medio de un acuerdo

de nivel de servicio con un suministrador externo como parte de un servicio de

mantenimiento de instalaciones.

Capacitación a los usuarios de un servicio, en el que la capacitación la imparta un

suministrador interno como parte de un acuerdo de nivel de operación (OLA)24.

Servicios de enfermería en un hospital suministrados mediante un acuerdo de

externalización.

Comidas y refrescos en una conferencia suministrados mediante un contrato de

catering.

Equipo de comunicaciones que un agente comercial compra y entrega al recibir un

pedido.

Gasolina que se vende en una estación de servicio.

Automóviles que un servicio de entregas va a entregar según se solicitó.

Cajeros automáticos en un banco.

Componentes de un motor de búsqueda basado en web.

Aviones en una línea aérea.

Coches en una oficina de alquiler de automóviles.

Habitualmente, los productos a adquirir se determinan en las fases iniciales

de la planificación y desarrollo del sistema de servicio.

Esta área de proceso no aborda directamente las situaciones en las que un

suministrador está integrado en el grupo de trabajo y utiliza los mismos

procesos y depende de los mismos gerentes que los miembros del grupo

de trabajo. Estas situaciones son manejadas habitualmente por otros

procesos o funciones (p. ej. procesos de gestión de trabajos, procesos o

funciones externas al grupo de trabajo), aunque algunas de las prácticas

específicas de esta área de proceso pueden resultar útiles para gestionar

el acuerdo de suministro.

Habitualmente esta área de proceso no se implementa para abordar

acuerdos en los que el cliente del grupo de trabajo es, a su vez, un

suministrador. Para manejar estas situaciones habitualmente se realizan

acuerdos informales con el cliente, o dentro del acuerdo global que el

grupo de trabajo tiene con el cliente se especifica qué elementos va a

suministrar el cliente. En este último caso, puede que sea útil aplicar

algunas de las prácticas de esta área de proceso para gestionar el

acuerdo, aunque aplicar otras pueden no serlo debido fundamentalmente a

la distinta relación que se tiene con los clientes frente a la que se tendría

con suministradores normales. Para más información sobre otros tipos de

acuerdo, consúltese el modelo CMMI-ACQ.

24

Operating Level Agreement (N. del T.)



Dependiendo de las necesidades del negocio, los suministradores pueden

ser de muchos tipos, incluyendo suministradores internos (esto es,

suministradores que están en la misma organización pero son externos al

grupo de trabajo), departamentos de fabricación, suministradores de

bibliotecas de reutilización, y suministradores comerciales (véase la

definición de “suministrador” en el glosario).

Un acuerdo de suministro se establece para gestionar la relación entre la

organización y el suministrador. Un acuerdo de suministro es cualquier

acuerdo escrito entre la organización (representando al grupo de trabajo) y

el suministrador. Este acuerdo puede consistir en un contrato, una licencia,

un acuerdo de nivel de servicio, o un memorando de acuerdo. El

suministrador entrega el producto adquirido conforme al acuerdo de

suministro (véase la definición de “acuerdo de suministro” en el glosario).


Extensión SSD


partes interesadas y desarrollar el sistema de servicio, consúltese el área

de proceso Desarrollo del Sistema de Servicio.

Para más información sobre mantener la trazabilidad bidireccional entre los

requisitos, consúltese el área de proceso Gestión de Requisitos.





SG 1 Establecer acuerdos de suministro

SP 1.1 Determinar el tipo de adquisición

SP 1.2 Seleccionar suministradores

SP 1.3 Establecer acuerdos de suministro

SG 2 Satisfacer los acuerdos de suministro

SP 2.1 Ejecutar el acuerdo de suministro

SP 2.2 Aceptar el producto adquirido

SP 2.3 Asegurar la transición de productos


SG 1 Establecer acuerdos de suministro

Se establecen y mantienen acuerdos con los suministradores.

SP 1.1 Determinar el tipo de adquisición

Determinar el tipo de adquisición para cada producto o

componente de producto que se va a adquirir.

Se pueden utilizar muchos tipos de adquisición para adquirir los productos

y componentes de producto que se pueden utilizar en los trabajos.



Algunos ejemplos de tipos de adquisición son:

Obtener servicios de otra área dentro de la compañía.

Comprar componentes comerciales (COTS) modificados.

Obtener productos mediante un acuerdo de suministro.

Obtener productos de un suministrador interno.

Obtener productos del cliente.

Obtener productos de un suministrador preferente.

Combinar varios de los tipos anteriores (p. ej. contratar la modificación de un producto

COTS, pedir a otra área de la compañía que co-desarrolle productos junto a un

suministrador externo).

Si se adquieren productos COTS modificados de gran valor para el trabajo,

o que representen riesgos importantes para el proyecto, puede que sea

crítico para el trabajo velar por la evaluación y selección de estos productos

y su suministrador. Al decidir cuál se selecciona se deberían considerar

aspectos que incluyan los problemas de propiedad y la disponibilidad de

los productos.


1. Lista de tipos de adquisición que se utilizarán para todos los productos

y componentes de producto que se adquirirán.

SP 1.2 Seleccionar suministradores

Seleccionar suministradores en base a evaluar su capacidad para

cumplir los requisitos especificados y los criterios establecidos.

Extensión SSD



de Servicio.





Se deberían establecer criterios para abordar qué factores son importantes

para el trabajo.

Algunos ejemplos de factores que pueden ser importantes para el trabajo son:

Localización geográfica del suministrador.

Registros de desempeño del suministrador en trabajos similares.

Capacidades de ingeniería.

Personal e instalaciones disponibles para realizar el trabajo.

Experiencias previas en situaciones similares.

Satisfacción de los clientes con productos similares entregados por el suministrador.




1. Estudios de mercado.

2. Lista de suministradores candidatos.

3. Lista de suministradores preferentes.

4. Estudio de contraprestaciones u otros registros con criterios de

evaluación, ventajas e inconvenientes de los suministradores

candidatos, y justificación de la selección de suministradores.

5. Materiales y requisitos de licitación.

Subprácticas

1. Establecer y documentar los criterios para evaluar los suministradores

potenciales.

2. Identificar los suministradores potenciales y distribuirles el material y

los requisitos de licitación.

Una manera proactiva de realizar esta actividad es llevar a cabo investigaciones de

mercado para identificar fuentes potenciales de productos candidatos para su

adquisición.

3. Evaluar las propuestas conforme a los criterios de evaluación.

4. Evaluar los riesgos asociados a cada suministrador propuesto.



5. Evaluar la capacidad que los suministradores propuestos tienen para

realizar el trabajo.

Algunos ejemplos de métodos utilizados para evaluar las facultades que un suministrador propuesto tiene para realizar el trabajo son:

Evaluar las experiencias anteriores en aplicaciones similares.

Evaluar la satisfacción de los clientes con los productos similares proporcionados.

Evaluar el desempeño previo en trabajos similares.

Evaluar las habilidades de gestión.

Evaluaciones de capacidad.

Evaluar el personal disponible para realizar el trabajo.

Evaluar las instalaciones y los recursos disponibles.

Evaluar la capacidad que tiene el grupo de trabajo para trabajar con el suministrador propuesto.

Evaluar el impacto de los productos COTS candidatos sobre el plan de trabajo y los compromisos.



Cuando se evalúan productos COTS modificados, considerar:

Coste de los productos COTS modificados.

Coste y esfuerzo para incorporar los productos COTS modificados dentro del trabajo.

Requisitos de seguridad.

Beneficios e impactos que pueden resultar de futuras versiones del producto.

Las futuras versiones de los productos COTS modificados pueden proporcionar

características adicionales que den soporte a las mejoras del trabajo que se hayan

planificado o previsto, pero también pueden dar lugar a que el suministrador deje de

dar soporte a la versión actual.

6. Seleccionar el suministrador.

SP 1.3 Establecer acuerdos de suministro

Establecer y mantener los acuerdos de suministro.

Un acuerdo de suministro es cualquier acuerdo escrito entre la

organización (representando al trabajo) y el suministrador. Este acuerdo

puede ser un contrato, una licencia, un acuerdo de nivel de servicio, o un

memorando de acuerdo.

En el contenido del acuerdo de suministro se debería especificar lo que se

ha dispuesto sobre seleccionar los procesos y productos de trabajo del

suministrador que se van a monitorizar, analizar, y evaluar, en caso de que

lo dispuesto sea apropiado para la adquisición o el producto que se está

adquiriendo. El acuerdo de suministro también debería especificar qué

revisiones, monitorización, evaluaciones, y pruebas de aceptación se van a

realizar.

Se deberían monitorizar los procesos del suministrador que sean críticos

para que el trabajo tenga éxito (p. ej. por su complejidad, por su

importancia).

Los servicios adquiridos se pueden prestar directamente a los clientes o

usuarios finales del proveedor de servicios. El contenido del acuerdo de

suministro de tales servicios adquiridos debería especificar si el proceso de

aceptación se realizará antes, durante, o después de que el suministrador

los preste. Si el suministrador va a prestar servicios al cliente continua o

repetidamente, el contenido también debería especificar cuándo o cada

cuánto tiempo se ejecutará el proceso de aceptación (p. ej. cada vez que

se preste el servicio, en momentos prestablecidos o aleatorios para un

subconjunto de los servicios prestados).

Antes de aprobar los acuerdos de suministro entre entidades legales

independientes habitualmente éstos son revisados por asesores legales o

asesores de contratación.

Los acuerdos de suministro deberían abordar la terminación, la terminación

anticipada, y la transición del servicio según sea apropiado.




1. Declaraciones de trabajo.

2. Contratos.

3. Memorandos de acuerdo.

4. Acuerdos de licencia.

Subprácticas

1. Actualizar los requisitos (p. ej. requisitos de producto, requisitos de

nivel de servicio) que el suministrador debe cumplir para que reflejen

las negociaciones con el suministrador cuando sea necesario.

Extensión SSD


partes interesadas, consúltese el área de proceso Desarrollo del


Para más información sobre gestionar los requisitos de producto y de

componentes de producto del proyecto y asegurar que dichos

requisitos estén alineados con los planes de proyecto y los productos

de trabajo, consúltese el área de proceso Gestión de Requisitos.

2. Documentar qué va a proporcionar el grupo de trabajo al

suministrador.

Incluir lo siguiente:

Instalaciones proporcionadas por el grupo de trabajo.

Documentación.

Servicios.

3. Documentar el acuerdo de suministro.

El acuerdo de suministro debería incluir una declaración de trabajo, una

especificación, unos términos y condiciones, una lista de entregables, un cronograma,

un presupuesto, y un proceso de aceptación definido.



Habitualmente este subpráctica incluye realizar las siguientes tareas:

Identificar los requisitos, el alcance, los niveles de servicio, y los procesos de comunicación específicos que el suministrador va a proporcionar.

Alinear los acuerdos de nivel de servicio del subcontratista con los acuerdos de nivel de servicio del contratista.

Asegurar que las responsabilidades de manejo de riegos fluyan hasta los suministradores según sea apropiado.

Revisar los aspectos legales del acuerdo de suministro en caso necesario para asegurar que se está conforme con ellos y que obligan al suministrador.

Identificar el tipo y el grado de supervisión al suministrador, incluyendo los procesos seleccionados que se van a monitorizar y los productos seleccionados que se van a evaluar (así como los procedimientos y criterios de evaluación correspondientes que se van a utilizar).

Establecer la declaración del trabajo, la especificación, los términos y condiciones, la lista de entregables, el cronograma, el presupuesto, y el proceso de aceptación.

Identificar quiénes son responsables y están autorizados para hacer cambios en el acuerdo de suministro por parte del grupo del trabajo y del suministrador.

Identificar el modo en que se determinarán, comunicarán, y abordarán los cambios a los requisitos y los cambios al acuerdo de suministro.

Identificar los estándares y procedimientos que se van a seguir.

Identificar las dependencias críticas que haya entre el trabajo y el suministrador.

Identificar los tipos de revisión que se van a llevar a cabo con el suministrador.

Identificar qué responsabilidades tiene el suministrador sobre mantener y dar soporte continuo a los productos adquiridos.

Identificar la garantía, la propiedad, y los derechos de uso de los productos adquiridos.

Identificar los criterios de aceptación.

En algunos casos la selección de productos COTS modificados puede requerir un acuerdo de suministro adicional a los acuerdos establecidos en la licencia del producto. Algunos ejemplos de qué podría cubrir un acuerdo con un suministrador de COTS son:

Descuentos por volumen de compras.

Qué partes interesadas relevantes están cubiertas por el acuerdo de licencia, incluyendo los suministradores, los miembros del equipo, y el cliente.

Planes de futuras mejoras.

Soporte in situ, tal como responder a consultas e informes de problema.

Capacidades adicionales que no tenga el producto.

Soporte de mantenimiento, incluyendo soporte después de que el producto deje de estar disponible globlalmente.

4. Revisar periódicamente el acuerdo de suministro para asegurar que

refleja con precisión la relación que existe entre el grupo de trabajo y

el suministrador, así como los riesgos y condiciones de mercado

actuales.



5. Asegurar que todas las partes en el acuerdo de suministro entienden y

aceptan todos los requisitos antes de implementar el acuerdo o

cualquier cambio.

6. Actualizar el acuerdo de suministro según se necesite para reflejar

cambios en los procesos o productos de trabajo del suministrador.

7. Actualizar los planes de trabajo y los compromisos, incluyendo los

cambios a los procesos o productos de trabajo del grupo de trabajo,

según se necesite para reflejar el acuerdo de suministro.

Para más información sobre monitorizar compromisos, consúltese el

área de proceso Monitorización y Control de Trabajos.

SG 2 Satisfacer los acuerdos de suministro

Los acuerdos de suministro son satisfechos tanto por el grupo de trabajo como por el suministrador.

SP 2.1 Ejecutar el acuerdo de suministro

Realizar las actividades con el suministrador conforme a lo

descrito en el acuerdo de suministro.






1. Informes de progreso y medidas de desempeño del suministrador.

2. Materiales e informes de revisión del suministrador.

3. Acciones seguidas hasta su cierre.

4. Entregas de productos y documentación.

Subprácticas

1. Monitorizar el progreso y desempeño del suministrador (p. ej., plazos,

esfuerzo, coste, desempeño técnico) según se define en el acuerdo de

suministro.

2. Seleccionar, monitorizar, y analizar los procesos que utiliza el

suministrador según lo descrito en el acuerdo de suministro.

Se deberían monitorizar los procesos del suministrador que sean críticos para que el

trabajo tenga éxito (p. ej. por su complejidad, por su importancia). La selección de

procesos a monitorizar debería tener en cuenta el impacto que dicha selección tiene

sobre el suministrador.

3. Seleccionar y evaluar los productos de trabajo del suministrador,

según lo descrito en el acuerdo de suministro.

La selección de productos de trabajo que se van a evaluar debería incluir los

productos, los componentes de producto, y los productos de trabajo que son críticos y

que permiten conocer si hay problemas de calidad tan pronto como sea posible. En



situaciones de bajo riesgo, puede que no sea necesario seleccionar ningún producto

de trabajo para su evaluación.

4. Llevar a cabo las revisiones con el suministrador según lo descrito en

el acuerdo de suministro.

Para más información sobre realizar revisiones de hitos y revisiones

de progreso, consúltese el área de proceso Monitorización y Control

de Trabajos.

Las revisiones cubren tanto las de tipo formal como las informales e incluyen los

siguientes pasos:

Preparar la revisión.

Asegurar la participación de las partes interesadas relevantes.

Llevar a cabo la revisión.

Identificar, documentar, y seguir todas las acciones hasta su cierre.

Preparar un informe resumido de la revisión y distribuirlo a las partes interesadas relevantes.

5. Llevar a cabo las revisiones técnicas con el suministrador según lo


Habitualmente las revisiones técnicas incluyen:

Evaluar la prestación de servicios del suministrador frente a los objetivos establecidos en los acuerdos de servicio (p. ej. acuerdos de nivel de servicio, acuerdos de nivel de operación).

Proporcionar al suministrador visibilidad sobre las necesidades y deseos de los clientes y usuarios finales según sea apropiado.

Revisar las actividades técnicas del suministrador y verificar que la interpretación e implementación de los requisitos que ha hecho el suministrador son consistentes con la interpretación del grupo de trabajo.

Asegurar que los compromisos técnicos se satisfacen y que los problemas técnicos se comunican y se resuelven de manera oportuna.

Obtener información técnica acerca de los productos del suministrador.

Proporcionar al suministrador información técnica y soporte apropiados.

6. Llevar a cabo las revisiones de gestión con el suministrador según lo


Habitualmente las revisiones de gestión incluyen:

Revisión de las dependencias críticas.

Revisión de los riesgos del trabajo en los que esté involucrado el suministrador.

Revisión del cronograma y el presupuesto.

Revisión de que el suministrador cumple los requisitos legales y normativos.

Las revisiones técnicas y de gestión se pueden coordinar y realizar a la vez.

7. Utilizar los resultados de las revisiones para mejorar el desempeño del

suministrador y para establecer y fomentar relaciones a largo plazo

con los suministradores preferentes.



El análisis de los resultados de las revisiones técnicas y de gestión y la realización de

revisiones completas para asegurar que las necesidades del negocio estén alineadas

con las obligaciones contractuales son posibles fuentes para mejorar el desempeño

del suministrador o la relación entre la organización y el suministrador. Se realizan

periódicamente revisiones completas de los acuerdos de suministro para asegurar

que las necesidades del negocio están alineadas con las obligaciones contractuales.

Las mejoras identificadas en estas revisiones se pueden registrar e incluir en un plan

de mejora.

8. Monitorizar los riesgos en los que el suministrador esté involucrado y

realizar acciones correctivas según se necesite.



Algunos ejemplos de fuentes de riesgo a monitorizar son:

Capacidad que tiene el suministrador de mantener la eficacia en las entregas.

Viabilidad del suministrador.

Elementos cubiertos por los acuerdos de confidencialidad.

Términos y condiciones contractuales.

Disponibilidad de suministradores alternativos.

SP 2.2 Aceptar el producto adquirido

Asegurar que se ha satisfecho el acuerdo de suministro antes de

aceptar el producto adquirido.

Antes de aceptar el producto descrito en el acuerdo de suministro se

debería completar un proceso de aceptación que incluya actividades

apropiadas, tales como revisiones de aceptación, pruebas, y auditorías de

configuración.

Cuando se adquieren servicios que se van a prestar directamente al cliente

o al usuario final del proveedor de servicios, esta práctica se puede

implementar antes, durante, o después de la prestación de servicios al

cliente o usuario final. Potencialmente puede implementar esta práctica

específica más de una vez.


1. Procedimientos de aceptación.

2. Resultados de revisiones o pruebas de aceptación.

3. Informes de discrepancias o planes de acciones correctivas.

Subprácticas

1. Definir los procedimientos de aceptación.

2. Revisar y acordar con las partes interesadas relevantes los

procedimientos de aceptación antes de la revisión o prueba de

aceptación.

3. Verificar que los productos adquiridos satisfacen sus requisitos.



Algunos ejemplos de verificar que un servicio adquirido satisface sus requisitos son:

Pilotar el servicio y comparar los resultados frente al acuerdo de nivel de servicio o al acuerdo de nivel de operación.

Inspeccionar el sistema de servicio del suministrador para verificar que cumple sus requisitos.

Monitorizar la prestación (o prestaciones) de servicios al cliente por parte del suministrador con respecto a los requisitos del acuerdo de suministro.

Extensión SSD



4. Confirmar que los compromisos no técnicos asociados a los productos

adquiridos se hayan satisfecho.

Esta confirmación puede incluir que se confirme que están en regla los acuerdos

apropiados sobre licencias, garantía, propiedad, uso, y soporte o mantenimiento, y

que los materiales de soporte se han recibido.

5. Documentar los resultados de las revisiones o pruebas de aceptación.

Algunos ejemplos de documentar los resultados de la revisión de aceptación de un servicio son:

Un informe evaluando los resultados de un piloto del servicio.

Un informe evaluando los resultados de inspeccionar el sistema de servicio del suministrador.

Una lista de comprobación completada que registre los resultados de la monitorización de la prestación (o prestaciones) de servicios al cliente por parte del suministrador.

6. Establecer un plan de acción y acordar con el suministrador la

realización de acciones para corregir los productos adquiridos que no

pasan sus revisiones o pruebas de aceptación.

7. Seguir las acciones hasta su cierre.



Trabajos.

SP 2.3 Asegurar la transición de productos

Asegurar la transición de los productos adquiridos al

suministrador.

Para asegurar que la transición sea fluida deberían tener lugar una

preparación y evaluación apropiadas antes de que el producto adquirido se

transfiera al proyecto, al cliente, o al usuario final.



Extensión SSD

Para más información sobre integrar componentes de sistema de servicio,



1. Descripciones del modo en que se van a satisfacer las obligaciones de

soporte continuo, tales como las garantías y las licencias.

2. Planes de transición.

3. Informes de capacitación.

4. Informes de soporte y mantenimiento.

Subprácticas

1. Asegurar que existen instalaciones para recibir, almacenar, integrar, y

mantener los productos adquiridos según sea apropiado.

2. Asegurar que se imparte capacitación apropiada a las personas

involucradas en la recepción, almacenamiento, integración, y

mantenimiento de los productos adquiridos.

3. Asegurar que los productos adquiridos se almacenan, distribuyen, e

integran siguiendo los términos y condiciones descritos en el acuerdo

de suministro o la licencia.


Continuidad del Servicio (SCON) 363

CONTINUIDAD DEL SERVICIO


Propósito

El propósito de Continuidad del Servicio (SCON) es establecer y mantener

planes para asegurar la continuidad del servicio durante y después de una

alteración significativa de la operativa ordinaria.


La continuidad del servicio es el proceso de preparar la mitigación de

alteraciones significativas en la prestación de servicios, de forma que la

prestación de servicios se pueda restablecer o reanudar aunque sea de

forma degradada. Estas prácticas describen el modo en que se preparan

los sistemas de servicio y los recursos de los que dependen para ayudar a

asegurar que se puede continuar dando el nivel mínimo de servicio que es

crítico en caso de que se materialicen riesgos significativos. Parte de la

continuidad del servicio es identificar cuáles son los servicios que no

pueden alterarse y cuáles sí pueden y por cuánto tiempo.

El área de proceso Continuidad del Servicio se apoya en las prácticas de

Gestión de Riesgos. El área de proceso Gestión de Riesgos describe un

enfoque general sistemático para identificar y mitigar todos los riesgos de

forma que se minimicen proactivamente sus impactos sobre el trabajo. Las

prácticas de continuidad del servicio se especializan en gestionar riesgos

que se centran en el tratamiento de alteraciones significativas en la

operativa ordinaria. Si se ha implementado la gestión de riesgos, algunas

de las capacidades resultantes se pueden utilizar para proporcionar una

continuidad del servicio más eficaz. Sin embargo, la gestión de riesgos

genérica no garantiza que se consiga la continuidad del servicio. Por tanto,

además de las prácticas específicas del área de proceso Gestión de

Riesgos se requieren las prácticas específicas de Continuidad del Servicio.

Continuidad del Servicio se puede aplicar tanto a nivel de organización

como a nivel de grupo de trabajo. Por consiguiente, cuando en esta área

de proceso se usa el término “organización” se puede aplicar a los grupos

de trabajo de la organización según sea apropiado.

Habitualmente, las alteraciones del servicio son situaciones en las que un

suceso (o secuencia de sucesos) hace virtualmente imposible que el

proveedor de servicios lleve a cabo el trabajo de la forma habitual.



Algunos ejemplos de tales eventos son:

Alteraciones en la infraestructura, tales como averías significativas en equipos y el

desplome de un edificio.

Desastres naturales, tales como huracanes, tornados, y terremotos.

Sucesos de naturaleza humana, tales como disturbios y actos de terrorismo.

Puede que el proveedor de servicios sólo disponga de un breve periodo de

tiempo para recuperar y reanudar la prestación de servicios.

El área de proceso Continuidad del Servicio engloba el desarrollo, las

pruebas, y el mantenimiento del plan de continuidad del servicio. Primero,

se debería identificar lo siguiente:

Las funciones esenciales que dan soporte a los servicios que la

organización ha acordado prestar.

Los recursos que se requieren para prestar los servicios.

Los peligros o amenazas potenciales para dichos recursos.

El grado en que el proveedor de servicios es susceptible a los efectos

de cada peligro o amenaza.

El impacto potencial sobre la continuidad del servicio de cada

amenaza.

Esta información se utiliza para desarrollar un plan de continuidad del

servicio que, en caso de alteraciones, haga posible que la organización

reanude la prestación de servicios. Habitualmente, la creación de un plan

de continuidad del servicio engloba las siguientes tres actividades después

de que se haya recogido la información descrita anteriormente. Todas

estas actividades, incluyendo la recogida de información, se repiten

periódicamente para mantener el plan actualizado:

Documentar el plan de continuidad del servicio en base a la

información recogida previamente.

Documentar las pruebas que validan el plan de continuidad del servicio.

Documentar los materiales de capacitación sobre la ejecución del plan

de continuidad del servicio y los métodos para impartirla.

Por último, los planes de continuidad del servicio se deberían validar. Dado

que no es sensato esperar a que haya una emergencia para ejecutar el

plan de continuidad del servicio por primera vez, el personal que realiza los

procedimientos del plan de continuidad del servicio debería recibir

capacitación sobre cómo realizar estos procedimientos. Además, se

deberían realizar pruebas periódicas para determinar si el plan de

continuidad del servicio sería eficaz ante una emergencia o una alteración

significativa reales, y qué cambios son necesarios en el plan para posibilitar

que la organización continúe prestando servicios de manera fiable.




Para más información sobre la prestación de servicios conforme a los

acuerdos de servicio, consúltese el área de proceso Prestación de

Servicios.



Para más información sobre impartir capacitación, consúltese el área de

proceso Capacitación Organizativa.






SG 1 Identificar dependencias esenciales del servicio

SP 1.1 Identificar y priorizar funciones esenciales

SP 1.2 Identificar y priorizar recursos esenciales

SG 2 Preparar la continuidad del servicio

SP 2.1 Establecer planes de continuidad del servicio

SP 2.2 Establecer capacitación sobre continuidad del servicio

SP 2.3 Impartir y evaluar la capacitación sobre continuidad del servicio

SG 3 Verificar y validar el plan de continuidad del servicio

SP 3.1 Preparar la verificación y validación del plan de continuidad del servicio

SP 3.2 Verificar y validar el plan de continuidad del servicio

SP 3.3 Analizar los resultados de la verificación y validación del plan de continuidad del servicio


SG 1 Identificar dependencias esenciales del servicio

Se identifican y documentan las funciones y recursos esenciales de las que dependen los servicios.

El primer paso para planificar la continuidad del servicio es identificar y

priorizar los servicios esenciales, de forma que se pueda crear un plan que

haga posible que estos servicios se presten durante una emergencia.

El segundo paso es identificar y documentar las funciones y recursos de

los que dependen dichos servicios. Las funciones esenciales pueden incluir

procesos manuales, procesos automáticos, actividades de usuarios finales,

y las propias actividades de prestación de servicios, sean éstas

prestablecidas o el resultado de gestionar una petición de servicio hecha

sobre la marcha.

Los servicios, funciones, y recursos identificados y priorizados son, de

hecho, los requisitos de continuidad del servicio y pueden gestionarse

como tales.


componente de producto, y sobre asegurar que dichos requisitos estén



alineados con los planes de trabajo y productos de trabajo, consúltese el

área de proceso Gestión de Requisitos.

SP 1.1 Identificar y priorizar funciones esenciales

Identificar y priorizar las funciones esenciales que se deben llevar

a cabo para asegurar la continuidad del servicio.

Para identificar funciones esenciales, es necesario conocer en detalle

todas las operaciones del sistema de servicio. Aunque muchas funciones

son importantes, no todas las actividades que se realizan son funciones

esenciales. Las funciones esenciales son aquellas que se deben mantener

durante las emergencias o las alteraciones del servicio significativas.

Las prioridades de las funciones esenciales deberían reflejar qué servicios

pueden alterarse y por cuánto tiempo (p. ej. alteración larga frente a corta).

Entender qué servicios son críticos determina cuáles son las funciones

esenciales que son necesarias para proporcionar los servicios críticos.

Establecer prioridades adecuadas requiere involucrar a un amplio rango de

partes interesadas.

Para más información sobre coordinarse y colaborar con las partes

interesadas relevantes, consúltese el área de proceso Gestión Integrada de

Trabajos.


1. Análisis de impacto en el negocio.

Subprácticas

1. Identificar y priorizar los servicios esenciales de la organización.

2. Identificar las funciones esenciales de las que dependen los servicios.

3. Analizar la criticidad de proporcionar dichas funciones y el impacto que

habría sobre los servicios si no se pudieran realizar las funciones

esenciales.





4. Priorizar la lista de funciones esenciales que se deberían proporcionar

incluso si hubiera una alteración significativa.

SP 1.2 Identificar y priorizar recursos esenciales

Identificar y priorizar los recursos esenciales que se requieren

para asegurar la continuidad del servicio.

Los recursos esenciales son los recursos que se necesitan durante o

después de una emergencia para que continúe el funcionamiento o que se

restablezcan los servicios. Estos recursos habitualmente son únicos y

difíciles de reemplazar. Por tanto, entre los recursos esenciales están

incluidos el personal clave y los activos, los datos, y los sistemas que son



esenciales. Puede que sea necesario proteger los recursos esenciales.

Podría ser necesario proporcionar por adelantado recursos de sustitución

adecuados. En el caso de los datos, podría ser necesario establecer copias

de seguridad y archivos.

Muchas organizaciones cometen el error de identificar sistemas, personal,

e infraestructura dentro de la organización, pasando por alto los recursos

externos a la organización de los que también depende la continuidad del

servicio. Entre los recursos que comúnmente se pasan por alto están los

consumibles y los registros vitales (p. ej. documentos que contengan

obligaciones legales o financieras).

Se pueden identificar recursos esenciales analizando lo siguiente:

Prestación de servicios.

Funciones que son esenciales para la continuidad del servicio.

Acuerdos de servicio interno, acuerdos de suministro, y definiciones de

servicios estándar.

Dependencias entre los componentes de sistema de servicio, las partes

interesadas relevantes, y el entorno de prestación de servicios.

Entre las dependencias comunes con los recursos están las fuentes de

información y de datos, tanto si provienen de dentro o de fuera de la

organización, y el personal clave que toma las decisiones relacionadas con

la prestación de servicios o que contribuye significativamente a realizar las

tareas de prestación de servicios.

Para más información sobre coordinarse y colaborar con las partes

interesadas relevantes, consúltese el área de proceso Gestión Integrada de

Trabajos.

Los recursos esenciales generalmente caen dentro de una de las

siguientes categorías:

Recursos para emergencias operativas (p. ej. personal, equipamiento,

o consumibles claves) que son necesarios para reanudar los servicios

alterados.

Recursos legales y financieros (p. ej. documentos contractuales) que

son esenciales para proteger los derechos e intereses de la

organización y los individuos directamente afectados por la

emergencia.

Para más información sobre las actividades de gestión de datos,

consúltese la práctica específica Planificar la gestión de datos en el área de



1. Orden sucesorio.

2. Delegaciones de autoridad.

3. Directorio del personal crítico que incluye información de contacto.

4. Datos y sistemas necesarios para dar soporte a las funciones de

servicio identificadas que son esenciales.



5. Registros de los acuerdos de servicio y los contratos.

6. Registros de los estatutos legales de operación (p. ej. estatutos de

constitución, autorizaciones de agencias gubernamentales locales,

estatales, o nacionales).

7. Balances de las prestaciones no capitalizadas, las nóminas, y los

registros de seguros del personal.

8. Lista de recursos internos y externos requeridos.

9. Lista de dependencias e interdependencias entre recursos.

Subprácticas

1. Identificar y documentar las dependencias internas y externas.

2. Identificar y documentar el personal clave y sus roles en relación a la

prestación de servicios.

3. Identificar y documentar las responsabilidades organizativas y las de

las partes interesadas relevantes.

4. Identificar y documentar los recursos que las funciones esenciales

necesitan para asegurar la continuidad.

5. Priorizar los recursos en base a evaluar el impacto que tendría que se

perdieran o que no se pudiera acceder a ellos.

6. Asegurar que se hagan provisiones de seguridad para el personal,

tanto interno como externo, dentro del entorno de prestación de

servicios y para las funciones organizativas de soporte.

7. Asegurar que en caso de emergencia los registros y las bases de

datos están protegidos, son accesibles, y se pueden utilizar.

SG 2 Preparar la continuidad del servicio

Se realizan preparativos para la continuidad del servicio.

Preparar la continuidad del servicio engloba crear un plan, impartir

capacitación para ejecutar el plan, y establecer recursos tales como

oficinas o sistemas de respaldo.

No es necesario reanudar inmediatamente todos los servicios después de

que se produzca una alteración. El plan de continuidad del servicio

identifica qué servicios deben reanudarse y la secuencia de prioridades

para recuperar dichos servicios.

Adicionalmente, se debería desarrollar e impartir capacitación para ejecutar

el plan de continuidad del servicio a quienes tuvieran que implementar el

plan.

Para más información sobre integrar planes, consúltese el área de proceso






SP 2.1 Establecer planes de continuidad del servicio

Establecer y mantener los planes de continuidad del servicio que

permitan que la organización reanude la realización de las

funciones esenciales.

Un plan de continuidad del servicio proporciona a la organización una guía

explícita en caso de alteración significativa a la operativa normal. Una

organización puede mantener varios planes que cubran diferentes tipos de

alteraciones o diferentes tipos de servicio. Y a la inversa, puede que sea

necesario tener un único plan de continuidad del servicio.


1. Declaración formal sobre quién tiene autoridad para iniciar y ejecutar

el plan de continuidad del servicio.

2. Lista de mecanismos de comunicación necesarios para iniciar la

ejecución del plan de continuidad del servicio.

3. Lista de amenazas y vulnerabilidades que podrían dificultar que la

organización preste sus servicios.

4. Lista de recursos y ubicaciones alternativas para dar soporte a las

funciones esenciales de la organización.

5. Documentación sobre la secuencia de recuperación.

6. Lista de roles y responsabilidades del personal clave.

7. Lista de partes interesadas y métodos para comunicarse con ellas.

8. Métodos documentados para manejar materiales relacionados con la

seguridad según sea apropiado.

Subprácticas

1. Identificar y documentar las amenazas y vulnerabilidades que tiene la

prestación de servicios en curso.

La información sobre amenazas y vulnerabilidades usualmente se desarrolla en otros

procesos y actividades y se utiliza como entrada al plan de continuidad del servicio.

En el plan de continuidad del servicio se registran los sucesos, las amenazas, y las

vulnerabilidades que tienen más probabilidad de desencadenar la puesta en práctica

del plan. Se pueden plantear diferentes acciones para distintas categorías de

sucesos. La información registrada sobre los riesgos de los servicios individuales

también puede ser una entrada a esta parte del plan.



2. Documentar el plan de continuidad del servicio.

3. Revisar el plan de continuidad del servicio con partes interesadas

relevantes.



Extensión SSD



4. Asegurar que existen almacenes y métodos de acceso seguros para el

plan de continuidad del servicio y para la información y las funciones

críticas que se necesitan para implementarlo.

5. Asegurar que los datos y sistemas vitales se protegen

adecuadamente.

Abordar la protección de los datos y sistemas vitales puede incluir que se desarrollen

componentes de sistema de servicio adicionales.

Extensión SSD



6. Documentar el nivel de servicio aceptable acordado con el cliente para

el caso de que se necesite sustituir el entorno normal de prestación de

servicios por el entorno de recuperación (p. ej. ubicación afectada por

la alteración, ubicación alternativa).

Documentar los niveles de servicio aceptables para varios escenarios de parada (p.

ej. ubicación, ciudad, país).

7. Planificar la vuelta a las condiciones de servicio normales.

8. Desarrollar los procedimientos para implementar el plan de


9. Actualizar el plan de continuidad del servicio según se necesite.

Algunos ejemplos de cuándo puede ser necesario actualizar el plan de continuidad del servicio son:

Se están liberando cambios importantes en los servicios.

Hay cambios en las funciones o infraestructuras esenciales.

Hay cambios en las dependencias clave, tanto internas como externas, que se tienen de los recursos.

Hay cambios en la realimentación que proviene de las órdenes de capacitación

Al preparar la verificación y validación del plan de continuidad del servicio, se identifican cambios que son necesarios.

Hay cambios en los resultados de las órdenes de verificación y validación.

Hay cambios en el entorno de prestación de servicios.

Se identifican nuevas amenazas o vulnerabilidades significativas.



SP 2.2 Establecer capacitación sobre continuidad del servicio

Establecer y mantener capacitación para la continuidad del

servicio.

Capacitar al personal que estará involucrado en llevar a cabo la

continuidad del servicio aumenta la probabilidad de éxito en caso de que el

plan deba ejecutarse. Puede que sea apropiado incluir al cliente y al

usuario final en la capacitación sobre continuidad del servicio.

Algunos ejemplos de cuándo deberían ser tenidos en cuenta los clientes y usuarios finales

son:

Situaciones en las que el cliente y el usuario final estén en la misma ubicación que el

proveedor de servicios y puedan verse afectados por los mismos sucesos que

provoquen que el proveedor de servicios inicie el plan de continuidad del servicio.

Situaciones en las que un cambio requerido por la ejecución del plan de continuidad

del servicio pueda afectar a la forma de trabajar del cliente o el usuario final.

Algunos ejemplos de tipo de personal que debería recibir capacitación son:

Personal que responde a las peticiones de servicio.

Personal que proporciona el soporte de infraestructura (p. ej. tecnologías de la

información, suministros).

Usuarios finales.

Suministradores.

Personal y gerentes del grupo de trabajo y la organización seleccionados.

Algunos ejemplos de métodos para impartir capacitación sobre continuidad del servicio son:

Juegos de rol.

Capacitación basada en escenarios.

Instrucción en aulas.

Discusiones en grupo.


1. Material de capacitación sobre continuidad del servicio.

Subprácticas

1. Desarrollar una estrategia para impartir capacitación sobre continuidad

del servicio.

2. Desarrollar y documentar la capacitación sobre continuidad del

servicio para cada categoría de amenaza y vulnerabilidad en la


3. Revisar el material de capacitación sobre continuidad del servicio con




Extensión SSD



4. Actualizar el material de capacitación según se necesite para reflejar

los cambios en el plan de continuidad del servicio y la realimentación

que se ha recibido sobre la eficacia de la capacitación.

SP 2.3 Impartir y evaluar la capacitación sobre continuidad del servicio

Impartir y evaluar la capacitación sobre la ejecución del plan de


La capacitación proporciona instrucción al personal que podría tener que

participar en la ejecución del plan de continuidad del servicio en caso de

una alteración significativa. Adicionalmente, la capacitación proporciona un

mecanismo para recabar información sobre si se debería actualizar o

clarificar el plan de continuidad del servicio.

Para más información sobre proporcionar capacitación, consúltese el área

de proceso Capacitación Organizativa.


1. Registros de capacitación.

2. Evaluación que los asistentes y especialistas en capacitación realizan

sobre la eficacia de la capacitación.

3. Mejoras sugeridas al plan de continuidad del servicio.

Subprácticas

1. Impartir al personal apropiado capacitación que cubra la ejecución del

plan de continuidad del servicio.

2. Mantener registros de las personas que completaron con éxito la

capacitación en continuidad del servicio.

3. Recabar realimentación acerca de la utilidad que la capacitación en

continuidad del servicio tiene para preparar a los que ejecutarán el

plan de continuidad del servicio.

4. Analizar la realimentación sobre la capacitación y documentar las

mejoras sugeridas al plan de continuidad del servicio y a la

capacitación en continuidad del servicio.

SG 3 Verificar y validar el plan de continuidad del servicio

El plan de continuidad del servicio se verifica y se valida.

Verificar y validar el plan de continuidad del servicio ayuda a asegurar que

se está preparado para las diversas amenazas y vulnerabilidades antes de

que ocurran alteraciones. Esta práctica posibilita que se realicen

revisiones, pruebas, y demostraciones en un entorno relativamente

benigno.



Completar con éxito la verificación y validación incluye seleccionar los

métodos apropiados, realizar la verificación y validación, y analizar los

resultados.

Algunos ejemplos de métodos de verificación son:

Inspecciones.

Revisiones entre pares.

Auditorías.

Recorridos.

Análisis.

Simulaciones.

Pruebas.

Demostraciones.


Discusiones con clientes finales, quizás en el contexto de una revisión formal.

Demostración de prototipos.

Demostraciones funcionales (p. ej. probar el sistema de respaldo, utilizar una red de

comunicaciones alternativa para coordinar la prestación de servicios, cambiar a

procesos manuales).

Pilotos del material de capacitación.

Pruebas del sistema de servicio y de sus componentes por parte de los usuarios finales

y otras partes interesadas relevantes.

Extensión SSD

El área de proceso Desarrollo del Sistema de Servicio contiene prácticas

centradas en verificar y validar componentes de sistema de servicio y servicios.

La guía que se encuentra allí puede ser útil para implementar la verificación y

validación de los planes de continuidad del servicio.

Para más información sobre verificar componentes de sistema de servicio

seleccionados con respecto a sus requisitos especificados, consúltese el


SP 3.1 Preparar la verificación y validación del plan de continuidad del servicio

Preparar la verificación y validación del plan de continuidad del

servicio.

La verificación y validación se debería realizar de forma periódica y en

base a eventos. Habitualmente, la verificación y validación del plan de

continuidad del servicio se realiza periódicamente (p. ej. anualmente). Sin

embargo, cuando se hacen cambios importantes al sistema de servicio o al

entorno de prestación de servicios, el plan de continuidad del servicio se

debería revisar o probar para confirmar que éste aún es correcto y está

actualizado.




1. Plan de verificación y validación para asegurar la continuidad del

servicio.

2. Métodos de evaluación utilizados para verificar y validar.

3. Descripción de los entornos necesarios para realizar la verificación y

validación.

4. Procedimientos de verificación y validación.

5. Criterios para determinar el éxito de la verificación y validación.

Subprácticas

1. Desarrollar un plan para llevar a cabo la verificación y validación de la


La estrategia para realizar la verificación y validación de la continuidad del servicio

documenta los requisitos para verificar y validar, y aborda los principios, actividades,

recursos, y entornos clave que se necesitan para que la verificación y validación del

plan de continuidad del servicio sea eficaz.

La verificación y validación no se hace una sola vez. La estrategia debería abordar la

frecuencia con la que se debería realizar la verificación y validación.

El plan para realizar la verificación y validación del plan de continuidad del servicio habitualmente incluye:

Estrategia utilizada para realizar la verificación y validación.

Categorías de las amenazas y vulnerabilidades que se van a evaluar.

Funciones y recursos esenciales que se van a verificar y validar en cada categoría.

Métodos para evaluar si la preparación es adecuada.

Entornos necesarios para dar soporte a la verificación y validación.

Cronograma de las actividades para realizar la verificación y validación.

Recursos asignados.

2. Revisar con las partes interesadas relevantes el plan de verificación y

validación, incluyendo los métodos de evaluación y los entornos y

otros recursos que se van a necesitar.

Las partes interesadas relevantes deberían entender y estar de acuerdo con la

estrategia, los métodos, las actividades, los entornos, y los recursos de verificación y

validación.

3. Determinar los procedimientos y criterios de verificación y validación

del plan de continuidad del servicio.

Los procedimientos y criterios se utilizan para asegurar que los elementos del plan de

continuidad del servicio sean correctos, eficaces, y actuales en relación a las

categorías de amenazas y vulnerabilidades.

4. Identificar los cambios al plan de continuidad del servicio a partir de la

preparación de la verificación y validación.



SP 3.2 Verificar y validar el plan de continuidad del servicio

Verificar y validar el plan de continuidad del servicio.

La verificación y validación se realiza conforme al plan, los métodos, y los

procedimientos definidos a fin de confirmar que el plan de continuidad del

servicio es completo, razonable, y eficaz.


1. Lista de personal y las partes interesadas relevantes implicadas en la

verificación y validación de la continuidad del servicio.

2. Resultados de la verificación y validación del plan de continuidad del

servicio.

Subprácticas

1. Preparar el entorno para realizar la verificación y validación.

2. Realizar la verificación y validación del plan de continuidad del

servicio.

3. Registrar los resultados de las actividades de verificación y validación.

SP 3.3 Analizar los resultados de la verificación y validación del plan de

continuidad del servicio

Analizar los resultados de la verificación y validación del plan de


Los resultados de la verificación y validación del plan de continuidad del

servicio se analizan frente a los criterios definidos de verificación y

validación. Los informes de análisis identifican qué elementos hay que

mejorar en el plan de continuidad del servicio e identifican problemas en los

métodos, entornos, procedimientos, y criterios de verificación y validación.


1. Informes de análisis de verificación y validación.

2. Recomendaciones de mejora al plan de continuidad del servicio.

3. Recomendaciones de mejora a la verificación y validación.

Subprácticas

1. Comparar los resultados de la verificación y validación del plan de

continuidad del servicio reales frente a los esperados.

2. Evaluar si la restauración logró o no los niveles de servicio acordados

u otros estados previstos.

3. Documentar las recomendaciones para mejorar el plan de continuidad

del servicio.

4. Documentar las mejoras recomendadas a la verificación y validación

del plan de continuidad del servicio.

5. Recopilar propuestas de mejora de los servicios o los componentes de

sistema de servicio según sea apropiado en base a los análisis de los

resultados.



6. Proporcionar información sobre el modo en que se pueden resolver los

defectos (incluyendo los métodos de verificación, los criterios, y el

entorno de verificación) e iniciar las acciones correctivas.



Trabajos.


Prestación de Servicios (SD) 377

PRESTACIÓN DE SERVICIOS


Propósito

El propósito de Prestación de Servicios (SD) es prestar servicios conforme

a los acuerdos de servicio.


El área de proceso Prestación de Servicios se centra en lo siguiente:

Establecer y mantener acuerdos de servicio.

Preparar y mantener un enfoque de prestación de servicios.

Preparar la prestación de servicios.

Prestar los servicios.

Recibir y procesar las peticiones de servicio.

Mantener los sistemas de servicio.

La prestación de servicios engloba el establecimiento y mantenimiento de

un acuerdo escrito con los clientes. Un “acuerdo de servicio” describe los

servicios a prestar al cliente, los niveles de servicio deseados, y las

responsabilidades del proveedor de servicios, el cliente, y el usuario final

según sea apropiado.

Un acuerdo de servicio puede cubrir múltiples servicios o múltiples clientes.

Puede tomar la forma de un acuerdo de nivel de servicio (SLA25

), una

declaración del trabajo a realizar (PWS26

), una declaración de objetivos

(SOO27

), una declaración de trabajo (SOW28

), o de otros tipos de acuerdo.

El acuerdo de servicio puede formar parte de un contrato, un memorando

de acuerdo, un documento aprobado de requisitos, o de algún otro

documento. Para casos simples, puede que no sea más que un menú

impreso de servicios y precios.

El área de proceso Prestación de Servicios da soporte a que la relación

entre el proveedor de servicios y sus clientes y usuarios finales sea

positiva, a la vez que cubre las necesidades de los tres. Los procesos de

prestación de servicios deberían fomentar la comunicación abierta y sin

asignación de culpas. El foco principal es la satisfacción de las

necesidades de los usuarios finales que están documentadas.

Un “cliente” es la parte (esto es, individuo, grupo, organización)

responsable de aceptar el servicio o autorizar el pago. Los clientes

25

Service Level Agreement (N. del T.) 26

Performance Work Statement (N. del T.) 27

Statement of Objectives (N. del T.) 28

Statement of Work (N. del T.)



identifican sus necesidades de servicio, compran servicios, y definen y

acuerdan los niveles de servicio deseados. Los clientes pueden ser

internos o externos a la organización proveedora de servicios, y pueden o

no ser los mismos que los usuarios finales, que son los beneficiarios

últimos de la prestación de servicios.

Además del establecimiento de acuerdos de servicio, el área de proceso

Prestación de Servicios incluye prácticas para preparar la prestación de

servicios así como para operar, monitorizar, y mantener el sistema de

servicio. La prestación de servicios se lleva a cabo mediante la operación

del sistema de servicio en respuesta a peticiones de servicio, las cuales

son comunicaciones de los clientes o usuarios finales que identifican la

necesidad de que se preste un servicio acordado. Estas peticiones se

realizan en el contexto de un acuerdo de servicio aceptado.

Los dos tipos de peticiones de servicio son:

Peticiones de servicio continuas o planificadas especificadas en los

acuerdos de servicio.

Peticiones de servicio identificadas por el cliente o por los usuarios

finales en el momento en que sus necesidades surgen de forma

ocasional.

Algunos ejemplos de peticiones ocasionales son:

Solicitar una consulta a una base de datos que se diseña ex profeso como parte de un

servicio de mantenimiento de sistemas.

Solicitar la recogida de un paquete como parte de un servicio de entrega de paquetes.

Identificar un componente estropeado de un sistema que se mantiene como parte de

un servicio de mantenimiento.

Solicitar un chequeo médico como parte de un programa de salud.

Sea cual sea la naturaleza de una petición de servicio específica, se

debería registrar, seguir, y resolver mediante algún tipo de sistema de

gestión de peticiones. Este enfoque ayuda a asegurar que se atienden

todas las peticiones a fin de cumplir los acuerdos de servicio. La respuesta

a las peticiones de servicio también incluye cualquier planificación a bajo

nivel que se necesite como una extensión en detalle de las actividades más

generales de planificación de trabajos.


Extensión SSD

Para más información sobre analizar, diseñar, desarrollar, integrar,

verificar, y validar los sistemas de servicio, incluyendo sus componentes,

con objeto de satisfacer los acuerdos de servicio existentes o previstos,




Para más información sobre desplegar nuevos componentes de sistema de

servicio o cambios significativos en los mismos al tiempo que se gestionan

sus efectos sobre la prestación de servicios en curso, consúltese el área de

proceso Transición del Sistema de Servicio.

Para más información sobre establecer las líneas base y seguir y controlar

los cambios, consúltese al área de proceso Gestión de Configuración.




SG 1 Establecer acuerdos de servicio

SP 1.1 Analizar los acuerdos y datos de servicio existentes

SP 1.2 Establecer acuerdos de servicio

SG 2 Preparar la prestación de servicios

SP 2.1 Establecer el enfoque de prestación de servicios

SP 2.2 Preparar las operaciones del sistema de servicio

SP 2.3 Establecer un sistema de gestión de peticiones

SG 3 Prestar servicios

SP 3.1 Recibir y procesar peticiones de servicio

SP 3.2 Operar el sistema de servicio

SP 3.3 Mantener el sistema de servicio


SG 1 Establecer acuerdos de servicio

Los acuerdos de servicio se establecen y se mantienen.

El acuerdo de servicio entre el proveedor de servicios y el cliente se

establece y se mantiene. En contraste con una cultura centrada en las

culpas y disputas sobre pequeños detalles del acuerdo, un enfoque

colaborativo continuo sobre las actividades descritas en esta área de

proceso fomenta una cultura que da soporte a la mejora de la calidad del

servicio.

El acuerdo de servicio se debería establecer antes de empezar la

prestación de servicios. Más adelante, el acuerdo de servicio se puede

actualizar en base a los resultados de la prestación de servicios (p. ej. para

reflejar los cambios que se necesiten en los servicios prestados, los niveles

de servicio, las responsabilidades del proveedor de servicios o el cliente)

Para tener éxito en mantener la colaboración entre el proveedor de

servicios y el cliente, es importante definir las responsabilidades de ambas

partes. También es importante establecer expectativas realistas para los

niveles de servicio, lo cual requiere que se definan niveles de servicio

medibles y alcanzables.

Cuando las definiciones de servicio estándar y los datos sobre líneas base

de prestación de servicios estén disponibles a nivel organizativo, el

proveedor de servicios debería utilizar esta información como base para

establecer y adaptar los acuerdos.



Extensión SSD



de Servicio.




Para más información sobre monitorizar compromisos, consúltese el área

de proceso Monitorización y Control de Trabajos.

SP 1.1 Analizar los acuerdos y datos de servicio existentes

Analizar los acuerdos de servicio y datos de servicio existentes

para preparar los nuevos acuerdos que se esperan.

Esta práctica tiene en cuenta el contexto completo en el que se establecen

los requisitos. En este análisis se incluyen los objetivos del cliente, las

restricciones de los suministradores, las inquietudes del proveedor de

servicios, y los datos y definiciones existentes sobre prestación de servicios

(p. ej. datos de rendimiento, niveles de servicio, líneas base, uso de

recursos, capacidades de monitorización, catálogos de servicios, servicios

estándar).

El análisis de los acuerdos y los datos de servicio existentes es una

actividad que se ejecuta repetidamente durante la vida del acuerdo de

servicio. El acuerdo de servicio no es un artefacto estático. Es dinámico y

debe ser ajustable, ya que al analizar continuamente los datos y acuerdos

de servicio, con el tiempo se pueden identificar cambios.


1. Descripciones del cliente de los planes, los objetivos, y las

necesidades de servicio.

2. Resultados de las encuestas y cuestionarios de satisfacción de

clientes y usuarios finales.

3. Resultados de evaluar la capacidad que tiene el proveedor de cumplir

las necesidades del cliente.

Subprácticas

1. Revisar los datos disponibles sobre necesidades de clientes y usuarios

finales.

Es importante conseguir entender las percepciones de los clientes y usuarios finales

acerca del servicio antes de que se establezca el acuerdo de servicio. Estas

percepciones pueden incluir objetivos del cliente que no estén expresados

directamente como requisitos del servicio.



Algunos ejemplos de fuentes de datos sobre necesidades de clientes y usuarios finales son:

Entrevistas cara a cara o telefónicas.

Planes y objetivos proporcionados por el cliente señalando el uso que esperan hacer de los servicios.

Declaraciones de trabajo y materiales de licitación relacionados.

Resultados de encuestas a clientes y usuarios finales.

Para más información sobre recabar y analizar datos, consúltese el


2. Revisar lo que preocupa al personal de prestación de servicios y de

soporte.

Antes de establecer un acuerdo de servicio, es importante entender los puntos de

vista del personal de prestación de servicios y de soporte que trabaja con los clientes

y usuarios finales. Este personal es el responsable último de asegurar que la

prestación de servicios cumple con los requisitos. También tiene una perspectiva

operativa única sobre el impacto potencial de nuevos acuerdos. Esta información

puede recopilarse por medio de entrevistas cara a cara o telefónicas, o por medio de

otros métodos de solicitar realimentación al personal (p. ej. reuniones del personal,

correo electrónico, encuestas).

3. Revisar los acuerdos de servicio y acuerdos de suministro existentes.

La revisión de acuerdos existentes incluye:

Considerar el impacto que los acuerdos de suministro del cliente tienen sobre el cumplimiento de los servicios solicitados.

Revisar los requisitos de los servicios solicitados frente a las definiciones de servicio estándar si es que existen.

Revisar los acuerdos de servicio y acuerdos de suministro existentes (p. ej. acuerdos de nivel operativo, acuerdos marco) para evaluar qué potencial tienen para cubrir los requisitos de servicio que se han identificado.

4. Revisar los datos de servicio y los diseños de sistema de servicio

actuales que estén disponibles.

Se revisan los datos de servicio existentes (p. ej. datos de rendimiento, niveles de

servicio, líneas base, historial de incidencias, datos sobre gestión de capacidad y

disponibilidad) y las capacidades (p. ej. capacidades de monitorización). Se pueden

utilizar comparativas que estén disponibles a nivel de industria u otros datos

publicados, en especial en el caso de que los requisitos del servicio no hayan sido

abordados previamente por el proveedor.



Disponibilidad.



Incidencias.



Extensión SSD



5. Analizar la capacidad de suministrar los servicios solicitados.

Considere el enfoque global de cómo se acometerá la prestación de los servicios

solicitados.

Los enfoques de prestación de servicios incluyen los siguientes enfoques de hacer-comprar-reutilizar:

Utilizar los recursos de un sistema de servicio existente.

Modificar o crear un sistema de servicio para cubrir los nuevos requisitos.

Externalizar algunos servicios o componentes de sistema de servicio a suministradores externos.

Para más información sobre asegurar que el rendimiento del sistema

de servicio sea eficaz y que los recursos se provean y utilicen

eficazmente para dar soporte a los requisitos del servicio, consúltese

el área de proceso Gestión de Capacidad y Disponibilidad.

Extensión SSD




servicios a los suministradores, consúltese el área de proceso Gestión

de Acuerdos de Suministro.

SP 1.2 Establecer acuerdos de servicio

Establecer y mantener el acuerdo de servicio.

La forma del acuerdo de servicio puede estar determinada por el cliente o

el proveedor de servicios, dependiendo del tipo de servicio, mercado, y

naturaleza del modelo de negocio del proveedor de servicios. El contenido

del acuerdo puede establecerlo una u otra parte, o puede negociarse

conjuntamente.

El acuerdo de servicio debería cubrir todos los términos, condiciones, y

compromisos que sean necesarios para prestar con éxito los servicios de

forma continua, incluyendo los compromisos que son responsabilidad de

clientes y usuarios finales cuando sea apropiado.



Algunos ejemplos de elementos en un acuerdo de servicio son:

Tipos, niveles, y medidas de servicio.

Disponibilidad del servicio.

Criterios de aceptación y calidad del servicio.

Qué impacto es aceptable sobre las actividades del cliente y el usuario final.

Identificación de riesgos y contingencias.

Consideraciones sobre propiedad intelectual.

Roles y responsabilidades de clientes y usuarios finales.

Recursos suministrados por el cliente.

Coste esperado, pagos, y plazos de financiación.

Consideraciones sobre seguridad y protección.

Para más información sobre establecer las propiedades de los servicios

estándar y los niveles de servicio, consúltese el área de proceso Gestión

Estratégica de Servicios.


1. Acuerdo de servicio.

Subprácticas

1. Definir la estructura y la forma del acuerdo de servicio.

Es importante definir una estructura de acuerdo de servicio que cumpla con las

necesidades del cliente y del proveedor de servicios. La estructura del acuerdo de

servicio complementa o refleja los atributos críticos, categorías, y estructura o

jerarquía de las definiciones de servicio estándar si es que existen.

Algunos ejemplos de estructuras a considerar son:

Basada en el servicio: El acuerdo de servicio se organiza alrededor de un servicio (p. ej. proporcionar correo electrónico corporativo), y puede incluir a varios clientes distintos.

Basada en el cliente: El acuerdo de servicio se organiza alrededor de un cliente, y puede cubrir varios servicios para ese cliente.

En algunos contextos de servicio (p. ej. contratación gubernamental), los clientes

proporcionan un nivel de detalle considerable sobre sus expectativas para la

estructura y el formato del acuerdo de servicio. En esas situaciones, esta subpráctica

equivale a mejorar la comprensión de las expectativas del cliente y el rango de

adaptaciones permitidas en la estructura y el formato del acuerdo.

2. Definir, negociar, y obtener un acuerdo sobre el acuerdo de servicio

preliminar.

3. Publicar el acuerdo de servicio y ponerlo a disposición de los

proveedores de servicios, los clientes, y los usuarios finales según sea

apropiado.

4. Revisar y actualizar el acuerdo de servicio de forma periódica y en

respuesta a eventos según sea apropiado.



SG 2 Preparar la prestación de servicios

Se lleva a cabo la preparación de la prestación de servicios.

La preparación de la prestación de servicios implica desarrollar un enfoque

detallado para recibir y procesar las peticiones de servicio y prestar los

servicios que se han especificado en el acuerdo de servicio. El enfoque

incluye identificar e integrar las actividades requeridas de prestación de

servicios, asegurar que los sistemas de servicio estén listos para prestar

los servicios en los entornos apropiados de prestación de servicios, y

asegurar que los consumibles requeridos estén a mano.

SP 2.1 Establecer el enfoque de prestación de servicios

Establecer y mantener el enfoque que se va a utilizar para prestar

los servicios y operar el sistema de servicio.

El enfoque de prestación de servicios identifica y describe los recursos,

procesos, e interfaces que son esenciales para prestar los servicios de

forma exitosa a lo largo del tiempo.

Un enfoque de prestación de servicios aborda el modo en el que se deberían llevar a cabo

las actividades siguientes:

Prestar los servicios conforme a los plazos establecidos.

Preparar y actualizar los cronogramas de las operaciones diarias.

Realizar y transferir asignaciones para llevar a cabo las operaciones de prestación de

servicios.

Comunicar la información apropiada al personal de operaciones, la gerencia, los

clientes, y los usuarios finales.

Utilizar métodos y herramientas para llevar a cabo las operaciones de prestación de

servicios.

Asignar y transferir la responsabilidad para resolver las peticiones de servicio.

Asignar y transferir la responsabilidad para la monitorizar el estado de las peticiones y

para seguir el progreso de las acciones relacionadas con peticiones.

Posibilitar que los clientes y usuarios finales remitan peticiones.

Categorizar las peticiones.

Utilizar métodos y herramientas para gestionar las peticiones.

Recoger, distribuir, y analizar los datos de rendimiento.

Un grupo de trabajo u organización maduro trata estos elementos como

componentes de un sistema de servicio definido y los desarrolla utilizando

un conjunto riguroso de prácticas de desarrollo de sistemas de servicio.







Extensión SSD








1. Enfoque de prestación de servicios (esto es, enfoque de gestión de

peticiones, operaciones del sistema de servicio).

2. Listas de contactos y asignaciones.

3. Criterios sobre peticiones de servicio.

4. Plantillas de informes de situación internos (p. ej. cuadros de mando).

5. Plantillas de informes de situación externos (p. ej. avisos de peticiones

de servicio completadas).

Subprácticas

1. Definir los criterios para determinar las peticiones de servicio.

Para ser capaces de identificar peticiones de servicio válidas, se deberían definir

criterios que faciliten que los proveedores de servicios determinen qué es y qué no es

una petición de servicio. Además, habitualmente hay criterios para diferenciar qué

prioridad tiene una petición de servicio y cuál es su impacto.

2. Definir categorías para las peticiones de servicio y criterios para

categorizar las peticiones de servicio.

Disponer de un conjunto establecido de categorías facilita que las peticiones de

servicio se completen. Estas categorías predeterminadas pueden posibilitar que los

recursos se asignen de forma apropiada y eficiente.

Algunos ejemplos de categorías de petición de servicio son:

Peticiones de servicio administrativas (p. ej. crear un nuevo usuario, cambiar contraseñas, restaurar ficheros a partir de copias de seguridad).

Peticiones de software (p. ej. instalar o actualizar un paquete de software).

Peticiones de laboratorio (p. ej. análisis radiológico, análisis de sangre).

Entrega de paquetes de tamaño inusual.

Resolver dudas sobre las facturas.

3. Describir el modo en que se asignará y se transferirá la

responsabilidad para procesar las peticiones de servicio.



La descripción puede incluir:

Quién es responsable de llevar a cabo la petición.

Quién es responsable de monitorizar y seguir el estado de la petición.

Quién es responsable de seguir el progreso de las acciones relacionadas con la petición.

Cómo se asigna y se transfiere la responsabilidad de todas estas actividades.

4. Identificar uno o más mecanismos para que los clientes y usuarios

finales soliciten peticiones de servicio.

Estos mecanismos deberían tener en cuenta las formas que tienen los grupos e

individuos de solicitar peticiones, tales como a través del soporte telefónico, por medio

de papel (por correo o entregados en persona), y por medio de formularios

electrónicos presentados en páginas web.

5. Identificar en el acuerdo de servicio los requisitos de tiempos definidos

para completar las peticiones de servicio.

Frecuentemente, las cantidades acordadas de tiempo mínimo y máximo que se

necesita para completar las peticiones de servicio están documentadas en el acuerdo

de servicio antes del inicio de la prestación de servicios.

6. Determinar los requisitos de recursos para la prestación de servicios

según éstos se requieran.

Los requisitos de recursos se generan en los acuerdos de servicio, por la necesidad

de responder a las incidencias y peticiones de servicio que se previeron, así como de

mantener los sistemas de servicio de modo que se puedan prestar los servicios de

forma continuada. Estos recursos pueden incluir al personal, los consumibles, y a

otros recursos que deberían ser controlados para asegurar que el servicio se preste

conforme a los acuerdos de servicio.





7. Revisar, refinar, o mejorar los mecanismos de comunicación con las

partes interesadas (p. ej. letreros, informes de situación, cuadros de

mando) según se necesite.

Los métodos y herramientas para comunicarse con los clientes, los usuarios finales, el

personal del proveedor de servicios, y las otras partes interesadas relevantes durante

el curso de la prestación de servicios forman parte de un sistema de servicio que sea

completo. Estos métodos y herramientas (p. ej. listas de contactos) se pueden crear a

la vez que se desarrolla el sistema de servicio, pero para poder cumplir las

necesidades de prestación de servicios a lo largo del tiempo, regularmente se

deberían revisar, adaptar, y posiblemente complementar.

Extensión SSD





8. Documentar el enfoque de prestación de servicios.

9. Revisar y acordar con las partes interesadas relevantes los enfoques

de prestación de cada servicio identificable por separado.

La información sobre el enfoque se debería presentar a las partes interesadas

relevantes en términos que puedan entender. La revisión debería permitirles identificar

qué elementos del enfoque les preocupan.

10. Actualizar el enfoque de prestación de servicios según se necesite.

SP 2.2 Preparar las operaciones del sistema de servicio

Confirmar que el sistema de servicio está listo para que se presten

los servicios.

Asegurar que los componentes de sistema de servicio apropiados (p. ej.

herramientas, consumibles, personal, procesos, procedimientos) están

listos para las operaciones del sistema de servicio. Para posibilitar que los

servicios se presten de forma sistemática, los sistemas de servicio pueden

necesitar que se adquieran consumibles. La confirmación de estar

preparados para dar los servicios de forma continua no es una práctica de

una sola vez. Estas actividades se deberían realizar repetidamente según

lo necesite el enfoque global de prestación de servicios, incluso si no hay

cambios en el sistema de servicio.

Para más información sobre desplegar nuevos componentes de sistema de

servicio o cambios significativos en los mismos al tiempo que se gestionan

sus efectos sobre la prestación de servicios en curso, consúltese el área de



1. Informe de validación de umbrales de herramientas de monitorización.

2. Informe de validación de procedimientos de operación.

3. Informe de validación de consumibles (p. ej. papel, materiales, soporte

magnético)

4. Registros de adquisición y uso de consumibles.

5. Registros y recibos de prestación de servicios.

6. Resultados de comprobar la operación del sistema de servicio.

Subprácticas

1. Confirmar que los componentes y herramientas del sistema de servicio

apropiados estén operativos.



Algunos ejemplos de herramientas de sistema de servicio son:


Herramientas de gestión del sistema.

Sistemas de seguimiento.

Herramientas de presentación.

Ficheros de registro.

Herramientas de análisis.

Herramientas de gestión de conocimiento en línea.

Herramientas de detección de virus.

Herramientas de gestión de bases de datos

2. Evaluar los resultados de confirmar que los componentes de sistema

de servicio están listos, y determinar qué acciones correctivas son

necesarias.

Dependiendo de la situación, cualquier deficiencia o problema que se descubra

debería ser tratada como una incidencia en el servicio.



Incidencias.

3. Revisar los requisitos de nivel de servicio en los acuerdos de servicio,

y asegurar que se establecen umbrales adecuados en las

herramientas de monitorización del sistema de servicio.

4. Desarrollar, revisar, o refinar los procedimientos de prestación de

servicios.

Durante el desarrollo del sistema de servicio, se pueden crear procesos,

procedimientos operativos estándar, o instrucciones de trabajo detalladas, pero para

cumplir las necesidades de prestación de servicios a lo largo del tiempo, éstos se

deberían revisar, adaptar, y posiblemente complementar regularmente.

Extensión SSD



5. Asegurar que los recursos necesarios para realizar las actividades y

tareas de prestación de servicios estén disponibles.

Las actividades y tareas de prestación de servicios incluyen: operación,

monitorización, y reparación de componentes de sistema de servicio; soporte a los

usuarios del sistema de servicio; y adquisición y reemplazo de componentes de


6. Preparar y actualizar cronogramas detallados de ejecución y

monitorización de trabajos a fin de prestar los servicios según lo

solicitado.



7. En los cambios de personal, orientar y dar soporte al personal que se

incorpora a prestar los servicios sobre la operación actual del sistema

de servicio.

Cuando hay cambios en el personal involucrado en la prestación de servicios (p. ej.

rotación de personal en un cambio de turno), el personal que se incorpora recibe

orientación sobre el estado actual de las operaciones con objeto de asegurar que no

se interrumpe la prestación de servicios en curso.

8. Asegurar que todos los consumibles necesarios para la prestación de

servicios estén disponibles.

Los procedimientos para reponer consumibles y reemplazar o actualizar componentes

de infraestructura se documentan. Según se necesite, adquirir e inspeccionar los

consumibles del sistema de servicio conforme a los procedimientos documentados.

SP 2.3 Establecer un sistema de gestión de peticiones

Establecer y mantener un sistema de gestión de peticiones para

procesar y seguir la información de las peticiones.

Un sistema de gestión de peticiones incluye los medios de

almacenamiento, los procedimientos, y las herramientas de acceso al

sistema de gestión de peticiones. Estos medios, procedimientos, y

herramientas de almacenamiento se pueden automatizar, aunque no es

necesario. Por ejemplo, los medios de almacenamiento podrían consistir en

un sistema de archivo donde se almacenen documentos. Los

procedimientos podrían estar en papel, y las herramientas podrían ser

herramientas manuales o instrumentos para realizar el trabajo sin ayuda

automatizada.

A menudo las peticiones de servicio se solicitan por medio de un mostrador

de servicios o de una función de atención a usuarios.


1. Un sistema de gestión de peticiones con productos de trabajo

controlados.

2. Procedimientos de control de acceso al sistema de gestión de

peticiones.

Subprácticas

1. Asegurar que el sistema de gestión de peticiones permite que las

peticiones se reasignen y transfieran entre grupos.

Puede que sea necesario transferir peticiones entre grupos distintos cuando el grupo

que introduce la petición no sea el más adecuado para realizar la acción de

tratamiento.

2. Asegurar que el sistema de gestión de peticiones permite almacenar,

actualizar, y recuperar información de gestión de las peticiones.



Algunos ejemplos de sistemas de gestión de peticiones son:

Mostrador de servicios.

Seguimiento de tickets.

Libros de registro de servicios.

Paneles de seguimiento de tareas.

3. Asegurar que el sistema de gestión de peticiones permite la

generación de informes útiles para completar las peticiones.

4. Mantener la integridad del sistema de gestión de peticiones y su

contenido.

Algunos ejemplos de mantener la integridad del sistema de gestión de peticiones son:

Realizar copias de seguridad de los registros de petición y restaurarlas.

Archivar los registros de petición.

Mantener la seguridad para evitar accesos no autorizados.

5. Mantener el sistema de gestión de peticiones según se necesite.

SG 3 Prestar servicios

Los servicios se prestan conforme a los acuerdos de servicio.

Los servicios se prestan de forma continua y en respuesta a peticiones de

servicio conforme a los acuerdos de servicio. Esta prestación se lleva a

cabo operando el sistema de servicio, el cual se mantiene operativo o se

retorna al estado operativo según se necesite a pesar de que haya

incidencias en el servicio. El sistema de servicio también está sujeto a

diversas necesidades de mantenimiento.



SP 3.1 Recibir y procesar peticiones de servicio

Recibir y procesar peticiones de servicio conforme a los acuerdos

de servicio.

Las peticiones de servicio se pueden solicitar por medio mecanismos

diversos (p. ej. formularios web, llamadas telefónicas). En los acuerdos de

servicio también se pueden identificar algunas peticiones, especialmente si

son de servicios continuos o periódicos. La recepción y procesamiento de

todas las peticiones de servicio debería estar coordinada por un sistema de

gestión de peticiones establecido.


1. Registro de gestión de petición.


3. Datos de satisfacción de clientes.

4. Recibos de usuarios finales confirmando que la petición se ha

completado.



Subprácticas

1. Recibir peticiones de servicio y asegurar que cada petición está dentro

del alcance del acuerdo de servicio.

Algunos ejemplos de recepción de peticiones de servicio son:

Peticiones de servicio solicitadas por el cliente o el usuario final por medio de un formulario web.

Peticiones de servicio solicitadas por el cliente o el usuario final llamando a atención a usuarios o al mostrador de servicios.

En organizaciones en las que se use una función de atención a usuarios, las

peticiones de servicio usualmente se solicitan a dicha función.

2. Registrar información sobre la petición de servicio.

Cuando se registra información sobre la petición, incluir suficientes datos para poder

analizar y resolver correctamente la petición de servicio.

Algunos ejemplos de datos a registrar sobre las peticiones de servicio son:

Nombre e información de contacto de la persona que solicitó la petición.

Descripción de la petición de servicio.

Categorías a las que pertenece la petición de servicio.

Fecha y hora en las que se realizó la solicitud.

Elementos de configuración involucrados en la petición

Código e información de cierre.

3. Categorizar y analizar la petición de servicio.

Utilizando las categorías establecidas en el enfoque de prestación de servicios,

asignar a la petición de servicio las categorías relevantes en el sistema de gestión de

peticiones. Para algunas peticiones de servicio, el análisis de la petición se puede

completar simplemente seleccionando el tipo de petición. Para otras peticiones (p. ej.

actualizar el software del sistema operativo) puede que sea necesario constituir un

equipo especial para analizar la petición.

Algunos ejemplos de cuándo realizar el análisis de la petición son:

Cuando el impacto de la petición sobre la organización o el cliente sea grande.

Cuando la resolución de la petición de servicio vaya a llevar un tiempo o esfuerzo considerables.

4. Determinar qué recursos son necesarios para resolver la petición de

servicio.

Qué individuos, grupos, y otros recursos son más apropiados puede depender del tipo

de petición de servicio, las localizaciones involucradas, y el impacto en la organización

o el cliente.

5. Determinar las acciones a realizar para satisfacer la petición de

servicio.



Utilizando las categorías establecidas en el enfoque de prestación de servicios,

determinar las acciones apropiadas a llevar a cabo. En algunos casos, las propias

categorías pueden estar asociadas a acciones predeterminadas.

Algunos ejemplos de acciones son:

Responder a las preguntas del cliente.

Reparar elementos (como parte de un servicio de mantenimiento).

Capacitar a un usuario final.

Proporcionar nuevos consumibles o herramientas.

6. Planificar las acciones posteriores según sea apropiado.

Realizar cronogramas adicionales y otros planes que se requieran para guiar las

acciones que se han seleccionado. Si se analizan peticiones de servicio estándar, las

acciones para resolver peticiones de servicio estándar se pueden documentar en un

plan de acción estándar. Si las acciones realizadas implican cambios al sistema de

servicio, puede que sean necesarias acciones adicionales para asegurar la

trazabilidad con los requisitos.

7. Monitorizar el estado de las peticiones de servicio según sea

apropiado hasta que se completen según lo descrito en el acuerdo de

servicio.

Durante la vida de una petición de servicio, el estado de la petición se debería

registrar, seguir, transferir según se necesite, y cerrar.

Para más información sobre monitorizar el trabajo con respecto al

plan, consúltese el área de proceso Monitorización y Control de

Trabajos.

8. Revisar el estado y la resolución de las peticiones de servicio, y

confirmar los resultados con las partes interesadas relevantes.

La comunicación es un factor crítico cuando se proveen servicios. La comunicación

con la persona que solicitó el servicio, y posiblemente con otras partes interesadas

relevantes afectadas por éste, debería ser tenida en cuenta durante toda la vida de la

petición en el sistema de gestión de peticiones. Usualmente, el resultado de las

acciones realizadas se debería revisar con la persona que solicitó la petición de

servicio, para verificar que las acciones completaron la petición de servicio a la

satisfacción del solicitante.

En organizaciones que utilicen una función de atención a usuarios, el estado de las

peticiones de servicio es comunicado a las partes interesadas relevantes por atención

a usuarios.

9. Cerrar la petición de servicio y registrar las acciones realizadas y los

resultados.

Las acciones realizadas para completar la petición de servicio y los resultados de

realizar las acciones son registrados en el sistema de gestión de peticiones para

poder dar soporte a peticiones de servicio similares en circunstancias futuras.



SP 3.2 Operar el sistema de servicio

Operar el sistema de servicio para prestar los servicios conforme a

los acuerdos de servicio.

Esta práctica engloba realizar las actividades que se necesitan para operar

el sistema de servicio con el fin de prestar los servicios en base al enfoque

de prestación de servicios acordado. Operar significa que se ejecute el

sistema de servicio de forma integrada y que el personal proveedor de

servicios use sus procesos y otros recursos para prestar los servicios a los

usuarios finales.


1. Lista de servicios prestados.

2. Registros de servicio.

3. Informes de rendimiento y cuadros de mando.

4. Registro de acciones correctivas.

5. Datos de satisfacción de clientes.

6. Registro de gestión de petición en la base de datos.

Subprácticas

1. Operar los componentes de sistema de servicio conforme a los

procedimientos del sistema de servicio.

Operar los componentes de sistema de servicio puede incluir iniciarlos o detenerlos,

proporcionarles entradas, controlarlos, o manejar sus salidas según sea apropiado.

2. Realizar las actividades de soporte a las operaciones (p.je. actualizar

los umbrales).

Entre las actividades de soporte que los proveedores de servicio realizan durante las

operaciones puede estar capacitar u orientar a clientes y usuarios finales según se

necesite.

3. Gestionar las dependencias y caminos críticos en los planes de

prestación de servicios conforme a los procedimientos operativos.

La gestión de algunas actividades de prestación de servicios puede estar

adecuadamente cubierta por las actividades de gestión de trabajos y de medición y

análisis, especialmente para aquellas peticiones de servicio que estén identificadas

directamente en los acuerdos de servicio.

4. Gestionar y controlar la seguridad en la prestación de servicios.

La seguridad puede incluir monitorizar las violaciones de seguridad, asegurando que

las vulnerabilidades se corrijan, y controlando el acceso a los servicios.

Cuando se prestan servicios, los sistemas de servicio deberían asegurar que sólo se

prestan servicios aprobados al personal autorizado según lo que especifique el

acuerdo de servicio.

5. Gestionar y controlar los otros atributos de calidad asociados con la

prestación de servicios que estén orientados a las operaciones.



Además de la seguridad, se deberían gestionar otros atributos de calidad orientados a

las operaciones del sistema de servicio. Son ejemplos de atributos de calidad la

capacidad, la disponibilidad, la responsividad, la usabilidad, la fiabilidad, y la

seguridad. La gestión de algunos de estos atributos de calidad orientados a las

operaciones del sistema de servicio se aborda en otras áreas de proceso.



Disponibilidad.

6. Monitorizar los componentes de sistema de servicio a bajo nivel

utilizando herramientas de monitorización y de recogida de datos

según sea apropiado.

Parte de la monitorización de las operaciones del sistema de servicio puede estar

cubierta adecuadamente por la monitorización y control a nivel de grupo de trabajo o

la medición y análisis. Sin embargo, otros servicios pueden requerir monitorizar y

recoger datos a nivel de cada petición de servicio individual, o de forma continua

dentro del alcance de una petición de servicio individual. Esta monitorización a bajo

nivel puede requerir de herramientas específicas para manejar de forma apropiada la

recogida de datos, su análisis, y su reporte. A menudo estas herramientas se

automatizan.

7. Según sea apropiado, realizar las actividades necesarias para

completar las peticiones de servicio o resolver las incidencias en el

servicio conforme al acuerdo de servicio.

Durante toda su vida, el estado de las peticiones de servicio o de las incidencias de

servicio se debería registrar, seguir, escalar según se necesite, y cerrar. La resolución

apropiada de una incidencia puede ser un procedimiento operativo simple (p. ej.

restablecer un componente de sistema que ha fallado) o puede implicar algún tipo de

mantenimiento del sistema de servicio.



Incidencias.

Para más información sobre monitorizar el trabajo con respecto al

plan, consúltese el área de proceso Monitorización y Control de

Trabajos.

8. Comunicar el estado de las peticiones de servicio hasta que se

cierren.

9. Recoger información sobre la satisfacción de clientes inmediatamente

después de prestar los servicios o completar las peticiones de servicio.

SP 3.3 Mantener el sistema de servicio

Mantener el sistema de servicio para asegurar que la prestación de

servicios sea continua.

Los sistemas de servicio operativos deberían ser mantenidos para

asegurar su continua capacidad de prestar servicios a lo largo del tiempo

conforme a los acuerdos de servicio. Esta práctica engloba una variedad

de tipos de mantenimiento que incluye:



Mantenimiento correctivo (esto es, corregir y reparar componentes que

degraden la capacidad operativa del sistema de servicio).

Mantenimiento preventivo (esto es, prevenir la ocurrencia de

incidencias y defectos a través de actividades pre-planificadas).

Mantenimiento adaptativo (esto es, adaptar el sistema de servicio a

entornos de prestación de servicios cambiantes o distintos).

Mantenimiento perfectivo (esto es, desarrollar o adquirir capacidades

operativas del sistema de servicio adicionales o mejoradas).

El mantenimiento correctivo se puede realizar para tratar incidencias en el

servicio o para resolver sus causas subyacentes.

Dependiendo del tipo y alcance de las instancias actuales de

mantenimiento del sistema de servicio, otras áreas de proceso pueden

contribuir con prácticas que son relevantes para llevar a cabo esta labor,

especialmente si se trata de mantenimientos que tengan las siguientes

características:

Representan un cambio a los requisitos o el diseño del sistema de

servicio (p. ej. mantenimiento perfectivo).

Conllevan riesgos significativos a implementar cambios requeridos por

las actividades de mantenimiento.

Se puede realizar mantenimiento de una parte del sistema de servicio,

incluyendo consumibles, procesos, y personas. El mantenimiento de

personas, como partes del sistema de servicio, a menudo se lleva a cabo

por medio de capacitación, aunque también pueden ser apropiados otros

métodos (p. ej. transferir miembros del personal a roles que concuerden

mejor con sus habilidades).

Extensión SSD



de Servicio.

Para más información sobre preparar la transición del sistema de servicio,





1. Peticiones de cambio de mantenimiento preventivo o correctivo.

2. Notificaciones de mantenimiento.

3. Cronogramas de mantenimiento preventivo.

Subprácticas

1. Revisar las peticiones de mantenimiento y priorizarlas en base a los

criterios que se identificaron cuando se estableció el enfoque de




Extensión SSD

Las actividades de mantenimiento que sean significativas – aquellas que

resulten en cambios a los requisitos o el diseño del sistema de servicio –

también se benefician de las prácticas de Desarrollo del Sistema de

Servicio.

2. Analizar los impactos en los sistemas de servicio y en la prestación de

servicios.

3. Desarrollar un plan para implementar el mantenimiento.

Para asegurar que la disponibilidad del servicio no se vea afectada adversamente, las

peticiones de mantenimiento no rutinarias se deberían planificar en periodos de

mantenimiento acordados.

4. Entregar notificaciones de mantenimiento a las partes interesadas

relevantes.

5. Actualizar la documentación del sistema de servicio según sea

apropiado.

6. Implementar y comprobar el mantenimiento correctivo o preventivo

conforme al plan y a los procedimientos operativos.

Se deberían realizar pruebas fuera del entorno de prestación de servicios cuando sea

apropiado. En los cambios significativos al sistema de servicio por mantenimiento

también se deberían utilizar las prácticas de Transición del Sistema de Servicio.

7. Enviar la documentación y los cambios de configuración a un

repositorio de gestión de configuración.


Desarrollo del Sistema de Servicio (SSD) 397

Extensión SSD

DESARROLLO DEL SISTEMA DE SERVICIO


Propósito

El propósito de Desarrollo del Sistema de Servicio (SSD) es analizar,

diseñar, desarrollar, integrar, verificar, y validar los sistemas de

servicio, incluyendo sus componentes, con objeto de satisfacer los

acuerdos de servicio existentes o previstos.


El área de proceso Desarrollo del Sistema de Servicio es aplicable a

todos los aspectos de un sistema de servicio. Se aplica tanto a los

nuevos sistemas de servicio como a los cambios en los sistemas de

servicio existentes.

Un “sistema de servicio” es una combinación integrada e

interdependiente de componentes de sistema de servicio que satisface

los requisitos de las partes interesadas.

Un “componente de sistema de servicio” es un proceso, producto de

trabajo, persona, consumible, cliente u otro recurso que un sistema de

servicio requiere para proporcionar valor. Los componentes de sistema

de servicio pueden incluir componentes que pertenezcan al cliente o a

terceros.

Un “consumible del sistema de servicio” es cualquier cosa utilizada por

el proveedor de servicios que deja de estar disponible o que cambia de

forma permanente al ser utilizada para prestar el servicio.

Las personas que son consideradas componentes de sistema de

servicio son aquellas que realizan tareas formando parte del sistema de

servicio, incluyendo al personal del proveedor y los usuarios finales, a

fin de posibilitar que el sistema de servicio opere y preste así los

servicios (consúltense las definiciones de “sistema de servicio”,

“componente de sistema de servicio”, “consumible del sistema de

servicio” y “producto de trabajo” en el glosario).

Las organizaciones que deseen mejorar y evaluar sus procesos de

desarrollo de productos deberían contar con el modelo completo CMMI-

DEV, cuya área de interés se centra específicamente en el desarrollo.

Las organizaciones proveedoras de servicios también pueden elegir el

modelo CMMI-DEV como base para mejorar y evaluar sus procesos de

desarrollo del sistema de servicio. Este uso del modelo CMMI-DEV se

prefiere para organizaciones que ya tengan experiencia con CMMI-



DEV y para organizaciones que desarrollen sistemas de servicio

complejos a gran escala.

Sin embargo, el área de proceso Desarrollo del Sistema de Servicio

ofrece un medio alternativo para conseguir fines de algún modo

similares, al cubrir en una única área de proceso el desarrollo de

requisitos así como el desarrollo, la integración, la verificación, y la

validación del sistema de servicio. Las organizaciones proveedoras de

servicios que sean noveles en el uso de CMMI pueden preferir utilizar

SSD, sobre todo aquellos proveedores de servicios que desarrollen

servicios simples con relativamente pocos componentes e interfaces.

Incluso las organizaciones que utilicen el modelo CMMI-DEV para

desarrollar el sistema de servicio pueden querer consultar el área de

proceso Desarrollo del Sistema de Servicio para obtener una guía útil

sobre la aplicación de las prácticas de desarrollo a componentes de

sistema de servicio, tales como personas, procesos, y consumibles.

Es especialmente importante recordar que los componentes de algunos

sistemas de servicio pueden limitarse a las personas y los procesos

que éstas realizan. En aquellos contextos y otros similares en los que

los sistemas de servicio son bastante simples, se debe tener cuidado al

interpretar las prácticas específicas de esta área de proceso, de forma

que las implementaciones que resulten aporten valor de negocio a la

organización que presta los servicios.

El proceso de desarrollo del sistema de servicio está guiado por los

requisitos del servicio y del sistema de servicio, los cuáles se recopilan

de varias fuentes, tales como acuerdos de servicio y defectos y

problemas identificados durante los procesos de prestación de

servicios y de resolución y prevención de incidencias.

El área de proceso Desarrollo del Sistema de Servicio se centra en las


Recopilar, coordinar, analizar, validar, y asignar los requisitos de

las partes interesadas para los sistemas de servicio.

Evaluar soluciones alternativas para el sistema de servicio y

seleccionar entre ellas.

Diseñar y construir o componer (según se necesite), integrar, y

documentar sistemas de servicio que cumplan los requisitos.

Verificar y validar los sistemas de servicio para confirmar que

satisfacen sus requisitos previstos y que satisfarán las expectativas

de los clientes y usuarios finales durante la prestación de servicios.

CMMI no promociona métodos concretos para el desarrollo del sistema

de servicio. La forma en que la organización de servicios elige

desarrollar el sistema de servicio puede variar, desde desarrollar a nivel

interno a externalizar o integrar un producto comercial. La mayoría de

organizaciones de servicios, en sus labores para construir sus sistemas



de servicio, emplearán un equipo y un enfoque de desarrollo concreto.

La elección del/los método/s depende de los requisitos a cumplir y de

los componentes de sistema de servicio a desarrollar. Los métodos

ágiles constituyen una posible familia de enfoques, pero pueden no ser

apropiados para algunos (o ningún) componentes (el término “métodos

ágiles” es una forma breve de referirse a cualquier método de

desarrollo o de gestión que cumpla el Manifiesto para el desarrollo Ágil

[Beck 2001] y que habitualmente aborda el desarrollo de software).

Para organizaciones que elijan utilizar métodos ágiles, los siguientes

párrafos pueden ser útiles al implementar las prácticas de SSD.

En entornos ágiles, el proceso de requisitos, diseño, desarrollo, y

validación se realiza incrementalmente y colaborando con las partes

interesadas relevantes de forma continua, y en especial con los clientes

y usuarios finales. Las necesidades e ideas del cliente se recaban,

elaboran, analizan, y validan de forma iterativa. Los requisitos se

documentan en formas tales como historias de usuario, escenarios,

casos de uso, registros de producto, y resultados de iteración. Estos

requisitos se priorizan en ciclos de desarrollo, a partir de los cuales se

evolucionan los modelos de diseño, los modelos operativos, y los

diagramas para producir componentes de sistema de servicio. Los

métodos ágiles enfatizan una fuerte relación de trabajo entre el

personal de desarrollo, el personal que provee los servicios, y el cliente

(o usuario final). Este enfoque iterativo y cooperativo se utiliza para

seleccionar y refinar la solución del sistema de servicio con el fin de

proporcionar altos grados de calidad y eficiencia.

Se mantienen reuniones cortas o comunicaciones diarias para

conseguir que la validación de las selecciones y decisiones técnicas

sea casi a tiempo real. También se realizan revisiones a final de ciclo

para validar el desarrollo actual y revisar las prioridades del

subsiguiente ciclo de desarrollo de los requisitos. Debido al énfasis en

la exploración y validación tempranas de las necesidades y

expectativas, es esencial el compromiso y disponibilidad de las partes

interesadas. También es importante que todas las partes entiendan su

rol y estén dispuestas a compartir y abordar los riesgos que surgen de

tal enfoque colaborativo.

Más aún, al decidir si utilizar un método ágil, considerar qué

implicaciones hay para otras áreas de proceso. En particular, puede

que sea necesario entender de antemano qué efectos tiene sobre la

entrega y la transición del sistema de servicio; y mantener debates

sobre la mejor forma de mitigar cualquier posible impacto.

Para más información sobre cómo aplicar métodos ágiles, consúltese la

sección 5.0 de CMMI-DEV, Interpretando CMMI al utilizar enfoques

ágiles.

Para los servicios estándar, los procesos de desarrollo descritos en

esta área de proceso también se pueden aplicar a nivel organizativo

para identificar, desarrollar, y mantener los activos esenciales (p. ej.

componentes, herramientas, arquitecturas, procedimientos operativos,



representaciones del sistema de servicio, software) que se utilizan para

desarrollar los sistemas de servicio o adaptarlos al cliente con el fin de

prestar los servicios estándar (o los servicios adaptados).

Para más información sobre establecer las necesidades y planes

estratégicos de los servicios estándar, consúltese el área de proceso

Gestión Estratégica de Servicios.




Para más información sobre desplegar el sistema de servicio,








Para más información sobre seleccionar y desplegar mejoras,

consúltese el área de proceso Gestión del Rendimiento Organizativo.


componente de producto, y sobre asegurar que dichos requisitos estén

alineados con los planes de trabajo y productos de trabajo, consúltese

el área de proceso Gestión de Requisitos.


SG 1 Desarrollar y analizar requisitos de las partes interesadas

SP 1.1 Desarrollar requisitos de las partes interesadas

SP 1.2 Desarrollar requisitos de sistema de servicio

SP 1.3 Analizar y validar requisitos

SG 2 Desarrollar el sistema de servicio

SP 2.1 Seleccionar soluciones para el sistema de servicio

SP 2.2 Desarrollar el diseño

SP 2.3 Asegurar la compatibilidad entre interfaces

SP 2.4 Implementar el diseño del sistema de servicio

SP 2.5 Integrar componentes de sistema de servicio

SG 3 Verificar y validar el sistema de servicio

SP 3.1 Preparar la verificación y validación

SP 3.2 Realizar revisiones entre pares

SP 3.3 Verificar los componentes de sistema de servicio seleccionados

SP 3.4 Validar el sistema de servicio




SG 1 Desarrollar y analizar requisitos de las partes interesadas

Las necesidades, expectativas, restricciones, e interfaces de las partes interesadas se recopilan, analizan, y transforman en requisitos de sistema de servicio validados.

Esta meta cubre la transformación de las necesidades, expectativas, y

restricciones de las partes interesadas en requisitos que pueden ser

utilizados para desarrollar un sistema de servicio que haga posible la


Las necesidades se recopilan de fuentes que pueden incluir los

acuerdos de servicio; los servicios estándar definidos; las políticas

organizativas; y la comunicación con los usuarios finales, los clientes, y

las otras partes interesadas relevantes. Estas necesidades de servicio

pueden definir qué expectativas tienen las partes interesadas acerca de

qué se va a entregar, especificar niveles o grados de servicio

concretos, o identificar restricciones sobre cómo, cuándo, con qué

frecuencia, o a quién se van a prestar los servicios. En concreto, se

deberían determinar las necesidades, expectativas, y restricciones

relacionadas con los atributos de calidad de las partes interesadas

relevantes. Los atributos de calidad son propiedades del servicio y del

sistema de servicio (p. ej. tiempo de respuesta, disponibilidad,

seguridad), que son críticas para la satisfacción de los clientes y para

cubrir las necesidades de las partes interesadas relevantes (consúltese

la definición de “atributos de calidad” en el glosario).

A su vez, puede que sea necesario analizar y elaborar estas

necesidades, expectativas, y restricciones para identificar detalles

necesarios de los servicios prestados que las fuentes originales no

tuvieron en cuenta. El resultado es un conjunto de requisitos de las

partes interesadas especificados en el lenguaje de los desarrolladores

del sistema de servicio, no en el lenguaje de los que remitieron los

requisitos.

Por ejemplo, un cliente puede establecer como requisito “mantener en

funcionamiento el equipo que se referencia en la Tabla 25”, con

detalles adicionales de ratios de disponibilidad, tiempo medio de

reparaciones, y otros niveles de servicio. Sin embargo, este requisito

podría implicar la necesidad de un conjunto de sub-servicios

especializados, tales como los de diagnóstico, soporte en el terreno, y

mantenimiento preventivo, cada uno de los cuales con sus propios

requisitos de sub-servicio implícitos. Estos refinamientos pueden no ser

de interés o incluso no ser conocidos por las partes interesadas

originales, pero su especificación completa es necesaria para identificar

todo lo que el sistema de servicio debe ser capaz de hacer para cumplir

los requisitos de prestación de servicios.

A medida que los requisitos del servicio se analizan y elaboran,



finalmente éstos conducen a requisitos de sistema de servicio

derivados, los cuales definen y restringen lo que el sistema de servicio

debe cumplir para asegurar que los servicios requeridos se prestan.

Por ejemplo, si el servicio tiene un requisito de tiempo de respuesta, el

sistema de servicio debe tener un requisito derivado que posibilite dar

soporte a ese tiempo de respuesta.

El proceso de desarrollar y analizar los requisitos puede implicar varias

iteraciones que incluyan que todas las partes interesadas relevantes

comuniquen requisitos y sus ramificaciones, de tal forma que todos

puedan acordar un conjunto consistente y definido de requisitos para el

sistema de servicio. Los cambios pueden estar guiados por cambios en

las expectativas de las partes interesadas, o por nuevas necesidades

descubiertas durante las actividades subsiguientes de desarrollo del

sistema de servicio, transición del sistema de servicio, o prestación de

servicios. Debido a que las necesidades cambian con frecuencia

durante el ciclo de vida del servicio, raramente se debería considerar al

desarrollo y análisis de requisitos como un proceso de una sola vez.

Como con todos los requisitos, se realizan los pasos apropiados para

asegurar que el conjunto de requisitos de servicio y de sistema de

servicio aprobados se gestiona de forma eficaz a fin de dar soporte al

desarrollo del servicio y el sistema de servicio.

Para más información sobre gestionar cambios en los requisitos,

consúltese el área de proceso Gestión de Requisitos.

SP 1.1 Desarrollar requisitos de las partes interesadas

Recopilar y transformar las necesidades, expectativas,

restricciones, e interfaces de las partes interesadas en

requisitos priorizados de las partes interesadas.

Las necesidades de las partes interesadas relevantes (p. ej. clientes,

usuarios finales, suministradores, desarrolladores, probadores,

personal de fábrica, personal de soporte logístico, personal de

prestación de servicios, la organización) son la base para determinar

los requisitos de las partes interesadas. Las necesidades, expectativas

restricciones, interfaces, modelos operativos, y modelos de servicio de

las partes interesadas se analizan, armonizan, refinan, priorizan, y

elaboran para traducirlas en el conjunto de requisitos de las partes

interesadas.

Los requisitos recogidos de los clientes y usuarios finales acerca de los

servicios que se van a prestar son documentados en un acuerdo de

servicio. Estos requisitos también se utilizan para derivar requisitos de

sistema de servicio. Estos requisitos derivados se combinan con otros

requisitos recogidos para el sistema servicio y producen el conjunto

completo de requisitos de las partes interesadas.

Para más información sobre analizar los acuerdos y datos de servicio



existentes, consúltese el área de proceso Prestación de Servicios.

Estos requisitos deberían estar formulados en un lenguaje que puedan

entender las partes interesadas relevantes, y que aun así tenga la

precisión que requieren los que desarrollan el servicio o el sistema de

servicio.

Algunos ejemplos de requisitos de las partes interesadas son:

Requisitos de operaciones.

Requisitos de entrega al cliente.

Requisitos de monitorización.

Requisitos de instrumentación.

Requisitos de documentación.

Requisitos de acuerdo de nivel de operaciones.

Estándares organizativos para líneas de producto y servicios estándar.

Requisitos de acuerdos con otras partes interesadas relevantes.


1. Requisitos de clientes.

2. Requisitos de usuarios finales.

3. Restricciones de clientes y usuarios finales sobre la realización de

la verificación y validación.

4. Restricciones de niveles de personal.

Subprácticas

1. Implicar a las partes interesadas relevantes utilizando métodos de

recabar necesidades, expectativas, restricciones, e interfaces

externas.

Recabar requisitos va más allá de recogerlos porque implica identificar

proactivamente requisitos adicionales no provistos explícitamente por los clientes

utilizando métodos tales como encuestas, análisis de datos de satisfacción de

clientes, prototipos, simulaciones, o talleres para recabar atributos de calidad.

2. Transformar las necesidades, expectativas, restricciones, e

interfaces de las partes interesadas en requisitos priorizados de

las partes interesadas.

Al documentar el conjunto de requisitos reconocidos de las partes interesadas se

deberían consolidar y priorizar las diferentes aportaciones de las partes

interesadas relevantes, obtener la información faltante, y resolver los conflictos.

3. Definir restricciones para la verificación y validación.

SP 1.2 Desarrollar requisitos de sistema de servicio

Refinar y elaborar los requisitos de las partes interesadas para



desarrollar requisitos de sistema de servicio.

Los requisitos de las partes interesadas se analizan conjuntamente con

el desarrollo del modelo operativo con objeto de derivar conjuntos de

requisitos más detallados y precisos llamados “requisitos derivados”.

Estos requisitos abordan todos los aspectos del sistema de servicio

asociados con la prestación de servicios, incluyendo los productos de

trabajo, los servicios, los procesos, los consumibles, y los clientes y

otros recursos; así como las funcionalidades y atributos de calidad que

necesitan las partes interesadas relevantes.

Los requisitos derivados surgen de las restricciones, de las

consideraciones de problemas tácitos no explícitamente establecidos

en la línea base de los requisitos de las partes interesadas, y de los

factores que introduce la arquitectura del sistema de servicio

seleccionada, su diseño, las consideraciones que son exclusivas del

trabajo del desarrollador, y las prioridades estratégicas, incluyendo las

tendencias de mercado de la industria. La extensión y profundidad de

los requisitos derivados varía con la complejidad del sistema de

servicio que se necesita para cumplir los requisitos de las partes

interesadas.



En algunos contextos de servicios, los requisitos derivados pueden ser

tan simples como identificar y cuantificar los recursos necesarios. Para

sistemas de servicio complejos que tengan muchos tipos de

componentes e interfaces, los requisitos iniciales se refinan de forma

iterativa en conjuntos de requisitos más detallados, que pueden ser

asignados a componentes de sistema de servicio según se va

refinando la solución preferida.

Por medio de tales actividades de análisis, refinamiento, derivación, y

asignación se establecen la funcionalidad y los atributos de calidad

requeridos por el sistema de servicio.


1. Requisitos derivados con relaciones y prioridades.

2. Requisitos de servicio.

3. Requisitos de sistema de servicio.

4. Asignaciones de requisitos.

5. Requisitos de arquitectura, que especifiquen o restrinjan las

relaciones entre los componentes de sistema de servicio.

6. Requisitos de interfaz.

7. Requisitos de nivel de cualificación.

Subprácticas

1. Desarrollar los requisitos y expresarlos en los términos que se



necesitan para diseñar el servicio y el sistema de servicio.

En particular, estos requisitos incluyen requisitos de arquitectura que especifican

atributos de calidad que son críticos.

2. Derivar los requisitos que resulten de la selección de soluciones y

de las decisiones de diseño.

3. Establecer y mantener las relaciones entre requisitos que hay que

tener en cuenta para gestionar los cambios y asignar los

requisitos.

Las relaciones incluyen dependencias en las que un cambio en un requisito

puede afectar a otros requisitos.

Las relaciones entre requisitos pueden ayudar a diseñar y evaluar el impacto de

los cambios.

4. Priorizar los requisitos derivados.

La priorización de requisitos puede ayudar a definir los ciclos de desarrollo

iterativos.

5. Asignar los requisitos a entidades lógicas, a componentes de

sistema de servicio, y a otras entidades según sea apropiado.

Según evoluciona el modelo operativo, los requisitos se asignan a entidades

lógicas (p. ej. funciones, procesos) las cuales ayudan a establecer relaciones

entre los requisitos y el modelo operativo. Estas entidades lógicas también sirven

para organizar los requisitos y para ayudar a sintetizar la solución técnica. A

medida que la solución técnica se selecciona o va surgiendo, los requisitos se

asignan a componentes de sistema de servicio (o a la arquitectura, en el caso de

muchos requisitos no funcionales) según sea apropiado.

En el caso de utilizar un enfoque iterativo o incremental para el desarrollo del

sistema de servicio, los requisitos también se asignan a iteraciones o a

incrementos.

6. Identificar interfaces tanto externas como internas al sistema de

servicio.

7. Desarrollar requisitos para las interfaces identificadas.

SP 1.3 Analizar y validar requisitos

Analizar y validar los requisitos, y definir la funcionalidad y los

atributos de calidad requeridos para el sistema de servicio.

Se realizan análisis de requisitos para determinar qué impacto tendrá el

entorno de prestación de servicios proyectado sobre la capacidad para

satisfacer las necesidades, expectativas, restricciones, e interfaces de

las partes interesadas relevantes. Dependiendo del contexto de la

prestación de servicios, se deberían considerar factores tales como la

viabilidad, las necesidades de la misión, las restricciones de los costes,

la heterogeneidad de los usuarios finales, el tamaño del mercado

potencial, y la estrategia de compras. También se establece una

definición de la funcionalidad y los atributos de calidad requeridos. Los



objetivos de los análisis son determinar cuáles los requisitos candidatos

de los modelos del sistema de servicio que satisfarán las necesidades,

expectativas, y restricciones de las partes interesadas, y después

traducir estos modelos en requisitos exhaustivos del sistema de

servicio. En paralelo con esta actividad, se determinan los parámetros

que se utilizan para evaluar la eficacia de la prestación de servicios en

base a las entradas de los clientes y usuarios finales y al modelo de

prestación de servicios preliminar.

Los requisitos se validan trabajando con las partes interesadas

relevantes para asegurar que, en el entorno de prestación de servicios,

el sistema de servicio prestará los servicios como se proyectó.


1. Modelos y escenarios operativos, casos de uso, y diagramas de

actividad e historias de usuario.

2. Modelos de la instalación, la capacitación, la operación, el

mantenimiento, el soporte, y la retirada del sistema de servicio y

los componentes de sistema de servicio.

3. Definición de la funcionalidad y los atributos de calidad requeridos.

4. Requisitos de calidad significativos para la arquitectura.

5. Nuevos requisitos.

6. Informes de defectos en requisitos y cambios propuestos para

resolverlos.

7. Evaluación de riesgos relacionados con los requisitos.

8. Registro de los métodos y los resultados de los análisis.

Subprácticas

1. Desarrollar modelos y escenarios operativos que incluyan las

operaciones, la instalación, el desarrollo, el mantenimiento, el

soporte, y la retirada según sea apropiado.

Identificar y desarrollar escenarios que sean consistentes con el nivel de detalle

de las partes interesadas sobre las necesidades, expectativas, y restricciones en

las cuales se espera que opere el sistema de servicio propuesto.

2. Desarrollar un modelo operativo detallado que defina la interacción

entre el sistema de servicio, los usuarios finales, y el entorno, y

que satisfaga las necesidades operativas, de mantenimiento, de

soporte, y de retirada.

Los modelos y escenarios operativos se refinan de forma iterativa para incluir

mayor nivel de detalle a medida que se toman decisiones y se desarrollan

requisitos de más bajo nivel (p. ej. para describir más a fondo las interacciones

entre el sistema de servicio, los usuarios finales, y el entorno). Los modelos y

escenarios operativos se revisan periódicamente para asegurar que abordan las

necesidades de funcionalidad y de atributos de calidad de las partes interesadas

relevantes, las distintas fases del ciclo de vida, y los modos de uso del sistema de



servicio. Las revisiones pueden tomar la forma de recorridos.

3. Establecer y mantener una definición de la funcionalidad y los

atributos de calidad requeridos.

Esta definición de la funcionalidad y los atributos de calidad requeridos describe

qué tiene que hacer el producto (consúltese la definición de “definición de

funcionalidad y atributos de calidad requeridos” en el glosario). Esta definición

puede incluir descripciones, descomposiciones, y reparto de las funciones del

producto.

Adicionalmente, la definición especifica consideraciones o restricciones de diseño

acerca del modo en que la funcionalidad requerida se va a materializar en el

sistema de servicio. Los atributos de calidad abordan factores del sistema de

servicio tales como la disponibilidad, la mantenibilidad; la modificabilidad; la

puntualidad, la capacidad productiva, y el tiempo de respuesta; la fiabilidad; la

seguridad; y la escalabilidad. Algunos atributos de calidad surgirán como

atributos significativos para la arquitectura, dirigiendo así las actividades

subsiguientes de diseño del sistema de servicio de alto nivel. Comprender

claramente los atributos de calidad y su importancia en función de las

necesidades de la misión o del negocio es una entrada esencial al proceso de

diseño.

4. Analizar los requisitos para asegurar que son necesarios,

suficientes, y que equilibran las necesidades y las restricciones de

las partes interesadas.

A medida que se definen los requisitos, se deberían entender qué relaciones

tienen con los requisitos de mayor nivel y con la funcionalidad definida de mayor

nivel. Se determinan los requisitos clave que se utilizarán para realizar el

seguimiento del progreso. Se puede realizar un análisis de coste/beneficio para

evaluar el impacto sobre los costes, los plazos, el rendimiento, y los riesgos del

servicio o el sistema de servicio que tienen los requisitos de atributos de calidad

que son significativos para la arquitectura. Puede que sea necesario renegociar

los requisitos de mayor nivel cuyos costes o riesgos resulten ser inaceptables.

5. Validar los requisitos para asegurar que el sistema de servicio

resultante actuará como se proyectó en el entorno del usuario

final.

SG 2 Desarrollar el sistema de servicio

Los componentes de sistema de servicio se seleccionan, diseñan, implementan, e integran.

Un sistema de servicio puede incluir productos de trabajo, procesos,

personas, consumibles, y clientes y otros recursos.

Una parte importante de los componentes de sistema de servicio que a

menudo no se tiene en cuenta es el factor humano. Las personas que

realizan las tareas formando parte de un sistema de servicio posibilitan

que los sistemas operen, y este rol lo pueden desempeñar tanto el

personal del proveedor como los usuarios finales. Por ejemplo, un

sistema de servicio que procese las llamadas entrantes de un servicio



debería disponer de personal capacitado para recibir las llamadas y

procesarlas de forma apropiada utilizando otros componentes del

sistema de servicio. En otro ejemplo, los usuarios finales de un servicio

de seguros pueden necesitar seguir un proceso de reclamaciones

preestablecido para recibir del sistema de servicio los beneficios del

servicio.

Un consumible es cualquier cosa utilizable por el proveedor de

servicios que deje de estar disponible o que cambie permanentemente

al ser utilizada en la prestación de servicios. Un ejemplo es la gasolina

de un sistema de servicio de transportes que utilizan los vehículos que

funcionen con gasolina. Incluso los sistemas de servicio que se

componen fundamentalmente de personas y procesos manuales a

menudo utilizan consumibles tales como el material de oficina. El papel

que desempeñan los consumibles del sistema de servicio siempre se

debería tener en cuenta.

Esta meta se centra en las siguientes actividades:

Evaluar y seleccionar soluciones que potencialmente satisfagan un

conjunto apropiado de requisitos.

Desarrollar diseños detallados para las soluciones seleccionadas

(lo suficientemente detallados como para poder implementar el

sistema de servicio a partir del diseño).

Implementar los diseños de los componentes de sistema de

servicio según se necesite.

Integrar el sistema de servicio de forma que se puedan verificar y

validar sus funciones y atributos de calidad.

Habitualmente, estas actividades se solapan, son recurrentes, y se

soportan mutuamente. Puede que sea necesario algún nivel de diseño,

a veces bastante detallado, para seleccionar soluciones. Se pueden

utilizar prototipos, pilotos, y pruebas independientes como medio para

adquirir conocimientos suficientes para desarrollar un conjunto

completo de requisitos o seleccionar de entre las alternativas

disponibles.

Desde la perspectiva de las personas, los diseños pueden consistir en

especificaciones de niveles de cualificación y planes de personal, y los

distintos planes de personal se pueden probar con prototipos o pilotos

para determinar cuáles funcionan mejor bajo ciertas condiciones.

Desde la perspectiva de los consumibles, los diseños pueden consistir

en especificaciones de las características y cantidades de consumibles

que son necesarios. Puede que incluso algunos consumibles requieran

ser implementados. Por ejemplo, puede que sea necesario diseñar e

imprimir formularios específicos en papel para probarlos más adelante

como parte del sistema de servicio.

Los procesos de desarrollo se implementan de forma repetida en el

sistema de servicio según se necesite para dar respuesta a cambios en

los requisitos, o a problemas que no se descubrieron durante la

verificación, validación, transición, o entrega. Por ejemplo, algunas



cuestiones que se revelaron en los procesos de verificación y

validación se pueden resolver en los proceso de desarrollo de

requisitos. La recurrencia e iteración en estos procesos permite al

grupo de trabajo asegurar la calidad de todos los componentes de

sistema de servicio antes de que éste empiece a prestar servicios a los

usuarios.

SP 2.1 Seleccionar soluciones para el sistema de servicio

Seleccionar soluciones para el sistema de servicio de entre las

soluciones alternativas.

Las soluciones alternativas y sus virtudes relativas son tenidas en

cuenta de antemano para seleccionar una solución. Se establecen los

requisitos clave (incluyendo los requisitos de atributos de calidad), los

problemas de diseño, y las restricciones con el fin de utilizarlos en los

análisis de soluciones alternativas. Se tienen en cuenta las

características de la arquitectura que proporcionan la base para

mejorar y evolucionar el sistema de servicio.





Una estrategia que potencialmente es ineficaz para implementar esta

práctica consiste en generar únicamente soluciones basadas en la

forma en que se prestaban los servicios en el pasado. Es importante

considerar alternativas que representen formas distintas de asignar y

llevar a cabo las funciones necesarias (p. ej. procesos manuales frente

a automáticos, responsabilidades de los usuarios finales frente a las del

personal de prestación de servicios, gestión de peticiones de servicio

planificadas con anterioridad frente a peticiones sobre la marcha).

Se pueden asignar componentes de sistema de servicio, incluyendo

funciones de prestación de servicios y de soporte, a los

suministradores externos. Como resultado, se investigan acuerdos de

suministro prospectivos. Para utilizar componentes suministrados

externamente se tienen en cuenta sus costes, sus plazos, sus

prestaciones, y sus riesgos. Se pueden utilizar alternativas

suministradas externamente con o sin modificaciones. A veces, para

cumplir mejor los requisitos del servicio o del sistema de servicio, estos

elementos requieren modificaciones en aspectos tales como las

interfaces o adaptaciones de alguna de sus características.





1. Criterios para filtrar soluciones alternativas.



2. Criterios de selección.

3. Decisiones y justificaciones de la selección de un componente de


4. Documentación de las relaciones entre requisitos y componentes

de sistema de servicio.

5. Soluciones, evaluaciones, y justificaciones documentadas.

Subprácticas

1. Establecer criterios definidos de selección.

2. Desarrollar soluciones alternativas.

El desarrollo de soluciones alternativas puede requerir utilizar patrones de

arquitectura, reutilizar componentes, investigar soluciones comerciales (COTS),

externalizar servicios, y tener en cuenta la madurez y obsolescencia tecnológicas.

3. Seleccionar el sistema de servicio que mejor satisfaga los criterios

establecidos.

La selección se basa en evaluar las alternativas utilizando los criterios definidos.

En situaciones de alto riesgo, para ayudar en la evaluación se pueden utilizar

simulaciones, prototipos, o pilotos.

Seleccionar las soluciones para el sistema de servicio que satisfacen mejor los

criterios es la base para poder asignar los requisitos a los diferentes aspectos del

sistema de servicio. Los requisitos de menor nivel se generan a partir de las

alternativas seleccionadas y se utilizan para desarrollar el diseño de los

componentes de sistema de servicio. Los requisitos de interfaz entre los

componentes de sistema de servicio se describen.

SP 2.2 Desarrollar el diseño

Desarrollar diseños para el sistema de servicio y para los


El término “diseño” en esta práctica se refiere a definir los componentes

de sistema de servicio y el conjunto de sus relaciones previstas; estos

componentes interactuarán colectivamente en los modos previstos para

lograr la prestación real de los servicios.

Los diseños de sistema de servicio deberían proporcionar el contenido

apropiado no sólo para la implementación, sino también para otros

aspectos del ciclo de vida del sistema de servicio, tales como la

modificación, la transición y puesta en producción, el mantenimiento, el

sostenimiento, y la prestación de servicios. La documentación de

diseño proporciona una referencia para dar soporte al entendimiento

mutuo del diseño por parte de las partes interesadas relevantes, y

facilita que se realicen futuros cambios en el diseño tanto durante el

desarrollo como en las fases subsiguientes del ciclo de vida.

Una descripción completa del diseño se documenta por medio de un

“paquete de diseño” que incluye el rango completo de características y

parámetros, incluyendo las funciones, las interfaces, los umbrales de



operación, las características de los procesos de fabricación y servicio

(p. ej. qué funciones se automatizan frente a cuáles se realizan

manualmente), y otros parámetros. Los estándares de diseño

establecidos (p. ej. listas de comprobación, plantillas, marcos de

procesos) son la base para lograr que la documentación de diseño

tenga un alto nivel de definición y completitud.

Algunos ejemplos de otros productos de trabajo relacionados con el diseño del

sistema de servicio son:

Descripciones de los roles, las responsabilidades, las autoridades, las

rendiciones de cuentas, y las habilidades de las personas que se necesitan

para prestar el servicio.

Casos de uso funcionales describiendo los roles y actividades de las personas

que participan en el servicio.

Diseños o plantillas de manuales, formularios en papel, material de

capacitación, y guías para los usuarios finales, los operadores, y los

administradores.

“Diseñar las personas” en este contexto quiere decir especificar las

habilidades y niveles de cualificación que se necesitan para acometer

las tareas requeridas, y puede incluir indicar qué niveles de personal

son apropiados así como cuáles son las necesidades de capacitación

(si se necesita capacitación para lograr los niveles de cualificación

necesarios). “Diseñar consumibles” en este contexto significa

especificar las propiedades y características de los consumibles que se

requieren para dar soporte a la prestación de servicios así como las

estimaciones de uso de recursos para que opere el sistema de servicio.


1. Arquitectura del sistema de servicio.

2. Diseños de componentes y consumibles del sistema de servicio.

3. Descripción de habilidades y detalles de la solución de personal (p.

ej. asignar utilizando personal disponible, contratar personal

permanente o temporal).

4. Diseño de especificaciones de interfaz y documentos de control.

5. Criterios de reutilización de diseños y componentes de sistema de

servicio.

6. Resultados de decisiones de hacer-o-comprar.

Subprácticas

1. Desarrollar un diseño para el sistema de servicio.

El diseño del sistema de servicio habitualmente consta de dos grandes fases que

se solapan en la ejecución: diseño preliminar y diseño detallado. El diseño

preliminar establece las capacidades y la arquitectura del sistema de servicio. El

diseño detallado define completamente la estructura y las capacidades de los




2. Asegurar que el diseño cumple con los requisitos de funcionalidad

y de atributos de calidad que tiene asignados.

3. Documentar el diseño.

4. Diseñar las interfaces de los componentes de sistema de servicio

utilizando para ello los criterios establecidos.

Los criterios para las interfaces frecuentemente reflejan los parámetros críticos

que se deberían definir, o al menos investigar, para determinar su aplicabilidad.

Estos parámetros son a menudo característicos de un tipo de sistema de servicio

determinado, y frecuentemente se asocian con requisitos de atributos de calidad

(p. ej. seguridad, protección, durabilidad, características de misión crítica).

Determinar minuciosamente qué procesos se deberían automatizar o automatizar

parcialmente, y qué procesos se deberían realizar manualmente.

5. Evaluar si los componentes de sistema de servicio deberían

desarrollarse, comprarse, o reutilizarse en base a los criterios

establecidos.

SP 2.3 Asegurar la compatibilidad entre interfaces

Gestionar las definiciones, los diseños, y los cambios de las

interfaces del sistema de servicio internas y externas.

Muchos problemas de integración surgen de aspectos de las interfaces

tanto internas como externas que no se conocen o controlan. La

gestión eficaz de los requisitos de interfaces, de sus especificaciones, y

de sus diseños ayuda a asegurar que las interfaces implementadas

serán completas y compatibles.

En el contexto de los sistemas de servicio, las interfaces pueden

caracterizarse de manera amplia de acuerdo a uno de estos cuatro

grandes grupos:

Las interfaces persona-a-persona, que son interfaces que

representan una comunicación directa o indirecta entre dos o más

personas, pudiendo ser cualquiera de ellas personal del proveedor

de servicios o usuarios finales. Por ejemplo, un guion de llamadas,

el cual indica el modo en que un operador de atención a usuarios

interactúa con un usuario final, define una interfaz de comunicación

directa persona-a-persona. Los libros de registro y los letreros

instructivos son ejemplos de interfaces indirectos persona-a-

persona.

Los interfaces persona-a-componente, que son interfaces que

engloban las interacciones entre una persona y uno o más

componentes de sistema de servicio. Estas interfaces pueden

incluir tanto interfaces gráficas de usuario para componentes

automatizados (p. ej. aplicaciones software), como mecanismos de

control para el operador de componentes automatizados,

parcialmente automatizados, y no automatizados (p. ej.

equipamiento, vehículos).



Las interfaces componente-a-componente, que son interfaces que

no incluyen interacción directa con personas. Las interfaces de

muchas de las interacciones entre componentes automatizados

pertenecen a este grupo, aunque existen otras posibilidades, tales

como las especificaciones que restringen la unión física de dos

componentes (p. ej. un camión de reparto, un muelle de carga).

Interfaces compuestas, que son interfaces que mezclan o conectan

en niveles interfaces de más de uno de los otros tres grupos. Por

ejemplo, un sistema de ayuda en-línea que permita conversar

puede tener una interfaz compuesta, construida sobre una

combinación integrada de interfaces persona-a-persona, persona-

a-componente, y componente-a-componente.

Las interfaces también se pueden caracterizar como interfaces

externas o internas. Las “interfaces externas” son interacciones entre

los componentes de sistema de servicio y otras entidades externas al

sistema de servicio, incluyendo las personas, las organizaciones, y los

sistemas. Las interfaces internas pueden incluir las interacciones entre

el personal, los equipos, y las funciones de la organización proveedora

de servicios. Las “interfaces internas” también pueden incluir las

interacciones entre el personal o los usuarios finales y los componentes

de sistema de servicio.

Algunos ejemplos de productos de trabajo de interfaz de usuario son:

Guiones de interacción con el cliente.

Tipos y frecuencias de los informes.

Interfaces de programas de aplicación.


1. Categorías de interfaces con listas de interfaces por categoría.

2. Tabla o correspondencia de relaciones de interfaz entre los

componentes de sistema de servicio y el entorno externo.

3. Lista de las interfaces definidas que se han acordado para cada

par de componentes de servicio cuando sea aplicable. 4.

Informes de las reuniones del grupo de control de interfaces.

5. Acciones para actualizar las interfaces.

6. Actualización de una descripción o un acuerdo de interfaz.

Subprácticas

1. Revisar la cobertura y completitud de las descripciones de interfaz.

Las descripciones de interfaz se deberían revisar con las partes interesadas

relevantes para evitar que se malinterpreten, reducir retrasos, y prevenir el

desarrollo de interfaces que no funcionen correctamente.

2. Gestionar las definiciones de interfaz del sistema de servicio

internas y externas, sus diseños, y sus cambios.

La gestión de interfaces incluye mantener la consistencia de las interfaces



durante la vida del sistema de servicio, cumplir con las decisiones y las

restricciones de arquitectura, y resolver los problemas de conflicto, no

conformidad, y cambio. También es importante gestionar las interfaces entre los

componentes adquiridos a suministradores y los otros componentes de sistema

de servicio.

SP 2.4 Implementar el diseño del sistema de servicio

Implementar el diseño del sistema de servicio.

En esta práctica, el término “implementar” se refiere a la creación

efectiva de los componentes de sistema de servicio, de forma que se

puedan integrar, verificar y validar subsecuentemente. “Implementar”

no se refiere a poner los servicios en funcionamiento en el entorno de

prestación de servicios. Ese proceso de despliegue tiene lugar más

adelante durante la transición del sistema de servicio.

En algunos casos, los consumibles y las personas (p. ej. el personal del

proveedor) pueden “implementarse”. Por ejemplo, puede que sea

necesario imprimir formularios especializados en papel. La

“implementación” de personas puede llevar consigo la contratación de

nuevo personal o el establecimiento de una nueva estructura

organizativa o estructura de equipo para manejar nuevas clases de

responsabilidades. Estas nuevas estructuras deberían integrarse,

verificarse, y validarse antes de empezar la transición del servicio.

Para más información sobre desplegar el sistema de servicio,


Los componentes de sistema de servicio se implementan a partir de

diseños e interfaces establecidos previamente. La implementación

puede incluir la prueba aislada de componentes de sistema de servicio,

y usualmente incluye el desarrollo de cualquier material que se

necesite para capacitar al personal y a los usuarios finales.

Algunos ejemplos de actividades que ocurren durante la implementación son:

Se confirma la compatibilidad de los interfaces.

Se entrega incrementalmente la funcionalidad de un componente.

Se codifica el software.

Se desarrollan los materiales de capacitación.

Se fabrican las piezas eléctricas y mecánicas.

Se escriben los procedimientos que implementan los diseños de proceso.

Se construyen las instalaciones.

Se establecen los acuerdos de suministro.

El personal se contrata o se transfiere.

Se establecen las estructuras organizativas y de los equipos.

Se producen consumibles adaptados al cliente (p. ej. materiales de

empaquetado desechables).




1. Componentes de sistema de servicio implementados.

2. Materiales de capacitación.

3. Manuales de usuario, de operador, y de mantenimiento.

4. Descripciones de procedimientos.

5. Registros de nuevas contrataciones o de transferencias de

personal.

6. Registros de comunicaciones acerca de cambios en la

organización.

Subprácticas

1. Utilizar métodos eficaces para implementar el diseño del sistema

de servicio.

2. Cumplir los estándares y criterios que correspondan.

3. Realizar las revisiones entre pares de los componentes de sistema

de servicio seleccionados.

4. Realizar las pruebas aisladas de los componentes de sistema de

servicio según sea apropiado.

5. Actualizar el sistema de servicio según se necesite.

SP 2.5 Integrar componentes de sistema de servicio

Ensamblar e integrar los componentes de sistema de servicio

implementados para obtener un sistema de servicio verificable.

La integración del sistema de servicio se debería realizar de acuerdo a

una estrategia y unos procedimientos de integración planificados. Antes

de la integración, se debería verificar que cada componente de sistema

de servicio cumple con sus requisitos de interfaz. Los componentes de

sistema de servicio que son procesos manuales se deberían ejecutar a

la vez se hace el uso apropiado de cualquier otro componente de

sistema de servicio que se necesite para verificar que los requisitos se

cumplen.

Durante la integración, se combinan componentes subordinados para

formar componentes ensamblados de sistema de servicio mayores y

más complejos y se realizan funciones de prestación de servicios más

completas. Estos componentes de sistema de servicio ensamblados y

combinados se comprueban para verificar que interactúan

correctamente. Este proceso continúa hasta que la integración del

sistema de servicio se completa. Si durante este proceso se identifican

problemas, éstos se documentan y se ponen en marcha acciones

correctivas.

Algunos sistemas de servicio pueden requerir que se ensamblen

recursos del cliente o el usuario final para una integración completa. Si

estos recursos están disponibles bajo los términos de un acuerdo de

servicio, éstos deberían ser incorporados a las actividades de



integración según sea apropiado. Si dichos recursos del cliente o el

usuario final no están disponibles, se pueden sustituir temporalmente

por recursos equivalentes para posibilitar la integración completa del



1. Estrategia justificada de integración del sistema de servicio.

2. Entorno de integración del sistema de servicio documentado y

verificado.

3. Procedimientos y criterios para la integración del sistema de

servicio.

4. Informes de excepciones.

5. Componentes de sistema de servicio ensamblados.

6. Informes de evaluación de interfaces.

7. Informes resumidos sobre la integración del sistema de servicio.

8. Planes de asignación de personal que muestren la secuencia de

los lugares y momentos en que se provee personal.

Subprácticas

1. Desarrollar una estrategia de integración del sistema de servicio.

La estrategia de integración describe el enfoque para recibir, ensamblar, y

evaluar los componentes de sistema de servicio que componen el sistema de

servicio.

La estrategia de integración debería estar alineada con la estrategia de servicio

descrita en el área de proceso Planificación de Trabajos y armonizada con la

solución y el diseño del sistema de servicio. Los resultados de desarrollar una

estrategia de integración del sistema de servicio se pueden documentar en un

plan de integración del sistema de servicio, el cual se puede revisar con las

partes interesadas con objeto de promover que se comprometan y lo entiendan.

2. Asegurar que el entorno de integración esté preparado.

3. Confirmar que cada componente de sistema de servicio que se

requiere para la integración ha sido identificado correctamente, se

comporta de acuerdo a su descripción, y que todas las interfaces

cumplen con sus descripciones de interfaz.

4. Evaluar la compatibilidad de las interfaces y el comportamiento

(funcionalidad y atributos de calidad) del sistema de servicio

ensamblado.

SG 3 Verificar y validar el sistema de servicio

Se verifican y validan los componentes seleccionados del sistema de

servicio para asegurar que la prestación de servicios sea correcta.



Algunos proveedores de servicio se refieren a cualquier verificación y

validación como “probar”. Sin embargo, en CMMI “probar” se considera

uno de los métodos utilizados para verificar y validar. La verificación y

validación se describen de forma separada en esta área de proceso

para asegurar que ambos aspectos se tratan de manera adecuada.

Algunos ejemplos de métodos de verificación son:

Inspecciones.

Revisiones entre pares.

Auditorías.

Recorridos.

Análisis.

Evaluaciones de arquitectura.

Simulaciones.

Pruebas.

Demostraciones.

Integración continua (esto es, enfoque Ágil para identificar problemas de

integración de forma temprana).


Discusiones con usuarios, quizás en el contexto de una revisión formal.

Demostraciones de prototipos.

Presentaciones funcionales (p. ej. recorridos de la ejecución de la prestación

de servicios, demostraciones de la interfaz del usuario final).

Pilotos y materiales de capacitación.

Pruebas de los servicios y de los componentes de sistema de servicio

realizadas por usuarios finales y por otras partes interesadas relevantes.

Revisiones de ciclo para desarrollos incrementales.

Las prácticas de verificación incluyen preparar la verificación, realizar la

verificación, e identificar las acciones correctivas. La verificación

incluye las pruebas del sistema de servicio y de los componentes de

sistema de servicio seleccionados frente a todos los requisitos

seleccionados, incluyendo los acuerdos de servicio existentes, los

requisitos de servicio, y los requisitos de sistema de servicio.

Algunos ejemplos de componentes de sistema de servicio que se pueden verificar y

validar son:

Las personas.



Los procesos.

El equipamiento.

El software.

Los consumibles.

La validación demuestra que el sistema de servicio, tal como se ha

desarrollado, prestará los servicios como se proyectó. La verificación

aborda si el sistema de servicio refleja de forma adecuada los

requisitos especificados. En otras palabras, la verificación asegura que

“se construyó correctamente”. La validación asegura que “se construyó

lo correcto”.

Las actividades de validación utilizan enfoques similares a los de

verificación (p. ej. pruebas, análisis, inspección, demostración,

simulación). Estas actividades se centran en asegurar que el sistema

de servicio hace posible que los servicios se prestan como se proyectó

dentro del entorno esperado de prestación de servicios. Usualmente,

se involucra a los usuarios finales y a otras partes interesadas

relevantes en las actividades de validación. Las actividades de

verificación y validación a menudo se ejecutan de forma concurrente y

pueden utilizar partes del mismo entorno. Las actividades de validación

y verificación pueden tener lugar repetidamente en múltiples fases del

proceso de desarrollo del sistema de servicio.

SP 3.1 Preparar la verificación y validación

Establecer y mantener un enfoque y un entorno para la

verificación y validación.

La preparación es necesaria para asegurar que hay estipulaciones para

verificar dentro de los requisitos del servicio y del sistema de servicio,

los diseños, los planes de desarrollo, y los cronogramas. La verificación

engloba seleccionar, inspeccionar, probar, analizar, y demostrar todos

los componentes del sistema de servicio, incluyendo los productos de

trabajo, los procesos, y los recursos consumibles.

Se necesitan actividades de preparación similares para que la

validación sea significativa y tenga éxito. Estas actividades incluyen

seleccionar servicios y componentes de sistema de servicio, y

establecer y mantener el entorno, los procedimientos, y los criterios de

validación. Es particularmente importante involucrar a los usuarios

finales y al personal que presta los servicios en primera línea en las

actividades de validación, ya que sus perspectivas acerca de qué

significa una prestación de servicios satisfactoria pueden variar

significativamente entre sí y con respecto a las de los desarrolladores

del sistema de servicio.


1. Lista de componentes seleccionados para la verificación y

validación del sistema de servicio.



2. Métodos de verificación y validación para cada uno de los

componentes seleccionados.

3. Entorno de verificación y validación.

4. Procedimientos de verificación y validación.

5. Criterios de verificación y validación.

Subprácticas

1. Seleccionar los componentes que se van a verificar y validar, y los

métodos de verificación y validación que se utilizarán con cada

uno.

Los componentes de sistema de servicio se seleccionan en base a su

contribución a que los objetivos y los requisitos del servicio se cumplan y los

riesgos se aborden.

2. Establecer y mantener los entornos que se requieren para dar

soporte a la verificación y validación.

3. Establecer y mantener procedimientos y criterios de verificación y

validación para los componentes seleccionados del sistema de

servicio.

SP 3.2 Realizar revisiones entre pares

Realizar revisiones entre pares de los componentes de sistema

de servicio seleccionados.

Las revisiones entre pares implican un examen metodológico de los

componentes de sistema de servicio por parte de los pares del

productor con el fin de identificar defectos a eliminar y de recomendar

cambios.

Las revisiones entre pares son un método importante y eficaz de

verificación que se implementa por medio de inspecciones, recorridos

estructurados, u otras escuelas de métodos de revisión.


1. Cronograma de revisiones entre pares.

2. Lista de comprobación para la revisión entre pares.

3. Criterios de entrada y salida para los componentes de sistema de

servicio y los productos de trabajo.

4. Criterios para solicitar otra revisión entre pares.

5. Material de capacitación sobre revisiones entre pares.

6. Componentes de sistema de servicio seleccionados para la

revisión entre pares.

7. Resultados de la revisión entre pares, incluyendo los problemas y

las acciones.

8. Datos sobre revisiones entre pares.



Subprácticas

1. Determinar qué tipo de revisión entre pares se va a realizar.

Algunos ejemplos de tipos de revisión entre pares son:

Inspecciones.

Recorridos estructurados.

Revisiones activas.

2. Establecer y mantener procedimientos y criterios para las

revisiones entre pares de los componentes de sistema de servicio

y de los productos de trabajo seleccionados.

3. Definir requisitos para la revisión entre pares.

Las revisiones entre pares deberían afrontar las siguientes guías:

Debería haber suficiente preparación.

Se debería gestionar y controlar su realización.

Se deberían registrar datos consistentes y suficientes.

Se deberían registrar las acciones.

Algunos ejemplos de requisitos para las revisiones entre pares son:

Recogida de datos.

Criterios de entrada y de salida.

Criterios para solicitar otra revisión entre pares.

4. Establecer y mantener listas de comprobación para asegurar que

los componentes de sistema de servicio y los productos de trabajo

se revisan de forma coherente.

Algunos ejemplos de elementos que las listas de comprobación abordan son:

Reglas de construcción.

Guías de diseño.

Completitud.

Corrección.

Mantenibilidad.

Tipos de defecto comunes.

Las listas de comprobación se modifican según se necesite para abordar los tipos

específicos de producto de trabajo y de revisión entre pares. Los pares de

quienes desarrollan las listas de comprobación y los usuarios finales potenciales

revisan las listas de comprobación.

5. Desarrollar un cronograma detallado de las revisiones entre pares,

incluyendo las fechas de capacitación sobre revisiones entre pares

y de disponibilidad de los materiales de las revisiones entre pares.

6. Preparar la revisión entre pares.

Las actividades de preparación de la revisión entre pares habitualmente



incluyen:

Identificar al personal que será invitado a participar en la revisión entre pares de cada uno de los componentes de sistema de servicio o productos de trabajo.

Identificar los revisores clave que deberían participar en una revisión entre pares.

Preparar y actualizar los materiales a utilizar durante las revisiones entre pares, tales como las listas de comprobación y los criterios de revisión.

7. Asegurar que los componentes de sistema de servicio o los

productos de trabajo satisfacen los criterios de entrada de la

revisión entre pares y poner los componentes o productos de

trabajo a disposición de los participantes en la revisión con

suficiente antelación como para permitirles preparar

adecuadamente la revisión entre pares.

8. Asignar roles para la revisión entre pares según sea apropiado.

Algunos ejemplos de roles son:

Líder.

Lector.

Registrador.

Autor.

9. Realizar las revisiones entre pares de los componentes de sistema

de servicio y los productos de trabajo seleccionados, e identificar

los problemas que surjan en la revisión entre pares.

Uno de los propósitos de realizar una revisión entre pares es identificar y eliminar

los defectos de forma temprana. Las revisiones entre pares se realizan

incrementalmente, a medida que los componentes de sistema de servicio y los

productos de trabajo se desarrollan.

Las revisiones entre pares se pueden realizar para los productos de trabajo clave

de las actividades de especificación, diseño, pruebas, e implementación y de los

productos de trabajo específicos de planificación. Se pueden realizar revisiones

entre pares de planes de personal, descripciones de competencias, estructura

organizativa, y otros aspectos del sistema de servicio orientados a personas. Sin

embargo, se deberían utilizar con cautela si es para revisar el desempeño y

competencias individuales, en cuyo caso se deberían emplear de forma

coordinada con otros métodos de evaluación individual ya vigentes en la

organización.

Cuando se identifiquen problemas durante las revisiones entre pares, se deberían

comunicar al desarrollador principal o al gerente del componente de sistema de

servicio o producto de trabajo para que se corrijan.

10. Realizar revisiones entre pares adicionales si el criterio establecido

indica que es necesario.

11. Asegurar que se cumplen los criterios de salida de la revisión entre



pares.

12. Registrar y almacenar los datos relativos a la preparación, la

realización, y los resultados de las revisiones entre pares.

Los datos habituales son el nombre del componente de sistema de servicio o del

producto de trabajo, la composición del equipo de revisión entre pares, el tipo de

revisión entre pares, el tiempo de preparación por revisor, la duración de la

reunión de revisión, el número de defectos encontrados, el tipo y origen de los

defectos, etc. Se puede recopilar información adicional del componente de

sistema de servicio o del producto de trabajo revisado.

Proteger los datos para asegurar que los datos de revisiones entre pares no se

utilicen de forma inapropiada. El propósito de las revisiones entre pares es

verificar el correcto desarrollo e identificar defectos para asegurar una mayor

calidad, y no proporcionar razones para castigar al personal o criticar su trabajo

en público. No proteger los datos de las revisiones entre pares a la larga puede

comprometer su eficacia por llevar a que los participantes no sean nada francos

en sus evaluaciones.

13. Analizar los datos de las revisiones entre pares.

Algunos ejemplos de datos de revisiones entre pares que se pueden analizar son:

Tiempo o ratio de preparación real frente al tiempo o ratio esperado.

Número real de defectos frente al número de defectos esperados.

Tipos de defecto encontrados.

Causas de los defectos.

Impacto de la resolución de los defectos.

SP 3.3 Verificar los componentes de sistema de servicio seleccionados

Verificar los componentes de sistema de servicio

seleccionados frente a sus respectivos requisitos.

Los métodos, los procedimientos, los criterios, y el entorno de

verificación se utilizan para verificar el sistema de servicio seleccionado

y cualquier otro proceso asociado de mantenimiento, capacitación, y

soporte. Las actividades de verificación se deberían realizar a lo largo

del ciclo de vida del sistema de servicio.


1. Resultados y registros de verificación.

2. Informes de verificación.

3. Informes de análisis (p. ej. estadísticas de rendimiento, análisis

causal de no conformidades, comparación del comportamiento real

del sistema de servicio frente a los modelos, tendencias).

4. Informes de problemas.



5. Peticiones de cambio a los métodos de verificación, a los criterios,

y al entorno.

Subprácticas

1. Realizar la verificación de los componentes de sistema de servicio

y productos de trabajo seleccionados frente a sus requisitos.

La verificación de los componentes seleccionados incluye verificar que operan de

forma integrada entre ellos y con los interfaces externos apropiados.

2. Registrar los resultados de las actividades de verificación.

3. Identificar las acciones que resulten de la verificación de los

componentes de sistema de servicio y los productos de trabajo.

4. Documentar el método de verificación tal y como se ha ejecutado y

las desviaciones frente a los métodos y procedimientos disponibles

que se han descubierto al realizarlo.

5. Analizar y registrar los resultados de todas las actividades de

verificación.

SP 3.4 Validar el sistema de servicio

Validar el sistema de servicio para asegurar que es apropiado

para el uso en el entorno de prestación de servicios proyectado

y que cumple las expectativas de las partes interesadas.

Los métodos, los procedimientos, y los criterios de validación se utilizan

para validar los servicios, los componentes de sistema de servicio, y

cualquier otro proceso asociado de mantenimiento, capacitación, y

soporte seleccionados. Las actividades de validación se realizan a lo

largo del ciclo de vida del sistema de servicio.

La validación de la operación global del sistema de servicio se debería

llevar a cabo en un entorno que provea suficientes similitudes al

entorno de prestación de servicios como para poder confirmar que el

sistema de servicio cumplirá su uso proyectado. El entorno de

prestación de servicios incluye al conjunto completo de circunstancias y

condiciones bajo las cuales se prestan realmente los servicios

conforme a los acuerdos de servicio. A veces, la validación se puede

realizar eficazmente en un entorno simulado pero en otros contextos

sólo es posible realizarla en una parte del entorno de prestación de

servicios. En este último caso, se debería tener cuidado de que las

actividades de validación no perturben las actividades del servicio en

curso hasta el punto de poner en riesgo el cumplimiento de la

prestación de servicios acordada (consúltese la definición de “entorno

de prestación de servicios” en el glosario).


1. Informes y resultados de validación.

2. Matriz de referencias cruzadas de validación.

3. Informes de deficiencias y otros problemas de validación.



4. Peticiones de cambio a los métodos, los criterios, y el entorno de

validación.

5. Aceptación por parte del usuario (esto es, firma) de la validación

de la prestación de servicios.

6. Informes de los paneles de discusión.

Subprácticas

1. Realizar la validación de la funcionalidad y los atributos de calidad

de los componentes de sistema de servicio seleccionados para

asegurar que son adecuados para el uso en el entorno de

prestación de servicios proyectado.

Los métodos, los procedimientos, los criterios, y el entorno de validación se

utilizan para validar los componentes de sistema de servicio y cualquier otro

servicio asociado de mantenimiento, capacitación, y soporte seleccionados.

2. Analizar los resultados de las actividades de validación.

Los datos de validación resultantes de las pruebas, las inspecciones, las

demostraciones, o las evaluaciones se analizan frente a los criterios de

validación. Los informes de análisis indican si se cumplieron las necesidades. En

caso de deficiencias, estos informes documentan el grado de éxito o fracaso y

categorizan las causas probables del fracaso. Los resultados recogidos de las

pruebas, inspecciones, o revisiones se comparan con los criterios establecidos

para determinar si hay que seguir adelante o si hay que abordar problemas de

requisitos o de diseño.


Transición del Sistema de Servicio (SST) 425

TRANSICIÓN DEL SISTEMA DE SERVICIO


Propósito

El propósito de Transición del Sistema de Servicio (SST) es desplegar

nuevos componentes de sistema de servicio o cambios significativos en los

mismos a la vez que se gestionan los efectos que éstos tienen sobre la

prestación de servicios en curso.


El área de proceso Transición del Sistema de Servicio aborda todos los

aspectos de la planificación, comunicación, gestión, despliegue, y

confirmación de que se hace una transición eficaz de los componentes de

sistema de servicio al entorno de prestación de servicios. El alcance de

esta área de proceso cubre tanto los componentes nuevos como los

cambios significativos a componentes existentes.

Se define cambio “significativo” como aquel que introduce riesgos

inaceptables de que el sistema de servicio no cumpla con sus objetivos.

Aunque estas prácticas se centran en la transición de componentes de

sistema de servicio, la transición de un sistema de servicio completo (esto

es, una colección de componentes interdependientes e integrados) también

se puede gestionar con estas prácticas.

En esta área de proceso, el término “transición” se refiere al proceso

completo de preparación, ejecución, y confirmación del despliegue de

componentes de sistema de servicio hasta que estén completamente

operativos a la vez que se mantiene la prestación de servicios. El término

“desplegar” o “despliegue” es más específico y se refiere a la actividad que

consiste en mover componentes de sistema de servicio al entorno de

prestación de servicios. En algunos dominios, al despliegue también se le

llama “lanzamiento”.

Los despliegues generalmente caen en tres categorías:

Instalación nueva.

Sustitución.

Eliminación.

Planificar la transición asegura que las partes interesadas relevantes estén

informadas de los cambios inminentes. Preparar la transición también

incluye evaluar la compatibilidad del que será el nuevo sistema de servicio

con el entorno actual de prestación de servicios dentro de las restricciones

existentes derivadas de los acuerdos de servicio y las actividades de

prestación de servicios en curso. Se consideran los impactos en el sistema

de servicio que se va a sustituir o reemplazar paulatinamente por el nuevo

sistema. También se consideran los impactos en sistemas de servicio que



compartan interfaces o recursos con el nuevo sistema, así como los

impactos en la continuidad del servicio.

Algunos aspectos críticos de la transición del sistema de servicio son:

Control de la configuración de los componentes de sistema de servicio.

Gestión de interfaces internas y externas.

Despliegue de los componentes de sistema de servicio en el entorno

de prestación de servicios.

Aceptación por parte de las partes interesadas de los componentes de

sistema de servicio nuevos o actualizados.

Gestión de los impactos de la transición.

Se pueden hacer cambios de emergencia al sistema de servicio cuando lo

apruebe una autoridad designada siguiendo las políticas establecidas. Se

puede alterar el orden normal esperado de los procesos de transición del

sistema de servicio para dar cabida a necesidades únicas de situaciones

de emergencia, pero al final todos los procesos relevantes se deberían

completar una vez que la situación se normalice. Este enfoque permite que

se identifiquen y se aborden los impactos no anticipados asociados con

cambios de emergencia.







Servicio.

Para más información sobre operar el sistema de servicio, consúltese el


Extensión SSD





Para más información sobre identificar causas de los resultados








SG 1 Preparar la transición del sistema de servicio

SP 1.1 Analizar las necesidades de transición del sistema de servicio

SP 1.2 Desarrollar planes de transición del sistema de servicio

SP 1.3 Preparar a las partes interesadas para los cambios

SG 2 Desplegar el sistema de servicio

SP 2.1 Desplegar componentes de sistema de servicio

SP 2.2 Evaluar y controlar los impactos de la transición


SG 1 Preparar la transición del sistema de servicio

Se lleva a cabo la preparación de la transición del sistema de servicio.

Una planificación rigurosa posibilita que la transición de componentes de

sistema de servicio al entorno de prestación de servicios sea tranquila. En

esta preparación es crítico analizar la compatibilidad, lo cual se aborda en

esta meta. Además, los planes proactivos y rigurosos acompañados de

estrategias de capacitación y comunicación clarifican la transición,

recabando así el respaldo de las partes interesadas relevantes.

Como parte de la preparación de la transición del sistema de servicio,

revisar los modelos y escenarios operativos del sistema de servicio y

adaptarlos según se necesite para ayudar a asegurar que la planificación

sea suficientemente rigurosa. Revisar también los criterios de aceptación

del sistema de servicio para asegurar que el sistema de servicio cumple

con dichos criterios.

Preparar la transición del sistema de servicio también requiere la

evaluación del impacto potencial de la transición sobre los atributos de

calidad. Los atributos de calidad son propiedades clave del servicio y del

sistema de servicio (p. ej. responsividad, disponibilidad, seguridad) que son

importantes para lograr los objetivos de negocio o la misión (consúltese la

definición de “atributos de calidad” en el glosario). Por ejemplo, una

transición que no se ha planificado bien puede afectar negativamente a la

disponibilidad del servicio o a la seguridad de la prestación de servicios.

Las prácticas abordadas por esta meta deberían comenzar mientras se

desarrollan los componentes nuevos del sistema de servicio o sus

cambios. Haciendo esto, las necesidades y restricciones de la transición se

pueden tener en cuenta durante el desarrollo del componente.

SP 1.1 Analizar las necesidades de transición del sistema de servicio

Analizar la funcionalidad, los atributos de calidad, y la

compatibilidad de los sistemas de servicio actual y futuro para

minimizar el impacto en la prestación de servicios.

El propósito de esta práctica es identificar y mitigar los problemas

asociados a la transición. Esta identificación y mitigación se consigue en

parte analizando el modo en el que el sistema de servicio actual (tal-como-

es) se verá afectado por los cambios previstos del sistema de servicio

después de la transición (tal-como-será).



La transición de componentes de sistema de servicio nuevos o modificados

afecta al entorno de prestación de servicios. Algunos de dichos efectos se

pueden anticipar durante el desarrollo del sistema de servicio.

Análogamente, las actividades en curso de prestación de servicios (si las

hubiera), las peticiones de servicio ocasionales, y las circunstancias ajenas

del entorno pueden llevar a un despliegue fallido si las restricciones que

éstas imponen no se tienen en cuenta. Debido a estas restricciones, puede

que sea necesario hacer gradualmente el despliegue real de las nuevas

capacidades o de las capacidades de prestación de servicios modificadas.

Puede que sea necesario ajustar el diseño del sistema de servicio para

hacer viable la transición. Consecuentemente, esta práctica debería

realizarse en paralelo con las prácticas de desarrollo del sistema de

servicio y continuarse durante la transición hasta llegar al estado operativo.

Para más información sobre preparar las operaciones del sistema de

servicio, consúltese el área de proceso Prestación de Servicios.

Extensión SSD

Para más información sobre desarrollar el sistema de servicio, incluyendo

asegurar la compatibilidad entre interfaces, consúltese el área de proceso

Desarrollo del Sistema de Servicio.


1. Análisis de compatibilidad de los sistemas de servicio antes y después

de la transición.

2. Problemas a abordar y riesgos a mitigar asociados con la transición.

Subprácticas

1. Establecer una línea base del sistema de servicio actual, si no se

hubiera establecido previamente.

Para más información sobre establecer líneas base, consúltese al área

de proceso Gestión de Configuración.

2. Analizar el sistema de servicio tal y como opera actualmente en el

entorno de prestación de servicios.

En algunos casos puede existir documentación y modelos operativos del sistema de

servicio actual. Esta documentación y modelos operativos se pueden utilizar para

entender mejor las operaciones actuales. Si el sistema de servicio actual no estuviera

documentado o no existiese, recabar de las partes interesadas relevantes la mayor

cantidad posible de información relacionada con las operaciones actuales.

3. Analizar los componentes de sistema de servicio propuestos para la

transición (p. ej. el sistema de servicio post-transición o tal-como-será)

para identificar problemas potenciales relacionados con la

compatibilidad, la funcionalidad, los atributos de calidad, o las

interfaces.



Este análisis debería utilizar la documentación de desarrollo de los componentes de

sistema de servicio propuestos. Esta documentación puede incluir modelos

operativos, escenarios, diseños, y diagramas de flujo de trabajo.

Si es necesario, definir procedimientos para asegurar la compatibilidad del sistema de

servicio antes de que se despliegue. Estos procedimientos pueden reutilizar los

métodos aplicables de verificación y validación empleados durante el desarrollo del

sistema de servicio, en cuyo caso también se deberían tener en cuenta las

restricciones adicionales del mundo real que estarán presentes una vez empiece la

transición del sistema de servicio. Dependiendo de la complejidad del sistema de

servicio y de los riesgos asociados a la transición, estos procedimientos pueden variar

desde un simple análisis y resolución de problemas potenciales de compatibilidad

hasta un régimen de pruebas y evaluaciones formales.

4. Identificar y mitigar los problemas potenciales.

Para más información sobre mitigar riesgos, consúltese el área de

proceso Gestión de Riesgos.

SP 1.2 Desarrollar planes de transición del sistema de servicio

Establecer y mantener los planes de las transiciones específicas

del sistema de servicio.

Para cada transición específica del sistema de servicio, se establece un

plan que incluya todas las actividades que van desde la aceptación de

componentes de sistema de servicio hasta la resolución de impactos en los

usuarios finales y en el entorno de prestación de servicios. Un plan de

transición debería identificar todas las actividades y recursos que se

requieren para una transición específica.

Cuando sea apropiado se deberían incluir en los planes de transición:

La identificación de los componentes de sistema de servicio que están

listos para la transición.

El tipo de despliegue (p. ej. nuevo, reemplazo, eliminación).

Enfoque de adquisición.

La instalación e integración de componentes de sistema de servicio en

el entorno de prestación de servicios.

La identificación y resolución de consideraciones relacionadas con la

garantía.

Las fases temporales del despliegue que satisfacen las dependencias

operativas entre los componentes de sistema de servicio.

Los criterios de aceptación para el despliegue.

Las restricciones y limitaciones de los recursos.

La provisión inicial de consumibles.

Los procedimientos de reversión (o suspensión) para “deshacer” la

transición y devolver el entorno de prestación de servicios a su estado

operativo estable anterior.

La capacitación al personal de prestación de servicios y de soporte.



La comunicación a las partes interesadas relevantes sobre el estado de

la transición y los cambios en los servicios.

La profundidad del plan de transición debería ser apropiada para el tipo de

transición y la criticidad de los componentes que pasarán por la transición.

Por ejemplo, la transición de nuevos componentes críticos para el negocio

puede requerir de planes y cronogramas detallados, evaluación de riesgos,

procedimientos para suspender el despliegue, y una revisión formal del

material de planificación por parte de las partes interesadas relevantes.

Transiciones menos significativas, como la eliminación de un servicio

obsoleto, pueden requerir planes menos rigurosos.

Si se han realizado transiciones similares en el pasado, los resultados de

las revisiones post-despliegue se deberían tener en cuenta para planificar

la transición. Esta información puede acelerar el proceso de planificar y

ayudar a identificar problemas que de otro modo se podrían pasar por alto.




1. Planes de transición del sistema de servicio.

Subprácticas

1. Definir el enfoque del despliegue de cada transición de sistema de

servicio específica.

Cuando se defina el enfoque, considerar el tipo de despliegue (p. ej. nueva

instalación, reemplazo, eliminación), teniendo en cuenta que en una misma transición

se pueden combinar estos tipos de despliegue. Considerar las prioridades y

restricciones de las partes interesadas relevantes.

Definir también una estrategia de reversión o suspensión, en caso de que el

despliegue no tenga éxito y haya que restaurar el sistema de servicio a su estado

anterior. Incluir criterios para determinar qué constituye un despliegue con éxito frente

a cuándo suspender los cambios.

Si se está eliminando un sistema de servicio, abordar asuntos tales como la

notificación a los usuarios finales, el manejo de errores, los métodos de archivo, la

demolición, y el reciclaje.

2. Determinar los costes, los recursos, y los plazos requeridos para la

transición del sistema de servicio a un estado operativo nuevo o

modificado.

Planificar las actividades de transición de forma que se equilibren el trabajo y los

recursos disponibles frente a las necesidades de los clientes y usuarios finales,

incluyendo la necesidad de tener tiempo para preparar y llevar a cabo la transición.

Cuando sea apropiado, utilizar los datos reales de transiciones similares para estimar

los costes, los recursos, y los plazos.

3. Identificar a las partes interesadas relevantes para las actividades de

transición.



Cuando se identifique a las partes interesadas en la transición y se definan sus roles y

responsabilidades, asegurar que se han tenido en cuenta a las partes interesadas que

están externalizadas.

4. Desarrollar un plan de transición del sistema de servicio.

En base al enfoque del despliegue y las estimaciones de la transición, documentar un

plan de transición.

5. Obtener el compromiso de las partes interesadas con el plan.

Asegurar que las partes interesadas relevantes revisan el plan de transición del

sistema de servicio para obtener su compromiso. Dar respuesta a los comentarios de

la revisión.

6. Establecer una línea base del plan de transición.

7. Si hay funciones esenciales nuevas o cambios significativos en las

mismas formando parte de la transición, asegurar que el plan de

continuidad del servicio se actualiza con objeto de incluir las nuevas

funciones esenciales.

Para más información sobre establecer planes de continuidad del

servicio, consúltese el área de proceso Continuidad del Servicio.

Para más información sobre integrar planes y coordinarse y colaborar

con las partes interesadas relevantes, consúltese el área de proceso


SP 1.3 Preparar a las partes interesadas para los cambios

Preparar a las partes interesadas relevantes para los cambios en

los servicios y en los sistemas de servicio.

Esta práctica asegura que no se dificulte la transición del sistema de

servicio debido a una mala preparación de las partes interesadas

relevantes para los cambios causados por introducir componentes de

sistema de servicio nuevos o modificados. Las partes interesadas

relevantes deberían incluir siempre a los clientes, los usuarios finales, el

personal del proveedor, la dirección, los suministradores externos, y

cualquier otro que debiera estar al tanto de los cambios esperados.


1. Estrategia de notificación de la transición.

2. Estrategia de capacitación sobre la transición.

Subprácticas

1. Establecer y mantener una estrategia de notificación de la transición.

2. Implementar la estrategia de notificación para mantener a las partes

interesadas relevantes informadas acerca de los cambios planificados

en los servicios y la disponibilidad del servicio durante la transición.

Asegurar que la estrategia de notificación aborde el modo en que se va a comunicar la

reversión o suspensión, si fuese apropiado.



3. Establecer y mantener una estrategia de capacitación sobre la

transición.

La estrategia de capacitación sobre la transición puede englobar un amplio rango de

actividades de orientación y capacitación que involucren a los clientes, los usuarios

finales, el personal de prestación de servicios y de soporte, los gerentes, y la dirección

según sea apropiado. La estrategia de capacitación sobre la transición también

debería englobar las actividades para asegurar que la capacitación sea eficaz

después de haberla proporcionado, tales como exámenes, pilotos, o encuestas.

Algunos ejemplos de información que se debería incorporar a la orientación y capacitación son:

Servicios nuevos o modificados y el modo de solicitarlos.

Procedimientos y herramientas para la realimentación de los clientes y usuarios finales.

Procedimientos y herramientas para mantener, hacer ajustes, y dar soporte a los usuarios finales.

Uso de las herramientas seleccionadas para la prestación de servicios.

Diseño del sistema de servicio.

Umbrales de operación previstos.

Procedimientos y herramientas para planificar, monitorizar, y gestionar los recursos del sistema de servicio.

Procedimientos para manejar incidencias en el servicio que ocurran durante la transición.

4. Implementar la estrategia de capacitación.

Para más información sobre establecer un plan táctico organizativo de

capacitación, consúltese el área de proceso Capacitación

Organizativa.

SG 2 Desplegar el sistema de servicio

El sistema de servicio se despliega en el entorno de prestación de servicios.

Esta meta se centra en obtener componentes de sistema de servicio (si

fuese apropiado de la autoridad de control de configuración) e instalarlos e

integrarlos en el entorno de prestación de servicios. Este proceso se lleva a

cabo de acuerdo al plan táctico de transición del sistema de servicio.

El despliegue puede causar efectos tanto planeados como no planeados

en la operación del sistema de servicio. Identificar, evaluar, y controlar

estos efectos es una parte esencial para conseguir que el despliegue sea

exitoso.

SP 2.1 Desplegar componentes de sistema de servicio

Desplegar sistemáticamente componentes de sistema de servicio

en el entorno de prestación de servicios en base a planificar la

transición.

La preparación de la transición, incluyendo el plan táctico de transición del

sistema de servicio, se utiliza para guiar el despliegue.




1. Registros de instalación.

2. Artefactos de evaluación del despliegue.

Subprácticas

1. Confirmar que los componentes de sistema de servicio a desplegar

están puestos bajo control de configuración según sea apropiado.

Para más información sobre establecer líneas base, consúltese al área

de proceso Gestión de Configuración.

2. Instalar el sistema de servicio en el entorno de prestación de servicios.

Esta subpráctica incluye el empaquetado, la distribución, la integración, y la

instalación de componentes de sistema de servicio en el entorno de prestación de

servicios. Los detalles de la instalación e integración se deberían incluir en el plan

táctico de transición del sistema de servicio.

3. Validar los componentes de sistema de servicio en el entorno de


Asegurar que los componentes desplegados operan como se espera. Los escenarios

y procedimientos operativos se pueden utilizar para evaluar el sistema de servicio

nuevo o modificado. Como parte de esta evaluación, puede que sea necesario

actualizar los criterios de aceptación para el despliegue, los cuales fueron definidos

como parte del plan táctico de transición.



Extensión SSD



4. En caso de eliminar componentes de sistema de servicio, archivar de

forma apropiada los componentes de sistema de servicio y quitarlos

del entorno de prestación de servicios.

Asegurar que se manejan adecuadamente las interfaces con los componentes de

sistema de servicio eliminados.

SP 2.2 Evaluar y controlar los impactos de la transición

Evaluar el impacto de la transición sobre las partes interesadas y

sobre la prestación de servicios, y realizar las acciones correctivas

apropiadas.

Las actividades de transición se extienden más allá de la instalación de los

nuevos componentes de sistema de servicio en el entorno de prestación de

servicios. El proveedor de servicios asegura que las operaciones de

servicio no se ven afectadas adversamente por los cambios recientes.

A menudo este periodo de evaluación puede extenderse por algún tiempo

para ayudar a asegurar que no se producen efectos no deseados de la

transición. Por ejemplo, en el dominio médico, una clínica pediátrica puede



implementar servicios específicos para ayudar a los padres de niños con

necesidades especiales. Los servicios podrían incluir un grupo facilitado de

padres, sesiones de terapia centralizadas, y guías educativas. Evaluar el

impacto de estos nuevos cambios en el sistema de servicio requeriría

recabar información de las familias con niños de varias edades y

diagnósticos. Puede que lleve bastante tiempo recabar estos datos y

asegurar que los nuevos servicios afectan positivamente a las partes


Adicionalmente, esta práctica asegura que el despliegue no degrada otros

aspectos del sistema de servicio o de la prestación de servicios en general.

Los impactos no anticipados se abordan de manera oportuna y en la forma

que se detalla en el plan táctico de transición. Se pueden implementar

planes de suspensión según se necesite en base a los impactos adversos

en el sistema.

Para más información sobre asegurar que las incidencias en el servicio se

resuelven de manera oportuna y eficaz y que las incidencias en el servicio

se previenen según sea apropiado, consúltese el área de proceso

Resolución y Prevención de Incidencias.


1. Revisión post-despliegue.

2. Artefactos de evaluación del despliegue.

Subprácticas

1. Utilizar métodos de recogida para recabar de las partes interesadas

relevantes información acerca del despliegue.

Algunos ejemplos de métodos son:

Encuestas.

Buzón de comentarios.

Formulario de entrada en una web.

2. Comunicar proactivamente la información sobre el impacto del

despliegue.

La comunicación se debería realizar siguiendo el plan táctico de transición del sistema

de servicio, y como mínimo debería incluir que las partes interesadas relevantes

confirmen que la transición se ha completado con éxito.

Se pueden utilizar varios medios de comunicación para asegurar que las partes interesadas relevantes sean conscientes de los problemas del despliegue:

Notificaciones por correo electrónico.

Notificaciones encastradas en el sistema.

Documentación sobre preguntas frecuentes (FAQ)

Señalización visible en el entorno de prestación de servicios.

Reuniones.



3. Para los impactos significativos, consultar en el plan táctico los

detalles acerca de cómo y cuándo se debería suspender o revertir el

despliegue.

4. Continuar evaluando y controlando los impactos hasta que los

problemas del despliegue se hayan resuelto.

Los impactos que potencial o realmente estén interfiriendo con la prestación de

servicios son incidencias en el servicio que se deberían gestionar utilizando el sistema

de gestión de incidencias.

5. Realizar una revisión post-despliegue.

Esta revisión identifica, recoge, y documenta las lecciones aprendidas del despliegue.

Esta información puede ser útil tanto para operar el sistema de servicio como para

futuras transiciones.

Se deberían incluir a las partes interesadas relevantes para abordar cuestiones tales como:

¿Está operando de forma eficaz la nueva funcionalidad?

¿Se han degradado otros aspectos del sistema de servicio?

¿Se han visto afectadas negativamente las partes interesadas?

¿Se han evaluado en profundidad la nueva funcionalidad y los atributos de calidad del sistema de servicio?


Gestión Estratégica de Servicios (STSM) 436

GESTIÓN ESTRATÉGICA DE SERVICIOS


Propósito

El propósito de Gestión Estratégica de Servicios (STSM) es establecer y

mantener los servicios estándar de acuerdo con las necesidades y planes

estratégicos.


El área de proceso Gestión Estratégica de Servicios engloba las siguientes

actividades:

Analizar las capacidades y necesidades de servicios que abarcan

múltiples clientes y acuerdos.

Establecer y mantener servicios estándar, niveles de servicio estándar,

y descripciones de que reflejen estas capacidades y necesidades.

Los procesos de gestión estratégica de servicios mejoran el alineamiento

entre el conjunto de servicios ofrecidos por la organización proveedora de

servicios y sus objetivos estratégicos de negocio. Si la organización es

pequeña o tiene una focalización reducida, los servicios estándar pueden

consistir en un único servicio o un grupo de servicios relativamente

limitado. Las organizaciones más grandes pueden tener un conjunto de

servicios estándar más complejo.

Analizar activamente los datos de clientes y competidores, las tendencias y

oportunidades del mercado, y las características de la organización, tales

como sus capacidades y fortalezas, produce información que la

organización utiliza para establecer los servicios estándar. Los servicios

estándar forman parte de lo que posibilita que se alcance un rendimiento

consistente en toda la organización. El objetivo de esta área de proceso no

es gestionar los servicios individuales sino obtener la información que se

necesita para realizar decisiones estratégicas y eficaces acerca del

conjunto de servicios estándar que la organización mantiene.

Los servicios estándar proporcionan una base para aprovechar al máximo

las capacidades que la organización proveedora tiene para lograr sus

objetivos de negocio. Los servicios estándar también pueden mejorar la

calidad del servicio, la captación de negocio, y la satisfacción tanto de los

clientes como de los usuarios finales, a la vez que reducen los costes, los

errores, y el tiempo para desarrollar y prestar servicios. Los niveles de

servicio estándar son un componente clave de los servicios estándar. Los

niveles de servicio hacen que las expectativas y responsabilidades entre la

organización de servicios y el cliente sean claras, especificas, y medibles.

En esta área de proceso, cuando se mencionan las necesidades del

cliente, también se incluyen las necesidades del usuario final. Las



necesidades del cliente y del usuario final pueden ser distintas. Es crítico

recoger y analizar los datos de ambas para desarrollar los servicios

estándar y para entender las necesidades y los planes estratégicos.

Los servicios estándar habitualmente se describen en un catálogo de

servicios que está orientado a las necesidades de información de los

clientes. Adicionalmente, se pueden mantener descripciones de los

servicios estándar orientadas a las necesidades del personal de la

organización proveedora de servicios.

Prestar atención a la satisfacción con los servicios vigentes y su uso

permite a la organización ajustar o corregir algunos servicios y puede

contribuir a planificar futuros servicios. La organización también puede

identificar requisitos para nuevos sistemas de servicio o cambios a

sistemas existentes. Estos sistemas pueden dar soporte a uno o varios

clientes.

Las prácticas específicas en esta área de proceso se complementan con

las prácticas en Definición Organizativa de Procesos, Enfoque Organizativo

en Procesos, y Rendimiento Organizativo de Procesos. En esas áreas de

proceso, la organización define, mejora, y entiende cuantitativamente sus

procesos estándar. Por contra, el foco más amplio de STSM se sitúa en los

servicios en lugar hacerlo sólo en los componentes de sistema de servicio

que puedan ser procesos.


Para más información sobre monitorizar el estado de las incidencias hasta

su cierre, consúltese el área de proceso Resolución y Prevención de

Incidencias.

Para más información sobre la prestación de servicios conforme a los

acuerdos de servicio, consúltese el área de proceso Prestación de

Servicios.

Extensión SSD



de Servicio.



Para más información sobre entender los requisitos, consúltese el área de

proceso Gestión de Requisitos.






SG 1 Establecer necesidades y planes estratégicos para los servicios estándar

SP 1.1 Recopilar y analizar datos

SP 1.2 Establecer planes para servicios estándar

SG 2 Establecer servicios estándar

SP 2.1 Establecer propiedades de servicios estándar y niveles de servicio estándar

SP 2.2 Establecer descripciones de servicios estándar


SG 1 Establecer necesidades y planes estratégicos para los servicios estándar

Las necesidades y los planes estratégicos para los servicios estándar se establecen y se mantienen.

Las “necesidades estratégicas” son condiciones u objetivos de la

organización que a menudo están supeditadas a factores del entorno. Una

organización puede necesitar incrementar sus ingresos, sus beneficios, o

su cuota de mercado. Los clientes pueden necesitar un conjunto de

servicios diferente o nuevo, o esperar un cambio en la oferta de servicios

de la organización en base a lo que los competidores están ofreciendo o a

los cambios en sus propios objetivos. La organización considera el rango

de necesidades a la luz de sus capacidades, toma decisiones acerca de

qué objetivos perseguir, y refleja esas necesidades y objetivos en planes

para los servicios estándar.

En muchas organizaciones, la información sobre planificación estratégica

puede ser privada, confidencial, y estar sujeta a requisitos de no-

divulgación o a otros controles. Para proteger la información estratégica

confidencial, cualquiera que participe en el desarrollo de planes para los

servicios estándar debería tener cuidado en cumplir con los controles.

SP 1.1 Recopilar y analizar datos

Recopilar y analizar datos acerca de las necesidades y

capacidades estratégicas de la organización.

La organización recopila y analiza datos que puedan ayudar a planificar los

servicios estándar que la organización va a establecer y mantener. Qué

datos son apropiados puede variar para distintos servicios, sectores de

mercado, y características organizativas tales como el tamaño. Los datos

proporcionarán visibilidad sobre las capacidades de la organización y las

necesidades de su mercado, incluyendo sus clientes y usuarios finales.



Algunos ejemplos de fuentes y técnicas para recopilar y analizar datos relevantes son:

Planes de negocio.

Investigación de mercado.

Encuestas.

Inteligencia de negocio.

Datos de revisiones de servicios y de gestión de cuentas.

Tendencias y patrones de uso de los servicios.

Quejas y felicitaciones de los clientes.

Patrones de incidencias y de peticiones de servicio.

Incumplimientos de los niveles de servicio.

Datos de competidores.

Estudios de mercado.

Planes.

Técnicas de planificación estratégica, tales como el análisis de debilidades, amenazas,

fortalezas, y oportunidades (DAFO).

Análisis de competencias esenciales.

Planificación de escenarios.

Ejemplos de producto de trabajo

1. Datos analizados sobre las capacidades de la organización.

2. Datos analizados sobre las necesidades estratégicas.

3. Descripciones de las capacidades de la organización.

4. Descripciones de las necesidades estratégicas.

Subprácticas

1. Recopilar y analizar datos sobre las capacidades de la organización.

2. Recopilar y analizar datos sobre las necesidades estratégicas de la

organización.

3. Describir las capacidades y necesidades estratégicas de la

organización.

4. Comunicar las descripciones a las partes interesadas relevantes.

SP 1.2 Establecer planes para servicios estándar

Establecer y mantener planes para los servicios estándar.

La planificación de servicios estándar traduce la información sobre las

capacidades y necesidades estratégicas de la organización en decisiones

acerca de los servicios estándar. Los planes para los servicios estándar

reflejan las acciones que son necesarias para equilibrar las capacidades de

la organización; las necesidades estratégicas, incluyendo las necesidades

de los clientes y usuarios finales; y las condiciones de competitividad en el

mercado.




1. Descripciones de objetivos estratégicos de negocio.

2. Descripciones de servicios potenciales.

3. Análisis de las necesidades del sistema de servicio.

4. Paquetes de decisión o de aprobación para los servicios

seleccionados.

5. Planes para los servicios estándar.

Subprácticas

1. Confirmar los objetivos estratégicos de negocio.

Los objetivos estratégicos de negocio de una organización de servicios pueden ser

explícitos y estar disponibles. Si no lo están, los planificadores que ejecuten esta

actividad documentan su interpretación de los objetivos implícitos como parte de su

planificación. Esta interpretación debería ser revisada y aprobada por la dirección.

2. Recomendar requisitos para los servicios estándar en base a los

objetivos estratégicos de negocio, las capacidades de la organización,

y las necesidades estratégicas.

3. Identificar las acciones que se necesitan para los servicios estándar.

Las acciones que se necesitan pueden incluir desarrollar nuevos servicios estándar,

revisar o mejorar los servicios estándar actuales, o retirar servicios estándar. En la

gestión de servicios, un modo de fallo conocido es no prestar atención a la gestión de

la obsolescencia de los servicios. Los servicios estándar que dejen de cumplir las

necesidades de los clientes o las capacidades actuales de la organización se

deberían retirar o se deberían modificar de forma que puedan cumplirlas. La

organización debería establecer prioridades y decidir sobre la temporización de las

acciones según sea apropiado.

Para más información sobre seleccionar mejoras, consúltese el área




Trabajos.

Los servicios estándar nuevos o modificados pueden requerir de nuevos sistemas de

servicio o de sistemas de servicio modificados. Estos sistemas de servicio pueden dar

soporte a uno o varios clientes y a uno o varios servicios estándar. Así, las acciones

que se necesitan también pueden incluir que se establezcan y mantengan “activos

esenciales” (p.ej. componentes, herramientas, arquitecturas, procedimientos

operativos, representaciones de sistemas de servicio, software) con el fin de

desarrollar o adaptar de forma más eficiente y eficaz los sistemas de servicio que

prestan servicios estándar a múltiples clientes.

Extensión SSD





4. Revisar y acordar con las partes interesadas relevantes los servicios

estándar que se van a establecer y mantener.

SG 2 Establecer servicios estándar

Se establece y se mantiene un conjunto de servicios estándar.

SP 2.1 Establecer propiedades de servicios estándar y niveles de servicio

estándar

Establecer y mantener las propiedades del conjunto de servicios

estándar y niveles de servicio estándar de la organización.

Puede que sea necesario disponer de múltiples servicios estándar y niveles

de servicio estándar para afrontar las necesidades de los diferentes

clientes, unidades de la organización, mercados, o dominios de aplicación.

Además de establecer servicios estándar, se pueden agrupar servicios en

líneas de servicio cuando el tamaño y la complejidad del conjunto de

servicios justifiquen una organización suplementaria La organización

desarrolla los procesos estándar para producir los servicios estándar.




1. Atributos críticos de los servicios estándar.

2. Conjunto de niveles de servicio estándar de la organización.

3. Plantillas de acuerdos de nivel de servicio (ANS’s).

4. Criterios de adaptación.

5. Partes comunes y partes variables de los servicios estándar.

6. Agrupaciones de los servicios en líneas de servicio.

7. Necesidades y expectativas para los sistemas de servicio que

producen servicios estándar.

Subprácticas

1. Seleccionar los servicios estándar.

Los servicios estándar seleccionados deberían cumplir las políticas, los estándares, y

los modelos organizativos.

2. Especificar los atributos críticos de cada servicio.



Algunos ejemplos de atributos críticos son:

Características y beneficios.

Niveles de servicio y categorías disponibles.

Costes.

Usuarios actuales.

Usuarios previstos.

Componentes de servicio.

Sistema de prestación de servicios.

Servicios relacionados.

3. Determinar las partes comunes y las partes variables de los servicios

estándar.

Se pueden asignar categorías y parámetros a las partes variables de un servicio

estándar. Los niveles de servicio estándar pueden representar algunos de los grados

de variabilidad de los servicios estándar.

Algunos ejemplos de variaciones permitidas son:

Precio

Proveedores de sub-servicios

Criterios para utilizar componentes del cliente

4. Organizar los servicios en líneas de servicio según se necesite.

Esta organización de servicios en líneas de servicio puede incluir que se asegure una

integración apropiada entre los servicios.

5. Definir niveles de servicio.

Los niveles de servicio definidos permiten que los niveles del servicio que se ofrecen

sean específicos y medibles. Los niveles de servicio pueden ayudar a equilibrar el

coste y la demanda de servicios, y a clarificar los roles y responsabilidades entre el

proveedor del servicio y el usuario.

Determinar los niveles de servicio incluye los siguientes requisitos de servicio:

El máximo periodo aceptable de pérdida continuada de un servicio.

El máximo periodo aceptable de servicio degradado.

El nivel de servicio degradado que es aceptable durante el periodo de recuperación del servicio.

Los requisitos de redundancia.

Los niveles de servicio estándar se pueden reflejar en acuerdos de nivel de servicio

estándar o en plantillas de acuerdo de nivel de servicio.



La información sobre el nivel de servicio incluye:

Responsabilidades del proveedor y del usuario.

Disponibilidad del servicio.

Horas de servicio acordadas y excepciones a éstas.

Volumen de servicio que se prevé.

Tiempos de respuesta para las incidencias en el servicio y para las peticiones.

Objetivos de rendimiento o de calidad.

Mediciones clave a monitorizar.

Procedimientos de reporte y escalado de problemas.

Consecuencias de no alcanzar un nivel de servicio.

Variaciones permitidas (p.ej. servicio “oro”).

6. Establecer criterios de adaptación según sea apropiado.

La organización utiliza el conocimiento sobre la variabilidad de las necesidades del

cliente para desarrollar opciones de adaptación que limiten el riesgo y mejoren la

satisfacción de los clientes y el plazo de comercialización, a la vez que mantienen la

consistencia en toda la organización.

Los criterios y guías de adaptación describen:

El modo de utilizar el conjunto de servicios estándar de la organización para guiar el desarrollo de los servicios individuales.

Los requisitos obligatorios que deben satisfacer los servicios definidos.

Las opciones que se pueden ejercer y los criterios para seleccionar entre las distintas opciones.

Los procedimientos que se deben seguir para realizar y documentar adaptaciones.

Algunos ejemplos de criterios y procedimientos de adaptación son:

Criterios para seleccionar servicios estándar de entre los servicios aprobados por la organización.

Criterios para seleccionar componentes de servicio de entre el conjunto de servicios estándar de la organización.

Procedimientos para adaptar los servicios y componentes de servicio seleccionados para ajustarse a las necesidades específicas.

Algunos ejemplos de acciones de adaptación son:

Modificar un nivel de servicio.

Combinar componentes de distintos servicios.

Modificar componentes de servicio.

Remplazar componentes de servicio.

Reordenar componentes de servicio.



Algunos ejemplos de razones para la adaptación son:

Adaptar el servicio a una nueva necesidad del cliente o un nuevo entorno de trabajo.

Retocar el servicio para un uso específico o una clase de usos similares.

7. Identificar las necesidades y expectativas sobre los sistemas de

servicio que producen servicios estándar según sea apropiado.

En situaciones en las que la organización necesite desarrollar y mantener múltiples

sistemas de servicio para producir sus servicios estándar, puede que sea beneficioso

establecer activos esenciales a nivel organizativo para desarrollar y adaptar al cliente

dichos sistemas de servicio.

Extensión SSD



SP 2.2 Establecer descripciones de servicios estándar

Establecer y mantener descripciones de los servicios estándar

definidos de la organización.

No es suficiente con establecer las propiedades de los servicios estándar.

Estas propiedades además se deberían empaquetar en descripciones de

servicio específicas. Además del conjunto de descripciones que usa el

proveedor de servicios, habitualmente se necesita una versión separada

para el cliente. Un modo de fallo común al utilizar servicios estándar es que

éstos se definen y describen para cubrir las necesidades de parte del

personal de la organización proveedora del servicio, pero no se describan

de forma eficaz y apropiada para todos los usuarios previstos de los

servicios estándar. Para que se puedan usar con éxito, los servicios

estándar se deberían describir de forma apropiada para el rango completo

de usuarios de las descripciones que se han previsto.


1. Descripciones de servicio.

2. Catálogo o menú de servicios.

3. Materiales complementarios tales como las instrucciones para el

personal de prestación de servicios, las instrucciones para los

comerciales, la información sobre propuestas y precios, y la

información contractual.

Subprácticas

1. Desarrollar las descripciones de los servicios estándar para todos los

usuarios relevantes.

También se puede desarrollar material adicional relacionado con los servicios

estándar cuando éstos aún no existen. Este material puede incluir información para

quienes desarrollan los servicios específicos, el personal de prestación de servicios, o

el personal de ventas y otros empleados.



2. Realizar revisiones entre pares de las descripciones con las partes


Se pueden incluir a los representantes del cliente y de los usuarios finales en estas

revisiones entre pares con objeto de asegurar que las descripciones cubren sus

necesidades de información.

3. Actualizar las descripciones según se necesite.

4. Almacenar las descripciones en una ubicación y en un medio al que

tengan acceso todos los usuarios previstos.

Para ser eficaces, las descripciones de servicio estándar deberían estar disponibles y

accesibles sistemáticamente en una ubicación que anime a que todo el abanico de

usuarios previstos las usen. Dependiendo de las características de los servicios y de

la organización, las descripciones pueden estar ubicadas en un gran y complejo

repositorio en línea o en una simple hoja de papel.

Aunque frecuentemente el catálogo o menú de servicios está en formato electrónico,

muchas organizaciones también producen una versión en papel. Junto a las

descripciones se puede almacenar material complementario, tal como las guías de

adaptación o instrucciones dirigidas al personal de prestación de servicios, los

comerciales, los autores de propuestas, y los especialistas en contratación. Puede

que se requieran distintas variantes del catálogo o menú de servicios para los clientes

y el personal de la organización proveedora de servicios.

Algunos ejemplos de localización del repositorio de servicios estándar son:

Base de datos de gestión de configuración.

Páginas web.

Carpeta o biblioteca de documentos.

Biblioteca de activos de proceso.


Monitorización y Control de Trabajos (WMC) 446

MONITORIZACIÓN Y CONTROL DE TRABAJOS


Propósito

El propósito de Monitorización y Control de Trabajos (WMC) es

proporcionar información sobre el trabajo en curso de forma que se puedan

realizar las acciones correctivas apropiadas cuando el rendimiento se

desvíe significativamente del plan.


Un plan de trabajo documentado es la base para monitorizar las

actividades, comunicar el estado, y realizar las acciones correctivas. El

progreso o estado se determina principalmente comparando los atributos,

los esfuerzos, los costes, y los plazos reales de los productos de trabajo y

las tareas con el plan en los intervalos, los hitos, o los niveles de control

prestablecidos en el cronograma o en la EDT. Disponer de visibilidad

apropiada sobre el progreso posibilita que se realicen acciones correctivas

de manera oportuna cuando el rendimiento se desvía significativamente del

plan. Una desviación es significativa si, de no resolverse, impide que los

trabajos logren sus objetivos.

El término “plan de trabajo”, se utiliza en esta área de proceso para

referirse al plan global para controlar el trabajo.

Cuando el estado real se desvía significativamente con respecto a los

valores esperados, se llevan a cabo acciones correctivas según sea

apropiado. Estas acciones pueden requerir que se replanifique, lo que

puede significar que se modifique el plan original, que se establezcan

nuevos acuerdos, o que se incluyan en el plan actual actividades de

mitigación adicionales.




Disponibilidad.

Para más información sobre proporcionar resultados de medición,


Para más información sobre establecer y mantener planes que definan los

trabajos, consúltese el área de proceso Planificación de Trabajos.




SG 1 Monitorizar el trabajo con respecto al plan

SP 1.1 Monitorizar parámetros de planificación del trabajo

SP 1.2 Monitorizar compromisos

SP 1.3 Monitorizar riesgos

SP 1.4 Monitorizar la gestión de datos

SP 1.5 Monitorizar la involucración de las partes interesadas

SP 1.6 Realizar revisiones de progreso

SP 1.7 Realizar revisiones de hitos

SG 2 Gestionar acciones correctivas hasta su cierre

SP 2.1 Analizar problemas

SP 2.2 Realizar acciones correctivas

SP 2.3 Gestionar acciones correctivas


SG 1 Monitorizar el trabajo con respecto al plan

El progreso y el rendimiento reales se monitorizan con respecto al plan de trabajo.

SP 1.1 Monitorizar parámetros de planificación del trabajo

Monitorizar los valores reales de los parámetros de planificación

con respecto al plan de trabajo.

Los parámetros de planificación del trabajo habitualmente constituyen

indicadores del progreso y el rendimiento, e incluyen a los atributos de los

productos de trabajo y tareas, los costes, los esfuerzos, y los plazos.

Dentro de los atributos de los productos de trabajo y tareas se incluyen el

tamaño, la complejidad, los niveles de servicio, la disponibilidad, el peso, la

forma, la adecuación, y la función. La frecuencia de monitorización de

parámetros debería ser tenida en cuenta.

Las consideraciones sobre la frecuencia pueden incluir la posible

necesidad de monitorizar cada petición de servicio o incidencia, o incluso la

posible monitorización continua de los servicios prestados.

Monitorizar habitualmente implica medir los valores reales de los

parámetros de planificación, comparar los valores reales con los estimados

en el plan, e identificar las desviaciones significativas. Registrar los valores

reales de los parámetros de planificación incluye registrar la información

contextual asociada que se necesita para ayudar a entender las medidas.

El análisis del impacto que tienen las desviaciones significativas para

determinar las acciones correctivas que hay que realizar se maneja en la

meta específica 2 de esta área de proceso.


1. Registros de rendimiento.

2. Registros de desviaciones significativas.

3. Informes de rendimiento de costes.



Subprácticas

1. Monitorizar el progreso con respecto al cronograma.

Habitualmente la monitorización del progreso incluye:

Medir periódicamente las actividades e hitos que realmente se han completado.

Comparar las actividades e hitos que realmente se han completado frente a las que se habían planificado en el cronograma.

Identificar las desviaciones significativas con respecto a las estimaciones de plazos planificadas.

2. Monitorizar los costes y los esfuerzos empleados en el trabajo.

Habitualmente la monitorización de los costes y los esfuerzos incluye:

Medir periódicamente los costes y los esfuerzos empleados y el personal que está realmente asignado.

Comparar los esfuerzos, los costes, el personal, y la capacitación reales con los presupuestos y estimaciones planificados.

Identificar las desviaciones significativas con respecto al presupuesto y estimaciones planificados.

3. Monitorizar los atributos de los productos de trabajo y las tareas.

Para más información sobre desarrollar y mantener una competencia

de medición que se use para dar soporte a las necesidades de

información de la gerencia, consúltese el área de proceso Medición y

Análisis.

Para más información sobre establecer las estimaciones de los

productos de trabajo y los atributos de las tareas, consúltese el área

de proceso Planificación de Trabajos.

Habitualmente la monitorización de los atributos de los productos de trabajo y las tareas incluye:

Medir periódicamente los atributos reales de los productos de trabajo y las tareas, tales como el tamaño, la complejidad, o los niveles de servicio (y los cambios a dichos atributos).

Comparar los atributos reales de los productos de trabajo y las tareas (y los cambios a dichos atributos) con las estimaciones en el plan de trabajo.

Identificar las desviaciones significativas con respecto a las estimaciones en el plan de trabajo.

4. Monitorizar los recursos proporcionados y los utilizados.



Disponibilidad.

Para más información sobre planificar los recursos, consúltese el área




Algunos ejemplos de recursos son:

Instalaciones físicas.

Ordenadores, periféricos, y software.

Redes.

Entorno de seguridad.

Personal.

Procesos.

5. Monitorizar los conocimientos y habilidades de los miembros del grupo

de trabajo.

Para más información sobre planificar los conocimientos y habilidades

que se necesitan, consúltese el área de proceso Planificación de

Trabajos.

La monitorización de los conocimientos y habilidades del personal del grupo de trabajo habitualmente incluye:

Medir periódicamente el aprendizaje de conocimientos y habilidades por parte del personal del grupo de trabajo.

Comparar la capacitación real obtenida con la documentada en el plan de trabajo.

Identificar las desviaciones significativas con respecto a las estimaciones en el plan de trabajo.

6. Documentar las desviaciones significativas de los parámetros de

planificación.

SP 1.2 Monitorizar compromisos

Monitorizar los compromisos con respecto a los que se

identificaron en el plan de trabajo.


1. Registros de revisiones de compromisos.

Subprácticas

1. Revisar regularmente los compromisos (tanto externos como internos).

2. Identificar los compromisos que no se hayan cumplido o que tengan

un riesgo significativo de no cumplirse.

3. Documentar los resultados de las revisiones de compromisos.

SP 1.3 Monitorizar riesgos

Monitorizar los riesgos frente a aquellos identificados en el plan de

trabajo.

Para más información sobre identificar problemas potenciales antes de que

ocurran de forma que se puedan planificar e invocar actividades de manejo

de riesgos según se necesite durante la vida del producto o trabajo a fin de

mitigar los impactos adversos sobre el logro de objetivos, consúltese el




Para más información sobre identificar riesgos, consúltese el área de



1. Registros de monitorización de riesgos.

Subprácticas

1. Revisar periódicamente la documentación de riesgos en el contexto

del estado y de las circunstancias actuales del trabajo.

Un ejemplo de riesgo cuyo estado podría cambiar sería una amenaza a la continuidad de las operaciones, o un cambio en el promedio de la mezcla de tipos de petición provenientes de los usuarios finales. Si la probabilidad del riesgo ha aumentado o si el impacto potencial es más grave, entonces puede que sean necesarias acciones correctivas.

2. Actualizar la documentación de los riesgos a medida que se dispone

de información adicional.

A medida que avanza el trabajo (especialmente en los trabajos de larga duración o en

la operación continua) surgen nuevos riesgos. Es importante identificar y analizar

estos nuevos riesgos. Por ejemplo, puede que queden obsoletos el software, los

equipamientos, y las herramientas; o puede que el personal clave pierda

gradualmente habilidades en las áreas de particular importancia a largo plazo para el

grupo de trabajo y la organización.

3. Comunicar el estado de los riesgos a las partes interesadas

relevantes.

Algunos ejemplos de estados de los riesgos son:

Un cambio en la probabilidad de ocurrencia del riesgo.

Un cambio en la prioridad del riesgo.

SP 1.4 Monitorizar la gestión de datos

Monitorizar la gestión de los datos con respecto al plan de trabajo.

Para más información sobre identificar los tipos de datos a gestionar y el

modo de planificar su gestión, consúltese la práctica específica Planificar la

gestión de datos en el área de proceso Planificación de Trabajos.

Las actividades de gestión de datos se deberían monitorizar para asegurar

que los requisitos de gestión de datos se cumplen. Dependiendo de los

resultados de la monitorización y de los cambios en los requisitos, las

circunstancias, o el estado, puede que sea necesario replanificar las

actividades de gestión de datos del grupo de trabajo.


1. Registros de gestión de datos.

Subprácticas

1. Revisar periódicamente las actividades de gestión de datos frente a

sus descripciones en el plan de trabajo.



2. Identificar y documentar los problemas significativos y sus impactos.

Un ejemplo de problema significativo sería cuando algunas partes interesadas no tienen acceso a los datos que necesitan para cumplir sus roles como partes interesadas relevantes.

3. Documentar los resultados de revisar las actividades de gestión de

datos.

SP 1.5 Monitorizar la involucración de las partes interesadas

Monitorizar la involucración de las partes interesadas con respecto

al plan.

Para más información sobre identificar a las partes interesadas relevantes

y planificar su involucración apropiada, consúltese la práctica específica

Planificar la involucración de las partes interesadas en el área de proceso

Planificación de Trabajos.

La involucración de las partes interesadas se debería monitorizar para

asegurar que se producen las interacciones apropiadas. Dependiendo de

los resultados de la monitorización y de los cambios en los requisitos del

trabajo, las circunstancias, o el estado, puede que sea necesario

replanificar la involucración de las partes interesadas.


1. Registros de la involucración de las partes interesadas.

Subprácticas

1. Revisar periódicamente el estado de la involucración de las partes

interesadas.


3. Documentar los resultados de las revisiones del estado de la

involucración de las partes interesadas.

SP 1.6 Realizar revisiones de progreso

Revisar periódicamente el progreso, el rendimiento, y los

problemas del trabajo.

El “progreso” del trabajo se refiere a la situación del trabajo en un momento

determinado en el que las partes interesadas relevantes (especialmente los

representantes del grupo de trabajo y la gerencia del grupo de trabajo)

revisan las actividades de trabajo realizadas hasta ese momento y sus

resultados e impactos con el fin de determinar si existen problemas

significativos o carencias de rendimiento que se deban abordar.

Las revisiones de estado o de progreso son revisiones del trabajo que se

realizan para mantener a las partes interesadas relevantes informadas.

Estas revisiones pueden ser informales y no estar especificadas

explícitamente en los planes de trabajo.


1. Resultados documentados de la revisión del trabajo.



Subprácticas

1. Regularmente, comunicar a las partes interesadas relevantes el

estado de las actividades y los productos de trabajo asignados.

En estas revisiones se incluye a la gerencia, el personal, los clientes, los usuarios

finales, los suministradores, y las otras partes interesadas relevantes según sea

apropiado.

2. Revisar los resultados de la recogida y análisis de medidas para

controlar el trabajo.

Las mediciones que se revisan incluyen a aquellas que se recogen para medir los

parámetros de servicio identificados en la planificación de trabajos (p. ej.

disponibilidad, número de usuarios) y pueden incluir las recogidas para medir la

satisfacción de clientes.




3. Identificar y documentar los problemas y las desviaciones significativos

con respecto al plan.

4. Documentar las peticiones de cambio y los problemas identificados en

los productos de trabajo y los procesos.

Para más información sobre seguir y controlar los cambios, consúltese

al área de proceso Gestión de Configuración.

5. Documentar el resultado de las revisiones.

6. Seguir las peticiones de cambio y los informes de problema hasta su

cierre.

SP 1.7 Realizar revisiones de hitos

Revisar los logros y los resultados en los hitos seleccionados.

Para más información sobre identificar los hitos principales, consúltese la

práctica específica Establecer el presupuesto y el cronograma en el área


Los hitos son eventos o momentos prestablecidos en los que se lleva a

cabo una revisión minuciosa del estado con objeto de entender el grado en

el que se están cumpliendo los requisitos de las partes interesadas (si el

trabajo incluye un hito en el desarrollo, entonces la revisión se lleva a cabo

para asegurar que se están cumpliendo los supuestos y requisitos

asociados a ese hito). Los hitos se pueden asociar al trabajo global o a una

instancia o tipo de servicio concreto. Por tanto, los hitos pueden estar

basados en eventos o basados en el calendario.

Las revisiones de hitos se planifican durante la planificación de trabajos y

habitualmente son revisiones formales.

No es necesario realizar las revisiones de progreso y las de hitos por

separado. Los propósitos de ambas revisiones se pueden abordar en una

única revisión. Por ejemplo, en una única revisión prestablecida se pueden



evaluar el progreso, los problemas, y el rendimiento alcanzados hasta un

momento (o un hito) planificado con respecto a las expectativas del plan.

Dependiendo del tipo de trabajo, el “arranque” y el “cierre” podrían ser

fases cubiertas por las revisiones de hitos.


1. Resultados documentados de las revisiones de hitos.

Subprácticas

1. Llevar a cabo revisiones de hitos con las partes interesadas relevantes

en puntos significativos del cronograma del trabajo, tales como al

terminar las fases seleccionadas.

En las revisiones de hitos se incluye a la gerencia, el personal, los clientes, los

usuarios finales, los suministradores, y las otras partes interesadas relevantes según

sea apropiado.

2. Revisar los compromisos, el plan, el estado, y los riesgos del trabajo.


4. Documentar los resultados de la revisión, las acciones, y las

decisiones.

5. Seguir las acciones hasta su cierre.

SG 2 Gestionar acciones correctivas hasta su cierre

Se gestionan acciones correctivas hasta su cierre cuando el rendimiento del trabajo o los resultados se desvíen significativamente con respecto al plan.

SP 2.1 Analizar problemas

Recopilar y analizar los problemas y determinar las acciones

correctivas para tratarlos.

Este análisis se realiza por motivos distintos y generalmente se analizan

problemas distintos que en los análisis realizados como parte de los

análisis de incidencias y los análisis de peticiones de cambio. Sin embargo,

se pueden utilizar los mismos mecanismos o mecanismos similares para

analizar este tipo de problemas y gestionarlos hasta su cierre. La mejor

forma de implementar una solución común para analizar los problemas y

gestionarlos hasta su cierre depende del riesgo de no manejar cada

problema apropiadamente y de los costes que tienen las soluciones

alternativas.


1. Lista de problemas que requieren acciones correctivas.

Subprácticas

1. Recopilar problemas a analizar.

Los problemas se recopilan a partir de las revisiones y de ejecutar otros procesos.



Algunos ejemplos de problemas que se recopilan son:

Problemas descubiertos al realizar verificaciones o validaciones.

Desviaciones significativas de los parámetros de planificación con respecto a las estimaciones en el plan de trabajo.

Compromisos que no se han satisfecho (tanto internos como externos).

Cambios significativos en los estados de los riesgos.

Problemas de acceso, recogida, privacidad, o seguridad de los datos.

Problemas de representación o de involucración de las partes interesadas.

Supuestos (u otros compromisos del cliente o de los suministradores) sobre los productos, las herramientas, o el entorno de transición que no se han cumplido.

2. Analizar los problemas para determinar si se necesitan acciones

correctivas.

Para más información sobre criterios para las acciones correctivas,

consúltese la práctica específica Establecer el presupuesto y el

cronograma en el área de proceso Planificación de Trabajos.

Se requiere una acción correctiva cuando el problema, si se deja sin resolver, puede

impedir que el trabajo logre sus objetivos.

SP 2.2 Realizar acciones correctivas

Realizar acciones correctivas sobre los problemas identificados.


1. Planes de acciones correctivas.

Subprácticas

1. Determinar y documentar las acciones apropiadas que son necesarias

para tratar los problemas identificados.

Para más información sobre desarrollar planes de trabajo, consúltese


Algunos ejemplos de acciones potenciales son:

Modificar la declaración del trabajo.

Modificar los requisitos.

Revisar las estimaciones y los planes.

Renegociar los compromisos.

Añadir recursos.

Cambiar los procesos.

Revisar los riesgos.

2. Revisar y acordar con las partes interesadas relevantes las acciones a

realizar.

3. Negociar los cambios en los compromisos internos y externos.



SP 2.3 Gestionar acciones correctivas

Gestionar las acciones correctivas hasta su cierre.


1. Resultados de la acción correctiva.

Subprácticas

1. Monitorizar que se completen las acciones correctivas.

Para más información sobre monitorizar el estado de las incidencias

hasta su cierre, consúltese el área de proceso Resolución y

Prevención de Incidencias.

2. Analizar los resultados de las acciones correctivas para determinar su

eficacia.

3. Determinar y documentar las acciones apropiadas para corregir las

desviaciones con respecto al resultado planeado de realizar las

acciones correctivas.

Las lecciones aprendidas que son el resultado de las acciones correctivas pueden ser

una entrada de los procesos de planificación y de gestión de riesgos.


Planificación de Trabajos (WP) 456

PLANIFICACIÓN DE TRABAJOS


Propósito

El propósito de Planificación de Trabajos (WP) es establecer y mantener

los planes que definan los trabajos.


Planificar es una de claves para gestionar el trabajo eficazmente. El área

de proceso Planificación de Trabajos engloba las siguientes actividades:

Desarrollar el plan de trabajo.

Interactuar apropiadamente con las partes interesadas relevantes.

Obtener el compromiso con el plan.

Mantener el plan.

Planificar incluye estimar los atributos de los productos de trabajo y de las

tareas, determinar los recursos necesarios, negociar los compromisos,

elaborar un cronograma, e identificar y analizar los riesgos. Para establecer

el plan de trabajo puede que sea necesario realizar iteraciones de estas

actividades. El plan de trabajo proporciona la base para realizar y controlar

las actividades del trabajo que afrontan los compromisos con el cliente.

Habitualmente el plan de trabajo se actualiza a medida que el trabajo

progresa con el fin de afrontar los cambios en los requisitos y los

compromisos, las estimaciones inexactas, las acciones correctivas, y los

cambios de proceso. Las prácticas específicas que describen tanto

planificar como replanificar están contenidas en esta área de proceso.

El término “plan de trabajo” se utiliza en esta área de proceso para referirse

al plan global para controlar el trabajo. El plan de trabajo puede ser un

único documento o puede estar distribuido en múltiples documentos. En

cualquier caso, se debería incluir una imagen coherente de quién hace

qué. Igualmente, la monitorización y el control pueden estar centralizados o

distribuidos, siempre y cuando sea posible mantener una imagen coherente

del estado del trabajo a nivel del equipo de trabajo.

Puede que los grupos de trabajo que dan respuesta a las peticiones de

servicio generadas a lo largo del tiempo por los usuarios finales requieran

un nivel completo de planes detallados y actualizados frecuentemente para

poder gestionar las asignaciones de recurso-tarea y las colas de tareas

(p.ej. asignar trabajos de reparación en un taller de mantenimiento). Estos

planes operativos de bajo nivel se pueden considerar como una extensión

detallada del plan global del trabajo.

Para las líneas de producto y los servicios estándar, varios conjuntos de

actividades de trabajo se podrían beneficiar de las prácticas en esta área



de proceso. Estas actividades incluyen la creación y el mantenimiento de

los activos esenciales (p. ej. componentes, herramientas, arquitecturas,

procedimientos operativos, representaciones del sistema de servicio,

software) y el soporte para que se usen; el desarrollo de cada servicio

individual a partir de los activos esenciales; y la coordinación de la labor

general de desarrollo, uso, y mejora de los servicios estándar.








Extensión SSD


partes interesadas y desarrollar el sistema de servicio, consúltese el área

de proceso Desarrollo del Sistema de Servicio.

Para más información sobre recabar y analizar datos, consúltese el área de




Para más información sobre gestionar requisitos, consúltese el área de

proceso Gestión de Requisitos.






SG 1 Establecer estimaciones

SP 1.1 Establecer la estrategia de servicio

SP 1.2 Estimar el alcance del trabajo

SP 1.3 Establecer estimaciones de los atributos de productos de trabajo y tareas

SP 1.4 Definir fases del ciclo de vida

SP 1.5 Estimar el esfuerzo y el coste

SG 2 Desarrollar un plan de trabajo

SP 2.1 Establecer el presupuesto y el cronograma


SP 2.3 Planificar la gestión de datos

SP 2.4 Planificar los recursos

SP 2.5 Planificar los conocimientos y las habilidades que se necesitan

SP 2.6 Planificar la involucración de las partes interesadas

SP 2.7 Establecer el plan de trabajo

SG 3 Obtener el compromiso con el plan

SP 3.1 Revisar los planes que afecten al trabajo

SP 3.2 Conciliar los niveles de trabajo y de recursos

SP 3.3 Obtener el compromiso con el plan


SG 1 Establecer estimaciones

Las estimaciones de los parámetros de planificación del trabajo se establecen y se mantienen.

Los parámetros de planificación del trabajo incluyen toda la información

que el grupo de trabajo necesita para planificar, organizar, asignar

personal, dirigir, coordinar, reportar, y presupuestar lo que se necesite.

Las estimaciones de los parámetros de planificación deberían tener una

base sólida para infundir confianza en que los planes que están basados

en dichas estimaciones son capaces de sustentar los objetivos del trabajo.

Los factores a considerar al estimar estos parámetros incluyen los

requisitos del trabajo, incluyendo los requisitos del producto, los requisitos

impuestos por la organización, los requisitos impuestos por el cliente, y los

otros requisitos que afecten al trabajo.

Otros factores adicionales para los servicios incluyen la estrategia de

servicio, los servicios y niveles de servicio identificados, y el modo en que

se van a manejar las incidencias y peticiones.

Se necesita documentación de la justificación de las estimaciones y datos

de soporte para que las partes interesadas puedan revisar el plan y

comprometerse con él y para mantener el plan a medida que el trabajo

progresa.



SP 1.1 Establecer la estrategia de servicio

Establecer y mantener la estrategia de servicio.

La estrategia de servicio proporciona el marco de negocio para planificar y

gestionar el trabajo. La estrategia incluye consideraciones de los siguientes

factores a un nivel de abstracción apropiado:

Los objetivos y las restricciones del servicio.

Los posibles enfoques para lograr dichos objetivos y restricciones.

Los recursos que se necesitan (p. ej. habilidades, entornos,

herramientas, nuevas tecnologías).

Los riesgos asociados con estos factores y el modo en que han de

tratarse.

Habitualmente, la estrategia de servicio tiene una visión del servicio a largo

plazo, refleja su alcance completo, considera los riesgos a largo plazo, y

aborda los roles que deben llevar a cabo las múltiples partes interesadas,

incluyendo los suministradores, los clientes, y los otros grupos de trabajo.

La estrategia de servicio puede desempeñar varios papeles, pero habitual

e inicialmente sirve como base para que la dirección apruebe un servicio y

comprometa los recursos que éste necesita. Puede que sea necesario

actualizar la estrategia de servicio a medida que se realiza la planificación

del trabajo y que se exploran y desarrollan la solución, los procesos, los

recursos, y los riesgos.

Para un servicio de corta duración, es posible que no se desarrolle una

estrategia, o que sólo se desarrolle una vez, en cuyo caso ésta es

reemplazada por el plan de trabajo a medida que el trabajo del servicio

progresa y se hace posible planificar en detalle.

Para un servicio de larga duración, la estrategia desempeña un papel

continuado de ayudar a mantener una perspectiva y una justificación del

servicio a largo plazo, comprendiendo varios elementos del plan de trabajo

pero a un nivel mayor de abstracción, en tanto que el plan de trabajo

habitualmente reflejará un nivel mucho más detallado sobre un horizonte

temporal más cercano.

Inicialmente, una estrategia de servicio puede ser creada por la

organización o por el personal del servicio ulterior, quizás colaborando con

los potenciales clientes y suministradores, o con otra combinación de

partes que tengan una visión estratégica de negocio de las posibilidades

que tiene el servicio.

La estrategia de servicio puede incluir una descripción de alto nivel de los

servicios que se van a prestar, el enfoque para desarrollar el sistema de

servicio, y el enfoque para prestar los servicios según sea apropiado.




1. Estrategia de servicio.

Subprácticas

1. Identificar los objetivos del servicio y las capacidades que éste

pretende proporcionar.

La organización puede mantener una estrategia de negocio global en la cual el

servicio desempeñe un papel al establecer las capacidades que la organización

necesita. Los objetivos y capacidades relativos al servicio descritos en esta

subpráctica pueden haberse derivado de tales consideraciones del negocio global,

pero tenderán a convertirse en un conjunto de objetivos y capacidades específicos o a

corto plazo.

Para más información sobre establecer y mantener los servicios

estándar conforme a las necesidades y planes estratégicos,

consúltese el área de proceso Gestión Estratégica de Servicios.

2. Identificar el enfoque utilizado para lograr los objetivos o proveer las

capacidades.

A menudo existirá un enfoque para desarrollar la infraestructura que se necesita para

prestar los servicios (p. ej. enfoque técnico) y un enfoque para la prestación que tenga

en cuenta la satisfacción de los clientes, los niveles de cualificación que se necesitan,

los niveles de cualificación disponibles, los costes, y los riesgos.

Para más información sobre establecer el enfoque de prestación de

servicios, consúltese el área de proceso Prestación de Servicios.

3. Documentar las consideraciones de negocio.

Las consideraciones de negocio incluyen los costes y beneficios potenciales, la

propiedad intelectual, las condiciones de competencia, el envejecimiento de la

industria y su impacto en las necesidades y los márgenes de beneficio a largo plazo,

las competencias esenciales que la organización debe mejorar, las competencias

esenciales que se necesitan de otras partes, y las tendencias futuras en la sociedad,

el comercio, y la tecnología

4. Identificar las necesidades de recursos principales.

Revisar el enfoque de servicio ayuda a identificar las categorías de recurso que el

servicio y los suministradores de dichos recursos necesitan (p. ej. otros grupos de

negocio dentro de la organización, grupos funcionales específicos, recursos humanos,

expertos en propiedad intelectual, el departamento legal, el departamento de

marketing, socios comerciales, suministradores externos).





5. Identificar a las partes interesadas que desempeñarán un rol principal

en el servicio.



La práctica específica Planificar la involucración de las partes interesadas proporciona

una consideración más detallada, aunque quizás a más corto plazo, de cuáles son las

partes interesadas que se deben involucrar en el servicio y en qué modo.

Puede que el enfoque de servicio se pueda apoyar en las partes interesadas externas

(p. ej. clientes y socios comerciales actuales y potenciales) para que proporcionen

algunos de los recursos que son necesarios.

6. Identificar los tipos de acuerdo que se van a utilizar.

Para que el servicio tenga éxito, éste debería establecer acuerdos con sus principales

partes interesadas. La naturaleza de dichos acuerdos se determina, en parte,

considerando las necesidades, los objetivos, las expectativas, las restricciones, y los

riesgos de cada una de las partes. El negocio debería tener en cuenta los tipos de

acuerdo seleccionados y así ayudar a resolver el modo en que las distintas partes

compartirán los riesgos, los costes, y los beneficios del servicio.

7. Identificar los riesgos y el modo en que éstos se pueden asignar a las

distintas partes interesadas.

La práctica específica Identificar riesgos en esta área de proceso proporciona una

consideración más detallada, aunque quizás a más corto plazo, de los riesgos que el

servicio puede encontrar.

8. Identificar el enfoque a utilizar para mantener la seguridad y la

protección en el servicio.

En todas las actividades de planificación principales (p. ej. aquellas actividades de

planificación relacionadas con los objetivos del servicio, los recursos, los riesgos, las

partes interesadas), se debería prestar atención a la seguridad y protección, pero esta

subpráctica sugiere tener una visión y una focalización integral de los riesgos y

problemas de seguridad y protección, así como de las actividades que el servicio

podría incluir para abordarlos.

9. Revisar la estrategia de servicio con la dirección y obtener su

aceptación.

Revisar la estrategia de servicio desde las siguientes perspectivas de negocio claves:

¿Son correctos estos objetivos?

¿Es factible el enfoque?

¿Es esta estrategia una forma apropiada de asignar los recursos de la organización por un periodo de tiempo prolongado?

¿Cuál es el retorno de la inversión?

¿Qué oportunidades se abren como resultado de esta estrategia?

¿Estará la organización expuesta a riesgos excesivos?

¿Qué roles pueden tener en el éxito del servicio algunas partes interesadas principales que aún no estén identificadas?

¿Cómo podrían reaccionar los clientes, los suministradores, y los competidores?

10. Actualizar la estrategia de servicio según se necesite.

Dependiendo de la duración del servicio, puede que sea necesario refinar la estrategia

de servicio para reflejar cambios en los objetivos, el enfoque, la disponibilidad de los



recursos, las condiciones del mercado, las necesidades de los clientes, las

tecnologías de proceso y de producto, etc.

SP 1.2 Estimar el alcance del trabajo

Establecer una estructura de descomposición del trabajo (EDT) de

alto nivel para estimar el alcance del trabajo.

La EDT evoluciona con el trabajo. Una EDT de alto nivel puede servir para

estructurar la estimación inicial. El desarrollo de una EDT divide el trabajo

global en un conjunto interconectado de componentes manejables.

La EDT habitualmente es una estructura orientada a producto, a producto

de trabajo, o a tareas, que proporciona un esquema para identificar y

organizar las unidades lógicas de trabajo que se van a gestionar, las cuales

se llaman “paquetes de trabajo”. La EDT proporciona una referencia y un

mecanismo organizativo para asignar tareas, plazos, y responsabilidades, y

se usa como marco básico para planificar, organizar, y controlar el trabajo.

Las actividades en la EDT se pueden organizar de formas diversas, pero

habitualmente están delimitadas por el tiempo o la duración y abordan

tanto el desarrollo y mantenimiento del sistema de servicio como la

prestación de servicios según sea apropiado. Algunos de los servicios

identificados se pueden prestar de forma continua; otros se pueden prestar

en respuesta a peticiones ocasionales. En ambos casos están

especificados en un (posiblemente futuro) acuerdo de servicio.

Las actividades se pueden subdividir en una o más dimensiones. Por

ejemplo, en el caso del mantenimiento de productos, las actividades

podrían subdividirse distinguiéndolas entre las actividades que persistirán

hasta el final de la vida del producto (desde la entrega del producto hasta

su eliminación), las actividades relacionadas con la gestión y ejecución del

acuerdo de servicio, y las actividades relacionadas con incidencias o

peticiones de servicio concretas.


1. Descripciones de tareas.

2. Descripciones de paquetes de trabajo.

3. EDT.

Subprácticas

1. Desarrollar una EDT en base a la estrategia de servicio.

La EDT proporciona un esquema para organizar el trabajo. La EDT debería permitir

identificar los siguientes elementos:

Riesgos y tareas para mitigarlos.

Tareas para los entregables y las actividades de soporte.

Tareas para la adquisición de habilidades y conocimientos.

Tareas para el desarrollo de los planes de soporte que se necesitan, tales como los planes de gestión de configuración, de aseguramiento de calidad, y de verificación.



Tareas para la integración y la gestión de los elementos que no son de desarrollo.

2. Definir los paquetes de trabajo con el nivel de detalle suficiente para

que se puedan especificar las estimaciones de las tareas, las

responsabilidades, y los plazos.

La EDT de alto nivel pretende ayudar a calibrar el esfuerzo que se necesita para

realizar las tareas y desempeñar los roles y responsabilidades organizativos. Que a

este nivel haya más detalle en la EDT ayuda a desarrollar cronogramas realistas,

minimizando así la necesidad de reservas de gestión.

3. Identificar los productos y los componentes de producto a adquirir

externamente.




4. Identificar los productos de trabajo que se van a reutilizar.

SP 1.3 Establecer estimaciones de los atributos de productos de trabajo y tareas

Establecer y mantener las estimaciones de los atributos de los

productos de trabajo y de las tareas.

El tamaño es la entrada principal de muchos modelos usados para estimar

el esfuerzo, el coste, y los plazos. Los modelos también pueden estar

basados en otros atributos, tales como el nivel de servicio, la conectividad,

la complejidad, la disponibilidad, y la estructura.

Algunos ejemplos de atributos de estimación incluyen:

Número de requisitos.

Número y complejidad de las interfaces.

Volumen de datos.

Número de elementos de riesgo.

Número de niveles de servicio.

Disponibilidad de los servicios, por nivel de servicio (p. ej. tiempo de resolución, ratio de

disponibilidad operativa, número de llamadas por hora que atención a usuarios debería

ser capaz de manejar).

Número de partes interesadas afectadas por un nivel de servicio.

Experiencia de los participantes en el grupo de trabajo.

Velocidad o productividad del equipo.

Dispersión geográfica de los miembros del grupo de trabajo.

Proximidad de los clientes, los usuarios finales, y los suministradores.

Las estimaciones deberían ser consistentes con los requisitos cuando se

determina el esfuerzo, el coste, y los plazos del trabajo. A cada atributo de

tamaño se le debería asignar un nivel relativo de dificultad o complejidad.




1. Tamaño y complejidad de tareas y productos de trabajo.

2. Modelos de estimación.

3. Estimaciones de atributos.

Subprácticas

1. Usar los métodos apropiados para determinar los atributos de los

productos de trabajo y de las tareas que se utilizarán para estimar las

necesidades de recursos.

Los métodos para determinar el tamaño y la complejidad se deberían basar en

modelos validados o en datos históricos.

Los métodos para determinar los atributos evolucionan a medida que se entienden

mejor las relaciones que existen entre las características del desarrollo y la prestación

del servicio y los atributos.

2. Estimar los atributos de los productos de trabajo y de las tareas.

Algunos ejemplos de tareas para las cuales se realizan estimaciones de tamaño son:

Desarrollo y entrega del sistema de servicio.

Monitorización del sistema de servicio.

Mantenimiento preventivo o reparación.

Capacitación en operaciones.

Gestión y resolución de incidencias.

Monitorización y tratamiento de la obsolescencia.

Actualización de los equipamientos y suministros que utilizan los equipos de servicio.

Soporte logístico.

Mantenimiento de las instalaciones

Retirada de sistemas

SP 1.4 Definir fases del ciclo de vida

Definir las fases del ciclo de vida en las cuales se encuadra la

labor de planificación.

Determinar las fases del ciclo de vida proporciona periodos planificados de

evaluación y de toma de decisiones. Estos periodos normalmente se

definen para dar soporte a los puntos lógicos de decisión, en los cuales se

determina la conveniencia de continuar confiando en el plan y la estrategia

y se realizan compromisos significativos en relación a los recursos. Tales

puntos proporcionan eventos planificados en los cuales se pueden realizar

correcciones y determinaciones sobre el alcance y el coste futuros.

Comprender el ciclo de vida es crucial para determinar el alcance de la

labor de planificación y los tiempos para planificar inicialmente, así como

los tiempos y criterios (hitos críticos) para la replanificar.



La selección de un ciclo de vida para desarrollar y proporcionar servicios

dependerá de las características de los servicios y sus entornos. Algunos

proveedores de servicio definirán fases en base a sus definiciones de

servicios estándar. Dependiendo de la naturaleza del servicio, se podrían

incluir fases explícitas para el arranque y el cierre.



A menudo, los servicios individuales tienen asociados ciclos de vida

implícitos que implican puntos de comunicación, evaluación, y decisión, y

que se deberían tener en cuenta para estimar qué se necesita para dar

soporte a tales servicios.


1. Fases del ciclo de vida.

SP 1.5 Estimar el esfuerzo y el coste

Estimar el esfuerzo y el coste de los productos de trabajo y las

tareas en base estimaciones justificadas.

Las estimaciones de esfuerzo y coste generalmente se basan en los

resultados de análisis de utilizar modelos o datos históricos aplicados al

tamaño, las actividades, y los otros parámetros de planificación. La

confianza en estas estimaciones está basada en la justificación del modelo

seleccionado y en la naturaleza de los datos. Pueden existir ocasiones en

las que los datos históricos disponibles no se puedan aplicar, tales como

cuando las labores no tengan precedentes o cuando el tipo de tarea no se

ajuste a los modelos disponibles. Por ejemplo, se puede considerar que

una labor no tiene precedentes si la organización no tiene experiencia con

ese tipo de producto o tarea.

Las labores sin precedentes tienen más riesgo, requieren más

investigación para desarrollar bases de estimación razonables, y requieren

más reservas de gestión. La singularidad del trabajo se documenta al

utilizar estos modelos con objeto de asegurar que todos los supuestos

realizados durante la planificación inicial se entienden de la misma forma.


1. Justificación de estimaciones.

2. Estimaciones de esfuerzo.

3. Estimaciones de costes.

Subprácticas

1. Recopilar los modelos o los datos históricos que se van a utilizar para

transformar los atributos de los productos de trabajo y de las tareas en

estimaciones de horas de trabajo y de costes.

Se han desarrollado muchos modelos paramétricos para ayudar a estimar el coste y

los plazos. No se recomienda el uso de estos modelos como fuente única de

estimación debido a que están basados en datos históricos de trabajos que podrían



no ser pertinentes para al trabajo que se planifica. Se pueden utilizar múltiples

modelos y métodos para asegurar que haya un alto nivel de confianza en la

estimación.

Los datos históricos deberían incluir datos sobre el coste, el esfuerzo, y los plazos de

los trabajos realizados previamente además de datos apropiados sobre la escala con

el fin de tener en cuenta los diferentes tamaños y complejidades.

2. Incluir las necesidades de infraestructura de soporte al estimar el

esfuerzo y el coste.

La infraestructura de soporte incluye los recursos que se necesitan desde el punto de

vista del desarrollo y mantenimiento del producto.

Al estimar el esfuerzo y el coste, hay que considerar las necesidades de recursos de

infraestructura para el entorno de desarrollo, el entorno de pruebas, el entorno de

producción, el entorno de operaciones, o cualquier otra combinación apropiada de

estos entornos.

Algunos ejemplos de recursos de infraestructura son:

Recursos de cómputo críticos.

Herramientas con las que equipar a los equipos de servicio.

Instalaciones, maquinaria, y equipamiento.

3. Estimar el esfuerzo y el coste utilizando modelos, datos históricos, o

una combinación de ambos.



Algunos ejemplos de información de entrada sobre esfuerzo y coste que se utiliza habitualmente para estimar son:

Estimaciones proporcionadas por un experto o grupo de expertos (p. ej. Método Delphi).

Riesgos, incluyendo el grado en el que la labor no tiene precedentes.

Competencias y roles críticos que se necesitan para realizar el trabajo.

Viajes.

EDT.

Selección de modelos de ciclo de vida del trabajo y procesos.

Estimaciones de costes del ciclo de vida.

Nivel de cualificación de los gerentes y el personal que se necesitan para realizar el trabajo.

Necesidades de conocimientos, habilidades, y capacitación.

Acuerdos de servicio para centros de atención al cliente y trabajos de garantía.

Costes directos de personal y costes generales.

Nivel de seguridad requerido para las tareas, los productos de trabajo, el hardware, el software, el personal, y el entorno de trabajo.

Instalaciones que se necesitan (p. ej. para desarrollar y mantener el sistema de servicio y para prestar los servicios).

Requisitos del servicio y del sistema de servicio.

Requisitos del producto y de los componentes de producto.

Estrategia de servicio.

Estimaciones de tamaño de los productos de trabajo, las tareas, y los cambios previstos.

Coste de los productos adquiridos externamente.

Capacidad de las herramientas proporcionadas.

Capacidad de los procesos de manufactura.

SG 2 Desarrollar un plan de trabajo

Se establece y se mantiene un plan de trabajo como base para gestionar el trabajo.

Un plan de trabajo es un documento formal y aprobado que se utiliza para

gestionar y controlar la ejecución del trabajo. Está basado en los requisitos

y en las estimaciones establecidas.

El plan de trabajo debería tener en cuenta todas las fases del ciclo de vida.

La planificación debería asegurar que todos los planes que afectan al

trabajo sean consistentes con el plan global del trabajo.

SP 2.1 Establecer el presupuesto y el cronograma

Establecer y mantener el presupuesto y el cronograma.

El presupuesto y el cronograma están basados en las estimaciones

desarrolladas y aseguran que la asignación del presupuesto, la



complejidad de las tareas, y las dependencias entre las mismas se abordan

de forma apropiada.

Los planes orientados a eventos con recursos limitados han demostrado

ser eficaces para afrontar los riesgos. Identificar los logros que se tienen

que demostrar antes de iniciar un evento permite proporcionar algo de

flexibilidad en la temporización del evento, entender de una misma forma

qué se espera, percibir mejor el estado del trabajo, y mayor precisión en los

estados de las tareas del trabajo.

Las subprácticas y ejemplos de productos de trabajo de esta práctica

específica se deberían interpretar tanto a nivel global del servicio como

dentro de cada tipo de servicio según sea apropiado. Esto es, las

peticiones individuales de servicio (p. ej. reparar una pieza de un equipo en

unas instalaciones remotas, transportar un paquete a un destino) pueden

tener hitos individuales, dependencias entre tareas, asignaciones de

recursos, y restricciones temporales que se deberían considerar de forma

conjunta y en coordinación con las actividades de preparación de

presupuestos y cronogramas de mayor nivel.


1. Cronogramas.

2. Dependencias temporales.

3. Presupuesto.

Subprácticas

1. Identificar los hitos principales.

Los hitos son eventos o puntos en el tiempo pre-planificados en los cuales se realiza

una revisión en profundidad del estado con el fin de conocer el grado de cumplimiento

de los requisitos de las partes interesadas (si el trabajo incluye un hito de desarrollo,

entonces la revisión se realiza para asegurar que se cumplen los supuestos y los

requisitos asociados con ese hito). Los hitos se pueden asociar con el servicio global

o con un tipo o instancia de servicio concreta. Los hitos pueden, por tanto, estar

basados en eventos o en el calendario. Si están basados en el calendario, a menudo

es difícil cambiar las fechas una vez que éstas se han acordado.

2. Identificar los supuestos temporales.

Cuando los cronogramas se desarrollan inicialmente, es común hacer supuestos

sobre la duración de ciertas actividades. Estos supuestos se hacen frecuentemente

sobre elementos para los que hay pocos datos de estimación disponibles. Identificar

estos supuestos permite discernir el nivel de confianza (esto es, incertidumbre) en el

cronograma global.

3. Identificar las restricciones.

Se deberían identificar tan pronto como sea posible los factores que limitan la

flexibilidad de las opciones que hay para gestionar. El examen de los atributos de los

productos de trabajo y de las tareas a menudo hace aflorar a la superficie estos

problemas. Estos atributos pueden incluir la duración de la tarea, los recursos, las

entradas, y las salidas.



4. Identificar las dependencias entre las tareas.

Con frecuencia, las tareas de un proyecto o un servicio se pueden ejecutar siguiendo

una secuencia ordenada que minimiza la duración. Esta secuenciación implica que se

identifiquen las tareas predecesoras y sucesoras con el fin de determinar la

ordenación óptima.

Algunos ejemplos de herramientas y entradas que pueden ayudar a determinar el orden óptimo de las tareas son:

Método del Camino Crítico (CPM).

Técnica de Evaluación y Revisión del Programa (PERT).

Planificación por limitación de recursos.

Prioridades del cliente.

Valor para el usuario.

5. Establecer y mantener el presupuesto y el cronograma.

Establecer y mantener el presupuesto y el cronograma habitualmente incluye:

Definir la disponibilidad comprometida o esperada de los recursos e instalaciones.

Establecer la distribución temporal de las actividades.

Establecer una descomposición de los cronogramas subordinados.

Definir las dependencias entre las actividades (relaciones de precedencia o sucesión).

Definir el cronograma de las actividades y los hitos para dar soporte a que se monitorice y controle el trabajo.

Identificar los hitos, las entregas, o las entregas incrementales de productos al cliente.

Definir actividades de una duración apropiada.

Definir hitos separados temporalmente de forma apropiada.

Definir una reserva de gestión en base al nivel de confianza en que se cumpla el cronograma y el presupuesto.

Utilizar los datos históricos apropiados para verificar el cronograma.

Definir los requisitos de incrementos de financiación.

Documentar los supuestos y las justificaciones.

6. Establecer criterios para las acciones correctivas.

Se establecen criterios para determinar qué constituye una desviación significativa

con respecto al plan. Se necesita una base para calibrar cuándo se deberían llevar a

cabo acciones correctivas para los problemas y los asuntos. Las acciones correctivas

pueden conducir a que se replanifique, lo cual puede significar que se revise el plan

original, que se establezcan nuevos acuerdos, o que se incluyan actividades de

mitigación en el plan actual. El plan de trabajo define cuándo (p. ej., bajo qué

circunstancias, con qué frecuencia) y por quién serán aplicados los criterios.




Identificar y analizar los riesgos.

Para más información sobre identificar problemas potenciales antes de que

ocurran de forma que se puedan planificar e invocar actividades de manejo

de riesgos según se necesite durante la vida del producto o trabajo a fin de

mitigar los impactos adversos sobre el logro de objetivos, consúltese el


Para más información sobre las actividades de monitorización de riesgos,

consúltese la práctica específica Monitorizar riesgos en el área de proceso

Monitorización y Control de Trabajos.

Los riesgos se identifican o descubren y se analizan para dar soporte a la

planificación del trabajo. Esta práctica específica se debería extender a

todos los planes que afecten al trabajo con el fin de asegurar que todas las

partes interesadas relevantes están interactuando de forma apropiada

sobre los riesgos identificados.

Habitualmente la identificación y análisis de riesgos en la planificación de trabajos incluye:

Identificar los riesgos.

Analizar los riesgos para determinar el impacto, la probabilidad de ocurrencia, y el

marco temporal en el que es probable que ocurran los problemas.

Priorizar los riesgos.


1. Riesgos identificados.

2. Impacto y probabilidad de ocurrencia de los riesgos.

3. Prioridad de los riesgos.

Subprácticas

1. Identificar los riesgos.

La identificación de riesgos implica identificar los potenciales problemas, peligros,

amenazas, vulnerabilidades, etc. que podrían afectar negativamente a las tareas y a

los planes. Los riesgos se deberían identificar y describir de forma comprensible antes

de poder analizarlos y gestionarlos apropiadamente. Cuando se identifican riesgos, es

una buena idea utilizar un método estándar para definirlos. Se pueden utilizar

herramientas de identificación y de análisis de riesgos para ayudar a identificar

posibles problemas.



Algunos ejemplos de herramientas para identificar y analizar riesgos son:

Taxonomías de riesgos.

Evaluaciones de riesgos.

Listas de comprobación.

Entrevistas estructuradas.

Tormentas de ideas.

Modelos de rendimiento de procesos, productos, y trabajos.

Modelos de costes.

Análisis de red.

Análisis de factor de calidad.

2. Documentar los riesgos.

3. Revisar y obtener acuerdos con las partes interesadas relevantes

acerca de la completitud y corrección de los riesgos documentados.

4. Actualizar los riesgos según sea apropiado.

Algunos ejemplos de cuándo puede ser necesario actualizar los riesgos identificados son:

Cuando se identifican nuevos riesgos.

Cuando los riesgos se convierten en problemas.

Cuando los riesgos desaparecen.

Cuando las circunstancias del trabajo cambian significativamente.

SP 2.3 Planificar la gestión de datos

Planificar la gestión de los datos

Los datos son formas de documentar que se requieren para dar soporte al

trabajo en todas sus áreas (p. ej. administración, ingeniería, gestión de

configuración, financiación, logística, calidad, seguridad, fabricación,

adquisición). Los datos pueden tomar cualquier forma (p. ej. informes,

manuales, libretas, gráficas, dibujos, especificaciones, ficheros,

correspondencia). Los datos pueden existir en cualquier medio (p. ej.

impresos o dibujados sobre distintos materiales, fotografías, electrónico,

multimedia).

Los datos pueden ser entregables (p. ej. elementos identificados en los

requisitos de datos del contrato) o no entregables (p. ej., datos informales,

estudios de contraprestaciones, análisis, actas de reuniones internas,

documentación de la revisión interna de los diseños, lecciones aprendidas,

acciones). La distribución puede tomar muchas formas, incluyendo la

transmisión electrónica.

Se deberían establecer requisitos de datos para el trabajo en base a un

conjunto común o estándar de requisitos de datos tanto para los elementos

de datos que se van a crear como para el contenido y la forma de estos.

Los requisitos de uniformidad de contenido y de formato de los elementos



de datos facilitan que se comprenda su contenido y ayudan a gestionar de

forma consistente los recursos de datos.

Debería estar clara la razón para recoger cada documento. Esta tarea

incluye analizar y verificar los entregables y los no entregables, los

requisitos de datos, y los datos suministrados por el cliente. A menudo, los

datos se recogen sin comprender claramente cómo se van a utilizar. Los

datos son costosos y se deberían recoger únicamente si se necesitan.


1. Plan para la gestión de datos.

2. Lista maestra de datos gestionados.

3. Descripción del contenido y formato de los datos.

4. Lista de requisitos de datos para adquirientes y suministradores.

5. Requisitos de privacidad.

6. Requisitos de seguridad.

7. Procedimientos de seguridad.

8. Mecanismos de recuperación, reproducción, y distribución de datos.

9. Cronograma para la recogida de datos.

10. Lista de datos a recoger.

Subprácticas

1. Establecer requisitos y procedimientos para asegurar la privacidad y la

seguridad de los datos.

No todo el mundo tendrá la necesidad de acceder a los datos o la acreditación

necesaria para hacerlo. Se deberían establecer procedimientos para identificar quién

tiene acceso a qué datos, así como cuándo se puede acceder a qué datos.

Los requisitos y procedimientos pueden incluir al personal de servicio, que tendrá la

responsabilidad de la seguridad de los datos cumpliendo los términos de un acuerdo

de servicio.

2. Establecer un mecanismo para almacenar los datos y acceder a los

datos almacenados.

La información a la que se accede debería tener una forma comprensible (p. ej. el

resultado electrónico o en pantalla de un acceso a una base de datos) o estar

representada de la misma forma en que fue generada originalmente.

3. Determinar los datos que serán identificados, recogidos, y distribuidos.

4. Determinar los requisitos para proporcionar acceso a los datos a las

partes interesadas relevantes y para distribuírselos.

Revisar otros elementos del plan de trabajo puede ayudar a determinar quién requiere

acceso a los datos o requiere recibirlos así como qué datos están implicados.



5. Decidir qué datos y planes requieren control de versiones u otros

niveles de control de configuración y establecer mecanismos para

asegurar que los datos se controlan.

SP 2.4 Planificar los recursos

Planificar los recursos para realizar el trabajo.

La definición de los recursos (p. ej., esfuerzo, equipamiento, materiales,

métodos) y las cantidades que se necesitan para realizar los trabajos está

basada en las estimaciones iniciales y proporciona información adicional

que se puede aplicar para expandir la EDT que se utiliza para gestionar el

trabajo.

La EDT de alto nivel, desarrollada en etapas tempranas como un

mecanismo de estimación, habitualmente se expande descomponiendo

estos niveles más altos en paquetes de trabajo que representan unidades

de trabajo autónomas que se pueden asignar, realizar, y seguir por

separado. Se hace esta subdivisión para distribuir la responsabilidad de

gestionar y proporcionar mayor control a la gestión.

Cada paquete de trabajo en la EDT debería tener asignado un identificador

único (p. ej., un número) para permitir que se siga. Una EDT puede estar

basada en los requisitos, las actividades, los productos de trabajo, los

servicios, o en una combinación de estos elementos. La EDT debería ir

acompañada de un diccionario que describa el trabajo para cada paquete

de trabajo en la estructura de descomposición del trabajo.


1. Paquetes de trabajo.

2. Diccionario de tareas de la EDT.

3. Requisitos de personal basados en el tamaño y el alcance del trabajo.

4. Lista de instalaciones y equipamiento que son críticos.

5. Definiciones y diagramas de procesos y flujos de trabajo.

6. Lista de requisitos de administración del trabajo.

7. Informes de situación.

Subprácticas

1. Determinar los requisitos de procesos.

Los procesos utilizados para gestionar el trabajo se identifican, definen, y coordinan

con todas las partes interesadas relevantes con el fin de asegurar que durante la

ejecución del trabajo las operaciones serán eficientes.

2. Determinar los requisitos de comunicación.

Estos requisitos abordan los tipos de mecanismos a utilizar para comunicarse con los

clientes, los usuarios finales, el personal del proveedor de servicios, y con las otras




Los mecanismos de comunicación se pueden crear durante el desarrollo del sistema

de servicio y regularmente se deberían revisar, adaptar, y posiblemente complementar

para cubrir las necesidades de la prestación de servicios en curso.

Extensión SSD



3. Determinar los requisitos de personal.

El personal de un trabajo depende de la descomposición de los requisitos en tareas,

roles, y responsabilidades para acometer los requisitos según lo que está dispuesto

en los paquetes de trabajo de la EDT.

Los requisitos de personal deberían considerar los conocimientos y habilidades que

se requieren para cada puesto identificado según se define en la práctica específica

Planificar los conocimientos y las habilidades que se necesitan.





4. Determinar los requisitos de instalaciones, equipamiento, y

componentes.

La mayoría de los grupos de trabajo son únicos en algún aspecto y requieren un

conjunto de activos únicos para lograr los objetivos del trabajo. Determinar y adquirir

estos activos de manera oportuna es crucial para el éxito del trabajo.

Es mejor identificar lo antes posible los elementos que tienen plazos de entrega a fin

de determinar el modo en que se abordarán estos plazos. Incluso cuando los activos

requeridos no son únicos, recopilar una lista de instalaciones, equipamiento, y piezas

(p. ej., número de ordenadores para el personal que trabaja en el grupo de trabajo,

aplicaciones de software, espacio de oficina) proporciona una visión más profunda

sobre algunos aspectos del alcance de una labor que a menudo se pasan por alto.

5. Determinar otros requisitos de recursos continuos.

Más allá de determinar los procesos, las plantillas de informe, el personal, las

instalaciones, y el equipamiento, puede que exista una necesidad continua de otros

tipos de recursos para que los trabajos se lleven a cabo de forma eficaz, incluyendo:

Consumibles (p. ej., electricidad, material de oficina).

Acceso a la propiedad intelectual.

Acceso al transporte (para las personas y el equipamiento).

Los requisitos para tales recursos se derivan de los requisitos (existentes y futuros)

establecidos en los acuerdos (p. ej., acuerdos con el cliente, acuerdos de servicio,

acuerdos de suministro), el enfoque estratégico, y la necesidad de gestionar y

mantener las operaciones durante un período de tiempo.



SP 2.5 Planificar los conocimientos y las habilidades que se necesitan

Planificar los conocimientos y las habilidades que se necesitan

para realizar el trabajo.

Para más información sobre desarrollar las habilidades y conocimientos de

las personas de modo que puedan realizar sus roles eficaz y

eficientemente, consúltese el área de proceso Capacitación Organizativa.

Proporcionar conocimientos a los grupos de trabajo implica capacitar al

personal y adquirir conocimientos de fuentes externas.

Los requisitos de personal dependen de los conocimientos y habilidades

disponibles para dar soporte a la ejecución del trabajo.

Planificar la capacitación aborda los conocimientos y habilidades que los

grupos de trabajo y el personal de soporte requieren para realizar sus

tareas. Las necesidades de conocimientos y habilidades pueden provenir

de los riesgos identificados.

Por ejemplo, si el grupo de trabajo está prestando un servicio para cuyo éxito hace falta que

se esté familiarizado en detalle con un equipo complejo, la planificación de la capacitación

asegura que el personal asignado tenga la experiencia apropiada con dicho equipo o

provee al grupo de trabajo capacitación en esas áreas.

La capacitación también puede incluir la orientación sobre los procesos del

grupo de trabajo y los conocimientos sobre el dominio que son necesarios

para hacer el trabajo. El grupo de trabajo también puede identificar y

planificar los conocimientos y las habilidades que necesitan sus

suministradores. Planificar incluye asegurar que las fuentes de costes y de

financiación estén disponibles para el pago de la capacitación, y que los

tiempos de entrega para obtener la financiación y la capacitación sean

suficientes.

En el caso de servicios de larga duración y de operación continua, los

conocimientos y habilidades que se necesitan evolucionarán a medida que:

Los miembros del personal roten entrando y saliendo del grupo de

trabajo (o desde un tipo de servicio a otro).

Cambie la tecnología utilizada en el sistema de servicio o en un servicio

concreto.

Cambien los procesos y la tecnología utilizados en los entornos de

desarrollo o del cliente.

Por ejemplo, un cambio de personal crea la necesidad de determinar los conocimientos y

habilidades que necesitan los nuevos miembros del grupo de trabajo. Se necesitan nuevos

conocimientos y habilidades durante las diferentes fases del ciclo de vida del servicio (o a

medida que se añaden nuevos servicios o niveles de servicio). La planificación de las

habilidades y conocimientos que se necesitan debería abordar estas fuentes de cambio.

Para más información sobre preparar la transición del sistema de servicio y

preparar a las partes interesadas para los cambios, consúltese el área de





1. Inventario de necesidades de habilidades.

2. Planes de personal y de nuevas contrataciones.

3. Bases de datos (p. ej., habilidades, capacitación).

4. Planes de capacitación.

Subprácticas

1. Identificar los conocimientos y las habilidades que se necesitan para

realizar el trabajo.

2. Evaluar los conocimientos y las habilidades disponibles.

3. Seleccionar mecanismos para proporcionar los conocimientos y las

habilidades que se necesitan.

Algunos ejemplos de mecanismos son:

Capacitación interna (tanto organizativa como del grupo de trabajo)

Capacitación externa.

Asignaciones de personal y nuevas contrataciones.

Adquisición externa de habilidades.

La opción entre capacitar internamente y externalizar la capacitación de los

conocimientos y habilidades que se necesitan viene determinada por la disponibilidad

de experiencia en capacitación, el cronograma del trabajo, y los objetivos de negocio.

4. Incorporar los mecanismos seleccionados en el plan de trabajo.

SP 2.6 Planificar la involucración de las partes interesadas

Planificar la involucración de las partes interesadas identificadas.

Las partes interesadas se identifican en todas las fases del ciclo de vida del

trabajo por medio de identificar a las personas y las funciones que deberían

estar representadas en el trabajo y describir su importancia y su grado de

interacción con las actividades del trabajo. Un formato conveniente para

lograr esta identificación es una matriz bidimensional que tiene partes

interesadas en un eje y actividades en el otro. La relevancia de cada parte

interesada con cada actividad en una fase concreta y la cantidad de

interacción que se espera se debería mostrar en la intersección del eje de

las actividades de la fase y el eje de las partes interesadas.

Para que la información de entrada de las partes interesadas sea útil, es

necesario que éstas se seleccionen cuidadosamente. Para cada actividad

principal, identificar a las partes interesadas que estén afectadas y a

quienes tengan la experiencia que se necesita para llevarla a cabo. Esta

lista de partes interesadas relevantes probablemente cambiará a medida

que el trabajo avanza durante las fases del ciclo de vida del trabajo. Sin

embargo, es importante asegurar que las partes interesadas relevantes en

las fases posteriores del ciclo de vida tienen la información de entrada

sobre los requisitos y las decisiones de diseño que les afectan lo más

pronto posible.





Algunos ejemplos de tipos de contenidos que se deberían incluir en un plan de interacción

con las partes interesadas son:

Lista de todos las partes interesadas relevantes.

Justificación de la involucración de las partes interesadas.

Relaciones entre las partes interesadas.

Recursos (p. ej. capacitación, materiales, tiempo, financiación) que se necesitan para

asegurar la interacción entre las partes interesadas.

Cronogramas para las fases de interacción de las partes interesadas.

Por cada fase del ciclo de vida, roles y responsabilidades de las partes interesadas

relevantes con respecto al trabajo.

Por cada fase del ciclo de vida, importancia relativa para el éxito del trabajo de cada

parte interesada.

La implementación de esta práctica específica se basa en compartir o

intercambiar información con la práctica específica previa de Planificar los

conocimientos y las habilidades que se necesitan.


1. Plan de involucración de las partes interesadas.

SP 2.7 Establecer el plan de trabajo

Establecer y mantener el plan global del trabajo.

Se necesita un plan documentado que abarque todos los elementos

relevantes de la planificación para conseguir el mutuo entendimiento y el

compromiso de los individuos, los grupos, y las organizaciones que

ejecutan o dan soporte a los planes.

El plan generado para el trabajo define todos los aspectos de la labor,

uniendo lo siguiente de manera lógica:

Consideraciones sobre el ciclo de vida del trabajo.

Tareas.

Presupuestos y cronogramas.

Hitos.

Gestión de datos.

Identificación de riesgos.

Necesidades de recursos y habilidades.

Identificación e interacción con las partes interesadas.

Consideraciones sobre infraestructura.

Las consideraciones sobre infraestructura incluyen las relaciones de

responsabilidad y de autoridad entre los miembros del grupo de trabajo, la

gerencia, y las organizaciones de soporte.




1. Plan global del trabajo.

Subprácticas

1. Documentar el plan de trabajo.

Los grupos de trabajo pueden estar formados por otros grupos de trabajo de menor

nivel. Un servicio puede estar formado por un grupo de trabajo que desarrolle el

sistema de servicio y un grupo de trabajo que preste el servicio. La prestación de

servicios puede componerse de varios servicios que se podrían beneficiar de

planificarlos por separado y de las prácticas de esta área de proceso. Cuando se

forman grupos de trabajo a partir de otros grupos, el plan global del trabajo debería

hacer referencia a los planes de los grupos de trabajo de menor nivel, y todos los

planes de trabajo relacionados deberían ser compatibles entre sí y darse mutuamente

el soporte apropiado.

2. Incluir, referenciar, y conciliar los resultados de las actividades de

planificación según sea apropiado.

Para conseguir el soporte de las partes interesadas relevantes, el plan de trabajo

debería documentar un enfoque realista y sensato para cubrir sus necesidades,

expectativas, y restricciones. Tal plan requiere que varios elementos de planificación

sean razonablemente completos y consistentes (al menos hasta la siguiente revisión

del plan, que podría ser semanas o meses más adelante).

Si se implementan de forma apropiada, las prácticas específicas de esta área de

proceso abordan la práctica genérica Planificar el proceso según se aplica a otras

áreas de proceso dentro del alcance de la labor de mejora de procesos, pero en caso

contrario los resultados de implementar dicha práctica genérica también se deberían

tener en cuenta en esta subpráctica.

3. Revisar el plan de trabajo con las partes interesadas relevantes y

obtener su aprobación.

Las prácticas específicas de la siguiente meta, Obtener el compromiso con el plan,

describen las actividades que ayudan a asegurar que el plan de trabajo describe un

enfoque realista para cubrir las necesidades, las expectativas, y las restricciones de

las partes interesadas relevantes y que ayudan a asegurar que dichas partes

interesadas relevantes satisfarán sus roles según está descrito en el plan de trabajo,

incluyendo la provisión de recursos y otras formas de soporte durante la ejecución del

trabajo.

4. Actualizar el plan de trabajo según se necesite.

Generalmente, cuando se revisa el plan puede que sea necesario repetir muchas de

las actividades de planificación descritas en esta área de proceso con el fin de ayudar

a asegurar que se mantienen los compromisos de las partes interesadas relevantes

con el plan.

SG 3 Obtener el compromiso con el plan

Se establecen y se mantienen los compromisos con el plan de trabajo.

Para ser eficaces, los planes requieren el compromiso de quienes sean

responsables de implementar y dar soporte al plan.



SP 3.1 Revisar los planes que afecten al trabajo

Revisar todos los planes que afecten al trabajo para comprender

los compromisos.

Los planes desarrollados en otras áreas de proceso habitualmente

contienen información similar a la referenciada en el plan global del trabajo.

Estos planes pueden proporcionar una orientación detallada adicional y

deberían ser compatibles con el plan global del trabajo y darle soporte para

indicar quién tiene la autoridad, quién es responsable, quién tiene que

rendir cuentas, y quién tiene el control. Se deberían revisar todos los

planes que afecten al trabajo para asegurar que todos entienden de la

misma forma el alcance, los objetivos, los roles, y las relaciones que se

requieren para que el trabajo tenga éxito. Muchos de estos planes se

describen en la práctica genérica Planificar el proceso.


1. Registro de las revisiones de los planes que afectan al trabajo.

SP 3.2 Conciliar los niveles de trabajo y de recursos

Ajustar el plan de trabajo para conciliar los recursos disponibles y

los estimados.

Para establecer un trabajo que sea factible, es necesario obtener el

compromiso de las partes interesadas relevantes y conciliar las diferencias

entre los recursos estimados y los disponibles. Habitualmente se logra la

conciliación modificando o aplazando los requisitos, negociando más

recursos, encontrando formas de incrementar la productividad,

externalizando, ajustando la mezcla de habilidades del personal, o

revisando todos los planes que afecten al trabajo o sus cronogramas.


1. Métodos y parámetros de estimación correspondientes actualizados

(p. ej. mejores herramientas, el uso de productos comerciales).

2. Presupuestos renegociados.

3. Cronogramas actualizados.

4. Lista de requisitos actualizada.

5. Acuerdos con las partes interesadas renegociados.

SP 3.3 Obtener el compromiso con el plan

Obtener el compromiso de las partes interesadas relevantes

responsables de realizar el plan y dar soporte a su ejecución.

Obtener el compromiso implica la interacción entre todas las partes

interesadas relevantes, tanto internas como externas al grupo de trabajo. El

individuo o grupo que adquiere un compromiso debería tener la certeza de

que el trabajo se puede realizar dentro de las restricciones de coste,

plazos, y rendimiento. A menudo, resulta adecuado adquirir un compromiso

provisional para poder empezar una labor y permitir que se realice una



investigación que aumente la certeza hasta un nivel apropiado que permita

adquirir un compromiso definitivo.


1. Peticiones de compromiso documentadas.

2. Compromisos documentados.

Subprácticas

1. Identificar el soporte que se necesita y negociar los compromisos con


Se puede utilizar la EDT como una lista de comprobación para asegurar que se

obtienen los compromisos para todas las tareas.

El plan de interacción con las partes interesadas debería identificar a todas las partes

que deberían comprometerse.

2. Documentar todos los compromisos organizativos, tanto definitivos

como provisionales, asegurando el nivel apropiado de firmantes.

Los compromisos se deberían documentar para asegurar un entendimiento mutuo

consistente y para el seguir y mantener el trabajo. Los compromisos provisionales se

deberían acompañar de una descripción de los riesgos asociados con la relación.

3. Revisar los compromisos internos con la dirección según sea

apropiado.

4. Revisar los compromisos externos con la dirección según sea

apropiado.

La dirección puede tener la visión y la autoridad que se necesitan para reducir los

riesgos asociados a los compromisos externos.

5. Identificar los compromisos relacionados con las interfaces entre los

elementos del trabajo y otros grupos de trabajo y unidades

organizativas, de tal forma que estos compromisos se puedan

monitorizar.

Las especificaciones de interfaces bien definidas son la base para los compromisos.


Referencias 481

Tercera Parte:

Apéndices


Referencias 482

Apéndice A: Referencias

Ahern 2005 Ahern, Dennis M.; Armstrong, Jim; Clouse, Aaron; Ferguson,

Jack R.; Hayes, Will; & Nidiffer, Kenneth E. CMMI SCAMPI

Distilled: Appraisals for Process Improvement. Boston, MA:

Addison-Wesley, 2005.

Ahern 2008 Ahern, Dennis M.; Clouse, Aaron; & Turner, Richard. CMMI

Distilled: A Practical Introduction to Integrated Process

Improvement, 3rd

Edition. Boston: Addison-Wesley, 2008.

Beck 2001 Beck, Kent et. al. Manifesto for Agile Software Development.

2001. http://agilemanifesto.org/.

Chrissis 2011 Chrissis, Mary Beth; Konrad, Mike; & Shrum, Sandy. CMMI:

Guidelines for Process Integration and Product Improvement,

3rd

Edition. Boston: Addison-Wesley, 2011.

Crosby 1979 Crosby, Philip B. Quality Is Free: The Art of Making Quality

Certain. New York: McGraw-Hill, 1979.

Curtis 2009 Curtis, Bill; Hefley, William E.; & Miller, Sally A. The People

CMM: A Framework for Human Capital Management, 2nd

Edition. Boston, MA: Addison-Wesley, 2009.

Deming 1986 Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT

Press, 1986.

EIA 2002a Electronic Industries Alliance. Systems Engineering Capability

Model (EIA/IS-731.1). Washington, DC, 2002.

EIA 2002b Government Electronics and Information Technology Alliance.

Earned Value Management Systems (ANSI/EIA-748). New

York, NY, 2002.

http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FEIA-

748-B.

EIA 2003 Electronic Industries Alliance. EIA Interim Standard: Systems

Engineering (EIA/IS-632). Washington, DC, 2003.

Forrester 2011 Forrester, Eileen; Buteau, Brandon; & Shrum, Sandy. CMMI for

Services: Guidelines for Superior Service, 2nd

Edition. Boston:



Referencias 483

Gallagher 2011 Gallagher, Brian; Phillips, Mike; Richter, Karen; & Shrum,

Sandy. CMMI-ACQ: Guidelines for Improving the Acquisition of

Products and Services, 2nd

Edition. Boston: Addison-Wesley,

2011.

GEIA 2004 Government Electronic Industries Alliance. Data Management

(GEIA-859). Washington, DC, 2004.

http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FGEI

A+859-2009.

Gibson 2006 Gibson, Diane L.; Goldenson, Dennis R.; & Kost, Keith.

Performance Results of CMMI-Based Process Improvement

(CMU/SEI-2006-TR-004, ADA454687). Pittsburgh, PA:

Software Engineering Institute, Carnegie Mellon® University,

August 2006.

http://www.sei.cmu.edu/library/abstracts/reports/06tr004.cfm.

Glazer 2008 Glazer, Hillel; Dalton, Jeff; Anderson, David; Konrad, Mike; &

Shrum, Sandy. CMMI or Agile: Why Not Embrace Both!

(CMU/SEI-2008-TN-003). Pittsburgh, PA: Software

Engineering Institute, Carnegie Mellon University, November

2008.

http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm.

Humphrey 1989 Humphrey, Watts S. Managing the Software Process. Boston,

MA: Addison-Wesley, 1989.

IEEE 1991 Institute of Electrical and Electronics Engineers. IEEE Standard

Computer Dictionary: A Compilation of IEEE Standard

Computer Glossaries. New York, NY: IEEE, 1991.

ISO 2005a International Organization for Standardization. ISO 9000:

International Standard. 1987.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_d

etail.htm?csnumber=42180.

ISO 2005b International Organization for Standardization and International

Electrotechnical Commission. ISO/IEC 20000-1 Information

Technology – Service Management, Part 1: Specification;

ISO/IEC 20000-2 Information Technology – Service

Management, Part 2: Code of Practice, 2005.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc

_browse.htm?commid=45086.


Referencias 484

ISO 2006a International Organization for Standardization and International

Electrotechnical Commission. ISO/IEC 15504 Information

Technology—Process Assessment Part 1: Concepts and

Vocabulary, Part 2: Performing an Assessment, Part 3:

Guidance on Performing an Assessment, Part 4: Guidance on

Use for Process Improvement and Process Capability

Determination, Part 5: An Exemplar Process Assessment

Model, 2003-2006.




Electrotechnical Commission. ISO/IEC 14764 Software

Engineering – Software Life Cycle Processes – Maintenance,

2006.



ISO 2007 International Organization for Standardization and International

Electrotechnical Commission. ISO/IEC 15939 Systems and

Software Engineering—Measurement Process, 2007.



ISO 2008a International Organization for Standardization and International


Software Engineering—Software Life Cycle Processes, 2008.





Software Engineering—System Life Cycle Processes, 2008.



ISO 2008c International Organization for Standardization. ISO 9001,

Quality Management Systems—Requirements, 2008.



IT Governance 2005 IT Governance Institute. CobiT 4.0. Rolling Meadows, IL: IT

Governance Institute, 2005.

http://www.isaca.org/Content/NavigationMenu/Members_and_

Leaders/COBIT6/Obtain_COBIT/Obtain_COBIT.htm.

Juran 1988 Juran, Joseph M. Juran on Planning for Quality. New York:

Macmillan, 1988.


Referencias 485

McFeeley 1996 McFeeley, Robert. IDEAL: A User’s Guide for Software

Process Improvement (CMU/SEI-96-HB-001, ADA305472).

Pittsburgh, PA: Software Engineering Institute, Carnegie

Mellon University, February 1996.


McGarry 2001 McGarry, John; Card, David; Jones, Cheryl; Layman, Beth;

Clark, Elizabeth; Dean, Joseph; & Hall, Fred. Practical

Software Measurement: Objective Information for Decision

Makers. Boston: Addison-Wesley, 2001.

Office of Government Commerce 2007a

Office of Government Commerce. ITIL: Continual Service

Improvement. London, UK: Office of Government Commerce,

2007.

Office of Government Commerce 2007b

Office of Government Commerce. ITIL: Service Design.

London, UK: Office of Government Commerce, 2007.

Office of Government Commerce 2007c

Office of Government Commerce. ITIL: Service Operation.


Office of Government Commerce 2007d

Office of Government Commerce. ITIL: Service Strategy.


Office of Government Commerce 2007e

Office of Government Commerce. ITIL: Service Transition.


SEI 1995 Software Engineering Institute. The Capability Maturity Model:

Guidelines for Improving the Software Process. Reading, MA:


SEI 2002 Software Engineering Institute. Software Acquisition Capability

Maturity Model (SA-CMM) Version 1.03 (CMU/SEI-2002-TR-

010, ADA399794). Pittsburgh, PA: Software Engineering

Institute, Carnegie Mellon University, March 2002.


SEI 2010a CMMI Product Team. CMMI for Development, Version 1.3

(CMU/SEI-2010-TR-033). Pittsburgh, PA: Software


2010.


SEI 2010b CMMI Product Team. CMMI for Acquisition, Version 1.3



2010.



Referencias 486

SEI 2010c Caralli, Richard; Allen, Julia; Curtis, Pamela; White, David; and

Young, Lisa. CERT® Resilience Management Model, Version

1.0 (CMU/SEI-2010-TR-012). Pittsburgh, PA: Software

Engineering Institute, Carnegie Mellon University, May 2010.


SEI 2011a SCAMPI Upgrade Team. Standard CMMI Appraisal Method for

Process Improvement (SCAMPI) A, Version 1.3: Method

Definition Document (CMU/SEI-2011-HB-001). Pittsburgh, PA:

Software Engineering Institute, Carnegie Mellon University,

expected January 2011.


SEI 2011b SCAMPI Upgrade Team. Appraisal Requirements for CMMI,

Version 1.2 (ARC, V1.3) (CMU/SEI-2011-TR-001). Pittsburgh,

PA: Software Engineering Institute, Carnegie Mellon University,

expected January 2011.


SEI 2009 CMMI Product Team. CMMI for Services, Version 1.2


Engineering Institute, Carnegie Mellon University, February

2009.


Shewhart 1931 Shewhart, Walter A. Economic Control of Quality of

Manufactured Product. New York: Van Nostrand, 1931.

Fuentes relacionadas con Aseguramiento/Seguridad de la Información

DHS 2009 Department of Homeland Security. Assurance Focus for

CMMI (Summary of Assurance for CMMI Efforts), 2009.

https://buildsecurityin.us-cert.gov/swa/proself_assm.html.

DoD and DHS 2008 Department of Defense and Department of Homeland

Security. Software Assurance in Acquisition: Mitigating

Risks to the Enterprise, 2008. https://buildsecurityin.us-

cert.gov/swa/downloads/SwA_in_Acquisition_102208.pdf.

ISO/IEC 2005 International Organization for Standardization and

International Electrotechnical Commission. ISO/IEC 27001

Information Technology – Security Techniques – Information

Security Management Systems – Requirements, 2005.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue

_detail.htm?csnumber= 42103.


Referencias 487

NDIA 2008 NDIA System Assurance Committee. Engineering for System Assurance. Arlington,

VA: NDIA, 2008.

http://www.ndia.org/Divisions/Divisions/SystemsEngineering

/Documents/Studies/SA-Guidebook-v1-Oct2008-REV.pdf.


Acrónimos 488

Apéndice B: Acrónimos

ANSI American National Standards Institute (Instituto Americano

de Estándares Nacionales)

ARC Appraisal Requirements for CMMI (Requisitos de

Evaluación para CMMI)

CAM Capacity and Availability Management (área de proceso

Gestión de Capacidad y Disponibilidad)

CAR Causal Analysis and Resolution (área de proceso Análisis

Causal y Resolución)

CCB configuration control board (comité de control de

configuración)

CL capability level (nivel de capacidad)

CM Configuration Management (área de proceso Gestión de

Configuración)

CMF CMMI Model Foundation (Bases del Modelo CMMI)

CMM Capability Maturity Model (Modelo de Capacidad y

Madurez)

CMMI Capability Maturity Model Integration (Integración de

Modelos de Capacidad y Madurez)

CMMI-ACQ CMMI for Acquisition (CMMI para Adquisiciones)

CMMI-DEV CMMI for Development (CMMI para Desarrollo)

CMMI-SVC CMMI for Services (CMMI para Servicios)

CMU Carnegie Mellon University (Universidad Carnegie Mellon)

CobiT Control Objectives for Information and related Technology

(objetivos de control para la información y tecnologías

relacionadas)

COTS commercial off-the-shelf (componente comercial)


Acrónimos 489

CPI cost performance index (índice de rendimiento en costes)

CPM critical path method (método del camino crítico)

DAR Decision Analysis and Resolution (área de proceso Análisis

de Decisiones y Resolución)

DHS Department of Homeland Security (Departamento de

Seguridad de la Patria)

DoD Department of Defense (Departamento de Defensa)

EIA Electronic Industries Alliance (Alianza de Industrias

Electrónicas)

EIA/IS Electronic Industries Alliance/Interim Standard (Alianza de

Industrias Electrónicas/Estándar Provisional)

FAQ frequently asked question (preguntas más frecuentes)

FCA functional configuration audit (auditoría de configuración

funcional)

FMEA failure mode and effects analysis (análisis de modos y

efectos de fallos)

GG generic goal (meta genérica)

GP generic practice (práctica genérica)

IBM International Business Machines

IDEAL Initiating, Diagnosing, Establishing, Acting, Learning (Iniciar,

Diagnosticar, Establecer, Actuar, Aprender)

IEC International Electrotechnical Commission (Comisión

Electrotécnica Internacional)

IEEE Institute of Electrical and Electronics Engineers (Instituto de

Ingenieros Eléctricos y Electrónicos)

INCOSE International Council on Systems Engineering (Consejo

Internacional sobre Ingeniería de Sistemas)

IPD-CMM Integrated Product Development Capability Maturity Model

(Modelo de Capacidad y Madurez - Gestión Integrada de

Productos)

IRP Incident Resolution and Prevention (área de proceso

Resolución y Prevención de Incidencias)


Acrónimos 490

ISO International Organization for Standardization (Organización

Internacional para la Estandarización)

ISO/IEC International Organization for Standardization and

International Electrotechnical Commission (Organización

Internacional para la Estandarización y Comisión

Internacional Electrotécnica)

IT information technology (TI - tecnologías de la información)

ITIL Information Technology Infrastructure Library (Biblioteca de

Infraestructura de Información Tecnológica)

ITSCMM Information Technology Services Capability Maturity Model

(Modelo de Capacidad y Madurez para Servicios de

Tecnología de la Información)

IWM Integrated Work Management (área de proceso Gestión

Integrada de Trabajos)

MA Measurement and Analysis (área de proceso Medición y

Análisis)

MDD Method Definition Document (Documento de Definición del

Modelo)

ML maturity level (nivel de madurez)

MTBF mean time between failure (tiempo medio entre fallos)

NDIA National Defense Industrial Association (Asociación

Industrial para la Defensa Nacional)

OID Organizational Innovation and Deployment (anterior área de

proceso Innovación Organizativa y Despliegue)

OLA operating level agreement (acuerdo de nivel de operación)

OPD Organizational Process Defnition (área de proceso

Definición Organizativa de Procesos)

OPF Organizational Process Focus (área de proceso Enfoque

Organizativo en Procesos)

OPM Organizational Performance Management (área de proceso

Gestión del Rendimiento Organizativo)

OPP Organizational Process Performance (área de proceso

Rendimiento Organizativo de Procesos)


Acrónimos 491

OT Organizational Training (área de proceso Capacitación

Organizativa)

PCA physical configuration audit (auditoría de configuración

física)

P-CMM People Capability Maturity Model (Modelo de Capacidad y

Madurez de Personas)

PERT Program Evaluation and Review Technique (Técnica de

Evaluación y Revisión de Programas)

PPQA Process and Product Quality Assurance (área de proceso

Aseguramiento de Calidad de Procesos y Productos)

PWS performance work statement (declaración del rendimiento

del trabajo)

QFD Quality Function Deployment (Despliegue de la Función de

Calidad)

QWM Quantitative Work Management (área de proceso Gestión

Cuantitativa de Trabajos)

REQM Requirements Management (área de proceso Gestión de

Requisitos)

RSKM Risk Management (área de proceso Gestión de Riesgos)

RSS rich site summary (formato de sindicación de contenidos)

SaaS software as a service (software como un servicio)

SAM Suplier Agreement Management (área de proceso Gestión

de Acuerdos de Suministro)

SCAMPI Standard CMMI Appraisal Method for Process Improvement

(Método Estándar de Evaluación de CMMI para Mejora de

Procesos)

SCON Service Continuity (área de proceso Continuidad del

Servicio)

SD Service Delivery (área de proceso Prestación de Servicios)

SECAM Systems Engineering Capability Assessment Model (Modelo

de Evaluación de Capacidad en Ingeniería de Sistemas)

SECM Software Engineering Capability Model (Modelo de

Capacidad en Ingeniería de Software)


Acrónimos 492

SEI Software Engineering Institute (Instituto de Ingeniería de

Software)

SG specific goal (meta específica)

SLA service level agreement (acuerdo de nivel de servicio)

SOA service-oriented architecture (arquitectura orientada a

servicios)

SOO statement of objectives (declaración de objetivos)

SOW statement of work (declaración del trabajo)

SP specific practice (práctica específica)

SPI schedule performance index (índice de rendimiento en

plazos)

SSD Service System Development (área de proceso Desarrollo

del Sistema de Servicio)

SSE-CMM Systems Security Engineering Capability Maturity Model

(Modelo de Capacidad y Madurez en Ingeniería de

Seguridad de Sistemas)

SST Service System Transition (área de proceso Transición del

Sistema de Servicio)

STSM Strategic Service Management (área de proceso Gestión

Estratégica de Servicios)

SW-CMM Capability Maturity Model for Software or Software

Capability Maturity Model (Modelo de Capacidad y Madurez

para Software)

SWOT strengths, weaknesses, opportunities, and threats (DAFO -

Debilidades, Amenazas, Fortalezas y Oportunidades)

WBS work breakdown structure (EDT- Estructura de

Descomposición del Trabajo)

WMC Work Monitoring and Control (área de proceso

Monitorización y Control de Trabajos)

WP Work Planning (área de proceso Planificación de Trabajos)


Participantes en el Proyecto CMMI Versión 1.3 493

Apéndice C: Participantes en el Proyecto CMMI

Versión 1.3

Muchas personas con talento han formado parte del equipo de producto

que ha desarrollado los modelos de la versión 1.3 de CMMI. Se enumeran

a continuación a quienes participaron en uno o más de los siguientes

equipos durante el desarrollo de la versión 1.3 de CMMI. Las

organizaciones que se indican junto al nombre de cada uno de los

miembros son aquellas a las que dichos miembros representaban en el

momento en el que formaron parte del equipo.

Los siguientes son los grupos principales involucrados en el desarrollo de

este modelo:

Comité de Dirección de CMMI.

Grupo Asesor de CMMI para Servicios.

Equipo de Coordinación de CMMI V1.3.

Comité de Control de Configuración de CMMI V1.3.

Equipo del Núcleo del Modelo CMMI V1.3.

Equipo de Traducción de CMMI V1.3.

Equipo de Alta Madurez de CMMI V1.3.

Mini Equipo de Adquisiciones de CMMI V1.3.

Mini Equipo de Servicios de CMMI V1.3.

Equipo de Actualización de SCAMPI de CMMI V1.3.

Equipos de Capacitación de CMMI V1.3.

Equipo de Calidad de CMMI V1.3.

Comité de Dirección de CMMI

El Comité de Dirección de CMMI guía y aprueba los planes del Equipo de

Producto de CMMI, asesora sobre problemas importantes en el proyecto

CMMI, asegura que se involucren las diferentes comunidades interesadas

y aprueba la versión final del modelo.

Miembros del Comité de Dirección

Alan Bemish, US Air Force

Anita Carleton, Software Engineering Institute

Clyde Chittister, Software Engineering Institute

James Gill, Boeing Integrated Defense Systems

John C. Kelly, NASA



Kathryn Lundeen, Defense Contract Management Agency

Larry McCarthy, Motorola, Inc.

Lawrence Osiecki, US Army

Robert Rassa, Raytheon Space and Airborne Systems (líder)

Karen Richter, Institute for Defense Analyses

Joan Weszka, Lockheed Martin Corporation

Harold Wilson, Northrop Grumman

Brenda Zettervall, US Navy

Miembros Ex-Oficio del Comité de Dirección

Mike Konrad, Software Engineering Institute

Susan LaFortune, National Security Agency

David (Mike) Phillips, Software Engineering Institute

Soporte al Comité de Dirección

Mary Beth Chrissis, Software Engineering Institute (CCB)

Eric Hayes, Software Engineering Institute (secretario)

Rawdon Young, Software Engineering Institute (programa de

Evaluación)

Grupo Asesor de CMMI para Servicios

El Grupo Asesor para Servicios asesora al equipo de desarrollo del

producto sobre las industrias de servicios.

Brandon Buteau, Northrop Grumman Corporation

Christian Carmody, University of Pittsburgh Medical Center

Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM SED

Annie Combelles, DNV IT Global Services

Jeff Dutton, Jacobs Technology, Inc.

Eileen Forrester, Software Engineering Institute

Craig Hollenbach, Northrop Grumman Corporation (líder)

Bradley Nelson, Department of Defense

Lawrence Osiecki, US Army ARDEC


Timothy Salerno, Lockheed Martin Corporation

Sandy Shrum, Software Engineering Institute

Nidhi Srivastava, Tata Consultancy Services

Elizabeth Sumpter, NSA

David Swidorsky, Bank of America



Equipo de Coorinación de CMMI V1.3

El Equipo de Coordinación reúne a miembros de otros equipos de

desarrollo del producto para asegurar la coordinación entre todo el

proyecto.

Rhonda Brown, Software Engineering Institute

Mary Beth Chrissis, Software Engineering Institute


Will Hayes, Software Engineering Institute


So Norimatsu, Norimatsu Process Engineering Lab, Inc.

Mary Lynn Penn, Lockheed Martin Corporation

David (Mike) Phillips, Software Engineering Institute (líder)


Kathy Smith, Hewlett Packard

Barbara Tyson, Software Engineering Institute

Rawdon Young, Software Engineering Institute

Mary Lynn Russo, Software Engineering Institute (miembro sin voto)

Comité de Control de Configuración de CMMI V1.3

El Comité de Control de Configuración aprueba todos los cambios a los

materiales de CMMI, incluyendo los modelos, el MDD SCAMPI y la

capacitación sobre introducción al modelo.


Michael Campo, Raytheon

Mary Beth Chrissis, Software Engineering Institute (líder)

Kirsten Dauplaise, NAVAIR

Mike Evanoo, Systems and Software Consortium, Inc.

Rich Frost, General Motors

Brian Gallagher, Northrop Grumman

Sally Godfrey, NASA

Stephen Gristock, JP Morgan Chase and Co.

Eric Hayes (miembro sin voto)

Nils Jacobsen, Motorola

Steve Kapurch, NASA


Chris Moore, US Air Force

Wendell Mullison, General Dynamics Land Systems


Robert Rassa, Raytheon Space and Airborne Systems




Mary Lou Russo (miembro sin voto)

Warren Schwoemeyer, Lockheed Martin Corporation

John Scibilia, US Army

Dave Swidorsky, Bank of America


Mary Van Tyne, Software Engineering Institute (miembro sin voto)


Equipo del Núcleo del Modelo CMMI V1.3

El Equipo de Núcleo del Modelo desarrolla los materiales del modelo

comunes a las tres constelaciones.

Jim Armstrong, Stevens Institute of Technology

Rhonda Brown, Software Engineering Institute (co-líder)

Brandon Buteau, Northrop Grumman



Mary Beth Chrissis, Software Engineering Institute

Mike D’Ambrosa, Process Performance Professionals



Mike Konrad, Software Engineering Institute (co-líder)

So Norimatsu, Norimatsu Process Engineering Lab, Inc.

Mary Lynn Penn, Lockheed Martin Corporation





Sandy Shrum, Software Engineering Institute (co-líder)


Katie Smith-McGarty, US Navy

Equipo de Traducción de CMMI V1.3

El Equipo de Traducción coordina los trabajos de traducción de los

materiales de CMMI.

Richard Basque, Alcyonix

Jose Antonio Calvo-Manzano, Universidad Politecnica de Madrid

Carlos Caram, Integrated Systems Diagnostics Brazil

Gonzalo Cuevas, Universidad Politecnica de Madrid




Antoine Nardeze, Alcyonix

So Norimatsu, Norimatsu Process Engineering Lab, Inc. (líder)

Seven Ou, Institute for Information Industry

Ricardo Panero Lamothe, Accenture


Winfried Russwurm, Siemens AG

Tomas San Feliu, Universidad Politecnica de Madrid

Equipo de Alta Madurez de CMMI V1.3

El Equipo de Alta Madurez desarrolló los materiales del modelo sobre alta

madurez.

Dan Bennett, US Air Force


Rick Hefner, Northrop Grumman

Jim Kubeck, Lockheed Martin Corporation

Alice Parry, Raytheon

Mary Lynn Penn, Lockheed Martin Corporation (líder)



Mini Equipo de Adquisiciones de CMMI V1.3

El Mini Equipo de Adquisiciones proporciona su experiencia en

adquisiciones a los trabajos de desarrollo del modelo.

Rich Frost, General Motors

Tom Keuten, Keuten and Associates

David (Mike) Phillips, Software Engineering Institute (líder)



Mini Equipo de Servicios de CMMI V1.3

El Mini Equipo de Servicios proporciona su experiencia en servicios a los

trabajos de desarrollo del modelo.

Drew Allison, Systems and Software Consortium, Inc.

Brandon Buteau, Northrop Grumman

Eileen Forrester, Software Engineering Institute (líder)

Christian Hertneck, Anywhere.24 GmbH

Pam Schoppert, Science Applications International Corporation



Equipo de Actualización de SCAMPI de CMMI v1.3

El Equipo de Actualización de SCAMPI desarrolla los documentos

Appraisal Requirements for CMMI (ARC-Requisitos de Evaluación para

CMMI) y SCAMPI Method Definition Document (MDD-Documento de

Definición del Método SCAMPI).

Mary Busby, Lockheed Martin Corporation

Palma Buttles-Valdez, Software Engineering Institute

Paul Byrnes, Integrated System Diagnostics

Will Hayes, Software Engineering Institute (líder)

Ravi Khetan, Northrop Grumman

Denise Kirkham, The Boeing Company

Lisa Ming, The Boeing Company

Charlie Ryan, Software Engineering Institute

Kevin Schaaff, Software Engineering Institute

Alexander Stall, Software Engineering Institute

Agapi Svolou, Software Engineering Institute

Ron Ulrich, Northrop Grumman

Equipos de Capacitación de CMMI V1.3

Los dos equipos de capacitación (uno para CMMI-DEV y CMMI-ACQ y el

otro para CMMI-SVC) desarrollaron los materiales de capacitación sobre el

modelo.

Equipo de capacitación sobre ACQ y DEV

Barbara Baldwin, Software Engineering Institute

Bonnie Bollinger, Process Focus Management

Cat Brandt-Zaccardi, Software Engineering Institute



Mary Beth Chrissis, Software Engineering Institute (líder)

Stacey Cope, Software Engineering Institute

Eric Dorsett, Jeppesen

Dan Foster, PF Williamson

Eric Hayes, Software Engineering Institute

Kurt Hess, Software Engineering Institute


Steve Masters, Software Engineering Institute

Robert McFeeley, Software Engineering Institute

Diane Mizukami-Williams, Northrop Grumman

Daniel Pipitone, Software Engineering Institute



Mary Lou Russo, Software Engineering Institute (miembro sin voto)


Katie Smith-McGarty, US Navy


Equipo de Capacitación sobre SVC

Drew Allison, Systems and Software Consortium, Inc.

Mike Bridges, University of Pittsburgh Medical Center

Paul Byrnes, Integrated System Diagnostics


Eileen Clark, Tidewaters Consulting

Kieran Doyle, Excellence in Measurement

Eileen Forrester, Software Engineering Institute (líder del capacitación

sobre SVC)

Suzanne Miller, Software Engineering Institute

Hillel Glazer, Entinex

Christian Hertneck, Anywhere.24 GmbH

Pat Kirwan, Software Engineering Institute

Judah Mogilensky, PEP

Heather Oppenheimer, Oppenheimer Partners

Pat O’Toole, PACT

Agapi Svolou, Alexanna

Jeff Welch, Software Engineering Institute

Equipo de Calidad de CMMI V1.3

El Equipo de Calidad lleva a cabo diversas comprobaciones de

aseguramiento de calidad en los materiales del modelo para asegurar su

precisión, legibilidad y consistencia.

Rhonda Brown, Software Engineering Institute (co-líder)

Erin Harper, Software Engineering Institute


Mary Lou Russo, Software Engineering Institute

Mary Lynn Russo, Software Engineering Institute

Sandy Shrum, Software Engineering Institute (co-líder)


Glosario 500

Apéndice D: Glosario

El glosario define los términos básicos utilizados en los modelos CMMI. Las

entradas del glosario habitualmente son términos con varias palabras que

consisten en un nombre junto a uno o varios modificadores restrictivos (hay

algunas excepciones a esta regla que justifican que haya términos en el

glosario de una sola palabra).

El glosario de términos de CMMI no es un componente requerido,

esperado, o informativo de los modelos CMMI. Interprete los términos del

glosario según el contexto de los componentes del modelo en los que

aparezcan.

Para formular las definiciones apropiadas para CMMI, se han consultado

varias fuentes. Primero se ha consultado el diccionario Merriam-Webster

OnLine dictionary (http://www.merriam-webster.com/). Según fue

necesario, también se consultaron otros estándares, incluyendo los

siguientes:

ISO 9000 [ISO 2005a]

ISO/IEC 12207 [ISO 2008a]

ISO/IEC 15504 [ISO 2006a]

ISO/IEC 15288 [ISO 2008b]

ISO/IEC 15939 [ISO 2007]

ISO 20000-1 [ISO 2005b]

IEEE [IEEE 1991]

CMM for Software (SW-CMM) v1.1

EIA 632 [EIA 2003]

SA-CMM [SEI 2002]

People CMM (P-CMM) [Curtis 2009]

CobiT v. 4.0 [IT Governance 2005]

ITIL v3 (Service Improvement, Service Design, Service Operation,

Service Strategy, and Service Transition) [Office of Government

Commerce 2007]

Para desarrollar el glosario se ha reconocido la importancia de utilizar una

terminología que puedan entender todos los usuarios del modelo. También

se ha reconocido que las palabras y términos pueden tener distintos

significados en distintos contextos y entornos. El glosario de los modelos

CMMI está diseñado para documentar el significado de las palabras y los

términos que más ampliamente deberían ser utilizados y entendidos por los

usuarios de los productos CMMI.


Glosario 501

Aun cuando el término “producto” incluye tanto servicios como productos y

el término “servicio” está definido como un tipo de producto, muchos de los

términos del glosario contienen ambas palabras “producto” y “servicio” para

enfatizar que CMMI aplica tanto a productos como a servicios.

Cada entrada en el glosario tiene de dos a tres componentes. Siempre hay

un término y una definición. A veces se proporcionan notas adicionales.

El término definido aparece en la parte izquierda de la página. La definición

aparece en primer lugar, utilizando un tamaño de letra similar al término

definido. Las notas del glosario aparecen con menor tamaño de letra a

continuación.

acción correctiva (corrective action)

Actos o hechos empleados para remediar una situación o eliminar un error.

activo de proceso (process asset)

Cualquier cosa que la organización considere útil para lograr las metas de un área de proceso (véase también “activos de proceso organizativos”).

activos de proceso organizativos (organizational process assets)

Artefactos relacionados con describir, implementar, y mejorar procesos.

Las políticas, las descripciones de mediciones, las descripciones de procesos, y las herramientas de soporte a la implementación de procesos son algunos ejemplos de estos artefactos.

El término “activos de proceso” se utiliza para indicar que estos artefactos se desarrollan o adquieren para cumplir objetivos de negocio de la organización, y representan inversiones de la organización que se espera que actualmente y en el futuro proporcionen valor al negocio (véase también “biblioteca de activos de proceso”).

acuerdo de nivel de servicio (service level agreement)

Acuerdo de servicio que especifica los servicios prestados; las medidas de servicio; los niveles de servicio aceptables y no aceptables; y las responsabilidades, obligaciones y acciones que se esperan ante situaciones previstas, tanto por parte del proveedor como del cliente (véase también "medición", servicio" y "acuerdo de servicio").

Un acuerdo de nivel de servicio es un tipo de acuerdo de servicio que documenta los detalles indicados en la definición.

El uso del término "acuerdo de servicio" siempre incluye como subcategoría al "acuerdo de nivel de servicio", y para abreviar se puede utilizar el primero en lugar del segundo. Sin embargo, cuando se desea enfatizar situaciones en las que existan varios niveles de servicio aceptables, o cuando otros detalles del acuerdo de nivel de servicio puedan ser importantes para la discusión, se prefiere el término "acuerdo de nivel de servicio".


Glosario 502

acuerdo de servicio (service agreement)

Un registro vinculante y por escrito de una promesa de intercambio de valor entre un proveedor de servicios y un cliente (véase también "cliente").

Los acuerdos de servicio pueden ser completamente negociables, parcialmente negociables, o no negociables, y dependiendo de la situación, los puede redactar el proveedor de servicios, el cliente o ambos.

Una "promesa de intercambiar de valor" significa un reconocimiento y aceptación conjuntos de lo que cada parte proporcionará a la otra para satisfacer el acuerdo. Habitualmente, el cliente proporciona pagos a cambio de servicios prestados, pero son posibles otros acuerdos.

El registro "por escrito" no tiene por qué estar contenido en un documento u otro artefacto individual. Alternativamente, para algunos tipos de servicio puede ser extremadamente breve (p. ej. un recibo que identifique el servicio, su precio y su receptor).

acuerdo de suministro (supplier agreement)

Un acuerdo documentado entre un adquiriente y un suministrador (véase también "suministrador").

Los acuerdos de suministro también se conocen como contratos, licencias y memorandos de acuerdo.

adaptación (tailoring) El acto de hacer, modificar o adaptar algo a un fin concreto.

Por ejemplo, un proyecto o un grupo de trabajo establece su proceso definido a partir del conjunto de procesos estándar de la organización adaptándolo a sus objetivos y restricciones y a su entorno. De forma análoga, un proveedor de servicios adapta los servicios estándar a un acuerdo de servicio concreto.

adaptación de procesos (process tailoring)

Crear, modificar o adaptar una descripción de proceso para un fin concreto.

Por ejemplo, partiendo del conjunto de procesos estándar de la organización, un proyecto o grupo de trabajo adapta su proceso definido para que cumpla con sus objetivos, restricciones y entorno (véase también "proceso definido", "conjunto de procesos estándar de la organización" y "descripción de proceso").

adquiriente (acquirer) Parte interesada que adquiere u obtiene productos o servicios de un suministrador (véase también “parte interesada”).

adquisición (acquisition)

Proceso de obtener productos o servicios por medio de acuerdos de suministro (véase también "acuerdo de suministro").


Glosario 503

alcance de la evaluación (appraisal scope)

Definición de los límites de la evaluación que engloba los límites organizativos y los límites del modelo CMMI dentro de los cuales operan los procesos que se van a examinar.

Este término se utiliza en los materiales de evaluación, tales como el SCAMPI MDD.

análisis causal (causal analysis)

Análisis de los resultados para determinar sus causas.

análisis de requisitos (requirements analysis)

Determinar las características funcionales y los atributos de calidad específicos del producto o servicio, basándose en analizar las necesidades, expectativas y restricciones del cliente, el modelo operativo, los entornos de uso esperados para personas, productos, servicios y procesos, y las medidas de eficacia (véase también "modelo operativo").

análisis de riesgos (risk analysis)

Evaluación, clasificación y priorización de riesgos.

análisis funcional (functional analysis)

Examinar una función definida para identificar todas las subfunciones que se necesitan para lograr dicha función; identificar las relaciones funcionales e interfaces (internas y externas) y capturar estas relaciones e interfaces en una arquitectura funcional; y descomponer los requisitos de mayor nivel y asignarlos a subfunciones de menor nivel (véase también “arquitectura funcional”).

área de proceso (process area)

Grupo de prácticas relacionadas dentro de un área que, cuando se implementan de conjuntamente, satisface un conjunto de metas que se consideran importantes para mejorar en esa área.

arquitectura (architecture)

Conjunto de estructuras necesarias para razonar acerca de un producto. Estas estructuras se componen de elementos, relaciones entre elementos, y propiedades de ambos.

En un contexto de servicios, la arquitectura aplica a menudo al sistema de servicio

Obsérvese que la funcionalidad es sólo un aspecto del producto. También es importante razonar acerca de atributos de calidad, tales como la responsividad, fiabilidad y seguridad. Las estructuras proporcionan medios para destacar distintas partes de la arquitectura (véase también "arquitectura funcional").

arquitectura de procesos (process architecture)

(1) Ordenación, interfaces, interdependencias y otras relaciones entre elementos de proceso dentro de un proceso estándar, o (2) interfaces, interdependencias y otras relaciones entre elementos de proceso y procesos externos.


Glosario 504

arquitectura funcional (functional architecture)

Organización jerárquica de funciones, de sus interfaces funcionales internas y externas (externas a la propia agregación) e interfaces físicas externas, de sus respectivos requisitos, y de sus restricciones de diseño (véase también "arquitectura", "análisis funcional" y "definición de la funcionalidad y atributos de calidad requeridos").

arranque de trabajo (work startup)

Momento en el que un conjunto de recursos interrelacionados se destina a desarrollar o proporcionar uno o más productos o servicios para un cliente o usuario final (véase también "grupo de trabajo"),

arranque del proyecto (project startup)

Momento en el que un conjunto de recursos interrelacionadods para un proyecto se destinan al desarrollo o entrega de uno o más productos o servicios para un cliente o usuario final (véase también "proyecto"),

aseguramiento de la calidad (quality assurance)

Un medio planificado y sistemático para asegurar a la gerencia que se aplican los estándares, prácticas, procedimientos, y métodos definidos del proceso.

atributo de calidad (quality attribute)

Propiedad de un producto o servicio por la cual las partes interesadas relevantes juzgarán su calidad. Los atributos de calidad son caracterizables por medidas apropiadas.

Los atributos de calidad, tales como la puntualidad, capacidad productiva, responsividad, seguridad, modificabilidad, fiabilidad, y usabilidad son no-funcionales. Éstos tienen una influencia significativa sobre la arquitectura.

atributo de proceso (process attribute)

Característica medible de la capacidad de un proceso aplicable a cualquier proceso.

atributos de productos de trabajo y tareas (work product and task attributes)

Características de productos, servicios y tareas que se utilizan para ayudar a estimar un trabajo. Estas características incluyen elementos tales como el tamaño, complejidad, peso, forma, ajuste y función. Se utilizan habitualmente como entrada para derivar otras estimaciones de recursos (p. ej. esfuerzo, costes, plazos).

auditoría (audit) Examen objetivo con respecto a criterios específicos de un producto de trabajo o un conjunto de productos de trabajo (p. ej. requisitos; véase también "evaluar objetivamente").

Este término se utiliza de varias formas en CMMI, incluyendo las auditorías de configuración y las auditorías de cumplimiento de procesos.


Glosario 505

auditoría de configuración (configuration audit)

Auditoría realizada para verificar que un elemento de configuración, o un conjunto de elementos de configuración que componen una línea base, se ajusta a un estándar o requisito especificado (véase también "auditoría" y "elemento de configuración")

biblioteca de activos de proceso (process asset library)

Conjunto de activos de proceso que se conservan y pueden ser utilizados por una organización, proyecto o grupo de trabajo (véase también “biblioteca de activos de proceso de la organización”).

biblioteca de activos de proceso de la organización (organization’s process asset library)

Biblioteca de información utilizada para almacenar y hacer disponibles los activos de proceso que sean útiles para quienes definen, implementan, y gestionan procesos en la organización.

Esta biblioteca contiene activos de proceso que incluyen documentación relacionada con procesos, tales como políticas, procesos definidos, listas de comprobación, documentos de lecciones aprendidas, plantillas, estándares, procedimientos, planes y materiales de capacitación.

calidad (quality) Grado en el que un conjunto de características inherentes satisface los requisitos

calificación de la evaluación (appraisal rating)

Valor asignado por un equipo de evaluación a (a) una meta o área de proceso de CMMI, (b) el nivel de capacidad de un área de proceso o (c) el nivel de madurez de una unidad organizativa.

Este término se utiliza en los materiales de evaluación de CMMI, tales como el MDD de SCAMPI. Una calificación se determina poniendo en práctica el proceso de calificación definido en el método de evaluación que se esté empleando.

capacidad de proceso (process capability)

Rango de resultados esperados que se pueden alcanzar al seguir un proceso.

capacitación (training)

Opciones de aprendizaje formales e informales.

Estas opciones pueden incluir capacitación en aulas, tutela informal, capacitación basada en web, autoestudio guiado y programas formalizados de capacitación en el puesto de trabajo.

La elección de opciones en cada situación se basa en evaluar las necesidades de capacitación y las carencias en el desempeño que hay que abordar.


Glosario 506

catálogo de servicios (service catalog)

Lista o repositorio de definiciones de servicio estandarizadas.

Los catálogos de servicios pueden incluir distintos niveles de detalle sobre los niveles de servicio, calidades, precios, elementos negociables/adaptables y términos y condiciones disponibles.

Un catálogo de servicios no tiene por qué estar contenido en un único documento u otro artefacto, y puede ser una combinación de elementos que proporcionen una información equivalente (tales como páginas web enlazadas a bases de datos). Alternativamente, para algunos servicios un catálogo eficaz puede ser un simple menú impreso de los servicios disponibles y sus precios.

La información del catálogo de servicios puede dividirse en varios subconjuntos para dar soporte a diferentes tipos de partes interesadas (p. ej., clientes, usuarios finales, personal del proveedor, suministradores).

causa común de variación (common cause of variation)

Variación del proceso debida a las interacciones normales y esperadas entre los componentes de un proceso (véase también “causa especial de variación”).

causa especial de variación (special cause of variation)

Causa del defecto que es específica de una situación transitoria y no es parte inherente del proceso (véase también "causa común de variación")

ciclo de vida de producto (product lifecycle)

Periodo de tiempo, compuesto por fases, que comienza cuando se concibe un producto o servicio, y finaliza cuando el producto o servicio deja de estar disponible para su uso.

Dado que una organización puede estar produciendo varios productos o servicios para varios clientes, puede que no sea adecuado disponer de una única descripción de ciclo de vida de producto. Por tanto, la organización puede definir un conjunto de modelos de ciclo de vida de producto aprobados. Estos modelos habitualmente se pueden encontrar en la literatura publicada y con frecuencia se adaptan para utilizarlos en la organización.

Un ciclo de vida de producto podría constar de las siguientes fases: (1) concepto y visión, (2) viabilidad, (3) diseño/desarrollo, (4) producción y (5) retirada.


Glosario 507

cliente (customer) Parte responsable de aceptar el producto o autorizar el pago.

El cliente es externo al proyecto o grupo de trabajo (excepto posiblemente en ciertas estructuras de proyecto en las cuales el cliente, de hecho, forma parte del equipo del proyecto o del grupo de trabajo), pero no es necesariamente externo a la organización. El cliente puede ser un proyecto o un grupo de trabajo de mayor nivel. Los clientes son un subconjunto de las partes interesadas (véase también “parte interesada”).

En la mayoría de los casos en los que se usa este término, la definición que se pretende es la precedente; sin embargo, en algunos contextos, con el término “cliente” se pretende incluir a otras partes interesadas relevantes (véase también “requisitos de cliente”).

Los usuarios finales pueden ser distintos de los clientes si las partes que directamente reciben el valor de los productos y servicios no son las mismas que las que establecen, pagan o negocian los acuerdos. En contextos en los que los clientes y los usuarios finales sean esencialmente los mismos, el término “cliente” puede englobar a ambos (véase también “usuario final”).

comité de control de configuración (configuration control board)

Grupo de personas que se responsabiliza de evaluar y aprobar o rechazar cambios propuestos a los elementos de configuración, y de asegurar que los cambios aprobados se implementen (véase también “elemento de configuración”).

Los comités de control de configuración también se conocen como “comités de control de cambios”.

componente de modelo CMMI (CMMI model component)

Cualquiera de los elementos de arquitectura principales que componen un modelo CMMI.

Algunos de los elementos principales de un modelo CMMI son las prácticas específicas, las prácticas genéricas, las metas específicas, las metas genéricas, las áreas de proceso, los niveles de capacidad y los niveles de madurez.

componente de producto (product component)

Producto de trabajo que forma parte del producto a menor nivel (véase también “producto” y “producto de trabajo”).

Los componentes de producto se integran para formar el producto. Pueden existir varios niveles de componentes de producto.

En las áreas de proceso, cuando se utilizan los términos “producto” y “componente de producto”, sus significados también abarcan los servicios, los sistemas de servicio y sus componentes.

Este término tiene un significado especial en el Conjunto de Productos CMMI además de su significado habitual.


Glosario 508

componente de sistema de servicio (service system component)

Recurso necesario para que un sistema de servicio preste servicios satisfactoriamente.

Algunos componentes pueden seguir siendo propiedad del cliente, usuario final o terceras partes antes de empezar y después de terminar la prestación de servicios (véase también “cliente” y “usuario final”).

Algunos componentes pueden ser recursos transitorios que forman parte del sistema de servicio por un tiempo limitado (p. ej. elementos que se estén reparando en un establecimiento de mantenimiento).

Los componentes pueden incluir procesos y personas.

Cuando el contexto deje claro su significado, la palabra "componente" se puede utilizar para abreviar en lugar de "componente de sistema de servicio".

La palabra “infraestructura” puede utilizarse para referirse colectivamente a los componentes tangibles y esencialmente permanentes del sistema de servicio. Dependiendo del contexto y del tipo de servicio, la infraestructura puede incluir recursos humanos.

componentes esperados de CMMI (expected CMMI coponents)

Componentes de CMMI que describen las actividades que son importantes para lograr un componente requerido de CMMI.

Los usuarios del modelo pueden implementar los componentes esperados explícitamente o implementar prácticas alternativas equivalentes a estos componentes. Las prácticas específicas y genéricas son componentes esperados del modelo.

componentes informativos de CMMI (informative CMMI components)

Componentes de CMMI que ayudan a los usuarios del modelo a comprender los componentes requeridos y esperados del modelo.

Estos componentes pueden ser ejemplos, explicaciones detalladas u otro tipo de información útil. Las subprácticas, las notas, las referencias, los títulos de metas, los títulos de prácticas, las fuentes, los ejemplos de productos de trabajo, y las elaboraciones de prácticas genéricas son componentes informativos del modelo.

componentes requeridos de CMMI (required CMMI components)

Componentes de CMMI que son esenciales para lograr la mejora de procesos en un área de proceso determinada.

Las metas específicas y las metas genéricas son componentes requeridos del modelo. En las evaluaciones, satisfacer metas se utiliza como base para decidir si un área de proceso se ha satisfecho o no.


Glosario 509

conjunto de procesos estándar de la organización (organization’s set of standard processes)

Conjunto de las definiciones de proceso que guían las actividades de una organización.

Estas descripciones de proceso cubren los elementos de proceso fundamentales (y sus interrelaciones, tales como son la secuencia e interfaces) que deberían incorporarse en los procesos definidos implementados en proyectos, grupos de trabajo y trabajos de toda la organización. Un proceso estándar posibilita que las actividades de desarrollo y mantenimiento de la organización sean consistentes, y es esencial para la estabilidad y mejora a largo plazo (véase también “proceso definido” y “elemento de proceso”).

conjunto de productos (product suite)

Véase “Conjunto de Productos CMMI”.

Conjunto de Productos CMMI (CMMI Product Suite)

Conjunto completo de productos desarrollados alrededor del concepto CMMI (véase también “Marco CMMI” y “modelo CMMI”).

Estos productos incluyen el propio marco, los modelos, los métodos de evaluación, los materiales de evaluación y los materiales de capacitación.

constelación (constellation)

Colección de componentes de CMMI utilizados en un área de interés (p. ej. adquisición, desarrollo, servicios) para construir modelos, materiales de capacitación y documentos relacionados con evaluaciones.

consumible del sistema de servicio (service system consumable)

Componente de sistema de servicio que deja de estar disponible o cambia permanentemente al ser utilizado para proporcionar un servicio.

El combustible, los suministros de oficina y los recipientes desechables son ejemplos de consumibles utilizados habitualmente. Algunos tipos de servicio concretos pueden tener sus propios consumibles especializados (p. ej., un servicio sanitario puede requerir medicinas o suministros de sangre).

Una persona no es un consumible, pero su tiempo de trabajo sí es un consumible.

contratista (contractor)

Véase "suministrador"

control de calidad (quality control)

Técnicas y actividades operativas que se utilizan para satisfacer los requisitos de calidad (véase también “aseguramiento de la calidad”).

control de configuración (configuration control)

Elemento de la gestión de configuración que consiste en evaluar, coordinar, aprobar o rechazar, e implementar cambios a elementos de configuración una vez se ha establecido formalmente su identificador de configuración (véase también “identificación de configuración”, “elemento de configuración” y “gestión de configuración”).


Glosario 510

control de interfaz (interface control)

En gestión de configuración, el proceso de (1) identificar todas las características funcionales y físicas relevantes para interconectar dos o más elementos de configuración proporcionados por una o más organizaciones, y (2) asegurar que los cambios propuestos a estas características se evalúen y aprueben antes de implementarlos (véase también “elemento de configuración” y “gestión de configuración”).

control de versiones (version control)

Establecer y mantener líneas base e identificar cambios a líneas base haciendo posible regresar a la línea base anterior.

En algunos contextos, un producto de trabajo individual puede tener su propia línea base y puede ser suficiente un nivel de control menor al control de configuración formal.

control estadístico de procesos (statistical process control)

Análisis de procesos y de medidas de rendimiento de procesos basados en la estadística, los cuales identifican causas de variación en el rendimiento de procesos especiales y comunes, y mantienen el rendimiento de procesos dentro de límites (véase también "causa común de variación", "causa especial de variación" y "técnicas estadísticas").

criterios de aceptación (acceptance criteria)

Criterios que un entregable debe satisfacer para ser aceptado por un usuario, cliente u otra entidad autorizada (véase también “entregable”).

criterios de entrada (entry criteria)

Circunstancias que tienen que estar presentes para que pueda comenzar con éxito una labor.

criterios de salida (exit criteria)

Circunstancias que tienen que estar presentes para que pueda finalizar con éxito una labor.

datos (data) Información registrada.

La información registrada puede incluir datos técnicos, documentos de software, información financiera, información de gestión, representaciones de hechos, cantidades, o datos de cualquier naturaleza que puedan ser comunicados, almacenados y procesados.

declaración de trabajo (statement of work)

Descripción del trabajo a realizar.


Glosario 511

definición de la funcionalidad y atributos de calidad requeridos (definition of required functionality and quality attributes)

Caracterización de la funcionalidad y atributos de calidad requeridos, que se obtiene por medio de "trocear", organizar, anotar, estructurar, o formalizar los requisitos (funcionales y no funcionales) con objeto de facilitar posteriores refinamientos y razonamientos sobre los requisitos, así como para explorar, definir y evaluar la (posiblemente, inicial) solución (véase también “arquitectura”, "arquitectura funcional” y “atributo de calidad”).

A medida que progresan los procesos de solución técnica, esta caracterización puede evolucionar más aún hasta convertirse en una descripción de la arquitectura en vez de ser simplemente una ayuda para delimitar y guiar su desarrollo, dependiendo de los procesos de ingeniería empleados, los lenguajes usados para especificar los requisitos y la arquitectura, y las herramientas y entornos utilizados para desarrollar el producto o el sistema de servicio.

definición de proceso (process definition)

El acto de definir y describir un proceso.

El resultado de definir un proceso es una descripción de proceso (véase también "descripción de proceso")

densidad de defectos (defect density)

Número de defectos por unidad de tamaño de producto.

Un ejemplo es el número de informes de problema por cada mil líneas de código.

desarrollo (development)

Crear un producto o un sistema de servicio por medio de un esfuerzo deliberado.

En algunos contextos, el desarrollo puede incluir el mantenimiento del producto desarrollado.

descripción de proceso (process description)

Expresión documentada de un conjunto de actividades que se realizan para lograr un propósito determinado.

La descripción de proceso proporciona una definición operativa de los principales componentes del proceso. La descripción especifica de manera completa, precisa y verificable, los requisitos, el diseño, el comportamiento u otras características del proceso. También puede incluir procedimientos para determinar si se han satisfecho o no estas disposiciones. Se pueden encontrar descripciones de proceso a nivel de actividad, de proyecto, de grupo de trabajo, o a nivel organizativo.


Glosario 512

directivo (senior manager)

Rol de gestión en un nivel de la organización suficientemente elevado como para que el centro de atención principal de la persona que lo desempeña sea la permanencia a largo plazo de la organización en vez de las preocupaciones y presiones del corto plazo (véase también "nivel directivo").

Un directivo tiene autoridad para dirigir la asignación o reasignación de recursos para dar soporte a la eficacia de la mejora de procesos organizativa.

Un directivo puede ser cualquier gerente que satisfaga esta descripción, incluyendo al director de la organización. Sinónimos para “directivo” incluyen “ejecutivo” y “gerente de máximo nivel”. Sin embargo, estos sinónimos no se utilizan en los modelos CMMI para asegurar la consistencia y usabilidad.


documento (document)

Conjunto de datos, independientemente del medio en el que estén registrados, que de forma general perdura y puede ser leído por seres humanos o por máquinas.

Los documentos incluyen tanto los documentos en papel como los electrónicos.

ejecutivo (executive) Véase "directivo".

ejemplo de producto de trabajo (example work product)

Componente informativo del modelo que proporciona muestras de resultados de una práctica específica.

elaboración de práctica genérica (generic practice elaboration)

Componente informativo del modelo que aparece después de las prácticas genérica para proporcionar orientación sobre cómo se podría aplicar la práctica genérica en un área de proceso de forma única (este componente de modelo no está presente en todos los modelos CMMI).

elemento de configuración (configuration item)

Agrupación de productos de trabajo que se designa para la gestión de configuración y se trata como una entidad única por el proceso de gestión de configuración (véase también “gestión de configuración”).


Glosario 513

elemento de proceso (process element)

Unidad básica de un proceso.

Un proceso se puede definir en términos de subprocesos o elementos de proceso. Un subproceso se considera elemento de proceso cuando no se puede descomponer más en subprocesos o elementos de proceso (véase también “proceso” y “subproceso”).

Cada elemento de proceso cubre un conjunto de actividades estrechamente relacionadas (p. ej. elemento de estimación, elemento de revisión entre pares). Los elementos de proceso se pueden representar utilizando plantillas a completar, abstracciones a refinar o descripciones a modificar o utilizar. Un elemento de proceso puede consistir en una actividad o tarea.

Los términos “proceso”, “subproceso” y “elemento de proceso” forman una jerarquía en la que "proceso” es el de mayor nivel y más general, los "subprocesos” están por debajo, y "elemento de proceso” es el más específico.

elemento no desarrollado (nondevelopmental item)

Elemento que fue desarrollado antes de su utilización actual en un proceso de adquisición o desarrollo.

Puede ser necesario realizar pequeñas modificaciones en dicho elemento para cumplir los requisitos de su actual utilización prevista.

empresa (enterprise) La composición completa de una compañía (véase también “organización”).

Una compañía puede estar formada por varias organizaciones en varias ubicaciones con clientes distintos.

entorno de prestación de servicios (delivery environment)

Conjunto completo de circunstancias y condiciones bajo las cuales se prestan servicios conforme a acuerdos de servicio (véase también "servicio" y "acuerdo de servicio").

El entorno de prestación de servicios engloba todo lo que tenga o pueda tener efectos significativos sobre la prestación de servicios, incluyendo sin que suponga una limitación la operación del sistema de servicio, los fenómenos naturales, y el comportamiento de todas las partes, pretendan o no tener tales efectos. Por ejemplo, considérese los efectos que, sobre un servicio de transporte, tienen la meteorología o los patrones de tráfico (véase también “sistema de servicio”).

El entorno de prestación de servicios se distingue de forma única de otros entornos (p. ej. entornos de simulación, entornos de pruebas). El entorno de prestación de servicios es en el que los servicios se prestan realmente y se tienen en cuenta para la satisfacción del acuerdo de servicio.


Glosario 514

entregable (deliverable)

Elemento que se proporciona a un adquiriente o a otro destinatario designado conforme a lo especificado en un acuerdo (véase también “adquiriente”).

Este elemento puede ser un documento, un elemento hardware, un elemento software, un servicio, o cualquier tipo de producto de trabajo

equipo (team) Grupo de personas con habilidades y experiencia complementarias que trabajan juntas para acometer objetivos especificados.

El equipo establece y mantiene un proceso que identifica los roles, responsabilidades, e interfaces; es suficientemente preciso como para posibilitar que el equipo mida, gestione y mejore el rendimiento de su trabajo; y posibilita que el equipo se comprometa y defienda sus compromisos.

Colectivamente, los miembros del equipo proporcionan las habilidades y el respaldo apropiados para todos los aspectos de su trabajo (p. ej. para las diferentes fases de la vida de un producto de trabajo) y son responsables de acometer los objetivos especificados.

No es necesario que todos los miembros de un proyecto o grupo de trabajo pertenezcan a un equipo (p. ej. una persona asignada a acometer una tarea que sea altamente auto contenida). Así, un gran proyecto o grupo de trabajo puede constar de varios equipos junto a personal de proyecto que no pertenezca a ningún equipo. Un proyecto o grupo de trabajo más pequeño puede constar de un solo equipo (o de un único individuo).

equipo de acciones de proceso (process action team)

Equipo que tiene la responsabilidad de desarrollar e implementar actividades de mejora para una organización, tal y como se documenta en un plan de acciones de proceso.

escenario operativo (operational scenario)

Descripción de una secuencia ficticia de eventos que incluye la interacción del producto o servicio con su entorno y usuarios así como la interacción entre sus componentes de producto o servicio.

Los escenarios operativos se utilizan para evaluar los requisitos y el diseño del sistema, y para verificar y validar el sistema.


Glosario 515

establecer y mantener (establish and maintain)

Crear, documentar, utilizar, y actualizar productos de trabajo según se necesite para asegurar que sigan siendo útiles.

La frase “establecer y mantener” desempeña un papel especial en comunicar un principio más profundo de CMMI: los productos de trabajo que tengan un papel central o clave para el rendimiento de los grupos de trabajo, los proyectos, y organizativo deberían recibir una atención especial con objeto de asegurar que se utilicen y sean útiles en ese papel.

Este término tiene una particular relevancia en CMMI porque frecuentemente aparece en declaraciones de metas y de prácticas (aunque en las primeras como "se establecen y mantienen"), y se debería considerar una forma corta del principio anterior aplicado a cualquier producto de trabajo que sea objeto del término.

estándar (standard) Requisitos formales desarrollados y utilizados para prescribir enfoques sistemáticos para adquisiciones, desarrollos, o servicios.

Algunos ejemplos de estándares son los estándares ISO/IEC, los estándares IEEE y los estándares organizativos.

estrategia de adquisición (acquisition strategy)

Enfoque específico para adquirir productos y servicios que se basa en tener en cuenta las fuentes de suministro, los métodos de adquisición, los tipos de especificación de requisitos, los tipos de acuerdo y los riesgos asociados con la adquisición.

estructura de descomposición del trabajo-EDT (work breakdown structure-WBS)

Disposición de los elementos de trabajo y sus interrelaciones y relaciones con el producto final o el servicio.

estudio de contraprestaciones (trade study)

Evaluación de alternativas, en base a criterios y análisis sistemáticos, para seleccionar la que cumple mejor determinados objetivos.

evaluación (appraisal)

Examen de uno o más procesos realizado por un equipo de profesionales cualificados utilizando un modelo de referencia de evaluación como base para, como mínimo, determinar fortalezas y debilidades.


evaluar objetivamente (objectively evaluate)

Revisión de actividades y productos de trabajo con respecto a criterios que minimicen la subjetividad y el sesgo del revisor (véase también "auditoría").

Un ejemplo de evaluación objetiva sería una auditoría con respecto a requisitos, estándares, o procedimientos por parte de una función independiente de aseguramiento de calidad.


Glosario 516

extensión (addition) Componente del modelo claramente destacado que contiene información de interés para usuarios concretos.

En los modelos CMMI, todas las extensiones que lleven el mismo nombre se pueden seleccionar opcionalmente para utilizarlas agrupadamente. En CMMI para Servicios, el área de proceso Desarrollo del Sistema de Servicio (SSD) es una extensión.

externalización (outsourcing)

Véase “adquisición”.

gestión cuantitativa (quantitative management)

Gestionar un proyecto o grupo de trabajo utilizando técnicas estadísticas y otra técnicas cuantitativas para entender el rendimiento o rendimiento predicho de los procesos en comparación con los objetivos de calidad y rendimiento de procesos del proyecto o grupo de trabajo, e identificar las acciones correctivas que pueda ser necesario realizar (véase también “técnicas estadísticas”).

Algunas técnicas estadísticas utilizadas para la gestión cuantitativa son: el análisis, creación o uso de modelos de rendimiento de procesos; el análisis, creación o uso de líneas base de rendimiento de procesos; el uso de diagramas de control; el análisis de varianza y análisis de regresión; y el uso de intervalos de confianza o intervalos de predicción, análisis de sensibilidad, simulaciones, y contrastes de hipótesis.

gestión de cambios (change management)

Uso sensato de medios para dar salida a los cambios, o cambios propuestos, en productos o servicios (véase también "gestión de configuración").

gestión de configuración (configuration management)

Disciplina que aplica dirección y vigilancia técnicas y administrativas a (1) identificar y documentar las características funcionales y físicas de los elementos de configuración, (2) controlar los cambios a esas características, (3) registrar y reportar el procesamiento de cambios y el estado de la implementación, y (4) verificar el cumplimiento de los requisitos especificados (véase también "auditoría de configuración", "control de configuración", "identificación de configuración" y "registro del estado de la configuración".

gestión de datos (data management)

Procesos y sistemas disciplinados para planificar, adquirir y administrar datos de negocio y técnicos, que son consistentes con los requisitos de datos a lo largo del ciclo de vida de los datos.

gestión de requisitos (requirements management)

Gestionar todos los requisitos recibidos o generados por el proyecto o grupo de trabajo, incluyendo tanto los requisitos técnicos como los no técnicos, así como aquellos requisitos impuestos al proyecto o grupo de trabajo por la organización (véase también “requisitos no técnicos”).


Glosario 517

gestión de riesgos (risk management)

Proceso organizado y analítico utilizado para identificar lo que podría causar daños o pérdidas (identificar riesgos); evaluar y cuantificar los riesgos identificados; y desarrollar, y en caso necesario implementar, enfoques apropiados para prevenir o gestionar las causas de aquellos riesgos que pudieran resultar en daños o pérdidas significativas.

Habitualmente, la gestión de riesgos se realiza para las actividades de un proyecto, grupo de trabajo, organización u otras unidades organizativas que desarrollen o proporcionen productos o servicios.

gestionado cuantitativamente (quantitatively managed)

Véase “gestión cuantitativa”.

grupo de procesos (process group)

Conjunto de especialistas que facilitan la definición, mantenimiento y mejora de los procesos utilizados por la organización.

grupo de trabajo (work group)

Conjunto gestionado de personas y otros recursos asignados que proporciona uno o más productos o servicios a un cliente o usuario final (véase también "proyecto").

Un grupo de trabajo puede ser cualquier entidad organizativa que tenga un propósito definido, tanto si aparece en el organigrama como si no. Los grupos de trabajo se pueden dar en cualquier nivel de la organización, pueden constar de otros grupos de trabajo, y pueden sobrepasar la frontera de la organización.

Un grupo de trabajo y su trabajo se podría considerar un proyecto si tiene un tiempo de vida limitado de forma intencionada.

guías de adaptación (tailoring guidelines)

Guías organizativas que permiten que los proyectos, grupos de trabajo, y funciones organizativas adapten apropiadamente los procesos estándar con objeto de utilizarlos.

El conjunto de procesos estándar de la organización se describe a un nivel general que puede no ser directamente utilizable para llevar a cabo el proceso.

Las guías de adaptación ayudan a quienes establecen el proceso definido para el proyecto o grupo de trabajo. Las guías de adaptación engloban (1) la selección del proceso estándar, (2) la selección de un modelo de ciclo de vida aprobado, y (3) la adaptación del proceso estándar y del modelo de ciclo de vida para ajustarlos a las necesidades del proyecto o grupo de trabajo. Las guías de adaptación describen qué se puede y qué no se puede modificar, e identifican los componentes de proceso que son candidatos a ser modificados.


Glosario 518

hallazgos (findings) Véase “hallazgos de la evaluación”.

hallazgos de la evaluación (appraisal findings)

Resultados de una evaluación que identifican las cuestiones, problemas y oportunidades de mejora de procesos que están dentro del alcance de la evaluación más importantes.

Los hallazgos de una evaluación son inferencias derivadas de evidencias objetivas corroboradas.

identificación de configuración (configuration identification)

Elemento de la gestión de configuración que consiste en seleccionar los elementos de configuración de un producto, asignarles identificadores únicos, y registrar sus características funcionales y físicas en documentos técnicos (véase también "elemento de configuración", "gestión de configuración" y "producto").

identificación de riesgos (risk identification)

Enfoque organizado y concienzudo que se utiliza para buscar riesgos en el logro de objetivos que sean probables o realistas.

incidencia en el servicio (service incident)

Indicación de una interferencia real o potencial en un servicio.

Las incidencias en el servicio pueden ocurrir en cualquier dominio de servicios, ya que las quejas de clientes y usuarios finales son tipos de incidencia, e incluso en los servicios más simples pueden generarse quejas.

Cuando el contexto deje claro su significado, la palabra "incidencia" se puede utilizar para abreviar en lugar de "incidencia en el servicio".

ingeniería de hardware (hardware engineering)

Aplicación de un enfoque sistemático, disciplinado y cuantitativo a la transformación de un juego de requisitos que representan las necesidades, expectativas y restricciones del conjunto de partes interesadas, con objeto de diseñar, implementar y mantener un producto tangible utilizando tecnología y técnicas documentadas (véase también "ingeniería de software" e "ingeniería de sistemas").

En CMMI, la ingeniería de hardware representa todos los campos técnicos (p. ej. eléctrico, mecánico) que transforman requisitos e ideas en productos tangibles.

ingeniería de sistemas (systems engineering)

Enfoque interdisciplinar que rige todo el esfuerzo técnico y de gestión que se requiere para para transformar un conjunto de necesidades, expectativas y restricciones de cliente en una solución, así como para dar soporte a dicha solución a lo largo de su vida (véase también “ingeniería de hardware” e “ingeniería de software”).

Este enfoque incluye definir medidas de prestaciones técnicas, integrar especialidades de ingeniería encaminadas a establecer una arquitectura, y definir procesos de soporte para el ciclo de vida que equilibren los objetivos de costes, plazos y prestaciones.


Glosario 519

ingeniería de software (software engineering)

(1) Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software. (2) Estudio de enfoques como en (1) (véase también “ingeniería de hardware” e “ingeniería de sistemas”).

institucionalización (institutionalization)

Forma arraigada de hacer el trabajo que una organización sigue rutinariamente como parte de su cultura corporativa.

gerente (manager) Persona que dirige y controla técnica y administrativamente a los que realizan las tareas o actividades que están dentro del área de responsabilidad del gerente.

Este término tiene un significado especial en el Conjunto de Productos CMMI además de su significado habitual. Las funciones tradicionales de un gerente incluyen planificar, organizar, dirigir, y controlar el trabajo dentro de un área de responsabilidad.

licitación (solicitation)

Proceso consistente en preparar el pliego que se va a utilizar para seleccionar a un suministrador (véase también “pliego de condiciones”).

límites naturales (natural bounds)

Rango de variación inherente de un proceso, según lo determinan medidas de rendimiento de procesos.

A veces, a los límites naturales se les llama "la voz del proceso".

Para determinar si la variación de un proceso se debe a causas comunes (es decir, el proceso es predecible o estable) o si se debe a alguna causa especial que puede y debería identificarse y eliminarse, se utilizan técnicas tales como diagramas de control, intervalos de confianza e intervalos de predicción (véase también "medida" y "rendimiento de procesos").

línea base (baseline) Conjunto de especificaciones o productos de trabajo que se ha revisado y acordado formalmente, los cuales, a partir de entonces, sirven como base para posteriores desarrollos y sólo pueden cambiarse mediante procedimientos de control de cambios (véase también “línea base de configuración” y “línea base de producto”).

línea base de configuración (configuration baseline)

Información de configuración designada formalmente en un momento determinado de la vida de un producto o componente de producto (véase también "ciclo de vida del producto")

Las líneas base de configuración junto con los cambios aprobados sobre esas líneas base constituyen la información de configuración actual.


Glosario 520

línea base de rendimiento de procesos (process performance baseline)

Caracterización del rendimiento de procesos documentada, la cual puede incluir tendencia central y variación (véase también "rendimiento de procesos").

Una línea base de rendimiento de procesos se puede utilizar como punto de referencia para comparar el rendimiento de procesos real con respecto al esperado.

línea base del producto (product baseline)

Paquete de datos técnicos aprobado inicialmente que define un elemento de configuración durante la producción, operación, mantenimiento, y soporte logístico de su ciclo de vida (véase también "elemento de configuración", "gestión de configuración" y "paquete de datos técnicos").

Este término está relacionado con la gestión de configuración.

línea de productos (product line)

Grupo de productos que comparten un conjunto de características comunes gestionadas que satisfacen necesidades específicas de una misión o mercado seleccionado y se desarrollan a partir de un conjunto común de activos fundamentales de una manera prescrita (véase también "línea de servicios").

El desarrollo o adquisición de productos para una línea de productos se basa en explotar lo que es común y limitar la variación (es decir, limitar las variaciones de producto innecesarias) dentro del grupo de productos. El conjunto gestionado de activos fundamentales (p. ej. requisitos, arquitectura, componentes, herramientas, artefactos de prueba, procedimientos operativos, software) incluye orientación prescriptiva sobre cómo utilizarlos para desarrollar productos. La operación de la línea de productos implica engranar la ejecución de actividades generales de desarrollo de activos fundamentales, desarrollo de productos y gestión.

Muchas personas utilizan “línea de productos” simplemente para referirse al conjunto de productos producidos por una unidad de negocio particular, se hayan o no construido a partir de activos compartidos. A ese conjunto lo llamamos “cartera” y reservamos “línea de productos” para el significado técnico proporcionado aquí.

línea de servicios (service line)

Conjunto consolidado y estandarizado de servicios y niveles de servicio que satisfacen necesidades específicas de un área seleccionada del mercado o la misión (véase también "línea de productos" y "nivel de servicio").

madurez organizativa (organizational maturity)

Grado en el que una organización ha desplegado explícita y consistentemente procesos que están documentados, gestionados, medidos y controlados, y que se mejoren continuamente.

La madurez organizativa puede medirse por medio de evaluaciones.


Glosario 521

Marco CMMI (CMMI Framework)

Estructura básica que organiza los componentes de CMMI, incluyendo los elementos de los modelos CMMI actuales, así como las reglas y métodos para generar modelos, los métodos de evaluación (incluyendo los artefactos asociados), y los materiales de capacitación (véase también “modelo CMMI” y “Conjunto de Productos CMMI”).

El marco posibilita añadir nuevas áreas de interés a CMMI de forma que se integren con las actuales.

marco de trabajo (framework)

Véase “Marco CMMI”.

medición (measurement)

Conjunto de operaciones que se realizan para determinar el valor de una medida (véase también “medida”).

La definición de este término en CMMI es consistente con la definición del término en ISO 15939.

medición de proceso (process measurement)

Conjunto de operaciones que se utilizan para determinar valores de medidas de un proceso y sus productos o servicios resultantes con el propósito de caracterizar y comprender el proceso (véase también “medición”).

medida (measure) Variable a la que se asigna el valor que resulta de una medición (véase también “medida base”, “medida derivada” y “medición”).

La definición de este término en CMMI es consistente con la definición del término en ISO 15939.

medida base (base measure)

Medida definida en términos de un atributo y del método para cuantificarlo (véase también “medida derivada”).

Las medidas base son funcionalmente independientes de las otras medidas.

medida de nivel de servicio (service level measure)

Medida de rendimiento en la prestación de servicios asociada a un nivel de servicio (véase también “medida” y “nivel de servicio”).

medida de prestaciones técnicas (technical performance measure)

Medida técnica de requisitos, capacidades o combinaciones de requisitos y capacidades definida con precisión (véase también “medida”).

medida derivada (derived measure)

Medida que se define como función de dos o más valores de medidas base (véase también "medida base").

mejora de procesos (process improvement)

Programa de actividades diseñado para mejorar el rendimiento y la madurez de los procesos de la organización, y resultados de dicho programa.


Glosario 522

mejoras de proceso y tecnológicas (process and technology improvements)

Mejoras incrementales e innovadoras en los procesos y en las tecnologías de proceso, producto, o servicio.

memorando de acuerdo (memorandum of agreement)

Documento vinculante de entendimiento o acuerdo entre dos o más partes.

Al memorando de acuerdo también se le llama "memorando de entendimiento".

meta específica (specific goal)

Componente requerido del modelo que describe características únicas que deben estar presentes para satisfacer el área de proceso (véase también “nivel de capacidad”, “meta genérica”, “objetivos de negocio de la organización” y “área de proceso”).

meta genérica (generic goal)

Componente requerido del modelo que describe las características que deben estar presentes para institucionalizar los procesos que implementan un área de proceso (véase también “institucionalización”).

modelo CMMI (CMMI model)

Modelo generado a partir del Marco CMMI (véase también “Marco CMMI” y “Conjunto de Productos CMMI”).

modelo de capacidad y madurez (capability maturity model)

Modelo que contiene los elementos esenciales para la eficacia en los procesos dentro de una o más áreas de interés y describe un camino de mejora evolutivo que va desde procesos inmaduros y ad hoc hasta procesos maduros y disciplinados con calidad y eficacia mejoradas.

modelo de ciclo de vida (lifecycle model)

División de la vida de un producto, servicio, proyecto, grupo de trabajo, o actividades en fases.

modelo de referencia (reference model)

Un modelo que se utiliza como punto de referencia para medir un atributo.

modelo de referencia de evaluación (appraisal reference model)

Modelo CMMI frente al que el equipo de evaluación establece correlaciones con las actividades de proceso implementadas.

Este término se utiliza en los materiales de evaluación de CMMI, tales como el SCAMPI MDD.


Glosario 523

modelo de rendimiento de procesos (process performance model)

Descripción de las relaciones que existen entre atributos medibles de uno o más procesos o productos de trabajo desarrolladas a partir de datos históricos de rendimiento de procesos y que se utilizan para predecir el rendimiento futuro (véase también “medida”).

Uno o más de estos atributos medibles representan entradas controlables ligadas a subprocesos que permiten realizar análisis de tipo "qué-pasa-si" para planificar, replanificar dinámicamente y resolver problemas. Los modelos de rendimiento de procesos incluyen modelos basados en estadística, probabilidad y simulación que predicen resultados intermedios o finales conectando el rendimiento pasado con los resultados futuros. Éstos modelan la variación de los factores y aportan conocimientos sobre el rango y la variación esperados en los resultados predichos. Un modelo de rendimiento de procesos puede ser una colección de modelos que (cuando se combinan) satisface los criterios de modelo de rendimiento de procesos.

modelo operativo (operational concept)

Descripción general de la forma en que se utiliza u opera una entidad.

Al modelo operativo también se le llama "modelo de operaciones”.

nivel de capacidad (capability level)

Logro de mejora de procesos dentro de un área de proceso individual (véase también "meta genérica", "meta específica", "nivel de madurez" y "área de proceso").

El nivel de capacidad se define por medio de las metas genéricas y específicas apropiadas para el área de proceso.

nivel de madurez (maturity level)

Nivel de mejora de procesos sobre un conjunto predefinido de áreas de proceso en el que todas las metas del conjunto se han alcanzado (véase también “nivel de capacidad” y “área de proceso”).

nivel de servicio (service level)

Magnitud, grado, o calidad definidos para el rendimiento en la prestación de servicios (véase también "servicio" y "medida de nivel de servicio).

nivel directivo (higher level management)

Persona o personas que establece las políticas y orientación global para el proceso pero que en el día a día directamente no lo monitoriza ni controla (véase también “directivo”).

Estas personas pertenecen a un nivel de gestión en la organización superior al de los inmediatamente responsables del proceso, y pueden ser (aunque no necesariamente) directivos.

objetivo cuantitativo (quantitative objective)

Objetivo para el valor deseado expresado utilizando medidas cuantitativas (véase también "medida", "objetivos de mejora de procesos" y "objetivos de calidad y rendimiento de procesos")


Glosario 524

objetivos de calidad y rendimiento de procesos (quality and process performance objectives)

Objetivos y requisitos cuantitativos para la calidad del producto, la calidad del servicio y el rendimiento de procesos.

objetivos de calidad y rendimiento del procesos (quality and process performance objectives)

Los objetivos cuantitativos de rendimiento de procesos incluyen la calidad; sin embargo, para enfatizar la importancia de la calidad en el Conjunto de Productos CMMI se utiliza la frase “objetivos de calidad y rendimiento de procesos”. Los “objetivos de rendimiento de procesos” se referencian en el nivel de madurez 3; el término “objetivos de calidad y rendimiento de procesos” implica el uso de datos cuantitativos y se utiliza únicamente en los niveles de madurez 4 y 5.

objetivos de mejora de procesos (process improvement objectives)

Conjunto de características deseadas establecidas para guiar la labor de mejora de un proceso existente de una forma específica, medible ya sea en términos de características del producto o servicio resultante (p. ej. calidad, prestaciones, cumplimiento de estándares), ya en términos de la manera en que se ejecuta el proceso (p. ej. eliminación de pasos de proceso redundantes, combinación de pasos de proceso, mejora del tiempo de ciclo) (Véase también "objetivos de negocio de la organización" y "objetivos cuantitativos").

objetivos de negocio (business objectives)

Véase “objetivos de negocio de la organización”.

objetivos de negocio de la organización (organization’s business objectives)

Objetivos desarrollados-por-la-dirección diseñados para asegurar la existencia continuada de la organización y aumentar su rentabilidad, cuota de mercado y otros factores que influyan en el éxito de la organización (véase también “objetivos de calidad y rendimiento de procesos” y “objetivo cuantitativo”).

organización (organization)

Estructura administrativa en la cual hay personas que colectivamente gestionan uno o más proyectos o grupos de trabajo como un todo, tienen un directivo en común, y operan bajo las mismas políticas.

Sin embargo, la palabra “organización” tal y como se utiliza en todos los modelos CMMI también se puede aplicar a una única persona de una organización pequeña que realice una función que en una organización mayor pudiera estar realizada por un grupo de personas (véase también "empresa").


Glosario 525

paquete de datos técnicos (technical data package)

Colección de elementos que, dependiendo de si la información es apropiada para el tipo de producto o componente de producto de que se trate (p. ej. los requisitos de materiales y de fabricación pueden no ser útiles para los componentes de producto asociados a procesos o servicios software), pueden incluir lo siguiente:

Descripción de la arquitectura de producto.

Requisitos asignados.

Descripciones de componente de producto.

Descripciones de procesos de ciclo de vida relacionadas con productos, si no están descritos mediante componentes de producto independientes.

Características clave del producto.

Características físicas requeridas y restricciones.

Requisitos de interfaz.

Requisitos de materiales (lista de materiales y características de los materiales).

Requisitos de fabricación y manufactura (tanto para el fabricante original como para el soporte sobre el terreno).

Criterios de verificación utilizados para asegurar que se han cumplido los requisitos.

Condiciones de uso (entornos) y escenarios de operación/uso, modos y estados para las operaciones, soporte, capacitación, fabricación, retirada, y verificaciones durante la vida del producto.

Justificación de las decisiones y características (p. ej. requisitos, asignaciones de requisitos, elecciones de diseño).

parámetros de rendimiento (performance parameters)

Medidas de eficacia y otras medidas clave que se utilizan para guiar y controlar el desarrollo progresivo.

parte interesada (stakeholder)

Grupo o individuo afectado por el resultado de un cometido o que es responsable del mismo de alguna manera (véase también “cliente” y “parte interesada relevante”).

Las partes interesadas pueden incluir a los miembros del proyecto o grupo de trabajo, suministradores, clientes, usuarios finales, entre otros.


parte interesada relevante (relevant stakeholder)

Parte interesada que ha sido identificada para involucrarla en determinadas actividades y se ha incluido en un plan (véase también “parte interesada”).


Glosario 526

participantes en la evaluación (appraisal participants)

Miembros de la unidad organizativa que participan en una evaluación proporcionando información.

perfil de logros (achievement profile)

Lista de áreas de proceso y sus niveles de capacidad correspondientes que representan el progreso de la organización en cada área de proceso a medida que avanza por los niveles de capacidad (véase también “perfil de nivel de capacidad”, “perfil de objetivos” y “secuenciación de objetivos”).

perfil de niveles de capacidad (capability level profile)

Lista de áreas de proceso y sus niveles de capacidad correspondientes (véase también “perfil de logros”, “perfil de objetivos” y “secuenciación de objetivos”).

Un perfil de niveles de capacidad puede ser un "perfil de logros" si representa el progreso de la organización en cada área de proceso a medida que avanza por los niveles de capacidad. O puede ser un "perfil de objetivos" si representa un objetivo para la mejora de procesos.

perfil de objetivos (target profile)

Lista de áreas de proceso y sus niveles de capacidad correspondientes que representan un objetivo para la mejora de procesos (véase también “perfil de logros” y “perfil de niveles de capacidad”).

Los perfiles de objetivos sólo están disponibles cuando se usa la representación continua.

petición de servicio (service request)

Comunicación de un cliente o usuario final indicando que se desea una o más instancias específicas de prestación de servicios (véase también “acuerdo de servicio”).

Estas peticiones se realizan dentro del contexto de un acuerdo de servicio.

En caso de que se vayan a prestar servicios continua o periódicamente, algunas peticiones de servicio podrían estar identificadas en el propio acuerdo de servicio.

En otros casos, las peticiones de servicio que entren dentro del alcance del acuerdo de servicio establecido previamente son generadas por los clientes o usuarios finales a medida que surgen sus necesidades.

plan de acciones de proceso (process action plan)

Plan, habitualmente resultado de evaluaciones, que documenta cómo se implementarán mejoras específicas para abordar debilidades detectadas durante una evaluación.

plan de mejora de procesos (process improvement plan)

Plan para lograr objetivos organizativos de mejora de procesos en base a entender en profundidad las fortalezas y debilidades actuales de los procesos y activos de proceso de la organización.


Glosario 527

plan de proyecto (project plan)

Plan que proporciona la base para realizar y controlar las actividades del proyecto, las cuales abordan los compromisos con el cliente del proyecto.

Planificar proyectos incluye estimar atributos de los productos de trabajo y tareas, determinar los recursos que se necesitan, negociar los compromisos, elaborar un cronograma, e identificar y analizar los riesgos del proyecto. Para establecer el plan de proyecto puede ser necesario realizar estas actividades de forma reiterada.

plan de trabajo (work plan)

Plan de actividades y asignaciones de recursos relacionadas para un grupo de trabajo.

Planificar el trabajo incluye estimar atributos de productos de trabajo y tareas, determinar los recursos que se necesitan, negociar compromisos, producir un cronograma, e identificar y analizar los riesgos. Para establecer un plan de trabajo puede ser necesario realizar estas actividades de forma reiterada.

pliego de condiciones (solicitation package)

Colección de documentos formales que incluye una descripción de la forma en que los suministradores potenciales deben responder, la declaración de trabajo relevante para el suministrador, y las disposiciones requeridas en el acuerdo de suministro.

política organizativa (organizational policy)

Principios rectores, habitualmente establecidos por la dirección, que una organización adopta para influir y determinar decisiones.

políticas (policy) Véase "política organizativa".

práctica específica (specific practice)

Componente esperado del modelo que se considera importante para conseguir la meta específica asociada (véase también “área de proceso” y “meta específica”).

Las prácticas específicas describen las actividades con las que se espera que se consiga una meta específica de un área de proceso.

práctica genérica (generic practice)

Componente esperado del modelo que se considera importante para alcanzar las metas genéricas asociadas.

Las prácticas genéricas asociadas a una meta genérica describen las actividades con las que se esperan que se consiga una meta genérica y que contribuyen a la institucionalización de los procesos asociados al área de proceso.

prestaciones técnicas (technical performance)

Característica del proceso, producto o servicio, generalmente definida por un requisito funcional o técnico.

Algunos ejemplos de tipos de prestaciones técnicas son la precisión al estimar, las funciones de usuario final, las funciones de seguridad, el tiempo de respuesta, la precisión de componentes, el peso máximo, la capacidad productiva mínima, el rango permisible.


Glosario 528

proceso (process) Conjunto de actividades interrelacionadas, que transforman entradas en salidas, para lograr un propósito determinado (véase también “área de proceso”, “subproceso” y “elemento de proceso”).

El término "el proceso" se utiliza de forma especial en las declaraciones y descripciones de las metas genéricas y prácticas genéricas. “El proceso”, tal y como se utiliza en la Segunda Parte, es el proceso o procesos que implementan el área de proceso.

Los términos “proceso”, “subproceso” y “elemento de proceso” forman una jerarquía en la que "proceso” es el de mayor nivel y más general, los "subprocesos” están por debajo, y "elemento de proceso” es el más específico. A un proceso concreto se le puede llamar subproceso si forma parte de otro proceso mayor. También se le puede llamar elemento de proceso si no se descompone en subprocesos.

Esta definición de proceso es consistente con la definición de proceso en ISO 9000, ISO 12207, ISO 15504 y EIA 731.

proceso capaz (capable process)

Proceso que puede satisfacer sus objetivos especificados de calidad del producto, calidad del servicio y rendimiento de procesos (véase también "proceso estable" y "proceso estándar")

proceso de evaluación formal (formal evaluation process)

Enfoque estructurado para evaluar soluciones alternativas con respecto a criterios establecidos con objeto de determinar la solución que se recomienda para abordar un problema.

proceso definido (defined process)

Proceso gestionado que se adapta a partir del conjunto de procesos estándar de la organización de acuerdo a las guías de adaptación de la organización; tiene una descripción de proceso que se mantiene; y contribuye a los activos de proceso organizativos con experiencias relacionadas con procesos (véase también “proceso gestionado”).

proceso estable (stable process)

Estado en el cual las causas especiales de variación de procesos se han eliminado y se ha evitado que reaparezcan, de forma que sólo quedan causas comunes de variación de procesos (véase también “proceso capaz”, “causa común de variación”, “causa especial de variación”, y “proceso estándar”).

proceso estándar (standard process)

Definición operativa del proceso básico que guía el establecimiento de un proceso común en una organización.

Un proceso estándar describe los elementos de proceso fundamentales que cualquier proceso definido debería incorporar. También describe las relaciones (p. ej., ordenación, interfaces) entre estos elementos de proceso (véase también “proceso definido”).


Glosario 529

proceso gestionado (managed process)

Proceso realizado que se planifica y ejecuta acorde a políticas; que emplea personas cualificadas que disponen de recursos adecuados para producir resultados controlados; que involucra a las partes interesadas relevantes; que se monitoriza, controla y revisa; y para el que se evalúa el cumplimiento de su descripción de proceso (véase también “proceso realizado”).

proceso incompleto (incomplete process)

Proceso que no se realiza o que sólo se realiza parcialmente; una o más metas específicas del área de proceso no se satisfacen.

A un proceso incompleto también se le llama de nivel de capacidad 0.

proceso planificado (planned process)

Proceso documentado por medio de una descripción y de un plan.

La descripción y el plan deberían estar coordinados, y el plan debería incluir estándares, requisitos, objetivos, recursos y asignaciones.

proceso realizado (performed process)

Proceso que logra que se lleve a cabo el trabajo que se necesita para producir productos de trabajo; se satisfacen las metas específicas del área de proceso.

procesos de ciclo de vida del producto (product related lifecycle processes)

Procesos asociados con un producto o servicio durante una o más fases de su vida (p. ej., desde su concepción hasta su retirada), tales como procesos de fabricación y soporte.

producto (product) Producto de trabajo que está previsto entregar al cliente o usuario final.

Este término tiene un significado especial en el Conjunto de Productos CMMI además de su significado habitual. La forma del producto puede variar dependiendo del contexto (véase también “cliente”, “componente de producto”, “servicio” y “producto de trabajo”).

producto de trabajo (work product)

Resultado útil de un proceso.

Este resultado puede incluir ficheros, documentos, productos, piezas del producto, servicios, descripciones de proceso, especificaciones y facturas. Una diferencia clave entre los productos de trabajo y los componentes de producto es que los productos de trabajo no forman parte necesariamente del producto final (véase también “producto” y “componente de producto”).

En los modelos CMMI, la definición de “producto de trabajo” incluye a los servicios; sin embargo, a veces se utiliza el término "productos de trabajo y servicios” para enfatizar que los servicios están incluidos en la discusión.

productos comerciales (commercial off-the-

Elementos que se pueden adquirir de un suministrador comercial.


Glosario 530

shelf)

progreso y rendimiento del proyecto (project progress and performance)

Lo que ha logrado el proyecto en lo que respecta a la implementación de los planes de proyecto, incluyendo esfuerzo, costes, plazos y prestaciones técnicas (véase también "prestaciones técnicas")

propietario del proceso (process owner)

Persona (o equipo) responsable de definir y mantener un proceso.

A nivel organizativo, el propietario del proceso es la persona (o equipo) responsable de describir el proceso estándar; a nivel de proyecto o grupo de trabajo, el propietario del proceso es la persona (o equipo) responsable de describir el proceso definido. Por tanto, un mismo proceso puede tener varios propietarios en distintos niveles de responsabilidad (véase también “proceso definido” y “proceso estándar”).

prototipo (prototype) Tipo, forma o instancia preliminar de un producto, servicio, componente de producto o componente de servicio, que sirve como modelo para etapas posteriores o para la versión completa del producto o servicio final.

Este modelo del producto o servicio (p. ej. físico, electrónico, digital, analítico) se puede utilizar para los siguientes propósitos (entre otros):

Evaluar la viabilidad de una tecnología nueva o con la que no se esté familiarizado.

Evaluar o mitigar riesgos técnicos.

Validar requisitos

Demostrar características críticas.

Cualificar un producto o servicio.

Cualificar un proceso.

Caracterizar el rendimiento o prestaciones del producto o servicio.

Esclarecer principios físicos.

proyecto (project) Conjunto gestionado de actividades y recursos interrelacionados, incluyendo personas, que proporciona uno o más productos o servicios a un cliente o usuario final.

Un proyecto tiene comienzo (es decir, el arranque del proyecto) y final previstos. Habitualmente los proyectos operan siguiendo un plan. Frecuentemente dicho plan está documentado y especifica qué es lo que se va a producir o implementar, los recursos y financiación que se van a utilizar, el trabajo que se va a realizar y los plazos para realizarlo. Un proyecto puede estar compuesto de proyectos (véase también “arranque del proyecto”).

En algunos contextos, para referirse a un proyecto se utiliza el término “programa”.


Glosario 531

pruebas de aceptación (acceptance testing)

Pruebas formales realizadas para posibilitar que un usuario, cliente u otra entidad autorizada determine si un entregable se acepta o no (véase también “pruebas unitarias”).

pruebas unitarias (unit testing)

Probar unidades de hardware o software individuales o grupos de unidades relacionadas (véase también “pruebas de aceptación”).

recabado de requisitos (requirements elicitation)

Utilizar técnicas sistemáticas, tales como prototipos o encuestas estructuradas, para identificar y documentar de manera proactiva las necesidades de clientes y usuarios finales.

registro del estado de la configuración (configuration status accounting)

Elemento de la gestión de configuración que consiste en registrar y reportar la información que se necesita para gestionar una configuración eficazmente (véase también “identificación de configuración” y “gestión de configuración”).

Esta información incluye una lista con la configuración aprobada, el estado de los cambios propuestos a la configuración, y el estado de implementación de los cambios aprobados.

rendimiento de procesos (process performance)

Medida de los resultados que se obtienen al seguir un proceso (véase también “medida”)

El rendimiento de procesos se caracteriza tanto por medidas de proceso (p. ej. esfuerzo, tiempo de ciclo, eficiencia en la eliminación de defectos) como por medidas de producto o de servicio (por ejemplo, fiabilidad, densidad de defectos, tiempo de respuesta).

repositorio de mediciones de la organización (organization’s measurement repository)

Repositorio utilizado para recoger resultados de mediciones de procesos y productos de trabajo y hacerlos disponibles, concretamente por su relación con el conjunto de procesos estándar de la organización.

Este repositorio contiene o hace referencia a resultados de medición reales y a la información relacionada que se necesita para entender y analizar los resultados de medición.

representación (representation)

Organización, uso, y presentación de los componentes de un CMM.

En general, hay dos tipos de enfoque evidentes para presentar buenas prácticas: la representación por etapas y la representación continua.

representación continua (continuous representation)

Estructura del modelo de capacidad y madurez, en la que los niveles de capacidad proporcionan el orden recomendado para abordar la mejora de procesos dentro de cada área de proceso específica (véase también “nivel de capacidad”, “área de proceso” y “representación por etapas”).


Glosario 532

representación por etapas (staged representation)

Estructura del modelo en la que alcanzar las metas de un conjunto de áreas de proceso establece un nivel de madurez; cada nivel construye una base para los niveles siguientes (véase también “nivel de madurez” y “área de proceso”).

requisito (requirement)

(1) Una condición o capacidad que el usuario necesitada para solucionar un problema o lograr un objetivo. (2) Condición o capacidad que el producto, servicio, componente de producto o componente de servicio debe cumplir o tener para satisfacer un acuerdo de suministro, estándar, especificación u otros documentos formalmente impuestos. (3) Representación de una condición o capacidad como en (1) o en (2) documentada (véase también “acuerdo de suministro).

requisito asignado (allocated requirement)

Requisito que resulta al asignar a un elemento de arquitectura o componente de diseño de menor nivel todo o parte de un requisito de nivel superior.

De forma más general, los requisitos se pueden asignar a otros componentes lógicos o físicos, incluyendo personas, consumibles, entregas incrementales, o la arquitectura como un todo, dependiendo de lo que mejor posibilite que el producto o servicio cumpla los requisitos.

requisito de cliente (customer requirement)

Resultado de recabar, consolidar y resolver, de una forma que sea aceptable para el cliente, los conflictos entre las necesidades, expectativas, restricciones e interfaces de las partes interesadas relevantes para el producto, (véase también “cliente”).

requisitos contractuales (contractual requirements)

Resultado de analizar y refinar los requisitos de cliente para convertirlos en un conjunto de requisitos que se pueda incluir en uno o más pliegos de condiciones o acuerdos de suministro (véase también "adquiriente", "requisito de cliente", "acuerdo de suministro", y "pliego de condiciones").

Los requisitos contractuales incluyen los requisitos, tanto técnicos como no técnicos, que son necesarios para adquirir productos o servicios.

requisitos de componente de producto (product component requirements)

Especificación completa de un componente de producto o servicio, incluyendo su ajuste, forma, función, rendimiento y cualquier otro requisito.


Glosario 533

requisitos de producto (product requirements)

Refinamiento, utilizando el lenguaje de los desarrolladores, de los requisitos de cliente, transformando requisitos implícitos en requisitos derivados explícitos (véase también “requisitos derivados” y “requisitos de componente de producto”).

El desarrollador utiliza los requisitos de producto para guiar el diseño y la construcción del producto o servicio.

requisitos del servicio (service requirements)

Conjunto completo de requisitos que afectan a la prestación de servicios y al desarrollo del sistema de servicio (véase también “sistema de servicio”).

Los requisitos del servicio incluyen requisitos tanto técnicos como no técnicos. Los requisitos técnicos son características del servicio a prestar y del sistema de servicio que se necesita para posibilitar la prestación. Los requisitos no técnicos pueden incluir condiciones, disposiciones, compromisos y términos adicionales identificados en acuerdos y regulaciones, así como las capacidades y condiciones que se necesitan, derivadas de los objetivos de negocio.

requisitos derivados (derived requirements)

Requisitos que, sin estar establecidos explícitamente, se infieren a partir de los requisitos de cliente, (1) por requisitos contextuales (p. ej. estándares, regulaciones, políticas, prácticas comunes y decisiones de gestión aplicables) o (2) por requisitos que se necesiten para especificar un componente de producto o servicio.

Los requisitos derivados también pueden surgir durante el análisis y diseño de los componentes de producto o servicio (véase también “requisitos de producto”).

requisitos no técnicos (nontechnical requirements)

Requisitos que afectan a la adquisición o desarrollo de productos o servicios y no son propiedades de los productos o servicios.

Algunos ejemplos son cantidades de productos o servicios que hay que proporcionar, derechos sobre datos para los COTS y los elementos no desarrollados que se entregan, fechas de entrega e hitos con criterios de salida. Las restricciones del trabajo asociadas a plazos de capacitación, provisión de ubicaciones, y despliegue son otros requisitos no técnicos.

requisitos técnicos (technical requirements)

Propiedades (es decir, atributos) de los productos o servicios que se van a adquirir o desarrollar.

resultado de medición (measurement result)

Valor que se determina realizando una medición (véase también “medición”).

retorno de la inversión (return on investment)

Ratio entre los beneficios obtenidos (productos o servicios) y los costes de producción, el cual determina si una organización obtiene o no beneficios cuando realiza una acción para producir algo.


Glosario 534

revisión de diseño (design review)

Examen formal, documentado, exhaustivo y sistemático de un diseño con objeto de determinar si el diseño cumple los requisitos aplicables, identificar problemas, y proponer soluciones.

revisión entre pares (peer review)

Revisión de productos de trabajo realizada entre pares durante el desarrollo de productos de trabajo con objeto de identificar defectos a eliminar (véase también “producto de trabajo”).

En el Conjunto de Productos CMMI, el término “revisión entre pares” se utiliza en lugar del término “inspección de producto de trabajo”.

secuenciación de objetivos (target staging)

Secuencia de perfiles de objetivos que describe el camino de mejora de procesos a seguir por la organización (véase también “perfil de logros”, “perfil de niveles de capacidad” y “perfil de objetivos”).

La secuenciación de objetivos sólo está disponible cuando se utiliza la representación continua.

representación equivalente (equivalent staging)

Secuenciación de objetivos, creada utilizando la representación continua, que se define de tal forma que permite comparar los resultados de utilizar la secuenciación de objetivos con los niveles de madurez de la representación por etapas (véase también “perfil de niveles de capacidad”, “nivel de madurez”, “perfil de objetivos” y “secuenciación de objetivos”).

Una secuenciación así permite hacer comparativas entre organizaciones, empresas, proyectos y grupos de trabajo, sin importar la representación de CMMI que utilicen. La organización puede implementar componentes del modelo CMMI más allá de los que se reporten en la representación equivalente. La representación equivalente describe la forma en que una organización se compara con otras organizaciones en términos de niveles de madurez.

servicio (service) Producto que es intangible y no almacenable (véase también "producto", "cliente" y "producto de trabajo").

Los servicios se proporcionan utilizando sistemas de servicio que han sido diseñados para satisfacer los requisitos de servicio (véase también “sistema de servicio”).

Muchos proveedores de servicios proporcionan combinaciones de servicios y bienes. Un único sistema de servicio podría proporcionar ambos tipos de productos. Por ejemplo, una organización de capacitación podría proporcionar materiales de capacitación junto con sus servicios de capacitación.

Los servicios se pueden proporcionarse combinando procesos manuales y automatizados.



Glosario 535

sistema de servicio (service system)

Combinación integrada e interdependiente de los recursos que lo componen que satisface los requisitos del servicio (véase también “componente de sistema de servicio” y “requisitos del servicio”).

Un sistema de servicio engloba todo lo que se necesita para la prestación de servicios, incluyendo productos de trabajo, procesos, instalaciones, herramientas, consumibles y recursos humanos.

Obsérvese que el sistema de servicio incluye a las personas que se necesitan para realizar los procesos del sistema de servicio. En contextos en los que haya usuarios finales que realicen parte de los procesos que se necesitan para la prestación de servicios, dichos usuarios finales también formarían parte del sistema de servicio (al menos durante dichas interacciones).

Un sistema de servicio complejo podría dividirse en varios sistemas o subsistemas de prestación y soporte. Aunque para la organización proveedora de servicios estas divisiones y distinciones puedan ser significativas, para otras partes interesadas podrían no ser tan significativas.

sistema de sistemas (system of systems)

Conjunto o disposición de sistemas que resulta al integrar sistemas que son útiles e independientes formando un sistema mayor que proporciona capacidades únicas.

soporte (sustainment)

Procesos utilizados para asegurar que un producto o servicio permanece operativo.

subpráctica (subpractice)

Componente informativo del modelo que proporciona orientación para interpretar e implementar las prácticas específicas o genéricas.

Las subprácticas pueden estar redactadas como si fuesen preceptivas, pero realmente sólo se pretende dar ideas que puedan ser útiles para la mejora de procesos.

subproceso (subprocess)

Proceso que forma parte de un proceso mayor (véase también “proceso”, “descripción de proceso” y “elemento de proceso”).

Un subproceso puede descomponerse o no en subprocesos o elementos de proceso de mayor granularidad. Los términos “proceso”, “subproceso” y “elemento de proceso” forman una jerarquía en la que "proceso” es el de mayor nivel y más general, los "subprocesos” están por debajo, y "elemento de proceso” es el más específico. A un subproceso también se le puede llamar elemento de proceso si no se descompone en subprocesos adicionales.


Glosario 536

suministrador (supplier)

(1) Entidad que proporciona productos o realiza servicios que están siendo adquiridos. (2) Individuo, sociedad, compañía, corporación, asociación u otra entidad que tiene un acuerdo con un adquiriente para diseñar, desarrollar, fabricar, mantener, modificar o suministrar elementos conforme a los términos de un acuerdo (véase también “adquiriente”).

técnicas estadísticas (statistical techniques)

Técnicas adaptadas a partir del campo de la estadística matemática utilizadas para actividades tales como caracterizar el rendimiento de procesos, entender la variación de procesos, y predecir resultados.

Las técnicas de muestreo, el análisis de varianza, los contrastes chi-cuadrado, y los diagramas de control de proceso son algunos ejemplos de técnicas estadísticas.

técnicas estadísticas y otras técnicas cuantitativas (statistical and other quantitative techniques)

Técnicas analíticas que permiten llevar a cabo una actividad cuantificando parámetros de la tarea (p. ej., entradas, tamaño, esfuerzo y rendimiento. Véase también “técnicas estadísticas” y “gestión cuantitativa”).

Este término se utiliza en las áreas de proceso de alta madurez en las que se describe el uso de técnicas estadísticas y otras técnicas cuantitativas para mejorar el entendimiento de los procesos de los proyectos, los trabajos y organizativos.

El análisis de tendencias, las gráficas de comportamiento, el análisis de Pareto, los diagramas de barras, los diagramas radar y la promediación de datos son algunos ejemplos de técnicas cuantitativas no estadísticas.

El motivo de utilizar el término compuesto “técnicas estadísticas y otras técnicas cuantitativas” en CMMI es el de reconocer que, además de las técnicas estadísticas cuya utilización se espera, hay otras técnicas cuantitativas que también se pueden utilizar eficazmente.

trazabilidad (traceability)

Asociación discernible entre dos o más entidades lógicas, tales como requisitos, elementos de sistema, verificaciones o tareas (véase también “trazabilidad bidireccional” y “trazabilidad de requisitos”).

trazabilidad bidireccional (bidirectional traceability)

Asociación discernible en ambos sentidos (es decir, hacia y desde una entidad) entre dos o más entidades lógicas (véase también “trazabilidad de requisitos” y “trazabilidad”).

trazabilidad de requisitos (requirements traceability)

Asociación discernible entre los requisitos y requisitos relacionados, implementaciones y verificaciones (véase también “trazabilidad bidireccional” y “trazabilidad”).


Glosario 537

usuario final (end user)

Parte que en último término utiliza el producto entregado o recibe el beneficio del servicio prestado (véase también “cliente”).

Los usuarios finales pueden o no además ser clientes (que pueden establecer y aceptar acuerdos o autorizar pagos).

En contextos en los que un único acuerdo de servicio cubra varias prestaciones de servicios, puede considerarse usuario final a cualquier parte que inicie peticiones de servicio (véase también “acuerdo de servicio” y “petición de servicio”).

validación (validation)

Confirmar que el producto o servicio, tal y como se ha proporcionado (o se va a proporcionar), cumplirá su uso pretendido.

En otras palabras, la validación asegura que se “construyó lo correcto” (véase también "verificación”).

verificación (verification)

Confirmar que los productos de trabajo reflejan adecuadamente los requisitos que se han especificado para ellos.

En otras palabras, la verificación asegura que “se construyó correctamente” (véase también “validación”).

visión compartida (shared vision)

Entendimiento compartido de los principios rectores, incluyendo la misión, los objetivos, el comportamiento esperado, los valores y los resultados finales, los cuales se desarrollan y utilizan por un proyecto o grupo de trabajo.


Glosario 538