ITIL V3 Foundation

ITIL® V3 Foundation. Fundamentos de ITIL®

1


Unidad 1: ¿Qué es ITIL®?

Índice

1.1. Introducción a ITIL®

1.2. Servicio

1.3. Gestión de Servicios

1.4. Gestión de Servicios TI

1.5. Modelo de Madurez: Estándar ISO/IEC 20000

1.6. ¿A quién afecta la Gestión de Servicios TI?

1.7. Buenas prácticas

1.8. Clientes internos y externos

1.9. Servicios internos y externos

1.10. Sistemas, Funciones y Procesos

1.11. La librería ITIL®

1.12. Ventajas e inconvenientes.


2

1.1. Introducción a ITIL®

¿Qué es ITIL®?

¿Qué es ITIL®? Esta es la primera pregunta que surgirá en tu primera toma de contacto. Tras

buscar información en diferentes fuentes seguramente deberá preguntar “pero… ¿qué es

ITIL®?”. Si continúas con una azarosa búsqueda, sin confiar en los mejores profesionales,

puede que esta pregunta se convierta en crónica e ITIL® parezca más un problema que una

solución.

En este curso resolveremos esta pregunta y otras cuestiones relacionadas. Te mostraremos la

estructura de ITIL®, sus objetivos y las ventajas de emplear esta gran librería de “buenas

prácticas” en tu organización. Y las recomendaciones de ITIL® se convertirán en tu gran aliado

para el éxito.

Introducción a ITIL®

Las empresas y profesionales que trabajan hoy en día con las más novedosas Tecnologías de

Información, encuentran una infinidad de problemas para conseguir sus objetivos.

Es difícil diseñar una aplicación carente de errores, gestionar un conjunto de proveedores o

manejar un equipo de trabajo de forma eficaz, si previamente no se establecen unas pautas

bien definidas y documentadas.

Estas afirmaciones, sin embargo, son mucho más fáciles de cuestionar que de llevar a cabo.

Distintos estándares, un mercado en constante evolución, políticas internas de cada

institución… son elementos que dificultan la buena predisposición a los proyectos

estructurados.

Aquí es cuando surge ITIL®: La Biblioteca de Infraestructura de Tecnologías de Información

(Information Technology Infrastructure Library).

Introducción a ITIL®. La librería.

Descripción: Y cuál es exactamente la función de esta ‘Librería’? Agrupar los mejores

procedimientos de gestión para que las organizaciones puedan usarlos como marcos de

trabajo, y que su implantación posibilite la mejora de la calidad y de las operaciones de TI. Los

procedimientos desarrollados en ITIL® son independientes del proveedor y cada empresa será

la encargada de usarlos como guía para sus propios fines.


3

Descripción informal: ITIL® es un manual de buenas prácticas, recopiladas entre los mejores

procedimientos contrastados del mercado y que sirven de guía para la mejora de la calidad en

las organizaciones.

Nota

ITIL® fue originalmente un producto de la Agencia Central de TeleComunicaciones (CCTA

del gobierno británico), y, desde 2001 propiedad del Ministerio de Comercio (OGC). Aunque

la Versión 2 fue la que alcanzó mayor grado de desarrollo y de popularidad en el mercado,

en este curso nos centraremos en la Versión 3, que ha sido mejorada y condensada.

1.2. Servicio

Servicio: Utilidad y Garantía

Si un término es indispensable para el entendimiento de ITIL®, no es otro que los servicios.

Definición: Un Servicio es un medio para entregar valor a los clientes, facilitando los

resultados que los clientes quieren conseguir sin asumir costes o riesgos específicos

Por tanto, en adelante debemos diferenciar claramente Servicio y procesos, tareas, fases,

objetivos, y otros términos que pueden dar lugar a confusión. Los servicios son elementos

completos, que no disponen de limitaciones económicas o técnicas y cuya consecución puede

requerir de múltiples tareas o procesos diferenciados.

Cada servicio además lleva asociado un Valor, compuesto por dos elementos:

Utilidad: La finalidad o funcionalidad utilidad de un servicio para un cliente.

Garantía: La forma en que se proporciona esa funcionalidad, y que ITIL® trata de

estandarizar para obtener un alto nivel de calidad.


4

Tipos de Servicio

Los servicios son un elemento esencial en el negocio de una empresa. Por tanto, pueden

clasificarse de diversas formas.

La más habitual (orientada al negocio) es crear una Línea de Servicio, donde se evalúen en

función de su utilidad o desuso. Así indicamos:

Servicios populares Los servicios más demandados y con mayor interés para el

negocio.

Servicios viables Los servicios que son asumibles en la actualidad

Servicios a eliminar progresivamente Servicios obsoletos o duplicados

Sin embargo, esto no supone una clasificación como tal. Para organizarlos y preparar una

estrategia adecuada para cada uno, se diferencian según sus características o utilidad (lo que

denominamos Arquetipos de servicio), lo que en definitiva aportará un Valor concreto al

cliente:

Líneas de Servicio Arquetipos de servicio

Servicios de alquiler Alquilar, Licenciar, Proporcionar

Servicios gestionados Gestionar, Operar, Mantener

Servicios de corrección Recuperar, Resolver, Reparar

Servicios de custodia Almacenar, Proteger, Monitorizar

Servicios de administración Procesar, Gestionar, Registrar

Servicios de evaluación Analizar, Evaluar, Auditar

Servicios de transformación Modificar, Transformar, Transportar

Servicios de creación Diseñar, Desarrollar, Adaptar

Servicios de comunicación Conectar, Integrar

Definición ITIL®: Una Línea de Servicio (LOS) es un servicio esencial o de soporte con

múltiples Paquetes del Nivel de Servicio. Está controlada por un gestor de producto y cada

Paquete del Nivel de Servicio está diseñado para un segmento concreto del mercado.


5

1.3 Gestión de Servicios

Gestión de Servicios

Para lograr estos valores para los clientes mediante la buena organización de Servicios, ITIL®

define Gestión de Servicios como:

Definición: La Gestión de Servicios es un conjunto de capacidades organizativas

especializadas cuyo fin es generar valor para los clientes en forma de servicios.

Entre las características principales que debe cumplir un buen sistema de Gestión de servicios

se encuentran:

Especialización y coordinación: El proveedor de servicios gestiona los recursos y se

encarga de la coordinación en lugar del cliente.

Principio de agencia: La gestión de servicios siempre conlleva la creación de un

intermediario o agente, normalmente del proveedor de servicios, que facilita las tareas

como interlocutor.

Encapsulación: El cliente sólo conocerá la información vital, sin necesidad de conocer

los detalles. El proveedor le ofrece Modularidad (estructura clara), Acoplamiento

flexible (independencia de recursos y usuarios) y Separación de conceptos.

1.4. Gestión de Servicios TI

Gestión de Servicios TI

Dentro de la Gestión de Servicios, podemos diferenciar un apartado especializado en TI y que

denominamos Gestión de Servicios TI.

Las necesidades de la gestión de TI se han visto incrementadas sobremanera (debido al

aumento de la información, de la importancia de la misma y de los diversos soportes y

modelos para tratarla), por lo que se implantó una ISO de calidad ISO / IEC 20000. Este modelo

se establece como un estándar para todas las organizaciones encargadas de la Gestión de

Servicios TI, y se encarga de la definición, gestión y diseño de procesos.


6

Como puede observarse en este gráfico, este modelo cubre todos los aspectos de gestión

inicial (requisitos), la planificación de las actividades (Planificación e implementación) y una

concisa descripción de los procesos implicados en todo el ciclo de la Gestión de Servicios TI.

Gobierno TI & Gestión de Servicios TI

Es conveniente diferenciar entre la Gestión de Servicios, que tiene relación con la toma de

decisiones y la implementación de los procesos, y el Gobierno del Servicio, cuya misión es

adoptar una serie de decisiones correctas.

Definición de Van Grembergen: El Gobierno de TI consiste en un completo marco de

estructuras, procesos y mecanismos relacionales. Las estructuras implican la existencia de

funciones de responsabilidad, como los ejecutivos y responsables de las cuentas de TI, así

como diversos Comités de TI. Los procesos se refieren a la monitorización y a la toma de

decisiones estratégicas de TI. Los mecanismos relacionales incluyen las alianzas y la

participación de la empresa/organización de TI, el diálogo en la estrategia y el aprendizaje

compartido.

Para poder derivar en esas decisiones se recomienda:


7

Crear un organismo de Gobierno para garantizar que las decisiones adoptadas son

correctas.

Segmentar o subdividir entre tipos de Gobierno específicos para determinadas

decisiones, como la gestión de contratos, provisión de servicios o comunicación.

Crear matrices de toma de decisiones, como la enormemente extendida del modelo

RACI (ver unidad 6).

Por tanto, la Gestión de Servicios TI se encuadra dentro de la Gestión de Servicios, mientras

que el Gobierno de TI está relacionado con la Gestión de la Información o de la propia

empresa.

1.5. Modelo de Madurez: Estándar ISO/IEC 20000

Modelo de Madurez (CMMI)

El propósito de ITIL® es alcanzar el mayor grado de calidad en todo el sistema de procesos

necesarios para los objetivos de una empresa. Para ello, es recomendable empaparse de las

mejores prácticas constatadas hasta la fecha, y utilizar un modelo maduro de los existentes en

el mercado.

En concreto, en el sector TI, el ciclo de mejora de madurez de procesos se denomina Modelo

de Madurez de la Capacidad Integrado (CMMI). Se trata de un modelo continuo y por etapas.

Modelo Continuo

Modelo continuo: El modelo CMMI se subdivide en distintos niveles de capacidad, que

representan las características de los procesos para alcanzar una mejora. Junto con los

Procesos incompletos y los Procesos realizados, se subdivide en estos niveles:

1. Proceso gestionado (Nivel de capacidad 1): Un proceso ejecutado que cuenta con

la infraestructura básica para su soporte.

2. Proceso definido (Nivel de capacidad 2): Adaptación de un conjunto de procesos

estándar a las directrices de una organización, y que proporciona información de mejora

diversa, como la organización de productos y medidas.

3. Proceso gestionado cuantitativamente (Nivel de capacidad 3): Un proceso que se

controla mediante estadísticas y otras técnicas cuantitativas.

4. Proceso en optimización (Nivel de capacidad 4): Un proceso gestionado

cuantitativamente y mejorado gracias a información de las causas comunes del

proceso.


8

Modelo por etapas

Modelo por etapas: Se definen 5 etapas para identificar los distintos grados de madurez

de los procesos.

1. Inicial: Procesos concretos y sin ningún orden.

2. Gestionado: Procesos planificados y ejecutados según las directrices de la

organización.

3. Definido: Procesos bien caracterizados y documentados. Se describen en

estándares, procedimientos, herramientas y métodos.

4. Gestionado cuantitativamente: Además de bien estructurados, la organización

establece objetivos cuantitativos de calidad y rendimiento de procesos y los utilizan

como criterios para la gestión de procesos.

5. Optimización: Se añaden mejoras paulatinas a los procesos y a la tecnología que se

emplea, para mejorar el rendimiento.

La relación entre Proveedor y Cliente

Para alcanzar un alto nivel de madurez, es recomendable emplear un sistema de calidad

certificado como la serie ISO 9000, y en particular para organizaciones de Gestión de Servicios

TI el ISO en concreto ISO/IEC 20000.

Nota

Es importante tener en cuenta los diferentes niveles de madurez entre clientes y

proveedores, para gestionar mejor los procesos.

Mediante un sistema de calidad adecuado, estableceremos una correcta relación entre el

Proveedor (y especialmente el Proveedor de Servicios TI) y Cliente. El Proveedor dispondrá de

una serie de servicios, y el cliente hará uso de los mismos.

Proveedor Es el responsable de suministrar bienes o Servicios que son necesarios para

proporcionar Servicios de TI. Por ejemplo vendedores de Software, de Hardware, proveedores

de telecomunicación, etc.

Cliente Es la persona o grupo que compra bienes y servicios proporcionados por un

proveedor. El cliente de un Proveedor TI es quien acuerda el Objetivo del Nivel de Servicio.


9

Contrato La relación principal entre el Cliente y el Proveedor se establece mediante un

Contrato, o acuerdo legal entre ambas partes. ITIL® además denomina dos tipos de contrato

de forma especial:

Contrato de Servicio: Acuerdo Legal o SLA (Ver unidad 4) para la entrega de un

Servicio de TI.

Contrato de Soporte: Contrato entre un Proveedor de TI y un tercero, que a su vez

proporciona el servicio al cliente.

1.6. ¿A quién afecta la Gestión de Servicios TI?

¿A quién afecta la Gestión de Servicios TI?

Sin embargo, todos estos conceptos relacionados con los Servicios, pueden resultar algo

volátiles para algunos usuarios que no se vean directamente afectados en un sistema de

Gestión de servicios. Sin embargo, todos los miembros de la organización deben estar

implicados en mayor o menor medida. Veamos algunos de los componentes de una o varias

unidades de negocio y la implicación que pueden tener en la Gestión de Servicios.

Clientes Los clientes intermedios o finales de cualquier unidad de negocio tienen la

necesidad de obtener determinados servicios de forma eficiente. Son, por

consiguiente, el usuario más interesado en una óptima gestión del servicio.

Dueños Los dueños del servicio verán reflejada la satisfacción de sus clientes en

forma de nuevos servicios o la apreciación económica de los mismos.

Empleados Cuando un empleado disponga de la información y formación

adecuada, además de la delimitación de sus funciones y una buena metodología de

comunicación con las distintas unidades de negocio, mejorará de forma perceptible los

resultados de su trabajo.

Partners o Asociados Los Partners o Asociados de la organización obtendrán

mayor retorno de su inversión, y podrán contribuir de forma sencilla a la mejora

continua de los servicios proporcionados o en los que colaboran para ofrecer.

Inversores Los accionistas e inversores podrán observar de forma transparente los

servicios del negocio, por lo que su confianza aumentará notablemente. Por supuesto,

obviamos las mejoras económicas que obtendrá el proveedor de servicios TI.

Auditores Podrán revisar las buenas prácticas empleadas, y comprobar fielmente

los hitos de todas ellas.

Como puedes ver, hemos mostrado algunos de los grupos, entidades o usuarios que se verán

afectados por una correcta Gestión de Servicio TI. Aunque podemos concluir que todos los

usuarios-entidades que tengan alguna relación con nuestro negocio se verán afectados de

forma positiva, e incluso podremos establecer tablas donde se enlacen a todos los implicados

y si son los que provocan cambios, los controlan o se ven afectados por ellos.


10

1.7. Buenas prácticas

Buenas prácticas

Aunque ITIL® se presenta ante los profesionales de TI como un estándar de Buenas prácticas,

no se debe incurrir en el error de pensar que se trata de una guía que debe seguirse paso a

paso.

Algunos ejemplos de Buenas prácticas son los estándares, los marcos de trabajo, y el

conocimiento acumulado y contrastado de organizaciones e individuos.

Un ejemplo de marcos de trabajo probados son:

CMMI (Capability Maturity Model Integration) Modelo para la mejora y evaluación

de procesos para el desarrollo, mantenimiento y operación de sistemas de software

COBIT (Control Objectives for Information and related Technology) Metodología

para la gestión de información.

PRINCE2. (Projects in Controlled Environments) Metodología de gestión de

proyectos, que cubre la administración, control y gestión del proyecto.

Estándares recomendados

Algunos estándares recomendados son:

ISO/IEC 20000 (International Organization for Standardization/International Electro

technical Commission)

ISO 9000 (International Organization for Standardization)

Es importante adaptar las necesidades concretas de una empresa a estas buenas prácticas,

para aprovechar la ventaja de los estándares y no caer en los errores habituales provocados

por situaciones puntuales.


11

1.8. Clientes internos y externos

Clientes internos y externos

Y ¿Por qué la necesidad de estas ‘buenas prácticas’? La razón es muy sencilla, con el empleo de

buenas prácticas se lograrán mejorar los servicios que se ofrecen a los clientes, y por tanto, su

satisfacción será más probable.

No hay que confundir el término Cliente orientado al negocio con su acepción genérica (el

ordenador de un usuario, una aplicación cliente-servidor o incluso a veces un simple usuario).

Un cliente es:

Definición ITIL®: Cliente. Aquel que compra bienes o servicios en un negocio. Por

consiguiente, el cliente de un Proveedor de Servicios TI es la persona o entidad que define y

acuerda el Objetivo de Nivel de Servicio.

Atendiendo a esta definición, podemos diferenciar entre dos tipos de cliente:

Cliente interno Es el cliente que trabaja para el mismo negocio que el proveedor del

Servicio TI.

Cliente externo Es un cliente que trabaja en un negocio distinto al del proveedor del

servicio TI.


12

1.9. Servicios internos y externos

Servicios internos y externos. Proveedores de Servicios TI

Cuando una organización presta servicios al menos a un cliente lo denominamos Proveedor de

Servicios TI o simplemente Proveedor de Servicios. En una empresa pequeña, este concepto

puede resultar bastante sencillo, ya que la mayoría de servicios se centralizan en ella, y los que

no es capaz de soportar, se externalizan.

Para poder diferenciar el tipo de servicio que puede ofrecer una empresa, como unidad de

negocio (o agrupaciones de unidades de negocio) en cada caso, diferenciaremos en primer

lugar al propio proveedor de servicios. Existen tres tipos de Proveedor de Servicios TI:

Proveedor de Servicios de Tipo I: Proveedor interno de servicios Pueden

existir uno o varios de estos proveedores dentro de una organización. Un proveedor de

Servicios de Tipo I es aquel que está integrado dentro de una Unidad de Negocio, y por

tanto, ayudan a conseguir fácilmente beneficios a esa UN.

Estos proveedores ofrecen las ventajas de cercanía al cliente, menores riesgos y costes

más bajos, pero el inconveniente de la limitación para el crecimiento de la organización.

Proveedor de Servicios de Tipo II: Unidad de servicios compartidos (SSU) En

este caso, estos proveedores proporcionan servicios TI a más de una Unidad de

Negocio. También son proveedores internos, pero que adoptan las mejores prácticas

del sector y optimizan su operativa para obtener mayor competitividad.

Esto permite precios más bajos, mayor maniobrabilidad e incluso la posibilidad de

estandarizar acciones en varias unidades de negocio. Sin embargo, el conjunto de

provisiones de servicio queda totalmente trasparente al cliente, que puede preferir a

otro proveedor.


13

Proveedor de Servicios de Tipo III: Proveedor externo de servicios Se trata de

un proveedor que proporciona Servicios a clientes externos. Se utilizan en entornos de

negocio que necesitan cierta flexibilidad para dar servicio a los clientes.

Las posibilidades para los clientes aumentan, ya que pueden diversificar entre

diferentes proveedores y obtener mayor cantidad-calidad de servicios. Sin embargo

aumentan los riesgos para el negocio y pueden aparecer costes adicionales.


14

Por tanto, como podemos observar, no sólo son importantes los proveedores de servicios de

tipo III para proporcionar servicios a clientes externos. También son de extrema importancia

los proveedores de tipo I y II para satisfacer los servicios internos y las necesidades de

diferentes unidades de Negocio.

Definición ITIL®: Unidad de Negocio (UN): Segmento del Negocio que tiene sus propios

Planes, Métricas, ingresos y Costes. Cada Unidad de Negocio posee Activos y los usa para crear

valor para sus Clientes en forma de bienes y Servicios

1.10. Sistemas, Funciones y Procesos

Sistemas, Funciones y Procesos

Aunque hemos introducido el concepto de Servicio, aún no nos hemos detenido en el de

Proceso. Es importante también este aspecto, puesto que gran parte de ITIL® desarrolla

gestiones de procesos estandarizados. Para ahondar en ello, antes demos afianzar otros

términos, como Sistema.

Definición: Sistema. Un sistema es un grupo de componentes interrelacionados o

interdependientes que forman un conjunto unificado y que funcionan juntos para conseguir un

objetivo común.

Una organización, una función, un proceso, incluso el ciclo de vida de un servicio son

diferentes sistemas. Cuando están bien diseñados deben retroalimentarse para conseguir los

objetivos de una forma más eficiente y aprender de los resultados que obtenga.

Definición: Función. Una función es una subdivisión de una organización que está

especializada en realizar un tipo concreto de trabajo y tiene la responsabilidad de obtener

resultados concretos. Las funciones son subdivisiones independientes que tienen las

capacidades y recursos necesarios para alcanzar los resultados exigidos. Tienen sus propias

prácticas y su propio cuerpo de conocimientos.

Un ejemplo de función sería el sistema de facturación de una empresa al final de mes.


15

Definición: Proceso. Un proceso es un conjunto estructurado de actividades diseñado para

cumplir un objetivo concreto. Los procesos dan como resultado un cambio orientado hacia un

objetivo y utilizan la retroalimentación para efectuar acciones de automejora y autocorrección.

Un ejemplo de proceso, podría ser la recopilación de horas extra mensuales, que serán

utilizadas en la función de facturación y en la función de compensación de horas laborales.

Como puede verse, función es algo más genérico, persigue un objetivo concreto, mientras que

proceso es un conjunto de acciones que pueden emplearse en una o más funciones.

1.11. La Librería ITIL®

La librería ITIL®. Gestión de Servicios TI.

ITIL®, en su versión actual (la versión 3), organiza su información en base a la gestión de

servicios según el Ciclo de Vida de un Servicio. Detalla la forma en que se estructura la gestión

del servicio, los componentes relacionados y los efectos de alterar dichos componentes.

Para lograr la mejor calidad en los objetivos de una organización, sea del tipo que sea ésta, el

ciclo de vida se divide en cinco fases, que aglutinan los procesos necesarios en cada una de

ellas:

1. Estrategia del Servicio (SS): En esta fase inicial se diseña la estrategia necesaria para

alcanzar unos objetivos. Es importante en ella recopilar la mayor cantidad de

información posible.

2. Diseño del Servicio (DS): En la segunda fase, se concretará el diseño más adecuado

para cada organización. Se definirá la arquitectura, la documentación, los procesos y

los requisitos asociados, con una visión que abarque tanto al presente de la empresa

como a su futuro.

3. Transición del Servicio (TS): Se mejoran los aspectos creados en la fase de diseño, para

optimizarlos y emplearlos en modo de producción.

4. Operación del Servicio (OS): En esta fase se efectúa la provisión del servicio y el

soporte al cliente. Deben conseguirse los objetivos esperados y generarse valor para el

cliente.

5. Mejora Continua del Servicio (CSI): Esta fase retorna de nuevo a la Operación del

servicio, para optimizar los resultados obtenidos, modificando procesos, añadiendo

algunos nuevos y deduciendo (y eliminando) errores previos.


16

La librería ITIL®. Ciclo de vida del Servicio.

La librería de ITIL® se basa sobre todo en los cinco manuales correspondientes a estas cinco

fases del Ciclo de vida. También se complementa con otras publicaciones como ‘Quía de

introducción’, ‘Guías sobre elementos claves’, ‘Ayudas para la cualificación’, “White Papers” y

un detallado Glosario, con las definiciones estandarizadas bajo el manto de ITIL®.

1.12. Ventajas e inconvenientes

Ventajas de ITIL®

Emplear ITIL® conlleva numerosas ventajas, por lo que es recomendable tenerlas siempre bien

presente a la hora de decidir si se ha de dar forma a las mejores prácticas que recomienda en

los servicios ofrecidos. Todas ellas incrementarán el valor del servicio ofrecido por el

proveedor:

Organización: La organización se clarifica y se estructura mejor. Se permite así

distribuir responsabilidades, asignar recursos y externalizar elementos de los servicios

TI cuando sea necesario.


17

Calidad: El uso de ITIL® proporciona un acercamiento a los sistemas de calidad

estándar ISO/IEC 20000 e ISO 9000, lo que conlleva una garantía en la consecución de

objetivos.

Normalización: Gracias a una buena organización y el empleo de los estándares de

calidad, podremos normalizar los procedimientos empleados. Se eliminarán los

superfluos o ineficientes y se añadirán los de nueva creación que sean necesarios.

Y, por consiguiente, el cliente o el usuario de los servicios también se verán beneficiado de

estas ventajas:

Calidad-Precio: El coste será menor, y sin embargo la disponibilidad y calidad del

servicio será mucho más alta.

Enfoque: Los servicios estarán más enfocados a las necesidades del cliente e

incorporarán detalles específicos para lograr los objetivos concretos.

Comunicación: Existirá una buena comunicación entre cliente y proveedor, lo que se

reflejará en todos los aspectos del proyecto común.

Inconvenientes de ITIL®

Hay que tener también en cuenta que hay que cuestionar ciertos inconvenientes a la hora de

adoptar las propuestas de ITIL®:

Recursos: Introducir ITIL implica consumir recursos temporales y económicos. Es

conveniente implantarlo de forma paulatina, con una serie de plazos. Y por supuesto,

es necesaria una inversión en tecnología y formación para lograr la cohesión de

recursos.

Estructura: Aunque no existe una estructura estándar para todas las organizaciones,

sí hay casos funcionales previos que pueden tomarse como plantillas y que facilitarán

la estructuración y control de procesos. El objetivo debe ser claro y los procesos

independientes (aunque conectados), si no es así, puede perderse la visión del

objetivo del servicio.

Información: Adaptarse a ITIL® requiere un alto grado de información. Es necesario

un análisis inicial y ciertas estadísticas de partida, es más que conveniente una

documentación asociada a cada proceso, e indispensable la información, formación y

cooperación de todos los integrantes de la organización.


1


Unidad 2: Ciclo de Vida del Servicio

Índice

2.1. Introducción

2.2. Ciclo de Vida del Servicio

2.3. Estrategia del Servicio ITIL® (SS)

2.4. Diseño del Servicio (DS).

2.5. Transición del Servicio (TS)

2.6. Operación del Servicio (OS)

2.7. Mejora Continua del Servicio (CSI)


2

2.1. Introducción

Introducción al Ciclo de Vida del Servicio

Si el corazón de ITIL® es el Servicio que se desea ofrecer y la Gestión del Servicio el envoltorio

con las características que rodean al mismo, el Ciclo de Vida del Servicio representa la forma

en que se consigue aplicar todas las buenas prácticas enumeradas en ITIL®.

El Ciclo de Vida del Servicio ha quedado establecido en la versión 3 como cinco fases bien

