• Categories
• ITIL
• Calidad (Negocios)
• Diseño
• Business
• Tecnología

Citation preview

1 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 Servicios de comunicación

Diseñar, Desarrollar, Adaptar 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

  

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®





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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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. 2. 3. 4. 5.

Estrategia del Servicio. Diseño del Servicio. Transición del Servicio. Operación del Servicio. Mejora Continua del Servicio.

3 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 subobjetivo 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 ITIL® V3 Foundation. Fundamentos de ITIL®

(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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

  

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 eficaciaeficiencia).

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 ITIL® V3 Foundation. Fundamentos de ITIL®

        

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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.

Ciclo de Vida

Gestión Financiera

SS

UNIDAD 4

Gestión de la Demanda (DM) Gestión de la Cartera de Servicios (SCM) Gestión de Niveles de Servicio (SLM)

DS

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)

UNIDAD 5

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)

TS

4 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 

Refactorizados



Renovados



Racionalizados



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 ITIL® V3 Foundation. Fundamentos de ITIL®

  

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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 ITIL® V3 Foundation. Fundamentos de ITIL®

4.7 DS. Gestión de la Capacidad 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

   

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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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: Ciclo de Vida

Gestión Financiera

UNIDAD 4

Gestión de la Demanda (DM) Gestión de Cartera de Servicios (SPM)

SS

Gestión de Niveles de Servicio (SLM) Gestión del Catálogo de Servicios Gestión de la Capacidad Gestión de la Disponibilidad

UNIDAD 5

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

DS

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)

TS

3 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®



   

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

    

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

• 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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 ITIL® V3 Foundation. Fundamentos de ITIL®

   

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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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: Ciclo de Vida

UNIDAD 7

Gestión del Conocimiento. (DIKW y SKMS)

TS

Gestión de Versiones y Despliegues Gestión de Peticiones Gestión de Accesos Gestión de Eventos Gestión de Incidencias Gestión de Problemas

OS

3 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®







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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®





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 ITIL® V3 Foundation. Fundamentos de ITIL®





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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

 

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®



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 ITIL® V3 Foundation. Fundamentos de ITIL®

ITIL® V3 Foundation. Fundamentos de ITIL® 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

Exámenes ITIL® Aquí puedes ver algunos de los exámenes asociados a alguna certificación de ITIL® hasta la fecha:

Código ITV23FB ITV23MB ITV3CSI ITV3F ITV3MLC ITV3OSA ITV3PPO ITV3RCV ITV3SD ITV3SO ITV3SOA ITV3SS ITV3ST

Examen ITIL® V3 Foundation Bridge ITIL® V3 Managers Bridge ITIL® V3 Intermediate: Continual Service Improvement ITIL® V3 Foundation ITIL® V3 Intermediate: Managing Across the Lifecycle ITIL® V3 Intermediate: Operational Support & Analysis ITIL® V3 Intermediate: Planning, Protection & Optimization ITIL® V3 Intermediate: Release, Control & Validation ITIL® V3 Intermediate: Service Design ITIL® V3 Intermediate: Service Operation ITIL® V3 Intermediate: Service Offerings & Agreements ITIL® V3 Intermediate: Service Strategy 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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

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 ITIL® V3 Foundation. Fundamentos de ITIL®

 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.