Entender ITIL 2011Normas y mejores prácticas para avanzar hacia ISO 20000 Prefacio de Martin CROSS - General Manager MCS Associates El objetivo de este libro sobre ITIL es proporcionar al lector todas las claves para un correcto entendimiento de los procesos ITIL 2011 y su organización. El libro está estructurado a partir de la noción de «ciclo de vida de los servicios ». El libro servirá de hilo conductor para aquellos que ya hayan seguido una formación ITIL Foundation (Versión 3 o 2011) y permitirá, a todos los que aún no tienen ningún conocimiento sobre la materia, descubrir y entender las contribuciones de ITIL en la gestión de los servicios, así como la metodología para tener éxito en la implantación ITIL en la empresa, independientemente de su tamaño. A lo largo de todo el libro, el autor utiliza su experiencia profesional como Consultor y Formador ISO 9001 e ITIL, y presenta las diferentes normas que permiten situar correctamente a ITIL 2011 y a considerar una posiblecertificación ISO 20000. Para ello, se dedica una serie de capítulos a lasnormas, métodos y herramientas que facilitan la puesta en marcha y gestión de un entorno ITIL. En cada una de las secciones dedicadas a un proceso ITIL, el autor destaca las principales relaciones entre los diferentes procesos ITIL, así como los posibles beneficios y principales dificultades que pueden aparecer. Esto permite al lector entender la anidación de los procesos y las implicaciones que esto tiene. El último capítulo presenta un caso práctico de puesta en marcha de un proyecto ITIL en una empresa y permite entender mejor el desarrollo de este tipo de proyectos. Los capítulos del libro: Prefacio – Prólogo – ITIL y las normas – El ciclo de vida de la gestión de los servicios –
Material de descargaArchivos adicionales
Publicación: octubre 2012 Ref. ENI : DPT11ITI ISBN : 9782746076181 Share on facebookShare on email
Los procesos de la estrategia de servicios – Los procesos del diseño de los servicios – Los procesos de la transición de los servicios – Los procesos de la explotación de servicios – Mejora continua de servicios (CSI) – Puesta en marcha de un proyecto ITIL – Anexos
Jacques QUESNEL Jacques QUESNEL está cerficado en ITIL Foundation V2 y V3 - Trainer Accredited ITIL Foundation V2 y V3 – Experto en Calidad ISO 9001. Aplica los procesos ITIL desde hace muchos años en los proyectos de Experto en Calidad que ha desarrollado en diferentes empresas. Es toda esta experiencia, tanto técnica como pedagógica, la que hoy le permite proponer un libro claro y práctico de la puesta en marcha del referencial ITIL.
Prefacio En el mundo actual, la gestión de una empresa obliga a tener múltiples competencias, conocimientos y herramientas adaptadas. Al mismo tiempo, la empresa se debe enfrentar a retos y restricciones importantes. En este contexto, los sistemas de información juegan un papel estratégico principal, que tienen influencia incluso sobre la supervivencia de la empresa. De esta manera, la correcta gestión de los sistemas de información y las elecciones organizativas determinan, de una manera importante, el buen funciona- miento de la empresa. En el momento actual las empresas dependen, cada vez en mayor medida, de sus sistemas de información, cuyos requerimientos se hacen sentir tanto a nivel financiero como a nivel de la rapidez con la que la dirección de los sistemas de información debe responder a las necesidades de las empresas, siempre cambiantes, con una complejidad de los sistemas de información cada vez más importante. Si además de todo esto consideramos las nuevas tecnologías, movilidad, distribución geográfica, externalización de los servicios y conectividad, entenderemos con facilidad que la dirección de los sistemas de información tengan obligatoriamente que hacer malabares con todos estos elementos para poder ofrecer servicios de calidad para los negocios. Así, cada vez más las empresas y su dirección de sistemas de información tienen en consideración el uso de estándares, métodos y marcos de trabajo de dominio público, con el objetivo de mejorar la gestión de su sistema de información. Pero existen muchas opciones y es fácil perderse en este laberinto. Entre las diferentes opciones relacionadas con la gestión de los servicios, hoy en día ITIL representa una de las maneras más habituales para estructurar las direcciones de los sistemas de información de una forma clara y efectiva, basándose en las buenas prácticas reconocidas a través de todo el mundo. En la actualidad, ITIL está reconocido como un estándar de facto para la gestión de los servicios informáticos. Pero hay que reconocer que ITIL, debido a su actual evolución, sigue siendo una materia complicada para un neófito y es fácil perderse entre las innumerables posibilidades que ofrece. El presente libro propone, de una manera concisa y precisa, una visión de conjunto de ITIL, cubriendo todos los procesos, y presenta varias facetas de su aplicación. De esta manera, es un placer para mí felicitar a Jacques Quesnel por haber tenido éxito en la presentación del conjunto de conceptos ITIL en un único libro, bien estructurado y de lectura agradable. Jacques Quesnel, al que tengo el placer de conocer personal y profesionalmente, acumula una amplia experiencia en esta área, que le permite documentar sus conocimientos en la
puesta en marcha de los conceptos ITIL, así como en su gestión. Puesto que una buena receta no hace al buen cocinero, es necesario saber mezclar los componentes de manera correcta, para obtener un buen resultado. A través de las múltiples puestas en marcha de ITIL que he visto en todo el mundo, puedo comprobar con tristeza que, de manera habitual, las empresas no aprovechan al máximo los beneficios que ofrece ITIL, ya sea por falta de entendimiento de los conceptos o por una incorrecta aplicación de estos. Por este motivo, la experiencia de Jacques Quesnel representa una mina importante de información y recomendaciones propuestas en el libro. Esto representa un enorme beneficio para el lector que busque respuestas claras en esta área, tan fascinante como compleja. También es importante observar que el libro proporciona una vista de varios métodos, estándares y marcos de trabajo que permiten aprender la gestión de los sistemas de información con un enfoque más global, y posicionar ITIL entre sus compañeros de viaje. Permítanme una última reflexión: poco importan los esfuerzos realizados para emprender algo; si no hacemos las elecciones correctas, los resultados no serán los esperados. Este libro permitirá al lector tomar las elecciones correctas para obtener los beneficios que puedan aportar un enfoque ITIL bien entendido y gestionado. Martin Cross General Manager MCS Associates Coparticipante de la creación del método TIPA Participante de los grupos de trabajo ISO 20 000 y 15 504
PROLOGO Una nueva versión de este libro Las buenas prácticas ITIL evolucionan. En 2011, la OGC ha publicado una nueva versión de ITIL. Una de las primeras novedades de ITIL 2011 está en la nomenclatura de las versiones. Para estar alineado con las reglas de nomenclatura de las versiones de las normas ISO, a partir de ahora el nivel de versión se indica por el año de publicación, lo que simplifica la identificación de las versiones. Por lo tanto, la nueva versión de ITIL es ITIL 2011. Sin ser una versión principal, esta versión añade cambios, fundamentalmente en la fase estratégica del servicio, y explica algunos puntos que no estaban lo suficientemente claros en la versión ITIL V3. Por lo tanto, era importante hacer que este libro evolucionara para que permaneciera actualizado.
ITIL Y LAS NORMAS
ITIL ITIL (Information Technology Infrastructure Library, que traducido literalmente significa «Librería de infraestructura de las tecnologías de información»), es un conjunto de libros en los que se presentan numerosas prácticas, procedimientos y métodos utilizados en la gestión de servicios informáticos. ITIL es una recopilación de las mejores prácticas aplicadas desde hace años en organizaciones de tamaño más o menos importante. Por tanto, ITIL se utiliza como línea directriz en la implantación de una gestión de servicios en un entorno informático. Los procesos descritos en ITIL se ponen en marcha, en su totalidad o parte de ellos, en función de su empresa, actividad, tamaño y objetivos estratégicos.
1. Histórico
1972: comienzo de los trabajos de desarrollo de las prácticas por la CCTA (Central Computing and Telecommunication Agency).
1990: publicación de los primeros elementos por el organismo gubernamental británico CCTA.
1991: primer examen de certificación ITIL.
2001: publicación de la segunda versión de ITIL (ITIL V2).
2005-2006: evolución importante en el ámbito de las certificaciones.
Finales de 2005: adopción de la norma ISO/CEI 20000 para las empresas, basadas en el marco ITIL.
2007: publicación de ITIL-Refresh (ITIL V3).
2011: publicación de la nueva versión (ITIL 2011).
a. ¿Qué no es ITIL? ITIL no es:
Un lenguaje.
Un proceso.
Un método.
Una norma.
b. ¿Qué es ITIL? Un conjunto de manuales que describen los procesos integrados de gestión de las TI (tecnologías de la información). Un marco de referencia global que:
Describe las mejores prácticas de gestión de los servicios de TI.
Pertenece al dominio público.
Es independiente de los fabricantes de TI (software y hardware) y de las empresas de consultoría, aunque ampliamente reconocido por estas últimas.
2. Los actores El principal actor es el OGC (Office of Government Commerce), que es el propietario de los derechos de ITIL. Otro actor importante es el itSMF (it Service Management Forum). Existen foros en la mayoría de los países, también en España (http://www.itsmf.es). Hay ocho organismos de certificación (Examination Institutes):
APMG-UK
EXIN
ISEB
Loyalist College (LCS)
Dansk IT
DF Certifiering
TUV SUD
CSME
Estos son los únicos organismos que pueden entregar certificaciones. Las certificaciones ITIL solo se conceden a las personas. Las empresas se pueden certificar en el marco de ISO 20000. Puede encontrar las direcciones de estos organismos en el sitio Web ITIL: http://www.itil-officialsite.com/ExaminationInstitutes/ExamInstitutes.aspx
oficial
A raíz de los trabajos de la organización británica de normalización, ha visto la luz la norma BS15000, que recoge la mayor parte de las prácticas ITIL. Desde 2005, esta norma se ha convertido en una norma internacional: ISO/IEC 200002011 (ver la siguiente sección).
Atención: el programa de certificación puesto en práctica actualmente por APMG y OGC ha permitido certificar las primeras herramientas. Sin embargo, varios fabricantes de software han optado por tener en cuenta las recomendaciones ITIL para que sus herramientas respeten de manera más fiable las mejores prácticas de ITIL. El término «Compliant ITIL» no es en absoluto una garantía de que la herramienta le permita realizar el conjunto de operaciones descritas en ITIL 2011. Por ejemplo, podemos observar que ciertos programas de software solo tienen en cuenta los servidores en la CMS (Configuration Management
System - Sistema de Gestión de la Configuración); ¿cómo se gestiona en este caso la noción de CI (Configuration Item - Elemento de Configuración) a nivel de los puestos de trabajo o del software?
3. Las versiones de ITIL a. ITIL V2 Un determinado número de empresas todavía están bajo ITIL V2, aunque podemos pensar que van a evolucionar hacia ITIL 2011 antes o después.
Presentación de la estructura de ITIL V2 La versión ITIL V2 está formada por 10 libros. Los dos más importantes son:
El suministro de servicios (Service Delivery), que se refiere a los procesos necesarios para el diseño y suministro de servicios.
Los servicios de soporte (Service Support), que se refiere a los procesos necesarios para el mantenimiento y la asistencia técnica de los servicios.
b. Los procesos ITIL V2 Procesos tácticos
Gestión de niveles de servicios
Gestión financiera
Gestión de la capacidad
Gestión de la continuidad de los servicios
Gestión de la disponibilidad
Gestión de la seguridad
Procesos operativos
Gestión de cambios
Gestión de incidencias
Gestión de problema
Gestión de configuraciones
c. ITIL V3 Esta versión de ITIL se publicó en 2007 y representa una evolución importante respecto a la V2. Los conceptos de la versión anterior se conservan en lo fundamental; sin embargo, esta versión añade cambios importantes y, en particular, sobre la estructura global. Esta versión se basa en una noción nueva: el ciclo de vida de la gestión de los servicios. La versión ITIL 2011 también se basa en esta noción. Esta noción se detallará en el capítulo El ciclo de vida de la gestión de los servicios.
Presentación de la estructura de ITIL V3 El núcleo de ITIL V3 se compone de cinco libros principales:
Estrategia de servicios
Diseño de servicios
Transición de servicios
Operación de servicios
Mejora continua de servicios
d. Los procesos ITIL V3 Nivel decisional: Mejora continua de servicios
Mejora continua de servicios
Nivel decisional: Estrategia de servicios (Procesos estratégicos)
Estrategia de servicios
Gestión del porfolio de servicios
Gestión financiera
Gestión de la demanda
Nivel decisional: Diseño de servicios (Procesos estratégicos y tácticos)
Gestión del catálogo de servicios
Gestión del nivel de servicios
Gestión de la disponibilidad
Gestión de la capacidad
Gestión de la continuidad de los servicios informáticos
Gestión de la seguridad informática
Gestión de proveedores
Nivel decisional: Transición de servicios (Procesos tácticos y operativos)
Gestión de cambios
Gestión de los activos de servicios y configuraciones
Gestión de los despliegues y de las entradas en producción
Validación y prueba de los servicios
Evaluación
Gestión del conocimiento
Nivel decisional: Explotación de los servicios (Procesos operativos)
Gestión de eventos
Ejecución de consultas
Gestión de incidencias
Gestión de problemas
Gestión de la evaluación
e. ITIL 2011 Esta nueva versión de ITIL se presenta como una evolución de la versión V3. Los puntos más importantes que se tienen en cuenta son: Estandarización de cada proceso
Objetivos
Perímetro
Valor para las empresas
Estandarización de los procesos
Objetivos
Perímetro
Valor para las empresas
Políticas, principios y conceptos básicos
Actividades del proceso
Activadores, entradas, salidas e interfaces
Factores de éxito críticos
Información
Riesgos y oportunidades (cuando se implementan)
f. Los procesos ITIL 2011 Nivel decisional: Mejora continua de los servicios
Mejora de los procesos en siete etapas
Nivel decisional: Estrategia de servicios (Procesos estratégicos)
Gestión de la estrategia de servicios
Gestión del porfolio de servicios
Gestión financiera
Gestión de la demanda
Gestión de la relación comercial
Nivel decisional: Diseño de servicios (Procesos tácticos)
Coordinación del diseño
Gestión del catálogo de servicios
Gestión de los niveles de servicios
Gestión de la disponibilidad
Gestión de la capacidad
Gestión de la continuidad de los servicios informáticos
Gestión de la seguridad informática
Gestión de proveedores
Nivel decisional: Transición de servicios(Procesos tácticos y operativos)
Planificación y soporte de la transición de servicios
Gestión de cambios
Gestión de los activos de servicios y configuraciones
Gestión de los despliegues y de las entradas en producción
Validación y prueba de servicios
Evaluación de los cambios
Gestión del conocimiento
Nivel decisional: Explotación de los servicios (Procesos operativos)
Gestión de eventos
Ejecución de consultas
Gestión de incidencias
Gestión de problemas
Gestión de los accesos
4. La filosofía de ITIL La filosofía de ITIL se basa en cuatro principios:
Considerar que la organización TI está estrechamente unida al «negocio» y que el uno no funciona sin el otro.
Proponer una estructura basada en los procesos que se debe adaptar a cada organización, ya sea esta grande o pequeña, y a todas las tecnologías.
Los servicios de TI se definen para ajustarse a lo esperado por parte de los usuarios y los clientes, es decir, al negocio, y se basan en un conjunto de procesos.
Identificar las prácticas más eficaces para utilizar los recursos humanos y tecnologías necesarias para ejecutar procesos y entregar los servicios esperados.
a. Los objetivos de ITIL El objetivo de ITIL es responder a estos cuatro puntos:
Alinear los servicios ITIL a las necesidades del «negocio» de los clientes actuales y futuros.
Mejorar la calidad de los procesos proporcionados.
Mejorar la eficacia y aspirar a la eficiencia de la organización TI.
Reducir los costes de entrega de los servicios TI a más largo plazo.
Esto implica:
Una transición, desde una cultura generalmente orientada a la tecnología, hasta una cultura orientada alrededor del «negocio» y de los servicios.
Gestionar la organización TI como una unidad de «negocio».
b. Algunas definiciones importantes
Para entender correctamente los objetivos de la puesta en práctica de ITIL, es necesario definir algunos términos que se utilizarán en este libro, para que tenga una comprensión clara de su significado. TI: Tecnologías de la información. Con frecuencia, es el término utilizado para definir la organización TI, ya sea el servicio informático o la dirección informática, en función del tamaño de la empresa o de su organización. Algunas veces, la sigla TI se traduce al inglés y se convierte en IT. Es la organización que proporciona el servicio al cliente (interno o externo). Negocio: los términos «profesión», «negocio» o «tarea» tienen el mismo significado. Según la organización de la empresa cliente, podemos utilizar un término u otro. El negocio es una denominación de la entidad que utiliza el servicio proporcionado por la organización TI. Si tomamos el ejemplo de un banco, el cliente es el banco. En el seno de esta empresa, existen varios negocios (finanzas, seguros, bolsa...), que utilizan todos los servicios proporcionados por las TI. Sin embargo, cada negocio utiliza uno o varios servicios específicos que le son propios y para los que se han definido y validado los niveles de servicio específicos, entre el negocio y la organización TI. Servicio: medio de proporcionar un valor añadido a los clientes, facilitándoles la obtención de los resultados esperados, respetando las restricciones de costes y riesgos (ver la siguiente sección). Cliente: persona o grupo que define los objetivos de los niveles de servicio para cada servicio. En general, es quien da la orden. Aprueba y firma los acuerdos de niveles de servicio; generalmente, también es responsable de la financiación de los servicios.
Usuario: persona que utiliza diariamente los servicios proporcionados por la organización TI. Proveedor de servicios: organización que proporciona servicios a uno o varios clientes internos o externos. Existen tres tipos de proveedores de servicios:
Tipo I - Proveedor interno: proporciona servicios internos que forman parte de la unidad de negocio. Puede haber varios proveedores de tipo I en la organización.
Tipo II - Proveedor de servicios compartidos: proveedor de servicios internos que proporciona servicios a una o varias unidades de negocio.
Tipo III - Proveedor externo: proveedor de servicios externos, que proporciona servicios para un cliente.
Proceso: un proceso está formado por una o varias actividades relacionadas (ver la siguiente sección). Propietario de proceso: el propietario de uno o varios procesos es responsable de los resultados del proceso y rinde cuentas a su dirección. Responsable de procesos: el responsable de un proceso está encargado de la realización de un proceso y rinde cuentas al propietario del proceso. CMS (Configuration Management System): sistema de gestión de configuraciones. En ITIL V2 hablamos de CMDB (Configuration Management Data Base). CMDB (Base de datos de gestión de configuraciones): modelo físico que refleja la infraestructura que contiene todos los CI, su estado y las relaciones entre ellos. Actualmente, todavía muchas personas hablan de CMDB en lugar de la CMS, por motivos de comprensión o facilidad. CI (Elemento de Configuración), componente de la infraestructura o elemento asociado a una infraestructura, bajo el control de la gestión de configuraciones. Incidencia: todo evento que no forma parte de las operaciones estándares de un servicio y que cause o pueda causar una interrupción o reducción de la calidad del servicio. Petición de servicio: petición que no refleja un mal funcionamiento de un servicio de TI y que no altera el estado de la infraestructura de un servicio. Problema: causa subyacente desconocida para una o varias incidencias.
c. ¿Qué es una buena práctica? Una buena práctica se define por varios elementos:
Se desarrolla a partir de elementos generales aplicables a múltiples contextos del negocio u organizativos.
Es ampliamente reconocida por la industria como modelo de referencia.
Constituye un éxito comprobado, ha sido implementada en las organizaciones y aporta un valor para el servicio proporcionado.
Las mejores prácticas más utilizadas en el entorno informático son las siguientes:
ITIL, COBIT, CMMI, PRINCE2, PMBOK y Six Sigma.
Las normas más utilizadas en el entorno informático son las siguientes:
ISO 9001-2008
ISO 20000-2011
IS0 27000
d. ¿Qué es un servicio?
Un servicio es el resultado de las acciones realizadas por un proveedor para entregar lo que ha sido acordado.
El servicio se proporciona a través de una interacción entre cliente, usuarios y proveedor.
El cliente y el proveedor pueden ajustar el servicio durante su entrega.
La satisfacción con un servicio depende, de manera decisiva, de las experiencias anteriores del cliente, los usuarios, sus expectativas y de una buena gestión de estas últimas.
Ejemplos de servicios TI:
Servicio de mensajería electrónica
Servicio de impresión
Servicio de utilización de un sistema financiero
e. Enfoque a procesos Para que un organismo (estructura, empresa, conjunto de actividades...) funcionen eficazmente, es necesario identificar y gestionar muchas actividades estructuradas y relacionadas. La norma ISO 9001:2008 fomenta la adopción de un enfoque a procesos durante el desarrollo y puesta en práctica de un sistema de gestión de la calidad, en el seno de la organización. La exigencia de mejora continua de la calidad permite aumentar la satisfacción de los clientes en relación con sus requerimientos. ITIL también se basa en un conjunto de procesos relacionados. El enfoque a procesos representa la puesta en marcha de un sistema de procesos en el seno de un organismo, así como la identificación de las interacciones entre los diferentes procesos. Un proceso está formado por una o varias actividades estructuradas y relacionadas. Un proceso proporciona resultados específicos. Definición de un proceso
Un proceso es un conjunto de actividades estructuradas y relacionadas para proporcionar un resultado específico. Un proceso incluye uno o varios elementos de entrada, que transforma en uno o varios elementos de salida. De manera habitual, el elemento de salida de un proceso es el elemento de entrada del proceso siguiente. Los procesos deben estar documentados y controlados. Un proceso se debe poder medir. Para esto, usaremos indicadores. Algunos de estos indicadores se llaman KPI (Key Performance Indicator). Un KPI es un indicador que permite medir el rendimiento de una actividad.
Descripción de un proceso Para obtener un funcionamiento óptimo del sistema de calidad, es necesario vigilar, medir y analizar estos procesos. La gestión de estos procesos se realiza para obtener el resultado deseado. Cuando se utiliza en un sistema de gestión de la calidad, este enfoque destaca la importancia de:
Entender y cumplir los requerimientos.
Considerar los procesos en términos de valor añadido.
Medir el rendimiento y la eficacia de los procesos.
Mejorar continuamente los procesos, basándose en mediciones objetivas.
La mejora continua de los procesos se basa en la Rueda de Deming.
f. Definición de los objetivos La definición de un objetivo debe responder obligatoriamente al acrónimo SMART.
S de Sencillo. Cada objetivo se debe expresar de manera clara y concisa para que los encargados de implementar el proceso puedan entenderlo.
M de Medible. Para cada objetivo, hay que poder medir el nivel alcanzado. Es el único medio para evaluar su evolución.
A de Alcanzable. No sirve para nada fijar objetivos demasiado ambiguos. Esto también implica que la(s) persona(s) encargada(s) de implementar el proceso haya(n) aceptado este nivel de objetivo.
R de Realista. Para esto, el objetivo debe ser compatible con la cultura y la estructura de la empresa.
T de Temporal. Para esto, es imprescindible definir en qué periodo de tiempo se debe medir el objetivo.
Atención: tener multitud de objetivos diferentes para un mismo proceso no es acertado. De manera ideal, un proceso no debería tener más de 5 a 7 objetivos.
g. El principio de la Rueda de Deming El principio de la Rueda de Deming se descompone en cuatro actividades consecutivas, dentro de un ciclo de funcionamiento (en general, la duración de un ciclo es de un año). Este principio también se denomina PDCA.
La Rueda de Deming Habitualmente, estos cuatro ciclos se definen de la siguiente manera: P de Plan (Planificar) En esta fase vamos a:
Identificar la estrategia de mejora.
Planificar, decidir los objetivos, el calendario, las responsabilidades y los recursos, basándonos en lo que hemos definido durante la actividad Act.
Definir los indicadores que permitirán medir la mejora real.
D de Do (Hacer) En esta fase vamos a:
Realizar las acciones que se definen en el plan, respetando los objetivos y el calendario.
C de Check (Controlar) En esta fase vamos a:
Realizar el control o los controles para verificar los resultados obtenidos durante la fase Do.
Verificar los resultados de los indicadores.
A de Act (Definir los ejes de mejora) A partir de los resultados del Check, vamos a identificar las direcciones de mejora. Estas direcciones de mejora se validarán durante el próximo ciclo en el Plan.
h. La calidad La calidad representa la totalidad de características de un servicio, que le permiten satisfacer las necesidades identificadas e implícitas. ¿Cómo influye la calidad en el servicio?
La calidad del servicio refleja la consecución de las expectativas del cliente y de los usuarios, de manera constante.
La puesta en marcha de medidas de control del proceso de entrega de los servicios permite conseguir una mayor consistencia.
El control de la calidad requiere un diálogo continuo entre el cliente, los usuarios y el proveedor.
Las medidas de control permiten un mayor conocimiento del coste de los servicios y establecer mejor cuál es el precio razonable asociado a los servicios esperados.
La calidad del servicio no se puede evaluar de manera anticipada.
Las normas Más adelante encontrará las diferentes normas, modelos y mejores prácticas utilizadas en la actualidad en el entorno de los servicios informáticos.
1. ISO 9001:2008 La norma ISO 9001 tiene por objetivo la certificación de las empresas, No obstante, también existe una certificación para las personas: Auditor certificado ISO 9001. La norma ISO 9001 forma parte de la serie de normas ISO 9000, relativas a los sistemas de gestión de la calidad, y establece los requisitos exigidos para la existencia de un sistema de gestión de la calidad. Estos requerimientos servirán como base a la certificación del organismo. Las otras normas de la serie 9000: vocabulario (ISO 9000), líneas directrices (ISO 9004)... no contienen requisitos y no pueden servir de base para la certificación. La versión en vigor de ISO 9001 es la versión de 2008 (aparecida en noviembre de 2008). La versión ISO 9001:2000 tuvo validez hasta noviembre de 2010. En relación con la documentación sustituida (ISO 9001:2000), la norma NF EN ISO 9001:2008 no añade ningún requisito nuevo. Únicamente introduce aclaraciones a los
requisitos existentes de la norma NF EN ISO 9001:2000. También añade las modificaciones destinadas a mejorar la coherencia con la norma NF EN ISO 14001:2004.
a. Enfoque a procesos La norma ISO 9001:2008 fomenta la adopción de un enfoque a procesos en el momento del desarrollo y puesta en práctica de un sistema de gestión de la calidad, en el seno del organismo. La exigencia de mejora continua de la calidad permite incrementar la satisfacción de los clientes en relación con sus requerimientos. El enfoque a procesos se refiere a la puesta en marcha de un sistema de procesos en el seno de un organismo, así como a la identificación de las interacciones entre los diferentes procesos (ver la sección El enfoque a procesos). Para obtener un funcionamiento óptimo del sistema de calidad, es necesario hacer un seguimiento, medir y analizar estos procesos. La gestión de estos procesos se realiza con el objetivo de obtener el resultado deseado. Cuando se utiliza en un sistema de gestión de la calidad, este enfoque destaca la importancia de:
Entender y cumplir los requerimientos.
Considerar los procesos en términos de valor añadido.
Medir el rendimiento y la eficacia de los procesos.
Mejorar constantemente los procesos basándose en medidas objetivas.
b. Los requerimientos de la norma * * Una parte del texto está extraída del sitio de Wikipedia (http://es.wikipedia.org/wiki). Este texto se encuentra bajo licencia CC-BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0/). Los requerimientos de la norma están relacionados con cuatro grandes áreas:
La responsabilidad de la dirección: exigencia de hechos por parte de la dirección, como actor principal y permanente de la actividad.
El sistema de calidad: requisitos administrativos que permiten conservar los activos. Necesidad de tener en cuenta la noción de sistema.
El proceso: requerimientos relativos a la identificación y gestión de los procesos, que contribuyen a la satisfacción de las partes interesadas.
La mejora continua: requerimientos de medida y registro del rendimiento, a todos los niveles útiles, así como el inicio de acciones de progreso eficaces.
Detalle de la norma ISO 9001 - versión 2008 La puesta en marcha de un sistema de gestión de la calidad según los requerimientos de la norma ISO 9001-Versión 2008 consiste en:
Demostrar la capacidad de proporcionar de manera regular un producto, conforme a los requerimientos del cliente y a las exigencias reglamentarias aplicables.
Tratar de aumentar la satisfacción de los clientes mediante la aplicación eficaz del sistema y, en particular, poner en práctica un proceso de mejora continua (según el principio PDCA o Rueda de Deming).
Los requerimientos de la norma Los requerimientos de la norma ISO 9001 se presentan en ocho artículos:
Artículo 1: dominio de la aplicación
Artículo 2: referencias normativas
Artículo 3: términos y definiciones
Artículo 4: sistema de gestión y de calidad
Artículo 5: responsabilidad de la dirección
Artículo 6: gestión de recursos
Artículo 7: realización del producto
Artículo 8: medida, análisis y mejora
La norma se basa en ocho principios de gestión:
Orientación a cliente
Liderazgo
Implicación del personal
Enfoque a procesos
Gestión mediante el enfoque a sistemas
Mejora continua
Enfoque real para la toma de decisiones
Relaciones mutuamente beneficiosas con los proveedores
Fuente: http://es.wikipedia.org/wiki/ISO_9001
2. COBIT * COBIT es un modelo de organización; no es una norma internacional reconocida.
COBIT (Control Objectives for Information and related Techonology - Objetivos de control para la Información y Tecnología relacionadas) es una herramienta unificadora que permite establecer un lenguaje común para hablar de la gestión de los sistemas de información, integrando al mismo tiempo otros repositorios, tales como ISO 9000 o ITIL. COBIT fue desarrollada en 1994 por el ISACA (Information Systems Audit and Control Association) y publicada en 1996 (http://www.isaca.org/bookstore). ISACA está presente en diferentes ciudades españolas, así como en Internet en sitios Web comohttp://www.isacamadrid.es o http://www.isacabcn.org. Ampliamente utilizada como herramienta de conformidad con Sarbanes-Oxley y otras numerosas normas mundiales, COBIT es anterior a la legislación de control adoptada en todo el mundo. Es el resultado de 15 años de búsqueda y cooperación por parte de los expertos en TI y comerciales internacionales. Es un repositorio unificador internacional que integra a todas las normas principales mundiales de la tecnología de la información, como ITIL, CMMI e ISO 17799. La nueva versión de este repositorio se puede descargar gratuitamente en el organismo ITGI independiente, sin ánimo de lucro, en la dirección http://www.itgi.org. Es un marco de control que tiene como objetivo ayudar en el manejo de la gestión del riesgo (seguridad, fiabilidad, conformidad) y de las inversiones. COBIT ha evolucionado y la versión 4 apareció en España en el año 2007. COBIT es un enfoque orientado a procesos.
Fuente: http://es.wikipedia.org/wiki/CobiT COBIT descompone los sistemas informáticos en cuatro áreas principales, que engloban un conjunto de 34 procesos. A su vez, estos procesos se dividen en 215 actividades.
a. Los cuatro dominios Los cuatro dominios principales de COBIT:
Planificación y organización (10 procesos)
Adquisición y puesta en práctica (7 procesos)
Proveedor del servicio (13 procesos)
Seguimiento y evaluación (4 procesos)
b. Los seis niveles Para medir la madurez de los procesos, CobiT utiliza una evaluación basada en seis niveles:
Inexistente
Inicializada, caso a caso
Reproducible aunque intuitivo
Proceso definido
Gestionable y medible
Optimizado
En resumen, COBIT es un marco de referencia para controlar el buen gobierno de los SI a lo largo del tiempo. Se basa en un conjunto de buenas prácticas recogidas por los expertos de SI. Hoy en día, un número creciente de empresas importantes ponen en práctica el modelo COBIT para poder proporcionar información clara y comprensible, no solo a sus accionistas, sino también a las autoridades oficiales de sus países o con los que tienen una actividad o mantienen relación.
3. CMMI * CMMI es un modelo de organización, no es una norma internacional reconocida. CMMI, siglas para Capability Maturity Model + Integration, es un modelo de referencia, un conjunto estructurado de buenas prácticas, destinado a entender, evaluar y mejorar las actividades de las empresas de ingeniería. CMMI fue desarrollado por el SEI (Software Engineering Institute) de la universidad Carnegie Mellon, inicialmente para entender y medir la calidad de los servicios proporcionados por los proveedores de software informático del Departamento de Defensa de los Estados Unidos (DoD). En la actualidad se usa ampliamente en las empresas de ingeniería informática, por los directores de sistemas informáticos e industriales, para evaluar y mejorar sus propios desarrollos de productos.
Histórico En los años ochenta, el departamento de defensa de los Estados Unidos solicitó la elaboración de un repositorio de criterios que le permitieran evaluar a sus proveedores de software. Después de una lenta maduración, el SEI (Software Engineering Institute), financiado por el DoD, presentó en 1991 el CMM (Capability Maturity Model). Este modelo de referencia solo se aplica a las buenas prácticas de la ingeniería de software. Después de un importante entusiasmo por este modelo, vieron la luz otros modelos similares, tales como:
SE-CMM (System Engineering)
SA-CMM (Software Acquisition)
IPD-CMM (Integrated Product Development)
People CMM (para la gestión de los recursos humanos)
SS-CMM (Supplier Sourcing)
Fue necesario cambiar el nombre CMM «inicial» por SW-CMM (SW para SoftWare).
En 2001, el SEI propuso una nueva versión de su modelo, el CMMI ( Capability Maturity Model Integration), que engloba las buenas prácticas de los otros modelos, salvo la gestión de recursos humanos, que ya no lo tuvo en cuenta (versión 1.1). En 2006, se actualizó la versión del modelo (versión 1.2). Esta última versión del CMMI, la actual, tiende a simplificar el modelo y a mejorar la consideración de los componentes de tipo hardware. El modelo CMMI define una escala de medida de la madurez de cinco niveles y los indicadores necesarios para evaluar las actividades dirigidas por un equipo, en relación con esta escala; el equipo puede ser un grupo de trabajo, uno o varios proyectos, una sociedad e incluso una institución del Estado. CMMI es un marco genérico de procesos que se declina en tres modelos (llamados constelaciones).
a. Los tres modelos
CMMI-DEV para el desarrollo de sistemas (software u otros).
CMMI-ACQ para las actividades en el ámbito de las adquisiciones (versión publicada en 2007).
CMMI-SVC para el suministro de servicios (publicación en febrero de 2009).
La particularidad de estos tres modelos es que tienen una parte común (el núcleo o «core» en inglés), que representa alrededor del 60% de las prácticas. De un modelo a otro, las diferencias se centran en la categoría de «ingeniería», cuyas prácticas varían según la actividad implicada. El modelo CMMI se utiliza mayoritariamente en las sociedades informáticas; sin embargo, los principios de CMMI se aplican a cualquier actividad de ingeniería: arquitectura, mecánica, electrónica...
Madurez De acuerdo con la definición dada en el CMMI, la madurez de una organización es el grado con el que esta despliega los procesos explícitamente y de manera coherente, procesos que se documentan, gestionan, miden, controlan y mejoran continuamente. Un nivel de madurez (Maturity Level) corresponde a la consecución de un nivel de capacidad uniforme para un grupo de procesos. Un nivel de capacidad (Capability Level) mide la consecución de los objetivos de un proceso para el nivel dado.
b. Descriptivo de un modelo Las buenas prácticas recomendadas por el modelo (versión 1.2), se reúnen en 22 áreas de proceso, agrupadas a su vez en cinco niveles de madurez. Inicial (Initial), nivel de madurez 1 No hay procesos establecidos o bien están documentados, pero no se utilizan. No hay supervisión (monitoring), ninguna evaluación de rendimiento y no existe comunicación. En este nivel, tanto las soluciones como los proyectos son decididos, desarrollados e instaurados por un individuo.
No hay descripción del nivel 1 de madurez en el modelo. Reproducible (Managed), nivel de madurez 2 Los planes de proyecto (plan de desarrollo, control de calidad, gestión de configuración...) se definen para cada proyecto. El jefe de proyecto tiene una fuerte responsabilidad en el nivel 2: debe definir, documentar, aplicar y mantener actualizados sus planes. De un proyecto a otro, el jefe de proyecto se beneficia y mejora sus prácticas de gestión de proyectos de ingeniería. Estándar (Defined), nivel de madurez 3 En este nivel, se pone en práctica una estandarización adecuada, una capitalización centralizada (en particular, sobre las medidas realizadas en los proyectos) y un repositorio de control interno (o sistema de calidad). Existen líneas directrices, un plan estratégico y una planificación de mejora de procesos. Controlado (Quantitatively managed), nivel de madurez 4 Los procesos se basan en objetivos cuantitativos de calidad. Se tiene en cuenta la expresión de la calidad solicitada por el cliente para cuantificar los objetivos del proyecto y establecer los planes, según la capacidad de los procesos de la organización. Optimizado (Optimizing), nivel de madurez 5 Los procesos que se gestionan cuantitativamente para el seguimiento del proyecto (nivel 4 de madurez) están en continua optimización con el objetivo de anticipar las evoluciones previstas (necesidades de clientes, nuevas tecnologías...).
Fuente: http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration
4. PRINCE2 PRINCE es un método, no es una norma internacional reconocida. La certificación PRINCE se destina a las personas, y no a las organizaciones informáticas. PRINCE es un método y una guía de mejores prácticas en términos de gestión de proyectos. PRINCE, originariamente llamado PROMPT, fue adoptado por la OGC en 1989 y aplicado en los proyectos del gobierno británico. En 1996, la última versión del método (PRINCE2) fue ampliada y se hizo más flexible para poder gestionar proyectos de todo tipo y tamaño. El OGC es el propietario y depositario del método PRINCE2 y, en los orígenes de ITIL, recoge las mejores prácticas de gestión de servicios informáticos. PRINCE2 es de dominio público.
Método Un proyecto es un proceso con un inicio y un fin claramente definidos.
Los proyectos siempre se deben controlar para que tengan éxito. El método tiene en cuenta los factores de cambio del entorno del proyecto, susceptibles de influir en su éxito.
Los procesos PRINCE2 está divido en ocho procesos definidos por las claves de entrada y de salida, los objetivos esperados y las actividades que se deben realizar. Cada proceso se designa mediante una abreviatura:
(SU) - Elaborar el proyecto (EP)
(IP) - Inicializar el proyecto (IP)
(DP) - Dirigir el proyecto (DP)
(CS) - Controlar una secuencia (CS)
(MP) - Gestionar la entrega de productos (EP)
(SB) - Gestionar los límites de secuencia (LS)
(CP) - Cerrar un proyecto (CP)
(PL) - Planificar (PL)
Podemos agrupar estas etapas en cuatro fases:
Arranque (SU)
Iniciación (IP)
Ejecución (CS, MP, SB)
Cierre (CP)
Los procesos (DP) se aplican a lo largo de todo el proyecto.
Fuente: http://es.wikipedia.org/wiki/PRINCE2
5. ISO 20000-2011 La norma ISO 20000 tiene como objetivo la certificación de empresas. No obstante, también existe una certificación para las personas: Auditor certificado ISO 20000. En el origen de la norma ISO 20000, se encuentra la norma británica BS 15000, que se basa en las buenas prácticas ITIL. La versión ISO 20000-2011 es la nueva versión publicada. La norma ISO 20000 se presenta en dos volúmenes.
El primer volumen contiene los requerimientos de la norma, es decir, aquello que se debe demostrar en el proceso de la auditoría de certificación. El segundo contiene las mejores prácticas y las recomendaciones. De manera habitual, se dice que el primero contiene los «Shall» o «What» (aquello que es obligatorio) y el segundo los «Should» o «How» (aquello que sería conveniente hacer o cómo hacerlo). ISO 20000 se basa, en parte, en los principios de ITIL V2 (origen de la BS 15000) e igualmente en algunos principios y procesos de la norma ISO 9001. ISO 20000, a diferencia de ISO 9001, que se aplica a todos los sectores de actividad, está destinado únicamente a la gestión de los organismos informáticos en el seno de las empresas. Se puede facilitar la puesta en práctica de una certificación ISO 20000 si la empresa ya está llevando a cabo un proceso de calidad (ha adquirido la certificación ISO 9001 o simplemente tiene establecido un enfoque a procesos), o si ya se ha realizado un enfoque ITIL.
Los procesos de gestión de los servicios ISO 20000-11 hace referencia a 13 procesos.
ISO 20000-2011 Estos 13 procesos se describen en los artículos 3 a 10 de la norma. El artículo 3 trata de los requerimientos de un sistema de gestión.
El artículo 3.1 trata de la responsabilidad de la Dirección.
El artículo 3.2 trata de los requerimientos relativos a la documentación.
El artículo 3.3 trata de la competencia, sensibilización y formación del personal.
El artículo 4 trata de la planificación y de la puesta en marcha de la gestión de los servicios. La siguiente figura ilustra los procesos y relaciones entre los procesos presentes en los artículos 4 a 10 de la norma.
Rueda de Deming aplicada a los procesos de gestión de servicios
El artículo 4.1 trata de la planificación de la gestión de los servicios (Planificar).
El artículo 4.2 trata de la puesta en marcha de la gestión y suministro de los servicios (Hacer).
El artículo 4.3 trata del seguimiento, medición y revisión (Verificar).
El artículo 4.4 trata de la mejora continua (Actuar).
El artículo 5 trata de la planificación y puesta en marcha de las modificaciones o creación de servicio.
El artículo 6 trata de los procesos de suministro de los servicios.
El artículo 6.1 trata de la gestión de los niveles de servicio.
El artículo 6.2 trata de los informes de servicio.
El artículo 6.3 trata de la gestión de la continuidad y disponibilidad de los servicios.
El artículo 6.4 trata de la dotación presupuestaria y contabilidad de los servicios informáticos.
El artículo 6.5 trata de la gestión de la capacidad.
El artículo 6.6 trata de la gestión de la seguridad de la información.
El artículo 7 trata de los procesos de gestión de las relaciones.
El artículo 7.1 trata de las generalidades.
El artículo 7.2 trata de la gestión de las relaciones comerciales.
El artículo 7.3 trata de la gestión de los proveedores.
El artículo 8 trata de los procesos de resolución de problemas.
El artículo 8.1 trata del contexto.
El artículo 8.2 trata de la gestión de incidencias.
El artículo 8.3 trata de la gestión de problemas.
El artículo 9 trata de los procesos de control.
El artículo 9.1 trata de la gestión de las configuraciones.
El artículo 9.2 trata de la gestión de los cambios.
El artículo 10 trata de los procesos de la puesta en producción.
El artículo 10.1 trata de los procesos de gestión de la puesta en producción.
EL CICLO DE VIDA DE LA GESTION DE SERVICIOS Enfoque En este capítulo vamos a ver cómo se representa la estructura del ciclo de vida de la gestión de los servicios en ITIL V3 y cuáles son las relaciones entre las diferentes fases del ciclo y los diferentes procesos y funciones.
El contexto del ciclo de vida de la gestión de los servicios es un contexto organizativo. Es importante entender correctamente el objetivo del ciclo de vida de la gestión de los servicios antes de poner en práctica una estrategia ITIL. De su comprensión dependerá, en parte, el éxito de su proyecto ITIL. Este ciclo de vida de la gestión de los servicios, desglosado en fases, es permanente y continuo. Se considera que, para el proceso de mejora continua de los servicios (CSI), es necesario ejecutar un ciclo de gestión al menos una vez cada año.
En cada fase del ciclo de vida de la gestión de los servicios, se efectúan los controles y se analizan los retornos de la experiencia. Las mejoras se pondrán en práctica en el curso del ciclo siguiente.
Enfoque del ciclo de vida de la gestión de los servicios El ciclo de vida de la gestión de los servicios se presenta a partir de la estrategia de servicios (Service Strategy - SS), que se encuentra en el centro del diagrama. Esto es
lógico, ya que los otros procesos se ponen en práctica a partir de las decisiones tomadas y estrategias definidas por la Dirección informática o la Dirección General de la empresa. Los otros tres grupos de procesos se representan alrededor de la estrategia de servicios. Se comienza por el diseño de servicios (Service Design - SD), seguido por la transición de servicios (Service Transition - ST), para terminar con la explotación de los servicios (Service Operation - SO). Finalmente, el conjunto de estos procesos se rodea por los procesos de mejora continua de servicios (Continual Service Improvement - CSI).
Las fases del ciclo de vida El ciclo de vida de la gestión de los servicios está formado por las siguientes fases: Definir la estrategia de gestión de servicios (Service Strategy - SS). Diseñar los servicios con el fin de soportar la estrategia (Service Design - SD). Poner en práctica los servicios con el fin de satisfacer las exigencias del diseño (Service Transition - ST). Soportar los servicios de gestión de las actividades operativas (Service Operation SO).
Fases del ciclo de vida de la gestión de los servicios La interacción entre las fases se gestiona mediante el enfoque de mejora continua de servicios (Continual Service Improvement - CSI), que permite medir y mejorar el nivel de madurez de los procesos y, por lo tanto, de los servicios. Después de la realización de todas las fases del ciclo de vida de la gestión del servicio, termina un periodo de servicio y comienza otro.
En la fase inicial de estrategia de los servicios (Service Strategy - SS), el proveedor de los servicios informáticos establece una estrategia: Gestionando las exigencias del negocio (proceso de gestión de peticiones). Traduciéndola en una estrategia de entrega de servicios (estrategia de servicios). Validando la sostenibilidad de los costes (proceso de gestión financiera). Introduciendo el servicio en el porfolio de servicios (proceso de gestión del porfolio de servicios). En este estado, la organización TI debe utilizar los recursos, lo que tiene un coste, en los proyectos de consultoría en un nivel estratégico. Durante este periodo, esta estructura no proporciona valor a la empresa. Durante la segunda fase, fase de diseño de servicios (Service Design - SD), cuando ya se ha definido una estrategia, la organización TI comienza a diseñar el servicio: Estableciendo las exigencias de «nivel de servicio» de este servicio (proceso de gestión de nivel de servicio). Estudiando la disponibilidad (proceso de gestión de la disponibilidad). La capacidad necesaria (proceso de gestión de la capacidad). Seleccionando los proveedores que van a soportar el servicio (proceso de gestión de proveedores). Definiendo las disposiciones adecuadas para la continuidad de los servicios (proceso de gestión de la continuidad de servicios informáticos). Validando y estableciendo las exigencias de seguridad (proceso de gestión de seguridad de la información). Añadiendo el servicio al catálogo de servicios (proceso de gestión del catálogo de servicios). Durante la tercera fase, fase de transición de servicios (Service Transition - ST), el servicio está preparado para ponerse en marcha en el entorno real. El proveedor de servicios: Define el plan de transición (planificación y soporte en la transición). Evalúa, aprueba, pone en marcha y planifica los cambios (proceso de gestión de cambios). Antes de la puesta en marcha de estos cambios, el servicio se prueba (proceso de validación y prueba de servicios) en un entorno lo más parecido posible al futuro entorno de explotación, pero nunca en el propio entorno de explotación. Si la prueba tiene éxito, el servicio se documenta (proceso de gestión del conocimiento) y sus componentes se añaden a la base de datos de los activos y configuraciones (proceso de gestión de activos de servicio y configuraciones). La última actividad consiste en poner el servicio en producción en un entorno real (proceso de gestión de despliegues y entradas en producción). Para terminar, la última etapa consiste en la satisfacción del cliente, que se mide antes de cerrar el cambio. Durante la cuarta fase, fase de explotación de servicios (Service Operation - SO), el servicio se gestiona y soporta para atender los niveles de servicios acordados:
Gestionando las peticiones de soporte de los usuarios (función de centro de servicios y procesos de tratamiento de consultas). Haciendo seguimiento de los eventos y alertas del servicio (proceso de gestión de los eventos). Restaurando el servicio después de un problema (proceso de gestión de incidencias). Buscado las causas de las incidencias y reduciendo la duración de estas (proceso de gestión de problemas). Gestionando de manera segura el uso del servicio (proceso de gestión del acceso). Manteniendo el software (función de gestión de aplicaciones). Ejecutando las actividades diarias (función de gestión de operaciones). Soportando la infraestructura (función de gestión técnica). La fase de mejora continua de los servicios (Continual Service Improvement) se realiza durante todas las fases del ciclo de vida de la gestión del servicio. Está encargada de medir el servicio y los procesos (medición de los servicios) y de documentar los resultados (realización de informes de los servicios) con el objetivo de mejorar la calidad del servicio y la madurez de los procesos (mejora de los servicios). Estas mejoras se pondrán en práctica durante el próximo periodo del ciclo de vida de la gestión del servicio, comenzando de nuevo por la estrategia de servicios, seguida del diseño de servicios y la transición de servicios. La fase de explotación de servicios continúa gestionando las operaciones durante todos los periodos del servicio.
Los niveles decisionales En la toma de decisiones en el seno de una organización, se definen tres niveles decisionales en la versión 3 de ITIL: Nivel estratégico: decisiones a largo plazo, que normalmente se toman para atender ciertas metas y objetivos. Una decisión incorrecta en este nivel tiene a menudo consecuencias importantes o puede suponer un coste muy elevado. Estas decisiones se toman a nivel de la Dirección informática o la Dirección General de la empresa. Nivel táctico: decisiones a medio plazo, a menudo destinadas a ser proactivas y a un nivel intermedio entre las decisiones estratégicas y operativas. Nivel operativo: decisiones a corto plazo, a menudo decisiones reactivas, que tendrán un impacto sobre las operaciones diarias.
Los niveles decisionales Estos niveles se utilizan para identificar las decisiones tomadas. También permiten identificar las líneas de comunicación entre los diferentes niveles. El nivel de comunicación estratégico generalmente es responsabilidad de la Dirección informática de más alto nivel, o de la Dirección General de la empresa. Esto depende del tamaño y la estructura de la organización.
La fase de diseño de los servicios se sitúa entre el nivel táctico y el estratégico. La fase de transición de servicios se sitúa entre el nivel táctico y el operativo. La fase de mejora continua de los servicios es transversal a todos los niveles decisionales.
Rol y funciones Hemos explicado que la estructura de ITIL 2011 se basa en los procesos. Sin embargo, para entender correctamente esta estructura hay que definir la noción de proceso, rol y función. Ya hemos visto lo que es un proceso: Un proceso está formado por una o varias actividades relacionadas. Un proceso incluye uno o varios elementos de entrada y uno o varios elementos de salida. Una función es una unidad, equipo o grupo de personas, junto con los recursos y herramientas funcionales específicas, para ejecutar un determinado tipo de trabajo y que serán responsables de resultados concretos. Por ejemplo, el centro de servicios. Es imprescindible que los roles y responsabilidades se definan claramente para todos los procesos y actividades de la organización de los TI.
Un rol es un conjunto de responsabilidades, actividades y asignadas a las personas de la organización (un grupo o equipo).
autoridades
específicas
Un rol se define en un proceso o función. Una misma persona o equipo puede tener varios roles. La noción de rol se usa en la implementación del modelo RACI.
Atención con no mezclar la noción de rol con un título o el nombre de un puesto.
Los procesos y funciones de ITIL 2011 La imagen siguiente ofrece una visión del conjunto de los procesos (representados por medio de rectángulos) y funciones (representadas por medio de óvalos) presentes en ITIL 2011.
Vista global de los procesos y funciones ITIL 2011 Cada fase del ciclo de vida de la gestión de servicios está compuesta por un determinado número de procesos y funciones. Fase de mejora continua de los servicios La fase de mejora continua de servicios incluye los modelos y procesos para la mejora continua de servicios, principalmente el proceso de mejora en siete etapas, el Ciclo de Deming y elmodelo CSI. Fase estratégica de servicios La estrategia de servicios comienza con el proceso de creación de la estrategia de servicios genéricos (creación de la estrategia) y continúa con los procesos de
gestión de la relación comercial, del porfolio de servicios, de los servicios financieros y de la demanda. Fase de diseño de servicios El diseño de los servicios se aplica a los procesos de:
Gestión del catálogo de servicios
Gestión de los niveles de servicio
Gestión de la disponibilidad
Gestión de la capacidad
Gestión de la continuidad de servicios informáticos
Gestión de la seguridad informática
Gestión de proveedores
Fase de transición de servicios La transición de los servicios se aplica a los procesos de:
Gestión de cambios
Gestión de activos de servicio y configuraciones
Gestión de despliegues y entradas en producción
Validación y prueba de servicios
Evaluación
Gestión del conocimiento
Fase de explotación de servicios La explotación de los servicios se aplica a los procesos de:
Gestión de eventos
Ejecución de consultas
Gestión de incidencias
Gestión de problemas
Gestión de la evaluación También explica las cuatro funciones a través de ITIL: centro de servicios, gestión técnica, gestión de operaciones informáticas y gestión de aplicaciones.
Campo de aplicación de los procesos ITIL 2011
LOS PROCESOS DE LA ESTRATEGIA DE SERVICIOS La fase de la estrategia de servicios 1. Los niveles decisionales Como hemos visto en el capítulo de presentación de la norma, ITIL está compuesto por procesos estratégicos, tácticos y operativos.
Los niveles decisionales de la estrategia de servicios Los procesos de la estrategia de servicios se sitúan en la parte superior de la organización IT. El primer objetivo de la estrategia de servicios es definir la estrategia de la organización en términos de servicios.
2. Los procesos de la estrategia de servicios
Generación de la estrategia de servicios
Gestión financiera
Gestión de la relación comercial
Gestión de la demanda
Gestión del porfolio de servicios
Generación de la estrategia 1. Enfoque En esta sección vamos a ver cómo se definen y ponen en práctica las estrategias de servicios.
2. ¿Por qué una estrategia de servicios? La estrategia consiste en tomar una decisión sobre cómo aportar valor a un cliente, en función de nuestras capacidades y aptitudes (la nuestra y la de nuestros proveedores).
Esto resulta complicado porque la negociación es compleja e incierta. Se basa en probabilidades; existe la necesidad de discernir las tendencias y los modos, en constante interacción.
3. Objetivos del proceso Los objetivos de la estrategia de servicios son los siguientes:
Permitir la comprensión de la estrategia que se pone en marcha.
Proporcionar una definición clara de los servicios que usa el cliente.
Tener la capacidad de definir cómo se crea y entrega el valor del servicio.
Identificar las oportunidades de servicios y cómo explotarlos.
Proponer un modelo de prestación de servicios claro, que establezca cómo se entregan y financian los servicios, a quién se entregan y con qué propósito.
Tener las capacidades organizativas necesarias para la ejecución de la estrategia.
Documentar y coordinar el uso de los activos de servicio para ofrecer un servicio y cómo optimizar su rendimiento.
Proporcionar los procesos que definen la estrategia de la organización, los servicios que permitirán alcanzar la estrategia, qué nivel de inversión será necesario, a qué nivel de peticiones y los medios de asegurar una relación de trabajo entre el cliente y el proveedor de servicios.
Para esto, la dirección de la empresa dará la dirección, definirá las políticas, identificará los proyectos y asignará los recursos. La estrategia también definirá la priorización de las inversiones. Para hacer frente a la evolución de la empresa y de su entorno, será necesario revisar esta estrategia al menos una vez al año.
4. Definiciones Aptitud: capacidad de una organización, persona, proceso, aplicación, elemento de configuración o servicio TI para realizar una actividad. Recursos: término genérico que incluye la infraestructura, personas, medios financieros o todo aquello que ayude a liberar el servicio.
5. Perímetro La gestión de la estrategia es responsable de proporcionar varios entregables:
Los requerimientos para el diseño de servicios.
Los requerimientos para la transición de servicios.
Los requerimientos para la explotación de servicios.
6. Conceptos básicos a. Entender los valores del servicio para los clientes Para entender las necesidades de los clientes, es necesario entender la manera de proporcionar un valor añadido a estos y cómo diferenciarse de otros proveedores de la competencia. La estrategia de servicio se basa en:
Un mejor entendimiento de las necesidades de los clientes.
Las oportunidades en términos de servicio: nuevos servicios, servicios mejorados, servicios obsoletos.
Para estar en disposición de responder correctamente a las necesidades de los clientes y hacerlo en plazos aceptables, la estrategia de servicios debe aplicar un «porfolio de servicios».
b. Definición del valor añadido El valor añadido de un servicio se debe demostrar centrándose en la utilidad y la garantía. Es este valor añadido el que permitirá a la organización TI y al cliente distinguir el servicio frente a la competencia.
Utilidad del servicio La utilidad del servicio se demuestra por la capacidad del servicio de proporcionar resultados en consonancia con los objetivos del cliente. Esto demuestra que el servicio se adapta a las necesidades. Esto se percibe por parte del cliente como un valor añadido, que ofrecerá mejores rendimientos. Podemos poner como ejemplo un banco que utiliza un servicio para conceder préstamos a sus clientes. Si la organización TI le ofrece un servicio que permite la aprobación de un préstamo en 24 horas, mientras que otros bancos requieren 48 horas para hacerlo, es evidente que esta diferencia en el tiempo de tratamiento de una petición es una utilidad del servicio, que permitirá proporcionar un valor añadido al cliente.
Garantía del servicio La garantía del servicio proporciona al cliente un compromiso para prestar un servicio que respete y garantice sus requerimientos de servicio. Esto demuestra que el servicio se adapta al uso. La garantía del servicio se puede expresar asegurando que se respeten los siguientes puntos:
Nivel de disponibilidad conforme a lo acordado.
Capacidad conforme a lo acordado.
Nivel de seguridad conforme a lo acordado.
Nivel de continuidad conforme a lo acordado (si se ha aplicado el proceso de gestión de la continuidad para este servicio).
La organización TI debe ser capaz de proporcionar el servicio de manera continua, con un nivel de calidad estable y permanente.
c. Actividades principales
Las cuatro actividades principales
Las cuatro actividades principales Las cuatro actividades principales del proceso de generación de servicios son:
Definir el mercado: se trata de entender las necesidades de los clientes y las oportunidades en términos de servicios.
Desarrollar las ofertas: a partir del análisis hecho en la etapa anterior, se definen cuáles son los servicios que serán ofrecidos por la organización TI.
Desarrollar los activos estratégicos: como hemos visto en la sección de definición del valor añadido, conviene identificar los medios que se deben aplicar para proporcionar un valor añadido a los clientes, a través de los servicios ofrecidos por la organización TI.
Preparar la ejecución: el objetivo es definir el contenido del porfolio de servicios y del catálogo de servicios, así como definir cuáles serán los requerimientos para el diseño, la transición y la explotación de servicios.
Estas actividades se ven limitadas por factores internos (organización, competencias de los empleados, elecciones estratégicas de la empresa...) y por factores externos (evolución del mercado, estado de la competencia, evolución tecnológica, requerimientos reglamentarios...).
7. Roles Los principales roles son los siguientes:
Los miembros de la Dirección de la empresa.
El responsable de la generación de la estrategia.
El propietario del proceso.
8. Descripción del proceso
El proceso de Generación de la estrategia
9. Los entregables de la estrategia de servicios La estrategia debe proporcionar varios entregables:
El porfolio de servicios.
Los requerimientos para el diseño de servicios.
Los requerimientos para la transición de servicios.
Los requerimientos para la explotación de servicios.
Los requerimientos para la mejora continua.
Las otras fases del ciclo de vida de los servicios pondrán en marcha soluciones que garanticen los requerimientos en este proceso.
Gestión financiera
1. Enfoque En esta sección vamos a ver cómo se pone en práctica la gestión financiera. Este proceso es importante para el correcto funcionamiento de la organización TI, ya que permite conocer exactamente los costes del conjunto de servicios proporcionados al cliente y determinar los modos de facturación. Este proceso también permite asegurar que se aplican los procedimientos y las prácticas definidas por la gestión financiera para el conjunto de equipos de la organización TI. Fundamentalmente, veremos su importancia en la forma de determinar los costes para cada servicio.
2. ¿Por qué una gestión financiera? Los costes de los servicios informáticos están en continuo aumento para responder a las necesidades, en constante evolución, de los clientes y las empresas. En ausencia de una gestión financiera, es difícil conocer el verdadero coste de los servicios informáticos. Esto explica que frecuentemente haya insatisfacción por parte de los clientes o de las empresas, respecto a la relación calidad/precio de los servicios que se les proponen. La aplicación de un proceso de gestión financiera permite identificar de manera precisa los costes de los servicios, lo que implica que la contabilidad no resulte simple, aunque esta sea precisa.
La versión 3 de ITIL introduce el concepto de Valorización del servicio. ¿Qué es la valorización? Podemos definir este término de las siguientes maneras: «Reconocimiento del valor de cualquier cosa para sacar de ella más recursos». Desde un punto de vista económico: «Aumento del valor de mercado de un producto o servicio por medios legales o una acción voluntaria». En el caso de ITIL se trata de valorizar, en términos financieros, las inversiones realizadas por la empresa y la organización TI. Esta valorización se basa en el valor acordado de los servicios ofrecidos por la organización TI. La valorización del servicio es una media del coste total de entrega de un servicio informático y del valor total para la empresa de ese servicio. La estimación del valor del servicio se utiliza para permitir a la empresa y al proveedor del servicio informático llegar a un acuerdo sobre el valor de este. La valorización del servicio se basa en factores clave:
La prestación de valor.
El valor potencial del servicio.
La prestación de valor determina la base de referencia mínima del coste para proporcionar el servicio. Es decir: «¿cuál es el coste total de entrega de este servicio?» Desde el comienzo de este libro, hemos dicho que el objetivo era proporcionar un valor añadido al servicio prestado. El valor potencial del servicio es la componente de este valor añadido, basado en la percepción de valor que tiene el cliente. Este valor se calcula en función de la utilidad y la garantía.
a. Otros conceptos La modelización de la demanda es la identificación de los costes de uso de un servicio y la previsión de las implicaciones financieras de la demanda de servicios en el futuro. Se identifican las necesidades de financiación, las variaciones y las causas o razones de esta variación. La demanda del servicio se puede gestionar a través de la tarificación y de los ajustes de bonus susceptibles de influir en la demanda del cliente. La gestión del porfolio de servicios utiliza los datos proporcionados por la gestión financiera, para comparar las unidades organizativas entre ellas o en relación con los proveedores externos. Esto permite decidir cómo y dónde se obtiene un servicio.
3. Objetivos del proceso El objetivo principal del proceso de gestión financiera para un servicio interno es asegurar una gestión económica de los recursos TI, utilizados para proporcionar los servicios de las TI. Para obtener un resultado satisfactorio, es necesario poner en práctica tres actividades, entre las cuales una es opcional:
Presupuestación (obligatoria).
Contabilidad de las TI (obligatoria).
Imputación (opcional).
Para una organización TI, la gestión financiera también permite poder justificar los gastos informáticos y establecer la relación con los servicios suministrados. Esto también permite participar en las decisiones de gestión en términos de inversión informática. Para esto, la gestión financiera necesita tener información detallada de los cambios.
4. Definición Presupuestación (Budgeting): es un proceso de previsión y control de los gastos informáticos. Contabilidad (Accounting): es el proceso habitual que permite conocer y verificar los costes por cliente, servicio o actividad. Imputación (Charging): es el proceso que permite facturar los costes de un servicio a un cliente. También se conoce como facturación.
5. Perímetro La gestión financiera es responsable de:
Prever la financiación.
Establecer un plan operativo.
Realizar el análisis de costes.
Definir las políticas de facturación.
La gestión financiera cubre la totalidad de los costes de la organización TI necesarios para poner en marcha los servicios que ofrece a sus clientes.
6. Roles Los roles principales son:
Propietario del proceso
Responsable de la gestión financiera
Responsable de la relación comercial
Responsable de los niveles de servicios
Responsable de la capacidad
Responsable de la gestión de configuraciones
7. Indicadores Se pueden aplicar varios indicadores para elaborar un cuadro de mando. Este cuadro de mando se deberá proporcionar a la Dirección:
Importe de los gastos de las TI durante el ejercicio
Importe de las facturas
Importe de las ganancias
Perspectivas de coste
Perspectivas de ganancias
Inversiones futuras...
En función de los modos de puesta en marcha, será el cliente o la actividad quien proporcione estos indicadores. Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de Gestión financiera
9. Conceptos básicos a. El ciclo de vida de la gestión financiera
El ciclo de vida de la gestión financiera
b. Las relaciones con los otros procesos La gestión de activos y configuraciones La gestión financiera necesita información de los activos de la organización TI. Esta información está disponible y actualizada continuamente por la gestión de activos y configuraciones (gestión de los CI, su estado, coste y las relaciones entre estos activos).
La gestión de la demanda La gestión de la demanda es un punto de entrada para la gestión financiera, ya que permite conocer los costes de la puesta en marcha de un servicio.
La gestión de la relación comercial La gestión de la relación comercial necesita la información financiera relativa a los costes de las soluciones e inversiones necesarias, principalmente en términos de activos de servicios. Este proceso también tendrá que proporcionar información a la gestión financiera.
La gestión del porfolio de servicios La gestión del porfolio de servicios necesita información de la gestión financiera para comparar los costes de las entidades organizativas entre ellas o con los proveedores externos, con objeto de decidir cómo se proporcionarán los servicios.
La gestión de la capacidad La información de costes es imprescindible para evaluar los costes de la gestión de la capacidad. La información conseguida para determinar los costes también será útil para las diferentes evaluaciones de recursos e inversiones.
La gestión de los niveles de servicios El SLR y después el SLA definen las expectativas del cliente. El coste del servicio puede tener un impacto importante en la forma y alcance de los servicios ofrecidos por la organización TI. La gestión financiera trabaja en estrecha colaboración con la gestión de los niveles de servicio, para definir los modos de facturación que se utilizarán para el cliente.
¡Atención! No hay que olvidar que, si bien es necesario tener en cuenta los costes relacionados directamente con la producción del servicio, también hay que tener en cuenta los diferentes costes generales necesarios para el funcionamiento de la organización TI.
c. Planificación de la gestión financiera La puesta en marcha de la gestión financiera se basa en tres subprocesos: la presupuestación, la contabilidad y la facturación. La puesta en marcha de estos tres procesos se puede hacer por etapas. Este debe ser un proyecto de empresa y formar parte del proyecto de implantación de la estrategia ITIL. Será necesario establecer un plan de aplicación, definir las políticas de facturación e identificar los costes y los beneficios esperados.
Una vez más, es mejor ser modestos y comenzar por un perímetro restringido para validar las opciones tomadas, antes de hacer un despliegue generalizado.
Poner en marcha la gestión financiera implica un fuerte compromiso de la dirección de la empresa en el proyecto.
d. La presupuestación El objetivo de la presupuestación es asegurar la concordancia entre el presupuesto provisional y el coste real de servicios. La creación del presupuesto permite asegurar que la financiación prevista es suficiente para proporcionar los servicios. El presupuesto se hace a partir de las previsiones de beneficios y los gastos necesarios para proporcionar los servicios. Se establece anualmente. Los gastos necesarios y planificados son los siguientes:
Compra de hardware
Compra de software
Contratos de mantenimiento (software y hardware)
Recursos humanos
Instalaciones
Servicios externos
Servicios internos
Todos los demás costes relacionados con la prestación del servicio
La presupuestación permite:
Prever la financiación necesaria para gestionar la organización TI durante un periodo dado.
Tener la seguridad de que los ingresos estarán disponibles para soportar los gastos previstos.
Asegurar que los gastos reales se mantienen conforme a las previsiones.
Para ser eficaz, la presupuestación implica una revisión periódica con objeto de tener en cuenta los cambios y controlar la coherencia entre el presupuesto y lo realizado.
e. La contabilidad Es el proceso contable habitual el que permite conocer y verificar los costes por cliente, servicio o actividad.
La organización TI se puede ver como un centro de coste o, por el contrario, como un centro de beneficios. El hecho de poner en marcha ITIL facilita la transición de la contabilidad al «centro de beneficio» de la gestión de la organización TI. Cuando es necesario tomar decisiones de inversión o renovación, el hecho de disponer de una contabilidad de los servicios informáticos puede ayudar a tomar una decisión. La contabilidad permite:
Identificar los coses en función de su clasificación: costes de inversión o de funcionamiento.
Contabilizar los gastos para el suministro del servicio.
Evaluar el coste de los cambios.
Calcular el coste del suministro de los servicios.
La contabilidad requiere competencias especiales y un conocimiento perfecto de las reglas de contabilidad española, incluidas contabilidades extranjeras para algunas empresas. Por lo tanto, es necesario tener recursos capaces de controlar estas normas.
f. La categorización de los costes La contabilidad debe diferenciar la categorización de los costes:
Los costes de inmovilización. Por ejemplo: adquisición de un servidor.
Los costes de explotación. Por ejemplo: contrato de mantenimiento.
g. La facturación Es el proceso que permite facturar los costes de un servicio a un cliente, ya sea interno o externo. Es habitual que la facturación se concrete en una factura, correspondiente a una fracción de la cantidad de la facturación anual, por ejemplo 1/12 cada mes. Sin embargo, la facturación se puede basar en varios modelos:
Precio de coste
Coste máximo
Tarifa interna vigente
Tarifa del mercado
Precio fijo negociado con el cliente
h. La imputación La imputación es opcional en el caso del suministro de servicios internos; sin embargo es preferible ponerla en marcha desde el comienzo de la gestión financiera.
El proceso de gestión de los niveles de servicio se debe poner en marcha al mismo tiempo que la gestión financiera si se quiere obtener un reparto justo y simple de los costes. En este marco, es necesario distinguir varias opciones que permitirán definir las reglas de imputación.
Modelos de costes Es posible definir el cálculo de los costes siguiendo tres modelos:
Coste por cliente; en este caso se tiene en cuenta el conjunto de costes de los diferentes servicios ofrecidos al cliente.
Coste por servicio; en este caso se tienen en cuenta los diferentes costes del servicio ofrecido.
Coste por localización; en este caso se tienen en cuenta los diferentes costes relacionados con el suministro del servicio, en una ubicación particular.
Tipos de coste Es posible repartir los costes en función de su tipo:
Hardware (adquisición, ubicación)
Software (adquisición, ubicación, modo ASP)
Mantenimiento (software, hardware)
Personal (salarios, formación)
Inmuebles
Servicios externos
Transferencia de cargas
Categorización de los costes Es preciso hacerse cargo de la categorización de los costes y diferenciar:
Las inmovilizaciones o la explotación. Por ejemplo: adquisición de un servidor (inmovilización), frente a los contratos de mantenimiento (explotación).
Directos o indirectos.
Los costes directos corresponden a los costes directamente imputables a un cliente o a un servicio.
Fijos o variables. Por ejemplo: contrato de mantenimiento, frente a la capacidad de almacenamiento en disco.
i. El modelo de costes para un servicio El siguiente esquema muestra el reparto de los costes para un servicio.
Modelo de costes para un servicio Identificamos el conjunto de elementos que forma parte de los costes de un servicio. A partir de estos elementos, es posible definir los costes directos e indirectos. Los costes directos son claramente identificables y directamente imputables a un servicio. En la imagen, el servicio entregado al cliente es una prestación de tipo centro de servicios, para una parte del hardware, software y recursos humanos. Los costes indirectos son los costes que no son directamente imputables a un servicio. Por ejemplo, las instalaciones no son directamente imputables a un servicio, pero, si se define un coste asignado a cada empleado, entonces es posible asig-nar un coste indirecto
para cada servicio, en función del número de empleados. En este caso se habla de costes indirectos absorbidos. En el ejemplo, vamos a poder asignar un coste al centro de servicios para las instalaciones que ocupa. Los otros costes son no imputables directamente. En este caso, se habla de costes indirectos no absorbidos. La recuperación de estos costes se puede realizar por medio del aumento de un determinado porcentaje a todos los costes. Estos son, por ejemplo, los costes de energía, conserjería de los locales. El acumulado de los costes directos e indirectos absorbidos va a permitir obtener los costes absorbidos. El hecho de añadir el incremento generado por los costes indirectos no absorbidos permitirá obtener un coste real del centro de servicios. Se deberá realizar el mismo cálculo para cada servicio.
Gestión del porfolio de servicios 1. Enfoque En esta sección vamos a ver cómo se gestiona el porfolio de servicios. Veremos que este proceso es importante para la gestión de los servicios proporcionados por la organización TI.
2. ¿Por qué una gestión del porfolio de servicios? La organización TI debe conocer constantemente los servicios que ofrece a sus clientes, pero también aquellos que son susceptibles de ser ofrecidos o que se han eliminado. Este proceso debe ayudar a responder a las siguientes preguntas estratégicas:
¿Por qué un cliente compraría este servicio?
¿Por qué nos compraría a nosotros?
¿Cuál es el modelo de precios o facturación?
¿Cuáles son nuestras fuerzas, debilidades, prioridades y riesgos?
¿Cuáles son nuestros recursos y nuestra capacidad para ponerlos en marcha?
3. Objetivos del proceso Para responder a las preguntas anteriores, los objetivos del proceso son los siguientes:
Proporcionar un proceso y los mecanismos para permitir a la organización estudiar y decidir cuáles son los servicios que se tienen que proporcionar, teniendo en cuenta el nivel potencial de retorno y los riesgos asumibles.
Mantener un porfolio de servicios actualizado, basado en las necesidades de negocio de cada servicio y los beneficios esperados por el cliente.
Proporcionar un mecanismo a la organización para evaluar cómo estos servicios le permitirán responder a sus estrategias y a los cambios de su entorno interno o externo.
Controlar qué servicios se ofertan, en qué condiciones y con qué nivel de inversión.
Seguir las inversiones en servicios a lo largo de su ciclo de vida, permitiendo de esta manera a la organización evaluar su estrategia, así como su capacidad de aplicación.
Analizar los servicios para identificar aquellos que ya no son viables con objeto de eliminarlos del porfolio de servicios.
4. Definición Porfolio de servicios: expresión de la estrategia de los servicios de la organización TI. Contienen el conjunto de servicios (pipeline, catálogo de servicios y servicios eliminados). Catálogo de servicios: es un subconjunto del porfolio de servicios. Contiene todos los servicios operativos.
5. Perímetro La gestión del porfolio de servicios es responsable de:
La identificación de todos los servicios.
Control de las inversiones en servicios.
Maximizar el valor de los servicios.
La construcción del paquete de servicios (SDP - Service Design Package).
6. Roles Los roles principales son los siguientes:
Responsable del porfolio de servicios.
Responsable del catálogo de servicios.
Responsable de la relación comercial.
Propietario del servicio.
7. Indicadores Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:
Número global de servicios en el pipeline.
Número global de servicios en el catálogo de servicios.
Número global de servicios retirados del porfolio de servicios.
Número de servicios que se han movido en un periodo: del pipeline al catálogo de servicios. del catálogo de servicios a los servicios retirados.
Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se establezca.
8. Descripción del proceso
El proceso de gestión del porfolio de servicios
9. Conceptos básicos a. El ciclo de vida de un servicio
El ciclo de vida de un servicio
b. El pipeline de servicios El pipeline de servicios es un subconjunto del porfolio de servicios. El pipeline de servicios contiene todos los servicios en fase de desarrollo. Este servicio puede estar destinado a un cliente en particular o responder a un mercado potencial.
c. El catálogo de servicios El catálogo de servicios debe contener todos los detalles de todos los servicios operativos:
Sus características (vienen del porfolio de servicios).
Los detalles relativos a los clientes.
Sus atributos.
Su estado.
d. Servicios eliminados Este subconjunto del porfolio de servicios contiene todos los servicios eliminados. La organización TI necesita conservar los diferentes elementos relativos a los servicios eliminados. De hecho, éstos se podrían reactivar en caso de que un cliente lo solicite. Estos servicios forman parte de los activos de la empresa.
e. El porfolio de servicios y el catálogo de servicios La organización TI necesita conocer cada uno de los servicios operativos e identificar a todos los clientes de un mismo servicio. Para responder a esta necesidad, es aconsejable poner en práctica un porfolio de servicios que debe contener el catálogo de servicios. El porfolio de servicio se diseña en el diseño de los servicios, pero se produce y actualiza en la gestión del porfolio de servicios.
El porfolio de servicios debe contener un conjunto de información relativa a cada servicio:
Sus características (descripción detallada).
Su valor añadido.
Los riesgos asociados.
Su coste.
Su estado.
Las opciones de estado en el porfolio de servicios contienen, al menos:
Requerimientos: la empresa o el diseño de servicios establece un conjunto de requerimientos para un servicio nuevo o modificado.
Definido: se ha evaluado, definido y documentado el conjunto de requerimientos para el nuevo servicio y se ha producido el SLR.
Aprobado: ha finalizado y se ha autorizado el conjunto de requerimientos para el nuevo servicio.
Aceptado: los requerimientos del nuevo servicio se comunican y se le asig-nan los recursos y presupuestos.
Construido: están construidos el servicio y los componentes que forman parte de él.
Probado: están probados el servicio y los componentes que forman parte de él.
Los servicios proporcionados por los proveedores de servicios también son elementos clave del porfolio de servicios y del catálogo de servicios. La organización debe definir una política relativa a la gestión del porfolio de servicios y al catálogo de servicios. Esta política debe, en particular, definir los detalles de las responsabilidades de cada servicio. El diseño de servicios diseña el porfolio de servicios, y la estrategia de servicios lo produce y publica. Es un elemento de la estrategia de servicios. Normalmente, el porfolio de servicios se divide en secciones que contienen los servicios en función de las áreas del negocio implicadas. Lo ideal sería que la gestión del porfolio de servicios se hiciera con la colaboración de diseño, transición de servicios, explotación y mejora continua de servicios. Una vez que el servicio se transfiere a la transición de servicios, se debe incluir en el catálogo de servicios.
El proceso de gestión de cambios debe validar todos los cambios en el porfolio de servicios o en el catálogo de servicios.
f. El empaquetado de los servicios La gestión del porfolio de servicios es responsable de la construcción del empaquetado de los servicios (SDP - Service Design Package). Este empaquetado de servicios se utilizará en las fases de diseño y transición de servicios. Normalmente, un servicio está compuesto por un conjunto de componentes o servicios que, una vez ensamblados, darán lugar a un paquete de servicios. Un paquete de servicios puede contener:
Una carta que incluye una descripción del uso y la garantía.
Las especificaciones del servicio.
Los criterios de aceptación del servicio.
Los modelos que se usan en la prestación del servicio.
La arquitectura definida para entregar el servicio y las restricciones relacionadas.
Los planes de despliegue previstos.
Un paquete de servicios se puede componer de los siguientes elementos:
Un servicio básico.
Uno o varios servicios de apoyo, que proporcionarán un valor añadido.
Módulos complementarios.
Módulos de extensión del servicio.
Construcción de un paquete Para este ejemplo, podemos tomar un servicio de tipo centro de servicios. Vamos a definir un servicio básico; por ejemplo, un soporte de 09:00 a 17:00 h, de lunes a viernes. Para incluir este servicio básico en el porfolio de servicios, debemos definir e identificar todos los componentes de este servicio para determinar su coste. A este servicio básico se le podrán añadir servicios adicionales, para obtener un servicio diferenciado para cada cliente. Podemos hablar de la construcción de un servicio a partir de piezas, como se hace con las piezas de LEGO®. En función de las necesidades del cliente, vamos a añadir una o varias piezas específicas, correspondientes a dichas necesidades. Podemos definir las piezas correspondientes a una extensión del servicio:
Extensión de 07:00 a 09:00 h.
Extensión de 17:00 a 19:00 h.
Extensión para el sábado.
Extensión para el domingo...
También podemos definir las piezas complementarias:
Complemento para un idioma extranjero.
Complemento para un soporte de tipo penalización, fuera de los horarios de apertura...
Es el conjunto de todas las piezas lo que permitirá ofrecer al cliente un servicio a medida, que corresponda a sus necesidades. También será necesario definir los niveles de servicio asociados a cada uno de estos módulos y cada paquete.
Es evidente que se deberá evaluar el coste de cada una de estas piezas, para poder integrarla en un paquete antes de ofrecerlo al cliente.
Gestión de las peticiones 1. Enfoque En esta sección vamos a ver cómo se gestionan las peticiones de los clientes, en términos de peticiones de nuevos servicios. Veremos que este proceso es muy importante para la generación de la estrategia de servicios.
2. ¿Por qué una gestión de peticiones? Los clientes expresan regularmente nuevas necesidades en forma de peticiones. La dirección de la organización necesita conocer el conjunto de estas peticiones para definir su estrategia de servicio.
3. Objetivos del proceso Los principales objetivos del proceso de gestión de las peticiones son los siguientes:
Minimizar al máximo la incertidumbre de la petición del cliente.
Proporcionar datos fiables para la gestión de la capacidad, con objeto de obtener una capacidad eficiente.
4. Definición Pattern Business activity: esquema de actividad de negocio que ayuda al proveedor de servicios a entender y planificar las variaciones de actividades relacionadas con el negocio.
5. Perímetro La gestión de las peticiones es responsable de:
La identificación de las peticiones de los clientes.
La identificación de los diferentes componentes de un servicio.
6. Roles Los roles principales son los siguientes:
Responsable de las peticiones.
Responsable de la relación comercial.
Responsable de la gestión del porfolio de servicios.
Responsable de los niveles de servicios.
Propietario del proceso.
7. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de peticiones de cliente.
Número de peticiones tenidas en cuenta.
Número de peticiones planificadas a corto plazo.
Número de peticiones rechazadas.
Esta lista no es exhaustiva; convendrá definir los indicadores en función de la estructura que se establezca.
8. Descripción del proceso
El proceso de gestión de peticiones
9. Conceptos básicos Minimizar la incertidumbre de la petición La gestión de la demanda es importante para la estrategia de servicios. La organización TI necesita conocer la tendencia de evolución de las necesidades del cliente, para adaptar su oferta. La organización TI debe ser capaz de responder a las peticiones de sus clientes, cuando necesite la disponibilidad del servicio correspondiente a su petición. Para poder responder correctamente a la petición, el proceso de gestión de la capacidad requiere conocer la tendencia de evolución de los servicios. Esta tendencia de evolución puede ser de tipo capacidad, al alza o a la baja, o de tipo tecnología(integración de nuevas tecnologías o eliminación de tecnologías obsoletas). La adaptación de la capacidad tendrá un impacto en la calidad del servicio que se proporcionará. Esta medición de la evolución de la petición se debe hacer escuchando al cliente y en estrecha coordinación con él, fundamentalmente a través de la gestión de la relación comercial.
Sin embargo, en la «vida real», es necesario ser realista y no creer que esto eliminará todas las incertidumbres relacionadas con la evolución de las necesidades de las empresas.
10. Las actividades de la gestión de peticiones Las actividades de la gestión de peticiones implican al conjunto de fases del ciclo de vida.
Estrategia de servicios: identificar los servicios y expectativas en términos de resultados del cliente, así como los PBA (Patterns of Business Activity) que generan. Previsión de peticiones en función de los escenarios de uso. Soporte de la gestión del porfolio de servicios.
Diseño de servicios: confirmar los requerimientos del cliente en términos de disponibilidad y rendimiento, así como asegurar que los activos de los servicios necesarios están disponibles. Los procesos principales en esta fase son la gestión de la capacidad y la gestión de la disponibilidad. La gestión de peticiones también permitirá definir las opciones de la gestión de la continuidad de los servicios.
Transición de los servicios: implicación en las pruebas y validación del servicio, en previsión de la explotación y validación de los PBA.
Explotación de los servicios: las funciones de gestión de aplicaciones, gestión técnica y gestión de operaciones de supervisión del uso de los activos de servicio, en los diferentes niveles definidos.
11. Fuentes de información para la gestión de peticiones Las principales fuentes de información que utiliza el proceso de gestión de peticiones son:
Los Business Plan.
Los planes y previsiones de comercialización.
Las previsiones de venta.
El lanzamiento de nuevos productos.
12. Pattern of Business Activity El PBA o esquema de actividad de negocio ayuda al proveedor de servicios a entender y planificar las variaciones de actividad relacionadas con el negocio. Es necesario documentar los siguientes puntos:
Clasificación: permite indicar cuál es el tipo de cada PBA.
Atributos: frecuencia, volumen, ubicaciones y duración.
Necesidades: rendimiento, seguridad, disponibilidad y plazo.
Activos de servicios: equipos de diseño que redactarán los perfiles de usuario para cada PBA.
Los PBA pueden ser diarios, semanales, mensuales o anuales, en función de las necesidades.
LOS PROCESOS DEL DISEÑO DE SERVICIOS La fase de diseño de servicios 1. ¿Por qué un diseño de servicios? Como hemos visto en el capítulo de presentación de la norma, ITIL se compone de procesos estratégicos, tácticos y operativos.
Los niveles decisionales de gestión de los servicios La fase de diseño de servicios se encuentra entre el nivel estratégico y el táctico. Los procesos del diseño de servicios se sitúan después de los procesos de estrategia de servicios. El primer objetivo del diseño de servicios es elaborar los servicios que se explotarán a través de la transición de servicios.
2. Los procesos de diseño de servicios
Coordinación del diseño
Gestión del catálogo de servicios
Gestión de la capacidad
Gestión de la disponibilidad
Gestión de la continuidad
Gestión de la seguridad
Gestión de proveedores
3. Consideraciones sobre el diseño de los servicios a. Enfoque Las actividades de diseño de los servicios se pueden definir y analizar a partir de los cinco aspectos principales siguientes.
Enfoque del diseño de servicios
b. El diseño de las soluciones de servicios Durante la fase de diseño de los servicios (Service Design - SD), se deben realizar numerosas actividades para crear un nuevo servicio o para modificar un servicio existente. Es necesario un enfoque estructurado para desarrollar el nuevo servicio con un coste adecuado, respondiendo a las exigencias de funcionalidad y calidad previstas, y en los plazos acordados. En el diseño de una solución de servicio, se debe tener en cuenta:
El diseño de los servicios informáticos y las infraestructuras existentes.
Diseñar las soluciones de servicios para los nuevos requerimientos.
Revisar los servicios informáticos existentes.
c. El diseño de los sistemas de gestión de los servicios y las herramientas El uso de sistemas de gestión y herramientas apropiadas permite gestionar eficazmente todos los aspectos de los servicios a lo largo de su ciclo de vida.
El proceso de gestión del porfolio de servicios ocupa un lugar particular en la organización ITIL. El porfolio de los servicios se utiliza para dar soporte a todos los procesos y describir los servicios de un proveedor, en términos de valor de negocio. Define las necesidades de la empresa y valida la adecuación de la respuesta de los proveedores a estas necesidades. El porfolio de servicios permite responder a las siguientes preguntas estratégicas:
¿Por qué un cliente debería comprar estos servicios?
¿Por qué debería comprarnos estos servicios a nosotros?
¿Cuáles son las tarifas y el sistema de facturación?
¿Cuáles son mis puntos fuertes y débiles, las prioridades y los riesgos?
¿Cómo se deben asignar nuestros recursos y nuestras aptitudes?
d. El diseño de las arquitecturas técnicas El desarrollo y despliegue de una infraestructura informática, compuesta por un conjunto de aplicaciones y datos, son las actividades del diseño de las arquitecturas técnicas. Este desarrollo se realiza con el objetivo de satisfacer las necesidades de negocio actuales y futuras. También se deben tener cuenta los aspectos relativos a las personas, procesos y socios o proveedores que rodean a estos componentes técnicos.
e. El diseño de los procesos Como recordatorio, la definición de proceso es: «conjunto estructurado de actividades diseñadas para lograr un objetivo específico». Para lograr este objetivo, el proceso parte de una o varias entradas y, a través de las diferentes actividades predefinidas, las transforma en elementos de salida. Las actividades de planificación y de regulación de un proceso son las actividades de control que van a permitir la realización de un proceso de manera eficiente y eficaz. Un modelo de proceso incluye todos los roles, responsabilidades, herramientas y controles.
f. El diseño de los sistemas de medición El funcionamiento normal de un proceso obliga a que tenga mediciones y controles. Esto es válido para todos los aspectos de los procesos de diseño. Se pueden definir y utilizar cuatro tipos de métricas para medir la capacidad y el rendimiento de los procesos:
Métricas de progreso: hitos y entregables en la capacidad del proceso.
Métricas de conformidad: conformidad de requerimientos gubernamentales y reglamentarios.
un
proceso
respecto
a
los
Métricas de eficacia: la precisión y exactitud del proceso y su capacidad de entregar un resultado conforme a los términos de eficacia.
Métricas de eficiencia: la productividad del proceso, velocidad, capacidad de tratamiento y el uso de sus recursos.
4. Las 4 P Muchos diseños, planes y proyectos fracasan debido a diferentes motivos. Sin embargo, muchos de estos fracasos se deben a una ausencia de preparación de la gestión. La puesta en marcha de la gestión de servicios ITIL como una práctica hace referencia a la preparación y planificación de un uso efectivo y eficiente de las 4 P (del inglés People, Product,Process y Partners).
a. Personas En esta categoría incluimos a los usuarios, los clientes y al personal informático y responsables. Entre los elementos importantes, están la comunicación, la formación y una definición clara de los roles y responsabilidades de todas las partes implicadas.
b. Procesos En esta categoría se encuentran los procesos ITIL, que se integran en el ciclo de vida de la gestión de servicios:
Estrategia de servicios (Service Strategy - SS).
Diseño de servicios (Service Design - SD).
Transición de servicios (Service Transition - ST).
Explotación de servicios (Service Operation - SO).
Mejora continua de servicios (Continual Service Improvement - CSI).
c. Productos Hoy en día, las organizaciones informáticas disponen de un determinado número de herramientas, que se anuncian como «Compliant ITIL» o «Conforme ITIL». Por supuesto, salvo si tiene la certificación ITIL por la OC, estas herramientas no ofrecen realmente una garantía de conformidad. No hay que creer que el uso de estas herramientas va a garantizar que la organización TI trabaje conforme a ITIL. Para que la organización TI trabaje conforme a ITIL, será necesario poner en práctica todos los procesos descritos en este libro, así como una organización que permita este modo de funcionamiento.
d. Asociaciones Para suministrar servicios informáticos de calidad, la organización debe poner en marcha un proceso de gestión de proveedores (socios, fabricantes, empresas de servicios...).
5. Los enfoques para el suministro de los servicios La organización TI puede definir las estrategias para el suministro de los servicios.
No hay buena o mala estrategia, sino que todas tienen sus beneficios e inconvenientes, y todas necesitan un cierto nivel de adaptación y personalización. En realidad, existe una buena estrategia para cada empresa. Esta estrategia debe estar en relación con las capacidades de la organización TI. La estrategia de suministro de los servicios es responsabilidad del proceso de generación de la estrategia. La organización no tiene necesariamente la capacidad de ofrecer el conjunto de servicios solicitados por sus clientes. En este caso, la organización buscará una solución alternativa para responder positivamente a estos. Esta solución deberá garantizar la continuidad del suministro y la calidad de los servicios suministrados. Esta solución alternativa pasa a menudo por la externalización de una parte o del servicio completo. Lo primero de todo es que la organización TI se debe formular las siguientes preguntas:
¿Por qué externalizar?
¿Qué se debe externalizar?
¿A qué se debe parecer la relación?
¿Cómo llegar?
Las principales estrategias para el suministro de servicios se describen más adelante.
a. Internalización Esta estrategia se basa en el uso de los recursos organizativos internos de la organización TI. Estos recursos se asignan al diseño, desarrollo, transición, mantenimiento y explotación. Estos recursos garantizan el soporte de los servicios nuevos, modificados o revisados.
b. Externalización Esta estrategia se basa en el uso de los recursos de una o varias organizaciones externas para proporcionar una parte claramente definida del diseño, desarrollo, mantenimiento, explotación o soporte de un servicio. Los servicios de aplicaciones de tipo ASP pueden estar en esta categoría. La firma de un acuerdo oficial entre la organización TI y el proveedor externo se debe hacer en forma de contrato de tipo UC (Underpinning Contract).
c. Cosourcing Esta estrategia consiste en una combinación de recursos internos y externos que colaboran para suministrar en común los elementos claves del ciclo de vida.
Normalmente, esto implica el uso de varias organizaciones externas que colaboren en el diseño, desarrollo, transición, explotación y soporte de una parte de un servicio.
d. Asociación o multisourcing En esta estrategia, los acuerdos oficiales se establecen entre dos o más organizaciones para colaborar en el diseño, desarrollo, transición, explotación o soporte de los servicios informáticos. Se debe prestar una atención especial a las asociaciones estratégicas que favorezcan la competencia y las oportunidades comerciales.
Coordinación del diseño 1. Enfoque En esta sección vamos a ver cómo se gestiona el diseño de los servicio para nuevos servicios o para modificar los existentes. Para alcanzar los objetivos definidos en la fase de la estrategia, es necesaria una buena coordinación entre los diferentes procesos y actores de esta fase del ciclo de vida de los servicios. El objetivo de este proceso es asegurar que se alcanzan los objetivos de la fase de diseño de los servicios, manteniendo un único punto de coordinación y control para todas las actividades y procesos de esta fase.
2. Objetivos del proceso Los objetivos de este proceso son los siguientes:
Asegurar un diseño coherente de los servicios para responder a los requerimientos y expectativas del cliente, fundamentalmente en términos de resultados. Evidentemente, esto implica a la gestión del sistema de información, arquitectura, tecnología, procesos, información y métricas. Esto debe responder a las necesidades actuales del cliente y su evolución en un entorno cambiante.
Coordinar todas las actividades de diseño a través de los proyectos, cambios, proveedores y equipos de soporte, gestión de planificaciones, recursos y conflictos.
Planificar y coordinar los recursos y las capacidades necesarias para diseñar o modificar los servicios.
Producir los SDP (Service Design Packages), basados en la carta de servicios y las peticiones de cambio.
Asegurar que el diseño de los servicios y SDP se produce y transmite a la fase transición de servicios.
Gestionar los criterios de calidad, requerimientos entre las fases de estrategia y transición de servicios.
Asegurar que todos los modelos de servicios y soluciones diseñadas están de acurdo con la estrategia, la gestión y el resto de los requerimientos de la empresa.
Mejorar la eficacia y efectividad de las actividades y procesos.
Asegurar que todas las partes adoptan los estándares comunes, las prácticas de reutilización de las actividades y los procesos y sistemas de soporte apropiados.
Mejorar el rendimiento de la fase de diseño de los servicios.
3. Descripción del proceso
Proceso de coordinación del diseño
4. Conceptos básicos a. Políticas de diseño El proveedor del servicio debe definir las políticas que permitirán identificar el tipo de diseño sobre el que la coordinación debe prestar más atención. Por ejemplo, este puede ser el caso para los cambios importantes, y el resto de los cambios tendrán que corresponder a las normas de diseño definidas en este proceso. También se debe definir los niveles de documentación. Para un cambio importante, puede ser necesario tener un paquete de diseño (SDP - Service Design Package) completo, mientras que para los cambios menos importantes será suficiente con una documentación simplificada. Las políticas de diseño deben incluir:
El respeto de los estándares y convenciones de la empresa.
El respeto de las reglas de gestión en todas las actividades.
La puesta en marcha de estándares para asegurar una buena comprensión de las actividades de diseño:
Modelos de documento Planes de documentación Planes de formación Planes de marketing y comunicación Planes de medida y métricas Planes de prueba Planes de despliegue
Criterios para resolver los posibles conflictos de asignación de recursos.
Modelos de coste estándares.
5. Indicadores
Evolución del porcentaje de los servicios (diseño o cambio) exitosos, en términos de calidad, coste y respeto de los plazos.
Reducción del número de cambios urgentes que se crean como consecuencia del diseño de los servicios.
Satisfacción del cliente para cada servicio nuevo o modificado.
Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se ponga en marcha.
Gestión del catálogo de servicios 1. Enfoque En esta sección vamos a ver cómo se gestiona el catálogo de servicios. Veremos que este proceso es importante para la gestión de los servicios proporcionados por la organización TI, y principalmente para la gestión de la relación comercial, la gestión de los niveles de servicios y el centro de servicios.
2. ¿Por qué una gestión del catálogo de servicios? La organización informática necesita conocer cada uno de los servicios operativos e identificar todos los clientes de un mismo servicio.
3. Objetivos del proceso Los objetivos principales del proceso de gestión del catálogo de servicios son:
Mantener el conocimiento y comprensión de los servicios operativos establecidos por la organización TI.
Mantener la información contenida en el catálogo de servicios.
Asegurar la coherencia de la información entre el porfolio de servicios y el catálogo de servicios.
Asegurar la coherencia de la información contenida en el catálogo de servicios, principalmente de todos los detalles, los estados, las interfaces y las dependencias.
4. Definición Porfolio de servicios: expresión de la estrategia de servicios de la organización TI. Catálogo de servicios: contiene todos los servicios operativos o listos para usar.
5. Perímetro La gestión del catálogo de servicios, que es un subconjunto del porfolio de servicios, es responsable de todos los servicios operativos. La gestión del catálogo de servicios cubre:
La contribución a la definición de los servicios y paquetes de servicios (SDP).
El desarrollo y mantenimiento de la descripción de los servicios y paquetes de servicios (SDP).
La producción y mantenimiento de un catálogo de servicios actualizado.
Asegurar la coherencia de la información relativa a las interfaces y las dependencias con el porfolio de servicios.
6. Roles Los roles principales son los siguientes:
Responsable del catálogo de servicios
Responsable del porfolio de servicios
Responsable de la relación comercial
Propietario del proceso
7. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de servicios en el catálogo de servicios.
Número de servicios retirados en el periodo.
Número de servicios movidos en un periodo: Del pipeline al catálogo de servicios. O del catálogo a los servicios retirados.
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión del catálogo de servicios
9. Conceptos básicos a. El catálogo de servicios La organización informática necesita conocer cada uno de los servicios operativos e identificar a todos los clientes de un mismo servicio. Para dar respuesta a esta necesidad, es aconsejable poner en marcha un catálogo de servicios. El catálogo de servicios es un subconjunto del porfolio de servicios. El catálogo de servicios debe contener todos los detalles de todos los servicios operativos:
Sus características
Sus interfaces
Sus dependencias
Los procesos relacionados
Sus atributos
Su estado (le que debe ser único)
Su precio
Los soportes...
El catálogo de servicios está compuesto por dos secciones:
El catálogo de servicios profesionales. Solo los clientes o posibles clientes pueden ver este catálogo.
El catálogo de servicios técnicos.
Todos los cambios en el porfolio de servicios o en el catálogo de servicios se deben validar por el proceso de gestión de cambios.
Relaciones entre los componentes del catálogo
Relaciones entre los componentes del catálogo de servicios
El catálogo de servicios profesionales El catálogo de servicios de negocio contiene detalles de todos los servicios informáticos entregados a los clientes. Deben estar descritas las relaciones entre los procesos profesionales y los servicios.
El catálogo de servicios técnicos El catálogo de servicios técnicos contiene los detalles de todos los servicios informáticos entregados a los clientes. Se deben describir las relaciones entre los servicios, los servicios compartidos, los componentes y los CI necesarios para soportar los servicios.
b. Porfolio de servicios y catálogo de servicios El diseño de servicios diseña el porfolio de servicios, pero este se actualiza en gestión del porfolio de servicios. Los servicios proporcionados por los proveedores de servicios también son los elementos clave del porfolio de servicios y del catálogo de servicios. La organización debe definir una política relativa a la gestión del porfolio y catálogo de servicios. En particular, esta política debe definir los detalles de las responsabilidades para cada servicio. La gestión del porfolio de servicios se deberá realizar, de manera ideal, con la colaboración de diseño, transición, explotación y mejora continua de servicios.
Tan pronto como se transfiere un servicio a transición de servicios, este se debe incluir en el catálogo de servicios.
Gestión de los niveles de servicio 1. Enfoque En este apartado vamos a ver cómo se gestionan los diferentes contratos de servicio. Veremos que este proceso es especialmente importante para la gestión de los servicios proporcionados por la organización TI. Esto implica tanto a las relaciones entre el cliente como a las diferentes entidades de la organización TI y la gestión de los contratos con los subcontratistas.
2. ¿Por qué una gestión de los niveles de servicio? Es imprescindible verificar y validar las necesidades y requerimientos del cliente, y definir cuáles serán los compromisos que se deben aplicar entre los diferentes actores del entorno TI y, en particular, entre los clientes y la organización TI. Estos compromisos deben estar definidos obligatoriamente en los contratos firmados por las diferentes partes implicadas en los acuerdos de servicio. Una vez establecidos, los contratos de servicio permiten identificar los objetivos específicos y medir sus logros.
3. Objetivos del proceso El proceso de gestión de los niveles de servicios debe responder a varios objetivos. El principal es definir, documentar, acreditar, vigilar y medir los niveles de servicio proporcionados y, si es necesario, tomar medidas correctivas. Hay otros objetivos importantes, como proporcionar informes del nivel alcanzado de los objetivos definidos en los compromisos y el mantenimiento y la mejora de la relación con el cliente, en coordinación con el proceso de gestión de la relación comercial; estos elementos van a ayudar a mantener y mejorar la calidad de los servicios y vigilar y mejorar la satisfacción del cliente, respecto a los servicios proporcionados. En último lugar, pero igualmente importante, es necesario asegurar la comprensión clara y no ambigua de los compromisos de niveles de servicios entre la organización TI y el cliente.
4. Definición Service Level Requirement (SLR): es la expresión de las necesidades del cliente. Service Level Manager (SLM): es el responsable de la gestión de los niveles de servicio. Service Level Agreement (SLA): acuerdo de niveles de servicio alcanzado entre el cliente y la organización TI. Operationnal Level Agreement (OLA): acuerdo de niveles de servicio entre las diferentes entidades o servicios de la organización TI. Underpinning Contract (UC): contrato que establece las relaciones entre la organización TI y los subcontratistas o proveedores. Catálogo de servicios: documento que presenta el conjunto de servicios proporcionados por la organización de los TI. Service Improvement Program (SIP): programa de mejora de servicios. Es un documento que presenta las acciones de mejora de la gestión de los TI y de la relación con el cliente. Auto-conmutador: equipamiento que permite el enrutamiento de las comunicaciones telefónicas. ACD: equipamiento que permite el enrutamiento de las comunicaciones telefónicas, según un programa que tiene en cuenta los diferentes parámetros predefinidos por la organización TI.
5. Perímetro La gestión de los niveles de servicio es responsable de las siguientes acciones:
Cooperar con la gestión de la relación con el cliente.
Establecer y negociar los requerimientos de niveles de servicios solicitados por el cliente.
Establecer los requerimientos de los niveles de servicio entre las diferentes entidades de la organización TI y gestionarlos (OLA).
Establecer contratos de servicios con proveedores externos (UC) y asegurar que están alineados con los SLA y OLA.
Proporcionar un punto de contacto regular y comunicarse con el cliente o los profesionales.
Proporcionar seguimiento e informes de la realización de los servicios, en particular de los ausentes.
La gestión de los niveles de servicios cubre la totalidad de los servicios ofrecidos por la organización TI, así como la totalidad de servicios proporcionados por los subcontratistas o los proveedores de servicios.
6. Roles Los roles principales son los siguientes:
Responsable de los cambios
Responsable de los activos y configuraciones
Responsable de los niveles de servicios
Responsable de la relación comercial
Propietario del proceso
7. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso. Deben estar definidos en el SLA y serán específicos para cada servicio implicado en un contrato. Por lo tanto, no es posible dar aquí ejemplos, ya que dependen mucho del servicio ofrecido al cliente.
8. Descripción del proceso
El proceso de gestión de los niveles de servicios
9. Conceptos básicos a. Relaciones entre la gestión de la relación y la gestión de los niveles de servicio El objetivo principal de la gestión de los niveles de servicio es asegurar la consecución de los niveles de servicio definidos. Es una gestión diaria. El objetivo de la gestión de la relación comercial tiene una orientación a medio o largo plazo. Se trata de identificar las necesidades del cliente y asegurar la capacidad de la organización TI para responder a estas necesidades. Este proceso se centra en la relación global entre el proveedor de servicios y su cliente.
b. El ciclo de vida de un contrato de niveles de servicio
El ciclo de vida de un acuerdo de niveles de servicio
c. Expresión de la petición del cliente La expresión de la petición del cliente se debe realizar a través de un documento llamado SLR (Service Level Requirement). Este documento deberá tener en cuenta las necesidades del cliente y, en particular, los objetivos e indicadores deseados por este. A partir de este documento, el SLM (Service Level Manager) va a establecer su petición de cambios (RFC - Request For Change). El examen de esta petición por la gestión de cambios permitirá identificar los diferentes equipos que contribuirán al suministro del servicio y a la construcción del acuerdo de niveles de servicio, que se firmará con el cliente (SLA). En este marco, el responsable de los cambios transmitirá a los diferentes miembros del CAB (Change Advisory Board - grupo de personas encargadas de aconsejar al responsable de los cambios) los documentos relativos a este cambio.
d. Estudio y puesta en marcha de un contrato SLA El SLM asegura la negociación entre el cliente y el proceso de cambios, con el objetivo de encontrar un equilibrio entre las necesidades del cliente y aquello que la organización TI está en disposición de suministrar. Esta negociación puede requerir varios ciclos de ida y vuelta entre el cliente y el SLM, y el SLM y los propietarios/responsables de los procesos implicados en el servicio (proceso de gestión de la capacidad, proceso de gestión de la disponibilidad, proceso de gestión de la continuidad, proceso de gestión de la seguridad, proceso de gestión de incidencias, centro de servicios...). El SLM volverá entonces a dirigirse hacia el proceso de gestión de cambios, para encontrar la adecuación entre la petición del cliente, expresada en el SLR, y lo que ofrece la organización TI.
Será necesario definir paralelamente los contratos de niveles de servicio entre las diferentes entidades de la organización TI (OLA - Operationnal Level Agreement) y también, si fuera necesario, entre la organización TI y los subcontratistas o proveedores (UC - Underpinning Contract). Cuando se alcance un acuerdo con el cliente, será necesario establecer un contrato entre las dos partes, el SLA (Service Level Agreement), antes de que el servicio se pueda poner en marcha. Los diferentes acuerdos de servicio se deberán registrar en la CMS, a partir del porfolio y del catálogo de servicios (ver los capítulos correspondientes a estos procesos).
Un SLA debe ser un documento escrito, firmado por las dos partes, en términos no técnicos y comprensible para todos. Debe contener un determinado número de elementos que describan de manera precisa los compromisos y los indicadores, lo que permitirá asegurar que se respetan los compromisos. Estos acuerdos deben, por supuesto, definir los derechos y deberes de las dos partes. Para ser eficaz, el SLA debe ser un acuerdo real entre la organización TI y el cliente. Un acuerdo desequilibrado provocará, tarde o temprano, una situación de difícil manejo y la insatisfacción del cliente. Con frecuencia, en la actualidad, al menos en el ámbito de los acuerdos de servicio con grandes empresas, son estas las que imponen sus propios contratos a la organización TI. Muy a menudo, las razones dadas por estas empresas están basadas en cuestiones jurídicas. En este caso, la organización TI debe tomar todas las precauciones para que el contrato que se le ofrece reúna todos los elementos correspondientes al servicio propuesto.
Lo que debe contener un SLA A continuación encontrará un ejemplo de los elementos que deberá contener, como mínimo, un SLA para un centro de servicios. Es necesario indicar que este ejemplo solo es válido para este tipo particular de servicio. Se deberá adaptar al servicio realmente proporcionado por la organización TI.
Descripción del servicio.
Duración del contrato.
Perímetro del servicio.
Horarios de suministro del servicio (de 08:00 a 18:00).
Disponibilidad del servicio (de lunes a viernes).
Fiabilidad del servicio (90% de las llamadas entrantes deben ser atendidas).
Soporte del servicio (nivel de competencias exigidas a los técnicos).
Rendimiento del servicio: Volumen de llamadas entrantes. Plazo en el que se deben atender las llamadas (90% de las llamadas entrantes atendidas en menos de 30 segundos). Plazo de suministro de una solución (2 horas para una llamada de prioridad 2)...
Condiciones de puesta en marcha de un cambio o evolución del servicio.
Continuidad de los servicios de la organización TI.
Seguridad de los servicios de la organización TI.
Seguridad de disponibilidad).
Responsabilidades de TI y del cliente.
Informes y revisiones de los servicios (planificación de los comités de control).
Incentivos/penalizaciones de rendimiento...
la
información
de
los
clientes
(confidencialidad,
integridad,
Todos los indicadores u objetivos definidos en los acuerdos deben ser medibles. La aplicación de penalizaciones financieras deberá estar acompañada de la aplicación de incentivos financieros. Estos incentivos se deberán poner en marcha tan pronto como la calidad del servicio esté por encima del umbral predefinido.
Definición de los indicadores y objetivos en el ámbito de un SLA En el ámbito de la puesta en marcha de un acuerdo de tipo SLA, es necesario estar atentos a la definición de los objetivos e indicadores.
Definición de los indicadores En el ejemplo anterior, para estar seguros de no sobrepasar un objetivo de llamadas no respondidas superior al 15% de las llamadas entrantes, será necesario fijar objetivos más ambiciosos para las diferentes entidades implicadas en la realización del servicio. Se dará el objetivo del 12% a los tres equipos, y se deberá firmar un acuerdo de niveles de servicio de tipo OLA con cada uno de los 3 equipos. De esta manera, aunque uno de los equipos no alcance su objetivo, esto permitirá mantener la consecución del objetivo final. Si uno de los equipos (por ejemplo: equipo A) subcontrata una parte de su actividad, será prudente a la hora de fijar al subcontratista un objetivo superior, por ejemplo, menos del 10% de llamadas no atendidas, con el objetivo de mantener el objetivo inicial fijado para el equipo A, en caso de dificultades leves del subcontratista. Ejemplos: El centro de servicios recibe 1.000 llamadas al mes, y el objetivo está fijado en el 15%. El objetivo de llamadas no respondidas o perdidas es equivalente a menos de 150 llamadas/mes. A los 3 equipos se les ha fijado un objetivo del 12% máximo de llamadas no respondidas, es decir, 120 llamadas/mes como máximo.
El equipo A recibe 300 llamadas/mes.
400
llamadas/mes
y
los
otros
equipos
reciben
cada
uno
Esto significa que el equipo A no debe perder más de 48 llamadas por mes y que los otros no deben perder más de 36 llamadas/mes. El equipo A subcontrata la mitad de su actividad, es decir, 200 llamadas/mes. Deberá firmar un acuerdo de tipo UC que prevea un objetivo inferior al 10% de las llamadas, es decir, un máximo de 20 llamadas/mes. Caso 1 Si los resultados del subcontratista no son los correctos, por ejemplo, 30 llamadas perdidas, y el equipo A se encuentra justo en el límite del objetivo de la parte que él realiza, es decir, 24 llamadas perdidas, el objetivo global fijado para el equipo A se sobrepasa: 30 + 24 = 54 llamadas perdidas. En la hipótesis de que los otros dos equipos estén también en el límite de sus objetivos, el número de llamadas perdidas por el conjunto del centro de servicios será entonces de 36 + 36 + 54 = 126 llamadas perdidas. Esto significa que, aunque el conjunto de los equipos no ha sido especialmente eficaz, los objetivos del SLA sin embargo son correctos: 126 llamadas perdidas para un objetivo máximo de 150 llamadas. Caso 2 El equipo B tiene dificultades serias y pierde 50 llamadas. Los otros equipos están en el límite de sus objetivos. El número total de llamadas perdidas será entonces de: 48 + 36 + 50 = 134 llamadas perdidas para un objetivo máximo de 150 llamadas. Los objetivos del SLA serán, sin embargo, correctos.
Estos dos ejemplos muestran que la fijación de objetivos superiores permite mantener el objetivo fijado en el SLA, incluso en caso de que un equipo falle.
e. Estudio y puesta en marcha de un acuerdo OLA Normalmente, el suministro de un servicio al cliente implica actividades para varias entidades de la organización TI. Es necesario definir en qué ámbito deberán proporcionar sus servicios estas diferentes entidades. Para ello, se debe establecer un acuerdo de niveles de servicios específico. Este acuerdo se llamada OLA (Operational Level Agreement). Este acuerdo se firma entre la entidad responsable de proporcionar el servicio al cliente y cada una de las otras entidades que contribuye al suministro del servicio.
Lo que debe contener un OLA Más adelante encontrará un ejemplo de los elementos que debería contener, como mínimo, un OLA para una prestación de centro de servicios. Describe los compromisos entre el centro de servicios y el equipo de «informática interna». Es necesario indicar que este ejemplo sólo es válido para este tipo particular de servicio. Se debe adaptar al servicio realmente proporcionado por la organización TI.
Descripción del servicio.
Perímetro del servicio.
Horario de suministro del servicio (de 7:00 a 19:00).
Disponibilidad del servicio (de lunes a viernes).
Fiabilidad del servicio (100% en los horarios de suministro del servicio al cliente).
Soporte del servicio (nivel de competencias exigido para los técnicos que intervienen en la plataforma del centro de servicios).
Rendimiento del servicio: Plazos de intervención sobre un puesto de trabajo. Plazos de intervención sobre un puesto telefónico. Plazos de restablecimiento en caso de incidencia sobre un autoconmutador. Plazos de restablecimiento en caso de una incidencia sobre el ACD. Plazos de suministro para la instalación de un nuevo puesto de trabajo. Flujo de ancho de banda...
Condiciones de puesta en marcha de un cambio o evolución del servicio.
Continuidad de los servicios de la organización TI.
Seguridad de los servicios de la organización TI.
Seguridad de la información de cliente (confidencialidad, integridad y disponibilidad).
Responsabilidades del centro de servicios y del equipo de «informática interna».
Informes y revisiones del servicio (planificación de los comités de control).
Coste interno de los diferentes elementos del servicio.
Imputación de los diferentes elementos del servicio...
f. Estudio y puesta en marcha de un acuerdo UC (Underpinning Contract) En algunos casos, la organización puede tener una estrategia de externalización, para ciertos servicios o parte de los servicios.
Esta estrategia se basa en el uso de los recursos de una o varias organizaciones externas, para suministrar una parte claramente definida del diseño, desarrollo, mantenimiento, explotación y/o soporte de un servicio. Los servicios de aplicaciones de tipo ASP pueden estar dentro de esta categoría. La firma de un acuerdo oficial entre la organización TI y el proveedor externo se hace en forma de contrato de tipo UC (Underpinning Contract). Los objetivos que se definirán con el subcontratista o el proveedor deben estar adaptados para responder a los objetivos fijados en los acuerdos de niveles de servicio firmados con el cliente (SLA). En este tipo de contrato, la organización TI es «cliente» del proveedor.
Atención, hay que diferenciar entre los acuerdos (tipos SLA y OLA) y el contrato (tipo UC).
10. Beneficios y dificultades a. Beneficios La gestión de los niveles de servicio permite una buena relación con el cliente. Permite poner en práctica los contratos que servirán de base para medir la efectividad y eficacia de los procesos a través de los diferentes indicadores que se aplicarán. La validación de los acuerdos por el proceso de cambios garantizará la adecuación entre las necesidades del cliente y las capacidades de la organización TI.
b. Dificultades potenciales Es imprescindible que los contratos sean claros y precisos. Un error común es la definición de los indicadores. Es necesario prestar atención a lo que se desea medir y también al volumen de los elementos medibles. Si toma un indicador con un umbral muy elevado y un volumen bajo, corre el riesgo de sobrepasar este umbral aunque solo esté fallando un único elemento. Por ejemplo Número de incidencias principales tratadas en menos de 1 hora, con un umbral del 90%. Si sólo tiene 10 incidencias principales por mes, es suficiente una única incidencia tratada en 1 hora para sobrepasar el umbral. ¡Por lo tanto, este no es un buen indicador!
Atención también al seguimiento de los contratos y acuerdos de servicios. Las reuniones de seguimiento se deben realizar en los plazos previstos en el contrato o los acuerdos de servicio. También se deben elaborar y distribuir los informes.
Gestión de la capacidad 1. Enfoque En esta sección vamos a ver cómo se gestiona la capacidad de la organización TI. Veremos que el suministro de servicios y su calidad dependen mucho de la eficacia del proceso.
2. ¿Por qué una gestión de la capacidad? En un entorno actual, donde los presupuestos están impuestos en general, es importante asegurar que los costes en inversión y funcionamiento están perfectamente justificados y, sobre todo, que estos costes permiten proporcionar los medios necesarios para entregar los servicios, respetando los compromisos que figuran en los SLA. Es imprescindible adaptar las actividades de la organización TI para utilizar eficientemente los recursos. Para esto, es indispensable controlar el rendimiento y la rentabilidad de los servicios ofrecidos por la organización TI. Es imprescindible comprender las peticiones actuales de servicios informáticos de los clientes para prever los requerimientos futuros. Igualmente, es necesario ajustar el uso de los recursos teniendo en cuenta otros procesos de gestión de servicios. Último punto: es necesario elaborar un plan de la capacidad que prevea los recursos de la organización TI, necesarios para atender los niveles de servicio pactados en los acuerdos de servicios (SLA).
La gestión de la capacidad y de la disponibilidad son esenciales para asegurar la parte de Garantía en el valor del servicio (Valor del servicio = Utilidad + Garantía).
3. Objetivos del proceso Los objetivos principales del proceso de gestión de la capacidad son los siguientes:
Producir y mantener un plan de capacidad, apropiado y actualizado, que refleje las necesidades actuales de la organización TI.
Garantizar que el rendimiento de servicios corresponde o excede los objetivos de rendimiento acordados en los SLA, gestionando el rendimiento y la capacidad de servicios y los recursos de la organización TI.
Proporcionar los consejos y servir de guía, para todos los problemas relacionados con la capacidad y el rendimiento, al resto de los sectores de la organización TI y de la empresa.
Evaluar el impacto de todos los cambios solicitados, en términos de plan de capacidad, recursos y rendimiento.
Tomar medidas proactiva para mejorar el rendimiento de los servicios, siempre que tenga justificación financiera.
El proceso de gestión de la capacidad también tiene la responsabilidad de asegurar el sistema de alertas de novedades tecnológicas para la organización TI.
4. Definición BCM (Business Capacity Management): subprocesos cuyo objetivo es garantizar que se tienen en cuenta los requerimientos futuros. SCM (Service Capacity Management): subprocesos cuyo objetivo es identificar y entender los servicios informáticos. CCM (Component Capacity Management): subprocesos cuyo objetivo es la gestión, el control y la previsión del rendimiento, el uso y la capacidad de los componentes.
5. Perímetro La gestión de la capacidad debe ser un punto central para el rendimiento de la organización TI, en términos de rendimiento y capacidad. La gestión de la capacidad tiene en cuenta el conjunto de componentes de la infraestructura informática (hardware y software). También se debe tener en cuenta la gestión de los recursos humanos, ya que una falta de personal cualificado puede ser origen de un funcionamiento incorrecto en el suministro de los servicios. La gestión de los PBA (Pattern Business Activity), proporcionados por el proceso de gestión de la demanda, se debe tener en cuenta en la gestión de la capacidad. La gestión de la capacidad, junto con proceso de gestión financiera, va a influir en el proceso de la gestión de la demanda. La gestión de la capacidad debe ayudar al diagnóstico y resolución de los incidentes y problemas asociados a un componente o servicio. La gestión de la capacidad también se debe hacer cargo de todos los cambios proporcionados por la gestión de cambios relativos a la infraestructura. Cuando en la organización TI existe un sistema de alertas de novedades tecnológicas, es oportuno que esté unido a la gestión de la capacidad.
6. Roles Los roles principales son los siguientes:
Responsable de la capacidad
Propietario del proceso
7. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Conformidad con la capacidad prevista.
Evolución de la capacidad de almacenamiento.
Evolución de la potencia de procesamiento de CPU.
Evolución de la banda ancha...
Interrupción en el suministro del servicio, como consecuencia de una falta de medios o recursos.
Reducción del número de incidentes o problemas debidos a un bajo rendimiento.
...
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión de la capacidad
9. Conceptos básicos
Equilibrio de la gestión de la capacidad La imagen anterior simboliza la gestión de la capacidad. Hay que ser capaz de encontrar el correcto equilibrio, entre los costes por un lado y la capacidad por otro, entre la oferta y la demanda.
a. El ciclo de vida de la gestión de la capacidad El ciclo de vida de la capacidad se puede definir con tres actividades principales, que se detallan a continuación. El punto de entrada de estas actividades está relacionado con el proceso de estrategia de servicios.
El ciclo de vida de la gestión de la capacidad
b. Los diferentes subprocesos La gestión de la capacidad está compuesta de tres subprocesos.
Algunas actividades de estos subprocesos son similares, aunque cada subproceso tiene un objetivo muy diferente.
Gestión de la capacidad de negocio (BCM) El objetivo principal del subproceso de gestión de la capacidad de negocio es garantizar que los requerimientos de negocio futuros para los servicios informáticos se tienen en cuenta y están incluidos, y que se planifica y pone en marcha dentro de plazo una capacidad informática suficiente para soportar los servicios nuevos o modificados. Para esto, es necesario transformar las necesidades y los planes de negocio en requerimientos para los servicios y la infraestructura informática. Los requerimientos de negocio futuros para los servicios informáticos se cuantifican, diseñan, planifican y ejecutan en plazos.
Gestión de la capacidad de servicio (SCM) El objetivo principal del subproceso es garantizar que el rendimiento de todos los servicios se corresponde con los objetivos definidos en los SLA. Este subproceso también tiene como objetivo garantizar que este rendimiento se supervisa y se mide, y que los datos obtenidos se registran, analizan y reportan. Por último, este subproceso tiene como objetivo la gestión, el control y la previsión:
Del rendimiento de principio a fin.
Del uso de los servicios informáticos operativos.
De la producción y de las cargas de trabajo.
Gestión de la capacidad de los componentes (CCM) El objetivo principal de este subproceso es la gestión, el control y la previsión del rendimiento, del uso y la capacidad de los componentes tecnológicos de la infraestructura informática. Este subproceso también tiene como objetivo garantizar que todos los componentes de la infraestructura informática que tienen un recurso limitado sean supervisados y medidos y que los datos obtenidos se registren, analicen y reporten.
c. Producción del plan de capacidad El plan de capacidad se construye a partir de los elementos que provienen de las diferentes actividades de la gestión de la capacidad.
Producción del Plan de capacidad La gestión de la capacidad proporciona un plan de capacidad que engloba:
Los recursos informáticos.
La financiación necesaria.
La justificación del coste de este gasto.
El plan de capacidad se establece teniendo en cuenta las necesidades expresadas por el proceso de gestión del porfolio de servicios, así como por los PBA (Pattern Business Activity). Cuando se aplica el proceso de gestión de la continuidad, las necesidades particulares de este proceso se deben tener en cuenta en el proceso de gestión de la capacidad. El plan de capacidad también tiene como objetivo soportar el plan de la empresa. La producción y el mantenimiento de la capacidad se debe efectuar en los intervalos predefinidos. Es esencialmente un plan de inversiones y, por lo tanto, se debe publicar cada año y servirá de base para las negociaciones de los presupuestos futuros. El plan de capacidad se utiliza en todos los dominios de la empresa y de la gestión informática. Los proveedores de servicios informáticos y la dirección de la organización TI actúan sobre este último para planificar la capacidad de la infraestructura informática. El plan de capacidad contiene la información sobre el uso actual de los servicios y los componentes. También contiene los planes para el desarrollo de la capacidad informática, con el objetivo de responder a las necesidades del crecimiento de los servicios existentes y de los nuevos servicios acordados en el marco del SLA.
El plan de capacidad se debe utilizar de manera activa, como base en la toma de decisiones.
Contenido de un plan de capacidad A continuación encontrará un ejemplo de lo que puede contener un plan de capacidad:
Introducción
Perímetro del plan
Método de recogida de información
Hipótesis
Escenarios de negocios
Resumen de servicios
Resumen de los recursos
Tasa de utilización actual
Previsiones del uso de servicios y recursos
Opciones de mejora de los servicios
Modelo de costes
Recomendaciones
d. Gestión de la demanda El proceso de gestión de la petición debe permitir a la gestión de la capacidad influir en las peticiones de servicios de los clientes y de los usuarios. Esta actividad permitirá gestionar el impacto de estas peticiones sobre los componentes de la infraestructura informática. La modelización se realiza a partir de estas peticiones.
e. Modelización El objetivo principal del proceso de la gestión de la capacidad es predecir el comportamiento de los sistemas informáticos, respecto a un volumen y variedad de tareas dadas. El objetivo de la modelización es beneficiarse de la ejecución de los subprocesos de la gestión de la capacidad. La modelización se puede basar en estimaciones que son resultado de la experiencia, en la información actualizada, relativa al uso de los componentes, o en estudios piloto. También se puede realizar basándose en prototipos o benchmarks. Algunas opciones pueden ser costosas, pero se recomiendan, especialmente en el caso de que se pongan en marcha nuevos servicios.
Base de referencia
En primer lugar, para realizar una modelización, es necesario crear un modelo de referencia que refleje exactamente el rendimiento en curso. Solo después se puede realizar la modelización. Para esto vamos a hacernos, por ejemplo, la siguiente pregunta: «¿qué pasaría si?». Esta pregunta puede estar relacionada con los fallos, los cambios planificados efectuados, los volúmenes y la variedad de las cargas de trabajo.
Análisis de las tendencias Es posible efectuar un análisis de las tendencias sobre el uso de los componentes a partir de la información del rendimiento de los servicios que se ha recogido en el proceso de gestión de la capacidad. El análisis de la tendencia solo proporciona las estimaciones sobre el uso futuro de los recursos. Este análisis puede ayudar en la toma de decisiones y en la definición del plan de capacidad.
Modelos analíticos Existen modelos analíticos que son representaciones del comportamiento de los sistemas informáticos. Estos modelos utilizan técnicas matemáticas; por ejemplo, teoría de la cola de espera de red de clase múltiple. El modelo se construye normalmente a través de un paquete de software, especificando en el paquete los componentes y la estructura de la configuración que se necesita modelizar. También conviene precisar el uso del componente, por ejemplo: CPU, memoria, disco o red, para numerosas tareas o aplicaciones.
Dimensionamiento de la aplicación El objetivo principal del dimensionamiento de la aplicación es estimar los requerimientos de recursos, para soportar un cambio propuesto en un servicio existente o la puesta en marcha de un servicio nuevo. El objetivo también es asegurar que el dimensionamiento obtenido va a garantizar que se satisfacen los niveles de servicio requeridos. La modelización se puede utilizar en el proceso de dimensionamiento de la aplicación.
f. Las actividades iterativas de la gestión de la capacidad Estas actividades, como para todo proceso, se basan en el funcionamiento de la Rueda de Deming.
Las actividades iterativas de la gestión de las capacidades A partir de los datos obtenidos por un determinado número de controles y entradas de información (acción de «Check»), se podrá realizar una acción de análisis (acción de «Act»). A partir de este análisis, será posible definir las acciones que se deben poner en marcha (acción de «Plan»). En ese momento, solo faltará implementar las acciones definidas (acción de «Do»).
g. El contenido de las bases de datos de la capacidad
El contenido de la base de datos de la capacidad La base de datos de la capacidad contiene información muy variada:
Datos técnicos.
Financieros.
De uso.
de negocio.
De servicios.
A partir de estos datos, el responsable de la capacidad estará en disposición de proporcionar los informes de gestión y, sobre todo, el plan de capacidad.
Gestión de la disponibilidad 1. Enfoque En esta sección vamos a ver cómo se asegura la disponibilidad de los servicios por parte de la organización TI. Veremos que la disponibilidad de los servicios y su calidad dependen mucho de la eficacia de este proceso.
2. ¿Por qué una gestión de la disponibilidad? Hoy en día, las empresas son cada vez más dependientes de las tecnologías de la información. La disponibilidad y fiabilidad de los servicios informáticos dependen de la fiabilidad de los componentes, de la infraestructura puesta en marcha para responder a las expectativas del cliente, como las que se formulan en el SLA.
La no disponibilidad de un servicio o de un componente puede tener un impacto financiero más o menos importante para la empresa y el cliente. Por esta razón hoy en día la gestión de la disponibilidad resulta esencial para garantizar que la organización TI libere los niveles de disponibilidad de servicios, tal y como fueron definidos en los SLA.
La satisfacción del cliente y los usuarios depende directamente de la disponibilidad del servicio. En este sentido, la gestión de la disponibilidad tiene un papel primordial en la puesta en marcha y seguimiento de los servicios.
3. Objetivos del proceso Los objetivos principales del proceso de gestión de la disponibilidad son los siguientes:
Producir y mantener un plan de disponibilidad, adecuado y actualizado, que refleje las necesidades actuales y futuras de la organización TI y de sus clientes.
Garantizar que la disponibilidad de los servicios cumple o excede los objetivos de disponibilidad acordados en los SLA, gestionando los servicios y recursos relacionados con el rendimiento de la disponibilidad.
Proporcionar consejos y servir de guía en todos los problemas relacionados con la disponibilidad para el resto de los sectores de la organización TI y de la empresa.
Evaluar el impacto de todos los cambios solicitados, en términos de plan de capacidad, recursos y rendimiento.
Asegurar que las medidas proactivas se implementan cuando es necesario y tienen justificación financiera.
4. Definiciones Disponibilidad: aptitud de un servicio TI o un componente para cumplir la función esperada en un momento dado o durante un periodo de tiempo definido. Fiabilidad: capacidad de un servicio TI para funcionar sin fallos operativos. Facilidad de mantenimiento: facilidad de un servicio para ser mantenido o restaurado a un estado operativo. Facilidad de servicio: respeto de los acuerdos contractuales alcanzados con terceros para asegurar la disponibilidad de los servicios de las organizaciones TI. También se conocen como capacidad de soporte exterior. Resistencia: capacidad de un servicio TI para continuar funcionando correctamente a pesar de un fallo de uno o varios de sus subsistemas. Seguridad: puesta en marcha de controles justificables con el objetivo de asegurar un servicio informático continuo (sistemas y datos que residen en él), respetando los parámetros de confidencialidad, integridad y disponibilidad (ver sección Seguridad Concepto CIA). Función vital de negocio (VBF): elementos de negocio críticos de un proceso de negocio o de un servicio TI.
Plan de disponibilidad: plan a largo plazo de mejoras proactivas de la disponibilidad de las organizaciones TI, en función de las restricciones presupuestarias.
5. Perímetro La gestión de la capacidad tiene a su cargo el conjunto de la infraestructura informática. La gestión de la capacidad también se debe hacer cargo de todos los cambios proporcionados por la gestión de los cambios y que conciernen a la infraestructura. La gestión de la disponibilidad se centra en dos tipos de actividades: las actividades reactivas y las actividades proactivas. Estas actividades se desarrollan más extensamente en la sección sobre conceptos básicos.
6. Roles Los roles principales son los siguientes:
Responsable de la disponibilidad
Propietario del proceso
7. Indicadores Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:
Conformidad de la disponibilidad prevista.
Tiempos de no disponibilidad.
Número de no disponibilidades.
MTTR (Mean Time To Repair), MTBSI (Mean Time Before Service Incidents), MTBF (Mean Time Before Failure)...
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión de la disponibilidad
9. Conceptos básicos El proceso de gestión de la disponibilidad incluye dos elementos clave:
a. Las actividades reactivas Se debe supervisar, medir y analizar todos los eventos, incidencias y problemas que implican la no disponibilidad de un servicio. Estas actividades están implicadas fundamentalmente en los roles operativos. Entre las actividades reactivas de la gestión de la disponibilidad, podemos identificar la medida, el análisis y la gestión de todos los eventos encontrados durante el periodo de suministro del servicio (evento, incidente o problema), generando una disminución de la disponibilidad o la no disponibilidad parcial o total. Como sucede con cualquier proceso, la gestión de la disponibilidad debe proporcionar informes de la disponibilidad de los servicios y componentes.
b. Las actividades proactivas Para ser eficaz, la gestión de la disponibilidad debe tener actividades proactivas. Estas actividades se centran en una planificación proactiva, una implicación en el diseño y la mejora de la disponibilidad. Estas actividades están implicadas fundamentalmente en los roles de diseño y planificación.
Las actividades proactivas de la gestión de la disponibilidad son:
Identificar las funciones vitales de negocio (VBF - Vital Business Functions).
Diseño con vistas a la disponibilidad.
Análisis del impacto del fallo de un componente.
Análisis del punto de fallo único.
Análisis por árbol de fallos.
Modelización.
Análisis y gestión de los riesgos.
Calendario de pruebas de la disponibilidad.
Mantenimiento preventivo y planificado.
Producción de documentos de la (PSA - Projected Service Availability).
Revisión y mejora continua.
disponibilidad
proyectada
del
servicio
c. Seguridad - Concepto CIA La seguridad es un punto importante en el proceso de gestión de la disponibilidad. La disponibilidad también refleja cómo los usuarios acceden a los sistemas de información y a la información que contienen. La gestión de la disponibilidad tiene la responsabilidad de asegurar que los requerimientos de seguridad se definan de forma conjunta con los usuarios y se incorporen al diseño de la disponibilidad, especialmente para:
El acceso lógico y físico a los datos, componentes o servicios de las TI disponibles únicamente para las personas autorizadas.
El retorno al servicio de los componentes y servicios, sin comprometer las directivas de seguridad de las TI.
En este objetivo, la gestión de la disponibilidad pone en marcha el concepto de CIA. Este concepto tiene que ver con la seguridad de datos. Confidencialidad, Integridad, Disponibilidad = Confidentiality, Integrity, Availability La sigla CIA significa: Confidentiality: solo las personas autorizadas pueden acceder a los datos. Integrity: los datos deben estar íntegros en el momento en que se entregan. Availability: los datos deben estar disponibles en el momento en que se necesitan.
La gestión de la seguridad es responsable de definir las políticas de seguridad de la empresa y asegurar la conformidad con las directivas de seguridad en el seno de la organización TI. Sin embargo, el proceso de gestión de la disponibilidad debe poner en práctica las políticas de seguridad definidas por la gestión de la seguridad.
d. Los diferentes tipos de disponibilidad Alta disponibilidad: característica de un servicio TI que minimiza u oculta a ojos del usuario los efectos de los errores de un componente TI. Operación continua: característica de un servicio TI que minimiza u oculta a ojos del usuario los efectos de un periodo de no disponibilidad planificado. Disponibilidad continua: característica de un servicio TI que minimiza u oculta a ojos del usuario los efectos de todos los errores y todos los periodos de no disponibilidad planificados.
Vista global de los diferentes niveles de disponibilidad
e. Cálculo de los tiempos de no disponibilidad Los tiempos de disponibilidad y no disponibilidad se calculan con la ayuda de tres indicadores,MTTR, MTBSI y MTBF. El esquema siguiente muestra cómo se definen estos diferentes indicadores.
Modo de cálculo de los indicadores El MTTR, duración media de reparación o tiempo de no disponibilidad, también llamado Down Time o tiempo de no disponibilidad, es el tiempo transcurrido entre el momento en que se produce una incidencia y el momento en que el servicio se restaura. Incluye el tiempo de detección, diagnóstico (o tiempo de respuesta), reparación, restauración y recuperación. El MTBF es la duración media durante la cual el servicio está disponible. También se llama Up Time o tiempo disponible. El MTBSI es el tiempo medio entre dos incidencias.
Es importante que el indicador MTBF sea lo más elevado posible. También es importante que el indicador MTBSI sea, del mismo modo, lo más elevado posible. En caso contrario, esto provocará la aparición de múltiples periodos de no disponibilidad, lo que perjudicará la calidad percibida por el cliente, aunque el indicador MTBF esté en los límites definidos en el SLA.
f. El Plan de disponibilidad Es imprescindible elaborar un plan de disponibilidad, ya que servirá para estructurar el conjunto de acciones que permitan mejorar el proceso de gestión de la disponibilidad. Este plan debe contener:
Los fines.
Los objetivos.
Los elementos de gestión (personal, herramientas técnicas...).
Para elaborar el plan de disponibilidad, es deseable propietarios/responsables de los siguientes procesos:
La gestión de los niveles de servicios.
La gestión de la continuidad de los servicios.
La gestión de la capacidad.
La gestión financiera.
poner
en
contacto
a
los
El plan de disponibilidad debe cubrir un periodo de 1 a 2 años y se deberá hacer una revisión regular 3 o 4 veces por año. El plan de capacidad y el plan de disponibilidad son complementarios.
g. El coste de la no disponibilidad La aplicación del proceso de gestión de la disponibilidad tiene un coste. Algunas veces es necesario justificar este coste. Una buena manera de justificar esta inversión es presentar los costes de no disponibilidad. La tabla siguiente aporta una buena metodología de presentación de los costes de no disponibilidad y sus consecuencias en la relación con el cliente.
Coste de la no disponibilidad
10. Beneficios y dificultades a. Beneficios El interés de la puesta en marcha del proceso de gestión de la disponibilidad reside en que permite identificar un responsable único de la disponibilidad del conjunto de servicios operativos. Esto también permite tener una persona responsable capaz de responder a las necesidades expresadas por las diferentes áreas de negocio.
b. Dificultades potenciales La principal dificultad que puede surgir se relaciona con el volumen y la complejidad de los elementos que hay que manejar. La dificultad más frecuente es determinar las necesidades del negocio o del cliente. Es necesario garantizar una disponibilidad que sea eficiente, es decir, de un nivel ligeramente superior al nivel normal demandado por el negocio. Pero no es necesario que este nivel sea demasiado elevado, ya que se puede incurrir en un coste adicional.
Gestión de la continuidad de los servicios 1. Enfoque En esta sección vamos a ver cómo la organización TI se asegura de la continuidad de servicios informáticos. En el vocabulario que se usa en la continuidad de los servicios, se utiliza de manera habitual el término ITSCM (IT Services Continuity Management). Veremos que la supervivencia de la empresa, en caso de un fallo grave, depende de la eficacia de este proceso.
2. ¿Por qué una gestión de la continuidad? Las empresas cada vez dependen más de sus equipos informáticos. Un fallo grave puede tener consecuencias desastrosas para la empresa. En un número importante de casos, un fallo informático grave conduce a la desaparición de la empresa. Sin embargo, aún hoy en día, un gran número de empresas nunca ha puesto en práctica un plan de continuidad de servicios. La crisis económica ha obligado a muchas empresas a reducir sus presupuestos informáticos, incluidos los destinados a copias de seguridad y a la no interrupción de las actividades. Sin embargo, deben encontrar el equilibrio adecuado entre los costes y los riesgos, evaluando las pérdidas potenciales en caso de desastre y, sobre todo, el tiempo que se necesitaría para devolverlo todo a un estado normal de funcionamiento.
La gestión de la continuidad de los servicios es un elemento esencial de la noción de garantía en la definición del valor del servicio.
Cuanto más complejas son las aplicaciones, más graves son las consecuencias en caso de avería.
3. Objetivos del proceso Los objetivos principales del proceso de gestión de la continuidad de servicios informáticos son los siguientes:
Sostener el proceso global de gestión de la continuidad de la empresa, asegurando el suministro de los servicios agregados en el marco del BCM (Business Continuity Management) y los niveles definidos.
Producir y mantener un conjunto de planes de continuidad.
Asegurar la capacidad para poner en práctica los planes de continuidad, respetando los niveles de servicio, principalmente en términos de disponibilidad de seguridad.
Asegurar de manera regular que los planes de continuidad responden a las evoluciones de los BIA (impactos y requerimientos).
Proporcionar consejos a todas las áreas del negocio y a la organización TI sobre la puesta en marcha del proceso de la continuidad.
Asegurar que se tienen en cuenta todos los cambios en el plan de continuidad.
Asegurar que se toman medidas proactivas para mejorar la disponibilidad de los servicios, dentro de los límites de un coste justificable.
4. Definiciones BCP (Business Continuity Plan): plan de continuidad del negocio. BCM (Business Continuity Management): proceso que se ocupa del análisis y gestión del riesgo, con el objetivo de que la organización pueda asegurar, en todo momento, la capacidad de producción o el suministro de los servicios mínimamente requeridos. BIA (Business Impact Analysis): método de análisis del impacto en el negocio que permite evaluar las pérdidas potenciales durante un siniestro. DRP (Disaster Recovery Plan): plan de restablecimiento o recuperación informática.
5. Perímetro La gestión de la continuidad tiene a su cargo toda la infraestructura informática o parte de ella. El proceso de continuidad de los servicios (ITSCM) se encarga de:
Lo que está en el perímetro del proceso y las reglas que tiene asociadas.
Los BIA (existentes y actualizados), para identificar el impacto en caso de funcionamiento incorrecto.
La identificación y la gestión de los riesgos.
Una estrategia de continuidad que se integrará en el proceso BCM.
Uno o varios planes de continuidad.
Los planes de prueba para asegurar la capacidad para poner en práctica los planes de continuidad.
6. Roles Los principales roles son los siguientes:
Responsable de la continuidad de servicios.
Propietario del proceso.
7. Indicadores Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:
Índice de formación de los equipos.
Tiempo de puesta en marcha del plan.
Tiempo de recuperación.
Tiempo de retorno a un servicio normal.
Tiempo para adoptar los nuevos servicios...
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Aspectos identificables en un BIA (Business Impact Analysis) La introducción de un BIA debe permitir la identificación y posterior prevención de un cierto número de riesgos, como por ejemplo:
Pérdida de la capacidad operativa.
Pérdida de ventajas competitivas.
Pérdida de beneficio.
Gastos adicionales.
Reputación dañada.
No respetar las obligaciones legales.
Riesgo para la seguridad del personal.
Pérdida inmediata a largo plazo de partes de mercado.
9. Descripción del proceso
El proceso de gestión de la continuidad
10. Conceptos básicos a. Ciclo de vida de la gestión de la continuidad de servicios
Ciclo de vida de la gestión de la continuidad
Fase 1 - Iniciación Durante esta fase, la primera etapa es determinar cuáles son las políticas puestas en marcha. La segunda etapa consiste en determinar cuál será el perímetro que se tendrá en cuenta en el plan de continuidad de servicios. La última etapa consiste en poner en práctica el proyecto.
Fase 2 - Requerimientos y estrategias La primera etapa consiste en hacer un análisis de impactos en el negocio, área por área y servicio por servicio. La segunda etapa consiste en una evaluación de los riesgos. Para ello es posible utilizar el método CRAMM (ver la sección El método CRAMM).
La última etapa consiste en definir la estrategia de continuidad de servicios informáticos.
Fase 3 - Puesta en marcha La primera etapa de esta fase es desarrollar los planes de continuidad de servicios informáticos. La segunda etapa es desarrollar los planes informáticos, los planes de recuperación y los procedimientos relacionados con estos planes. La tercera etapa consiste en la planificación de la organización. Para terminar esta fase, la última etapa consiste en la puesta en práctica de la estrategia de pruebas.
Fase 4 - Gestión operativa Para esta última fase, en la primera etapa, es necesario formar, educar y sensibilizar a los empleados. Durante la segunda etapa, también es necesario poner en práctica las auditorías y revisar de manera regular los planes elaborados. La tercera fase consiste en poner en marcha la estrategia de pruebas. Las pruebas se deben realizar en función de la planificación elaborada en el plan de pruebas. La última etapa consiste en tener en cuenta la gestión de los cambios.
Resumen de las actividades de puesta en marcha
b. El método CRAMM El método CRAMM fue creado en 1987 por la agencia central de informática y telecomunicaciones del gobierno del Reino Unido, el CCTA, de donde viene su nombre de CRAMM (CCTA Risk Analysis and Management Method). CRAMM es un método de análisis de riesgos conforme a las normas BS 7799 e ISO 17799. El método CRAMM está estructurado en las tres fases siguientes: 1 - Definición de los valores de riesgo. 2 - Análisis de los riesgos y de vulnerabilidad. 3 - Definición y elección de las medidas de seguridad.
Definición de los valores Esta primera fase consiste inicialmente en determinar el perímetro de estudio y organizar las actividades. Seguidamente se procede a la definición de los valores (los activos de la organización TI) y su importancia relativa.
Análisis de los riesgos y de la vulnerabilidad Durante esta fase, se agrupan los valores en función de las necesidades relativas a disponibilidad, integridad y confidencialidad de los datos (ver Gestión de la disponibilidad Conceptos básicos). Seguidamente se establecerá la gravedad de los riesgos y la vulnerabilidad de las defensas. Para terminar, se precisará el nivel de importancia de los principales riesgos.
Definición y elección de las medidas de seguridad Durante esta fase será necesario definir las necesidades en términos de medios de seguridad y compararlas con la seguridad existente. Seguidamente se debe diseñar el plan de medidas de correcciones que se deben aplicar para reducir los riesgos a un nivel aceptable.
Gestión de los riesgos
11. Las soluciones de continuidad de servicios Es útil recordar que, cualquiera que sea la solución aplicada, el plan de continuidad de servicios solo prevé asegurar la continuidad de las actividades vitales de la empresa. Por ejemplo, el servicio de pagos no se tendrá en cuenta en el plan de continuidad, ya que es posible que la empresa solicite a su banco que efectúe unas transferencias de salario equivalentes a las del mes anterior.
En cambio, los servicios relacionados con la producción formarán parte del plan de continuidad de servicios.
a. No hacer nada Paradójicamente, esta es la solución adoptada por la gran mayoría de las empresas. Las razones de esta elección son, esencialmente, el coste estimado de la puesta en marcha de un plan de continuidad de servicios y la dificultad de esa puesta en marcha. Esto también significa que la empresa no ha realizado un estudio de los costes efectivos de un siniestro, y que estos costes no se han cotejado con los costes de puesta en marcha de un plan de continuidad de servicios.
b. Solución temporal manual Esta solución se utiliza en empresas pequeñas. Normalmente consiste en almacenar las copias de seguridad en una ubicación más o menos segura. Si no hay disponible ningún equipamiento informático, se prevé volver al trabajo directamente en papel. No hay plan de continuidad de servicios. Esto también significa que, como en la solución anterior, la empresa no ha estudiado realmente los costes efectivos de un siniestro y que estos costes no se han cotejado con los costes de puesta en marcha de un plan de continuidad de servicios.
c. Acuerdos recíprocos Esta solución se usa por los PME y consiste en acuerdos, formalizados o no, entre dos empresas próximas la una a la otra. Estas empresas tienen tamaños relativamente similares y utilizan, en parte, software similar. Esta solución se puede poner en práctica de manera sencilla, pero no responde realmente a una necesidad de continuidad de servicios. De hecho, solo tiene valor en el contexto de un siniestro puramente informático. Si hablamos de siniestro de tipo natural (geográfico o climático), esta solución no tiene ningún valor, ya que no se podrá aplicar. Por ejemplo, en las inundaciones sufridas en la ciudad de Nueva Orleans, provocadas en el año 2005 por el huracán Katrina, toda la zona de actividad estaba inundada, lo que hacía imposible la puesta en marcha de esta solución. La situación será la misma en caso de siniestro eléctrico, salvo que el acuerdo se realizara con una empresa físicamente distante.
d. Soluciones comerciales de continuidad Existen varias soluciones comerciales que permiten la puesta en marcha de un plan de continuidad de servicios.
Algunas empresas, debido a su tamaño, pueden poner en marcha un plan de continuidad de servicios de manera interna, ya que disponen de varios centros informáticos en regiones diferentes. En los dos casos, se pueden poner en práctica los siguientes modelos.
Soluciones de hardware Existen varias ofertas de soluciones de hardware:
Alquiler de camión con un equipamiento básico, que se pone a disposición bajo demanda.
Alquiler de salas blancas compartidas: en este tipo de contrato, varias empresas comparten una sala blanca. Actualmente, lo normal es que haya cuatro o cinco empresas por contrato. En este tipo de contrato, es la primera empresa que la solicita la que se podrá beneficiar de esta sala. Normalmente, la empresa continuará utilizando esta sala durante un máximo de 21 días. Si otra empresa necesita la sala, deberá esperar el fin del periodo de 21 días para poder disponer de ella. Estadísticamente, la posibilidad de ver dos empresas solicitando la sala al mismo tiempo es muy baja, casi improbable. Por lo tanto, esta solución es aceptable.
Alquiler de sala blanca asignada: en este caso, la empresa alquila una sala blanca a una empresa especializada. Esta empresa dispone de esta sala permanentemente y, de esta manera, puede equiparla de forma anticipada, para reducir el plazo de puesta en marcha con posterioridad a un siniestro. Esta solución es muy costosa, lo que explica las reticencias de muchas empresas.
Ubicación de seguridad propiedad de la empresa: en este caso la empresa decide equipar una sala en una ubicación distante para hacer de ella una ubicación de respaldo. De nuevo, la empresa podrá equipar con antelación la ubicación de respaldo.
Ubicación espejo: en este caso, la empresa va a poner en marcha una solución de redundancia/mirroring entre dos ubicaciones. Si una de las ubicaciones cae, la otra puede responder a las operaciones sin demora. Hoy en día, solo los grandes grupos son capaces de poner en práctica una solución como esta.
e. Los diferentes tipos de recuperación Recuperación gradual También llamada recuperación progresiva o Cold stand-by, esta solución prevé una recuperación en un plazo de más de 72 horas. Esta solución suele estar vinculada con un tipo de plataforma de seguridad: alquiler de camión equipado o alquiler de sala blanca compartida.
Recuperación intermedia Llamada recuperación intermedia o Warm stand-by, esta solución prevé una recuperación en un plazo comprendido entre 24 y 72 horas. Con esta solución, la empresa se va a organizar para poner en marcha su ubicación de respaldo lo más rápidamente posible. Es necesario tener en cuenta que, aunque la sala blanca esté equipada con anterioridad, esta no podrá estar operativa de manera inmediata. Esto incluye la actualización del sistema de información con los datos de la última versión de la copia de seguridad, lo que requiere tiempo.
Recuperación inmediata Llamada también Hot stand-by, esta solución prevé una recuperación en un plazo de menos de 24 horas. Con esta solución la empresa se va a organizar para poner en marcha su ubicación de respaldo lo más rápidamente posible, en menos de 24 horas. Esto implica que se debe realizar una actualización diaria de los datos de la ubicación de respaldo.
f. Plan de recuperación genérico A continuación proporcionamos un ejemplo de lo que podría contener un plan de recuperación:
Introducción
Entrada en producción
Roles y responsabilidades
Estrategia de recuperación
Activación
Personal de recuperación
Dependencias
Lista de verificación del equipo de recuperación
Condiciones de vuelta a la normalidad
12. Precauciones que hay que tener La puesta en marcha de un plan de continuidad de servicios informáticos implica tomar algunas precauciones. La primera es saber que se debe tratar de un proyecto completo. Para ser operativo, el plan de recuperación se debe poner en práctica por parte de un equipo claramente identificado. Este equipo debe seguir obligatoriamente una formación para que cada uno de los empleados sepa con exactitud qué debe hacer y cuándo debe hacerlo. Se deben realizar pruebas obligatoriamente. En función de la empresa, estas pruebas se deben llevar a cabo como mínimo todos los meses. Las pruebas se deben realizar en condiciones lo más cercanas posible a la realidad. Algunas empresas no dudan en hacer las pruebas a gran escala: se interrumpe el sistema operativo para bascular hacia la ubicación de respaldo. Es cierto que, en este caso, la empresa asume un riesgo, pero ¿no es este riesgo inferior al hecho de descubrir un funcionamiento incorrecto más importante el día que se produzca un verdadero siniestro?
De manera obligatoria, se debe realizar un balance al final de cada prueba. Las modificaciones identificadas deben dar lugar a peticiones de cambio.
13. Beneficios y dificultades a. Beneficios Los beneficios de la gestión de la continuidad son numerosos, pero, si hay uno que vale la pena destacar sobre los demás, es que la supervivencia de la empresa, en caso de siniestro grave, a menudo depende de la puesta en marcha de este proceso.
b. Dificultades potenciales La dificultad más importante para poner en marcha este proceso consiste en obtener un acuerdo con las partes encargadas de la generación de la estrategia y la gestión financiera.
Gestión de la seguridad 1. Enfoque En esta sección vamos a ver cómo se asegura la seguridad informática a nivel de la organización TI. La eficacia de este proceso es importante para garantizar la calidad de la información proporcionada por la organización TI, y también el nivel de calidad del suministro de servicios. Se deben abordar los diferentes riesgos relacionados con el uso, acceso o almacenamiento de los datos, definiendo y poniendo en práctica políticas para ello.
2. ¿Por qué una gestión de la seguridad? Hoy en día, la gestión de seguridad es una necesidad y una obligación para todas las empresas. Se debe definir y poner en práctica una política de seguridad. Su puesta en marcha debe garantizar que satisfaga las necesidades del negocio, así como las de la organización TI. La gestión de la seguridad debe sensibilizar sobre el cumplimiento de las normas de seguridad, tanto a las personas de la organización TI como a los usuarios de los servicios proporcionados por la organización TI. La gestión de la seguridad se debe asegurar de que los proveedores del servicio comprenden y aplican las políticas de seguridad. La gestión de la seguridad debe gestionar todos los aspectos relativos a las tecnologías de la información, la seguridad informática, la seguridad de los accesos y la gestión de documentos. La gestión de la seguridad es una parte importante para la noción de garantía de un servicio y esto está relacionado con la definición de la calidad del servicio. La gestión de la seguridad se debe considerar como una parte de la gestión de la empresa.
La seguridad, como la calidad, debe ser un estado de ánimo que hay que mostrar todos los días.
3. Objetivos del proceso Los principales objetivos del proceso de gestión de la seguridad son los siguientes:
Proteger la información frente a fallos, respetando la confidencialidad, integridad y disponibilidad (regla CIA).
Satisfacer los requerimientos de seguridad acordados en los SLA, OLA y UC.
Satisfacer los requerimientos legales.
Garantizar un nivel de seguridad (referencia de seguridad, autenticidad y no rechazo).
Las políticas de seguridad se definen en el proceso de gestión de la seguridad. La puesta en marcha de estas políticas se lleva a cabo en el proceso de gestión de la disponibilidad y en el centro de servicios.
4. Definición No hay una definición especial para este proceso, aparte de la definición de la regla CIA que se describió en la sección Seguridad - Concepto CIA.
5. Perímetro La gestión de la seguridad tiene a su cargo el conjunto de la organización TI y de la infraestructura informática. La seguridad informática se refiere al conjunto del perímetro de la infraestructura informática. La seguridad también implica el respecto de la legalidad (reglas y políticas). La seguridad también debe tener en cuenta las obligaciones definidas por el cliente en los SLA. La seguridad se refiere no sólo a los sistemas y datos, sino también a los accesos y a las personas. Se debe tener en cuenta el conjunto lógico y físico de la organización TI.
6. Roles Los roles principales son los siguientes:
Responsable de la seguridad.
Propietario del proceso.
7. Indicadores Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:
Número de incidencias de seguridad.
Tiempo de no disponibilidad debido a una incidencia de seguridad.
Número de no disponibilidades debido a incidencias de seguridad...
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión de la seguridad
9. Conceptos básicos a. Confidencialidad, Integridad y Disponibilidad (CIA) Este concepto hace referencia a la seguridad de los datos. Confidencialidad, Integridad y Disponibilidad = Confidentiality, Integrity, Availability La sigla CIA significa: Confidentiality: solo las personas autorizadas pueden acceder a los datos. Integrity: los datos deben estar íntegros en el momento en que se entregan. Availability: los datos deben estar disponibles en el momento en que se necesitan.
La gestión de la seguridad es responsable de definir las políticas de seguridad de la empresa y asegurar su conformidad con las directrices de seguridad, en el seno de las organizaciones TI.
Definiciones de ejemplo Confidencialidad
High: datos personales bajo protección (Data Protection Act/CNIL), datos médicos e información estratégica.
Medium: internos, no deben salir de la empresa.
Low: externos, todo lo que está autorizado a salir.
Integridad
High: transacciones financieras, software y datos personales.
Medium: información dirección).
Low: sin requerimientos.
de
medidas
e
información
de
identificación
(nombre,
Disponibilidad
High: 24 horas al día, 99,5%.
Medium: de 07:00 a 19:00, 99%.
Low: sin requerimiento.
b. Las actividades y responsabilidades Estratégica La definición de las políticas de seguridad se establece a nivel estratégico.
Táctica Las actividades a nivel táctico son las siguientes:
Establecimiento de los niveles de seguridad en las SLA y suministro de servicios, respetando los acuerdos.
Implantación de las medidas de seguridad para controlar disponibilidad): Confidencialidad/Integridad/Disponibilidad.
(gestión
de
la
Operativa Las actividades a nivel operativo son las siguientes:
Establecer las relaciones importantes con los otros procesos.
Responder a las incidencias de seguridad de manera adecuada (gestión de las incidencias y problemas).
Participación en el análisis de impacto de los RFC.
Puesta en marcha segura de los cambios (gestión de las entradas en producción).
Aplicación de la Rueda de Deming Las actividades de este proceso concuerdan con el modo tradicional de funcionamiento de los procesos. Es una aplicación del principio de la Rueda de Deming.
Rueda de Deming aplicada a la seguridad
c. Ciclo de vida de una incidencia de seguridad El tratamiento de una incidencia de seguridad se lleva a cabo a través del proceso de gestión de las incidencias. En función de su importancia, esta incidencia puede activar la creación de un problema. En función de los resultados del análisis, esto puede dar lugar a una petición de cambio, incluso a una petición de cambio urgente. Esto también puede dar lugar a la creación de nuevas reglas de seguridad para evitar que este tipo de incidencias de seguridad se vuelvan a producir.
Ciclo de vida de una incidencia de seguridad
10. Beneficios y dificultades a. Beneficios La puesta en marcha de la gestión de la seguridad permite proteger la empresa contra las amenazas y ataques que provengan tanto del interior como del exterior de esta. El coste de la puesta en marcha de este proceso puede parecer elevado pero, en vista de los costes que la empresa tendría que soportar en caso de siniestro causado por un fallo de seguridad, pérdida o corrupción de archivos o accesos no autorizados a información vital de la empresa, este coste es muy razonable.
b. Dificultades potenciales La puesta en marcha de este proceso se enfrenta a menudo con la dificultad de gestión de los códigos de acceso. ¿Cómo implementar una política de seguridad sobre los derechos de acceso y conseguir que los usuarios respeten esta política? Una complicación excesiva de los códigos implica a menudo una reacción bien conocida por todos: se anota el código en un Post-it y se deja en el cajón, sobre el teclado o en la pantalla. Por lo tanto, es necesario conseguir la adhesión del personal a esta política. La gestión de la seguridad, al menos en las empresas grandes y medianas, se convierte en un trabajo a tiempo completo que requiere una formación especial. Es cierto que, en el caso de las empresas pequeñas, el establecimiento de este proceso se simplifica, ya que el tamaño del perímetro que hay que proteger es un elemento importante.
Gestión de los proveedores
1. Enfoque En esta sección vamos a ver cómo se asegura la gestión de los proveedores. Este proceso es importante, ya que permite garantizar la calidad del servicio.
2. ¿Por qué una gestión de los proveedores? La elección de un proveedor no se puede hacer basándose únicamente en el precio. De hecho, es imprescindible que la calidad del servicio de la organización TI no se pueda poner en peligro como consecuencia de un fallo de un proveedor. Para evitar esto, es necesario asegurar un seguimiento del proveedor. Fundamentalmente, esto se hace, pero solo en parte, a través de los contratos de tipo UC (Underpinning Contract).
3. Objetivos del proceso Los principales objetivos del proceso de gestión de los proveedores son los siguientes:
Negociar los contratos y firmarlos.
Asegurar el seguimiento del funcionamiento de los contratos.
Asegurar una buena relación calidad/precio.
Asegurar que se gestionan los proveedores y los servicios.
Garantizar que los contratos se alinean con las necesidades de la empresa.
Asegurar que los contratos están alineados con los objetivos de los SLA.
Definir y mantener una política para proveedores.
4. Definición No hay definición particular para este proceso.
5. Perímetro La gestión de proveedores tiene que ver con las relaciones entre la organización TI y el proveedor (también llamado subcontratista).
6. Roles Los roles principales son los siguientes:
Responsable de los proveedores.
Propietario del proceso.
7. Indicadores Se pueden emplear varios indicadores para medir el funcionamiento del proceso, que se pueden aplicar al conjunto de la producción informática o a nivel de cada servicio:
Número de incidencias en el suministro de los servicios.
Tiempo de no disponibilidad debido a una incidencia en el suministro del servicio.
Número de no disponibilidades debidas a una incidencia en el suministro del servicio...
Es necesario añadir a esta lista los indicadores definidos en el contrato de tipo UC, firmado entre el proveedor y la organización TI. Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión de los proveedores
9. Conceptos básicos a. Negociaciones antes de la firma del contrato La puesta en marcha de este proceso permite negociar los contratos y obtener una relación calidad/precio ventajosa por parte de los proveedores. También es necesario estar seguros de que los contratos de subcontratación y los acuerdos con los proveedores están alineados con las necesidades de la empresa y que se apoyan y siguen los objetivos acordados en los SLA y los SLR, de forma conjunta con el responsable de los niveles de servicio (Service Level Manager). El responsable del proceso deberá negociar y acordar los contratos con los proveedores.
b. Después de la firma del contrato El responsable del proceso deberá gestionar las relaciones con los proveedores y asegurar que el rendimiento de los proveedores se mantiene acorde con sus compromisos.
Debe mantener una política de proveedores y respaldar las bases de datos de contratos y proveedores (SCD - Supplier & Contracts Database). El responsable del proceso deberá asegurar la categorización de los proveedores y el mantenimiento de la base de datos de proveedores y contratos (SCD). El seguimiento de los contratos incluye una evaluación anual de los resultados. Al final del contrato, la decisión de su renovación o no se deberá tomar en función de los resultados globales obtenidos a lo largo de la duración del contrato.
10. Beneficios y dificultades a. Beneficios La gestión de los proveedores permite un seguimiento más eficaz de estos, así como garantizar que se cumplen los acuerdos de servicio definidos (SLA y OLA).
b. Dificultades potenciales No hay dificultades potenciales para la puesta en marcha de este proceso.
LOS PROCESOS DE LA TRANSICION DE LOS SERVICIOS La fase de los procesos de transición de servicios 1. ¿Por qué una transición de servicios? Como hemos visto en el capítulo de presentación de la norma, ITIL está dividido en procesos estratégicos, tácticos y operativos.
Los niveles decisionales de la gestión de servicios Los procesos de transición de servicios se sitúan al mismo tiempo en la parte táctica y en la parte operativa.
Este posicionamiento, que puede sorprender, resulta sin embargo lógico, ya que el rol de los procesos de esta fase es proporcionar un vínculo entre los procesos que elaboran los servicios y los procesos de explotación que entregan los servicios. Uno de los objetivos de la transición de servicios es asegurar que la puesta en marcha de un cambio no tiene un impacto negativo en la calidad de los servicios proporcionados por la organización. La transición de servicios se basa en dos procesos principales:
La gestión de los activos de servicio y configuraciones.
La gestión de cambios.
Para una mayor eficacia, es deseable que estos dos procesos se pongan en marcha al mismo tiempo.
2. Los objetivos de la transición de servicios El objetivo de la transición de servicios es asegurar que los servicios nuevos, modificados o eliminados, corresponden a las expectativas del negocio, tal y como se documentan en las fases de estrategia y diseño de servicios. Los objetivos principales son los siguientes:
Planificar y gestionar los cambios de manera eficaz.
Gestionar los riesgos relacionados con el cambio de un servicio (nuevo, modificado o eliminado).
Asegurar el éxito del despliegue de los cambios.
Asegurar que los cambios generan valor para el negocio.
Proporcionar un buen conocimiento de los servicios y de los activos de los servicios.
3. El perímetro de la transición de los servicios La fase de transición debe dar consejos a las fases de diseño y mejora continua de los servicios. Debe permitir una mejora en cuanto a la capacidad para poner en marcha un servicio nuevo o modificado o eliminar uno existente. Esto incluye la planificación, la construcción, la prueba, la evaluación y el despliegue del cambio.
4. Los procesos de transición de servicios
Gestión de la transición, planificación y soporte.
Gestión de los activos de servicio y configuraciones.
Gestión de cambios.
Gestión de las entradas en producción.
Validación del servicio y de las pruebas.
Evaluación.
Gestión del conocimiento.
Gestión de la transición, planificación y soporte 1. Enfoque Este proceso es esencial para el correcto funcionamiento del conjunto de procesos de la fase de transición, ya que garantiza la visión global y asegura y coordina los recursos necesarios para cumplir los compromisos de esta fase.
2. Objetivos del proceso Los principales objetivos del proceso de gestión de la transición son los siguientes:
Planificar y coordinar los recursos.
Coordinar las actividades de los diferentes actores.
Poner en marcha servicios nuevos o modificados.
Retirar todos los elementos que forman parte de un servicio eliminado.
Poner en marcha todas las modificaciones que tienen que ver con el entorno informático.
Identificar y gestionar los riesgos para limitar los errores en el funcionamiento durante la fase de transición.
Controlar y mejorar el rendimiento de las actividades de la fase de transición.
3. Perímetro del proceso En este proceso, el perímetro de las actividades incluye el mantenimiento de las políticas, las normas y los modelos para el conjunto de actividades y procesos de la fase de transición. La gestión de la transición también tiene que coordinar los esfuerzos necesarios para poner en marcha varios cambios en un mismo periodo. Asimismo hay que priorizar los requerimientos, algunas veces contradictorios. Por supuesto, se debe aplicar la mejora continua de los procesos de esta fase.
4. Descripción del proceso y las relaciones principales
El proceso de transición, planificación y soporte
5. Conceptos básicos El diseño de los servicios, en coordinación con el cliente y los proveedores de los servicios, internos y externos, desarrolla el servicio. Para esto, se basa en el empaquetado de servicios (SDP - Service Design Package). El empaquetado de servicios es un requisito previo para la fase de transición. Se puede leer una descripción de un paquete de servicios en la descripción del proceso de gestión del porfolio de servicios (fase de estrategia).
Atención: este proceso no es responsable de la planificación de la construcción, las pruebas y el despliegue de un cambio. Estas actividades se gestionan en el marco del proceso de gestión de cambios.
6. Preparación para la transición La transición necesita la puesta en marcha de varias actividades previas al cambio. A continuación se enumeran algunos ejemplos de estas actividades:
Revisar y aceptar los elementos de entrada que provengan de las otras fases del ciclo de vida.
Revisar y controlar los elementos esperados: la demanda de empaquetado de servicios y los criterios de aceptación del servicio.
cambios,
el
Asegurar que se crea una base de referencia para permitir una eventual vuelta atrás.
Gestión de los activos de servicio y configuraciones 1. Enfoque En esta sección vamos a ver cómo se gestionan los activos, así como cuál es la base de la gestión de los activos de servicio y configuraciones (SACM): cómo se gestionan las relaciones entre los elementos de configuración.
Atención: normalmente se habla de gestión de configuraciones, que es la definición del proceso en la versión 2 de ITIL; esto es así por una sencilla cuestión de simplificación terminológica.
2. ¿Por qué una gestión de los activos de servicio y de las configuraciones? La gestión de los activos, a menudo llamada Asset Management, no es suficiente para describir el conjunto de componentes de un sistema de información. Para asegurar su gestión de manera efectiva, es imprescindible tener la información completa y precisa de la infraestructura entera del sistema de información y del conjunto de sus componentes. Si los servicios no se entregan en las condiciones definidas en los contratos de servicio, la organización puede sufrir pérdidas importantes. Debido al papel que desempeñan estos activos en el soporte a la prestación de calidad del servicio, el valor real de los activos informáticos es normalmente superior a su valor presupuestario.
3. Objetivos del proceso Los objetivos principales del proceso de gestión de configuraciones son los siguientes:
Optimizar los activos de servicios.
Garantizar la integridad de los elementos de configuración y las configuraciones necesarias para mantener un CMS (Configuration Management System) operativo.
Dar asistencia a la gestión eficaz de los servicios TI: Proporcionando un modelo lógico de la infraestructura de los TI y de los servicios TI. Aportando una base sólida a la gestión de incidencias, la gestión de problemas, la gestión de cambios y las entradas en producción.
4. Definiciones Activo: es un componente de un proceso de negocio:
Proceso
Organización
Personal
Información
Software
Infraestructura
Capital financiero
Elemento de Configuración (CI - Configuration Item): es un activo, componente de servicio u otro elemento que está, o estará, bajo el control del proceso de gestión de activos y configuraciones. Los elementos de configuración varían en complejidad, tamaño y tipo, y van desde un servicio o sistema entero, incluidos el hardware, software, documentación y personal de soporte, hasta un simple módulo de software o un componente de hardware sin importancia. DML (Definitive Media Library): los diferentes CD de las versiones definitivas y autorizadas de todos los CI de software se registran en la biblioteca. En realidad esta zona de almacenamiento puede estar formada por una o varias bibliotecas lógicas o físicas. En la versión 2 de ITIL se habla de DSL (Definitive Storage Library). DHS (Definitive Hardware Storage): lugares de almacenamiento de los equipos principales. CMS (Configuration Management System): sistema de gestión de configuraciones. El sistema de gestión de configuraciones contiene toda la información para todos los CI incluidos en el perímetro definido. La CMS tiene en cuenta los datos de varias bases de gestión de configuraciones (CMDB), que en conjunto forman una federación CMS. En la versión 2 de ITIL se habla de CMDB (Configuration Management Data Base), y actualmente, por analogía, muchas personas continúan hablando de CMDB en lugar de CMS. Baseline: configuración de referencia.
5. Perímetro La gestión de activos de servicio y configuraciones tiene a su cargo:
La gestión de los activos a los que se hace referencia en la gestión de los activos de servicios y configuraciones.
La gestión de las relaciones entre los elementos.
La gestión de la documentación asociada a estos elementos.
6. Roles Los roles principales son los siguientes:
Responsable de los activos de servicio y configuraciones.
Responsable de los activos.
Propietario del proceso.
7. Indicadores Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:
Número de CI creados.
Número de CI modificados.
Número de CI archivados.
Número de errores en la identificación de los CI...
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso y las principales relaciones
El proceso de gestión de activos de servicio y configuraciones
9. Conceptos básicos a. El ciclo de vida de un CI El ciclo de vida de un CI está definido por cinco actividades que se detallan a continuación:
El ciclo de vida de un CI
b. Las actividades de la gestión de configuraciones Las principales actividades de la gestión de los activos de servicio y configuraciones son las siguientes:
Planificación La primera etapa del proceso consiste en la redacción de las especificaciones del proyecto y la planificación de su puesta en marcha. Las estimaciones deben incluir la definición del perímetro, los objetivos, las reglas y los procedimientos, el contexto técnico y organizativo del proceso de la gestión de activos de servicio y configuraciones.
Identificación Durante la segunda etapa, hay que seleccionar e identificar todos los CI de la infraestructura. Esta identificación debe incluir los elementos siguientes: su propietario, relaciones y documentación asociada. Para cada CI, hay que definir un identificador único y, para alguno de ellos, un número de versión. Esta etapa termina etiquetando cada elemento y guardándolo en la CMS.
Control La actividad de control consiste en asegurar que solo se aceptan y registran los CI autorizados e identificados, desde su recepción hasta su destrucción. Esta actividad permite asegurar que ningún CI se añade, modifica, sustituye o elimina sin que haya una petición de cambios aprobada (ver sección sobre gestión de cambios).
Gestión del estado A lo largo de todo su ciclo de vida, un CI es objeto de un seguimiento en lo que respecta a todos los datos actuales y pasados que tienen que ver con él. Este seguimiento permite conocer la evolución del estado del CI, fundamentalmente a través de los cambios aprobados y las entradas en producción.
Verificación y auditoría Además de las acciones de seguimiento, es imprescindible efectuar una serie de revisiones y auditorías que permitan verificar la existencia real de los CI y asegurar que se registran correctamente en el sistema de gestión de activos de servicio y configuraciones.
c. ¿Qué contiene la CMS? La CMS debe contener todos los elementos de la infraestructura identificados. Es necesario definir los atributos y relaciones de cada CI.
Contenido de la CMS
Granularidad de la CMS El punto más importante de la puesta en marcha de una CMS es la definición de la granularidad de la base de datos. Es necesario tener cuidado en el momento de definir esta granularidad (ver la siguiente sección: Beneficios y dificultades - Dificultades potenciales):
Si es demasiado larga, faltará información importante.
Si es demasiado fina, la gestión de la base será especialmente difícil.
Ejemplo: Si es demasiado larga: si la base de datos solo contiene los servidores, falta información relativa a los puestos de trabajo conectados a estos servidores. Si es demasiado fina: ¿para qué sirve registrar y, sobre todo, gestionar el ratón del puesto de trabajo, cuando hoy este tipo de hardware se considera como un consumible? En principio, el establecimiento de una CMS es bastante fácil, basta con registrar los CI. En la realidad, las cosas no son tan simples. La dificultad principal reside en mantener la integridad de la base. Si la granularidad es demasiado fina, será difícil mantener su integridad, ya que su actualización resultará muy difícil.
Los atributos de un CI Para cada elemento de configuración (CI), es imprescindible registrar un determinado número de atributos y las relaciones existentes entre los diferentes CI.
Recordemos que un atributo es una información relativa a un CI (ver capítulo Anexos Atributos de un CI). Normalmente encontramos tres tipos de atributos: Atributos técnicos:
Características técnicas.
Puesta en producción: manual o automática con herramientas de auto-diagnóstico.
Atributos administrativos:
Ciclo de vida (cambios, incidencias...).
Puesta en producción: manual o automática si se integran con los otros procesos.
Atributos contables:
Tarifas, mantenimiento y licencia.
Origen: manual.
Las relaciones de los CI Además de los atributos, para cada CI es necesario definir las relaciones que van a unirle con los otros CI. Las relaciones se definen mediante las uniones (lógicas o físicas) entre los diferentes CI de la infraestructura.
d. Configuración de referencia La literatura ITIL habla de Baseline, lo que podemos traducir por «Configuración de referencia». Una configuración de referencia es la imagen de un CI o de un grupo de CI tomados en un momento concreto con el fin de comparar, o como punto de retorno. Una configuración de referencia es utilizada normalmente por el proceso de gestión de cambios, para permitir una marcha atrás en caso de problemas en la puesta en producción de un cambio.
Variante Es posible definir una versión ligeramente diferente de un CI o de una configuración de referencia. Esto se llama variante.
10. Beneficios y dificultades a. Gestión de licencias Las empresas se encuentran frecuentemente con el problema de la gestión de las licencias de software. Debido a los diferentes medios de adquisición de software disponibles hoy día, ofertas multilicencia, licencia de empresa y descarga individual en Internet, es difícil controlar las compras.
El control y la auditoría del software están bajo la responsabilidad del proceso de la gestión de activos y configuraciones, mientras que las políticas de adquisición e instalación deben estar bajo la responsabilidad del proceso de gestión de seguridad.
La ley hace responsables a los directivos de la empresa en caso de uso fraudulento de software. Estos corren el riesgo de penas de prisión si el software adquirido ilegalmente se utiliza en la empresa. El proceso de gestión de activos de servicio y configuraciones permite a la organización supervisar y controlar las licencias del software, desde su compra hasta la retirada de su explotación.
b. Beneficios El proceso de gestión de activos de servicio y configuraciones permite un suministro económico y eficaz de los servicios informáticos. Entre los beneficios que aporta la gestión de activos de servicio y configuraciones, se pueden enumerar:
Gestión y control de los CI de valor: permite controlar el uso de estos elementos, a quién han sido confiados y si el inventario actual se corresponde con el inventario oficial.
Suministro de información sobre los CI y su documentación para mantener todos los procesos de gestión de servicios, de entradas en producción, de cambios, de incidencias, de problemas, de capacidad y de seguridad.
Aportando a un proceso de gestión de problemas los datos sobre las tendencias: la información de la gestión de activos de servicio y configuraciones se asociará a las tendencias de los problemas aparecidos sobre los tipos particulares de CI. Esta información de tendencia en relación con los problemas permite una prevención proactiva de problemas.
Soporte al proceso de gestión de cambios: la información de gestión de activos y configuraciones permite realizar un análisis de impacto y planificar los cambios con total seguridad, eficacia y efectividad. Esto limita el impacto de los cambios sobre el entorno de producción.
Soporte al proceso de gestión de entradas en producción: la información de gestión de activos de servicio y configuraciones contribuye a la integridad del sistema de información, aportando información sobre las versiones de los CI y los cambios que forman parte de la entrada en producción.
Soporte al proceso de la continuidad de servicios: la CMS, las bibliotecas seguras y las reservadas con seguridad ayudan a la restauración de los servicios informáticos después de un fallo, identificando los CI necesarios y su localización.
Soporte al proceso de gestión financiera: es fácil, a partir de la gestión de activos de servicio y configuraciones, establecer una lista completa de los CI. A partir de esta lista, se pueden deducir los costes esperados de mantenimiento y los derechos de licencia, los contratos de mantenimiento, las fechas de renovación de licencias, las fechas de fin de vida de los CI y los costes de sustitución (con la condición de que esta información se conserve).
Respeto a las obligaciones legales: la gestión de los activos de servicio y configuraciones conserva un inventario de todos los elementos de software de la infraestructura informática. Las copias ilegales de software se pueden identificar fácilmente, con el objetivo de ser regularizadas, borradas o destruidas.
c. Dificultades potenciales Las dificultades potenciales que puede encontrar el proceso de gestión de activos y configuraciones son:
El proyecto que se ha puesto en marcha no está bien controlado: es necesario que las etapas de análisis y diseño estén suficientemente desarrolladas, pues en caso contrario el resultado final no será el esperado. Cuando los cambios y entradas en producción se planifican, es necesario tener en cuenta el tiempo dedicado a las actividades de gestión de activos y configuraciones.
Puesta en marcha de manera aislada: si la gestión de activos y configuraciones se pone en marcha de manera aislada, sin proceso de gestión de cambios o proceso de gestión de entradas en producción, será menos eficaz y puede que no se logren los resultados esperados.
Incorrecta definición del CI: el nivel de detalle es demasiado elevado (en este caso, se le pidió al personal un trabajo innecesario) o demasiado bajo (en este caso, el control es insuficiente).
El alcance del proceso: si el proceso se percibe como demasiado burocrático o rígido, las personas intentarán eludir la gestión de activos y configuraciones para ganar tiempo o simplemente por malicia. Entonces será necesario emprender acciones de información y formación para conseguir la adhesión de estas personas.
Ineficacia del proceso: el proceso puede ser ineficaz y una fuente de errores cuando se gestiona de manera manual. Hoy en día, las herramientas disponibles tienen buenas prestaciones y permiten la recuperación automática de la información. Sin embargo, pueden aparecer problemas cuando la herramienta de gestión de activos y configuraciones no permite considerar las nuevas funcionalidades o no soporta todas las categorías de CI.
Falta de compromiso de la dirección: sin un fuerte compromiso por parte de los dirigentes por respetarlo, el proceso de gestión de activos y configuraciones será muy difícil de llevar a cabo.
Gestión de cambios 1. Enfoque En esta sección vamos a ver cómo se gestionan los cambios y el impacto positivo que puede tener la gestión de cambios en la calidad de los servicios de la organización. Veremos que la eficacia de este proceso depende mucho de la calidad de la gestión de configuraciones.
2. ¿Por qué una gestión de cambios? Actualmente estamos en un mundo cambiante. Todo evoluciona: las necesidades de las empresas, las tecnologías, los servicios... Las organizaciones TI se deben adaptar a todos estos cambios.
Sin embargo, estos cambios no deben tener un impacto negativo en la entrega de los servicios ni en su calidad. Para dar una respuesta satisfactoria, es indispensable tener una estrategia de evaluación de riesgos. En la gestión de riesgos, hay que incluir la gestión de recursos, la continuidad del servicio, el impacto financiero y el impacto en la calidad del servicio prestado. Cuando se pone en marcha un cambio, es necesario que sea operativo inmediatamente, es decir, durante la primera ocurrencia. Además, todas las personas que intervienen deben recibir una comunicación apropiada y en plazos útiles para todos los cambios que les afectan. El porfolio de servicios proporciona una definición clara de todos los servicios que están en el pipeline, activos o eliminados. La comprensión del porfolio de servicios ayuda a las partes implicadas en la transición a entender los impactos potenciales en un servicio nuevo o modificado y sobre los otros servicios. Es esto lo que permitirá efectuar los cambios que garanticen un equilibrio entre la necesidad de cambios y el impacto de estos en los servicios. Para asegurar una gestión de cambios eficaz, es indispensable tener información completa y precisa de la infraestructura del sistema de información y el conjunto de sus componentes. Se trata del rol de gestión de configuraciones que hemos visto anteriormente. Por esta razón, es aconsejable poner en marcha estos dos procesos de manera simultánea. Finalmente, es importante tener siempre en mente la idea de que todo cambio (adición, modificación o eliminación de un componente) en la infraestructura informática se debe tener en cuentaobligatoriamente por la gestión de cambios antes de aplicarse.
3. Objetivos del proceso Los objetivos principales del proceso de gestión de cambios son los siguientes:
Asegurar que se utilizan los métodos y los procedimientos estándares para un tratamiento eficaz y rápido de todos los cambios, de manera que se minimice el impacto de todos los incidentes relacionados con los servicios.
Garantizar que todos los cambios son: Registrados, examinados, priorizados. Autorizados. Planificados. Probados. Aplicados. Documentados.
Revisados.
Optimizar los riesgos de negocio: algunas veces, no hacer nada es un riesgo superior al de poner en marcha un cambio que implique un riesgo, pero también un beneficio potencial.
4. Definiciones Cambios: es la adición, modificación o eliminación de un CI o de una configuración de referencia. RFC (Request For Change): formulario que se utiliza para describir un cambio solicitado. Cambio estándar: un cambio relativamente común, autorizado de forma previa por el cliente, cuyos impactos, costes y riesgos son conocidos y que implica un procedimiento de tratamiento establecido. CAB (Change Advisory Board): es una estructura que examina los cambios y asesora al responsable de estos sobre las decisiones que hay que tomar. ECAB (Emergency Change Advisory Board): es una estructura que examina los cambios urgentes y asesora al responsable de los cambios sobre las decisiones que hay que tomar en el ámbito de un cambio urgente. FSC (Forward Scheduled Change): calendario de cambios que contiene los detalles de todos los cambios de infraestructura aprobados para su implantación, con las fechas propuestas de implantación. PIR (Post Implementation Report): revisión posterior a la implantación que verifica que los cambios cumplen sus objetivos, que los clientes están satisfechos y que no ha habido consecuencias negativas. PSA (Project Service Availability): disponibilidad prevista de los servicios, calendario que prevé los periodos de inactividad de los servicios.
5. Perímetro La gestión de cambios se encarga de:
Todos los cambios aportados por el diseño de los servicios.
Todos los cambios aportados por la explotación de los servicios.
Estos cambios pueden incluir:
Hardware
Software
Aplicaciones
Contratos de servicios
Entorno de la organización
Documentos asociados a los diferentes CI
Sistemas de medida (herramientas, métodos y métricas)
Arquitecturas técnicas
6. Roles Los principales roles son los siguientes:
Responsable de los cambios.
Responsable de las entradas en producción.
Propietario del proceso.
Miembro del CAB.
7. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de RFC registrados.
Número de RFC implementados con éxito.
Número de RFC que generaron incidencias.
Número de RFC que generaron problemas.
Número de vueltas atrás.
Número de cambios estándares.
Número de cambios urgentes.
Esta lista no es exhaustiva; convendrá definir los indicadores en función de la estructura que se aplique.
8. Descripción del proceso
El proceso de gestión de cambios
9. Conceptos básicos a. El ciclo de vida de un cambio El ciclo de vida de un cambio se puede definir por ocho actividades principales que se detallan a continuación:
El ciclo de vida de un cambio
b. Los diferentes tipos de cambios Hay tres tipos de petición de cambios:
Petición de cambios normal Es el caso del tratamiento normal de la petición que sigue el conjunto de etapas del ciclo de vida.
Petición de cambios estándar Es una petición previamente autorizada por el cliente. En un primer momento, esta petición se ha tratado en el marco de un cambio normal. Los resultados fueron satisfactorios (el PIR no indica ninguna dificultad de puesta en marcha y no hay impacto negativo sobre los servicios), se conviene con el cliente que es posible realizar todas las peticiones de este tipo de manera simplificada (ya que han sido descritas y validadas). Por ejemplo: petición de instalación de un puesto de trabajo estándar. Con frecuencia, este tipo de peticiones se tratan directamente por el centro de servicios. Sin embargo, el responsable de los cambios debe informar al CAB de los cambios estándares, después de la oportuna revisión.
Petición de cambios urgente Es una petición que se debe poner en marcha rápidamente. En este caso, se simplifican un determinado número de etapas o estas no se realizan. Este tipo de cambios debe ser excepcional.
c. Impacto de los cambios Menor En caso de un impacto menor, el responsable de los cambios autoriza el cambio e informa al CAB de la acción emprendida.
Significativo Cuando el cambio tiene un nivel significativo en términos de impacto o de recursos, el responsable de los cambios envía al CAB el conjunto de elementos relativos a la petición para su evaluación. La evaluación del CAB tiene en cuenta el impacto sobre las infraestructuras, los recursos y la planificación de la puesta en marcha. El CAB asesora al responsable de los cambios.
Importante En caso de un impacto importante o de coste significativo, el responsable de los cambios transmite el cambio a la dirección para pedir consejo. Si el cambio se aprueba, se transmite al CAB para su evaluación. La evaluación del CAB tiene en cuenta el impacto sobre las infraestructuras, los recursos y la planificación de la puesta en marcha. El CAB asesora al responsable de los cambios.
d. Urgencia El responsable de los cambios define la urgencia de la petición:
Inmediata
Riesgo de pérdidas potenciales importantes.
Reunión del ECAB para su evaluación inmediata y toma de decisión rápida, con el objetivo de poner en marcha el cambio lo antes posible.
Asignar un máximo de recursos de manera inmediata para tratar el cambio.
Alta
Impacto fuerte sobre determinados usuarios o impacto sobre un gran número de usuarios.
Definir la prioridad alta para la construcción y puesta en marcha del cambio.
Asignar los recursos necesarios y planificar una rápida entrada en producción.
Media
Sin impacto importante.
Asignar una prioridad media y planificar el cambio para la próxima entrada en producción planificada.
Baja
Cambio justificado, pero sin impacto real sobre la entrega del servicio.
Construir el cambio y planificar para la próxima entrada en producción prevista.
Esta definición solo tiene valor como ejemplo. La tabla se debe definir en función de la organización.
e. El CAB y el ECAB El CAB El CAB es una entidad «de geometría variable». El responsable de los cambios es el que debe definir la composición del CAB, en función del cambio o de los cambios solicitados. De manera ideal, el CAB deberá estar formado por los responsables de proceso, asistidos por los expertos del campo o de las áreas implicadas (por ejemplo: bases de datos, redes, aplicación implicada...). El CAB no se reúne por cada petición de cambios. En términos generales, se fija un plan de revisiones del CAB, durante las que se examinan el conjunto de peticiones de cambio. Previamente a estas revisiones, el responsable de los cambios tendrá que enviar al conjunto de miembros del CAB los elementos que forman parte de cada cambio solicitado. En función del tamaño de la organización, estas revisiones se organizan con la presencia física de los miembros del CAB o por vídeo o teleconferencia.
El ECAB
Como el CAB, el ECAB es una entidad «de geometría variable». Es el responsable de los cambios el que definirá la composición del ECAB, en función de los cambios urgentes solicitados. Normalmente, la composición del ECAB está limitada a dos o tres miembros que ayudarán al responsable de los cambios a tomar una decisión rápida. Por supuesto, no hay planificación de revisiones ECAB. Únicamente la urgencia justifica la creación de un ECAB.
f. Las actividades de la gestión de cambios Una parte de las actividades las realiza el proceso de puesta en producción, que veremos en el capítulo siguiente, pero cuya coordinación está asegurada por la gestión de cambios. Las principales actividades de la gestión de cambios son las siguientes:
Recepción El responsable de la gestión de cambios recibe los RFC que provienen:
De los procesos de explotación de servicios.
De los procesos de diseño de servicios.
De los procesos de la estrategia de servicios.
De manera ideal, debería contener, como mínimo, los siguientes elementos:
El identificador único de la RFC.
Las referencias de las incidencias y problemas relacionados.
La referencia del CI implicado.
La descripción del cambio.
Las razones del cambio.
Las consecuencias potenciales si el cambio no se pone en marcha.
Los datos del solicitante.
La prioridad solicitada.
La estimación del impacto del cambio.
La estimación de los recursos necesarios para la puesta en marcha.
La estimación de los riesgos.
Las posibilidades de marcha atrás.
Si la RFC no se completa de forma correcta, se rechaza automáticamente sin que se registre.
Registro Si la RFC se completa correctamente, se registra.
El tipo de la petición de cambio puede ser:
Normal
Estándar (si todavía no se ha identificado)
Urgente
En función del tipo de cambios, el tratamiento es diferente. Ahora vamos a ver en detalle el tratamiento de una petición normal.
Evaluación Los miembros del CAB examinan los elementos recibidos para cada cambio registrado. Para esta evaluación, deben tener en cuenta los elementos siguientes:
Impacto sobre el servicio implicado.
Impacto sobre los otros servicios.
Impacto sobre las infraestructuras.
Consecuencias en caso de no llevarse a cabo.
Recursos necesarios para la puesta en marcha.
Recursos adicionales necesarios si el cambio se pone en marcha.
Autorización Se habla de autorización o aprobación para poner en marcha un cambio. La única persona habilitada para autorizar o rechazar un cambio es la que haya sido autorizada para el cambio. Generalmente, es el responsable de los cambios. Reúne al CAB o al ECAB para obtener sus evaluaciones y tener en cuenta sus consejos antes de tomar su decisión.
Construcción Esta parte se realiza en el ámbito del proceso de gestión de entradas en producción. La gestión de cambios tiene un papel de coordinación en la construcción de los cambios y en la puesta en producción. Es importante preparar un plan de marcha atrás, especialmente tomando una configuración de referencia (ver sección de Gestión de los activos de servicio y configuraciones). También es necesario elaborar un plan de pruebas. Estas pruebas deben tener en cuenta una prueba unitaria del cambio y una prueba en un entorno lo más cercano posible al entorno de producción.
En el caso de un cambio urgente, en función de la urgencia, puede ser que el plan de vuelta atrás y el plan de pruebas no se estudien ni realicen.
Pruebas Esta parte se realiza en el ámbito del proceso de gestión de entradas en producción. Se debe poner en marcha el plan de pruebas. Estas pruebas deben tener en cuenta los siguientes aspectos:
Impacto sobre el rendimiento del servicio.
Impacto sobre el rendimiento de otros servicios.
Funcionalidad.
Asistencia posible.
Capacidad de mantenimiento.
Fiabilidad y disponibilidad.
Cumplimiento de las reglas de seguridad.
Entrada en producción Esta parte se realiza en el ámbito del proceso de gestión de entradas en producción. Como consecuencia de las etapas anteriores, la gestión de cambios pasa el testigo al proceso de entradas en producción, que veremos en el capítulo siguiente. Como consecuencia de la entrada en producción, se regresa al proceso de gestión de cambios para realizar la última etapa de la gestión de cambios.
Reporting Como consecuencia de la entrada en producción del cambio, es imprescindible hacer balance de la petición de cambio. Esta operación se traduce en la creación de un documento llamado PIR (Post Implementation Review). Durante esta revisión, se deben analizar todos los aspectos técnicos de la puesta en marcha:
Nivel de recursos consumidos en relación con las previsiones.
Tiempo de puesta en marcha en relación con las previsiones.
Dificultades encontradas.
Número de incidencias creadas.
Número de problemas creados.
¿La marcha atrás se ha iniciado?
Los resultados son consistentes con los objetivos...
Como consecuencia de esta revisión, será posible cerrar todos los tickets «Problema» e «Incidencia» relacionados con el cambio.
Atención: en el ámbito de un cambio de software o de aplicación, es imprescindible que el personal del Centro de servicios y los usuarios hayan recibido correctamente la formación necesaria para aprender la nueva versión. Del mismo modo, deberemos asegurarnos de que la documentación, tanto para un cambio de software o de aplicación como para un elemento de infraestructura, esté a disposición del personal del centro de servicios y de los usuarios.
Cambio normal y cambio urgente
g. Las «7 R» de la gestión de cambios En los libros en inglés se menciona el término 7 R, ya que en cada pregunta encontramos una palabra que empieza por la letra R como asunto principal. Encontrará entre paréntesis la palabra inglesa. Para cualquier petición de cambio, es obligatorio hacerse las siete preguntas siguientes:
¿Quién pide el cambio? (Who Raised)
¿Cuál es el motivo para esta petición? (Reason)
¿Cuál es el resultado esperado de este cambio? (Return)
¿Cuáles son los riesgos potenciales de este cambio? (Risks)
¿Qué recursos hay que poner en marcha para hacer este cambio? (Resources)
¿Quién es responsable de la construcción, las pruebas y la implementación del cambio? (Responsible)
¿Cuáles son las relaciones entre este cambio y los otros cambios? (Relationship)
Sin estos elementos, la evaluación del impacto del cambio en la entrega no es posible. El análisis de los riesgos y beneficios es imprescindible para asegurar las ventajas del cambio.
10. Beneficios y dificultades a. Beneficios El proceso de gestión de cambios permite una gestión eficiente de todas las modificaciones, asegurando que los cambios que se han puesto en marcha no afectarán a la calidad de los servicios proporcionados por la organización ni a los niveles de servicio contractuales. Entre los beneficios que aporta la gestión de cambios, podemos incluir:
Mejor evaluación del coste de los cambios solicitados.
Mejor evaluación de los costes reales de los cambios aplicados.
Mejor respuesta a los requerimientos del negocio.
Reducción del impacto negativo de los cambios sobre la calidad de los servicios proporcionados por la organización.
Cumplimiento de los compromisos establecidos en los SLA.
Mejora de la gestión de los incidentes y de la gestión de los problemas (garantía de que la información relativa a la infraestructura se suministra antes del cambio).
Mejora de la gestión de la disponibilidad y de la gestión de la continuidad, mediante un mejor conocimiento de la evolución de las infraestructuras.
Disminución de los riesgos, ya que se tienen en cuenta los cambios en la gestión de la seguridad.
Productividad mejorada para los equipos de la organización, ya que las acciones se planifican.
Productividad mejorada para los usuarios, ya que hay menos interrupciones del servicio no programadas.
Perspectivas de negocio mejoradas, ya que se demuestra profesionalidad.
b. Dificultades potenciales Las dificultades potenciales que podemos encontrar en el proceso de gestión de cambios son:
Gestión de activos y configuraciones deficiente o no implementada.
Proceso demasiado burocrático.
Intentos de eludir el proceso de gestión de cambios.
PIR no realizada al final de una implementación.
Perímetro demasiado importante para los recursos disponibles.
Procedimientos de vuelta atrás ausentes o deficientes.
Falta de apoyo por parte de la dirección de la organización.
Gestión de las entradas en producción 1. Enfoque En esta sección vamos a ver cómo se gestionan las entradas en producción de los cambios. Veremos que la eficacia de este proceso es muy dependiente de las acciones realizadas por la gestión de cambios. En términos de gestión de proceso, la gestión de las entradas en producción se podría considerar como un subproceso de la gestión de cambios, ya que se inicia por la gestión de cambios y se vuelve hacia la gestión de cambios al final del proceso.
2. ¿Por qué una gestión de las entradas en producción? Hemos visto en la sección anterior el tratamiento de las peticiones de cambios (RFC). Para dar una respuesta satisfactoria a la gestión de cambios, es imprescindible tener una estrategia de entradas en producción rigurosa. Esto permite efectuar los cambios que garantizan la protección del entorno de producción. Todos los aspectos, ya sean técnicos o no, se deben tener en cuenta para una gestión eficiente de las entradas en producción.
Para asegurar una gestión eficaz de las entradas en producción, es imprescindible disponer de información completa y precisa de la infraestructura del sistema de información y del conjunto de sus componentes. La gestión de activos y configuraciones, que hemos visto anteriormente, tiene el papel de proporcionar esta información. La puesta en marcha de la gestión de las entradas en producción debe permitir proteger el entorno de producción contra cualquier daño debido a entradas en producción no autorizadas o a pruebas realizadas directamente en el entorno de producción.
3. Objetivos del proceso Los objetivos principales del proceso de gestión de las entradas en producción son los siguientes:
Definir las políticas de entrada en producción.
Diseñar y aplicar procedimientos eficaces para los despliegues.
Asegurar que todos los despliegues se pueden trazar, instalar, probar, verificar y, eventualmente, volver atrás o desinstalar.
Planificación de los contenidos exactos de las actualizaciones y de los planes de desarrollo (coordinación con la gestión de cambios).
Verificación de que todos los elementos desarrollados o modificados cumplen los requisitos de seguridad y se pueden controlar por la CMS.
Asegurar que el servicio nuevo o modificado permite garantizar los niveles de utilidad y garantía recogidos en el SLA.
Gestión de los requisitos de clientes y usuarios para las actualizaciones y su despliegue.
Comunicar y asegurar que se ha dado a los usuarios y al personal de la organización formación suficiente (particularmente al centro de servicios).
Supervisar y controlar los despliegues documentación) nuevos o modificados.
Mantener y controlar el contenido de la DML (Definitive Media Library) y de la DHS (Definitive Hardware Storage) y asegurar que todas las copias se almacenan correctamente en la DML.
Puesta en marcha del ELS (Early Life Support).
de
software
y
hardware
(y
de
su
4. Definiciones ELS (Early Life Support): es un soporte específico que se debe aplicar en el momento de la entrada en producción de nuevos productos, en particular en el momento de la modificación o modificaciones de versión de software o de aplicaciones. Plan de vuelta atrás: plan que permite volver a la situación anterior en caso de que el despliegue de los cambios no sea satisfactorio. Big Bang: modo de implementación de un cambio.
FSC (Forward Scheduled Change): calendario de cambios que contiene los detalles de todos los cambios de infraestructura aprobados para su implantación, con sus fechas propuestas de implantación. PSA (Projected Service Availability): disponibilidad proyectada de servicios, calendario que prevé los periodos de inactividad de los servicios. PIR (Post Implementation Review): revisión posterior a la implantación que verifica que el cambio cumple sus objetivos, que los clientes están satisfechos y que no hay consecuencias negativas.
5. Perímetro La gestión de las entradas en producción es responsable de:
El diseño de las entradas en producción.
La validación del hardware y software.
La planificación de las entradas en producción.
La puesta en marcha del ELS.
Esto incluye todos los componentes de las configuraciones necesarias para implementar una entrada en producción, como:
Activos de servicio físicos (servidor o redes).
Activos de servicio virtuales (servidor o memoria).
Aplicaciones y software.
Formación para los usuarios y el personal de TI.
Los servicios (incluyendo los contratos y acuerdos de servicio).
6. Roles Los principales roles son los siguientes:
Responsable de las entradas en producción.
Responsable de cambios.
Propietario del proceso.
7. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de entradas en producción, principales y de poca importancia.
Número de entradas en producción implementadas con éxito.
Número de entradas en producción que generaron incidencias.
Número de entradas en producción que generaron problemas.
Número de marchas atrás.
Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión de las entradas en producción
9. Conceptos básicos a. El ciclo de vida de una entrada en producción El ciclo de vida de una entrada en producción se puede definir por seis actividades principales, que se detallan a continuación:
El ciclo de vida de un cambio
b. Los diferentes tipos y modos de entrada en producción Tipos de despliegue Existen tres tipos de despliegue:
Despliegue completo (Full release): la ventaja de establecer un despliegue completo es que se construyen todos los componentes y se prueban y ponen en marcha todos juntos. El despliegue se puede realizar al mismo tiempo sobre todas las infraestructuras (software o hardware), o sobre un entorno piloto, antes de implementarlo en el conjunto de entornos. La ventaja de hacerlo en dos partes (o fases) es la reducción de riesgos de bloqueo generalizado en caso de dificultad. Desafortunadamente, esta opción resulta a menudo más costosa, ya que es necesario modificar los recursos técnicos en cada fase del despliegue.
Despliegue intermedio (Delta release): en este caso de despliegue, solo se cambia la parte de la infraestructura que haya sido modificada desde la última entrada en producción. El coste de un cambio como este es, en general, menos elevado que en el caso de un despliegue completo. Por el contrario, si se ha modificado un CI sin que se haya registrado en la CMDB, se corre el riesgo de tener dificultades en el despliegue. Esto puede obligar en algunos casos a la necesidad de una vuelta atrás. Como en el caso del despliegue completo, el despliegue intermedio se puede realizar en una o dos fases, con las mismas consecuencias financieras.
Despliegue por agrupación (Package): la tendencia en la mayoría de las empresas es agrupar los cambios, en la medida en que no sean cambios importantes, con el objetivo de limitar las interrupciones del servicio. Algunos cambios, incluso de poca importancia, pueden provocar la puesta en marcha de otros cambios al mismo tiempo. Hay que prestar atención, sin embargo, a no crear una entrada en producción empaquetada, que contenga demasiados cambios; existiría el riesgo de tener que hacer una marcha atrás sobre demasiados elementos.
Modo de despliegue Por otro lado, el despliegue se puede lograr de varias maneras, en función de las herramientas que se utilicen: Big Bang En ese caso se realiza un despliegue de manera global sobre el conjunto de la infraestructura, en una única operación.
Fase En este caso, en función del número de personas o ubicaciones implicadas y si es posible, el despliegue se realiza en varias operaciones planificadas, ubicación por ubicación, servicio por servicio, o cliente por cliente. Modo «Push & Pull» En este caso, la emisión de las entradas en producción se realiza de manera electrónica. En modo «Push», se fuerza la instalación sobre un conjunto de puestos; en modo «Pull», es el usuario el encargado de hacer la actualización sobre su puesto. Pueden aparecer problemas en la utilización de este modo de despliegue. En el caso del «Push», nunca se está del todo seguro de que todos los puestos de trabajo hayan tenido suministro eléctrico, lo que implica que algunos usuarios podrían utilizar una versión diferente en un momento dado. En el caso del «Pull», puede aparecer el mismo problema si no todos los usuarios hacen el cambio en el momento indicado. Modo Automatizado o Manual La entrada en producción de los cambios se puede realizar de manera manual o automatizada, en función de las herramientas disponibles en la organización.
c. Las cuatro fases de la entrada en producción 1. Planificación de la entrada en producción En esta fase, hay que preparar una planificación para la construcción y despliegue de la entrada en producción. Esta fase comienza con la autorización de la gestión del cambio para la planificación de una entrada en producción y termina con la autorización de la gestión del cambio para la creación de la entrada en producción. 2. Construcción y pruebas La entrada en producción se construye, prueba y controla en la DML (Definitive Media Library). Esta fase comienza con la autorización de la gestión del cambio para la creación de la entrada en producción y termina con la autorización de la gestión del cambio para el control de una base de referencia en la DML, a través del proceso de gestión de configuraciones (SACM). Esta fase es única para cada entrada en producción. 3. Despliegue El paquete de entrada en producción que está en la DML se despliega en el entorno de producción. Esta fase comienza con la autorización de la gestión del cambio para el despliegue. Incluye la creación de una base de referencia en la DML, por el proceso de gestión de configuraciones (SACM). Esta fase es única para cada entrada en producción. Esta fase termina con el soporte por la fase operación del ciclo de vida y el inicio del ELS (Early Life Support). La fase de despliegue puede ser un proceso recurrente en función de la opción de despliegue seleccionado.
4. Revisión del despliegue y cierre Se debe aprender de la experiencia; se deben analizar los objetivos de rendimiento y realización para determinar los ejes de mejora.
d. Las actividades de gestión de la puesta en producción El responsable de la gestión de las entradas en producción debe definir una estrategia para aclarar los roles y responsabilidades de cada uno. Esta estrategia se debe concretar en un documento. La política de entradas en producción se debe revisar después de cada cambio principal de la infraestructura técnica. Las principales actividades de la gestión de las entradas en producción son las siguientes.
Diseño Es imprescindible diseñar los procedimientos para la entrada en producción de los cambios. En esta actividad, es necesario:
Definir los modelos de entrada en producción.
Definir el plan de pruebas.
Definir el plan de puesta en marcha.
Preparar los procedimientos documentados.
Construcción y preparación En esta actividad hay que construir el cambio:
Identificar el hardware y el software implicados en el cambio.
Ensamblar el conjunto de componentes.
Preparar el entorno de pruebas.
Asegurar, si el cambio lo implica, que la documentación está disponible y que se ha definido y puesto en práctica correctamente un plan de formación.
Evaluación En esta actividad hay que realizar las pruebas. De manera ideal, en la medida de lo posible, es deseable implicar a los clientes y usuarios en las pruebas. El objetivo es obtener la aceptación formal del cliente y del usuario sobre la futura entrada en producción. Estas pruebas deben incluir pruebas funcionales, operativas, de rendimiento y de integración. Se deben realizar de manera unitaria y de manera global, en un entorno lo más parecido posible al entorno de producción.
Planificación
La planificación de cambios se debe realizar teniendo en cuenta el calendario de cambios (FSC), así como las disponibilidades proyectadas de servicios (PSA). La planificación implica obtener un consenso sobre el contenido de la puesta en producción, la planificación de los recursos, la planificación de la aceptación de los grupos de soporte y del cliente y la producción del plan de vuelta atrás.
Comunicación y formación La comunicación con los clientes, los usuarios y el personal del centro de servicios es imprescindible. Cada uno debe saber cómo se va a producir la entrada en producción de los cambios y conocer los impactos de la operación. En caso de que el cambio implique que se debe impartir una formación, ya sea a los usuarios, al personal del centro de servicios o a los dos, la formación se deberá llevar a cabo antes de la entrada en producción. Algunos cambios, fundamentalmente en caso de una nueva versión de software o una nueva aplicación, necesitan aplicar una célula de soporte (Early Life Support) para asistir al personal del centro de servicios durante un cierto tiempo. La puesta en marcha del ELS también se debe preparar para que esté operativo después de la instalación de los cambios. El personal que ha contribuido al desarrollo del servicio también puede estar integrado en el soporte ELS. Esto mejorará la transmisión del conocimiento a los técnicos del centro de servicios, lo que también puede mejorar la calidad de las relaciones entre los diferentes equipos.
Distribución e instalación La instalación del cambio se debe realizar utilizando uno de los tipos y modos de despliegue, enumerados en el capítulo anterior. La CMS se debe actualizar con motivo de la entrada en producción, la copia de versiones en la DML o el almacenamiento del hardware en la DSH, la actualización de todos los CI implicados. Se deben registrar todos los fallos encontrados durante la instalación para la redacción del PIR.
10. Beneficios y dificultades a. Beneficios La gestión de las entradas en producción permite desplegar el cambio asegurando que los cambios que se han puesto en marcha no afectarán a la calidad de los servicios proporcionados por la organización ni a los niveles de servicio contractuales. Entre los beneficios que aporta la gestión de cambios, podemos enumerar:
Entornos de producción y de pruebas estables.
Reducción del impacto negativo del cambio sobre la calidad de los servicios proporcionados por la organización.
Respeto de los acuerdos definidos en los SLA.
Gestión de la disponibilidad y gestión de la continuidad mejoradas, al tener en cuenta elFSC para realizar el despliegue.
Baja probabilidad de encontrar copias ilegales de software en la organización.
Mejora de la productividad de los equipos de la organización TI, ya que las acciones están planificadas.
Mejora de la productividad de los usuarios, ya que hay menos interrupciones del servicio no programadas.
b. Dificultades potenciales Las dificultades que pueden entorpecer el proceso de gestión de las entradas en producción son:
Resistencia al cambio de los equipos acostumbrados a realizar las entradas en producción individualmente.
Intentos para evitar los procedimientos de aplicación.
Responsabilidades mal definidas.
Gestión de activos y configuraciones errónea o no implementada.
Perímetro demasiado importante para los recursos disponibles.
Procedimientos de vuelta atrás ausentes o erróneos.
Gestión de validaciones y pruebas 1. Enfoque Este proceso contribuye a la puesta en marcha de una estrategia de calidad. Esta estrategia de calidad permite entregar un servicio nuevo o modificado, a través de las fases de diseño y entrada en producción, correspondiente a las necesidades y al uso esperado.
2. ¿Por qué una gestión de las validaciones y las pruebas? La validación y las pruebas son un dominio esencial de la gestión de servicio. A menudo, esta actividad se pasa por alto o se ignora, lo que es un error. Si los servicios no se prueban lo suficiente, su despliegue puede generar:
Incidentes, diferencias entre lo que espera el cliente y lo que suministra el proveedor de servicios.
Llamadas al centro de servicios para pedir explicaciones o aclaraciones sobre el uso y las funcionalidades de un servicio o de una aplicación.
Problemas y errores difíciles de diagnosticar.
Costes adicionales, ya que puede ser más costoso reparar un error en un entorno de producción que en un entorno de pruebas.
Uso del servicio que no corresponde a los requerimientos del negocio.
3. Objetivos del proceso Los objetivos principales del proceso de gestión de validaciones y pruebas son los siguientes:
Asegurar que las necesidades del cliente, para un servicio nuevo o modificado, se definen y obtienen el soporte adecuado.
Asegurar que un servicio nuevo o modificado responde correctamente a las necesidades (utilidad) y que se proporciona la garantía correctamente (garantía).
Asegurar que un servicio nuevo o modificado proporciona los resultados que el cliente espera, respetando los costes, la capacidad y la disponibilidad previstos inicialmente.
Poner en marcha un proceso de planificación e implementación que pruebe que el servicio nuevo o modificado responderá a las necesidades, incluidos los compromisos que se especifican en el SLA.
4. Perímetro del proceso El proveedor de servicios asume la responsabilidad del suministro de la prestación y del mantenimiento de los activos de servicio, cliente o proveedor, respetando los compromisos definidos en los acuerdos de servicios (SLA/OLA). Este proceso permite asegurar que el proveedor de servicios es capaz de garantizar la prestación a lo largo del ciclo de vida del servicio, lo que implica disponer de los recursos y capacidades necesarias. Los resultados de este proceso servirán al proceso de gestión de los cambios para activar, o no, el proceso de despliegue.
5. Descripción del proceso
El proceso de gestión de validaciones y pruebas
6. Conceptos básicos a. Enfoques y técnicas de pruebas Existen numerosos enfoques que se pueden combinar para hacer la validación y las pruebas, según las restricciones del entorno de pruebas y del futuro entorno de producción. De la misma manera, se pueden combinar diferentes enfoques para responder a los requerimientos de diferentes tipos de servicio, modelos de servicio, perfiles de riesgo, nivel de competencia, objetivos y nivel de pruebas de proceso. A continuación se enumeran algunos ejemplos:
Enfoque basado en el riesgo.
Enfoque de conformidad con los estándares o las normas.
Enfoque basado en la experiencia.
Enfoque basado en los métodos del ciclo de vida del desarrollo de software y simulación.
Escenario de pruebas.
Prototipado.
Pruebas de laboratorio.
Pruebas de no regresión.
Ejecución de proyectos piloto.
Para optimizar los recursos de prueba, las actividades de prueba se deben definir y asignar en función de la importancia del servicio, del impacto potencial sobre las operaciones previstas y del nivel de riesgos. Los análisis del impacto sobre el negocio se deben hacer durante la fase de diseño, particularmente en los procesos de gestión de la capacidad, disponibilidad y continuidad de servicios.
Gestión de la evaluación de los cambios 1. Enfoque Este proceso contribuye a la puesta en marcha de una estrategia de calidad. Esta estrategia de calidad permite entregar un servicio nuevo o modificado, a través de las fases de diseño y entrada en producción, que corresponde a las necesidades y uso esperado.
2. ¿Por qué una gestión de la evaluación de los cambios? La gestión de los cambios necesita los resultados de la gestión de evaluación para poder decidir desplegar o no un cambio. Para esto, es necesario un marco estandarizado y uniforme para evaluar el rendimiento de los cambios, teniendo en cuenta el rendimiento real y el esperado. Será necesario identificar los riesgos reales o potenciales para proporcionar ayuda a la toma de decisión para la gestión de los cambios.
3. Objetivos del proceso Los objetivos principales del proceso de evaluación de los cambios son:
Definir correctamente el resultado esperado por las partes implicadas y suministrar información de gestión precisa y eficaz.
Evaluar los objetivos de un cambio, pero también los efectos no esperados que puede tener este cambio, teniendo en cuenta las capacidades, los recursos y las restricciones organizativas.
Proporcionar resultados de buena calidad que permitirán a la gestión de los cambios decidir desplegar o no un cambio.
4. Perímetro del proceso Este proceso se aplica a todos los cambios sometidos al proceso de gestión de los cambios.
5. Descripción del proceso
El proceso de gestión de las evaluaciones
6. Conceptos básicos Todos los cambios se deben evaluar, pero solo los cambios significativos lo deben ser en el marco del proceso de evaluación. Los criterios de evaluación se deben definir para poder determinar cuáles son los cambios implicados por este proceso. Esta evaluación debe tener en cuenta los riesgos inherentes a este cambio y las interacciones con los otros servicios o las infraestructuras compartidas. Como para los otros procesos ITIL, es deseable la aplicación de modelos. Por supuesto, se debe documentar la decisión que se tome.
a. Desarrollo de las actividades del proceso
El desarrollo de las actividades del proceso de evaluación
Gestión del conocimiento 1. Enfoque En esta sección, vamos a ver cómo se gestiona el conocimiento en el seno del proveedor de servicios. Para una parte importante, el conocimiento proviene de una fuente interna de la empresa, pero también del exterior (fabricantes de software, proveedores externos...).
2. ¿Por qué una gestión del conocimiento? La capacidad para suministrar un servicio de calidad se basa en un buen conocimiento del entorno de suministro del servicio, pero también en el entorno exterior y en la capacidad de reaccionar en función de las circunstancias. Para esto, los colaboradores de los departamentos de TI deben poder encontrar información en las diferentes bases de información de la empresa. Este conocimiento debe incluir la identificación de los participantes y los riesgos.
3. Objetivos del proceso Los objetivos principales del proceso de gestión del conocimiento son los siguientes:
Mejorar la calidad de la gestión decisional, asegurando que la información esté disponible y sea segura, a través del ciclo de vida de los servicios.
Hacer que el proveedor de servicios sea más eficiente y mejorar la calidad del servicio.
Mejorar la satisfacción del cliente.
Reducir los costes conocimiento.
Asegurar que la gestión tiene una comprensión clara del valor del servicio suministrado al cliente.
Poner en marcha y mantener un sistema de gestión del conocimiento (SKMS).
Recolectar, analizar, almacenar, compartir, usar y mantener el conocimiento, la información y los datos a través de la organización.
del
servicio,
reduciendo
la
necesidad
de
redescubrir
el
4. Perímetro La gestión del conocimiento se aplica al conjunto de actividades de la gestión de los departamentos de TI, a través de las diferentes fases del ciclo de vida de los servicios.
5. Descripción del proceso y de las principales relaciones
La gestión del conocimiento
6. Conceptos básicos Es obligatoria una política de gestión del conocimiento para guiar al equipo directivo, en términos de comportamiento y compromiso, con objeto de hacer más efectivo y eficiente este proceso. Esta política será diferente en función de la cultura de la empresa. Sin embargo, tiene que incluir:
El conocimiento y la información necesarias para el soporte de los servicios.
Todo el conocimiento y la información se deben crear, revisar, aprobar, mantener, controlar y hacerlos disponibles siguiendo un proceso formal y documentado.
Todas las políticas, planes y procesos se deben revisar, al menos, una vez al año.
a. SKMS La base de datos de conocimientos se llama SKMS (Service Knowledge Management System). Esta base de datos contiene las bases de datos específicas de cada proceso. Por ejemplo, la base de datos de la gestión de configuraciones (CMDB) se incluye en el sistema de gestión de configuraciones (CMS - Configuration Management System), que a su vez está incluida en la SKMS.
b. El modelo DIKW
El modelo DIKW El modelo DIKW es una representación de la estructura del conocimiento. A continuación explicamos el significado de este acrónimo.
En primer lugar, partimos de datos sin tratar (la «D» del modelo). Cuando estos datos se estructuran (qué, quién, cuándo y dónde), pasamos a la «I» del modelo, ya que los datos se han transformado en «Información». La siguiente etapa va a responder al «Cómo». En esta etapa, podemos hablar de «Conocimiento». La última etapa se llama de la «Sabiduría», ya que en este momento sabemos cómo usar el conocimiento y, por tanto, crear valor.
LOS PROCESOS DE LA EXPLOTACION DE SERVICIOS La fase de explotación de servicios 1. ¿Por qué una explotación de los servicios? Como hemos visto en el capítulo de presentación de la norma, ITIL se descompone en procesos estratégicos, tácticos y operativos.
Los niveles decisionales de la fase Operaciones Los procesos de explotación de los servicios se sitúan en la parte correspondiente a los niveles «operativos». La explotación de los servicios se basa en las funciones y procesos. En esta primera parte, no veremos los procesos «transición de servicios», a pesar de que se identifican tanto en la parte «táctica» como en la parte «operativa». Se tratarán en la parte «transición de los servicios».
2. Los objetivos de la explotación de servicios Al contrario de lo que sugieren algunas ideas preconcebidas, la explotación de servicios no solo afecta a las operaciones diarias dirigidas a suministrar el servicio. En el marco del ciclo de vida de los servicios, el objetivo de la explotación de servicios es asegurar que el negocio puede cumplir sus objetivos y poner en marcha procesos para optimizar los costes y la calidad de los servicios. En el ámbito tecnológico, la explotación de los servicios es responsable del co- rrecto funcionamiento de los diferentes elementos que forman la infraestructura informática, que soporta los servicios y la ejecución de las actividades de control, para gestionar y entregar los servicios. En el ámbito del negocio global, la explotación de servicios es responsable de suministrar servicios eficaces con un coste aceptable y con un nivel de servicio equivalente a los niveles definidos en los SLA. También debe asegurar el mantenimiento del nivel de satisfacción de los usuarios.
3. Los procesos de explotación de los servicios
La gestión de eventos.
La gestión de incidencias.
La gestión de problemas.
El tratamiento de consultas.
La gestión de accesos.
4. Las funciones de explosión de servicios La fase explotación de servicios se compone, además de los procesos mencionados anteriormente, de cuatro funciones:
El centro de servicios.
La gestión de operaciones.
La gestión técnica.
La gestión de aplicaciones.
a. La definición de una función Una función es un grupo de personas o un equipo y herramientas u otros recursos que se usan para realizar las actividades definidas en un proceso. Una persona o un grupo de personas pueden trabajar para varias funciones. Una actividad se puede realizar por una persona, un grupo de personas o varios grupos de personas. Para asegurar un suministro óptimo de los servicios, es imprescindible definir claramente los roles y responsabilidades de cada uno.
La organización debe aplicar y gestionar una estructura de equipos, grupos o funciones. La definición de los roles y responsabilidades se debe efectuar a nivel de cada proceso y de cada una de las actividades del proceso (ver Anexos - El modelo RACI).
b. La ubicación de las funciones
Ubicación de las funciones y relaciones
Funciones
1. Función de gestión de operaciones a. Descripción de la función
La función de gestión de operaciones
b. Conceptos básicos La gestión de operaciones está formada por dos partes:
El control de las operaciones: gestión del conjunto de actividades diarias para suministrar el servicio.
Los medios generales (Facilities Management): gestión del entorno físico y de los contratos con los proveedores externos.
2. Función de gestión de aplicaciones Esta función es responsable de la gestión de las aplicaciones a través de su ciclo de vida. Tiene relación con la gestión de las operaciones y el centro de servicios. Véase el esquema de la sección La ubicación de las funciones.
3. Función de gestión técnica Esta función suministra las competencias y los recursos técnicos para las operaciones.
Tiene un papel importante en el diseño, transición (pruebas y despliegue) y operaciones (soporte). Tiene relación con la gestión de operaciones y el centro de servicios. Véase el esquema de la sección La ubicación de las funciones.
El centro de servicios 1. Etapas preliminares Antes de la puesta en marcha del centro de servicios, es necesario realizar varias etapas preliminares. Encontrará estas etapas en los capítulos siguientes:
Definición de la estrategia de negocios: capítulo Los procesos de la estrategia de servicios - Generación de la estrategia.
Preparar la puesta en marcha de un CMS inicial: capítulo Los procesos de la transición de servicios - Gestión de los activos de servicio y configuraciones.
Preparar la puesta en marcha de contratos de servicios básicos: capítulo Los procesos del diseño de servicios - Gestión de los niveles de servicio.
Preparar la gestión de los cambios: capítulo Los procesos de la transición de servicios - Gestión de cambios.
2. Requisitos previos Antes de establecer el centro de servicios, se deben iniciar los siguientes procesos, aunque no necesariamente finalizarlos:
Gestión de la estrategia.
Gestión del porfolio de servicios.
Gestión de los activos y configuraciones.
Gestión de los niveles de servicios
Gestión de cambios
Gestión de incidencias.
Gestión de problemas (fundamentalmente, gestión de la base de errores conocidos).
3. Los diferentes tipos del centro de servicios El centro se servicios se llama SPOC (Single Point of Contact) porque permite al usuario acceder al conjunto de los servicios especializados, usando un punto de contacto único. Se pueden distinguir los siguientes cuatro tipos de centro de servicios.
4. El centro de servicios local El centro de servicios tiene a cargo las llamadas de los usuarios procedentes de la ubicación en la que está instalado.
Centro de servicios local Este tipo de centro es práctico mientras la empresa no tenga demasiadas ubicaciones; en caso contrario, esto implica una multiplicación de las competencias y los recursos para cada ubicación.
Inconvenientes En este tipo de organización, no hay capitalización posible entre los empleados presentes en las dos ubicaciones. Tampoco es posible que una ubicación absorba una sobrecarga puntual de otra segunda ubicación. Esta sobrecarga se podría deber a una incidencia técnica, una ausencia no planificada de un técnico o a cualquier otro motivo.
5. Centro de servicios centralizado El centro de servicios está implantado en una ubicación central y recibe las llamadas de los usuarios de las diferentes ubicaciones de la empresa. Este tipo de centro permite un mejor uso de los recursos disponibles, una reducción de los costes operativos y contribuye a mejorar la visibilidad del conjunto de la gestión.
Centro de servicios centralizado La noción de SPOC sigue siendo válida para el usuario, ya que este accede al conjunto de los servicios especializados, usando para ello un punto de contacto único.
6. Centro de servicios virtual El centro de servicios se implanta en diferentes ubicaciones que pueden estar repartidas en uno o varios países o continentes. Sin embargo, los usuarios solo ven el centro de servicios virtual. El funcionamiento de estos centros se basa en el uso de tecnologías de telecomunicaciones de mayor rendimiento y el uso de redes de banda ancha. Los centros se pueden establecer en función de varios criterios:
Idiomas hablados.
Aplicaciones implicadas.
Centro de servicios virtualizado Este tipo de centros, como el centro de servicios centralizado, permite un mejor uso de los recursos disponibles, una reducción de los costes operativos y contribuye a mejorar la visibilidad del conjunto de la gestión. La noción de SPOC sigue siendo válida para el usuario, ya que accede al conjunto de los servicios especializados, usando para ello un punto de contacto único.
7. Centro de servicios «Follow the sun» Las organizaciones internacionales pueden combinar el modelo de centro de servicios virtual con una noción de desfases horarios. El centro de servicios se implanta en diferentes ubicaciones, que pueden estar repartidas en uno o varios países o continentes. De esta manera, algunas veces se utiliza el término de centro de servicios «Follow the sun», para recordar que el acceso al centro de servicios es posible durante las 24 horas del día. Sin embargo, los usuarios solo ven el centro de servicios virtual. El funcionamiento de estos centros se basa en el uso de tecnologías de telecomunicaciones de mayor rendimiento y el uso de redes de banda ancha. Los centros se pueden establecer en función de varios criterios:
Idiomas hablados.
Aplicaciones implicadas.
Desfases horarios.
Uno de los beneficios de este tipo organizaciones es que los equipos de soporte del centro de servicios trabajan en horarios normales, cuyo coste de explotación es menor.
Centro de servicios «Follow the Sun»
8. Externalizar el centro de servicios a. ¿Por qué externalizar el centro de servicios? Hoy en día, un número importante de empresas han elegido externalizar su centro de servicios. Esta solución responde, en general, a una estrategia de externalización total o parcial de la actividad informática. Una ventaja importante de esta solución es que la empresa subcontratada está obligada a obtener resultados. Esta obligación de resultados se debe trasladar correctamente al contrato de externalización del servicio, contrato de tipo UC (ver capítulo Los procesos del diseño de los servicios - Gestión de los niveles de servicio). Este tipo de soluciones pueden ser interesantes para pequeñas o medianas estructuras, ya que las inversiones, tanto en hardware como en software, relativas a las herramientas de gestión de incidencias y problemas se pueden agrupar a nivel de subcontratación. Además, esta solución también permite resolver un problema interno de competencias informáticas.
b. Los riesgos de la externalización La elección de la externalización de un centro de servicios es una decisión particularmente importante para la empresa. En efecto, en el marco de una externalización, la empresa acepta confiar a otra empresa el cuidado de la gestión de una parte de su informática y, por tanto, de una parte de sus competencias.
Esto es importante, ya que las competencias de las personas de la organización TI forman parte de los activos de la empresa (ver el capítulo Los procesos de la transición de los servicios - Gestión de los activos de servicios y configuraciones, para la definición del término «Activo»). Por lo tanto, esta decisión implica la aceptación por parte de la empresa de la pérdida de parte de sus activos, al menos temporalmente. Por otra parte, la empresa debe tener en cuenta que esta decisión se puede modificar en cualquier momento. Por lo tanto, será necesario prever en el contrato con el proveedor una cláusula de marcha atrás, también llamada cláusula de reversibilidad. En esta cláusula, el proveedor se debe comprometer a transmitir a la empresa el conjunto del conocimiento desarrollado y, si es necesario, las herramientas específicas desarrolladas para asegurar el servicio durante el periodo en el que el servicio ha estado bajo su responsabilidad. Durante esta prestación, la empresa se debe asegurar de que el proveedor respeta este compromiso y que pone en marcha los medios necesarios que permitan esta vuelta atrás.
9. El funcionamiento del centro de servicios a. Registro de la información por el centro de servicios, noción de ticket Una de las obligaciones del centro de servicios es registrar el conjunto de información que le ha sido transmitida, tanto por parte de los clientes/usuarios como por el hardware o el software. Para registrar esta información, el centro de servicios va a utilizar un software de tratamiento de llamadas. La creación de un registro genera un ticket, al que se hace referencia por medio de un identificador único, que servirá posteriormente para asegurar que se trazan de manera correcta las diferentes acciones realizadas para el tratamiento de este registro, y para la comunicación con el cliente o usuario. Se debe proporcionar este identificador a la persona que está en el origen de su creación. Existen diferentes tipos de ticket:
Incidencia
Problema
Petición de servicio
Petición de información
Alerta (recuperada por el hardware o el software)
b. Los medios técnicos del centro de servicios El centro de servicios debe disponer de una herramienta con buen rendimiento, capaz de realizar el conjunto de operaciones que permitan atender y hacer el seguimiento de las llamadas de los usuarios.
Atención: el programa de certificación puesto en marcha actualmente por APMG y OGC ha permitido certificar las primeras herramientas. Sin embargo, varios fabricantes de software han optado por tener en cuenta las recomendaciones ITIL con el objetivo de que sus herramientas respeten de manera más fiable las mejores prácticas de ITIL. El término «Compliant ITIL» no es en absoluto una garantía de que la herramienta le permita realizar el conjunto de operaciones descritas en ITIL V3. Por ejemplo, podemos observar que ciertos programas de software solo tienen en cuenta los servidores en la CMS; ¿cómo se gestiona en este caso la noción de CI a nivel de los puestos de trabajo o del software? Las herramientas utilizadas deben permitir el registro de los diferentes elementos útiles y necesarios para el tratamiento de la llamada de un usuario o de un miembro del equipo informático (incidencia, problema y petición de servicio), o de la generación de un evento por parte del hardware o el software. Especialmente, la herramienta de gestión de las llamadas debe permitir la definición de la prioridad de la llamada, en función de los criterios establecidos en el contrato de servicio (urgencia e impacto). También debe permitir hacer el seguimiento del tiempo transcurrido con el objetivo de respetar los plazos de tratamiento definidos en el contrato de servicio en función de la prioridad. Esta herramienta debe proporcionar la posibilidad de elaboración de estadísticas.
c. Los medios humanos del centro de servicios El centro de servicios es el punto de centralización de los equipos técnicos de soporte. Los empleados se deben organizar en equipos, que deben adaptarse para tener en cuenta los horarios definidos en los contratos de niveles de servicio. Pueden existir equipos de diferentes niveles de soporte, en función del tamaño de la empresa.
Atención: en ITIL, el centro de servicios se ve como una «función». Los empleados del centro pueden tener un rol en los procesos de incidente o problema.
d. La comunicación del centro de servicios El establecimiento del centro de servicios es un acto fundador, originado por la puesta en marcha de una estrategia ITIL en la empresa. El centro de servicios es el punto de entrada para los clientes del servicio informático; no olvide que los clientes del servicio informático pueden ser personas internas de la empresa, aunque también clientes de la empresa, si proporciona a sus clientes los medios informáticos. El centro de servicios también es un escaparate de los servicios informáticos.
Por este motivo, la comunicación se debe definir claramente y adaptar al entorno de la empresa. Por lo tanto, es importante preparar correctamente la comunicación del centro de servicios. El responsable del centro de servicios debe definir una política real de marketing de los servicios ofrecidos por el centro. Esto es importante, ya que la comunicación se deberá realizar en la fase inicial de la puesta en marcha, pero también de manera regular posteriormente. La apertura de un centro de servicios debe estar marcada por una importante comunicación hacia los clientes y usuarios, así como hacia el conjunto del personal de la organización. En esta comunicación, la oferta de servicios debe ser clara, precisa y comprensible para todos los futuros usuarios. Se pueden utilizar varios canales:
Envío por buzoneo (en papel o electrónico).
Envío de un documento de ayuda (en papel).
Envío de un objeto que permita la memorización del número de llamada o una dirección de correo electrónico.
Dirección de correo de la Dirección General...
e. Comunicación del estado de los tickets creados por los clientes o usuarios Los clientes o usuarios pueden presentar sus peticiones por diferentes medios, según las tecnologías que se hayan puesto en marcha en el centro de servicios. Estas tecnologías pueden permitir:
Una llamada telefónica.
Un fax.
Un correo electrónico.
Una entrada directa de la petición por medio de un formulario o un acceso directo a la herramienta.
Un acceso Web...
A lo largo del ciclo de vida de un ticket, el cliente o usuario debe poder, en todo momento, conocer el estado de su ticket. Esto entra en la categoría de la comunicación necesaria para la satisfacción del cliente o usuario. Para esto, los agentes del centro de servicios deben poder consultar, en cualquier momento, las evoluciones de las acciones realizadas en el contexto del tratamiento de un ticket que ha abierto un cliente/usuario.
El centro de servicios se debe comunicar de manera regular con el cliente o usuario. Esta comunicación es necesaria para el cierre de un ticket, algo que no se podrá realizar sin el acuerdo del cliente o usuario. El centro de servicios también se debe comunicar con los otros procesos que se han puesto en marcha en la empresa.
10. Beneficios y dificultades a. Beneficios La puesta en marcha de un centro de servicios permite hacer un seguimiento mejor de las incidencias informáticas. También permite mejorar el rendimiento del conjunto de los empleados de la empresa, ya que les da una respuesta rápida y, por tanto, limita el tiempo perdido a causa de las incidencias informáticas.
b. Dificultades potenciales Durante la puesta en marcha de un centro de servicios, pueden aparecer una serie de dificultades o inconvenientes. La primera dificultad que puede encontrar es la comunicación. Si no establece un sistema de comunicación sólido, con el apoyo de la dirección de la empresa y de la organización TI, no obtendrá la adhesión de los usuarios. La segunda dificultad es la identificación de los futuros técnicos y su formación. Estas son, sin duda, las dificultades más frecuentes.
Procesos La explotación de servicios está formada por cinco procesos. Los más importantes son la gestión de incidencias y la gestión de problemas. Los otros tres procesos son la gestión de eventos, de consultas y de accesos. Estos cinco procesos se detallan a continuación.
Gestión de eventos 1. Enfoque En esta sección, vamos a ver cómo se gestionan los eventos en la explotación de servicios. En la sección anterior hemos visto la aplicación del centro de servicios. Un evento se puede considerar como un cambio de estado, que tiene un sentido para un elemento de configuración (CI) o para un servicio. La eficacia de un servicio depende del conocimiento de la infraestructura y la capacidad para identificar una desviación con respecto a una situación normal o esperada. Esto es posible con una cuidadosa supervisión y un sistema de control basado en dos tipos de herramientas, supervisión activa y supervisión pasiva.
2. Objetivo del proceso El objetivo principal del proceso de gestión de eventos es identificar los eventos, darles un sentido y determinar las acciones más importantes. Los objetivos de la gestión de eventos son los siguientes:
Detectar cualquier cambio de estado que tenga algún sentido para un elemento de configuración (CI) o para un servicio.
Determinar las acciones de control para los eventos y asegurar la comunicación con las funciones adecuadas.
Suministrar un punto de entrada para la ejecución de varios procesos de las operaciones y actividades de control.
Suministrar los medios de comparar el rendimiento real de funcionamiento y el comportamiento opuesto a las normas de diseño y al contenido de los acuerdos de servicios SLA.
Suministrar una base para crear informes.
3. Perímetro El perímetro de la gestión de eventos se aplica a todas las actividades de la gestión de servicios que necesitan un control automatizado. Esto incluye la gestión de los CI y el entorno físico, la gestión de licencias, la seguridad y las operaciones diarias.
4. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de eventos de tipo alerta.
Número de eventos de tipo excepción.
Número de eventos de tipo entorno.
Esta lista no es exhaustiva; convendría definir los indicadores en función de la estructura que se ponga en marcha.
5. Descripción del proceso
El proceso de gestión de eventos
6. Conceptos básicos a. Diferentes tipos de evento Existen tres tipos de eventos:
Evento de tipo información.
Evento de tipo alerta.
Evento de tipo excepción.
Evento de tipo información Estos son los eventos que afectan a las actividades regulares y normales dentro de la gestión de servicios.
Este tipo de evento no activa ninguna acción particular. Por ejemplo: un usuario que se conecte a una aplicación o una tarea que empieza o termina con normalidad. Evento de tipo alerta Estos son los eventos que se producen cuando se sobrepasa un umbral. Estos umbrales se definen en la herramienta de gestión de eventos o en los SLA u OLA. Este tipo de evento necesita, de manera regular, la intervención de un operador. Por tanto, este tipo de evento se transmite al responsable designado de la actividad. En algunos casos, este tipo de evento puede generar una incidencia. Por ejemplo: un umbral de uso del espacio en disco superior al 70% o el tiempo de respuesta de una transacción superior al 10% del tiempo definido. Evento de tipo excepción Estos son los eventos relacionados con una situación excepcional. Por ejemplo: un umbral de uso del espacio en disco superior al 90%, una transacción no terminada o un intento de conexión a una aplicación con un usuario o una contraseña incorrectos.
Gestión de las incidencias 1. Enfoque En esta sección vamos a ver cómo se gestionan las incidencias en el seno del centro de servicios. En la sección anterior hemos visto la puesta en marcha de un centro de servicios. Cuando una empresa decide poner en marcha ITIL, normalmente el proceso incidencia es uno de los primeros en activarse, después de la puesta en marcha de un centro de servicios, ya que esto permite iniciar progresivamente la estrategia ITIL. También veremos cómo se tratan los eventos y las peticiones, ya que las segundas llegan al centro de servicios y se tienen en cuenta por el proceso de incidencia inicialmente.
2. ¿Por qué una gestión de incidencias? Independientemente de cuál sea la calidad de los servicios proporcionados por la organización TI, es inevitable que se produzcan incidencias. En efecto, no es realista pretender producir un servicio que garantice su funcionamiento sin ninguna incidencia, ya que esto haría necesario realizar pruebas en un entorno idéntico al de la explotación, lo que hace necesario a su vez tener que prever todos los escenarios posibles. Por otra parte, no hay que olvidar nunca que un error humano siempre es posible y que este se halla en el origen de un porcentaje nada despreciable de las incidencias... Cuando no hay gestión de incidencias, el usuario, en caso de un funcionamiento incorrecto de su puesto de trabajo o de la aplicación que utiliza, tenderá a molestar a sus compañeros
para resolver este funcionamiento incorrecto. Esto tendrá un impacto sobre la actividad de la persona, pero también de sus compañeros. Si, a pesar de la ayuda de sus compañeros, el usuario no soluciona el funcionamiento incorrecto, contactará con los técnicos. La interrupción de un técnico en su trabajo también tendrá un impacto sobre su efectividad. Además, como no hay ningún registro del funcionamiento incorrecto ni sobre las causas o solución propuesta, no puede haber capitalización sobre esta intervención. Finalmente, como no hay un seguimiento, será imposible determinar la criticidad de una incidencia aislada, pero que podría evolucionar y convertirse en una crisis más o menos grave. Sin embargo, si se ha puesto en marcha una gestión de incidencias, se pueden identificar varios puntos positivos:
Reactividad: el usuario puede acceder rápidamente a un técnico que le proporcione asistencia. Menos pérdida de tiempo para el usuario y también para sus compañeros, a los que no molestará más.
Eficacia de un técnico: ya no se le molesta durante una actividad planificada.
Capitalización del saber: si se registra una incidencia, en caso de que vuelva a parecer una incidencia del mismo tipo, el conjunto de técnicos del servicio sabrán lo que conviene hacer, lo que ahorra tiempo en el tratamiento de las incidencias y minimiza la pérdida de tiempo por parte del usuario.
Prevención: será posible identificar correctamente una incidencia menor antes de que se convierta en crítica, con el riesgo de que esto provoque una situación de crisis.
Atención: el personal deberá tener la formación necesaria para poder realizar una misión de soporte telefónico. No es suficiente con ser un excelente técnico para poder hacerse cargo de una llamada telefónica de un usuario. Es imprescindible que el personal que trata las incidencias, además de sus competencias técnicas, tenga capacidad de relación y sepa mostrar empatía durante el tratamiento de una llamada. La selección y formación del personal será, por lo tanto, muy importante.
3. Objetivo del proceso El objetivo principal del proceso de gestión de incidencias es: «Restaurar un servicio operativo tan rápido como sea posible, minimizando el impacto en la empresa y asegurando que se mantienen los niveles de servicio y disponibilidad acordados». El funcionamiento normal de un servicio se define como el funcionamiento del servicio dentro de los límites acordados de servicio (SLA). También hay que tener en cuenta otros objetivos:
Asegurar que se usan los métodos estandarizados y los procedimientos, para garantizar una respuesta rápida y eficaz.
Aumentar la visibilidad de las incidencias y comunicación entre el negocio y la organización de los TO.
Mantener la satisfacción del cliente en relación con la calidad de los servicios de TI.
4. Definiciones La definición de incidencia es la siguiente: «Todo evento operativo que no forma parte de las operaciones estándares de un sistema, que provoca o pueda provocar una interrupción del servicio o una alteración de su calidad». La definición de evento es la siguiente: «Un cambio de estado que tiene un significado para la gestión de un componente de configuración (CI) de un servicio informático». La definición de alerta es la siguiente: «Una advertencia que indica que se ha alcanzado un umbral, ha cambiado alguna cosa o se ha producido un error». La definición de petición de servicio es la siguiente: «Una petición por parte de un usuario de información, un consejo para un cambio estándar o para el acceso a un servicio informático, por ejemplo, restaurar una contraseña o proporcionar un servicio informático estándar para un nuevo usuario».
5. Perímetro La gestión de incidencias trata las incidencias reportadas por:
Los usuarios (por medio del centro de servicios).
El personal técnico.
La supervisión técnica.
Algunos ejemplos de incidencias:
A nivel de hardware: Puesto de trabajo averiado. Impresora no operativa. Recurso no disponible o inaccesible. Alerta o excepción generada automáticamente por un componente del sistema.
A nivel de aplicación: Servicio no disponible. Funcionamiento incorrecto de la aplicación. Pregunta sobre la utilización del servicio.
6. Roles y función Entre los roles encontramos:
Los grupos de primer y, ocasionalmente, de segundo y tercer nivel (si existen), así como los grupos de expertos.
El responsable de incidencias.
El propietario del proceso.
En cuanto a la función, hallamos la de gestor del centro de servicios.
7. Indicadores Se pueden establecer varios indicadores para medir el funcionamiento del proceso:
Número de incidencias creadas.
Número de incidencias resueltas en el primer contacto.
Duración media del tratamiento de una incidencia.
Número de incidencias tratadas sin contar los retrasos de las SLA.
Número de incidencias escaladas.
Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se ponga en marcha.
8. Descripción del proceso
El proceso de gestión de incidencias
9. Conceptos básicos a. El ciclo de vida de una incidencia El tratamiento de una incidencia se desarrolla en varias etapas. Normalmente se habla del ciclo de vida de una incidencia. Las peticiones de servicios, consultas y eventos se tratan por medio del centro de servicios y se registran en el ámbito del proceso de gestión de incidencias. En el ámbito de la gestión de incidencias, también abordaremos las nociones de escalado e incidencia principal.
El ciclo de vida de las incidencias Ahora vamos a ver en detalle cada una de las etapas del ciclo de vida.
b. Registro de una incidencia La primera etapa del tratamiento de una incidencia consiste en registrarla en la herramienta de gestión que se ha puesto en marcha en el centro de servicios.
Se deben registrar todas las incidencias, sin excepción. En caso contrario, no será posible conocer realmente la actividad de los equipos del centro de servicios, ni hacer un seguimiento en caso de llamada de un usuario.
En esta etapa, el técnico debe identificar al solicitante. Si ya se ha puesto en marcha el proceso de gestión de los activos y configuraciones (SACM), será posible encontrar sus datos en la herramienta de gestión de incidencias, a partir de su nombre o de su identificador. Sin embargo, el técnico deberá validar con el usuario la exactitud de la información. En caso contrario, corresponderá al técnico registrar el conjunto de datos del usuario.
c. Clasificación Esta es, sin duda, la etapa más importante en la gestión de incidencias.
La categorización Permite determinar cuál es el hardware, servicio o personas implicadas en la incidencia y el nivel de prioridad que le ha sido asignado. El técnico será capaz de categorizar la incidencia por medio del interrogatorio al usuario.
Atención: el usuario describe, en general, los síntomas que ha identificado, pero estas no son obligatoriamente las causas de la incidencia. Por lo tanto, es posible que la categorización evolucione durante el tratamiento de la incidencia. La categorización nos va a ayudar a identificar cuál es el SLA que se debe tener en cuenta para definir la prioridad de la incidencia. Esta categorización va a permitir identificar el grupo de soporte al que se debe dirigir la llamada, en la medida en que el técnico no sea capaz de tratarla él mismo. Durante esta etapa, el técnico identificará, si es posible, el elemento de configuración (Configuration Item - CI) implicado. Durante esta etapa, el técnico identificará si la petición es de servicio. En este caso, la petición se tratará por el procedimiento de tratamiento de peticiones de servicio. Muchas incidencias son recurrentes y, en este caso, las causas y las soluciones pueden ser conocidas. Por este motivo, es posible que durante esta etapa el técnico necesite consultar la base de problemas y errores conocidos. Si se identifican los elementos comunes, se podrá poner en práctica rápidamente la solución definitiva o una temporal. En caso contrario, implicará búsqueda y diagnóstico por el grupo de soporte que se encargará de la incidencia.
La priorización La priorización se lleva a cabo basándose en dos parámetros:
El impacto.
La urgencia.
Estos parámetros se deben definir en el contrato de servicios (Service Level Agreement SLA). En función de estos dos parámetros, se puede definir una tabla de asignación de prioridades. La combinación de estos dos parámetros va a permitir definir la prioridad de la incidencia.
Tabla de definición de prioridades Esta tabla de asignación debe indicar los plazos de resolución previstos. Esta tabla debe estar a disposición de los técnicos. Hoy en día, la mayor parte de las herramientas de gestión de llamadas permiten integrar esta tabla en la configuración de la herramienta.
La prioridad de una incidencia siempre se debe determinar a partir de esta tabla. El usuario no debe decidir el nivel de prioridad de su llamada. En caso de que el usuario proteste por el nivel de prioridad, el técnico no debe faltar a la regla y deberá elevar la protesta a sus superiores.
El impacto El impacto de una incidencia se determina en función de criterios definidos en el contrato de servicios (SLA).
El impacto de un funcionamiento incorrecto no es el mismo si este afecta a un puesto de trabajo o a un servidor. Del mismo modo, en términos de software, si el funcionamiento incorrecto afecta a una aplicación administrativa, el impacto no será el mismo que si afecta a una aplicación empresarial. El número de usuarios afectados también se tiene en cuenta en la definición del impacto. Generalmente se definen un mínimo de tres niveles:
Alto: afecta a un número importante de usuarios o está implicada una aplicación principal.
Medio: afecta a un número limitado de usuarios o está implicada una aplicación estándar.
Bajo: afecta a un único usuario o a muy pocos o está implicada una aplicación administrativa.
Los diferentes niveles se deben definir para cada servicio en el ámbito del SLA.
La urgencia La urgencia también se define en el SLA. Generalmente se establecen un mínimo de tres niveles:
Alto: es una aplicación o un equipo crítico.
Medio: es una aplicación o un equipo no crítico.
Bajo: el usuario puede continuar trabajando, aunque de forma no óptima.
La prioridad Es necesario definir en qué plazo se debe restablecer el servicio. Se construye una tabla de prioridad a partir de los parámetros de impacto y urgencia. Es preciso definir los plazos de restablecimiento del servicio en relación con el nivel de prioridad.
Adicionalmente a los niveles de prioridad definidos a partir del impacto y la urgencia, se puede definir un nivel de prioridad sin que tenga asociado un plazo de restablecimiento del servicio. En este caso, se debe planificar la intervención e informar al usuario del plazo de planificación.
d. Incidencia principal Más allá de la priorización de una incidencia, existen circunstancias para las que es necesario tomar medidas particulares. Por ejemplo, en caso de que la red de comunicación de la empresa sea totalmente inaccesible para todos los usuarios. En este tipo de situaciones, se califica la incidencia como incidencia principal.
Esto significa que se va a activar un procedimiento particular con el objetivo de tratar la incidencia lo más rápido posible, poniendo en práctica los recursos adecuados a una situación como esta. Esto se puede parecer a lo que se conoce generalmente como una situación crítica.
e. Escalado Existen dos casos de escalado. Uno de ellos forma parte del tratamiento normal de una incidencia y el otro es, y debe seguir siendo, excepcional.
Esquema de la gestión del escalado Escalado funcional: es el envío de una incidencia a un nivel de asistencia superior, debido principalmente a la falta de conocimiento o experiencia de un técnico, o porque ha transcurrido el plazo de tiempo acordado en el SLA para tratar la incidencia o está próximo a terminar.
Generalmente, las herramientas de gestión de incidencias actuales permiten desencadenar este escalado funcional de manera automática, en función de los plazos previstos en el SLA.
En este tipo de escalado, las incidencias cambian de propietario. Escalado jerárquico: enfoque adoptado durante una actividad cuando es probable que la resolución de una incidencia no se realice a tiempo o no vaya a ser satisfactoria. Los encargados de la gestión deben tomar rápidamente la decisión apropiada. Este tipo de escalado también se pone en marcha cuando un cliente solicita una modificación de la prioridad asignada a su incidencia.
En este tipo de procesos de escalado, las incidencias no cambian de propietario.
f. Investigación y diagnóstico Durante esta fase, el técnico llevará a cabo las investigaciones necesarias para determinar las verdaderas causas de la incidencia. Para ello, preguntará al usuario y consultará las bases de datos que tiene a su disposición. Entre ellas se encuentran las bases de datos de problemas y errores. Es importante tener informado al cliente durante esta fase y, cuando sea posible, ofrecerle una solución temporal. Por ejemplo, para una incidencia relacionada con una impresora, se le puede proponer imprimir en otra impresora.
No hay que olvidar el objetivo del proceso de gestión de incidencias: minimizar el impacto sobre el servicio. Todas las investigaciones y operaciones llevadas a cabo durante esta fase se deberán registrar en la herramienta de gestión de incidencias para garantizar su trazabilidad, así como para permitir un análisis global de las incidencias, que se llevará a cabo en el proceso de la gestión de problemas.
g. Resolución La resolución de la incidencia se puede llevar a cabo basándose en una solución aportada por:
El centro de servicios.
Un grupo de soporte.
La gestión de problemas.
Un RFC.
La información relativa a las operaciones puestas en práctica para la resolución de la incidencia se deben registrar en la herramienta de gestión de incidencias.
h. Cierre
En principio, cualquier incidencia se puede cerrar sin el consentimiento de la persona que está en el origen de la incidencia. En la realidad, será necesario establecer excepciones, ya que no es posible mantener abiertas las incidencias más allá de un cierto tiempo. Por ejemplo, una de las opciones utilizadas en algunas empresas es considerar que, en caso de no obtener respuesta de un usuario contactado por correo electrónico, el ticket se cierra de manera administrativa. La ausencia de respuesta puede ser consecuencia de varios factores: ausencia de larga duración, baja en la empresa... En esta fase, el centro de servicios se debe asegurar de que el registro de las diferentes acciones realizadas durante el tratamiento de la incidencia se ha hecho correctamente en la herramienta de gestión de incidencias.
10. Beneficios y dificultades a. Beneficios La gestión de incidencias no debería ser un centro de coste. Es un centro de beneficios para la empresa. El coste del centro de servicios y la gestión de incidencias siempre es compensado por las ganancias en productividad que aporta a la empresa: disminución de la no disponibilidad del personal, del número de incidencias y gestión proactiva de estas.
b. Dificultades potenciales La principal dificultad es convencer a todos los usuarios de que utilicen el centro de servicios y, por lo tanto, la gestión de incidencias. La segunda es convencer a los técnicos para que registren todas las incidencias, aunque el tiempo de entrada de datos en la herramienta sea varias veces superior al tiempo que lleva la respuesta al usuario. Si no se registra el conjunto de incidencias, será difícil demostrar que el centro de servicios es un centro que genera beneficios.
Gestión de problemas 1. Enfoque En esta sección vamos a ver cómo se gestionan los problemas. En la sección anterior hemos visto la gestión de incidencias. Como el proceso incidencia, el proceso gestión de problemas es, a menudo, uno de los primeros en aplicarse, después del centro de servicios y de la gestión de incidencias, ya que permite iniciar gradualmente la estrategia ITIL.
2. ¿Por qué una gestión de problemas? El objetivo principal del proceso de gestión de incidencias es restaurar lo más rápidamente posible un servicio normal y minimizar el impacto sobre las aplicaciones de negocio. Este objetivo es el que no permite, en general, que gestión de incidencias busque la causa subyacente desconocida de las incidencias. Por lo tanto, es necesario confiar a otro proceso la responsabilidad de buscar esta causa original, lo que puede llevar tiempo.
Atención: habitualmente se habla de «causa desconocida», «causa subyacente desconocida», «causa inicial» o «causa primera» para definir la causa de un funcionamiento incorrecto en la prestación de un servicio o de la incidencia. Todos estos términos tienen el mismo significado y valor.
3. Objetivos del proceso El objetivo principal del proceso de gestión de problemas es: «Minimizar el impacto en la empresa durante las incidencias y problemas derivados de errores en la infraestructura, y prevenir la aparición de incidencias, problemas y errores, de forma proactiva». Para ello, el proceso tiene por objetivo identificar la causa raíz del funcionamiento incorrecto y de las incidencias, mitigar su impacto y encontrar, si es posible, una solución rápida y definitiva que impida la reproducción de estos funcionamientos incorrectos e incidencias. Cuando sea posible, la gestión de problemas puede, en un primer momento, proporcionar una solución temporal, antes de buscar una solución definitiva. Esto debería permitir la vuelta al funcionamiento normal del servicio. El proceso es reactivo y proactivo al mismo tiempo, en función de la actividad implicada. Se proporcionan explicaciones detalladas en la sección Gestión de problemas - Conceptos básicos.
Recordatorio: el funcionamiento normal de un servicio se define como un funcionamiento dentro de los límites acordados del servicio (SLA).
4. Definición La definición de problema es la siguiente: «Un problema es la causa subyacente desconocida de una o varias incidencias».
5. Perímetro La gestión de problemas trata todos los problemas reportados por:
La gestión de eventos.
La gestión de incidencias.
La gestión de problemas también debe:
Llevar a cabo una actividad de seguimiento y control de las incidencias.
Tener una actividad de control de errores.
Realizar una gestión proactiva de los problemas.
6. Roles Entre los roles se encuentran:
Los grupos de tercer nivel, si existen, así como los grupos de expertos.
El responsable de problemas.
El propietario del proceso.
7. Indicadores Se pueden poner en marcha varios indicadores para medir el funcionamiento del proceso:
Número de problemas creados.
Número de problemas importantes.
Número de errores conocidos, registrados en la base de datos de errores.
Número de problemas resueltos en el periodo.
Duración media del tratamiento de un problema.
Número de problemas tratados más allá de los plazos acordados en los SLA (si se han definido).
Número de RFC remitidos a la gestión de cambios.
Número de RFC cerrados sin generación de incidencia o de un nuevo problema.
Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se establezca.
8. Descripción del proceso
El proceso de gestión de problemas
9. Conceptos básicos a. El ciclo de vida de un problema El ciclo de vida de un problema está relacionado con el ciclo de vida de las incidencias. Normalmente, una o varias incidencias están relacionadas con el origen de un problema. Como se señala en la gestión de incidencias, el objetivo de este proceso es restaurar el servicio normal en el menor tiempo posible. Para ello, es esencial que el centro de servicios cuente con una base de conocimientos documentados (base de datos de errores conocidos), para ayudar en un diagnóstico rápido. La puesta al día de la base de datos es una de las actividades de la gestión de problemas.
El siguiente diagrama muestra la relación entre el proceso de gestión de incidencias y el proceso de gestión de problemas, incluida la actualización de la base de datos de errores conocidos, así como la creación de un RFC.
El ciclo de vida de los problemas
b. Las actividades de la gestión de problemas Las principales actividades de la gestión de problemas son las siguientes:
Gestión de problemas.
Control de errores.
Gestión proactiva de problemas.
Gestión de problemas La gestión de problemas tiene un rol importante en la prestación de servicios. Permite identificar el CI o los CI (Configuration Item) responsables del mal funcionamiento. Identificar las causas principales de una o varias incidencias puede permitir limitar el número de estas, en particular en el caso de incidencias recurrentes, proporcionando una solución definitiva. Algunas veces, la gestión de problemas puede entrar en colisión con el objetivo de la gestión de incidencias: restaurar el servicio normal lo más rápidamente posible. De hecho, algunas veces es necesario tomar un tiempo para identificar y analizar la causa raíz de un problema. Esto significa congelar el estado del CI el tiempo que dura este análisis, lo que va en contra del objetivo de la gestión de incidencias. Por lo tanto, será necesario recurrir al arbitraje para decidir qué actitud tomar. En caso de recurrencia de las incidencias, la decisión adecuada consistirá en tomar el tiempo útil y necesario para realizar este análisis. La gestión de problemas también depende mucho de las acciones de la gestión de incidencias. Es imprescindible que el conjunto de acciones realizadas para el tratamiento de una incidencia (prueba, soluciones temporales, arreglos temporales...) se registren para
que el análisis preliminar realizado por la gestión de problemas pueda ser eficaz. También es primordial que la gestión de incidencias identifique los CI afectados o implicados en la incidencia.
Control de errores
Control de errores El objetivo del control de errores es identificar, evaluar, supervisar los errores y, cuando sea posible y económicamente interesante, eliminarlos.
Tratamiento de errores Cuando se ha implementado con éxito la RFC que se ha puesto en marcha para la gestión de cambios, se puede cerrar el error y los problemas que tiene asociados.
Gestión proactiva de problemas La gestión proactiva de problemas es una de las actividades importantes de la gestión de problemas. El objetivo de esta actividad es prevenir la aparición de incidencias o de un funcionamiento incorrecto en la prestación de servicios. Para ello, la gestión de problemas debe analizar, en intervalos regulares, las incidencias y problemas. Este análisis debe permitir definir las tendencias e identificar los CI que potencialmente pueden causar la aparición de nuevas incidencias. Este análisis se puede completar con un análisis de costes asociados a la resolución de incidencias.
Ver el anexo: las secciones Análisis de Kepner y Tregoe y Diagrama de Ishikawa.
10. Beneficios y dificultades a. Beneficios Uno de los beneficios principales de la gestión de problemas es la reducción del número de incidencias. También se obtendrá una mayor corrección de incidencias en el centro de servicios y, al mismo tiempo, los técnicos se benefician de una base de datos de errores conocidos. Por otro lado, el análisis proactivo de tickets de incidencias puede resaltar los problemas potenciales.
Todos estos elementos contribuyen a mejorar la disponibilidad del servicio.
b. Dificultades potenciales La gestión de problemas necesita la identificación y formación continua de los técnicos que en general tienen un nivel técnico superior al de los técnicos del centro de servicios. Posteriormente, es imprescindible separar las actividades de gestión de incidencias, de aquellas que pertenecen a la gestión de problemas. Estos son dos procesos con objetivos opuestos. En una pequeña empresa, los técnicos deben tener conocimiento, en todo momento, del proceso en el que van a trabajar, principalmente si son las mismas personas las que aseguran la realización de las tareas.
Gestión de consultas 1. Enfoque En esta sección vamos a ver cómo se gestionan las consultas, también llamadas peticiones de servicio, en el marco de la fase de explotación de servicios. Ya hemos visto en la sección anterior la aplicación del centro de servicios. La gestión de consultas se asegura a través del centro de servicios. Existen varios tipos de consultas. Algunas son el objeto de una simple transmisión a un equipo, grupo o función, mientras que otras necesitan un tratamiento más importante o largo. La gestión de cambios estándar también se asegura a través de este proceso.
2. Objetivos del proceso «El objetivo principal del proceso de gestión de consultas es responder a todas las peticiones y preguntas que recibe el centro de servicios». Los objetivos de la gestión de consultas son los siguientes:
Suministrar un canal a los usuarios para solicitar y obtener los servicios estándares, para los que se han definido autorizaciones y cualificaciones.
Suministrar una información al cliente y a los usuarios de la disponibilidad de un servicio y el procedimiento para obtenerlo.
Origen para entregar las peticiones de cambio estándares.
Mantener la satisfacción del cliente y de los usuarios, a través de un proceso eficiente.
Tener en cuenta las reclamaciones de los usuarios o del cliente.
3. Perímetro El perímetro de la gestión de consultas se aplica a todas las peticiones de los usuarios.
4. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de consultas recibidas.
Número de consultas tratadas en modo excepción.
Número de peticiones de cambio estándares.
Número de consultas rechazadas.
Esta lista no es exhaustiva; conviene definir los indicadores en función de la estructura que se aplique.
5. Descripción del proceso
El proceso de gestión de problemas
6. Conceptos básicos Las consultas pueden afectar a diferentes actividades:
Petición para el suministro de un equipamiento, con o sin autorización inicial.
Petición para la instalación de un software.
Petición para obtener un acceso a una base de datos.
Petición para la puesta en marcha de una petición de cambio estándar.
Esta lista no es exhaustiva; conviene definir las peticiones en función de la estructura que se aplique.
Una buena gestión de consultas implica, obligatoriamente, la puesta en marcha de modelos.
Gestión de accesos 1. Enfoque En esta sección vamos a ver cómo se gestionan los accesos en el marco de la fase de explotación de servicios. Hemos visto anteriormente la aplicación del centro de servicios; la puesta en marcha de este proceso está relacionada con el centro de servicios.
2. Objetivos del proceso Los objetivos de la gestión de accesos son los siguientes:
Gestionar los accesos aplicando políticas de seguridad definidas en el proceso de gestión de la seguridad.
Responder de manera eficaz a las peticiones para garantizar el acceso a los servicios.
Modificar los derechos asociados a una petición de accesos.
3. Perímetro El perímetro de la gestión de accesos afecta a todas las peticiones de acceso, ya sean accesos a un servicio o grupo de servicios, a bases de datos o redes, que necesiten un control de accesos.
4. Indicadores Se pueden aplicar varios indicadores para medir el funcionamiento del proceso:
Número de peticiones.
Número de rescisiones.
Número de intentos fraudulentos.
5. Descripción del proceso
El proceso de la gestión de accesos
6. Conceptos básicos El control de los accesos se basa en varias actividades:
Gestión de contraseñas.
Asignación de derechos de acceso.
Modificación de derechos de acceso.
Eliminación de derechos de acceso.
Acciones proactivas sobre los accesos.
La gestión de los accesos debe garantizar que solo los usuarios autorizados puedan acceder a un servicio. También es imprescindible identificar los intentos de intrusión a través de las redes. Las tecnologías de identificación de un usuario evolucionan constantemente.
Por lo tanto, será imprescindible adaptarse a los métodos con mejor rendimiento.
Las políticas de seguridad se definen en el proceso de gestión de la seguridad. El proceso de gestión de los accesos pone en marcha estas políticas.
MEJORA CONTINUA DE SERVICIOS (CSI) Enfoque El ciclo de vida de la gestión del servicio se divide en varias fases. El proceso de mejora continua de servicios (Continual Services Improvement) gestiona la iteración entre esas diferentes fases. Un proverbio dice «el que no avanza retrocede». Por este motivo, es necesario que, de forma regular, por no decir constantemente, se alineen de nuevo los servicios con las cambiantes necesidades del cliente y de la empresa.
¿Por qué un proceso de mejora continua de servicios? Uno de los objetivos de la puesta en marcha de ITIL es proporcionar un valor añadido a los servicios propuestos por la organización TI a sus clientes. Para responder a este objetivo, es necesario poner en marcha un proceso que permita medir y mejorar el nivel de madurez del servicio y los procesos.
Objetivos del proceso Los principales objetivos del proceso de mejora continua de los servicios son los siguientes:
Analizar los resultados de los diferentes contratos (SLA, OLA y UC).
Identificar e implementar las áreas de mejora para los servicios y procesos.
Mejorar la rentabilidad, sin disminuir el nivel de calidad.
Mejorar la relación con el cliente.
Asegurar que los métodos de gestión de la calidad son eficaces.
Definición ROI: Retorno de la inversión (Return On Investment). VOI: Valor de la inversión (Value On Investment). Valores intangibles: son los beneficios no expresados en valor económico; por ejemplo, la mejora de la satisfacción del cliente, el aumento de la competencia de los actores de la organización TI, la disminución de los riesgos...
Perímetro Los procesos de mejora continua de los servicios implican al conjunto de la gestión de servicios (procesos, servicios, organización, personal...). El perímetro abarca los servicios ofrecidos y los procesos internos.
Roles Los principales roles son:
Propietario del proceso.
El responsable de la mejora continua de servicios.
Todos los demás responsables de procesos.
Todos los demás propietarios de procesos.
Propietario del servicio.
Indicadores Se pueden aplicar varios indicadores:
Los KPI.
Los CSF.
Las bases de referencia.
La medición de los servicios.
Las métricas.
Descripción del proceso
El proceso de mejora continua de servicios
Conceptos básicos
El ciclo de vida de la mejora continua de servicios El ciclo de vida de los servicios tiene las fases siguientes:
Definir la estrategia de gestión de servicios (Service Strategy - SS).
Diseñar de servicios para apoyar la estrategia (Service Design - SD).
Implementar los Transition - ST).
Soportar los servicios de gestión de actividades operativas (Service Operation - SO).
servicios
para satisfacer los
requisitos
de
diseño (Service
1. Las relaciones con los otros procesos El proceso de mejora continua de los servicios está relacionado con el conjunto de los procesos. Participa en todas las fases del ciclo de vida de los servicios.
2. El valor añadido al negocio La mejora continua de los servicios añade valor al negocio a través de:
Las mejoras.
Los beneficios.
Un retorno de la inversión.
Un valor de inversión.
Los valores intangibles.
3. Las herramientas para la mejora Varias herramientas contribuyen a la mejora continua de los servicios. Ya hemos visto algunas en los capítulos anteriores:
La Rueda de Deming (en el capítulo ITIL y las normas).
Las 4 P (en la sección Consideraciones sobre el diseño de los servicios - capítulo Los procesos del diseño de los servicios).
Vamos a ver otras dos.
a. El modelo CSI
El enfoque Continual Service Improvement (CSI) A la pregunta «¿Adónde queremos ir?», corresponde una actividad que consiste en identificar la visión que tenemos de los servicios y procesos. A la pregunta «¿Dónde estamos actualmente?», corresponde una actividad de evaluación de la situación actual.
A la pregunta «¿Dónde queremos estar?», corresponde una actividad de definición de objetivos medibles y la prioridad de las mejoras. A la pregunta «¿Cómo conseguir nuestro objetivo?», corresponde una actividad de puesta en marcha de las acciones de mejora. A la pregunta «¿Cómo sabemos que hemos llegado?», corresponde una actividad de verificación de las medidas y de las métricas aplicadas para asegurar que los objetivos fijados se han alcanzado. A la pregunta «¿Cómo vamos a continuar?», corresponde una actividad de control, para asegurar la eficacia del proceso de mejora continua de los servicios.
Ver también la descripción en el capítulo Puesta en marcha de un proyecto ITIL.
b. El proceso de mejora en 7 etapas
El proceso de mejora en 7 etapas Etapa 1 - Identificación de la estrategia para la mejora
Visión y estrategia
Necesidades de negocio
Estrategias
Objetivos tácticos
Objetivos operativos
Etapa 2 - Definir lo que vamos a medir Etapa 3 - Recoger los datos
Qué
Cuándo
Cómo
Criterios para evaluar la integridad de los datos
Objetivos operativos
Medir los servicios
Etapa 4 - Tratamiento de los datos
Frecuencia
Formato
Herramientas y sistema
Exactitud
Etapa 5 - Análisis de los datos
Relaciones
Tendencias
Conforme con la planificación
Objetivos alcanzados
Acciones correctivas
Etapa 6 - Presentación y uso de la información
Evaluación
Resumen
Planes de acción...
Etapa 7 - Poner en práctica las medidas correctivas
El proceso de mejora continua en siete etapas está directamente relacionado con los objetivos estratégicos, tácticos y operativos. Mide los servicios y los procesos de gestión de los servicios.
PUESTA EN MARCHA DE UN PROYECTO ITIL Etapas preliminares Antes de poner en marcha un proyecto ITIL, es necesario estar seguros de una serie de puntos que garanticen una puesta en marcha exitosa: Definición del proyecto. Ciclo de implantación. Elección de los procesos de puesta en marcha inicial. La implantación anterior de una certificación ISO 9001 puede favorecer la implantación de un proyecto ITIL.
Definición del proyecto La primera actividad de la puesta en marcha de un proyecto ITIL consiste en definir cuál es la visión de la organización TI para la empresa. Esta actividad es responsabilidad de la Dirección de la empresa. La dirección de la organización, por supuesto, prepara un conjunto de documentos para presentar el proyecto a la dirección de la empresa y, de esta manera, proporcionarle los elementos que le permitirán tener en cuenta y apoyar el proyecto. Esto plantea la cuestión de la gestión documental del proyecto desde el momento inicial y, al final, la gestión documental de los procesos ITIL. Una gestión documental rigurosa implica que se documenten las diferentes actividades del proyecto y los procesos. Para esto, es necesario poner en práctica en los documentos la gestión de los participantes, definiendo fundamentalmente sus funciones: propietario del proceso, redactor, validador y destinatario. En el modelo RACI, el propietario del proceso se define como «Accountable» (ver en el anexo la descripción del modelo). Es conveniente utilizar el término «propietario del proceso» en los documentos que describen el proceso, salvo en el caso de la documentación en inglés. También será necesario definir y publicar un documento sobre la gestión de los derechos de acceso, para que cada uno sepa quién está autorizado a hacer qué y cuándo. Como en toda gestión documental, será necesario asegurar la gestión de las versiones de los diferentes documentos, así como la versión de los procesos a través de estos diferentes documentos. Vaya a la sección Puesta en marcha de un proyecto ITIL - Puesta en marcha de la gestión del conocimiento.
Esta gestión será más eficaz si, al mismo tiempo, se lleva a cabo una mejora de la calidad del proyecto.
Ciclo de implantación La implantación de los procesos se debe hacer siguiendo una determinada lógica. Se puede adoptar el principio de funcionamiento descrito en el capítulo Mejora continua de los servicios de ITIL, para estudiar la puesta en marcha del proyecto. Para más detalle sobre el proceso, vaya al capítulo Mejora continua de los servicios (CSI). Para ello, se puede utilizar el siguiente modelo:
Modelo del ciclo de implantación Este modelo se basa en seis etapas que vamos a describir a continuación.
Etapa 1 - ¿Cuál es la visión? Esta etapa permite validar la visión y los objetivos que la Dirección de la empresa quiere que ponga en marcha la Dirección de la organización TI. Especialmente, esta etapa debe permitir identificar cómo la organización TI va a poder aportar un valor añadido a las áreas de negocio de la empresa o del cliente.
Los procesos ITIL se pueden utilizar como modelo de organización, para identificar aquellos que aportan a la empresa un retorno de la inversión lo más rápidamente posible. En esta etapa es necesario establecer una comunicación sólida por parte de la Dirección de la empresa para anunciar y apoyar este proyecto.
Etapa 2 - ¿Dónde estamos actualmente? La segunda es una etapa de observación y análisis. Para conocer el camino que se debe recorrer y definir las medidas que se deben poner en marcha, en primer lugar es necesario verificar la situación actual. Esta operación permite conocer el grado de madurez de la organización ITIL. Esta etapa es importante, ya que le permite identificar cómo difiere la organización actual de la propuesta por ITIL. En esta etapa es necesario abordar aspectos muy diferentes: La visión a largo plazo. Los procesos de gestión (según lo descrito por ITIL). El establecimiento de una verdadera cultura de servicio. Los medios tecnológicos. Los medios humanos. La formación. La documentación... En esta etapa, la organización TI ha de establecer un esquema de comunicación que deberá mantener durante todo el desarrollo del proyecto. Es imprescindible obtener la adhesión de los empleados para que tenga éxito la puesta en marcha de los procesos; la comunicación que se establezca, en todas las formas, será un factor de adhesión. En la segunda etapa, se plantean preguntas sobre el nivel de madurez alcanzado por la empresa en general, y la dirección informática en particular. La medición y el análisis de la situación se lleva a cabo a través de reuniones, seminarios, auditorías o investigaciones.
En la puesta en marcha de una estrategia de calidad, las etapas 1 y 2 se pueden asimilar a la etapa «Act» de la Rueda de Deming (PDCA).
Etapa 3 - ¿Adónde queremos ir? Durante esta tercera etapa, será necesario definir de manera precisa qué organización se establecerá y cuáles son los roles y objetivos que se asignarán a cada propietario de proceso dentro de la organización de TI, en la implantación de la estructura ITIL. En esta etapa se definen cuáles son los niveles de rendimiento esperados y las métricas que permitirán medirlos.
Esta fase, para cada proceso, debe permitir identificar y construir su estructura y relaciones, actuales y futuras, con las otras entidades de la empresa. También durante esta etapa se deben identificar los beneficios, los problemas y los costes esperados de la puesta en marcha del proyecto. Esto pasa por el análisis de las medidas que hay que aplicar para obtener los resultados esperados, tal y como fueron definidos en las etapas anteriores. Se deben definir de manera detallada las necesidades, los recursos (técnicos y humanos) y la carga de trabajo. Se debe elaborar y publicar el plan del proyecto de implantación para explicar cuáles serán los cambios y cómo se pondrán en marcha. En esta etapa la comunicación es muy importante, ya que permitirá al conjunto de la empresa entender cómo se pondrá en marcha el proyecto de implantación.
En la puesta en marcha de una estrategia de calidad, la etapa 3 se puede asimilar a la etapa «Plan» de la Rueda de Deming (PDCA).
Etapa 4 - ¿Cómo llegar a nuestro objetivo? Esta cuarta etapa corresponde a la puesta en marcha del proyecto. Se deben poner en marcha los procesos y se deberá estudiar la medida de su eficacia. En esta etapa es importante desarrollar o mejorar los procesos, después de adaptar o instalar las herramientas informáticas destinadas a sostenerlos. No hay que olvidar que, para que un proceso funcione, necesita establecer un sistema de documentación basado en documentos y procedimientos. También se debe tener en cuenta y realizar la formación del personal. Se debe prever una fase de pruebas y validación antes de pasar a un modo de funcionamiento recurrente. Estas pruebas deben permitir verificar el correcto funcionamiento del proceso y el logro de los objetivos definidos anteriormente por la empresa.
En la puesta en marcha de una estrategia de calidad, la etapa 4 se puede asimilar a la etapa «Do» de la Rueda de Deming (PDCA).
Etapa 5 - ¿Hemos llegado? Esta etapa le debe permitir asegurar que el proyecto puesto en marcha cumpla con las expectativas iniciales de la empresa. Para esto, es necesario medir los resultados de los procesos, ayudándose de las métricas aplicadas en las etapas anteriores y, si es necesario, definiendo nuevas métricas.
Estas medidas deben tener en cuenta la satisfacción del personal y de los clientes de la organización TI. Esta medición se puede realizar utilizando las encuestas de satisfacción. También es importante asegurar la mejora de la calidad del servicio y observar que los niveles de actividades reales se ajustan a las previsiones.
En la puesta en marcha de una estrategia de calidad, la etapa 5 se puede asimilar a la etapa «Check» de la Rueda de Deming (PDCA).
Etapa 6 - Continuar el ciclo de vida de los procesos Esta última etapa, que de hecho no debe ser la última, ya que va a desembocar en la puesta en marcha del proceso de mejora continua del servicio, es importante para el seguimiento de las operaciones. Para ello, es necesario revisar lo que se ha hecho, las dificultades y problemas que se han encontrado, y reflexionar sobre la manera de mejorar. El resultado de esta etapa permitirá poner en práctica la primera etapa del proceso de mejora continua del servicio. Para ello, es importante hacer una evaluación completa del proyecto de implantación, revisar los procesos para asegurar que su contenido está correctamente alineado con los objetivos y verificar que existe un correcto aporte de valor añadido a los procesos de negocio de la empresa o del cliente. Durante esta etapa, también es preciso verificar, controlar y mejorar, si es necesario, las métricas que permitirán medir los resultados del funcionamiento de los procesos (ver el capítulo Mejora continua de los servicios). También es una oportunidad para recordar el mensaje clave: mantener una visión empresarial en la puesta en marcha de los servicios.
La dirección debe llevar a cabo una comunicación al final de este proyecto, destacando las mejoras comprobadas y recordando su fuerte apoyo a este proyecto y a las estructuras y la organización que se han puesto en marcha.
Puesta en marcha del proyecto 1. Plazos de realización En función del tamaño de la empresa y de los medios que se ponen en marcha, los plazos de realización serán más o menos dilatado. Para acelerar el proceso de puesta en marcha, muchas empresas cuentan con la participación de consultores independientes especializados en la aplicación de las estrategias de ITIL. La siguiente tabla da una idea de los plazos de puesta en marcha de los procesos de un proyecto ITIL.
Pequeña/mediana empresa
Procesos ITIL
Gran empresa
Centro de servicios + Gestión de incidencias
2 a 4 meses
4 a 6 meses
Gestión de problemas
1 a 2 meses
2 a 4 meses
Gestión de configuraciones
2 a 6 meses
3 a 10 meses
Gestión de cambios
2 a 6 meses
3 a 10 meses
Gestión del porfolio de servicios + Gestión del catálogo de servicios
1 a 4 meses
3 a 8 meses
Gestión de los niveles de servicio
2 a 4 meses
3 a 6 meses
Gestión de la capacidad
1 a 3 meses
2 a 6 meses
Gestión de la disponibilidad
1 a 3 meses
2 a 6 meses
Tiempo de puesta en marcha de los
procesos Se trata de tiempos medios para una puesta en marcha óptima. Para pequeñas y medianas empresas, la puesta en marcha global de un proyecto ITIL tarda de uno a dos años, en función de los recursos asignados al proyecto y del tamaño de la empresa. El número de oficinas de la empresa también puede modificar el tiempo global de puesta en marcha. En el caso de grandes empresas, el tiempo razonable es de dos a cuatro años, fundamentalmente dependiendo del número de oficinas y de sus implantaciones en diferentes países.
2. Formación de los actores del proyecto En el ámbito de una implantación ITIL, es deseable que todo el equipo directivo de la empresa siga una formación de tipo ITIL Foundation, incluso aunque el paso de la certificación no sea obligatorio.
De manera ideal, esta formación debería incluir a los responsables de las diferentes áreas en una misma sesión, para permitir a unos y otros intercambiar y entender mejor las dificultades que pueden encontrar diariamente en la realización de sus tareas. Una formación como esta permite entender los conceptos principales, así como adquirir un vocabulario común; la formación da a todos los actores un nivel de conocimiento mínimo para llevar a cabo este proyecto de magnitud para la empresa. En una segunda etapa, pero que se puede realizar al mismo tiempo, es imprescindible formar al conjunto de personas de la organización TI. Una vez más, el paso de la certificación ITIL Foundation no es obligatorio, pero sí muy recomendable, ya que requiere una fuerte implicación de los empleados en la formación. Con respecto a las personas que se identifican para ser propietarias de los procesos, es posible hacer que sigan una formación complementaria adaptada a los procesos de los que serán propietarias. Estos cursos de formación se pueden realizar en formato interempresas o intraempresa.
3. Los factores de éxito a. Tener una visión clara del proyecto El objetivo principal de ITIL es sustituir una visión muy orientada a la tecnología por una visión de negocio. Entender ITIL es importante, pero también es necesario identificar qué va a apoyar esto a la actividad de la empresa y a participar en la creación de valor.
b. ITIL es un medio, no un objetivo Algunas direcciones informáticas y proveedores de servicios informáticos utilizan ITIL como una pantalla para protegerse de los usuarios y de sus clientes. ITIL debe servir al objetivo de resolver las incidencias y los problemas encontrados por los usuarios y los clientes, así como al objetivo de la mejora continua de los servicios, y no convertirse él mismo en un objetivo.
c. Preparación de la empresa La puesta en marcha de un proyecto ITIL normalmente es un largo y, algunas veces, difícil camino. La resistencia al cambio siempre existe en las empresas y actúa como freno a este. Se deben desarrollar métodos específicos para explicar este cambio y hacer frente a esta resistencia. La comunicación, en todas sus variedades, forma parte de estas medidas.
d. Comunicación La puesta en marcha de un proyecto ITIL dará lugar a un cambio en las relaciones entre las diversas áreas y la organización TI. La dirección de la empresa debe establecer una comunicación destinada al conjunto del personal de la empresa. Esta acción de comunicación debe usar los resultados tan pronto como estén disponibles, y utilizarlos para mantener una motivación continua de los diferentes actores del proyecto.
Uno de los objetivos de la comunicación será facilitar el paso de la organización TI de una cultura tecnológica a una cultura de servicio.
e. Apoyo de la directiva Los miembros de la directiva de la empresa se deben adherir al proyecto; para ello es imprescindible que la Dirección General de la empresa establezca una comunicación específica con objeto de acompañarlos en este proyecto. Una falta de implicación de la directiva en el proyecto será rápidamente identificada por los diferentes actores y provocará la desmotivación de los actores del proyecto, incluso una resistencia al cambio.
f. Identificar a los propietarios de los procesos La puesta en marcha de un proyecto ITIL tal vez dará lugar a cambios en la estructura de la empresa. Hoy en día muchas empresas están constituidas por un «silo» de competencias o actividades. La puesta en marcha de los procesos, que a menudo abarca varias áreas de competencias, va a necesitar, en algunos casos, una modificación de la estructura jerárquica. Es necesario forzar al conjunto de actores a trabajar de modo colaborativo. Por lo tanto, va a ser necesario identificar a los propietarios de procesos capaces de trabajar de un modo transversal.
g. Formación Una de las grandes aportaciones de ITIL es proporcionar un vocabulario común para todos los actores de la gestión de servicios informáticos. La formación de estos actores hará ganar un tiempo considerable en el establecimiento de los procesos y reforzará la adhesión de los actores (ver más arriba la sección Formación de los actores del proyecto).
h. Apoyar el cambio La implantación de un nuevo sistema o de un nuevo procedimiento implica sistemáticamente una resistencia por parte de las personas que utilizan o producen el elemento modificado. Esta resistencia al cambio es natural y clásica, pero no debe tomarse a la ligera. Para tratar este problema, tanto los usuarios como los miembros de la dirección informática deben entender los objetivos que se buscan, identificar los beneficios y compartir la visión de la nueva organización, para ver el cambio como algo deseable y necesario. La presentación de estos cambios requiere un enfoque gradual y debe conducir a su aceptación por las diversas partes implicadas en el proyecto.
i. Prever un proceso progresivo Los procesos de gestión de servicios de ITIL representan una carga muy importante durante su puesta en marcha y algunas veces van en contra de la madurez de la empresa. Esto puede implicar cierta confusión y una mala integración del conjunto. La solución consiste en pasar por etapas progresivas que respeten los objetivos de la empresa y las futuras evoluciones de su madurez. Esto también permite proyectar la implantación de los procesos desde una óptica de resultados a corto plazo, que favorece su adopción.
j. Definir un proyecto realista Para tener éxito en un proyecto de implantación de ITIL, es necesario tener medios humanos, técnicos, tecnológicos y financieros. Este es un compromiso de medio o largo plazo; en función del tamaño de la empresa, normalmente entre uno y tres años. Hay que tener cuidado con el exceso de ambición en el inicio del proyecto.
Es necesario empezar «poco a poco» y hacer crecer el perímetro progresivamente. No puede haber una operación de tipo Big Bang para implementar un proyecto ITIL; es, obligatoriamente, un proyecto a largo plazo. Querer poner en marcha todos los procesos al mismo tiempo representa un proyecto muy importante, largo y costoso. El peor enemigo durante la implantación de ITIL, como en la mayoría de los proyectos, es la búsqueda de la perfección y la definición de objetivos demasiado ambiciosos. En este caso, los riesgos de desmotivación o rechazo de los actores del proyecto son muy elevados.
k. Definir prioridades La puesta en marcha del proyecto se extiende durante algunos meses, incluso años. Por lo tanto, es imprescindible definir las prioridades de su puesta en marcha. La elección de los procesos se debe hacer en función de las prioridades determinadas por la empresa. De manera ideal, deberán ser prioritarios los procesos que permitan el nacimiento de una cultura de servicio. El establecimiento de un centro de servicios y del proceso de gestión de incidencias se puede hacer de manera simple y obtener resultados rápidamente. La comunicación de estos resultados permitirá una mayor motivación de los actores del proyecto.
4. Elección de los procesos De forma ideal, aunque normalmente no es el caso, sería necesario poner en marcha el conjunto de procesos ITIL en el mismo momento en que se implanta la organización TI. Actualmente, la gran mayoría de las empresas ya han implantado una organización informática. Por lo tanto, es necesario tener en cuenta la existencia de la empresa y establecer un proyecto en función de su realidad. En este contexto, los primeros procesos que se deben poner en marcha son los siguientes:
Generación de la estrategia.
Gestión de incidencias.
Gestión de problemas.
Gestión de configuraciones.
Gestión de cambios y entradas en producción.
5. Definición del equipo de proyecto Es imprescindible trabajar en modo proyecto para tener éxito en la implantación de procesos ITIL. La primera actividad que se debe realizar es definir el equipo de proyecto que se encargará de poner en práctica los procesos y asegurar el seguimiento del proyecto. La tentación de poner en marcha los procesos a medida que sea necesario es un error, ya que esto no implica automáticamente la adhesión del personal y finalmente es, al menos, tan caro como el caso de creación de un equipo de proyecto. Este equipo de proyecto debe preparar un informe del proyecto y validarlo con la Dirección de la empresa y la Dirección de la organización TI.
Sin el soporte real y eficaz de la Dirección de la empresa, no es posible poner en marcha un proyecto ITIL en ella. Es importante que la dirección de la empresa emita un comunicado sobre este proyecto tan pronto se haya tomado la decisión de ponerlo en marcha.
6. Generación de la estrategia En un primer lugar, la dirección de la organización TI debe poner en marcha, de manera paralela, una estrategia para la organización. En este ámbito, debe definir la estrategia que desea poner en marcha para la explotación y transición de servicios. En este estado del proyecto, no es necesario tener una definición completa y definitiva de las estrategias que se van a poner en marcha. El conjunto de estrategias se debe revisar más adelante.
Es durante esta etapa cuando resulta deseable poner en marcha un ciclo de formación ITIL.
7. Puesta en marcha de los procesos de explotación de servicios Normalmente, los procesos de gestión de explotación de servicios son los primeros en ponerse en marcha. Existen varias razones para esta elección:
Visibilidad, tanto a nivel interno de la organización TI como para los clientes y usuarios.
Resultados fácilmente demostrables.
Procesos que con frecuencia se ponen en marcha parcialmente.
Puntos de entrada para más procesos.
Tiempo de puesta en marcha bastante corto.
8. Puesta en marcha del centro de servicios Esta etapa se puede desarrollar al mismo tiempo que las etapas descritas en las secciones Puesta en marcha de la gestión de activos de servicios y configuraciones y Puesta en marcha de la gestión de cambios. Es necesario determinar qué tipo de centro de servicios se implantará: centro de servicios local, centralizado o virtual. La puesta en marcha del proceso de gestión de incidencias debe coincidir con la puesta en marcha del centro de servicios. La comunicación con las otras áreas de la empresa y con el cliente es imprescindible.
Es necesario comunicar al conjunto de actores la puesta en marcha y el modo de funcionamiento del centro de servicios para garantizar el apoyo de todos los actores a la nueva organización y la implementación exitosa del proyecto.
a. Consideraciones sobre la puesta en marcha del centro de servicios en el ámbito de varias estructuras locales La puesta en marcha del centro de servicios necesita tener en cuenta los siguientes elementos:
Establecer los procesos comunes a todas las ubicaciones y procedimientos comunes, si es posible.
Asegurar que las competencias conocidas por una ubicación estén disponibles para el resto de las ubicaciones.
Asegurar la compatibilidad del hardware, el software y la infraestructura de red.
Utilizar los mismos procesos de escalado y mismos códigos de estado en todas las ubicaciones.
Utilizar la misma base de datos compartida.
Estandarizar la clasificación de las peticiones.
En el ámbito de este ejemplo, vamos a decidir poner en marcha un centro de servicios centralizado, por lo tanto, único en la sede de la empresa. El jefe de proyecto responsable de la puesta en marcha del centro de servicios debe tener en cuenta los diferentes recursos de los que dispone, tanto de hardware (PBX, puestos de trabajo [informáticos y de telefonía], redes...) como de software (herramientas de gestión de llamadas, bases de datos, bases de conocimiento, CMS...), además de los recursos humanos (recepcionistas, agentes de soporte de nivel 1, agentes de soporte de nivel n) y, para finalizar, los recursos financieros.
El jefe de proyecto debe tener en cuenta una serie de puntos clave:
Definir objetivos claros y alcanzables.
Inicio sencillo, con un perímetro reducido.
No intentar hacer todo al mismo tiempo.
Adoptar un enfoque por fases.
Implicar y consultar a los clientes.
Implicar y consultar a los usuarios finales.
Formar equipos que aseguren el soporte de los productos/aplicaciones/hardware.
Educar y formar a los clientes y los usuarios en la utilización del centro de servicios.
Asesorar y vender el servicio.
No iremos más allá en la descripción del trabajo del jefe de proyecto: se trata de la puesta en parcha de un proyecto real informático.
Atención: no se pueden poner en marcha todos los niveles de soporte al mismo tiempo. De nuevo, hay que ser modesto y empezar poco a poco, con un servicio, para posteriormente integrar de manera progresiva el conjunto de servicios definidos en el catálogo de servicios.
b. Desarrollo de las operaciones En primer lugar, debe elegir una herramienta de gestión de llamadas que corresponda a sus necesidades. Si ya hay una herramienta operativa, es necesario asegurar que permite todas las operaciones de creación, control y seguimiento de los tickets. También es necesario verificar la configuración de la herramienta en función de las obligaciones definidas en el contrato de servicios. Posteriormente, debe configurar la herramienta para tener en cuenta las reglas definidas en el contrato de nivel de servicios o SLA (ver sección Gestión de los niveles de servicio capítulo Los procesos del diseño de los servicios). En general, los fabricantes de software proporcionan un soporte para la configuración de sus herramientas, ya que normalmente resulta complejo realizar esta configuración de manera óptima.
Atención: no olvide que un error en la configuración de la herramienta, puede tener importantes consecuencias en el cumplimiento del contrato de servicios. La configuración se refiere, en particular a:
Los horarios de soporte.
Los diferentes tipos de llamadas.
Los diferentes códigos de gestión de tickets.
Los diferentes datos relativos a los actores del soporte.
Las nociones de impacto y urgencia, que después permitan definir automáticamente un nivel de prioridad.
Las colas de espera y asignación de llamadas, para cada uno de los tipos de llamadas.
Las reglas de escalado.
Las obligaciones de respetar los plazos de tratamiento.
Todas las otras obligaciones especificadas en el contrato de nivel de servicios.
Esta no es una lista exhaustiva de los puntos que se deben tratar. En una etapa posterior, es obligatorio prever una formación del conjunto de los equipos del centro de servicios (responsables y técnicos) sobre el uso de la herramienta.
Del perfecto manejo de la herramienta de gestión de incidencias dependerá la eficacia y eficiencia del centro de servicios y, por lo tanto, la percepción que tendrán los clientes de él.
9. Puesta en marcha de la gestión de incidencias y problemas En esta etapa será necesario poner en marcha los procesos de gestión de incidencias y problemas. De manera ideal, esta etapa deberá coincidir con la puesta en marcha del centro de servicios. Sea cual sea el tamaño de la organización TI, es deseable identificar correctamente los dos procesos de gestión de incidencias y problemas. Los objetivos de estos dos procesos son distintos y opuestos:
Restablecer el servicio lo más rápidamente posible para la gestión de incidencias; por lo tanto, responder lo más rápidamente posible.
Identificar la causa subyacente desconocida para la gestión de problemas; por lo tanto, tomar el tiempo necesario para analizar e identificar la causa primera real de las incidencias.
Si el tamaño de la organización TI no permite tener dos equipos distintos, en este caso es preferible asignar los roles a los técnicos, dejándoles cambiar de rol de manera regular. Por ejemplo, una parte del equipo asegura la gestión de incidencias por la mañana y cambia de rol por la tarde, para asegurar la gestión de problemas. Esta forma de funcionar también se puede establecer de manera diaria o semanal.
Esta etapa implica estar especialmente atentos a la formación de los técnicos del centro de servicios.
10. Puesta en marcha de los procesos de transición de servicios Después de la puesta en marcha de los procesos de explotación de servicios, es aconsejable poner en marcha los procesos de transición de servicios. Estos, a su vez, suelen ser puntos de entrada para el proceso de diseño de servicios. El proceso de gestión del catálogo de servicios se pone en marcha habitualmente en el mismo momento que los procesos de transición de servicios, ya que servirá de unión entre los procesos de explotación y transición de servicios. Al mismo tiempo, servirá como punto de partida para muchos procesos de diseño de servicios.
11. Puesta en marcha de la gestión de activos de servicio y configuraciones Esta etapa se puede llevar a cabo al mismo tiempo que las etapas descritas en las secciones Puesta en marcha del centro de servicios y Puesta en marcha de incidencias y problemas. Los procesos de gestión de activos de servicio y configuraciones se apoyan en la creación de una base de datos (CMS) que contenga el conjunto de activos de la empresa. La puesta en marcha de la CMS se puede hacer de manera independiente de la puesta en marcha del centro de servicios y de los procesos de gestión de incidencias y problemas, aunque su disponibilidad pueda ayudar al funcionamiento de estos dos procesos. La creación de esta base de datos se apoya en un análisis preciso de su contenido futuro, y fundamentalmente de los atributos y relaciones que se definirán.
Atención: no quiera ir demasiado rápido y demasiado lejos; es necesario ser modesto y comenzar poco a poco, antes de ampliar el perímetro y la granularidad de la CMS. En caso de que ya exista una gestión de Assets en la empresa, eventualmente se podrán utilizar los datos ya disponibles.
Lo importante es mantener actualizada la CMS. Esto se consigue poniendo en marcha el proceso de gestión de cambios.
a. ¿Qué beneficios se pueden obtener de la puesta en marcha? La puesta en marcha de la gestión de activos de servicio y configuraciones (SACM) permite a la empresa obtener una mejor gestión de sus activos y configuraciones. Esto será tanto más importante cuanto que los elementos definidos e identificados en este proceso sean puntos de entrada para muchos otros procesos.
No se trata aquí de detallarlos todos, pero podemos tomar como ejemplo los casos siguientes:
Mejora de la seguridad.
Mejora de la movilidad del personal.
Mejora de la gestión de configuraciones tipo.
b. Los riesgos en términos de seguridad Un problema frecuente que se encuentra la mayoría de las empresas: la gestión de los derechos de acceso. ¿Cómo es la asignación de derechos de acceso en las empresas? Tras entrar en la empresa, al empleado se le asignan derechos de acceso basados en la posición que va a ocupar. Las complicaciones comienzan cuando el empleado cambia de puesto. Lógicamente, a este empleado se le deberán retirar una serie de derechos, aquellos que ya no corresponden a su nuevo puesto, y deberá recibir otros nuevos, siempre en función de su nuevo puesto. En la realidad, y de hecho sucede en muchas empresas, cuando un empleado cambia su puesto solo se le asignan sus nuevos derechos, lo que puede, a la larga, provocar muchos problemas. Fundamentalmente, esta falta de rigor en la gestión de derechos provocará que el empleado tenga que realizar varias llamadas al centro de servicios para contrarrestar la falta de acceso a archivos o aplicaciones debido a los derechos que no se concedieron. Mucho más grave es mantener los derechos de acceso del empleado a archivos o aplicaciones, aunque el personal asignado al nuevo puesto ocupado por el empleado no esté autorizado a acceder a estos archivos o aplicaciones. Los riesgos en los que se incurre por este funcionamiento incorrecto pueden ser muy elevados, ya sea por errores de uso o manipulación involuntaria o debido a una voluntad de acción maliciosa.
Estos riesgos se pueden evitar aplicando las configuraciones tipo, identificadas en la CMS, para cada tipo de función. Por lo tanto, basta aplicar, por cada cambio de función de un empleado, la configuración correspondiente a su nueva función.
c. Las dificultades encontradas durante el movimiento de personal Normalmente, se presentan tres situaciones diferentes en este punto.
Personas con discapacidad En todas las empresas, al menos teóricamente, debe haber un cierto porcentaje, fijado por ley, de personal con discapacidad. El puesto de trabajo del empleado puede necesitar una adaptación, en función de su discapacidad.
En el marco de una reorganización de servicios en el seno de la empresa, es imprescindible tener en cuenta las diferentes características de acondicionamiento del puesto de trabajo del empleado. Estas características pueden estar relacionadas con una dificultad física de acceso al lugar de trabajo o con la necesidad de utilizar un equipamiento especial; por ejemplo, una pantalla de tamaño específico en caso de discapacidad visual. No siempre las personas encargadas de la puesta en marcha de la reorganización tendrán conocimiento de estas características, lo que puede provocar un funcionamiento incorrecto en el momento de la mudanza.
La aplicación de una configuración tipo permitirá identificar las características vinculadas a esta persona, facilitando el trabajo de los equipos encargados de la reorganización, y aportará la seguridad de una transferencia sin riesgos.
Llegada de un nuevo empleado Actualmente, muchas empresas utilizan personal externo. En normal que estos nuevos empleados se encuentren el día de su llegada sin puesto de trabajo y sin ninguna posibilidad de acceder a las aplicaciones o a los datos con los que tienen que trabajar. También es habitual que el plazo de espera para disponer de un puesto de trabajo con todos los derechos correspondientes a su función en la empresa sea superior a una semana. Al final, para que este nuevo empleado pueda trabajar, termina compartiendo el puesto de trabajo con sus compañeros y, lo que es más grave, los códigos de acceso a las aplicaciones y a los datos (usuario y contraseña). Se debe tener en cuenta dos aspectos en este tipo de situación:
La falta de productividad del nuevo empleado.
El incumplimiento de las normas de seguridad definidas en el proceso de gestión de la seguridad de la información.
La preparación de la llegada de un nuevo empleado permitirá a los equipos internos poner en marcha los diferentes medios informáticos antes de que esta se produzca y servirá, por lo tanto, para mejorar la productividad y eliminar los riesgos relacionados con la seguridad de la información.
Marcha de un empleado No es raro ver todavía hoy en día en las empresas grandes o medianas que cuando se marcha de un empleado no se hace nada en términos de actualización de los derechos de acceso a las aplicaciones y datos. Además, es frecuente que esta situación se mantenga durante varias semanas, incluso meses.
El impacto es también doble:
No se liberan recursos, fundamentalmente de almacenamiento.
No se respetan las normas de seguridad definidas en el proceso de gestión de la seguridad de la información.
De nuevo, en ausencia de procesos claramente definidos e identificados, los riesgos de olvido son muy elevados. El empleado es un recurso de la organización TI y, por lo tanto, se debe gestionar en el proceso de gestión de activos de servicio y configuraciones para evitar este tipo de funcionamientos inco-rrectos.
d. Dificultades en la gestión de configuraciones tipo En las empresas medianas y grandes, en el seno de la organización informática, hay un equipo encargado de la puesta en marcha y mantenimiento de los equipos informáticos. En ausencia de definición de configuraciones tipo, los empleados de estos equipos deben gestionar de manera unitaria la instalación de cada puesto de trabajo. La optimización de los tiempos de puesta en marcha de los puestos de trabajo para estos equipos pasa necesariamente por la definición de configuraciones tipo. Se tienen en cuenta dos tipos de configuraciones tipo:
Configuraciones de tipo hardware: la definición de configuraciones tipo permiten una gestión más eficaz de los puestos de trabajo y facilitan las operaciones de mantenimiento de los puestos. La utilización de un Master específico para cada tipo de configuración de hardware, en función del tipo de máquina o fabricante, permite una puesta en marcha y despliegue de los puestos de trabajo más rápidos.
Configuraciones de tipo funcional: la definición de configuración tipo en función del tipo de puesto funcional ocupado por el empleado va a permitir una vez más, gracias al uso de un Master, una preparación del puesto más rápida y, sobre todo, mejor controlada (seguridad de que todo el software del puesto está correctamente instalado y configurado, y que todos los derechos de acceso a la aplicaciones y datos se han definido correctamente).
12. Puesta en marcha de la gestión de cambios Esta etapa se puede llevar a cabo al mismo tiempo que las etapas descritas en la sección Puesta en marcha del centro de servicios y Puesta en marcha de la gestión de incidencias y problemas. La puesta en marcha de los procesos de gestión de cambios y gestión de las entradas en producción probablemente va a proporcionar cambios en los hábitos de funcionamiento de la organización TI. De manera ideal, la puesta en marcha del proceso de gestión de cambios se debería hacer al mismo tiempo que la puesta en marcha del proceso de gestión de los activos de servicio y configuraciones. Sin embargo, debido a que los procesos de diseño de servicios todavía no están implementados, es posible que únicamente una parte del proceso de gestión de cambios se ponga en marcha en esta etapa.
Un punto muy importante en esta etapa es permitir la actualización de la CMS tan pronto como se identifique un cambio en la infraestructura. La constitución del CAB se debe llevar a cabo al comienzo de esta etapa. Esta responsabilidad recae sobre el propietario del proceso, normalmente llamado Change manager o responsable de los cambios. Es deseable, al menos al inicio del proceso, informar a todos los propietarios de procesos, tan pronto estén identificados, del conjunto de peticiones de cambio presentadas. Esto no implica necesariamente que estén obligados a participar en las reuniones del CAB, al menos si no se ven implicados por los cambios examinados. La elaboración y la firma de los contratos de acuerdo de servicio entre la organización TI y el cliente o entre la organización TI y los proveedores se deben llevar a cabo en el marco del proceso de gestión de cambios para asegurar la coherencia de las ofertas y de las respuestas proporcionadas. La puesta en marcha de este proceso debe permitir la coordinación de las actividades en los proyectos en las intervenciones de los equipos internos y las intervenciones de los proveedores. Un punto importante que es preciso tener en cuenta en el momento de la implantación de un cambio, fundamentalmente durante la instalación de un nuevo servicio, una nueva versión de software o de aplicación, es la parte «documental». En efecto, es importante para el conjunto de los actores de la empresa, pero también para el cliente y los usuarios, haber sido informados de este cambio y haber recibido, si se da el caso, documentación adaptada, así como la formación necesaria para aprender correctamente el nuevo servicio o la nueva versión de software o de una aplicación. En el caso anterior, es igualmente importante establecer un soporte específico para esta puesta en marcha (Early Life Support). Además del hecho de que esto permite asumir más rápidamente el nuevo servicio o versión de software/aplicación, esto también permite un refuerzo de las relaciones entre los equipos de diseño de servicios y los equipos operativos durante el ciclo de vida de los servicios.
No hay que olvidar que uno de los objetivos de la gestión de cambios es reducir los riegos relacionados con los cambios mal controlados. El punto más importante durante la fase de inicio del proceso es asegurar que todos los cambios relativos a los elementos de la configuración de activos del servicio y de la configuración se registran correctamente en el sistema de gestión (CMS: Configuration Management System). Será necesario estar atentos.
13. Puesta en marcha de la gestión de pruebas y validación de los servicios Esta etapa se puede llevar a cabo al mismo tiempo que la etapa descrita en la sección Puesta en marcha de la gestión de cambios.
Las empresas, en función de su tamaño y del tamaño de su organización TI, no tendrán siempre un equipo de pruebas y de validación de los servicios para asegurar el conjunto de pruebas anteriores a las entradas en producción de los cambios. En ausencia de equipos dedicados, el responsable del proceso deberá formar un equipo temporal para hacer las diferentes pruebas y operaciones de validación de los servicios. En la medida de lo posible, puede ser interesante incluir en estos equipos a empleados procedentes tanto de la gestión del diseño de servicios como de la gestión operativa. Esta mezcla puede mejorar la colaboración entre los diferentes equipos. Esta etapa permite verificar, antes de la puesta en marcha de un servicio, que corresponde a las necesidades y proporciona el rendimiento esperado. Esto también sirve para asegurar que responde a las especificaciones solicitadas en el contrato de servicios.
14. Puesta en marcha de la gestión de las entradas en producción Esta etapa se puede llevar a cabo al mismo tiempo que la etapa descrita en las secciones Gestión de cambios y Gestión de validaciones y pruebas, del capítulo Los procesos de la transición de los servicios. La formación del equipo encargado de la puesta en marcha en producción seguirá las reglas definidas en la sección Gestión de las entradas en producción y Gestión de las validaciones y pruebas del capítulo Los procesos de transición de Servicios. Para lograr su objetivo, el responsable del proceso debe definir un plan de despliegue de acuerdo con el cliente y las diferentes partes interesadas. También es imprescindible asegurar que el paquete de instalación esté compuesto por un conjunto de componentes compatibles entre ellos. Es importante asegurar la trazabilidad del paquete de instalación y despliegue para permitir una eventual desinstalación en caso de que sea necesario. Durante esta etapa, también será necesario asegurar que el conocimiento y las competencias se transfieren a los equipos operativos (soporte y explotación).
15. Puesta en marcha de la gestión del conocimiento Este proceso tiene por objetivo asegurar que la información fiable y segura, es decir, aquella que respeta el principio de CIA, está disponible para permitir mejorar la calidad de la toma de decisiones. Para ello, es necesario asegurar que la noción de valor añadido se ha entendido claramente y se comparte por el conjunto de equipos de cada servicio prestado por la organización de TI. Es necesario asegurar que la información relativa al servicio (usuarios, restricciones, beneficios esperados...) sea accesible a las personas adecuadas, en el momento adecuado.
El suministro de la información que define el conocimiento permite al proveedor del servicio mejorar la calidad del servicio proporcionado, reduciendo los costes y aumentando la satisfacción del cliente.
Es deseable poder aprovechar la puesta en marcha de este proceso para hacerse cargo del conjunto de actividades relacionadas con la gestión de la documentación. Se debe poner en marcha una estandarización de los diferentes formatos de soporte para clarificar la presentación y lectura de los diferentes documentos. Esta estandarización debe permitir un mejor entendimiento de la documentación para el conjunto de los empleados de la organización TI. El establecimiento de una gestión documental, idealmente usando una herramienta de gestión documental, debe permitir a cada uno encontrar rápidamente la información que necesita, tanto para tomar decisiones como para proporcionar soporte a los usuarios. El establecimiento del proceso de gestión del conocimiento se puede hacer a través de la gestión del conocimiento (SKMS - Service Knowledge Management System) y de herramientas de gestión de los activos de servicio y configuraciones (CMS - Configuration Management System).
16. Puesta en marcha del porfolio de servicios y del catálogo de servicios En esta etapa, se debe comenzar la puesta en marcha de los procesos de gestión del porfolio de servicios y gestión del catálogo de servicios. El catálogo de servicios es un subconjunto del porfolio de servicios. La primera etapa consistirá en hacer un inventario de los servicios que entrega actualmente la organización TI. Esto constituirá la base del catálogo de servicios que alimentará finalmente al porfolio de servicios. La puesta en marcha completa del proceso de gestión del porfolio de servicios se puede realizar en segundo lugar, al mismo tiempo que el proceso de gestión de la demanda. La elaboración de un catálogo de servicios servirá para:
Crear una etapa preparatoria en el establecimiento de la gestión de los niveles de servicio.
Poner en marcha la comunicación hacia los empleados de la organización TI, clientes y usuarios.
Realizar un análisis de las diferentes actividades de la organización TI y las relaciones entre estas actividades.
El análisis de las actividades dará lugar a una reflexión de los problemas relacionados con los procesos, la organización y las herramientas de la organización TI. En esta etapa, será necesario hacer un análisis de cada uno de los servicios para identificar el valor añadido aportado para cada servicio. El catálogo de servicios se debe dividir en dos capítulos distintos. El catálogo de servicios debe identificar y diferenciar el catálogo de servicios de negocio, es decir, los servicios ofrecidos a los clientes, y el catálogo de servicios técnicos, es decir, los servicios internos.
El catálogo de servicios de negocio contiene los detalles de todos los servicios informáticos suministrados y prestados a los clientes. Contiene las relaciones con las áreas de negocio y con los procesos. Este catálogo es visible para los clientes. El catálogo de servicios técnicos contiene las relaciones con los componentes y con los CI necesarios para proporcionar el servicio. También contiene las relaciones con los servicios de soporte. Este catálogo es visible para los servicios internos de la organización TI. ¿Cómo describir un servicio? La descripción de un servicio debe incluir los siguientes elementos:
Una descripción técnica o funcional del servicio. Esta descripción se puede basar
ANEXOS Análisis de Kepner y Tregoe Para analizar los problemas, es posible utilizar la matriz desarrollada por Charles Kepner y Benjamin Tregoe. Kepner y Tregoe afirman que el análisis de un problema debe ser un proceso automático de resolución de problemas. Esta matriz utiliza el conocimiento y las experiencias pasadas. Se definen cinco fases para el análisis de un problema.
1. Las cinco fases Las cinco fases definidas por Kepner y Tregoe son las siguientes:
Definición del problema.
Descripción del problema (identificación de la identidad, el lugar, el momento y el tamaño).
Establecimiento de las posibles causas.
Pruebas de las causas más probables.
Verificación de causa real.
Sea cual sea la cantidad de información o la urgencia de encontrar una solución, es mejor adoptar un enfoque estructurado para analizar los problemas, con el objeto de aumentar las posibilidades de éxito.
2. Definición del problema El análisis y la búsqueda de la causa se basan en la definición del problema. Es imprescindible identificar de manera precisa cuáles son las desviaciones en relación con los niveles de servicio acordados. En la práctica, la definición de un problema es, a menudo, difícil debido a la complejidad de la infraestructura informática o de los acuerdos de niveles de servicio no explícitos.
Frecuentemente, la causa más probable del problema se señala en la descripción de este. No hay que sacar conclusiones precipitadas que podrían conducir a pistas falsas.
3. Descripción del problema Se utilizan los siguientes elementos para describir un problema:
Identidad: ¿qué componente (CI) o parte correctamente?, ¿cuál es el problema identificado?
Ubicación: ¿dónde aparece el problema?
Momento: ¿cuándo apareció el problema?, ¿con qué frecuencia aparece?
Tamaño: ¿cuál es la importancia del problema (en términos de tamaño)?, ¿cuántos componentes (CI) están afectados?
del
componente
no
funciona
La situación real y efectiva se determina por las respuestas a estas preguntas. A continuación, se deberá buscar en el entorno próximo los componentes que funcionan correctamente. Esto le permitirá identificar lo que podría haber sido parte del problema, pero que no lo es. A continuación, se pueden identificar las diferencias relevantes entre las dos situaciones.
Atención: los cambios pasados pueden ser la causa de estas diferencias.
4. Establecer las posibles causas La lista de las diferencias y, en caso necesario, de los cambios antes mencionados, contiene, por lo general, la causa principal del problema. De este modo, es posible determinarla.
5. Prueba de las causas más probables Se debe examinar cada posible causa para determinar si se puede aceptar como causa de todos los síntomas del problema.
6. Verificación de la causa real Se deben verificar las posibles causas identificadas para comprobar si son la causa principal del problema. La puesta en marcha de un cambio o la sustitución de una pieza pueden ser pruebas.
Diagrama de Ishikawa Esta herramienta fue destacada por Kaoru Ishikawa (1915-1989), ingeniero químico y pionero (y uno de los teóricos) de la gestión de calidad.
Herramienta de análisis de causas probables, este diagrama causa-efecto también se llama diagrama de espinas de pescado o diagrama de las 5M.
1. Objetivos Este diagrama permite determinar el conjunto de causas que producen un efecto estudiado:
Profundizar y explorar todas las dimensiones de una situación dada.
Llegar a un acuerdo sobre la definición y características de la cuestión tratada.
Ordenar por familias y subfamilias todas las causas de un problema dado.
Visualizar con claridad la relación adecuada de causa y efecto.
2. Casos de uso El diagrama de Ishikawa se utiliza con frecuencia en los dos siguientes ámbitos:
Resolución de un problema: Determinar la causa principal de un problema. Entender las razones que hacen que un proceso no genere los entregables previstos. Identificar las posibles fuentes de información. En el caso de resolución de problemas, esto puede evitar errores de diagnóstico. Ello tiene un impacto directo en el plazo, la calidad y los costes invertidos en la resolución del problema.
Desarrollo de un nuevo servicio o de un proyecto: cuáles son las áreas que es preciso considerar para obtener un servicio eficiente. La gestión y los medios financieros se pueden tener en cuenta en este ámbito.
3. Las áreas de clasificación Originalmente, Kaoru Ishikawa identificó cinco áreas de clasificación. Las cinco áreas pueden ser una base efectiva para la clasificación:
Materia: materias primas, piezas, almacenamiento, calidad y manipulación.
Equipo: maquinaria, mantenimiento.
Mano de obra: experiencia.
Medio: entorno físico, iluminación, ruido, planificación, relaciones, proveedores, mercado y legislación.
Métodos: instrucciones, manuales y procedimientos.
herramientas,
directos,
conjuntos,
equipos,
indirectos,
suministros,
capacidad,
motivación,
identificación,
edad,
formación,
número
y
absentismo
y
4. Progreso En el marco de la resolución de un problema:
Definir con claridad el eje sobre el que desea actuar directamente.
Listar las causas más probables del problema.
Clasificar las causas probables en las cinco áreas.
Establecer subfamilias cuando el número de casos por familia lo justifique.
Trazar el diagrama causa/efecto (Ishikawa).
Recomendación: asegúrese de que el diagrama es claro y legible.
5. Ejemplo Definir con claridad el eje sobre el que desea actuar directamente El objetivo:
prestación de un servicio de tipo centro de servicios.
Listar las causas más probables del problema En este caso, vamos a definir cuatro áreas:
recursos de red,
telefonía,
seguridad de datos,
puestos de trabajo.
Clasificar las causas probables en las áreas Para el área de recursos de red:
proveedores,
mantenimiento,
ancho de banda.
Para el área de telefonía:
puesto telefónico: tipo: o con cables, o sin cables,
cantidad: o instalados, o en reserva,
desbordamiento,
mantenimiento,
ACD,
Autoconmutador,
Para el área de seguridad de los datos:
derechos de acceso,
conexiones exteriores,
copia de seguridad de los datos,
Para el área de puestos de trabajo:
mantenimiento,
calidad: instalados, en reserva,
configuración: software, hardware,
Establecer subfamilias cuando el número de casos por familia lo justifique En este caso, no vamos a definir subfamilias.
Trazar el diagrama de causa/efecto (Ishikawa) A continuación encontrará el diagrama resultante de nuestras hipótesis.
Diagrama de Ishikawa
El modelo RACI Para el correcto funcionamiento de un sistema basado en procesos, es importante saber, en el seno de la organización: quién hace qué, cuáles son las responsabilidades y cuáles los roles. Para gestionar eficazmente un servicio o un proceso, es imprescindible que las responsabilidades y los roles de cada uno estén claramente definidos. Esto es lo que permitirá a la organización tener buen rendimiento y tomar rápidamente buenas decisiones antes de poder ejecutarlas eficazmente. En el caso de una elección estratégica o de una operación crítica, saber quién decide, quién actúa y quién está implicado permite a la organización reaccionar con rapidez. El modelo RACI proporciona ventaja para tomar decisiones con confianza y serenidad. RACI es acrónimo de los cuatro roles principales siguientes:
Responsible (en español: Responsable de la realización) es la persona o personas que realizan la actividad. Puede haber varias personas con este rol.
Accountable (en español: Responsable) es la única persona responsable de una actividad. Muy a menudo, hay una relación jerárquica entre A y R (con frecuencia, A es jefe de R).
Consulted (en español: Consultado): son las personas consultadas; por lo tanto, aquellas cuya opinión se solicita.
Informed (en español: Informado): son las personas a las que se mantendrá informadas.
Atención a la correcta definición de «Responsible» y «Accountable» porque es común intercambiar el significado en español de «Responsable de la realización» y «Responsable». En la siguiente tabla, la «R» es equivalente a «Responsible». No se trata, pues, del «Responsible» sino de la persona «encargada de hacer».
El modelo RACI
El punto importante cuando se utiliza el modelo RACI o cualquier otra herramienta o modelo es no permitir la asignación de responsabilidades al azar. Por otra parte, es importante que la asignación de roles se haga lo antes posible en la puesta en marcha del proyecto. No hay que esperar a una situación de crisis para asignar los roles. Los conflictos se pueden evitar y se pueden tomar decisiones rápidamente si los roles se definen de antemano.
1. Las variantes del modelo RACI a. RASCI Una variante del modelo RACI se llama RASCI y añade un rol adicional: La S significa Supportive (en español: el que da soporte). Este rol desempeña un papel de soporte, por ejemplo asignando recursos adicionales para la puesta en marcha del proyecto.
b. RACI-VS Otra versión más completa de RACI, llamada RACI-VS, se utiliza para los roles siguiente: Verifies (en español: Controlador): la persona o grupo que verifica si se ha cumplido el criterio de aceptación.
Signs Off (en español: Responsable del cierre): persona que aprueba la decisión «V» (ver más arriba) del controlador y que autoriza la transferencia del producto. Se puede tratar de la persona A (Accountable - Responsable).
Atributos de un CI
1. Propuesta de definición de los atributos de un CI
Atributo
Descripción
Identificador del CI
Nombre único por el que se conoce este tipo de CI.
Número de serie, de licencia (o copia de licencia)
Identificador único para las instancias particulares del CI (por ejemplo, para un software, número de licencia o número de copia, y para hardware, el número de serie).
Categoría
Clasificación de un CI (hardware, software, documentación...).
Tipo
Descripción del tipo de CI. Completa la «categoría» y añade información (por ejemplo, configuración del hardware, paquete de software, periférico de hardware o módulo de software o de un programa).
Número de (hardware)
modelo
Modelo de CI (correspondiente, por ejemplo, al número de modelo del proveedor; por ejemplo, modelo yyy PC/aa de tal proveedor).
Fecha de vencimiento de la garantía
Fecha de vencimiento de la garantía del proveedor para el CI de hardware o de responsabilidad de asistencia para el software.
Número de versión
Número de versión del CI.
Ubicación
Ubicación del CI (por ejemplo, la biblioteca en la que encuentra el CI o el CD sobre el que se registra, el lugar o ubicación donde se sitúa el servicio).
Propietario responsable
El nombre o designación del propietario responsable del CI.
Fecha de inicio de la responsabilidad
Fecha a partir de la cual el propietario se con- vierte en responsable del CI.
Origen/proveedor
El origen del CI (por ejemplo, el nombre del servicio si se ha desarrollado internamente, comprado a la organización xxx...).
Licencia
Número de licencia o referencia a un contrato de licencia.
Fecha aprovisionamiento
Fecha de aceptación
de
Fecha en la que la organización ha adquirido el CI.
Fecha en la que el CI ha superado satisfactoriamente las pruebas de aceptación de la organización.
Para los RFC, los
registros de cambios, los registros de paquetes, los nombres, los números de copia, los números de modelo y los números de versión de los CI afectados por el cambio, y cómo se afectan, se debe guardar en un CMS. También se deben registrar un modo para volver atrás y las consecuencias de una vuelta atrás.
Glosario Este glosario retoma los términos usados en este libro, así como los acrónimos y términos ingleses usados en la literatura ITIL. Estos términos están clasificados por orden alfabético. Puede encontrar un diccionario ITIL de la OGC en español, que puede descargar gratuitamente en internet. Haga un búsqueda usando ITIL 2011 Spanish Glossary v1.0 para acceder al documento descargable. Atención, este diccionario tiene 154 páginas, pero es particularmente útil por el nivel de detalle que ofrece y por la facilidad de búsqueda tanto en inglés como en español. Activación: lanzamiento por la dirección general de la empresa del plan de reanudación de la actividad después de un problema importante. Actualización: agrupamiento de uno o varios cambios autorizados, probados e instalados en el entorno de producción. Actualización agrupada: conjunto de actualizaciones de software o de hardware, implantadas al mismo tiempo en el entorno de producción. Actualización completa: actualización integral de los componentes de un sistema (hardware, software, documentación, procedimientos...) que hayan sido modificados o no desde la última actualización. Actualización diferencial (DELTA): actualización que solo sustituye los elementos de configuración que han cambiado desde la última actualización. Acuerdo de nivel de explotación: expresión en términos técnicos del acuerdo de nivel de servicio firmado por los usuarios, y que expresa de manera particular los recursos técnicos y humanos que se deben utilizar. Acuerdo de nivel de servicios: documento que define los objetivos concretos y específicos para el servicio considerado. Compromete a las dos partes (clientes y proveedores, u organización TI si el cliente es un servicio interno de la empresa), en lo relativo a los niveles esperados en términos de disponibilidad, capacidad y costes, y permite la evaluación del rendimiento de la organización informática durante el suministro y soporte de este servicio. Adaptabilidad: capacidad de un servicio para cambiar su nivel de rendimiento y costes, como consecuencia de un cambio en la petición o en la infraestructura. Ajuste: actividad dedicada a adaptar los parámetros de un componente infraestructura o servicio, con el objetivo de obtener una mejora del rendimiento.
de
la
Alerta: mensaje electrónico que proviene de un sistema de monitorización automático informando de que se ha alcanzado un umbral o se produce o se puede producir un fallo.
Amenazas: causas eventuales de una perturbación que actúa sobre la infraestructura (hardware, software o servicios) y que podrían dificultar el suministro de los servicios. Amortización: medida de la disminución del valor de un activo a lo largo del tiempo, desde un punto de vista contable, sea cual sea la causa del desgaste u obsolescencia. Análisis de impacto: identificación de los procesos de negocio críticos y las pérdidas o daños potenciales que pueda causar a la empresa como consecuencia de un funcionamiento incorrecto de estos procesos. Análisis de los fallos del sistema: técnica diseñada para proporcionar un enfoque estructurado de la identificación de las causas subyacentes de los funcionamientos incorrectos en el suministro de los servicios. Análisis del riesgo: identificación de la importancia de los componentes de la infraestructura (los elementos de activos), de las amenazas a las que estos componentes puedan estar expuestos y de su vulnerabilidad frente a las amenazas identificadas. Anomalía: condición que causa la imposibilidad de una unidad funcional para ejecutar la función requerida. Asistencia: servicio que corresponde al suministro de ayuda y de soporte que la dirección informática aporta al cliente. Atributo: característica descriptiva de un elemento de configuración registrado en la base de datos de la gestión de configuraciones (por ejemplo: tipo de CI, marca o modelo, proveedor...). Auditoría: proceso de inspección y verificación utilizado para validar que una actividad se realiza según un estándar aceptado o según la mejor práctica reconocida. Base de datos de la gestión de las configuraciones: base de datos que reagrupa la información de configuración e histórica de todos los elementos de configuración (CI), así como las relaciones establecidas entre estos CI. Biblioteca de software definitivo (Definitive Software Library o Definitive Media Library): es la biblioteca en la que se guardan las versiones definitivas y autorizadas de todos los CI de software. En realidad, esta zona de almacenamiento puede estar formada por una o varias bibliotecas lógicas o físicas. Cadena de valor: sucesión de actividades que crea un producto o servicio susceptible de generar un valor de mercado o permitir a la empresa aumentar su cifra de negocios. Calendario de cambios: calendario que contiene los detalles de todos los cambios aprobados para la implementación y sus fechas de ejecución propuestas. Cambio: modificación voluntaria de un elemento de configuración de la infraestructura, con el objetivo de cambiar su comportamiento, capacidad o estado. Cambio de urgencia: modificación de un componente de la infraestructura planificado y puesto en marcha en un plazo muy corto, con el objetivo de evitar un riesgo potencial importante o reducir el impacto para el sistema de información.
Cambio estándar: modificación frecuente conocida y controlada usando procedimientos de puesta en marcha precisos y sin necesidad de pasar por el comité consultivo de cambios. Capacidad: potencia, rendimiento, velocidad o volumen de un componente o de la infraestructura. Catálogo de servicios: documento producido bajo la responsabilidad del proceso de gestión del catálogo, con el objetivo de informar a los clientes y usuarios de los servicios y la infraestructura disponibles. Categoría: clasificación por grupos distintos de los elementos de configuración como hardware, cambio o problema. Categorización de las incidencias: clasificación que permite jerarquizar las incidencias. Centro de beneficio: modo de organización contable en el que una actividad de negocio interna de la empresa se percibe como una actividad independiente, cuyos objetivos se definen por la Dirección de la empresa, pero que es susceptible de generar beneficios, incluso si estos se logran en detrimento de otras actividades de la empresa. Centro de coste: modo de organización contable en el que una actividad de negocio solo se percibe a través de sus gastos. Centro de llamadas: interfaz entre los usuarios y la informática, dedicada a la recepción de llamadas telefónicas de petición de asistencia, consultas o quejas. Centro de servicios: el centro de servicios se llama en la actualidad SPOC (Single Point of Contact), ya que permite al usuario acceder al conjunto de servicios especializados a través de un único punto de contacto. El centro de servicios también sustituye a un rol de gestión de las incidencias, ofreciendo un recurso técnico de primer nivel y teniendo en cuenta todas las peticiones, quejas o consultas de los usuarios. Ciclo de vida: descripción de las diferentes etapas de la duración de uso de un producto, servicio o proceso. Ciclo de vida de las incidencias: progreso del estado de funcionamiento incorrecto del servicio que va desde la funcionamiento incorrecto hasta la restauración del servicio, diagnóstico del origen, reparación o solución temporal del operativa.
un evento, que implica un aparición o detección del pasando por las etapas de fallo en la infraestructura
Ciclo de vida de los problemas: progreso del estado de la causa de una anomalía que afecta al sistema de información, que pasa por la identificación de la causa, elaboración de una solución temporal o permanente y petición de cambio eventual, para poner en marcha esta solución. Clasificación: actividad de agrupamiento de los elementos de configuración (CI) por tipo (hardware, software, procedimientos, documentos o servicios externos). Cliente: el que especifica las necesidades de negocio, con quién se ha acordado los servicios que se tienen que entregar y quién es responsable de su financiación. Comité consultivo de cambios: analiza los impactos y proporciona los consejos al cliente sobre los cambios (no los autoriza). Asiste al gestor de cambios en la evaluación, priorización y planificación de los cambios. Se compone de las propiedades del proceso
táctico y del proceso de gestión de cambios, del responsable de la seguridad, del cliente, del representante o de los representantes de los usuarios y de los especialistas si es necesario. Comité de urgencia de cambios: reunión de urgencia de un comité consultivo de cambios, restringido a los miembros imprescindibles para la evaluación de un cambio urgente. Configuración básica: imagen congelada del estado de un elemento de configuración (CI) o de un conjunto de CI, con el objetivo de evaluar el impacto de un cambio en la infraestructura o asegurar que la infraestructura se puede restaurar rápidamente. Contabilidad: conjunto de actividades que permiten a la organización informática identificar, clasificar y justificar sus gastos financieros. Contramedida: acción que se toma para reducir el riesgo o su impacto sobre el sistema de información. Contrato: Acuerdo formal entre dos personas, sometidas a las restricciones legales en vigor. Contrato de subcontratación: contrato con un proveedor externo para obtener una prestación de servicios que permita el suministro de los servicios informáticos. De esta manera, hablamos de contrato de tipo UC (Underpinning Contract). Control de configuraciones: actividad que asegura que solo los elementos de configuración (CI) autorizados e identificados se usan en la infraestructura informática de la empresa. Convivialidad: capacidad de un servicio, aplicación o hardware de utilizarse de manera sencilla, intuitiva y sin formación excesiva. Coste de funcionamiento (de explotación, producción...): representa los gastos de explotación diaria de una organización (costes en personal, mantenimiento del hardware, electricidad...). Coste de transferencia: representa el coste de las prestaciones suministradas de una división de la empresa a otra. Coste de los servicios externos: representa los costes de los servicios adquiridos a los proveedores externos. Coste directo: representa los costes que se pueden imputar totalmente a un cliente (por ejemplo: aplicación contable que se imputa a la Dirección financiera). Coste fijo: representa un coste que no varía con el volumen de uso o las evoluciones de la actividad de la empresa. Coste indirecto: representa un coste que no se puede imputar completa y directamente a un único cliente o servicio, por lo que cuyo valor se debe repartir entre los diferentes actores (por ejemplo: mensajería utilizada por toda la empresa). Coste marginal: representa el coste de producción de una unidad adicional antes de la aplicación del sistema de producción. Incluye principalmente los costes de materia prima, mano de obra y amortización del sistema. El interés de este valor es demostrar que el
coste de posesión de un equipamiento no es simplemente su coste de compra y también permite confirmar que el coste de producción de una unidad disminuye con el volumen producido. Coste total de posesión: representa el coste acumulado de todos los elementos que componen un servicio o un equipamiento. Dicho de otra manera, el precio de compra inicial incluye los costes de personal, mantenimiento, transferencia, materias primas consumibles... Coste variable: representa un coste que evoluciona en función del volumen de uso de un servicio, materias primas o de un producto. Cultura de servicio: base sobre la que se debe construir la organización TI. La satisfacción del cliente es la prioridad más importante de la organización TI y las actividades de puestas en marcha contribuyen a estos objetivos. Definitive Hardware Storage: zona de informáticos de recarga.
almacenamiento seguro de los equipos
Definitive Media Library o Definitive Software Library: biblioteca en la que se guardan las versiones definitivas y autorizadas de todos los CI de software. En realidad, esta zona de almacenamiento puede estar formada por una o varias bibliotecas lógicas o físicas. Diagnóstico: tercera etapa del ciclo de vida de una incidencia durante la que el equipo informático intenta identificar su origen. Dimensionamiento de la aplicación: actividad de evaluación de los recursos necesarios para una aplicación nueva y adición o mejora de una aplicación existente. Disponibilidad: indica la capacidad de un sistema para hacer su función durante un tiempo dado. Normalmente, este valor se expresa como un porcentaje del tiempo durante el que el sistema está disponible, en relación con el horario de servicio negociado en el SLA. Duración media de disponibilidad (MTBF): duración media durante la que el servicio está disponible. Este tiempo también se llama Up Time o tiempo de disponibilidad. Duración media de reparación (MTTR): duración media de reparación, también llamada Down Time o «tiempo de no disponibilidad». Es el tiempo que transcurre entre el momento en que se produce la incidencia y el momento en que se restaura el servicio. Incluye el tiempo de detección, diagnóstico (o tiempo de respuesta), reparación, restauración y recuperación. Duración media entre dos incidencias (MTBSI): tiempo entre dos incidencias. Eje sobre el cliente: basado en los objetivos del cliente. Elemento de configuración: representa cualquier componente de la infraestructura informática referenciado en la base de datos de configuraciones (CMDB), como el hardware, el software, documentación o documentos de la organización (contratos, acuerdos, formularios, procedimientos...). Ensamblado: etapa final en la producción de una configuración, utilizable a partir de un conjunto de elementos de configuración para obtener un paquete de software o hardware a instalar.
Entorno: conjunto de hardware, software, procedimientos, etc., funcionando de manera conjunta, con el objetivo de proporcionar un servicio. Entorno de producción u operativo: sistema informático que se usa para proporcionar el servicio solicitado por los usuarios. Entorno de prueba: sistema informático compuesto de hardware, software y documentación, que se usa para probar los cambios antes de implantarlos en el entorno de producción. Error conocido: causa identificada del funcionamiento incorrecto de un componente de la infraestructura, sin que por el momento se haya implantado obligatoriamente una solución definitiva. Evaluación de riesgos: actividad que permite analizar los riesgos potenciales y sus consecuencias en el sistema de información y, por extensión, en la actividad de la organización TI o de la empresa. Evento: todo evento detectable o perceptible que pudiera tener un impacto significativo en la gestión de la infraestructura informática o la entrega de un servicio. Externalización: operación que consiste en transferir los servicios realizados internamente en la empresa a un proveedor externo. Facturación: actividad de creación y emisión de una factura para recuperar la cantidad acordada en el suministro de un servicio. Fase de alerta: primera fase del plan de continuidad de actividad durante el que se inician las acciones urgentes y la evaluación de los daños. Fase de invocación y de recuperación: la segunda fase de un plan de recuperación de las actividades del negocio durante la que se lanzan los procedimientos de reparación, restauración y recuperación de los servicios. Fiabilidad: corresponde a la aptitud de un sistema para funcionar de manera perdurable, con incidencias o interrupciones mínimas. Funciones vitales para el negocio (VBF - Vital Functions Business): agrupa las funcionalidades que soporta uno o varios servicios informáticos, cuya no disponibilidad puede tener consecuencias graves para la actividad de la empresa. Gestión de la capacidad del negocio (BCM - Business Capacity Management): actividad de la gestión de las capacidades que permite asegurar que se tienen en cuenta las necesidades futuras en materia de servicios informáticos. Gestión de la capacidad de los recursos (BCR - Business Capacity Resource): actividad de gestión de las capacidades que permite asegurar que los recursos informáticos existentes se vigilan y miden, y que se tiene en cuenta el suministro de las nuevas tecnologías. Gestión de la capacidad de los servicios (SCM - Service Capacity Management): actividad de la gestión de las capacidades que permite asegurar que los recursos cumplen los objetivos de los servicios informáticos firmados en los acuerdos de nivel de servicios.
Gestión de la continuidad del negocio (BCM - Business Continuity Management): proceso de evaluación de los errores y las consecuencias que pueden tener en las funciones y procesos de negocio críticos, para asegurar que la empresa está en condiciones de responder de manera planificada y preparada. Gestión de la disponibilidad: proceso responsable del diseño, implementación y control de la disponibilidad de los servicios informáticos. Gestión de las capacidades: proceso encargado de definir y controlar las necesidades de la empresa en materia de capacidad informática, con el objetivo de proporcionar esta capacidad en el momento adecuado y con un coste óptimo. Gestión de cambios: proceso responsable de controlar y gestionar las peticiones de cambios de la infraestructura y los servicios. Gestión de configuraciones: proceso de planificación, identificación, control verificación de los elementos de configuración, que componen la infraestructura.
y
Gestión de incidencias: proceso de gestión cuyo objetivo es restablecer un servicio operativo tan rápidamente como sea posible, minimizando el impacto en la empresa y asegurando que se mantienen los niveles de servicio y disponibilidad acordados. Gestión de las crisis: proceso de estimación de los impactos como consecuencia de un error grave e identificación de los modos de acción que permitan sobrevivir. Gestión de problemas: proceso de gestión cuyo objetivo es minimizar el impacto sobre la empresa de las incidencias y problemas que provienen de errores de la infraestructura, y prevenir la aparición de incidencias, problemas y errores de manera proactiva. Gestión de riesgos: actividad de identificación de los riesgos que puedan afectar a la empresa y de identificación de las contramedidas adoptadas y justificadas, desde un punto de vista financiero. Gestión financiera: proceso responsable de la presupuestación, contabilidad y facturación de los servicios informáticos. Histórico de cambios: información de seguimiento del iniciador, origen, fecha y contenido de los cambios. Horas/Horario de mantenimiento: horario acordado de disponibilidad del soporte de los servicios. Horas/Horario de servicio: horario acordado de disponibilidad del servicio. Impacto: medida de las consecuencias que tiene o puede tener un evento (incidencia, problema, error grave o cambio) en la empresa. Imputación: asignación de los costes de producción de los servicios informáticos, con vistas a su imputación a uno o varios clientes en forma de facturación real o ficticia. Incidencia: corresponde a un evento quo no forma parte del funcionamiento normal de un sistema (servicio, procedimiento, software, hardware...) y que causa o puede causar una alteración de la calidad de los servicios y de la productividad del cliente.
Infraestructura: agrupa el conjunto de componentes (elementos de configuración) que se usan en el suministro de los servicios informáticos y de telecomunicación a los usuarios (hardware informático y de telecomunicaciones, software, oficinal, personal, documentación...). Interfaz: relación de interacción física o funcional entre los elementos de configuración. Mantenimiento de los servicios: agrupamiento lógico dentro del repositorio ITIL de los cinco procesos de gestión de configuraciones, incidencias, problemas, cambios y actualizaciones. Medida de reducción de riesgo: medida adoptada para reducir la probabilidad o las consecuencias de la aparición de un error en las actividades de la empresa. Mejora continua: principio según el cual todos los aspectos del suministro y mantenimiento de los servicios se reevalúan regularmente, para identificar las mejoras potenciales, sobre todo en términos de eficacia. Este principio se basa en la Rueda de Deming. Métricas de disponibilidad informática: conjunto de métricas que se usan para medir la disponibilidad, fiabilidad, mantenibilidad y el tiempo de respuesta de los servicios informáticos. Modelo de coste: reparto de los costes de producción de los servicios informáticos, con el objetivo de calcular el coste total de estos servicios antes de facturarlos a los clientes. Modelo de coste por cliente: costes identificados y distribuidos para cada cliente del servicio. Modelo de coste por servicio: costes identificados y distribuidos sobre los servicios informáticos que se proporcionan al cliente. Modelo de incidencia: conjunto estructurado de preguntas empleadas por el personal del centro de servicios para permitir la resolución rápida o la asignación precisa de las incidencias. El personal técnico mantiene y proporciona escenarios de diagnóstico como una de sus responsabilidades dentro del proceso de la gestión de las incidencias. Objetivo de continuidad del negocio: definición del detalle y perímetro de recuperación de la actividad después un error grave, incluyendo personal, infraestructuras y servicios. Objetivos de negocio: objetivos medibles, elaborados con el objetivo de ayudar a la realización de la estrategia de la empresa. Objetivos de nivel de servicios: equivalente al documento de especificaciones de un servicio, este documento corresponde a la expresión de las necesidades de los clientes de la organización TI, en términos de servicio. Organización: estructura que corresponde a la dimensión organizacional. Puede ser el servicio informático, como entidad específica de la empresa. Periodo de convivencia del servicio: horario de disponibilidad acordado en el SLA de un servicio informático. Periodo de no disponibilidad: periodo situado en los horarios de servicio acordados durante el que el servicio no está operativo.
Petición de cambio o RFC(Request For Change): formulario que se utiliza para describir un cambio solicitado. El cambio puede afectar a cualquier componente o servicio de la infraestructura informática. Petición de servicio: petición de cambio menor que no afecta a la infraestructura y no justifica la intervención del comité consultivo de cambios, como por ejemplo la modificación de una contraseña o la instalación de un puesto de trabajo nuevo. Plan: documento formal que describe los objetivos, la planificación y los recursos que hay que poner en marcha en un proceso. Plan de capacidad: este plan sirve para gestionar los recursos necesarios para el suministro de los servicios informáticos a diario, y también para tener una visión de las necesidades futuras. Plan de continuidad de las actividades de negocio: describe las funciones, responsabilidades y acciones necesarias que permiten retomar las actividades del negocio críticas después de un error grave. Plan de continuidad de los servicios: este plan describe las acciones y procedimientos que la dirección informática debe seguir en caso de error grave, para retomar el suministro de los servicios críticos para el negocio. Plan de la calidad de los servicios: este plan describe los objetivos internos que hay que alcanzar durante un periodo dado, para mejorar los niveles de servicio acordados y la percepción de la calidad que la empresa tiene de estos servicios. Plan de la disponibilidad: plan que permite asegurar que las necesidades de disponibilidad de los servicios TI actuales y futuras se pueden satisfacer de manera rentable. Plan de despliegues: plan que describe los métodos, planificaciones y recursos necesarios para implantar las actualizaciones en producción. Plan de vuelta atrás: este plan describe las acciones que se tiene que tomar para restablecer el servicio después de una actualización sin éxito. Política de facturación: conjunto de reglas y decisiones de la empresa, respecto a la facturación y cobro, que la dirección informática debe poner en marcha para justificar sus finanzas. Potencial de mantenimiento externo: capacidad para disponer de los servicios de proveedores externos, con el objetivo de mantener un CI de la infraestructura en estado de funcionamiento, para que pueda ejecutar las funciones requeridas. Potencial de servicio externo: capacidad para disponer de la asistencia de proveedores externos para configurar un Cl de la infraestructura. Precio con margen: coste de producción al que se añade un margen equivalente a un porcentaje de este coste. Precio del mercado: precio idéntico o comparable al que generalmente facturan los proveedores externos por el mismo servicio. Precio fijo: precio acordado con un cliente para un servicio dado en un periodo dado.
Prestación: suministro de un bien o de un servicio a un cliente. En el contexto ITIL, también hablamos de servicio. Presupuestación: ciclo periódico de previsión, negociación y control de los gastos de la organización informática. Primer nivel de asistencia: recursos técnicos y de gestión presentes dentro del centro de servicios que permiten resolver rápidamente las incidencias sencillas. Prioridad: valor que se basa en el impacto sobre el negocio y la urgencia asignada a una incidencia, problema o cambio, para indicar su importancia relativa en la cola de gestión de estos eventos. Problema: origen desconocido subyacente en una o varias incidencias existentes o potenciales. Proceso de escalado: es el enrutamiento de una incidencia, problema o cambio a un nivel de asistencia superior, por razones técnicas o jerárquicas. Programa de mejora de servicios (Service Improvement Plan): plan formal de puesta en marcha de mejora continua de la calidad y eficacia de los servicios informáticos. Afecta a un proceso o servicio que suministra la organización TI. Propietario del proceso: persona sobre la que recaen los acuerdos del proceso. Su función es asegurar la eficacia de un proceso. Es responsable del diseño, la gestión de cambios, la mejora continua del proceso y sus medidas. Proveedor de servicios: organización interna o externa que suministra los servicios o productos a los clientes. Algunas de estas organizaciones pueden albergar determinadas aplicaciones de la empresa en sus oficinas. Por tanto, se trata de un proveedor de alojamiento de aplicaciones (ASP - Application Service Provider). Proveedor externo: tercera parte responsable del suministro o mantenimiento de uno o varios elementos del sistema de información. Proveedor interno: unidad responsable del suministro de los servicios informáticos dentro de la empresa, independientemente de su pertenencia efectiva a esta. Pruebas de integración: pruebas realizadas en un entorno tan próximo como sea posible al entorno de producción. El conjunto de componentes de hardware y software implicados en un cambio se tienen que identificar para asegurar que funcionan correctamente en conjunto. Recuperación: operación de relanzamiento de la actividad como consecuencia de un fallo. Esta operación agrupa las acciones de reparación y restauración de uno o varios elementos de configuración o de un servicio. Recuperación gradual: inicio en frío. Opción de la continuidad de los servicios informáticos. La recuperación de la actividad de la empresa se hace en un plazo que puede ser de hasta varios días después de un error grave. Recuperación inmediata: inicio inmediato. Opción de la continuidad de los servicios informáticos. La recuperación de los servicios es instantánea o casi inmediata (menos de 24 horas) en el caso de un error grave.
Recuperación intermedia: inicio intermedio. Opción de la continuidad de los servicios informáticos. La recuperación de los servicios es rápida (entre 24 y 72 horas) en caso de un error grave. Redundancia: método que se usa para eliminar los puntos de debilidad únicos, mediante la duplicación de los elementos de configuración (CI), cuya no disponibilidad puede perturbar la actividad del servicio. Registro: información individual o compuesta contenida en una base de datos. Registro de actualización: registro que contiene la información de la historia de una actualización, así como de los elementos de configuración a los que afecta. Registro de cambio: registro que contiene la información de un cambio, junto con los diferentes componentes a los que afecta. Registro de cambios: lista exhaustiva que agrupa la información de las peticiones de cambio (evaluación, pruebas, decisiones, estado actual...). Registro de error conocido: registro que contiene la información y el histórico de un error conocido. Registro de incidencia: registro que contiene la información y el histórico de una incidencia. Registro de problema: registro que contiene la información y la historia de un problema. Relación: interdependencia o conexión entre los componentes de la infraestructura, los servicios o los procesos de la dirección informática. Las relaciones permiten evaluar el impacto potencial de un cambio, un funcionamiento incorrecto o de un fallo. Resistencia: es la capacidad de un sistema o componente para continuar funcionando incluso si una parte de los elementos del sistema o del componente ha fallado. Restauración del servicio: actividad de puesta a disposición de los usuarios de un servicio o de los datos imprescindibles para su trabajo. Revisión postimplementación: reunión de evaluación de un cambio después de su implementación para determinar si se ha implementado con éxito y si se obtienen los beneficios previstos. Riesgo: evaluación de la probabilidad de que una perturbación se produzca y haya pérdidas potenciales como resultado de ella. Segundo nivel de asistencia: agrupa las personas que tienen competencias técnicas avanzadas, implicadas en la gestión de incidencias y problemas no resueltos por los equipos de primer nivel. Servicio: en el marco de ITIL, un servicio puede tener dos sentidos diferentes: una organización o una prestación. Solución de seguridad: hardware, software y procedimientos aplicados para asegurar la disponibilidad de los componentes de la infraestructura que sufren un fallo.
Solución temporal: solución provisional que permite recuperar el servicio en las condiciones lo más cercanas posible a un funcionamiento normal. Tarificación: elaboración de la política tarifaria y establecimiento de las tasas de facturación que se aplicarán a los clientes. Tasa de resolución de primer contacto: proporción de incidencias resueltas desde el primer contacto entre el usuario y el centro de servicios. Esta tasa se expresa en un porcentaje de las incidencias registradas por el centro de servicios durante el mismo periodo. Tasa en vigor: modo de facturación de los servicios informáticos en el que los precios propuestos son comparables a los de otras organizaciones parecidas. Tecnología de la información y las comunicaciones (TIC): conjunto de tecnologías de tratamiento y transferencia de datos, según las instrucciones programadas, para extraer resultados. Incluye la información de tipo texto, imagen, vídeo, sonido... Tipo de coste: los componentes de los servicios informáticos se clasifican por un tipo de componente como hardware, software, personal, instalación, servicio externo... Esto permite elaborar un modelo de coste. Tipo de llamada: todas las llamadas recibidas en el centro de servicios se clasifican según su tipo. Este tipo se puede definir en función de su asunto, destino, importancia... (ejemplo: incidencia, consulta, petición de servicio, queja...). Tolerancia a las averías: capacidad de un servicio o un sistema para continuar su actividad cuando se produce un error. Ver también Resistencia. Tratamiento de los errores: actividad que elabora una solución que permite resolver un error conocido (la causa), pasando eventualmente por una petición de cambio en la infraestructura. Tratamiento de los problemas: actividad que identifica la causa de un probl