diferenciadas entre sí, aunque complementarias. En esta unidad, trataremos de estudiarlo con

mayor detenimiento.

2.2 Ciclo de Vida del Servicio

Ciclo de Vida del Servicio

El Ciclo de Vida del Servicio es un modelo organizativo que ofrece información relevante del

servicio. En concreto debe proporcionar:

Información del propio servicio y sus características.

La estructura de gestión del servicio

Las fases para completar la ejecución del servicio y cómo se relacionan entre sí.

El efecto, cambios y soluciones, al modificar algún elemento del Ciclo.

Por tanto, en el ciclo de vida, se expandirá la información de los procesos, componentes y

todos los elementos de la Gestión de Servicios.

Recuerda

La versión 3 de ITIL® divide el Ciclo de Vida del

Servicio en 5 fases:

1. Estrategia del Servicio.

2. Diseño del Servicio.

3. Transición del Servicio.

4. Operación del Servicio.

5. Mejora Continua del Servicio.


3

2.3 Estrategia del Servicio de ITIL® (SS)

(SS) Estrategia del Servicio. Objetivo

La Estrategia del Servicio, es el centro del Ciclo de Vida. En esta fase confluyen todos los

aspectos relevantes del servicio.

Cada fase del Ciclo de Vida del Servicio se diferencia de las otras por el objetivo que persigue

cumplir principalmente, y en qué momento temporal debe abarcarse. En este caso, la

Estrategia del Servicio pretende identificar los elementos diferenciadores de nuestro servicio

para conseguir el mejor rendimiento del mercado. Es importante fijar unos objetivos claros y:

Tener un enfoque claro del mercado, para saber quiénes son nuestros competidores y

cómo actuar.

Distinguirse de la competencia, mediante características de mayor calidad que la

competencia.

Crear una estructura basada en el rendimiento, gracias a la medición de resultados y

una mejora continua de la estrategia inicial.

ITIL® propone una estrategia de trabajo y una planificación de recursos, pero no se trata de

una manual que haya que implantar sino una serie de recomendaciones con alto rendimiento

contrastado con anterioridad.

(SS) Las cuatro “P” de la Estrategia del Servicio

Los proveedores de servicio, cuando entiendan los factores en juego para establecer la

estrategia, y una vez queden claros, tener en cuenta que la estrategia se compone de “Las

cuatro P”:

Nota

No confundir “Las cuatro P de la SS” con “Las cuatro P del DS o cuatro P de ITIL®” que

veremos en la unidad 3.

Perspectiva: La estrategia como perspectiva define las convicciones, los valores y los

objetivos por los que se rige toda la organización. Una perspectiva estratégica determina

la dirección tomada por el proveedor de servicios para alcanzar sus objetivos.

Es decir, la perspectiva define los servicios del proveedor y la relación con el cliente. Se

centra en el enfoque y la misión de la organización.


4

Posición: La estrategia como posición define las características propias del proveedor de

servicios a los ojos del cliente.

Aunque nuestra organización puede tener una perspectiva clara de las posibilidades que

ofrece, es mucho más importante conocer la posición, o lo que opina el cliente al

respecto. Normalmente las perspectiva de una organización alcanza cotas más altas (para

llegar a diferentes clientes) que la posición que adopta para tratar con un cliente

concreto.

Así existen distintos posicionamientos:

Posicionamiento basado en la diversidad: Un catálogo de servicios concreto, que

se ofrece a diferentes clientes de necesidades similares.

Posicionamiento basado en la necesidad: Un catálogo de servicios más extenso,

pero que se ofrece a un tipo de cliente con ciertas características concretas.

Posicionamiento basado en la accesibilidad: Un catálogo especializado según

ciertas necesidades concretas (como ubicación o escala).

Por tanto, una organización debe adoptar una posición, sea cual sea su perspectiva.

Plan: La estrategia como plan se centra en el plan de acción de la organización en un

mercado competitivo. La Gestión del Servicio es un conjunto de planes coordinados a

través del cual los proveedores de servicios planifican e implementan estrategias de

servicio.

Las organizaciones deben tener un plan de acción, de contingencia ante errores, de actividades

adicionales, etc. Es decir, deben tener y documentar de forma clara sus objetivos.

Patrón: La estrategia como patrón representa los procedimientos de una organización.

Como consecuencia de la perspectiva, la posición y el plan de la estrategia, se crean

patrones característicos que llevan a éxitos recurrentes.

A lo largo del tiempo, la organización debe mantener esas acciones y actividades. Si se

modifican, implica directamente un cambio en la estrategia.

En resumen, ITIL® expone una serie de propuestas para establecer una buena estrategia, y

dicha estrategia debe quedar clara y ser mejorada a lo largo del Ciclo de Vida mediante una

revisión constante. Así no solamente se alcanzarán los objetivos, sino que se lograrán de una

forma óptima.


5

2.4 Diseño del Servicio (DS)

(DS) Diseño del Servicio. Objetivo

El Diseño del Servicio es la siguiente fase tras tener bien definida una estrategia organizativa.

Incluye no sólo el diseño de nuevos Servicios, sino también la modificación de los que han sido

creados con anterioridad.

En esta fase se buscará un equilibrio entre la funcionalidad y la gestión de recursos, por lo que

es indispensable la captación de los requisitos necesarios para el Servicio. La clave del Diseño

del Servicio es la información y la buena distribución de la misma entre todos los recursos

existentes, tanto materiales como personales.

El objetivo del Diseño del servicio es la consecución de los objetivos del negocio para satisfacer

las necesidades actuales y futuras, mientras se ahorra tiempo y dinero. Por tanto, como

objetivo secundario pretende minimizar los riesgos y crear estándares que eleven la calidad de

los servicios TI que se ofrecen.

(DS) Elementos del Diseño

Para realizar un buen diseño, es imprescindible conocer cinco aspectos fundamentales:

1. Solución del Servicio Representa todos los requisitos necesarios para el Servicio;

Los funcionales y los recursos asociados.

2. Cartera de Servicios Todo el sistema necesario para ejecutar los servicios junto con

el catálogo de los mismos, en el Diseño del Servicio son especialmente importantes las

herramientas para la creación.

3. Arquitectura Estructura de gestión y tecnológica necesaria para los Servicios.

4. Procesos Todos los procesos y características empleados en los Servicios.

5. Métricas y sistemas de medición Estándares y documentación asociada.

En la siguiente unidad los detallaremos con mayor profundidad.

El Diseño del Servicio puede desarrollarse de diversas formas, pero es necesario mantener el

catálogo de Servicios siempre actualizados. La Gestión del Servicio de Negocio (BSM) permite

aumentar la productividad, facilitar la gestión y sincronización de actividades TI, definir

prioridades y en definitiva aumentar la calidad del servicio (con la consecuente satisfacción del

cliente).


6

2.5 Transición del Servicio (TS)

(TS) Transición del Servicio

La Transición del Servicio se centra en las modificaciones, y cómo dar al cliente el soporte

necesario para el proceso de cambio. Se basa en la coordinación y gestión de procesos

necesarios para la construcción (y posterior despliegue con sus pruebas asociadas) de una

nueva versión del Servicio en producción.

Por tanto, según la propia definición y finalidad de la Transición del Servicio, es importante

seguir una secuencia de pasos.

Planificación: Es muy importante planificar la actividad a ejecutar, para establecer un

calendario y márgenes de error.

Construcción: Es necesario definir los aspectos relacionados con la construcción del

Servicio.

Pilotos: En la mayoría de los casos, es conveniente la creación de un piloto de Servicio,

es muy útil para detectar problemas o falta de conocimiento de requisitos.

Pruebas: Haya o no un piloto, es necesario probar la construcción realizada, para la

detección de fallos.

Preparación del despliegue: Preparar el servicio para el despliegue en producción. En

ocasiones son necesarios requisitos diferentes a desarrollo.

Despliegue: Desplegar el servicio en un esquema de producción.

Revisión y cierre: Una vez se haya contrastado la buena transición, cerrarla y pasar a la

siguiente fase.

(TS) Transición del Servicio. Objetivo

Si realizamos una buena Transición del Servicio, daremos soporte al cliente en el proceso de

cambio, minimizaremos el impacto de los servicios en producción, y en general reduciremos

los errores conocidos para aumentar la satisfacción del cliente.

Pero, ¿realmente es tan importante la Transición del Servicio? ¿Por qué no pasar directamente

desde el Diseño a la Operación y así ahorrar tiempo? Si pensásemos así estaríamos cayendo en

un grave error, pues esta fase del Ciclo de Vida es imprescindible para ahorrar costes en el

Servicio final y obtener una mayor productividad, debido principalmente a que los valores

reales no siempre coinciden con las especificaciones.


7

2.6 Operación del Servicio (OS)

(OS) Operación del Servicio

Finalizados los procesos de las fases previas, llega el momento de esquematizar la que organiza

la ejecución de los Servicios: La Operación del Servicio.

Esta fase es tal vez la más conocida en la mayoría de las organizaciones, puesto que se encarga

de ‘cómo’ llevar a cabo la prestación del servicio. Sin embargo, insistimos en recordar que

hemos mostrado tres fases ineludibles anteriores, con objetivos específicos, y cuyo sub-

objetivo sería el facilitar esta Operación.

(OS) Los procesos de la OS. Objetivo

En definitiva, la Operación del servicio tiene como objetivo principal conseguir procesos y

actividades eficientes, y para lograrlo se centra principalmente en estos procesos:

Gestión de Eventos Debe tener en cuenta todos los eventos posibles, sin dejar

ninguno al azar. Si así ocurriera, podría escapar algún proceso a nuestro control.

Gestión de Incidencias Cuando, cómo y por quien deben ser resueltas las

incidencias? Al igual que sucede con los eventos, deben ser previstas con antelación.

Gestión de Peticiones El Ciclo de Vida del Servicio pretende gestionar de forma

eficiente un servicio. Por tanto, es imprescindible fijar el inicio del mismo.

Gestión de Problemas Todas las peticiones llevarán asociados una serie de

problemas (salvo raras ocasiones). Es necesario establecer roles y prioridades de

solución.

Gestión de Accesos Permisos y accesos asignados a los servicios.

Monitorización Todas las actividades, informes y estadísticas que rodean al Servicio.

No son acciones adicionales, sino complementarias e imprescindibles para la siguiente

fase del Ciclo de Vida.

Operaciones de TI Las funciones que deben realizar los procesos, tecnologías y

personas.


8

(OS) Ámbito de la Operación del Servicio

De forma periódica deben recopilarse los datos de las actividades y del rendimiento diario de

estos elementos:

Los servicios El centro de atención del Ciclo de Vida del Servicio no puede desligarse

de su unidad central, los servicios. Cuáles son, hacia quién están generados por el

proveedor, y si son necesarios nuevos servicios.

Los procesos de Gestión del Servicio Cómo se efectúan los Servicios, y los resultados

que están obteniendo los procesos relacionados.

La tecnología Software, Hardware y elementos mecánicos o documentales que

sirven de soporte para la Operación del Servicio.

Las personas En último lugar, pero no por ello lo menos importante. Es

imprescindible realizar el seguimiento, atender sugerencias, formar e informar a todos

los participantes de un proyecto. La comunicación entre las personas es un elemento

vital para alcanzar los objetivos.

(OS) Funciones y Roles

Una Operación del Servicio eficaz se logra con un equipo de trabajo bien compenetrado, con

roles y funciones bien definidas. Es por tanto tener bien claros algunos conceptos cuando los

usemos:

Grupo Personas que realizan actividades similares.

Equipo Grupo con un objetivo común en un proyecto, aunque los componentes

estén en diferentes estructuras organizativas.

Departamento Una subdivisión organizativa creada para realizar alguna/s

actividades concretas.

División Agrupación de varios departamentos según su zona geográfica, productos o

línea de negocio.

Rol En todos los departamentos y equipos, es necesario que cada persona tenga un

determinado rol, o comportamiento, responsabilidades, y actividades concretas

asignadas a esa persona. En ocasiones el rol también se asigna a un grupo de personas

y no a un individuo.

Función Un conjunto de actividades y procesos que deben ser realizadas en un Ciclo

de Vida de forma automatizada o manual.


9

2.7 Mejora Continua del Servicio (CSI)

(CSI) Mejora Continua del Servicio

La Mejora Continua del Servicio es una fase especial con un objetivo muy concreto: Mejorar de

forma continuada la eficacia y eficiencia de los servicios de TI con el fin de lograr los objetivos

establecidos al comenzar con el menor coste posible.

En cierto modo, podría denominarse como Segunda parte de Operación del Servicio, pues

además de comenzar al finalizar OS, retorna de forma periódica a esta fase para optimizar los

resultados alcanzados.

Esto se logra realizando un análisis exhaustivo de los procesos, y en la mayoría de ocasiones,

automatizando procesos o eliminando acciones innecesarias o duplicadas.

(CSI) Modelo de Deming

Para llevar a cabo una buena CSI, debemos implantar un modelo que gestione cada uno de los

pasos necesarios. Uno de los más utilizados en la actualidad es el de W. Edwards Deming, que

propone un diagrama con una serie de pasos para la mejora del Ciclo de Vida, en cuatro pasos

bien diferenciados: Planificar, Implementar, Monitorizar y Ajustar.

Planificar CSI

Determinar la calidad general de la gestión TI.

Determinar las necesidades presentes y futuras del negocio.

Ajustar la Cartera de Servicios de forma continua.

Revisar la madurez de los servicios de TI.

Determinar los requisitos, acciones intermedias y objetivos finales.

Determinar las comprobaciones que se deben ejecutar durante la fase de verificación.

Determinar los interfaces entre CSI y el resto del Ciclo de Vida.

Determinar los procesos y actividades que hay que introducir.

Definir roles y responsabilidades (gestión).

Identificar las herramientas necesarias para el soporte y documentación de procesos.

Seleccionar los métodos y técnicas para medir y documentar la calidad y eficacia de los servicios y procesos.

Implementar CSI

Determinar el presupuesto.

Documentar roles y responsabilidades.

Determinar la política, los planes y los procedimientos de CSI.

Comunicar la política, planes y procedimientos a todos los equipos.


10

Proporcionar herramientas de monitorización, análisis, informes y mantenimiento.

Integrar CSI en las fases de Estrategia del Servicio, Diseño del Servicio, Transición del Servicio y Operación del Servicio.(En principio esta fase afecta principalmente a la OS, pero interactúa con todas ellas cuando es necesario).

Monitorizar, medir y evaluar CSI (Verificar):

Informar de los progresos del plan mediante estadísticas, tests y documentos.

Evaluar la documentación.

Efectuar evaluaciones y auditorías de procesos.

Plantear propuestas para mejorar procesos.

Ajustar CSI (Actuar):

Introducir las mejoras.

Ajustar los procedimientos y políticas.

Ajustar los roles y las responsabilidades.

(CSI) Análisis DAFO

Cuando sean gestionadas correctamente todas estas características y se institucionalicen los

cambios, se lograrán éxitos a corto plazo, nuevas solicitudes de cambios y la detección de

fallos o ‘gaps’, que nos ayudarán a realizar correcto análisis DAFO. Los objetivos sólo se

lograrán analizando con detalle cada uno de estos elementos:

Debilidades Cómo podemos suprimir las debilidades de nuestros proyectos o de

nuestra organización?

Amenazas Cómo debemos gestionar las amenazas de nuestro sector? Como

debemos eliminar las amenazas de nuestros proyectos?

Fortalezas Cuáles son nuestros ‘puntos fuertes’ en nuestra organización y cómo

podemos sacarles el mayor partido?

Oportunidades Estamos abiertos a nuevas mejoras y modificaciones para optimizar

el beneficio? Sacamos provecho a las nuevas oportunidades?

Ejemplo

Una práctica recomendable, para comenzar con la CSI en el Ciclo de Vida de los Servicios de

nuestra organización, es el análisis DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades)

de cada Servicio o proyecto de forma independiente. Una vez concluido, se establecerá un

plan de acción para implantar las mejoras necesarias y la metodología para hacerlo.


11

En el siguiente ejemplo vamos a proceder como si fuésemos un gestor CSI, e investigar los

puntos a favor y en contra de nuestra estrategia para un servicio.

Enunciado: Nuestra organización es una importante carpintería industrial muy conocida y

valorada en el mercado (30 años de antigüedad). Aceptamos sólo pedidos telefónicos desde

hace 1 mes de camas, armarios y mesas de noche a precios de fábrica. Sólo aceptamos

clientes-tiendas de la comunidad de Murcia.

Debilidades:

Sólo aceptamos pedidos telefónicos. Esto importa un riesgo, ya que ciertos clientes

buscarán nuestro servicio a través de internet, es importante facilitar los pedidos a los

clientes.

Precios de fábrica. Los precios son demasiado bajos, lo que implica que es necesario un

alto volumen de ventas para alcanzar un beneficio alto.

Pedidos desde hace un mes. Aún no tenemos suficiente información del resultado de

nuestros servicios, pues el historial es muy corto.

Camas, mesas de noche y armarios. No existe un catálogo de cunas, taburetes y

reposapiés? Sólo se ofrecen dormitorios? Se informa al cliente de otros productos? Se

pretende vender el conjunto completo de dormitorio? La estrategia no resulta clara.

Amenazas:

Estamos restringiendo nuestro negocio a Murcia. Actualmente la demanda de muebles

ha bajado sensiblemente, y además la competencia ha aumentado mucho debido a una

potente marca sueca.

Puntos fuertes:

El prestigio de la organización es contrastado. La captación de clientes y fidelidad a la

marca será más sencilla.

La empresa dispone de varias sucursales y proveedores. Los recursos son más que

suficientes para este servicio concreto.

La empresa lleva muchos años en el negocio. Las ventas hasta ahora han producido altos beneficios, y la gestión ha permitido aumentar la plantilla casi cada año.

Posibles oportunidades:

Clientes-tienda. Podría empezar a ofrecerse el producto a clientes particulares, intermediarios o incluso centros de productos diversificados.

Productos; Una buena opción es la de expandir el catálogo de productos ofrecidos en el mismo servicio (cunas, literas…) o incluso crear nuevos servicios similares.

Pedidos: Puede diversificarse la forma de realizar pedidos y adaptarlos a las características del cliente final (precios, envios, ubicación, colores…).


1


Unidad 3: Principios y Modelos clave

Índice

3.1. Introducción

3.2. Creación de Valor por medio de Servicios

3.3. Las cuatro “P” de ITIL®

3.4. Diseño de Catálogo de Servicios

3.5. Herramientas en la Gestión del Servicio (MoSCoW)

3.6. Modelo de Mejora Continua de Servicio (CSI)

3.7. Líneas Base

3.8. Riesgos


2

3.1. Introducción

Introducción

Ofrecer un servicio no conlleva un beneficio inmediato sólo por el hecho de existir. El

proceso para crear un servicio debe tener siempre como horizonte el cumplimiento de

un determinado objetivo, y concretar todas sus fases.

Las Personas, los Procesos, Partners y los Productos que intervienen o se obtienen de

ese servicio, deben ser gestionados de una forma adecuada para obtener un Valor. En

esta unidad nos centraremos en esta premisa y en la forma correcta de planificar un

servicio con todos los factores que lo rodean.

3.2 Creación de Valor por medio de Servicios

Ciclo de Vida del Servicio

Para comenzar a desarrollar un proyecto, es necesario organizar los conceptos e ideas que

rodean a los Servicios de TI. Debemos definir unos objetivos y plantear las mejores prácticas a

seguir para lograr alcanzarlos.

Por tanto, el principio básico a evaluar a lo largo de cualquier ciclo, será el Servicio. Y los

servicios por sí mismos no ofrecerán ningún beneficio si no aportan un Valor al cliente (y por

consiguiente, a la organización proveedora de los mismos).

Valor de un servicio: Utilidad y Garantía

Como ya mencionamos en la unidad anterior, el Valor de un Servicio puede medirse mediante

dos componentes:

Funcionalidad El Servicio debe tener una utilidad bien definida. Aunque tenga

cierta capacidad de adaptación, el objetivo tiene que ser concreto y alcanzable (No se

debe definir a lo largo de su ciclo de vida, sino tener una estructura pre-fijada).


3

El cliente debe percibir esta utilidad. El servicio tiene un inicio, una fase intermedia y

una finalización (si obviamos el periodo continuo de mejora). En este ciclo de vida se

debe documentar apropiadamente los requisitos iniciales, procesos necesarios, todos

los recursos materiales y personales empleados, y por supuesto, el objetivo final

alcanzado.

Garantía Es otro aspecto fundamental del servicio; Un servicio no tendrá ninguna

utilidad si no tiene un cierto nivel de calidad. Por tanto, los servicios que ofrezca un

proveedor deben proporcionar a su vez una garantía o “cómo” se proporciona ese

servicio.

Es importante que se cumpla una planificación inicial, que haya una correcta

coordinación entre todas las partes implicadas y tratar de alcanzar el mayor nivel de

calidad posible en todos los procesos.

Activos del servicio: Recursos y Capacidades

Para poder crear valor en los servicios que ofrecen, las organizaciones utilizan los recursos y

habilidades de que disponen.

Los recursos La adquisición de recursos es sencilla y está relacionada con procesos,

las personas, los sistemas y la tecnología.

Las capacidades Se logran de forma más compleja, pues están basadas en

experiencias previas adquiridas mediante formación, situaciones con los clientes,

creación de servicios originales…

Ambos elementos, junto con las personas, se engloban en lo que ITIL® denomina Activos de

servicio. Mediante los activos combinados se genera valor, pero los recursos son insuficientes

para lograrlo en demasía, y las capacidades necesitan los recursos para conseguirlo.

Puedes ver en esta imagen cómo los recursos y capacidades se combinan para conseguir Valor

para el cliente.

Personas Representan la capacidad de percepción, evaluación, liderazgo,

creatividad, comunicación… y otra serie de características indispensables para la

generación del servicio.

Gestión Sistema que administra otros activos e incluye liderazgo, administración,

política, rendimiento, normativas e incentivos.

Organización Aplicaciones, procesos, infraestructuras y personas que utilizan una

serie de sistemas para trabajar juntos con un objetivo común.


4

Procesos Métodos y procedimientos que facilitan las actividades de gestión e

implementación.

Conocimiento Información acumulada mediante experiencia y logros, relacionada

con un contexto concreto.

Información Colecciones, abstracciones y patrones que se emplean en todo el

entorno de los servicios entre clientes y proveedores.

Aplicaciones Herramientas, automatizaciones, hardware y otros elementos que

interactúan con otros activos.

Infraestructura Jerarquías entre personas, aplicaciones y otros activos relacionados

entre sí.

Capital financiero Elementos económicos para proporcionar el resto de activos.

3.3 Las cuatro “P” de ITIL®

Las cuatro “P” de ITIL®

Antes de diseñar un modelo concreto de TI, es necesario definir los diferentes actores que

intervienen para conformarlo.

Los procesos representan a las diferentes actividades a realizar, las personas los responsables

de dicha ejecución, y los productos, la consecución de objetivos definidos inicialmente.Los

partners son los colaboradores y suministradores asociados al proveedor de Servicios.

A las personas, procesos, partners y productos se les conoce como Las cuatro “P” de ITIL®.

Proceso

Proceso: Un proceso se compone de una serie de actividades que se efectúan para lograr que

una entrada se convierta en una salida. Dicha salida finalmente se combinará con otras salidas

(o servirá de entrada a otros procesos) hasta obtener un resultado final. Para entender el

significado de un proceso es necesario conocer estos términos:

Entrada: Recursos necesarios para poder llevar a cabo un proceso.

Salida: Resultado intermedio del proceso.

Resultado: Objetivo final del conjunto de procesos o del servicio.

Control: Políticas y estándares y que permiten la comunicación entre procesos.


5

Procedimiento: La descripción del funcionamiento de uno o varios procesos. Incluye

también las personas encargadas de realizar esas actividades.

Nota

En la Unidad 4 se ahondará más profundamente en los procesos básicos.

Personas

Personas: Los procesos suelen asignarse a diferentes departamentos, con una o más personas

asignadas a la ejecución de los mismos. Deben efectuar, entre otras, las siguientes tareas:

Gestión de información: Almacén de datos, contacto con los clientes, información de

los usuarios, gestión de procesos, gestión de estándares, comentarios…

Documentación: Documentación de requisitos de entrada y de salidas de los procesos.

Estadísticas, monitorización…

Detección: De problemas, de posibilidades del mercado, pruebas de usabilidad,

cambios del entorno.

Nota

En la unidad 6 se detallarán las nociones de rol y propiedad asociados al concepto personas.

Productos

Productos: Llamamos productos a los servicios, tecnología y herramientas de los que dispone

nuestra organización, o que ofreceremos a clientes y usuarios finales. ITIL® no sólo nos indica

como proporcionar mejores servicios, sino que también ayuda a las diferentes empresas con

tecnología TI y aplicaciones de efectividad contrastada.

Marcos de aplicaciones: Los diseñadores de aplicaciones disponen de unos requisitos,

lenguajes y características para llevar a cabo ciertas acciones con la aplicación

desarrollada. Los desarrolladores de ITIL® deben crear un entorno o agrupación de

aplicaciones y los resultados que pueden obtenerse del conjunto. Se pueden crear

tantos marcos como sean necesarios.


6

Herramientas CASE: Podemos destacar las herramientas de Ingeniería de Sistemas

Asistida por Ordenador (CASE), muy usadas en entorno de desarrollo, y utilizadas para

generar aplicaciones, enumerar requisitos o crear esquemas de diseño.

Las herramientas CASE ofrecen:

o Guiones de funcionamiento, inicio y parada de una aplicación.

o Guiones de monitorización de Hardware y Software.

o Requisitos del acuerdo entre el proveedor y el cliente.

o Requisitos de documentación.

o Requisitos de soporte.

Partners

Partners: Se conoce como partner a una organización que está asociada a otra, en una

relación de colaboración. También se incluyen en esta definición a aquellos

suministradores de servicios externos al proveedor de servicios.

Los sistemas de partners suponen un beneficio común para las dos empresas

asociadas.

3.4 Diseño del Catálogo de servicios

Diseño del Catálogo de servicios. Los procesos.

Una vez establecidas las estrategias y definido los elementos necesarios para el servicio que se

