Una vez se hayan introducido los servicios con éxito en el

entorno real de trabajo es necesario realizar una gestión eficaz

de las operaciones diarias de los mismos. Es en este punto, en
la interfaz con el cliente, donde se generan las percepciones en
relación con su rendimiento como proveedor de servicio.

Este libro presenta y explica las actividades de entrega y control

que ofrecen soporte a una operación del servicio de alta calidad.
El uso de esta guía le ayudará a conseguir una metodología
Operación del Servicio
equilibrada y flexible, afianzando su posición para conseguir la
excelencia como proveedor de servicio.

La organización itSMF International, a través de su Subcomité

Ejecutivo de Publicaciones Internacionales (IPESC), integrado

Operación del Servicio

por miembros de todos los capítulos de itSMF en todo el mundo,
ha concedido la aprobación formal de itSMF International a
este libro.

ISBN 978-0-11-331150-7

www.tso.co.uk 9 780113 311507

5878 SO Spanish Cover V0_3.indd 1 7/1/10 15:48:36

5878 SO Spanish Cover V0_3.indd 2 7/1/10 15:48:38
Operación del Servicio

London: TSO
Publicado por TSO (The Stationery Office) y disponible en:
Online
www.tsoshop.co.uk

Dirección, Teléfono, Fax y Correo electrónico

TSO
PO Box 29, Norwich NR3 1GN
Teléfono para pedidos y consultas generales: 0870 6005522
Fax pedidos: 0870 600 5533
Correo electrónico: [email protected]
Teléfono de texto: 0870 240 3701

Tiendas de TSO
16 Arthur Street, Belfast BT1 4GD
028 9023 8451 Fax 028 9023 5401

TSO@Blackwell y otros Agentes Acreditados

Publicado para la Office of Government Commerce bajo licencia de la Controller of Her Majesty’s Stationery
Office.
© Crown Copyright 2009
Este es un producto con valor añadido de Crown copyright, su reutilización requiere una Click-Use Licence
para el material con valor añadido publicado por OPSI.
Las solicitudes para utilizar, reproducir o reeditar el material de esta publicación deben enviarse a OPSI,
Information Policy Team, Kew, Richmond, Surrey TW9 4DU, Correo electrónico: [email protected], o
rellene el formulario de solicitud en el sitio web de OPSI http://www.opsi.gov.uk/click-use/value-added-
licence-information/index.htm
OPSI, en colaboración con la Office of Government Commerce (OGC), puede preparar posteriormente una
Value Added Licence basada en los términos estándar adaptados a sus requisitos particulares, incluyendo
las condiciones de pago
El logo OGC ® es una Marca Comercial Registrada de la Office of Government Commerce
ITIL ® es una Marca Comercial Registrada, y una Registered Community Trade Mark de la Office of
Government Commerce, y está Registrada en la U.S. Patent and Trademark Office
El logo Swirl ™ es una Marca Comercial de la Office of Government Commerce
Primera publicación en 2009
ISBN  978  0  11  331150  7
Impreso en el Reino Unido para The Stationery Office
 | iii

Contenido
Lista de figuras v 4.3 Gestión de Peticiones 62
4.4 Gestión de Problemas 65
Lista de tablas vi
4.5 Gestión de Accesos 75
Prólogo de OGC vii 4.6 Actividades operativas de procesos
cubiertas por otras fases del ciclo de vida 80
Prólogo del Arquitecto Jefe viii
5 Actividades Comunes de Operación del
Prólogo ix Servicio 87
Agradecimientos x 5.1 Monitorización y control 90
1 Introducción 1 5.2 Operaciones de TI 100

1.1 Descripción general 3 5.3 Gestión del Mainframe 104

1.2 Contexto 3 5.4 Gestión y Soporte de Servidores 104

1.3 Propósito 7 5.5 Gestión de Red 105

1.4 Uso 7 5.6 Almacenamiento y Archivo 106

1.5 Descripción general de los capítulos 8 5.7 Administración de Bases de datos 107
5.8 Gestión de Servicios de Directorio 108
2 Gestión del Servicio como una práctica 9
5.9 Soporte al Puesto de Trabajo 108
2.1 ¿Qué es la Gestión del Servicio? 11
5.10 Gestión del Middleware 109
2.2 ¿Qué son los servicios? 11
5.11 Gestión de Internet / Web 109
2.3 Funciones y procesos a lo largo del ciclo
de vida 12 5.12 Gestión de Ias Instalaciones y del
Centro de Proceso de Datos 110
2.4 Aspectos fundamentales de la Operación
del Servicio 14 5.13 Gestión de la Seguridad de la Información
y Operación del Servicio 111
3 Principios de Operación del Servicio 19 5.14 Mejora de las actividades operativas 113
3.1 Funciones, grupos, equipos, departamentos
y divisiones 21 6 Organización de la Operación del
Servicio 115
3.2 Logro del equilibrio en la Operación
del Servicio 22 6.1 Funciones 117
3.3 Provisión del servicio 30 6.2 Centro de Servicio al Usuario 120
3.4 Implicación del personal de operación 6.3 Gestión Técnica 133
en Diseño del Servicio y en Transición
6.4 Gestión de Operaciones de TI 138
del Servicio 31
6.5 Gestión de Aplicaciones 141
3.5 Salud operativa 31
6.6 Roles y responsabilidades de Operación
3.6 Comunicación 32
del Servicio 154
3.7 Documentación 34
6.7 Estructuras de la Organización de
Operación del Servicio 161
4 Procesos de Operación del Servicio 37
4.1 Gestión de Eventos 40 7 Consideraciones sobre la tecnología 171
4.2 Gestión de Incidencias 51 7.1 Requisitos genéricos 173
iv |

7.2 Gestión de Eventos 174 B5 Comunicación asociada con los cambios 214
7.3 Gestión de Incidencias 175 B6 Comunicación asociada con las
excepciones 215
7.4 Gestión de peticiones 175
B7 Comunicación asociada con las
7.5 Gestión de Problemas 176
emergencias 216
7.6 Gestión de Accesos 176
B8 Comunicación con usuarios y clientes 217
7.7 Centro de Servicio al Usuario 176
Apéndice C: Kepner y Tregoe 219
8 Implementación de operación del
C1 Definición del problema 221
servicio 179
C2 Descripción del problema 221
8.1 Gestión del cambio en Operación
del Servicio 181 C3 Establecimiento de las causas posibles 221
8.2 Operación del servicio y Gestión C4 Prueba de la causa más probable 221
de Proyectos 181
C5 Verificación de la causa real 221
8.3 Evaluación y gestión del riesgo en
Operación del Servicio 182 Apéndice D: Diagramas de Ishikawa 223
8.4 Personal de operaciones en Diseño y Apéndice E: Descripción detallada de
Transición del Servicio 182
Gestión de las Instalaciones 227
8.5 Planificación e Implementación de las
E1 Gestión de Edificios 229
tecnologías de Gestión del Servicio 182
E2 Alojamiento de Equipos 229
9 Desafíos, Factores Críticos de Éxito y
E3 Gestión de la Energía 230
riesgos 187
E4 Acondicionamiento del Entorno y
9.1 Desafíos 189
Sistemas de Alerta 231
9.2 Factores Críticos de Éxito 191
E5 Seguridad 232
9.3 Riesgos 193
E6 Control de Acceso Físico 232
Epílogo 195 E7 Envío y Recepción 232
E8 Implicación en Gestión de Contratos 232
Apéndice A: Guía complementaria de la
industria 199 E9 Mantenimiento 233
A1 COBIT 201 Apéndice F: Control de Acceso Físico 235
A2 ISO/IEC 20000 201
Glosario 241
A3 CMMI 202
Lista de acrónimos 243
A4 Cuadro de Mando Integral 202
Lista de definiciones 245
A5 Gestión de la Calidad 202
A6 ITIL y el Marco de Trabajo OSI 202 Índice 275

Apéndice B: Comunicación en Operación

del Servicio 205
B1 Comunicación operativa rutinaria 207
B2 Comunicación entre turnos 208
B3 Informes de Rendimiento 209
B4 Comunicación en proyectos 212
 | v

Lista de figuras
Todos los diagramas que se incluyen en esta publicación Figura 5.4 El Bucle de Control de la Monitorización en
tienen la intención de proporcionar una ilustración y ITSM
guía de los conceptos de la Práctica de la Gestión del
Figura 6.1 Funciones de Operación del Servicio
Servicio de ITIL. Han sido elaborados artísticamente
para reforzar visualmente los conceptos clave y no Figura 6.2 Centro de Servicio al Usuario Local
están concebidos para cumplir con un método formal
o estándar de representación técnica. El Modelo de Figura 6.3 Centro de Servicio al Usuario Centralizado
Servicio Integrado de Prácticas de Gestión del Servicio Figura 6.4 Centro de Servicio al Usuario Virtual
de ITIL satisface los estándares de representación
técnica y debe consultarlo si desea obtener los detalles Figura 6.5 Ciclo de Vida de Gestión de Aplicaciones
completos. Vea www.best-management-practice.com/itil Figura 6.6 Rol de los equipos en el Ciclo de Vida de
para disponer de detalles. Gestión de Aplicaciones
Figura 1.1 Aprovisionamiento de Prácticas de Gestión Figura 6.7 Operaciones de TI organizadas de acuerdo
del Servicio con el ejemplo de especialización técnica
Figura 1.2 Núcleo de ITIL Figura 6.8 Un departamento basado en la ejecución
Figura 2.1 Una conversación sobre la definición y el de un conjunto de actividades
significado de los servicios Figura 6.9 Operaciones de TI organizadas de acuerdo
Figura 2.2 Un proceso básico con la geografía

Figura 3.1 Lograr un equilibrio entre el enfoque Figura 6.10 Estructura Centralizada de Gestión Técnica,
interno y externo de Aplicaciones y de Operaciones de TI

Figura 3.2 Lograr un equilibrio entre enfoque en la Figura D.1 Ejemplo de inicio de un Diagrama de
estabilidad y en la capacidad de respuesta Ishikawa

Figura 3.3 Equilibrio entre la calidad y el coste del Figura D.2 Ejemplo de un Diagrama de Ishikawa
servicio completado

Figura 3.4 Lograr un equilibrio entre el enfoque en los

costes y en la calidad
Figura 3.5 Lograr un equilibrio entre ser demasiado
reactivo o demasiado proactivo
Figura 4.1 El Proceso de Gestión de Eventos
Figura 4.2 Flujo del proceso de Gestión de Incidencias
Figura 4.3 Categorización de incidencias multinivel
Figura 4.4 Flujo del proceso de Gestión de Problemas
Figura 4.5 Comparación de causas importantes con
triviales
Figura 4.6 Sistema de Gestión del Conocimiento del
Servicio
Figura 5.1 Lograr madurez en la Gestión de
Tecnología
Figura 5.2 El Bucle de Control de la Monitorización
Figura 5.3 Bucle de Control de la Monitorización
Complejo
vi |

Lista de tablas
Tabla 3.1 Ejemplos de enfoque interno y externo
extremos
Tabla 3.2 Ejemplos de enfoque extremo en la
estabilidad y en la capacidad de respuesta
Tabla 3.3 Ejemplos de enfoque extremo sobre la
calidad y sobre el coste
Tabla 3.4 Ejemplos de comportamiento
extremadamente reactivo o proactivo
Tabla 4.1 Sistema simple de codificación de
prioridad
Tabla 4.2 Gráfico de clasificación de causas de
Pareto
Tabla 5.1 Monitorización Reactiva y Proactiva,
Activas y Pasivas
Tabla 6.1 Herramientas y técnicas de encuestas
Tabla 6.2 Roles organizativos
Tabla B.1 Requisitos de comunicación en servicios
de TI
Tabla B.2 Requisitos de comunicación entre turnos
Tabla B0.3 Requisitos de los Informes de
Rendimiento: servicio de TI
Tabla B0.4 Requisitos de los Informes de
Rendimiento: Equipo o departamento de
Operación del Servicio
Tabla B.5 Requisitos de los Informes de
Rendimiento: infraestructura o proceso
Tabla B.6 Comunicación dentro de proyectos
Tabla B.7 Comunicación en el traspaso de proyectos
Tabla B.8 Comunicación sobre los cambios
Tabla B.9 Comunicación durante las excepciones
Tabla B.10 Comunicación durante emergencias
Tabla B.11 Comunicación con usuarios y clientes
Tabla F.1 Dispositivos de control de accesos
 | vii

Prólogo de OGC
Desde su creación, ITIL ha crecido hasta convertirse
en el método para la Gestión del servicio de TI más
ampliamente aceptado en el mundo. Sin embargo, a
este éxito, va unida la responsabilidad de garantizar
que la guía siga estando actualizada en un entorno
de negocio global y cambiante. Los requisitos de la
gestión del servicio se ven configurados inevitablemente
por el desarrollo de la tecnología, por la revisión
de los modelos de negocio y por el aumento de las
expectativas de los clientes. Nuestra última versión
de ITIL ha sido elaborada como respuesta a estos
desarrollos.
Esta es una de las cinco publicaciones centrales que
describen las prácticas de gestión de los servicios de
TI que componen ITIL. Son el resultado de un proyecto
de dos años de revisión y actualización de la guía.
El número de profesionales de todo el mundo de la
gestión del servicio que han colaborado para desarrollar
el contenido de estas publicaciones es enorme. Su
experiencia y conocimiento han contribuido a la
generación del contenido para ofrecerle un conjunto
coherente de guías de alta calidad. Esto está respaldado
por el desarrollo continuo de un plan de acción integral
de cualificaciones, junto con consultoría y formación
acreditadas.
Ya forme parte de una empresa global, de un
departamento gubernamental o de un pequeño negocio,
ITIL le permitirá acceder a una experiencia profesional
de gestión del servicio de clase mundial. Básicamente,
coloca los servicios de TI en su lugar, en el corazón de
las operaciones de negocio de éxito.

Peter Fanning
Acting Chief Executive
Office of Government Commerce
viii |

Prólogo del Arquitecto Jefe

La guía de Prácticas de Gestión del Servicio de ITIL se
estructura en torno al Ciclo de Vida del Servicio. La
propia práctica general es común a todo el ciclo de vida,
y se basa en procesos, funciones, actividades, modelos
organizativos y medidas que en conjunto permiten a la
Gestión de los Servicios de TI (ITSM) integrarse con los
procesos de negocio, proporcionar valor medible y hacer
que la industria de ITSM avance en nuestra búsqueda de
la excelencia del servicio.
Ninguna otra parte del Ciclo de Vida del Servicio de ITIL
refleja tan íntimamente cómo nuestro desempeño como
proveedores de servicio afecta a los clientes como lo hace
la Operación del Servicio. Implica dónde se entregan y
apoyan diariamente la estrategia, el diseño, la transición y
las mejoras.
La publicación Operación del Servicio da vida a la Gestión
del Servicio para el negocio, y la responsabilidad del
rendimiento de los servicios, las personas que los crean
y la tecnología que les permitirá monitorizar, controlar y
entregar estos servicios en esta etapa del Ciclo de Vida
del Servicio.
Esta publicación nos servirá como guía para lograr la
excelencia del servicio y para ver el valor de ITSM de
una forma amplia y centrada en el negocio. Ya sea un
principiante en la práctica de ITIL o un practitioner
experimentado, la guía de esta publicación ampliará su
visión y conocimiento para convertirse en un proveedor
de servicios de primer nivel a través de la implementación
de la Operación del Servicio.
Hay un dicho que dice que después de que todo sale
bien, es fácil analizar el por qué. La guía que se incluye
en Operación del Servicio se extrae de más de 20 años de
experiencia de ITSM procedente de expertos, hombres de
negocio y practitioners de ITSM de todo el mundo, y de
las lecciones que aprendieron sobre qué es realmente la
excelencia del servicio y sobre cómo lograrla.
Cualquier implicado en servicios operativos se beneficiará
de la guía que se incluye en las siguientes páginas de
esta publicación. Operación del Servicio ofrece el mejor
asesoramiento y guía de todo el mundo, y un camino
para obtener lo que es posible en su futuro.

Sharon Taylor
Chief Architect, Prácticas de Gestión del Servicio de ITIL
 | ix

Prólogo
Esta publicación abarca y sustituye los aspectos
operativos de las publicaciones Soporte del Servicio y
Provisión del Servicio de ITIL y también cubre la mayor
parte del alcance de la Gestión de Infraestructuras
de TIC. También incorpora aspectos operativos de las
publicaciones Planificación para Implementar, Gestión de
Aplicaciones, Gestión de Activos de Software y Gestión
de la Seguridad.
Los principios básicos de las mejores prácticas de
la gestión del servicio de TI que se incluyen en las
versiones previas de ITIL permanecerán inalterables. ¡El
sentido común sigue siendo el sentido común!
Sin embargo, las tecnologías, las herramientas y las
relaciones han cambiado significativamente, incluso en
un plazo relativamente corto desde que se completara la
última versión de ITIL. Aunque esta publicación reutiliza
y actualiza material relevante de las versiones anteriores,
también incluye en un único volumen nuevos conceptos
y prácticas de la industria para proporcionar un ámbito
completo que sirva de guía sobre las mejores prácticas
actualizadas asociadas con la Operación del Servicio para
el negocio y el entorno tecnológico actuales.

Información de contacto
Puede encontrar todos los detalles de la gama
de materiales publicados por ITIL en www.best-
management-practice.com/itil
Para disponer de más información sobre las
cualificaciones y la acreditación de la formación, visite
www.itil-officialsite.com. De forma alternativa, puede
ponerse en contacto con:
APMG Service Desk
Sword House
Totteridge Road
High Wycombe
Buckinghamshire
HP13 6DG
Tel.: +44 (0) 1494 452450
Correo electrónico: [email protected]
x |

Agradecimientos
Arquitecto Jefe y autores Hughes de HP Global Delivery Application Services, Cindi
Sharon Taylor (Aspect Group Inc) Chief Architect Locker y Dhiraj Gupta de Progressive Casualty Insurance
Company, Peter Doherty y Robert Stroud de Computer
David Cannon (HP) Autor Associates y Paul Tillston de Hewlett-Packard, Brian
Jakubec, Vernon Blakes, Angela Chin, Colin Lovell, Ken
David Wheeldon (HP) Autor
Hamilton, Rose Lariviere, Jenny McPhee, Tom Nielsen,
Roc Paez, Lloyd Robinson, Paul Wilmot, Jeanette Smith y
Equipo de redacción de ITIL Ken Wendle de Hewlett-Packard.
El equipo de redacción de ITIL contribuyó a crear
Durante el desarrollo de las Prácticas de Gestión
esta guía a través de comentarios sobre el contenido
del Servicio de ITIL, para qué éstas reflejen la mejor
y la alineación del conjunto. Extendemos nuestro
práctica actual y elaborar publicaciones con un valor
agradecimiento a otros autores de ITIL, específicamente
perdurable, OGC consultó ampliamente a diferentes
a Jeroen Bronkhorst (HP), Gary Case (Pink Elephant),
grupos interesados de todo el mundo en cada
Ashley Hannah (HP), Majid Iqbal (Carnegie Mellon
etapa del proceso. OGC también desearía expresar
University), Shirley Lacy (ConnectSphere), Vernon Lloyd
su agradecimiento a las siguientes personas y a sus
(Fox IT), Ivor Macfarlane (Guillemot Rock), Michael Nieves
organizaciones por sus contribuciones para la renovación
(Accenture), Stuart Rance (HP), Colin Rudd (ITEMS) y
de la guía de ITIL:
George Spalding (Pink Elephant).

El Grupo Asesor de ITIL

Tutores
Pippa Bass, OGC; Tony Betts, Independiente; Signe-Marie
Christian Nissen y Paul Wilkinson.
Hernes Bjerke, Det Norske Veritas; Alison Cartlidge, Xansa;
Diane Colbeck, DIYmonde Solutions Inc; Ivor Evans,
Contribuciones adicionales DIYmonde Solutions Inc; Karen Ferris, ProActive; Malcolm
Muchas personas dedicaron generosamente su tiempo Fry, FRY-Consultants; John Gibert, Independiente;
y experiencia a esta publicación de la Operación del Colin Hamilton, RENARD Consulting Ltd; Lex Hendriks,
Servicio. Jim Clinch, como Jefe de Proyecto de OGC, EXIN; Carol Hulm, British Computer Society-ISEB; Tony
agradece el soporte proporcionado por HP al equipo Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance,
de redacción en el desarrollo de esta publicación, y ITPreneurs; Christian Nissen, Itilligence; Don Page, Marval
particularmente la contribución de Peter Doherty y Group; Bill Powell, IBM; Sergio Rubinato Filho, CA; James
Robert Stroud, y por el soporte de Jenny Dugmore, Siminoski, SOScorp; Robert E. Stroud, CA; Jan van Bon,
Convenor of Working Group ISO/IEC 20000, Janine Eves, Inform-IT; Ken Wendle, HP; Paul Wilkinson, Getronics
Carol Hulm, Aidan Lawes y Michiel van der Voort. PinkRoccade; Takashi Yagi, Hitachi.
Los autores también deserarían agradecer a Stuart
Rance y Ashley Hanna de Hewlett-Packard, Christian Revisores
F Nissen (Itilligence), Maria Vase (Itilligence), Eu Jin Jorge Acevedo, Computec S.A; Valerie Arraj, InteQ; Colin
Ho (UBS), Jan Bjerregaard, (Sun Microsystems), Jan Ashcroft, City of London; Martijn Bakker, Getronics
Øberg (ØBERG Partners), Lars Zobbe Mortensen (Zobbe PinkRoccade; Jeff Bartrop, BT & Customer Service Direct;
Consult & Zoftware), Mette Nielsen (Carlsberg IT), John Bennett, Centram Ltd; Niels Berner, Novo Nordisk;
Michael Imhoff (IBM), Niels Berner (Novo Nordisk), Nina Ian Bevan, Fox IT; Signe-Marie Hernes Bjerke, DNV; Jan
Schertiger (HP), Signe-Marie Hernes Bjerke (DNV), Steen Bjerregaard, Sun Microsystems; Enrico Boverino, CA;
Sverker Nilsson (Westergaard CSM), Ulf Myrberg (BiTa), Stephen Bull, Sierra Systems; Bradley Busch, InTotality;
Russell Jukes, Debbi Jancaitis, Sheldon Parmer, Ramon Howard Carpenter, IBM; Diane Colbeck, DIYmonde
Alanis, Tim Benson y Nenen Ong de Hewlett-Packard Solutions Inc; Nicole Conboy, Nicole Conboy &
IT, Jaye Thompson, Dee Seymour, Andranik Ziyalyan, Associates; Sharon Dale, aQuip International; Sandra
Young Chang, Lauren Abernethy, April McCowan, Becky Daly, Dawling Consultancy; Michael Donahue, IBM;
Wershbale, Rob Garman, Scott McPherson, Sandra Paul Donald, Lucid IT; Juan Antonio Fernandez, Quint
Breading, Rick Streeter, Leon Gantt, Charlotte Devine, Wellington Redrood; Juan Jose Figueiras, Globant;
Greg Algorri, Mary Fischer, Bill Thayer y Diana Osberg Rae Garrett, Pink Elephant; Klaus Goedel, HP; Detlef
de The Walt Disney Company’s Enterprise IT, Dennis Gross, Automation Consulting Group GmbH; Matthias
Deane y John Sowerby de DHL, Richard Fahey y Chris Hall, University of Dundee; Lex Hendriks, EXIN; Jabe
 | xi

Hickey, IBM; Kevin Hite, Microsoft; Eu Jin Ho, UBS;

Michael Imhoff, IBM; Scott Jaegar, Plexant; Tony Jenkins,
DOMAINetc; Tony Kelman-Smith, HP; Peter Koepp,
Independiente; Joanne Kopcho, Capgemini America;
Debbie Langenfield, IBM; Sarah Lascelles, Interserve
Project Services Ltd; Peter Loos, Accenture Services
GmbH; Emmanuel Marchand, Advens; Jesus Martin,
Ibermatica SA; Phil Montanaro, EDS; Luis Moran,
Independiente; Lars Zobbe Mortensen, Zobbe Consult &
Zoftware; Ron Morton, HP; Darren Murtagh, Retravision;
Ulf Myrberg, BiTa; Mette Nielsen, Carlsberg IT; Steen
Sverker Nilsson, Westergaard CSM; Jan Øberg, ØBERG
Partners; Eddy Peters, CTG; Poul Mols Poulsen, Coop
Norden IT; Bill D Powell, IBM; Roger Purdie, The Art
of Service; Padmini Ramamurthy, Satyam Computer
Services Ltd; Frances Scarff, OGC; Nina Schertiger, HP;
Markus Schiemer, Unisys; Barbara Schiesser, Swiss ICT;
Klaus Seidel, Microsoft; Gilbert Silva, Techbiz Informatica
Ltd; Joseph Stephen, Department of Transportation,
US Government; Michala Sterling, Mid Sussex District
Council; Rohan Thuraisingham, Friends Provident
Management Services Ltd; Matthew Tolman, Sandvik; Jan
van Bon, Inform-IT; Maria Vase, ITILLIGENCE; Christoph
Wettstein, CLAVIS klw AG; Andi Wijaya, IBM; Aaron Wolfe,
Pink Elephant; Takashi Yagi, Hitachi; YoungHoon Youn,
IBM.

Equipo de Traducción al Español

La traducción de esta versión en español fue organizada
por el Comité de Publicaciones de itSMF España y su
coordinador Marlon Molina, con el apoyo de Oscar
Corbelli como jefe del proyecto. Esta versión ha sido
traducida por la empresa Translatorcom y revisada por
un equipo de expertos en ITIL quienes han dedicado
una gran cantidad de su tiempo a este proyecto, y a
quienes itSMF España desea expresar su gratitud:
Vanessa Jiménez Torres (TCPSI)
Maria Dolores Montero del Castillo (Telefónica)
Gonzalo Ibáñez Cardenoso (Telefónica)
José García (SOITSA)
José Luis Benito
Oscar Corbelli (Tecnofor) (Coordinador del proyecto)
Marlon Molina (Tecnofor) (Coordinador Publicaciones)
Introducción 1
 | 3

1 Introducción
Esta publicación provee asesoramiento sobre la mejor El personal de Operación del Servicio tiene que disponer
práctica y una guía sobre todos los aspectos de la gestión de procesos y herramientas de soporte que les permitan
de la operación diaria de los servicios de tecnologías de tener una visión general de la Operación del Servicio
la información (TI) de una organización. Cubre los temas y de la entrega (en lugar de sólo los componentes
asociados con las personas, procesos, infraestructura independientes, como por ejemplo el hardware, las
tecnológica y relaciones necesarios para garantizar la aplicaciones de software y las redes, que integran el
provisión de alta calidad y rentable de servicios de TI que servicio extremo a extremo desde una perspectiva de
satisfagan las necesidades del negocio. negocio) y detectar cualquier amenaza o fallo en la
calidad del servicio.
La llegada de nuevas tecnologías y la confusión creciente
en las líneas que unen a los silos tradicionales de tecnología Como los servicios pueden ser provistos, total o
para la gestión de aplicaciones de hardware, redes, telefonía parcialmente, por una o más organizaciones de
y software, implica la necesidad de un método actualizado suministradores/socios, la visión del servicio extremo a
para gestionar operaciones del servicio. Cada vez es más extremo de Operación del Servicio debe ampliarse para
probable que las organizaciones consideren diferentes formas abarcar aspectos externos de la provisión del servicio;
de provisión de su TI con una flexibilidad y coste óptimos, y dónde se necesitan herramientas y procesos de
con la introducción de TI de servicio público, servicios de TI interfaz o compartidos para gestionar flujos de trabajo
de pago por uso, provisión de TI virtual, capacidad dinámica interorganizativos.
e informática Empresarial Adaptativa, además de opciones de Operación del Servicio no es una unidad organizativa
externalización y contratación de tareas. ni un proceso único, sino que incluye varias funciones,
Estas alternativas han creado una gran cantidad de relaciones procesos y actividades que se describen en los Capítulos
de negocio de TI, tanto interna como externamente, que 4, 5 y 6.
han aumentado su complejidad en proporción directa con
la complejidad de las tecnologías que se están gestionando. 1.2  Contexto
Cada día que pasa, la dependencia del negocio con
respecto a estas complejas relaciones es más crítica para la 1.2.1 Gestión del Servicio
supervivencia y para el éxito. TI es un término de uso común cuyo significado cambia
según el contexto. Desde la primera perspectiva,
1.1  Descripción general los sistemas, aplicaciones e infraestructura de TI son
componentes o subconjuntos de un producto mayor.
Operación del Servicio es la fase del Ciclo de Vida de Habilitan, o se encuentran integrados en, procesos
ITSM que es responsable de las actividades habituales del y servicios. Desde la segunda perspectiva, TI es una
negocio. organización con su propio conjunto de capacidades y
Operación del Servicio es considerada como la ‘fábrica’ recursos. Las organizaciones de TI pueden ser de varios
de TI. Esto implica un enfoque más cercano respecto a tipos como, por ejemplo, funciones de negocio, unidades
las actividades diarias y a la infraestructura que se utilizan de servicios compartidos y unidades centrales en el ámbito
para entregar servicios. Sin embargo, esta publicación de empresa.
se basa en la noción de que el propósito de Operación
Desde la tercera perspectiva, TI es una categoría de
del Servicio es entregar y apoyar servicios. La gestión de
servicios que utiliza el negocio. Habitualmente se trata de
la infraestructura y de las actividades operativas siempre
aplicaciones e infraestructuras de TI que organizaciones de
debe apoyar este propósito.
TI internas o proveedores externos de servicios empaquetan
Los procesos bien implementados y planificados no y ofrecen como servicios. Los costes de TI se tratan como
serán útiles si la operación diaria de esos procesos no gastos de negocio. Desde la cuarta perspectiva, TI es una
se dirige, controla y gestiona adecuadamente. Tampoco categoría de activos empresariales que proporcionan un
será posible realizar mejoras del servicio si no se realizan caudal de beneficios para sus propietarios, incluyendo, sin
sistemáticamente las actividades diarias de monitorización excluir otros, ingresos, ganancias y beneficios. Los costes de
del rendimiento, las métricas de evaluación y la TI se tratan como inversiones.
recopilación de datos durante la Operación del Servicio.
4 | Introducción

Estándares Empleados

Prácticas de la industria Clientes

Fuentes Facilitadores
Investigación académica Proveedores
(Generar) (Agregar)
Formación y educación
Experiencia interna Asesores

Tecnologías

Sustitutos Competencia

Impulsores Reguladores Conformidad Escenarios

(Filtrar) (Filtrar)

Clientes Compromisos

Ajuste del conocimiento a los objetivos,

contexto y propósito del negocio

Figura 1.1 Aprovisionamiento de Prácticas de Gestión del Servicio

1.2.2  Buena práctica en el dominio público públicos, estándares y el conocimiento propietario de las
Las organizaciones operan en entornos dinámicos con la organizaciones y los individuos (vea la Figura 1.1).
necesidad de aprender y adaptarse. Existe una necesidad Los estándares y marcos de trabajo públicos resultan
de mejorar el rendimiento mientras se gestionan los pros atractivos cuando se comparan con el conocimiento
y contras. Sometidos a una presión similar, los clientes propietario:
buscan aprovechar las ventajas de los proveedores de
■ El conocimiento propietario se integra profundamente
servicio. Persiguen estrategias de aprovisionamiento del
en las organizaciones y por lo tanto es difícil de
servicio que se adapten mejor a sus propios intereses de
adoptar, reproducir, o transferir incluso con la
negocio. En muchos países, las agencias gubernamentales
cooperación de los propietarios. Tal conocimiento
y las organizaciones sin ánimo de lucro tienen una
normalmente se encuentra en forma de conocimiento
propensión similar a la externalización en la búsqueda
tácito que es inextricable y está deficientemente
de la eficacia operativa. Esto ejerce una presión adicional
documentado.
sobre los proveedores de servicio para mantener una
■ El conocimiento propietario está adaptado al contexto
ventaja competitiva con respecto a las alternativas que
puedan tener los clientes. El aumento de la externalización local y a las necesidades de negocio específicas,
ha expuesto particularmente a los proveedores internos de hasta el punto de ser completamente característico.
servicio a una competencia inusual. A menos que los receptores de tal conocimiento
tengan circunstancias coincidentes, puede que el
Para hacer frente a la presión, las propias organizaciones conocimiento no resulte tan eficaz al aplicarlo.
se comparan con sus homólogos y buscan cerrar los ■ Los propietarios de este conocimiento esperan verse
gaps en sus capacidades. Una forma de cerrar tales gaps recompensados por sus inversiones a largo plazo.
es la adopción de buenas prácticas de uso generalizado Podrían poner a disposición tal conocimiento sólo
en la industria. Existen muchas fuentes de buenas bajo términos comerciales, a través de compras y de
prácticas entre las que se incluyen marcos de trabajo contratos de licencia.
 Introducción | 5

■ Los marcos de trabajo y normas disponibles del Servicio. ITIL se aplica en organizaciones de todo
públicamente, como por ejemplo ITIL, Control el mundo para establecer y mejorar las capacidades en
Objetives for IT (COBIT), CMMI, eSCM-SP, PRINCE2, la Gestión del Servicio. ISO/IEC 20000 proporciona un
ISO 9000, ISO 20000 e ISO 27001, se validan a través estándar formal y universal para las organizaciones que
de un conjunto diverso de entornos y situaciones, deseen auditar y certificar sus capacidades de Gestión
más que por la experiencia limitada de una única del Servicio. Mientras que ISO/IEC 20000 es un estándar
organización. Están sujetos a una amplia revisión a cumplir y mantener, ITIL ofrece una estructura de
a través de múltiples organizaciones y disciplinas. conocimiento útil para cumplir el estándar.
Se examinan minuciosamente a través de diversos
La Biblioteca ITIL incluye los siguientes componentes:
conjuntos de socios, proveedores y competidores.
■ Es más probable que el conocimiento de los marcos ■ Núcleo de ITIL: guía de las mejores prácticas
de trabajo públicos se distribuya ampliamente entre aplicables a todos los tipos de organizaciones que
una gran comunidad de profesionales a través de una proporcionan servicios para un negocio
certificación y una formación disponible públicamente. ■ Guía complementaria de ITIL: un conjunto
Las organizaciones pueden adquirir tal conocimiento complementario de publicaciones con una guía
con mayor facilidad a través del mercado laboral. específica para sectores industriales, tipos de
organizaciones, modelos operativos y arquitecturas
Ignorar los estándares y marcos de trabajo públicos
tecnológicas.
puede situar innecesariamente a una organización en
desventaja. Las organizaciones deben cultivar su propio El Núcleo de ITIL se compone de cinco publicaciones
conocimiento propietario sobre la base de una estructura (vea la Figura 1.2). Cada una de ellas proporciona la guía
de conocimiento que se derive de estándares y marcos necesaria para un método integrado, tal y como requiere
de trabajo públicos. La colaboración y coordinación la especificación del estándar ISO/IEC 20000:
entre organizaciones se simplifica si se fundamentan en ■ Estrategia del Servicio
estándares y prácticas compartidas.
■ Diseño del Servicio
■ Transición del Servicio
1.2.3 ITIL y buena práctica en la Gestión del
■ Operación del Servicio
Servicio
■ Mejora Continua del Servicio.
El contexto de esta publicación es el Marco de Trabajo de
ITIL como una fuente de buenas prácticas en la Gestión

Mejora
Continua
del Servicio
Transición
del Servicio

Estrategia
del Servicio

Diseño
del Servicio Operación
del Servicio

Figura 1.2 Núcleo de ITIL

6 | Introducción

Cada publicación se centra en las capacidades que la eficacia operativa, sino para conseguir un rendimiento
representan un impacto directo en el rendimiento de diferenciador. Las decisiones que se toman con respecto
un proveedor de servicio. La estructura del núcleo se a la Estrategia del Servicio tienen consecuencias de
representa en la forma de un ciclo de vida. Es iterativa gran repercusión, incluyendo algunas cuyos efectos son
y multidimensional. Garantiza que las organizaciones se retardados.
configuren para aprovechar las capacidades en un área
Las organizaciones que ya ponen en práctica ITIL utilizan
para obtener aprendizaje y mejoras en otras. Se espera
este volumen como guía para realizar una revisión
que el Núcleo de ITIL proporcione estructura, estabilidad
estratégica de sus capacidades de Gestión del Servicio
y fortaleza a las capacidades de Gestión del Servicio
basadas en ITIL y mejorar el alineamiento entre esas
con principios, métodos y herramientas duraderas. Esto
capacidades y sus estrategias de negocio. Este volumen
sirve para proteger las inversiones y proporcionar el
de ITIL anima a los lectores a detenerse a reflexionar por
fundamento necesario para medir, aprender y mejorar.
qué se tiene que realizar algo antes de pensar en cómo
La guía en ITIL se puede adaptar a los cambios de uso en realizarlo. Las respuestas al primer tipo de preguntas se
diversos entornos de negocio y estrategias organizativas. centran más en el negocio del cliente. La Estrategia del
La Guía Complementaria de ITIL proporciona flexibilidad Servicio amplía el ámbito del Marco de Trabajo de ITIL
para implementar el Núcleo en un rango diverso de más allá de la audiencia tradicional de los profesionales de
entornos. Los profesionales pueden seleccionar la Guía ITSM.
Complementaria en función de sus necesidades para
impulsar el Núcleo en un contexto de negocio dado, de 1.2.3.2  Diseño del Servicio
igual forma que se seleccionan los neumáticos según El volumen Diseño del Servicio proporciona una guía para
el tipo de automóvil, el propósito y las condiciones el diseño y desarrollo de servicios y procesos de gestión
de la carretera. Esto permite ampliar la duración y la del servicio. Recoge los principios y métodos de diseño
portabilidad de los activos del conocimiento y proteger las que permiten transformar los objetivos estratégicos en
inversiones en las capacidades de Gestión del Servicio. portfolios de servicios y activos del servicio. El ámbito
del Diseño del servicio no se limita a nuevos servicios.
1.2.3.1  Estrategia del Servicio Incluye los cambios y mejoras necesarios para aumentar
El volumen de la Estrategia del Servicio proporciona la o mantener el valor que se proporciona a los clientes
guía para diseñar, desarrollar e implementar la Gestión del durante el ciclo de vida de los servicios, la continuidad
Servicio, no sólo como una capacidad organizativa, sino de los servicios, el logro de niveles de servicio y la
también como un activo estratégico. Se proporciona una conformidad con los estándares y regulaciones. Sirve de
orientación sobre los principios que sustentan la práctica guía a las organizaciones para el desarrollo de capacidades
de la Gestión del Servicio y que resultan útiles para el de diseño para la Gestión del Servicio.
desarrollo de las políticas, guías y procesos de Gestión
del Servicio durante todo el Ciclo de Vida del Servicio 1.2.3.3  Transición del Servicio
de ITIL. La guía de la Estrategia del Servicio resulta útil El volumen Transición del Servicio proporciona una guía
en el contexto del Diseño del Servicio, Transición del para el desarrollo y mejora de capacidades que permitan
Servicio, Operación del Servicio y de la Mejora Continua transformar servicios nuevos y modificados en operaciones.
del Servicio. Los temas recogidos en Estrategia del Esta publicación proporciona una guía sobre cómo los
Servicio incluyen el desarrollo de mercados, internos y requisitos de la Estrategia del Servicio que se codifican en
externos, activos del servicio, catálogo de servicios y la el Diseño del servicio se materializan de forma eficaz en la
implementación de la estrategia a través del Ciclo de Vida Operación del Servicio mientras se controlan los riesgos de
del Servicio. La Gestión Financiera, la Gestión de la Cartera fallo y discontinuidad. La publicación combina prácticas
de Servicios, el Desarrollo Organizativo y los Riesgos incluidas en Gestión de la Entrega, Gestión del Programa
Estratégicos son algunos de los temas principales. y Gestión del Riesgo, y las sitúa en el contexto práctico
Las organizaciones utilizan la guía para establecer los de la Gestión del Servicio. Proporciona una guía sobre la
objetivos y expectativas de rendimiento para servir a gestión de la complejidad relacionada con los cambios en
los clientes y a los mercados, e identificar, seleccionar los servicios y en los procesos de Gestión del Servicio, lo
y priorizar oportunidades. La Estrategia del Servicio que evita consecuencias indeseadas mientras se innova.
trata de garantizar que las organizaciones estén en Se proporciona la guía para transferir el control de los
posición de manejar los costes y riesgos asociados a sus servicios entre clientes y proveedores de servicio.
portfolios de servicios, y se preparen no sólo para lograr
 Introduction | 7

1.2.3.4  Operación del Servicio disponer de la guía de las mejores prácticas en estas
El volumen contiene prácticas sobre la gestión de la importantes etapas.
Operación del Servicio. Incluye una guía para lograr Operación del Servicio es extremadamente importante ya
eficacia y eficiencia en la entrega y el soporte de servicios que los eventos que pueden impactar negativamente en
que garanticen el valor para el cliente y el proveedor la calidad del servicio ocurren en el día a día operativo. La
de servicio. Los objetivos estratégicos se materializan en forma en la que se opera la infraestructura de TI de una
última instancia a través de la Operación del Servicio, organización y sus procesos de ITSM de soporte tendrá
por lo que se convierte en una capacidad crítica. Se el impacto más directo e inmediato sobre la calidad del
proporciona una orientación para saber cómo mantener servicio.
la estabilidad de la Operación del Servicio, permitiendo
cambios en el diseño, escala, ámbito y niveles de servicio.
Las organizaciones obtienen directrices, métodos y 1.3  Propósito
herramientas detalladas del proceso para su uso en dos Operación del Servicio es una fase crítica para el ciclo
perspectivas de control principales: reactiva y proactiva. de vida de ITSM. Los procesos bien implementados y
Los gestores y profesionales reciben el conocimiento que planificados no serán útiles si la operación diaria de esos
les permita tomar las mejores decisiones en áreas como procesos no se dirige, controla y gestiona adecuadamente.
la gestión de la disponibilidad de los servicios, el control Tampoco será posible realizar mejoras del servicio si no
de la demanda, la optimización del uso de la capacidad, se realizan sistemáticamente las actividades diarias de
la programación de las operaciones y la solución de los monitorización del rendimiento, las métricas de evaluación
problemas. Se proporciona una guía sobre las operaciones y la recopilación de datos durante la Operación del
de soporte a través de nuevos modelos y arquitecturas, Servicio.
como por ejemplo servicios compartidos, cálculo de
El personal de Operación del Servicio tiene que disponer
funcionalidades, utility computing (informática bajo
de procesos y herramientas de soporte que les permitan
demanda) y comercio móvil.
tener una visión general de la Operación del Servicio
y de la entrega (en lugar de sólo los componentes
1.2.3.5  Mejora Continua del Servicio
independientes, como por ejemplo el hardware, las
Este volumen proporciona una guía instrumental sobre aplicaciones de software y las redes, que integran el
la creación y mantenimiento del valor que se ofrece a los servicio extremo a extremo desde una perspectiva de
clientes a través de la mejora del diseño, introducción y negocio) y detectar cualquier amenaza o fallo en la
operación de los servicios. Combina principios, prácticas calidad del servicio.
y métodos a partir de la Gestión de la Calidad, Gestión
de Cambios y Mejora de la Capacidad. Las organizaciones Como los servicios pueden ser provistos, total o
aprenden a realizar mejoras graduales y a gran escala parcialmente, por una o más organizaciones de
en la calidad del servicio, la eficiencia operativa y la suministradores/socios, la visión del servicio extremo a
continuidad del negocio. Se proporciona la orientación extremo de Operación del Servicio debe ampliarse para
para vincular los esfuerzos de mejora y los resultados con abarcar aspectos externos de la provisión del servicio; y
la Estrategia, Diseño y Transición del Servicio. Se establece dónde se necesitan herramientas y procesos de interfaz
un sistema de retroalimentación de bucle cerrado, basado o compartidos para gestionar flujos de trabajo inter-
en el modelo Planificar-Hacer-Verificar-Actuar (PDCA) que organizativos.
se especifica en la ISO/IEC 20000, y que permite recibir
entradas de cambio desde cualquier perspectiva de 1.4  Uso
planificación.
Esta publicación debe usarse junto con las otras cuatro
La gestión operativa diaria de los Servicios de TI se ve publicaciones que componen el Ciclo de Vida del Servicio
influenciada significativamente por cómo de bien se ha de ITIL.
definido la estrategia general del servicio de TI de una
Los lectores deben ser conscientes de que las directrices
organización y por cómo de bien se han planificado e
de las mejores prácticas y otros volúmenes no tienen
implementado los procesos de ITSM. Esta es la cuarta
la intención de tener el valor de una norma. Cada
publicación en la serie de Prácticas de Gestión del
organización es única y debe ‘adaptar y adoptar’ la
Servicio de ITIL, y antes de Operación del Servicio deberán
directriz a sus propias necesidades, entorno y cultura
consultarse las demás publicaciones de Estrategia del
específicos. Esto implicará tener en cuenta el tamaño,
Servicio, Diseño del Servicio y Transición del Servicio para
aptitudes/recursos, cultura, financiación, prioridades
8 | Introducción

y madurez de ITSM existentes en la organización, y El Capítulo 6 recoge todos los aspectos organizativos de
modificar la directriz de la forma más apropiada para la Operación del Servicio, es decir, los individuos o grupos
adecuarla a las necesidades de la organización. que realizan procesos o actividades de Operación del
Servicio, e incluye alguna directriz sobre las estructuras
Para las organizaciones que se enfrentan a ITIL por
organizativas de la Operación del Servicio.
primera vez, disponer de alguna forma de evaluación
para comparar los procesos y prácticas actuales de El Capítulo 7 describe las herramientas y la tecnología que
la organización con aquellos recomendados por ITIL se utilizan durante la Operación del Servicio.
representaría un punto de inicio muy valioso: Estas
El Capítulo 8 recoge algunos aspectos sobre la
evaluaciones se describen con más detalle en la
implementación que será necesario considerar antes de
publicación Mejora Continua del Servicio de ITIL.
la fase operativa en la que el ciclo de vida pasa a estar
Cuando existan gaps importantes, podría ser necesario activo.
abordar estos gaps en etapas durante un periodo de
El Capítulo 9 resalta los desafíos, Factores Críticos del Éxito
tiempo para cumplir las prioridades de negocio de
y los riesgos a los que hay que enfrentarse durante la
la organización y mantener el ritmo de lo que una
Operación del Servicio, mientras que el Epílogo resume y
organización es capaz de absorber y costear.
finaliza la publicación.
ITIL no proporciona por sí sola la directriz para los
1.5  Descripción general de los   Directores de TI, y los apéndices presentan algunos
capítulos de los marcos de trabajo, metodologías y métodos
El Capítulo 2 introduce el concepto de Gestión del Servicio complementarios clave que se utilizan comúnmente junto
como una práctica. Aquí, Gestión del Servicio se posiciona con ITIL durante la Operación del Servicio.
como un componente estratégico y profesional para
cualquier organización. Este capítulo también ofrece una
descripción general de la Operación del Servicio como un
componente crítico de la Práctica de Gestión del Servicio.
Los principios clave de la Operación del Servicio se
incluyen en el Capítulo 3 de esta publicación. Estos
principios describen algunos de los conceptos y principios
básicos sobre los que se basa el resto de la publicación.
El Capítulo 4 incluye los procesos realizados dentro de
la Operación del Servicio. La mayoría de los procesos de
Operación del Servicio son reactivos debido a la naturaleza
del trabajo que se realiza para mantener los servicios
de TI en un estado estable y robusto. Este capítulo
también incluye procesos proactivos para enfatizar que
el objetivo de Operación del Servicio es la estabilidad y
no el estancamiento. Operación del Servicio debe buscar
constantemente las formas mejores y más rentables de
hacer cosas, y los procesos proactivos desempeñan aquí
un rol importante.
El Capítulo 5 recoge varias actividades comunes de
Operación del Servicio que componen grupos de
actividades y procedimientos que realizan las Funciones
de Operación del Servicio. Estas actividades especializadas,
y con frecuencia técnicas, no son procesos en el sentido
real de la palabra, sino que todas ellas son vitales para
la capacidad de entregar servicios de TI de calidad a un
coste óptimo.
Gestión del Servicio
como una práctica 2
 | 11

2 Gestión del Servicio como una practica

2.1  ¿Qué es la Gestión del Servicio? consumidores de servicios: pocos intermediarios, o
ninguno, entre el cliente, el front-office y el back-office.
La Gestión del Servicio es un conjunto de capacidades
■ La naturaleza perecedera de la salida del servicio y
organizativas especializadas empleadas para proporcionar
de la capacidad del servicio: se genera valor para el
valor a los Clientes en forma de Servicios. Las capacidades
cliente al garantizar el suministro continuo de calidad
adoptan la forma de funciones y procesos para gestionar
consistente. Los proveedores necesitan garantizar un
servicios durante un ciclo de vida, con especializaciones en
suministro estable de la demanda de los clientes.
estrategia, diseño, transición, operación y mejora continua.
Las capacidades representan la capacidad, competencia y Sin embargo, la Gestión del Servicio es algo más que
confianza para la acción de una organización del servicio. un conjunto de capacidades. También es una práctica
El acto de transformación de recursos en servicios de profesional que se apoya en una amplia estructura de
valor se encuentra en el centro de la Gestión del Servicio. conocimiento, experiencia y habilidades. Una comunidad
Sin estas capacidades, una organización del servicio es global de individuos y organizaciones en el sector público
simplemente un conjunto de recursos que, por sí mismos, y privado impulsa su crecimiento y madurez. Existen
tienen un valor intrínseco relativamente bajo para los esquemas formales para la educación, formación y
clientes. certificación de organizaciones que la ponen en práctica, y
para los individuos que influyen en su calidad. Las mejores
Definición de la Gestión del Servicio prácticas de la industria, la investigación académica y los
La Gestión del Servicio es un conjunto de capacidades estándares formales contribuyen a su capital intelectual y
organizativas especializadas empleadas para se basan en él.
proporcionar valor a los Clientes en forma de Servicios. Los orígenes de la Gestión del Servicio se encuentran
en servicios tradicionales como los de las líneas aéreas,
Las capacidades organizativas se modelan mediante bancos, hoteles y empresas de telefonía. Su práctica
los desafíos que se espera superar. Un ejemplo de ha crecido con la adopción de un método orientado
esto es cómo en la década de los 50 Toyota desarrolló al servicio en las organizaciones de TI para gestionar
capacidades únicas para superar el reto de mejora de las aplicaciones, infraestructuras y procesos de TI. Las
la escala y del capital financiero en comparación con soluciones a los problemas del negocio y el soporte
sus competidores americanos. Toyota desarrolló nuevas a los modelos, estrategias y operaciones de negocio
capacidades en la ingeniería de producción, gestión de aumentan en forma de servicios. La popularidad de los
operaciones y gestión de proveedores para compensar servicios compartidos y la externalización ha contribuido
su incapacidad para ofrecer grandes inventarios, fabricar al incremento del número de organizaciones que son
componentes, producir materias primas o adquirir las proveedores de servicio, entre las que se incluyen
empresas que las producen. [Fuente: Magretta, Joan las unidades organizativas internas. A cambio, se ha
2002. What Management Is: How it works and why it’s fortalecido la práctica de la Gestión del Servicio y al
everyone’s business. The Free Press.] De forma similar, las mismo tiempo se han impuesto mayores retos.
capacidades de Gestión del Servicio se ven influenciadas
por los siguientes desafíos que distinguen los servicios de
otros sistemas de creación de valor, como por ejemplo la
2.2  ¿Qué son los servicios?
fabricación, la minería y la agricultura:
2.2.1 La propuesta de valor
■ La naturaleza intangible de los productos finales e
intermedios de los procesos del servicio: resultan ser Definición de servicio
difíciles de medir, controlar y validar (o probar). Un servicio es un medio de entrega de valor a los
■ La demanda está íntimamente asociada con los clientes facilitando los resultados que los clientes
activos del cliente: Los usuarios y otros activos del desean lograr sin la responsabilidad sobre los costes y
cliente, como por ejemplo los procesos, aplicaciones, riesgos específicos.
documentos y transacciones, llegan con la demanda y
estimulan la producción del servicio. Los servicios son un medio de entrega de valor a los
■ El alto nivel de contacto para los productores y clientes facilitando los resultados que los clientes desean
12 | Gestión del Servicio como una práctica

Debo preguntar si Los servicios son un medio de provisión de valor a

tiene una definición través de los resultados que los clientes esperan sin
para los servicios. que sean responsables de costes y riesgos específicos.

¿Que implicaría eso en

términos operativos? Los servicios proveen resultados por sus
Deme alguna idea. efectos positivos sobre actividades, objetos
y tareas, para crear condiciones para un
mejor rendimiento. Así, es más probable
¿Pero sin propiedad sobre conseguir los resultados deseados.
costes y riesgos? Los clientes
no la desean de todos modos.
No, pero pueden transferir la propiedad al
Gestor Gestor proveedor. Por eso es un servicio en
(Operaciones) (Estrategia) realidad. Si los clientes lo gestionaran
Aha! Porque el proveedor se todo, no necesitarían un servicio,
especializa con capacidades para ¿verdad?
gestionar esos costes y riesgos.

(Una conversación informal

Sí, y también porque el cliente puede
en el enfriador de agua)
centrarse a su vez en esos resultados.

Y también porque el proveedor

¡Escribamos un libro
puede distribuir esos costes y
sobre gestión del servicio!
riesgos entre más de un cliente.

Figura 2.1 Una conversación sobre la definición y significado de los servicios

lograr sin la titularidad de costes y riesgos específicos. la organización. Las funciones tienden a optimizar
Los servicios facilitan los resultados mejorando el localmente sus métodos de trabajo para centrarse en los
rendimiento de las tareas asociadas y reduciendo el efecto resultados asignados. La coordinación deficiente entre
de las restricciones. El resultado es un incremento de las funciones, combinada con un enfoque hacia dentro,
posibilidades de obtener los resultados deseados. genera silos funcionales que impiden el alineamiento y la
retroalimentación críticos para el éxito de la organización
como conjunto. Los modelos de proceso ayudan a evitar
2.3  Funciones y procesos a lo largo
este problema con jerarquías funcionales que mejoran la
del ciclo de vida coordinación y el control interdisciplinario. Los procesos
bien definidos pueden mejorar la productividad dentro y
2.3.1  Funciones entre funciones.
Las funciones son unidades de organizaciones
especializadas que realizan ciertos tipos de trabajos y son 2.3.2  Procesos
responsables de la obtención de resultados específicos. Los procesos son ejemplos de sistemas de bucle cerrado,
Son independientes, y cuentan con las capacidades y debido a que proporcionan cambios y la transformación
recursos necesarios para su rendimiento y resultados. Las necesarios para lograr un objetivo, y utilizan la
capacidades incluyen métodos de trabajo internos para retroalimentación para reforzarse y corregirse a sí mismas
las funciones. Las funciones tienen su propia estructura de (Figura 2.2). Es importante considerar todo el proceso o
conocimiento, que se acumula a partir de la experiencia. cómo un proceso se adapta a otro.
Proporcionan estructura y estabilidad a las organizaciones.
Las definiciones del proceso describen acciones,
Las funciones son medios que facilitan a las organizaciones dependencias y la secuencia. Los procesos tienen las
la estructura que necesitan para implementar el principio siguientes características:
de especialización. Las funciones definen típicamente
roles, la autoridad asociada, y la responsabilidad para ■ Medible: Podremos medir el proceso de una
obtener unos resultados y un rendimiento específicos. forma apropiada. Está orientado al rendimiento. Los
La coordinación entre funciones a través de procesos responsables desean medir el coste, la calidad y
compartidos es un patrón común en el diseño de otras variables, mientras que los profesionales están
involucrados con la duración y la productividad.
 Gestión del Servicio como una práctica | 13

Datos, Proceso
información y
conocimiento
Suministra-
dores Salida
deseada
Actividad 1 Actividad 2 Actividad 3 Cliente

Control y calidad del

servicioservicio

Disparador

Figura 2.2 Un proceso básico

■ Resultados específicos: La razón que explica la 2.3.3 Especialización y coordinación a lo

existencia de un proceso es la entrega de un resultado largo del ciclo de vida
específico. Este resultado debe ser identificable y
La especialización y la coordinación son necesarias en
cuantificable individualmente. Aunque podemos
el método del ciclo de vida. Esto será posible con la
contabilizar los cambios, es imposible contabilizar
retroalimentación y control entre las funciones y procesos
cuántos Centros de Servicio al Usuario se completaron.
dentro de y entre los elementos del ciclo de vida. El
■ Clientes: Cada proceso entrega sus resultados
patrón dominante en el ciclo de vida es el progreso
primarios a un cliente o interesado. El proceso debe
secuencial que comienza a partir de Estrategia del Servicio
satisfacer sus expectativas, independientemente de
y que continúa a través de Diseño del servicio, Transición
que sean internos o externos a la organización.
del servicio, Operación del Servicio y de nuevo vuelve a
■ Responde a un evento específico: Aunque el
Estrategia del Servicio a través de CSI. Sin embargo, ese no
proceso podría ser continuo o iterativo, éste debe ser es el único patrón de acción. Cada elemento del ciclo de
fácil de rastrear para detectar su activación específica. vida proporciona puntos de retroalimentación y control.
Con frecuencia, las funciones se confunden con los La combinación de múltiples perspectivas permite
procesos. Por ejemplo, existen errores de concepto que mejorar la flexibilidad y el control a través de entornos y
confunden la Gestión de la Capacidad con un proceso situaciones. El método del ciclo de vida imita la realidad
de Gestión del Servicio. En primer lugar, la Gestión de de la mayoría de las organizaciones, donde la gestión
la Capacidad es una capacidad organizativa que cuenta eficaz requiere el uso de múltiples perspectivas de control.
con procesos y métodos de trabajo especializados. El que Los responsables del diseño, desarrollo y mejora de los
sea una función o un proceso depende por completo del procesos para la Gestión del Servicio pueden adoptar una
diseño de la organización. Es un error asumir que Gestión perspectiva de control basada en el proceso. Se podría
de la Capacidad sólo puede ser un proceso. Es posible proporcionar un mejor servicio a aquellos responsables
medir y controlar la capacidad y determinar si es adecuada de la gestión de acuerdos, contratos y servicios mediante
para un propósito dado. Puede ser un error asumir que una perspectiva de control basada en el ciclo de vida con
siempre es un proceso con resultados cuantificables discretos. distintas fases. Ambos tipos de perspectivas de control
se benefician del enfoque orientado a los sistemas. Cada
perspectiva de control puede revelar patrones que pueden
no ser obvios para los demás.
14 | Gestión del Servicio como una práctica

2.4  Aspectos fundamentales de la propios servicios. Por lo tanto, una gran parte
Operación del Servicio de esta publicación se ocupa de la gestión de la
infraestructura utilizada para entregar servicios.
2.4.1  Propósito/meta/objetivo ■ Personas. Independientemente de los servicios,
los procesos y la tecnología que se gestione, todos
El propósito de la Operación del Servicio es coordinar
éstos estarán relacionados con personas. Es decir, las
y realizar las actividades y procesos requeridos para
personas que impulsan la demanda de los servicios
entregar y gestionar servicios con los niveles acordados
y productos de la organización y las personas que
para los usuarios y clientes del negocio. Operación del
deciden cómo se hará esto. En última instancia,
Servicio también es responsable de la gestión continua
también son personas quienes gestionan la tecnología,
de la tecnología que se utiliza para entregar y apoyar los
los procesos y los servicios. Esto es fundamental
servicios.
para evitar el fracaso de los proyectos de Gestión del
Los procesos bien implementados y diseñados serán de Servicio
poco valor si la operación diaria de esos procesos no
se dirige, controla y gestiona adecuadamente. Tampoco 2.4.3 Valor para el negocio
será posible realizar mejoras del servicio si no se realizan
Cada etapa en el Ciclo de Vida del Servicio de ITIL aporta
sistemáticamente las actividades diarias de monitorización
valor al negocio. Por ejemplo, el valor del servicio se
del rendimiento, las métricas de evaluación y la
modela en la Estrategia del Servicio; el coste del servicio
recopilación de datos durante la Operación del Servicio.
se diseña, prevé y valida en el Diseño del Servicio y en la
Transición del Servicio; y las medidas para la optimización
2.4.2  Ámbito se identifican en la Mejora Continua del Servicio. La
Operación del Servicio incluye la ejecución de todas las operación del servicio es la fase en la que estos planes,
actividades continuas que se requieren para entregar y diseños y optimizaciones se ejecutan y miden. Desde
dar apoyo a los servicios. El alcance de la Operación del el punto de vista de un cliente, el valor real se ve en la
Servicio incluye: Operación del Servicio.
■ Los propios servicios. Cualquier actividad que forme Existen desventajas en esto:
parte de un servicio estará incluida en la Operación
■ Una vez que se haya diseñado y probado un servicio,
del Servicio, independientemente de que la realice un
se espera ejecutarlo dentro del presupuesto y en
Proveedor de Servicios, un suministrador externo o el
función de los objetivos de Retorno de la Inversión
usuario o cliente de ese servicio
establecidos previamente en el ciclo de vida. Sin
■ Procesos de Gestión del Servicio. La gestión y
embargo, realmente, muy pocas organizaciones
ejecución continua de muchos procesos de la Gestión
planifican eficientemente los costes de la gestión
del Servicio se realiza en la Operación del Servicio,
continua de los servicios. Es muy fácil cuantificar los
incluso cuando varios procesos de ITIL (como por
costes de un proyecto, pero es muy difícil cuantificar
ejemplo Gestión de Capacidad y de Cambios) se
lo que costará el servicio después de tres años de
originen en las etapas de Diseño del Servicio o
operación.
Transición del Servicio del Ciclo de Vida del Servicio,
■ Es difícil obtener financiación durante la fase
éstos serán utilizados continuamente en la Operación
operativa, determinar los defectos potenciales del
del Servicio. Algunos procesos no se incluyen
diseño o los requisitos imprevistos, ya que esto no
específicamente en la Operación del Servicio, como
formaba parte de la propuesta original de valor. En
por ejemplo la Definición de la Estrategia o el propio
muchos casos, todos estos problemas sólo salen a la
proceso de diseño real. Estos procesos se centran
superficie después de un cierto tiempo en operación.
más en actividades de mejora y de planificación a
La mayoría de las organizaciones no tienen un
más largo plazo que están fuera del ámbito directo
mecanismo formal para revisar el diseño y valor de los
de la Operación del Servicio; sin embargo, Operación
servicios operativos. Esto se deja para que Gestión de
del Servicio proporciona la entrada e influye en estos
Problemas e Incidencias lo resuelva como si fuese un
procesos regularmente como parte del ciclo de vida
tema puramente operativo.
de la Gestión del Servicio.
■ Es difícil obtener financiación adicional para
■ Tecnología. Todos los servicios requieren alguna
herramientas o acciones (incluyendo formación)
forma de tecnología para su entrega. La gestión de
que tengan por objetivo mejorar la eficiencia de la
esta tecnología no es un aspecto independiente,
Operación del Servicio. Esto se debe particularmente
sino una parte integral de la gestión de los
 Gestión del Servicio como una práctica | 15

a que no están vinculadas directamente con y alternativas dentro de las cuales se podría impulsar la
la funcionalidad de un servicio específico, y mejora como parte del soporte general de los objetivos de
parcialmente porque no hay ninguna expectativa negocio.
desde el principio por parte del cliente de que estos
costes deban incluirse dentro del coste del servicio. 2.4.5  Procesos dentro de la Operación del
Desafortunadamente, el ritmo de cambio de la Servicio
tecnología es muy alto. Poco después de que se haya
Éstos constituyen un número de procesos clave de
desplegado una solución que gestione eficientemente
Operación del Servicio que deben vincularse entre sí para
un conjunto de servicios, aparece una nueva
proporcionar una estructura de soporte de TI general. A
tecnología que puede hacerlo más rápido, más barato
continuación se describe brevemente la estructura general,
y más eficientemente.
y posteriormente en el Capítulo 4 se describirán con más
■ Una vez que un servicio haya estado operativo durante detalle cada uno de los procesos.
algún tiempo, éste se convierte en parte de la línea de
referencia de lo que el negocio espera de los servicios 2.4.5.1  Gestión de Eventos
de TI. Los intentos para optimizar el servicio, o usar
Gestión de Eventos monitoriza todos los eventos que
nuevas herramientas para gestionarlo de forma más
pueden producirse a través de la infraestructura de TI para
eficiente, sólo se ven como un éxito si el servicio ha
monitorizar la operación normal y detectar y escalar las
sido muy problemático en el pasado. En otras palabras,
condiciones de excepción.
no se valoran algunos servicios y cualquier acción para
optimizarlos se percibe como ‘arreglo de servicios que
2.4.5.2  Gestión de Incidencias y Problemas
no están rotos’.
Gestión de Incidencias se concentra en restaurar servicios
Esta publicación sugiere varios procesos, funciones y degradados o dañados inesperadamente tan rápidamente
medidas que tienen por objetivo abordar estas tareas. como sea posible para minimizar el impacto en el negocio.

2.4.4 Optimización del rendimiento de la Gestión de Problemas implica: análisis de la causa raíz

para determinar y resolver la causa de las incidencias,
Operación del Servicio
actividades proactivas para detectar y evitar futuros
La Operación del Servicio se optimiza de dos formas: problemas/incidencias, y un subproceso de Errores
■ Mejora incremental a largo plazo. Se basa en la Conocidos para acelerar el diagnóstico y resolución si se
evaluación del rendimiento y en la salida de todos produjeran incidencias posteriores.
los procesos y funciones de la Operación del Servicio
a lo largo del tiempo. Los informes se analizan y se 2.4.5.3  Gestión de Peticiones
toma una decisión sobre la necesidad de la mejora y, Gestión de Peticiones es el proceso que aborda las
si fuera así, cuál es la mejor forma de implementarla Peticiones de Servicio, muchas de ellas cambios realmente
a través del Diseño del Servicio y la Transición del menores o de bajo riesgo, realizadas inicialmente a través
Servicio. Algunos ejemplos de esto son el despliegue del Centro de Servicio al Usuario, pero usando un proceso
de un nuevo conjunto de herramientas, cambios independiente similar al de Gestión de Incidencias aunque
en los diseños del proceso, la reconfiguración de la con registros/tablas de Gestión de Peticiones, donde se
infraestructura, etc. Este tipo de mejora se recoge con vinculan necesariamente con los Registros de Problemas
detalle en la publicación Mejora Continua del Servicio. o Incidencias que iniciaron la necesidad de la petición.
■ Mejora continua a corto plazo de prácticas de Para que se trate de una Petición de Servicio, es normal
trabajo dentro de los propios procesos, funciones y que se definan y cumplan algunos requisitos previos
tecnología de la Operación del Servicio. Éstas son (p. ej., necesita verificarse, ser repetible, ser aprobada
generalmente mejoras menores que se implementan previamente, estar procedimentada).
sin cambiar la naturaleza fundamental de un proceso o
Para resolver una o más incidencias, problemas o Errores
tecnología. Algunos ejemplos de esto son el ajuste, el
Conocidos, podría ser necesaria alguna forma de cambio.
equilibrio de la carga de trabajo, la redistribución del
Los cambios pequeños o incluso estándar pueden ser
personal y la formación, etc.
gestionados a través de un proceso de Gestión de
Aunque éstas se analizan con más detalle dentro del Peticiones, pero cambios mayores, de mayor riesgo o
ámbito de la Operación del Servicio, la publicación Mejora poco frecuentes, requieren el uso de un proceso formal de
Continua del Servicio proporcionará un marco de trabajo Gestión de Cambios.
16 | Gestión del Servicio como una práctica

2.4.5.4  Gestión de Accesos Diseño del Servicio. En algunas organizaciones, esto se

Gestión de Accesos es el proceso de concesión del corresponde con un departamento centralizado y único,
derecho de uso de un servicio a usuarios autorizados mientras que en otras, algunas actividades y personal se
mientras se restringe el acceso a otros usuarios no centralizan o se suministran a través de departamentos
autorizados. Se basa en la capacidad para identificar de distribuidos o especializados. Gestión de Operaciones de
forma precisa a los usuarios autorizados y posteriormente TI tiene dos funciones que son únicas y que generalmente
gestionar su capacidad de acceso a servicios cuando son estructuras organizativas formales. Éstas son:
se requiera durante diferentes etapas de sus Recursos ■ Control de Operaciones de TI, que generalmente está
Humanos (RRHH) o ciclo de vida contractual. Gestión de atendido por turnos de operadores y que garantiza
Accesos también ha sido denominado como Gestión de que se lleven a cabo las tareas operativas rutinarias.
Derechos o Identidades en algunas organizaciones. Control de Operaciones de TI también proveerá
actividades centralizadas de monitorización y control,
2.4.6  Funciones dentro de la Operación del normalmente usando un Puente de Operaciones o un
Servicio Centro de Operaciones de Red.
Los procesos por sí mismos no implicarán una Operación ■ Gestión de las Instalaciones hace referencia a la
del Servicio eficaz. Además, se necesita una infraestructura gestión del entorno físico de TI, normalmente
estable y personas con las capacidades adecuadas. Para centros de datos o salas de ordenadores. En muchas
lograr esto, Operación del Servicio cuenta con varios organizaciones, Gestión de Aplicaciones y Gestión
grupos de personas capacitadas, todas centradas en el uso Técnica se ubican con Operaciones de TI en grandes
de procesos para que la capacidad de la infraestructura se centros de datos.
adapte a las necesidades del negocio.
2.4.6.4  Gestión de Aplicaciones
Estos grupos se encuentran dentro de cuatro funciones
principales, listadas aquí y analizadas con detalle en el Gestión de Aplicaciones será responsable de gestionar
Capítulo 6. Aplicaciones a través de su ciclo de vida. La función de
Gestión de Aplicaciones soporta y mantiene aplicaciones
2.4.6.1  Centro de Servicio al Usuario operativas y también desempeña un rol importante en
el diseño, prueba y mejora de aplicaciones que forman
El Centro de Servicio al Usuario es el punto principal
parte de los servicios de TI. Gestión de Aplicaciones
de contacto para usuarios si hubiera una interrupción
normalmente se divide en departamentos basados en el
del servicio, para Peticiones de Servicios, o incluso para
portfolio de aplicaciones de la organización, por lo que se
algunas categorías de Solicitudes de Cambio. El Centro de
facilita la especialización y un soporte más enfocado.
Servicio al Usuario proporciona un punto de comunicación
a los usuarios y un punto de coordinación para múltiples
2.4.6.5  Interfaces con otras etapas de la Gestión
procesos y grupos de TI.
del Ciclo de Vida del Servicio
2.4.6.2  Gestión Técnica Existen otros muchos procesos que se ejecutarán o
soportarán durante la Operación del Servicio, pero que se
Gestión Técnica proporciona habilidades técnicas
impulsan durante otras fases del Ciclo de Vida de Gestión
detalladas y recursos necesarios para apoyar la
del Servicio. Estos procesos serán analizados en la parte
operación continua de la Infraestructura de TI. Gestión
final del Capítulo 4 e incluyen:
Técnica también desempeña un rol importante en
el diseño, prueba, entrega y mejora de servicios de ■ Gestión de Cambios, que es un proceso importante
TI. En organizaciones pequeñas, es posible gestionar que podría vincularse estrechamente con Gestión de
esta experiencia en un único departamento, pero en la Configuración y con Gestión de la Entrega. Estos
organizaciones mayores, se divide normalmente entre temas se recogen principalmente en la publicación
varios departamentos especializados técnicamente. Transición del Servicio.
■ Gestión de la Disponibilidad y de la Capacidad, que se
2.4.6.3  Gestión de Operaciones de TI recogen en la publicación Diseño del Servicio.
Gestión de Operaciones de TI ejecuta las actividades ■ Gestión Financiera, que se recoge en la publicación
operativas diarias necesarias para gestionar la Estrategia del Servicio.
Infraestructura de TI. Esto se realiza de conformidad ■ Gestión del Conocimiento, que se recoge en la
con los Estándares de Rendimiento definidos durante el publicación Transición del Servicio.
 Gestión del Servicio como una práctica | 17

■ Continuidad del Servicio de TI, que se recoge en la

publicación Diseño del Servicio.
■ Medición e Informes del Servicio, que se recogen en la
publicación Mejora Continua del Servicio.
Principios de Operación
del Servicio 3
 | 21

3 Principios de Operación del Servicio

Al analizar Operación del Servicio, se tiende a considerar grupos hace referencia a personas que realizan
únicamente un enfoque en la gestión de las actividades actividades similares incluso cuando trabajan
diarias y en la tecnología como fin en sí mismo. Sin sobre diferentes tecnologías o informan dentro de
embargo, Operación del Servicio se encuentra dentro de estructuras organizativas diferentes o incluso en
un contexto extremadamente amplio. Como parte de la diferentes compañías. Normalmente los grupos no
Gestión del Ciclo de Vida del Servicio, es responsable de son estructuras organizativas formales aunque son
ejecutar y realizar procesos que optimicen el coste y la muy útiles a la hora de definir procesos comunes a
calidad de los servicios. Como parte de la organización, través de la organización, p. ej., garantizar que todas
será responsable de que el negocio cumpla sus objetivos. las personas que resuelven incidencias completen el
Como parte del mundo de la tecnología, será responsable Registro de Incidencias de la misma forma. En esta
del funcionamiento eficaz de los componentes que publicación el término ‘grupo’ no hace referencia a un
apoyan a los servicios. Los principios incluidos en este grupo de empresas que pertenecen a la misma entidad.
capítulo tienen por objetivo ayudar a los practitioners ■■ Equipo: Un equipo es un tipo más formal de grupo.
de Operación del Servicio a lograr un equilibrio entre Son personas que trabajan juntas para lograr un
todos estos roles y a centrarse en la gestión eficaz de objetivo común, pero no necesariamente en la misma
los aspectos diarios mientras se mantiene una mayor estructura organizativa. Los miembros del equipo
perspectiva del contexto. pueden ubicarse o trabajar en múltiples ubicaciones
diferentes y operar virtualmente. Los equipos son
3.1  Funciones, grupos, equipos, depar- útiles para colaborar o para abordar una situación de
naturaleza temporal o transitoria. Algunos ejemplos
tamentos y divisiones
de equipos son los equipos de proyecto, equipos de
La publicación Operación del Servicio utiliza varios desarrollo de aplicaciones (que con frecuencia están
términos para hacer referencia a la forma en la que formados por varias unidades de negocio diferentes) y
se organizan las personas para ejecutar procesos o equipos de resolución de incidencias y problemas.
actividades. Existen múltiples definiciones publicadas ■■ Departamento: Los departamentos son estructuras
para cada término y el propósito de esta publicación no organizativas formales que se crean para realizar
será entrar en el debate sobre cuál es la mejor definición. continuamente un conjunto específico de actividades
Tenga en cuenta que las siguientes definiciones son definidas. Los departamentos tienen una estructura
genéricas y no tiene valor de norma. Simplemente se jerárquica con gerentes que normalmente son
proporcionan para definir supuestos que faciliten el responsables de la ejecución de actividades y también
entendimiento de la materia. El lector debe adaptar estos de la gestión diaria del personal en el departamento.
principios a las prácticas organizativas que se utilicen en ■■ División: Una división hace referencia a un número
su propia organización. de departamentos que se han agrupado juntos,
■■ Función: Una función es un concepto lógico que normalmente por criterios geográficos o por líneas
hace referencia a las personas y a las medidas de producto. Una división normalmente será
automatizadas que ejecutan un proceso definido, independiente y podrá planificar y ejecutar todas las
una actividad o una combinación de procesos o actividades en una cadena de suministro.
actividades. En organizaciones grandes, una función ■■ Rol: Un rol hace referencia a un conjunto de
podría dividirse y ser llevada a cabo por varios comportamientos o acciones conectadas que son
departamentos, equipos y grupos, o podría estar realizadas por una persona, equipo o grupo en un
a cargo de una única unidad organizativa (p. ej., contexto específico. Por ejemplo, un departamento
Centro de Servicio al Usuario). En organizaciones de Gestión Técnica puede llevar a cabo el rol de
más pequeñas, una persona o grupo puede realizar Gestión de Problemas al diagnosticar la causa raíz de
múltiples funciones, es decir, el departamento de incidencias. También se puede esperar que este mismo
Gestión Técnica también podría incorporar la función departamento desempeñe otros múltiples roles en
del Centro de Servicio al Usuario. diferentes momentos, p. ej., podría analizar el impacto
■■ Grupo: Un grupo es un número de personas que de cambios (rol de Gestión de Cambios), gestionar
de alguna forma son análogas. En esta publicación, el rendimiento de los dispositivos que estén bajo su
22 | Principios de Operación del Servicio

control (rol Gestión de la Capacidad), etc. El ámbito de Ambas visiones son necesarias al entregar servicios. La
su rol y qué los activa para que desempeñen ese rol, organización que se enfoca sólo en los requisitos de
están definidos por el proceso pertinente y acordado negocio, sin pensar en cómo se entregarán los servicios,
por su gerente de línea. acabará por hacer promesas que no se podrán mantener.
La organización que se centra sólo en los sistemas
3.2  Logro del equilibrio en la internos, sin pensar en los servicios que respaldan, acabará
Operación del Servicio con servicios caros que ofrecen poco valor.

Operación del Servicio es algo más que la ejecución El posible conflicto asociado con los roles entre las
repetitiva de un conjunto estándar de procedimientos y visiones internas y externas es el resultado de muchas
actividades. Todas las funciones, procesos y actividades se variables, incluyendo la madurez de la organización, su
diseñaron para entregar un nivel acordado y especificado cultura de gestión, su historia, etc. Esto dificulta el logro
de servicios, aunque tienen que entregarse en un entorno de un equilibrio, y la mayoría de las organizaciones
siempre cambiante. tienden más hacia un rol que hacia otro. Lógicamente,
ninguna organización se centrará por completo interna o
Esto crea un conflicto entre el mantenimiento del externamente, sino que se encontrará en una posición a
status quo y la adaptación a los cambios en el entorno lo largo de un espectro entre las dos. Esto se ilustra en la
tecnológico y en el negocio. Por lo tanto, uno de los roles Figura 3.1:
clave de Operación del Servicio es abordar este conflicto
y lograr un equilibrio entre conjuntos conflictivos de Una organización Una organización aquí
aquí no está está bastante
prioridades. equilibrada y corre el equilibrada,
riesgo de no cumplir pero tiende a
Esta sección de la publicación resalta algunas de los requisitos de entregar por debajo de
las tensiones y conflictos clave e identifica cómo las negocio lo prometido al cliente
organizaciones de TI pueden reconocer que están
Enfoque Enfoque
sufriendo un desequilibrio tendiendo más hacia un extremo en lo extremo en lo
extremo que hacia el otro. También proporciona interno externo
directrices de alto nivel sobre cómo resolver el conflicto
y, por lo tanto, desplazarse hacia un método que aplique
mejores prácticas. Por lo tanto, cada conflicto representa
una oportunidad de crecimiento y mejora.
Figura 3.1 Lograr un equilibrio entre el enfoque
3.2.1 Visión interna de TI comparada con la interno y externo
visión externa del negocio
El conflicto más fundamental en todas las fases del La Tabla 3.1 presenta algunos ejemplos de las
Ciclo de Vida de ITSM se encuentra entre la visión de TI características de las posiciones en los extremos del
como un conjunto de servicios de TI (la visión externa espectro. El propósito de esta tabla es ayudar a las
del negocio) y la visión de TI como un conjunto de organizaciones a identificar su extremo más cercano, y no
componentes de tecnología (visión interna de TI): a identificar las posiciones reales a las que deben aspirar
las organizaciones.
■■ La visión externa de TI es la forma con la que los
usuarios y clientes experimentan los servicios. No
siempre entienden ni se preocupan de los detalles
de cómo se utiliza la tecnología para gestionar esos
servicios. Lo que les preocupa es que los servicios se
entreguen como solicitaron y acordaron.
■■ La visión interna de TI es la forma en la que se
gestionan los componentes y sistemas de TI para
entregar los servicios. Debido a la complejidad y
variedad de los sistemas de TI, esto normalmente
implica que la tecnología sea gestionada por varios
equipos o departamentos diferentes, cada uno de
los cuales está centrado en el logro de un buen
rendimiento y disponibilidad de ‘sus’ sistemas.
 Principios de Operación del Servicio | 23

Tabla 3.1 Ejemplos de enfoque interno y externo extremos

Enfoque interno extremo Enfoque externo extremo

Enfoque Rendimiento y gestión de dispositivos, sistemas Logro de altos niveles de rendimiento del servicio de TI
principal y personal de la Infraestructura de TI, con poca con poca consideración sobre cómo lograrlo
consideración al resultado final del servicio de TI
Métricas ■■ Enfoque en el rendimiento técnico sin mostrar qué ■■ Enfoque en Métricas Externas sin mostrar al personal
es lo que esto implica para los servicios interno cómo se derivan y cómo se pueden mejorar
■■ Métricas internas (p. ej., tiempo disponible de la red) ■■ Se espera que el personal interno diseñe sus propias
que rinden cuentas al negocio en lugar de métricas métricas para medir el rendimiento interno.
del rendimiento del servicio.
Experiencia ■■ Gran consistencia de la entrega aunque sólo se ■■ La consistencia de la entrega es deficiente
del cliente/ entrega un porcentaje de lo que necesita el negocio. ■■ ‘TI consiste en buenas personas con buenas
usuario ■■ Usa un método “push” para la entrega, es decir, intenciones, pero no siempre se puede llevar a cabo’
prefiere tener un conjunto estándar de servicios para ■■ Modo reactivo de operación.
todas las unidades de negocio.
■■ Usa un método “pull” para la entrega, es decir, prefiere
entregar servicios personalizados bajo pedido
Estrategia de ■■ Operaciones estándar a través de la dirección ■■ Múltiples equipos de entrega y múltiples tecnologías
operaciones ■■ Todos los nuevos servicios necesitan acoplarse ■■ Las nuevas tecnologías requieren nuevos métodos
dentro de la arquitectura y procedimientos actuales. de operaciones y con frecuencia nuevos equipos de
operaciones de TI.
Procedi- Se enfoca exclusivamente sobre cómo gestionar la Se enfoca principalmente sobre lo que se necesita hacer y
mientos y tecnología y no sobre cómo se relaciona su rendimiento cuándo, y menos sobre cómo debería lograrse
manual con los servicios de TI
Estrategia de ■■ Reducción de costes lograda exclusivamente a través ■■ Presupuesto asignado sobre la base de la unidad de
costes de la consolidación de la tecnología negocio que tiene más necesidades
■■ Optimización de recursos y procedimientos ■■ Menos articulado o las unidades de negocio directas
operativos con frecuencia tienen servicios inferiores ya que no hay
■■ Con frecuencia, el impacto en el negocio del recorte suficiente financiación asignada a sus servicios.
de costes sólo se entiende a posteriori
■■ Los cálculos del Retorno de la Inversión se enfocan
exclusivamente en el ahorro de costes o en los
‘periodos de recuperación’
Formación La formación se dirige como un aprendizaje, donde los ■■ La formación se dirige proyecto a proyecto
nuevos operadores tienen que aprender la forma en la ■■ No hay cursos de formación estándar debido a que los
que se tienen que hacer las cosas y no el por qué procedimientos operativos y la tecnología están en
continuo cambio.
Personal de ■■ Personal especializado organizado de conformidad ■■ Personal generalista, organizado particularmente de
operaciones con la especialidad técnica conformidad con la capacidad técnica y parcialmente
■■ El personal trabaja en el falso supuesto de que de conformidad con su relación con una unidad de
un buen logro técnico es lo mismo que un buen negocio
servicio al cliente. ■■ Dependencia de los ‘actos heroicos’ donde el personal
se desvía de su camino para resolver problemas que
hubieran podido evitarse a través de procesos internos
mejores.
24 | Principios de Operación del Servicio

Esto no significa que el enfoque externo carezca de ■■ Implicación del personal de Operaciones de TI en las
importancia. Lo que se pretende de la Gestión del Servicio fases de Diseño y Transición del Servicio del Ciclo de
es proporcionar servicios que cumplan los objetivos de Vida de ITSM.
la organización en su conjunto. Es esencial estructurar ■■ Entrada desde, y retroalimentación para, la Mejora
servicios alrededor de clientes. Al mismo tiempo, es posible Continua del Servicio, para identificar áreas donde
que la calidad de los servicios se vea comprometida si no se haya un desequilibrio y los medios para identificar e
piensa en cómo se entregarán. implementar la mejora.
La puesta en práctica de Operación del Servicio con un ■■ Un plan de comunicación y formación claro para el
equilibrio entre el enfoque interno y externo requiere negocio. Aunque muchas organizaciones son buenas
un método dedicado a largo plazo y que se refleje en en el desarrollo de Planes de Comunicación para los
todas las fases del Ciclo de Vida del Servicio de ITSM. Esto proyectos, con frecuencia esto no se extiende a su
requerirá lo siguiente: fase operativa.

■■ Entender qué servicios está utilizando el negocio y por

3.2.2 Estabilidad comparada con capacidad
qué.
de respuesta
■■ Entender la importancia relativa y el impacto de esos
servicios en el negocio. No importa cómo sea de buena la funcionalidad de
un servicio de TI y no importa cómo de bien se haya
■■ Entender cómo se utiliza la tecnología para proveer
diseñado, esto apenas tendrá valor si los componentes del
servicios de TI.
servicio no están disponibles o si son inconsistentes.
■■ Implicación de Operación del Servicio en proyectos de
Mejora Continua del Servicio para identificar formas de Esto significa que Operación del Servicio necesita
entregar servicios de más calidad y menos costosos. garantizar que la Infraestructura de TI sea estable y
■■ Procedimientos y manuales que contengan el rol de esté disponible tal y como se diseñó. Al mismo tiempo,
Operaciones de TI en la gestión de la tecnología y en Operación del Servicio necesita reconocer que el negocio
la entrega de servicios de TI. y los requisitos de TI están en continuo cambio.
■■ Un conjunto claramente diferenciado de métricas para Algunos de estos cambios son evolutivos. Por ejemplo,
informar al negocio sobre el logro de los objetivos del la funcionalidad, rendimiento y arquitectura de una
servicio; y para informar a los directores de TI sobre la plataforma podrían cambiar con el paso de los años.
eficiencia y eficacia de Operación del Servicio. Cada cambio ofrece una oportunidad de proveer mejores
■■ Todo el personal de Operaciones de TI entiende niveles de servicio al negocio. En los cambios evolutivos,
exactamente cómo afecta el rendimiento de la es posible planificar cómo responder al cambio y, por lo
tecnología a la entrega de los servicios de TI y, a su tanto, mantener la estabilidad mientras se responde a los
vez, cómo éstos afectan al negocio y a los objetivos cambios.
de negocio.
Sin embargo, muchos cambios se producen muy
■■ Un conjunto de servicios estándar entregados rápidamente y algunas veces bajo extrema presión. Por
consistentemente a todas las Unidades de Negocio y ejemplo, una Unidad de Negocio gana inesperadamente
un conjunto de servicios no estándar (algunas veces un contrato que requiere servicios adicionales de TI,
personalizados) entregados a Unidades de Negocio más capacidad y tiempos de respuesta más rápidos. La
específicas, junto con un conjunto de Procedimientos capacidad de respuesta a este tipo de cambio sin impactar
de Operación Estándar (SOPs) que puedan cumplir en otros servicios representa un reto significativo.
ambos conjuntos de requisitos.
■■ Una estrategia de costes para equilibrar los requisitos Muchas organizaciones de TI son incapaces de lograr este
de diferentes unidades de negocio con el ahorro equilibrio y tienden a centrarse en la estabilidad de la
de costes disponible a través de la optimización Infraestructura de TI o en la capacidad de respuesta rápida
de la tecnología existente o de la inversión en a los cambios.
nuevas tecnologías, y entender la estrategia de
costes realizada a través de todos los recursos de TI
implicados.
■■ Estrategia de Retorno de la Inversión basada en el
valor en lugar de en los costes.
 Principios de Operación del Servicio | 25

Tabla 3.2 Ejemplos de enfoque extremo en la estabilidad y en la capacidad de respuesta

Enfoque extremo en la estabilidad Enfoque extremo en la capacidad de respuesta

Enfoque ■■ Tecnología ■■ Salida para el negocio

principal ■■ Desarrollo y perfeccionamiento de las técnicas y ■■ Acuerda los cambios requeridos antes de determinar lo
procesos de gestión de TI estándar. que se requerirá para entregarlos.
Problemas TI puede demostrar que está cumpliendo con los SOP y El personal de TI no está disponible para definir o ejecutar
típicos experi- los Acuerdos de Nivel Operativo (OLA), incluso cuando tareas rutinarias debido a que están ocupados en proyectos
mentados exista una falta de coordinación con los requisitos de para nuevos servicios
negocio
Estrategia de ■■ Estrategia de crecimiento basada en el análisis de la ■■ Se adquiere tecnología para cada nuevo requisito de
crecimiento demanda existente sobre los sistemas existentes negocio
tecnológico ■■ Los nuevos servicios se resisten y algunas veces las ■■ Uso de múltiples tecnologías y soluciones para
Unidades de Negocio asumen la propiedad de ‘sus soluciones similares, para cumplir necesidades de
propios’ sistemas para obtener acceso a nuevos negocio ligeramente diferentes.
servicios.
Tecnología Se utiliza tecnología existente o estándar; los servicios Exceso de provisión. No se intenta modelar el nuevo
utilizada deben ajustarse a los parámetros existentes servicio en la infraestructura existente. Se compra
para entregar tecnología nueva y dedicada para cada nuevo proyecto
servicios de TI
Gestión de ■■ Previsiones basadas en proyecciones de cargas de ■■ Previsiones basadas en la futura actividad del negocio
Capacidad trabajo actuales para cada servicio individual, sin tener en cuenta la
■■ El rendimiento del sistema se mantiene a niveles actividad de TI y otros servicios de TI
consistentes a través del ajuste y gestión de la ■■ Las cargas de trabajo existentes no son relevantes.
demanda, no a través de la gestión y la previsión de
la carga de trabajo.

La Tabla 3.2 presenta algunos ejemplos de las características ■■ Garantizar inversiones en tecnologías y procesos que
de las posiciones en los extremos del espectro. El propósito sean adaptables en lugar de rígidos, p. ej., servidor
de esta tabla es ayudar a las organizaciones a identificar su virtual y tecnología de aplicaciones, y el uso de Modelos
extremo más cercano, y no a identificar las posiciones reales de Cambios (vea la publicación Transición del Servicio).
a las que deben aspirar las organizaciones. ■■ Construir un proceso robusto de Gestión del Nivel de
Servicio (SLM) que esté activo desde la fase de Diseño
Una organización aquí Una organización
no está equilibrada y aquí está bastante del Servicio hasta la fase de Mejora Continua del
corre el riesgo de equilibrada, pero Servicio del Ciclo de Vida de ITSM.
ignorar cambios en los puede tender a gastar
requisitos de negocio en exceso en el ■■ Fomentar la integración entre SLM y los demás
cambio
procesos de Diseño del Servicio para garantizar la
Enfoque adecuada alineación entre los requisitos de negocio y
Enfoque extremo
extremo en la en la capacidad de las actividades operativas de TI y los componentes de
estabilidad respuesta la Infraestructura de TI. Esto facilita modelar el efecto
de los cambios y de las mejoras.
■■ Iniciar cambios en la etapa apropiada más temprana
en el Ciclo de Vida de ITSM. Esto garantizará que los
requisitos funcionales (negocio) y de capacidad de
Figura 3.2 Lograr un equilibrio entre enfoque en la gestión (operativo de TI) se puedan evaluar y construir
estabilidad y en la capacidad de respuesta o que se cambien conjuntamente.
■■ Garantizar lo antes posible la implicación de TI en
Construir una organización de TI que logre un equilibrio los cambios en el negocio dentro del proceso de
entre la estabilidad y capacidad de respuesta en Operación cambio para garantizar la escalabilidad, consistencia
del Servicio requerirá las siguientes acciones: y la posibilidad de realización de servicios de TI que
soporten cambios del negocio.
26 | Principios de Operación del Servicio

Servicio
Coste del servicio

Rango de equilibrio
óptimo entre
Coste y Calidad

Calidad de servicio
(Rendimiento, Disponibilidad, Recuperación)
Figura 3.3 Equilibrio entre la calidad y el coste del servicio

■■ Los equipos de Operación del Servicio deben ■■ Posteriormente en el ciclo de vida del servicio, incluso
proveer entradas en el diseño y perfeccionamiento pequeñas mejoras de calidad resultan muy caras. Por
continuo de las arquitecturas y servicios de TI (vea ejemplo, mejorar la disponibilidad del mismo servicio
las publicaciones Diseño del Servicio y Estrategia del del 96% al 99,9% podría requerir grandes inversiones
Servicio). en tecnología de alta disponibilidad, en personal de
■■ Implementar y utilizar SLM para evitar situaciones en soporte y en herramientas.
las que el negocio, el personal y los directores de TI Auque esto pudiera parecer sencillo, muchas
negocian acuerdos informales. organizaciones se encuentran bajo mucha presión a la
hora de mejorar la calidad del servicio a la vez que se
3.2.3 Calidad del servicio comparada con reducen los costes. En la Figura 3.3, la relación entre
coste del servicio coste y calidad es algunas veces inversa. Es posible
Se requiere que la Operación del Servicio entregue (normalmente dentro del rango de optimización) mejorar
consistentemente a sus clientes y usuarios el nivel de la calidad mientras que se reducen los costes. Esto
servicio de TI acordado, y que a la vez mantenga los normalmente se inicia dentro de Operación del Servicio
costes y el uso de los recursos a un nivel óptimo. y continúa a través de la Mejora Continua del Servicio.
Algunos costes se pueden reducir progresivamente con el
La Figura 3.3 representa la inversión realizada para entregar paso del tiempo, pero la mayoría de los ahorros de costes
un servicio a niveles cada vez más altos de calidad. sólo pueden hacerse una vez. Por ejemplo, una vez se
En la Figura 3.3, un aumento en el nivel de calidad haya eliminado una herramienta de software duplicada,
normalmente genera un incremento en el coste de ese ésta no se podrá eliminar nuevamente para conseguir
servicio, y viceversa. Sin embargo, la relación no siempre ahorros de costes posteriores.
es directamente proporcional: Lograr un equilibrio óptimo entre coste y calidad
■■ Al comienzo del ciclo de vida del servicio es posible (mostrado entre líneas de puntos en la Figura 3.3) es
lograr aumentos significativos en la calidad del servicio un rol clave de la Gestión del Servicio. No existe ningún
con una cantidad relativamente pequeña de dinero. estándar de la industria que indique cuál debería ser
Por ejemplo, mejorar la disponibilidad del servicio del este rango, ya que cada servicio tendrá un rango de
55% al 75% es bastante sencillo y puede no requerir optimización diferente en función de la naturaleza del
una gran inversión.
 Principios de Operación del Servicio | 27

servicio y del tipo de objetivo de negocio a cumplir. Por Los Requerimientos de Nivel de Servicio, junto con una
ejemplo, el negocio podría estar preparado para gastar comprensión clara del propósito de negocio del servicio
más con el objeto de lograr mayor disponibilidad en un y de los riesgos potenciales, ayudarán a garantizar que
servicio crítico, a la vez que está preparado para aceptar se entregue el servicio al coste apropiado. También
menor calidad de una herramienta administrativa. ayudarán a evitar que se sobredimensione el servicio sólo
porque lo permite el presupuesto, o que disminuya el
La identificación del equilibro adecuado entre coste y
tamaño porque el negocio no entiende los requisitos de
calidad debe realizarse durante las fases del Ciclo de Vida
gestión de la solución. Ambos darán como resultado la
de Estrategia del Servicio y Diseño del Servicio, aunque en
insatisfacción del cliente e incluso más gastos cuando la
muchas organizaciones se deja a los equipos de Operación
solución se vuelva a diseñar o modificar para adaptarse a
del Servicio, muchos de los cuales generalmente no tienen
los requisitos que se deberían haber especificado durante
todos los datos o la autoridad necesarios para poder
el Diseño del Servicio.
tomar este tipo de decisiones.
Una organización aquí Una organización
Desafortunadamente, también es común encontrar no está equilibrada y aquí está bastante
organizaciones que gastan grandes cantidades de dinero corre el riesgo de perder equilibrada, pero puede
calidad del servicio tender a gastar en exceso
sin lograr ninguna mejora clara de la calidad. Nuevamente, debido a las drásticas para entregar niveles de
la Mejora Continua del Servicio podrá identificar la causa reducciones de coste servicio superiores a los
estrictamente necesarios
de la ineficiencia, evaluar el equilibrio óptimo de ese
servicio y formular un plan correctivo. Enfoque Enfoque
extremo en el extremo en la
Coste Calidad
Lograr el equilibrio correcto es importante. Un enfoque
demasiado centrado en la calidad dará como resultado
servicios de TI que entregan más de lo necesario a un
coste mayor, y podría provocar una discusión sobre
la reducción del precio de los servicios. Un enfoque
demasiado centrado en el coste dará como resultado Figura 3.4 Lograr un equilibrio entre el enfoque en los
la entrega de servicios de TI dentro o por debajo del costes y en la calidad
presupuesto, pero añadirá riesgo al negocio a través de
servicios de TI que no cumplen los estándares.

Nota especial: ¿Cuánto es demasiado?

En los últimos años, las organizaciones de TI han
estado bajo presión para reducir los costes. En
muchos casos esto ha permitido optimizar costes y
mejorar la calidad. Pero en otros casos, los costes se
redujeron hasta un punto en el que la calidad empezó
a deteriorarse. Al principio, se produjeron signos
sutiles, como por ejemplo pequeños incrementos de
los tiempos de resolución de incidencias y un ligero
incremento en el número de incidencias. Sin embargo,
con el tiempo la situación se transformó en algo más
grave debido a que el personal debía trabajar muchas
horas para manejar múltiples cargas de trabajo y
los servicios empezaron a quedarse obsoletos o la
infraestructura se quedó desactualizada.
No existe un cálculo sencillo que determine cuándo
se han recortado demasiado los costes, pero un buen
SLM es esencial para que los clientes sean conscientes
del impacto de un recorte demasiado fuerte, por lo
que identificar estos signos y síntomas de advertencia
puede mejorar en gran medida la capacidad de una
organización para corregir esta situación.
28 | Principios de Operación del Servicio

Tabla 3.3 Ejemplos de enfoque extremo sobre la calidad y sobre el coste

Enfoque extremo en la calidad Enfoque extremo en el coste

Enfoque Entrega del nivel de calidad demandado por el negocio Respeta el presupuesto y reduce costes
principal independientemente de lo que cueste
Problemas ■■ Presupuestos crecientes ■■ TI limita la calidad del servicio basándose en su
típicos experi- ■■ Los servicios de TI entregan generalmente más de lo disponibilidad de presupuesto
mentados necesario para el éxito del negocio ■■ Solicitudes crecientes desde el negocio para obtener
■■ Demanda creciente de servicios de mayor calidad. más servicios de TI.
Gestión Normalmente TI no tiene un método para comunicar Los informes financieros se realizan exclusivamente sobre
Financiera el coste de los servicios de TI. Los métodos de las cantidades presupuestadas. No hay forma de vincular
contabilidad de costes se basan en un método agregado actividades en TI a la entrega de servicios de TI.
(p. ej., coste de TI por usuario).

La Tabla 3.3 presenta algunos ejemplos de las activamente el comportamiento proactivo del personal
características de las posiciones extremas del espectro de operaciones. La desafortunada ironía de este método
coste/calidad. El propósito de esta tabla es ayudar a las es que desincentivar la inversión en esfuerzo para la
organizaciones a identificar su extremo más cercano, y no Gestión del Servicio proactiva puede aumentar finalmente
a identificar las posiciones reales a las que deben aspirar el esfuerzo y el coste de las actividades reactivas y poner
las organizaciones. en mayor riesgo la estabilidad y la consistencia de los
servicios.
Si se logra un equilibrio se garantizará la entrega del
nivel de servicio necesario para cumplir los requisitos de Una organización proactiva siempre está buscando
negocio con un coste óptimo (en lugar de al coste más fórmulas para mejorar la situación actual. Examinará
bajo posible). Esto requerirá lo siguiente: continuamente los entornos internos y externos buscando
signos de cambio que puedan tener un impacto potencial.
■■ Un proceso de Gestión Financiera y herramientas
El comportamiento proactivo normalmente se considera
que puedan contabilizar el coste de la entrega de los
como positivo, especialmente porque permite a la
servicios de TI; y modelar métodos alternativos de
organización mantener su ventaja competitiva en un
entrega de servicios con diferentes niveles de coste.
entorno cambiante. Sin embargo, ser demasiado proactivo
Por ejemplo, comparar el coste de la entrega de
puede resultar caro y puede distraer al personal. La
un servicio al 98% de disponibilidad o al 99,9% ; o
necesidad de lograr un equilibrio adecuado con respecto
comparar el coste de suministrar un servicio con o sin
al comportamiento reactivo y proactivo normalmente
funcionalidades adicionales.
consigue el resultado óptimo.
■■ Garantizar que las decisiones en torno al coste frente
a la calidad sean tomadas por los responsables Generalmente es mejor gestionar servicios de TI de forma
adecuados durante la Estrategia y Diseño del Servicio. proactiva, pero esto no es fácil de planificar o lograr. Esto
Los responsables operativos de TI generalmente no se debe a que crear una organización de TI proactiva
cuentan con herramientas para evaluar oportunidades depende de muchas variables que incluyen:
de negocio y sólo se les debe pedir que tomen ■■ La madurez de la organización. Cuanto más tiempo
decisiones financieras que estén asociadas a la la organización haya estado entregando un conjunto
consecución de eficiencias operativas. consistente de servicios de TI, más probable será que
entienda la relación entre TI y el negocio así como la
3.2.4 Reactivo contra proactivo de la Infraestructura de TI y los servicios de TI.
Una organización reactiva es aquella que no actúa a ■■ La cultura de la organización. Algunas organizaciones
menos que un impulsor externo se lo pida, p. ej., un tienen una cultura enfocada a la innovación y serán
nuevo requisito de negocio, una aplicación que ha sido más propensas a ser proactivas. Otras son más
desarrollada o un aumento de las quejas realizadas propensas a centrarse en el statu quo, por lo que es
por usuarios y clientes. Una realidad desafortunada en más probable que se resistan al cambio y que tengan
muchas organizaciones consiste en centrarse en la gestión un enfoque más reactivo.
reactiva como el único medio para garantizar servicios que ■■ El rol que desempeña TI en el negocio y la exigencia
sean sumamente consistentes y estables, desalentando de que las TI influyan en la estrategia y las tácticas
 Principios de Operación del Servicio | 29

del negocio. Por ejemplo, una empresa en la que el Una organización aquí no Una organización aquí
CIO es un miembro de la dirección, es más propensa está equilibrada y no está bastante
puede dar soporte de equilibrada,
a tener una organización de TI más proactiva y forma eficaz la estrategia pero tiende a arreglar servicios
responsable que una empresa en la que TI sea visto del negocio que no presentan problemas, lo
que provoca elevados niveles
como un gasto general administrativo. de cambio
■■ El nivel de integración de los procesos y herramientas Extremadamente Extremadamente
de gestión. Cuanto más elevados sean los niveles Reactiva Proactiva
de integración, más se facilitará el conocimiento de
oportunidades.
■■ La madurez y ámbito de la Gestión del Conocimiento
en la organización. Esto está especialmente presente
en organizaciones que han sido capaces de almacenar
y organizar históricos de datos de forma eficiente, Figura 3.5 Lograr un equilibrio entre ser demasiado
especialmente datos de Gestión de Problemas y de reactivo o demasiado proactivo
Gestión de la Disponibilidad.
■■ Las organizaciones más maduras tienden a ser más
Desde una perspectiva de la madurez, está claro que proactivas simplemente porque disponen de más
las organizaciones más jóvenes tendrán experiencias y datos e informes, y conocen los patrones típicos de las
prioridades diferentes a las de las más asentadas; lo que es incidencias y flujos de trabajo. Por lo tanto, tienen más
mejor práctica para una organización madura puede que facilidad para hacer previsiones de excepciones.
no sea adecuado para una organización más joven. Por lo
■■ El personal que trabaja en organizaciones maduras
tanto, una falta de equilibrio puede estar relacionada con
también tiende generalmente a tener relaciones
el grado de madurez de una organización. Considere lo
más estables entre ellos y el negocio y, por lo tanto,
siguiente:
pueden ser más proactivos a la hora de cumplir
■■ Las organizaciones menos maduras (u organizaciones requisitos de negocio cambiantes. Esto se cumple
con tecnología o servicios de TI más nuevos) especialmente cuando TI se considera como un
generalmente serán más reactivas, simplemente componente estratégico del negocio.
porque no conocen todas las variables implicadas
La Tabla 3.4 presenta algunos ejemplos de las
en la actividad de su negocio y en el suministro de
características de las posiciones en los extremos del
servicios de TI.
espectro. El propósito de esta tabla es ayudar a las
■■ El personal de TI en nuevas organizaciones tiende a organizaciones a identificar a qué extremo se acercan más,
actuar de forma más genérica, porque no está claro no a identificar posiciones reales a las que deben aspirar
lo que se requiere exactamente para la entrega de las organizaciones.
servicios de TI estables para el negocio.
■■ Las incidencias y problemas en nuevas organizaciones
son bastante impredecibles porque la tecnología es
relativamente nueva y cambia rápidamente.
30 | Principios de Operación del Servicio

Tabla 3.4 Ejemplos de comportamiento extremadamente reactivo o proactivo

Extremadamente reactivo Extremadamente proactivo

Enfoque Responde a las necesidades del negocio y a las Anticipa requisitos de negocio antes de que se informe de
principal incidencias sólo después de que se haya tenido noticia ellos y antes de que se produzcan los problemas
de ellas
Problemas ■■ La preparación de la entrega de nuevos servicios ■■ El dinero se gasta antes de que se establezcan los
típicos experi- consume mucho tiempo porque cada proyecto se requisitos. En algunos casos TI compra componentes
mentados trata como si fuera el primero que nunca se utilizarán porque se previeron requisitos
■■ Se producen incidencias similares de forma repetitiva erróneos o porque se paró el proyecto
debido a que no hay forma de anticiparse a ellas ■■ El personal de TI tiende a estar mucho tiempo en
■■ La rotación de personal es alta y la moral es la organización y tiende a asumir que conoce los
generalmente baja ya que el personal de TI pasa requisitos de negocio mejor que el propio negocio
continuamente de proyecto a proyecto sin lograr un
conjunto estable y duradero de servicios de TI
Planificación Espera hasta que haya problemas de capacidad y a Anticipa problemas de capacidad y gastar dinero para
de la continuación compra capacidad extra hasta que se prevenirlos, incluso cuando es improbable que se produzca
Capacidad produce la siguiente incidencia asociada con la capacidad esa situación
Planificación ■■ No existen planes hasta después de un evento o ■■ Exceso de planificación (y exceso de gasto) de
de la desastre importante opciones de Recuperación de TI. Normalmente la
Continuidad ■■ Los Planes de TI se centran en la recuperación de recuperación inmediata está garantizada para la mayoría
del Servicio sistemas clave sin garantizar que el negocio pueda de los servicios de TI independientemente de su
de TI recuperar sus procesos impacto o prioridad
Gestión de ■■ Normalmente los cambios no se registran o se Los cambios se solicitan e implementan incluso cuando no
Cambios registran en el último minuto como Cambios de hay necesidad real de ello, es decir, se realiza una cantidad
Emergencia significativa de trabajo para arreglar componentes que no
■■ No hay tiempo suficiente para una evaluación están rotos
adecuada sobre el impacto y los costes
■■ Los cambios se controlan y prueban deficientemente
lo que provoca un alto número de incidencias

Aunque el comportamiento proactivo de Operación del ■■ Implicación continua de SLM en Operación del
Servicio es generalmente bueno, en ocasiones también Servicio.
se necesita comportamiento reactivo. Por lo tanto, el rol
de Operación del Servicio es lograr un equilibrio entre ser 3.3  Provisión del servicio
reactivo y proactivo. Esto requerirá:
Todo el personal de Operación del Servicio debe ser
■■ Procesos formales de Gestión de Problemas y Gestión completamente consciente de que su objetivo es ‘proveer
de Incidencias, integrados entre Operación del Servicio servicios’ al negocio. Deben proveer un servicio puntual
y Mejora Continua del Servicio. (respuesta rápida y entrega diligente de requisitos),
■■ Ser capaces de priorizar tanto los fallos técnicos profesional y atento para que el negocio pueda dirigir
como las demandas del negocio. Esto debe ser sus propias actividades, de modo que se satisfagan las
realizado durante la Operación del Servicio, pero los necesidades comerciales del cliente y se logren los éxitos
mecanismos deben instaurarse durante la Estrategia del negocio.
y Diseño del Servicio. Estos mecanismos podrían
Es importante que el personal esté formado no sólo
incluir sistemas de categorización de incidencias,
sobre cómo entregar y apoyar los servicios de TI, sino
procedimientos de escalado y herramientas que
también en la manera en la que éstos deben proveerse.
faciliten la evaluación del impacto de los cambios.
Por ejemplo, un personal capacitado que realiza un
■■ Datos de Gestión de la Configuración y Gestión
servicio de entrega eficiente, todavía podría provocar una
de Activos para ser provistos cuando se requieran, insatisfacción importante en el cliente si fueran demasiado
ahorrando tiempo en los proyectos y tomando insensibles o mostraran falta de interés. Por el contrario,
decisiones más precisas.
 Principios de Operación del Servicio | 31

un trato adecuado al cliente ayudará si el servicio no se se debe involucrar al personal de Gestión de Operaciones
está entregando. de TI durante la Transición del Servicio para garantizar
la consistencia y asegurar que se cumplan los requisitos
Un elemento crítico para ser un proveedor de servicios
establecidos del negocio y de la capacidad de gestión.
competente consiste en poner más énfasis en la
contratación y formación del personal para desarrollar Los recursos deben de estar disponibles para realizar
aptitudes en el trato y en la gestión de relaciones e estas actividades y deben tenerse en cuenta los tiempos
interacciones con el cliente, a la vez que desarrollan requeridos.
aptitudes técnicas para gestionar el entorno de TI.
3.5  Salud operativa
3.4  Implicación del personal de Muchas organizaciones encuentran útil para comparar la
operación en Diseño del Servicio y en monitorización y el control de Operación del Servicio con
Transición del Servicio la monitorización y control de la salud.
Es extremadamente importante que el personal de En este sentido, la Infraestructura de TI es como un
Operación del Servicio se implique en el Diseño del organismo que tiene signos vitales que se pueden
Servicio y Transición del Servicio y potencialmente monitorizar para comprobar si funciona con normalidad.
también en Estrategia del Servicio cuando sea apropiado. Esto significa que no será necesario monitorizar
Una clave para lograr el equilibrio en Operación del continuamente cada componente de cada sistema de TI
Servicio es contar con un conjunto eficaz de procesos de para garantizar que está funcionando.
Diseño del Servicio. Éstos proporcionarán a Gestión de La Salud Operativa se puede determinar aislando algunos
Operaciones de TI: ‘signos vitales’ importantes en dispositivos y servicios
■■ Una definición clara de objetivos del servicio de TI y que se definen como críticos para lograr el éxito en
criterios de rendimiento la ejecución de una Función Vital del Negocio. Esto
podría ser el uso del ancho de banda en un segmento
■■ Un vínculo de las especificaciones del servicio de TI
de red, o el uso de memoria en un servidor importante.
con el rendimiento de la Infraestructura de TI
Si estos signos estuvieran dentro de los rangos
■■ Definición de los requisitos operativos de rendimiento
normales, el sistema será saludable y no requerirá una
■■ Una correspondencia de servicios y tecnología
atención adicional. Esta reducción en la necesidad de
■■ La capacidad de modelar el efecto de los cambios en monitorización exhaustiva provocará una reducción de
la tecnología y de los cambios en los requisitos de costes y que los departamentos y equipos operativos se
negocio centren en las áreas adecuadas para el éxito del servicio.
■■ Modelos apropiados de costes (p. ej., basados en el
Sin embargo, como en los organismos, es importante
cliente o en el servicio) para evaluar el Retorno de la
comprobar los sistemas más a fondo de vez en cuando
Inversión y las estrategias de reducción de costes.
para buscar problemas que no afectan inmediatamente
La naturaleza de la implicación de la Gestión de a los signos vitales. Por ejemplo, un disco podría estar
Operaciones de TI debe posicionarse detalladamente. funcionando perfectamente, pero éste podría estar
Diseño del Servicio es una fase en el Ciclo de Vida de cercano a su umbral de Tiempo Medio Entre Fallos
Gestión del Servicio que utiliza un conjunto de procesos, (MTBF). En este caso el sistema debe salir del servicio y
no una función independiente de Operación del Servicio. ser sometido a un examen en detalle o ‘comprobación
Como tal, muchas de las personas que están implicadas de estado’. Al mismo tiempo, debe destacarse que el
en el Diseño del Servicio procederán de Gestión de resultado final debe ser el funcionamiento saludable
Operaciones de TI. del servicio en sentido general. Esto significa que las
Esto no sólo se deberá estimular, sino que el personal comprobaciones de estado de los componentes deben
de Operación del Servicio debe medirse en relación con equilibrarse con respecto al servicio ‘extremo a extremo’.
su implicación en las actividades de Diseño del Servicio, La definición de lo que se necesita monitorizar y qué
y tales actividades deben incluirse en las descripciones significa estar “sano” o “enfermo”, se define durante
y roles del trabajo, etc. Esto ayudará a garantizar la el Diseño del Servicio, especialmente en Gestión de la
continuidad entre los requisitos del negocio y el diseño de Disponibilidad y SLM.
la tecnología y operación, y también ayudará a garantizar La Salud Operativa depende de la capacidad de evitar
que lo que se diseñe también se pueda operar. También incidencias y problemas invirtiendo en una infraestructura
fiable y con capacidad de mantenimiento. Esto se logra
32 | Principios de Operación del Servicio

a través de un buen diseño de la disponibilidad y de la determinar la relevancia de cada evento y también si

Gestión proactiva de problemas. Al mismo tiempo, la hay alguna respuesta predefinida con respecto a ese
Salud Operativa también depende de la capacidad de evento.
identificar fallos y localizarlos de forma eficaz para que ■■ Un conjunto de herramientas de diagnóstico, como
tengan el mínimo impacto en el servicio. Esto requiere una por ejemplo scripts de diagnóstico, árboles de fallos y
sólida Gestión de Incidencias y Problemas (preferiblemente una base de datos de Errores Conocidos y soluciones
automatizada). provisionales comunes. Éstos se utilizan en cuanto
La idea de Salud Operativa también ha conducido a un se detecta un error para determinar la respuesta
área especializada denominada ‘Sistemas de Recuperación apropiada.
Automática’. Esta es una aplicación de Gestión de la ■■ La capacidad de generar una llamada para solicitar
Disponibilidad, Capacidad, Conocimiento, Problemas e una intervención activando una alerta o generando
Incidencias, y hace referencia a un sistema que se ha una incidencia.
diseñado para resistir las condiciones de operación más Aunque el concepto de Salud Operativa no es un
severas y para detectar, diagnosticar y recuperarse de concepto esencial de Operación del Servicio, es con
la mayoría de las incidencias y Errores Conocidos. Los frecuencia una metáfora útil que contribuye a determinar
Sistemas de Recuperación Automática se conocen con lo que se necesita monitorizar y con qué frecuencia llevar
diferentes nombres, por ejemplo, Sistemas Autónomos, a cabo el mantenimiento preventivo.
Sistemas Adaptativos y Sistemas Dinámicos. Las
características de los Sistemas de Recuperación Automática Qué y cuándo monitorizar la salud operativa debe
incluyen: determinarse en Diseño del Servicio, probarse y
perfeccionarse durante Transición del Servicio, y optimizarse
■■ La capacidad de recuperación se diseña e implementa en Mejora Continua del Servicio cuando sea necesario.
en el sistema, por ejemplo, múltiples discos
redundantes o múltiples procesadores. Esto protege
al sistema contra fallos de hardware ya que podrá 3.6  Comunicación
continuar operando con el componente de hardware Es necesaria una buena comunicación con otros equipos
duplicado. y departamentos de TI, con los usuarios y los clientes
■■ La capacidad de recuperación del software, los datos internos, y entre los propios equipos y departamentos de
y el sistema operativo también se diseñan dentro del Operación del Servicio. Normalmente los problemas se
sistema, por ejemplo bases de datos en espejo (donde pueden prevenir o evitar con una comunicación adecuada.
una base de datos se duplica en un dispositivo de
Esta sección tiene por objeto resumir el proceso de
backup) y una tecnología de intercalado de discos
comunicación que debe tener lugar en Operación del
(donde los bits individuales de datos se distribuyen
Servicio. Este no es un proceso independiente, sino una
a través de un conjunto de discos, por lo que un
check-list del tipo de comunicación que se requiere para
fallo de disco genera la pérdida de sólo parte de los
lograr una Operación del Servicio eficaz.
datos, que se podrán recuperar fácilmente utilizando
algoritmos). Un principio importante es que toda la comunicación
■■ La capacidad de cambiar el procesamiento de un debe tener un propósito objetivo o una acción resultante.
dispositivo físico a otro sin ninguna interrupción del La información no deberá comunicarse a menos que
servicio. Esto podría ser en respuesta a un fallo o haya una audiencia clara. Además,, esa audiencia debe
deberse a que el dispositivo está alcanzando niveles estar activamente implicada a la hora de determinar la
elevados de uso (algunos sistemas se diseñaron necesidad de esa comunicación y lo que harán con esa
para distribuir continuadamente cargas de trabajo información.
de procesamiento para optimizar el uso de la En el Apéndice B de esta publicación se incluye una
capacidad disponible, lo que también se conoce como descripción detallada de los tipos de comunicaciones
virtualización). típicas en Operación del Servicio, junto con una
■■ Herramientas integradas de monitorización que descripción de la audiencia típica y de las acciones que se
permiten al sistema detectar eventos y determinar si pretenden tomar como resultado de cada comunicación.
éstos representan operaciones normales. Éstos incluyen:
■■ Un motor de correlación (vea el párrafo 4.1.5.6
■■ Comunicación de rutina operacional
sobre Gestión de Eventos). Esto permitirá al sistema
■■ Comunicación entre turnos
 Principios de Operación del Servicio | 33

■■ Información de rendimiento de alguno de los medios anteriores. La necesidad de

■■ Comunicación en proyectos calidad podría eliminar algunas opciones de VoIP.
■■ Comunicación asociada a los cambios ■■ Es posible utilizar cualquier medio de comunicación
■■ Comunicación asociada a las excepciones siempre que todos los implicados entiendan cómo y
■■ Comunicación asociada a las emergencias cuándo tendrá lugar la comunicación.
■■ Formación sobre nuevos procesos personalizados y 3.6.1  Reuniones
diseños del servicio
Organizaciones diferentes se comunican con métodos
■■ Comunicación de la estrategia y del diseño a los
distintos. Cuando las organizaciones están dispersas,
equipos de Operación del Servicio. tenderán a apoyarse en el correo electrónico y en
Tenga en cuenta que no hay un medio definitivo de videoconferencias. Las organizaciones que tienen
comunicación, ni existe una ubicación o frecuencia fijas. herramientas y procesos de Gestión del Servicio más
En algunas organizaciones la comunicación tiene que maduros tenderán a apoyarse en herramientas y procesos
tener lugar en reuniones. Otras organizaciones prefieren para la comunicación (p. ej., con una herramienta de
utilizar el correo electrónico o la comunicación inherente a Gestión de Incidencias para escalar y hacer el seguimiento
sus herramientas de Gestión del Servicio. de incidencias, en lugar de solicitar correos electrónicos o
llamadas telefónicas para la actualización).
Por lo tanto, debería haber una política de comunicación
dentro de cada equipo o departamento y para cada Otras organizaciones prefieren comunicarse a través de
proceso. Aunque ésta debería ser formal, la política no reuniones. Sin embargo, es importante no caer sólo en
debe ser pesada o compleja. Por ejemplo, un responsable el modo en el que se realiza el trabajo o se implica la
podría requerir que todas las comunicaciones asociadas gestión, durante las reuniones. Además, las reuniones
con cambios deban enviarse por correo electrónico. cara a cara tienden a incrementar los costes (p. ej., viajes,
Siempre y cuando esto se especifique en los SOPs del tiempo dedicado a discusiones informales, refrigerios,
departamento (o en cualquier forma en la que existan), no etc.), por lo que los organizadores de reuniones deben
hay necesidad de crear una política independiente para ello. equilibrar el valor de la reunión con el número e identidad
de los participantes y con el tiempo que dedicarán y lo
Aunque el contenido típico de la comunicación es
que tardarán en desplazarse hasta la reunión.
bastante consistente una vez que se hayan definido los
procesos, los medios de comunicación están cambiando El propósito de las reuniones es comunicar eficazmente
con cada introducción de nueva tecnología. La lista de a un grupo de personas un conjunto común de
alternativas está creciendo y, a día de hoy, incluye: objetivos o actividades. Las reuniones deben controlarse
adecuadamente y ser breves, y se deben centrar en
■■ Correo electrónico para clientes tradicionales o
facilitar la acción. Una buena regla será evitar mantener
dispositivos móviles
una reunión si la información puede comunicarse
■■ Mensajes SMS
eficientemente mediante medios automatizados.
■■ Localizadores
■■ Mensajería instantánea y webchats
Varios factores son esenciales para el éxito de las
reuniones. Aunque éstos podrían parecer de sentido
■■ Utilidades de Voz sobre IP(VoIP) que pueden hacer
común, algunas veces se desatienden:
que cualquier dispositivo conectado a la red pase a
ser un medio de comunicación barato ■■ Establecer y comunicar una agenda clara para
■■ Utilidades de teleconferencia y reuniones virtuales, que garantizar que la reunión logre su objetivo y para
han revolucionado las reuniones que ahora pueden ayudar al moderador a evitar que los participantes
celebrarse a larga distancia ‘secuestren’ la reunión.
■■ Utilidades para compartir documentos. ■■ Garantizar que se entiendan las reglas de
participación. Las organizaciones tienden a tener un
Los medios de comunicación están fuera del alcance de
conjunto formal de reglas para las reuniones que van
esta publicación. Sin embargo, deben tenerse en cuenta
de relativamente informales hasta muy formales (p. ej.,
los siguientes puntos:
Roberts Rules of Order).
■■ La comunicación es prioritaria y los medios de ■■ Hacer uso de ‘plazas de aparcamiento’ o notas
comunicación deben garantizar que dan servicio que registren asuntos que no están directamente
a este objetivo. Por ejemplo, la necesidad de relacionadas con el objetivo de la reunión, pero que
comunicaciones seguras puede eliminar la viabilidad se puedan utilizar si surge el tema.
34 | Principios de Operación del Servicio

■■ Actas de la reunión: deben establecerse normas sobre Deben recogerse las oportunidades de mejora de los
cuándo se redactan las actas. Las actas se utilizan para servicios o procesos, si surgieran, y enviarse al equipo
recordar la asignación de acciones y para realizar el responsable de Mejora Continua del Servicio.
seguimiento del progreso de las acciones delegadas.
También son útiles para garantizar que se realice el 3.6.1.2  Reuniones de departamento, grupo o
seguimiento y que se llevan a cabo las acciones y equipo
decisiones interdisciplinares.
Estas reuniones son en esencia similares a las reuniones de
■■ Usar técnicas para estimular el nivel apropiado de Operaciones, pero destinadas a un único departamento,
participación. Una técnica al discutir mejoras es, por grupo o equipo de TI. Cada responsable o supervisor
ejemplo, la técnica ‘mantener, parar, iniciar’. Se incita transmite la información de la reunión de Operaciones
a los participantes a hacer una lista de elementos que que es relevante para su equipo.
les gustaría mantener, cosas que necesitan detenerse e
iniciativas o acciones que les gustaría que se iniciaran. Además, estas reuniones también cubrirán lo siguiente:

A continuación se presentan algunos ejemplos de ■■ Una discusión más detallada de incidencias, problemas
reuniones típicas: y cambios en los que todavía se está trabajando, con
información sobre:
3.6.1.1  Las reuniones de Operaciones ●● Progreso hasta la fecha

Las reuniones de Operaciones normalmente se celebran ●● Confirmación de lo que es necesario hacer

entre los responsables y los departamentos, equipos ●● Tiempos estimados de finalización

o grupos operativos de TI al comienzo de cada ●● Solicitud de recursos adicionales, si se requiere
semana o día laborable. El propósito de este tipo de ●● Discusión de posibles problemas o inquietudes
reuniones es hacer que el personal sea consciente de ■■ Confirmación de la disponibilidad del personal para
cualquier asunto relevante para Operaciones (como por atender a sus responsabilidades
ejemplo planificación de cambios, eventos de negocio, ■■ Confirmación de la planificación de vacaciones.
planificación de mantenimiento, etc.) y para proporcionar
una oportunidad al personal para que ponga encima de 3.6.1.3  Reuniones con el cliente
la mesa cualquier problema del que sean conscientes.
Será necesario mantener periódicamente reuniones con
Esta es una oportunidad para garantizar que todos los
los clientes, además de las reuniones regulares de Revisión
departamentos del centro de datos estén alineados.
del Nivel de Servicio. Algunos ejemplos:
En organizaciones dispersas geográficamente puede que
■■ Seguimiento después de incidencias graves. El
no sea posible tener una reunión diaria de Operaciones.
propósito de estas reuniones es restaurar la relación
En estos casos, es importante coordinar la agenda de
con los clientes, pero también garantizar que TI
las reuniones y garantizar que cada reunión tenga dos
tenga toda la información que se requiere para
componentes:
evitar recurrencias. Los clientes también tienen la
1 La primera parte de la reunión cubrirá aspectos que se oportunidad de proporcionar información sobre
apliquen a la organización en su conjunto, p. ej., nuevas impactos imprevistos en el negocio. Estas reuniones
políticas, cambios que afectan a todas las regiones y son útiles para acordar acciones que se deberán
eventos de negocio que abarcan todas las regiones. ejecutar para tipos similares de incidencias que
2 La segunda parte de la reunión cubrirá aspectos que pudieran producirse en el futuro.
se aplican sólo a la región local, p. ej., planificaciones ■■ Un foro de clientes que se puede utilizar para hacer
de operaciones locales, cambios en la infraestructura propuestas, lo que incluiría probar ideas para nuevos
local, etc. servicios o soluciones, o reunir requisitos para servicios
Las reuniones de Operaciones normalmente están dirigidas o procedimientos nuevos o revisados. Un foro de
por el Responsable de Operaciones de TI o por un clientes es generalmente una reunión regular con los
Responsable de Operaciones senior y asistirán a ella todos clientes para analizar áreas de preocupación común.
los responsables y supervisores (excepto aquellos cuyo
turno no esté operativo). También es útil tener al menos 3.7  Documentación
un representante del Centro de Servicio al Usuario en la
Gestión de Operaciones de TI y todos los equipos y
reunión para que sean conscientes de cualquier situación
departamentos de Gestión Técnica y de Aplicaciones están
que pudiera ocasionar incidencias.
implicados en la creación y mantenimiento de una serie
 Principios de Operación del Servicio | 35

de documentos. Éstos se detallan en el Capítulo 4, 5 y 6

de esta publicación e incluyen lo siguiente:
■■ Participación en la definición y mantenimiento de
manuales para todos los procesos en los que están
implicados. Éstos incluyen procesos y otras fases del
Ciclo de Vida de Gestión del Servicio de TI (p. ej.,
Gestión de la Capacidad, Gestión de Cambios, Gestión
de la Disponibilidad) además de todos los procesos
incluidos en la fase de Operación del Servicio.
■■ Establecer sus propios manuales de procedimientos
técnicos. Éstos deben mantenerse actualizados y se
debe añadir nuevo material que pudiera ser relevante
utilizando el Control de Cambios. Se debe recordar
que sus procedimientos siempre deben estructurarse
para cumplir los objetivos y restricciones definidos
dentro de los procesos de mayor nivel de Gestión del
Servicio, como SLM. Por ejemplo, un procedimiento
técnico para gestionar servidores siempre garantizará
el logro de los niveles de disponibilidad y rendimiento
acordados en los Acuerdos de Nivel Operativo y en los
Acuerdos de Nivel de Servicio (SLAs).
■■ Participación en la creación y mantenimiento de
documentos de planificación, p. ej., los Planes
de Disponibilidad y Capacidad, y los Planes de
Continuidad de los Servicios de TI.
■■ Participación en la creación y mantenimiento de la
Cartera de Servicios. Esto incluirá la cuantificación de
costes y el establecimiento de la viabilidad operativa
de cada servicio propuesto.
■■ Participación en la definición y mantenimiento de las
instrucciones de trabajo de la herramienta de Gestión
del Servicio para cumplir requisitos de generación de
informes.
Procesos de Operación
del Servicio 4
 | 39

4 Procesos de Operación del Servicio

Los procesos que se listan en el párrafo 2.4.5 se analizan sistema de Gestión de Incidencias, pero otras podrían
con detalle en este capítulo. Como referencia, se describirá elegir (debido a su elevado volumen o a la prioridad
brevemente la estructura general y posteriormente se de negocio de tales peticiones) facilitar la provisión
describirá con más detalle cada uno de los procesos. independiente de las capacidades de Gestión de
Tenga en cuenta que los roles y las herramientas que se Peticiones a través del proceso de Gestión de
emplean para cada proceso se describen en los Capítulos Peticiones. Se ha convertido en una práctica popular
6 y 7 respectivamente. usar un proceso formal de Gestión de Peticiones para
gestionar peticiones de clientes y usuarios de todo
■■ Gestión de Eventos es el proceso que monitoriza
tipo que incluyen, instalaciones, cambios y suministros
todos los eventos que pueden producirse en la
además de aquellas específicas de los servicios de TI.
infraestructura de TI para permitir la operación normal
Estas peticiones generalmente no están ligadas a las
y para detectar y escalar estados de excepción.
mismas medidas de SLA y separar los registros y el
■■ Gestión de Incidencias se concentra en restaurar el
flujo del proceso está surgiendo como Mejor Práctica
servicio a los usuarios lo más rápidamente posible
en muchas organizaciones.
para minimizar el impacto en el negocio.
■■ Gestión del Acceso: es el proceso de concesión
■■ Gestión de Problemas implica el análisis de la causa
del derecho de uso de un servicio a los usuarios
raíz para determinar y resolver la causa de los eventos e
autorizados mientras que se restringe el acceso a otros
incidencias, actividades proactivas para detectar y evitar
usuarios no autorizados. Se basa en la capacidad para
futuros problemas/incidencias, y un subproceso de
identificar de forma precisa a los usuarios autorizados
Errores Conocidos que permita acelerar el diagnóstico y
y posteriormente gestionar su capacidad de acceso
resolución si se producen incidencias posteriores.
a servicios cuando se requiera durante diferentes
NOTA: Sin esta distinción entre incidencias y etapas de su ciclo de vida contractual o de Recursos
problemas, y sin mantener Registros de Incidencias y Humanos (RRHH). La Gestión del Acceso también
Problemas independientes, habría riesgo de que: ha sido denominada como Gestión de Derechos o
●● Las incidencias se cierren demasiado pronto en el Gestión de Identidades en algunas organizaciones.
ciclo de soporte general y no se tomen acciones Además, existen muchos otros procesos que se ejecutarán
que eviten su recurrencia, por lo que las mismas o soportarán durante Operación del Servicio, pero que se
incidencias tendrían que solucionarse una y otra impulsan durante otras fases del Ciclo de Vida de Gestión
vez, o del Servicio. Los aspectos operativos de estos procesos se
●● Las incidencias se mantendrían abiertas para que analizarán en la parte final de este capítulo e incluyen:
se pudiera realizar un análisis de la causa raíz,
■■ Gestión del Cambio, que es un proceso importante
y se perdería su visibilidad cuando se restaurara
realmente el servicio al usuario, por lo que se que podría vincularse estrechamente con la Gestión de
podrían incumplir los objetivos del SLA incluso la Configuración y con la Gestión de la Entrega. Estos
cuando el servicio se hubiera restaurado conforme temas se recogen principalmente en la publicación
a las expectativas de los usuarios. Con frecuencia Transición del Servicio.
esto genera un gran número de incidencias ■■ Gestión de la Capacidad y de la Disponibilidad, cuyos
abiertas, muchas de las cuales nunca se cerrarían a aspectos operativos se incluyen en esta publicación,
menos que se emprendiera una ‘purga’ periódica. pero que están recogidos con más detalle en la
Esto puede ser muy desmotivador y podría evitar publicación Diseño del Servicio.
disponer de una visibilidad eficaz de los problemas ■■ Gestión Financiera, que se recoge en la publicación
actuales. Estrategia del Servicio.
■■ Gestión del Conocimiento, que se recoge en la
■■ Gestión de Peticiones implica la gestión de
publicación Transición del Servicio.
peticiones de clientes o usuarios que no se generaron
como una incidencia por el retraso o fallo inesperado ■■ Continuidad del Servicio de TI, que se recoge en la
de un servicio. Algunas organizaciones pueden elegir publicación Diseño del Servicio.
manejar tales peticiones como una ‘categoría’ de ■■ Medición e Informes del Servicio, que se recogen en la
incidencias y gestionar la información a través de un publicación Mejora Continua del Servicio.
40 | Procesos de Operación del Servicio

4.1  Gestión de Eventos ■■ Elementos de Configuración:

●● Se incluirán algunos CI ya que éstos deben
Un evento se puede definir como hecho detectable o
permanecer en un determinado estado (p. ej., un
discernible que tiene relevancia para la gestión de la
switch en una red necesita estar operativo y las
Infraestructura de TI o para la entrega del servicio de TI, y
herramientas de Gestión de Eventos confirman este
para la evaluación del impacto que una desviación podría
hecho monitorizando respuestas a ‘pings’).
provocar en los servicios. Los eventos son habitualmente
●● Se incluirán algunos CI porque su estado necesita
notificaciones generadas por un servicio de TI, Elemento
de Configuración (CI) o herramienta de monitorización. cambiar frecuentemente. Gestión de Eventos puede
servir para automatizar esto y actualizar el CMS (p.
La Operación eficaz del servicio dependerá del grado ej., la actualización de un servidor de archivos).
de conocimiento del estado de la infraestructura y de ■■ Condiciones ambientales (p. ej., detección de
la detección de cualquier desviación de una operación incendios y humos)
normal o esperada. Unos buenos sistemas de control y
■■ Monitorización de las licencias de software para
monitorización facilitan esta situación, que se basa en dos
garantizar el uso y ubicación óptimos/legales de las
tipos de herramientas:
licencias
■■ herramientas de monitorización activa que realizan un ■■ Seguridad (p. ej., detección de intrusiones)
muestreo de los CI clave para determinar su estado ■■ Actividad normal (p. ej., seguimiento del uso de una
y disponibilidad. Cualquier excepción generará un aplicación o rendimiento de un servidor).
alerta que será necesario comunicar a la herramienta o
equipo apropiado para adoptar una acción. La diferencia entre Monitorización y Gestión de
■■ herramientas de monitorización pasiva que detectan y Eventos
asocian alertas o comunicaciones operativas generadas Estas dos áreas están íntimamente relacionadas
por los CIs. aunque son ligeramente diferentes por su naturaleza.
Gestión de Eventos se centra en la generación y
4.1.1  Propósito/meta/objetivo detección de notificaciones significativas sobre el
Gestión de eventos ofrece la capacidad de detectar estado de los servicios e Infraestructura de TI.
eventos, darles sentido y determinar la acción de control
Aunque es cierto que la monitorización es necesaria
apropiada. Por lo tanto, Gestión de Eventos es la base para
para detectar y hacer el seguimiento de estas
la Monitorización y Control Operativo (vea el Apéndice B).
notificaciones, monitorizar es un término más amplio
Además, si se programan estos eventos para comunicar que Gestión de Eventos. Por ejemplo, las herramientas
información operativa además de advertencias y de monitorización comprobarán el estado de un
excepciones, éstos se podrán utilizar como base para dispositivo para garantizar que esté operando dentro
automatizar muchas actividades rutinarias de Gestión de de los límites aceptables, incluso si ese dispositivo no
Operaciones, por ejemplo ejecutar scripts en dispositivos estuviera generando eventos.
remotos, o enviar jobs para su procesamiento, o incluso
De una forma más simple, Gestión de Eventos trabaja
equilibrar dinámicamente la demanda para un servicio a
con eventos que se generan específicamente para ser
través de múltiples dispositivos para mejorar el rendimiento.
monitorizados. La monitorización hace un seguimiento
Por lo tanto, Gestión de Eventos proporciona el punto de estos eventos, pero también busca activamente
de entrada para la ejecución de muchos procesos condiciones que no los generan.
y actividades de Operación del Servicio. Además,
proporciona una forma de comparación del rendimiento 4.1.3  Valor para el negocio
y comportamiento reales con respecto a los estándares
El valor de Gestión de Eventos para el negocio es
de diseño y SLAs. Así pues, Gestión de Eventos también
generalmente indirecto; sin embargo, es posible
proporciona una base para el aseguramiento del Servicio
determinar la base para su valor de la siguiente forma:
e Informes, para la Mejora del Servicio. Esto se recoge con
detalle en la publicación de Mejora Continua del Servicio. ■■ Gestión de Eventos provee mecanismos para la
detección anticipada de incidencias. En muchos
4.1.2  Ámbito casos es posible detectar y asignar la incidencia al
Gestión de Eventos puede aplicarse a cualquier aspecto grupo adecuado para tomar acciones antes de que se
de Gestión del Servicio que sea necesario controlar y que produzca cualquier interrupción real del servicio.
pueda automatizarse. Éstos incluyen:
 Procesos de Operación del Servicio | 41

■■ Gestión de Eventos posibilita la monitorización de ■■ Eventos que implican una operación inusual pero
algunos tipos de actividades automatizadas mediante no excepcional. Éstos representan una señal de
excepciones, por lo que se elimina la necesidad de que la situación podría requerir una monitorización
una monitorización de recursos cara e intensiva en más intensa. En algunos casos esta condición se
tiempo real, mientras que se reduce el tiempo de resolverá automáticamente, por ejemplo, en el caso
caída. de una combinación inusual de cargas de trabajo,
■■ Cuando se integra en otros procesos de Gestión la operación normal se restaurará cuando éstas
del Servicio (como por ejemplo, Gestión de la se completen. En otros casos, podría requerirse
Disponibilidad o Gestión de la Capacidad), Gestión la intervención de un operador si la situación se
de Eventos puede señalar cambios de estado o repitiese o si continuara durante demasiado tiempo.
excepciones que permitan a la persona o equipo Estas reglas o políticas se definen en los Objetivos
apropiado aplicar una respuesta anticipada, con lo que de Monitorización y Control para ese dispositivo o
se mejoraría el rendimiento del proceso. A su vez, esto servicio. A continuación se presentan algunos ejemplos
permitirá al negocio beneficiarse de una Gestión del de este tipo de eventos:
Servicio más eficaz y eficiente. ●● El uso de la memoria de un servidor se acerca al
■■ Gestión de Eventos proporciona una base para realizar 5% de su nivel de rendimiento más alto aceptable
operaciones automatizadas, por lo que se aumenta ●● El tiempo de duración de una transacción es un
la eficiencia y permite asignan íos recursos humanos 10% mayor de lo normal.
más costosos a trabajos más innovadores, como por
Se destacan dos aspectos en relación con los ejemplos
ejemplo la definición de una funcionalidad mejorada o
anteriores:
nueva, o la definición de nuevas formas con las que el
negocio pueda explotar la tecnología para conseguir ■■ ¿Qué constituye exactamente una operación inusual
aumentar su ventaja competitiva. en comparación con una normal y frente a una
excepción? No hay ninguna regla definitiva sobre esto.
4.1.4 Políticas/principios/conceptos básicos Por ejemplo, un fabricante podría determinar que el
Existen muchos tipos diferentes de eventos, por ejemplo: benchmark del 75% del uso de la memoria es óptima
para la aplicación X. Sin embargo, se ha descubierto
■■ Eventos que implican una operación regular: que, bajo las condiciones específicas de nuestra
●●notificación de que una carga de trabajo organización, los tiempos de respuesta comienzan a
programada ha finalizado degradarse por encima del 70% de uso. La siguiente
●● un usuario se ha registrado para utilizar una sección analizará cómo se determinan estas cifras.
aplicación ■■ Cada uno cuenta con el envío y recepción de un
●● un correo electrónico ha llegado hasta su mensaje de algún tipo. Generalmente se les denomina
destinatario. notificaciones de Eventos y no se generan sin motivo.
■■ Eventos que implican una excepción Los siguientes párrafos analizarán exactamente cómo
●● un usuario intenta iniciar sesión en una aplicación se definen, generan y capturan los eventos.
con la contraseña incorrecta
●● se ha producido una situación inusual en un
proceso de negocio que podría indicar una
excepción que requiere una investigación de
negocio posterior (p. ej., una alerta de la página
web indica que un sitio de autorización de pagos
no está disponible, lo que impacta a la aprobación
financiera de transacciones de negocio)
●● la CPU de un dispositivo está por encima de la
tasa de uso aceptable
●● el escaneo de un PC descubre una instalación de
software no autorizado.
42 | Procesos de Operación del Servicio

Evento

Generación de
Notificación
de Evento

Detección del
Evento

Filtrado del Evento

Informativo ¿Significado? Excepción

Advertencia

Correlación del Evento

Disparador

¿Incidencia
Registro del Evento Respuesta Alerta Problema/
Automática Incidencia Cambio? Cambio

Problema

Intervención Gestión Gestión Gestión

Humana de Incidencias de Problemas de Cambios

Revisar Acciones

No
¡Eficaz?

Sí

Cerrar Evento

Fin Figura 4.1 El Proceso de Gestión

de Eventos
 Procesos de Operación del Servicio | 43

4.1.5  Actividades, métodos y técnicas del cada tipo de CI. Durante la Transición del Servicio, se
proceso establecerían y probarían las opciones de generación de
eventos.
La Figura 4.1 es una representación genérica y de alto
nivel de Gestión de Eventos. Se puede usar como punto Sin embargo, en muchas organizaciones, la definición
de referencia y definición, más que como un diagrama de los eventos que se generarán se realiza mediante el
de flujo real de la Gestión de Eventos. A continuación se sistema de prueba y error. Los responsables del sistema
describen las actividades de este proceso. usan un conjunto estándar de eventos como punto
de partida y a continuación ajustan el CI a lo largo del
4.1.5.1  Generación del evento tiempo para incluir o excluir eventos según se requiera.
Los eventos se producen continuamente, pero no todos El problema de este método es que sólo tiene en cuenta
ellos se detectan o registran. Por lo tanto, es importante las necesidades inmediatas del personal que gestiona el
que todos los implicados en el diseño, desarrollo, gestión dispositivo y no facilita una buena planificación o mejora.
y soporte de servicios de TI y de la Infraestructura de Por otra parte, dificulta mucho la monitorización y la
TI que utilizan eventos, entiendan los tipos que será gestión del servicio con respecto a todos los dispositivos
necesario detectar. y al personal. Un método para mitigar este problema
sería revisar el conjunto de eventos como parte de las
Esto se analiza en el párrafo 4.1.10.1, titulado actividades de mejora continua.
‘Instrumentación’.
Un principio general de notificación de eventos consiste
en que mientras más importantes sean los datos que
4.1.5.2  Notificación de eventos
contiene y mayor sea la audiencia objetivo, más fácil
La mayoría de los CI están diseñados para transmitir cierta será la toma de decisiones sobre el evento. A menudo
información sobre ellos mismos de alguna de las dos los operadores se enfrentan con mensajes de error
formas siguientes: codificados y no saben cómo abordarlos o qué hacer
■■ Una herramienta de gestión que recopila ciertos datos con ellos. Unos datos de notificación significativos y unos
específicos interroga a un dispositivo. Frecuentemente roles y responsabilidades definidos claramente tienen que
se hace referencia a esto como muestreo. articularse y documentarse durante el Diseño del Servicio
■■ El CI genera una notificación cuando se cumplen y Transición del Servicio (vea también el párrafo 4.1.10.1
ciertas condiciones. La capacidad para generar estas en ‘Instrumentación’). Si no se definen claramente los
notificaciones tiene que diseñarse y crearse dentro del roles y responsabilidades, nadie sabrá quién está haciendo
CI, por ejemplo un gancho de programación incluido qué y esto puede conducir a errores o a duplicidades de
en una aplicación. esfuerzos.

Las notificaciones de eventos pueden ser propietarias, en 4.1.5.3  Detección de eventos

cuyo caso sólo se podrán utilizar las propias herramientas
Una vez se haya generado una notificación de Evento,
de gestión del fabricante para detectar eventos. Sin
ésta será detectada mediante un agente que corre en el
embargo, la mayoría de CIs generan notificaciones de
mismo sistema, o será transmitida directamente a una
eventos usando un estándar abierto, como por ejemplo
herramienta de gestión específicamente diseñada para leer
SNMP (Simple Network Management Protocol).
e interpretar el significado del evento.
Muchos CI se configuran para generar un conjunto
estándar de eventos basándose en la experiencia del 4.1.5.4  Filtrado de eventos
desarrollador de lo que se requiere para operar el CI, con El propósito del filtrado es decidir si es necesario
la capacidad de generar tipos adicionales de eventos comunicar el evento a una herramienta de gestión o
‘activando’ el mecanismo pertinente de generación ignorarlo. Si se ignora, el evento normalmente se registrará
de eventos. Para otros tipos de CI, se tendrá que en el dispositivo, en un archivo de registro, pero no se
instalar alguna forma de software ‘agente’ para iniciar tomarán acciones posteriores.
la monitorización. Normalmente esta funcionalidad de
monitorización es gratuita, pero algunas veces existe un La razón de llevar a cabo el filtrado es que no siempre
coste asociado a la licencia de la herramienta. será posible desactivar la notificación de eventos, incluso
cuando se haya tomado la decisión de que no es
En un mundo ideal, el proceso Diseño del Servicio necesario generar ese tipo de eventos. También se podría
debe definir los eventos que es necesario generar y a decidir que sólo se transmita la primera de una serie de
continuación debe especificar cómo llevarlo a cabo para notificaciones de eventos repetitivos.
44 | Procesos de Operación del Servicio

El primer nivel de correlación se realizará durante Una buena regla consiste en que todos los fallos
el filtrado, es decir, se determinará si el evento es deben tratarse como una excepción, debido a que
informativo, una advertencia, o una excepción (vea el el riesgo de que una incidencia afecte al negocio es
siguiente paso). Esta correlación se realiza normalmente a mucho mayor. Ejemplos de advertencias:
través de un agente que reside en el CI o en un servidor al ●● El grado de utilización de la memoria en un
que el CI se conecta. servidor se encuentra actualmente al 65% y está
El paso de filtrado no siempre es necesario. Para aumentando. Si alcanzara el 75%, los tiempos
algunos CI, todos los eventos son importantes y de respuesta serían inaceptablemente largos y se
pasan directamente hacia el motor de correlación de podría incumplir el OLA para ese departamento.
una herramienta de gestión, incluso si el evento está ●● La tasa de colisiones en una red se ha
duplicado. Además, se podrían desactivar todas las incrementado en un 15% durante la última hora.
notificaciones de eventos no deseadas. ■■ Excepción: Una excepción significa que un servicio o
dispositivo está actualmente operando anormalmente
4.1.5.5  Relevancia de los eventos (aunque esto se haya definido). Habitualmente esto
Cada organización tendrá su propia categorización significa que se ha incumplido un OLA o SLA y
de la relevancia de un evento, pero se sugiere que se esto está generando un impacto en el negocio. Las
consideren al menos estas tres categorías: excepciones pueden representar un fallo total, una
funcionalidad deteriorada o un rendimiento degradado.
■■ Informativo: Hace referencia a un evento que no Sin embargo, tenga en cuenta que una excepción no
requiere ninguna acción y que no representa una siempre representa una incidencia. Por ejemplo, una
excepción. Éstos se almacenan típicamente en los excepción puede generarse al descubrirse un dispositivo
archivos de registro del sistema o servicio y se sin autorización en la red. Esto se puede gestionar
mantienen allí durante un periodo predeterminado. usando un Registro de Incidencia o una Solicitud de
Los eventos informativos se utilizan típicamente para Cambio (o incluso ambos), dependiendo de las políticas
comprobar el estado de un dispositivo o servicio, de Gestión de Incidencias y Cambios. A continuación se
o para confirmar el resultado satisfactorio de una muestran ejemplos de excepciones:
actividad. Los eventos informativos también se ●● Un servidor se ha caído
pueden utilizar para generar estadísticas (como por
●● El tiempo de respuesta de una transacción
ejemplo el número de usuarios conectados en una
estándar a través de la red se ha ralentizado a más
aplicación durante un cierto periodo de tiempo) y
de 15 segundos
como entrada en investigaciones (como por ejemplo
●● Más de 150 usuarios se han conectado
qué jobs han finalizado satisfactoriamente antes de un
simultáneamente en la aplicación contable Libro
fallo en la cola de procesamiento de transacciones).
Mayor
A continuación se muestran algunos ejemplos de
●● Un segmento de la red no está respondiendo a
eventos informativos:
solicitudes rutinarias.
●● Un usuario inicia sesión en una aplicación
●● Un trabajo en la cola de lotes se completa
4.1.5.6  Correlación de eventos
satisfactoriamente
Si un evento fuera relevante, tendrá que adoptarse una
●● Un dispositivo ha pasado a estar online
decisión sobre la relevancia exacta y qué acciones se
●● Una transacción se completó satisfactoriamente.
deben realizar para abordarlo. Es aquí donde se determina
■■ Advertencia: Una advertencia es un evento que
el significado del evento.
se genera cuando un servicio o dispositivo se está
aproximando a un umbral. Las advertencias tienen La correlación normalmente se realiza mediante un ‘Motor
como objetivo enviar una notificación a la persona, de Correlación’ que normalmente forma parte de una
proceso o herramienta adecuada, de tal forma que se herramienta de gestión que compara el evento con un
pueda comprobar la situación y se pueda adoptar una conjunto de criterios y reglas en un orden prefijado. Estos
acción para evitar una excepción. Las advertencias no criterios normalmente se denominan Reglas de Negocio,
surgen normalmente por el fallo de un dispositivo. A aunque generalmente son bastante técnicos. La idea es
pesar de todo, existe algún debate sobre si el fallo de que el evento puede implicar algún impacto sobre el
un dispositivo redundante es una advertencia o una negocio y las reglas puedan servir para determinar el nivel
excepción (ya que el servicio todavía está disponible). y tipo de impacto en el mismo.
 Procesos de Operación del Servicio | 45

Un Motor de Correlación se programa de acuerdo con los ■■ Disparadores de bases de datos que restringen el
estándares de rendimiento creados durante el Diseño del acceso de un usuario a registros o campos específicos,
Servicio y con cualquier guía adicional específica para el o que crean o eliminan entradas en la base de datos.
entorno de operación.
A continuación se muestran ejemplos de lo que los
4.1.5.8  Selección de respuestas
Motores de Correlación tendrán en cuenta: En este punto del proceso, existen varias opciones de
respuesta. Es importante tener en cuenta que las opciones
■■ Número de eventos similares (p. ej., esta es la tercera
de respuesta pueden elegirse en cualquier combinación.
vez que el mismo usuario ha intentado conectarse Por ejemplo, podría ser necesario preservar la entrada
con la contraseña incorrecta; una aplicación informa de registro como referencia en el futuro, pero al mismo
que se ha producido un patrón inusual de uso de un tiempo escalar el evento a un miembro del personal de
teléfono móvil que podría indicar que el dispositivo se Gestión de Operaciones para iniciar acciones.
ha perdido o ha sido robado)
■■ Varios CI generan eventos similares Las opciones en el diagrama de flujo son ejemplos.
Distintas organizaciones tendrán diferentes opciones, y
■■ Si una acción específica está asociada al código o a
sin duda serán más detalladas. Por ejemplo, habrá un
los datos en el evento
rango de respuestas automáticas para cada tecnología
■■ Si el evento representa una excepción
diferente. Este diagrama de flujo no representa el proceso
■■ Una comparación de información del nivel de uso en que se utiliza para determinar cuál es la apropiada y cómo
el evento con un estándar mínimo o máximo (p. ej., ejecutarla. Algunas de las opciones disponibles son:
¿el dispositivo ha superado un umbral?)
■■ Si se requieren datos adicionales para, posteriormente, ■■ Evento registrado: Independientemente de la
investigar el evento y posiblemente incluso hacer una actividad que se realice, será una buena idea
recopilación de esos datos consultando otro sistema o disponer de un registro de eventos y de cualquier
base de datos acción posterior. El evento puede registrarse como
un Registro de Eventos en la herramienta Gestión de
■■ Categorización del evento
Eventos, o simplemente se puede dejar como una
■■ Asignación de un nivel de prioridad al evento.
entrada en el registro del sistema del dispositivo o
de la aplicación que generó el evento. Aunque, si
4.1.5.7  Disparador
éste fuera el caso, sería necesario que hubiera una
Se requerirá una respuesta si la actividad de correlación orden permanente para que el personal adecuado
llegara a reconocer un evento. El mecanismo que se utiliza de Gestión de Operaciones compruebe los registros
para iniciar la respuesta se denomina disparador. regularmente, con instrucciones claras sobre cómo
Existen muchos tipos de disparadores diferentes, cada uno usar cada registro. También debe recordarse que la
diseñado específicamente para la tarea que se tiene que información de los eventos en los registros puede
iniciar. Algunos ejemplos incluyen: no tener sentido hasta que se haya producido una
incidencia; y que el personal de Gestión Técnica
■■ Disparadores de Incidencias que generan un registro
use los registros para investigar dónde se originó la
en el sistema de Gestión de Incidencias, iniciando así incidencia. Esto significa que es necesario que los
el proceso de Gestión de Incidencias procedimientos de Gestión de Eventos para cada
■■ Disparadores de Cambios que generan una Petición de sistema o equipo definan estándares que indiquen
Cambio (RFC), iniciando así el proceso de Gestión de cuánto tiempo deben mantenerse los eventos en los
Cambios registros antes de que se archiven y eliminen.
■■ Un disparador que resulta de una RFC aprobada que ■■ Respuesta automática: Algunos eventos se entienden
se ha implementado pero que provocó el evento, o lo suficientemente bien como para que la respuesta
de un cambio no autorizado que se ha detectado. En apropiada ya haya sido definida y automatizada.
cualquier caso se consultará con Gestión de Cambios Esto normalmente es el resultado de un buen diseño
para su investigación o de la experiencia previa (normalmente Gestión
■■ Scripts que ejecutan acciones específicas, como por de Problemas). El disparador iniciará la acción
ejemplo el envío de trabajos por lotes o el reinicio de y a continuación evaluará si se ha completado
un dispositivo satisfactoriamente. Si no fuera así, se creará un
■■ Sistemas de búsqueda que notificarán el evento a una Registro de Incidencia o Problema. A continuación se
persona o equipo a través de teléfono móvil muestran ejemplos de respuestas automáticas:
46 | Procesos de Operación del Servicio

●● Reinicio de un dispositivo ●● Cuando se produce una excepción: Por ejemplo,

●● Reinicio de un servicio el escaneo de un segmento de red revela que
●● Envío de un trabajo por lotes se han añadido dos dispositivos nuevos sin la
●● Cambio de un parámetro en un dispositivo
autorización pertinente. Una forma de abordar
esta situación es abrir una RFC que pueda servir
●● Bloqueo de un dispositivo o aplicación para
como vehículo para que el proceso de Gestión de
protegerlo contra el acceso sin autorización.
Cambios aborde la excepción (como alternativa
Nota: el bloqueo de un dispositivo podría ocasionar
al método más convencional de apertura de una
una denegación del servicio a usuarios autorizados,
incidencia que se encaminará a través del Centro
lo que podría ser aprovechado por un atacante
de Servicio al Usuario hacia Gestión de Cambios).
intencionado. Esta es la razón por la que deben
Aquí será conveniente la investigación de Gestión
adoptarse las máximas precauciones al decidir si
de Cambios debido a que los cambios sin
ésta es o no una acción adecuada. Si se utilizara esta
autorización implican que el proceso de Gestión
repuesta, podría ser prudente combinarla también
de Cambios no ha sido eficaz.
con una solicitud de intervención humana para que la
●● La correlación identifica que se requiere un
acción automatizada se pueda comprobar y aprobar
cambio: En este caso la actividad de correlación
rápidamente.
de eventos determina que la respuesta apropiada
■■ Alerta e intervención humana: Si el evento requiere
a un evento es que se cambie algo. Por ejemplo,
intervención humana, será necesario escalarlo. El
se ha alcanzado un umbral de rendimiento y se
propósito del alerta es garantizar que se avise a la
tiene que ajustar un parámetro en un servidor
persona que disponga de las habilidades necesarias
principal. ¿Cómo decide esto la actividad de
para abordar el evento. El alerta contendrá toda la
correlación? Porque se ha programado en este
información necesaria para que esa persona determine
sentido en el proceso de Diseño del Servicio o
la acción adecuada a llevar a cabo– incluyendo la
porque este hecho se ha producido antes, y la
referencia a cualquier documentación necesaria (p.
Gestión de Problemas o la Gestión de Operaciones
ej., manuales de usuario). Es importante tener en
actualizaron el Motor de Correlación para realizar
cuenta que no es necesariamente lo mismo que el
dicha acción.
escalado funcional de una incidencia, donde el énfasis
■■ Abrir un Registro de la Incidencia: Como en el
está en la restauración del servicio dentro del tiempo
caso de una RFC, se puede generar una incidencia
acordado (lo que puede requerir una gran variedad
inmediatamente cuando se detecta una excepción,
de actividades). El alerta requiere que una persona o
o cuando el Motor de Correlación determina que un
equipo realice una acción específica, posiblemente en
tipo específico o combinación de eventos representa
un dispositivo específico y en un momento específico,
una incidencia. Cuando se abre un Registro de
p. ej., cambiar el cartucho de toner de una impresora
Incidencia, deberá incluirse la máxima información
cuando el nivel esté bajo.
posible, con vínculos a los eventos referidos y, si fuera
■■ ¿Incidencia, problema o cambio? Algunos eventos
posible, con un script para el diagnóstico completado.
representarán una situación en la que la respuesta
■■ Abrir o vincular a un Registro de Problemas: No
apropiada necesitará ser gestionada a través del
es frecuente abrir un Registro de Problemas sin
proceso de Gestión de Incidencias, Problemas o
incidencias asociadas (por ejemplo, como resultado de
Cambios. Estos eventos se discuten a continuación,
un Análisis de Fallos del Servicio (vea la publicación
pero es importante tener en cuenta que una única
Diseño del Servicio) o de una evaluación de la
incidencia podría iniciar cualquiera o una combinación
madurez, o debido a un gran número de errores de
de estos tres procesos, por ejemplo, un fallo no crítico
reintentos en red, incluso cuando todavía no se haya
de un servidor se registra como una incidencia, pero
producido un fallo). En la mayoría de los casos, este
como no existe una solución provisional, se creará un
paso implica vincular una incidencia a un Registro de
Registro de Problema para determinar la causa raíz y
Problema existente. Esto ayudará a los equipos de
la forma de solución, también se creará una RFC para
Gestión de Problemas a reevaluar la severidad y el
reubicar la carga de trabajo en un servidor alternativo
impacto del problema, que podría generar un cambio
mientras se resuelve el problema.
de la prioridad en un problema pendiente.
■■ Abrir una RFC: Existen dos momentos en el proceso
de Gestión de Eventos donde se puede crear una RFC: ■■ Sin embargo, es posible evaluar el impacto de las
incidencias con algunas de las herramientas más
 Procesos de Operación del Servicio | 47

sofisticadas y también generar un Registro de La Revisión también servirá como entrada en la mejora
Problema automáticamente, donde se garantice que continua y en la evaluación y auditoría del proceso de
pueda iniciarse inmediatamente el análisis de la causa Gestión de Eventos.
raíz.
■■ Tipos especiales de incidencia: En algunos casos,
4.1.5.10  Cerrar evento
un evento indicará una excepción que no impacta Algunos eventos permanecerán abiertos hasta que tenga
directamente en los servicios de TI, por ejemplo, el lugar una cierta acción, por ejemplo, un evento que
fallo de una unidad de aire acondicionado redundante, se vinculó a una incidencia que aún sigue abierta. Sin
o una entrada sin autorización a un centro de datos. embargo, la mayoría de los eventos no están ‘abiertos’ o
Las directrices para estos eventos son las siguientes: ‘cerrados’.
●● Deberá registrarse una incidencia mediante el uso Los eventos informativos simplemente se registran y
de un Modelo de Incidencias que sea apropiado posteriormente se utilizan como entrada para otros
para ese tipo de excepción, p. ej., una Incidencia procesos, como por ejemplo Gestión del Almacenamiento
de Operaciones o una Incidencia de Seguridad (vea y Backup. Los eventos de respuesta automática
el párrafo 4.2.4.2 para disponer de más detalles normalmente serán cerrados por la generación de un
sobre los Modelos de Incidencias). segundo evento. Por ejemplo, un dispositivo genera
●● La incidencia deberá escalarse al grupo que un evento y se reinicia a través de una respuesta
gestione ese tipo de incidencias. automática. Tan pronto como el dispositivo vuelva a estar
●● Cuando no hay interrupción, el Modelo de satisfactoriamente online, generará un evento que cierre
Incidencias empleado deberá reflejar que éste era de forma efectiva el bucle y limpie el primer evento.
un caso operativo más que un caso de servicio. A veces es muy difícil relacionar el evento abierto y las
Normalmente las estadísticas no se comunicarán notificaciones cerradas debido a que están en formatos
a los clientes o usuarios, a menos que se puedan diferentes. Sería muy conveniente que los dispositivos de
utilizar para demostrar que el dinero invertido en la infraestructura generen eventos ‘de apertura’ y “cierre”
redundancias ha sido una buena inversión. en el mismo formato y especifiquen el cambio de estado.
●● Estas incidencias no deberán utilizarse para Esto permitirá que la correlación haga que se realice
calcular el tiempo de caída pero podrán servir fácilmente la correspondencia entre las notificaciones
para demostrar el grado de proactividad de TI abiertas y cerradas.
manteniendo los servicios disponibles.
En el caso de los eventos que generaron una incidencia,
4.1.5.9  Acciones de revisión problema o cambio, éstos deberán cerrarse formalmente
con un vínculo al registro adecuado de los otros procesos
Cuando se generan miles de eventos diariamente, no
involucrados.
es posible revisar formalmente cada uno de ellos en
forma individual. Sin embargo, es importante comprobar
4.1.6 Disparadores, interfaces
que ninguna excepción o evento significativo haya sido
gestionado indebidamente, o hacer el seguimiento de las interprocesales de entradas y salidas
tendencias o recuentos de los tipos de eventos, etc. En La Gestión de Eventos puede ser iniciada por cualquier
muchos casos, esto se puede realizar automáticamente, tipo de evento. La clave es definir cuáles de estos eventos
por ejemplo muestreando un servidor que se haya son importantes y sobre cuáles hay que actuar. Los
reiniciado usando un script automatizado para ver si está disparadores incluyen:
funcionando correctamente. ■■ Excepciones para cualquier nivel de rendimiento de
En los casos en los cuales los eventos hayan generado una CI definido en las especificaciones de diseño, OLAs o
incidencia, problema y/o cambio, la Revisión de Acciones SOPs
no deberá duplicar ninguna revisión que se haya realizado ■■ Excepciones a un proceso o procedimiento
como parte de esos procesos. Más bien, la intención es automatizado, p. ej., un cambio rutinario que haya
garantizar que el traspaso entre el proceso de Gestión de sido asignado a un equipo de desarrollo y que no
Eventos y otros procesos tenga lugar tal y como se diseñó haya concluido a tiempo
y que la acción esperada se lleve a cabo realmente. Esto ■■ Una excepción dentro de un proceso de negocio que
garantizará que las incidencias, problemas o cambios está siendo monitorizado por Gestión de Eventos
que se originan dentro de Gestión de Operaciones no se ■■ La finalización de un trabajo o tarea automatizada
pierdan entre los equipos o departamentos.
48 | Procesos de Operación del Servicio

■■ Un cambio de estado en un dispositivo o registro de ■■ Los eventos pueden representar una rica fuente de
base de datos información que se puede procesar para incluirla en
■■ Acceso de un usuario o procedimiento automatizado o sistemas de Gestión del Conocimiento. Por ejemplo,
job a una aplicación o base de datos se pueden correlacionar patrones de rendimiento con
■■ Una situación en la que un dispositivo, base de la actividad del negocio para usarlos como entrada en
datos o aplicación, etc., ha alcanzado el umbral de las futuras decisiones de estrategia y diseño.
rendimiento predefinido. ■■ Gestión de Eventos puede desempeñar un rol
importante a la hora de garantizar la detección
Gestión de Eventos puede hacer de interfaz para
anticipada del impacto potencial en los SLA, y se
cualquier proceso que requiera monitorización y control,
puede aplicar para rectificar los fallos lo antes posible
especialmente aquellos que no requieren monitorización
para que se minimice el impacto en los objetivos del
en tiempo real, pero que requieren alguna forma de
servicio.
intervención tras un evento o grupo de eventos. A
continuación se muestran ejemplos de interfaces con otros 4.1.7  Gestión de la Información
procesos: La información clave implicada en Gestión de Eventos
■■ Interfaz con aplicaciones de negocio y/o procesos incluye lo siguiente:
de negocio para permitir la detección de eventos ■■ Mensajes SNMP, que representan una forma estándar
de negocio potencialmente importantes y actuar de comunicar información técnica sobre el estado de
en consecuencia (p. ej., una aplicación de negocio los componentes de una Infraestructura de TI.
informa de una actividad anómala en la cuenta de
■■ Bases de Información de Gestión (MIBs) de dispositivos
un cliente que podría indicar algún tipo de fraude o
de TI. Una MIB es la base de datos en cada dispositivo
brecha de seguridad).
que contiene información sobre ese dispositivo,
■■ Las relaciones principales en ITSM se realizan con la incluyendo su sistema operativo, versión de la BIOS,
Gestión de Incidencias, Problemas y Cambios. Estas configuración de los parámetros del sistema, etc. La
interfaces se describen con más detalle en el párrafo posibilidad de interrogar MIBs y compararlas con una
4.1.5.8. norma es fundamental para poder generar eventos.
■■ La Gestión de la Capacidad y de la Disponibilidad son ■■ Agentes de Software de herramientas de monitorización
críticas para definir los eventos que son significativos, comerciales
los umbrales apropiados y cómo responder ante
■■ Los Motores de Correlación contienen reglas detalladas
ellos. A su vez, la Gestión de Eventos mejorará el
para determinar la relevancia y respuesta apropiada
rendimiento y la disponibilidad de los servicios
a los eventos. Los detalles sobre estos aspectos se
respondiendo a los eventos cuando éstos se producen
incluyen en el párrafo 4.1.5.6.
e informando sobre los patrones de eventos y sobre
■■ No existe ningún Registro de Eventos estándar para
eventos reales para determinar (comparándolo con
todos los tipos de eventos. Los contenidos exactos y el
los objetivos de los SLA y con los KPI) si existe algún
formato del registro dependen de las herramientas que
aspecto del diseño de la infraestructura o de la
se están usando y lo que se está monitorizando (p. ej.,
operación que se pudiera mejorar.
un servidor y las herramientas de Gestión de Cambios
■■ Gestión de la Configuración podrá usar eventos para
tendrán datos muy diferentes y probablemente usarán
determinar el estado actual de cualquier CI en la
un formato diferente). Sin embargo, existen algunos
infraestructura. La comparación de eventos con las
datos clave que normalmente se requieren para
líneas base autorizadas en el Sistema de Gestión de
que cada evento sea útil en el análisis. Esto incluirá
la Configuración (CMS) ayudará a determinar si se
típicamente el:
están llevando a cabo cambios sin autorización en
●● Dispositivo
la organización (vea la publicación Transición del
Servicio). ●● Componente

■■ Gestión de Activos (recogida con más detalle en ●● Tipo de fallo

las publicaciones Diseño y Transición del Servicio) ●● Fecha/hora

puede usar la Gestión de Eventos para determinar el ●● Parámetros de excepción
estado en el ciclo de vida de los activos. Por ejemplo, ●● Valor.
podría generarse un evento para indicar que se ha
configurado satisfactoriamente un nuevo activo y que
ahora está operativo.
 Procesos de Operación del Servicio | 49

4.1.8  Métricas ■■ El despliegue de agentes necesarios de monitorización

Para cada periodo de medida en cuestión, las métricas a través de toda la infraestructura de TI, podría resultar
para comprobar la eficacia y eficiencia del proceso Gestión una actividad difícil y lenta que requerirá de un
de Eventos deben incluir lo siguiente: compromiso continuo durante un periodo bastante
amplio de tiempo. Existe el riesgo de que se originen
■■ Número de eventos por categoría otras tareas que pudieran desviar recursos y retrasar
■■ Número de eventos por importancia dicho despliegue.
■■ Número y porcentaje de eventos que requirieron la ■■ La adquisición de los perfiles necesarios puede ser
intervención humana y si ésta se llevó a cabo lenta y costosa.
■■ Número y porcentaje de eventos que generaron
incidencias o cambios 4.1.9.2  Factores Críticos de Éxito
■■ Número y porcentaje de eventos provocados por Para obtener los fondos necesarios debe elaborarse un
problemas existentes o por Errores Conocidos Esto Proyecto o iniciativa convincente que muestre cómo
podría generar un cambio en la prioridad de trabajo los beneficios de una Gestión de Eventos eficaz pueden
sobre ese problema o Error Conocido superar con creces los costes, generando un retorno
■■ Número y porcentaje de eventos repetidos o positivo de la inversión.
duplicados. Esto ayudará a ajustar el Motor de
Uno de los CSF (Factores Críticos de Éxito) más
Correlación para eliminar la generación de eventos
importantes es lograr el nivel correcto de filtrado. Esto se
innecesarios, y también se podrá utilizar para ayudar
complica por el hecho de que cambie la relevancia de
en el diseño de una funcionalidad de generación de
los eventos. Por ejemplo, el que un usuario se registre
eventos mejorada en los nuevos servicios
hoy en un sistema es normal, pero si ese usuario deja la
■■ l Número y porcentaje de eventos que indican organización e intenta iniciar sesión generará una brecha
problemas de rendimiento (por ejemplo, crecimiento en la seguridad.
en el número de veces que una aplicación supera
sus umbrales de transacción durante los últimos seis Existen tres claves con respecto al nivel correcto de
meses) filtrado:
■■ l Número y porcentaje de eventos que indican ■■ Integrar Gestión de Eventos en todos los procesos
problemas potenciales de disponibilidad (p. ej., de Gestión del Servicio donde sea factible Esto
sistemas de recuperación de fallos para dispositivos garantizará que sólo se informará de los eventos
alternativos, o intercambio de carga de trabajo relevantes para estos procesos.
excesiva) ■■ Diseñar nuevos servicios teniendo en cuenta Gestión
■■ Número y porcentaje de cada tipo de evento por de Eventos (esto se analiza con detalle en el párrafo
plataforma o aplicación 4.1.10).
■■ Número y relación de eventos comparado con el ■■ Prueba y error. No importa lo exhaustivamente que se
número de incidencias. prepare Gestión de Eventos, habrá clases de eventos
que no se filtren adecuadamente. Por lo tanto, Gestión
4.1.9 Desafíos, Factores Críticos de Éxito y de Eventos debe incluir un proceso formal para
riesgos evaluar la eficacia del filtrado.
Es necesaria una planificación adecuada para la
4.1.9.1  Desafíos
introducción del agente software de monitorización
Existen varios retos que se podrían considerar: a través de toda la Infraestructura de TI. Esto deberá
■■ Un reto inicial podría ser obtener la financiación para considerarse como un proyecto con escalas de tiempo
la adquisición de las herramientas y para el esfuerzo realistas y se le asignarán y reservarán los recursos
necesario para implantar y explotar los beneficios de adecuados durante toda la duración del proyecto.
dichas herramientas.
■■ Uno de los desafíos mayores es establecer el nivel 4.1.9.3  Riesgos
correcto de filtrado. Si se establece incorrectamente el Los riesgos clave son realmente aquellos ya mencionados
nivel de filtrado, se podría generar un desbordamiento anteriormente: error a la hora de obtener la financiación
con respecto a eventos relativamente insignificantes, adecuada; garantizar el nivel correcto de filtrado; y error
o la incapacidad de detectar eventos relativamente a la hora de mantener el impulso en el despliegue de
importantes hasta que fuera demasiado tarde. los agentes de monitorización necesarios a través de la
50 | Procesos de Operación del Servicio

infraestructura de TI. Si no se abordaran algunos de estos ■■ ¿Cómo se generarán los eventos?

riesgos, esto podría impactar negativamente al éxito de ■■ ¿El CI ya tiene mecanismos de generación de eventos
Gestión de Eventos. como una funcionalidad estándar y, si fuera así, cuáles
de éstos se utilizarán? ¿Son suficientes o es necesario
4.1.10 Diseño de Gestión de Eventos personalizar el CI para que incluya mecanismos o
Una Gestión de Eventos eficaz no se diseña luego que información adicionales?
se haya desplegado un servicio en Operaciones. Debido ■■ ¿Qué datos se utilizarán para llenar el Registro de
a que Gestión de Eventos forma la base para monitorizar Eventos?
el rendimiento y disponibilidad de un servicio, deberán ■■ ¿Los eventos se generan automáticamente o se tiene
especificarse y acordarse los objetivos y mecanismos de que consultar al CI?
monitorización exactos durante los procesos de Gestión ■■ ¿Dónde se registrarán y almacenarán los eventos?
de la Capacidad y Disponibilidad (vea la publicación ■■ ¿Cómo se recopilarán datos adicionales?
Diseño del Servicio).
Nota: Aquí existe una fuerte interfaz con el diseño de la
Sin embargo, esto no significa que Gestión de Eventos aplicación. Todas las aplicaciones deben codificarse de
esté diseñado por un grupo de desarrolladores aislados tal forma que los mensajes/códigos de error detallados y
del sistema y que se lance a Gestión de Operaciones significativos se generen en el punto exacto de fallo para
junto con el sistema que tiene que gestionarse. Tampoco que éstos se puedan incluir en el evento y permitir el
significa que, una vez diseñado y acordado, Gestión de rápido diagnóstico y resolución de la causa subyacente. La
Eventos se convierta en algo estático. Las operaciones necesidad de incluir y probar tal sistema de mensajes de
diarias definirán eventos, prioridades, alertas y otras error se trata con más detalle en la publicación Transición
mejoras adicionales que volverán a alimentar, a través del Servicio.
del proceso de Mejora Continua, a Estrategia del Servicio,
Diseño del Servicio, etc. 4.1.10.2  Sistema de mensajes de error
Se espera que las funciones de Operación del Servicio El sistema de mensajes de error es importante para todos
participen en el diseño del servicio y en cómo éste se los componentes (hardware, software, redes, etc.). Es
mide (vea la sección 3.4). particularmente importante que todas las aplicaciones de
Para Gestión de Eventos, las áreas específicas de diseño software se diseñen para apoyar a Gestión de Eventos.
incluyen lo siguiente. Esto podría incluir la provisión de mensajes y/o códigos
de error significativos que indiquen claramente el punto
4.1.10.1  Instrumentación específico de fallo y la causa más probable. En tales casos,
la prueba de nuevas aplicaciones debe incluir la prueba de
La instrumentación es la definición de lo que se
una generación de eventos precisa.
puede monitorizar sobre CIs y la forma en la que
su comportamiento se puede ver afectado. En otras Las tecnologías más recientes como por ejemplo Java
palabras, instrumentación trata sobre la definición y Management Extensions (JMX) o HawkNL™, proporcionan
diseño de cómo monitorizar y controlar exactamente la herramientas de desarrollo de soluciones distribuidas,
Infraestructura de TI y los servicios de TI. basadas en la web, dinámicas y modulares para gestionar
y monitorizar dispositivos, aplicaciones y redes orientadas
Instrumentación trata en parte sobre un conjunto de
a servicios. Éstas se pueden utilizar para reducir o eliminar
decisiones que necesitan tomarse y en parte sobre el
la necesidad de que los programadores incluyan mensajes
diseño de mecanismos para ejecutar estas decisiones.
de error dentro del código, lo que permite un nivel valioso
Las que son necesarias tomar incluyen: de normalización y de independencia del código.
■■ ¿Qué es necesario monitorizar?
4.1.10.3  Detección de Eventos y Mecanismos de
■■ ¿Qué tipo de monitorización se requiere (p. ej., activa
o pasiva; rendimiento o salida)? Alerta
■■ ¿Cuándo necesitamos generar un evento? Un buen diseño de Gestión de Eventos también incluirá
■■ ¿Qué tipo de información es necesario comunicar en
el diseño y carga de las herramientas utilizadas para filtrar,
el evento? correlacionar y escalar Eventos.
■■ ¿Quiénes son los interesados de los mensajes? El Motor de Correlación se cargará específicamente con las
reglas y criterios que determinarán la relevancia y acción
Los mecanismos que son necesarios diseñar incluyen:
posterior para cada tipo de evento.
 Procesos de Operación del Servicio | 51

Un diseño minucioso de los mecanismos de alerta y 4.2  Gestión de Incidencias

detección de eventos requiere lo siguiente:
En la terminología de ITIL, una ‘incidencia’ se
■■ Conocimiento del negocio en relación con cualquier
define como:
proceso de negocio que se esté gestionando a través
Una interrupción no planificada de un Servicio de TI
de Gestión de Eventos
o reducción en la calidad de un servicio de TI. El fallo
■■ Conocimiento detallado de los Requerimientos de
de un elemento de configuración que todavía no
Nivel de Servicio del servicio al que está dando
ha impacto en el servicio también se considera una
soporte cada CI
incidencia, por ejemplo el fallo de un disco de una
■■ Conocimiento de quién realizará el soporte del CI configuración en espejo (‘mirror’).
■■ Conocimiento de lo que constituye una operación
normal y anormal del CI Gestión de Incidencias es el proceso de tratamiento
de todas las incidencias; esto puede incluir fallos,
■■ Conocimiento de la importancia de múltiples eventos
preguntas o cuestiones reportadas por los usuarios
similares (en el mismo CI o en varios CI similares)
(normalmente a través de una llamada telefónica
■■ Un entendimiento de lo que se necesita conocer para
al Centro de Servicio al Usuario), personal técnico,
dar soporte al CI de forma eficaz
o detectadas automáticamente y reportadas por las
■■ Información que pueda ayudar en el diagnóstico de herramientas de monitorización de eventos.
problemas con el CI
■■ Familiarizarse con los códigos de clasificación
y priorización de incidencias para que, si fuera 4.2.1  Propósito/meta/objetivo
necesario crear un Registro de Incidencia, se puedan El objetivo principal del proceso de Gestión de
proporcionar dichos códigos Incidencias es restaurar la operación normal del servicio
■■ Conocimiento de otros CI que pudieran depender del lo antes posible y minimizar el impacto negativo en
CI afectado, o de aquellos otros de los que depende las operaciones del negocio y por lo tanto asegurar el
■■ Disponibilidad de la información de los Errores mantenimiento de los mejores niveles posibles de calidad
Conocidos de proveedores o de la experiencia previa. y disponibilidad del servicio. La ‘Operación normal del
servicio’ se define aquí como la operación del servicio
4.1.10.4  Identificación de umbrales dentro de los límites de los SLA.
Los propios umbrales no se establecen ni se gestionan a
través de Gestión de Eventos. Sin embargo, a menos que 4.2.2  Ámbito
éstos se diseñen y comuniquen adecuadamente durante el La Gestión de Incidencias incluye cualquier evento que
proceso de instrumentación, será difícil determinar el nivel de afecte o pueda afectar negativamente a un servicio. Esto
rendimiento que es adecuado para cada CI. incluye eventos que los usuarios comunican directamente,
Por otra parte, la mayoría de los umbrales no son ya sea a través del Centro de Servicio al Usuario o, a través
constantes. Éstos están formados típicamente por diversas de una interfaz, desde la Gestión de Eventos hasta las
variables asociadas. Por ejemplo, el número máximo herramientas de Gestión de Incidencias.
de usuarios concurrentes antes de que se reduzca el Además, el personal técnico también puede informar y/o
tiempo de respuesta, variará dependiendo de qué otros registrar incidencias (si, por ejemplo, tuvieran noticia de
trabajos estén activos en el servidor. Normalmente, este algo negativo con respecto a un componente de hardware
conocimiento sólo se obtiene por la experiencia, lo que o de red, podrían registrar o informar de una incidencia
significa que los Motores de Correlación se tienen que y dirigirla al Centro de Servicio al Usuario). Sin embargo,
ajustar y actualizar continuamente a través del proceso de esto no significa que todos los eventos sean incidencias.
Mejora Continua del Servicio. Muchas clases de eventos en modo alguno están
asociadas con interrupciones, ya que son indicadores de
la operación normal o sólo tienen por objetivo informar
(véase la sección 4.1).
Aunque se informa tanto de las incidencias como de las
peticiones de servicio al Centro de Servicio al Usuario, esto
no significa que sean lo mismo. Las peticiones de servicio
no representan una interrupción del servicio acordado,
pero representan una forma de satisfacer las necesidades
52 | Procesos de Operación del Servicio

del cliente y podrían abordarse como un objetivo acordado conscientes de estas escalas de tiempo. Las herramientas
en un SLA. Las peticiones de servicio se tramitan mediante de Gestión del Servicio deben usarse para automatizar
el proceso Gestión de Peticiones (vea la sección 4.3). escalas de tiempo y escalar la incidencia como requieran
unas reglas predefinidas.
4.2.3  Valor para el negocio
El valor de la Gestión de Incidencias incluye: 4.2.4.2  Modelos de Incidencias
Muchas incidencias no son nuevas. Éstas implican tratar
■■ La capacidad de detectar y resolver incidencias
con algo que ha pasado antes y que podría volver a pasar
consiguiendo que el tiempo de caída para el negocio
nuevamente. Por esta razón, muchas organizaciones
sea menor, lo que a su vez implica una mayor
encontrarán útil predefinir Modelos de Incidencias
disponibilidad del servicio. Esto significa que el
‘estándar’ y aplicarlos a las incidencias adecuadas cuando
negocio podrá explotar la funcionalidad del servicio
se produzcan.
según se diseñó.
■■ La capacidad para alinear la actividad de TI con las Un Modelo de Incidencias es una forma de predefinir los
prioridades de negocio en tiempo real. Esto se debe pasos que deben tomarse para manejar un proceso (en
a que la Gestión de Incidencias incluye la capacidad este caso un proceso para tratar con un tipo particular
de identificar prioridades del negocio y asignar de incidencia) de una forma acordada. Por lo tanto, se
dinámicamente recursos cuando sea necesario. pueden utilizar herramientas de soporte para gestionar
■■ La capacidad de identificar mejoras potenciales en los el proceso requerido. Esto garantizará que las incidencias
servicios. Esto se produce como resultado de entender ‘estándar’ se manejen de forma predefinida y dentro de las
lo que constituye una incidencia y también lo que escalas de tiempo también definidas previamente.
está en contacto con las actividades del personal Las incidencias que podrían requerir un manejo
operativo del negocio. especializado se pueden tratar de esta forma (por
■■ El Centro de Servicio al Usuario, durante su manejo de ejemplo, las incidencias asociadas con la seguridad
incidencias, identifica requisitos adicionales del servicio pueden reencaminarse a Gestión de la Seguridad de la
o de formación encontrados en TI o en el negocio. Información, y las incidencias asociadas con la capacidad o
La Gestión de Incidencias es altamente visible para el con el rendimiento podrían reencaminarse a Gestión de la
negocio, y por lo tanto es más fácil demostrar su valor Capacidad).
que en el caso de la mayoría de áreas de Operación El Modelo de Incidencias debe incluir:
del Servicio. Por esta razón, la Gestión de Incidencias
■■ Los pasos que deben tomarse para manejar la
es muchas veces uno de los primeros procesos a
incidencia
implementar en los proyectos de la Gestión del Servicio.
El beneficio añadido de hacer esto es que la Gestión de ■■ El orden cronológico de estos pasos con cualquier
Incidencias se puede utilizar para resaltar otras áreas que dependencia o co-procesamiento definidos
necesitan atención, y por esa razón, proporcionar una ■■ Responsabilidades; quién debe hacer qué
justificación para el gasto de implementación de otros ■■ Escalas de tiempo y umbrales para completar las
procesos. acciones
■■ Procedimientos de escalado; con quién hay que
4.2.4  Políticas/principios/conceptos básicos ponerse en contacto y cuándo
Existen algunos aspectos básicos que es necesario tener ■■ Cualquier actividad de conservación de evidencias
en cuenta y decidir al considerar Gestión de Incidencias. (particularmente relevante para incidencias asociadas
Éstos se recogen en esta sección. con la seguridad y con la capacidad).
Los modelos deben ser la entrada a las herramientas de
4.2.4.1  Escalas de tiempo soporte de gestión de incidencias que están en uso, y las
Las escalas de tiempo deben acordarse para todas las herramientas deben automatizar el tratamiento, gestión y
etapas por las que pasa una incidencia (éstas diferirán escalado del proceso.
dependiendo del nivel de prioridad de la incidencia).
Se basan en los objetivos de respuesta y resolución de 4.2.4.3  Incidencias graves
las incidencias dentro de los SLA, y se capturan como Deberá usarse un procedimiento independiente para
objetivos dentro de los OLA y de los Contratos de Soporte incidencias ‘graves’, con escalas de tiempo más breves y
(UCs). Todos los grupos de soporte deben ser totalmente con más urgencia. Deberá acordarse y trazarse idealmente
 Procesos de Operación del Servicio | 53

una definición de lo que constituye una incidencia grave 4.2.5.1  Identificación de incidencias
para todo el sistema de priorización de incidencias, de tal El trabajo no puede comenzar a tratar con una incidencia
forma que se traten a través del proceso de incidencias hasta que ésta no se detecte. Normalmente es inaceptable,
graves. desde una perspectiva de negocio, esperar hasta que un
Nota: A veces las personas usan una terminología inexacta usuario se vea afectado y se ponga en contacto con el
y/o confunden una incidencia grave con un problema. En Centro de Servicio al Usuario. Siempre que sea posible,
realidad, una incidencia siempre será una incidencia. Ésta todos los componentes clave deben monitorizarse para
podría crecer en impacto o prioridad hasta convertirse detectar anticipadamente fallos reales o potenciales para
en una incidencia grave, pero una incidencia nunca se que el proceso de gestión de incidencias pueda comenzar
convierte en un problema. Un problema es la causa rápidamente. Idealmente, las incidencias deben resolverse
subyacente de una o más incidencias y siempre se antes de que tengan impacto en los usuarios.
corresponde con una entidad independiente. Vea la sección 4.1 para disponer de más detalles.
Algunas incidencias de baja prioridad también podrían
tener que manejarse a través de este procedimiento 4.2.5.2  Registro de incidencias
debido al impacto potencial en el negocio, y puede que Todas las incidencias deben registrarse en su totalidad
algunas incidencias graves no necesiten manejarse de esta y marcarse con una fecha/hora independientemente de
forma si la causa y resoluciones fueran obvias y el proceso si salieron a la luz a través de una llamada telefónica
de incidencias normales pudiera hacerlas frente fácilmente al Centro de Servicio al Usuario o si se detectaron
dentro de los tiempos objetivo de resolución acordados, automáticamente a través de una alerta de eventos.
siempre que el impacto permaneciera bajo.
Nota: Si el Centro de Servicio al Usuario y/o el personal de
Si fuera necesario, el procedimiento de gestión de soporte visitara a los clientes para abordar una incidencia,
incidencias graves debe incluir el establecimiento se les podría solicitar que trataran más incidencias
dinámico de un equipo independiente de gestión de ‘mientras estén allí’. Si se hiciera esto sería importante
incidencias graves bajo la dirección directa del Gestor de abrir un Registro de Incidencias para cada incidencia
Incidencias. Formulado para concentrarse en esta única adicional manejada. Con ello se garantizaría que se
incidencia con el fin de garantizar que se suministran mantiene un registro histórico y que se obtiene una
los recursos y el enfoque adecuados para encontrar una acreditación por el trabajo acometido.
rápida resolución. Si el Responsable del Centro de Servicio
al Usuario estuviera también cumpliendo el rol de Gestor
de Incidencias (como en una organización pequeña),
entonces podría ser necesario designar a una persona
independiente para que dirija al equipo de investigación
de incidencias graves para evitar conflictos de tiempo o
de prioridades, pero en última instancia deberá informar al
Gestor de Incidencias.
Si al mismo tiempo fuera necesario investigar la causa de
la incidencia, entonces el Gestor de Problemas también se
implicaría aunque el Gestor de Incidencias debe garantizar
que se mantengan independientes la restauración del
servicio y la causa subyacente. En todo el proceso, el
Centro de Servicio al Usuario garantizaría que todas las
actividades se registren y que los usuarios se mantengan
completamente informados del progreso.

4.2.5  Actividades, métodos y técnicas del

proceso
El proceso a seguir durante la gestión de una incidencia se
muestra en la Figura 4.2. El proceso incluye los siguientes
pasos.
54 | Procesos de Operación del Servicio

Desde Desde Llamada Correo Electrónico

Gestión Interfaz Telefónica Personal
de Eventos Web de Usuario Técnico

Identificación
de la Incidencia

Registro
de la Incidencia

Categorización
de la Incidencia

Sí
¿Petición de A Gestión
Servicio? de Peticiones

No

Priorización
de la Incidencia

Procedimiento
de Incidencia Sí
¿Incidencia Grave?
Grave

No

Diagnóstico
Inicial

¿Se Requiere Escalado

Sí Sí Funcional
Escalado
Funcional? 2/3 Nivel

Gestión Sí ¿Se Requiere No

de Escalados Escalado
Jerárquico?

No Investigación
y Diagnóstico

Resolución
y Recuperación

Cierre de la
Incidencia

Fin Figura 4.2 Flujo del proceso de

Gestión de Incidencias
 Procesos de Operación del Servicio | 55

Deberá registrarse toda la información relevante asociada Tenga en cuenta que la verificación de Peticiones de
a la naturaleza de la incidencia, para que se mantenga un Servicios en este proceso no implica que las Peticiones
registro histórico completo y para que si fuera necesario de Servicio sean incidencias. Esto es simplemente el
remitir la incidencia a otros grupos de soporte tengan reconocimiento del hecho de que las Peticiones de
toda la información relevante a mano para ayudarles. Servicio algunas veces se registran incorrectamente como
La información necesaria para cada incidencia incidencias (p. ej., un usuario introduce incorrectamente la
probablemente incluirá: petición como una incidencia desde la interfaz web). Esta
verificación detectará tales solicitudes y asegurará que se
■■ Un número de referencia único
pasen al proceso de Gestión de Peticiones.
■■ Categorización de incidencias (con frecuencia divididas
La categorización multinivel está disponible en la mayoría
entre dos y cuatro niveles de categorías secundarias)
de las herramientas – normalmente con tres o cuatro
■■ Urgencia de la incidencia
niveles de detalle. Por ejemplo, una incidencia se podría
■■ Impacto de la incidencia categorizar como se muestra en la Figura 4.3.
■■ Prioridad de la incidencia
■■ Fecha/hora registrada Hardware
■■ Nombre/ID de la persona y/o grupo que registra la
incidencia
Servidor
■■ Método de notificación (telefónico, automático, correo
electrónico, en persona, etc.)
■■ Nombre/departamento/teléfono/ubicación del usuario Placa de Memoria

■■ Método de devolución de llamada (telefónica, correo,

etc.) Fallo de Tarjeta
■■ Descripción de síntomas O

■■ Estado de la incidencia (activa, en espera, cerrada, etc.) Software

■■ CI asociado
■■ Grupo/persona de soporte para el que se asigna la
Aplicación
incidencia
■■ Problema asociado/Error Conocido
■■ Actividades acometidas para resolver la incidencia Paquete de Finanzas
■■ Fecha y hora de resolución
■■ Categoría de cierre Sistema de órdenes
de pedido
■■ Fecha y hora de cierre.
Nota: Si el Centro de Servicio al Usuario no trabajara las 24 Figura 4.3 Categorización de incidencias multinivel
horas/7 días a la semana y la responsabilidad de primera
línea de registro y gestión de incidencias pasara a otro Todas las organizaciones son únicas y por lo tanto es
grupo, como por ejemplo Soporte de Red u Operaciones difícil proporcionar una guía genérica sobre las categorías
de TI, fuera de las horas del Centro de Servicio al Usuario, que debe usar una organización, particularmente a
entonces este personal necesitará ser igualmente riguroso niveles inferiores. Sin embargo, existe una técnica que se
sobre el registro de detalles de incidencias. Tal personal puede utilizar para ayudar a una organización a lograr un
deberá demostrar una formación y conocimiento conjunto correcto y completo de categorías, si estuvieran
completo sobre estos temas. partiendo de cero. Los pasos implican:
1 Mantener una sesión de tormenta de ideas
4.2.5.3  Categorización de incidencias (brainstorming) entre los grupos de soporte
Parte del registro inicial deberá asignar una codificación pertinentes, implicando al Supervisor de SD y a los
adecuada de la categorización de incidencias para que se Gestores de Problemas e Incidencias.
registre el tipo exacto de la llamada. Esto será importante 2 Use esta sesión para decidir intuitivamente las
posteriormente al analizar frecuencias/tipos de incidencias categorías de mayor nivel, e incluya una categoría
para establecer tendencias de uso en Gestión de ‘otra’. Establezca las herramientas de registro
Problemas, Gestión de Suministradores y otras actividades pertinentes para usar estas categorías durante un
de ITSM. periodo de prueba.
56 | Procesos de Operación del Servicio

3 Use las categorías durante un breve periodo de y el nivel de impacto que está causando. A menudo
prueba (suficientemente largo como para que cada (no siempre), una indicación de impacto es el número
categoría acoja varios cientos de incidencias, pero no de usuarios que se ven afectados. En algunos casos, y
demasiado amplio como para que se tarde demasiado de forma muy importante, la pérdida de servicio para
tiempo en realizar un análisis). un único usuario puede tener un impacto grave en el
negocio. Todo depende de quién está intentando hacer
4 Realice un análisis de las incidencias registradas
qué, por lo que los números por sí solos no bastarán para
durante el periodo de prueba. El número de
evaluar la prioridad en su conjunto. Otros factores que
incidencias registradas en cada categoría de mayor
también pueden contribuir a los niveles de impacto son:
nivel confirmará si las categorías tienen valor, y un
análisis más detallado de la ‘otra’ categoría deberá ■■ Riesgo para la integridad física
permitir la identificación de cualquier categoría de ■■ El número de servicios afectados. Podrían ser múltiples
mayor nivel que sea necesaria. servicios
5 Se deberá utilizar un análisis de desglose de las ■■ El nivel de pérdidas financieras
incidencias dentro de cada categoría de nivel superior ■■ Efecto en la reputación del negocio
para decidir las categorías de menor nivel que se ■■ Incumplimientos regulatorios o legislativos.
requerirán.
La Tabla 4.1 incluye una alternativa eficaz para calcular
6 Revise y repita estas actividades después de un estos elementos y derivar un nivel de prioridad general
periodo adicional de uno a tres meses, y nuevamente para cada incidencia:
de manera regular para garantizar que siguen
Tabla 4.1 Sistema simple de codificación de prioridad
siendo pertinentes. Sea consciente de que algunos
cambios significativos en la categorización podría Impacto
causar algunas dificultades a la hora de determinar Alto Medio Bajo
tendencias de las incidencias o generación de Alto 1 2 3
informes de la dirección, por lo que deberían Urgencia Medio 2 3 4
estabilizarse a menos que los cambios se requieran
Bajo 3 4 5
verdaderamente.
Si ya se utilizara un esquema existente de Código de prioridad Descripción Tiempo de resolución objetivo
categorización, pero se creyera que no está funcionando 1 Crítico 1 hora
satisfactoriamente, podrá usarse la idea básica de la 2 Alto 8 horas
técnica sugerida anteriormente para revisar y modificar el 3 Medio 24 horas
esquema existente.
4 Bajo 48 horas
NOTA: Algunas veces los detalles disponibles en el 5 Planificación Planificado
momento del registro de una incidencia podrían estar
En todos los casos, debe suministrarse una guía clara,
incompletos, ser engañosos o incorrectos. Por lo tanto,
con ejemplos prácticos, para permitir a todo el personal
es importante comprobar y actualizar si fuera necesario
de soporte determinar los niveles correctos de impacto
la categorización de la incidencia en el momento del
y urgencia para que se asigne la prioridad correcta. Esta
cierre de la llamada (en un campo de categorización de
guía debe generarse durante las negociaciones del nivel
cierre independiente para no corromper la categorización
de servicio.
original). Vea el párrafo 4.2.5.9.
Sin embargo, debe tenerse en cuenta que habrá ocasiones
4.2.5.4  Priorización de la incidencia en las que, debido a la conveniencia particular del negocio
Otro aspecto importante del registro de cada incidencia o por cualquier otra razón, los niveles de prioridad normal
es acordar y asignar un código de priorización adecuado tendrán que anularse. Si un usuario fuera inflexible con
ya que esto determinará cómo se maneja la incidencia respecto a que el nivel de prioridad de una incidencia
mediante herramientas de soporte y mediante el personal debe superar las directrices normales, el Centro de Servicio
de soporte. al Usuario debe cumplir tal petición. Y si posteriormente
resultara incorrecto, esta situación se podrá resolver como
La priorización normalmente se puede determinar un problema de nivel de gestión off-line en lugar de
teniendo en cuenta tanto la urgencia de la incidencia (la considerarla como una disputa que se produce cuando el
rapidez con la que el negocio necesita una resolución), usuario se encuentra al teléfono.
 Procesos de Operación del Servicio | 57

Algunas organizaciones también podrían admitir VIPs 4.2.5.6  Escalado de la incidencia

(altos ejecutivos, directivos, diplomáticos, políticos, etc.), ■■ Escalado funcional. En cuanto esté claro que el
cuyas incidencias se tratarían con una prioridad mayor de Centro de Servicio al Usuario es incapaz de resolver la
lo normal. Aunque en tales casos será mejor atenderlas incidencia por sí mismo (o cuando se hayan superado
y documentarlas dentro de la guía suministrada por el los tiempos objetivo para la resolución del primer
personal del Centro de Servicio al Usuario sobre cómo punto, cualquiera que venga primero), la incidencia
aplicar los niveles de prioridad, por lo que todos son deberá escalarse inmediatamente para aplicar un
conscientes de las reglas acordadas para los VIPs, y soporte posterior.
quienes están incluidos en esta categoría.
Si la organización dispusiera de un grupo de soporte
Debe tenerse en cuenta que la prioridad de una incidencia de segundo nivel y el Centro de Servicio al Usuario
podría ser dinámica si las circunstancias cambiaran o si creyera que la incidencia puede resolverse a través
una incidencia no se resolviera dentro de los tiempos de ese grupo, le enviaría la incidencia a ellos. Si fuera
objetivo de los SLA. En este caso la prioridad deberá obvio que la incidencia exigirá un conocimiento
alterarse para reflejar la nueva situación. técnico más profundo, o cuando el grupo de segundo
nivel no hubiera sido capaz de resolver la incidencia
Nota: algunas herramientas podrían tener limitaciones
dentro de los tiempos objetivo acordados (cualquiera
que dificulten el cálculo automático de rendimiento con
que sea primero), la incidencia deberá escalarse
respecto a los objetivos del SLA si una prioridad cambia
inmediatamente al grupo de soporte de tercer nivel
durante la vida útil de una incidencia. Sin embargo, si las
adecuado. Tenga en cuenta que los grupos de soporte
circunstancias cambiaran, deberá hacerse el cambio de
de tercer nivel podrían ser internos, pero también
prioridad, y si fuera necesario, realizar ajustes manuales en
podrían ser terceros, como el caso de suministradores
las herramientas de generación de informes. Idealmente,
de software o fabricantes o actualizadores de
no deberán seleccionarse herramientas con tales
hardware. Las reglas para escalar y manejar incidencias
limitaciones.
deben acordarse en OLAs y UCs con los grupos de
soporte internos y externos respectivamente.
4.2.5.5  Diagnóstico inicial
Si se hubiera encaminado la incidencia a través del Nota: La Propiedad de la Incidencia seguirá siendo del
Centro de Servicio al Usuario, el Analista del Centro de Centro de Servicio al Usuario. Independientemente de
Servicio al Usuario debiera haber realizado un diagnóstico dónde se haga referencia a una incidencia durante su
inicial, normalmente mientras que el usuario todavía duración, la propiedad de la incidencia seguirá siendo
esté al teléfono. Si la llamada surgiera de esta forma, se del Centro de Servicio al Usuario y asimismo, seguirá
detectarán todos los síntomas de la incidencia con el fin siendo el responsable de realizar un seguimiento de
de determinar exactamente lo que ha ido mal y cómo la incidencia en curso, mantendrá informados a los
corregirlo. Será en esta etapa donde los guiones para el usuarios, y en última instancia será responsable del
diagnóstico y la información de los errores conocidos Cierre de la Incidencia.
resulten ser de más valor permitiendo un diagnóstico ■■ Escalado Jerárquico. Si las incidencias fueran de
preciso y anticipado. naturaleza grave (por ejemplo incidencias de Prioridad
Si fuera posible, el Analista del Centro de Servicio al 1), este hecho se deberá notificar a los directores
Usuario resolverá la incidencia mientras el usuario todavía de TI adecuados, por lo menos para mantenerlos
se encuentre al teléfono y cerrará la incidencia si la informados. El escalado jerárquico también se utiliza
resolución fuera satisfactoria. si los pasos de ‘Investigación y Diagnóstico’ y de
‘Resolución y Recuperación’ consumieran demasiado
Si el Analista del Centro de Servicio al Usuario no pudiera tiempo o se probara que son demasiado difíciles de
resolver la incidencia mientras el usuario todavía está aplicar. El escalado jerárquico debe continuar hasta
al teléfono, pero hubiera una perspectiva de que el la cadena de dirección para que los directores senior
Centro de Servicio al Usuario pudiera hacerlo dentro sean conscientes del hecho y se puedan preparar y
del límite de tiempo acordado sin asistencia de otros tomar todas las acciones necesarias, como por ejemplo
grupos de soporte, el Analista deberá informar al usuario asignar recursos adicionales o implicar a proveedores/
de sus intenciones, proporcionar al usuario el número empresas de mantenimiento.. El escalado jerárquico
de referencia de la incidencia e intentar encontrar una también se utiliza cuando existen argumentos sobre a
resolución. quién se le asigna la incidencia.
58 | Procesos de Operación del Servicio

Además, los usuarios afectados o la dirección del cliente generales, y las herramientas de soporte deberán diseñarse
pueden iniciar el escalado jerárquico cuando lo consideren y/o seleccionarse para permitir esto. Sin embargo, deben
oportuno. Esta es la razón por la que es importante que tomarse las precauciones oportunas para coordinar
los directores de TI sean conscientes del hecho, para que actividades, particularmente actividades de resolución y
puedan anticipar y prepararse para cualquier escalado. recuperación. De lo contrario, las acciones de diferentes
grupos podrían entrar en conflicto o complicar una
Es necesario acordar los niveles y escalas de tiempo
resolución.
exactos para el escalado funcional o jerárquico teniendo en
cuenta los objetivos de los SLA, e integrarse dentro de las Es probable que esta investigación incluya acciones como:
herramientas de soporte que se puedan utilizar para vigilar
■■ Establecer exactamente lo que se ha hecho mal o lo
y controlar el flujo de proceso dentro de las escalas de
que está buscando el usuario
tiempo acordadas.
■■ Entender el orden cronológico de los eventos
El Centro de Servicio al Usuario debe mantener al usuario ■■ Confirmar el impacto total de la incidencia, incluyendo
informado de cualquier escalado relevante que tenga lugar, el número y rango de los usuarios afectados
y garantizar que el Registro de Incidencias se encuentre ■■ Identificar cualquier evento que pudiera haber
actualizado apropiadamente para mantener un histórico disparado la incidencia (p. ej., un cambio reciente,
completo de acciones. alguna acción del usuario)
Nota relacionada con la asignación de Incidencias ■■ Buscar información sobre ocurrencias previas
Podría haber muchas incidencias en una cola con el mismo consultando Registros de Problemas/Incidencias y/o
nivel de prioridad. Por lo tanto, el personal del Centro de Bases de Datos de Errores Conocidos, o Registros de
Servicio al Usuario y/o de Gestión de Incidencias decidirá Errores de fabricantes/suministradores, o Bases de
inicialmente, junto con los responsables de varios grupos Datos de Conocimiento.
de soporte a los que se les escalan incidencias, el orden
en el que las incidencias deberán escogerse y trabajar 4.2.5.8  Resolución y Recuperación
activamente en ellas. Estos responsables deben garantizar Si se hubiera identificado una posible resolución, ésta
que las incidencias se aborden dentro de un verdadero deberá aplicarse y probarse. Las acciones específicas a
orden de prioridad de negocio y que no se permita al emprender y las personas que estarán implicadas en las
personal escoger las incidencias a su gusto. acciones de recuperación podrían variar dependiendo de
la naturaleza del fallo, pero podrían implicar:
4.2.5.7  Investigación y Diagnóstico ■■ Al usuario al que se le haya solicitado que emprenda
En caso de incidencias en las que el usuario sólo está actividades dirigidas en su propio PC o en su equipo
buscando información, el Centro de Servicio al Usuario remoto
deberá ser capaz de suministrársela razonablemente ■■ Al Centro de Servicio al Usuario en la implementación
rápido, y resolver la petición de servicio. Pero si se de la resolución de forma centralizada (es decir,
informara de un fallo, esto sería una incidencia y reiniciando un servidor), o de forma remota usando
probablemente requiera algún grado de investigación y software para tomar el control del PC del usuario para
diagnóstico. diagnosticar e implementar una resolución
Cada uno de los grupos de soporte implicados en la ■■ A los grupos de soporte especialistas a los que se
tramitación de incidencias investigará y diagnosticará lo le ha solicitado la implementación de acciones
que ha ido mal, y todas estas actividades (incluyendo específicas de recuperación (p. ej., reconfiguración de
los detalles de cualquier acción tomada para tratar de un router a través de Soporte de Red)
resolver o recrear la incidencia) deberán documentarse ■■ Un proveedor externo o mantenedor al que se le haya
completamente en el registro de incidencias para que solicitado resolver el fallo.
se mantenga en todo momento un registro histórico
Incluso cuando se haya encontrado una resolución, deben
completo de todas las actividades.
realizarse las pruebas suficientes para garantizar que se
Nota: En muchas ocasiones se puede perder tiempo complete la acción de recuperación y que el servicio se
valioso si las acciones de investigación y diagnóstico (o haya restaurado completamente para los usuarios.
las acciones de resolución y recuperación) se realizaran
NOTA: en algunos casos, podría ser necesario para
en serie. Cuando sea posible, tales actividades deberán
dos o más grupos tomar acciones de recuperación
realizarse en paralelo para reducir los tiempos de escala
independientes, aunque posiblemente coordinadas, para
 Procesos de Operación del Servicio | 59

implementar una resolución general. En tales casos, y personal de TI sean conscientes de esto. Podría ser
Gestión de Incidencias debe coordinar las actividades y inadecuado usar este método para ciertos tipos de
establecer contactos con todas las partes implicadas. incidencias, como por ejemplo incidencias graves o
aquellas que implican a VIPs, etc.
Independientemente de las acciones tomadas, o quién
las realice, el Registro de Incidencias debe actualizarse Reglas para la reapertura de incidencias
convenientemente con toda la información y detalles A pesar de aplicar todas las precauciones posibles, se
pertinentes para mantener un historial completo. producirán casos en los que las incidencias vuelvan a
El grupo de resolución debe volver a pasar la incidencia al surgir incluso cuando éstas se hayan cerrado formalmente
Centro de Servicio al Usuario para la acción de cierre. con anterioridad. Debido a tales casos, sería deseable
disponer de reglas predefinidas para determinar si se
4.2.5.9  Cierre de la Incidencia puede reabrir una incidencia. Esto podría tener sentido,
El Centro de Servicio al Usuario debe comprobar que la por ejemplo, para acordar que se pueda abrir una
incidencia se resuelva completamente y que los usuarios incidencia si ésta se volviera a producir dentro de un día
estén satisfechos y dispuestos a acordar el cierre de la hábil. A partir de este punto deberá elevarse una nueva
incidencia. El Centro de Servicio al Usuario también debe incidencia pero vinculada a las incidencias previas.
comprobar lo siguiente: El umbral/reglas exactas de tiempo podrían variar
■■ Categorización del cierre. Compruebe y confirme dependiendo de las organizaciones, aunque es necesario
que la categorización inicial de la incidencia fue que se acuerden y documenten reglas claras, y se aplique
correcta o, en el caso de que la categorización una guía a todo el personal del Centro de Servicio al
posterior resultara diferente, actualice el registro para Usuario para mantener la uniformidad.
que se registre una categorización del cierre correcta
para la incidencia, buscando asesoramiento o guía en 4.2.6 Disparadores, interfaces de entrada y
los grupos de resolución cuando sea necesario. salida entre procesos
■■ Encuesta de satisfacción del usuario. Realice una Las incidencias se pueden activar de muchas formas.
encuesta de satisfacción por correo electrónico o con El camino más habitual es el que se da cuando un
devolución de llamada para el porcentaje acordado de usuario llama al Centro de Servicio al Usuario o completa
incidencias. una pantalla de registro de incidencias basada en la
■■ Documentación de la incidencia. Busque cualquier web, aunque cada vez es más habitual que se informe
detalle pendiente y asegúrese que el Registro de automáticamente de las incidencias a través de
Incidencias esté totalmente documentado para que se herramientas de Gestión de Eventos. El personal técnico
complete un registro histórico a un nivel suficiente de podría notificar fallos potenciales y elevar una incidencia,
detalle. o solicitar que el Centro de Servicio al Usuario lo haga
■■ ¿Problema recurrente o continuo? Determine (junto para que se pueda abordar el fallo. Algunas incidencias
con los grupos de resolución) si es probable que la también podrían surgir a partir de los suministradores,
incidencia pudiera volver a producirse y decida si es quienes podrían enviar alguna forma de notificación de
necesario tomar alguna acción preventiva para evitar una dificultad potencial o real que necesitara atención.
esto. Junto con Gestión de Problemas, plantee un Las interfaces con Gestión de Incidencias incluyen:
Registro de Problemas en todos esos casos para que
■■ Gestión de Problemas: La Gestión de Incidencias
se inicie la acción preventiva.
forma parte del proceso general de tratamiento de
■■ Cierre formal. Cierre formalmente el Registro de
problemas en la organización. En muchas ocasiones
Incidencias.
las incidencias están provocadas por problemas
Nota: Algunas organizaciones podrían decidir utilizar subyacentes que deben resolverse para evitar
un periodo de cierre automático con respecto a que vuelva a producirse la incidencia. Gestión de
incidencias específicas o incluso con respecto a todo Incidencias ofrece un punto donde se informe de las
tipo de incidencias (p. ej., la incidencia se cerrará mismas.
automáticamente después de dos días hábiles si no ■■ La Gestión de la Configuración ofrece datos que
se produjera ningún contacto posterior por parte del sirven para identificar y escalar las incidencias. Uno
usuario). Si se considerara este método, primero se tiene de los usos de CMS es identificar equipos defectuosos
que discutir y acordar completamente con los usuarios, y analizar el impacto de una incidencia. También se
y anunciarlo ampliamente para que todos los usuarios utiliza para identificar a los usuarios afectados por
60 | Procesos de Operación del Servicio

problemas potenciales. El CMS también contiene ●● Histórico de incidencias y problemas

información sobre a qué grupo de soporte deben ●● Categorías de incidencias
asignarse las categorías de incidencias. A su vez, la ●● Acciones adoptadas para resolver incidencias
Gestión de Incidencias puede mantener el estado de ●● Guión para el diagnóstico que puede ayudar a los
los CI defectuosos. También puede ayudar a la Gestión analistas de primera línea a resolver la incidencia,
de la Configuración a auditar la infraestructura cuando o al menos recopilar información que ayude a
se trabaje para resolver una incidencia. analistas de segunda o tercera línea a resolverla
■■ Gestión de Cambios: Cuando se requiere un cambio más rápidamente.
para implementar una solución temporal o una ■■ Registros de Incidencias, que incluyen los siguientes
resolución, éste necesitará registrarse como un RFC, datos:
y procesarse a través de la Gestión de Cambios. A
●● Un número de referencia único
su vez, la Gestión de Incidencias podrá detectar y
●● Categorización de incidencias
resolver incidencias que surjan de cambios fallidos.
●● Fecha y hora de registro y de cualquier actividad
■■ Gestión de la Capacidad: La Gestión de Incidencias
está preparada para monitorizar el rendimiento si se posterior
produce un problema de rendimiento. La Gestión de ●● Nombre e identidad de la persona que registra y

la Capacidad podría desarrollar soluciones temporales actualiza el Registro de Incidencias

para las incidencias. ●● Nombre/organización/detalles de contacto de los
■■ Gestión de la Disponibilidad; usará los datos usuarios afectados
de Gestión de Incidencias para determinar la ●● Descripción de los síntomas de las incidencias
disponibilidad de los servicios de TI y determinar ●● Detalles de cualquier acción tomada para intentar
dónde se puede mejorar el ciclo de vida de la diagnosticar, resolver o volver a crear la incidencia
incidencia. ●● Categoría, impacto, urgencia y prioridad de la
■■ SLM: La capacidad de resolver incidencias en un incidencia
tiempo especificado es una parte clave de la provisión ●● Relación con otras incidencias, problemas, cambios
de un nivel de servicio acordado. Gestión de Incidencias o Errores Conocidos
permite a SLM definir respuestas medibles a las ●● Detalles del cierre, incluyendo hora, categoría,
interrupciones del servicio. También ofrece informes acción tomada e identidad de la persona que
que permitan a SLM revisar SLA de forma objetiva y cierre el registro.
regularmente. En particular, Gestión de Incidencias
podrá ayudar a definir cuándo los servicios se Gestión de Incidencias también requiere acceso al CMS.
encuentran en su peor momento para que SLM pueda Esto ayudará a identificar los CI afectados por la incidencia
realizar acciones como parte del Programa de Mejora y también a estimar el impacto de la incidencia.
del Servicio (SIP). Vea la publicación Mejora Continua La Base de Datos de Errores Conocidos proporciona
del Servicio para disponer de más detalles. SLM define información valiosa sobre las posibles resoluciones y
los niveles aceptables de servicio dentro de los cuales soluciones provisionales. Esto se analiza con detalle en el
trabaja la Gestión de Incidencias, incluyendo: párrafo 4.4.7.2.
●● Tiempos de respuesta de incidencias
●● Definiciones de impactos 4.2.8  Métricas
●● Tiempos objetivos de reparación Las métricas que deben monitorizarse y difundirse sobre
●● Definiciones del servicio que se relacionan con los la valoración de la eficiencia y eficacia del proceso de
usuarios Gestión de Incidencias, y su operación, incluirán:
●● Reglas para solicitar servicios ■■ Número total de incidencias (como una medida de
●● Expectativas para proveer retroalimentación a los control)
usuarios. ■■ Lista detallada de incidencias en cada etapa (p. ej.,
registradas, trabajo en curso, cerradas, etc.)
4.2.7  Gestión de la Información
■■ Número de incidencias actuales acumuladas
La mayor parte de la información utilizada en Gestión de ■■ Número y porcentaje de incidencias graves
Incidencias procede de las siguientes fuentes:
■■ El tiempo medio transcurrido para lograr la resolución
■■ Las herramientas de Gestión de Incidencias, que o superación de la incidencia, desglosado por código
contienen información sobre: de impacto
 Procesos de Operación del Servicio | 61

■■ Porcentaje de incidencias atendidas dentro del tiempo auto-ayuda basadas en la web (que pueden acelerar la
de respuesta acordado (los objetivos de tiempo de asistencia y reducir los requisitos de recursos).
respuesta de incidencias podrían especificarse en ■■ Disponibilidad de la información sobre problemas
los SLA, por ejemplo, por código de impacto y de y Errores Conocidos. Esto permitirá al personal de
urgencia) Gestión de Incidencias aprender de las incidencias
■■ Coste promedio por incidencia previas y también realizar el seguimiento del estado
■■ Número de incidencias reabiertas y como porcentaje de las resoluciones.
del total ■■ La integración del CMS para determinar las relaciones
■■ Número y porcentaje de incidencias asignadas entre los CI y para hacer referencia al histórico de los
incorrectamente CI cuando se hace el soporte de primera línea.
■■ Número y porcentaje de incidencias clasificadas ■■ Integración en el proceso de SLM. Esto ayudará a
incorrectamente Gestión de Incidencias a analizar correctamente el
■■ Porcentaje de Incidencias cerradas por el Centro impacto y la prioridad de las incidencias y a ayudar
de Servicio al Usuario sin utilizar a otros niveles de en la definición y ejecución de procedimientos
soporte (con frecuencia se hace referencia a ello como de escalado. SLM también se beneficiará de la
‘primer punto de contacto’) información aprendida durante la Gestión de
■■ Número y porcentaje de incidencias procesadas por Incidencias, por ejemplo, para definir si los objetivos
operador del Centro de Servicio al Usuario de rendimiento de nivel de servicio son realistas y
alcanzables.
■■ Número y porcentaje de incidencias resueltas de forma
remota, sin la necesidad de realizar una visita
4.2.9.2  Factores Críticos de Éxito
■■ Número de incidencias manejadas por cada Modelo
de Incidencias Los siguientes factores serán críticos para lograr una
Gestión de Incidencias exitosa:
■■ Desglose de incidencias por hora del día, para ayudar
a precisar picos y garantizar la correspondencia de los ■■ Un buen Centro de Servicio al Usuario es clave para
recursos. una Gestión de Incidencias satisfactoria
Los informes deben generarse bajo la autoridad del ■■ Objetivos claramente definidos, tal y como se definen
Gestor de Incidencias, que elaborará una programación en los SLA
y una lista de distribución en colaboración con el Centro ■■ Formación técnica adecuada y orientada al cliente,
de Servicio al Usuario, y dará soporte a los grupos que dirigida a que el personal de soporte cuente con los
manejan incidencias. Las listas de distribución deben niveles de habilidad correctos en todas la etapas del
incluir al menos a la Gestión de Servicios de TI y grupos proceso
de soporte especializados. Considere también poner los ■■ Herramientas de soporte integradas para impulsar y
datos a disposición de los usuarios y clientes, por ejemplo, controlar el proceso
a través de informes acordados en SLA. ■■ OLA y UC que sean capaces de influir y modelar el
comportamiento correcto de todo el personal de
4.2.9 Desafíos, Factores Críticos de Éxito y soporte.
Riesgos
4.2.9.3  Riesgos
4.2.9.1  Desafíos Los riesgos para lograr una Gestión de Incidencias exitosa
Los siguientes desafíos estarán presentes para lograr una son realmente similares a algunos de los desafíos, y
Gestión de Incidencias exitosa: opuestos a algunos de los Factores Críticos de Éxito
■■ La capacidad de detectar incidencias lo antes posible.
mencionados anteriormente. Éstos incluyen:
Esto requerirá formar a los usuarios para que informen ■■ Inundación de incidencias que no se puedan manejar
de las incidencias, el uso de Súper Usuarios (vea el dentro de los plazos de tiempo aceptables debido a
párrafo 6.2.4.5), y la configuración de herramientas de la falta de disponibilidad de recursos o a la falta de
Gestión de Eventos. recursos formados adecuadamente
■■ Convencer a todo el personal (equipos técnicos ■■ Incidencias que están atascadas y que no progresan
y usuarios) de que deben registrarse todas las como es debido, todo ello provocado por
incidencias, y fomentar el uso de posibilidades de herramientas de soporte inadecuadas para elevar
alertas y avisos en curso
62 | Procesos de Operación del Servicio

■■ Falta de fuentes de información a tiempo y/o de categorización de alto nivel para identificar esas
adecuadas debido a herramientas inadecuadas o a la ‘incidencias’ que de hecho son Peticiones de Servicio).
falta de integración
Sin embargo, tenga en cuenta que aquí existe una
■■ Incompatibilidad en los objetivos y acciones debido a
diferencia significativa. Una incidencia normalmente es un
un alineamiento deficiente o a la falta de OLA y/o UC. evento sin planificar mientras que una Petición de Servicio
normalmente es algo que puede y debería planificarse.
4.3  Gestión de Peticiones Por lo tanto, en una organización donde se tienen que
El término ‘Petición de Servicio’ se utiliza como una manejar un gran número de Peticiones de Servicio, y
descripción general para muchos tipos diferentes de donde las acciones a tomar para satisfacer esas peticiones
demandas planteadas por los usuarios en el Departamento son muy variadas y especializadas, podría ser adecuado
de TI. Muchos de estos tipos son realmente pequeños manejar Peticiones de Servicio como un flujo de trabajo
cambios, de bajo riesgo, que se producen con frecuencia, completamente independiente, y registrarlas y manejarlas
de bajo coste, etc. (p. ej., una solicitud de cambio como un tipo de registro independiente.
de una contraseña, o una solicitud para instalar una Esto podría ser particularmente adecuado si la
aplicación de software adicional en una estación de organización hubiera decidido ampliar el ámbito del
trabajo particular, una solicitud para reubicar algunos Centro de Servicio al Usuario y usar este centro como un
componentes del equipo informático) o quizás sólo una centro de actividad para otros tipos de asuntos que no
pregunta que solicita información. Debido a su escala y estén relacionados con TI, o para la solicitud de servicios,
frecuencia, y a su naturaleza de bajo riesgo, sería mejor como por ejemplo una petición para dar servicio a una
que estas incidencias fueran manejadas por procesos fotocopiadora o incluir, por ejemplo, problemas sobre la
independientes, en lugar de congestionar u obstruir gestión de edificios, como la necesidad de reubicar un
los procesos normales de Gestión de Cambios y de mueble o reparar una fuga en las cañerías.
Incidencias.
Nota: en última instancia, esto permitirá a cada
4.3.1  Propósito/meta/objetivo organización decidir y documentar la petición que se
manejará a través del proceso de Gestión de Peticiones y
Gestión de Peticiones representa los procesos de manejo
aquellas que tendrán que pasar a través de un proceso de
de Peticiones de Servicio de los usuarios. Los objetivos del
Gestión de Cambios más formal. Siempre existirán áreas
proceso Gestión de Peticiones incluyen:
grises que impidan formular una guía genérica de utilidad.
■■ Proporcionar un canal para que los usuarios soliciten
y reciban servicios estándar para los que existe un 4.3.3  Valor para el negocio
proceso de cualificación y aprobación predefinido El valor de Gestión de Peticiones es proporcionar un
■■ Proporcionar información a los usuarios y clientes acceso rápido y eficaz a los servicios estándar que el
sobre la disponibilidad de los servicios y el personal del negocio pueda utilizar para mejorar su
procedimiento para obtenerlos productividad o la calidad de los servicios y productos del
■■ Aprovisionar y entregar los componentes de servicios negocio.
estándar solicitados (p. ej., licencias y medios de
Gestión de Peticiones reduce eficazmente la burocracia
software)
implicada en la solicitud y recepción de acceso a servicios
■■ Ayudar con información general, reclamaciones o
nuevos o existentes. Por lo tanto, también se reduce
comentarios.
el coste de suministro de estos servicios. La gestión
centralizada también aumenta el nivel de control sobre
4.3.2  Ámbito estos servicios. Esto a su vez puede ayudar a reducir
El proceso necesario para satisfacer una solicitud variará costes a través de una negociación centralizada con los
en función de lo que se está pidiendo exactamente. Este proveedores, y también puede ayudar a reducir el coste
proceso normalmente se podrá dividir en un conjunto de soporte.
de actividades que tienen que realizarse. Algunas
organizaciones se sentirán cómodas permitiendo que las 4.3.4  Políticas/principios/conceptos básicos
Peticiones de Servicio sean manejadas a través de sus
Muchas Peticiones de Servicio serán recurrentes, por
procesos de Gestión de Incidencias (y herramientas). En
lo que se puede idear un flujo (o modelo) de proceso
este caso las Peticiones de Servicio se manejan como
predefinido para incluir las etapas necesarias para
un tipo particular de ‘incidencia’ (usando un sistema
 Procesos de Operación del Servicio | 63

satisfacer una petición, los individuos o los grupos de 4.3.5.2  Aprobación Financiera
soporte implicados, las escalas de tiempo objetivo o las Un paso adicional importante, que probablemente
rutas de escalado. Normalmente, las Peticiones de Servicio será necesario al abordar una petición de servicio, es la
quedarán satisfechas mediante la implementación de un aprobación financiera.
Cambio Estándar (vea la publicación Transición del Servicio
para disponer de más detalles sobre Cambios Estándar). La La mayoría de las peticiones tendrán el mismo tipo de
responsabilidad de las Peticiones de Servicio reside en el implicaciones financieras, independientemente del tipo de
Centro de Servicio al Usuario, que monitoriza, escala, cursa acuerdo comercial existente. Primero debe establecerse
y con frecuencia satisface la solicitud del cliente. el coste de satisfacción de la petición. Podría ser posible
acordar precios fijos para peticiones ‘estándar’, y la
4.3.4.1  Modelos de Peticiones aprobación previa para tales peticiones podría darse
como parte de la gestión financiera general y anual de la
Algunas Peticiones de Servicio se producirán
organización. En todos los demás casos, debe generarse
frecuentemente y será necesario gestionarlas de forma
y enviarse al usuario una estimación del coste para la
consistente para cumplir los niveles de servicio acordados.
aprobación financiera (el usuario podría necesitar la
Para hacer esto, muchas organizaciones desearán crear
aprobación en su cadena financiera/de dirección). Si se
Modelos de Peticiones predefinidos (que típicamente
diera la aprobación, además de satisfacer la petición, el
incluyen alguna forma de aprobación previa por parte
proceso también debe incluir el cargo (facturación o cargo
de Gestión de Cambios). Esto es similar en concepto a la
cruzado) por el trabajo realizado, si el mismo hubiera sido
idea de Modelos de Incidencias ya descritos en el párrafo
establecido.
4.2.4.2, pero que se aplica a Peticiones de Servicio.
4.3.5.3  Otra aprobación
4.3.5  Actividades, métodos y técnicas del
En algunos casos podría ser necesaria una aprobación
proceso
posterior, como por ejemplo una aprobación extendida
4.3.5.1  Selección de menús del negocio o asociada al cumplimiento. Gestión de
Peticiones debe tener la capacidad de definir y comprobar
Gestión de Peticiones ofrece grandes oportunidades para
tales aprobaciones cuando sea necesario.
las prácticas de auto-ayuda en las que los usuarios pueden
generar una Petición de Servicio usando tecnología que
4.3.5.4  Cumplimiento
se vincule con herramientas de Gestión del Servicio.
Idealmente, se debe ofrecer a los usuarios una selección La actividad de cumplimiento real dependerá de la
de tipo ‘menú’, a través de una interfaz web, para que naturaleza de la Petición de Servicio. Algunas peticiones
puedan seleccionar e introducir detalles de Peticiones de más simples podrían completarse a través del Centro de
Servicio desde una lista predefinida, donde se pueden Servicio al Usuario, actuando como soporte de primera
establecer las expectativas apropiadas informando la línea, mientras que otras se tendrán que enviar a grupos
entrega y/u objetivos/fechas de implementación (en especializados y/o a proveedores para su gestión.
línea con los objetivos de los SLA). En caso de que las Algunas organizaciones tienen grupos de gestión
organizaciones estén ofreciendo una capacidad de TI de especializados (para ‘elegir, empaquetar y enviar’), o
auto-ayuda a los usuarios, debería tener sentido combinar podrían haber externalizado algunas actividades de
esto con un sistema de Gestión de Peticiones descrito gestión a terceros. El Centro de Servicio al Usuario
anteriormente. debe monitorizar y controlar el avance, y mantener
Se pueden utilizar directamente herramientas web a los usuarios informados convenientemente,
especializadas para ofrecer este tipo de experiencia independientemente de la fuente de gestión real.
de ‘cesta de la compra’ junto con interfaces para las
herramientas ITSM integradas de uso interno, u otras 4.3.5.5  Cierre
herramientas generales de automatización del proceso Cuando la Petición de Servicio se haya gestionado, ésta
de negocio o de Planificación de Recursos de la Empresa deberá devolverse al Centro de Servicio al Usuario para
(ERP) que se podrían utilizar para la gestión de las su cierre. El Centro de Servicio al Usuario debe pasar a
actividades de Gestión de Peticiones. través del mismo proceso de cierre descrito anteriormente
en el párrafo 4.2.5.9, comprobando que el usuario quede
satisfecho con el resultado.
64 | Procesos de Operación del Servicio

4.3.6 Disparadores, interfaces entre procesos ■■ Solicitudes de Cambio: En algunos casos el proceso de

de entradas y salidas Gestión de Peticiones se iniciará a través de una RFC.
Esto es típico si la Petición de Servicio se asocia a un
La mayoría de las peticiones se activarán a través de una
CI
llamada del usuario al Centro de Servicio al Usuario o a
■■ La Cartera de Servicios, para facilitar el ámbito de la
través de algún formulario de la pantalla de entrada de
auto-ayuda basada en web que rellene el usuario para Petición de Servicio según se haya acordado identificar
hacer su petición. En muchas ocasiones, este último ■■ Las Políticas de Seguridad formularán cualquier control
método implica una selección de un portfolio de tipos a llevar a cabo o al que adherirse en la provisión de
de peticiones disponibles. Las interfaces principales con un servicio, p. ej., garantizando que el solicitante esté
Gestión de Peticiones incluyen: autorizado a acceder al servicio, o que se licencie el
software.
■■ Gestión de Incidencias / Centro de Servicio al
Usuario: Muchas Peticiones de Servicio podrían venir 4.3.8  Métricas
a través del Centro de Servicio al Usuario y se podrían
Las métricas necesarias para juzgar la eficacia y eficiencia
manejar inicialmente a través del proceso de Gestión
de Gestión de Peticiones incluirán lo siguiente (cada
de Incidencias. Algunas organizaciones podrían
métrica necesitará desglosarse por tipo de petición, dentro
decidir que todas las peticiones se manejen a través
del periodo):
de esta ruta, pero otras podrían decidir disponer de
un proceso independiente, por razones ya analizadas ■■ Número total de Peticiones de Servicio (como una
anteriormente en este capítulo. medida de control)
■■ También es necesario crear un fuerte vínculo entre ■■ Lista detallada de peticiones de servicio en cada etapa
Gestión de Peticiones, Versiones, Activos y Gestión (p. ej., registradas, VIP, cerradas, etc.)
de la Configuración ya que algunas peticiones se ■■ El tamaño de la acumulación actual de incidencias de
corresponderán con el despliegue de componentes Peticiones de Servicio pendientes
nuevos o actualizados que se pueden desplegar ■■ El tiempo medio transcurrido para cumplimentar cada
automáticamente. En tales casos, la ‘versión’ puede tipo de Petición de Servicio
predefinirse, construirse, y probarse pero sólo ■■ El número y porcentaje de Peticiones de Servicio
desplegarse bajo petición de aquellos que desean la completadas dentro de los tiempos objetivo asignados
‘versión’. Después del despliegue, el CMS tendrá que
■■ El coste promedio por tipo de Petición de Servicio
actualizarse para reflejar el cambio. Donde proceda,
■■ Nivel de satisfacción del cliente con el manejo de
también serán necesarias las comprobaciones/
Peticiones de Servicio (medido con alguna forma de
actualizaciones de las licencias de software.
encuesta de satisfacción).
En algunos casos, será necesario relacionar las Peticiones
de Servicio asociadas con TI con cualquier incidencia o 4.3.9 Desafíos, Factores Críticos de Éxito y
problema que hubiera iniciado la necesidad de la petición riesgos
(como sería el caso de cualquier otro tipo de cambio).
4.3.9.1  Desafíos
4.3.7  Gestión de la Información Se afrontarán los siguientes desafíos al introducir la
Gestión de Peticiones depende de la información de las Gestión de Peticiones:
siguientes fuentes:
■■ Definir y documentar claramente el tipo de peticiones
■■ Las Peticiones de Servicio contendrán información sobre: que se atenderán dentro del proceso de Gestión
●● El servicio que se está solicitando de Peticiones (y aquellas que pasarán a través del
●● Quién pidió y autorizó el servicio Centro de Servicio al Usuario y se manejarán como
●● Qué proceso se utilizará para satisfacer la petición incidencias o aquellas que necesitarán pasar a través
de Gestión de Cambios formal), por lo que todas las
●● A quienes se asignó y qué acción se tomó
partes tendrán absolutamente claro el objetivo
●● La fecha y hora en las que se registró la petición
■■ Establecer capacidades front-end de auto-ayuda que
además de la fecha y hora de todas las acciones
permitan a los usuarios interactuar satisfactoriamente
tomadas
con el proceso de Gestión de Peticiones.
●● Detalles del cierre.
 Procesos de Operación del Servicio | 65

4.3.9.2  Factores Críticos de Éxito 4.4  Gestión de Problemas

La Gestión de Peticiones depende de los siguientes ITIL define un ‘problema’ como la causa desconocida de
Factores Críticos de Éxito: una o más incidencias.
■■ El acuerdo sobre cuáles servicios se estandarizarán y
quién está autorizado para solicitarlos. También debe 4.4.1  Propósito/meta/objetivo
fijarse el coste de estos servicios. Esto podría hacerse Gestión de Problemas es el proceso responsable de
como parte del proceso de SLM. Asimismo debe la gestión del ciclo de vida de todos los problemas.
definirse cualquier variante de los servicios. Los principales objetivos de Gestión de Problemas son
■■ Publicación de los servicios para los usuarios como prevenir problemas y las incidencias resultantes, eliminar
parte del Catálogo de Servicios. Es importante que incidencias recurrentes y minimizar el impacto de las
esta parte del Catálogo de Servicios sea fácilmente incidencias que no puedan prevenirse.
accesible, quizás a través de la Intranet, y debe
reconocerse como la primera fuente de información 4.4.2  Ámbito
para usuarios que están buscando acceso a un Gestión de Problemas incluye las actividades requeridas
servicio. para diagnosticar la causa raíz de las incidencias y para
■■ Definición de un procedimiento de gestión estándar determinar la resolución de esos problemas. También
para cada uno de los servicios que se están es responsable de garantizar que se implemente la
solicitando. Esto incluye todas las políticas de compras resolución a través de los procedimientos adecuados de
y la capacidad para generar órdenes de compra y control, especialmente Gestión de Cambios y Gestión de
órdenes de trabajo la Entrega.
■■ Un punto único de contacto que se pueda utilizar
Gestión de Problemas también mantendrá información
para solicitar un servicio. En muchas ocasiones este
sobre problemas y sobre las soluciones provisionales y
punto corresponde con el Centro de Servicio al
resoluciones apropiadas para que una organización pueda
Usuario o se realiza a través de una petición a través
reducir el número e impacto de las incidencias. A este
de la Intranet, pero podría ser a través de una petición
respecto, Gestión de Problemas dispone de una fuerte
automatizada dentro de la Gestión de Peticiones o a
interfaz con Gestión del Conocimiento, y herramientas
través del sistema de compras.
como Bases de Datos de Errores Conocidos que se usarán
■■ Herramientas de auto-ayuda necesarias para proveer en ambos.
una interfaz a los usuarios. Es esencial integrar
estas herramientas con las de gestión interna, con Aunque Gestión de Incidencias y de Problemas son
frecuencia gestionadas a través de Gestión de Cambios procesos independientes, están estrechamente asociados
e Incidencias. y normalmente utilizarán las mismas herramientas,
pudiendo definir sistemas similares de codificación de
4.3.9.3  Riesgos prioridad, impacto y categorización. Esto garantizará una
comunicación eficaz al tratar con problemas e incidencias
Los riesgos que se pueden encontrar con Gestión de
asociados.
Peticiones incluyen:
■■ Ámbito deficientemente definido, donde no está claro 4.4.3  Valor para el negocio
lo que se espera exactamente que el proceso debe La Gestión de Problemas trabaja junto con la Gestión
cubrir de Incidencias y la Gestión de Cambios para garantizar
■■ Interfaces de usuario deficientemente diseñadas la mejora de la disponibilidad y calidad del servicio
o implementadas, por lo que los usuarios tienen de TI. Cuando se resuelven las incidencias, se registra
dificultades a la hora de presentar peticiones que información sobre la resolución. Con el tiempo,
necesitan esta información se utiliza para acelerar el tiempo
■■ Procesos de gestión interna deficientemente diseñados de resolución e identificar soluciones permanentes,
u operados, que son incapaces de tratar el volumen o reduciendo el número y tiempo de resoluciones de
naturaleza de las peticiones que se están haciendo incidencias. Esto disminuye el tiempo de caída y las
■■ Capacidades inadecuadas de monitorización que interrupciones en los sistemas críticos del negocio.
hacen que no se puedan recopilar las métricas.
66 | Procesos de Operación del Servicio

El valor adicional se deriva de lo siguiente: 4.4.5.1  Detección de problemas

■■ Mayor disponibilidad de los servicios de TI Es probable que existan múltiples formas de detectar
■■ Mayor productividad del negocio y del personal de TI problemas en todas las organizaciones. Éstas incluyen:
■■ Reducción de gastos con respecto a soluciones ■■ Sospecha o detección por el Centro de Servicio al
provisionales y arreglos que no funcionan Usuario de una causa desconocida de una o más
■■ Reducción del coste del esfuerzo para apagar fuegos o incidencias, lo que genera un Registro de Problemas.
resolver incidencias repetidas. El centro de servicio al usuario puede haber resuelto
la incidencia pero no ha determinado o definido
4.4.4  Políticas/principios/conceptos básicos una causa definitiva y sospecha que es probable que
Éstos son algunos conceptos importantes de Gestión vuelva a producirse la incidencia, por lo que genera
de Problemas que deben tenerse en cuenta desde el un Registro de Problemas para permitir resolver
principio. Éstos incluyen: la causa subyacente. Alternativamente, podría ser
inmediatamente obvio desde el principio que una
4.4.4.1  Modelos de Problemas incidencia, o incidencias, hayan sido provocadas
por un problema grave, por lo que se generará un
Muchos problemas serán únicos y requerirán el
Registro de Problemas sin dilación.
tratamiento de forma individual. Pero es posible que
■■ El análisis de una incidencia por un grupo de
algunas incidencias puedan ser recurrentes debido a
soporte técnico que revela que existe un problema
problemas subyacentes o latentes (por ejemplo, cuando
subyacente, o que es probable que exista.
el coste de una resolución permanente es alto y se
ha tomado la decisión de no seguir adelante con una ■■ Detección automática del fallo de una infraestructura
solución cara, lo que implica ‘vivir con’ el problema). o aplicación, usando herramientas de eventos/
alertas que plantean automáticamente una incidencia
Además de crear un Registro de Errores Conocidos en que podría revelar la necesidad de un Registro de
la Base de Datos de Errores Conocidos (vea el párrafo Problemas.
4.4.5.7) para asegurar un rápido diagnóstico, podría ser ■■ Una notificación de un suministrador o contratista de
útil la creación de un Modelo de Problemas para tratar que existe un problema que se tiene que resolver.
tales problemas en el futuro. Esto es muy similar en
■■ Análisis de incidencias como parte de Gestión
concepto a la idea de Modelos de Incidencias ya descritos
Proactiva de Problemas, lo que genera la necesidad de
en el párrafo 4.2.4.2, pero que se aplica a problemas y a
plantear un Registro de Problemas para que se pueda
incidencias.
investigar posteriormente el fallo subyacente.

4.4.5  Actividades, métodos y técnicas del Deberá realizarse un análisis frecuente y regular de los
proceso datos de problemas y de incidencias para identificar
cualquier tendencia que pasase a ser tangible. Esto
Gestión de Problemas consiste en dos procesos
requerirá una categorización significativa y detallada
principales:
de incidencias/problemas y de una generación de
■■ La Gestión Reactiva de Problemas, que se ejecuta informes regular de patrones y áreas con gran número
generalmente como parte de Operación del Servicio , de incidencias. Para identificar tendencias, será útil una
y por lo tanto se recoge en esta publicación generación de informes ‘top ten’ con capacidad de
■■ Y la Gestión Proactiva de Problemas que se inicia
descenso hacia niveles de detalle mayores.
en Operación del Servicio, pero que generalmente se En la publicación Mejora Continua del Servicio se incluyen
dirige como parte de Mejora Continua del Servicio más detalles sobre cómo deben manejarse tendencias
(vea esta publicación para disponer de más detalles). detectadas.
El proceso de Gestión Reactiva de Problemas se muestra
en la Figura 4.4. Representa un gráfico simplificado que 4.4.5.2  Registro de problemas
muestra el flujo de proceso normal, pero en realidad Independientemente del método de detección, deberán
algunos de los estados podrían ser repetitivos o podrían registrarse todos los detalles relevantes del problema para
tener que hacerse variaciones para manejar situaciones que exista un registro histórico completo. Cada registro
particulares. debe marcarse con su fecha y hora para permitir el
escalado y control adecuados.
 Procesos de Operación del Servicio | 67

Gestión
Centro de Servicio Gestión Gestión Suministrador
Proactiva
al Usuario. de Eventos de Incidencias o Contratista
de Problemas

Detección
del Problema

Registro
del Problema

Categorización

Priorización

CMS
Investigación
y Diagnóstico

¿Solución
Temporal?

Crear Registro Base de Datos

de Error Conocido de Errores
Conocidos

Gestión Sí ¿Se Requiere

de Cambios un Cambio?

No

Resolución

Cierre

¿Problema Revisión de
Grave? Problema Grave

Figura 4.4 Flujo del

proceso de Gestión
Fin de Problemas
68 | Procesos de Operación del Servicio

Debe realizarse una referencia cruzada con la incidencia 4.4.5.5  Investigación y Diagnóstico de Problemas
que inició el Registro de Problemas, y deberán copiarse Deberá realizarse una investigación para intentar
todos los detalles pertinentes desde los Registros de diagnosticar la causa raíz del problema. La velocidad y
Incidencias hasta el Registro de Problemas. Es difícil naturaleza de esta investigación variará dependiendo
lograr la exactitud ya que los casos podrían variar, pero del impacto, severidad y urgencia del problema, aunque
normalmente incluirá detalles como: se deberá aplicar el nivel apropiado de recursos y de
■■ Datos del usuario experiencia para encontrar una resolución proporcionada
■■ Detalles del servicio al código de prioridad asignado y con el objetivo del
■■ Detalles de los equipos
servicio para ese nivel de prioridad.
■■ Fecha/hora registrada inicialmente Existen varias técnicas útiles de resolución de problemas
■■ Detalles de categorización y prioridad que se pueden utilizar para ayudar al diagnóstico y
■■ Descripción de incidencias resolución, y éstas deberán utilizarse apropiadamente.
Estas técnicas se describirán posteriormente con más
■■ Detalles de todas las acciones de diagnóstico o de
detalle en esta sección.
intento de recuperación efectuadas.
El CMS debe usarse para ayudar a determinar el nivel de
4.4.5.3  Categorización de Problemas impacto y para ayudar a precisar y diagnosticar el punto
Los problemas deberán categorizarse de la misma forma exacto de fallo. También se debe poder acceder a la Base
que las incidencias (y es aconsejable utilizar el mismo de Datos de Errores Conocidos (KEDB) y deberán utilizarse
sistema de codificación) de tal forma que se pueda trazar las técnicas de correspondencia de problemas (como por
fácilmente en el futuro la naturaleza real del problema y ejemplo búsquedas de palabras clave) para determinar si
se pueda obtener información de gestión significativa. el problema se ha producido anteriormente, y si fuera así,
encontrar la resolución utilizada.
4.4.5.4  Priorización de Problemas En muchas ocasiones sería provechoso intentar recrear
Los problemas deben priorizarse de la misma forma y el fallo para entender lo que está saliendo mal, y a
por las mismas razones que las incidencias, pero también continuación intentar distintas formas de encontrar
deberán tenerse en cuenta la frecuencia e impacto de las la resolución más apropiada y rentable para el
incidencias asociadas. El sistema de codificación descrito problema. Para hacer esto de forma eficaz sin provocar
anteriormente en la Tabla 4.1 (que combina impacto interrupciones posteriores para los usuarios, será necesario
con urgencia para dar un nivel de prioridad general), se utilizar un problema de prueba que refleje el entorno de
podrá utilizar para priorizar problemas de la misma forma producción.
que podría utilizarse para las incidencias, no obstante, Existen muchas técnicas de análisis, diagnóstico y de
las definiciones y guías para apoyar al personal sobre lo resolución de problemas, y se han realizado muchas
que constituye un problema, y los objetivos de servicio investigaciones en este área. Algunas de las técnicas más
asociados con cada nivel, obviamente deberán diseñarse útiles y más frecuentemente utilizadas incluyen:
por separado.
■■ Análisis Cronológico: Al tratar con un problema
La priorización de problemas también tiene que tener en difícil, a menudo existen informes conflictivos sobre lo
cuenta la severidad de los problemas. La severidad, en que ha ocurrido exactamente y cuándo. Por lo tanto,
este contexto, hace referencia al grado de seriedad del es muy útil documentar brevemente todos los eventos
problema desde la perspectiva de una infraestructura, por en orden cronológico para proporcionar una línea de
ejemplo: tiempo de dichos eventos. A menudo esto posibilita
■■ ¿Se puede recuperar el sistema, o es necesario ver cuáles eventos podrían haber sido provocados por
sustituirlo? otros, o desestimar cualquier reclamación que no esté
■■ ¿Cuánto costará?
respaldada por la secuencia de los eventos.
■■ Análisis del Valor de los Daños: Aquí es donde se
■■ ¿Cuántas personas, con qué habilidades, serán
toma un punto de vista más amplio del impacto y el
necesarias para solucionar el problema?
tipo de una incidencia o problema. En lugar de analizar
■■ ¿Cuánto tiempo se tardará en solucionar el problema?
únicamente el número de incidencias/problemas de
■■ ¿Qué alcance tiene el problema (p. ej., ¿cuántos CI se
un tipo particular en un periodo particular, se realiza
ven afectados)? un análisis de mayor profundidad para determinar
exactamente el nivel de los daños que se ha producido
 Procesos de Operación del Servicio | 69

en la organización/negocio debido a estas incidencias/ potenciales para resolver el problema. Estas sesiones
problemas. Se puede idear una fórmula para calcular pueden ser muy constructivas e innovadoras pero es
este nivel de daño. Típicamente, habría que tener en igualmente importante que alguien, quizás el Gestor
cuenta: de Problemas, documente el resultado y cualquier
●● El número de personas afectadas acción acordada, y mantenga un grado de control en
●● La duración del tiempo de caída las sesiones.
●● El coste para el negocio (si esto se pudiera calcular ■■ Diagramas de Ishikawa: Kaoru Ishikawa (1915–89),
o estimar rápidamente). un líder Japonés en control de calidad, desarrolló un
método de documentación de causas y efectos que
Teniendo en cuenta todos estos factores, se puede
puede ser útil para ayudar a identificar dónde algo
determinar una imagen mucho más detallada de esas
podría ir mal, o cómo podría mejorarse. Este diagrama
incidencias/problemas o tipos de incidencias/problemas
corresponde típicamente como resultado de una
que están causando los mayores daños; y de esta forma
sesión de tormenta de ideas donde los solucionadores
obtener un mejor enfoque de lo que realmente importa y
de problemas pueden ofrecer sugerencias. El objetivo
merece la máxima prioridad de resolución.
principal se representa mediante el tronco del
■■ Kepner y Tregoe: Charles Kepner y Benjamin Tregoe diagrama, y los factores principales se representan
desarrollaron una forma útil de análisis de problemas como ramas. Los factores secundarios se añaden como
que se puede utilizar formalmente para investigar tallos, y así sucesivamente. La creación del diagrama
problemas cuya causa es compleja. Definieron las estimula la discusión y en muchas ocasiones mejora
siguientes etapas: el entendimiento de un problema complejo. En el
●● definición del problema Apéndice D se incluye el ejemplo de esta técnica.
●● descripción del problema en términos de ■■ Análisis de Pareto: Esta es una técnica para separar
identidad, ubicación, tiempo y tamaño causas potencialmente importantes de problemas más
●● establecimiento de las causas posibles triviales. Deberán seguirse los siguientes pasos:
●● prueba de la causa más probable 1 Cree una tabla que liste las causas y su frecuencia
●● verificación de la causa real. en forma de porcentaje.
2 Ordene las filas en orden descendente de
El método se describe con mayor detalle en el
importancia de las causas, es decir, primero la causa
Apéndice C.
más importante.
■■ Tormenta de ideas (Brainstorming): En muchas 3 Añada a la tabla una columna de porcentaje
ocasiones puede ser valioso reunir a las personas acumulado. A través de este paso, el gráfico debería
relevantes, físicamente o por medios electrónicos, y asemejarse a algo similar a la Tabla 4.2, que ilustra
‘aplicar la lluvia o tormenta de ideas’ al problema, 10 causas de fallo de red en una organización.
de tal forma que se expongan sus ideas sobre lo 4 Cree un gráfico de barras con las causas ordenadas
que podría ser la causa potencial y las acciones según sus porcentajes con respecto al total.

Tabla 4.2 Gráfico de clasificación de causas de Pareto

Fallos de red
Causas Porcentaje del total Cálculo % acumulado
Controlador de red 35 0+35% 35
Corrupción de archivos 26 35%+26% 61
Conflictos de direccionamiento 19 61%+19% 80
Server OS 6 80%+6% 86
Error de script 5 86%+5% 91
Cambio sin probar 3 91%+3% 94
Error del operador 2 94%+2% 96
Fallo de backup 2 96%+2% 98
Intentos de intrusión 1 98%+1% 99
Fallo de disco 1 99%+1% 100
70 | Procesos de Operación del Servicio

Fallos de la Red pero es importante que el trabajo en buscar una

40 120 solución permanente continúe siempre y cuando esté
justificado. En este ejemplo, lo primero que habría que
35 hacer es encontrar y corregir la razón de que el archivo
100 se corrompa para evitar que este hecho se produzca
nuevamente.
30
En casos donde se encuentre una solución provisional, es
80
25 importante que el registro del problema siga abierto, y los
detalles de la solución temporal siempre se documenten
dentro del Registro de Problemas.
20 60

4.4.5.7  Plantear un Registro de Errores

15
40 Conocidos
En cuanto se complete el diagnóstico, y particularmente
10
en el caso en el que se haya encontrado una solución
20 temporal (incluso cuando ésta no constituyera una
5
solución permanente), debe plantearse un Registro de
Errores Conocidos e introducirse en una Base de Datos
0 0 de Errores Conocidos para que, en el caso de que surjan
Controlador de red

Conflictos de direcciones
Corrupción de archivos

Cambio no probado

Error del operador

Error de scripts

Intentos de intrusión
Servidor del SO

Fallo de disco
Fallo de backup

incidencias o problemas posteriores, éstos puedan

identificarse y se pueda restablecer el servicio con mayor
rapidez.
Sin embargo, en algunos casos, podría ser ventajoso
plantear un Registro de Errores Conocidos incluso
anticipadamente en el proceso general. Este registro sólo
Figura 4.5 Comparación de causas importantes con sería para propósitos de información por ejemplo, incluso
triviales si no se puede completar el diagnóstico o no se encuentra
una solución temporal, por lo que es desaconsejable
establecer un punto procedimental concreto cuando deba
5 Superponga un gráfico de línea de los porcentajes plantearse un Registro de Errores Conocidos. Esto debería
acumulados. El gráfico completo se ilustra en la hacerse tan pronto como sea útil.
Figura 4.5.
La Base de Datos de Errores Conocidos y la forma en
6 Dibuje una línea en el 80% del eje y paralela al
la que debe usarse se describen con más detalle en el
eje x. A continuación prolongue la línea hasta el
párrafo 4.4.7.2.
punto de intersección con la curva en el eje x. Este
punto en el eje x separa las causas importantes y las
4.4.5.8  Resolución de problemas
causas triviales. Esta línea se representa como una
línea de puntos en la Figura 4.5. Idealmente, en cuanto se encuentre una solución, ésta
se debería aplicar para resolver el problema, aunque en
Desde este gráfico se ve claramente que existen tres realidad, podría ser necesario tomar precauciones para
causas principales de fallos de red en la organización. Por garantizar que no se provoquen dificultades posteriores.
lo tanto, éstas deberán afrontarse primero. Si se requiriera algún cambio en la funcionalidad, será
necesario plantear y aprobar una RFC antes de que se
4.4.5.6  Soluciones provisionales pueda aplicar la resolución. Si el problema fuera muy
En algunos casos, podría ser posible encontrar una grave y se necesitara un arreglo urgente por razones del
solución provisional para las incidencias provocadas negocio, entonces el Comité de Cambios / Comité de
por un problema, una forma temporal de superar las Emergencia (CAB/EC) gestionará una RFC de emergencia
dificultades. Por ejemplo, se podría realizar una corrección para facilitar esta acción urgente. De lo contrario, la
manual en un archivo de entrada para permitir que un RFC deberá seguir el proceso establecido de Gestión de
programa complete su ejecución con éxito y permitir Cambios para ese tipo de cambio, y deberá aplicarse la
completar correctamente un proceso de facturación, resolución sólo cuando se haya aprobado y programado el
 Procesos de Operación del Servicio | 71

cambio. Mientras tanto, la KEDB deberá usarse para ayudar Conocidos. El Gestor de Problemas facilita la reunión y
a resolver rápidamente cualquier aparición posterior de las documenta cualquier acción acordada.
incidencias/problemas que se produzcan.
El conocimiento aprendido de la revisión deberá
Nota: Podrían existir algunos problemas para los que no incorporarse en una reunión de revisión del servicio con
se pudiera justificar un Caso de Negocio de resolución el cliente del negocio para garantizar que el cliente sea
(p. ej., cuando el impacto fuese limitado pero el coste de consciente de las acciones y planes tomados para evitar
la resolución fuese extremadamente alto). En tales casos, que las incidencias graves se vuelvan a producir en el
podría tomarse la decisión de dejar abierto el Registro futuro. Esto ayuda a mejorar la satisfacción del cliente y
de Problemas y usar la descripción de una solución a asegurar al negocio que Operaciones del Servicio está
temporal en el Registro de Errores Conocidos para detectar manejando incidencias graves de forma responsable y
y resolver cualquier reaparición rápidamente. Se debe trabajando activamente para evitar que se vuelvan a
tener cuidado de usar el código apropiado para rellenar producir en el futuro.
adecuadamente el Registro de Problemas abierto de
forma que no perjudique el rendimiento del equipo que 4.4.5.11  Errores detectados en el entorno de
realiza el proceso, y que no se lleven a cabo trabajos sin desarrollo
autorización.
Sería raro que nuevas aplicaciones, sistemas o versiones
de software estén completamente libres de errores. Es
4.4.5.9  Cierre de Problemas más probable que durante la prueba de estas nuevas
Cuando se haya completado algún cambio (y revisado aplicaciones, sistemas o versiones se utilice un sistema
satisfactoriamente), y se haya aplicado la resolución, el de priorización para erradicar los fallos más serios, pero
Registro de Problemas deberá cerrarse formalmente, es posible que no se rectifiquen los fallos menores. Esto
así como cualquier Registro de Incidencias relacionado a menudo se debe al equilibrio que tiene que haber
que todavía estuviera abierto. En ese momento deberá entre entregar nuevas funcionalidades al negocio lo antes
realizarse una comprobación para garantizar que el posible, y asegurar componentes o códigos libres de fallos.
registro contiene una descripción histórica completa de
Cuando se toma una decisión de lanzar algo en el entorno
todos los eventos, y si no fuera así, el registro deberá
de producción que incluye deficiencias conocidas, éstas
actualizarse.
deben registrarse como Errores Conocidos en la KEDB,
Se deberá actualizar el estado de cualquier Registro junto con los detalles de las soluciones temporales o
de Errores Conocidos relacionado para mostrar que la actividades de resolución. Debería haber un paso formal
resolución se ha aplicado. en la aprobación de la prueba que garantice que este
traspaso siempre tenga lugar (vea la publicación Transición
4.4.5.10  Revisión de Problemas Graves del Servicio).
Después de cualquier problema grave (determinados por La experiencia ha demostrado que si ésto no se produjera,
el sistema de prioridades de la organización), mientras implicará costes de soporte más elevados cuando los
la memoria todavía esté reciente, deberá realizarse una usuarios empiecen a experimentar fallos y a plantear
revisión para aprender cualquier lección para el futuro. incidencias que tienen que rediagnosticarse y resolverse
Específicamente, la revisión deberá examinar: nuevamente.
■■ Aquellas cosas que se hicieron correctamente
■■ Aquellas cosas que se hicieron incorrectamente 4.4.6 Disparadores, interfaces entre procesos
■■ Qué podría hacerse mejor en el futuro de entradas y salidas
■■ Cómo evitar la repetición de Problemas La gran mayoría de Registros de Problemas se activarán
■■ Si hubiera habido alguna responsabilidad de terceros y como reacción a una o más incidencias, y muchos serán
si fueran necesarias acciones de seguimiento. creados o iniciados a través del personal del Centro de
Servicio al Usuario. Otros Registros de Problemas, y los
Tales revisiones se pueden utilizar como parte de las
correspondientes Registros de Errores Conocidos, podrían
actividades de concienciación y de formación dirigidas al
activarse durante la fase de pruebas, particularmente en
personal de soporte, y cualquier lección aprendida deberá
las últimas etapas de prueba como por ejemplo durante
documentarse en procedimientos adecuados, instrucciones
las Pruebas de Aceptación del Usuario (UAT), si se tomara
de trabajo, scripts de diagnóstico o Registros de Errores
la decisión de ir adelante con una versión incluso cuando
se conocen algunos fallos. Los suministradores podrían
72 | Procesos de Operación del Servicio

activar la necesidad de algunos Registros de Problemas proactivas. Gestión de Problemas proporciona

a través de la notificación de fallos potenciales o de información de gestión relativa a la calidad de
deficiencias conocidas en sus productos o servicios (p. las decisiones tomadas durante el proceso de
ej., se podría recibir un aviso para vigilar el uso de un CI Planificación de la Capacidad.
particular, y se podría crear un Registro de Problemas ●● Continuidad del Servicio de TI: Gestión de
para facilitar la investigación por parte del personal Problemas actúa como un punto de entrada
técnico del estado de esos CIs dentro de la Infraestructura en Gestión de la Continuidad del Servicio de TI
de TI de la organización). cuando no se resuelva un problema significativo
La relación principal entre Gestión de Problemas y Gestión antes de que empiece a tener un impacto
de Incidencias se ha analizado con detalle en los párrafos importante sobre el negocio.
4.2.6 y 4.4.5.1. Otras interfaces clave incluyen lo siguiente: ■■ Mejora Continua del Servicio
●● Gestión del Nivel de Servicio: Las incidencias y
■■ Transición del Servicio
problemas afectan al nivel de entrega del servicio
●●Gestión de Cambios: Gestión de Problemas medido por SLM. Gestión de Problemas contribuye
garantiza que todas las resoluciones o soluciones a las mejoras en los niveles de servicio, y su
provisionales que requieren un cambio en un CI, se información de gestión se utiliza como la base de
envíen a través de Gestión de Cambios mediante algunos de los componentes de revisión de los
una RFC. Gestión de Cambios monitorizará el SLA. SLM también proporciona parámetros con
progreso de estos cambios y mantendrá informado los que Gestión de Problemas trabaja, como por
a Gestión de Problemas. Gestión de Problemas ejemplo información del impacto y el efecto en
también está implicada en la rectificación de la los servicios de resoluciones y medidas proactivas
situación provocada por cambios fallidos. propuestas.
●● Gestión de la Configuración: Gestión de
■■ Estrategia del Servicio
Problemas usa el CMS para identificar los CI
●● Gestión Financiera: Ayuda a evaluar el impacto
defectuosos y también para determinar el impacto
de las resoluciones o soluciones provisionales
de problemas y resoluciones. El CMS también
propuestas, además del Análisis del Valor de
se puede utilizar para formar la base de la KEDB
los Daños. Gestión de Problemas proporciona
y mantener o integrarse con los Registros de
información de gestión sobre el coste de
Problemas.
resolución y prevención de problemas, que
●● Gestión de Versiones y Despliegues: Es
se utiliza como entrada en los sistemas de
responsable de lanzar las soluciones a problemas preparación de presupuestos y de contabilidad
en el entorno de producción. También ayuda de costes, y en los cálculos de Coste Total de
a asegurar que los errores conocidos asociados Propiedad.
se transfieran desde la Base de Datos de Errores
Conocidos de desarrollo hasta la Base de Datos 4.4.7  Gestión de la Información
de Errores Conocidos de producción. Gestión de
Problemas ayudará a resolver problemas causados 4.4.7.1  CMS
por fallos durante el proceso de lanzamiento.
El CMS contendrá los detalles de todos los componentes
■■ Diseño del Servicio de la Infraestructura de TI además de las relaciones entre
●● Gestión de la Disponibilidad: Está implicada estos componentes. Actuará como una fuente valiosa para
a la hora de determinar cómo reducir el tiempo el diagnóstico de problemas y para evaluar el impacto
de caída y aumentar el tiempo de disponibilidad. de los problemas (p. ej., si este disco se ha caído, qué
Como tal, tiene una estrecha relación con datos están en ese disco; qué servicios usan esos datos;
Gestión de Problemas, especialmente en las áreas qué usuarios usan esos servicios). Puesto que contendrá
proactivas. Buena parte de la información de detalles de actividades previas, también se puede utilizar
gestión disponible en Gestión de Problemas se como una fuente valiosa de datos históricos para ayudar
comunicará a Gestión de la Disponibilidad. a identificar tendencias o debilidades potenciales.
●● Gestión de la Capacidad: Algunos problemas Representa una parte de Gestión Proactiva de Problemas
requerirán una investigación por parte de los (vea la publicación Mejora Continua del Servicio).
equipos y técnicas de Gestión de la Capacidad,
p. ej., problemas de rendimiento. Gestión de la
Capacidad también ayudará a evaluar medidas
 Procesos de Operación del Servicio | 73

4.4.7.2  Base de Datos de Errores Conocidos La KEDB debe usarse durante las fases de Diagnóstico
El propósito de una Base de Datos de Errores Conocidos de Problemas e Incidencias e intentar acelerar el proceso
es permitir el almacenamiento del conocimiento previo de resolución, y deberán añadirse nuevos registros lo
de incidencias y problemas, y cómo se superaron, para más rápidamente posible cuando se haya identificado y
permitir acelerar el diagnóstico y resolución si se volvieran diagnosticado un problema.
a producir. Todo el personal de soporte deberá estar perfectamente
El Registro de Errores Conocidos debe contener detalles formado y familiarizado con el valor que la KEDB puede
exactos del fallo y de los síntomas que se produjeron, ofrecer y la forma en la que debería usarse. Deberían ser
junto con los detalles precisos de cualquier solución capaces de recuperar y usar datos fácilmente.
provisional o acción de resolución que se podría tomar Nota: Algunas herramientas/implementaciones podrán
para restaurar el servicio y/o resolver el problema. Un distinguir o delinear los Errores Conocidos cambiando
recuento de incidencias también será útil para determinar simplemente un campo en el Registro de Problemas
la frecuencia con la que éstas se podrían producir original. Esto es aceptable siempre que esté disponible el
nuevamente y determinar las prioridades, etc. mismo nivel de funcionalidad deseado.
Se debe tener en cuenta que puede que no exista un Caso La KEDB, como el CMS, forma parte de un Sistema de
de Negocio para la resolución permanente de algunos Gestión del Conocimiento del Servicio (SKMS) que se
problemas. Por ejemplo, si un problema no provocase una ilustra en la Figura 4.6. Puede encontrar información sobre
discontinuidad seria y existiera una solución provisional el SKMS en el libro Transición del Servicio.
y/o el coste de resolución del problema pesara mucho
más que los beneficios de una resolución permanente,
entonces se podría tomar una decisión para tolerar
la existencia del problema. Sin embargo, aún sería
conveniente diagnosticar e implementar una solución
provisional lo más rápidamente posible, que es donde la
KEDB puede ser de ayuda.
Es esencial que cualquier dato introducido en la base de
datos se pueda recuperar rápidamente y con precisión. El
Gestor de Problemas debe estar perfectamente formado
y estar familiarizado con los métodos/algoritmos de
búsqueda usados por la base de datos seleccionada y
debe garantizar con precisión que cuando se añadan
nuevos registros, se incluyan correctamente los pertinentes
criterios clave de búsqueda.
Debe prestarse atención para evitar la duplicación de
registros (p. ej., el mismo problema descrito en dos o
más formas como registros independientes). Para evitar
esto, el Gestor de Problemas debe ser la única persona
responsable de introducir un nuevo registro. Se debe
permitir y, por supuesto, motivar a otros grupos de
soporte para que propongan nuevos registros, pero
el Gestor de Problemas debe examinarlos antes de
introducirlos en la KEDB. En organizaciones grandes,
en las que exista personal de Gestión de Problemas
en múltiples ubicaciones pero sólo se utilice una KEDB
(¡recomendado!), deberá acordarse un procedimiento
entre todo el personal de Gestión de Problemas para
garantizar que no se produzca tal duplicación. Esto podría
implicar la designación de sólo un miembro del personal
como Gestor de KEDB centralizada.
74 | Procesos de Operación del Servicio

Cambiar y Entregar Gestión de Activos Ciclo de Vida Configuración Técnica Gestión de la Calidad
Centro de Servicio al
Capa de Configuración Ver Usuario Ver
Ver Ver Ver Ver
Presentación Configuraciones del Activos del usuario
Programaciones/Planes Activo Financiero Aplicaciones de Activo y Configuración
Cambiar Estado Petición Activo Informe de Proyecto Servicio Políticas de Gestión,
Configuración del usuario,
Portal Configuración, líneas Cambios, Versiones, Activo
Cambiar agenda y Estado Aplicación Procesos,
minutas del Comité de Cuentas y Facturas de referencia y Entorno Procedimientos,
y Elemento de
Cambios Gestión de Licencias cambios de Entorno de Prueba formularios, plantillas,
Configuración e
Rendimiento de los Estrategia, Diseño, Infraestructura listas de comprobación
incidencias, problemas,
Activos Transición, Operación soluc. temporales, cambios
del Servicio relacionados
Buscar, Navegar, Almacenar, Recuperar, Actualizar, Publicar, Suscribir, Colaborar

Capa de Monitorización
Elaboración de Gestión del Rendimiento
Procesamiento Consulta y Análisis Modelado Cuadros Mando Integrales,
Informes Previsión, Planificación, Presupuestación
del Conocimiento Paneles Control, Alertas

Negocio/Cliente/Suministrador/Usuario – Servicio – Aplicación– Infraestructura asignación

Capa de
Integración Portfolio de Servicios Cambio del Servicio
de Información Catálogo de Servicios Modelo
CMDB integrado Entrega del Servicio
de Servicio

Proceso Común, Reconciliación Sincronización

Correlación del Gestión de Extraer,
Modelo de Datos de Datos de Datos Mining
Esquema Meta Datos Transformar, Carga
e Información

Integración de Datos

Biblioteca Definitiva CMDBs Físicas

Almac. de Datos de Plataforma Gestión Herramientas Aplicaciones
de Medios Herramientas de Configuración de Descubri-
Doc. del Proyecto Empresariales
Biblioteca Definitiva Configuración E.g. Base Software miento, Gestión de Accesos
Fuentes y CMDB1 de Datos de Gestión de
de Documentos Recursos Humanos
Herramientas de Almacenamiento Activos y
Datos e Estructurado Gestión de la Cadena
Biblioteca Definitiva Middleware Red auditoría de Suministro Gestión
Información CMDB2 Mainframe Escritorio
Multimedia 1 de las Relaciones con
Distribuido Móvil los Clientes
Software
Biblioteca Definitiva
del Proyecto CMDB3
Multimedia 2

Figura 4.6 Sistema de Gestión del Conocimiento del Servicio

4.4.8  Métricas ■■ El porcentaje de Revisiones de Problemas Graves

Las siguientes métricas deben usarse para juzgar la eficacia completadas satisfactoriamente y a tiempo.
y eficiencia del proceso de Gestión de Problemas, o su Todas las métricas deberán dividirse por categoría,
operación: impacto, severidad, urgencia y nivel de prioridad, y se
■■ Número total de problemas registrados en el periodo deben comparar con periodos previos.
(como una medida de control)
■■ El porcentaje de los problemas resueltos dentro de los
4.4.9 Desafíos, Factores Críticos de Éxito y
objetivos de los SLA (y el porcentaje de los que no se riesgos
han resuelto) Una dependencia importante para Gestión de Problemas
■■ El número y porcentaje de problemas que superaron es la implantación de herramientas y de un proceso
sus tiempos de resolución objetivo de Gestión de Incidencias efectivo. Esto garantizará la
■■ La acumulación de problemas pendientes y la identificación de problemas lo antes posible y que se
tendencia (estática, reduciéndose o aumentando) haga el máximo trabajo de pre-calificación. Sin embargo,
■■ El coste promedio de manejar un problema también es crítico que los dos procesos tengan interfaces
formales y prácticas de trabajo en común. Esto implica lo
■■ El número de problemas graves (abiertos y cerrados y
siguiente:
acumulados)
■■ El porcentaje de Revisiones de Problemas Graves ■■ Vincular las herramientas de Gestión de Problemas y
realizadas satisfactoriamente de Incidencias
■■ El número de Errores Conocidos añadidos a la KEDB ■■ La capacidad de asociar Registros de Problemas y de
■■ La exactitud en porcentaje de la KEDB (de auditorías Incidencias
de la base de datos)
 Procesos de Operación del Servicio | 75

■■ El personal de segunda y tercera línea debe tener una 4.5.3  Valor para el negocio
buena relación de trabajo con el personal de primera Gestión de Accesos proporciona el siguiente valor:
línea
■■ Asegurar que el personal que trabaja en la resolución ■■ El acceso controlado a los servicios garantiza que la
de problemas entienda bien el impacto en el negocio organización sea capaz de mantener más eficazmente
la confidencialidad de su información
Además, es importante que Gestión de Problemas pueda ■■ Los empleados tienen el nivel correcto de acceso para
usar todos los recursos disponibles de Gestión de la realizar sus funciones de forma eficaz
Configuración y del Conocimiento.
■■ Existe menos probabilidad de que un usuario
Otro CSF es la formación continua del personal técnico inexperto cometa errores en la entrada de datos o en
tanto en los aspectos técnicos de su trabajo como en las el uso de un servicio crítico (p. ej., sistemas de control
implicaciones del negocio de los servicios a los que dan de producción)
soporte y de los procesos que usan. ■■ La capacidad de auditar el uso de los servicios y de
rastrear el abuso de los servicios
4.5  Gestión de Accesos ■■ La capacidad de revocar con más facilidad
los derechos de acceso cuando sea necesario;
Gestión de Accesos es el proceso de concesión del consideración importante de seguridad
derecho de uso de un servicio a usuarios autorizados
■■ Podría ser necesario para el cumplimiento de las
mientras que se evita el acceso a otros usuarios no
normas regulatorias (p. ej., SOX, HIPAA, COBIT).
autorizados. También se ha hecho referencia a este
proceso como Gestión de Derechos o Gestión de
4.5.4  Políticas/principios/conceptos básicos
Identidades en diferentes organizaciones.
Gestión de Accesos es el proceso que permite a los
4.5.1  Propósito/meta/objetivo usuarios usar los servicios que están documentados en el
Catálogo de Servicios. Consta de los siguientes conceptos
Gestión de Accesos proporciona el derecho de los usuarios
básicos:
a poder usar un servicio o grupo de servicios. Por lo tanto,
es la ejecución de políticas y acciones definidas en Gestión ■■ Acceso hace referencia al nivel y amplitud de la
de la Disponibilidad y de la Seguridad. funcionalidad de un servicio o de los datos que el
usuario tiene derecho a utilizar.
4.5.2  Ámbito ■■ Identidad hace referencia a la información sobre
Gestión de Accesos es efectivamente la ejecución de aquellas personas que se distinguen como un
Gestión de la Seguridad de la Información y de Gestión individuo, verificando su estado dentro de la
de la Disponibilidad, y eso permite a la organización organización. Por definición, la Identidad de un
gestionar la confidencialidad, disponibilidad e integridad usuario es única para ese usuario. (Esto se analiza con
de los datos y de la propiedad intelectual de la más detalle en el párrafo 4.5.7.1).
organización. ■■ Derechos (también denominados privilegios) hacen
referencia a los ajustes reales por medio de los cuales
Gestión de Accesos garantiza que se conceda a los
a un usuario se le proporciona acceso a un servicio
usuarios el derecho de uso de un servicio, pero no
o grupo de servicios. Los derechos típicos, o niveles
garantiza que este acceso esté disponible durante todo el
de acceso, incluyen leer, escribir, ejecutar, cambiar,
tiempo acordado. Esto lo proporcionará la Gestión de la
eliminar.
Disponibilidad.
■■ Servicios o grupos de servicios. La mayoría de
Gestión de Accesos es un proceso que se ejecuta a través los usuarios no usan sólo un servicio, y los usuarios
de todas las funciones de Gestión de Aplicaciones y que realizan un conjunto similar de actividades
Técnica, y normalmente no es una función independiente. usarán un conjunto similar de servicios. En lugar de
Sin embargo, probablemente habrá un único punto de proporcionar acceso a cada servicio para cada usuario
control de coordinación, normalmente en Gestión de independiente, es más eficiente poder conceder a
Operaciones de TI o en el Centro de Servicio al Usuario. cada usuario, o grupo de usuarios, acceso simultáneo
Gestión de Accesos puede iniciarse mediante una Petición a todo el conjunto de servicios a los que tienen
de Servicio a través del Centro de Servicio al Usuario. derecho de uso. (Esto se analiza con más detalle en el
párrafo 4.5.7.2).
76 | Procesos de Operación del Servicio

■■ Servicios de Directorio hace referencia a un tipo ■■ Autorización de un responsable adecuado (definido en

específico de herramienta que se utiliza para gestionar el proceso)
el acceso y los derechos. Éstos se analizan en la ■■ Presentación de una Petición de Servicio (con
sección 5.8. evidencia justificada) a través del Centro de Servicio al
Usuario
4.5.5  Actividades, métodos y técnicas del ■■ Presentación de una RFC (con evidencia justificada)
proceso a través de Gestión de Cambios, o ejecución de un
Cambio Estándar predefinido
4.5.5.1  Solicitud de acceso ■■ Una política que establece que el usuario puede tener
El acceso (o restricción) se puede solicitar usando alguno acceso a un servicio opcional si lo necesita.
de los siguientes mecanismos:
Para nuevos servicios, el Registro de Cambios debe
■■ Una solicitud estándar generada por el sistema especificar los usuarios o grupos de usuarios que
de Recursos Humanos. Esto generalmente se hace tendrán acceso al Servicio. Entonces Gestión de Accesos
siempre que se contrate, promocione, transfiera a una comprobará que todos los usuarios siguen siendo válidos
persona o cuando la misma deje la empresa. y proporcionará automáticamente acceso como se
■■ Una Solicitud de Cambio especificó en la RFC.
■■ Una Petición de Servicio enviada a través del sistema
de Gestión de Peticiones 4.5.5.3  Asignación de Permisos
■■ Ejecución de un script u opción autorizada Gestión de Accesos no decide quién tiene acceso a los
previamente (p. ej., descargar una aplicación desde un servicios de TI. Más bien, Gestión de Accesos ejecuta
servidor de pruebas cuando sea necesario). las políticas y regulaciones definidas durante Estrategia
del Servicio y Diseño del Servicio. Gestión de Accesos
Las reglas para solicitar acceso normalmente se
implementa las decisiones de restricción o provisión de
documentan como parte del Catálogo de Servicios.
accesos, en lugar de tomar la decisión.
4.5.5.2  Verificación En cuanto se haya verificado a un usuario, Gestión de
Gestión de accesos necesita verificar todas las solicitudes Accesos proporcionará a ese usuario los derechos de uso
de acceso a un servicio de TI desde dos perspectivas: del servicio solicitado. En la mayoría de los casos, esto
generará una solicitud para cada equipo o departamento
■■ Que el usuario que solicita acceso es quien dice que es
implicado en el soporte de ese servicio para llevar a cabo
■■ Que tienen un permiso legítimo para ese servicio. la acción necesaria. Si fuera posible, estas tareas deberán
El usuario logra normalmente la primera categoría automatizarse.
proporcionando su nombre de usuario y contraseña. Cuantos más roles y grupos existan, más probable será
Dependiendo de las políticas de seguridad de la que surja un Conflicto de Roles. Un Conflicto de Roles
organización, el uso de nombre de usuario y contraseña en este contexto hace referencia a una situación en la
normalmente se aceptan como prueba de que la persona que dos grupos o roles específicos, si se asignaron a un
es un usuario legítimo. Sin embargo, para disponer único usuario esta situación generará problemas con la
de servicios más sensibles, podría requerirse una separación de responsabilidades o habrá un conflicto de
identificación posterior (biométrica, uso de una clave de intereses. A continuación se muestran ejemplos de esto:
acceso electrónica, o un mecanismo de encriptación, etc.).
■■ Un rol requiere acceso detallado mientras que a otro
La segunda categoría requerirá alguna verificación rol se le impide ese acceso
independiente, diferente a la solicitud del usuario. Por ■■ Dos roles permiten a un usuario realizar dos tareas
ejemplo: que no deben combinarse (p. ej., un contratista puede
■■ Notificación de Recursos Humanos de que la persona rellenar su hoja de registro horario y a continuación
es un nuevo empleado y requiere un nombre de aprobar todo el pago del trabajo para el mismo
usuario y acceso para un conjunto estándar de proyecto).
servicios
■■ Notificación de Recursos Humanos de que se ha
promocionado a un usuario y requiere acceso a
recursos adicionales
 Procesos de Operación del Servicio | 77

El Conflicto de Roles se puede evitar con la creación ■■ Acción disciplinaria. En algunos casos, la
detallada de roles y grupos, aunque en muchas ocasiones organización requerirá una restricción temporal para
están provocados por políticas y decisiones tomadas fuera evitar que el usuario acceda a alguno o a todos los
de Operación del Servicio, por el negocio o por diferentes servicios a los que normalmente tendría acceso.
equipos de proyecto que trabajan durante Diseño del Deberían existir funcionalidades en el proceso y
Servicio. En cada caso, el conflicto debe documentarse y herramientas para hacer esto, en lugar de tener que
escalarse a los implicados para su resolución. eliminar y restablecer los derechos de acceso del
Al definir roles y grupos, existe la posibilidad de que sean usuario.
demasiado generales o demasiado específicos. Siempre ■■ Despidos. Cuando se despida a un empleado o
habrá usuarios que necesiten algo ligeramente diferente contratista, o cuando se emprenda una acción legal
de los roles predefinidos. En estos casos, es posible contra un cliente (por ejemplo, por incumplimiento
utilizar roles estándar y, a continuación, añadir o quitar de un pago por productos comprados en Internet), el
derechos específicos según sea el caso, similar al concepto acceso se anulará inmediatamente. Además, Gestión
de Líneas de Referencia y Variantes en Gestión de la de Accesos, junto con Gestión de la Seguridad de
Configuración (vea la publicación Transición del Servicio). la Información, tomará medidas activas para evitar
Sin embargo, la decisión para hacer esto no se encuentra y detectar acciones malintencionadas contra la
en las manos de los miembros individuales del personal organización por parte de ese usuario.
operativo. Cada excepción debe coordinarse con Gestión Gestión de Accesos debe entender y documentar el Ciclo
de Accesos y aprobarse a través del proceso de origen. de Vida de Usuario típico para cada tipo de usuario, y
Gestión de Accesos debe realizar una revisión regular usarlo para automatizar el proceso. Las herramientas de
de los roles y grupos que ha creado, y gestionarlos para Gestión de Accesos proporcionarán funcionalidades que
asegurarse que son los apropiados para los servicios que permitan a un usuario pasar de un estado a otro, o de un
TI entrega y da soporte. Los roles/grupos innecesarios u grupo a otro, fácilmente y con un registro de auditoría.
obsoletos deberán retirarse.
4.5.5.5  Registro y seguimiento del acceso
4.5.5.4  Monitorización del estado de la identidad Gestión de Accesos no debería responder únicamente
Como usuarios que trabajan en la organización, sus roles a las solicitudes. También es responsable de garantizar
cambian y, por lo tanto, también lo hacen sus necesidades que los derechos que han suministrado se estén usando
de acceso a servicios. A continuación se muestran adecuadamente.
ejemplos de esos cambios:
A este respecto, Monitorización y Control de Accesos debe
■■ Cambios de puesto. En este caso, el usuario incluirse en las actividades de monitorización de todas las
posiblemente necesitará acceder a servicios diferentes funciones de Gestión de Aplicaciones y Gestión Técnica y
o adicionales. de los procesos de Operación del Servicio.
■■ Promociones o pérdidas de categoría laboral. El
Gestión de Incidencias debe gestionar las excepciones,
usuario probablemente usará el mismo conjunto de
posiblemente usando Modelos de Incidencias diseñados
servicios, pero necesitará acceder a niveles diferentes
específicamente para tratar el abuso de derechos de
de funcionalidad o de datos.
acceso. Debe tenerse en cuenta que la visibilidad de
■■ Transferencias. En esta situación, el usuario podría tales acciones debe estar restringida. Si se pone esta
necesitar acceder a exactamente el mismo conjunto de información a disposición de todos aquellos que tienen
servicios, pero en una región diferente con diferentes acceso al sistema de Gestión de Incidencias, se expondrán
prácticas de trabajo o diferentes conjuntos de datos. las vulnerabilidades.
■■ Dimisión o fallecimiento. Es necesario bloquear
completamente el acceso para evitar que se utilice Gestión de la Seguridad de la Información juega un rol
el nombre de usuario como una vulnerabilidad en la vital a la hora de detectar el acceso sin autorización y
seguridad. compararlo con los derechos que Gestión de Accesos
haya asignado. Esto requerirá que Gestión de Accesos se
■■ Retirada. En muchas organizaciones, un empleado
implique a la hora de definir los parámetros de uso en las
que se retire todavía podría tener acceso a un
herramientas de Detección de Intrusiones.
conjunto limitado de servicios, incluyendo sistemas
de beneficios, o sistemas que le permitan comprar También se podría requerir que Gestión de Accesos
productos de la empresa a una tarifa reducida. proporcione un registro de acceso para servicios
específicos durante investigaciones o auditorías. Si se
78 | Procesos de Operación del Servicio

sospechara que un usuario está incumpliendo la política, 4.5.6 Disparadores, interfaces entre procesos
o estuviera haciendo un uso inapropiado de los recursos, de entradas y salidas
o un uso fraudulento de los datos, se podría requerir que
Gestión de Accesos se activa a través de la solicitud de
Gestión de Accesos diera evidencia de las fechas, horas e
un usuario o usuarios que quieren acceder a un servicio
incluso del contenido de ese acceso del usuario a Servicios
o grupo de servicios. Esto podría originarse a partir de lo
específicos. Esto normalmente se realizará a través del
siguiente:
personal operativo de ese servicio, pero trabajando como
parte del proceso de Gestión de Accesos. ■■ Una RFC. Esta es la forma más habitual usada para
incorporaciones o actualizaciones de servicio de gran
4.5.5.6  Eliminación o restricción de derechos escala donde es necesario actualizar un número
Al igual que Gestión de Accesos provee derechos para significativo de usuarios como parte del proyecto.
usar un Servicio, también es responsable de revocar esos ■■ Una Petición de Servicio. Ésta normalmente se
derechos. De nuevo, ésta no es una decisión que pueda inicia a través del Centro de Servicio al Usuario,
tomar por sí misma. Más bien, ejecutará las políticas o directamente dentro del sistema de Gestión de
y decisiones tomadas durante Estrategia y Diseño del Peticiones, y la ejecutan los equipos de Gestión de
Servicio, y también las decisiones tomadas por los Aplicaciones y de Gestión Técnica pertinentes.
gerentes de la organización. ■■ Una solicitud del personal apropiado de Gestión de
Recursos Humanos (que debe canalizarse a través
La retirada del acceso normalmente se hace en las
del Centro de Servicio al Usuario). Ésta normalmente
siguientes circunstancias:
se genera como parte del proceso para contratar,
■■ Fallecimiento promocionar, reubicar, y del proceso de cese o
■■ Dimisión jubilación.
■■ Despido ■■ Una solicitud del gerente de un departamento, que
■■ Cuando el usuario ha cambiado de rol y ya no podría estar desempeñando un rol de RR. HH., o que
requiere acceso al servicio podría haber tomado una decisión para empezar a
■■ Transferencia o viaje a un área donde se aplican usar un servicio la primera vez.
diferentes accesos regionales. Gestión de Accesos debería vincularse con los procesos
En otros casos, no es necesario retirar el acceso, sino sólo de Recursos Humanos para verificar la identidad de los
aplicar restricciones más estrictas. Éstas podrían incluir usuarios, además de asegurar que tienen derecho a los
la reducción del nivel, tiempo o duración del acceso. servicios que están solicitando.
Las situaciones en las que deberá restringirse el acceso Gestión de la Seguridad de la Información es un impulsor
incluyen: clave de Gestión de Accesos, debido a que proporcionará
■■ Cuando el usuario ha cambiado los roles y se le ha las políticas de seguridad y protección de datos, y las
degradado y ya no requiere los mismos niveles de herramientas necesarias para ejecutar Gestión de Accesos.
acceso Gestión de Cambios desempeña un rol importante para
■■ Cuando el usuario está bajo investigación, pero controlar las solicitudes reales de acceso. Esto se debe
todavía requiere acceso a servicios básicos, como por a que cualquier solicitud de acceso a un servicio es
ejemplo el correo electrónico. En este caso, su correo un cambio, aunque normalmente se procesa como un
electrónico podría estar sujeto a una exploración Cambio Estándar o Petición de Servicio (posiblemente
adicional (pero esto necesitaría manejarse con usando un modelo), una vez se hayan acordado los
mucho cuidado y de total acuerdo con la política criterios de acceso a través de SLM.
de seguridad de la organización) (N. de R.: también
SLM mantiene los acuerdos de acceso a cada servicio. Esto
considerar aspectos legales de cada país respecto al
incluirá los criterios en lo referente a quién tiene derecho
acceso a información personal del usuario).
a acceder a cada servicio, cuál será el coste de ese acceso,
■■ Cuando un usuario esté fuera de la organización en
si fuera apropiado, y qué nivel de acceso se concederá
una asignación temporal y no requiera acceso a ese para los diferentes tipos de usuario (p. ej., gerentes o
servicio durante algún tiempo. personal).
También existe una fuerte relación entre Gestión de
Accesos y Gestión de la Configuración. El CMS se puede
 Procesos de Operación del Servicio | 79

utilizar para el almacenamiento de datos, y se le puede que proporcionar acceso inicialmente. Los procedimientos
interrogar para determinar los detalles actuales del acceso. entre TI y RR.HH. deben establecerse bien definidos
para que incluyan comprobaciones a prueba de fallos
4.5.7  Gestión de la Información que garanticen que los derechos de acceso se retiren
inmediatamente cuando ya no se justifiquen o requieran.
4.5.7.1  Identidad
Cuando a un usuario se le concede acceso a una
La identidad de un usuario es la información del mismo aplicación, la organización ya debería haber establecido
que lo distingue como un individuo, y que verifica su (normalmente el Departamento de Seguridad o de
estado dentro de la organización. Por definición, la Recursos Humanos) que el usuario es quien dice ser.
identidad de un usuario es única para ese usuario. Debido
a que existen casos en los que dos usuarios comparten En este punto, toda esa información se archiva y el archivo
una información (p. ej., tienen el mismo nombre), la se asocia con una identidad corporativa, normalmente un
identidad normalmente se establece usando más de una número de empleado o contratista y con una identidad
información, por ejemplo: que se pueda usar para acceder a recursos corporativos
e información, normalmente una identidad de usuario o
■■ Nombre
‘nombre de usuario’ y una contraseña asociada.
■■ Dirección
■■ Detalles de contacto, p. ej., teléfono, dirección de 4.5.7.2  Usuarios, grupos, roles y grupos de
correo electrónico, etc. servicios
■■ Documentación física, p. ej., permiso de conducir,
Aunque cada usuario tiene una identidad individual, y
pasaporte, certificado de matrimonio, etc.
cada servicio de TI se puede ver como una entidad por
■■ Números que hacen referencia a un documento o derecho propio, en muchas ocasiones es útil agruparlos
entrada en una base de datos, p. ej., número de juntos para que se puedan gestionar con más facilidad.
empleado, número de identificación fiscal, número de Algunas veces los términos ‘perfil de usuario’ o ‘plantilla
permiso de conducir, etc. de usuario’ o ‘rol de usuario’ se utilizan para describir este
■■ Información biométrica, p. ej., huellas digitales, tipo de agrupamiento.
imágenes de retina, patrones de reconocimiento de
La mayoría de organizaciones tienen un conjunto
voz, ADN, etc.
estándar de servicios para todos los usuarios individuales,
■■ Fecha de vencimiento (si fuera relevante).
independientemente de su posición o trabajo (excluyendo
La identidad de un usuario se proporciona a cualquiera a clientes, que no tienen ninguna visibilidad de servicios
con un requisito legítimo para acceder a servicios de TI o y procesos internos). Éstos incluirán servicios como
a información organizativa. Éstos podrían incluir: mensajería, automatización de la oficina, Soporte al Puesto
de Trabajo, telefonía, etc. A los nuevos usuarios se les
■■ Empleados
proporcionan automáticamente derechos de uso de estos
■■ Contratistas
servicios.
■■ Personal de proveedores (p. ej., gestor de cuentas,
personal de soporte, etc.) Sin embargo, la mayoría de los usuarios también tienen
algún rol especializado que llevan a cabo. Por ejemplo,
■■ Clientes (especialmente al comprar productos o
además de los servicios estándar, el usuario también lleva
servicios en Internet).
a cabo un rol de Gestión de Marketing que requiere tener
La mayoría de las organizaciones verificarán la identidad acceso a algunos datos y herramientas especializadas de
de un usuario antes de que se unan a la organización modelización financiera y de marketing.
solicitando alguna información mencionada anteriormente.
Algunos grupos podrían tener requisitos únicos, como
Cuanto más segura sea la organización, más tipos de
por ejemplo trabajadores a domicilio o en campo que
información se requieren y con más detenimiento se
podrían tener que marcar un número de teléfono o usar
comprueban.
conexiones de Red Privada Virtual (VPN), con implicaciones
Muchas organizaciones se enfrentarán a la necesidad de de seguridad que podrían tener que gestionarse más
proporcionar derechos de acceso a personal temporal estrictamente.
u ocasional o a contratistas/suministradores. En muchas Para facilitar que Gestión de Accesos proporcione los
ocasiones la gestión de accesos para ese personal se derechos apropiados, usa un catálogo de todos los roles
muestra problemática. Muchas veces el cierre del acceso en la organización y cuáles servicios soportan cada rol.
después del uso es tan difícil de gestionar, o incluso más, Gestión de Accesos debe compilar y mantener este
80 | Procesos de Operación del Servicio

catálogo de roles junto con RR.HH. y en muchas ocasiones ■■ La capacidad de gestionar cambios para los requisitos
se automatizará en las herramientas de Servicio de de acceso de un usuario
Directorio (vea la sección 5.8). ■■ La capacidad de restringir los derechos de acceso a
Además de jugar diferentes roles, los usuarios también usuarios sin autorización
podrían pertenecer a diferentes grupos. Por ejemplo, se ■■ Una base de datos de todos los usuarios y los
requiere que todos los contratistas registren sus hojas de derechos que se les puede haber concedido.
registro horario en un Sistema de Tarjetas de Tiempo que
no utilizan los empleados. Gestión de Accesos evaluará 4.6  Actividades operativas de
todos los roles que desempeña un usuario además
procesos cubiertas por otras fases
de los grupos a los que pertenece, y se asegurará de
proporcionar los derechos de uso de todos los servicios del ciclo de vida
asociados.
4.6.1  Gestión de Cambios
Nota: Todos los datos sobre usuarios estarán sujetos
Gestión de Cambios se aborda principalmente en la
a la legislación de protección de datos (esto existe en
publicación Transición del Servicio, pero existen algunos
la mayoría de las ubicaciones geográficas de alguna u
aspectos de Gestión de Cambios en los que el personal de
otra forma) por lo que deberían manejarse y protegerse
Operación del Servicio estará implicado diariamente. Éstos
como parte de los procedimientos de seguridad de la
incluyen:
organización.
■■ Plantear y enviar tantas RFC como sean necesarias
4.5.8  Métricas para abordar problemas de Operación del Servicio
La métricas que se pueden usar para medir la eficiencia y ■■ Participar en reuniones de CAB o CAB/EC para
eficacia de Gestión de Accesos incluyen: garantizar que los riesgos, inconvenientes y puntos de
■■ Número de solicitudes de acceso (Petición de Servicio, vista de Operación del Servicio se tengan en cuenta.
RFC, etc.) ■■ Implementar cambios dirigidos por Gestión de
■■ Instancias de acceso concedidas, por servicio, usuario, Cambios si implican a servicios o componentes de
departamento, etc. Operación del Servicio
■■ Instancias de acceso concedidas por derechos ■■ Desistir de cambios dirigidos por Gestión de Cambios
concedidos a individuos o departamentos si implican a servicios o componentes de Operación
del Servicio
■■ Número de incidencias que requieren un
restablecimiento de los derechos de acceso ■■ Ayudar a definir y mantener modelos de cambios
asociados con componentes y servicios de Operación
■■ Número de incidencias causadas por ajustes de
del Servicio
accesos incorrectos.
■■ Recibir planificaciones de cambios y garantizar que
4.5.9 Desafíos, Factores Críticos de Éxito y todo el personal de Operación del Servicio sea
consciente y esté preparado para todos los cambios
riesgos
pertinentes
Las condiciones para una Gestión de Accesos exitosa
■■ Usar el proceso de Gestión de Cambios para cambios
incluyen:
estándar y de tipo operativo.
■■ La capacidad de verificar la identidad de un usuario
(que la persona es quien dice ser) 4.6.2  Gestión de la Configuración
■■ La capacidad de verificar la identidad de la persona o Gestión de la Configuración se aborda principalmente
cuerpo aprobatorio en la publicación Transición del Servicio, pero existen
■■ La capacidad de verificar que un usuario está algunos aspectos de Gestión de la Configuración en los
cualificado para acceder a un servicio específico que el personal de Operación del Servicio estará implicado
■■ La capacidad para vincular múltiples derechos de diariamente. Entre éstos se incluye:
acceso a un usuario individual
■■ Informar a Gestión de la Configuración de cualquier
■■ La capacidad de determinar el estado del usuario en
discrepancia encontrada entre cualquier CI y el CMS
cualquier momento (p. ej., determinar si son todavía
■■ Realizar las modificaciones necesarias para corregir
empleados de la organización cuando se registran en
cualquier discrepancia, bajo la autoridad de Gestión
un sistema)
de la Configuración, si estuvieran implicados
componentes o servicios de Operación del Servicio.
 Procesos de Operación del Servicio | 81

La responsabilidad de actualizar el CMS recae en Gestión la infraestructura de TI, y la predicción del impacto de
de la Configuración, pero en algunos casos se le podría cualquier cambio o tendencia.
solicitar al personal de Operaciones, bajo la dirección de
Muchas de estas actividades son objeto de planificación
Gestión de la Configuración, actualizar las relaciones, o
estratégica o de largo plazo y se abordan en las
incluso añadir nuevos CI o marcar CI como ‘dispuestos’
publicaciones Estrategia del Servicio, Diseño del Servicio
en el CMS, si estas actualizaciones estuvieran relacionadas
y Transición del Servicio. Sin embargo, existen varias
con actividades operativas llevadas a cabo realmente por
actividades de Gestión Operativa de la Capacidad que
el personal de Operaciones.
deben realizarse sobre una base permanente, de forma
regular, como parte de Operación del Servicio. Éstas
4.6.3  Gestión de Versiones y Despliegues
incluyen lo siguiente.
Gestión de Versiones y Despliegues se aborda
principalmente en la publicación Transición del Servicio, 4.6.4.1  Monitorización del Rendimiento y de la
pero existen algunos aspectos de este proceso en los que
Capacidad
el personal de Operación del Servicio estará implicado
diariamente. Éstos podrían incluir: Todos los componentes de la Infraestructura de TI deben
monitorizarse continuamente (junto con Gestión de
■■ Acciones reales de implementación asociadas con el
Eventos) para que se pueda identificar cualquier tendencia
despliegue de nuevas versiones bajo la dirección de o problema potencial antes de que se produzcan
Gestión de Versiones y Despliegues, si se asocian con fallos o degradación del rendimiento. Idealmente, tal
servicios y componentes de Operación del Servicio monitorización debe automatizarse y deberán establecerse
■■ Participación en las etapas de planificación de nuevas umbrales de tal manera que surjan alertas de excepción
versiones importantes para aconsejar sobre asuntos de en el momento oportuno para permitir la acción de
Operación del Servicio recuperación o la acción preventiva antes de que se
■■ El manejo físico de CIs desde o para el DML y cumplir produzcan impactos adversos.
así sus roles operativos, mientras que se cumplen los
Los componentes y elementos a monitorizar variarán
procedimientos de Gestión de Versiones y Despliegues,
dependiendo de la infraestructura en uso, pero
como por ejemplo asegurar que todos los elementos
típicamente incluirán:
se retiren y vuelva a introducir adecuadamente.
■■ Utilización de la CPU (en conjunto y desglosado por
4.6.4  Gestión de la Capacidad uso del sistema/servicio)
Gestión de la Capacidad debe operar a tres niveles: ■■ Utilización de la memoria
Gestión de la Capacidad del Negocio, Gestión de la ■■ Índices IO (físicos y buffer) y utilización del dispositivo
Capacidad del Servicio y Gestión de la Capacidad de los ■■ Longitud de la cola (máxima y promedio)
Recursos. ■■ Uso de almacenamiento de archivos (discos,
■■ Gestión de la Capacidad del Negocio implica particiones, segmentos)
trabajar con el negocio para planificar y anticipar ■■ Aplicaciones (índices de rendimiento, índices de fallo)
cuestiones estratégicas a largo plazo e iniciativas ■■ Bases de datos (utilización, bloqueos de registros,
tácticas a corto plazo que probablemente tendrán un indexación, contención)
impacto en la capacidad de TI. ■■ Índices de transacción de red, índices de errores y de
■■ Gestión de la Capacidad del Servicio trata sobre reintentos
el entendimiento de las características de cada uno ■■ Tiempo de respuesta de transacción
de los servicios de TI, y de las demandas que los
■■ Perfiles de duración de lotes
diferentes tipos de usuarios o transacciones tienen
■■ Índices de efectividad de la página/sitio de Internet/
sobre la estructura subyacente, de qué forma
Intranet
éstas varían con el tiempo y cómo pudieran verse
impactadas por los cambios del negocio. ■■ Tiempos de respuesta de Internet (externo o interno a
firewalls)
■■ Gestión de la Capacidad de Recursos vise à la
compréhension des caractéristiques de pimplica el ■■ Número de registros de sistema/aplicación y usuarios
entendimiento de las características y capacidades de concurrentes
rendimiento, y de los niveles actuales de utilización de ■■ Número de nodos de red en uso, y niveles de
todos los componentes técnicos (CIs) que componen utilización.
82 | Procesos de Operación del Servicio

Existen diferentes tipos de herramientas de monitorización suficiente personal en el Centro de Servicio al Usuario
necesarias para recopilar e interpretar datos en cada para manejar el índice de incidencias; ya sea que la
nivel. Por ejemplo, algunas herramientas permitirán la estructura del CAB pueda manejar el número de cambios
monitorización del rendimiento de las transacciones que se están solicitando revisar y aprobar; ya sea que las
del negocio, mientras que otras monitorizarán el herramientas de soporte puedan manejar el volumen de
comportamiento de los CI. datos que se está recopilando, son asuntos que el equipo
de Gestión de la Capacidad podría ayudar a investigar y
Gestión de la Capacidad debe establecer y calibrar
responder.
umbrales de alarma (donde fuera necesario en
colaboración con Gestión de Eventos, ya que en
muchas ocasiones se podrían utilizar herramientas de
4.6.4.2  Incidencias asociadas con el rendimiento
Monitorización de Eventos) para que se establezcan o con el manejo de capacidad
los niveles de alerta correctos y para que se defina Si se activara un alerta, o se planteara una incidencia en el
cualquier filtro necesario para que sólo se planteen Centro de Servicio al Usuario, provocadas por un problema
eventos significativos. Sin tal filtro, es posible que los actual o continuo de Gestión del Rendimiento o de la
alertas ‘sólo de información’ puedan enmascarar alertas Capacidad, Gestión de la Capacidad debe implicarse para
más importantes que requieran una atención inmediata. identificar la causa y encontrar una solución. Colaborando
Además, es posible que fallos graves provoquen con los grupos de soporte técnico apropiados, y junto
‘avalanchas de alertas’ debido a los altos volúmenes de con Gestión de Problemas, deberán realizarse todas las
alertas repetidas, que nuevamente deberán filtrarse para investigaciones necesarias para detectar exactamente lo
que no queden ocultos los mensajes más significativos. que se ha hecho mal y qué es necesario para corregir la
situación.
Podría ser apropiado usar capacidades de monitorización
externas -de terceros- para algunos CI u otros Podría ser necesario cambiar a una monitorización más
componentes de la Infraestructura de TI (p. ej., páginas/ detallada durante la fase de investigación para determinar
sitios clave de Internet). Gestión de la Capacidad la causa exacta. Normalmente la monitorización se
debe verse implicada a la hora de ayudar a especificar establece a un nivel de ‘segundo plano’ durante
y seleccionar cualquiera de tales capacidades de circunstancias normales debido a la gran cantidad
monitorización, y a la hora de integrar los resultados de datos que se pueden generar, y para evitar cargar
o cualquier alerta con otros sistemas de manejo y demasiado la Infraestructura de TI. Pero cuando las
monitorización. dificultades específicas se están investigando con una
monitorización más detallada sería necesario precisar la
Gestión de la Capacidad debe trabajar con todos los
causa exacta.
grupos de soporte apropiados para tomar decisiones
sobre hacia dónde se envían las alarmas y sobre las rutas Cuando se haya encontrado una solución, o solución
de escalado y escalas de tiempo. Las alertas deberán potencial, se deberá aprobar cualquier cambio necesario
registrarse para el Centro de Servicio al Usuario así como para resolver el problema a través de Gestión de Cambios
para el personal de soporte apropiado, de tal forma que se formal antes de la implementación. Si el fallo estuviera
puedan plantear Registros de Incidencias para que exista provocando interrupciones serias y se necesitara una
un registro permanente de eventos, y para que el personal resolución urgente, se deberá utilizar un proceso de
del Centro de Servicio al Usuario tenga una visión sobre cambio urgente. Es muy importante que no tenga lugar
cómo de bien están abordando el fallo los grupos de ningún ‘ajuste’ sin su propuesta a través de Gestión
soporte, y para que puedan intervenir si fuera necesario. de Cambios, incluso ajustes aparentemente pequeños
normalmente pueden tener efectos acumulativos muy
Las capacidades de rendimiento demandadas de los
grandes, algunas veces a través de toda la infraestructura
fabricantes y los objetivos de nivel de servicio acordados,
de TI.
junto con los datos históricos reales monitorizados de
capacidad y rendimiento, deberán usarse para establecer
4.6.4.3  Tendencias de rendimiento y capacidad
niveles de alerta. Inicialmente podría ser necesario un
proceso iterativo, realizando algunos ajustes de prueba y Gestión de la Capacidad tiene un rol que desempeñar en
error hasta que se logren los niveles correctos. la identificación de cualquier tendencia de rendimiento o
capacidad que pase a ser perceptible. En la publicación
Nota: Gestión de la Capacidad podría tener que implicarse Mejora Continua del Servicio se incluyen más detalles
en los requisitos de capacidad y capacidades de Gestión sobre las acciones necesarias para abordar tales
del Servicio de TI. Ya sea que la organización tenga tendencias.
 Procesos de Operación del Servicio | 83

4.6.4.4  Almacenamiento de los datos de Gestión para permitir mejoras del rendimiento para un grupo
de la Capacidad restringido más pequeño, entonces las funciones de
Operación del Servicio tendrán que tomar acciones
Normalmente se generan grandes cantidades de datos
para implementar tales restricciones, normalmente
a través de la monitorización del rendimiento y de la
acompañadas por acciones concurrentes para implementar
capacidad. La monitorización de medidores y tablas de
la salida de sesión de usuarios que han estado inactivos
sólo algunos Kbytes cada uno, puede crecer rápidamente
durante un periodo de tiempo acordado. Con ello se
hasta archivos enormes si se estuvieran monitorizando
liberarían recursos para otros.
muchos componentes a intervalos relativamente cortos.
Otro problema de la monitorización a intervalos muy
cortos es que no es posible recopilar información
4.6.4.6  Gestión de la Carga de Trabajo
significativa sin hacer la lectura durante un largo periodo Podrían existir ocasiones en las que fuera necesario
de tiempo. Por ejemplo, una simple instantánea de mantener la optimización de los recursos de la
una CPU mostrará que el dispositivo está ‘ocupado’ o infraestructura o mejorar el rendimiento o volumen de
‘desocupado’, pero una recopilación durante, digamos, trabajo. En muchas ocasiones esto puede hacerse a través
un periodo de 5 minutos, mostrará el nivel de utilización de Gestión de la Carga de Trabajo, que es un término
promedio durante ese periodo, que es una medida mucho genérico para indicar acciones como:
más significativa de la capacidad del dispositivo para ■■ Replanificar un servicio o carga de trabajo en particular
trabajar cómodamente, o si es probable que se produzcan para que se ejecute en un momento diferente del día,
problemas potenciales de rendimiento. o día de la semana, etc. (normalmente lejos de los
En cualquier organización es probable que las periodos de mayor demanda en ventanas de tiempo
herramientas de monitorización usadas varíen sin demanda), que con frecuencia significará tener que
ampliamente, con una combinación de herramientas hacer ajustes en el software de planificación de tareas.
específicas del sistema, muchas de ellas como parte del ■■ Mover un servicio o carga de trabajo de una ubicación
sistema operativo básico, y herramientas especializadas de o conjunto de CIs a otra, normalmente para equilibrar
monitorización que se estén usando. Para coordinar los el uso o el tráfico.
datos que se están generando y para permitir la retención ■■ Virtualización Técnica: establecer y usar sistemas
de datos significativos para realizar análisis e identificar de virtualización para permitir el movimiento del
tendencias, será necesaria alguna forma de depósito para procesamiento alrededor de la infraestructura
mantener estos datos de recopilación: un Sistema de para ofrecer un mejor rendimiento/capacidad de
Información de Gestión de la Capacidad (CMIS). recuperación de forma dinámica.
El formato, ubicación y diseño de tal base de datos ■■ Limitar o mover la demanda de recursos a través de
deberá planificarse e implementarse por anticipado. Vea técnicas de Gestión de la Demanda (vea lo expuesto
la publicación Diseño del Servicio para disponer de más anteriormente y también la publicación de Diseño del
detalles; pero habrá algunos aspectos operativos que Servicio).
manejar, como por ejemplo backups y mantenimiento de Sólo será posible gestionar cargas de trabajo de forma
la base de datos. eficaz si existe un buen entendimiento de las cargas
de trabajo que se ejecutarán y en qué momento, y
4.6.4.5  Gestión de la Demanda cuántos recursos se ponen a disposición para cada
Gestión de la Demanda es el nombre dado a un número carga de trabajo en la Infraestructura de TI. Por lo tanto,
de técnicas que se pueden utilizar para modificar la la monitorización y análisis detallados de las cargas
demanda de un recurso o servicio particular. Algunas de trabajo serán necesarios sobre una base operativa
técnicas de Gestión de la Demanda pueden planificarse permanente.
anticipadamente, y éstas se recogen con más detalle en la
publicación Estrategia del Servicio. Sin embargo, existen 4.6.4.7  Modelado y dimensionamiento de las
otros aspectos de Gestión de la Demanda que son de una aplicaciones
naturaleza más operativa y que requieren acciones a más La modelización y/o dimensionamiento de nuevos
corto plazo. servicios y/o aplicaciones debe realizarse, cuando sea
Si, por ejemplo, el rendimiento de un servicio particular aplicable, durante las fases de planificación y transición.
fuera causa de preocupación, y se requirieran restricciones Vea las publicaciones de Diseño del Servicio y Transición
a corto plazo sobre la concurrencia de los usuarios del Servicio. Sin embargo, las funciones de Operación del
84 | Procesos de Operación del Servicio

Servicio tienen un rol a desempeñar a la hora de evaluar la ■■ Informes sobre cualquier dificultad específica
precisión de las predicciones y de retroalimentar cualquier encontrada en el último periodo con respecto a la
problema o discrepancia. capacidad, con detalles de acciones preventivas y de
recuperación tomadas para el futuro
4.6.4.8  Planificación de la Capacidad ■■ Detalles de cualquier actualización requerida o
Durante el Diseño del Servicio y Transición del Servicio se compras necesarias y planificadas para el futuro, con
calculan los requisitos de capacidad de los servicios de TI. escalas de tiempo y costes indicativos.
Deberá mantenerse y actualizarse regularmente un plan ■■ Cualquier riesgo potencial de capacidad que sea
de previsión de la capacidad, y Operación del Servicio probable, con las contramedidas sugeridas que se
tendrá un rol a desempeñar en esto. Un plan como éste pudieran plantear.
deberá hacer una previsión de hasta dos años o más, pero
deberá revisarse regularmente cada tres a 12 meses, en 4.6.5  Gestión de la Disponibilidad
función de la volatilidad y los recursos disponibles. Durante el Diseño del Servicio y Transición del Servicio,
los servicios de TI se diseñaron para la disponibilidad
El plan deberá vincularse con el ciclo de planificación
y recuperación. Operación del Servicio es responsable
financiera de la organización, para que cualquier gasto
de conseguir que los servicios de TI estén realmente
requerido para las actualizaciones, mejoras o añadidos de
disponibles para los usuarios especificados en el momento
la infraestructura puedan incluirse en las estimaciones del
requerido y a los niveles acordados.
presupuesto y aprobarse por anticipado.
Durante Operación del Servicio, los usuarios y equipos de
El plan deberá predecir el futuro pero también deberá
TI están en la mejor posición para detectar si los servicios
examinar e informar sobre las predicciones previas,
cumplen realmente los requisitos acordados y si el diseño
particularmente para proporcionar cierta confianza en
de estos servicios es eficaz.
las predicciones posteriores. Si se hubieran encontrado
algunas discrepancias, éstas deberán explicarse, Lo que parece una buena idea durante la fase de Diseño
describiendo futuras acciones para su solución. podría no ser realmente práctico u óptimo. La experiencia
de los usuarios y las funciones operativas hacen que
El Plan de Capacidad podría incluir típicamente:
sean una entrada principal en la mejora continua de los
■■ Detalles del rendimiento y utilización actuales con servicios existentes y del diseño.
nuevas tendencias para todos los CI clave, incluyendo
Sin embargo, existen varios desafíos para acceder a este
●● Redes troncales
conocimiento:
●● LANs
■■ La mayoría de las experiencias de los usuarios y
●● Mainframes (si todavía se utilizaran)
equipos operativos son informales, o se dispersan a
●● Servidores clave
través de múltiples fuentes.
●● Dispositivos de almacenamiento de datos
■■ Es necesario formalizar el proceso de recopilación y
principales
comparación de estos datos.
●● Equipos de escritorio y portátiles seleccionados
■■ Normalmente, los usuarios y el personal operativo
(representativos)
están totalmente ocupados con sus actividades y
●● Sitos web clave
tareas habituales, y es muy difícil para ellos implicarse
●● Bases de datos clave en una planificación regular y en las actividades de
●● Aplicaciones clave diseño. Un argumento que con frecuencia se utiliza
●● Capacidad operativa, electricidad, superficie útil, aquí es que si se mejora el diseño, los equipos
capacidad medioambiental (acondicionamiento del operativos estarán menos ocupados resolviendo
aire), peso de la superficie, salida y generación de problemas y, por lo tanto, tendrán más tiempo para
calor, demanda y suministro de electricidad y agua, implicarse en las actividades de diseño. Sin embargo,
etc. la práctica demuestra que en cuanto el personal se
●● Soporte magnético. libera, con frecuencia se convierten en el objetivo de
■■ Rendimiento y utilización estimados para todos esos los ejercicios de reducción de la fuerza de trabajo.
CI durante el periodo de planificación (p. ej., los Habiendo dicho esto, existen tres oportunidades clave
siguientes tres meses) para implicar al personal de operaciones en la Mejora de
■■ Datos corporativos con estimaciones previas para la Disponibilidad, ya que éstas generalmente se ven como
mantener la confianza en estimaciones futuras parte de su responsabilidad continua:
 Procesos de Operación del Servicio | 85

■■ Revisión de las actividades de mantenimiento. y perfilarse en Mejora Continua del Servicio (vea otras
Diseño del Servicio definirá planificaciones y publicaciones de ITIL en esta serie).
actividades detalladas de mantenimiento que se
Los repositorios clave de Operación del Servicio, que se
requieren para mantener en funcionamiento los
han mencionado con frecuencia en algún otro capítulo,
servicios de TI al nivel requerido de rendimiento y
son el CMS y la KEDB, pero deben ampliarse para incluir
disponibilidad. La comparación regular de los tiempos
toda la documentación de los departamentos y equipos
y actividades de mantenimiento reales con los planes
de Operación del Servicio, como por ejemplo manuales,
destacará las áreas potenciales de mejora. Una de las
manuales de procedimientos, instrucciones de trabajo, etc.
fuentes de esta información es una revisión del grado
de cumplimiento de los Objetivos de Mantenimiento
4.6.7  Gestión Financiera de los servicios de TI
del Servicio, y si no fuera así, la razón de ello.
El personal de Operación del Servicio debe participar y dar
■■ Revisiones de problemas graves. Los problemas
soporte al sistema de contabilidad y de preparación de los
podrían ser el resultado de cualquier número de
presupuestos generales de TI, y podría estar implicado de
factores, uno de los cuales puede ser un diseño
forma activa en cualquier sistema de cobros que pudiera
deficiente. Por lo tanto, las revisiones de problemas
establecerse.
podrían incluir oportunidades para identificar mejoras
en el diseño de los servicios de TI, que incluirán Es necesario realizar una planificación adecuada para que
mejoras en la disponibilidad y en la capacidad. las estimaciones de los presupuestos de coste de capital
■■ Implicación en iniciativas específicas aplicando (Capex) y de gastos operativos (Opex) puedan prepararse y
técnicas como el Análisis de Fallos del Servicio (SFA), acordarse a tiempo para cumplir los ciclos presupuestarios.
Análisis de Impacto de Fallos de Componentes (CFIA), El Gestor de Operación del Servicio también debe estar
o Análisis del Árbol de Fallos (FTA) o como miembros implicado en revisiones regulares, al menos mensuales, de
de actividades de Observación Técnica (TO), como las revisiones de gastos en relación con los presupuestos,
parte del seguimiento de problemas graves o como como parte del proceso continuo de contabilidad y
parte de un programa de mejora continua del servicio, preparación de presupuestos de TI. Deberá identificarse
en colaboración con el personal dedicado de Gestión cualquier discrepancia y realizarse los ajustes necesarios.
de la Disponibilidad. Estas técnicas de Gestión de Todos los gastos comprometidos deben pasar por el
la Disponibilidad se explican con más detalle en la sistema de órdenes de compra de la organización
publicación Diseño del Servicio. para que se puedan acumular, y deberán hacerse las
Podría haber ocasiones en las que el propio personal comprobaciones adecuadas con respecto a todos los
operativo necesite que se caigan uno o más servicios bienes recibidos para que las facturas y pagos se puedan
para permitirles dirigir sus actividades operativas o de autorizar correctamente, o se puedan investigar y rectificar
mantenimiento, lo que afectaría a la disponibilidad si no las discrepancias.
se planificaran y gestionaran adecuadamente. En tales Debe tenerse en cuenta que algunas reducciones de
casos, deberán coordinarse con el personal de SLM y costes propuestas por el negocio podrían incrementar
de Gestión de la Disponibilidad, que negociarán con el realmente los costes de TI, o al menos los costes unitarios.
negocio/usuarios, en numerosas ocasiones utilizando el Deben tomarse todas las precauciones necesarias para
Centro de Servicio al Usuario para realizar este rol, para asegurar que TI se implique en el análisis de todas las
acordar y planificar tales actividades. medidas de ahorro de costes y contribuya a las decisiones
globales. Gestión Financiera se recoge con detalle en la
4.6.6  Gestión del Conocimiento publicación Estrategia del Servicio.
Es de gran importancia que se recopilen, almacenen y
evalúen todos los datos y la información que puedan 4.6.8  Gestión de la Continuidad del Servicio
resultar de utilidad para las futuras actividades de de TI
Operación del Servicio. Los datos, métricas e información
Las funciones de Operación del Servicio son responsables
relevantes deberán pasar a lo largo de la cadena de
de la prueba y ejecución de los planes de recuperación
suministro y llegar hasta otras fases del Ciclo de Vida
del servicio y de los sistemas, como se determina en
del Servicio para que puedan desembocar en las capas
los planes de Continuidad de los Servicios de TI para la
de conocimiento y de saber del Sistema de Gestión del
organización. Además, los gerentes de todas las funciones
Conocimiento del Servicio, cuyas estructuras tienen que
de Operación del Servicio deben estar en el equipo de
definirse en Estrategia del Servicio y Diseño del Servicio,
Coordinación Central de la Continuidad del Negocio.
86 | Procesos de Operación del Servicio

Esto se analiza con detalle en Estrategia del Servicio y

Diseño del Servicio y no se repetirá aquí, excepto para
indicar que es importante que las funciones de Operación
del Servicio se impliquen en las siguientes áreas:
■■ Evaluación del riesgo, empleando su conocimiento de
la infraestructura y técnicas como CFIA, y el acceso a
la información del CMS para identificar puntos únicos
de fallo u otras situaciones de alto riesgo
■■ Ejecución de cualquier medida de Gestión del
Riesgo que esté acordada, p. ej., implementación
de contramedidas, o aumento de la capacidad de
recuperación de componentes de las infraestructuras,
etc.
■■ Asistencia a la hora de escribir los planes de
recuperación reales para sistemas y servicios bajo su
control
■■ Participación en la prueba de los planes (como la
implicación en las pruebas off-site, simulaciones, etc.)
sobre una base continua bajo la dirección del Gestor
de la Continuidad de los Servicios de TI (ITSCM)
■■ Mantenimiento continuo de los planes bajo el control
de ITSCM y de Gestión de Cambios
■■ Participación en las campañas de formación y
concienciación para garantizar que son capaces de
ejecutar los planes y entender sus roles ante un
desastre.
■■ El Centro de Servicio al Usuario desempeñará un rol
clave en la comunicación con el personal, clientes y
usuarios durante un desastre real.
Actividades Comunes de
Operación del Servicio 5
 | 89

5 Actividades Comunes de Operación del

Servicio
El Capítulo 4 abordó los procesos requeridos para una
En realidad, es imposible lograr servicios de calidad
Operación del Servicio eficaz, y el Capítulo 6 abordará
sin alinear y ‘engranar’ cada nivel de tecnología (y las
los aspectos organizativos. Este capítulo se centra en un
personas que los gestionan) con los servicios que se
número de actividades operativas que garantizan que la
están proporcionando. Gestión del servicio implica
tecnología se alinee con los objetivos generales de los
personas, procesos y tecnología.
Servicios y Procesos. Estas actividades se describen en
ocasiones como procesos, pero en realidad son conjuntos En otras palabras, las actividades habituales de
de actividades técnicas especializadas que tienen por Operación del servicio no tratan sobre la gestión de la
objetivo asegurar que la tecnología requerida para proveer tecnología para garantizar el buen rendimiento de la
y soportar servicios funcione de forma eficiente y eficaz. tecnología. Tratan sobre el logro del rendimiento que
integrará el componente tecnológico con las personas
Estas actividades normalmente tendrán una naturaleza y componentes de proceso para lograr objetivos de
técnica, aunque la tecnología exacta variará en función del servicio y negocio. Consulte en la Figura 5.1 ejemplos
tipo de servicios que se esté proveyendo. Esta publicación sobre cómo se gestiona la tecnología en el proceso de
se centrará en las actividades requeridas para gestionar TI. madurez de las organizaciones.

Nota importante sobre la gestión de tecnología

La Figura 5.1 ilustra los pasos implicados en la madurez
Es tentador separar el concepto de Gestión del Servicio desde una organización centrada en la tecnología hasta
de la gestión de la infraestructura que se utilizó para una organización que utilice la tecnología como parte
proveer esos servicios. de su estrategia de negocio. La Figura 5.1 describe con

• TI se mide en términos de su contribución al negocio

Nivel 5 • Los servicios se miden por su capacidad para agregar valor
• Tecnología se subordina a la función de negocio que habilita
Contribución • Portfolio de Servicios dirige inversión y objet. de rendimiento
• La experiencia tecnológica está tan arraigada en las
Estratégica operaciones que el negocio la percibe como una utilidad

• Servicios se cuantifican e iniciativas se dirigen a la entrega de niveles pertinentes

Centrado Nivel 4 • Los requisitos del servicio y la tecnología impulsan el aprovisionamiento
• Diseño del Servicio especifica requisitos de rendimiento y las normas operativas
en el Negocio Provisión • Los sistemas consolidados dan soporte a múltiples servicios
• Toda la tecnología se asigna a servicios y se gestiona para requisitos de servicio
del Servicio • Gestión de Cambios abarca tanto el desarrollo como las operaciones

• Los servicios críticos han sido identificados junto con sus dependencias tecnológicas
Nivel 3 • Sistemas se integran para proporc. rendimiento, disponib. y recuperación requeridos para servicios
• More focus on measuring performance across multiple devices and even platforms
Centrado Integración • Correlación virtual de datos de Config. y Activos con Gestión de Cambios indiv. para operaciones
• Disponibilidad Consolidada y Planificación de la Capacidad sobre algunos servicios
de Tecnología
en la Tecnología • Planificación de Recuperación de Desastres Integrado
• Los sistemas se consolidan para ahorrar costes

• Las iniciativas se dirigen a alcanzar control e incrementar la estabilidad de la infraestructura

Nivel 2 • TI ha identificado la mayoría de los componentes de tecnología y entiende para qué se usa cada uno
• Gestión técnica se centra en alcanzar un alto rendimiento en cada componente independientemente de su función
Control de • Se mide, e informa de, la disponibilidad de los componentes
• Se realiza la Gestión de Problemas Reactiva y el control de inventarios
Tecnología • Se realiza el control de cambios en los componentes de ‘misión crítica’
• Las soluciones puntuales sirven para automatizar esos procesos en su lugar, sobre una base plataforma a plataforma

• TI se impulsa por la tecnológica y la mayoría de las iniciativas están dirigidas a intentar entender la infraestructura y tratar las excepciones
Nivel 1 • Gestión de tecnología se realiza por técnicos expertos y sólo ellos entienden cómo gestionar cada dispositivo o plataforma
• La mayoría de los equipos se dirigen por incidencias y la mayoría de las mejoras están dirigidas a facilitar la gestión, no a mejorar servicios
Impulsado • Las organizaciones afianzan las especializaciones de la tecnología y no fomentan la interacción con otros grupos
• Las herramientas de gestión se dirigen a gestionar tecnologías individuales, lo que genera redundancias
por Tenología • Comienzan a crearse los procesos de Gestión de Incidencias

Figura 5.1 Lograr madurez en la Gestión de Tecnología

90 | Actividades Comunes de Operación del Servicio

más detalle el rol de los Gestores de Tecnología en Finalmente, el propósito de este capítulo no es proveer
organizaciones con diferentes niveles de madurez. El un análisis detallado de todas las actividades. Están
diagrama no es completo, pero proporciona ejemplos especializadas, y se dispone de una guía detallada de los
sobre cómo se gestiona la tecnología en cada tipo de proveedores de la plataforma y de otros marcos de trabajo
organización. Los encabezados en negrita indican el rol más técnicos; a medida que evolucione la tecnología, se
principal que desempeña TI en la gestión de la tecnología. añadirán nuevas categorías continuamente. Este capítulo
El texto en las flechas describe las características de un simplemente tiene por objetivo destacar la importancia y
departamento de TI en cada nivel. naturaleza de la gestión de la tecnología para la Gestión
del Servicio en el contexto de TI.
El propósito de este diagrama en este capítulo es el
siguiente:
■■ Este capítulo se centra en las actividades de
5.1  Monitorización y control
Gestión Técnica, pero no existe una única forma La medida y control de los servicios se basa en un ciclo
para representarlas. Una organización menos continuo de monitorización, generación de informes y en
madura tenderá a ver estas actividades como fines la acción posterior. Este ciclo se analiza con detalle en esta
en sí mismos, no como medios para un fin. Una sección debido a que es fundamental para la provisión,
organización más madura tenderá a subordinar estas soporte y mejora de los servicios.
actividades a los objetivos de Gestión del Servicio de
También es importante tener en cuenta que, aunque
mayor nivel. Por ejemplo, el equipo de Gestión de
este ciclo tiene lugar durante Operación del Servicio,
Servidores pasará de ser un departamento aislado,
proporciona una base para establecer la estrategia,
centrado únicamente en gestionar servidores, a
designar y probar servicios, y lograr una mejora
transformarse en un equipo que trabaje estrechamente
significativa. Por otra parte es la base de la medición
con otros Gestores de Tecnología para encontrar
de SLM. Por consiguiente, aunque las funciones de
formas de incrementar su valor en el negocio.
Operación del servicio realizan la monitorización, no
■■ Presentar y reforzar el punto de que no hay
debe ser considerada como una cuestión puramente
ninguna forma ‘correcta’ de agrupar y organizar los operativa. Todas las fases del Ciclo de Vida del Servicio
departamentos que realicen estos servicios. Algunos deben garantizar que las medidas y controles se definan,
lectores podrían interpretar los encabezados de este ejecuten y accionen claramente.
capítulo como los nombres de departamentos, pero
este no es el caso. El objetivo de este capítulo es 5.1.1 Definiciones
identificar las actividades técnicas típicas implicadas en
Operación del Servicio. Los aspectos organizativos se La monitorización hace referencia a la actividad de
analizan en el Capítulo 6. observar una situación para detectar los cambios que
■■ Las actividades de Operación del Servicio que se se produzcan con el tiempo.
describen en el resto de este capítulo no son típicas
de cualquiera de los niveles de madurez. Más bien, En el contexto de Operación del Servicio, esto implica lo
las actividades normalmente están todas presentes de siguiente:
alguna forma en todos los niveles. Sólo se organizan y
gestionan de forma diferente en cada nivel. ■■ Usar herramientas para monitorizar el estado de los CI
y actividades operativas clave
En algunos casos, un grupo dedicado podría gestionar ■■ Garantizar que se cumplen (o no se cumplen) las
todo lo relacionado con un proceso o actividad mientras condiciones especificadas y, si no fuera así, levantar
que, en otros casos, los procesos o actividades podrían una alerta destinada al grupo apropiado (p. ej., la
compartirse o dividirse entre grupos. Sin embargo, a disponibilidad de los dispositivos de red clave)
modo de guía general, las siguientes secciones listan las
■■ Garantizar que el rendimiento o utilización de un
actividades requeridas bajo los grupos funcionales que
componente o sistema se encuentre dentro de
con más frecuencia estarán implicados en su operación.
un rango especificado (p. ej., espacio de disco o
Esto no significa que todas las organizaciones tengan que
utilización de memoria)
usar estas divisiones. Las organizaciones más pequeñas
■■ Detectar tipos o niveles anormales de actividad en
tenderán a asignar grupos de estas actividades (si
la infraestructura (p. ej., tratamientos potenciales de
fueran necesarias) a un único departamento, o incluso a
seguridad)
individuos.
 Actividades Comunes de Operación del Servicio | 91

■■ Detectar cambios no autorizados (p. ej., introducción ■■ Medir la disponibilidad

de software) ■■ Iniciar acciones correctivas que podrían estar
■■ Asegurar la conformidad con las políticas de la automatizadas (p. ej., reiniciar un dispositivo de forma
organización (p. ej., uso inapropiado del correo remota o ejecutar un script), o ser manuales (p. ej.,
electrónico) notificar el estado al personal de operaciones).
■■ Realizar el seguimiento de las salidas para el negocio
y garantizar que cumplen los requisitos de calidad y
5.1.2  Bucles de Control de la Monitorización
rendimiento El modelo más habitual para definir el control, es el Bucle
■■ Realizar el seguimiento de cualquier información que de Control de la Monitorización. Aunque es un modelo
se use para medir Indicadores Clave de Rendimiento simple, tiene muchas aplicaciones complejas dentro
(KPIs). de Gestión del Servicio de TI. Esta sección definirá los
conceptos básicos del Modelo de Bucle de Control de
La generación de informes hace referencia al análisis, la Monitorización y las secciones siguientes mostrarán la
producción y distribución de la salida de la actividad importancia de estos conceptos para el Ciclo de Vida de
de monitorización. Gestión del Servicio.

En el contexto de Operación del Servicio, esto implica lo

siguiente: Norma

■■ Usar herramientas para recopilar la salida de

información de monitorización que pueda divulgarse a
varios grupos, funciones o procesos
■■ Interpretar el significado de esa información Controlar Comparar
■■ Determinar dónde se usaría esa información de modo
útil
■■ Garantizar que las personas que toman decisiones
tengan acceso a la información que le permita tomar Monitorizar
decisiones
■■ Encaminar la información obtenida a la persona, grupo
o herramienta apropiados.

Control hace referencia al proceso de gestión de

la utilización o comportamiento de un dispositivo,
sistema o servicio. Si embargo, es importante tener en Entrada Actividad Salida

cuenta que manipular simplemente un dispositivo no

es lo mismo que controlarlo. El control requiere tres
Figura 5.2 El Bucle de Control de la Monitorización
condiciones:
■■ La acción debe garantizar que el comportamiento
La Figura 5.2 describe los principios básicos de control. Se
cumpla una norma o estándar definido
mide una única actividad y su salida usando una norma
■■ Deberán definirse, entenderse y confirmarse las
o estándar predefinidos para determinar si se encuentra
condiciones que provocan la acción dentro de un rango aceptable de rendimiento o calidad.
■■ La acción debe definirse, aprobarse y ser adecuada Si no fuera así, se emprenderán acciones para rectificar la
para estas condiciones. situación o para restablecer el rendimiento normal.
Típicamente, existen dos tipos de Bucles de Control de la
En el contexto de Operación del Servicio, el control Monitorización:
implica lo siguiente:
■■ Los Sistemas de Bucle Abierto se diseñan para
■■ Usar herramientas para definir las condiciones que realizar una actividad específica independientemente
representan operaciones normales u operaciones de las condiciones del entorno. Por ejemplo, puede
anormales iniciarse un backup en un momento y a una
■■ Regular el rendimiento de dispositivos, sistemas o frecuencia dados, y se ejecutará independientemente
servicios de otras condiciones.
92 | Actividades Comunes de Operación del Servicio

■■ Los Sistemas de Bucle Cerrado monitorizan un En este diagrama, cada actividad está controlada por su
entorno y responden a los cambios experimentados propio Bucle de Control de la Monitorización, que usa
en ese entorno. Por ejemplo, un monitor evaluará el un conjunto de normas para esa actividad específica.
tráfico en un circuito para equilibrar la carga de la El proceso completo también tiene su propio Bucle
red. Si el tráfico de red superara un cierto rango, el de Control de la Monitorización, que desarrolla todas
sistema de control comenzará a encaminar tráfico a las actividades y garantiza que todas las normas sean
través de un circuito de backup. El monitor continuará adecuadas y se estén cumpliendo.
proporcionando retroalimentación al sistema de
En la Figura 5.3, existe un doble bucle de
control, que continuará hasta regular el flujo del
retroalimentación. Un bucle se centra exclusivamente en
tráfico de red entre los dos circuitos.
la ejecución de un estándar definido, y el segundo evalúa
Para ayudar a aclarar la diferencia, la resolución de Gestión el rendimiento del proceso y también los estándares con
de Capacidad a través del exceso de provisión es un bucle los que se ejecuta el proceso. Un ejemplo de esto se daría
abierto; un equilibrador de carga que detecte congestión/ si el primer conjunto de bucles de retroalimentación en
fallo y redirija capacidad es un bucle cerrado. la parte inferior del diagrama representara estaciones
individuales en una línea de montaje y el bucle de nivel
5.1.2.1  Bucle Complejo de Control de la superior representara el Aseguramiento de la Calidad.
Monitorización El Bucle Complejo de Control de la Monitorización es
El Bucle de Control de la Monitorización que se muestra una buena herramienta de aprendizaje organizativo
en la Figura 5.2 es una buena base para definir cómo (como define Chris Argyris, (1976) Increasing Leadership
funciona Gestión de Operaciones, pero dentro del Effectiveness. Nueva York: Wiley). El primer nivel de
contexto de ITSM la situación es mucho más compleja. retroalimentación al nivel de actividad individual está
La Figura 5.3 ilustra un proceso que consiste en tres relacionado con la monitorización y respuesta a los
actividades principales. Cada una tiene una entrada y datos (hechos individuales, códigos o elementos de
una salida, y la salida se convierte en una entrada para la información). El segundo nivel está tiene que ver con la
siguiente actividad.

Norma

Controlar Comparar

Monitorizar

Norma Norma Norma

Controlar Comparar Controlar Comparar Controlar Comparar

Monitorizar Monitorizar Monitorizar

Actividad Actividad Actividad

Entrada Salida Entrada Salida Entrada Salida Entrada

Figura 5.3 Bucle de Control de la Monitorización Complejo

 Actividades Comunes de Operación del Servicio | 93

monitorización y respuesta a la información (un conjunto ■■ ¿Con qué frecuencia deben tomarse las medidas?
de varios hechos sobre los que podría extraer una ■■ ¿Necesitamos realizar la medición activa para
conclusión). Consulte la publicación Transición del Servicio comprobar si el elemento está dentro de la norma
para disponer de un análisis completo sobre Datos, o necesitamos esperar hasta que se informe de una
Información, Conocimiento y Saber. excepción (medida pasiva)?
Todo esto es una interesante teoría, pero no explica ■■ ¿Gestión de Operaciones es la única función que
cómo se puede usar el concepto de Bucle de Control realiza la monitorización?
de la Monitorización para operar servicios de TI. Y ■■ Si no fuera así, ¿cómo se asocian las instancias de
especialmente, ¿quién define la norma? En función de lo monitorización con Gestión de Operaciones?
que se ha descrito hasta ahora, los Bucles de Control de la ■■ Si existieran múltiples bucles, ¿qué procesos son
Monitorización pueden servir para gestionar: responsables de cada bucle?
■■ El rendimiento de las actividades en un proceso Las siguientes secciones ampliarán el concepto de Bucles
o procedimiento. Cada actividad y su salida asociada de Control de la Monitorización y mostrarán cómo se
pueden medirse potencialmente para asegurar que responde a estas cuestiones.
se identifiquen los problemas con el proceso antes
que finalice el proceso completo. Por ejemplo, en 5.1.2.2  La boucle de contrôle de l’ITSM
Gestión de Incidencias, el Centro de Servicio al Usuario En ITSM, el Bucle de Control de la Monitorización
monitoriza si un equipo técnico ha aceptado una complejo puede representarse como se muestra en la
incidencia en un tiempo especificado. Si no fuera así, Figura 5.4.
se escala la incidencia. Esto se realiza mucho antes del
La Figura 5.4 puede servir para ilustrar el control de un
tiempo de resolución objetivo para esa incidencia ya
proceso o de los componentes usados para proveer un
que el objetivo de escalar esa actividad es garantizar
servicio. En este diagrama la palabra ‘actividad’ implica
que el proceso se complete a tiempo en su totalidad.
que se refiere a un proceso. Para aplicarlo a un servicio,
■■ La eficacia de un proceso o procedimiento en
una ‘actividad’ también podría ser un ‘CI’. Existen varias
su totalidad. En este caso, el cuadro ‘actividad’ funciones significativas en la Figura 5.4:
representa todo el proceso como una entidad única.
Por ejemplo, Gestión de Cambios medirá el éxito ■■ Cada actividad en un proceso de Gestión del
del proceso comprobando si se implementó un Servicio (o cada componente que se utilice para
cambio a tiempo, según la especificación y dentro del proveer un servicio), se monitoriza dentro de los
presupuesto. procesos de Operación del Servicio. El departamento
o equipo operativo responsable de cada actividad
■■ El rendimiento de un dispositivo. Por ejemplo, el
o componente aplicará el Bucle de Control de la
cuadro ‘actividad’ podría representar el tiempo de
Monitorización como se define en el proceso, y con
respuesta de un servidor bajo una carga de trabajo
las normas que se definieron durante los procesos
dada.
de Diseño del Servicio. El rol de Monitorización y
■■ El rendimiento de una serie de dispositivos. Por
Control Operativo es el de garantizar que el proceso
ejemplo, el tiempo de respuesta del usuario final de
o las funciones del servicio sean exactamente los
una aplicación a través de la red.
especificados, que es la razón por la que están
Para definir cómo usar el concepto de Bucles de Control principalmente involucrados en el mantenimiento del
de la Monitorización en Gestión del Servicio, necesitará estado existente.
responder a las siguientes cuestiones: ■■ Las normas y mecanismos de Monitorización y
■■ ¿Cómo definimos las necesidades a monitorizar? Control se definen en el Diseño del Servicio, pero
se basan en los estándares y arquitecturas definidos
■■ ¿Cuáles son los umbrales adecuados para cada una de
durante Estrategia del Servicio. Cualquier cambio en
éstas?
la Estrategia del Servicio, arquitectura, portfolios de
■■ ¿Cómo se realizará la monitorización (manual o
servicios o Requerimientos de Nivel de Servicio de
automatizada)?
la organización, precipitarán cambios en lo que se
■■ ¿Qué representa la operación normal? monitoriza y cómo se controla.
■■ ¿Cuáles son las dependencias para la operación ■■ Los Bucles de Control de la Monitorización se sitúan
normal? dentro del contexto de la organización. Esto implica
■■ ¿Qué ocurre antes de que tengamos la entrada? que los Ejecutivos del Negocio y de TI ejecutarán
94 | Actividades Comunes de Operación del Servicio

Ejecutivos de Negocio y Gestores de Unidad de Negocio

Estrategia del 1
Servicio 2 Mejora Continua
3 del Servicio

Diseño del Servicio

Portfolios,
Gestión de TI y Gestión de Cuentas de Proveedores

Estándares y Políticas

Arquitecturas Técnicas Transición del Servicio

y Estándares de
Rendimiento

Usuarios
Norma Norma Norma

Controlar Comparar Controlar Comparar Controlar Comparar

Monitorizar Monitorizar Monitorizar

Entrada Actividad Salida Entrada Actividad Salida Entrada Actividad Salida

Personal Técnico y Expertos Internos y Externos

Figura 5.4 El Bucle de Control de la Monitorización en ITSM

fundamentalmente la Estrategia del Servicio con el de la necesidad del negocio de un cambio en el

apoyo de gestores de cuentas del proveedor. Diseño Portfolio de Servicios, o de que la arquitectura no
del Servicio actúa como vínculo entre Estrategia del provee lo que se esperaba.
Servicio y Operación del Servicio, y normalmente ●● Flecha 2. En este caso los Requerimientos de
implicará a representantes de todos los grupos. Nivel de Servicio necesitan ajustarse. Esto podría
Normalmente, el personal de TI ejecutará las representar que el servicio es demasiado caro; o
actividades y controles (algunas veces involucrando que es necesario cambiar la infraestructura para
a usuarios) y estarán apoyados por Directores de TI y mejorar el rendimiento; o debido a que Gestión de
por proveedores. Mejora del Servicio abarca todas las Operaciones es incapaz de mantener la calidad del
áreas, pero principalmente representa los intereses del servicio en la arquitectura real.
negocio y de sus usuarios. ●● Flecha 3. En este caso las normas especificadas
■■ Tenga en cuenta que los procesos de CSI llevan a en Diseño del Servicio no se están cumpliendo.
cabo el segundo nivel de monitorización en este Bucle Esto podría deberse a que no son adecuadas o
de Control de la Monitorización a través de Estrategia no son ejecutables, o a la falta de formación o a
del Servicio y de Diseño del Servicio. Estas relaciones una falta de comunicación. Las normas y la falta
se representan por las flechas numeradas en la Figura de conformidad deberán ser investigadas y se
5.4 de la forma siguiente: tomarán acciones para rectificar la situación.
●● Flecha 1. En este caso CSI ha reconocido que el
Transición del Servicio proporciona un conjunto
servicio se mejorará realizando un cambio en la
importante de comprobaciones y balances en estos
Estrategia del Servicio. Esto podría ser el resultado
procesos. Lo hace de la siguiente manera:
 Actividades Comunes de Operación del Servicio | 95

■■ Para nuevos servicios, Transición del Servicio 5.1.2.3 Definir lo que es necesario monitorizar
garantizará que las arquitecturas técnicas sean las La definición de lo que es necesario monitorizar se basa
adecuadas; y que se puedan ejecutar los Estándares en entender la salida deseada de un proceso, dispositivo o
de Rendimiento Operativo. Esto a su vez garantizará sistema. TI debería centrarse en el servicio y en su impacto
que los departamentos o equipos de Operación del en el negocio, en vez de únicamente en los componentes
Servicio puedan cumplir los Requerimientos de Nivel individuales de la tecnología. La primera pregunta que
de Servicio. es necesario formularse es ‘¿Qué estamos intentando
■■ Para servicios existentes, Gestión de Cambios conseguir?’.
gestionará cualquiera de los cambios que se requieran
como parte de un control (p. ej., ajuste), además 5.1.2.4 Monitorización y Control Interno y
de cualquier cambio representado por las flechas Externo
etiquetadas como 1, 2 y 3. Aunque Transición del
Desde el principio, estará claro que existen dos niveles de
Servicio no defina la estrategia y el diseño de los
monitorización:
servicios por sí misma, proporciona coordinación y
garantiza que los servicios estén funcionando, y que ■■ Monitorización y Control Interno: La mayoría
continuarán como se planificó. de equipos o departamentos se preocupan por
ser capaces de ejecutar las tareas que se les haya
¿Por qué este bucle está recogido bajo Operación asignado de forma eficaz y eficiente. Por lo tanto,
del Servicio? monitorizarán los elementos y actividades que
La Figura 5.4 representa la Monitorización y Control estén directamente bajo su control. Este tipo de
de la totalidad de Gestión del Servicio de TI. Algunos monitorización y control se centra en actividades
lectores de la publicación de Operación del Servicio que están autocontenidas dentro del equipo o
podrían considerar que sería más adecuado que se departamento. Por ejemplo, el Gestor del Centro
trataran en la publicación Estrategia del Servicio. de Servicio al Usuario monitorizará el volumen de
Sin embargo, Monitorización y Control sólo puede llamadas para determinar cuánto personal debe estar
desarrollarse eficazmente cuando el servicio esté disponible para responder al teléfono.
operativo. Esto implica que la calidad de todo el ■■ Monitorización y Control Externo: Aunque cada
conjunto de procesos de Gestión del Servicio de equipo o departamento es responsable de gestionar
TI depende de cómo se monitoriza y controla en su propia área, no actuarán de forma independiente.
Operación del Servicio. Cada tarea que realicen, o dispositivo que gestionen,
Las implicaciones de esto son las siguientes: afecta al éxito de la organización global. Cada
equipo o departamento también estará controlando
■■ El personal de Operación del Servicio no está
elementos y actividades en nombre de otros grupos,
compuesto únicamente por personas interesadas en
procesos o funciones. Por ejemplo, el equipo de
lo que se está monitorizando y cómo se controla.
Gestión de Servidores monitorizará el rendimiento de
■■ Aunque Operación del Servicio es responsable la CPU en los servidores clave, y equilibrará la carga
de monitorizar y controlar los servicios y de trabajo para que una aplicación crítica pueda
componentes, actúan como administradores de permanecer dentro de los umbrales de rendimiento
una parte muy importante del conjunto de bucles establecidos por Gestión de Aplicaciones.
de Monitorización y Control de ITSM
La distinción entre Monitorización Interna y Externa es
■■ Si el personal de Operación del Servicio definiera
importante. Si Operación del Servicio se centrara sólo en
y ejecutara de forma aislada los procedimientos
la Monitorización Interna, tendría una infraestructura muy
de Monitorización y Control, ninguno de los
bien gestionada, pero no habría forma de entender o
procesos o funciones de Gestión del Servicio serán
influir en la calidad de los servicios. Si sólo se centrara en
completamente eficaces. Esto se debe a que las
la Monitorización Externa, entenderá el grado de calidad
funciones de Operación del Servicio no apoyarán
que tiene el servicio, pero no tendrá idea de lo que está
las prioridades y requisitos de información de los
causando una calidad deficiente y cómo cambiarlo.
demás procesos, p. ej., intento de negociar un SLA
cuando los únicos datos disponibles son los índices En realidad, la mayoría de organizaciones tienen una
de cambio de página en un servidor y la utilización combinación de Monitorización Interna y Externa, aunque
detallada del ancho de banda de una red. en muchos casos no están vinculadas. Por ejemplo, el
equipo de Gestión de Servidores conoce exactamente
96 | Actividades Comunes de Operación del Servicio

cómo de bien están funcionando los servidores y el ■■ Identificarán CIs clave, cómo deberán configurarse y
Gestor de Nivel de Servicio conoce exactamente cómo cuales son los niveles de rendimiento y disponibilidad
perciben los usuarios la calidad del servicio proporcionado requeridos para cumplir los Niveles de Servicio
por los servidores. Sin embargo, ninguno de ellos sabe acordados.
cómo vincular estas métricas para definir qué nivel de ■■ Trabajarán con los desarrolladores y proveedores
rendimiento de los servidores representa un servicio de de los CI que integren cada servicio para
buena calidad. Esto resulta aún más confuso cuando el identificar cualquier restricción o limitación en esos
rendimiento del servidor que es aceptable a mediados de componentes.
mes, no es aceptable a finales de mes. ■■ Todos los equipos y departamentos de soporte y
provisión necesitarán identificar la información que
5.1.2.5  Definición de objetivos para les ayudará a ejecutar su rol de forma eficaz. Parte
Monitorización y Control del Diseño del Servicio y del desarrollo servirá para
Muchas organizaciones empiezan respondiendo a la instrumentar cada servicio de modo que pueda ser
pregunta ‘¿Qué estamos gestionando?’. Esto conducirá monitorizado para proporcionar esta información, o de
invariablemente a un Sistema de Monitorización Interno, modo que se puedan generar eventos significativos.
con un vínculo muy débil con la salida o servicio real que Todo esto significa que una parte muy importante de la
requiere el negocio. definición de lo que Operación del Servicio monitoriza, y
La pregunta más adecuada es ‘¿Cuál es el resultado final como realiza el control, es identificar a los interesados de
de las actividades y equipos que mi equipo gestiona?’. cada servicio.
Por lo tanto, el mejor punto de comienzo, al definir qué Los interesados pueden definirse como alguien interesado
monitorizar, es determinar el resultado requerido. en la provisión y recepción satisfactorias de servicios de
La definición de los objetivos de Monitorización y TI. Cada interesado tendrá una perspectiva diferente de
Control debe iniciarse idealmente con la definición de lo que se proveerá, o se recibirá de un servicio de TI.
los documentos de Requisitos del Nivel de Servicio (vea Operación del Servicio necesitará entender cada una de
la publicación Diseño del Servicio). Estos documentos estas perspectivas para determinar exactamente lo que se
especificarán cómo los clientes y usuarios medirán el necesita monitorizar y qué hacer con el resultado.
rendimiento del servicio, y se usan como entrada en Por lo tanto, Operación del Servicio confiará en SLM para
los procesos de Diseño del Servicio. Durante Diseño del definir exactamente quiénes son estos interesados y cómo
Servicio, varios procesos determinarán cómo se proveerá contribuyen a, o utilizan, el servicio. Esto se analiza con
y gestionará el servicio. Por ejemplo, Gestión de la más detalle en las publicaciones Diseño del Servicio y
Capacidad determinará la forma más rentable y apropiada Mejora Continua del Servicio.
de proveer los niveles de rendimiento requeridos.
Gestión de la Disponibilidad determinará cómo se puede Nota sobre los Objetivos de Monitorización
configurar la infraestructura para proporcionar los menores Internos y Externos
puntos de fallo.
El resultado requerido podría ser interno o externo
Si hubiera alguna duda sobre la validez o nivel de detalle a las funciones de Operación del Servicio, aunque
de los objetivos, el marco de trabajo COBIT proporciona siempre se tiene que recordar que una acción
un conjunto de objetivos de alto nivel e integral en la interna normalmente tendrá un resultado externo.
forma de una lista de comprobación. En el Apéndice A de Por ejemplo, la consolidación de servidores para
esta publicación se proporciona más información sobre facilitar su gestión, podría permitir ahorros de costes,
COBIT. que afectarán a la negociación de SLM y al ciclo
El Proceso de Diseño del Servicio ayudará a identificar los de revisión, así como a los procesos de Gestión
siguientes conjuntos de entradas para definir las normas y Financiera.
mecanismos de Monitorización y Control Operativo:
■■ Se trabajará con clientes y usuarios para determinar 5.1.2.6  Tipos de monitorización
cómo se medirá la salida del servicio. Esto incluirá Existen muchos tipos diferentes de herramientas de
mecanismos, frecuencia y muestreo de medición. Esta monitorización y diferentes situaciones en las que se
parte de Diseño del Servicio se centrará especialmente utilizan. Esta sección se centra en algunos de los diferentes
en los Requisitos Funcionales.
 Actividades Comunes de Operación del Servicio | 97

tipos de monitorización que se pueden realizar y cuándo ■■ Monitorización Proactiva se utiliza para detectar
serían adecuados. patrones de eventos que indican que un sistema
o servicio podría estar al borde del fallo. La
Monitorización Activa comparada con la monitorización proactiva normalmente se utiliza en
Monitorización Pasiva entornos más maduros donde estos patrones se han
■■ Monitorización Activa se refiere al ‘examen’ continuo detectado previamente, y a menudo varias veces. Por
de un dispositivo o sistema para determinar su estado. lo tanto, las herramientas de Monitorización Proactiva
Este tipo de monitorización puede necesitar muchos son un medio de automatizar la experiencia del
recursos y normalmente se reserva para monitorizar personal de TI estacional y con frecuencia se crean
proactivamente la disponibilidad de dispositivos o gracias al proceso de Gestión Proactiva de Problemas
sistemas críticos; o como paso de diagnóstico al (vea la publicación Mejora Continua del Servicio).
intentar resolver una Incidencia o diagnosticar un
Tenga en cuenta que la Monitorización Reactiva y
problema.
Proactiva podrían ser activas o pasivas, según la Tabla 5.1:
■■ Monitorización Pasiva es más habitual y hace
referencia a la generación y transmisión de Medición Continua comparada con Medición Basada
eventos a un ‘dispositivo de escucha’ o agente en Excepciones
de monitorización. La Monitorización Pasiva ■■ Medición Continua se centra en monitorizar un
depende de la correcta definición de eventos y sistema en tiempo real para garantizar que cumple
de la instrumentación del sistema que se está una norma de rendimiento (por ejemplo, un servidor
monitorizando (vea la sección 4.1). de aplicaciones está disponible el 99,9% de las
Reactivo frente a Proactivo horas de servicio acordadas). La diferencia entre
■■ La Monitorización Reactiva se diseñó para solicitar Medición Continua y Monitorización Activa es que
o provocar acciones después de un cierto tipo de la Monitorización Activa no tiene que ser continua.
evento o fallo. Por ejemplo, la degradación del Sin embargo, al igual que la Monitorización Activa,
rendimiento de los servidores podría provocar necesita muchos recursos y normalmente está
un reinicio, o un fallo del sistema generaría una reservada para componentes o servicios críticos. En
incidencia. La monitorización reactiva no sólo se la mayoría de los casos, el coste del ancho de banda
utiliza para las excepciones. También se puede usar adicional y de la potencia del procesador supera el
como parte de procedimientos normales de operación, beneficio de la medición continua. En estos casos
por ejemplo, un trabajo por lotes (Job Batch) se a monitorización normalmente se basará en el
completa satisfactoriamente, lo que avisa al sistema de muestreo y en el análisis estadístico (p. ej., se informa
planificación para que envíe el siguiente trabajo por del rendimiento del sistema cada 30 segundos y se
lotes (Job Batch). extrapola para representar el rendimiento general).

Tabla 5.1 Monitorización Reactiva y Proactiva, Activas y Pasivas

Activa Pasiva
Reactiva Sirve para diagnosticar el dispositivo que está causando Detecta y correlaciona registros de eventos para determinar
el fallo y bajo qué condiciones (p. ej., hacer 'ping' de el significado de los eventos y de la acción apropiada (p.
un dispositivo, o ejecutar y hacer el seguimiento de ej., un usuario inicia sesión tres veces con la contraseña
una transacción de muestra a través de una serie de incorrecta, que genera una excepción de seguridad y
dispositivos) se escala a través de procedimientos de Gestión de la
Requiere el conocimiento de la topografía de la Seguridad de la Información)
estructura y de la correspondencia de los servicios con Requiere un conocimiento detallado de la operación normal
respecto a los CI de la infraestructura y de los servicios

Proactiva Sirve para determinar el estado en tiempo real de Los registros de eventos se correlacionan con el tiempo
un dispositivo, sistema o servicio Normalmente para para construir tendencias para la Gestión Proactiva de
componentes críticos o después de la recuperación Problemas.
de un dispositivo que ha fallado para asegurar que se Los patrones de eventos se definen y programan en
recuperó completamente (es decir, que no causará más herramientas de correlación para el futuro reconocimiento
incidencias)
98 | Actividades Comunes de Operación del Servicio

En estos casos, el método de medición tendrá que Basada en Excepciones), se analizará con detalle en la
documentarse y acordarse en los OLA para garantizar publicación Mejora Continua del Servicio.
que sea adecuado para soportar los Requisitos de
Informes del Servicio (vea la publicación Mejora 5.1.2.7  Monitorización en Entornos de Pruebas
Continua del Servicio). Al igual que con cualquier Infraestructura de TI, un
■■ Medición Basada en Excepciones no mide el Entorno de Pruebas necesitará definir cómo utilizará la
rendimiento en tiempo real de un servicio o sistema, monitorización y control. Estos controles se analizan con
pero detecta e informa de las excepciones. Por detalle en la publicación Transición del Servicio.
ejemplo, un evento se genera si no se completa
■■ Monitorización del propio Entorno de Pruebas:
una transacción, o si se alcanzara un umbral de
Un Entorno de Pruebas consta de infraestructura,
rendimiento. Esta forma de medir es más rentable y
aplicaciones y procesos que tienen que gestionarse
sencilla, pero podría generar interrupciones de servicio
y controlarse sólo como cualquier otro entorno.
prolongadas. La Medición Basada en Excepciones se
Es tentador pensar que el Entorno de Pruebas no
usa para sistemas menos críticos o en sistemas en
necesita una monitorización y control rigurosos
los que el coste es un asunto de gran importancia.
debido a que no es un entorno activo. No obstante,
También se usa si las herramientas de TI no son
este argumento no es válido. Si no se monitorizara
capaces de determinar el estado o calidad de un
y controlara adecuadamente un Entorno de Pruebas,
servicio (p. ej., si la calidad de la impresión forma
hay peligro de realizar las pruebas en equipos que
parte de la especificación del servicio, la única forma
se desvíen de los estándares definidos en Diseño del
de medir esto es la inspección física, con frecuencia
Servicio.
realizadas por el usuario más que por el personal de
TI). Si se usa la Medición Basada en Excepciones, es ■■ Monitorización de los elementos que se están
importante que el OLA y el SLA para este servicio probando: Los resultados de la prueba tienen que
lo reflejen, debido a que es más probable que se rastrearse y comprobarse con precisión. También es
produzcan interrupciones del servicio, y normalmente importante que se pruebe cualquier herramienta de
se necesita que los usuarios informen de la excepción. monitorización que se haya integrado en servicios
nuevos o modificados.
Rendimiento frente a salida
5.1.2.8  Generación de informes y acción
Existe una importante distinción entre la generación de
informes para realizar el seguimiento del rendimiento de ’Un informe sólo crea concienciación; un informe con un
componentes o de los equipos o departamentos que se plan de acción logra resultados’.
usan para proveer un servicio, y la generación de informes
que sirven para demostrar el logro de los objetivos de Generación de informes y mal funcionamiento
calidad del servicio.
La experiencia práctica ha demostrado que se generan
Los Directores de TI en muchas ocasiones los confunden más informes en las organizaciones que funcionan mal
informando al negocio del rendimiento de sus equipos o que en las organizaciones eficaces. Esto se debe a que
departamentos (p. ej., número de llamadas atendidas por los informes no se están usando para iniciar planes de
Analista del Centro de Servicio al Usuario), como si fuera la acción predefinidos, sino más bien:
misma cosa que la calidad del servicio (p. ej., incidencias
■■ culpar a otro por una incidencia
resueltas dentro del tiempo acordado).
■■ intentar encontrar quién es el responsable de
Gestión del Servicio debe usar la Monitorización del tomar una decisión
Rendimiento y las métricas para determinar si las ■■ como entrada para crear planes de acción para
personas, el proceso y la tecnología están funcionando futuros eventos.
correctamente y cumpliendo los estándares. En organizaciones que funcionan mal, se generan
Los usuarios y clientes preferirían ver informes asociados muchos informes que nadie tiene tiempo de leer o
con la calidad y el rendimiento del servicio. analizar.

Aunque Operación del Servicio está implicada en ambos La monitorización sin control es irrelevante e ineficaz. La
tipos de informes, el interés principal de esta publicación monitorización siempre debe orientarse a asegurar que se
es la Monitorización del Rendimiento, mientras que la están cumpliendo los objetivos operativos y del servicio.
monitorización de la Calidad del Servicio (o Monitorización Esto significa que no se debería monitorizar un sistema
 Actividades Comunes de Operación del Servicio | 99

o servicio a menos que haya un propósito claro para algunas métricas básicas que podrían servir para medir la
monitorizar. eficacia y eficiencia de un proceso.
Esto también significa que cuando se defina la Aunque esta publicación no aborda principalmente
monitorización debería definirse cualquier acción la medida y a las métricas, es importante que las
necesaria. Por ejemplo, no bastará con poder detectar organizaciones que usen estas directrices tengan métricas
que una aplicación importante ha fallado. El equipo y técnicas de medida robustas que apoyen los objetivos
pertinente de Gestión de Aplicaciones también debe haber de su organización. Esta sección es un resumen de estos
definido los pasos exactos que se seguirán cuando falle la conceptos.
aplicación.
Medición
Además, también debe reconocerse que podría ser
necesario que las acciones sean adoptadas por personas Medición hace referencia a cualquier técnica que
diferentes, por ejemplo, un simple evento (como por se utilice para evaluar la extensión, dimensión o
ejemplo el fallo de una aplicación) podría disparar una capacidad de un elemento en relación con un estándar
acción del equipo de Gestión de Aplicaciones (para o unidad.
restaurar el servicio), de los usuarios (para iniciar el
■■ Extensión hace referencia al grado de conformidad
procesamiento manual) y de la dirección (para determinar
o cumplimiento (p. ej., si todos los cambios
cómo se puede evitar este evento en el futuro).
son autorizados formalmente por la autoridad
Las implicaciones de este principio se describen con más apropiada)
detalle en relación con Gestión de Eventos (vea la ■■ Dimensión hace referencia al tamaño de un
sección 4.1). elemento, p. ej., el número de incidencias resueltas
por el Centro de Servicio al Usuario
5.1.2.9  Auditorías de Operación del Servicio ■■ Capacidad hace referencia a la capacidad total
Deben realizarse auditorías regulares en los procesos y de un elemento, por ejemplo, máximo número
actividades de Operación del Servicio para garantizar que: de transacciones estándar por minuto que puede
■■ Se están realizando como se pretendía procesar un servidor.
■■ No existen engaños
La medida sólo se convierte en significativa cuando es
■■ Todavía son adecuados para su propósito, o para
posible medir la salida real o las dimensiones de un
identificar cualquier cambio o mejora que se requiera.
sistema, función o proceso con respecto a un estándar
Los Gestores de Operación del Servicio podrían decidir o nivel deseado, p. ej., el servidor debe ser capaz de
realizar ellos mismos tales auditorías, pero idealmente es procesar un mínimo de 100 transacciones estándar por
preferible alguna forma de elemento independiente para minuto. Esto deberá definirse en Diseño del Servicio, y
realizar las auditorías. perfeccionarse con el tiempo a través de Mejora Continua
del Servicio, pero la propia medida tiene lugar durante
Se podría solicitar la implicación del equipo o
Operación del Servicio.
departamento de auditoría interna de TI de la
organización, o bien las organizaciones podrían decidir Métricas
la contratación de empresas de consultoría/auditoría/
valoración externas para que se obtenga una visión Métricas hace referencia a la evaluación periódica y
experta completamente independiente. cuantitativa de un proceso, sistema o función, junto
Las auditorías de Operación del Servicio forman parte de con los procedimientos y herramientas que se usarán
la medida continua que tiene lugar como parte de Mejora para hacer estas evaluaciones y los procedimientos
Continua del Servicio y se analizan con más detalle en esa para interpretarlos.
publicación.
Esta definición es importante porque no sólo especifica lo
5.1.2.10  Medición, métricas y KPIs que es necesario medir, sino también cómo medirlo, cuál
será el rango de rendimiento aceptable y qué acciones es
Esta sección se ha centrado principalmente en la
necesario tomar como resultado del rendimiento normal
monitorización y control como base para Operación del
o de una excepción. Por lo tanto, está claro que cualquier
Servicio. Otras secciones de la publicación han abordado
métrica indicada en la sección previa de esta publicación
es una métrica muy básica y necesitará aplicarse y
100 | Actividades Comunes de Operación del Servicio

ampliarse dentro del contexto de cada organización antes una incidencia, sino en si se resolvió dentro del tiempo
de que pueda ser eficaz. acordado, y si es posible evitar futuras incidencias.

Indicadores Clave de Rendimiento (KPI) Sin embargo, CSI no sólo se interesa por las excepciones.
Si se cumple un SLA de forma consistente a lo largo del
Un KPI hace referencia a un nivel de rendimiento tiempo, CSI también estará interesado en determinar si ese
acordado y específico que se utilizará para medir la nivel de rendimiento puede mantenerse a un coste inferior
eficacia de una organización o proceso. o si es necesario mejorarlo hasta un nivel de rendimiento
incluso superior. Por consiguiente, CSI también puede
Los KPI son únicos para cada organización y tienen que tener la necesidad de recibir informes de rendimiento
estar relacionados con entradas, salidas y actividades regulares.
específicas. No son genéricos o universales y, por lo tanto, No obstante, debido a que es improbable que CSI
no han sido incluidos en esta publicación. necesite, o pueda manejar, la ingente cantidad de datos
Una razón adicional para no incluirlos es el hecho de que se generan en toda la actividad de monitorización,
que se pueden usar métricas similares para lograr KIPs normalmente se centrará en un subconjunto específico
muy diferentes. Por ejemplo, una organización empleó la de datos de monitorización en un momento dado. Esto
métrica ‘Porcentaje de Incidencias resueltas por el Centro podría determinarse en función de la entrada procedente
de Servicio al Usuario’ para evaluar el rendimiento del del negocio o de las mejoras en la tecnología.
Centro de Servicio al Usuario. Esto funcionó eficazmente Esto presenta dos implicaciones principales:
durante aproximadamente dos años, después de los
cuales el director de TI comenzó a darse cuenta de que ■■ La monitorización para CSI cambiará a lo largo del
este KPI se estaba usando para evitar una Gestión de tiempo. Pueden estar interesados en monitorizar
Problemas eficaz, es decir, si, después de dos años, el 80% el servicio de correo electrónico un trimestre, y
de todas las incidencias se pueden resolver en 10 minutos en analizar los sistemas de RR.HH. en el trimestre
en la primera llamada, ¿por qué no hemos sacado una siguiente.
solución para ellas? Efectivamente, el KPI se transformó ■■ Esto quiere decir que Operación del Servicio y CSI
ahora en una medida de la ineficacia de los equipos de necesitan crear un proceso que les ayude a acordar
Gestión de Problemas. las áreas que es necesario monitorizar y para qué
propósito.
5.1.2.11  Interfaces con otras prácticas del Ciclo
de Vida del Servicio 5.2  Operaciones de TI
Monitorización Operativa y Mejora Continua del
Servicio 5.2.1  Gestión de Consolas/Puente de
Esta sección se ha centrado en la Monitorización
Operaciones
y Generación de Informes Operativos, aunque la Ofrecen un punto de coordinación central para gestionar
monitorización también constituye el punto de inicio varias clases de eventos, detectar incidencias, gestionar
para Mejora Continua del Servicio. Esto se aborda en la actividades operativas rutinarias, e informar del estado o
publicación Mejora Continua del Servicio, pero aquí se rendimiento de la tecnología.
indican las diferencias clave. La observación y monitorización de la Infraestructura
La Calidad es el objetivo clave de monitorización para la de TI puede realizarse desde una consola centralizada
Mejora Continua del Servicio (CSI). Por consiguiente, la hacia la que se encaminan todos los eventos del
monitorización se centrará en la eficacia de un servicio, sistema. Históricamente, esto implica la monitorización
proceso, herramienta, organización o CI. El énfasis no está de la consola de operaciones maestras de uno o más
en asegurar un rendimiento del servicio en tiempo real; mainframes, aunque hoy en día es más probable que
en lugar de esto se trata de identificar dónde se pueden implique la monitorización de una torre de servidores,
realizar las mejoras en los niveles de servicio existentes, o dispositivos de almacenamiento, componentes de red,
el rendimiento de TI. aplicaciones, bases de datos o de cualquier otro CI,
incluyendo cualquier mainframe restante, desde una única
Por consiguiente, la monitorización para CSI tenderá a ubicación, conocida como el Puente de Operaciones.
centrarse en la detección de excepciones y resoluciones.
Por ejemplo, CSI no está tan interesada en si se resolvió Existen dos teorías sobre la razón por la que se utilizó
el nombre de Puente de Operaciones. Una es que se
 Actividades Comunes de Operación del Servicio | 101

asemeja al puente de una gran nave automatizada (como de servicios; o como parte del mantenimiento rutinario
las naves espaciales que se ven en las películas de ciencia encargado por los equipos de Gestión Técnica y de
ficción). La otra teoría es que el Puente de Operaciones Aplicaciones.
representa un vínculo entre los equipos de Operaciones
Planificación de Trabajos implica la definición e inicio de
de TI y el Centro de Atención al Usuario tradicional. En
paquetes de software (Job´s o scripts) de planificación de
algunas organizaciones esto significa que las funciones
trabajos para ejecutar el trabajo en tiempo real y por lotes
del Control Operativo y del Centro de Atención al Usuario
(Batch). Esto normalmente implicará planificaciones diarias,
se fundieron en el Centro de Servicio al Usuario, que
semanales, mensuales, anuales y ad hoc para satisfacer las
realizaba ambos conjuntos de tareas desde una única
necesidades del negocio.
ubicación física.
Además del diseño inicial, o del rediseño periódico, de
Independientemente de cómo se denomine, un Puente
las planificaciones, es probable que haya frecuentes
de Operaciones reunirá todos los puntos críticos de
modificaciones o ajustes a realizar, durante los cuales,
observación dentro de la infraestructura de TI para que
es necesario identificar y adecuar las dependencias de
se puedan monitorizar y gestionar desde una ubicación
trabajos (Job´s). Habrá también un rol que desempeñar en
centralizada con el mínimo esfuerzo. Es probable que los
la definición de alertas y en los Informes de Excepciones
dispositivos que se están monitorizando estén físicamente
a usar para monitorizar/comprobar planificaciones de
dispersos y que se puedan ubicar en instalaciones
trabajo. Gestión de Cambios desempeña un rol importante
informáticas centralizadas o distribuidas dentro de la
a la hora de evaluar y validar cambios importantes en
comunidad de usuarios, o ambos casos.
las planificaciones, además de crear procedimientos de
El Puente de Operaciones combinará muchas actividades, Cambios Estándar para cambios más rutinarios.
que podrían incluir Gestión de Consolas, gestión de
Es necesario que se reciban (o se agilicen si se retrasan)
eventos, gestión de red de primera línea, Planificación de
e introduzcan en tiempo de ejecución los parámetros
Trabajos y soporte de atención continuada (para el Centro
y/o archivos, y que se comprueben todos los registros de
de Servicio al Usuario y/o grupos de soporte de segunda
tiempo de ejecución y se identifique cualquier fallo.
línea si no están operativos las 24 horas 7 días a la
semana). En algunas organizaciones, el Centro de Servicio Si se produjeran fallos, entonces tendrá que iniciarse
al Usuario forma parte del Puente de Operaciones. el re-arranque, bajo la orientación de las unidades de
negocio adecuadas, a menudo con diferentes parámetros
La ubicación y diseño físico del Puente de Operaciones
o versiones de datos/archivos modificados. Esto requerirá
debe realizarse con precisión para ofrecer al personal
comunicaciones precisas para garantizar que se usen los
autorizado la accesibilidad y visibilidad correctas de todas
parámetros y archivos correctos.
las pantallas y dispositivos pertinentes. Sin embargo, esta
será un área muy sensible en el caso de que sea esencial Muchas organizaciones se enfrentan a un incremento de
el acceso controlado y un alto grado de seguridad. las planificaciones de trabajos por lotes (batch) nocturnas
que pueden, si desbordan la franja horaria de trabajos por
Puede que las organizaciones más pequeñas no tengan
lotes (batch) nocturna, impactar negativamente en los
un Puente de Operaciones físico, pero siempre existirá
dispositivos online diarios, por lo que se están buscando
la necesidad de Gestión de Consolas, normalmente en
formas de utilizar el rendimiento y la capacidad máxima
combinación con otros roles técnicos. Por ejemplo, un
del horario nocturno junto con Gestión de la Capacidad.
único equipo de personal técnico gestionará la red,
Aquí es donde las técnicas de Gestión de la Carga de
servidores y aplicaciones. Parte de su rol será monitorizar
Trabajo pueden ser útiles, como por ejemplo:
las consolas para esos sistemas, en muchas ocasiones
usando consolas virtuales para que puedan realizar ■■ Replanificar el trabajo para evitar la contención en
la actividad desde cualquier ubicación. Sin embargo, dispositivos específicos o en horarios específicos y
debe tenerse en cuenta que estas consolas virtuales son mejorar el rendimiento general
herramientas poderosas y, si se usan en ubicaciones ■■ La migración de las cargas de trabajo a plataformas/
inseguras o sobre conexiones desprotegidas, podrían entornos alternativos para mejorar el rendimiento
representar una amenaza importante en la seguridad. y/o producción (las capacidades de virtualización
lo facilitan al permitir la migración dinámica y
5.2.2 Planificación de Trabajos automatizada)
Operaciones de TI realizará las rutinas estándar, peticiones
o informes que se les encargue como parte de la provisión
102 | Actividades Comunes de Operación del Servicio

■■ La sincronización precisa y la ‘intercalación’ de Además, los requisitos regulatorios especifican que

trabajos para obtener la máxima utilización de ciertos tipos de organización (como por ejemplo
recursos disponibles. Servicios Financieros o empresas listadas) deben tener
una estrategia formal de Backup y Restauración y que
Anécdota debe ejecutarse y auditarse esta estrategia. Los requisitos
exactos variarán en función del país y del sector industrial.
Una organización grande, que se enfrentó a problemas Esto deberá determinarse durante el Diseño del Servicio e
de desborde/utilización de lotes (procesos batch), integrarse en la funcionalidad y en la documentación del
identificó que, debido a que la naturaleza humana servicio.
impulsa a que las personas sean ‘ordenadas’, todos los
trabajos estaban iniciándose a cada hora exacta o en El único aspecto a tener en cuenta con los backups es
intervalos de 15 minutos durante la hora (es decir, a que podrían necesitar ser restaurados en algún punto. Por
las n en punto, a los 15 minutos, a la media hora, a las esta razón, no es tan importante definir cómo realizar el
menos cuarto, etc.). backup de un sistema como definir los componentes que
están en riesgo y cómo mitigar eficazmente ese riesgo.
Con la replanificación del trabajo para que empezara
tan pronto como terminara otro trabajo, y con el Existe un gran número de herramientas disponibles
escalonado de los tiempos de inicio de otro trabajo, para Backup y Restauración, pero merece la pena tener
fue capaz de obtener reducciones significativas en la en cuenta las funcionalidades de las tecnologías de
contención y lograr un procesamiento mucho más almacenamiento empleadas para datos del negocio
rápido, lo que permitió resolver sus problemas sin la que se están usando para backup/restauración (p. ej.,
necesidad de actualizaciones. instantáneas). Por lo tanto, cada vez se produce un mayor
grado de integración entre las actividades de Backup y
La Planificación de Trabajos se ha convertido en una Restauración y las de Almacenamiento y Archivo (vea la
actividad altamente sofisticada que incluye cualquier sección 5.6).
número de variables, como por ejemplo sensibilidad al
tiempo, dependencias que no son críticas, balanceo de la 5.2.3.1  Backup
carga de trabajo, fallo y reenvío, etc. Como resultado de Los datos de la organización tienen que estar protegidos
ello, la mayoría de las “Operaciones” confían en que las y esto incluirá el backup (copia) y almacenamiento de
herramientas de Planificación de Trabajos permitan que datos en ubicaciones remotas en las se puedan proteger
Operaciones de TI planifique trabajos para realizar un uso y usar si fuera necesario restaurar debido a la pérdida,
óptimo de la tecnología y, con ello, lograr los Objetivos corrupción o implementación de Planes de Continuidad
del Nivel de Servicio. de los Servicios de TI.
La última generación de herramientas de planificación Deberá acordarse la estrategia de backup con el negocio,
permite que un conjunto único de herramientas sirva abordando:
para planificar y automatizar actividades técnicas y
■■ A qué datos se tienen que aplicar el backup y la
actividades de proceso de Gestión del Servicio (como
frecuencia e intervalos a usar.
por ejemplo Planificación de Cambios). Aunque esta es
■■ Cuántas generaciones de datos es necesario conservar.
una gran oportunidad para mejorar la eficiencia, también
Esto podría variar según el tipo de datos a los que se
representa un punto único de fallo mayor. Por lo tanto, las
está aplicando el backup, y el tipo de archivo (p. ej.,
organizaciones que usan este tipo de herramienta todavía
archivo de datos o aplicación ejecutable).
usan soluciones puntuales, como agentes y también como
un backup en caso de fallo en el conjunto principal de ■■ El tipo de backup (completo, parcial, incremental) y
herramientas. los puntos de control (Checkpoint’s) a usar.
■■ Las ubicaciones a usar para el almacenamiento
5.2.3  Backup y Restauración (probablemente para incluir sitios de recuperación de
desastres) y planificaciones de rotación.
Backup y Restauración es principalmente un componente
de una buena Planificación de la Continuidad de los ■■ Métodos de transporte (p. ej., transferencia de
Servicios de TI. Propiamente dicho, Diseño del Servicio archivos a través de la red, transporte físico en soporte
aseguraría que existan estrategias sólidas de backup para magnético).
cada servicio, y Transición del Servicio garantizaría que ■■ Prueba/comprobaciones a realizar, como lecturas
éstas se prueben adecuadamente. de prueba, restauraciones de prueba, sumas de
verificación, etc.
 Actividades Comunes de Operación del Servicio | 103

■■ Punto Objetivo de Recuperación. Describe el punto Si los backups se estuvieran automatizando o realizando
en el que se restaurarán los datos después de la de forma remota, entonces deberán considerarse las
recuperación de un Servicio de TI. Esto podría implicar capacidades de Monitorización de Eventos para que se
la pérdida de datos. Por ejemplo, un Punto Objetivo pueda detectar anticipadamente y rectificar cualquier
de Recuperación de un día podría estar apoyado por fallo antes de que provoque problemas. En tales casos,
backups diarios, y se podrían perder hasta 24 horas Operaciones de TI tiene un rol que desempeñar en la
de datos. El Punto Objetivo de Recuperación para definición de alertas y rutas de escalado.
cada servicio de TI deberá negociarse, acordarse y
En todos los casos, el personal de Operaciones de TI
documentarse en OLAs, SLAs y UCs.
debe estar formado en los procedimientos de backup (y
■■ Tiempo Objetivo de Recuperación. Describe el
restauración), que deben documentarse adecuadamente
tiempo máximo permitido para la recuperación de un en el Manual de Procedimientos de Operaciones de TI de
servicio de TI después de una interrupción. El Nivel la organización. Cualquier requisito u objetivo específico
de Servicio a proporcionar podría ser menor que los debe aparecer en OLAs y UCs cuando proceda, al mismo
Objetivos de Nivel de Servicio habituales. El Tiempo tiempo que deberá especificarse cualquier requisito o
Objetivo de Recuperación para cada servicio de TI actividad de usuario o cliente en el SLA apropiado.
deberá negociarse, acordarse y documentarse en OLAs,
SLAs y UCs. 5.2.3.2  Restauración
■■ Cómo verificar que los backups funcionarán si fueran
Una restauración se puede iniciar a partir de varias fuentes,
necesarios para restaurar. Incluso si no se hubieran
que van desde un evento que indique la corrupción de
generado códigos de errores, podrían producirse varias
datos, hasta una Petición de Servicio de un usuario o
razones por las que no se pudiera restaurar el backup.
cliente registrado en el Centro de Servicio al Usuario.
El riesgo de que esto se produzca se minimizará
Podría ser necesaria una restauración en caso de:
con una buena estrategia de backup y con buenos
procedimientos de operaciones. Los procedimientos ■■ Datos corruptos
de backup deben incluir un paso de verificación ■■ Datos perdidos
para garantizar que se completen los backups y que ■■ Situación de recuperación de desastres/Continuidad de
funcionen si se necesitara una restauración. Si se Servicios de TI
detectara cualquier fallo de backup, deberán iniciarse ■■ Datos históricos requeridos para investigación forense.
acciones de recuperación.
Los pasos que se tomarán incluirán:
También existe una necesidad de comprar y gestionar los
■■ Localización de los datos/medios apropiados
medios necesarios (discos, cintas, CDs, etc.) a usar para los
backups, para que no haya escasez de suministro. ■■ Transporte o transferencia inversa hasta la ubicación
de recuperación física
Si se estuvieran usando dispositivos automatizados, será
■■ Acuerdo sobre el punto de recuperación del punto de
necesaria la precarga anticipada de los medios necesarios.
control (Checkpoint) y la ubicación específica para los
Al cargar y quitar medios recuperados del almacenamiento
datos recuperados (disco, directorio, carpeta, etc.)
off-site, es importante que haya un procedimiento para
■■ Restauración real del archivo/datos (post escritura a
verificar que sean los correctos. Esto evitará que el
memoria y restauración a un estado previo/posterior)
backup más reciente se esté sobrescribiendo con datos
necesarios para llegar al punto de control (Checkpoint)
defectuosos y, por lo tanto, que no se disponga de datos
acordado
válidos para restaurar. Después de que hayan realizado
■■ Comprobación para garantizar que la restauración se
backups satisfactorios, los medios deberán retirarse para su
almacenamiento. haya completado satisfactoriamente, con acciones de
recuperación posteriores si fuera necesario, hasta que
El inicio real de los backups podría automatizarse, o se haya alcanzado el éxito.
llevarse a cabo desde el Puente de Operaciones. ■■ Aprobación de usuario/cliente.
Algunas organizaciones podrían utilizar el personal
de Operaciones para realizar el transporte físico y el
5.2.4 Impresión y Salida
apilamiento de copias de backup en/desde ubicaciones Muchos servicios consisten en la generación y envío de
remotas, en las que, en otros casos, esto podría transferirse información en formato impreso o electrónico. Asegurar
a otros grupos como al personal de seguridad interno o a que la información correcta llegue a las personas
contratistas externos.
104 | Actividades Comunes de Operación del Servicio

adecuadas, con absoluta integridad, requiere un control y servicios y, por lo tanto, su rendimiento establecerá una
una gestión formales. línea de referencia para el rendimiento del servicio y las
expectativas del usuario o cliente, aunque es posible que
Las instalaciones de Impresión (físicas) y Salida
nunca sean conscientes de que están haciendo uso del
(electrónicas) y los servicios necesarios, deben gestionarse
mainframe.
formalmente debido a que:
Las formas en las que se organizan los equipos de
■■ A menudo representan la salida tangible de un
gestión del mainframe son bastante diversas. En algunas
servicio. Por lo tanto, es muy importante la capacidad
organizaciones la Gestión del Mainframe es un equipo
para medir que esta salida ha alcanzado el destino
individual y altamente especializado que gestiona todos
adecuado (por ejemplo, comprobar que los archivos
los aspectos, desde las operaciones diarias hasta la
con datos de transacciones financieras hayan llegado
ingeniería del sistema. En otras organizaciones, varios
realmente al banco a través de un servicio FTP).
equipos o departamentos realizan las actividades, con
■■ La salida física y electrónica contiene en muchas
un equipo que proporciona la ingeniería y el soporte de
ocasiones información sensible o confidencial. Es
tercer nivel, y combinando las operaciones diarias con
esencial que se apliquen los niveles de seguridad
el resto de Operaciones de TI (y, muy probablemente,
adecuados tanto en la generación como en la entrega
gestionadas a través del Puente de Operaciones).
de esta salida.
Normalmente, es probable que se realicen las siguientes
Muchas organizaciones contarán con requisitos de
actividades:
impresión en papel que Operaciones de TI debe gestionar.
■■ Mantenimiento y soporte del sistema operativo del
Además de la carga y recarga física de papel y la
mainframe
operación y cuidado de las impresoras, es posible que se
■■ Soporte de tercer nivel para cualquier incidencia/
requieran otras actividades, como por ejemplo:
problema relacionado con el mainframe
■■ Acuerdo y establecimiento de la notificación previa ■■ Escritura de scripts de trabajo
a tiradas grandes y alertas para evitar la impresión ■■ Programación del sistema
excesiva debido a trabajos de impresión indebidos
■■ Soporte para la interfaz con el hardware (H/W);
■■ Control físico de la papelería de alto valor, como los
organización del mantenimiento, acuerdo de
cheques o los certificados de la compañía, etc. franjas de tiempo, identificación del fallo de H/W,
■■ La gestión de los medios de almacenamiento físico colaboración con ingeniería de H/W.
y electrónico necesarios para generar la salida. En ■■ Provisión de información y asistencia a Gestión de la
muchos casos, se esperará que TI proporcione archivos Capacidad para ayudar a conseguir el rendimiento,
para los materiales impresos y electrónicos utilización y funcionamiento óptimo del mainframe.
■■ Control de todo el material impreso, para cumplir
la legislación y regulación de protección de datos, 5.4  Gestión y Soporte de Servidores
por ejemplo HIPAA (Health Insurance Portability and
Accountability Act) en los EE.UU., o FSA (Financial Los servidores se utilizan en la mayoría de las
Services Authority) en el Reino Unido. organizaciones para proporcionar servicios flexibles y
accesibles para el alojamiento de aplicaciones o bases de
En aquellos casos en los que los servicios se proveen datos, ejecutar servicios cliente/servidor, Almacenamiento,
directamente a los usuarios, es importante que se defina Impresión y Administración de Archivos. Por lo tanto, la
claramente la responsabilidad del mantenimiento de gestión satisfactoria de los servidores es vital para el éxito
las impresoras o los dispositivos de almacenamiento. de Operación del Servicio.
Por ejemplo, la mayoría de los usuarios asumen que TI
debe encargarse de la limpieza y el mantenimiento de Entre los procedimientos y actividades que deben realizar
las impresoras. Si no se hace así, el SLA debe indicarlo los Equipos o departamentos de Servidores (puede que
claramente. se requieran equipos independientes cuando se utilicen
diferentes tipos de servidores (UNIX, Wintel, etc.) se
incluyen:
5.3  Gestión del Mainframe
■■ Soporte al sistema operativo: Soporte y
Los mainframes continúan siendo muy utilizados y mantenimiento de los sistemas operativos pertinentes
cuentan con prácticas bien establecidas y maduras. Los y del software de las utilidades vinculadas (por
mainframes conforman el componente central de muchos ejemplo, software de conmutación automática) que
 Actividades Comunes de Operación del Servicio | 105

incluyen la gestión de parches y la implicación en la analiza con más detalle en Diseño del Servicio y
definición de las políticas de backup y restauración. Transición del Servicio.
■■ Gestión de licencias: para todos los CI del servidor, ●● Montaje e instalación de nuevos servidores como
especialmente sistemas operativos, utilidades y parte del mantenimiento continuo o para la
cualquier software de aplicaciones no gestionado por provisión de nuevos servicios. Esto se analiza con
los equipos de Gestión de Aplicaciones. más detalle en Transición del Servicio.
■■ Soporte de tercer nivel: soporte de tercer nivel para ●● Configuración y gestión de clusters que estén
todas las incidencias relacionadas con el servidor destinados a establecer redundancia, mejorar el
y/o el sistema operativo del servidor, incluyendo rendimiento del servicio y facilitar la gestión de la
las actividades de diagnóstico y restauración. Esto infraestructura.
también incluirá la colaboración con terceros ■■ Mantenimiento continuo. Normalmente consta
contratistas de soporte del hardware y/o fabricantes de servidores de repuesto o ‘blades’ según un
que se requieran para escalar las incidencias calendario de renovación para asegurar que se
relacionadas con el hardware. sustituya el equipo antes de que falle o quede
■■ Asesoramiento para el aprovisionamiento: obsoleto. Esto permite que los servidores no sólo sean
asesoramiento y guía al negocio para la selección, completamente funcionales, sino que también sean
dimensionamiento, aprovisionamiento y uso de los capaces de dar soporte a la evolución de los servicios.
servidores y el software de las utilidades vinculadas ■■ Retirada del servicio activo y eliminación del
para satisfacer las necesidades del negocio. equipo servidor antiguo. A menudo se realiza junto
■■ Seguridad del sistema: control y mantenimiento con las políticas medioambientales de la organización
de los controles y permisos de acceso a los entornos para la eliminación de residuos.
de servidores pertinentes, así como de las medidas
adecuadas de seguridad física y del sistema. Entre 5.5  Gestión de Red
estas actividades se incluye la identificación y
Debido a que la mayoría de los servicios de TI dependen
aplicación de parches de seguridad, Gestión de
de la conectividad, Gestión de Red será esencial
Accesos (vea la sección 4.5) y la detección de
para proveer servicios y para permitir también que el
intrusiones.
personal de Operación del Servicio acceda y gestione los
■■ Definición y gestión de servidores virtuales:
componentes clave del servicio.
implica que se pueda utilizar cualquier servidor
que se haya diseñado y fabricado con un estándar Gestión de Red tendrá la responsabilidad general sobre
común para procesar cargas de trabajo de diversas todas las Redes de Área Local (LAN), Redes de Área
aplicaciones y clientes. Se requerirá Gestión del Metropolitana (MAN) y Redes de Área Ancha (WAN) que
Servidor para establecer estos estándares y asegurar pertenezcan a la organización, y también será responsable
posteriormente que las cargas de trabajo se equilibren de establecer contacto con los suministradores de red
y distribuyan correctamente. También es responsable externos.
de realizar el seguimiento de qué servidor está Su rol incluirá las siguientes actividades:
procesando qué carga de trabajo para tratar las
incidencias de forma eficaz. ■■ Planificación inicial e instalación de nuevas redes o
■■ Capacidad y Rendimiento: proporciona información componentes de red, mantenimiento y mejoras de la
y asistencia a Gestión de la Capacidad para ayudar a infraestructura de la red física. Esto se realiza a través
conseguir el rendimiento, utilización y funcionamiento de Diseño del Servicio y Transición del Servicio.
óptimos de los servidores disponibles. Esto se analiza ■■ Soporte de tercer nivel para todas las actividades
con mayor detalle en Diseño del Servicio, pero incluye relacionadas con la red, incluyendo la investigación de
la provisión de una orientación sobre el software de los problemas de la red (por ejemplo la comprobación
virtualización así como su instalación y operación para de dispositivos o direcciones web activos y/o uso
conseguir valor a cambio del dinero mediante unos de herramientas software de gestión, aunque debe
niveles de rendimiento más elevados y el uso de un tener en cuenta que la comprobación de actividad
número mínimo de servidores. de un servidor no implica necesariamente que el
■■ Otras actividades rutinarias incluyen: servicio esté disponible) y establecimiento de los
contactos necesarios con terceros. Esto también
●● Definir arquitecturas estándar para los servidores
incluye la instalación y uso de herramientas
como parte del proceso de provisión. Esto se
‘husmeadoras’(sniffers) que analicen el tráfico de
106 | Actividades Comunes de Operación del Servicio

red para ayudar en la resolución de incidencias y

Nota sobre la gestión de VoIP como un servicio
problemas.
■■ Mantenimiento y soporte del sistema operativo de la Muchas organizaciones han experimentado problemas
red y del software middleware, incluyendo la gestión de rendimiento y disponibilidad con sus soluciones de
de parches, actualizaciones, etc. VoIP, a pesar del hecho de que parece haber un ancho
■■ La monitorización del tráfico de red para identificar los de banda disponible más que suficiente. Esto provoca
fallos o localizar problemas potenciales asociados con una caída de las llamadas y una calidad de sonido
el rendimiento o con cuellos de botella. deficiente. Esto normalmente se debe a las variaciones
■■ Reconfiguración o reencaminamiento del tráfico para en el ancho de banda durante la llamada, que suelen
conseguir una mejora del rendimiento o un mejor ser el resultado del uso de la red por parte de otros
equilibrio; definición de reglas para el equilibrado/ usuarios, aplicaciones u otra actividad de la web. Esto
encaminamiento dinámico. ha provocado la diferenciación entre la medición del
ancho de banda disponible para iniciar una llamada
■■ Seguridad de la red (en colaboración con Gestión de
(Ancho de Banda de Acceso al Servicio – o SAB) y la
la Seguridad de la Información de la organización),
cantidad de ancho de banda que debe estar disponible
que incluye la gestión del firewall, derechos de acceso,
de forma continua durante la llamada (Ancho de Banda
protección con contraseñas, etc.
de Utilización del Servicio – o SUB). Debería prestar
■■ Asignación y gestión de direcciones, Domain Name
atención para diferenciar entre estos anchos de banda
Systems (DNSs – que transforman el nombre de
al diseñar, gestionar o medir servicios de VoIP.
un servicio en su dirección IP asociada) y sistemas
Dynamic Host Configuration Protocol (DHCP), que
permiten acceder y usar el DNS.
5.6  Almacenamiento y Archivo
■■ Gestión de Proveedores de Servicio de Internet (ISP).
■■ Implementación, monitorización y mantenimiento de Muchos servicios requieren el almacenamiento de datos
Sistemas de Detección de Intrusiones en nombre de durante un tiempo determinado y que estos datos estén
Gestión de la Seguridad de la Información. También disponibles fuera de línea durante un cierto periodo de
serán responsables de asegurar que no se deniegue el tiempo después de que se dejen de utilizar. A menudo
servicio a los usuarios legítimos de la red. esto es necesario debido a los requisitos regulatorios o
legislativos, pero también a que los datos del historial y
■■ Actualización de Gestión de la Configuración, según
de auditoría tienen un valor incalculable para diversos
se requiera, documentando los CI, estados, relaciones,
propósitos, incluyendo marketing, desarrollo de producto,
etc.
investigaciones forenses, etc.
A menudo, Gestión de Red también es responsable, en
Es posible que se requiera un equipo o departamento
ocasiones junto con Soporte al Puesto de Trabajo, de los
independiente para gestionar la tecnología de
asuntos de conectividad remota como las funcionalidades
almacenamiento de datos de la organización, como por
de recepción de llamadas, devolución de llamada y
ejemplo:
VPN para los teletrabajadores, trabajadores remotos o
suministradores. ■■ Dispositivo de almacenamiento, como discos,
controladores, cintas, etc.
Algunos equipos o departamentos de Gestión de
■■ Network Attached Storage (NAS), que es un
Red también serán responsables de los servicios
de voz/telefonía, incluyendo la provisión y soporte almacenamiento vinculado a una red y al que pueden
de intercambios, líneas, ACD, paquetes de software acceder varios clientes
estadístico, etc., y de los sistemas de Voz sobre el ■■ Redes de Área de Almacenamiento (SAN) designadas
Protocolo de Internet (VoIP) y de Monitorización Remota para vincular dispositivos de almacenamiento
(RMon). informático, como controladores de conjuntos de
discos y librerías de cinta. Además de los dispositivos
Asimismo, muchas organizaciones contemplan la VoIP y la de almacenamiento, un SAN también necesitará la
telefonía como áreas especializadas y cuentan con equipos gestión de varios componentes de red, como hubs,
dedicados para gestionar esta tecnología. Sus actividades cables, etc.
serán similares a las que se describen mas arriba.
■■ Direct Attached Storage (DAS), que es un dispositivo
de almacenamiento vinculado directamente a un
servidor
 Actividades Comunes de Operación del Servicio | 107

■■ Almacenamiento direccionable por contenido organizaciones, las funciones pueden combinarse o

(CAS), que es un almacenamiento que se basa en vincularse bajo una única estructura de gestión. Entre las
la recuperación de información en función de su opciones organizativas se incluyen:
contenido, en lugar de su ubicación. El enfoque en
■■ Cada equipo de Gestión de Aplicaciones administra
este tipo de sistema se centra en el entendimiento
la base de datos para todas las aplicaciones bajo su
de la naturaleza de los datos y de la información
control
almacenada, en lugar de centrarse en proporcionar
■■ Un departamento dedicado gestiona todas las bases
ubicaciones de almacenamiento específicas.
de datos, independientemente del tipo o aplicación
Independientemente del tipo de sistemas de ■■ Varios departamentos, gestionando cada uno de ellos
almacenamiento que se estén utilizando, Almacenamiento un tipo de base de datos, independientemente de la
y Archivo requerirá la gestión de los componentes de la aplicación a la que pertenezca.
infraestructura, así como las políticas relacionadas con
dónde almacenar los datos, durante cuánto tiempo, en La Administración de Bases de Datos trabaja para asegurar
qué forma y quién puede acceder a los mismos. Las el rendimiento, seguridad y funcionamiento óptimos de
responsabilidades específicas incluirán: las bases de datos que gestionan. Los Administradores de
Bases de Datos tienen las responsabilidades siguientes:
■■ Definición de las políticas y procedimientos de
■■ Creación y mantenimiento de estándares y políticas de
almacenamiento de datos
las bases de datos
■■ Convención de nomenclatura de almacenamiento de
archivos, jerarquía y decisiones de ubicación ■■ Diseño, creación y pruebas iniciales de la base de
datos
■■ Diseño, dimensionamiento, selección,
aprovisionamiento, configuración y operación de toda ■■ Gestión de la disponibilidad y el rendimiento
la infraestructura de almacenamiento de datos de la base de datos; capacidad de recuperación,
dimensionamiento, unidades volumétricas de la
■■ Mantenimiento y soporte de todo el software de
capacidad, etc.
utilidades y el middleware de almacenamiento de
datos ■■ La capacidad de recuperación puede requerir
la duplicación de la base de datos, que sería
■■ Coordinación con los equipos de Gestión del Ciclo
responsabilidad de Administración de Bases de Datos.
de Vida o los equipos de Gobierno para asegurar la
conformidad con las regulaciones sobre libertad de ■■ Administración continua de los objetos de la base de
información, protección de datos y gobierno de TI datos: índices, tablas, vistas, restricciones, instantáneas
de las secuencias y procedimientos almacenados;
■■ Implicación en la definición y acuerdo de la política
bloqueos de página, para conseguir una utilización
de archivo
óptima
■■ Cuidado de todas las instalaciones de almacenamiento
■■ La definición de disparadores que generarán eventos,
■■ Archivado de los datos según las reglas y calendarios
que a su vez alertarán a los administradores de la base
definidos durante Diseño del Servicio. Los equipos
de datos sobre problemas potenciales de rendimiento
o departamentos de Almacenamiento también
o de integridad en la base de datos
proporcionarán información para la definición de estas
■■ Realización del mantenimiento de la base de datos: las
reglas y proporcionarán informes sobre su eficacia
tareas rutinarias que aseguran que las bases de datos
como entrada al futuro diseño
funcionen de forma óptima y segura, por ejemplo,
■■ Recuperación de los datos archivados según se
ajuste, indexación, etc.
necesite (por ejemplo, para auditorías, para pruebas
■■ Monitorización del uso; volúmenes de transacción,
forenses o para satisfacer cualquier otro requisito de
tiempos de respuesta, niveles de concurrencia, etc.
negocio)
■■ Generación de informes. Podría tratarse de informes
■■ Soporte de tercera línea para las incidencias
que se basen en los datos de la base de datos, o de
relacionadas con el almacenamiento y archivo.
informes relacionados con el rendimiento e integridad
de la base de datos
5.7  Administración de Bases de datos ■■ Identificación, generación de informes y gestión de
La Administración de Bases de Datos debe realizarse en los problemas de seguridad de la base de datos;
estrecha colaboración con los equipos o departamentos seguimiento de auditoría y forense
clave de Gestión de Aplicaciones y, en algunas ■■ Asistencia al diseño de backup de la base de datos,
archivo y estrategia de almacenamiento
108 | Actividades Comunes de Operación del Servicio

■■ Asistencia al diseño de alertas de la base de datos y a ■■ Vincular diferentes Servicios de Directorio en toda la
la gestión de eventos organización para formar un Servicio de Directorio
■■ Provisión de soporte de tercer nivel para todas las distribuido, por ejemplo, los usuarios sólo verán un
incidencias relacionadas con la base de datos. conjunto lógico de recursos de red. Esto se denomina
Distribución de Servicios de Directorio
■■ Monitorizar Eventos en los Servicios de Directorio,
5.8  Gestión de Servicios de Directorio
como por ejemplo intentos fallidos para acceder a
Un Servicio de Directorio es una aplicación de software un recurso y adoptar la acción pertinente cuando se
especializada que gestiona información sobre los recursos requiera
disponibles en una red y a la que pueden acceder los ■■ Mantener y actualizar las herramientas que se utilizan
usuarios. Sirve de base para facilitar el acceso a esos para gestionar Servicios de Directorio.
recursos y asegurar que se detecten e impidan los accesos
no autorizados (vea la información detallada sobre Gestión
de Accesos en la sección 4.5). 5.9  Soporte al Puesto de Trabajo
El Servicio de Directorio contempla cada recurso como Debido a que la mayoría de los usuarios acceden a los
un objeto del Servidor de Directorio y le asigna un servicios de TI mediante ordenadores de sobremesa o
nombre. Cada nombre se vincula a la dirección de red del portátiles, es clave que reciban soporte que asegure los
recurso, para que los usuarios no tengan que memorizar niveles de disponibilidad y rendimiento acordados para los
direcciones confusas y complejas. servicios.

Servicio de Directorio se basa en los estándares OSI’s X.500 Soporte al Puesto de Trabajo tendrá la responsabilidad
y normalmente utiliza protocolos como Directory Access general sobre todo el hardware de los ordenadores de
Protocol (DAP) o Lightweight Directory Access Protocol sobremesa y portátiles, el software y los periféricos de la
(LDAP). LDAP sirve para dar soporte a las credenciales organización. Las responsabilidades específicas incluirán:
del usuario para el inicio de sesión de la aplicación y, ■■ Políticas y procedimientos para los puestos de trabajo,
con frecuencia, incluye datos de usuario/cliente interno por ejemplo, políticas de licencias, uso de ordenadores
y externo, lo que resulta especialmente adecuado para portátiles o de sobremesa para fines personales,
el registro de llamada en la extranet. Debido a que LDAP restricción de movimientos de equipos USB, etc.
es una herramienta operativa crítica, y generalmente se ■■ Diseño y acuerdo de imágenes del puesto de trabajo
mantiene actualizada, también es una buena fuente de estándar
datos y verificación para el CMS. ■■ Mantenimiento del servicio al puesto de trabajo,
Gestión de Servicios de Directorio se refiere al proceso incluyendo el despliegue de versiones, actualizaciones,
que se utiliza para gestionar Servicios de Directorio. Sus parches y hotfixes junto con Gestión de Versiones y de
actividades incluyen: la Entrega (consulte información más detallada en la
publicación Transición del Servicio)
■■ Trabajar dentro de Diseño del Servicio y Transición del
■■ Diseño e implementación de la política de archivo/
Servicio para asegurar que los nuevos servicios sean
reconstrucción del puesto de trabajo (incluyendo la
accesibles y estén controlados durante su despliegue
política relacionada con cookies, favoritos, plantillas,
■■ Localizar recursos en una red (si aún no han sido
datos personales, etc.)
definidos durante Diseño del Servicio)
■■ Soporte de tercer nivel para las incidencias
■■ Realizar el seguimiento del estado de esos recursos y
relacionadas con el puesto de trabajo, incluyendo
proporcionar la capacidad para gestionar esos recursos
las visitas en el propio puesto de trabajo cuando sea
de forma remota
necesario
■■ Gestionar los derechos de usuarios o grupos de
■■ Soporte para los problemas de conectividad (junto con
usuarios específicos para acceder a los recursos en una
Gestión de Red) para los teletrabajadores, personal
red
desplazado, etc.
■■ Definir y mantener las convenciones de nomenclatura
■■ Control de la configuración y auditoría de todo los
a utilizar para los recursos en una red
equipos del puesto de trabajo (junto con Gestión de la
■■ Asegurar la consistencia de la nomenclatura y el Configuración y Auditoría de TI).
control de acceso en las diferentes redes de una
organización
 Actividades Comunes de Operación del Servicio | 109

5.10  Gestión del Middleware ■■ Asegurar el funcionamiento correcto del middleware a

través de monitorización y control
Middleware es el software que conecta o integra
■■ Detectar y solucionar Incidencias relacionadas con el
componentes de software entre aplicaciones y
middleware
sistemas distribuidos o dispares. Middleware permite
■■ Mantener y actualizar el middleware, incluyendo
la transferencia eficaz de datos entre aplicaciones y, en
consecuencia, es esencial para los servicios que dependen la concesión de licencias e instalación de nuevas
de múltiples aplicaciones o fuentes de datos. versiones
■■ Definir y mantener información sobre cómo se
Actualmente se emplean diversas tecnologías para dar vinculan las aplicaciones a través del Middleware.
soporte a la comunicación entre programas, como object Esta actividad debería formar parte del CMS (vea la
request brokers (ORB), middleware orientado a mensajes, publicación Transición del Servicio).
llamadas a procedimientos remotos y servicios web
punto a punto. El desarrollo de nuevas tecnologías es
permanente, por ejemplo Enterprise Service Bus (ESB), 5.11  Gestión de Internet / Web
que permite que los programas, sistemas y servicios Muchas organizaciones realizan buena parte de su
se comuniquen entre sí independientemente de la negocio a través de Internet y, por lo tanto, tienen una
arquitectura y origen de las aplicaciones. Esta tecnología gran dependencia de la disponibilidad y rendimiento
se emplea especialmente en el contexto del despliegue de de sus sitios web. En tales casos, será deseable y estará
Arquitecturas Orientadas a Servicios (SOA). justificado asignar un equipo o departamento de Soporte
Gestión del Middleware puede ser realizada dentro de la de Internet / Web con rol independiente.
Función de Gestión de Aplicaciones (cuando se dedique Las responsabilidades de este equipo o departamento
a una aplicación específica) o dentro de una Función incluyen la Intranet e Internet y, probablemente, incluirán:
de Gestión Técnica (cuando se contemple como una
ampliación del Sistema Operativo de una plataforma ■■ Definir arquitecturas para Internet y los servicios web
específica). ■■ La especificación de estándares para el desarrollo y
gestión de aplicaciones basadas en la web, contenido,
La funcionalidad provista por el middleware incluye: sitios web y páginas web. Esto normalmente se
■■ Proveer mecanismos de transferencia para los datos de realizará durante el Diseño del Servicio
diversas aplicaciones o fuentes de datos ■■ Diseño, pruebas, implementación y mantenimiento de
■■ Enviar trabajo a otra aplicación o procedimiento para sitios web. Esto incluirá la arquitectura de sitios web y
su procesamiento la indicación del contenido que estará disponible
■■ Transmitir datos o información a otros sistemas, como ■■ En muchas organizaciones, la gestión web incluirá la
por ejemplo suministrar datos para su publicación en edición del contenido a publicar en la web
sitios web (por ejemplo, información del estado de las ■■ Mantenimiento de todas las aplicaciones de desarrollo
incidencias) y gestión
■■ Entregar módulos de software actualizados en ■■ Coordinación de, y asesoramiento a, los equipos de
entornos distribuidos contenido web del negocio. El contenido puede residir
■■ Cotejo y distribución de mensajes e instrucciones del en aplicaciones o dispositivos de almacenamiento,
sistema, por ejemplo, Eventos y scripts operativos que lo que implica una estrecha relación con Gestión de
se deben ejecutar en dispositivos remotos Aplicaciones y otros equipos de Gestión Técnica.
■■ Configuración multidifusión con redes. Multidifusión es ■■ Coordinación y gestión de suministradores de ISP,
el suministro simultáneo de información a un grupo hosts, monitorización de suministradores externos
de destinos utilizando la ruta de entrega más eficiente u organizaciones de virtualización, etc. En muchas
■■ Gestionar tamaños de colas. organizaciones los ISP se gestionan dentro de Gestión
de Red.
Gestión del Middleware es el conjunto de actividades que
■■ Soporte de tercer nivel para las incidencias
se usan para gestionar middleware. Entre éstas se incluye:
relacionadas con Internet o la web
■■ Trabajar dentro de Diseño del Servicio y Transición del ■■ Soporte de interfaces con back-end y sistemas
Servicio para asegurar que se elijan las soluciones de heredados. Esto con frecuencia implicará colaborar
middleware adecuadas y que puedan funcionar de con miembros de los equipos de Desarrollo de
forma óptima al desplegarlas
110 | Actividades Comunes de Operación del Servicio

Aplicaciones y Gestión para asegurar el acceso seguro ■■ Acondicionamiento del Entorno y Sistemas de
y la consistencia de la funcionalidad Alerta, que incluyen la especificación, mantenimiento
■■ Monitorización y gestión del rendimiento del sitio y monitorización de sistemas de detección de humos
web, incluyendo: prueba de señal de red, simulación y extinción de incendios, agua, sistemas de calefacción
de la experiencia de usuario, benchmarking, equilibrio y aire acondicionado, etc.
de la carga bajo demanda, virtualización ■■ Seguridad se encarga de la conformidad con toda la
■■ Disponibilidad del sitio web, capacidad de legislación, estándares y políticas relacionados con la
recuperación y seguridad. Esta actividad formará seguridad de los empleados
parte de la Gestión de la Seguridad de la Información ■■ Control de Accesos Físicos se refiere a garantizar
general de la organización. que sólo acceda a la instalación el personal autorizado
y que se detecte y gestione cualquier acceso no
autorizado. Esto se analiza con más detalle en el
5.12  Gestión de las Instalaciones y
Apéndice F
del Centro de Proceso de Datos
■■ Envío y Recepción se refiere a la gestión de todos los
Gestión de las Instalaciones hace referencia a la gestión equipos, mobiliario, correo, etc. que entren o salgan
del entorno físico de las Operaciones de TI, normalmente del edificio. Asegura que sólo entren o salgan del
ubicada en Centros de Proceso de Datos o salas de edificio los elementos pertinentes y que se encaminen
ordenadores. Este es un campo amplio y complejo y a la parte correcta
esta publicación proporcionará una descripción general ■■ Implicación en Gestión de Contratos de los diversos
de su rol y actividades clave. El Apéndice E incluye una suministradores y proveedores de servicio involucrados
descripción general más detallada. en la instalación
En muchos aspectos, Gestión de las Instalaciones podría ■■ Mantenimiento se refiere a la conservación regular y
contemplarse como una función de pleno derecho. Sin planificada de la instalación, así como a la detección y
embargo, debido a que esta publicación se centra en resolución de problemas en la instalación.
dónde se alojan las Operaciones de TI, cubrirá Gestión
de las Instalaciones de forma específica en cuanto a su Nota importante en relación con los Centros de
relación con la gestión de Centros de Proceso de Datos Proceso de Datos
y como un subconjunto de la función de Gestión de Los Centros de Proceso de Datos son instalaciones
Operaciones. generalmente especializadas y, aunque usan y se
Los componentes principales de Gestión de las benefician de las disciplinas genéricas de Gestión de
Instalaciones son las siguientes: las Instalaciones, necesitarán adaptar estas últimas.
Por ejemplo, la distribución, la calefacción y aire
■■ Gestión de Edificios, que se refiere al mantenimiento acondicionado, la planificación de la energía y muchos
y conservación de los edificios que albergan al otros aspectos se gestionan de forma exclusiva en los
personal de TI y al Centro de Proceso de Datos (CPD). Centros de Proceso de Datos.
Las actividades típicas incluyen la limpieza, eliminación
de residuos, gestión de estacionamientos y control de Esto quiere decir que, aunque los Centros de Proceso
accesos. de Datos pueden ser instalaciones que pertenecen a
■■ Hosting de Equipos, asegura que se provean todos
una organización, se gestionan mejor bajo la autoridad
de Operaciones de TI, aunque puede existir una línea
los requisitos especiales para el alojamiento físico de
de información funcional entre TI y el departamento
los equipos hardware y los equipos de personas que
que gestiona otras instalaciones para la organización.
los respaldan
■■ Gestión de la Energía, que se refiere a la gestión
del suministro y uso de fuentes de alimentación 5.12.1  Estrategias del Centro de
que se utilizan para mantener la instalación en Procesamiento de Datos
funcionamiento. Esta definición de Gestión de la
La gestión de un Centro de Proceso de Datos implica
Energía tiene diversas implicaciones que se comentan
mucho más que alojar un espacio abierto en el que
en el Apéndice E. Tenga en cuenta que esta
grupos técnicos instalan y gestionan equipos, aplicando
información sobre el uso de la energía es importante
sus propias metodologías y procedimientos. Requiere un
para la planificación de la capacidad de los nuevos
conjunto integrado de procesos y procedimientos que
servicios y edificios.
implican a todos los grupos de TI en cada etapa del Ciclo
 Actividades Comunes de Operación del Servicio | 111

de Vida de ITSM. Las operaciones del Centro de Proceso La monitorización, control y gestión remota de los
de Datos se rigen por decisiones estratégicas y de diseño equipos y sistemas será esencial para gestionar un
para la gestión y control que ejecutan los operadores. Esto entorno virtual, debido a que muchos servicios no se
requiere contar con diversos factores clave: vincularán a ninguna parte específica del equipo.
■■ Automatización del Centro de Procesamiento de ■■ Los Sistemas de gestión unificados se han vuelto
Datos. Sistemas de automatización especializados que más importantes a medida que los servicios se
reducen la necesidad de operadores manuales y que ejecutan en múltiples ubicaciones y tecnologías.
monitorizan y realizan el seguimiento de la instalación Actualmente, es importante definir qué acciones son
y de todas las operaciones de TI en todo momento necesarias realizar y qué sistemas realizarán esas
■■ Gestión basada en políticas, en la que las reglas de acciones. Esto implica invertir en soluciones que
automatización y asignación de recursos se gestionan permitirán que los Gestores de la infraestructura
mediante las políticas definidas, en lugar de tener que especifiquen de forma sencilla qué salida se requiere,
realizar procedimientos complejos de cambio cada vez permitiendo que el sistema de gestión calcule la mejor
que el procesamiento pase de un recurso a otro combinación de herramientas y acciones para alcanzar
■■ Servicios en tiempo real 24 horas al día, 7 días a la tal salida.
semana
■■ Estandarización de equipos. Proporciona una mayor 5.13  Gestión de la Seguridad de la
facilidad en la gestión, niveles más consistentes de Información y Operación del Servicio
rendimiento y un medio que facilita múltiples servicios
a través de una tecnología similar. La estandarización El proceso de Gestión de la Seguridad de la Información
también reduce la variedad de experiencia técnica se cubre en la publicación Diseño del Servicio de
requerida para gestionar equipos en el Centro de ITIL. Gestión de la Seguridad de la Información tiene
Procesamiento de Datos y proporcionar servicios la responsabilidad general de establecer políticas,
■■ SOAs, en los que pueden reutilizarse, intercambiarse estándares y procedimientos que aseguren la protección
y sustituirse los componentes del servicio muy de los activos, datos, información y servicios de TI de
rápidamente y sin afectar al negocio. Esto permitirá la organización. Los equipos de Operación del Servicio
que el Centro de Procesamiento de Datos tenga desempeñan un rol en la ejecución de estas políticas,
una buena capacidad de respuesta para satisfacer estándares y procedimientos, y trabajarán estrechamente
las exigencias cambiantes del negocio sin tener que con los equipos y departamentos responsables de la
perder tiempo en realizar una nueva ingeniería y Gestión de la Seguridad de la Información.
arquitectura Los equipos de Operación del Servicio no pueden asumir
■■ Virtualización. Esto quiere decir que los Servicios de la responsabilidad de la Gestión de la Seguridad de la
TI se proveen mediante un conjunto de equipos en Información, dado que esta situación representaría un
evolución constante, dirigidos a satisfacer la demanda conflicto. Es necesario que exista una separación de roles
actual. Por ejemplo, una aplicación puede ejecutarse entre los grupos que definen y gestionan el proceso y los
en un dispositivo dedicado junto con su base de grupos que ejecutan las actividades específicas como parte
datos durante los periodos de demanda elevada, de la operación continua. Esto contribuirá a la protección
pero cambiar a un dispositivo compartido con su frente a los incumplimientos de las medidas de seguridad,
base de datos en un dispositivo remoto durante debido a que ninguna persona en forma individual
los periodos valle de uso de forma automatizada y debería tener el control sobre dos o más fases de una
automática. Esto implicará ahorros de costes aún transacción u operación. Gestión de la seguridad de la
mayores debido a que se puede usar cualquier equipo información asignaría las responsabilidades para asegurar
en cualquier momento, sin ninguna intervención una comprobación cruzada de las obligaciones.
humana, salvo para realizar el mantenimiento y A continuación se describe el rol de los equipos de
sustitución de los equipos que presenten fallos. La Operación del Servicio.
infraestructura de TI tiene una mayor capacidad de
recuperación debido a que cualquier componente está
5.13.1  Elaboración de políticas e informes
respaldado por cualquier número de componentes
similares, cualquiera de los cuales podría asumir Involucrará al personal de Operación que realiza
automáticamente la carga de trabajo del componente actividades de elaboración de políticas específicas,
fallido. como la comprobación de los registros electrónicos de
datos del sistema, alertas de eventos/monitorización,
112 | Actividades Comunes de Operación del Servicio

detección de intrusiones y/o elaboración de informes de el personal. Cuando el personal de los suministradores
incumplimientos de la seguridad reales o potenciales. externos o los visitantes necesiten tener acceso, es posible
Esto se realiza junto con Gestión de la Seguridad que el personal de Operación del Servicio sea responsable
de la Información para proporcionar un sistema de de acompañar y gestionar el movimiento de ese personal.
comprobación y equilibrio que asegure la detección y
Si existen accesos privilegiados a sistemas, es necesario
gestión eficaz de los problemas de seguridad.
restringirlos únicamente a aquellas personas para las
El personal de Operación del Servicio es con frecuencia que se haya verificado la necesidad de dichos accesos
el primero en detectar los eventos de seguridad, y retirarlos inmediatamente cuando deje de existir tal
y se encuentra en la mejor posición para detener necesidad. Debe mantenerse un seguimiento de auditoría
temporalmente y/o impedir el acceso a los sistemas de las personas que hayan tenido acceso y cuándo, y de
comprometidos. todas las actividades realizadas empleando esos niveles de
acceso.
Se necesitará poner una atención particular si se requiere
que organizaciones externas accedan físicamente al
interior de la organización. El personal de Operación del
5.13.4  Filtrado y examen
Servicio tendrá que acompañar a los visitantes hasta el Todo el personal de Operación del Servicio debería ser
interior de las áreas sensibles y/o controlar su acceso. examinado y controlado hasta un nivel de seguridad
adecuado para la organización en cuestión.
También desempeñarán un rol en el control del acceso
de terceros, como, por ejemplo, el registro y control Los suministradores y contratistas externos también
de entrada de los encargados del mantenimiento del deberían ser filtrados y examinados, tanto las
hardware para realizar diagnósticos, etc. organizaciones como el personal específico involucrado.
Muchas organizaciones han comenzado a utilizar las
5.13.2  Asistencia técnica comprobaciones de antecedentes policiales o de agencias
gubernamentales, especialmente cuando los contratistas
Puede que sea necesario proporcionar cierto soporte
van a trabajar con sistemas clasificados. Cuando sea
técnico al personal de Seguridad de TI para ayudar a la
necesario, deben establecerse los acuerdos pertinentes de
investigación de las incidencias de seguridad y contribuir
no divulgación y confidencialidad.
a la elaboración de informes o recopilar pruebas delictivas
para utilizarlas en acciones disciplinarias o juicios
criminales.
5.13.5  Formación y concienciación
Todo el personal de Operación del Servicio recibirá
También es posible que se requiera asesoramiento y formación y concienciación regular y continua sobre
asistencia técnica en relación con las mejoras potenciales la política y los procedimientos de seguridad de la
de la seguridad (por ejemplo, configurar firewalls organización. Deberían incluir información detallada
adecuados o controles de acceso/por contraseña). de las medidas disciplinarias en vigor. Además, debería
Se puede confiar en el uso de información de la gestión especificarse cualquier requisito de seguridad en el
de eventos, incidencias, problemas y de la configuración contrato de empleo del empleado.
para proporcionar cronologías precisas de las
investigaciones relacionadas con respecto a la seguridad. 5.13.6  Políticas y procedimientos
documentados
5.13.3  Control de la seguridad operativa Los procedimientos de Operación del Servicio
Por razones operativas, a menudo el personal técnico documentados deben incluir toda la información
necesitará contar con privilegios de acceso a áreas pertinente relacionada con los problemas de seguridad,
técnicas clave (por ejemplo, contraseñas del sistema extraídos de los documentos de la política de seguridad
raíz, acceso físico a Centros de Proceso de Datos o general de la organización. Se debe tener en cuenta el uso
salas de comunicaciones, etc.) Por lo tanto, es vital que de manuales que ayuden a comunicar los mensajes de
se mantengan controles y seguimientos de auditoría seguridad al personal correspondiente.
adecuados para todas las actividades que cuenten con
privilegios para evitar y detectar cualquier evento de
seguridad.
Es necesario que existan controles físicos para todas las
áreas seguras, con registros de entrada y salida de todo
 Actividades Comunes de Operación del Servicio | 113

5.14  Mejora de las actividades 5.14.5  Comunicación

operativas No es necesario comentar que Operación del Servicio
Todo el personal de Operación del Servicio debería mejorará con una buena comunicación sobre los
buscar continuamente áreas en las que se puedan realizar cambios de los requisitos, la tecnología y los procesos.
mejoras en los procesos para conseguir una mayor calidad Sin embargo, a menudo se descuida la comunicación.
en el servicio de TI y/o desempeñarlas de una forma más La mejora de Operación del Servicio depende de
rentable. Esto podría incluir algunas de las actividades la comunicación formal y regular entre los equipos
siguientes. responsables del diseño, soporte y operación de los
servicios.
5.14.1  Automatización de las tareas
5.14.6  Educación y formación
manuales
Los equipos de Operación del Servicio deberían entender
Es probable que las tareas que tengan que ser realizadas
la importancia de sus actividades diarias. Se requiere una
manualmente, particularmente aquellas que se tengan que
educación que asegure que el personal entienda qué
repetir regularmente, consuman más tiempo, coste, y sean
funciones o servicios de negocio soportan sus actividades.
más proclives a los errores que aquellas que se realicen
Esto fomentará un mayor cuidado o atención al detalle y
de forma sistemática y automatizada. Debería analizarse
también ayudará a los equipos de Operación del Servicio a
el potencial de automatización de todas las tareas para
identificar mejor las prioridades del negocio.
reducir el esfuerzo y los costes y minimizar los errores
potenciales. Los programas de formación deberían asegurar que todo
el personal cuente con las habilidades necesarias para la
Deben evaluarse los costes de la automatización y los
tecnología o aplicaciones que gestionan. Debe impartirse
beneficios probables que proporcionará.
formación cada vez que se introduzca nueva tecnología, o
cuando se cambie la tecnología existente.
5.14.2 Revisión de actividades o
procedimientos provisionales
Debido a la naturaleza pragmática de Operación del
Servicio, en ocasiones puede ocurrir que se introduzcan
actividades o procesos provisionales para abordar las
urgencias operativas a corto plazo. Existe el riesgo de que
tales prácticas puedan continuar y se conviertan en la
‘norma’, y lleguen a crear ineficiencias continuas. Cuando
sea necesario introducir alguna actividad o procedimiento
provisional, es importante que sea revisada tan pronto
como se supere la urgencia inmediata, y sea eliminada o
sustituida por procesos eficaces acordados para el largo
plazo.

5.14.3  Auditorías operativas

Deberían realizarse auditorías regulares de todos los
procesos de Operación del Servicio para garantizar que
estén funcionando satisfactoriamente.

5.14.4 Uso de Gestión de Incidencias y

Problemas
Gestión de Incidencias y Problemas proporciona una
rica fuente de oportunidades de mejora operativa. Estos
procesos se comentan en detalle en el Capítulo 4 de esta
publicación.
 Organización de la
Operación del Servicio 6
 | 117

6 Organización de la Operación del Servicio

6.1  Funciones Las funciones de Operación del Servicio que se presentan

en la Figura 6.1 son necesarias para gestionar el ’estado
Una función es un concepto lógico que hace referencia a
continuo’ del entorno operativo de TI. Son funciones
las personas y a las medidas automatizadas que ejecutan
lógicas que no tienen que ser realizadas necesariamente
un proceso definido, una actividad o una combinación
por una estructura organizativa equivalente. Esto quiere
de procesos o actividades. En organizaciones grandes,
decir que Gestión Técnica y de Aplicaciones puede
una función podría dividirse y ser realizada por varios
organizarse en cualquier combinación y en cualquier
departamentos, equipos y grupos, o podría estar a cargo
número de departamentos. Los agrupamientos de
de una única unidad organizativa.
Gestión de Operaciones de TI

Control de
Centro de Servicio Gestión Operaciones de TI Gestión de
al Usuario Técnica Aplicaciones
Gestión de Consolas
Programación del
trabajo
Backup y Restauración Aplicac.
Mainframe Impresión y Salida Financieras

Gestión de Instalaciones Aplicac.

Servidor
RR.HH.
Centros de Datos
Sitios de Recuperación
Consolidación
Contratos Aplicac. de
Red
Negocio

Almacena-
miento

Base de
Datos

Servicios
de
Directorio

Escritorio

Middleware

Internet/Web
Figura 6.1 Funciones de
Operación del Servicio
118 | Organización de la Operación del Servicio

segundo nivel que se muestran en la Figura 6.1 son En algunas organizaciones, esto se corresponde con
ejemplos de grupos típicos de actividades que realiza un departamento centralizado y único, mientras que
Gestión Técnica (vea el Capítulo 5) y no representan una en otras, algunas actividades y personal se centralizan
sugerencia de estructura organizativa. o se suministran a través de departamentos
distribuidos o especializados. Este hecho se ilustra
A continuación se ofrece una descripción general de las
en la Figura 6.1 mediante el solapamiento de las
funciones de Operación del Servicio que se muestran en la
funciones de Gestión Técnica y de Aplicaciones.
Figura 6.1:
Gestión de Operaciones de TI tiene dos funciones
■■ El Centro de Servicio al Usuario es el punto que son únicas y que generalmente son estructuras
principal de contacto para los usuarios cuando se organizativas formales. Éstas son:
produce una interrupción del servicio, para peticiones ●● Control de Operaciones de TI, que generalmente
de servicios, o incluso para algunas categorías de está atendido por turnos de operadores y
Solicitudes de Cambio. El Centro de Servicio al Usuario que garantiza que se lleven a cabo las tareas
proporciona un punto de comunicación para los operativas rutinarias. Control de Operaciones de
usuarios y un punto de coordinación para múltiples TI también proveerá actividades centralizadas de
procesos y grupos de TI. Normalmente, el Centro de monitorización y control, normalmente usando
Servicio al Usuario es una función independiente del un Puente de Operaciones o un Centro de
resto de funciones de Operación del Servicio, para Operaciones de Red.
que pueda realizar sus acciones de forma eficaz. En ●● Gestión de las Instalaciones hace referencia a
algunos casos, por ejemplo cuando se ofrece soporte la gestión del entorno físico de TI, normalmente
técnico a usuarios en la primera llamada, puede ser Centros de Procesamiento de Datos o salas
necesario que haya personal de Gestión Técnica y de de ordenadores. En muchas organizaciones,
Aplicaciones en el Centro de Servicio al Usuario. Esto Gestión de Aplicaciones y Gestión Técnica se
no implica que el Centro de Servicio al Usuario forme ubican junto con Operaciones de TI en grandes
parte de la función de Gestión Técnica. De hecho, Centros de Procesamiento de Datos. En algunas
mientras se encuentren en el Centro de Servicio organizaciones, muchos componentes físicos de
al Usuario, dejarán de pertenecer a las funciones la infraestructura de TI han sido externalizados
de Gestión Técnica o de Gestión de Aplicaciones y Gestión de las Instalaciones puede incluir la
y formarán parte del Centro de Servicio al Usuario, gestión de los contratos de externalización.
incluso si sólo se tratara de una situación temporal.
■■ Gestión de Aplicaciones será responsable de
■■ Gestión Técnica proporciona habilidades técnicas
gestionar Aplicaciones a lo largo de su ciclo de
detalladas y recursos necesarios para apoyar la vida. La función de Gestión de Aplicaciones soporta
operación continua de la Infraestructura de TI. Gestión y mantiene aplicaciones operativas y también
Técnica también desempeña un rol importante en desempeña un rol importante en el diseño, prueba
el diseño, prueba, provisión y mejora de servicios de y mejora de las aplicaciones que forman parte de
TI. En organizaciones pequeñas, es posible que esta los servicios de TI. Gestión de Aplicaciones se divide
experiencia se gestione en un único departamento, normalmente en departamentos que se basan en
pero en organizaciones mayores, normalmente se el portfolio de aplicaciones de la organización (vea
divide entre varios departamentos especializados los ejemplos en la Figura 6.1), por lo que se facilita
técnicamente. En muchas organizaciones, los la especialización y un soporte más enfocado. En
departamentos de Gestión Técnica también son muchas organizaciones, los departamentos de
responsables de la operación diaria de un subconjunto Gestión de Aplicaciones tienen personal que realiza
de la infraestructura de TI. La Figura 6.1 muestra que, operaciones diarias para esas aplicaciones. Al igual
aunque forma parte de un departamento de Gestión que en el caso de Gestión Técnica, este personal se
Técnica, el personal que realiza estas actividades se integrará lógicamente en la función de Gestión de
integran lógicamente en la función de Gestión de Operaciones de TI.
Operaciones.
■■ Gestión de Operaciones de TI es la función que se
responsabiliza de las actividades operativas diarias
necesarias para gestionar la Infraestructura de TI.
Esto se realiza de conformidad con los Estándares de
Rendimiento definidos durante el Diseño del Servicio.
 Organización de la Operación del Servicio | 119

■■ La complejidad de la tecnología que se utiliza en

Nota especial sobre Gestión de la Seguridad de la
la organización. Cuanto mayor sea el número de
Información
tecnologías diferentes empleadas, más probable será
Aunque muchos estarán de acuerdo en que Gestión que existan varios equipos diferentes que realicen
de la Seguridad de la Información es una función, tareas similares, aunque en un entorno diferente (por
está muy especializada y abarca varias fases del ciclo ejemplo, Gestión de Servidores UNIX y Gestión de
de vida. También es responsable de la supervisión Servidores Windows).
de muchas actividades dentro de todas las funciones
■■ La disponibilidad de habilidades. Cuando las
de Operación del Servicio. Si desea una descripción
habilidades técnicas son escasas, es habitual que
detallada sobre Gestión de la Seguridad de la
las organizaciones utilicen técnicos para realizar
Información, consulte la publicación Diseño del
múltiples grupos de actividades aunque, en algunos
Servicio y la sección 5.13 de esta publicación.
casos, las consideraciones de seguridad lo dificultan
bastante. Por ejemplo, una organización que trabaje
6.1.1  Funciones y actividades en proyectos clasificados o secretos puede tener la
El Capítulo 5 de esta publicación presenta diversas necesidad de contratar recursos experimentados y
actividades comunes de Operación del Servicio. Debido especializados incluso cuando eso implique reubicarlos
a la naturaleza técnica y a la especialización de estas o contratarlos a través de proveedores que cuenten
actividades, los equipos, grupos o departamentos que con la aprobación de seguridad.
las realizan tienen, con frecuencia, nombres que se ■■ La cultura de la organización. Algunas organizaciones
corresponden con las actividades particulares. Por ejemplo, prefieren trabajar en entornos altamente
Gestión de Red podría ser realizada por un ’Departamento especializados, mientras que otras prefieren la
de Gestión de Red’. Esto, no obstante, no representa flexibilidad de contar con personal con habilidades
una norma. Existen diversas opciones para correlacionar generales.
actividades con un equipo o departamento, por ejemplo: ■■ La situación financiera de la organización determinará
■■ Una actividad podría ser realizada por varios equipos cuántas personas, y con qué tipo de habilidades,
o departamentos, por ejemplo, si una organización pueden ser empleadas y cómo se organizarán.
tiene cinco departamentos principales de Soporte Como resultado de estos factores, es imposible que
de Aplicaciones para apoyar cada uno de ellos a un esta publicación prescriba una estructura organizativa
conjunto diferente de aplicaciones, cada departamento adecuada que se adapte a cada situación, no obstante,
podría realizar Administración de Bases de Datos para las siguientes secciones indican las actividades necesarias
’sus’ aplicaciones. bajo los grupos funcionales que con mayor probabilidad
■■ Un departamento podría realizar varias actividades, participarán en su operación. Tenga en cuenta que esto
por ejemplo, el Departamento de Gestión de Red no significa que todas las organizaciones tengan que
podría ser responsable de la gestión de la red, Gestión usar estas divisiones. Las organizaciones más pequeñas
de Servicios de Directorio y Gestión de Servidores. tenderán a asignar grupos de estas actividades (si fueran
■■ Una actividad podría ser realizada por grupos, por necesarias) a un único departamento, o incluso a una
ejemplo, Administración de la Seguridad puede ser persona individual, si llega a ser necesario.
realizada por cualquier persona que sea responsable
de la gestión de una aplicación, servidor, middleware
o puesto de trabajo.
Estas decisiones organizativas están influenciadas por
diversos factores, como por ejemplo:
■■ El tamaño y ubicación de la organización. Las
organizaciones más pequeñas y menos distribuidas
tenderán a combinar estas funciones, mientras que
las organizaciones descentralizadas pueden tener
varios equipos o departamentos para realizar la misma
actividad (por ejemplo, por región).
120 | Organización de la Operación del Servicio

El Centro de Servicio al Usuario tiene una importancia vital

Nota especial sobre la externalización
en el Departamento de TI de una organización y debería
Es probable que estas consideraciones organizativas ser el punto único de contacto diario para los usuarios de
sean más pertinentes para las organizaciones de TI TI; y tratará todas las incidencias y peticiones de servicio,
internas. La situación se complica aún más cuando utilizando habitualmente herramientas de software
se externalizan algunas o todas las actividades o especializado para registrar y gestionar todos esos eventos.
funciones. Las oportunidades de externalización
El valor de un Centro de Servicio al Usuario eficaz no
principales han sido el Centro de Servicio al Usuario
debería ser subestimado. A menudo, un buen Centro de
y Operaciones de Red. Esto se tratará con mayor
Servicio al Usuario puede compensar las deficiencias en
detalle en la Guía Complementaria de ITIL, aunque a
otros puntos de la organización de TI; pero un Centro de
continuación se recuerdan algunos de los puntos clave:
Servicio al Usuario deficiente (o la falta de un Centro de
■■ Independientemente de quién esté realizando Servicio al Usuario) puede ofrecer una mala impresión de
la actividad, la compañía que contrate al una organización de TI eficaz.
subcontratista continúa siendo responsable de
Por lo tanto, es muy importante que se utilice personal
asegurar que la actividad se realice hasta un nivel
con la preparación adecuada en el Centro de Servicio al
que permita la provisión de servicios a sus clientes
Usuario y que los Gestores de TI hagan todo lo posible
y usuarios.
para que el centro sea un lugar atractivo en el que trabajar
■■ La externalización como solución a los problemas y de esa forma mejorar la retención del personal.
de una organización o como una alternativa a los
procesos de Gestión del Servicio rara vez funciona. La naturaleza, tipo, tamaño y ubicación exacta de un
Los mejores resultados se consiguen si los procesos Centro de Servicio al Usuario diferirán en función del tipo
ya están en vigor antes de la externalización. de negocio, número de usuarios, geografía, complejidad
■■ La externalización ofrece los mejores resultados de las llamadas, ámbito de los servicios y muchos otros
cuando ambas organizaciones -Cliente y Proveedor- factores.
se implican activamente. Si el personal y los Alineados con los requisitos del cliente y del negocio,
gestores del cliente se desvinculan, es improbable los gestores senior de la organización de TI deberían
que el subcontratista tenga éxito, sencillamente determinar la naturaleza del Centro de Servicio al Usuario
debido a que nadie entiende la organización mejor que se requiere (y si debería ser interno o externalizado)
que las personas que trabajan en ella. como parte de su estrategia de ITSM general (vea la
■■ El subcontratista no debería determinar sus publicación de Estrategia del Servicio) y, a continuación,
resultados o la manera de cómo deberían debe realizarse la planificación subsiguiente para preparar
medirse. Estos resultados se identifican mediante e implementar la función del Centro de Servicio al Usuario
el entendimiento de los requisitos de negocio de pertinente (bien al implementar una nueva función o,
los usuarios y clientes, y asegurándose de que las cuando, probablemente en la mayoría de los casos, deban
capacidades del subcontratista puedan cumplirlos. realizarse mejoras en una función existente; consulte las
■■ Aunque los servicios del subcontratista sean publicaciones Diseño del Servicio y Transición del Servicio).
una parte integral de la organización, continúa
siendo una organización externa, con un conjunto 6.2.1  Justificación y rol del Centro de
diferente de objetivos, políticas y prácticas Servicio al Usuario
de negocio. Deben mantenerse estándares En la actualidad no es necesario justificar la necesidad
de seguridad y ambas partes deben entender de un Centro de Servicio al Usuario, debido a que
claramente sus respectivos roles y contribuciones. muchas organizaciones ya se han convencido de que
éste es, con diferencia, el mejor método para abordar los
6.2  Centro de Servicio al Usuario problemas de soporte de primera línea de TI. Sólo hay que
Un Centro de Servicio al Usuario es una unidad funcional preguntarse ’¿Cuál es la alternativa?’ para presentar una
compuesta por un número dedicado de personal causa convincente para el concepto del Centro de Servicio
responsable de tratar diversos eventos del servicio, a al Usuario. Deberían tenerse en cuenta los siguientes
través de llamadas telefónicas, interfaz web o eventos de beneficios cuando se requieran justificaciones adicionales:
infraestructura sobre los que se informa automáticamente. ■■ Mejora del servicio, de la percepción y de la
satisfacción del cliente
 Organización de la Operación del Servicio | 121

■■ Incremento de la accesibilidad a través de un punto ■■ Resolución de las incidencias/peticiones de servicio

único de contacto, comunicación e información que puedan solucionar
■■ Mejor calidad y capacidad de respuesta más rápida a ■■ Escalado de las incidencias/peticiones de servicio que
las peticiones del cliente o usuario no puedan resolver dentro de los plazos de tiempo
■■ Mejora del trabajo en equipo y de la comunicación acordados
■■ Mejora del enfoque y puesta en marcha de una ■■ Mantener a los usuarios informados del progreso
metodología proactiva para la provisión del servicio ■■ Cierre de todas las incidencias resueltas, peticiones y
■■ Un reducido impacto negativo sobre el negocio otras llamadas
■■ Mejora de la gestión y control de la infraestructura ■■ Realización de las devoluciones de llamadas/encuestas
■■ Mejora del uso de los recursos de Soporte de TI y de satisfacción del cliente/usuario acordadas
mejora de la productividad del personal de negocio ■■ Comunicación con los usuarios, manteniéndoles
■■ Información de gestión más significativa para apoyar informados sobre el progreso de las incidencias,
la toma de decisiones notificándoles los cambios inminentes o las
■■ Es una práctica habitual que el Centro de Servicio interrupciones del servicio acordadas, etc.
al Usuario provea puestos de ’nivel básico’ para el ■■ Actualización del CMS, si se acuerda, bajo la dirección
personal de ITSM. Trabajar en el Centro de Servicio y aprobación de Gestión de la Configuración.
al Usuario es una base excelente para cualquiera que Nota: estas actividades se explican y se ponen en contexto
desee continuar una carrera profesional en Gestión con el proceso completo de Gestión de Incidencias
del Servicio. No obstante, esto también podría y Gestión de Peticiones en las secciones 4.2 y 4.3,
presentar desafíos si se cuenta con personas que no respectivamente.
entiendan el negocio o la tecnología. Los usuarios
que llamen al Centro de Servicio al Usuario deberían 6.2.3 Estructura organizativa del Centro de
poder hablar con alguien que sea capaz de abordar
Servicio al Usuario
sus necesidades, y los Analistas del Centro de Servicio
al Usuario no deberían ’quemarse’ en menos de un Existen diversas alternativas para estructurar y localizar
año debido a una tensión laboral indebida. Debería los Centros de Servicio al Usuario. La solución correcta
seleccionarse cuidadosamente a los profesionales para diferirá dependiendo de cada organización. Las opciones
que cuenten con las habilidades adecuadas y con un principales se detallan más abajo aunque, en realidad, una
buen entendimiento del negocio, y proporcionarles organización puede necesitar implementar una estructura
la formación adecuada, lo que impedirá la reducción que combine varias de estas opciones para satisfacer
de los niveles de soporte debido a la falta de enteramente las necesidades del negocio:
conocimiento en la primera línea.
6.2.3.1  Centro de Servicio al Usuario Local
6.2.2 Objetivos del Centro de Servicio al Cuando un centro de servicio se ubica dentro, o
Usuario físicamente cerca, de la comunidad de usuarios a la que
sirve. Esto favorece con frecuencia la comunicación y
El objetivo fundamental del Centro de Servicio al
proporciona una presencia claramente visible que puede
Usuario es restaurar el ’servicio normal’ a los usuarios tan
gustar a algunos clientes, pero que a menudo puede ser
pronto como sea posible. En este contexto, hablamos
ineficiente y cara debido a que el personal se encuentra
de ’restauración del servicio’ en el sentido más amplio
inmovilizado a la espera de tratar las incidencias cuando el
posible. Aunque esto podría involucrar la solución de un
volumen y la tasa de llegada de llamadas no justifique su
fallo técnico, también podría incluir el cumplimiento de
presencia.
una petición de servicio o la respuesta a una consulta,
cualquier cosa que sea necesaria para permitir que los No obstante, puede haber algunas razones válidas para
usuarios vuelvan a trabajar satisfactoriamente. mantener un centro de servicio local, incluso cuando el
volumen de llamadas por sí mismo no justifique hacerlo.
Las responsabilidades específicas incluirán:
Entre las razones se podrían incluir:
■■ Registro de todos los detalles importantes de la
■■ Diferencias de idioma, culturales o políticas
incidencia/petición de servicio, asignando códigos de
■■ Diferentes zonas horarias
categorización y priorización
■■ Grupos especializados de usuarios
■■ Provisión de investigación y diagnóstico de primera
línea
122 | Organización de la Operación del Servicio

■■ La existencia de servicios personalizados o externalización, o cualquier combinación que se requiera

especializados que requieran el conocimiento de para satisfacer la demanda de los usuarios. No obstante, es
especialistas importante tener en cuenta que se requieren salvaguardas
■■ Condición de VIP o de criticidad de los usuarios. en todas estas circunstancias para asegurar la consistencia
y uniformidad en términos culturales y de calidad de
6.2.3.2  Centro de Servicio al Usuario servicio.
Centralizado
6.2.3.4  Soporte “Siguiendo al ol”
Es posible reducir el número de Centros de Servicio al
Usuario fusionándolos en una única ubicación (o en un Algunas organizaciones globales o internacionales
número inferior de ubicaciones) concentrando al personal pueden decidir combinar dos o más Centros de Servicio
en una o más estructuras de Centro de Servicio al Usuario al Usuario dispersos geográficamente para proporcionar
Centralizado. Esto puede ser más eficiente y rentable, un servicio que siga al sol durante las 24 horas. Por
permitiendo menos personal general para tratar un ejemplo, un Centro de Servicio al Usuario en Asia-Pacífico
volumen superior de llamadas, y también puede permitir puede responder a las llamadas durante su horario de
mayores niveles de habilidades a través de un elevado oficina estándar y al final de este periodo puede transferir
grado de familiarización mediante la ocurrencia frecuente la responsabilidad para cualquier incidencia abierta a
de eventos. Aún podría ser necesario mantener alguna un centro de servicio con sede en Europa. Ese centro
forma de ’presencia local’ para gestionar los requisitos de de servicio tratará esas llamadas junto con sus propias
soporte físico, aunque ese personal puede controlarse y incidencias durante su horario estándar y luego puede
desplegarse desde el centro de servicio central. transferirlas a un centro de servicio con sede en los EE.UU.,
que finalmente devuelve la responsabilidad al centro de
6.2.3.3  Centro de Servicio Virtual servicio de Asia-Pacífico para completar el ciclo.
A través del uso de la tecnología, particularmente Internet, Esto puede proporcionar una cobertura durante las 24
y el uso de herramientas de soporte corporativas, se horas a un coste relativamente bajo, debido a que ningún
puede proporcionar la experiencia de contar con un centro de servicio trabaja durante más de un turno. No
Centro de Servicio al Usuario único y centralizado cuando, obstante, para que esta metodología funcione se deben
de hecho, el personal puede encontrarse distribuido abordar las mismas salvaguardas de procesos comunes,
o ubicado en cualquier número o tipo de estructura herramientas, base de datos de información y cultura
o ubicación geográfica. Esto introduce la opción del compartidas, y también se requieren procesos de escalado
’teletrabajo’, grupos de soporte secundarios, off-shoring o y transferencia bien controlados.

Usuario Usuario Usuario Usuario

Centro de Servicio
al Usuario

Gestión Gestión Gestión de Soporte Gestión de

Técnica de Aplicaciones Operaciones Externo Peticiones
de TI

Figura 6.2 Centro de Servicio al Usuario Local

 Organización de la Operación del Servicio | 123

Emplazamiento Cliente 1 Emplazamiento Cliente 2 Emplazamiento Cliente 3

Centro de Servicio
al Usuario

Soporte de
Segunda Línea

Gestión Gestión Gestión de Soporte Gestión de

Técnica de Aplicaciones Operaciones Externo Peticiones
de TI

Figura 6.3 Centro de Servicio al Usuario Centralizado

Virtual Service Desk

San Francisco
Centro de Servicio al Usuario
París Rio de
Centro de Servicio Janeiro
al Usuario Centro de Servicio
al Usuario

Centro de Servicio
al Usuario
Virtual
Sidney
Centro de Servicio al Usuario
Beijing
Centro de Servicio al Usuario

Sistema de
Gestión del
Conocimiento
del Servicio
Londres
Centro de Servicio al Usuario
Figura 6.4 Centro de Servicio al Usuario Virtual
124 | Organización de la Operación del Servicio

6.2.3.5  Grupos Especializados del Centro de

Anécdota
Servicio al Usuario
Una compañía detectó que existía una cultura de ’ellos
Para algunas organizaciones podría ser beneficioso crear
y nosotros’ entre el Centro de Servicio al Usuario y el
’grupos de especialistas’ dentro de la estructura general
resto de equipos de soporte. Los equipos de tercera
del Centro de Servicio al Usuario para que las incidencias
línea se consideraban mejores que el personal del
relacionadas con un servicio de TI particular puedan
Centro de Servicio al Usuario. El hecho de ocultar
encaminarse directamente (normalmente a través de la
el Centro de Servicio al Usuario en una sala aislada
selección de telefonía o una interfaz basada en web) al
contribuía a reforzar esta cultura. La compañía
grupo de especialistas. Esto puede permitir una resolución
descubrió que crear una oficina con una distribución
más rápida de estas incidencias, a través de una mayor
abierta con el Centro de Servicio al Usuario situado en
familiaridad y formación especializada.
el centro fomentaba un trabajo más estrecho y ayudó
La selección se realizaría utilizando un script junto con las a superar dichas barreras.
líneas de ’Si su llamada está relacionada con el Servicio
X, pulse 1, de lo contrario, por favor espere para que le
atienda un analista del Centro de Servicio al Usuario’. 6.2.3.7  Nota sobre la creación de un punto
Es necesario tener cuidado para no complicar en exceso único de contacto
la selección, por lo que sólo deben tenerse en cuenta los Independientemente de la combinación de opciones que
grupos especializados para un número muy reducido de se elija para completar la estructura general del Centro de
servicios clave allí donde existan, y cuando las tasas de Servicio al Usuario, los usuarios individuales no deberían
llamadas sobre ese servicio justifiquen la presencia de un tener dudas con respecto a con quién deberían ponerse
grupo de especialistas independiente. en contacto si necesitan asistencia. Debería facilitarse y
publicitarse un único número de teléfono (o un número
6.2.3.6  Entorno individual para cada grupo si se elige una estructura con
El entorno en el que se ubicará el Centro de Servicio al centros de servicio independientes), así como una única
Usuario debería ser cuidadosamente escogido. Cuando sea dirección de correo electrónico y una única página web
posible, deberían facilitarse las siguientes instalaciones: de contacto para el Centro de Servicio al Usuario.

■■ Una ubicación en la que la función completa pueda Algunas ideas que puedan emplearse con éxito para
situarse con luz natural y espacio general suficientes ayudar a publicitar el número de teléfono y la dirección
que permitan disponer de un buen escritorio y espacio de correo electrónico del Centro de Servicio al Usuario,
adecuado de archivos para cada operador, y lugar y facilitar que estén a disposición de los usuarios que
para moverse con comodidad si fuera necesario. probablemente puedan necesitarlos, son:
■■ Un entorno tranquilo, con control acústico adecuado, ■■ Incluir el número de teléfono del Centro de Servicio
para que una conversación telefónica no moleste a al Usuario en las etiquetas de los CI de hardware,
otra adhiriéndolas a los componentes que puedan suscitar
■■ Entornos agradables y mobiliario confortable para llamadas del cliente
alegrar el ánimo (el Centro de Servicio al Usuario ■■ Imprimir los datos de contacto del Centro de Servicio
puede ser un lugar muy estresante en el que trabajar, al Usuario en los teléfonos
por lo que cada pequeño detalle es de utilidad) ■■ En el caso de los PC y portátiles, utilizar un fondo de
■■ Una sala de descanso independiente y zona de pantalla o de escritorio personalizado con los datos
refrigerios próxima para que el personal pueda realizar de contacto del Centro de Servicio al Usuario, junto
breves descansos cuando sea necesario sin alejarse con la lectura de información sobre el sistema que se
durante demasiado tiempo. precisará al llamar (como la dirección IP, número de
versión del sistema operativo) en una esquina
■■ Imprimir el número del Centro de Servicio al Usuario
en los materiales promocionales de marketing
(bolígrafos, lápices, tazas, alfombrillas de ratón, etc.)
■■ Situar estos datos en un lugar destacado en los sitios
de Internet/intranet del Centro de Servicio al Usuario
 Organización de la Operación del Servicio | 125

■■ Incluirlos en cualquier tarjeta de contacto o tarjetas Sería necesario tener en cuenta los siguientes factores al
de encuesta de satisfacción que se entreguen a los tomar decisiones sobre los niveles de personal:
usuarios cuando se necesite visitar un puesto de
■■ Expectativas del cliente con respecto al servicio
trabajo
■■ Requisitos de negocio, como por ejemplo,
■■ Repetir la información de contacto en toda la
presupuesto, tiempos de respuesta a las llamadas, etc.
correspondencia que se envíe a los usuarios (junto con
■■ Tamaño, antigüedad relativa, diseño y complejidad
números de referencia de la llamada)
de la Infraestructura de TI y del Catálogo de Servicios,
■■ Situar la información de contacto en tablones de
por ejemplo, el número y tipo de incidencias, el grado
anuncios o ubicaciones físicas que los usuarios puedan
de personalización con respecto al software comercial
visitar regularmente (entradas, cafeterías, áreas de
estándar desplegado, etc.
refrigerio, etc.).
■■ El número de clientes y usuarios a dar soporte y
factores relacionados, como por ejemplo:
6.2.4 Dotación de personal del Centro de
●● Número de clientes y usuarios que hablan un
Servicio al Usuario
idioma diferente
En esta sección se comentan los problemas y criterios ●● Nivel de habilidades
implicados, para establecer el modelo y los niveles
■■ Tipos de incidencias y de Peticiones de Servicio (y
adecuados de plantilla. El apartado 6.6.1 que se agrega
tipos de RFC, si procede):
más abajo incluye información detallada sobre los roles
●● Tiempo de duración requerido para los tipos de
y responsabilidades habituales del Centro de Servicio al
llamada (por ejemplo, consultas sencillas, consultas
Usuario. Entre ellos se incluye el Gestor, el Supervisor y los
de aplicación especializadas, hardware, etc.)
Analistas del Centro de Servicio al Usuario y, en algunas
organizaciones, estos roles se complementan con usuarios ●● Experiencia local o externa requerida

de negocio (’Super Usuarios’) que proporcionarán soporte ●● Volumen y tipos de incidencias y Peticiones de
de primera línea. Servicio
■■ El periodo de cobertura de soporte requerido, en
6.2.4.1  Niveles de dotación de personal función de:
Una organización debe asegurarse de contar con el ●● Horas cubiertas
número correcto de personal en todo momento para ●● Requisitos de soporte fuera del horario normal
responder a la demanda que el negocio ejercerá sobre ●● Zonas horarias a cubrir
el centro. Las tasas de llamadas pueden ser muy volátiles ●● Ubicaciones a respaldar (particularmente si el
y, con frecuencia, también puede pasar de ser muy alta personal del Centro de Servicio al Usuario también
a muy baja, y volver a ser muy alta de nuevo, durante el realiza soporte en el propio puesto de trabajo del
mismo día. Una organización que planifique un nuevo usuario)
centro de servicio debería intentar predecir la tasa de ●● Tiempo de desplazamiento entre las ubicaciones
entrada de llamadas y el perfil de las mismas, y asignar el ●● Patrón de la carga de trabajo de las peticiones (por
personal correspondiente. Es necesario realizar el análisis ejemplo, diario, al final de mes, etc.)
estadístico de las tasas de entrada de llamadas que
●● Los objetivos de nivel de servicio vigentes (niveles
recogen los acuerdos de soporte actuales, y monitorizarlas
de respuesta, etc.)
y ajustarlas posteriormente si fuera necesario.
■■ El tipo de respuesta requerido
Muchas organizaciones detectarán que las tasas de ●● Telefónica
llamadas presentan picos durante el inicio del horario ●● Correo electrónico/fax/voz/vídeo
de oficina y más tarde descienden rápidamente,
●● Asistencia física
experimentándose posiblemente otro nuevo pico al inicio
●● Acceso/control online
de la tarde. Lógicamente, lo anterior variará en función del
negocio de la organización aunque es un patrón que se ■■ El nivel de formación requerido
detecta con frecuencia en muchas organizaciones. En tales ■■ Las tecnologías de soporte disponibles (por ejemplo,
circunstancias, puede que sea posible utilizar personal a sistemas de telefonía, herramientas de soporte remoto,
tiempo parcial, teletrabajadores, personal de soporte de etc.)
segunda línea o personal externo para dar servicio durante ■■ Los niveles de habilidades existentes en el personal
dichos picos de demanda. ■■ Los procesos y procedimientos vigentes.
126 | Organización de la Operación del Servicio

Es necesario tener en cuenta todos estos elementos antes una base de conocimiento eficaz, scripts de diagnóstico
de tomar cualquier decisión sobre los niveles de dotación y herramientas de soporte integradas (incluyendo un
de personal. Los niveles de documentación necesarios CMS), así como programas continuos de formación y
también deberían reflejar esos elementos. Recuerde que, concienciación, para que las tasas de resolución de la
cuanto mejor sea el servicio, más lo utilizará el negocio. primera línea puedan aumentar gradualmente.
Tiene a su disposición diversas herramientas que ayudan También se puede conseguir lo anterior ubicando personal
a determinar el número adecuado de personal para el de segundo nivel en el Centro de Servicio al Usuario,
Centro de Servicio al Usuario. Este modelado de la carga creando una estructura de dos niveles de forma efectiva.
de trabajo depende del ’conocimiento local’ detallado Esto presenta las ventajas de disponer de personal de
de la organización, como por ejemplo los volúmenes y segundo nivel para ayudar en los periodos con picos de
patrones, servicio y perfiles de usuario, etc. llamadas y formar al personal menos experimentado, y
normalmente incrementará la tasa de resolución en la
6.2.4.2  Nivel de habilidades primera llamada. Sin embargo, el personal de segundo
Una organización debe tomar decisiones sobre el nivel y nivel tendrá responsabilidades fuera del Centro de
rango de habilidades que se requiere para su personal del Servicio al Usuario, lo que obliga a gestionar calendarios
Centro de Servicio al Usuario, y asegurar posteriormente de trabajo o a duplicar puestos de personal de segunda
que esas habilidades estén disponibles en los plazos línea. Además, tratar con llamadas rutinarias puede resultar
adecuados. desmotivador para el personal más experimentado. Una
desventaja potencial adicional es que el Centro de Servicio
Existen diversos niveles de cualificación posibles, al Usuario adquiere capacidades realmente buenas para
comenzando desde un nivel sencillo con sólo ’registro solucionar los problemas de las llamadas, mientras que el
de llamadas’, en el que el personal sólo necesita personal de segundo nivel debería centrarse en eliminar
habilidades técnicas muy básicas, hasta un Centro de la causa raíz en lugar de solucionar los problemas de las
Servicio al Usuario ’técnico’ en el que se emplea personal llamadas.
técnicamente más cualificado. En el primer caso, se
gestionarán muchas llamadas pero la tasa de resolución Otro factor a tener en cuenta al tomar decisiones sobre
será baja, mientras que la situación será opuesta en el los requisitos de habilidades para el personal del Centro
segundo caso. de Servicio al Usuario es el nivel de personalización o
especialización de los servicios soportados. Los servicios
La decisión sobre el nivel de habilidades requerido estará estandarizados requieren menos conocimientos específicos
impulsada frecuentemente por los tiempos de resolución para proporcionar un buen soporte al cliente. Cuanto más
objetivo (acordados con el negocio y reflejados en los especializado sea el servicio, probablemente se requerirá
objetivos de los niveles de servicio), la complejidad de los mayor conocimiento especializado en la primera llamada.
sistemas respaldados y ’lo que el negocio esté dispuesto a
pagar’. Tenga en cuenta que las tasas de resolución en la primera
línea pueden verse reducidas debido a una buena
Existe una fuerte correlación entre los objetivos y los Gestión de Problemas, lo que reducirá el número de las
costes de respuesta y resolución. En general, cuanto más incidencias más sencillas y repetitivas. En tales casos,
breve sean los tiempos objetivo, más elevado será el aunque las tasas de resolución parezcan reducirse, la
coste, debido a que se necesitarán más recursos. calidad de servicio general habrá mejorado al eliminarse
Aunque pueden existir casos en los que la dependencia por completo muchas de las incidencias. Aunque esto es
o criticidad del negocio obligan a contar con un centro positivo, si se tratara de un caso en que el personal del
de servicio altamente especializado a nivel técnico, Centro de Servicio al Usuario recibe incentivos y premios
normalmente, el método óptimo y más económico por la resolución en la primera llamada, podría ser
es tener una primera línea de soporte de ’registro de perjudicial para el estado de ánimo de dicho personal y la
llamadas’, con escalados rápidos y eficaces a grupos de eficacia del proceso, a menos que se revisen los umbrales
resolución de segunda y tercera línea más cualificados de los incentivos y se adecuen a la nueva situación.
en los que el personal puede estar concentrado y ser Las mejoras de los tiempos/tasas de resolución no
utilizado con mayor eficacia (vea Gestión de Incidencias, deberían dejarse al azar, sino que deben formar parte de
sección 4.2, si desea más detalles y referencias sobre un Programa de Mejora Continua del Servicio (consulte
las estructuras de soporte principio a fin). Sin embargo, la publicación Mejora Continua del Servicio si desea
este punto básico de inicio puede mejorar a lo largo del información adicional).
tiempo si se incorpora personal de primera línea con
 Organización de la Operación del Servicio | 127

Una vez que se identifiquen los niveles de habilidad al Usuario es vital. Todo el personal recién incorporado
necesarios, existe una tarea continua que debe asegurar debe asistir a un programa de introducción formal, cuyo
que el Centro de Servicio al Usuario permita que el contenido exacto variará en función de los niveles de
personal respectivo obtenga y mantenga las habilidades habilidades y de la experiencia con la que cuente el nuevo
necesarias, y que el personal con un correcto balance de personal; aunque es probable que incluya muchas de las
habilidades esté en servicio en los horarios pertinentes habilidades requeridas indicadas anteriormente.
para mantener la consistencia.
Cuando sea posible, debería impartirse un programa
Lo anterior implicará un programa de formación y de concienciación, que incluya breves periodos de
concienciación continua que debería cubrir: adscripción en comisión de servicio en áreas de negocio
clave, en especial al nuevo personal que aún no cuente
■■ Habilidades en relaciones interpersonales, habilidades
con este nivel de concienciación sobre el negocio.
en atención telefónica, habilidades de comunicación,
escucha activa y formación en la atención al cliente. El nuevo personal del Centro de Servicio al Usuario
■■ Concienciación sobre el negocio: conocimiento debería estar inicialmente ’a la sombra’ del personal
específico de las áreas de negocio, impulsores, experimentado, sentado junto a ellos y escuchando
estructura, prioridades, etc. de la organización las conversaciones, antes de responder ellos mismos
■■ Concienciación sobre la provisión de todos los a llamadas, con un mentor a la escucha que tenga la
servicios de TI clave de la organización para los que se capacidad de intervenir y proporcionar soporte cuando
proporciona soporte sea necesario. El mentor debería revisar inicialmente cada
■■ Concienciación técnica (y una formación técnica más llamada con el empleado en prácticas después de su
profunda hasta el nivel adecuado, en función de la finalización para enseñarle cualquier lección. La frecuencia
tasa de resolución que se pretenda conseguir) de tales revisiones debería reducirse gradualmente a
medida que aumente la experiencia y la seguridad,
■■ En función del nivel de servicio provisto, algunas
aunque el mentor continuará proporcionando soporte
habilidades de diagnóstico (por ejemplo, Kepner y
continuo incluso cuando el empleado en prácticas haya
Tregoe)
alcanzado la etapa en la que puede trabajar de forma
■■ Herramientas y técnicas de soporte
independiente.
■■ Formación y guías de concienciación previos a la
introducción de nuevos sistemas y tecnologías Puede ser necesario formar a los mentores para realizar
■■ Procesos y procedimientos (más particularmente esta actividad. La experiencia y las habilidades técnicas
Gestión de Incidencias, Cambios y de la Configuración, en el Centro de Servicio al Usuario no bastan para ser
pero con una descripción general de todos los un buen orientador. Las habilidades para transferir
procesos y procedimientos de ITSM) conocimiento con eficacia y la capacidad para enseñar
sin ser condescendiente o amenazante son igualmente
■■ Habilidades mecanográficas y de lenguaje para
importantes.
asegurar la entrada rápida y precisa de información
sobre la incidencia o Petición de Servicio. Se necesitará un programa que mantenga actualizado
el conocimiento del personal del Centro de Servicio al
Para que un programa de este tipo sea eficaz, deberían
Usuario y que conciencie al personal sobre los nuevos
evaluarse periódicamente los requisitos y niveles de
desarrollos, servicios y tecnologías. Los plazos en los que
habilidad y mantener registros sobre la formación.
se realicen tales eventos son críticos y no deben afectar a
También debería mantenerse una preparación cuidadosa las obligaciones habituales. Muchos Centros de Servicio al
de las rotaciones y calendarios de dotación de personal Usuario detectan que es mejor organizar breves ’tutoriales’
para conservar un equilibrio uniforme de experiencia y durante los periodos tranquilos cuando será menos
niveles de habilidad adecuados en el personal durante probable que se requiera que el personal atienda a las
los periodos operativos críticos. No basta únicamente con llamadas.
contar con el número adecuado de personal en servicio,
Nota: Debería invertirse en el desarrollo profesional del
también se debería disponer de la combinación correcta
personal del Centro de Servicio al Usuario. La tutoría
de habilidades.
interna y el aprendizaje práctico junto al personal de
segundo y tercer nivel es un buen comienzo, pero
6.2.4.3  Formación
los Centros de Servicio al Usuario de primer nivel se
La formación adecuada del personal del Centro de Servicio benefician de un programa formalizado de desarrollo del
al Usuario antes de incorporarse al Centro de Servicio personal. El compromiso organizativo con el desarrollo
128 | Organización de la Operación del Servicio

profesional contribuye a inculcar un sentido de logro y Esto contribuye a evitar ’avalanchas de incidencias’cuando
oportunidad entre el personal. Esto permite con frecuencia falle un componente que afecte a muchos clientes.
la innovación en la operación del Centro de Servicio al
También pueden servir para hacer llegar información
Usuario (como, por ejemplo, los servicios especializados)
desde el Centro de Servicio al Usuario hasta su comunidad
que a su vez impulsan las eficiencias operativas en todas
de usuarios local, lo que puede ser muy útil para divulgar
las líneas de soporte. Esto contribuye a crear habilidades
con rapidez información detallada del servicio a todos los
que pueden ser útiles en el rol actual y también a medida
usuarios.
que se progresa e inicia la formación para un nuevo
rol. Aunque es importante desarrollar sus competencias Es importante observar que los Super Usuarios deberían
esenciales en su rol actual, también será importante registrar todas las llamadas que traten, y no sólo aquellas
disponer con un recorrido profesional claro y reconocer que pasen a TI. Esto quiere decir que deben tener acceso
los requisitos y necesidades de desarrollo futuros. y formación sobre cómo utilizar las herramientas de
registro de Incidencias. Esto ayudará a medir la actividad
6.2.4.4  Retención del personal del Super Usuario y también a asegurar que no abuse
Es muy importante que todos los Directores de TI de su posición. Además, se garantizará que no se pierda
reconozcan la importancia del Centro de Servicio al un historial valioso sobre las incidencias y la calidad del
Usuario y del personal que trabaja en él, y le concedan servicio.
esta atención especial. Cualquier pérdida de personal También es posible que los Super Usuarios se involucren
importante puede ser perjudicial y provocar una en:
inconsistencia en el servicio, por lo que deberían
■■ Formación técnica para los usuarios de su área
emplearse esfuerzos para conseguir que el Centro de
■■ Proporcionar soporte para las incidencias menores o la
Servicio al Usuario sea un lugar atractivo en el que
gestión de peticiones sencillas
trabajar.
■■ Involucrarse en el despliegue de nuevas versiones
Entre las alternativas para conseguir lo anterior se incluye
el reconocimiento adecuado del rol con paquetes de Los Super Usuarios no facilitan soporte necesariamente
recompensa que lo premien, ejercicios de fortalecimiento para todos los aspectos de TI. En muchos casos, un
de los equipos, rotación del personal en otras actividades Super Usuario únicamente proporcionará soporte para
(proyectos, soporte de segunda línea, etc.). una aplicación, módulo o área de unidad de negocio
específica. Como usuario del negocio, a menudo el Super
El Centro de Servicio al Usuario puede servir en ocasiones Usuario cuenta con un conocimiento profundo sobre
como peldaño o trampolín hacia otros roles más técnicos el funcionamiento de los procesos de negocio clave y
o de supervisión/gestión. Por esa razón, es necesario cómo funcionan los servicios en la práctica. Es muy útil
garantizar que se realicen planificaciones adecuadas compartir este conocimiento con el Centro de Servicio al
de relevo del personal para que el centro de servicio Usuario, para que éste pueda mejorar la calidad de los
no pierda en ningún momento su experiencia clave servicios en el futuro.
en cualquier área. Además, el riesgo puede mitigarse
mediante una buena documentación y formación Es necesario destacar que los Super Usuarios potenciales,
multidisciplinar. y especialmente su dirección, deben mostrar un firme
compromiso para dedicar tiempo e interés en el
6.2.4.5  Super Usuarios desempeño de este rol antes de que se inicie la selección
y la formación.
Muchas organizaciones consideran que es útil nombrar
o designar un número de ’Super Usuarios’ entre toda la Un Super Usuario debe recibir la formación,
comunidad de usuarios para que actúen como puntos responsabilidad y expectativa adecuadas para que se
de contacto con TI en general y el Centro de Servicio al convierta en una interfaz valiosa para el negocio y el
Usuario en particular. Centro de Servicio al Usuario. Los Super Usuarios pueden
ser desaprovechados si no se comunica claramente a los
Los Super Usuarios pueden recibir cierta formación y
usuarios su rol, responsabilidades y el proceso que los
concienciación adicional y servir de canal de comunicación
gobierna. Es imprescindible que un Super Usuario no sea
en ambos sentidos. Es posible que se les solicite filtrar
percibido como un sustituto o un medio para eludir al
peticiones y problemas que plantee la comunidad de
Centro de Servicio al Usuario.
usuarios (en algunos casos hasta el punto de que sea el
Super Usuario quien eleve las incidencias o peticiones).
 Organización de la Operación del Servicio | 129

6.2.5  Métricas del Centro de Servicio al y válidas, puede descomponer esta métrica en más
Usuario detalle tal y como se indica a continuación:
●● El porcentaje de llamadas resueltas durante el
Deberían establecerse métricas para poder evaluar
regularmente el rendimiento del Centro de Servicio al primer contacto con el Centro de Servicio al
Usuario. Las métricas son importantes para evaluar la Usuario, por ejemplo, mientras el usuario sigue al
salud, madurez, eficiencia, eficacia y cualquier oportunidad teléfono para informar de la llamada
de mejora de las operaciones del Centro de Servicio al ●● El porcentaje de llamadas resueltas por el propio

Usuario. personal del Centro de Servicio al Usuario sin

necesidad de solicitar soporte adicional de otros
Las métricas del rendimiento del Centro de Servicio al grupos. Nota: algunos centros de servicio deciden
Usuario deben ser realistas y elegidas cuidadosamente. ubicar en el mismo lugar, o integrar, personal
Es habitual que se seleccionen métricas que no están de segunda línea técnicamente cualificado con
fácilmente disponibles y que pudieran parecer una posible el Centro de Servicio al Usuario (vea Gestión de
indicación del rendimiento; no obstante, esto último Incidencias si desea más información). En tales
puede resultar confuso. Por ejemplo, el número total de casos, cuando se realicen comparaciones es
llamadas recibidas por el Centro de Servicio al Usuario importante separar (i) el porcentaje resuelto por el
no es en sí mismo una indicación de un rendimiento propio personal del Centro de Servicio al Usuario;
bueno o malo y, de hecho, puede deberse a eventos y (ii) el porcentaje resuelto por la combinación del
completamente ajenos al control del Centro de Servicio al personal de primera línea del Centro de Servicio al
Usuario. Por ejemplo, un periodo particularmente activo Usuario y el personal de segunda línea.
para la organización o la entrega de una nueva versión de ■■ Tiempo medio de resolución de una incidencia
un sistema corporativo importante.
(cuando se resuelva en la primera línea)
Un aumento del número de llamadas al Centro de ■■ Tiempo medio para escalar una incidencia (cuando no
Servicio al Usuario puede indicar una menor fiabilidad sea posible una resolución en la primera línea)
de los servicios durante ese periodo de tiempo, pero ■■ Coste medio del Centro de Servicio al Usuario para la
también puede mostrar la confianza del usuario en un gestión de una incidencia. En este punto se deberían
Centro de Servicio al Usuario que está madurando, lo considerar dos métricas:
que provoca una mayor probabilidad de que los usuarios ●● Coste total del Centro de Servicio al Usuario
soliciten asistencia en lugar de intentar solucionar dividido por el número de llamadas. Esto
sus problemas por sí mismos. Para que este tipo de proporcionará una cifra media que es útil como
métrica sea fiable y permita llegar a alguna conclusión, índice y a fines de planificación pero que no
es necesario realizar una comparación adicional de los representa de forma precisa los costes relativos de
periodos anteriores para cualquier mejora del Centro de los diferentes tipos de llamadas
Servicio al Usuario implementada desde la última línea
●● Si se calcula el porcentaje del tiempo de duración
de referencia de medición, o los cambios de fiabilidad del
de la llamada en todo el centro y un coste por
servicio, problemas, etc. para aislar la verdadera causa del
minuto (costes totales durante el periodo por los
incremento.
minutos de duración totales de la llamada), se
Por lo tanto, se requiere un análisis adicional y métricas puede obtener el coste de las llamadas individuales
más detalladas que deben ser examinadas durante un y proporcionar una cifra más precisa.
determinado periodo de tiempo. Este análisis incluirá
Al evaluar los tipos de incidencias con la duración de la
las estadísticas del tratamiento de llamadas mencionadas
llamada, se obtiene una imagen más precisa del coste
anteriormente en telefonía, y adicionalmente:
por llamada para cada tipo de llamada, y se consigue
■■ Tasa de resolución en la primera línea: el porcentaje una indicación sobre qué tipos de incidencias tienden
de llamadas resueltas en la primera línea, sin la a presentar un coste de resolución mayor y los posibles
necesidad de escalados a otros grupos de soporte. objetivos de mejora.
Esta es la cifra que las organizaciones citan con ■■ Porcentaje de actualizaciones de clientes o usuarios
frecuencia como medida principal del rendimiento de
realizadas dentro de los tiempos objetivo, según se
los Centros de Servicio al Usuario, y que se emplea
defina en los objetivos del SLA
para comparar el rendimiento con otros centros,
■■ Tiempo medio para revisar y cerrar una llamada
aunque las comparaciones deben realizarse con
resuelta
cuidado. Para realizar comparaciones más precisas
130 | Organización de la Operación del Servicio

■■ El número de llamadas, desglosado por hora y día del Centro de Servicio al Usuario fue cortés y profesional,
de la semana; combinado con la métrica del tiempo si inculcan o no confianza al usuario.
medio de llamada, es crítico para determinar el
Los propios usuarios son la mejor fuente para obtener
número de personal necesario.
estas medidas. Puede obtenerlas a través de una encuesta
En la publicación Mejora Continua del Servicio se ofrece más amplia de satisfacción del cliente/usuario que cubra
información detallada adicional sobre métricas y cómo todo TI o puede buscarlas específicamente en los propios
deberían emplearse para impulsar la calidad del servicio. problemas del Centro de Servicio al Usuario.

6.2.5.1  Encuestas de satisfacción del cliente/ Una forma eficaz para conseguir lo anterior es devolver
la llamada al cliente o usuario para realizar una
usuario
encuesta telefónica, en la que un Operador o Supervisor
Además de realizar el seguimiento de las medidas independiente del Centro de Servicio al Usuario llama a un
tangibles del rendimiento del Centro de Servicio al Usuario pequeño porcentaje de usuarios, poco después de que se
(a través de las métricas descritas más arriba), también es haya resuelto su incidencia, para formularles las preguntas
importante evaluar las mediciones más intangibles, como específicas necesarias.
por ejemplo, cómo perciben los clientes y usuarios que se
ha respondido a sus llamadas, si sienten que el operador El número de preguntas formuladas debería ser muy
reducido (de cinco a seis como máximo) para que los
Tabla 6.1 Herramientas y técnicas de encuestas
Técnica/Herramienta Ventajas Desventajas
Encuesta posterior a la llamada ■■ Alta velocidad de respuesta, ya que el ■■ Las personas podrían sentirse
Se les solicita a los usuarios que que llama se encuentra al teléfono presionadas a la hora de hacer la
permanezcan al teléfono después de la ■■ Se encuesta al usuario inmediatamente encuesta, lo que da como resultado una
llamada y a continuación se les pide que después de la llamada, ya que su experiencia negativa del servicio
evalúen el servicio que se les proporcionó experiencia es reciente ■■ El encuestador se percibe como parte
del Centro de Servicio al Usuario que
está haciendo la encuesta, lo que podría
desmotivar las respuestas abiertas
Encuesta telefónica saliente ■■ La velocidad de respuesta es mayor, ■■ Este método podría verse como
Se contacta en algún momento con ya que se entrevista directamente al intrusivo, si la llamada interrumpiera el
los clientes y usuarios que hayan usado usuario trabajo del usuario o cliente
previamente el Centro de Servicio al ■■ Pueden identificarse categorías ■■ La encuesta se realiza en algún
Usuario después de su experiencia con el específicas de usuarios o clientes momento después de que el usuario
mismo (p. ej., personas que solicitaron un o cliente haya hecho uso del Centro
servicio específico, o personas que de Servicio al Usuario por lo que su
experimentaron la interrupción de un percepción podría haber cambiado
servicio en particular)
Entrevistas personales ■■ El entrevistador es capaz de observar ■■ Las entrevistas consumen tiempo para el
La persona que está haciendo la encuesta señ~ales no verbales además de escuchar entrevistador y el entrevistado
entrevista personalmente a clientes y lo que el usuario o cliente está diciendo ■■ Los usuarios y clientes podrían convertir
usuarios. Este método es especialmente ■■ Los usuarios y clientes sienten un las entrevistas en sesiones de quejas
eficaz para clientes o usuarios que usan alto grado de atención personal y un
el Centro de Servicio al Usuario con sentimiento de que sus respuestas se
cierta frecuencia o que hayan tenido una están tomando en serio
experiencia negativa

Entrevistas de grupo ■■ Puede entrevistarse a un gran número ■■ Puede que las personas no se expresen
Se entrevista a clientes y usuarios en de usuarios y clientes libremente en presencia de sus iguales o
pequeñ~os grupos. Este método es ■■ Las preguntas son más genéricas y responsables
adecuado para recopilar impresiones por lo tanto más consistentes entre ■■ Las opiniones de las personas pueden
generales y para determinar si hay entrevistadores cambiar fácilmente en el grupo durante
necesidad de cambiar ciertos aspectos del la entrevista
Centro de Servicio al Usuario, p. ej., horas
de servicio o ubicación
 Organización de la Operación del Servicio | 131

Tabla 6.1 Herramientas y técnicas de encuestas (continuado)

Técnica/Herramienta Ventajas Desventajas
Encuestas por correo ordinario/correo ■■ Todos los clientes o usuarios, o aquellos ■■ Las encuestas por correo necesitan
electrónico específicos, pueden ser el objetivo mucha mano de obra para su proceso
Los cuestionarios de la encuesta se envían ■■ Las encuestas por correo pueden ■■ El porcentaje de personas que responde
por correo a un conjunto objetivo de ser anónimas, lo que permitirá a las a las encuestas por correo tiende a ser
clientes y usuarios. Se les solicita que personas expresarse con más libertad pequen~o
devuelvan sus respuestas por correo
■■ Las encuestas por correo electrónico ■■ La falta de interpretación de una
ordinario o por correo electrónico
no son anónimas, pero se pueden crear pregunta podría afectar al resultado
usando formas automatizadas que sean
convenientes y fáciles de responder
por parte del usuario. También se
incrementa la probabilidad de que se
completen.
Encuestas online ■■ La audiencia potencial de estas ■■ No se podrá predecir el porcentaje de
Los cuestionarios se publican en un sitio encuestas es bastante grande los que respondan a las encuestas
web y se anima a los usuarios y clientes ■■ Los encuestados pueden completar el
por correo electrónico o por vínculos en cuestionario a su debido tiempo
una página frecuentada a participar en la
■■ Los vínculos en las páginas web
encuesta
transitadas son buenos recordatorios sin
ser intrusivos

usuarios concedan el tiempo de cooperación necesario. Independientemente de las razones o de la amplitud del
También se diseñarán las preguntas de la encuesta para contrato de externalización, es vital que la organización
que el usuario o cliente conozca sobre qué área o materia mantenga la responsabilidad de las actividades y servicios
se formulan las preguntas y a qué incidencia o servicio se proporcionados por el Centro de Servicio al Usuario. La
refieren. El Centro de Servicio al Usuario debe emprender organización es responsable en última instancia de los
acciones si se detectan niveles de satisfacción bajos y en resultados de la decisión, y por lo tanto debe determinar
relación con cualquier retroalimentación que reciba. el nivel de servicio que proporcionará la empresa externa,
no al revés.
Para poder realizar comparaciones adecuadas, debería
elegirse el mismo porcentaje de llamadas en cada periodo Si se eligiera el camino de la externalización, existirán
y realizar rigurosamente las encuestas a pesar de que algunas salvaguardas que serán necesarias para garantizar
existan otras presiones de tiempo. que el Centro de Servicio al Usuario externalizado
funcione eficaz y eficientemente con los demás equipos y
Las encuestas son un área compleja y especializada, y
departamentos de TI de la organización, y para mantener
requieren un buen entendimiento de las estadísticas y
el control de la Gestión del Servicio de principio a fin
de las técnicas de su realización. Esta publicación no
(esto es particularmente importante para organizaciones
pretende proporcionar una descripción general de todas
que buscan la certificación ISO/IEC 20000 ya que se tendrá
ellas, pero en la Tabla 6.1 se ofrece un resumen de
que demostrar el control general de la gestión). Algunas
algunas de las técnicas y herramientas más empleadas.
de estas salvaguardas se describen a continuación.
6.2.6 Externalización del Centro de Servicio
6.2.6.1  Herramientas y procesos comunes
al Usuario
El Centro de Servicio al Usuario no tendrá la
La decisión de externalizar el Centro de Servicio al Usuario
responsabilidad de todos los procesos y procedimientos
es un aspecto estratégico para los gestores senior, y se
que inicie. Por ejemplo, el Centro de Servicio al Usuario
aborda con detalle en las publicaciones Estrategia del
recibe una Petición de Servicio pero el equipo de
Servicio y Diseño del Servicio. Muchas de las directrices
Operaciones de TI interno satisfará tal petición.
incluidas en esta sección no son únicas para el Centro de
Servicio al Usuario y se pueden aplicar a cualquier función, Si se externalizara el Centro de Servicio al Usuario, se
área de soporte y servicio que se esté externalizando. deberán tomar las precauciones oportunas para que las
herramientas sean consistentes con aquellas que todavía
132 | Organización de la Operación del Servicio

se están usando en la organización del cliente. En muchas podrían indicar que un proveedor potencial usa el Marco
ocasiones la externalización se ve como una oportunidad de Trabajo de ITIL en su entrega de servicios a los clientes,
para sustituir herramientas obsoletas o inadecuadas, y en o que ha logrado la certificación de estándares para
otras ocasiones sólo para detectar que existen problemas sus prácticas internas, pero es igualmente importante
graves de integración entre la nueva herramienta y las disponer de la tecnología que demuestre la capacidad
herramientas y procesos heredados. de un proveedor de servicio para gestionar servicios y
que dispone de una interfaz adecuada para las prácticas
Por esta razón, es importante garantizar que esos aspectos
internas. No existe un estándar de cumplimiento que
se investiguen apropiadamente y que se enfoquen y
asegure esto y por lo tanto los esfuerzos de contratación
especifiquen adecuadamente los requisitos del cliente
deben incluir cuestiones específicas para satisfacer este
antes de firmar el contrato de externalización. Las
requisito. Se puede encontrar más información sobre
herramientas del Centro de Servicio al Usuario no sólo
la captación de proveedores externos en la publicación
apoyan al Centro de Servicio al Usuario externalizado, sino
Diseño del Servicio.
que también deberán apoyar los requisitos de negocio y
los procesos de la organización del cliente.
6.2.6.2  Objetivos de los SLA
Idealmente, el centro de servicio externalizado deberá usar Será necesario que los objetivos de los SLA con respecto
algunas herramientas y procesos (o, como mínimo, hacer a los tiempos totales de gestión de incidencias y de
de interfaz entre herramientas y procesos) para permitir resolución se acuerden con los clientes y entre todos
un flujo de proceso sin impedimentos entre el Centro de los equipos y departamentos, y será necesario coordinar
Servicio al Usuario y los grupos de soporte de segunda y y acordar los objetivos de los OLA/UC con grupos de
tercera línea. soporte individuales para afianzar y apoyar los objetivos
Por otra parte, el Centro de Servicio al Usuario de los SLA.
externalizado deberá tener acceso a: En la sección sobre métricas que se incluye más arriba se
■■ Toda la información y registros de incidencias podrán ver ejemplos de estos objetivos (vea la sección
■■ Información y Registros de Problemas 6.2.5).
■■ Datos de Errores Conocidos
■■ Planificación de Cambios 6.2.6.3  Buenas comunicaciones
■■ Fuentes de conocimiento interno (especialmente Es necesario que las líneas de comunicación entre el
expertos en aplicaciones o técnicos) Centro de Servicio al Usuario externalizado y los otros
■■ SKMS grupos de soporte trabajen de forma muy eficiente. Esto
puede favorecerse mediante los siguientes pasos:
■■ CMS
■■ Alertas procedentes de herramientas de ■■ Ubicación física cercana
monitorización. ■■ Reuniones regulares de revisión/coordinación
■■ Tutoriales de formación cruzada entre los equipos y
En muchas ocasiones supone un reto integrar procesos
y herramientas en una organización menos madura con departamentos
respecto a aquellas que son más maduras. Un supuesto ■■ Mecanismos de ’asociación’ cuando se usa
común pero incorrecto es que la madurez de una conjuntamente personas de ambas organizaciones
organización de algún modo dará como resultado una para dotar de personal al centro de servicio
mayor madurez en las otras. La implicación activa para ■■ Los Planes de Comunicación y objetivos de
garantizar el alineamiento de los procesos y herramientas rendimiento se documentan de manera consistente en
es esencial para lograr una transición suave y una gestión OLAs y UCs.
continua de los servicios entre las organizaciones internas En casos en los que el Centro de Servicio al Usuario se
y externas. De hecho, si esto no se abordara directamente, ubique off-shore, no todas estas medidas serán posibles.
podría dar como resultado un incumplimiento del Sin embargo, todavía será fundamental la necesidad de
contrato. formación y de comunicación del personal del Centro de
Además, también se asume incorrectamente que la prueba Servicio al Usuario, aún más en casos en los que existan
de la calidad y madurez de la Gestión del Servicio en un diferencias idiomáticas y culturales.
socio externo puede garantizarse estableciendo requisitos Esto se tratará con más detalle en publicaciones
en el procedimiento de compras para la ’conformidad con complementarias de ITIL, pero, como regla general, las
ITIL’ y / o ’certificación ISO/IEC 20000’. Estas afirmaciones
 Organización de la Operación del Servicio | 133

empresas de externalización que ofrecen soluciones off- 6.3  Gestión Técnica

shore de Centro de Servicio al Usuario, tendrán que tener
Gestión Técnica hace referencia a los grupos,
en cuenta lo siguiente:
departamentos o equipos que ofrecen la experiencia
■■ Programas de formación centrados en el técnica y la gestión general de la Infraestructura de TI.
entendimiento cultural del mercado del cliente
■■ Habilidades idiomáticas – especialmente el 6.3.1 Rol de Gestión Técnica
entendimiento del uso idiomático del lenguaje del Gestión Técnica desempeña un doble rol:
mercado local del cliente. Esto no quiere decir que
se haga un esfuerzo para que el personal del Centro ■■ Es el custodio del conocimiento y experiencia técnica
de Servicio al Usuario parezca que sea nativo del asociados con la gestión de la Infraestructura de TI.
país del cliente (los clientes detectan rápidamente En este rol, Gestión Técnica garantiza el conocimiento
ese tipo de falta de sinceridad), sino que se facilite el necesario para que se identifiquen, desarrollen y
entendimiento del cliente y que éste aprecie mejor definan el diseño, prueba, gestión y mejora de los
sus prioridades servicios de TI.
■■ Visitas regulares de representantes de la organización ■■ Proporciona los recursos reales para apoyar el
del cliente para proporcionar formación y Ciclo de Vida de ITSM. En este rol, Gestión Técnica
retroalimentación apropiadas directamente al personal garantiza que los recursos se formen y se desplieguen
y a la dirección del Centro de Servicio al Usuario eficazmente para diseñar, construir, realizar la
transición, operar y mejorar la tecnología requerida
■■ Formación en el uso de métodos de trabajo y
para entregar y apoyar servicios de TI.
herramientas de las organizaciones del cliente. Esto
es especialmente eficaz si los mismos instructores Con estos dos roles, Gestión Técnica podrá garantizar
presentan materiales de formación similares a aquellos que la organización tenga acceso al tipo correcto de nivel
usados por la organización del cliente. de recursos humanos para gestionar la tecnología y, por
lo tanto, cumplir los objetivos de negocio. La definición
6.2.6.4  Propiedad de los datos de los requisitos de estos roles comienza con Estrategia
Deberá determinarse la propiedad de los datos recopilados del Servicio, se amplía en Diseño del Servicio, se valida
por el Centro de Servicio al Usuario externalizado. La en Transición del Servicio y se perfecciona en Mejora
propiedad de todos los datos relativos a los usuarios, Continua del Servicio (vea las demás publicaciones de ITIL
clientes, CIs afectados, servicios, incidencias, Peticiones de de esta serie).
Servicio, cambios, etc., deberá residir en la organización Parte de este rol también consiste en garantizar un
que esté externalizando la actividad, pero ambas equilibrio entre el nivel de habilidad, utilización y el coste
organizaciones requerirán acceso a los mismos. de estos recursos. Por ejemplo, no sería eficaz contratar un
Los datos que se asocien específicamente con el recurso de alto nivel en el extremo más alto de la escala
rendimiento de los empleados de la compañía de de salarios y, a continuación, sólo usar esa habilidad el
externalización seguirán siendo de propiedad de la misma, 10% del tiempo. Una estrategia más adecuada de Gestión
que en muchas ocasiones tendrá restricciones legales a Técnica sería identificar los tiempos que se necesitará una
la hora de compartir los datos con la organización del determinada habilidad técnica y entonces contratar a un
cliente. Esto también podría aplicarse a otros datos que proveedor sólo para esas tareas.
se usen únicamente para la gestión interna del Centro Otra estrategia en organizaciones grandes sería hacer
de Servicio al Usuario, como actividades de optimización, uso de personal especializado fuera de los grupos
recuento, información de costes del Centro de Servicio al ’centrales’ para que se pueda emplear adecuadamente a
Usuario, etc. los técnicos especialistas, proporcionar una economía de
Todos los requisitos y cuestiones asociados con la escala para la organización y minimizar la necesidad de
propiedad de los datos deberán especificarse en el contratar proveedores. Deberán identificarse habilidades
contrato de soporte con la empresa que ofrece el servicio especializadas entre recursos de la organización de TI
de externalización. y, a continuación, hacer uso de ellas para necesidades
específicas que se puedan plantear. Sería análogo a una
unidad táctica especial cuyos miembros también realizan
tareas regulares pero a los que se les asignan tareas que
necesitan de sus habilidades especializadas. Este tipo de
134 | Organización de la Operación del Servicio

utilización de recursos es particularmente útil para los estas habilidades se realiza durante la Mejora Continua
equipos de proyecto y para la resolución de problemas. del Servicio.
Un rol adicional, pero muy importante, que desempeña ■■ Documentación de las habilidades que existan en la
Gestión Técnica, es proporcionar una directriz para organización, además de aquellas que sea necesario
Operaciones de TI sobre la mejor forma de realizar la desarrollar. Esto incluirá el desarrollo de Inventarios de
gestión operativa continua de la tecnología. Este rol se Habilidades y la realización de Análisis de Necesidades
lleva a cabo parcialmente durante el proceso de Diseño de Formación.
del Servicio, pero también como parte de la comunicación ■■ Iniciar programas de formación para desarrollar y
diaria con Gestión de Operaciones de TI, ya que se busca perfeccionar las habilidades en los recursos técnicos
lograr una estabilidad y rendimiento óptimos. apropiados y mantener registros de formación para
todos los recursos técnicos.
A continuación se analizan los objetivos, actividades y
■■ Diseño y provisión de formación para usuarios, para
estructuras que permiten a Gestión Técnica realizar estos
el Centro de Servicio al Usuario, y para otros grupos.
roles de forma eficaz.
Aunque los requisitos de formación deben definirse
en Diseño del Servicio, éstos se ejecutan en Operación
6.3.2 Objetivos de Gestión Técnica del Servicio. En el caso de que Gestión Técnica no
Los objetivos de Gestión Técnica son ayudar a planificar, provea formación, será responsable de la identificación
implementar y mantener una infraestructura técnica de organizaciones que puedan proporcionarla.
estable para apoyar los procesos de negocio de la ■■ Contratación de recursos con habilidades que no se
organización a través de: puedan desarrollar internamente, o que no hubiera
■■ Una topología técnica rentable, con alta capacidad de suficientes personas para realizar las actividades
recuperación y bien diseñada requeridas de Gestión Técnica.
■■ El uso de las habilidades técnicas adecuadas para ■■ Obtener habilidades para actividades específicas si las
mantener la infraestructura técnica en condiciones requeridas no estuvieran disponibles internamente o
óptimas en el mercado, o si fuera mucho más rentable hacerlo
■■ Uso rápido de habilidades técnicas para acelerar el de esta manera.
diagnóstico y resolver cualquier fallo técnico que se ■■ Definición de estándares usados en el diseño de
produzca. nuevas arquitecturas y participación en la definición
de arquitecturas tecnológicas durante las fases de
6.3.3  Actividades genéricas de Gestión Estrategia y Diseño del Servicio.
Técnica ■■ Investigación y desarrollo de soluciones que puedan
ayudar a ampliar el Portfolio de Servicios o que
Gestión Técnica está implicada en dos tipos de
se puedan utilizar para simplificar o automatizar
actividades:
Operaciones de TI, reducir costes o incrementar los
■■ En esta sección se analizan las actividades que son niveles de servicio de TI.
genéricas en relación con la función de Gestión ■■ Implicación en el diseño y construcción de nuevos
Técnica en su totalidad ya que hacen posible que servicios. Gestión Técnica contribuirá al diseño de
Gestión Técnica, como función, ejecute su rol. estándares de Rendimiento y Arquitectura Técnica
■■ En el Capítulo 5 se recoge un conjunto de actividades para servicios de TI. Por otra parte, también será
y procesos separados que son realizados por las tres responsable de especificar las actividades operativas
funciones de Gestión de Operaciones de TI, Técnica, y requeridas para gestionar la Infraestructura de TI de
de Aplicaciones. forma continua.
Las actividades genéricas de Gestión Técnica se destacan ■■ Implicación en proyectos, no sólo durante Diseño
de la siguiente forma: del Servicio y Transición del Servicio, sino también
para Mejora Continua del Servicio o para proyectos
■■ Identificar el conocimiento y experiencia requeridos
operativos como por ejemplo actualizaciones de
para gestionar y operar la Infraestructura de TI y para
Sistemas Operativos, proyectos de consolidación de
entregar servicios TI. Este proceso comienza durante
servidores, o movimientos físicos.
la fase de Estrategia del Servicio, se amplía con detalle
■■ Gestión de la Disponibilidad y de Capacidad dependen
en Diseño del Servicio, y se ejecuta en Operación del
de Gestión Técnica para diseñar servicios de TI que
Servicio. La evaluación y actualización continuas de
cumplan los niveles de servicio requeridos por el
 Organización de la Operación del Servicio | 135

negocio. Esto significa que el modelado y previsión de la Configuración y sus datos. Esto se realizará en
la carga de trabajo a menudo se realizan con recursos cooperación con Gestión de Aplicaciones para
de Gestión Técnica. garantizar que se creen las relaciones y atributos
■■ Colaboración a la hora de evaluar los riesgos, correctos de los CIs a partir del despliegue de servicios
identificando dependencias críticas del sistema y del y del mantenimiento continuo durante la vida útil de
servicio y definiendo e implementando contramedidas. los CIs.
■■ Diseño y realización de pruebas de la funcionalidad, ■■ Gestión Técnica está involucrada en los procesos
rendimiento y capacidad de gestión de servicios de TI. de Mejora Continua del Servicio, particularmente
■■ Gestión de proveedores. Muchos departamentos a la hora de identificar oportunidades de mejora
o grupos de Gestión Técnica son los únicos que y posteriormente ayudar a evaluar soluciones
conocen exactamente lo que se requiere de un alternativas.
proveedor y cómo medirlos y gestionarlos. Por ■■ Como un custodio de experiencia y conocimiento
esta razón, muchas organizaciones confían en técnicos, Gestión Técnica garantiza que toda la
departamentos de Gestión Técnica para gestionar documentación operativa y del sistema se actualice
contratos con proveedores de CI específicos. Si éste y utilice adecuadamente. Esto incluye garantizar que
fuera el caso, será importante garantizar que estas todos los manuales de gestión, administración y del
relaciones se gestionen como parte del proceso de usuario estén actualizados y completos, y que el
SLM. personal técnico esté familiarizado con sus contenidos.
■■ Definición y gestión de estándares y herramientas ■■ Actualización y mantenimiento de datos usados para
de Gestión de Eventos. Gestión Técnica también informar sobre las capacidades técnicas y del servicio,
monitorizará y responderá ante muchas categorías de p. ej., Gestión del Rendimiento y de Capacidad,
eventos. Gestión de la Disponibilidad, Gestión de Problemas,
■■ Los departamentos y grupos de Gestión Técnica etc.
forman parte del proceso de Gestión de Incidencias. ■■ Ayudar a Gestión Financiera de TI a identificar el coste
Reciben incidencias a través del Escalado Funcional de la tecnología y de los recursos humanos de TI
y proporcionan soporte de segundo nivel y niveles usados para gestionar servicios de TI.
posteriores. También están implicados en el ■■ Implicación en la definición de actividades operativas
mantenimiento de categorías y a la hora de definir realizadas como parte de Gestión de Operaciones
los procedimientos de escalado que se ejecutan en de TI. Muchos departamentos, grupos o equipos de
Gestión de Incidencias. Gestión Técnica, también realizan las actividades
■■ Gestión Técnica como una función, proporciona operativas como parte de la función de Gestión de
los recursos que ejecutan el proceso de Gestión de Operaciones de TI de una organización.
Problemas. Se utilizará su conocimiento y experiencia
técnica para diagnosticar y resolver problemas. 6.3.4 Organización de Gestión Técnica
También se utilizará su relación con los proveedores Normalmente Gestión Técnica no se proporciona
para escalar y hacer el seguimiento de los equipos de por un único departamento o grupo. Será necesario
soporte de proveedores. que uno o más equipos o departamentos de Soporte
■■ Los recursos de Gestión Técnica se implicarán a Técnico proporcionen gestión y soporte técnico para la
la hora de definir sistemas de codificación que se Infraestructura de TI. En todas las organizaciones, excepto
utilizan en Gestión de Problemas e Incidencias (p. ej., las más pequeñas, donde un único departamento o
Categorías de Incidencias). equipo combinado podría ser suficiente, serán necesarios
■■ Los recursos de Gestión Técnica se utilizan para dar equipos o departamentos independientes para cada tipo
soporte a Gestión de Problemas a la hora de validar y de infraestructura que se esté utilizando.
mantener la KEDB. Gestión de Operaciones de TI está formada por varias
■■ Gestión de Cambios se basa en el conocimiento y áreas tecnológicas. Cada una de éstas requiere un
experiencia técnicos para evaluar cambios, y muchos conjunto específico de habilidades para gestionar
de ellos serán realizados por Gestión Técnica. y operarla. Algunos conjuntos de habilidades están
■■ Las versiones normalmente se despliegan usando asociados y pueden realizarlos técnicos con conocimientos
recursos de Gestión Técnica. variados, mientras que otros son específicos a un
■■ Gestión Técnica proporcionará información y componente, sistema o plataforma.
mantendrá operativo el sistema de Gestión de
136 | Organización de la Operación del Servicio

El principal criterio de la estructura organizativa de En esta publicación, se ven como parte de la misma
Gestión Técnica es la especialización o división de tareas. función, pero muchas organizaciones los ven como dos
El principio consiste en que las personas se agrupen de equipos independientes o incluso como departamentos. El
acuerdo con sus conjuntos de habilidades técnicas, y que problema de esta visión es que un buen diseño necesita
estos conjuntos de habilidades estén determinados por la la entrada de las personas necesarias para gestionar la
tecnología que se necesita gestionar. solución, y una buena cooperación requiere la implicación
de las personas que diseñaron la solución.
Las Secciones 6.6 y 6.7 recogen con detalle los
aspectos organizativos de Gestión Técnica, pero esta Los problemas que se necesitan superar son similares a
lista proporciona algunos ejemplos de equipos y aquellos afrontados en la gestión del Ciclo de Vida de
departamentos típicos de Gestión Técnica: la Aplicación (vea la sección 6.5 para disponer de una
análisis más detallado). La solución incluirá los siguientes
■■ Equipo o departamento de mainframe – si la
elementos:
organización todavía estuviera usando uno o más
tipos de mainframes ■■ El personal de soporte debe implicarse durante el
■■ Equipo o departamento de servidores – con frecuencia diseño o arquitectura de una solución. El personal
divididos nuevamente por tipos de tecnologías (p. ej., de diseño deberá implicarse a la hora de establecer
servidor Unix, servidor Wintel) los objetivos de mantenimiento y resolver temas de
■■ Equipo o departamento de almacenamiento, soporte.
responsable de la gestión de todos los dispositivos y ■■ Un cambio es la forma de medir al personal de Diseño
medios de almacenamiento de datos y Soporte. Los diseñadores deberán mantenerse como
■■ Equipo o departamento de Soporte de Red, parcialmente responsables de los defectos de diseño
atendiendo las WAN/LAN internas de la organización y que generen interrupciones operativas. El personal
gestionando cualquier proveedor de red externo de soporte deberá mantenerse como parcialmente
■■ Equipo o departamento de ordenadores de escritorio, responsable de la contribución a la arquitectura
responsable de todos los equipos instalados técnica.
■■ Equipo o departamento de base de datos, responsable
de la creación, mantenimiento y soporte de las bases
6.3.6  Métricas de Gestión Técnica
de datos de la organización Las métricas para Gestión Técnica dependerán en gran
■■ Equipo o departamento de middleware, responsable medida de la tecnología que se esté gestionando, aunque
de la integración, prueba y mantenimiento de todo el algunas métricas genéricas incluirán:
middleware en uso en la organización ■■ Medida de las salidas acordadas. Éstas podrían
■■ Equipo o departamento de Servicio de Directorio, incluir:
responsable del mantenimiento del acceso y de ●● Contribución al logro del nivel de servicios para
los derechos de los elementos del servicio de la el negocio. Aunque muchos de estos equipos de
infraestructura Gestión Técnica no estarán en contacto directo
■■ Equipo o departamento de Internet o Web, con el negocio, la tecnología que gestionan
responsable de la gestión de la disponibilidad y impactará en el mismo. Las métricas deberán
seguridad del acceso a los servidores y al contenido reflejar las contribuciones negativas (incidencias
por parte de clientes externos, usuarios y asociados escaladas a su equipo) y positivas (rendimiento y
■■ Equipo o departamento de Mensajes, responsable de disponibilidad del sistema)
los servicios de correo electrónico ●● Los ratios de transacción y de disponibilidad para
■■ Equipo o departamento de Telefonía sobre IP (p. ej., transacciones críticas del negocio
VoIP). ●● Formación del Centro de Servicio al Usuario
●● Registro de soluciones de problemas en la KEDB
6.3.5 Diseño Técnico y Soporte y ●● Evaluación de usuarios sobre la calidad de las
Mantenimiento Técnico salidas definidas en los SLA
Gestión Técnica está compuesta por diseñadores y ●● Instalación y configuración de componentes bajo
arquitectos técnicos especialistas (que se ven implicados su control.
principalmente durante Diseño del Servicio) y por personal ■■ Métricas de proceso. Los equipos de Gestión Técnica
especialista de soporte y mantenimiento (que se ven ejecutan muchas actividades de procesos de Gestión
implicados principalmente durante Operación del Servicio). del Servicio. Su disponibilidad para hacerlo se medirá
 Organización de la Operación del Servicio | 137

como parte de las métricas del proceso si fuera ■■ Formación y desarrollo de habilidades. Estas
pertinente (vea la sección sobre cada proceso para métricas garantizan que el personal tenga las
disponer de más detalles). Algunos ejemplos incluyen: habilidades y formación necesarias para gestionar
●● Tiempo de respuesta para eventos y tasas de la tecnología que se encuentre bajo su control, y
finalización también identificarán áreas en las que aún se requiera
●● Tiempos de resolución de incidencias para soporte formación.
de segunda y tercera línea
●● Estadísticas de resolución de problemas 6.3.7 Documentación de Gestión Técnica
●● Número de escalados y razones de los mismos Gestión Técnica está implicada en la redacción y
●● Número de cambios implementados y rechazados mantenimiento de diversos documentos como parte
de otros procesos (p. ej., Planificación de la Capacidad,
●● Número de cambios sin autorización detectados
Gestión de Cambios, Gestión de Problemas, etc.).
●● Número de versiones desplegadas, totales y
Estos documentos se analizan con más detalle en las
exitosas
descripciones pertinentes del proceso.
●● Problemas de seguridad detectados y resueltos
●● Utilización real del sistema con respecto a Sin embargo, existen algunos documentos que son
previsiones del Plan de Capacidad (si el equipo ha específicos para grupos o equipos de Gestión Técnica
contribuido al desarrollo del plan) que documentarán la gestión y control de documentos
asociados con la tecnología bajo su control. La
●● Seguimiento en relación con los SIP
documentación de Gestión Técnica incluye lo siguiente.
●● Gasto en relación con el presupuesto.
■■ Rendimiento de la tecnología. Estas métricas se
6.3.7.1  Documentación técnica
basan en especificaciones de Diseño del Servicio y en
estándares de rendimiento técnico establecidos por Gestión Técnica será responsable del aprovisionamiento y
proveedores, y que normalmente se encontrarán en mantenimiento de la documentación técnica para todos
OLAs o en Procedimientos de Operación Estándar. los CI. Incluye:
Las métricas reales variarán según la tecnología, pero ■■ Manuales técnicos
probablemente incluirán: ■■ Manuales de gestión y administración
●● Tasas de utilización (p. ej., memoria o procesador ■■ Manuales de usuario para CIs. Éstos típicamente
para servidores, ancho de banda para redes, etc.) excluirán manuales de usuario de aplicaciones que
●● Disponibilidad (de sistemas, red, dispositivos, mantendrá Gestión de Aplicaciones.
etc.), que será útil para medir el rendimiento de
sistemas y equipos, pero no se confundirá con 6.3.7.2  Planificaciones de Mantenimiento
Disponibilidad del Servicio, ya que para esto se Estas planificaciones se definen y acuerdan durante la
requiere la capacidad de medir la disponibilidad fase de Diseño del Servicio asociada a la Gestión de la
general del servicio y podría usar las cifras de Disponibilidad y de la Capacidad, pero principalmente son
disponibilidad para un número de sistemas o de propiedad de los diferentes departamentos, grupos o
componentes individuales equipos de Gestión Técnica. Esto se debe a que tienen la
●● Rendimiento (p. ej., tiempos de respuesta, tasas de experiencia técnica con respecto a tecnologías específicas
colas, etc.). y es más probable que conozcan lo que se requiere para
■■ Tiempo Medio Entre Fallos (MTBF) de equipos mantenerlas en perfecto funcionamiento.
específicos. Esta métrica se utiliza para garantizar que
Para disponer de más detalles sobre la definición de
se tomen buenas decisiones de compra y, cuando
Planificaciones de Mantenimiento y sobre Objetivos del
se compara con planificaciones de mantenimiento,
Mantenimiento de los Servicios, consulte la publicación
analizar si los equipos se están manteniendo
Diseño del Servicio de ITIL.
adecuadamente
■■ Medida de la actividad de mantenimiento,
6.3.7.3  Inventario de Habilidades
incluyendo:
Un Inventario de Habilidades es un sistema o herramienta
●● Mantenimiento realizado según la planificación
que identifica las habilidades requeridas para entregar
●● Número de ventanas de mantenimiento superadas
y apoyar los servicios de TI de soporte, y también a los
●● Objetivos de mantenimiento alcanzados (número y
individuos que poseen esas habilidades. Los Inventarios de
porcentaje).
138 | Organización de la Operación del Servicio

Habilidades son más eficaces si se alinean con procesos, ■■ El valor generado debe superar el coste de la inversión
arquitecturas y estándares de rendimiento. y todos los demás gastos generales organizativos
(como por ejemplo costes de gestión y marketing) si
Por otra parte, los Inventarios de Habilidades deberán
el negocio tuviera éxito.
identificar la formación disponible para desarrollar cada
habilidad si el personal existente dejara la organización. De forma similar, Gestión de Operaciones de TI puede
definirse como la función responsable de la gestión y
Los Inventarios de Habilidades también se pueden usar
mantenimiento continua de la Infraestructura de TI de una
como parte del Portfolio de Servicios si un nuevo servicio
organización para asegurar la entrega del nivel acordado
pudiera entregarse con el personal y los conjuntos
de los servicios de TI para el negocio.
de habilidades existentes, o si se necesitara hacer
una inversión en nuevo personal o formación. Por lo Operaciones de TI se puede definir como el conjunto de
tanto, los Inventarios de Habilidades pueden contribuir actividades implicadas en el funcionamiento diario de la
significativamente a la Planificación de la Capacidad. Infraestructura de TI para el propósito de la provisión de
servicios de TI a los niveles acordados para cumplir los
La definición y mantenimiento de Inventarios de
objetivos de negocio establecidos.
Habilidades requieren una buena interfaz con procesos y
herramientas de Recursos Humanos de la organización.
6.4.1 Rol de Gestión de Operaciones de TI
El rol de Gestión de Operaciones es el de ejecutar las
6.4  Gestión de Operaciones de TI actividades y procedimientos continuos requeridos para
En el negocio, el término ’Gestión de Operaciones’ se gestionar y mantener la Infraestructura de TI para entregar
utiliza para indicar el departamento, grupo o equipo de y dar soporte a Servicios de TI a los niveles acordados.
personas responsables de realizar la organización de las Éstos ya se han descrito en la sección 5, pero se resumen
actividades operativas diarias de la organización, como por aquí para completar la información:
ejemplo poner en funcionamiento la línea de producción ■■ Control de Operaciones, que supervisa la ejecución y
en un entorno de fabricación o gestionar los centros de monitorización de las actividades y eventos operativos
distribución y los movimientos de la flota dentro de una en la Infraestructura de TI. Esto se puede hacer con
organización logística. la ayuda de un Puente de Operaciones o un Centro
Gestión de Operaciones generalmente tiene las siguientes de Operaciones de Red. Además de ejecutar tareas
características: rutinarias desde todas las áreas técnicas, Control de
Operaciones también realiza las siguientes tareas
■■ Existe alguna forma de asegurar que un dispositivo,
específicas:
sistema o proceso está funcionando o trabajando
●● Gestión de Consolas, que hace referencia a
realmente (a diferencia de estrategia o planificación)
la definición de la capacidad de observación y
■■ Aquí es donde los planes se convierten en acciones
monitorización central y al uso de esas consolas
■■ El enfoque se centra en actividades diarias o a corto para realizar actividades de monitorización y
plazo, aunque debe tenerse en cuenta que estas control
actividades generalmente se realizarán y repetirán
●● Planificación de Trabajos, o la gestión de scripts
durante un periodo relativamente amplio (a diferencia
o jobs por lotes rutinarios
de las actividades de proyectos extraordinarios)
●● Backup y Restauración en nombre de todos los
■■ Estas actividades las realiza personal técnico
equipos y departamentos de Gestión Técnica y de
especializado, que con frecuencia tiene que recibir
Aplicaciones y con frecuencia en nombre de los
formación técnica para aprender cómo realizar cada
usuarios
actividad
●● Gestión de la impresión y de la salida para
■■ Existe un enfoque sobre la generación de acciones
el cotejo y distribución de toda la impresión
repetibles y consistentes que, si se repitieran con
centralizada o salida electrónica
suficiente frecuencia al nivel correcto de calidad,
●● Rendimiento de las actividades de
garantizarán el éxito de la operación
mantenimiento en nombre de los equipos
■■ Aquí es donde se provee y se mide el valor real de la
y departamentos de Gestión Técnica o de
organización
Aplicaciones.
■■ Existe una dependencia con respecto a la inversión en
■■ Gestión de las Instalaciones, que hace referencia
equipos o en recursos humanos, o en ambos
a la gestión del entorno físico de TI, típicamente un
 Organización de la Operación del Servicio | 139

Centro de Proceso de Datos o salas de ordenadores ■■ Un conjunto claramente diferenciado de métricas para
y emplazamientos de recuperación con todos los informar al negocio sobre el logro de los objetivos del
equipos de alimentación y refrigeración. Gestión de Servicio; y para informar a los directores de TI sobre la
las Instalaciones también incluye la coordinación eficiencia y eficacia de Operaciones de TI
de proyectos de consolidación a gran escala, p. ■■ Todo el personal de Operaciones de TI entiende
ej., consolidación del Centro de Proceso de Datos exactamente cómo el rendimiento de la tecnología
o proyectos de consolidación de servidores. En afecta a la entrega de los servicios de TI
algunos casos, la gestión de un centro de proceso ■■ Una estrategia de costes para equilibrar los requisitos
de datos se externaliza, en cuyo caso Gestión de las de diferentes unidades de negocio con el ahorro
Instalaciones hace referencia a la gestión del contrato de costes disponible a través de la optimización de
de externalización. la tecnología existente o de la inversión en nuevas
Al igual que con muchos procesos y funciones de tecnologías
Gestión del Servicio de TI, Gestión de Operaciones de TI ■■ Un valor, más que el coste, basado en la estrategia del
desempeña un rol doble. Retorno de la Inversión.
■■ Gestión de Operaciones de TI es responsable
6.4.2 Objetivos de Gestión de Operaciones
de ejecutar las actividades y los estándares de
rendimiento definidos durante Diseño del Servicio de TI
y probados durante Transición del Servicio. En Los objetivos de Gestión de Operaciones de TI incluyen:
este sentido, el rol de Operaciones de TI será ■■ Mantenimiento del status quo para lograr estabilidad
principalmente el de mantener el status quo. La de los procesos y actividades diarias de la
estabilidad de la infraestructura de TI y la consistencia organización
de los Servicios de TI es la preocupación principal ■■ Escrutinio regular y mejoras para lograr la mejora
de Operaciones de TI. Aún así, las mejoras operativas
del servicio con costes reducidos, a la vez que se
tienen como meta encontrar formas más simples y
mantiene la estabilidad
más adecuadas de hacer la misma cosa.
■■ La rápida aplicación de capacidades operativas para
■■ Al mismo tiempo, Operaciones de TI forma parte
diagnosticar y resolver fallos operativos de TI que se
del proceso de añadir valor a las diferentes líneas
produzcan.
de negocio y dar soporte a la red de valor (vea
la publicación Estrategia del Servicio de ITIL). La
6.4.3 Organización de Gestión de
capacidad del negocio para cumplir sus objetivos y
para seguir siendo competitivo depende de la salida
Operaciones de TI
y fiabilidad de la operación diaria de TI. Propiamente La Figura 6.1 de la introducción del Capítulo 6 mostró que
dicho, Gestión de Operaciones de TI debe poder Gestión de Operaciones de TI se ve como una función de
adaptarse continuamente a los requisitos y demanda pleno derecho pero que, en muchos casos, el personal de
del negocio. El Negocio no se preocupa de que los grupos de Gestión Técnica y de Aplicaciones forman
Operaciones de TI obedezca un procedimiento parte de esta función.
estándar o que un servidor tenga un rendimiento Esto significa que algunos departamentos y grupos de
óptimo. Como la demanda y los requisitos de negocio Gestión Técnica y de Aplicaciones gestionarán y ejecutarán
son cambiantes, Gestión de Operaciones de TI deberá sus propias actividades operativas. Otros delegarán estas
tener la capacidad de mantener su ritmo de cambio, actividades a un departamento de Operaciones de TI
que a menudo desafía el status quo. dedicado.
Operaciones de TI debe lograr un balance entre estos No hay un único método para asignar actividades,
roles, lo cual requerirá lo siguiente: ya que dependerá de la madurez y estabilidad de la
■■ Entender cómo se utiliza la tecnología para proveer infraestructura que se está gestionando. Por ejemplo, las
servicios de TI áreas de Gestión Técnica y de Aplicaciones que fueran
■■ Entender la importancia relativa y el impacto de esos claramente nuevas e inestables, tienden a gestionar sus
servicios en el negocio propias operaciones. Los grupos donde la tecnología
o aplicación fuera estable, la madurez y el buen
■■ Procedimientos y manuales que contengan el rol de
entendimiento tenderán más a tener estandarizadas sus
Operaciones de TI en la gestión de la tecnología y en
la entrega de servicios de TI
140 | Organización de la Operación del Servicio

operaciones y por lo tanto se sentirán más cómodos a la ●● Costes comparados con presupuesto asociado con
hora de delegar estas actividades. el mantenimiento, construcción, seguridad, envío,
etc.
En la sección 6.7 de esta publicación se analizarán con
detalle algunas opciones para estructurar Operaciones de ●● Incidencias asociadas con el edificio, p. ej.,
TI. reparaciones necesarias en las instalaciones
●● Informes sobre el acceso a las instalaciones
6.4.4  Métricas de Gestión de Operaciones ●● Número de eventos de seguridad e Incidencias y
de TI su resolución
●● Estadísticas de uso, especialmente cuando se
Gestión de Operaciones de TI se mide en términos de
asocian con los cambios en las estrategias de
la ejecución eficaz de sus actividades y procedimientos
configuración y acondicionamiento del entorno
especificados, además de por la ejecución de sus
actividades de proceso. A continuación se muestran los ●● Eventos o incidencias asociadas con el envío y
siguientes ejemplos: distribución.

■■ Ejecución exitosa de los trabajos planificados 6.4.5 Documentación de Gestión de

■■ Número de excepciones con respecto a las actividades
Operaciones de TI
y trabajos planificados
Durante Gestión de Operaciones de TI se generan y usan
■■ Número de datos o restauraciones requeridas del
varios documentos. Esta lista representa un resumen de
sistema
algunos de los más importantes y no incluye informes que
■■ Estadísticas de instalación de equipos, incluyendo
genera Gestión de Operaciones de TI en nombre de otros
el número de elementos instalados por tipo, procesos o funciones.
instalaciones exitosas, etc.
■■ Métricas de proceso. Gestión de Operaciones de TI 6.4.5.1  Procedimientos de Operación Estándar
ejecuta muchas actividades de proceso de Gestión
Los SOP se corresponden con un conjunto de documentos
del Servicio. Su disponibilidad para hacerlo se medirá
que contienen instrucciones detalladas y planificaciones
como parte de las métricas de proceso si fuera
de actividades para todos los equipos, departamentos y
pertinente (vea la sección sobre cada proceso para
grupos de Gestión de Operaciones de TI.
disponer de más detalles). Algunos ejemplos incluyen:
●● Tiempo de respuesta a eventos Estos documentos representan el trabajo rutinario que
●● Tiempos de resolución de incidencias es necesario realizar para cada dispositivo, sistema o
procedimiento. También describen los procedimientos a
●● Número de incidencias asociadas con la seguridad
seguir si se detectara una excepción o si se requiriera un
●● Número de escalados y razones para esos
cambio.
escalados
●● Número de cambios implementados y rechazados Los documentos SOP también se podrían usar para
●● Número de cambios sin autorización detectados definir niveles estándar de rendimiento para dispositivos
y procedimientos. En algunas organizaciones, los
●● Número de versiones desplegadas, totales y
documentos SOP se hacen referencia en el OLA. En lugar
exitosas
de listar medidas detalladas de rendimiento en el OLA, se
●● Seguimiento en relación con los SIP
inserta una cláusula para hacer referencia a los estándares
●● Gasto en relación con el presupuesto.
de rendimiento en el SOP y cómo éstos se medirán y se
■■ Si se hubieran delegado las actividades de informará sobre ellos.
mantenimiento, entonces las métricas asociadas con
estas actividades también serán apropiadas para: 6.4.5.2  Registros de Operaciones
●● Mantenimiento realizado según la planificación
Cualquier actividad que se realice como parte de
●● Número de ventanas de mantenimiento superadas Operaciones de TI deberá registrarse por varias razones,
●● Objetivos de mantenimiento alcanzados (número y entre las que se incluyen:
porcentaje).
■■ Éstos se pueden usar para confirmar que se hayan
■■ Las métricas asociadas con Gestión de las Instalaciones
completado satisfactoriamente trabajos o actividades
son amplias, pero incluyen típicamente:
específicos
 Organización de la Operación del Servicio | 141

■■ Se pueden usar para confirmar que un servicio de TI brevemente con una referencia a la sección o página del
se entregó y aceptó SOP.
■■ Pueden usar Gestión de Problemas para buscar la
La mayoría de las Planificaciones de Turnos tienen
causa raíz de incidencias la forma de una lista de comprobación en la que los
■■ Forman la base para informes sobre el rendimiento operadores pueden marcar el elemento cuando éste se
de los equipos y departamentos de Gestión de complete, junto con el tiempo de finalización. Esto facilita
Operaciones de TI. ver el progreso de las actividades y también ayuda a
El formato de estos registros es tan variado como el identificar cualquier problema potencial en caso de que
número de sistemas y equipos o departamentos de los trabajos tarden demasiado.
Gestión de Operaciones. A continuación se incluyen los Los Informes de Turnos son una forma de Registro de
siguientes ejemplos de Registros de Operaciones: Operaciones, pero tienen funciones adicionales como las
■■ Registros del Sistema Operativo almacenados en cada siguientes:
dispositivo ■■ Registrar eventos y acciones importantes que se
■■ Registros de Actividades de Aplicaciones almacenados produzcan durante el turno
en un archivo en el servidor de aplicaciones ■■ Formar parte del traspaso entre responsables del turno
■■ Registros de eventos almacenados en el servidor de ■■ Informar de cualquier excepción con respecto a los
herramientas de monitorización Objetivos de Mantenimiento de Servicios
■■ Registros de utilización para dispositivos clave ■■ Identificar cualquier actividad incompleta que pudiera
■■ Registros de acceso físico que registran cuándo y degradar el rendimiento en algún servicio durante las
quién accedió a edificios seguros horas de servicio posteriores.
■■ Registros escritos a mano de acciones realizadas por
operadores. Esto debe hacerse en una carpeta o libro 6.4.5.4  Planificación de Operaciones
de registro formal, numerado o almacenado en un Las Planificaciones de Operaciones son similares a las
entorno seguro. Las comprobaciones deberán asegurar Planificaciones de Turnos pero cubren todos los aspectos
que no se eliminen las páginas. de Operaciones de TI a un alto nivel. Esta planificación
Se necesitará establecer una política como parte de incluirá una descripción general de todos los cambios,
los SOP para establecer cuánto tiempo se tendrán que mantenimiento, trabajos rutinarios y trabajo adicional
guardar los registros, cómo se archivan y cuándo se planificados, junto con información sobre los próximos
pueden eliminar. Estas políticas tendrán en cuenta los eventos del negocio y del proveedor. La Planificación de
requisitos reglamentarios y de cumplimiento. Las políticas Operaciones se utiliza como la base para la Reunión Diaria
también deberán especificar los parámetros para las de Operaciones y es la referencia principal para todos los
estrategias adecuadas de almacenamiento y backup para responsables de Operaciones de TI a la hora de hacer el
almacenar y recuperar archivos de registro. seguimiento del progreso y detectar excepciones.

6.4.5.3  Informes y Planificaciones de Turnos 6.5  Gestión de Aplicaciones

Las Planificaciones de Turnos son documentos que
Gestión de Aplicaciones será responsable de gestionar
describen las actividades exactas que es necesario llevar
Aplicaciones a lo largo de su ciclo de vida. La Función
a cabo durante el turno. También listarán todas las
de Gestión de Aplicaciones se realiza a través de algún
dependencias y secuencias de actividades. Probablemente
departamento, grupo o equipo implicado en la gestión y
habrá más de una Planificación de Turnos, en la que
soporte de aplicaciones operativas. Esta función también
cada equipo tendrá una versión para sus propios
desempeña un rol importante en el diseño, prueba y
sistemas. Es importante que todas las planificaciones se
mejora de aplicaciones que forman parte de los servicios
coordinen antes de comenzar el turno. Normalmente
de TI. Como tal, podría estar implicada en proyectos de
esta planificación la realizará una persona que esté
desarrollo, pero normalmente no es lo mismo que los
especializada en Planificación de Turnos con la ayuda de
equipos de Desarrollo de Aplicaciones.
herramientas de planificación.
Una Planificación de Turnos podría consistir en varios 6.5.1 Rol de Gestión de Aplicaciones
elementos rutinarios que se incluyen en el SOP. En Gestión de Aplicaciones es para las aplicaciones lo que
este caso, los elementos simplemente podrían listarse Gestión Técnica es para la Infraestructura de TI. Gestión de
142 | Organización de la Operación del Servicio

Aplicaciones desempeña un rol en todas las aplicaciones, 6.5.2 Objetivos de Gestión de Aplicaciones

ya se compren o se desarrollen internamente. Una de Los objetivos de Gestión de Aplicaciones consisten en
las decisiones clave a la que contribuye es la decisión de dar soporte a los procesos de negocio de la organización
comprar una aplicación o construirla (esto se analiza con ayudando a identificar requisitos funcionales y de
detalle en la publicación Diseño del Servicio). Una vez capacidad de gestión para el software de aplicación, y a
tomada la decisión, Gestión de Aplicaciones desempeñará continuación ayudar en el diseño y despliegue de esas
un doble rol: aplicaciones y en el soporte y mejora continua de las
■■ Es el custodio del conocimiento y de la experiencia mismas.
técnica asociada con la gestión de las aplicaciones. En Estos objetivos se logran a través de:
este rol, Gestión de Aplicaciones, colaborando junto
con Gestión Técnica, garantiza que el conocimiento ■■ Aplicaciones que estén adecuadamente diseñadas y
requerido para que el diseño, prueba, gestión sean fiables y rentables
y mejora de los servicios de TI se identifiquen, ■■ Garantizar que la funcionalidad requerida esté
desarrollen y definan. disponible para lograr el resultado de negocio
■■ Proporciona los recursos reales para apoyar el Ciclo requerido
de Vida de ITSM. En este rol, Gestión de Aplicaciones ■■ Organización de las capacidades técnicas adecuadas
garantiza que los recursos se formen y se desplieguen para mantener las aplicaciones en condiciones óptimas
eficazmente para diseñar, construir, realizar la ■■ Uso rápido de habilidades técnicas para acelerar el
transición, operar y mejorar la tecnología requerida diagnóstico y resolver cualquier fallo técnico que se
para entregar y apoyar servicios de TI. produzca.
Con estos dos roles, Gestión de Aplicaciones podrá
garantizar que la organización tenga acceso al tipo
6.5.3  Principios de Gestión de Aplicaciones
correcto de nivel de recursos humanos para gestionar
6.5.3.1  ¿Construir o comprar?
las aplicaciones y, por lo tanto, cumplir los objetivos de
Una de las decisiones clave de Gestión de Aplicaciones es
negocio. Esto comienza con Estrategia del Servicio, se
comprar una aplicación que dé soporte a la funcionalidad
amplía en Diseño del Servicio, se prueba en Transición del
requerida, o construir la aplicación específicamente
Servicio y se perfecciona en Mejora Continua del Servicio
para los requisitos de la organización. Estas decisiones
(vea las demás publicaciones de ITIL de esta serie).
a menudo las toma el Chief Technical Officer (CTO) o el
Parte de este rol consiste en garantizar un equilibrio entre Comité Ejecutivo, pero dependerán de la información
el nivel de habilidad y el coste de estos recursos. proporcionada por varias fuentes. Esto se analiza con
Adicionalmente a estos dos roles de alto nivel, Gestión de detalle en Diseño del Servicio, pero se resumen aquí desde
Aplicaciones también lleva a cabo los dos siguientes roles una perspectiva funcional de Gestión de Aplicaciones.
específicos: Gestión de Aplicaciones ayudará a tomar esta decisión
■■ Guiar a Operaciones de TI sobre la mejor forma durante Diseño del Servicio de la siguiente forma:
de realizar la gestión operativa continua de las ■■ Dimensionamiento de la aplicación y previsiones de la
aplicaciones. Este rol se lleva a cabo parcialmente carga de trabajo (vea la sección 4.6.4)
durante el proceso de Diseño del Servicio, pero ■■ Especificación de los requisitos de capacidad de
también como parte de la comunicación diaria con gestión
Gestión de Operaciones de TI, ya que se busca lograr ■■ Identificación de los costes operativos existentes
una estabilidad y rendimiento óptimos.
■■ Requisitos de acceso de datos para informar o para la
■■ La integración del Ciclo de Vida de Gestión de
integración en otras aplicaciones
Aplicaciones en el Ciclo de Vida de ITSM. Esto se
■■ Investigación de la amplitud que se puede lograr con
analiza más adelante.
la funcionalidad requerida mediante las herramientas
A continuación se analizan los objetivos, actividades existentes, y el grado de adaptación que se requerirá
y estructuras que permiten a Gestión de Aplicaciones para lograrlo
realizar estos roles de forma eficaz. ■■ Estimación del coste de la adaptación
■■ Identificación de las habilidades que se requerirán
para dar soporte a la solución (p. ej., si se compra
una aplicación, ¿se requerirá un nuevo conjunto
 Organización de la Operación del Servicio | 143

de empleados, o se podrá formar a los empleados implicación en el diseño, construcción, prueba, despliegue
existentes para dar soporte a esta aplicación?) y soporte de las aplicaciones. Ejemplos de estos métodos
■■ Requisitos de administración son Método de Análisis y Diseño de Sistemas Estructurados
■■ Requisitos de seguridad. (SSADM), Método de Desarrollo de Sistemas Dinámicos
(DSDM), Desarrollo Rápido de Aplicaciones (RAD), etc.
Si la decisión fuera construir la aplicación, se necesitaría
tomar una decisión posterior sobre si el desarrollo se ITIL está principalmente interesado en la gestión
externalizará o se construirá empleando a los propios global de aplicaciones como parte de Servicios de TI,
empleados. Esto se detalla en las publicaciones Estrategia independientemente de que se hayan desarrollado
del Servicio y Diseño del Servicio, pero existen algunas internamente o hayan sido adquiridas a un tercero. Por
consideraciones importantes que afectan a Operación del esta razón, se ha utilizado el término Ciclo de Vida de
Servicio, por ejemplo: Gestión de Aplicaciones debido a que implica una misión
más integral.
■■ ¿Cómo se especificarán y acordarán los requisitos de
capacidad de gestión (p. ej., aplicación del diseño y Esto no debería sustituir el SDLC, que todavía es
monitorización de la transacción)? Éstos se omiten un método válido que utilizan los desarrolladores,
algunas veces cuando los equipos o departamentos especialmente en empresas de software. Sin embargo,
operativos no están presentes en el proyecto esto no significa que debiera haber un mayor alineamiento
■■ ¿Cuáles son los Criterios de Aceptación para el entre la visión del desarrollo de las aplicaciones y la
rendimiento operativo; cómo y dónde se probará la gestión ’activa’ de esas aplicaciones.
solución y quién realizará las pruebas? Esto es más difícil en aplicaciones compradas a gran
■■ ¿Quién poseerá y gestionará la Biblioteca Definitiva escala, como por ejemplo correo electrónico, ya que los
para esa aplicación? desarrolladores no interactúan normalmente de forma
■■ ¿Quién diseñará y mantendrá la gestión operativa y individual con los usuarios de sus aplicaciones. Sin
los scripts de administración para estas aplicaciones? embargo, el ciclo de vida básico todavía se mantiene
■■ ¿Quién será responsable de la configuración del fielmente en los requisitos, diseño, personalización,
entorno y de la propiedad y mantenimiento de los operación y despliegue de la aplicación. La optimización
diferentes componentes de la infraestructura? se logra a través de una mejor gestión, de las mejoras en
■■ ¿Cómo se instrumentará la solución para que sea la personalización y en las actualizaciones.
capaz de generar los eventos requeridos? El Ciclo de Vida de Gestión de Aplicaciones se ilustra en la
siguiente figura:
6.5.3.2  Modelos Operativos
Un Modelo Operativo es la especificación del entorno
Requisitos
operativo en el que se ejecutará eventualmente la aplicación
cuando pase a estar activa. Esto se usará durante las fases
de prueba y transición para simular y evaluar el entorno
activo. Esta es una forma de asegurar que la aplicación
pueda dimensionarse correctamente y se pueda documentar
y entender perfectamente las condiciones requeridas del Optimizar Diseñar
entorno. El Modelo Operativo deberá definirse y usarse en la
prueba durante las fases de Diseño del Servicio y Transición
del Servicio respectivamente (vea las publicaciones Diseño
del Servicio y Transición del Servicio).
Operar Crear
6.5.4 Ciclo de Vida de Gestión de
Aplicaciones
Se han utilizado muchos nombres para hacer referencia
al ciclo de vida seguido para desarrollar y gestionar las
aplicaciones, incluyendo Ciclo de Vida del Software (SLC), Desplegar
y Ciclo de Vida de Desarrollo del Software (SDLC). Los
equipos de Desarrollo de Aplicaciones y sus Gestores
de Proyectos los utilizan generalmente para definir su Figura 6.5 Ciclo de Vida de Gestión de Aplicaciones
144 | Organización de la Operación del Servicio

Los procesos de ITSM y los procesos de Desarrollo de

■■ Transición del Servicio: Los equipos de Gestión y
Aplicaciones tienen que alinearse como parte de la
Desarrollo de Aplicaciones están implicados en la
estrategia global de entrega de servicios de TI en el
prueba y validación de lo que se ha construido y
soporte del negocio.
desarrollado operativamente.
Desarrollo de Aplicaciones y Operaciones forman parte del ■■ Operación del Servicio: Cubre la fase Operación
mismo ciclo de vida general y ambos deberían implicarse del Ciclo de Vida de Gestión de Aplicaciones. Estos
en todas las etapas, aunque su nivel de implicación variará procesos y estructuras se analizan con detalle en
dependiendo de la etapa del ciclo de vida. esta publicación.
■■ Mejora Continua del Servicio: Cubre la fase
Relación entre los Ciclos de Vida de Gestión de Optimización del Ciclo de Vida de Gestión de
Aplicaciones y Gestión del Servicio Aplicaciones. Mejora Continua del Servicio mide
El Ciclo de Vida de Gestión de Operaciones no la calidad y relevancia de las aplicaciones en
debería verse como una alternativa al Ciclo de Vida operación, y proporciona recomendaciones sobre
de Gestión del Servicio. Las aplicaciones forman parte cómo mejorar las aplicaciones si hubiera un claro
de los servicios y tienen que gestionarse como tal. No Retorno de la Inversión para hacerlo.
obstante, las aplicaciones son una combinación única
de tecnología y funcionalidad, y requieren un enfoque 6.5.4.1  Requisitos
especializado en cada etapa del Ciclo de Vida de
Esta es la fase en la que se recopilarán los requisitos
Gestión del Servicio.
para una nueva aplicación basándose en las necesidades
Cada etapa del Ciclo de Vida de Gestión de de negocio de la organización. Esta fase estará activa
Aplicaciones tiene su propio conjunto específico principalmente durante la fase de Diseño del Servicio del
de objetivos, actividades, entregables y equipos Ciclo de Vida de ITSM.
dedicados. Cada etapa también tiene una
A continuación se indican los seis tipos de requisitos para
responsabilidad clara para asegurar que sus salidas se
cualquier aplicación, así se desarrollen a nivel interno, se
correspondan con los objetivos específicos del Ciclo de
externalicen o se compren:
Vida de Gestión del Servicio. En cada publicación de
ITIL se recogen con detalle los diferentes aspectos de ■■ Los requisitos funcionales son aquellos requeridos
Gestión de Aplicaciones: específicamente para dar soporte a una función de
negocio particular
■■ Estrategia del Servicio: Define la arquitectura
■■ Los requisitos de capacidad de gestión, vistos desde
general de las aplicaciones y de la infraestructura.
una perspectiva de Gestión del Servicio, abordan la
Esto incluirá la definición de los criterios para el
necesidad de un servicio con capacidad de respuesta,
desarrollo a nivel interno, para la externalización
disponible y seguro, y tratan con aquellos aspectos
del desarrollo, o la compra y personalización de
como el despliegue, operaciones, gestión del sistema
las aplicaciones. Estrategia del Servicio también
y seguridad
ayudará a definir el Portfolio de Servicios
(incluyendo aplicaciones) que también incluirá ■■ Los requisitos de usabilidad son aquellos que abordan
información sobre el Retorno de la Inversión las necesidades del usuario final, y dan como resultado
de las aplicaciones y de los servicios a los que funcionalidades del sistema que facilitan el uso
dan soporte. Por lo tanto, durante esta fase se ■■ Los requisitos estructurales, especialmente si
establecerán los requisitos de alto nivel. esto requiere un cambio en los estándares de la
■■ Diseño del Servicio: Ayuda a establecer los arquitectura existente
requisitos para la funcionalidad y capacidad de ■■ Requisitos de interfaz, donde existen dependencias
gestión de las aplicaciones y colabora con los entre las herramientas y aplicaciones existentes y la
equipos de Desarrollo para garantizar que se nueva aplicación
cumplan estos objetivos. Diseño del Servicio cubre ■■ Requisitos de Nivel de Servicio que especifican cómo
la mayor parte de la fase de Requisitos y se implica se llevará a cabo el servicio, la calidad de su salida
durante la fase de Construcción del Ciclo de Vida y cualquier otro aspecto cualitativo medido por el
de Gestión de Aplicaciones. usuario o cliente.
 Organización de la Operación del Servicio | 145

6.5.4.2 Diseñar Las pruebas son un componente integral de las fases

Esta es la fase en la que los requisitos se traducen en Construir y Desplegar, debido a que representan una
especificaciones. Diseñar incluye el diseño de la propia validación de la actividad y de la salida de dichas fases,
aplicación y el diseño del entorno, o el modelo operativo incluso si utilizara personal y entornos diferentes. La
sobre el que se tiene que ejecutar la aplicación. Las prueba en la fase Construir se centra en si la aplicación
consideraciones estructurales son los aspectos más cumple sus especificaciones de funcionalidad y capacidad
importantes de esta fase, ya que pueden impactar en la de gestión. A menudo la distinción se realiza entre un
estructura y en el contenido del modelo de aplicación entorno de desarrollo y prueba. El entorno de prueba
y operativo. Las consideraciones estructurales para la permite probar la combinación del modelo operativo
aplicación (diseño de la arquitectura de la aplicación) y las y de aplicación. La prueba se incluye en la publicación
consideraciones estructurales para el modelo de operación Transición del Servicio de ITIL.
(diseño de la arquitectura del sistema), están íntimamente En el caso del software comprado, esto implicará la
asociadas y es necesario alinearlas. adquisición real de la aplicación, cualquier middleware
En el caso de un software comprado, a la mayoría de las requerido, y el hardware y equipos de red asociados. Aquí
organizaciones no se les permitirá entrar directamente deberá hacerse cualquier personalización que se requiera,
en el diseño del software (que ya se ha construido). Sin además de la creación de tablas, categorías, etc. que sea
embargo, es importante que Gestión de Aplicaciones necesario utilizar. Esto se realiza en muchas ocasiones
sea capaz de proporcionar retroalimentación con el como una implementación piloto a través del equipo o
suministrador de software sobre la funcionalidad, departamento pertinente de Gestión de Aplicaciones.
capacidad de gestión y rendimiento del mismo. A su
vez, dicha información lo podrá utilizar el suministrador 6.5.4.4  Desplegar
del software como parte de la mejora continua de su En esta fase se despliegan tanto el modelo operativo
producto. como la aplicación. El modelo operativo se incorpora en
el entorno de TI existente y la aplicación se instala en la
Parte del proceso de evaluación general del software
parte superior del modelo operativo, usando el proceso
comprado deberá incluir una evaluación de si el
de Gestión de Versiones y Despliegues descrito en la
suministrador tiene capacidad de respuesta ante tal
publicación Transición del Servicio de ITIL.
retroalimentación. Al mismo tiempo, deberá garantizar
que haya un equilibrio entre tener capacidad de respuesta Las pruebas también tienen lugar durante esta fase,
y cambiar su software y el impacto negativo o cambio de aunque aquí el énfasis se pone en asegurar que el proceso
alguna funcionalidad básica. y los mecanismos de despliegue funcionen eficientemente,
p. ej., probar si la aplicación todavía funciona según la
Diseñar para el software comprado también incluirá el
especificación después de que se haya descargado e
diseño de cualquier personalización que se requiera. Aquí
instalado. Esto se conoce como Soporte Post-Implantación
tendrá una especial importancia realizar una valoración
y cubre un periodo de garantía predefinido para probar,
sobre si una futura versión de software permitirá la
validar y monitorizar una nueva aplicación o servicio
personalización.
durante dicho periodo. Soporte Post-Implantación
se recoge con detalle en la publicación Transición del
6.5.4.3  Construir
Servicio.
En esta fase, tanto la aplicación como el modelo
operativo se ponen a disposición para el despliegue. Los 6.5.4.5  Operar
componentes de la aplicación se codifican o adquieren,
En esta fase la organización de servicios de TI opera
integran y prueban.
la aplicación como parte de la entrega de un servicio
Tenga en cuenta que Probar no es una etapa requerido por el negocio. El rendimiento de la aplicación
independiente en el ciclo de vida, incluso si fuera una en relación con el servicio global se mide continuamente
actividad separada, o si las pruebas se realizaran con respecto a los Niveles de Servicio y a las directrices
independientemente de las actividades operativas y de clave de negocio. Es importante distinguir que las propias
desarrollo. Sin las fases Construir y Desplegar, no habría aplicaciones no equivalen a un servicio. En muchas
nada que probar y, sin las pruebas, no habría nada que organizaciones es muy común hacer referencia a las
controlar sobre lo que se ha desarrollado o desplegado. aplicaciones como ’servicios’; sin embargo, las aplicaciones
no son sino un componente de otros muchos necesarios
para proveer un servicio de negocio.
146 | Organización de la Operación del Servicio

La fase Operar no es exclusiva de las aplicaciones y se de una fase podría rebajar el nivel de optimización del
analiza en toda esta publicación, presentándose una lista conjunto.
más detallada de actividades en la sección 6.5.5 más
adelante. 6.5.5  Actividades genéricas de Gestión de
Aplicaciones
6.5.4.6  Optimizar Aunque la mayoría de los equipos y departamentos
En la fase Optimizar, los resultados de las medidas del de Gestión de Aplicaciones se dedican a aplicaciones
rendimiento de Nivel de Servicio se miden, analizan y se o conjuntos de aplicaciones específicas, existe un gran
ponen en práctica. Las posibles mejoras se analizan y se número de actividades que tienen en común. Estas
inician los desarrollos si es necesario. Las dos estrategias incluyen:
principales en esta fase son mantener y/o mejorar los
■■ Identificar el conocimiento y experiencia requeridos
Niveles de Servicio y disminuir los costes. Esto podría
para gestionar y operar aplicaciones en la entrega de
conducir a la reiteración en el ciclo de vida o a la retirada
los servicios de TI. Este proceso comienza durante la
justificada de una aplicación.
fase de Estrategia del Servicio, se amplía con detalle
Un aspecto importante a recordar sobre el Ciclo de en Diseño del Servicio, y se ejecuta en Operación del
Vida de Gestión de Aplicaciones es que, debido a que Servicio. La evaluación y actualización continuas de
es circular, la misma aplicación puede residir al mismo estas habilidades se realiza durante la Mejora Continua
tiempo en diferentes fases del ciclo de vida. Por ejemplo, del Servicio.
cuando se esté diseñando la siguiente versión de una ■■ Iniciar programas de formación para desarrollar y
aplicación y se esté desplegando la versión actual, la perfeccionar las habilidades en los recursos de Gestión
versión previa todavía podría estar en funcionamiento de Aplicaciones apropiados y mantener registros de
en algunas partes de una organización. Esto requiere formación para estos recursos.
obviamente una sólida versión, y control de configuración ■■ Contratación de recursos con habilidades que no se
y versiones. puedan desarrollar internamente, o si no hubieran
Las fases particulares podrían llevar tiempo o verse como suficientes personas para realizar las actividades
más importantes que otras, pero todas son cruciales. Cada requeridas de Gestión de Aplicaciones.
aplicación deberá pasar por todas ellas al menos una vez ■■ Diseño y provisión de formación para el usuario
y, debido a la naturaleza circular del ciclo de vida, pasará final. La formación puede proveerse y desarrollarse
por algunas etapas más de una vez. mediante los grupos de Desarrollo de Aplicaciones y
Gestión de Aplicaciones, o por terceros, pero Gestión
Este método también permite los métodos de desarrollo
de Aplicaciones es responsable de asegurar que la
iterativo, donde el software está continuamente en
formación se dirija como sea apropiado.
desarrollo en pasos incrementales. Cada paso sigue
el ciclo de vida y la aplicación se construye en etapas ■■ Internalizar actividades específicas si las habilidades
incrementales, usando las prioridades del negocio como requeridas no estuvieran disponibles internamente o
una directriz. en el mercado, o si fuera mucho más rentable hacerlo
de esa manera.
Una buena comunicación es clave a medida que una ■■ Definición de estándares usados en el diseño de
aplicación se desplaza a través de las fases del ciclo de
nuevas arquitecturas y participación en la definición
vida. Será fundamental que aquellos que manejen la
de arquitecturas de las aplicaciones durante los
aplicación en una fase de su existencia pasen información
procesos de Estrategia del Servicio.
de alta calidad a aquellos que la manejen en la siguiente
■■ Investigación y Desarrollo de soluciones que puedan
fase. También es importante que una organización
ayudar a ampliar el Portfolio de Servicios o que
monitorice la calidad del Ciclo de Vida de Gestión
se puedan utilizar para simplificar o automatizar
de Aplicaciones. Los cambios en el ciclo de vida, por
Operaciones de TI, reducir costes o incrementar los
ejemplo en la forma en la que una organización pasa
niveles de servicio de TI.
información entre las diferentes fases, afectarán a su
■■ Implicación en el diseño y construcción de nuevos
calidad. El entendimiento de las características de todas
servicios. Todos los equipos o departamentos de
las fases en el Ciclo de Vida de Gestión de Aplicaciones es
Gestión de Aplicaciones contribuirán al diseño de
crucial para mejorar la calidad del conjunto. Los métodos
estándares de Rendimiento y Arquitectura Técnica
y herramientas utilizados en una fase podrían tener un
para servicios de TI. Por otra parte, también serán
impacto en las demás, mientras que la optimización
responsables de especificar las actividades operativas
 Organización de la Operación del Servicio | 147

requeridas para gestionar las aplicaciones de forma validar y mantener la KEDB junto con los equipos de
continua. Desarrollo de Aplicaciones.
■■ Implicación en proyectos, no sólo durante el proceso ■■ Gestión de Cambios contará con el conocimiento y
de Diseño del Servicio, sino también para Mejora experiencia técnicos para evaluar cambios, y muchos
Continua del Servicio o para proyectos operativos de ellos serán realizados por los equipos de Gestión
como por ejemplo actualizaciones de Sistemas de Aplicaciones.
Operativos, proyectos de consolidación de servidores, ■■ El éxito de Gestión de la Entrega depende de la
o movimientos físicos. implicación del personal de Gestión de Aplicaciones.
■■ Diseño y realización de pruebas para la funcionalidad, De hecho, en muchas ocasiones son los impulsores
rendimiento y capacidad de gestión de los Servicios del proceso de Gestión de la Entrega para sus
de TI (teniendo en cuenta que las pruebas deberán aplicaciones.
controlarse y realizarse a través de un probador ■■ Gestión de Aplicaciones definirá, gestionará y
independiente – vea la publicación Transición del mantendrá los atributos y las relaciones de los CIs de
Servicio). la aplicación en el CMS.
■■ Gestión de la Disponibilidad y de Capacidad dependen ■■ Gestión de Aplicaciones se implica en los procesos
de Gestión de Aplicaciones a la hora de contribuir al de Mejora Continua del Servicio, particularmente
diseño de las aplicaciones para cumplir los niveles de a la hora de identificar oportunidades de mejora
servicio requeridos por el negocio. Esto significa que y posteriormente para ayudar a evaluar soluciones
el modelado y la previsión de la carga de trabajo a alternativas.
menudo se realizan junto con recursos de Gestión ■■ Gestión de Aplicaciones garantiza que toda la
Técnica y de Aplicaciones. documentación operativa y del sistema se actualice
■■ Colaboración a la hora de evaluar los riesgos, y se utilice adecuadamente. Esto incluye asegurar
identificando dependencias críticas del sistema y del que todos los manuales de diseño, gestión y de
servicio y definiendo e implementando contramedidas. usuarios estén actualizados y completos, y que el
■■ Gestión de proveedores. Muchos departamentos o personal y usuarios de Gestión de Aplicaciones estén
grupos de Gestión de Aplicaciones son los únicos familiarizados con sus contenidos.
que conocen exactamente lo que se requiere de un ■■ Colaboración con Gestión Técnica a la hora de llevar
proveedor y cómo medirlos y gestionarlos. Por esta a cabo el Análisis de Necesidades de Formación y de
razón, muchas organizaciones confían en Gestión de mantener los Inventarios de Habilidades.
Aplicaciones para gestionar contratos con proveedores ■■ Ayudar a Gestión Financiera de TI a identificar los
de aplicaciones específicas. Si éste fuera el caso, costes de la gestión continua de las aplicaciones.
será importante garantizar que estas relaciones se ■■ Implicación en la definición de actividades operativas
gestionen como parte del proceso de SLM. realizadas como parte de Gestión de Operaciones
■■ Implicación en la definición de los estándares de TI. Muchos departamentos, grupos o equipos
de Gestión de Eventos y especialmente en la de Gestión de Aplicaciones, también realizan las
instrumentación de aplicaciones para la generación de actividades operativas como parte de la función de
eventos significativos. Gestión de Operaciones de TI de una organización.
■■ Gestión de Aplicaciones como una función, ■■ Introducción y mantenimiento de las políticas de
proporciona los recursos que ejecutan el proceso de configuración de software.
Gestión de Problemas. Se utilizará su conocimiento ■■ Junto con los equipos de Desarrollo de Software,
y experiencia técnica para diagnosticar y resolver realizar la definición y mantenimiento de la
problemas. También se utilizará su relación con los documentación asociada con las aplicaciones.
proveedores para escalar y hacer el seguimiento Esta documentación incluirá manuales de usuario,
con equipos o departamentos de soporte de los manuales de administración y gestión, además de
proveedores. cualquier SOP requerido para gestionar aspectos
■■ Los recursos de Gestión de Aplicaciones se implicarán operativos de la aplicación.
a la hora de definir los sistemas de codificación a
emplear en Gestión de Problemas e Incidencias (p. ej., Los equipos y departamentos de Gestión de Aplicaciones
Categorías de Incidencias). serán necesarios para todas las aplicaciones clave. La
naturaleza exacta del rol variará dependiendo de las
■■ Los recursos de Gestión de Aplicaciones se utilizan
aplicaciones a las que se esté dando soporte, aunque las
para dar soporte a Gestión de Problemas a la hora de
responsabilidades genéricas probablemente incluirán:
148 | Organización de la Operación del Servicio

■■ Soporte de tercer nivel para incidencias asociadas a las cada uno de ellos afecta a la forma con la que una
aplicaciones cubiertas por ese equipo o departamento aplicación necesita ser gestionada y operada.
■■ Implicación en los planes de pruebas de operación y ■■ El tipo o marca de tecnología usada. Aplicaciones
en los aspectos del despliegue que tienen una funcionalidad similar, pueden operar
■■ Gestión de parches y seguimiento de fallos de de forma diferente en distintas bases de datos o
la aplicación (codificación de los arreglos para el plataformas. Estas diferencias tienen que entenderse
código interno, transportes/parches para el código de para gestionar la aplicación de forma eficaz.
terceros) Incluso si las actividades para gestionar estas aplicaciones
■■ Implicación en las cuestiones de capacidad de soporte fueran genéricas, la planificación específica de las mismas
y operación de la aplicación como por ejemplo diseño y la forma en la que se llevan a cabo serán diferentes.
de códigos, mensajes de error, vínculos de gestión de Por esta razón, los equipos y departamentos de Gestión
eventos de Aplicaciones tienden a organizarse de acuerdo con
■■ Dimensionamiento y rendimiento de la aplicación; las categorías de las aplicaciones a las que dan soporte.
métricas de volumen y pruebas de la carga, etc. Esto Ejemplos típicos de organizaciones de Gestión de
se encuentra en soporte de los procesos de Gestión Aplicaciones incluyen:
de la Disponibilidad y de Capacidad
■■ Aplicaciones financieras. En organizaciones grandes
■■ Implicación en el desarrollo de Políticas de Versiones
donde se utilizan varias aplicaciones diferentes para
■■ Identificación de mejoras en el software existente, los distintos aspectos de Gestión Financiera, podría
desde una perspectiva de funcionalidad y de haber varios departamentos, grupos o equipos que
capacidad de gestión. gestionaran estas aplicaciones, p. ej., Deudores y
Acreedores, Análisis de la Antigüedad de las Cuentas,
6.5.6 Organización de Gestión de Libro Mayor de las Cuentas, etc.
Aplicaciones ■■ Aplicaciones de mensajería y colaboración
Aunque todos los departamentos, grupos o equipos de ■■ Aplicaciones de RR.HH.
Gestión de Aplicaciones realizan actividades similares, ■■ Aplicaciones de soporte de fabricación
cada aplicación o conjunto de aplicaciones tiene un ■■ Automatización de la fuerza de ventas
conjunto diferente de requisitos de gestión y operativos. A
■■ Aplicaciones de procesamiento de órdenes de venta
continuación se muestran ejemplos de estas diferencias:
■■ Aplicaciones de centros de llamadas y de marketing
■■ El propósito de la aplicación. Cada aplicación se ■■ Aplicaciones específicas de negocio (p. ej., atención
ha desarrollado para cumplir un conjunto específico médica, seguros, banca, etc.)
de objetivos, normalmente objetivos de negocio. ■■ Aplicaciones de TI como Centro de Servicio al Usuario,
Para disponer de un soporte y mejora eficaces, el Gestión de Sistemas Empresariales, etc.
grupo que gestiona esa aplicación necesita tener
■■ Portales web
un entendimiento integral del contexto del negocio
■■ Compra online.
y cómo se utiliza la aplicación para cumplir sus
objetivos. Esto normalmente se logra a través de
Analistas de Negocio que están cerca del cliente y
6.5.6.1  Roles organizativos
son responsables de asegurar que los requisitos de Tradicionalmente, los equipos y departamentos de
negocio se traduzcan eficazmente en especificaciones Desarrollo y Gestión de Aplicaciones han sido unidades
de la aplicación. Los Analistas de Negocio deberán autónomas. Cada uno maneja su propio entorno a su
reconocer que los requisitos de negocio deben propio estilo y cada uno tiene una interfaz independiente
traducirse en especificaciones funcionales y de para el negocio. Esto se ilustra en la Tabla 6.2.
capacidad de gestión.
■■ La funcionalidad de la aplicación. Cada aplicación
se diseñó para funcionar de forma diferente y para
realizar diferentes funciones en distintos momentos.
■■ La plataforma en la que se ejecuta la aplicación.
Aunque la plataforma normalmente se gestiona a
través del equipo o departamento de Gestión Técnica,
 Organización de la Operación del Servicio | 149

Tabla 6.2 Roles organizativos

Desarrollo de Aplicaciones Gestión de Aplicaciones

Enfoque principal Crear funcionalidad para su cliente. Lo que la Enfoque en lo que es la funcionalidad además de
aplicación hace es más importante para ellos que cómo entregarla.
cómo se opera Aspectos de la capacidad de gestión de la
aplicación, es decir, cómo garantizar estabilidad y
rendimiento de la aplicación
Modo de gestión La mayor parte del trabajo de desarrollo se realiza La mayor parte del trabajo se realiza como
en proyectos en los que el enfoque se centra parte de procesos continuos y repetibles. En
en la entrega de unidades concretas de trabajo el proyecto trabaja un número relativamente
para las especificaciones, a tiempo y dentro del pequeñ~o de personas.
presupuesto. Esto significa que es muy difícil para el personal
Esto significa que, con frecuencia, es difícil para los de operaciones implicarse en proyectos de
desarrolladores entender y construir las operaciones desarrollo, debido a que les apartan de sus ’tareas
en marcha, especialmente desde que no están reales’
disponibles para dar soporte a la aplicación una vez
que hayan pasado al siguiente proyecto
Medida Se recompensa al personal por la creatividad y por Se recompensa al personal por la consistencia y
completar un proyecto para que puedan pasar al por evitar eventos inesperados y una operación
siguiente proyecto. sin autorización (p. ej., los desarrolladores añaden
’campanas y silbidos’)
Coste Los proyectos de desarrollo son relativamente Los costes de gestión continua normalmente
fáciles de cuantificar debido a que se conocen se mezclan con los costes de otros servicios de
los recursos y es fácil vincular sus gastos a una TI, debido a que los recursos se comparten a
aplicación o Servicio de TI específicos menudo entre múltiples aplicaciones y servicios
de TI
Ciclos de Vida El personal de desarrollo se centra en los Ciclos El personal implicado en la gestión continua
de Vida de Desarrollo de Software, que acentúan normalmente sólo controlará una o dos fases de
las dependencias con respecto a una operación estos ciclos de vida - Operación y Mejora
exitosa, pero que no asignan la responsabilidad de
éstas

Durante los últimos años, estos dos mundos se están ■■ Una interfaz única con el negocio para todas las
uniendo a través de recientes movimientos hacia métodos etapas del ciclo de vida y un proceso de requisitos
Orientados a Objetos y SOA, junto con el aumento de la comunes y de ajuste a la especificación.
presión del Negocio para ser más responsables y facilitar ■■ Un cambio en cómo se mide al personal de Desarrollo
el trabajo con ellos. y Gestión. Los equipos de desarrollo deberán
Esto significa que Desarrollo de Aplicaciones tendrá mayor mantenerse como parcialmente responsables de
responsabilidad con respecto al éxito de la operación de los defectos del diseño que generen interrupciones
las aplicaciones que diseñen, mientras que Gestión de operativas. El personal de gestión debe mantenerse
Aplicaciones tendrá una mayor implicación en el desarrollo como parcialmente responsable de la contribución al
de aplicaciones. diseño de la arquitectura técnica y de la capacidad de
gestión de las aplicaciones.
Esto no modifica el rol fundamental de cada grupo, ■■ Un único proyecto de Gestión de Cambios para ambos
pero requiere un método más integrado para el SLC. grupos, con Control de Cambios en cada grupo que
Esto también significará que la salida de Desarrollo de esté subordinado a la autoridad general de Gestión de
Aplicaciones estará más adaptada al consumo masivo, Cambios (vea la publicación Transición del Servicio).
y que Gestión de Aplicaciones estará más implicada en
■■ Una representación clara de las actividades de
proyectos de Desarrollo.
Desarrollo y Gestión en el ciclo de vida, que se ilustra
Esto requerirá los siguientes cambios: a un alto nivel en la Figura 6.5. Deberán definirse
las actividades exactas y cómo interactúan en cada
150 | Organización de la Operación del Servicio

■■ Asumirá la responsabilidad general de liderazgo,

Requisitos
control y toma de decisiones del equipo o
departamento de aplicaciones
■■ Proveerá conocimiento técnico y liderazgo en las
actividades de soporte de las aplicaciones específicas
cubiertas por el equipo o departamento
■■ Asegurará que se mantengan los niveles necesarios
Optimizar Diseñar
de formación técnica, concienciación y experiencia
Gestión del Servicio de TI dentro del equipo o departamento pertinente para las
Estrategia, Diseño,
Transición aplicaciones a las que se están dando soporte y para
y Mejora los procesos que se están utilizando
■■ Implicará la comunicación continua con usuarios
Crear y
Operar y clientes en relación con el rendimiento de la
Probar
aplicación y con los requisitos en evolución del
negocio
■■ Informará a la dirección senior de todos los asuntos
relevantes para las aplicaciones a las que se esté
Desplegar dando soporte
■■ Realizará la gestión de línea para todos los miembros
del equipo o departamento.

Despliegue de la Aplicación Gestión de la Aplicación

6.5.7.2  Analista/Arquitecto de Aplicaciones
Figura 6.6 Rol de los equipos en el Ciclo de Vida de Los Analistas y Arquitectos de Aplicaciones son
Gestión de Aplicaciones responsables de hacer corresponder los requisitos con
las especificaciones de la aplicación. Las actividades
organización, aunque se ofrecen algunas directrices específicas incluyen:
genéricas en cada una de las publicaciones de ITIL. ■■ Trabajar con usuarios, patrocinadores y con todos los
■■ Mayor enfoque en la integración de los requisitos demás interesados para determinar sus necesidades en
previos de funcionalidad y de capacidad de gestión en evolución
el proyecto. ■■ Trabajar con Gestión Técnica para determinar el nivel
La Figura 6.6 muestra un Ciclo de Vida de Gestión de más alto de los requisitos del sistema para cumplir los
Aplicaciones con la implicación de ambos grupos. En requisitos de negocio dentro del presupuesto y de las
este diagrama está claro que Desarrollo de Aplicaciones restricciones tecnológicas
estará dirigiendo algunas fases con entrada procedente ■■ Realizar análisis de coste-beneficio para determinar
de Gestión de Aplicaciones. En otros casos, Gestión los medios más apropiados para cumplir el requisito
de Aplicaciones estará dirigiendo la fase con entrada y establecido
soporte de Desarrollo de Aplicaciones. Ambos grupos ■■ Desarrollar Modelos Operativos que aseguren el
están subordinados a la Estrategia del Servicio de TI de la uso óptimo de los recursos y el nivel adecuado de
organización y sus esfuerzos se coordinarán a través de los rendimiento
mecanismos y procesos de Transición del Servicio. ■■ Asegurar que las aplicaciones se diseñen para
ser gestionadas eficazmente dada la arquitectura
6.5.7 Roles y responsabilidades de Gestión tecnológica, las habilidades disponibles y las
de Aplicaciones herramientas de la organización
■■ Desarrollar y mantener estándares para el
6.5.7.1  Jefes de Equipo/Gestores de Aplicaciones dimensionamiento, rendimiento y modelado de la
Será necesario un Jefe de Equipo o Gestor de Aplicaciones aplicación, etc.
(en función del tamaño y/o importancia del equipo o del
■■ Generar un conjunto de requisitos de pruebas de
departamento, de la aplicación a la que dan soporte, y de
aceptación, junto con los diseñadores, ingenieros de
la estructura y cultura de la organización) para cada uno
pruebas y el usuario, que determinen que se han
de los equipos o departamentos de aplicaciones. El rol:
cumplido todos los requisitos de alto nivel en relación
 Organización de la Operación del Servicio | 151

con los aspectos funcionales y con la capacidad de ●● Utilización real del sistema con respecto a
gestión previsiones del Plan de Capacidad (si el equipo ha
■■ Entrar en el diseño de los datos de configuración contribuido al desarrollo del plan)
requeridos para gestionar y hacer el seguimiento de la ●● Seguimiento en relación con los SIP
aplicación de forma eficaz. ●● Gasto en relación con el presupuesto.

Se necesitarán varios Analistas de Aplicaciones, para ■■ Rendimiento de aplicaciones. Estas métricas se

cada uno de los equipos o departamentos de Gestión de basan en especificaciones de Diseño del Servicio y en
Aplicaciones, para llevar a cabo las actividades genéricas estándares de rendimiento técnico establecidos por
que se describen en el párrafo 6.5.5. proveedores, y que normalmente se encontrarán en
OLAs o en SOPs. Las métricas reales variarán según la
Las formas en la que se pueden organizar los grupos de aplicación, pero probablemente incluirán:
Gestión de Aplicaciones, y las opciones disponibles, se
●● Tiempos de respuesta
analizan con algún detalle en la sección 6.7 que se incluye
●● Disponibilidad de la aplicación, que es útil para
más abajo.
medir el rendimiento de los grupos de trabajo o
de la aplicación, pero que no se confundirá con
6.5.8  Métricas de Gestión de Aplicaciones
Disponibilidad del Servicio, ya que ésta requiere la
Las métricas para Gestión de Aplicaciones dependerán en capacidad de medir la disponibilidad general del
gran medida de las aplicaciones que se están gestionando, servicio y podría usar las cifras de disponibilidad de
aunque algunas métricas genéricas incluirán: varios sistemas o componentes individuales
■■ Medida de las salidas acordadas. Éstas podrían ●● Integridad de los datos y de los informes.
incluir: ■■ Medida de la actividad de mantenimiento,
●● Capacidad de los usuarios para acceder a la incluyendo:
aplicación y a su funcionalidad ●● Mantenimiento realizado según la planificación
●● Los informes y archivos se transmiten a los ●● Número de ventanas de mantenimiento superadas
usuarios ●● Objetivos de mantenimiento alcanzados (número y
●● Los ratios de transacción y de disponibilidad para porcentaje).
transacciones críticas del negocio ■■ Es probable que los equipos de Gestión de
●● Formación del Centro de Servicio al Usuario Aplicaciones trabajen estrechamente con los equipos
●● Registro de soluciones de problemas en la KEDB de Desarrollo de Aplicaciones en proyectos, y deberán
●● Medidas de usuario de la calidad de las salidas usarse las métricas apropiadas para medir esto,
como se define en los SLA. incluyendo:
■■ Métricas de proceso. Los equipos de Gestión Técnica ●● Tiempo invertido en proyectos
ejecutan muchas actividades de proceso de Gestión ●● Satisfacción de clientes y usuarios con la salida del
del Servicio. Su disponibilidad para hacerlo se medirá proyecto.
como parte de las métricas de proceso si fuera ●● Coste de la implicación en el proyecto.
pertinente (vea la sección sobre cada proceso para ■■ Formación y desarrollo de habilidades. Estas
disponer de más detalles). Algunos ejemplos incluyen: métricas garantizan que el personal tenga las
●● Tiempo de respuesta para eventos y tasas de habilidades y formación necesarias para gestionar
finalización la tecnología que se encuentre bajo su control, y
●● Tiempos de resolución de incidencias para soporte también identificarán áreas en las que todavía se
de segunda y tercera línea requiera formación.
●● Estadísticas de resolución de problemas
●● Número de escalados y razones para esos 6.5.9 Documentación de Gestión de
escalados Aplicaciones
●● Número de cambios implementados y rechazados Durante Gestión de Aplicaciones se generan y usan
●● Número de cambios sin autorización detectados varios documentos. Esta lista representa un resumen de
●● Número de versiones desplegadas, totales y algunos de los más importantes y no incluye informes
exitosas, incluyendo garantizar el cumplimiento de o documentos que Gestión de Aplicaciones genera
las Políticas de Versiones de la organización en nombre de otro proceso o funciones (p. ej., RFC,
●● Problemas de seguridad detectados y resueltos documentación de Errores Conocidos, Registro de
152 | Organización de la Operación del Servicio

Entregas, etc.). Tenga en cuenta que los documentos

El Porfolio de Aplicaciones y el Catálogo de
deberán controlarse como CIs y asociarse con las
Servicios
aplicaciones pertinentes o con los equipos de Gestión de
Aplicaciones. El Portfolio de Aplicaciones no deberá confundirse
con el Catálogo de Servicios y no deberá considerarse
6.5.9.1  Porfolio de Aplicaciones como una lista de servicios para clientes y usuarios.
El Portfolio de Aplicaciones se utiliza principalmente como Las aplicaciones son uno de los componentes usados
parte de Estrategia del Servicio, pero se le menciona aquí para proveer servicios de TI, normalmente no el propio
para proporcionar una información completa. El Portfolio servicio.
de Aplicaciones es una lista (más precisa que un sistema o Por lo tanto, el Portfolio de Aplicaciones se usará
base de datos) de todas las aplicaciones en uso dentro de como un documento de planificación sólo para
la organización, junto con la siguiente información: aquellos gestores y personal que estén implicados
Atributos clave de la publicación en el desarrollo y gestión de la Estrategia de TI de
la organización, además del personal de TI al que se
■■ Clientes y usuarios le asigne la tarea de gestionar las aplicaciones o las
■■ Propósito del negocio plataformas sobre las que éstas se ejecutarán.
■■ Nivel de criticidad del negocio
El Catálogo de Servicios deberá centrarse en el listado
■■ Arquitectura (incluyendo las dependencias de la
de servicios que están disponibles, en lugar de listar
Infraestructura de TI)
simplemente las aplicaciones y asumir que los usuarios
■■ Desarrolladores, grupos de soporte, suministradores o y clientes pueden crear el enlace. No obstante, en
proveedores ocasiones la aplicación es sinónimo del servicio, p. ej.,
■■ La inversión realizada en la aplicación hasta la fecha. las aplicaciones de procesamiento de texto se conocen
A este respecto, el Porfolio de Aplicaciones se puede típicamente por su nombre; un servicio de alojamiento
usar como un registro de activos para las aplicaciones. de la aplicación mencionará los nombres de la
El propósito del Porfolio de Aplicaciones es analizar la aplicación alojada, etc.
necesidad y uso de aplicaciones en la organización. Se
puede usar para vincular la funcionalidad e inversión
a la actividad del negocio y por lo tanto es una parte 6.5.9.2  Requisitos de Aplicaciones
importante del control y planificación continuos de TI. Existen dos conjuntos de documentos que contienen
Otro beneficio del Portfolio de Aplicaciones es que se requisitos para las aplicaciones:
puede usar para identificar la duplicación y el exceso de
■■ Los Requisitos de Negocio describen el Caso
licencias de aplicaciones.
de Negocio para la aplicación requerida. En otras
El Portfolio de Aplicaciones forma parte del Porfolio de palabras, lo que el negocio hará con la aplicación. Esto
Servicios de TI global, que se analiza con detalle en la incluirá el Retorno de la Inversión para la aplicación
publicación Estrategia del Servicio. además de las mejoras asociadas con el negocio. Los
requisitos de negocio también incluirán los Requisitos
de Nivel de Servicio, tal y como los definieron los
usuarios y clientes del servicio.
■■ Los documentos Requisitos de Aplicaciones se
basan en los Requisitos de Negocio y especifican
exactamente cómo la aplicación cumplirá esos
requisitos. En resumen, los documentos de Requisitos
de Aplicaciones recopilan información que se utilizará
para autorizar nuevas aplicaciones o cambios en las
aplicaciones existentes, por ejemplo:
●● Para diseñar la arquitectura de la aplicación
(especificación de los diferentes componentes del
sistema, cómo se relacionan con los demás y cómo
se gestionarán)
 Organización de la Operación del Servicio | 153

●● Para especificar una Petición de Propuesta (RFP) habitual que el equipo que desarrolla las especificaciones
para una aplicación de Producto de Software funcionales mantenga el Caso de Uso para esa aplicación.
Empaquetado (COTS)
■■ Los Casos de Uso documentan el uso que se
●● Para iniciar el diseño y construcción de una pretende de la aplicación con escenarios en tiempo
aplicación a nivel interno. real que demuestran sus límites y su funcionalidad
Los documentos de requisitos normalmente son total. Los Casos de Uso también se pueden utilizar
propiedad de un responsable de proyecto, incluso de un como escenarios de modelado y dimensionamiento
equipo de proyecto de desarrollo o para un equipo que entre usuarios, Desarrolladores y el personal de
elabore especificaciones para una RFP. Los Documento de Gestión de Aplicaciones.
Requisitos están sujetos al control de documentos para el ■■ Los Casos de Cambio usan escenarios para predecir
proyecto, puesto que forman parte del alcance general del el impacto de cambios potenciales para la utilización,
mismo. arquitectura o funcionalidad, y proyectan el impacto
de escenarios de cambio específicos. Los Casos de
Es necesario definir cuatro tipos diferentes de Requisitos
Cambio se usan para aclarar el alcance y dirección
de Aplicaciones (para disponer de información más
con el patrocinador. En este punto, será necesario
detallada, consulte las publicaciones Diseño del Servicio y
un trabajo de diseño y arquitectura adicional para
Transición del Servicio de ITIL):
asegurar que los Casos de Cambio se puedan cumplir
■■ Los Requisitos Funcionales describen aquello que en el futuro con un coste razonable. El patrocinador
una aplicación pretende hacer, y pueden expresarse deberá estar preparado para pagar un coste extra. Si
como servicios, tareas o funciones que se requiere que no fuera así, los Casos de Cambio deberán reducirse
realice la aplicación. en función de lo que el patrocinador esté dispuesto
■■ Los Requisitos de Capacidad de Gestión se utilizan a pagar. Los Casos de Cambio también se utilizan
para definir aquello que es necesario para gestionar la para evaluar la arquitectura. Influyen en el proceso de
aplicación o para garantizar que realice las funciones desarrollo permitiendo el diseño de las funcionalidades
requeridas consistentemente y al nivel correcto. Los apropiadas de la arquitectura para minimizar el
requisitos de capacidad de gestión también identifican impacto de los futuros cambios.
restricciones en el sistema de TI. Estos requisitos sirven
Para disponer de más información consulte las
como base para el dimensionamiento anticipado del
publicaciones Diseño del Servicio y Mejora Continua del
sistema y para las estimaciones de costes, y pueden
Servicio de ITIL.
dar soporte a la evaluación de la viabilidad del sistema
de TI propuesto. Lo que es más importante, dirigen el
6.5.9.4  Documentación del diseño
diseño de los modelos operativos y de los estándares
de rendimiento usados en Gestión de Operaciones de Este no es un documento específico, sino que hace
TI. referencia a cualquier documento generado por el
personal de Gestión o Desarrollo de Aplicaciones que
■■ Los Requisitos de Usabilidad normalmente son
especifique cómo se construirá una aplicación. Debido a
especificados por los usuarios de la aplicación y
que estos documentos generalmente son de propiedad
hacen referencia a su facilidad de uso. También será
y están gestionados por los equipos de Desarrollo, esta
necesario especificar aquí cualquier requisito especial
publicación no los analizará con detalle. Sin embargo,
para los usuarios discapacitados.
para garantizar el éxito en la operación, Gestión de
■■ Los Requisitos de Prueba especifican lo que se
Aplicaciones deberá garantizar que la documentación del
requiere para asegurar que el entorno de prueba sea
diseño contenga:
representativo del entorno operativo y que la prueba
sea válida (es decir, que realmente pruebe lo que se ■■ Especificaciones de dimensionamiento
pretende). ■■ Perfiles de carga de trabajo y previsiones de utilización
■■ Arquitectura Técnica
6.5.9.3  Casos de Uso y de Cambio ■■ Modelos de datos
Los Casos de Uso y de Cambio se gestionan como parte ■■ Estándares de codificación
de los procesos de Diseño del Servicio y de Mejora ■■ Estándares de rendimiento
Continua del Servicio, pero están mantenidos por Gestión ■■ Definiciones de Gestión de la Configuración de
de Aplicaciones. En el caso del software adquirido, es Software
154 | Organización de la Operación del Servicio

■■ Definiciones de entornos y consideraciones de la

Manuales y Procedimientos de Operación Estándar
construcción (si fuera pertinente).
Los manuales no deberán verse como una sustitución
En el caso de las aplicaciones COTS, estos documentos
de los SOP, pero sí como una entrada en los SOP.
adoptan la forma de Especificaciones de Aplicaciones
que se usan como entrada en la elaboración de RFPs. En Los SOP deberán contener todos los aspectos de
estos casos, los documentos son de propiedad y están las aplicaciones que sea necesario gestionar como
gestionados por Gestión de Aplicaciones. parte de operaciones estándar. Si no se extrajeran
de los manuales, existe una alta probabilidad de
Para disponer de más información sobre la
que se ignoren o se lleven a cabo de una forma no
Documentación del Diseño, consulte la publicación Diseño
estándar. Gestión de Aplicaciones deberá garantizar
del Servicio de ITIL.
que cualquiera de esas instrucciones se extraiga
de los manuales y se inserte en la documentación
6.5.9.5  Manuales
independiente de los SOPs para Operaciones. También
Gestión de Aplicaciones es responsable de la gestión será responsable de garantizar que estas instrucciones
de manuales para todas las aplicaciones. Aunque se actualicen con cada cambio o nueva versión de
normalmente son los equipos de Desarrollo de software.
Aplicaciones o suministradores externos los que
desarrollan estos manuales, Gestión de Aplicaciones
6.6  Roles y responsabilidades de
será responsable de garantizar que los manuales sean
relevantes para las versiones operativas de las aplicaciones.
Operación del Servicio
La clave para un ITSM eficaz es asegurar que existen
Normalmente, Gestión de Aplicaciones mantiene tres tipos
roles y responsabilidades claramente definidos para
de manuales:
llevar a cabo la práctica de Operación del Servicio. Un rol
■■ Los Manuales de Diseño contienen información normalmente se vincula con una descripción de trabajo o
sobre la estructura y arquitectura de la aplicación. con una descripción de un grupo de trabajo que no debe
Son útiles para crear informes o para definir reglas vincularse necesariamente con un individuo. El tamaño
de correlación de eventos. También pueden ser útiles de una organización, cómo se estructura, la existencia de
para el diagnóstico de problemas. patrones externos y otros factores, influirán sobre cómo
■■ Los Manuales de administración o gestión se asignan los roles. Independientemente de que un rol
describen las actividades requeridas para mantener particular se vincule con un único individuo o se comparta
y operar la aplicación a los niveles de rendimiento entre dos o más, la importancia es la consistencia de la
especificados en la fase de Diseño. Estos manuales responsabilidad y ejecución, junto con la interacción con
también ofrecerán descripciones detalladas de otros roles en la organización.
la detección y resolución de problemas, Errores
Conocidos y de Fallos, e instrucciones paso a paso 6.6.1 Roles del Centro de Servicio al Usuario
para las tareas habituales de mantenimiento. Los siguientes roles son necesarios para el Centro de
■■ Los Manuales de usuario describen la funcionalidad Servicio al Usuario.
de la aplicación cuando la use un usuario final. Estos
manuales contienen instrucciones paso a paso sobre 6.6.1.1  Gestor del Centro de Servicio al Usuario
cómo usar la aplicación, además de descripciones de
En organizaciones grandes, en las que el Centro de
lo que se debería introducir típicamente en ciertos
Servicio al Usuario cuenta con un tamaño significativo,
campos, o qué hacer si se produjera un error.
podría justificarse un rol de Gestor del Centro de Servicio
al Usuario, con los Supervisores del Centro de Servicio al
Usuario que le informen. En tales casos, este rol podría
asumir la responsabilidad de algunas de las actividades
listadas anteriormente y podría realizar las siguientes
actividades adicionales:
■■ Gestionar las actividades generales del centro de
servicio, incluyendo los supervisores
■■ Actuar como un punto de escalado superior para los
supervisores
 Organización de la Operación del Servicio | 155

■■ Asumir un rol cliente-servicios más amplio través de la atención de llamadas y del tratamiento de
■■ Informar a los gestores senior sobre cualquier las incidencias resultantes o de las Peticiones de Servicio
problema que pudiera impactar significativamente en usando los procesos Información de Incidencias y
el negocio Gestión de Peticiones, en línea con los objetivos descritos
■■ Asistir a las reuniones del Comité de Cambios anteriormente. El número exacto del personal requerido se
■■ Asumir la responsabilidad general de las incidencias y analiza en el párrafo 6.2.4.1.
del manejo de Peticiones de Servicio en el Centro de
Servicio al Usuario. Esto podría ampliarse a cualquier 6.6.1.4  Super Usuarios
otra actividad asumida por el Centro de Servicio al Los Super Usuarios se analizan con detalle en la sección
Usuario, p. ej., monitorizar ciertas clases de eventos. sobre el personal del Centro de Servicio al Usuario en el
párrafo 6.2.4. En resumen, este rol consistirá en usuarios
Nota: En todos los casos, las descripciones de trabajos
del negocio que actúan como puntos de contacto con
definidos claramente deberán redactarse y acordarse para
TI en general y con el Centro de Servicio al Usuario en
que se conozcan las responsabilidades específicas.
particular. El rol del Super Usuario puede resumirse de la
siguiente forma:
6.6.1.2  Supervisor del Centro de Servicio al
Usuario ■■ Facilitar la comunicación entre TI y el negocio a un
nivel operativo
En centros de servicio muy pequeños es posible que el
■■ Reforzar las expectativas de los usuarios en relación
Analista senior del Centro de Servicio al Usuario también
actúe como el Supervisor, pero en centros de servicio con los Niveles de Servicio que se han acordado
mayores, es probable que se necesite un rol dedicado de ■■ Formación del personal sobre los usuarios en su área
Supervisor del Centro de Servicio al Usuario. Si hay turnos ■■ Proporcionar soporte para las incidencias menores o
definidos, podrían haber dos o más responsables que para la gestión de peticiones sencillas
desempeñaran el rol, normalmente de forma superpuesta. ■■ Implicación con nuevas versiones y despliegues.
Es probable que el rol del Supervisor incluya:
■■ Garantizar que el personal y los niveles de aptitud se
6.6.2 Roles de Gestión Técnica
mantengan en las horas operativas gestionando las Los siguientes roles son necesarios para las áreas de
planificaciones del personal de los turnos, etc. Gestión Técnica
■■ Asumir las actividades de RR.HH. cuando sea necesario
6.6.2.1  Gestores Técnicos/Jefes de Equipo
■■ Actuar como un punto de escalado cuando se reciban
llamadas difíciles o controvertidas Podría ser necesaria la presencia de un Gestor Técnico o
■■ Producción de informes de estadísticas y de gestión Jefe de Equipo (dependiendo del tamaño y/o importancia
del equipo y de la estructura y cultura de la organización)
■■ Representar al Centro de Servicio al Usuario en las
para cada uno de los equipos o departamentos técnicos.
reuniones
El rol:
■■ Organizar la formación del personal y sesiones de
concienciación ■■ Asumirá la responsabilidad general del liderazgo,
■■ Coordinación con la gestión senior control y toma de decisiones del equipo o
■■ Coordinación con Gestión de Cambios departamento técnico
■■ Realizar sesiones informativas con el personal del ■■ Proveerá conocimiento técnico y liderazgo en las
Centro de Servicio al Usuario sobre cambios o áreas técnicas específicas cubiertas por el equipo o
despliegues que pudieran afectar a los volúmenes en departamento
el Centro de Servicio al Usuario ■■ Asegurará que los niveles necesarios de formación
■■ Ayudar a los analistas a la hora de proveer soporte de técnica, concienciación y experiencia se mantengan
primera línea cuando las cargas de trabajo sean altas, dentro del equipo o departamento
o donde se requiera experiencia adicional. ■■ Informará a la dirección senior de todos los problemas
relevantes para su área de responsabilidad
6.6.1.3  Analistas del Centro de Servicio al ■■ Realizará la gestión de línea para todos los miembros
Usuario del equipo o departamento.
El rol primario del Analista del Centro de Servicio al
Usuario es la provisión de soporte de primer nivel a
156 | Organización de la Operación del Servicio

6.6.2.2  Analistas/Arquitectos Técnicos 6.6.3 Roles de Gestión de Operaciones de TI

Este término hace referencia a cualquier miembro del Los siguientes roles son necesarios en el área de Gestión
personal de Gestión Técnica que realice las actividades de Operaciones de TI:
listadas en el párrafo 6.3.3, excluyendo las acciones
operativas diarias, que las realizarán los Operadores en 6.6.3.1  Gestor de Operaciones de TI
Gestión Técnica o en Gestión de Operaciones de TI. Será necesario un Gestor de Operaciones de TI para asumir
Basándose en la lista de actividades genéricas del párrafo la responsabilidad general de todas las actividades de
6.3.3, el rol de los Analistas y Arquitectos Técnicos incluye: Gestión de Operaciones de TI, que incluyen:
■■ Trabajar con usuarios, patrocinadores, Gestión de ■■ Control de Operaciones, que supervisa la ejecución
Aplicaciones y con todos los demás interesados para y monitorización de las actividades operativas en
determinar sus necesidades en evolución la Infraestructura de TI. Esto se puede hacer con la
■■ Trabajar con Gestión de Aplicaciones y otras áreas de ayuda de un Puente de Operaciones o un Centro
Gestión Técnica para determinar el nivel más alto de de Operaciones de Red. Además de ejecutar tareas
los requisitos del sistema requeridos para cumplir con rutinarias desde todas las áreas técnicas, Control de
las necesidades en función del presupuesto y de las Operaciones también realiza las siguientes tareas
restricciones tecnológicas específicas:
■■ Definir y mantener el conocimiento sobre ●● Gestión de Consolas, que hace referencia a
cómo se relacionan los sistemas y asegurar la definición de la capacidad de observación y
que las dependencias se entiendan y gestionen monitorización central y al uso de esas consolas
adecuadamente para realizar actividades de monitorización y
■■ Realizar análisis de coste-beneficio para determinar control
los medios más apropiados para cumplir los requisitos ●● Planificación de Trabajos, o la gestión de scripts
establecidos o trabajos por lotes rutinarios
■■ Desarrollar Modelos Operativos que aseguren el uso ●● Backup y Restauración en nombre de todos los
óptimo de los recursos y el nivel de rendimiento equipos o departamento de Gestión Técnica y de
adecuado Aplicaciones y con frecuencia en nombre de los
■■ Asegurar que la infraestructura se configure para ser usuarios
gestionada eficazmente en función de la arquitectura ●● Gestión de la impresión y de la salida para
tecnológica, las habilidades disponibles y las el cotejo y distribución de toda la impresión
herramientas de la organización centralizada o salida electrónica.
■■ Asegurar el rendimiento consistente y fiable de la ■■ Gestión de las Instalaciones, que hace referencia
infraestructura para entregar el nivel requerido de a la gestión del entorno físico de TI, típicamente un
servicio para el negocio Centro de Proceso de Datos o salas de ordenadores
■■ Definir todas las tareas requeridas para gestionar la y emplazamientos de recuperación con todos los
infraestructura y asegurar que estas tareas se lleven a equipos de alimentación y refrigeración. Gestión de
cabo adecuadamente las Instalaciones también incluye la coordinación
■■ Entrar en el diseño de los datos de configuración de proyectos de consolidación a gran escala, p.
requeridos para gestionar y hacer el seguimiento de la ej., consolidación del centro de proceso de datos
aplicación de forma eficaz. o proyectos de consolidación de servidores. En
algunos casos, la gestión de un Centro de Proceso
Las formas en las que se puede organizar Gestión técnica,
de Datos se externaliza, en cuyo caso Gestión de las
y las opciones disponibles, se analizan con algún detalle
Instalaciones hace referencia a la gestión del contrato
en la sección 6.7.
de externalización.
6.6.2.3  Operador Técnico El rol del Gestor de Operaciones de TI es:
Este término se utiliza para hacer referencia a cualquier ■■ Proveer liderazgo general, control y toma de
personal que realice tareas operativas diarias en Gestión decisiones y asumir la responsabilidad de los equipos
Técnica. Normalmente, estas tareas se delegan a un y departamento de Gestión de Operaciones de TI
equipo de Operaciones de TI dedicado, por lo que este rol ■■ Informar a la gestión senior sobre todos los problemas
se analiza en el párrafo 6.6.3.4 sobre Operaciones de TI. de Operaciones de TI
 Organización de la Operación del Servicio | 157

■■ Realizar la gestión de línea para todos los gestores/ ■■ Gestión de dispositivos de impresión, reabastecimiento
supervisores del departamento o equipos de de papel, tóner, etc.
Operaciones de TI. ■■ Asegurar que se lleven a cabo los trabajos por lotes, el
archivado, etc.
6.6.3.2  Responsables de turnos ■■ Realizar trabajos planificados de mantenimiento,
Muchas áreas de Operaciones de TI trabajarán a lo largo como por ejemplo mantenimiento de bases de datos,
del día sobre la base de dos o tres turnos. En tales casos, limpieza de archivos, etc.
será necesario un responsable de turno en cada uno de ■■ Grabación de imágenes para la distribución e
ellos para realizar las siguientes actividades: instalación en nuevos servidores, puestos de trabajo u
■■ Asumir la responsabilidad general del liderazgo, ordenadores portátiles
control y toma de decisiones durante el turno ■■ Instalación física de equipos estándar en el Centro de
■■ Asegurar que todas las actividades operativas se Proceso de Datos.
realicen satisfactoriamente dentro de las escalas de
tiempo acordadas y de conformidad con las políticas y 6.6.4 Roles de Gestión de Aplicaciones
procedimientos de la empresa
6.6.4.1  Jefes de Equipo/Gestores de Aplicaciones
■■ Coordinarse con los demás responsables de
Deberá considerarse tener un Gestor de Aplicaciones
turnos para asegurar el traspaso de información, la
o Jefe de Equipo para cada uno de los equipos o
continuidad y la consistencia entre turnos
departamentos de aplicaciones. Su rol incluye:
■■ Actuar como gestor de línea para todos los Analistas
de Operaciones en su turno ■■ Asumirá la responsabilidad general de liderazgo,
■■ Asumir la responsabilidad general de seguridad y control y toma de decisiones del equipo o
salud durante el turno (a menos que se designe departamento de aplicaciones
específicamente a otros miembros del personal). ■■ Proveerá conocimiento técnico y liderazgo en las
actividades de soporte de las aplicaciones específicas
6.6.3.3  Analistas de Operaciones de TI cubiertas por el equipo o departamento
Los Analistas de Operaciones de TI forman parte del ■■ Asegurará que se mantengan los niveles necesarios
personal senior de Operaciones de TI que son capaces de de formación técnica, concienciación y experiencia
determinar la forma más eficaz y eficiente de dirigir una dentro del equipo o departamento pertinente para las
serie de operaciones, normalmente en entornos diversos aplicaciones a las que se están dando soporte y para
de alto volumen. los procesos que se están utilizando
■■ Implicará la comunicación continua con usuarios
Este rol normalmente se realiza como parte de la Gestión
y clientes en relación con el rendimiento de la
Técnica, pero las organizaciones grandes podrían
aplicación y con los requisitos en evolución del
determinar que el volumen y diversidad de las actividades
negocio
operativas requieran de una planificación y ejecución más
■■ Informará a la dirección senior de todos los asuntos
detallada. Ejemplos de esto incluyen la Planificación de
relevantes para las aplicaciones a las que se esté
Jobs y la definición de una planificación y estrategia de
dando soporte
Backup.
■■ Realizará la gestión de línea para todos los miembros
6.6.3.4  Operadores de TI del equipo o departamento.

Los Operadores de TI son el personal que realiza las

6.6.4.2  Analista/Arquitecto de Aplicaciones
actividades operativas diarias que se definen en Gestión
Técnica y de Aplicaciones y, en algunos casos, Analistas de Los Analistas y Arquitectos de Aplicaciones son
Operaciones de TI. Los roles típicos del Operador incluyen: responsables de hacer corresponder los requisitos con
las especificaciones de la aplicación. Las actividades
■■ Realización de backups específicas incluyen:
■■ Operaciones de consola, es decir, monitorización del
■■ Trabajar con usuarios, patrocinadores y con todos los
estado de sistemas específicos, colas de jobs, etc.,
demás interesados para determinar sus necesidades en
y proporcionar intervención de primer nivel si fuera
evolución
pertinente
■■ Trabajar con Gestión Técnica para determinar los
requisitos de alto nivel del sistema para cumplir
158 | Organización de la Operación del Servicio

los requerimientos dentro del presupuesto y de las Operaciones, a menos que el Centro de Servicio al Usuario
restricciones tecnológicas y el Puente de Operaciones se hayan combinado.
■■ Realizar análisis de coste-beneficio para determinar los La investigación y resolución de eventos que se han
medios más apropiados para cumplir el requerimiento identificado como Incidencias, inicialmente las asumirá el
establecido Centro de Servicio al Usuario y a continuación se escalarán
■■ Desarrollar Modelos Operativos que aseguren el uso a los equipos apropiados de Operación del Servicio.
óptimo de los recursos y el nivel de rendimiento
adecuado El Centro de Servicio al Usuario también será responsable
de comunicar información sobre este tipo de incidencias
■■ Asegurar que las aplicaciones son diseñadas para
al equipo apropiado de Gestión Técnica o de Aplicaciones
ser gestionadas eficazmente dada la arquitectura
y, cuando sea pertinente, al usuario.
tecnológica, las habilidades disponibles y las
herramientas de la organización
6.6.5.2  El rol de Gestión Técnica y de
■■ Desarrollar y mantener estándares para el
dimensionamiento, rendimiento y modelado de la Aplicaciones
aplicación, etc. Gestión Técnica y de Aplicaciones desempeñan varios
■■ Generar un conjunto de requisitos de pruebas de roles importantes de la siguiente forma:
aceptación, junto con los diseñadores, ingenieros ■■ Durante Diseño del Servicio, participarán en la
de pruebas y el usuario, que determinen que se instrumentación del servicio, clasificarán eventos,
han cumplido todos los requerimientos de alto nivel actualizarán motores de correlación y asegurarán que
en relación con los aspectos funcionales y con la se defina cualquier respuesta automática
capacidad de gestión ■■ Durante Transición del Servicio probarán el
■■ Entrar en el diseño de los datos de configuración servicio para asegurar que los eventos se generen
requeridos para gestionar y hacer el seguimiento de la adecuadamente y que las respuestas definidas sean
aplicación de forma eficaz. apropiadas
Será necesario un número de Analistas de Aplicaciones ■■ Durante Operación del Servicio estos equipos
para cada uno de los equipos o departamentos de Gestión normalmente realizarán Gestión de Eventos para
de Aplicaciones a la hora de llevar a cabo las actividades los sistemas bajo su control. No es habitual que
descritas en otro punto de esta publicación. los equipos tengan a una persona dedicada para
Gestión de Eventos, pero cada gestor o jefe de
Las formas en las que se pueden organizar los grupos de
equipo asegurará que se definan los procedimientos
Gestión de Aplicaciones, y las opciones disponibles, se
adecuados y que se ejecuten de acuerdo con los
analizan con algún detalle en la sección 6.7.
requisitos de proceso y de las políticas
■■ Gestión Técnica y de Aplicaciones también se
6.6.5 Roles de Gestión de Eventos
implicarán en el tratamiento de las incidencias y
No es habitual que una organización designe a un problemas asociados con los eventos
’Gestor de Eventos’, debido a que los eventos tienden ■■ Si las actividades de Gestión de Eventos se
a producirse en múltiples contextos y por muchas delegaran al Centro de Servicio al Usuario o a
razones diferentes. Sin embargo, es importante que los Gestión de Operaciones de TI, Gestión Técnica y de
procedimientos de Gestión de Eventos se coordinen para Aplicaciones deberán asegurarse que el personal esté
evitar la duplicidad de esfuerzos y herramientas. Los roles adecuadamente formado y que tenga acceso a las
de las funciones de Operación del Servicio en Gestión de herramientas apropiadas que le permitan realizar estas
Eventos son los siguientes. tareas.

6.6.5.1  El rol del Centro de Servicio al Usuario 6.6.5.3  El rol de Gestión de Operaciones de TI
El Centro de Servicio al Usuario no se implica Si Operaciones de TI está separado de Gestión Técnica
normalmente en Gestión de Eventos como tal, a menos o de Aplicaciones, es habitual delegar en Gestión de
que un evento requiera alguna respuesta que se encuentre Operaciones de TI la Monitorización de Eventos y la
dentro de la actividad definida del Centro de Servicio respuesta de primera línea. A los operadores de cada
al Usuario, por ejemplo, notificar a un usuario que un área se les asignarán las tareas de monitorización de
informe está preparado. Sin embargo, generalmente eventos, respondiendo cuando se requiera, o asegurando
este tipo de actividad se realiza a través del Puente de que las Incidencias se creen cuando sea pertinente. Las
 Organización de la Operación del Servicio | 159

instrucciones sobre cómo hacerlo deberán incluirse en los Tal grupo puede manejar mucha de las incidencias
SOP para esos equipos. menos complicadas, dejando que los grupos de soporte
más especializados (tercera línea) se concentren en el
Monitorización de Eventos se delega habitualmente
tratamiento de incidencias más complejas y/o nuevos
al Puente de Operaciones si existiera. El Puente de
desarrollos, etc.
Operaciones puede iniciar y coordinar, o incluso llevar a
cabo, las respuestas requeridas por el servicio, o proveer Si se usara un grupo de segunda línea, normalmente
soporte de primer nivel para aquellos eventos que existirán ventajas al ubicar este grupo cerca del Centro
generen una incidencia. de Servicio al Usuario para mejorar las comunicaciones y
para facilitar el movimiento de personal entre los grupos,
6.6.6 Roles de Gestión de Incidencias lo que podría ser útil para la formación/concienciación y
Los siguientes roles son necesarios para el proceso de durante periodos particularmente activos o de escasez de
Gestión de Incidencias. personal. Normalmente, un gestor de soporte de segunda
línea (o supervisor si sólo fuera un pequeño grupo) se
6.6.6.1  Gestor de Incidencias hará cargo de este grupo.
Un Gestor de Incidencias tiene la responsabilidad de: Se puede contemplar externalizar este grupo, lo que será
más probable y práctico si ya se ha externalizado el propio
■■ Dirigir la eficiencia y eficacia del proceso de Gestión
Centro de Servicio al Usuario.
de Incidencias
■■ Generar información de gestión
6.6.6.4 Tercera línea
■■ Gestionar el trabajo del personal de soporte de
El soporte de tercera línea se creará a través de
incidencias (primera y segunda línea)
varios grupos técnicos internos y/o de proveedores
■■ Monitorizar la eficacia de Gestión de Incidencias y
o suministradores. La lista variará dependiendo de la
hacer recomendaciones de mejora
organización pero es probable que incluya:
■■ Desarrollar y mantener los sistemas de Gestión de
Incidencias ■■ Soporte de Red
■■ Gestionar Incidencias Graves ■■ Soporte de Voz (si fuera independiente)
■■ Desarrollar y mantener los procesos y procedimientos ■■ Soporte de Servidores
de Gestión de Incidencias. ■■ Soporte al Puesto de Trabajo
■■ Gestión de Aplicaciones – probablemente podrá haber
En muchas organizaciones, el rol del Gestor de Incidencias
grupos independientes para diferentes aplicaciones y
se asigna al Supervisor del Centro de Servicio al Usuario
tipos de aplicación, algunos de lo cuales podrían ser
por lo que podría ser necesario asignarlo a un rol
proveedores o mantenedores externos. En muchos
independiente en organizaciones grandes con altos
casos, el mismo equipo será responsable de los
volúmenes de trabajo. En cualquier caso, es importante
Desarrollos de Aplicaciones además del soporte, y por
que al Gestor de Incidencias se le dé la autoridad para
lo tanto será importante que se prioricen los recursos
gestionar las incidencias de forma eficaz a través de la
para que se dé soporte según el nivel de importancia
primera, segunda y tercera línea.
■■ Soporte de Bases de Datos

6.6.6.2  Primera línea ■■ Ingenieros de Mantenimiento de Hardware

■■ Mantenedores/Suministradores de Equipos del Entorno
Esto se trata con detalle en la sección 6.1 dedicada al
Centro de Servicio al Usuario y no se repetirá aquí. Nota: Dependiendo de si una organización decidiera
aprovisionar sus servicios de soporte, cualquiera de los
6.6.6.3  Segunda línea grupos anteriores podrían ser grupos internos o externos.
Muchas organizaciones decidirán tener un grupo de
soporte de segunda línea, llevado a cabo por personal con 6.6.7 Roles de Gestión de Peticiones
mayores habilidades técnicas (aunque todavía generales) El tratamiento inicial de Peticiones de Servicio lo abordará
que el Centro de Servicio al Usuario, y con tiempo el personal del Centro de Servicio al Usuario y de Gestión
adicional para dedicarse al diagnóstico y resolución de Incidencias.
de incidencias sin la interferencia de interrupciones
La cumplimentación eventual de la petición será
telefónicas.
abordada por los equipos o departamentos apropiados de
Operación del Servicio y/o por suministradores externos
160 | Organización de la Operación del Servicio

cuando sea apropiado. En muchas ocasiones, Gestión de Si un problema individual fuera suficientemente serio
Instalaciones, Compras y otras áreas del negocio ayudarán para justificarlo, se establecería un equipo de gestión de
en la gestión de la Petición de Servicio. En la mayoría de problemas dedicado para que trabaje en la resolución de
los casos, no habrá necesidad de crear roles o puestos este problema en particular. El Gestor de Problemas tiene
adicionales. un rol que desempeñar a la hora de garantizar que estén
disponibles el número y nivel correcto de recursos en el
En casos excepcionales en los que se trate con un gran
grupo, y para el escalado y comunicación a través de la
número de Peticiones de Servicio, o cuando los requisitos
cadena de gestión de todas las organizaciones implicadas.
tengan una importancia crítica para la organización,
podría ser apropiado tener uno o más equipos de Gestión
de Incidencias dedicado a tratar y gestionar Peticiones de
6.6.9 Roles de Gestión de Accesos
Servicio. Debido a que Gestión de Accesos es una actividad
ejecutoria de las políticas de Gestión de Seguridad y
6.6.8 Roles de Gestión de Problemas Disponibilidad, estas dos áreas serán responsables de
definir los roles apropiados. No es habitual que una
Los siguientes roles son necesarios para el proceso de
organización designe a un ’Gestor de Accesos’, aunque
Gestión de Problemas.
es importante que haya un único proceso de Gestión
de Accesos y un único conjunto de políticas asociadas
6.6.8.1  Gestor de Problemas
con la gestión de derechos y de accesos. Es probable
Debería haber una persona designada (o, en que este proceso y las políticas asociadas sean definidos
organizaciones grandes, un equipo) responsable de la y mantenidos por la Gestión de la Seguridad de la
Gestión de Problemas. Puede que organizaciones más Información y que los ejecuten las diversas funciones de
pequeñas no puedan justificar un recurso a tiempo Operación del Servicio. Sus actividades pueden resumirse
completo para este rol, y en tales casos, se podría de la siguiente forma.
combinar con otros roles, pero es esencial que esta
responsabilidad no se deje únicamente a cargo de los 6.6.9.1  El rol del Centro de Servicio al Usuario
recursos técnicos. Sería necesario un único punto de
El Centro de Servicio al Usuario se utiliza típicamente
coordinación y un propietario del proceso de Gestión de
como un medio para solicitar acceso a un servicio. Esto
Problemas. Este rol coordinará las actividades de Gestión
se realiza normalmente usando una Petición de Servicio.
de Problemas y tendrá la responsabilidad específica de:
El Centro de Servicio al Usuario validará la petición
■■ Coordinarse con todos los grupos de resolución de comprobando que ésta se haya aprobado al nivel
problemas para asegurar una rápida resolución de apropiado de autoridad, que el usuario sea un empleado,
problemas dentro de los objetivos del SLA contratista o cliente legítimo, y que estén habilitados para
■■ Propiedad y protección de la KEDB el acceso.
■■ Barrera de control para la inclusión de todos los Una vez se hayan realizado estas comprobaciones
Errores Conocidos y para la gestión de los algoritmos (normalmente accediendo a las bases de datos pertinentes
de búsqueda y a los documentos de Gestión del Nivel de Servicio), se
■■ Cierre formal de todos los Registros de Problemas pasará la petición al equipo apropiado para proporcionar
■■ Colaboración con suministradores, contratistas, el acceso. Es bastante habitual delegar al Centro de
etc., para asegurar que cumplan sus obligaciones Servicio al Usuario la responsabilidad de proporcionar
contractuales, especialmente con respecto a acceso para servicios simples durante una llamada.
la resolución de problemas y al suministro de
El Centro de Servicio al Usuario también será el
información y datos asociados con los mismos
responsable de comunicarse con el usuario para asegurar
■■ Actividades de organización, ejecución,
que sepa cuándo se le ha concedido el acceso y para
documentación y seguimiento asociadas con las
asegurar que reciba cualquier otro soporte requerido.
Revisiones de Problemas Graves.
El Centro de Servicio al Usuario también está bien situado
6.6.8.2  Grupos de Resolución de Problemas para detectar e informar de incidencias asociadas con
Es probable que la resolución real de problemas la asuma el acceso. Por ejemplo, usuarios que intenten acceder a
uno o más grupos de soporte técnico y/o suministradores los servicios sin autorización; o usuarios que informen
o contratistas de soporte bajo la coordinación del Gestor de incidencias que indiquen que un sistema o servicio
de Problemas. se ha usado de forma inadecuada, por ejemplo, por un
 Organización de la Operación del Servicio | 161

empleado anterior que usó un nombre de usuario antiguo 6.7  Estructuras de la Organización
para obtener acceso y realizar actividades sin autorización. de Operación del Servicio
6.6.9.2  El rol de Gestión Técnica y de Ya se ha dado alguna información general sobre
consideraciones organizativas para cada función (vea
Aplicaciones
los párrafos 6.2.3, 6.3.4 y 6.5.6). Esta sección trata
Gestión Técnica y de Aplicaciones desempeñan diversos algunas estructuras organizativas específicas para todas
roles importantes de la siguiente forma: las funciones. Existen diversas formas de organizar las
■■ Durante Diseño del Servicio, garantizarán que se funciones de Operación del Servicio, y cada organización
creen los mecanismos para simplificar y controlar la tendrá que tomar sus propias decisiones, basándose en su
Gestión de Accesos en cada servicio que se diseñe. escala, geografía, cultura y entorno de negocio. Algunas
También especificarán las formas en las que se pueda opciones se analizan en el resto de esta sección.
detectar y detener el abuso de los derechos
■■ Durante Transición del Servicio probarán el servicio 6.7.1 Organización por especialización
para asegurar que se pueda conceder, controlar y técnica
evitar el acceso según se diseñó En este tipo de organización, los departamentos se
■■ Durante Operación del Servicio estos equipos crean de acuerdo con la tecnología y las habilidades
normalmente realizarán Gestión de Accesos para y actividades necesarias para gestionar esa tecnología.
los sistemas bajo su control. No es habitual que los Operaciones de TI seguirá la estructura de los
equipos tengan a una persona dedicada para llevar departamentos de Gestión Técnica y de Aplicaciones. La
la Gestión de Accesos, pero cada gestor o jefe de implicación de esto es que Operaciones de TI se centrará
equipo asegurará que se definan los procedimientos en las agendas operativas de los departamentos de
adecuados y que se ejecuten de acuerdo con los Gestión Técnica y de Aplicaciones.
requisitos de proceso y de las políticas
Esta estructura puede funcionar bien, siempre que estos
■■ Gestión Técnica y de Aplicaciones también estarán grupos estén bien representados en los procesos de
implicados en el tratamiento de Incidencias y Diseño, Prueba y Mejora del Servicio, lo que garantizará
Problemas asociados con Gestión de Accesos que sus agendas estén alineadas con los requisitos del
■■ Si las actividades de Gestión de Accesos se negocio.
delegaran en el Centro de Servicio al Usuario o en la
Gestión de Operaciones de TI, Gestión Técnica y de Esta estructura también asume que todos los
Aplicaciones deberán asegurarse que el personal esté departamentos de Gestión Técnica y de Aplicaciones
adecuadamente formado y que hayan tenido acceso a han distinguido claramente entre las actividades propias
las herramientas apropiadas que les permitan realizar de Gestión y las actividades propias de operaciones.
las correspondientes tareas. También se requiere que se hayan estandarizado estas
actividades operativas para que el Gestor de Operaciones
6.6.9.3  El rol de Gestión de Operaciones de TI de TI pueda gestionarlas eficientemente sin interferencias
de los equipos y departamentos de Gestión Técnica y de
Si Operaciones de TI se separara de Gestión Técnica o de
Aplicaciones.
Aplicaciones, es habitual delegar que asuman las tareas
operativas de Gestión de Accesos. A los operadores de En la Figura 6.7 se muestra un ejemplo de estructura
cada área se les asignarán las tareas de proporcionar de la organización de Operaciones de TI basada en la
o denegar el acceso a los sistemas y recursos clave. experiencia técnica.
Las circunstancias bajo las que podrán hacerlo, y las
instrucciones sobre cómo hacerlo, deberán incluirse en los
SOP para esos equipos.
El Puente de Operaciones, si existiera, podrá usarse
para monitorizar eventos relacionados con Gestión de
Accesos e incluso puede dar soporte de primera línea y
coordinación para la resolución de esos eventos si fuera
apropiado.
162 | Organización de la Operación del Servicio

Las ventajas de este tipo de estructura organizativa ■■ Los dispositivos, sistemas o plataformas individuales se
incluyen lo siguiente. pueden gestionar de forma más eficaz, ya que están
a cargo de personas con las habilidades apropiadas,
■■ Es más fácil establecer objetivos de rendimiento
que son medidas de acuerdo con su rendimiento
interno ya que todo el personal en un único
■■ Se facilita la gestión de los programas de formación,
departamento tiene un conjunto de tareas similares
sobre una tecnología similar ya que los conjuntos de habilidades están claramente
definidos y separados en grupos específicos.

Gestión de
Operaciones de TI

Control de Operaciones de Operaciones de Gestión de

Operaciones de TI Infraestructura Aplicación Instalaciones

Operaciones de
Operaciones del
Aplicaciones
Mainframe
Financieras

Operaciones de
Operaciones Aplicaciones
de Servidores de RR.HH.

Operaciones de Operaciones de
Almacenamiento Aplicaciones
de Negocio

Operaciones
de Red

Operaciones
de Escritorio

Operaciones de
la Base de Datos

Operaciones del
Servicio de
Directorio

Operaciones del
Middleware

Operaciones
Internet/Web

Figura 6.7 Operaciones de TI organizadas de acuerdo con la especialización técnica (ejemplo)

 Organización de la Operación del Servicio | 163

Las desventajas de este tipo de estructura organizativa independientemente de la tecnología, deberían agruparse,
incluyen. aunque dentro de cada departamento podría haber
equipos centrados en una tecnología, en una aplicación
■■ Cuando las personas se dividen en departamentos
específica, etc.
independientes, las prioridades de su propio grupo
tienden a estar por encima de las prioridades de otros En este tipo de organización, no hay una diferenciación
departamentos. Por ejemplo, cuando un departamento clara entre las diferentes áreas de Gestión Técnica y de
rechaza aceptar la propiedad de una incidencia, Aplicaciones. Podrán agruparse en un único departamento
culpando a los demás mientras que el negocio actividades similares de muchas áreas diferentes.
continúa afectado.
Entre los ejemplos de departamentos que se han
■■ El conocimiento sobre la infraestructura y las preparado para realizar un conjunto específico de
relaciones entre componentes es difícil de recopilar actividades para múltiples tecnologías se incluyen:
y está fragmentada. Cada grupo tiende a recopilar y
mantener sólo los datos que necesita para dar soporte ■■ Mantenimiento (esto implica que un equipo
a su propia función, y no facilitan a otro grupo el coordinará y realizará todo el mantenimiento de todas
acceso a ellos. las tecnologías)
■■ Cada tecnología gestionada por un grupo se ve como ■■ Gestión de Contratos o Gestión de Terceros
una entidad independiente. Esto supone un problema ■■ Monitorización y Control
en los sistemas que están formados por componentes ■■ Puente de Operaciones
gestionados por diferentes equipos, p. ej., una ■■ Centro de Operaciones de Red
aplicación, gestionada por el equipo de Gestión de ■■ Estrategia y Planificación de Operaciones (que,
Aplicaciones, corre en un servidor gestionado por el como parte de los procesos de Diseño del Servicio,
departamento de Gestión de Servidores, y usa un normalmente define los estándares a utilizar en
segmento de red gestionado por el departamento de Operaciones de TI). Este departamento puede
Redes de Área Local. Si un equipo o departamento establecer la estrategia o estándares para cada tipo de
hiciera un cambio sin coordinarlo con los demás, esto área de Gestión Técnica y de Aplicaciones.
podría ser desastroso para el servicio.
El departamento de Estrategia y Planificación de
■■ Es más difícil entender el impacto del rendimiento
Operaciones se utiliza para ilustrar este tipo de estructura
deficiente de un departamento con respecto al
en la Figura 6.8.
Servicio de TI, ya que existen muchos grupos
diferentes que contribuyen al mismo servicio, cada Las ventajas de este tipo de estructura organizativa
uno con sus propios objetivos de rendimiento. incluyen lo siguiente.
■■ Es muy difícil hacer el seguimiento del rendimiento ■■ Es más fácil gestionar grupos de actividades asociadas,
general del Servicio de TI, ya que cada grupo se está ya que todas las personas implicadas en estas
midiendo de forma individual. actividades informan al mismo gestor
■■ La coordinación de las Evaluaciones y Planificaciones ■■ La evaluación de los equipos o departamentos se basa
de Cambios es más difícil, ya que numerosos más en los resultados que en actividades aisladas.
departamentos tienen que aportar información para Esto contribuye a crear niveles más altos de garantía
cada cambio. en la prestación del servicio.
■■ El trabajo que se requiere de conocimiento de
múltiples tecnologías se hace complejo, ya que la Las desventajas de este tipo de estructura organizativa
mayoría de los recursos están formados para gestionar incluyen lo siguiente.
una única tecnología y sólo se preocupan por ella. Por ■■ Recursos con habilidades similares podrían duplicarse
lo tanto, los proyectos tienen que incluir formación en diferentes funciones, lo que genera mayores costes
cruzada que consume mucho tiempo y además es ■■ Aunque la evaluación se basa más en los resultados,
más cara. todavía se centra en el rendimiento de actividades
internas más que en la experiencia del cliente o del
6.7.2 Organización por actividad usuario final.
Este tipo de estructura organizativa se centra en el hecho
de que tienen que realizarse actividades similares en 6.7.3 Organización para gestionar procesos
todas las tecnologías de la organización. Esto implica No es una buena idea estructurar toda la organización
que las personas que realizan actividades similares, de acuerdo con los procesos. Los procesos se usan
164 | Organización de la Operación del Servicio

Organiación por Actividad

Gestor de
Estrategia de TI
y Planificación

Arquitectura Investigación
Planificación Portfolio
y de Nueva
de Capacidad de Servicios
Estándares Tecnología

Aplicaciones Mainframe

Infraestructura Servidores

Almacenamiento

Red

Basado en Web

Figura 6.8 Un departamento basado en la ejecución de un conjunto de actividades

para superar el ’efecto silo’ de departamentos, no para Operaciones de TI es responsable de definir SLAs y
crear silos. Sin embargo, existen diversos procesos que negociar UCs.
necesitarán una estructura organizativa dedicada para
Además, existen procesos concretos que vinculan las
darles soporte y gestionarlos. Por ejemplo, será muy difícil
actividades de diferentes grupos para lograr un resultado
que Gestión Financiera tenga éxito sin un departamento
específico. El uso de procesos como fundamento para
de Finanzas, incluso si ese departamento estuviera
la creación de departamentos puede anular el propósito
compuesto por un número pequeño de personas.
de darle prioridad a los procesos. Los departamentos
En organizaciones basadas en procesos las personas basados en procesos únicamente son eficaces cuando son
se organizan en grupos o departamentos que realizan capaces de coordinar la ejecución del proceso en toda la
o gestionan un proceso específico. Esto es similar a la organización.
estructura basada en actividades, excepto en que sus
Esto significa que sólo debería considerarse tener
departamentos se centran en conjuntos de actividades de
departamentos basados en procesos si Gestión de
principio a fin, más que en un tipo individual de actividad.
Operaciones de TI desempeña el rol de Propietario del
Debe tenerse en cuenta que este tipo de estructura Proceso para un proceso específico.
organizativa sólo debería usarse si Gestión de Operaciones
Entre los ejemplos de grupos o departamentos basados en
de TI fuera responsable de algo más que sólo Operaciones
procesos se incluyen:
de TI. Por ejemplo, en algunas organizaciones,
 Organización de la Operación del Servicio | 165

■■ Operaciones de la Capacidad ■■ Los Centros de Proceso de Datos que están

■■ Monitorización y Control de la Disponibilidad distribuidos geográficamente
■■ Gestión Financiera de TI ■■ Distintas regiones o países que tienen tecnologías
■■ Administración de Seguridad diferentes o proporcionan un conjunto diferente de
■■ Gestión de Activos y de la Configuración (incluyendo servicios
la instalación y despliegue de equipos). ■■ Cuando existen diferentes modelos de negocio
o estructuras organizativas en distintas regiones,
Las ventajas de este tipo de estructura organizativa por ejemplo, si el negocio está geográficamente
incluyen lo siguiente. descentralizado y cada Unidad de Negocio tiene
■■ Los procesos son más fáciles de definir bastante autonomía
■■ Existen menos conflictos de roles ya que las ■■ Cuando se aplica una legislación diferente en distintos
descripciones de trabajos y las descripciones de roles países o regiones (p. ej., regulaciones de seguridad)
de procesos son las mismas. En otras estructuras, una ■■ Si se aplican estándares diferentes en distintos países
única descripción del trabajo incluirá posiblemente o regiones
actividades para varios roles ■■ Si existen diferencias culturales o idiomáticas entre el
■■ Las métricas del rendimiento del equipo o personal que gestiona TI.
departamento y del rendimiento del proceso son las
En la Figura 6.9 se ofrece un ejemplo de este tipo de
mismas, alineando eficazmente las métricas ’internas’
estructura. Tenga en cuenta que en este ejemplo cada
y ’externas’.
departamento geográfico se estructura internamente
Las desventajas de este tipo de estructura organizativa a través de la Especialización Técnica. Esto podría ser
incluyen lo siguiente. diferente en cada región. Por ejemplo, una región podría
estructurarse de esta forma, mientras que en otra región
■■ Un principio básico de los procesos es que son
se aplica una estructura basada en procesos o actividades.
un medio para vincular las actividades de varios
departamentos y grupos. Al hacer uso de procesos La Figura 6.9 también muestra que una ubicación podría
como fundamento para el diseño organizativo, es realizar operaciones centralizadas para todas las regiones
necesario definir procesos adicionales para asegurar si fueran suficientemente similares. En este ejemplo, el
que los departamentos funcionen juntos. Departamento Americano de Operaciones de Servidores
■■ Aunque un departamento sea responsable de gestiona las operaciones de todos los servidores en todas
la ejecución de un proceso, todavía existirán las ubicaciones, Bruselas gestiona todas las operaciones de
dependencias externas. Es posible que los grupos no la base de datos y Singapur gestiona todas las operaciones
consideren importantes las actividades de proceso que de almacenamiento.
queden fuera de su propio proceso, lo que redunda Las ventajas de este tipo de estructura organizativa
en procesos que no se pueden ejecutar por completo incluyen lo siguiente.
porque no se han podido establecer las dependencias.
■■ Aunque es posible centralizar algunos aspectos de un ■■ La estructura organizativa se puede personalizar para
proceso, siempre habrá un número de actividades que cumplir las condiciones locales
tendrán que realizar otros grupos. La relación entre ■■ Es posible monitorizar Operaciones de TI para cumplir
el equipo o departamento dedicado a una tarea y las diferentes niveles de servicio de TI en función de la
personas que realizan las actividades descentralizadas región.
es a menudo difícil de definir y gestionar. Las desventajas de este tipo de estructura organizativa
incluyen lo siguiente.
6.7.4 Organizar Operaciones de TI
■■ Las líneas de información y las estructuras de
geográficamente
autorización pueden ser confusas. Por ejemplo,
Operaciones de TI puede distribuirse físicamente y, en ¿Operaciones de Red informa al Gestor del Centro de
algunos casos, cada ubicación necesitará organizarse de Proceso de Datos o a un Gestor de Operaciones de
acuerdo con su propio contexto particular. Red centralizado?
Esta estructura se utiliza típicamente en las siguientes ■■ Los estándares operativos son difíciles de imponer, lo
circunstancias: que acarrea actividades y herramientas inconsistentes
y duplicadas, reduciéndose las economías de escala,
166 | Organización de la Operación del Servicio

Gestor de
Operaciones de TI

Operaciones de TI
Operaciones de TI en Operaciones de TI en Operaciones de TI en
en África –
América – Miami Europa – Bruselas Asia Pacífico – Singapur
Johannesburgo

Operaciones del Operaciones del Operaciones del Operaciones del

Mainframe Mainframe Mainframe Mainframe

Operaciones
de Servidores

Operaciones de
Almacenamiento

Operaciones Operaciones Operaciones Operaciones

de Red de Red de Red de Red

Operaciones Operaciones Operaciones Operaciones

del Escritorio del Escritorio del Escritorio del Escritorio

Operaciones de
la Base de Datos

Operaciones de Operaciones de Operaciones de Operaciones de

Internet/Web Internet/Web Internet/Web Internet/Web

Figura 6.9 Operaciones de TI organizadas de acuerdo con la geografía

lo cual aumenta a su vez los costes generales de 6.7.5 Estructuras organizativas híbridas

operación. No es frecuente que Gestión de Operaciones de TI
■■ La duplicación de roles, actividades, herramientas e esté articulada en torno a un solo tipo de estructura
instalaciones en múltiples ubicaciones puede ser muy organizativa. La mayoría de las organizaciones usan una
costosa. especialización técnica, con algunos departamentos
■■ Los servicios compartidos, como por ejemplo el correo adicionales basados en actividades o procesos.
electrónico, son más difíciles de proveer, debido a que
El tipo de estructura usada y la combinación exacta de
cada organización regional opera de forma diferente.
departamentos con especialización técnica, basados en
■■ La comunicación con los clientes y con TI interno será
actividades y basados en procesos, dependerá de diversas
más difícil debido a que no se ubican juntos y podría
variables organizativas.
ser difícil para el personal de una ubicación entender
las prioridades de los clientes o del personal de otra
ubicación.
 Organización de la Operación del Servicio | 167

Gestor de
Operaciones de TI

Control de Gestión de Gestión de Gestión de

Operaciones de TI Infraestructuras Instalaciones Aplicaciones

Gestión de
Gestión de Gestión del Aplicaciones
Servidores Mainframe Financieras

Gestión de Operaciones de
Operaciones Operaciones del
Aplicaciones de Aplicaciones
de Servidores Mainframe
RR.HH. Financieras

Operaciones de Gestión de
Gestión Gestión del
Aplicaciones de Aplicaciones
de Red Almacenamiento
RR.HH. de Negocio

Operaciones de Operaciones de
Operaciones
Almacenamiento Aplicaciones
de Red
de Negocio

Gestión de Gestor
la Base de Datos del Escritorio

Operaciones de Operaciones
la Base de Datos del Escritorio

Gestión de
Internet/Web

Operaciones de
Internet/Web

Figura 6.10 Estructura Centralizada de Gestión Técnica, de Aplicaciones y de Operaciones de TI

168 | Organización de la Operación del Servicio

departamento podrá delegar alguna de estas actividades

Variables de la estructura organizativa
al departamento de Control de Operaciones.
Los criterios exactos elegidos y la estructura
Las ventajas de esta estructura organizativa son:
organizativa resultante dependerán de diversas
variables, que podrían incluir: ■■ Existe una mayor consistencia y control entre las
actividades más tácticas y las más operativas de
■■ La naturaleza del negocio
Gestión Técnica
■■ Expectativas y requisitos de negocio
■■ Es más fácil imponer el cumplimiento de los
■■ La arquitectura técnica y la tecnológica
estándares de rendimiento y las arquitecturas técnicas
■■ La estabilidad de la Infraestructura de TI actual y la que se crean en Diseño del Servicio, debido a que las
disponibilidad de habilidades para gestionarla personas que están implicadas en el diseño gestionan
■■ El gobierno de la organización (es decir, la forma las actividades de las personas que ejecutan tales
en la que se asigna la autoridad y se toman las actividades
decisiones, además de cualquier marco de trabajo ■■ Al no existir duplicidades entre ubicaciones o
de gobierno formal que se utilice, como por actividades, esta estructura es normalmente más
ejemplo COBIT o SOX) rentable.
■■ El entorno legislativo, político y socioeconómico de
La desventaja de esta estructura organizativa es:
la organización
■■ El tipo y nivel de las habilidades disponibles para ■■ Resulta muy difícil gestionar eficazmente el ámbito
la organización de esta estructura en grandes organizaciones o en
■■ El tamaño, antigüedad y madurez de la organizaciones con múltiples Centros de Proceso de
organización Datos.
■■ El estilo de gestión de la organización
6.7.5.2  Organización de la Gestión Técnica y de
■■ Dependencia de TI con respecto a las actividades,
Aplicaciones
procesos y funciones críticas para el negocio
Las organizaciones de Gestión Técnica y de Aplicaciones
■■ La forma en la que TI participa en la red de valor
tienden a ser bastante sencillas. Como se indicó en los
(es decir, la forma en la que TI interactúa con
párrafos 6.3.4 y 6.5.6, los departamentos de Gestión
el negocio y con sus socios, suministradores y
Técnica normalmente se basan en la tecnología que
clientes)
gestionan y los departamentos de Gestión de Aplicaciones
■■ La relación entre TI y sus proveedores.
en las aplicaciones y conjuntos de aplicaciones que
Para disponer de una descripción completa sobre gestionan.
cómo estos factores influyen en el diseño operativo,
consulte la sección ’Desarrollo Organizativo’ de la Sin embargo, existen algunas estructuras y variaciones
publicación Estrategia del Servicio. alternativas de la organización que se analizan en esta
sección.
6.7.5.1  Funciones combinadas
6.7.5.3  Geografía
Debería analizarse un último tipo de organización. Esta
estructura incorpora los departamentos de Gestión En organizaciones con múltiples ubicaciones, es
Técnica, de Aplicaciones y de Operaciones de TI en una habitual que los departamentos de Gestión Técnica y
única estructura. Esto ocurrirá en algunos casos si todos de Aplicaciones estén representados en cada ubicación
los grupos se ubican juntos en un único Centro de física. Sin embargo, esto no significa que cada ubicación
Proceso de Datos. Aquí, el Gestor del Centro de Proceso tenga todos los mismos departamentos, o que todas sean
de Datos asume la responsabilidad de la Gestión Técnica, responsables de las mismas acciones.
de Aplicaciones y de Operaciones de TI. A medida que las herramientas de soporte y gestión
Este tipo de estructura organizativa se ilustra en la Figura maduran, cada vez más CIs y partes de la Infraestructura
6.10. de TI se pueden gestionar de forma remota. Esto significa
que cada departamento dispondrá de un equipo de
En esta estructura, Gestión de Operaciones de TI será Gestión Técnica y de Aplicaciones fuerte y centralizado,
responsable de las funciones de Gestión Técnica y con miembros locales para proveer soporte o actividades
de Aplicaciones, que a su vez son responsables de in situ especializadas.
gestionar sus propias actividades operativas. Cada
 Organización de la Operación del Servicio | 169

Por ejemplo, en la Gestión de Servidores, el equipo central 6.7.5.4  Estructura combinada de Gestión Técnica
ayudará a crear estándares para la configuración de y de Aplicaciones
servidores, monitorizará y controlará dispositivos remotos,
Algunas organizaciones estructuran sus funciones de
realizará backups, actualizaciones del Sistema Operativo,
Gestión Técnica y de Aplicaciones de acuerdo con
etc. Los equipos locales darán el soporte básico in situ, el
los sistemas. Esto significa que cada departamento
mantenimiento de hardware y la reparación, configuración
estará formado por especialistas en aplicaciones y por
e instalación de los nuevos servidores.
especialistas técnicos de la Infraestructura de TI, centrados
En la Gestión de Aplicaciones, el equipo central podría todos en la gestión de servicios que se basan en ese
participar en el diseño y prueba de la aplicación, conjunto de sistemas. Los componentes que se comparten
en la monitorización y control; realizar backups, entre todos estos sistemas, como la red, estarán
comprobaciones de integridad de los datos, etc. El gestionados por departamentos de Gestión Técnica
equipo local podría facilitar formación y soporte in situ dedicados.
a los usuarios finales y trabajar con el equipo de Gestión
La ventaja de esta estructura organizativa es:
Técnica local para resolver problemas más complejos que
impliquen a equipos locales. ■■ Es más fácil generar resultados de alta calidad para
el usuario final debido a que todos los miembros
Sin embargo, existe un problema potencial que es
del departamento se centran en el éxito del sistema
necesario resolver, y que consiste en saber a quién
en conjunto, más que en el rendimiento de una
informará el equipo local. En algunas organizaciones,
aplicación o componente tecnológico individual.
informan al gestor del equipo centralizado. Esto tiene la
ventaja añadida de la consistencia del rendimiento y de la Las desventajas de esta estructura organizativa son:
gestión a través de toda la empresa. ■■ La duplicación de habilidades y recursos en
En otras organizaciones, los equipos locales informan al varios departamentos incrementará el coste de la
Director de TI más senior del emplazamiento. Esto tiene organización. Por ejemplo, es probable que cada
la ventaja añadida de que los Servicios de TI pueden grupo disponga de un individuo o equipo dedicado
personalizarse para cumplir las condiciones locales, pero para la gestión de servidores. Cada grupo realizará
crea mucha confusión sobre quién tomará el control en tareas muy similares.
los equipos locales. ■■ Se reduce la comunicación entre el personal que está
gestionando tecnologías similares. Esto reduce el nivel
Las ventajas de este tipo de estructura organizativa
de aprendizaje mediante la experiencia y aumenta la
incluyen lo siguiente.
confianza en las herramientas colaborativas de gestión
■■ La estructura organizativa se puede personalizar para del conocimiento.
cumplir las condiciones locales ■■ Cuando personas con habilidades similares pertenecen
■■ Gestión Técnica y de Aplicaciones pueden al mismo departamento, habrá una compensación
personalizarse para cumplir diferentes niveles de de los miembros con menor nivel de habilidad y
servicio de TI dependiendo de la región. de competencia. Cuando sólo haya una persona
Las desventajas de este tipo de estructura organizativa con habilidades de Gestión de Servidores en un
incluyen las siguientes. departamento basado en sistemas, y su competencia
sea mínima, el rendimiento de todo el departamento
■■ Las líneas de información y las estructuras de se verá afectado.
autorización pueden ser confusas
■■ Los estándares son difíciles de imponer, lo que genera
actividades y herramientas inconsistentes y duplicadas,
reduciéndose las economías de escala, lo cual
aumenta a su vez los costes generales de operación
■■ La duplicación de roles, actividades, herramientas e
instalaciones en múltiples ubicaciones podría ser muy
costosa.
Consideraciones sobre
la tecnología 7
 | 173

7 Consideraciones sobre la tecnología

Cada función y proceso se define en la sección pertinente organización (como contratos, ubicaciones, licencias,
en los Capítulos 4 y 6. Este capítulo presenta juntos todos suministradores, etc., es decir, todo lo que la organización
los requisitos tecnológicos para definir los requisitos de TI desee controlar), junto con todos los atributos
generales de un conjunto integrado de tecnología de relevantes en una ubicación centralizada que permita
Gestión del Servicio para Operación del Servicio. almacenar y mantener las relaciones entre ellos y su
vinculación con los Registros de Incidencias, Problemas,
Debería emplearse la misma tecnología, con algunos
Cambios y Errores Conocidos cuando sea apropiado.
posibles añadidos, en el resto fases del ITSM, que son
Estrategia del Servicio, Diseño del Servicio, Transición
del Servicio y Mejora continua del Servicio, para dar
7.1.4 Tecnología de Descubrimiento/
coherencia y permitir que se gestione adecuadamente un Despliegue/Licenciamiento
Ciclo de Vida de ITSM eficaz. Para poblar con datos o verificar los ya existentes en
el CMS y para ayudar en la Gestión de Licencias, se
Los requisitos principales de Operación del Servicio son los
requerirán herramientas automatizadas de descubrimiento
que se establecen en este capítulo.
o auditoría. Tales herramientas deberán poder ejecutarse
desde cualquier ubicación en la red y permitir la consulta
7.1  Requisitos genéricos y recuperación de la información asociada a todos
Es necesario que una tecnología integrada de ITSM (o los componentes que se integran o se conectan a la
conjunto de herramientas, ya que algunos suministradores Infraestructura de TI.
venden su tecnología como ‘módulos’ mientras Tal tecnología deberá permitir el ‘filtrado’ para que se
que algunas organizaciones podrían decidir integrar puedan examinar los datos que se están transfiriendo y
productos de diferentes proveedores) incluya la siguiente sólo se extraigan los datos requeridos. También es muy
funcionalidad central. útil si se pudieran extraer sólo los registros modificados
desde la última auditoría, para sacar informes.
7.1.1  Autoayuda
Esta misma tecnología podrá utilizarse para desplegar
Muchas organizaciones encuentran beneficioso ofrecer nuevo software en las ubicaciones seleccionadas. Este
capacidades de ‘Autoayuda’ a sus usuarios. Por lo tanto, la es un requisito esencial para que todos los equipos o
tecnología debería dar soporte a esta opción con alguna departamentos de Operación del Servicio puedan distribuir
forma de interfaz web que permita definir páginas en las parches, transportes, etc., a los usuarios correctos.
que se ofrezca una serie de Peticiones de Servicio y de
Autoayuda a través de menús comunicadas directamente Sería aconsejable disponer de funciones de ‘Autoayuda’
con el software de gestión de procesos. para que sea posible solicitar descargas aprobadas de
software que pueda tratarse automáticamente mediante el
7.1.2  Flujo de trabajo o motor de procesos software de despliegue.

Es necesario que haya un flujo de trabajo o motor de Es muy aconsejable utilizar herramientas que permitan la
control de procesos para permitir la definición previa y el comparación automática de los detalles de las licencias
control de los procesos definidos, como por ejemplo el de software (idealmente en el CMS) y los números de
Ciclo de Vida de la Incidencia, Ciclo de Vida de la Gestión licencias desplegadas realmente, que puedan sacar
de Peticiones, Ciclo de Vida del Problema, Modelo de informes que reflejen cualquier discrepancia.
Cambio, etc.
7.1.5 Control remoto
Esto debería permitir la definición previa y la gestión
posterior automatizada de responsabilidades, plazos de Es ,muy útil para los Analistas del Centro de Servicio al
tiempo, rutas de escalado y alertas. Usuario y para otros grupos de soporte, poder tomar
control remoto del puesto de trabajo del usuario (bajo
7.1.3 CMS integrado condiciones de seguridad controladas adecuadamente)
para realizar investigaciones o corregir ajustes, etc. Para
La herramienta deberá tener un CMS integrado para
permitir este nivel de control remoto será necesario
permitir mantener los activos de la infraestructura de
disponer del software y permisos adecuados.
TI, componentes, servicios y cualquier CI auxiliar de la
174 | Consideraciones sobre la tecnología

7.1.6 Utilidades de diagnóstico Una empresa de telecomunicaciones de Europa del

Sería extremadamente útil para el Centro de Servicio al Este fue capaz de conectar su sistema de facturación
Usuario y para otros grupos de soporte si la tecnología y monitorización de la red de telefonía móvil con
incorporara la capacidad de crear y usar scripts de sus procesos de Gestión de Eventos, Gestión de
diagnóstico y otras utilidades (como por ejemplo, Incidencias y Gestión de la Configuración. De esta
herramientas de deducción basadas en casos) para ayudar forma, fue capaz de detectar cualquier patrón de
al diagnóstico precoz de incidencias. Idealmente, éstas facturación/uso inusual, e interpretarlo para que
deberían ser ‘sensibles al contexto’ con una presentación pudiera identificar, con un alto nivel de precisión, si un
de scripts lo más automatizada posible. teléfono había sido robado y si estaba siendo utilizado
para realizar llamadas no permitidas.
7.1.7 Generación de informes Fue capaz de lanzar eventos para esos patrones
No tiene mucho sentido almacenar datos a menos que y automatizar acciones para suspender el uso
éstos se puedan recuperar y usarse fácilmente para de teléfonos móviles y, en paralelo, identificar la
cumplir los propósitos de la organización. Por lo tanto, ubicación exacta del usuario no permitido (usando
la tecnología deberá incorporar buenas capacidades de tecnología GPRS) y poner incidencias para que la
generación de informes, además de permitir que las policía tuviera la capacidad de encontrar al ladrón
interfaces estándar se puedan utilizar para introducir datos sospechoso y recuperar el terminal.
en utilidades de reporting estándar de mercado, paneles
de control, etc. Teóricamente se pueden extraer informes
Se requieren más capacidades de integración de
en tiempo real en pantalla además de informes impresos a
herramientas avanzadas para permitir una mayor
través del uso de informes ‘top ten’ sensibles al contexto.
explotación de esta clase de negocio e integración de TI.

7.1.8  Paneles de Control 7.2  Gestión de Eventos

La tecnología de Paneles de Control es útil para permitir
Las siguientes funcionalidades serían aconsejables para
‘ver de un vistazo’ los niveles generales de disponibilidad
cualquier tecnología de Gestión de Eventos:
y de rendimiento del servicio de TI. Tales visualizaciones
se pueden incluir en informes de nivel de gestión ■■ Interfaz abierta para múltiples entornos que permita
para usuarios y clientes, pero también pueden ofrecer monitorizar y generar alertas a través de servicios
información en tiempo real para su inclusión en páginas heterogéneos y a través de toda la Infraestructura de
web de TI y ofrecer informes dinámicos, y se pueden TI de una organización.
utilizar para propósitos de soporte y de investigación. ■■ Fácil de desplegar, con mínimos costes de
Además, puede ser particularmente útil disponer de configuración.
capacidades para dar soporte a vistas personalizadas de ■■ Agentes ‘Estándar’ para monitorizar la mayoría de los
información según perfiles de interés. entornos/componentes/sistemas.
Sin embargo, algunas veces representan una visión técnica ■■ Interfaces abiertas para aceptar cualquier entrada
de la infraestructura en lugar de una visión del servicio de eventos estándar (p. ej., SNMP) y para generar
y, en tales casos, podrían ser menos interesantes para los múltiples alertas.
clientes y usuarios. ■■ Enrutamiento centralizado de todos los eventos a una
única ubicación, programable que permita diferentes
7.1.9 Integración con Gestión de Servicios ubicaciones en diversos momentos.
de Negocio ■■ Soporte de las fases de diseño/prueba para que se
puedan monitorizar nuevas aplicaciones/servicios
Existe una tendencia dentro de la industria de TI para
durante las fases de diseño/prueba y generar
intentar reunir la parte de TI asociada con el negocio con
retroalimentación en el diseño y transición.
los procesos y disciplinas de Gestión del Servicio de TI.
Algunos lo llaman Gestión de Servicios de Negocio. Para ■■ Evaluación programable y tratamiento de alertas
facilitarlo, las aplicaciones y herramientas del negocio dependiendo de los síntomas y del impacto.
deben conectarse con herramientas de soporte de ITSM ■■ La capacidad de permitir a un operador reconocer una
para ofrecer la funcionalidad requerida. Esto se puede alerta, y reaccionar ante ella, y si no se da ninguna
ilustrar mediante este ejemplo: respuesta en una franja de tiempo definida, escalar la
alerta.
 Consideraciones sobre la tecnología | 175

■■ Una buena funcionalidad de generación de informes ■■ Facilidades de generación de informes fáciles de usar
para permitir la retroalimentación en las fases de para permitir generar métricas de incidencias y para
diseño y transición además de un ‘panel de control’ facilitar el análisis de incidencias para propósitos de
con información significativa de gestión y de negocio. Gestión de Problemas y Gestión de la Disponibilidad.
■■ Herramientas de diagnóstico (integradas o de interfaz
Tal tecnología deberá permitir una interfaz directa con los
procesos de Gestión de Incidencias de la organización (a con productos independientes), ya mencionadas en la
través de entradas en los Registros de Incidencias), además sección dedicada al Centro de Servicio al Usuario.
de la capacidad de escalado al personal de soporte,
suministradores, ingenieros, etc., a través de correo 7.3.2  Flujo de trabajo y escalado automático
electrónico, mensajería SMS, etc. Los objetivos de tiempo objetivo deberán incluirse en
herramientas de soporte, que deberán utilizarse para
Se requerirán equipos especializados, o quizás
automatizar el control del flujo de trabajo y las rutas de
herramientas especializadas independientes para la
escalado.
monitorización web. Tales equipos deberán ser capaces de
simular el tráfico del cliente sobre el sitio web e informar Si, por ejemplo, un grupo de soporte de segunda línea no
sobre la disponibilidad y rendimiento en relación con la hubiera resuelto una incidencia en el plazo acordado de
‘experiencia del cliente’. 60 minutos, la incidencia se encaminará automáticamente
hasta el grupo de tercera línea apropiado (determinado
por la categorización de incidencias), y deberá asumirse
7.3  Gestión de Incidencias automáticamente cualquier escalado jerárquico necesario
(p. ej., mensaje SMS al Gestor del Centro de Servicio al
7.3.1 Tecnología integrada de ITSM Usuario, Gestor de Incidencias y/o Gestor de Servicios
Se requiere una tecnología integrada de ITSM que tenga de TI e incluso al usuario, si fuera apropiado). Se debe
las siguientes funcionalidades: informar al grupo de soporte de segunda línea de la
■■ Un CMS integral para permitir la creación y acción de escalado como parte del proceso automatizado.
mantenimiento de relaciones entre incidencias,
peticiones de servicio, problemas, Errores Conocidos y 7.4  Gestión de peticiones
todos los demás elementos de configuración de forma
automática. Es necesario disponer de una tecnología integrada de
ITSM para que las Peticiones de Servicio se puedan
■■ El CMS que pueda servir de ayuda para determinar la
vincular con incidencias o eventos que las hayan iniciado
prioridad y colaborar en el diagnóstico e investigación.
(y que se almacenen en el mismo CMS, al que se podrá
■■ Un motor de flujo de proceso que permita generar
interrogar para que informe con respecto a los SLA).
modelos de proceso predefinidos (incluyendo modelos
Algunas organizaciones estarán satisfechas con el uso del
de incidencias predefinidos, vea el párrafo 3.2.1.5) y
elemento de Gestión de Incidencias de tales herramientas
controlarlos automáticamente con encaminamiento
y con el tratamiento de las Peticiones de Servicio como un
interno flexible para todos los grupos de soporte
subconjunto y categoría definidos de incidencias. Cuando
pertinentes y para interfaces externas de correo
una organización decida plantear Peticiones de Servicio
electrónico/SMS.
independientes, requerirá una herramienta que permita
■■ Capacidades de escalado y de alerta automáticos para esta capacidad.
evitar que se pase por alto o se retrase una incidencia.
■■ Interfaz abierta con herramientas de Gestión de Las capacidades de Autoayuda del front-end serán
Eventos para que cualquier fallo pueda plantearse necesarias para que los usuarios puedan enviar peticiones
automáticamente como incidencia. a través de alguna forma de proceso de selección dirigida
por menús basado en web.
■■ Una interfaz web que permita autoayuda y que las
peticiones de servicio entren a través de pantallas de En todos los demás aspectos, las facilidades necesarias
Internet/Intranet. para gestionar Peticiones de Servicio son muy similares
■■ Una KEDB integrada para que los problemas/ a aquellas utilizadas para gestionar incidencias: control
incidencias resueltos o diagnosticados se puedan predefinido del flujo de trabajo de Modelos de Peticiones,
registrar y buscar para acelerar la resolución de futuras niveles de prioridad, escalado automatizado, generación
incidencias. eficaz de informes, etc.
176 | Consideraciones sobre la tecnología

7.5  Gestión de Problemas Nota: En algunos casos, los componentes o sistemas

investigados por la Gestión de Problemas, podrían estar
7.5.1 Tecnología Integrada de Gestión del suministrados por proveedores o fabricantes externos. Para
Servicio controlarlo, podría ser necesario usar herramientas de
soporte y KEBDs del propio proveedor.
Será necesario utilizar una herramienta de ITSM integrada
que diferencie entre incidencias y problemas para que se
puedan plantear Registros de Problemas independientes, 7.6  Gestión de Accesos
para abordar las causas subyacentes de las incidencias,
Gestión de Accesos usa una gran variedad de tecnologías,
aunque vinculados con las incidencias relacionadas. La
principalmente:
funcionalidad de los Registros de Problemas deberá
ser similar a aquellas necesarias para los Registros de ■■ Tecnología de Gestión de Recursos Humanos para
Incidencias, y también deberá permitir la correspondencia validar la identidad de los usuarios y hacer el
de múltiples incidencias con respecto a Registros de seguimiento de su estado
Problemas. ■■ Tecnología de Servicios de Directorio (vea la sección
5.8 para disponer de una descripción de Servicios de
7.5.2 Gestión de Cambios Directorio). Esta tecnología permite a los gestores de
La integración con Gestión de Cambios es muy tecnología asignar nombres a recursos en una red y
importante, para que los Registros de Peticiones, Eventos, a continuación proporcionar acceso a esos recursos
Incidencias y Problemas puedan asociarse con las RFCs basándose en el perfil del usuario. Las herramientas
que hayan causado problemas. Esto se hace para evaluar de Servicios de Directorio también permiten que la
el éxito del proceso de Gestión de Cambios, además de Gestión de Accesos cree roles y grupos y los vincule
los Registros de Incidencias y de Errores Conocidos, y para con usuarios y recursos
que las RFC puedan plantearse fácilmente para controlar ■■ Funcionalidades de Gestión de Accesos en
las actividades necesarias para resolver problemas que se Aplicaciones, Middleware, Sistemas Operativos y
hayan identificado a través del Análisis de la Causa Raíz o Sistemas Operativos en Red
del Análisis Proactivo de Tendencias. ■■ Sistemas de Gestión de Cambios
■■ Tecnología de Gestión de Peticiones (vea la sección 7.4)
7.5.3 CMS integrado
También es importante disponer de un CMS integrado 7.7  Centro de Servicio al Usuario
que permita vincular Registros de Problemas con los
componentes afectados y con los servicios que se han Deberán proveerse las herramientas y el soporte técnico
visto impactados, y con cualquier otro CI relevante. adecuados para permitir que el personal del Centro de
Servicio al Usuario lleve a cabo sus roles de la manera más
Gestión de la Configuración forma parte de un SKMS eficaz y eficiente. Esto incluirá lo siguiente.
mayor que incluye vínculos con muchos de los
repositorios de datos que se utilizan en Operaciones 7.7.1 Telefonía
del Servicio. El proceso y las prácticas de Gestión de
Debido a que es probable que los usuarios planteen la
la Configuración y los requisitos de las tecnologías
mayoría de las incidencias a través de llamadas telefónicas,
subyacentes están incluidos en la publicación Transición
el Centro de Servicio al Usuario deberá estar provisto
del Servicio.
con servicios de telefonía modernos y adecuados. Estos
incluirán:
7.5.4 Base de Datos de Errores Conocidos
■■ Un sistema de distribución automática de llamadas
Una KEDB eficaz es un requisito esencial debiendo facilitar
el almacenamiento y recuperación de los datos de Errores (ACD) para permitir un único número de teléfono
Conocidos. (o números si se prefiriera la opción de un Centro
de Servicio al Usuario distribuido o segmentado) y
Será necesario disponer de buenas utilidades para crear capacidades de distribución entre grupos. Advertencia:
informes de gestión, lo que permitirá cargar datos Si las opciones se ofrecieran a través del ACD, a través
automáticamente sin tener que volver a insertarlos, del teclado o de la selección por Reconocimiento
además de poder profundizar en el Análisis de Interactivo de Voz (IVR), no use demasiados niveles de
Incidencias y Problemas. opciones ni ofrezca opciones ambiguas. Por otra parte,
no incluya opciones ‘sin salida’ u opciones que, una
 Consideraciones sobre la tecnología | 177

vez elegidas, no permitan al usuario volver al menú Para facilitar esto, es necesaria una funcionalidad que
anterior. categorice y recupere Errores Conocidos previos usando
■■ Programa de interfaz de llamadas (CTI) que permita patrones coincidentes y búsqueda de palabras clave con
identificar a usuario que llama (a través de un ACD respecto a los síntomas. La Gestión de Problemas es
vinculado) y así rellenar de forma automatizada los responsable de la KEDB, aunque el Centro de Servicio al
detalles del usuario en el registro de incidencias desde Usuario ayudará a acelerar el tratamiento de incidencias.
el CMS.
■■ VoIP – el uso de esta tecnología puede reducir 7.7.2.2  Scripts de diagnóstico
significativamente los costes de telefonía sobre Los scripts de diagnóstico multinivel deberían
todo si se gestionan usuarios remotos y llamadas desarrollarse, almacenarse y gestionarse para permitir
internacionales al personal del Centro de Servicio al Usuario precisar
■■ Software de generación de estadísticas para permitir la causa de los fallos. Se deberá solicitar a los grupos y
recopilar estadísticas de telefonía y explotarlas/ suministradores especialistas de soporte que proporcionen
imprimirlas para su análisis. Esto debería permitir detalles de los fallos más probables y se tendrá
obtener la siguiente información para cualquier que responder a las preguntas clave para identificar
periodo seleccionado: exactamente lo que ha ido mal y disponer de detalles de
●● Número de llamadas recibidas, en total y las acciones de resolución a tomar.
abortadas por algún corte, si se hubiera elegido un Estos detalles deberán incluirse en scripts sensibles al
enrutamiento de llamadas mediante una opción de contexto que aparezcan en pantalla, dependiendo de la
teclado o sistema IVR categorización multinivel de la incidencia, y deberán estar
●● Tiempos de respuesta y perfiles de recepción de dirigidos por las respuestas del usuario a las preguntas
llamadas que se le realizan para determinar el diagnóstico.
●● Tasas de abandono de llamadas
7.7.2.3  Interfaz web de Autoayuda
●● Tasas individuales de atención de llamadas por
operador del Centro de Servicio al Usuario En muchas ocasiones será rentable y provechoso
●● Duración media de las llamadas
proporcionar alguna funcionalidad de ‘Autoayuda’
automatizada para que los usuarios puedan buscar y
●● Auriculares manos libres con capacidades
obtener ayuda y que les permita resolver sus propias
de acceso dual (en al menos algunos de los
dificultades. Idealmente, esto se debería hacer a través de
auriculares) para su uso durante la formación de
una interfaz web 24x7 que de uso sencillo mediante la
nuevo personal, etc.
selección de menús y que pudiera incluir, por ejemplo:
7.7.2  Herramientas de soporte ■■ Preguntas más frecuentes (FAQ) y soluciones.
■■ Capacidades de búsqueda de ‘Cómo hacerlo’ – para
Existe una gama de herramientas independientes de
guiar a los usuarios a través de una lista de tareas o
soporte del Centro de Servicio al Usuario disponibles en el
actividades sensibles al contexto.
mercado, y algunas organizaciones podrían decidir producir
sus propios sistemas de gestión/registro de incidencias ■■ Un servicio de tipo boletín que contenga detalles de
simples. Si una organización quiere implementar seriamente aspectos/problemas destacados del servicio junto con
ITSM, entonces se requerirá un conjunto de herramientas tiempos de restauración previstos.
de ITSM totalmente integradas que tenga un CMS como ■■ Capacidades de cambio de contraseña – usando
soporte y que proporcione soporte integrado para todos los software de protección de contraseñas para
procesos definidos por ITIL. comprobar identidades, que permita procesos de
autorización y cambio de las contraseñas sin la
Los elementos específicos de tales herramientas, que serán necesidad de la intervención del Centro de Servicio al
particularmente beneficiosas para el Centro de Servicio al Usuario.
Usuario, incluirán lo siguiente.
■■ Descargas de complementos de software (parches,
paquetes de servicio, corrección de errores, etc.,
7.7.2.1  Base de Datos de Errores Conocidos
si se determina que el usuario tiene la versión
Debería usarse una KEDB integrada para almacenar detalles incorrecta o se necesita un arreglo) – las herramientas
de incidencias/problemas previos y sus resoluciones, de están disponibles para automatizar el proceso de
forma que si se vuelven a producir puedan diagnosticarse y comprobación, para comparar la imagen del puesto
solucionarse con más rapidez. con la versión ‘estándar’ acordada y para permitir
178 | Consideraciones sobre la tecnología

que se ofrezcan y acepten actualizaciones si fuera el control del puesto de trabajo del usuario para poder
necesario. dirigir investigaciones o corregir configuraciones, etc. Será
■■ Reparaciones de software – si se detectara que se necesario disponer de medios para permitir este nivel de
pudiera haber producido una corrupción del software, control remoto.
permitir arreglos, retirada y/o reinstalación del
software. 7.7.3  Planificación de la Continuidad de los
■■ Peticiones de desinstalación de software – Servicios de TI para herramientas de soporte
completadas automáticamente con cualquier licencia de ITSM
que se devolverá al conjunto. Es probable que las organizaciones pasen a ser
■■ Descargas de paquetes de software adicionales – rápidamente dependientes de sus herramientas de
las herramientas están disponibles para comprobar ITSM por lo que el trabajo pasa a ser difícil sin ellas.
políticas de software predefinidas y para descargar Deberá realizarse un Análisis de Impacto en el Negocio
paquetes de software adicionales, si estuvieran y un Análisis de Riesgos, para luego planificar métodos
cubiertos por estas políticas. Esto puede incluir que garanticen los niveles adecuados de capacidad de
comprobaciones automatizadas de licencias de recuperación y de Continuidad del Servicio de TI.
software y aprobaciones financieras, además de la
actualización del CMS.
■■ Advertencia con antelación cualquier parada
planificada o interrupción o degradación de los
servicios.
La solución de autoayuda deberá incluir la capacidad de
que los propios usuarios registren las incidencias, incluso
durante los periodos en los que se cierre el Centro de
Servicio al Usuario (si no estuviera operativo 24x7) Estas
incidencias serán atendidas por el personal del Centro de
Servicio al Usuario al comienzo del siguiente turno.
Tendrán que tomarse algunas precauciones para garantizar
que las actividades de Autoayuda seleccionadas para hacer
partícipes a los usuarios del proceso no sean demasiado
avanzadas para el usuario medio, y que se incluyan
medios para evitar que ‘el conocimiento limitado se
convierte en peligroso’. Se podrían establecer medios
ligeramente más avanzados de Autoayuda para ‘Super
Usuarios’, aquellos que hayan tenido una formación
adicional. También es necesario extremar el cuidado con
respecto al entrenamiento que se le da al personal de un
Centro de Servicio al Usuario en relación con la cantidad
de usuarios que harán uso de la Autoayuda.
Nota: Como ya se recogió en la lista anterior, es posible
combinar algunas actividades simples de Gestión de
Peticiones como parte de un sistema de Autoayuda
general, lo que también puede representar un beneficio
significativo a la hora de reducir llamadas al Centro de
Servicio al Usuario (vea el párrafo 7.1.1 para disponer de
más detalles).

7.7.2.4  Control remoto

Como ya se ha establecido, aunque se repita aquí para
completarlo, en muchas ocasiones será útil para los
Analistas del Centro de Servicio al Usuario poder tomar
Consideraciones de la
implementación 8
 | 181

8 Consideraciones de la implementación
Debería tenerse en cuenta que Operación del Servicio ■■ Cambios de gestión o de personal (desde la pérdida
es una fase en un ciclo de vida y no una entidad de o transferencia de individuos hasta adquisiciones o
pleno derecho. Para que un servicio, proceso, estructura absorciones)
organizativa o tecnología esté operando, se tiene que ■■ Cambio de los niveles de servicio o en la provisión del
haber implantado primero. Sin embargo, existen varios servicio – externalización, internalización, asociaciones,
procesos y funciones descritos en esta publicación, que etc
hacen importante recordar las consideraciones de la
implementación que deben haberse abordado en el 8.1.2 Evaluación del cambio
momento en el que el servicio entra en operación. El personal de Operación del Servicio deberá estar
Se han cubierto varias de estos en la sección pertinente. implicado en la evaluación de todos los cambios para
Por ejemplo, en el Capítulo 6 se ofrecen directrices sobre asegurar que se tengan en cuenta completamente
las estructuras organizativas y roles. Esto no se repetirá todos los aspectos operativos. Esta implicación deberá
aquí. Más bien, esta sección se centrará en alguna directriz comenzar lo antes posible (vea el párrafo 4.6.1) no sólo
genérica de implementación para Operación del Servicio en las últimas etapas de cambio, es decir, como miembro
en sentido general. del CAB y ECAB, momento en el cual se habrán tomado
muchas decisiones fundamentales y es probable que la
influencia sea muy limitada. El Gestor de Cambios deberá
8.1  Gestión del cambio en Operación informar a todas las partes afectadas del cambio que
del Servicio se está evaluando, para que la información pueda estar
Operación del Servicio deberá esforzarse para lograr preparada y disponible antes de las reuniones del CAB.
estabilidad, aunque no estancamiento. Existen muchas Sin embargo, es importante que el personal de Operación
razones ventajosas y válidas para afirmar que ‘el cambio del Servicio se implique en estas últimas etapas ya que
es algo bueno’, pero el personal de Operación del Servicio podrían estar implicados en la implementación real
debe garantizar que cualquier cambio se absorba sin y querrán que se garantice una planificación precisa
impactos negativos en la estabilidad de los servicios de TI para evitar discusiones potenciales o momentos
que se están ofreciendo. particularmente delicados.

8.1.1 Disparadores del cambio 8.1.3 Medida de cambio exitoso

Existen muchas cosas que pueden disparar un cambio en La medida definitiva del éxito con respecto a los
el entorno de Operación del Servicio. Incluyen: cambios realizados en Operación del Servicio es que los
■■ Hardware o componentes de red nuevos o clientes y usuarios no experimenten ninguna variación o
actualizados interrupción del servicio. En la medida de lo posible, los
■■ Software de aplicaciones nuevas o actualizadas efectos de los cambios deberían ser invisibles, excepto las
■■ Software de sistema nuevo o actualizado (sistemas mejoras en la funcionalidad, calidad o ahorro financiero
operativos, utilidades, middleware, etc.) incluyendo que puedan resultar del cambio.
parches y correcciones.
■■ Cambios legislativos, de conformidad o de gobierno 8.2  Operación del servicio y Gestión
■■ Obsolescencia – algunos componentes se quedan de Proyectos
anticuados o el fabricante deja de mantenerlos
Ya que Operación del Servicio generalmente se ve como
■■ Imperativo del negocio – tiene que ser flexible a la algo que sigue haciendo lo mismo y que normalmente
hora de trabajar en ITSM, particularmente durante se centra en ejecutar procedimientos definidos de forma
Operación del Servicio, y habrá muchas ocasiones estándar, existe una tendencia a no usar procesos de
en las que el negocio necesite cambios de TI para Gestión de Proyectos cuando de hecho, sería apropiado
cumplir requisitos que son dinámicos hacerlo. Por ejemplo, las actualizaciones importantes de la
■■ Mejoras en los procesos, procedimientos y/o infraestructura, o el despliegue de procedimientos nuevos
herramientas subyacentes para mejorar la entrega de o modificados, son tareas importantes en las que Gestión
TI o reducir los costes financieros
182 | Consideraciones de la implementación

de Proyectos podría servir para mejorar el control y la 8.4  Personal de operaciones en

gestión de costes/recursos. Diseño y Transición del Servicio
El uso de la Gestión de Proyectos para gestionar estos Todos los grupos de TI estarán implicados durante Diseño
tipos de actividades, podría tener los siguientes beneficios: del Servicio y Transición del Servicio para garantizar que
■■ Los beneficios del proyecto se establecen y acuerdan los nuevos componentes o servicios se diseñen, prueben
claramente o implementen para proporcionar los niveles correctos de
■■ Existe más visibilidad de lo que se está haciendo funcionalidad, facilidad de uso, disponibilidad, capacidad,
y cómo se está gestionando, lo que facilita a los etc.
demás grupos de TI y al negocio cuantificar las Adicionalmente, el personal de Operación del Servicio
contribuciones realizadas por equipos operativos deberá implicarse durante las primeras etapas de Diseño
■■ Esto a su vez facilita la obtención de fondos para del Servicio y de Transición del Servicio para garantizar
proyectos de los que tradicionalmente ha sido difícil que cuando los nuevos servicios lleguen al entorno de
justificar los costes producción, se ajusten al propósito desde una perspectiva
■■ Mayor consistencia y mejora de la calidad de Operación del Servicio, y que se les pueda dar soporte
■■ El logro de los objetivos genera mayor credibilidad en el futuro.
para grupos operativos. En este contexto, “poder darles soporte” significa:
■■ Que se les pueda dar soporte desde un punto de vista
8.3  Evaluación y gestión del riesgo técnico y operativo a partir de recursos existentes o
en Operación del Servicio con recursos o capacidades adicionales que se hayan
Habrá ocasiones en las que sea imperativo que la acordado previamente
evaluación de riesgos para Operación del Servicio se ■■ Que no se produzca un impacto negativo en otras
realice con rapidez y se actúe en consecuencia. prácticas de trabajo, técnicas u operacionales, procesos
o planificaciones
El área más obvia se encuentra en la evaluación del
■■ Que no haya costes operativos inesperados o en curso
riesgo de cambios potenciales o de Errores Conocidos
o gastos de soporte crecientes
(ya cubiertos en otras secciones de la publicación), pero
■■ Que no haya ninguna complicación contractual o legal
además el personal de Operación del Servicio podría
inesperada
necesitar involucrarse en la evaluación del riesgo y del
impacto de: ■■ Que no haya rutas complejas de soporte entre
múltiples departamentos de soporte de organizaciones
■■ Fallos reales o potenciales – de los que haya externas.
informado Gestión de Eventos o Gestión de
Incidencias/Problemas, o advertencias comunicadas Nota: El cambio no se hace únicamente en relación con la
por fabricantes, suministradores o contratistas tecnología. También requiere formación, concienciación,
cambio cultural, motivación y mucho más. En la
■■ Nuevos proyectos que darán como resultado, en
publicación Transición del Servicio se recogen más detalles
última instancia, su puesta en producción
relacionados con una gestión más amplia del cambio.
■■ Riesgo del entorno (que abarca riesgos del tipo de
Continuidad del Servicio de TI con entorno físico
y local, además de riesgos asociados a relaciones 8.5  Planificación e Implementación
políticas, comerciales o industriales) de las tecnologías de Gestión del
■■ Suministradores, especialmente si se trata de nuevos Servicio
recursos o si los componentes clave del servicio
Existen varios factores que las organizaciones necesitan
estuvieran bajo el control de terceros
planificar para prepararse para y durante el despliegue e
■■ Riesgos de seguridad – tanto teóricos como reales
implementación de las herramientas de soporte de ITSM.
que surjan de incidencias o eventos asociados con la
Entre ellos se incluye:
seguridad
■■ Nuevos clientes/servicios a dar soporte. 8.5.1 Licencias
El coste total de las herramientas de ITSM, particularmente
la herramienta integrada que formará el núcleo del
conjunto de herramientas requerido, estará determinado
 Consideraciones de la implementación | 183

normalmente por el número y tipo de licencias de usuario suele ser menor, por lo que los costes generales se
que necesite la organización. reducen bastante.
En muchas ocasiones tales herramientas se venden en Tenga en cuenta que algún personal podría requerir
formato modular, por lo que se necesitará entender acceder a múltiples licencias (p. ej., el personal de soporte
perfectamente la funcionalidad exacta de cada modulo podría requerir una licencia dedicada o compartida en la
y deberá realizarse algún dimensionamiento inicial para oficina durante el día, pero podría requerir una licencia
determinar cuántos, y qué tipo de, usuarios necesitarán web para proporcionar soporte desde casa). Asimismo,
acceso a cada módulo. las licencias podrían requerirse para clientes/usuarios/
suministradores que usen la misma herramienta para
Las licencias normalmente estarán disponibles en los
introducir, ver o actualizar registros o informes.
siguientes tipos (la terminología exacta podría variar
dependiendo del suministrador de software). Nota: Algunos acuerdos de licencias (de cualquiera de los
tipos mencionados anteriormente) podrían restringir el uso
8.5.1.1  Licencias dedicadas del software para un dispositivo individual o CPU.
Usadas por el personal que requiere un uso frecuente y
prolongado del módulo (p. ej., el personal del Centro de 8.5.1.4  Servicio bajo demanda
Servicio al Usuario necesitaría una licencia dedicada para Ha habido una tendencia dentro de la industria de TI
usar un módulo de Gestión de Incidencias). de suministradores a ofrecer aplicaciones de TI ‘bajo
demanda’, donde se permite el acceso a la aplicación
8.5.1.2  Licencias compartidas durante un periodo de demanda y a continuación se
Para el personal que hace un uso regular del módulo, pero interrumpe cuando no se necesita por más tiempo– el
con intervalos significativos entre cada uso, se podrán coste se carga según la base del tiempo consumido en el
usar normalmente licencias compartidas (p. ej., el personal uso de la aplicación. Este tipo de oferta la hacen algunos
de soporte de tercera línea podría necesitar un acceso suministradores de herramientas de ITSM lo que podría
regular a un módulo de Gestión de Incidencias, pero ser atractivo para organizaciones más pequeñas o si las
sólo en los momentos en los que están actualizando un herramientas en cuestión fueran muy especializadas o se
registro de incidencias). Es necesario estimar el índice de usaran con relativamente poca frecuencia.
licencias requeridas para los usuarios, para poder comprar Una alternativa sería ofrecer el uso de una herramienta
el número. Esto dependerá del número de usuarios como parte de una asignación de consultoría específica
potenciales, de la duración de los periodos de uso y de la (p. ej., consultoría especializada en Gestión de Capacidad,
frecuencia esperada entre usos para proporcionar un nivel es decir, podría ofrecer un paquete de consultoría de
estimado de concurrencia. Planificación de la Capacidad regular pero relativamente
El coste de una licencia compartida normalmente infrecuente, y proporcionar el uso de las herramientas
es mayor que el de las licencias dedicadas, pero el durante la duración de la asignación). En tales casos, es
coste global es menor cuando los usuarios las están probable que las tarifas de licencias se incluyan como
compartiendo, por lo que se necesitarán menos licencias parte o como un añadido a la tarifa de consultoría.
totales. Mayor variación se produce cuando se licencia y carga el
software por agente/actividad. Un ejemplo de esto es el
8.5.1.3  Licencias web software de consulta/monitorización y/o simulación (p. ej.,
Permitir alguna forma de “interfaz ligera” a través de software de agente que puede simular rutas predefinidas
acceso web para las capacidades de la herramienta, de clientes a través del sitio web de una organización
normalmente será adecuado para el personal que requiera para evaluar e informar en base al rendimiento y
acceso remoto, que sólo acceda ocasionalmente, o que disponibilidad). Este software se carga típicamente sobre la
sólo use un pequeño subconjunto de la funcionalidades base del número de agentes, su ubicación y/o el nivel de
(p. ej., personal de ingeniería que desea registrar los actividad generada.
detalles de acciones tomadas en incidencias o usuarios En todos los casos, deberán investigarse y entenderse
que sólo desean registrar una incidencia directamente). perfectamente todos los informes relacionados con la
Normalmente las licencias web cuestan mucho menos estructura de licencias durante el periodo de consultas de
que otras licencias (incluso podrían ser gratuitas si se compras y antes de que se desplieguen herramientas para
adquirieran con otras licencias), y el índice de uso también que los costes finales no generen ningún tipo de sorpresa.
184 | Consideraciones de la implementación

8.5.2 Despliegue demasiado pronto, podrán verse como una panacea

Muchas herramientas de ITSM, particularmente las inmediata y cualquier acción necesaria para cambiar
herramientas de Descubrimiento y de Monitorización de procesos, prácticas de trabajo o actitudes podría quedar
Eventos, requerirán desplegar algún software de cliente/ obstaculizada o descuidada.
agente en todas las ubicaciones objetivo antes de que Normalmente una única herramienta no será suficiente
se puedan utilizar. Esto necesitará una planificación y para hacer que las cosas funcionen mejor. Existe un viejo
ejecución precisas, y deberán abordarse a través de dicho que dice: ‘Un tonto con una herramienta todavía
procesos de Gestión de Versiones y Despliegues formales sigue siendo tonto’
(vea la publicación Transición del Servicio).
Lo primero que debe hacer la organización es examinar
Incluso cuando sea posible el despliegue en red, se los procesos a los que se dirigirá la herramienta, y
requerirá una planificación y pruebas precisas, y los garantizar también que se ‘introduzca’ al personal en los
registros deberán mantenerse a lo largo del despliegue nuevos procesos y en la forma de trabajo, y que éstos
para que el personal de soporte tenga conocimiento de hayan adoptado una ‘cultura del servicio’.
quién ha sido actualizado y quién no. Podría ser necesaria
Sin embargo, en muchas ocasiones las herramientas
alguna forma de Gestión de Cambios temporal y el CMS
pueden hacer las cosas realidad para muchas personas.
deberá actualizarse según avanza el despliegue.
Éstas son tangibles y el personal técnico puede ver
En muchas ocasiones es necesario reiniciar los dispositivos inmediatamente cómo los nuevos procesos pueden
para que se pueda reconocer el software cliente, algo que funcionar y cómo podrían mejorar su forma de trabajo.
habrá que planear con anticipación ya que de lo contrario
Algunos procesos no se pueden llevar a cabo sin las
se podrían producir amplios retrasos si el personal no
herramientas adecuadas por lo que existe un equilibrio
apagara de forma general sus ordenadores de escritorio
preciso a alcanzar para asegurar que las herramientas se
durante la noche.
introduzcan cuando se necesiten, pero no antes.
Podría haber problemas particulares a la hora del
De forma similar, se tiene que poner atención para
despliegue de este software en PCs de sobremesa u otros
asegurar que se proporcione formación sobre cualquier
equipos portátiles por lo que podrían ser necesarias
herramienta en el punto correcto, no con demasiada
acciones especiales para que los usuarios vuelvan a iniciar
anticipación, lo que provocaría la reducción o pérdida de
sesión y se reciba e instale así el nuevo software.
conocimiento, pero con la suficiente antelación como para
que el personal pueda formarse formalmente y pueda
8.5.3 Comprobaciones de la capacidad
familiarizarse con la operación de las herramientas y con
Podría ser necesaria cierta Gestión de Capacidad el entorno activo. Deberá planificarse una formación
de forma anticipada para garantizar que todas las adicional durante un periodo adicional cuando las
ubicaciones objetivo tengan la suficiente capacidad de herramientas pasen a estar operativas y en el futuro,
almacenamiento y procesamiento para alojar y ejecutar el cuando sea necesario.
nuevo software. Las ubicaciones que no tengan suficiente
capacidad necesitarán actualizarse o sustituirse y los 8.5.5 Tipo de presentación
tiempos de espera de estas acciones deberán incluirse en
Se necesita tomar una decisión sobre el tipo de
los planes.
presentación que es necesario tener, ya sea una
La capacidad de la red también debería comprobarse introducción del tipo ‘Big Bang’ o por fases. Dado que
para establecer si puede abordar la transmisión de la la mayoría de las organizaciones no comenzarán desde
información de gestión, la transmisión de logs y la una situación completamente nueva y tendrán servicios
distribución de clientes, y también posiblemente del activos que se seguirán ejecutando durante el arranque,
software y archivos de configuración. probablemente será necesario utilizar un método
organizado en fases.
8.5.4 Programación del despliegue de la
En muchos casos, una nueva herramienta sustituirá a una
tecnología herramienta antigua, probablemente menos sofisticada,
IEs necesario asegurarse que las herramientas se y el periodo de tiempo entre el apagado de una y el
desplieguen en el momento adecuado en relación arranque de la otra será otro factor a planificar.
con el nivel de sofisticación y conocimiento de ITSM
En muchas ocasiones esto implicará decidir qué datos es
de la organización. Si las herramientas se desplegaran
necesario transferir desde la herramienta antigua hasta la
 Consideraciones de la implementación | 185

nueva, y esto podría requerir un cambio de formato para

lograr los resultados que se necesitan. Idealmente, esta
transferencia debería poder hacerse electrónicamente,
pero en algunos casos podría ser inevitable tener que
volver a introducir una pequeña cantidad de datos activos,
lo cual se deberá sopesar en la planificación.
Precaución: normalmente las herramientas más antiguas
dependen de una entrada y mantenimiento manual de
los datos por lo que si se estuviera usando la migración
electrónica de los datos, deberá realizarse una auditoría
para verificar la calidad de los mismos.
Si la transferencia de datos se complicara o consumiera
tiempo para lograrlo, una alternativa podría ser permitir
un periodo de ejecución en paralelo, permitiendo que
la herramienta antigua siga estando disponible durante
un periodo inicial junto con la nueva, para que se pueda
hacer referencia a estos datos si fuera necesario. En tales
casos, será prudente hacer que la herramienta antigua sea
de ‘sólo lectura’ para que no se puedan cometer errores
a la hora de registrar nuevos datos en la herramienta
antigua.
Puede encontrar todos los detalles sobre el proceso de
Gestión de Versiones y Despliegues en la publicación
Transición del Servicio.
Desafíos, Factores Críticos
de Éxito y riesgos 9
 | 189

9 Desafíos, Factores Críticos de Éxito y riesgos

9.1  Desafíos
Anécdotas
Existen varios desafíos que se afrontan dentro de Una organización utiliza una ‘Política de Transición
Operación del Servicio y que es necesario superar. Éstos hacia Operaciones’ para garantizar que los servicios
incluyen aquellos establecidos en esta sección. que se están desplegando hayan tenido el nivel
apropiado de entrada desde los equipos operativos.
9.1.1 Falta de implicación con el personal Representa básicamente una política que muestra
de desarrollo y de proyectos claramente las circunstancias bajo las que una
Tradicionalmente, siempre ha habido una separación aplicación está ‘preparada’ para la transición hacia
entre el personal de Operación del Servicio y el personal Operaciones. Esto mejoró la comunicación con
implicado en el desarrollo de nuevas aplicaciones o en los equipos de desarrollo y proyecto y también
la ejecución de proyectos que eventualmente entregarán proporcionó un conjunto de directrices claras sobre
nuevas funcionalidades al entorno de producción. cómo trabajar con los equipos operativos.
Otra organización usa Casos de Uso de Operaciones
Esta separación se consideró e impulsó originalmente
para conseguir que los equipos de desarrollo incluyan
debido al deseo de prevenir “complots” y evitar riesgos
los requisitos que deberá cumplir la aplicación
potenciales de seguridad (en algunas organizaciones
en producción bajo el control del personal de
todavía es un requisito legislativo). Sin embargo, en lugar
Operaciones.
de usar esta separación de tareas para crear contribuciones
positivas, en muchas organizaciones representa una fuente
de rivalidad y de maniobras políticas. 9.1.2  Justificación de los fondos
En demasiadas ocasiones, ITSM se ve como algo que se En muchas ocasiones es difícil justificar el gasto en el área
ha iniciado en las áreas operativas y que no tiene que ver de Operación del Servicio debido a que el dinero gastado
nada con el desarrollo o con proyectos. en esta área con frecuencia se asocia con ‘costes de la
infraestructura’, sin nada nuevo que ofrecer a la inversión.
Esta visión es muy dañina debido a que el momento
adecuado para pensar en los aspectos de Operación La publicación Estrategia del Servicio analiza cómo
del Servicio es al comienzo de los nuevos desarrollos y garantizar un Retorno de la Inversión y eliminar la
proyectos, cuando todavía hay tiempo para incluir estos percepción de la inversión como un gasto puramente
factores en las etapas de planificación. de Infraestructura. Se ofrece una buena guía sobre cómo
justificar la inversión.
Las publicaciones Diseño del Servicio y Transición del
Servicio describen los pasos necesarios para garantizar que En realidad, muchas inversiones en ITSM, particularmente
se consideren los aspectos de Operaciones desde el inicio en las áreas de Operación del Servicio, pueden ahorrar
de los nuevos desarrollos y proyectos. dinero y mostrar un Retorno de la Inversión positivo,
además de mejorar la calidad del servicio. Algunos
ejemplos de áreas potenciales de ahorro incluyen:
■■ Reducción de costes de licencia de software a través
de la mejora de la gestión de licencias y de las copias
desplegadas
■■ Reducción de los costes de soporte debido a menos
incidencias y problemas y a la reducción de los
tiempos de resolución
■■ Reducción del personal a través de la racionalización
de la fuerza de trabajo, roles de soporte y estructuras
de control de costes
■■ Menos ‘negocio perdido’ debido a la mala calidad del
servicio de TI
190 | Desafíos, Factores Críticos de Éxito y riesgos

■■ Mejor uso de los equipos existentes de la ■■ Las dos etapas en el ciclo de vida tienen métricas
infraestructura y aplazamiento de más gastos debido a diferentes que impulsan a Diseño del Servicio a
una mejor capacidad de gestión completar el proyecto a tiempo, conforme a las
■■ Procesos mejor alineados, que permite duplicar menos especificaciones y al presupuesto. En muchos casos,
actividades y mejorar el uso de los recursos existentes. es difícil prever la apariencia del servicio y cuánto
costará después de que se haya desplegado y operado
9.1.3  Desafíos para los Gestores de durante algún tiempo. Si no funcionara como cabría
Operación del Servicio esperar, se considera que Gestión de Operaciones
de TI es la responsable. Aunque este desafío siempre
A continuación se muestra una lista de algunos retos que
será una realidad en Gestión del Servicio, se puede
los Gestores de Operación del Servicio deberían esperar
abordar mediante la implicación activa en la etapa de
afrontar. No existen soluciones fáciles para estos desafíos,
Transición del Servicio del ciclo de vida. El objetivo de
principalmente porque son subproductos de la cultura
Transición del Servicio es garantizar que los servicios
de la organización y de las decisiones tomadas durante
diseñados operen según lo esperado y que el Gestor
el proceso de creación de la estructura organizativa. El
de Operaciones pueda proporcionar el conocimiento
propósito de la inclusión de la lista es garantizar que los
necesario a Transición del Servicio para evaluar y
Gestores de Operación del Servicio sean conscientes de
solucionar problemas antes de que se conviertan en
los desafíos a los que se enfrentan y puedan crear un plan
problemas en el entorno operativo.
para abordarlos.
■■ Transición del Servicio no se utiliza de forma eficaz
Las diferencias entre las actividades de Diseño y las para gestionar la transición entre las fases de Diseño
actividades Operativas continuará planteando desafíos. y Operación. Por ejemplo, puede que algunas
Esto se debe a varias razones, incluyendo las siguientes. organizaciones sólo usen Gestión de Cambios para
■■ Diseño del Servicio podría tender a centrarse en un programar el despliegue de cambios que ya se han
servicio individual cada vez, mientras que Operación realizado, más que probar si el cambio realizará
del Servicio tiende a centrarse en la entrega y soporte satisfactoriamente la transición entre Diseño y
de todos los servicios al mismo tiempo. Los Gestores Operación. Es de gran importancia que se respeten
de Operaciones deberían trabajar estrechamente con las prácticas de Transición del Servicio y las políticas
Diseño del Servicio y Transición del Servicio para de la organización para evitar que las prácticas de
aportar la perspectiva de Operaciones que garantice Cambios se gestionen deficientemente. Los Gestores
que el diseño y transición ofrezcan soporte a todas las de Operación, Cambios y Transición deberán tener la
necesidades operativas. autoridad para denegar cualquier cambio en el entorno
■■ En muchas ocasiones Diseño del Servicio puede
de operación, sin excepción, que no se haya probado
aplicarse en proyectos, mientras que Operación del a conciencia.
Servicio se centra en procesos y actividades de gestión Estos desafíos sólo se podrán abordar si el personal de
repetibles y continuos. El resultado de esto es que Operación del Servicio se implica en Diseño y en Transición
el personal operativo en muchas ocasiones no está del Servicio, y esto requerirá que se les asignen tareas y se
disponible para participar en actividades de proyecto les mida a la hora de realizarlas. Los Roles identificados en
de Diseño del Servicio, lo que a su vez hace que los procesos de Diseño del Servicio deberán incluirse en las
los servicios de TI sean difíciles de operar, o que no descripciones de trabajo del personal de Gestión Técnica
incluyan los elementos de diseño de capacidad de y de Aplicaciones de TI, y deberán dedicar cierto tiempo a
gestión adecuados. Además, una vez que el personal cada proyecto.
del proyecto haya finalizado el diseño de un Servicio Otro grupo de desafíos es el que está asociado a la
de TI, podrían pasar al siguiente proyecto y no estar medición. Cada estructura alternativa introducirá diferentes
disponibles para dar soporte a las dificultades que combinaciones de elementos que serán fáciles o difíciles
se presenten en el entorno operativo. Superar este de medir. Por ejemplo, medir el rendimiento de un
desafío requiere que Operación del Servicio planifique dispositivo o de un equipo podría ser relativamente fácil,
las actividades del personal para que se impliquen pero determinar si ese rendimiento es adecuado o no para
activamente en los proyectos de diseño, doten de el Servicio de TI general, es algo totalmente diferente. Un
recursos a las actividades de transición y participen buen proceso de Gestión del Nivel de Servicio ayudará a
en el Soporte Post-Implementación de los servicios resolver esta cuestión, aunque implicará que los equipos
introducidos en el entorno operativo. de Operación del Servicio deban formar parte integrante
 Desafíos, Factores Críticos de Éxito y riesgos | 191

de ese proceso (vea la publicación Mejora Continua del La Gestión Senior deberá proporcionar un soporte visible
Servicio). durante el lanzamiento de nuevas iniciativas de Operación
Un tercer conjunto de desafíos se asocia con el uso de del Servicio (como por ejemplo a través de asistencias
Equipos de Trabajo Virtuales. Las estructuras de gestión a seminarios, firmas en memorandos y anuncios, etc.) y
jerárquica tradicionales se están convirtiendo en estructuras mostrando igualmente un soporte continuo. Se podrían
inadecuadas debido a la complejidad y diversidad de la generar mensajes erróneos si un gestor senior fallara a la
mayoría de organizaciones. Ha surgido un paradigma en la hora de acudir a una reunión de proyecto importante o a
gestión (Gestión por Matriz) donde los empleados tienen un seminario de lanzamiento. Una situación aún peor se
que informar a diferentes fuentes para diferentes tareas. produce cuando los gestores senior respaldan la iniciativa
Esto ha generado una compleja red de responsabilidades verbalmente, pero abusan de su autoridad a la hora de
y un incremento del riesgo de que las actividades no sean motivar para que se eluda la práctica de Operación del
gestionadas adecuadamente. Por otra parte, permite que Servicio.
las habilidades y conocimientos que hay en la organización Los Gestores Senior también deberán facultar a los
estén disponibles cuando se necesiten para dar soporte al Gestores Intermedios que serán responsables directos
negocio. La Gestión del Conocimiento y la representación de Operación del Servicio. Dar apoyo públicamente a la
de las estructuras de autoridad pasan a tener cada vez iniciativa, pero a continuación pasar por alto requisitos
más importancia cuando las organizaciones se expanden y de presupuesto o cambios necesarios, dañará tanto
diversifican. Esto se analiza en la publicación Estrategia del a la implementación como a la iniciativa corriente de
Servicio de ITIL. Operación del Servicio.
Uno de los desafíos más significativos a los que se Los Gestores Intermedios también deberán dar el apoyo
enfrentan los Gestores de Operación del Servicio es el necesario, y demostrarlo, especialmente en la práctica.
equilibrio de muchas relaciones internas y externas. La Si se viera que un gestor intermedio estuviera eludiendo
mayoría de las organizaciones de TI actuales son complejas, o pasando por alto un procedimiento acordado (p. ej.,
y debido a que los servicios se orientan cada vez más al implementar un cambio que no ha pasado a través del
consumo masivo, existe un incremento en el uso de redes proceso Gestión de Cambios), se transmitirá el mensaje
de valor, asociaciones y modelos de servicios compartidos. a los demás de que pueden hacer lo mismo por lo que
Aunque esto representa una ventaja significativa con el procedimiento tiendrá menos valor y se pensará que
respecto a la evolución dinámica de las necesidades del puede ser ignorado por todos. Los Gestores Intermedios
negocio, también se incrementa la complejidad a la hora deberán tomarse muchas molestias para que se conozca
de gestionar los servicios de forma coherente y eficiente, y su apoyo, no sólo verbalmente sino también a través
dificulta la entrega sin fisuras entre cliente y proveedor de de sus acciones y cumplimiento de los procesos y
los servicios. Un Gestor de Operación del Servicio deberá procedimientos de la organización acordados.
invertir en conocimiento y habilidades de gestión de Los Gestores Intermedios también deberán ofrecer todo su
relaciones para ayudar a abordar la complejidad de este respaldo para contratar al personal que dé soporte a los
desafío. procesos, en lugar de aceptar la necesidad de formalizar
Operación del Servicio, y a continuación incrementar la
9.2  Factores Críticos de Éxito carga de trabajo del personal existente para lograr que se
lleve a cabo.
9.2.1 Soporte de gestión
El soporte de la Gestión Intermedia y Senior será 9.2.2 Soporte del negocio
necesario para todas las actividades y procesos de ITSM, Es importante que las Unidades de Negocio también den
particularmente en Operación del Servicio. soporte a Operación del Servicio. Este nivel de soporte
El soporte de la Gestión Senior es crítico para obtener y puede lograrse mucho mejor si el personal de Operación
mantener los fondos y recursos adecuados. En lugar de ver del Servicio implica al negocio en todas sus actividades
a Operación del Servicio como un ‘agujero negro’ para la y están abiertos a la hora de informar sobre sus éxitos y
inversión, la Gestión Senior deberá cuantificar y defender fracasos, y de sus esfuerzos por mejorar.
los beneficios de una buena Operación del Servicio. Será igualmente importante que las Unidades de Negocio
También deberán estar completamente informados de los entiendan, acepten y lleven a cabo el rol que desempeñan
terribles resultados que podrían producirse debido a una en Operación del Servicio. Un buen servicio requiere
Operación del Servicio deficiente. buenos clientes. El cliente tiene la responsabilidad
directa de respaldar y promover dentro del negocio el
192 | Desafíos, Factores Críticos de Éxito y riesgos

cumplimiento de políticas, procesos y procedimientos, 9.2.4  Dotación de personal y retención

como por ejemplo el uso del Centro de Servicio al Usuario Disponer del personal apropiado con las habilidades
para registrar todas las peticiones. apropiadas, es crítico para el éxito de Operación del
Comunicarse regularmente con el Negocio para entender Servicio. Algunos de los retos que es necesario superar
sus preocupaciones y aspiraciones y para obtener son los siguientes.
retroalimentación sobre los esfuerzos realizados para ■■ Los proyectos para nuevos servicios normalmente son
cumplir sus necesidades, será esencial para construir las buenos a la hora de especificar nuevas habilidades
relaciones correctas y para asegurar el soporte continuo. que se requieren, pero con frecuencia se estima por
Por su parte el Negocio deberá estar de acuerdo con los debajo el número de personas que deben componer
costes de la implementación de Operación del Servicio el equipo y cómo retener las nuevas habilidades.
y entender el retorno de la inversión, a menos que ya se Vea el párrafo 9.2.1 para disponer de más ideas
haya acordado como parte del proceso de Diseño. sobre cómo facilitar mejor la comunicación sobre los
requisitos.
9.2.3  Líderes ■■ Carencia de recursos que tengan un buen
Los proyectos de ITSM y la práctica continua que se entendimiento de Gestión del Servicio. Es necesario
desprende de ellos (llevada a cabo por el personal disponer de las personas con buenas habilidades
de Operación del Servicio) son en muchas ocasiones técnicas, pero es necesario también que haya un
más exitosos si se encuentra a uno o más ‘líderes’ que número de personas clave que sean capaces de
puedan liderar a los demás a través de su entusiasmo y moverse entre aspectos tecnológicos y de servicio.
compromiso con ITSM. ■■ Como estos recursos son bastante escasos, es bastante
habitual que después de la formación dejen la
En algunos casos, estos líderes podrían ser gestores senior
empresa y se vayan a otra por un salario mayor. Unos
que estén ejerciendo el liderazgo desde la cima. Pero los
planes de carrera claros y unos buenos incentivos
líderes también pueden tener éxito si proceden de otros
deberían formar parte de cada iniciativa de Gestión
niveles de la organización. Uno o dos miembros júnior del
del Servicio.
personal podrían tener una beneficiosa influencia en un
■■ Intentar asignar demasiadas tareas con demasiada
cierre de éxito.
anticipación al personal existente. El logro de una
En muchas ocasiones los líderes se crean o se ven Operación del Servicio eficiente tardará tiempo,
ampliamente influenciados a través de la formación pero si se aborda correctamente se logrará.
reglada en Gestión del Servicio, particularmente a niveles Desafortunadamente, algunos gestores intentan
más avanzados en los que los beneficios potenciales para reducir coste asignando el trabajo temporal de la
una organización, y para los individuos que emprenden implementación de nuevos procesos y herramientas
una carrera profesional en Gestión del Servicio, pueden al personal existente que ya está muy cargado
explorarse por completo. de trabajo. Invariablemente, el proyecto fallará, o
Se deberá tener en cuenta que los líderes surgen con el el servicio se verá perjudicado llegando incluso
transcurso del tiempo. No pueden crearse o nombrarse. el personal más valioso a dejar la empresa. Los
En muchas ocasiones son los usuarios o clientes los proyectos de éxito de Gestión del Servicio con
que proporcionan la mayor ayuda a la hora de crear frecuencia requieren una inversión a corto plazo para
buenos procesos de Gestión del Servicio, dado que son contrataciones o para personal temporal, hecho que
extremadamente conscientes de las mejoras necesarias no deberá subestimarse.
desde una perspectiva de negocio. Es importante
reconocer que éstos forman parte normalmente de un 9.2.5 Formación en Gestión del Servicio
personal altamente motivado que con frecuencia asume La formación y concienciación adecuadas pueden tener
voluntariamente las cargas de trabajo más importantes. Si beneficios globales mucho más amplios. Además de crear
su aportación fuera la más útil, se les deberá dar tiempo líderes a partir de unos pocos, se puede usar para ganarse
para que trabajen como líderes. los ’corazones y las mentes’ de muchos. El personal
de Operación del Servicio deberá ser consciente de las
consecuencias de sus acciones en la organización, ya
sean malas o buenas, y a todos se les deberá inculcar una
‘cultura de Gestión del Servicio’.
 Desafíos, Factores Críticos de Éxito y riesgos | 193

Es posible disponer de la práctica y de las herramientas independientes siempre que sea posible. La financiación
más refinadas del mundo de Operación del Servicio, pero de tales entornos de prueba será esencial si se desea
Gestión del Servicio no tendrá éxito a menos que las lograr servicios de alta calidad.
personas también se adapten a los objetivos generales de
Adicionalmente, será necesario disponer del tiempo y
Gestión del Servicio. Por lo tanto, la aceptación y respaldo
esfuerzo suficientes para garantizar que las pruebas se
de todo el personal será muy importante, y no deberá
planifiquen y diseñen adecuadamente, para que se incluya
subestimarse el rol de la formación y concienciación, e
el tiempo adecuado para las pruebas y para volver a
incluso de certificaciones que beneficien al individuo.
realizarlas en caso de fallo. La mejor forma de garantizarlo
La formación requerida para el éxito de Gestión del es seguir la guía que se ofrece en la publicación Transición
Servicio incluye: del Servicio.
■■ Formar al personal de TI sobre los procesos que se
han implementado. Esto incluirá formación genérica
9.2.8  Medida y generación de informes
para que entiendan perfectamente los conceptos, Es necesario disponer de una definición clara sobre cómo
además de formación focalizada en los propios se va a medir y cómo va a informar (como se describe
procesos de la organización en el Apéndice B), para que todo el personal tenga
■■ Formación sobre habilidades “interpersonales” claro los objetivos a cumplir y para que los Gestores del
especialmente para aquel personal que está de cara al Negocio puedan revisar rápida y fácilmente el progreso y
cliente determinar con precisión las áreas que necesitan atención.
■■ Formación para que se entienda el negocio y la
importancia de lograr una cultura del servicio 9.3  Riesgos
■■ Si se hubieran implementado herramientas, formación El fallo a la hora de cumplir los desafíos ya descritos en
sobre el uso y gestión de esas herramientas la sección 9.1 o a la hora de abordar los Factores Críticos
■■ Además, los clientes y usuarios necesitan una de Éxito descritos en la sección 9.2, se debe a riesgos
formación adecuada sobre cómo trabajar con TI, obvios, a continuación se describen otros riesgos menos
es decir, acceder a servicios, pedir cambios, enviar evidentes.
peticiones, usar herramientas, etc.
9.3.1  Pérdida del servicio
9.2.6  Herramientas adecuadas
El riesgo final para el negocio con respecto a la
Muchos procesos y actividades de Operación del Servicio vulnerabilidad en Operación del Servicio es la pérdida
no se pueden realizar eficazmente sin las herramientas de servicios críticos de TI con el consiguiente impacto
de soporte adecuadas (como se describió en el Capítulo negativo sobre sus empleados, clientes y finanzas. En
7). La gestión senior deberá asegurarse de que los fondos casos extremos, podría resultar en pérdida potencial de
para tales herramientas se incluyan en los presupuestos y vida o en perjuicios para la integridad física si se utilizaran
permitan su compra, despliegue y soporte. los servicios de TI afectados para propósitos críticos de
seguridad y salud, como por ejemplo salidas de vehículos
9.2.7  Validez de las pruebas de emergencia, dispositivos de radiación médica, etc.
La calidad de los servicios de TI que pueden
proporcionarse en Operación del Servicio depende de la 9.3.2 Riesgos para el éxito de Operación del
calidad de los sistemas y componentes entregados en el Servicio
entorno productivo.
Los riesgos para lograr el éxito en Operación del Servicio
El nivel de calidad mejorará significativamente si son numerosos, y en muchos casos son opuestos a
se prueban completa y adecuadamente los nuevos los Factores Críticos de Éxito, tal y como se describió
componentes y versiones en el momento oportuno. La anteriormente. A esto hay que añadir:
documentación también deberá ser comprobada con
■■ Financiación y recursos inadecuados: Los fondos
respecto a su contenido y calidad.
deberán justificarse, asignarse y mantenerse en reserva
Esto requiere disponer de un entorno de prueba integral para su propósito original.
y realista para todos los sistemas/componentes, que ■■ Pérdida de la oportunidad: Si el personal viera
refleje el entorno operativo en términos de volumen Gestión del Servicio como la ‘moda del momento’
y características. Se debería contar con probadores más que como una forma de cambio permanente de
194 | Desafíos, Factores Críticos de Éxito y riesgos

la forma en la que trabajarán en el futuro, cualquier servicio mejorado, podría sentirse defraudado. Este
ímpetu se perderá como resultado de ello: debe problema deberá resolverse a través de un SLM claro y
aclararse desde el comienzo que se requiere una a través de una comunicación precisa durante Diseño
nueva forma de trabajar. Además, deberán aplicarse del Servicio. Las quejas de esta naturaleza deberán
mecanismos para garantizar que la iniciativa sobreviva recogerse a través de los procesos de Mejora Continua
a los cambios organizativos. del Servicio y no tendrían que implicar simplemente
■■ Pérdida de personal clave: Algunas veces la que Operación del Servicio mejore el servicio
pérdida de una o dos personas clave podría automáticamente bajo demanda.
tener un impacto grave: para intentar minimizar
este efecto, las organizaciones deberán buscar la
formación multidisciplinar del personal y reducir las
dependencias con respecto a los individuos. Esto
se produce especialmente en organizaciones poco
maduras donde el conocimiento todavía no se ha
formalizado en procesos, documentos y herramientas.
Estas organizaciones tienden a depender de los
esfuerzos ‘heroicos’ de algunas personas expertas, y se
ven muy dañadas cuando éstas se marchan.
■■ Resistencia al cambio: Algunas veces las personas
se oponen a lo nuevo y están poco dispuestas
a asumirlo. Ayudará la educación, formación,
comunicación y resaltar los beneficios del cambio.
■■ Falta de soporte de gestión: Esto normalmente
se produce entre Gestores Intermedios que pueden
experimentar dificultades para percibir la visión
general o los beneficios prácticos que el personal
júnior podría obtener. Vea el párrafo 9.2.1 para
disponer de más información sobre esto, aunque
es necesario que los gestores respalden Gestión
del Servicio y participen en las fases y procesos
apropiados de Diseño, Transición y Operación del
Servicio para proporcionar un soporte tangible.
■■ Si el diseño inicial fuera erróneo, una
implementación con éxito no ofrecerá los resultados
esperados, y en última instancia será necesario su
rediseño.
■■ En algunas organizaciones Gestión del Servicio puede
ser vista con desconfianza por TI y el negocio. El
personal de TI la ve como un intento para controlarlos,
mientras que el negocio lo percibe como un intento
por parte de TI para obtener más fondos sin mejorar
realmente ningún aspecto. Los beneficios de Gestión
del Servicio deberían estar claramente articulados para
todos los interesados.
■■ Diferencias con las expectativas del cliente. Aunque
el personal operativo está motivado para realizar sus
tareas con respecto a los estándares, las expectativas
del cliente y del usuario difieren algunas veces. En
otros casos, un cliente de un área determinada podría
haber pagado más por un servicio superior, por lo
que un usuario de otra área, al conocer ese nivel de

Epílogo
 | 197

Epílogo
Una simple realidad deberá guiarnos en Operación
del Servicio. El negocio y la tecnología continuarán
evolucionando en el futuro. Lo que fue innovador el
año pasado ya es algo común este año. Lo que es
mejor práctica al día de hoy será una práctica común
mañana. Lograr la excelencia en Operación del Servicio
requiere flexibilidad, equilibrio y buen juicio en el uso
de las prácticas de ITIL. La guía que se incluye en esta
publicación es una clave para lograr conocimiento,
sabiduría, visión del futuro y la capacidad para equilibrar
las necesidades del negocio de hoy y la demanda del
mañana.
Todas las prácticas comunes, buenas y de futuro
contribuyen al objetivo de la excelencia del servicio.
ITIL las proporciona como base para guiarle hacia este
objetivo.
La estabilidad en un mundo cambiante es la realidad
para los Proveedores de Servicio. Aquellos que destaquen
y sigan siendo los mejores de su clase entienden lo que
aquí se expone y saben que el camino para lograrlo es
adaptarse, aprender, innovar y liderar.
La publicación Operación del Servicio forma parte integral
de una práctica global del Ciclo de Vida de ITSM que,
utilizada junto con la Práctica de ITIL para Gestión del
Servicio, proporciona una poderosa herramienta para
cualquier Proveedor de Servicio.
 Apéndice A:
Guía complementaria
de la industria A
 | 201

Apéndice A: Guía complementaria de la industria

Cuando ITIL se introdujo por primera vez en la década de operando los procesos que se auditarán, aunque es un
los 80, no había nada más disponible en términos de guías material válido que las organizaciones podrían encontrar útil.
“no propietarias” sobre la mejor práctica de ITIL.
Debe tenerse en cuenta que COBIT e ITIL no son
A día de hoy, existen otros marcos de trabajo o ‘competencia’ ni se excluyen mutuamente, por el
metodologías que tienen contribuciones válidas que hacer contrario, se pueden usar en conjunto como parte del
en este área, que complementan y que tienen sinergias marco de trabajo general de gobierno y gestión de una
con ITIL, y que pueden ser de ayuda para Operación del organización. ITIL proporciona a una organización una
Servicio. guía de mejor práctica para gestionar y mejorar su proceso
y entregar servicios de TI de alta calidad y rentables. COBIT
proporciona una guía sobre cómo estos procesos deberían
A1  COBIT
auditarse y evaluarse para determinar si están operando
El marco de trabajo COBIT, generado por la Information como es debido y si proporcionan el beneficio óptimo
Systems Audit and Control Association (ISACA) y para la organización.
gestionado por el IT Governance Institute, proporciona un
Para disponer de una imagen completa general, las
marco de trabajo de referencia muy útil para el personal
organizaciones podrían leer y familiarizarse con lo que
de seguridad y de auditorías de TI.
COBIT tiene que decir a la vez que leen y entienden ITIL.
La versión actual de COBIT, edición 4, incluye 34 Objetivos Puede obtener más detalles del estándar a través de ISACA
de Control de Alto Nivel, 13 de los cuales se agrupan bajo en www.isaca.org
el ‘Dominio de Entrega y Soporte’, que se corresponde
bastante bien con la fase de Operación del Servicio de
ITIL. Éstos se denominan:
A2  ISO/IEC 20000
En diciembre de 2005 la Organización Internacional
■■ DS1 Definir y gestionar niveles de servicio.
de Estándares publicó un estándar internacional, ISO/
■■ DS2 Gestionar servicios de terceros.
ISE 20000, con el que las organizaciones pueden buscar
■■ DS3 Gestionar rendimiento y capacidad.
una acreditación independiente para ITSM. Lo precedió
■■ DS4 Asegurar el servicio continuo. un Estándar Británico, BS15000, que fue introducido
■■ DS5 Asegurar la seguridad del sistema. originalmente en 2000 y bajo el cual se acreditaron
■■ DS6 Identificar y repercutir costes. algunas organizaciones, aunque fue reemplazado por ISO/
■■ DS7 Educar y formar a los usuarios. ISE 20000 y las acreditaciones fueron transferidas.
■■ DS8 Gestionar el Centro de Servicio al Usuario y las Mientras que ISO/IEC 20000 se correspondía inicialmente
incidencias. con la publicación de ITIL Soporte del Servicio y Entrega
■■ DS9 Gestionar la configuración. del Servicio, el estándar sigue correspondiéndose
■■ DS10 Gestionar problemas. perfectamente con ITIL en la actualidad, y también
■■ DS10 Gestionar datos. cubre Seguridad de ITIL, Gestión de las Relaciones con el
■■ DS12 Gestionar el entorno físico. Negocio y Gestión de Proveedores.
■■ DS13 Gestionar operaciones. En el caso de aquellas organizaciones que buscan
Algunos aspectos de Operación del Servicio también se una acreditación formal de ISO/IEC 20000 para el
tratan ligeramente en algunos de los objetivos de control reconocimiento internacional y exterior del éxito de sus
dentro de otros dominios, pero la gran mayoría de lo que procesos de ITIL, el personal de Operación del Servicio se
COBIT tiene que decir sobre la fase de ‘operación activa’ implicará de forma significativa a la hora de prepararse
de TI se incluye en los objetivos de control anteriormente para la acreditación y recibir la supervisión formal
mencionados. necesaria para lograr el estándar.

COBIT está dirigido principalmente a auditores, por lo que Se puede disponer de más detalles del estándar a través
pone el énfasis en lo que debería auditarse y cómo, en del itSMF en www.itsmf.com o de ISO en www.iso.org
lugar de incluir una guía detallada para aquellos que estén
202 | Apéndice A: Guía complementaria de la industria

A3  CMMI A5  Gestión de la Calidad

La Integración del Modelo de Madurez de la Capacidad Existen notables ventajas a la hora de adherir los procesos
(Capability Maturity Model® Integration -CMMI) es un de ITSM de una organización, y los procesos de Operación
método de mejora de procesos desarrollado por el del Servicio en particular, a su sistema de gestión de la
Software Engineering Institute (SEI) de la Carnegie Mellon calidad. Si una organización tuviera un sistema formal
University. CMMI provee a las organizaciones de los de gestión de la calidad, como por ejemplo ISO9000, Six
elementos esenciales para la eficacia de los procesos. El Sigma, TQM, etc., entonces éste podría servir para evaluar
modelo puede utilizarse como guía para la mejora de el progreso de forma regular e impulsar iniciativas de
procesos a lo largo de un proyecto, una división, o una mejora del servicio acordadas a través de revisiones e
organización completa. CMMI ayuda a integrar funciones informes regulares.
de la organización tradicionalmente separadas, fijar
Muchas organizaciones han usado una evaluación
prioridades y objetivos en la mejora de procesos, hacer
externa o una auditoría anual regular como método
de guía para la calidad de los procesos, y proporcionar un
para determinar las mejoras requeridas e impulsar a
punto de referencia para la evaluación de los procesos en
continuación su sistema de Gestión de la Calidad a través
curso. Vea http://www.sei.cmu.edu/cmmi para disponer de
de programas específicos de trabajo.
más información.
Un gran número de organizaciones de consultoría de TI
A6  ITIL y el Marco de Trabajo OSI
han integrado el modelo de madurez en sus servicios
de evaluación de ITSM como una forma de ayudar a las En el momento en el que ITIL v1 se estaba elaborando,
organizaciones a preparar y a juzgar las mejoras de los la Organización Internacional de Estándares lanzó una
procesos, incluyendo aquellos del área de Operación del iniciativa que dio como resultado el marco de trabajo
Servicio. Las organizaciones podrían decidir usar alguna Interconexión de Sistemas Abiertos (Open System
forma del modelo para ayudar a impulsar su recorrido Interconnection - OSI). Dado que esta iniciativa cubría
hacia la acreditación independiente de ISO/ISE 20000. muchas de las mismas áreas que abarcaba el equipo de
ITIL, no debe sorprender que muchas de ellas tengan los
mismos fundamentos.
A4  Cuadro de Mando Integral
Sin embargo, tampoco debe sorprender que clasificaran
A principios de los años 90 los Doctores Robert Kaplan
sus procesos de forma diferente, con una terminología
(Harvard Business School) y David Norton desarrollaron un
diferente, o que usaran la misma terminología de forma
nuevo método para la gestión estratégica. Denominaron
diferente. Para crear más confusión, es habitual que
a este sistema el ‘Cuadro de Mando Integral’. Detectando
diferentes grupos de una organización usen terminología
algunas de las debilidades y ambigüedades de métodos de
tanto de ITIL como del marco de trabajo OSI.
gestión anteriores, el método del cuadro de mando integral
proporciona un claro consejo de lo que las empresas deberán Aunque explorar el marco de trabajo OSI no se encuentra
medir para ‘equilibrar’ la perspectiva financiera. El Cuadro dentro del ámbito de esta publicación, éste hace
de Mando Integral recomienda que la organización se vea contribuciones significativas a la hora de definir y ejecutar
desde cuatro perspectivas y es útil para desarrollar métricas, programas y proyectos de ITSM en todo el mundo.
recopilar y analizar datos en relación con cada una de estas También ha provocado un gran debate entre equipos que
perspectivas: no son conscientes de los orígenes de la terminología que
están usando.
■■ La Perspectiva de Innovación y Aprendizaje
■■ La Perspectiva del Proceso de Negocio Por ejemplo, algunas organizaciones tienen dos
■■ La Perspectiva del Cliente departamentos de Gestión de Cambios, uno que sigue
el proceso de Gestión de Cambios de ITIL y el otro que
■■ La Perspectiva Financiera.
usa el modelo de Instalación, Movimientos, Añadidos
Algunas organizaciones podrían decidir usar el método del y Cambios (IMAC) de OSI. Cada departamento está
Cuadro de Mando Integral como una forma de evaluar e convencido de que es completamente diferente al otro,
informar del rendimiento de la calidad de TI en general y y que llevan a cabo roles diferentes. Un examen más
del rendimiento de Operación del Servicio en particular. detallado revelará que existen varias áreas comunes.
Tiene a su disposición más detalles a través de la En Operación del Servicio, la gestión de Errores Conocidos
Comunidad de Usuarios del Cuadro de Mando Integral en podría corresponder con Gestión de Fallos. También
www.scorecardsupport.com
 Apéndice A: Guía complementaria de la industria | 203

hay una sección asociada con Gestión de la Capacidad

Operativa que se puede vincular al concepto de Gestión
del Rendimiento de OSI.
 B
Apéndice B:
Comunicación
en Operación
del Servicio
 | 207

Apéndice B: Comunicación en Operación del

Servicio
B1  Comunicación operativa rutinaria Deben tenerse en cuenta consideraciones importantes
durante Diseño del Servicio para definir el contenido, tipo
La mayor parte de la comunicación en Operación del
y formato de la comunicación que se requiere para operar
Servicio debe realizarse de modo que se asegure que
los servicios de TI.
todos los equipos y departamentos sean capaces de
ejecutar las actividades estándar implicadas en la provisión
de servicios de TI y en la gestión de la infraestructura de TI.

Tabla B.1 Requisitos de comunicación en servicios de TI

Propósito ■■ Coordinar las actividades regulares de Operación del Servicio a todos los niveles.
■■ Garantizar que todo el personal sea consciente de la actividad planificada en todo momento y que sean
conscientes de cualquier cambio o iniciativa que pudiera afectar a la operación normal del entorno de TI
Frecuencia Este tipo de comunicación es regular y se comunica en ciclos diarios, semanales y mensuales.
Responsables ■■ Todos los gestores y personal implicados en Operación del Servicio
de los roles ■■ Todos los gestores de procesos para aquellos ejecutados por el personal de Operación del Servicio,
especialmente Gestión de Cambios, Incidencias y Problemas
■■ Clientes y usuarios
■■ Personal de los proveedores implicado en Operación del Servicio
Contenido ■■ Sintetizar eventos posteriores a la comunicación previa hasta asegurar que todos sean conscientes de cualquier
seguimiento que necesite realizarse. Asegurar también que se hayan completado todos los lotes y que los
equipos y departamentos estén preparados para la actividad operativa estándar
■■ Un informe sobre la salud de los sistemas principales
■■ Informar al personal de Gestión de Operaciones de cualquier novedad o evento que pudiera afectar a las
operaciones en ese periodo
■■ Analizar cualquier problema o incidencia pendiente de resolver y asegurar que tenga lugar un plan de acción para
cada uno
■■ Analizar la planificación de los cambios que se espera realizar durante el día, junto con una sesión informativa
de las incidencias potenciales que pudieran producirse como resultado de la acción apropiada a tomar. Esto no
deberá confundirse con la reunión del CAB. Representa una oportunidad para comprobar que los cambios que
se acordaron y planificaron mediante el CAB, o a través de un Modelo de Cambios, todavía se mantienen en la
dirección correcta
■■ Cualquier mantenimiento planificado u otra interrupción que se haya planificado para el siguiente periodo
operativo
■■ Anuncio de los resultados de cualquier reunión Post Mortem o de Crisis que se hubiera mantenido desde la
comunicación previa
■■ Anuncio o recordatorio de la formación que podría estar disponible la siguiente semana o mes para dar tiempo al
personal y a sus supervisores a planificar la formación en la Planificación de Operaciones
Contexto/ ■■ Registros de Operaciones
fuentes ■■ Informes de Incidencias
■■ Informes de Problemas
■■ Calendario de Mantenimiento
■■ Calendario de Cambios
208 | Apéndice B: Comunicación en Operación del Servicio

B2  Comunicación entre turnos

No todas las organizaciones funcionan por turnos, pero
para aquellas que lo hagan, la Tabla B2 sintetizará la
comunicación que es necesario establecer entre los turnos.

Tabla B.2 Requisitos de comunicación entre turnos

Propósito Esta comunicación asegura que el traspaso entre el turno actual y el siguiente sea eficaz y que también el nuevo
turno sea consciente de cualquier dificultad potencial. También se asegurará que el nuevo turno sea consciente de
cualquier tarea que sea necesario completar.
Frecuencia En el traspaso de cada turno
Responsables ■■ Responsables de cada turno
de los roles ■■ El personal de cada turno que realice tareas similares
Contenido ■■ Un informe resumen sobre las operaciones asumidas durante el turno anterior
■■ Un resumen de todas las excepciones y alertas que se resolvieron durante el turno
■■ Detalles de cualquier excepción o alerta pendiente, con información sobre todas las acciones tomadas en el
momento actual y cualquier información sobre acciones futuras anticipadas (p. ej., se espera que un proveedor se
encuentre en el emplazamiento para proporcionar soporte durante las siguientes cuatro horas)
Contexto/ La comunicación entre turnos normalmente se basará en las siguientes fuentes:
fuentes ■■ Registros de turnos
■■ Informes de los Responsables de Turnos
■■ Comunicación mediante ‘chat’ electrónico o verbal impersonal si el personal del turno estuviera en diferentes
instalaciones
 Apéndice B: Comunicación en Operación del Servicio | 209

B3  Informes de Rendimiento Rendimiento de los equipos o departamentos de

Informes de Rendimiento en el contexto de la Operación del Servicio
comunicación hace referencia a tres áreas principales, tal Esto consiste en una comunicación ‘interna’ que tiene
y como se establece más abajo. Adicionalmente, las Tablas lugar entre los miembros de un equipo o departamento y
B.3-B.5 ilustran respectivamente los tres métodos. su gestor, o un gestor de procesos y el equipo que ejecuta
el proceso. Las personas que no pertenecen a estos
Rendimiento del Servicio de TI equipos o departamentos deberán implicarse en este tipo
Esta categoría de Informes de Rendimiento normalmente de comunicación ya que tiene como finalidad gestionar
se realiza como parte de SLM y se incluye en la personas en lugar de medir la calidad del servicio.
publicación Mejora Continua del Servicio. Sin embargo,
Sin embargo, es un error común en los departamentos
existe un aspecto muy importante de Informes del Servicio
de TI comunicar este tipo de información a los clientes
que atañe a Operación del Servicio, particularmente con
como si fuera lo mismo que informar sobre la Calidad del
respecto a los equipos o departamentos de Operación del
Servicio. Por ejemplo, un gestor podría informar que su
Servicio que se requieren para registrar y comunicar la
departamento resuelve el 80% de todos los problemas.
información que se incluye en estos informes.
Sin embargo, en lo que respecta al usuario medio, esta
Sin embargo, el personal de Operación del Servicio no información es irrelevante. Estos usuarios se preocupan
está en la mejor posición para decidir sobre el contenido, más por que el rendimiento de los Servicios de TI sea el
formato y frecuencia de los Informes de Rendimiento del acordado. Además, la divulgación de información interna a
Servicio. Los requisitos para este tipo de comunicación los clientes y usuarios podría ser negativa para los equipos
tienen que definirse claramente durante Diseño del y departamentos de Operación del Servicio y podría
Servicio y afinarse durante Mejora Continua del Servicio. generar altos niveles de interferencia desde el negocio a la
hora de ‘corregir’ problemas percibidos.

Tabla B.3 Requisitos de los Informes de Rendimiento: servicio de TI

Propósito Proporcionar información a los grupos responsables de los informes de Servicios de TI para clientes y usuarios, que
pueda servir para demostrar el logro de los objetivos del servicio y como entrada para las reuniones de Revisión de
los Niveles de Servicio. La información también se puede usar como base para cambiar los servicios de TI.
Frecuencia Según se defina en los SLA y OLA. Esta información normalmente se comunica regularmente de forma diaria,
mensual y trimestral.
Responsables ■■ Equipos y departamentos de Operación del Servicio, normalmente personal de Operaciones de TI
de los roles ■■ Personal de SLM
■■ Equipos de Diseñ~o del Servicio (que ayudarán a definir los estándares de rendimiento y refinar éstos a través de
Mejora Continua del Servicio)
■■ Equipos de Mejora Continua del Servicio, especialmente aquellos a los que se les han asignado tareas con
Informes del Servicio
Contenido A continuación se muestran ejemplos del tipo de información sobre el Rendimiento del Servicio que es necesario
comunicar para permitir la elaboración de informes sobre el Rendimiento del servicio.
■■ Logro de actividades específicas según se define en los OLA
■■ Logro de objetivos para la entrega de salidas especificadas
■■ Logros de disponibilidad del servicio o del sistema
■■ Capacidad para cumplir los Objetivos de Mantenimiento de Servicios dentro de los tiempos objetivo y de los
niveles de impacto
Contexto/ ■■ Herramientas de monitorización y elaboración de informes
fuentes ■■ Registros de Eventos
■■ Registros de Turnos
210 | Apéndice B: Comunicación en Operación del Servicio

Tabla B.4 Requisitos de los Informes de Rendimiento: Equipo o departamento de Operación del Servicio
Propósito Existen tres propósitos principales de la comunicación del Rendimiento del equipo o departamento de Operación del
Servicio:
■■ Proactivamente, para asegurar que el personal de Operación del Servicio esté ejecutando sus actividades
requeridas para entregar servicios de TI y para dar soporte a la Infraestructura de TI
■■ Detectar problemas potenciales con respecto a niveles de recursos, habilidades y elusión de procedimientos
■■ Garantizar que se haya implementado y acatado correctamente la acción correctiva
Frecuencia No hay una frecuencia establecida para este tipo de comunicación. Aunque algunos Informes de Rendimiento podrían
generarse diaria, semanal o mensualmente, la mayoría de los gestores se implican en la comunicación continua con
sus equipos o departamentos según lo requiera la situación.
Bajo situaciones normales de operación, esta comunicación tenderá a ser menos frecuente que en situaciones en las
que exista un alto grado de cambio o si las organizaciones están experimentando un volumen elevado de incidencia
graves.
Responsables ■■ Gestores de Operación del Servicio
de los roles ■■ Personal de Operación del Servicio
■■ Los problemas de rendimiento podrían escalarse al Gestor del Servicio o al CIO
Contenido ■■ Comparación entre rendimiento real y requerido
■■ Tendencias de rendimiento con el tiempo
■■ Informes específicos de mala conducta o fallo a la hora de realizar una acción requerida
Contexto/ ■■ Informes regulares de rendimiento, p. ej., Registros de Incidencias, registros de mantenimiento, métricas de
fuentes proceso
■■ Comunicación interpersonal y verbal durante las situaciones de trabajo
■■ Reuniones de departamento o de equipo
■■ Asesoramiento por parte de un responsable o gestor
■■ La investigación después de un Informe de Servicio deficiente podría iniciar una serie de comunicaciones en
Operación del Servicio
■■ Evaluaciones de Rendimiento Individual, normalmente usando KPIs documentados en la descripción del puesto de
trabajo de los individuos

Rendimiento del proceso o infraestructura

Ya sea sobre el rendimiento de un equipo de trabajo o de
un departamento, esta es una comunicación ‘interna’ que
tiene lugar entre los miembros responsables de la gestión
de un sistema o componente de una infraestructura,
o entre los miembros de un equipo de proceso. Las
personas que no pertenecen a estos equipos deberán
implicarse en este tipo de comunicación ya que tiene
como finalidad gestionar personas en lugar de medir la
calidad del servicio.
 Apéndice B: Comunicación en Operación del Servicio | 211

Tabla B.5 Requisitos de los Informes de Rendimiento: infraestructura o proceso

Propósito Este tipo de comunicación tiene al menos tres propósitos:
■■ Asegurar la operación normal de la infraestructura o de un proceso
■■ Detectar problemas potenciales con la infraestructura o proceso implicado
■■ Garantizar que se haya adoptado una acción correctiva y que ésta sea efectiva
Frecuencia La frecuencia de este tipo de comunicación variará en función de la naturaleza de los sistemas que se están
gestionando o del proceso que se está ejecutando.
Algunos componentes de la infraestructura son más volátiles y requerirán comunicaciones frecuentes, e incluso
reuniones, para garantizar que se comportan de forma predecible. Los componentes más estables simplemente
requerirán una confirmación de que todo sigue funcionando como se espera.
Algunos procesos tienen un requisito de información y comunicación frecuentes. Por ejemplo, Gestión de Incidencias
podría requerir actualizaciones cada cinco minutos para una incidencia de gran impacto. Otros procesos no necesitan
comunicar con esa frecuencia. Por ejemplo, Planificación de la Capacidad necesita comunicar cambios de forma
mensual o incluso trimestral.
Responsables ■■ Personal que gestiona CIs clave
de los roles ■■ Personal que ejecuta procesos
■■ Propietarios del proceso y gestores de la tecnología
■■ Escalado potencial para gestores más senior, el Gestor del Servicio
Contenido ■■ Comparación entre rendimiento real y requerido
■■ Tendencias de rendimiento con el tiempo
■■ Informes específicos de objetivos fallidos o niveles inesperados de rendimiento
Contexto/ ■■ Registros de Eventos
fuentes ■■ Registros de Rendimiento del Sistema
■■ Informes de Rendimiento del Proceso
■■ Registros de Incidencias y Problemas
■■ Informes de Excepciones e Informes de Auditoría
■■ Revisión con el proveedor
■■ Los Informes del servicio podrían indicar un problema con uno o más procesos o áreas tecnológicas
212 | Apéndice B: Comunicación en Operación del Servicio

B4  Comunicación en proyectos ■■ Se informa de las excepciones y las comprobaciones

del resultado del aseguramiento de la calidad dentro
El personal de Operación del Servicio normalmente está
de los equipos de Aseguramiento del Proyecto,
implicado en proyectos. Por ello, pueden proporcionar la
quienes a su vez comunicarán la necesidad de adoptar
entrada de nuevos diseños, o ayudar a verificar los índices
acciones correctivas si fuera necesario.
de utilización o rendimiento, o contribuir en la realización
de pruebas de servicios nuevos o modificados. En otros Dentro de cada equipo, la comunicación estará más
casos, los proyectos podrían afectar a los OLA existentes centrada en la finalización de sus tareas y, generalmente,
y se requerirá su retroalimentación. Hay que señalar será más frecuente que la comunicación de todo el
que esta implicación supondrá un añadido al nivel de proyecto.
comunicación que estos individuos estarán recibiendo o Es probable que haya un alto nivel de comunicación
transmitiendo, lo cual requerirá una dedicación y tiempo menos formal dentro de cada equipo y también entre
adicionales, con lo que se debería permitir que los equipos para asegurar que se completen las tareas a
gestores asignen recursos a proyectos a tiempo parcial. tiempo y que los recursos prometidos estén disponibles
La comunicación formal del proyecto tiende a seguir el en el momento y lugar en el que se supone que tienen
ciclo de las reuniones del proyecto. Por ejemplo: que estar. También será necesaria una comunicación
extensa, como parte del traspaso de un equipo a otro
■■ Se celebrarán reuniones del proyecto semanales
cuando el proyecto pase de una etapa o fase a otra.
o mensuales con el Gestor de Proyecto y con los
Una regla general importante es documentar cualquier
responsables de los equipos individuales
comunicación que pudiera afectar potencialmente al
■■ Se enviará una actualización del estado mensual al
resultado o al coste del proyecto.
Patrocinador Ejecutivo del proyecto y, posiblemente, a
otros interesados clave

Tabla B.6 Comunicación dentro de proyectos

Propósito Comunicación del proyecto para múltiples propósitos, que incluyen:
■■ Obtener soporte de los interesados del proyecto – esta comunicación se centrará en el alcance, coste y
beneficios del proyecto, y buscará demostrar un retorno general de la inversión del proyecto
■■ Garantizar que todos los miembros del equipo de proyecto entiendan y estén alineados con los objetivos del
proyecto
■■ Asignar trabajo a individuos o equipos
■■ Planificar actividades y garantizar que los recursos estén preparados para iniciar su etapa del proyecto
■■ Comprobar e informar del progreso del proyecto
■■ Detectar y escalar excepciones o retrasos potenciales en el proyecto
■■ Preparar a los clientes y destinatarios del proyecto para el despliegue de la solución que se está creando
Frecuencia La frecuencia, responsables de los roles y el contenido de la comunicación, dependerán de la naturaleza del
proyecto y del tipo de metodología de Gestión de Proyectos que se esté utilizando
 Apéndice B: Comunicación en Operación del Servicio | 213

Tabla B.7 Comunicación en el traspaso de proyectos

Responsables ■■ Gestor de Proyecto y personal de coordinación y administrativo del proyecto
de los roles ■■ Patrocinador del Proyecto
■■ Interesados Clave del Proyecto (p. ej., clientes, Directores de TI, miembros de la Dirección, usuarios, etc.)
■■ Equipos de proyecto y contribuidores individuales
■■ Personal técnico y de ventas del proveedor donde la compra de servicios o soluciones forma parte del proyecto
Contenido ■■ Recopilación de requisitos para la solución que se está creando mediante el proyecto
■■ Planificación del proyecto
■■ Información de ‘Marketing’ del proyecto incluyendo Retorno de la Inversión o información del Caso de Negocio
■■ Actualizaciones del estado
■■ Recopilación de información para completar una tarea
■■ Eventos que podrían afectar al alcance, coste o finalización a tiempo del proyecto
■■ Informe del progreso dentro de los equipos o entre equipos
■■ Información sobre los resultados de la prueba
■■ Notificaciones a los equipos o individuos de que el proyecto se está aproximando a ‘su’ etapa o actividad y que
deberán hacer todos los preparativos apropiados
■■ Información sobre la finalización con éxito de actividades
■■ Revisión del éxito general del proyecto
Contexto/ ■■ Presentación del Proyecto
fuentes ■■ Presupuesto del Proyecto
■■ Declaración de Requisitos
■■ Planificación del Proyecto
■■ Reuniones del proyecto
■■ Reuniones de equipo
■■ Informes del estado y del progreso
■■ Informes de pruebas
■■ Documentación de aprobación del cliente
■■ Revisión de la Post Implementación
214 | Apéndice B: Comunicación en Operación del Servicio

B5  Comunicación asociada con los

cambios
Gestión de Cambios se aborda con detalle en la
publicación Transición del Servicio de ITIL e incluye
información sobre la comunicación de los cambios.
Sin embargo, es necesario acentuar la naturaleza de la
comunicación operativa acerca de los cambios.

Tabla B.8 Comunicación sobre los cambios

Propósito Dar soporte al proceso de Gestión de Cambios a través de :
■■ Evaluar el impacto potencial y los recursos requeridos para el cambio
■■ Garantizar que cada equipo sea consciente de la naturaleza y planificación de los cambios que se les ha asignado
■■ Construir, probar y desplegar cambios en su entorno
■■ Asegurar que cada equipo informe del progreso en cada cambio
■■ Notificar a Gestión de Cambios que un cambio ya está preparado para su despliegue
■■ Retornar los cambios que fueron insatisfactorios y comunicar los resultados a Gestión de Cambios
■■ Colaborar en la evaluación de los cambios para asegurar que se hayan implementado correctamente
Frecuencia La frecuencia de la comunicación asociada a los cambios está determinada por la naturaleza del cambio y por los
tiempos establecidos en la Planificación de Cambios.
La mayoría de los equipos o departamentos revisarán los cambios de forma diaria o semanal. Cada día analizarán y
priorizarán todos los nuevos cambios que se les asignen e informarán del progreso de los cambios en los que estén
trabajando. Después de cada cambio, informarán sobre el éxito de los mismos y se asegurarán de que se inicie
cualquier acción de resolución requerida.
Responsables ■■ Gestor de Cambios, administradores y coordinadores
de los roles ■■ Jefes de Equipo, Directores de Departamento, Gestores de Turnos o Gestores de Proyecto
■■ El personal de Operación del Servicio implicado en construir, probar y desplegar cambios (normalmente equipos
o departamento de Gestión Técnica, de Aplicaciones y de Operaciones de TI)
■■ Gestores de Entornos de Pruebas y equipos
■■ Equipos de Cambios o Despliegue de Versiones
Contenido ■■ Peticiones y autorización de cambios
■■ Informes sobre la viabilidad de un cambio
■■ Informes sobre los recursos requeridos para construir, probar o desplegar un cambio
■■ Calendario de la Actividad de los Cambios
■■ Descripciones detalladas del cambio y de las actividades requeridas de cada equipo o departamento
■■ Informe del progreso y estado de la actividad del cambio
■■ Resultados de las pruebas
■■ Informes de Excepciones, incluyendo detalles de la ejecución de Planes de Marcha Atrás
Contexto/ ■■ RFCs
fuentes ■■ Comunicación de Control del Cambio (durante reuniones operativas diarias o semanales, o a través de correo
electrónico, llamadas de conferencia o usando las herramientas de Gestión de Cambios)
■■ Reuniones del Comité de Cambios
■■ Planes de Entrega
■■ Informes de Disponibilidad de Servicio Propuesta
■■ Revisiones del Cambio
 Apéndice B: Comunicación en Operación del Servicio | 215

B6  Comunicación asociada con las tratará en el contexto de ese proceso o a través de un
excepciones proceso de Aseguramiento de la Calidad); un equipo,
departamento o individuo cuyo rendimiento no alcanza
En este contexto, una excepción hace referencia a el estándar (lo que se tratará a través de procedimientos
cualquier suceso, actividad o rendimiento que se salga disciplinarios de RR.HH.); o una excepción con respecto
fuera de lo normal o esperado. La forma más habitual de al rendimiento contractual de un proveedor. Aunque no
excepción es una Incidencia (que se trata con detalle en la todas se asocian directamente con Gestión del Servicio,
sección 4.2 de esta publicación). Existen otras excepciones añadirán gastos generales al nivel de comunicación
que no pasan necesariamente por Gestión de Incidencias, requerido del personal durante la fase de Operación del
como por ejemplo una excepción del proceso (que se Servicio.
Tabla B.9 Comunicación durante las excepciones
Propósito La comunicación durante o después de las excepciones tiene por objetivo:
■■ Informar de la excepción a las personas adecuadas
■■ Evaluar la relevancia, gravedad e impacto de la excepción
■■ Asegurar que se impliquen recursos con las habilidades y jerarquía apropiadas a la hora de resolver la excepción y
adoptar la acciones pertinentes para evitar una futura recurrencia
■■ Proveer actualizaciones a los interesados que se vean afectados por la excepción
Frecuencia Este tipo de comunicación es reactiva y ad hoc, y no se produce a menos que se haya identificado una excepción o el
riesgo de una excepción. Por lo tanto, la frecuencia es directamente proporcional a la frecuencia de las excepciones.
Una vez se haya detectado una excepción, la frecuencia y contenido de la comunicación estarán determinados por
el impacto, urgencia y gravedad de la excepción.
Responsables Los responsables reales de los roles dependerán del tipo y amplitud de la excepción, aunque podrían incluir:
de los roles ■■ Gestión de Incidencias
■■ El Centro de Servicio al Usuario
■■ Gestión de Problemas
■■ Propietarios del proceso (si la excepción se asociara con el rendimiento del proceso)
■■ Gestores departamentales o jefes de equipo
■■ SLM
■■ Gestión de Recursos Humanos
■■ Expertos y Gestores de Tecnología
■■ Personal de gestión de cuentas de proveedores
■■ Expertos técnicos de proveedores
Contenido ■■ Descripción y evaluación de la excepción
■■ Evaluación del impacto. Esto implicará típicamente la comunicación con los interesados que se vean afectados
por la excepción
■■ Estimación y confirmación del coste de la resolución
■■ Una decisión sobre la acción que se tomará
■■ Comunicación de la decisión tomada. Es probable que esté en varios formatos. Por ejemplo, es probable que
la comunicación con los clientes contenga una disculpa y una descripción general de alto nivel de lo que se
está haciendo para resolver la excepción. Una comunicación con las personas que se espera que resuelvan la
excepción estará más detallada y contendrá acciones y secuencias claras
■■ Confirmación de que la excepción se ha resuelto
Contexto/ ■■ Revisiones del proceso
fuentes ■■ Revisiones del cambio
■■ Revisiones del Nivel de Servicio
■■ Eventos
■■ Análisis de Tendencias de los procesos, dispositivos, rendimiento del equipo, etc.
■■ Incidencia, Problema y Registros de Cambios
■■ Encuestas de satisfacción del cliente
216 | Apéndice B: Comunicación en Operación del Servicio

B7  Comunicación asociada con las excepciones. Las diferencias principales estriban en el nivel
emergencias de urgencia e impacto de la excepción.

Aunque ITIL especifica cómo abordar situaciones Las comunicaciones de emergencias normalmente se
urgentes de gran impacto como desastres (Gestión de inician mediante el Gestor de Incidencias (vea el párrafo
la Continuidad del Servicio de TI) y como Incidencias 4.2.5 para disponer de un análisis sobre Incidencias
Graves (Gestión de Incidencias), los gestores en la fase Graves) o mediante un Director de TI que se haya
de Operación del Servicio se encontrarán tratando varios designado como punto de escalado para todas esas
tipos y escalas de emergencias que no se cubren en estos emergencias.
procesos. Es importante tener en cuenta que este no es En el caso de que se invoque un Plan de Continuidad de
un proceso independiente, sino que es una visión de los Servicios de TI, éste incluirá un Plan de Comunicación
múltiples procesos y situaciones desde la perspectiva de que tendrá que ejecutar la autoridad apropiada.
una comunicación.
El Gestor de Incidencias o el gestor designado
La comunicación durante las emergencias es similar normalmente formará un equipo responsable que iniciará
en propósito y contenido a la comunicación durante y coordinará la comunicación.

Tabla B.10 Comunicación durante emergencias

Propósito El propósito de la comunicación en una emergencia es investigar y confirmar inmediatamente el impacto y gravedad
de la Incidencia para confirmar que verdaderamente sea una situación de emergencia. También deberá confirmar
que esta Incidencia no represente un desastre o cualquier contingencia recogida en los Planes de Continuidad de los
Servicios de TI.
En cuanto se haya identificado el ámbito de la emergencia, el equipo responsable de gestionar la situación asignará
recursos para crear un plan de acción y empezar a resolver la emergencia y restaurar el servicio.
Frecuencia Este tipo de comunicación no se produce a menos que haya una Incidencia Grave o una situación de emergencia.
Una vez se haya detectado una excepción, la frecuencia y contenido de la comunicación estarán determinados por
el impacto, urgencia y gravedad de la excepción, y potencialmente mediante un Plan de Recuperación del Servicio.
Responsables ■■ Gestor de Incidencias
de los roles ■■ Gestores Senior de grupos responsables del personal de TI al que se requerirá resolver la situación
■■ Gestores del negocio y Ejecutivos (incluyendo posiblemente al personal jurídico si la organización estuviera
expuesta a una posible acción legal como resultado de la incidencia)
■■ Clientes y usuarios
■■ Gestor de la Continuidad de los Servicios de TI y equipo de Coordinación Central
■■ Responsables y personal senior de los proveedores (dependiendo de la amplitud y naturaleza de la situación)
■■ Gestores y personal de Gestión Técnica
■■ Gestores y personal de Gestión de Aplicaciones
■■ Gestores y personal de Gestión de Operaciones de TI
Contenido ■■ La naturaleza y amplitud de la emergencia
■■ Evaluación del impacto. Esto implicará típicamente la comunicación con los interesados que se vean afectados
por la excepción
■■ Estimación y confirmación del coste de la resolución
■■ Una decisión sobre la acción que se tomará
■■ Comunicación de la decisión tomada. Es probable que esté en varios formatos. Por ejemplo, es probable que
la comunicación con los clientes contenga una disculpa y una descripción general de alto nivel de lo que se
está haciendo para resolver la excepción. Una comunicación con las personas que se espera que resuelvan la
excepción estará más detallada y contendrá acciones y secuencias claras
■■ Confirmación de que la excepción se ha resuelto
Contexto/ ■■ Registro de Incidencias para Incidencias Graves
fuentes ■■ Eventos
■■ Reuniones de crisis o de emergencia convocadas por el Gestor de Incidencias, por el gestor designado, o por el
Gestor de la Continuidad de los Servicios de TI
 Apéndice B: Comunicación en Operación del Servicio | 217

B8  Comunicación con usuarios y del Servicio. El enfoque se encuentra en los requisitos
clientes del cliente y usuarios y en lo que TI está haciendo para
satisfacerlos. No se debería incluir descripciones técnicas e
Esta sección aparece la última no porque sea la menos información detallada sobre los procesos internos.
importante, sino porque incorpora varias de las áreas
analizadas anteriormente. Un principio importante en la
comunicación con los clientes es que la comunicación
no deberá centrarse en aspectos internos de Operación

Tabla B.11 Comunicación con usuarios y clientes

Propósito Existe un gran número de razones para la comunicación con usuarios y clientes en Operación del Servicio. Éstas
incluyen:
■■ Garantizar que los servicios se hayan entregado como se acordó
■■ Comunicación con respecto al cumplimiento de las Peticiones de Servicio
■■ Informar de Incidencias y mantener a clientes y usuarios actualizados sobre su estado hasta que se resuelvan
■■ Notificar a usuarios y clientes los cambios que podrían afectarles
■■ Proporcionar acceso a los servicios
■■ Tratar los problemas potenciales de seguridad
■■ Planificar actividades que impliquen a usuarios o clientes, p. ej., mantenimiento
■■ Notificación de eventos de negocio especiales que requieran soporte adicional o cambio de las prioridades
■■ Revisión de la satisfacción de clientes y usuarios
■■ Coordinación durante situaciones de contingencia
Frecuencia La comunicación con usuarios y clientes es continua. El formato y contenido de la comunicación se definirá
mediante los procesos que se están ejecutando. Por ejemplo, la comunicación sobre una Incidencia estará
determinada mediante el proceso de Gestión de Incidencias.
Algunas comunicaciones serán formales y se planificarán, p. ej., proporcionando informes sobre el rendimiento de
un servicio durante una reunión de revisión. Otras comunicaciones serán formales pero ad hoc, p. ej., comunicación
sobre el estado de una Incidencia
Responsables La identidad de los responsables de los roles y su número dependerá del proceso que se esté ejecutando, del
de los roles tipo de situación que se haya producido y del ámbito en el que se esté comunicando, p. ej., proporcionar una
actualización sobre el estado de una Petición de Servicio tendrá una audiencia muy diferente que participar en una
reunión de Revisión del Nivel de Servicio
Contenido El contenido de esta comunicación variará dependiendo del contexto. Sin embargo, es importante centrar la
comunicación en los destinatarios. Esto significa usar nombres de servicios en lugar de nombres de servidores o de
aplicaciones, ser profesional, evitar la jerga técnica, no ser condescendientes y tratar a los clientes y usuarios con
respeto
Contexto/ El contexto de esta comunicación es la ejecución diaria de actividades operativas y la entrega y soporte de servicios.
fuentes Los equipos de Operación del Servicio no deberán comunicarse con clientes y usuarios con respecto a aspectos
de planificación, estrategia, diseñ~o o prueba, a menos que se les hayan asignado a un equipo de proyecto que esté
tratando con una de estas áreas
 Apéndice C:
Kepner y Tregoe C
 | 221

Apéndice C: Kepner y Tregoe

Charles Kepner y Benjamin Tregoe desarrollaron un ■■ Identidad. ¿Qué parte no funciona bien? ¿Cuál es el
método útil para analizar problemas. En este apéndice, su problema?
método está presente como un ejemplo de método de ■■ Ubicación. ¿Dónde se produce el problema?
Análisis de Problemas. ■■ Tiempo. ¿Cuándo empezó a producirse el problema?
Kepner y Tregoe establecen que el Análisis de Problemas ¿Con qué frecuencia se ha producido el problema?
deberá ser un proceso sistemático de resolución ■■ Envergadura. ¿Cuál es la envergadura del problema?
de problemas y deberá aprovechar al máximo el ¿Cuántas partes se ven afectadas?
conocimiento y la experiencia. Distinguen las siguientes La situación del problema estará determinada por las
cinco fases para el Análisis de Problemas (descritas con respuestas a estas preguntas. El siguiente paso será
más detalle a continuación): investigar las partes similares que están funcionando
■■ Definición del problema adecuadamente en un entorno similar. Con esto, se
■■ Descripción del problema con respecto a la identidad, formula una respuesta a la pregunta ‘Cuál PODRÍA SER
ubicación, tiempo y tamaño pero que NO ES?’ (¿Qué partes podrían mostrar el mismo
■■ Establecimiento de las causas posibles problema pero no lo hacen?)
■■ Prueba de la causa más probable Entonces es posible buscar eficientemente las diferencias
■■ Verificación de la causa real. relevantes en ambas situaciones. Además, pueden
identificarse los últimos cambios que podrían ser la causa
En función del tiempo y de la información disponible,
de estas diferencias.
estas fases se pueden aplicar con mayor o menor
extensión. Incluso en situaciones en las que sólo se
disponga de una cantidad muy limitada de información, C3  Establecimiento de las causas
o en las que haya una gran presión de tiempo, sería posibles
conveniente adoptar un método estructurado para el
El muy probable que la lista de diferencias y cambios
Análisis de Problemas con el objetivo de incrementar las
mencionada anteriormente incluya la causa del problema.
oportunidades de éxito.

C4  Prueba de la causa más probable

C1  Definición del problema
Es necesario evaluar cada causa posible para determinar si
Debido a que la investigación se basa en la definición
pudiera ser la causa de todos los síntomas del problema.
del problema, esta definición tiene que establecer con
precisión las desviaciones que se han producido con
respecto a los niveles de servicio acordados. C5  Verificación de la causa real
Normalmente, ya se indica la causa más probable Tendrán que verificarse las causas posibles restantes por si
del problema durante la definición de mismo. Evite fueran la fuente del problema. Esto sólo se puede hacer
sacar conclusiones precipitadas que puedan guiar la proporcionándolo de una forma u otra, por ejemplo,
investigación en la dirección errónea desde el comienzo. implementando un cambio o sustituyendo una parte.
Aborde primero las causas posibles que se puedan verificar
En la práctica, la definición del problema es normalmente
de forma rápida y simple.
una tarea difícil debido a una Infraestructura de TI
complicada y a la falta de transparencia en los acuerdos
con respecto a los niveles de servicio.

C2  Descripción del problema

Los siguientes aspectos se utilizan para describir el
problema, es decir, en qué consiste el problema:
 Apéndice D:
Diagramas de Ishikawa D
 | 225

Apéndice D: Diagramas de Ishikawa

El Diagrama de Ishikawa, también conocido como el A continuación se mostrará la técnica básica de desarrollo
Diagrama de Pescado, Causa y Efecto o de Árbol, es de estos diagramas, junto con un ejemplo muy simple. Un
una herramienta que sirve para identificar y presentar equipo de resolución de problemas usará el Diagrama de
sistemáticamente todas las causas posibles de un Ishikawa de la forma siguiente:
problema, particularmente en un gráfico. La técnica
1 Prepare un diagrama en blanco en un formato que
adoptó este nombre por su desarrollador, Kaoru Ishikawa
pueda ver todo el grupo. Esté podría estar en una
(1915-89), un líder en el control de calidad japonés. A
pizarra, tablero, proyectarse a través de un proyector
continuación se muestra un ejemplo.
de datos desde un PC, etc.
El objetivo principal se representa mediante la espina
2 Defina el problema que el grupo está intentando
o tronco del diagrama, y los factores principales se
resolver en términos claros y específicos y escríbalo en
representan como ramas. Los factores secundarios se
el cuadro de la ‘cabeza de pez’ del diagrama.
añaden como tallos, y así sucesivamente. La creación del
diagrama estimula la discusión y en muchas ocasiones 3 Escriba la categorías de causas en las puntas de las
mejora el entendimiento de un problema complejo. Estos ‘espinas de pescado’. Éstas deberán ser categorías
diagramas se usan ampliamente para identificar soluciones bastante amplias, debido a que aún no se conocen las
para problemas sistemáticos, como por ejemplo identificar causas exactas. En la Figura D1 se muestra un ejemplo
la causa de pérdida de productividad en líneas de en el que el grupo está intentando encontrar la causa
montaje, o disminución de los niveles de satisfacción del de unos niveles inaceptables de caídas de la red.
cliente en una organización de servicios.

Diagrama de Ishikawa que muestra Categorías de Problema y Causa

Tecnología Personas

Niveles Inaceptables
de Caídas en la Red

Procesos Entorno

Figura D.1 Ejemplo de inicio de un Diagrama de Ishikawa

226 | Apéndice D: Diagramas de Ishikawa

Diagrama de Ishikawa que muestra posibles causas

Tecnología Personas
Soporte deficiente del proveedor Fin formación Sin notificación de
Falta de habilidades eventos de marketing
Fallo del hardware
Retención deficiente Tasas de utilización anormales
Mala compra del personal
Roles no definidos Procesamiento durante
El negocio no permitirá una caída
periodos picos
Mantenimiento deficiente Confusión de roles

Actividades no especificadas en el Diseño Duplicación de esfuerzo Niveles Inaceptables

de Caídas en la Red
El equipo no se encuentra
en el centro de datos
Sin comunicación con los desarrolladores Los Cls clave no están en una
Seguridad deficiente fuente de alimentación limpia
Interrupciones en
Cambios no No existe software de la alimentación
controlados detección de intrusiones
Sin alimentación de backup
Sin gestión de entregas
para equipos remotos
Procesos Entorno

Figura D.2 Ejemplo de un Diagrama de Ishikawa completado

4 Use técnicas de tormentas de ideas para permitir que

los participantes sugieran causas posibles y téngalas
en cuenta en la rama pertinente del diagrama. En la
Figura D.2 se ha completado un diagrama simple.
5 Interprete el diagrama. Esto se podrá hacer
clasificando las causas superiores basándose en la
experiencia y en los datos disponibles. Una vez se
hayan detectado las causas, se investigará cada una de
ellas con más detalle de acuerdo con su clasificación y
prioridad.
 E
Apéndice E :
Descripción detallada
de Gestión de las
Instalaciones
 | 229

Apéndice E : Descripcíon detallada de Gestíon

de las Instalaciones
El propósito de este apéndice no es proporcionar una sección E6 que se incluye más adelante y en el
explicación detallada de todos los aspectos de Gestión de Apéndice F.
las Instalaciones. Más bien destacará las actividades más ■■ Señalización, es, por ejemplo, garantizar que se
importantes para ayudar al posicionamiento de algunas pueda encontrar un edificio, pero no tan obviamente
de las otras funciones e identificar dónde impactarán como para exponer una ubicación clave a un ataque.
los procesos específicos en una buena Gestión de las
Instalaciones y viceversa. E2  Alojamiento de Equipos
Gestión de las Instalaciones proporcionará información a Las instalaciones no se gestionan simplemente porque
Gestión de la Configuración en relación con la ubicación existan y sean de propiedad de una organización. Se
y estado de los CIs, y también será una parte integral gestionan para que las personas y equipos que contienen
de Gestión de Cambios, Gestión de la Capacidad, puedan desempeñar sus propósitos específicos. En el caso
Planificación de la Disponibilidad y Gestión Continua del de las Instalaciones de TI, como por ejemplo el Centro
Servicio. de Proceso de Datos, esto añade algunas exigencias muy
Los componentes principales de Gestión de las específicas al gestor de esa instalación.
Instalaciones son los siguientes. Una de éstas es el alojamiento de los equipos de TI. No
se trata de la simple asignación de una sala y permitir
E1  Gestión de Edificios que el personal de Gestión Técnica instale y gestione
equipos. Los diferentes tipos de equipos tienen requisitos
Aunque muchas actividades de Gestión de Edificios muy específicos con respecto a la instalación en la que se
se externalizan y se contratan a otros suministradores, alojan, por ejemplo:
todavía son de responsabilidad de Gestión de las
Instalaciones. Las actividades típicas incluyen: ■■ Los equipos de agua refrigerada necesitan acceso a
agua de refrigeración que la instalación tendrá que
■■ Limpieza. Esto podría hacerse a través de empleados
suministrar
o de terceros. Es muy importante asegurar aquí que
■■ El peso de los equipos varía y tiene que distribuirse
el personal de limpieza cumpla todas las políticas de
para no aplicar demasiada presión en el piso
confidencialidad y de control de accesos.
■■ La fuente de alimentación podría variar para diferentes
■■ Eliminación de residuos, incluyendo la separación
tipos de equipos.
de elementos para el reciclaje, elementos peligrosos
(p. ej., baterías, líquidos y gases como por ejemplo Si los equipos se situaran simplemente en el Centro
unidades de aire acondicionado), documentación de Proceso de Datos en el orden en el que se reciben,
confidencial. será muy difícil encontrarlos y el personal podría tener
■■ Instalación de componentes físicos, como por que recorrer la instalación varias veces para dar servicio
ejemplo el cableado, alimentación, suelos elevados, a equipos similares. Este tráfico pone en peligro la
sistemas de entrada y salida de seguridad, oficinas, integridad y seguridad de otros equipos en la planta.
armarios, etc. Esto implica que Gestión de las Instalaciones tendrá la
■■ Aparcamiento. Esto incluiría la distribución responsabilidad de planificar y diseñar la distribución
del aparcamiento para el personal y contratas, del Centro de Proceso de Datos para que se disponga
aparcamiento de los visitantes y aparcamiento para de un acceso y seguridad óptimos para los equipos que
visitantes y personal minusválido. Gestión de las se alojarán allí. Al mismo tiempo, se deberá recordar
instalaciones también incluirá la documentación e que estos equipos sirven para entregar servicios de TI, y
implementación de cualquier política en relación con se deberá tener en cuenta cualquier requisito para ese
el lugar de aparcamiento de las personas. servicio a la hora de alojar los equipos. Por ejemplo, el
■■ Control de Accesos y Monitorización de la Centro de Proceso de Datos podría tener que modificarse
Seguridad. Esto se analiza con más detalle en la parea acomodar un servidor que no es estándar.
230 | Apéndice E: Descripción detallada de Gestión de las Instalaciones

Además, la mayoría de los Centros de Proceso de Datos Gestión de las Instalaciones será responsable de establecer
también ofrecen las siguientes actividades de alojamiento: fuentes de alimentación auxiliares por si se produjeran
fallos de alimentación, desastres y otras contingencias.
■■ Recepción de nuevos equipos
Esto se hará generalmente en forma de Fuentes de
■■ Desembalaje, configuración e instalación de equipos
Alimentación Ininterrumpida (UPS) para los equipos clave,
estándar
y también en forma de generadores alimentados mediante
■■ Generación y mantenimiento de diagramas de
una fuente de energía alternativa (normalmente diesel).
distribución del Centro de Proceso de Datos Gestión de las Instalaciones no sólo es responsable de
■■ Gestión de la planificación de cualquier actividad de suministrar estas alternativas, sino también de probarlas,
mantenimiento con respecto a los equipos alojados en mantener los suministros de combustible, y mantenerlas.
el Centro de Proceso de Datos
Es necesario indicar que será necesario modelar y probar
■■ Eliminación de equipos retirados.
cualquier fuente de alimentación alternativa para asegurar
A partir de esta lista de actividades, está claro que Gestión que sea capaz de responder a la demanda requerida y
de las Instalaciones no debería verse como una función que se active automáticamente después de un fallo de
independiente, sino como una parte muy importante de la alimentación.
operación global de TI en la organización.
Otra actividad clave de Gestión de las Instalaciones es
gestionar el uso de la energía. Tradicionalmente, el rol de
E3  Gestión de la Energía Gestión de las Instalaciones se limitaba a asegurar que la
Gestión de la Energía hace referencia a la gestión del energía estuviera disponible. Sin embargo, debido a que
suministro y uso de fuentes de alimentación que se los recursos naturales son cada vez más escasos y caros,
utilizan para mantener la instalación en funcionamiento. se debe prestar más atención a las técnicas que permiten
Esta definición de Gestión de la Energía tiene varias gestionar un uso más responsable.
implicaciones que se analizarán más adelante. Uno de estos métodos es la gestión dinámica de la
La primera tarea de Gestión de las Instalaciones a la hora energía en Centros de Proceso de Datos. El principio se
de gestionar la energía, es determinar los requisitos de basa en que, durante los periodos pico de procesamiento,
energía para la instalación. Esto incluye definir: se usarán más ordenadores para hacer el trabajo. Cuando
se reduce la carga de trabajo, el trabajo se centraliza en
■■ La energía que será necesaria para, p. ej., la zona de menos ordenadores, mientras que aquellos que no están
oficinas, los equipos en el Centro de Proceso de Datos, en uso se desconectan o sitúan en modo en espera. Esto
la cafetería, etc. requiere una interacción significativa entre las actividades
■■ Cuándo se necesitará esa energía. Algunas operaciones de Gestión de Operaciones de TI, Gestión Técnica y todos
requieren una fuente continua de electricidad durante los procesos de Diseño del Servicio. Tal interacción se
las 24 horas al día. Otras, como por ejemplo el analiza con más detalle en la sección sobre estrategias del
espacio de oficinas, usarán más electricidad durante el Centro de Proceso de Datos.
día y muy poca por la noche. Otras sólo necesitarán
electricidad en un momento específico
■■ Cuánta energía se necesitará
■■ Qué tipo de energía se utilizará. Aunque la mayoría
de las organizaciones usan electricidad, en muchas
ubicaciones los sistemas de calefacción dependen del
gas natural.
Gestión de las Instalaciones también será responsable de
establecer un contrato con empresas de suministro o, en
muchos casos, con la autoridad local o municipal que
proporciona ese servicio. Esto incluirá una tarifa acordada
y un nivel de disponibilidad. Este aspecto ha pasado a ser
muy importante en ubicaciones en las que el suministro
de electricidad varía debido a la falta de infraestructuras o
debido al exceso de uso de los consumidores en general.
 Apéndice E: Descripción detallada de Gestión de las Instalaciones | 231

E4  Acondicionamiento del Entorno y de backup con demasiada frecuencia entonces la

Sistemas de Alerta planificación inicial fue inadecuada).
■■ La monitorización continua de la temperatura y ajuste
Gestión de las Instalaciones garantiza que las condiciones
de los parámetros de refrigeración de acuerdo con
físicas dentro de los Centros de Proceso de Datos o salas
los cambios estacionales y con la distribución de
de ordenadores se mantengan en los niveles correctos
los equipos. Estos monitores podrían vincularse con
para conseguir unas Operaciones de TI óptimas. Estas
el Puente de Operaciones, que podría responder a
condiciones incluyen:
cualquier desviación significativa con respecto a las
■■ Temperatura temperaturas normales.
■■ Humedad ■■ Identificar y evitar errores ‘obvios’, como por ejemplo
■■ Calidad del aire situar la salida de calor de un servidor importante
■■ Capacidad para evitar riesgos del entorno, como por cerca de la toma de entrada de una unidad de aire
ejemplo incendio, inundación, etc. acondicionado; o evitar el flujo de aire apilando
manuales en espacio ‘libre’.
La temperatura se mantiene a través de los sistemas de
calefacción y refrigeración, además de la distribución de Se deberán realizar pasos similares para identificar niveles
los equipos en la instalación. Esto requerirá las siguientes ideales de humedad y para especificar si se requieren
actividades: equipos deshumidificadores.

■■ Averiguar la salida de calor para CIs y su temperatura Los equipos de detección de humos se instalan
de operación óptima. normalmente como parte de la estrategia general de
control de incendios de la instalación y se vinculan con
■■ Identificar el requisito de refrigeración total para todos sistemas automatizados de extinción de incendios. Sin
los equipos en la instalación además de la de los embargo, Gestión de las Instalaciones no debería asumir
elementos específicos. Por ejemplo, un climatizador que una respuesta automatizada contra incendios es
podría mantener un Centro de Proceso de Datos a una adecuada. Las unidades de detección de humos deberán
temperatura constante, pero podría haber equipos que vincularse con el Puente de Operaciones y deberá
deban mantenerse a una temperatura inferior. investigarse cualquier excepción.
■■ Modelar los requisitos generales de calefacción y Deberán instalarse unidades de detección de movimiento
refrigeración, además de asignar áreas específicas en en todas las áreas de operación que no estén
la instalación que pudieran estar más cálidas o frías de vigiladas. Éstas garantizarán que se detecte el acceso
forma natural. Esta información se usa para identificar sin autorización y que se informe a Seguridad de las
dónde se encuentra la mejor ubicación para equipos Instalaciones, y posiblemente al Puente de Operaciones.
específicos. Es importante tener en cuenta que, Esto ayudará a implementar una planificación apropiada
cuando se instalan nuevos equipos en una instalación, de actividades de mantenimiento o instalación.
se cambiará la distribución de las áreas más cálidas
y más refrigeradas, de ahí la necesidad de aplicar La detección de polvo y partículas puede ayudar a
técnicas de modelado y distribución más sofisticadas. mantener la calidad del aire alrededor de sistemas que
También será necesario que estos modelos tengan sean particularmente sensibles. Nuevamente, los monitores
en cuenta variaciones estacionales en la temperatura. deberán encaminarse hasta el Puente de Operaciones para
Por ejemplo, algunas instalaciones podrían necesitar que se puedan investigar y corregir las desviaciones antes
calentarse en invierno y refrigerarse en verano. que se produzcan daños significativos.

■■ La adquisición y mantenimiento de unidades de Existe también un gran número de tipos de

aire acondicionado con suficiente capacidad, y el monitorización de instalaciones, que se basan en la
mantenimiento regular de estas unidades. ubicación de las mismas. Por ejemplo, monitores de
■■ Invertir en unidades de aire acondicionado de backup movimiento en edificios instalados en ubicaciones con
que se puedan usar en caso de fallo de una unidad altos niveles de actividad sísmica. Éstos actúan como
principal, o para proporcionar una capacidad de sistemas de advertencia anticipada para indicar que es
refrigeración adicional en días excepcionalmente necesario cerrar o recuperar de un fallo a un sistema en
calurosos (aunque esto sería una excepción un emplazamiento alternativo antes de que un seísmo
infrecuente ya que, si es necesario utilizar la unidad o terremoto importante afecte a los equipos sensibles.
También se están instalando monitores y protecciones
232 | Apéndice E: Descripción detallada de Gestión de las Instalaciones

similares en instalaciones en las que existe una actividad ■■ Dotación de vigilantes de seguridad
tormentosa con alto nivel de aparato eléctrico. ■■ Instalación y mantenimiento de equipos de vigilancia
A estos sistemas se les denomina colectivamente como ■■ Protección contra la ingeniería social.
Sistemas de Gestión de Edificios (BMS), aunque debido
a que estas herramientas están integradas, el término se E7  ENVÍO Y RECEPCIÓN
está usando para hacer referencia a un único sistema de Las instalaciones grandes requieren áreas especiales en
gestión integrado, en lugar de una recopilación imprecisa las que se puedan recepcionar las entregas de muebles,
de herramientas que realizan funciones similares. Debe equipos informáticos, racks, etc. Este área necesita
pensarse en usar herramientas de monitorización que se asegurarse para que el personal que realiza la entrega no
integren, o al menos sean consistentes, con herramientas pueda acceder al resto de la instalación. También existe la
de monitorización existentes. (Vea el Capítulo 7 para necesidad de que haya un almacén seguro cerca del área
disponer de más detalles sobre las herramientas). de recepción donde los elementos puedan almacenarse
hasta que se puedan trasladar hasta su ubicación final.
E5  Seguridad Es necesario aplicar un proceso para responsabilizarse de
Un aspecto importante de Gestión de las Instalaciones es los elementos que se envíen y que el contratista de la
la seguridad de las personas que trabajan en el edificio. entrega o envío retire sólo esos elementos. Siempre que
Por lo tanto, Gestión de las Instalaciones es responsable sea posible, estos elementos deberán organizarse en un
de entender y cumplir la legislación y los estándares de almacén seguro en el área de envío y recepción antes
seguridad pertinentes. de su envío. Esto evitará el acceso sin autorización a la
instalación.
La seguridad se exige en las siguientes áreas:
La documentación en entrega y envío tiene que estar
■■ Diseño y construcción de edificios
completa, revisada y firmada para cada remesa que se
■■ Distribución de las salas y equipos en la instalación
entregue o envíe. Deberá mantenerse un registro central
■■ Educación de todo el personal con respecto a de todas las remesas para su control.
estándares de seguridad obligatorios en la instalación
■■ Definición de procedimientos y rutas de evacuación y
puntos de reunión en caso de producirse un incendio
E8  Implicación en Gestión de
u otra situación que ponga en peligro la vida de las Contratos
personas. La mayoría de las instalaciones se aprovisionan, gestionan
■■ Envío de notificaciones e información asociadas con y se ponen en servicio a través de varias entidades.
cualquier información de seguridad de la que el Aunque los contratos reales con estas entidades deberán
personal deberá ser consciente. gestionarse típicamente mediante los departamentos
comerciales y legales pertinentes, Gestión de las
Instalaciones desempeñará un rol clave a la hora de
E6  Control de Acceso Físico
especificar y negociar estos contratos. Los contratos típicos
Ésta es una parte muy importante de Gestión de incluyen:
las Instalaciones y se ha desarrollado en un campo
■■ Gestión de alquileres para propiedades alquiladas.
especializado. Como tal, el contenido se resume aquí por
Esto es bastante infrecuente ya que la mayoría de las
conveniencia, pero se analiza con detalle en el Apéndice F.
organizaciones ven su Centro de Proceso de Datos
Los componentes principales de Control de Acceso Físico como un activo clave. Alquilar tales instalaciones se
(se analiza en el Apéndice F) son: vería como un riesgo debido a la posibilidad de que
■■ Ayuda en la definición y mantenimiento de Controles se venda el edificio, de que el arrendador clausure
de Acceso Físico como parte de las Políticas de sus actividades, o que el arrendador no cumpla el
Seguridad de la organización contrato en términos de mantenimiento adecuado.
■■ Mantenimiento de planes de plantas que indican las ■■ Alquiler o mantenimiento de equipos ambientales,
áreas que están restringidas como por ejemplo unidades de aire acondicionado,
■■ Instalación y mantenimiento de dispositivos de control
monitorización y alertas ambientales (equipos de
de acceso físico detección de humos o de supresión o extinción de
incendios).
■■ Monitorización y control del acceso a instalaciones
 Apéndice E: Descripción detallada de Gestión de las Instalaciones | 233

■■ Contratos de mantenimiento de edificios. Éstos actividades rutinarias de mantenimiento y el despliegue de

incluyen el mantenimiento de ascensores, suelos, cambios.
fontanería y alimentación eléctrica.
■■ Instalaciones de telecomunicaciones. Aunque las
telecomunicaciones normalmente están gestionadas
por un equipo o departamento dedicado o como
parte de una Red de Área Amplia, en muchas
ocasiones dependen de terceros que suministran y
mantienen los equipos de telecomunicación ubicados
dentro o justo al lado del Centro de Proceso de Datos.
En muchos países, estas tareas de mantenimiento
las realizan organizaciones de telecomunicaciones
gubernamentales o paraestatales. La gestión de estos
tipos de contratos requiere un conjunto de habilidades
especiales.
■■ Servicios de seguridad para la provisión de control
de acceso físico y de servicios de respuesta.
Una parte muy importante de Gestión de Contratos
es garantizar que el personal externo sea consciente y
cumpla las políticas de seguridad de la organización.
Esto incluye el control de acceso físico, confidencialidad y
uso sin autorización de las instalaciones o equipos de la
organización. Deberán realizarse auditorías regulares para
asegurar que se esté implementando este aspecto.

E9  Mantenimiento
Gestión de las Instalaciones es responsable de coordinar
todas las actividades de mantenimiento rutinario dentro
del edificio. Esto hace referencia al mantenimiento de
edificios además del mantenimiento de los equipos del
Centro de Proceso de Datos.
La razón de la inclusión del mantenimiento de equipos es
simplemente evitar que el edificio se exponga en exceso
a actividades inusuales en determinados momentos. El
hecho de que múltiples equipos trabajen a la vez en
diferentes lugares en el Centro de Proceso de Datos,
representa un riesgo de protección y seguridad.
Es importante tener en cuenta que el mantenimiento real
de los equipos de TI se realiza a través del personal de
Gestión Técnica, pero bajo la coordinación de Gestión de
Cambios y de Gestión de las Instalaciones.
El Gestor de las Instalaciones deberá mantener
una planificación maestra de todas las actividades
de mantenimiento planificadas para asegurar que
las actividades de mantenimiento se coordinen
adecuadamente. Esta planificación forma parte de la
Planificación de Cambios de Gestión de Cambios y se
utiliza para asegurar que no haya conflictos entre las
 Apéndice F:
Control de Acceso Físico F
 | 237

Apéndice F: Control de Acceso Físico

La Sección 5.12 y el Apéndice E introdujeron el área de ■■ Políticas en relación con la vigilancia del personal,
Control de Acceso Físico como parte de Gestión de las p. ej., qué podría registrarse, dónde y si existen
Instalaciones. Esta sección proporciona un análisis más algunas excepciones.
detallado de este área.
La mayoría de las organizaciones usan múltiples niveles
Gestión de la Seguridad de la Información es responsable de control de acceso, desde el acceso a la propiedad,
de la definición y documentación de todas las políticas pasando por el acceso a áreas específicas del edificio, y
de control de accesos. Estas políticas identificarán todas a continuación a funciones, equipos o salas específicos.
las medidas de seguridad física que es necesario adoptar Cada nivel de seguridad se implanta empleando diferentes
y establecerán qué grupos de empleados deberán tener mecanismos y personal, que proporcionan seguridad
acceso a determinadas zonas. Gestión de las Instalaciones adicional.
garantizará que estas políticas se implementen
Todas las instalaciones deberán tener un plano de
adecuadamente. Las políticas deberán incluir:
distribución actual y documentado que indique
■■ La áreas que están restringidas y para quién exactamente las áreas que están restringidas. Este plan
■■ Qué controles de acceso se implantarán también indicará las medidas de seguridad que se
■■ Bajo qué circunstancias se permitirá el acceso a áreas implementan y dónde. Esto ayudará a las auditorías de
específicas restringidas. Por ejemplo, evitar el acceso a seguridad y también al mantenimiento de los equipos de
la planta de un Centro de Proceso de Datos a menos control de accesos.
que se introduzca un número de RFC autorizado en Los dispositivos de control de accesos se instalarán
un teclado en todas las entradas y salidas. El objetivo de estos
■■ Cómo se monitorizará el control de accesos dispositivos es garantizar que sólo el personal autorizado
■■ Una declaración de políticas de privacidad y la acceda al área restringida. Aunque parezca a primera
información que tiene que conocerse para permitirse vista que este es un aspecto bastante claro, existen
el acceso varios elementos que deberán tenerse en cuenta (vea la
Tabla F.1).

Tabla F.1 Dispositivos de control de accesos

Control de accesos Ejemplo Ventajas Desventajas
Mecánico Cerradura y llave Estable y fiable Requiere control de llaves. Las
Barato cerraduras tienen que sustituirse cada
vez que alguien deje la organización.
Alguien que tenga conocimiento
de algunas técnicas sencillas puede
comprometer este tipo de control
Acceso por código Mecánico (p. ej., un dispositivo con Estable Alguien que observe al personal usar
pulsador montado en la puerta) Relativamente barato el dispositivo puede obtener el código
Electrónico (p. ej., un teclado fácilmente. El código tiene que
usado para armar o desarmar una cambiarse cada vez que alguien deje
alarma de seguridad) la organización
Las personas tienden a escribir el
código en algún sitio
238 | Apéndice F: Control de Acceso Físico

Tabla F.1 Dispositivos de control de accesos (continuado)

Control de accesos Ejemplo Ventajas Desventajas

Acceso electrónico Tarjetas llave Fáciles de usar Relativamente caro, aunque los
Se pueden usar para hacer el costes han disminuido, y en muchas
seguimiento del acceso del ocasiones es más barato que usar
personal recursos humanos para vigilar
físicamente cada punto de acceso
Se pueden cancelar o cambiar
centralizadamente para adecuarse a Depende de la disponibilidad de la
los cambios en los requisitos alimentación
Se pueden cancelar incluso si el Personas que utilizan equipos
personal no devuelve su tarjeta especializados de copia pueden
comprometer este sistema de control
Biométrico Escáner de retina o análisis de voz Mecanismo muy fiable para Depende de la disponibilidad de la
identificar individuos específicos alimentación
Difícil de falsear Requiere sistemas de control de
Más eficaz contra la ingeniería accesos más sofisticados
social Relativamente caro
Acceso múltiple Puerta con una tarjeta llave. Una Fácil de cambiar de un lugar a Difícil para controlar el ‘Seguimiento
persona abre la puerta y permite otro, especialmente cuando varios de cerca’
el acceso a cualquier número de grupos están trabajando juntos Depende de la concienciación sobre la
personas que le acompañ~an seguridad del personal autorizado
Extremadamente vulnerable a la
ingeniería social
No deberá usarse en áreas de alta
seguridad
Acceso individual El torno permite que sólo entre una Acceso fácil de controlar Podría formarse un cuello de botella
persona. No podrá usarse la misma Evita la ingeniería social de forma en horas pico
tarjeta llave para que entre una más eficaz Requiere más personal y vigilancia
segunda persona
Acceso La puerta giratoria sólo permite Es adecuado para situaciones Requiere más monitorización para
unidireccional el acceso o la salida. Se utiliza en las que no hay necesidad de asegurar que las personas no intenten
típicamente en aeropuertos donde monitorizar lo que las personas ir por la dirección errónea
el personal de seguridad sólo se sacan, pero en las que las cosas Típicamente unidireccional; también
preocupa por las personas que que entran podrían provocar daños implica vigilancia y equipos de
entran en el aeropuerto, pero no significativos escaneo adicionales
de aquellos que salen
Acceso Puerta con acceso controlado Adecuado para el acceso general a Las personas que salen pueden facilitar
bidireccional áreas restringidas el acceso a personal sin autorización
Podría producirse un cuello de botella
(p. ej., en tornos bidireccionales las
personas que salen tienen que esperar
a las personas que entran)
Activo Requiere la acción por parte del Facilita el acceso de control Requiere que el personal recuerde un
personal que obtiene acceso, p. ej., Más seguro código o lleve consigo una tarjeta
leyendo digitalmente una tarjeta llave
llave o perforando un código
 Apéndice F: Control de Acceso Físico | 239

Tabla F.1 Dispositivos de control de accesos (continuado)

Control de accesos Ejemplo Ventajas Desventajas

Pasivo Un detector pasivo desbloquea una Proporciona una salida más segura El personal sin autorización puede
salida desde dentro siempre que en el caso de producirse un obtener fácilmente el acceso
alguien se aproxime incendio esperando simplemente fuera de la
No requiere tarjetas llave para puerta
personas que se muevan hacia Puede activarse desde fuera insertando
áreas seguras algo bajo la puerta y moviéndolo
dentro del alcance del sensor

Debido a que la mayoría de los mecanismos de control de que se utilicen nuevamente. Esto se hace para
de acceso no son infalibles, es importante garantizar que garantizar que si se descubriera una acción maliciosa,
el acceso se pueda monitorizar y controlar. Esto se hace estas cintas se podrán usar en la investigación. Esto
mediante personal de seguridad especializado y mediante significa que la calidad de las imágenes deberá
equipos de vigilancia electrónica. ser lo suficientemente buena como para facilitar la
identificación de personas, pero también tienen que
Dado que la seguridad hace referencia a todo lo relativo
estar en un formato que facilite almacenar grandes
a la gestión del acceso de personas a una instalación,
cantidades de datos visuales.
se utilizarán personas que implanten las medidas de
■■ Registros de Eventos de Acceso. Éstos registran
seguridad. Las organizaciones más grandes cuentan
algunas veces con su propio personal de seguridad, típicamente cada entrada y salida de personal usando
pero la mayoría tenderá a externalizar el control de mecanismos electrónicos de acceso.
acceso físico a empresas especializadas. Esto se hace ■■ Unidades de detección pasiva para detectar la
normalmente por las siguientes razones: presencia de personal en un área en la que no debería
haber personal.
■■ Los vigilantes de seguridad requieren formación
■■ Alarmas que notificarán al personal de seguridad
especializada y normalmente están sujetos a diferentes
un acceso o salida sin autorización, con frecuencia
códigos disciplinarios (casi siempre militares) con
vinculadas con una alarma sonora.
respecto a la mayoría de los empleados de la
empresa. Esto en muchas ocasiones entra en conflicto Independientemente de cómo se asegure el entorno, la
con el tipo de código disciplinario más comercial y seguridad depende de la concienciación con respecto a la
se gestiona mejor mediante un conjunto de gestores seguridad de los empleados y los contratistas que trabajan
diferente que usan una cultura diferente de gestión. en la instalación. La ingeniería social es todavía una de las
■■ Es menos probable que las empresas externas se vean brechas más habituales de la seguridad física. La ingeniería
influenciadas por situaciones de ingeniería social, social hace referencia a la práctica de obtención de acceso
debido a que cuentan con formación especializada a una instalación usando habilidades interpersonales y de
y es improbable que entiendan algunos matices comunicación para convencer a alguna persona para que
internos de la organización que un ingeniero social le permita el acceso sin autorización a un edificio, área
experimentado pudiera usar. restringida, equipos o datos restringidos; o a armarios que
tengan documentos confidenciales.
Los equipos de vigilancia sirven para ampliar la eficacia de
los mecanismos de control de acceso físico y del personal A continuación se muestran ejemplos de ingeniería social.
de seguridad. Es importante tener en cuenta que ningún ■■ Presentarse como un empleado o contratista legítimo
equipo de vigilancia puede sustituir la presencia de un de la organización. La técnica común es acercarse al
vigilante de seguridad consciente y formado. Simplemente personal de seguridad y declarar que han perdido su
amplía su eficacia. A continuación se muestran ejemplos tarjeta de acceso. Se firma un Registro de Accesos y
de equipos de vigilancia que se usan habitualmente. se proporciona una tarjeta de visitante. Normalmente
■■ Cámaras de vídeo para monitorizar puntos de no hay una comprobación real de si la persona es
acceso clave y también puntos de acceso con menor un empleado legítimo, especialmente en áreas de
uso, lo que permite que un vigilante de seguridad recepción concurridas.
monitorice varias ubicaciones a la vez. Estas cámaras
normalmente graban las imágenes en cintas y los
vídeos se almacenan durante algún tiempo antes
240 | Apéndice F: Control de Acceso Físico

■■ Presentarse como alguien que tiene una razón para

tener acceso sin autorización a la instalación, p. ej., un
trabajador de empresas de servicio (gas, electricidad,
etc.) o inspector de incendios.
■■ Un antiguo empleado o contratista que se aproxima a
las personas con quienes está familiarizado para que
le permitan el acceso.
■■ ‘Seguimiento de cerca’, donde una persona
simplemente sigue a un empleado autorizado a través
de una entrada que hayan abierto.
La ingeniería social se detecta mejor cumpliendo
estrictamente los procedimientos de control de acceso,
con los programas de formación continua, sesiones
informativas regulares para el personal de seguridad y
auditorías estrictas.
Cada vez más empresas ofrecen servicios para probar el
rigor del control de accesos con personas especializadas
en el uso de técnicas de ingeniería social.
Glosario
 | 243

Lista de acrónimos
ACD Distribución Automática de Llamadas eSCM-SP Modelo de Madurez del eSourcing para
Proveedores de Servicio
AM Gestión de la Disponibilidad
FMEA Modos de Fallos y Análisis de los Efectos
AMIS S istema de Información de Gestión de la
Disponibilidad FTA Análisis por Árboles de Fallos
ASP Proveedor de Servicios de Aplicaciones IRR Tasa Interna de Retorno
BCM Gestión de la Capacidad del Negocio ISG Consejo de Dirección de TI
BCM Gestión de la Continuidad del Negocio ISM Gestión de la Seguridad de la Información
BCP Plan de Continuidad del Negocio ISMS Sistema de Gestión de la Seguridad de la
Información
BIA Análisis de Impacto sobre el negocio
ISO Organización Internacional de Normalización
BRM Gestor de las Relaciones con el Negocio
ISP Proveedor de Servicios de Internet
BSI B ritish Standards Institution (Institución Británica
de Estándares) TI Tecnologías de la Información
BSM Gestión del Servicio de Negocio ITSCM Gestión de la Continuidad del Servicio de TI
CAB Comité de Cambios ITSM Gestión de los Servicios de TI
CAB/EC Comité de Cambios / Comité de Emergencia itSMF Foro para la Gestión de los Servicios de TI
(ITSMf)
CAPEX Gasto de Capital
IVR Respuesta Interactiva de Voz
CCM Gestión de la Capacidad del Componente
KEDB Base de Datos de Errores Conocidos
CFIA Análisis de Impacto de Fallos de Componentes
KPI Indicador Clave de Rendimiento
CI Elemento de Configuración
LOS Línea de Servicio
CMDB Base de Datos de Gestión de la Configuración
MoR Gestión del Riesgo
CMIS Sistema de Información de Gestión de la
Capacidad MTBF Tiempo Medio entre Fallos
CMM Modelo de Madurez de la Capacidad MTBSI Tiempo Medio entre Incidencias de Servicio
CMMI Integración de Modelos de Capacidad y MTRS Tiempo Medio de Restauración del Servicio
Madurez
MTTR Tiempo Medio de Reparación
CMS Sistema de Gestión de la Configuración
NPV Valor Neto Actual
COTS Producto Software Empaquetado
OGC Office of Government Commerce (Oficina de
CSF Factor Crítico de Éxito Comercio del Gobierno Británico)
CSI Mejora Continua del Servicio OLA Acuerdo de Nivel Operativo
CSP Paquete de Servicio Esencial OPEX Gasto Operativo
CTI Integración de Telefonía e Informática OPSI Oficina de Información del Sector Público
DIKW Datos-a-Información-a-Conocimiento-a- PBA Modelo de Actividades de Negocio
Sabiduría
PFS Prerrequisitos para el Éxito
eSCM-CL Modelo de Madurez para Organizaciones
PIR Evaluación Post Implementación
Cliente
PSA Disponibilidad de Servicio Propuesta
244 | Glosario

QA Aseguramiento de la Calidad WIP Trabajo en Curso

QMS Sistema de Gestión de la Calidad
RCA Análisis de la Causa Raíz
RFC Solicitud de Cambio
ROI Retorno de la Inversión
RPO Punto Objetivo de Recuperación
RTO Objetivo de Tiempo de Recuperación
SAC Criterios de Aceptación del Servicio
SACM Gestión de la Configuración y de Activos del
Servicio
SCD Base de datos de Contratos y Proveedores
SCM Gestión de la Capacidad del Servicio
SFA Análisis de Fallos del Servicio
SIP Programa de Mejora de Servicio
SKMS Sistema de Gestión del Conocimiento del
Servicio
SLA Acuerdo de Nivel de Servicio
SLM Gestión del Nivel de Servicio
SLP Paquete del Nivel de Servicio
SLR Requerimientos de Nivel de Servicio
SMO Objetivos de la Gestión de Servicios
SoC Separación en Asuntos
SOP Procedimientos de Operación Estándar
SOR Declaración de Requisitos
SPI Interlocutor con el Proveedor de Servicios
SPM Gestión de la Cartera de Servicios
SPO Optimización de la Provisión del Servicio
SPOF Punto Único de Fallo
TCO Coste Total de Propiedad
TCU Coste Total de Utilización
TO Observación Técnica
TOR Términos de Referencia
TQM Gestión de Calidad Total
UC Contrato de Soporte
UP Perfil de Usuario
VBF Función Vital del Negocio
VOI Valor de la Inversión
 Glosario | 245

Lista de definiciones
Los nombres de la publicación incluidos entre paréntesis Organizativos, de Proceso, de Conocimiento, Personas,
después del nombre de un término, identifican el lugar Información, Aplicaciones, Infraestructura, y de Capital.
donde el lector podrá encontrar más información sobre
ese término. Esto se debe a que ese término se utiliza Activo del Servicio
fundamentalmente en esa publicación o porque allí se Cualquier Capacidad o Recurso de un Proveedor de
podrá encontrar información adicional de utilidad sobre Servicio. Vea también Activo.
el mismo. Los términos sin un nombre de publicación
asociado son utilizados por varias publicaciones, o Acuerdo
no están definidos con mayor detalle de lo que están
Documento que describe el entendimiento formal entre
en el glosario, es decir, sólo se dan indicaciones a los
dos o más partes. Un Acuerdo no tiene fuerza legal, a
lectores sobre los puntos en los que se puede ampliar el
menos que forme parte de un Contrato. Vea también
conocimiento o ver un contexto más amplio. Los términos
Acuerdo de Nivel de Servicio, Acuerdo de Nivel Operativo.
asociados a varios nombres de publicaciones se amplían
en más de una de ellas.
Acuerdo de Nivel de Servicio (SLA)
Donde la definición de un término incluya otro término, (Diseño del Servicio) (Mejora Continua del Servicio)
los términos asociados se resaltarán con un segundo Consiste en un Acuerdo entre un Proveedor de Servicios
color. Esto se ha considerado así para indicar a los lectores de TI y un Cliente. El SLA describe el Servicio de TI,
definiciones adicionales que forman parte del término documenta los Objetivos de Nivel de Servicio y especifica
original en el que están interesados. La forma ‘Vea también las responsabilidades del Proveedor de Servicios de TI y
Término X, Término Y’ se utiliza al final de una definición del Cliente. Un único SLA puede cubrir varios Servicios
si no se utilizara un término asociado importante con el de TI o varios Clientes. Vea también Acuerdo de Nivel
texto de la propia definición. Operativo.

Aceptación Acuerdos de Nivel Operativo (OLA)

Acuerdo formal que indica que un Servicio de TI, Proceso, (Diseño del Servicio) (Mejora Continua del Servicio)
Plan, u otro Entregable se ha completado, es preciso, Consiste en el Acuerdo entre un Proveedor de Servicios de
fiable y cumple los requisitos especificados. Normalmente TI y otra parte de la misma Organización. Un OLA soporta
la Aceptación está precedida por una Evaluación o Prueba la entrega de Servicios de TI del Proveedor de Servicios de
y se requiere antes de proceder con la siguiente etapa de TI a los Clientes. El OLA define los bienes y Servicios que
un Proyecto o Proceso. se suministrarán y las responsabilidades de ambas partes.
Por ejemplo, podrá haber un OLA:
Acreditado
■■ Entre el Proveedor de Servicios de TI y un
Autorizado oficialmente para un Rol. Por ejemplo, una
departamento de compras para obtener hardware en
entidad acreditada podría estar autorizada para impartir
los plazos acordados
cursos o dirigir una Auditoría.
■■ Entre el Centro de Servicio al Usuario y un Grupo
de Soporte para la Resolución de Incidencias en los
Actividad
plazos acordados.
Un conjunto de acciones diseñadas para alcanzar un
resultado específico. Normalmente, las Actividades Vea también Acuerdo de Nivel de Servicio.
se definen como parte de Procesos o Planes, y se
documentan en Procedimientos. Ajustado al Propósito
Un término informal usado para describir un Proceso,
Activo Elemento de Configuración, Servicio de TI, etc., que es
(Estrategia del Servicio) Cualquier Recurso o Capacidad. capaz de cumplir sus Objetivos o Niveles de Servicio. Estar
Los Activos de un Proveedor de Servicio incluyen todo Ajustado al Propósito requiere un diseño, implementación,
aquello que pueda contribuir a la entrega del Servicio. Los control y mantenimiento adecuados.
Activos pueden ser de los siguientes tipos: De Gestión,
246 | Glosario

Ajuste Análisis Cronológico

La Actividad responsable de la Planificación de Cambios (Operación del Servicio) Técnica empleada para ayudar a
para que el uso de los Recursos sea el más eficiente. identificar causas posibles de Problemas. Todos los datos
Los Ajustes forman parte de la Gestión del Rendimiento, disponibles sobre el Problema se recopilan y ordenan
que incluye Monitorización del Rendimiento y la por fecha y hora para proporcionar una escala temporal
implementación de los cambios requeridos. detallada. Esto hará posible identificar qué Eventos
pueden haber sido activados por otros.
Alerta
(Operación del Servicio) Advertencia de que se ha Análisis de Fallos del Servicio (SFA)
alcanzado un umbral, de que algo ha cambiado, o de (Diseño del Servicio) Una Actividad que identifica las
que se produjo un Fallo. En general, las Alertas se crean causas subyacentes de una o más interrupciones del
y gestionan con herramientas de Gestión de Sistemas y Servicio de TI. SFA identifica oportunidades de mejora
están administradas por el Proceso de Gestión de Eventos. tanto de Procesos del Proveedor de Servicios de TI como
de las herramientas y la Infraestructura de TI. SFA es más
Alta Disponibilidad una Actividad de tipo proyecto limitada en tiempo que un
(Diseño del Servicio) Una metodología o diseño que proceso continuo de análisis.
minimiza u oculta a los Usuarios de un Servicio de TI los
efectos del Fallo de un Elemento de Configuración. Las Análisis de Impacto de Fallos de
soluciones de Alta disponibilidad se diseñan para alcanzar Componentes (CFIA)
los niveles acordados de disponibilidad y para hacer (Diseño del Servicio) Técnica utilizada para ayudar a
uso de técnicas como la Tolerancia a Fallos, Resistencia identificar el impacto que produce un fallo de CI sobre
y Recuperación rápida, para reducir el número de los Servicios de TI. Se elabora a partir de una matriz que
Incidencias y el Impacto de las mismas. contiene los Servicios de TI en un extremo y los CI en el
otro. Esto permite la identificación de los CI críticos (que
Ámbito podrían provocar el fallo de múltiples Servicios de TI) y
El límite o grado en el que se aplica un Proceso, de los Servicios de TI poco robustos (que tienen múltiples
Procedimiento, Certificación, Contrato, etc. Por ejemplo, Puntos Únicos de Fallo).
el Ámbito de la Gestión de Cambios puede incluir todos
los Servicios de TI reales y Elementos de Configuración Análisis de Impacto en el Negocio (BIA)
asociados, el Ámbito de un Certificado ISO/IEC 20000 (Estrategia del Servicio) BIA es la Actividad de la Gestión
puede incluir todos los Servicios de TI implementados de la Continuidad del Negocio que identifica las
desde un centro de datos en cuestión. Funciones Vitales del Negocio y sus dependencias. Estas
dependencias pueden incluir Proveedores, personas, otros
Amenaza Procesos de Negocio, Servicios de TI, etc. BIA define los
Cualquier cosa que pueda aprovechar una Vulnerabilidad. requisitos de recuperación para los Servicios de TI. Dichos
Cualquier causa potencial de una Incidencia puede ser requisitos incluyen Objetivos de Tiempos de Recuperación,
considerada una Amenaza. Por ejemplo, un fuego es una Objetivos del Punto de Recuperación y los Objetivos de
Amenaza que puede aprovechar la Vulnerabilidad de los Nivel de Servicio mínimos para cada Servicio de TI.
suelos inflamables. Este término se utiliza comúnmente
en la Gestión de la Seguridad de la Información y en Análisis de Kepner & Tregoe
la Gestión de la Continuidad del Servicio de TI, pero (Operación del Servicio) (Mejora Continua del Servicio)
también se aplica a otras áreas tales como Gestión de la Enfoque estructurado para la resolución de Problemas. El
Disponibilidad y Problemas. Problema se analiza en términos de qué, dónde, cuándo
y en qué medida. Se identifican las posibles causas. Se
Análisis Coste-Beneficio prueba la causa más probable. Se verifica la verdadera
Una Actividad que analiza y compara los Costes y los causa.
beneficios involucrados en uno o más cursos de acción
alternativos. Vea también Caso de Negocio. Análisis de la Causa Raíz (RCA)
(Operación del Servicio) Una Actividad que identifica
la Causa Raíz de una Incidencia o Problema. El RCA se
 Glosario | 247

concentra habitualmente en fallos de la Infraestructura de Aseguramiento de la Calidad (QA)

TI. (Transición del Servicio) Es el Proceso responsable de
garantizar que la Calidad de un producto, Servicio o
Análisis de Tendencias Proceso estará al nivel de su Valor previsto.
(Mejora Continua del Servicio) El análisis de datos para
identificar patrones en el tiempo. Análisis de Tendencias Asociación
se utiliza en Gestión de Problemas para identificar Es una relación entre dos Organizaciones que supone
Fallos comunes o Elementos de Configuración frágiles, una estrecha colaboración entre ambas, orientada a la
y en Gestión de Capacidad como una herramienta de consecución de objetivos comunes para el beneficio
modelización para predecir el comportamiento futuro. mutuo. Un Proveedor de Servicios de TI debería tener
También se usa como una herramienta de gestión para una relación de Sociedad con el Negocio, así como con
identificar deficiencias en los Procesos de Gestión de los aquellos Terceros que sean críticos para proveer los
Servicios de TI. Servicios de TI. Vea también Red de Valor.

Análisis del Árbol de Fallos (FTA) Atributo

(Diseño del Servicio) (Mejora Continua del Servicio) Una (Transición del Servicio) Una parte de información de
técnica que puede usarse para determinar la cadena de un Elemento de Configuración. Ejemplos: nombre,
Eventos que lleva a un Problema. El Análisis del Árbol de ubicación, Número de la versión, y Coste. Los Atributos
Fallos representa la cadena de Eventos utilizando notación de un CI se registran en la Base de Datos de Gestión de la
Booleana en un diagrama. Configuración (CMDB). Vea también Relación.

Análisis del Valor de los Daños Auditoría

(Operación del Servicio) Técnica empleada para ayudar Inspección y verificación formal para verificar si un
a identificar el Impacto del Negocio de uno o más Estándar o un conjunto de Directrices se está siguiendo,
problemas. Se utiliza una fórmula para calcular el Valor si sus Registros son precisos, o si las metas de Eficiencia
de los Daños basada en el número de Usuarios afectados, y Eficacia se están cumpliendo. Una Auditoría la puede
la duración del Tiempo de Caída, el Impacto sobre cada realizar tanto un grupo interno como externo.
Usuario, y el coste del Negocio (si se conoce).
Backup
Aplicación
(Diseño del Servicio) (Operación del Servicio) Copia de
Programa que ofrece Funciones requeridas por un Servicio datos para protegerlos de la pérdida de Integridad o
de TI. Cada Aplicación podría ser parte de más de un Disponibilidad de los datos originales.
Servicio de TI. Una Aplicación se puede ejecutar en uno
o más Servidores o Clientes. Vea también Gestión de Base de Conocimiento
Aplicaciones, Porfolio de Aplicaciones.
(Transición del Servicio) Base de datos lógica que contiene
los datos empleados por el Sistema de Gestión del
Aprovisionamiento de Servicios Interno
Conocimiento del Servicio.
(Estrategia del Servicio) Uso de un Proveedor Interno de
Servicios para la gestión de Servicios de TI. Base de Datos de Errores Conocidos (KEDB)
(Operación del Servicio) Base de datos que contiene todos
Arquitectura
los Registros de Errores Conocidos. Esta base de datos
(Diseño del Servicio) La estructura de un Sistema o está creada por Gestión de Problemas y la usan Gestión
un Servicio de TI, incluyendo las Relaciones de sus de Incidencias y de Problemas. La Base de Datos de
Componentes y del entorno en el que se encuentran. Errores Conocidos forma parte del Sistema de Gestión del
La Arquitectura también incluye los Estándares y las Conocimiento del Sistema.
Directrices que dirigen el diseño y evolución del Sistema.
Base de Datos de Gestión de la
Configuración (CMDB)
(Transición del Servicio) Base de Datos usada para
almacenar Registros de Configuración durante todo su
248 | Glosario

Ciclo de Vida. El Sistema de Gestión de la Configuración Calidad

mantiene una o más CMDB, y cada CMDB contiene Característica de un producto, Servicio o Proceso
Atributos de CI, y Relaciones con otros CI. para proporcionar su propio valor. Por ejemplo, un
Componente hardware puede ser considerado de alta
Benchmark Calidad si rinde según lo esperado y proporciona la
(Mejora Continua del Servicio) El estado registrado de Fiabilidad requerida. La Calidad de un Proceso requiere
algo en un punto específico de tiempo. Un Benchmark se la capacidad para medir su Eficacia y Eficiencia, o incluso
puede crear para una Configuración, Proceso, o cualquier para mejorarlas si fuese necesario. Vea también Sistema de
otro conjunto de datos. Por ejemplo, se puede usar un Gestión de la Calidad.
benchmark en:
■■ Mejora Continua del Servicio, para establecer el estado Cambio
actual para gestionar las mejoras (Transición del Servicio) Adición, modificación o
■■ Gestión de Capacidad, para documentar características eliminación de algo que podría afectar a los Servicios
de Rendimiento durante las operaciones normales. de TI. El Alcance debería incluir todos los Servicios de TI,
Elementos de Configuración, Procesos, Documentación,
Vea también Benchmarking, Línea de Referencia. etc.

Benchmarking Cambio de Emergencia

(Mejora Continua del Servicio) Comparar un Benchmark (Transición del Servicio) Cambio que deberá introducirse
con una Línea de Referencia o con una Mejor Práctica. lo antes posible. Por ejemplo, para resolver una Incidencia
El término Benchmarking también se usa para referirse Grave o para implementar un parche de seguridad. El
a la creación de una serie de Benchmarks en el tiempo, Proceso de Gestión de Cambios normalmente tendrá
y comparar los resultados para medir el progreso o la un Procedimiento específico para tratar Cambios de
mejora. Emergencia. Vea también Comité de Cambios de
Emergencia (ECAB).
Biblioteca Definitiva de Medios (DML)
(Transición del Servicio) Una o más ubicaciones en las Cambio Estándar
que se almacenan de forma segura versiones definitivas y (Transición del Servicio) Un Cambio preautorizado que
aprobadas para todos los Elementos de Configuración de representa un Riesgo bajo, es relativamente habitual y que
Software. La DML también podría contener CIs asociados cumple un Procedimiento o una Instrucción de Trabajo.
como por ejemplo licencias y documentación. La DML es Por ejemplo, restablecimiento de claves y provisión de
un área de almacenamiento lógico único incluso si existen equipos estándar para un nuevo empleado. Las RFC
múltiples ubicaciones. Todo el software en la DML estará no se requieren para implementar un Cambio Estándar
bajo el control de Gestión de Cambios y de la Entrega, y y se registran y se les hace el seguimiento usando un
se registra en el Sistema de Gestión de la Configuración. mecanismo diferente, como por ejemplo una Petición de
Sólo se acepta software de la DML para su uso en una Servicio. Vea también Escenario de Cambios.
Entrega
Capacidad
Bucle de Control de la Monitorización
(Diseño del Servicio) Rendimiento máximo que se puede
(Operación del Servicio) Monitorización de la salida obtener de un Elemento de Configuración o Servicio de TI
de una Tarea, Proceso, Servicio de TI o Elemento de en el cumplimiento de los Objetivos de Nivel de Servicio
Configuración; comparando dicha salida con un patrón acordados. Para algunos tipos de CI, la Capacidad puede
predefinido y tomando las acciones apropiadas en base a ser el tamaño o el volumen, por ejemplo, de una unidad
esta comparación. de disco.

Cadena de Suministro Capacidad de Recuperación

(Estrategia del Servicio) Actividades en la Cadena de (Diseño del Servicio) La capacidad de resistencia de un
Valor acometidas por Suministradores. Una Cadena de Elemento de Configuración o Servicio de TI ante Fallos o
Suministro implica típicamente múltiples Suministradores, de Recuperarse rápidamente tras un Fallo. Por ejemplo, un
cada uno de ellos aportando valor al producto o Servicio. cable reforzado resistirá fallos cuando esté bajo estrés. Vea
también Tolerancia a Fallos.
 Glosario | 249

Capacidad de Respuesta similares. Por ejemplo, los Tipos de Coste se usan para
Medida del tiempo consumido para responder a algo. agrupar tipos similares de Costes. Las Categorías de
Podría ser un Tiempo de Respuesta o una Transacción, Incidencias se usan para agrupar tipos similares de
o la velocidad a la que un Proveedor de Servicios de TI Incidencias, Los Tipos de CI, se usan para agrupar clases
responde a una Incidencia o a una Solicitud de Cambio, similares de Elementos de Configuración.
etc.
Causa Raíz
Carga de Trabajo (Operación del Servicio) La causa original o subyacente de
Los Recursos requeridos para entregar una parte una Incidencia o Problema.
identificable de un Servicio de TI. Las Cargas de Trabajo
pueden Categorizarse por Usuarios, grupos de Usuarios, o Centro de Atención al Usuario
Funciones dentro de un Servicio de TI. Se usa para ayudar (Operación del Servicio) Un punto de contacto para que
en el análisis y gestión de la Capacidad, Rendimiento y los Usuarios puedan registrar Incidencias. Un Centro
Uso de Elementos de Configuración y Servicios de TI. El de Atención al Usuario normalmente tiene un enfoque
término Carga de Trabajo se usa a veces como sinónimo más técnico que un Centro de Servicio al Usuario y no
de Rendimiento. proporciona un Punto Único de Contacto. El término
Centro de Atención al Usuario se utiliza a menudo como
Caso de Cambio sinónimo del Centro de Servicio al Usuario.
(Operación del Servicio) Técnica empleada para predecir
el impacto de Cambios propuestos. Los Escenarios del Centro de Llamadas
Cambio utilizan escenarios específicos para aclarar el (Operación del Servicio) Organización o Unidad de
alcance de los Cambios propuestos y para ayudar con el Negocio que gestiona gran cantidad de llamadas
Análisis Coste-Beneficio. Vea también Caso de Uso. telefónicas entrantes y salientes. Vea también Centro de
Servicio al Usuario.
Caso de Negocio
(Estrategia del Servicio) Justificación para el gasto de Centro de Servicio al Usuario
un elemento relevante. Incluye información de Costes, (Operación del Servicio) Punto Único de Contacto entre
beneficios, opciones, situaciones, Riesgos, y posibles el Proveedor de Servicio y los Usuarios. Un Centro de
problemas. Vea también Análisis Coste-Beneficio. Servicio al Usuario típico gestiona Incidencias, Peticiones
de Servicio, y también la comunicación con los Usuarios.
Caso de Uso
(Diseño del Servicio) Una técnica usada para definir la Cerrado
funcionalidad requerida, los Objetivos y el Diseño de (Operación del Servicio) Estado final en el Ciclo de Vida de
Pruebas. Los Casos de Uso definen escenarios realistas que una Incidencia, Problema, Cambio, etc. Cuando el Estado
describen las interacciones entre Usuarios y un Servicio de es Cerrado, no se ejecuta ninguna acción adicional.
TI u otro Sistema. Vea también Caso de Cambio.
Certificación
Catálogo de servicios Emisión de un certificado que acredita la Conformidad con
(Diseño del Servicio) Una base de datos o un Documento un Estándar. La Certificación incluye una Auditoría formal
estructurado con información sobre todos los Servicios realizada por un organismo independiente y Acreditado.
de TI en activo, incluyendo aquellos disponibles para el El término Certificación también se usa para denotar la
Despliegue. El Catálogo de Servicios es la única parte concesión de un certificado que acredita que una persona
publicada del Portfolio de Servicios para Clientes, y se ha logrado una cualificación determinada.
utiliza para apoyar la venta y entrega de los Servicios de
TI. El Catálogo de Servicios incluye puntos de contacto, Ciclo de Vida
entregables, órdenes de entrega y Procesos de solicitud. Las diversas etapas en la vida de un Servicio de TI,
Elemento de Configuración, Incidencia, Problema, Cambio,
Categoría etc. El Ciclo de Vida define las Categorías de cada Estado y
Denominación de un grupo de cosas que tienen algo en las transiciones de Estado permitidas. Por ejemplo:
común. Las Categorías se usan para agrupar contenidos
250 | Glosario

■■ El Ciclo de Vida de una Aplicación incluye Requisitos, Cliente de Negocio

Diseñar, Construir, Desplegar, Operar, Optimizar (Estrategia del Servicio) El receptor de un producto o
■■ El Ciclo de Vida Extendido de la Incidencia incluye Servicio del Negocio. Por ejemplo, si el Negocio es un
Detectar, Responder, Diagnosticar, Reparar, Recuperar, fabricante de coches, entonces el Cliente de Negocio es
Restaurar. quien compra un coche.
■■ El Ciclo de Vida de un Servidor puede incluir: Pedido,
Recibido, En Pruebas, Operativo, Retirado, etc. Cliente Externo
Un Cliente que trabaja para un Negocio diferente al del
Ciclo de Vida de la Gestión del Servicio Proveedor de Servicios de TI. Vea también Proveedor
Aproximación a la Gestión de los Servicios de TI que pone Externo de Servicios.
énfasis en la importancia de la coordinación y el Control
a través de las diferentes Funciones, Procesos y Sistemas COBIT
necesarios para gestionar el Ciclo de Vida completo de (Mejora Continua del Servicio) Objetivos de Control para
los Servicios de TI. La aproximación del Ciclo de Vida la Información y las Tecnología Relacionada (COBIT)
de la Gestión del Servicio incluye la Estrategia, Diseño, proporciona las directrices y Mejores Prácticas para la
Transición, Operación y Mejora Continua de los Servicios gestión de los Procesos de TI. COBIT está publicado por el
de TI. IT Governance Institute. Vea www.isaca.org para disponer
de más información.
Cierre
(Operación del Servicio) La acción de cambiar el Estado de Comité de Cambios (CAB)
una Incidencia, Problema, Cambio, etc., a Cerrado. (Transición del Servicio) Grupo de personas que asesora
al Gestor de Cambios en la evaluación, priorización y
Clasificación planificación de los Cambios. Este comité está formado
Acción de asignar una Categoría a algo. La Clasificación se por representantes de todas las áreas del Proveedor de
usa para garantizar una gestión y sistema de creación de Servicios de TI, del Negocio y Proveedores Externos.
informes sólidos. Elementos que se suelen clasificar: CIs,
Incidentes, Problemas, Cambios etc. Comité de Cambios de Emergencia (ECAB)
(Transición del Servicio) Subconjunto del Comité de
Cliente Cambios que toma decisiones sobre Cambios de
Alguien que compra bienes o Servicios. El Cliente Emergencia de gran impacto. Los miembros del ECAB
de un Proveedor de Servicios de TI es la persona o pueden determinarse en el mismo momento en el que es
grupo que define y acuerda los Objetivos de Nivel de convocado y su composición variará dependiendo de la
Servicio. El término Cliente -customer- también se utiliza naturaleza del Cambio de Emergencia.
informalmente para Usuario, por ejemplo: “Esta es una
Organización enfocada al Usuario". Componente
Término genérico usado para definir una parte de algo
Cliente más complejo. Por ejemplo, un Sistema informático puede
Término genérico que describe un Cliente, Negocio o ser un Componente de un Servicio de TI, una Aplicación
Cliente de Negocio. Por ejemplo, Gestor de Clientes podría puede ser un Componente de una Unidad de Entrega. Los
utilizarse como sinónimo de Gestor de Cuentas. Componentes que necesitan ser gestionados deberían ser
El término cliente también se usa para definir: Elementos de Configuración.

■■ Un ordenador que un Usuario utiliza directamente, por Concurrencia

ejemplo, un PC, un portátil, o estación de trabajo
Una medida del número de Usuarios que realizan una
■■ La parte de una Aplicación Cliente-Servidor con el que
misma Operación al mismo tiempo.
el Usuario se relaciona directamente. Por ejemplo, un
Cliente de correo electrónico.
Confidencialidad
(Diseño del Servicio) Principio de seguridad que requiere
que sólo personal autorizado pueda acceder a los datos.
 Glosario | 251

Configuración Contramedida o medida de seguridad. Control también

(Transición del Servicio) Término genérico usado para es un medio de gestionar el uso o comportamiento de un
describir un grupo de Elementos de Configuración que Elemento de Configuración, Sistema o Servicio de TI.
actúan o funcionan juntos para proveer un Servicio de TI,
o un subconjunto representativo de un Servicio de TI. El Control de Configuración
término Configuración también se usa para describir los (Transición del Servicio) La Actividad responsable de
parámetros de uno o más CI. asegurar que la adición, modificación o eliminación de un
CI se gestionen adecuadamente, por ejemplo enviando
Conformidad una Solicitud de Cambio o Petición de Servicio.
Garantía del cumplimiento de un Estándar o conjunto
de Directrices, o que se emplean unas prácticas de Control de Costes
seguimiento adecuadas y consistentes. (Estrategia del Servicio) El Proceso responsable de
identificar los Costes de la entrega de Servicios de
Construir TI, comparándolos con los costes presupuestados, y
(Transición del Servicio) La Actividad de montaje de un registrando las diferencias con el Presupuesto
número de Elementos de Configuración para crear parte
de un Servicio de TI. El termino Construir también se Control de Operaciones
utiliza para hacer referencia a una Versión que se autoriza Vea Control de Operaciones de TI.
para su distribución. Por ejemplo, Construcción de un
Servidor o Construcción de un ordenador portátil. Control de Operaciones de TI
(Operación del Servicio) La Función responsable de
Contabilidad de Costes Monitorizar y Controlar los Servicios de TI e Infraestructura
(Estrategia del Servicio) El Proceso responsable de de TI. Vea también Puente de Operaciones.
identificar los Costes de la entrega de Servicios de
TI, comparándolos con los costes presupuestados, y Control de Procesos
registrando las diferencias con el Presupuesto. Es la Actividad de planificación y regulación de un
Proceso, con el Objetivo de garantizar un desarrollo
Contramedida Eficiente, Eficaz y coherente del Proceso.
Puede usarse para referirse a algún tipo de Control. El
término Contramedida es muy usado cuando se refiere a Corrección
medidas que incrementan la Capacidad de recuperación, (Transición del Servicio) Recuperación de un estado
Tolerancia a fallos o Fiabilidad de un Servicio de TI. conocido después del fallo de una Versión o Cambio.

Contrato Coste
Un Acuerdo de validez legal entre dos o más partes. La cantidad de dinero gastada en una Actividad específica,
Servicio de TI, o Unidad de Negocio. Los Costes consisten
Contrato de Soporte (UC) de un coste real (dinero), o coste subjetivo, tal como el
(Diseño del Servicio) Un Contrato entre un Proveedor de tiempo de la gente y Depreciación.
Servicios de TI y un Tercero. El Tercero proporciona bienes
o Servicios que soportan la entrega de un Servicio de Coste de Capital (CAPEX)
TI a un Cliente. El Contrato de Soporte define objetivos (Estrategia del Servicio) Coste asociado a la compra
y responsabilidades que se requieren para alcanzar los de algo que se convertirá en un Activo financiero,
Objetivos de Nivel de Servicio en un SLA. por ejemplo, equipos informáticos o edificios. El valor
de un Activo se Deprecia durante varios periodos de
Control contabilización.
Un medio de gestión de Riesgo que asegura que se
alcance el Objetivo de Negocio, o que asegura que se Coste Indirecto
sigue un Proceso. Por poner ejemplos, los Controles (Estrategia del Servicio) El Coste de proveer un Servicio de
incluyen Políticas, Procedimientos, Roles, RAID, door- TI que no se puede asignar completamente a un Cliente
locks, etc. Algunas veces al control se le denomina específico. Por ejemplo, el Coste de proveer Servidores
252 | Glosario

compartidos o licencias de software. También conocido Declaración de Requisitos (SOR)

como Gasto General. (Diseño del Servicio) Un Documento que contiene todos
los Requisitos para una compra de producto, o para un
Coste Operativo Servicio de TI nuevo o modificado.
Coste que resulta de la ejecución de Servicios de TI.
Frecuentemente son pagos reiterativos. Por ejemplo, Dependencia
costes de personal, electricidad y mantenimiento del La dependencia directa o indirecta de un Proceso o
hardware (también conocido como 'gastos corrientes' o Actividad sobre otro.
'gastos de explotación'). Vea también Gastos de Capital.
Derechos
Coste Unitario
(Operación del Servicio) Los permisos concedidos a un
(Estrategia del Servicio) El Coste para el Proveedor de Usuario o Rol. Por ejemplo, el Derecho a modificar una
Servicios de TI de proporcionar un único Componente de información en concreto, o a autorizar un Cambio.
un Servicio de TI. Por ejemplo el Coste de un PC, o una
única Transacción. Desarrollo
(Diseño del Servicio) Proceso responsable de crear o
Cuadro de Mando Integral
modificar un Servicio de TI o Aplicación. También usado
(Mejora Continua del Servicio) Herramienta de gestión para referirse al Rol o grupo encargado del trabajo de
desarrollada por los Doctores Robert Kaplan (Escuela de Desarrollo.
Negocios de Harvard) y David Norton. Un Cuadro de
Mando Integral permite dividir la Estrategia en Indicadores Descripción del Puesto de Trabajo
Clave de Rendimiento. El Rendimiento frente a los KPI se
Documento que define los Roles, responsabilidades,
usa para medir el éxito en la consecución de la Estrategia.
aptitudes y conocimiento requeridos por una persona en
El Cuadro de Mando Integral tiene 4 áreas principales,
particular. Una Descripción del Puesto de Trabajo puede
cada una con un número pequeño de KPIs. Las mismas 4
incluir múltiples Roles, por ejemplo, los Roles de Gestor
áreas se consideran en diferente nivel de detalle a lo largo
de la Configuración y Gestor de Cambios pueden ser
de la Organización.
desempeñados por una sola persona.
Cualificación
Despliegue
(Transición del Servicio) Actividad que garantiza que
(Transición del Servicio) Vea Puesta en Producción.
la Infraestructura de TI es la apropiada y se encuentra
Se utiliza con más frecuencia para hacer referencia a
configurada correctamente para albergar una Aplicación o
Despliegues complejos o por fases o a Despliegues en
Servicio de TI. Vea también Validación.
múltiples ubicaciones.
Cultura
Detección
Un conjunto de valores que un grupo de personas
(Operación del Servicio) Etapa en el Ciclo de Vida de la
comparte, incluyendo expectativas acerca de cómo
Incidencia. La detección lleva a que la Incidencia sea
la gente debería comportarse, sus creencias, ideas y
conocida por el Proveedor de Servicios. La detección
prácticas. Vea también Visión.
puede ser automática, o a través de un registro de
incidencia de un Usuario.
Cultura de Servicios
Cultura orientada al Cliente. Los Objetivos principales de Diagnóstico
una Cultura de Servicios son la satisfacción del Cliente y
(Operación del Servicio) Una etapa en el Ciclo de vida de
ayudar al Cliente a conseguir sus Objetivos de Negocio.
Incidencias y Problemas. El propósito de Diagnóstico es
identificar una Solución Provisional para una Incidencia o
Cumplimiento
la Causa Raíz de un Problema.
Realizar Actividades para cumplir una necesidad o
Requisito. Por ejemplo, proporcionar un nuevo Servicio de Diagrama de espina de pescado
TI, o cumplir una Solicitud de Servicio.
Vea Diagrama de Ishikawa.
 Glosario | 253

Diagrama de Ishikawa entrante hacia la persona más adecuada en el menor

(Operación del Servicio) (Mejora Continua del Servicio) tiempo posible. Algunas veces se le llama Distribución
Una técnica que ayuda a un equipo a identificar las Automatizada de Llamada.
posibles causas de un Problema. Originalmente diseñada
por Kaoru Ishikawa, el resultado de está técnica es un Documento
diagrama parecido a la espina de un pez. Información en formato legible. Un Documento puede
estar en papel o en formato electrónico. Por ejemplo,
Dimensionamiento de la Aplicación la declaración de una Política, un Acuerdo de Nivel de
(Diseño del Servicio) Actividad responsable de entender Servicio, un Registro de Incidencia, el plano de una sala
los Requisitos de Recursos necesarios para soportar una de ordenadores. Vea también Registro.
Aplicación nueva, o un Cambio importante sobre una
Aplicación existente. El Dimensionado de la Aplicación Economías de Escala
ayuda a asegurar que los Servicios de TI pueden cumplir (Estrategia del Servicio) La reducción en Coste medio que
los Objetivos de Nivel de Servicio acordados para la será posible incrementando la utilización de un Servicio
Capacidad y el Rendimiento. de TI o un Activo.

Directriz Eficacia
Un Documento que describe las Mejores Prácticas que (Mejora Continua del Servicio) Una medida para saber si
recomiendan lo que se debe hacer. Normalmente no se se han alcanzado los Objetivos de un Proceso, Servicio
obliga a la conformidad con una directriz. Vea también o Actividad. Una actividad o Proceso Eficaz es aquél que
Estándar. alcanza sus Objetivos acordados. Vea también KPI.

Diseño Eficiencia
(Diseño del Servicio) Actividad o Proceso que identifica (Mejora Continua del Servicio) Una medida para
Requisitos y que a continuación define una solución determinar si se ha utilizado la cantidad correcta de
que es capaz de alcanzar dichos Requisitos. Vea también recursos en la provisión de un Proceso, Servicio o
Diseño del Servicio. Actividad. Un Proceso Eficaz alcanza sus Objetivos con el
mínimo de tiempo, dinero, personas u otros recursos. Vea
Diseño del Servicio también KPI.
(Diseño del Servicio) Una fase en el Ciclo de Vida de un
Servicio de TI. Diseño del Servicio incluye varios Procesos Elemento de Configuración (CI)
y Funciones y es el título de una de las publicaciones (Transición del Servicio) Cualquier Componente que
esenciales de ITIL. Vea también Diseño. necesite ser gestionado con el objeto de proveer un
Servicio de TI. La información sobre cada CI se almacena
Disponibilidad en un Registro de Configuración dentro del Sistema de
(Diseño del Servicio) Capacidad de un Elemento de Gestión de la Configuración y se mantiene durante todo
Configuración o de un Servicio de TI para cumplir las su Ciclo de Vida mediante Gestión de la Configuración.
Funciones que se le suponen cuando se requiere. La Los CI están bajo el control de Gestión de Cambios.
Disponibilidad la determinan la Fiabilidad, Capacidad Típicamente, los CI son Servicios de TI, hardware,
de Mantenimiento, Capacidad de Servicio, Rendimiento, software, edificios, personal, y documentación formal
y Seguridad. Normalmente la Disponibilidad se calcula como documentación de Procesos y SLAs.
en porcentajes. Éste cálculo se basa normalmente en el
Tiempo de Servicio Acordado y en el Tiempo de Caída. Empaquetado
Calcular la Disponibilidad usando métricas de resultados Vea también Producto Software Empaquetado.
de Negocio respecto del Servicio de TI se considera como
una Mejor Práctica. Entorno
(Transición del Servicio) Un subconjunto de la
Distribución Automática de Llamada (ACD) Infraestructura de TI que se utiliza para un propósito
(Operación del Servicio) El uso de las Tecnologías de particular. Por ejemplo: Entorno de Producción, Entorno
la Información para redirigir una llamada telefónica de Pruebas, Entorno de Construcción. Para múltiples
254 | Glosario

Entornos existirá la posibilidad de compartir Elementos Proceso defectuoso que impacta en un CI o en un Servicio
de Configuración, por ejemplo, los entornos de Pruebas de TI.
y Producción pueden usar diferentes particiones en
una única máquina mainframe. También se utiliza en el Error Conocido
término de “entorno físico” para definir instalaciones, aire (Operación del Servicio) Problema que tiene una Causa
acondicionado, sistema eléctrico, etc. Raíz documentada y una Solución Provisional. Los Errores
Entorno también se usa como término genérico para Conocidos se crean y gestionan a través de su Ciclo de
definir condiciones externas que influyen o afectan sobre Vida mediante la Gestión de Problemas. Los equipos
algo. de Desarrollo o los Suministradores también podrían
identificar Errores Conocidos.
Entorno de Desarrollo
(Diseño del Servicio) Entorno usado para crear o modificar
Escalabilidad
Servicios de TI o Aplicaciones. Los Entornos de Desarrollo Capacidad de un Servicio de TI, Proceso, Elemento de
normalmente no están sometidos al mismo grado de Configuración, etc., a la hora de realizar su Función
control que el Entorno de Pruebas o de Producción. Vea acordada cuando la Carga de Trabajo o el Ámbito
también Desarrollo. cambian.

Entorno de producción Escalado

(Transición del Servicio) Entorno controlado que contiene (Operación del Servicio ) Una Actividad que obtiene
Elementos de Configuración Reales empleados para Recursos adicionales cuando son necesarios para alcanzar
proveer Servicios de TI a los Clientes. las metas de Nivel de Servicio o las expectativas del
Cliente. El escalado puede ser necesario dentro de
Entorno de Producción cualquier Proceso de Gestión de los Servicios de TI, pero
normalmente se asocia más con Gestión de Incidencias,
Vea Entorno de Producción.
Gestión de Problemas y Gestión de quejas de Clientes.
Existen dos tipos de Escalado: Escalado Funcional y
Entorno de Pruebas
Escalado Jerárquico.
(Transición del Servicio) Entorno controlado empleado
para probar Elementos de Configuración, desarrollos, Escalado Funcional
Servicios de TI, Procesos, etc.
(Operación del Servicio) Transferencia de una Incidencia,
Problema o Cambio a un equipo técnico con un alto nivel
Entrega
de experiencia para que ayude en un Escalado.
(Transición del Servicio) Colección de hardware, software,
documentación, Procesos, u otros Componentes Escalado Jerárquico
requeridos para implementar uno o más Cambios
(Operación del Servicio) Informar o implicar a niveles más
aprobados en los Servicios de TI. Los contenidos de cada
senior de gestión para que ayuden en un Escalado.
Versión se gestionan, prueban, e implementan como una
única entidad.
Escenario del Cambio
Entregable (Operación del Servicio) Técnica empleada para predecir
el impacto de Cambios propuestos. Los Escenarios del
Algo que se debe proporcionar para cumplir un
Cambio utilizan escenarios específicos para aclarar el
compromiso en un Acuerdo de Nivel de Servicio o en
alcance de los Cambios propuestos y para ayudar con el
un Contrato. Entregable también se usa en forma más
Análisis Coste-Beneficio. Vea también Caso de Uso.
informal para una resultado planificado de cualquier
Proceso.
Especificación
Error Definición formal de Requisitos. Una Especificación puede
usarse para definir Requisitos Técnicos u Operativos, y
(Operación del Servicio) Un defecto de diseño o mal
puede ser interna o externa. Muchos Estándares públicos
funcionamiento que causa Fallos en uno o más Elementos
consisten en un Código de Prácticas y una Especificación.
de Configuración o Servicios de TI. También se considerará
un Error, a aquel error cometido por una persona o un
 Glosario | 255

La Especificación define el Estándar frente al que una La evaluación también se usa para comparar el Resultado
Organización puede ser Auditada. real con el pretendido, o comparar una alternativa con
otra.
Estado
Nombre de un campo requerido en muchos tipos de Evaluación
Registros. Muestra la situación actual de un Elemento de Inspección y análisis para verificar si se está siguiendo un
Configuración, Incidencia o Problema, etc., en su Ciclo de Estándar o un conjunto de Directrices, si sus Registros son
Vida. precisos, o si las metas de Eficiencia y Eficacia se están
cumpliendo. Vea también Auditoría.
Estándar
Un Requisito obligatorio. Por ejemplo ISO/IEC 20000 Evaluación del Riesgo
(Estándar internacional), la seguridad interna estándar para Los pasos iniciales de la Gestión del Riesgo. Analizar el
una configuración Unix, o un estándar gubernamental valor de los Activos del negocio, identificando Amenazas
acerca de cómo mantener los Registros financieros. El para esos Activos, y evaluando la Vulnerabilidad de cada
término Estándar también se emplea para definir un Activo con respecto a esas Amenazas. La Evaluación del
Código de Prácticas o Especificación publicada por una Riesgo puede ser cuantitativa (basada en datos numéricos)
Organización de Estándares como ISO o BSI. Vea también o cualitativa.
Directriz.
Evento
Estimación (Operación del Servicio) Un cambio de estado significativo
Uso de la experiencia para proporcionar un valor para la gestión de un Elemento de Configuración o un
aproximado para una Métrica o Coste. La Estimación Servicio de TI.
también se usa en Gestión de la Capacidad y de la
El término Evento también se usa como Alerta o
Disponibilidad como un método de modelado más
notificación creada por un Servicio de TI, Elemento de
económico pero menos preciso.
Configuración o herramienta de Monitorización. Los
Eventos requieren normalmente que el personal de
Estrategia Operaciones de TI tome acciones, y a menudo conllevan el
(Estrategia del Servicio) Plan Estratégico diseñado para registro de Incidencias.
alcanzar determinados Objetivos.
Factor Crítico de Éxito (CSF)
Estrategia del Servicio Algo que debe existir si un Proceso, Proyecto, Plan, o
(Estrategia del Servicio) Título de uno de los libros Servicio de TI desea tener éxito. Los KPI se utilizan para
Esenciales de ITIL. La Estrategia del Servicio establece una medir el alcance de cada CSF. Por ejemplo: un CSF de
Estrategia general para los Servicios de TI y para la Gestión “proteger los Servicios de TI cuando se hacen Cambios”
de los Servicios de TI. podría medirse a través de KPIs tales como “reducción
del porcentaje de Cambios fallidos”, o “porcentaje de
Estratégico reducción de Cambios que causan Incidencias”, etc.
(Estrategia del Servicio) El más alto de los tres niveles de
Planificación y entrega (Estratégico, Táctico y Operativo). Fallo
Las Actividades Estratégicas incluyen el establecimiento de (Operación del Servicio) Pérdida de la habilidad de Operar
Objetivos y la Planificación a largo plazo para alcanzar la de acuerdo con las Especificaciones, o de proporcionar el
Visión global. resultado requerido. El término Fallo puede usarse cuando
nos referimos a Servicios de TI, Procesos, Actividades,
Evaluación Elementos de Configuración, etc. Un Fallo a menudo
(Transición del Servicio) Proceso responsable de evaluar un provoca una Incidencia.
Servicio de TI nuevo o modificado para asegurar que los
Riesgos se han gestionado y para ayudar a determinar si se Fallo
debe proceder con el Cambio. Vea Error.
256 | Glosario

Fiabilidad Gestión de Accesos

(Diseño del Servicio) (Mejora Continua del Servicio) (Operación del Servicio) Proceso responsable de permitir
Medida de cuánto tiempo un Elemento de Configuración a los Usuarios hacer uso de los Servicios de TI, datos, u
o Servicio de TI puede ejecutar de forma ininterrumpida otros Activos. La Gestión de Accesos ayuda a proteger
su Función acordada. Generalmente se mide como MTBF la Confidencialidad, Integridad y Disponibilidad de los
o MTBSI. El término Fiabilidad también puede utilizarse Activos, asegurando que sólo los Usuarios autorizados
para definir la probabilidad de que un Proceso, Función, puedan acceder o modificar los Activos. Algunas veces se
etc., responda de la forma esperada. Vea también hace referencia a la Gestión de Accesos como Gestión de
Disponibilidad. Derechos o Gestión de Identidades.

Foro para la Gestión de los Servicios de TI Gestión de Activos

(itSMF) (Transición del Servicio) Proceso responsable de dar
El Foro para la Gestión de los Servicios de TI (itSMF) es seguimiento e informar del valor y la propiedad de los
una Organización independiente dedicada a promover Activos financieros en todo el Ciclo de Vida. La Gestión
una aproximación profesional a la Gestión de los Servicios de Activos forma parte de los Activos del Servicio y del
de TI. itSMF es una Organización sin ánimo de lucro con Proceso de Gestión de la Configuración. Vea también
representación en gran número de países de todo el Registro de Activos.
mundo (delegaciones de itSMF). itSMF y sus miembros
contribuyen al desarrollo de ITIL y de los Estándares de Gestión de Aplicaciones
Gestión de los Servicios de TI asociados. Vea www.itsmf. (Diseño del Servicio) (Operación del Servicio) Función
com para disponer de más información. responsable de gestionar las Aplicaciones en su Ciclo de
Vida.
Función
Un equipo o grupo de personas y las herramientas que Gestión de Calidad Total (TQM)
usan para llevar a cabo uno o más Procesos o Actividades. (Mejora Continua del Servicio) Una metodología para
Por ejemplo, el Centro de Servicio al Usuario. gestionar la mejora continua mediante el uso del Sistema
El término Función también tiene otros dos significados: de Gestión de Calidad. TQM establece una Cultura,
involucrando a todo el personal de la Organización en un
■■ El propósito de un Elemento de Configuración, Proceso de continua monitorización y mejora.
Persona, Equipo, Proceso o Servicio de TI. Por ejemplo,
una Función del Servicio de Correo Electrónico puede Gestión de Cambios
ser almacenar y reenviar correos, una Función de
(Transición del Servicio) Proceso responsable del control
un Proceso de Negocio puede ser entregar bienes a
del Ciclo de Vida de los Cambios. El objetivo principal
Clientes.
de Gestión de Cambios es permitir la ejecución de los
■■ Realizar correctamente el propósito pretendido: 'El
Cambios que van a reportar beneficios, con la mínima
ordenador está funcionando'. interferencia en los Servicios de TI.

Función Vital de Negocio (VBF) Gestión de Capacidad del Negocio (BCM)

(Diseño del Servicio) Una Función de un Proceso de (Diseño del Servicio) En el contexto de ITSM, la Gestión
Negocio que es critica para el éxito del Negocio. Las de Capacidad del Negocio es la Actividad responsable
Funciones Vitales del Negocio son consideraciones de comprender los futuros Requisitos de Negocio para
importantes para la Gestión de la Continuidad del usarlos en el Plan de Capacidad. Vea también Gestión de
Negocio, Gestión de la Continuidad del Servicio de TI y la Capacidad del Servicio.
Gestión de la Disponibilidad.
Gestión de Continuidad de los Servicios de
Gasto General
Tecnologías de la Información (ITSCM)
Vea Coste Indirecto.
(Diseño del Servicio) Proceso responsable de gestionar los
Riesgos que podrían impactar seriamente a los Servicios
Gasto operativo (OPEX)
de TI. ITSCM asegura que el Proveedor de Servicios de
Vea Coste Operativo. TI pueda proporcionar siempre los Niveles de Servicio
 Glosario | 257

mínimos acordados, reduciendo el Riesgo a un nivel de la Configuración forma parte del Proceso de Gestión de
aceptable y Planificando la Recuperación de los Servicios la Configuración y Activos del Servicio.
de TI. ITSCM debería diseñarse de tal manera que soporte
la Gestión de la Continuidad del Negocio. Gestión de la Configuración y Activos del
Servicio (SACM)
Gestión de Eventos (Transición del Servicio) El Proceso responsable de la
(Operación del Servicio) Proceso responsable de la gestión Gestión de la Configuración y Gestión de Activos.
de Eventos a lo largo de su Ciclo de Vida. La Gestión
de Eventos es una de las principales Actividades de Gestión de la Continuidad del Servicio
Operaciones de TI.
Vea Gestión de la Continuidad del Servicio de TI.

Gestión de Incidencias Gestión de la Demanda

(Operación del Servicio) Proceso responsable de la gestión
Actividades que entienden e influyen en la demanda del
del Ciclo de vida de todas las Incidencias. El objetivo
Cliente de Servicios y en la provisión de Capacidad para
principal de la Gestión de Incidencias es recuperar lo antes
cumplir con esas demandas. A nivel estratégico, la Gestión
posible el Servicio de TI para los Usuarios.
de la Demanda puede incluir un análisis de los patrones
de Actividad de Negocio y Perfiles de Usuarios. A nivel
Gestión de la Capacidad táctico puede incluir el uso de tarifas diferenciadas para
(Diseño del Servicio) Proceso responsable de asegurar que alentar a los Usuarios a utilizar los Servicios de TI en horas
la Capacidad de los Servicios de TI y la Infraestructura de de baja actividad. Vea también Gestión de la Capacidad.
TI es capaz de proveer los Objetivos de Nivel de Servicio
en los niveles de tiempo y Rentabilidad acordados. La Gestión de la Disponibilidad
Gestión de Capacidad tiene en cuenta todos los Recursos
(Diseño del Servicio) Proceso responsable de definir,
requeridos para proveer el Servicio de TI, y la planificación
analizar, Planificar, medir y mejorar todos los aspectos
de los Requisitos de Negocio a corto, medio y largo plazo.
relativos a la Disponibilidad de los Servicios de TI. La
Gestión de la Disponibilidad tiene la responsabilidad de
Gestión de la Capacidad del Componente que toda la Infraestructura de TI, Procesos, Herramientas,
(CCM) Roles, etc., son los adecuados a los Objetivos de Nivel de
(Diseño del Servicio) (Mejora Continua del Servicio) Servicio sobre Disponibilidad.
Proceso responsable de la comprensión de la Capacidad,
Utilización, y Rendimiento de los Elementos de Gestión de la Seguridad
Configuración. Se recopilan datos, se archivan y se Vea Gestión de la Seguridad de la Información.
analizan para su uso en el Plan de Capacidad. Vea también
Gestión de la Capacidad del Servicio. Gestión de la Seguridad de la Información
(ISM)
Gestión de la Capacidad del Servicio (SCM)
(Diseño del Servicio) Proceso que asegura la
(Diseño del Servicio) (Mejora Continua del Servicio) La
Confidencialidad, Integridad y Disponibilidad de los
Actividad responsable de comprender el Rendimiento y
Activos de una Organización, información, datos
la Capacidad de los Servicios de TI. Los Recursos usados
y Servicios de TI. La Gestión de la Seguridad de la
por cada Servicio de TI y el patrón de uso siguiendo una
Información normalmente forma parte de un acercamiento
línea temporal se recogen, registran y analizan para ser
organizativo a la Gestión de la Seguridad de alcance
utilizados en el Plan de Capacidad. Vea también Gestión
mayor que el que tiene el Proveedor de Servicios de
de la Capacidad del Negocio y Gestión de la Capacidad
TI e incluye control de documentos de acceso, acceso
del Recurso.
a edificios, llamadas de teléfono, etc., para toda la
Organización.
Gestión de la Configuración
(Transición del Servicio) Proceso responsable de mantener Gestión de Versiones
la información sobre los Elementos de Configuración
(Transición del Servicio) Proceso responsable de la
requeridos para la provisión de un Servicio de TI,
Planificación, Programación y Control del paso de
incluyendo las Relaciones entre ellos. Esta información se
Versiones a los entornos de pruebas y producción. El
gestiona durante todo el Ciclo de Vida del CI. La Gestión
258 | Glosario

Objetivo principal de la Gestión de Versiones es asegurarse Gestión de Problemas

de se protege la integridad del Entorno de Producción (Operación del Servicio) Proceso responsable de la
y de que se liberen sólo los Componentes correctos. La gestión del Ciclo de vida de todos los Problemas. El
Gestión de Versiones es parte del Proceso de Gestión de principal Objetivo de la Gestión de Problemas es prevenir
Versiones y del Despliegue. Incidencias, así como reducir el Impacto de aquellas que
no haya sido posible prevenir.
Gestión de las Instalaciones
(Operación del Servicio) Función responsable de la gestión Gestión de Sistemas
del Entorno físico en el que se ubica la Infraestructura de La parte de Gestión de los Servicios de TI que se centra
TI. Gestión de las Instalaciones incluye todos los aspectos en la gestión de la Infraestructura de TI en lugar de en los
de la gestión del Entorno físico, por ejemplo, energía Procesos.
eléctrica o refrigeración, la Gestión de Accesos de los
edificios, y Monitorización del entorno. Gestión de Suministradores
(Diseño del Servicio) Proceso responsable de asegurar
Gestión de las Relaciones con el Negocio
que todos los Contratos con Proveedores soportan las
(Estrategia del Servicio) El Proceso o Función responsable necesidades del Negocio, y que todos los Proveedores
del mantenimiento de la Relación con el Negocio. cumplen sus compromisos contractuales.
Normalmente incluye:
■■ gestión de las Relaciones personales con los directivos Gestión de Versiones y Despliegue
■■ Proporcionar información a la Gestión de la Cartera de (Transición del Servicio) Proceso responsable de la Gestión
Servicios de Versiones y Despliegue.
■■ Asegurarse de que el Proveedor de Servicios de TI
está satisfaciendo las necesidades de Negocio de los Gestión del Almacenamiento
Clientes (Operación del Servicio) Proceso responsable de gestionar
Este Proceso está fuertemente relacionado con la Gestión y mantener el almacenamiento de datos a lo largo de su
de Niveles de Servicio. Ciclo de Vida.

Gestión de los Servicios de TI (ITSM) Gestión del Conocimiento

Implantación y gestión de Servicios de TI de Calidad (Transición del Servicio) Proceso responsable de
que cumplan con las necesidades del Negocio. Los recoger, analizar, almacenar y compartir conocimiento
Proveedores de Servicios de TI llevan a cabo la Gestión de e información dentro de una Organización. El propósito
los Servicios de TI a través de la adecuada combinación de principal de la Gestión del Conocimiento es mejorar
personas, Procesos y Tecnologías de la Información. Vea la Eficiencia reduciendo la necesidad de redescubrir el
también Gestión del Servicio. conocimiento.

Gestión de Operaciones Gestión del Nivel de Servicio (SLM)

Vea Gestión de Operaciones de TI. (Diseño del Servicio) (Mejora Continua del Servicio)
Proceso responsable de negociar y asegurar el
Gestión de Operaciones de TI cumplimiento de los Acuerdos de Nivel de Servicio. SLM
es responsable de asegurar que todos los Procesos de
(Operación del Servicio) Función dentro de un Proveedor
Gestión de los Servicios de TI, Acuerdos de Nivel Operativo
de Servicios de TI que se encarga de ejecutar las
y Contratos de Soporte son adecuados con respecto a los
Actividades diarias necesarias para gestionar los Servicios
Objetivos de Nivel de Servicio. SLM monitoriza e informa
de TI y la Infraestructura de TI que los soporta. Gestión de
de los Niveles de Servicio y mantiene revisiones periódicas
Operaciones de TI incluye el Control de Operaciones de TI
con el Cliente.
y la Gestión de las Instalaciones.
Gestión del Porfolio de Servicios (SPM)
Gestión de Peticiones
(Estrategia del Servicio) Proceso responsable de gestionar
(Operación del Servicio) Proceso responsable de la gestión
el Porfolio de Servicios. La Gestión de la Cartera de
del Ciclo de Vida de todas las Peticiones de Servicio.
 Glosario | 259

Servicios contempla los Servicios en términos del valor de identificar posibles Problemas o tendencias que puedan
que proporcionan al Negocio. causarlos.

Gestión del Rendimiento Gestión Técnica

(Mejora Continua del Servicio) Es el Proceso responsable (Operación del Servicio) La Función responsable de
de las Actividades del día a día dentro de la Gestión de proporcionar capacidades técnicas en el soporte de los
la Capacidad. Incluye la monitorización, detección de Servicios de TI y en la gestión de la Infraestructura de
umbrales, análisis de Rendimiento y Ajustes, así como TI. La Gestión Técnica define los roles de los Grupos
la implementación de Cambios relacionados con el de Soporte, así como las herramientas, Procesos y
Rendimiento o la Capacidad. Procedimientos requeridos.

Gestión del Riesgo Gestor de Cuentas

El Proceso responsable de identificar, evaluar y controlar (Estrategia del Servicio) Rol muy parecido a Gestor de las
Riesgos. Vea también Evaluación del Riesgo. Relaciones con el Negocio, aunque incluye más aspectos
comerciales. Se utiliza más habitualmente cuando se
Gestión del Riesgo (MoR) trabaja con Clientes Externos.
La metodología OGC para la gestión de Riesgos. MoR
incluye todas las Actividades necesarias para identificar y Gestor del Proceso
Controlar toda exposición al Riesgo que pueda tener un Es el Rol responsable de la gestión Operativa de un
impacto en la consecución de los Objetivos de Negocio de Proceso. Las responsabilidades del Gestor del Proceso
la Organización. Vea www.m-o-r.org para disponer de más cubren la Planificación y coordinación de todas las
detalles. Actividades necesarias para el desarrollo, seguimiento y
registro de actividad de un Proceso. Pueden existir más
Gestión del Servicio de un Gestor del Proceso para un Proceso determinado,
Un conjunto de Funciones y Procesos para gestionar como pueden ser Gestores de Cambio por regiones
Servicios durante su Ciclo de Vida. Gestión del Servicio geográficas, o Gestores de Continuidad de los Servicios
también se utiliza como sinónimo de Gestión del Servicio de TI para cada Centro de Proceso de Datos. El Rol del
de TI. Gestor del Proceso se asigna normalmente a la persona
que desempeña también el Rol de Propietario del Proceso
Gestión del Servicio de Negocio (BSM) aunque en grandes Organizaciones, ambos Roles pueden
estar separados.
(Estrategia del Servicio) (Diseño del Servicio) Metodología
de gestión de Servicios de TI que tiene en cuenta los
Gestor del Servicio
Procesos de Negocio soportados y el Valor para el negocio
proporcionado. Gestor que es responsable de gestionar el Ciclo de
Vida de uno o más Servicios de TI de principio a fin.
Este término también hace referencia a la gestión de El término Gestor del Servicio también se emplea para
Servicios de Negocio entregados a Clientes del Negocio. referirse a un gestor dentro del Proveedor de Servicios de
TI. Habitualmente empleado para referirse al Gestor de
Gestión Financiera Relaciones con el Negocio, Gestor de Procesos o Gestor de
(Estrategia del Servicio) La Función y Procesos Cuentas o a un gestor con responsabilidad en el conjunto
responsables de gestionar los requisitos de Presupuesto, de Servicios de TI.
Contabilidad e Imputación de Costes de un Proveedor de
Servicios de TI. Gobierno
Asegurar que se implementan las Políticas y Estrategias,
Gestión Proactiva de Problemas y que se siguen correctamente los Procesos requeridos.
(Operación del Servicio) Parte del Proceso de Gestión El Gobierno incluye definir los Roles y Responsabilidades,
de Problemas. El Objetivo de la Gestión Proactiva de medir y generar informes, y tomar acciones para resolver
Problemas es la predicción de Problemas. La Gestión cualquier problema identificado.
Proactiva de Problemas analiza los Registros de
Incidencias, así como los datos recibidos por otros
Procesos de Gestión de los Servicios de TI con el propósito
260 | Glosario

Grupo de Soporte Incidencia

(Operación del Servicio) Un grupo de personas con (Operación del Servicio) Interrupción no planificada
capacidades técnicas. Los Grupos de Soporte proporcionan de un Servicio de TI o reducción en la Calidad de un
el Soporte Técnico necesario para todos los Procesos Servicio de TI. También lo es el Fallo de un Elemento de
de Gestión de los Servicios de TI. Vea también Gestión Configuración que todavía no ha impactado en el Servicio.
Técnica. Por ejemplo, el Fallo de uno de los discos de un “mirror".

Habilidad Incidencia Grave

(Estrategia del Servicio) Capacidad de una Organización, (Operación del Servicio) La Categoría mayor de Impacto
persona, Proceso, Aplicación, Elemento de Configuración para una Incidencia. Una Incidencia Grave genera una
o Servicio de TI para el desarrollo de una Actividad. Las interrupción significativa del Negocio.
Habilidades son Activos intangibles de una Organización.
Vea también Recurso. Indicador Clave de Rendimiento (KPI)
(Mejora Continua del Servicio) Métrica empleada para
Horario del Servicio ayudar a gestionar un Proceso, Servicio de TI o Actividad.
(Diseño del Servicio) (Mejora Continua del Servicio) Muchas Métricas pueden medirse pero sólo las más
Un periodo de tiempo acordado cuando debería estar importantes se definen como KPIs y son empleadas para
Disponible un Servicio de TI en particular. Por ejemplo, gestionar de forma activa e informar sobre los Procesos,
'Lunes-Viernes de 08:00 a 17:00 excepto días festivos'. El los Servicios de TI o las Actividades. Los KPI deberían
Horario del Servicio debe definirse en un Acuerdo de Nivel seleccionarse de tal forma que aseguren el control de la
de Servicio. Eficiencia, la Eficacia, y la Rentabilidad. Vea también Factor
Crítico de Éxito.
Identidad
(Operación del Servicio) Se utiliza un nombre único para Información de Gestión
identificar a un Usuario, persona o Rol. La Identidad se Información empleada para apoyar la toma de decisiones
utiliza para conceder Derechos a ese Usuario, persona, o de los gestores. La Información de Gestión a menudo se
Roles. Por ejemplo, las identidades podrían ser el nombre genera automáticamente a través de las herramientas que
de usuario SmithJ o el Rol 'Gestor de cambios'. soportan los diversos Procesos de Gestión de Servicios
de TI. La Información de Gestión suele incluir los valores
Impacto de los KPI como por ejemplo “Porcentaje de Cambios
(Operación del Servicio) (Transición del Servicio) Una precedidos por Incidencias”, o “tasa de resolución en
medida del efecto de una Incidencia, Problema o Cambio primera instancia”.
en los Procesos de Negocio. Normalmente el Impacto se
basa en cómo se verán afectados los Niveles de Servicio. Informe de Excepciones
El Impacto y la Urgencia se emplean para asignar la Un documento que contiene detalles de uno o más KPIs
Prioridad. u otros objetivos importantes que hayan superado los
umbrales definidos. Por ejemplo, objetivos de los SLA
Impulsor fallidos o a punto de ello, y Métricas de Rendimiento que
Algo que influye en la Estrategia, Objetivos o Requisitos. indiquen un problema potencial de Capacidad.
Por ejemplo, una nueva legislación o las acciones de
competidores. Informes del Servicio
(Mejora Continua del Servicio) Proceso responsable de la
Imputación de Costes generación y entrega de los informes de cumplimiento
(Estrategia del Servicio) Requerir el pago por la provisión y tendencias de Niveles de Servicio. Los Informes del
de Servicios de TI. La Imputación de Costes para Servicios Servicio deben acordar con los Clientes el formato,
de TI es opcional, y muchas Organizaciones optan por contenido y frecuencia de los informes.
tratar a su Proveedor de Servicios de TI como un Centro
de Coste. Infraestructura de TI
Todo el hardware, software, redes, instalaciones etc.
requeridas para Desarrollar, Probar, proveer, Monitorizar,
 Glosario | 261

Controlar o soportar los Servicios de TI. El término ISO/IEC 20000

Infraestructura de TI incluye todas las Tecnologías Especificación ISO y Código de Práctica para la Gestión
de la Información pero no las personas, Procesos y de los Servicios de TI. ISO/IEC 20000 está alineado con las
documentación asociados. Mejores Prácticas ITIL.

Instrucción de Trabajo ISO/IEC 27001

Un Documento que contiene instrucciones detalladas que (Diseño del Servicio) (Mejora Continua del Servicio)
especifican exactamente qué pasos seguir para acometer Especificación ISO para la Gestión de la Seguridad de la
una Actividad. Una Instrucción de Trabajo contiene Información. El Código de Práctica correspondiente es ISO/
muchos más detalles que un Procedimiento y sólo se crea IEC 17799. Vea también Estándar.
cuando se necesitan instrucciones muy detalladas.
ITIL
Integración de Telefonía e Informática (CTI)
Conjunto de Mejores Prácticas para la Gestión de los
(Operación del Servicio) Integración de Telefonía e Servicios de TI. ITIL es propiedad de la OGC y consiste
Informática (CTI) es un término general que implica en una serie de publicaciones que aconsejan sobre
cualquier tipo de integración entre ordenadores y sistemas la provisión de Servicios de TI de Calidad, y sobre los
de telefonía. Se utiliza habitualmente para hacer referencia Procesos y las instalaciones necesarias para soportarlos.
a Sistemas donde una Aplicación visualiza pantallas Vea www.itil.co.uk para disponer de más información.
detalladas asociadas con llamadas telefónicas entrantes
y salientes. Vea también Distribución Automática de Línea de Referencia
Llamadas, Respuesta Interactiva de Voz.
(Mejora Continua del Servicio) Una Referencia que se usa
como punto de referencia. Por ejemplo:
Integridad
(Diseño del Servicio) Un principio de seguridad que ■■ Una Línea de Referencia de ITSM se puede usar como
certifica que sólo personal y Actividades autorizados punto de partida para medir el resultado de un Plan
puedan modificar Elementos de Configuración. La de Mejora del Servicio
Integridad considera todas las posibles causas de ■■ Una Línea de Referencia de la Gestión de la
modificación, incluyendo Fallos de software y hardware, Configuración puede servir para restablecer la
Eventos medioambientales e intervención humana. Infraestructura de TI en una Configuración conocida en
caso de fallo de un Cambio o de un Entregable.
Interesado ■■ Gestión de Capacidad, para documentar características
Conjunto de personas que tienen interés en una de Rendimiento durante las operaciones normales.
Organización, Proyecto, Servicio de TI, etc. Los Interesados Vea también Benchmarking, Línea de Referencia.
pueden interesarse en las Actividades, Objetivos, Recursos
o Entregables. Los Interesados pueden incluir Clientes, Llamada
Asociaciones, empleados, accionistas, propietarios, etc.
(Operación del Servicio) Llamada telefónica de un Usuario
al Centro de Servicio al Usuario. Una Llamada puede
Internalizar derivar en el registro de una Incidencia o una Petición de
Vea Aprovisionamiento de Servicios Interno. Servicio.

Invocación Madurez
(Diseño del Servicio) Inicio de los pasos definidos en un (Mejora Continua del Servicio) Medida de la Fiabilidad,
plan. Por ejemplo, inicio del Plan de Continuidad de los Eficiencia y Eficacia de un Proceso, Función, Organización,
Servicios de TI para uno o más Servicios de TI. etc. Los Procesos y Funciones más maduros están
íntimamente alineados con los Objetivos de Negocio y con
ISO 9000 la Estrategia, y están soportados por un marco de trabajo
Término genérico que se refiere a un conjunto de para la mejora continua.
Estándares y Directrices para los Sistemas de Gestión
de la Calidad. Vea www.iso.org para disponer de más
información. Vea también ISO.
262 | Glosario

Mejor Práctica Modelo

Actividades o Procesos que más de una Organización han Representación de un Sistema, Proceso, Servicio de TI,
usado con éxito. ITIL es un ejemplo de Mejor Práctica. Elemento de Configuración, etc., que se emplea para
ayudar a entender o predecir comportamientos futuros.
Mejora Continua del Servicio (CSI)
(Mejora Continua del Servicio) Una etapa en el Ciclo Modelo de Cambio
de vida de un Servicio de TI y el título de una de las (Transición del Servicio) Una forma repetible de abordar
publicaciones esenciales de ITIL. La Mejora Continua una Categoría de Cambio particular. Un Modelo de
del Servicio es responsable de la gestión de mejoras en Cambios define los pasos predefinidos específicos que
los Procesos de Gestión de los Servicios de TI y de los seguirán a un cambio de esta categoría. Los Modelos
Servicios de TI. El Rendimiento de los Proveedores de de Cambios podrían ser muy simples, sin requisitos para
Servicios de TI se mide continuamente y las mejoras se la aprobación (p. ej., Cambio de Contraseña) o podrían
realizan en los Procesos, Servicios de TI e Infraestructura ser muy complejos con muchos pasos que requieran
de TI para incrementar su Eficiencia y Eficacia, y aprobación (p. ej., versión importante de software). Vea
Rentabilidad. Vea también Planificar-Hacer-Verificar-Actuar. también Cambio Estándar, Comité de Cambios.

Métrica Modelo de Madurez del eSourcing para

(Mejora Continua del Servicio) Algo que se mide y de Proveedores de Servicio (eSCM-SP)
lo que se informa para ayudar a gestionar un Proceso, (Estrategia del Servicio) Un marco de trabajo para ayudar
Servicio de TI o Actividad. Vea también KPI. a los Proveedores de Servicios de TI a desarrollar sus
Capacidades de Gestión de los Servicios de TI desde una
Métrica Externa perspectiva de Aprovisionamiento del Servicio. eSCM-SP
Una Métrica que se utiliza para medir la entrega de fue desarrollado por la Carnegie Mellon University, EE.UU.
Servicios de TI a un Cliente. Las Métricas Externas
normalmente se definen en SLAs y se transmiten a los Monitorización
Clientes. Vea también Métrica Interna. (Operación del Servicio) Observación repetida de un
Elemento de Configuración, Servicio de TI o Proceso para
Métrica Interna detectar Eventos y asegurarse de que se conoce el estado
Una Métrica que se utiliza dentro del Proveedor de actual.
Servicios de TI para Monitorizar la Eficiencia, Eficacia,
Rentabilidad de los Procesos internos del Proveedor de Monitorización Activa
Servicios de TI. Las Métricas Internas normalmente no (Operación del Servicio) Monitorización de un Elemento
se comunican al Cliente del Servicio de TI. Vea también de Configuración o un Servicio de TI que utiliza de forma
Métrica Externa. regular revisiones automatizadas para descubrir el estado
actual. Vea también Monitorización pasiva.
Middleware
(Diseño del Servicio) Software que conecta uno o más Monitorización Pasiva
Componentes o Aplicaciones software. El Middleware (Operación del Servicio) Monitorización de un Elemento
generalmente se adquiere de un Suministrador, en lugar de Configuración o un Servicio de TI o un Proceso que
de desarrollarlo dentro del Proveedor de Servicios de TI. radica en una Alerta o notificación para descubrir el estado
Vea también Empaquetado. actual. Vea también Monitorización Activa.

Modelado Monitorización Proactiva

Técnica que se emplea para predecir el comportamiento (Operación del Servicio) Monitorización que busca
futuro de un Sistema, Proceso, Servicio de TI, Elemento patrones de Eventos para predecir posibles Fallos en el
de Configuración, etc. El Modelado suele emplearse en futuro. Vea también Monitorización Reactiva.
Gestión Financiera, Gestión de Capacidad y Gestión de la
Disponibilidad. Monitorización Reactiva
(Operación del Servicio) Monitorización que toma acciones
como respuesta a un Evento. Por ejemplo, envío de un
 Glosario | 263

trabajo por lotes cuando se complete el trabajo previo, o Objetivos de Control para las Tecnologías de
registro de una Incidencia cuando se produce un Error. la Información (COBIT)
Vea también Monitorización Proactiva.
Vea COBIT.

Negocio
Observación Técnica
(Estrategia del Servicio) El total de una entidad u
(Mejora Continua del Servicio) Una técnica usada en la
Organización compuesta por un número de Unidades de
Mejora del Servicio, investigación de Problemas y Gestión
Negocio. En el contexto de ITSM, en el Negocio se incluye
de la Disponibilidad. El personal de Soporte Técnico se
tanto el sector público como el privado, y organizaciones
reúne para monitorizar el comportamiento y Rendimiento
sin fines de lucro. Un Proveedor de Servicios de TI provee
de un Servicio de TI y realizar recomendaciones de mejora.
Servicios de TI a un Cliente que es parte del Negocio. El
Proveedor de Servicios de TI puede ser parte del mismo
Office of Government Commerce (OGC)
Negocio que el Cliente (Proveedor Interno de Servicios) o
parte de otro Negocio (Proveedor Externo de Servicios). OGC consiguió la marca ITIL (derechos de autor y marca
registrada). OGC es un departamento del Gobierno del
Nivel de Servicio Reino Unido que da soporte a la realización de la agenda
de compras del gobierno gracias a su trabajo en alianzas
Resultados medidos e informados frente a uno o más
de contratación y a sus elevados niveles de aptitudes
Objetivos de Nivel de Servicio. El término Nivel de Servicio
y habilidades de compra con distintos departamentos.
se emplea a veces para referirse a un Objetivo de Nivel de
También proporciona soporte a proyectos complejos para
Servicio.
el sector público.

Objetivo
Off-shore
El propósito o la intención definidos de un Proceso,
(Estrategia del Servicio) Provisión de Servicios desde una
una Actividad o una Organización en su totalidad.
localización externa al país del Cliente y, frecuentemente,
Los Objetivos se expresan generalmente como metas
en diferente continente. Puede tratarse de la provisión de
medibles. El término Objetivo se usa también de manera
un Servicio de TI, o de Funciones de soporte como por
informal para Requisito. Vea también Salida.
ejemplo el Centro de Servicio al Usuario.

Objetivo de la Gestión de Servicios

Opción de Recuperación
(Operación del Servicio) El tiempo que se espera que un
(Diseño del Servicio) Estrategia para responder a
Elemento de Configuración no esté disponible debido a
una interrupción del Servicio. Las Estrategias usadas
una Actividad de mantenimiento planificada.
habitualmente son No Hacer Nada, Solución Provisional
Manual, Acuerdo Recíproco, Recuperación Gradual,
Objetivo de Negocio Recuperación Intermedia, Recuperación Rápida,
(Estrategia del Servicio) El Objetivo de un Proceso de Recuperación Inmediata. Las Opciones de Recuperación
Negocio, o del Negocio como un todo. Los Objetivos de podrían hacer uso de facilidades dedicadas, o Facilidades
Negocio apoyan la Visión de Negocio, proporcionan guías de Terceros compartidas por múltiples Negocios.
para la Estrategia de TI, y normalmente reciben apoyo de
los Servicios de TI. Operación
(Operación del Servicio) Gestión del día a día de
Objetivo de Nivel de Servicio un Servicio de TI, un Sistema, u otro Elemento de
(Diseño del Servicio) (Mejora Continua del Servicio) Configuración. El término Operación se usa también para
Compromiso que está documentado en un SLA. Los referirse a una Actividad o Transacción predefinida. Por
Objetivos de Nivel de Servicio se basan en los Requisitos ejemplo, la carga de una cinta magnética, la recogida
de Nivel de Servicio y son necesarios para asegurar que el de importes en un punto de venta, o la lectura de datos
Diseño del Servicio de TI se Ajuste al Propósito del mismo. desde una unidad de disco.
Los Objetivos de Nivel de Servicio deben ser medibles y
normalmente se basan en KPIs. Operación del Servicio
(Operación del Servicio) Una fase en el Ciclo de Vida de
un Servicio de TI. La Operación del Servicio incluye varios
264 | Glosario

Procesos y Funciones y es uno de los títulos esenciales en Organización Internacional para la

las publicaciones de ITIL. Vea también Operación. Normalización (ISO)
La Organización Internacional para la Normalización (ISO)
Operaciones de Negocio es el mayor desarrollador de Estándares del mundo. ISO
(Estrategia del Servicio) La ejecución del día a día, la es una organización no gubernamental que constituye
monitorización y la gestión de los Procesos de Negocio. una red de Institutos de Estandarización nacionales de 156
países. Vea www.iso.org para disponer de más información
Operaciones de TI sobre ISO.
(Operación del Servicio) Actividades desempeñadas por
Control de Operaciones de TI, incluyendo Gestión de Outsourcing
Consolas, Planificación de Tareas, Backup y Restauración, y (Estrategia del Servicio) Uso de un Proveedor Externo de
Gestión de Salida e Impresión. Operaciones de TI se utiliza Servicios para la gestión de Servicios de TI. Vea también
también como sinónimo de Operación del Servicio. Aprovisionamiento del Servicio.

Operar Panel de Control

Obtener un rendimiento esperado. Se dice que un Proceso (Operación del Servicio) Representación gráfica de
o un Elemento de Configuración Opera, cuando está Resultados generales de Servicios de TI y Disponibilidad.
proporcionando el resultado requerido. Operar también El Panel de Control podría actualizarse en tiempo real
puede referirse a la realización de una o más Operaciones. y también puede incluirse en informes de gestión y en
Por ejemplo, Operar un PC consiste en la realización de páginas web. Los Paneles de Control puede utilizarse para
las Operaciones diarias que necesita para su rendimiento ayudar en la Gestión del Nivel de Servicio, Gestión de
correcto. Eventos o Diagnóstico de Incidencias.

Operativo Parada Planificada

El nivel inferior de los 3 niveles de la Planificación y (Diseño del Servicio) Tiempo acordado cuando un Servicio
Entrega (Estratégico, Táctico, Operativo). Las Actividades de TI no esté disponible. Parada Planificada se utiliza
Operativas incluyen la Planificación o entrega del día a día normalmente para mantenimiento, actualizaciones y
de un Proceso de Negocio o de un Proceso de Gestión prueba. Vea también Tiempo de Caída.
de los Servicios de TI. El término Operativo puede usarse
como sinónimo del término Real. Perfil de Usuario (UP)
(Estrategia del Servicio) Un patrón de demanda de los
Optimizar Usuarios para Servicios de TI. Cada Perfil de Usuario
Revisar, Planificar y solicitar Cambios para obtener la incluye uno o más Patrones de Actividad de Negocio.
máxima Eficiencia y Eficacia de un Proceso, Elemento de
Configuración, Aplicación, etc. Perspectiva de control
(Estrategia del Servicio) Un acercamiento a la gestión
Organización de Servicios de TI, Procesos, Funciones, Activos, etc.
Una compañía, entidad legal u otra institución. Como Pueden haber varias Perspectivas de Control diferentes
ejemplos de Organizaciones que no se consideran para un mismo Servicio de TI, Procesos, etc., permitiendo
empresas se pueden incluir la Organización Internacional a diferentes individuos o equipos centrarse en lo que
para la Normalización o itSMF. El término Organización se es importante y relevante para su Rol específico. Como
utiliza algunas veces para hacer referencia a una entidad ejemplos de Perspectivas de Control se pueden incluir
que tiene Personas, Recursos y Presupuestos. Por ejemplo, gestión Reactiva y Proactiva dentro de Operaciones de TI,
una Unidad de Negocio o Proyecto. o una visión de Ciclo de vida para un equipo de Proyecto
de Aplicaciones.
Organización Internacional de Normalización
Vea Organización Internacional para la Normalización Perspectiva del Negocio
(ISO). (Mejora Continua del Servicio) El entendimiento del punto
de vista del Negocio por parte del Proveedor de Servicio
 Glosario | 265

y de los Servicios de TI, y un entendimiento del Negocio Plan de Disponibilidad

desde el punto de vista del Proveedor de Servicio. (Diseño del Servicio) Plan para asegurar que se puedan
proveer de forma rentable los Requisitos de Disponibilidad
Petición de Cambio (RFC) actuales y futuros para Servicios de TI.
(Transición del Servicio) Propuesta formal para que
se realice un Cambio. Una RFC incluye detalles del Planificación
Cambio propuesto, y puede registrarse en papel o Una Actividad responsable de la creación de uno o más
electrónicamente. El término RFC se suele confundir con Planes. Por ejemplo, Planificación de la Capacidad.
Registro de Cambio, o con el Cambio en sí.
Planificación de Cambios
Petición de Servicio
(Transición del Servicio) Documento que enumera
(Operación del Servicio) Petición que hace un Usuario todos los Cambios aprobados y su fecha prevista de
solicitando información, asesoramiento, un Cambio implementación. Una Planificación de Cambios también
Estándar o Acceso a un Servicio de TI. Por ejemplo, la se conoce como Lista de Cambios Planificados, incluso
inicialización de una clave, o proporcionar a un nuevo puede contener información sobre Cambios que ya se han
Usuario Servicios de TI estándares. Las Peticiones de implementado.
Servicio se gestionan normalmente mediante un Centro de
Servicio al Usuario, y no requieren que se realice una RFC. Planificación de la Capacidad
(Diseño del Servicio) Actividad del proceso de Gestión
Piloto
de Capacidad responsable de la creación de un Plan de
(Transición del Servicio) Despliegue limitado de un Capacidad.
Servicio de TI, una Versión o un Proceso en el Entorno de
Producción. Un piloto se usa para reducir el Riesgo y para Planificación de Trabajos
obtener retroalimentación del Usuario y la Aceptación. Vea
(Operación del Servicio) Planificación y gestión de la
también Prueba, Evaluación.
ejecución de las tareas del software que se requieren
como parte de un Servicio de TI. La Planificación de
Plan
Trabajos se realiza mediante Gestión de Operaciones de
Propuesta detallada que describe las Actividades y TI, y con frecuencia se automatiza usando herramientas
Recursos necesarios para la consecución de un Objetivo. de software que realizan tareas por lotes u online en
Por ejemplo, el Plan para implementar un nuevo Proceso momentos específicos del día, semana, mes o año.
o Servicio de TI. ISO/IEC 20000 requiere un Plan como
parte de la gestión de cada Proceso de Gestión de los Planificar-Hacer-Verificar-Actuar
Servicios de TI.
(Mejora Continua del Servicio) Ciclo de gestión de
Procesos en cuatro etapas, y atribuido a Edward Deming.
Plan de Capacidad
Plan-Do-Check-Act es también conocido como el Ciclo de
(Diseño del Servicio) Plan de Capacidad que se utiliza Deming.
para gestionar los Recursos requeridos para entregar
Servicios de TI. El Plan contiene escenarios para diferentes PLAN (planificar): Diseñar o revisar Procesos que soportan
predicciones de demanda de Negocio, y las opciones Servicios de TI.
valoradas para proveer los Objetivos de Nivel de Servicio. DO (hacer): Implementación del Plan y gestión de los
Procesos.
Plan de Continuidad de los Servicios de TI
CHECK (verificar): Medición de los Procesos y los Servicios
(Diseño del Servicio) Plan que define los pasos requeridos
de TI, comparación con los Objetivos marcados y
para Recuperar uno o más Servicios de TI. El Plan también
generación de informes.
identificará los disparadores para la Invocación, personas
a involucrar, comunicaciones, etc. El Plan de Continuidad ACT (actuar): Planificación e implementación de Cambios
de los Servicios de TI deberá formar parte de un Plan de para la mejora de los Procesos.
Continuidad del Negocio.
Política
Documento formal que contiene las intenciones y
expectativas de gestión. Las Políticas se utilizan para dirigir
266 | Glosario

las decisiones, y asegurar un desarrollo e implementación Primera línea de soporte

coherente y apropiado de los Procesos, Estándares, Roles, (Operación del Servicio) El primer nivel en una jerarquía
Actividades, Infraestructura de TI, etc. de los Grupos de Soporte implicados en la resolución
de Incidencias. Cada nivel contiene más habilidades
Política de Seguridad especialistas, o tienen más tiempo u otros recursos. Vea
Vea Política de Seguridad de la Información. también Escalado.

Política de Seguridad de la Información PRINCE2

(Diseño del Servicio) La Política que gobierna un método Metodología de Gestión de Proyectos estándar del
de la Organización para Gestión de la Seguridad de la gobierno del Reino Unido. Vea www.ogc.gov.uk/prince2
Información. para disponer de más información.

Porfolio de Aplicaciones Prioridad

(Diseño del Servicio) Una base de datos o Documento (Transición del Servicio) (Operación del Servicio) Categoría
estructurado que se usa para gestionar Aplicaciones en empleada para identificar la importancia relativa de una
su Ciclo de Vida. El Porfolio de Aplicaciones contiene Incidencia, Problema o Cambio. La Prioridad se basa en
Atributos que son clave para todas las Aplicaciones. el Impacto y la Urgencia, y se utiliza para identificar los
Algunas veces el Porfolio de Aplicaciones se implementa plazos requeridos para la realización de las diferentes
como parte del Porfolio de Servicios, o como parte del acciones. Por ejemplo, el SLA podría indicar que las
Sistema de Gestión de la Configuración. Incidencias de Prioridad 2 deben resolverse en menos de
12 horas.
Porfolio de Servicios
(Estrategia del Servicio) Conjunto de todos los Servicios Problema
que son gestionados por un Proveedor de Servicios. El (Operación del Servicio) Causa de una o más Incidencias.
Porfolio de Servicios se emplea para gestionar el Ciclo En el momento en el que se crea el Registro de
de Vida completo de todos los Servicios, e incluye tres Problemas, no es frecuente conocer su causa, por lo que
Categorías: Flujo de Creación de Servicios (propuestos o es necesario realizar su investigación mediante el Proceso
en Desarrollo); Catálogo de Servicios (Reales o disponibles de Gestión de Problemas.
para su Despliegue); y Servicios Retirados. Vea también
Gestión de la Cartera de Servicios. Procedimiento
Documento que contiene los pasos que se deben seguir
Práctica para la realización de una determinada Actividad. Los
Se trata de un método de trabajo o forma en la que Procedimientos se definen como partes de Procesos. Vea
debería realizarse el trabajo. Las Prácticas pueden incluir también Instrucción de Trabajo.
Actividades, Procesos, Funciones, Estándares y Directrices.
Vea también Mejor Práctica. Procedimientos de Operación Estándar (SOP)
(Operación del Servicio) Procedimientos usados por
Presupuestar Gestión de Operaciones de TI.
La Actividad para predecir y controlar el gasto de dinero.
Es un ciclo de negociaciones periódicas para establecer Proceso
futuros Presupuestos (normalmente en periodos anuales) y Conjunto estructurado de Actividades diseñado para la
la monitorización y ajuste diario del Presupuesto actual. consecución de un Objetivo determinado. Los Procesos
requieren una o más entradas y producen una serie de
Presupuesto salidas, ambas previamente definidas. Un Proceso suele
Lista de todo el dinero que una Organización o una incorporar la definición de los Roles que intervienen, las
Unidad de Negocio ha planificado recibir y pagar en un responsabilidades, herramientas y Controles de gestión
periodo de tiempo específico. Vea también Presupuestar, necesarios para obtener las salidas de forma eficaz. El
Planificación. Proceso podrá definir las Políticas, Estándares, Directrices,
Actividades, y las Instrucciones de Trabajo que sean
necesarias.
 Glosario | 267

Proceso de Entrega Proveedor Externo de Servicios

El nombre usado por ISO/IEC 20000 para el grupo de (Estrategia del Servicio) Un Proveedor de Servicios de TI
Procesos que incluye Gestión de la Entrega. Este grupo no que forma parte de una Organización diferente a la de
incluye ningún otro Proceso. su Cliente. Un Proveedor de Servicios de TI puede tener
Clientes Internos o Externos.
Proceso de Entrega también se utiliza como sinónimo de
Proceso de Gestión de la Entrega.
Proveedor Interno de Servicios
Proceso de Negocio (Estrategia del Servicio) Proveedor de Servicios de TI que
forma parte de la misma Organización que su Cliente. Un
Un Proceso que pertenece y que lo lleva a cabo el
Proveedor de Servicios de TI puede tener Clientes Internos
Negocio. Un Proceso de Negocio contribuye a la entrega
o Externos.
de un producto o Servicio para un Cliente de Negocio.
Por ejemplo, un revendedor podría tener un Proceso de
compra que ayudara a entregar Servicios a sus Clientes
Proyecto
de Negocio. Muchos de los Procesos de Negocio están Se trata de una Organización temporal, compuesta por
basados en Servicios de TI. personal y por los Activos requeridos para la obtención de
los Objetivos y Salidas necesarios. Cada Proyecto tiene un
Producto Software Empaquetado (COTS) Ciclo de Vida que típicamente incluye inicio, Planificación,
ejecución, Cierre, etc. Los Proyectos se gestionan
(Diseño del Servicio) Software de aplicación o Middleware
habitualmente mediante metodologías formales, como
que se puede comprar de un Tercero.
puede ser PRINCE2.
Programa
Prueba
Conjunto de Proyectos y Actividades planificadas y
(Transición del Servicio) Una Actividad que verifica que un
gestionadas como una unidad para la obtención de unos
Elemento de Configuración, Servicio de TI, Proceso, etc.
Objetivos y Salidas comunes.
cumple con sus Especificaciones o Requisitos acordados.
Programa de Mejora de Servicio (SIP)
Puente de Operaciones
(Mejora Continua del Servicio) Un Plan formal para
(Operación del Servicio) Ubicación física donde se
implementar mejoras en un Proceso o Servicio de TI.
monitorizan y gestionan Servicios de TI y la Infraestructura
de TI.
Propietario del Proceso
Es el Rol responsable de asegurar que un Proceso Coincide Puesta en Producción
con su Propósito. Las responsabilidades del Propietario del
(Transición del Servicio) La Actividad responsable del
Proceso cubren el patrocinio, Diseño, Gestión de Cambios
traslado de hardware, software, documentación, Procesos,
y mejora continua del Proceso y sus Métricas. Este Rol
etc, nuevos o modificados, al Entorno de Producción.
se asigna comúnmente a la persona que desempeña
Despliegue es parte del Proceso de Gestión de Versiones y
también el Rol de Gestor del Proceso, aunque en grandes
Despliegues. Vea también Despliegue.
Organizaciones, ambos Roles pueden estar separados.

Proveedor de Servicio Punto Objetivo de Recuperación (RPO)

(Operación del Servicio) La cantidad máxima de datos que
(Estrategia del Servicio) Organización que presta Servicios
podría perderse cuando el Servicio se Restaura después
a uno o más Clientes Internos o Externos. El término
de una interrupción. El Punto Objetivo de Recuperación
de Proveedor de Servicio se usa a menudo como forma
se expresa como un espacio de tiempo antes del Fallo.
abreviada de Proveedor de Servicios de TI.
Por ejemplo, un Punto Objetivo de Recuperación de un
día podría estar apoyado por Backups diarios, y se podrían
Proveedor de Servicio de Internet (ISP)
perder hasta 24 horas de datos. Los Puntos Objetivos de
Un Suministrador Externo de Servicios que proporciona Recuperación para cada Servicio de TI deberán negociarse,
acceso a Internet. La mayoría de los ISP también acordarse y documentarse, y usarse como requisitos
proporcionan otros Servicios de TI como por ejemplo para Diseño del Servicio y Planes de Continuidad de los
alojamiento web. Servicios de TI.
268 | Glosario

Punto Único de Contacto Recurso

(Operación del Servicio) Proporcionar un único y (Estrategia del Servicio) Término genérico que incluye
consistente modo de comunicarse con una Organización Infraestructura de TI, personal, dinero o cualquier otra
o Unidad de Negocio. Por ejemplo, Un SPOC para un cosa que pueda ayudar a entregar un Servicio de TI.
Proveedor de Servicios de TI se denomina normalmente A los Recursos se les considera como el Activo de una
Centro de Servicio al Usuario. Organización. Vea también Habilidad, Activo del Servicio.

Punto Único de Fallo (SPOF) Red de Valor

(Diseño del Servicio) Cualquier Elemento de Configuración (Estrategia del Servicio) Un complejo conjunto de
que puede provocar una Incidencia cuando falla y para el relaciones entre dos o más grupos u Organizaciones.
que no se ha implementado una Contramedida. Un SPOF El valor es generado a través del intercambio de
puede ser tanto una persona, un paso en un Proceso o conocimiento, información, bienes o Servicios. Vea
Actividad como un Componente de la Infraestructura de también Asociación.
TI. Vea también Fallo.
Redundancia
Real Vea Tolerancia a Fallos.
(Transición del Servicio) Hace referencia a un Servicio de
El término Redundante también tiene un significado de
TI o Elemento de Configuración que se está usando para
obsoleto, o de que ya no es necesario.
entregar un Servicio a un Cliente.
Registro
Recuperación
Un Documento que contiene el resultado u otro tipo de
(Diseño del Servicio) (Operación del Servicio) Recuperar
salida desde un Proceso o Actividad. Los registros son
un Elemento de Configuración o un Servicio de TI hasta
la evidencia de que una Actividad tuvo lugar, y podría
el estado de funcionamiento. Recuperar un Servicio de
estar en papel o en formato electrónico. Por ejemplo, un
TI incluye normalmente la recuperación de datos para
informe de Auditoría, un Registro de la Incidencia, o los
llegar un estado consistente. Después de la recuperación
minutos de una reunión.
podrían ser necesarios otros pasos antes de que los
Servicios de TI puedan estar disponibles para los Usuarios
Registro de Activos
(Restauración).
(Transición del Servicio) Una lista de Activos que incluye
Recuperación Inmediata propietario y valor. Gestión de Activos mantiene el
Registro de Activos.
(Diseño del Servicio) Una Opción de Recuperación que
es también conocida como Recuperación Inmediata.
Registro de Cambio
Se realiza la provisión para Recuperar el Servicio de
TI sin pérdida de Servicio. La Recuperación Inmediata (Transición del Servicio) Registro que contiene los detalles
normalmente usa tecnologías de Duplicación, Equilibrio de de un Cambio. Cada Registro de Cambio documenta el
Carga y Ubicación Dividida. Ciclo de Vida de un sólo Cambio. Un Registro de Cambio
se crea para cada Solicitud de Cambio que se reciba,
Recuperación Intermedia incluso para aquellas que se rechacen posteriormente.
Los Registros de Cambios deberían hacer referencia a los
(Diseño del Servicio) Una Opción de Recuperación que
Elementos de Configuración que se ven afectados por el
es también conocida como Recuperación Intermedia.
Cambio. Los Registros de Cambios se almacenan en el
Se realiza la provisión para la Recuperación del Servicio
Sistema de Gestión de la Configuración.
de TI en un período de tiempo entre 24 y 72 horas.
Recuperación Intermedia utiliza típicamente una
Registro de Errores Conocidos
Facilidad Fija o Portátil compartida que tiene Sistemas
de Ordenador y Componentes de Red. El hardware y (Operación del Servicio) Registro que contiene los detalles
software necesitarán configurarse, y los datos necesitarán de un Error Conocido. Cada Registro de Errores Conocidos
almacenarse, como parte del Plan de Continuidad de los documenta el Ciclo de Vida de un Error Conocido,
Servicios de TI. incluyendo el Estado, Causa Raíz, y Solución Provisional.
En algunas implementaciones, un Error Conocido se
 Glosario | 269

documenta usando campos adicionales en un Registro de Requisito

Problemas. (Diseño del Servicio) Una declaración formal de lo que se
necesita. Por ejemplo: un Requisito de Nivel de Servicio,
Registro de la Incidencia un Requisito de Proyecto, o los Entregables requeridos
(Operación del Servicio) Registro que contiene los para un Proceso. Vea también Declaración de Requisitos.
detalles de una Incidencia. Cada Registro de la Incidencia
documenta el Ciclo de Vida de una sola Incidencia. Requisito de Nivel de Servicio (SLR)
(Diseño del Servicio) (Mejora Continua del Servicio)
Registro de la Versión Requisito del Cliente para un aspecto de un Servicio de TI.
(Transición del Servicio) Registro en la CMDB que define el Los SLR se basan en Objetivos de Negocio y se usan para
contenido de una Versión. Un Registro de la Versión tiene negociar los Objetivos de Nivel de Servicio acordados.
Relación con todos los Elementos de Configuración que se
ven afectados por la Versión. Resolución
(Operación del Servicio) Acción tomada para reparar
Registro de Problemas la Causa Raíz de una Incidencia o Problema o para
(Operación del Servicio) Registro que contiene los detalles implementar una Alternativa. En ISO/IEC 20000, el Proceso
de un Problema. Cada Registro de Problemas documenta de Resolución es el grupo de Procesos que incluye la
el Ciclo de Vida de un sólo Problema. Gestión de Problemas e Incidencias.

Relación Respuesta Interactiva de Voz (IVR)

Conexión o interacción entre dos personas o cosas. (Operación del Servicio) Una forma de Distribución
En la Gestión de las Relaciones con el Negocio es la Automática de Llamadas que acepta entradas del Usuario,
interacción entre el Proveedor de Servicios de TI y el tales como presionar una tecla o instrucciones vocales,
Negocio. En la Gestión de la Configuración es el enlace para identificar el destinatario correcto de Llamadas
entre dos Elementos de Configuración que identifican entrantes.
una dependencia o conexión entre ellos. Por ejemplo,
las Aplicaciones se pueden vincular con los Servidores Restauración
sobre los que se ejecutan, los Servicios de TI pueden tener (Operación del Servicio) Acción para restaurar un Servicio
muchos enlaces a todos los CI que contribuyen a ese de TI para los Usuarios tras Reparar y Recuperarse de una
Servicio de TI. Incidencia. Este es el Objetivo Principal de la Gestión de
Incidencias.
Rendimiento
(Diseño del Servicio) Una medida del número de Restauración del Servicio
Transacciones u otras Operaciones realizadas en un tiempo Vea Restaurar.
fijo. Por ejemplo 5000 correos electrónicos enviados por
hora, o 200 E/S de disco por segundo. Retirar
(Transición del Servicio) Eliminación permanente de un
Rendimiento
Servicio de TI u otro Elemento de Configuración del
Medida de la respuesta obtenida por un Sistema, persona, Entorno de Producción. La Retirada es una etapa en el
equipo, Proceso, o Servicio de TI. Ciclo de Vida de muchos Elementos de Configuración.

Rentabilidad Retroceder
Una medida del equilibrio entre la Eficacia y el Coste de Vea Corrección.
un Servicio, Proceso o actividad. Un Proceso Rentable es
aquel proceso que alcanza su Objetivo al mínimo Coste. Revisión
Vea también KPI, Valor Obtenido por el Dinero.
La evaluación de un Cambio, Problema, Proceso, Proyecto,
etc. Las Revisiones habitualmente se llevan a cabo en
Reparación
puntos predefinidos en el Ciclo de Vida, y especialmente
(Operación del Servicio) La sustitución o corrección de un tras el Cierre. El propósito de una Revisión es asegurarse
Elemento de Configuración fallido.
270 | Glosario

de que se han suministrado todos los Entregables, e Servicio de Directorio

identificar oportunidades de mejora. (Operación del Servicio) Aplicación que gestiona
información de la Infraestructura de TI disponible en una
Riesgo red, y los Usuarios y Derechos de acceso relacionados.
Un posible Evento que podría causar daño o pérdida,
o afectar a la capacidad de alcanzar Objetivos. Un Servicio de Negocio
Riesgo se mide por la probabilidad de una Amenaza, la Servicio de TI que sustenta directamente un Proceso de
Vulnerabilidad del Activo a esa Amenaza, y por el Impacto Negocio, en contraposición a un Servicio de Infraestructura
que tendría en caso de producirse. que el Proveedor de Servicios de TI usa internamente y
que normalmente no tiene visibilidad hacía el Negocio. El
Rol término Servicio de Negocio también se usa para definir
Conjunto de responsabilidades, Actividades y un Servicio que se provee a Clientes de Negocio a través
autorizaciones concedidas a una persona o equipo. Un de Unidades de Negocio. Por ejemplo, la provisión de
Rol se define en un Proceso. Una persona o equipo puede servicios financieros a Clientes de un banco, o la provisión
tener múltiples Roles, por ejemplo, una misma persona de bienes a Clientes en una tienda de venta al por menor.
y de manera individual puede llevar a cabo los Roles de La provisión exitosa de Servicios de Negocio a menudo
Gestor de la Configuración y Gestor de Cambios. depende de uno o más Servicios de TI.

Salida Servicio de TI
Es el resultado de la realización de una Actividad, el Servicio que un Proveedor de Servicios de TI proporciona a
seguimiento de un Proceso, la entrega de un Servicio de uno o más Clientes. Un Servicio de TI se basa en el uso de
TI, etc. El término Salida se emplea para referirse a los las Tecnologías de la Información y soporta los Procesos
resultados esperados, al igual que a los resultados reales. de Negocio del Cliente. Un Servicio de TI se compone de
Vea también Objetivo. una combinación de personas, Procesos y tecnología y
debería estar definido en un Acuerdo de Nivel de Servicio.
Script de Diagnóstico
(Operación del Servicio) Conjunto estructurado de Servidor
preguntas usadas por el personal del Centro de Servio al (Operación del Servicio) PC que está conectado a la red y
Usuario para asegurarse que responden a las preguntas que provee Funciones de software que usan otros PC.
correctas, y para ayudarles a Clasificar, Resolver y asignar
Incidencias. Los Scripts de Diagnóstico también podrían Sistema
estar disponibles para ayudar a lo Usuarios a diagnosticar Número de cosas relacionadas que trabajan juntas para
y resolver sus propias incidencias. conseguir un Objetivo común. Por ejemplo:

Segunda Línea de Soporte ■■ Un Sistema Informático completo, incluyendo

hardware, software y Aplicaciones
(Operación del Servicio) El segundo nivel en una jerarquía
■■ Un sistema de Gestión, incluyendo múltiples Procesos
de los Grupos de Soporte implicados en la resolución
de Incidencias y en la investigación de Problemas. Cada que se planifican y gestionan juntos. Por ejemplo, un
nivel contiene más habilidades especialistas, o tienen más Sistema de Gestión de la Calidad
tiempo u otros recursos. ■■ Un Sistema de Gestión de Bases de Datos o un
Sistema Operativo que incluye muchos módulos de
Seguridad software que se diseñan para realizar un conjunto de
Funciones relacionadas.
Vea Gestión de la Seguridad de la Información.
Sistema de Gestión
Servicio
Marco de trabajo de Políticas, Procesos y Funciones
Un medio de entregar valor a los clientes facilitando
que asegura que una Organización puede alcanzar sus
resultados que los clientes quieren lograr sin la propiedad
Objetivos.
de Costes y Riesgos específicos.
 Glosario | 271

Sistema de Gestión de Calidad (QMS) podría revisar los KPI, Niveles de Servicio y Umbrales de
(Mejora Continua del Servicio) Conjunto de Procesos Monitorización, y proporcionar Recursos adicionales para
responsables de asegurar que el trabajo será realizado por Gestión de Incidencias y Problemas.
una Organización con la Calidad necesaria para satisfacer
las necesidades de los Objetivos de Negocio o Niveles de Soporte siguiendo al Sol
Servicio. Vea también ISO 9000. (Operación del Servicio) Una metodología para el uso del
Centro de Servio al Usuario y de los Grupos de Soporte
Sistema de Gestión de la Configuración alrededor del Mundo para proporcionar Servicio 24/7. Las
(CMS) Llamadas, Incidencias, Problemas y Peticiones de Servicio
son pasadas entre grupos en diferentes husos horarios.
(Transición del Servicio) Conjunto de herramientas y bases
de datos usadas para gestionar los datos de Configuración
de un Proveedor de Servicios de TI. El CMS también
Soporte Técnico
incluye información sobre Incidencias, Problemas, Errores Vea Gestión Técnica.
Conocidos, Cambios y Versiones; y puede contener
datos sobre empleados, Proveedores, ubicaciones, Standby
Unidades de Negocio, Clientes y Usuarios. El CMS consta (Diseño del Servicio) Empleado para referirse a Recursos
de herramientas para recopilar, almacenar, gestionar, que no son necesarios para entregar los Servicios de TI
actualizar, y mostrar datos sobre todos los Elementos de reales, pero que están disponibles para soportar los Planes
Configuración y sus Relaciones. El CMS se mantiene a de Continuidad de Servicio de TI. Por ejemplo un Centro
través de Gestión de la Configuración y lo usan todos los de datos de Reserva puede mantenerse para dar soporte a
Procesos de Gestión de los Servicios de TI. Vea también acuerdos de Sobreavisos Calientes, Medios o Fríos.
Base de Datos de Gestión de la Configuración, Sistema de
Gestión del Conocimiento del Servicio. Suministrador
(Estrategia del Servicio) (Diseño del Servicio) Tercero
Sistema de Gestión del Conocimiento del responsable de suministrar bienes o Servicios que son
Servicio (SKMS) necesarios para proporcionar Servicios de TI. Ejemplos de
(Transición del Servicio) Conjunto de herramientas y bases suministradores incluyen los vendedores de hardware y
de datos que se emplean para gestionar el conocimiento software, proveedores de redes y telecomunicaciones y
y la información. El SKMS incluye tanto el Sistema de Organizaciones de Outsourcing. Vea también Contrato de
Gestión de la Configuración como otras herramientas y Soporte, Cadena de Suministro.
bases de datos. El SKMS almacena, gestiona, actualiza
y presenta toda la información que un Proveedor de Super Usuario
Servicios de TI necesita para gestionar todo el Ciclo de (Operación del Servicio) Un Usuario que ayuda a otros
Vida de los Servicios de TI. Usuarios, y ayuda en la comunicación con el Centro
de Servicio al Usuario o con otras partes del Proveedor
Solución Provisional de Servicios de TI. Los Super Usuarios normalmente
(Operación del Servicio) Reducción o eliminación del proporcionan soporte para Incidencias menores y para la
Impacto de una Incidencia o Problema para el que todavía formación.
no está disponible una Resolución completa. Por ejemplo,
reinicio de un Elemento de Configuración fallido. Las Táctico
Soluciones Provisionales para Problemas se documentan El nivel medio de los 3 niveles de la Planificación y
en los Registros de Errores Conocidos. Las Soluciones Entrega (Estratégico, Táctico, Operativo). Las Actividades
Provisionales para Incidencias que no tienen asociados Tácticas incluyen los Planes a medio plazo requeridos para
Registros de Problemas se documentan en el Registro de alcanzar Objetivos específicos, típicamente a lo largo de
Incidencias. un periodo de semanas o meses.

Soporte Post-Implantación Tecnologías de la Información (TI)

(Transición del Servicio) Soporte proporcionado para un Uso de la tecnología para el almacenamiento,
Servicio de TI nuevo o modificado durante un periodo de comunicación o procesado de información. La tecnología
tiempo después de que se Entregue. Durante el Soporte incluye típicamente ordenadores, telecomunicaciones,
Post-Implementación, el Proveedor de Servicios de TI
272 | Glosario

Aplicaciones y otro software. La información puede Tiempo Medio de Restauración del Servicio
incluir datos de Negocio, voz, imágenes, video, etc. Las (MTRS)
Tecnologías de la Información (TI) se utilizan a menudo
Tiempo medio dedicado a restaurar un Elemento de
para apoyar los Procesos de Negocio a través de Servicios
Configuración o Servicio de TI tras un Fallo. MTTS se
de TI.
mide desde que el CI o Servicio de TI falla hasta que está
completamente Restaurado y dando su funcionalidad
Tercera Línea de Soporte normal. Vea también Tiempo Medio de Reparación.
(Operación del Servicio) El tercer nivel en una jerarquía
de los Grupos de Soporte implicados en la resolución Tiempo Medio Entre Fallos (MTBF)
de Incidencias y en la investigación de Problemas. Cada
(Diseño del Servicio) Métrica para medir e informar de la
nivel contiene más habilidades especialistas, o tienen más
Fiabilidad. MTBF es el tiempo medio que un Elemento de
tiempo u otros recursos.
Configuración o Servicio de TI puede realizar su Función
concertada sin interrupción.. Se mide desde que el CI
Tercero(s) o Servicio de TI empieza a funcionar, hasta que falla la
Una persona, grupo, o Negocio que no es parte del siguiente vez.
Acuerdo de Nivel de Servicio para un Servicio de TI, pero
que es necesaria para asegurar el éxito de la entrega de Tiempo Objetivo de Recuperación (RTO)
ese Servicio de TI. Por ejemplo, un Proveedor de software,
(Operación del Servicio) El tiempo máximo permitido
una empresa de mantenimiento de hardware, o el
para la recuperación de un Servicio de TI después de una
departamento de ... Los requisitos para los Terceros están
interrupción. El Nivel de Servicio a proporcionar podría ser
normalmente especificados en Contratos de Soporte o
menor que los Objetivos de Nivel de Servicio. El Tiempo
Acuerdos de Nivel Operativo.
Objetivo de Recuperación para cada Servicio de TI deberá
negociarse, acordarse y documentarse. Vea también
Tiempo de Caída Análisis de Impacto en el Negocio.
(Diseño del Servicio) (Operación del Servicio) El tiempo
en el que un Elemento de Configuración o un Servicio Tipo de Llamada
de TI no está Disponible durante un Tiempo Acordado
(Operación del Servicio) Una categoría que se utiliza para
de Servicio. La Disponibilidad de un Servicio de TI
distinguir peticiones entrantes en un Centro de Servicio
normalmente se calcula a partir del Tiempo Acordado de
al Usuario. Habitualmente, los tipos de llamadas son
Servicio y del Tiempo de Caída.
Incidencia, Petición de Servicio y Reclamación.

Tiempo de Respuesta
Tolerancia a Fallos
Una medida del tiempo para completar una Operación
(Diseño del Servicio) Habilidad de un Servicio de TI
o Transacción. Usado en la Gestión de Capacidad como
ó Elemento de Configuración para continuar con su
medida del Rendimiento de la Infraestructura de TI, y en
Operación correcta tras el Fallo de un Componente. Vea
la Gestión de Incidencias como una medida del tiempo
también Capacidad de Recuperación, Contramedida.
consumido para contestar una llamada, o iniciar el
Diagnóstico.
Tormenta de ideas
Tiempo Medio de Reparación (MTTR) (Operación del Servicio) Una técnica que ayuda a un
equipo a generar ideas. Las ideas no se revisan durante
Tiempo medio dedicado a reparar un Elemento de
la sesión de Tormenta de ideas, pero sí en una etapa
Configuración o Servicio de TI tras un Fallo. MTTR se
posterior. Gestión de Problemas utiliza normalmente
mide desde que el CI o Servicio de TI falla hasta que
Tormenta de ideas para identificar causas posibles.
es reparado. MTTR no incluye el tiempo necesario para
Recuperar o Restaurar. MTTR se emplea algunas veces
Trabajo en Progreso (WIP)
de forma incorrecta para querer decir Tiempo Medio de
Restauración del Servicio. Un Estado que significa que las Actividades se han
iniciado pero que todavía no se han completado. Se
utiliza habitualmente como un Estado para Incidencias,
Problemas, Cambios, etc.
 Glosario | 273

Transacción Usabilidad
Una Función discreta realizada por un Servicio de TI. (Diseño del Servicio) La facilidad mediante la cual una
Por ejemplo, transferir dinero de una cuenta bancaria a Aplicación, producto o Servicio de TI puede usarse. Los
otra. Un transacción simple puede involucrar numerosas Requisitos de Usabilidad se incluyen a menudo en una
adiciones, borrados y modificaciones de datos. Ya se Declaración de Requerimientos.
completen todas con éxito o ninguna se lleve a cabo.
Usuario
Transición Una persona que usa el Servicio de TI diariamente. Los
(Transición del Servicio) Un cambio de estado, usuarios son distintos a los Clientes, dado que algunos
correspondiente al movimiento de un Servicio de TI u otro Clientes no usan el Servicio de TI directamente.
Elemento de Configuración de un estado de su Ciclo de
Vida a otro. Utilidad
(Estrategia del Servicio) Funcionalidad ofrecida por
Transición del Servicio un Producto o Servicio para satisfacer una necesidad
(Transición del Servicio) Una fase en el Ciclo de Vida específica. La utilidad a menudo se resume en “lo que
de un Servicio de TI. Transición del Servicio incluye hace”.
varios Procesos y Funciones y es el título de una de las
publicaciones esenciales de ITIL. Vea también Transición. Validación
(Transición del Servicio) Una Actividad que asegura que
Turno un Servicio de TI, Proceso, Plan u otro Entregable nuevo
(Operación del Servicio) Un grupo o equipo de personas o cambiado satisface las necesidades del Negocio. La
que realizan un Rol específico durante un periodo de Validación asegura que se satisfacen los Requisitos de
tiempo fijado. Por ejemplo, podrían haber cuatro turnos Negocio incluso aunque éstos se combinen desde su
del personal de Control de Operaciones de TI para dar diseño original. Vea también Verificación, Aceptación,
soporte a un Servicio de TI que se usa las 24 horas al día. Cualificación.

Umbral Valor Obtenido por el Dinero

El valor de una Métrica que debe provocar la generación Una medida informal de la Rentabilidad. Valor Obtenido
de una Alerta, o que se tome una acción de gestión. Por por el Dinero se basa a menudo en la comparación con
ejemplo, “una incidencia de prioridad 1 no resuelta en 4 el Coste de las alternativas. Vea también Análisis Coste-
horas”, “más de 5 errores leves de disco en una hora”, o Beneficio.
“más de 10 cambios fallidos en un mes”.
Varianza
Unidad de Negocio La diferencia entre un valor previsto y el valor real medido.
(Estrategia del Servicio) Segmento del Negocio que tiene Se usa comúnmente en Gestión Financiera, Gestión de
sus propios Planes, Métricas, ingresos y Costes. Cada Capacidad y Gestión del Nivel de Servicio, pero puede
Unidad de Negocio posee Activos y los usa para crear aplicarse en cualquier área donde se empleen Planes.
valor para sus Clientes en forma de bienes y Servicios.
Verificación
Urgencia (Transición del Servicio) Una Actividad que asegura que
(Transición del Servicio) (Diseño del Servicio) Una medida un Servicio de TI, Proceso, Plan u otro Entregable nuevo
del tiempo en el que una Incidencia, Problema o Cambio o modificado, sea completo, preciso, Fiable y esté de
tendrá un Impacto significativo para el Negocio. Por acuerdo con su especificación de diseño. Vea también
ejemplo, una Incidencia de alto Impacto puede tener una Validación, Aceptación.
Urgencia baja si el Impacto no afectara al Negocio hasta
el final del año fiscal. El Impacto y la Urgencia se emplean Versión
para asignar la Prioridad. (Transición del Servicio) Una Versión se usa para
identificar una Línea de Referencia específica o un
Elemento de Configuración. Las Versiones emplean
normalmente una convención de identificación que
274 | Glosario

posibilita identificar la secuencia o fecha de cada Línea de

Referencia. Por ejemplo Aplicación de Nóminas Versión 3
contiene funcionalidades actualizadas de la Versión 2.

Visión
Una descripción de lo que la Organización intenta ser en
el futuro. El Equipo Directivo creará una Visión y se usará
para influir en la Cultura y en la Planificación Estratégica.

Vuelta atrás
(Transición del Servicio) Recuperación de un estado
conocido después del fallo de una Versión o Cambio.
Index
 Index | 277

Index
Capacidad, 226 identidad, Gestión de la Información, 71-72
Capacidad, 227 problemas de comunicación, 197, 197 (Tab)
CAPEX (Coste de Capital), 227 CMDB (Base de Datos de Gestión de la Configuración), 229
Carga de Trabajo, 250 CMMI (Integración del Modelo de Madurez de la
Caso de Negocio, 225 Capacidad®), 184
Casos de Uso, 139, 249 CMS vea Sistema de Gestión de la Configuración (CMS)
Catálogo de Servicios, 138, 244 COBIT (Objetivos de Control para la Información y
Categorías, 227 Tecnología asociada), 87, 183, 228
Causa Raíz, 243 Comité de Cambios (CAB), 227
Centro de Atención al Usuario, 233 Comité de Cambios de Emergencia (ECAB), 232
Centro de Llamadas, 226 Componente, 228
Centro de Servicio al Usuario Centralizado, 111, 112 (Fig) comunicación, 29-31, 103, 187-197
Centro de Servicio al Usuario Local, 111, 111 (Fig) asociadas con excepciones, 195, 195 (Tab)
Centro de Servicio al Usuario, 15, 77, 87, 109-121 asociado con el cambio, 194, 194 (Tab)
definición, 109-110, 244 asociado con el proyecto, 192, 192 (Tab), 193 (Tab)
dotación de personal, 114-117 con usuarios/clientes, 197, 197 (Tab)
formación, 116 emergencias, 196, 196 (Tab)
niveles de habilidades, 114-115 entre turnos, 188
problemas de retención, 116 Externalización del Centro de Servicio al Usuario,
Super Usuarios, 116-117 120-121
entorno, 113-114 informes de rendimiento, 189-191, 189 (Tab), 190
externalización, 119-121 (Tab), 191 (Tab)
problemas de comunicación, 120-121 logro de equilibrio, 22
funciones, 108, 109-110 operativa rutinaria, 187
métricas, 117-118, 118 (Tab) reuniones, 30-31
objetivos, 110-111 Concurrencia, 229
organización, 111-114 Confidencialidad, 229
roles y responsabilidades, 140-141, 143, 145-146 conflicto de roles, 20
Virtual, 111-113, 112 (Fig) Conformidad, 228
Centro de Servicio Virtual, 111-113, 112 (Fig) conocimiento propietario, 4-5
Cerrado, 228 consideraciones tecnológicas, 14, 157-161
Certificación, 227 cuadros de mando, 158
CFIA (Análisis de Impacto de Fallos de Componentes), 228 Despliegue, 157, 167, 168
CI (Elemento de Configuración), 229 estabilidad y capacidad de respuesta, 23 (Tab)
Ciclo de Vida Gestión de Eventos, 158
definición, 237 Gestión de Incidencias, 159
Gestión de Aplicaciones, 130-133, 130 (Fig) Gestión de Licencias, 157
Gestión del Servicio (vea Gestión del Ciclo de Vida del Gestión de Peticiones, 159
Servicio) Gestión de Problemas, 159-160
Cierre, 53, 64, 228 logro de equilibrio, 22
Clasificación, definición, 228 planificación e implementación, 166-168
Cliente de Negocio, 225 Sistema de Gestión de la Configuración, 157
Cliente Externo, 232 construir, definición, 225
Cliente vea también la definición de clientes/usuarios, 228 Contabilidad de costes, 223
clientes/usuarios vea también interesados Continuidad de los Servicios de TI, 16, 35, 161
definición, 230, 249 Interfaces inter proceso entre entradas y salidas de la
experiencia Gestión de Problemas, 65
enfoque interno y externo, 21 (Tab) Contramedida, 230
reuniones, 31 Contrato de Soporte (UC), 248
278 | Index

contrato, definición, 229 dimisiones, 70

Control de Acceso Físico, 100, 211-212, 215-217 Directriz, 233
dispositivos, 215-216 (Tab) Diseño del Servicio, 6, 14, 26, 87-88, 131-132
Control de Configuración, 229 definición, 244
(anular) desafíos, 172
Control de Operaciones de TI, 142 implicación del personal, 28, 166
definición, 235 Interfaces inter proceso de entradas y salidas de la
funciones, 108 Gestión de Problemas, 65
seguridad, 102 Diseño, 231
Control de Operaciones vea Control de Operaciones de TI disparadores
Control de Procesos, 157, 240 cambio, 165
control remoto, consideraciones tecnológicas, 157, 161 Gestión de Accesos, 71
control, definición, 229 Gestión de Eventos, 41, 43-44
Coste de Capital (CAPEX), 227 Gestión de Incidencias, 53-54
Coste Indirecto, 234 Gestión de Peticiones, 57
Coste Operativo, 238 Gestión de Problemas, 65
Coste Unitario, 248 Disponibilidad, 224
Coste, 230, 238 Distribución Automática de Llamadas, 224
COTS (Producto Software Empaquetado Comercial), 228 divisiones, definición, 19
CSI vea Mejora Continua del Servicio (CSI) DML (Biblioteca Definitiva de Medios), 230
CTI (Integración de Telefonía e Informática), 228 Documentación del Diseño, 139
Cuadro de Mando Integral, 184, 224 documentación, 31-32
Cualificación, 241 definición, 231
Cultura de Servicios, 244 Diseño, 139
cultura, definición, 230 Gestión de Aplicaciones, 138-140
Cumplimiento, 233 Gestión de Operaciones de TI, 127-128
Declaración de Requisitos (SOR), 247 Gestión Técnica, 125
departamentos, definición, 19 Principios de Operación del Servicio, 31-32
Dependencia, 230 dominio público, Mejor Práctica 3-5
derechos dotación de personal
definición, 243 Desafíos de Operación del Servicio, 171
restricción/retirada, Gestión de Accesos, 70 Factores Críticos de Éxito, 174
Desarrollo de Aplicaciones, 136, 136 (Fig) investigación, 102
Desarrollo, 231 retención, 174
Descripción del Puesto de Trabajo, 236 ECAB (Comité de Cambios de Emergencia), 232
Descubrimiento, consideraciones tecnológicas, 157 economías de escala, definición, 231
despidos, 70 educación y formación vea formación
Despliegue Eficacia, 231
consideraciones tecnológicas, 157, 167, 168 Eficiencia, 231
definición, 230 Elemento de Configuración (CI), 229
Despliegue, 243 emergencias, problemas de comunicación, 196, 196 (Tab)
Detección, 231 encuestas de satisfacción del cliente, métricas del Centro
Diagnóstico, 52, 231 de Servicio al Usuario, 118, 118 (Tab)
Diagramas de árbol vea Diagramas de Ishikawa Entorno de Desarrollo, 231
Diagramas de Causa-Efecto vea Diagramas de Ishikawa Entorno de Producción, 237
Diagramas de espina de pescado vea Diagramas de Entorno de Pruebas, 248
Ishikawa Entorno, 232
Diagramas de Ishikawa, 62, 205-206 Entrega, 242
completo, 206 (Fig) Entregable, 230
definición, 235 Envío y Recepción, 212
inicio, 205 (Fig) equipos, definición, 19
Dimensionamiento de la Aplicación, 223 Error, 232
 Index | 279

Errores Conocidos, 236 disparadores, 71

Escalabilidad, 243 interfaces inter proceso de entradas y salidas, 71
Escalado Funcional, 233 objetivo, 68
Escalado Jerárquico, 234 roles y responsabilidades, 145-146
Escalado, 51-52, 232 monitorización de estado de la identidad, 69-70
Escenarios del Cambio, 139, 227 registro, 70
eSCM-SP (Modelo de Madurez del eSourcing para restricción/retirada de derechos, 70
Proveedores de Servicio), 232 verificación, 69
Especificación, 246 Gestión de Activos, 224
Estado, 247 Gestión de Aplicaciones, 16, 128-140
estándar internacional ISO/IEC 20000, 183 actividades genéricas, 133-134
Estándar, 246 Ciclo de Vida, 130-133, 130 (Fig)
Estimación, 232 definición, 223
estrategia de costes documentación, 138-140
enfoque interno y externo, 21 (Tab) funciones, 108, 128-129
logro de equilibrio, 22-26 manuales, 139-140
calidad comparada con coste, 23-26, 24 (Fig), 25 métricas, 137-138
(Fig), 25 (Tab) objetivos, 129
Estrategia del Servicio, 6, 14, 26, 131 organización, 134-136, 135 (Tab)
definición, 246 principios, 129-130
Interfaces inter proceso de entradas y salidas de roles y responsabilidades, 136-137, 136 (Fig), 143-144,
Gestión de Problemas, 66 146
Estrategia, 14, 247 Gestión de Calidad Total (TQM), 241, 248 vea también
Estratégico, 247 Mejor Práctica
Evaluación del Riesgo, 77, 166, 243 Gestión de Cambios, 16, 35, 72-73
Evaluación, 232 definición, 227
evaluación, definición, 224 Interfaces inter proceso de entradas y salidas de la
Evento, 232 Gestión de Problemas, 65, 159
excepciones, 42 problemas de comunicación, 194, 194 (Tab)
Gestión de Eventos y categorización de la relevancia, Gestión de Capacidad, 14, 73-76, 167-168
40 almacenamiento de datos, 75
medición, Monitorización y Control, 89 definición, 13, 227
problemas de comunicación, 195, 195 (Tab) estabilidad y capacidad de respuesta, 23 (Tab)
Externalización, 239 incidencias, 74
Centro de Servicio al Usuario, 119-121 Interfaces inter proceso de entradas y salidas de la
Factor Crítico de Éxito (CSF), 230 Gestión de Problemas, 65
Fallo, 223 monitorización, 73-74
Fiabilidad, 242 Gestión de la Continuidad de los Servicios de Tecnologías
financiación, 175 de la Información (ITSCM), 77, 236
Desafíos de Operación del Servicio, 171 Gestión de Contratos, 212
formación Gestión de Edificios, 100, 209
enfoque interno y externo, 21 (Tab) Gestión de Eventos, 15, 35-46
Equipos de Operación del Servicio, 102, 103 actividades/técnicas de proceso, 38 (Fig), 39-43
Gestión del Servicio, 174 categorización de la relevancia, 40
Personal del Centro de Servicio al Usuario, 116 correlación, 40-41
Foro para la Gestión de los Servicios de TI (itSMF), 236 filtro, 39-40
FTA (Análisis de Árbol de Fallos), 233 notificación, 39
Función Vital del Negocio, 249 selección de respuestas, 41-42
Funciones, definición 19, 107, 233 consideraciones tecnológicas, 158
Gestión de Accesos 15, 35, 68-72 definición, 232
actividades/técnicas de proceso, 68-70 desafíos, 44
definición, 223 diseño, 45-46
280 | Index

disparadores, 41, 43-44 Gestión de la Continuidad del Servicio vea Gestión

Factores Críticos de Éxito, 44-45 de Continuidad de los Servicios de Tecnología de
Gestión de la Información, 44 Información (ITSCM)
interfaces inter proceso de entradas y salidas, 43-44 Gestión de la Demanda, 75, 230
métricas, 44 Gestión de la Disponibilidad y de Capacidad, 35
objetivo, 36 Gestión de la Disponibilidad, 76-77
principios, 37 definición, 224
riesgos, 45 Interfaces inter proceso de entradas y salidas de la
roles y responsabilidades, 143-144 Gestión de Problemas, 65
valor para el negocio, 36-37 revisiones, 76
Gestión de Fallos, 184 Gestión de la Energía, 100, 210
Gestión de incidencias, 15, 27, 29, 35, 46-55 Gestión de la Entrega, 242
actividades/técnicas de proceso, 49-53 Gestión de la Información, 71-72
categorización, 50 Base de Datos de Errores Conocidos, 66
cierre, 53 Gestión de Eventos, 44
escalado, 51-52 Gestión de Incidencias, 54
flujo, 48 (Fig) Gestión de Problemas, 66
investigación y diagnóstico, 52 identidad de usuario, 71-72
priorización, 50-51, 51 (Tab) métricas, 72
registro, 49-50 Sistema de Gestión de la Configuración, 66
resolución y recuperación, 52-53 Gestión de la Seguridad de la Información (ISM), 101-103,
ámbito, 46-47 108
asociada con la capacidad, 74 definición, 234
consideraciones tecnológicas, 159 funciones, 71
definición, 234 Gestión de la Seguridad vea Gestión de la Seguridad de la
desafíos, 55 Información (ISM)
disparadores, 53-54 Gestión de las Instalaciones, 100-101, 209-212
escalas de tiempo, 47 definición, 233
factores críticos de éxito, 55 funciones, 108, 142
Gestión de la Información, 54 Gestión de las Relaciones con el Negocio, 226
interfaces inter proceso de salidas, 53-54 Gestión de Licencias
métricas, 54-55 consideraciones tecnológicas, 157
objetivo, 46 Gestión y Soporte del Servidor, 95
principios, 47-49 planificación e implementación, 166-168
riesgos, 55 Gestión de los Servicios de TI
roles y responsabilidades, 144-145 Bucles de Control de la Monitorización, 85-87, 85 (Fig)
Gestión de Internet / Web, 99-100 consideraciones tecnológicas, 157, 159
Gestión de la Calidad, 184 Gestión de Operaciones de TI, 125-128
Gestión de la Capacidad de los Recursos, 73 definición, 235
Gestión de la Capacidad del Componente, 228 documentación, 127-128
Gestión de la Capacidad del Negocio (BCM), 73, 225 funciones, 108, 126
Gestión de la Capacidad del Servicio (SCM), 73, 244 métricas, 127
Gestión de la Carga de Trabajo, 75 organización, 127
Gestión de la Configuración y Activos del Servicio (SACM), roles y responsabilidades 142, 144, 146
244 Gestión de Operaciones vea Gestión de Operaciones de TI
Gestión de la Configuración, 73 Gestión de Peticiones, 15, 35, 55-58
actualizaciones, 96 actividades/técnicas de proceso, 56-57
definición, 229 ámbito 56
Interfaces inter proceso de entradas y salidas de la consideraciones tecnológicas, 159
Gestión de Problemas, 65 definición, 242
disparadores, 57
interfaces inter proceso de entradas y salidas, 57
 Index | 281

métricas, 58 formación, 174

objetivo, 56 fuentes, 4, 4 (Fig), 11
roles y responsabilidades, 145 Marco de Trabajo de ITIL (vea Marco de Trabajo de ITIL)
Gestión de Problemas, 14, 15, 27, 35, 58-68 práctica, 11-16
actividades/técnicas de proceso, 59-65, 60 (Fig), 201 Gestión del Servicio de Negocio (BSM)
categorización, 61 consideraciones tecnológicas, 158
Investigación y diagnóstico, 61-63 definición, 226
priorización, 61 Gestión Financiera, 16, 35
registro, 61 definición, 233
solución provisional, 64 Interfaces inter proceso de entradas y salidas de la
ámbito 59 Gestión de Problemas, 66
consideraciones tecnológicas, 159-160 logro de equilibrio, 25-26, 25 (Tab)
definición, 240 Servicios de TI, 77
desafíos, 67-68 Gestión Proactiva de Problemas, 240
disparadores, 65 Gestión Técnica, 15, 81-103, 121-125
Gestión de la Información, 66 actividades genéricas, 122-123
interfaces inter proceso de entradas y salidas, 65-66 Administración de Bases de Datos, 97-98
métricas, 67 Almacenamiento y Archivo, 97
objetivo, 58-59 definición, 247
roles y responsabilidades, 145 documentación, 125
Gestión de Recursos Humanos, disparadores de Gestión de funciones, 108, 121
Accesos, 71 Gestión de Internet / Web, 99-100
Gestión de Red, 96-97 Gestión de la Seguridad de la Información (vea Gestión
Gestión de Servicios de Directorio, 98 de la Seguridad de la Información (ISM))
Gestión de Sistemas, 247 Gestión de las Instalaciones, 100-101
Gestión de Suministradores, 247 Gestión de Red, 96-97
Gestión de Versiones y del Despliegue, 73 Gestión de Servicios de Directorio, 98
definición, 242 Gestión del Centro de Proceso de Datos, 100-101
Interfaces inter proceso de entradas y salidas de la Gestión del Mainframe, 95
Gestión de Problemas, 65 Gestión del Middleware, 99
Gestión del Almacenamiento, 247 Gestión y Soporte del Servidor, 95-96
Gestión del Centro de Proceso de Datos, 100-101 madurez, 81 (Fig)
Gestión del Ciclo de Vida del Servicio métricas, 124-125
definición, 245 Monitorización y Control (vea Monitorización y Control)
especialización y coordinación, 13 objetivos, 121-122
funciones, 12 Operaciones de TI (vea Operaciones de TI)
procesos, 12-14, 13 (Fig) organización, 123
Gestión del Conocimiento, 16, 35, 77, 236 roles y responsabilidades 141, 143-144, 146
Gestión del Mainframe, 95 Soporte al Puesto de Trabajo, 98-99
Gestión del Middleware, 99 Gestión Web, 99-100
Gestión del Nivel de Servicio (SLM) Gestión y Soporte de Capacidad, Rendimiento y
definición, 245 Servidores, 96
Interfaces inter proceso de entradas y salidas de Gestión y Soporte del Servidor, 95-96
Gestión de Problemas, 65 Gestor de Cuentas, 223
Gestión del Porfolio de Servicios (SPM), 246 Gestor de Incidencias, 144
Gestión del proyecto, 165-166 Gestor de Procesos, 240
Gestión del Rendimiento, 239 Gestor del Centro de Servicio al Usuario, 140
Gestión del Riesgo, 237 vea también Gestión del Riesgo Gestor del Servicio, 245
Gestión del Riesgo, 77, 166, 175, 243 vea también Gestión gestores de departamento, 71
del Riesgo Gestores de Operación del Servicio, 171, 173
Gestión del Servicio Gobierno, 233
definición, 11, 245 Grupo de Soporte, 247
282 | Index

grupos, definición, 19 Estrategia del Servicio (vea Estrategia del Servicio)

guía complementaria de la industria, 183-184 Mejora Continua del Servicio (vea Mejora Continua del
guía de la industria, complementaria, 183-184 Servicio (CSI))
Horario del Servicio, 245 Operación del Servicio (vea Operación del Servicio)
Identidad, definición, 234 Transición del Servicio (vea Transición del Servicio)
identificación de umbrales, diseño de Gestión de Eventos, Medida e Informes del Servicio, 16, 35
46 Mejor Práctica
Impacto, 234 definición, 225
Impresión y Salida, 94-95 dominio público, 3-5
Impulsor, 231 fuentes, 4, 4 (Fig)
Imputación de Costes, 228 guía complementaria de la industria, 183-184
Incidencia Grave, 237 Mejora Continua del Servicio (CSI), 6-7, 14, 35, 131
Incidencia, 234 Bucles de Control de la Monitorización, 91-92
incidencias, Gestión de Capacidad, 74 definición, 229
Indicadores Clave de Rendimiento (KPIs) Interfaces inter proceso/entrada y salida de Gestión de
definición, 236 Problemas, 65
Monitorización y Control, 91 logro de equilibrio, 22, 24-25, 27
Información de Gestión, 237 mensajes de error, diseño de Gestión de Eventos, 46
Informe de Excepciones, 232 Métrica Externa, 232
informes de rendimiento, problemas de comunicación, Métrica Interna, 235
189-191, 189 (Tab), 190 (Tab), 191 (Tab) métricas, 172
Informes del Servicio, 246 Centro de Servicio al Usuario, 117-118, 118 (Tab)
Infraestructura de TI, 235 definición, 237
Instrucción de Trabajo, 249 enfoque interno y externo, 21 (Tab)
Integración de Telefonía e Informática (CTI), 228 Gestión de Aplicaciones, 137-138
Integridad, 234 Gestión de Eventos, 44
Interconexión de Sistemas Abiertos (OSI), 184 Gestión de Incidencias, 54-55
interesados, 88, 246 vea también clientes/usuarios Gestión de la Información, 72
interfaces inter proceso/entrada y salida, 43-44, 57, 65-66, Gestión de Operaciones de TI, 127
159 Gestión de Peticiones, 58
Invocación, 235 Gestión de Problemas, 67
ISM vea Gestión de la Seguridad de la Información (ISM) Gestión Técnica, 124-125
ISO (Organización Internacional para la Normalización), logro de equilibrio, 22
235 Monitorización y Control, 91
ISO 9000, definición, 235 Middleware, 237
ISO/IEC 27001, definición, 235 Modelado, 238
ISP (Proveedor de Servicio de Internet), 235 Modelo de Cambios, 227
IVR (Respuesta Interactiva de Voz), 234 Modelo de Madurez del eSourcing para Proveedores de
KEDB vea Base de Datos de Errores Conocidos (KEDB) Servicio (eSCM-SP), 232
KPIs vea Indicadores Clave de Rendimiento (KPIs) Modelo, 238
líderes, 173-174 monitorización
Lightweight Directory Access Protocol (LDAP), 98 activa, 223
Línea de referencia, 225 definición, 223, 238
logro de equilibrio vea principios Gestión de Capacidad, 73-74
Llamada, 226 pasiva, 239
Lluvia de ideas, 62, 206, 225 monitorización del estado de identidad, Gestión de
Madurez, 237 Accesos, 69-70
Mantenimiento, 212 Monitorización Proactiva, 240
manuales, Gestión de Aplicaciones, 138-140 Monitorización Reactiva, 241
Marco de Trabajo de ITIL, 5-7, 5 (Fig) Monitorización y Control, 82-92
definición, 236 definiciones, 82-83
Diseño del Servicio (vea Diseño del Servicio) asociadas con objetivos, 87-88
 Index | 283

medición basada en excepciones, 89 definición, 238

métricas, 91 problemas de comunicación, 187
tipos, 223, 239 Optimizar, 239
activa comparado con pasiva, 88-89, 89 (Tab) Organización Internacional para la Normalización (ISO),
medición basada en excepciones, 89 235
Motor de Correlación, 40-41 organización, 107-154
motor del flujo de trabajo, 157 Centro de Servicio al Usuario, 111-114
MTBF (Tiempo Medio Entre Fallos), 237 definición, 239
MTRS (Tiempo Medio de Restauración del Servicio), 237 estructuras, 146-154
MTTR (Tiempo Medio de Reparación), 237 basada en la geografía, 150, 151 (Fig), 153
negocio basada en actividades, 148, 149 (Fig)
definición, 225 basada en proceso, 148-150
soporte, 173 centralizada, 152-154, 152 (Fig)
Nivel de Servicio, 245 especialización técnica, 146-148, 147 (Fig)
Objetivo de la Gestión de Servicios, 245 híbrida, 150-154
Objetivo de Negocio, 226 Gestión de Aplicaciones, 134-136, 135 (Tab)
Objetivo de Nivel de Servicio, 245 Gestión de Operaciones de TI, 127
Objetivo, 238 Gestión Técnica, 123
Objetivos de Control para la Información y Tecnología OSI (Interconexión de Sistemas Abiertos), 184
asociada (COBIT), 87, 183, 228 paneles de control
Observación Técnica, 247 consideraciones tecnológicas, 158
Office of Government Commerce (OGC), 238 definición, 230
off-shore, definición, 238 Parada Planificada, 239
OLA (Acuerdos de Nivel Operativo), 238 pérdidas de categoría laboral, 70
Opción de Recuperación, 241 Perfil de Usuario (UP), 249
Operación del Servicio, 6, 77 personal de operaciones
comunicación (vea comunicación) enfoque interno y externo, 21 (Tab)
consideraciones de la implementación, 165-168 implicación, 28
contexto, 3-7 Perspectiva de Control, 229
definición, 3, 245 Perspectiva del Negocio, 226
desafíos, 171-173 Petición de Cambio (RFC), 242
dotación de personal (vea dotación de personal) Disparadores de Gestión de Accesos, 71
educación y formación (vea formación) Petición de Servicio
externalizar, 109, 119-121, 239 definición, 246
factores críticos de éxito, 173-175 Disparadores de Gestión de Accesos, 71
funciones, 15-16, 107-109, 107 (Fig) Piloto, 239
objetivos, 7, 13 (vea también procesos específicos) Plan de Continuidad de los Servicios de TI, 236
optimización del rendimiento, 14-15 Plan de Disponibilidad, 224
organización (vea organización) Plan, 239
principios (vea principios) Planificación de Cambios, 228
procesos (vea procesos) Planificación de la Capacidad, 75-76, 227
Operaciones Planificación de Trabajos
definición, 238 definición, 236
estrategia, enfoque interno y externo, 21 (Tab) Operaciones de TI, 92-93
Operaciones de Negocio, 226 Planificación, 240
Operaciones de TI, 15-16, 92-95 Planificar-Hacer-Verificar-Actuar, 239
Backup y Restauración, 93-94 Política de Seguridad de la Información, 234
definición, 235 Política de Seguridad, 234
Planificación de Trabajos-Jobs-, 92-93 Política de Transición hacia Operaciones, 171
Operadores de TI, 142 Política, 240
Operar, 238 Porfolio de Aplicaciones, 138, 223
Operativo Porfolio de Servicios, 245
284 | Index

Práctica Gestión Técnica, 122-123

buena (vea Mejor Práctica) Medición e Informes del Servicio (vea Medición e
definición, 240 Informes del Servicio)
presupuesto, definición, 225 Monitorización y Control (vea Monitorización y Control)
Primera línea de soporte, 233 Producto Software Empaquetado Comercial (COTS), 228
PRINCE2, 240 Programa de Mejora de Servicio (SIP), 245
principios, 19-32 Programa, 241
Bucles de Control de la Monitorización, 83 (Fig) promociones, 70
buena práctica (vea Mejor Práctica) propiedad de los datos, externalización del Centro de
comunicación, 29-31 Servicio al Usuario, 121
documentación, 31-32 Propietario del Proceso, 241
Gestión de Aplicaciones, 129-130 Proposición de Valor, 11
Gestión de Incidencias, 47-49 Proveedor de Servicio de Internet (ISP), 235
logro de equilibrio, 19-27 Proveedor de Servicio, 246
calidad comparada con coste, 23-26, 24 (Fig), 25 Proveedor Externo de Servicios, 232
(Fig), 25 (Tab) proyecto(s)
comportamiento reactivo comparado con proactivo, definición, 241
20-22, 27 (Fig), 27 (Tab) problemas de comunicación, 192, 192 (Tab), 193 (Tab)
consideraciones tecnológicas, 22 traspaso, 193 (Tab)
estabilidad comparada con capacidad de respuesta, Prueba, 247
22-23, 22 (Fig), 23 (Tab) Puente de Operaciones, 92, 238
externo comparado con interno, 20-22, 20 (Fig), 21 Puesta en producción, 243
(Tab) Punto Objetivo de Recuperación, 241
métricas, 22 Punto Único de Contacto, 246
Salud Operativa, 28-29 Punto Único de Fallo, 246
Prioridad, 240 Real, 237
Problema, 240 Recuperación Inmediata, 234
Procedimiento, definición, 240 Recuperación Intermedia, 235
Procedimientos de Operación Estándar, 140, 246 Recuperación, 241
procedimientos y manuales Recurso, 243
enfoque interno y externo, 21 (Tab) Red de Valor, 249
Gestión de Aplicaciones, 139-140 Redundancia, 242
logro de equilibrio, 22 registro
Proceso de Entrega, 242 Gestión de Accesos, 70
Proceso de Negocio, 226 Gestión de Incidencias, 49-50
procesos, 15, 35-77 Gestión de Problemas, 61
Continuidad del Servicio de TI (vea Continuidad del Registro de Activos, 224
Servicio de TI) Registro de Cambio, 227
definición, 223, 240 Registro de Entrega, 242
Gestión de Accesos (vea Gestión de Accesos) Registro de Errores Conocidos, 237
Gestión de Aplicaciones, 133-134 Registro de Eventos, 41
Gestión de Cambios (vea Gestión de Cambios) Registro de Incidencias, 42, 234
Gestión de Eventos (vea Gestión de Eventos) Registro de Problemas, 42, 240
Gestión de Incidencias (vea Gestión de Incidencias) Registro, 241
Gestión de la Disponibilidad y de la Capacidad, 35 Relación, 242
Gestión de la Seguridad de la Información (vea Gestión rendimiento de la infraestructura, 190
de la Seguridad de la Información (ISM)) Rendimiento del Proceso, 190
Gestión de Peticiones, 56, 57 Rendimiento, 239, 248
Gestión de Problemas (vea Gestión de Problemas) Rendimiento, 248
Gestión del Conocimiento (vea Gestión del Rentabilidad, 230
Conocimiento) Reparación, 242
Gestión Financiera (vea Gestión Financiera) Requisito de Nivel de Servicio (SLR), 245
 Index | 285

Requisito, 242 Sistemas adaptativos, 29

Resolución, 52-53, 242 Sistemas Automáticos, 29
responsables de turnos, Gestión de Operaciones de TI, 142 Sistemas de Bucle Abierto, 83
respuesta automática, selección de respuesta de Gestión Sistemas de Bucle Cerrado, 83
de Eventos, 41 Sistemas de Recuperación Automática, 29
Respuesta Interactiva de Voz (IVR), 234 Sistemas dinámicos, 29
Restaurar, 93-94, 243 SKMS (Sistema de Gestión del Conocimiento del Servicio),
Retirar, 243 66, 67 (Fig), 245
retiro, 70 SLA (Acuerdo de Nivel de Servicio), 245
reuniones de departamento, problemas de comunicación, SLM vea Gestión del Nivel de Servicio (SLM)
31 SLR (Requerimiento de Nivel de Servicio), 245
reuniones de equipos, comunicación, 31 Solución Provisional, 64, 250
reuniones de grupo, problemas de comunicación, 31 Soporte al Puesto de Trabajo, 98-99
reuniones, problemas de comunicación, 30-31 Soporte de Gestión, 173
Revisión, 64, 243 Soporte Post-Implantación, 231
RFC vea Petición de Cambio (RFC) Soporte siguiendo al Sol, 233
riesgo, definición 243 soporte técnico, 101-102
rol(es), 140-146, 243 SOR (Declaración de Requisitos), 247
definición, 19 SPM (Gestión del Porfolio de Servicios), 246
roles y responsabilidades, 140-146 Standby, 246
SACM (Gestión de la Configuración y Activos del Servicio), Suministrador, 247
244 Super Usuarios
Salida, 239 definición, 247
Salida, 94-95 Personal del Centro de Servicio al Usuario, 116-117
Salud Operativa, 28-29 Supervisor del Centro de Servicio al Usuario, 140-141
SCM (Gestión de la Capacidad del Servicio), 73, 244 Táctico, 247
Scripts de Diagnóstico, 161, 231 Tecnologías de la Información (TI), 234 vea también
Segunda Línea de Soporte, 244 entradas bajo TI
Seguridad, 211 Tercera Línea de Soporte, 248
Servicio de Directorio, 231 Terceros, 248
Servicio de Negocio, 226 Tiempo de Caída, 231
Servicio Interno, 235 Tiempo de Respuesta, 243
Servicio, 244 Tiempo Medio de Reparación (MTTR), 237
servicios de seguridad, 212, 217 vea también Control de Tiempo Medio de Restauración del Servicio (MTRS), 237
Acceso Físico Tiempo Medio Entre Fallos (MTBF), 237
Servicios de TI Tiempo Objetivo de Recuperación, 241
definición, 236 Tipo de Llamada, 226
Gestión Financiera, 77 Tolerancia a Fallos, 233
Gestión Técnica, (vea Gestión Técnica) tormenta de ideas, 62, 206, 225
servicios, definición, 11, 12 (Fig) Trabajo en Curso, 249
Servidor, 244 Transacción, 248
SFA (Análisis de Fallos del Servicio), 244 transferencias, Gestión de Accesos, 70
SIP (Programa de Mejora del Servicio), 245 Transición del Servicio 6, 14, 131
Sistema de Gestión de la Calidad, 241 definición, 246
Sistema de Gestión de la Configuración (CMS) implicación del personal, 28, 166
definición, 229 Interfaces inter proceso/entrada y salida de Gestión de
Gestión de la Información, 66 Problemas, 65
integrada, consideraciones tecnológicas, 157, 159-160 Transición, 248
Sistema de Gestión del Conocimiento del Servicio (SKMS), Tregoe vea Análisis de Kepner & Tregoe
66, 67 (Fig), 245 turnos
Sistema de Gestión, 237 comunicación entre, 188, 188 (Tab)
Sistema, 247 definición, 246
286 | Index

UC (Contrato de Soporte), 248

Umbral, 248
Unidad de Negocio, 226
Urgencia, 248
Usabilidad, 249
usuarios vea clientes/usuarios
Utilidad, 249
utilidades de diagnóstico, 157-158
Validación, 249
validez de las pruebas, 174-175
Valor Obtenido por el Dinero, 249
Varianza, 249
Verificación
definición, 249
Gestión de Accesos, 69
Versión, 249
virtualización, 101
Visión, 249
fuentes, 4, 4 (Fig)
conocimiento propietario, 4-5
Vuelta atrás, 242
5878 SO Spanish Cover V0_3.indd 2 7/1/10 15:48:38
 Una vez se hayan introducido los servicios con éxito en el
entorno real de trabajo es necesario realizar una gestión eficaz
de las operaciones diarias de los mismos. Es en este punto, en
la interfaz con el cliente, donde se generan las percepciones en
relación con su rendimiento como proveedor de servicio.

Este libro presenta y explica las actividades de entrega y control

que ofrecen soporte a una operación del servicio de alta calidad.
El uso de esta guía le ayudará a conseguir una metodología
Operación del Servicio
equilibrada y flexible, afianzando su posición para conseguir la
excelencia como proveedor de servicio.

La organización itSMF International, a través de su Subcomité

Ejecutivo de Publicaciones Internacionales (IPESC), integrado

Operación del Servicio

por miembros de todos los capítulos de itSMF en todo el mundo,
ha concedido la aprobación formal de itSMF International a
este libro.

ISBN 978-0-11-331150-7

www.tso.co.uk 9 780113 311507

5878 SO Spanish Cover V0_3.indd 1 7/1/10 15:48:36