Iso 20000-2 - Norma Chilena 2012 (Con Notas)

PROYECTO DE NORMA EN CONSULTA PUBLICA - prNCh-ISO 20000/2
Tecnologa de la informacin - Gestin del servicio - Parte 2 - Orientacin sobre la aplicacin de los sistemas
de gestin del servicio
Prembulo
El Instituto Nacional de Normalizacin, INN, es el organismo que tiene a su cargo el estudio y preparacin de las
normas tcnicas a nivel nacional. Es miembro de la INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION (ISO) y de la COMISION PANAMERICANA DE NORMAS TECNICAS (COPANT),
representando a Chile ante esos organismos.
Este proyecto de norma ha sido estudiado por el Comit Informtica, para proporcionar orientaciones sobre la
aplicacin de un SGS basado en ISO/IEC 20000-1, adems de ejemplos y sugerencias para permitirle a las
organizaciones interpretar y aplicar ISO/IEC 20000-1, incluyendo referencias a otras partes de ISO/IEC 20000 y
otras normas pertinentes.
Este proyecto de norma es idntico a la versin en ingls de la Norma Internacional ISO/IEC 20000-2:2012(E)
Information technology - Service management - Part 2: Guidance on the application of service management
systems.
Para los propsitos de este proyecto de norma, se han realizado los cambios editoriales que se indican y
justifican en Anexo C.
La Nota Explicativa incluida en un recuadro en clusula 2 Referencias normativas y Anexo B, Bibliografa, es

un cambio editorial que se incluye con el propsito de informar la correspondencia con Norma Chilena de las
Normas Internacionales citadas en este proyecto de norma.
Los Anexos A, B, C no forman parte del proyecto de norma, se insertan slo a ttulo informativo.
Si bien se ha tomado todo el cuidado razonable en la preparacin y revisin de los documentos normativos
producto de la presente comercializacin, INN no garantiza que el contenido del documento es actualizado o
exacto o que el documento ser adecuado para los fines esperados por el Cliente.
En la medida permitida por la legislacin aplicable, el INN no es responsable de ningn dao directo,
indirecto, punitivo, incidental, especial, consecuencial o cualquier dao que surja o est conectado con el uso
o el uso indebido de este documento.
Vencimiento consulta pblica: 2013.01.25 I

Tecnologa de la informacin - Gestin del servicio - Parte 2 - Orientacin sobre la aplicacin de los sistemas
de gestin del servicio
0 Introduccin
Esta norma proporciona orientaciones sobre la aplicacin de los sistemas de gestin del servicio (SGS) basados
en ISO/IEC 20000-1. Esta norma no agrega ningn requisito a aquellos establecidos en ISO/IEC 20000-1 y no
establece explcitamente como se puede proporcionar evidencia a un asesor o auditor. La intencin de esta
norma es permitirle a las organizaciones y personas interpretar ISO/IEC 20000-1, ms exactamente, y por lo
tanto usarla ms eficazmente.
En ISO/IEC 20000-1 se define un SGS como un sistema de gestin para dirigir, monitorear y controlar las
actividades de gestin del servicio del proveedor del servicio. El SGS debera incluir lo que se requiere para la
planificacin, diseo, transicin, prestacin y mejoramiento de los servicios. Como mnimo esto incluye
polticas, objetivos, planes, procesos, interfaces de procesos, documentacin y recursos de la gestin del servicio.
El SGS abarca todos los procesos como un sistema de gestin general, con los procesos de gestin del servicio
como parte del SGS.
La integracin e implementacin coordinada de un SGS proporciona control continuo, una mayor eficacia,
eficiencia y oportunidades para el mejoramiento continuo. Le permite a una organizacin trabajar eficientemente
con una visin compartida. La operacin de procesos segn se especifica en clusulas 5 a 9 requiere que el
personal est bien organizado y coordinado. Se pueden utilizar herramientas apropiadas para permitirle a los
procesos de gestin del servicio que sean eficaces y eficientes. Las organizaciones ms eficaces consideran el
impacto del SGS a travs de todas las etapas del ciclo de vida del servicio, desde la planificacin y diseo hasta
la transicin y operacin, incluyendo el mejoramiento continuo.
Esta norma proporciona ejemplos y sugerencias para permitirle a las organizaciones interpretar y aplicar
ISO/IEC 20000-1, incluyendo referencias a otras partes de ISO/IEC 20000 y otras normas pertinentes.
Los usuarios de normas internacionales son responsables de su correcta aplicacin. Es importante para las
organizaciones y personas utilizar ISO/IEC 20000 para comprender los puntos que se listan a continuacin:
- ISO/IEC 20000-1 no pretende incluir todos los requisitos estatutarios y reglamentarios, o todas las
obligaciones contractuales del proveedor del servicio. La conformidad con ISO/IEC 20000-1 no confiere
por s misma inmunidad de las obligaciones estatutarias.
- ISO/IEC 20000-1 es aplicable a proveedores de servicios internos y externos, grandes y pequeos, y

comerciales y no comerciales.
- ISO/IEC 20000-1 fomenta la adopcin de un enfoque de procesos integrados cuando se planifica,

establece, implementa, opera, monitorea, mide, revisa, mantiene y mejora un SGS para el diseo,
transicin, mejoramiento y prestacin de servicios que cumplan los requisitos del servicio.
Vencimiento consulta pblica: 2013.01.25 1

ISO/IEC 20000 fomenta la aplicacin de la metodologa conocida como Planificar-Hacer-Verificar-Actuar

(PHVA) al SGS y a los servicios. La metodologa PHVA, que se muestra en Figura 1, se puede describir
brevemente como sigue:
Planificar: establecer, documentar y acordar el SGS incluyendo las polticas, objetivos, planes y procesos
necesarios para disear y prestar servicios de acuerdo con las necesidades del negocio, los requisitos del
cliente y las polticas del proveedor del servicio.
Hacer: implementar y operar el SGS para el diseo, transicin, prestacin y mejoramiento de los servicios.
Verificar: monitorear, medir y revisar el SGS y los servicios frente a los planes, polticas, objetivos y
requisitos e informar los resultados.
Actuar: tomar acciones para mejorar continuamente el desempeo del SGS. Esto incluye los procesos de
gestin del servicio y los servicios.
Cuando se utiliza dentro de un SGS, los aspectos ms importantes de un enfoque de procesos integrados y de
la metodologa PHVA son los siguientes:
a) comprender y cumplir los requisitos del servicio para lograr la satisfaccin del cliente;
b) establecer la poltica y objetivos para la gestin del servicio;
c) disear y prestar servicios basados en el SGS que agreguen valor para el cliente;
d) monitorear, medir y revisar el desempeo del SGS y de los servicios;
e) mejorar continuamente el SGS y los servicios basados en las mediciones de los objetivos.
Cuando estn presentes otros sistemas de gestin, la implementacin de un SGS, con la adopcin de un
enfoque de procesos y la metodologa PHVA, le permite al proveedor del servicio alinear o integrar
completamente los sistemas de gestin de la organizacin. Por ejemplo, es posible integrar ISO/IEC 20000
con un sistema de gestin de la calidad en base a ISO 9001 y/o un sistema de gestin de la seguridad de la
informacin en base a ISO/IEC 27001. Un enfoque de sistema de gestin integrado aumenta la eficiencia,
establece la rendicin de cuentas y trazabilidad claras y mejora la planificacin, comunicacin y control
organizacional.
Figura 1 - Metodologa PHVA aplicada a la gestin del servicio

Como se indica en ISO/IEC 20000-1:
ISO/IEC 20000 puede ser utilizada por:
a) una organizacin que busca servicios de proveedores de servicios y requiere asegurarse que se cumplirn
sus requisitos del servicio;
b) una organizacin que requiere un enfoque consistente por todos sus proveedores de servicios, incluyendo
aquellos en una cadena de suministro;
c) el proveedor del servicio que intenta demostrar su capacidad para el diseo, transicin, prestacin y
mejoramiento de los servicios que cumplen los requisitos del servicio;
d) un proveedor del servicio para monitorear, medir y revisar sus procesos de gestin del servicio y los
servicios;
e) un proveedor del servicio para mejorar el diseo, transicin, prestacin y mejoramiento de los servicios a
travs de la implementacin y operacin efectiva del SGS;
f) un asesor segn los criterios para una evaluacin de la conformidad de un SGS del proveedor del servicio
para los requisitos de esta norma.
Esta norma puede ser utilizada por una organizacin en busca de orientacin sobre cmo mejorar la gestin del
servicio, est o no interesada en obtener la certificacin.
1 Alcance y campo de aplicacin
1.1 Generalidades
Esta norma proporciona orientaciones sobre la aplicacin de un SGS basado en ISO/IEC 20000-1. Esta norma
proporciona ejemplos y sugerencias para permitirle a las organizaciones interpretar y aplicar ISO/IEC 20000-
1, incluyendo referencias a otras partes de ISO/IEC 20000 y otras normas pertinentes. Esta norma es
independiente de marcos de trabajo especficos de mejores prcticas y el proveedor del servicio puede aplicar
una combinacin de orientaciones generalmente aceptadas y sus propias tcnicas.
La Figura 2 muestra en la caja central los procesos desde clusulas 6 a 9. La clusula 5 diseo y transicin de
procesos de servicios nuevos o modificados que rodean los procesos de clusulas 6 a 9. Esto muestra que los
servicios nuevos o modificados son operados por los procesos en la caja central. Cuando no hay servicios nuevos
o modificados a los cuales aplique clusula 5, todos los servicios se pueden prestar directamente mediante las
clusulas 6 a 9.
Las interfaces entre los procesos de gestin del servicio y las relaciones entre los distintos componentes del SGS
se pueden implementar de manera diferente por distintos proveedores de servicios. La naturaleza de la relacin
entre el proveedor del servicio y el cliente tambin puede influenciar como el SGS se implementa para cumplir
los requisitos de ISO/IEC 20000-1. Por estas razones en Figura 2 no se representan las interfaces entre procesos.

Figura 2 - Sistema de gestin del servicio
1.2 Aplicacin
El proveedor del servicio es responsable del SGS y por lo tanto no le puede pedir a otra parte que cumpla los
requisitos de Clausula 4 de ISO/IEC 20000-1:2011. Por ejemplo, el proveedor del servicio no puede pedir a otra
parte que proporcione la alta gerencia y demuestre el compromiso de la alta gerencia o demuestre la gobernanza
de procesos operados por otras partes.
Algunas actividades en Clausula 4 pueden ser realizadas por otra parte bajo la gestin del proveedor del servicio.
Por ejemplo, los proveedores de servicios pueden involucrar a otras partes para llevar a cabo auditoras internas
en su nombre. Otro ejemplo es cuando un proveedor de servicio le pide a otra parte crear el plan de gestin del
servicio inicial. El plan una vez creado y acordado, es de responsabilidad directa de, y es mantenido por, el
proveedor del servicio. En estos ejemplos, el proveedor del servicio utiliza a otras partes para actividades de
corto plazo especficas. El proveedor del servicio tiene la autoridad, responsabilidad y debe rendir cuentas por el
SGS. El proveedor del servicio puede por lo tanto demostrar evidencia del cumplimiento de todos los requisitos
de clusula 4 de IEC/IESO 20000-1:2011.
El proveedor del servicio puede mostrar evidencia del cumplimiento de todos los requisitos directamente o
puede mostrar evidencia del cumplimiento de la mayora de los requisitos directamente como as tambin la
gobernanza de procesos operados por otras partes. Si el proveedor del servicio depende de otras partes para la
operacin de la mayora de los procesos en clusulas 5 a 9, el proveedor del servicio es poco probable que pueda
demostrar gobernanza de los procesos. Sin embargo, si otras partes operan slo una minora de los procesos, el
proveedor del servicio puede cumplir normalmente los requisitos especificados en ISO/IEC 20000-1.
La rendicin de cuentas, autoridades y responsabilidades por el SGS definidas, acordadas y documentadas son
fcilmente accesibles tanto para el proveedor del servicio como para otras partes pertinentes. Para cumplir los
requisitos de ISO/IEC 20000-1 el proveedor del servicio puede acordar cambios en los trminos de los contratos
existentes u otros acuerdos documentados.
ISO/IEC 20000 excluye la especificacin de, u orientaciones especficas sobre, cualquier producto o
herramienta. Sin embargo, las organizaciones pueden utilizar esta norma para ayudarles a utilizar o desarrollar
productos o herramientas que apoyen la operacin del SGS.
2 Referencias normativas
El documento siguiente es indispensable para la aplicacin de esta norma. Para referencias con fecha, slo se
aplica la edicin citada. Para referencias sin fecha se aplica la ltima edicin del documento referenciado
(incluyendo cualquier enmienda).
ISO/IEC 20000-1 Information technology - Service management - Part 1: Service management system
requirements.
NOTA EXPLICATIVA NACIONAL
La equivalencia de las Normas Internacionales sealadas anteriormente con Norma Chilena, y su grado de correspondencia es el siguiente:
Norma Internacional Norma nacional Grado de correspondencia
ISO/IEC 20000-1 En estudio -
3 Trminos y definiciones
Para los propsitos de esta norma, se aplican los trminos y definiciones dados en ISO/IEC 20000-1.
4 Requisitos generales del sistema de gestin del servicio
4.1 Responsabilidad de la gerencia
4.1.1 Compromiso de la gerencia
4.1.1.1 Responsabilidades de la alta gerencia
La alta gerencia debera ser la instancia que dirige, monitorea y controla el proveedor del servicio al ms alto
nivel.
La alta gerencia debera ser consciente que cumplir los requisitos de ISO/IEC 20000-1 incluye:
a) demostrar su compromiso de involucrarse en todas las etapas del SGS, comenzando con la planificacin y
establecimiento del SGS y continuando a travs de la operacin, monitoreo, medicin, revisin,
mantenimiento y mejoramiento continuo del SGS;
b) demostrar su rendicin de cuentas y responsabilidades por el SGS;
c) asegurar que los requisitos del servicio, alcance del SGS, poltica y objetivos de gestin del servicio son
comprendidos y reconocidos por todas las partes interesadas del SGS;
d) asegurar que el plan de gestin del servicio se crea, implementa. mantiene y alinea con los objetivos del
negocio;
e) asegurar la provisin de recursos adecuados para cumplir los objetivos de gestin del servicio y para
adherirse a la poltica de gestin del servicio;
f) asegurar que el desempeo del SGS se informa a nivel de la alta gerencia;
g) lograr los objetivos de gestin del servicio, incluyendo cuando stos varan debido a cambiantes
necesidades del negocio o requisitos del servicio;

h) asegurar que los riesgos para el servicio se minimizan, por ejemplo, mediante la evaluacin de riesgos
asociados con cambios y tomando acciones.
La alta gerencia tambin debera asegurar que todas las etapas del ciclo de vida se prestan a los niveles
acordados, segn se define en los requisitos del servicio. El ciclo de vida del servicio incluye la planificacin,
implementacin, operacin, monitoreo, medicin, revisin, mantenimiento y mejoramiento continuo. El ciclo de
vida del servicio tambin incluye la transferencia del servicio a un cliente o a una parte diferente o eliminacin
eventual del servicio.
La alta gerencia debera estar conscientes que ellos son responsables de asegurar que el SGS y los servicios
prestados mediante el SGS son evaluados y examinados. Las evaluaciones deberan incluir las propias revisiones
y auditoras internas del proveedor del servicio, como as tambin las auditoras externas. En 4.5 se puede
encontrar ms informacin acerca de revisiones por la gerencia.
4.1.1.2 Evidencia del compromiso de la alta gerencia
Sin el compromiso de la gerencia, es posible que las decisiones de gestin entren en conflicto con requisitos para
un SGS eficaz. Ejemplos pueden incluir reasignacin de recursos para otros proyectos, falta de comunicacin
sobre el SGS y conflictos no resueltos en el proceso de diseo.
Debera haber evidencia disponible de la rendicin de cuentas y del compromiso de la gerencia para su revisin
por un asesor. La alta gerencia debera ser capaz de proveer evidencia en base a registros de su involucramiento:
a) reuniones regulares sobre el SGS, por ejemplo, presidir las reuniones de planificacin de forma que el SGS
permanezca alineado con las necesidades del negocio y los requisitos del servicio nuevos o modificados;
b) asegurar que el SGS incluya una definicin del alcance, la poltica de gestin del servicio, los objetivos de
gestin del servicio y el plan de gestin del servicio;
c) aprobacin de la poltica de gestin del servicio, los objetivos de gestin del servicio y el plan de gestin del
servicio;
d) aprobacin de los procesos y procedimientos consistentes con, y de apoyo a, las polticas del SGS.
La aprobacin del plan de gestin del servicio por la alta gerencia es importante porque el plan puede tener
implicancias para los compromisos con el cliente, actividades de planificacin para los proveedores y la
asignacin de recursos para mejoramientos y otros cambios.
La alineacin entre polticas, procesos y procedimientos permite que las indicaciones de la alta gerencia sean en
cascada para todo el personal del proveedor del servicio. Esto debera alinear las decisiones de la gerencia con la
forma de operar del personal del proveedor del servicio en el da a da.
4.1.1.3 Comunicaciones de la alta gerencia
La alta gerencia debera estar activamente involucrada en un programa continuo de comunicaciones. La

comunicaciones se deberan dirigir mediante procedimientos de comunicaciones aprobados segn se describe en
4.1.3.2.
La alta gerencia debera estar activamente involucrada en un programa continuo de comunicaciones para
explicar cmo el SGS establecido est alineado con los objetivos del negocio y las expectativas del cliente. Esto
es importante para el xito del SGS porque el personal que comprende el propsito e importancia del SGS es
menos propenso a resistir los cambios debido al miedo o falta de conocimientos. Las comunicaciones de la alta
gerencia sobre el SGS pueden ser una oportunidad para el proveedor del servicio para motivar a su propia
organizacin. Adicionalmente, una apreciacin de la importancia del SGS tanto por la gerencia como por el
personal, debera reducir el riesgo o probabilidad que las decisiones que se tomen o soluciones prestadas estn en
contradiccin con el SGS.
El programa de comunicaciones debera explicar lo siguiente:
a) cambios, polticas, normas, visin y misin organizacionales como as tambin las metas del negocio;
b) necesidades del negocio, por ejemplo, la relacin entre el SGS y los servicios prestados, como as tambin
cmo stos apoyan al logro de las metas y objetivos organizacionales definidos;
c) cmo el SGS establecido est alineado con los objetivos del negocio y las expectativas del cliente;
d) cmo la poltica de gestin del servicio, los objetivos de gestin del servicio y el plan de gestin del servicio
apoyan el cumplimiento de los requisitos del servicio;
e) requisitos del cliente, por ejemplo, metas del servicio, capacidad prevista en base a la demanda prevista,
informacin de seguridad y continuidad del servicio para apoyar la continuidad del negocio;
f) requisitos estatutario, tales como horas de trabajo, salud y seguridad y proteccin de los datos, que varan
segn el pas;
g) requisitos reglamentarios, por ejemplo, que los registros se mantengan por un periodo de tiempo especfico;
h) requisitos contractuales, por ejemplo, un requisito para firmar un acuerdo de no divulgacin antes de tener
acceso a la informacin del proveedor del servicio;
i) acuerdos documentados con el cliente;
j) anlisis regular de los datos obtenidos a travs de las mediciones del SGS y componentes, por ejemplo,
mediciones de los procesos.
Adicionalmente, las comunicaciones pueden ser una oportunidad para el proveedor del servicio para motivar a su
propia organizacin.
Un programa de comunicaciones es importante para el xito del SGS porque el personal que comprende el
propsito e importancia del SGS es menos propenso a resistir los cambios debido al miedo o falta de
conocimientos. Las comunicaciones deberan generar una apreciacin de la importancia del SGS tanto por la
gerencia como por el personal y reducir el riesgo o probabilidad que las decisiones que se tomen o soluciones
prestadas estn en contradiccin con el SGS.
El resultado de estas actividades de comunicaciones debera ser que las personas comprendan su rol en la gestin
del servicio y como ellos contribuyen al cumplimiento de los requisitos del servicio y al cumplimientos de los
objetivos de gestin del servicio.
4.1.1.4 Objetivos de gestin del servicio
La alta gerencia debera definir los objetivos acordados para la gestin del servicio. Los objetivos deberan estar
alineados con los objetivos del negocio y con la poltica de gestin del servicio.
Por ejemplo, objetivos de gestin del servicio genricos pueden incluir lo siguiente:
a) permitir mayor agilidad en los negocios a travs de una prestacin rpida de servicios nuevos o
modificados;
b) reducir la no disponibilidad imprevista para los servicios crticos del negocio;
c) optimizar el costo de los servicios prestados a travs de eficiencia operativa;

d) aumentar la calidad de los servicios mientras se reduce el riesgo.
Los objetivos de gestin reales se deberan definir de modo que los logros frente a los objetivos se puedan medir
exactamente. La medicin tambin debera permitir oportunidades para que el mejoramiento sea una prioridad.
Los objetivos deberan ser un insumo clave en el plan de gestin del servicio. El plan debera identificar acciones
para el logro de los objetivos y alineacin con otros componentes del SGS.
Los objetivos de gestin del servicio se deberan revisar a intervalos regulares para permitirle a la alta gerencia
decidir cmo y cundo stos deben ser revisados.
El proveedor del servicio debera asegurar que la eficacia de cada componente del SGS se mide para evaluar la
eficacia del apoyo para los objetivos de gestin del servicio. Por ejemplo, la medicin de la eficacia del apoyo de
los objetivos mediante un proceso especfico. Las mediciones tambin deberan demostrar el valor del SGS en el
apoyo a los objetivos del negocio.
El proveedor del servicio puede encontrar til medir las contribuciones de las personas hacia el logro de los
objetivos. Esto facilitar que el personal apoye el SGS para trabajar de una forma integrada hacia las mismas
metas.
4.1.1.5 Plan de gestin del servicio
El plan de gestin del servicio debera facilitar la coordinacin de todas las iniciativas del SGS para asegurar el
logro de los objetivos de gestin del servicio. El plan y las polticas tambin se deberan alinear.
El plan debera ser un mecanismo potente para permitir un control y visibilidad de extremo a extremo. Tambin
debera prevenir iniciativas incompatibles de ser aprobadas o implementadas. El plan debera permitir que la
utilizacin de los recursos y capacidades sea tan eficiente y eficaz como sea posible.
El plan se debera comunicar a todas las partes interesadas Esto debera asegurar un entendimiento comn del
alcance de las iniciativas, las tareas, plazos y responsabilidades asignadas. Las responsabilidades asignadas se
deberan incluir en las mediciones del desempeo de todos los involucrados en el SGS, incluidos aquellos
involucrados en iniciativas del plan de gestin del servicio.
No se debera considerar que el plan est completo cuando el SGS est implementado. Debera existir
indefinidamente mediante su modificacin para adaptarse a las necesidades cambiantes del negocio, requisitos
del cliente o prioridades del proveedor del servicio.
El plan de gestin del servicio puede consistir de un nico plan o un programa de cambios coordinados
gestionados centralmente con algunos cambios implementados localmente.
El proveedor del servicio debera siempre ser consciente de la necesidad de mantener todos los cambios
localmente bajo la gestin global del plan de gestin del servicio. Por ejemplo, un mejoramiento para un proceso
se puede llevar a cabo localmente, bajo el control local del dueo del proceso, pero ste se incluye en el
programa global gestionado centralmente.
Los planes para un propsito especfico, por ejemplo, para el proceso de gestin de la continuidad y
disponibilidad del servicio, se puede referenciar al plan de gestin global del servicio en vez de incluirlo dentro
de ste. Los planes especializados y su alineacin con el plan global se deberan revisar con una frecuencia que
sea adecuada para la tasa de cambio. Esta debera ser al menos anualmente.
Cualquier cambio resultante de revisiones o cambios en los requisitos del servicio o planes particulares, se
debera documentar en el plan de gestin global del servicio. Por ejemplo, el cambio de horas de oficina a 24
horas completas de operacin, reemplazo de la tecnologa o cambios en las habilidades.
Los contenidos del plan de gestin del servicio debera incluir:

a) una introduccin;
b) una descripcin de las funciones organizacionales del proveedor del servicio;
c) prioridades de iniciativas;
d) resultados esperados alineados a objetivos del negocio;
e) medidas del desempeo;
f) metas del servicio;
g) planes del proyecto;
h) tareas y dependencias;
i) obtencin de beneficios logrados como resultado de mejoramientos implementados con anterioridad;
j) riesgos y opciones de mitigacin de riesgo.
Se deberan identificar los riesgos para el plan de gestin del servicio, evaluados y gestionados inicialmente y
como parte de la metodologa PHVA. La evaluacin del riesgo debera cubrir las entradas, las salidas, las
actividades y la responsabilidad y rendicin de cuentas para la mitigacin de riesgos. El plan tambin se debera
disear para asegurar que los objetivos acordados y los requisitos del servicio sean logrados.
4.1.1.6 Recursos para apoyar el plan de gestin del servicio
Los recursos necesarios para lograr los objetivos de gestin del servicio se deberan documentar en el plan de
gestin del servicio. Se debera considerar lo siguiente:
a) recursos humanos deberan tomar en cuenta las habilidades y experiencia de las personas y no slo basarse
nicamente en el nmero de personas;
b) recursos tcnicos, por ejemplo, infraestructura y capacidad para lograr el desempeo requerido;
c) herramientas para apoyar los procesos del SGS;
d) capacidad de las oficinas, otras instalaciones e instalaciones para la continuidad del servicio;
e) datos e informacin, por ejemplo, detalles de los requisitos del cliente, planes de negocio del cliente, las
necesidades del negocio del proveedor del servicio, polticas de gestin del servicio, mediciones de
desempeo y otros informes;
f) recursos financieros, presupuestado con un nivel de detalle adecuado para gestionar la planificacin,
implementacin, operacin y mejoramiento del SGS;
g) calidad y disponibilidad del personal del proveedor del servicio, y sus horas trabajadas;
h) procesos, procedimientos y plazos para la introduccin, retencin y planificacin de la sucesin del personal
debidamente calificado.
4.1.1.7 Contenidos de los requisitos del servicio

En 3.34 de ISO/IEC 20000-1 se incluyen las necesidades del negocio, los clientes y los usuarios del servicio y
las necesidades del proveedor del servicio en la definicin de los requisitos del servicio. La alta gerencia debera
ser responsable de asegurar que los servicios prestados cumplen los requisitos del servicio acordados.
Tanto los requisitos del cliente como las necesidades del negocio se deberan documentar, monitorear, revisar y
gestionar para asegurar la continua alineacin con servicios nuevos o modificados como as tambin con
servicios en el entorno real.
Los requisitos del servicio deberan incluir las metas del servicio solicitado y las expectativas de la calidad. Las
necesidades del proveedor del servicio deberan incluir detalles de las necesidades de recursos y capacidades.
Los requisitos del servicio son una entrada al SGS, que se muestra en Figura 2.
Ejemplos de requisitos del servicio pueden incluir:
a) un servicio en uso, incluyendo los requisitos del nivel de servicio;
b) criterios de calidad para el diseo de servicios nuevos o modificados;
c) prioridades de la criticidad del negocio de servicios;
d) requisitos de disponibilidad;
e) requisitos reglamentarios;
f) requisitos de seguridad de la informacin.
4.1.1.8 El rol de la alta gerencia para acordar y cumplir con los requisitos del servicio
La alta gerencia debera asegurar que los requisitos del servicio se definen en trminos de:
a) resultados deseados que los clientes esperan, por ejemplo, eficacia, eficiencia, satisfaccin mejorada;
b) las limitaciones que el servicio eliminar;
c) funcionalidad de un servicio desde la perspectiva del cliente, incluyendo las necesidades de los usuarios del
servicio, a menudo denominada adecuacin para su propsito;
d) patrones de la actividad del negocio y demanda que el servicio debera soportar;
e) aseguramiento de que el servicio y los productos sern proporcionados o que cumplirn ciertas
especificaciones acordadas, a menudo denominada como garanta.
Una caracterstica tpica de garanta es que sta se define en trminos de la continuidad, disponibilidad,
capacidad y seguridad del servicio. Por ejemplo, la garanta asegura que el servicio seguir siendo adecuado para
su propsito, incluso en los niveles de servicio degradados debido a las interrupciones o desastres importantes.
La garanta tambin debera asegurar la seguridad de los servicios.
Las necesidades de los usuarios del servicio se deberan definir dentro del contexto de las necesidades del
cliente. Esto debera describir el beneficio que recibir un usuario al utilizar el servicio como parte del
desempeo de sus actividades laborales. Ejemplos son los siguientes:
EJEMPLO 1 - Eliminar las restricciones. Un cambio deseado para un servicio puede permitirle a los usuarios
acceder a un servicio de forma remota en lugar de slo a partir de ubicaciones fijas.
EJEMPLO 2 Funcionalidad. Un mejoramiento deseado en el tiempo de procesamiento de las transacciones del

negocio.
EJEMPLO 3 - Desempeo. Un usuario puede necesitar procesar una transaccin de compra por minuto y 50
transacciones en una hora.
4.1.1.9 Necesidades del proveedor del servicio
Desde el punto de vista del proveedor del servicio, los requisitos del servicio deberan incluir aquellos que se
listan a continuacin:
a) Requisitos para asegurar la prestacin para las necesidades del negocio e intereses ms amplios de la
organizacin que posee la organizacin del proveedor del servicio. Por ejemplo, los requisitos para cumplir
polticas, normas, requisitos estatutarios y reglamentarios, y obligaciones contractuales.
b) Alcance del SGS para dirigir, monitorear y controlar un conjunto integrado de actividades y procesos de
gestin del servicio. Esto incluye los requisitos para los activos, capacidades y recursos necesarios para el
diseo, transicin, prestacin y mejoramiento de los servicios. Por ejemplo, las unidades organizacionales,
personas, procesos, informacin y tecnologa necesaria para apoyar el SGS.
c) Limitaciones conocidas del SGS, por ejemplo limitaciones de recursos humanos, tcnicos, de informacin y
financieros.
d) Requisitos para la medicin, auditora, presentacin de informes y mejoramiento de los servicios prestados
frente a los objetivos definidos del negocio.
e) Requisitos para la medicin, auditora, presentacin de informes y mejoramiento de la eficacia del SGS.
4.1.1.10 Requisitos conflictivos
Si el proveedor del servicio establece que ha ocurrido un conflicto en los requisitos, se deberan tomar acciones.
Ejemplos de conflictos en los requisitos incluyen los siguientes:
a) Si hay conflictos entre los requisitos del cliente y las necesidades del negocio del cliente, el conflicto lo
debera resolver el cliente, por ejemplo, un requisito del cliente que est en conflicto con la gerencia
estratgica del negocio. Alternativamente, el proveedor del servicio puede analizar las diferencias y
proponer requisitos del servicio revisados.
b) Pueden ocurrir conflictos entre los requisitos del cliente y las necesidades del negocio propias del proveedor
del servicio cuando los requisitos del cliente no son realistas en trminos de prioridades, costos o fondos
disponibles. La naturaleza del conflicto y el por qu los requisitos no son realistas se le debera comunicar
claramente al cliente.
c) Los requisitos del servicio en conflicto con los requisitos estatutarios o reglamentarias, o las obligaciones
contractuales deberan ser resuelto. Por ejemplo, la distribucin de software puede ser restringida por un
acuerdo de licencia de una forma no compatible con los requisitos del cliente para el acceso a nuevas
versiones de software.
El proveedor del servicio debera asegurar que cualquier riesgo que surja de los conflictos son evaluados y
cuantificados a fin de identificar mtodos de minimizacin de riesgos. La evaluacin debera incluir el riesgo
para la satisfaccin del cliente y la habilidad para cumplir los objetivos y requisitos del cliente.
Los conflictos y su potencial impacto se deberan documentar y discutir con el cliente de modo que se puedan
resolver. Si se identifica un conflicto despus del diseo del servicio acordado, el conflicto se debera resolver
segn una accin correctiva o como una oportunidad de mejoramiento.
4.1.1.11 Riesgos para el servicio

La alta gerencia debera asegurar que los riesgos para el SGS y los servicios se identifican, documentan y
evalan. Los riesgos para un servicio pueden incluir incumplimiento de requisitos estatutarios y reglamentarios u
obligaciones contractuales. Por ejemplo, incumplimiento de requisitos de licencia de software o imposibilidad de
presentar pruebas de integridad financiera.
La alta gerencia tambin debera asegurar que se gestionan todos los riesgos identificados, incluso asegurando
que:
a) se desarrollan y documentan opciones para gestionar los riesgos identificados;
b) las opciones preferidas son acordadas con el cliente;
c) las opciones para la mitigacin de riesgos se implementan cuando es necesario.
NOTA - El proveedor del servicio encontrar una ayuda en los requisitos y recomendaciones de ISO 31000
sobre gestin del riesgo.
4.1.2 Poltica de gestin del servicio
4.1.2.1 Directrices para la poltica de gestin del servicio
La poltica de gestin del servicio debera ser especfica para las circunstancias del proveedor del servicio y tener
una orientacin al cliente. La poltica no debera ser declaracin genrica de aplicacin general. En lugar de eso,
la poltica debera reflejar las circunstancias y objetivos del proveedor del servicio.
La poltica se debera basar en el alcance acordado del SGS y por lo tanto de apoyo a los objetivos de gestin del
servicio y al plan de gestin del servicio del proveedor del servicio.
La poltica debera representar la orientacin de la alta gerencia y el compromiso para cumplir los requisitos del
servicio. La poltica tambin debera asegurar el cumplimiento de los requisitos para el diseo y transicin del
proceso de servicio nuevo o modificado de clusula 5 de ISO/IEC 20000-1:2011.
La poltica debera dar una orientacin clara de la alta gerencia a los gerentes y al personal del proveedor del
servicio.
EJEMPLO 1 - Los servicios estn alineados con los objetivos del negocio del cliente.
EJEMPLO 2 - Los cambios en los procesos o procedimientos slo se hacen a travs del proceso de gestin del
cambio.
EJEMPLO 3 - Los roles y las responsabilidades para los procesos de gestin del servicio se definen y
documentan de una forma consistente y el desempeo del personal se mide frente al logro de aquellas
responsabilidades.
La poltica de gestin del servicio se debera estructurar de modo que sta se pueda utilizar para evaluar si los
objetivos de gestin del servicio del proveedor del servicio se estn cumpliendo. Por ejemplo, debera ser posible
demostrar un vnculo entre la poltica de gestin del servicio y lo que se est haciendo para lograr los objetivos
de gestin del servicio del proveedor del servicio. La poltica de gestin del servicio se debera estructurar para
permitir la medicin de la adhesin a la poltica.
El proveedor del servicio tambin debera ser capaz de demostrar que este vnculo entre los objetivos del
proveedor del servicio y la poltica de gestin del servicio ha sido eficaz desde que la poltica de gestin del
servicio fue originalmente acordada.