desea ofrecer, podemos proceder al diseño del servicio. Los procesos más firmemente ligados

a esta fase del ciclo de vida son:

Gestión del Catálogo de Servicios (SCM) La estrategia de una organización

planificará un conjunto de servicios o Cartera de Servicios (Estrategia del Servicio). Sin

embargo, cuando se materialicen los requisitos necesarios y los procesos que

intervienen en ellos, la Cartera quedará reducida en cierta medida, y sólo algunos de

esos servicios estarán disponibles para el cliente (Diseño del Servicio). A esto se le

conoce como Catálogo de Servicios.


7

Gestión del Nivel de Servicio (SLM) Denominamos Gestión del Nivel de Servicio a la

relación proveedor-cliente, que garantiza la provisión de servicios actuales y futuros.

Para ello se sirve de Acuerdos de Nivel de Servicio (SLA), con la definición de los

objetivos y responsabilidades de ambos (Cliente y proveedor).

SLM incluye una serie de actividades como planificación, provisión, decisiones y

monitorización.

Gestión de la Capacidad Gracias a los SLA se establecen unas necesidades entre

cliente y proveedor. La Gestión de la Capacidad se encarga de planificar los recursos

para garantizar la capacidad de provisión de servicios durante el tiempo estimado.

Gestión de la Disponibilidad Este proceso se encargará de gestionar la

disponibilidad de servicio al cliente en todo momento. Por tanto, es imprescindible la

monitorización preventiva, soporte y resolución reactiva ante cualquier problema que

pueda surgir y que implique la ausencia del servicio acordado (SLA).

Gestión de la Continuidad del Servicio de TI (ITSCM) Cuando sucede un problema

leve, simplemente lo llamamos Gestión de Incidencia, y es el proceso que se encarga

de solventarlo. Si la incidencia es mayor y puede afectar a la continuidad del negocio,

entonces las acciones y planificaciones se denominan Gestión de la continuidad del

Servicio.

Gestión de Suministradores La Gestión de suministradores es el proceso centrado

en manejar todos los suministradores que permitan a una empresa ofrecer un

determinado servicio. Por tanto, no sólo deben cumplir ciertas características, sino

también es imprescindible que incluyan un ITSCM adecuado y una Gestión de

Seguridad equivalentes a los del proveedor.

Gestión de la Seguridad de la Información (ISMS) La Gestión de la Seguridad de la

Información es un elemento un poco especial, pues no sólo se debe fijar en el Diseño

del Servicio, sino a lo largo de todo el ciclo de vida. Todos los problemas de seguridad

pasados, presentes y futuros deben gestionarse de forma continuada para cumplir la

expectativa de clientes, proveedores y suministradores.

Diseño del Servicio

En resumen, es necesario contemplar estos elementos para realizar un diseño adecuado del

servicio y orientarlo a las expectativas del negocio, según unos requerimientos que

recopilaremos y almacenaremos en un documento llamado Declaración de Requerimientos

(SOR):

Solución del servicio Deben evaluarse los recursos disponibles y la capacidad para

disponer de ellos y ofrecer ciertos servicios estables (garantizados) y de calidad.

Acuerdos sobre la provisión del servicio.


8

Cartera de servicios Paquetes de Diseño del Servicio (SDP) según los servicios e

infraestructuras TI de los que se disponga. Servicios acordados para el negocio.

Procesos Soluciones que se ofrecerán y objetivos que se desean cumplir. Desarrollo

de servicios alternativos, y diseño de nuevos servicios a partir de nuevos requisitos.

Sistemas de medida Evaluación y acuerdos sobre gastos y costes. Monitorización

de servicios y evaluación de beneficios.

Definición: Declaración de requerimientos (SOR): Documento que contiene todos los

Requerimientos para la compra de un producto o para un Servicio de TI nuevo o cambiado.

Diseño de la arquitectura

Para dar forma al servicio, debemos concretar una arquitectura adecuada a él. ITIL® describe la

Arquitectura del Servicio como:

Definición ITIL®: El diseño de la arquitectura es el desarrollo y mantenimiento de

políticas, estrategias, arquitecturas, diseños, documentos, planes y procesos de TI para el

despliegue, implementación y mejora de servicios y soluciones de TI apropiados en toda

la organización.

Es decir, la arquitectura debe coordinar a todos los procesos y personas implicadas y garantizar

los servicios a la par que se aplican las políticas del negocio, estrategias, riesgos y costes

asignados. Entre las plantillas o marcos de arquitectura podemos destacar:

Arquitectura de servicios Arquitectura básica para convertir una infraestructura

inicial (recursos y aplicaciones) en servicios.

Arquitectura de entorno En algunos sectores se la conoce como ‘Arquitectura de

requisitos’, puesto que se encarga de analizar todas las variables de entorno de un

proyecto.

Arquitectura de información Para la gestión de información (documentación,

análisis, estadísticas…).

Arquitectura de aplicaciones Para los proyectos donde se desarrollan aplicaciones

individuales.

Arquitectura de la infraestructura de TI Para la organización geográfica del

hardware y las aplicaciones que ofrecen servicios TI.


9

Métricas y Valor

El diseño del servicio no servirá de nada si no se dispone de un buen sistema de métricas que

nos indique si dicho servicio está efectuándose con normalidad, si se cumplen los plazos

acordados, y si es el mejor método para llevarlo a cabo (Realización, progreso y eficacia-

eficiencia).

Para comprobar estos aspectos, es necesario revisar estos elementos para lograr el Valor en

nuestros servicios:

Los recursos internos Una buena gestión, implicará unos costes finales del servicio

mucho menores.

Recursos y elementos externos Al igual que el punto anterior, implica mejoría de

costes y una mayor calidad.

Revisión de la arquitectura Será más sencillo crear nuevos servicios o modificar los

actuales.

Catálogo de servicios actualizado Se aumenta la calidad del servicio y se confirma

la capacidad de ofrecer los que aparezcan en el catálogo.

Prioridad de actividades Facilita el seguimiento y la toma de decisiones.

Contrastar servicios TI con el negocio Mayor coherencia entre los servicios y

objetivos a conseguir.

Establecer hitos Resultados más eficaces

Gestión del servicio de negocio Mejor sincronización entre servicio y negocio.

3.5 Herramientas en la Gestión del Servicio (MoSCoW)

Herramientas en la Gestión del Servicio (MoSCoW).

Para ayudar a los procesos en la Gestión del Servicio, ITIL® recomienda el uso de las

herramientas. Pueden emplearse para ofrecer una visión gráfica de un proceso de negocio,

para establecer un acuerdo de servicio o para minimizar riesgos humanos.

Las herramientas tienen algunas ventajas como:

Aseguran el cumplimiento de estándares.


10

Ayudan en la creación de un Sistema de Configuración del Servicio

Son muy útiles para crear y mantener un Sistema de Gestión del Conocimiento

Aumentan la velocidad del proceso de diseño.

Dan soporte a ciertos aspectos del Servicio

Ayudan en el desarrollo de prototipos

Disminuyen determinados riesgos.

Ayudan en la Gestión de costes

Pueden utilizarse para simular situaciones ficticias.

Son muy útiles en todas las fases del Ciclo de Vida del Servicio.

MoSCoW

Sin embargo, hay que ser precavido a la hora de seleccionar las herramientas que nos

ayudarán en la Gestión del Servicio. No todas ellas son adecuadas, y es necesario realizar un

análisis previo antes de seleccionar cualquier herramienta.

Un modelo de análisis muy empleado es el que revisa los requisitos necesarios para cualquier

herramienta, denominado MoSCoW:

M (must) Qué requisitos debe incluir la herramienta de forma ineludible.

S (should) Cuáles son recomendables.

C (could) Listado de requisitos que puede o no incorporar la herramienta.

W (won’t) Los que no son necesarios en la situación actual.

En general, es conveniente el uso de herramientas totalmente integradas, que den soporte a

diferentes procesos y sean adaptables. Así podremos ‘configurarlas’ según nuestras

necesidades, plataformas y situaciones.

En el caso de que no sea posible esta flexibilidad deben escogerse las más sencillas y dirigidas

hacia los objetivos concretos a conseguir.

3.6 Modelo de Mejora Continua de Servicio (CSI)

Modelo de Mejora Continua de Servicio (CSI). Deming.


11

Una vez finalizada la estrategia inicial, y el posterior diseño del mismo, la fase subsiguiente

será la de transición y operación del propio servicio (de momento no entraremos en detalles

en ello). Finalmente, para optimizar el servicio y lograr el valor buscado, debemos acoger un

plan de Mejora continua de servicio.

Para conseguirlo deben realizarse estas actividades, y en este orden (aunque algunas puedan

intercambiarse):

Planificar

Gestionar recursos materiales

Gestionar recursos humanos

Gestionar recursos temporales.

Gestionar intercambio de información con los clientes, proveedores y los propios

elementos del proyecto.

Hacer y mejorar

Generar un protocolo de actuación para cada servicio, adaptando el Ciclo de Vida.

Respetar las decisiones tomadas para cada fase del Ciclo de Vida del Servicio, y

efectuar un control riguroso de cada una de ellas.

Documentar todas las acciones, procesos, elementos, incidencias o problemas que

aparezcan en cualquier momento.

Informar

Proponer nuevas mejoras en cualquier fase del Ciclo de Vida del servicio.

Informar de las nuevas necesidades de los clientes y del nivel de satisfacción por el

servicio.

Revisar

Comprobar que todos los procesos se efectúan satisfactoriamente.

Evaluar la satisfacción del cliente.

Verificar que el personal implicado sigue las directrices.

Verificar que las herramientas son útiles para el fin que fueron adquiridas.

Analizar los resultados respecto a los objetivos del acuerdo inicial.

Mejorar

Aplicar métodos y protocolos de gestión de calidad.

Introducir nuevas acciones para aumentar la eficiencia y eficacia del servicio.

Nota

Recordar el modelo de Deming que perseguía conseguir las mejoras en el Ciclo de Vida,

paso a paso, según el modelo Planificar-Hacer-Verificar-Actuar.


12

PKI (Indicadores Clave de Rendimiento)

En cualquier caso, para la Mejora Continua es imprescindible establecer unos KPI (Indicadores

Clave de Rendimiento) que nos sirvan de guía para dilucidar si nuestros procesos están

realizándose de forma correcta y alcanzamos el objetivo deseado. Los KPI determinan el

correcto funcionamiento del proceso, su valor, rendimiento y la calidad del mismo.

Se establecerán uno o varios KPI para cada CSF (Factor Crítico de Éxito o lo que es lo mismo,

éxito de servicio para el negocio). Además, según sus características, serán de tipo cualitativo

(se ofrece mayor velocidad de conexión al cliente) o cuantitativo (la compra de un nuevo

servidor de mayor capacidad) y se complementarán entre sí.

En definitiva, un CSF es cualquier riesgo que pueda sufrir un proceso, mientras que los KPIs son

la medida de dichos riesgos.

Para poder definir KPIs adecuados habría que plantear estas preguntas:

¿Quién, cuándo y durante cuánto tiempo se necesita la información?

¿El KPI es claro e indica qué acciones deben realizarse?

¿El KPI es variable, o es estable y de características bien definidas?

¿Puede modificarse el KPI si las condiciones cambian?

¿Quién es el responsable de analizar las medidas y de las mejoras derivadas de los

KPIs?

¿Se lograrán los objetivos si se cumple el KPI?

¿Es necesario el KPI para lograr los objetivos?

Definición ITIL®: KPI: Indicador Clave de Rendimiento. Métrica empleada para ayudar

a gestionar un Proceso, Servicio de TI o Actividad. Muchas Métricas pueden medirse, pero

sólo las más importantes se defi nen como KPIs y son empleadas para gestionar de forma

activa e informar sobre los Procesos, los Servicios de TI o las Actividades. Los KPIs deberían

ser seleccionados de tal forma que aseguren el control de la Efi ciencia, la Efectividad, y la

Rentabilidad.

Definición ITIL®: Factores Críticos de Éxito (CSF): Algo que debe existir si un Proceso,

Proyecto, Plan, o Servicio TI desea tener éxito. Se utilizan KPIs para medir el alcance de cada

CSF. Por ejemplo: un CSF de “proteger Servicios TI cuando se hacen Cambios” se podría

medir por KPIs tales como “porcentaje de reducción de Cambios con fallo”, o “porcentaje

de reducción de Cambios que provoquen Incidentes” etc.


13

3.7 Líneas Base

Líneas Base

Una línea base es un determinado modelo o buena práctica usado en un determinado

momento. Cuando finalice un proceso de forma correcta y comprobemos su estabilidad,

podremos implantarlo como ‘plantilla’ o modelo fijado para el Ciclo de Vida de Servicios

similares.

Un buen ejemplo sería el anterior, una vez finalizado un curso avanzado, cuyos cuestionarios

de calidad ofrecen resultados satisfactorios y donde los alumnos han obtenido certificaciones

muy valoradas en el mercado. Se puede reutilizar todo el proceso (solicitudes, gestión, compra

de material, documentación…) como línea base en futuros cursos similares.

Un servicio puede componerse de varias líneas base, procesos nuevos y procesos reutilizados,

cooperando juntos en un determinado momento.

Métricas de CSI

Pero, ¿Cómo saber si la CSI está resultando productiva? ¿Cómo evaluarla? Para ello es

necesario implantar métricas, que nos ayuden a conocer si se están obteniendo los resultados

esperados. Las métricas se agrupan según su tipología, las más habituales son:

Métricas de tecnología: Miden el rendimiento de las aplicaciones. También la

disponibilidad de los componentes.

Métricas humanas: En cierto aspecto realizan la misma acción que las anteriores, pero

respecto a las personas (los factores y metodología difieren).

Métricas de proceso: Los KPI establecidos ofrecerán unos valores reales de

Rendimiento. Estos valores se contrastarán con los CSF para comprobar si los procesos

funcionan correctamente o han de mejorarse.

Métricas de servicio: Se realizarán mediciones de todos los componentes del servicio,

para discernir si se ha alcanzado el objetivo.


14

3.8 Riesgos

¿Qué son los riesgos? ITIL® los define de esta forma:

Definición ITIL®: Riesgo: Un riesgo es un resultado incierto o, en otras palabras, una

oportunidad positiva o una amenaza negativa.

Es decir, un riesgo no sólo son las amenazas que pueden surgir cuando modificamos la Cartera

de Servicios, sino que también se consideran como tales las oportunidades que pueden surgir.

Al implementar la Cartera se deben tener en cuenta los factores de una mala inversión, el uso

de tecnología obsoleta o una posibilidad de inversión beneficiosa, por ejemplo.

La Gestión del Riesgo

La Gestión del Riesgo debe realizar una serie de tareas para establecer los riesgos y

controlarlos. Normalmente estas acciones se organizan en dos etapas:

1) Análisis de Riesgos: Durante esta fase se recopilan todos los riesgos potenciales. Es

importante no olvidar ninguno, pues puede suponer una pérdida de Valor en el

Servicio final.

Entre los riesgos podemos encontrar:

Riesgos de contrato El proveedor de Servicios llegará a una serie de acuerdos con

el cliente, en forma de contrato. Entre sus características debe aparecer un periodo

de entrega, un formato, unos responsables… todas estas definiciones suponen un

riesgo si no responden a una buena estrategia.

Riesgos de diseño Los Servicios deben responder a unos objetivos concretos, y

ofrecer una determinada funcionalidad. Es imprescindible establecer un diseño

adecuado para asegurar que cada servicio proporcionado al cliente es el acordado.

Riesgos operativos Se subdividen en Riesgos para las unidades del negocio, y en

Riesgos para las unidades del servicio. Son los que se producen con la propia

operativa del servicio, (caídas de servidores, cambios de suministradores, problemas

o incidencias posibles…)

Riesgos de mercado Mediante la Diferenciación y la Consolidación, los

proveedores de servicios pueden reducir los riesgos propios del mercado. Estos

surgen por un exceso de competencia (o la falta), por poca diferenciación de

servicios, etc.


15

2) Gestión de Riesgos: La Gestión del Riesgo son las tareas asignadas para analizar,

evaluar, reparar y supervisar los riesgos detectados (o incluso permitir la detección de

riesgos adicionales). Los Servicios reducen los riesgos para el negocio del cliente, pero

por el contrario, los aumentan para el proveedor de Servicios.

Nota

Es importante resaltar que la gestión de riesgos no es algo de lo que deba encargarse

la Estrategia del Servicio, sino sólo del análisis.


1


Unidad 4: Procesos SS, DS. La Disponibilidad del Catálogo.

Índice

4.1. Introducción: Los Procesos.

4.2. SS. Gestión Financiera.

4.3. SS. Gestión de la demanda (DM).

4.4. SS. Gestión de Cartera de Servicios (SPM).

4.5. DS. Gestión de Niveles de servicio (SLM).

4.6. DS. Gestión de Catálogo de servicios (SCM).

4.7. DS. Gestión de la Capacidad.

4.8. DS. Gestión de Disponibilidad.


2

4.1. Introducción: Los Procesos

Introducción: Los Procesos

La finalidad de una acción de negocio es lograr un objetivo determinado. Con tal fin, se

crean los servicios de cada organización, y los implicados en la ejecución de dicho

servicio son los Procesos, las Personas y los Productos.

En esta unidad nos centraremos en una las partes fundamentales: Los Procesos.

Los procesos constituyen la forma de administrar todos los factores que rodean a un

servicio, mediante la planificación de actividades y la gestión de los recursos asignados.

Un proceso bien definido, conseguirá resultados eficaces y eficientes en forma de

Valor para los clientes y la propia empresa.

Definición ITIL®: Un proceso es un conjunto estructurado de actividades diseñado para

cumplir un objetivo específico. Convierte una o más entradas en salidas definidas. Un

proceso incluye todos los roles, responsabilidades, recursos y controles de gestión

necesarios para proporcionar una salida fiable y, en caso necesario, puede definir

políticas, estándares, directrices, actividades, procedimientos e instrucciones de

trabajo.


3

Esquema: Procesos de la SS y DS

En esta unidad analizaremos los procesos más relacionados con la fase inicial de la

Estrategia y el Diseño del Servicio para la generación de un Catálogo.

Gestión Financiera

Gestión de la Demanda (DM)

Gestión de la Cartera de Servicios (SCM)

Gestión de Niveles de Servicio (SLM)

Gestión del Catálogo de Servicios

Gestión de la Capacidad

Gestión de la Disponibilidad

Gestión de la Seguridad de la Información (ISMS)

Gestión de los Suministradores

Gestión de la Continuidad del Servicio (ITSCM)

Gestión de Cambios

Gestión de Activos y Configuración del Servicio (SACM)

SS

DS

TS

UN

IDA

D 4

Ciclo de Vida

UN

IDA

D 5


4

4.2 SS. Gestión Financiera

Caso de Negocio

La La Gestión Financiera es un elemento vital durante todo el Ciclo de Vida del Servicio. Se

encarga de cuantificar los costes de los servicios, evaluar sus beneficios y descubrir los

inconvenientes existentes.

Su actividad principal es la de Valorar el servicio, es decir, obtener un valor real de cada

servicio respecto del negocio. Por tanto, con cada evaluación se crea un Caso de Negocio

donde se aglutinan todos los factores para justificar una inversión.

Definición ITIL®: Caso de Negocio: Justificación para el gasto de un elemento relevante.

Incluye información de Costos, beneficios, opciones, situaciones, Riesgos, y posibles problemas

y prevé las consecuencias probables de una acción del negocio.

Un nuevo Caso de Negocio debe incluir dos conceptos ITIL®:

Valor de provisión: Los costes reales asociados a la provisión de servicio TI.

Costes de Licencias software

Costes de Hardware

Instalaciones

Personal asociado a un servicio.

Costes asociados (alquileres, incentivos, intereses…)

Costes de mantenimiento

Costes legales.

Potencial del servicio: Valor adicional del servicio durante su ejecución, ya sea por la

mejora de servicios adicionales, por un valor estratégico o por elementos puntuales no

contemplados.

Una buena gestión financiera conseguirá:

• Mejor capacidad de decisión.

• Rapidez de adaptación ante cambios.

• Gestión de la Cartera de Servicios

• Conformidad y control financiero.

• Control operativo.

• Captura y creación de valor.


5

Gestión financiera: Estrategia, planificación y análisis

La Gestión Financiera se encarga de estudiar la demanda del servicio en el sector, de gestionar

una Cartera adecuada a esa demanda, y de Optimizar la Provisión del Servicio (SPO) para

buscar alternativas económicas y de proceso con el fin de optimizar los beneficios de los

servicios.

Tras establecer la estrategia inicial, se debe proceder con la planificación de los servicios TI

según los recursos asignados. ITIL® la clasifica en:

Planificación operativa y financiera (Contabilidad general y de activos fijos)

Interpretación de gastos de TI como sistemas financieros colectivos.

Planificación de la demanda Necesidades y servicios demandados por los clientes.

Planificación del entorno (Conformidad) Dentro de la propia unidad de negocio de

la organización, debe realizarse un estudio de conformidad. No sólo para la creación

del servicio, sino también el seguimiento de la evolución del mismo.

Finalmente, debe realizarse un análisis sobre la inversión en el servicio. La Gestión Financiera

debe proporcionar los modelos y evaluaciones de retorno de los servicios, sopesando todos los

costes del servicio y el valor producido.

Gestión Financiera: Contabilidad

La principal función de la Gestión Financiera es la de Contabilidad. Está compuesta por una

serie de procesos, que sirven para obtener información detallada sobre los costes del servicio,

y posteriormente aplicar esos datos en la planificación.

Entre sus funciones cabe destacar:

Tipos de costes Debe calcular los gastos de hardware, software o administrativos. Es

muy conveniente dividir los costes en diferentes tipos (según clientes, clasificación) y

subdividirlos a su vez en abstracciones llamados elementos de coste.

Registro de servicio Se asigna un coste a cada servicio.

Clasificación de costes Los costes también se clasifican entre:

Costes de capital u operativos: Los costes de capital son aquellos relacionados con

compras de activos que se usarán durante varios años. Los operativos, sin embargo, son

costes periódicos sin relación con activos de forma directa.

Costes directos o indirectos: Los directos afectan de forma directa al servicio TI,

mientras que los indirectos tienen cierta relación con un servicio o con varios de ellos


6

Costes fijos/variables: Los costes fijos no cambian, con independencia de los

