Itil
Itil
Itil
Gestión de Servicios TI
Fundamentos de la Gestión TI 4
Visión General 4
ITIL 5
Soporte al Servicio 6
Provisión del Servicio 7
Forum ITSMF 8
Certificaciones ITIL 9
Caso Práctico 10
Centro de Servicios 11
Visión General 11
Introducción y Objetivos 12
Implementación 13
Estructura 14
Funciones 17
Equipo y Formación 18
Control Centro de Servicios 19
Caso Práctico 20
Gestión de Incidentes 21
Visión General 21
Introducción y Objetivos 22
Clasificación y Registro 24
Escalado 25
Proceso 26
Registro y Clasificación 27
Análisis, Resolución y Cierre 28
Control del Proceso 29
Caso Práctico 30
Gestión de Problemas 31
Visión General 31
Introducción y Objetivos 32
Proceso 34
Control de Problemas 35
Control de Errores 37
Control del Proceso 39
Caso Práctico 40
Gestión de Configuraciones 41
Visión General 41
Introducción y Objetivos 42
Definiciones 43
Proceso 44
Planificación 45
Clasificación y Registro 46
Monitorización 48
Control 49
Auditorías 50
Control del Proceso 51
Caso Práctico 52
Gestión de Cambios 53
Visión General 53
Introducción y Objetivos 54
Conceptos Básicos 56
Proceso 58
Registro 59
Aceptación y Clasificación 61
Aprobación y Planificación 62
Implementación 63
Evaluación 64
Emergencias 65
Control del Proceso 66
Caso Práctico 67
Gestión de Versiones 69
Visión General 69
Introducción y Objetivos 70
Conceptos Básicos 72
Proceso 74
Planificación 75
Desarrollo 76
Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papel en la
misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido
en una herramienta imprescindible y clave para empresas e instituciones.
La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez genera
ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una
herramienta más entre muchas otras.
Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de soporte y de alguna forma eran
equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la
organización pero poco más.
Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una parte sustancial de los
procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de
ejemplo la Banca Electrónica.
ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus
objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios
informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las
expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la
gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar
los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias,
es soportado por los procesos de mantenimiento y operaciones.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del
coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes
de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a
cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados,
con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta
calidad, y de coste aceptable.
ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros centrales cubriendo las dos principales áreas
de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros
complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del
negocio. A partir del año 2000, se acometió una revisión de la biblioteca. En esta revisión, ITIL ha sido reestructurado
para hacer más simple el acceder a la información necesaria para administrar sus servicios. Los libros centrales se han
Fundamentos de la Gestión TI
Soporte al Servicio
El soporte al servicio se preocupa de de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del
servicio prestado al usuario.
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de soporte al servicio
según los estándares ITIL:
La provisión del servicio se ocupa de los servicios ofrecidos en si mismos. En particular de los Niveles de servicio, su
disponibilidad,su continuidad, su viabilidad financiera, la capacidad necesaria de la infraestructura TI y los niveles de
seguridad requeridos
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de provisión del
servicio según los estándares ITIL:
En la actualidad, las empresas dependen cada vez en mayor medida de la tecnología para la promoción y distribución de
sus productos en el mercado, por lo que resulta imprescindible adoptar unos estándares que permitan la correcta gestión
de los procesos informáticos asociados.
El objetivo del ITSMF es organizar una red de expertos en Gestión de Servicios Informáticos, ofrecer completa
información sobre los mismos y organizar seminarios y conferencias para ayudar a las empresas a resolver los problemas
que puedan encontrar en este campo, todo ello con el objetivo de mantener un alto nivel de calidad de lestos servicios
gracias a la utilización de un código de Mejores Prácticas.
Más de 1000 compañias, grandes corporaciones y empresas públicas de todo el mundo pertenecen al ITSMF. Osiatis es
en la actualidad una de las empresa responsables de las actividades del Forum en España y Francia (Claude Durand,
Director de Desarrollo de Osiatis Francia, es tesorero de la asociación en ese país).
EXIN e ISEB
La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information Systems Examination Board"
(ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. Fue realizado en estrecha cooperación
con la OGC y el itSMF. EXIN e ISEB son organizaciones sin ánimo de lucro que cooperan para ofrecer una amplia gama de
certificaciones en tres niveles:
El sistema de certificación está basado en los requisitos para representar eficazmente el papel pertinente dentro de una
organización TI. Hasta la fecha, se han entregado más de 50.000 certificados Foundation a profesionales de más de 30
países.
Hoy en día, ITIL representa mucho más que una serie de libros útiles sobre Gestión de Servicios TI. El marco de mejores
prácticas en la Gestión de Servicios TI representa un conjunto completo de organizaciones, herramientas, servicios de
educación y consultoría, marcos de trabajo relacionados, y publicaciones. Desde 1990, se considera a ITIL como el
marco de trabajo y la filosofía compartida por quienes utilizan las mejores prácticas ITIL en sus trabajos. Gran cantidad
de organizaciones se encuentran en la actualidad cooperando internacionalmente para promover el estándar ITIL como
un estándar de facto para la Gestión de Servicios TI.
Enlaces de interés
Podréis encontrar información adicional en:
Para mejor ilustrar los contenidos de este "curso" cada capítulo incluye un caso práctico relacionado directamente con los
contenidos del mismo.
Todos estos casos prácticos se refieren a una compañía (ficticia) dedicada al catering, "Cater Matters", que ha optado por
introducir la metodología ITIL para la gestión de sus servicios.
"Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye:
La logística del servicio es compleja y los niveles de servicio muy exigentes en lo que respecta a la calidad y los plazos de
entrega.
Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informático que le
permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como sus procesos de producción
y distribución.
La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la metodología ITIL
como la base de todos sus procesos y servicios. Entre las decisiones adoptadas consecuentemente caben destacar:
• Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con los clientes
y el resto de la infraestructura TI.
• Organización de sus actividades en torno a los procesos.
• Designación de responsables o gestores para cada uno de los procesos críticos.
• Establecimiento de estrictos protocolos de monitorización de la calidad del servicio.
El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los los usuarios y
la Gestión de Servicios TI.
Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos
de soporte al servicio:
Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus
contactos con usuarios y clientes.
Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente y continuo e
independiente de su localización geográfica.
Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que estan recibiendo una atención
personalizada y ágil que les ayude a:
El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los
servicios ofrecidos:
• Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en
los casos más triviales, a otras instancias de soporte y/o comerciales.
• Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico
que permita resolver en el menor tiempo las interrupciones del servicio.
• Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los
servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Aparte de
ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes, usuarios y la propia
organización TI tales como:
o Supervisión de los contratos de mantenimiento y niveles de servicio.
o Canalización de las Peticiones de Servicio de los clientes.
o Gestión de las licencias de software.
o Centralización de todos los procesos asociados a la Gestión TI.
Los principales beneficios de una correcta implementación del Centro de Servicios se resumen en:
La implementación de un Service Desk requiere una meticulosa planificación. En primera instancia debe establecerse:
Además de estas cuestiones de carácter técnico, es imprescindible ponderar otros aspectos más directamente
relacionados con el "factor humano" y que son tan importantes o más que los puramente técnicos para el éxito del
Centro de Servicios:
El objetivo NO es implementar lo más rápidamente posible un Centro de Servicios sino implantar un Centro de
Servicios cuyos objetivos se alineen con nuestros procesos de negocio, mejoren la satisfacción de nuestros clientes,
optimicen la imagen externa de nuestra organización y nos sirva de plataforma para identificar nuevas oportunidades de
negocio.
Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto de toda la organización TI con
clientes y usuarios, es por lo tanto imprescindible que:
Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica.
Estructura lógica
Los integrantes del Centro de Servicios deben:
Estructura física
Dependiendo de las necesidades de servicio: locales, globales, 24/7,...se debe de optar por una estructura diferente para
el Centro de Servicios.
• Centralizado
• Distribuido
• Virtual
En este caso todo el contacto con los usuarios se canaliza a través de una sola estructura central.
Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos
geográficos (ya sean ciudades, países o continentes). Sus ventajas son obvias en estos casos, sin embargo la
deslocalización de los diferentes Centros de Servicios conlleva grandes problemas:
En la actualidad y gracias a las rápidas redes de comunicación existentes la situación geográfica de los Centros de
Servicios puede llegar a ser irrelevante.
El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos.
Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de
Servicios TI. Sin embargo, no cabe duda, de que su función principal es gestionar la relación con los clientes y usuarios
manteniéndoles puntualmente informado de todos aquellos procesos de su interés.
A continuación describimos algunas de las actividades que un Service Desk debería ofrecer para merecer ese nombre:
Gestión de Incidentes
Independientemente de que la completa gestión de las incidencias requiera la colaboración de otros departamentos y
personal, el Service Desk debe ofrecer una primera línea de soporte para la solución de todas las interrupciones de
servicio y/o peticiones de servicio que puedan cursar los clientes y usuarios.
Centro de información
El Service Desk debe ser la principal fuente de información de los clientes y usuarios, informando sobre:
• Nuevos servicios.
• El lanzamiento de nuevas versiones para la corrección de errores.
• El cumplimiento de los SLAs.
• ...
Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio, evaluar las
necesidades de los clientes y su grado de satisfacción con el servicio prestado.
El Centro de Servicios se encuentra en una situación inmejorable para ofrecer también información privilegiada a todos
los procesos de gestión de los servicios TI. Es para ello imprescindible que se lleve un adecuado registro de toda la
interacción con los usuarios y clientes.
Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externos del
mantenimiento y la Gestión de Incidentes que debe ser canalizada a través del Service Desk.
La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su Service
Desk.
Todos hemos sufrido frustrantes experiencias con grandes empresas que prometen un soporte continuo y de alta calidad
y que a la hora de la verdad disponen de un centro de contacto con personal poco preparado, cuando no directamente
mal educado.
"El éxito de su Service Desk es el éxito de su empresa" y el mismo depende en gran medida de las personas que lo
integren. Es por tanto imprescindible establecer estrictos protocolos de selección y formación de su personal integrante.
La formación impartida debe referirse a todos estos aspectos y no limitarse a la capacitación tecnológica.
Y, por último, recordar que sólo tenemos una oportunidad de ofrecer una buena primera impresión.
La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente, no sea
responsabilidad exclusiva de éste.
Es importante que se intenten establecer métricas bien definidas para medir el rendimiento del Centro de Servicios y la
apreciación que los usuarios tienen de éste.
• Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax.
• Porcentaje de incidentes que se cierran en primera línea de soporte.
• Porcentaje de consultas respondidas en primera instancia.
• Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.
• Cumplimiento de los SLAs.
• Número de llamadas gestionadas por cada miembro del personal del Service Desk.
Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el
uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados.
Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar la opinión del
cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Toda esta información debe ser
recopilada y analizada periódicamente para mejorar la calidad del servicio.
Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater Matters" ha
decidido implantar un Service Desk que centralice todos los contactos con clientes, proveedores y la organización TI.
• Realizar una pequeña promoción para presentar los nuevos servicios a los clientes existentes y
potenciales.
• Habilitar un espacio web para canalizar, en la medida de los posible, la interacción con los usuarios a
través de este medio:
o Formularios de consultas y alta de incidentes.
o Consulta remota, mediante los web services asociados, del estado de los incidentes activos,
históricos de incidencias y cumplimiento de los SLAs.
o FAQs actualizadas que permitan a los usuarios consultar directamente sobre los servicios
prestados, errores conocidos, etc.
• Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos de
interacción con los usuarios dependiendo de la situación en cuestión.
• Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del
Service Desk.
• Impartir formación específica:
o Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de
Atención al Cliente".
o Sobre las herramientas de software utilizadas.
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de
la manera más rápida y eficaz posible.
La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se
preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el
servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe
jugar una papel esencial en el mismo.
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y
software según el libro de Soporte del Servicio de ITIL un incidente es:
“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una
interrupción o una reducción de calidad del mismo”.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las
Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que
estos servicios se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el
inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.
Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:
• No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan
innecesariamente y/o omitiendo los protocolos preestablecidos.
• No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se
registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
• No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede
provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.
Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de
prioridad para la resolución de las mismas.
• Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de
negocio y/o del número de usuarios afectados.
• Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente
y/o el nivel de servicio acordado en el SLA.
También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos
necesarios: los incidentes “sencillos” se tramitarán cuanto antes.
Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente.
La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones
temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin
graves repercusiones.
Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente
diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:
Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba
recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este
proceso se le denomina escalado.
• Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el
problema.
• Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que
se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la
resolución de un incidente específico.
* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario , integrar diferentes niveles en el caso de PYMES
Registro
La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo.
Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de
Servicios o el soporte técnico, entre otros.
El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre
el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.
• La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera
instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad
competente.
• Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un
usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.
• Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente
tanto en los procesos internos como en las comunicaciones con el cliente.
• Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para
el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).
• Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que
puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia
CMDB (hardware interrelacionado), etc.
• Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben
ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.
Clasificación
La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada
para la resolución del mismo.
• Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles)
dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los
servicios afectados por el incidente.
• Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según
criterios preestablecidos, un nivel de prioridad.
• Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia
designara al personal de soporte técnico responsable de su resolución (segundo nivel).
• Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por
ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en
base al SLA correspondiente y la prioridad.
En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna
incidencia ya resuelta y aplicar el procedimiento asignado.
Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un
nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente
se seguirán los protocolos de escalado predeterminados.
Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de
datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.
Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra
una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de
las causas subyacentes.
• La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual
sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de
incumplimiento.
• Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el
servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
• Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a
los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
• Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la
organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
• Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre
asignación de recursos, costes asociados al servicio, etc.
Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta
implementación. Entre ellos cabe destacar:
Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la
forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:
El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor de uno de sus
clientes.
Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la
web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos
El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días
pero también observa que éste se ha guardado defectuosamente.
El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.
• Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita
rápidamente el suministro.
• Registra los datos del incidente.
• Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error
conocido y cuales son las posibles soluciones temporales
• Propone una solución temporal al cliente: indica una zona reservada de la web desde la que se pueden
realizar pedidos "urgentes" vía email.
• Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la
mañana.
• Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los
helados solicitados.
• Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes
del mediodía.
• Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.
• No consigue identificar la causa del incidente.
• Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero
pre-calificando su prioridad como baja.
• Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución
temporal satisfactoria no se requiere un escalado superior.
• Registra la solución temporal del incidente junto a la información proporcionada por el departamento de
sistemas.
• Da por cerrado el incidente.
• Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
• Determinar posibles soluciones a las mismas.
• Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.
• Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos
buscados sin crear problemas de carácter secundario.
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes
incluso antes de que estos ocurran.
Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más
rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes y causas del mismo.
Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función
de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.
Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia
significativa.
Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas.
Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de
Incidentes se resumen en el siguiente interactivo:
• Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la
Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los
incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y
resolver los problemas.
• Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los
agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la
infraestructura TI.
• Aumento de los costes por la contratación de personal especializado, aunque estos se vean
sobradamente compensados por los beneficios derivados.
Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en
errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas
a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha
colaboración con la Gestión de Cambios.
Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a
detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI
El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el
Control de Errores pueda proponer las soluciones correspondientes.
1. Identificación y Registro
Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información
utilizadas son:
• La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y
que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se
habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría
de problema.
• Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la
Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los
sistemas y estructuras TI para evitar futuros problemas.
• Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la
existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.
Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales
y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles
específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.
Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se
determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de
deterioro de la calidad del servicio).
Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por
ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos
recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su
impacto en la infraestructura TI.
Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda
frecuente que el problema este causado por:
• Errores de procedimiento.
• Documentación incorrecta.
• Falta de coordinación entre diferentes áreas.
• ...
Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo
tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en
la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.
Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de
Errores para su posterior procesamiento.
Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de
Errores el registro del mismo como error conocido.
Análisis y Solución
Se deben investigar diferentes soluciones para el error evaluando en cada momento:
En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio,
pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios.
Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de
tenerse en cuenta las siguientes consideraciones:
Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas.
En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se
considera concluido el proceso y se emiten los informes correspondientes.
• Disminución del número de incidentes y una más rápida resolución de los mismos.
• Mayor eficacia en la resolución de problemas.
• Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o
provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información
de vital importancia a otras áreas de la infraestructura TI.
Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada
proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para
evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al
proceso de identificación y solución de problemas.
El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le
pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.
La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el
modelo de Kepner y Tregoe:
• La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos,
sin que este error parezca tener correlación con otros componentes de hardware / software.
Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.
Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:
Verificación:
• Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel
de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB).
• Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión.
• Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera que
estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas,
realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.
• Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla
con la almacenada en la CMDB para subsanar discrepancias.
Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la
misma. La principal tarea de la Gestión de Configuraciones es llevar un registro actualizado de todos los elementos de
configuración de la infraestructura TI junto con sus interrelaciones.
Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos, en particular, de la Gestión
de Cambios y Versiones.
• Proporcionar información precisa y fiable al resto de la organización de todos los elementos que
configuran la infraestructura TI.
• Mantener actualizada la Base de Datos de Configuraciones:
o Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado,...
o Interrelación entre los CIs.
o Servicios que ofrecen los diferentes CIs.
• Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. Una fuente
habitual de problemas es la incompatibilidad entre diferentes CIs, drivers desactualizados, etc. La detección de
estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema.
• Una Gestión de Cambios más eficiente. Es imprescindible conocer la estructura previa para diseñar
un cambio que no genere nuevas incompatibilidades y/o problemas.
• Reducción de costes. El conocimiento detallado de todos los elementos de configuración permite, por
ejemplo, eliminar duplicidades innecesarias.
• Control de licencias. Se pueden identificar tanto copias ilegales de software que pueden suponer tanto
peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que
pueden repercutir negativamente en la organización.
• Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectar vulnerabilidades
en la infraestructura.
• Mayor rapidez en la restauración del servicio. Si se conocen todos los elementos de configuración y
sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve
posible.
Las principales dificultades con las que topa la Gestión de Configuraciones son:
• Una incorrecta planificación: es esencial programar correctamente las actividades necesarias para
evitar duplicaciones o incorrecciones.
• Estructura inadecuada de la CMDB: mantener actualizada una base de datos de configuraciones
excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos.
• Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de
registro y sacar el máximo provecho de la CMDB.
• Falta de Coordinación con la Gestión de Cambios y Versiones que imposibilita el correcto
mantenimiento de la CMDB.
• Falta de organización: es importante que haya una correcta asignación de recursos y
responsabilidades. Es preferible, cuando sea posible, que la Gestión de Configuraciones sea llevada a cabo
por personal independiente y especializado.
Definiciones
A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración
(CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una
definición precisa de ambos.
Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos
ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:
• Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes:
tarjetas de red, teclados, lectores de CDs, ...
• Software: sistemas operativos, aplicaciones, protocolos de red, ...
• Documentación: manuales, acuerdos de niveles de servicio, ...
En resumen, todos los componentes que han de ser gestionados por la organización TI.
La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la
infraestructura TI de la organización.
Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura
predefinidos.
Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén
correctamente registrados y se conoce su estado actual.
Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real
de la estructura TI de la organización.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias
con el resto de procesos. Por ello su implantación es particularmente compleja.
Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que
aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:
Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa con las graves
consecuencias que esto supondrá para el resto de los procesos.
La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor
con éxito, predeterminar la estructura del CMDB de manera que:
• Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la
organización y resultar, a la larga, en una dejación de responsabilidades.
• La información sea suficiente: debe existir, al menos un registro de todos los sistemas críticos para la
infraestructura TI.
Alcance
En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:
• Es esencial incluir al menos todos los sistemas de hardware y software implicados en los servicios
críticos.
• Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo,
pueden obviarse componentes que ya han sido retirados.
• Es recomendable incorporar, al menos, la documentación asociada a proyectos, SLAs y licencias.
En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos objetivos en exceso
ambiciosos pueden resultar contraproducentes.
• Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.
• Relaciones: conexión en red, impresoras conectadas, etc.
• Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.
• La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.
• Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir
físicamente unido al mismo (mediante una etiqueta de difícil eliminación).
• Los códigos no deben ser sólo utilizados para componentes de hardware sino también para
documentación y software.
Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede
ser de gran utilidad, por ejemplo, a la Gestión de Disponibilidad para conocer que CIs han sido responsables de la
degradación de la calidad del servicio.
Puede ser de gran utilidad para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del
ciclo de vida de las componentes, organizados por diferentes filtros (tipo, fabricante, responsable, costes, etc.).
Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de , digamos, los
switches instalados a la hora de adoptar decisiones de compra de nuevo material:
La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de
componentes para mantener actualizada la CMDB.
El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse
actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el
software "en producción".
El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la
estructura TI de la organización.
Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de
hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB.
Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos
datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:
Una correcta Gestión de Configuraciones necesita la colaboración de toda la estructura TI para mantener actualizada
la información almacenada en la CMDB.
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Configuraciones, tanto para
conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la
infraestructura TI.
La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una "gran devoradora de
recursos" si se establecen criterios excesivamente ambiciosos. Por ello la dirección de "Cater Matters" ha decidido, en una
primera fase, limitar el alcance de la base de datos de configuraciones a los sistemas considerados críticos:
Para simplificar aún más la gestión se ha decido uniformizar las configuraciones en una serie de "configuraciones de
referencia" aplicables a los CIs arriba descritos.
Aunque esto ha supuesto una inversión inicial importante se ha considerado que sus ventajas eran obvias:
El haber optado por una serie de configuraciones estándar permite alcanzar un gran nivel de detalle sin necesidad de
realizar un esfuerzo desmedido por lo que se han registrado:
• Configuraciones de software:
o Sistemas operativos.
o Aplicaciones instaladas.
o Interdependencias: relaciones padre-hijo, propietarios,...
o Documentación asociada.
• Configuraciones de hardware:
o Servidores y estaciones de trabajo.
o Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,...
o Documentación y controladores asociados.
A su vez se han instalado herramientas de gestión que permiten la monitorización remota de todas esas configuraciones
y la realización de auditorías periódicas automatizadas.
Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no
sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamente de un cambio.
Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo
funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe
hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en
servicios y tecnologías desactualizados.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que,
si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en
todo momento la calidad y continuidad del servicio TI.
El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios
necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.
• Están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio TI.
• Están convenientemente registrados, clasificados y documentados.
• Han sido cuidadosamente testeados en un entorno de prueba.
• Se ven reflejados en la CMDB.
• Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto
funcionamiento tras su implementación.
La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:
• Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo
que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un
servicio o adaptarse a requisitos legales.
• No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la
información sobre los CIs en la CMDB.
• Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y
estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad.
• Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y
documentar adecuadamente el proceso.
• No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos
asociados.
• Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el
proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.
En el resto de este capítulo se utilizará con frecuencia el concepto de Gestor de Cambios y Consejo Asesor del
Cambio (CAB), por lo que resulta conveniente describir y diferenciar sus respectivas atribuciones:
• Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el último responsable
de todas las tareas asignadas a la Gestión de Cambios. En grandes organizaciones el Gestor de Cambios
puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas.
• Consejo Asesor de Cambios (CAB): es un órgano interno, presidido por el Gestor de Cambios,
formado principalmente por representantes de las principales áreas de la gestión de servicios TI. Sin embargo,
en algunos casos también puede incorporar:
o Consultores externos.
o Representantes de los colectivos de usuarios.
o Representantes de los principales proveedores de software y hardware.
El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de Configuraciones: todos los cambios
de CIs inventariados en la CMDB deben ser correctamente supervisados y registrados.
Al igual que a la hora de implementar la Gestión de Configuraciones se sugirió como medida simplificadora la creación
Estos protocolos de cambio estándar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestión
más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten periódicamente pueden
acordarse procedimientos estándar que no requiera la aprobación de la Gestión de Cambios en cada caso.
Independientemente de su origen el correcto registro inicial de una RFC requerirá, cuando menos, de los siguientes
datos:
• Fecha de recepción.
• Identificador único de la RFC.
• Identificador del error conocido asociado (dado el caso).
• Descripción del cambio propuesto:
o Motivación.
o Propósito.
o CIs involucrados.
o Estimación de recursos necesarios para la implementación.
o Tiempo estimado.
Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado
seguimiento del mismo desde su aprobación hasta la evaluación final y cierre.
La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:
Aceptación
Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si
se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos
de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la RFC debe ser devuelta al
departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha
RFC o para que pueda ser consecuentemente modificada.
La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrada
justificado su ulterior procesamiento.
Clasificación
Tras su aceptación se deben asignar a la RFC una prioridad y categoría dependiendo de la urgencia y el impacto de la
misma.
La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será el dato relevante
para establecer el calendario de cambios a realizar.
La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de
recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio.
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación que
incluyera, al menos, los siguientes niveles de prioridad:
• Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan
actualizar ciertos paquetes de software o se compre nuevo hardware, etc.
• Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de
más alta prioridad.
• Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que deterioran
apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su próxima reunión y adoptar las
medidas pertinentes que permitan una pronta solución.
• Urgente: es necesario resolver un problema que esta provocando una interrupción o deterioro grave del
servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que
trataremos de forma independiente.
Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro
cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar
tareas de asesoramiento.
Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas
interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en
cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de "back out" que
permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.
En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y
elaborar el FSC o calendario del cambio correspondiente.
En el caso de cambios que tengan un alto impacto debe también consultarse a la dirección pues pueden entrar en
consideración aspectos de carácter estratégico y de política general de la organización.
Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe
evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente
equivaldrían a un solo cambio. Esto tiene algunas ventajas:
Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente
la Gestión de Versiones, si lo es de supervisar y coordinar todo el proceso.
En la fase de desarrollo del cambio se deberá monitorizar el proceso para asegurar que:
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración
preliminar de los nuevos sistemas en lo que respecta a su:
• Funcionalidad.
• Usabilidad.
• Accesibilidad.
La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren
objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de
usuarios).
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de
Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y, dentro de lo posible,
hacerles participes del mismo:
Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del
mismo en la calidad del servicio y en la productividad de la organización.
Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y
toda la información se incluirá en la PIR asociada.
Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación
deficiente a veces resultan inevitables.
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto
involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que
la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia.
El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos
de validación de los cambios urgentes que pueden requerir:
Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los procesos asociados
sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a
posteriori.
Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que
dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambios futuros
incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de
referencia que cubran aspectos tales como:
• RFCs solicitados.
• Porcentaje de RFCs aceptados y aprobados.
• Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
• Tiempo medio del cambio dependiendo del impacto y la prioridad
• Número de cambios de emergencia realizados.
• Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
• Numero de back-outs con una detallada explicación de los mismos.
• Evaluaciones post-implementación.
• Porcentajes de cambios cerrados sin incidencias ulteriores.
• Incidencias asociadas a cambios realizados.
• Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº
de cambios aprobados por reunión, etc.
Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de la empresa para
gestionar tanto los pedidos como la cadena de suministro.
El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado
para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión de la Capacidad han
informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.
Por otro lado, la dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más
elevados niveles de servicio para incrementar su cuota de mercado.
Todo ello requiere un cambio sustancial en la estructura de software y hardware de los servicios de Internet y su
interconexión con el software de gestión interna de la organización (ERP).
Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión de Cambios que tiene
por objetivos:
Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la
Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de
Proyectos:
Tras la implementación del cambio y en colaboración con el "Soporte al Servicio" y la "Provisión del Servicio" la Gestión
de Cambios:
La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para
asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB de forma que
ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.
La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se
guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan
piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.
Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea
delicada la implementación de cualquier cambio.
La Gestión de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea específica de la Gestión
de Versiones el diseñar, poner a prueba e instalar en el entorno de producción los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de
Servicios TI.
Las principales dificultades con las que topa la Gestión de Versiones son:
• No existe una clara asignación de responsabilidades y/o la organización TI no acepta la figura dominante
de la Gestión de Versiones en todo el proceso de implementación del cambio.
• No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las
nuevas versiones de software y hardware.
• Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. Es habitual
que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobre todo cuando ésta no
ha sido la política tradicional de la misma.
• Se realizan cambios sin tener en cuenta a la Gestión de Versiones argumentado que estos sólo son
responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello.
• Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir
"ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última
versión estable.
• La implementación sincronizada de versiones en entornos altamente distribuidos.
Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno
de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.
Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique
unívocamente. El sistema universalmente aceptado es:
Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).
En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado.
• Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su
mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el
entorno de producción.
• Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no.
Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la
instalación si se han realizado las pruebas pertinentes.
DSL
La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el entorno TI. Esto incluye
no solo sistemas operativos y aplicaciones sino también controladores de dispositivos y documentación asociada.
La DSL debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en
caso de que se deban implementar los planes de back-out.
La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos.
DHS
El Depósito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de producción.
Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes se hallen registrados
en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Esto
es especialmente importante para los casos de versiones menores y de emergencia pues en el caso de lanzamientos de
gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso.
A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes
factores:
• Cómo puede afectar la nueva versión a otras áreas del entramado TI.
• Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.
• Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción.
• Qué planes de back-out son necesarios.
• Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo
sobre el servicio y la integridad del sistema TI.
• Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva
versión con garantías de éxito.
• Quiénes serán los responsables directos en las diferentes etapas del proceso
• Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén
puntualmente informados y puedan percibir la nueva versión como una mejora.
• Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos,
gradual, ...
• Cuál es la vida media útil esperada de la nueva versión.
• Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.
• Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva
versión.
La Gestión de Versiones es la encargada del diseño y construcción de las nuevas versiones siguiendo las pautas
marcadas en las RFCs correspondientes.
A veces el desarrollo se realizara "en la casa" y muchas otras requerirá la participación de proveedores externos. En este
segundo caso, la tarea de la Gestión de Versiones será la de asegurar que el paquete o paquetes de software o
hardware ofrecidos cumple las especificaciones detalladas en la RFC. Asimismo, la Gestión de Versiones será la
responsable de todo el proceso de configuración necesario.
El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación necesarios
para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:
Parte integrante del desarrollo lo componen los planes de back-out asociados. Estos tendrán que tomar en cuenta la
disponibilidad acordada con los clientes en los SLAs correspondientes.
Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producción una nueva
versión con razonables garantías de éxito.
Las pruebas no deben limitarse a una validación de carácter técnico (ausencia de errores) sino que también deben
realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple los requisitos establecidos y
es razonablemente usable (siempre existe una inevitable resistencia al cambio en los usuarios que debe ser tenida en
consideración).
Es importante que las pruebas incluyan los planes de back-out para asegurarnos que se podrá volver a la última versión
estable de una forma rápida, ordenada y sin perdidas de valiosa información.
La Gestión de Cambios será la encargada de dar la validación final a la versión para que se proceda a su instalación. Si
la versión no fuera aceptada se devolverá a la Gestión de Cambios para su reevaluación.
Llego el momento de la verdad: la distribución de la nueva versión, también conocida como rollout.
El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y
responsabilidades específicas. En particular los usuarios finales deben estar puntualmente informados del calendario de
lanzamiento y de cómo este puede afectar a sus actividades diarias.
• Los CIs que deben borrarse e instalarse y en que orden debe realizarse este proceso.
• Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.
• Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos
o parciales.
Tras la implementación, la Gestión de Versiones debe ser puntualmente informada por el Service Desk de los
comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser
analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas
correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano.
Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil
de la cadena.
Es inútil disponer de un sofisticado servicio TI si los usuarios , debido a una incompleta (in)formación, no se encuentran
en disposición de aprovechar sus ventajas.
• Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la
nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el
proceso.
• Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupo de
usuarios finales. Durante este proceso de prueba se documentarán y analizarán:
o La experiencia subjetiva de usuario.
o Los comentarios y sugerencias sobre usabilidad y funcionalidad. o Las dudas que hayan surgido
durante el uso de la nueva versión.
o La claridad de la documentación que se pondrá a disposición del usuario final.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de
referencia que cubran aspectos tales como:
La Gestión de Cambios ha aprobado (véase el caso práctico del capítulo anterior) un RFC que tiene como principales
objetivos:
La Gestión de Versiones es la encargada del proceso de desarrollo, compra, prueba y distribución de las nuevas versiones
de hardware y software asociadas. Para ello:
• En colaboración con las Gestiones de Capacidad y Disponibilidad evalúa las necesidades del nuevo
hardware y se encarga de su compra y configuración.
• Contacta con sus proveedores habituales de desarrollo web para establecer de forma precisa las
especificaciones del nuevo software y establecer un calendario de desarrollo.
• Duplica la estructura web: se compran nuevos servidores para que los antiguos puedan prestar servicio
permanentemente y estén dispuestos inmediatamente para el "back-out".
• Se crean scripts de traducción que permitan salvar los nuevos datos en la versión anterior para evitar su
perdida en caso de back-out.
• Se establece un calendario de pruebas con usuarios reales para que estos puedan probar y "aprobar" el
nuevo servicio.
• Se planifica un despliegue en dos fases:
I. Se implementa toda la estructura web pero los datos no se incorporan directamente en el ERP
de la empresa.
II. Se completa el proceso con la integración mediante WebServices de los pedidos web en el ERP.
• Se desarrolla un manual de usuario para la nueva versión y se crea una página FAQs en la web que
incluyen las dudas más frecuentes elevadas por los usuarios en la fase de pruebas.
• Se informa a los usuarios sobre la nueva versión y se avisa de posibles y cortas interrupciones del
servicio en la fecha de instalación.
• Se procede a la instalación de la nueva versión.
• Se guarda una copia maestra de todo el software en la DSL.
• Se actualiza la CMDB.
El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente.
La tecnología, al menos en lo que respecta a la gestión de servicios TI, no es un fin en sí misma sino un medio para
aportar valor a los usuarios y clientes.
La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de
negocio y todo ello a unos costes razonables.
La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidad de los servicios
TI ofrecidos.
La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidades y
expectativas del cliente y los costes de los servicios asociados, de forma que estos sean asumibles tanto por el cliente
como por la organización TI.
• Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente.
• Se facilita la comunicación con los clientes impidiendo los malentendidos sobre las características y
calidad de los servicios ofrecidos.
• Se establecen objetivos claros y metrizables.
• Se establecen claramente las responsabilidades respectivas de los clientes y proveedores del servicio.
• Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos de
actuación en caso de deterioro del servicio.
• La constante monitorización del servicio permite detectar los "eslabones más débiles de la cadena" para
su mejora.
• La gestión TI conoce y comprende los servicios ofrecidos lo que facilita los acuerdos con proveedores y
subcontratistas.
• El personal del Service Desk dispone de la documentación necesaria (SLAs, OLAs,etc.) para llevar una
relación fluida con clientes y proveedores.
• Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante
los clientes.
Lo que repercute a la larga en una mejora del servicio con la consecuente satisfacción de clientes y usuarios.
• No existe una buena comunicación con clientes y usuarios por lo que los SLAs acordados no recogen sus
necesidades reales.
• Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en
servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente.
• No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente.
• Los SLAs son excesivamente prolijos y técnicos incumpliendo así sus objetivos primordiales.
• No se dedican los recursos suficientes pues la dirección los considera como un gasto añadido y no como
parte integral del servicio ofrecido.
• Problemas de comunicación: no todos los usuarios conocen las características del servicio y los niveles de
calidad acordados.
• No se monitoriza adecuada y consistentemente el cumplimiento de los SLAs dificultando así la mejora de
la calidad del servicio.
• No existe en la organización un verdadero compromiso con la calidad del servicio TI ofrecido.
Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el cliente.
Catálogo de Servicios
El Catálogo de Servicios no es sólo una herramienta imprescindible a la hora de simplificar la comunicación con el cliente
sino que también puede ser una gran ayuda tanto a la organización interna como a la proyección exterior de la
organización TI.
• Describir los servicios ofrecidos de manera no técnica y comprensible para clientes y personal no
especializado.
El SLR constituye el elemento base para desarrollar el SLA y posibles OLAs correspondientes.
Hojas de Especificación
Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los
servicios ofrecidos al cliente.
Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de
calidad suficiente y determinar si es necesario el outsourcing de determinados procesos, sirviendo de documento de base
para la elaboración de los OLAs y UCs correspondientes.
En resumen, el SQP debe contener la información necesaria para que la organización TI conozca los procesos y
procedimientos involucrados en el suministro de los servicios prestados, asegurando que estos se alineen con los
procesos de negocio y mantengan unos niveles de calidad adecuados.
Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta
a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos
esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.
El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a
disposición de los gestores de los otros procesos TI.
• Planificación:
o Asignación de recursos.
o Elaboración de un catálogo de servicios.
o Desarrollo de SLAs tipo.
o Herramientas para la monitorización de la calidad del servicio.
o Análisis e identificación de las necesidades del cliente.
o Elaboración del los Requisitos de Nivel de servicio(SLR), Hojas de Especificación del Servicio y
Plan de Calidad del Servicio(SQP).
• Implementación de los Acuerdos de Nivel del Servicio:
o Negociación.
o Acuerdos de Nivel de Operación.
o Contratos de Soporte.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los
estamentos de la organización TI. Y, si esto no fuera ya de por sí una labor lo suficientemente compleja, resulta
imprescindible la colaboración activa de los clientes y usuarios de los servicios TI.
El objetivo primordial de la Gestión de Niveles de Servicio es definir, negociar y monitorizar la calidad de los servicios
TI ofrecidos. Si los servicios no se adecuan a las necesidades del cliente, la calidad de los mismos es deficiente o sus
costes son desproporcionados, tendremos clientes insatisfechos y la organización TI será responsable de las
consecuencias que se deriven de ello.
Todo el proceso de planificación previo debe estar orientado a dar respuestas a las siguiente preguntas:
La respuesta a cada una de estas preguntas debe darse en forma de documentos, algunos de carácter interno y otros
accesibles a los clientes, que pasamos a describir sucintamente a continuación.
En primer lugar la Gestión de Niveles de Servicio debe poner a disposición de toda la organización, pero en especial a
disposición del Service Desk y la fuerza de ventas un Catálogo de Servicios.
Este catálogo de servicios debe describir, en un lenguaje comprensible para los no expertos, los productos y servicios
ofrecidos junto a indicaciones generales del nivel de servicio ofrecido, tales como disponibilidad, tiempos de respuesta,
etc.
La elaboración de este Catálogo de Servicios puede resultar una tarea compleja pues es necesario alinear aspectos
técnicos con políticas de negocio pero es un documento imprescindible pues:
• Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades.
• Delimita las funciones y compromisos de la organización TI.
• Puede ser utilizado como herramienta de venta.
• Evita malentendidos entre los diferentes actores implicados en la prestación de servicios.
Sin embargo, en la mayoría de los casos, por muy detallado y completo que sea el Catálogo de Servicios, la complejidad
de los servicios ofrecidos requiere un largo y extenso periodo de negociación con el cliente.
Los resultados de esta interacción/negociación deben ser incorporados al documento de Requisitos de Nivel de Servicio
(SLR) que debe reflejar las necesidades del cliente y sus expectativas respecto a:
• Una descripción detallada, con todos los detalles técnicos necesarios, sobre como se prestará el servicio.
• Cuáles serán los indicadores internos de rendimiento y calidad del servicio.
• Cómo se implementará el servicio.
Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su
infraestructura, está información deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de acordarse con
el cliente y su responsables técnicos.
El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y
contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios.
En función de los requisitos plasmados en las Hojas de Especificación del Servicio se elabora un plan global que permita
asignar los recursos a la organización TI, establecer metas claras basadas en los indicadores de rendimiento elegidos y
asegurar que los niveles de calidad ofrecidos se adaptan a las necesidades de los clientes y a los compromisos asumidos
por la organización.
En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportuno externalizar parte de
los servicios el SQP servirá de documento guía para el establecimiento de los contratos con los proveedores externos.
La fase de planificación debe concluir con la elaboración y aceptación de los acuerdos necesarios para la prestación del
servicio.
Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de Operación y Contratos de Soporte.
Es conveniente estructurar los SLAs más complejos en diversos documentos de forma que cada grupo involucrado reciba
exclusivamente la información correspondiente al nivel en que se integra, ya sea en el lado del cliente como del
proveedor.
La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos entre los que se encuentran:
El OLA, por su naturaleza, involucra detalles sobre la prestación del servicio que deben ser opacos para el cliente pero
que resultan imprescindibles a la organización TI para su organización.
Contratos de Soporte
Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de
prestación de servicios.
Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los Contratos de Soporte deben
representar compromisos claros y perfectamente delimitados. A pesar de esta diferencia crucial, los UCs pueden
considerarse como una extensión "externa" de los OLAs en el sentido de que persiguen el mismo fin: organizar los
procesos y procedimientos necesarios para la correcta provisión del servicio.
El proceso de monitorización de los niveles de servicio es imprescindible si queremos mejorar progresivamente la calidad
del servicio ofrecido, su rentabilidad y la satisfacción de los clientes y usuarios.
La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la
organización como los relacionados con la percepción de los usuarios.
Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con anterioridad unos baremos de
calidad del servicio que han de servir de guía en la elaboración de los informes correspondientes.
Los informes de rendimiento elaborados deben cubrir factores clave tales como:
• Cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes
responsables de la degradación del servicio.
• Quejas, justificadas o no, de los clientes y usuarios.
• Utilización de la capacidad predefinida.
• Disponibilidad del servicio.
• Tiempos de respuesta.
• Costes reales del servicio ofrecido.
• Problemas detectados y cambios realizados para restaurar la calidad del servicio.
• Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OLAs.
La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de la calidad de
los servicios ofrecidos.
Esta revisión debe realizarse en base a parámetros objetivos y metrizables resultado de la experiencia previa, los SLAs
en vigencia y la evolución del Catálogo de Servicios.
Este proceso de revisión no debe limitarse a aquellos SLAs que por una razón u otra han sido incumplidos, aunque,
evidentemente, en estos casos sea inexcusable, sino que debe tener como objetivo mejorar y homogeneizar la calidad del
servicio.
El resultado de la revisión debe ser un Programa de Mejora del Servicio (SIP) que tome en cuenta factores tales como:
El SIP debe ser el documento base para negociar la renovación del SLA con el cliente y debe constituir un documento de
referencia para la gestión de otros procesos TI como la Gestión de Cambios, Gestión de Problemas, etc.
El objetivo de la Gestión de Niveles de Servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del
cliente pero esto no se puede llevar a cabo sin una buena gestión de los procesos involucrados.
La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Niveles de
Servicio y aporta información de vital importancia a otras áreas involucradas en el soporte y la provisión de los servicios
TI.
• Informes Estadísticos de Rendimiento: donde se detallen los SLAs, OLAs y UCs elaborados y el
nivel de cumplimiento de los mismos, costes promedio asociados al proceso, etc.
• Informes de Seguimiento: donde se especifiquen las acciones de monitorización realizadas, sus
resultados y el grado de satisfacción de los clientes con el servicio prestado.
• Planes de Mejora: donde se especifiquen las acciones propuestas para la mejora del servicio TI y el
impacto que estas han tenido en la calidad del servicio.
La dirección de "Cater Matters" ha decidido implementar una Gestión de Niveles de Servicio que adapte a las
necesidades de su organización los principios y recomendaciones de ITIL.
Para llevar a cabo esta tarea de la forma más eficiente posible se han determinado una serie de acciones iniciales que se
resumen en:
Su principal función es negociar y acordar, en representación de "Cater Matters", la provisión de servicios con los
clientes.
• Elaborar y mantener actualizado un catálogo de los servicios ofrecidos por "Cater Matters".
• Determinar la estructura general de los SLAs, OLAs y UCs.
• Negociar los SLAs, OLAs y UCs con clientes y proveedores
• Supervisar el cumplimiento de los acuerdos de provisión del servicio con clientes y proveedores.
• Mantener informados a la Dirección y la organización TI sobre el rendimiento de todo el proceso.
• Determinar los Planes de Mejora del Servicio que solucionen las deficiencias en la calidad de los servicios
prestados y/o adapten estos servicios a las nuevas necesidades de los clientes y a los últimos avances
tecnológicos.
• Interactuar con los otros procesos TI para asegurar que todos ellos reciben y aportan la información
necesaria para el óptimo funcionamiento de la organización.
• Particulares.
• Pequeñas empresas.
• Grandes corporaciones e instituciones y organismos públicos.
El objetivo del catálogo no es sólo dar a conocer los diferentes servicios sino mostrar claramente al (potencial) cliente
cuales son las diferencias entre las diferentes opciones de un mismo "servicio base".
Para ello se elabora un catálogo online que permite comparar las diferentes "versiones" y realizar una estimación
preliminar de los costes basándose en las diferentes opciones seleccionadas.
• Plazos de entrega.
• Disponibilidad del servicio (festivos, horarios nocturnos, etc.).
• Servicios auxiliares.
SLAs prototipo
A fin de evitar que la elaboración de los SLAs se convierta en una tarea excesivamente compleja y tediosa se desarrollan
plantillas para los diferentes tipos de servicios y clientes.
Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus
procesos de negocio es moneda corriente que no exista una conciencia real de los costes que esta tecnología supone.
El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costes asociados a los servicios TI de
forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos TI necesarios.
Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios no podrán evaluar el
retorno a la inversión ni podrán establecer planes consistentes de inversión tecnológica.
La Gestión Financiera de los Servicios Informáticos tiene como objetivo principal administrar de manera eficaz y
rentable los servicios y la organización TI.
Por regla general, a mayor calidad de los servicios mayor es su coste, por lo que es necesario evaluar cuidadosamente las
necesidades del cliente para que el balance entre ambos sea óptimo.
Los principales beneficios de una correcta Gestión Financiera de los Servicios Informáticos se resumen en:
Las principales dificultades a la hora de implementar la Gestión Financiera de los Servicios Informáticos se resumen
en:
• Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos
Categorías de coste
La clasificación de costes por servicio o producto puede realizarse en
virtud de uno a más criterios:
• Costes de capital: que proviene de la amortización del inmovilizado material o inversiones a largo
plazo.
• Costes de Operación: son los costes asociados al funcionamiento diario de la organización TI.
Tipos de coste
Es imprescindible distinguir entre los diferentes tipos de coste para diseñar una política de precios clara y consistente.
Los tipos de coste se subdividen a su vez en elementos de coste. El siguiente diagrama nos muestra una típica estructura
de tipos y elementos de coste para una organización TI:
• Presupuestos:
o Análisis de la situación financiera.
o Fijación de políticas financieras.
o Elaboración de presupuestos.
• Contabilidad:
o Identificación de los costes.
o Definición de elementos de coste.
o Monitorización de los costes.
• Fijación de precios:
o Elaboración de una política de fijación de precios.
o Establecimiento de tarifas por los servicios prestados o productos ofrecidos.
Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.
Los presupuestos realizados pueden tener diferentes horizontes temporales. Pueden ser a corto plazo, incluyendo los
costes de los servicios prestados en la actualidad, o resultar de una proyección sobre la evolución prevista del negocio en
dos o más años.
Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales:
Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI es necesario identificar
previamente todos los elementos de coste.
La estimación de los costes asociados a esos elementos no es siempre una tarea sencilla y a menudo influyen factores
externos que no se hallan bajo el control directo de la organización TI, como por ejemplo el aumento del precio de las
licencias del software, etc.
Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos al respecto para
evitar que se conviertan en papel mojado al menor vaivén del mercado.
En principio, la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada a otros
servicios o departamentos. Sin embargo, la complejidad de las interrelaciones TI dificulta el proceso cuando los
responsables de su contabilidad desconocen sus mecanismos básicos y la tecnología que los sustenta.
Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance un excesivo nivel de detalle
que lo encarezca más allá de lo razonable.
• Una correcta evaluación de los costes reales para su comparación con los presupuestados.
• Tomar decisiones de negocio basadas en los costes de los servicios.
• Evaluar la eficiencia financiera de cada uno de los servicios TI prestados.
• Facturar adecuadamente, si es de aplicación, los servicios TI.
Si se desea considerar a la organización TI como otra unidad de negocio es necesario conocer en detalle tanto sus costes
como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues el cliente es la propia
organización).
Es una de las actividades principales de la Gestión Financiera identificar los denominados elementos de coste que se
pueden clasificar de forma genérica en:
No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia organización, pero éste es un paso
esencial si buscamos que se utilice eficientemente la infraestructura TI.
Para que la organización TI pueda funcionar como una verdadera unidad de negocio es imprescindible tanto conocer los
costes reales de los servicios prestados como establecer una política de precios que, cuando menos, permita recuperar
los costes en los que se ha incurrido.
En primer lugar debe establecerse una política de fijación de precios. Existen múltiples opciones, entre ellas:
• Coste más margen: se establecen los costes totales del servicio y se les añade un margen de beneficios
(que puede ser del 0% para "clientes internos").
• Precio de mercado: se cobran los servicios en función de las tarifas vigentes en el mercado para
servicios de similar naturaleza.
• Precio negociado: se negocia directamente con el cliente cuál es el precio estipulado por los servicios.
• Precio flexible: que depende de la capacidad TI realmente utilizada y/o de los objetivos cumplidos.
Una vez determinada la política de fijación de precios se deben determinar las tarifas de los servicios en función de:
• La política elegida.
• Los servicios solicitados.
• Factores de escala y necesidades de disponibilidad.
• Los costes asociados.
• Los precios vigentes en el mercado.
En algunas ocasiones estas tarifas serán usadas para una facturación real mientras que en otras sólo se utilizarán de
referencia para evaluar el rendimiento teórico de la organización TI.
No es tarea de la Gestión Financiera de los Servicios TI sino de la Gestión de Niveles de Servicio negociar con los
clientes y elaborar el catálogo de servicios. Sin embargo, es recomendable que, en los aspectos económicos, su actividad
sea supervisada por la Gestión Financiera.
Para ello es necesario que exista una comunicación fluida y convenientemente estructurada entre ambos procesos.
Por un lado la Gestión de Niveles de Servicio debe proveer información a la Gestión Financiera sobre:
Sin una estrecha colaboración entre ambos procesos será imposible llegar a acuerdos que sean rentables y a su vez
satisfactorios para el cliente.
El responsable del proceso de Gestión Financiera no ha de ser de manera imprescindible un miembro de la organización
TI, es, sin embrago, imprescindible que disponga de ciertos conocimiento sobre los servicios TI y/o esté correctamente
asesorado por especialistas en todo lo referente a la tecnología.
Para poder evaluar la función de la Gestión Financiera es necesario establecer tanto unos criterios claros para evaluar
su éxito como unos indicadores de rendimiento específicos.
En lo que respecta a los indicadores de rendimiento, estos deben incluir métricas que permitan evaluar si:
La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Financiera según
los parámetros arriba descritos y aporta información de vital importancia a la organización en su conjunto.
• Resúmenes contables.
• Análisis de eficiencia de cada uno de los servicios TI.
• Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología.
• Planes de reducción de costes por servicio.
La organización TI de "Cater Matters" lleva prestando, desde hace años, servicios esenciales tanto a la propia
organización de la empresa como a los clientes externos de sus servicios de catering.
Sin embargo, hasta la fecha, los gastos TI no han sido contabilizados y presupuestados de manera específica y es, con
los datos disponibles en la actualidad, imposible conocer el impacto de los servicios TI en los costes de cada uno de los
servicios de catering prestados.
La gestión de "Cater Matters" quiere desarrollar una política de fijación de precios de los servicios TI que le permita
trasladar sus costes al usuario final del servicio de catering, en la misma medida que ya se hace con los costes de
transporte, materias primas, etc.
Para gestionar el proceso se ha nombrado a un sénior manager del departamento TI y a un miembro del departamento
financiero de la empresa como responsables del mismo.
• En colaboración con la Gestión de Configuraciones elaborar un listado de todos los CIs que intervienen
en la prestación de servicios directos a los clientes.
• Evaluar, prorrateando entre los diferentes servicios si esto fuera necesario, cuales son los costes
asociados al uso de los mismos: amortización, mantenimiento, fungibles, etc.
• Evaluar los costes de personal y los costes operativos.
• Estimar los costes de difícil asignación u ocultos asociados a los servicios TI.
• Evaluar los costes indirectos: instalaciones, costes administrativos, etc.
• Establecer estrictos criterios contables para la administración de los costes TI.
• Establecer una política de precios de coste adicional o "coste + margen".
Todas estas actividades buscan determinar con precisión los costes asociados a los servicios TI ya prestados y proponer
tarifas que sean trasladas a los clientes, ya sea directamente o incluidas en otras partidas de carácter general.
Pero los objetivos de una Gestión Financiera proactiva van más allá e incluyen una correcta planificación de gastos e
inversiones futuras. Para ello y en colaboración con la Gestión de Niveles de Servicio, Gestión de la Capacidad y
Gestión de la Disponibilidad se estudian:
La información recopilada servirá de base para la elaboración de los primeros "presupuestos anuales TI" elaborados por la
Gestión Financiera.
La Gestión de la Capacidad es la encargada de que todos los servicios TI se vean respaldados por una capacidad de
proceso y almacenamiento suficiente y correctamente dimensionada.
Sin una correcta Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizan inversiones
innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son
insuficientes con la consecuente degradación de la calidad del servicio.
• Asegurar que se cubren las necesidades de capacidad TI tanto presentes como futuras.
• Controlar el rendimiento de la infraestructura TI.
• Desarrollar planes de capacidad asociados a los niveles de servicio acordados.
• Gestionar y racionalizar la demanda de servicios TI.
Ambos escenarios son habituales y a menudo se pueden encontrar conviviendo en una misma organización: directivos,
clientes e informáticos deslumbrados por tecnologías que realmente no necesitan y adquieren pero que obvian
aplicaciones, equipos y servicios que realmente aumentarían la productividad en sus respectivos entornos de trabajo.
Una de las principales tareas de la Gestión de la Capacidad es la de matizar la percepción de que la "capacidad es
barata". Aunque el aumento de la capacidad puede requerir, en primera instancia, de modestos desembolsos, debido a la
reducción de costes en los equipos de hardware y aplicaciones informáticas, la administración y mantenimiento de
infraestructuras desproporcionadas puede resultar, a la larga, muy cara.
En resumen: se racionaliza la gestión de las compras y mantenimiento de los servicios TI con la consiguiente reducción
de costes e incremento en el rendimiento.
La implementación de una adecuada política de Gestión de la Capacidad también se encuentra con algunas serias
dificultades:
El proceso de Gestión de la Capacidad puede segmentarse en subprocesos que analizan las necesidades de capacidad
TI desde diferentes puntos de vista:
• Gestión de la Capacidad del Negocio: que centra su objeto de atención en las necesidades futuras de
usuarios y clientes.
• Gestión de la Capacidad del Servicio: que analiza el rendimiento de los servicios TI con el objetivo de
garantizar los niveles de servicio acordados.
• Gestión de la Capacidad de Recursos: que estudia tanto el uso de la infraestructura TI como sus
tendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizan eficazmente.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Plan de Capacidad
La elaboración del Plan de Capacidad es la tarea principal de la Gestión de Capacidad.
El Plan de Capacidad debe incluir información sobre los costes de la capacidad actual y prevista. Esta información es
indispensable para que la Gestión Financiera pueda elaborar los presupuestos y previsiones financieras de manera
realista.
Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o bianual es importante que se monitorice
su cumplimiento para adoptar medidas correctivas en cuanto se detecten desviaciones importantes del mismo.
Modelado y Benchmarking
Cuanto más compleja sea una infraestructura informática más difícil es prever las necesidades de capacidad futura. En
esos casos, es imprescindible realizar modelos y simulaciones sobre posibles escenarios de desarrollo futuro que
aseguren la correcta escalabilidad de las aplicaciones y hardware.
• Un simple análisis de tendencias que permita evaluar la carga de proceso esperada en la infraestructura
informática y escalar consecuentemente su capacidad actual.
• Realizar modelos y simulaciones sobre diferentes escenarios para llevar a cabo previsiones de carga y
repuesta de la infraestructura informática.
• Realizar benchmarks con prototipos reales para asegurar la capacidad y el rendimiento de la futura
infraestructura.
El correcto dimensionamiento requiere que la Gestión de la Capacidad disponga de información fiable sobre:
Es importante que la Gestión de la Capacidad participe en las primeras etapas de desarrollo de un producto, servicio o
definición de un SLA para asegurar que se dispondrá de la capacidad necesaria para llevar el proyecto a buen término.
Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicación debido a
expectativas injustificadas sobre la tecnología. Se puede caer en el equivoco de que los costes asociados a la capacidad
se limitan a la compra de mas servidores, o más espacio de almacenamiento, etcétera, olvidando que sistemas más
complejos implican uno mayores gastos de mantenimiento y administración, o ignorando los problemas que pueden
conllevar dichos cambios.
Monitorización
Su objetivo principal es asegurar que el
rendimiento de la infraestructura informática se
adecua a los requisitos de los SLAs.
Análisis y Evaluación
Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas tales como
petición de aumento de la capacidad o una mejor Gestión de la Demanda.
Optimización y cambios
Si se ha optado por solicitar un aumento de la capacidad se elevará una RFC a la Gestión de Cambios para que se
desencadene todo el proceso necesario para la implementación del cambio. La Gestión de la Capacidad prestará su
apoyo en todo el proceso y será corresponsable, junto a la Gestión de Cambios y Versiones de asegurar que el cambio
solicitado cumpla los objetivos previstos.
En el caso de que una simple racionalización de la demanda sea suficiente para solventar las posibles deficiencias o
incumplimientos de los SLAs será la propia Gestión de la Capacidad la responsable de gestionar ese subproceso.
Idealmente la CDB debe estar interrelacionada con la CMDB para que esta última ofrezca una imagen integral de los
sistemas y aplicaciones con información relativa a su capacidad. Esto no es óbice para que ambas bases de datos puedan
ser "físicamente independientes".
Aunque la Gestión de la Demanda debe formar parte de las actividades rutinarias de la Gestión de la Capacidad ésta
cobra especial relevancia cuando existen problemas de capacidad en la infraestructura TI.
El origen de los problemas que la Gestión de la Demanda debe subsanar a corto plazo incluyen:
La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios
críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma
eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda
actuar en consecuencia.
Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Un aumento de la capacidad
siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorización de la capacidad permite
reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo
plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad.
Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por la organización
se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicos asociados a procesos
automáticos (tales como campañas de marketing promocional, informes de rendimiento para clientes, etcétera). En la
mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio,
ahorrando a la organización una gravosa ampliación del ancho de banda.
Ahora bien, si el coste añadido por aumentar el ancho de banda es marginal, puede resultar más eficiente su contratación
directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en la optimización del sistema.
La Gestión de la Capacidad debe evaluar a priori, basandose en la experiencia y las tendencias del mercado, cuándo la
solución "más potente, más grande" es económicamente más rentable (teniendo en cuenta los costes indirectos) que un
análisis pormenorizado de la situación.
• El uso de recursos.
• Desviaciones de la capacidad real sobre la planificada.
• Análisis de tendencias en el uso de la capacidad.
• Métricas establecidas para el análisis de la capacidad y monitorización del rendimiento.
• Impacto en la calidad del servicio, disponibilidad y otros procesos TI.
El éxito de la Gestión de la Capacidad depende algunos indicadores clave entre los que se encuentran:
Hasta la fecha, la Gestión de las Capacidad de "Cater Matters" había sido reactiva, o en otras palabras el incremento o
redistribución de la capacidad se realizaba exclusivamente cuando aparecían los problemas.
Con el incremento de la importancia de los servicios TI, tanto para la organización de "Cater Matters" como para sus
clientes, la dirección de la empresa ha decidido implementar las mejores prácticas ITIL para la Gestión de la
Capacidad.
Para ello se ha nombrado un Gestor de la Capacidad que tiene como principales responsabilidades:
• Elaborar un Plan de Capacidad anual que se revisara trimestralmente frente a datos reales extraídos de
la monitorización del sistema y de las previsiones de negocio.
• Poblar la Base de Datos de la Capacidad (CDB) para que contenga toda la información relevante a la
capacidad.
• Proponer mejoras del servicio.
• Minimizar el número e impacto de futuros incidentes que degraden la calidad del servicio.
• Racionalizar el uso de la capacidad de la infraestructura TI.
• Disminuir los costes en infraestructura TI.
• Aumentar la productividad y satisfacción del cliente.
La Gestión de la Continuidad del Servicio se preocupa de impedir que una imprevista y grave interrupción de los
servicios TI, debido a desastres naturales u otras fuerzas de causa mayor, tenga consecuencias catastróficas para el
negocio.
La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamente procedimientos:
• Proactivos: que buscan impedir o minimizar las consecuencias de una grave interrupción del servicio.
• Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea posible (y recomendable) tras el
desastre.
La ITSCM requiere una implicación especial de los agentes involucrados pues sus beneficios sólo se perciben a largo
plazo, es costosa y carece de rentabilidad directa. Implementar la ITSCM es como contratar un seguro médico: cuesta
dinero, parece inútil mientras uno está sano y desearíamos nunca tener que utilizarlo, pero tarde o temprano nos
alegramos de haber sido previsores.
Los objetivos principales de la Gestión de la Continuidad de los Servicios TI (ITSCM) se resumen en:
Aunque, a priori, las políticas proactivas que prevean y limiten los efectos de un desastre sobre los servicios TI son
preferibles a las exclusivamente reactivas, es importante valorar los costes relativos y la incidencia real en la continuidad
del negocio para decantarse por una de ellas o por una sabia combinación de ambas.
Una correcta ITSCM debe formar parte integrante de la Gestión de Continuidad del Negocio (BCM) y debe estar a su
servicio. Los servicios TI no son sino una parte, aunque a menudo muy importante, del negocio en su conjunto y no tiene
mayor sentido que, por ejemplo, un sistema de pedidos online siga funcionando a la perfección tras un desastre si nos
resulta imposible suministrar la mercancía a nuestros clientes.
Es importante diferenciar entre desastres "de toda la vida", tales como incendios, inundaciones, etcétera, y desastres
"puramente informáticos", tales como los producidos por ataques distribuidos de denegación de servicio (DDOS), virus
informáticos, etcétera. Aunque es responsabilidad de la ITSCM prever los riesgos asociados en ambos casos y restaurar
el servicio TI con prontitud, es evidente que recae sobre la ITSCM una responsabilidad especial en el último caso pues:
Los principales beneficios de una correcta Gestión de la Continuidad del Servicio se resumen en:
Las principales dificultades a la hora de implementar la Gestión de la Continuidad del Servicio se resumen en:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
El primer paso necesario para desarrollar una Gestión de la Continuidad del Servicio coherente es establecer
claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política.
La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación
de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión.
La Gestión de la Continuidad del Servicio está abocada al fracaso sino se destina una cantidad de recursos
suficientes, tanto en el plano humano como de equipamiento (software y hardware). Su dimensión depende de su
alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa que no dispusiera de los recursos
correspondientes.
Una importante parte del esfuerzo debe destinarse a la formación del personal. Éste debe interiorizar su papel en
momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergencia no es el mejor
momento para estudiar documentación y manuales.
Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar determinar el impacto que una
interrupción de los servicios TI pueden tener en el negocio.
En la actualidad casi todas las empresas, grandes y pequeñas, dependen en mayor o menor medida de los servicios
informáticos, por lo que cabe esperar que un "apagón" de los servicios TI afecte a prácticamente todos los aspectos del
negocio. Sin embargo, es evidente que hay servicios TI estratégicos de cuya continuidad puede depender la
supervivencia del negocio y otros que "simplemente" aumentan la productividad de la fuerza comercial y de trabajo.
Cuanto mayor sea el impacto asociado a la interrupción de un determinado servicio mayor habrá de ser el esfuerzo
realizado en actividades de prevención. En aquellos casos en que la "solución puede esperar" se puede optar
exclusivamente por planes de recuperación.
Los servicios TI han de ser analizados por la ITSCM en función de diversos parámetros:
• Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos de
negocio.
• Compromisos adquiridos a través de los SLAs.
Dependiendo de estos factores se buscará un balance entre las actividades de prevención y recuperación teniendo en
cuenta sus respectivos costes financieros.
Sin conocer cuales son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar una política de
prevención y recuperación ante desastre mínimamente eficaz.
La Gestión de la Continuidad del Servicio debe enumerar y evaluar, dependiendo de su probabilidad e impacto, los
diferentes riesgos factores de riesgo. Para ello la ITSCM debe:
Gracias a los resultados de este detallado análisis se dispondrá de información suficiente para proponer diferentes
medidas de prevención y recuperación que se adapten a las necesidades reales del negocio.
La prevención frente a riesgos genéricos y poco probables puede ser muy cara y no estar siempre justificada, sin
embargo, las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas, de rápida
implementación y relativamente baratas.
Por ejemplo, si el riesgo de perdida de alimentación eléctrica es elevado debido, por ejemplo, a la localización geográfica
se puede optar por deslocalizar ciertos servicios TI a través de ISPs que dispongan de sistemas de generadores
redundantes o adquirir generadores que proporcionen la energía mínima necesaria para alimentar los CIs de los que
dependen los servicios más críticos, etcétera.
La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas, que eviten la interrupción de los
servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio en el menor tiempo posible.
Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención y recuperación que
ofrezcan las garantías necesarias a unos costes razonables.
Actividades preventivas
Las medidas preventivas requieren un detallado análisis previo de riesgos y vulnerabilidades. Algunos de ellos serán de
carácter general: incendios, desastres naturales, etcétera, mientras que otros tendrán un carácter estrictamente
informático: fallo de sistemas de almacenamiento, ataques de hackers, virus informáticos, etcétera.
La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con la Gestión de la
Continuidad del Negocio (BCM) y requieren medidas que implican a la infraestructura "física" de la organización.
La prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren especial atención de la ITSCM. En este
aspecto es esencial la estrecha colaboración con la Gestión de la Seguridad.
Los sistemas de protección habituales son los de "Fortaleza" que ofrecen protección perimetral a la infraestructura TI.
Aunque imprescindibles no se hallan exentos de sus propias dificultades pues aumentan la complejidad de la
infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades.
Actividades de recuperación
Tarde o temprano, por muy eficientes que seamos en nuestras actividades de prevención, será necesario poner en
marcha procedimientos de recuperación.
• "Cold standby": que requiere un emplazamiento alternativo en el que podamos reproducir en pocos
días nuestro entorno de producción y servicio. Esta opción es la adecuada si los planes de recuperación
estiman que la organización puede mantener sus niveles de servicio durante este periodo sin el apoyo de la
infraestructura TI.
• "Warm standby": que requiere un emplazamiento alternativo con sistemas activos diseñados para
recuperar los servicios críticos en un plazo de entre 24 y 72 horas.
• "Hot standby": que requiere un emplazamiento alternativo con una replicación continua de datos y con
todos los sistemas activos preparados para la inmediata sustitución de la estructura de producción. Ésta es
evidentemente la opción mas costosa y debe emplearse sólo en el caso de que la interrupción del servicio TI
tuviera inmediatas repercusiones comerciales.
Por supuesto, existe otra alternativa que consiste en hacer "poco o nada" y esperar que las aguas vuelvan naturalmente
a su cauce: una alternativa poco recomendable para alguien que esté hojeando este curso sobre ITIL y del que
suponemos que los servicios TI jugarán un papel importante en su organización :-)
Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidas unas estrategias de
prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con ese objetivo la Gestión de la
Continuidad del Servicio debe elaborar una serie de documentos entre los que se incluyen:
En principio los planes de gestión de emergencias deben tomar en cuenta aspectos tales como:
Plan de recuperación
Cuando la interrupción del servicio es inevitable llego el momento de poner en marcha los procedimientos de
recuperación.
Cuando se pone en marcha un plan de recuperación no hay espacio para la improvisación, cualquier decisión puede tener
graves consecuencias tanto en la percepción que de nosotros tengan nuestros clientes como en los costes asociados al
proceso.
Aunque pueda resultar paradójico, un "desastre" puede ser una buena oportunidad para demostrar a nuestros clientes la
solidez de nuestra organización TI y por tanto incrementar la confianza que tiene depositada en nosotros. Ya conocen el
dicho: "No hay mal que por bien no venga".
Una vez establecidas las políticas, estrategias y planes de prevención y recuperación es indispensable que estos no
queden en papel mojado y que la organización TI esté preparada para su correcta implementación.
Ello depende de dos factores clave: la correcta formación del personal involucrado y la continua monitorización y
evaluación de los planes para su adecuación a las necesidades reales del negocio.
Formación
Es inútil disponer de unos completos planes de prevención y recuperación si las personas que eventualmente deben
llevarlos a cabo no están familiarizados con los mismos.
Actualización y auditorías
Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los
requisitos de la organización en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los
planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación.
En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos procesos de actualización y
auditoria pueden establecerse de forma periódica.
La Gestión de Cambios juega un papel esencial en asegurar que los planes de recuperación y prevención estén
actualizados manteniendo informada a la ITSCM de los cambios realizados o previstos.
La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión que incluyan
información relevante para el resto de la organización TI.
Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio es mantener la "concentración".
Tras largos periodos en los que la prevención o, simple y llanamente, la suerte han impedido la existencia de graves
interrupciones del servicio se puede caer en un relajamiento que puede acarrear graves consecuencias.
Por esto es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial se diluyan y la
ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que "un desastre se convierta en
una catástrofe".
Pero si el control del proceso es importante en condiciones normales éste se vuelve crítico durante las situaciones de
crisis. La ITSCM debe garantizar:
La organización TI de "Cater Matters" carece de una Gestión de la Continuidad del Servicio que merezca ese nombre.
La gestión de "Cater Matters" es consciente de la importancia que tienen en la actualidad los servicios TI en toda su
cadena de producción y distribución y pretende corregir esa situación.
De entre todos los servicios TI, los asociados a la gestión de existencias, por estar compuestas de productos perecederos,
y los servicios online de pedidos son considerados de importancia estratégica por la dirección de la empresa. Por ello se
decide que en primera instancia la ITSCM debe garantizar la continuidad de dichos servicios en un plazo nunca superior a
las 8 horas mientras que se establecen objetivos menos ambiciosos para otros servicios.
Se asigna a un ejecutivo senior del departamento TI el papel de gestor del proceso y se le encarga coordinar todas las
actividades con la Gestión de la Continuidad del Negocio.
La Gestión de la Continuidad del Negocio ha firmado acuerdos de colaboración con otras empresas de catering para
suministros de emergencia que cubran los clientes más importantes:
La coordinación en estos casos requiere el desarrollo de módulos especiales que permitan exportar las bases de datos de
pedidos a formatos estándar de intercambio de datos para que estos puedan ser procesados por las otras organizaciones.
Por otro lado, se desarrolla una aplicación de gestión de emergencia de las existencias que permite administrar los
pedidos a los proveedores y preservar la integridad de las existencias dependiendo de su información de caducidad y del
impacto de la interrupción del negocio en las mismas.
Se establece asimismo:
Pero la Gestión de la Continuidad del Servicio no sólo debe aplicar medidas reactivas que mitiguen el impacto de una
eventual interrupción del servicio, entre sus obligaciones se encuentran la elaboración de unos planes de prevención que
eviten dichas situaciones.
• Contrata servicios de "housing" con un proveedor que dispone de conexiones con varios operadores al
"backbone de Internet" y asegura alimentación eléctrica interrumpida.
• Replica los sistemas críticos en diferentes localizaciones geográficas.
• Supervisa la política de back-ups de los servidores de datos.
• Instala sistemas de protección perimetral.
Nuestras vidas, tanto personales como profesionales, dependen cada vez más de la tecnología. Ésta nos permite acceder
a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñado hace unos pocos años.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestros proveedores
tecnológicos. Con frecuencia una oferta diferente sólo se encuentra a un par de clics de distancia.
Por otro lado, el rápido desarrollo tecnológico implica una constante renovación de equipos y servicios. Como proveedores
nos enfrentamos al reto de evolucionar sin apenas margen para el error pues nuestros sistemas han de encontrarse a
disposición del cliente prácticamente 24/7.
La Gestión de la Disponibilidad es responsable de optimizar y monitorizar los servicios TI para que estos funcionen
ininterrumpidamente y de manera fiable, cumpliendo los SLAs y todo ello a un coste razonable. La satisfacción del cliente
y la rentabilidad de los servicios TI dependen en gran medida de su éxito.
El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén disponibles y funcionen
correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor.
Los indicadores clave sobre los que se sustenta el proceso de Gestión de la Disponibilidad se resumen en:
• Disponibilidad: porcentaje de tiempo sobre el total acordado en que los servicios TI han sido accesibles
al usuario y han funcionado correctamente.
• Fiabilidad: medida del tiempo durante el cual los servicios han funcionado correctamente de forma
ininterrumpida.
• Mantenibilidad: capacidad de mantener el servicio operativo y recuperarlo en caso de interrupción.
• Capacidad de Servicio: determina la disponibilidad de los servicios internos y externos contratados y
su adecuación a los OLAs y UCs en vigor. Cuando un servicio TI es subcontratado en su totalidad la
disponibilidad y la capacidad de servicio son términos equivalentes.
La disponibilidad depende del correcto diseño de los servicios TI, la fiabilidad de los CIs involucrados, su correcto
mantenimiento y la calidad de los servicios internos y externos acordados.
Las principales dificultades con las que topa la Gestión de la Disponibilidad son:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de los SLAs.
La disponibilidad propuesta debe encontrase en línea tanto con los necesidades reales del negocio como con las
posibilidades de la organización TI.
Aunque en principio todos los clientes estarán de acuerdo con unas elevadas cotas de disponibilidad es importante
hacerles ver que una alta disponibilidad puede generar unos costes injustificados dadas sus necesidades reales. Quizá
unas pocas horas sin un determinado servicio pueden representar poco más allá de una pequeña inconveniencia mientras
que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la replicación de sistemas u
otras medidas igualmente costosas que no van a tener una repercusión real en la rentabilidad del negocio.
Para llevar a cabo eficientemente está tarea es necesario que la Gestión de la Disponibilidad:
La correcta planificación de la disponibilidad permite establecer unos niveles de disponibilidad adecuados tanto en lo que
respecta a las necesidades reales del negocio como a las posibilidades de la organización TI.
El documento que debe recoger los objetivos de disponibilidad presentes y futuros y que medidas son necesarias para su
cumplimiento es el Plan de Disponibilidad.
• La situación actual de disponibilidad de los servicios TI. Obviamente esta información debe ser
actualizada periódicamente.
• Herramientas para la monitorización de la disponibilidad.
• Métodos y técnicas de análisis a utilizar.
• Definiciones relevantes y precisas de las métricas a utilizar.
• Planes de mejora de la disponibilidad.
• Expectativas futuras de disponibilidad.
Es imprescindible que este plan proponga los cambios necesarios para que se cumplan los estándares previstos y
colabore con la Gestión de Cambios y la Gestión de Versiones en su implementación (en caso de ser aprobados, claro
está).
Para que este plan sea realista debe contar con la colaboración de los otros procesos TI involucrados.
Un diferente nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados o en las actividades
necesarias para suministrar un determinado servicio TI. Si éste se diseña sin tener en cuenta futuras necesidades de
disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo, incurriendo en costes adicionales
innecesarios.
Aunque hayamos realizado un correcto diseño de los servicios según el Plan de Disponibilidad y se hayan tomado
todas las medidas preventivas necesarias, tarde o temprano, nos habremos de enfrentar a interrupciones del servicio.
En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto indeseado sobre los niveles
de disponibilidad acordados.
Estas interrupciones programadas pueden afectar a la disponibilidad del servicio y por lo tanto han de ser
cuidadosamente planificadas para minimizar su impacto.
En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que ello sea posible, deben aprovecharse las
franjas horarias de inactividad para realizar las tareas que implican una degradación o interrupción del servicio.
• Consultar con el cliente en que franja horaria la interrupción del servicio afectará menos a sus
actividades de negocio.
• Informar con la antelación suficiente a todos los agentes implicados.
• Incorporar dicha información a los SLAs.
Seguridad
Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es una correcta Gestión de la
Seguridad.
Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del proceso.
Es tan importante determinar cuándo el servicio estará disponible como el "quién y cómo" va a utilizarlo. La
disponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra.
La monitorización de la disponibilidad del servicio y la elaboración de los informes correspondientes son dos de las
principales actividades de la Gestión de la Disponibilidad.
Desde el momento de la interrupción del servicio hasta su restitución o "tiempo de parada" el incidente pasa por distintas
fases que deben ser individualizadamente analizadas:
• Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo hasta que la organización
TI tiene constancia del mismo.
• Tiempo de respuesta: es el tiempo que transcurre desde la detección del problema hasta que se
realiza un registro y diagnóstico del incidente.
• Tiempo de reparación/recuperación: periodo de tiempo utilizado para reparar el fallo o encontrar un
"workaround" o solución temporal al mismo y devolver el sistema a la situación anterior a la interrupción del
servicio.
Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida de la
interrupción del servicio. El cliente debe conocer estas métricas y dar su conformidad a las mismas para evitar
malentendidos. En algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" y la interpretación
puede diferir entre proveedores y clientes, por lo tanto, estás métricas deben de poder expresarse en términos que el
cliente pueda entender.
Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y que debe poner a disposición del cliente
en los informes de disponibilidad correspondientes incluyen:
• Tiempo Medio de Parada (Downtime) : que es el tiempo promedio de duración de una interrupción
de servicio, e incluye el tiempo de detección, respuesta y resolución.
• Tiempo Medio entre Fallos (Uptime): es el tiempo medio durante el cual el servicio esta disponible sin
interrupciones.
• Tiempo Medio entre Incidentes: es el tiempo medio transcurrido entre incidentes que es igual a la
suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos. El Tiempo Medio entre Incidentes es una
medida de la fiabilidad del sistema.
Aunque llevamos hablando ya un buen rato de disponibilidad aún no hemos aportado un método para cuantificarla.
donde:
AST se corresponde con el tiempo acordado de servicio, DT es el tiempo de interrupción del servicio durante las franjas
horarias de disponibilidad acordadas.
Por ejemplo, si el servicio es 24/7 y en el último mes el sistema ha estado caído durante 4 horas por tareas de
mantenimiento la disponibilidad real del servicio fue:
La Gestión de la Disponibilidad tiene a su disposición un buen número de métodos y técnicas que le permiten
determinar que factores intervienen en la disponibilidad del servicio y que le permiten consecuentemente prever que tipo
de recursos se deben asignar para las labores de prevención, mantenimiento y recuperación, así como elaborar planes de
mejora a partir de dichos análisis.
CFIA
Que son las siglas de Component Failure Impact Analysis (Análisis del Impacto de Fallo de Componentes).
Mediante esté método se identifica el impacto que tiene en la disponibilidad de los servicios TI el fallo de cada elemento
de configuración involucrado. Es evidente que este método requiere una CMDB correctamente actualizada.
FTA
Que son las siglas de Failure Tree Analysis (Análisis del Árbol de Fallos).
Su objetivo es estudiar cómo se "propagan" los fallos a través de la infraestructura TI para comprender mejor su impacto
en la disponibilidad del servicio.
CRAMM
Que son las siglas de CCTA Risk Analysis and Management Method (Método de Gestión y Análisis de Riesgos de la CCTA).
Su objetivo es identificar los riesgos y vulnerabilidades a los que se haya expuesta la infraestructura TI con el objetivo de
adoptar contramedidas que los reduzcan o que permitan recuperar rápidamente el servicio en caso de interrupción del
mismo.
SOA
Que son las siglas de Service Outage Analysis (Análisis de Interrupción del Servicio).
Ésta técnica tiene como objetivo analizar las causas de los fallos detectados y proponer soluciones a los mismos.
Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente haciendo especial
Gestión de la Disponibilidad
Control del Proceso
La Gestión de la Disponibilidad debe elaborar periódicamente informes sobre su gestión que incluyan información
relevante tanto para los clientes como para el resto de la organización TI.
Para que toda esta información sea fácil y correctamente analizada es imprescindible el establecimiento de métricas
precisas que permitan determinar de forma inequívoca parámetros tales como tiempos de parada y funcionamiento. Por
ejemplo, en el caso de un servicio online de comercio electrónico se puede considerar que tiempos de respuesta
superiores a 10 segundos son equivalentes a que el sistema esta caído, aunque estrictamente hablando el sistema
termine respondiendo.
La disponibilidad 12/7 es algo a lo que los clientes de "Cater Matters" otorgan una gran importancia.
Los servicios TI sólo juegan una pequeña, aunque importante, parte en los servicios prestados por la organización a sus
clientes y los problemas de disponibilidad suelen proceder de procesos no directamente ligados con la tecnología. Sin
embargo, una interrupción de los servicios online pueden presuponer un grave problema dado el alto volumen de pedidos
que se reciben por dicho canal, la práctica totalidad, así como su importancia en el apartado de la gestión de stocks de
materia prima.
La Gestión de la Disponibilidad, en colaboración con los responsables de otros procesos TI ha sido encargada de
elaborar nuevos planes de disponibilidad que tengan en cuenta un rápido crecimiento del negocio que puede implicar una
disponibilidad 24/7 para diferentes líneas de negocio.
Por otro lado, la gestión de "Cater Matters" ha decidido informar periódicamente a sus clientes sobre los niveles de
rendimiento y disponibilidad de los diferentes servicios prestados. Para ello ha encargado a la Gestión de la
Disponibilidad que implante los procedimientos necesarios para la medición del:
Que se complementarán con un módulo de cálculo estadístico y de generación automática de informes sobre el
cumplimiento de los niveles de disponibilidad acordados para cada cliente.
De esta forma "Cater Matters" busca entablar una relación de confianza con sus clientes y mantener a la organización TI
alerta sobre posibles degradaciones de los niveles de calidad del servicio.
Sin embargo, desde el advenimiento de las ubicuas redes de comunicación y en especial Internet los problemas asociados
a la seguridad de la información se han agravado considerablemente y nos afectan prácticamente a todos. Que levante la
mano el que no haya sido víctima de algún virus informático en su ordenador, del spam (ya sea por correo electrónico o
teléfono) por una deficiente protección de sus datos personales o, aún peor, del robo del número de su tarjeta de crédito.
La información es consustancial al negocio y su correcta gestión debe apoyarse en tres pilares fundamentales:
La Gestión de la Seguridad debe, por tanto, velar por que la información sea correcta y completa, esté siempre a
disposición del negocio y sea utilizada sólo por aquellos que tienen autorización para hacerlo.
• Diseñar una política de seguridad, en colaboración con clientes y proveedores correctamente alineada
con las necesidades del negocio.
• Asegurar el cumplimiento de los estándares de seguridad acordados.
• Minimizar los riesgos de seguridad que amenacen la continuidad del servicio.
La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de "expertos en seguridad" que desconocen los
otros procesos de negocio. Si caemos en la tentación de establecer la seguridad como una prioridad en sí misma
limitaremos las oportunidades de negocio que nos ofrece el flujo de información entre los diferentes agentes implicados y
la apertura de nuevas redes y canales de comunicación.
La Gestión de la Seguridad debe conocer en profundidad el negocio y los servicios que presta la organización TI para
establecer protocolos de seguridad que aseguren que la información esté accesible cuando se necesita por aquellos que
tengan autorización para utilizarla.
Una vez comprendidos cuales son los requisitos de seguridad del negocio, la Gestión de la Seguridad debe supervisar
que estos se hallen convenientemente plasmados en los SLAs correspondientes para, a renglón seguido, garantizar su
cumplimiento.
La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos generales a los que está expuesta la
infraestructura TI, y que no necesariamente tienen porque figurar en un SLA, para asegurar, en la medida de lo posible,
que no representan un peligro para la continuidad del servicio.
Es importante que la Gestión de la Seguridad sea proactiva y evalúe a priori los riesgos de seguridad que pueden
suponer los cambios realizados en la infraestructura, nuevas líneas de negocio, etcétera.
• Se evitan interrupciones del servicio causadas por virus, ataques informáticos, etcétera.
• Se minimiza el número de incidentes.
• Se tiene acceso a la información cuando se necesita y se preserva la integridad de los datos.
• Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios.
• Se cumplen los reglamentos sobre protección de datos.
• Mejora la percepción y confianza de clientes y usuarios en lo que respecta a la calidad del servicio.
La Gestión de la Seguridad esta estrechamente relacionada con prácticamente todos los otros procesos TI y necesita
para su éxito la colaboración de toda la organización.
Para que esa colaboración sea eficaz es necesario que la Gestión de la Seguridad:
• Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos.
• Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados tanto en los servicios
prestados a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos.
• Implemente el Plan de Seguridad.
• Monitorice y evalúe el cumplimiento de dicho plan.
• Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y
vulnerabilidades.
• Realice periódicamente auditorías de seguridad.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a la Gestión de la
Seguridad. Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos
tales como los objetivos, responsabilidades y recursos.
Plan de Seguridad
El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos como parte de los SLAs,
OLAs y UCs.
Este plan ha de ser desarrollado en colaboración con la Gestión de Niveles de Servicio que es la responsable en última
instancia tanto de la calidad del servicio prestado a los clientes como la del servicio recibido por la propia organización TI
y los proveedores externos.
El Plan de Seguridad debe diseñarse para ofrecer un mejor y más seguro servicio al cliente y nunca como un obstáculo
para el desarrollo de sus actividades de negocio.
Siempre que sea posible deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad
acordados.
Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes en todas las
fases del servicio y para todos los estamentos implicados. "Una cadena es tan resistente como el más débil de sus
eslabones", por lo que carece de sentido, por ejemplo, establecer una estrictas normas de acceso si una aplicación tiene
vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante algún tiempo
ofreciendo la imagen de "fortaleza" pero esto valdrá de poco si alguien descubre que la "puerta de atrás está abierta".
Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica.
• El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al
respecto.
• Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad.
• Se imparte la formación pertinente.
Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión de la Seguridad respecto a todas estas
cuestiones y que incluso permita que ésta proponga medidas disciplinarias vinculantes cuando los empleados u otro
personal relacionado con la seguridad de los servicios incumpla con sus responsabilidades.
Evaluación
No es posible mejorar aquello que no se conoce, es por la tanto indispensable evaluar el cumplimiento de las medidas de
seguridad, sus resultados y el cumplimiento de los SLAs.
Aunque no es imprescindible, es recomendable que estas evaluaciones se complementen con auditorías de seguridad
externas y/o internas realizadas por personal independiente de la Gestión de la Seguridad.
Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que se plasmaran en RFCs
que habrán de ser evaluados por la Gestión de Cambios.
Independientemente de estas evaluaciones de carácter periódico se deberán generar informes independientes cada vez
que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo considera
oportuno, estos informes se acompañaran de las RFCs correspondientes.
Mantenimiento
La Gestión de la Seguridad es un proceso continuo y se han de mantener al día el Plan de Seguridad y las secciones
de seguridad de los SLAs.
Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluación arriba citada o de cambios
implementados en la infraestructura o servicios TI.
No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas.
Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y
vulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte las medidas
necesarias de actualización de equipos de hardware y software, sin olvidar el apartado de formación: el factor humano es
normalmente el eslabón más débil de la cadena.
Al igual que en el resto de procesos TI es necesario realizar un riguroso control del proceso para asegurar que la Gestión
de la Seguridad cumple sus objetivos.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridad y aporta información de
vital importancia a otras áreas de la infraestructura TI.
• Informes sobre el cumplimiento, en lo todo lo referente al apartado de seguridad, de los SLAs, OLAs y
UCs en vigor.
• Relación de incidentes relacionados con la seguridad calificados por su impacto sobre la calidad del
servicio.
• Evaluación de los programas de formación impartidos y sus resultados.
• Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI.
• Auditorías de seguridad.
• Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos.
La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en el concepto de
"fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información actualizada sobre sus pedidos, pagos
pendientes, etcétera y eso requiere la interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse canales al exterior desde el
núcleo TI de la organización.
La dirección de "Cater Matters" ha decidido crear una serie de Web Services que permitan el acceso a dicha información
preservando su confidencialidad e integridad. Esto requiere la revisión del Plan de Seguridad y las secciones de
seguridad de los SLAs en vigor.
• Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs autorizadas de clientes podrán
disponer del servicio.
• Se implementan protocolos de encriptación de los archivos XML intercambiados.
• Se requiere autenticación para el acceso al servicio.
• Se monitoriza la interacción con la aplicación para detectar posibles ataques externos.
• Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
• Se autoriza un solo canal de entrada a los servidores locales a través de los servidores web de la
empresa.
Se propone una evaluación periódica del servicio con el objetivo de detectar vulnerabilidades y adoptar medidas
correctivas.
El objetivo es dar un servicio de calidad y con altos niveles de seguridad que fidelice a los clientes en un tiempo de rápido
desarrollo en el que la competencia se encuentra a un "solo clic de distancia".