La poltica de gestin del servicio debera definir claramente niveles de autoridad, por ejemplo, lo que hace
posible determinar si una iniciativa de mejoramiento debera ser aprobada por el dueo de un proceso particular
o por la alta gerencia.
La poltica de gestin del servicio se debera comunicar y comprender dentro de la propia organizacin del
proveedor del servicio. La poltica de gestin del servicio tambin puede estar disponible para el cliente y los
proveedores segn se requiera. Las referencias a la poltica que es discutida, comprendida y utilizada
apropiadamente, se puede utilizar como evidencia del cumplimiento de este requisito. Por ejemplo, minutas de
reunin, encuestas al personal, contratos con proveedores, acuerdos con subcontratistas, solicitudes de cambio a
la poltica o solicitudes de aclaracin, impacto de la poltica en los procesos, procedimientos y comportamientos
durante las operaciones normales y no planificadas, encuestas al cliente, encuestas al proveedor.
La alta gerencia tambin debera ser responsable de asegurar que la poltica de gestin del servicio se examine a
intervalos apropiados, al menos anualmente. Esto debera identificar cualquier deficiencia y asegurar una
alineacin continua con las necesidades del negocio y los requisitos del cliente. Los criterios de calidad aplicados
durante la revisin de la poltica de gestin del servicio debera tomar en consideracin lo siguiente:
a) la validez de la poltica frente a los requisitos del servicio;
b) la adecuacin de la frecuencia de revisin;
c) la alineacin entre la poltica y los objetivos de gestin del servicio;
d) la alineacin entre la poltica y el plan de gestin del servicio;
e) la alineacin entre la poltica y los procesos de gestin del servicio;
f) si la revisin es documentada, aprobada, sometida a monitoreo, apropiada y practicable;
g) la adecuacin del marco de trabajo para establecer, implementar, operar, monitorear, revisar, mantener y
mejorar el SGS;
h) acciones de remediacin y mejoramiento identificadas en revisiones y auditoras anteriores del SGS.
4.1.2.2 Mejoramientos y otros cambios a la poltica
Tras una revisin de la poltica de gestin del servicio, si se detecta una deficiencia, la alta gerencia debera
asegurar que esto se corrige. La deficiencias se deberan corregir ya sea con un cambio a la poltica, a los
objetivos de gestin del servicio, al plan, a los procesos o a los procedimientos.
La poltica tambin se debera actualizar para reflejar cualquier cambio a los objetivos de gestin del servicio o
al alcance del SGS.
4.1.3 Autoridad, responsabilidad y comunicacin
4.1.3.1 Autoridad y responsabilidad
El proveedor del servicio debera asegurar que las autoridades y responsabilidades por todos los aspectos del
SGS estn definidos. La descripcin de roles se deberan acordar, asignar a personas, comunicar a todo el
personal y mantener al da a travs de un procedimiento de gestin documentado. El proveedor del servicio
debera asegurar que todo el personal est incentivado a establecer y mantener una conciencia de cmo sus
actividades contribuyen al logro de los objetivos de gestin del servicio.
4.1.3.2 Procedimientos de comunicacin

La alta gerencia debera ser responsable de asegurar que los procedimientos de comunicacin se disean,
transfieren, implementan y utilizan. La alta gerencia puede delegar el diseo real de los procedimientos. Sin
embargo, sta debera aprobarlos antes de la implementacin y hacer cumplir su uso. La alta gerencia se debera
involucrar activamente en los procedimientos de comunicacin.
La alta gerencia debera comprender el valor de la conciencia, motivacin y participacin del personal en la
gestin eficaz del servicio y el mejoramiento continuo. Los procedimientos de comunicacin deberan incentivar
la motivacin del personal. Por ejemplo, comunicar los resultados exitosos de la participacin del personal en las
actividades de mejoramiento, puede tener un efecto motivacional significativo.
Los procedimientos de comunicacin deberan cubrir como mnimo el mtodo de prestacin, el tiempo y/o
frecuencia y el pblico. Los procedimientos tambin deberan cubrir mecanismos de escalada, detalles de
contacto, mantenimiento de la lista de distribucin, mtodos de comunicacin, herramientas y acceso a la
informacin, programas y responsabilidades.
Los procedimientos de comunicacin deberan incluir lo siguiente:
a) el mtodo de prestacin;
b) el tiempo y la frecuencia;
c) el pblico de comunicaciones especficas;
d) mecanismos de escalada;
e) detalles de contacto del pblico de la comunicacin;
f) mantenimiento de la lista de distribucin;
g) mtodos de comunicacin;
h) herramientas y acceso a la informacin;
i) programas y responsabilidades.
La comunicacin puede adoptar varias formas y depende de la cultura o de la organizacin, la persona que se
comunica y el rol de sta en la organizacin.
Los mtodos de comunicacin de la alta gerencia pueden incluir material de orientacin para el personal,
sesiones informativas y talleres, publicaciones del personal interno, email, medios de comunicacin social, o
foros de retroalimentacin de personal.
4.1.4 Representante de la gerencia
4.1.4.1 Comprensin de las responsabilidades
El representante de la gerencia debera ser un miembro del equipo de gerencia del proveedor del servicio que
tenga la autoridad para asegurar que el SGS se establece, utiliza, mejora con el tiempo y alinea con las
necesidades cambiantes del negocio. Esta autoridad debera incluir asegurar que los procesos de gestin del
servicio tienen las interfaces apropiadas entre s y estn integrados con el resto del SGS.
El proveedor del servicio debera asegurar de que est claro quin es el representante de la gerencia y que los
niveles de autoridad y responsabilidades del representante de la gerencia son comprendidos por:
a) dueos de proceso, quienes tienen la autoridad y responsabilidad por asegurar que el proceso, sus interfaces
a otros procesos e integracin dentro del SGS se documentan, adhieren a, miden y mejoran;
b) dueos de servicio, quienes tienen la autoridad y responsabilidad por un servicio a lo largo de su ciclo de
vida, incluyendo diseo, transicin, implementacin, mejoramiento, y retiro;
c) otro personal del proveedor del servicio;
d) grupos internos;
e) proveedores, incluyendo los proveedores principales;
f) el cliente.
NOTA - Para ejemplos sobre interfaces entre procesos de gestin de servicio e integracin con otros
componentes del SGS, consulte Anexo A.
4.1.4.2 Responsabilidades
El representante de la gerencia debera ser responsable de asegurar que se logra lo siguiente:
a) todos los aspectos de las responsabilidades de gestin especificadas en ISO/IEC 20000-1 se realizan,
incluyendo aquellas solicitadas por la alta gerencia;
b) se documentan los requisitos del servicio;
c) el SGS y la definicin del alcance cumplen las propias necesidades del proveedor del servicio, las
necesidades del cliente y de los usuarios de los servicios;
d) el alcance y los detalles del SGS se verifican a intervalos adecuados para asegurar que los requisitos del
servicio se siguen cumpliendo, por ejemplo, si las necesidades del cliente cambian, es posible que el SGS o
el alcance del SGS tambin necesita cambiar;
e) los objetivos y la poltica de gestin del servicio se utilizan como la base para decisiones durante la
planificacin inicial de los procesos para el diseo de los procesos y operacin y el mejoramiento de los
procesos;
f) el diseo de los procesos comienza con la identificacin de las entradas y salidas y cualquier otra actividad
realizada como parte de los procesos;
g) la poltica y objetivos dictan los criterios para priorizar los mejoramientos para los procesos de gestin del
servicio;
h) los procesos de gestin del servicio tienen interfaces apropiadas y efectivas una con la otra y se integran con
el resto del SGS;
i) la metodologa PHVA se implementa y utiliza para el mejoramiento continuo del SGS y los servicios;
j) las auditoras internas y evaluaciones del SGS se llevan a cabo a intervalos regulares, con el fin de medir la
capacidad del SGS para lograr los objetivos de gestin del servicio y para cumplir los requisitos del
servicio.
4.1.4.3 Gestin de activo
La alta gerencia debera ser consciente que ISO/IEC 20000-1 requiere que todos los activos utilizados para
prestar servicios se gestionan de acuerdo a requisitos estatutarios, reglamentarios y financieros pertinentes y
obligaciones contractuales. Los activos se deberan gestionar mediante procedimientos eficaces.

Ejemplos de activos que se deberan gestionar incluyen licencias de software, dispositivos mviles, componentes
de la infraestructura, personas, contratos, procedimientos y otros documentos. Los proveedores de servicios
deberan ser capaces de identificar exactamente la ubicacin, estado y otros detalles pertinentes sobre los activos.
La alta gerencia debera ser consciente que la gestin de os activos requiere una base de datos de la gestin de la
configuracin (CMDB) exacta, o medios equivalentes para el mantenimiento de registros, que se establezca y
utilice eficazmente. La informacin en la base de datos se debera mantener al da mediante procesos de gestin
del servicio eficaces, por ejemplo, los cambios en la CMDB se aprueban va el proceso de gestin del cambio.
Los requisitos estatutarios pueden incluir leyes de privacidad y proteccin de datos como as tambin leyes de
propiedad intelectual y derechos de autor. Otros requisitos estatutarios se pueden relacionar a la proteccin del
acctivos de informacin al cliente o proteccin de la informacin financiera.
requisitos reglamentarios y obligaciones contractuales pueden incluir asegurar que los activos cumplan con las
normas y requisitos de licencia del negocio, por ejemplo, normas de seguridad para la encriptacin de
informacin confidencial en computadores porttiles.
NOTA - El proveedor del servicio encontrar til la serie ISO/IEC 19770 sobre gestin de activos de software.
4.1.4.4 Presentacin de informes por el representante de la gerencia
Los informes a la alta gerencia deberan incluir pero no limitarse a los tpicos de 4.1.4.2. Por ejemplo, los
informes deberan identificar oportunidades de mejoramiento continuo obtenidas utilizando la metodologa
PHVA. Esto se debera basar en informes del desempeo del SGS y los servicios.
La frecuencia y nivel de detalle de los informes debera ser adecuado para el nivel de actividad, categoras de
cambio y seriedad de los asuntos y riesgos identificados por el representante de la gerencia. Se deberan
proporcionar alternativas de cambios para corregir las deficiencias y ayudar a la priorizacin de acciones y la
posterior decisin por parte de la alta gerencia.
Los informes a la alta gerencia deberan articular claramente el valor prestado por el SGS en apoyo a los
objetivos del negocio.
4.2 Gobernanza de los procesos operados por otras partes
4.2.1 Orientacin sobre procesos operados por otras partes
El proveedor del servicio debera ser consciente que puede cumplir los requisitos de ISO/IEC 20000-1 mediante
la demostracin de gobernanza de los procesos operados por otras partes, para una minora de los procesos.
El proveedor del servicio debera ser capaz de identificar todos los procesos de gestin del servicio o partes de
los procesos que son operados por otras partes. El proveedor del servicio debera tener visibilidad de extremo a
extremo del desempeo de otras partes que operan alguno de los procesos de clusulas 5 a 9.
El proveedor del servicio debera ser capaz de demostrar que controla todas las partes que operan procesos en el
SGS, lo que se debera apoyar en todos los contratos y otros acuerdos documentados.
4.2.2 Otras partes
Otras partes incluyen:
a) grupos internos que son unidades organizacionales dentro de la misma organizacin como el proveedor del
servicio, pero no dentro del control directo del proveedor del servicio, por ejemplo, un centro de datos o un
equipo de seguridad especializado;

b) un cliente que acta como proveedor, por ejemplo, el cliente realiza alguna de las actividades de gestin del
incidente y solicitudes de servicio;
c) proveedores, por ejemplo, contratacin externa de los ensayos realizados como parte de los procesos de
gestin de la entrega y despliegue.
Los proveedores tambin pueden ser los proveedores principales con la responsabilidad de gestionar proveedores
subcontratados.
4.2.3 Demostracin de la rendicin de cuentas y autoridad
El proveedor del servicio debera demostrar el proceso de rendicin de cuentas y autoridad mediante la entrega
de evidencia como la que se describe a continuacin:
a) La rendicin de cuentas del proveedor del servicio por la eficacia de los procesos de gestin del servicio
operados por el proveedor del servicio u otra parte, por ejemplo, la matriz de los encargados de la toma de
decisiones, prueba de niveles de autorizacin dentro de la propia organizacin del proveedor del servicio.
b) Que el proveedor del servicio tiene la facultad de exigir el cumplimiento de un proceso. Por ejemplo,
establecer la poltica de seguridad de la informacin, utilizar controles, detectar brechas e iniciar acciones
correctivas. Otro ejemplo incluye proporcionar evidencia que las prcticas han sido cambiadas a solicitud
del proveedor del servicio.
c) Anlisis de los registros del proceso, incluyendo las mediciones por el proveedor del servicio. Por ejemplo,
considerando un conjunto completo de registros de incidentes o un informe de incidente y tomar decisiones
en base al contenido, an si los registros de incidentes son proporcionados por otra parte que opera el
proceso de gestin del incidente.
d) Control de la definicin de todos los procesos del SGS, incluyendo los procesos de clusulas 5 a 9 operados
por otras partes. Esto incluye las interfaces entre cada proceso. Por ejemplo, documentar, acordar y operar
las interfaces y dependencias del proceso de gestin del cambio con el proceso de gestin de la
configuracin. En 4.2.4 se proporcionan ms detalles adicionales.
e) Control de la planificacin y establecimiento de prioridades para el mejoramiento de todos los procesos de

clusulas 4 a 9 de ISO/IEC 20000-1:2011. Por ejemplo, evaluar y priorizar un mejoramiento en el proceso
de gestin de la capacidad, an si el proceso lo opera otra parte.
El proveedor del servicio puede solicitar a otras partes que operen procesos diseados y documentados por el
proveedor del servicio. Alternativamente, el proveedor del servicio puede aprobar los procesos que las otras
partes disean, documentan y operan.
El proveedor del servicio debera ser consciente que si depende de otras partes para la operacin de la mayora
de sus procesos, es poco probable que sea posible demostrar adecuada gobernanza de los procesos.
NOTA - En ISO/IEC TR 20000-3:2009 se describe la gobernanza de los procesos operados por otras partes.
4.2.4 Desempeo y cumplimiento del proceso
El proveedor del servicio debera asegurar cada proceso descrito en clusulas 5 a 9 proporciona los resultados
deseados y contribuye a cumplir los objetivos de gestin del servicio.
La gobernanza de los procesos operados por otras partes debera incluir una definicin del proceso, que incluya:
a) identificacin de la propiedad del proceso, por ejemplo, qu grupo o gerente es responsable dentro de la
organizacin del proveedor del servicio es responsable por el proceso;

b) responsabilidad por la operacin, por ejemplo, qu grupo o gerente es responsable de la operacin del
proceso;
c) el objetivo del proceso, los resultados del proceso y la contribucin a los requisitos del servicio y a los
objetivos de gestin del servicio que estn siendo cumplidos;
d) entradas y salidas del proceso y qu parte las genera;
e) definicin de las interfaces con otros procesos, incluyendo los procesos de gestin del servicio, por ejemplo,
los datos que pasan entre los procesos o el traspaso de actividades o informacin desde una parte a otra;
f) definicin de las interfaces entre procesos y otros componentes del SGS, por ejemplo, entre los procesos y
la poltica de gestin del servicio y objetivos;
g) la frecuencia y el mtodo por el que pasa la informacin hacia y desde cada proceso;
h) documentos y registros solicitados por el proveedor del servicio para la gobernanza de procesos operados
por otras partes y quin los genera;
i) responsabilidades y rendicin de cuentas claras para todas las actividades requeridas.
La definicin de interfaces entre los componentes del SGS debera incluir los mtodos mediante los cuales los
procesos de gestin del servicio se establecen y mejoran continuamente para apoyar a los objetivos y la poltica
de gestin del servicio, y las necesidades cambiantes del negocio. Por ejemplo, cmo los componentes del SGS
que incluyen procesos se deberan medir frente a su alineacin con, y apoyo de, la poltica de gestin del
servicio.
4.2.5 Determinar el desempeo y cumplimiento del proceso
El proveedor del servicio debera asegurar que todos los procesos son eficaces por:
a) documentar y acordar con las otras partes la frecuencia y formato de los documentos y registros que deben
estar disponibles para el proveedor del servicio y para otras partes;
b) establecer el ciclo de revisin y los criterios para la evaluacin de procesos;
c) conducir una evaluacin del proceso frente a los requisitos de ISO/IEC 20000-1;
d) definir las obligaciones de otras partes dentro de la actividad de revisin del proceso;
e) anlisis del desempeo del proceso;
f) anlisis de interfaces entre procesos o partes de procesos operados por otras partes y otros procesos, como
as tambin polticas y planes;
g) anlisis del alineamiento entre procesos o partes de procesos operados por otras partes y objetivos de
gestin del servicio;
h) establecer prioridades y planificar actividades para mejoramientos o correcciones para optimizar procesos.
4.2.6 Control de la planificacin y priorizacin del mejoramiento de los procesos
El proveedor del servicio debera ser capaz de demostrar que controla la prioridad dada a los mejoramientos de
todos los procesos, incluyendo aquellos operados por otras partes.

EJEMPLO 1 - Un mejoramiento propuesto para el proceso de gestin del cambio se puede considerar que tiene
mayores beneficios para la organizacin que un mejoramiento propuesto para el proceso de gestin de la entrega
y despliegue. La priorizacin de mejoramientos de procesos se debera alinear con los objetivos del negocio y los
requisitos del servicio.
EJEMPLO 2 - Un mejoramiento para el proceso de gestin del incidente operado por otra parte deberan ser
dirigidos por los objetivos del negocio y los requisitos del servicio del proveedor del servicio y la organizacin
del proveedor del servicio.
4.3 Gestin de la documentacin
4.3.1 Establecer y mantener documentos
4.3.1.1 Documentos como evidencia
El proveedor del servicio debera asegurar que la evidencia est disponible para cualquier auditora del SGS.
Mucha de la evidencia debera existir en la forma de documentos. Los documentos pueden ser de cualquier tipo,
forma o medio adecuado para su finalidad, por ejemplo, en papel, archivos electrnicos, en una base de datos o
procesador de textos.
Se pueden considerar como evidencia para una auditora del SGS los documentos siguientes:
a) polticas de gestin del servicio, objetivos y planes;
b) documentos del proceso y procedimiento;
c) un catlogo de servicios;
d) documentos del servicio incluyendo diseos, especificaciones de los requisitos, SLAs, criterios de
aceptacin y revisiones del servicio;
e) documentos contractuales, incluyendo especificacin de requisitos y control de cambios;
f) actividades de planificacin de auditora e informes;
g) documentos que describan o se asocien con un cambio en particular, tales como actividades de planificacin
del cambio.
El proveedor del servicio debera ser consciente que algunos documentos, tales como polticas, son requeridos
por ISO/IEC 20000-1 para cumplir los requisitos de procesos especificos. Adems, una organizacin puede
desear considerar documentos adicionales, incluyendo polticas, para proporcionar una mayor claridad o
asegurar una operacin eficaz o el mejoramiento del SGS y la prestacin de los servicios.
Los registros son un tipo especial de documento y tambin deberan estar disponibles como evidencia.
4.3.1.2 Generacin de documentos, incluyendo registros
El proveedor del servicio debera comprender que un procedimiento efectivo es esencial para la generacin de
documentos, incluyendo registros. Esto incluye el uso de un sistema de nomenclatura y numeracin que alinea
con el propsito y la historia de las revisiones de los documentos. El uso de plantillas y formatos normalizados
puede reducir el esfuerzo de crear, acceder, actualizar y utilizar el contenido.

Debera haber evidencia de un procedimiento de aceptacin para documentos de acuerdo con los roles y
responsabilidades para los documentos definidos en el SGS.
El proveedor del servicio debera tambin comprender que los documentos, tales como SLA, polticas y planes,
pueden ser independientes, por ejemplo, una poltica de seguridad de la informacin, que defina qu informacin
se puede almacenar en dispositivos mviles o un servidor que apoye la prestacin de un servicio de correo
electrnico. Estas interdependencias se deberan comprender y gestionar cuando se hacen cambios en los
documentos.
Los registros, que muestran lo que se ha hecho realmente o lo qu ha ocurrido, no siempre requiere un
procedimiento de aceptacin, por ejemplo, un registro de incidente. Un registro de incidente debera se debera
actualizar segn el incidente se ha llevado al cierre. Operar un procedimiento de aceptacin cada vez que un
registro de incidente se actualiza causara retrasos inaceptables en la resolucin de incidentes.
NOTA - Los documentos y registros no tienen que ser exclusivos de los SGS. Siempre que cumplan los
requisitos de ISO/IEC 20000-1, tambin pueden cubrir los requisitos de normas, tales como la ISO 9001 o
ISO/IEC 27001.
4.3.2 Control de documentos
El control de documentos se debera reconocer como esencial. El control de los documentos debera incluir una
revisin peridica, con la actualizacin o archivo si es necesario. La revisin debera ser al menos anual. Los
documentos se deberan proteger de dao, por ejemplo, debido a condiciones ambientales deficientes y mal
funcionamiento del hardware.
El control puede proporcional visibilidad de los impactos de los cambios, por ejemplo, un cambio a un SLA que
afecta a los contratos con otras partes o la disponibilidad de requisitos. El proveedor del servicio debera asegurar
que los documentos se controlan mediante el uso de:
a) nomenclatura de versin y numeracin;
b) responsabilidad asignada para escribir, editar, revisar, aprobar, actualizar, eliminar y archivar documentos;
c) cambiar registros que indican la fecha, autor, aprobacin del cambio y naturaleza de las revisiones;
d) evaluacin de los cambios para identificar documentos mediante el proceso de gestin del cambio antes de
la aprobacin;
e) identificacin de las relaciones entre documentos especficos y otros componentes del SGS;
f) mecanismos de control de acceso a los documentos y distribucin;
g) un procedimiento para aprobar documentos para uso;
h) un procedimiento para revisar y actualizar segn sea necesario y reaprobar documentos;
i) un procedimiento para asegurar que los documentos de origen externo determinados por el proveedor del
servicio, que son necesarios para la planificacin y operacin del SGS, se identifican y se controla su
distribucin;
j) un procedimiento para asegurar que los documentos se eliminan de acuerdo con la poltica de seguridad de
la informacin y los requisitos reglamentarios y estatutarios;
k) un procedimiento para archivar documentos desactualizados.

Para lograr el control de los documentos, se pueden utilizar tcnicas de gestin de los documentos, gestin
conocimientos, gestin del cambio y gestin de la configuracin, por ejemplo, una poltica sobre cmo se
indican las versiones del documento.
El proveedor del servicio debera identificar aquellos documentos sujetos a los procedimientos de control del
documento. Esto puede incluir documentos de origen externo tales como normas, reglamentos o documentos del
cliente. El proveedor del servicio debera distinguir entre los distintos tipos de control a aplicar a diferentes tipos
de temes, por ejemplo, entre aquellos documentos de origen interno y externo que requieren una seguridad
diferente debido al distinto contenido.
Los documentos que se deberan controlar incluyen todos aquellos que se listan en 4.3.1.1. Muchos documentos
se clasifican como tem de configuracin (IC), los cuales por lo tanto tambin son controlados a travs del
proceso de gestin de la configuracin. Cuando el control de los documentos se logra por medios electrnicos, se
debera dar especial atencin a los procedimientos apropiados de aprobacin, acceso, distribucin, medios de
soporte y procedimientos de archivo.
NOTA 1 - El proveedor del servicio encontrar til ISO 9001:2008, 4.2.3 y 4.2.4.
NOTA 2 - Para mayor informacin, ver ISO/IEC TR 20000-4:2010, 5.10, Proceso de gestin del tem de
informacin.
4.3.3 Control de los registros
Los registros asociados al SGS se deberan alinear a los requisitos de ISO/IEC 20000-1, requisitos estatutarios y
reglamentarios y a las obligaciones contractuales. Por ejemplo, retencin de los registros, prcticas de archivo y
eliminacin. Los registros que se deberan retener incluyen el registro de revisiones de documentos y el
monitoreo de los comentarios de la revisin para su resolucin. Estos requisitos y obligaciones deberan
influenciar el diseo del SGS.
Se debera resolver cualquier conflicto entre los requisitos estatutarios y reglamentarios u obligaciones
contractuales y los requisitos de ISO/IEC 20000-1. Esto debera aplicar para todos los registros que se crean y
utilizan como parte del SGS. Esto incluye pero no se limita a documentacin, anotaciones y registros de la base
de datos, registros de errores conocidos, temes de configuracin, registros de incidentes y solicitudes de
registros de cambio.
Se deberan controlar los registros establecidos para proporcionar evidencia de la conformidad con los requisitos
y de la operacin eficaz del SGS. La organizacin debera establecer y documentar un procedimiento para
definir los controles necesarios para la identificacin, almacenamiento, proteccin, recuperacin, retencin y
disposicin de los registros. Los registros deberan permanecer legibles, fcilmente identificables y recuperables.
NOTA - En ISO/IEC 15489-1 se puede encontrar ms informacin sobre la gestin de los registros.
4.4 Gestin de los recursos
4.4.1 Entrega de los recursos
4.4.1.1 Recursos para implementar el SGS
El proveedor del servicio debera tener disponibles todos los recursos acordados en el plan para establecer,
implementar, mantener y mejorar el SGS y los servicios acordados. Los recursos incluyen al menos lo siguiente:
a) recursos humanos, por ejemplo, personas para disear, implementar y operar un SGS, alta gerencia y
personal involucrado en la gestin del SGS y los servicios;

b) recursos tcnicos, por ejemplo, infraestructura y capacidad suficiente para lograr los requisitos del servicio,
herramientas para apoyar los procesos del SGS, capacidad de las oficinas e instalaciones, instalaciones para
la continuidad del servicio;
c) informacin, por ejemplo, detalles de los requisitos del cliente, los planes de negocio y las necesidades del
negocio del cliente, las necesidades del negocio del proveedor del servicio, las polticas de gestin del
servicio, medidas y otros informes;
d) recursos financieros, incluyendo tanto fondos para proyectos y fondos para continuar la operacin del SGS.
4.4.1.2 Aprobacin de los recursos
Los procedimientos deberan existir para aprobar el uso de recursos aprobados, tales como personas,
infraestructura, herramientas y fondos. Estos incluyen:
a) fondos acordados y presupuestados con anterioridad a la ejecucin del plan de gestin del servicio;
b) asignacin de personas requeridas para el proyecto para implementar el plan de gestin del servicio y para
los mejoramientos continuos a largo plazo y la operacin del da a da de los procesos;
c) identificacin y desarrollo de habilidades, reclutamiento aprobado y/o para personas en formacin

existentes;
d) identificacin, cuerdo y aprobacin de nuevos roles y tecnologas;
e) la infraestructura necesaria que puede incluir instalaciones de oficinas y data center, telecomunicaciones
tales como puntos locales LAN y WAN, servidores, almacenamiento, y distribucin de energa y
refrigeracin;
f) herramientas de gestin del servicio que pueden incluir herramientas para la supervisin o medicin y
servicio de informacin o soporte de procesos especficos.
EJEMPLO - Los procedimientos de obtencin de recursos pueden ser apoyados por herramientas de modelado
de capacidad especificas o mediante informacin tomada de una base de datos de la gestin de la configuracin
(CMDB). Aunque las herramientas no son un requisito de ISO/IEC 20000-1, stas pueden hacer los procesos
ms eficaces y eficientes. Las herramientas pueden asistir con la provisin de evidencia de conformidad con los
requisitos de ISO/IEC 20000-1.
4.4.2 Recursos humanos
4.4.2.1 Generalidades
El compromiso del proveedor del servicio para la entrega de los recursos debera incluir la definicin de lo que
cada rol y persona contribuye al SGS y al servicio. El proveedor del servicio tambin debera definir y acordar
los niveles de autoridad y responsabilidad para cada tipo de rol. Esto incluye la competencia, educacin,
formacin, habilidades y experiencia requerida para cada rol. El proveedor del servicio debera definir, acordar y
comunicar esta informacin dentro de la organizacin del proveedor del servicio. Cuando se considere
pertinente, el proveedor del servicio tambin debera comunicar esta informacin a otras partes.
El proveedor del servicio debera comprender los riesgos que surgen de la incertidumbre en cuanto a qu
funciones, y por lo tanto qu personas, tienen determinados tipos y niveles de autoridad y responsabilidad.
Cuando el nivel de autoridad, rendicin de cuentas y responsabilidad de cada rol se ha definido, esta informacin
debera llegar a ser un componente integrado del SGS. El proveedor del servicio puede encontrar una matriz de

responsabilidad, por ejemplo, la matriz RACI1) es til para documentar la autoridad, la rendicin de cuentas y la
responsabilidad. Una vez que la informacin se convierte en un componente del SGS, sta entonces se debera
incluir en el ciclo de revisin del SGS.
Los recursos deberan incluir la alta gerencia que tiene la rendicin de cuentas y responsabilidad total por el SGS
y los servicios prestados por el SGS. Este requisito de recursos continuar indefinidamente despus del proyecto
de implementacin del SGS.
Las autoridades y responsabilidades para cada proceso de gestin del servicio en el SGS deberan incluir:
a) un dueo de proceso, responsable de:
1) el diseo del proceso;
2) asegurar la adhesin al proceso;
3) la medicin y mejoramiento del proceso;
b) un gerente de proceso, responsable de la operacin del proceso y la gestin de los recursos de gestin del
proceso;
c) personal que ejecuta los procedimientos del proceso.
Otros roles que son especficos a procesos de gestin del servicio individual se describen en clusulas 5 a 9 de
esta norma.
NOTA - Es una prctica aceptable para una sola persona el tener ms de un rol de gestin del servicio, en
particular para las organizaciones ms pequeas.
4.4.2.2 Competencia, habilidades, formacin y experiencia
La competencia requerida para un rol se debera basar en el anlisis de las caractersticas y requisitos especficos
de ese rol. Esto debera incluir pero no limitarse a: educacin, formacin, habilidades y experiencia.
Se debera identificar la competencia requerida para cada rol pertinente para el cumplimiento de 4.4.2 de
ISO/IEC 20000-1:2011. Tambin se debera tomar en consideracin el nivel y tipo de responsabilidad y
autoridad de un rol. Esto incluye los roles de la alta gerencia.
El proveedor del servicio tambin debera considerar la carga de trabajo involucrada en cada rol y cmo cada rol
cambiar con el tiempo. La asignacin de roles y responsabilidades a las personas debera tomar en cuenta estos
aspectos del rol cuando asigna roles y responsabilidades.
El proveedor del servicio debera asignar roles a personas que cumplan los criterios de capacidad para que ese
rol sea desempeado con xito.
La decisin sobre la idoneidad de una persona para un rol se debera basar en una comparacin de la
competencia real y la competencia requerida para ese rol. Cuando exista una disparidad entre los requisitos de
competencia acordados y las competencias de la persona que se considera para un rol, o que ya lo ejerce, el
proveedor del servicio debera asegurar que la disparidad se corrige.
Las disparidades se pueden corregir por varios mtodos, por ejemplo, la persona posee educacin y formacin
para corregir la disparidad. Como alternativa, el proveedor del servicio puede permitir que la falta de habilidades
o experiencia se obtenga haciendo que la persona trabaje con otra que ya tenga las habilidades y experiencia
1)
Del ingls Responsible, Accountable, Consulted, Informed.
idneas. Despus de que se ha tomado esta accin correctiva, el proveedor del servicio debera reevaluar la
competencia de la persona o personas para verificar que las acciones tomadas han corregido la disparidad.
Disparidades pueden ser corregidos por varios mtodos, por ejemplo, el individuo est dotado de la educacin y
la formacin para corregir la disparidad. Como alternativa, el proveedor del servicio puede permitir que falten
conocimientos o experiencia que se puedan obtener a travs de la persona que trabaja con otro que ya tiene las
habilidades y la experiencia idneas. Despus de esta accin correctiva tomada, el proveedor del servicio debe
volver a evaluar la competencia de la persona o personas para comprobar que las acciones tomadas han
corregido la disparidad.
Los proveedores de servicios deberan alinear los indicadores clave del desempeo y/o reas de resultados clave
del personal para el logro de los objetivos de gestin del servicio. De esta manera, el personal no slo se estar
consciente de sus obligaciones, sino que comprender mejor cmo pueden contribuir a los resultados del servicio
deseados.
El proveedor del servicio debera establecer y mantener registros actuales de la competencia, incluyendo la
educacin, formacin, habilidades y experiencia. El proveedor del servicio debera asegurar que el personal es
consciente de cmo ellos contribuyen al logro de los objetivos de gestin del servicio.
Debera existir un procedimiento documentado para asegurar que los registros del personal se mantienen al da.
4.5 Establecer y mejorar el SGS
4.5.1 Definir el alcance
El proveedor del servicio debera establecer si ISO/IEC 20000-1 es aplicable a sus circunstancias al principio de
la etapa de planificacin. Igualmente, el proveedor del servicio debera definir el alcance del SGS al principio de
la etapa de planificacin. El proveedor del servicio debera ser consciente de que descuidar cualquiera de estas
actividades puede dar lugar a un SGS ineficiente o con fallas que no cumpla con los requisitos de ISO/IEC
20000-1.
Para que el SGS sea efectivo, el proveedor del servicio debera mejorar continuamente el SGS y los servicios
utilizando la metodologa PHVA. El alcance del SGS debera ser comprendido antes de mejorar el SGS.
Cuando se define el alcance del SGS se deberan considerar los parmetros siguientes:
a) las unidades organizacionales que proveen servicios, por ejemplo, un nico departamento, grupo de
departamentos o todos los departamentos;
b) los servicios ofrecidos, por ejemplo, un nico, grupo de, o todos los servicios, servicios financieros,
servicios de venta al por menor, servicios de correo electrnico;
c) ubicacin geogrfica desde la cual el proveedor del servicio preste los servicios, por ejemplo, una oficina o
un grupo de oficinas, de carcter regional, nacional o global;
d) clientes y sus ubicaciones, por ejemplo, un cliente, muchos clientes, clientes externos o internos;
e) tecnologa utilizada para proveer los servicios.
La declaracin del alcance no debe incluir los nombres de las otras partes que contribuyan a la prestacin del
servicio.