resultados (Compra de material), los variables sí lo hacen según los resultados (

Unidades de coste: Unidad de consumo que contabiliza un determinado Servicio.

Nota

Es importante tener en cuenta el hecho de que los usuarios de un servicio, las licencias, los

costes estructurales, el número de recursos… varían. Lo llamamos Dinámica de costes

Variables (VCD).

Gestión Financiera: Facturación

Habitualmente, las empresas TI suelen funcionar como centros donde la financiación se base

exclusivamente en los costes por los servicios realizados. Sin embargo, ciertos costes son

variables, y algunos difícilmente cuantificables por lo que conocer estas opciones es

recomendable a la hora de facturar:

Coste fijo o por usuario Los costes se asocian a un determinado factor, como el

número de usuarios. Es el más sencillo, pero menos flexible.

Directo plus Los costes de un servicio se ven incrementados por ciertos costes

indirectos comunes a varios servicios.

Sujeto a niveles Se crean varios niveles de utilidad o garantía ofrecidos por un

servicio. Se les asigna un coste y se definen en cada caso cuáles son los adecuados.

Uso medido Costes establecidos según ciertas medidas, siempre y cuando exista un

estudio muy depurado para cada unidad en gestiones de contabilidad anteriores.

Cobro por noción Un método de contabilidad, que calcula los costes según una

determinada forma de pago.

Entre los modelos más utilizados para la facturación están los planes renovables (paralelo al

Ciclo de Vida), planes con disparadores (por ejemplo, debido a un cambio de un servidor), y

Financiación de coste cero (sólo los costes reales de provisión de servicio).


7

4.3 SS. Gestión de la demanda (DM)

Gestión de la demanda (DM)

Una vez establecida la estrategia sobre la Gestión Financiera, el siguiente paso lógico es la

generación de la Cartera de Servicios, y por consiguiente el posterior Catálogo

(profundizaremos sobre ello más adelante). Fuertemente asociado a estos procesos surge la

Gestión de la Demanda, que será la encargada de analizar la demanda de servicios por parte

de los clientes, para poder crear la Cartera asociada con un estudio de rentabilidad.

Para gestionar correctamente la demanda de servicios ha de tenerse en cuenta los problemas

de:

Sincronización entre producción y consumo Los servicios que se generen, deben

tener un consumidor predefinido, sino cualquier valor que se obtenga no tendrá

aplicación.

Capacidad adecuada El proveedor de servicios debe cuantificar con cierta exactitud

la cantidad de servicios que puede ofrecer. Si las previsiones son optimistas, incurrirá

en insatisfacción del cliente, paralización de servicios, y, en definitiva, una baja calidad.

Previsión, planificación y coordinación Es necesario estar en contacto con el cliente

e intentar prever todos los aspectos que influyan en la planificación del servicio.

Importante

Como comentamos en la Unidad 2, la Estrategia de un Servicio también se considera un

patrón, pues la perspectiva, posición y plan establecido dirigen las acciones subsiguientes.

Durante la DM han de tenerse en cuenta de forma especial los Patrones de Actividad de

Negocio, ya que serán la base de la Gestión de la Capacidad y la creación de procesos según

las necesidades del negocio.

Paquetes de Servicio

Los paquetes de Servicio es la forma de aglutinar los servicios básicos que ofrece un proveedor

con los servicios asociados. Un proveedor no ofrece sólo un servicio esencial, sino que en la

mayoría de los casos también dispone de servicios de soporte, que tienen una importancia

enorme en la satisfacción final del cliente. Por ello deben tenerse en cuenta estas

estandarizaciones en la Gestión de la Demanda:


8

Definición ITIL®: Paquete de servicio: Un Paquete de Servicio es una descripción detallada

de un servicio de TI que está disponible para entregarse a los clientes. Incluye un Paquete del

Nivel de Servicio (SLP) y uno o más servicios esenciales y de soporte.

Paquete de Nivel de Servicio (SLP) Es un modelo de funcionalidad de servicio que

satisface un patrón de negocio concreto. Un SLP está asociado a un nivel de servicio, a

un Paquete del Servicio Principal (CSP) y a unos costes asociados.

Paquete del Servicio Principal (CSP) Es el equivalente al servicio esencial que desea

ofrecerse, pero que puede estar incluido en varios Paquetes de Nivel de Servicio.

Línea de Servicio (LOS) Es un servicio esencial o un servicio de soporte controlado

por un gestor de producto y con varios Paquetes de Nivel de Servicio para cada

segmento del mercado.

Los diferentes clientes se clasifican en segmentos tipificados, y para disponer de una capacidad

del mejor servicio, se intercalan los servicios empaquetados en CSPs y SLPs.

4.4 SS. Gestión de Cartera de Servicios (SPM)

La Cartera de Servicios

Y llegamos a la creación de la Cartera de Servicios. El proceso de Gestión debe analizar las

necesidades del negocio, y la respuesta del proveedor de servicios a dicha necesidad,

generando Valor de Negocio en el proceso.

La Gestión de la Cartera de Servicios se trata de un método de gobierno para controlar los

riesgos y costes. Para ello debe incluir la documentación del Catálogo de servicios y la creación

de nuevos Servicios.

¿Qué es entonces la Cartera de Servicios? En ITIL®, una Cartera de Servicios es el conjunto

completo de servicios gestionados por un proveedor de servicios.

Definición ITIL®: Cartera de Servicios: Conjunto de todos los Servicios que son

gestionados por un Proveedor de Servicios. La Cartera de Servicios se emplea para gestionar el

Ciclo de Vida completo de todos los Servicios, e incluye tres Categorías: Canal de Entrada de

Servicios (propuestos o en Desarrollo); Catálogo de Servicios (Reales o disponibles para su

Despliegue); y Servicios Retirados.


9

Nota

El dueño del Catálogo de Servicios es el gestor de productos, y es el encargado de gestionar

los servicios como un producto durante todo el Ciclo de Vida. (Colaboran habitualmente

con los Gestores de las Relaciones con el Negocio (BRM), que son los encargados de

coordinar y dirigir la Cartera de Clientes).

¿Cómo maximizar el Valor de la Cartera?

La Cartera de Servicios ayuda en la toma de decisiones importantes acerca de los servicios, y

ofrece información vital al Cliente y al Proveedor de Servicios sobre ellos. Una buena Gestión

de esta Cartera, permite adelantarse a los cambios y mantener o incluso mejorar la estrategia

de la organización.

Para que ayude a maximizar el Valor, mientras se reducen costes y minimizan los riesgos, la

SPM debe responder a estas preguntas:

¿Cuál es la necesidad de un cliente de comprar estos servicios?

¿Qué podemos ofrecer al cliente para que nos compre estos servicios?

¿Cuáles son los puntos fuertes de nuestra organización?

¿Cuáles son las debilidades de nuestra organización?

¿Qué riesgos tienen nuestros servicios?

¿Cómo se asignan los recursos y capacidades?

Gracias a las respuestas, se mantendrá la calidad del servicio, e incluso se podrán identificar

nuevas oportunidades de negocio.

Proceso de la SPM

La Gestión de Cartera de Servicios es un proceso que debe mantener la Cartera durante todo

el Ciclo de Vida de forma periódica. Por tanto, para asegurar su éxito, debe realizar estas

acciones:

1. Definición Se recopilan todos los servicios existentes para poder determinar los

costes particulares y el global de la cartera. Cada servicio genera un Caso de Negocio.

2. Análisis Se evalúan los costes y prioridades para que el suministro de servicios esté

de acuerdo con la demanda de los mismos, con un coste óptimo. Para esta evaluación

han de definirse las 4 “P”, el objetivo del servicio, los servicios que deben apoyarlo

para conseguir este objetivo, y la forma de lograrlo.


10

Según los resultados de este análisis surgirán tres categorías:

Inversiones para mantener el negocio (RTB) Para mantener las operaciones de

los servicios.

Inversiones de crecimiento del negocio (GTB) Para ampliar el ámbito de los

servicios.

Inversiones para transformar el negocio (TTB) Para nuevas oportunidades de

negocio.

3. Aprobación Se adoptan las decisiones y se autorizan los servicios, cerrando la

Cartera. Los servicios resultantes de la Cartera pueden ser:

Retenidos Sustituidos Racionalizados

Refactorizados Renovados Retirados

4. Institución En esta fase final se documentan y comunican las decisiones. Se

comprueba que estos resultados estén de acuerdo con la Gestión financiera inicial, y

se asignan los recursos necesarios en otras fases de Diseño o Transición de Servicio.

4.5 DS. Gestión de Niveles de servicio (SLM)

Gestión de Niveles de servicio (SLM): SLA y OLA

La Gestión del Nivel de Servicio es el proceso encargado de garantizar el acuerdo o nivel de

servicio pactado para los servicios TI actuales y futuros. En resumen, debe supervisar el nivel

de servicio en todo momento.

En este proceso se debe tener siempre claros los conceptos:

SLA Acuerdo por escrito entre el cliente y el proveedor del servicio, donde se

especifican las características, objetivos y responsabilidades de cada uno.

OLA Acuerdo entre un proveedor de servicios y otra parte de la organización para

cooperar en la provisión de servicios.

La Gestión del Nivel de Servicio, toma como bases todos los acuerdos pactados con el cliente,

y entre sus objetivos se encuentran:

Velar por que los acuerdos de servicio sean claros y conocidos por el cliente.


11

Generar medidas proactivas para mejorar los servicios, siempre que se ajusten a los

presupuestos y retornos de inversión definidos.

Establecer un sistema de comunicación entre proveedor TI y clientes que sea fiable y

continuo.

Supervisar los servicios, y la satisfacción del cliente en la entrega.

Definir, monitorizar y documentar los diferentes hitos de cada servicio.

Proceso de Gestión de Nivel de Servicio

El proceso de Gestión de Nivel de Servicio debe:

Diseñar marcos de trabajo SLA Es la funcionalidad principal, definir los prototipos

de acuerdo entre cliente y proveedor para poder contratar los servicios. Pueden usarse

distintos SLAs:

SLA basados en el servicio: Un SLA asociado a un solo servicio que puede

ofrecerse a varios clientes. Es más eficiente pero menos flexible ante clientes

especiales.

SLA basados en el cliente: Un SLA asociado a un cliente, para todos sus

servicios. Está más orientado al cliente, pero implica mayores costes para el

proveedor.

SLA multinivel: Subdivide un SLA en Nivel corporativo (genérico para todos los

niveles), Nivel de servicio (genérico para el servicio) y Nivel de cliente

(particular para un tipo de clientes o de negocio). Es el más complejo en

principio, pero más reutilizable para distintos servicios.

Definición, acuerdo y documentación sobre requisitos de nuevos servicios A partir

de un catálogo de Servicios y los SLAs definidos, debe decidirse los Requisitos de Nivel

de Servicio (SLR) entre el cliente y todos los departamentos del proveedor.

Monitorización del rendimiento del servicio según el SLA Es necesario establecer

una serie de hitos o resultados intermedios de los servicios. Así se podrá supervisar el

estado en todo momento, y documentar incidencias o procesos sin problemas y el

cliente estará en todo momento informado, a la par que satisfecho.

Revisión de acuerdos externos y OLAs La Gestión de Cambios y Gestión de la

Configuración deben actualizar en todo momento los distintos acuerdos existentes

respecto al servicio. Entre otros, los Acuerdos de Soporte (UC).

Documentación Toda la información relacionada con los servicios y los procesos

implicados, deben ser documentadas en detalle. Así se podrá realizar una revisión de

historial adecuada, y planificar futuras mejoras con una base de información

coherente.

Revisión del servicio Además de un Plan de Mejora del Servicio (SIP) con información detallada de las mejoras en curso, debe revisarse periódicamente los servicios para proponer nuevos cambios, y renovar los SLAs mediante la Gestión de Cambios y de la Configuración.


12

Contacto con el cliente Además de todos los aspectos anteriores, es importante

mantener una relación constante con el cliente. Acciones de perfeccionamiento

proactivo en los servicios existentes, nuevas propuestas para adaptarse a sus

necesidades o cuestionarios de calidad, son elementos que pueden facilitar la

satisfacción final.

Los BRM y los gráficos SLAM

La Gestión de Nivel de Servicio conlleva una consulta continua con el cliente y con el catálogo

de servicios. Para coordinar la Cartera de clientes y administrarla de acuerdo con el catálogo

de servicios, debe crearse un Gestor de las Relaciones con el Negocio (BRM). Se encargará así

de colaborar habitualmente con el dueño del catálogo de servicios para ofrecer el mejor

servicio a los clientes.

Una herramienta que habitualmente usan los BRMs son los gráficos SLAM.

Para poder monitorizar los SLA y poderlos comparar con los objetivos del Nivel de Servicio,

suelen emplearse estos gráficos. Gracias a ellos puede observarse de forma gráfica y sencilla

los objetivos del Nivel de Servicio que se han alcanzado en los últimos meses (el último año

generalmente).

Según el tipo de gráfico empleado, se utiliza un código cromático para diferentes resultados en

los objetivos (al menos, se definen los objetivos alcanzados y los que quedan por alcanzar).

4.6 DS. Gestión de Catálogo de servicios (SCM)

Cartera Vs Catálogo

Uno de los procesos más importantes es la Gestión del Catálogo de Servicios (SCM), pues se

trata de la fuente central de información de los Servicios de TI donde se ofrecen todos los

detalles, acciones y actores de los servicios actuales y futuros de cara al cliente.

Recordad que en la unidad 3 diferenciábamos entre Cartera de Servicios (Listado de Servicios)

y Catálogo (Servicios finales ofrecidos al cliente) de Servicios. Insistimos en diferenciarlas por el

aspecto práctico con el que se diferencian:

Cartera de Servicios: El listado de servicios que ofrece una organización está definido

en la Cartera. Describe el proceso de los servicios, desde los requisitos iniciales hasta la

ejecución final, pasando por todas las fases intermedias del Ciclo de Vida. Incluye

servicios activos e inactivos.


13

Catálogo de Servicios: Aunque es un listado reducido de la Cartera de Servicios,

presenta una visión más objetiva de cara al negocio. Sólo incluye los servicios activos

en la fase de Operación del Servicio, pero también ofrece información adicional como

responsabilidades, precios y condiciones de servicio y entrega. En definitiva,

representa los servicios disponibles de la Cartera para el cliente.

Nota

El proceso de Gestión del Catálogo de Servicios debe mantener el Catálogo actualizado y

carente de errores.

Importante

El Catálogo de Servicios se subdivide en Catálogo de Servicios de Negocio, con

información sobre los procesos de negocio y la relación con los Servicios TI, y el Catálogo

de Servicios Técnico, con la información del anterior más las configuraciones y

componentes. El de Negocio es visible al cliente pero el Técnico no.

Características del Catálogo

El catálogo debe tener estas características para justificar su existencia:

Todos los clientes deben estar familiarizados con los servicios proporcionados.

La organización TI debe estar familiarizada con la tecnología que soportan los servicios.

El catálogo debe ser exacto (sin más o menos servicios que los que hay).

El catálogo debe estar actualizado.

Y para crearlo se deben establecer de forma clara qué servicios forman parte del catálogo, los

procesos TI asociados, la gestión de niveles se servicio, dependencias entre procesos y

unidades de negocio, etc.

Importante

Cabe destacar que el Catálogo de Servicio incluye, tanto detalles para el negocio

(accesibles al cliente), como detalles técnicos de uso exclusivo por parte del

proveedor, y ambos son indispensables.

Nota

Es recomendable una base de datos u hoja de cálculo integrada con el catálogo y

mantenida de forma continuada.


14

4.7 DS. Gestión de la Capacidad


La Gestión de Capacidad es la encargada de revisar el equilibrio de las necesidades del negocio

(en la actualidad y en el futuro) y la capacidad de ofrecer los servicios relacionados siempre

que se justifiquen los costes.

La Gestión de Capacidad debe trabajar junto con la Cartera de Servicios, y revisar cuando debe

actualizarlos junto con el coste de dicha actualización. Así, la monitorización y medición, junto

con la predicción de situaciones, provocarán una serie de medidas a realizar.

El Plan de Capacidad

La Gestión de capacidad se pondrá en marcha al aparecer la necesidad de un nuevo servicio,

modificar uno anterior, una interrupción, un cambio de estrategia… cuando esto sucede se

pondrá en marcha la gran maquinaria cuyo corazón llamamos Sistema de Información para la

Gestión de la Capacidad (CMIS).

Definición: Sistema de Información para la Gestión de la Capacidad (CMIS).

Repositorio virtual de todos los datos del proceso de Gestión de Capacidad, típicamente

almacenados en múltiples localizaciones físicas.

A este entorno lo llamamos Plan de Capacidad, y consiste en una serie de elementos obtenidos

gracias a la evaluación de unas entradas y unas salidas y a la planificación consecuente. Entre

ellos destacan las previsiones de las cargas de trabajo, las tendencias de negocio, la

actualización de las tecnologías necesarias u obsoletas, el listado de problemas relativos a la

capacidad, etc.

Definición: Plan de Capacidad: El Plan de Capacidad se usa para gestionar los Recursos

requeridos para proveer Servicios de TI. El Plan contiene escenarios para distintas predicciones

de demanda de Negocio, y las opciones valoradas para proveer los Objetivos de Nivel de

Servicio acordados.

Para poder crear un plan de Capacidad debe disponerse de estas entradas:

Información financiera

Información de cambios y rendimiento.

Información de capacidad de los componentes

Información de los servicios procedentes de estrategias TI

Información del negocio

Información de los requisitos futuros

Un CMIS inicial

Cualquier tipo de información relacionada con la experiencia previa.


15

Así se podrá obtener como salida:

Un Plan de Capacidad

Un CMIS actualizado

Análisis de trabajos

Informes de carga de trabajo

Predicciones

Hitos, alertas, eventos, planificaciones.

Información del rendimiento de los servicios.

Procesos de la Gestión de Capacidad

Se compone de tres procesos:

Gestión de la Capacidad del Negocio (BCM) Transforma los requisitos

proporcionados por el cliente en los requisitos técnicos iniciales para el servicio TI.

Algunos de sus subprocesos son:

Soporte: La SLM se verá apoyada por la Gestión de Capacidad para

transformar los SLR (Requisitos de Nivel de Servicio) en configuraciones del

servicio.

Configuración del servicio: Recomendaciones para los nuevos servicios o

modificaciones en los existentes (como hardware y software).

Verificación y aprobación del SLA: De nuevo, la Gestión de Capacidad se

relaciona directamente con la SLM para proponerle nuevos SLA y mantenerlos

actualizados.

Implementación: Control y monitorización de todos los cambios durante el

Ciclo de Vida.

Gestión de Capacidad del Servicio (SCM) Se encarga de controlar y predecir el

rendimiento de los servicios TI (recursos humanos y materiales, estado de procesos,

modificaciones …) , para garantizar los objetivos definidos en los SLAs.

Gestión de Capacidad de los Componentes (CCM) En este caso gestiona los

componentes de un servicio TI, especialmente la infraestructura de soporte (como los

equipos, las redes, los sistemas de comunicación). La actividad en concreto se efectúa

durante la Operación del Servicio.


16

4.8 DS. Gestión de Disponibilidad

La disponibilidad de los servicios

La Gestión de Disponibilidad debe encargarse de garantizar que la Cartera de Servicios cumple

o incluso supera las necesidades actuales y futuras en cada uno de los servicios creados.

Esta gestión servirá de guía tanto para el cliente como para el proveedor de servicios, y se

encargará de las medidas proactivas para mejorar la eficiencia en costes, disponibilidad y para

colaborar en el diagnóstico de problemas relacionados con esa disponibilidad. En definitiva,

garantizarla en todo momento.

Cubre además todos los aspectos relacionados con los servicios actuales y futuros, como

procedimientos, herramientas, infraestructuras TI, formación, competencias e impacto

durante todo el Ciclo de Vida del Servicio.

La disponibilidad de los Servicios está en relación directa con la satisfacción de los clientes.

En el caso de un fallo, esa satisfacción puede mantenerse con una respuesta eficaz.

El plan de Disponibilidad

La Gestión de la Disponibilidad se encarga de mediciones diferentes, según el punto de vista

del negocio, del usuario de los servicios o del proveedor de servicios TI. En general debe

valerse de estos KPIs para medir la eficacia y eficiencia de los servicios, y su disponibilidad

durante su existencia:

Porcentaje de reducción de costes derivados de la falta de disponibilidad.

Porcentaje de mejora de disponibilidad global del servicio.

Porcentaje de mejora en la satisfacción de los clientes.

Porcentaje de reducción de la falta de disponibilidad de servicios y componentes.

Porcentaje de fiabilidad de servicios y componentes.

Toda la información de la disponibilidad, no sólo de los servicios, sino también de los

componentes que se van a emplear en ellos, se almacena en el Sistema de Información para la

Gestión de Disponibilidad (AMIS). Este sistema sirve para crear el Plan de Disponibilidad.

Para poder crear un plan de disponibilidad efectivo y que se aseguren la continuidad del

Negocio (es decir, la falta de interferencia para que este continúe sin percances) debemos

recopilar una serie de entradas:

Funciones Vitales del Negocio Necesidades imprescindibles para la posibilidad de que continúen los servicios y actividades que sustentan al negocio.


17

Estrategias y planes financieros de la organización Son la base para poder establecer una cartera de Servicios.

Requisitos de TI Son necesarios para conocer los componentes de los Servicios (si dichos componentes no están disponibles, tampoco lo estarán los servicios).

Análisis De riesgos estructurales, de impacto, etc.

Resultados del SLM Se utilizarán junto con los Planes de Capacidad para crear nuevos Planes de Disponibilidad.

Calendarios Entregas y pedidos, cambios, etc, gestionados por sus respectivos procesos.

Información previa Información de una Cartera de Servicios previa.

Información de disponibilidad anterior Informes de fallos y falta de disponibilidad.

Objetivos Objetivos de los servicios.

Conociendo estas características y otras que sean de importancia para el negocio en concreto

podremos crear el Plan de Disponibilidad, el AMIS, y todo el sistema de registro,

monitorización y programación de servicios asociado a la Disponibilidad.

Nota

También se crearán las PSO cuando sea necesario (Paradas de Servicio Previstas) y las

paradas de mantenimiento preventivo.

Disponibilidad: Acciones Proactivas y Reactivas

Por tanto, según la descripción ofrecida hasta ahora, la disponibilidad de los servicios afectará

al proveedor de servicios, al usuario o cliente final y en definitiva, a todo el negocio en general

para lograr cubrir los objetivos. Para lograrlo es necesario implantar una estrategia reactiva y

proactiva.

Acciones Proactivas Se ejecuta en la fase de la Estrategia y Diseño del Servicio en forma

de actividades preventivas.

Identificar las Funciones Vitales del Negocio. (VBF)

Análisis de Fallos. Por grupos o árboles (FTA), de forma individual (SPOF) o análisis del

impacto de los fallos de los componentes (CFIA)

Modelado y programa de pruebas de disponibilidad.


18

Análisis de riesgos, gestión y mantenimiento planificado y preventivo.

Nota

También la creación de un documento de Disponibilidad de Servicio Planificada (PSA).

Revisión y Mejoras continuas.

Acciones Reactivas Se ejecuta en la fase de Operación del Servicio y la Mejora Continua

del Servicio.

Análisis de falta de disponibilidad

Análisis de Fallos del Servicio (SFA)

Monitorización de la disponibilidad (servicios, sistemas y componentes).

Ciclo de Vida expandido de la incidencia.

Ciclo de Vida ampliado: MTRS

Para mostrar los fallos y restauración de un servicio, recurrimos al Ciclo de Vida ampliado. En

él mostraremos exclusivamente el proceso desde la detección de un fallo hasta la restauración

del servicio.

Para emplearlo correctamente, es necesario conocer dos términos adicionales: MTRS y

Redundancia.

MTRS Es el Tiempo Medio de Restauración de Servicios, es decir, una medida tangible

que poder revisar ante la caída de un servicio hasta lograr su funcionamiento con

normalidad. Para poder calcularlo influyen los MTRS de cada proceso, las políticas, los

recursos, la configuración de activos del servicio, personal de soporte y la redundancia.

Los MTRS están compuestos de estos componentes (por lo que hay que reducir la duración

de cada uno de ellos)

Detección de la incidencia: El periodo de tiempo desde que se produce una incidencia

hasta que es detectada.

Diagnóstico de incidencia: El periodo necesario para diagnosticar y evaluar el fallo.

Reparación de incidencia: Descriptor de en qué momento se solventó la incidencia.

Recuperación: Momento en que se completa la recuperación de un componente.

Restauración: Momento en que el servicio vuelve a funcionar con normalidad.

Nota

En ocasiones también puede emplearse el MTBF (Tiempo Medio que un Servicio funcionará sin

fallos), MTBSI (Tiempo Medio entre Fallos de un Sistema o Servicio) y MTTR (Tiempo de

reparación de un servicio, desde la detección del fallo hasta la reparación, sin contar el tiempo

de restauración).


19

Ciclo de Vida ampliado: Redundancia

Redundancia Es la manera de aumentar la disponibilidad de un servicio, se puede

clasificar según las características y puede ser:

Según su respuesta:

Activa: Acciones preventivas y siempre en acción.

Pasiva: Acciones reactivas tras un fallo.

Según los medios empleados:

Homogénea: Cuando el fallo es sobradamente conocido y se puede solventar con un

activo del servicio similar.

Heterogénea: Cuando el fallo es más impredecible, se emplean diferentes formatos y

elementos para solucionarlo.

Nota

Para aumentar la disponibilidad, también pueden emplearse distintos sistemas de acceso

como una Red cerrada (redundancia homogénea), Varios canales (redundancia

heterogénea) o Conexión difusa (distintas formas de acceso cambiantes y adaptables).

Disponibilidad, Fiabilidad y Capacidad

La Gestión de Disponibilidad tiene la responsabilidad de monitorizar, medir e informar acerca

de estos aspectos:

Disponibilidad: Todos los servicios o procesos y componentes asociados, deben poder

realizar la función para la que fueron concebidos cuando sea necesario.

Fiabilidad: El servicio debe ejecutarse sin interrupciones debidas a fallos, durante el

tiempo que se haya estimado.

Capacidad de mantenimiento: Si un servicio, sistema o componente, sufre algún fallo, la

capacidad de mantenimiento es la forma de medir el tiempo necesario para restaurarlo.

Capacidad de servicio: La capacidad que el proveedor de servicios dispone para poder

ofrecer un determinado servicio con el contrato acordado.

Toda la información necesaria y el nivel de componentes para el proceso de Gestión de

Disponibilidad están contemplados en el Sistema de Información para la Gestión de la

Disponibilidad (AMIS). Es además la base con la que se crea un plan de disponibilidad, que

cubra dos años iniciales, con revisiones trimestrales y mejoras semestrales y que incluya:


20

Niveles de disponibilidad actuales, desde el punto de vista del cliente.

Requisitos para servicios actuales y futuros.

Programación y revisión del Análisis de Fallos del servicio (SFA)

Oportunidades de actualizaciones planificadas.


1


Unidad 5: Procesos DS, TS. Configuración y Continuidad del Servicio

Índice

5.1. Introducción

5.2. DS. Gestión de la Seguridad de la información (ISMS)

5.3. DS. Gestión de suministradores

5.4. DS. Gestión de la continuidad del servicio de TI (ITSCM)

5.5. TS. Gestión de cambios

5.6. TS. Gestión de activos y configuración del servicio (SACM)


2

5.1. Introducción

Introducción

Una vez finalizados los procesos iniciales donde se realiza la Gestión Financiera, se

establece la Demanda y los Niveles de Servicio, y se habilita un Catálogo de Servicio

con alta disponibilidad, debemos proceder con el resto de procesos que nos permitan

Gestionar los servicios según una correcta metodología propuesta por ITIL®.

En esta unidad continuaremos analizando los procesos restantes encuadrados en el

Diseño del Servicio y en un primer acercamiento a la fase del Ciclo de Vida donde se

realiza la TS mediante el estudio de los cambios.

Esquema: Procesos del DS y la TS

Resumimos los ya vistos hasta ahora, y los que revisaremos en esta unidad:

Gestión Financiera

Gestión de la Demanda (DM)

Gestión de Cartera de Servicios (SPM)

Gestión de Niveles de Servicio (SLM)

Gestión del Catálogo de Servicios


Gestión de la Disponibilidad

Gestión de la Seguridad de la Información (ISMS)

Gestión de los Suministradores

Gestión de la Continuidad del Servicio (ITSCM)

Gestión de Cambios

Gestión de Activos y Configuración del Servicio (SACM)

SS

DS

TS

UN

IDA

D 4

Ciclo de Vida

UN

IDA

D 5


3

5.2 DS. Gestión de la Seguridad de la información (ISMS)

Características de la ISMS

ITIL® también contempla la Gestión de la Seguridad de la Información, para garantizar tanto la

disponibilidad de los servicios como la gestión de seguridad asociada. En particular:

Disponibilidad Garantizar la Disponibiidad de los servicios, y el acceso a los mismos.

Confidencialidad Garantizar el acceso de algunas personas a ciertos servicios

mientras que a otras se les excluye.

Integridad Garantizar la protección contra cambios no autorizados y la integridad

de la información.

Autenticidad Garantizar la confiabilidad de las transacciones y del intercambio de

información.

Actividades y políticas de la ISMS

Para ello es necesario crear un Sistema de Gestión de la Seguridad de la Información (ISMS)

que realice estas acciones:

Delimitar claramente los requisitos de seguridad acordados, tanto en la actualidad

como en el futuro del servicio.

Crear una política de seguridad de la información adecuada.

Implementar y mantener dicha política, junto con la documentación asociada.

Distribuir y mejorar la política entre todos los actores que intervengan. (Proveedores,

clientes y servicios).

Mejorar las políticas de seguridad de forma proactiva, y limitar las ocasiones en que se

haga de forma reactiva.

Definición: Política de Información: Documento formal que gobierna la ISMS y contiene

intenciones y expectativas de gestión. Se emplea para dirigir las decisiones y asegurar un

desarrollo adecuado de Procesos, Estándares, Roles, Asctividades, Infraestructura de TI, etc.

Nota

Es recomendable que esté respaldado por la certificación ISO 27001 y otras ‘buenas

prácticas’ de calidad.


4

Métricas de la ISMS

ISMS es un proceso continuado, que debe ser apoyado e impuesto desde la directiva de la

empresa, y está compuesto por una serie de medidas preventivas, bloqueantes, correctivas…

en definitiva, acciones que ayuden a mejorar la Gestión de Nivel de Servicio, Gestión de

cambios y Gestión de incidencias y problemas.

Distintos cambios de procesos, nuevas políticas, planes de negocio, incumplimiento de

seguridad… deben provocar como resultado nuevos ISMS, nuevas políticas asociadas,

controles, auditorías y procesos de evaluación de toda índole.

Finalmente se verán reflejados en los KPIs como:

Aumento de procedimientos de seguridad y depuración de los existentes.

Mayor aceptación de los procedimientos de seguridad.

Disminución de las incidencias y fallos de los servicios.

Disminución de los fallos de seguridad.

5.3 DS. Gestión de suministradores

La Base de Datos de Suministradores y Contratos (SCD)

Tras abordar el problema de la gestión del Catálogo de Servicios, y de la Disponibilidad y

Seguridad, resulta imprescindible abordar la Gestión de los suministradores.

La calidad de los servicios del proveedor TI, se verá directamente afectado por la calidad de los

suministradores asociados. Por tanto, mediante esta Gestión, se delimitarán los servicios TI

finales y se lograrán los precios más adecuados al objetivo final: mantener la calidad.

Este proceso se encargará de categorizar, realizar el seguimiento, contratar y en definitiva

encargarse de la gestión de suministradores externos o internos. Es importante mantener este

sistema mediante una Base de Datos de Suministradores y Contratos (SCD).

Nota

La SCD debe incluir los contratos, detalles de los suministradores, detalles del servicio, y

diversas configuraciones.


5

Características del contrato con los suministradores

Especialmente los servicios de los suministradores externos, deben quedar plasmados en un

contrato con estas fases:

1. Identificación de las necesidades

Crear un plan de requisitos (SOR) y/o un pliego de oferta (ITT).

Preparar un caso de negocio inicial (requisitos, políticas y objetivos).

2. Evaluación de Suministradores

Identificar un método de aprovisionamiento

Normalizar los criterios de selección

3. Aprovisionamiento y contratos

Realizar la selección (selección, negociación y contratación).

Actualizar la SCD con los nuevos suministradores

Realizar la Transición del servicio (estableciendo interfaces entre contactos y servicios).

4. Categorización de suministradores

Evaluar y Categorizar los suministradores y contratos.

Mantener actualizada la SCD

5. Gestión del rendimiento

Gestionar el correcto servicio del suministrador

Monitorizar, documentar y revisar la entrega.

Mejorar

Revisar el alcance del servicio, las necesidades del negocio y la dependencia del

suministrador.

6. Finalización de contratos.

Revisar y renegociar los contratos (terminar o renovar).


6

5.4 DS. Gestión de la continuidad del servicio de TI (ITSCM)

Funciones de la ITSCM

La Continuidad del Servicio de TI representa a los procesos necesarios para garantizar la

continuidad del negocio. Entre algunas de sus responsabilidades están:

Efectuar periódicamente Análisis de Impacto sobre el Negocio (BIA).

Crear y mantener una serie de planes de recuperación y continuidad, y que están listos

en todo momento. (Y negociarlos con otros proveedores cuando sea necesario).

Analizar estimaciones de riesgo periódicamente, e implantar medidas proactivas para

prevenir dichos riesgos y mejorar la disponibilidad.

Cuantificar el impacto de los cambios sobre los planes actuales.

Asesorar al resto de áreas de negocio de los planes de continuidad y recuperación.

Adaptar los planes de continuidad de servicio a los planes de continuidad del negocio.

Gestión de Incidencias

Así pues, debe garantizar que todos los servicios TI, aplicaciones, instalaciones, Soporte

Técnico y Centro de Servicio al Usuario, estén coordinados para funcionar según el acuerdo de

negocio. (Se incluyen los repositorios, telecomunicaciones, sistemas informáticos… )

Gestión de Incidencias Es importante diferenciar ITSCM de la Gestión de Incidencias. La

Gestión de Incidencias se encarga de problemas más leves, que pueden afectar a un limitado

número de procesos o servicios, pero no a la totalidad del negocio.

Ciclo de Vida de la Continuidad del Servicio.

Se debe conocer y planificar el Ciclo de Vida de la continuidad de cada uno de los servicios TI, a

partir de un modelo genérico dividido en cuatro fases:

1. Iniciación: Es importante concretar los objetivos del negocio, las políticas y planes

asignados al servicio a tratar.

Definición del proyecto

Asignación de recursos (materiales, personales y económicos)

Definición de política y alcance, y documentación de los mismos.

Acuerdo del servicio y plan de calidad asignado.


7

2. Requisitos y estrategia: Hay que definir de forma clara los requisitos necesarios y las

estrategias de acción para satisfacerlos.

Nota

En la siguiente pantalla conoceremos más detalles de los requisitos y estrategias).

