Documentos de Académico
Documentos de Profesional
Documentos de Cultura
ISO20000 GuiaCompletadeAplicacion LuisMoran PDF
ISO20000 GuiaCompletadeAplicacion LuisMoran PDF
© Crown copyright 2007 All rights reserved. Material is reproduced with the permission of the Office of
Government Commerce under delegated authority from the Controller of HMSO.
Licensed Product
ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
The Swirl logo™ is a Trade Mark of the Office of Government Commerce.
The OGC logo® is Registered Trade Mark of the Office of Government Commerce in the United Kingdom.
PRINCE® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
IT Infrastructure Library® is Registered Trade Mark of the Office of Government Commerce in the United
Kingdom and other countries.
M_o_R® is Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
ISBN: 978-84-8143-662-4
Depósito Legal: M-47292-2009
Impreso en España - Printed in Spain
Edita: AENOR
Maqueta y diseño de cubierta: AENOR
Imprime: Xxxxxx
Nota: AENOR no se hace responsable de las opiniones expresadas por los autores en esta obra.
Génova, 6. 28004 Madrid • Tel.: 902 102 201 • Fax: 913 103 695
comercial@aenor.es • www.aenor.es
Este libro está dedicado a todos los
profesionales de tecnologías de la
información y las comunicaciones que
abnegadamente han aportado sus
conocimientos y experiencia para la definición
y difusión de las normas y las mejores
prácticas que marcan el camino
de evolución de este sector.
Agradecimientos
Este libro recopila las experiencias de profesionales que están fuertemente involu-
crados en el impulso de las normas y las buenas prácticas internacionales relativas a
la gestión de las tecnologías de la información y las comunicaciones.
En la creación de esta primera edición del libro han participado:
• Dirección de la obra (Telefónica):
Luis Morán Abad – Dirección técnica y contenido final.
Alejandro Pérez Sánchez – Contenido intermedio.
• Colaboradores:
Paloma García López (AENOR)
Carlos Manuel Fernández Sánchez (AENOR)
Eduardo Méndez Polo (Telefónica)
Jaime Pastor Pastor (Telefónica)
8 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Las tecnologías de la información son cada día más necesarias en la gestión de las
empresas.
Este sector, en su evolución hacia la madurez, ha ido generando diversos conjuntos
de mejores prácticas que ayudan a las organizaciones a gestionar estos entornos tec-
nológicos cada vez más complicados y, por otra parte, más esenciales.
Este libro nace con la intención de ayudar a todo tipo de empresas en la gestión
de la actividad de sus departamentos informáticos. Profesionales de Telefónica y de
AENOR han puesto su mejor empeño en explicar y aportar sus años de experien-
cia en este ámbito. Para ello, se ha utilizado como eje vertebrador las Normas
UNE-ISO/IEC 20000, que se enriquecen con las buenas prácticas de otros marcos
como ITIL®.
Los autores han desarrollado una buena guía sobre la forma de incorporar estas
mejores prácticas de la industria en la gestión diaria de las tecnologías. Esta publi-
cación ayudará a las empresas a adoptar los últimos avances en la forma de organizar
las actividades que contribuyen a que el mundo tecnológico sea operativo y rentable
para las organizaciones y para la sociedad.
Esperamos que todo su contenido sea de gran utilidad en la mejora de los servicios
de tecnologías de la información prestados en su organización.
Telefónica
Introducción
Durante la década de los años 50, algunas predicciones futuristas imaginaron que,
para el año 2000, los coches serían capaces de volar, se iría de vacaciones a Marte, y
que Estados Unidos podría llegar a contar con “nada menos” que trescientos mil
ordenadores. En 1947 el director de una famosa multinacional del sector predijo
que en el mundo sólo habría mercado para 5 ordenadores. Estas predicciones hoy
en día nos parecen ridículas, unas por lo exageradas, y otras por que se han que-
dado muy cortas.
Las tecnologías de la información y las comunicaciones han avanzado mucho más
de lo esperado, pero después de poblar el mundo de dispositivos de silicio, con
unas capacidades de proceso inimaginables, nos encontramos con un panorama
desalentador:
• Equipos que se bloquean.
• Sistemas que se “caen”.
• Servicios que se interrumpen.
• Atención al usuario deficiente.
• Pérdidas de tiempo y de productividad de los usuarios.
• Personal técnico desbordado por llamadas y peticiones de asistencia.
• Directores de sistemas de información que ven cómo, a pesar del esfuerzo con-
tinuo de su equipo, el roce y el malestar con el resto de la empresa no cesan.
1 Para facilitar la lectura, en el resto del libro se ha optado por utilizar el mismo término
“ISO/IEC 20000” para referirse a estas normas, tanto para la serie UNE, como para la serie
ISO/IEC.
Introducción 17
Índice de las Normas ISO/IEC 20000 Índice del libro ISO 20000
7 Procesos de relaciones
7.1 Generalidades
7.2 Gestión de las relaciones con el negocio
7.3 Gestión de suministradores
8 Procesos de resolución
8.1 Antecedentes
8.2 Gestión del incidente
8.3 Gestión del problema
9 Procesos de control
9.1 Gestión de la configuración
9.2 Gestión del cambio
10 Proceso de entrega
10.1 Proceso de gestión de la entrega
13 Términos y definiciones
1.1. Las Normas ISO/IEC 20000 son parte del camino a la excelencia
1.2. Normas, estándares, marcos de referencia y metodologías reconocidas
en el ámbito de las TI
1.3. Entender los entornos de normalización y certificación
1.4. Las principales normas y buenas prácticas en TI
0
50
38
BIT
MI CO
CM
0 1
ITIL 2 70
0 00 000
9 20
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Ámbito de la empresa
p Ámbito específico
p de TI
Calidad
Gestión del Funciones de TI
y medio Empresa Gobierno TI Tecnología
servicio de TI ((desarrollo,, seg.,
g , etc.))
ambiente
Ticket SPICE
Evaluación
SAS
ISO/IEC 15504
8000
TQM PPeople
l ISO/IEC
King CMMI for
CMMI 17799 o
COBIT Services
ACC 27002 FEAF
CMMI ISO
ITIL v3
ISO ISO/IEC
CoCo ASL 90003
Tipo de usso
SO 27001
Directrice
DSDM 12207
EFQM 9004 COSO ISO/IEC
ISO ISO/IEC ISPL BS 25999
eTOM 20000 Zachman
14001 (Telcos) 38500 PAS 77
MOF
SAS 70 PMBOK
Lean
CORBA
Prrescriptivo
6 RUP PRINCE2
Sigma XML
TL 9000 SOX
SOA
El veterano marco ITIL destaca como el gran compendio de referencia, que aspira
a convertirse en ese modelo universal que estructura y organiza toda la actividad de
las TI. Si bien la versión 2, publicada en el año 2000, ha tenido una aceptación
excepcional, hay que esperar a ver cómo el sector va adoptando la nueva versión 3,
publicada en el año 2007, y que presenta una visión más amplia y coherente de la
gestión de las TI, agrupada en torno al ciclo de vida del servicio.
El marco para el desarrollo de software CMMI (Capability Maturity Model Integra-
tion) aparece como el modelo más aceptado para la medición de la madurez de los
procesos de gestión en la construcción de aplicaciones. Para complicar más el pano-
rama, en su última versión se crea un nuevo modelo CMMI for Services, que se
superpone en gran medida con el ámbito central de ITIL; y por tanto, también con
las Normas ISO/IEC 20000. Además, para los procesos y medición de la madurez
del desarrollo, también la normativa internacional inició desde 1993 su andadura.
ISO e IEC han desarrollado un modelo para la evaluación de los procesos de desa-
rrollo de software bajo la iniciativa SPICE que ha desembocado en la publicación
de la serie ISO/IEC 15504. En paralelo, han ido evolucionando otro conjunto de
normas relativas a la ingeniería del software (ISO/IEC 15288, ISO/IEC 12207,
ISO/IEC 25001, ISO/IEC 25030, ISO/IEC 16085, etc.).
26 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Por otra parte, los temas medioambientales también tienen su impacto en la ges-
tión de TI. Deben tenerse en cuenta: la legislación nacional, local y la normativa
sobre retirada y gestión del equipamiento y residuos informáticos; la serie de Nor-
mas ISO-EN 14000 relativa a la gestión medioambiental; en España existe tam-
bién la Norma UNE 150002 Sistemas de gestión medioambiental. Guía para la apli-
cación de la norma UNE-EN ISO 14001:1996 en las empresas de servicios y la guía para
la aplicación de los sistemas de gestión medioambiental a las relaciones con sumi-
nistradores y clientes, denominada UNE 150004 EX; o el Código de Conducta
para la Eficiencia Energética en Centros de Datos publicado por la Unión Europea.
Tanta abundancia de información y recomendaciones resulta confusa para las orga-
nizaciones que sólo desean soluciones prácticas y directas para mejorar su gestión
de las TI.
De todo el mapa anterior, se recomienda centrarse inicialmente en las normas y
marcos de mayor relevancia y más aceptados para la mejora de TI, como son:
• ISO/IEC 20000 partes 1 y 2, e ITIL (en sus versiones 2 y 3) para mejorar la
gestión de los servicios de TI.
• COBIT para la auditoría y la medición de las TI.
• ISO/IEC 27001 para la gestión de la seguridad de la información.
• ISO/IEC 15504 y CMMI for Development para la gestión del desarrollo de
software.
• ISO/IEC 38500 y COBIT como referencias para el gobierno de las
tecnologías de la información.
Normalización y acreditación
Normalización internacional Principales iniciativas privadas
según el país
• España: AENOR - ENAC
ISO CEN OGC Carnegie ITGI PMI
• UK: BSI - UKAS
e
IEC CENELEC
Organismos
• Perú: INDECOPI
• Australia: SA
Participan comités Participa industria local Participan los líderes y gurús de la industria TI
normalización países itSMF España y GT-25
(en UNE-ISO
UNE ISO 20000) itSMF SEI y ESI
ISO/IEC ISO/IEC
ISO 9001 ISO 27001 ITIL CMMI COBIT PMBOK
20000 20000
ormas
Fuente: Telefónica
Por otra parte, el ámbito de las denominadas iniciativas privadas (ITIL, CMMI,
COBIT, etc.) se centra principalmente en el desarrollo de marcos de mejores prác-
ticas y no de normativa. Los procedimientos y la gestión de la representación del
sector quedan a la libre elección de la institución u organismo que impulsa la ini-
ciativa (OGC, Carnellie Mellon, ITG, etc.). Con frecuencia se basa en una llamada
pública de participación para trabajar en la siguiente edición de estos marcos a la
que suelen responder los principales actores internacionales y gurús en la materia.
El proceso de selección del equipo de revisión es específico de cada institución, así
como el procedimiento de edición de la nueva versión del marco de referencia.
Como se puede intuir hay que ser un autentico especialista en la materia para com-
prender los diversos esquemas y estructuras que se han ido creando alrededor de la
normalización y marcos de mejores prácticas. Por la vinculación con la temática de
este libro se explican los procesos de creación de las normas ISO/IEC y de las nor-
mas UNE españolas:
Ciclo de creación de las normas ISO/IEC. Una norma internacional se desarro-
lla en el ámbito de los comités técnicos y de los subcomités técnicos de ISO y de
IEC. El proceso sigue seis etapas: propuesta, preparatoria, comité, consulta, apro-
bación y publicación. En este proceso, el documento propuesta de norma pasa por
tres estados que indican el grado de aceptación y apoyo que se va alcanzando de los
diversos borradores:
• CD (Committee Draft): es un borrador generado por un grupo de trabajo,
que ha recibido la aprobación del grupo y se remite al comité correspon-
diente para su aprobación.
• DIS (Draft of International Standard): es el borrador de norma internacio-
nal que el comité de normalización ha aprobado y somete a comentarios y
votación por parte de los países.
• FDIS (Final Draft of International Standard): es el borrador final de la
norma internacional, que el comité envía para su aprobación final a todos los
miembros para su publicación final como norma internacional.
aceptar que la nueva norma se cree por el procedimiento de fast-track, para pasar
directamente como DIS a la etapa 4. Normalmente el procedimiento rápido puede
durar un año, mientras que el normal suele durar entre 2 y 3 años, dependiendo de
la dificultad de alcanzar el consenso en las diversas etapas.
Ciclo de creación de las normas UNE españolas. El proceso de elaboración de
una norma UNE está sometido a una serie de fases que permiten asegurar que el
documento final es fruto del consenso, y que cualquier persona, aunque no perte-
nezca al comité de AENOR, productor de la norma, pueda emitir sus opiniones o
comentarios. Tras la aprobación del proyecto final de norma por un Comité Téc-
nico de Normalización, el Boletín Oficial del Estado (BOE) publica la relación
mensual de proyectos UNE sometidos a un período de Información Pública,
durante el cual cualquier persona o entidad interesada podrá presentar observacio-
nes. Las observaciones deben realizarse a AENOR. Una vez analizados los comen-
tarios recibidos en esta fase, el comité redactará el texto final, que será aprobado y
publicado como norma UNE por AENOR.
En la figura 1.3 se representan las etapas de estos dos ciclos, internacional y nacional.
Los gobiernos
Es importante destacar el papel activo de los gobiernos, instituciones gubernamen-
tales y administraciones públicas en el campo de la normalización, pues desempe-
ñan un triple papel: como sustento de la actividad de normalización mediante sub-
venciones a los organismos de normalización, como impulsores de algunas
iniciativas destacadas, y en su papel de exigir el cumplimiento de la normativa, bien
estableciendo una regulación o bien en su papel de cliente contratante de servicios
al sector de las TIC.
Entre estos organismos destacan el Ministerio de Comercio Británico (OGC, Office
of Government Commerce) en su papel de creador, impulsor y propietario de ITIL y
el Departamento de Defensa de Estados Unidos (DoD, Departament of Defense)
como impulsor de CMMI.
Organismos de acreditación
Las entidades nacionales de acreditación son entidades independientes cuya fun-
ción es la acreditación de entidades certificadoras y laboratorios de ensayo. Es decir,
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Normalmente, los certificados locales emitidos por las entidades certificadoras van
acompañados de el reconocimiento internacional de IQNet.
Entidades certificadoras
Para que las empresas puedan demostrar a nivel nacional e internacional que cum-
plen las normas, necesitan un certificado. Se trata de un instrumento para verificar
la correcta implantación de las normas.
La obtención del certificado se realiza mediante un proceso de evaluación indepen-
diente por parte de una entidad certificadora o de certificación. Un requisito
importante que asegura la solvencia para que una entidad pueda conceder una
marca de certificación es que dicha entidad sea “competente para certificar” los
productos, los servicios, los sistemas de gestión o las personas, a los que se aplica la
marca de certificación.
Los organismos de acreditación son los encargados de acreditar a las entidades de
certificación. Las entidades de certificación utilizan los servicios profesionales
de los auditores.
34 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Marcas de certificación
Las marcas de certificación las conceden las entidades correspondientes a los pro-
ductos, sistemas y servicios que cumplen con los requisitos definidos.
La certificación, en base a normas, tiene su reflejo en los distintivos de certifica-
ción, cuya concesión significa que el producto o servicio ha pasado por el adecuado
proceso de certificación de forma satisfactoria. Cuando, por ejemplo, se trata de
una marca de seguridad, la concesión de la marca significará que cumple los requi-
sitos de seguridad, según la norma de referencia.
En un producto con certificado de calidad, la etiqueta puede contener distintos
logotipos (véase la figura 1.4) dependiendo de la entidad que otorgue el certificado.
Auditores
Los auditores son los únicos profesionales acreditados para realizar la auditoría del
cumplimiento de los requisitos de una norma por una organización. La calificación
de auditor se concede únicamente a los candidatos que demuestren experiencia
suficiente y hayan pasado los exámenes exigidos para ello.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Consultores
Los consultores asesoran, bien a las organizaciones o entidades que quieren
implantar las normas, o bien, una vez implantadas, que desean certificarse. Para
esta función existe una acreditación profesional específica. La formación que reci-
ben les permite adquirir un nivel suficiente de conocimiento de la normas, del
esquema de certificación y de su aplicación.
Los consultores asisten a las organizaciones en la interpretación y aplicación de la
normas, así como, para la aplicación efectiva de ISO/IEC 20000 en la gestión del
servicio. Asimismo, el consultor externo puede efectuar una evaluación de los nive-
les de gestión del servicio y establecer el nivel de preparación necesario para una
solicitud de certificación y su posterior consecución.
Actualmente, existe una acreditación de consultor ISO/IEC 20000 otorgada por enti-
dades de formación acreditadas por UKAS e itSMF-UK. Otros organismos que regu-
lan la formación profesional (EXIN, APMG) también están entrando en este campo.
ITIL v0:
Service Level
Management
ITIL v2 se ha utilizado como base para la creación de las Normas ISO/IEC 20000.
En la figura 1.7, se muestra una representación típica de ITIL v2. En ella se puede
apreciar el negocio a la izquierda del todo, en el extremo derecho se sitúa la tecno-
logía, y, en medio, haciendo que la tecnología sea útil para el negocio están los pro-
cesos ITIL. De ellos, los dos libros más valiosos por su contenido y más aceptados
por el mercado son los relativos a la gestión de servicio (libros Soporte de Servicio y
Provisión de Servicio publicados por OGC).
Diseño
del servicio
Estrategia
del servicio
del servicio
Operación
ITIL v3
ón
s ici icio
an rv
Tr l se
de
Mejora
del servicio
Fuente: Libro ITIL Estrategia del Servicio publicado por OGC y e.p.
MEJORA
ESTRATEGIA DISEÑO TRANSICIÓN OPERACIÓN
CONTINUA
os
iesg
inis
Fuente: ISACA.
ISO/IEC 17799 (que pasará a ser denominada ISO/IEC 27002) recoge un código
de buenas prácticas para la gestión de la seguridad de la información. Se centra en
desarrollar los objetivos de control de la seguridad, y para cada uno de ellos, se
indica una guía para su implantación. Cada organización debe considerar cuántos
serán realmente los aplicables según sus propias necesidades.
CMMI
for Services
CMMI
Foundation
16 áreas
de proceso
CMMI for CMMI for
comunes
Development Acquisition
para el desarrollo de aplicaciones (CMMI for Development), otra para las adquisi-
ciones (CMMI for Adquisition) y una nueva para la prestación de servicios (CMMI
for Services).
CMMI describe cinco etapas evolutivas (niveles) en las cuales una organización se
sitúa según la madurez de sus procesos:
1. Inicial (Initial). Los procesos son caóticos; pocos procesos están realmente
definidos.
2. Repetible (Repeatable). Se establecen los procesos básicos y se observa cierto
nivel de disciplina respecto a ellos.
3. Definido (Defined). Todos los procesos están definidos, documentados, nor-
malizados e integrados.
4. Gestionado (Managed). Los procesos se miden recogiendo datos detallados
de los mismos.
5. En optimización (Optimizing). La mejora de los procesos es continua y pro-
porciona nuevas ideas y oportunidades.
Con la publicación en Marzo del 2009 de CMMI for Services, el SEI también entra
en el ámbito de la gestión del servicio, con bastante solape con ITIL e ISO/IEC
20000. En la figura 1.13 se muestran los procesos de este nuevo modelo.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Fuente: SEI.
Procesos cliente-proveedor
Procesos de ingeniería
Procesos
Procesos de proyecto
de soporte
Procesos de organización
Fuente: SPICE.
Las Normas UNE-ISO/IEC 20000 son las traducciones al castellano de las ante-
riores ISO/IEC, están formadas por dos partes publicadas como documentos inde-
pendientes:
• UNE-ISO/IEC 20000-1:2007 Tecnología de la información. Gestión del
servicio. Parte 1: Especificaciones. Contiene los requisitos exigibles para cum-
plir con la norma. Por ello, el verbo de sus frases suele contener un “debe”,
indicando que el requisito tiene que ser satisfecho para ser acorde con la
norma.
• UNE-ISO/IEC 20000-2:2007 Tecnología de la información. Gestión del
servicio. Parte 2: Código de buenas prácticas. Esta parte contiene a veces una
extensión o detalle de los requisitos de la parte 1, mientras que en otras oca-
siones se desarrollan los requisitos con más profundidad. La parte 2, utiliza
el condicional “debería”, que se interpreta como una recomendación para
satisfacer el requisito de la parte 1, pero quizás no la única.
Dada la equivalencia entre estas normas ISO/IEC (en inglés) y las normas UNE
(en castellano), a partir de ahora en el libro se utilizará únicamente el término
ISO/IEC 20000 para ambas normas.
En la figura 2.1 se muestran los objetivos de cada una de las partes de estas normas
frente al alcance más amplio del presente libro.
Figura 2.1. Las dos partes de las Normas ISO/IEC 20000 y su reflejo en
el presente libro
Fuente: Telefónica.
Si realizásemos un esquema que reflejara toda la actividad llevada a cabo en TI, las
funciones y los recursos tecnológicos, tendríamos:
• Para coronar el esquema, en la parte más alta, se definirían las actividades de
gobierno de TI: estrategia, alineación con el negocio, etc.
• Por debajo de ellas estarían los procesos de gestión del servicio de TI.
• En el siguiente nivel se situarían los equipos que constituyen las fuerzas de
trabajo de TI: con la operación, funciones técnicas, el desarrollo de software,
y el resto de especialidades y conocimientos tecnológicos
• A continuación, aparecería la capa de herramientas: de soporte a la gestión,
de administración técnica, de monitorización, etc., es decir, las herramientas
que hacen que la actividad sea más fluida y controlada.
• Por último la capa en la base del esquema, que alojaría la tecnología: siste-
mas, aplicaciones e infraestructura de TI (tecnología suministrada por los
fabricantes, comunicaciones, edificios para alojarlos, etc.)
En este esquema las normas se posicionarían sobre el área de la gestión del servicio,
debido a su carácter organizacional y de gestión. En la figura 2.3 se muestra el
esquema con todo su detalle.
58 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Fuente: Telefónica.
• El servicio
• La orientación al cliente
ISO/IEC 20000
• La comunicación interna
• Los procesos internos
Tarea 1
Tarea 2
Control Mecanismos
(actividades de evaluación)
Indicadores Recursos
y KPI
Roles
Propietario Objetivos
Herramientas
del proceso del proceso
Según indica la Norma UNE-EN ISO 9001, una ventaja del enfoque basado en
procesos es el control continuo que proporciona sobre los vínculos entre los proce-
sos individuales dentro del sistema de procesos, así como sobre su combinación e
interacción. Un enfoque de este tipo, cuando se utiliza dentro de un sistema de ges-
tión de la calidad, enfatiza la importancia de:
a) La comprensión y el cumplimiento de los requisitos.
b) La necesidad de considerar los procesos en términos que aporten valor.
c) La obtención de resultados del desempeño y eficacia del proceso.
d) La mejora continua de los procesos con base en mediciones objetivas.
Las Normas ISO/IEC 20000 definen una capa de procesos de TI que aglutina las
principales actividades para que los servicios se provean y presten según las exigencias
62 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
del negocio. Esta capa de procesos se utiliza por la organización tradicional de TI,
garantizado que estas actividades esenciales se ejecuten de la forma definida. Para
facilitar el trabajo es necesario implantar un conjunto de herramientas de soporte a
la ejecución de los procesos (capa de herramientas). Por tanto, la implantación de
las normas no requiere necesariamente cambiar la estructura organizativa. Aunque
sí será necesaria la definición detallada de los procesos y de los roles o funciones
específicos, que garanticen que son efectivos. En la figura 2.6 se representan la capa
de procesos ISO/IEC 20000 y la capa de herramientas como instrumentos al servi-
cio de la organización de TI y de sus equipos de trabajo.
Fuente: Telefónica.
CIO
F1 F2 F3
P1
P2
P3
F: funciones o departamentos
P: procesos
Fuente: Gartner.
de cómo aplicar una parte de un proceso. Desarrolla las actividades y tareas que for-
man un proceso, e incluye una descripción detallada de cada una de ellas.
Un proceso describe “qué hay que hacer” y un procedimiento “cómo hay que
hacerlo” en una situación concreta. Por ejemplo, un proceso puede establecer que
hay que registrar el incidente en la herramienta de gestión de incidentes, y el proce-
dimiento indicar los pasos a dar en la herramienta concreta de gestión de inciden-
tes, qué hay que poner en cada campo, etc.
La mayor parte de las organizaciones suele completar sus procedimientos con ins-
trucciones de trabajo complementarias, más detalladas que los procedimientos,
cuyo objetivo es describir, hasta los últimos detalles necesarios, las tareas descritas
en los procedimientos. Una instrucción de trabajo puede elaborarse en el caso de
que haga falta más detalle en un procedimiento, por ejemplo, cuando roles distin-
tos tienen instrucciones de trabajo distintas dentro del mismo procedimiento.
Por tanto, procesos, procedimientos e instrucciones de trabajo tienen como finali-
dad primordial ser utilizadas por el personal en la realización diaria de su trabajo.
En el caso concreto de los procesos de gestión de TI, todos los procesos se deben
formalizar, pero la experiencia demuestra que no en todos ellos es productivo bajar
al nivel de detalle de procedimiento o de instrucción de trabajo. En general, será
útil poner énfasis en detallar aquellos procesos en los que:
• Se ve involucrado mucho personal.
• Se deben engranar un conjunto de actividades, subprocesos y tareas com-
plejos.
• Es necesaria una automatización minuciosa.
Típicamente, los procesos que tienen un flujo extenso, y que convendrá detallar,
son: la gestión del incidente (y la gestión de la petición del usuario), la gestión del
cambio, la gestión de la entrega y la gestión de suministradores. Más allá del
alcance de estas normas, será necesario bajar a nivel del procedimiento en: la ope-
ración, la gestión del evento o la gestión del acceso. En el resto de procesos, para la
mayoría de las organizaciones, detallarlos no aportará un valor adicional.
Sistema de Gestión del Servicio de TI (SGSTI)
UNE-ISO/IEC 20000-1
Esta parte de la Norma ISO/IEC 20000 define los requisitos para que un proveedor
del servicio proporcione servicios gestionados de una aceptable calidad a sus clientes.
Puede ser usada:
a) para negocios que solicitan ofertas para sus servicios;
Nota 1: El término “negocio” en esta norma internacional debería interpretarse en un sentido
amplio, abarcando aquellas actividades que son esenciales para alcanzar los fines que
persigue la organización.
b) para negocios que requieren de un enfoque consistente por parte de todos sus
proveedores del servicio en la cadena de suministro;
c) por proveedores del servicio para medir y comparar su gestión del servicio
de TI;
d) como base de una evaluación independiente;
e) por una organización que necesite demostrar su capacidad para proveer
servicios que cumplan con los requisitos de los clientes; y
f) por una organización que busque mejorar los servicios, mediante la aplica-
ción efectiva de los procesos para monitorizar y mejorar la calidad de los
servicios.
En relación a la estructura y tamaño del proveedor de TI, debemos indicar que los
requisitos de la norma son totalmente independientes de la estructura de la organi-
zación o tamaño de la misma. Aunque, cuanto mayor sea el tamaño del proveedor
o la complejidad de los servicios, mayores beneficios se podrán obtener de la apli-
cación de la norma. Un proveedor de servicio debe utilizar la organización que le
sea más apropiada, según su negocio, su cultura y su estrategia.
Para entender claramente el alcance de estas normas se debe comprender el signifi-
cado que se otorga a dos conceptos: “servicio de TI” y “proveedor de TI”.
66 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• El correo electrónico.
• El sitio web de la empresa.
• El portal web interno de la empresa (la intranet).
• El servicio de ERP (Enterprise Resource Planning) de una empresa.
• El servicio de alojamiento de aplicaciones o portales web.
• El servicio de alojamiento de servidores ofrecido por un Internet Center.
• El servicio de facturación.
• El servicio de gestión del conocimiento.
• El servicio de colaboración.
Servicios de TI
Negocio
Gestión Acceso en
de clientes teletrabajo
Gestión Provisión y
de ventas soporte del
Gestión de Correo
Gestión de puesto de trabajo
facturación electrónico
actuaciones
De forma clara, estas normas se refieren a los servicios que se prestan utilizando
como base los sistemas informáticos. Esta concepción de servicio no quiere decir
que no se puedan aplicar las directrices y recomendaciones a otro tipo, pero su apli-
cación habrá que matizarla e interpretarla, como es el caso de los servicios de las
operadoras de telecomunicaciones. Pero hay otros casos que no están en el alcance,
aunque también se denominan servicios, como por ejemplo: la prestación de servi-
cios de consultoría, la venta de equipamiento informático, etc. En la figura 2.9 se
muestra la simbología utilizada en el libro para estos dos omnipresentes conceptos.
Servicio de TI Proveedor de TI
Por otra parte, es importante tener en cuenta el punto en el que se esté situado en
la cadena de provisión para determinar si tal o cual actividad es un servicio ofre-
cido, o bien, es un servicio contratado. Un área interna de una empresa ofrece ser-
vicios a los usuarios de la misma, pero a su vez, contrata servicios al mercado (el
centro de tele-atención, el alojamiento de sus equipos en un centro de proceso de
datos de un tercero, los servicios de telecomunicaciones, etc.). Así, en la posición
del área interna de TI, ésta ofrece servicios a sus usuarios y clientes, y contrata otros
servicios a los proveedores externos o internos.
Bajo la perspectiva de estas normas, el término servicio se utiliza para referirse al
prestado por la organización a la que se aplica la norma.
En este ámbito, el término “proveedor del servicio de TI” se puede aplicar a cual-
quier unidad, departamento, organización o empresa que preste servicios de TI,
con independencia de que haya o no transacción económica, o del tamaño de la
organización. Algunos ejemplos de proveedor de TI pueden ser:
• Los departamentos de sistemas de información o departamentos de infor-
mática internos de las empresas.
• Empresas que ofrezcan servicios de TI al mercado.
A partir de este punto, a lo largo del libro se utilizará el término “proveedor de TI”
como sinónimo de organización de TI o departamento informático, dotándole del
mismo alcance que en las normas.
El papel del proveedor de TI aparece levemente descrito en las generalidades del
apartado 7.1 de la norma, cuando tratan las relaciones con el negocio.
UNE-ISO/IEC 20000-2
Servicio de TI
Cliente del
Cliente de TI negocio
Grandes
clientes
Parece que los autores de ISO/IEC 20000 e ITIL (v2 y v3) suelen coincidir en
cuáles son los procesos básicos para la gestión de las TI. Así, estos diferentes
marcos de referencia tienen un núcleo con procesos bastante similares (inci-
dente, problema, configuración, cambio, entrega, nivel de servicio, disponibili-
dad, continuidad, capacidad y financiero). En cambio, a la hora de realizar la
agrupación conceptual de estos procesos, es donde los autores han dejado volar
su creatividad, proponiendo en sus modelos agrupaciones dispares. Por suerte,
estas diferentes agrupaciones son conceptuales y no tienen reflejo en el conte-
nido de los procesos que se han de aplicar. En el caso de las Normas ISO/IEC
20000, la agrupación tiene su lógica y es razonable (agrupaciones: provisión del
servicio, control, entrega, resolución y relaciones), pero distinta a lo establecido
en ITIL v2 (libros: soporte de servicio, provisión de servicio, gestión infraes-
tructuras, etc.) y distinto ITIL v3 (libros: estrategia, diseño, transición, opera-
ción y mejora continua). Así, se agrupan bajo la provisión de servicio procesos
distintos a los contemplados en ITIL v2 en su libro de provisión de servicio. En
ITIL v3 la agrupación se hace en función del ciclo de vida del servicio. Con
independencia de la agrupación de procesos que se realice, individualmente hay
un núcleo común (gestión del incidente, gestión del problema, gestión de la
configuración, etc.).
Los primeros apartados en estas normas están centrados en inculcar en TI las ense-
ñanzas aprendidas implantando y mejorando sistemas de gestión en todo tipo de
organizaciones. Por ello, los capítulos 3 y 4 se centran en: el sistema de gestión TI
y en la planificación e implementación de la gestión del servicio.
Prácticamente, el resto de estas normas se dedica a la definición de los procesos,
agrupados en: Planificación e implementación de servicios, nuevos o modificados;
Procesos de provisión de servicio; Procesos de relación; Procesos de resolución;
Procesos de control y Proceso de entrega.
En el esquema de la figura 2.11 se muestra el modelo básico utilizado en este
libro y en las normas para representar todo el alcance de la gestión del servicio de
TI. En el rectángulo exterior se sitúa el sistema de gestión del servicio de TI (que
se explica en el capítulo 3). Hacia el interior del rectángulo aparece de forma
inmediata las actividades de implantación del sistema de gestión (tratadas en el
capítulo 4). Una vez establecido el sistema que gestionará el servicio, su implan-
tación y mejora, se incorporan los 14 procesos establecidos en ISO/IEC 20000
(tratados en los capítulos de 5 al 10). Esta figura se utilizará de índice gráfico en
todo el libro.
Las Normas ISO/IEC 20000 se componen de un conjunto de procesos que inter-
actúan entre sí y que son necesarios para la prestación de un servicio con el obje-
tivo de normalizar la gestión de los sistemas de información mediante procesos
72 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
En las normas, para cada fase del ciclo PDCA se establecen los requisitos y reco-
mendaciones a seguir por todo proveedor de TI.
Procesos de provisión de servicio. Regulan las actividades necesarias para que los
servicios cumplan los cometidos pactados con el negocio. Cobran especial relevan-
cia frente a la necesidad de prestar servicios de TI de calidad, alineados a los objeti-
vos del negocio, que cubran las necesidades actuales y que deben ser capaces de
evolucionar rápidamente para cubrir las necesidades futuras. En estas normas, la
provisión de servicio aglutina 6 procesos:
• Proceso de gestión de nivel de servicio.
• Proceso de generación de informes del servicio.
• Proceso de gestión de la continuidad y disponibilidad del servicio.
• Proceso de elaboración de presupuesto y contabilidad de los servicios de TI.
• Proceso de gestión de la capacidad.
• Proceso de gestión de seguridad de la información.
74 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
ISO/IEC 20000 divide de una forma más racional las funciones de la ges-
tión de nivel de servicio en 4 o 5 procesos:
1. La gestión de nivel de servicio, que en estas normas trata todo lo relativo
a los servicios desde la perspectiva interna de TI, como por ejemplo la
definición, el cumplimiento y seguimiento de los acuerdos de nivel de
servicio (SLA), la gestión del catálogo de servicios y el plan de mejora
de los servicios.
2. La generación de informes de servicio aparece como un proceso nuevo.
En ITIL se hace referencia a los informes del servicio pero como parte de
cada proceso (por ejemplo la gestión de la disponibilidad) y no se trata
de un proceso separado.
3. El proceso de relaciones con el negocio (el definido en estas normas se
corresponde únicamente a las relaciones con el cliente, que se llevan a
cabo en la gestión de nivel de servicio de ITIL).
4. El proceso de planificación e implementación de nuevos servicios o de
servicios modificados.
5. Incluso en la v2 se llega a asignar la gestión de los contratos con los sumi-
nistradores a este proceso en lo relativo al respaldo de los niveles de servi-
cio pactados con el cliente. En la v3 como en ISO 20000 aparece un pro-
ceso nuevo específico para la gestión de suministradores.
Sí Sí Sí
servicio
Elaboración de presupuestos y contabilidad
Sí Sí Sí
de los servicios de TI
Gestión de la capacidad Sí Sí Sí
Gestión de la seguridad de la información Sí Sí Sí
Gestión de las relaciones con el negocio Sí En gest. nivel servicio
Gestión de suministradores Sí (2) Sí
Gestión del incidente Sí Sí Sí
Gestión del problema Sí Sí Sí
Gestión de la configuración Sí Sí Sí
Gestión del cambio Sí Sí Sí
Proceso de gestión de la entrega Sí Sí Sí
(1)
En ITIL v3 la creación de nuevos servicios está embebida en el concepto de ciclo de vida del servicio.
(2) En ITIL v2 la gestión de suministradores se trata en el libro ITIL Business Perspective publicado por OGC.
El término “sistema de gestión” proviene del inglés “management system” que repre-
senta un modo o forma de gestionar, o una manera formalizada de realizar las
cosas. Así, “IT management system” o “el sistema de gestión de TI” correspondería
a una forma normalizada para gestionar los trabajos que se realizan en TI, se
corresponde a la forma de hacer, trabajar y gestionar. La abreviatura que se ha acu-
ñado para el sistema de gestión de TI es SGSTI (Sistema de Gestión del Servicio
de TI). Es frecuente encontrar otras siglas relacionadas con este concepto, como
son: SGC (Sistema de Gestión de la Calidad), SGS (Sistema de Gestión de Servi-
cios) o SMS (Service Management System).
Se entiende el sistema de gestión de TI como el propio modelo de hacer o trabajar
en TI. Lo que cotidianamente se expresa como “vamos a implantar ITIL”, “vamos a
implantar ISO/IEC 20000”, “hay que hacer un proyecto para mejorar los servicios
de TI”, “esta es nuestra forma de trabajar en esta casa”, “el departamento de infor-
mática se gestiona en base a estos procedimientos”, etc. todas ellas son maneras de
expresarse en TI y expresan de alguna forma el concepto de “sistema de gestión
de TI” utilizado en los ámbitos de calidad. Por tanto, siendo como es la esencia de
ISO/IEC 20000 o ITIL, este sistema se define, se implanta y se mejora.
Quizá lo que más despista a los profanos es el término “sistema” pues, inconscien-
temente, parece que induce a pensar en una herramienta o algo parecido, pero no
es sólo esto. El sistema de gestión recoge la nueva forma de trabajar, de relacionarse
y de prestar servicios en TI. Si este sistema se ha creado siguiendo los principios,
los procesos y los requerimientos específicos para TI establecidos en las Normas
ISO/IEC 20000, habremos constituido el sistema de gestión de TI o SGSTI.
Desde la perspectiva de los elementos que lo componen, el sistema de gestión se
definiría como: “el conjunto de políticas, procesos, procedimientos e instrucciones
de trabajo, necesarios para la correcta gestión del servicio de TI”.
Desde una perspectiva integral del proveedor de TI, el sistema de gestión se vería
como: “el conjunto de elementos interrelacionados de una organización de tecno-
logías de la información por los cuales se lleva a cabo de forma normalizada su acti-
vidad de servicio en la búsqueda de la satisfacción de sus clientes”. Además, el con-
cepto de sistema de gestión conlleva que las actividades se normalicen en procesos
y que todos los procesos trabajen conjuntamente de una manera coordinada y con
un objetivo común, evitándose pasar de una estructura de departamentos estancos
a otra de procesos inconexos.
Con independencia de la definición utilizada, el objetivo y alcance del sistema de
gestión es el mismo.
A partir de ahora, el mundo técnico debe asumir como parte de su día a día este nuevo
concepto de “sistema de gestión de TI” o SGSTI, que equivale a gestionar el servicio
SGSTI
Fuente: Telefónica.
También hay que entender que estas normas y marcos de referencia del mercado
(ISO/IEC 20000, ITIL, etc.) aportan directrices y recomendaciones; pero no son
utilizables, como tal, directamente en la empresa. Requieren concretarse en proce-
sos y procedimientos, que son los instrumentos sobre los que se articula la gestión
de la actividad. Además, para que sean de verdad útiles, la aplicación de todos estos
estándares debe adaptarse a las particularidades de cada empresa (tamaño, negocio,
cultura, estrategia, etc.).
Por ello, todo proveedor u organización de TI debe crear su propio sistema de ges-
tión que tenga en cuenta cómo adaptar las normas a todas las particularidades pro-
pias de cada empresa.
86 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Tecnologías de la información
Gestión y operación
SG de otras áreas
del servicio de TI
de la empresa
SGSTI
Gestión servicio
Calidad y y su prestación
mejora continua
ITIL
ISO 9001
ISO 20000
Implicación
de la dirección
AR PARA
S LÍDERES
SGSTI
Documentación Cambio cultural
Responsabilidades de la dirección
La mejora de los servicios de TI pasa por implantar los procesos que forman el sis-
tema de gestión de TI en todo su detalle. Este enfoque en torno a los procesos va a
suponer la introducción de cambios sustanciales, tanto desde el punto de vista cul-
tural en la forma de trabajar de las personas como, en algunos casos, profundos
cambios organizativos. Ante esta transformación de TI (o del proveedor de servi-
cio de TI en terminología de la norma) resulta imprescindible contar con el apoyo,
compromiso y participación de la alta dirección de la empresa y de TI, como dina-
mizadora esencial de todo este proceso.
En líneas generales, las empresas tienen sus grupos internos (calidad, procesos, de
mejora, explotación, etc.) que frecuentemente inician por si mismas las actividades
SGSTI
UNE-ISO/IEC 20000-1
f) gestionar los riesgos para la organización de la gestión del servicio y para los
servicios; y
g) llevar a cabo revisiones de la gestión del servicio, a intervalos planificados,
para asegurar la continuidad de su idoneidad, su adecuación y su efectividad.
UNE-ISO/IEC 20000-2
El papel de la dirección para asegurar todos los niveles del plan de gestión del
que las mejores prácticas son adoptadas servicio.
y mantenidas en los procesos es funda- El rol de responsable senior debería
mental para cualquier proveedor del estar al frente de los recursos designa-
servicio que quiera cumplir con los requi- dos para las actividades de mejora del
sitos de la Norma ISO/IEC 20000-1. servicio, bien sean actividades conti-
Para asegurar el compromiso de la nuas o con un enfoque de proyecto.
dirección se debería identificar un res- El responsable senior debería estar apo-
ponsable a nivel de alta dirección como yado por un grupo encargado de la
responsable de los planes de gestión del toma de decisiones que tenga la sufi-
servicio. Este responsable senior debe- ciente autoridad para definir la política
ría responsabilizarse de la entrega a y para hacer cumplir sus decisiones.
Requisitos de la documentación
Para que el sistema de gestión sea eficaz es necesario dar respuesta a dos aspectos
clave. El primero de ellos es definir y documentar adecuadamente las actividades,
funciones y responsabilidades que deben desempeñarse. El segundo es contar con
la participación activa y efectiva del personal implicado en el servicio.
El primer paso de cara a implantar un sistema de gestión es crear una estructura
documental. Permite llevar registro y control de todas las actividades realizadas,
evaluar la eficiencia del sistema y servir para la toma de decisiones sobre acciones
correctivas o preventivas. Todas las actividades desarrolladas deben documentarse.
A este respecto estas normas establecen:
UNE-ISO/IEC 20000-1
Los proveedores del servicio deben facilitar documentos y registros para asegurar
una planificación, operación y control de la gestión del servicio efectivas. Esto debe
incluir:
a) políticas y planes de la gestión del servicio documentados;
b) acuerdos del nivel de servicio documentados;
c) procesos y procedimientos documentados requeridos por esta norma; y
d) registros requeridos por esta norma.
Los soportes en los que esté recogida la documentación deben ser los adecuados
para permitir un normal funcionamiento del sistema. Por ejemplo, si nuestra orga-
nización recibe mensualmente 1.000 incidentes, no pueden quedar registrados úni-
camente en un cuaderno. Deberán registrarse en una herramienta informática
dimensionada de acuerdo a las necesidades del proceso y de la organización.
La documentación del sistema contribuye a:
• Lograr la conformidad con los requisitos del cliente y la mejora de la calidad.
• Proveer la formación adecuada.
92 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• La repetibilidad y la trazabilidad.
• Proporcionar evidencias objetivas.
• Evaluar la eficacia y la adecuación continua del sistema de gestión de servi-
cios de TI.
Para gestionar de una forma eficaz la documentación del sistema es necesario ela-
borar un procedimiento que diga cómo y quién crea los documentos, los revisa,
aprueba, mantiene y elimina.
Fuente: Telefónica.
Como es lógico, los contenidos del sistema de gestión se deben alojar en una herra-
mienta de soporte documental que permita una gestión de versiones y un control
de los cambios a los contenidos.
El manual del SGSTI es el documento principal que recoge la estrategia de la
empresa, la estructura, responsabilidades, actividades, recursos, modelo de proce-
sos, etc., que una organización establece para llevar a cabo la gestión de los servi-
cios de TI. Físicamente puede ser un único documento o una estructura documen-
tal basada en versiones.
El manual de procesos y procedimientos del SGSTI contiene la definición especí-
fica de todos los procesos, procedimientos e instrucciones de trabajo que aseguren
la adecuada gestión de servicios de TI. Nuevamente, la denominación de “manual”
no quiere decir que sea un documento único, pues estará formado por un conjunto
completo de documentos. Pero, eso sí, con un adecuado control de versiones. El
manual del SGSTI nos dice: ¿qué? y ¿quién?; mientras que el manual de procedi-
mientos indica: ¿cómo? y ¿cuándo?
La definición de los procesos es una de las principales actividades para el cambio
en el proveedor de TI. Para la definición de procesos se recomienda la utilización
de una herramienta específica de diagramación con soporte para poder describir su
contenido. En la figura 3.7 se muestra un ejemplo de la estructura documental para
definir un proceso.
Cuando sea necesario especificar en detalle una actividad o una tarea se utiliza el
documento denominado “instrucción de trabajo”, que describe la forma en la que
se debe realizar un trabajo. En la figura 3.8 se muestra el ejemplo del contenido de
una de ellas.
SGSTI
1. Introducción
• Objetivo del documento. Documentos
de referencia.
3. El proceso en detalle
• Diagrama de flujo del proceso.
• Diagrama de flujo de los subprocesos.
• Diagrama de flujo de las actividades.
• Detalle de cada actividad y E/S.
• Relaciones con otros procesos.
4. Roles y responsabilidades
• Roles y sus responsabilidades.
• Matriz RACI.
8. Anexos
Fuente: Telefónica.
Figura 3.7. Ejemplo del índice del documento para la definición de un proceso
96 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
1. Introducción.
2. Objeto.
3. Campo de aplicación.
4. Documentos relacionados.
5. Definiciones.
6. Pautas de implantación.
7. Prioridad de los incidentes.
8. Tabla de prioridades.
9. Lista de umbrales basada en prioridades.
10. Categoría de un incidente.
Las evidencias son cualquier documento o prueba que proporcione una demostra-
ción objetiva del cumplimiento de las normas por el proveedor de TI. Las eviden-
cias se obtienen de los registros y de cualquier otra forma que permita probar que
se cumplen los requisitos (por ejemplo, un documento, una comprobación, etc.).
En relación a las evidencias, ISO/IEC 20000-2 indica:
UNE-ISO/IEC 20000-2
Los registros están ligados al control de la actividad de TI, mientras que las eviden-
cias se utilizan directamente para la certificación y las auditorías.
la forma de trabajar de las personas que componen TI y la forma en que estas sienten
cuál es su misión en la organización. El cambio se orienta hacia una sistemática de
trabajo estructurada, centrada en los clientes, basada en procesos y articulada en
torno a servicios.
Para que esta transformación se pueda llevar a cabo, hay que poner la máxima aten-
ción y esfuerzo en el equipo humano que está involucrado en los servicios. Pues es
este conjunto de personas el que debe evolucionar sus formas de hacer hacia los
esquemas estandarizados por el mercado.
Por lo tanto, para conseguir una eficaz implantación del sistema de gestión, es
necesario llevar a cabo la adecuada gestión de los recursos humanos. Para ello,
debemos responder a tres preguntas:
• ¿Cuáles son las necesidades en cuanto a roles y funciones que requiere el sis-
tema de gestión?
• ¿Qué perfiles existen dentro la organización?
• ¿Cómo se va a cubrir el posible desfase entre ambos aspectos?
Para responder a estas preguntas ISO/IEC 20000-1 establece los siguientes requi-
sitos:
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
El personal que realiza el trabajo relativo del más amplio contexto de nego-
a la gestión del servicio debería ser com- cio y de cómo contribuyen a la
petente para esta función gracias a la consecución de los objetivos de
educación recibida, a la formación, las calidad;
habilidades y la experiencia adecuadas.
c) mantener registros apropiados de
El proveedor del servicio debería: la educación, formación, habili-
dades y experiencia;
a) determinar las aptitudes necesa-
rias para cada rol en la gestión d) proveer formación o llevar a cabo
del servicio; otras acciones para satisfacer
estas necesidades;
b) asegurar que el personal es cons-
ciente de la relevancia e impor- e) evaluar la efectividad de las ac-
tancia de sus actividades dentro ciones realizadas.
Como no podía ser de otra forma, ISO/IEC 20000-2 hace especial hincapié en
el desarrollo profesional y de las competencias de las personas que forman parte
de TI:
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
En la figura 3.9 se muestra una situación que es frecuente encontrar en las empre-
sas más avanzadas. En esta primera etapa de evolución en las formas de gestión de
las TI, se incorporan las normas más relevantes: para la gestión de sistemas, para el
desarrollo, para la seguridad y para el gobierno de las TI.
El SGSTI debe unificar, incorporándolos, los sistemas de gestión en el ámbito de
TI que posiblemente se estén implantando o ya se hayan implantado.
Dado que el entorno normativo está en frenética ebullición, el sistema de gestión
de TI se debería ir enriqueciendo con aquellos avances normativos que contribu-
yan a la mejora del proveedor de TI, con el fin de implantar en el quehacer coti-
diano de TI la riqueza de las formas de hacer de todos estos estándares. Así, la gestión
de todo proveedor de TI se construirá tomando en cuenta todos los estándares de
mayor relevancia para tener una gestión de las TI completamente madura (denomi-
nado aquí como: SGSTI++), como se muestra en la figura 3.10.
Después de esta visión al futuro, conviene dejar claro que en el caso de las Normas
ISO/IEC 20000 sólo se exige que se cumpla con los requisitos especificados en
ellas y no se requiere que se incorporen todos los otros estándares mencionados
anteriormente.
En los capítulos siguientes del libro se profundiza en los 14 procesos definidos en
estas normas, que son la base para la trasformación de las actividades más esencia-
les del proveedor de TI.
SGSTI
SPICE ISO
ISO 9001 COBIT ITIL ISO 17799
15504
CMMI for
ISO 9004 ISO 38500 ISO/IEC 20000 ISO 27001
DEV
ISO 90003
Resumen
La aportación principal de un sistema de gestión es el orden y la estandarización.
Así, toda la organización trabaja de la misma forma y con el mismo “idioma”. Todo
ello contribuye en la consecución del objetivo que tiene este sistema de gestión:
“hacer posible una efectiva gestión e implantación de todos los servicios de TI”.
El objetivo de este sistema de gestión es conseguir que la provisión y prestación de
los servicios de TI se realice de una manera eficaz y eficiente.
En la figura 3.11 se recoge una visión completa del SGSTI y su relación con el día
a día del proveedor de TI.
Fuente: Telefónica.
Figura 3.11. Visión completa del SGSTI y su relación con el día a día
del proveedor de TI
SGSTI
Fuente: Telefónica.
Beneficios
Implantar la gestión de los servicios de TI, utilizando los conceptos y rigor impues-
tos por el sistema de gestión, aporta importantes ventajas a la organización de TI:
• Formaliza en la organización la implantación de la gestión del servicio.
• Propone una aproximación estructurada de lo general (estrategia y políticas)
a lo particular (procedimientos).
• Da soporte a una implantación por etapas, extendida en el tiempo.
• Impone rigor en la definición, en el seguimiento y en la captura de registros
y evidencias.
• Permite la alineación con los sistemas de gestión de la calidad (ISO 9001)
de la empresa.
• Genera un sistema documental en el que se recoge formalmente toda la
información necesaria para soportar el modelo de gestión.
• La gestión documental que lo soporta es una pieza imprescindible para obte-
ner la certificación ISO/IEC 20000.
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Sabe qué sistemas de gestión hay implantados en su empresa u
organización?
• ¿Qué aporta un sistema de gestión a las organizaciones de TI?
• ¿Cuál es la diferencia entre el Sistema de Gestión del Servicio de TI
(SGSTI) y el modelo de procesos ISO/IEC 20000?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
4
Capítulo 4
Planificación e
implementación de
la gestión del servicio
Las Normas ISO/IEC 20000, al igual que muchas otras normas internacionales,
establecen que la implantación de los procesos para la gestión del servicio se estruc-
ture en las cuatro etapas identificadas por las siglas PDCA, muy utilizadas en gestión
de la calidad (véase la figura 4.1). Estas normas se centran en definir los requisitos y
recomendaciones a tener en cuenta para la implantación de los procesos establecidos
en los sistemas de gestión, ordenados en cada una de estas 4 etapas del PDCA.
El ciclo PDCA representa una forma de organizar los cambios o las acciones de
mejora en las organizaciones. Es una estructuración sencilla en 4 pasos y viene a
recordar que, además de planificar e implementar los cambios, hay que comprobar
el éxito de las acciones, y si hay algo que corregir o prevenir (que siempre lo habrá)
hay que actuar para subsanarlo. La gran importancia de este ciclo sencillo radica en
que se utiliza mucho en la normativa internacional de ISO y de otras instituciones
como la forma de implantar una actividad de mejora continua de cualquier aspecto
en cualquier organización. En la figura 4.2 se muestra este ciclo aplicado a la ges-
tión del servicio de TI.
112 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
P
Planificar: planificar la
implementación y la entrega
de la gestión del servicio.
Plan
Planificar
D A
Hacer: implementar el plan
Do Act Actuar: mejorar la eficacia y
de gestión del servicio. Hacer Actuar la eficiencia de la entrega
y la gestión de los servicios.
Check
Verificar
C
Verificar: monitorizar, medir
y revisar que los objetivos y
el plan de gestión del servicio
se están alcanzando.
El concepto original del ciclo PDCA fue desarrollado por Walter Shewhart, estadís-
tico pionero en el desarrollo de procesos de control estadístico en los Laborarios Bell
de EEUU durante la década de 1930. El ciclo de Shewhart fue adoptado y promo-
cionado posteriormente por un discípulo suyo W. Edwards Deming en la década de
1950, difundiéndose como ciclo o rueda de Deming, quien propuso que los procesos
se deben analizar y medir para identificar las causas de las variaciones que originan
que los productos se desvíen de los requisitos de los clientes. Deming recomienda
que los procesos de negocio deben estar en un bucle realimentado de mejora conti-
nua para poder identificar y cambiar las partes del proceso que necesitan mejora.
Unos años después, en su carrera profesional, Deming modifica el concepto origi-
nal de PDCA, cambiando “check” por “study”, pues según él, “estudiar” describe
mejor la intención inicial, apareciendo el nuevo ciclo Plan-Do-Study-Act (PDSA),
que ha tenido escasa aceptación.
Posteriormente la metodología de mejora continua Seis Sigma define un ciclo de
cinco etapas: Define-Measure-Analyze-Improve-Control (DMAIC) basado en el ciclo
de Deming.
Otros autores proponen anteponer al PDCA una etapa de análisis y de decisión.
Para ello, utilizan la metodología FOCUS (Find-Organize-Clarify-Understand-Start);
creándose un ciclo de nueve etapas denominado: FOCUS-PDCA.
PDCA
En la figura 4.3 se muestran estas 6 etapas en las que ITIL v2 estructura la activi-
dad de implementación.
¿Cuál es la visión?
¿Dónde estamos
ahora?
¿Cómo hacemos
para llegar?
¿Cómo comprobamos
que hemos alcanzado
los objetivos?
Fuente: Libro ITIL Planning to Implement Service Management publicado por OGC.
Plan
Planificar
Do Act
Ciclo PDCA Hacer Actuar
Fase inicial de evaluación
habitual
y selección de acciones Check
Verificar
C A P D C A
Verificar: Actuar: Planificar: Hacer: Verificar: Actuar:
realizar un identificar planificar la implementar monitorizar, medir mejorar la eficacia
análisis o las acciones implementación el plan de y revisar que los y la eficiencia
evaluación que se deben y la entrega de gestión del objetivos y el plan de la entrega
inicial de la realizar. la gestión servicio. de gestión del y la gestión de
organización del servicio. servicio se están los servicios.
de TI alcanzando.
Figura 4.4. Inicio habitual en TI del ciclo PDCA por una fase inicial de Check y Act
UNE-ISO/IEC 20000-1
La Norma ISO/IEC 20000-1 presenta un esquema del PDCA como motor para la
implementación y mejora de la gestión del servicio. En la figura 4.6, en la parte
izquierda se muestran las entradas a tener en cuenta en la gestión del servicio (requi-
sitos del negocio, requisitos del cliente, solicitudes de servicios nuevos o modifica-
ciones, interfaces con otros procesos, el centro de servicio al usuario, otros grupos o
áreas, etc.). En la parte derecha se muestran las salidas de la actividad de gestión del
servicio (entrega de resultados al negocio, satisfacción de las áreas cliente, los servi-
cios nuevos o renovados disponibles, satisfacción del equipo de TI, etc.). En la parte
central se sitúa la propia gestión de TI, destacándose la necesaria implicación de la
dirección y el motor PDCA para implantar y evolucionar la gestión de TI.
cultural y organizacional: los procesos, las herramientas que los soportan y las per-
sonas. Áreas que, aunque no resultan nuevas en absoluto, no por ello dejan de ser
importantes para estructurar las actividades que se deben realizar. En la figura 4.7
se muestran estas tres áreas alrededor del SGSTI y del ciclo PDCA utilizado para
implementarlo y mejorarlo.
La experiencia muestra que estos marcos de mejores prácticas utilizan una visión
bastante homogénea de los procesos y de su contenido, por lo que las diferencias
en la definición de los mismos son pequeñas. Es en los detalles de quién y con qué
se realizan (contenidas en los procedimientos) cuando empiezan a aparecer diferen-
cias entre las organizaciones. Por este motivo se recomienda realizar con rapidez la
definición de procesos y procedimientos, y también contar con el apoyo de una
consultora externa para ello.
La definición de los procesos es una actividad importante en la implantación y, ade-
más, se suele concluir con bastante éxito. Pero hay que recordar que no es la única
faceta: los procesos hay que implantarlos para que el personal trabaje de acuerdo a
ellos; el apoyo de las herramientas de gestión es esencial para dar eficiencia y con-
ducir el trabajo diario; y el cambio cultural de la organización es el factor más difí-
cil de llevar a cabo.
verdad por el cambio y que ellos son importantes para conseguirlo. Sin cumplir
este requisito el fracaso está garantizado.
La importancia de las personas en este camino de transformación se debe manifes-
tar nítidamente en:
• Planes paulatinos, constantes e intensivos de formación sobre las nuevas for-
mas de trabajo y las nuevas herramientas de gestión.
• Entrenamiento individual en las funciones de su puesto, hasta que cada uno
llegue a desempeñarlas a la perfección.
• Comunicación, ánimo y estímulo constante. Mediante conferencias, reunio-
nes, boletines internos, etc. Transmitiendo tranquilidad ante la incertidum-
bre del cambio y entusiasmo.
• Motivación permanente a los que se implican y una gestión pertinaz de quie-
nes se muestran reticentes al cambio.
• Evolución organizativa ágil. Los nuevos roles necesarios se deben definir y
nombrar con rapidez.
• Autoridad y disciplina. Es necesario mantener el principio de autoridad, pues
el servicio de TI no es un juguete tecnológico, y sí es o será la pieza esencial
para la supervivencia de la empresa.
• Foco en el dominio de la tecnología. No se debe olvidar la necesidad del
dominio absoluto de la tecnología, sin el cual, todo esfuerzo de establecer
procedimientos y organizar será en vano. Así, por muy detallados que se ten-
gan los procedimientos, por muy alineados que se esté con el negocio, si los
programadores no saben construir código de calidad o si el técnico de
soporte al intentar resolver una incidencia destroza el equipo por desconoci-
miento técnico, no hay transformación posible.
SGSTI
Entrega 5 PDCA
Cambio 4 Herramientas
3
Creación
Configuración
2 servicios
1
Nivel de
Problema
servicio
0
Incidente Informes
Suministradores Contin. y
dispon.
Relaciones
Presupuestar
negocio
Seguridad Capacidad
– +
SATURADOS ECONÓMICOS OBLIGADOS CONDICIONADOS VISIONARIOS
(Por actividad diaria) (En reducción (Por necesidad (Por consolidaciones o (Negocios en alza)
de costes) de certificado) por outsourcing)
• Formación reducida. • Charlas introductorias. • Foco en “aprobar el • Formación global: • Formación global:
• Creen en ITIL pero • Formación examen” que supone amplia. extensiva.
“no practican”. especializada: puntual. la obtención de la • Formación • Formación
certificación. especializada: amplia. especializada:
• Desarrollo de • Desarrollo de
proyectos puntuales proyectos tácticos. • Una o dos personas • Desarrollo de proyectos abundante.
y por necesidad encargadas de estratégicos y • Desarrollo de
• Equipos de proyecto preparar un sistema
operativa formado por personal “completos”. proyectos estratégicos
(por ejemplo, de documentación (y tácticos alineados
interno. que justifique el • Equipos de trabajo con
catálogo de personal interno y fuerte con la estrategia).
servicios, etc.). • Reutilización de cumplimiento de
herramientas existentes. las normas. apoyo de especialistas • Equipos de trabajo
externos. con personal interno
• Compra herramientas • Foco en los papeles y fuerte apoyo de
de forma puntual. y en la formalización • Foco en normalización
integrada y herramientas especialistas externos.
documental.
que lo soporten. • Foco en normalización
• Poco interés por mejorar. e integración de
• Mejoras de “rebote”. procesos y las
• Cambios puntuales. herramientas que
lo soporten.
• Charlas introductorias.
• Formación especializada
puntual.
Fuente: Telefónica.
UNE-ISO/IEC 20000-1
Además, ISO/IEC 20000-2 añade dos aspectos más que se deberían considerar en
la planificación:
UNE-ISO/IEC 20000-2
g) una planificación de los recursos h) el enfoque para la modificación
expresada en términos de las fechas del plan y de los servicios defini-
en las que deberían estar disponi- dos por el plan;
bles las fuentes de financiación, las
habilidades y los recursos;
PDCA
El plan de implantación debe contemplar todos los aspectos relativos a los tres blo-
ques principales: los procesos, las herramientas de gestión necesarias y las perso-
nas. En la figura 4.11 se aprecia un ejemplo de las actividades que se deben con-
templar en un plan de implantación de estas normas.
• Formación de profesionales.
• Plan de comunicación.
• Cambio organizativo.
PERSONAS
• Entrenamiento personal.
• Despliegue de herramientas.
• Cambio de formas trabajo.
Fuente: Telefónica.
SGSTI
Entrega 5 PDCA
Cambio 4 Herramientas
3
Creación
1
Nivel de
Problema
servicio
0
Incidente Informes
Suministradores Contin. y
dispon.
Relaciones
Presupuestar
negocio
Seguridad Capacidad
4.o Formación y certificación de profesio- Otras etapas de PDCA: ejecución del plan
nales clave en ITIL e ISO/IEC 20000 de implementación, comprobación y mejora
UNE-ISO/IEC 20000-2
Enfoques de la planificación
UNE-ISO/IEC 20000-2
Se pueden utilizar varios planes de ges- Un plan de gestión del servicio debería
tión del servicio en lugar de un plan o incluir:
programa de gran magnitud. En este a) la implementación de la gestión
caso, los procesos subyacentes a la ges- del servicio (o de parte de la ges-
tión del servicio deberían ser coherentes tión del servicio);
entre ellos. También se debería poder
b) la entrega de los procesos de la
demostrar cómo se gestiona cada
gestión del servicio;
requisito de planificación vinculándolo
a sus correspondientes funciones, res- c) los cambios de los procesos de la
ponsabilidades y procedimientos. gestión del servicio;
La planificación de la gestión del servi- d) las mejoras de los procesos de la
cio debería formar parte del proceso gestión del servicio;
para convertir las necesidades de los e) los nuevos servicios (hasta el punto
clientes y las intenciones de los directi- que afecten a los procesos inclui-
vos en servicios y para proporcionar dos en el alcance acordado de la
una guía para dirigir el progreso. gestión del servicio).
personas tendrán que trabajar de una forma o de otra según del servicio de
que se trate. Debemos destacar que este segundo caso es el más eficaz para la
obtención de un certificado.
consigue hasta que no estén todos ellos implantados. Como las combinaciones son
muchas, a continuación se presentan las más frecuentes:
• Escenario 1: Inestabilidad. Una organización con inestabilidad y con con-
tinuos cortes del servicio estará sumida en una crisis permanente restaurando
los servicios. En esta situación, lo primero que hay que hacer es poner foco
inmediato en controlar la situación. Para ello será necesario trabajar con la
gestión del incidente para minimizar los tiempos de no disponibilidad. De
forma casi paralela, parece razonable implementar también la gestión del
cambio, que pone orden en todo paso al entorno productivo y reduce el
número de incidentes que se producen derivados de los cambios. Además,
será conveniente iniciar la gestión del problema, para eliminar los fallos y
defectos ocultos. También se debería abordar soluciones de monitorización
para tener un mejor control del entorno productivo.
• Escenario 2: Garantizar. Es este caso, la organización de TI necesita dar
garantías al negocio de que las pérdidas de información y del servicio son
mínimas. Lógicamente, es una situación más avanzada que el escenario 1 de
crisis, aunque no se debe poner en riesgo el negocio por que TI no pueda
recuperar los datos o los sistemas. El foco se debe poner en los procesos que
garantizan que los servicios se puedan restaurar en cualquier situación, bien
sea por fallos locales o por el impacto de desastres mayores. Antes de comen-
zar con los procesos ISO/IEC 20000, habrá que revisar o implantar una
solución sólida de copias de seguridad (backup). Después, deberá centrarse
en el registro de las versiones de las aplicaciones instaladas y de la parametri-
zación realizada. Para ello ser tratará la gestión de la configuración y la ges-
tión de la entrega. Posteriormente, se implementará la gestión de la conti-
nuidad para garantizar la recuperación en caso de desastre.
• Escenario 3: Relaciones. Si el servicio es estable pero la opinión de las
áreas negocio clientes sobre el servicio de TI es mala y las relaciones son
tensas y difíciles, la estrategia debe ser distinta. Hay que ponerse de inme-
diato a regular y mejorar la comunicación, a tranquilizar al negocio y a ges-
tionar las expectativas. En este escenario lo razonable sería comenzar con la
gestión de las relaciones con el negocio y definir un catálogo de servicios
que regule las expectativas sobre TI, para pasar inmediatamente a la defini-
ción de acuerdos de nivel de servicio (SLA) y a implementar la gestión de
nivel de servicio que se encargue de seguir su cumplimiento. La gestión
de informes y su disponibilidad online al negocio mejorará enormemente la
percepción sobre TI.
Gestión de la
Gestión Catálogo
configuración
del cambio de servicios
CMDB y DSL
Además de los ejemplos anteriores, se pueden dar otras situaciones a partir de las
cuales se decide implementar ISO/IEC 20000:
• Escenario 4: Un problema. Foco en resolver un problema inmediato que
existe en la organización. En este caso, TI no se puede detener a realizar eva-
luaciones sobre la madurez actual. Se deben identificar los principales pro-
blemas acuciantes del proveedor de TI para buscar soluciones inmediatas.
Cada problema tendrá su propia aproximación. El problema puede ser de
índole técnico, organizativo, de motivación, de capacitación, de gestión, etc.
Las Normas ISO/IEC 200000, junto con ITIL y el sentido común, aporta-
rán alguna vía de solución.
• Escenario 5: Foco en los servicios críticos. La empresa tiene claramente
identificados cuáles son sus servicios críticos con gran impacto en la actividad
PDCA
Eventos a considerar
UNE-ISO/IEC 20000-2
Conviene tener en cuenta que los éxitos rápidos hay que publicitarlos en la organi-
zación.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Nota: Es posible que la persona que sea ade- mentación inicial no sea la apropiada para la
cuada para realizar la planificación y la imple- operación continua.
Director de TI
Patrocinador SGSTI
CIO
Grupo implementación y
Planificación Dirección de Dirección de procesos TI
y control desarrollo producción
Director de TI
CIO
Dado que la transformación es un proceso continuo, este equipo creado ad-hoc para
el proyecto o los proyectos de implantación, suele constituirse en una estructura
estable en el tiempo. Este equipo muy centrado inicialmente en la implantación,
va evolucionado su actividad hacia la mejora continua de los servicios y de la activi-
dad de TI.
En las grandes organizaciones habría que tener en cuenta la necesidad de diversos tipos
de apoyo externo a lo largo del tiempo. A este respecto, en las más avanzadas, suelen
contratar una evaluación anual o bianual para identificar las fortalezas adquiridas y los
nuevos puntos de mejora. A veces, además de esta evaluación se suele realizar un
benchmarking comparativo con el mercado de los ratios más destacados de TI.
La aparición continua de normativa, que por una parte aporta ayuda a las empresas
pero que por otra acaba convirtiéndose en una nueva demanda del mercado, hace
que este equipo de implantación o de procesos de TI tenga garantizada una intensa
actividad para los próximos 10 años.
Las empresas deberán tener en cuenta, en sus estrategias y sus porfolios de proyec-
tos anuales, destinar una partida al proyecto de transformación continua de las for-
mas de hacer.
UNE-ISO/IEC 20000-1
Objetivo: Monitorizar, medir y revisar que los objetivos y el plan de gestión del ser-
vicio se están cumpliendo.
El proveedor del servicio debe aplicar métodos adecuados para la monitorización y,
cuando sea necesario, la medición de los procesos de gestión del servicio. Estos
métodos deben demostrar la capacidad de los procesos para alcanzar los resulta-
dos planificados.
La dirección debe realizar revisiones a intervalos planificados para determinar si los
requisitos de gestión del servicio:
a) son conformes con el plan de gestión del servicio y los requisitos de esta
norma, y
b) se implementan y se mantienen de manera eficaz.
PDCA
UNE-ISO/IEC 20000-2
El proveedor del servicio debería plani- Los resultados del análisis deberían pro-
ficar e implementar la monitorización, porcionar una entrada a un plan para
la medición, el análisis y la revisión de la mejora del servicio.
los servicios, los procesos de gestión
Además de las actividades de gestión
del servicio y los sistemas asociados.
del servicio relativas a la medición y el
Entre los elementos que se deberían
análisis, es posible que la alta dirección
monitorizar, medir y revisar están los
necesite recurrir a auditorías internas y a
siguientes:
otros tipos de verificaciones. Al decidir
a) los logros respecto a los objetivos la frecuencia de dichas auditorías inter-
de servicio definidos; nas y verificaciones, se deberían tener
en cuenta, entre otros, factores como el
b) la satisfacción del cliente;
nivel de riesgo implicado en un pro-
c) la utilización de los recursos; ceso, su frecuencia de realización y su
historial de problemas pasados. Las
d) las tendencias;
auditorías internas y las verificaciones se
e) las no conformidades de mayor deberían planificar, registrar y llevarse a
consideración; cabo de una manera competente.
UNE-ISO/IEC 20000-1
Política:
Debe haber una política publicada sobre la mejora del servicio. Se debe corregir
cualquier no conformidad con la norma o con los planes de gestión del servicio.
Se deben definir claramente los roles y las responsabilidades para las actividades de
mejora del servicio.
Actividades:
El proveedor del servicio debe realizar actividades para:
a) recopilar y analizar los datos para delimitar y medir la capacidad del provee-
dor del servicio para gestionar y proveer el servicio junto con los procesos de
gestión del mismo;
b) identificar, planificar e implementar mejoras;
c) consultar a todas las partes implicadas;
d) establecer objetivos de mejora en cuanto a la calidad, los costes y la utiliza-
ción de recursos;
e) tener en cuenta las aportaciones importantes, referentes a mejoras, que se
realicen desde todos los procesos de gestión del servicio;
f) medir, informar y comunicar las mejoras en el servicio;
g) revisar las políticas, los planes y los procedimientos de gestión del servicio,
siempre que sea necesario; y
h) asegurar que todas las acciones aprobadas se llevan a cabo y que se alcan-
zan los objetivos deseados.
PDCA
UNE-ISO/IEC 20000-2
En la mejora continua hay que distinguir dos tipos de mejoras: la mejora de los
procesos de gestión del servicio y la mejora propia de los servicios. Ambos tipos de
mejora redundarán en que la organización de TI funcione con más eficiencia, y en
que los servicios prestados sean de mayor calidad.
En el caso de la mejora de los procesos, las acciones de mejora de cada uno de ellos
las identifica y propone el propietario o el responsable del proceso. En relación a
144 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
las mejoras en cada uno de los servicios, las detecta, recopila de otras partes y pro-
pone cada uno de los gestores de nivel de servicio (véase el apartado 6.1). En ITIL,
para el conjunto de mejoras de uno o varios servicios agrupados en un plan se ha
acuñado el término de plan de mejora del servicio (SIP, Service Improvement Pro-
gram). Las acciones de mejora pueden abarcar todo tipo de actividad necesaria:
mejoras tecnológicas en los servicios, incorporación de herramientas, formación a
los involucrados, comunicación, mejora en la documentación, etc.
A la luz de lo establecido y recomendado por estas normas, parece razonable que
todas las acciones de mejora (de los procesos y de los servicios) se consoliden en una
planificación o un plan de mejora unificado, formado en base de los planes de
mejora de cada proceso y de cada servicio. De esta forma se tendrá una visión unifi-
cada de todas las acciones de mejora y las interrelaciones entre ellas. Este plan de
mejora unificado se puede ejecutar por fases y aplicando nuevamente el ciclo PDCA.
Las propuestas de mejora, que emanan de diversas fuentes (mejoras detectadas en
cada proceso, plan de mejora del servicio, iniciativas de calidad como Seis Sigma o
Lean, etc.), recopiladas por los gestores de los procesos, se agrupan para organizar-
las en un plan consolidado. Así, la mejora continua de la gestión del servicio se rea-
liza de una forma coordinada por un responsable único de esta actividad. En la
figura 4.16 se muestra la agrupación de las propuestas de mejora en un plan unifi-
cado común a toda la organización de TI.
Resumen
La implementación de sistema de gestión del servicio de TI (SGSTI) está bien
especificada en las Normas ISO/IEC 20000 y debe seguir las 4 etapas del ciclo de
mejora continua de Deming (PDCA). En la figura 4.17 se muestra de nuevo la
aplicación de estas 4 etapas al SGSTI.
Beneficios
La implantación de la gestión del servicio de TI siguiendo el ciclo PDCA y los
requisitos especificados y recomendados en las Normas ISO/IEC 20000, aportarán
entre otros, los beneficios siguientes:
• Permitirá que todas las actividades de transformación de la organización se
lleven a cabo de una forma controlada y organizada.
• Los objetivos se fijan en función de la situación de partida, obtenida
mediante una evaluación inicial.
• Los proyectos de implementación tienen unos objetivos fijados.
• Se monitorizan y miden los resultados de los proyectos.
• Se establece un plan de mejora continua.
• Se aprovecha la experiencia de otras organizaciones que iniciaron antes el
camino.
146 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Figura 4.18. Ejemplo de actividades y técnicas asociadas a cada etapa del PDCA
PDCA
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Cómo se aplica el ciclo PDCA en su organización?
• ¿Cuál es la secuencia de implantación de los procesos que más se
adecua a su caso particular?
• En función de su experiencia, ¿qué otras recomendaciones de imple-
mentación añadiría a este capítulo?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
5
Capítulo 5
Planificación e implementación
de nuevos servicios o de
servicios modificados
Las organizaciones de TI, y las actividades que desarrollan, han sido tradicional-
mente vistas como un soporte interno al negocio, descuidando en general el uso de
criterios apropiados para medir su rentabilidad, eficacia y la calidad del servicio
ofrecido a toda la organización. Actualmente el entorno donde nos movemos, en el
que los horarios de disponibilidad de los servicios son cada vez más amplios, donde
las exigencias del cliente son cada vez más elevadas, y donde los cambios en el
negocio son cada vez más rápidos, es muy importante que los sistemas de informa-
ción estén adecuadamente organizados y alineados con la estrategia de la empresa.
La “planificación e implementación de nuevos servicios o de servicios modifica-
dos”, tiene la misión de garantizar que los servicios se puedan crear y entregar con
la funcionalidad, costes, calidad y plazos acordados con los clientes. Para ello hay
que gestionar el ciclo completo de la provisión y entrega de los servicios, realizando
una planificación unificada e integrada, asegurando que todas las partes implicadas
conocen y cumplen con el plan y los compromisos acordados.
En este capítulo se presenta una visión de este proceso, con un alcance más allá de
lo establecido en estas normas, definiendo el marco de un proceso nuevo que está
presente a lo largo de todo el ciclo de vida de la provisión de un servicio: desde la
elaboración de la propuesta de servicio, hasta la revisión después de su implanta-
ción, en el entorno de producción real. El proceso recorre y organiza con eficiencia
a toda la organización de TI, sirviendo como integración entre la estrategia del
negocio, el desarrollo de aplicaciones, el departamento de explotación o produc-
ción, y el área de planificación y control económico de TI.
Para las empresas que ya tengan implementada una metodología o un proceso de
gestión de los proyectos para el desarrollo de aplicaciones, este capítulo les apor-
tará nuevos puntos de mejora para incorporar y con ello enriquecer y complemen-
tar la metodología ya implementada, facilitando así la integración con los nuevos
procesos de gestión del servicio. Por tanto, este proceso utiliza las metodologías y
procesos existentes en la organización para cubrir parte de sus etapas. En este capí-
tulo no se aborda la descripción de la etapa de construcción (software y hardware)
del servicio, ni en las metodologías gestión de proyectos TI (PMBOK, PRINCE2,
etc.), aunque éstas serán necesarias para gestionar los proyectos de creación de los
servicios. También sería necesaria la utilización de otros estándares y mejores prác-
ticas relacionados con el desarrollo de software (SPICE o CMMI).
El lector comprenderá mejor los detalles de este proceso cuando haya profundizado
en el resto de procesos de gestión del servicio, pues utiliza gran parte de ellos. En
realidad, el capítulo se debería haber ubicado de los últimos del libro, pero se ha
decidido mantener la posición que tiene en las normas para conseguir una numera-
ción de capítulos similar.
152 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
OPERACIÓN
MEJORA
CONSTRUCCIÓN
CONTINUA
Fuente: Telefónica.
Por tanto, este proceso es idóneo para la integración de las dos áreas de TI, tradi-
cionalmente separadas y mal engranadas: el desarrollo y la producción.
En la figura 5.5 se muestra un esquema global que integra el ciclo de vida ITIL v3,
con las etapas típicas de las metodologías de gestión de proyectos, los procesos de
desarrollo de software y la relación con el resto de los procesos de gestión del servi-
cio de TI contemplados en ISO/IEC 20000.
La creación y evolución de servicios orquesta una “cadena de fabricación” en TI,
que comienza con los requisitos del negocio y termina con los servicios operativos.
En un extremo de la cadena de fabricación está la necesidad del cliente de nuevas
funcionalidades de negocio y, en el otro extremo, se obtiene el servicio entregado y
operativo. El cliente, tras el tiempo acordado, espera recibir el servicio pactado que
cumpla con la funcionalidad, los costes y los acuerdos de servicio establecidos al
inicio del proceso. Justo entre estos dos extremos, es necesario desarrollar toda una
5. Planificación e implementación de nuevos servicios o de servicios modificados 157
Fuente: Telefónica.
Cada uno de los otros procesos que participan en la cadena tiene unos objetivos
específicos y su propio aporte a la construcción del servicio final. Aunque estos
procesos no se han tratado todavía en este libro, es conveniente tener una visión
general de su participación en este proceso. A continuación, se detallan los prin-
cipales:
Relaciones con el negocio. Su objetivo es establecer y mantener una buena rela-
ción entre el proveedor del servicio y el cliente, basándose en el entendimiento del
cliente y de los fundamentos de su negocio (véase el capítulo 7 para obtener más
detalles de este proceso).
El proceso de creación de servicios engrana con este proceso de relaciones para que
gestione todo el contacto necesario con las áreas de negocio. Su contribución se
centra en la toma de requisitos de las necesidades del cliente, la posterior negocia-
ción de la propuesta de servicio, la gestión del nuevo acuerdo de nivel de servicio y
el consenso con el cliente de la planificación para la creación del servicio realizada
por el proceso de creación. En su función “comercial”, durante el proceso de crea-
ción, se encarga de mantener informado al cliente y estar presente en las reuniones
de seguimiento, acompañando al jefe de proyecto. En la entrega, gestiona la parti-
cipación del cliente en las validaciones funcionales y en las reuniones para el cierre
del proyecto de creación.
5. Planificación e implementación de nuevos servicios o de servicios modificados 159
Hasta este punto se han podido observar los objetivos y ámbito de actuación de
este proceso de creación y modificación de servicios de TI. La figura 5.7 propor-
ciona un resumen de este proceso: una definición, el objetivo formalizado en las
Normas ISO/IEC 20000 y las principales aportaciones del proceso.
Los principales factores clave en torno a los que se articula este proceso se resumen en:
• Cumplimiento de los plazos, atendiendo a la agilidad y tiempo de respuesta
de la organización de TI ante necesidades del negocio.
• Cumplimiento de la funcionalidad demandada.
• Gestión eficiente de los costes.
• Cumplimiento de las políticas establecidas en TI, tanto para la construcción
del servicio y de sus componentes, como para la articulación de su puesta en
producción.
• Velar por la calidad necesaria demandada por el negocio.
• Integración de las soluciones en las arquitecturas TI existentes, tanto de:
datos, de aplicaciones, de componentes, tecnológica de hardware-software, de
seguridad, etc.
En la figura 5.8 se resumen estos factores clave que estructuran y rigen la actividad
de este proceso en las relaciones intensas y constantes con los intervinientes en la
creación o evolución de un servicio TI.
Cliente
Servicio
Requisitos
del servicio Planificación Informe
del proyecto de pruebas
Políticas, procesos desarrollo de software,
metodología gestión de proyectos
Especificaciones
técnicas
y arquitecturas
de servicio
OLA y UC
Acuerdos internos con áreas,
procesos, funciones
Propuesta
y suminstradores
de servicio
Lista de
cambios
Solicitud
RFC planificados
SLA de cambio
(FSC)
Figura 5.9. Componentes principales de las etapas de diseño y transición del proceso
164 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
internas (OLA) y externas (UC) intervinientes, sobre la aportación que cada uno
va a realizar a la provisión e implantación del servicio. Esta planificación del pro-
yecto esta sujeta al control del cambio.
Solicitud de cambio (RFC, Request For Change). Formulario utilizado para pro-
poner un cambio en cualquier componente de la infraestructura de TI o en cual-
quier aspecto de un servicio de TI. En este caso contempla la creación de un servi-
cio o la modificación de uno existente.
En la RFC se reflejan la naturaleza, los detalles, la justificación y la autorización del
cambio propuesto. La RFC va actualizándose a lo largo de la vida de la creación
del servicio. La RFC se describe en el apartado 9.2 de este libro.
determinar si la necesidad del cliente está cubierta por el catálogo; las políticas,
metodologías de gestión de proyectos y las arquitecturas TI con el fin de que la cre-
ación del nuevo servicio sea acorde con todo lo dictado en la organización; los
SLA, OLA y UC existentes; y la CMDB para proveer todo tipo de información
sobre TI y sus elementos de configuración.
Las actividades principales que realiza este proceso son:
• Gestión de la demanda, realizada por relaciones con el negocio (cliente) para
profundizar en sus necesidades, determinación de si éstas están en el catálogo
de servicios, y su encaje en las previsiones presupuestarias y en el porfolio de
servicios.
• Establecimiento de los requisitos del servicio por parte del cliente (SLR).
• Realización, si procede, del análisis de viabilidad (TCO y ROI).
• Elaboración de las especificaciones técnicas del servicio, que incluye su arqui-
tectura y el diseño funcional y técnico.
• Elaboración de la propuesta del servicio y del SLA.
• Realización del plan de proyecto para la creación del servicio.
• Revisión y formalización de acuerdos internos y contratos (OLA y UC).
• Confección de la solicitud de cambio (RFC) y aprobación de la creación del
servicio. Dar la orden del inicio de la construcción del servicio.
• Seguimiento del proceso de construcción.
• Realización de la integración y pruebas del servicio construido, en el entorno
de pruebas-integración.
• Aprobación de la implantación del servicio por gestión del cambio.
• Realización de la implantación y despliegue del servicio.
• Revisión post-implantación.
• Comunicación de los resultados a todas las partes interesadas.
• Cierre de la implantación y de la solicitud de servicio.
Las salidas principales del proceso son: el servicio operativo y listo para que pro-
vea las funcionalidades al negocio especificadas; todo tipo de documentación aso-
ciada necesaria (de usuario, para las áreas técnicas, de soporte para la atención de
incidentes y peticiones del usuario, etc.); el servicio cargado en las herramientas
de autorresolución al usuario; y las contrataciones necesarias realizadas (para la
5. Planificación e implementación de nuevos servicios o de servicios modificados 169
Gestión demanda.
Necesidades frente a
catálogo de servicios Análisis de viabilidad
Requisitos de servicio Especificaciones técnicas • Aprobación preliminar
del cliente (SLR) del servicio (SS)
Negociación propuesta Propuesta del servicio y SLA
servicio y SLA
Acuerdo con el cliente Plan de proyecto del servicio
Revisión y formalización de • Aprobación del RFC de
acuerdos y contratos (OLA, UC) creación/evolución
del servicio
Confección solicitud • Aprobación planificación
de cambio (RFC) • Inclusión en FSC
Orden de construcción • Gestión del cambio
Construcción del servicio. Pruebas del servicio (por otros procesos y departamentos TI)
Fuente: Telefónica.
Estas especificaciones describen con detalle lo que el cliente desea y cual es el impacto
que tiene en la organización TI, su provisión, implantación y operación. Este docu-
mento de uso interno no necesita ser firmado por el cliente, pero si está sujeto al con-
trol documental establecido por el sistema de gestión del servicio de TI (SGSTI).
172 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
1. Introducción
• Objetivo y alcance.
• Nombre del cliente/SLR de referencia.
2. Descripción del servicio
• Nombre del servicio, objetivos y alcance.
• Requerimientos de alto nivel:
– Funcionalidad.
– Horario de servicio y soporte.
– Disponibilidad, fiabilidad y continuidad.
– Rendimiento y volúmenes.
– Interfaces, etc.
3. Estructura y propuesta de nivel de servicio
4. Planificación
• Fecha requerida de disponibilidad del servicio.
• Duración del servicio.
5. Relaciones con otros elementos de configuración
• Servicios, componentes hardware y software.
6. Unidades involucradas la creación del servicio
• Nombre del departamento, responsable, datos
de contacto y requerimientos técnicos, humanos
y económicos asociados.
7. Servicios impactados
• Nombre del servicio y descripción del impacto.
UNE-ISO/IEC 20000-1
1. Objetivos y alcance.
2. Descripción del servicio:
• Funcionalidad.
• Seguridad y continuidad.
3. Estimación de recursos necesarios del cliente.
4. Estimación de plazos de creación y entrega.
5. Estimación de costes asociados.
6. Impacto y modificaciones a contratos y acuerdos
existentes.
7. Propuesta SLA:
• Compromisos de prestación regular del servicio en
términos medibles.
• Indicadores y métricas de gestión del
cumplimiento.
• Mecanismos de control y seguimiento de la
evolución de los niveles de servicio acordados.
8. Criterios de aceptación del servicio.
9. Participantes y sus responsabilidades en las
actividades de creación, implantación, operación
y evolución de los nuevos servicios. Contemplar
las actividades a llevar a cabo por los clientes y
el proveedor de servicio TI.
El SLA del servicio describe las condiciones de la prestación regular del mismo
durante el tiempo que dure el acuerdo. Contiene los compromisos de TI y del cliente
para prestación del servicio y será la referencia que se utilizará por las dos partes para
medir la prestación del servicio. En el ámbito de este proceso se formaliza el SLA,
pero su realización corresponde al proceso de gestión de nivel de servicio (SLM),
trabajando para este proceso. Este punto se trata detalladamente en el apartado 6.1.
La propuesta de servicio describe en términos de negocio “qué” se entregará al
cliente y “cuándo”; y el SLA contiene los compromisos de ambas partes para la
prestación habitual del servicio. Estos documentos constituyen el medio por el que
5. Planificación e implementación de nuevos servicios o de servicios modificados 175
las dos partes, cliente y proveedor de servicios TI, pueden medir los compromisos
tanto del cumplimiento de la creación del servicio como los de su prestación regu-
lar durante su vida útil.
UNE-ISO/IEC 20000-1
1. Introducción:
• Objetivo y alcance.
• Clientes, SLR y SLA de referencia.
• Fecha de inicio servicio.
2. Procesos y departamentos involucrados:
• Nombre del departamento.
• Persona y datos de contacto.
• Participación requerida.
3. Descripción de los niveles de soporte necesarios:
• Niveles de soporte requeridos de los procesos
(incidentes, disponibilidad, capacidad, gestión
del cambio, gestión de presupuestos y costes de
servicios TI, etc.).
• Niveles de soporte requeridos a los
suministradores externos y a otros departamentos
de TI.
4. Planificaciones de trabajo:
• Objetivos y alcance.
• Planificación de trabajo de cada departamento,
y/o proceso, de TI (desarrollo de aplicaciones,
operación de servicio, etc.).
• Descripción de actividades.
• Cambios necesarios (descripción y justificación).
• Recursos necesarios.
• Estimación de esfuerzo y costes asociados.
Figura 5.14. Contenido tipo del plan de proyecto de creación del servicio
analizado por este proceso para determinar si supone un impacto potencial en los
compromisos adquiridos con los clientes.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
Los nuevos servicios, o las modificaciones en los existentes, deben ser aceptados por el
proveedor del servicio antes de ser implementados en el entorno de producción real.
Una vez finalizado el desarrollo y las pruebas del servicio, el proceso de gestión del
cambio toma el control para comprobar si se han cubierto todos los compromisos
reflejados en la RFC y someter a la aprobación del comité de cambios la implanta-
ción del servicio en el entorno de producción real.
La implantación del servicio en el entorno de producción real, la realiza el proceso
de gestión de la entrega (véase el apartado 10.1) bajo la supervisión de gestión del
cambio (véase el apartado 9.2).
UNE-ISO/IEC 20000-1
de las métricas de este proceso son similares a la de los procesos que utiliza, por lo
que no se repiten aquí. Únicamente se enumeran aquéllas que tienen un carácter
más global al proceso:
• Número de proyectos realizados.
• El “Time to market” de los proyectos o plazo medio desde el primer contacto
con el usuario hasta que el servicio se ha entregado y se está utilizando.
• Cumplimiento de los plazos acordados o porcentaje de cumplimiento de los
plazos previstos en cada proyecto.
• Alineación con el cliente, medida como el número de inconformidades (o
modificaciones) del cliente por proyecto y del usuario final con los nuevos
servicios.
• Calidad técnica, medida como el número de defectos encontrados en las
pruebas del servicio.
• Número de incidentes causados por los nuevos servicios o las modificaciones.
• Cumplimiento de los costes acordados en los proyectos.
• Volumen medio de recursos utilizados. Número medio de horas/hombre
dedicados por proyecto.
• Calidad de las previsiones, medida como el número o coste de los nuevos
servicios no previstos en los planes anuales (porfolio de servicios, presu-
puestos, etc.).
Siguiendo los principios de COBIT, las métricas se estructuran en tres capas: una
primera capa con las métricas que aportan una visión al negocio de cómo está TI,
denominadas KGI de TI (KGI, Key Global Indicador); una segunda capa destinada
a la visión que el director de sistemas de información debería tener sobre el pro-
ceso, denominadas KGI del proceso. Por último, para mostrar los detalles internos
del proceso al responsable del proceso estaría la tercera capa, los KPI del proceso
(KPI, Key Performance Indicador).
En el gráfico de la figura 5.15 se muestra un resumen de los indicadores más rele-
vantes de este proceso.
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
• El propietario del modelo SGSTI, que actúa como propietario del proceso
(process owner), define el proceso y se encarga de la mejora continua del
mismo. Todo ello de una forma integrada con el modelo de gestión de TI
incorporado en el SGSTI.
• El responsable de la gestión del cambio, ya que debe autorizar el inicio de las
pruebas e integración, la implantación en producción y el cierre de la entrega.
Responsable de la
gestión del servicio
SGSTI
Gestor de la
creación de servicios
Administrador y
soporte del proceso
Propietario del
modelo (SGSTI)
Resumen
La creación de servicios se ha convertido en un factor clave para lograr el éxito
empresarial. El proveedor de TI debe posibilitar un tiempo de entrega de servicios
(time-to-market) acorde a las necesidades del cliente, pero también debe contemplar
que los costes, la funcionalidad y calidad de los servicios estén ajustados a sus nece-
sidades reales.
Las principales responsabilidades que tiene a su cargo el proceso se indican en la
figura 5.17.
correcto entre la demanda del cliente, la provisión del servicio, el coste de los mis-
mos y la satisfacción del cliente.
Para finalizar este capítulo, es importante destacar que este proceso es complejo y
soporta múltiples relaciones, por lo que el uso de las herramientas adecuadas es un
punto que no se debe descuidar. La disponibilidad de herramientas específicas (catá-
logo de servicios actualizado, formularios de recogida de requerimientos y especifi-
caciones SLR, SS, modelos de SLA/OLA/UC, un sistema de gestión documental,
etc.) pueden ser el elemento clave para el éxito de este proceso y, por tanto, para el
éxito de TI en la provisión de servicios nuevos o modificados.
Beneficios
La planificación e implementación de servicios nuevos o de servicios modificados
posibilita una mayor confianza en la relación TI-Negocio, y un incremento de
la satisfacción de los clientes, gracias a la transparencia y claridad de las propuestas
de los servicios que se van a proveer e implantar, ya que están realizadas con el
compromiso de todas las partes implicadas y alineadas con las necesidades de nego-
cio planteadas por el cliente.
También contribuye a mejorar esta relación la fiabilidad que proporciona la planifi-
cación integrada de todas las áreas y procesos TI intervinientes que permite asegu-
rar que una petición es viable, que la relación calidad-precio es adecuada, que está
alineada con la estrategia de negocio y técnica. También contribuye a agilizar y ase-
gurar el time to market de provisión de soluciones, minimizando los riesgos relacio-
nados con el cumplimiento de plazos y costes asociados.
Los principales beneficios que se obtienen al implementar este proceso son:
• Los servicios TI se diseñan para satisfacer las necesidades reales del cliente.
• La relación con el cliente se basa en “servicios” que TI proporciona, y en el
lenguaje y términos del negocio.
• Se atienden las demandas del negocio convirtiéndolas en servicios, de acuerdo
con la estrategia y los presupuestos.
• La organización de TI y sus clientes tienen unas expectativas claras y consis-
tentes del servicio solicitado a TI.
• Gestión formalizada de los requisitos del cliente, en su propio lenguaje.
• Control del ciclo completo, e integrado, de creación y modificación de los
servicios, desde la perspectiva de las necesidades y acuerdos con el cliente,
hasta su entrega y puesta en funcionamiento operativo.
5. Planificación e implementación de nuevos servicios o de servicios modificados 189
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Cuál es la operativa habitual para la creación de servicios TI en su
organización?
• ¿Cómo se validan las propuestas de nuevos servicios?
• ¿Qué mejoras incorporaría al proceso propuesto en este capítulo?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
6 Procesos de
provisión de servicio
Capítulo 6
99,99%
6.3. Gestión de la continuidad y 6.6. Gestión de la seguridad
disponibilidad del servicio de la información
Una vez creado el servicio y puesto con éxito en explotación regular, es necesario
desencadenar una serie de actividades que ayuden a garantizar que los servicios cum-
plen los cometidos pactados con el negocio en términos de: los niveles de servicio,
la continuidad, la disponibilidad, los presupuestos, la capacidad y la seguridad.
Además de velar por la consecución de lo comprometido, también se debe estar
involucrado en asegurarse que los nuevos servicios o la evolución de los mismos se
realiza cumpliendo con lo que la organización ha predefinido.
Para garantizar que se cumplen estos objetivos se han definido los procesos de
provisión del servicio, seis procesos especializados que engranan con las relacio-
nes con el negocio y con la creación de servicios. En la figura 6.1 se muestran
estas relaciones.
Gestión de la capacidad
Gestión
de nivel de
servicio
Gestión de la continuidad y
disponibilidad de servicios TI
En este escenario de servicios de alta calidad, alineados con los objetivos del nego-
cio, que cubren las necesidades actuales y que deben ser capaces de evolucionar
rápidamente para cubrir las necesidades futuras, los procesos de la provisión del
servicio toman una especial importancia.
194 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Los procesos de provisión del servicio en ISO/IEC 20000 contienen una impor-
tante diferencia frente a lo definido en ITIL v2, pues incorpora la generación de
informes de servicio como un proceso independiente e incluye también el proceso
de seguridad de la información. Además, agrupa en uno sólo los procesos de conti-
nuidad y de disponibilidad (que en ITIL v2 están separados).
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 195
Analizando ITIL v3, se aprecia que aparecen la gestión del catálogo de servicios y
la gestión de suministradores como procesos nuevos que restan peso a la gestión
de nivel de servicio definida esta nueva versión de ITIL.
Por tanto, el panorama entre estos tres modelos queda algo intrincado. En la figura
6.1.2 se muestra una comparativa entre los alcances asignados a este proceso en los
diferentes marcos.
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 197
El proceso debe ser capaz de comprender las demandas del negocio, aunque en
ISO/IEC 20000 no lleva propiamente las relaciones con el negocio (véase el apar-
tado 7.2). Se relaciona internamente con el resto de unidades de TI para negociar y
198 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
fijar los acuerdos operativos. También establece los requisitos para que los contra-
tos de soporte con los suministradores estén alineados con los compromisos del
servicio, contratos que negociará y seguirá el proceso de gestión de suministrado-
res (véase el apartado 7.3).
En la figura 6.1.4 se muestran los principios básicos en los que se sustenta la activi-
dad de este proceso.
Catálogo
de servicios Supervisión
Cultura del servicio
de servicio y de los SLA
Mejoras
Acuerdos de nivel
de servicio (SLA)
Programa de
mejora del
Acuerdos de nivel Gestión de nivel servicio (SIP)
de operativo (OLA) de servicio
Cultura de
compromiso
Mejora
del proceso
Las salidas principales del proceso son el catálogo de servicios creado, actualizado y
publicado a los usuarios (vía web); los acuerdos de nivel de servicio nuevos o
actualizados firmados; el o los programas de mejora del servicio, que se remitirán
al comité de cambios (CAB) y al plan de mejora unificado de los procesos y de los
servicios (véase el capítulo 4).
Las salidas secundarias del proceso son los acuerdos de nivel operativo internos
nuevos o actualizados; la definición de requisitos para los contratos de soporte para
la gestión de suministradores; las especificaciones sobre los contenidos necesarios
sobre los informes de los servicios, tanto para el uso interno del proceso, como para
su publicación al resto de TI y al cliente; las peticiones de cambio necesarias para la
aprobación de las modificaciones a realizar; y por último, la CMDB actualizada con
los cambios en el catálogo, en los SLA, etc.
El catálogo de servicios de TI
El catálogo de servicios es el instrumento de relación más importante de TI con sus
clientes, ya que en él se recoge el conjunto total de los servicios que la organización
de TI provee a sus clientes. El catálogo es una excelente herramienta para ayudar
en el cambio cultural del proveedor de servicios de TI hacia objetivos como:
• Alineamiento con el negocio. Aportando valor añadido al conocer de
forma clara y precisa los servicios de TI que soportan su negocio.
• Orientación al cliente. Estructurando la misión y el trabajo de TI en torno
a la satisfacción de las necesidades del cliente en forma de prestación de
servicios.
• Calidad de servicio. Contemplando los indicadores y métricas que consti-
tuyen la base de los acuerdos de nivel de servicio (SLA).
• Gestión de los servicios. Facilita la gestión y control de los niveles de servi-
cio comprometidos con los clientes, posibilitando medir en términos que el
cliente entiende. Estas medidas permiten pasar de medir “percepciones” a
tener métricas entendidas y acordadas por las dos partes.
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 205
UNE-ISO/IEC 20000-1
Se deben acordar por las partes, y registrar, el conjunto total de los servicios a ser
provistos, junto a los correspondientes objetivos de nivel de servicio y las característi-
cas de la carga de trabajo que deben soportar.
UNE-ISO/IEC 20000-2
Todos los servicios deberían estar defini- b) los objetivos (por ejemplo tiempo de res-
puesta o de instalación de una impre-
dos en un catálogo de servicios. Este sora, tiempo para reiniciar un servicio
catálogo puede ser referenciado desde tras un fallo importante),
el SLA y debería utilizarse para recoger c) datos de contacto,
aquellos aspectos considerados como d) horario del servicio y excepciones,
demasiado cambiantes para ser intro- e) disposiciones de seguridad.
ducidos en el SLA.
El catálogo de servicios es un docu-
El catálogo de servicios debería ser mento clave para establecer las expec-
mantenido y estar actualizado en todo tativas del cliente y debería ser fácil-
momento. mente accesible y estar ampliamente
Nota: El catálogo de servicios puede incluir infor- disponible tanto para los clientes como
mación genérica como: para el personal de apoyo.
Con el fin de describir de forma detallada y homogénea todos los servicios que
oferta TI, se debe establecer una plantilla documental que servirá de base para defi-
nir todos los servicios. Esta ficha tipo suele estructurarse en dos partes: una que
contiene los aspectos de interés para los clientes y usuarios, y otra que incorpora
detalles sobre los servicios internos de TI, que no se muestra a los usuarios. En la
figura 6.1.8 se presenta un ejemplo de la estructura de una ficha de servicio.
Es recomendable que el servicio se dé de alta en el catálogo tan pronto como se
conozcan los datos básicos del mismo, sin esperar a que esté operativo. De esta
forma, toda la comunidad de usuarios y los profesionales de la organización de TI
conocerán de primera mano los servicios que están en fase de definición y acuerdo.
Para gestionar correctamente las expectativas y no crear conflictos o malos entendi-
dos, se utiliza la información de estado del servicio (véase la figura 6.1.9). Esta
información debe contener las etapas del ciclo de vida de los servicios, desde su
petición hasta su retirada de la operación.
208 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• Definición.
• Funcionalidades del servicio.
Ficha de un servicio de TI • Opciones de contratación.
• Condiciones de uso.
Fuente: Telefónica.
Estados de un servicio
Requerimientos
Definido
Analizado
Aprobado
Dotado
Diseñado
Desarrollado
Construido
Probado
Desplegado
Operativo
Retirado
Una vez que se define o se actualiza el catálogo, se debe generar una nueva versión
del mismo. Esta nueva versión se debe publicar en la organización TI, distribuida a
los gestores de las relaciones con el negocio y clientes para publicitar y dar a cono-
cer todos los servicios disponibles, poniéndolo accesible a los usuarios (vía web).
El catálogo de servicios requiere un mantenimiento y una actualización periódica,
incorporando los nuevos servicios o las modificaciones a los existentes. Todo cam-
bio en el catálogo debe realizarse bajo el control del proceso de gestión del cambio.
UNE-ISO/IEC 20000-1
Cada servicio ofrecido se debe definir, acordar y documentar en uno o más acuer-
dos de nivel de servicio (SLAs).
Se deben acordar y registrar por todas las partes relevantes los SLAs, junto con los
acuerdos de servicios de soporte, los contratos con suministradores y los correspon-
dientes procedimientos.
Los SLAs deben estar bajo el control de la gestión del cambio.
210 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-2
El contenido del SLA debe identificar claramente a todos los intervinientes del
acuerdo de servicio: el cliente, los usuarios, las distintas áreas de la organización TI
involucradas en la prestación del servicio; así como las características del servicio a
prestar: los horarios de disponibilidad del servicio, los tiempos de respuesta, los
plazos de resolución en caso de incidente, etc.
En relación a los horarios de disponibilidad del servicio se deben definir los tramos
horarios en los que habitualmente se utiliza el servicio, por ejemplo: 7 x 24 horas,
de lunes a viernes de 8:00 a 18:00 h, etc. Además, es importante incluir directrices
para posibles ampliaciones del mismo, que contemplen el tiempo de preaviso nece-
sario (por ejemplo, esta solicitud se debe realizar al servicio de asistencia técnica
antes de las 12 AM para una ampliación del servicio por la tarde, antes de las 12 del
jueves para una ampliación el fin de semana). También se incluyen horarios espe-
ciales como en períodos de vacaciones, etc., y un calendario anual del servicio en el
caso de variaciones de las condiciones del servicio, como en campañas de Navidad,
en verano, etc.
La disponibilidad del servicio es uno de los parámetros que más impacta en el nego-
cio y uno de los más famosos en el SLA. Se definen los objetivos de disponibilidad
de los servicios dentro del horario acordado, normalmente expresados en términos de
porcentajes (99%, 99,8%, 99,99%, etc.); se incluye también el período y el método
de medida.
212 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
En el caso del procesado por lotes, se establece la ventana de tiempo para la ejecu-
ción de trabajos batch (normalmente en horario nocturno), se acuerda el porcen-
taje de finalización correcta de los trabajos, el lugar para obtener y entregar los
resultados, los interlocutores por ambas partes, etc.
También se debe contemplar las condiciones relativas a la capacidad soportada por
el servicio, como son los límites de la carga de trabajo, el número de usuarios, capa-
cidad de procesamiento del sistema, los volúmenes de tráfico de comunicaciones,
el número pico de transacciones que será necesario procesar y el número máximo
de usuarios en concurrencia. Esto es importante para poder identificar las deficien-
cias en el rendimiento o el incremento de costes debido a la necesidad de ampliar la
capacidad del servicio o del número de licencias de software.
En relación a los cambios al SLA, es importante identificar los criterios para reali-
zarlos y los interlocutores necesarios para aprobar, gestionar e implementar las peti-
ciones de cambio (RFC) relacionadas con el servicio. Normalmente los criterios se
basan en la categorización y urgencia, o impacto del cambio.
Los aspectos de la continuidad ante desastres y seguridad del servicio también son
temas para analizar e incorporar al SLA:
• Se debe contemplar si el servicio está sujeto a planes para la continuidad de
los servicios TI, describiendo brevemente las condiciones que marcan la acti-
vación del plan y cómo ponerlo en marcha.
• Detalles de los objetivos de servicio reducidos o modificados en caso de
desastre (si no existe un SLA específico para tales situaciones).
• Información relacionada con la seguridad, especialmente aquellos aspectos
que sean responsabilidad del cliente (por ejemplo, copias de seguridad, cam-
bios de contraseña, etc.).
En el acuerdo de servicio es importante recoger los detalles sobre los costes, perío-
dos y fórmulas de facturación (si se factura).
Se deben detallar los contenidos, frecuencia y distribución de los informes, así
como, la frecuencia de las reuniones para la revisión del servicio.
En la figura 6.1.10 se muestran los conceptos que se deben incluir en un SLA, ali-
neados con las recomendaciones de la Norma ISO/IEC 20000-2.
El acuerdo de nivel de servicio es el contrato que TI firma con sus clientes, en torno
a este acuerdo todas las áreas y procesos de la organización deben enfocar su activi-
dad para velar por su cumplimiento.
214 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Según ITIL, hay diversas formas de establecer los SLA: basado en el servicio,
basado en el cliente y multinivel.
SLA basado en el cliente. Soporta un acuerdo con una área cliente específica, que
cubra todos los servicios que utilizan. Por ejemplo, se puede llegar a acuerdos con
el departamento de finanzas de una organización para cubrir, por ejemplo, el sis-
tema financiero, el de contabilidad, el de nóminas, la facturación y otros servicios
que utilicen.
A menudo, los clientes prefieren este acuerdo, ya que cubren todos sus requisitos
con un solo documento. Sólo se requiere una firma, lo que simplifica su gestión y
evolución posterior.
Nivel corporativo
UNE-ISO/IEC 20000-2
En relación a la gestión del SLA los principales temas a tener en cuenta son:
Redacción de los acuerdos. La redacción de los SLA deberá ser clara y concisa,
sin dejar lugar a la ambigüedad. Generalmente no es necesario que los acuerdos
estén redactados utilizando una terminología legal; en realidad la utilización de
un lenguaje claro ayudará a una mejor comprensión. Como comprobación resulta
muy útil que una persona independiente, que no esté implicada en la redacción
del documento, realice una lectura final del mismo. Esta revisión suele poner de
218 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
manifiesto las posibles ambigüedades y dificultades, lo que nos permite tomas las
medidas oportunas de revisión y aclaración.
También merece la pena recordar que los acuerdos de nivel de servicio pueden dar
cobertura a los servicios ofrecidos a diferentes comunidades lingüísticas, por lo que
es necesario contemplar la disponibilidad de los SLA en los diferentes idiomas. En
este aspecto hay que dedicar un especial cuidado a la terminología, ya que un SLA
puede revisarse en diferentes países y, por tanto, puede ser necesario considerar los
aspectos de terminología, estilos y diferencias culturales.
Firma del acuerdo. Este aspecto es esencial para que el SLA acordado tenga la
suficiente credibilidad por las dos partes, por lo que hay que garantizar que al tér-
mino del proceso de redacción y negociación, el acuerdo de nivel de servicio sea
firmado por los cargos apropiados, tanto del lado del cliente como del proveedor
de TI.
Esto garantizará el compromiso de que ambas partes intentarán hacer todo lo que
sea posible para cumplir los SLA firmados. De forma general, cuanto más alta sea
la jerarquía de los firmantes, mayor será esta garantía.
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 219
Una vez firmado y cerrado el acuerdo de nivel de servicio se debe formalizar den-
tro de la organización TI como un activo más, y por tanto estará sujeto al control
de gestión del cambio, mediante la correspondiente formalización de una petición
de cambio. A partir de este punto, cualquier modificación estará sujeta a la gestión
y aprobación del proceso de gestión del cambio.
Difusión de los SLA. Una vez cerrado el SLA, es fundamental utilizar una buena
promoción y difusión que permita asegurar que los clientes y las diferentes áreas del
proveedor de servicios TI están enterados de su existencia y de los objetivos clave.
En este punto es clave que el centro de servicio al usuario tenga conocimiento de
los contenidos de los SLA, ya que es el primer punto de contacto de los incidentes,
consultas y quejas de los clientes. Si el personal del centro de servicio al usuario no
está bien informado de los SLA en vigor y no actúa en consecuencia, los clientes
perderán rápidamente su confianza en estos acuerdos.
Revisión de los SLA. Los acuerdos del nivel de servicio deben revisarse periódica-
mente con los clientes para garantizar si aún son validos y adecuados a las necesida-
des del negocio y las capacidades de la organización TI, por ejemplo, anualmente
en línea con el ciclo financiero.
UNE-ISO/IEC 20000-1
Los SLAs se deben revisar periódicamente por las partes, para asegurar que se
encuentran actualizados y continúan siendo eficaces con el transcurso del tiempo.
estén consiguiendo los objetivos. Todas las medidas acordadas se deberían registrar
en las actas, y se debería revisar el progreso y los resultados obtenidos en la
siguiente reunión.
UNE-ISO/IEC 20000-2
Los servicios de soporte de los cuales trador de servicios. Esto incluye los grupos
depende el servicio prestado se deberían internos que proveen parte del servicio
documentar y acordar con cada suminis- ofrecido por el proveedor del servicio.
Estructura de un acuerdo de
nivel operativo (OLA)
Introducción:
• Objetivo y alcance.
• SLA de referencia.
• Unidad TI que lo soporta.
Requerimientos:
• Acuerdos del servicio.
• Descripción del nivel de servicio (SLA).
• Plan de proyecto del servicio interno.
• Objetivo y alcance del servicio.
• Ámbito de aplicación.
• Funcionalidades proporcionadas.
Responsables involucrados:
• Responsable de planificación e implantación de
servicios nuevos o modificados.
• Responsable de gestión de nivel de servicio.
• Responsables de procesos/departamentos
afectados.
• Responsables de otros procesos/departamentos
involucrados.
Fuente: Telefónica.
Introducción:
• Objetivo y alcance.
• SLA y OLA de referencia.
• Nombre del suministrador. Unidad TI que lo soporta.
Requerimientos:
• Acuerdos de nivel de servicio (SLA) y
operativos (OLA).
• Plan de proyecto del servicio.
Condiciones comerciales:
• Coste del servicio y forma de pago.
Responsables involucrados:
• Responsable de planificación e implantación de
servicios nuevos o modificados.
• Responsable de nivel de servicio.
• Proveedores de servicios externos.
Fuente: Telefónica.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-1
Las acciones de mejora definidas durante este proceso se deben registrar y constitu-
yen una entrada al plan de mejora del servicio.
en todos los aspectos relacionados con la satisfacción de las necesidades del cliente
mediante servicios ya disponibles en el catálogo o mediante la confección o revi-
sión de los acuerdos del nivel de servicio. Una vez puesto en marcha el servicio, ges-
tión de nivel de servicio “rinde cuentas” al cliente sobre los niveles de servicio
alcanzados y analiza conjuntamente las opciones de mejora.
En el caso del proceso de planificación e implantación de servicios nuevos o modi-
ficados, la interrelación sigue un esquema similar: las relaciones con el negocio se
encargan de entender al cliente y el establecimiento de los requisitos, mientras que
la gestión de nivel de servicio proporciona un catálogo de servicios actualizado y la
definición del acuerdo de nivel de servicio (SLA).
El proceso de generación de informes del servicio produce los informes que nece-
sita la gestión de nivel de servicio para informar a los clientes y a TI sobre los nive-
les de servicio. Los informes deben contemplar información relevante de forma
que permita analizar aspectos clave del servicio, como su rendimiento, cargas
de trabajo, cumplimiento de los compromisos con los clientes (SLA), incidentes
graves, etc. Los informes deben servir para la gestión de los servicios y la defini-
ción de acciones correctoras y de mejora de los servicios.
El proceso de elaboración de presupuestos y contabilidad de los servicios de TI
proporciona la información económica necesaria para la toma de decisiones en
cuanto a los niveles de servicio y para que los compromisos se asuman con un
conocimiento preciso de los costes.
Con el resto de procesos, la gestión de nivel de servicio establece el valor de los
parámetros en SLA que se pueden cumplir por TI, para posteriormente realizar el
seguimiento de los mismos. Así, con la gestión de la continuidad y disponibilidad
se establecerán los umbrales de los SLA de emergencia y los valores de disponibili-
dad y de rendimiento de los servicios; con la gestión de la seguridad los temas rela-
tivos al nivel de seguridad a comprometer; con la gestión de la capacidad se defi-
nen las necesidades de proceso, almacenamiento, etc.
La relación con la gestión del cambio es de las más fundamentales, pues gestión de
nivel de servicio (como todos los otros procesos) no puede cambiar nada que no
esté validado por la gestión del cambio. Por ello, se deben generar peticiones de
cambio antes de crear un nuevo SLA o de modificar uno existente, así como para
ejecutar las modificaciones derivadas de los planes de mejora del servicio.
En relación con el área de desarrollo de aplicaciones, el proceso de planificación y
diseño de infraestructuras y el de operación del servicio, se tratan los requisitos a
cumplir por cada una para la satisfacción de los niveles de servicio. Los compromisos
con cada una de estas partes se formalizarán en un acuerdo de nivel operativo (OLA).
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 231
Figura 6.1.17. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 233
En la figura 6.1.18 se muestra un esquema con los roles para este proceso.
234 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Responsable de la
gestión del servicio
Responsable del
proceso SLM
Gestores del
nivel de servicio
Gestores de otros
procesos y áreas TI
SGSTI
Administrador
catálogo de servicios Administrador y
soporte del proceso
Propietario del
modelo (SGSTI)
Resumen
El proceso de gestión de nivel de servicio es clave para cumplir con las expectativas
de los clientes de TI, manteniendo y mejorando la estabilidad de los servicios ya
que regula y controla toda la cadena de aseguramiento de los acuerdos de nivel de
servicio firmados con los clientes.
El proceso mantiene la calidad y fiabilidad de los servicios, velando, tanto por la
creación de SLA fiables y acordes con las necesidades del negocio, como por el con-
trol y mejora reactiva/proactiva que permiten mejorar la calidad de la prestación de
los servicios de TI. Este proceso trabaja en estrecha colaboración con los procesos
y con las áreas técnicas.
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 235
Los principales elementos que componen el proceso son: el responsable del pro-
ceso, el catálogo de servicios, los SLA, los OLA, los UC y los programas de mejora
del servicio (SIP).
Beneficios
La mejora en la calidad y la reducción de las interrupciones del servicio, que aporta
una efectiva gestión de nivel de servicio, permite la obtención de ahorros económi-
cos significativos. Por un lado, el cliente puede realizar sus funciones de negocio de
forma predecible y minimizar el impacto negativo en sus actividades mediante el
cumplimiento de los acuerdos de servicio establecidos y la planificación de paradas
de mantenimiento del servicio, y por otro, la organización TI gastará mucho menos
tiempo y esfuerzo al tener menos incumplimientos de SLA que resolver.
Entre los beneficios de la gestión de nivel de servicio se pueden destacar:
• La prestación del servicio TI se diseña para satisfacer los requisitos del servi-
cio de los clientes.
• Permite mejorar las relaciones con los clientes.
• Las dos partes firmantes del SLA tienen una visión clara de sus funciones y
responsabilidades, evitando posibles omisiones o malentendidos.
• Se tienen objetivos específicos y acordados, con los que se puede comparar y
medir la calidad del servicio; “si no aspira a nada, probablemente eso sea lo
que consiga”.
• Permite centrar el esfuerzo en TI en los servicios clave para el negocio.
• La monitorización de los servicios facilita la identificación de áreas de debili-
dad, permitiendo emprender las acciones resolutivas que sean necesarias,
mejorando así la calidad de los futuros servicios.
• El seguimiento realizado por este proceso permite identificar fallos en los
servicios motivados por acciones de los usuarios, pudiendo definir acciones
de mejora, como por ejemplo, la formación.
• La actividad de gestión de nivel de servicio refuerza la gestión y relación con
las áreas internas de TI y con los suministradores externos gracias a su inte-
gración en la cadena de aseguramiento de los SLA de los clientes, “todos tie-
nen un objetivo común”.
• Los SLA constituyen el elemento básico para poder realizar la facturación de
los servicios TI a los clientes según los niveles de servicio requeridos.
236 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Cuál es la estructura del catálogo de servicios de su organización
deTI?
• ¿Cuál es la estructura de los SLA de su organización?
• ¿Cómo están estructuradas internamente las unidades o grupos de su
departamento de TI de cara a la realización de OLA?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
6. Procesos de provisión de servicio
6.2. Generación de informes del servicio 237
Para que la gestión del servicio aporte valor real a la organización de TI y al nego-
cio, debe disponer en tiempo y con calidad de la información que permita la
correcta toma de decisiones. La centralización de todos los informes en un único
punto aporta grandes ventajas en la realización de esta labor incomprendida, pues
responsabiliza a un proceso de la definición general de las políticas de informes y
de su generación. Los informes deben ser fiables, precisos y entregados a tiempo.
Los informes de TI destinados al negocio deben contener medidas significativas y
entendibles por él que permitan ayudarle a alcanzar sus objetivos estratégicos. La
precisión y fiabilidad de los valores aportados son clave en la relación con el cliente.
Asimismo, la puntualidad en la entrega de los informes de nivel de servicio, según
lo comprometido en los SLA, junto con los aspectos reseñados anteriormente,
aportan confianza al cliente en la relación.
240 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Los informes deben mantener una continuidad a lo largo del tiempo, represen-
tando conceptos similares y su evolución histórica. Para ello, disponer de un repo-
sitorio con todos los indicadores y sus mediciones será una de las primeras activi-
dades que se deben realizar. Para la creación de este repositorio o base de datos hay
varias alternativas, como utilizar la solución que habitualmente incorporan las
herramientas de gestión del servicio o como crear uno nuevo utilizando las herra-
mientas habituales de análisis de datos e inteligencia de negocio (data warehouse,
data mart, extracción de datos, etc.). En organizaciones pequeñas se puede empe-
zar con una simple hoja de cálculo.
Es importante que los informes reflejen la evolución histórica de los indicadores
que contienen, pues en la gestión del servicio de TI son tan esenciales las tenden-
cias como los valores puntuales de un período.
Los informes deben entregarse a tiempo, en el momento en que se necesiten, para
conocer la situación o para tomar decisiones. Para conseguirlo es necesario dispo-
ner de las herramientas adecuadas que faciliten la laboriosa tarea de su confección.
El cumplimiento sistemático en las fechas de entrega de los informes permitirá que
las decisiones se tomen a tiempo y marcará una pauta rítmica de trabajo en toda la
organización.
242 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Hechos
ocurridos Niveles
de servicio
Cuadros
de mando
Política Diseño de
de informes informes Realización Informes
de informes
KGI
Panel de
control
KPI
Indicadores
Arquitectura
de métricas
Monitorización
Base de datos de
indicadores y mediciones
Cuadro de mando integral (BSC, Balanced Score Card). Término difundido por
Kaplan y Norton para mostrar el estado de una empresa en base a objetivos e indi-
cadores agrupados en cuatro perspectivas: económica, cliente, interna y crecimiento.
6. Procesos de provisión de servicio
6.2. Generación de informes del servicio 243
Cuadro de mando de TI. Conjunto de indicadores que muestran una visión glo-
bal del estado de TI. Contiene indicadores globales. Resume en un informe los
indicadores más relevantes sin respetar las cuatro perspectivas clásicas de Kaplan y
Norton.
Indicador objetivo (KGI, Key Goal Indicator). Indicador que muestra una caracte-
rística clave o general. Término utilizado en COBIT. Se utiliza para determinar los
indicadores más importantes de TI (por ejemplo, el tiempo que se tarda en crear
un nuevo servicio de TI o “time-to-market”). Dado que la organización de TI suele
244 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
estar dividida por lo menos en tres áreas (desarrollo, sistemas o centro de proceso
de datos y microinformática o puesto de trabajo), los KGI se agrupan a su vez en:
• KGI-TI. Indicador objetivo general o común a todo el área de TI o indica-
dor de gobierno de las TI.
• KGI-CPD. Indicador objetivo del área de explotación de sistemas o del cen-
tro de proceso de datos (CPD).
• KGI-PT. Indicador objetivo del área del puesto de trabajo (PT) formado por
microinformática más las redes.
• KGI-DES. Indicador objetivo del área de desarrollo de aplicaciones.
Informe del servicio. Es un informe sobre los servicios que presta TI indicando
el grado de cumplimiento de los niveles de servicio, los hechos más relevantes en el
período con relación al servicio (incidentes, problemas, evolución, etc.).
Niveles de servicio. Son los valores mínimos o máximos de los indicadores pacta-
dos con el cliente que deben cumplir los servicios de TI prestados.
Políticas de informes. Documento que establece los principios que deben cumplir
los informes de una organización.
Las entradas de soporte que utiliza el proceso son los acuerdos de nivel de servicio,
que informan sobre los umbrales que se utilizarán en los informes; las estrategias
del negocio y de TI, para la confección de la arquitectura de métricas y el diseño de
los informes tipo; datos externos de benchmarking del mercado con ratios compara-
tivos, con el fin de comparar los valores de los indicadores internos con los externos.
Las salidas principales del proceso son: los cuadros de mando actualizados necesa-
rios (global de TI, del CPD, del Puesto, de Desarrollo, etc.); los informes del servi-
cio prestado; el panel de control de TI; otros tipos de informes sobre acciones, pro-
yectos, iniciativas, etc.; las políticas de informes generadas que marcan las
directrices del proceso.
Como salidas secundarias del proceso destacan: la base de datos de indicadores y
mediciones actualizada, el repositorio generado por el proceso que almacena los
datos necesarios para la confección de los informes; la propia arquitectura de métri-
cas creada y actualizada; las diversas plantillas que conforman los informes tipo; las
alertas generadas por haberse sobrepasado los umbrales de nivel de servicio, etc.
Las actividades del proceso son:
Definición de la política de informes. En la que se define el alcance del proceso,
las responsabilidades sobre los datos y los informes, su difusión, etc.
Hay que señalar que en numerosos casos, la implementación de éstas y otras herra-
mientas requeridas por el proceso de generación de informes de servicio se limitará
a establecer las interfaces con las herramientas ya implementadas dentro de otros
procesos (un caso general es la integración con las herramientas de monitorización
y operación).
Generación de informes. En esta actividad se generan los informes con los resul-
tados de los indicadores o métricas obtenidas. Los informes deben ser útiles y no
unos meros portadores de datos. Por ello, además de los datos, deben incorporar
análisis de la información, revisión de los resultados obtenidos, descripción de los
hechos relevantes en el período, etc. (aunque estos análisis, en muchos casos, este
proceso sólo se encargue de hacer que otros lo realicen). Como resultado de esta
actividad y, en función del destinatario y la periodicidad establecida, se generan los
informes del servicio. También es clave que los informes reflejen el resultado de la
comparación entre los valores de indicadores obtenidos y los valores objetivo o
umbrales de referencia.
La generación de informes toma como punto de partida los datos ya recopilados
en la base de datos de indicadores y mediciones, y de los informes tipo, para la
248 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
generación de los informes. En una primera fase, el proceso genera los informes en
modo borrador, para que sean completados y comentados por cada uno de los pro-
cesos o áreas involucradas. Por ello, esta actividad debe perseguir a los responsables
para que revisen y complementen con información estos borradores.
Supervisión del funcionamiento del proceso y mejora del mismo. Al igual que
en resto de procesos, el responsable del proceso debe supervisar la eficacia del pro-
ceso, la calidad de los datos contenidos y la entrega a tiempo de los informes.
Una de las facetas importantes de esta actividad es comprobar y conseguir que los
informes sean utilizados por sus destinatarios y que cumplan su misión de infor-
mación, seguimiento o ayuda a la toma de decisiones para los que fueron creados.
Es también responsabilidad de esta actividad impulsar en los otros procesos la
generación de los planes de mejora derivados del análisis de los informes. Un ejem-
plo claro de esto es el proceso de gestión de nivel de servicio, que vela por que se
subsanen de forma inmediata las roturas de niveles de servicio detectadas en los
informes, desarrollando las iniciativas de mejora. Además, dado que los informes
llevan también integrada la tendencia de evolución de los indicadores, se podrá
detectar anticipadamente el riesgo de incumplimiento de los niveles de servicio
para adoptar las medidas proactivas necesarias.
Todas las mejoras detectadas se incorporarán al plan general de mejora de TI, sin
que por ello, se dejen de ejecutar las acciones correctoras inmediatas.
UNE-ISO/IEC 20000-2
Política
Los requisitos para la generación de infor- tradores subcontratados por éstos, los
mes para clientes y para gestión interna informes deberían reflejar las relacio-
se deberían acordar y ser registrados. nes entre ellos. Por ejemplo, un sumi-
nistrador principal debería informar
La supervisión del servicio y la genera-
sobre la totalidad del servicio que
ción de informes abarcan todos los
presta, incluyendo cualquier servicio
aspectos medibles del servicio, propor-
realizado por un tercero y que forme
cionando datos actuales e históricos.
parte del que el suministrador principal
Cuando existan múltiples proveedores, gestiona como parte del servicio al
suministradores principales y suminis- cliente.
Cuadros
Tendencias de mando
Benchmarking
Gobierno
Informe mensual
ejecutivo
Verbal
Métricas servicio
Gestión
Alertas
Inventarios
Documentación Monitorización
Cualitativa Cuantitativa
Fuente: Telefónica.
En la figura 6.2.7 se muestra esta estructura por capas y el ámbito de cada indica-
dor (arquitectura de métricas) y su relación con los informes asociados.
Fuente: Telefónica.
• Intuitiva. Cada miembro expresa de forma intuitiva las métricas que consi-
dera más relevantes. La visión intuitiva es muy importante y se utiliza varias
veces en el ciclo de definición del mapa de indicadores.
• En base a un mix de experiencias (propias y ajenas). La experiencia y la
historia de los indicadores internos y los aportados por organizaciones exter-
nas, conforman la base para la primera propuesta.
• Seguimiento de COBIT al 100%. En este caso se toma el estándar COBIT
y de él se extraen indicadores.
• Seguimiento de ITIL al 100%. Al igual que en el caso anterior, ITIL se
toma como la única referencia.
• Mix de modelos: ITIL + COBIT. Se toman los procesos ITIL como base, y
se buscan indicadores proporcionados tanto por ITIL como por COBIT, o
bien que resulten complementarios a efectos de completitud de la información.
• Alineación con el negocio. El eje conductor de todo el ejercicio de selec-
ción de indicadores se articula en torno a la estrategia del negocio, identifi-
cando los objetivos de la empresa y los objetivos definidos de TI.
Perspectiva BSC
Tipos de objetivos de negocio en COBIT
del negocio
1 Expandir el porcentaje de mercado.
2 Aumentar el ingreso.
Perspectiva
3 Retorno sobre la inversión.
financiera
4 Optimizar el uso de recursos.
5 Administrar los riesgos del negocio.
Se pasa a la Etapa II, en la que se identifica la estrategia seguida por TI. Igualmente
el resultado es una lista corta de objetivos de TI. En la figura 6.2.11 se muestran
los objetivos tipificados en COBIT para los objetivos de TI.
6. Procesos de provisión de servicio
6.2. Generación de informes del servicio 257
1 Responder a los requerimientos del negocio en alineación con la estrategia del negocio.
2 Responder a los requerimientos de gobierno en línea con el consejo de dirección.
3 Asegurar la satisfacción de los usuarios finales con los servicios y niveles de servicio ofrecidos.
4 Optimizar el uso de la información.
5 Crear agilidad en TI.
6 Determinar cómo las necesidades funcionales y de control del negocio son traducidas en soluciones
automáticas efectivas y eficientes.
7 Adquirir y mantener sistemas y aplicaciones estandarizados.
8 Adquirir y mantener infraestructuras de TI integradas y estandarizadas.
9 Adquirir y mantener técnicas en TI que respondan a la estrategia de las TI.
10 Asegurar la mutua satisfacción en la relación con terceros.
11 Integrar perfectamente aplicaciones y soluciones tecnológicas dentro de los procesos de negocio.
12 Asegurar la transparencia y comprensión de los costes, beneficios, estrategias, políticas y servicios de TI.
13 Asegurar el correcto uso y funcionamiento de las aplicaciones y soluciones tecnológicas.
14 Responder por todos los activos de TI y protegerlos.
15 Optimizar las infraestructuras, recursos y capacidades de TI.
16 Reducir los defectos y adaptaciones en las entregas de soluciones y servicios.
17 Proteger la consecución de los objetivos de TI.
18 Establecer con claridad el impacto en el negocio de los riesgos en los objetivos y recursos de TI.
19 Asegurar que la información crítica y confidencial está protegida de aquellos que no deben tener acceso
a ella.
20 Asegurar que las transacciones del negocio automatizadas y los intercambios de información pueden ser
realizadas correctamente.
21 Asegurar que los servicios e infraestructuras de TI pueden resistir y recuperarse correctamente de fallos
debidos a errores, ataques deliberados o desastres.
22 Asegurar el mínimo impacto en el negocio en caso de una interrupción o cambio en los servicios de TI.
23 Comprobar que los servicios de TI están disponibles cuando se les requiera.
24 Mejorar la relación costes-eficiencia en las TI (rentabilidad) y su contribución a los beneficios del negocio.
25 Entregar los proyectos en tiempo y presupuesto cumpliendo con los estándares de calidad.
26 Mantener la integridad de la información e infraestructura de proceso.
27 Asegurar la conformidad de TI con leyes y regulaciones.
28 Asegurar que TI da servicios de calidad con una demostrada eficiencia en costes, mejora continua y
preparación para cambios futuros.
En la Etapa III, se realiza el cuadre entre las estrategias del negocio y las estrategias
de TI. Para ello se ponen ambas en una matriz y se identifica, para cada cruce, si la
estrategia de TI contribuye o no la estrategia de negocio dada. Con toda esta infor-
mación previa y con el conocimiento preciso del propio negocio y de cómo TI se
alinea con él, se aborda la selección de los objetivos de TI (Etapa IV).
258 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
A partir de este punto, para cada objetivo de TI se van identificando los indicado-
res de objetivos (KGI). Para cada indicador de objetivos se identifican los indica-
dores de rendimiento (KPI) que le apalancarán (Etapa V). En esta última etapa se
entra en un proceso iterativo en el que se relacionan en una tabla todos los indica-
dores posibles (coctelera de indicadores) seleccionados de diversas fuentes (las
métricas actuales, las deducidas por un ejercicio intuitivo, las que propone ITIL,
las que propone COBIT, etc.). Con todas estas métricas clasificadas, se estructuran
los tres niveles (KGI-TI, KGI-Proceso y KPI), o los establecidos por la arquitec-
tura de métricas que hayamos creado, y se realiza una selección intuitiva de las que
más contribuyen a los objetivos concretos de TI.
3 Alcance de la arquitectura.
3 Antecedentes en la organización.
3 Estrategia de la empresa. Objetivos de negocio
identificados.
3 Estrategia de TI. Objetivos de TI identificadas.
3 Alineación de TI con el negocio. Matriz cruce
objetivos negocio frente a TI.
3 Estructuración en capas de la arquitectura.
3 Métricas de objetivos de TI (KGI-TI).
3 Métricas de objetivos del área del centro de datos o
sistemas (KGI-CPD).
3 Métricas de objetivos del puesto de trabajo (KGI-PT).
3 Métricas globales de desarrollo (KGI-DES).
3 Fichas detalladas de los indicadores.
3 Etc.
Nombre indicador
Código Proceso Valor máx.
Versión Periodicidad Valor mín.
Categoría Ind/KPI/KGI Perspectiva (Norton y Kaplan) Valor mín. (Alza-Baja)
Especificación
Justificación
Audiencia Responsable
Restricciones Padres (KPIs o KGIs a los que contribuye)
Fórmula
Fuente: Telefónica.
Fuente: Telefónica.
Los informes en TI
En relación a los informes, la Norma ISO/IEC 20000-1 requiere que los mismos
estén identificados y que se verifique el cumplimiento de los requisitos y necesi-
dades del negocio. También establece los conceptos mínimos a cubrir en los
informes.
UNE-ISO/IEC 20000-1
Las decisiones de gestión y las acciones correctivas deben tener en cuenta los aspectos
destacados en los informes de servicio y deben comunicarse a las partes afectadas.
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
Informes de servicio
a) comportamiento frente a objetivos
El proveedor del servicio debería generar de nivel de servicio, por ejemplo
informes para los clientes y para la direc- informes de caídas del servicio,
ción, que cubran los siguientes aspectos: logros;
6. Procesos de provisión de servicio
6.2. Generación de informes del servicio 265
destacadas, los cambios más relevantes o los volúmenes de actividad del día. Estos
informes son descriptivos de lo acontecido en el día y no suelen contener gráficos de
indicadores.
Figura 6.2.18. Índice ejemplo de los informes diario y semanal del servicio
6. Procesos de provisión de servicio
6.2. Generación de informes del servicio 269
Informe del servicio mensual. Es el informe más relevante para la gestión de TI.
Contiene toda la información necesaria para conocer y controlar el devenir de la
actividad. Suele constar de un resumen general y un resumen de cada parte rele-
vante de TI que interese seguir mensualmente:
• Resumen ejecutivo del mes.
• Informe sobre la disponibilidad.
• Informe sobre los incidentes y el análisis causal asociado.
• Análisis de las peticiones de usuario realizadas.
• Informe estadístico y descriptivo de los cambios.
• Informe de los proyectos y las iniciativas de transformación de TI.
• Análisis y volumetrías de transacciones.
• Resumen del estado presupuestario en el mes.
• Variación de la planta, descripción de las capacidades de provisión, en lo rela-
tivo a la planta y en las capacidades de trabajo (sourcing).
• Información resumen sobre el resultado del resto de procesos de gestión
TI, etc.
Fuente: Telefónica.
Dentro del informe mensual del servicio (en la figura 6.2.20 se muestra un ejem-
plo), uno de los apartados más relevantes es el relativo al análisis de la disponibili-
dad de los servicios. En el ejemplo se muestran las cifras alcanzadas por cada uno
de los servicios en el mes, junto a una gráfica de la evolución mensual del indica-
dor, representando también la disponibilidad de los servicios críticos. Como en
todos los informes, se deben comentar los aspectos más destacados relativos al
asunto que se esté tratando (disponibilidad, etc.) que hubieran ocurrido en el mes,
así como las acciones de mejora emprendidas.
Fuente: Telefónica.
Responsable de la
gestión del servicio
Gestor del
proceso de informes
Consultor
de métricas
Gestores de otros
procesos y áreas TI
SGSTI
Responsable de generación
de los informes
Especialistas en el Administrador y
Propietario del
modelo (SGSTI) diseño del servicio soporte del proceso
Resumen
Los indicadores e informes son una necesidad innegable en una gestión con cali-
dad de TI, pero su generación ha sido siempre una de las asignaturas pendientes de
las organizaciones, muy centradas en la tecnología y el día a día, y poco en el
gobierno y la gestión.
El proceso de generación de informes de servicio centraliza las arduas activida-
des de recopilación de indicadores e información, para generar unos informes
con la calidad del dato contrastada, en los plazos convenidos y con la máxima
eficiencia.
276 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Aunque en las Normas ISO/IEC 20000 los requisitos para el proceso son más
reducidos, en este apartado se han desarrollado en toda su amplitud, con el fin de
llevar a las organizaciones de TI a la excelencia.
La generación de informes pasa por la definición de una política de informes, que
marque las directrices a cumplir en cuanto al suministro de información.
Un segundo paso recomendado, es la creación de una arquitectura de métricas, que
defina y estructure los indicadores a medir, poniendo orden y posibilitando la con-
tinuidad en las mediciones.
Las organizaciones situadas en las mejores prácticas, disponen de una base de datos
centralizada (o bien federada) en la que incorporan las definiciones de los indica-
dores y todos los históricos de las mediciones.
Los principales informes de TI van más allá de representar únicamente cifras sobre
cumplimiento de los niveles de servicio. El alcance de los informes abarca todo tipo
de información analítica y descriptiva. También se considera dentro del alcance a la
información mostrada en vivo. Así, los principales informes son:
• Informes del servicio: diarios, semanales, mensuales y anuales.
• Cuadros de mando de TI.
• Informe financiero de TI.
• Informe de capacidad.
• Informe de disponibilidad.
• Informe de continuidad de TI.
• Informe de mejora global: SIP + procesos.
• Informe de cada proceso.
• Lista de cambios planificados (FSC).
• Informes de proyectos e iniciativas estratégicas.
• Informe de problemas.
También se consideran dentro del alcance del proceso los paneles de control, con
gráficas que muestran en tiempo real el estado de los servicios y las infraestructu-
ras, así como, los informes generados de forma instantánea (por ejemplo, vía web).
Para poder tratar el ingente volumen de datos, es necesaria la máxima automatiza-
ción, desde la captura de las mediciones mediante las herramientas de monitoriza-
6. Procesos de provisión de servicio
6.2. Generación de informes del servicio 277
ción, pasando por la carga a la base de datos referida anteriormente, hasta llegar a
la generación instantánea (online) de los informes.
La fiabilidad y la calidad de los datos son esenciales para que los informes sean de
utilidad.
Muchos de los informes contienen también tendencias, descripciones y análisis de
las actividades y sucesos ocurridos en el período.
Beneficios
Los principales beneficios aportados por el proceso de generación de informes son:
• La centralización de la generación de informes en un proceso facilita la espe-
cialización, y permite al resto de procesos y áreas de TI centrarse en sus
cometidos.
• Los informes y las métricas se diseñan y gestionan de forma común.
• Los informes se planifican con una visión común de las necesidades de TI y
de los clientes, lo que permite más claridad y concisión. Además se ofrece
una visión más homogénea sobre toda la actividad de TI.
• Cada área recibe los informes que necesita y con la periodicidad acordada.
• Es más fácil garantizar que la información es fiable. Existe un responsable de
cada dato y de cada informe.
• El diseño común por especialistas facilita que la información sea más clara y
entendible por los destinatarios.
• Se centralizan en un punto todos los indicadores y todas sus mediciones.
Con lo cual, cualquier cambio o nuevo informe será más fácil de implemen-
tar, al tener la información histórica registrada.
• La centralización facilita la creación una plataforma común para la genera-
ción y difusión de los informes. Además, la dedicación específica a esta acti-
vidad aumenta la productividad en la generación de informes.
• La organización de TI conoce los resultados de su trabajo, con claridad y a
tiempo. Por tanto, mejora su motivación.
• La comunicación e información clara y a tiempo permite mejorar la satisfac-
ción de los clientes.
278 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Cuáles son los 10 indicadores principales que se utilizan en su orga-
nización¿
• Enumere los informes generados en un año en el ámbito de TI en su
organización
• ¿Qué aporta los marcos de ITIL y COBIT a los indicadores e informes?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
99,99%
lleven a cabo las tareas definidas, muchas de ellas, con una visión a futuro que com-
pite con las prisas y sobrecarga que conlleva el día a día de los servicios.
Como es normal, las Normas ISO/IEC 20000 no definen una estructuración de las
actividades que se deben realizar. Por eso, en este apartado se detalla el proceso
tomando como base la estructura para la gestión de la continuidad de cuatro blo-
ques utilizada en ITIL v2:
• Inicio o implementación del proceso.
• Definición de los requerimientos y de la estrategia a seguir en el proceso.
• Implementación de las soluciones.
• Gestión operativa del proceso.
Sobre estos bloques se detallan las actividades que se deben realizar y se añade un
quinto con las actividades de mejora del proceso, típicas de estas normas.
En la figura 6.3.4 se muestran las diversas estructuras que se dan al proceso de ges-
tión de la disponibilidad en las versiones 2 y 3 de ITIL. Aunque las agrupaciones y
denominación de las actividades difieren, el concepto de fondo en el proceso es
siempre el mismo.
• Inicio: • Inicio:
– Definir política continuidad. – Fijar política continuidad.
– Ámbito de la continuidad. – Ámbito de la continuidad.
– Definición e inicio proyecto continuidad. – Inicio del proyecto continuidad.
• Requerimientos y estrategia: • Requerimientos y estrategia:
– Análisis impacto en el negocio. – Análisis impacto en el negocio.
– Evaluación del riesgo. – Evaluación de riesgos.
– Definición estrategia continuidad negocio. – Definición estrategia continuidad de TI.
• Implementación: • Implementación:
– Organización y planificación implementación. – Desarrollo planes continuidad de servicios TI.
– Desarrollo planes de recuperación. – Desarrollo planes TI, planes recuperación y
– Implementar medidas de reserva. procedimientos.
– Implementar medidas reducción del riesgo. – Planificación de la organización.
– Desarrollar los procedimientos. – Prueba de la estrategia.
– Pruebas iniciales. • Gestión operativa:
• Gestión operativa: – Educación, concienciación y formación.
– Educación y concienciación. – Revisión y auditoría.
– Revisión y auditoría. – Pruebas.
– Pruebas. – Gestión de cambios.
– Control de cambios. • Invocación
– Formación.
– Aseguramiento.
Análisis del árbol de fallos (FTA, Fault Tree Analysis). Método de análisis de los
sucesos ocurridos en un servicio para determinar la causa una interrupción de
los servicios de TI. Se representa una cadena de sucesos en un esquema en forma
de árbol booleano.
Análisis de impacto en el negocio (BIA, Business Impact Analysis). Análisis del
impacto que tendrían los riesgos en la actividad de la empresa u organización, si se
produjera la parada de una función de negocio. Permite identificar y ponderar cuá-
les son las funciones de negocio vitales que deberán protegerse mediante la dispo-
nibilidad, la continuidad y la seguridad. Este análisis es fundamental para el des-
arrollo de las actividades de estos procesos.
Análisis del impacto por el fallo de un componente (CFIA, Component Failure
Impact Analysis). Predecir y estimar el impacto sobre la disponibilidad del servicio
derivada de los fallos de los componentes incluidos en la infraestructura de TI y del
diseño del servicio propuesto. El CFIA de los componentes permitirá identificar
los componentes más débiles (vulnerabilidad y amplitud del impacto) que requie-
ren establecimiento de contramedidas de refuerzo.
Análisis de las paradas del servicio (SOA, Service Outage Analysis). Análisis a
posteriori de las causas de las caídas de un servicio, con el fin de reducir la frecuen-
cia y duración de las paradas. De forma similar se utiliza el término SFA (Service
Failure Analysis). Toma como fuente de información los incidentes ocurridos, para
realizar un análisis forense de cara a mejorar la disponibilidad.
Arquitectura de disponibilidad. Definición tecnológica que establece la forma
homogénea de construir servicios en la organización para que se cumplan los requi-
sitos de disponibilidad. Esta arquitectura establece la redundancia de componentes,
99,99%
DISPONIBILIDAD
GESTIÓN DE LA DISPONIBILIDAD
Política
Inicio Definición e inicio
del proyecto
Diseñar para la
Implementación
disponibilidad
Diseñar para
Verificar la seguridad Planificar las paradas
la recuperación
Gestión • Métricas
operativa Supervisar la Investigar y mejorar
• Monitorizar
disponibilidad la disponibilidad SUPERVISAR
• Informes
UNE-ISO/IEC 20000-1
ISO/IEC 20000-2 recomienda, además, que se dote de los recursos necesarios para
poder satisfacer estos requisitos en cualquier circunstancia. Insta también a que se
trabaje de forma integrada entre la gestión de la disponibilidad y la continuidad.
También detalla el concepto de “extremo a extremo” mencionado en la parte 1,
incluyendo todos los elementos que sustentan el servicio con independencia de
quién dependan: del proveedor principal o bajo el control, bien del propio cliente,
o de otros proveedores de servicio.
UNE-ISO/IEC 20000-2
se mantengan los niveles de servicio Los procesos que aseguran que se man-
acordados. Estos requisitos deberían tiene la disponibilidad requerida, debe-
tener una influencia capital en las accio- rían incluir aquellos elementos de la
nes, esfuerzos y recursos destinados para provisión del servicio que estén bajo el
satisfacer la disponibilidad de los servi- control bien del propio cliente o de
cios que los soportan. otros proveedores del servicio.
Implementar la disponibilidad
Definidos los requisitos que se deben cumplir, se inicia la fase de implementar el
proceso (o subproceso) de gestión de la disponibilidad. En la implementación
se realizan las actividades siguientes: diseñar para la disponibilidad, diseñar para la
recuperación, verificar la seguridad, planificar las paradas y mantenimiento, y generar
el plan de disponibilidad.
Cálculo de la disponibilidad
Período de servicio: 24 x 7 24 x 5 12 x 5
Horas/mes de servicio: 720 horas 480 horas 240 horas
% disponibilidad:
99,999% 25,92 seg 17,28 seg 8,64 seg
99,99% 4,32 min 2,88 min 1,44 min
99,98% 8,64 min 5,76 min 2,88 min
99,90% 43,2 min 28,8 min 14,4 min
99,00% 7,2 horas 4,8 horas 2,4 horas
98,00% 14,4 horas 9,6 horas 4,8 horas
95,00% 1,5 días 24 horas 12 horas
Planificar las paradas (PSO, Projected Service Outage). Parte de la gestión de la dis-
ponibilidad es la gestión del mantenimiento del servicio (planificación de las para-
das) tanto a efectos propios del mantenimiento como para la incorporación de
cambios. Organiza las actividades de mantenimiento dentro de los períodos y ven-
tanas (planificaciones de parada para el mantenimiento de los sistemas o para la
implantación de cambios) en los que se minimiza el impacto sobre la disponibili-
dad del servicio.
Se genera el plan de paradas planificadas (PSO) en el que se definen los períodos
diarios, semanales o mensuales en los que se pueden parar los servicios. Se trata de
un elemento básico para minimizar el impacto en el negocio de estas actividades.
Además, las ventanas de parada se suele excluir en el cálculo de la disponibilidad
real del servicio.
Plan de disponibilidad
3 Política de disponibilidad.
3 Riesgos identificados.
3 Requisitos de la disponibilidad y estrategia.
3 Funciones vitales del negocio (VBF).
3 Directrices de diseño de servicios.
3 Arquitectura de los servicios enfocada a la
disponibilidad y tiempo de respuesta.
3 Definición de las plataformas tecnológicas que se
van a utilizar.
3 Horarios de los servicios.
3 Plan de recuperación y procedimientos.
3 Plan de paradas planificadas (PSO). Ventanas de
mantenimiento y cambio.
3 Requisitos de seguridad.
3 Herramientas de monitorización.
3 Métricas de disponibilidad que se van a utilizar.
3 Modelos de informes de disponibilidad.
3 Fijar los métodos y técnicas de análisis a utilizar.
3 Planificación de la mejora de la disponibilidad.
3 Análisis tendencias tecnológicas.
UNE-ISO/IEC 20000-1
Estas medidas e informes de disponibilidad deben reflejar las perspectivas del nego-
cio, de los usuarios y de la organización de soporte. Se analizan las tendencias y
posibles desviaciones, se estudian las tendencias de la disponibilidad de los compo-
nentes de la infraestructura y se comunican los resultados a las partes interesadas.
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
CONTINUIDAD
Las entradas que desencadenan o activan el proceso son: la realización del plan de
continuidad de negocio por parte de la empresa, que requiere de TI la realización
de su contribución a este plan; el acaecimiento de una contingencia severa que
activa la ejecución de los procedimientos de continuidad; la llegada de la fecha pre-
vista de pruebas de continuidad, que inicia el protocolo de pruebas; y la proximi-
dad de la fecha de revisión del plan de continuidad.
Las entradas más relevantes que utiliza el proceso como información de soporte
son: las condiciones solicitadas o pactadas con los clientes en los acuerdos de nivel
de servicio (SLA); la información de los principales riesgos que amenazan a TI; los
presupuestos asignados a la continuidad, que condicionan las inversiones; los cam-
bios realizados en las infraestructuras o los servicios que deban contemplarse en las
soluciones de continuidad; la información sobre los elementos de configuración
contenida en la CMDB; y la información técnica diversa para proporcionar solu-
ciones o directrices.
Las actividades del proceso se estructuran en 5 grupos:
• Inicio. El primer paso es determinar sobre qué aspectos del negocio y de los
servicios va a actuar la continuidad de TI y sobre cuáles no.
– Definir política continuidad. Directrices y objetivos que establece la
dirección y principales responsabilidades.
– Ámbito de la continuidad. Localizaciones, unidades de negocio o servi-
cios que se deben cubrir. Normalmente no se debería restringir el ámbito.
– Definición del proyecto de continuidad. Plan detallado del proyecto de
implementación de la continuidad (de TI). Designación del responsable
máximo de plan y de los responsables en cada departamento o área. Pre-
supuesto para la definición del plan. Posteriormente se tendrá que hacer
una dotación adicional de presupuesto para la implantación de la solución
de continuidad. Organización de proyecto y estructura de control. Plan de
calidad del mismo. Lanzamiento del proyecto.
GESTIÓN DE LA CONTINUIDAD
Política de continuidad
Ámbito de la continuidad
Inicio
Definición e inicio
del proyecto
Estrategia de continuidad
Realizar el plan de
Plan de continuidad TI
continuidad de TI
Pruebas iniciales
Aseguramiento
La descripción de las funciones vitales del negocio es una actividad clave, que será
de utilidad para la continuidad, pero también para la disponibilidad y para la segu-
ridad. En la figura 6.3.14 se muestra una ficha de ejemplo para la descripción de
estas funciones de negocio.
La evaluación de riesgos permite identificar la posibilidad de que ocurra un desas-
tre o alguna interrupción grave de los servicios. Ofrece una evaluación de la proba-
bilidad de que ocurra el suceso y la vulnerabilidad o exposición de la organización
99,99%
+10 d
Función Impacto datos parada Valor Valor
Criticidad
2d
5d
2h
1d
de negocio negativo admisible admisible normal mínimo
Denominación,
descripción de
la actividad y
su importancia
para la empresa
RPO RTO
1
Véase también la Norma ISO/IEC Guide 73. Risk management. Vocabulary. Guidelines for use in
standards.
312 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
CRAMM M_o_R
Gestión de riesgos
Activos Amenazas Vulnerabilidades • M_o_R políticas
• M_o_R aproximación:
– Políticas gestión de riesgos
Análisis de riesgos – Guía del proceso
Riesgos – Planes
Gestión de riesgos
– Registros del riesgo
– Gestión de logs
• M_o_R proceso:
Contramedidas – Identificar
– Evaluar
– Planificar
– Implementar
• Institucionalizar y revisar M_o_R
• Comunicar
La Norma ISO/IEC 20000-2 establece claramente los requisitos que se deben con-
siderar en la estrategia de continuidad, indicando además que se debe revisar por lo
menos una vez al año, y que los cambios a la misma se deben acordar formalmente.
UNE-ISO/IEC 20000-2
con replicación de datos entre ellos. Una aplicación sólo está ejecutándose en
uno de los centros y, en caso de necesidad, debe activarse en el otro centro
(de respaldo). Proporciona tiempos de recuperación inferiores a 24 horas
(RTO), con una pérdida de datos (RPO) casi nula si se implementa una
replicación del almacenamiento por fibra.
• Recuperación intermedia. Conocida como warm standby, utiliza instalacio-
nes de respaldo proporcionadas por terceros. Los plazos de recuperación
esperados están normalmente entre las 24 y 72 horas.
• Recuperación gradual. Conocida como cold standby, emplea un centro de
respaldo que únicamente contiene la infraestructura física y de conectividad
necesaria. Por lo que, en caso de emergencia, hay que instalar los servidores,
el almacenamiento, las aplicaciones, configurar, etc. Los tiempos de recupe-
ración son superiores a las 72 horas. La información se carga desde la última
copia de seguridad realizada y llevada a resguardo, por lo que la pérdida de
información puede ser superior a las 24 horas (RPO).
• Acuerdos recíprocos. Acuerdos entre empresas u organizaciones para alojar
los servicios en caso de contingencia.
• Soluciones manuales. Soluciones provisionales, como por ejemplo, regis-
trar los tickets de incidentes en el service desk en formularios en papel. Tam-
bién comprenden la restauración de los servicios de forma completa desde
las copias de seguridad.
Implementar la continuidad
Una vez establecida la estrategia de continuidad y los requisitos, se pasa a la elabo-
ración del plan de continuidad de TI y a su implementación. Es necesario que pre-
viamente se haya aprobado el plan general de continuidad del negocio. En la etapa
de implementación se realizan las siguientes actividades (según ITIL):
• Organización y planificación de la implementación, que realiza la elabora-
ción y documentación del plan de continuidad de TI.
99,99%
Plan de continuidad de TI
Fuente: Libro ITIL Diseño del Servicio publicado por OGC y Telefónica.
esquema del plan articulado en torno al ciclo de vida de la gestión de una con-
tingencia.
En relación al plan de continuidad, las Normas ISO/IEC 20000 recomiendan una
política formal de registro de la documentación relacionada, la salvaguardia de los
datos de configuración y, especialmente, de la información necesaria para la restau-
ración de los servicios: plan de continuidad, procedimientos, etc.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Plan de recuperación
3 Estrategia de recuperación.
3 Procedimiento de invocación.
3 Interfaces y dependencias con otros planes.
3 Directrices generales.
3 Dependencias: sistemas, infraestructuras, servicios
externos, etc.
3 Lista de contactos: personal TI, personal otras áreas,
dirección, suministradores.
3 Grupo de recuperación: de TI, de servicios
generales, etc.
3 Lista de comprobación del grupo de recuperación.
3 Formulario de evaluación de daños.
3 Procedimientos de recuperación:
• Recuperación del service desk.
• Recuperación telecomunicaciones.
• Recuperación de la LAN .
• Recuperación de la WAN.
• Recuperación servidores y almacenamiento.
• Recuperación de datos.
• Recuperación de PC.
• Recuperación alimentación eléctrica.
• Recuperación aire acondicionado.
• Comunicación in situ, etc.
Fuente: Libros ITIL Diseño del Servicio y A Guide to Business Continuity Plan publicados por OGC.
Una vez elaborado el plan de continuidad, debe ser difundido y puesto a disposi-
ción de las partes involucradas. El responsable del plan de continuidad de TI debe
formar al personal a su cargo sobre las actuaciones que se deberán realizar en el
caso de que se produzca cualquiera de las situaciones identificadas como de emer-
gencia o desastre.
El responsable del plan establece anualmente un plan de pruebas, donde se definen
las pruebas que se deben llevar a cabo para asegurar la actualización y eficacia de
todos los planes de continuidad de la organización.
UNE-ISO/IEC 20000-1
El plan de continuidad del servicio debe probarse de acuerdo a las necesidades del
negocio.
Todas las pruebas de continuidad se deben registrar y tras las pruebas fallidas se
deben elaborar planes de acción.
99,99%
UNE-ISO/IEC 20000-2
Los planes de continuidad del servicio y Se deberían llevar a cabo pruebas con
la documentación relacionada (por una frecuencia suficiente para asegu-
ejemplo los contratos) deberían estar rar que los planes de continuidad son
ligados a los procesos de gestión del efectivos y permanecen así aún cuando
cambio y de gestión de los contratos. se producen cambios en los sistemas,
Los planes de continuidad del servicio y procesos, personal y necesidades del
la documentación relacionada (por negocio. El cliente y el proveedor del
ejemplo los contratos) deberían eva- servicio deberían estar implicados con-
luarse respecto al impacto previamente juntamente en las pruebas, basadas en
a que se aprueben los cambios en el un conjunto acordado de objetivos.
sistema y en el servicio, y previamente a Los fallos en las pruebas se deberían
acordar los nuevos requisitos del cliente documentar y revisar para proveer de
o bien cambios en éstos siempre que información a un plan de mejora del
sean significativos. servicio.
Una vez aprobado el plan de pruebas, que debe ser respaldado por la dirección, se
realizan acciones de comunicación entre los responsables de los procesos y servicios
implicados, para que estén al tanto de los planes establecidos.
Cada vez que se realice una prueba, el responsable de realizarla dejará constancia
del resultado en el informe de pruebas, que describe las acciones llevadas a cabo y
la eficacia del plan de continuidad. Esta información la analiza el responsable del
proceso, que revisa periódicamente la eficacia de los planes para proponer las mejo-
ras que crea necesarias.
Asimismo, el responsable del proceso es el encargado de que los planes de conti-
nuidad se mantengan actualizados y acordes a la situación actual de la organización.
Para ello, periódicamente debe analizar los cambios realizados que pudieran afectar
al plan, como por ejemplo los:
• Cambios en los procesos (existentes, nuevos o suspendidos).
• Cambios en la estrategia de negocio.
• Cambios en los SLA.
• Cambios en los acuerdos o contratos con proveedores.
• Cambios en la legislación.
• Una nueva evaluación de riesgos.
• Cambios en las ubicaciones, dispositivos y recursos.
322 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• Cambios en el personal.
• Cambios de direcciones, números de teléfono o información de contacto.
Responsable de la
gestión del servicio
Gestor continuidad TI
Gestor
disponibilidad
Responsable plan
de continuidad negocio
Gestores de otros
procesos y áreas TI Arquitecto tecnológico Especialista
de soporte
SGSTI
Resumen
La gestión de la disponibilidad y de la continuidad parte de principios muy simila-
res de alineación con las necesidades del negocio y de creación de planes, para poste-
riormente divergir en dos disciplinas diferenciadas. La primera es la disponibilidad
que se convertirá en el astro rey de los servicios. El porcentaje de disponibilidad será
la obsesión de todo responsable. La segunda, la gestión de la continuidad, “juega a
los dados” con el azar y el futuro de la empresa, proponiendo a la dirección impor-
tantes inversiones para garantizar la supervivencia, e intentando sustraer presu-
puesto de las actividades operativas.
Una vez implantados los planes, la gestión de la disponibilidad estará continua-
mente en boca de todos, mientras que la gestión de la continuidad se convertirá en
ese profeta que muchas veces predica en el desierto.
La gestión de la disponibilidad tiene por objeto que se alcancen las máximas cotas
de disponibilidad posibles (dentro de las requeridas por el negocio), o por lo menos,
los niveles pactados siempre moviéndose dentro del ámbito presupuestario asig-
nado. La gestión de la disponibilidad trabaja para alcanzar los siguientes resultados:
• Tasas de disponibilidad y tiempos de respuesta acordes con lo pactado con el
negocio y, al menos, que sean similares a las de las empresas de la competencia.
• Definición de las directrices de diseño para la disponibilidad. Diseño de
arquitecturas de disponibilidad.
• Tipificación de los servicios en función de su criticidad para el negocio.
• Generación y revisión del plan de disponibilidad.
• Planificación y control de componentes de la infraestructura y de los servi-
cios, para asegurar el cumplimiento de las necesidades de disponibilidad
actuales y futuras.
• Análisis de las situaciones de no disponibilidad del servicio, con el fin de
identificar mejoras. Interviene a posteriori, después de que la gestión del
incidente haya restaurado el servicio.
• Mejorar la disponibilidad de la infraestructura.
• Controlar que los cambios cumplen con unos niveles de disponibilidad ade-
cuados y fiables.
Beneficios
Los principales beneficios son la obtención de una correcta disponibilidad y tiempo
de respuesta de los servicios, y una mejora significativa en la garantía de continui-
dad de los servicio de TI.
En cuanto a la gestión de la disponibilidad, los beneficios se resumen en:
• El negocio utiliza unos servicios con unos niveles de disponibilidad y tiempo
de respuesta adecuados a sus necesidades.
• Los servicios se diseñan sobre una arquitectura planificada para ofrecer la
disponibilidad deseada.
• Los cambios se prueban para verificar el cumplimiento de los criterios de
disponibilidad.
• Se identifican los incumplimientos y se investiga su causa.
• Los niveles de disponibilidad se monitorizan continuamente y se mejoran
donde sea necesario.
330 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 2:
• ¿Cuáles son los principales riesgos a los que están expuestos los servi-
cios de TI en su organización¿
• ¿Cuáles son las funciones vitales en su negocio?
• ¿Qué impacto tendría en su negocio una parada de una hora de los
servicios de TI más críticos (bien por fallo interno o por desastre)?
2
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
6. Procesos de provisión de servicio
6.4. Gestión financiera de TI 331
La reducción de los costes de TI lleva siendo, en los últimos años, una de las prin-
cipales prioridades de la dirección de sistemas de información. El reto está en con-
jugar esta progresiva constricción presupuestaria con la presencia cada vez mayor
de las tecnologías de la información en el negocio. En tiempos de crisis económica,
el proceso de gestión financiera de TI aporta elementos esenciales de decisión y de
control (véase la figura 6.4.1).
En sentido contrario a la reducción de costes, ha ido creciendo el número de servi-
cios de TI considerados críticos por el negocio. Con la apertura a Internet el
número de usuarios se ha disparado y la demanda de nuevas tecnologías en la
empresa se incrementa cada día.
Además, los antiguamente “iletrados” usuarios de los sistemas son hoy ciudadanos
de un mundo cada vez más digitalizado, que exigen a la empresa el mismo nivel
tecnológico que ellos reciben en su vida privada: un correo con la calidad y capaci-
dad de gmail, entornos colaborativos como los de Internet, un espacio en disco de
red equivalente a su disco USB de bolsillo, etc. Para colmo de males, estos servicios
332 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
son gratuitos o a un coste unas cien veces inferior a los que la empresa puede ofre-
cer a sus usuarios.
Todo ello, genera la sensación de que los servicios que TI ofrece al negocio son
inflexibles y caros, provocando una percepción muy negativa en la alta dirección y
en las áreas cliente de TI.
Por fortuna, hay algunos apuntes en el “haber” de TI para equilibrar un poco
la balanza, como por ejemplo las grandes holguras presupuestarias del pasado, la
capacidad actual para poner el foco en lo verdaderamente esencial para la empresa
y el aumento de prestaciones del equipamiento hardware y las nuevas formas de
gestión de TI más eficientes, como las definidas en ISO/IEC 20000 o en ITIL.
La adopción de las mejores prácticas en la gestión económica o financiera de TI y
otras medidas de eficiencia y calidad, aportarán una solución a este callejón sin
salida de hacer más con menos presupuesto. Estas prácticas proporcionan instru-
mentos para responder a los retos de reducción de costes en un entorno de negocio
cada vez más exigente e impulsa a las organizaciones de TI hacia una gestión efi-
ciente de los recursos. Aunque en realidad, la gestión financiera no permite por sí
sola la reducción de costes o el “hacer más con menos”, necesita la existencia del
resto de procesos.
Una gestión económica avanzada de los servicios de TI está caracterizada por:
• La definición de unas políticas de gestión económica o financiera de TI.
• La elaboración precisa y formal de los presupuestos anuales y el seguimiento
con rigor de su evolución.
• La realización de una contabilidad analítica de los costes, que permite el
conocimiento al detalle de los costes de TI en la provisión de los servicios.
• La imputación de costes a las áreas cliente mediante una facturación acorde
con los servicios ofrecidos, para contrapesar la demanda con los costes reales.
Hay que señalar que esta actividad no está dentro del ámbito de la Normas
ISO/IEC 20000, si bien es una actividad muy recomendable y, por ello, tra-
tada en este libro.
está ante una actividad que es la especialidad de otro departamento y ante el que TI
es uno más.
Por todo lo anterior, el enfoque de este proceso debe ser algo diferente al resto de
los procesos de TI. Muchas de las descripciones realizadas en este proceso son más
bien explicaciones simplificadas de las disciplinas económicas y van destinadas al
personal de TI para que realice adecuadamente la parte que les corresponde en la
gestión financiera. En este proceso no se pretende dar ningún tipo de lección a los
profesionales de las finanzas.
El proceso de gestión financiera de TI debería conseguir que las necesidades y requisi-
tos particulares de TI se incorporen en los sistemas financieros y contables de la
empresa. Desde la estructura de los presupuestos hasta la contabilización de la última
factura, se deberían realizar integrados en estos sistemas. Es frecuente y lógico que las
organizaciones grandes de TI tengan un grupo propio de personas dedicadas al control
y a la gestión financiera. Pero se debe evitar la tendencia natural de crear un sistema de
control y de gestión de costes de TI paralelo y conseguir que las necesidades puedan
ser cubiertas por el sistema financiero corporativo, aunque en muchos casos, las nece-
sidades particulares de TI (sobre todo desde la perspectiva de gestión de activos y en la
utilización de recursos) requieren la utilización de sistemas complementarios.
En ISO/IEC 20000-2, la gestión financiera de TI se describe en torno a tres áreas:
la definición de las políticas, la elaboración del presupuesto y la contabilidad de los
servicios. Además, en este libro se incorporan también muchas de las recomenda-
ciones de ITIL v2, entre otras, la facturación de los servicios, esencial para equili-
brar la balanza entre la demanda de las áreas cliente y de la oferta de TI. En la
figura 6.4.2 se muestra una introducción a este proceso.
El objetivo principal del proceso es conseguir una administración eficiente de los
recursos económicos de TI. Genera como principales contribuciones:
• La administración eficiente de los activos de TI utilizados para proveer los
servicios de TI.
• Una integración y diálogo perfecto con el área financiera de la empresa.
• El poder realizar una contabilidad exacta de los servicios de TI.
• Facilitar la toma de decisiones sobre inversiones en TI de una forma efi-
ciente.
• Orientar las organizaciones de TI a estructuras de costes más competitivas.
• La optimización de los costes de los servicios de TI. La detección de inefi-
ciencias en costes, permitiendo concentrar los recursos económicos en fun-
ciones esenciales para el negocio.
334 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
1
Enron, Tyco International, Adelphia, Peregrine Systems y WorldCom.
2
La información sobre SOX se ha obtenido de Wikipedia.
6. Procesos de provisión de servicio
6.4. Gestión financiera de TI 337
Requerimientos
financieros del
negocio para TI
PRESUPUESTO CONTABILIDAD
Modelo
Proceso Procesos
de entrega Procesos de relaciones
Proceso de gestión de resolución Gestión de las relaciones
de la entrega Gestión del incidente con el negocio
Gestión del problema Gestión de suministradores
de costes
Mejoras
FACTURACIÓN
PDCA
Modelo de SGSTI
facturación
Precios
Catálogo
de servicios
anual), que suele conllevar la definición de unos nuevos objetivos financieros para
TI realizados en función de la planificación de las actividades que se deben realizar;
y de una necesidad de compra que TI inicia y solicita su aprobación presupuestaria.
Hay otras entradas de soporte que se utilizan en el proceso. Destacan los objetivos
financieros establecidos por la organización para TI; la planificación de proyectos y
actividades previstas para TI, donde se reflejan todas las actividades y compromisos
planificados; el modelo de costes, formado por una estructura que permite regis-
trar y asignar todos los costes; el modelo de facturación o imputación de costes a
GESTIÓN FINANCIERA DE TI
SISTEMAS DE
INFORMACIÓN
MARKETING VENTAS FABRICACIÓN ADMINISTRACIÓN SERVICIOS Etc.
GENERALES
tener presupuestado y aprobado este coste extra antes de cerrar el SLA. Con la ges-
tión de nivel de servicio también se analizan las mejoras de eficiencia en costes de
los servicios. Además, en el catálogo de servicios se incorpora el precio de cada ser-
vicio y sus opciones.
Gestión de suministradores. La gestión de suministradores está muy vinculada a
este proceso. Las relaciones entre ambos se establecen en todos los ámbitos de la
gestión de suministradores: en la definición de la estrategia de sourcing, que debe
ser acorde con los objetivos financieros; en el ciclo de selección y contratación, que
lleva a cabo las compras; y en el ciclo de gestión de la prestación del suministrador,
para velar por los pagos y las variaciones económicas dependientes de la demanda.
Gestión del cambio. Los cambios importantes deben valorarse en cuanto al coste
y aprobarse bajo el ámbito de la gestión del cambio. Este requisito obliga a la ges-
tión financiera a trabajar de una forma conjunta con el resto de la organización en
la aprobación de los cambios y sus costes bajo el proceso de gestión del cambio.
Gestión de la capacidad. La gestión de la capacidad participa en la elaboración de
los presupuestos con las previsiones de recursos identificadas en el plan de capaci-
dad. Con las previsiones, se pueden concentrar las compras y evitar las compras de
urgencia para obtener ahorros adicionales. Además, proporciona información sobre
la utilización de las infraestructuras y de los recursos.
Gestión de la disponibilidad y continuidad. La continuidad puede requerir gran-
des inversiones en replicaciones, en servicios externos y en centros redundados. La
elaboración de presupuestos y contabilidad debe conseguir que las soluciones de
continuidad tengan el equilibrio entre el coste y el beneficio aportado al negocio.
Pues, podría ocurrir que la pérdida posible del negocio sea menor que el coste de
los mecanismos redundados.
Gestión de la configuración. La información sobre los costes de los activos los
proporciona el proceso de gestión financiera, y gestión de la configuración los
almacena como un atributo de información más. Posteriormente se utilizarán para
el cálculo de los costes por servicio.
Este proceso también se relaciona con el resto de procesos y áreas para definir las
partidas presupuestarias del ejercicio, identificar mejoras de eficiencia económica y
el seguimiento de los objetivos económicos.
UNE-ISO/IEC 20000-1
Nota: Esta sección cubre la elaboración de presupuestos y de la contabilidad del los servicios de TI. En
la práctica, muchos proveedores del servicio estarán involucrados en facturar por tales servicios.
Sin embargo, dado que la facturación es una actividad opcional, no está cubierta por la norma.
Se recomienda a los proveedores que si hacen uso de la facturación, el mecanismo para hacerlo
esté plenamente definido y entendido por las partes. Todas las prácticas contables en uso se debe-
rían alinear con las prácticas contables más amplias de la organización del proveedor del servicio.
En la nota anterior se deja claro el alcance de los requisitos del proceso en la parte 1,
en los que no se incluye la facturación, aunque en este libro sí se trata.
Por otra parte, se recalca la importancia de que la elaboración de presupuestos y la
contabilidad de TI estén perfectamente alineadas con las prácticas contables gene-
rales de la organización. Hay que intentar que la contabilidad de la empresa con-
temple las necesidades de la contabilidad analítica de TI, con el fin de poder extraer
de ésta los costes por servicio, los costes por cliente, los costes por actuación, etc.
Así, se evita realizar la contabilización dos veces, una en los sistemas contable gene-
rales de la empresa y otra en los sistemas contables específicos de TI.
UNE-ISO/IEC 20000-2
Generalidades
La responsabilidad sobre muchas de las
Esta sección cubre la realización de los decisiones financieras va a estar fuera
presupuestos y de la contabilidad para del ámbito de la gestión del servicio y
los servicios de TI. En la práctica, también podrían dictarse externamente
muchos proveedores están implicados los requisitos acerca de qué información
en la facturación del servicio. Sin financiera se debe facilitar, de qué
embargo, dado que la facturación es manera y con qué frecuencia. Las dis-
una actividad opcional, no está cubierta posiciones de esta sección están enfo-
por esta norma. Se recomienda a los cadas en las prácticas que se deberían
proveedores del servicio que cuando seguir para satisfacer los requisitos de la
lleven a cabo la facturación, el meca- norma. Sin embargo, se pueden tener
nismo empleado para ello esté definido en cuenta requisitos más amplios en el
en detalle y sea entendido por todas las caso de que impacten en alguna de las
partes implicadas. políticas y procedimientos definidos.
6. Procesos de provisión de servicio
6.4. Gestión financiera de TI 345
ISO/IEC 20000-2 hace hincapié en que muchas decisiones financieras que afectan
a este proceso se toman fuera de él. La gestión financiera de TI está supeditada a
las directrices del departamento financiero de la organización. En algún escenario,
como en el caso de las empresas pequeñas, la responsabilidad completa del proceso
puede ser externa a TI.
• Las herramientas de soporte a la gestión del proceso deben ser los mismos
sistemas de gestión de la empresa. Deben permitir gestionar los presupues-
tos, la contabilización de los gastos por servicio y por cliente, el registro del
consumo de recursos y su facturación.
• Contemplar los propios costes originados por el proceso, que esencialmente
están relacionados con el personal y la adaptación de los sistemas financieros
de la empresa.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
Los costes se deben presupuestar con suficiente detalle para permitir el control eco-
nómico efectivo y la toma de decisiones.
El proveedor del servicio debe monitorizar e informar de los costes contra el presu-
puesto, revisar las previsiones económicas y gestionar los costes en consonancia.
Los costes de los cambios en el servicio se deben valorar y aprobar a través del pro-
ceso de gestión del cambio.
ISO/IEC 20000-1 requiere que los cambios se valoren en cuanto a sus costes y que
se aprueben a través del proceso de gestión del cambio. De esta forma, se tiene
un mejor conocimiento y control de los costes. Las peticiones de cambio (RFC),
presentadas con el fin de aprobar su ejecución, deben incorporar el coste asociado
(así se establece en el formato de RFC del apartado 9.2). El proceso de gestión
financiera controlará a través de su presencia en el comité de cambios (CAB,
Change Advisory Board), que se actué dentro de los presupuestos asignados.
Una vez aprobado el cambio, cuando se necesite la ejecución de alguna compra
(equipamiento, licencias, servicios, etc.), volverá a intervenir la gestión financiera
para autorizarla económicamente.
UNE-ISO/IEC 20000-2
En teoría, antes de la realización del presupuesto, se deberían tener cerradas las pro-
puestas de los planes anuales de los otros procesos y áreas, que tienen una influen-
cia directa en el presupuesto, como por ejemplo, el plan estratégico de TI, la car-
tera de proyectos anual, el plan de capacidad, el plan de continuidad, el plan de
disponibilidad y las estimaciones de costes de otras áreas y procesos (service desk,
problemas, cambios, infraestructuras, etc.).
• Mensualmente:
– Comprobar que los costes consolidados del mes en curso se corresponden
con las previsiones, y analizar y explicar cualquier desviación.
– Realizar análisis de costes.
– Obtener los precios reales por servicio-cliente, y compararlos con los pre-
supuestos.
– Difundir un balance de situación mensual.
– Notificar las desviaciones producidas a cada área.
– Revisar la recuperación de los costes en comparación con los objetivos
establecidos.
• Trimestral o semestralmente:
– Evaluar la exactitud de las fórmulas para el cálculo de costes, comparando
los costes y los ingresos reales con los previstos.
– Comprobar las listas de precios de los servicios.
354 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• Anualmente:
– Planificar los cambios necesarios en el personal y los recursos para el pró-
ximo año.
– Revisar los sistemas de contabilidad y facturación de TI, para:
· Generar las cuentas finales del año financiero en curso.
· Asegurar de que se alcanzan los objetivos de negocio de la organización
de TI.
– Generar los análisis anuales del coste.
– Confeccionar y difundir un balance final.
– Revisar los elementos de coste estándar (es importante tener en cuenta
que las correcciones deben ser las imprescindibles, ya que cualquier cam-
bio dificultará las comparaciones entre distintos años).
– Recalcular el valor por unidad del coste para comprobar que se correspon-
den con los resultados previstos.
– Revisar la política de gestión económica y los procedimientos de la conta-
bilidad de TI.
– Ayudar al cliente y a otros gestores de TI a definir los presupuestos para el
nuevo año financiero.
– Revisar las necesidades de continuidad de los servicios que soportan la
gestión económica de TI, y comprobar que todos sus requerimientos y
necesidades están cubiertos.
UNE-ISO/IEC 20000-2
Contabilidad
Los modelos de costes deberían ser
Los procesos de contabilidad se debe- capaces de mostrar los costes de la pro-
rían usar para realizar el seguimiento de visión del servicio.
los costes hasta el nivel de detalle acor-
Los estados de cuentas deberían mostrar
dado durante un periodo de tiempo
las situaciones de excesos y defectos
también acordado.
de gasto así como las recuperaciones de
Las decisiones sobre la provisión del dichas situaciones y deberían permitir al
servicio deberían estar basadas en com- lector entender los costes de niveles bajos
paraciones sobre la eficacia en costes. de servicio o de pérdidas de servicio.
Se debe poner un foco especial en conocer el gasto por cliente, por servicio y por
actividad, lo cual implica tener que realizar un desglose o asignación por cliente y
por servicio en todos los gastos. En lo relativo a la actividad, se necesitará un sis-
tema de imputación de tiempos por parte del personal.
356 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Modelo de costes en TI. Un modelo de costes por servicio es una estructura con-
table en la que se pueden registrar y asignar todos los costes conocidos a servicios,
de manera que se puedan conocer los costes de toda la estructura productiva nece-
saria para un servicio. De igual manera, existe el modelo de costes por cliente (mar-
keting, ventas, etc.), que permite conocer todos los costes incurridos por TI para
prestar los servicios a cada uno de ellos.
El modelo de costes de TI se debe definir e implementar de forma conjunta entre
TI y el área financiera de la empresa. De esta manera, además de cumplir con la
legalidad vigente, se evita tener que realizar una contabilidad duplicada.
A la hora de plantear el desarrollo e implantación de un modelo de costes, y antes
de lanzarse a definir los elementos de coste típicos de TI, se debería obtener la
siguiente información.
• La información procedente de las cuentas de gasto de la empresa a la que
pertenece la organización de TI (gastos de personal, contratos de servicios
de TI, mantenimiento de licencias, amortización del hardware y del soft-
ware, etc.).
6. Procesos de provisión de servicio
6.4. Gestión financiera de TI 357
El modelo de costes es un aspecto clave y piedra angular para una adecuada ges-
tión económica de los servicios de TI. En la figura 6.4.9 se muestra el ejemplo de
un modelo de costes de TI enfocado a los servicios.
Elementos de coste
Servicios externos
Transferencia
Costes directos Costes indirectos
del servicio del servicio
Reglas de
Costes directos y % de
reparto de los
costes absorbidos incremento
costes indirectos
del servicio común
no imputables
El modelo de costes por servicio es una forma de asignar internamente los costes
con el fin de conocer el coste total de prestación de cada servicio. Para ello, prime-
ramente se obtiene la información contable por elemento de coste según la estruc-
tura común definida: costes de hardware, costes de software, costes de personal,
costes de ubicación física, costes de servicios externos y costes de transferencia.
Una vez recopilados todos los costes, se clasifican los costes en dos tipologías,
directos o indirectos:
• Costes directos del servicio. Son aquéllos que pueden atribuirse de manera
clara a un único servicio. Por ejemplo: un servicio que se ejecuta en una
máquina específica.
• Costes indirectos. Son aquéllos en los que se incurre de forma común a
todos los servicios o en un número acotado de ellos. Por ejemplo, la red o el
departamento de soporte técnico, que tendrán que ser distribuidos entre
todos de manera equitativa. Al distribuir los costes indirectos se dan dos
casos:
– Costes indirectos imputables a un servicio. Son aquellos costes
de recursos comunes que razonablemente se pueden imputar a un ser-
vicio mediante un tipo de prorrateo por el uso que hace el servicio del
recurso. Por ejemplo, el consumo de CPU de un servicio en una máquina
virtual.
– Costes indirectos no imputables a un servicio o no absorbibles. Es el
coste de cualquier recurso que presta servicios de una forma común a
todos y que no tiene una relación posible con un servicio o cuya imputa-
ción es muy compleja. Se repercute entre todos los servicios del modo más
justo posible. Estos elementos comunes pueden ser de hardware, de soft-
ware, de personal, de ubicación, de servicios externos o de transferencia.
Por ejemplo, un cortafuegos del centro de datos, los sistemas de aire acon-
dicionado, el personal administrativo, etc. En este caso, los costes se dis-
tribuyen en base a una tasa común que incrementa los costes del servicio
calculados hasta ese momento.
La suma de los costes totales asignados a los servicios debe ser igual a la suma de
los costes iniciales.
Existen diferentes tipologías a la hora de calcular los costes, las dos más utilizadas
son:
• En base al coste total de la propiedad o TCO (Total Cost of Ownership), que
calcula todos los costes necesarios durante el ciclo de vida completo del
servicio. En este caso, los clientes soportan la totalidad de los costes de pro-
visión y prestación del servicio.
• En base al coste marginal, calculando el coste en función del incremento en el
total de costes por proveer un servicio adicional. Sólo se repercuten al cliente
los costes incrementales del ejercicio. Es una forma más sencilla e imprecisa de
repercutir los costes, pero igualmente sirve para moderar la demanda.
Los modelos más utilizados para la distribución de los costes en función de los con-
sumos son:
• Coste por usuario de los servicios. En este modelo, se carga una cuota fija
por cada usuario con independencia del uso que se realice. Muy utilizado en
los servicios al puesto de trabajo (PC, archivos en red, navegación por Inter-
net, correo electrónico, etc.). Es un modelo sencillo, pero poco equitativo.
Para que tenga su efecto de moderar la demanda, debe combinarse con otros
costes que sean reflejo del consumo variable. También se utiliza para reper-
cutir los costes de las aplicaciones con complejidad de administración o
cuando el coste de las licencias es alto.
• Coste por capacidad de proceso consumida. Forma histórica de medición
en el ámbito mainframe. Las mediciones son sencillas y las proporciona el
propio sistema. Se factura por tiempo de uso del procesador. El coste por
MIP (Millones de Instrucciones por Segundo) en el mainframe, o por MIP
equivalente para entornos abiertos, es un dato con benchmarking del mercado.
• Coste por servidor (o por caja). Se tipifican los servidores según su sistema
operativo y capacidad para fijar un precio por cada uno de ellos. Es un modelo
poco preciso, pero sencillo y fácil de contrastar con los inventarios. Por ello se
utiliza mucho en los contratos de outsourcing completos. En el precio se distin-
gue entre los servidores que se compran y entre los que sólo se administran.
• Coste por capacidad de proceso asignada. En los nuevos entornos virtua-
lizados, un servidor alberga varias máquinas virtuales, por lo cual la capaci-
dad de proceso asignada es una medida algo más precisa que la medición por
servidores físicos.
• Coste por unidad de almacenamiento. En relación al almacenamiento, se
miden los “gigas” (GB) o los “teras” (TB) netos totales instalados o los asig-
nados a un cliente para cada servicio.
6. Procesos de provisión de servicio
6.4. Gestión financiera de TI 361
Aunque ninguno de estos modelos para la imputación de los consumos es muy pre-
ciso, su contabilización mensual resulta sencilla.
Una vez calculado el coste de la provisión y prestación del servicio, se pueden apli-
car distintas formulas de facturación:
• Precios fijos o tarifa plana. El precio mensual es constante, con indepen-
dencia del consumo.
• Precios con dos tramos. La cual incluye un término fijo para cubrir los cos-
tes fijos y un término variable en función del consumo que recuperaría los
costes variables.
• Precios alineados con el mercado. Los precios se regulan por el propio
mercado o por benchmarking externos.
En cualquier caso, el modelo de facturación debe ser sencillo y entendible por las
partes. Para la fijación del precio se pueden seguir varias tendencias: la más utili-
zada para servicios internos es cuando los precios se basan en el coste real de los
servicios; otra es el establecimiento del precio según la demanda que exista del
mismo o según la exclusividad del servicio ofertado.
En los primeros años o ejercicios en que se aplique la facturación, se deben revisar
las tendencias del consumo de los clientes y usuarios para evitar que las estruc-
turas de precios estén generando distorsiones en el consumo óptimo de los servi-
cios de TI.
Administrador y
soporte del proceso
Propietario del
Gestor de la
modelo (SGSTI)
capacidad
Gestor de las
relaciones con Departamento financiero
de la empresa Contables de
el negocio la empresa
• El personal de TI, que imputa su dedicación a las diversas tareas con el fin
de tener una contabilización detallada de los servicios.
• Las diversas áreas de TI, que realizan las peticiones de compra.
Métricas
Las métricas se deben adaptar a las necesidades de gestión y control que tenga cada
organización. Las métricas de gestión financiera de TI suelen proporcionar infor-
mación sobre los costes, en forma de ratios, y medidas específicas sobre el funcio-
namiento del proceso:
• Ratios sobre presupuestos y costes:
– Presupuesto de TI en relación al volumen de facturación de la empresa
(ITR, IT Spending per unit of Revenue). Representa el porcentaje de los
ingresos de la empresa que deben destinarse a sostener las tecnologías de
la información en la empresa.
– Peso del presupuesto de inversión (CAPEX) en relación al presupuesto
total de TI.
– Ratio de coste total de TI por usuario.
– Ratio de coste total de TI por potencia de proceso instalada (MIP, MIP
equivalente, specs, transacciones por minuto, etc.)
– Ratio de coste total de TI por GB almacenamiento instalado.
– Con frecuencia se miden ratios de costes sobre áreas o temáticas de interés
en un período dado, como por ejemplo, el porcentaje de presupuesto dedi-
cado a seguridad informática, presupuesto dedicado a innovación, etc.
Figura 6.4.11. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
Resumen
El crecimiento de los recursos dedicados a los sistemas de información y la utili-
zación extensiva de los servicios de TI, junto con la tendencia a la reducción de
3
El límite inferior del ITR puede llegar al 1%, como es el caso del sector de distribución.
366 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Otro objetivo del proceso es la integración plena con los departamentos financie-
ros y contables de la empresa evitando mantener registros paralelos. Pero estos sis-
temas de la empresa se deben adaptar para satisfacer también las necesidades de
información analítica de TI.
Beneficios
El principal beneficio es una gestión más eficiente y controlada de los gastos en tec-
nologías de la información.
La presupuestación es la actividad clave en el proceso de gestión financiera de los
servicios de TI y proporciona:
• Mejora en la priorización de los proyectos de inversión. Toma de decisiones
sobre los servicios en base a análisis de rentabilidad de las inversiones.
6. Procesos de provisión de servicio
6.4. Gestión financiera de TI 367
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 4:
• ¿Cuáles de las tres actividades principales de este proceso (presupues-
tar, contabilizar y facturar) se realizan en su organización?
• Indique tres procesos que son necesarios tener implantados previa-
mente para que el proceso de gestión financiera de TI tenga éxito.
4
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
6. Procesos de provisión de servicio
6.5. Gestión de la capacidad 369
La actividad del negocio no debería ser coartada por una falta de capacidad o un mal
rendimiento de los sistemas de información. En momentos de máxima demanda
los sistemas deben responder. Los incrementos de carga deben estar previstos, los
sistemas diseñados para absorberlos y también lo deben estar para poder crecer
de forma dinámica. Pero alcanzar este estatus de poderío no es una tarea sencilla.
Se requiere la ejecución de un conjunto complejo y diverso de actividades. En este
proceso se explican las más relevantes que están contenidas en las mejores prácticas
del mercado (véase la figura 6.5.1).
El proceso de gestión de capacidad, muy maduro en la década de 1980 con los
entornos mainframe, pasó al olvido a comienzos de la década de 1990 con la lle-
gada de los sistemas abiertos; cuando duplicar la capacidad de un equipo era más
económico que pagar a un ingeniero de sistemas para que la planificara. Pero las
alegrías y derroches en TI finalizaron con la burbuja de las “puntocom”. Se ha
vuelto a la senda del estricto control económico y al seguimiento del retorno de
la inversión. Así, la gestión de la capacidad vuelve a tener plena vigencia en los
comienzos del siglo XXI.
370 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Como si los ajustes económicos no hubieran sido justificación suficiente, las ten-
dencias a la consolidación y a la virtualización de las infraestructuras refuerzan la
necesidad de disponer de una buena gestión de la capacidad (y rendimiento).
Implantar plataformas comunes requiere gestionar y controlar los recursos que
consume cada servicio para evitar que interfiera en el rendimiento de sus compañe-
ros de habitáculo.
Recientemente se ha incorporado a la ecuación la necesidad de ajustar el consumo
eléctrico, como consecuencia de los problemas con la refrigeración de los centros
de datos, la reducción del impacto ambiental de las TI y la necesidad de rebajar la
factura eléctrica. Este recién llegado sitúa también a la gestión de la capacidad
como un buen instrumento para ejecutar las políticas medioambientales, o verdes,
en TI relativas al uso eficiente de las infraestructuras.
Gestionar la capacidad de los servicios de TI permite garantizar que se tendrá, en
todo momento, la capacidad suficiente para cubrir la demanda actual y futura acor-
dada con el negocio, manteniendo siempre un coste razonable y equiparable con el
mercado. La gestión de la capacidad debe equilibrar las previsiones de utilización o
carga con los recursos disponibles, de modo que se eviten pérdidas o degradacio-
nes del servicio. Pero también debe vigilar el coste de la sobrecapacidad para evitar
el derroche de recursos.
Gestionar adecuadamente la capacidad no es una tarea fácil. Se debe tener un cono-
cimiento técnico de las infraestructuras de TI, pues se encarga de supervisar la capa-
cidad actual, de anticipar las ampliaciones necesarias, de modelar el comporta-
miento de las aplicaciones, y del ajuste y mejora continua del rendimiento.
Además, requiere un entendimiento de la actividad del negocio, para poder predecir
las variaciones en el consumo de recursos (crecimiento “vegetativo”, campañas de
marketing, variaciones estacionales, acontecimientos singulares, etc.). La gestión de la
capacidad debe conocer las variaciones temporales del negocio para ajustar los recur-
sos, como es típico en la facturación mensual. Según el ciclo del negocio, se pueden
presentar campañas según la estación del año. Así, en las empresas de telefonía móvil,
las épocas de fin de año y de verano se dispara la actividad de los consumidores y los
sistemas se ven sometidos a su máxima carga. También hay que tener en cuenta acon-
tecimientos puntuales, como el lanzamiento de una campaña de marketing. Por todo
ello, es necesaria una comunicación fluida entre la gestión de la capacidad y el negocio.
En la figura 6.5.2 se presenta una visión introductoria al proceso de gestión de la
capacidad.
El objetivo del proceso de gestión de la capacidad es garantizar que siempre existe
la capacidad de TI necesaria, justificable en términos de coste, y ajustada a las nece-
sidades del negocio, actuales y futuras.
6. Procesos de provisión de servicio
6.5. Gestión de la capacidad 371
El proceso de gestión de la capacidad debe ser el foco central de todos los temas
relacionados, tanto con la capacidad como con el rendimiento. Las tareas diarias
deberán realizarse por los grupos técnicos de la organización (técnica de sistemas,
administración de bases de datos, ingeniería, soporte de redes, etc.), trabajando
para este proceso en las actividades que marca la gestión de la capacidad.
La gestión de la capacidad trata aspectos proactivos y reactivos.
• La faceta proactiva comprende todas las actividades que permiten anticiparse
a una carencia de capacidad y a un escaso rendimiento, como por ejemplo, la
previsión de la demanda por parte del negocio, la previsión de la capacidad
necesaria por los servicios, el modelado de servicios, el dimensionado de las
aplicaciones, el plan de capacidad, etc.
• Los aspectos reactivos del proceso están relacionados con la detección de faltas
de capacidad, el ajuste o tuning de componentes o de los servicios, la provisión
con urgencia de soluciones, el establecimiento de umbrales en la monitoriza-
ción, etc.
372 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Además, el proceso debería tratar otros aspectos relacionados con la mejora o inno-
vación en las plataformas informáticas, como por ejemplo:
• La automatización de la provisión de peticiones de los usuarios, autorregis-
tro, autorresolución, distribución de software, etc.
• La automatización de los centros de datos, con la implantación de políticas
de asignación dinámica de recursos según las previsiones de carga, provisión
automatizada de infraestructura virtual, etc.
• La consolidación de servidores y del almacenamiento.
• La virtualización de los sistemas operativos.
• La gestión de la obsolescencia del equipamiento y la renovación del parque.
La desconexión y retirada de equipos. La gestión del apagado de aplicacio-
nes sin uso.
• En coordinación con las políticas medioambientales en TI (green IT), parti-
cipa en la implantación de las políticas relacionadas con el consumo energé-
tico y de materiales menos contaminantes, como por ejemplo:
– El seguimiento del consumo eléctrico. Implantación de políticas de reduc-
ción del consumo en equipos, como la entrada en suspensión tras perío-
dos de inactividad.
– La definición de políticas de compra de equipamiento certificado con eti-
quetas verdes de bajo consumo y materiales reciclables.
Previsión
Utilización de la carga
o carga
Capacidad Plan de
Previsiones
del negocio Modelos capacidad de capacidad
abiertos o cerrados sobre este ámbito; la información obtenida sobre cualquier ele-
mento a partir de la base de datos de gestión de la configuración (CMDB, Change
Management Data Base) y la información sobre los históricos de monitorización en
la base de datos de gestión de la capacidad (CDB, Capacity Data Base); la planifica-
ción de los cambios a partir de la lista de cambios planificados (FSC, Forward Sche-
dule of Changes) o bien change schedule (siguiendo la terminología ITIL v3), para
conocer en qué momento se necesitará la capacidad; los presupuestos de TI que
establecen los recursos económicos disponibles; etc.
La gestión de la capacidad tiene tres subprocesos o ámbitos de actuación: el nego-
cio, los servicios y los recursos.
• La gestión de la capacidad del negocio. Se enfoca en conocer la capacidad
que va a demandar el negocio para anticiparse en la cobertura de las necesi-
dades. Los requisitos futuros se obtienen a partir de los planes de negocio,
crecimiento, planes de desarrollo, nuevos servicios, etc.
En la capacidad del negocio también se incluyen los aspectos de la capacidad
de los servicios en lo concerniente a su relación con otros procesos: asisten-
cia en la definición de los requisitos de nivel de servicio de capacidad, diseño
de nuevos servicios y la provisión de infraestructuras, verificación de SLA en
rendimiento y carga, firma de los acuerdos, etc.
• La gestión de la capacidad de los servicios. Se centra en la gestión de la
capacidad y rendimiento de los servicios de TI, que deben cumplir los míni-
mos establecidos en los acuerdos de nivel de servicio. Se puede considerar
como la visión hacia el interior de los servicios centrada, principalmente,
en conseguir su adecuado funcionamiento, ya que las interacciones con el
entorno se tratan en la capacidad del negocio.
• La gestión de la capacidad de los recursos. Se centra en la gestión de los
componentes individuales de la infraestructura de TI: capacidad, rendi-
miento, parametrización, optimización, monitorización, obsolescencia, etc.
Siguiendo ITIL, en cada uno de estos tres ámbitos se realiza un conjunto de activi-
dades que se enumeran de forma común, aunque unas son más específicas de un
ámbito y otras, en cambio, se realizan en los tres.
• Elaborar el plan de capacidad. Documento que recoge de forma precisa las
necesidades inmediatas y a medio plazo de recursos. Su elaboración orquesta
un movimiento en toda la organización para predecir las necesidades de
capacidad del negocio, de los servicios y de los recursos. Es el documento
maestro que pronostica las necesidades para que se proporcionen los presu-
puestos necesarios.
380 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Actividades
Elaborar Ciclo de mejora Relacionarse
el plan de de la capacidad con otros
Subprocesos capacidad y rendimiento procesos
Modelado
Las principales salidas o resultados del proceso son: el plan de capacidad elaborado o
actualizado, con las previsiones de recursos necesarias; la base de datos de capacidad,
con toda la información de capacidad y rendimiento recogida en la monitorización;
los informes de capacidad elaborados; y el dimensionado de aplicaciones realizado.
Como resultados secundarios del proceso se obtienen: los umbrales y alarmas para
la monitorización de la capacidad y rendimiento; las líneas base en cuanto a la utili-
zación de recursos y los perfiles de comportamiento; las recomendaciones de par-
tida para los acuerdos de nivel de servicio; las recomendaciones sobre políticas de
facturación, de cara a influir en el consumo de recursos; los cambios proactivos (y
sus RFC) para la mejora de la capacidad y del rendimiento; la planificación de las
operaciones revisada, de cara a ajustar los picos en la carga de los recursos; las pro-
puestas de actividades para la mejora de los servicios; etc.
El plan de capacidad
Uno de los principales instrumentos del proceso es el plan de capacidad, cuyo obje-
tivo es predecir las necesidades de capacidad con el fin anticiparse a su demanda.
Alrededor de la elaboración del plan se desencadena la actualización de informa-
ción y revisión completa de la situación actual. Las actualizaciones del plan marcan
el tempo de este proceso. Al igual que ocurriera en disponibilidad y continuidad, el
plan de capacidad marca el ciclo vital del proceso, que debe ir acompasado con la
gestión financiera de TI.
En el plan de capacidad también se incorporan los niveles actuales de utilización de
recursos y el rendimiento de los servicios. Se estudian los planes y la estrategia del
negocio. Las estimaciones y suposiciones realizadas se deben indicar con claridad.
También debería incluir recomendaciones sobre los recursos requeridos, sus costes,
los beneficios, el impacto, etc.
Las Normas ISO/IEC 20000 explicitan un conjunto de requerimientos que se
deben cumplir a través del plan de capacidad:
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Se debería generar un plan de capacidad mentar las opciones existentes junto con
donde se documente el rendimiento real su coste para cumplir con los requisitos
de la infraestructura y los requisitos espe- del negocio, así como, las soluciones
rados, con la frecuencia suficiente para recomendadas para conseguir los obje-
tener en cuenta el ritmo de cambios de los tivos de nivel de servicio tal como están
servicios y de los volúmenes de servicio, la definidos en el SLA.
información de los informes de gestión del
Debería existir una buena comprensión
cambio y del negocio del cliente.
de la infraestructura técnica y sus capa-
Dicho informe debería elaborarse al cidades presentes y las que estén pro-
menos anualmente. Se deberían docu- yectadas.
El plan de capacidad debe publicarse anualmente y debe estar alineado con el ciclo
presupuestario. Hay que tener presente que está muy vinculado al plan de inver-
sión y debe estar finalizado antes de que se inicie la elaboración de los presupuestos
de TI. Se recomienda su actualización cada tres meses, para reflejar los cambios en
el negocio o para corregir las previsiones.
En la figura 6.5.7 se muestra la estructura propuesta en ITIL, que divide el plan en
11 apartados.
Los apartados de mayor interés del plan de capacidad son:
• Los escenarios del negocio. Que analizan la situación actual del negocio,
visto desde la demanda hacia TI. Se presenta la situación actual del negocio
(número de departamentos, número de usuarios, número de edificios, volu-
men de transacciones, etc.). A partir de la estrategia y planes del negocio, se
realiza una previsión sobre la evolución del negocio, en cuanto a la actividad
prevista, nueva actividad, nuevos edificios, etc. Contemplando siempre las
repercusión que tendrán en los servicios de TI.
• El resumen de los servicios. Presenta la situación actual de los servicios, mos-
trando servicio a servicio un perfil del mismo: carga, tráfico, almacenamiento,
384 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Plan de capacidad
Fuente: Libro ITIL Diseño del Servicio publicado por OGC y e.p.
Estructura de la CDB
UNE-ISO/IEC 20000-2
Del conjunto común de actividades del proceso, las principales actividades que se
pueden considerar para llevar a cabo el subproceso de gestión de la capacidad del
negocio son las siguientes:
Elaborar el plan de capacidad en el ámbito del negocio. Se centra en identificar
la evolución y las necesidades que tendrá el negocio en el período cubierto por el
plan. Las necesidades se convertirán en los requisitos que TI debe satisfacer. En esta
actividad se desarrolla el apartado del plan de capacidad relativo a los “escenarios del
negocio”, que está formado por dos subapartados: la situación actual del negocio y
la evolución prevista del negocio. El objetivo principal es predecir la evolución del
negocio en los aspectos que puedan impactar en TI, como por ejemplo, el volumen
de actividad, la variación o la diversificación de actividades, la incorporación de nue-
vas tecnologías, el impulso a la movilidad, las políticas de teletrabajo, etc.
6. Procesos de provisión de servicio
6.5. Gestión de la capacidad 389
• Distribución geográfica <tabla de usuarios por ciudades> <nueva tabla de usuarios por ciudades>
usuarios.
• Distribución funcional <tabla de usuarios por departamentos> <tabla de usuarios por departamentos>
usuarios.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
debe ejecutar las políticas de TI y utiliza como principal medio la imputación de cos-
tes, pero también tiene otras alternativas, como por ejemplo, la comunicación, la
limitación del uso (por ejemplo, el tamaño de los buzones de correo), etc. La
influencia en el uso se debe realizar con una visión general del negocio, pues muchas
veces infringe graves prejuicios e improductividad en el negocio. Además, se deben
realizar de forma alineada con la gestión de la estrategia del negocio y apoyadas en
la gestión financiera de TI.
Modelado de los servicios. En el caso de los servicios, el modelado permite definir
varios escenarios de trabajo, con variaciones en la carga que soportarán los servicios
y la cuantificación de los recursos necesarios para soportarla. El modelado se utiliza
en la etapa de diseño de los servicios. En la mayoría de los casos el resultado es una
simple tabla o gráfica que representa las diversas cargas junto con los recursos nece-
sarios. En el caso de productos software, el modelado debe partir del realizado por
los propios fabricantes, que se podrá complementar con pruebas en el escenario real,
ya que los datos de los fabricantes generalmente se referirán a configuraciones “lim-
pias” y que no consideran escenarios de compartición de los recursos.
Dimensionado de aplicaciones. Actividad muy similar al modelado cuyo resul-
tado está orientado a conocer con detalle los recursos que necesitará una aplicación
para satisfacer los niveles de servicio. Se realiza o al inicio del proyecto o en la fase
de pruebas y también se puede hacer en cambios importantes. Si se ha realizado el
modelado previamente, se utilizarán sus resultados. Se realiza principalmente en
aplicaciones críticas. En los desarrollos a medida, sólo se podrá realizar en la fase
de las pruebas finales antes de entrada en producción, sometiendo a la aplicación a
diversas situaciones de carga, utilizando para ello herramientas de generación auto-
mática. Por este motivo, es mucho más importante la identificación e incorpora-
ción de requisitos de rendimiento durante la fase de establecimiento de requisitos
técnicos al nuevo desarrollo.
Realización de informes de capacidad y rendimiento. Emisión de informes
sobre los servicios, detallando el rendimiento de los servicios, la utilización de
recursos (técnicos y humanos), la capacidad remanente, etc. Los informes se reali-
zarán de forma periódica o bajo petición, en ambos casos coordinados con el pro-
ceso de gestión de informes.
En la figura 6.5.10 se muestran los indicadores más relevantes para este proceso
recomendadas por itSMF España.
Figura 6.5.10. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
base a un proyecto llave en mano, como puede ocurrir con la continuidad, sino que
se suele realizar por el propio equipo que posteriormente llevará el proceso.
Una vez puesta en marcha, la gestión de la capacidad requiere perfiles con una pro-
funda especialización técnica en las tecnologías que se utilizan (se realiza en tuning
de aplicaciones, se resuelven problemas de rendimiento, etc.) y también es necesario
conocimiento del negocio de cara a predecir el comportamiento del mismo.
Los roles involucrados en la gestión de la capacidad se estructuran en roles propios
del proceso y roles ajenos al proceso.
Los roles propios del proceso son:
• Gestor de la capacidad. Es el responsable de la implantación del proceso defi-
nido por el propietario del modelo de gestión. También supervisa y coordina
la ejecución y el control del proceso, se encarga de proponer mejoras al pro-
ceso, realiza el plan de capacidad, tiene la visión del negocio, interactúa con
el resto de procesos, asegura que se cumplen los SLA en cuanto a la capaci-
dad y rendimiento, vela por el correcto tratamiento de los datos que utiliza
el proceso y supervisa la implementación de la monitorización.
• Administrador y soporte del proceso de capacidad. Asiste al gestor de la
capacidad en lo que necesite.
6. Procesos de provisión de servicio
6.5. Gestión de la capacidad 397
Responsable de la
gestión del servicio
Administrador y
Gestor de soporte del proceso
la capacidad de capacidad
SGSTI
Especialista
tecnológico
Especialista en Administrador
monitorización de la CDB
Propietario del
modelo (SGSTI)
Resumen
Si este proceso cayó alguna vez en el olvido, vuelve a tener plena vigencia debido a
las nuevas tendencias en TI: los ajustes en los costes, la consolidación y la virtuali-
zación de las infraestructuras de procesamiento o la reducción del consumo eléc-
trico. La necesidad de compartir plataformas requiere gestionar y controlar los
recursos que consume un servicio para evitar que interfiera en el rendimiento de
los otros.
La gestión de la capacidad es un proceso que comprende un amplio abanico de
especialidades diferentes, desde el entendimiento de la evolución del negocio, hasta
las funciones más técnicas de ajuste de las aplicaciones y de las plataformas para
conseguir un rendimiento óptimo.
6. Procesos de provisión de servicio
6.5. Gestión de la capacidad 399
Beneficios
La gestión de la capacidad es un proceso de previsión que permite anticipar las
necesidades y gestionar la dotación de fondos para conseguirlos. Por tanto, tiene
una vertiente importante en la planificación económica.
También lucha contra el despilfarro en la compra o utilización de los recursos, ajus-
tando la demanda a las infraestructuras necesarias.
En su faceta técnica pura, se centra en conseguir un rendimiento óptimo de los ser-
vicios, realizando el ajuste fino de las aplicaciones y de las plataformas.
Los principales beneficios esperados con la implantación de este proceso son los
siguientes:
• Se conocen anticipadamente las necesidades de recursos.
• Se pueden agrupar y racionalizar las compras.
• El diálogo con el negocio permite identificar los perfiles de utilización de los
servicios y reconducir el consumo que se hace de ellos por parte de los usua-
rios.
• Se controlan los gastos imprevistos por nuevos proyecto o por necesidades
de compras urgentes.
• La optimización de recursos, la revisión de la utilización de licencias, la ges-
tión de la obsolescencia del parque de equipamiento y la retirada de recursos
no utilizados, pueden generar importantes ahorros.
• La mejora del rendimiento y el tunning es una garantía para la estabilidad de
los servicios y la utilización óptima de los recursos.
• La monitorización permitirá seguir el consumo de capacidad (por ejemplo,
el consumo energético) y el rendimiento.
• El ciclo de mejora de la capacidad asegura que las instalaciones están siendo
revisadas y mejoradas continuamente.
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Cuál es el contenido del plan de capacidad de su organización?
• ¿Cómo se realizan las pruebas de rendimiento de las aplicaciones?
• Cite las dos mejores prácticas de su organización relativas al proceso
de capacidad.
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 403
estaba postergada para ser considerada parte de los procesos de provisión, que son
proactivos y alinean los servicios con los requisitos del negocio. De hecho, implan-
tar la gestión de la seguridad y sus actividades tiene bastante similitud con la
importante gestión de la disponibilidad. Ambas tienen una fase previa de implanta-
ción, se articulan en torno a un plan, participan en el diseño de los servicios, tienen
actividades proactivas, analizan los riesgos, dan su apoyo en la resolución de los
incidentes y problemas que impactan en la disponibilidad o en la seguridad, tienen
facetas reactivas, generan informes, proponen mejoras, supervisan el funciona-
miento en su ámbito, etc. Teniendo en mente estas similitudes, es más sencillo
entender las grandes directrices de la gestión de la seguridad (véase la figura 6.6.1).
La seguridad en TI ha ido evolucionando desde la resolución de crisis, a golpe de
inversión en tecnología de protección, hacia el concepto de gestión, que combina
tecnología con medidas organizativas, con procesos y con procedimientos de segu-
ridad. La evolución hacia un modelo de gestión de la seguridad de la información
viene impulsada por la Norma UNE-ISO/IEC 27001, que resalta la necesidad de
disponer de un sistema de gestión de la seguridad y la Norma UNE-ISO/IEC
17799 que detalla cada uno de los controles necesarios para garantizar la seguri-
dad.
La empresa actual debe entender la gestión de la seguridad como un proceso, que
garantice y salvaguarde su información, pero que no suponga una barrera para la
organización a la hora de desarrollar su actividad.
La gestión de seguridad de la información es el proceso con responsabilidad sobre
los niveles de seguridad de los activos utilizados para la prestación de los servicios
de TI a los clientes. En la figura 6.6.2 se presenta una introducción al proceso de
gestión de seguridad de la información.
Las Normas ISO/IEC 20000 establecen para este proceso un objetivo muy claro:
“gestionar la seguridad de la información de manera eficaz para todas las activida-
des del servicio”. El proceso de gestión de seguridad de la información debe traba-
jar para asegurar que los activos utilizados en la prestación de los servicios se
encuentren en unos niveles de exposición al riesgo aceptables para el negocio.
Por otra parte, en ITIL v3 se enuncia el objetivo con un enfoque algo diferente: “ali-
near la seguridad de TI con la seguridad del negocio y garantizar que la seguridad
de la información es gestionada de forma efectiva en todas las actividades de la ges-
tión del servicio”. Es muy interesante el matiz añadido por la versión 3, poniendo
énfasis en que la seguridad en TI esté integrada con la seguridad general de la
empresa. También destaca que la seguridad no es una isla dentro del área de TI, sino
que enfoca la actividad del proceso principalmente a velar porque los diversos gru-
pos especialistas de TI desarrollen entre sus actividades los aspectos de la seguridad.
Así, este proceso, al igual que ocurriera con la gestión de la disponibilidad, marca las
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 405
pautas, define las medidas de salvaguardia y vela por que se cumplan, más que des-
arrollar las medidas por si mismo.
Las principales ventajas que aporta el proceso son:
• Mejora la seguridad de los sistemas de información en todos sus aspectos.
Reduce el riesgo de contagio de virus, de entrada de los silenciosos troyanos,
de expansión de gusanos que saturan las comunicaciones, etc.
• Mejora el control y la custodia de los activos de información de la empresa,
implantando medidas adecuadas a la criticidad de la información o de los sis-
temas.
• La mayor protección ante las amenazas permite aumentar la fiabilidad de los
servicios, reduciendo la probabilidad de ocurrencia de incidentes de seguridad.
• Define y prepara métodos eficientes en la resolución de incidentes de segu-
ridad.
• Implementa una gestión integral de la seguridad, que proporciona una
visión conjunta del impacto de la seguridad en el negocio.
• Realiza la mejora continua de la seguridad reduciendo nivel de riesgo de los
servicios prestados a los clientes.
406 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Activo Riesgos de
seguridad
Objetivos
de control • Monitorización
de la seguridad
Amenaza
• de seguridad Declaración de Controles de
Eventos de
riesgos (SoA) seguridad • seguridad
• Vulnerabilidad Plan de
• Probabilidad tratamiento de
Incidentes
riesgos de
• Impacto seguridad de seguridad
• Nivel de riesgo
Registros de
seguridad
d
• Informes
seguridad
de
da
eg uri Comité de
es
ad seguridad
ític
Pol
de seguridad), hay que tener en cuenta los conceptos principales que se utilizan en
el proceso de gestión de seguridad de la información:
Activo de sistemas de información o elemento de configuración. Dato, infor-
mación, programa, equipo, persona o cualquier otro recurso de los sistemas de
información utilizado en la prestación de los servicios. En el ámbito de seguridad
se denomina “activo”, mientras que en el proceso de gestión de la configuración y
en el resto de procesos se utiliza el término “elemento de configuración”. Así,
activo y elemento de configuración son conceptos similares.
Amenaza. Suceso de ocurrencia probable que puede desencadenar un incidente en la
organización, produciendo daños o pérdidas materiales o inmateriales en sus activos.
Análisis de riesgos de seguridad. Actividad que proporciona información relativa
a las amenazas de seguridad que pueden afectar a los servicios, así como, la probabi-
lidad de que ocurran. En TI se suele realizar un análisis de riesgos específico en cada
uno de los tres procesos (incidentes, continuidad y seguridad), pero con objetivos
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 409
y, para cada uno de estos, se establecen los controles que harán posible alcanzar
el objetivo fijado. Las Normas ISO/IEC 27001 e ISO/IEC 17799 establecen cerca
de 40 posibles objetivos de control de la seguridad de la información.
Registro de seguridad. Información relativa a un aspecto o un evento de seguri-
dad que se almacena de una forma controlada. Los registros son un instrumento
esencial en las normas para desarrollar el principio de auditabilidad.
Plan de tratamiento de riesgos (RTP, Risk Treatment Plan). Documento base
que articula la implantación de la gestión de los riesgos.
Plan Director de Seguridad de la Información (PDSI). Nombre un poco rimbom-
bante que se suele dar al documento que unifica todas las acciones a varios años para
transformar la seguridad. Tiene categoría de plan estratégico. Normalmente contiene
el plan de implantación del proceso o del SGSI, y el plan de tratamiento de riesgos.
Probabilidad. Frecuencia con la que puede ocurrir un suceso, o la relación entre el
número de casos favorables y el número de casos totales.
Riesgo. Es la posibilidad de que se materialice una amenaza y ésta cause un
impacto en un determinado servicio o activo. El riesgo es función de la magnitud
de la amenaza, de la vulnerabilidad al mismo de los servicios y de la probabilidad
de que ocurra el suceso. En torno al riesgo aparecen un conjunto de actividades:
• Aceptación del riesgo. Decisión de aceptar un riesgo.
• Análisis del riesgo. Sistemática de uso de información para identificar fuen-
tes y estimación del riesgo.
• Valoración del riesgo. Todo el proceso de análisis y evaluación del riesgo.
• Evaluación del riesgo. Proceso de comparar un riesgo estimado con el
riesgo dado por los criterios para determinar la importancia del riesgo.
• Tratamiento o gestión del riesgo. Proceso de selección e implantación de
las medidas para cambiar el riesgo.
UNE-ISO/IEC 20000-2
Generalidades
El personal del proveedor del servicio
La seguridad de la información es el con roles de especialista en seguridad
resultado de un sistema de políticas y de la información debería estar familia-
procedimientos diseñados para identifi- rizado con la norma ISO/IEC 17799,
car, controlar y proteger la información y Tecnologías de la información. Técni-
cualquier equipamiento empleado junto cas de seguridad. Código de prácticas
con el almacenamiento, transmisión y para la gestión de la seguridad de la
procesamiento de dicha información. información.
Las entradas desencadenantes del proceso son la definición de una política de segu-
ridad en el negocio, que origina el inicio de la creación del proceso; los requisitos
de seguridad del negocio concretados en los acuerdos de nivel de servicio; la ocu-
rrencia de un incidente severo de seguridad, pues este proceso colabora con la ges-
tión del incidente en la gestión de la crisis; y la llegada de un conjunto de fechas
específicas (de pruebas de seguridad, de revisión del plan de tratamiento de riesgos
o las fechas de las revisiones o auditorías).
El proceso utiliza unas entradas de soporte de otras fuentes necesarias para llevar a
cabo sus cometidos. Entre dichas entradas destacan el análisis de riesgos realizado en
el plan de continuidad de TI, pues en caso de que se haya realizado aportará un enten-
dimiento mejor del negocio y de los riesgos; la información de incidentes y de los pro-
blemas ocurridos relacionados con la seguridad; los datos de la monitorización de los
sistemas y de la seguridad; los cambios en curso para supervisar que se evalúe su segu-
ridad; la información de los activos y de la CMDB; el entorno legal y regulatorio que
influye en la seguridad; los presupuestos asignados a la seguridad; etc.
Las salidas principales del proceso son la política de la seguridad definida; los resul-
tados de la evaluación de riesgos de seguridad; el plan de tratamiento de los riesgos;
la declaración de riesgos; los objetivos de control y los controles seleccionados; los
resultados de las auditorías de seguridad; o los informes relativos a la seguridad y
sus indicadores.
Las salidas secundarias, o de menor importancia, que se obtienen del proceso son,
por ejemplo, los requisitos formalizados para la seguridad; el plan de proyecto para
implantar el proceso de seguridad; los procedimientos para detección y respuesta a
incidentes de seguridad; una clasificación de los activos en cuanto a su criticidad; el
personal de TI y de la empresa concienciado; los informes de los resultados de las
pruebas de seguridad; etc.
En la definición de las actividades del proceso se han tenido en cuenta lo establecido
en la Norma ISO/IEC 27001 en su apartado 4.2, que agrupa las actividades de
gestión de la seguridad en torno al ciclo PDCA de Deming (véase la figura 6.6.6).
Extrayendo cada epígrafe del apartado 4.2 de la Norma ISO/IEC 27001 se esta-
blecen un total de 30 actividades. En la figura 6.6.7 se relacionan éstas.
Como se ha mencionado anteriormente, en este libro se ha decidido respetar lo defi-
nido en ISO/IEC 27001 como la mejor vía para llevar a cabo los requisitos estable-
cidos en las Normas ISO/IEC 20000, además, para facilitar el entendimiento de las
actividades, se ha realizado una agrupación intermedia. De esta forma, en el presente
proceso las actividades de gestión de la seguridad quedan estructuradas en dos nive-
les: el primero alineado el ciclo PDCA de ISO/IEC 27001, mientras que el segundo
nivel permite entender mejor el transcurso del proceso.
414 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
P – Planificar A – Actuar
Creación del proceso o SGSI Mantenimiento y mejora
Establecer política, objetivos, evaluar el riesgo, Plan Implementar mejoras, acciones correctivas
seleccionar controles, obtener la aprobación Planificar y preventivas, comunicar resultados,
de la dirección, declaración de riesgos. asegurar implantación de las mejoras.
Do Act
Hacer Actuar
D – Hacer Check C – Verificar
Implementación y operación Verificar Supervisión y revisión
Plan de tratamiento del riesgo, implementar Supervisar, monitorizar, revisiones regulares,
controles, formación, implantar procedimientos medir la efectividad, auditorías, actualizar
gestión incidentes de seguridad. planes, registro de acciones y eventos.
En la figura 6.6.8 se muestra un esquema con las actividades del proceso, realizado
imitando el ya legendario esquema de gestión de la continuidad de ITIL v2.
Análisis de riesgos
Evaluación de riesgos
de seguridad
Selección de objetivos de
• Requerimientos y estrategia
control y sus controles
Declaración de
Declaración de riesgos
riesgos de seguridad
Pruebas iniciales
Prueba de Supervisar,
Supervisión
controles monitorizar
y revisión
CHECK
Actualizar
Mantenimiento y mejora
ACT
Fuente: e.p. a partir del libro ITIL Provisión de Servicio publicado por OGC y de UNE-EN ISO 27001.
seguridad (si se está aplicando ISO/IEC 27001). La creación del proceso se realiza
en las etapas de inicio, y de requerimientos y estrategia, al igual que en la implanta-
ción de los procesos de continuidad y disponibilidad. En el inicio se establece el
entorno necesario para que comience la implantación de la gestión de la seguridad.
A partir del entorno del negocio, se determinan los requerimientos de seguridad, se
identifican los riesgos, se acuerda el tratamiento a los mismos, se establecen los
objetivos de control y se seleccionan los controles adecuados para conseguir estos
objetivos, y se realiza la declaración formal de los riesgos.
• Alcance, política y enfoque. Se concretan las directrices que debe cumplir
el proceso:
– Definir el alcance (4.2.1.a 1): se concreta el alcance y los límites del pro-
ceso en términos de las características de la actividad del negocio, de la
organización, su ubicación, sus activos y tecnología, incluyendo los deta-
lles y la justificación de cualquier exclusión del alcance.
– Definir una política de seguridad (4.2.1.b): que incluya un marco para
la fijación de objetivos y establezca una orientación general; que tenga en
cuenta los requisitos de la actividad del negocio, los requisitos legales y las
obligaciones contractuales.
– Definir el enfoque de la evaluación de riesgos de la organización
(4.2.1.c): la metodología seleccionada para la evaluación de riesgos debe
asegurar que las evaluaciones de riesgos generen resultados comparables y
reproducibles.
1
Entre paréntesis la referencia al epígrafe equivalente en la Norma UNE-ISO/IEC 27001.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 417
2
SoA, Statement of Applicability.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 419
seguridad, pues los controles son de todo tipo, unas veces serán directrices
internas, otras la designación de funciones, otras requerirá la compra de
equipamiento o de soluciones software, puede ser necesario cambiar la con-
figuración de los sistemas, etc.
– Definir el modo de medir la eficacia de los controles (4.2.2.d): la
medición de la eficacia de los controles permite determinar hasta qué
punto los controles cumplen los objetivos de control planificados. Se
define la forma de medir la eficacia de los controles o de los objetivos
de control seleccionados, también se especifica cómo se tienen que usar
estas mediciones.
Enfoque del proceso en ITIL v3 muy similar a 27001 Actividades de gestión de la seguridad en ITIL v3
UNE-ISO/IEC 20000-1
La dirección, con la autoridad apropiada, debe aprobar una política de seguridad
de la información, que debe comunicarse a todo el personal implicado y, cuando
sea adecuado, a los clientes.
El comité de seguridad
La política de seguridad conviene que esté respaldada por un órgano interno en el
que se traten todas las cuestiones que precisen de la intervención de la dirección,
además de servir como instrumento que ejecuta el compromiso con la seguridad de
la información.
El comité de seguridad, por su composición, se convierte en el asesor del responsa-
ble de seguridad para las decisiones de mayor nivel en la organización en los asun-
tos relacionados con la seguridad de la información. Al frente del mismo se encuen-
tra el responsable del proceso de seguridad. El comité se debería reunir con una
periodicidad mínima mensual. El resultado de las reuniones de este comité deberá
quedar reflejado en unas actas de reunión.
El comité de seguridad se responsabiliza de:
• El asesoramiento al responsable de seguridad.
• La comunicación a toda la organización de la importancia de cumplir tanto
los requisitos de la norma como los legales y reglamentarios.
• La evolución de la política y objetivos de la seguridad.
• El aseguramiento de la disponibilidad de presupuestos y recursos adecuados.
• La aprobación y respaldo ejecutivo a los planes de implantación y de trata-
miento de riesgos de la organización.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 425
• Que se realicen todas las actividades del proceso, desde la creación, hasta el
mantenimiento y mejora.
• La revisión de los temas de seguridad más relevantes para la empresa u orga-
nización.
Evaluación de riesgos
Es recomendable que la evaluación de riesgos de seguridad y su tratamiento esté
basada en alguna de las metodologías existentes relacionadas con esta materia,
como por ejemplo, CRAMM, NIST, Magerit, etc. Cada organización puede deci-
dir utilizar la metodología que considere más adecuada.
ISO/IEC 20000-2 recomienda además que la evaluación de riesgos se realice con
una periodicidad, que se registre, que se mantenga actualizada con los cambios, etc.
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
Se lleva a cabo un análisis de las amenazas que pueden derivarse de cada una de
estas fuentes, en función de los activos existentes en la organización, los procesos y
servicios prestados, la posición en el mercado, el tipo de clientes y los antecedentes.
Las amenazas se irán reflejando en el análisis de riesgos, detallándose:
• Tipo de amenaza. Por ejemplo, robo de información.
• Motivo. Se indican los motivos que pueden provocar que una amenaza se
materialice.
• Resultado (ataque o incidente). Se indican las consecuencias que tendría
para la organización cada una de las amenazas en caso de materializarse. Los
resultados tendrán alguna de las siguientes consecuencias sobre la informa-
ción: visualización, modificación, destrucción o pérdida, e interrupción.
Riesgo Impacto
El nivel de riesgo de cada amenaza deberá cruzarse con cada uno de los activos. De
este modo se conoce el riesgo total soportado por cada uno de los activos. Este
riesgo total es ponderado en función de la importancia dada al activo en el
momento de su identificación. Para cada uno de los activos se tendrá un nivel de
riesgo ponderado.
Determinar si los riesgos son aceptables. Con los valores de los riesgos calculados
se determinan los riesgos asumibles por la organización y los que no son aceptables.
• Evitar el riesgo.
• Transferir el riesgo a terceros (seguros, proveedores, etc.).
UNE-ISO/IEC 20000-1
Los controles se asocian a cada uno de los riesgos con el nivel de detalle necesario.
La selección de controles debe:
434 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Para cada una de estas áreas de gestión de la seguridad se establecen sus objetivos
de control. Para cada objetivo de control se establece un conjunto posible de con-
troles. En ISO/IEC 27001 se propone un total de 39 objetivos de control y 133
controles. En la figura 6.6.13 se muestra un ejemplo de este contenido.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 435
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
Este mismo tema de terceros está desarrollado también en ISO/IEC 27001 (véase
el apartado A.6.2 “Terceros”) que establece como objetivo “mantener la seguridad
de la información de la organización, así como la de los dispositivos de procesado
de la información que son objeto de acceso, tratamiento, comunicación o gestión
por terceros”.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 437
UNE-ISO/IEC 20000-1
Los incidentes de seguridad se deben comunicar y registrar tan pronto como sea
posible de acuerdo a los procedimientos de gestión del incidente. Se deben poner
en marcha procedimientos para asegurar que todos los incidentes de seguridad son
investigados, y que se toman medidas al respecto.
Se deben poner en marcha mecanismos para poder cuantificar y monitorizar los
tipos, volúmenes e impacto de los incidentes y el mal funcionamiento de la seguri-
dad. Las acciones de mejora identificadas durante este proceso se deben registrar y
servir como información de entrada al plan de mejora del servicio.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 439
UNE-ISO/IEC 20000-2
Documentos y registros
Los registros se deberían analizar perió- c) dar entrada de información a un
dicamente para proporcionar informa- plan de mejora del servicio;
ción a la dirección en cuanto a: d) tener bajo control el acceso a la
a) la eficacia de la política de segu- información, los activos y los sis-
ridad de la información; temas.
b) las tendencias que aparezcan en La gestión de la seguridad de la infor-
los incidentes en seguridad de la mación debería estar documentada de
información; una manera fiable.
440 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
La documentación debe incluir las decisiones de la dirección junto con los registros
de las mismas, debiendo quedar constancia de que las acciones dan respuesta a las
decisiones y a las políticas adoptadas, y garantizando que dichos documentos y los
correspondientes registros están disponibles (véase el apartado 4.3 de la Norma
UNE-ISO/IEC 27001).
La gestión de la seguridad se puede implementar como un proceso más dentro del
sistema de gestión del servicio de TI (SGSTI) o en base a un sistema de gestión
específico para la seguridad (SGSI). De cara a simplificar y mantener una coheren-
cia, todos los modelos de gestión relativos a TI deberán implementarse bajo el
paraguas formal del sistema de gestión de la calidad definido en la Norma ISO
9001. En la figura 6.6.14 se muestra esta tendencia a la unificación de los sistemas
de gestión en TI (véase el capítulo 3).
La documentación del SGSI debe incluir (véase el apartado 4.3 de la Norma UNE-
ISO/IEC 27001):
• Las declaraciones documentadas de la política y de los objetivos del SGSI.
• El alcance del SGSI.
• Los procedimientos y mecanismos de control que soportan al SGSI.
• Una descripción de la metodología de evaluación de riesgos.
• El informe de evaluación de riesgos.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 441
ISO/IEC ISO/IEC
20000 27001
Fuente: Telefónica.
Este proceso se apoya también en otros roles relevantes para el mismo y que son
ajenos al proceso:
444 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Resumen
El incremento continuo de las amenazas hace que la seguridad de la información
sea cada vez un aspecto más crítico en las empresas. La red Internet es el cauce por
el que llegan la mayoría de ellas. Si las amenazas han aumentado por esta vía, las
vulnerabilidades también: la conectividad desde cualquier lugar, la proliferación de
aparatos tecnológicos en el mercado de consumo en la empresa, la gran capacidad
de los dispositivos de bolsillo en la empresa, etc.
La seguridad se ha convertido en los cimientos sobre los que se sustenta la infor-
mación de la empresa, cimientos que hay que cuidar continuamente para que no
pierdan su solidez.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 445
Responsable de la
gestión del servicio
Dirección
SGSTI
SGSI
Responsable
de seguridad
Administrador y
soporte del proceso
Áreas técnicas de seguridad
Gestor continuidad TI
Beneficios
Entre los beneficios más relevantes que proporciona la gestión de la seguridad de la
información destacan los siguientes.
• Protege y aumenta la robustez y seguridad de los sistemas de información,
realizando un tratamiento adecuado de los riesgos, reduciendo el riesgo de
sustracción o pérdida de información esencial.
• Proporciona confianza a todas las partes. A la dirección porque sus activos
están mejor protegidos, al mercado porque son más robustos los sistemas, y
al departamento de TI porque le permite cumplir las exigencias de la dirección.
• Asegura que los incidentes de seguridad de la información son correcta-
mente gestionados, reduciendo su impacto en el negocio.
• Establece auditorías de seguridad con regularidad, que comprueban la ade-
cuación de las medidas de seguridad implantadas.
• Aporta información a la dirección sobre el estado de seguridad de la empresa
u organización, de cara a adoptar las medidas que se consideren oportunas.
• Fortalecimiento de la imagen ante el mercado y confianza de los clientes en
una organización que apuesta por la seguridad de la información.
• Ahorro de costes por evitar incidentes de seguridad, en primas de seguros,
por sanciones derivadas de incumplimientos legales, etc.
6. Procesos de provisión de servicio
6.6. Gestión de la seguridad de la información 447
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 3:
• ¿Cómo se realiza la gestión de la seguridad de la información en su
empresa?
• ¿Está la dirección de su empresa implicada en la gestión de la seguri-
dad de la información?
• ¿La gestión de la seguridad se trata en su organización como un
ámbito independiente o de forma integrada con los otros procesos de
gestión de los servicios de TI?
3 Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
7 Procesos de
Capítulo 7
relaciones
7.1. Generalidades
Con el fin de garantizar que el proveedor de TI trabaje alineado con las necesida-
des de la empresa, las Normas ISO/IEC 20000 establecen los procesos de relacio-
nes. Regulan las relaciones en los dos extremos de la cadena de provisión de TI. Por
una parte se definen las relaciones con el negocio y, por otra, las relaciones con los
suministradores.
La misión de la gestión de las relaciones con el negocio es garantizar que se crean,
mantienen y mejoran continuamente los servicios de TI que necesita la empresa. Al
igual que en ITIL, en ISO/IEC 20000 el negocio está representado por la figura
del cliente. Se entiende como “cliente” a la persona, área o áreas de la empresa que
especifican los servicios de TI que necesitan y acuerdan los SLA. Para ello, el pro-
ceso de gestión de las relaciones con el negocio servirá de interlocución único entre
el cliente y la organización de TI, para la identificación de necesidades y la provi-
sión de los servicios. Cuenta con la colaboración continua de la gestión de nivel de
servicio y de otros procesos, para tratar de encontrar el balance correcto entre la
demanda del cliente, la provisión de los servicios, el coste de los mismos y la satis-
facción del cliente.
Por otra parte, hay que tener presente que los servicios que TI ofrece se construyen
formando un “puzzle” de piezas tecnológicas, adecuadamente integradas y gestio-
nadas. Para mantener en marcha este puzzle de tecnologías, la organización de TI
necesita suministradores diversos: de hardware, de productos software, integrado-
res, consultores, empresas de servicios, etc. La gestión adecuada de dichos suminis-
tradores es también esencial para poder garantizar los niveles de servicio requeridos.
En este capítulo se presentan las mejores prácticas para el éxito en la gestión de las
fronteras de la organización de TI: con el negocio y con los suministradores.
7. Procesos de relaciones
7.1. Generalidades 453
7.1. Generalidades
Con frecuencia se oye hablar de la importancia de una gestión adecuada de las rela-
ciones, especialmente en el ámbito de TI. Pero, ¿en qué consiste la gestión de una
relación?, aunque esta disciplina parece atractiva, no es fácil concretar su contenido
y conseguir con ello un aporte real a la mejora del servicio de TI.
En general, se puede decir que la gestión de una relación es aquella disciplina que
establece el método para que la interacción entre dos partes sea eficaz, ayuda a que
transcurra con las mínimas fricciones y contribuye a que sea duradera (véase la
figura 7.1.1). Los mecanismos habituales que permiten regular y organizar una
relación compleja son los siguientes:
• El establecimiento de los objetivos principales que se quieren conseguir con
la relación.
• La definición de los diversos interlocutores por cada parte, los perfiles perso-
nales y las habilidades necesarias.
• La utilización de un marco, reglas y lenguaje común aceptado por ambas
partes.
454 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Los principales actores en los procesos de relación son los clientes de los servi-
cios (tanto internos de otras áreas de la empresa, como clientes comerciales rea-
les), el proveedor del servicio de TI (organización de TI o área de TI a la que
se esté aplicando estas normas) y los suministradores (que proporcionan bienes
o servicios a la organización de TI, que pueden ser internos de la empresa o
externos).
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Esta norma se dirige hacia el rol de un de servicio o de soporte interno que son
proveedor del servicio, el cual cumple a menudo designados como acuerdos
un papel entre los suministradores, que de nivel operacional.
proporcionan bienes o servicios a dicho
El proveedor del servicio juega un papel
proveedor del servicio, y los clientes, que
dentro de la cadena de suministro, en la
reciben los servicios.
cual cada eslabón debería añadir valor,
Tanto los suministradores, como los de forma que el proveedor del servicio
clientes pueden ser internos y externos que recibe bienes o servicios proceden-
a la organización del proveedor del tes del suministrador y entrega un servi-
servicio. cio mejorado al cliente.
Las relaciones externas se formalizarán A modo de aclaración, dentro de esta
mediante contratos. Las relaciones inter- sección el término proveedor del servicio
nas se formalizarán mediante acuerdos se utiliza siempre para describir la orga-
7. Procesos de relaciones
7.1. Generalidades 455
Si se echa una mirada a ITIL v2, se aprecia que no establece ningún proceso espe-
cífico que describa la relación con los suministradores, aunque hace mucho hinca-
pié en que los contratos con suministradores (contratos de soporte, Underpinning
Contracts o UC) respalden los compromisos del nivel de servicio que TI asume con
sus clientes. En cambio, en ITIL v3 el libro Diseño del Servicio define específica-
mente un proceso de gestión de suministradores.
En el marco para el gobierno y auditoría de TI (COBIT) de estos temas se encuen-
tran referencias, indicadores y controles centrados principalmente en el control de
las adquisiciones y el gobierno de TI. No trata específicamente las relaciones con el
negocio ni las relaciones con los suministradores bajo el concepto de proceso.
En el ámbito del desarrollo de software, las relaciones tanto con el cliente como con
los suministradores de desarrollo, están bastante detalladas en el modelo CMMI. Asi-
mismo, la universidad Carnegie Mellon también ha desarrollado el marco eSCM-SP
(eSourcing Capability Model for Service Providers) formado por 84 prácticas específicas
para la gestión de suministradores y el ciclo de vida del sourcing en TI.
Además, existen otros marcos de mejores prácticas en los que se trata la mejora de
las relaciones con los suministradores, como por ejemplo, el modelo ISPL (Infor-
mation Services Procurement Library1), que es un compendio europeo de mejores
1
Véase http://projekte.fast.de/ISPL/.
456 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
prácticas para la provisión y prestación de proyectos y servicios TI. ISPL fue publi-
cado en 1999 por un consorcio de 5 organizaciones europeas dentro del programa
SPRITE-S2 de la Comisión Europea y se basó en la experiencia de más de 200 pro-
cesos de compra reales en TI. Trata la definición de una estrategia de aprovisiona-
miento de servicios (sourcing), así como las etapas posteriores: peticiones de oferta,
establecimiento del contrato, planificación de la provisión y seguimiento de la eje-
cución. ISPL hoy está en desuso, por lo que la llegada del proceso en ITIL v3 es
bien acogida por el mercado.
Otros modelos sectoriales también tratan el entorno de la gestión de suministrado-
res, como es el caso del modelo eTOM para el sector de las telecomunicaciones,
que contempla procesos como por ejemplo, la gestión de partners/suministradores
o la gestión de la cadena de suministro.
7. Procesos de relaciones
7.2. Gestión de las relaciones con el negocio 457
Figura 7.2.1. Actividades del proceso de gestión de las relaciones con el negocio
Las empresas e instituciones tienen cada vez una mayor dependencia de las tecnolo-
gías de la información. Los departamentos de TI, y las actividades que desarrollan,
han sido vistos tradicionalmente como una carga y un coste para el negocio, infrauti-
lizándose el potencial de la tecnología para ponerse en primera línea, aportando ideas
y abriendo nuevas oportunidades para la empresa. Para que las tecnologías de la
información estén alineadas con las necesidades de la empresa, es necesario instru-
mentar una vía de comunicación permanente, regulada y eficaz entre TI y el negocio.
La gestión de las relaciones con el negocio asegura que la comunicación entre TI y
sus clientes sea clara y fluida (véase la figura 7.2.1). Se entiende como “cliente” a
las áreas internas de la empresa o a las unidades externas que especifican y contra-
tan los servicios de TI, diferenciándolo así de la figura del “usuario” que es la per-
sona que utiliza los servicios. Igual que el centro de atención al usuario (service desk)
es el punto único de contacto entre TI y la comunidad de usuarios, el proceso de
gestión de las relaciones con el negocio se convierte en canal único de la comunica-
ción reglada entre TI y el negocio.
Este proceso se preocupa de dar una respuesta adecuada a las demandas del cliente,
actuando de interfaz entre el negocio y las áreas de TI. Vela por la satisfacción del
458 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Fuente: Telefónica.
Para el desarrollo con éxito de la misión de este proceso es necesario que el perso-
nal involucrado en él, por parte de TI, conozca a fondo la naturaleza del propio
negocio. Pero también es imprescindible que estos profesionales conozcan perfec-
tamente a TI y sus capacidades, para saber qué puede ofrecer y en qué condiciones.
460 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
El espíritu de servicio al cliente es otro de los valores a buscar y potenciar entre los
participantes en este proceso, pero no es un requisito exclusivo del mismo, sino que
debe hacerse extensivo a toda la organización de TI. El rigor en la relación facili-
tará a TI alinearse con el negocio, tomando nota de las necesidades, formalizándo-
las en requisitos, redactando las actas de las mismas, realizando un seguimiento del
cliente e impulsando en el resto de TI al cumplimiento de las demandas. Así, estos
cuatro pilares en los que se sustenta este proceso se muestran en la figura 7.2.4.
Catálogo Necesidades
de servicios Servicios nuevos
o modificaciones
Cli
SLA: ent
e
Acuerdo PDCA
de nivel de SGSTI
servicio
TI
Informes Mejoras
del servicio
Reclamaciones Programa de mejora
al servicio del servicio (SIP)
Reuniones cliente-TI,
Encuestas y entrevistas
demanda y revisión
de satisfacción
del servicio
comunicación con el cliente para los otros procesos. Se conforma así como un
punto único de relación con las áreas cliente de TI. El proceso interviene en las pri-
meras etapas de la creación de servicios (véase el capítulo 5) y engrana con la ges-
tión de nivel de servicio, tanto para la creación como para la prestación de los mis-
mos (véase el apartado 6.1). Las principales actividades del proceso son:
• Identificación de los clientes. En la implementación de este proceso, una
de las primeras actividades es la identificación de las áreas cliente y conseguir
que estas designen a sus representantes legítimos y reconocidos interna-
mente. Con los clientes identificados se podrá determinar la carga de trabajo
7. Procesos de relaciones
7.2. Gestión de las relaciones con el negocio 465
UNE-ISO/IEC 20000-1
El proveedor del servicio debe identificar y documentar quienes son los actores prin-
cipales y los clientes de los servicios.
• Objetivos y alcance.
• Descripción del servicio:
– Funcionalidad.
• Seguridad y continuidad.
• Estimación de plazos de provisión y entrega.
• Estimación de costes asociados.
• Indicadores y métricas de gestión.
• Mecanismos de control y seguimiento de los
niveles de servicio acordados.
Fuente: Telefónica.
Los resultados o salidas principales del proceso de relaciones con el negocio son los
requisitos de servicio acordados con el cliente, los SLA firmados, los informes de
seguimiento entregados al cliente, los resultados de las encuestas de satisfacción al
cliente y las propuestas de mejora. Otras salidas del proceso son, por ejemplo, los
informes emitidos sobre cómo se han resuelto las reclamaciones, las actas de las
reuniones con el cliente, etc.
La definición de los requisitos puede resultar difícil, pues puede que el negocio no
sepa exactamente lo que quiere, por lo que pueden necesitar ayuda para compren-
der y definir sus necesidades. Hay que tener en cuenta que los requisitos expresa-
dos al inicio irán concretándose y diferirán de los que finalmente se acuerden. Si se
realiza facturación del servicio, es frecuente que las diferencias entre lo solicitado
inicialmente y lo acordado sea mayor. Pueden ser necesarias varias tandas de nego-
ciaciones antes de lograr el equilibrio entre lo que se busca y lo que económica-
mente se puede conseguir.
En la figura 7.2.10 se muestra un ejemplo de estructura para el SLR.
• Objetivos y alcance.
• Acuerdo de nivel de servicio firmado.
• Datos de contacto del cliente.
• Fecha de solicitud.
• Descripción del servicio:
– Nombre del servicio.
– Descripción de las funcionalidades requeridas.
• Características del servicio:
– Fecha de inicio del servicio .
– Fecha de finalización/desconexión del servicio.
– Horario del servicio y soporte.
– Requerimientos de disponibilidad y fiabilidad.
– Requerimientos de seguridad y continuidad.
– Requerimientos de interfaces.
– Requerimientos de rendimiento (tiempos de respuesta).
– Requerimientos de explotación y operación.
• Diseño del nivel de servicio.
– Modificaciones en caso necesario a los acuerdos de nivel
de servicio existentes.
• Responsabilidad del diseño/departamentos involucrados:
– Nombre del departamento.
– Participación requerida.
– Responsables y datos de contacto.
• Planificación.
• Fecha requerida de disponibilidad.
UNE-ISO/IEC 20000-1
El proveedor del servicio y los clientes se deben reunir, al menos una vez al año,
para la revisión del servicio y para discutir cualquier cambio en el alcance del
mismo, en el SLA, en el contrato (si existe) o en las necesidades del negocio. Se
deben mantener reuniones a intervalos acordados para discutir el comportamiento y
las prestaciones, los cumplimientos, asuntos varios y planes de acción. Estas reunio-
nes se deben documentar.
A las reuniones puede invitarse a otros actores relacionados con el servicio.
Los cambios al contrato(s), si existen, y al SLA deben ser el resultado de las reunio-
nes mencionadas, cuando sea apropiado. Estos cambios deben estar sujetos al pro-
ceso de gestión del cambio.
El proveedor del servicio debe permanecer al tanto de las necesidades del negocio y de
los principales cambios en el mismo para preparar una respuesta a dichas necesidades.
UNE-ISO/IEC 20000-2
El proveedor del servicio y los clientes previo, tratar las necesidades de nego-
deberían realizar revisiones del servicio, cio actuales y previstas y proponer cual-
al menos anualmente y antes y después quier cambio necesario en el alcance
de cambios importantes. La revisión del servicio y los SLA. Otros grupos de
debería considerar el comportamiento interés implicados como por ejemplo
472 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Conviene destacar varios aspectos que se deben tener en cuenta en las revisiones
del servicio con los clientes, apuntados por estas normas, pues suponen un avance
a muchas de las prácticas actuales. Son las siguientes:
• El gestor de la relación debe reunirse de forma periódica con todas las áreas
cliente para revisar el servicio, los niveles de servicio prestados frente a los
requeridos en el SLA, el grado de satisfacción del cliente, etc. Se trata de eva-
luar la calidad del servicio desde el punto de vista del cliente.
• El mantenimiento de reuniones en los plazos acordados y, como mínimo,
una vez al año. Lo habitual es que las reuniones de revisión con los clientes
sean mensuales. En servicios críticos en períodos de inestabilidad las reunio-
nes pueden llegar a ser semanales.
• Las reuniones de revisión deberían estar procedimentadas, para que transcu-
rran de una forma eficiente y no se deje ningún tema sin tratar. De estas reu-
niones debe haber un acta formalizada y aprobada por todas las partes.
• A las reuniones con los clientes se puede invitar a otros actores, pues la rela-
ción con el cliente no es un coto cerrado. Ahora bien, la asistencia de diver-
sos miembros debe ser preparada para presentar entre todos una imagen de
TI coherente y alineada hacia los mismos objetivos. No hay nada más
penoso que una discusión interna de TI delante del cliente.
• Como consecuencia de estas reuniones, surgirán propuestas de cambio al
servicio o al SLA. Toda propuesta de cambio se gestionará con una petición
de cambio reglada (RFC) que pasará al control del proceso de gestión del
cambio.
• Este contacto permanente debe aprovecharse para que TI esté al tanto de
la situación y evolución del área de negocio, con el objetivo de facilitar la
7. Procesos de relaciones
7.2. Gestión de las relaciones con el negocio 473
anticipación de TI. Por ello, el gestor de las relaciones con el negocio debe-
ría concretar esta información obtenida en un informe, o un comunicado por
escrito, a la dirección de TI o al área de estrategia de TI, de los cambios de
tendencia junto con una predicción sobre las demandas futuras del área
de negocio hacia TI.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Ficha de reclamación
En las Normas ISO/IEC 20000 no queda clara la distinción del término cliente
(área cliente de TI que especifica los servicios) y de usuario (persona que utiliza los
servicios). Por lo que el tratamiento de la medición de la satisfacción del cliente en
estas normas se debe entender que corresponde a los dos ámbitos: al cliente y al
usuario.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe tener una o varias personas asignadas como respon-
sable(s) de gestionar la satisfacción del cliente y todo el proceso de gestión de rela-
ciones con el negocio. Debe existir un proceso de medición periódica de la satisfac-
ción del cliente para obtener información y comentarios, y actuar en consecuencia.
Las acciones de mejora que se identifiquen durante este proceso se deben registrar y
utilizar como información de entrada para un plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Se debería medir la satisfacción del de forma que los clientes puedan respon-
cliente para permitir al proveedor del ser- der fácilmente y sin que se requiera un
vicio comparar el desempeño con los excesivo tiempo para cumplimentar de
objetivos de satisfacción de clientes y con una manera adecuada dicha encuesta.
encuestas previas. El alcance y la comple- Se deberían investigar las variaciones
jidad de la encuesta se deberían concebir significativas en los niveles de satisfac-
7. Procesos de relaciones
7.2. Gestión de las relaciones con el negocio 477
ción para llegar a entender las razones deberían tratar con el cliente. Se debe-
de las mismas. ría acordar un plan de acción, utilizán-
Los análisis de tendencias u otras com- dolo como entrada para un plan de
paraciones solo deberían realizarse mejora del servicio sobre cuyo progreso
sobre preguntas comparables y entre se informe al cliente.
métodos de muestreo comparables. Las felicitaciones sobre el servicio se
Los resultados y conclusiones de las deberían documentar y dar a conocer al
encuestas de satisfacción del cliente se equipo que esté prestando el servicio.
Fuente: Telefónica.
Figura 7.2.12. La misión de punto de contacto único con el cliente de este proceso
Los roles de mayor relevancia que participan en el proceso de gestión del cambio
se representan en la figura 7.2.14.
Entre las habilidades y aptitudes necesarias, tanto del responsable del proceso
de gestión de relaciones con el negocio como de los gestores de cliente, deben
destacar:
7. Procesos de relaciones
7.2. Gestión de las relaciones con el negocio 481
Responsable de la
gestión del servicio
Gestor de las relaciones
SGSTI
con el negocio
Propietario del
modelo (SGSTI)
Administrador y soporte
del proceso de relaciones
con el negocio
Figura 7.2.14. Roles del proceso de gestión de las relaciones con el negocio
• Innovación respecto a la calidad del servicio y los modos en que puede mejo-
rarse dentro de los límites de la organización.
• Saber escuchar y tener la capacidad de aplicar los conocimientos recién
aprendidos de una manera efectiva.
Resumen
La gestión de la relación con el negocio permite una mejor alineación continua de
TI-Negocio, facilita y formaliza la relación para asegurar que la actividad de TI se
enfoca a las necesidades de la empresa.
Establece una disciplina de comunicación que, con un conjunto de documentos,
permite mejorar la efectividad de la relación. Los principales medios de formaliza-
ción que aporta o utiliza este proceso son:
• El catálogo de servicios, que constituye la base para el diálogo.
• Las necesidades del cliente se registran en una hoja de requerimientos del
servicio (SLR).
• Se negocia la formalización de los compromisos mediante los acuerdos de
nivel de servicio (SLA).
• Se mantienen reuniones de seguimiento periódicas del servicio prestado.
• Las quejas del cliente se registran como reclamaciones.
• Se conoce la opinión del cliente y de los usuarios mediante encuestas y entre-
vistas.
Beneficios
La gestión de las relaciones con el negocio se asegura de que las actividades lleva-
das a cabo en la provisión de los servicios contribuyen a los objetivos de negocio
del cliente. Entre los beneficios obtenidos destacan:
• Se asegura que el objetivo de TI es la satisfacción del cliente y que ésta se
mide.
• Saca a TI de su mundo tecnológico para orientarse al negocio.
• Fuerza a TI a trabajar para lo que necesita el negocio.
• Las relaciones con las áreas cliente se gestionan con mayor profesionalidad.
7. Procesos de relaciones
7.2. Gestión de las relaciones con el negocio 483
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Cómo se desempeñan las relaciones entre TI y las áreas de negocio en
su organización?
• ¿Cómo se tratan las quejas de los clientes en su empresa?
• ¿Cuál es la frecuencia y contenido principal de las encuestas a las áreas
cliente en su organización?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
7. Procesos de relaciones
7.3. Gestión de suministradores 485
capacidad de reacción del equipo técnico que recibe el servicio contratado. La rea-
parición de este proceso primero en ISO/IEC20000 y después en ITIL v3 (en el
libro de Diseño del Servicio) pone de manifiesto la importancia que tiene en la nor-
mativa y marcos de buenas prácticas. En el presente apartado se presenta una visión
integral de la gestión de suministradores, que se inicia con la definición de la estra-
tegia y concluye con el término de los servicios contratados. Esta visión va más allá
de los límites establecidos en ISO/IEC 20000 para el proceso.
La gestión de suministradores es toda actividad dirigida a que los servicios contra-
tados al suministrador se presten según la forma acordada, para obtener el benefi-
cio previsto de los contratos para la organización de TI. Por tanto, la gestión de
suministradores supervisa, guía y exige a los suministradores el cumplimiento de lo
pactado en el contrato. Y, por otra parte, también debe velar porque la propia orga-
nización de TI contratante haga todo lo posible para que el servicio se preste con la
fluidez deseada.
Recalcar la diferencia terminológica entre suministrador o empresa externa a la que
se contrata algún producto o servicio y el término “proveedor de TI” en ISO/IEC
20000, que se refiere a la propia organización de TI o al departamento interno de
informática.
En la figura 7.3.2 se presenta un esquema introductorio al proceso.
rutina habitual en la prestación del servicio, de tal forma que las reuniones, infor-
mes, escalados, etc. fluyan con total normalidad sin necesitarse un esfuerzo especí-
fico para conseguirlos.
Junto a esta faceta, el rigor en la relación, manteniendo un trato formal y documen-
tado, permitirá dejar trazas y evidencias de todo lo acontecido a lo largo de la his-
toria de la relación con cada uno de los suministradores.
No hay que olvidar que la relación con el suministrador se desarrolla en un marco
contractual, en el que debe haber una cobertura legal para la prestación y la gestión
de los desacuerdos. El carácter contractual debe estar presente a lo largo de toda la
relación.
El cuarto aspecto importante es el relativo a la función de interlocutor entre la
organización de TI y los suministradores. Para tener éxito en la mediación es nece-
sario que se conozcan y se gestionen los mecanismos que se van utilizar para que
fluya la relación con los suministradores y asegurar así el cumplimiento de lo con-
tratado y la satisfacción mutua. Frecuentemente se ignora esta faceta de facilitador
interno con toda la organización de TI para alcanzar los objetivos esperados en las
contrataciones, pero se debe velar por que todo el mundo cumpla con su parte. En
ocasiones, es el propio personal de la organización contratante quien dificulta o
ralentiza la prestación del servicio. Otras veces, son las deficientes interfaces entre
las herramientas las que dificultan el flujo de intercambio de información, de peti-
ciones o de trabajos.
En la gestión de suministradores, normalmente los problemas suelen surgir en las
fronteras e interfaces. En las fronteras en cuanto a la determinación de los límites
de lo contratado, entrando en discusiones sobre si una actividad está contratada o
no. En las interfaces por la necesidad de integración de los sistemas, organizacio-
nes, culturas, procesos y formas de hacer entre la organización TI contratante y las
diversas organizaciones de prestación de servicios de los suministradores.
De forma general, aunque no plenamente coincidente con las normas y estándares
de referencia, como se verá más adelante, el alcance de este dominio (gestión de
suministradores) debería comprender desde la definición de la estrategia de sour-
cing (realizada en el ámbito de la definición de la estrategia general de TI), pasando
por la selección y contratación, para seguir con la prestación o recepción de los ser-
vicios, hasta concluir con la etapa de finalización de los mismos.
De esta forma, y tomando como referencia el proceso similar definido en ITIL (en
su versión 2 dentro del libro Business Perspective, y en su versión 3 dentro del libro
Diseño del Servicio), en este capítulo se desarrolla un enfoque propio en el que,
cubriéndose también las actividades de establecimiento de la estrategia de sourcing
y de finalización o terminación del suministro, las actividades se agrupan en dos
490 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Fases del ciclo de vida del outsourcing desde la perspectiva de organizaciones contratantes
Figura 7.3.5. Esquema del modelo de gestión de outsourcing del modelo eSCM-CL
492 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Suministrador 1
Proveedor de TI
Negocio Suministrador 2
(área TI)
Suministrador 4
Suministrador 3
subcontratado
PDCA
Mejora
SGSTI
Los componentes principales que se emplean en el proceso son, por orden alfabé-
tico, los siguientes:
• Contrato. Documento legal que formaliza la compra o la contratación.
• Contrato de soporte (UC, Underpinning Contract). Término muy utilizado
en el ámbito de ITIL. Se refiere al contrato específico de servicios con un
suministrador externo en el que se fijan los niveles de servicio que el sumi-
nistrador debe cumplir. Los niveles de servicio pactados en los contratos de
soporte deben ser igual o más exigentes que los acordados con las áreas clien-
tes en los SLA.
• Declaración de requisitos (SOR, Statement Of Requirements). La declaración
de requerimientos es el término utilizado en ITIL v3 para referirse a la RFP.
• Estrategia de sourcing. La estrategia de sourcing determina qué actividades
o funciones se van a realizar internamente (retenidas) y cuales se van a con-
494 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
contractual y pasa a formar parte del contrato final (está relacionado con otra
forma de emitir solicitudes de ofertas denominadas: ITT, Invitation To Tender).
Si se ha realizado un RFI previo, se toman sus resultados como punto de par-
tida. Toda compra importante debería llevar una RFP que especifique todos
los detalles y acuerdos de la compra. La RFP se remite a los suministradores
candidatos y suele formar parte del contrato final.
• Políticas de contratación. Directrices y normativas internas que dictan las
pautas establecidas en la estrategia de sourcing que se deben seguir en todas
las adquisiciones o contrataciones.
• Proveedor de TI. Organización, departamento, área de TI que presta los
servicios de TI. Es el contratante de los servicios de terceros que necesite
para ser capaz de proveer los servicios TI prestados al negocio.
• RFI (Request For Information). Petición de información, de ideas y de enfo-
ques que solicita la organización de TI a ciertos suministradores clave.
Mediante la RFI se plantea al mercado una situación y se le solicitan ideas y
posibles soluciones. Con los resultados de este sondeo se enfoca de forma
más precisa la contratación a realizar.
• SCD (Supplier and Contract Data base). Es la base de datos de suministrado-
res y contratos, que centraliza y registra toda la información sobre los con-
tratos realizados. Este término se ha acuñado en ITIL v3, aunque el con-
cepto ya era muy conocido en el mercado.
• Servicio. En lo relativo al término de servicio, surge un nuevo conflicto ter-
minológico, pues también se denomina servicio a la prestación contratada a
un suministrador. Por tanto, ya existen tres tipos de servicios:
– Los servicios que comercializa el negocio al mercado, que en algunas oca-
siones son servicios de TI puros.
– Los servicios que presta el proveedor o área de TI internamente a las áreas
de cliente de la empresa.
– Los servicios que presta un suministrador al proveedor o área de TI.
del contrato final). El término ITT se utiliza en ITIL v3, mientras que en la
versión 2 se utiliza más RFP.
La RFP o la ITT son formas parecidas de solicitar ofertas al mercado para efec-
tuar una compra y, por tanto, deben tener asignado un presupuesto interno.
• Sourcing. El término sourcing comprende todas las actividades relativas al
aprovisionamiento de productos y a la provisión y el soporte de los servicios,
necesarias para poder prestar el servicio de TI. En los dos extremos del sour-
cing están: el outsourcing (externalización completa de una unidad de TI) y el
insourcing (realización de la actividad internamente por el personal de planti-
lla y subcontratado). Entre medias está el outsourcing selectivo (externaliza-
ción de funciones al mejor suministrador en cada una de ellas) y una amal-
gama de posibles subcontrataciones. La proporción de cada uno depende de
las políticas y estrategias de sourcing de la organización. Por tanto, el con-
cepto de sourcing va más allá de su traducción literal por “suministro”, pues
también incluye las actividades internas retenidas en la organización de TI.
• Subcontratistas. Empresas a las que un suministrador contrata a su vez algún
servicio necesario para prestar el servicio contratado con el proveedor TI.
• Suministrador de TI. Empresa externa al proveedor de TI que provee
algún producto, o presta algún de servicio a éste, bajo un contrato de com-
pra o de prestación. El abanico de suministradores es muy amplio y com-
prende a fabricantes de equipamiento hardware, fabricantes de productos
software, proveedores de telecomunicaciones, servicios mantenimiento hard-
ware y software, servicios de soporte, servicios de body shopping, consultores,
integradores, servicios de valor añadido, outsourcers de funciones específicas
de TI, outsourcers integrales, etc.
Conviene destacar que, para evitar la confusión terminológica, en las Nor-
mas ISO/IEC20000 se ha adoptado el término de suministrador para desig-
nar a toda organización a la que se le contrata algún tipo de prestación, que-
dando el término proveedor para aquellas organizaciones que quiere cumplir
con lo especificado por la norma (a efectos de certificación). Se distingue,
así, entre suministrador de TI y proveedor de TI (área o departamento de
TI). Esta consideración es muy importante en el ámbito de estas normas, y
hay que afinar el lenguaje, utilizando siempre suministrador para estas pres-
taciones contratadas externamente.
• Tipos de sourcing. Los tipos de sourcing son tan variados como tipos de ser-
vicios, o parte de los mismos, que se pueden contratar. Los tipos más fre-
cuentes en el mercado son: internalización o realización interna, prestación
de servicios o body shopping, outsourcing selectivo, y outsourcing completo.
7. Procesos de relaciones
7.3. Gestión de suministradores 497
Fuente: e.p. y Libro ITIL Diseño del Servicio publicado por OGC.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe tener documentados los procesos de gestión de suminis-
tradores y debe designar un gestor responsable del contacto con cada suministrador.
500 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Los SLAs con los suministradores se deben alinear con los SLAs con el negocio.
Las interfaces entre los procesos utilizados por cada parte deben ser acordadas y docu-
mentadas.
Todos los roles y relaciones entre suministradores principales y subcontratados deben
estar claramente documentados. Los suministradores principales deben ser capaces
de demostrar que tienen procesos para garantizar que los subcontratistas cumplen
con los requisitos contractuales.
Se debe disponer de un proceso para la revisión detallada del contrato o del
acuerdo formal, con periodicidad mínima anual, que garantice que las necesidades
y obligaciones contractuales del negocio se siguen cumpliendo.
UNE-ISO/IEC 20000-2
Estrategia de sourcing
La estrategia de sourcing forma parte de la estrategia general de TI. En la estrategia
de sourcing se definen las actividades que se realizarán internamente en la organiza-
ción de TI y las actividades que se externalizarán. Por tanto, la estrategia de sourcing
define la forma en que se cubrirán las necesidades para la creación y prestación de los
servicios. Abarca tanto a las áreas de desarrollo como las de producción o explota-
ción, contemplando todo tipo de funciones de TI (planificación y control, arquitec-
tura, programación, operación, técnica, etc.). Para todas ellas, se define que activida-
des se realizarán internamente y en cuáles se recurrirá al apoyo de suministradores.
Además, la estrategia de sourcing refleja la visión final deseada en cuanto al mapa de
suministradores, definiendo si habrá una concentración de suministradores o una
atomización de los mismos, el número idóneo de suministradores deseado, etc.
La estrategia de sourcing define los tipos de servicios que puede contratar la organi-
zación de TI. Éstos son de muy diversa índole. En la figura 7.3.11 se muestran
diversos ejemplos de tipos de contrataciones que se podrían realizar.
Ejemplos de contrataciones
1
Documento: Best practices for creating an IT service sourcing strategy. Gartner 2007.
7. Procesos de relaciones
7.3. Gestión de suministradores 503
tipos, se debe definir cuáles de sus actividades se deben retener y cuáles se pueden
externalizar (véase el ejemplo de la figura 7.3.13).
Gestión Retener
involucradas
Control Retener
Tecnológicas Externalizar
+ Operativas Externalizar
Gobierno
Funciones de TI Arquitectura Desarrollo Producción
de TI
Internalizado
Gestión INTERNO INTERNO INTERNO INTERNO
Externalizado
Tecnológicas EXTERNO EXTERNO EXTERNO
Frontera típica
de externalización INTERNO Internalizado EXTERNO Externalizado
Mejora
Estrategia Diseño Construcción Transición Operación
continua
Servicios TI
• PC, LAN,
INTERNO INTERNO
ficheros
SUMINISTRADOR A
• Movilidad
INTERNO INTERNO
(WIFI+RAS)
• Comunica-
INTERNO SUMINISTRADOR G INTERNO
ciones WAN
Diversos
INTERNO Internalizado SUM. n
suministradores
Dado que los tipos de adquisiciones gestionados pueden ser muy diversos, desde
un equipamiento sencillo, pasando por un proyecto llave en mano, hasta la contra-
tación de un servicio de externalización a varios años, es necesario que los procedi-
mientos existentes se adapten a la envergadura y criticidad de cada tipo de adquisi-
ción. En las simples y repetitivas, bastará con una sencilla hoja de petición de
compra. En cambio, en los grandes proyectos será necesario recorrer todas las eta-
pas: la RFI, pasando por el caso de negocio, la aprobación de la inversión, la gene-
ración de la RFP, etc.
Incorporando la estructura de las actividades definidas en ITIL v3 a este ciclo de selec-
ción y contratación queda un esquema como el que se muestra en la figura 7.3.16.
• Necesidad de TI.
• RFI.
Actividades de selección y contratación • Caso de negocio.
• RFP (SOR).
• Hoja de compra.
• Identificación de la necesidad y preparación del caso de negocio • Asiento de la petición
de compra en el ERP.
• Evaluación y provisión de nuevos contratos y suministradores • Hoja seguimiento
de ofertas.
• Implementación de nuevos suministradores y contratos
• Contrato (UC).
Como se ha apuntado, la realización del caso de negocio o business case sólo se reco-
mienda en las grandes inversiones. Se analizarán las alternativas, los costes y los
beneficios del proyecto tanto para el negocio, como para la organización de TI.
Una vez realizado, el comité de inversiones o la dirección de TI decidirán si es idó-
neo llevarlo a cabo y la alternativa más adecuada. El caso de negocio y la gestión de
la aprobación del presupuesto asociado los suele realizar el área proponente traba-
jando para el proceso de gestión de suministradores. La estructura y el contenido
tipo de un caso de negocio deben estar estandarizados en la organización para evi-
tar reinventar continuamente la rueda y reducir el tiempo de su confección. Para la
realización de los casos de negocio se necesita información de los costes unitarios y
totales de la actividad, de los mantenimientos, de las amortizaciones, etc. Esta
información analítica de los costes conviene recogerla y mantenerla centralizada
para los diversos estudios que se realicen. En la figura 7.3.17 se muestra un ejem-
plo de estructura de un caso de negocio.
De forma previa a la realización del caso de negocio, puede ser necesario hacer una
consulta o petición de ideas (RFI) a los proveedores principales, que pudieran dar
una orientación sobre la solución más adecuada. La RFI permite realizar una pros-
pección del mercado en un ámbito en el que no se tiene experiencia y, en cierta
manera, ahorra la contratación de una consultoría externa. La RFI también la rea-
liza el área proponente de la compra y, en contra de la práctica habitual, siempre lo
debe remitir al mercado el área de compras, ambas trabajando bajo este proceso de
gestión de suministradores.
Especificación de compra
(RFP o SOR) enfocada
a una externalización
Fichas de suministradores:
3 Código y nombre del suministrador.
3 Contactos principales.
3 Contratos realizados.
3 Volumen total contratado por ejercicios.
3 Valoración del suministrador.
Fichas de contratos:
3 Código y título del contrato.
3 Servicios contratados. Descripción.
3 Niveles de servicio a cumplir.
3 Importe contratado.
3 Fechas y período del contrato.
3 Fecha límite para la comunicación de la terminación
del contrato.
3 Valoración de los resultados del contrato.
3 Éxitos y conflictos surgidos.
Relaciones:
3 Tipos de relaciones y procedimientos.
3 Interlocutores para cada una de ellas.
3 Interfaces entre herramientas.
3 Histórico de la relación.
UNE-ISO/IEC 20000-1
desplegar lo necesario para que este flujo sea efectivo: reuniones, interlocutores,
herramientas, interfaces, procedimientos, escalados, etc. Por tanto, éste es un ciclo o
subproceso que prepara los “conectores” entre la organización de TI y sus suminis-
tradores, para supervisar posteriormente su funcionamiento.
En las Normas ISO/IEC 20000 se establecen unos requisitos muy básicos para la
gestión de la prestación del servicio del suministrador:
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Fuente: Libro ITIL Diseño del Servicio publicado por OGC y e.p.
los productos o servicios recibidos, integra los servicios recibidos de los suministra-
dores con los servicios de TI ofrecidos a las áreas cliente, y supervisa de forma conti-
nua el funcionamiento de las herramientas y las interfaces para garantizar que el tra-
bajo fluye con normalidad.
Para asegurar una correcta relación con los suministradores es fundamental el esta-
blecimiento de conductos de comunicación eficientes, que permitan a ambas partes
profundizar en su conocimiento mutuo. De esta forma, la interrelación para la
prestación diaria de los suministradores se suele articular en base a tres tipos de uni-
dades de información que fluyen hacia los suministradores:
• Tickets. Traspaso de tickets de incidentes y peticiones de servicio recogidas
en el catálogo de servicios, que normalmente provienen directamente del
contacto con el usuario.
• Órdenes de trabajo. Envío de órdenes de trabajo o peticiones, que son
generadas por la organización de TI para solicitar trabajos al suministrador
(cambios, informes, actuaciones, etc.).
• Proyectos. Actividades de mayor envergadura y complejidad que suelen
contener unos objetivos, una planificación, unos compromisos, una direc-
ción específica, un presupuesto determinado, etc. Los proyectos pueden ser
de todo tipo: de desarrollo de software, de arquitectura, de diseño, de plata-
forma tecnológica, etc.
UNE-ISO/IEC 20000-1
Los cambios al contrato(s), si existen, y los SLAs deben ser el resultado de estas revi-
siones o de aquellas requeridas en cualquier otro momento. Cualquier cambio debe
estar sujeto al proceso de gestión del cambio.
UNE-ISO/IEC 20000-2
Revisión periódica de los objetivos del servicio frente a las necesidades del
negocio, objetivos y acuerdos. Se suele realizar en el ámbito del comité ejecutivo.
Se identifican los puntos conflictivos, el desempeño de los interlocutores y se rea-
liza la revisión de todos los indicadores comprometidos. Su periodicidad suele ser
trimestral, con los suministradores esenciales, y anual con el resto. También se
deben replantear si los objetivos contratados están alineados con las necesidades
de TI y del negocio.
En este ámbito se llevan a cabo dos tipos de revisiones formales: la revisión del
desempeño del suministrador (en base a revisiones del servicio) y la revisión del con-
trato (del rendimiento, de los escalados, los costes, las variaciones en la demanda, las
mejoras al servicio, la opinión de los clientes, etc.).
Planificación para posible cierre, renovación o extensión. Toda la actividad dia-
ria debe estar concebida para que se retenga el conocimiento, de esta forma, la
dependencia de un suministrador determinado es menor. Además de esto, con la
anticipación necesaria (normalmente 3 meses antes) se debe decidir si se continuará
con el servicio, se procederá a su renovación y en qué ámbitos se modificará su
alcance. En función de la decisión tomada, se iniciarán las acciones de recopilación
de información, auditorías necesarias, denuncia del contrato, etc.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Fuente: Libro ITIL Diseño del Servicio publicado por OGC y e.p.
Llegada la fecha en la que el contrato finaliza, se deben realizar dos acciones princi-
pales (según ITIL v3).
526 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Tanto el proveedor del servicio como el que no puedan ser resueltos mediante
suministrador deberían funcionar con- el procedimiento ordinario.
forme a un proceso para gestionar los El proceso debería asegurar que los
conflictos, el cual se debería definir o conflictos son registrados, investigados,
referenciar dentro del contrato. que se toman las acciones necesarias
Debería existir un procedimiento o itine- sobre ellos y que se cierran formal-
rario para poder escalar los conflictos mente.
7. Procesos de relaciones
7.3. Gestión de suministradores 527
UNE-ISO/IEC 20000-2
Debería quedar claro si el proveedor del ción del proveedor del servicio si así lo
servicio trata con todos los suministradores requiere.
de forma directa o mediante un suministra-
El proveedor del servicio debería obtener
dor principal que toma la responsabilidad
evidencias de que los suministradores
de los suministradores subcontratados.
principales gestionan formalmente a los
El suministrador principal debería regis- suministradores subcontratados; guián-
trar los nombres, responsabilidades y dose, cuando sea apropiado, por los
relaciones entre todos los suministrado- requisitos incluidos en la Norma ISO/IEC
res subcontratados y ponerla a disposi- 20000-1.
Los roles ajenos que son relevantes en este proceso son los siguientes.
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados. Aporta los niveles de servicio a mantener en
los contratos.
• Las áreas de TI proponentes de las compras, que son las que solicitan la rea-
lización de las compras.
• El responsable de informes, aportando los informes que se deben entregar al
cliente.
7. Procesos de relaciones
7.3. Gestión de suministradores 531
• El propietario del modelo SGSTI, que actúa como propietario del proceso
(process owner), define las actividades del proceso y se encarga de la mejora
continua del mismo. Todo ello, de una forma integrada con el modelo de
gestión del proveedor de TI incorporado en el SGSTI.
Estrategia Selección y
Prestación
de sourcing contratación
Responsable de la
gestión del servicio
Chief Sourcing Responsable Gestor de las
SGSTI Officer de compras relaciones con
el suministrador
Propietario del
modelo (SGSTI)
Administrador y
soporte del proceso
Gestor de
suministradores
Gestores del Áreas de TI proponentes
nivel de servicio de las compras
Resumen
La maduración del sector lleva paulatinamente hacia la concentración de “la fábrica
de los servicios de TI” en empresas especializadas que prestan servicios al resto de
532 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
organizaciones internas de TI. Lo que permite que las empresas se centren en las
actividades que aporten un valor diferencial a su negocio, recurriendo a la exter-
nalización de las funciones no esenciales que el mercado comercializa empaque-
tadas en forma de producto o servicio (ERP, mantenimiento correctivo de soft-
ware, comunicaciones, hosting, monitorización, operación, atención telefónica al
usuario, etc.).
Como consecuencia, cada vez se externalizan más actividades de la organización de
TI. Por ello, la gestión de los suministradores, casi inexistente hasta, ahora se ha
convertido en un proceso clave para el éxito en los servicios de TI.
La gestión de suministradores también debe tener en cuenta que detrás de un sumi-
nistrador hay personas, que además de ser eficientes en el cumplimiento de sus
compromisos, tienen sentimientos, vida personal, familia, frustraciones, etc.
De forma histórica las grandes organizaciones han desarrollado el ciclo de selección
y contratación de suministradores, implementando buenas prácticas y políticas en
la selección y en la contratación. En cambio, el ciclo de gestión de la prestación del
suministrador es apenas un recién nacido, pero esencial en un escenario con cada
vez más funciones de TI externalizadas.
Los aspectos más destacados de este proceso son los siguientes:
• El proceso de gestión de suministradores abarca todo tipo de servicios, desde
la compra de productos, pasando por la contratación de servicios, hasta los
diversos tipos de externalizaciones.
• La estrategia de sourcing define las actividades que se realizarán interna-
mente y las que se contratarán a los suministradores. Una vez definida, la
implementación de esta estrategia pasa por el establecimiento de acuerdos
marcos de tarifas con los suministradores principales, que promocionen más
agilidad para las contrataciones del día a día y faciliten la tendencia hacia una
consolidación de suministradores.
• El proceso, bajo aproximación pura ISO/IEC 20000, partiría de una estrate-
gia de sourcing ya definida para dividirse en dos grandes ciclos, junto con una
actividad de finalización del contrato:
– El ciclo de selección y contratación de productos y servicios.
– El ciclo de gestión de la prestación de los suministradores.
Beneficios
La gestión de suministradores permite garantizar que las necesidades de la organi-
zación de TI se aprovisionan de forma alineada con la estrategia general, y que los
productos y servicios contratados cumplen con los acuerdos firmados. Entre los
beneficios obtenidos destacan:
• Definición de una estrategia de sourcing, que identifica las actividades críticas
a retener y las funciones que se externalizarán.
• Se asegura la ejecución de la estrategia de sourcing en lo relativo a la contra-
tación externa.
534 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 2:
• Según su opinión, ¿qué debe contemplar la estrategia de sourcing de TI?
• ¿Cómo se realizan la selección y contratación de suministradores en su
organización?
• Según su experiencia, ¿qué aspectos destacaría en la gestión de los sumi-
nistradores?
2 Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
8 Procesos de
resolución
Capítulo 8
8.1. Antecedentes
8.1. Antecedentes
La gestión del incidente se centra en restaurar el servicio cuanto antes, sin admitir
dilaciones por investigaciones técnicas. Su objetivo es que todo servicio caído o
degradado retorne cuanto antes a la normalidad.
Mantener únicamente esta actividad frenética de “apaga fuegos” no sería produc-
tivo, pues los defectos no reparados producirían más y más incidentes. Así, de
forma independiente, se debe realizar una labor más sosegada y concienzuda
de análisis de los fallos, para buscar soluciones definitivas. Aquí aparece la necesi-
dad de un nuevo proceso como la gestión del problema.
Las Normas ISO/IEC 20000 dedican unos párrafos introductorios a los procesos
de resolución, estableciendo una relación permanente entre ambos procesos, defi-
niendo el concepto de prioridad e introduciendo las soluciones provisionales:
UNE-ISO/IEC 20000-1
Antecedentes
La gestión del incidente y la gestión del problema son procesos separados, aunque
ambos están fuertemente relacionados.
540 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-2
La gestión del incidente y del problema mientras la gestión del problema tiene
son procesos distintos, aunque están como misión la identificación y la elimi-
estrechamente relacionados. El proceso nación de las causas de los incidentes.
de gestión del incidente se encarga de la
restauración del servicio a los usuarios,
La relación entre ambos procesos es constante, pues la gestión del incidente genera
información que posteriormente analizará la gestión del problema en busca de
defectos en los servicios. Así, en su actividad diaria de restaurar el servicio, la ges-
tión de incidente se encuentra frecuentemente con defectos en los servicios. Como
su función no es dedicarse a erradicarlos, los comunicará a la gestión del problema
para a su análisis y resolución. Por otra parte, la gestión del problema vuelca su
conocimiento y las soluciones encontradas en una base de datos, para que la ges-
tión del incidente los pueda aplicar en futuros incidentes similares.
UNE-ISO/IEC 20000-2
e) el tiempo transcurrido para pro- Nota: La prioridad se utiliza durante toda la ges-
porcionar un método de resolu- tión del servicio pero es fundamental para la ges-
tión del incidente y del problema.
ción.
Esta misma clasificación de impacto y urgencia se utiliza para ordenar por priori-
dad los cambios (véase también el apartado 9.2).
En cualquier caso, los criterios para definir el impacto y la urgencia deberían esta-
blecerse en coordinación con los responsables del negocio y formalizarse en el SLA.
En la figura 8.1.2 se presentan los tipos de prioridad más habituales y un rango
orientativo del tiempo de atención asociado.
Tiempo
Prioridad Descripción
atención
Prioridad de un incidente
PRIORIDAD/ IMPACTO
Tiempo de resolución
Alto Medio Bajo
Planificar /
Baja Medio / Bajo /
Cuando haya
o Bronce <2 h <6 h
hueco
si > SLA
Incidente grave Crisis
UNE-ISO/IEC 20000-2
Siempre que sea necesario, la gestión error deje de existir (por ejemplo, por-
del problema debería desarrollar y que el servicio ya no se utilice).
mantener soluciones provisionales para La gestión del problema debería tener
permitir a la gestión del incidente ayu- acceso a la información sobre las áreas
dar a los usuarios o al personal a res- de negocio afectadas por los problemas.
taurar el servicio.
Se debería almacenar y mantener en la
Un error conocido sólo se debería base de datos de conocimiento, la infor-
cerrar cuando se haya aplicado satis- mación sobre las soluciones provisiona-
factoriamente un cambio correctivo o el les, su aplicabilidad y su efectividad.
La gestión del incidente es el proceso que más volumen de trabajo genera en TI.
Además involucra a un número de actores bastante amplio, desde los teleoperado-
res, pasando por todas las áreas técnicas, hasta llegar a los desarrolladores de las
aplicaciones.
Hay que tener en cuenta que en una organización de TI se atienden entre 2 y 3
contactos por mes de cada usuario, relativos a incidentes y peticiones de servicio
(una empresa de 5.000 personas generará unas 15.000 llamadas al mes que TI
548 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
deberá atender). Además, hay que considerar que la tendencia es a que este volu-
men de contactos se vaya incrementando, debido al aumento de la diversidad de
dispositivos móviles y a la progresiva penetración de las TI en la actividad de la
empresa. Por ello, es importante disponer de una organización perfectamente pre-
parada y entrenada para su atención y resolución.
Una buena gestión de los incidentes y las peticiones en la organización, reducirá
enormemente las tensiones internas y permitirá a la organización salir de la crisis
continua como único medio de gestión y de trabajo. Además, liberará a la direc-
ción de TI de llamadas y quejas inoportunas de los otros directores, permitiendo
que en la organización de TI cada uno realice su propio trabajo.
Por tanto, es un proceso que tiene dos flujos de trabajo (workflow) diferenciados y
amplios, que se deben afinar y optimizar. El primero de ellos es el ciclo de vida del
incidente y el otro el ciclo de vida de la petición de servicio. Ambos comienzan en
el mismo punto, el centro de servicio al usuario (SD, Service Desk) que atiende los
contactos del usuario, bien sea a través de llamadas telefónicas o, más reciente-
mente, a través de una aplicación web. A partir de este momento, el flujo de ambos
procesos se separan para recorrer diversas partes de la organización de TI: el inci-
dente se trata por los niveles técnicos especializados y las peticiones por la adminis-
tración de los servicios.
Ya que estos dos flujos recorren gran parte de la organización, hay que transmitir a
todos los implicados los objetivos que se deben cumplir, para que TI actúe como
un auténtico equipo sincronizado. Los tres pilares en los que se sustenta este pro-
ceso se resumen en la figura 8.2.3.
Incidentes
Personal
técnico
Incidentes
Problemas
identificados Conocimiento
técnico
Peticiones de
Incidentes cambio (RFC) Errores
conocidos CMDB
Petición de cambio (RFC, Request For Change). Medio para proponer un cam-
bio en cualquier componente de la infraestructura de TI o en cualquier aspecto de
un servicio de TI. La gestión del incidente genera las peticiones de cambio que
necesite para la resolución rápida de los incidentes abiertos.
Fuente: Libros ITIL Soporte de Servicio y Operación del Servicio publicados por OGC.
En ISO/IEC 20000-1 están condensados los requisitos para la gestión del inci-
dente. En ella se especifica lo siguiente:
556 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Las tareas que habitualmente se realizan en la detección y registro son las siguientes:
• Comprobar que la comunicación del usuario o el ticket abierto automática-
mente por la monitorización corresponde de verdad a un incidente.
• Registrar los datos preliminares en la ficha o pantalla de registro de incidentes
(bien por el teleoperador del service desk o directamente por el usuario vía web).
• Si se trata de un incidente, verificar que no se ha registrado previamente, en
cuyo caso se asocia con el incidente existente. Si no existe, se graba como
incidente nuevo.
• Si se trata de una petición o solicitud de servicio o similar, se graba el regis-
tro con los datos requeridos para tramitarla.
Ficha de un incidente
Fuente: Libros ITIL Soporte de Servicio y Operación del Servicio publicados por OGC, y Telefónica.
Clasificación de un incidente
Categoría Subcategoría
Hardware Instalación/Configuración.
Rotura.
Factor humano.
Funcionalidad.
Software Inconsistencia/Corrupción.
Rendimiento/Bloqueos.
Factor humano.
Causa ajena a TI Servicios internos.
Defecto de fabricación hardware.
Bug software.
Red WAN.
Desconocido
Asignación y escalado
Cuando la primera línea no puede resolver el incidente, de forma inmediata lo
asigna al grupo técnico que corresponda en la segunda línea de soporte (escalado
horizontal). Si además, el incidente cumple unos requisitos definidos, se informa
inmediatamente a los responsables superiores (escalado vertical).
El escalado tiene el objetivo de resolver el incidente lo antes posible, para no
incumplir los niveles de servicio acordados. Es una actividad que puede ser itera-
tiva y que puede pasar por diferentes grupos de soporte e incluso a suministradores
hasta que se restaure el servicio.
Hay dos tipos de escalado:
• Escalado funcional (que equivale a enviar a otra línea de soporte). Es la
remisión de un incidente a otro grupo de soporte técnico o funcional para
que se continúe trabajando en él cuando es necesario aumentar la especiali-
zación necesaria. También se le conoce como escalado horizontal. Se realiza
generalmente desde los grupos de soporte de la primera línea a la segunda, o
de la segunda a la tercera. Es importante una buena tipificación del incidente
para conseguir que éste llegue al grupo de soporte adecuado. Los motivos
para promover un escalado pueden ser:
– El grupo que investiga la resolución del incidente no cuenta con los
conocimientos o experiencia requeridos para resolver el incidente. En
este caso, la petición partirá probablemente del equipo encargado de la
resolución.
– El tiempo disponible para la resolución del incidente pone en riesgo el
cumplimiento de los niveles de servicio acordados (SLA). En este caso,
el escalado puede ser también jerárquico.
UNE-ISO/IEC 20000-2
Siempre que sea posible, se debería cliente. Cuando la causa del problema
proporcionar al cliente los medios nece- siga sin determinarse pero se haya esta-
sarios para continuar con sus activida- blecido una solución provisional, se
des empresariales, aunque sea con un deberían registrar los detalles para utili-
servicio degradado (por ejemplo inhabi- zarlos durante la diagnosis continua del
litando una función defectuosa). El problema y cuando se produzcan inci-
motivo es minimizar la repercusión dentes similares.
sobre las actividades empresariales del
Desgraciadamente, en la vida diaria las situaciones no son tan sencillas. Por ejemplo,
un fallo puede hacer que se haya corrompido una base de datos o que unos procesos
batch se hayan quedado a mitad y haya que reanudarlos y terminarlos, posiblemente
borrando datos incompletos y repitiéndolos desde el principio. También puede suce-
der que sea necesario recurrir a las copias de seguridad y avisar a clientes de que se han
perdido las últimas altas o facturas.
Estas situaciones complican a veces extraordinariamente la solución de un incidente
y generan discusiones sobre si los SLA se están cumpliendo o no. Por ejemplo, el
servicio se puede recuperar, pero reparar una base de datos corrupta puede llevar
días o semanas ¿Se puede decir que el servicio se ha recuperado hasta que la base
de datos esté limpia? Si ha fallado una cadena batch (programada en JCL), se puede
corregir y liberar una nueva versión, pero ¿termina el incidente con esto, o no ter-
mina hasta que el trabajo se ha lanzado otra vez y ha finalizado correctamente? El
servicio no se puede restablecer al cien por cien hasta que el trabajo batch haya fina-
lizado, pero es posible que no se pueda lanzar hasta la noche siguiente, aunque el
error en la programación en el JCL se haya corregido en minutos.
El equipo que solucionó el incidente, deberá actualizar el registro del incidente
cumplimentando los detalles propios de la resolución e información complementa-
ria, como por ejemplo:
• La fecha y hora de la resolución del incidente.
• El equipo que proporcionó la solución.
• El detalle de la solución.
• El detalle de los procedimientos y elementos utilizados en la resolución.
• Los incidentes relacionados, si los hubiese.
UNE-ISO/IEC 20000-2
Reabrir el incidente
En caso de disconformidad del usuario con la resolución del incidente no se podrá
cerrar el incidente y volverá a la actividad de asignación, registrando en la informa-
ción del incidente que se ha reabierto.
566 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
En el caso habitual del cierre por defecto del incidente es muy importante tener
posibilidad de su reapertura para disponer de información estadística sobre la cali-
dad en la resolución. Se debe evitar la práctica de generar un nuevo ticket de inci-
dente, en lugar de reabrir el anterior.
En la reapertura, se registra en la base de datos de incidentes la causa de la reaper-
tura y la no conformidad del usuario.
Estados de un incidente
El estado de un incidente es un indicador del progreso realizado en su resolución.
Marca las diversas etapas por las que puede pasar el ticket de un incidente hasta su
resolución. El estado permite conocer al instante en que fase del flujo de resolución
se encuentra. Además, al marcar la evolución en etapas, posibilita extraer ciertas
métricas con el fin de evaluar el desempeño del proceso. En la figura 8.2.9 se mues-
tra un ejemplo de los posibles estados de un incidente.
Notificado.
Detectado.
Diagnosticado.
Reparado el fallo.
Recuperado el CI.
Restaurado servicio.
Cerrado.
Un cierto detalle en los estados del incidente permite identificar en que etapas hay
que actuar para mejorar el proceso.
UNE-ISO/IEC 20000-2
Nota 1: El proceso de gestión del incidente puede afecten, o que pudieran potencial-
ser proporcionado por un servicio de mente, afectar al servicio;
atención al cliente, que actúe como punto
b) un proceso centrado en la restaura-
de contacto diario con los usuarios.
ción del servicio a los clientes y no en
Nota 2: La gestión de incidentes debería ser: la determinación de la causa de los
incidentes.
a) un proceso tanto proactivo como reac-
tivo, que responda a los incidentes que
La función del service desk dentro del proceso de gestión del incidente, lleva a cabo
una labor importantísima. Aparte de centralizar todas las gestiones de seguimiento
del ciclo de vida del incidente, gestiona todas las comunicaciones de TI con el usua-
rio, en ambos sentidos, tanto para atender las llamadas como para emitir comuni-
cados o contactar con el usuario.
Lo recomendable es apoyarse en la herramienta de gestión del incidente para la
comunicación, que posibilita el acceso de los usuarios para consultar el estado de
sus incidentes y peticiones. Otro medio muy habitual es el correo electrónico y oca-
sionalmente debería ser el teléfono.
UNE-ISO/IEC 20000-1
Se debe mantener informado al cliente del progreso del incidente sobre el que haya
informado o de su solicitud de servicio, y se le debe alertar por adelantado sobre si sus
niveles de servicio no se pueden satisfacer, acordando con él las acciones a tomar.
570 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-2
Se debe poner foco en que el service desk, como primera línea de soporte, resuelva
el mayor número de incidentes y peticiones posibles; de esta forma, se reducirá
la carga de trabajo de todo el resto de la organización de TI. Para ello, es necesa-
rio contar con perfiles más cualificados que los tradicionales teleoperadores y
poner énfasis en una buena documentación que contenga los procedimientos de
resolución.
Dado el alto volumen de incidentes que se gestionan, es recomendable disponer
de una herramienta que, mediante reglas, realice el escalado funcional o jerárquico de
los incidentes de forma automática y envíe notificaciones a los gestores del proceso,
que les permitan reaccionar antes de rebasar los plazos del nivel de servicio pactado.
Esto libera a los supervisores del service desk de la ardua tarea de descubrir, en las
colas de trabajo, qué incidentes están a punto de superar su SLA. El tiempo de
resolución y las métricas clave del proceso se mejoran sustancialmente en cuanto
se implanta esta automatización.
Los resultados de las encuestas de satisfacción también mejoran cuando, mediante
otra automatización, se informa a cada usuario del estado de su incidente y de sus
ajustes, ofreciendo transparencia en la gestión.
Se recomienda que el service desk realice también el tratamiento de las quejas o recla-
maciones de los usuarios, como instrumento esencial para la mejora del servicio y
la atención prestada. La recepción de quejas aporta información importante de
mejora y sirve para restaurar la confianza del usuario en el servicio. Las quejas de los
usuarios se deben registrar y valorar. También debe asegurarse de que se tomen
las acciones correctoras adecuadas. Toda queja debe tener una gestión asociada:
registro, seguimiento, informe al usuario y cierre.
En las Normas ISO/IEC 20000 en el único lugar en el que explícitamente se tra-
tan las reclamaciones y quejas es en el proceso de gestión de las relaciones con el
negocio (véase el capítulo 7). En ese proceso no se hace distinción explícita entre
8. Procesos de resolución
8.2. Gestión del incidente 571
UNE-ISO/IEC 20000-1
Todo el personal implicado en la gestión del incidente debe tener acceso a informa-
ción relevante como, por ejemplo errores conocidos, resoluciones de problemas y la
base de datos de gestión de la configuración.
UNE-ISO/IEC 20000-2
Incidentes graves
Hay organizaciones de TI que se gestionan en base a crisis, que acaban marcando
el ritmo de trabajo del día a día. No hay nada peor que una crisis para desbaratar la
productividad. Pero las crisis se producirán, por lo que se debe predefinir el com-
portamiento de la organización ante estos incidentes graves. Estas normas tratan el
tema de forma expresa.
576 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Se debería definir claramente qué cons- Esto debería incluir una responsabilidad
tituye un incidente grave y quién está del escalado y una comunicación efica-
capacitado para llevar a cabo cambios ces entre todas las áreas implicadas en
en el funcionamiento habitual del pro- la resolución y hacia los clientes que se
ceso de incidentes/problemas. vean afectados por dicho incidente
grave.
Todos los incidentes graves deberían
tener en todo momento un gestor res- Nota: Este nivel de autoridad puede ser temporal
ponsable claramente definido. y aplicarse sólo mientras dure el incidente
grave.
La designación como responsable de un
incidente grave debería proporcionar los El proceso para un incidente grave
niveles de autoridad individual adecua- debería incluir una revisión que propor-
dos para la función de coordinar y con- cionará información al plan de mejora
trolar todos los aspectos de la resolución. del servicio.
Los incidentes graves, así como, todos los incidentes con un impacto alto, se deben
notificar en tablón de anuncios web de TI, y además, en la pantalla principal de la
herramienta de incidentes.
El objetivo que se pretende conseguir ante un incidente grave es su resolución en
un tiempo récord, minimizando el alto impacto que ocasiona. También es necesa-
rio mantener un flujo de comunicación constante entre las áreas técnicas resoluto-
rias y el comité de crisis, sin descuidar mantener puntualmente informadas a las
áreas cliente afectadas.
Normalmente, este tipo de incidentes son de obligada y cuidada documentación,
de la forma más extensa y eficaz posible. Requieren un informe especial, aparte del
seguimiento extraordinario y específico por parte de los gestores de nivel de servi-
cio, y de los gestores de los procesos implicados.
usuario, como utilizador de los servicios, y el rol del cliente o área cliente, como
representante del negocio ante TI.
Como es lógico, los servicios que se pueden solicitar deben estar identificados el
catálogo de servicios de TI. Algunos ejemplos de peticiones de servicio son las
siguientes:
• Solicitud de alta en un servicio del tipo aplicación o solicitud de acceso a un
servicio existente.
• Petición de equipamiento. Solicitud de nuevos componentes (hardware o
software) relacionados con el puesto de trabajo.
• Petición de actuaciones en el puesto de trabajo. Configuración del acceso
remoto UMTS, instalación de actualizaciones de los controladores de dispo-
sitivo, etc.
• Petición de ejecución de servicios planificados, como por ejemplo, la ejecu-
ción de cadenas batch.
• Consultas funcionales o técnicas, preguntas o dudas del usuario sobre un
tema del ámbito de servicios de TI. Las preguntas pueden ser de índole téc-
nico o funcional. Para la resolución de consultas funcionales suele haber un
equipo funcional específico, bien vinculado al área de desarrollo, al área de
relaciones con las unidades de negocio o bien al área de negocio (en este caso
fuera de TI). En todos los casos, TI debe registrar y tramitar este tipo de
consultas.
• Reclamaciones o quejas. El usuario manifiesta su disconformidad con un
servicio prestado.
Las entradas de las peticiones, al igual que los incidentes, se realizan a través del
service desk, punto único de contacto para el usuario.
Establecido que TI sólo aceptará del usuario peticiones de servicio ya predefinidas
en el catálogo, la primera acción que se realizará es comprobar si la petición está
entre los servicios que ofrece TI y que el usuario tiene permiso para realizarla.
Como ya hemos comentado, las soluciones de autorregistro y autorresolución por
parte del usuario son esenciales para reducir la carga del soporte en TI. Automati-
zar al máximo la provisión, junto a una gestión eficiente y previsora de la capaci-
dad (número de licencias) y del stock (componentes) son elementos claves para
reducir los tiempos de entrega y aliviar la carga de trabajo rutinaria en TI. Permitir
al usuario conocer vía web la evolución de su petición, facilita la comunicación y
mejora la imagen de TI.
8. Procesos de resolución
8.2. Gestión del incidente 579
Las peticiones de servicio que llegan al service desk recorren el mismo camino que
los incidentes en las dos primeras etapas (las actividades de “detección y registro” y
“clasificación y soporte inicial”), pasando después a un itinerario propio. Destacar
que algunas peticiones requerirán un itinerario de aprobación jerárquica y del con-
trol presupuestario. En la figura 8.2.10 se muestra el ciclo de vida de una petición
de servicio, según la estructura propuesta en ITIL v3.
Figura 8.2.12. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
La medición del ciclo de vida de una petición se centra en ratios de agilidad, de efi-
ciencia y de satisfacción del usuario. Los más comunes son el volumen de peticiones
gestionadas, el volumen de peticiones según su estado, desglose de las peticiones por
tipo (de servicio, consulta, etc.), el tamaño de lista de peticiones de servicio pendien-
tes, el plazo medio de provisión por tipo de petición, las peticiones de servicio ter-
minadas en plazo, el número de quejas y reclamaciones, el coste medio de provisión,
la satisfacción del usuario con la gestión de peticiones de servicio, etc.
En la figura 8.2.13 se muestra el resumen de los indicadores más relevantes para
este proceso seleccionados en ITIL v3 (en el libro Operación del Servicio).
Fuente: Libro ITIL Operación del Servicio publicado por OGC y e.p.
• Gestor del service desk. Es el responsable del funcionamiento del personal que
forma el centro de servicio al usuario, incluidas las herramientas. Es otro de
los roles importantes del proceso. Sus principales responsabilidades son las
siguientes:
– Supervisar la operativa diaria del service desk.
– Vigilar el estado de los tickets o contactos abiertos.
– Preparar los planes de formación para el personal asignado.
– Analizar la carga de trabajo de su personal, su nivel de conocimientos y
los costes laborales asociados.
– Avisar y realizar el seguimiento de la pérdida y degradación de servicios.
– Supervisar el progreso de los contactos, y en su caso tomar decisiones ante
dificultades en su resolución.
– Informar de las desviaciones e incumplimiento de los acuerdos de nivel de
servicio (SLA).
– Realizar los informes necesarios, como por ejemplo, los informes puntua-
les de actividad a petición, los informes del progreso del contacto y los
informes detallados de la actuación del service desk.
Las que no puede resolver las escala a la siguiente línea de soporte (escalado
funcional). Resuelve o escala los incidentes abiertos por las herramientas de
monitorización.
• Especialista de soporte (líneas 2 y 3). Es el rol responsable de diagnosticar la
incidencia, resolverla, comprobarla, asignarla a otro grupo y documentarla.
Participa en la resolución “in situ” de incidentes que no pueden resolverse
desde una ubicación remota y en el tratamiento personalizado de las inciden-
cias de los usuarios de dirección. Está formado por grupos de especialistas
técnicos en la gestión de la tecnología, en la administración de las aplicacio-
nes y sus datos, o en el desarrollo de software. Incluye a los grupos internos y
al soporte de fabricantes y terceros.
• Administración y soporte al proceso del incidente. Apoya al gestor del inci-
dente en sus responsabilidades. Vela por la implicación de los equipos ante la
llegada de una incidencia crítica, asegurando que se cumplen los SLA. Coor-
dina los escalados entre grupos en caso de necesidad. Supervisa a los miem-
bros de las diferentes líneas de soporte. Participa en la resolución de conflic-
tos internos.
Los roles ajenos que son relevantes en este proceso son los siguientes:
• El responsable de gestión de la configuración, pues el acceso a la CMDB es
imprescindible para toda la actividad de la gestión del incidente.
• El responsable de problemas facilita soluciones y errores conocidos para la
resolución de nuevos incidentes.
• El responsable de la gestión del servicio vela por que todos los servicios cum-
plan los niveles pactados.
• El responsable de gestión de la entrega. Su proceso debe proporcionar for-
mación al service desk y a las otras líneas de soporte sobre los nuevos servicios
o evolución de los existentes.
• El responsable de la gestión del cambio debe proporcionar información de
todos los cambios en los componentes (CI).
• El propietario del modelo de gestión de TI (SGSTI) actúa como propietario
del proceso (process owner), define las actividades del proceso y se encarga de
la mejora continua del mismo. Todo ello, de una forma integrada con el
modelo de gestión de TI o SGSTI.
Los roles de mayor relevancia que participan en el proceso de gestión del cambio
se representan en la figura 8.2.14.
586 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Responsable de la
gestión del servicio
SGSTI
Propietario del
modelo (SGSTI)
Gestor de la
configuración Especialista de Especialista de Especialista de
Gestor del service desk línea 2 línea 3
problema (proveedor TI) (fabricante)
Resumen
ISO/IEC 20000 e ITIL v2 tratan en un mismo proceso los dos ciclos de la gestión
del incidente y la gestión de la petición del usuario, porque ambos ciclos tiene una
parte común (el service desk) y con frecuencia se ve involucrado el mismo personal
técnico en su tratamiento. En cambio, en ITIL v3 se ha decidido separar estos
ciclos en dos procesos diferenciados, pues el primero debe restaurar cuanto antes el
servicio para que el negocio pueda seguir trabajando aportando productividad,
mientras que la gestión de peticiones atiende nuevas necesidades predefinidas al
usuario y otorga agilidad al negocio.
La gestión del incidente es un proceso esencial para apagar los “fuegos” que se
produzcan en TI y minimizar el impacto en el negocio de los fallos y caídas de los
servicios.
8. Procesos de resolución
8.2. Gestión del incidente 587
Beneficios
Algunos de los beneficios de alcanzar una correcta gestión el incidente son los
siguientes:
• Resolución más rápida de los incidentes y reducción del impacto en el nego-
cio de los fallos. Se produce una mejora de la disponibilidad.
• El proceso pone foco en la restauración del servicio, como eje fundamental.
• Mejor alineación de TI con las necesidades en el día a día del negocio.
• Mejor atención a los usuarios.
• Tratamiento eficiente del alto volumen de actividad requerido. Implementa-
ción de herramientas de autoatención por parte de los usuarios.
• Mayor número de incidentes resueltos en primera línea, con lo que se alivia
la carga de trabajo de las líneas de soporte más especializadas.
• Estar preparado ante las crisis.
588 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• Describa las etapas de la gestión del incidente en su organización.
• ¿Qué mejoraría para que la resolución de incidentes fuera más efi-
ciente?
• Describa el ciclo de gestión de peticiones en su organización.
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
8. Procesos de resolución
8.3. Gestión del problema 589
Los principales beneficios que aporta la gestión del problema son los siguientes:
• Reduce el número de incidentes y, por tanto, mejora la calidad de los servi-
cios.
• Estabiliza los servicios en producción regular para mantener el transcurrir
normal del negocio.
• En su trabajo, encuentra soluciones provisionales y permanentes a los defec-
tos de los servicios.
• Asegura la resolución de defectos graves que afectan al servicio.
• Identifica la causa raíz de los incidentes, evitando incidentes repetitivos.
• Propone proyectos de mejora para resolver los problemas.
• Realiza el seguimiento de los problemas identificados.
• Incrementa el conocimiento de la organización, proporcionando:
– La identificación de tendencias en los datos históricos.
– Los medios para prevenir fallos y para reducir el impacto de los fallos en
el negocio.
– Los errores conocidos, soluciones provisionales y soluciones permanentes
a la base de datos del conocimiento.
– La mejora del ratio de resoluciones de incidentes en el primer contacto o
en la primera línea de atención por el service desk.
Para el éxito del proceso es necesario desplegar tres disciplinas básicas: un buen
conocimiento técnico, una vocación por la calidad técnica y el seguimiento de los
temas hasta que los defectos queden completamente eliminados. En la figura 8.3.3
se muestran estas disciplinas esenciales del proceso.
Tarde o temprano, los defectos latentes acaban saliendo a la luz, generando inci-
dentes en los servicios. En este momento aparece la necesidad de disponer de espe-
cialistas con un buen conocimiento técnico para realizar la investigación a fondo
hasta identificar el defecto y buscar una solución.
El proceso también requiere perseverancia para el seguimiento de todos los temas
hasta su finalización, pues con frecuencia, será necesaria la participación de muchas
áreas técnicas: unas veces habrá que revisar todo un desarrollo, otras los equipos de
comunicaciones, en ocasiones habrá que reemplazar un equipamiento o actualizar
al último parche el software base. Por tanto, el proceso debe controlar múltiples acti-
vidades de resolución de los problemas que transcurrirán en paralelo, actuando
592 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Problema
• Service desk Solución provisional
• Gestión incidente Causa raíz (workaround)
• Gestión disponibilidad CONTROL DE Error
• Gestión capacidad PROBLEMAS
Solución
• Gestión nivel de servicio
Ticket de Error permanente
• Áreas técnicas
problema conocido
• Seguridad (KE)
• Desarrollo
Solicitud de
cambio (RFC)
CONTROL DE
PREVENCIÓN ERRORES
PROACTIVA DE
PROBLEMAS Problema PIR
resuelto Resolución
del error
CMDB BD de problemas
Conocimiento
BD incidentes Base datos Fichas de Errores técnico
configuración problemas conocidos
Fuente: e.p., libro ITIL Soporte de Servicio publicado por OGC y Telefónica.
Las salidas principales del proceso de gestión del problema son los problemas
resueltos y la base de datos de problemas, que contiene los errores conocidos con
sus soluciones provisionales y permanentes. La información sobre los errores cono-
cidos es una fuente importante de conocimiento, a veces se considera una base de
datos independiente de los errores conocidos, y es esencial para que el proceso
de gestión del incidente diagnostique y resuelva con rapidez. También es una salida
principal las peticiones de cambio (RFC) generadas para la construcción e imple-
mentación de las soluciones (provisionales o permanentes) encontradas.
Otras salidas de índole secundario son la notificación sobre la evolución o resolución
del problema a quién generó el ticket del problema; la base de datos de incidentes
actualizada con las causas raíces identificadas, con las soluciones provisionales o
598 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-2
La gestión del incidente y la gestión del problema tienen dos objetivos claramente
diferenciados. Mientras el primero debe recuperar el servicio lo antes posible, el
segundo se ocupa de que ese tipo de incidente no se reproduzca.
También en los métodos de ejecución actúan de forma diferente. Mientras la gestión
del incidente trabaja en una carrera contrarreloj para lograr obtener la recuperación
del servicio en tiempo récord; la gestión del problema trabaja, normalmente a medio
plazo, para erradicar la causa raíz con independencia del cierre o no del incidente.
La gestión del problema requiere un esfuerzo nada despreciable, tanto económico,
como de apoyo de la dirección, ya que el equipo de resolución de problemas, a
menudo experto en la tecnología afectada, debe liberarse del día a día. Así, se nece-
sita el soporte de la dirección para la dedicación de estos recursos y mantenerlos,
aunque en ocasiones los plazos de resolución se prolonguen.
También, el proceso debe velar por que el ratio coste (de investigación y de resolu-
ción) frente al beneficio (por la eliminación de los incidentes) sea óptimo.
A la hora de iniciar la implementación del proceso se recomienda poner primero
foco en resolver los problemas que se produzcan en los servicios vitales para el
negocio, para ir extendiendo paulatinamente su cobertura al resto de servicios
menos críticos. En etapas posteriores se incorporarán las actividades proactivas,
para identificar los problemas latentes antes de que generen incidentes.
8. Procesos de resolución
8.3. Gestión del problema 599
Por otra parte, la eficacia de este proceso sólo podrá obtenerse, tras disponer de un pro-
ceso de gestión del incidente suficientemente maduro, que registre toda la información
necesaria (clasificación, síntomas, resolución, etc.) para poder actuar a posteriori.
También es conveniente disponer de buenos sistemas de monitorización tecnoló-
gica, correlación de eventos y análisis de estadísticas.
Control de problemas
La etapa de control de problemas es la primera que se activa cuando se detecta un
problema, se inicia con la recepción del ticket del problema y concluye con la iden-
tificación de la causa raíz del mismo. El ticket entra en estado de problema y sale en
estado de error.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Se deberían clasificar los incidentes Nota: Cuando se registren incidentes por primera
para ayudar a determinar las causas de vez, su categorización se verá influenciada
por otros factores que incluyen el servicio,
los problemas. La clasificación puede
el área de negocio afectada y los síntomas
hacer referencia a los problemas y cam- que se presenten.
bios existentes.
Al igual que en los incidentes, todo problema debe estar previamente registrado. Si
este proviene de un incidente, se deben establecer referencias cruzadas entre ambos.
Las actividades comprendidas en la etapa de control de problemas son:
Identificación y registro de problemas. La identificación de los problemas proviene
de distintas fuentes de la organización de TI, ya sea de forma reactiva o proactiva:
• Del service desk y de la gestión de incidentes.
• De problemas propuestos a partir del análisis de eventos de las herramientas
de monitorización de la infraestructura desde la gestión de eventos.
• De problemas asociados a los servicios detectados en la gestión de nivel de
servicio.
8. Procesos de resolución
8.3. Gestión del problema 601
3 Número de ticket.
3 Persona que abrió el problema.
3 Fechas: apertura, actualizaciones, cierre.
3 Estado del problema.
3 Datos descriptivos del problema:
• Descripción.
• Detalles.
• CI implicados. Servicio o aplicación.
• Categoría.
• Prioridad (impacto+urgencia). Esto ayudará a
• Incidentes asociados. tener documentado
el problema más
3 Historial del problema: escalados, participantes,
detalladamente y
descripción de las investigaciones realizadas, etc.
dará pistas a posibles
3 Datos descriptivos de la resolución: investigaciones para
• Descripción de la solución provisional. solucionar otros
• Descripción de la solución definitiva. problemas.
• RFC generados, sus fechas y sus estados.
• Fecha de cierre.
3 Revisión del problema
• Esfuerzo y costes necesarios para la resolución.
• Beneficio aportado.
Una buena clasificación de los incidentes es esencial para extraer información pre-
cisa para la identificación de problemas.
Por otra parte, las soluciones generadas por incidentes se deberían almacenar tam-
bién en la base de datos de problemas, para que el conocimiento se centralice en un
único punto.
Clasificación de problemas. Al igual que los incidentes y los cambios, los proble-
mas deben tener también asignada una categoría y una prioridad (en función del
impacto y urgencia) para poder planificar los recursos adecuadamente.
Es importante que la asignación de una categoría a los problemas sea precisa y bien
realizada, para poder asignar el problema a los equipos de soporte adecuados y,
para una vez resuelto, poder acceder con precisión al conocimiento. La clasifica-
ción de un problema se va depurando según avanza la investigación sobre el
mismo.
Con relación a la prioridad, se necesita que se asigne una a cada problema y aun-
que el volumen de problemas puede ser bajo, el número de recursos asignados a la
gestión de los problemas también suele ser escaso, por lo que disponer de un orden
de ejecución resulta nuevamente fundamental. En la definición del impacto se
estima la criticidad de los servicios que se verían afectados si el problema provocase
un incidente, el número de servicios, el volumen de usuarios amenazados, etc. La
urgencia se determina en función de la probabilidad de que se puedan producir
incidentes.
Los problemas tienen también un estado según avanzan en su ciclo de vida, para
tener un mayor control del proceso y poder realizar análisis estadísticos posteriores.
En la figura 8.3.8 se muestra un ejemplo de algunos detalles relevantes del proceso.
Investigación y diagnóstico de problemas. Los problemas se gestionan de forma
centralizada por el proceso, pero en su investigación y resolución se asignan a los
especialistas de TI, denominados analistas técnicos (propietarios de los elementos
de configuración involucrados en el problema, técnicos de las áreas afectadas,
equipo de desarrollo, responsables del servicio afectado, etc.). En la investigación,
con frecuencia se necesita también la participación de los fabricantes.
El analista técnico de problemas asignado realiza la investigación y diagnóstico con
los medios a su alcance para identificar la causa raíz del problema. Si a lo largo de
esta actividad surgen conflictos por la necesidad de dedicación de recursos, se lo
comunicará al responsable del proceso, de modo que éste pueda tomar las acciones
correctoras necesarias.
Tradicionalmente en este punto de la investigación se describen varias técnicas
genéricas que ayudan al análisis en las tareas de investigación y diagnóstico.
8. Procesos de resolución
8.3. Gestión del problema 603
Solucionado
Cerrado
Prioridad de un problema
IMPACTO
PRIORIDAD
Alto Medio Bajo
Se
Alta rvi
cio
sv
ita
URGENCIA
Pro les
bab , vo
ilid lum
Media ad en
de de
pro usu
duc ari
ir i os,
nci etc
Baja den .
tes
Control de errores
El control de errores se encarga de subsanar los errores y eliminar las causas raíces
que los provocan. Realiza el seguimiento de todos los errores conocidos, desde su
identificación hasta su resolución.
UNE-ISO/IEC 20000-2
Las Normas ISO/IEC 20000 ponen foco en la responsabilidad de gestión del pro-
blema como generador y difusor del conocimiento sobre los errores conocidos. Los
errores conocidos se almacenan en una base de datos, típicamente como un sub-
conjunto integrado en la base de datos de gestión del problema, y se ponen a dis-
posición de otros procesos en modo de sólo lectura. Por otra parte, la gestión del
incidente mantiene la base de datos de incidentes en la que se registra todo lo que
se analiza e identifica en la resolución del incidente. Por tanto, las bases de datos de
problemas y de incidentes son complementarias.
Además, los instrumentos, más utilizados en la resolución de incidentes son el
árbol de tipologías de incidentes, la base de datos de incidentes, con la resolución
de incidentes similares, y la base de datos de problemas, en su vista de los errores
conocidos.
Por ello, la coordinación aquí es muy importante ya que se debe aportar coherencia
y consistencia a las clasificaciones de cada elemento. Muchas veces, aparecen árbo-
les de tipologías (propiedad del proceso de incidentes), que simulan la lista de erro-
res conocidos (propiedad de gestión del problema), que se solapan y confunden al
técnico de soporte de primer nivel.
Identificación y registro de errores. En el proceso los errores se tratan como una
estructura de información específica, por ello, la primera actividad de la etapa de
control de errores es la identificación y el registro de los mismos.
Valoración de errores. En esta actividad se realiza una evaluación de los recursos y
plazos necesarios para las alternativas de solución. En la evaluación se contrasta el
606 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-1
Se deben remitir al proceso de gestión del cambio los cambios necesarios para
corregir la causa subyacente de problemas.
UNE-ISO/IEC 20000-2
Cuando la causa raíz se haya identifi- debería conducir a través del proceso
cado y se haya tomado una decisión de gestión del cambio.
para resolver el error, la resolución se
8. Procesos de resolución
8.3. Gestión del problema 607
UNE-ISO/IEC 20000-2
Comunicación y conocimiento
Las Normas ISO/IEC 20000 recomiendan que se comunique a las partes interesa-
das las soluciones provisionales, permanentes y el progreso de la resolución del pro-
blema. Pero la faceta de comunicación del proceso va más allá, proporcionando una
base de conocimiento de errores conocidos muy importante a la organización en
general y especialmente a la gestión del incidente. Además, presenta informes a la
dirección y a otros procesos sobre la evolución de su actividad, y especialmente al
centro de servicio al usuario.
UNE-ISO/IEC 20000-1
Para que resulte eficaz la resolución de problemas, se debe supervisar, revisar y ela-
borar informes sobre ella.
8. Procesos de resolución
8.3. Gestión del problema 609
El equipo de gestión del problema debe ser responsable de garantizar que esté dis-
ponible, para la gestión de incidentes, la información actualizada sobre errores
conocidos y problemas corregidos.
UNE-ISO/IEC 20000-2
Es una buena práctica poner a disposición libre de todo el personal técnico todas las
soluciones de errores, tendencias, previsiones y el resto de conocimiento que desde
gestión del problema se genere. Y también lo es, aprovechar el feedback que, ante
dicho conocimiento, propongan los colaboradores de los equipos de soporte técnico.
UNE-ISO/IEC 20000-2
Durante el ciclo de vida del problema, se debe registrar información para poder
realizar el seguimiento y escalado. A veces no es sencillo descubrir al inicio del
registro del problema todos los actores que van a acabar trabajando en él. Por esto
se debe alimentar constantemente el registro del caso, con todos los implicados y
sus aportaciones. Como en un análisis forense, cualquier prueba que sea subesti-
mada en una parte del proceso puede ser vital para el esclarecimiento del caso. En
un problema pasa lo mismo; todos los elementos son vitales para la determinación
de la causa raíz.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
En ISO/IEC 20000-2 se detallan los temas que se deben tratar en las revisiones de
los problemas importantes.
8. Procesos de resolución
8.3. Gestión del problema 611
UNE-ISO/IEC 20000-2
Todas las acciones de mejora identificadas a lo largo del proceso de gestión del pro-
blema, tanto técnicas (causas raíz detectadas) como organizacionales, constituye
información importante para aportar al plan de mejora del servicio (SIP, véase el
apartado 6.1) o al plan de mejora unificado de los procesos y de los servicios (véase
el capítulo 4).
UNE-ISO/IEC 20000-1
Se deben llevar a cabo acciones preventivas para reducir los problemas potenciales,
por ejemplo las derivadas de análisis de tendencias de volúmenes y tipos de incidentes.
612 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-2
En ITIL se establece que las actividades principales de los procesos de gestión pro-
activa de problemas son el análisis de tendencias y la identificación de acciones pre-
ventivas.
Análisis de tendencias. El objetivo es identificar componentes frágiles en la
infraestructura de TI e investigar las razones de esta fragilidad. Así, los informes
sobre el análisis de incidentes y problemas proporcionan información sobre medi-
das proactivas. El análisis de tendencias puede llevar a la identificación de defectos
en la infraestructura de TI y también puede llevar a identificar áreas que necesita-
rán más atención del área de soporte.
Identificación de acciones preventivas. Como consecuencia de la actividad ante-
rior se identifican acciones preventivas que de deben implementar e integrar en el
plan de mejora del servicio (SIP) o en el plan de mejora unificado de los procesos y
de los servicios. Debería ser posible establecer comparaciones significativas expre-
sándolas en términos de costes financieros para la organización.
8. Procesos de resolución
8.3. Gestión del problema 613
Los resultados esperados por una buena gestión del problema se pueden apreciar a
través de:
• La reducción de la cantidad de incidentes, al eliminar la causa raíz que los
provoca y, por tanto, evitar su recurrencia.
• La reducción de tiempo para la reparación de un incidente (MTTR), debido
a la base de conocimiento que se va generando, junto con un incremento de
la tasa de resolución de incidentes en primer nivel.
• La reducción de los tiempos necesarios para la resolución de los problemas.
• La disminución de los costes asociados a la resolución.
Figura 8.3.9. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
tengan que intervenir primero para restaurar el servicio y posteriormente para eli-
minar la causa raíz, participando así en los dos procesos asumiendo diferentes roles.
Esta situación puede implicar un conflicto de intereses entre la dedicación a la res-
tauración del servicio y la dedicación a la eliminación de los defectos. Se debe dife-
renciar claramente entre la actuación del personal técnico bajo la resolución de pro-
blemas y en caso de incidentes.
Los participantes en este proceso deben tener una cualificación técnica muy alta,
involucrando a los especialistas, internos o externos, que se necesiten.
Como en el resto de los procesos, los roles que intervienen en el proceso se estruc-
turan en los roles propios del proceso y los roles ajenos al proceso (el gestor del
nivel de servicio).
Los roles propios del proceso son los siguientes:
• El gestor de problemas (gestor del proceso o process manager). Es el respon-
sable de la operación diaria del proceso de gestión de problemas, velando
por la implicación de los equipos ante la definición de un problema, asegu-
rando que se cumplen los SLA, y coordinando los escalados entre grupos en
caso de necesidad.
• Líder de equipo de gestión del problema. Es el responsable de liderar de
forma eficaz y eficiente al equipo de trabajo encargado de la resolución
de un problema
• Analista técnico de problemas. Es el rol encargado de llevar a cabo la investi-
gación, diagnóstico y resolución de problemas. En este rol participan los téc-
nicos especialistas de todo tipo, de desarrollo, técnico de sistemas, del hard-
ware, etc., que participan en las actividades de investigación y diagnóstico
del problema y en la resolución de errores.
Los roles ajenos que son relevantes en este proceso son los siguientes:
• El responsable del centro de servicio al usuario, por la estrecha relación entre
el soporte en la primera línea de incidentes y la gestión del problema.
• El responsable de desarrollo y el responsable de infraestructuras o de tecno-
logía, pues deben proveer técnicos especialistas en las disciplinas que se nece-
siten para identificar y resolver los problemas.
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
• El propietario del modelo SGSTI, que actúa como propietario del proceso
(process owner), define las actividades del proceso y se encarga de la mejora
616 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
continua del mismo. Todo ello, de una forma integrada con el modelo de
gestión del proveedor de TI incorporado en el SGSTI.
Los roles de mayor relevancia que participan en el proceso de gestión del problema
se representan en el gráfico de la figura 8.3.10.
Responsable de la
gestión del servicio
SGSTI
Administrador y
Gestor de soporte del proceso
problemas
Propietario del
modelo (SGSTI)
Resumen
La misión del proceso de gestión del problema es evitar que se produzcan inciden-
tes repetitivos o nuevos. Este proceso es uno de los más eficaces y que mejores
resultados proporciona, pues va buscando y subsanando defectos en los servicios
para hacerlos más estables.
8. Procesos de resolución
8.3. Gestión del problema 617
Beneficios
Entre las ventajas de adoptar un enfoque formal de gestión del problema se inclu-
yen las siguientes:
• Mejora de la calidad de los servicios de TI. La gestión del problema ayuda a
generar un ciclo en el que la calidad de los servicios de TI se incrementa rápi-
damente.
• Reducción del volumen de incidentes. La gestión del problema contribuye a
reducir el número de incidentes que interrumpen el curso normal del negocio.
• Aporte de soluciones permanentes. Se produce una reducción gradual del
número e impacto de problemas y errores, ya que las soluciones son perma-
nentes y no parches provisionales.
• Incremento del conocimiento de la organización. El proceso de gestión del
problema genera la base de errores conocidos que permite reutilizar las expe-
riencias previas.
• Mejora del ratio de resoluciones en la primera línea de soporte. El conoci-
miento generado sobre la resolución de errores permite resolver mayor
número de incidentes en la primera línea.
618 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
Describa un problema relevante que haya ocurrido en su organización, y
sobre él:
• Realice un esquema Ishikawa (raspa de pez) con los errores más fre-
cuentes para un servicio crítico, agrupados según esta metodología de
análisis de causa-raíz.
• En el caso, describa qué se hizo mal, qué se hizo bien y que cambia-
ría en su organización.
1 Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
9 Capítulo 9
Procesos
de control
Tener todo bajo control es el primer deseo de los responsables de TI. Los siste-
mas de información, cada vez más importantes para la empresa, deben evolucio-
nar de una forma controlada. La industria ha consensuado dos procesos cuyo
énfasis se centra en este deseado control de TI y de sus servicios: el proceso de la
gestión de la configuración y el proceso de la gestión del cambio. El primero con-
trola la información sobre los elementos considerados clave para la gestión de los
servicios de TI, y el segundo, que no se cambie nada sin seguir las reglas preesta-
blecidas.
Se puede considerar que la gestión de la configuración supone para TI lo que la
imprenta para la Humanidad: una forma industrializada de tratamiento con rigor
del conocimiento común. Efectivamente, los servicios de TI cada vez más críti-
cos no se pueden gestionar mediante acciones voluntaristas de algunos profesio-
nales de TI, la información y el conocimiento de TI debe ser tratado con rigor
bajo una estricta política definida en la empresa. Sólo de esta forma se podrá
garantizar que las decisiones se toman con la información precisa y fidedigna.
Al avanzar en el presente capítulo se apreciará cómo el proceso de gestión de la
configuración articula las políticas y mecanismos que hacen posible que la informa-
ción que se necesite para la gestión de TI esté disponible y con la calidad y fiabili-
dad deseadas.
Por otra parte, el mayor porcentaje de incidentes y fallos en los servicios de TI pro-
vienen de errores o defectos introducidos al cambiar. Pero los cambios son necesa-
rios para mantener los servicios alineados con la evolución del negocio y de la tec-
nología.
El proceso de la gestión del cambio introduce una serie de mejores prácticas que
ayudan a que la necesaria actividad de realizar modificaciones se realice de la forma
más segura y controlada posible.
Las prácticas más importantes que se aprenderán es este capítulo son las siguientes:
• Cómo diseñar y gestionar la base de datos de la gestión de la configuración.
• Cómo articular la información común para que sea útil.
• Los dos roles para garantizar el control: el gestor de la configuración y el
gestor del cambio.
• Cómo pone orden un simple formulario, la petición de cambio.
• A definir y articular el comité de control de cambios, que posibilita la
coordinación de todos los recursos humanos que están involucrados en un
cambio.
622 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Los tres pilares en los que se sustenta este proceso se resumen en el esquema de la
figura 9.1.3.
Servicios
Documentación
SLAs
CI CI CI CI
Gestor de la CI CI
configuración CI CMDB
CI HW
CI CI CI CI CI
SW
Base de datos de gestión
de la configuración Elementos de configuración
(CMDB) (CI)
Biblioteca de continuidad y
disponibilidad
6.2 Generación de
informes del servicio
6.4 Elaboración de
presupuesto y contabilidad
software definitivo
del servicio de los servicios de TI
9. Procesos de control
9.1 Gestión de la configuración
10. Proceso 9.2 Gestión del cambio 7. Procesos
de entrega de relaciones
10.1 Proceso de gestión 8. Procesos 7.2 Gestión de las
de la entrega de resolución relaciones con el negocio
8.2 Gestión del incidente 7.3 Gestión de
8.3 Gestión del problema suministradores
los procesos. De toda esta información gestionada por los procesos y áreas, sólo se
alojará en la CMDB la que se haya decidido que compartirla aporta valor. No obs-
tante, es necesaria una buena integración entre las herramientas, de tal forma que
desde la CMDB se pueda consultar los registros asociados a un CI que existan en las
herramientas de soporte específico de otros procesos (incidente, capacidad, etc.).
La CMDB está formada por:
• Fichas con la información detallada de cada elemento de configuración, pero
no suele albergar el elemento de configuración en sí mismo. Sólo en los
casos en que los elementos de configuración son documentos electrónicos
(SLA, contratos, etc.), se podrán incluir el CI de forma completa en la CMDB.
Los archivos fuentes y los ejecutables de los programas no se suelen incluir
en la CMDB.
• Relaciones entre los diferentes elementos de configuración.
Las relaciones nos permiten obtener todos los CI que participan en un servicio
determinado.
Con las relaciones se construyen estructuras de configuración o esquemas de rela-
ción, que tienen por eje central el CI que interese conocer en un momento deter-
minado. Forman, por tanto, el árbol en el que se estructuran las categorías de los
elementos de configuración. Así, los esquemas de relación más habituales son
los siguientes:
• Esquema de relación de un servicio, que muestra todos los componentes que
participan en ese servicio.
• Esquema de relación de un servidor, para conocer todo lo instalado en él y
en que servicios está soportando.
• Esquema de relación de red, muestra los componentes de una red.
CMDB
9. Procesos de control
9.1. Gestión de la configuración 631
Identificación de
la configuración Control de configuración
(estructura, alcance y detalle)
(registrar y actualizar)
Modificaciones
a los CI
Planificación e implementación
de la gestión de la
configuración Otros procesos
5. Planificación e implementación de nuevos servicios o de servicios modificados
CI CI CI CI disponibilidad
del servicio
informes del servicio
9. Procesos de control
9.1 Gestión de la configuración
presupuesto y contabilidad
de los servicios de TI
CI CI de entrega
8. Procesos
de relaciones
CMDB
10.1 Proceso de gestión 7.2 Gestión de las
de la entrega de resolución relaciones con el negocio
CI CI
8.2 Gestión del incidente 7.3 Gestión de
8.3 Gestión del problema suministradores
Verificación y CI CI CI CI CI
auditoría de la
configuración
DSL
PDCA Supervisión y Seguimiento del estado de
SGSTI mejora del proceso la configuración e informes
(informar)
Fuente: HP y e.p.
UNE-ISO/IEC 20000-1
Debe existir una visión integrada para la planificación de la gestión del cambio y de
la configuración.
El proveedor del servicio debe definir la interfaz con los procesos de contabilidad
financiera de activos.
Nota: La contabilidad financiera de los activos queda fuera del ámbito de esta sección.
Debe existir una política que defina qué se considera como elemento de configura-
ción y qué componentes lo constituyen.
Deben estar controladas, en una biblioteca física o electrónica segura, las copias
maestras de los elementos de configuración digitales, con referencias a los registros
de configuración, por ejemplo software, productos de prueba, documentos de
soporte.
Todos los elementos de configuración deben ser identificables de manera única y
registrados en la base de datos de gestión de la configuración, cuyo acceso para
CMDB
9. Procesos de control
9.1. Gestión de la configuración 635
UNE-ISO/IEC 20000-2
• Propósito.
• Objetivo.
• Alcance.
• Políticas y procedimientos.
• Estrategia de implantación.
• Planificación de actividades:
– Diseño de la CMDB.
– Diseño de la DSL.
• Organización.
• Herramientas de soporte.
• Análisis de la información disponible y sus
fuentes.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Fuente: Libros ITIL Soporte de Servicio y Transición del Servicio publicados por OGC, y Telefónica.
CI tipo servidor
Fuente: Telefónica.
Hay muchas alternativas y para gustos no hay nada escrito. Lo más sencillo es esta-
blecer una clave con un número secuencial precedido de un acrónimo de categoría
o clasificación dentro de la CMDB, en el máximo nivel de abstracción posible. Por
ejemplo “HW001001” (correspondiente a la categoría hardware). Otros prefieren
incorporar alguna característica del CI a la clave para hacerla más inteligible, pero
esta característica debería ser constante durante la vida del CI, por ejemplo
“HWSER001001” (correspondiente a un servidor en la categoría HW).
Fuente: Libros ITIL Soporte de Servicio y Transición del Servicio publicados por OGC, y Telefónica.
Diseño de la DSL
Gestor de la
configuración
Ficha CI CI CI CI
del CI CI CI
CICMDB CI
Diseño de la DSL: software CI CI CI CI CI
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Las auditorías físicas y periódicas, también deben alimentar los registros de opor-
tunidades de mejora, y arrancar las consiguientes acciones correctivas.
La detección de inconsistencias debe llevar aparejada una concienciación de todos
los implicados sobre la importancia y gravedad (impacto) que puede representar
una inexactitud en la información recogida. Así, no sólo se favorece la mejora con-
tinua, sino que además, se garantiza la solvencia de la CMDB y la DSL, haciéndo-
las cada vez más robustas y fiables.
Figura 9.1.12. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
Los roles ajenos que son relevantes en este proceso son los siguientes.
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
• El propietario del modelo SGSTI, que actúa como propietario del proceso
(process owner), define las actividades del proceso y se encarga de la mejora
continua del mismo. Todo ello de una forma integrada con el modelo de ges-
tión del proveedor de TI incorporado en el SGSTI.
• El responsable de la gestión del cambio debe proporcionar información
de todos los cambios en los CI a los que se ha asignado el control de uno
o varios elementos de configuración. Será un miembro de la organiza-
ción de TI especializado en un ámbito tecnológico, y con el conoci-
miento requerido para identificar y mantener los CI que estén bajo su
área de control.
Resumen
Sin una buena información de la configuración es imposible alcanzar una eficiencia
y madurez en la gestión de las TI. Una información fidedigna y completa sobre la
infraestructura de TI, sus servicios y la organización que los presta, son los cimien-
tos para reducir los incidentes, ser ágiles en la provisión de peticiones, evitar erro-
res en los cambios, etc.
De una forma paulatina pero constante, en la implementación de la gestión del
servicio hay que dedicar esfuerzos importantes a aglutinar y organizar la informa-
ción sobre la configuración de TI. Por ello, es uno de los primeros procesos que
CMDB
9. Procesos de control
9.1. Gestión de la configuración 657
Responsable de la
gestión del servicio
Gestor de la
SGSTI configuración
Administrador de
la CMDB y DSL
Propietario del
modelo (SGSTI)
Administrador y
soporte del proceso
de configuración
Titulares de elementos
de configuración
Gestor del cambio
Beneficios
Algunos de los beneficios de alcanzar una correcta gestión de la configuración son
los siguientes:
• Resolución más rápida de los incidentes y los problemas, que redunda en
una mayor calidad de servicio. Una fuente habitual de problemas es la
incompatibilidad entre diferentes CI (por ejemplo, drivers desactualizados,
etc.). La detección de estos errores sin una CMDB actualizada alarga consi-
derablemente el ciclo de vida de un incidente o de un problema.
• Disponer de los fuentes precisos y actualizados cuando empieza un pro-
yecto de evolución, así como, tener un correcto control de los módulos
que cada equipo de desarrollo está modificando resulta esencial para aho-
rrar esfuerzos inútiles y que varios equipos trabajen sobre software desac-
tualizado.
• De la misma forma, no tiene precio la eficacia y seguridad que le otorga a un
equipo de desarrollo que comienza un proyecto, el conocer con precisión la
configuración real del entrono de producción en donde se explotará el apli-
cativo.
• Una gestión del cambio más eficiente. Es imprescindible para conocer la
estructura previa, analizar el impacto y diseñar un cambio que no genere
nuevas incompatibilidades o incidentes.
• Reducción de costes. El conocimiento detallado de todos los elementos de
configuración permite, por ejemplo, eliminar duplicidades innecesarias y
ahorrar tiempo en repetidas búsquedas de información.
• Control de licencias. Al contrario de lo que pasaba antaño, que el control
de licencias acarreaba el descubrimiento de software ilegal, hoy día tener un
buen control de las licencias puede traer importantes ahorros en costes,
por licencias no utilizadas, por mantenimientos innecesarios, por duplici-
dades, etc.
• Mayores niveles de seguridad. Una CMDB y DSL actualizadas permiten,
por ejemplo, detectar vulnerabilidades en la infraestructura.
• Mayor rapidez en la restauración del servicio. Si se conocen todos los ele-
mentos de configuración y sus interrelaciones será mucho más sencillo recu-
perar la configuración de producción en el tiempo más breve posible.
CMDB
9. Procesos de control
9.1. Gestión de la configuración 659
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• Realice un esquema con los dos primeros niveles de una CMDB para
su organización.
• ¿Qué campos incluiría en la ficha del CI tipo servicio?
• ¿Cómo se organiza en su empresa el paso de los componentes soft-
ware, que suelen mantener de los equipos de desarrollo (control de
versiones), a la DSL?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
9. Procesos de control
9.2. Gestión del cambio 661
La gestión del cambio debe trabajar para asegurar que los cambios:
• Son necesarios y están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio de TI.
• Están convenientemente registrados, clasificados y documentados.
• Cumplen los plazos acordados.
• Han sido cuidadosamente probados en un entorno de prueba.
9. Procesos de control
9.2. Gestión del cambio 663
Fiabilidad, agilidad y eficiencia, son quizá los tres principios directores que debe
regir la gestión del cambio. Fiabilidad para evitar errores y fallos, agilidad para ser
capaces de cambiar los servicios respondiendo al “time to maket” que requiere la
empresa, y eficiencia para realizar el proceso incurriendo en costes mínimos, como
se muestra en la figura 9.2.3.
Figura 9.2.3. Principios directores que deben regir la gestión del cambio
El equilibrio entre estos tres mandatos permitirá que, el control y rigor que impone
este proceso en la organización para conseguir la fiabilidad y reducir el riesgo, se
pueda realizar incurriendo en el mínimo coste organizativo. Si se adoptan procedi-
mientos excesivamente restrictivos, se mejora la fiabilidad, pero se dificultan los
cambios y la organización se vuelve lenta. Si por el contrario el proceso de cambio
se trivializa, se provoca una falta de estabilidad en el servicio que infringirá impor-
tantes costes a causa de incidentes y la imposibilidad de controlar su calidad.
En el diseño del proceso y de las tareas que incluye hay que tener en cuenta el volu-
men de cambios que se tendrán que gestionar, pues una organización grande (por
664 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
ejemplo, de 10.000 usuarios y 500 servidores) suele gestionar entre 70 y 100 peti-
ciones de cambio ya formalizadas a la semana (sin contar los cambios estándar pre-
autorizados), por lo que, gran parte de la actividad del proceso se centra en contro-
lar que todos los involucrados en este flujo sin fin de cambios cumplan las reglas.
Disponer de una herramienta para su soporte es esencial.
También, es conveniente diferenciar las actividades propias de la gestión del cam-
bio de las actividades específicas de la gestión de los proyectos que se encargan de
la construcción de los grandes cambios. El primero hace referencia al proceso
de control de toda la actividad que pueda impactar en los servicios, y el segundo se
encarga de engranar la actividad necesaria para construir o modificar las aplicacio-
nes o plataformas que forman parte de un cambio específico. La gestión del cam-
bio se rige por ISO/IEC 20000, mientras que la gestión de proyectos utiliza disci-
plinas como PMBOK o PRINCE2.
Además, hay que considerar que la gestión del cambio es una parte esencial del pro-
ceso de creación de servicios (planificación e implementación de servicios nuevos o
modificados; véase el capítulo 5), pues da luz verde al inicio de la construcción y se
responsabiliza de la implantación del nuevo servicio.
Gestión del cambio tiene una estrecha relación con gestión de la entrega, pues cada
uno de los cambios aprobados debe ser implantado y desplegado por este último
proceso.
En la figura 9.2.4 se recoge un resumen de los elementos que intervienen el pro-
ceso de gestión del cambio.
Los elementos principales que componen el proceso de gestión del cambio son los
siguientes:
Cambio. Acción específica y prevista que alterará o tendrá un efecto sobre los ser-
vicios o la infraestructura de TI. En general, es cualquier adición, eliminación,
modificación o movimiento de uno o más CI (elementos de configuración). En la
actividad habitual del proceso, los cambios se articulan en función de una serie de
criterios entre los que podemos considerar:
• Atendiendo a su alcance, complejidad o impacto:
– Gran cambio (macro).
– Cambio significativo (mayor).
– Cambio menor.
ACTORES SERVICIOS
CI
Documentación
HW SLAs
Promotores Comité de cambios
de los cambios Gestor del cambio (CAB) SW
Solicitud de cambio
(RFC)
Lista de cambios Gestionar la
planificados (FSC) mejora del proceso
Plan de pruebas
– Cambio estándar.
– Cambio preautorizado.
– Cambio urgente o de emergencia.
ciclo de vida del cambio hasta su último requisito. Son ejemplos, implantar
un nuevo servicio con toda su infraestructura, realizar una consolidación de
servidores, cambiar la arquitectura de los firewalls.
• Cambio menor. De impacto bajo y que requiere pocos recursos. Suelen
recorrer un ciclo de vida mucho más corto, eliminándose actividades de con-
trol que no tienen sentido para estos cambios menores. Por ejemplo, instalar
un servidor nuevo.
• Cambio preautorizado. Cambio recurrente que se gestiona por delegación
siguiendo unas reglas predeterminadas. Para cambios de escasa importancia,
recurrentes o que se repiten periódicamente, pueden acordarse procedimien-
tos estándar que no requieran la aprobación expresa de la gestión del cambio
(cambios preautorizados). Una vez definida esta tipología, permite una ges-
tión más rápida y eficiente de cambios de bajo impacto en la organización de
TI. Por ejemplo, establecer los perfiles de acceso de un nuevo empleado,
generar una nueva contraseña o instalar una aplicación en un PC.
• Cambio de emergencia. Establecen la forma de actuar cuando es impres-
cindible introducir un cambio de forma inmediata para solucionar una crisis
grave.
Clasificación de un cambio. Todo cambio debe ser clasificado para poder tratarlo
de la forma más adecuada posible. De forma similar a los incidentes y los proble-
mas, se establecen dos tipos de clasificaciones: la categoría que tipifica el contenido
del cambio y la prioridad con la que debe ser tratado:
• Categoría del cambio. Tipificación de un cambio según una clasificación
predefinida, que tendrá en cuenta el efecto del cambio en la organización
de TI en función de los recursos que se estimen necesarios para su implan-
tación.
• Prioridad del cambio. Valor que se asigna a la solicitud de cambio (RFC)
para indicar su importancia para la organización. Su objeto es el de asegurar
la adecuada asignación de recursos y determinar el plazo en el que se requiere
su ejecución. La prioridad dependerá de:
– El impacto del cambio. Medida del efecto sobre el negocio.
– La urgencia del cambio. Medida de plazo para la atención de un cambio.
negocio. Se reúne de forma regular para informar al gestor del cambio sobre la ido-
neidad de aprobar cada cambio. El CAB es convocado y liderado por el gestor del
cambio.
Gestor del cambio. Responsable de todo el proceso de gestión del cambio. Res-
ponsable último de que toda la actividad de cambios no impacte en los servicios y
de que se realice según lo establecido.
Herramienta de gestión del cambio. Es el conjunto de aplicaciones y bases de
datos necesarios para dar soporte informático al proceso.
Informe de disponibilidad prevista del servicio (PSA, Projected Service Availa-
bility). Es el documento utilizado en la gestión del cambio para describir el efecto
de los cambios sobre los niveles de disponibilidad definidos en los acuerdos de
nivel de servicio. El PSA muestra detalles de las variaciones de la disponibilidad en
los acuerdos de nivel de servicio, motivadas por el cambio programado propuesto.
Lista de cambios planificados (FSC, Forward Schedule of Change). Es una pro-
gramación unificada de todos los cambios en curso, que recoge los detalles de los
cambios cuya implantación haya sido aprobada, así como las fechas propuestas para
su implantación. En ITIL v3 se ha pasado a denominar “lista de cambios” (change
schedule).
La FSC es controlada por el gestor del cambio y debe ser acordada con todas las
partes: los clientes, la gestión de nivel de servicio, el centro de servicio al usuario,
gestión de la disponibilidad, etc. Una vez acordada, el centro de servicio al usua-
rio debería comunicar a la comunidad de usuarios cualquier planificación o
tiempo adicional de parada para la implantación de cambios, utilizando para ello
los métodos más efectivos disponibles.
La FSC es una entrada esencial del proceso de gestión de la entrega.
Plan de pruebas del cambio. Documento que detalla todas las pruebas necesarias
que se realizarán en todas las etapas por las que pasa el cambio, desde las pruebas
durante la fase de construcción, las pruebas en la fase de implementación, hasta las
pruebas de aceptación final del cambio. El plan de pruebas se prepara en el ámbito
del proyecto.
Promotores de los cambios. Personas de la organización de TI que, a partir de
una necesidad de realizar un cambio, desencadenan la solicitud del cambio. En
cambios grandes o complejos, el cambio se gestionaría como un proyecto y el pro-
motor sería el jefe del proyecto.
Registro de cambios. Base de datos que contiene toda la información relativa a los
cambios en curso ya realizados o rechazados. Contiene las RFC, los detalles sobre
668 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Fuente: Libros ITIL Soporte de Servicio y Transición del Servicio publicados por OGC, y Telefónica.
Figura 9.2.5. Entradas, actividades y salidas del proceso de gestión del cambio
De una forma específica, las Normas ISO/IEC 20000 establecen unas directrices
concretas que el proceso de gestión del cambio debe cumplir y que se deben tener
en cuenta en la planificación, definición, implantación y operación habitual del pro-
ceso.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Para garantizar una correcta gestión de los servicios, los procesos y procedimientos
de gestión de cambio deberán garantizar que los cambios tengan su alcance clara-
mente definido y documentado. En coordinación con la estrategia y la gestión del
porfolio de proyectos, la gestión del cambio también vela por que sólo sean apro-
bados los cambios que proporcionan beneficios al negocio, por ejemplo, comercia-
les, legales, regulatorios o estatutarios.
En la planificación del proceso, es recomendable definir y establecer los motivos
por los que se realizarán cambios, y quienes serán los promotores de estos cambios,
acotándose claramente los actores y la forma en la que se van a producir las entra-
das del proceso.
En la implementación de una adecuada política de gestión del cambio en la
organización se deben superar algunos aspectos culturales críticos como los
siguientes:
• Que los diferentes departamentos acepten la autoridad de la gestión del
cambio.
• Que se sigan con rigor los procedimientos establecidos y, en particular, que
se actualice correctamente en la CMDB la información sobre los elementos
del servicio cambiados.
672 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• Que los encargados de la gestión del cambio conozcan a fondo las activida-
des, servicios, necesidades y estructura de la organización capacitándoles
para desarrollar correctamente su actividad.
• Que los gestores del cambio dispongan de las herramientas adecuadas de soft-
ware para monitorizar y documentar adecuadamente el proceso.
• Y por supuesto, el compromiso suficiente de la dirección por implementar
rigurosamente los procesos asociados.
Fuente: Libros ITIL Soporte de Servicio y Transición del Servicio publicados por OGC, y Telefónica.
En el caso de cambios normales o menores, este ciclo de vida puede resultar pesado
y poco eficiente, por lo que se debería aligerar eliminando las etapas que no apor-
ten valor.
Se debe definir una estructura y formato para la solicitud de cambio. Según sea el
tamaño del cambio, la información a incorporar a la RFC será más amplia cuanta
mayor complejidad tenga el cambio para tener un mejor control sobre él. Así en
cambios grandes, el jefe de proyecto añadirá a la RFC los siguientes documentos:
• Una planificación detallada.
• Un estudio de rentabilidad o business case.
• Un informe de disponibilidad prevista (PSA).
• Un plan de pruebas del cambio.
Registro de la RFC
En todos los cambios, la solicitud de cambio es recibida por el proceso de cambio
y desencadena las actividades del ciclo de vida del cambio. La primera de ellas, es el
registro de la RFC que, normalmente, lo realizará el propio promotor del cambio
en la herramienta de gestión del proceso. En el registro se introduce la información
inicial de la RFC.
Aceptación de la RFC
Tras el registro de la RFC se debe evaluar preliminarmente su pertinencia. Una
RFC puede ser rechazada si se considera que el cambio no está justificado o se
puede solicitar su modificación si se considera que algunos aspectos de la misma
son susceptibles de mejora o mayor definición. En este caso, la RFC debe ser
9. Procesos de control
9.2. Gestión del cambio 677
Identificador de RFC.
Fecha de solicitud.
Intervinientes en el cambio.
Responsable del cambio/Solicitante del cambio - patrocinador del cambio.
Descripción del cambio.
Agenda del cambio.
Fecha de implantación y fechas intermedias relevantes.
Metas y objetivos.
¿Cuál es el estado actual?, ¿Por qué es necesario el cambio? ¿Cuál es el resultado
deseado del cambio? ¿Cuáles son las consecuencias si el cambio es rechazado o
pospuesto?, etc.
Información económica.
Información de costes y presupuesto.
Prioridad del cambio.
Planificación del cambio.
Plan de proyecto de creación del servicio.
Estimación de recursos.
Tiempos/Utilización de recursos; por ejemplo, los tiempos necesarios para
probar/implementar el cambio.
Impacto del cambio.
Proveer información acerca del impacto del cambio (por ejemplo, en la empresa, el
departamento, el sistema). Esta descripción debe marcar la importancia del cambio
y el riesgo asociado.
Documentación.
Información relevante relacionada con las modificaciones provocadas por el cambio
solicitado.
Consideraciones clave y riesgos asociados.
Circunstancias bajo las que no se recomienda implementar el cambio. Requisitos
previos a la implementación del cambio.
Riesgos asociados al cambio. Descripción y aprobación.
Aprobaciones.
Aprobación o denegación de la solicitud de cambio y fecha.
Responsables y firma de los integrantes del CAB intervinientes.
Observaciones/comentarios emitidos en el proceso.
Revisión post implantación.
Resultado del cambio.
Fecha de la revisión.
Responsables y firma de los encargados de la revisión.
Observaciones/comentarios emitidos en el proceso.
Fuente: Libros ITIL Soporte de Servicio y Transición del Servicio publicados por OGC, y Telefónica.
devuelta al departamento o persona que la solicitó, para que se puedan realizar nue-
vas alegaciones o para que pueda ser modificada.
La aceptación de la petición de cambio no implica su posterior aprobación por el
CAB, es sólo indicación de que se ha encontrado justificado su procesamiento.
Categoría
Descripción
del cambio
• El impacto. Medida del efecto sobre el negocio que el tiene cambio actual-
mente o podría tener potencialmente. Se relaciona con el grado de incumpli-
miento del SLA. Se puede valorar en función de la criticidad para el negocio
del/los servicio/s afectado/s, el número de usuarios afectados y su importan-
cia relativa en la organización.
• La urgencia. Medida de la criticidad para la atención de un cambio, en fun-
ción de los tiempos límites que fueron pactados con el negocio. Puede iden-
tificarse con el tiempo disponible para su tratamiento antes de que se llegue
al incumplimiento del SLA. Se puede establecer mediante la estimación del
tiempo necesario para la resolución, tomando como referencia los tiempos
de respuesta establecidos en el SLA.
En cualquier caso, los criterios para definir el impacto y la urgencia deberían esta-
blecerse en coordinación con los responsables del negocio y formalizarse en el SLA.
En la figura 9.2.9 se presentan los tipos de prioridad más habituales y su corres-
pondencia con el procedimiento aplicable.
Tiempo de
Prioridad Descripción Procedimiento
atención
Para la aprobación de la construcción del cambio el gestor del cambio debe eva-
luarlo minuciosamente, especialmente los grandes (de categoría macro y mayor)
contemplando:
• Cuáles son los beneficios esperados del cambio propuesto. Revisión del caso
de negocio (business case) presentado por el promotor del cambio.
• Justificación de esos beneficios frente a los costes asociados al proceso de
cambio.
• Cuáles son los riesgos asociados. Revisión del informe de disponibilidad pre-
vista (PSA).
• Si se dispone de los recursos necesarios para llevar a cabo el cambio, en forma
y plazo, con garantías de éxito.
• Prioridad asignada: urgencia, conocer si puede demorarse el cambio e
impacto, cuál será el impacto general sobre la infraestructura y la calidad de
los servicios de TI.
• ¿Puede el cambio afectar los niveles establecidos de seguridad de TI?
682 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
y/o la gestión de infraestructuras de TI. Pero el proceso de gestión del cambio debe
realizar una supervisión de esta actividad.
En la fase de construcción del cambio se deberá supervisar el proyecto para asegu-
rar que:
• Tanto el software desarrollado como el hardware adquirido se ajustan a las
especificaciones predeterminadas.
• Se cumplen los calendarios previstos y la asignación de recursos es la adecuada.
• El entorno de pruebas es realista y simula adecuadamente el entorno de pro-
ducción.
• Los planes de marcha atrás permitirán la rápida recuperación de la última
configuración estable.
• Si es posible, debe permitirse el acceso restringido de usuarios al entorno de
pruebas para que realicen una valoración preliminar de los nuevos sistemas
en lo que respecta a su funcionalidad, usabilidad y accesibilidad.
Implementación de un cambio
La etapa de implementación corresponde a la integración del cambio en la infraes-
tructura, a las pruebas finales y al paso al entorno productivo.
Aunque la gestión del cambio no es la encargada directa de implementar el cambio,
algo de lo que se encarga habitualmente la gestión de la entrega (con recursos de
infraestructuras y del propio proyecto) o directamente los equipos técnicos, sí es la
encargada de supervisar y coordinar todo el proceso. Mientras que en ISO/IEC
20000 y en ITIL v2 es el proceso de gestión de la entrega (release management), en
ITIL v3 la implementación de cambio se realiza bajo el proceso denominado “ges-
tión de versiones y despliegues” (release and deployment management).
UNE-ISO/IEC 20000-1
Se debe revisar el éxito de todos los cambios y, en caso contrario, se deben decidir y
llevarse a cabo acciones correctivas tras la implementación.
UNE-ISO/IEC 20000-2
Si la evaluación final determina que el proceso y los resultados han sido satisfacto-
rios, se procederá al cierre de la RFC.
9. Procesos de control
9.2. Gestión del cambio 685
Cambios de emergencia
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios
afectados o porque se han visto involucrados sistemas o servicios críticos para la orga-
nización, debe encontrar una respuesta inmediata adecuada. Es frecuente que la solu-
ción al incidente requiera un cambio urgente, pero hasta las urgencias y las situacio-
nes de crisis, deben estar reguladas mediante un procedimiento de emergencia.
El procedimiento que se debe seguir en estos casos de crisis debe estar debidamente
previsto. Como el objetivo prioritario en estas situaciones críticas es restaurar el
servicio, es a menudo frecuente que los procesos asociados sigan un orden inverso
al usual, realizándose a posteriori tanto en los registros en la CMDB, como en la
documentación asociada al cambio.
686 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Figura 9.2.11. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
9. Procesos de control
9.2. Gestión del cambio 689
Los roles ajenos que son relevantes en este proceso son los siguientes:
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
• El propietario del modelo SGSTI, que actúa como propietario del proceso
(process owner), define las actividades del proceso y se encarga de la mejora
continua del mismo. Todo ello, de una forma integrada con el modelo de
gestión del proveedor de TI incorporado en el SGSTI.
• Los jefes de los proyectos de desarrollo o de infraestructuras que controlan
todas las actividades asociadas a los cambios grandes.
• Los especialistas técnicos.
Los roles de mayor relevancia que participan en el proceso de gestión del cambio
se representan en el gráfico de la figura 9.2.12.
Resumen
La necesidad de continua evolución de las tecnologías de la información requiere
una actividad constante de cambios en las infraestructuras y en los desarrollos para
permanecer actualizado y evitar que los servicios se queden obsoletos.
El proceso de gestión del cambio es clave para mantener la estabilidad de los
servicios, pues regula y controla toda actuación sobre ellos. El proceso necesita
690 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Responsable de la
gestión del servicio
Promotores
Gestor
o solicitantes
del cambio
SGSTI de los cambios
Propietario del
modelo (SGSTI)
Comité de cambios
(CAB)
Administrador y
Especialistas soporte del proceso
técnicos del cambio
Beneficios
Los principales beneficios derivados de una correcta gestión del cambio son los
siguientes:
• Se reduce el número de incidentes y problemas potencialmente asociados a
todo cambio. Por lo tanto, se reduce el riesgo asociado a los cambios.
• Se reducen los plazos medios en la implantación de los cambios.
• La organización realiza los cambios con más eficiencia.
• Se reduce el impacto en el negocio debido a las paradas asociadas a los
cambios.
• Se puede retornar a configuraciones estables de manera sencilla y rápida en el
caso en el que el cambio tenga un efecto negativo.
• Se reduce el número de operaciones de marcha atrás necesarias.
• Los cambios son mejor aceptados y se evitan “tendencias inmovilistas”.
• Se evalúan los verdaderos costes asociados al cambio y, por tanto, es más sen-
cillo valorar el retorno real de la inversión.
• La CMDB y la DSL están correctamente actualizadas, algo imprescindible
para la correcta gestión del resto de los procesos de TI.
• Se reducen las actuaciones de emergencia y el trastorno que ocasionan en el
trabajo diario.
• Se desarrollan procedimientos de cambio estándar que permiten la rápida
actualización de sistemas no críticos.
692 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• Cite tres ejemplos en su organización de cambios pre-autorizados, de
cambios mayores y de cambios de emergencia.
• Por limitación de recursos, debe escoger sólo 3 procesos para imple-
mentar en primer lugar. Si uno de ellos es gestión del cambio, ¿qué
otros dos procesos implementaría en su organización?
• ¿Qué aspectos de lo descrito en este apartado no se adaptan bien a
su organización? ¿Por qué?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
10 Proceso de gestión
de la entrega
Capítulo 10
La mayor cantidad de fallos en los servicios viene generada por errores en los cam-
bios e implantaciones, tanto por defectos en su construcción como por errores en
las operaciones que conlleva la puesta en explotación. Pero las organizaciones de TI
deben mantener un ritmo constante de cambios y de creación de nuevos servicios
para responder de una forma ágil a las necesidades del negocio.
Realizar cambios en los servicios no es tarea sencilla, tanto por la cantidad de com-
ponentes hardware y software, como por el número de suministradores que entran
en escena para mantener los servicios de TI. Además, se requiere que los servicios
evolucionen sin interferir en la producción normal, manteniendo los niveles de servi-
cio acordados y garantizando los tiempos comprometidos, no sólo para las tareas
identificadas del despliegue, sino también para los plazos que marca el negocio
(time to market).
La importante misión de introducir cambios se realiza mediante dos procesos: la
gestión del cambio y la gestión de la entrega. Si la gestión del cambio pone control
y orden en todas las peticiones de cambio, bajo el concepto del proceso de entrega,
se agrupan las actividades operativas necesarias para que el cambio se ponga en el
entorno productivo, minimizando el riesgo de fallos y maximizando la eficiencia de
las tareas que se deben llevar a cabo.
Las Normas ISO/IEC 20000 dedican la mayor extensión de requisitos y recomen-
daciones a este proceso. El éxito en este proceso de entrega vendrá dado por la uti-
lización de unos procedimientos y tareas bien desarrollados y controlados, que per-
mitan una gestión correcta de los recursos puestos a disposición del proceso, y la
optimización y mejora del mismo.
Un proveedor de TI de tamaño medio suele realizar entre 70 y 100 cambios sema-
nales en sus servicios. Además de esto, cada servicio operativo suele tener dos o tres
grandes versiones al año. Para complicarlo aún más, muchos estos cambios se debe-
rán realizar fuera de la jornada laboral. Por tanto, la realización de una forma segura
y eficiente de las tareas de implementación de los cambios resulta esencial para la
calidad de los servicios y para la tranquilidad de todos. En este capítulo encontrará
las prácticas más avanzadas para lograrlo.
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 697
El nombre del proceso de gestión de la entrega, del término inglés release manage-
ment, ha tenido múltiples traducciones al castellano. También se le conoce como
gestión de despliegues, gestión de versiones, gestión de lanzamientos, gestión de
despliegue de versiones, etc. En ISO/IEC 20000 e ITIL v2 se ha traducido como
gestión de la entrega, mientras que en ITIL v3 adopta el nombre de gestión de des-
pliegues y versiones (release and deployment management) 1.
La gestión de la entrega ejecuta las acciones a realizar para producir el cambio auto-
rizado.
Los cambios se convierten en entregas una vez que han sido construidos y ha sido
aprobada su transición, por ello, toda entrega ha tenido que pasar primero por la
gestión del cambio. El proceso se activa con la recepción de la petición de cambio
aprobada (RFC) y de los elementos a instalar. Desde este momento hasta que el
cambio ha sido incorporado a la producción normal, es necesaria la intervención
1
Véase la terminología acordada por el sector en www.itsmf.es
698 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Despliegue
(automatización)
Política
de entregas
Planificación
de la entrega
Metodología
de pruebas
Plataformas
de pruebas
e integración
Entrega
CMDB DSL
Lista de cambios Base de datos Biblioteca de Almacén definitivo
planificados (FSC) de gestión de software definitivo de hardware
la configuración
Los componentes que intervienen en el proceso de gestión del incidente son los
siguientes.
Almacén de Hardware Definitivo (DHS). Uno o varios emplazamientos dis-
puestos para el almacenamiento seguro de componentes y repuestos de hardware.
Estos componentes se gestionan con el mismo nivel que los elementos de configu-
ración hardware equivalentes del entorno de producción. El mantenimiento com-
pleto del DHS es responsabilidad directa del proceso de gestión de la entrega. En
ITIL v3, en el proceso de gestión de la configuración se habla del almacenamiento
de los recambios o repuestos definitivos (DS, Definitive Spares).
Base de Datos de Gestión de la Configuración (CMDB). Base de datos gestio-
nada por el proceso de gestión de la configuración y que el proceso de gestión de la
entrega debe actualizar con los cambios a los elementos de configuración (CI) que
realice de forma coordinada con gestión de la configuración.
Biblioteca de Software Definitivo (DSL). La gestión de la entrega debe actuali-
zar este repositorio con las últimas versiones del software implementado en produc-
ción, así como con la parametrización realizada y la documentación asociada. En
ISO/IEC 20000 la responsabilidad de este repositorio recae en gestión de la confi-
guración. Por tanto, al igual que en el caso de la CMDB, cualquier actualización en
esta biblioteca debe estar coordinada con el proceso de gestión de la configuración.
Despliegue. Es la acción de poner en producción el conjunto de cambios que con-
tiene una entrega. Es importante poner foco en la automatización de este proceso
mediante el uso de las herramientas técnicas adecuadas.
Entrega. Es un conjunto de cambios aprobados en un servicio TI, que se prueban
e introducen como conjunto en el entorno de producción. Consta del software
nuevo o modificado y del hardware nuevo o modificado. Se define por las RFC que
implementa. La entrega se caracteriza por:
• Unidad de entrega. Porciones de los servicios que normalmente se imple-
mentan a la vez. Generalmente, esta unidad es variable, dependiendo de los
tipos de elementos de software y hardware implicados
• Tipo de entrega. Se definen varias categorías de entregas en función del
impacto (mayores y menores), la urgencia (normales y emergencia) y la tasa de
renovación de elementos de configuración (completas, delta y empaquetadas).
• Identificación de la entrega. Las entregas deben estar identificadas unívo-
camente de acuerdo a un esquema definido en la política de entregas. Debe
incluir una referencia al servicio o elemento de configuración que representa
y un número de versión de hasta tres niveles (por ejemplo, servicio_
nomina_V2.3.6).
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 703
la conexión del aplicativo software con el entorno real (reglas del firewall, segmenta-
ción de VLAN, integración con el middleware, automatización de tareas batch, inte-
gración en la monitorización, integración en el backup, etc.) para poder comprobar
su correcto funcionamiento antes del paso a producción regular.
Política de entrega. Define las funciones y responsabilidades principales de la ges-
tión de la entrega. Establece las pautas en toda la organización para la implementa-
ción de los cambios. Normalmente se suelen definir tres o cuatro grandes ciclos de
entrega anuales, que regula todo el mantenimiento evolutivo y correctivo de las
aplicaciones. Los cambios que no pueden asociarse a estos ciclos anuales, se gestio-
nan “al detalle” intentando agruparlos o empaquetarlos. La política de entrega debe
incluir también la numeración, frecuencia de las entregas y el nivel de infraestruc-
tura TI comprendido en las entregas. La política de entrega es parte del plan del
proceso de gestión de la entrega.
Revisión (PIR, Post Implementation Review). Comprobación técnica y funcional
que se realiza transcurrido un determinado período de tiempo tras la implantación
de la entrega y cuyo objetivo es el de validar si los efectos de los cambios han sido
los deseados, para proceder al cierre definitivo de la entrega y, consecuentemente,
de los cambios que alberga. La realiza el proceso de gestión de la entrega, la lidera
el gestor del cambio.
La entrega
Se define como entrega a una colección de hardware, software, documentación,
procesos u otros componentes requeridos para implementar uno o más cambios
aprobados a los servicios de TI. Los contenidos de cada entrega son administrados,
probados e implementados como una única entidad (Glosario ITIL v3, OGC).
Las entregas se suelen clasificar según su impacto en la infraestructura TI, en las
siguientes categorías:
• Entregas mayores. Representan importantes despliegues de software y hard-
ware, y que introducen modificaciones importantes en la funcionalidad,
características técnicas, etc.
• Entregas menores. Suelen implicar la corrección de errores conocidos pun-
tuales. Su tamaño reducido no exime que se implementen de una manera
procedimentada y correctamente documentada.
UNE-ISO/IEC 20000-1
Nota: El proceso de gestión de la entrega se debería integrar con los procesos de gestión de la configu-
ración y de gestión del cambio.
El proveedor del servicio debe planificar con el negocio la entrega de los servicios,
sistemas, software y hardware. Los planes sobre cómo desplegar una entrega se
deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes,
usuarios, personal de operaciones y de soporte.
UNE-ISO/IEC 20000-2
En la implementación del proceso hay que considerar las relaciones con otros pro-
cesos. La gestión de la entrega, está estrechamente ligada con la gestión de la confi-
guración y la gestión del cambio:
• Gestión de la configuración, para asegurar que toda la información relativa a
las nuevas versiones se integra adecuadamente en la CMDB, de forma que
ésta se halle correctamente actualizada y ofrezca una imagen real de la confi-
guración de la infraestructura TI.
• Gestión del cambio: la gestión de la entrega tiene la responsabilidad de
implementar las entregas acordadas por el comité de cambios. La gestión del
cambio es la encargada de aprobar y supervisar todo el proceso, pero es tarea
específica de la gestión de la entrega el diseñar, poner a prueba e instalar en
el entorno de producción los cambios preestablecidos.
Política de entrega
La principal misión de la política de entrega es que toda la organización entienda y
asuma la función de la entrega y su alto nivel de implicación y responsabilidad en la
construcción y evolución de los servicios, una vez aprobados por la gestión del
cambio. La política de entrega se debe realizar alineada con la política de construc-
ción de servicios y la estrategia de TI.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Política de entrega
Implant.
El ciclo de vida completo de una entrega comienza una vez que el cambio ha sido
construido, aceptado por el equipo técnico y aprobada su implementación por la
gestión del cambio. En la figura 10.1.7 se presenta el ciclo típico de una entrega.
El ciclo de vida completo de una entrega se resume en:
• La gestión del cambio (el gestor o el CAB) aprueba la implantación del cam-
bio construido. La aprobación actúa como desencadenante del proceso de
gestión de la entrega.
• Se realiza la aceptación y revisión preliminar del cambio construido. Se rea-
liza la primera planificación, acorde con lo previsto en el proyecto de cons-
trucción.
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 713
• Realizar la formación necesaria a los usuarios y técnicos para que sean capa-
ces de gestionar los nuevos servicios.
• Garantizar y ejecutar un plan de marcha atrás a un punto consistente si la
entrega no tuviera éxito.
• Comunicar y formar a los clientes y usuarios sobre las funcionalidades de
la nueva versión.
• Comunicar y formar a los técnicos y responsables de producción sobre la
operación de la nueva versión, errores conocidos o cambios en los niveles
de servicio.
• Actualizar la CMDB, DSL y DHS. Es fundamental garantizar que se han
actualizado correctamente estos repositorios.
• Realizar la verificación postimplementación de la entrega y comunicárselo a
la gestión del cambio.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe planificar con el negocio la entrega de los servicios,
sistemas, software y hardware. Los planes sobre cómo desplegar una entrega se
deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes,
usuarios, personal de operaciones y de soporte.
El proceso debe incluir la forma en que se de marcha atrás o se corrija la entrega si
no se realiza con éxito.
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 715
Los planes deben registrar los entregables y las fechas de la entrega, y hacer refe-
rencia a las peticiones de cambio, errores conocidos y problemas relacionados.
El proceso de gestión de la entrega debe proporcionar la información adecuada al
proceso de gestión del incidente.
Las peticiones de cambio se deben evaluar en cuanto a su impacto en los planes de
entregas. Los procedimientos de gestión de la entrega deben incluir la actualización
y el cambio de la información de configuración y los registros de cambio. Las entre-
gas de emergencia se deben gestionar de acuerdo a un proceso definido que rea-
lice la interfaz con el proceso de gestión del cambio de emergencia.
UNE-ISO/IEC 20000-2
El proveedor del servicio debería traba- errores conocidos que hayan sido
jar conjuntamente con el negocio para identificados durantes las pruebas
asegurar que los elementos de configu- de la entrega;
ración que se van a desplegar en una c) los procesos relacionados para la
entrega son compatibles entre sí y con implementación de una entrega a
los elementos de configuración del lo largo de todo el negocio y las
entornode destino.
diferentes unidades geográficas;
La planificación de la entrega debería
d) el modo en el que se dará mar-
asegurar que los cambios de los siste-
cha atrás de la entrega o en que
mas de información, infraestructuras,
esta se remediará si no se con-
servicios y documentación afectados
cluye con éxito;
son acordados, autorizados, planifica-
dos, coordinados y que se realiza un e) los procesos de verificación y acep-
seguimiento de los mismos. tación;
La entrega y el despliegue se deberían f) la comunicación, preparación,
planificar en etapas ya que los detalles documentación y formación para
del despliegue podrían no ser conoci- los clientes y personal de apoyo;
dos inicialmente. g) la logística y los procesos implica-
La planificación de una entrega y del dos para realizar la compra, el
despliegue normalmente debería incluir: almacenamiento, la expedición, la
a) las fechas de la entrega y la des- conexión, la aceptación y la puesta
cripción de los entregables; a disposición de los bienes;
b) los cambios y problemas relacio- h) los recursos de apoyo necesarios
nados, errores conocidos cerra- para asegurar el mantenimiento
dos o resueltos por esta entrega y de los niveles de servicio;
716 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• Qué planes de comunicación y/o formación deben desarrollarse para que los
usuarios estén puntualmente informados y puedan percibir la nueva versión
como una mejora.
• Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en
todos los emplazamientos, gradual.
• Cuál es la vida media útil esperada de la nueva versión.
• Qué planes de comunicación y/o formación deben desarrollarse para que los
técnicos y responsables de producción puedan operar y explotar esta nueva
versión.
• Qué impacto puede tener la entrega en la calidad del servicio y en los niveles
de servicio acordados.
• Informar del modelo de operación, para la resolución de errores conocidos,
o posibles incidentes en la producción.
• Si es posible establecer métricas precisas que determinen el grado de éxito
del lanzamiento de la nueva versión.
• Hardware:
– Las especificaciones del hardware.
– Las instrucciones de ensamblaje y los manuales de instalación.
– Documentación, manuales de uso de configuración, soporte y manteni-
miento.
– Contrato de mantenimiento, garantías, soportes, relación de proveedores
y fabricantes, etc.
718 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
• Documentación:
– Aplicaciones, sistemas, herramientas, utilidades, hardware, etc.
• Control y gestión:
– Inclusión en los sistemas de monitorización y alertas.
– Inclusión en los sistemas de gestión del servicio.
• Personas:
– Técnicos que deberán intervenir.
– Personas del área cliente o usuarios que deberán participar para validar los
resultados.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Es importante que los planes de pruebas incluyan también la prueba de los planes
de marcha atrás, para asegurar la posibilidad de volver a la última versión estable
de una forma rápida, ordenada y sin pérdida de información valiosa.
Las principales actividades realizadas en el proceso de prueba deben incluir:
• Pruebas del correcto funcionamiento de la versión en un entorno realista.
• Pruebas de integración con la versión en producción. Si se realiza un desplie-
gue fragmentado en el entorno de producción, será necesario realizar las
pruebas con las versiones operativas.
• Pruebas de regresión si fueran necesarias en preproducción.
• Pruebas de capacidad en el entorno de preproducción.
• Pruebas de los procedimientos automáticos o manuales de instalación.
• Listas de errores detectados, si se diera el caso.
• Pruebas de los planes de marcha atrás.
• Documentación para usuarios, técnicos de soporte y desarrolladores.
UNE-ISO/IEC 20000-1
UNE-ISO/IEC 20000-2
Destacar que también debe ser parte integrante del desarrollo los planes de marcha
atrás asociados. Estos tendrán que tomar en cuenta la disponibilidad acordada con
los clientes en el SLA.
Es necesario que todo procedimiento de entrega, genere un histórico de su resultado.
La documentación de las entregas debe seguir un patrón uniforme definido. La
metodología de desarrollo o construcción utilizada, debe contemplar la descripción
de la documentación a utilizar. Los modelos de documentación deberán adecuarse
al tipo de entrega, centrándose en que la documentación de la entrega contenga
todos los apartados de utilidad. Con frecuencia se utiliza el mismo patrón de docu-
mentación para una gran entrega que para cambios sencillos, resultando bastante
pesada e inútil.
La documentación va evolucionando desde archivos de texto aislados, hacia siste-
mas documentales integrados. Cada vez es más frecuente, que la documentación de
los servicios y sus evoluciones se estructuren en un sistema web que se convierte en
una ayuda o consulta online accesible de forma selectiva por todas las partes de la
organización.
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
UNE-ISO/IEC 20000-2
Figura 10.1.8. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
Los roles ajenos que son relevantes en este proceso son los siguientes:
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
• El propietario del modelo SGSTI actúa como propietario del proceso (pro-
cess owner). Define las actividades del proceso y se encarga de la mejora con-
tinua del mismo. Todo ello, de una forma integrada con el modelo de ges-
tión del proveedor TI incorporado en el SGSTI.
• El responsable de la gestión del cambio, que debe autorizar el inicio de las
pruebas e integración, la implantación en producción y el cierre de la entrega.
Resumen
El proceso de la gestión de la entrega proporciona control sobre la implementación
de los cambios, garantiza la calidad de lo construido y vela por minimizar el
impacto de las paradas en los entornos productivos. Junto con la gestión del inci-
dente, es uno de los procesos que más recursos consume de TI y más tensión
genera, por lo que deberá tenerse en cuenta en su primera implementación y en el
ciclo de mejora continua.
Por tanto, la gestión de la entrega:
• Proporciona confianza, en cuanto a robustez de la solución, al haber sido
certificada en los entornos y modelos de pruebas.
• Aporta eficiencia a la organización, al ofrecer una sistemática para el desplie-
gue de componentes, optimizado y monitorizado, que reduce el tiempo nece-
sario para realizar estas tareas. Automatizando aquellas que sean repetitivas.
• Pone orden manteniendo un listado de cambios planificados (FSC).
• Ejerce control sobre los servicios, al disponer de una sistemática para instalar
cualquier versión de estos.
• Garantiza, de forma coordinada con el proceso de la gestión del cambio, la
disponibilidad y estabilidad de la operación diaria de los servicios con una
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 729
Responsable de la
gestión del servicio
SGSTI
Gestor de Administrador y
la entrega soporte del proceso
de entrega
Propietario del
modelo (SGSTI)
política de entregas pactadas, con fechas para los pasos a explotación acorda-
dos. Esto permite hacer un calendario junto con los responsables de los servi-
cios, que posibilita el no hacer coincidir en el tiempo despliegues y puntas
de negocio, o fechas críticas para la correcta prestación del servicio.
• Prevé con anterioridad la necesidad de recursos para el proceso, lo que per-
mitirá una correcta planificación de las personas y los componentes.
• Controla a los proveedores en cuanto a la validez de sus entregas.
• Garantiza de que la CMDB esta correctamente actualizada.
• Controla el software instalado en producción, su parametrización y documen-
tación, a través de una DSL actualizada. Esto incluye no sólo sistemas ope-
rativos y aplicaciones sino también controladores de dispositivos y documen-
tación asociada.
730 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Beneficios
Los principales beneficios aportados por el proceso de gestión de la entrega son los
siguientes:
• Los cambios en los servicios se realizan sin deterioro de la calidad de servicio.
• Las nuevas versiones cumplen los objetivos propuestos.
• Se reduce el número de incidentes por incompatibilidades con otro software
o hardware instalado.
• Se establece un orden lógico para el paso a producción, que permite la inte-
gración no traumática de las diferentes soluciones, evitando los incidentes
por efectos colaterales en producción.
• El proceso de pruebas asociado, no sólo permite asegurar la calidad del software
y hardware que se va a instalar, sino que también permite conocer la opinión de
los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.
• También permite detectar posibles problemas de capacidad, en las pruebas
realizadas, y actuar con la gestión de la capacidad, para garantizar las necesi-
dades en producción.
• El correcto mantenimiento de la DSL impide que se pierdan las valiosas
copias de los archivos fuente.
• Se reduce el número de copias de software ilegales.
• Control centralizado del software y hardware desplegado.
• Se garantiza la existencia de un plan de marcha atrás a un punto estable, que
garantiza la posibilidad de continuidad de la explotación, todos los despliegues
son controlados en cuanto un nivel de impacto y riesgo sobre la producción.
• Protección contra virus y problemas asociados a versiones de software incon-
troladas.
• Se garantiza la existencia de los procedimientos de gestión y monitorización,
que permiten la correcta operatividad en producción, del software y hardware
desplegado.
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 731
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 2:
• ¿Cómo encaja la metodología de pruebas en el proceso de entrega?
• El equipo de desarrollo de software, ¿qué papel juega en este pro-
ceso?
• Cite dos mejores prácticas en su organización relativas al proceso de
entrega.
2
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
11
Capítulo 11
La certificación de la
gestión del servicio de TI
conforme a ISO/IEC 20000
De forma paulatina, se observa que la alineación con ISO/IEC 20000 es cada vez
más un criterio empleado en la toma de decisiones relevantes en la contratación de
recursos de TI, dado que la aplicación de estas normas permite a cualquier provee-
dor de servicios de TI acreditar la calidad en la prestación de sus servicios. Esto
quiere decir que están alineados con el negocio, que se aplican criterios de eficien-
cia, que se reducen los riesgos de operación del servicio, que se satisfacen los requi-
sitos de sus clientes, que se vela por el cumplimiento de los suministradores, etc.
Para obtener la certificación ISO/IEC 20000 es necesario tener implementado el
sistema de gestión del servicio de TI (SGSTI) y también haber evolucionado en las
formas de trabajar para incorporar las prácticas y los requisitos de estas normas.
A partir de este momento, se está en disposición de cubrir una serie de etapas nece-
sarias para la obtención de la certificación.
El ciclo de certificación no es un recorrido lineal que empieza y termina. Más
bien, es parecido a un círculo de mejora, que comienza con la certificación inicial
y que culmina con el mantenimiento y mejora en la calidad de la gestión de los
servicios. Este aspecto es clave en ISO/IEC 20000-1. Por ello, en las normas se
738 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
1. Determinar alcance
2. Solicitud de certificación
3. Auditoría fase I:
Análisis de documentación
4. Auditoría fase I:
Visita previa
5. Auditoría fase II
La primera
certificación ¿Existen Sí
no conformidades?
Plan de acciones
correctivas
6. Evaluación y decisión
Sí
8. Auditorías de seguimiento
Mantenimiento de (años 1 y 2)
la certificación
9. Auditoría de renovación Responsabilidad proveedor TI
(cada tercer año) Lidera el certificador
Fuente: AENOR.
PDCA. Pero no está tan claro si se deben certificar todos los servicios, todas las
localizaciones, todos los clientes a la vez. De aquí, la importancia en consensuar el
alcance.
Es frecuente acometer el alcance completo en varias certificaciones sucesivas, más
pequeñas, más rápidas y con menos riesgo de fracaso. Es importante que los servi-
cios seleccionados para la certificación sean lo suficientemente representativos para
el proveedor de TI, ya sea por volumen de actividad, impacto en la cuenta de resul-
tados, etc.
Una vez identificados los servicios hay que determinar las ubicaciones en las que se
prestan. Es necesario identificar qué ubicaciones entrarán a formar parte de la cer-
tificación. En este punto, lo deseable es que las ubicaciones elegidas sean todas en
las que se prestan los servicios seleccionados y, en el caso de certificaciones con el
alcance reducido deben ser lo suficientemente representativas. Además, las exclu-
siones deben estar perfectamente justificadas.
Llegados a este punto es recomendable que el proveedor de TI realice una evalua-
ción de la situación actual del alcance definido para la certificación (véase la evalua-
ción o assessment descrito en el capítulo 4). De esta forma, podrá determinar su
situación respecto a los requerimientos de la norma. En el caso de necesitar acome-
ter mejoras en el sistema de gestión del servicio de TI, evaluar su viabilidad, y
tomar la decisión de si se inicia el proceso de certificación.
Hasta este momento el proveedor de TI no ha tenido contacto con el equipo de
auditoría de la certificación, por lo que la definición del alcance y la evaluación rea-
lizados son internas y no están validadas por el certificador.
2. Solicitud de certificación
El siguiente paso cubre la confección del “formulario de solicitud de certificación”,
que la entidad de certificación remite al proveedor de TI previa solicitud.
En la solicitud se incluye información, como por ejemplo, el alcance de la certifica-
ción, contactos, direcciones, número de personas de la organización, número de
emplazamientos, etc. (véase la figura 11.1.3).
Esta información es importante, ya que proporciona una idea de la dimensión del
sistema de gestión de servicios que se pretende certificar y que será una de las varia-
bles que se deben tener en cuenta a la hora de planificar la auditoría. Esta planifica-
ción determina el volumen de las actividades que se van a realizar y la estimación
de carga de trabajo, que dará como resultado una oferta de la entidad de certifica-
ción con un presupuesto.
11. La certificación de la gestión del servicio de TI conforme a ISO/IEC 20000
11.1. La primera certificación conforme a ISO/IEC 20000 741
Fuente: AENOR.
serán tenidas en cuenta por el equipo auditor en la siguiente actividad, que se deno-
mina visita previa.
Este análisis se puede realizar tanto en las instalaciones de la organización de TI,
como en las instalaciones de la entidad certificadora. En ocasiones se realiza
de forma conjunta con la visita previa que se detalla a continuación. El análisis de
documentación y la visita previa forman parte de la auditoría fase I.
5. Auditoría fase II
La auditoría fase II es la actividad clave en el proceso de certificación. En ella el
equipo auditor evalúa al completo el sistema de gestión de servicios de TI
(SGSTI). Analiza su conformidad con relación a los requisitos de la norma y com-
prueba su implantación y funcionamiento operativo.
Para ello, la entidad certificadora confecciona un plan de auditoría específico para
el cliente (véase la figura 11.1.4).
La auditoría fase II comienza con una reunión en la que se presenta el plan de tra-
bajo de la auditoría y se concretan las entrevistas con las personas de las áreas que
serán objeto de la visita. Esta etapa, dependiendo del alcance de la certificación
acordado, puede durar entre 3 y 6 jornadas.
Para cada uno de los servicios y centros incluidos en el alcance de la certificación, se
revisará el cumplimiento del manual de gestión de servicios y su adecuación a la
norma objeto de certificación. Para realizar esta labor, el equipo auditor revisará el
cumplimiento de la norma mediante comprobaciones in situ y evidencias formales
de su cumplimiento.
El resultado de la auditoría fase II se plasma en un informe, en cuyo contenido se
reflejarán las “no conformidades” o incumplimientos detectados por el equipo
auditor. Dichos incumplimientos estarán contrastados frente a los requisitos espe-
cificados por la norma, los legales o reglamentarios, los de los clientes de la organi-
zación o los propios del SGSTI.
El informe será entregado y comentado en la reunión final de auditoría.
Plan de acciones correctivas. En el caso que el informe de la auditoría refleje no
conformidades, el proveedor de TI debe confeccionar un documento específico: el
Plan de Acciones Correctivas (PAC).
Para ello, la organización dispone de un plazo de tiempo establecido para presentar
a la entidad de certificación el plan de acciones correctivas dirigido a subsanar las no
conformidades detectadas en la auditoría. En dicho plan se debe incluir un análisis
11. La certificación de la gestión del servicio de TI conforme a ISO/IEC 20000
11.1. La primera certificación conforme a ISO/IEC 20000 745
• Nombre de la empresa.
• Domicilio.
• Alcance de la auditoría.
• Normas de referencia que aplican.
• Composición del equipo auditor.
• Programa de trabajo, detallando:
– Reunión inicial:
• Fechas y horarios.
• Auditores y asistentes.
• Agenda.
– Reuniones de auditoria:
• Fechas y horarios.
• Auditores y asistentes.
• Servicios de TI y apartados de la
norma a auditar en cada reunión.
– Reunión final:
• Fechas y horarios.
• Auditores y asistentes.
Fuente: AENOR.
de las causas que motivaron cada uno de los incumplimientos y, también, deben
quedar reflejados los responsables de la implantación de dichas acciones.
Una vez emitido el plan de acciones correctivas, puede ocurrir que se necesiten
aclaraciones relacionadas con las acciones enviadas, por lo que podría ser necesario
efectuar “ampliaciones del PAC”.
6. Evaluación y decisión
Cuando se ha cerrado el plan de acciones correctivas, el responsable de la auditoría
envía un informe a la entidad de certificación con una recomendación sobre la con-
veniencia de conceder, o no, la certificación al proveedor de TI solicitante.
746 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
8. Auditorías de seguimiento
El certificado tiene una validez de tres años. A lo largo de los cuales la entidad cer-
tificadora realizará auditorías de seguimiento para comprobar que el sistema de
gestión continúa cumpliendo con los requisitos indicados en la norma y que cada
año el SGSTI se mantiene y mejora dentro del ciclo de mejora continua.
De este modo, transcurrido un año desde la certificación, se planifica la primera
auditoría de seguimiento (AS1) y, al año de ésta, se planifica la segunda auditoría
de seguimiento (AS2).
9. Auditoría de renovación
Una vez cumplidos los 3 años de validez, la certificación expira (caduca) y se debe
realizar una auditoría de renovación de la certificación (muy similar a la auditoría
de certificación fase II).
Tanto en las auditorías de seguimiento como en la de renovación, también se emite
un informe en el que quedan reflejadas las no conformidades o incumplimientos. El
proceso de respuesta a las no conformidades mediante el plan de acciones correctivas
(PAC) se repite, así como, el de evaluación y decisión.
11. La certificación de la gestión del servicio de TI conforme a ISO/IEC 20000
11.1. La primera certificación conforme a ISO/IEC 20000 747
Fuente: AENOR.
Por tanto, las evidencias son el medio por el que se demuestra al resto de la organi-
zación, a los clientes y a los auditores, el cumplimiento de los requisitos expresados
en la parte 1 de las normas ISO/IEC 20000. Las evidencias también demuestran
que se siguen los procesos y procedimientos que integran el sistema de gestión
de TI. El objetivo es poder mostrar de manera fehaciente la orientación al servicio del
proveedor de TI, así como, el alineamiento con el negocio.
La generación de evidencias no debe tener como fin “satisfacer al auditor”. No se
debe olvidar que la auditoría será mucho más fácil de superar si el sistema de ges-
tión está adecuadamente implantado y afianzado. Cuando las evidencias son pro-
porcionadas por el trabajo diario surgen de forma natural, así, nadie debería estar
pensando en temas como:
“…ahora toca preparar el informe de seguimiento del proceso porque me lo piden para
la auditoría”,
decir que sea un listado exhaustivo o excluyente, pero sí útil, y en algunos casos
suficiente para determinadas organizaciones.
Por tanto, esta relación no se puede considerar como obligatoria, simplemente pre-
tende ser una ayuda. Será el auditor, en cada caso, el que determine cuáles son las
evidencias más adecuadas para cada situación. Dado que las evidencias son el modo
por el que la organización muestra que tiene control sobre cada uno de los proce-
sos que integran el sistema de gestión, habrá que adaptar el número y el tipo de
evidencias que se van a recopilar a la realidad de cada organización y cómo éstas
se asocian a cada proceso.
A continuación se detallan, para cada uno de los procesos definidos en la Norma
ISO/IEC 20000-1 las evidencias asociadas.
Evidencias para “8.3. Gestión del problema”. Establece los soportes en los que
registrar problemas, además de la documentación asociada al mismo.
• BD de problemas. Recoge los problemas identificados, proporcionando
información del estado en que se encuentran.
• Documentación de la resolución asociada al problema. Accesible por las
líneas de soporte.
• Comunicación entre la gestión del incidente y del problema.
Normativa
• UNE-ISO/IEC 20000-1:2007 Tecnología de la información. Gestión del servicio.
Parte 1: Especificaciones.
• UNE-ISO/IEC 20000-2:2007 Tecnología de la información. Gestión del servicio.
Parte 2: Código de buenas prácticas.
• UNE-ISO/IEC 17021:2006 Evaluación de la conformidad. Requisitos para los
organismos que realizan la auditoría y la certificación de sistemas de gestión.
• UNE-ISO 10005:2005 Sistemas de gestión de la calidad. Directrices para los planes
de la calidad.
• UNE-ISO/IEC 17799:2002 Tecnología de la información. Código de buenas prác-
ticas para la Gestión de la Seguridad de la Información.
• UNE-ISO/IEC 27001:2007 Tecnología de la información. Técnicas de seguridad.
Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos.
• UNE 71044:1999 Tecnología de la información. Procesos del ciclo de vida del soft-
ware.
• UNE-EN ISO 9001:2008 Sistemas de gestión de la calidad. Requisitos.
• ISO/IEC 15288:2008 Systems and software engineering – System life cycle processes.
• ISO/IEC 15504-1:2004 Information technology – Process assessment – Part 1: Con-
cepts and vocabulary.
• ISO/IEC 15504-2:2003 Information technology – Process assessment – Part 2: Per-
forming an assessment.
• ISO/IEC 15504-3:2004 Information technology – Process assessment – Part 3:
Guidance on performing an assessment.
• ISO/IEC 15504-4:2004 Information technology – Process assessment – Part 4: Gui-
dance on use for process improvement and process capability determination.
• ISO/IEC 15504-5:2006 Information technology – Process Assessment – Part 5: An
exemplar Process Assessment Model.
766 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Activo (Asset): Componente de un servicio de TI. Los activos pueden incluir per-
sonas, alojamiento, sistemas de ordenadores, redes, registros manuales, fax, etc.
Acuerdo de nivel de servicio (SLA): Un acuerdo escrito entre el proveedor de
servicio y cliente, que documenta niveles de servicio acordados por un servicio.
Acuerdos de colaboración operacional (OLA): Un acuerdo interno que da
cobertura a los servicios que soporta la organización de TI en su prestación
de servicios al cliente.
Análisis del impacto (impact analysis): La identificación de procesos de negocio
críticos, y el daño potencial o la pérdida que se puede causar a la organización
como resultado de una interrupción a estos procesos.
Análisis del riesgo: La identificación y evaluación del nivel (medida) de los ries-
gos, calculado a partir del valor de los activos y de los niveles evaluados de ame-
nazas y vulnerabilidades a los que están expuestos dichos activos.
Autoridad de cambios (Change authority): Grupo al que se delega autoridad de
aprobación de los cambios, por ejemplo por un comité de proyectos. Algunas
veces también se le conoce como comité de configuración.
Base de datos de la gestión de la configuración (CMDB): Una base de datos
que contiene todos los detalles relevantes de cada CI y detalles de relaciones
importantes entre los CI.
Biblioteca de software: Una colección controlada de CI software designada para
mantener juntos esos que tienen estados o géneros similares y segregados de
esos que no se parecen, para ayudar en desarrollo, operación y mantenimiento.
Biblioteca de software definitivo (DSL): Repositorio en el que se almacenan y
protegen las versiones autorizadas definitivas de todos los CI software. Se trata
768 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
entrega delta contendrá sólo aquellos módulos que hayan sido modificados o
renovados desde la última entrega.
Error conocido (KE, Known Error): Aquel incidente, o aquel problema, cuya causa
raíz se conoce y para la que se ha identificado un arreglo provisional o una alterna-
tiva permanente. Ante un caso con impacto en el negocio se realizará una solicitud
de cambio (RFC), pero siempre seguirá considerándose como error conocido
hasta su solución permanente mediante el correspondiente cambio.
Estructura de la configuración (Configuration structure): Jerarquía de todos
los CI que conforman una configuración.
Externalización: El proceso mediante el cual las funciones realizadas por la orga-
nización son contratadas externamente para la operación por terceros en nom-
bre de la organización.
Función de negocio (Business function): Una unidad de negocio en la organiza-
ción, por ejemplo, un departamento, división, oficina, etc.
Gestión de la configuración (Configuration management): Proceso que se
ocupa de la identificación y definición de los CI de un sistema, registrando e
informando sobre el estado de los CI y las RFC (solicitudes de cambio), y veri-
ficando la exactitud y corrección de dichos CI.
Gestión de nivel de servicio (Service level management): El proceso encargado
de definir, acordar, documentar y gestionar los niveles de servicio al cliente,
según sus requerimientos y con unos costes justificados.
Gestión de servicios (Service management): Gestión de los servicios según los
requisitos del cliente.
Gestión del cambio (Change management): Proceso de control de los cambios
de cualquier aspecto de los servicios, o en la infraestructura, de un modo con-
trolado, permitiendo llevar a cabo los cambios aprobados con el mínimo
impacto en el servicio.
Gestión del coste (Cost management): Todos los procedimientos, tareas y entre-
gables necesarios para satisfacer el coste de una organización y los requerimien-
tos de precio.
Herramienta de gestión de la configuración (Configuration management tool):
Un producto software que proporciona asistencia automatizada para el control
de cambios, configuración y versiones.
Hoja de especificaciones (SS, SpecSheet): Especifica detalladamente lo que el
cliente quiere (externo) y que consecuencias tiene para el proveedor de servicio
(interno), como recursos requeridos y habilidades.
772 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
de una interrupción del negocio y de las posibles pérdidas que pueda ocasionar
dicha interrupción.
Rol (Role): Una serie de responsabilidades, actividades y autorizaciones.
Servicios (Services): Entregables de la organización de servicios informáticos que
son percibidos por los clientes; los servicios no consisten simplemente en hacer
disponibles los recursos de ordenadores para el uso de los clientes.
Sistema (System): Conjunto integrado de uno o más procesos, hardware, software,
utilidades y personal, que proporciona la capacidad de satisfacer una necesidad
o un alcanzar objetivo determinado.
Solicitud de cambio (RFC, Request For Change): Formulario o pantalla usada
para registrar los detalles de una solicitud para un cambio a cualquier CI dentro
de la infraestructura o para procedimientos y elementos asociados con la infraes-
tructura.
Solución temporal (Workaround): Método para evitar un incidente o un pro-
blema, bien mediante un arreglo provisional o mediante una técnica que impli-
que que el cliente no dependa de un aspecto específico del servicio del cual se
sepa que presenta un problema.
TIC (ICT) / TI (IT): La convergencia de Información Tecnológica, Comunica-
ciones y Datos.
Unidad de negocio: Una división de una entidad de negocio en la que los ingre-
sos son registrados y los gastos incurridos se controlan, de forma que los ingre-
sos y gastos se usan para evaluar el rendimiento de la división.
Urgencia (Urgency): Medida de la criticidad para el negocio de un incidente o
un problema, basada en su impacto sobre las necesidades de negocio de los
clientes.
Usuario (User): La persona que utiliza los servicios de manera habitual.
Usuario final (End-User): Véase “Usuario”.
Versión (Version): Elemento identificado de un CI, dentro de la estructura des-
glosada de un producto o en la estructura de configuración, que sirve de refe-
rencia para el seguimiento y auditoria del historial de cambios. También se uti-
liza en los SCI, definiéndose una referencia específica en el desarrollo para el
diseño, revisión, modificación, pruebas o producción.
Versión completa (Full release): Todos los componentes de la unidad de entrega
que se desarrollan, prueban, distribuyen e implementan a la vez. Véase también
“versión delta”.
Términos y definiciones 775
Versión delta (Delta release): Una versión delta o parcial, es aquélla que sola-
mente incluye los CI de la unidad de entrega que se hayan modificado o reno-
vado desde la última entrega completa o parcial (delta). Por ejemplo, si la uni-
dad de versión es el programa, una versión delta contendrá solo aquellos
módulos que hayan sido modificados o renovados desde la última entrega com-
pleta del programa o desde la última versión delta de determinados módulos.
Véase también “Versión completa”.