El proveedor del servicio debera tomar en cuenta las orientaciones de ISO/IEC TR 20000-3 cuando planifica
cmo cumplir los requisitos de ISO/IEC 20000-1. Esta proporciona recomendaciones sobre cmo definir el
alcance del SGS y verificar la aplicabilidad de ISO/IEC 20000-1 a las circunstancias del proveedor del servicio.
4.5.2 Planificar el SGS (Planificar)
4.5.2.1 Aspectos importantes de la planificacin
La planificacin para el SGS debera cubrir todos los aspectos de la gestin del servicio y la prestacin de
servicios, e incluye pero no se limita a los aspectos indicados abajo.
a) Objetivos de gestin del servicio. Los objetivos prioritarios del proveedor del servicio en la implementacin
de los cambios y mejoramientos necesarios deberan ser inequvocos.
b) Plan de gestin del servicio. Cuando sea posible el plan de gestin del servicio se debera subdividir en
etapas, con beneficios identificados para cada etapa.
c) Poltica de gestin del servicio del proveedor del servicio. Por ejemplo, polticas relacionadas a todos los
subplanes tales como polticas de gestin del cambio, polticas de seguridad de la informacin, polticas de
continuidad del servicio. Definir las polticas al principio de la planificacin del SGS permite la verificacin
del alcance del SGS y hace posible identificar consideraciones importantes.
d) Requisitos del servicio. Las polticas, normas o indicadores clave del desempeo del negocio deberan ser
compatibles con los requisitos del servicio y deberan cumplir los requisitos del cliente y las necesidades del
negocio. Por ejemplo, los requisitos del servicio no deberan dar como resultado una no conformidad para
una poltica de seguridad de la informacin, poniendo en riesgo al negocio completo.
e) Limitaciones conocidas que pueden afectar al SGS. Por ejemplo, el personal del proveedor del servicio que
tiene habilidades insuficientes para implementar y gestionar el SGS. El plan debera identificar las acciones
apropiadas tales como proporcionar formacin y concientizacin, la contratacin de personal nuevo con las
habilidades y experiencia pertinentes y utilizando la experticia de otras partes como personal mentor.
4.5.2.2 Alineacin de la planificacin y los acuerdos
El plan de gestin del servicio debera incluir el acuerdo y documentacin de los requisitos del servicio. Las
metas del servicio se deberan documentar en el plan y como parte de los acuerdos entre el proveedor del
servicio y los grupos pertinentes. Los acuerdos deberan tomar en consideracin los aspectos que se listan a
continuacin:
a) Cliente, por ejemplo, SLA, requisitos de los servicios nuevos o modificados. Esto se debera considerar an
si el acuerdo documentado con un cliente no es un contrato legalmente vinculante.
b) Grupos internos, por ejemplo, acuerdos de nivel operativo con un grupo de instalaciones, grupo de
desarrollo de sistemas, grupo de recursos humanos, o grupo financiero. Esto no puede ser un contrato
legalmente vinculante porque el proveedor del servicio y los grupos internos son parte de la misma entidad
legal. Sin embargo, los grupos internos pueden no ser parte de la gestin de lnea directa del proveedor del
servicio. Los grupos internos pueden ser un aspecto importante de la definicin del alcance del SGS, ya que
pueden aportar una parte importante del servicio global.
c) Proveedores y proveedores principales, por ejemplo, subcontratos de servicios o recursos.
d) Otras normas, requisitos estatutarios y reglamentarios, por ejemplo, especficos de la industria, tales como
mdicos, automotrices, telecomunicaciones, o especficos del pas para el cumplimiento de las leyes de
licencias de software.

4.5.2.3 Roles de gestin, autoridades y responsabilidades
Los roles de gestin, autoridades y responsabilidades dentro del alcance del SGS se deberan documentar en el
plan de gestin del servicio, en la documentacin del proceso y en los acuerdos pertinentes, incluyendo:
a) a todos los roles para los cuales la gerencia individual o colectivamente rinde cuentas y es responsable;
b) al representante de la gerencia, incluyendo los lmites de la autoridad de este rol, y la relacin con la alta
gerencia que esta persona representa;
c) a los dueos de servicio o proceso.
Las autoridades y responsabilidades por los roles en el SGS se deberan verificar para asegurar que no existen
conflictos de inters, por ejemplo, el mismo rol que proponga y tambin apruebe un cambio. El marco de trabajo
de autoridades, responsabilidades y roles de proceso en el plan deberan incluir los detalles sobr que rol rinde
cuentas y es responsable de todos los componentes del SGS.
4.5.2.4 Interfaces del proceso
La informacin sobre las interfaces entre procesos debera incluir el tipo, mtodo y frecuencia de transferencia
de la informacin desde un proceso a otro. El proveedor del servicio debera ser consciente que esto es una parte
importante de la definicin de su proceso y asegura que los procesos y el SGS funcionaran eficaz y
eficientemente.
Clusula 5 de ISO/IEC 20000-1:2011 incluye requisitos para las interfaces entre los procesos de clusulas 6 a 9 y
el diseo y transicin de servicios nuevos o modificados.
Los requisitos para los servicios nuevos o modificados incluyen la etapa del proyecto en la que se definen los
requisitos del servicio y cuando el servicio se disea y transfiere. El proveedor del servicio debera ser consciente
que la gestin eficaz del proyecto es importante para gestionar algunas interfaces. En el plan se debera definir,
acordar y registrar la interface entre el SGS y todos los proyectos.
Se deberan medir los componentes integrados del SGS, incluyendo los procesos, polticas, objetivos y planes,
de modo que se pueda identificar, gestionar y mejorar la eficiencia y eficacia del SGS y de los servicios.
A fin de facilitar la integracin e interoperabilidad entre el cliente y el proveedor del servicio, el proveedor del
servicio puede establecer descripciones de los procesos normalizados. Las descripciones de los procesos definen
el propsito, resultados, actividades, polticas, roles y responsabilidades, temes de informacin e interfaces para
cada proceso de gestin del servicio dentro del SGS. Cada proceso tambin puede requerir procedimientos
documentados o instrucciones de trabajo para definir mejor cmo llevar a cabo las actividades.
El proveedor del servicio debera ser consciente que la coordinacin y gestin global del SGS es particularmente
importante cuando ste se mejora o modifica por alguna razn. Los cambios en los procesos que forman parte
del SGS slo se deberan hacer despus de que se comprende y considera aceptable el impacto del cambio en el
resto del SGS. Esto incluye el impacto sobre otros procesos o la capacidad de prestacin de servicios de la
organizacin.
EJEMPLO - Cambios en los parmetros o metas utilizados el proceso de gestin de solicitud del servicio e
incidente, puede tener un efecto no deseado y perjudicial sobre otros procesos, tales como la gestin del nivel de
servicio (GNS), procesos de gestin de la seguridad de la informacin (GSI) y presentacin de informes.
Comprender la interdependencias entre procesos y entre todos los componentes del SGS puede reducir el riesgo
y permitir la gestin eficaz del SGS. En Anexo A se pueden encontrar ejemplos de interfaces entre procesos de
gestin del servicio y de integracin dentro del SGS.

4.5.3 Implementar y operar el SGS (Hacer)
El proveedor del servicio debera implementar y operar el SGS alineado con el plan de gestin del servicio y
como un medio para lograr los objetivos de gestin del servicio.
El proveedor del servicio debera ser consciente de los beneficios de asegurar que las autoridades y
responsabilidades tanto del proveedor del servicio y como del cliente se documentan y acuerdan para las
actividades que afectan a ambas partes.
El proveedor del servicio debera ser consciente que una persona que es idnea para la planificacin e
implementacin inicial no siempre es adecuada para la operacin del SGS. Se requieren distintas habilidades
para la planificacin, implementacin y operacin.
4.5.4 Supervisin y operacin del SGS (Verificar)
El proveedor del servicio debera monitorear, medir y revisar los objetivos de gestin del servicio y planificar las
actividades necesarias para asegurarse de que se estn logrando. La alta gerencia debera ser consciente de los
resultados de las revisiones. Si se considera necesario hacer cambios a los objetivos y al plan de gestin del
servicio, estos cambios se deberan aprobar de acuerdo con el proceso de gestin del cambio.
De acuerdo con la metodologa PHVA, el proveedor del servicio debera identificar, reunir, analizar e informar
regularmente informacin sobre el proceso y los servicios prestados. Estas actividades deberan apoyar la gestin
eficaz del SGS y de los servicios, y deberan permitir la capacidad para demostrar objetivamente la calidad y
valor de los servicios prestados.
NOTA - Para mayor informacin sobre mediciones ver ISO/IEC 15939, para procesos de evaluacin y
evaluacin de desempeo ISO/IEC 15504, para evaluacin del producto ISO/IEC 14598 y para ejemplos de
mtricas de software de productos ISO/IEC 9126 partes 2 y 3.
4.5.4.2 Auditora interna
El proveedor del servicio debera asegurar que se realizan auditoras internas de acuerdo a un procedimiento
documentado que incluya autoridades y responsabilidades para las auditoras. Aquellos responsables de llevar a
cabo las auditoras internas deberan estar adecuadamente informados y ser independientes de las reas que es
auditada, por ejemplo, no deberan auditar su propio trabajo. Se deberan documentar los roles requeridos. Se
puede incluir un gerente de proyecto, el patrocinador, el comit de gerencia, otras partes interesadas y los
auditores independientes.
Debera haber un programa de auditora interna acordado que identifique cuando cada servicio y qu clusulas
de ISO/IEC 20000-1 se deben auditar. Debera haber una razn para las decisiones de planificacin, incluyendo
por qu los servicios o clusulas de ISO/IEC 20000-1 estn incluidos o excluidos para cada auditora interna.
Los factores que se deberan tomar en cuenta incluyen el grado de riesgo involucrado en un proceso, su
frecuencia de operacin y su historia pasada.
La periodicidad con que se realizan las auditoras internas se debera planificar y no so hacer cuando hay riesgos
conocidos y otros asuntos. El periodo seleccionado debera tomar en cuenta la tasa de cambio de:
a) el SGS y los servicios;
b) los requisitos del cliente y de la organizacin del cliente;
c) la organizacin y el personal del proveedor del servicio;

d) la tecnologa utilizada para prestar el servicio;
e) los cambios mayores en las herramientas de gestin del servicio, cuando se utilizan herramientas.
La gerencia se debera asegurar que las auditoras se realizan segn la planificacin, a menos que se reprogramen
por razones documentadas.
Las auditoras internas del SGS deberan incluir una evaluacin del alcance del SGS y que el SGS sigue siendo
eficaz para la prestacin de los servicios acordados con el cliente. Esto debera incluir la verificacin de que la
poltica de gestin del servicio todava proporciona la gerencia de gestin correcta y que los objetivos se
cumplen dentro de los plazos previstos. La auditora interna debera revisar los planes e informar respecto del
desempeo del SGS.
Utilizando un calendario consistente con la frecuencia de auditora, los auditores internos deberan proporcionar
detalles sobre las no conformidades. El proveedor del servicio debera entonces utilizar los resultados de la
auditora interna para identificar y priorizar las acciones.
Se deberan tomar en cuentas los resultados de las auditoras previas. Por ejemplo, cuando se identifica una
preocupacin los planes deberan incluir asegurar que la causa de la preocupacin se vuelve a auditar en la
prxima auditora interna. La auditora interna debera verificar que las acciones correctivas o preventivas
identificadas y acordadas se han implementado en los plazos acordados. El auditor interno debera tambin
verificar que las acciones acordadas de hecho han dado como resultado el mejoramiento previsto.
Las no conformidades se deberan analizar para determinar las causas races. Las acciones que surjan a partir de
las auditoras deberan incluir acciones preventivas en relacin con las causas races identificadas. Las acciones
deberan tener dueos y plazos claros y acordados, para ayudar a asegurar que stas se completan eficazmente y
en el tiempo. Las actividades de monitoreo de las no conformidades identificadas deberan incluir la verificacin
sobre qu acciones se han tomado. Los resultados de las acciones tomadas se deberan informar a la alta
gerencia.
4.5.4.3 Revisin por la gerencia
El SGS se debera revisar a intervalos planeados para verificar que el SGS contina permitiendo el cumplimiento
de las necesidades cambiantes del negocio y los requisitos del servicio. Esto se debera realizar al menos
anualmente. Sin embargo, algunos proveedores de servicio operan en un entorno rpidamente cambiante y
deberan revisar el SGS con una mayor frecuencia. La revisin debera incluir el alcance real frente al alcance
definido del SGS, a adecuacin de los planes actuales comparados con las necesidades actuales del cliente y de
las necesidades del negocio del cliente.
Especficamente, la revisin se puede realizar con respecto a:
a) el desempeo del SGS frente a polticas, planes y objetivos;
b) la medicin de indicadores de desempeo de procesos claves (IDC);
c) los resultados de auditoras internas y externas;
d) una revisin de las actividades de mejoramiento continuo alineadas con los objetivos del negocio;
e) revisiones de cambios posteriores a la implementacin;
f) mejores prcticas de la industria;

g) resultados de las encuestas de satisfaccin del cliente;
h) resultados del negocio deseados.
NOTA - Para requisitos y guas para evaluacin de procesos, ver ISO/IEC 15504 partes 2 y 3.
4.5.5 Mantener y mejorar el SGS (Actuar)
Se debera hacer un enfoque estratgico para el mejoramiento del servicio mediante el establecimiento de una
poltica sobre mejoramiento continuo del SGS y los servicios. La poltica debera incluir una definicin de los
criterios de evaluacin acordados para aceptar y priorizar las oportunidades de mejoramiento.
Todos los servicios prestados al cliente, los procesos de gestin del servicio y el SGS en su totalidad deberan
estar sujetos a mejoramiento continuo. Para facilitar esto ms fcilmente, el proveedor del servicio puede
encontrar til especificar actividades de mejoramiento continuo en la documentacin del proceso de gestin del
servicio. El proveedor del servicio tambin puede encontrar provechoso alinear la medicin de los componentes
del SGS y las metas de desempeo del personal frente a los logros del mejoramiento continuo.
Las no conformidades identificadas a travs de evaluaciones, auditoras u otros medios se deberan dirigir y
tomar acciones para eliminar las causas de las no conformidades tanto identificadas como potenciales.
4.5.5.2 Gestin del mejoramiento
El mejoramiento continuo es uno de los conceptos bsicos de ISO/IEC 20000. Se debera utilizar un
procedimiento documentado que identifique las autoridades y responsabilidades para todas las actividades de
mejoramiento. Este procedimiento debera asegurar que las oportunidades de mejoramiento se identifican,
evalan, priorizan, aprueban, implementan, gestionan y miden eficazmente.
Las entradas para la gestin del mejoramiento continuo incluyen:
a) directivas pertinentes desde la alta gerencia;
b) causas races identificadas como un resultado de las auditoras y revisiones. tanto del SGS como de los
servicios individuales;
c) sugerencias del cliente, otras partes y desde dentro de la organizacin del proveedor del servicio;
d) registros de problemas;
e) pruebas de planes, por ejemplo, pruebas de la continuidad del servicio;
f) especificacin de los requisitos del servicio o de valor, por ejemplo, priorizar actividades de mejoramiento
en base a la criticidad del negocio de servicios;
g) utilizacin optimizada de recursos o reduccin del riesgo, por ejemplo, oportunidades para aumentar la
eficiencia o mejorar la automatizacin.
NOTA 1 - En ISO/IEC TR 20000-4 se puede encontrar un mayor orientacin.
NOTA 2 - En ISO/IEC 15504, partes 5 y 6, se incluye un modelo de proceso y un mtodo de evaluacin para
ingeniera de sistemas y desarrollo de software.

5 Diseo y transicin de servicios nuevos o modificados
5.1 Generalidades
5.1.1 Intencin de los requisitos
El proceso de diseo y transicin de servicios nuevos o modificados debera establecer e implementar planes
para controlar la prestacin de servicios nuevos o modificados. El proceso se debera aplicar a servicios
nuevos o modificados que son de alto riesgo o tienen un impacto potencialmente importante sobre los
servicios o el cliente.
5.1.2 Conceptos
Este proceso debera proporcionar un mecanismo para gestionar el diseo y la transicin de servicios nuevos o
modificados. El proceso trabaja estrechamente con el proceso de gestin del cambio. Los IC desarrollados o
modificados en el proceso se deberan controlar a travs del proceso de gestin de la configuracin mediante
el proceso de gestin del cambio. El servicio nuevo o modificado se debera desplegado a travs del proceso
de gestin de la entrega y despliegue.
Los requisitos para los servicios nuevos o modificados deberan ser identificados por el cliente o las partes
interesadas de un servicio, a fin de cumplir una necesidad del negocio o efectuar un mejoramiento a la forma
en que se presta el servicio al cliente. El proveedor del servicio debera decidir cundo utilizar este proceso, en
base a la poltica de gestin del cambio que incluye los criterios para determinar el uso del proceso. Cada
proveedor del servicio puede tener una poltica distinta y utilizar criterios distintos para determinar qu
cambios de clusula 5 aplicara. El eliminacin de servicios, la transferencia de servicios y los servicios
nuevos o los cambios con potencial de tener un impacto importante se deberan gestionar mediante el proceso
de diseo y transicin de servicios nuevos o modificados. El proveedor del servicio debera comprender los
riesgos asociados con cada servicio nuevo o modificado propuesto. Los riesgos deberan tomar en cuenta las
circunstancias del proveedor del servicio y del cliente, incluyendo las actividades del negocio del cliente. Se
deberan tomar acciones para minimizar los riesgos de los servicios nuevos o modificados.
5.1.3 Explicacin de los requisitos
El proceso de diseo de servicios nuevos o modificados est previsto para cambios que requieren niveles
adicionales de visibilidad y control para gestionar niveles ms altos de riesgo e impacto. Los tres procesos de
control, la gestin de la configuracin, la gestin del cambio y la gestin de la entrega y despliegue, estn en
el ncleo de la gestin de todos los cambios al SGS y los servicios. Sin embargo, un proyecto complejo con
interfaces al SGS y tareas o entregables fuera del alcance del SGS, a menudo puede requerir la capa adicional
de control que proporciona el proceso de diseo y transicin de servicios nuevos o modificados.
Para cada proveedor del servicio, es probable que los criterios utilizados para determinar qu tipos de cambio
son apropiados para ser gestionados a travs del proceso de diseo y transicin de servicios nuevos o
modificados sean distintos. Por ejemplo, los criterios pueden incluir un cambio en un servicio que impacta a
ms de un nmero especfico de usuarios o ubicaciones. Otro ejemplo puede incluir cualquier cambio que
podra poner al proveedor del servicio en riesgo de ser penalizado bajo la legislacin de proteccin de datos.
El proceso de diseo y transicin de servicios nuevos o modificados debera definir y gestionar las interfaces
pertinentes con los procesos de control de clusula 9. El proceso de diseo y transicin de servicios nuevos o
modificados debera trabajar con los procesos de control de clusula 9 para asegurar la gestin ptima de
riesgo y la prestacin de una solucin que cumpla todos los requisitos del servicio. Los IC afectados por los
servicios nuevos o modificados deberan ser controlados por el proceso de gestin de la configuracin. La
evaluacin, aprobacin, calendarizacin y revisin de los servicios nuevos o modificados deberan ser
controladas por el proceso de gestin del cambio. Todos los servicios nuevos o modificados se deberan
desplegar en el entorno real utilizando el proceso de gestin de la entrega y despliegue.

5.2 Planificacin de servicios nuevos o modificados
5.2.1 Necesidad de servicios nuevos o modificados
La necesidad de un servicio nuevo o la modificacin de un servicio puede provenir del cliente, del proveedor
del servicio, de grupos internos o proveedores. El propsito del servicio nuevo o modificado puede ser para
satisfacer necesidades del negocio y requisitos del cliente o para mejorar la eficacia del servicio.
5.2.2 Cambios con impacto importante sobre el servicio o el cliente
Este proceso se debera aplicar sobre aquellos cambios que tienen el potencial de generar un impacto
importante sobre los servicios y por consiguiente tambin sobre el cliente. Tales cambios en los servicios
necesitan actividades adicionales provistas por la aplicacin de clusula 5, para as reducir el riesgo asociado
con el cambio.
Un cambio donde el impacto sobre los servicios o el cliente es suficientemente bajo slo se puede gestionar a
travs de los procesos de control. La mayora de los cambios manejados por el proveedor del servicio deberan
estar en esta ltima categora.
5.2.3 Poltica sobre cambios con un impacto importante
Los cambios que estn en el alcance de clusula 5 se deberan identificar utilizando la poltica de gestin del
cambio desarrollada como parte del proceso de gestin del cambio. La poltica debera incluir los criterios
para la identificacin de los cambios de riesgo ms alto que tienen el potencial de generar un impacto
importante en los servicios o el cliente. La poltica se debera basar en las necesidades especficas del
proveedor del servicio y una evaluacin de los riesgos a los sus servicios. La poltica debera tener en
consideracin que la propuesta para un servicio nuevo o modificado se puede originar desde una diversidad de
fuentes y por una diversidad de razones.
La poltica se debera documentar y acordar por la alta gerencia y por los dueos de los procesos ms
directamente involucrados en el proceso de servicios nuevos o modificados.
Los criterios en la poltica de gestin del cambio siempre deberan incluir la eliminacin de un servicio
existente o la transferencia de un servicio a ser prestado por otra parte. Para cada proveedor del servicio, es
probable que los otros criterios sean distintos.
Los cambios con un impacto potencialmente importante pueden incluir:
a) un cambio a un servicio que impacta a ms de un nmero especfico de usuarios o ubicaciones;
b) un cambio que podra poner al proveedor del servicio en riesgo de ser penalizado bajo la legislacin de
proteccin de datos;
c) un servicio nuevo o un cliente nuevo para un servicio existente;
d) una diferencia importante sobre cmo ser proporcionado o prestado el servicio, por ejemplo, ubicacin,
plataforma de hardware;
e) implementacin de un nuevo sistema operativo o aplicacin de software, o una entrega importante de un

software existente.
El proveedor del servicio tambin debera tomar en consideracin los cambios que pueden ser necesario para
el SGS, incluidos los cambios en el alcance del SGS como resultado de servicios nuevos o modificados. Por
ejemplo, la identificacin de riesgos para las metas del servicio acordadas con el cliente, cambios en los
procedimientos de gestin de proveedores o los acuerdos documentados con otras partes que tienen un
impacto sobre los servicios existentes o planificados.
5.2.4 Gestin del cambio como un proyecto
Los servicios nuevos o modificados para los que aplica clusula 5 se deberan gestionar como un proyecto,
debido al tamao, riesgos y alcance de los cambios. El proveedor del servicio debera considerar el impacto
financiero, organizacional y tcnico potencial del servicio nuevo o modificado, ms el impacto potencial sobre
el SGS.
El proveedor del servicio debera asegurar una fuerte coordinacin entre el proceso de gestin del cambio y
los roles y autoridades de gestin del proyecto, desde la etapa ms temprana posible del proyecto.
El proveedor del servicio debera asegurar que el proyecto toma en consideracin:
a) el impacto en los arreglos de soporte existentes, por ejemplo, los procedimientos operacionales del
proveedor del servicio;
b) el impacto en los niveles de servicio existentes y la habilidad del proveedor del servicio para gestionar el
impacto;
c) acuerdos de apoyo del proveedor, contratos y acuerdos documentados con otras partes que puedan
resultar afectadas por las adiciones o cambios en el servicio;
d) requisitos del cliente para el servicio existente, incluyendo salidas tales como informar qu puede ser
afectado por las adiciones o cambios en el servicio;
e) herramientas y mtodos de despliegue.
5.2.5 Contribuciones de otras partes
Otra parte puede proveer componentes del servicio para los servicios nuevos o modificados. El servicio nuevo
o modificado puede implicar la adquisicin de software, infraestructura, habilidades especializadas u otros
componentes del servicio.
Cuando est involucrada otra parte en los servicios nuevos o modificados, el proveedor del servicio debera
hacer una revisin completa. La revisin debera valorizar la capacidad de la otra parte para cumplir sus
compromisos, incluyendo los requisitos del servicio acordados. La revisin tambin debera valorizar el riesgo
para los servicios existentes y al entorno de soporte.
A fin de aceptar el servicio en el entorno real, puede ser necesario especificar requisitos, tales como el nmero
de personal de soporte, la tecnologa, pruebas o documentacin.
5.2.6 Evaluacin del riesgo
El proveedor del servicio debera ser consciente de la importancia de evaluar riesgos, asuntos y esfuerzos de
mitigacin tempranamente durante el proceso y desde entonces, en cada fase desde la planificacin hasta la
aceptacin en el ambiente real.
Durante la etapa de planificacin se deberan utilizar los resultados de las evaluaciones de riesgo para
desarrollar criterios de aceptacin.
5.2.7 Criterios de aceptacin del servicio
Los criterios de aceptacin del servicio contenidos en el plan deberan incluir:
a) los requisitos que debe cumplir el proveedor del servicio, a fin de que el proveedor del servicio acepte los
servicios nuevos o modificados desde el proyecto;

b) una lista de verificacin para el traspaso del servicio nuevo o modificado, por ejemplo, transferencia de
conocimientos, documentacin, capacidad, disponibilidad, continuidad y seguridad requeridas para el
soporte del servicio nuevo o modificado;
c) los requisitos del cliente, como calendarios de comunicacin, formacin de conciencia y documentacin.
Cuando los riesgos para el servicio, SGS o las actividades del negocio del cliente son inaceptables y no se
pueden mitigar, el servicio nuevo o modificado se debera rechazar.
5.2.8 Eliminacin del servicio
Si se debe eliminar un servicio, esto se debera planificar y documentar en un plan de eliminacin de servicios.
El plan debera incluir:
a) las condiciones en que aplica la eliminacin;
b) los objetivos y factores de xito de la eliminacin;
c) gobernanza de los procesos operados por otras partes;
d) roles y responsabilidades de todas las partes interesadas, por ejemplo, clientes, proveedores, grupos
internos;
e) restricciones, riesgos y asuntos;
f) hitos y entregables;
g) interrupcin de la actividad y descripcin de cada actividad;
h) criterios de finalizacin acordados para la eliminacin y trmino de la responsabilidad del proveedor del
servicio;
i) la fecha en que el servicio ya no est disponible para los usuarios y la fecha cuando se elimina el servicio;
j) cmo sern manejadas por los otros servicios las interfaces entre el servicio a eliminar y los otros
servicios;
k) una revisin de los arreglos de seguridad de la informacin, incluyendo la eliminacin de informacin

sensible.
El proveedor del servicio debera asegurar que los detalles de los incidentes, problemas, requisitos del usuario
y las solicitudes de cambio destacados se han acordado con el cliente. Este acuerdo con el cliente debera
incluir las acciones resultantes.
Se debera acordar la propiedad de todos los datos, documentacin y componentes del sistema. Si se requiere,
se debera acordar, planificar e implementar arreglos para el acceso a los datos u otros componentes del
servicio. Tambin se deberan acordar arreglos para archivar, disponer o transferir.
Tambin se deberan identificar los cambios a los documentos necesarios como resultado de la eliminacin de
un servicio, adems de aquellos cambios hechos a travs del proceso de gestin del cambio.

Se deberan documentar en un acuerdo escrito con el cliente los objetivos de gestin del servicio, las
actividades y el resultado de la eliminacin de un servicio. Este acuerdo debera incluir la fecha de trmino del
servicio y los cambios de roles y responsabilidades. El acuerdo tambin debera incluir cmo el proveedor del
servicio gestionar los datos del usuario final, la informacin especfica del cliente, la documentacin del
servicio y la infraestructura afectada, las aplicaciones y licencias. El acuerdo escrito se puede denominar como
criterios acordados para la aceptacin de la eliminacin del servicio.
Cuando todo o parte del servicio se va transferir a otra parte, el objetivo debera ser que el servicio para el
usuario contine sin interrupciones innecesarias. El proveedor del servicio debera trabajar con el cliente y la
otra parte, para identificar los riesgos para la continuidad o calidad del servicio, con anterioridad a la
transferencia. El proveedor del servicio debera emitir una lista de tareas detallada de los pasos necesarios,
seguido de una valoracin documentada del resultado.
5.3 Diseo y desarrollo de servicios nuevos o modificados
5.3.1 Actividades realizadas por el proveedor del servicio, cliente y otras partes
El proveedor del servicio debera estar involucrado desde el principio en un proyecto para prestar servicios
nuevos o modificados. El involucramiento temprano puede evitar decisiones de diseo que den como
resultado un servicio dnde las funciones y caractersticas necesarias sean inadecuadas cuando entran
realmente operen. El involucramiento temprano del proveedor del servicio debera asegurar que los requisitos
acordados con el cliente incluyen criterios para la calidad del servicio nuevo o modificado, incluyendo a lo
menos:
a) niveles de servicio, respuesta y otros aspectos del desempeo;
b) confiabilidad y resiliencia del servicio;
c) controles de seguridad;
d) adecuacin para la continuidad de servicio requerido;
e) criterios de costo-beneficio para el cambio o para una nueva versin a entregar y desplegar;
f) facilidad de uso.
5.3.2 Gestin del riesgo
Durante la etapa de diseo el proveedor del servicio debera considerar los resultados de la evaluacin inicial
del riesgo realizada durante la etapa de planificacin. El diseo debera considerar riesgos identificados en esa
evaluacin. Durante la etapa de diseo el proveedor del servicio debera considerar cul de los riesgos
identificados ser aceptable cuando un servicio nuevo o modificado pase al entorno real. Esto debera tener en
cuenta el impacto potencial de un riesgo particular, incluso sobre:
a) el servicio que se disea;
b) el impacto potencial del riesgo en los otros servicios del proveedor del servicio;
c) los clientes que dependen de los servicios nuevos y existentes.
Cuando se identifica una no conformidad potencial de la calidad acordada y de los requisitos funcionales del
servicio, el proveedor del servicio debera mitigar el riesgo. Por ejemplo, cambiando el diseo o asegurando
que las partes interesadas comprenden y aceptan los riesgos.

La aceptacin del servicio en el entorno real se debera basar en una comprensin del impacto potencial de un
servicio que no cumple los criterios de aceptacin. Esto debera incluir una comprensin del impacto sobre
otros servicios. La evaluacin del riesgo y la orientacin de la gestin del riesgo proporcionadas en 5.2.6 y
5.3.2 debera influir en el desarrollo de criterios de aceptacin. Se debera considerar lo siguiente:
EJEMPLO 1 - Arreglo ahora: un retraso en el proceso de transicin en funcionamiento operacional a fin de

permitir la correccin de las deficiencias.
EJEMPLO 2 - Arreglo despus: aceptacin con salvedades, de modo que la correccin de deficiencias se
realiza despus de un intervalo acordado.
EJEMPLO 3 - Sin arreglo: aceptacin con otros servicios modificados, para acomodar las deficiencias del
servicio nuevo o modificado.
EJEMPLO 4 - No se puede arreglar: aceptacin, pero con el acuerdo de que las deficiencias no se pueden o
necesitan corregir.
NOTA - Para mayor informacin sobre la gestin del riesgo, ver ISO 31000.
5.3.3 Actividades de diseo del servicio
5.3.3.1 Planificacin del diseo
El diseo del servicio nuevo o modificado tambin se debera planificar, tomando en consideracin lo
siguiente:
a) enfoque en el cumplimiento de las necesidades del negocio acordadas y los requisitos del cliente, que se
deberan documentar como una parte de los requisitos dentro del alcance del proyecto;
b) se debera vincular al proceso de gestin del cambio para asegurar que los planes se comunican y
aprueban por las partes interesadas y que cualquier impacto en los IC se comprenden y aceptan;
c) para asegurar que los IC para los servicios nuevos o modificados se planifican y controlan;
d) para asegurar que las escalas de tiempo para el proyecto se toman en consideracin en el calendario de
cambios;
e) tomar en consideracin el costo de la prestacin y la gestin continua del servicio, por ejemplo, el diseo
del servicio debera dar como resultado un soporte eficaz sin recursos excesivos o sobrecarga tcnica;
f) tomar en consideracin el impacto organizacional, tcnico y comercial de prestar los servicios nuevos o
modificados;
g) asegurar que el diseo del servicio hace el mejor uso de la organizacin y tecnologa existentes y causa
las mnima alteracin a los arreglos comerciales existentes;
h) se lleve a cabo de una forma tal que el diseo permita que se cumplan los niveles de servicio acordados
para los servicios nuevos o modificados de una forma gestionable para la organizacin del proveedor del
servicio;
i) evaluar la adecuacin del servicio nuevo o modificado para los procesos existentes en el lugar dentro de
la organizacin del proveedor del servicio para gestionar, medir e informar los niveles de servicio.

El plan del proveedor del servicio para los servicios nuevos o modificados debera incluir las dependencias, el
tiempo y las restricciones recursos que puedan afectar a cualquiera de las actividades necesarias. Cuando el
proveedor del servicio depende de actividades a ser realizadas por partes externas, el plan debera considerar
estas dependencias. Las actividades que se pueden realizar como dependencias incluyen las pruebas y la
validacin. Los planes tambin deberan dar cuenta de las contingencias en caso de que no se cumplan las
escalas de tiempo.
El proveedor del servicio debera asegurar que se identifican y pueden proveer los recursos humanos, tcnicos,
de informacin y financieros y las capacidades de gestin del servicio necesarias para llevar a cabo todas las
actividades. Cuando estos recursos y capacidades no existen dentro de la organizacin del proveedor del
servicio, se debera comprender qu pasos se necesita dar a fin de proporcionarlos, incluyendo los plazos para
su prestacin. El alcance de la planificacin debera incluir el diseo inicial, el desarrollo y las actividades de
transicin a travs de la prestacin del servicio nuevo o modificado.
5.3.3.2 Servicios de diseo y desarrollo
El diseo del servicio se debera documentar y acordar antes del desarrollo. El diseo debera tener en cuenta
los requisitos actuales del servicio, consideraciones de seguridad de la informacin, la resiliencia del servicio
y las proyecciones de capacidad de los recursos para el crecimiento durante la vida prevista del servicio.
El diseo y desarrollo de los servicios nuevos o modificados debera adoptar mtodos y tcnicas de gestin de
proyectos. Debera haber trazabilidad entre los requisitos, el diseo y las pruebas de los servicios nuevos o
modificados.
Antes del desarrollo, el diseo del servicio se debera acordar por todas las partes afectadas o interesadas.
Estas partes deberan incluir a aquellas responsables de suministrar servicios existentes que puedan ser
afectados, y aquellos responsables de suministrar cualquiera de los recursos necesarios.
Durante el curso del proyecto, si se acuerdan cambios, el diseo se debera actualizar y aprobar. Antes de la
operacin real, el servicio se debera probar frente a cada requisito de la especificacin, y los resultados se
deberan registrar.
Segn sea apropiado, el diseo y desarrollo deberan incluir los tems siguientes:
a) las actividades de diseo e implementacin, transicin, operacin y mantenimiento para la aceptacin de

los servicios, incluyendo la identificacin de, o referencia a:
1) actividades de desarrollo a llevar a cabo;
2) entradas necesarias para cada actividad;
3) salidas necesarias de cada actividad;
4) actividades de gestin y soporte a llevar a cabo;
5) formacin del equipo necesario;
6) planificacin para el control del producto y provisin del servicio;
b) la organizacin de los recursos del proyecto, incluyendo la estructura del equipo, responsabilidades, uso
de proveedores, y recursos a utilizar;
c) interfaces organizacionales y tcnicas entre personas o grupos distintos, como equipos de sub-proyecto,
proveedores, socios, usuarios, representantes del cliente, y representantes de aseguramiento de la calidad;