3. Implementación: El proceso de aprobación e implantación de los planes ITSCM debe estar

gestionado por un alto directivo, un coordinador y los equipos de recuperación de errores.

Deben realizarse:

Pruebas básicas

Pruebas completas

Pruebas parciales de cada componente

Escenarios de prueba concretos.

4. Operación continuada: Finalmente debe haber un proceso de mantenimiento continuo,

para asegurar la calidad del servicio, con algunas acciones como:

Formación del personal.

Revisión y auditoría

Realización de las pruebas

Gestión de Cambios

Prueba definitiva

ITSM: Requisitos y Estrategias

A continuación enumeramos los requisitos para la continuidad del servicio y las posibles

estrategias a emplear.

Requisito: (BIA) Análisis de Impacto sobre el Negocio Evalúa el impacto debido a la

pérdida de servicio. Puede ser Tangible como la rotura de un cable, o Intangible como

el catarro de un empleado, e informa de:

El tipo de pérdida.

La forma de escalado del daño.

Los recursos y competencias que deben asignarse para dar continuidad a los

procesos de mayor importancia.

Los plazos de recuperación total o parcial del servicio.


8

Requisito: Ponderación del riesgo Evalúa los riesgos de una interrupción del

servicio por un fallo o un atentado de seguridad. Para solventar las situaciones por

estas situaciones se recomienda utilizar la Gestión del Riesgo (MoR).

Principios de MoR.

Planteamientos de MoR (organización).

Identificación, evaluación, planificación, implementación (procesos de MoR).

Incorporación y revisión de MoR.

Comunicación.

Estrategia: Medidas de reducción del riesgo La reducción de fallos está relacionado

con la Gestión de Disponibilidad, y debe basarse en los mejores controles de

seguridad, en el uso de las versiones más estables y actualizadas, sistemas tolerantes a

fallos, etc.

Estrategia: Recuperación de ITSCM No siempre es posible implantar las medidas de

reducción de riesgo deseadas, cuando conllevan unos costes económicos inasequibles,

por tanto pueden surgir otras medidas como:

Soluciones provisionales: Medidas temporasles por un tiempo limitado.

Recuperación gradual (Cold Standby): Los recursos principales se recuperan en

pocos días (4 aproximadamente) de una forma más económica que el servicio

completo.

Recuperación intermedia (Warm Standby): Los recursos principales se recuperan

en dos o tres días, con una pre-instalación, por ejemplo.

Recuperación rápida o inmediata (Hot Standby): Un mínimo de servicios

principales se recuperan en un plazo nunca superior a 24 horas.

Acuerdos recíprocos: Organizaciones o secciones similares, con infraestructuras

parecidas, llegan a un acuerdo de soporte.

Resumen de la Gestión de la Continuidad del Servicio TI (ITSCM)

A continuación resumimos la información acerca de la Gestión de la Continuidad del Servicio TI

(ITSCM).

Responsabilidades ITSCM

Análisis de impacto Efectuar periódicamente Análisis de Impacto sobre el Negocio

(BIA).


9

Plan de recuperación Crear y mantener una serie de planes de recuperación y

continuidad, y que están listos en todo momento. (Y negociarlos con otros

proveedores cuando sea necesario).

Estimar riesgos Analizar estimaciones de riesgo periódicamente, e implantar

medidas proactivas para prevenir dichos riesgos y mejorar la disponibilidad.

Impacto Cuantificar el impacto de los cambios sobre los planes actuales.

Asesorar Asesorar al resto de áreas de negocio de los planes de continuidad y

recuperación.

Adaptar Adaptar los planes de continuidad de servicio a los planes de continuidad

del negocio.

Ciclo de Vida de la continuidad del servicio TI

Iniciación Se concretan los objetivos del negocio, las políticas y planes asignados al

servicio a tratar.

Enumeración de requisitos Se enumeran los requisitos para la continuidad del

servicio y las posibles estrategias a emplear.

Implementación Aprobación e implantación de los planes ITSCM, gestionado por un

alto directivo, un coordinador y los equipos de recuperación de errores.

Operación continuada Finalmente debe haber un proceso de mantenimiento

continuo, para asegurar la calidad del servicio.

Gestión de Incidencias vs ITSCM

Gestión de Incidencias La Gestión de Incidencias se encarga de problemas más

leves, que pueden afectar a un limitado número de procesos o servicios, pero no a la

totalidad del negocio.

Gestión de la continuidad del servicio TI (ITSCM) La Gestión de continuidad del

servicio TI se encarga de los procesos necesarios para garantizar la continuidad del

negocio.

5.5 TS. Gestión de cambios

Gestión de Cambios

Llegados a este punto, los procesos del Diseño del Servicio han quedado establecidos y llega el

momento de revisar los que están directamente relacionados con la Transición del Servicio

dentro del Ciclo de Vida.

La Gestión de cambios debe encargarse de responder ante los cambios efectuados en el

negocio, solicitudes de cambio de TI o cambios en el negocio del cliente.


10

Definición: Un cambio es la adición, modificación o eliminación de un servicio, o un

componente de un servicio, autorizado, planificado o soportado, y de su documentación

asociada.

Actividades de la Gestión de Cambios

Así pues, cada organización debe registrar sus procesos de Gestión de Cambios, con la

información clara de qué les compete y qué no. En cualquier caso siempre deben:

Registrar todos los cambios que se produzcan

Evaluar los riesgos y cambios adicionales que impliquen.

Priorizar cada uno de los cambios, para maximizar la eficiencia y eficacia

Planificar los cambios proactivos y los cambios reactivos

Autorizar cada cambio según sus características y asignación.

Probarlos, aun cuando sean repetitivos.

Implementar los cambios y gestionar dicha implementación.

Documentar cada uno de los cambios realizados

Revisarlos periódicamente para evitar riesgos imprevistos.

Nota

Generalmente los cambios implican un descenso en la calidad de los servicios, sin

embargo, con la Gestión de Cambios, puede evitarse, e incluso aumentar el nivel de

calidad (reduciendo el número de fallos, modificando procesos con antelación a

normativas, reducción del TMRS…).

Comité de Cambios (CAB)

Debe crearse un Comité de Cambios (CAB) con los actores de los servicios TI (suministradores,

proveedor, cliente, expertos, usuarios finales…) para reunirlo de forma periódica y planificar

los cambios a realizar. Todos ellos deben estar perfectamente documentados, y definir sus

efectos positivos y negativos, tanto si se efectúan como sino. Entre sus tareas son

imprescindibles:

Solicitudes Nuevas solicitudes de cambios que deben ser revisadas por CAB.


11

Gestión Monitorización de cambios actualmente en curso o cerrados.

Autorización Análisis y aceptación de cambios o denegación de los no autorizados.

Otros cambios Cambios autorizados por otros departamentos responsables

excluidos del CAB.

Tipo de Solicitudes de Cambios

El CAB clasificará los cambios y priorizará todas las solicitudes de cambios que reciba. Según

los riesgos que impliquen y la categoría en la que se encuadren podemos distinguir entre:

RFC o Solicitud de cambio Se realiza una petición para modificar diferentes

elementos de configuración en un proceso.

Cambio estándar Son los cambios, usualmente rutinarios que registra la Gestión de

Cambios. Suelen estar pre-aprobados e implicar bajo nivel de riesgo. Se suelen solicitar

en el proceso de Gestión de Peticiones.

Cambio Normal Cualquier modificación, adición o eliminación de un servicio o

componente del servicio. Según el impacto que represente en el servicio se puede

categorizar en:

- Cambio Menor: Poco impacto en el servicio. El Gerente de Cambios autoriza el

RFC (No es necesario el CAB).

- Cambio Sustancial: Un impacto claro en el servicio. El Gerente de cambios

solicita asesoramiento del CAB para la autorización y programación,

especialmente a la Gestión de Versiones y Despliegues.

- Cambio Grave: Un alto impacto en los servicios y en el negocio. Se convoca al

CAB y a la Dirección para la toma de decisiones y asignación de recursos y/o

personal.

Cambio de emergencia Cambios debidos a un fallo en un servicio. El CAB debe

autorizarlo, aunque de una forma más rápida que los cambios planificados. Suele

crearse un Comité de Cambios de Emergencia (ECAB).

Las acciones realizadas en la Gestión de Cambios representa un impacto importantísimo sobre

el negocio y otros procesos de Gestión de Servicio, en especial sobre la Gestión de Problemas,

de Continuidad del Servicio, de la Seguridad de la Información, de la Capacidad, Demanda, y de

la Configuración y Activos del Servicio.

Ciclo de Vida de los cambios


12

A continuación mostramos el proceso lógico que debe seguir la Gestión de Cambios ante un

cambio normal (los cambios estándar o de emergencia sólo deben modificarlo levemente):

1. Nuevo RFC Nueva solicitud de cambio RFC. Se produce la necesidad de un cambio,

desde un equipo de trabajo, un servicio, el cliente o un individuo independiente. Se

registrará con un identificador único y se detallará la información relativa al cambio y a las

consecuencias.

2. Propuesta de RFC Se revisará el cambio solicitado, en especial el presupuesto, la

importancia y la comparación con otros existentes (para evitar duplicidad o solapamiento).

Si es aceptado se pasa a la siguiente fase, en caso contrario se informa al solicitante de los

motivos y se ofrece posibilidad de apelación.

3. Evaluación del cambio Se valoran los riesgos y se categoriza (suele usarse una matriz de

categorización del riesgo). Posteriormente se evalúa, y el Gestor de Cambios o el CAB

decidirán si se realiza. Este proceso se subdivide a su vez en tres subprocesos que

analizaremos en el próximo punto: Estudio del cambio, Prioridad y Planificación.

4. Autorización de Cambios Un responsable superior, un departamento, o un especialista

autorizará los cambios planificados.

5. Actualización de planificación Es necesaria una revisión de la planificación inicial en

todas las fases del servicio (especialmente las más importantes como transición, entrega y

pruebas).

6. Implantación Se construyen y crean los paquetes de cambios a entregar. El equipo

técnico efectuará la Gestión de entregas, despliegues y versiones, y el equipo de pruebas se

encargará de validarlos en la sección de Validación y Pruebas del servicio.

7. Revisión y finalización del cambio El CAB evaluará si el cambio ha resultado efectivos

una vez se hayan aplicado y valorará si los afectados han quedado satisfechos, si el proceso

se ha efectuado sin contratiempos, y si las previsiones de recursos han sido adecuadas.

Evaluación y Planificación

La evaluación del cambio es una parte vital al comienzo del Ciclo de vida de la Gestión de

Cambios. Según la clasificación que se conceda a cada uno, se asignará una serie de medidas

pertinentes. Esta fase se subdivide en tres subprocesos:

Estudio del cambio: Mediante las Siete R se realizará un estudio de impacto sobre el

servicio

1. ¿Quién solicitó el cambio? (Reclamación)

2. ¿Cuál es el motivo del cambio? (Razón)


13

3. ¿Cuál es el resultado requerido con el cambio? (Resultado)

4. ¿Qué riesgos presenta el cambio? (Riesgo)

5. ¿Qué recursos se necesitan? (Recursos)

6. ¿Quiénes son responsables de construir, probar e implementar el cambio?

(Responsabilidad)

7. ¿Qué relaciones existen entre este cambio y otros? (Relación)

Prioridad: Se estudia la prioridad e importancia de todas las respuestas obtenidas en

el estudio previo, y se subclasifican en:

1. Prioridad inmediata: Un cambio que requiere una acción inmediata e implica un

cambio en relación con un fallo importante del servicio o gran pérdida económica.

2. Prioridad alta: Será un cambio debido a un fallo grave para varios usuarios y con

relación directa con un problema urgente. En la siguiente reunión del CAB deberán

evaluarlo sin demora.

3. Prioridad media: Un cambio que carece de urgencia o con un impacto asumible.

Sin embargo no se puede posponer, y el CAB lo tratará a continuación de los de

prioridad alta, asignándole recursos restantes.

4. Prioridad baja: Un cambio que no se ejecutará hasta la liberación de recursos, pero

que sólo supone una mejora de la calidad y no implica necesidad.

Planificación: Se establece una planificación llamada Programación de Cambios (SC),

donde se fija un calendario que agrupe varios cambios en una misma entrega, y

afecte al mínimo a los participantes en el servicio.

Tras realizar esta evaluación, es habitual la creación de un listado de los cambios propuestos,

ordenados de forma metódica, y que incluyan matrices donde queden categorizados. Así la

Gestión de Cambios podrá administrarlos sabiamente y proyectarlos a través del tiempo de

una forma controlada.

5.6 TS. Gestión de activos y configuración del servicio (SACM)

El Sistema de Gestión de la Configuración (SCM)

El último proceso de Gestión de Servicio que vamos a ver en esta unidad es La Gestión de

activos y configuración del servicio (SACM). Este proceso se encarga de relacionar los

componentes de servicio TI con el propio servicio que ayudarán a proporcionar.


14

A estos componentes se les denomina activos del servicio, y deben estar fijados y protegidos

en un Sistema de Gestión de la Configuración (CMS). Así se creará una infraestructura estable

para la construcción de servicios.

SACM afecta a todos los activos del Ciclo de Vida del Servicio, e incluso a otros activos TI

ajenos a él, como productos adicionales, componentes de otros proveedores y configuraciones

(no son propiamente activos).

Por tanto, mediante SACM, lograremos concretar estos activos, y por tanto optimizar las

previsiones, cambios, costes, incidencias y en definitiva objetivos, en un entorno controlado.

Elemento de Configuración (CI)

Dentro de los Activos del Servicio destacan los Elementos de Configuración

Definición ITIL: Elemento de configuración (CI) Es un activo, componente de servicio u

otro elemento que está (o estará) bajo el control de Gestión de la Configuración.

Existen diferentes CI

CIs del servicio Activos de recursos del servicio, modelos, paquetes, políticas y

criterios, activos de recursos…

CIs del Ciclo de Vida del Servicio Relacionados con actividades del ciclo del Ciclo de

Vida del Servicio (por ejemplo, un plan de pruebas).

CIs organizativos Documentación, calendario, tareas…

CIs internos CIs propios de determinados proyectos o procesos independientes.

La Gestión de la Configuración mantiene el Sistema de Gestión de la Configuración (CMS). En

este sistema se incluyen las bases de datos que almacenan los CI, las herramientas para su

manejo y toda la información sobre los incidentes, problemas, cambios, versiones y errores

conocidos. Por tanto, el CMS está íntimamente relacionado con todos los Elementos de

Configuración y las diferentes relaciones que los unen, a la vez que las actualiza en todo

momento.

Ciclo de Vida de SACM

Un proceso SACM debe llevar a cabo estas fases:

1. Dirección y Planificación Tarea llevada a cabo por el equipo directivo y la Gestión de

Configuración donde deciden el entorno de gestión y queda plasmado en el Plan de

Gestión de Configuración. Deben definir:

Los objetivos

El Contexto inicial (Requisitos, políticas iniciales, estándares a aplicar)


15

Organización general (Roles , responsabilidades, relaciones, referencias,

proveedores).

Sofware, hardware y otras herramientas

Procesos

Plan de implantación

Alcance.

2. Identificación de la Configuración En esta fase se establecen los nombres y números de

versión de los elementos de configuración y activos. En cada servicio TI debe crearse una

configuración diferente. Para ello deben:

Definir el criterio para la asignación de los nombres, y las relaciones entre los

componentes.

Categorizar los elementos según esos criterios.

Especificar los atributos de cada elemento de configuración. Nota. En la siguiente

pantalla expandiremos esta información.

Indicar cuando y quién usará cada elemento.

Asignar un identificador único a cada elemento de configuración con un convenio

estándar.

Documentar criterios y asignaciones.

3. Control de la configuración El control de la configuración se encarga de la gestión de

todos los CIs. Al igual que se establece una Base de Datos para la Identificación de la

Configuración, en este caso se disponen una serie de procedimientos indispensables para

modificar cualquier elemento. Entre ellos están:

• Gestión de licencias

• Gestión de cambios

• Gestión de versiones

• Control de accesos

• Control de construcciones

• Promoción

• Despliegue

• Instalación

• Gestión de la integridad de configuraciones de línea base

4. Seguimiento y reporte del estado de la configuración En esta serie de tareas se

monitorizan las fases en la vida de los CIs, desde el registro inicial, hasta el cierre final y


16

retirada. Mediante una serie de informes y rutinas se realiza el seguimiento y se posibilita

la revisión del historial acumulado.

Los informes deben incluir información de los elementos, su estado, los cambios, las

referencias, las autorizaciones, y cualquier característica informativa de ellos.

5. Verificación y auditoría Aun cuando todas las fases de la Gestión de configuración y

activos sean robustas y eficientes, siempre es necesaria una verificación final y auditoría.

Siempre que exista alguna disconformidad con la auditoría también se debe documentar.

Debe realizarse siempre tras cualquier cambio en el CMS, aunque también como respuesta

a una entrada no autorizada, tras los cambios en un servicio TI (o previo a su realización), e

incluso de forma periódica y aleatoria.

Con ella se comprobará que:

Hay una documentación asociada a toda la Gestión de Configuración, previamente

al despliegue de la última versión.

La documentación es consecuente con la situación real del negocio y de los

servicios implicados.

Todos los CIs están documentados de forma actualizada, de modo que su

descripción permita su uso en el momento necesario y de forma correcta.

SACM: Atributos

Todos los elementos de configuración deben estar bien documentados y detallados. Estos

detalles se conocen como atributos dentro de una CMDB (Bases de Datos de Gestión de la

Configuración). Al menos deben crearse:

• Identificador.

Nota: Debe ser único (y ubicarlo bien visible en el Hardware). En la CMDB con forma de

número, etiqueta o código de barras.

• Tipo de CI

• Nombre/descripción

• Versión

• Ubicación

• Fecha de suministro

• Titular

• Suministrador/origen


17

• Documentación asociada

• Software asociado

• Datos históricos, i.e.: traza auditable

• Tipo de relaciones

• SLA aplicable

• Fecha de compra

• Fecha de aceptación

• Estado actual

• Estado planificado

• Valor de compra

• Valor residual después de depreciación

• Comentarios

SACM: Relaciones

Todos los elementos de configuración deben quedar bien detallados por los atributos que los

definen. Esta información se debe completar con la relación existente entre todos los CI.

Las relaciones y los atributos permiten clasificar los CIs (Software, Hardware,

Documentación…), a la par que vincularlos con las Incidencias, Errores Conocidos, Problemas,

Solicitudes de Cambio (RFCs) y Versiones. Todas las dependencias y relaciones se almacenan

en la CMDB.

La SACM tiene, por tanto, una relación directa con la Gestión de Versiones y Despliegues. Una

vez se ha plasmado toda la información de los elementos de configuración, se definen las

Unidades de entrega según las políticas de la organización: Porción del servicio o

infraestructura que se entrega como conjunto. (Ver la Unidad 7, Gestión de Versiones y

Despliegues para mayor detalle)


18

Resumen de los procesos de Gestión de Servicios

Ejemplo: Gestión de Servicios. A continuación exponemos una breve descripción de las

actividades que deben realizar algunos procesos de Gestión de Servicios.

Gestión del Catálogo de Servicios Se crea una fuente central de información con todos

los detalles de los Servicios de TI actuales y futuros que se ofrecen al cliente.

Gestión de Cambios La Gestión de cambios debe encargarse de responder ante los

cambios efectuados en el negocio, solicitudes de cambio de TI o cambios en el negocio del

cliente.

Gestión de la Demanda (DM) Realiza la gestión para asegurar que existe un equilibro

entre los servicios ofertados y la demanda de dichos servicios.

Gestión de Niveles de Servicio (SLM) Proceso encargado de garantizar el acuerdo o nivel

de servicio pactado para los servicios TI actuales y futuros.

Gestión de Activos y Configuración del Servicio (SACM) Este proceso se encarga de

relacionar los componentes de servicio TI con el propio servicio que ayudarán a

proporcionar.

Gestión de la Disponibilidad Es el proceso encargado de garantizar que la Cartera de

Servicios cumple o incluso supera las necesidades actuales y futuras en cada uno de los

servicios creados.

Gestión de la Seguridad de la Información (ISMS) Garantiza tanto la disponibilidad de los

servicios como la gestión de seguridad asociada.

Gestión de la Capacidad Es la encargada de revisar el equilibrio de las necesidades del

negocio (en la actualidad y en el futuro) y la capacidad de ofrecer los servicios relacionados

siempre que se justifiquen los costes.

Gestión Financiera Se encarga de cuantificar los costes de los servicios, evaluar sus

beneficios y descubrir los inconvenientes existentes.

Gestión de los Suministradores Este proceso se encargará de categorizar, realizar el

seguimiento, contratar y en definitiva encargarse de la gestión de suministradores externos

o internos.

Gestión de la Continuidad del Servicio (ITSCM) La Continuidad del Servicio de TI

representa a los procesos necesarios para garantizar la continuidad del negocio.


1


Unidad 6: Roles y responsabilidades

Índice

6.1. Introducción

6.2. Dueño del Proceso

6.3. Modelo RACI

6.4. Propietario del Servicio

6.5. Roles principales

6.6. Comunicación


2

6.1 Introducción

Introducción

ITIL está creado por y para las personas.

Para que los Servicios de TI deriven en satisfacción del cliente y en un beneficio

económico para el proveedor, deben apoyarse en los pilares más fuertes de la

organización: las Personas.

Los Procesos, Productos y Proveedores se supeditan a la estrategia marcada por la

empresa, y a los roles asignados a los equipos o individuos que formen parte del Ciclo

de Vida del Servicio. Un alto porcentaje de éxito en el resultado final se deberá a una

correcta distribución de roles y responsabilidades.

6.2 Dueño del Proceso

Dueño del Proceso

La inmensa mayoría de los Servicios, pueden dividirse en distintos procesos. Estos procesos

constarán de unas entradas, salidas e interfaces diferentes, que les permiten interactuar entre

sí.

Todos los procesos tienen un determinado nivel de calidad, que mide la efectividad de las

tareas que lleva a cabo. Para responder por los resultados finales de cada proceso se asigna un

Propietario del proceso. En la fase de DS es importante no sólo definir los procesos, sino los

dueños y los gestores de los mismos.

Definición ITIL®: Propietario del proceso: Es el Rol responsable de asegurar que un

Proceso coincide con su propósito. Las responsabilidades del propietario del proceso cubren el

patrocinio, diseño, gestión del cambio, mejora continua del proceso y sus métricas.

Nota

El Gestor del proceso, sobre todo en grandes organizaciones, es el responsable de la

ejecución y estructura del proceso, e informar al dueño del proceso.


3

Organización de los roles

Para mejorar la gestión de los procesos, un responsable efectúa organizaciones jerárquicas con

diferentes equipos o departamentos. Según la cantidad de subdivisiones y la forma de

cooperar entre sí se las conoce como:

Organizaciones planas Divisiones en pocos niveles jerárquicos. Suelen emplearse

en pequeñas empresas donde diferentes equipos o individuos tienen varios roles

asignados por un responsable de línea.

Organizaciones en red Es mucho más habitual hoy día. El responsable de línea fija

unos roles muy concretos en diferentes jerarquías, y a veces únicos, en cada equipo

de trabajo. Son muy vulnerables cuando no existe una buena comunicación entre

ellos.

Nota

En las organizaciones jerárquicas (planas y en red), las distintas personas suelen encargarse

de la línea de gestión.

Organizaciones de proyectos La forma de esta organización se basa en las

necesidades de un proyecto, según las tareas definidas en él. Incluye diferentes

configuraciones organizativas.

Nota

En las organizaciones de proyectos, suelen existir algunas personas que efectúan la labor de

responsable de los subprocesos internos.

Roles y responsabilidades

Los equipos o individuos tienen asignadas una serie de actividades y responsabilidades

respecto a otros equipos, personas, o procesos. A esto lo denominamos Rol.

La manera en que toman forma esos roles es el puesto de trabajo, donde se identifican las

funciones que debe desempeñar cada individuo. Generalmente, una misma persona suele

desempeñar diferentes roles similares o complementarios (por ejemplo el Gestor de

Incidencias a veces coincide como Gestor de Problemas en organizaciones pequeñas).

Los roles no sólo identifican responsabilidad y actividad sobre un procedimiento, sino también

autoridad o propiedad sobre procesos y/o personas.


4

6.3 Modelo RACI

El modelo RACI

A la hora de asignar las responsabilidades y roles a los distintos empleados, es importante

definir su alcance y detalles con claridad en el proceso del Diseño del Servicio. El modelo más

empleado, que llega a usarse como un estándar de hecho, se denomina modelo RACI:

Responsable, Alto responsable, Consultado e Informado.

Responsable La persona responsable o asignado para realizar la tarea.

Alto Responsable El responsable final del proceso.

Consultado Los encargados de asesorar durante la tarea.

Informado Personas que deben recibir información del progreso de los procesos.

Fases de un modelo RACI

Para crear una estructura organizativa, a partir de un modelo RACI deben realizarse estos

pasos:

1. Procesos Identificar todos los procesos y las acciones asociadas.

2. Roles Identificar los diferentes roles a asignar.

3. Asignación Mediante reuniones, asignar los códigos RACI a los empleados.

4. Detección Detección de superposición de roles y asignaciones incorrectas o

faltantes.

5. Comunicación Comunicación de todo el esquema

6. Revisión y Monitorización Comprobar que el modelo RACI creado funciona

correctamente.

6.4 Propietario del Servicio

Propietario del Servicio

Aunque puede dar lugar a confusión, el Propietario del Servicio no siempre tiene que coincidir

con los Propietarios de los Procesos implicados en el Servicio.


5

Propietario del Proceso Es el encargado de supervisar todas las actividades

relacionadas con ese proceso

Es el responsable de la estrategia del proceso.

Colabora en el diseño.

Debe gestionar los recursos.

Debe documentar los procedimientos y la aplicación de los mismos en el

proceso.

Propietario del Servicio Es el responsable final del Servicio. Por tanto se encarga de

gestionar la Transición del Servicio, y del mantenimiento del mismo de cara al cliente.

Distribuye las responsabilidades del servicio

Es el responsable final de la provisión del servicio ante los superiores.

Debe garantizar que el servicio cumple los requisitos iniciales.

Es la persona de contacto con el cliente y otros proveedores.

Nota

Puede observarse con las distintas tareas asignadas, que el Propietario del Proceso es un

‘responsable parcial’, más asociado a la fase de ES y DS, mientras que el Responsable del

Servicio es un ‘responsable total’, por lo que tiene que garantizar que el mismo se lleve a

cabo (TS y OS).

Capacidades de un Responsable

Ya sean Responsables de Servicios o de Procesos, para que sean asignados con ese Rol, deben

disponer de ciertas capacidades o aptitudes:

Disponer de dotes comunicativas, pues deberá usarlas con los clientes y otros

responsables.

Conocer las tecnologías de la información, y cómo pueden ayudar a los clientes o hasta

qué punto servirán para un propósito.

Conocer los objetivos del negocio y/o objetivos parciales de los procesos.

Tener habilidades para la traducción e interpretación, tanto de requisitos requeridos

como de las políticas que se deben aplicar.

Tener habilidades para la interpretación, análisis y monitorización de los

procedimientos.

Disponer de la capacidad y competencia para su función.


6

6.5 Roles principales

Roles principales

Cuando se proceda al Diseño del Servicio, sea mediante un modelo RACI o cualquier otro de

efectividad contrastada, surgirán una serie de roles. Entre los más importantes destacan los

siguientes, con sus correspondientes tareas:

Propietario del proceso Tiene la responsabilidad de garantizar la ejecución del

proceso según lo especificado y que se cumplan los objetivos.

Tareas:

Definir los PKI del Proceso (para poder evaluarlo)

Documentarlo para el Plan de Mejora del Servicio.

Monitorizar y revisar los roles, las responsabilidades

Monitorizar y mejorar el proceso.

Gestor del Diseño del Servicio Es el encargado del Diseño del Servicio y de la

coordinación general de roles.

Tareas:

Comprobar que el Diseño del servicio satisface los requisitos.

Diseñar el servicio y todos los elementos que intervienen en él.

Comprobar la eficacia y eficiencia del proceso de diseño.

Documentar todos los procesos de diseño.

Gestor del Catálogo del Servicio Debe crear y mantener el Catálogo de Servicios

Tareas:

Registrar todos los Servicios activos en el Catálogo de Servicios.

Comprobar que los Servicios del Catálogo están actualizados respecto a la

Cartera de Servicios.

Gestionar las copias de seguridad del Catálogo.

Garantizar la seguridad e integridad del Catálogo.

Gestor del Nivel del Servicio Tiene la responsabilidad de colaborar en la

preparación de la Cartera de Servicios para que satisfaga los SLA establecidos con los

clientes.

Tareas:

Colaborar en la creación y mantenimiento de la cartera de servicios.

Detectar nuevas demandas del mercado (por tanto, nuevos requisitos).


7

Definir los requisitos presentes y futuros para el negocio, y negociar nuevos

acuerdos de provisión de servicios en consonancia con ellos.

Garantizar que se cumplen los SLAs.

Gestor de la Disponibilidad La función principal es asegurar que todos los Servicios

ofertados del Catálogo están disponibles.

Tareas:

Colaborar en la creación y mantenimiento de la cartera de servicios.

Garantizar que los servicios en activo están siempre disponibles y colaborar con

acciones preventivas para sea así.

Colaborar con el diseño de la infraestructura de TI.

Colaborar en la detección, investigación y diagnóstico de incidentes y problemas.

Gestor de la Seguridad Debe diseñar y mantener las políticas de seguridad TI.

Tareas:

Diseñar y mantener las políticas de seguridad de la información.

Documentar y comunicar a los diferentes usuarios las políticas de seguridad que

les afectan.

Colaborar con el Gestor de Disponibilidad, analizando riesgos y proponiendo

medidas proactivas.

Realizar un análisis de impacto de las políticas de seguridad en el negocio.

Nota

Obsérvese, que los roles citados coinciden con los procesos definidos en el DS en el Ciclo de

Vida del Servicio. Además existen otros muchos responsables como Gestor de Capacidad,

Gestor de Suministradores, Diseñador de TI, etc.

6.6 Comunicación

La importancia de la comunicación

Hasta ahora hemos intentado definir roles, responsabilidades y distintos responsables que

pueden intervenir en un Servicio. Resta sólo un aspecto importante, la Comunicación entre

todos los implicados en cada una de las tareas.

La Comunicación será lo que permita tomar decisiones, realizar ciertas actividades, y sobre

todo, coordinar todas las tareas para lograr la mayor eficiencia y efectividad. Con ella se

conseguirá:


8

Delimitar funciones, tareas, incompatibilidades y roles confusos.

Evitar errores por el uso de herramientas incorrectas.

Optimizar los procedimientos

Servir como fuente de información adicional a la documentación estandarizada.

Aunque existen diversas formas de comunicación en una empresa, la más beneficiosa e

imprescindible son las reuniones. (Con independencia de su carácter formal o informal).

Importante: La comunicación tiene que ser accesible y sencilla. Si ofrece un exceso de detalle

o de complejidad llegará a ser contraproducente.

Formas de comunicación

Las formas más habituales de comunicación para la Gestión de un Servicio TI son:

Reuniones Deben realizarse reuniones periódicas, planificadas, en respuesta ante un

evento o de forma proactiva para determinar nuevas necesidades del Servicio. Deben

ofrecer una información concreta del proyecto para que presenten utilidad.

Informes En primer lugar (aunque los más olvidados) deben crearse informes internos,

para enlazar a los diferentes responsables, informar del progreso de cada fase y

establecer alertas específicas.

Tablones de anuncios Situados en zonas comunes, suelen representar una fuente de

información bastante efectiva debido al impacto. Sin embargo, no son una fuente fiable, y

cada vez están siendo más desbancados por las nuevas tecnologías.

Correo electrónico Hoy en día es la herramienta de trabajo principal en todas las

organizaciones. Por un lado presenta la ventaja de comunicación en cualquier lugar

geográfico y a cualquier hora, y por otro lado, también tiene una alta utilidad como

sistema de información histórica.

Chats, Messenger, teleconferencias Son los sistemas más novedosos y efectivos. La

mayoría de las empresas que trabajan ofreciendo servicios TI, hacen uso de ellas. Entre

sus desventajas podemos encontrar a veces la necesidad de recursos adicionales, y la

restricción temporal de uso.

Groupware, Redes Sociales Aúnan las ventajas del correo electrónico, informes,

‘Tablones online’ y otros mecanismos de comunicación instantánea. Por tanto son

indispensables en la actualidad. Entre sus desventajas podríamos denotar la dificultad de

gestión, o los problemas de seguridad.


1


Unidad 7: Procesos TS, OS. Transición y Operación del Servicio

Índice

7.1. Introducción

7.2. TS. Gestión del Conocimiento. (DIKW y SKMS)

7.3. TS. Gestión de Versiones y Despliegues

7.4. OS. Gestión de Peticiones

7.5. OS. Gestión de Accesos

7.6. OS. Gestión de Eventos

7.7. OS. Gestión de Incidencias

7.8. OS. Gestión de Problemas


2

7.1. Introducción

Introducción

En las unidades 4 y 5 estudiamos los procesos más importantes con los que

subdividimos el comienzo del Ciclo de Vida del Servicio (SS, DS y fase inicial de la TS).

Llegado a este punto, debemos proceder con la Operación del Servicio y todos los

procesos que permiten la realización de un Servicio. Esto no sólo implica los

procedimientos asignados al propio servicio, sino también las situaciones que pueden

activarlos, el control llevado a cabo y los problemas que pueden producirse.

Esquema: Procesos de la TS y la OS

Algunos de los procesos que veremos a lo largo de esta unidad son:

Gestión del Conocimiento. (DIKW y SKMS)

Gestión de Versiones y Despliegues

Gestión de Peticiones

Gestión de Accesos

Gestión de Eventos


Gestión de Problemas

TS

OS

UN

IDA

D 7

Ciclo de Vida


3

7.2 TS. Gestión del Conocimiento. (DIKW y SKMS)

Objetivos de la Gestión del Conocimiento

La Gestión del Conocimiento es un proceso que se aplica durante todo el Ciclo de Vida, aunque

tiene especial importancia durante la TS.

Su finalidad es la de mejorar garantizar la calidad y seguridad de la información para mejorar el

proceso de toma de decisiones de la dirección. Esto se traduce en la provisión de dicha

información a todas las personas integradas en el proveedor de servicios.

Esta definición puede suponer un concepto algo abstracto, pero mediante una serie de

medidas, se lograrán resultados concretos y medibles, entre los que destacan:

Mayor facilidad para localizar la información acerca de incidencias y problemas

Implica el correspondiente ahorro en tiempo de resolución).

Disminución de errores en la implementación d nuevos servicios o modificados Ofrece

mayor facilidad para aumentar el número de servicios en catálogo o en cantidad.

Mayor información Se plantearán menos problemas nuevos y menos retardos por falta

de dicha información.

Mayor documentación Menor dependencia personal, ya que la fuente de información

estará disponible en todo momento.

SKMS. Sistema de Gestión del Conocimiento del Servicio

La gestión del conocimiento debe realizar una serie de acciones:

1. Definir una Estrategia Como hemos visto hasta ahora a lo largo del curso, es prioritario

establecer una estrategia clara para lograr los objetivos con el servicio. Dicha estrategia

debe incluir ineludiblemente los recursos (personales, financieros y tecnológicos), las

medidas de rendimiento que aplicará, los roles, procedimientos, políticas…

Nota

Todos estos elementos deben estar bien documentados para que tengan utilidad.

2. Transferencia del conocimiento En muchas ocasiones es más complejo transmitir la

información acumulada a todos los interesados, que el mero hecho de conseguirla. Por ello

insistimos tanto en la documentación, ya que facilitará mucho cualquier transferencia de

conocimiento.

3. Gestión de la información Como obtener la información, el formato que se le dará y la

mejora de los datos son las funciones fundamentales de esta fase.


4

El futuro de un servicio, depende directamente de la buena recolección de requisitos

iniciales, y la adaptación a la estructura definida para el servicio. Deben realizarse acciones

de mejora y mantenimiento de la información, para lograr mayor eficiencia y efectividad.

4. Uso de un sistema SKMS Para dar soporte a todos los usuarios relacionados con un

servicio, con independencia de la zona geográfica o huso horario en el que se encuentren,

se debe crear un Sistema de Gestión del Conocimiento del Servicio (SKMS). Este sistema

está formado por una base de datos central (o Gestión de la configuración CMS) y una

Base de datos de Gestión de la Configuración (CMDB).

El SKMS maneja los datos, experiencia, comportamiento… para la toma de decisiones,

almacenándolos y gestionándolos.

También debe incluir la documentación de los procesos, acuerdos SLA, Errores-soluciones

conocidos, y en general todos los esquemas de información con detalle y con la

terminología empleada en todo momento.

DIKW. El modelo para la Gestión del Conocimiento

El CMDB acumula todo tipo de información, que envía al CMS. Finalmente el SKMS almacena

toda esa información, convirtiéndose en un soporte demasiado grande que incluye:

Requisitos y expectativas iniciales.

SLAs

Experiencia del personal

Rendimiento de la organización

Información de los procesos

Información de los usuarios

Errores y Soluciones

Terminologías y traducciones

Para facilitar la visualización de su estructura, suele emplearse un modelo DIKW. (Datos,

Información, Conocimiento y Saber).


5

7.3 TS. Gestión de Versiones y Despliegues

Unidad de Entrega y Paquete de Entrega

Una vez el servicio está preparado, pasaremos a la fase final de la Transición del Servicio. En

ella debemos realizar las entregas del servicio, de una forma organizada y documentada.

Surge por tanto la necesidad de diferenciar claramente algunos conceptos de vital importancia

durante la Gestión de Versiones:

Versión: Una versión es la forma de identificar una Línea Base o un Elemento de

configuración, mediante una convención a la hora de asignar el nombre.

El nombre de la versión al menos debe servir para identificar la fecha en la que se creó,

aunque en ocasiones ofrece mucha más información.

Ejemplo: La versión 3 de ITIL® identifica implícitamente unos cambios, organización y

vigencia diferentes a la versión 2.

Entrega: Una entrega es un conjunto de elementos de configuración, nuevos o

modificados, que son probados e implantados conjuntamente en el entorno de

producción.

Ejemplo: Un determinado Software ha sufrido diferentes modificaciones desde su

creación (Versión 1, Versión 2.3, Versión 2.5). Sin embargo, sólo la Versión 2.6 ha

visto la luz en el mercado y se ha ofrecido al cliente final.

Unidad de Entrega: Una unidad de entrega es la porción del servicio o la

infraestructura que está incluida en la entrega, de acuerdo con las directrices de

entrega de la organización.

Ejemplo: Una Unidad de entrega puede ser una página Web completa (ficheros,

documentación, pdfs, imágenes…) o un único fichero HTML modificado respecto a

uno anterior.

Paquete de Entrega: Una o varias Unidades de Entrega agrupadas.

Ejemplo: En un paquete de entrega a un cliente puede incluirse una Web modificada

con versión 2.6, un servidor físico de determinadas características, y un software de

versión 1.4.53.


6

La Gestión de Entregas está íntimamente relacionada con las versiones, puesto que

representan la cara visible de una entrega exitosa o fallida. Así pues, la Gestión de entregas

debe encargarse de:

• Supervisar la existencia de versiones.

• Supervisar el despliegue de los paquetes de versiones.

• Comprobar la transferencia de conocimiento a los clientes.

Gestión de Versiones y Despliegues

Definición ITIL®: Gestión de versiones y entregas: La Gestión de versiones y entregas se

ocupa de construir, probar y suministrar las capacidades para proporcionar los servicios

especificados en el DS, cumpliendo los requisitos de los grupos de interés y proporcionando los

objetivos planteados.

A la hora de realizar una entrega, deben observarse estas características, y gestionarlas de tal

modo que los servicios existentes sufran paradas o alteraciones mínimas. Para ello se deben

emplear una serie de políticas que aseguren este hecho, en concreto:

• Políticas de calidad del servicio Se evalúan los diseños y cambios antes de la transición.

• Políticas de riesgo Se enumeran los riesgos asociados de cada entrega y las acciones

relacionadas.

• Políticas de reutilización Al crear una nueva versión, se indica en qué circunstancias

puede reutilizarse.

• Políticas de Transición del Servicio Se debe indicar cómo realizar la propia transición.

• Políticas de versiones Políticas internas acerca de la diferenciación entre versiones

(formato, fechas, forma…)

• Pruebas integrales obligatorias Cada nuevo paquete de versiones debe incluir unas

pruebas exhaustivas.

• Participación en las pruebas de todas las partes interesadas Deben participar los

usuarios, clientes y gestores.

• Políticas de Gestión de Cambios Debe existir una política de gestión de cambios global

asociada a las versiones.


7

Fases de desarrollo de un Paquete de Versión

En un paquete de versión, no suelen incluirse todos los elementos de un servicio, salvo que

éste sea nuevo. Lo más habitual es entregar ciertos elementos de la configuración que afecten

a esa versión.

Para realizar una nueva entrega deben seguirse estos pasos:

1. Planificación El primer paso lógico es realizar una estimación del alcance, contenido y

riesgos implicados de un Servicio, junto con la designación de responsabilidades para la

entrega. Es imprescindible crear:

• Planes de construcción y pruebas: Indicando el método de construcción, pruebas de

servicio e integración, y mantenimiento en un entorno de desarrollo.

• Criterios de éxito/fallo: Una planificación de cada fase de entrega, y un plan de

actuación para las situaciones en que se produzca un error.

• Piloto: Es necesario crear un escenario similar al real donde poder probar un piloto de

prueba.

• Planificación de entrega y construcción: Planificación de los recursos y cambios

afectados, y la transferencia del conocimiento a los usuarios finales durante la

construcción.

• Planificación del despliegue: Plan real de alta o modificación del Servicio, teniendo en

cuenta las notificaciones a los usuarios, modificaciones y factores críticos planificados

hasta la fecha.

• Planificación financiera, logística y de distribución: Es importante revisar todos los

aspectos financieros, logísticos y de distribución, para constatar que todos los recursos

están disponibles y cómo actuar en el momento que alguno de ellos falte.

2. Preparación, pruebas y despliegue Se revisan todas las necesidades del servicio y se

compara con la configuración del servicio nuevo o modificado. Se solventan todos los

problemas y se documenta la situación.

3. Construcción y pruebas En esta fase debe gestionarse toda la infraestructura, procesos y

servicios implicados. Se realizará la compra y prueba de todos los componentes y

elementos para la versión, y se documentará toda la información de licencias y versiones,

junto con la actualización del CMS y la creación de un entorno de pruebas. El orden de

secuencia más estandarizado será:

Ensamblar e integrar todos los componentes.

Instalar el paquete de entrega (y revisarlo).

Documentar el ensamblado y la entrega.


8

Definición de la versión del paquete.

Comunicación de mensaje con la indicación de “Servicio activo”.

4. Pilotos Para poder gestionar correctamente las pruebas de las versiones, es necesario

generar una serie de pruebas de entrega del servicio (integración e instalación correctas),

pruebas de operación del servicio (paso al entorno de producción) y pilotos para probar

que todos los elementos del servicio cumplen las especificaciones.

5. Planificación y preparación del despliegue Esta fase se centra en los aspectos

relacionados con el despliegue del servicio y la comprobación de cambios que deben ser

aprobados por la Gestión de Cambios. La lista de actividades, riesgos financieros y de

servicio, formación de los usuarios, actualizaciones e información logística.

6. Despliegue y transferencia Esta es la fase central, donde se realiza el despliegue del

Servicio. Esto implica una serie de acciones principales y otras relacionadas:

Actualización del catálogo del Servicio, creación de auditorías de activos del

Servicio y distribución de notificaciones.

Transferencia de herramientas, activos financieros y responsabilidades asociadas

al Servicio.

Publicación de documentación (procesos, procedimientos y manuales que sean

necesarios).

Revisión de servicios y activos existentes, para la retirada de los duplicados u

obsoletos.

7. Verificación del despliegue Se revisa el despliegue efectuado, y se acogen las

impresiones y comentarios de todos los usuarios para la CSI.

8. Soporte post-implantación (ELS) Esta fase complementa a la anterior, documentando

diagnósticos de errores, soluciones provisionales y preguntas frecuentes (FAQ). Además se

encarga de resolver problemas operativos con la mayor rapidez posible y de constatar que

el Servicio se ofrece con el nivel de calidad esperado.

9. Revisión y cierre Finalmente debe realizarse una revisión final para comprobar que el

servicio satisface los criterios de calidad. Se debe comprobar la documentación de todos los

aspectos y que el servicio está preparado para pasar de ELS a Producción.

Importante: Las versiones definitivas se almacenan de forma segura en la DML (Biblioteca

Definitiva de Medios). Se trata de un repositorio único o múltiple administrada por la

Gestión de Cambios y la Gestión de Versiones, y registrada en el CMS. Suele incluir

software, licencias y documentación, y sólo lo que se almacena en ella se puede emplear

para nuevas versiones.


9

Planificación: El modelo V

Durante la planificación, es muy útil utilizar un modelo gráfico como el modelo V, donde se

definen las especificaciones del Servicio en un lateral, y en el lado contrario se muestran las

actividades asociadas. Además se subdivide en distintos niveles de configuración para facilitar

su estudio.

7.4 OS. Gestión de Peticiones

Gestión de Peticiones

Una vez definido los procesos asociados a la TS, con la Gestión de Versiones como punto

culminante, procederemos a la revisión de los procesos que se encuadran en la Operación del

Servicio, comenzando por la petición de los servicios.

Definición ITIL®: Una petición de servicio es una solicitud de información, asesoramiento,

cambio estándar o acceso a un servicio por parte de un usuario.

Es decir, una petición de servicio es lo que solicitan los usuarios cuando necesitan un

determinado servicio. Tienen la finalidad de proporcionar información sobre la disponibilidad


10

de servicios existentes, facilitar su solicitud y gestionar la misma, junto con los comentarios o

quejas que surjan en el proceso.

Planificación de peticiones

Las peticiones de servicio deben ser planificadas, para que no sean consideradas incidencias o

degeneren en problemas no contemplados.

1. Solicitudes a través de un menú Mediante un interfaz de usuario, generalmente

una aplicación o un interfaz Web, los usuarios deben poder seleccionar un Servicio del

catálogo ofrecido (y revisar los detalles del mismo).

2. Aprobación/Denegación Los precios de los servicios deben estar fijados. Así cuando

llegue una solicitud, podrá automatizarse la aceptación o denegación, dependiendo de

si los beneficios y costes son asumibles.

3. Tratamiento Debe existir un Centro de Servicio al Usuario para el tratamiento de los

Servicios más sencillos y Centros de Servicios especializados para los más complejos.

4. Cierre Una vez completada la petición del servicio, el Centro de Servicio al Usuario

cierra la petición.

Nota

La Gestión de Peticiones debe complementarse con estadísticas con el número de

peticiones realizadas, peticiones pendientes, costes medios, peticiones realizadas en su

plazo asignado y el nivel de satisfacción del cliente entre otros.

7.5 OS. Gestión de Accesos

Gestión de Accesos

No todos los usuarios tienen acceso a todos los servicios. Precisamente, durante el Diseño

del Servicio existía un proceso (recordar la ISMS en la Unidad 5) para configurar la seguridad,