d) anlisis de los posibles riesgos, supuestos, dependencias, y desafos asociados con el diseo y desarrollo;
e) el calendario que identifique:
1) las etapas del cambio, las actividades a realizar;
2) los recursos y el tiempo asociados;
3) las dependencias asociadas;
4) los hitos;
5) las actividades de verificacin y validacin;
f) identificacin de normas, reglas, prcticas y convenciones, metodologa, modelo del ciclo de vida,
requisitos estatutarios y reglamentarios, obligaciones contractuales, y otras restricciones;
g) herramientas y tcnicas para el desarrollo del servicio;
h) medios tales como el hardware y software requeridos para el desarrollo del servicio;
i) prcticas de gestin de la configuracin;
j) mtodo de control de productos de software y hardware no conformes;
k) mtodos de control para el software y hardware utilizado para soportar el despliegue del servicio;
l) procedimientos para archivar, respaldar, recuperar, y controlar el acceso a los productos de software; y
mtodos de control para la proteccin de virus.
Si el proveedor del servicio no puede controlar el diseo o el desarrollo de un servicio o componente del
servicio, el proveedor del servicio debera efectuar una evaluacin para asegurar que ste cumple con las
expectativas. Por ejemplo, se deberan evaluar las caractersticas funcionales y no funcionales de un producto
proveniente de un estante comercial frente a los requisitos y expectativas. Se debera planificar y disear
cualquier configuracin o personalizacin necesaria del producto.
Un documento utilizado para la planificacin del diseo y desarrollo puede ser un nico documento, una parte
de otro documento, o estar compuesto de varios documentos.
La planificacin se debera revisar peridicamente y corregir cualquier diseo, segn corresponda.
5.4 Transicin de servicios nuevos o modificados
La transicin de servicios nuevos o modificados se debera coordinar con el proceso de gestin del cambio, el
proceso de gestin de la entrega y despliegue y el proceso de gestin de la configuracin. La adopcin de este
enfoque debera asegurar que el control de los cambios aplica a la transicin del servicio nuevo o modificado.
La transicin de servicios debera incluir la construccin, prueba y aceptacin de los servicios nuevos o
modificados, continuando por hacer operativos los servicios nuevos o modificados a travs del proceso de
gestin de la entrega y despliegue.

La transicin se debera revisar con el cliente y las partes interesadas para establecer que ya est lista para la
operacin real. La decisin que resulte debera quedar registrada, junto con la aceptacin del cliente del
servicio nuevo o modificado en la operacin real. La transicin debera continuar hasta que sea acordado que
las actividades restantes son parte de la operacin real normal. Par continuar con la conclusin de la
transicin, el proveedor del servicio debera informar a las partes interesadas sobre los resultados logrados por
los servicios nuevos o modificados frente a los resultados planificados.
Los criterios de aceptacin del servicio se deberan revisar por el proveedor del servicio y las otras partes
interesadas. Cuando hay criterios de aceptacin destacados que no se han cumplido antes de la transicin de
un servicio, se debera decidir si la ausencia de estos criterios representa un riesgo significativo para el
servicio. Cuando el riesgo es significativo, se debera retrasar la transicin. Sin embargo, cuando hay
mitigacin del riesgo o el riesgo no es significativo, se puede decidir proceder con la transicin. En este caso,
las acciones destacadas y sus dueos se deberan registrar en la declaracin de criterios de aceptacin del
servicio y se deberan dar los pasos para asegurar que estas acciones se cumplan.
El proveedor del servicio debera registrar la aceptacin por el cliente y las partes interesadas de los servicios
nuevos o modificados frente a los criterios de aceptacin acordados.
5.5 Documentos y registros
Los documentos y registros, que se deberan generar y retener durante el proceso de diseo y transicin de
servicios nuevos o modificados deberan incluir:
a) requisitos del servicio para el servicio nuevo o modificado;
b) evaluacin de riesgos para cada solicitud de un servicio nuevo o modificado;
c) plan para el diseo, desarrollo y transicin del servicio nuevo o modificado;
d) un plan para los servicios a eliminar;
e) un informe de evaluacin de otras partes que contribuyen al servicio nuevo o modificado;
f) especificaciones de diseo para el servicio nuevo o modificado;
g) criterios de aceptacin del servicio;
h) informe de la transicin, que describa el resultado logrado frente al resultado esperado.
Es crtico que el proceso tenga acceso a la poltica sobre servicios nuevos o modificados en el alcance de
clusula 5 desarrollada y mantenida como parte del proceso de gestin del cambio.
5.6 Autoridades y responsabilidades
Adems del dueo del proceso, el gerente del proceso y el personal que ejecuta los procedimientos del proceso
segn se describe en 4.4.2.1, entre las autoridades y responsabilidades requeridas dentro del proceso de diseo
y transicin de servicios nuevos o modificados se debera incluir:
a) un gerente de servicios nuevos o modificados, generalmente un gerente de proyectos, responsable de la

prestacin y gestin de los entregables del proyecto y de asegurar el cumplimiento de los criterios de
aceptacin del servicio;
b) un grupo que pueda valorizar el impacto del servicio nuevo o modificado propuesto sobre el SGS desde
mltiples perspectivas, incluyendo polticas, objetivos y procesos.

c) un grupo, que puede ser el mismo que el anterior, que pueda estar involucrado en la planificacin de
todos los requisitos de los servicios nuevos o modificados y en la aceptacin de la prestacin de un
servicio nuevo o modificado.
d) representantes del cliente y del negocio, responsables de la documentacin y el acuerdo de todos los
requisitos de los servicios nuevos o modificados y de la aceptacin de la prestacin de servicios nuevos o
modificados.
6 Procesos de prestacin del servicio
6.1 Gestin del nivel de servicio
El proceso de GNS debera asegurar que un servicio acordado se suministre y que las metas del servicio se
cumplan. Se deberan desarrollar metas especficas y medibles para todos los servicios. El proceso de GNS
asegura que los servicios y sus metas se documenten de una forma que sea fcilmente comprensible para el
cliente.
6.1.2 Conceptos
El proceso de GNS debera definir, acordar, documentar, hacer monitoreo, informar y revisar los servicios
prestados. A fin de asegurar que la prestacin de los servicios sea alcanzable, gestionada y en alineacin con los
requisitos del cliente y las necesidades del negocio, el proceso de GNS trabaja estrechamente con el proceso de
gestin de la relaciones con el negocio (GRN) y el proceso de gestin de proveedores.
El proceso de GNS debera definir la integracin entre el proceso de gestin de proveedores, prestacin de
servicios para el proveedor del servicio y el proceso de GRN.
El proceso de GNS trabaja estrechamente con la gestin de proveedores y los procesos de GRN para asegurar
que los servicios prestados y las metas del servicio se alinean con las necesidades del negocio y los requisitos del
cliente.
El proceso de gestin de proveedores debera asegurar que las metas del servicio acordadas con los proveedores
estn alineadas con el proceso de GNS, como as tambin otra informacin de gestin necesaria para asegurar
que se pueden realizar las revisiones del servicio.
El proceso de GNS tambin debera proporcionar el proceso de gestin de proveedores con todos los detalles de
los cambios que afectan los requisitos con los proveedores. Por ejemplo, nuevos requisitos de un servicio que
implica que se deben cambiar el contrato con un proveedor. Otros ejemplos incluyen cambios para procesos y
procedimientos que afectan la interface entre el proveedor del servicio quien es responsable por la gobernanza de
los procesos y los proveedores que operan procesos en nombre del proveedor del servicio.
El proceso de GNS tambin debera proporcionar el proceso de GRN con metas del servicio acordadas para
cumplir los requisitos del cliente, como as tambin otra informacin de gestin necesaria para asegurar que se
pueden realizar las revisiones del servicio al cliente.
El proceso de GNS debera negociar, acordar y documentar los requisitos para los servicios nuevos o
modificados a travs de los documentos de requisitos del nivel de servicio, y a continuacin los debera gestionar
y revisar a travs del ciclo de vida del servicio, creando SLA firmados por servicios operativos.
NOTA - En Anexo A se describen ejemplos de interfaces entre el proceso de GNS y otros procesos del SGS.

6.1.3.1 Documentacin de compromisos del servicio
Los SLA pueden necesitar ser apoyados por acuerdos con proveedores externos a la organizacin del proveedor
del servicio, o con grupos internos. Estos acuerdos de apoyo con proveedores pueden ser conocidos como los
contratos de sustento.
Los acuerdos de apoyo con grupos internos pueden ser conocidos como acuerdos de nivel operativo. Estos no
pueden ser legalmente vinculantes para ninguna de las partes, pero pueden ser tratados como si lo fueran. Las
restricciones combinadas de todos los acuerdos que apoyan un SLA se debera considerar antes que el SLA
finalice.
El proveedor del servicio debera hacer monitoreo y medir los logros del desempeo del servicio de todos los
servicios operativos frente metas de los SLA, acuerdos del nivel operacional, u otros acuerdos de desempeo y
generar los informes del servicio. Las revisiones del servicio se deberan realizar al igual que la creacin de los
planes de mejoramiento del servicio, a intervalos regulares, al menos anualmente.
6.1.3.2 Catlogo de servicios
El proveedor del servicio debera definir todos los servicios en un catlogo, utilizando trminos que estn
alineados con la visin del cliente y comprensibles para aquellos sin un entendimientos tcnico detallado. El
catlogo de servicios debera cotejar y presentar todas las definiciones del servicio. El alcance de cada servicio
definido debera ser pertinente a las actividades del negocio del cliente. El catlogo debera mantener
informacin comn para todos o para la mayora de los servicios, a fin de simplificar los SLA, segn se describe
en 6.1.3.4. El catlogo de servicios debera incluir una diversidad de informacin, incluyendo:
a) el nombre y descripcin del servicio;
b) metas del servicio, por ejemplo, tiempo para cumplir una solicitud de servicio, tiempo para poner en marcha
un servicio para un usuario nuevo, tiempo para restablecer un servicio despus de una falla importante;
c) puntos de contacto;
d) horas de servicio, horas de soporte y excepciones;
e) medidas de seguridad;
f) servicios actuales;
g) dependencias entre los servicios y los componentes del servicio, por ejemplo, un servicio de soporte al
laptop de un usuario incluye el soporte de las aplicaciones, soporte para el acceso a internet y soporte del
hardware, cada uno de los cuales puede ser suministrado por distintos proveedores o grupos internos.
NOTA - Los ejemplos listados no son exhaustivos.
El proveedor del servicio debera asegurar que el catlogo de servicios est diseado de modo que la
informacin es fcil de mantener. La agrupacin lgica y eficiente de la informacin es particularmente
importante para la informacin que se somete a un cambio relativamente rpido. Esto minimiza el gasto general
del proceso de gestin del cambio, segn se describe en 6.1.3.4.

El catlogo de servicios tambin debera mostrar las dependencias entre servicios y servicios de soporte. Por
ejemplo cuando un servicio del negocio es dependiente de un nmero de servicios de sustento tal como el correo
electrnico, servicios de seguridad y red. Otros ejemplos incluyen un servicio que es dependiente de los
componentes del servicio que prestan los proveedores o los grupos internos fuera del control directo del
proveedor del servicio.
El catlogo de servicios es un documento clave para establecer la expectativas del cliente y debera estar
ampliamente disponible tanto para el cliente como para el personal de soporte.
6.1.3.3 Acuerdos del nivel de servicio
El cliente y el proveedor del servicio deberan acordar sobre los trminos y metas para un servicio a prestar, y
documentar stos en un SLA. Un SLA es un documento que describe al servicio y las metas del servicio. Un
SLA tambin especifica las responsabilidades del proveedor del servicio y del cliente. Un nico SLA puede
cubrir mltiples servicios o mltiples clientes. Los SLA deberan cubrir todos los componentes necesarios para
prestar el servicio.
Los requisitos del cliente, las necesidades del negocio y las capacidades del proveedor del servicio deberan ser
la fuerza determinante para el contenido, estructura y metas del SLA. Las metas, frente a las cuales se debera
medir el servicio prestado, se deberan definir desde la perspectiva del cliente.
El proveedor del servicio debera ser consciente que demasiadas metas en un SLA puede crear confusin y llevar
a gastos generales excesivos sin percibir beneficios. Los SLA slo deberan incluir un subconjunto apropiado de
las metas para enfocar la atencin sobre los aspectos ms importantes del servicio para el negocio y el cliente.
El contenido mnimo que debera estar en un SLA o que pueda ser directamente referenciado desde un SLA en
un catlogo de servicios es:
a) breve descripcin del servicio;
b) periodo de validez y/o mecanismo de control de cambios del SLA;
c) detalles de la aprobacin de los cambios;
d) breve descripcin de las comunicaciones, incluyendo presentacin de informes, frecuencia de revisin y

calendario;
e) horas de servicio, por ejemplo 09:00 h a 17:00 h, excepciones de fechas, por ejemplo fines de semana,
vacaciones pblicas, periodos crticos del negocio y cobertura fuera de horario.
f) interrupciones a los servicios calendarizadas y acordadas, incluyendo el aviso a dar y el nmero por
periodo;
g) responsabilidades del cliente, por ejemplo el uso correcto de los sistemas, adherencia a la poltica de
seguridad de la informacin;
h) responsabilidades y obligaciones del proveedor del servicio, por ejemplo, seguridad;
i) directrices de impacto y prioridad;
j) proceso de notificacin y escalada;
k) procedimiento de reclamos;

l) metas del servicio;
m) lmites de carga de trabajo superior e inferior, por ejemplo la capacidad del servicio para soportar el nmero
acordado de usuarios y/o volumen de trabajo, rendimiento del sistema;
n) detalles de la gestin financiera de alto nivel, por ejemplo, cdigos de carga;
o) acciones a seguir en el evento de una interrupcin a un servicio, incluyendo tanto incidentes como desastres,
son normalmente referenciados desde un SLA;
p) glosario de trminos;
q) soporte y servicios relacionados;
r) las excepciones a los trminos dados en el SLA.
La informacin que cambia frecuentemente o la informacin comn a muchos SLA se puede suministrar
mediante una referencia en el SLA a los documentos tales como los gerenteios telefnicos o de correo
electrnico y los diagramas estructurales organizacionales. Esto simplifica la gestin del cambio del SLA sin
afectar la calidad de proceso de GNS. Debera ser comn a todos los documentos, un glosario de trminos,
normalmente mantenido en el lugar, que incluya el catlogo de servicios. Esto slo es viable si los documentos
referenciados tambin estn bajo el control del proceso de gestin del cambio. El SLA y cada servicio que se
describe en el SLA se debera someter al proceso de gestin del cambio.
6.1.3.4 Gestin del catlogo de servicios y prestacin del servicio
El proveedor del servicio debera tener un procedimiento para hacer que el catlogo de servicios est fcilmente
disponible para aquellos que necesitan desempear sus roles eficazmente. El procedimiento tambin debera
asegurar que el catlogo se mantiene actualizado y es fcil mantenerlo al da, sin necesitar habilidades o
conocimientos especializados fuera del alcance del personal que utiliza el catlogo. Se deberan hacer
verificaciones regulares de la exactitud de la informacin que se mantiene en el catlogo.
Los cambios mayores del negocio, por ejemplo debidos al crecimiento, reorganizaciones del negocio y fusiones
o cambios en los requisitos del cliente, pueden necesitar que los niveles de servicio se ajusten, redefinan o
incluso sean temporalmente suspendidos.
Los cambios al catlogo de servicios o a los SLA se deberan iniciar y gestionar a travs del proceso de gestin
del cambio, para asegurar que los cambios no se implementen sin que se haya gestionado el impacto global.
El proceso de GNS debera ser lo suficientemente flexible para ajustarse a estos cambios. El proceso de GNS
debera asegurar que el proveedor del servicio se sigue enfocando en el cliente a travs de la planificacin,
implementacin y gestin continua de la prestacin del servicio. El proveedor del servicio debera trabajar con el
proceso de GRN y el cliente para comprender de los impulsores y requisitos del negocio del cliente.
El proceso de GNS debera gestionar y coordinar los contribuyentes a los niveles de servicio, para identificar:
a) el acuerdo de los requisitos del servicio y caractersticas de la carga de trabajo del servicio esperada;
b) el acuerdo sobre las metas del servicio;
c) la medicin e informe de los niveles de servicio logrados, cargas de trabajo y una explicacin si las metas
acordadas no se cumplen (ver 6.2);
d) la revisin del desempeo del servicio con el cliente para confirmar el desempeo informado y la
satisfaccin del cliente;

e) el inicio de las acciones correctivas o preventivas;
f) la entrada a un plan para el mejoramiento del servicio;
g) la revisin de la conveniencia y alineacin de los niveles de servicio y del catlogo de servicios con los
requisitos del negocio de acuerdo con las actividades de planificacin acordadas, como mnimo anualmente.
El proceso debera incentivar al proveedor del servicio y al cliente a desarrollar una actitud proactiva hacia el
mejoramiento del servicio y debera asegurar que tienen la responsabilidad conjunta por el servicio.
La satisfaccin del cliente es una parte importante del porceso de GNS pero se debera reconocer que es una
medicin subjetiva, mientras que las metas del servicio dentro de un SLA deberan ser mediciones objetivas. El
proceso de GNS debera trabajar estrechamente con los procesos de relaciones con el negocio y gestin de
proveedores para gestionar tanto la satisfaccin del cliente como para lograr las metas del servicio.
El catlogo de servicios y los SLA se deberan revisar con el cliente de acuerdo a las actividades de planificacin
acordadas.
6.1.3.5 Gestin de otras partes
El proveedor del servicio debera reconocer que un cliente puede actuar como proveedor y como cliente. Por
ejemplo, un grupo especializado en la organizacin del cliente puede suministrar un componente del servicio,
pero tambin recibe un servicio dentro del alcance del SGS del proveedor del servicio. Si este es el caso, el
proveedor del servicio debera utilizar el proceso de GNS para gestionar al cliente que acta como un proveedor.
En forma similar, un grupo interno que no sea incluido en el SGS debera ser gestionado por el proveedor del
servicio utilizando el proceso de GNS.
NOTA - La gestin de proveedores, por definicin externa a la organizacin del proveedor del servicio, est bajo
el proceso de gestin de proveedores en 7.2.
6.1.4 Documentos y registros
Documentos que genera y utiliza el cliente, el proveedor del servicio y las partes interesadas deberan incluir:
a) catlogo de servicios;
b) todos los SLA y otros acuerdos pertinentes;
c) procesos y procedimientos pata el proceso de GNS, incluyendo la gestin del catlogo de servicios y los
SLA;
d) entradas y salidas de las revisiones del proceso de GNS, el catlogo de servicios y los SLA;
e) requisitos de los informes del servicio;
f) revisin de las actividades de planificacin del servicio;
g) registros de revisin del servicio y oportunidades de mejoramiento identificadas;
h) planes de mejoramiento del servicio.

6.1.5 Autoridades y responsabilidades
segn se describe en 4.4.2.1, entre las autoridades y responsabilidades requeridas dentro del proceso de GNS
debera incluir lo siguiente:
a) La operacin del proceso y la gestin de los recursos y las comunicaciones debera ser la responsabilidad de
un gerente del nivel de servicio. Este gerente tambin es responsable por el personal del proveedor del
servicio que ejecuta los procedimientos.
b) Un representante del cliente y el gerente del nivel de servicio son conjuntamente responsables por la
autorizacin del catlogo de servicios y cada SLA es la responsabilidad del cliente y del gerente del nivel de
servicio. Estos dos roles deberan tener suficiente autoridad para acordar las definiciones de un servicio en
el catlogo y las metas del servicio.
6.2 Informes del servicio
El proceso de informes del servicio debera asegurar la generacin de informes acordados, oportunos, confiables
y exactos, para facilitar la toma de decisiones informadas y la comunicacin efectiva.
6.2.2 Conceptos
El xito de todos los procesos de la gestin del servicio depende del uso de la informacin suministrada en los
informes del servicio. El monitoreo y los informes del servicio deberan abarcar todos los aspectos medibles del
servicio, proporcionando un anlisis tanto actual como histrico.
Los informes del servicio deberan ser apropiados para las necesidades del pblico y de exactitud suficiente para
ser utilizados como una herramienta de apoyo a las decisiones. El lenguaje y presentacin debera ayudar el
entendimiento de los informes de modo que sean fciles de asimilar, por ejemplo, el uso de diagramas.
Los requisitos para los informes del servicio los deberan acordar y registrar el cliente y la gerencia interna. Se
deberan generar diversos tipos de informes. Estos incluyen informes reactivos y proactivos. Los informes
reactivos muestran qu ha ocurrido, despus que ha ocurrido. Los informes proactivos dan advertencias de
eventos significativos, con lo cual se permite que se tomen acciones preventivas de antemano, por ejemplo, un
informe que identifique la necesidad de una mayor redundancia para un servicio crtico del negocio, para
prevenir que ocurran incidentes que afecten al cliente. Otro tipo de informes incluyen calendarios e informes de
pronsticos. Estos muestran las actividades planificadas.
El proveedor del servicio debera generar informes para el cliente y la gerencia que incluyan al menos:
a) el desempeo frente a las metas del servicio, por ejemplo, excepciones o casi excepciones frente a las
metas, informes de cortes y logros;
b) las caractersticas de la carga de trabajo incluyendo el volumen de informacin y los cambios peridicos en
la carga de trabajo, por ejemplo, incidentes, problemas, cambios y actividades, clasificacin, ubicacin,
cliente, tendencias estacionales, mezcla de prioridades, nmero de solicitudes de ayuda, el perfil de edad de
la carga de trabajo pendiente;
c) las no conformidades con ISO/IEC 20000-1 identificadas durante auditoras internas;

d) el desempeo informados de las acciones correctivas y preventivas, lecciones aprendidas despus de los
eventos importantes, por ejemplo, incidentes mayores, diseo, transicin y entrega de servicios nuevos o
modificados, e interrupciones a la continuidad del servicios o pruebas y actividades de mejoramiento;
e) las proyecciones de tendencias actuales para ayudar a predecir el desempeo futuro;
f) el monitoreo de la resolucin para la satisfaccin del cliente de las acciones correctivas y preventivas para
tratar los reclamos, la retroalimentacin negativa a partir de las mediciones de la satisfaccin del cliente, y
sus causas races;
g) los pronsticos y planes, por ejemplo proyectos financieras, planes de carga de trabajo, calendario de
cambios planificados.
Cuando hay mltiples proveedores, proveedores principales y proveedores subcontratados, los informes deberan
reflejar las relaciones entre los proveedores, por ejemplo, un proveedor principal debera informar sobre la
totalidad del servicio que se presta, incluyendo los servicios de proveedores subcontratados que gestiona como
partes del servicios del cliente.
Las decisiones relacionadas al servicio, incluyendo aquellas tomadas por la alta gerencia, y las acciones que
resulten de cada una, se deberan basar en los hallazgos contenidos en los informes del servicio. El SGS debera
incluir un procedimiento que verifique rutinariamente que tales decisiones han sido validadas mediante
informacin de los informes del servicio, por ejemplo, informes de disponibilidad previa o desempeo utilizados
como una base para invertir en una mayor capacidad. No todas las decisiones relacionadas al servicio se pueden
basar en los informes del servicio. Ejemplos de excepciones incluyen cambios legales y reglamentarios, estudios
de mercado externos, cambios en la estructura del negocio, o avances tecnolgicos.
Cuando sea pertinente, el proveedor del servicio debera asegurar que los informes y resultados de cada proceso
se comunican a todas las partes interesadas, incluyendo a la alta gerencia, dueos de procesos, el cliente,
proveedores y proveedores principales.
segn se describe en 4.4.2.1, entre las autoridades y responsabilidades necesarias dentro del proceso de informes
del servicio se debera incluir:
a) personal responsable por la generacin y distribucin oportuna y exacta de los informes del servicio para los
destinatarios pertinentes;
b) personal responsable de la definicin de contenidos de cada informe, incluyendo su formato, contenidos,

estilo y frecuencia;
c) dueos de procesos de otros procesos de gestin del servicio, dueos del servicio, grupos tcnico y otras
partes interesadas, quienes deberan analizar informes e identificar, priorizar y accionar mejoramientos.
6.3 Gestin de la continuidad y disponibilidad del servicio
El proceso de la gestin de la continuidad y disponibilidad del servicio debera asegurar que los compromisos de
continuidad y disponibilidad del servicio acordados se pueden cumplir, dentro de las metas acordadas.

6.3.2 Conceptos
El proceso de gestin de la continuidad y disponibilidad del servicio incluye un enfoque en la prevencin de, y
recuperacin frente a, las fallas del sistema o desastres, como as tambin asegurar la provisin de suficiente
disponibilidad del servicio para cumplir los requisitos del mismo.
Los proveedores de servicios pueden operar el proceso de gestin de la continuidad y disponibilidad del servicio
como dos procesos separados que estn vinculados. Alternativamente, el proveedor del servicio puede operarlos
como un nico proceso. La decisin se debera basar en las circunstancias del proveedor del servicio y se debera
documentar como parte del SGS.
El proceso de gestin de la continuidad y disponibilidad del servicio debera permitir tanto aspectos reactivos
como proactivos del proceso y la priorizacin de la criticidad del negocio de los servicios acordados. El proceso
de la continuidad y disponibilidad del servicio tambin debera capturar datos para permitir que los servicios
sean sometidos a monitoreo, gestionados, revisados y mejorados por el proveedor del servicio e informados al
cliente cuando sea pertinente.
El proveedor del servicio debera desarrollar planes efectivos para asegurar que los requisitos acordados se
cumplen. Estos requisitos incluyen requisitos de disponibilidad y continuidad bajo circunstancias normales y
despus de una prdida importante de servicio. Los planes deberan incluir soluciones para los aumentos o las
disminuciones en los niveles de servicio, peaks esperados en la actividad y un entendimiento de los requisitos
nuevos o modificados para tratar la necesidad futura del negocio por la continuidad y disponibilidad del servicio.
6.3.3.1 Evaluacin y gestin del riesgo
Una caracterstica clave del proceso de gestin de la continuidad y disponibilidad del servicio debera ser la
evaluacin del riesgo y la gestin del riesgo. La evaluacin del riesgo debera incluir el anlisis del impacto en el
negocio de un prdida importante de servicio.
Los requisitos de la continuidad y disponibilidad del servicio se deberan identificar y acordar en base a los
requisitos del servicio acordado, los resultados obtenidos de los ejercicios de anlisis de impacto en el negocio,
las prioridades del negocio del cliente, polticas y planes, SLA y riesgos evaluados. El proveedor del servicio
debera mantener una capacidad de servicio suficiente, junto con planes eficaces diseados para asegurar que los
niveles de servicio acordados se mantienen en el evento de una prdida importante de servicio.
Asegurar que los niveles del servicio se mantienen despus de una prdida importante de servicio debera tener
en consideracin aquellos elementos de la operacin real del servicio que estn bajo el control de otras partes
tales como el cliente o los proveedores.
Los requisitos de la continuidad y la disponibilidad del servicio para un servicio normal y despus de una
prdida importante de servicio debera incluir al menos lo siguiente:
a) derechos de acceso, por ejemplo, quin puede tener derechos de acceso bajo condiciones normales y quin
puede tener la prioridad ms alta para acceder a un servicio limitado, despus de una prdida importante de
servicio;
b) tiempos de respuesta, por ejemplo, tiempos de respuesta bajo circunstancias normales y tambin despus de
una prdida importante de servicio. Se debera definir y acordar con el cliente lo que es tiempo de respuesta
aceptable para los distintos servicios y qu acciones se deberan tomar para asegurar que los tiempos de
respuesta acordados se logran;

c) disponibilidad de los servicios de extremo a extremo, por ejemplo, para el servicio normal lo que es
necesario es la disponibilidad de componentes necesarios para prestar un servicio completo. Despus de una
prdida importante de servicio se debera prioridad a que cada servicio especfico retorne a un desempeo
normal.
6.3.3.2 Poltica de continuidad del servicio
El proveedor del servicio puede encontrar til desarrollar y mantener una poltica que defina el enfoque general
para cumplir las obligaciones de la continuidad del servicio. El alcance de la poltica de continuidad del servicio
debera ser consistente con el alcance del SGS.
La poltica debera definir un mtodo consistente para determinar la resiliencia necesaria versus la real para cada
servicio y para priorizar eficazmente las oportunidades de mejoramiento en alineacin con la criticidad del
negocio de los servicios.
La poltica de continuidad del servicio debera conducir las actividades de planificacin de la continuidad del
proveedor dentro del alcance del plan de continuidad del servicio.
La poltica debera abordar los roles, actividades y responsabilidades necesarias para cumplir los requisitos del
servicio acordado.
La poltica debera definir las interfaces entre el proceso de gestin de la continuidad y disponibilidad del
servicio y otros procesos de gestin del servicio. En Anexo A se incluye informacin sobre las interfaces entre el
proceso de gestin de la continuidad y disponibilidad del servicio y otros componentes del SGS.
La poltica debera tomar en cuenta las horas de servicio acordadas y los periodos crticos del negocio. El
proveedor del servicio debera identificar los requisitos separadamente para cada grupo de clientes y servicio,
incluyendo:
a) el periodo continuo mximo aceptable de prdida de servicio;
b) los periodos mximos aceptables de servicio degradado;
c) los niveles de servicio degradado aceptables durante un periodo de recuperacin del servicio.
Las horas de servicio acordadas y los periodos crticos del servicio se deberan definir en relacin a ciclos
especficos del negocio y su criticidad asociada, por ejemplo, fin de mes, fin de ao, periodos de vacaciones.
Si el proveedor del servicio se basa en una poltica de continuidad del servicio para dirigir el proceso, la poltica
de continuidad del servicio se debera revisar a intervalos acordados, al menos anualmente. Los cambios en la
poltica se deberan acordar formalmente entre el proveedor del servicio y el cliente.
6.3.3.3 Planes de continuidad y disponibilidad del servicio
Si una poltica de continuidad del servicio est en su lugar, el proveedor del servicio puede alinear la poltica con
una estrategia de continuidad del servicio. Debera ser apropiada a la criticidad de los servicios basados en el
anlisis de impacto en el negocio de los servicios. El proveedor del servicio tambin debera incluir informacin
pertinente de otros procesos de gestin del servicio como entrada en la estrategia de continuidad del servicio.
Una vez que se define la estrategia, se debera realizar un anlisis de riesgo para identificar continuamente los
riesgos que entran en conflicto con la estrategia y definir controles para gestionarlos o instigar acciones de
mitigacin cuando el nivel de riesgo es inaceptable.

El proveedor del servicio debera mantener suficiente capacidad de servicio, junto con planes trabajables
diseados para asegurar que los requisitos acordados se puedan cumplir.
El proveedor del servicio debera desarrollar planes de continuidad y disponibilidad del servicio, planes y
procedimientos de recuperacin, y las polticas de las pruebas de continuidad del servicio. Los planes de
continuidad del servicio y las polticas de las pruebas se deberan disear para reducir el impacto de las
interrupciones importantes sobre las funciones y procesos claves del negocio.
El plan de continuidad del servicio se debera basar en los requisitos definidos en la poltica de continuidad del
servicio, en un anlisis de impacto en el negocio y en las evaluaciones del riesgo.
La operacin continua debera definir los requisitos para la educacin, concientizacin y formacin, revisin y
auditora de la continuidad del servicio, pruebas de continuidad del servicio y coordinacin con el proceso de
gestin del cambio. Los planes de continuidad del servicio se deberan probar regularmente y las
responsabilidades para la invocacin se debera asignar claramente. Las pruebas de continuidad del servicio se
deberan realizar al menos anualmente o despus de cada cambio importante del negocio. Las sesiones de
formacin regulares se deberan proporcionar a todas las partes pertinentes. Se debera contar con una poltica de
distribucin definida y gestionada para la conservacin de la continuidad del servicio y con planes de
recuperacin. Todos los medios de respaldo crticos, la documentacin y otros recursos necesarios para la
recuperacin se deberan almacenar fuera del sitio.
El proveedor del servicio debera asegurar que:
a) los planes de continuidad del servicio tomen en cuenta las dependencias entre los servicios y componentes
del servicio;
b) los planes de continuidad del servicio y otros documentos necesarios para apoyar la continuidad del servicio
se registran y mantienen;
c) la responsabilidad de invocar los planes de continuidad del servicio se asigna claramente, y los planes
claramente especifican las responsabilidades para tomar accione frente a cada requisito de recuperacin de
la poltica;
d) los respaldos de datos, documentos y software, y cualquier equipo y personal necesario para la restauracin
del servicio estn rpidamente disponibles despus de una falla importante del servicio o desastre;
e) los documentos de continuidad del servicio, por ejemplo, los planes y calendarios de continuidad del
servicio, listas de contacto y la CMDB, sigue siendo accesible durante una interrupcin;
f) el personal comprenda su rol al invocar y/o ejecutar los planes;
g) cuando sea apropiado, existen acuerdos de reserva con los proveedores y proveedores de recuperacin del
sitio.
Los planes de continuidad del servicio y los documentos relacionados, por ejemplo los contratos, deberan ser
objeto de una evaluacin de impacto antes que los cambios en el sistema o servicio sea aprobado, y antes que los
requisitos significativos nuevos o corregidos del cliente sean acordados. Los planes de continuidad del servicio y
los documentos relacionados tambin se deberan revisar y probar al menos anualmente.

Se debera desarrollar y publicar un plan de disponibilidad. El plan de disponibilidad debera identificar las
necesidades del negocio y los requisitos del cliente, los requisitos de diseo, especificaciones tcnicas y las
actividades de planificacin del proyecto necesarias para cumplir los requisitos de disponibilidad del negocio
tanto en la actualidad como en el futuro. Las predicciones respecto de la disponibilidad futura documentada en el
plan de disponibilidad debera incluir acciones preventivas propuestas para mitigar la probabilidad de no
disponibilidad no planificada. El plan de disponibilidad se debera examinar y revisar regularmente, al menos
anualmente y despus de cualquier cambio importante.
La planificacin y diseo de la disponibilidad de los servicios nuevos o modificados se debera basar en la

criticidad de los servicios para el negocio, y debera equilibrar los costos frente al riesgo aceptable del negocio.
Se deberan registrar e investigar todos los servicios y componentes del servicio no disponibles y se deberan
tomar las acciones apropiadas para reducir el impacto y/o probabilidad de cualquier ocurrencia futura.
6.3.4 Monitoreo y pruebas de continuidad y disponibilidad del servicio
6.3.4.1 Pruebas de continuidad del servicio
Las pruebas de continuidad del servicio se deberan realizar despus de cada cambio importante del negocio y el
cambio al entorno del servicio. La frecuencia se debera basar en las circunstancias del proveedor del servicio.
La frecuencia debera ser suficiente para obtener la seguridad de que los planes de continuidad del servicio son
eficaces, y lo siguen siendo a travs de la evolucin de los cambios de sistemas, procesos, personal y necesidades
del negocio. El alcance de las pruebas de continuidad del servicio debera incluir el retorno al funcionamiento
normal del servicio despus de una interrupcin.
Las pruebas de continuidad del servicio deberan contar con la participacin conjunta del cliente y del proveedor
del servicio, basada en un conjunto de objetivos acordados. Cuando sea aplicable, tambin se debera incluir a
otras partes. Las fallas en las pruebas se deberan documentar y revisar como entrada en un plan para mejorar el
servicio.
Se debera realizar una revisin despus de una prueba de continuidad del servicio para evaluar el logro de los
fines y objetivos de la prueba y para identificar las reas de debilidad o las oportunidades de mejoramiento.
6.3.4.2 Monitoreo y pruebas de disponibilidad
La gestin de la continuidad y disponibilidad del servicio debera, de acuerdo al plan de disponibilidad acordado:
a) realizar el monitoreo y registro de la disponibilidad del servicio;
b) mantener datos histricos exactos respecto a la disponibilidad de los servicios;
c) hacer comparaciones con los requisitos definidos en los SLA para identificar cualquier no conformidad a la
metas de disponibilidad acordadas;
d) documentar y revisar no conformidades;
e) predecir los requisitos futuros de disponibilidad.
Un calendario de pruebas regulares de disponibilidad debera confirmar que las soluciones de disponibilidad son
logrables y apropiadamente resilientes. Los mecanismos de disponibilidad, confiabilidad y resiliencia se
deberan revisar y probar despus de cualquier cambio importante.