y en la Operación del servicio debe controlarse quién puede usarlo.

Nota

La Gestión de la Disponibilidad es la encargada de garantizar la disponibilidad del Servicio,

por lo que la Gestión de Acceso no es responsable de esta disponibilidad.


11

La Gestión de Accesos se encarga de gestionar los accesos de los usuarios y aplicaciones a

determinados procesos, tareas, elementos, componentes o configuraciones del servicio.de

Suministradores, Diseñador de TI, etc.

Elementos habituales

La Gestión de Acceso maneja esta nomenclatura para la realización del servicio:

Identidad Para poder restringir los accesos, la organización establece información

de personas conocidas. También se les asigna un estado y en ocasiones se

generalizan usuarios similares con lo que denominamos perfil de usuario. Suelen

incluirse entre los datos de usuario el nombre, forma de contacto, documentación

personal, identificadores únicos y algunas características diferenciadoras.

Acceso Indica las posibilidades del servicio que un usuario tiene autorizado

utilizar. En organizaciones robustas suelen definirse distintos niveles de acceso.

Privilegios La forma de transformar las características autorizadas de los usuarios

en un sistema TI. Suelen coincidir con los permisos de lectura, escritura (edición y

eliminación) y ejecución. Según los niveles establecidos, existirá una lista mayor o

menor de privilegios.

Grupos de Servicios La norma más habitual es unir usuarios con los mismos

privilegios y características comunes en grupos. Por ejemplo un grupo de lectura de

25000 usuarios sólo necesitará establecer los privilegios para todo el grupo y no para

cada uno de ellos de forma individual.

Servicios de Directorio Una organización adicional para seccionar grupos según

unas características concretas para gestionar accesos y privilegios.

Solicitud de Acceso

Una solicitud de acceso puede generarse por la incorporación de nuevos usuarios a un

departamento o un nuevo cliente. También puede ser el efecto de una solicitud de cambio

(RFC) y una petición concreta, puntual o planificada.

Ante la solicitud de acceso deben realizarse estas actividades:

1. Verificar Debe validarse la identidad del solicitante, y la necesidad de dicho acceso.


12

2. Conceder derechos Todos los usuarios tendrán uno o varios roles asignados. Definir cuales corresponden al individuo que solicitó el acceso, pues dependiendo de ello dispondrá de más o menos privilegios.

3. Monitorización de accesos Todos los accesos deben ser monitorizados para comprobar que los derechos concedidos son adecuados y asegurar el control sobre los Servicios.

4. Monitorización del estado de las identidades El rol asignado a una persona puede

cambiar, así como su estado (un ascenso o una baja temporal, por ejemplo). Deben detectarse estos cambios y revocar o modificar los derechos en consecuencia.

7.6 OS. Gestión de Eventos

Gestión de Eventos

Ya hemos definido brevemente cómo gestionar las Peticiones de Servicio y los usuarios que

tienen Acceso a las mismas. Es decir, cómo, quién, y en este caso nos queda cuándo, gracias a

la Gestión de Eventos.

Definición ITIL®: Evento: Suceso detectable o discernible que tiene importancia para la

gestión de la infraestructura de TI o para la entrega de un servicio de TI, así como para la

evaluación del impacto que podría causar una desviación sobre los servicios.

En todas las organizaciones se producen estos cambios, y la Gestión de Eventos es la

encargada de detectarlos, analizarlos, y actuar en consonancia con una serie de actividades

durante la OS. La tarea de listar todos los eventos es realmente ardua, pero se verá

recompensada con la posibilidad de automatizar ciertos servicios, detección precoz de

incidencias y la liberación de recursos de otros procesos.

El proceso de Gestión de Eventos

El proceso de Gestión de Eventos debe realizar estas tareas:

Aparece un nuevo evento Los eventos rara vez están planificados. Pueden surgir en

cualquier momento y detectarse de diversas maneras. Muchos de ellos implicarán


13

varias acciones, y otros tantos no tendrán correlación directa con los servicios TI. El

equipo encargado de la Gestión de Eventos debe listar el mayor número de eventos

potenciales posible.

Detección e Informes de eventos Los Elementos de Configuración suelen

comunicarse entre ellos mediante la transmisión de eventos puntuales e informes

asociados, o mediante sondeos (datos recopilados por una herramienta que analiza un

dispositivo concreto). Deben existir herramientas capaces de detectar esas situaciones

cambiantes.

Filtrado de eventos Los eventos que deban ser atendidos, se pasarán a la

herramienta de Gestión de Eventos para realizar las acciones convenientes. El resto,

simplemente deben almacenarse.

Clasificación de eventos Es imprescindible clasificar la importancia de los eventos,

especialmente cuando varios coincidan en el mismo espacio temporal. Es habitual

clasificarlos en:

Alertas: Se deben a situaciones captadas al rebasar ciertos límites.

Normalmente no representan mucha gravedad, salvo que no se atiendan y

persistan en el tiempo.

Errores/Excepciones: Indican cualquier problema en el servicio, e

incumplimiento del OLA. Deben ser solventadas para restaurar el servicio.

Informativos: Son eventos que no conllevan una acción. Aunque deben

registrarse para su revisión en la CSI.

Relación entre eventos Una vez clasificados los eventos, han de priorizarse. En

igualdad de importancia debe atenderse antes un evento que afecta a varios procesos

que un evento que sólo está relacionado con un único proceso.

Disparador Una vez hayan sido detectados los eventos, debe lanzarse una acción.

La respuesta al evento se llama disparador, y existen diferentes según su actividad:

Disparadores en bases de datos (generan cambios en una BD), disparadores de

incidencias (generan registros en la Gestión de incidencias) y Secuencias de comandos

(una serie de acciones personalizadas).

Opciones de respuesta El proceso que lleve asociado el evento puede llevar

asociadas distintas respuestas: Registro de eventos, alertas de intervención humana,

solicitud de RFC, apertura de incidencia o problema, respuesta automática, etc.

Revisión de acciones Existen herramientas para la revisión automática de eventos.

En cualquier caso, es necesario realizar una revisión periódica para comprobar que

todos han sido tratados correctamente.


14

Cierre del evento Generalmente los eventos se cierran automáticamente, aunque

hay algunos que pueden persistir abiertos hasta que una acción externa los cierra. No

se debe confundir una respuesta “en curso” o “finalizada” a un evento, que con la

propia apertura o cierre del evento en sí. Un evento es un aviso, la respuesta es la

reacción ante ese aviso.

7.7 OS. Gestión de Incidencias


La Gestión de Incidencias es un proceso de vital importancia, junto con la Gestión de

Problemas. Tiene como atribución principal la de recuperar la actividad de un servicio para

minimizar al máximo el impacto en el negocio.

Definición ITIL®: Incidencia: Una incidencia es una interrupción no planificada o una

reducción de calidad de un servicio TI. El fallo de un elemento de configuración que no haya

afectado todavía al servicio también se considera una incidencia.

El Centro de Servicio al Usuario suele encargarse tanto de las peticiones de servicio, como de

las incidencias. Además, el proceso de Gestión de Incidencias, está íntimamente relacionado

con:

• Gestión de Cambios Una incidencia puede provocar un cambio o viceversa.

• Gestión de Capacidad Puede proponer soluciones temporales para resolver

incidencias.

• Gestión de Disponibilidad Debe ser informada de la disponibilidad por la Gestión de

Incidencias.

• Gestión de la Configuración CMS identifica usuarios afectados y los componentes.

• Gestión de Problemas Las incidencias pueden derivar en problemas y los problemas

pueden provocar nuevas incidencias.

Tratamiento de las Incidencias

Para poder solventar una incidencia deben seguirse una serie de pasos:


15

1. Identificación Hay que facilitar métodos para los usuarios y automatismos, para

detectar las incidencias cuanto antes.

2. Registro Un error tristemente habitual, es el hecho de detectar correctamente las

incidencias, pero no gestionar correctamente su registro. Si las incidencias no quedan

correctamente registradas y notificadas, degenerarán en nuevas incidencias y problemas

más graves.

3. Clasificación Deben separarse las incidencias según su tipo, duración, gravedad… e

incluso si es posible, de los errores conocidos.

4. Priorización En primer lugar han de atenderse las incidencias más graves, pero también

deben priorizarse las que afectan a varios procesos o las que son vitales para el negocio.

5. Diagnóstico inicial En un primer nivel de Gestión de Incidencias, se debe realizar un

diagnóstico inicial, para actuar según los procedimientos establecidos.

6. Escalado Las incidencias deben encuadrarse en distintos niveles de gestión. Algunas

incidencias podrán resolverse en el primer nivel (Centro de Servicio al cliente), otras

tendrán que escalarse a un segundo nivel (servicio técnico de nivel 1) y así sucesivamente.

Nota

Existen dos modalidades de escalado:

Escalado jerárquico: Se avisa a los responsables de TI ante una incidencia grave,

y a sus responsables superiores si no se puede solventar.

Escalado funcional: Se intenta solucionar la incidencia en el nivel de soporte más

básico, y si no es posible, se envía al siguiente nivel de soporte más avanzado.

7. Diagnóstico El departamento adecuado se encargará de analizar e investigar las

características del incidente.

8. Resolución Una vez solventado, se debe documentar e intentar restablecer el servicio

(si se había interrumpido o alterado).

9. Cierre Se debe comprobar que el servicio funciona con normalidad y cerrar la

incidencia (actualizando también la documentación).


16

Atributos de las Incidencias

Es vital documentar las incidencias, y dicha documentación debe incluir al menos las siguientes

características. La Gestión de Incidencias, necesita tener acceso al Sistema de Gestión de la

Configuración (CMS) para disponer siempre de la información actualizada.

Un Identificador único Todas las incidencias deben ser diferentes.

Categoría de la incidencia Para poder diferenciar de qué tipo son (Software o

hardware, por ejemplo).

Urgencia de la incidencia Una categorización más sencilla que la prioridad, por

ejemplo “Normal”, “Urgente” y “Crítica”. (se definirán según las necesidades del

negocio).

Nota

Una incidencia grave, sigue siendo una incidencia y no un problema. Un problema

surge debido a una o varias incidencias.

Prioridad de la incidencia Pueden definirse niveles de prioridad, por ejemplo de 1 a

10. Se calcula según el impacto (número de usuarios afectados) y la urgencia.

Nota

Algo muy habitual para delimitar esas prioridades, suele ser definir un marco de

OLAs (Acuerdos de Nivel Operativo) con los Límites de tiempo necesarios para

cubrir todas las fases de la incidencia.

La persona/equipo que detectó la incidencia Sin olvidar la fecha y hora.

Descripción Descripción de la incidencia. Esta descripción se contrastará con el

Modelo de incidencias (que describe las más habituales) para realizar las acciones

definidas en él.

Actividades realizadas Instalación de una actualización, sustitución de un elemento,

etc. Todo ello bien documentado.

Cierre Fecha y hora en que queda cerrada la incidencia y donde está almacenada la

documentación adjunta.

Nota

Especialmente importante es registrar la Fecha y Hora en cada una de las acciones, y el

Estado de la incidencia en todo momento.


17

7.8 OS. Gestión de Problemas

Gestión de Problemas

Como comentábamos en el punto anterior, las incidencias no deben confundirse con los

problemas. Y aunque uno de las tareas que debe realizar la Gestión de Problemas es resolver

los problemas de un Servicio, su principal función es la de prevenirlos.

Definición ITIL®: Problema: Causa de uno o más Incidentes. En el momento en el que se crea

el Registro del Problema, no es frecuente conocer su causa, por lo que es necesario realizar su

investigación mediante el Proceso de Gestión de Problemas.

KEDB, errores conocidos y soluciones

Toda la información documentada sobre la resolución de incidencias, servirá para acotar

problemas permanentes y solucionarlos de una forma mucho más efectiva en el futuro.

Gracias al tratamiento de las incidencias, se podrán definir errores conocidos y soluciones

(provisionales o no) almacenados en una base de datos de errores conocidos (KEDB).

Con esta información, como sucedía con las incidencias, es conveniente crear un modelo de

problemas, que nos sirva de guía cuando surja alguno nuevo.

La Gestión de Problemas tiene una relación directa con la Gestión de Cambios y Gestión de

Eventos, aunque también con una cantidad mayor de procesos que la Gestión de Incidencias

(Gestión Financiera, ITSCM, Gestión de Disponibilidad…).

Nota

Definiciones ITIL®:

Error conocido: Es un problema del que se tiene una causa raíz documentada y una solución provisional.

Solución provisional: Reducción o eliminación del impacto de una incidencia o problema, para la que aún no existe una solución completa.

Proceso para la identificación y solución de problemas

Los problemas deben ser identificados con la mayor celeridad posible. Esto permitirá también

dar mayor rapidez a su gestión. Podemos identificar estas fases:


18

Identificación El Centro de Servicio al Usuario detecta un problema, a partir de una incidencia desconocida, o varias incidencias persistentes.

Registro inicial Se registra el problema (en ocasiones, si es de gravedad, no será necesario pasar por la fase de incidencias).

Análisis El equipo de Soporte técnico analiza una incidencia y descubre un problema.

Registro Mediante un departamento especializado o una herramienta automática, se registra el problema.

Información El suministrador informa del problema.

Análisis Se analizan las incidencias y se registran las acciones efectuadas. En este momento deben realizarse varias acciones de documentación importante, y clasificar bien los problemas como hacíamos con las incidencias.

Registro final En algunas ocasiones, el problema puede solventarse y cerrarse un conjunto de incidencias asociadas. En otras, sólo puede registrarse, y ofrecer una solución temporal.


1


Unidad 8: Monitorización y Operación de TI

Índice

8.1. Introducción

8.2. Centro de Servicios de Usuario

8.3. Gestión Técnica

8.4. Gestión de Aplicaciones

8.5. Gestión de Operaciones

8.6. Operación del Servicio. Roles

8.7. Monitorización del Servicio


2

8.1. Introducción

Introducción

Aunque hemos visto los diversos procesos asociados a la OS (Gestión de Eventos, de

Incidencias y de Acceso, entre otros), nos queda todavía revisar una funcionalidad

importante: La propia Operación del Servicio y la Monitorización del mismo.

La Operación del Servicio TI debe realizar tareas de planificación de rutinas, backups y

restauraciones, impresiones, almacenes de datos… y el control continuo para

garantizar que el Servicio TI se lleva a cabo tal y como se estableció en el SLA.

Para ello se establecen diferentes roles y se asignan a distintos equipos,

departamentos e individuos. Durante esta unidad haremos un estudio de ellos.

8.2 Centro de Servicios de Usuario

La función del Centro de Servicios de Usuario

El centro de Servicio al Usuario es un elemento fundamental en la Operación del Servicio. Su

objetivo principal es la atención al cliente para la restauración del Servicio.

Se encarga de atender las peticiones telefónicas, eventos automáticos y solicitudes a través de

la red de forma manual o mediante herramientas de software.

Estructura del Centro de Servicio al Usuario

Cada organización puede disponer de un sistema diferente de estructura para el Centro de

Servicio al Usuario. Las más habituales son:

Centro de Servicio al Usuario Local El usuario se conecta al Centro de Servicio, y

éste a los distintos sistemas de Gestión Internos. Se utiliza en zonas cercanas

físicamente al usuario.

Centro de Servicio al Usuario Centralizado Cualquier usuario se conecta a un

servicio central, un Centro de Servicio al Usuario formará parte de ese Servicio. Es útil

para localizaciones físicas diferentes, pero que confluyen en una central de servicios.


3

Centro de Servicio al Usuario Virtual Se establece un sistema virtual de atención al

usuario, para casos más complejos, se pasará a un Centro de Soporte real. Se emplea

en zonas lejanas al usuario, o mediante internet.

Servicio 24x7. Combina todas las técnicas, pero su característica más importante es

la alta disponibilidad las 24 horas del día en cualquier parte del mundo.

Nota

También se lo conoce como “Follow the sun”.

Centro de Servicio Especializado Tras un primer filtro, existen diferentes Centros de

Servicio especializados, según la necesidad del cliente.

Características del Centro de Servicio al Usuario

Para poder disponer de un Centro de Servicio al Usuario eficaz es necesario un personal

formado (cualidades) y suficiente (cantidad). Para ello es recomendable:

Dividir el personal por nivel de servicio y conocimientos Es recomendable crear un

primer nivel de Centro de Servicio al Usuario y dos niveles de Soporte al menos.

Prever picos y valles en la atención a lo largo del tiempo Para tener esos picos

cubiertos con la cantidad de personal necesario.

Es recomendable el apoyo de herramientas TI Para la redistribución de llamadas,

para la virtualización, para la automatización de tareas… etc.

Almacenar toda la información posible No sólo un registro de llamadas, sino

encuestas de calidad asociadas.

Realizar formación Es altamente recomendable la formación interna, para disponer

de un Centro de Servicio al Usuario eficaz, y adaptado a las nuevas tecnologías.


4

8.3 Gestión Técnica

La función de la Gestión Técnica

Si el Centro de Servicios de Usuario representa “El frente de combate”, este segundo nivel se

compone de los diferentes grupos de trabajo encargados de la infraestructura TI.

Lleva a cabo todos los procedimientos para diseñar, probar, gestionar y mejorar el sistema TI,

mientras que también representa el apartado más técnico de todo el sistema de gestión. Es

por tanto un departamento encargado de relacionar la tecnología con las necesidades del

negocio.

La Gestión Técnica tiene diversas utilidades. Cabe destacar su cooperación para mejorar la

Cartera de Servicios, participación en los programas de formación, y en general del

aprovechamiento de sus conocimientos técnicos para el diseño, mantenimiento y gestión de

los Servicios, de la forma más eficiente.

Organización de la Gestión Técnica

Normalmente, de la Gestión Técnica se encargan distintos grupos o departamentos,

especializados según una tecnología, finalidad o funcionalidad. En muchos casos esa

diferenciación se debe a la tecnología empleada, y en otros tantos a las tareas que deben

realizar.

Estos departamentos deben incluir:

Diseñadores Para que apliquen sus conocimientos al diseño o mantenimiento de un

Servicio TI. Asegurarán que la estructura es rentable y está bien diseñada.

Arquitectos Para poder balancear los conocimientos técnicos y la relación con los

recursos y requisitos existentes.

Mantenedores Especialistas en mantenimiento de hardware o software.,

especialistas, técnicos especializados y también personal de soporte.

Personal de Soporte Especialistas técnicos de soporte, con conocimientos técnicos

amplios.

Nota

Todos estos grupos de trabajo están implicados en mayor o menor medida en los sistemas

de formación a otros niveles, la documentación técnica, inventario (técnico y de

conocimientos) y la planificación de sus funciones.


5

8.4 Gestión de Aplicaciones

La función de la Gestión de Aplicaciones

Al igual que la Gestión Técnica está íntimamente relacionada con la infraestructura de TI, la

Gestión de Aplicaciones es la encargada de las aplicaciones durante su ciclo de vida.

Se encarga principalmente de:

Sirve como enlace con la Gestión de Operaciones TI para decidir la operativa óptima de

las aplicaciones.

Gestionar el Ciclo de Vida del Software dentro del Ciclo de Vida de la Gestión de

Servicios de TI.

Nota

Hay que recordar, que en cualquier Servicio, la prioridad básica es satisfacer los objetivos

del Ciclo de Vida de la Gestión de Servicios. De forma interna, los diferentes Ciclos de Vida

del Software tendrán sus propios objetivos individuales, y consistentes con el principal.

Ciclo de Vida del Software (SLC)

Nota

También se lo conoce como Ciclo de Vida de Desarrollo de Software (SDLC) o simplemente

Ciclo de Vida de las Aplicaciones.

La Gestión de Aplicaciones se compone principalmente de equipos de desarrollo de

aplicaciones, revisores (no siempre se desarrollan las aplicaciones dentro del propio esquema)

y gestores. Todos ellos se encargan de tareas de diseño, desarrollo y pruebas, entre otros, y

definen su actividad como Ciclo de Vida del Software.

Fases del Ciclo de Vida del Software (SLC)

1. Requisitos Se deben recopilar TODOS los requisitos de una nueva aplicación durante la

SS. Se pueden clasificar en:

Requisitos funcionales: necesarios para crear una determinada función

Requisitos de gestión: para la disponibilidad y seguridad del servicio.

Requisitos de usabilidad: para satisfacer las necesidades de los usuarios.

Requisitos de la arquitectura: para satisfacer las necesidades técnicas.

Requisitos de interfaz: para detectar dependencias entre aplicaciones-herramientas.

Requisitos de nivel de servicio: para medir los SLA y niveles de calidad necesarios.


6

2. Diseño Esta fase será realizada durante el DS. De especial importancia son el modelado

del diseño de acuerdo con los requisitos de la arquitectura detallados anteriormente.

3. Construcción Se crea la aplicación y la forma de despliegue. También se realizan pruebas

sobre el diseño construido, muy importantes durante la TS.

4. Despliegue Partiendo de los modelos creados en la TS, se despliegan las aplicaciones.

5. Operación La aplicación forma parte del Servicio desarrollado. Se ejecuta y se observan

la consecución de los objetivos a nivel individual.

6. Optimización En esta última fase se analizan los resultados de la operación, y también se

supervisan los obtenidos por el Servicio. Mediante el CSI se intentarán mejorar las

aplicaciones.

8.5 Gestión de Operaciones

La función de la Gestión de Operaciones

La Gestión de Operaciones es la encargada de realizar las actividades operativas diarias y

garantizar la provisión de Servicios TI con el nivel acordado.

Debe, por tanto:

Garantizar la adaptación a las demandas del negocio y variaciones de requisitos

Debe mantener la estabilidad de los Ser vicios TI.

Si cumple bien su cometido, esa estabilidad disminuirá los fallos y se transformará en calidad

del Servicio y en Valor para el negocio. Además debe servir de base para la Mejora de

Servicios, mejorando el coste sin reducir la estabilidad.

Nota

La Gestión de Operaciones en muchas ocasiones funciona de forma independiente, pero a

veces coopera con la Gestión Técnica y Gestión de Aplicaciones.

Documentación de la Gestión de Operaciones TI

A lo largo de este curso siempre hemos insistido en la necesidad de la documentación para cualquier tipo de actividad en general, y en la Gestión de Servicios TI en particular. En esta función alcanza un alto grado de importancia, y debe reflejar:


7

Procedimientos de Operación Estándar (SOP) Cada departamento o equipo de trabajo TI tiene una operativa asignada. Todos los detalles personalizados deben aparecer en este tipo de documentos.

Registro de Operaciones Deben almacenarse todas las actividades realizadas por la Operación de TI, para:

Confirmar que las tareas se han realizado Confirmar la provisión de un servicio TI según los SLAs Poder analizar con posterioridad las incidencias Detectar problemas Poder generar nuevos informes para mejorar el Servicio.

Informes También llamados en otras ocasiones Procedimientos de Operación Específicos. Se encargan de personalizar los procedimientos iniciales, según unas tareas determinadas o unas características diferenciadoras.

8.6 Operación del Servicio. Roles

Operación del Servicio. Roles

La Operación del Servicio consta de una serie de procesos y actividades (funciones) que deben

ser realizadas por el software, hardware y personas que proporcionan el Servicio. Por regla

general, las personas o equipos encargados de dichas tareas suelen denominarse igual que la

función que desempeñan. A continuación mostramos las más importantes:

Roles en la Gestión de Peticiones Los encargados de iniciar las peticiones son el Centro

de Servicio al Usuario y el equipo de Gestión de Incidencias, y de ejecutar el servicio el

resto de departamentos responsables.

Roles en la Gestión de Accesos Más que una persona, suelen haber ciertos protocolos

para permitir los accesos. La Gestión de Seguridad de la Información se encarga de

definirlos y el Centro de Servicio al Usuario de gestiona las aplicaciones con ellos.

Roles en la Gestión de Eventos No suele tener un representante, aunque el Centro de

Servicio al Usuario suele atender las incidencias a causa de ciertos eventos, y la Gestión

técnica y de aplicaciones suele tratarlos.

Roles de Gestión de Incidencias Suele incluir al menos un Gestor de Incidencias,

encargado de manejar la información, gestionar el equipo de soporte de primeros niveles,

y en general monitorizar y supervisar las incidencias en todas las líneas de soporte.


8

Roles en la Gestión de Problemas Debe existir un responsable (al menos) que coordine

todas las actividades. Debe gestionar, documentar, ejecutar, y supervisar que en todo

momento se solventan los errores para garantizar el SLA. Además debe manejar y

mantener la Base de Datos de Errores Conocidos.

Roles en el Centro de Servicio al Usuario Debe incorporar:

Responsable del Centro de Servicio al Usuario (para gestionar todas las actividades,

escalar supervisores, servir de interfaz ante los clientes, informar a la dirección y

asumir responsabilidades).

Supervisor del Centro de Servicio al Usuario (Responsable de los informes , de escalado

de llamadas complejas y de garantizar niveles de personal).

Analistas (Primera línea de soporte. Procesan las primeras incidencias y peticiones).

Super-usuarios (Usuarios que actúan como interfaz entre el negocio y TI).

Roles en la Gestión Técnica Son necesarios para la Gestión Técnica:

Gestores técnicos y Responsables de equipo.

Arquitectos y Analistas

Operadores técnicos.

Roles en la Gestión de Aplicaciones Incluye gestores de aplicaciones y responsables de

equipo para controlar los equipos encargados de las aplicaciones y la toma de decisiones.

Roles en la Gestión de Operaciones Es necesario definir para la Gestión de

Operaciones:

Un Gestor de Operaciones TI Un Responsable de turno Analistas de Operaciones de TI Operadores de TI.

8.7 Monitorización del Servicio

La función de la Monitorización del Servicio

Para finalizar esta unidad, vamos a observar el ciclo de Monitorización del Servicio, que se

encarga de la monitorización, generación de informes y control, destinados a proporcionar el

mejor servicio.


9

Monitorización Un servicio no sólo ha de ofrecerse, sino que también debe haber

un seguimiento para comprobar su estabilidad, realización y posibles mejoras en la

eficiencia.

Control Deben controlarse también los dispositivos y sistemas, además del propio

servicio. Para ello se establecen estándares, entornos de actividad y conformidades

con la actividad de esos elementos en ese entorno.

Generación de informes Todos los Servicios persiguen satisfacer unos objetivos.

Para poder analizar si se cumplen correctamente, deben crearse informes asociados.

La monitorización y control no sólo pueden emplearse para supervisar un proceso. Se puede

utilizar para conocer el rendimiento de una serie de dispositivos, uno o varios procedimientos,

e incluso el Servicio en conjunto. Y por supuesto nos ayuda a detectar problemas en fases

intermedias.

La OS realiza monitorización de rendimiento de componentes, equipos y departamentos y de

la calidad del servicio ofrecido (salida).

Tipos de Monitorización

Existen dos tipos de sistemas monitorización y control:

De ciclo abierto: Son sistemas diseñados para realizar una acción, sin tener en cuenta

el entorno que las rodea. Por ejemplo un acceso a través de una contraseña simple.

De ciclo cerrado: Son sistemas afectados por el entorno que los rodea, y que también

lo monitorizan. Por ejemplo un sistema de autentificación mediante claves públicas y

privadas (que dependen de los equipos donde se quieran emplear).

Niveles de Monitorización

Además, también pueden dividirse en dos niveles:

Monitorización interna: Supervisa exclusivamente los elementos y actividades dentro

de un departamento. Por ejemplo, un director del Centro de Servicio al Usuario

monitoriza el número de llamadas recibidas para analizar si los telefonistas son

suficientes.

Monitorización externa: Supervisa los elementos externos al servicio. Por tanto está

más ligada a los resultados totales que a los parciales. Un director de Calidad, consulta

unos informes para evaluar la cantidad de asistencias realizadas correctamente.

Como puede observarse, la monitorización interna ofrece información más concreta, pero no

ayuda a mejorar el Servicio, sino los procesos implicados. La monitorización externa obtiene


10

información relacionada directamente con el Servicio, pero sin conocer los detalles internos.

La opción más adecuada es hacer uso de ambas.

Herramientas de Monitorización

Existen diferentes herramientas de monitorización:

Monitorización activa o pasiva:

La monitorización activa se encarga de preguntar constantemente a los

dispositivos acerca de su estado

La monitorización pasiva suele funcionar a partir de algún evento que

informan que debe monitorizarse una situación concreta.

Monitorización reactiva y proactiva:

La monitorización reactiva se efectúa como consecuencia de un evento.

La monitorización proactiva se efectúa de forma periódica y casi siempre de

manera preventiva.

Monitorización continua o por excepciones:

La monitorización continua se realiza para comprobar en tiempo real el

rendimiento de un sistema.

La monitorización por excepciones se emplea para supervisar sistemas ante

situaciones inhabituales.


1


Unidad 9: Procesos CSI. Mejora Continua del Servicio

Índice

9.1. Introducción

9.2. Mejora continua del Servicio (Deming).

9.3. El Gestor de CSI

9.4. Automatización del Servicio.

9.5. Informes del Servicio.

9.6. ROI


2

9.1. Introducción

Introducción

Aun cuando los procedimientos, personal y componentes de un Servicio estén optimizados al

máximo, el devenir del tiempo provocará la necesidad de revisarlo.

Los requisitos pueden cambiar, los grupos de trabajo ser reorganizados, e incluso la situación

del mercado y del negocio sufrir modificaciones.

Aquí entran en juego los procedimientos de la organización para la Mejora Continua del

Servicio o CSI. Entre las actividades más destacadas para lograrlo están la automatización de

rutinas, el empleo de tecnología y la generación de informes. Todo ello con la finalidad última

de alcanzar los objetivos establecidos.

9.2 Mejora continua del Servicio (Deming)

El plan para mejorar la calidad del Servicio (SIP)

La Mejora Continua del Servicio (CSI) es una fase que se ejecuta de forma continuada durante

el Ciclo de Vida del Servicio TI. Su objetivo principal es alcanzar las mayores cotas de calidad a

lo largo del tiempo mediante el seguimiento constante del Servicio.

Para implementar la CSI podemos adoptar un enfoque global del Ciclo de Vida, particular de

un servicio concreto o directamente funciona. En cualquier caso, siempre es aconsejable

utilizar un modelo probado como el PDCA (Modelo de Deming, ya introducido en la Unidad 2).

Es un proceso que podemos dividir en 7 pasos. En ellos se realizan todas las modificaciones

para mejorar cualquier aspecto susceptible a optimizar, detectado por la Gestión del Nivel de

Servicio.

Para poder planificar la CSI es necesario un Plan de Mejora, que supone el punto de inicio para

el proceso llamado Plan de Mejora del Servicio (SIP).

Definición ITIL®: Plan de mejora: Un Plan formal para implementar mejoras a un Proceso o

Servicio de TI.


3

Mediciones de CSI

Antes de comenzar a efectuar la CSI, debe identificarse claramente la visión, estrategia y

objetivos.

A continuación debe medirse una línea de referencia con los primeros resultados de los

Indicadores Clave de Rendimiento (PKI), que servirán de base al resto de mediciones.

Finalmente se efectúa el ciclo de CSI, con sus diferentes fases de medición y análisis.

Es importante destacar que las mediciones en un Servicio siempre se realizarán con una

finalidad, y utilizando un modelo donde se consolida cada una de las fases antes de incorporar

nuevos procesos. Suelen seguirse estos pasos:

Planificar Para realizar una planificación de tareas (para lograr el objetivo final).

Comprobar Testear cualquier actividad anterior.

Justificar Explicar la necesidad de cualquier acción.

Actuar Para modificar un proceso.

Importante

Este modelo con los pasos PDCA (Planificar-Comprobar-Justificar-Actuar en inglés) se

conoce también como Ciclo de Deming.

7 Pasos de CSI

Para asegurarse que un CSI es un proceso efectivo, puede dividirse en 7 etapas:

1. Ideal del Servicio Debe realizarse un estudio inicial de la situación ideal de un

Servicio.

2. Realidad del Servicio Ciertos requisitos y situaciones deben adaptarse a la realidad.

Se deben detectar nuevos requisitos y opciones TI en cada momento.

3. Medición de datos Se debe realizar una medición para constatar que se ha

satisfecho el objetivo del Servicio, y la correcta ejecución de tareas intermedias.

4. Procesamiento Gracias a la medición, se obtendrán ciertos KPIs con la información

más importante de lo sucedido hasta el momento. Almacenarlos según las

necesidades.

5. Análisis Se deben analizar los KPIs para localizar los errores y las situaciones

irregulares.


4

6. Presentación Es necesario informar a los responsables y afectados de los resultados

del paso previo, para confirmar o denegar que se hayan conseguido los objetivos.

7. Correcciones Ante cualquier medida correctiva, debe iniciarse un nuevo ciclo de

CSI.

El proceso de mejora de CSI

Estas 7 fases son la mejor forma de lograr una mejora en el Servicio es seguir el ciclo PDCA, por

lo que de cierta manera es una forma de expandir las cuatro actividades propuestas por el

Ciclo de Deming de una forma más detallada.

Nota

Es habitual, y una “mala práctica”, querer reaprovechar un ciclo abierto. Muchas veces las

correcciones realizadas así degeneran en unas nuevas disconformidades, puesto que no se

tiene en cuenta si los requisitos iniciales han cambiado.

Como puede que estos 7 pasos parezcan un proceso demasiado genérico, vamos a intentar

mostrar cada uno de una forma un poco más precisa y concreta.

Ciclo de Deming: Paso 1. Ideal del Servicio

En este primer paso, partiendo del Catálogo de Servicios y de los Requisitos de Nivel de

Servicio (SLR), los propietarios han de delimitar qué se debe medir.


5

Entradas: Se tienen en cuenta todos los requisitos iniciales y, por supuesto, el

presupuesto. Y se plantean los objetivos particulares de los Servicios del Catálogo, y de la

organización en General.

Salidas: Con ellos obtenemos mediciones, factores críticos de éxito y PKIs.

Ciclo de Deming: Paso 2. Realidad del Servicio

Esta fase tiene como centro crítico el SLA. Todo lo que pueda medirse debe estar incluido en él

e incida qué se puede medir.

Entradas: Todas las situaciones ideales son imposibles de llevar a la práctica. Debido a ello,

se analiza la situación real de la empresa (flujos, procedimientos, manuales…) y las

mediciones ideales, y con todo ello se obtienen salidas más ajustadas a la realidad del

negocio.

Salidas: Las salidas son similares a las del paso anterior, pero contrastadas con el entorno

real, y con la adición de herramientas creadas o ajustadas a las necesidades.

Importante

Los Objetivos deben ser SMART (eSpecíficos, Medibles, Alcanzables, Relevantes y viables en

el Tiempo).

Ciclo de Deming: Paso 3. Medición de datos

Mediante herramientas automatizadas o de forma manual, se procederá a la recopilación de

los datos indicados en los pasos anteriores.


6

Entradas: CSI debe desarrollar una operativa de acuerdo con la Operación de Servicio, para

poder cumplir los SLA con un menor coste u ofrecer una mayor calidad. Para ello se

monitorizan los procesos, herramientas, elementos de configuración, la organización

general y los Servicios.

Salidas: Además de la obtención de todos los datos necesarios, deben planificarse los

procedimientos de monitorización, crearse nuevos acuerdos, y actualizar las herramientas

empleadas en los nuevos planes de disponibilidad y capacidad. Todo ello debe responder a

las preguntas de cuándo, cómo y bajo qué criterios se obtendrán los datos y dejarlo fijado.

Ciclo de Deming: Paso 4. Procesamiento

Es necesario disponer de los datos según las necesidades del negocio. El personal especializado

y los responsables pertinentes, se encargarán de desarrollar los procedimientos para indicar

cómo procesar los datos.

Entradas: Se toman los PKIs y los Factores Críticos de Éxito y se enumeran sus requisitos, la

forma de almacenarlos y agruparlos, cómo se van a monitorizar, la frecuencia, etc.


7

Salidas: Los datos quedarán procesados, y los planes de Disponibilidad y Capacidad

actualizados. Todo ello también documentado.

Ciclo de Deming: Paso 5. Análisis

El departamento TI es el encargado de proponer opciones de mejora. En un estado inicial,

realiza pruebas, obtiene documentaciones y establece diálogos con los interesados para

concebir las respuestas de cómo mejorar el conocimiento. Después se evalúan.

Entradas: Se utilizan los datos procesados en la fase anterior, para analizarlos en

profundidad y supervisar su idoneidad.

Salidas: Se obtiene el conocimiento DIKW (Nota: recordar la Unidad 7). Se comprobará

que los datos sean los adecuados, para descubrir si son necesarios cambios, si se están

obteniendo los datos adecuados, si ayudan a lograr los objetivos… etc.

Ciclo de Deming: Paso 6. Presentación (Informes del Servicio)

Toda la información acumulada hasta el momento, tomará forma en los Informes de Servicio.

Las diferentes agrupaciones en divisiones, equipos y departamentos, se encargarán de asumir

una determinada función comunicativa, dentro de la propia organización o con cualquier parte

del negocio (clientes, otros proveedores). El objetivo es ofrecer los informes de Servicio como

soporte para las decisiones del negocio.


8

Entradas: Se toman, por consiguiente, los informes resultantes de las fases anteriores.

Salidas: Se obtienen diferentes perspectivas estratégicas adaptadas hacia los distintos

destinatarios.

Ciclo de Deming: Paso 7. Correcciones

El proveedor de Servicios TI, según su organización, deberá realizar las medidas correctivas

que sean necesarias. Sin embargo, ¡Cuidado!, nunca se deben aplicar de forma inmediata. Es

necesario revisar de nuevo la Estrategia, rediseñar, efectuar la Transición adecuada, y

finalmente incorporar el Servicio a la operación habitual. En definitiva, debe efectuar los

procesos del Ciclo de Vida para optimizar el Servicio.

Entradas: Deben revisarse los SLAs, los PKIs, los informes, los procedimientos establecidos.

Salidas: Un ROI optimizado, y todos los demás aspectos del Servicio mejorados.


9

9.3. El Gestor de CSI

El Gestor de CSI

La Mejora continua del Servicio debe tener un responsable principal dentro de la organización.

Se denomina Gestor de CSI y es el encargado de investigar las necesidades del negocio,

analizar los requisitos y recursos necesarios, realizar las mediciones pertinentes, y en

definitiva administrar todo el CSI. Entre sus tareas están:

Detectar nuevas oportunidades de mejora y presentarlas a la dirección.

Asignar roles de CSI

Priorizar mejoras en colaboración con el Dueño del Servicio.

Identificar requisitos para el CSI y elaborar SIPs. (Colaborando con el Gestor del Nivel

de Servicio)

Identificar las herramientas necesarias, y su correcto uso.

Realizar mediciones, y establecer líneas base.

Definir y encontrar Factores Críticos de Éxito y KPI.

Evaluar los datos.

Encargarse de la concienciación de la necesidad de CSI en la organización.

En definitiva, el Gestor de CSI debe ser una persona capaz de ofrecer consejos, gestionar las

oportunidades de mejora entre los distintos integrantes de la plantilla y mantener unas buenas

relaciones entre la gestión de TI y el negocio.


10

9.4 Automatización del Servicio

Uso de tecnología y herramientas

La CSI es un proceso que afecta a todos los procesos del Ciclo de Vida del Servicio. Una forma

de optimizarlo suele implicar al menos cierto grado de automatización, y es aplicable en la

identificación, análisis, investigación, organización… y un buen número de procedimientos.

Hay que ser precavidos. Toda automatización, si además incorpora una herramienta, requiere

de formación y documentación asociada.

Nota

Puede incluso caerse en la “Trampa de herramientas”, donde los usuarios disponen de

soluciones excesivamente complejas, y la organización no ha asumido un proceso de

formación previo y unos recursos iniciales.

Así pues, la automatización lleva asociado casi siempre de forma implícita el uso de tecnología

y herramientas.

La tecnología no sólo se puede emplear para automatizar rutinas de un equipo de desarrollo,

también tienen una gran utilidad en la comunicación con los clientes.

Recomendaciones antes de automatizar

Sin embargo, la acción de automatizar, especialmente útil durante la Operación del Servicio,

pueden tener efectos muy negativos si no se tienen en cuenta previamente estas

recomendaciones:

Establecer las tareas e interacciones entre ellas de una forma clara Así será más

sencillo implementar la automatización.

Simplificar los procesos al mínimo En este caso evitaremos muchos errores,

siempre y cuando, no simplifiquemos los procesos hasta tal punto de suprimir

información vital.

Evitar las interacciones Si un proceso es hermético y está bien automatizado, es

susceptible de un bajo índice de errores, mientras que si está abierto al uso de

distintos usuarios o interacciones con otros procesos será más sencillo que conlleve

problemas.


11

Automatizar repeticiones y rutinas Si se automatizan todos los procedimientos, se

crea un consumo de recursos innecesario. Sólo es recomendable hacerlo con las

actividades más habituales.

9.5 Informes del Servicio

Informes del Servicio

Un paralelismo que suele ocurrir es el de “Un servicio bien documentado-Un buen servicio”. La

razón es obvia; un Servicio que ha sido bien documentado, necesariamente incorpora en su

existencia un proceso de depuración para optimizarlo y conseguir los informes asociados al

mismo tiempo.

El proceso de Informes del Servicio se encarga de la generación y entrega de todos los niveles

del Servicio, incluidos los resultados.

Se debe establecer un criterio para la generación de informes en la organización, que incluya

entre otros:

Planificación de informes.

Acuerdos con el contenido que deben incluir.

Nota

Es más importante delimitar qué debe y qué puede no incluir, que el contenido exacto del

informe.

Bases de datos asociadas

Soportes utilizados.

Forma de acceso.

Planificación de la revisión de informes

Monitorización del Servicio

Según los destinatarios de esos informes, serán creados en uno u otro formato, e incorporarán

determinada información.

Sin embargo, es importante que no pierdan nunca de vista la utilidad para los objetivos del

negocio.

Podemos diferenciar distintos tipos de informes, según las personas que hagan uso de ellos:


12

1. Directores: Los informes suelen mostrar la identificación de procesos a lo largo del tiempo,

para poder identificar riesgos y revisar la consecución de objetivos.

Nota

Los emprendedores y estrategas, disponen de informes con especial atención a los riesgos

y aspectos económicos, o modificaciones de los informes más habituales.

2. Empleados y responsables: Con los matices que conllevan los distintos puestos, suelen

diferenciar competencias, métricas individuales y asignación a ciertos procesos.

Nota

El personal muy cualificado, suele disponer de informes similares, pero con mayor nivel de

detalle en un proceso concreto.

3. Gestores: En este caso, normalmente indican recursos, equipos, objetivos, y la relación

entre todo ello, para medir las posibles mejoras.

Importante: Es mucho más efectivo un número amplio de informes con información concisa,

que pocos informes demasiado complejos. En cualquier caso, si un informe no tiene relación

con los demás, seguramente implique un error por haber perdido la ‘visión’ de negocio.

9.6 ROI

Tipos de ROI

Hemos insistido en que la CSI sólo debe realizar actividades en respuesta a unos objetivos

específicos del negocio, pero no siempre será sencillo definirlo en el proceso inicial de SS. Para

ello ITIL® propone los siguientes conceptos que pueden ayudarte a definirlo, y por

consiguiente, alcanzar un buen Retorno de Inversión (ROI).

Algunos de las definiciones que debemos conocer para optimizar el ROI:

Caso de negocio Un método para identificar objetivos de negocio que dependen de la

Gestión del Servicio.

Se trata de un elemento para toma de decisiones, soporte y planificación, con

consecuencias cualitativas y cuantitativas, para preconizar las consecuencias de una acción

del negocio. Generalmente se basa en un estudio económico, pero incluye cualquier

aspecto que sirva para anticipar el resultado de cualquier acción.


13

ROI Pre-Programa Técnicas para analizar cuantitativamente las inversiones en Gestión

del Servicio.

En este caso indica la inversión para que, en el futuro, aumente el flujo de entrada en caja

o se reduzca el flujo de salida. Se suelen dar dos métodos:

NPV (Valor Neto Actual): Donde se analiza el flujo de entrada y el de salida en caja, y

se calcula la diferencia. Suele ser bastante realista y más sencillo que IRR.

IRR (Ratio Interno de Retorno): Se compara el flujo de entrada de caja y los

rendimientos obtenidos a lo largo del Ciclo de vida.

ROI Post-Programa Técnicas para analizar retroactivamente las inversiones en Gestión

del Servicio.

Siempre es aconsejable realizar un análisis ROI tras haber lanzado cierta Gestión de

Servicio, aunque sin olvidar realizar un estudio ROI pre-programa previo. Mediante el ROI

post-programa se debe:

Definir las características del Servicio, desde unos objetivos claros, hasta los datos

necesarios asociados.

Calcular los costes del programa ITIL® (planificación, diseño, operación…)

Convertir todos los datos en una evaluación de costes. Este aspecto es difícil de

conseguir, pues hay ciertos elementos que son difícilmente cuantificables.

Finalmente deben analizarse todas las ventajas cualitativas y cuantitativas del programa.


1


Unidad 10. La certificación ITIL® V3 Foundation

Índice

10.1. Introducción.

10.2. Las certificaciones ITIL®.

10.3. Los candidatos.

10.4. La certificación ITIL® V3 Foundation.

10.5. Material de estudio.

10.6. Práctica de examen.

10.7. Agradecimientos finales.


2

10.1. Introducción

Introducción

Durante el transcurso de las nueve unidades precedentes, hemos intentado

familiarizarte con ITIL®. Se han descrito los procesos más habituales, las definiciones

utilizadas, y diferentes recomendaciones obtenidas de las mejores prácticas llevadas a

cabo hasta la fecha.

Ahora sólo resta hacer uso de todas estas recomendaciones e incluso demostrar los

conocimientos de la materia mediante las certificaciones ITIL®.

10.2 Las certificaciones ITIL®

Las certificaciones ITIL®

Existen distintas certificaciones, organizadas por distintos niveles de experto.

¿Qué utilidad tiene una certificación de ITIL®?

En primer lugar, gracias a una certificación ITIL®, mejorarás la calificación profesional y

dispondrás de una capacitación reconocida a nivel internacional.

Además, puede ser un paso interesante para comenzar con la implantación de buenas

prácticas de TI en tu organización, o colaborar en cualquier empresa, centro formador o

estudio que emplee ITIL®.

El primer certificado que puedes obtener, es el de ITIL® V3 Foundation. Existen también

equivalencias o ‘examen-puente’ para pasar de la versión 2 a la versión 3, si ya dispones de la

certificación V2.


3

Exámenes ITIL®

Aquí puedes ver algunos de los exámenes asociados a alguna certificación de ITIL® hasta la

fecha:

Código Examen

ITV23FB ITIL® V3 Foundation Bridge

ITV23MB ITIL® V3 Managers Bridge

ITV3CSI ITIL® V3 Intermediate: Continual Service Improvement

ITV3F ITIL® V3 Foundation

ITV3MLC ITIL® V3 Intermediate: Managing Across the Lifecycle

ITV3OSA ITIL® V3 Intermediate: Operational Support & Analysis

ITV3PPO ITIL® V3 Intermediate: Planning, Protection & Optimization

ITV3RCV ITIL® V3 Intermediate: Release, Control & Validation

ITV3SD ITIL® V3 Intermediate: Service Design

ITV3SO ITIL® V3 Intermediate: Service Operation

ITV3SOA ITIL® V3 Intermediate: Service Offerings & Agreements

ITV3SS ITIL® V3 Intermediate: Service Strategy

ITV3ST ITIL® V3 Intermediate: Service Transition

El esquema de certificación

ITIL® establece una ruta bien definida donde se organizan los distintos grados de

conocimiento, estructurados en forma de diferentes niveles.

Para alcanzar cualquier nivel, es necesario obtener un determinado número de créditos que

sólo pueden conseguirse mediante formación oficial, y aprobar los exámenes asociados.

a)

b)

c)

d)


4

a) Maestro en ITIL®

Se obtiene por invitación o probada experiencia.

b) Experto en ITIL® Gestión de Servicios v3

Requisito: Mínimo 22 Créditos (ITIL® Foundations + Nivel Intermedio en ITIL ® + Curso

Gestionando el Ciclo de Vida)

c) Nivel Intermedio

Requisito: Realizar 5 cursos Ciclo de Vida de los Servicios o 4 cursos Capacidades de los

Servicios (+ aprobado de los exámenes de cada módulo)

d) Nivel 1 de Fundamentos de ITIL ®

Sin requisitos previos. Es deseable nociones sobre TI.

(+ aprobado de ITIL® V3 Foundation)

10.3 Los candidatos

Los candidatos

El certificado de ITIL® Foundations V3.0 tiene como objetivo certificar que el candidato conoce

los conceptos básicos de ITIL®, su estructura y terminología. También constata que se han

comprendido los principios fundamentales de las prácticas de ITIL® para la Gestión del

Servicio.

En definitiva, esta certificación está orientada a Profesionales TI de una empresa que ha

implantado ITIL® (o que está planteando hacerlo), gerentes comerciales y directivos que

necesitan conocimientos básicos para la mejora de los servicios de TI.

En cualquier caso, un candidato certificado en Fundamentos de ITIL® V3 no está habilitado

automáticamente para aplicar prácticas ITIL® para la Gestión del Servicio, pero sí para

cooperar con el asesoramiento de expertos ITIL®.


5

10.4 La certificación ITIL® V3 Foundation

La certificación ITIL® V3 Foundation

La certificación Foundations ITIL® V3.0 puede obtenerse a través de un único examen, que

puedes realizar en cualquier centro examinador EXIN, Prometric o Vue autorizado.

Características del examen:

Duración del examen Dispones de 60 minutos para realizarlo. (75 minutos si lo

realizas en un idioma distinto a tu lengua materna).

Número de preguntas Debes responder a un total de 40 preguntas

Tipo de preguntas Se tratan de preguntas de respuesta múltiple

Material No se permite ningún material de estudio durante la realización del

examen.

Material adicional No se permite ningún material electrónico.

Aprobado Es necesario responder correctamente al menos al 65% de las preguntas

(26 preguntas).

Idioma Puedes realizarlo en Castellano, Inglés U.S., Francés, Alemán, Italiano,

Japonés, Coreano, Español latino-américa, Portugués y Chino simplificado.

10.5 Material de Estudio

Material de estudio

Esperamos que el curso actual sirva como material principal para la preparación del examen.

Sin embargo, si quieres asegurar un resultado positivo cuando te presentes, te recomendamos

revisar:

El Glosario de términos ITIL®. Resulta un elemento indispensable para conocer la

terminología ITIL®. En este mismo curso puedes ver un amplio catálogo.

Guías de gestión oficiales, que también puedes encontrar en castellano de:

SS Estrategia del Servicio de ITIL® (Service Strategy)


6

SD Diseño del Servicio de ITIL® (Service Design)

ST Transición del Servicio de ITIL® (Service Transition)

SO Operación del Servicio de ITIL® (Service Operation)

CSI Mejora Continua del Servicio de ITIL® (Continual Service Improvement)

Nota

Todo este material de “self-study” (estudio por tu cuenta) es de por sí sólo suficiente para

el examen de ITIL® V3 Foundation. Para exámenes más avanzados, necesitarás la guía y

apoyo de un instructor acreditado.

Nota

Aquellos que estudiaran en su momento la V2 de ITIL®, no deben preocuparse por el paso

a la V3. Los cambios más drásticos se han producido en la organización de los contenidos,

y no sobre los contenidos mismos.

10.7 Agradecimientos finales

Agradecimientos finales

En el transcurso de este curso, hemos intentado proporcionarte toda la información que

necesitas para acercarte a ITIL®.

De forma condensada te hemos mostrado la terminología más adecuada, los conceptos más

relevantes, y algunos ejemplos para que el aprendizaje resultara más ameno.

Si, además de estas enseñanzas, estás interesado en realizar la certificación ITIL® V3

Foundation, te recomendamos encarecidamente que revises el curso de forma pausada.

También te aconsejamos que revises las prácticas, y, por supuesto, el ensayo de examen final.

Existen numerosos detalles que puedes pasar por alto si realizas este curso con demasiada

rapidez.

En cualquier caso, esperamos que el curso haya sido de tu agrado y puedas emplear los

conocimientos adquiridos en tu futuro profesional.

ITIL V3 Foundation

Documents

Transcript of ITIL V3 Foundation