Cuando sea posible, se debera predecir los asuntos potenciales y tomar acciones preventivas. La gestin de la
continuidad y disponibilidad del servicio se debera esforzar por lograr y mejorar los niveles de confiabilidad
definidos para todos los componentes del servicio, con acciones correctivas y preventivas identificadas,
registradas e implementadas en consecuencia.
6.3.4.3 Gestin del riesgo de disponibilidad
Las evaluaciones del riesgo deberan identificar las funciones vitales del negocio y los requisitos de
disponibilidad, y los riesgos acordados con el negocio.
La gestin del riesgo debera generar soluciones para permitir la prestacin de los niveles de disponibilidad
requeridos, y mediante la implementacin de contramedidas de costos justificables para mitigar los riesgos
identificados cuando sea posible. No es recomendable superar los requisitos a travs de inversiones financieras
importantes que cuestan mucho ms que los beneficios de mejorar la disponibilidad.
La planificacin y el diseo de la disponibilidad de los servicios nuevos o modificados se debera basar en la

criticidad del negocio del servicio, la importancia para el negocio de distintos periodos de trabajo y las horas de
servicio requeridas.
El monitoreo regular, la medicin, el anlisis de informes y revisiones del servicio y la disponibilidad de los
componentes deberan ser un aspecto esencial del proceso. Se deberan mantener todos los datos referentes a la
disponibilidad y no disponibilidad de los servicios. Los informes de las metas de disponibilidad logradas
deberan utilizar datos histricos reales y el enfoque de la medicin y presentacin de informes se debera alinear
con las metas acordadas.
La evaluacin de solicitudes de cambio para todos los servicios nuevos o modificados debera tomar en
consideracin los impactos potenciales de los riesgos para las metas de disponibilidad acordadas. Los
mecanismos de disponibilidad, confiabilidad y resiliencia se deberan revisar y probar regularmente despus de
cualquier cambio importante.
Los criterios de diseo de la disponibilidad deberan definir los productos bsicos, la tecnologa y los
componentes que ofrecen la confiabilidad necesaria.
6.3.4.4 Revisin despus de la invocacin de un plan de continuidad del servicio
La revisin despus de la invocacin de un plan de continuidad del servicio se debera llevar a cabo para:
a) identificar la naturaleza y causa de la interrupcin del servicio que inici la activacin del plan;
b) evaluar la adecuacin de la respuesta de la gerencia;
c) evaluar la eficacia de la organizacin en el cumplimiento de sus objetivos de tiempo de recuperacin;
d) evaluar la adecuacin de las pruebas y del plan de continuidad del servicio en la preparacin de personal
para la activacin del plan;
e) identificar los mejoramientos a introducir en el plan de continuidad del servicio y en las pruebas.
Los documentos y registros que se deberan generar y retener por el proceso de gestin de la continuidad y
disponibilidad del servicio deberan incluir pero sin limitarse a:
a) polticas de gestin de la continuidad y disponibilidad del servicio;

b) anlisis de impacto en el negocio;
c) informes de evaluacin del riesgo;
d) planes de continuidad y disponibilidad del servicio;
e) requisitos del cliente para de la continuidad y disponibilidad del servicio;
f) restricciones y datos de la disponibilidad de los componentes del servicio;
g) diseos de la continuidad y disponibilidad del servicio;
h) planes de pruebas de continuidad y disponibilidad del servicio;
i) informes de pruebas de continuidad y disponibilidad del servicio;
j) procedimientos y procesos de gestin de la continuidad y disponibilidad del servicio;
k) registros y requisitos de formacin de conciencia;
l) base de datos de la gestin de la disponibilidad;
m) informes de monitoreo de la disponibilidad;
n) mantenimiento y horarios previstos para los cortes del servicio.
El personal debera comprender su rol al invocar y/o ejecutar los planes y ser capaz de acceder rpidamente a los
documentos de la continuidad del servicio.
Los planes de continuidad del servicio y los documentos relacionados, por ejemplo los contratos, se deberan
evaluar en cuanto a su impacto potencial como parte del proceso de gestin del cambio, del proceso de GNS y
del proceso de gestin de proveedores. Por ejemplo, antes de aceptar servicios nuevos o modificados o acordar
requisitos del servicio.
segn se describe en 4.4.2.1, entre las autoridades y responsabilidades requeridas dentro del proceso de gestin
de la continuidad y disponibilidad del servicio se debera incluir:
a) administrador de la disponibilidad, responsable de asegurar que la infraestructura para el monitoreo y

recoleccin de datos relacionados a la disponibilidad de componentes y servicios ocurre correctamente y
segn sea necesario;
b) un equipo tcnico de recuperacin, responsable de planificar la recuperacin frente a desastres, pruebas y

restauracin de los servicios;
c) el cliente, personal del proveedor del servicio y partes interesadas quienes necesitan acceso a la informacin
de la gestin de la continuidad y disponibilidad del servicio, participan en las pruebas y acuerdan los
requisitos de la continuidad del servicio;
d) analista de disponibilidad, responsable de la revisin y anlisis de informes de disponibilidad y datos para

identificar asuntos de disponibilidad reales y potenciales, de modo que se puedan identificar soluciones
apropiadas para mejorar la disponibilidad;

e) personal de la continuidad del servicio, responsables de mantener la capacidad de monitoreo y factores

activadores.
6.4 Presupuesto y contabilidad de los servicios
El proceso de presupuesto y contabilidad debera apoyar el entendimiento del proveedor del servicio y la
capacidad para gestionar el costo total de los servicios. A fin de lograr este objetivo, el proceso debera asegurar
que:
a) el costo de los servicios individuales, el suministro del servicio global y el presupuesto del proveedor del
servicio se entienden;
b) es lograble un pronstico confiable tanto de los costos como del presupuesto;
c) los procesos de gestin del servicio desarrollan y utilizan un presupuesto;
d) las variaciones inesperadas de los costos o presupuestos se identifican y controlan;
e) el presupuesto se respeta de modo que la prestacin del servicio se financia adecuadamente durante el
perodo del presupuesto;
f) los pronsticos, presupuestos y costos se revisan regularmente para asegurar que los procesos y
procedimientos siguen siendo eficaces.
6.4.2 Conceptos
El proceso de presupuesto y contabilidad debera controlar los aspectos financieros de los servicios y
componentes del servicio. El proceso de presupuesto y contabilidad de los servicios debera proporcionar
informacin que apoye la operacin real de los servicios y el financiamiento de los cambios y mejoramientos del
servicio. El proceso de presupuesto y contabilidad de los servicios se debera asegurar de que a los costos de la
prestacin del servicio se les hace monitoreo y que los servicios en s son asequibles y de acuerdo con los
presupuestos.
La responsabilidad de muchas de las decisiones financieras pueden caer fuera del alcance del SGS. Los
requisitos con respecto al nivel de detalle de la informacin financiera a suministrar, en qu forma y con qu
frecuencias pueden ser dictada por partes externas al proveedor del servicio. Otros requisitos reglamentarios o de
la organizacin especficos tambin se deberan tener en cuenta, ya que tendrn un impacto sobre algunas de las
polticas y procedimientos definidos. Todas las prcticas contables utilizadas se deberan alinear a las prcticas
de contabilidad ms amplias de la organizacin del proveedor del servicio.
El proceso de presupuesto y contabilidad de los servicios lo debera realizar el proveedor del servicio,
independientemente de que otros aspectos de la gestin financiera sean realizados en otras partes de la
organizacin. El proceso de presupuesto y contabilidad de los servicios debera recibir la informacin de los
procesos financieros de la organizacin del proveedor del servicio, para as alinearse con dicha informacin.

6.4.3.1 Poltica
El proveedor de servicios debera tener una poltica y procedimientos documentados para la gestin financiera de
los servicios. La poltica debera definir los objetivos que debe cumplir el presupuesto y contabilidad para el
proceso de los servicios. La poltica tambin debera definir el detalle requerido para asegurar que se cumplan
los objetivos. Para ello, la poltica debera incluir los tipos de costos utilizados en el presupuesto para la
asignacin de costos y una explicacin de cmo se distribuyen los gastos generales.
Los criterios se deberan definir para permitir un anlisis del presupuesto y contabilidad para cada servicio.
Cuando se defina, estos criterios se pueden aplicar a los temes del presupuesto y a las partidas contables para
garantizar que algunos monitoreos peridicos y la visibilidad estn respecto de los costos de los servicios. Esto
se puede utilizar para hacer monitoreo de los costos de un servicio y permitir la comparacin con los costes de
adquirir el mismo servicio en otro lugar del mercado.
Los recursos previstos para el presupuesto y contabilidad de los procesos de los servicios se deberan basar para
el detalle financiero en las necesidades del cliente, del proveedor del servicio, de los proveedores y otras partes
interesadas, segn se defina en la poltica.
6.4.3.2 Tipos de costos
El proveedor del servicio debera seleccionar categoras para las partidas de costos en el presupuesto que sean
tiles para la gestin del servicio. Por ejemplo, los proveedores de servicios deberan definir modelos de costos
en lnea con los servicios y sus componentes, tal como se defina en el catlogo de servicios (ver 6.1). Se debera
asignar un tipo de costo a cada costo que forme parte de un servicio. Los modelos de costos son tiles segn
permitan al proveedor del servicio predecir con ms exactitud el costo/beneficio de los distintos niveles de
calidad del servicio, o de distintas opciones de servicio. Los modelos de costos deberan ser capaces de
demostrar el costo total de la prestacin de cada servicio.
El proveedor del servicio debera considerar tipos de costos tales como:
a) activos utilizados para proveer los servicios;
b) compartir recursos tales como una mesa de servicio, tambin conocida como soporte de nivel 1;
c) gastos generales, como espacio de oficina;
d) servicios prestados por proveedores;
e) el costo de emplear al personal de gestin del servicio.
Cuando se identifican tipos de costos adecuados debera haber un equilibrio entre los beneficios de la
informacin de la contabilidad detallada, derivada de los tipos de costos y los desafos de la recoleccin y
gestin de grandes volmenes de informacin necesaria. Los tipos de costos se deberan basar en categoras que
se puedan medir fcilmente y con seguridad. Los ejemplos incluyen costos de hardware, costos de
mantenimiento de software, y costos de personal.
6.4.3.3 Reparto de los gastos generales y asignacin de los costos directos
El reparto de los gastos generales se puede basar en una diversidad de mecanismo, tales como un costo de tarifa
plana, un porcentaje fijo, o en base al tamao de un elemento variable acordado de los servicios prestados.

El proveedor del servicio debera utilizar mtodos de reparto de los gastos generales y asignacin de los costos
directos que sean apropiados para su organizacin, equilibrando el costo de la gestin de reparto frente al
beneficio de ser capaz de repartir los costos en detalle. Otros factores que se pueden considerar incluyen:
a) la naturaleza, rango y consumo o uso de los servicios;
b) la granularidad de la organizacin del cliente, por ejemplo, una unidad de negocio como una unidad,
subdividido en departamentos, o por lugares;
c) SLA y el reparto de los costos por los servicios y niveles de servicio;
d) servicios prestados por los proveedores.
6.4.3.4 Presupuesto
El pronstico de gastos e ingresos para el presupuesto debera tener en cuenta los cambios previstos en los
servicios durante el periodo de presupuesto. Las variaciones estacionales y cambios previstos a corto plazo en los
costos y gastos del servicio, cuando sea aplicable, se deberan entender e incluir dentro de los presupuestos del
pronstico. El presupuesto y monitoreo de los costos se debera apoyar la planificacin para operar y mejorar los
servicios de modo que los niveles de servicio se puedan mantener a lo largo del ao. Debera haber suficientes
gastos previstos para cubrir los recursos necesarios para apoyar los servicios a los niveles de servicio acordados
y por la duracin acordada. Tambin se debera establecer un procedimiento para la identificacin y gestin de
las variaciones de los gastos presupuestados frente a los reales.
6.4.3.5 Contabilidad
Las actividades de contabilidad se deberan utilizar para hacer monitoreo a los costos para un nivel acordado de
detalle durante un periodo de tiempo acordado. Las decisiones sobre la prestacin del servicio se deberan basar
en las comparaciones de rentabilidad. Los modelos de costos deberan ser capaces de demostrar los costos totales
de prestacin del servicio.
Los informes contables deberan demostrar el sobre y bajo gasto. Idealmente los informes de contabilidad
tambin deberan proporcionar suficiente informacin para calcular los costos de los niveles de servicio bajos o
los costos derivados de una prdida de servicio. Para calcular los costos de los niveles de servicio bajos o de la
prdida del servicio, el proveedor del servicio debera tener un claro entendimiento de los costos de los recursos
necesarios para prestar el servicio. Esto debera incluir personal, componentes, instalaciones, y los aspectos del
servicio prestado por otras partes. El proveedor de servicios tambin debera tener un claro entendimiento del
impacto en el negocio de la prdida de servicio, dependiendo de la duracin, la hora del da/semana/mes o ao y
el servicio en cuestin. Esta informacin puede ser proporcionada por un anlisis de impacto en el negocio.
Los informes de contabilidad tambin pueden utilizar la informacin de la CMDB con respecto al estado del
ciclo de vida de los IC para calcular el costo total de propiedad y depreciacin de los IC que soportan un servicio
en particular. Esta informacin a su vez puede ser utilizada para comprender y planificar los costos en el
prximo ciclo de presupuesto.
6.4.3.6 Cargo
El cargo no est incluido en ISO/IEC 20000-1 pero se recomienda que cuando se utiliza el cargo, se defina el
mecanismo de cargo y sea entendido por todas las partes.

Los documentos y registros a generar y utilizar por el cliente, proveedor del servicio y partes interesadas
incluyen:
a) polticas, procesos y procedimientos para los presupuestos y la contabilidad;
b) presupuestos histricos, borradores de presupuesto para el prximo ao, presupuesto real para el ao en
curso;
c) pronsticos de gestin del servicio de las cargas de trabajo, capacidad (incluido el personal), costos
unitarios de temes de ingreso, gastos de capital planificados;
d) calendario para la generacin de presupuestos;
e) informes financieros que muestren los costos e ingresos para cada perodo de tiempo en el ao del
presupuesto, con las variaciones;
f) informes sobre las causas de las variaciones y cmo se gestionarn;
g) aporte financiero para los proyectos de mejoramiento continuo del servicio;
h) modelos de costos que muestren cmo los elementos de costo se utiliza para proporcionar servicios y crear
valor;
i) informes necesarios para propsitos legales o reglamentarios.
del presupuesto y contabilidad se debera incluir:
a) un gerente de presupuesto y contabilidad, responsable por la gestin de los recursos financieros;
b) gerentes con obligacin de rendir cuentas por un presupuesto especfico en la organizacin del proveedor
del servicio.
6.5 Gestin de la capacidad
El proceso de gestin de la capacidad debera asegurar que se proporciona la capacidad suficiente para cumplir
con la capacidad real acordada y los requisitos de desempeo. El proveedor del servicio debera crear e
implementar un plan de capacidad para cumplir con la capacidad futura del servicio acordada y los requisitos de
desempeo.
6.5.2 Conceptos
Los recursos se deberan equilibrar para cumplir tanto con la capacidad actual como con la acordada, como as
tambin con los requisitos de desempeo, y estar preparados para cumplir con requisitos futuros.

El proceso de gestin de la capacidad debera incluir actividades tanto reactivas como proactivas. Las
actividades reactivas se deberan enfocar en el monitoreo continuo, ajuste, anlisis y mejoramiento de la
capacidad operativa. El aspecto proactivo del proceso se debera enfocar en la planificacin para cumplir futuras
demandas del negocio acordadas.
El proceso de gestin de la capacidad debera desarrollar planes para asegurar que los requisitos de la capacidad
se pueden acordar, pronosticar y cumplir. Estos planes se deberan transformar las predicciones del negocio y las
estimaciones de carga de trabajo en requisitos de capacidad especficos. Esto se debera facilitar mediante la
incorporacin de las tres reas de enfoque siguientes en el proceso de gestin de la capacidad:
a) gestin de la capacidad del negocio, que se enfoca en cuantificar los planes y necesidades del negocio del
cliente y del proveedor del servicio en los requisitos de futuros servicios;
b) gestin de la capacidad del servicio, que se enfoca en planificar y gestionar los servicios y los recursos de
apoyo para asegurar que cumplan todas sus metas de servicio acordadas;
c) gestin de la capacidad de los componentes, que se enfoca en planificar y gestionar los recursos operativos
y los componentes para asegurar que efectivamente apoyen los servicios y logren las metas acordadas para
los componentes.
6.5.3.1 Actividades de gestin de la capacidad
Las actividades de gestin de la capacidad abarcan las tareas operativas del da a da, tales como el monitoreo de
uso de la capacidad y el anlisis de los datos de capacidad, la gestin del desempeo frente a las metas del
servicio y la planificacin de los requisitos de capacidad futuros.
Las actividades del proceso de gestin de la capacidad incluyen aquellas que se listan a continuacin:
a) Evaluar, documentar y acordar los requisitos de capacidad, definir la carga de trabajo, lneas de base del
desempeo, y establecer umbrales de desempeo y carga de trabajo y los activadores.
b) Evaluar, documentar y acordar los requisitos de capacidad para los servicios nuevos o modificados.
c) El proceso de gestin de la capacidad debera participar en el diseo de los servicios nuevos o modificados
y hacer recomendaciones para la adquisicin de componentes y recursos, donde el desempeo y/o
capacidad son factores. En el inters de equilibrar el costo y la capacidad, el proceso de gestin de la
capacidad debera obtener los costos de las soluciones alternativas propuestas y recomendar la solucin
costo-eficacia ms apropiada.
d) Las actividades para los requisitos de capacidad nuevos se deberan basar en las entradas de la
planificacin, los equipos de soporte y grupos del negocio. Esto debera incluir planificar la implementacin
de la infraestructura de los proyectos nuevos y predecir el reemplazo de los componentes de la
infraestructura por envejecimiento.
e) Establecer, hacer monitoreo y utilizar umbrales de capacidad, advertencias y alarmas para gestionar y
mejorar automticamente la utilizacin de los componentes y el desempeo de los servicios.

f) Mantener datos e informacin utilizados por el proceso de gestin de la capacidad en un repositorio, a

menudo referido como la base de datos de la capacidad. Este repositorio debera ser un elemento clave del
proceso de gestin de la capacidad. Los datos e informacin contenidos en la base de datos de la capacidad
se analiza por todas las actividades de gestin de la capacidad y debera incluir el negocio, servicio, recurso
o utilizacin y datos financieros, de todas las reas de la tecnologa segn se muestra a continuacin:
1) Datos del negocio: informacin fiable sobre las necesidades actuales y futuras del negocio.
2) Datos del servicio que incluyan, pero sin limitarse a: tiempos de respuesta de transaccin, tasas de
transaccin y volmenes de carga de trabajo.
3) Datos de utilizacin de componentes: Se deberan documentar las limitaciones de los componentes en

el nivel al para el cual se deberan utilizar. Ms all de este nivel de utilizacin, el recurso se sobre
utilizar y el desempeo de los servicios que utilizan el recurso se ver afectado.
4) Otros datos a utilizar por el proceso de gestin de la capacidad incluyen los cuellos de botella y las
debilidades identificadas; redundancia y capacidad de reserva; recursos, componentes y umbrales de
servicios y tolerancias; rendimiento actual, pasado y pronosticado y desempeo, comparaciones de los
logros reales frente a los logros pronosticados.
g) Generar informes de y desempeo, que proporcionan informacin valiosa para muchos procesos de gestin
del servicio. Los informes de capacidad se deberan consolidar y almacenar dentro de la base de datos de la
capacidad, de modo que las partes interesadas se puedan referir a ellos. Estos informes deberan incluir lo
que se lista a continuacin:
1) Informes basados en los componentes e informacin para ilustrar cmo los componentes estn
funcionando y cunto de su capacidad se est utilizando.
2) Informes basados en los servicios e informacin para ilustrar cmo el servicio y sus componentes
constituyentes estn funcionando con respecto a sus metas de servicio globales y limitaciones. Estos
informes proporcionan la base de los informes de servicio al cliente y los informes de GNS sobre la
capacidad y el desempeo.
3) Tambin se deberan generar informes de excepcin que muestran al personal de gestin y tcnico
cuando la capacidad y el desempeo de un componente o servicio en particular ha llegado a ser
inaceptable. En particular, los informes de excepcin deberan ser de inters para el proceso de GNS
para determinar si las metas de los SLA se han logrado o violado. El proceso de gestin del incidente y
solicitud es de servicio y el proceso de gestin del problema pueden as utilizar los informes de
excepcin en la resolucin de incidentes y problemas.
h) El pronstico de la capacidad y desempeo de un servicio y componente futuro se debera hacer en una

diversidad de formas, dependiendo de las tcnicas y la tecnologa utilizada. Los ejemplos incluyen los que
se listan a continuacin:
1) Modelado de lnea de base es la primera etapa en el modelado. Se utiliza para crear un modelo de
referencia que refleja exactamente el desempeo que se est logrando. Cuando este modelo de
referencia se ha creado, se pueden desarrollar modelados predictivos.
2) El anlisis de tendencias se completa al utilizar la informacin del desempeo del servicio y de la

utilizacin de recursos que se ha recolectado.

3) El modelado analtico se completa al utilizar tcnicas matemticas para analizar el desempeo de sistemas
computacionales.
4) El modelado de simulacin implica el modelado de eventos discretos, por ejemplo, tasas de retorno de la
transaccin frente a una configuracin del sistema dada.
6.5.3.2 Plan de capacidad
El plan de capacidad debera documentar el desempeo real, las necesidades de capacidad del negocio esperadas
y los requisitos del servicio. Se debera generar al menos anualmente o con mayor frecuencia si las tasas de
cambio en los servicios y los volmenes de servicio lo demandan. Se deberan documentar las soluciones
recomendadas para lograr las metas del servicio acordadas y las opciones de costos para cumplir con los
requisitos del negocio.
El plan de capacidad debera incluir:
a) uso del servicio actual y pronosticado, idealmente incluyendo recomendaciones con respecto a las
oportunidades para influir en la demanda de capacidad;
b) uso de recursos y desempeo actual y pronosticado, incluyendo un entendimiento sobre los recursos de
apoyo a los servicios;
c) el impacto en la capacidad y el desempeo de los requisitos acordados para la disponibilidad, continuidad

del servicio y metas del servicio, por ejemplo, estimaciones de la carga de trabajo y requisitos de capacidad
en caso de un desastre;
d) escalas de tiempo, umbrales y costos de actualizaciones de la capacidad del servicio, por ejemplo, las fechas
y costos requeridos para la entrega de un aumento de la capacidad del servicio como resultado de una fusin
de negocios;
e) resmenes de los planes del negocio pertinentes, escenarios y patrones de actividad del negocio;
f) resumen de los cambios en la actividad del negocio, incluidos los perfiles de usuario si estn disponibles;
g) detalles de los mtodos, supuestos e informacin utilizada para el clculo de los detalles en el plan de
capacidad;
h) el impacto potencial de las nuevas tecnologas en la capacidad y el rendimiento;
i) datos y procedimientos para permitir el anlisis predictivo, por ejemplo, tcnicas de modelado;
j) impacto potencial sobre los requisitos estatutarios, reglamentarios, contractuales y organizacionales, por
ejemplo, un plan para mantener suficiente espacio de almacenamiento y capacidad de respaldo para los
registros electrnicos mdicos para cumplir con la normativa.
Los documentos y registros que se generan y retienen por el proceso de gestin de la capacidad deberan incluir:
a) plan de capacidad;
b) procedimientos de gestin de la capacidad;
c) lneas de base y perfiles;

d) base de datos de la gestin de la capacidad;
e) especificaciones del umbral del servicio y los recursos y los umbrales para eventos y alarmas;
f) informes de desempeo del servicio;
g) calendarios y niveles de utilizacin;
h) revisiones de eficacia;
i) anlisis de carga de trabajo;
j) informes de excepcin de la gestin de la capacidad;
k) revisiones de registros de incidentes relacionados a la capacidad y el desempeo.
Entre los documentos y registros revisados por el proceso de gestin de la capacidad se deberan incluir los
requisitos y demandas de capacidad del servicio actual y futura del negocios de los clientes, incluyendo los SLA
y los niveles de servicio requeridos y los informes de auditora. Los cambios en el plan de capacidad se deberan
gestionar a travs del proceso de gestin del cambio.
de la capacidad se debera incluir las siguientes:
a) Analista de capacidad, encargado de analizar y revisar la capacidad y los datos de desempeo para
identificar los asuntos de capacidad actuales y potenciales de modo que se puedan identificar soluciones
para eliminar aquellos asuntos y mantener el desempeo del servicio. El analista de capacidad ayuda en la
identificacin de opciones y el anlisis y recomendacin de la o las soluciones preferidas para cumplir con
la demanda continua de capacidad.
b) Clientes y representantes del negocio, responsables de la documentacin y acuerdo de todos los requisitos
de capacidad.
6.6 Gestin de la seguridad de la informacin
El proceso de gestin de la seguridad de la informacin (GSI) debera asegurar que los controles de seguridad
existen para proteger los activos de informacin y que los requisitos de seguridad de la informacin se
incorporan en el diseo y transicin de los servicios nuevos o modificados.
6.6.2 Conceptos
La seguridad de la informacin debera ser el resultado de un sistema de polticas y procedimientos diseados

para identificar, controlar y proteger la informacin de la organizacin y los recursos utilizados en relacin con
su almacenamiento, transmisin y procesamiento.
La gerencia debera asegurar que los objetivos de gestin de la seguridad de la informacin claramente definidos
estn en su lugar y que se alinean con las necesidades de negocio.

El proveedor del servicio y el cliente deberan categorizar los activos de informacin de acuerdo al valor,
confidencialidad o impacto en el negocio. Para cada categora el proveedor del servicio y el cliente debera
definir y acordar un nivel de riesgo aceptable.
6.6.3.1 Poltica de seguridad de la informacin
Los requisitos del servicio, los requisitos estatutarios y reglamentarios y las obligaciones contractuales deberan
proporcionar la base de una poltica de seguridad de la informacin. La poltica debera dar una orientacin sobre
el uso de controles de seguridad de la informacin fsicos, administrativos y tcnicos, diseados para preservar la
seguridad de los activos de informacin, por ejemplo, confidencialidad, integridad y accesibilidad. La poltica
debera ser aprobada por los gerentees responsables de rendir cuentas por el SGS y los servicios.
El alcance de la poltica de seguridad de la informacin debera incluir pero no limitarse a los controles fsicos,
administrativos y tcnicos necesarios para asegurar la confidencialidad, integridad y accesibilidad de los activos
de informacin dentro del alcance del SGS. El alcance de la poltica de seguridad de la informacin puede ser
mayor que el alcance de SGS para atender las necesidades del negocio.
La gerencia debera asegurar que el personal, los clientes y proveedores y grupos internos tienen tanto la
comprensin adecuada de los contenidos de la poltica como as tambin una apreciacin de la importancia de
adherirse a ella.
La gerencia tambin debera asegurar que la poltica de seguridad de la informacin se utiliza como parte de las
evaluaciones del riesgo y durante las auditoras de seguridad de la informacin.
La poltica debera proporcionar una orientacin sobre los criterios para aceptar los riesgos y el enfoque para
gestionar los riesgos de seguridad de la informacin identificados, por ejemplo, gestin de contraseas.
La poltica debera asegurar que las auditoras internas de seguridad de la informacin se llevan a cabo a
intervalos regulares, por ejemplo, despus de una violacin de la seguridad de la informacin o despus del
despliegue de un servicio nuevo o modificado.
La poltica debera asegurar que los resultados de las auditoras de seguridad de la informacin se revisan a
intervalos regulares y se utilizan para identificar oportunidades de mejoramiento de la seguridad de la
informacin. Por ejemplo, la correccin de vulnerabilidades identificadas durante una auditora de seguridad de
la informacin.
NOTA - El personal con roles especializados por la seguridad de la informacin puede encontrar til
familiarizarse con ISO/IEC 27002 Information technology - Security techniques - Code of practice for
information security management. Esta Norma Internacional incluye orientaciones sobre el contenido de una
poltica de seguridad.
6.6.3.2 Controles de seguridad de la informacin
Los controles de seguridad de la informacin deberan garantizar que los objetivos de gestin de la seguridad de
la informacin se logran y que se gestiona los riesgos de seguridad de la informacin. Los controles de seguridad
de la informacin puede ser fsicos, administrativos o tcnicos.
El proveedor del servicio debera asegurar que los controles estn documentados, y que describen sus riesgos
asociados y las estrategias de mitigacin del riesgo. El proveedor del servicio tambin debera definir las
autoridades y responsabilidades para la revisin de los controles y la frecuencia con que se deberan revisar.

El proveedor del servicio tambin debera definir los controles de seguridad de la informacin para gestionar
organizaciones externas y personas que necesitan acceder, utilizar o gestionar la informacin o los servicios de la
organizacin.
6.6.3.3 Evaluacin del riesgo
El proceso de GSI debera realizar evaluaciones peridicas del riesgo para identificar los riesgos de la seguridad
de la informacin para el entorno real, y as documentar y poner en prctica controles especficos para prevenir o
minimizar el impacto de los riesgos identificados. Adicionalmente, el proceso de GSI debera realizar o asegurar
que se realicen evaluaciones del riesgo apropiadas como parte del diseo y transicin de los servicios nuevos o
modificados.
La poltica de seguridad de la informacin debera asegurar las evaluaciones del riesgo de seguridad de la
informacin:
a) se realizan a intervalos acordados, incluyendo los servicios nuevos o modificados;
b) se registran y son visibles slo para personal aprobado;
c) se mantienen durante los cambios en las necesidades de negocio, procesos y configuraciones;
d) ayudan a comprender lo que podra impactar un servicio;
e) definen requisitos para las auditoras de seguridad de la informacin;
f) informan decisiones con respecto a los tipos de controles a operar.
Se deberan evaluar los riesgos para los activos de informacin de acuerdo a la naturaleza del riesgo y el impacto
potencial en el negocio.
NOTA - El personal con responsabilidades especializadas por la seguridad de la informacin puede encontrar
til familiarizarse con ISO/IEC 27005 Information technology - Security techniques - Information security risk
management.
6.6.3.4 Gestin de los riesgos de seguridad de la informacin
Los controles de seguridad de la informacin deberan asegurar que el proveedor del servicio es capaz de lograr
los objetivos de gestin del servicio y los requisitos de la poltica de seguridad. Los controles tambin deberan
permitir que el proveedor del servicio gestione todos los riesgos de seguridad de la informacin identificados.
Los siguientes son ejemplos de controles de seguridad de la informacin:
a) la poltica de seguridad de la informacin se debera establecer, implementar y comunicar al personal, a los

proveedores y al cliente;
b) se deberan definir y asignar las autoridades y responsabilidades para el proceso de gestin de seguridad de
la informacin;
c) la eficacia de la poltica de seguridad de la informacin se debera monitorear, medir y evaluar;
d) el personal con roles de seguridad de la informacin importantes debera recibir formacin en seguridad de
la informacin;
e) debera estar disponible la ayuda de expertos en la evaluacin del riesgo y la implementacin de controles;

f) los cambios no deberan comprometer la operacin eficaz de los controles;
g) los incidentes de seguridad de la informacin se deberan informar de acuerdo con el proceso de gestin del
incidente y solicitudes de servicio, adems de asignarles una prioridad apropiada;
h) un incidente de seguridad de la informacin se debera escalar al personal con la habilitacin

correspondiente para resolverlo, dependiendo de la prioridad y el nivel de autorizacin necesario para
acceder al registro de incidentes de seguridad;
i) los detalles de los incidentes de seguridad de la informacin slo se deberan mantener visibles para el
personal con la habilitacin correspondiente;
j) se deberan completar las evaluaciones peridicas del riesgo para identificar los cambios en la disposicin a
tolerar el riesgo de la organizacin;
k) se deberan realizar auditoras peridicas para asegurar el cumplimiento de la poltica de seguridad de la

informacin y de los controles establecidos;
l) se deberan definir y aplicar eficazmente las lneas de base de la seguridad de la informacin;
m) se deberan analizar los hallazgos de las auditoras de seguridad de la informacin, culminando en planes de
accin priorizados;
n) se deberan crear y mantener al da los planes de formacin de seguridad de la informacin y los registros
de formacin.
El proveedor del servicio debera trabajar con el proceso de gestin de proveedores para asegurar que los
controles de seguridad de la informacin se identifican, documentan y gestionan con cualquier organizacin
externa que tenga acceso o utilice la informacin del proveedor del servicio.
6.6.3.5 Cambios e incidentes de seguridad de la informacin
Los cambios e incidentes de seguridad de la informacin se deberan procesar de acuerdo con el proceso de
gestin del cambio y el proceso de gestin del incidente y solicitudes de servicio.
Las solicitudes de cambio se deberan evaluar para identificar los riesgos de la seguridad de la informacin
nuevos o modificados como resultado del cambio propuesto. La solicitud de cambio tambin se debera evaluar
frente a los impactos potenciales sobre los servicios existentes, procesos, polticas o los controles de seguridad de
la informacin existentes.
El proveedor del servicio debera utilizar los resultados de las revisiones de los registros de incidentes de
seguridad de la informacin, como as tambin las evaluaciones y auditoras de seguridad de la informacin para
identificar deficiencias potenciales y oportunidades de mejoramiento.
Los documentos y registros que se deberan generar y retener por el proceso de GSI deberan incluir:
a) una estrategia de seguridad de la informacin;
b) poltica de seguridad de la informacin;
c) plan de seguridad de la informacin;
d) procedimientos de gestin de la seguridad de la informacin;

e) informes de seguridad de la informacin;
f) informes eficacia y eficiencia del proceso de GSI;
g) registros de incidentes de seguridad de la informacin;
h) evaluaciones del riesgo de seguridad de la informacin;
i) inventarios de activos de informacin.
Los documentos y registros se deberan analizar peridicamente para proporcionar a la gerencia informacin
sobre la eficacia de la poltica de seguridad de la informacin. Otras caractersticas de inters incluyen las
tendencias en los incidentes de seguridad de la informacin, la entrada a un plan de mejoramiento del servicio y
el control sobre el acceso a la informacin, activos, y sistemas.
segn se describe en 4.4.2.1, entre las autoridades y responsabilidades requeridas dentro del proceso de GSI se
debera incluir:
a) clientes, personal del proveedor del servicio y partes interesadas que requieren acceso a los IC y datos de
GSI;
b) personal que mantiene los controles de seguridad de la informacin.
7 Procesos de relacin
7.1 Gestin de relaciones con el negocio
El proceso de la GRN debera asegurar que se establecen los mecanismo para gestionar la relacin entre el
proveedor del servicio y el o los clientes. Un resultado de un proceso debera ser el mejoramiento de la
satisfaccin del cliente y la entrega de valor a travs de resultados del negocio alcanzables. Las rendiciones de
cuenta y las responsabilidades del cliente y del proveedor del servicio por identificar y priorizar los requisitos del
servicio se deberan definir claramente. Se deberan definir y seguir los procedimientos para gestionar la relacin
continua entre el servicio del proveedor y el cliente.
Los mecanismos para gestionar la relacin entre el proveedor del servicio y el cliente deberan incluir:
a) una persona designada responsable de gestionar la relacin con el cliente y la satisfaccin del mismo;
b) comunicaciones regulares con el cliente para permitir al proveedor del servicio comprender el entorno del
negocio, las necesidades y prioridades del negocio, y los requisitos para los servicios nuevos o modificados;
c) revisiones regulares del desempeo con el cliente de los servicios en el entorno real.
7.1.2 Conceptos
El proceso de GRN debera ser un habilitador clave hacia el desarrollo de la alineacin estratgica entre el
proveedor del servicio y el cliente. A travs de la alineacin de las necesidades del negocio del cliente y los
objetivos del proveedor del servicio se debera lograr aumentar el valor del negocio. El proceso de GRN debera
contribuir a la reduccin de cualquier barrera real o percibida entre el proveedor del servicio y sus clientes.

Debera haber un fuerte vnculo entre el proceso de GRN y el proceso de GNS. El proceso de GNS debera
definir y utilizar medidas para valorizar el desempeo del nivel de servicio. El proceso de GNS debera gestionar
servicios prestados actualmente y niveles de servicio a un nivel operativo.
Por el contrario, el proceso de GRN debera tratar de trabajar estrechamente con el cliente para comprender los
futuros objetivos y gerencia del negocio. Al hacer esto, el proceso de GRN debera asegurar que los cambios en
los servicios se pueden planificar antes de la necesidad del cliente. Una buena comprensin de los objetivos del
negocio del cliente tambin debera permitir que el proveedor del servicio ofrecer soluciones estrechamente
alineadas que satisfagan las necesidades del negocio del cliente.
Cuando se prestan grandes servicios comerciales a muchos clientes puede ser difcil tener una relacin individual
con cada cliente. Por ejemplo, los servicios de internet utilizados por hogares particulares. En este caso se
debera considerar cmo el proveedor del servicio interacta con mltiples clientes. Se pueden utilizar
mediciones de la satisfaccin del cliente para asegurar que los servicios planificados y los servicios reales estn
alineados con los requisitos del cliente.
El proveedor del servicio debera identificar y documentar quines son sus clientes, otras partes interesadas,
proveedores y proveedores subcontratados dependientes, a fin de comprender completamente las dependencias
entre los servicios. Por ejemplo, un servicio basado en internet que dependiente de un servicio que provee un
portal web seguro y la capacidad de cifrado. Las partes interesadas pueden incluir grupos de usuarios y unidades
del negocio.
El proveedor del servicio debera clasificar a sus clientes de acuerdo al tipo de servicios prestados. Los clientes
con caractersticas similares se pueden agrupar de formas similares para mejorar la eficacia y la eficiencia. Los
procesos definidos por el proveedor del servicio pueden ser distintos para cada tipo de cliente a un nivel
detallado.
El proveedor del servicio debera identificar a una o ms personas con nombre para que sea un nico punto claro
de contacto, responsable de gestionar la relacin y satisfaccin del cliente para cada cliente. Esta persona puede
ser escogida para gestionar la relacin con el cliente sobre una base de tiempo completo o, si es apropiado, puede
tener el rol combinado con otro rol.
Debido a la estrecha relacin entre los procesos de la GRN y la GNS, es posible que una misma persona
desempee los roles de gerente de relaciones del negocio y gerente del nivel de servicio. Si la misma persona
tiene ambos roles, las descripciones de roles deberan distinguir la naturaleza distinta de los roles: el proceso de
GRN es estratgico mientras el proceso de GNS es operativo o tctico. Tambin se deberan gestionar los riesgos
de tener una persona desarrollando estos dos roles con tales perspectivas distintas.
Los mecanismos de comunicacin establecidos con el cliente deberan incluir reuniones ad-hoc y reuniones
informales, adems de formalizar y documentar las reuniones. Estas comunicaciones deberan construir una
relacin con el cliente, identificar cambios en las prioridades y objetivos del negocio y luego activar la
comunicacin de retorno al proveedor del servicio para la accin.
Los mecanismos de comunicacin deberan ayudar a la comprensin del entorno del negocio en el cual opera el
servicio incluyendo las necesidades del negocio, los requisitos del cliente y los cambios mayores. El proveedor
del servicio debera utilizar esta informacin para responder a las necesidades identificadas.
Los proveedores de servicios pueden utilizar una herramienta para realizar el monitoreo y gestionar informacin
sobre el cliente.

7.1.3.2 Revisiones de la gestin del servicio al cliente
El proveedor del servicio debera realizar reuniones formales con el cliente para revisar la satisfaccin del
cliente, la gerencia estratgica y principales excepciones al desempeo de los servicios. Estas reuniones deberan
incluir revisiones de los SLA y del desempeo, cambios dentro de la organizacin del proveedor del servicio y
los cambios dentro de la organizacin del cliente.
Las reuniones deberan contar con la participacin de todas las partes. Las reuniones se deberan calendarizar
con anticipacin y realizar regularmente, al menos anualmente. La frecuencia real debera ser afectada por la tasa
de cambio de los requisitos del servicio, proyectos importantes tales como servicios nuevos y la calidad del
servicio prestado. Las reuniones deberan ser ms frecuentes que el mnimo anual cuando el proveedor del
servicio y el cliente gestionan una tasa de cambio alta o cuando existen preocupaciones sobre la calidad de los
servicios. Por ejemplo, una tasa de cambio rpida de los requisitos del servicio, proyectos importantes tales como
servicios nuevos o modificados. Cuando hay contenido insuficiente para la reunin, realizar reuniones de
revisin de clientes ms de cuatro veces al ao puede ser contraproducente para los representantes de la gerencia
involucrados.
Los resultados de las revisiones del cliente pueden dar como resultado la identificacin de servicios nuevos o
modificados necesarios para los servicios o niveles de servicio existentes. El proveedor del servicio debera
asegurar que los cambios a los SLA y los contratos se gestionan a travs del proceso de gestin del cambio y
siguen el proceso de GNS establecido.
Se debera establecer la trazabilidad de los requisitos del cliente para la modificacin del servicio.
7.1.3.3 Satisfaccin del cliente
El proveedor del servicio debera establecer un mecanismo formal para registrar la satisfaccin del cliente. La
frecuencia y escala de cualquier medicin se debera acordar por adelantado con el cliente, y sta debera incluir
la muestra de usuarios a someter. Tras la resolucin de un incidente y/o problema, estas actividades a menudo
pueden ser llevadas por una mesa de servicio, tambin conocida como soporte de nivel 1. Sin embargo, para
mediciones verdaderas de la satisfaccin del cliente, se debera realizar una medida ms amplia que incluya, por
ejemplo, el nmero y tipo de solicitudes de servicio, costo real, costo percibido y valor del negocio de los
servicios prestados. Los resultados se deberan identificar, analizar y revisar para identificar oportunidades de
mejoramiento.
Los resultados de las encuestas de satisfaccin se deberan medir en el tiempo, de modo que se le pueda hacer
monitoreo a la satisfaccin e identificar cualquier asunto o mejoramientos necesarios.
El procedimiento documentado de reclamos del servicio debera incluir el registro, investigacin, acciones,
informe y cierre de los reclamos del servicio recibidos. Debera incluir un procedimiento de escalada a utilizar si
el cliente no est de acuerdo en aceptar las acciones propuestas o la resolucin. El reclamo debera permanecer
abierto hasta que el cliente manifieste formalmente que est de acuerdo con el cierre de ste.
El proveedor del servicio debera comprender, definir y acordar con el cliente qu constituye un reclamo formal
del servicio. Un reclamo formal del servicio normalmente es muy serio y se presenta en forma escrita en vez de
verbal. El reclamo formal del servicio lo debera enviar un gerente del cliente a un gerente del proveedor del
servicio. Un incidente o problema puede ser la causa de reclamos pero ellos en s no son reclamos.
El resultado de la revisin del reclamo se debera resumir e informar al cliente de modo que pueda ver que sus
opiniones se han considerado seriamente y se ha actuado en consecuencia.

La documentacin para el proceso de GRN debera incluir:
a) la descripcin de los clientes y/o partes interesadas, que incluya informacin de contacto bsica, roles clave,
servicios solicitados;
b) la especificacin del rol de la persona designada para que interacte con el cliente;
c) agenda y duracin de las reuniones formales entre el cliente y el proveedor del servicio;
d) notas de las reuniones informales entre el cliente y el proveedor del servicio;
e) resumen de las mtricas del servicio que muestren el desempeo global del proveedor del servicio;
f) procedimiento de reclamos del servicio;
g) registros de reclamos y acciones tomadas;
h) mediciones y/o encuestas de satisfaccin del cliente;
i) revisin de los registros de satisfaccin, anlisis y accin;
j) resumen de resultados de la satisfaccin del cliente por retroalimentacin del cliente.
segn se describe en 4.4.2.1, entre las autoridades y responsabilidades requeridas dentro del proceso de GRN se
debera incluir:
a) un rol de analista del negocio, responsable de realizar las actividades globales de la satisfaccin del cliente,
incluyendo la recoleccin y anlisis de los reclamos, datos de satisfaccin del cliente;
b) un rol de gerente de relaciones del negocio, responsable de:
1) mejorar la satisfaccin del cliente para cada cliente;
2) actuar en nombre del cliente dentro de la organizacin del proveedor del servicio;
3) establecer mecanismos de comunicacin eficaces y efectivos entre el proveedor del servicio y el o los
clientes;
4) conducir revisiones del servicio con el cliente y asegurarse que se implementas los mejoramientos o
acciones:
5) asegurar que los cambios a los requisitos del cliente se reflejan en los SLA y otros documentos, por
medio del proceso de GNS;
6) estar en contacto con el proceso de GNS;
7) gestionar los reclamos formales del servicio para asegurar que se resuelven a satisfaccin del cliente;
8) asegurar que la medicin de la satisfaccin del cliente se lleva a cabo de forma rutinaria y que los
resultados se analizan, revisan y acta en consecuencia;

9) comunicar los resultados de la satisfaccin del cliente y las acciones resultantes al cliente en el
momento oportuno;
10) asegurar las escaladas del cliente se tratan de manera oportuna y eficaz;
11) comprender y planificar las futuros requisitos del negocio.
El nombre de este rol puede variar, aunque es comn gerente de relaciones del negocio. Otros posibles ttulos
son gerente de relaciones con clientes o gerente de cuentas. El proveedor del servicio debera ser consciente que
este rol se puede fusionar con otro, o ser desempeado por un equipo completo, dependiendo de las
circunstancias.
A fin de desempear este rol eficazmente el proveedor del servicio debera reconocer la necesidad de experticia
en el propio negocio del proveedor del servicio, la tecnologa y los requisitos y prioridades del negocio del
proveedor. Esta experticia tambin se debera utilizar para comunicar los requisitos del cliente a los especialistas
en tecnologa del proveedor del servicio. La complejidad de este rol significa que la atencin al detalle y la
habilidad servir de enlace con mltiples partes se debera reconocer como un aspecto importante del rol. El
proveedor del servicio tambin debera reconocer que estas responsabilidades estn ms all de las capacidades
de un persona a nivel de principiante.
7.2 Gestin de proveedores
El propsito de la gestin de proveedores debera ser gestionar proveedores para asegurar el suministro
ininterrumpido de servicios de calidad. Los proveedores de servicios pueden utilizar proveedores para operar
algunas partes de los procesos o servicios, o para proveer componentes tales como hardware y software. El
proceso de gestin de proveedores debera ser utilizado por todos los proveedores. Esto incluye a los
proveedores que operan procesos o partes de procesos para el proveedor del servicio. El proceso de gestin de
proveedores puede ser un complemento til para el proceso de GNS para la gestin de grupos internos y clientes
que actan como proveedores.
7.2.2 Conceptos
Los procedimientos de la gestin de proveedores debera asegurar que:
a) los proveedores comprenden sus obligaciones para con proveedor del servicio;
b) los requisitos acordados se cumplen dentro del alcance y niveles de servicio acordados;
c) se gestionan los cambios en los requisitos y obligaciones;
d) se registran las transacciones del negocio entre todas las partes;
e) se puede observar la informacin sobre el desempeo de los proveedores y actuar en consecuencia;
f) los SLA del proveedor del servicio con el cliente estn alineados con los contratos del proveedor.

7.2.3.1 Gestin de contratos
El proveedor del servicio debera designar una persona de contacto responsable por la relacin con cada
proveedor. Tambin se debera designar contactos entre proveedores cuando los servicios o componentes de
stos tengan dependencias.
El contrato debera incluir los requisitos y niveles de servicio requeridos del proveedor. Las metas del servicio
acordadas en el contrato del proveedor se deberan articular para asegurar que los SLA del proveedor del servicio
con el cliente se pueden cumplir. Si los niveles de servicio del proveedor no estn alineados con los SLA, esto se
debera gestionar como un riesgo con planes desarrollados para resolver el riesgo oportunamente.
Todos los contratos con proveedores deberan considerar un revisin calendarizada. Al menos se debera
calendarizar una revisin anual. La revisin debera evaluar si los objetivos del negocio para contratar un
servicio o un componente de un servicio siguen siendo vlidos y el proveedor logra el desempeo acordado
frente a las metas del servicio en el contrato.
Debera haber un proceso claramente definido para gestionar cada contrato. El proceso para modificaciones de
contratos tambin se debera definir claramente. Los cambios a este procedimiento se deberan notificar
formalmente a todos los proveedores afectados.
Si un contrato incluye sanciones o bonificaciones, sus bases se deberan establecer claramente y en consecuencia
el cumplimiento de los requisitos y metas del servicio se debera medir e informar.
Cuando un proveedor suministra una parte de un servicio, el proveedor del servicio debera asegurar que el
contrato con el proveedor incluye todo lo necesario para permitir el logro de los requisitos del cliente pertinentes.
Esto se debera asegurar y documentar antes de hacer un compromiso con el cliente. El proveedor tambin
debera aceptar que el prestador del servicio tendr la gobernanza de los procesos de gestin del servicio
operados por el proveedor, segn se describe en 4.2.
El proveedor del servicio debera, a intervalos planificados, obtener evidencia de que el proveedor cumple todos
los requisitos del contrato, y que tiene procesos de calidad que aseguran eficazmente que estos requisitos sern
cumplidos consistentemente. Esto se puede lograr por medio de la auditora del proveedor de servicios al
proveedor.
Todos los resultados de las reuniones, revisiones y auditoras referentes al servicio subcontratado se deberan
revisar para identificar oportunidades de mejoramiento. Cuando se necesiten cambios, stos se deberan
controlar utilizando el proceso de gestin del cambio.
7.2.3.2 Detalles del proveedor
El proveedor del servicio debera mantener para cada servicio y proveedor, an si esta informacin no est
incluida en el contrato, lo siguiente:
a) una definicin de los servicios, roles y responsabilidades;
b) alcance y capacidad del servicio;
c) requisitos a cumplir por el proveedor;
d) metas del servicio definidas y acordadas, sanciones o consecuencias por metas del servicio no cumplidas;
e) caractersticas de la carga de trabajo tales como nmero de transacciones, nmero de servidores o tamao
de las bases de datos;

f) criterios de excepciones acordadas para los SLA;
g) proceso de gestin de contratos, los niveles de autorizacin y un plan de salida de contrato;
h) condiciones de pago, si es pertinente;
i) parmetros acordados para presentacin de informes y registros del desempeo logrado.
7.2.3.3 Gestin de proveedores subcontratados
Debera estar claro si el proveedor del servicio trata con proveedores directamente o con proveedores
principales, cada uno tomando la responsabilidad por los proveedores subcontratados.
El proveedor del servicio debera obtener evidencia, de los proveedores principales, que stos formalmente
gestionan proveedores subcontratados. Esta evidencia se debera guiar por los requisitos de ISO/IEC 20000-1. Al
proveedor principal se le debera solicitar que registre el nombre de todos los proveedores subcontratados y sus
responsabilidades y relaciones. Esta informacin debera estar a disposicin del proveedor del servicio si la
necesita. En Figura 3 se muestra un ejemplo, tomado de ISO/IEC TR 20000-3, de proveedores y proveedores
subcontratados que suministran parte de un servicio.
7.2.3.4 Gestin de disputas contractuales
Tanto el proveedor del servicio como el proveedor deberan acordar un proceso para gestionar disputas. Esto se
debera definir o hacer referencia dentro del contrato e implementarlo si es necesario. Debera estar disponible
una ruta de escalada para disputas que no se resuelvan a travs de los medios normales de comunicacin. El
proceso debera asegurar que las disputas se registran, investigan, se acta en consecuencia y se cierran
formalmente.
7.2.3.5 Trmino del contrato
El proceso de gestin del contrato debera incluir disposiciones para el trmino del contrato, ya sea segn lo
esperado o anticipadamente. Tambin debera proporcionarlas para la transferencia del servicio a otra
organizacin al final del contrato. Las clusulas de trmino de contrato deberan aclarar las responsabilidades
para cerrar o transferir el servicio, costos, titularidad de la propiedad intelectual, hardware, licencias de software
y datos.
Figura 3 - Ejemplo de relacin con proveedores principales y proveedores subcontratados

El proveedor del servicio y el proveedor deberan mantener una copia aprobada de todos los contratos con los
proveedores. Los contratos deberan incluir o hacer referencia a la definicin del servicio e identificar los
procesos de gestin del servicio que cubren todos los servicios prestados por el proveedor. Se debera
documentar la interface entre procesos operados por mltiples partes.
El proveedor del servicio tambin debera mantener:
a) los nombres, responsabilidades y relaciones con las organizaciones de todas las partes interesadas,
incluyendo al cliente, al proveedor del servicio, al proveedor principal y a los proveedores subcontratados;
b) evidencia de que el proveedor del servicio gestiona formalmente al proveedor, incluyendo los registros y las
acciones a partir de reuniones peridicas de revisin de contrato, e informes de las auditoras
subcontratadas;
c) evidencia, similar a la anterior, de que los proveedores principales gestionan a los proveedores
subcontratados.
de proveedores se debera incluir lo siguiente:
a) Gerente de relaciones con proveedores, una persona designada responsable de gestionar la relacin del
proveedor del servicio con un proveedor especfico. Esto incluye la gestin del contrato y el desempeo.
Cuando varios funcionarios se dedican a estas actividades, debera haber un procedimiento para asegurar
que la informacin sobre el desempeo del proveedor es consistente, comparable, observada y se acta en
consecuencia.
b) Persona de contacto definida dentro de cada proveedor.
8 Procesos de resolucin
8.1 Gestin del incidente y solicitud del servicio
El proceso de incidentes y solicitudes del servicio debera gestionar incidentes y solicitudes de servicio
consistentemente para asegurar que la resolucin del incidente o cumplimiento de la solicitud se logra dentro de
las metas del servicio y marcos de tiempo acordados.
8.1.2 Conceptos
El proceso de gestin del incidente y solicitud del servicio debera permitir la gestin eficaz y eficiente de todos
los incidentes y solicitudes de servicio, en alineacin con las prioridades del negocio y del cliente. Los datos
recogidos como parte del proceso de incidente y solicitud del servicio se debera utilizar para monitorear el
desempeo frente a las metas pertinentes del servicio. Estos datos se pueden incluir en los informes de servicio
para el cliente.

Un incidente se considera que es una interrupcin no planificada de un servicio, una reduccin en la calidad de
un servicio o la falla de un tem de configuracin que an no afecta al servicio. Ejemplos de solicitudes de
servicio pueden incluir cambios de normas, por ejemplo, bajo riesgo, cambios bien definidos y pre aprobados,
solicitudes de informacin, solicitudes de orientacin o solicitudes de acceso a los servicios normalizados.
El proceso de gestin del incidente y solicitud del servicio se debera apoyar en dos procedimientos
documentados separados. El primero es para la gestin del incidente, el segundo para la gestin de solicitudes de
servicio. Los dos procedimientos deberan definir lo siguiente:
a) el registro consistente de incidentes y solicitudes de servicio;
b) la priorizacin y clasificacin de incidentes y solicitudes de servicio en base a las metas del servicio
documentadas y acordadas;
c) actividades necesarias para resolver incidentes y cumplir solicitudes de servicio, segn se detalla en los
prrafos siguientes;
d) las acciones necesarias para actualizar y cerrar los registros de incidente y solicitud del servicio conforme a
la confirmacin por parte del usuario que el incidente se ha resuelto o la solicitud de servicio se cumpli;
e) escalada, segn proceda, para asegurar la resolucin o cumplimiento de cada incidente o solicitud del
servicio de acuerdo con los niveles del servicio acordados.
Los procedimientos de incidente y solicitud del servicio deberan incluir la comparacin de incidentes frente a
errores y problemas conocidos y solicitudes de servicio frente al catlogo de servicios.
8.1.3 Explicaciones de los requisitos
8.1.3.1 Recepcin y registro de incidentes y solicitudes de servicio
Los procedimientos para el proceso de gestin del incidente y solicitud del servicio deberan definir los
mecanismos para recibir y registrar incidentes y solicitudes de servicio. Esto debera asegurar:
a) un enfoque consistente para el tratamiento;
b) el almacenamiento y la recuperacin de datos segn sean solicitados por una organizacin;
c) los mtodos/canales de comunicacin apropiados se utilizan y estn disponibles, tanto dentro de las horas
del servicio acordadas, como fuera de aquellas horas.
Todos los incidentes y solicitudes de servicio se deberan clasificar para que se pueda actuar en consecuencia de
acuerdo con su prioridad y el compromiso de metas del servicio. La clasificacin por tipo de incidente o solicitud
de servicio debera incluir determinar qu IC son afectados, los cuales a su vez deberan ayudar a identificar al
personal que puede necesitar estar involucrado en la resolucin o el cumplimiento.
La prioridad se debera acordar con el cliente tras la recepcin del incidente o solicitud del servicio, o tan pronto
como sea posible despus. La determinacin de la prioridad se debera basar sobre una evaluacin de impacto y
urgencia del incidente o solicitud del servicio en cuestin.
Los incidentes y solicitudes de servicio se deberan evaluar debido a posibles implicancias para la seguridad y
para determinar si los procedimientos de respuesta a incidentes de seguridad se deberan implementar adems de
la respuesta a la operacin normal. Por ejemplo, el personal operativo debera tener procedimientos establecidos
para determinar si se debera contactar al personal de seguridad de la informacin o al personal encargado de
aplicar las leyes.

Se debera desarrollar una matriz de prioridades basada en el impacto y urgencia, tanto para los incidentes como
para las solicitudes de servicio, como parte de la discusin y acuerdo de las metas del servicio. En Tabla 1 se
muestra un ejemplo de tiempos lmites de resolucin de incidentes en base a la prioridad. Tanto para los
incidentes como para las solicitudes de servicio, se deberan adoptar los principios generales de metas basadas en
cada una de las diversas categoras.
Tabla 1 - Ejemplo de matriz de tiempos lmites de resolucin de incidentes en base a prioridades
Impacto
Urgencia Mayor Alto Medio Bajo
Alta P1: Resolucin en 2 P2: Resolucin en 4 P3: Resolucin en 1 da P4: Resolucin en 2 das
horas horas
Media P2: Resolucin en 4 P3: Resolucin en 1 da P4: Resolucin en 2 das P5: Resolucin en 3 das
horas
Baja P3: Resolucin en 1 da P4: Resolucin en 2 das P5: Resolucin en 3 das P6: Resolucin en 5 das
La Tabla 1 es para incidentes, ya que las solicitudes de servicio pueden tener tiempos lmites distintos y
requieren una tabla separada.
8.1.3.2 Ciclo de vida de los incidentes y solicitudes de servicio y uso de datos
Como parte del proceso de gestin del incidente y solicitud del servicio se debera definir lo siguiente:
a) identificacin de fuentes de entrada para incidentes y solicitudes de servicio;
b) responsabilidades por la creacin y actualizacin de los registros de incidente y solicitud del servicio;
c) utilizacin de fuentes apropiadas de informacin, por ejemplo, CMDB, base de datos de errores conocidos,
el catlogo de servicios, otros documentos y registros pertinentes;
d) relacin con e/o interface para el proceso de gestin del problema;
e) reglas para escaladas, incluyendo activadores, tipos funcionales o jerrquicos y autoridad para invocar;
f) interface para el proceso de gestin del cambio cuando una solicitud de cambio se utiliza para permitir la
resolucin de incidentes o para cumplir las solicitudes de servicio;
g) responsabilidad por la verificacin de la resolucin del incidente o cumplimiento de la solicitud del

servicio;
h) la poltica y enfoque para el cierre del incidente o la solicitud del servicio, por ejemplo, el proceso debera
buscar una conformacin de la recuperacin eficaz del usuario o cliente, a continuacin actualizar el
registro, y finalmente dejar el registro en un estado de cerrado.
Sin la confirmacin de la recuperacin efectiva del usuario o cliente, el proveedor del servicio puede hacer una
suposicin inexacta de que el incidente ha sido resuelto o la solicitud del servicio se ha cumplido.
8.1.4 Procedimiento para un incidente mayor
El proceso de gestin del incidente y solicitud de servicio debera incluir un procedimiento documentado
especficamente para el tratamiento de los incidentes mayores. Un incidente mayor generalmente implica un
impacto ms alto y se requiere especial atencin para resolverlo.
El procedimiento para un incidente mayor debera definir:
a) qu constituye un incidente mayor;

b) quin tiene la autoridad para declarar un incidente mayor y cmo ste ser declarado;
c) quin debera coordinar y controlar las actividades y quin debera estar involucrado;
d) cmo los esfuerzos de resolucin se llevarn a cabo;
e) qu comunicaciones se deberan generar durante y despus de los incidentes mayores;
f) el formato, el tiempo y los participantes necesarios para una revisin del incidente mayor tras la resolucin;
g) las interfaces con el proceso de gestin de la continuidad y disponibilidad del servicio, en el evento que se
requiera la invocacin de la continuidad del servicio.
Los documentos y registros que se deberan generar y retener por el proceso de gestin del incidente y solicitud
del servicio deberan incluir:
a) procedimientos de gestin del incidente y solicitud de servicio;
b) registros del incidente;
c) registros de la solicitud del servicio;
d) registros del incidente mayor, incluyendo revisiones del incidente mayor y planes de accin;
e) informes de incidentes y solicitudes de servicio que cumplan;
f) informes de desempeo respecto de resolucin del incidente o del cumplimiento de la solicitud del servicio,
incluyendo instancias donde las metas del servicio se superaron o no se cumplieron;
g) informes estadsticos sobre los tipos de llamadas, tipos de cierre de llamadas, clasificaciones de llamadas,
desglose del volumen;
h) informes de excepcin para los incidentes y solicitudes de servicio mal manejados, donde los factores de la
calidad pueden incluir categoras tales como errores de clasificacin, ajustes de prioridad, escaladas,
incidentes reabiertos y los registros de solicitud del servicio con datos incorrectos;
i) incidentes que pasaron al proceso de gestin del problema para la investigacin del problema;
j) los mejoramientos potenciales que se han identificado o cundo se han tomado acciones.
del incidente y solicitud del servicio se deberan incluir aquellas que se listan a continuacin:
a) Gerente de incidente mayor, responsable de la invocacin del proceso de gestin del incidente mayores, del
equipo de respuesta y de identificar los roles y al personal requerido para cada incidente mayor.
b) Soporte de nivel 1, que proporciona un rol de comunicaciones para reunir los datos de los sntomas iniciales
y continuar las comunicaciones con los usuarios finales.

c) Grupos de resolucin que se pueden designar como soporte de nivel 2 y de nivel 3. A estos grupos se le
asignara una escalada de incidentes para diagnstico y resolucin, y normalmente tendran habilidades
tcnicas y experiencia superior a las del personal de soporte de nivel 1.
d) Grupos de prestaciones de servicio al que se le pueden asignar tareas para ayudar a la finalizacin de cada
solicitud de servicio.
e) Proveedores externos y vendedores que pueden proporcionar servicios de soporte segn se defina dentro de
los acuerdos y contratos de sustento.
8.2 Gestin del problema
El proceso de gestin del problema identifica las causas races subyacentes y desconocidas de los incidentes y
propone resoluciones permanentes a travs del proceso de gestin del cambio. El proceso de gestin del
problema tambin previene proactivamente que ocurran accidentes a travs del anlisis de tendencias y
recomendaciones de acciones preventivas.
8.2.2 Conceptos
El proceso de gestin del problema debera investigar las causas races de los incidentes. En consecuencia, el
proceso de gestin del problema debera minimizar o evitar el impacto de incidentes y problemas a travs de la
propuesta permanente de soluciones mediante el proceso de gestin del cambio.
El proceso de gestin del problema tambin debera generar y gestionar los registros de errores conocidos
incluyendo arreglos temporales una vez que la causa raz subyacente se ha identificado. Los registros de errores
conocidos se pueden utilizar para asegurar la resolucin eficiente del incidente y el aprendizaje de la
organizacin.
El proceso de gestin del problema debera tener un alcance definido y debera determinar los mtodos de
gestin del problema utilizados. Esto puede ser til para tener una poltica de gestin del problema que puede
definir los criterios tanto para la priorizacin como para la investigacin de problemas.
El enfoque principal del proceso de gestin del problema para muchas organizaciones se basa en los incidentes
que ya han ocurrido. Puede haber un tremendo beneficio para la organizacin en la bsqueda de soluciones
permanentes para los problemas de alto impacto y alto riesgo, que a su vez puede permitir que los servicios sean
ms confiables, rentables y eficientes.
Una vez que que el entorno se vuelve ms confiable como resultado de estas actividades de gestin del
problema, puede ser posible para el personal pasar ms tiempo en la gestin proactiva de problemas. Las
actividades de gestin proactiva de problemas deberan tener como primer objetivo prevenir que ocurran
incidentes. Por ejemplo, identificar un nico punto potencial de falla para un servicio crtico del negocio y
proponer redundancia para evitar cualquier futuro incidente que afecte al cliente.
El proceso de gestin del problema debera incluir los procedimientos que se listan a continuacin:
a) Identificacin del problema, lo que incluye:
1) deteccin de una causa raz desconocida de uno o ms incidentes;

2) el anlisis de uno o ms incidentes que revelen un problema subyacente;
3) el aviso de un proveedor o un grupo interno sobre un problema con un componente del servicio.
b) Registro del problema, para asegurar que cada problema se registra. Los registros deberan incluir los
detalles pertinentes del problema, incluyendo la fecha y hora, y una referencia cruzada para el o los
incidentes que iniciaron el registro de problemas.
c) Clasificacin y priorizacin del problema, lo que debera asegurar que:
1) cada problema se categoriza para ayudar a determinar su naturaleza y para proporcionar informacin
significativa, haciendo uso de la mismos criterios de clasificacin que utilizan en el proceso de gestin
del incidente y solicitud del servicio.
2) a cada problema se le da una prioridad para resolverlo de acuerdo a su urgencia y el impacto de los
incidentes relacionados;
3) tiempo y recursos para investigar el problema e identificar las mejores opciones de resolucin se
asignan de acuerdo a la prioridad del problema;
4) para la resolucin del problema se asigna tiempo y recursos de acuerdo a la prioridad del problema y el
beneficio de hacer el cambio a fin de cumplir los requisitos del servicio.
d) Investigacin y diagnstico del problema, lo que debera asegurar que:
1) cada problema se investiga para diagnosticar la causa raz;
2) se puede identificar un mtodo de resolucin. que depende del impacto de el o los incidentes
relacionados e incidentes relacionados, si existe o no un arreglo temporal y el costo estimado de la
resolucin;
3) la decisin para resolver el problema depende del impacto de los incidentes relacionados, si existe un
arreglo temporal y el costo de la resolucin;
4) la decisin de no resolver el problema se gestiona de acuerdo con la poltica de gestin del problema;
5) el proceso de gestin del problema es capaz de apoyar al proceso de gestin del incidente y solicitud
del servicio an antes de encontrar el error conocido, mediante la identificacin de un arreglo
temporal;
6) el diagnstico del problema es completo cuando se identifica la causa raz y se identifica un mtodo de
resolucin del problema.
e) Monitoreo del problema, lo cual debera asegurar que el avance de todos los problemas se registra para:
1) seguir el avance a travs del proceso de gestin del problema. incluyendo detalles de la persona
actualmente responsable del avance del problema;
2) registrar todos los recursos utilizados y acciones tomadas.
f) Escalada del problema, lo cual debera asegurar que todos los asuntos se escalan a las partes apropiadas
incluyendo:
1) identificacin de el o los incidentes relacionados con el incumplimiento de las metas del servicio;

2) informacin en cascada para el cliente de modo que pueda tomar las acciones apropiadas para
minimizar el impacto del problema no resuelto;
3) permitir la recepcin del servicio o soporte de nivel 1 para proporcionar actualizaciones regulares a
usuarios o consumidores afectados;
4) definir los puntos de escalada.
g) Documentar los errores conocidos, lo que debera asegurar que:
1) cuando se identifica la causa raz y un mtodo propuesto de resolucin del problema, se registra un
error conocido en la base de datos de errores conocidos, junto a los detalles de algn arreglo temporal;
2) el registro de un error conocido no est cerrado hasta despus de la solucin permanente se ha

implementado satisfactoriamente mediante el proceso de gestin del cambio;
3) los registros de los errores conocidos se ponen a disposicin todo el personal pertinente, los que
regularmente son informados de todos los registros de errores conocidos, nuevos o actualizados;
4) si el registro de un error conocido permanece abierto por un intervalo de tiempo definido, se revisa y se
mantiene al da de modo que no se mantenga informacin obsoleta en la base de datos de errores
conocidos;
5) todos los errores conocidos se registran frente a los servicios actual y potencialmente afectados y el
tem de configuracin sospechoso de ser culpable.
h) Cierre del registro del problema, cuando se identifica y registra un error conocido, lo cual debera asegurar
que:
1) los detalles de la resolucin se han registrado con exactitud;
2) el registro del problema se ha adaptado a los incidentes relacionados para facilitar el anlisis;
3) la causa raz se categoriza para facilitar el anlisis.
i) Mantener las revisiones de los problemas importantes para investigar problemas sin resolver, inusuales o de
alto impacto, lo cual debera asegurar:
1) se identifican y gestionan los riesgos para el negocio, el cliente y o proveedor del servicio;
2) hay visibilidad de la gestin sobre las razones de los problemas no resueltos, como as tambin su
impacto en el negocio en marcha.
j) Las revisiones de los problemas se deberan registrar y se deberan incluir recomendaciones apropiadas
sobre mejoramientos del servicio. Se deberan revisar:
1) oportunidades para mejorar el proceso de gestin de gestin del problema;
2) oportunidades para mejorar otros procesos, servicios o el SGS;
3) cmo prevenir la recurrencia o un tipo particular de problema;
4) si se debera proporcionar formacin o toma de conciencia para corregir o prevenir los incidentes
causados por error humano;

5) si ha habido alguna responsabilidad por parte de los proveedores, clientes o grupos internos por los
problemas que han ocurrido y si se requieren las acciones de monitoreo.
k) Gestin proactiva del problema, la que debera asegurar que:
1) los datos de incidentes y problemas, la CMDB y otras fuentes de informacin pertinente se analiza
para identificar tendencias;
2) los datos de incidentes y problemas, la CMDB y otras fuentes de informacin pertinente se pueden
utilizar para mejorar la toma de decisiones y ayudar a anticiparse a posibles degradaciones de servicio;
3) el conocimiento obtenido a partir de la revisin de un problema se comunica al cliente para asegurarse

de que el ste es consciente de las acciones tomadas y de las recomendaciones de mejoramiento del
servicio identificadas;
4) se definen mediciones clave que demuestran el valor de negocio de la gestin proactiva de problemas;
5) se identifican los posibles puntos singulares de falla, las tendencias y riesgos emergentes en los
servicios y se proponen opciones a travs del proceso de gestin del cambio.
Los documentos y registros, que se deberan generar y retener por el proceso de gestin del problema deberan
incluir:
a) procedimientos de gestin del problema;
b) registros de problemas;
c) registros de errores conocidos;
d) detalles de arreglos temporales;
e) vnculos para cambios que dan como resultados arreglos permanentes;
f) registros de revisin de problemas incluyendo actas de reuniones de revisin de problemas;
g) informes de gestin, incluyendo informacin sobre las tendencias de incidentes y problemas;
h) recomendaciones para el mejoramiento del servicio.
Para facilitar y apoyar el proceso de gestin del problema puede ser til una poltica de gestin del problema.
del problema se debera incluir:
a) personal que lleva a cabo el anlisis de causa raz de los problemas, determina la resolucin y/o arreglo
temporal y crea el registro de datos del error conocido asociado;
b) proveedores, clientes o grupos internos involucrados en proporcionar resoluciones, arreglos temporales,

informacin de errores conocidos, recomendaciones y revisiones.

9 Procesos de control
9.1 Gestin de la configuracin
El proceso de gestin de la configuracin debera incluir la identificacin, control, registro, monitoreo, informe y
verificacin de los temes de configuracin y la gestin de la informacin de IC en la CMDB. Se debera
establecer y mantener la integridad de la informacin sobre los servicios identificados, componentes del servicio
e IC a travs del ciclo de vida del servicio. El proceso de gestin de la configuracin tambin debera identificar,
gestionar y verificar la informacin sobre relaciones entre IC, como as tambin las relaciones entre IC y los
servicios que apoyan.
El alcance del proceso de gestin de la configuracin debera excluir la gestin de activos financieros pero
incluir una interface al proceso de gestin de activos financieros.
9.1.2 Conceptos
El proceso de gestin de la configuracin debera proporcionar un punto focal para la gestin y control de la
evolucin de las configuraciones y activos del servicio, como as tambin sus relaciones. Debera incluir
actividades para planificar y llevar a cabo el proceso de gestin de la configuracin.
La gestin de la configuracin debera documentar la definicin de cada tipo de IC e identificar cada IC de

acuerdo a la poltica y procedimientos de gestin de la gestin de la configuracin. La informacin registrada
para cada IC debera asegurar el control eficaz de cada IC y su informacin de configuracin asociada.
La informacin de configuracin asociada se registra en una CMDB que incluye datos sobre temes de
configuracin, versiones, relaciones, lneas de base y entregas. La informacin para cada IC debera incluir un
identificador, descripcin, estado, ubicacin, sus relaciones y registros asociados tales como solicitudes de
cambio, incidentes, problemas y registros de errores conocidos. La informacin de la configuracin la deberan
mantener personas aprobadas y estar disponible slo para partes interesadas aprobadas.
9.1.3.1 Actividades de la gestin de la configuracin
La planificacin para el proceso de gestin de la configuracin debera permitir a un proveedor de servicios

lograr un grado de control que sea suficiente para:
a) cumplir los requisitos acordados del cliente, usuario, proveedor del servicio y otras partes interesadas;
b) asegurar que los activos, incluyendo las licencias, utilizadas para prestar los servicios se gestionan de
acuerdo a los requisitos estatutarios y reglamentarios y las obligaciones contractuales;
c) asegurar que se mantiene la integridad de la informacin sobre los servicios y componentes de stos;
d) mantener la informacin de configuracin registrada para asegurar su confiabilidad y exactitud.

9.1.3.2 Recursos y capacidad
El proceso de gestin de la configuracin se debera planificar para asegurar que hay suficientes recursos y
capacidades para la implementacin y mantenimiento de la evolucin de los registros de IC. El alcance del
proceso de gestin de la configuracin y la poltica debera incluir:
a) planificar el alcance del proceso de gestin de la configuracin alineado con el SGS y el alcance del proceso
de gestin del cambio;
b) la definicin de cada tipo de IC y sus relaciones con otros IC y componentes del servicio;
c) autorizacin para acceder y controlar los cambios a los IC;
d) procedimientos documentados para identificar, registrar, controlar y hacer monitoreo a las versiones y el
estado de los IC.
e) las ubicaciones y condiciones de almacenamiento de los IC fsicos y en el caso de informacin, medios de

almacenamiento, de acuerdo con niveles designados de integridad, proteccin y seguridad;
f) los criterios o eventos para iniciar el control de la configuracin y mantenimiento de las lneas de base de
las configuraciones cambiantes;
g) un procedimiento documentado que incluya las autoridades y responsabilidades por la planificacin y

realizacin de auditoras, informar resultados y el mantenimiento de los registros de auditora;
h) planificacin para la eliminacin, archivo, disposicin o la transferencia de datos con respecto a IC de

acuerdo con los requisitos estatutarios y reglamentarios y las obligaciones contractuales;
i) automatizacin suficiente para asegurar el control eficaz, por ejemplo, para reducir las oportunidades de
error humano.
9.1.3.3 Identificacin y definicin de IC
La planificacin debera incluir la identificacin y definicin de tipos de IC que se someten al control del
proceso de gestin de la configuracin. Los IC se deberan escoger utilizando criterios de seleccin establecidos,
agrupados, clasificados e identificados de forma tal que sean manejables y trazables a travs de su ciclo de vida.
Cada servicio se debera clasificar o segregar en grupos de componentes constituyentes del servicio, lgicamente
relacionados y subordinados que permitan:
a) que las partes interesadas encuentren y utilicen la informacin de configuracin que estn autorizados a
utilizar;
b) un entendimiento comn entre las partes interesadas sobre cmo la informacin sobre los IC y sus
relaciones se gestionan;
c) que el personal involucrado en todos los procesos de gestin del servicio tenga acceso a la CMDB, a la
poltica y a los procedimientos de gestin de la configuracin que son necesarios o tiles para ayudarlos a
cumplir su rol;
d) al proveedor del servicio implementar un acceso editable a la CMDB solamente para el personal que tiene
los niveles correctos de autoridad y proporciona acceso de lectura a todos los otros miembros del personal.

Cuando sea apropiado, los IC se deberan identificar claramente mediante identificadores o marcas nicas e
identificables. Los identificadores deberan estar de acuerdo con las normas y convenciones pertinentes, de modo
que todos los IC bajo el control del proceso de gestin de la configuracin sean trazables sin ambigedad a sus
especificaciones o descripciones documentadas y equivalentes. Debera haber una lista de IC y una definicin de
la informacin que se debe registrar para cada IC. Se deberan identificar las dependencias y relaciones
apropiadas entre los IC para proporcionar el grado necesario de visibilidad y control.
9.1.3.4 Tipos de IC
Los tipos de IC deberan incluir:
a) servicios segn se listan en el catlogo de servicios y sus documentos e informacin relacionada, por
ejemplo, SLA, acuerdos, contratos, requisitos del servicio, especificacin del diseo del servicio;
b) componentes del servicio incluyendo el hardware, software y licencias, herramientas, aplicaciones,

documentacin, servicios de soporte;
c) todos los asuntos y entregas de servicios, sistemas y lneas de base de la configuracin del software o
construir declaraciones para cada entorno y norma de construccin de hardware aplicable, por ejemplo,
imagen de una configuracin de hardware;
d) copias maestras de IC almacenados en libreras fsicas y/o electrnicas, la CMDB y las herramientas
utilizadas;
e) activos de seguridad de la informacin;
f) activos que necesitan monitoreo por la gestin de activos financieros o razones del negocio, por ejemplo,
medios magnticos seguros, equipos;
g) documentacin del SGS, por ejemplo, polticas, documentacin del proceso, procedimientos, planes.
Cada tipo de IC debera tener asociada informacin en la CMDB o en documentos o registros integrados.
9.1.3.5 Mantenimiento de IC
Realizar la gestin de configuracin debera incluir actividades para mantener la informacin sobre los IC y sus
relaciones con un nivel apropiado de integridad y seguridad.
Los procedimientos de control de la configuracin deberan asegurar que slo los tipos de IC acordados e
identificables se aceptan y se conservan en un entorno adecuado y seguro. Los IC no se deberan aadir,
modificar, sustituir o eliminar/retirar sin la documentacin de control apropiada, por ejemplo, una solicitud de
cambio aprobada. El estado de evolucin de los IC a travs de sus ciclos de vida se debera documentar como
una lnea de base que se activa en momentos establecidos o bajo circunstancias definidas. Se debera registrar la
justificacin de la lnea de base. Los registros de configuracin se deberan mantener a lo largo de el ciclo de
vida del IC y archivar o eliminar de acuerdo a la poltica de gestin de la configuracin.
Para proteger la integridad de los sistemas, los servicios y la infraestructura, los registros de los IC y la CMDB se
debera conservar en un entorno adecuado y seguro. Este entorno debera protegerlos del acceso no autorizado,
cambios o corrupcin de la CMDB. Tambin deberan haber medios para la recuperacin ante desastres de la
CMDB y un mtodo que permita la recuperacin controlada del maestro controlado, por ejemplo, software,
medios electrnicos.

Las actividades de auditora de la configuracin se deberan realizar a intervalos planificados y en respuesta a

eventos especficos. Los procedimientos y recursos adecuados deberan estar en su lugar para:
a) verificar que el proveedor del servicio est en control de la informacin sobre todos los IC y sus relaciones
dentro del alcance de los procesos;
b) verificar que el proveedor del servicio est en control de la informacin sobre la ubicacin y cantidad de
licencias de software;
c) proporcionar confianza en que la informacin de la configuracin es exacta, controlada y visible para el

personal aprobado;
d) identificar la causa de las discrepancias entre la informacin de la configuracin real y la esperada, y

resolver en coordinacin con el proceso de gestin del cambio;
e) asegurar que se hace una lnea de base de configuracin a intervalos regulares y al menos antes del
despliegue de una entrega en el entorno real;
f) asegurar la confidencialidad y accesibilidad de la informacin en la CMDB.
Los documentos y registros que se deberan generar y retener mediante el proceso de gestin de la configuracin
deberan incluir:
a) una poltica de gestin de la configuracin;
b) procedimientos para el proceso de gestin de la configuracin;
c) informacin exacta y al da sobre los IC y sus relaciones con otros IC, componentes del servicio y servicios;
d) definiciones de tipos de IC;
e) lnea de base de la configuracin;
f) informes de gestin de la configuracin;
g) informes de auditora de la configuracin;
h) un procedimiento documentado que especifique la frecuencia y las pruebas de respaldo de la CMDB.
de la configuracin se debera incluir:
a) al cliente, usuarios, personal del proveedor del servicio y partes interesadas con acceso autorizado a la
informacin de la configuracin;
b) personal que mantiene la CMDB;
c) activo responsable o dueo del IC que asegure que se entrega la actualizacin con respecto al estado de los
IC;
d) proveedores internos y externos de activos e IC.

9.2 Gestin del cambio
El proceso de gestin del cambio debera gestionar cambios a travs de su ciclo de vida, asegurando que todos
los cambios se evalen, aprueben, implementen y revisen de una forma controlada.
9.2.2 Conceptos
El proceso de gestin del cambio proporciona un enfoque estructurado para la implementacin eficaz de los
cambios y minimiza el riesgo e idealmente la prevencin de incidentes causados falta de gestin o cambios
gestionados deficientemente.
Para permitir la visibilidad y control necesarios, todas las solicitudes de cambio se deberan registrar y clasificar.
Se debera establecer y comunicar a las partes interesadas un calendario de cambios que contenga detalles de los
cambios aprobados para el desarrollo y las fechas de implementacin propuestas, actualizado segn sea
necesario.
A continuacin se indican ejemplos tpicos de tipos de solicitudes de cambio:
a) Cambio de emergencia: un cambio que se debera implementar lo ms pronto posible. Por ejemplo, para
resolver un incidente mayor o implementar un parche de seguridad de la informacin.
b) Cambio normal: cualquier cambio en el servicio planificado que no es un cambio estndar o un cambio de
emergencia.
c) Cambio estndar: un cambio preautorizado que es de bajo riesgo, relativamente comn y sigue un
procedimiento o instruccin de trabajo.
Los cambios normales se pueden clasificar como mayor, significativo y menor, dependiendo del nivel de costo y
riesgo involucrado. Esta categorizacin se puede vincular a, y utilizar para, identificar una autoridad de cambio
apropiada, una persona con autoridad para esa categora de cambio.
Los procedimientos se deberan documentar y utilizar para controlar el registro, clasificacin, evaluacin,
aprobacin, planificacin, desarrollo, prueba y despliegue de todos los cambios.
Despus de la implementacin exitosa de los cambios, el proceso de gestin del cambio debera informar al
proceso de gestin de la configuracin que la CMDB se debera actualizar para reflejar el nuevo entorno.
9.2.3.1 Poltica de gestin del cambio
Se debera establecer y documentar una poltica de gestin del cambio que defina los IC bajo el control del
proceso de gestin del cambio. Todas las solicitudes de cambio para IC definidas en la poltica de gestin del
cambio como dentro del alcance del proceso de gestin del cambio se debera gestionar mediante el proceso.
Los cambios con el potencial de tener un impacto importante sobre los servicios o el cliente se deberan
clasificar de acuerdo a criterios definidos en una poltica de gestin del cambio. Estos cambios se deberan
gestionar utilizando el diseo y transicin de procesos del servicio nuevos o modificados, y coordinados con el
proceso de gestin del cambio.

La poltica de gestin del cambio debera definir criterios para determinar qu cambios se deberan gestionar a
travs del proceso de gestin del cambio y cuyos cambios se deberan gestionar a travs del diseo y transicin
de procesos del servicio nuevos o modificados.
Los criterios utilizados para determinar los cambios a gestionar a travs del diseo y transicin de los proceso de
servicios nuevos o modificados debera incluir cambios para la eliminacin de un servicio y cambios para la
transferencia de un servicio desde el proveedor del servicio a otra parte. La otra parte puede ser el cliente o un
proveedor.
9.2.3.2 Planificacin e implementacin
Las solicitudes de cambio deberan tener un alcance documentado y ellas se deberan clasificar de acuerdo a
criterios definidos y acordados. Las solicitudes de cambio se deberan evaluar y aprobar antes del desarrollo o
construccin, tomando en cuenta los riesgos, impactos a los servicios y a los clientes, ramificaciones financieras,
beneficios del negocio y viabilidad tcnica.
La gestin de la construccin, prueba e implementacin de los cambios se debera coordinar con el proceso de
gestin de la configuracin y el proceso de gestin de la entrega y despliegue.
Las actividades necesarias para revertir o remediar un cambio fallido se deberan planificar y probar. El cambio
se debera revertir o remediar si fracasa. Los cambios fallidos se deberan investigar para as tomar las acciones
apropiadas.
Se debera establecer y comunicar a las partes interesadas un calendario de cambios que contenga los detalles de
los cambios aprobados para el desarrollo y las fechas de implementacin propuestas, por ejemplo, soporte de
nivel 1; GRN, gestin de proveedores.
Los procedimientos y el proceso de gestin del cambio deberan asegurar que:
a) los cambios tienen un alcance claramente definido y documentado que identifica los temes de
configuracin afectados;
b) la toma de decisiones sobre la aceptacin y aprobacin de solicitudes de cambio toman en consideracin los
riesgos, prioridades, impactos potenciales a los servicios a al cliente, los requisitos del servicio, beneficios
del negocio, viabilidad tcnica e impacto financiero;
c) se establece un calendario de cambios que contiene detalles de los cambios aprobados y las fechas de
desarrollo propuestas;
d) el calendario de cambios se comunica a las partes interesadas;
e) el calendario de cambios se utiliza para planificar el despliegue de entregas;
f) los cambios aprobados para los temes de configuracin y los servicios identificados se desarrollan y
prueban de acuerdo al calendario de cambios;
g) los cambios se despliegan de acuerdo al calendario de cambios;
h) las actividades para revertir o remediar un cambio fallido se planifican y prueban;
i) los cambios fallidos se revierten o remediar y las razones para el cambio fallido se investigan y
documentan;
j) la CMDB se actualiza despus del despliegue, independientemente del xito o fracaso del cambio.

9.2.3.3 Revisin de la solicitud de cambio
Las solicitudes de cambio registradas se deberan analizar a intervalos planificados para identificar niveles
crecientes de cambios, tipos frecuentemente recurrentes, tendencias emergentes y otra informacin pertinente.
Los resultados y las conclusiones extrados del anlisis de cambios se deberan registrar y utilizar para identificar
oportunidades de mejoramiento. Cualquier no conformidad se debera registrar para as tomar acciones.
Cualquier debilidad o deficiencia identificada en el proceso de gestin del cambio como resultado de una
revisin de una solicitud de cambio particular se debera incorporar en los planes de mejoramiento.
Una vez que se despliega y acepta el cambio, la solicitud de cambio se debera cerrar. La solicitud de cambio
tambin se debera cerrar cuando se ha tomado la decisin de no llevar a cabo el cambio. Cuando se ha cerrado
la solicitud de cambio, el resultado del cambio se debera informar al iniciador de la solicitud de cambio y a las
otras partes interesadas.
9.2.3.4 Cambios de emergencia
Los cambios de emergencia se deberan diferenciar de los otros cambios, debido al aumento del riesgo y a
menudo al aumento del costo de aprobarlos e implementarlos.
Para los cambios de emergencia deberan haber un proceso definido que incluya acuerdos para aprobar y
posteriormente implementar y revisar la documentacin. Los cambios de emergencia los debera aprobar una
autoridad de cambios apropiada y si es posible, comunicada a las partes interesadas.
Los cambios de emergencia se pueden utilizar para resolver situaciones de emergencia donde no hay suficiente
tiempo para adherirse a los procedimientos del proceso de cambio, plazos y autoridades de aprobacin
habituales. Cuando sea posible, el proceso de cambio normal se debera seguir. Sin embargo, debido a la
urgencia de implementar un cambio de emergencia, algunos detalles se pueden documentar retrospectivamente y
algunas pruebas puede que no sean posibles. An si algunas de estas etapas se omiten para dar cabida a la
urgencia de la emergencia, debera haber un plan para revertir o remediar el cambio de emergencia si ste es
fallido. Cuando el procedimiento de emergencia omita otros requisitos de la gestin del cambio, por ejemplo,
pruebas incompletas previas a la implementacin, el cambio debera cumplir con estos requisitos tan pronto
como sea practicable. Los cambios de emergencia deberan estar justificados por el implementador y revisados
despus del cambio de verificar que sta fue una verdadera emergencia.
Los documentos, incluyendo los registros, que se deberan generar y retener:
a) poltica de gestin del cambio;
b) procedimientos y documentacin del proceso de gestin del cambio, incluyendo un procedimiento para el
cambio de emergencia y un procedimiento para el cambio estndar;
c) una lista de cambios estndar aprobada;
d) un calendario de cambios;
e) solicitudes de cambio registradas y cualquier informacin relacionada, por ejemplo, evaluacin del riesgo,
plan de remediacin, plan de despliegue;
f) informes de la eficiencia y eficacia del proceso de gestin del cambio;
g) informes de gestin del cambio, incluyendo revisiones posteriores a la implementacin.

Los registros de cambio asociados a cada solicitud de cambio, se deberan registrar en un log de cambio
adecuado. Si la organizacin tiene una CMDB, el registro de cambio se debera asociar al IC pertinente mediante
un vnculo al registro del IC. Idealmente este vnculo entre el registro de cambio y el o los IC pertinentes debera
ser visible desde el momento en que se registra la solicitud de cambio, a travs de la aprobacin y ejecucin.
del cambio se deberan incluir aquellas que se listan a continuacin:
a) Los roles y personas que pueden registrar y clasificar una solicitud de cambio.
b) Un dueo que es responsable de gestionar el ciclo de vida de cada solicitud de cambio, por ejemplo, dueo
del servicio, deo del proceso.
c) Representantes nominados para proporcionar recomendaciones sobre el impacto de los cambios. Esto puede
ser una mesa de recomendaciones de cambios que generalmente incluye representantes del proveedor del
servicio, del cliente y de las partes interesadas dependiendo del alcance y el impacto del cambio en el
servicio y el entorno del negocio.
d) Una autoridad de cambio para tomar decisiones sobre la aceptacin y aprobacin del cambio. Una autoridad
de cambio debera ser pertinente para el tipo de cambio y puede ser un rol nominado, una persona o una
mesa de recomendaciones de cambios y una mesa de recomendaciones de cambios de emergencia.
9.3 Gestin de la entrega y despliegue
El proceso de gestin de la entrega y despliegue debera asegurar que todas las entregas se desplieguen
eficazmente en el entorno real de modo que la integridad del hardware, software y componentes del servicio se
mantenga. El proceso de gestin de la entrega y despliegue debera coordinar todos los aspectos de una entrega.
Esto debera incluir la funcionalidad tcnica, la integracin con el entorno, asignacin de los recursos para
desarrollar, probar y desplegar la entrega, formacin, soporte, documentacin de la entrega. Todos los aspectos
se deberan considerar juntos para asegurar que la entrega sea exitosa.
La integridad del entorno real se debera proteger y los trastornos se deberan minimizar a travs de la
planificacin, pruebas y coordinacin apropiada con el proceso de gestin del cambio.
9.3.2 Conceptos
El proceso de gestin de la entrega y despliegue es responsable de coordinar las entregas grandes o complejas y
las entregas menores. El proceso de gestin de la entrega y despliegue por lo tanto se debera disear para
permitir la coordinacin y gestin eficaz de las entregas con alcance, complejidad y grados de riesgo distintos.
Una entrega puede ser uno o ms cambios a un servicio que se construyen, prueban y despliegan juntos. Los
cambios mltiples se pueden empaquetar juntos en una o ms entregas para ayudar a gestionar las dependencias
y para la eficiencia. Un paquete de entrega debera incluir un conjunto de IC que se desplegar junto como una
sola entrega.
El proceso de gestin de la entrega y despliegue debera asegurar que los cambios dentro de cada entrega son
compatibles entre s.
El despliegue debera ser responsable de distribuir y prestar el servicio y los componentes del servicio en la
ubicacin y hora correcta en el entorno de destino.

El proveedor del servicio debera coordinar las actividades de entrega y despliegue con los clientes, usuarios y
partes interesadas. En muchos casos las entregas se deberan coordinar con proyectos de cambio del negocio y
con la gestin del cambio del negocio para asegurar la alineacin con los programas pertinentes de toma de
conciencia, comunicacin y formacin.
El proceso de gestin de la entrega y despliegue debera planificar y gestionar las entregas individuales para los
servicios nuevos o modificados en coordinacin con el diseo y transicin de los procesos de servicios nuevos o
modificados y el proceso de gestin del cambio.
Cuando sea posible, las entregas deberan utilizar mtodos normalizados o consistentes para asegurar la
integridad de los IC. Las entregas se pueden lograr de manera ms rentable mediante la bsqueda de eficiencias
de escala a travs del uso de mtodos normalizados y cuando sea factible, utilizando la automatizacin.
9.3.3.1 Poltica de entrega
El proveedor del servicio, en conjunto con el cliente y las partes interesadas, debera desarrollar y acordar una
poltica de entrega para ayudar a especificar la frecuencia de las entregas y el enfoque para cada tipo de entrega.
Una poltica de entrega generalmente puede incluir:
a) la definicin de cada tipo de entrega incluyendo una entrega de emergencia, otros ejemplos son mayor,
significativo y menor;
b) la frecuencia de cada tipo de entrega;
c) definicin de roles clave y responsabilidades para todas las actividades de los procesos de gestin de la
entrega y despliegue;
d) niveles de autoridad para la aceptacin de la entrega y aprobacin del despliegue;
e) reglas para la verificacin y aceptacin de las entregas;
f) identificacin de esquemas para entregas;
g) reglas para las versiones de las entregas;
h) construccin y empaquetado de entregas;
i) enfoque de la entrega y despliegue para cada tipo de entrega, incluyendo mtodos de despliegue
automatizados y herramientas cuando sea aplicable;
j) un enfoque de prueba predefinido y consistente.
9.3.3.2 Planificacin de la entrega y despliegue
El proceso de gestin de la entrega y despliegue debera planificar la entrega y despliegue de un servicio nuevo o
modificado en el entorno real con el cliente y las partes interesadas. Se deberan utilizar los mtodos y tcnicas
de gestin de proyectos para apoyar la planificacin de la entrega y despliegue. La informacin mnima para los
planes de entrega y despliegue los debera definir el proveedor del servicio y pueden diferir de acuerdo al tipo de
entrega.

Los planes de entrega y despliegue siempre deberan asegurar que todos los cambios se coordinan con el proceso
de gestin del cambio. La planificacin de la entrega y despliegue debera incluir una evaluacin de impacto de
la entrega, los riesgos asociados y la identificacin de cualquier medida de mitigacin que se empleara para
minimizar los riesgos inaceptables.
Los factores tpicos que se deberan considerar cuando se planifica una entrega y su despliegue son el volumen
del negocio, cambios tcnicos y de otro tipo necesarios para desplegar una entrega. Por ejemplo, nuevas
habilidades, procesos nuevos o modificados y nuevas herramientas. Otros factores incluyen dependencias y el
tiempo y los recursos necesarios para construir, probar y desplegar una entrega.
Los planes de entrega y despliegue deberan incluir los componentes siguientes:
a) alcance y contenido de la entrega incluyendo los entregables;
b) servicios y componentes del servicio para transferir, dar de baja o retirar incluyendo las licencias;
c) programa para el empaquetado y despliegue de la entrega con fechas que se determinen en consulta con el
cliente para cada sito nominado;
d) roles y responsabilidades para planificar, coordinar, construir, probar, desplegar y revisar la entrega;
e) los mtodos y procedimientos para la entrega y despliegue que aseguren la integridad del software,
hardware y otros componentes del servicio durante el despliegue;
f) planes para las actividades de comunicacin que proporcionen la informacin necesaria a los usuarios
dentro de la organizacin del cliente, al personal dentro del proveedor del servicio y a los proveedores
pertinentes;
g) el enfoque para identificar, hacer monitoreo y gestionar cualquier asunto detectado durante la entrega;
h) planes de prueba que incluyan temes tales como criterios de aceptacin, mtodos de prueba, notas y hojas
de registro de resultados;
i) cuando sea apropiado, un enfoque para gestionar entornos de prueba controlados, para asegurar que las
entregas puedan ser suficientemente probadas antes del piloto, experiencia y/o despliegue;
j) enfoque para gestionar activos y IC de acuerdo a los procedimientos y polticas aplicables, por ejemplo,
gestin de activos, gestin de la configuracin, salud y seguridad, entorno, gestin de la seguridad de la
informacin;
k) los criterios frente a los cuales se deberan verificar las entregas y el despliegue, junto con los criterios
apropiados y el enfoque aprobado a utilizar para revertir o restaurar las entregas fallidas;
l) los requisitos definidos, o referencias a stos, en los planes para:
1) las instrucciones de trabajo para la entrega y desarrollo, independientemente de la utilizacin de

recursos internos o externos;
2) herramientas que se requieren para efectuar la entrega, incluyendo el uso de herramientas y tcnicas
para la instalacin remota o desatendida de software;
3) la implementacin de cambios estndar que se aprueban para entregas mediante el proceso de gestin
del cambio;
4) actualizacin de los detalles de la configuracin de cualquier servicio, componentes del servicio y IC

afectados por la entrega.
9.3.3.3 Prcticas de entrega y despliegue
Cada entrega debera contener un conjunto de IC. El proceso de gestin de la entrega y despliegue debera
trabajar estrechamente con el proceso de gestin de la configuracin para asegurar que los IC se definen
correctamente de acuerdo a:
a) tipos de IC acordados, por ejemplo, una poltica de gestin de la configuracin;
b) relaciones con otros IC.
c) nombre y versiones de las convenciones;
d) hardware tcnico y construcciones de entorno;
e) imgenes de software;
f) instrucciones de trabajo.
Esto debera asegurar la integridad de la informacin de los servicios y los componentes del servicio durante el
despliegue.
Los contenidos de una entrega deberan asegurar la adecuacin de la entrega para el despliegue. Los contenidos
de una entrega deberan definir los activos e IC que se adquirirn e instalarn segn los componentes de la
entrega. Esto puede incluir licencias del software maestro que se requiere adquirir y posteriormente almacenar en
la biblioteca del software. Esto tambin puede incluir la adquisicin de temes de hardware que se deberan
realizar en una tienda de hardware identificada.
Se deberan utilizar prcticas coherentes de trabajo y los procedimientos definidos que se han probado a travs
de pruebas, pilotos y experiencias. Ejemplos de tales prcticas de trabajo y procedimientos incluyen:
construccin de la entrega, prueba, distribucin de la entrega, verificacin, y si es necesario la revocacin o
remediacin de la entrega.
El proceso de gestin de la entrega y despliegue debera definir los mtodos y prcticas que se emplean para las
entregas de emergencia en coordinacin con la interface con el procedimiento de gestin del cambio de
emergencia.
9.3.3.4 Pruebas de entregas
Las actividades de prueba deberan incluir:
a) crear un plan de prueba;
b) crear rutinas de prueba y preparar el entorno de prueba para la entrega;
c) actividades de prueba a realizar en el entorno de prueba;
d) pruebas de aceptacin de usuario;
e) registro de los resultados de pruebas, incluyendo versin, asuntos y hora y fecha en que se encuentra el
asunto;
f) elaboracin de un informe de prueba;
g) firmar la entrega, siempre que cumpla con los criterios de aceptacin y es apta para el propsito.
9.3.3.5 Procedimientos y actividades de despliegue
Los procedimientos y las actividades de despliegue deberan incluir lo siguiente:
a) distribucin y suministro de los IC que soportan el servicio y los componentes del servicio en el lugar y
hora correctos;
b) construccin, instalacin y configuracin de los IC con todos los datos nuevos o convertidos e informacin;
c) verificacin de que los servicios y los componentes del servicio se han probado de acuerdo a las pruebas de
aceptacin y que se emiten informes de las instalaciones y las pruebas;
d) actualizacin de los registros para la nueva entrega y cualquier IC o servicios eliminado durante la
transicin;
e) registro de los incidentes, problemas, errores conocidos, eventos inesperados o desviaciones de los planes;
f) implementacin de acciones correctivas durante el despliegue;
g) invertir o tomar medidas correctivas para corregir una entrega fallido.
Los documentos y registros que se deberan generar y retener por el proceso de gestin de la entrega y
despliegue incluyen:
a) poltica de entrega;
b) plan de entrega;
c) contenido de cada entrega incluyendo cambios relacionados aprobados mediante el proceso de gestin del
cambio;
d) contenido de cada entrega incluyendo nuevos componentes, componentes alterados como resultado de las
actividades de entrega y despliegue, componentes retirados que se recuperan o pasan a obsoletos durante el
despliegue;
e) diseo de la entrega, notas de la entrega, y guas de instalacin para la entrega;
f) plan de despliegue, que puede estar en la forma de un plan de proyecto;
g) un calendario de entregas y despliegues que indique los periodos cuando las entregas no se pueden
calendarizar debido al riesgo elevado para el cliente en ese periodo, por ejemplo, cierre del ao financiero;
h) evaluacin de impacto del usuario y evaluacin de impacto del cambio en el negocio;
i) plan de comunicacin;
j) plan de formacin que abarca los usuarios, personal de proveedores de servicios y partes interesadas;
k) planes de prueba de entrega y despliegue y resultados de las pruebas;
l) aceptacin de la entrega y firma del cliente;
m) registros de xitos y fracasos junto con listas de acciones de monitoreo o logs de incidentes;
n) registros del incidente, problema o error conocido para las fallas de la entrega, inversiones o trabajos de
remediacin;
o) informacin del IC para cada entrega:
1) identificado y versin de la entrega;
2) descripcin de la entrega;
3) relacin entre la entrega y los IC que la conforman;
4) ubicacin del paquete de entrega e instalacin;
5) solicitudes de cambio asociadas;
6) incidentes, problemas y errores conocidos asociados, incluyendo aquellos que fueron corregidos por la
entrega.
de la entrega y despliegue se debera incluir:
a) el cliente o el representante del cliente, responsable de planificar y coordinar las entregas y el despliegue
con las actividades de cambio del negocio;
b) el usuario, responsable de operar el servicio o componente del servicio nuevo o modificado y cuando sea
aplicable realizar pruebas de usuario;
c) personal del proveedor del servicio, responsable de probar las actividades operativas para el servicio o
componente del servicio nuevo o modificado.

Anexo A
(informativo)
Interfaces entre procesos e integracin de procesos con el SGS
Los ejemplos listados en todas las tablas de este Anexo no son exhaustivo.
Tabla A.1 - Interfaces e integracin para el diseo y transicin de los servicios nuevos o modificados
Ejemplos de interfaces entre el diseo y la transicin de servicios nuevos o modificados y el resto del SGS incluyen:
El proceso de GNS debera proporcionar los requisitos del nivel de servicio de los servicio nuevos o modificados.
El proceso de GNR debera proporcionar todos los requisitos del cliente y del negocio del servicio nuevo o modificado, para asegurar
que stos se identifican, documentan, acuerdan y satisfacen.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar detalles sobre el impacto de la introduccin de los
servicios nuevos o modificados despus de la transicin en el nuevo entorno.
El proceso de gestin de la entrega y despliegue debera proporcionar recomendaciones sobre el momento y mtodo de despliegue.
El presupuesto y contabilidad para el proceso de servicio debera recibir un informe de los costos estimados por la provisin del
servicio modificado.
El proceso de gestin del cambio debera recibir solicitudes de cambio que sean introducidas mediante la introduccin de servicios
nuevos o modificados.
Ejemplos de integracin entre el diseo y la transicin de servicios nuevos o modificados y el resto del SGS incluyen:
El diseo y la transicin de servicios nuevos o modificados debera recibir el registro de no conformidad de auditora como una
entrada para identificar requisitos potenciales para los servicios nuevos o modificados.
El diseo y la transicin de servicios nuevos o modificados debera recibir el informe de anlisis de satisfaccin del cliente como una
entrada para identificar requisitos potenciales para los servicios nuevos o modificados para abordar la satisfaccin del cliente.
Tabla A.2 - Interfaces e integracin para la GNS
Ejemplos de interfaces entre la GNS y el resto del SGS incluyen:

El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar continuidad o disponibilidad de los
requisitos. Como entrada para el SLA, y reducir las brechas del mismo debidas a la discontinuidad o falta de disponibilidad.
El proceso de gestin de la capacidad debera proporcionar los requisitos de desempeo como entrada al SLA para reducir las brechas
del mismo debido a un desempeo deficiente.
El proceso de gestin de proveedores debera proporcionar los detalles de los contratos con los proveedores. de modo que las metas
contractuales del proveedor se alineen con los SLA.
El proceso de GSI debera proporcionar la poltica de seguridad de la informacin de modo que los SLA se desarrollen para alinearse
con la poltica de seguridad.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar datos pertinentes sobre los incidentes.
El proceso de gestin del incidente y solicitudes de servicio debera recibir SLA, de modo que los incidentes y las solicitudes se
prioricen y resuelvan o cumplan de acuerdo con los plazos acordados para la respuesta y resolucin.
El proceso de gestin del cambio debera recibir solicitudes de cambio para SLA, e identificar interrupciones del servicio proyectadas
detallando las variaciones previstas de los SLA.
Ejemplos de integracin entre la GNS y el resto del SGS incluyen:
El proceso de GNS debera mantener la definicin de servicio acordada entre la alta gerencia, el cliente, usuarios y el gerente del
nivel de servicio.
El proceso de GNS debera definir las habilidades del proveedor del servicio los recursos necesarios para prestar el servicio.
El proceso de GNS debera interactuar con los proveedores de servicios que sustentan los grupos de resolucin del servicio, tales
como los de soporte de nivel 2, y el cumplimiento para el aprovisionamiento de la solicitud de servicio.

Tabla A.3 - Interfaces e integracin para los informes del servicio
Ejemplos de interfaces entre los informes del servicio y el resto del SGS incluyen:
El proceso de GNS debera proporcionar informacin correspondiente a los SLA para definir las reglas y polticas apropiadas con
respecto a los informes del servicio.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar datos pertinentes sobre los incidentes para los
informes del servicio, de modo que todas las partes interesadas puedan comprender el impacto y tomar las acciones acordadas.
El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar informacin sobre la disponibilidad del
servicio y sus componentes.
El proceso de gestin de la capacidad debera proporcionar informes sobre la carga de trabajo, incluso frente a los umbrales
predefinidos.
El proceso de GRN debera recibir el nivel correcto de informacin, para permitir la prestacin de niveles de servicio ptimos y
mejorar la satisfaccin del cliente.
Ejemplos de integracin entre los informes del servicio y el resto del SGS incluyen:
El proceso de informes del servicio debera proporcionar informes a las partes interesadas con respecto a la calidad, costos y riesgos
de los servicios, para permitir la toma de decisiones y tomar acciones relacionadas al servicio.
El proceso de informes del servicio debera recibir datos desde cada proceso de gestin del servicio para permitir la comunicacin y
visibilidad necesaria para gestionar y mejorar el SGS.
Tabla A.4 - Interfaces e integracin para la gestin de la continuidad y disponibilidad del servicio
Ejemplos de interfaces entre la gestin de la continuidad y disponibilidad del servicio y el resto del SGS incluyen:
El proceso de GNS debera proporcionar:
- las obligaciones de la continuidad y disponibilidad del servicio en los SLA;
- niveles del servicio que seran aceptables para el negocio en el evento de un desastre;
- asistencia para determinar la disponibilidad de metas y la investigacin y resolucin de brechas del servicio y sus componentes.
El proceso de gestin de la capacidad debera proporcionar:
- el plan de capacidad, para permitir la alineacin con el plan de disponibilidad;
- modelado de informacin, de modo que se cuente con recursos suficientes, por ejemplo, almacenamiento de datos para permitir
la recuperacin despus de un desastre y con el suministro de resiliencia y capacidad de reserva.
El proceso de GSI debera proporcionar la definicin sobre cundo un incidente de seguridad de la informacin se podra considerar
un desastre.
El proceso de gestin de la configuracin debera proporcionar informacin sobre los componentes que conforman la infraestructura,
para permitir todas las actividades del proceso de gestin de la continuidad y disponibilidad del servicio, como as tambin el
mantenimiento de los planes y las instalaciones de recuperacin.
El proceso de gestin del cambio debera proporcionar: informacin sobre todos los cambios con un impacto potencial sobre los
planes de continuidad y disponibilidad del servicio.
Los procesos de GNS deberan recibir opciones y requisitos de recuperacin, de modo que se puedan acordar y documentar en los
SLA.
Los procesos de gestin del problema y gestin del incidente y solicitudes de servicio deberan recibir criterios claros, acordados y
documentados para la invocacin de los planes de continuidad y disponibilidad del servicio.
Ejemplos de integracin entre la gestin de la continuidad y disponibilidad del servicio y el resto del SGS incluyen:
El proceso de gestin de la continuidad y disponibilidad del servicio debera recibir informacin sobre los planes de negocio de los
clientes y partes interesadas, para identificar requisitos nuevos o modificados para la continuidad y disponibilidad del servicio.
El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar el anlisis de impacto a la alta gerencia y a
todas las partes interesadas, para asegurar as que las decisiones de gestin del servicio se basen en una comprensin clara del
impacto para el negocio debido a la falta de disponibilidad.

Tabla A.5 - Interfaces e integracin para el presupuesto y contabilidad de los servicios
Ejemplos de interfaces entre el presupuesto y contabilidad de los servicios y el resto del SGS incluyen:
El proceso de diseo y transicin de servicios nuevos o modificados debera proporcionar planes de servicios nuevos o modificados
incluyendo presupuestos y escalas de tiempo.
El proceso de GNS debera proporcionar el catlogo de servicios como base para construir los modelos de costos de los servicios
prestados por el proveedor del servicio.
El proceso de gestin de la capacidad debera proporcionar un plan de capacidad, incluyendo opciones de costos para cumplir con los
requisitos del negocio.
El proceso de gestin de proveedores debera proporcionar detalles de los cambios en los costos, tanto a corto plazo como durante la
vida de un contrato.
El proceso de gestin de la configuracin debera proporcionar detalles de todos los temes de configuracin.
El proceso de gestin de la capacidad debera recibir el presupuesto de las actualizaciones del servicio e infraestructura o la compra
de componentes nuevos.
El proceso de gestin del cambio debera recibir aprobacin financiera, cuando sea necesario.
Ejemplos de integracin entre el presupuesto y contabilidad de los servicios y el resto del SGS incluyen:
El proceso de presupuesto y contabilidad de los servicios debera recibir suficiente informacin de la gestin financiera de la
organizacin del proveedor del servicio, para permitir un pronstico confiable y distribucin de los costos.
El proceso de presupuesto y contabilidad de los servicios debera proporcionar a la organizacin la poltica de presupuesto y
contabilidad de los servicios, para permitir la alineacin con la poltica de gestin financiera, como as tambin con los requisitos
reglamentarios.
Los recursos financieros se deberan presupuestar a un nivel de detalle adecuado para gestionar la implementacin, operacin y
mejoramientos del SGS, lo que necesitar la coordinacin del presupuesto y contabilidad de los procesos de servicio y gestin
financiera.
Tabla A.6 - Interfaces e integracin para la gestin de la capacidad
Ejemplos de interfaces entre la gestin de la capacidad y el resto del SGS incluyen:

El proceso de GNS debera proporcionar SLA y los niveles de servicio necesarios, adems de las metas de gestin de la capacidad.
Los servicios de presupuesto y contabilidad deberan proporcionar informacin sobre las ganancias de eficiencia en la prestacin de
servicios que den como resultado costos de capacidad ms bajos o una mejor utilizacin de los recursos de capacidad.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar informacin sobre los incidentes relacionados a la
capacidad y el desempeo.
El proceso de gestin de la configuracin debera proporcionar datos tcnicos, del servicio, de la utilizacin, financieros y del negocio
con respecto de los IC mantenidos en la CMDB.
El proceso de GNS debera recibir informes regularmente, para asegurar que las metas de desempeo y capacidad para que se puedan
lograr los requisitos nuevos o modificados. El desempeo es dependiente de una carga de trabajo dada; por lo tanto en un SLA con
metas de desempeo especficas se necesitan ambos. Del mismo modo, puede ser un requisito para el proceso de gestin de la
capacidad ayudar al proceso de GNS en la redaccin y revisin de los acuerdos de nivel operativo y contratos externos, donde los
asuntos de capacidad o desempeo estn involucrados.
El proceso de gestin de la continuidad y disponibilidad del servicio debera recibir modelados de datos, para determinar la capacidad
necesaria para todas las opciones de recuperacin utilizadas. La configuraciones mnimas de hardware y software necesarias se
definen para proporcionar el desempeo necesario y niveles de rendimiento despus de una invocacin.
El proceso de gestin del problema debera recibir experticia especializada, para ayudar a identificar, diagnosticar y resolver
problemas relacionados con la capacidad.
El proceso de gestin del cambio debera recibir informacin del proceso de gestin de la capacidad con respecto al efecto
acumulativo de los cambios en la capacidad. El proceso de gestin de la capacidad tambin se representa en la mesa de
recomendaciones de cambios, para evaluar el impacto de los cambios sobre la capacidad existente y para identificar cambios en los
requisitos de la capacidad.
El proceso de gestin de la entrega y despliegue debera recibir informacin para ayudar a determinar la poltica de distribucin para
las entregas, particularmente cuando se utiliza la red para la distribucin. Se deberan considerar como parte de la poltica de
distribucin de las entregas factores tales como el ancho de banda de la red, la capacidad del servidor central y del destinatario, la
ventana de distribucin y el nmero de destinatarios.
Ejemplos de integracin entre la gestin de la capacidad y el resto del SGS incluyen:
El proceso de gestin de la capacidad debera recibir los resultados de auditoras que identifiquen las no conformidades y
oportunidades de mejoramiento.
El proceso de gestin de la capacidad debera proporcionar los requisitos para la competencia, concientizacin y formacin para
asegurar que el proveedor del servicio tiene habilidades suficientes y niveles de habilidades para apoyar el proceso de gestin de la
capacidad.

Tabla A.7 - Interfaces e integracin para la GSI
Ejemplos de interfaces entre la GSI y el resto del SGS incluyen:

El proceso de presupuesto y contabilidad de los servicios debera proporcionar informacin sobre los costos asociados con los
controles de seguridad.
El proceso de gestin de la capacidad debera proporcionar el impacto de los controles de seguridad en la capacidad (los controles de
seguridad a menudo afectan al desempeo de los servicios).
El proceso de gestin de proveedores debera emitir informes que midan si los proveedores se adhieren a, y mantienen, la poltica de
seguridad de la informacin.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar detalles de todos los incidentes de seguridad de la
informacin, para cumplir los requisitos de la poltica de seguridad de la informacin y prevenir la repeticin.
El proceso de gestin del problema debera proporcionar la causa raz de los incidentes de seguridad de la informacin identificados
para la GSI.
El proceso de gestin de la configuracin debera proporcionar detalles de los temes de configuracin que estn en la CMDB
asociada con un riesgo de seguridad alto y proporcionar informacin en la CMDB que puede determinar el impacto de los problemas
de seguridad de la informacin y las resoluciones.
El proceso de gestin del cambio debera proporcionar detalles de las resoluciones de seguridad de la informacin y arreglos
temporales.
El proceso de GNS debera recibir requisitos de seguridad de la informacin a incluir en los SLA.
El proceso de gestin de la continuidad y disponibilidad del servicio debera recibir detalles de los incidentes de seguridad de la
informacin, problemas y resoluciones para asegurar la continuidad y disponibilidad de los servicios.
El proceso de GRN debera recibir alertas sobre amenazas a la seguridad de la informacin.
El proceso de gestin del incidente y solicitudes de servicio debera recibir orientaciones sobre cmo tratar incidentes de seguridad de
la informacin.
Ejemplos de integracin entre la GSI y el resto del SGS incluyen:
El proceso de GSI debera proporcionar la poltica de seguridad de la informacin para la gestin de la documentacin, para asegurar
que se protege y controla toda la informacin en concordancia con el valor del negocio, requisitos reglamentarios y niveles necesarios
de confidencialidad, integridad y disponibilidad.
El proceso de GSI debera proporcionar la poltica de seguridad de la informacin para la gestin del riesgo, para asegurar que los
riesgos de seguridad para los servicios se evalan y gestionan.
Tabla A.8 - Interfaces e integracin para la GRN
Ejemplos de interfaces entre la GRN y el resto del SGS incluyen:

El proceso de GNS debera proporcionar SLA o contratos, que incluyan el alcance del servicio.
El proceso de informes del servicio debera proporcionar informes del servicio que incluyan las necesidades identificadas y los
requisitos del cliente.
El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar detalles de los planes de continuidad del
servicio.
El proceso de GSI debera proporcionar alertas de amenazas que puedan afectar las relaciones con los clientes.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar detalles de los reclamos formales y las felicitaciones
por parte del cliente.
El proceso de gestin del cambio debera recibir las acciones de remediacin y mejoramiento que surjan de los reclamos del cliente y
las encuestas de satisfaccin del cliente.
Ejemplos de integracin entre la GRN y el resto del SGS incluyen:
El proceso de GRN debera proporcionar estos resultados para el cliente, lo que lleva a una mejor comunicacin y satisfaccin del
cliente.
Los reclamos del cliente y las encuestas de satisfaccin del cliente deberan proporcionar una entrada para las revisiones del SGS.

Tabla A.9 - Interfaces e integracin para la gestin de proveedores
Ejemplos de interfaces entre la gestin de proveedores y el resto del SGS incluyen:

El proceso de GNS debera proporcionar metas, requisitos y responsabilidades, asegurando su inclusin los acuerdos y contratos de
sustento, de modo que estas metas apoyen a los requisitos del servicio, incluyendo a aquellos especificados en los SLA.
El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar los requisitos de continuidad y
disponibilidad para los servicios que estn siendo suministrados por otras partes.
Los servicios de presupuesto y contabilidad deberan proporcionar los fondos adecuados para financiar los requisitos de gestin de
proveedores y de los contratos y para proporcionar recomendaciones y orientaciones sobre las compras y asuntos de contratacin.
El proceso de GSI debera proporcionar las polticas y procedimientos con respecto al acceso del proveedor a los servicios y sistemas,
y sus responsabilidades con respecto a la conformidad con las polticas y requisitos de la GSI.
Ejemplos de integracin entre la gestin de proveedores y el resto del SGS incluyen:
El proceso de gestin de proveedores debera recibir datos del desempeo del proveedor y medir ste frente a alternativas disponibles
para negociar una mejor relacin calidad-precio para apoyar los requisitos del cliente y el plan de negocios.
El proceso de gestin de proveedores debera proporcionar los requisitos para la competencia, concientizacin y formacin del
proveedor y para los resultados de la valoracin de la formacin del proveedor para asegurar que el proveedor est continuamente
alineado con los requisitos de capacidad del negocio.
Mediante el proceso de gestin del cambio se deberan gestionar los cambios al contrato, acuerdos documentados u otros documentos
acordados por las partes interesadas, incluyendo cambios a los compromisos del servicio.
El proceso de gestin del cambio debera asegurar, segn sea necesario, que los proveedores cumplan con las prcticas de la
organizacin para la gestin del cambio y que los proveedores sean incluidos durante la revisin, evaluacin y autorizacin de
cambios propuestos que afectarn a los proveedores de servicios prestados.
Tabla A.10 - Interfaces e integracin para la gestin del incidente y solicitudes de servicio
Ejemplos de interfaces entre la gestin del incidente y solicitudes de servicio y el resto del SGS incluyen:
El proceso de GNS debera proporcionar metas acordadas de incidentes y solicitudes de servicio.
El proceso de gestin del problema debera proporcionar registros de errores conocidos y detalles de arreglos temporales para
minimizar el impacto de los incidentes.
El proceso de gestin de la configuracin debera proporcionar informacin con respecto a los IC afectados por incidentes o
solicitudes de servicio para el proceso de gestin del incidente y solicitudes de servicio, para permitir evaluaciones de impacto ms
exactas.
El proceso de gestin de la continuidad y disponibilidad del servicio deberan recibir detalles de los incidentes e incidentes mayores
que tengan un impacto.
El proceso de gestin de la capacidad debera recibir los detalles de los incidentes e incidentes mayores que estn relacionados a la
escasez de capacidad.
El proceso de gestin del problema debera recibir detalles de los registros de incidentes y solicitudes de servicio, para el anlisis de
tendencias.
El proceso de gestin del cambio debera recibir informes sobre el impacto de los cambios que fracasan que han dado como resultado
nuevos incidentes.
Ejemplos de integracin entre la gestin del incidente y solicitudes de servicio y el resto del SGS incluyen:
El proceso de gestin del incidente y solicitudes de servicio requiere las competencias de personal especializado para distintos roles.
Estos requisitos de competencia para la gestin del servicio se deberan definir claramente. Cuando exista un dficit u otra deficiencia
en la persona que se ha considerado para el rol o que ya lo ejerce, el proveedor del servicio debera asegurar que se corrige este
dficit.
Los registros de incidentes y solicitudes de servicio se deberan revisar para identificar oportunidades de mejoramiento de procesos y
ahorro de costos.

Tabla A.11 - Interfaces e integracin para la gestin del problema
Ejemplos de interfaces entre la gestin del problema y el resto del SGS incluyen:
El proceso de GNS debera proporcionar SLA y acuerdos que incluyan metas acordadas para la gestin del problema.
El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar los detalles de los problemas que tengan un
alto impacto sobre la disponibilidad y continuidad del servicio.
El proceso de gestin de la capacidad debera proporcionar las tendencias de la capacidad.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar:
- detalles sobre los incidentes para los cuales existe una causa desconocida para la gestin del problema;
- datos del incidente para la gestin proactiva del incidente tal como el anlisis de tendencia.
El proceso de gestin de la configuracin debera proporcionar informacin con respecto a la relacin a las relaciones entre los IC que
pueden ayudar a determinar el impacto de los problemas y sus soluciones.
El proceso de gestin del incidente y solicitudes de servicio debera recibir:
- detalles de los errores conocidos de los servicios nuevos o modificados que se han introducido en el entorno real;
- registros y detalles de los errores conocidos de arreglos temporales a fin de minimizar el impacto de los incidentes.
El proceso de gestin del cambio debera recibir solicitudes de cambio para implementar soluciones permanentes para los errores
conocidos.
Ejemplos de integracin entre la gestin del problema y el resto del SGS incluyen:
El proceso de gestin del problema debera recibir informacin relacionada a los problemas con el SGS.
El proceso de gestin del problema debera identificar la causa raz de los problemas con el SGS y resolverlos a travs del proceso de
gestin del cambio.
La base de datos de errores conocidos se debera adherir a la poltica y procedimientos de la gestin de la documentacin.
Tabla A.12 - Interfaces e integracin para la gestin de la configuracin
Ejemplos de interfaces entre la gestin de la configuracin y el resto del SGS incluyen:

El proceso de gestin de la configuracin debera proporcionar informacin con respecto a las relaciones entre los IC que pueden
ayudar a analizar el impacto y la causa raz de los problemas.
La gestin de la configuracin debera proporcionar informacin con respecto a cules IC sern afectados por los cambios propuestos.
La gestin de la configuracin debera proporcionar informacin sobre los IC que soportan servicios listados en el catlogo de
servicios.
El proceso de diseo y transicin de servicios nuevos o modificados debera proporcionar detalles de todos los planes y diseos para
los servicios nuevos o modificados, tal que el impacto en los IC y servicios existentes lo puedan evaluar las partes interesadas.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar detalles de todos los incidentes y solicitudes de
servicio relacionadas a los IC.
El proceso de gestin del problema debera proporcionar un vnculo entre los errores conocidos y arreglos temporales y los temes de
configuracin afectados.
El proceso de gestin del cambio debera proporcionar detalles de los cambios en los IC, y la autorizacin para reflejar aquellos
cambios en la CMDB.
El proceso de gestin de la entrega y despliegue debera proporcionar las lneas de base para la configuracin de los temes de entrega
y el entorno de destino antes y despus de la entrega.
Todos los procesos deberan recibir informacin al da y exacta sobre todos los IC dentro del alcance del proceso.
El presupuesto y la contabilidad para los procesos de servicios debera recibir detalles de cualquier activo, incluyendo las licencias,
que se utilizan para prestar los servicios.
Ejemplos de integracin entre la gestin de la gestin de la configuracin y el resto del SGS incluyen:
La alta gerencia es responsable de asegurar que todos los activos, incluyendo las licencias, que se utilizan para prestar los servicios se
gestionan de acuerdo a los requisitos estatutarios y reglamentarios, y obligaciones contractuales. La gestin de la configuracin es
uno de los principales medios por los que se logra este requisito.
El proceso de gestin de la configuracin no incluye la contabilidad de activos financieros pero debera incluir la interface para el
proceso de contabilidad de activos financieros.

Tabla A.13 - Interfaces e integracin para la gestin del cambio
Ejemplos de interfaces entre la gestin del cambio y el resto del SGS incluyen:
El proceso de gestin de la continuidad y disponibilidad del servicio debera proporcionar:
- solicitudes de cambio, para actualizar los procedimientos y planes de continuidad del servicio, asegurando as que los
procedimientos y planes para la continuidad del servicio se mantengan exactos, al da y que las partes interesadas se mantengan
conscientes de los cambios;
- el impacto potencial de un cambio propuesto sobre la disponibilidad de un servicio o componente para la gestin del cambio.
El proceso de gestin de la capacidad debera proporcionar la evaluacin sobre los cambios propuestos, incluyendo no slo el impacto
del cambio particular, sino que tambin el impacto global de los cambios sobre la capacidad y recursos del servicio o componentes de
la capacidad.
El proceso de GSI debera proporcionar la evaluacin del impacto potencial de los cambios propuestos sobre la poltica de seguridad
de la informacin y los controles.
El proceso de gestin del incidente y solicitudes de servicio debera proporcionar informacin sobre los incidentes asociados con los
cambios implementados.
El proceso de gestin del problema debera proporcionar informacin sobre los problemas asociados con los cambios implementados.
El proceso de gestin de la configuracin debera proporcionar un acceso confiable, rpido y fcil a la informacin exacta de la
configuracin, para permitir a las partes interesadas y al personal evaluar el impacto de los cambios propuestos.
El proceso de gestin de la entrega y despliegue debera recibir informacin sobre los cambios aprobados que se implementarn a
travs de la gestin de la entrega.
Ejemplos de integracin entre la gestin del cambio y el resto del SGS incluyen:
Todos los cambios al SGS se debera canalizar a travs del proceso de gestin del cambio.
El proceso de gestin del cambio debera proporcionar detalles de todos los cambios en el SGS, catlogo de servicios, servicios,
polticas, objetivos y planes, requisitos del negocio, requisitos del servicio y los requisitos del proveedor.
El alcance del SGS tiene implicancias para el tiempo y costo de los mejoramientos y otros cambios, que tienen implicancias para el
proceso de gestin del cambio.
Tabla A.14 - Interfaces e integracin para la gestin de la entrega y despliegue
Ejemplos de interfaces entre la gestin de la entrega y despliegue y el resto del SGS incluyen:
El proceso de de gestin de la continuidad y disponibilidad del servicio debera proporcionar la evaluacin de los diseos tcnicos
para asegurar que los servicios continan cumpliendo las metas de disponibilidad, particularmente cuando la capacidad global puede
aumentar. Cada revisin y actualizacin del plan de gestin de la continuidad debera incluir cualquier nueva entrega significativa. La
calendarizacin de las revisiones y pruebas adecuadas de la continuidad se deberan llevar a cabo antes del despliegue de la entrega.
El proceso de gestin de la capacidad debera proporcionar informacin y apoyar con respecto a la compra e instalacin de capacidad
adicional para apoyar la entrega. Esto puede incluir la reserva de capacidad para entornos de desarrollo y prueba.
El proceso de GSI debera proporcionar un plan de seguridad actualizado en lnea con la adopcin de nuevas polticas, prcticas y
herramientas que resultan de la entrega
El proceso de gestin de proveedores debera proporcionar los contratos y acuerdos necesarios que estn en marcha o se han
actualizado antes de la adquisicin y soporte de los componentes tcnicos dentro de una entrega. Esto sirve para la entrega que est en
produccin.
El proceso de gestin del cambio debera proporcionar la solicitud de cambio aprobada para la gestin de la entrega y despliegue.
El proceso de GNS debera recibir actualizaciones con respecto a los cambios al servicio o a la documentacin del nivel de servicio y
contactos clave.
El proceso de gestin del problema debera recibir notificaciones y registros de los defectos y correspondientes arreglos temporales
que sern promovidos al entorno real con la entrega.
El proceso de gestin de la configuracin debera recibir informacin que refleje los cambios para el entorno real despus de la
entrega. Esta informacin asegurar la exactitud de la CMDB. La informacin adicional de la entrega pertinente para la CMDB
incluir actualizaciones para los IC modificados o dados de baja y nuevos servicios que sustituyen a los servicios existentes.
Ejemplos de integracin entre la gestin de la entrega y despliegue y el resto del SGS incluyen:
El proceso de gestin de la entrega y despliegue debera tomar en cuenta la formacin, el reclutamiento o soporte inicial necesario
como parte de la entrega.
La alta gerencia debera asegurar la calidad y habilidades de los recursos de personal adquiridos o utilizados por el proveedor del
servicio son suficientes para crear, probar y desplegar la entrega, como as tambin para apoyar y operar la nueva entrega una vez en
produccin.

Anexo B
(informativo)
Bibliografa
[1] ISO/IEC TR 20000-3 Information technology - Service management - Part 3: Guidance on scope
definition and applicability of ISO/IEC 20000-1.
[2] ISO/IEC TR 20000-4 Information technology - Service management - Part 4: Process reference
model.
[3] ISO/IEC TR 20000-5 Information technology - Service management - Part 5: Exemplar
implementation plan for ISO/IEC 20000-1.
[4] ISO 9000 Quality management systems - Fundamentals and vocabulary.
[5] ISO 9001 Quality management systems Requirements.
[6] ISO 9004 Managing for the sustained success of an organization - A quality
management approach.
[7] ISO/IEC TR 9126-2 Software engineering - Product quality - Part 2: External metrics.
[8] ISO/IEC TR 9126-3 Software engineering - Product quality - Part 3: Internal metrics.
[9] ISO 10002 Quality management - Customer satisfaction - Guidelines for complaints
handling in organizations.
[10] ISO 10007 Quality management systems - Guidelines for configuration management.
[11] ISO/IEC 12207 Systems and software engineering - Software life cycle processes.
[12] ISO/IEC 14598 (all Software engineering - Product evaluation.
parts)
[13] ISO/IEC 15228 Systems and software engineering - System life cycle processes.
[14] ISO/IEC 15504-1 Information technology - Process assessment - Part 1: Concepts and
vocabulary.
[15] ISO/IEC 15504-2 Information technology - Process assessment - Part 2: Performing an
assessment.
[16] ISO/IEC 15504-3 Information technology - Process assessment - Part 3: Guidance on
performing an assessment.
[17] ISO/IEC 15504-4 Information technology - Process assessment - Part 4: Guidance on use for
process improvement and process capability determination.
[18] ISO/IEC 15504-5 Information technology - Process assessment - Part 5: An exemplar Process
Assessment Model.
[19] ISO/IEC 15939 Systems and software engineering - Measurement process.
[20] ISO 19011 Guidelines for quality and/or environmental management systems auditing.
[21] ISO/IEC 19770-1 Information technology - Software asset management - Processes.
[22] ISO/IEC TR 24748-2 Systems and software engineering - Life cycle management - Part 2: Guide to
the application of ISO/IEC 15288 (System life cycle processes).
[23] ISO/IEC TR 24748-3 Systems and software engineering - Life cycle management - Part 3: Guide to
the application of ISO/IEC 12207 (Software life cycle processes).
[24] ISO/IEC 27001 Information technology - Security techniques - Information security
management systems Requirements.
[25] ISO/IEC 27002 Information technology - Security techniques - Code of practice for
information security management.
[26] ISO/IEC 27005 Information technology - Security techniques - Information security risk
management.
[27] ISO 31000 Risk management - Principles and guidelines.
[28] ISO/IEC 38500 Corporate governance of information technology.
[29] ISO/IEC 90003 Software engineering - Guidelines for the application of ISO 9001:2000 to
computer software.

NOTA EXPLICATIVA NACIONAL
La equivalencia de las Normas Internacionales sealadas anteriormente con Norma Chilena, y su grado de
correspondencia es el siguiente:
Norma Internacional Norma nacional Grado de correspondencia

ISO/IEC TR 20000-3 No hay. -
La norma chilena NCh-ISO 9000.Of2010 es
ISO 9000 NCh-ISO 9000.Of2010 una adopcin idntica de la norma
ISO 9000:2005.
ISO 9001 NCh-ISO 9001.Of2009 una adopcin idntica de la norma ISO
9001:2008.
ISO 9004:2009.
ISO 10002:2004.
ISO 10007 No hay. -
ISO/IEC 12207 No hay. -
ISO/IEC 14598 (all parts) No hay. -
ISO/IEC 15504-1 No hay. -
ISO 19011 NCh-ISO 19011:2012 -
ISO/IEC 27001 NCh-ISO 27001.Of2009 una adopcin idntica de la norma
ISO/IEC 27001:2005.
ISO/IEC 27002:2005.
ISO/IEC 27005:2005.
ISO 31000 En estudio. -

Anexo C
(informativo)
Justificacin de los cambios editoriales
Tabla C.1 - Cambios editoriales
Clusula/subclusula Cambios editoriales Justificacin

En toda la norma Se reemplaza esta "esta parte de ISO/IEC La norma es de alcance nacional.
20000" por "esta norma".
1 Se reemplaza "Alcance" por "Alcance y campo De acuerdo a estructura de NCh2.
de aplicacin".
4.4.2.1 Se incluy la nota 1) al pie de pgina. Explicar el significado de la sigla RACI.
Anexo B Se reemplaza "Bibliografa" por "Anexo B De acuerdo a estructura de NCh2.
(Informativo) Bibliografa".

Iso 20000-2 - Norma Chilena 2012 (Con Notas)

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Iso 20000-2 - Norma Chilena 2012 (Con Notas)

Hochgeladen von

Copyright:

Verfügbare Formate

PROYECTO DE NORMA EN CONSULTA PUBLICA - prNCh-ISO 20000/2

La Nota Explicativa incluida en un recuadro en clusula 2 Referencias normativas y Anexo B, Bibliografa, es

Vencimiento consulta pblica: 2013.01.25 I

- ISO/IEC 20000-1 es aplicable a proveedores de servicios internos y externos, grandes y pequeos, y

- ISO/IEC 20000-1 fomenta la adopcin de un enfoque de procesos integrados cuando se planifica,

Vencimiento consulta pblica: 2013.01.25 1

ISO/IEC 20000 fomenta la aplicacin de la metodologa conocida como Planificar-Hacer-Verificar-Actuar

b) establecer la poltica y objetivos para la gestin del servicio;

d) monitorear, medir y revisar el desempeo del SGS y de los servicios;

Figura 1 - Metodologa PHVA aplicada a la gestin del servicio

Vencimiento consulta pblica: 2013.01.25 2

Como se indica en ISO/IEC 20000-1:

ISO/IEC 20000 puede ser utilizada por:

1 Alcance y campo de aplicacin

Vencimiento consulta pblica: 2013.01.25 3

Figura 2 - Sistema de gestin del servicio

NOTA EXPLICATIVA NACIONAL

Norma Internacional Norma nacional Grado de correspondencia

ISO/IEC 20000-1 En estudio -

4 Requisitos generales del sistema de gestin del servicio

4.1 Responsabilidad de la gerencia

4.1.1 Compromiso de la gerencia

4.1.1.1 Responsabilidades de la alta gerencia

b) demostrar su rendicin de cuentas y responsabilidades por el SGS;

f) asegurar que el desempeo del SGS se informa a nivel de la alta gerencia;

Vencimiento consulta pblica: 2013.01.25 5

4.1.1.2 Evidencia del compromiso de la alta gerencia

4.1.1.3 Comunicaciones de la alta gerencia

La alta gerencia debera estar activamente involucrada en un programa continuo de comunicaciones. La

El programa de comunicaciones debera explicar lo siguiente:

i) acuerdos documentados con el cliente;

4.1.1.4 Objetivos de gestin del servicio

b) reducir la no disponibilidad imprevista para los servicios crticos del negocio;

c) optimizar el costo de los servicios prestados a travs de eficiencia operativa;

Vencimiento consulta pblica: 2013.01.25 7

d) aumentar la calidad de los servicios mientras se reduce el riesgo.

4.1.1.5 Plan de gestin del servicio

Los contenidos del plan de gestin del servicio debera incluir:

b) una descripcin de las funciones organizacionales del proveedor del servicio;

d) resultados esperados alineados a objetivos del negocio;

e) medidas del desempeo;

f) metas del servicio;

g) planes del proyecto;

i) obtencin de beneficios logrados como resultado de mejoramientos implementados con anterioridad;

j) riesgos y opciones de mitigacin de riesgo.

4.1.1.6 Recursos para apoyar el plan de gestin del servicio

c) herramientas para apoyar los procesos del SGS;

4.1.1.7 Contenidos de los requisitos del servicio

Vencimiento consulta pblica: 2013.01.25 9

Ejemplos de requisitos del servicio pueden incluir:

a) un servicio en uso, incluyendo los requisitos del nivel de servicio;

b) criterios de calidad para el diseo de servicios nuevos o modificados;

c) prioridades de la criticidad del negocio de servicios;

f) requisitos de seguridad de la informacin.

b) las limitaciones que el servicio eliminar;

d) patrones de la actividad del negocio y demanda que el servicio debera soportar;

EJEMPLO 2 Funcionalidad. Un mejoramiento deseado en el tiempo de procesamiento de las transacciones del

4.1.1.9 Necesidades del proveedor del servicio

4.1.1.10 Requisitos conflictivos

4.1.1.11 Riesgos para el servicio

Vencimiento consulta pblica: 2013.01.25 11

a) se desarrollan y documentan opciones para gestionar los riesgos identificados;

b) las opciones preferidas son acordadas con el cliente;

c) las opciones para la mitigacin de riesgos se implementan cuando es necesario.