GestiondeServiciosTI_ITIL.pdf

Contenidos

SERVICIO DE ENTREGA

INTRODUCCIÓN 1.

INTRODUCCIÓN

10. 1

2. 2.1. 2.2. 2.3.

GESTIÓN DE SERVICIOS IT-FUNDAMENTOS 3 Servicios y calidad 3 Organización y políticas 9 Gestión de procesos 14

3. 3.1. 3.2. 3.3.

INTRODUCCIÓN A ITIL Fundamentos Organizaciones Los libros de ITIL

19 19 20 22

SERVICIOS DE SOPORTE 4. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6.

GESTIÓN DE INCIDENTES Introducción Objetivo El proceso Actividades Control del proceso Costes y problemas

31 31 34 35 37 40 42

5. 5.1. 5.2. 5.3. 5.4. 5.5. 5.6.

GESTIÓN DE PROBLEMAS Introducción Objetivo El proceso Actividades Control del proceso Costes y problemas

43 43 44 45 47 51 53

6. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

GESTIÓN DE CONFIGURACIONES Introducción Objetivo El proceso Actividades Control del proceso Costes y problemas

55 55 57 58 56 65 66

7. 7.1. 7.2. 7.3. 7.4. 7.5. 7.6.

GESTIÓN DE CAMBIOS Introducción Objetivo El proceso Actividades Control del proceso Costes y problemas

69 69 71 71 74 75 81

8. 8.1. 8.2. 8.3. 8.4. 8.5.

GESTIÓN DE VERSIONES Introducción Objetivo El proceso Actividades Costes y problemas

83 83 87 87 89 93

9. 9.1. 9.2. 9.3. 9.4. 9.5.

CENTRO DE SERVICIOS Introducción Objetivo Estructura Actividades Efectividad

95 95 96 96 100 101

10.1. 10.2. 10.3. 10.4. 10.5. 10.6. 11. 11.1. 11.2. 11.3. 11.4. 11.5. 11.6.

GESTIÓN DE NIVELES DE SERVICIO Introducción Objetivo El proceso Actividades Control del proceso Costes y problemas

103 103 105 105 108 113 114

GESTIÓN FINANCIERA DE LOS SERVICIOS TI Introducción Objetivo El proceso Actividades Control del proceso Costes y problemas

115 115 117 118 120 123 124

12. GESTIÓN DE LA CAPACIDAD 12.1. Introducción 12.2. Objetivo 12.3. El proceso 12.4.Actividades 12.5.Control del proceso 12.6.Costes y problemas

125 125 125 126 128 131 132

13. GESTIÓN DE LA CONTINUIDAD 13.1.Introducción 13.2.Objetivo 13.3.El proceso 13.4.Actividades 13.5.Control del proceso 13.6.Costes y problemas

133 133 133 134 135 141 142

14. GESTIÓN DE LA DISPONIBILIDAD 14.1.Introducción 14.2.Objetivo 14.3.El proceso 14.4.Actividades 14.5.Control del proceso 14.6.Costes y problemas

143 143 144 146 147 147 155

15. GESTIÓN DE LA SEGURIDAD 15.1.Introducción 15.2.Objetivo 15.3.El proceso 15.4.Actividades 15.5.Control del proceso 15.6.Costes y problemas

157 157 157 158 165 168 169

16. ESTUDIO DE CASO – Quick Couriers 171 16.1. Gestión de configuraciones 172 16.2. Gestión de incidentes y centros de servicio 173 16.3. Gestión de problemas 174 16.4. Gestión de cambios 175 16.5. Gestión de versiones 176 16.6. Gestión de disponibilidad 177 16.7. Gestión de la capacidad 178 16.8. Gestión de la continuidad de servicios de TI 179 16.9. Gestión Financiera 180 16.10. Gestión de niveles de servicio 181

Gestión de Servicios TI basado en ITIL

Capítulo 1: Introducción Hace unas décadas que los desarrollos de las TI vienen provocando un gran impacto en los procesos del negocio. La introducción del PC y de las tecnologías LAN, cliente/servidor e Internet ha permitido que las organizaciones lleven sus productos al mercado de una forma mas rápida y con mayor eficiencia. Estos desarrollos han marcado la transición de la era industrial a la de la información. Las organizaciones jerárquicas tradicionales tienen dificultades para adaptarse a mercados en constante cambio, lo que ha marcado una tendencia hacia organizaciones menos jerárquicas y más flexibles. De igual manera, dentro de las organizaciones se ha puesto énfasis en cambiar de funciones verticales o departamentos a procesos horizontales que se extienden a través de toda la organización, y se le otorga a personal de menor nivel la autoridad para tomar decisiones. Teniendo en cuenta estos aspectos básicos se desarrollaron los procesos operativos de la Gestión de Servicios TI. En los años 80, la calidad de los servicios TI que prestaba el gobierno británico era tal que se instruyó a la por entonces CCTA (Agenda Central de Telecomunicaciones y Computación, hoy Ministerio de Comercio, OGC) para que desarrollara una propuesta con el fin de que los ministerios y demás oficinas del sector público de Gran Bretaña utilizaran de manera eficaz y con eficiencia de costes los recursos TI. El objetivo era desarrollar una propuesta sin compromisos con proveedor alguno. Esto dio como resultado la Information Technology Infrastructure Library™ (ITIL). ITIL1 nació de una colección de las mejores prácticas observadas en el sector de servicios TI. ITIL proporciona una descripción detallada de una serie de buenas prácticas de TI, a través de una amplia lista de roles, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier organización de TI. En algunos casos se han definido las buenas prácticas como procesos que cubren las actividades más importantes de las organizaciones de servicios de TI. La vasta cantidad de temas cubiertos por las publicaciones convierte ITIL en un elemento de referencia útil para fijar nuevos objetivos de mejora para la organización de TI. La organización puede así crecer y madurar con ellos. Basándose en ITIL se han desarrollado varios sistemas para la Gestión de Servicios TI, generalmente organizaciones del negocio. Los ejemplos incluyen Hewlett & Packard (HP ITSM modelo de referencia), IBM (TI Modelo de Proceso), Microsoft (MOF) y muchos otros. Esta es una de las razones por las que ITIL se ha convertido en el estándar de facto para describir varios procesos fundamentales de la Gestión de Servicios TI. Esta adopción y adaptaciones de ITIL reflejan la propia filosofía de ITIL, y son desarrollos bien venidos para que ITIL se transforme en el tan necesario orden metodológico imprescindible para los actuales entornos heterogéneos y distribuidos de TI. La falta de una guía básica, introductoria y orientada al auto aprendizaje ha puesto trabas a la adopción general de ITIL. EI material proporcionado en los cursos de ITIL es a menudo demasiado escaso porque se elaboran específicamente para cada curso. Esta publicación esta dirigida a cualquier persona involucrada en la Gestión de Servicios TI o interesada en el tema. Dado que el colectivo al que apuntamos es muy amplio, el Forum de Gestión de Servicios TI (itSMF) resulta el canal perfecto para la industria como organización sin fines de lucro. Los objetivos del itSMF y de esta publicación son compatibles. La declaración de misión del itSMF es la siguiente: “El objetivo del ITSMF es promover experiencia y buenas prácticas actuales de la Gestión de Servicios TI, como organización independiente, sin fines de lucro. ITSMF para ello organiza conferencias, publica una revista, establece grupos de trabajo, y edita publicaciones. ITSMF también tiene como objetivo ampliar su 1

ITIL. es una marca registrada de CCTA/OGC

1

Introducción número de miembros.” Como corresponde, la declaración del ITSMF con respecto a este libro es: “Hacer accesible a una audiencia mas amplia la experiencia de la Gestión de Servicios TI.” Así, los objetivos de este libro son: 1. 2. 3. 4.

Contribuir a conseguir la misión del itSMF publicando un libro de referencia práctico y accesible sobre gestión de servicios TI, que también se pueda utilizar para preparar los exámenes de ITIL. Adoptar ITIL como el marco de referencia estándar y común para el libro. Estar actualizado con los nuevos términos, experiencia y métodos relevantes que hagan más accesible la Gestión de Servicios TI, y publicar nuevas ediciones regularmente. Asegurar que el texto es independiente haciendo caso omiso de las publicaciones comerciales.

Dado el rápido desarrollo en este campo, los libros de ITIL no siempre pueden describir los últimos avances. ITIL es en primera instancia una colección de buenas prácticas desarrolladas en la industria, y la teoría y la práctica no siempre van a la par. Cuando escribimos este libro tratamos de incorporar los progresos actuales del campo de las TI, sin desviarnos considerablemente de las publicaciones de ITIL. De esta manera, se puede utilizar el libro como guía de auto-estudio para prepararse para los exámenes oficiales de ITIL, y como introducción general a áreas más amplias de la Gestión de Servicios TI. Esta publicación no se dirige a la planificación y la implementación en profundidad de los procesos de ITIL. En el capítulo 2 "Fundamentos de la Gestión de Servicios TI", sin embargo, se mencionan de forma general los temas relacionados con la Gestión de Servicios TI, en términos de calidad, procesos y políticas. La primera edición de este libro esta basada en una publicación itSMF de Holanda, creada como introducción a la Gestión de Servicios TI. Ese trabajo se basaba en resúmenes y descripciones de publicaciones ITIL, autorizados por la OGC. Un gran número de auditores de distintos miembros del itSMF auditó una edición global. Karen Ferris, KMF Advance, y Graham Kennedy, Pro-Active Service P/L realizaron la revisión inicial de la edición australiana en enero del 2002. La revisión posterior en mayo 2002 fue hecha por Karen Ferris. Dado el deseo de un amplio consenso en el campo de ITIL, son bienvenidos nuevos desarrollos, material adicional y contribuciones de profesionales de ITIL. Los editores discutirán los contenidos y los incorporarán si corresponde a las nuevas ediciones. Jan van Bon Redactor jefe Abril 2004 Si tiene algún comentario sobre este documento por favor envíelo a los editores de "Gestión de Servicios TI, una introducción a ITIL", c/o Inform-IT, P.O. Box 23. 9841 PA Grijpskerk, the Netherlands, e-mail: [email protected].

2

Gestión de Servicios TI basado en ITIL

Capítulo 2: Gestión de Servicios TI – fundamentos Este capítulo trata temas tales como gestión de servicios, calidad, organización, política y procesos. Estos conceptos ofrecen un marco de referencia para el desarrollo de un acercamiento sistemático a la Gestión de Servicios TI. Los procesos de Gestión de Servicios TI descritos en este libro (también nombrados como Gestión TI) se comprenden mejor al analizarlos bajo la perspectiva de los conceptos sobre organizaciones, calidad y servicios que influenciaron el desarrollo de la metodología. La familiaridad con estos términos también ayuda a comprender los vínculos entre los diferentes elementos de la IT Infrastructure Library (ITIL). ITIL es la mejor descripción conocida de Gestión de Servicios TI y es, por lo tanto, utilizada como base para este libro. En este capitulo se introducen los siguientes temas: • Servicios y calidad - esta sección trata la relación entre la experiencia de calidad de los clientes de la empresa y los usuarios, y la gestión de calidad del proveedor de servicios TI. • Organización y políticas - esta sección trata conceptos tales como visión, objetivos y políticas y discuten conceptos como planificación, cultura corporativa y Gestión de Recursos Humanos. También se discute la coordinación entre los procesos del negocio de una empresa y las actividades TI que los soportan. • Gestión de Procesos - esta sección considera el control de los procesos relacionados con los Servicios TI.

2.1 Servicios y calidad Las organizaciones a menudo son muy dependientes de sus servicios TI y no sólo esperan que dichos servicios TI proporcionen soporte a la organización sino que también aporten nuevas opciones para conseguir los objetivos de la organización. Asimismo, las elevadas expectativas de los clientes de servicios TI tienden a cambiar significativamente con el tiempo. Los proveedores de servicios TI ya no pueden permitirse el lujo de centrarse en la tecnología y en su organización interna, sino que ahora deben considerar la calidad de los servicios que ofrecen y concentrarse en la relación con sus clientes. La provisión de servicios TI implica la gestión total –mantenimiento y operación- de la infraestructura TI Antes de comprar un producto, generalmente evaluamos su calidad tanto como su apariencia, su utilidad y sus prestaciones. En general, el cliente tiene pocas oportunidades para influir sobre la calidad del producto. Esto se debe a que ese producto ha sido desarrollado en una fábrica mediante un proceso sobre el que el cliente no tiene control. Gestionando efectivamente la planta de producción, el fabricante tratará por su parte de entregar un producto de calidad constante. En este ejemplo, la fabricación, las ventas y el consumo del producto son procesos independientes. Sin embargo, los servicios se proporcionan en relación con el cliente. Los servicios no pueden evaluarse por adelantado, sino sólo una vez prestados. La calidad de un servicio depende cierta forma de la manera en la que proveedor de servicio y su cliente interactúan. A diferencia del proceso de fabricación, el cliente y el proveedor pueden realizar cambios cuando se está desarrollando y utilizando el servicio. La forma en la que el cliente percibe el servicio y lo que el proveedor piensa que ofrece, dependen ampliamente de sus experiencias personales y de sus expectativas. El proceso de proveer un servicio es la combinación de producción y uso, en la que participan simultáneamente el proveedor y el cliente.

3

Gestión de Servicios TI - Fundamentos

La percepción del cliente es esencial para la provisión de los servicios. Los clientes generalmente se harán las siguientes preguntas para evaluar la calidad del servicio: ¿El servicio cumple con mis expectativas? ¿Puedo esperar un servicio similar la próxima vez? ¿Es razonable el coste del servicio?

• • •

Si el servicio cumple o no con las expectativas depende ante todo de cuan eficazmente se acordaron los entregables con el cliente, más que de la propia forma en la que se provee el servicio. Un dialogo continuo con el cliente es esencial para refinar los servicios y asegurarse de que tanto el cliente como el abastecedor sepan lo que se espera del servicio. En un restaurante, el camarero primero explicará el menú, y luego, al servir el plato, preguntará si es de su gusto. El camarero coordina activamente la oferta y la demanda durante la comida. Y es esta experiencia con el cliente lo que se utiliza para mejorar el contacto futuro con él. La calidad de un servicio es la capacidad que tiene éste para satisfacer las necesidades y las expectativas del cliente. Para poder proporcionar calidad, el abastecedor deberá evaluar continuamente la forma en la que se experimenta el servicio y lo que el cliente espera en el futuro. Lo que un cliente considera normal puede resultar algo especial para otro, y sin embargo con el tiempo el cliente se acostumbrará a lo que consideraba especial al principio. Los resultados de la evaluación del servicio pueden utilizarse para determinar si este debe ser modificado, si el cliente debe recibir más información, o si es necesario cambiar el precio del servicio. La calidad es el conjunto de características de un producto o servicio que influyen en la satisfacción de las necesidades explicitas e implícitas (ISO-8402). Los costes razonables pueden considerarse un requisito derivado. Una vez que se acordó lo que se espera del servicio, se debe convenir su coste. En este momento el proveedor del servicio debe ser consciente de los costes en los que incurrirá, y los valores actuales de mercado para servicios similares. El proveedor de servicio que a veces exceda las expectativas y otras no las cumpla hará que el cliente no se sienta satisfecho. Proporcionar una calidad constante es uno de los aspectos más importantes, si no el que más, de la industria de los servicios. Por ejemplo, un restaurante tendrá que comprar siempre ingredientes frescos, los chefs deberán trabajar juntos para proporcionar resultados constantes, y con suerte no existirán mayores diferencias de estilo entre el personal de servicio. Un restaurante sólo recibirá la categoría tres estrellas cuando consiga la misma calidad a lo largo del tiempo. Este no siempre es el caso: hay cambios entre el personal de servicio, una oferta exitosa puede terminarse pronto, y los chefs pueden irse para abrir sus propios restaurantes. Ofrecer alta calidad constantemente también significa que el componente de las actividades debe estar coordinado: cuanto mejor y más eficaz sea la cocina, mas rápido se puede servir a los clientes. Así, cuando se presta un servicio, la calidad total es resultado del conjunto de procesos que forman integrados el servicio. Estos procesos forman una cadena, y los eslabones se afectan unos a otros y a la calidad del servicio. La coordinación eficaz de los procesos no solo requiere proporcionar una calidad adecuada al llevar a cabo cada proceso, sino también una calidad consistente.

4

Gestión de Servicios TI basado en ITIL

2.1.1 Aseguramiento de la calidad Suministrar productos o servicios requiere actividades. La calidad de un producto o servicio depende mucho de la manera en la que se organizan estas actividades. El círculo de calidad de Deming (Figura 2.1) muestra un modelo simple y eficaz para controlar la calidad. El modelo asume que para dar una calidad apropiada, se deben seguir los siguientes pasos: • • • •

Planificar (Plan) - ¿Qué se debe hacer, cuándo, quién debe hacerlo, cómo, y utilizando qué? Hacer (Do) - se llevan a cabo las actividades programadas. Verificar (Act) - determinar si las actividades dan los resultados esperados. Actuar (Check) - ajustar los planes basándose en la información recogida al comprobar.

Una intervención eficaz y a tiempo significa que las actividades están divididas en procesos con sus propios planes y oportunidades para analizar. Debe estar claro quién es responsable en la organización y qué autoridad tiene para cambiar planes y procedimientos, incluyendo actividades y procesos.

Figura 2.1. Circulo de Calidad de Deming

El Dr. Edward Deming fue un estadista estadounidense que el General Douglas MacArthur llevó a Japón para ayudar a la reconstrucción de la economía destruida tras la Segunda Guerra Mundial. El había desarrollado teorías sobre el posible uso de la experiencia y la creatividad en las organizaciones en los EEUU en los años 30, pero debido a la Depresión sus ideas no fueron tomadas en cuenta en ese país. Sin embargo, sus métodos de optimización fueron utilizados con éxito en Japón. Algunas declaraciones típicas de Deming: • • • • • • • • •

'El cliente es la parte más importante de la línea de producción'. 'Tener clientes satisfechos no es suficiente, la ganancia viene de los clientes que regresan y de aquellos que hacen buenos comentarios de su producto o servicio a conocidos y amigos.' 'La clave de la calidad es reducir la variedad.' ‘Elimine las barreras entre los departamentos.' 'Los gestores deben aprender a tomar responsabilidades y a ser Líderes.' 'Mejorar constantemente.' 'Impartir un programa vigoroso de educación y auto-superación.' 'impartir capacitación para el trabajo.' 'La transformación es trabajo de todos.'

5

Gestión de Servicios TI - Fundamentos La Gestión de Calidad es responsabilidad de todos los que trabajan en la organización proveedora de servicios. Cada empleado debe saber cómo su contribución a la organización afecta a la calidad de trabajo provista por sus colegas, y eventualmente al servicio que proporciona la organización. La gestión de calidad también significa estar a la búsqueda de nuevas oportunidades todo el tiempo e implementar mejoras en las actividades relacionadas con la calidad. Aseguramiento de la calidad es un aspecto político dentro de la organización. Se refiere al conjunto de medidas y procedimientos que utiliza la organización para asegurar que los servicios proporcionados continúan cumpliendo las expectativas del cliente y los acuerdos establecidos. El compromiso de calidad garantiza que las mejoras originadas en la gestión de calidad se mantengan. Un sistema de calidad es la estructura orgánica relacionada con responsabilidades, procedimientos y recursos para implementar la gestión de calidad. La serie de estándares ISO 9000 es la que se usa generalmente para desarrollar, evaluar y mejorar los sistemas de calidad. Estándar de calidad ISO 9000: Algunas organizaciones exigen que sus abastecedores tengan el certificado ISO 9001 o ISO 9002. Dicho certificado prueba que el abastecedor tiene un sistema de calidad adecuado y que un auditor independiente evalúa su efectividad periódicamente. ISO es la Organización Internacional para la Estandarización. El sistema de calidad que cumple con los estándares ISO asegura al abastecedor que: -

el abastecedor ha tornado medidas para poder proporcionar la calidad acordada a los clientes; la gestión de calidad evalúa habitualmente la operación del sistema de calidad, y utiliza los resultados de las auditorias externas para implementar mejoras en el sistema si fuera necesario; los procedimientos del abastecedor se encuentran documentados y se comunican a aquellos a quienes afecta; que las quejas de los clientes están registradas, tratadas a su debido tiempo, y que se utilizan para mejorar el servicio si es posible; que el abastecedor controla los procesos de producción y puede mejorarlos.

El certificado ISO no otorga una garantía absoluta sobre la calidad del servicio provisto; sin embargo, indica que el abastecedor toma en serio el compromiso de calidad y que se encuentra listo para tomar medidas al respecto. La nueva serie de estándares ISO 9000, ISO-9000-2000, pone aun más énfasis que el estándar anterior en la capacidad de una organización para aprender de la experiencia y para implementar mejoras de calidad continuas.

2.1.2 Madurez de organización La experiencia en la mejora de calidad de los servicios TI ha demostrado que no es suficiente estructurar y definir las prácticas actuales. El origen de las diferencias entre el servicio provisto y los requisitos del cliente se relaciona generalmente con la forma en la que se gestiona la organización TI. Una mejora permanente de calidad demanda una cierta madurez de la organización.

6

Gestión de Servicios TI basado en ITIL

La Fundación Europea para la Gestión de Calidad fue creada en 1988 por catorce grandes compañías europeas, con el apoyo de la Comisión Europea. El objetivo de la EFQM es promover la Gestión de Calidad Total, para distinguirse por la satisfacción al cliente, al empleado, contribuir a la mejora de la sociedad, y los resultados de rendimiento. El "Modelo de Excelencia del Negocio” de EFQM, más conocido como el modelo EFQM, es ampliamente aceptado como el mayor marco de trabajo estratégico para gestionar una organización que busque mejorar equilibrada y continuamente todos los aspectos relacionados con el comercio. Más de 600 empresas y organizaciones de investigación se han unido a EFQM. Para mayor información: http://www.efqm.org/ El modelo de la Fundación Europea para la Gestión de Calidad (EFQM) (Figura 2.2) puede resultar útil para determinar la madurez de una organización. Este modelo identifica las áreas más importantes a considerar cuando se gestiona una organización. El círculo de Calidad de Deming esta incorporado en el modelo EFQM. Las medidas (estrategia, políticas) se toman basándose en los resultados de las diferentes áreas. Estas medidas sirven para apoyar a la planificación (por ej. la estructura de los procesos) que debería conducir a los resultados deseados. El modelo EFQM identifica nueve áreas.

Figura 2.2Modelo EFQM

Como herramienta adicional, la organización holandesa de calidad, INK, dividió el modelo en etapas que indican hasta que punto una empresa ha implementado la Gestión de Calidad Total, tanto en un área en particular, como en general. Existen cinco etapas: -

Orientada al producto - también conocida como ad hoc, orientada a la producción; todo el mundo en la organización trabaja mucho (pero sus esfuerzos no están dirigidos). Orientada al proceso - también conocida como "sabemos de qué se trata nuestro negocio", el desempeño de la organización está planificado y es repetible. Orientada al sistema - o "cooperación entre departamentos". Orientada a la cadena - también "sociedad externa"; la organización pone énfasis en el valor que agrega a la cadena abastecedor-cliente de la que forma parte. Orientada a la calidad total - o "el cielo en la tierra"; la organización ha llegado al nivel en el que el ejercicio de una mejora continua y equilibrada ha adquirido el carácter de instintivo.

7

Gestión de Servicios TI - Fundamentos

Las áreas cubiertas en el modelo EFQM pueden combinarse con los niveles de madurez organizativa. Los cuestionarios pueden utilizarse para determinar la madurez de la organización en las distintas áreas. Los auditores internos o externos pueden llevar a cabo tal valoración, Cuando una organización determina su madurez, puede desarrollar una estrategia para perfeccionarse y transformarla después en un plan. El plan, basado en el modelo y por un periodo de un año, describe las mejoras que deben hacerse en aspectos específicos de cada área y caso. Al repetir este proceso de autoevaluación y planificación año tras año, la organización se percata de cómo esta madurando. Las mayores ventajas de este planteamiento son que la organización puede mejorar su calidad paso a paso, que los resultados intermedios son visibles, y que la dirección puede pilotar la organización según su estrategia. Además del planteamiento de EFQM existen otros controles de salud y otros tipos de auto-evaluación. Algunos se centran principalmente en el ámbito interno. Debemos recordar que las mejoras a las partes internas de la organización pueden tener un efecto limitado sobre los resultados, por ejemplo si no mejora la relación con los clientes, la satisfacción de los empleados y el liderazgo, o si la estrategia y la política de la organización no están claras. En el sector de las TI, el proceso de mejora de la madurez mas conocido, es el Modelo de Madurez de Capacidad (CMM). Este método de mejora de proceso fue desarrollado por el Instituto de Ingeniería de Software (SEI) de la Universidad de Carnegie Mellon. CMM tiene como objetivo mejorar la madurez del proceso de creación de software. CMM incluye los siguientes niveles; -

Inicial - el proceso ocurre ad hoc. Repetible - los procesos han sido diseñados de manera tal que el servicio de calidad pueda repetirse. Definido - los procesos han sido documentados, estandarizados e integrados. Gestionado - la organización mide los resultados y utiliza esas medidas conscientemente para mejorar la calidad de sus servicios. Óptimo - la organización optimiza conscientemente el diseño de sus procesos para mejorar la calidad de sus servicios o para desarrollar nuevas tecnologías o servicios.

Los modelos de madurez basados en los niveles de CMM de madurez también han sido creados para la Gestión de Servicios TI. Desarrollar y mantener un sistema de calidad que cumpla con los requisitos de la norma ISO 9000 (ISO-9000-2000) puede ser considerado por la organización como la herramienta para alcanzar y mantener el nivel de madurez orientado al sistema (o "gestionado" en el CMM de Servicio TI).Esos estándares ISO hacen hincapié en la definición, descripción y diseño de los procesos. Cuando se evalúa la madurez de una organización no podemos restringirnos al proveedor del servicio. El nivel de madurez del cliente (Figura 2.3) también es importante. Si existen grandes diferencias entre el abastecedor y el cliente, entonces estas deberán ser consideradas para evitar un error en el planteamiento, los métodos y las expectativas mutuas. En concreto, esto afecta a la comunicación entre el cliente y el abastecedor. Es aconsejable que ambas organizaciones tengan el mismo nivel de desarrollo para operar a ese nivel, o para ajustar la comunicación en línea con el nivel mas bajo.

Figura 2.3 Niveles de Comunicación y madurez: cliente y proveedor

8

Gestión de Servicios TI basado en ITIL

2.2 Organización y políticas Las secciones anteriores ilustran claramente que la calidad de servicio se encuentra en franca asociación con la calidad de una organización y sus políticas. Esta sección tratará otros aspectos importantes de la organización y políticas que son relevantes a la gestión de procesos.

2.2.1 Visión, objetivos y políticas Una organización es una forma de cooperación entre personas. Cualquier organización, desde un club de petanca hasta una empresa multinacional, depende del concepto de por qué vale la pena cooperar con la organización. Esta visión puede ser poder ganar dinero vendiendo PCs. Sin embargo, para resultar atractivo para los stakeholders (p. ej. clientes, inversionistas, personal) su organización tendrá que comunicar por qué deberían hacer negocios con usted, por ejemplo porque usted es el mejor, el mas barato o el mas gracioso. De esta manera, usted querrá elaborar una imagen acorde. Para comunicar su visión, se puede definir a la organización a través de la Declaración de Misión (Figura 2.4). La declaración de misión es una descripción breve y clara de los objetivos de la organización y los valores en los que cree. Los objetivos de la organización describen en detalle lo que desea conseguir. Los buenos objetivos tienen cinco elementos fundan en tales: deben ser Singulares, Medibles, Adecuados, Realistas, y ligados al Tiempo (SMART). La política de la organización es la combinación de todas las decisiones y medidas tomadas para definir y conseguir los objetivos. En tales políticas, la organización priorizará los objetivos y decidirá cómo se consiguen los mismos. Por supuesto, las prioridades pueden cambiar con el tiempo, según las circunstancias. Cuanto más claras sean las políticas de la organización para todos los stakeholders, menor necesidad de definir de qué manera el personal debe hacer su trabajo. En vez de utilizar procedimientos detallados, el personal puede guiarse con las políticas de manera independiente. Las políticas que se formulan con claridad contribuyen a crear una organización flexible, ya que todos los niveles de la organización pueden responder con mayor rapidez a las circunstancias cambiantes.

Figura 2.4 Visión, objetivos y políticas

La planificación es necesaria para implementar las políticas en forma de actividades específicas. Los planes están a menudo divididos en etapas para fijar hitos que sirvan para monitorizar su progreso. Por ejemplo, se pueden usar las políticas para diseñar un plan anual, que se utilizará luego para desarrollar los presupuestos. Un plan anual puede hacerse más detallado para un departamento, un proyecto, o un trimestre. Cada uno de estos planes contiene un número de elementos: un programa de actividad, los recursos necesarios, y acuerdos sobre la calidad y cantidad de los productos o servicios a suministrar.

9

Gestión de Servicios TI - Fundamentos Para realizar las actividades planeadas es precisa la acción. Las acciones son asignadas al personal como tareas, o cedidas a organizaciones externas. Cuando se traduce la misión de la organización en objetivos, políticas, planificación y tareas, existe el riesgo de que después de un tiempo la misión, los objetivos o las políticas se olviden. Por tal razón es importante que a cada paso se mida si la organización todavía se esta moviendo en la dirección correcta, y se tomen acciones correctivas si fuera necesario. Así, debemos evaluar si la organización y los procesos cumplen con los objetivos, y para ello existen varios métodos. Uno de los métodos del negocio más comunes es la Cuadro de Mando Integral o Balanced Score Card (BSC). En este método, los objetivos de la organización o los procesos se utilizan para definir Factores Críticos de Éxito (CSF). Los CSFs están definidos según áreas de interés o perspectivas: clientes/mercado, procesos del negocio, personal/innovación y finanzas. Los parámetros determinados para medir si los CFSs cumplen con los estándares se conocen como Indicadores Clave de Rendimiento (KPI). Si es necesario se pueden subdividir en Indicadores de Rendimiento (PI). Los Indicadores Clave de Rendimiento, o KPIs, son parámetros para medir el progreso relativo con relación a los objetivos principales o Factores Críticos de Éxito (CSF) en la organización. El resultado de las mediciones y las circunstancias cambiantes pueden llevar a la modificación de los procesos, tareas, planes, y políticas, y hasta a un cambio en los objetivos, la misión y la visión de la organización. Cuando mas madura es una organización, más fácil le resultará hacer frente a tales cambios. Si el departamento TI soporta los intereses del negocio, los objetivos del departamento TI derivarán de los objetivos del negocio. El departamento TI, por ejemplo, puede tener este objetivo: "Contribuir a la fuerza competitiva del negocio". Los objetivos específicos del departamento TI se desarrollarán así con base en este objetivo general. Según la naturaleza del negocio, los objetivos del departamento TI serán definidos tomando en cuenta aspectos de seguridad, accesibilidad, tiempo de respuesta, sofisticación técnica, y otras consideraciones.

2.2.2 Horizonte de planificación Cuando se consideran las políticas y la planificación del departamento TI, debemos ser conscientes de los lazos entre la planificación global del negocio, los sistemas de aplicación y la infraestructura técnica. Cuando planeamos la red y las aplicaciones del negocio, el departamento de TI deberá estar más allá de una planificación a corto plazo para garantizar que el negocio tenga una infraestructura TI en la que desarrollarse en el momento actual y en el futuro. La Figura 2.5 muestra un ejemplo de las relaciones entre los diferentes planes.

Figura 2.5 Horizonte de planeamiento

10

Gestión de Servicios TI basado en ITIL La infraestructura técnica tiene un amplio horizonte de planificación y su papel de soporte contiene menos vínculos claros con las actividades esenciales del negocio. Lleva tiempo desarrollar la infraestructura técnica, y el hecho de que los sistemas de información y los negocios dependan de la infraestructura técnica limita la velocidad con la que pueden implementarse los cambios. Además, la creación de una infraestructura tecnológica demanda una inversión considerable y se debe tener en cuenta el tiempo de depreciación. El horizonte de planificación es más corto para las aplicaciones ya que son diseñadas con intenciones claramente de negocio. Para poner en práctica la planificación del ciclo de vida de las aplicaciones lo primero que debe considerarse son las funciones del negocio que proveerá el sistema, tras lo cual se encuentra la tecnología fundamental. Los planes del negocio, basados en la estrategia de la organización, cubren por lo general un año natural o financiero. Durante este periodo se elaboran el presupuesto, los informes de planificación y de progreso. En algunos sectores se ha acortado el tiempo del ciclo de planificación porque los ciclos de desarrollo de los productos también se han reducido. La planificación debe consignar cuatro elementos: -

Tiempo - es el factor más fácil de determinar. Lo define la fecha de comienzo y de finalización, y se divide a menudo en etapas. Cantidad - los objetivos deben ser medibles para monitorizar el progreso. Términos tales como 'mejor' y 'más rápido' resultan insuficientes para los fines de la planificación. Calidad - la calidad de los entregables (resultados) deben ser los apropiados para el objetivo. Costes e ingresos - los resultados deben coincidir con los costes, esfuerzos e ingresos esperados.

La diferencia en las perspectivas de planificación se da entre áreas, y también entre los diferentes niveles de actividades y procesos (estratégico, táctico y operativo). Este tema será analizado con mayor profundidad más adelante.

2.2.3 Cultura Las organizaciones que desean cambiar, por ejemplo mejorando la calidad de sus servicios, se enfrentarán a la larga con la cultura de la organización. La cultura de la organización, o cultura corporativa, se refiere a la forma en la que las personas se relacionan unas con otras dentro de la organización; la manera en la que se toman y se llevan a cabo las decisiones; y la actitud de los empleados para con su trabajo, los clientes, abastecedores, superiores y colegas. La cultura, que depende de los estándares y valores del personal de la organización no puede controlarse, pero si influenciarse. Influenciar la cultura de una organización supone liderazgo en forma de una política clara y consistente y de una política de personal que le dé soporte. La cultura corporativa puede tener gran influencia en la provisión de servicios TI. Los negocios valoran la innovación de diferentes formas. En una organización estable, donde la cultura dé poco valor a la innovación, puede resultar difícil ajustar sus servicios TI a los cambios en la organización del cliente. Si el departamento TI es inestable, una cultura que valora el cambio puede plantear una seria amenaza a la calidad de sus servicios. En tal caso, se puede producir la liberación completa, donde muchos cambios sin control producen gran cantidad de fallos.

2.2.4 Gestión de Recursos Humanos La política de personal tiene un papel importante y fundamental en la consecución de objetivos a largo plazo de una organización (ver también el modelo EFQM). También se puede utilizar para cambiar la política corporativa. El objetivo de la actual gestión de recursos humanos es optimizar el rendimiento de todo el personal de la organización, para lo cual se usan todos los instrumentos disponibles: incorporación y selección, capacitación y desarrollo profesional, motivación y gratificación.

11

Gestión de Servicios TI - Fundamentos La Gestión de Recursos Humanos (HRM) es la cumbre de la gestión de personal moderna. La Gestión de Recursos Humanos esta basada en dos premisas: -

La gestión de personal debe contribuir a los objetivos de la organización. Si las organizaciones tienen que responder mejor y con mayor rapidez en un ambiente que cambia cada vez más rápido, esto afectará al despliegue, la calidad y el volumen de personal.

-

Ofrecer a los empleados la posibilidad de desarrollar y utilizar sus habilidades beneficiará a la organización.

Hay tres planteamientos para la HRM: -

El planteamiento firme entiende a los recursos humanos como un medio de producción que debe ser organizado lo más eficiente y eficazmente posible. Como la estrategia corporativa esta determinada por factores económicos, técnicos y de mercado, lo mismo se aplica a la política de personal. Este planteamiento otorga diferentes valores a los empleados. Los empleados fundamentales son estratégicamente más importantes que los periféricos los cuales pueden ser reemplazados con facilidad. Por ejemplo, una empresa puede decidir contratar sólo personal fundamental en forma permanente, y para el resto utilizar una agencia de contratación.

-

El planteamiento flexible considera que el negocio se verá beneficiado al hacer el mejor uso posible del potencial humano y de las oportunidades. Los empleados de hoy en día están muy capacitados, son muy ambiciosos y están preparados para hacer una gran inversión en su trabajo. Por tal razón, su potencial debe identificarse de antemano considerando la necesidad de un desarrollo continuo (desarrollo profesional, política de capacitación). Cuando se selecciona la estrategia y la política, el negocio debe basar su decisión en el talento y el potencial de sus empleados.

-

El planteamiento integral toma en cuenta los intereses compartidos del personal y la dirección de la organización. Para conseguir los objetivos de la organización tendrá que existir buena entrada, buen movimiento y flujo de personal. Los cambios en el mercado y en la organización (p. ej. los desarrollos tecnológicos) provocan cambios constantes en las habilidades requeridas.

Todos los aspectos relacionados con la política de personal deben ser minuciosamente coordinados. La dinámica de los empleados dentro de la organización, las habilidades determinantes y a desarrollar (competencia), y la promoción en el mercado laboral interno se están convirtiendo cada vez más en factores de importancia dentro de la organización. La calidad de servicio que brinda una organización se beneficiará de un mejor uso del potencial de sus empleados. Esto facilita el progreso constante. Los instrumentos para la gestión de calidad en la política de personal incluyen: -

-

12

El despliegue de la política - comunicar a cada empleado cómo y hasta qué punto su tarea contribuye a hacer realidad los objetivos de la organización. Para lograr el éxito es condición importante extender el despliegue a todas las capas de la gestión. Autorización - dar a los empleados la oportunidad de organizar e implementar sus tareas de acuerdo con la organización. El grado de autorización determina hasta que punto se puede hacer responsables a los empleados por la calidad de trabajo que ofrecen. Responsabilidad - como resultado de la política de despliegue y autorización. Si se explicó a un empleado lo que se espera de él, y si se le brindó la oportunidad de preparar y llevar a cabo la tarea como lo deseaba, entonces debe hacerse responsable de ello. Esto puede ser tomado como base de evaluación y gratificación para los empleados. La gratificación puede ser material (salario) o inmaterial, por ejemplo ascenso, nuevas oportunidades para desarrollarse y oportunidades profesionales. Gestión de competencias - esto incluye el uso eficaz de las competencias disponible en la organización, y una forma sistemática de desarrollar las competencias que necesita la misma. Este planteamiento define y monitoriza las competencias que necesitan los procesos y los proyectos así como las competencias de los empleados. Al organizar a los empleados la clave es, además de la obtención de un buen nexo entre

Gestión de Servicios TI basado en ITIL las competencias necesarias y las disponibles, las oportunidades de crear competencias, transferir experiencia y aprender habilidades. Los mentores o los entrenadores pueden ayudar a los empleados. Establecer grupos de habilidades también puede ayudar al intercambio de experiencia y a fomentar el desarrollo de nuevas competencias. 2.2.5 Gestión de Relaciones con el Cliente TI La calidad de los servicios TI depende ampliamente de la buena relación con los clientes de la organización TI. Estas relaciones sientan la base para establecer y actualizar los acuerdos. La Gestión de Relaciones con el Cliente TI es la encargada de mantener la relación con los clientes y de coordinar a nivel estratégico, táctico y operativo con las organizaciones de clientes. La Figura 2.6, muestra un diagrama de las relaciones con el cliente, ilustra la comunicación horizontal que se da entre los clientes y la organización TI, con respecto al soporte y a la coordinación. La comunicación vertical tiene relación con las políticas, el control y la generación de informes.

Figura 2.6 Gestión de Relaciones con el Cliente

En la Gestión de Relaciones con el Cliente TI, el mayor desafío es asegurar que existan relaciones buenas y eficaces a todo nivel entre la organización TI y la del cliente. Sin embargo, la magnitud de la Gestión de Relaciones con el Cliente TI será diferente según los niveles. Uno de los elementos en las relaciones con el cliente es el Centro de Servicios, y el control de los Niveles de Servicio se puede basar en la Gestión de Niveles de Servicio. En estas áreas, la Gestión de Relaciones con el Cliente TI representara, principalmente, un papel de soporte organizando, por ejemplo, encuestas entre los clientes y los usuarios, proporcionando información, etc. El usuario es la "mano sobre el teclado ", el empleado que utiliza los servicios TI para sus actividades habituales. El cliente es aquel que "paga la cuenta", la persona autorizada para dar por finalizado el acuerdo sobre los servicios con la organización TI (por ejemplo un Acuerdo de Nivel de Servicio, 0 SLA) y responsable de abonar los servicios TI. Obviamente el cliente "que paga la cuenta" también puede ser el usuario de las "manos sobre el teclado" en muchas oportunidades. La Gestión de Relaciones con el Cliente TI representa un papel muy importante en el desarrollo del Alineamiento Estratégico entre la organización TI y la organización que compra de servicios TI. En la práctica, esto consiste principalmente en mantenerse en contacto con la organización de clientes, y explorar las opciones para aunar los objetivos estratégicos de ambas organizaciones. Ésta puede ser la base de una

13

Gestión de Servicios TI - Fundamentos relación a largo plazo, en la que la organización TI se centra en el cliente y propone soluciones que le ayuden a lograr sus objetivos del negocio. Dada la naturaleza dinámica de la organización de clientes y de la organización TI, también debe coordinarse las consecuencias de los cambios en ambas organizaciones. Los acuerdos con los clientes sobre los servicios provistos son especificados mediante propuestas de servicios en la Gestión de Niveles de Servicio. Por ejemplo, si el cliente desea introducir una Intranet, entonces se debe acordar la disponibilidad, el soporte a los usuarios, la implementación de peticiones de cambio y el coste. Tales acuerdos se formalizan en los Acuerdos de Nivel de Servicio (SLA). Si la organización de clientes desea cambiar (expandir o modificar) servicios TI que se enmarcan dentro de los acuerdos establecidos en el SLA, se deberá generar una Petici6n de Cambio (RFC). La Gestión de Cambios procesa después esa petición. Los cambios que estén más allá de los acuerdos actuales se incluyen en el proceso de la Gestión de Niveles de Servicio. En la mayoría de los casos, los usuarios pueden contactar al Centro de Servicios (Service Desk) para consultar tales peticiones y preguntas, y para informar sobre los problemas que aparecen. La figura 2.6 muestra información sobre la comunicación vertical y horizontal y sobre los horizontes de planificación de los procesos. La coordinación a nivel estratégico tiene un horizonte de planificación de varios años. La Gestión de Niveles de Servicio se relaciona con los acuerdos a nivel táctico, con un horizonte de planificación de por lo menos un año. La Gestión de Cambios, Centro de Servicios y la Gestión de Incidentes se ocupan del nivel de operaciones, con un horizonte de planificación de meses, semanas, días o hasta horas.

2.3 Gestión de Procesos Todas las organizaciones se orientan a hacer realidad su visión, misión, objetivos y políticas, y para ello se deben realizar las actividades correctas. Volvamos al ejemplo del restaurante, las actividades adecuadas incluyen comprar alimentos, llevar la contabilidad, pedir material de publicidad, recibir a los invitados, limpiar las mesas, pelar las patatas, y hacer café. Con una lista tan desordenada, algo se va a escapar y nos confundiremos fácilmente. Por tal motivo es una buena idea estructurar las actividades. Sería preferible disponer de una lista de manera tal que podamos ver como cada grupo de actividades contribuye a los objetivos del negocio, y como se relacionan. Tales grupos de actividades se conocen como procesos. Si la estructura de procesos de una organización esta claramente descripta, mostraran: -

Qué debe hacerse. Qué resultado se espera. Cómo medimos si los procesos dan los resultados esperados. Cómo los resultados de un proceso afectan a los de otros procesos.

Las preguntas de la Figura 2.7 surgen continuamente durante el planteamiento basado en el proceso de la Gestión de Servicios TI. Las herramientas para responder a estas preguntas se encuentran a la derecha.

14

Gestión de Servicios TI basado en ITIL

Figura 2.7 Modelo de mejora del proceso

2.3.1 Procesos Cuando se organizan las actividades en procesos, no utilizamos la asignación existente de tareas, ni las divisiones departamentales existentes. Es una elección consciente. Al optar por una estructura de procesos, podemos demostrar que ciertas actividades de la organizaci6n no están coordinadas, están duplicadas o que están descuidadas o son innecesarias. Un proceso es una serie de actividades relacionadas lógicamente que conducen a definir un objetivo. En todo caso miramos al objetivo de los procesos y las relaciones con los otros procesos. Un proceso es una serie de actividades que se desarrollan para convertir una entrada en una salida (Figura 2.8). Podemos asociar el consumo y la producción de cada proceso con los estándares y las características de calidad para proveer información sobre los resultados que deben obtenerse con los procesos. Esto produce una cadena de procesos que muestra que pasa dentro de la organización y cuales son los resultados, y también los puntos de monitorización de la cadena para controlar la calidad de los productos y los servicios brindados por la organización. Los estándares de producción de cada proceso deben definirse para que la cadena completa de procesos cumpla con los objetivos de la corporación, si cada proceso se desempeña de acuerdo con los estándares definidos para ese proceso. El proceso será eficaz si el resultado del proceso se ajusta a los estándares definidos. En caso de que las actividades del proceso también se desarrollen con el mínimo esfuerzo y costes necesarios, el proceso será eficiente. El propósito de la gestión de procesos es utilizar la planificación y el control para garantizar que los procesos sean eficaces y eficientes. Es posible estudiar cada proceso por separado para optimizar su calidad. El propietario del proceso es responsable de los resultados del mismo. El gestor del proceso es responsable de realizar y estructurar los procesos, y de informar sobre ellos al propietario del proceso. Los operadores del proceso son responsables de actividades específicas, y el gestor de procesos recibe información sobre estas actividades.

15

Gestión de Servicios TI - Fundamentos

Figura 2.8 Diagrama de proceso

La combinación lógica de las actividades da como resultado la clara transferencia de puntos en donde se puede controlar la calidad de los procesos. En el ejemplo del restaurante, podemos separar la responsabilidad de comprar y cocinar, para que los cocineros no tengan que comprar nada y no gasten demasiado en ingredientes frescos que no agregan valor. La dirección de la organización puede controlar teniendo en cuenta la calidad de los procesos según los datos de los resultados de cada proceso. En muchos casos, se deberán acordar los indicadores de rendimiento relevantes y los estándares. El control diario de los procesos puede ser dejado a cargo del gestor de procesos. El propietario del proceso evaluará los resultados considerando el informe de los indicadores de rendimiento y observando si cumplen con los estándares acordados. Si los indicadores no son claros, el propietario del proceso tendrá dificultades para determinar si los procesos están bajo control, y si se están implementando las mejoras proyectadas. Los procesos son descritos utilizando procedimientos e instrucciones de trabajo. Un procedimiento es una descripción de actividades lógicamente relacionadas, y de la persona que se encarga de realizarlas. Un procedimiento puede incluir etapas de distintos procesos. Un procedimiento define quien hace que cosa, y varía dependiendo de la organización. Un grupo de instrucciones de trabajo delimita cómo se deben llevar a cabo una o más actividades en un procedimiento.

La Figura 2.9 muestra el modelo de proceso basado la metodología ITIL que es la base del proceso de Gestión de Servicios TI que describe este libro.

16

Gestión de Servicios TI basado en ITIL

Figura 2.9 Modelo de proceso genérico ITIL

2.3.2 Procesos y departamentos La mayoría de los negocios se encuentran organizados jerárquicamente. Tienen departamentos que son responsables de un grupo de empleados. Hay diferentes formas de estructurar los departamentos, por ejemplo por cliente, producto, región o disciplina. Los servicios TI dependen por lo general de varios departamentos, clientes o disciplinas. Por ejemplo, si hay que proporcionar un servicio TI a usuarios con acceso a un programa contable a través de un servidor central, tendremos que hacer uso de varias disciplinas. El departamento de sistemas debe hacer que el programa y la base de datos estén accesibles, el departamento de comunicaciones debe hacer accesible los sistemas, y el departamento de soporte de PCs debe proveer a los usuarios con una interfaz para que puedan acceder a la aplicación. Los procesos que abarcan muchos departamentos pueden controlar la calidad del servicio evaluando ciertos aspectos como calidad, disponibilidad, capacidad, coste y estabilidad. Una organización de servicios tratará de alcanzar estos aspectos de calidad para cumplir con las peticiones de los clientes. La estructura de tales procesos debe garantizar que haya buena información sobre la provisión de servicios, para poder mejorar los servicios de planificación y control.

Figura 2.10 Procesos y departamentos (ejemplo)

17

Gestión de Servicios TI - Fundamentos La Figura 2.10 muestra un ejemplo básico de las combinaciones de actividades en un proceso (se indica con líneas punteadas).

2.3.3 Gestión de Servicios TI La Gestión de Servicios TI es lo que se conoce en principio como el planteamiento orientado al proceso y al servicio de lo que fue una vez la Gestión de TI En este capítulo demostraremos que los procesos siempre deben tener un objetivo definido. El objetivo de los procesos de Gestión de Servicios TI es contribuir a la calidad de los servicios TI. La gestión de calidad y el control de procesos forman parte de la organización y sus políticas. En un planteamiento orientado al proceso también debemos considerar la situación que se vive dentro de la organización (políticas, cultura, tamaño, etc.). ITIL, la mejor orientación conocida para la Gestión de Servicios TI, no dicta el tipo de organización, sino que describe las relaciones entre las actividades en los procesos, que son relevantes a cualquier organización. Esto proporciona un marco para intercambiar experiencias entre las organizaciones. Este planteamiento también ofrece un marco para aprender de la experiencia de organizaciones dinámicas.

18

Gestión de Servicios TI basado en ITIL

Capítulo 3: Introducción a ITIL Este capítulo describe la estructura y los objetivos de la IT Infrastructure Library (ITIL) y las organizaciones que contribuyen a mantener a ITIL como estándar de las mejores prácticas de la Gestión de Servicios TI.

3.1 Fundamentos ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de las TI para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios TI de calidad que se correspondan con los objetivos del negocio, y que satisfaga los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por mantenimiento y operaciones. A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, publica o privada, con servicios TI central izados o descentralizados, con servicios TI internos o provistos por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable. La Gestión de Servicios TI dirige la provisión y el soporte de los servicios TI adaptados a las necesidades de la organización. ITIL fue creada para comunicar las mejores prácticas en la Gestión de Servicios TI sistemática y coherentemente. Su planteamiento se basa en la calidad de servicio y en el desarrollo eficaz y eficiente de los procesos. ITIL ofrece un marco común para todas las actividades del departamento TI, como parte de la provisión de servicios, basado en la infraestructura TI. Estas actividades se dividen en procesos, que proporcionan un marco eficaz para lograr una Gestión de Servicios TI más madura. Cada uno de estos procesos cubre una o más tareas del departamento TI, tal como desarrollo de servicio, gestión de infraestructura, y provisión y soporte de los servicios. Este planteamiento del proceso permite describir las mejores prácticas de la Gestión de Servicios TI independientemente de la estructura de organización real de la entidad. Muchas de estas prácticas son claramente identificables y son de hecho utilizadas hasta cierto punto en varias organizaciones TI. ITIL presenta estas mejoras prácticas de manera coherente. Los libros de ITIL describen cómo estos procesos, una vez identificados, pueden ser optimizados, y cómo la coordinación entre ellos puede ser mejorada. Los libros de ITIL también explican cómo los procesos se pueden formalizar dentro de una organización. Los libros de ITIL ofrecen un marco de referencia para unificar la terminología relevante dentro de la organización, y ayuda a definir los objetivos y a determinar el esfuerzo necesario para su cumplimiento. Utilizando el planteamiento basado en los procesos, ITIL describe primero lo que debe incluirse en la Gestión de Servicios TI para dotar los servicios TI de la calidad demandada. La estructura y la asignación de tareas y responsabilidades entre las funciones y los departamentos dependen del tipo de organización y estas estructuras varían mucho entre los departamentos TI y cambian con bastante frecuencia. La descripción de la estructura de proceso ofrece un punto de referencia común que no cambia con tanta frecuencia, y que puede ayudar a mantener la calidad de los servicios TI durante y después de las reorganizaciones y entre los abastecedores y los socios cuando cambian. La lista incluida a continuación identifica algunas ventajas y desventajas de ITIL. Esta lista no pretende ser definitiva o exhaustiva, pero se ofrece como base para considerar las ventajas o las desventajas de ITIL y las distintas formas en las que las organizaciones utilizan esta metodología.

19

Introducción a ITIL

Ventajas de ITIL para el cliente/usuario: - La entrega de servicios TI se orienta más al cliente y los acuerdos sobre la calidad del servicio mejoran la relación entre el departamento TI y el cliente. - Se describen mejor los servicios, en un lenguaje más cómodo para el cliente, y con mayores detalles. - Se manejan mejor la calidad y el coste del servicio. - Mejora las comunicaciones con la organización TI al acordar los puntos de contacto. Ventajas de ITIL para la organización: - La organización TI desarrolla una estructura más clara, se vuelve más eficaz, y se centra más en los objetivos corporativos. - La dirección tiene más control y los cambios resultan más fáciles de manejar. - Una estructura de proceso eficaz brinda un marco para concretar de manera más adecuada la externalización de algunos de los elementos de los servicios TI. - Seguir las mejores prácticas de ITIL alienta el cambio cultural hacia la provisión de servicios, y sustenta la introducción de un sistema de gestión de calidad basado en las series ISO 9000. - ITIL establece un marco de referencia para las comunicaciones interna y las comunicaciones con los abastecedores, así como la estandarización y la identificación de los procedimientos. Problemas potenciales de ITIL: - Su introducción puede llevar tiempo y bastante esfuerzo, y supone un cambio de cultura en la organización. Una introducción demasiado ambiciosa puede llevar a la frustración porque nunca se alcanzan los objetivos. - Si la estructura de procesos se convierte en un objetivo en si misma, la calidad del servicio se puede ver afectada de forma adversa. En ese caso, los procedimientos se transforman en obstáculos burocráticos que tratan de evitarse en lo posible. - Puede no haber progreso si existe falta de comprensión sobre lo que deben proporcionar los procesos, cuales son los indicadores de rendimiento, y como se controlan los procesos. - No se ven las reducciones de coste y la mejora en la entrega de los servicios. - Una implementación con éxito implica el compromiso del personal de todos los niveles de la organización. Dejar el desarrollo de las estructuras de proceso a un departamento de especialistas puede aislar al departamento de la organización y puede fijar una dirección no aceptada por los otros departamentos. - Si hay poca inversión en las herramientas de soporte, los procesos pueden no funcionar adecuadamente y el servicio no mejorará. Se pueden necesitar más recursos y más personal si la organización se encuentra sobrecargada con las actividades de rutina de la Gestión de Servicios TI. Estos problemas potenciales por supuesto que se pueden superar. ITIL fue desarrollada en vista de las ventajas que aporta. Muchas de estas sugerencias de mejores prácticas buscan prevenir tales problemas, o ayudar a solucionarlos en caso de que aparezcan.

3.2 Organizaciones 3.2.1 OGC (CCTA) ITIL fue originalmente un producto de la CCTA. CCTA era la Agenda Central de Computación Y Telecomunicaciones del Gobierno del Reino Unido. Desde el 1 de abril de 2001, la OGC (Office of Government Commerce) absorbió a la CCTA y ahora es la propietaria de ITIL, El objetivo de la OGC es ayudar a sus clientes del sector público en el Reino Unido a actualizar sus actividades de provisión y a hacer el mejor uso posible de TI y demás instrumentos. "La OGC procura modernizar la provisión de TI en el gobierno, y conseguir un valor sustancial por el dinero invertido". La OGC promueve el uso de las "mejores prácticas" en muchas áreas (p. ej. la gestión de proyectos, provisión, y Gestión de Servicios TI). La OGC publica gran cantidad de libros (bibliotecas) escritos por expertos del Reino Unido e internacionales de diversas compañías y organizaciones.

20

Gestión de Servicios TI basado en ITIL La IT Infrastructure Library de la OGC consta de un número claro y completo de "Códigos de Práctica" para brindar servicios TI eficaces y eficientes.

3.2.2 ITSMF El Information Technology Service Management Forum (ITSMF), conocido originalmente como Information Technology Infrastructure Management Forum (ITIMF), es el único grupo de usuarios internacionalmente reconocido e independiente dedicado a la Gestión de Servicios TI. Es propiedad de sus miembros y son ellos quienes lo operan. El ITSMF tiene gran influencia y contribuye a la Industria de las Mejores Prácticas y a los Estándares a nivel mundial. El primer capítulo de ITSMF se fundó en el Reino Unido en 1991. El ITSMF holandés (ITSMF Holanda) fue el capítulo posterior, establecido en Noviembre de 1993. Ahora existen capítulos ITSMF en países como Sudáfrica, Bélgica, Alemania, Austria, Suiza, Canadá, los Estados Unidos, y Australia, que cooperan con itSMF Internacional. Los capítulos ITSMF promueven el intercambio de información y experiencia que permite a las organizaciones TI mejorar los servicios que ofrecen. Organizan seminarios, conferencias, sesiones sobre temas específicos, y otros eventos sobre temas actuales de Gestión de Servicios TI. También publican noticias y operan un sitio Web para compartir información. Estas tareas también contribuyen al desarrollo de ITIL.

3.2.3 EXIN y ISEB La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information Systems Examination Board" (ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. Fue realizado en estrecha cooperación con la OGC y el ITSMF. EXIN e ISEB son organizaciones sin ánimo de lucro que cooperan para ofrecer una amplia gama de certificaciones en tres niveles: -

Foundation Certificate en Gestión de Servicios TI Practitioner Certificate en Gestión de Servicios TI Manager Certificate en Gestión de Servicios TI

El sistema de certificación esta basado en los requisitos para completar eficazmente el papel pertinente dentro de una organización TI. A la fecha, se han entregado más de 50.000 certificados Foundation a profesionales de más de 30 países. El certificado Foundation esta dirigido a aquellos profesionales que deben desempeñar las tareas de mayor importancia dentro de la organización, y las relaciones entre las mismas. El examen Foundation cubre la función del Centro de Servicios, y los procesos para la Gestión de Incidentes, la Gestión de Problemas, la Gestión de Cambios, la Gestión de la Disponibilidad y de la Capacidad, la Gestión de Continuidad de Servicios TI, la Gestión Financiera para Servicios TI, y la Gestión de la Seguridad. Después de obtener el certificado Foundation, se puede pasar al examen de Practitioner y de Manager. Los Practitioners son entrenados a nivel práctico sobre el desempeño específico de los procesos ITIL o las tareas en tales procesos, para procesos como Gestión de Incidentes, Gestión de Cambios, y Gestión de Niveles de Servicio. Se capacita a los gestores a nivel teórico para controlar todos los procesos que se enuncian en el certificado Foundations, para aconsejar sobre la estructura y la optimización de los procesos, y sobre como implementarlos. Hoy en día, ITIL representa mucho más que una serie de libros útiles sobre Gestión de Servicios TI. El marco de mejores prácticas en la Gestión de Servicios TI es sector completo de organizaciones, herramientas, educación y servicios de consultoría, marcos de trabajo relacionados, y publicaciones. Desde 1990, se considera a ITIL como el marco de trabajo y el planteamiento y la filosofía compartida por quienes utilizan las mejores prácticas ITIL en sus trabajos. Gran cantidad de organizaciones se encuentran en la actualidad cooperando internacionalmente para promover el estándar ITIL como un estándar de facto para la Gestión de Servicios TI.

21

Introducción a ITIL

Figure 3.1 Entorno de ITIL (fuente: OGC)

La Figura 3.1, el medio ITIL, muestra que las organizaciones involucradas también proveen 'feedback' entre la practica actual (elipses blancas) y la teoría (elipses grises) para mantener ITIL al día. Además, se han desarrollado extensiones y alternativas, algunas de las cuales pueden ser consideradas como métodos de Gestión de Servicios TI en su propia forma. Estas alternativas mencionan las necesidades de ciertos grupos u organizaciones que tienen problemas específicos no cubiertos por ITIL. El aspecto que hace clínica a la metodología ITIL es que ofrece un marco de trabajo específico basado en la experiencia práctica de un conjunto global de usuarios profesionales.

3.3 Los Libros de ITIL Cada uno de los libros de ITIL trata una parte del marco de trabajo y da una descripción general de lo que es necesario para organizar la Gestión de Servicios TI. ITIL define los objetivos y las actividades, y las entradas y salidas de los procesos de la organización TI. Sin embargo, ITIL no brinda una descripción específica de la forma en la que se deben implementar estas actividades, ya que esto puede variar de organización a organización. Se pone mas énfasis en el planteamiento que ha sido probado; pero eso, según las circunstancias, puede ser implementado de diferentes formas. ITIL no es un método, sino que ofrece un marco de trabajo para planificar los procesos, los roles y las actividades más comunes, indicando los nexos entre ellos y los flujos de comunicaciones necesarios. ITIL se basa en la necesidad de proporcionar servicios de alta calidad, con énfasis en la relación con el cliente. La organización TI deberá cumplir los acuerdos con el cliente lo que implica mantener una buena relación con ellos, con los socios y con los abastecedores. Parte de la filosofía TI tiene su base en los sistemas de calidad, como la serie ISO 9000, y los marcos de trabajo de Calidad Total, como el EFQM. ITIL sustenta tales sistemas de calidad y ofrece una clara descripción de los procesos y las mejores prácticas en la Gestión de Servicios TI. Esto puede llevar a una reducción significativa del tiempo necesario para conseguir la certificación ISO. En principio, ITIL consistía en un gran número de libros, cada uno de los cuales describía un área especifica de mantenimiento y operación de la infraestructura TI. Los diez libros que describían Soporte de Servicio y Entrega de Servicio eran considerados el eje de ITIL. Existían aproximadamente 40 libros más sobre temas suplementarios relacionados con la Gestión de Servicios TI, desde cableado hasta manejo de las relaciones con el cliente. Sin embargo, la serie de libros originales de la Infrastructure Library abordaba la Gestión de Servicios TI desde la perspectiva TI. El Conjunto de Perspectivas del Negocio se introdujo para acortar la distancia entre el negocio y la organización TI y ayudar a alinear sus objetivos. Y hay que tener en cuenta que con el tiempo ciertos aspectos de ITIL tenían un planteamiento algo anticuado. Los libros centrales de ITIL han sido revisados y se han publicado dos libros, uno sobre Soporte del Servicio, y otro sobre Provisión del Servicio. Esto ha eliminado muchas repeticiones y contradicciones ocasionales de

22

Gestión de Servicios TI basado en ITIL las primeras colecciones y ha mejorado la cohesión interna. Ilustra también la visión de la Gestión de Servicios TI con más claridad. En cuanto a la publicación de este libro, la actualización de todas las colecciones de las publicaciones ITIL que se observa en la figura a continuación todavía no se ha completado. La estructura básica de ITIL se ilustra en la Figura 3.2, que utiliza un conjunto de piezas de rompecabezas como analogía.

Figura 3.2 ITIL puzzle (fuente: OGC)

El rompecabezas de ITIL muestra los siete elementos principales de los libros ITIL. Cada uno de estos elementos se conecta con los otros seis, y hasta cierto punto se superpone. Los siete elementos son: • Soporte del Servicio (2000) • Provisión del Servicio (2001) • Gestión de la Seguridad (1999) • Gestión de infraestructuras TI (2002) • Gestión de Aplicaciones (2002) • Planificación para Implementar la Gestión de Servicios (2002) • Perspectiva del Negocio (fecha prevista: 2004} El rompecabezas ITIL también ha sido comparado con placas tectónicas, o con continentes que chocan o se superponen. No sólo es difícil identificar con exactitud los límites, sino que además hay roces y presión. Esta imagen se confirma con lo que sucede en muchas organizaciones. En esta frontera en particular, se presentan los mayores problemas de gestión. Aunque no se puede evitar el problema, podemos, como con los terremotos, prepararnos para enfrentarlos. En este capítulo, presentaremos la colección de publicaciones ITIL usando los elementos más importantes del rompecabezas ITIL.

23

Introducción a ITIL

3.3.1 Perspectiva del Negocio Los libros ITIL de la Colección Perspectiva del Negocio describen muchos temas relacionados con la comprensión y la apreciación de los servicios TI como un aspecto integrado a la gestión del negocio. La colección de Perspectiva del Negocio, y el libro de Perspectiva del Negocio, que eventualmente reemplazara la colección, incluye: -

Gestión de la Continuidad del Negocio Asociaciones y externalizacion Cambios para la supervivencia Adaptación del negocio a los cambios radicales

Otros libros de ITIL tratan estos temas, además de los de la Colección de Perspectiva del Negocio. Gestión de Recursos Físicos La Gestión de Recursos Físicos se hace cargo de acordar los contratos entre la organización TI y las empresas que aportan los Recursos. Los abastecedores de Gestión de Recursos Físicos podrían ser responsables de la operación de todo o parte de la infraestructura TI. Sin embargo, la organización TI carga con la última responsabilidad por los servicios brindados al cliente. Este libro describe las medidas que puede tomar la organización TI para poder aceptar la responsabilidad sobre los acuerdos de Nivel de Servicio, y para evaluar los servicios provistos por los abastecedores de recursos. Gestión de Relaciones con Abastecedores Hasta cierto punto la Gestión de Relaciones con Abastecedores es similar a la Gestión de Relaciones con Clientes, pero sólo cubre la relación entre la organización TI y sus abastecedores. Una buena relación con los abastecedores no trata sólo de los acuerdos y los contratos; básicamente se ocupa de la forma de cooperación entre ambas partes, que contribuye a la entrega actual y futura de los servicios TI y a los objetivos de la organización TI. La naturaleza y el contenido de los contactos establecidos pueden distinguir las relaciones con los abastecedores. Estos pueden servir para discutir las perspectivas a largo plazo de relaciones existentes, promover las comunicaciones, o para investigar el alcance ofrecido por los diferentes abastecedores. Las tareas más importantes del proceso de Gestión de Relaciones con Abastecedores incluyen la selección de abastecedores, la evaluación de su desempeño, y la determinación de la forma en la que la organización TI opera los contactos con los abastecedores.

3.3.2 Provisión del Servicio Como se indica más arriba, el Soporte del Servicio y la Provisión del Servicio son considerados parte central del marco de trabajo ITIL para la Gestión de Servicios TI. El libro ITIL sobre Provisión del Servicio describe los servicios que necesita el cliente, y lo esencial para proporcionar esos servicios. Los siguientes temas se encuentran en la colección de Provisión del Servicio: -

Gestión de Niveles de Servicio Gestión Financiera de los Servicios TI Gestión de la Capacidad Gestión de Continuidad de los Servicios TI Gestión de la Disponibilidad

La Gestión de la Seguridad (con referencia al libro ITIL sobre Gestión de la Seguridad) se agregó en la introducción de este libro, pero no es parte de la colección de la Provisión del Servicio. La compleja interrelación entre los procesos descritos en los libros sobre Soporte del Servicio y Provisión del Servicio es casi imposible de mostrar en este diagrama. El diagrama simplificado de la Figura 3.3 ilustra las principales generalidades.

24

Gestión de Servicios TI basado en ITIL

Figura 3.3 Soporte del Servicio Y Provisión del Servicio

Gestión de Relaciones con Clientes TI Las mejores prácticas de la mayoría de las organizaciones demuestran que es aconsejable cohesionar y estructurar las relaciones con la organización del cliente a distintos niveles. Las actividades de la Gestión de Relaciones con Clientes TI abarcan muchos procesos (ver también la sección 2.2.5). El Centro de Servicios es el primer punto de contacto con los usuarios. Sin embargo, el cliente, que encarga el servicio, contactará inicialmente a través de la Gestión de Relaciones con Clientes TI. De ese modo, este proceso crea un puente entre la organización TI, que tradicionalmente ha tenido un planteamiento técnico, y los clientes que quieren alcanzar sus objetivos del negocio. La Gestión de Relaciones con Clientes TI no forma parte de la colección de Provisión del Servicio y no se desarrolla en este libro introductorio. Gestión de Niveles de Servicio El objetivo de la Gestión de Niveles de Servicio es establecer acuerdos claros con el cliente sobre los servicios TI, e implementar estos acuerdos. En consecuencia, la Gestión de Niveles de Servicio precisa información sobre las necesidades del cliente, los recursos proporcionados por la organización TI, y los recursos financieros disponibles. La Gestión de Niveles de Servicio maneja el servicio prestado al cliente (Foco en el Cliente). Al crear servicios basados en las necesidades del cliente (atracción por demanda) y no sólo según lo que le resulta técnicamente factible en la actualidad (impulsada por el suministro), la organización TI puede mejorar la satisfacción del cliente. El capítulo sobre Gestión de Niveles de Servicio en el libro de Provisión del Servicio describe: -

La claridad con la que se deben definir los acuerdos en el Acuerdo de Nivel de Servicio puede optimizar los servicios TI al justificar el coste para el cliente. Cómo se puede evaluar y discutir el servicio. Cómo se puede reforzar el servicio al soportar los Contratos con los abastecedores de la propia organización TI.

Gestión Financiera de los Servicios TI La Gestión Financiera de los Servicios TI maneja todo lo relativo con la entrega prudente de los servicios TI. Por ejemplo, la gestión Financiera proporciona información sobre los costes en los que incurre la organización al suministrar los servicios TI. Esto permite una consideración adecuada de los costes y beneficios (precio y rendimiento) al decidir que cambios realizar en la infraestructura o en los servicios TI. Tal como se discute en el capítulo sobre Gestión Financiera del libro de Provisión del Servicio, la identificación, asignación, proyección y evaluación de los costes se denominan bajo el término "contabilidad

25

Introducción a ITIL de costes", que en la versión actual de ITIL aparece como Elaboración de Presupuesto y Contabilidad. Estas actividades ayudan a entender los costes (¿en qué costes se incurre y donde?) y también se puede utilizar en la elaboración del presupuesto. Con respecto a la corriente de ingresos de la organización TI, la Gestión Financiera de los servicios TI describe varios métodos de imputación, que incluye la definición de objetivos y la determinación del precio, además de elaborar los diferentes aspectos del presupuesto. Gestión de la Capacidad La Gestión de la Capacidad es el proceso de optimización de costes, tiempo de adquisición, y despliegue de los recursos TI para sustentar los acuerdos establecidos con el cliente. La Gestión de la Capacidad tiene a su cargo la gestión de recursos, de rendimiento, de demanda, modelado, capacidad de planificación, la gestión de carga y el ajuste del tamaño. La Gestión de la Capacidad hace énfasis sobre la planificación para garantizar que los Niveles de Servicio acordados también se puedan cumplir en el futuro. Gestión de la Disponibilidad La Gestión de la Disponibilidad es el proceso de garantizar el correcto despliegue de los recursos, métodos y técnicas, para sustentar la disponibilidad de los servicios TI acordados con el cliente. La Gestión de la Disponibilidad se encarga de temas tales como optimizar el mantenimiento, o diseñar medidas para minimizar el número de incidentes. Gestión de la Seguridad El objetivo de la Gestión de la Seguridad es proteger la infraestructura TI del uso sin automación (como el acceso sin autorización a la información). Esto se basa en los requisitos establecidos en los Acuerdos de Nivel de Servicio, en los requisitos contractuales, la legislación y la política, y un nivel básico de seguridad. Cuando se actualizó la parte de Provisión del Servicio de ITIL se decidió que no era necesario reemplazar el libro publicado sobre Gestión de la Seguridad. El libro ITIL sobre Provisión del Servicio no trata la Gestión de la Seguridad, pero hace referencia al libro sobre Gestión de la Seguridad de ITIL. Gestión de Continuidad de Servicios TI Este proceso indica la preparación y la planificación de medidas de recuperación ante desastres en los servicios TI en el caso de que se produzca una interrupción del negocio. Conocida como Planificación de Contingencias en la revisión anterior de ITIL, pone énfasis en los vínculos entre todas las medidas necesarias para salvaguardar la continuidad de la organización de clientes ante la posibilidad de un desastre (Gestión de la Continuidad del Negocio) y las medidas para prevenir tal desastre. La Gestión de Continuidad de Servicios TI es el proceso de planificación y coordinación técnica, financiera y de gestión de recursos que se necesita para garantizar la continuidad del servicio tras el desastre, según lo convenido con el cliente.

3.3.3 Soporte del Servicio El libro ITIL sobre Soporte del Servicio describe como el cliente puede tener acceso a los servicios adecuados para contribuir a su negocio. Este libro cubre los siguientes temas: • Centro de Servicios (Service Desk) • Gestión de Incidentes • Gestión de Problemas • Gestión de Configuraciones • Gestión de Cambios • Gestión de Versiones (Release Management) Centro de Servicios (Service Desk) El Centro de Servicios es el punto de contacto inicial con la organización TI para los usuarios. Previamente, los libros ITIL se referían a esta como Centro de Soporte (Help Desk). La tarea mas importante del Centro de Soporte era registrar, resolver y controlar los problemas. El Centro de Servicios puede tener un papel más amplio (por ejemplo recibir Peticiones de Cambio) y puede encargarse de actividades relacionadas con muchos procesos. Es el punto de contacto inicial con el proveedor de servicios TI.

26

Gestión de Servicios TI basado en ITIL Gestión de Incidentes Entre las contribuciones realizadas por la ITIL al campo de la Gestión de Servicios TI la diferencia entre incidentes y problemas es posiblemente una de las más conocidas, pero no siempre la más popular. Aunque esta distinción puede a veces resultar confusa, su mayor ventaja yace en que la diferencia se hace entre la rápida restitución del servicio (tarea de la Gestión de Incidentes), y la identificación y el remedio de la causa del incidente (tarea de la Gestión de Problemas). El proceso de la Gestión de Incidentes tiene como objetivo resolver el incidente y restaurar la provisión del servicio rápidamente. Los incidentes son registrados, y la calidad del registro de incidentes determina la eficacia de cierto número de procesos a los que este registro aporta información. Gestión de Problemas Si se sospecha que existe un problema dentro de la infraestructura TI, la Gestión de Problemas trata de identificar la causa raíz del mismo. Se puede sospechar que hay un problema porque se registran incidentes repetitivamente, pero está claro que el objetivo es la prevención de dichos incidentes cuando sea posible. Una vez que se identificaron las causas (errores conocidos), se decide si es necesario realizar mejoras permanentes en la infraestructura para prevenir nuevos incidentes. Esta mejora se hace emitiendo una Petición de Cambio. Nótese también que la definición ITIL de Gestión de Problemas difiere bastante de p. ej. la definición que la industria TI le diera en los Estados Unidos en el pasado. Gestión de Configuraciones La Gestión de Configuraciones se encarga de realizar los cambios de infraestructura (estandarización y verificación del estado), de identificar los elementos de configuración (inventario, vínculos respectivos, verificación y registro), de reunir y gestionar la documentación de la infraestructura TI y de proporcionar información de la Infraestructura TI a todos los otros procesos. Gestión de Cambios La Gestión de Cambios asume la tarea de implementar los cambios en la infraestructura TI de manera controlada. El objetivo del proceso es determinar los cambios necesarios, y cómo deben implementarse para que produzcan el menor efecto adverso sobre los servicios TI, y al mismo tiempo garantizar la correcta identificación de los cambios, a través de una eficaz coordinación en toda la organización. Los cambios se realizan a partir del estado de las actividades monitorizadas por la Gestión de Configuraciones, a petición de la organización del cliente, la Gestión de Problemas y muchos otros procesos. Los cambios se implementan siguiendo unos pasos específicos de definición, planificación, construcción y pruebas, aceptación, implementación y evaluación. Gestión de Versiones (Release Management) Una versión es un grupo de elementos de configuración (CIs) que son probados e introducidos juntos en el entorno en uso. El principal objetivo de la Gestión de Versiones es garantizar un correcto despliegue de versiones, incluyendo la integración, el análisis y el almacenamiento de las mismas. La Gestión de Versiones garantiza que se suministren sólo aquellas versiones que son correctas y que se hayan analizado. Este proceso se relaciona de cerca con las actividades de la Gestión de Configuraciones y de Cambios. A través de las actividades de la Gestión de Versiones se implementan de manera real los cambios.

27

Introducción a ITIL

3.3.4 Gestión de Infraestructuras TI Los procesos de Gestión de operaciones TI se desarrollarán en un nuevo libro ITIL sobre Gestión de Infraestructuras TI. Este libro cubrirá: -

Gestión del Servicio de Redes Gestión de Operaciones Gestión de Centros distribuidos Instalación y Aceptación de Ordenadores Gestión de Sistemas

La Gestión de Infraestructuras TI incluye también la Gestión del Entorno. Gestión de Servicios de Red Los procesos de la Gestión de Servicios de Red se encargan de planificar y administrar las redes de comunicaciones. Se incluyen los sistemas de telefonía y las redes LAN y WAN. El modulo ITIL de Gestión de Servicios de Red también trata las necesidades de comunicaciones a largo plazo de la organización. Describe en si cómo las mejores prácticas de ITIL se pueden aplicar al entorno de redes. Gestión de Operaciones La Gestión de Operaciones de Informática (Operación de Sistemas) trata sobre la Gestión de hardware y de los sistemas de software, que incluye los mainframe y los sistemas medios, y también los servidores, para garantizar que se brinden los Niveles de Servicios acordados. Gestión de Centros distribuidos Los procesos de Gestión de Centros distribuidos tiene a su cargo la gestión de las operaciones en organizaciones descentralizadas. El objetivo es proveer soporte del servicio TI donde se encuentre el usuario. Esto incluye específicamente llegar a acuerdos sobre las actividades de varios procesos (en especial los procesos de soporte de los servicios TI) cuando se prestan servicios TI en diferentes lugares. Es importante definir con exactitud las responsabilidades para optimizar el servicio. Aprobación e Instalación de Ordenadores La Instalación de Ordenadores y la Aprobación se ocupan básicamente de fijar las pautas de la planificación para la aceptación, la instalación y la eventual desinstalación del hardware de la infraestructura TI. Estas pautas surgen de las actividades de los procesos de la Gestión de Cambios y de la Gestión de Versiones. Gestión de Sistemas A la fecha los libros ITIL no han cubierto la Gestión de Sistemas. En el futuro, este tema será desarrollado en un nuevo libro sobre Gestión de Infraestructuras TI. Gestión del Entorno La Gestión del Entorno tiene como función gestionar el entorno de la infraestructura TI (suministro de energía, refrigeración, etc.). Una de las tareas de este proceso es instalar y mantener los equipos de climatización de los CPD y redes.

3.3.5 Gestión de Aplicaciones El libro ITIL sobre Gestión de Aplicaciones trata la relación entre la gestión y el ciclo de vida del software. Incluye temas tales como Soporte del Ciclo de Vida del Software y Análisis de un Servicio TI para Uso Operativo. Un tema muy importante en Gestión de Aplicaciones es cómo se responde eficazmente a los cambios en el negocio. En este punto, resulta de suma importancia definir los requisitos e implementar una solución que satisfaga al cliente. Soporte del Ciclo de Vida del Software El soporte del ciclo de vida del software se encarga de definir la forma en la que se dará soporte del software durante todo su ciclo de vida, consultando a los responsables del desarrollo del software.

28

Gestión de Servicios TI basado en ITIL Es muy importante la forma en la que se diseña, construye, evalúa, opera y mantiene, y eventualmente se desinstala el software en los servicios TI. En cada etapa del ciclo de vida del software se debe llegar a un acuerdo entre los que desarrollan y los que operan la infraestructura TI. La selección de los modelos del Ciclo de Vida del Software tienen un gran impacto sobre los servicios TI. Probar un Servicio TI para Uso Operacional El objetivo de Probar un Servicio TI para Uso Operacional es garantizar la correcta operación de los servicios TI nuevos o modificados antes de que entren en operación. Esto se realiza en varias etapas: prueba de sistema, prueba de instalación y prueba de aceptación del usuario, para determinar si la aplicación desarrollada funciona, si esta correctamente instalada, si tiene interfaces con el resto de la infraestructura TI, y si ofrece a los usuarios las funciones que se acordaron con el cliente.

3.3.6 Dirección y Organización Las colecciones ITIL también incluyen algunos libros sobre temas a nivel estratégico, el Conjunto de Dirección. Los libros sobre Gestión de Calidad, Organización de Servicios TI y Planificación y Control de los Servicios TI tratan de manera específica las políticas y la planificación de los servicios TI a largo plazo. Gestión de Calidad para Servicios TI La Gestión de Calidad para los Servicios TI se ocupa de establecer y mantener un sistema de calidad coherente, basado en los procesos de Gestión de Servicios TI descritos en otros libros ITIL. Este libro describe la introducción de un sistema de calidad (basado en los estándares de la norma ISO-9000) en una organización TI, y la evaluación de un sistema de gestión de calidad existente. Las actividades de la Gestión de Calidad incluyen la definición e implementación de la política de calidad, y la operativa del sistema de calidad, incluyendo las auditorias. Organización de Servicios TI La Organización de Servicios TI maneja la estructura de la organización TI. Este libro ITIL describe como se puede analizar y evaluar la organización, en particular en términos de tareas, autoridad y responsabilidad. Se proporciona un marco de trabajo para tratar los cambios de la organización, basado en la descripción de procesos en otros libros ITIL. Las actividades más importantes de este proceso son determinar y definir la estructura y el papel de la organización y la descripción de las diferentes funciones. Planificación y Control para los Servicios TI La Planificación y Control para los Servicios TI intenta proporcionar un sistema de planificación, información y control coherente para la organización TI que garantice el cumplimiento de los objetivos y los requisitos según la estrategia del negocio y la estrategia de la organización TI. Esto implica coordinar la planificación y la información de varios procesos de la Gestión de Servicios TI (por ejemplo en forma de planes anuales y de informes trimestrales).

3.3.7 Planificación e implementación Hoy en día se cuenta con mucha experiencia en el mundo entero en la planificación y la implementación de programas para optimizar la Gestión de Servicios TI. Un libro futuro de ITIL tratará sobre este tema. En esencia, el concepto de planificación e implementación de cambios en la Gestión de Servicios TI se describe en el modelo de mejora de los procesos (capítulo 2). En la practica, la situación que se ilustra en este modelo no se manifiesta en la forma en la que las organizaciones toman sus decisiones, que puede verse afectada por aspectos históricos o políticos. Por tal razón es imprescindible que los directivos se comprometan con el programa de mejoras (Gestión de Compromisos), y que entiendan la cultura de la organización. Se debe ser consciente de que ya puede haber procesos que logren las necesidades de la organización, al menos en parte. Si se ignora esto, se puede generar resistencia en las personas necesarias para alinear mejor estos procesos con las necesidades del negocio y la experiencia adquirida con la Gestión de Servicios TI. Hará falta una comisión temporal para analizar las necesidades de la organización e implementar las soluciones necesarias. En un plan de mejora esto puede ser considerado un proyecto en si mismo, o una serie de proyectos. Una de las ventajas es que la organización se topará con puntos decisivos y podrá decidir si

29

Introducción a ITIL terminar, continuar, o modificar el proyecto. En dicho contexto el libro de ITIL recomienda adoptar PRINCE2 (Proyectos En Ambientes Controlados, 2a versión) para manejar tales proyectos. Cada proyecto debe basarse en el análisis de la situación actual, la situación deseada, y el camino entre ambas. En muchos casos, las alternativas se compararan según: -

Conveniencia para la organización. Riesgos, obstáculos y problemas potenciales. Costes de transición y costes a largo plazo. Costes por continuar con el planeamiento actual.

Identificar las alternativas potenciales puede resultar un proyecto en si mismo. La experiencia nos demuestra que ITIL no es una formula mágica. No se deben esperar milagros. Se debe prestar particular atención a los llamados proyectos de implementación ITIL que esconden una agenda particular –reorganización o fusión. ITIL describe la mejor práctica para perfeccionar la Gestión de Servicios TI, no es un libro de cocina para organizaciones. En principio ITIL brinda un marco de referencia para estructuras de proceso en la organización TI y, en un nivel más bajo, una guía para la estructura de esa organización. Si un proyecto tiene como objetivo mejorar la organización como tal, es aconsejable contratar expertos en el campo. Una medición de base o un análisis de salud puede ser un buen comienzo para el proceso de mejora. Una evaluación así de la Gestión de Servicios TI puede ayudar a identificar las fortalezas y las debilidades de la organización, y a definir con claridad los objetivos del proyecto de mejora. La medición se puede repetir después de un tiempo para ver el progreso del proyecto o programa.

30

Gestión de Servicios TI basado en ITIL

Capítulo 4: Gestión de Incidentes 4.1 Introducción La Gestión de Incidentes es una tarea reactiva, p. ej. reducir o eliminar los efectos de (potenciales) alteraciones en los servicios TI, asegurando de esta manera que los usuarios puedan volver a trabajar lo más pronto posible. Por esta razón los incidentes se registran, se clasifican y se asignan a los especialistas adecuados, luego se controlan y por último se resuelven y se cierran. Dado que toda esta actividad precisa de un estrecho contacto con los usuarios, el eje del proceso de Gestión de Incidentes es la función del Centro de Servicios que sirve como la oficina de entrada a los departamentos de especialistas y abastecedores subyacentes. La Gestión de Incidentes es esencial para los otros procesos ITIL ya que proporciona una valiosa información sobre los errores de infraestructura. La Figura 4.1. Muestra un ejemplo de la Gestión de Incidentes como proceso horizontal en la organización, que gestiona de manera eficaz y controla el flujo de trabajo de los incidentes. Usuarios Super Usuarios

Centro de servicios

Gestión de aplicaciones Primera Línea De soporte

Organización Gestión de Red y Servidor o Procesamiento Central o Sistema de Telefonía Segunda Línea De soporte Proceso de Gestión de Incidentes

Abastecedores Desarrollo & Arquitectos Tercera línea De soporte

th

n Línea de Soporte

Figura 4.1 Posición de procesos de la Gestión de Incidentes en relación con las funciones de los departamentos de la organización TI

4.1.1 Terminología Incidente Utilizamos una amplia definición de la palabra "Incidente", por lo que casi todas las llamadas al Centro de Servicios pueden ser registradas y monitorizadas como incidentes. El libro ITIL sobre Soporte del Servicio define un incidente como: Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar una interrupción a, o una reducción de la calidad de ese servicio. Por eso como reconocimiento de lo que es usual, ITIL pasa a ampliar la interpretación de esta definición de 'Incidente', de modo que casi todas las llamadas al Centro de Servicios pueden ser registradas y monitoreadas como Incidentes. En este contexto, 'Incidentes' incluyen no sólo errores de hardware y software, sino también Peticiones de Servicio debido a que ambos son tramitados de una manera similar. Es decir, Gestor de Incidentes tramita sus completos ciclos de vida. Peticiones de Servicio se pueden hacer para 'servicios estándar': que han sido acordados ser facilitados bajo SLAs; son suministrados a través de procedimientos acordados que tienen apropiadas verificaciones y controles; y donde se mantienen registros, p. ej. en la CMDB.

31

Gestión de Incidentes

Ejemplos de Petición de Servicio: -

Preguntas funcionales o peticiones de información. Indagación del estado de otros incidentes. Cambio de la clave de acceso. Peticiones de lotes de trabajo, restituciones y autorizaciones de claves. Extracción de base de datos. Petición para facilitar a nuevo empleado la apropiada funcionalidad/servidos TI.

Una Petición de Servicio puede ser para un Cambio Estándar que, mientras este cubierto por un 'servicio estándar', es tramitado bajo Gestión de Incidentes y no es sometido al proceso de Petición de Cambio. Si se pide un Servicio que no es para un definido 'servicio estándar', y ese altera el estado de la infraestructura, entonces ese hace iniciar una Petición de Cambio (RFC). Una RFC no es tramitada por Gestión de Incidentes pero es tratada formalmente por Gestión de Cambios. Impacto, urgencia y prioridad Cuando se atienden muchos incidentes al mismo tiempo, se deben establecer prioridades. Estas prioridades se basan en la seriedad del error para el negocio y el usuario. El Centro de Servicios asigna la prioridad consultando al usuario y de acuerdo con las disposiciones del SLA que determina el orden en el que deben tratarse los incidentes. Cuando los incidentes se escalan a niveles superiores - segunda línea (grado dos), tercera línea (grado tres) o un nivel de soporte superior, se mantiene la prioridad o se ajusta consultando con el Centro de Servicios. Por supuesto que el usuario pensará que su incidente es el de mayor prioridad, pero las exigencias del usuario son por lo general subjetivas. Para hacer una evaluación objetiva, se deben discutir con el usuario los siguientes criterios: -

Impacto del incidente - grado de desviación sobre la operativa normal, en términos de número de usuarios o de procesos del negocio afectados. Urgencia del incidente - la demora aceptable para el usuario o el proceso del negocio.

La prioridad se determina sobre la base de la urgencia y el impacto. Para cada prioridad se define un número de personas y cierta cantidad de recursos. Para incidentes con la misma prioridad, el esfuerzo que se deba poner en cada uno determinara el orden. Por ejemplo, un incidente que réquiem poco esfuerzo se puede resolver antes que otro para el que se necesite mas esfuerzo.

Figura 4.2 Determinando el impacto, la urgencia y la prioridad

La Gestión de Incidentes tiene opciones para reducir el impacto o la urgencia, tales como cambiar el hardware o asignar otra cola de impresión. El impacto y la urgencia también pueden cambiar durante la vida de un incidente, por ejemplo cuando afecta a más usuarios o durante los periodos críticos.

32

Gestión de Servicios TI basado en ITIL Impacto y urgencia pueden combinarse en una matriz como la de la Tabla 4.1.

Tabla 4.1 Ejemplo de un sistema de codificación de una prioridad

Escalado En el caso de que no pueda resolverse un incidente en la primera línea de soporte dentro del tiempo acordado, se tendrá que acudir a un grupo de mayor experiencia o a una autoridad en la materia. Esto se conoce como escalado, que viene determinado por los tiempos de resolución y las prioridades de las que hablamos mas arriba. Distinguimos entre escalado funcional y jerárquico: -

Escalado funcional (horizontal) - el escalado funcional significa involucrar mas personal especializado o privilegios de acceso (autoridad técnica) para solucionar el incidente, pudiéndose exceder los límites del departamento. Escalado jerárquico (vertical) - jerárquico significa que se realiza un movimiento vertical (a niveles mas altos) en la organización porque la autoridad (autoridad de la organización, poderes) o recursos necesarios para resolver el incidente son insuficientes.

El Gestor de Incidentes puede planificar reservar capacidad de antemano para el escalado funcional en la línea de organización, para que no sea necesario el escalado jerárquico para resolver el incidente. Primera, segunda y subsiguientes líneas de soporte Ya se explicó antes la asignación de la ruta del incidente, o el escalado funcional. La experiencia, la urgencia y la autoridad determinan la asignación de la ruta. El Centro de Servicios es el que generalmente provee el soporte de primer nivel, los departamentos de administración el soporte de segundo nivel, los desarrolladores de software y los especialistas el de tercer nivel, y los abastecedores el de cuarto nivel. Si la organización es pequeña, no habrá tantos niveles de escalado. En organizaciones muy grandes, el Gestor de Incidentes puede nombrar Coordinadores de Incidentes en determinados departamentos para ayudarlo. Por ejemplo, los Coordinadores actúan como interfaz entre el proceso y la línea de organización. Cada uno de ellos coordina su propio grupo de soporte.

33

Gestión de Incidentes La Figura 4.3 ilustra el proceso de escalado.

Figura 4.3 Escalado de Incidente (fuente: OGC). Nota: 'Nth línea' también conocida como 'TierN'

4.2 Objetivo El objetivo de la Gestión de Incidentes es restituir el servicio, como lo define el SLA, lo más pronto que sea posible, con el menor impacto posible sobre la actividad del negocio de la organización y el usuario. La Gestión de Incidentes también debe mantener registros eficaces de los incidentes para medir y evaluar el proceso, y proporcionar información a los otros procesos.

4.2.1 Beneficios -

-

34

Para el negocio en conjunto:
Mayor resolución dentro del tiempo estipulado de los incidentes reduciendo el impacto en el negocio.
Mayor productividad para el usuario.
Monitorización de incidentes como proceso independiente, centrado en el cliente.
Disponibilidad de información de producción centrada en el SLA. Para la organización TI:
Mejora de la monitorización, permitiendo una adecuada medición del rendimiento contra el SLA.
Gestión de información útil del SLA haciendo uso de la información disponible.
Mejor y más eficaz uso del personal.
No perder o registrar de manera incorrecta los incidentes y las peticiones de servicio.
CMDB más precisa, ya que se audita mientras se registran los incidentes en relación con los elementos de configuración.
Mejora de la satisfacción del usuario y del cliente.

Gestión de Servicios TI basado en ITIL

Si no se implementa la Gestión de Incidentes nos podemos enfrentar con los siguientes efectos adversos: -

Al no tener un responsable de monitorizar y escalar los incidentes, estos se pueden volver innecesariamente severos y reducir el nivel de servicio. Los usuarios pueden ser derivados a otras autoridades sin que se les resuelva el problema. Se interrumpe continuamente a los especialistas con llamadas de usuarios que impiden que ellos realicen su trabajo. En consecuencia, mucha gente puede estar trabajando sobre el mismo incidente, perdiendo tiempo innecesariamente, y dando soluciones conflictivas. Hay falta de información administrativa sobre el dominio del usuario y los servicios. Dados todos los problemas mencionados, el cliente y la organización gastan más de lo necesario.

4.3 El proceso La Figura 4.4 muestra la entrada y la salida del proceso, y sus actividades.

Figura 4.4 Posición del proceso de Gestión de Incidentes

4.3.1 Entradas al Proceso Los incidentes se pueden producir en cualquier parte de la infraestructura y los usuarios lo informan, pero los incidentes también pueden ser detectados por otros departamentos además del Centra de Servicios. y automáticamente por sistemas de detección que se montan para capturar eventos (fallos) de la infraestructura técnica o de aplicaciones.

4.3.2 Gestión de Configuraciones La Base de Datos de la Gestión de Configuraciones (CMDB) representa un papel muy importante en la Gestión de Incidentes ya que define las relaciones entre los recursos, los servicios, los usuarios y los Niveles de Servicio. Por ejemplo, la Gestión de Configuraciones muestra quien es responsable de un componente de infraestructura, para que esos incidentes puedan ser mejor direccionados. También ayuda a decidir sobre temas operativos, como el cambio de una cola de impresión o el cambio de usuarios a otro servidor. Cuando se registra el incidente, los detalles de configuración se asocian con el registra de incidentes para brindar información mas correcta sobre el error. Si fuera necesario, se actualiza el estatus de los componentes relevantes de la Base de Información de la Gestión de Configuraciones.

35

Gestión de Incidentes

4.3.3 Gestión de Problemas La Gestión de Problemas exige algunos requisitos de calidad para registrar los incidentes de manera que resulte más fácil la identificación de cualquier error subyacente. La Gestión de Problemas asiste a la de Incidentes aportando información sobre problemas, errores conocidos, trabajos en curso y Soluciones Temporales.

4.3.4 Gestión de Cambios Se puede resolver un incidente al implementar un cambio, por ejemplo remplazando un monitor. La Gestión de Cambios da información a la Gestión de Incidentes sobre los cambios programados y sus estados. A su vez, los cambios pueden provocar incidentes por estar mal implementados o por tener errores. La Gestión de Cambios se encarga de informar de tales incidentes a la Gestión de Cambios.

4.3.5 Gestión de Niveles de Servicio La Gestión de Niveles de Servicio supervisa los acuerdos sobre el soporte a proporcionar. La Gestión de Incidentes debe conocer el Acuerdo de Nivel de Servicio (SLA) para utilizarlo cuando se comunica con los usuarios. Los registros de incidentes pueden ser utilizados para generar informes que determinen si se esta cumpliendo con el nivel de servicio acordado.

4.3.6 Gestión de la Disponibilidad Para medir aspectos relacionados con la disponibilidad de los servicios, la Gestión de la Disponibilidad utiliza los informes de incidentes y el estado de verificación que maneja la Gestión de Configuraciones. Se puede asignar a un servicio el estado de "caído", como un CI/EC en el CMDB. Esta información se debe utilizar para determinar la disponibilidad real de un servicio y el tiempo de respuesta del abastecedor. Esta capacidad requiere de acciones con marcadores de tiempo a lo largo del progreso de los incidentes, desde la detección inicial hasta el cierre.

4.3.7 Gestión de la Capacidad Cabe a la Gestión de la Capacidad lo relativo a los incidentes que se provocan por falta de espacio en el disco o por tiempo de respuesta lento, por ejemplo. Un administrador de sistemas o el sistema por si mismo pueden señalar estos incidentes en el proceso de Gestión de Incidentes. La Figura 4.5 ilustra los pasos que incluye el proceso: -

36

Admisión y registro del incidente - se admite la llamada y se crea un registro del incidente. Clasificación y soporte inicial - el incidente se codifica por tipo, estado, impacto, urgencia, prioridad, SLA, etc. Se puede sugerir al usuario una solución, aunque sea temporal. Si la llamada es por una Petición de Servicio, se inicia el proceso que corresponde. Comparación - se investiga si el incidente es conocido, y si se relaciona con un problema o error conocido, y si existe una solución o un trabajo relacionado en curso. Investigación y Diagnostico - si no hay una solución conocida, se investiga el incidente. Resolución y Recuperación - una vez que se encontró la solución, se resuelve el tema. Cierre - se pregunta al usuario si esta satisfecho con la solución y se cierra el incidente. Monitorización y seguimiento del progreso - se monitoriza el ciclo entero del incidente, y si se considera que no se puede resolver el problema a tiempo, se continúa con el escalado.

Gestión de Servicios TI basado en ITIL

Figura 4.5 Proceso de Gestión de Incidentes

4.4 Actividades 4.4.1 Admisión y registro En muchos casos será el Centro de Servicios el que registre los incidentes. Se deben registrar de inmediato los incidentes que se producen, por las siguientes razones: -

Ponerse al día con las tareas de registro atrasadas resulta bastante difícil. La progresión de un incidente sólo se puede monitorizar si esta registrado. El registro de incidentes ayuda al diagnostico de los nuevos incidentes. La Gestión de Problemas puede utilizar el registro de incidentes para descubrir las causas que los provocan. Es más fácil determinar el impacto si se han registrado todas las llamadas. Sin registro, no se podrán monitorizar los niveles de servicio conforme a lo acordado. Al registrar los incidentes de manera inmediata, se pueden evitar situaciones donde muchas personas estén siguiendo el mismo problema o donde nadie este trabajando para dar por cerrado el incidente.

37

Gestión de Incidentes El lugar donde se notifica el incidente determina quien lo informa. Los incidentes pueden notificarse de la siguiente forma: -

Por el usuario - quien informa sobre el incidente al Centro de Servicios. Por un sistema - cuando se captura un problema o un evento en la infraestructura técnica o en una aplicación, como cuando se excede un umbral crítico, el evento se introduce en el sistema de registro de incidentes como incidente y si fuera necesario se direcciona a un grupo de soporte. Por un empleado del Centro de Servicios - quien se asegura de registrar el incidente. Por una persona de otro departamento TI - quien registra el incidente en el sistema de registro de incidentes o informa de la llamada al Centro de Servicios.

Se debe evitar registrar el mismo incidente dos veces. Por tal motivo, cuando se registra un incidente se verifica si no hay incidentes similares en curso: -

Si es así (y si se relacionan con el mismo incidente), se actualiza la información o se registra el incidente por separado y se lo relaciona con el incidente principal. En caso de ser necesario se pueden corregir el impacto y la prioridad y se agrega la información del nuevo usuario. Si no es así (no resulta igual a los incidentes abiertos), se registra un nuevo incidente.

En ambos casos, el resto del proceso es igual, aunque los pasos a seguir en el primer caso son mucho más simples. Cuando se registra un incidente se emprenden las siguientes actividades: -

Asignación de un número - en la mayoría de los casos el sistema asigna automáticamente un número de incidente único que el usuario utilizara en comunicaciones es futuras. Registro de información de diagnóstico básica - hora, síntomas, usuario, persona encargada del tema, ubicación e información del servicio y/o hardware afectado. Complementar la información del incidente - con cualquier información relevante sobre el incidente {p. ej. Utilizando un script para recoger mas información) o a través de la CMDB (Generalmente en base a la relación definida en la base de datos entre elementos de configuración). Alertar - si el incidente tiene un gran impacto, como cuando falla un servidor importante, se debe alertar a los otros usuarios y departamentos de gestión.

4.4.2 Clasificación La clasificación de los incidentes tiene como meta la categorización del incidente para facilitar su monitorización y su registro. Cuanto más extensivas sean las opciones de clasificación, mejor. Sin embargo, esto también requiere un mayor nivel de compromiso por parte del personal. A veces se intenta combinar muchos aspectos de clasificación en una sola lista -tipo, grupo de soporte y origen-lo que puede resultar confuso. Es mejor utilizar muchas listas cortas. En esta sección encontraremos puntos relevantes para la clasificación. Categoría Primero, a los incidentes se les asigna una categoría y una subcategoría, por ejemplo según los posibles orígenes del incidente o el grupo de soporte pertinente: -

38

Procesamiento central - acceso, sistema, aplicación. Red - router, segmento, hub, y dirección IP. Uso y Funcionalidad - servicio, capacidad, disponibilidad, backup, manual. Organización y Procedimientos - orden, Petición, soporte, comunicaciones. Petición de Servicio - cuando el usuario solicita al Centro de Servicios soporte, entrega, información, consejo o documentación. Esto puede cubrirse como un proceso aparte o de la misma manera en la que se trata un incidente.

Gestión de Servicios TI basado en ITIL Prioridad Luego se asigna la prioridad para garantizar que los grupos de soporte prestan la atención necesaria al incidente. La prioridad es un número basado en la Urgencia ¿Con qué rapidez se debe resolver? y el Impacto ¿Cuánto daño se causará si no se soluciona rápido? Prioridad = Urgencia * Impacto. Servicio Se puede utilizar una lista para identificar el/los servicios que se relacionan con el incidente, para referirlo/s al SLA pertinente. Esta lista tendrá también los tiempos de escalado para los servicios relacionados como lo determina el SLA. Grupo de soporte Si el Centro de Servicios no puede resolver el incidente de inmediato, se asigna un grupo de soporte para que se encargue del incidente. Este direccionamiento se basa a menudo en la categoría del incidente. Cuando se definen las categorías, se debe considerar la estructura de los grupos de soporte. El correcto direccionamiento de los incidentes es esencial para la eficaz Gestión de Incidentes. Uno de los Indicadores de Clave de Rendimiento para la calidad del Proceso de Gestión de Incidentes debería ser "el número de llamadas mal direccionadas". Tiempo estimado Según la prioridad y el SLA, se informará a la persona que llama del tiempo máximo estimado para resolver el incidente (ciclo horario), y cuando volver a llamar. Estos tiempos son registrados en el sistema. Número de referencia del incidente Se da al usuario un número de incidente para referencias futuras. Posición del flujo de trabajo (estado) El estado del incidente indica su posición en el flujo de trabajo del incidente. Ejemplos de estados son: - Nuevo - Admitido - Planeado - Asignado - Activo - Suspendido - Resuelto - Cerrado

4.4.3 Comparación Después de haber sido clasificado, se investiga si hay registro de un incidente similar previamente, y si existe una solución o trabajo en curso. Si el incidente tiene los mismos síntomas que otro problema o error conocido, se lo puede relacionar.

4.4.4 Investigación y Diagnostico El Centro de Servicios o el grupo de soporte direccionan los incidentes para los que no disponen de una solución o que van más allá de la experiencia del agente a otro grupo de soporte con más experiencia o conocimiento técnico. El grupo de soporte investigará y resolverá el incidente o lo direccionará a otro grupo de soporte. Durante el proceso de resolución, distintos agentes pueden actualizar el registro del incidente con el estado actual y la información sobre las medidas tomadas, clasificación revisada, tiempo, e identificación del agente.

39

Gestión de Incidentes

4.4.5 Resolución y Recuperación Después de haber completado el análisis y de haber resuelto el incidente satisfactoriamente, el agente registra la solución en el sistema. Para algunas soluciones, se tendrá que emitir una Petición de Cambio (RFC) a la Gestión de Cambios. En el peor de los casos, si no se encuentra la solución, el incidente permanece abierto.

4.4.6 Cierre Una vez que se implemento una solución satisfactoria para el usuario, el grupo de soporte direcciona el incidente otra vez al Centro de Servicios. Se contacta a la persona que informo sobre el incidente para verificar que todo esta resuelto. Si se confirma que el incidente fue resuelto de manera correcta, se da por cerrado; pero si no es así se vuelve a comenzar desde el lugar adecuado. Durante el cierre, la categoría final, prioridad, servicio(s) afectado(s), y el componente causante (CI) también se deben actualizar.

4.47 Seguimiento de progreso y monitorización En muchos casos, el Centro de Servicios, como dueño de todos los incidentes, es responsable de la monitorización de progreso. En ese caso, el Centro de Servicios también debe informar al usuario sobre el estado del incidente. El feedback con el usuario puede resultar útil eras un cambio de estado, de ciclo horario esperado, y escalamiento. Durante el seguimiento y la monitorización puede haber un escalamiento funcional a otro grupo de soporte, o escalamiento jerárquico para forzar decisiones sobre la resolución.

4.5 Control del proceso El control del proceso se basa en los informes de los diferentes grupos designados. El Gestor de Incidente es responsable de estos informes, como así también de la confección de la lista de distribución y del calendario de informes. Los informes deben ser muy detallados y adaptados a las necesidades por las siguientes razones: -

-

-

-

40

Gestor de Incidentes - necesita el informe para:
Identificar las partes faltantes en el proceso
Identificar los conflictos con los acuerdos
Seguir el desarrollo de los procesos
Identificar las tendencias Gestión de Línea TI - informe para la gestión del grupo de soporte; tendrá que facilitar el control dentro de cada departamento. Para ello es necesario tener información sobre:
El progreso de resolución del proceso
El ciclo horario del incidente en los distintos grupos de soporte Gestión de Niveles de Servicio - este informe tendrá en primera medida información sobre la calidad de servicios brindados. El Gestor de Niveles de Servicio recibirá todos los informes necesarios para que Nivel de Servicios los informe a los clientes. Los informes a los clientes deben dar información que especifique si se han cumplido los acuerdos con respecto a Niveles de Servicio dentro del proceso de Gestión de Incidentes. Gestores de proceso de otros procesos de Gestión de Servicios - los informes para los otros gestores de otros procesos serán meramente informativos. Por ejemplo, la Gestión de Incidentes podría brindar la siguiente información basada en los informes de incidente:
Número de incidentes informados y registrados.
Número de incidentes resueltos, subdivididos por la resolución de tiempo.
Estado de los incidentes sin resolver y el número de los incidentes sin solución.
Incidentes por periodo, grupo de cliente, grupo de soporte y resolución de acuerdo con el SLA.
Incidentes por categoría y prioridad, por grupo de soporte.

Gestión de Servicios TI basado en ITIL

4.5.1 Factores críticos para el éxito Una exitosa Gestión de Incidentes necesita: -

Un CMDB actualizado que ayude a estimar el impacto y la urgencia de los incidentes. De manera alternativa, esta información se puede obtener de los usuarios, pero la información no será tan completa, puede ser muy subjetiva y llevará más tiempo. Una Base de Conocimiento, por ejemplo una base de datos actual de errores problema /conocidos que describa como reconocer los incidentes, y soluciones y workarounds disponibles. Aquí también deben incluirse la base de datos de los proveedores. Un sistema bien automatizado para registrar, seguir y monitorear los incidentes. Fuertes vínculos con la Gestión de Niveles de Servicio para garantizar adecuadas prioridades y apropiados tiempos de resolución.

4.5.2 Indicadores de Rendimiento La evaluación de procesos de rendimiento necesita de parámetros claramente definidos y objetivos mensurables, a menudo llamados Indicadores de Rendimiento. Estos se informan con regularidad, por ejemplo todas las semanas, para elaborar datos para el historial que puedan utilizarse para identificar las tendencias. Ejemplos de tales parámetros incluyen: -

Número total de incidentes. Tiempo de resolución promedio. Tiempo de resolución promedio por prioridad. Promedios resueltos dentro de los parámetros del SLA. Porcentaje de incidentes resueltos por la primera línea de soporte (sin direccionar). Coste de soporte promedio por incidente. ' Incidentes resueltos por estación de trabajo o por agente de Mesa de Servicio. Incidentes resueltos sin visitar al usuario. Número de incidentes (o porcentaje) con clasificación inicial incorrecta. Número de incidentes (o porcentaje) mal direccionados.

4.5.3 Funciones y rotes Los procesos cortan la jerarquía horizontalmente. Esto solo se logra si se hace una correcta descripción de las responsabilidades y las autoridades asociadas con la implementación. Para brindar flexibilidad puede ser útil utilizar un planteamiento basado en roles. En organizaciones mas pequeñas, o para reducir costes, los roles se pueden combinar, por ejemplo la Gestión de Cambios con la Gestión de Configuraciones. Gestor de Incidentes En muchas organizaciones se asigna el papel del Gestor de Incidentes al Gestor de Mesa de Ayuda. El Gestor de Incidentes es responsable de: -

Monitorear la eficacia y eficiencia de los procesos. Controlar el trabajo de los grupos de soporte. Hacer recomendaciones para mejorar. Desarrollar y mantener el sistema de Gestión de Incidentes.

Personal del grupo de soporte - La primera línea de soporte es responsable del registro, clasificación, comparación, direccionamiento, resolución y cierre de los incidentes. - Los otros grupos de soporte se encargan principalmente de la investigación, diagnóstico y recuperación, todo dentro del set de prioridades.

41

Gestión de Incidentes

4.6 Costes y problemas 4.6.1 Costes Los costes asociados con la Gestión de Incidentes incluyen la implementación inicial de costes, tales como la definición de los procesos, capacitación e instrucción del personal, y la selección y compra de las herramientas para dar soporte al sistema. La selección de las herramientas puede tomar tiempo. Además hay costes de funcionamiento asociados con el personal y el uso de las herramientas. Estos costes dependen mucho de la estructura de la Gestión de Incidentes, la escala de actividades, responsabilidades, y la cantidad de lugares.

4.6.2 Problemas La introducción e implementación de la Gestión de Incidentes puede verse afectada por los siguientes problemas: -

-

-

42

Usuarios y personal de TI omiten los procedimientos de la Gestión de Incidentes - si los usuarios resuelven los problemas por si mismos, o se contactan directamente con personal especializado, sin tener en cuenta los procedimientos, la organización TI no tendrá información sobre el nivel de servicio y la cantidad de errores. De igual manera, los informes de la gestión no harán una clara descripción de la situación. Sobrecarga y acumulación de incidentes - si de repente hay gran cantidad de incidentes, el tiempo no será suficiente y los incidentes no serán bien registrados. Esto se produce cuando antes de ingresar la información se debe atender al próximo usuario. No se describe con precisión el incidente y los procedimientos para ubicar y derivar los incidentes no se siguen como corresponde. En consecuencia, la resolución se vuelve ineficaz y la carga de trabajo se incrementa aún más. Si el número de incidentes aumenta demasiado, un procedimiento para emplear capacidad de reserva puede prevenir la sobrecarga. Escalado - en la Gestión de Incidentes, los incidentes que no se pueden resolver rápidamente pueden escalar. Demasiados escalados pueden tener un efecto adverso en los especialistas que son distraídos de sus trabajos regulares. Falta de un Catálogo de Servicios y de Acuerdos de Nivel de Servicio - si no se encuentran claramente definidos los servicios y los productos a los que se da soporte, será difícil para la Gestión de Incidentes negarse a ayudar a los usuarios. Falta de compromiso - solucionar los incidentes utilizando un planteamiento basado en el proceso requiere por lo general cambios en la cultura y un mayor nivel de compromiso de los empleados. Esto puede generar alta resistencia dentro de la organización. Una Gestión de Incidentes precisa de un verdadero compromiso por parte del personal.

Gestión de Servicios TI basado en ITIL

Capítulo 5: Gestión de Problemas 5.1 Introducción Como leyera en el capítulo anterior, la Gestión de Incidentes actúa cuando hay un incidente, y finaliza cuando la situación ha sido recuperada. Esto significa que la causa de raíz del incidente no siempre está al descubierto y que el incidente se puede repetir. La Gestión de Problemas investiga la infraestructura y los registros disponibles, incluyendo la Base de Datos de Incidentes, para identificar las causas reales y los errores potenciales en la provisión de los servicios. Estas investigaciones son necesarias porque la infraestructura es compleja y distribuida, y los nexos entre los incidentes puede que no resulten tan obvios. Por ejemplo, muchos errores pueden encontrarse en la base del problema, mientras que las definiciones de gran cantidad de problemas pueden estar asociadas con el mismo error. Primero se debe identificar la causa. Una vez que identificada la causa principal y documentada una solución temporal, el problema se transforma en un error conocido. Se puede emitir Petición de Cambio (RFC) para eliminar la causa. Aun después de esto, la Gestión de Problemas continúa con el seguimiento y la monitorización de los errores conocidos en la infraestructura. Por tal razón, se registra la información sobre los errores conocidos, sus síntomas y las soluciones disponibles.

5.1.1 Definiciones de "problema" y "error conocido" La figura 5.1 muestra la relación entre un problema, un error conocido y RFC, y define estos términos.

Figura 5.1 Relación entre problemas y errores conocidos (Fuente: OGC)

5.1.2 Relación con la Gestión de Incidentes La Gestión de Problemas brinda soporte a la de Incidentes suministrando soluciones temporales (workarounds) y reparaciones rápidas (quick fixes), pero no es responsable de solucionar el incidente. La Gestión de Incidentes apunta a la rápida solución del error, de cualquier manera, incluyendo una solución temporal, mientras que la Gestión de Problemas se toma el tiempo para investigar, identificar la causa raíz y eliminarla. Un incidente jamás debe "transformarse" en un problema.

43

Gestión de Problemas Sin embargo, se puede definir un problema relacionado además del incidente. Así, al investigar un problema se puede llegar a la solución de un incidente actual que todavía esta sin resolver. La Figura 5.2 muestra la relación entre incidentes, problemas, errores conocidos y cambios.

Figura 5.2 Relaciones entre Gestión de Incidentes, Gestión de Problemas y Gestión de Cambios.

5.2 Objetivo El objetivo de la Gestión de Problemas es descubrir la causa principal de los problemas previniendo así los incidentes. La Gestión de Problemas realiza actividades proactivas y reactivas. La Gestión de Problemas reactiva tiende a identificar la causa principal de los incidentes pasados y ofrecen propuestas para mejorar o rectificar. La Gestión proactiva tiene como objetivo prevenir los incidentes identificando las debilidades en la infraestructura y proponiendo métodos para eliminarlos. La Gestión de Problemas garantiza que: -

Se identifiquen, documenten, y rastreen los errores a largo plazo. Se documenten los síntomas y las soluciones permanentes o temporales de los errores. Se realicen las Peticiones de Cambio pertinentes para modificar la infraestructura. Se prevengan los nuevos incidentes. Se elaboren los informes sobre la calidad de la infraestructura y los procesos.

La Gestión de Problemas puede mejorar con rapidez la calidad del servicio reduciendo significativamente el número de incidentes y la carga de trabajo en la organización TI. Algunas de las ventajas son: -

44

Mejor calidad de servicio TI y gestión - ya que se documentan y/o eliminan los errores. Aumento de la productividad del usuario - por la mejora en la calidad del servicio. Aumento de la productividad del personal - dado que se documentan las soluciones, hasta el agente de Gestión de Incidentes más inexperto puede resolver los incidentes con mayor velocidad y eficacia. Mejora de la reputación del servicio TI - dado que aumenta la estabilidad de los servicios, es probable que los clientes encarguen más servicios a la organización TI.

Gestión de Servicios TI basado en ITIL -

-

Aumento de conocimiento y aprendizaje operativo y administrativo - la Gestión de Problemas almacena información en el historial que puede utilizarse para identificar tendencias, y que puede servir para tomar medidas que prevengan nuevos incidentes. La información del historial también es útil para investigar y diagnosticar y al elaborar RFCs. Mejora en el registro de incidente - la Gestión de Problemas introduce estándares para registrar y clasificar los incidentes identificando los problemas y sus síntomas de manera eficaz. Esto también mejora el registro de los incidentes. Tasas más altas de resolución en primera línea de soporte - el soporte de primera línea tendra más posibilidades de resolver los incidentes porque la Gestión de Problemas brinda soluciones a los incidentes y a los problemas, y soluciones temporales disponibles en una base de conocimientos.

5.3 El proceso

Las entradas de la Gestión de Problemas son: -

Registros de Incidentes. Soluciones temporales definidas por la Gestión de Incidentes. Detalles de configuración de la Base de Datos de la Gestión de Configuraciones (CMDB). Detalles de los abastecedores sobre los productos que se utilizan en la infraestructura, incluyendo los detalles técnicos y errores conocidos de esos productos). Detalles sobre la infraestructura y su comportamiento, como registros de capacidad, mediciones de rendimiento, informes de Nivel de Servicio, etc.

Las principales actividades de la Gestión de Problemas: -

Control de Problemas - definir e investigar los problemas. Control de Errores - seguir los errores conocidos y elevar RFCs. Gestión de Problemas Proactiva - prevención de incidentes mediante la mejora de la infraestructura. Suministro de información - informar sobre los resultados y los problemas más importantes.

La información de salida incluye: -

Errores conocidos. Peticiones de Cambio (RFCs). Informes actualizados de los problemas (actualizados con la información sobre las soluciones y/o soluciones temporales (workarounds) ). Cierre del registro de problema una vez que se eliminó la causa raíz. Información de gestión (informes y estadísticas).

Figura 5.3 Posición del proceso de la Gestión de Problemas

45

Gestión de Problemas Podemos asociar los siguientes procesos a la Gestión de Problemas:

5.3.1 Gestión de Incidentes La Gestión de Incidentes es un socio muy importante de la Gestión de Problemas. Disponer de informes de incidentes eficaces resulta esencial para el éxito de la Gestión de Problemas, ya que esa información se utiliza para identificar los problemas. Por otra parte, la Gestión de Problemas da soporte a la Gestión de Incidentes. La Gestión de Problemas estudia el problema, y –hasta que se encuentra la solución para el mismo– puede documentar una solución temporal (que se encuentra al estudiar un problema) para tratar el incidente. Una vez identificada la causa y definido un error conocido, se puede proponer una Reparación Rápida que prevenga otros inconvenientes por el momento, o que reduzca el daño causado por un incidente. Si es posible, la Gestión de Problemas registrará una RFC que permita llegar a una solución definitiva. Nota: tanto la Gestión de Incidentes como la de Problemas pueden aplicar soluciones temporales

5.3.2 Gestión de Cambios La Gestión de Cambios es responsable de controlar la implementación de los cambios, incluso de las RFCs propuestas por la Gestión de Problemas para eliminar problemas. Esta gestión tiene a su cargo el análisis del impacto y los recursos necesarios, planificación, coordinación y evaluación de los cambios solicitados, como así también de informar a la Gestión de Problemas sobre el progreso y el cumplimiento de los cambios correctivos. Dichos cambios son evaluados en común con la Gestión de Problemas. Ello da como resultado la Revisión Post Implementación (PIR), tras la que errores proceso de Control de Errores puede cerrar los errores conocidos, y los registros de incidente pertinentes.

5.3.3 Gestión de Configuraciones La Gestión de Configuraciones brinda información fundamental sobre los elementos de la infraestructura, configuraciones de hardware y software, servicios, y otras relaciones tales como "esta conectado con", "usuarios", y "forma parte de". Estas relaciones son de vital interés para las investigaciones de la Gestión de Problemas.

5.3.4 Gestión de la Disponibilidad La Gestión de la Disponibilidad tiende a planear y hacer realidad los niveles de disponibilidad convenidos, y aporta información a la Gestión de Problemas. La Gestión de Problemas ayuda a la de Disponibilidad identificando las causas de falta de acceso y remediándolas. La Gestión de la Disponibilidad dirige el diseño y la arquitectura de la infraestructura y se encarga de prevenir los problemas e incidentes optimizando la planificación de la disponibilidad y la monitorización.

5.3.5 Gestión de la Capacidad La Gestión de la Capacidad optimiza el uso de los recursos TI y suministra a la Gestión de Problemas información esencial, necesaria para definir los problemas. La Gestión de Problemas ayuda a la de Capacidad identificando las causas de los problemas relacionados con capacidad y proponiendo los cambios necesarios para rectificarlos.

5.3.6 Gestión de Niveles de Servicio La Gestión de Niveles de Servicio abarca la negociación y la concreción de los acuerdos sobre la calidad de los servicios TI y la provisión de los mismos. La Gestión de Niveles de Servicio da información a la de Problemas que se utiliza para definir los problemas. Los procedimientos de la Gestión de Problemas deben contribuir con los estándares de calidad acordados. La Gestión de Problemas asiste también a la Gestión Financiera y a la de Continuidad de Servicios TI.

46

Gestión de Servicios TI basado en ITIL

5.4 Actividades 5.4.1 Control de Problemas Con esta actividad se espera identificar los problemas e investigar sus causas. Lo imperativo para Control de Problemas es avanzar con el problema para que se convierta en un error conocido al diagnosticar la causa principal del mismo. Las actividades de Control de Problemas se pueden observar en la Figura 5.4

Figura 5.4 Control de Problemas (fuente: OGC)

Identificación y registro del Problema En principio, cualquier incidente de causa desconocida debe asociarse con un problema. Sin embargo, esto por lo general sólo valdrá la pena si el incidente se produce frecuentemente o si se espera que se repita, o si hay un único incidente grave. La actividad de "identificar problemas" se encarga a los Coordinadores de Problemas. No obstante, personal que no esta involucrado en forma directa con la identificación del problema, como el personal de Gestión de la Capacidad puede identificar uno. Sus hallazgos también deben ser registrados como problemas. Esta tarea de identificación de problemas es quizás una de las más difíciles de todo el proceso de Gestión de Problemas, ya que es necesario utilizar todas las fuentes disponibles para inferir la existencia de un problema. La principal fuente de información será la Base de Datos de registros de Incidentes y para llevar a cabo esta actividad será de vital importancia que el personal que gestiona incidentes realice una correcta clasificación de los incidentes y sobre todo documente correctamente el tipo de cierre que se ha dado al incidente. Todos aquellos incidentes que se han cerrado aplicando una solución temporal o de los que no se ha concluido una causa raíz clara son susceptibles de ser analizados por los Coordinadores de Problemas para su registro. Los detalles del problema son similares a los del incidente, pero en este caso no es necesario incluir información sobre el usuario, etc. Sin embargo, se deben identificar los incidentes relacionados con el problema. Ejemplos de instancias cuando se identifican problemas: -

El análisis de los detalles de los incidentes indican que un incidente se repite, y provoca un volumen o tendencia significativa. El análisis de la infraestructura identifica las áreas débiles donde se podrían originar nuevos incidentes (también analizados por la Gestión de la Disponibilidad y de Capacidad). Cuando se produce un incidente serio que requiere de una solución permanente, para evitar que se repita en el futuro. Los Niveles de Servicio están amenazados (capacidad, rendimiento, costes, etc.). Los nuevos incidentes no pueden relacionarse con problemas existentes o errores conocidos. Los incidentes registrados no pueden relacionarse con un problema existente o con un error conocido.

47

Gestión de Problemas

El análisis de tendencias puede descubrir áreas que necesitan mayor atención. Los esfuerzos adicionales se pueden expresar en términos de coste y beneficio para la organización. Por ejemplo, al identificar las áreas que necesitan más soporte y determinan cuán relevantes son para los servicios que brindan. Esta evaluación puede basarse en el "factor dolor" de los incidentes, que toma en cuenta lo siguiente: -

Coste de los incidentes para las actividades del negocio. Número de incidentes. Número de usuarios y de procesos del negocio afectados. Tiempo y coste necesarios para resolver los incidentes.

Clasificación y distribución Los problemas se pueden clasificar por área (categoría). La identificación señala al nivel mas bajo de CIs que afecta el problema. La clasificación debe acompañarse de un análisis de impacto, que no es más que la seriedad del problema y su efecto sobre los servicios (urgencia e impacto). Luego se asigna una prioridad, de la misma manera que se hace con el proceso de Gestión de Incidentes. Con base en esa clasificación se asignan el personal y los recursos, y se dispone del tiempo necesario para resolver el problema. La clasificación incluye: • Categoría - identificar el dominio pertinente, por ejemplo el hardware o software. • Impacto - sobre el proceso del negocio. • Urgencia - grado hasta el que es posible postergar la solución. • Prioridad - combinación de urgencia, impacto, riesgo y recursos necesarios. • Estado - problema, error conocido, resuelto. La clasificación no es estática, por lo que puede cambiar durante el ciclo de vida de un problema. Por ejemplo, la disponibilidad de una solución temporal o de una reparación rápida puede reducir la urgencia de un problema, mientras los nuevos incidentes pueden aumentar el impacto de un problema. Investigación y diagnostico La investigación y el diagnóstico son una fase reiterativa –se repite muchas veces–, acercándose cada vez más al resultado esperado. A menudo, se intenta reproducir el incidente en un entorno de prueba. Puede ser necesario contar con mas expertos, p. ej. Especialistas de un grupo de soporte para asistir con el análisis y el diagnóstico del problema. Los problemas no sólo son provocados por el hardware y el software. Pueden ser causa de un error en la documentación, un error humano o de procedimiento, como la descarga de una versión de software errónea. Por tal razón puede ser útil incluir los procedimientos y la documentación en la CMDB y subordinarlos al proceso de Gestión de Versiones. Gran cantidad de errores pueden deberse a los componentes de la infraestructura. Una vez que se conoce la causa del problema, que se han identificado el CI o la combinación de los CIs, se puede establecer un nexo entre el CI y el/los incidente(s) para luego definir un error conocido. Paso seguido, la Gestión de Problemas continúa con las actividades de Control de Errores. Fuentes de error en otros entornos En muchos casos, los errores sólo se pueden identificar en el entorno de producción. Sin embargo, los productos del entorno de desarrollo (proveedores externos o desarrolladores internos) pueden en realidad contener errores conocidos ("bugs"). Nota: Para una organización de desarrollo el entorno de desarrollo de software es su entorno de producción.

48

Gestión de Servicios TI basado en ITIL Por lo general, el entorno de desarrollo y los abastecedores debe especificar los errores que contiene la versión especificada. Las revistas de informática traen a menudo información sobre los bugs/problemas de los productos populares. Algunos fabricantes ofrecen base de datos de conocimiento de sus productos que contienen los errores conocidos para esos productos. Si el error conocido en el producto suministrado no es demasiado serio, o si existe un imperativo del negocio para avanzar con la descarga a pesar de la falla, se puede decidir usar el ítem desarrollado en el entorno de producción, siendo imprescindible que los errores conocidos se incluyan en el Control de Errores. Se da un enlace a la Gestión de Incidentes para garantizar que los incidentes que resulten de la implementación puedan ser reorganizados rápidamente. Si fuera necesario, también se puede proporcionar una solución temporal o reparación rápida. Antes de empezar con la implementación, la Gestión de Cambios deberá decidir si estos errores conocidos son aceptables al realizar el análisis de Riesgo e Impacto. Tal decisión se toma a menudo bajo presión porque los usuarios se encuentran esperando las nuevas funciones y no suelen ser conscientes del impacto que puede provocar la existencia de estos errores conocidos.

5.4.2 Control de Errores El Control de Errores comprende la monitorización y la rectificación de los errores conocidos hasta que son resueltos con éxito, si es posible y apropiado. Control de Errores logra este objetivo elevando Peticiones de Cambio a la Gestión de Cambios, y evaluando los cambios en una Revisión Post Implementación (PIR). Control de Errores realiza el seguimiento de todos los errores conocidos desde su identificación hasta su resolución. El Control de Errores puede abarcar varios departamentos y comprende los entornos de producción y desarrollo.

Figura 5.5 Control de Errores (fuente: OGC)

Identificación de errores y registro Una vez que se establece la causa del problema y se conoce el CI pertinente, se asigna el estado de "error conocido" y comienza el proceso de Control de Errores. En muchos casos también se conocerá una solución temporal para el problema, aún si este se origino en el área de desarrollo. A pesar de esto, muchas veces todavía será necesario encontrar esta Solución Temporal. Si todavía hay incidentes abiertos serán comunicados a la Gestión de Incidentes. Así, la solución temporal podrá utilizarse en la resolución de los incidentes relacionados con el problema.

49

Gestión de Problemas Investigando una solución El personal involucrado en la Gestión de Problemas evalúa lo necesario para resolver el error conocido. Comparan distintas soluciones, considerando los Acuerdos de Nivel de Servicio, costes y beneficios. Determinan el impacto y la urgencia de la RFC. Todas las actividades de solución de ser registradas y deben existir los medios para realizar el seguimiento de los problemas (con estatus de error conocido) y determinar su estado. Reparación de emergencia Durante el proceso, puede ser necesario aprobar una reparación de emergencia si el error conocido esta provocando incidentes graves. Si la reparación de emergencia necesita de una modificación, se deberá emitir primero una RFC. Si el tema es muy serio y la demora resulta inaceptable, se tendrá que seguir el procedimiento de RFC urgente. Definición de la solución seleccionada La solución óptima se determinó en el paso previo. Sin embargo, puede optarse por no arreglar el error conocido, p. ej. porque no existe la justificación del negocio para hacer tal cosa. Por ejemplo, una empresa que tiene problemas con su sistema ERP desarrollado en la misma empresa puede haber dado una moratoria a todos los códigos de reparación del problema existente, porque la empresa ha tomado la decisión estratégica de cambiar a SAP a fin de año. Como en éste, y otros casos similares, el coste de implementar la corrección del problema puede no redundar en beneficios equivalentes. En otros casos, el impacto es aceptable, el incidente puede remediarse fácilmente aplicando una solución temporal o su repetición resulta poco probable. En otras ocasiones, será necesario un esfuerzo desproporcionado para remediar el error conocido. Cualquiera sea la decisión, se debe registrar el error conocido para que la Gestión de Incidentes pueda usarlo y se deben documentar las decisiones tomadas, normalmente en la RFC relacionada. Una vez que se eligió la solución, habrá información suficiente para elevar una RFC. Luego, la Gestión de Cambios implementa la corrección del error conocido. Revisión Post Implementación (PIR) Antes de cerrar el problema se debe revisar el cambio con el que se propone eliminar el error conocido en una Revisión Post Implementación (PIR). Si el cambio logró el objetivo se puede cerrar el problema. En la Base de Datos de Problemas, se cambia el estatus al de "resuelto". Se informa a la Gestión de Incidentes para que todo incidente relacionado también sea cerrado si precede. Nota: Muchas organizaciones implementan el proceso para que sólo se cierre el problema si los incidentes asociados han sido cerrados (y así verificar con el cliente el cierre) sino, el problema se tendrá que reabrir si no se pueden cerrar los incidentes asociados. Seguimiento y monitorización Esta actividad monitoriza el progreso de los problemas y los errores conocidos durante todas las etapas del proceso de Control de Problemas y Control de Errores. Los objetivos son: -

Determinar si la seriedad o la urgencia del problema varía, creando por lo tanto la necesidad de ajustar la prioridad asignada. Monitorizar el progreso de identificación e implementación de la solución, y monitorizar si la RFC se implementó de manera correcta. Por tal razón la Gestión de Cambios informa regularmente a Control de Errores sobre el progreso de las RFCs que ha recibido.

Aportar información Durante el proceso, se da información a la Gestión de Incidentes sobre las soluciones temporales y las reparaciones rápidas generadas. También es posible informar a los usuarios. Aunque la Gestión de Problemas proporciona información, será el Centro de Servicios quien la distribuya. La Gestión de Problemas utiliza la CMDB para decidir que información se debe dar y a quien. El SLA también puede aportar información sobre lo que se debe comunicar y a quien.

50

Gestión de Servicios TI basado en ITIL

5.4.3 Gestión de Problemas Proactiva Por lo general, la Gestión de Problemas Proactiva tiene a su cargo la calidad de la infraestructura. La Gestión de Problemas Proactiva (es decir la prevención de problemas) se concentra en el análisis de tendencia y la identificación potencial de incidentes antes de que ocurran. Esto se realiza mirando los componentes que son débiles o que están sobrecargados. Si hay muchos dominios, se harán intentos para prevenir que los errores que se producen en un dominio se repitan en otros. Se pueden descubrir e investigar las debilidades de los componentes de infraestructura.

5.5 Control del proceso 5.5.1 Informes de Gestión e Indicadores de Rendimiento El éxito de la Gestión de Problemas se demuestra a través de: -

La reducción de la cantidad de incidentes, resolviendo problemas. La reducción del tiempo necesario para resolver los problemas. Disminución de otros costes asociados con la resolución.

Los parámetros del proceso también pueden ser informados a fines de gestión interna, para evaluar y controlar la eficacia de la Gestión de Problemas. Los informes de la Gestión de Problemas pueden ser extensivos y cubrir los siguientes temas: -

Informe de tiempo - dividido en Control de Problemas, Control de Errores y Gestión de Problemas Proactiva y por grupo de soporte y abastecedor. Calidad del producto - los detalles del incidente, problema y error conocido pueden utilizarse para identificar los productos afectados por los errores frecuentes, y para determinar si los abastecedores pueden tener obligaciones contractuales asociadas. Eficacia de la Gestión de Problemas - detalles sobre la cantidad de incidentes, antes y después de resolver un problema, problemas registrados, cantidad de RFCs elevados, y errores conocidos resueltos. Relación entre la Gestión de Problemas reactiva y proactiva - aumentar la intervención proactiva en vez de reaccionar ante los incidentes muestra un incremento en la madurez del proceso. Calidad de los productos en desarrollo - los productos entregados por el entorno de desarrollo deben ser de alta calidad; de otra manera pueden provocar nuevos problemas. Los informes sobre los nuevos productos y sus errores conocidos son relevantes para la monitorización de la calidad de los productos. Estatus y Planes de Acción para problemas abiertos - resumen de lo que se ha hecho hasta el momento, y que se hará a futuro para progresar con los problemas más importantes, incluyendo las RFCs planeadas y el tiempo y los recursos necesarios. Propuestas para mejorar la Gestión de Problemas - si la información sobre los factores anteriormente mencionados no cumple con los objetivos del Plan de Calidad de Servicio, se puede proponer el registro, la información, las actividades proactivas, y los recursos adicionales necesarios.

Se pueden auditar los procesos habitualmente para planificar y mejorar los procesos. Los informes dependen del alcance de la Gestión de Problemas. Si el alcance se extiende a los productos en desarrollo, la Gestión de Problemas puede definir y monitorizar los errores conocidos aún mientras el software este en desarrollo.

5.5.2 Factores críticos de éxito El éxito de la implementación de la Gestión de Problemas depende de: -

Eficacia en el registro automatizado de incidentes y del registro del comportamiento de la infraestructura. Objetivos viables y hacer el mejor uso posible de la experiencia del personal, por ejemplo acordando sobre su disponibilidad a determinados horarios y reservando tiempo para investigar las causas principales de los problemas.

51

Gestión de Problemas -

Es imprescindible contar con una cooperación eficaz entre la Gestión de Incidentes y la de Problemas. Al asignar las tareas y las actividades se debe estar al tanto del conflicto entre la Gestión de Incidentes y la identificación de las causas de la Gestión de Problemas.

5.5.3 Funciones y roles Los procesos atraviesan las funciones o los departamentos de la organización y su jerarquía. Para lograr procesos eficaces se debe definir con claridad las responsabilidades y la autoridad asociadas con su implementación. Para brindar flexibilidad, puede resultar útil adoptar un modelo basado en los roles. En pequeñas organizaciones, o por razones financieras, los roles pueden estar combinados; por ejemplo la Gestión de Problemas y la de Nivel de Servicio. La última viñeta en el punto 5.5.2 explica por qué muchas organizaciones evitan la combinación del Centro de Servicios / Gestor de Incidentes y Gestor de Problemas. Gestor de Problemas El Gestor de Problemas es responsable de todas las actividades de la Gestión de Problemas tales como: -

Desarrollo y mantenimiento de Control de Problemas y Control de Errores. Evaluación de la eficiencia y la eficacia de Control de Problemas y Control de Errores. Ofrecer información administrativa. Gestionar el personal de la Gestión de Problemas. Obtener los recursos para las actividades. Desarrollar y mejorar los sistemas de Control de Problemas y Control de Errores. Analizar y evaluar la eficacia de la Gestión de Problemas Proactiva.

Roles de Tratamiento de Problemas Las responsabilidades del personal con roles de tratamiento de problemas incluyen: -

Responsabilidades reactivas:
Identificar y registrar los problemas analizando los detalles de los incidentes.
Investigar los problemas basándose en su prioridad.
Elevar RFCs.
Realizar el seguimiento del progreso de la resolución de los errores conocidos.
Aconsejar a la Gestión de Incidentes sobre la existencia de soluciones temporales y de reparaciones rápidas.

-

Responsabilidades proactivas:
Identificar tendencias,
Elevar RFC.
Prevenir que los problemas no se extiendan a otros sistemas.

52

Gestión de Servicios TI basado en ITIL

5.6 Costes y problemas 5.6.1 Costes Además de los costes por soporte y de las herramientas de diagnóstico, debemos considerar los costes de personal. En el pasado, no era común dejar tiempo para estas actividades. Aparte del personal TI interno involucrado en la Gestión de Problemas, debe considerarse el coste de contratar expertos adicionales de abastecedores externos. Sin embargo, los beneficios de estas actividades pueden fácilmente ser más valiosos que los costes incurridos.

5.6.2 Problemas Si es posible se tienen que evitar los siguientes puntos al implementar la Gestión de Problemas: -

-

-

Mala conexión entre la Gestión de Incidentes y la de Problemas - si existe una mala conexión entre los detalles de los incidentes y el problema y los detalles del error conocido, la Gestión de Incidentes no estará al tanto de las soluciones temporales de los problemas, y le será difícil a la Gestión de Problemas evaluar y seguir los problemas. Habrá menos información sobre el historial y menos experiencia documentada sobre la infraestructura TI. El éxito de la Gestión de Problemas depende fuertemente de la creación de este vínculo. Mala comunicación de los errores conocidos del área de desarrollo a la de producción – el software y la infraestructura técnica que se transfieren del entorno de producción deben venir acompañados de detalles al respecto de cualquier error conocido. Transmitir el conocimiento de los errores conocidos en el momento en que se descargan los sistemas evita que la organización desperdicie tiempo investigando errores que ya son conocidos. Por eso, debe haber un intercambio de información eficaz tanto entre los sistemas de almacenamiento como en los de registro, o debe haber un sistema unificado. Falta de compromiso - si el planteamiento previo era informal, puede haber resistencia a un planteamiento estricto de la Gestión de Problemas, en particular en cuanto a la documentación y al mantenimiento de los registros de historial. Por esa razón, el personal involucrado en las actividades de Gestión de Problemas deben contar con información correcta y eficaz de los progresos en la implementación de los procesos.

53

Gestión de Problemas

54

Gestión de Servicios TI basado en ITIL

Capítulo 6: Gestión de Configuraciones 6.1 Introducción Cada organización TI tiene información sobre su infraestructura TI. Tal información por lo general se encontrará disponible tras proyectos importantes que se siguen de una auditoría y de un Análisis de Impacto Sin embargo, lo más importante es mantener esta información actualizada. La Gestión de Configuraciones se encarga de suministrar detalles fiables y actualizados sobre la infraestructura TI. Es por demás importante ya que esta información no sólo incluye detalles sobre elementos específicos de la infraestructura (Elementos de Configuración, o CIs), sino sobre cómo estos CIs se relacionan unos con otros. Estas relaciones son la base del análisis de impacto y tendrán una importancia vital para la Gestión de Cambios. La Gestión de Configuraciones comprueba si los cambios en la infraestructura TI han sido correctamente registrados, incluyendo la relación entre CIs, y monitoriza el estado de los componentes para garantizar una correcta percepción de las versiones de los Elementos de Configuración (CIs) en vigor. Si la Gestión de Configuraciones está bien implementada, puede proporcionar información sobre los siguientes temas: • Información financiera y política de producto - ¿Qué componentes TI están en uso, cuantos de cada modelo (versión), y por cuanto tiempo los hemos tenido? - ¿Cuáles son las tendencias en los diferentes grupos de productos? - ¿Cuál es el valor actual, depreciado de los componentes TI? - ¿Qué componentes TI se pueden eliminar y cuales necesitan actualizarse? - ¿Cuánto costará reemplazar ciertos componentes TI? - ¿Qué licencias tenemos, son correctas? - ¿Qué contratos de mantenimiento deben ser revisados? - ¿Hasta qué punto está estandarizada nuestra infraestructura? • Corrección de la información y evaluación de impacto - ¿Qué componentes TI necesitaremos para un procedimiento de recuperación ante un desastre? - ¿EI plan de recuperación para desastre seguirá siendo eficaz si se cambian las configuraciones? - ¿Qué componentes TI se ven afectados por el rollout? - ¿A que red esta conectado el equipo? - ¿Qué módulos de software están incluidos en cada suite? - ¿Qué componentes TI se ven afectados por el cambio? - ¿Qué RFCs están en consideración para componentes TI específicos, y que incidentes y problemas han tenido lugar en el pasado y vienen al caso en la actualidad? - ¿Qué componentes TI son responsables de los errores conocidos? - ¿Qué componentes TI han sido adquiridos durante un periodo de un abastecedor en particular? • Provisión de los servicios y fijación de precio - ¿Cuáles son las configuraciones de componentes TI esenciales para ciertos servicios? - ¿Qué componentes TI se utilizan en un lugar y quienes lo usan? - ¿Cuáles son los componentes TI estándar que pueden ordenar los usuarios y a cuales damos soporte (catalogo de producto)?

55

Gestión de Configuraciones

6.1.1 Conceptos básicos En la terminología de la Gestión de Configuraciones los componentes TI y los servicios brindados con ellos se conocen como Elementos de Configuración (CIs). Cada componente TI del que se tiene registro de existencia y versión es un CI. Como se muestra en la Figura 6.1, los CIs pueden incluir hardware, todo tipo de software, componentes de red activos y pasivos, servidores, procesadores centrales, documentación, procedimientos, servicios y codos los otros componentes TI que deban ser controlados por la organización TI. Si la Gestión de Configuraciones se aplica más a los Sistemas de Información que a las Tecnologías de la Información, la CMDB también se puede usar para guardar y controlar los detalles de los usuarios TI, del staff TI y de las unidades del negocio. Esos CIs también deberán estar a disposición de la Gestión de Cambios, por ejemplo en los procesos de presentación del personal y de despedida.

Figura 6.1 Elementos de Configuración

Todos los CIs están incluidos en la Base de Datos de la Gestión de Configuraciones (CMDB). La CMDB sigue el rastro de los componentes TI y la relación entre ellos. En su forma más básica, una CMDB puede consistir en formularios de papel o un conjunto de hojas de cálculo. Los departamentos de desarrollo utilizan a menudo algo similar al CMDB para el control de versiones de todos los módulos de programas. Este tipo de control de versiones se suele encontrar incluido en las plataformas de desarrollo. Una CMDB puede consistir de varias bases de datos físicas que forman una entidad lógica, en cuyo caso. Es aconsejable optimizar la integración entre las diferentes bases de datos. La CMDB no debe ser confundida con las bases de datos de los programas de administración de stock o con las herramientas de auditoria. Los programas de administración de stock sólo brindan información limitada sobre el hardware y el software activo, los componentes de la red y del entorno. Sin embargo, la CMDB también muestra cómo debería ser la infraestructura si todo fuera hecho como se planea (ver también Gestión de Cambios), intuyendo la documentación. La información de la CMDB es de hecho una administración de la configuración autorizada de la infraestructura. Una lista con las diferencias (deltas) entre la base de datos de la gestión de recursos y la CMDB puede aportar información muy valiosa. Así mismo, una característica muy importante de la CMDB es que representa no sólo los Elementos de Configuración existentes y todos sus atributos, sino las relaciones entre ellos.

56

Gestión de Servicios TI basado en ITIL

La Gestión de Configuraciones no debe ser confundida con la de Activos: -

-

La Gestión de Activos - es un proceso contable para monitorizar la depreciación de los activos que exceden en precio ciertos límites, manteniendo registros del precio de compra, depreciación, unidad del negocio y localización. Un sistema eficaz de Gestión de Activos puede ser la base para poner en marcha el sistema de Gestión de Configuraciones, ya que puede ser la fuente inicial para poblar la CMDB. La Gestión de Configuraciones - va más allá, ya que además mantiene información sobre la relación entre los CIs (Elementos de Configuración) y la estandarización y la autorización de los CIs. La Gestión de Configuraciones también monitoriza el feedback sobre la información actual - estado de los componentes TI, su ubicación, y los cambios que se les han hecho.

6.2 Objetivos La Gestión de Configuraciones tiene como objetivo asistir con la administración del valor económico de los servicios TI (una combinación de requisitos del cliente, calidad y costes) manteniendo un modelo de infraestructura y de servicios TI lógico, y dando esa información a los otros procesos comerciales. La Gestión de Configuraciones implementa esto identificando, monitorizando, controlando y ofreciendo información sobre los Elementos de Configuración y sus versiones. Los objetivos de la Gestión de Configuraciones incluyen: - Mantener informes fiables de los detalles de los componentes TI y de los servicios que brinda a la organización. - Proveer información y documentación correctas para ayudar a los otros procesos de la Gestión de Servicios.

6.2.1 Beneficios La Gestión de Configuraciones contribuye a que la provisión de servicios de alta calidad en TI mantenga una relación de coste/calidad óptima al: -

-

Gestionar componentes TI - los componentes TI son esenciales para los servicios. Cada elemento de los servicios incluirá uno o más CIs y la Gestión de Configuraciones verifica que sucede con ellos. Servicios comerciales de alta calidad - la Gestión de Configuraciones proporciona información a los procesos de Cambios, identificación y solución de problemas y soporte a usuarios. Esto reduce la cantidad de errores y por lo tanto también reduce los costes al evitar la duplicación de esfuerzos. Eficacia en la solución de problemas - la Gestión de Configuraciones proporciona información al respecto de la ubicación de los CIs afectados y gestiona la modificación y reemplazo de CIs. También brinda información de tendencias para el proceso de Gestión de Problemas. Procesamiento de los cambios mas veloz - la Gestión de Configuraciones facilita el análisis de impacto rápido y veraz para poder procesar los cambios más rápida y eficazmente. Mejor control del software y hardware - se puede combinar el instalaciones de los paquetes, posiblemente también con los rollouts de hardware, y de esa manera evaluar toda la combinación por adelantado. La CMDB y las líneas de referencia (tomas instantáneas de la infraestructura) se pueden utilizar para desarrollar planes de distribución y de evaluación para grupos específicos. Mejora de la seguridad - gestionar las versiones utilizadas brinda información sobre los cambios autorizados a los CIs y el uso de las diferentes versiones de software. La información de la CMDB también puede ayudar a la correcta gestión del uso de licencias de software. Cumplimiento de los requisitos legales - cuando se realicen las auditorias y se las compare con la CMDB se identificaran las copias ilegales. Esto puede añadir un beneficio adicional ya que el software ilegal puede contener virus. De esta manera, la Gestión de Configuraciones puede prevenir la introducción de virus dentro de la organización. A pesar de que puede resultar difícil evitar que el personal introduzca software ilegal contaminado, el hecho de que el staff sepa que pueden ser descubiertos por la Gestión de Configuraciones, CMDB y las auditorías, y con las medidas disciplinarias que esto acarrea, puede desalentar esta práctica. Es la idea de no ser descubiertos lo que incita al personal a romper las reglas.

57

Gestión de Configuraciones Mayor precisión en la planificación del gasto - la CMDB puede brindar información sobre los costes de mantenimiento y los contratos, las licencias y fechas de vencimiento. Mas ayuda a la Gestión de la Disponibilidad y de Capacidad -estos procesos dependen de los detalles de configuración correctos para analizar y planear los servicios. Una base sólida para la Gestión de Continuidad de Servicios TI - la CMDB, si existe una copia de respaldo en un lugar seguro, puede ser de mucha utilidad al restaurar los servicios tras un desastre. La CMDB también es importante para identificar los CIs necesarios para la recuperación ante desastres, incluyendo los procedimientos relevantes y los manuales si están incluidos en la CMDB. El primer paso para la realización de un Plan de Continuidad del Negocio es la elaboración de un BIA (Business Impact Analisys). Durante esta fase, la existencia de una CMDB con los datos correctamente actualizados será de una gran ayuda. Identificación de los costes ocultos - normalmente encontraremos en las organizaciones multitud de registros administrados localmente por las secciones de la organización responsables de cada uno de los procesos. Las duplicidades e inconsistencias entre estos diferentes registros significan costes y riesgos adicionales. Para facilitar la identificación de los costes y reducir la carga de trabajo del personal TI se recomienda que la CMDB se convierta en un proceso coordinado a una cantidad limitada de individuos y en una base de datos única a nivel de la organización con la información centralizada.

-

-

6.3 El Proceso El proceso de registro y modificaciones de la Gestión de Configuraciones incluye mantener información sobre cambios e información de los procesos de adquisición. Los egresos son los registros de los otros procesos y la gestión TI. Hay otra producción: en esa la Gestión de Configuraciones brinda datos CMDB para los otros procesos para tener acceso mientras desarrollan sus actividades. Gestión de Cambios

Gestión de Versiones

Gestión de Configuraciones

Requerimiento de cambio registra y asigna un número de RDC

Reporte y auditoría de configuraciones

Análisis Analiza el impacto y busca consensos cuando se presentan diferencias entre asesores

Reporte de áreas y CI’s impactadas

Aprobación del cambio

Actualización de registros de CI’s

CMDB

Librería de SW definitiva

(DSL)

Implantación del cambio Involucra pruebas previas a la liberación

Liberación y distribución de nuevas versiones de SW y HW con documentación

Liberación de SW de la DSL y actualización de la CMDB

Revisión de la implantación Evalúa si el cambio cumplió con las expectativas

Cierre del cambio

Fin

Figura 6.2: Relaciones entre la CMDB y otros procesos (fuente: OGC)

58

Revisión de los registros de la CMDB actualizados

Gestión de Servicios TI basado en ITIL La Gestión de Configuraciones tiene vínculos con cierta cantidad de procesos.

6.3.1 Gestión de Incidentes La Gestión de Incidentes necesita consultar información sobre toda la infraestructura y los servicios relacionadas con ésta. Cuando se registran incidentes, la Gestión de Incidentes necesita acceso a toda la información relativa a los CIs, p. ej. para determinar la ubicación de los CIs y el propietario, para determinar si hay un problema o error conocido asociado a una solución temporal con el CI, para que cliente y para que servicio se dispuso, y porque SLA está cubierto.

6.3.2 Gestión de Problemas La Gestión de Problemas precisa información sobre la complejidad de la infraestructura de TI. Este proceso debería poder vincular los problemas y los errores conocidos a CIs y utiliza los datos CMDB para analizar incidentes y problemas. Al realizar la verificación real de la infraestructura con la configuración autorizada en la CMDB puede mostrar desviaciones o defectos en la infraestructura.

6.3.3 Gestión de Cambios La Gestión de Cambios utiliza la CMDB para estimar el impacto de los cambios a implementar. Este proceso autoriza cambios, y los cambios deben asociarse con los CIs pertinentes, de forma que en cualquier momento los demás procesos pueden consultar el histórico de cambios realizados sobre un determinado CI (Por ejemplo, esta información cobra una importancia especial durante el análisis de Problemas). La Gestión de Cambios es responsable del registro de RFCs, de forma que se convierte también en un proveedor de datos para mantener actualizada la CMDB.

6.3.4 Gestión de Versiones El proceso de Gestión de Versiones da información sobre los planes de despliegue y sobre las versiones autorizadas, tal como las fechas previstas de versiones mayores y menores. Este proceso proporciona información sobre los cambios implementados. Antes de implementar un cambio pide información sobre CIs, tal como el estado, ubicación, código de fuente, etc.

6.3.5 Gestión de Niveles de Servicio La Gestión de Niveles de Servicio necesita información sobre las características del servicio, las relaciones entre servicios y la infraestructura subyacente. Los datos de SLM también se pueden guardar en la CMDB dentro del CI como atributo. El Nivel de Servicio (p. ej. oro, plata, bronce) se puede registrar contra el servicio CI, o el componente CI de hardware o software.

6.3.6 Gestión Financiera La Gestión Financiera necesita información sobre el uso de servicios; por ejemplo quién tiene un PC o quién usa una determinada aplicación, y combina esto con la información de los SLAs para determinar los precios a cobrar. Este proceso también monitoriza los componentes y las inversiones TI (Gestión de Activos).

6.3.7 Gestión de la Disponibilidad La Gestión de la Disponibilidad utiliza la CMDB para identificar los CIs que contribuyen al servicio, para diseñar planes para los cambios, y para identificar debilidades, por ejemplo usando el Análisis de Impacto de Fallo de Componentes (CFIA). La disponibilidad de un servicio (cadena de componentes de la infraestructura) sólo es tan buena como el componente mas débil (vinculo en la cadena). La Gestión de Configuraciones da información sobre la composición de la cadena, y de cada elemento.

6.3.8 Gestión de Continuidad de Servicios TI La Gestión de Continuidad utiliza las configuraciones estándar de la CMDB (líneas de referencia o de base) para especificar los requisitos de recuperación ante desastres y evalúa que estas configuraciones estén disponibles en el lugar de recuperación de desastre. Así mismo, hay que recordar que en la CMDB no sólo podremos almacenar elementos físicos o componentes de servicios, sino además mantendremos datos vitales para la Gestión de Continuidad como es la documentación, los procedimientos para la activación de las salvaguardas y el Plan de Contingencia.

55

Gestión de Configuraciones

6.3.9 Gestión de la Capacidad La Gestión de la Capacidad usa datos de la CMDB para planear la optimización de la infraestructura TI, para asignar la carga de trabajo y para desarrollar un plan de capacidad.

6.3.10 Actividades Aunque, como los otros procesos, la Gestión de Configuraciones tiene un flujo de trabajo lógico, este no se sigue de una manera tan estricta. Se tiende a desarrollar las actividades en paralelo. La secuencia que se muestra a continuación se brinda primero para desarrollar el proceso al introducirlo, y para procesar e implementar los nuevos requisitos de información. -

-

-

Planificación - determinar la estrategia, política u objetivos de los procesos, análisis de la información disponibles y sus fuentes, identificación de las herramientas y recursos, creación de interfaces con otros procesos, proyectos, abastecedores, etc. Identificación - establecer el proceso para mantener la base de datos actualizada. Las actividades incluyen el desarrollo de modelos de datos para registrar todos los componentes de la infraestructura TI, las relaciones entre ellos y la información sobre sus propietarios o persona responsable, estado y documentación disponible. También se deben desarrollar los procedimientos para los nuevos CIs y para los cambios a CIs. Como las demandas de información cambian continuamente, la identificación de los datos de configuración cambia de la misma manera. Es muy importante en esta fase ser previsor al respecto de los procesos de ITIL que se van a implementar, ya que cada proceso requerirá de conjuntos de información diferente. De esta manera, si únicamente se va a poner en práctica la Gestión de Incidentes, el conjunto de información o atributos necesarios de cada CI será diferente al que se necesitaría en el caso de querer implementar la gestión Financiera. Control - el control garantiza que la CMDB este actualizada por la sola admisión, registro y monitorización de CIs autorizados e identificados. Control asegura que no se agregue, cambie o reemplace un CI sin la documentación que corresponda, como un RFC aprobado o una especificación actualizada. Monitorización del estado - guardar detalles actuales e históricos sobre el estado de los CIs durante su ciclo de vida. Este tipo de monitorización se puede usar para identificar estados tales como "en desarrollo", "en pruebas", "en producción”, "en almacén (stock)" o "eliminado". Verificación - verificación de la Base de Datos de la Gestión de Configuraciones (CMDB) por medio de auditorias de la infraestructura TI para verificar la existencia de CIs registrados y para evaluar la exactitud de los registros. Elaboración de informes - para dar información a los otros procesos e informar sobre las tendencias y desarrollos en el uso de los CIs.

Estos temas serán tratados en detalle más adelante.

6.4 Actividades 6.4.1 Planificación Los propósitos, objetivos, alcance y prioridades de la Gestión de Configuraciones se deben definir dentro de la Gestión de Servicios y deben estar en línea con los objetivos del negocio. El alcance de la Gestión de Configuraciones viene detallado en el Paso de Identificación. Los pasos relevantes para implementar la Gestión de Configuraciones están fuera del alcance de este libro.

6.4.2 Identificación La identificación se relaciona con la definición y mantenimiento de las convenciones y los números de versión de los componentes físicos de la infraestructura T I , la relación entre ellos, y los atributos pertinentes. Las configuraciones de TI de referencia del hardware actuales y futuros se describen en forma de clusters CI.

56

Gestión de Servicios TI basado en ITIL La pregunta general sobre la identificación de los componentes TI es: "¿Qué servicios y componentes asociados a la infraestructura TI debería controlar la Gestión de Servicios, y qué información necesitamos para ellos?” Cuando se desarrolla un sistema de identificación, se deben tomar decisiones sobre el alcance y el nivel de detalles de la información a registrar. Se debe identificar un propietario o stakeholder para cada propiedad (característica) a registrar. La pregunta general de arriba puede detallarse para determinar la información a registrar. Ejemplos de tales preguntas son: -

¿De qué recursos se dispone para obtener y mantener actualizada la información? ¿Qué madurez tienen nuestros procesos administrativos y logísticos? ¿A qué niveles se instalan, reemplazan, desarrollan y/o distribuyen los componentes en la organización, independientemente de los componentes más importantes? ¿Qué actividades desarrolladas por terceros deberían medirse y estar bajo control? ¿Qué componentes impactarén los servicios si se ven afectados por un fallo, y que información es pertinente al diagnosticar tales fallos? ¿Para qué componentes se debe registrar el estado y la historia del estado? ¿De qué componentes hay varias versiones o variantes utilizadas en la organización? ¿Qué componentes pueden afectar la capacidad y disponibilidad de los servicios después de un cambio? ¿Qué componentes de valor deberían contar con seguro contra robo o perdida? ¿Cuáles son las necesidades de información actuales y futuras de los otros procesos? ¿Para qué componentes se debería contar con información sobre número de serie, fecha de compra, y abastecedor, y que información necesita el departamento contable? ¿Para qué componentes se debe contar con información al respecto de contratos de soporte y mantenimiento y que información de este tipo es la requerida por cada uno de los diferentes abastecedores? ¿Qué requisitos se asocian con las provisiones del SLA? ¿Qué información se necesita para establecer los precios? ¿Las ambiciones son realistas o se deberían diferir algunos temas?

Las respuestas a estas preguntas nos darán información sobre una serie de actividades. Se debe tomar una decisión sobre el alcance (extensión) de la CMDB y su nivel de detalle (profundidad). La profundidad se puede dividir en: el número de niveles, las relaciones a rastrear, las convenciones de nomenclatura, y atributos. Estas áreas se tratan más abajo. Detallando el Alcance (de Tipos CI) Cuando se establece una CMDB y cuando se actualiza el modelo de datos, se debe decidir que parte de la infraestructura TI debe controlar la Gestión de Configuraciones. Por ejemplo, se deberían incluir PDAs, copiadoras y máquinas de fax en red, teclados y personal TI, o están fuera del alcance? El alcance de la Gestión de Configuraciones afecta al alcance de los diagnósticos de la Gestión de Problemas, el análisis de impacto de la Gestión de Cambios, la comprobación de los SLAs, el análisis y planeamiento de la Gestión de la Disponibilidad, etc. De manera adicional, también se pueden analizar los servicios TI y su contribución o impacto en las actividades comerciales del cliente. Por último, se pueden considerar los acuerdos hechos con los clientes sobre soporte y servicios. El alcance se puede dividir en áreas con sus propios requisitos y planteamientos. Ejemplos de estas áreas son estaciones de trabajo, comunicaciones de datos, archivos, servicios de impresión y aplicación, procesamiento central, base de datos y sistemas TI, y servicios de telefonía. Para desarrollar cada área, se puede establecer un proyecto independiente en al entorno de gestión pertinente.

57

Gestión de Configuraciones El alcance de la CMDB puede incluir hardware y software, pero también documentación, como Acuerdos de Nivel de Servido (SLAs), procedimientos, manuales, especificaciones técnicas, cartas de organización, planes de personal y proyectos. Como otras CIs, estos documentos estarán presentes físicamente en todos lados, pero son ingresados en la CMDB bajo número de versión, fecha de publicación, autor y otra información. Por lo tanto la Gestión de Configuraciones y la de Cambios pueden controlar las características de estos documentos. La Figura 6.3 muestra la relación entre un servicio y los componentes CMDB. Debajo de esto, encontramos los otros CIs necesarios para el servicio. Mantener la posición de estas relaciones hace más fácil determinar el impacto de los incidentes en los servicios. También es posible generar un informe de todos los componentes utilizados para un servicio. Esta información después se puede utilizar para planear las mejoras del servicio. El CI "servicio" también puede tener relaciones con otras CIs como acuerdos con el cliente en forma de Acuerdos de Nivel de Servicio. El Servicio B está por completo fuera del alcance. Esta figura muestra que no todas los CIs que contribuyen al "servicio A" están cubiertos por el alcance de la CMDB, lo que significa que el servicio A no cuenta con soporte total.

Figura 6.3: Alcance de CMDB (fuente: OGC)

Después de determinar el número de áreas en el alcance, podemos identificar el ciclo de vida de los elementos CI a incluir en el alcance. ¿Los CIs se incluyen en la CMDB cuando su estado es "en desarrollo" o "en producción", o sólo cuando han sido incorporados a la infraestructura? La ventaja de incluir los productos en desarrollo es que sus especificaciones no pueden cambiarse sin consultar y que su transferencia al ambiente de gestión será más fácil. La monitorización del estado de actividad de la Gestión de Configuraciones se verá afectada por esta elección, pero también puede ampliar el alcance de la Gestión de Configuraciones en términos de ciclo de vida del producto. Nivel de detalle Determinar el nivel de detalle de cada tipo de CI es un aspecto importante del establecimiento de la Gestión de Configuraciones. Es imposible predeterminar el nivel de detalle o conjunto de atributos que se deben incluir en la CMDB, por lo que esta decisión será trascendental para la correcta implantación del proceso de Gestión de Configuraciones. Para determinar el nivel de detalle, se diseña un plan de las relaciones entre CIs a cubrir en profundidad en la CMDB, y los nombres y atributos a cubrir. Se deben sopesar con cuidado, los requisitos, carga de trabajo asociadas y recursos disponibles cuando se determina la profundidad de las relaciones a cubrir. El número de relaciones aumenta exponencialmente con el número de niveles y el coste de mantenimiento posterior puede llegar a ser prohibitivo), ya sea económicamente o bien en términos de esfuerzo. Es importante tener en cuenta que el proceso de Control

58

Gestión de Servicios TI basado en ITIL indicado anteriormente se debe asegurar de que el contenido de la CMDB este al día y sea fiel a la realidad, por lo que a más información queramos mantener en la CMDB el coste de Control será mayor. Relaciones CI Las relaciones entre CIs son útiles para diagnosticar errores y predecir la disponibilidad de los servicios. Se pueden registrar muchas relaciones lógicas y físicas diferentes. • Relaciones físicas: - Forma parte de - esta es la relación padre/hijo del CI, p. ej. un floppy disk forma parte de un PC, y un modulo de software forma parte de un programa. - Esta conectado a- p. ej. un PC conectado a un segmento LAN. - Es necesario para - p. ej. hardware necesario para realizar una aplicación. • Relaciones lógicas: - Es copia de - copia de un modelo estándar, línea de referencia o programa. - Se relaciona - un procedimiento, manuales y documentación, un SLA, o área de cliente. - Es usado por- p. ej. un CI necesario para brindar un servicio, o un modulo de software que comparten cierto número de programas.

Figura 6.4, Relación padre/hijo de los Cls(fuente: OGC)

Al respecto de las relaciones entre Elementos de Configuración, estas son bidireccionales y normalmente encontraremos que el mero hecho de relacionar un CI 'a’ con un CI 'b' mediante una relación R, es decir aRb hace que aparezca una relación inversa de forma automática entre el CI 'b' y el CI ‘a’ De esta forma, si decimos que existe la relación 'a es necesario para b‘ automáticamente aparece una relación inversa que nos indica que 'b necesita a'. Por ejemplo, podemos tener elementos de Configuración que representan unas determinadas aplicaciones y tenemos otros elementos de Configuración que representan diferentes niveles de versión de Sistema Operativo. Así podremos relacionar las aplicaciones indicando las diferentes versiones de Sistema Operativo (por ejemplo, la contabilidad requiere Linux versión 2.3, el control de existencias requiere Linux versión 2.5, la gestión de nominas requiere Linux versión 2.3) y cuando se vaya a realizar un Cambio sobre la aplicación de Contabilidad sabremos los requisitos que tiene, pero si debemos realizar una actualización de Sistema Operativo, podremos realizar el análisis de Impacto y determinar fácilmente a que aplicaciones vamos a afectar (Por ejemplo, del caso anterior sabemos que actualizar la versión Linux de 2.3 a 2.4 puede afectar a las aplicaciones de Contabilidad y de Nominas).

59

Gestión de Configuraciones Profundidad o Nivel de Detalle Cuando se define el nivel del sistema, se crea una jerarquía de componentes y elementos. Se seleccionan los padres CIs y se define el número de niveles utilizados para el detalle. El nivel más alto está conformado por la infraestructura TI en si misma. El nivel más bajo es el nivel más detallado que se debe controlar. Incorporar un CI a la CMDB sólo resulta útil si su control y la información relacionada tienen algún beneficio para los procesos ITIL. Una consideración a tomar en cuenta para analizar nivel y profundidad es que el CI registrado en la CMDB debe seguir el proceso formal de Gestión de Cambios para que el cambio tenga efecto. Así, registrar el ratón en la CMDB significa que el pedido de un nuevo mouse debe canalizarse a través de la Gestión de Cambios como una RFC y no como una Petición de Servicio. Esto por lo general resulta una buena regla y una llamada de atención para las organizaciones que tienen un nivel de detalle demasiado bajo. Las siguientes consideraciones generales se aplican a la definición de la CMDB: -

A mayor cantidad de niveles, se debe manejar más cantidad de información. Esto incrementa la carga de trabajo y da como resultado una CMDB más grande, más compleja y más difícil de mantener. Cuanto menos niveles haya, menor control e información se tendrá sobre la infraestructura TI.

Si la CMDB no tiene muchos detalles, no se pueden monitorizar los cambios de los componentes principales. En ese caso, ante cualquier cambio a los componentes de un CI padre se creará una variante3 del CI padre. Por ejemplo, un PC disponible con dos tipos de disco duro aparecerá como Variante A y Variante B. Si hay demasiados cambios en los componentes hijo, será difícil y complejo mantener el número de variantes. Sin embargo, si existen mas niveles fundamentales se pueden mantener las variantes en el nivel correcto. Se pueden registrar más atributos para los componentes hijo y se los puede asociar con los errores conocidos, y durante el diagnóstico se pueden hacer preguntas tales como: "¿Qué controlador se necesita para esta opción de hardware?", "¿A qué segmento está conectada esta tarjeta de interfaz de red?", "¿Qué programas utilizan esta biblioteca?".

Figura 6.5, Detalle de la CMDB (fuente: OGC)

3

Las variantes se utilizan si coexisten demasiadas por mas de una CI; p. cj. cuando hay una relación paralela. Las versiones existen, por ejemplo, si tanto la versión nueva como la vieja están en uso al mismo tiempo, p. ej. cuando hay una relación actual. El uso eficaz de estos dos conceptos ayuda en la planificación de cambios. Si se desarrolla cada variante por separado, se debe introducir un número de versión de sistema por separado para cada variante. No resulta una buena alternativa porque hace más compleja la infraestructura TI y se necesita mas estudio para mantenerla. En muchos casos es aconsejable continuar desarrollando la fuente de todas las variantes y utilizar la nueva versión donde sea posible para crear las variantes necesarias.

60

Gestión de Servicios TI basado en ITIL Convención de nomenclatura Cada CI debe tener un nombre único y sistemático para asegurarse que se pueda distinguir de otros CIs. La opción más básica es un simple sistema de numeración, posiblemente dividido en líneas para cada área. Al crear un nuevo CI se puede generar un número nuevo. De ser posible, los nombres deben tener significado para facilitar la comunicación con los usuarios, sobre todo en aquellos CIs que vayan a ser utilizados en el soporte a usuarios. Por ejemplo, cuando un usuario llama al Centro de Atención a Usuarios indicando que su PC no funciona, tendrá que indicar que PC de todos los que hay en la organización es el que no funciona. Debemos utilizar una nomenclatura cómoda de usar y que el usuario pueda encontrar de una forma sencilla (no es una buena idea, por ejemplo, utilizar como identificador de un PC un número de serie de 10 dígitos). Los nombres de las convenciones también se pueden utilizar para clasificar los CIs, y que de esta manera sean fáciles de identificar durante las auditorías, el mantenimiento y los registros de incidentes. Algunos de los nombres recomendados por la ITIL para las convenciones son: -

-

Las etiquetas físicas del hardware deben ser de fácil acceso y lectura para los usuarios, y deben ser difíciles de quitar. Se puede acordar con los proveedores de servicio externalizados que soportan los contratos que se refieran a la información presente en las etiquetas. Un usuario también debe poder leer la etiqueta al informar un incidente. Se debe marcar con un número CI, un número de versión y una fecha los documentos controlados, tales como SLAs, procedimientos, y cartas de organización. Se debe almacenar en la DSL (Biblioteca de Software Definitiva) las copias de software, ver el capítulo sobre Gestión de Versiones. Todo el software debe contar con un número CI, y si es posible, el software instalado también debe tener un número CI, un número de versión, y un número de copia.

Atributos Además de los niveles de estructura CI, las relaciones, y las convenciones sobre los nombres, el desarrollo detallado de la CMDB también debe incluir los atributos. Los atributos son utilizados para almacenar la información pertinente en el CI. Se pueden utilizar los siguientes atributos para crear una CMDB. ATRIBUTO

DESCRIPCIÓN

Número / etiqueta o código de barra CI

Identificación única del CI. Este es a menudo un número de registro que le asigna automáticamente la base de datos. Aunque no se pueden etiquetar físicamente todos los CIs, todos tienen un número único. Número de identificación del proveedor en forma de un número serial o número de licencia. Herramientas de auditoria a menudo usan sus propios identificadores que pueden ser diferentes para cada área. Este atributo provee el vínculo a este ambiente. Identificación única que utiliza el proveedor en el catalogo. Cada versión de un modelo tiene un número diferente, p. ej. PAT-NL-C366-4000-T. Nombre completo del modelo, que a menudo incluye un identificador de versión, p. ej. 'PIIMMX400MHz'. Fabricante del CI. Clasificación del CI (p. ej. hardware, software, documentación, etc.). Descripción del tipo de CI, brinda detalles sobre la categoría, p. ej. Configuración hardware, paquete software, o modulo de programa. Fecha en la que vence la categoría. Número de versión del CI. Ubicación del CI, p. ej. la biblioteca o media donde residen los CIs del software, o el lugar/habitación donde se ubican los CIs de hardware. Nombre y/o designación del propietario o persona responsable del CI. Fecha en la que la persona antes mencionada se hace responsable del CI. El origen del CI, p. ej. desarrollado en la casa, comprado del proveedor X, etc. Número de licencia o referencia al acuerdo de licencia. Fecha en la que el CI fue entregado a la organización. Fecha en la que el CI fue entregado y aceptado en la organización. Estado actual del CI, ej. 'en prueba', 'activo', 'eliminado'. Siguiente estado programado del CI, con la fecha e indicación de la acción requerida. Coste de adquisición del CI. Valor actual del CI tras la depreciación. Campo de texto para comentarios, p. ej. para describir como una variante difiere de otra.

Copia o número serial Número de identificación de herramientas de auditoria Número del modelo / catalogo de referencia Nombre del modelo Fabricante Categoría Tipo Fecha de vencimiento de la categoría Número de versión Ubicación Propietario responsable Fecha de Responsabilidad Origen/proveedor Licencia Fecha de entrega Fecha de aceptación Estado (actual) Estado (programado) Coste Valor residual tras la depreciación Comentario Tabla 6.1. Ejemplos de atributos

61

Gestión de Configuraciones

Depende de la herramienta de Gestión de Servicios si la relación con los incidentes, etc. se incluye en la CMDB como atributo o de otra manera. En general, los números de las CIs pertinentes se incluyen en el registro de incidentes, de problemas y de cambios. Cualquiera sea la aproximación que se elija, las relaciones que se deben mantener entre los CI y los otros registros de los diferentes procesos son los siguientes: ATRIBUTO Números de RFC Números de Cambios Números de Problemas Números de Incidentes

DESCRIPCTON Número(s) de RFC abiertos actualmente o con anterioridad para el CI. Número(s) de cambio(s) abiertos actualmente o con anterioridad para el CI. Número(s) de problema(s) abiertos actualmente o con anterioridad para el CI. Número(s) de incidente(s) relacionados con el CI.

Tabla 6.2 Otros registros relacionados con los CIs

Como se mencionara anteriormente, mantener las relaciones entre los CIs es un trabajo importante de la Gestión de Configuraciones. Dependiendo del tipo de base de datos, estas relaciones se pueden registrar como atributos CI, o en una tabla por separado. ATRIBUTO Relaciones CI padres Relaciones CI hijos Otras relaciones

DESCRIPCION Clave o número CI de los CIs padre. Clave o número CI de los CIs hijo. Relaciones entre el CI y los otros CIs, aparte de las relaciones padre hijo antes mencionadas, p. ej. este CI 'usa' o 'esta conectado a'.

Tabla 6.3 Relación entre los atributos

Algunas bases de datos cuentan con una opción en forma de texto para registrar los cambios de los contenidos de campo para mantener un log histórico (Auditoria de cambios sobre los atributos). Esto puede ser útil para los campos marcados como "Estado Actual" para obtener información sobre Tiempo de Parada (downtime), reparadores y mantenimiento. También puede ser útil para rastrear la información del propietario. Además de los atributos que se mencionan más arriba, puede ser necesario tener listas de los atributos con información técnica sobre cada tipo de CI. Cada categoría de CI diferente tendrá características diferentes. Por ejemplo, para una PC: capacidad del disco duro, fabricante BIOS y versión BIOS, RAM, dirección IP, etc. Muchos sistemas de Gestión de Sistemas o de Gestión de Inventario registrarán esta información, y en ese caso es suficiente crear un enlace al tipo de registro CI para evitar que se duplique la información. Sin embargo, debemos recordar que estos sistemas dan información actual sin indicar si los resultados vienen de un cambio aprobado o sin autorización. Las listas rápidas se pueden usar para facilitar la entrada y la actualización de atributos. También se pueden crear vínculos a otras fuentes confiables, para información sobre ubicación, usuarios, departamentos, números de teléfono, tenedor de presupuesto, y números de presupuesto. Existen muchas opciones, pero se debe considerar la carga de trabajo que implica mantener estos archivos. Líneas de referencia Una línea de referencia de configuraciones es una toma instantánea de un grupo de CIs tomada en punto de tiempo específico. Una línea fundamental de configuración se puede usar como: -

62

Un producto autorizado/soportado que pueda ser incorporado a la infraestructura (estas líneas fundamentales están incluidas en el catalogo del producto). CIs estándar para registrar información de coste (coste de los elementos). Puntos de comienzo para desarrollar y evaluar las nuevas configuraciones. Como un back-out si existieran problemas con las nuevas configuraciones tras los cambios. Como un estándar para dar configuraciones a los usuarios, p. ej. "una estación de trabajo estándar". Como punto de partida para suministrar nuevo software.

Gestión de Servicios TI basado en ITIL Una estación de trabajo estándar (homologada para la Organización) es un ejemplo común de una línea de referencia. Al limitar el número de estaciones de trabajo estándar distintas es más fácil estimar el impacto y los recursos necesarios para poner en marcha nuevas funciones y mejoras, y para evaluarlas. Las líneas de referencia también se pueden utilizar para establecer una política para combinar y planear los cambios, p. ej. para Releases Empaquetados. Las líneas de referencia ayudan a reducir los costes de gestión y facilitan el proyecto de planificación. El catalogo de producto es otra aplicación útil de las líneas de referencia. Este catalogo enumera las configuraciones certificadas que se pueden utilizar en la infraestructura TI, y que los usuarios pueden solicitar. En ese caso, un CI nuevo es una copia del catalogo, con número y etiqueta. Antes de incorporar un modelo o producto nuevo a la infraestructura se lo debe incluir en el catálogo. Para esto es necesario tomar tres decisiones: • Del negocio - ¿Sirve a los intereses del negocio del usuario? • Finanzas - ¿Los costes de soporte son aceptables? • Impacto - ¿E1 impacto sobre el servicio es aceptable? Registro La CMDB en principio está llena de información de los registros financieros y de los registros de la infraestructura TI y se suplementa con la información técnica de los abastecedores. Sólo se registra la información con un stakeholder identificado, y la organización debe comprometerse a registrarla (p. ej. debe estar preparada para actualizar la información).

6.4.3 Monitorización del Estado El ciclo de vida de un componente se puede dividir en muchas etapas, y se le puede asignar un código de estado a cada etapa. Esto depende de las características de la infraestructura TI que la organización quiera registrar. Llevar un registro de la fecha de cada cambio de estado puede ser una fuente de información muy útil sobre el ciclo de vida de un producto: fecha de orden, de instalación, y las necesidades de mantenimiento y soporte.

Figura 6.6 Ejemplo de la monitorización del CI (fuente: OGC)

El estado de un componente también puede determinar lo que se puede hacer con el. Por ejemplo, si se rastrea el estado de partes no operacionales, este hardware no puede cambiar de lugar sin previa consulta, por ejemplo como parte de un plan de recuperación ante desastres. Un cambio en el estado de un CI puede ser producto de un cambio autorizado o sin autorización o de un incidente. Se puede utilizar la siguiente clasificación de estatus: • Nuevos CIs - En desarrollo/pedido - Evaluado - Aceptado

63

Gestión de Configuraciones

• CIs Existentes - Recibido - RFC abierta para la CI, nueva versión pedida - El cambio se incluyo y se aprobó en los planes, se proveerá una nueva CI y documentación (que también es una CI) - Mantenimiento en progreso - Down • CIs Archivadas - Obsoleto - Borrado - Eliminado - Robado - Vendido o alquiler vencido - En almacenamiento de archivo a la espera de donación, venta o destrucción - Destruido • Todas CIs - En stock - El pedido ha sido recibido, o la versión cambiada esta disponible - A prueba - Lanzado para instalar - Vivo (activo), la CI esta en uso - Excedente

6.4.4. Control La información debe manejarse de manera eficaz para mantener la CMDB al día. Cuando una actividad cambia las características registradas de una CI, o la relación entre las CIs, el cambio debe quedar asentado en la CMDB. Nota: los cambios en las características de las CIs sólo pueden realizarse si el cambio fue autorizado por la Gestión de Cambios; la Gestión de Incidentes sólo puede cambiar el estatus de una CI existente. La Gestión de Configuraciones controla todos los componentes TI que recibe la organización y garantiza que sean registrados en el sistema. El hardware se puede registrar cuándo se pide o cuándo se entrega, y el software cuándo se incluye definitivamente en la Biblioteca de Software Definitiva (DSL). Una de las tareas de control es garantizar que sólo se registren las CIs que hayan sido autorizadas y que están incluidas en el catalogo de productos. Por tal razón, la Gestión de Configuraciones mantiene fuertes vínculos con los abastecedores, la Gestión de Incidentes, de Problemas y de Cambios. Si los cambios coordinados por la Gestión de Cambios se efectúan en la estructura TI, la Gestión de Configuraciones debe incluir la información en la CMDB. Aunque las publicaciones de ITIL no son muy claras al respecto, en la práctica, registrar las RFCs es responsabilidad de la Gestión de Cambios. Los cambios son la mayor fuente de información sobre los cambios en la infraestructura y la actualización de la CMDB. Como tal, la Gestión de Configuraciones impone ciertos requisitos sobre la madurez de los otros procesos en los departamentos, en particular en la Gestión de Cambios, de producción y el departamento de compras. Para garantizar que la situación real refleje la CMDB autorizada, se monitorizan las siguientes acciones: - El CI esta presente en la CMDB. - El CI cambia de estado, p. ej. "activo" o "inactivo" (útil para la Gestión de la Disponibilidad). - El CI cambia de propietario. - El CI cambia en relación a otro CI. - El CI ha sido eliminado. - El CI tiene otra relación con un servicio, documentación u otros Cis. - Se renueva o modifica la licencia del CI. - Los detalles del CI se actualizan después de la auditoria.

64

Gestión de Servicios TI basado en ITIL

6.4.5 Verificación y auditorias Las auditorias se utilizan para verificar si la CMDB es un reflejo fiel de la situación actual. Por ejemplo, las herramientas de auditoría pueden analizar automáticamente las estaciones de trabajo e informar sobre la situación actual y el estado de la infraestructura TI. Esta información se puede utilizar para chequear y actualizar la CMDB. Las auditorias se pueden llevar a cabo en las siguientes situaciones: -

Después de implementar la nueva CMDB. Seis meses después de la implementación. Antes y después de cambios importantes. Después de una recuperación ante desastres. En cualquier momento que resulte conveniente.

Se realizan las siguientes preguntas durante una auditoria: -

¿Están todas las RFCs, de todas las etapas de implementación, registradas en la CMDB, y están controlada por la Gestión de Configuraciones? ¿La CMDB esta actualizada? en caso negativo, ¿Por qué? ¿Qué impacto tiene en la Gestión de Cambios (análisis real del impacto de los cambios planificados)? ¿E1 nombre de los nuevos CIs es acorde con las convenciones de nomenclatura? ¿Las variantes están bien utilizadas? ¿Se han registrado correctamente las configuraciones básicas, y se dispone de ellas inmediatamente? ¿Los contenidos de la Biblioteca de Software Definitivo (DSL) y del Depósito de Hardware Definitivo (DHS) se corresponden con la información de la CMDB? En caso negativo, ¿Por qué no?

Las auditorias también se pueden hacer al azar, o si la Gestión de Configuraciones piensa que la información no es correcta. Si existe un vínculo con las herramientas de auditoría, se pueden generar auditorias o informes delta casi todos los días para cada área. Las herramientas de auditoria no deben estar habilitadas para actualizar automáticamente la CMDB cuando se encuentran discrepancias. Todas las discrepancias indican que los procesos de Gestión de Cambios han sido pasados por alto y deben ser investigados.

6.5 Control del Proceso 6.5.1 Informes de gestión e indicadores de rendimiento Los informes de la Gestión de Configuraciones pueden incluir los siguientes elementos: -

Información sobre la calidad de los procesos. Cantidad de diferencias observadas entre los informes y la situación encontrada durante una auditoria (deltas). Cantidad de ocasiones en las que una configuración no tenía autorización. Cantidad de ocasiones en las que no se pudo encontrar una configuración registrada. Diferencias a nivel de atributo descubiertas durante la auditoria. Tiempo necesario para procesar un pedido para registrar información. Lista de CIs donde se registraron más de un cierto número de incidentes o cambios. Información estadística sobre la estructura y composición de la infraestructura TI. Datos de crecimiento y otra información sobre los desarrollos en la infraestructura TI. Resúmenes, registros y propuestas para mejorar, como recomendaciones para cambios en el marco y nivel de los CIs rastreados por la Gestión de Configuraciones, debido a cambios del negocio, técnicos, de precio de mercado y otros. Lista de costes de personal cuando se implementa el proceso.

65

Gestión de Configuraciones

6.5.2 Factores críticos de éxito Es condición para que la Gestión de Configuraciones tenga éxito que se reciba la información necesaria para mantener la base de datos al día. Esto significa que los vínculos con la Gestión de Cambios deben ser fuertes. Siempre debe haber un stakeholder que registre las características. Al introducir el proceso es esencial que la implementación se divida en etapas. Si los registros necesarios se introducen de repente, generalmente se producen fallos porque no se puede instaurar de golpe la disciplina requerida en la Gestión de Configuraciones. Los registros que se mantienen antes de introducir el proceso deben ser eliminados para evitar la duplicación. Cuando se introduce el proceso es importante promover algunas ventajas claras para la Gestión de Configuraciones (Ganancias Rápidas). También resulta importante que los elementos registrados del proceso sean entregados al personal que tenga las habilidades necesarias y la actitud correcta.

6.5.3 Funciones y roles Los procesos atraviesan la jerarquía de la organización. Esto sólo resulta posible si las responsabilidades y las autoridades asociadas con su implementación se encuentran bien definidas. Para otorgar flexibilidad, puede ser útil tomar un planteamiento basado en roles y responsabilidades. En organizaciones pequeñas, o por motivos financieros, se pueden combinar los roles: por ejemplo Gestión de Cambios y de Configuración. Las tareas de la Gestión de Configuraciones pueden incluir: -

Propuestas de cambio al alcance y nivel de detalle de la Gestión de Configuraciones. Asegurar que los procesos de la Gestión de Configuraciones sean comunicados a toda la organización. Proveer personal y capacitación para los procesos. Desarrollar el sistema de identificación y la convención de nomenclatura. Evaluar los sistemas existentes e implementar nuevos. Definir, planificar e implementar la CMDB. Crear informes. Organizar auditorías de configuración.

6.6 Costes y problemas 6.6.1 Costes Los costes de la introducción e implementación de la Gestión de Configuraciones dependen mucho del alcance y nivel de detalle. Estos costes incluyen el hardware, software y personal. Los costes del hardware y software dependen de: -

Hardware necesario adicional, y su configuración. Software necesario adicional, y su configuración. Coste de las licencias basado en el número de usuarios. Aplicación y diseño de la base de datos, población, personalización e implementación. Desarrollo de la base de datos. Mantenimiento de la base de datos. Coste de personal adicional asociado al proceso.

Los costes de personal dependen primero del tamaño de la organización y del nivel de detalle de la CMDB.

66

Gestión de Servicios TI basado en ITIL

6.6.2 Problemas La organización TI debe fijar un claro compromiso con las características a registrar de la infraestructura TI, y debe brindar los recursos necesarios para esta clase de gestión. La organización también se debe comprometer a utilizar la CMDB y a incorporar cualquier dato de importancia y de estructura de cualquier base de datos pertinente usada antes de la introducción de la CMDB en la CMDB. Los siguientes problemas pueden afectar al éxito de la implementación: -

-

-

-

-

-

Alcance de la CMDB o nivel de detalle del CI equivocado - si el alcance de la CMDB es demasiado estrecho, no se podrán chequear, arreglar, asegurar o restaurar las partes importantes de la infraestructura. Si el alcance es demasiado amplio, la pesadez de la base de datos y de su mantenimiento será un obstáculo que hará más lentos todos los procesos de gestión de servicios. En caso de que existan demasiados niveles, atributos, y relaciones, resultara muy engorroso mantener la CMDB. Pocos detalles pueden significar información de registro insuficiente sobre las CIs y los incidentes, problemas, errores conocidos y RFCs relacionados. Sistemas manuales inadecuados - algunas organizaciones desean mantener los registros en papel durante todo el tiempo que sea posible y sólo comprar herramientas automáticas cuando su utilización se torna casi imposible. Esto puede originar demoras, confusión, y escasez de personal y recursos. Es mejor seleccionar una herramienta mas temprano, teniendo en cuenta las necesidades funcionales. Asumir cambios urgentes - siempre habrá situaciones en las que los cambios deban ser implementados rápidamente. Esto suele suceder fuera de horario de oficina. Si la CMDB también resulta pertinente en esta situación, es aconsejable registrar el cambio en la CMDB de inmediato, pero la persona a cargo puede estar ausente. Si es posible esperar hasta la mañana siguiente, los registros del cambio y la CMDB deben actualizarse lo más pronto posible. Calendarios demasiado ambiciosos - en caso de que el cronograma para los cambios (RFCs) no de tiempo a implementar la Gestión de Configuraciones, el trabajo será demorado y la Gestión de Configuraciones parecerá ser el obstáculo. Se deben realizar esquemas realistas en base a experiencias pasadas. Aceptación de la gestión - por ser la Gestión de Configuraciones un proceso relativamente nuevo y no siempre visible, la gente puede presentar una cierta resistencia. Debe existir un claro compromiso para el éxito de la implantación. Así, el Gestor de Configuraciones debe promover el proceso e informarlo al resto de la organización. La experiencia enseña que los costes del proceso se reducen si se presenta a la Gestión de Configuraciones como una disciplina separada con un personal dedicado y un gestor responsable del proceso. Pasando por alto el proceso - en situaciones de stress o del personal tratara de evitar la Gestión de Configuraciones. Si la situación persiste, aún después de dar toda la información sobre las desventajas de dejar de lado el proceso, se deben tomar medidas disciplinarias.

67

Gestión de Configuraciones

68

Gestión de Servicios TI basado en ITIL

Capítulo 7: Gestión de Cambios 7.1 Introducción El rápido desarrollo de la TI y del mercado muestra que el cambio es ahora una cosa común. Sin embargo, la experiencia demuestra que los incidentes que afectan las aplicaciones del negocio tienen por lo general relación con cambios. Las causas de tales incidentes son numerosas: pueden ser causa de descuido, falta de recursos, preparación insuficiente, pobre análisis de impacto, y evaluación incorrecta o dificultades iniciales. Si los incidentes relacionados con los cambios no se ponen bajo control, el proveedor de servido TI, y por consiguiente el negocio en sí mismo, puede salirse fuera de control. El número de incidentes aumenta con cada incidente que necesita un tratamiento de emergencia, que a su vez puede provocar nuevos incidentes. La planificación diaria falla a menudo para tener en cuenta la presión creciente de trabajo (”Lo importante deja paso a lo urgente". Dejamos de realizar las actividades importantes para realizar las actividades urgentes y por lo tanto las importantes no se realizan nunca). Esto en su momento impactará en la rutina de operación y mantenimiento de los servicios TI. La Gestión de Cambios tiende a manejar el proceso de cambio y limitar así el número de incidentes relacionados con los cambios. El lema de la Gestión de Cambios es: No todo cambio es una mejora, pero toda mejora es un cambio. La Figura 7.1 muestra el ciclo de cambios como un proceso provisto de propuestas para nuevos desarrollos (Entrega de Servicio y Gestión de Problemas), cambios (pedidos hechos a la Gestión de Cambios) y soluciones (Gestión de Problemas): -

Innovación y mejora - la introducción de nuevos servicios y de nuevas capacidades técnicas en la infraestructura TI serán responsables de algunos de los errores nuevos, a largo plazo de la infraestructura TI. Cambios - cualquier cosa, desde una instalación menor hasta la reubicación de un mainframe; si se hace sin cuidado, los cambios representarán errores a largo plazo en la infraestructura TI. Medidas correctivas - tienden a corregir los recientemente ingresados errores a largo plazo.

La Gestión de Cambios opera como un control termostático entre flexibilidad (permitiendo cambios que pueden llevar a errores a largo plazo) y estabilidad (permitiendo cambios para remediar errores a largo plazo). Las medidas correctivas reducen el número de incidentes y como resultado la presión de trabajo también disminuye.

Figura 71 Entradas al proceso de cambio

69

Gestión de Cambios

7.1.1 Términos Básicos Autoridades en la Gestión de Cambios Hay dos autoridades en la Gestión de Cambios: -

-

El Gestor de Cambios - la persona responsable de filtrar, aceptar y clasificar todas las Peticiones de Cambio (RFCs). En grandes organizaciones, el Gestor de Cambios puede tener ayudantes, Coordinadores de Cambios, que lo/la representan al vincularse con las distintas áreas de la organización. La Gestión de Cambios es también responsable de conseguir la autorización necesaria. Hasta cierto punto, el proceso ya tiene autorización por declaración, pero puede ser preciso acercarse a la Gestión TI (p. ej. Comité Ejecutivo o de Dirección) por algunos cambios. El Gestor de Cambios también es responsable de planificar y coordinar la implementación de los cambios. El Consejo Asesor de Cambio (CAB) - este cuerpo de consulta se reúne a menudo para evaluar y planificar los cambios. Por lo general, sólo los cambios más importantes se presentan ante el CAB. Se debe designar un CAB/EC (Comité de Emergencia) con autoridad suficiente para tomar decisiones de emergencia. La membresía del Consejo es flexible e incluye representantes de todas las secciones TI más importantes:
Gestor de Cambios (presidencia)
Gestor de (Niveles de) Servido
Representantes del Centro de Servicios y de la Gestión de Problemas
Gestores de Línea
Gestores del Negocio (o sus representantes) del área de clientes
Representante(s) de grupo de usuarios
Representantes de Desarrollo de Aplicaciones
Gestores de Software y Sistemas
Representantes de Abastecedores

Alcance de proceso El alcance de la Gestión de Cambios se determina junto con la de Configuración, ya que la Gestión de Configuraciones brinda la información para evaluar el impacto de los cambios. Después de implementar el cambio, la Gestión de Configuraciones actualizará la CMDB. Si la CMDB tiene información sobre mouses y teclados, el reemplazo de un teclado debe contar como cambio. Determinar el alcance es una actividad dinámica, porque el alcance puede variar y por lo tanto la información de la CMDB también cambiará. Por esa razón el alcance tiene que revisarse continuamente, y los modelos de datos de la CMDB deben actualizarse al mismo tiempo. Para garantizar que la Gestión de Cambios y la de Configuración cooperan de manera eficaz, se deben registrar los cambios y la información relacionada con la CMDB. Se puede asumir que una cantidad de tareas de administración de rutina, que están bien definidas y cubiertas por procedimientos (estandarizados), no necesitan del control de la Gestión de Cambios. Ejemplos de tales actividades de rutina incluyen el montaje de cintas para copias de seguridad o la creación de IDs de usuario. En ese caso, las actividades no se procesan como cambio, pero se clasifican como Peticiones de Servicio bajo la Gestión de Incidentes. Una evaluación cuidadosa de los operadores de rutina puede resultar útil para que la Gestión de Cambios no se vuelva demasiado burocrática. Una forma de manejar esto es definir los llamados cambios pre-autorizados (o "categoría 0") que están registrados (preferentemente por los mismos solicitantes) en la base de datos de cambio, pero no necesitan del esfuerzo de los procedimientos de la Gestión de Cambios. Por ejemplo, si por lo general se siguen catorce etapas cuando se contrata personal (establecer una cuenta, instalar su estación de trabajo, crear su cuenta de email, etc.), esta clase de procedimiento de rutina no requiere el escrutinio que merecen los cambios importantes en la infraestructura. Como resultado, estas clases de cambios estándar se convierten en una plantilla repetitiva y se las trata como peticiones de Servicio preautorizadas.

70

Gestión de Servicios TI basado en ITIL

7.2 Objetivo El objetivo de la Gestión de Cambios es garantizar que se utilicen los procedimientos y los métodos estándar para que se puedan manejar los cambios con rapidez, con el menor impacto posible en la calidad de servicio. Todos los cambios deben poder ser identificables, en otras palabras, uno debe poder responder a la pregunta, "¿qué cambió?".

7.2.1 Ventajas Para poder proporcionar servicios TI de manera eficaz, la organización debe ser capaz de manejar gran cantidad de cambios con suavidad y responsabilidad. Las ventajas específicas de la Gestión de Cambios incluyen: -

Reducción del impacto adverso de los cambios en la calidad de los servicios TI. Mejor estimación de los costes de los cambios propuestos. Se tiran atrás pocos cambios y todas los back-outs se implementan con mayor suavidad. Se obtiene mejor información administrativa sobre los cambios, que permite un mejor diagnóstico de las áreas de problema. Mejora en la productividad del usuario a través de servicios TI más estables y perfeccionados. Mejora en la productividad del personal TI, porque no se distraen de sus actividades planificadas por cambios urgentes o procedimientos de back-out. Aumento de la capacidad para adaptarse a cambios frecuentes sin desestabilizar el entorno TI.

7.3 El proceso El proceso de la Gestión de Cambios aprueba o rechaza cada RFC. El Gestor de Cambios posibilita el proceso, pero es el Consejo Asesor de Cambio (CAB) el que toma las decisiones reales sobre los cambios más importantes. El CAB tiene miembros de todas las otras partes de la organización, como así también clientes y abastecedores. La Gestión de Configuraciones es la encargada de dar información sobre el impacto potencial de los cambios propuestos.

Figura 7.2 Posición de la Gestión de Cambios

Las entradas de la Gestión de Cambios incluyen: -

RFCs Información de la CMDB (específicamente el análisis de impacto de los cambios) Información de otros procesos (Base de Datos de Capacidad, información de presupuestos, etc.) Planificación de cambio (Programa Precoz de Cambio: FSC)

Las salidas del proceso incluyen: - Planificación de cambio actualizado (Programa Precoz de Cambio: FSC) - Disparadores de la Gestión de Configuraciones y de Versiones - Agenda CAB, minutas y acciones - Informes de la Gestión de Cambios

71

Gestión de Cambios

La Gestión de Cambios tiene las siguientes relaciones con los otros procesos.

7.3.1 Gestión de Incidentes La Gestión de Incidentes tiene una relación bilateral con la Gestión de Cambios. Por un lado, la Gestión de Cambios pasa los cambios solicitados por la Gestión de Incidentes para que dejen de ser incidentes, o cambios pedidos por la Gestión de Problemas que eliminan la causa raíz de los incidentes. Por otro lado, aunque se tomen muchas precauciones, la implementación de cambios aún puede derivar en incidentes. Estos pueden tener relación con una pobre implementación, o con usuarios que no estaban bien preparados para el cambio. El personal pertinente de la Gestión de Incidentes debe estar informado de la implementación de los cambios, para que puedan identificar y remediar los incidentes relacionados rápidamente.

7.3.2 Gestión de Configuraciones La Gestión de Cambios y de Configuración tienen procesos muy ligados, tanto que los dos procesos se pueden integrar eficazmente, un paso recomendado en la guía del Servicio de Soporte ITIL. Los cambios se registran bajo el control de la Gestión de Configuraciones y también realiza el análisis de impacto de los cambios. La Gestión de Configuraciones identifica las relaciones entre el CI (en el cambio que se dirige) y los otros CIs, para mostrar que se ve afectado por el cambio.

7.3.3 Gestión de Problemas La relación entre la Gestión de Cambios y la de Problemas es muy similar a la que manden en la Gestión de Cambios y la de Incidentes Por un lado los cambios se solicitan generalmente para resolver problemas. Por otro lado, si la implementación de los cambios no se encuentra bien controlada, los cambios pueden derivar en nuevos problemas.

7.3.4 Gestión de Versiones Los cambios a menudo dan como resultado el desarrollo y la implementación de un nuevo conjunto de aplicaciones o infraestructura técnica. La Gestión de Versiones tiene a su cargo esta implementación. La Gestión de Cambios se encarga de controlar el desarrollo de las nuevas versiones de tales sistemas.

7.3.5 Gestión de Niveles de Servicio La Gestión de Niveles de Servicio tiene que determinar el impacto de los cambios en los servicios y los procesos de negocio. Según la situación, la Gestión de Niveles de Servicio puede contar con un representante en el CAB. Si un cambio tiene un impacto muy importante o presenta un gran riesgo, se deberá discutir siempre su implementación y tiempo con el cliente. La Gestión de Cambios informa a la Gestión de Niveles de Servicio a través del informe de Disponibilidad Proyectada de Servicio (PSA). En dicho informe, la Gestión de Cambios enumera los cambios a los SLAs acordados y el impacto del Programa de Cambios a Futuro (FSC) sobre la disponibilidad de servicio.

7.3.6 Gestión de la Disponibilidad La Gestión de la Disponibilidad inicia los cambios que tienden a mejorar la disponibilidad del servicio y verifica si se obtuvo la mejora que se quería. La Gestión de la Disponibilidad también entenderá sobre la estimación del impacto potencial de los cambios, ya que tal impacto podría afectar la disponibilidad del servicio.

7.3.7 Gestión de la Capacidad El Gestor de Capacidad ante todo debe preocuparse por el efecto cumulativo de los cambios a lo largo del tiempo, como el aumento del tiempo de respuesta y la necesidad de mayor capacidad de almacenamiento. Teniendo como base el Plan de Capacidad, la Gestión de la Capacidad propondrá a menudo mejoras y cambios en forma de RFCs.

72

Gestión de Servicios TI basado en ITIL

7.3.8 Gestión de Continuidad de Servicios Tl Se deben controlar siempre las medidas de prevención y los planes de recuperación que garanticen la continuidad de los servicios, ya que los cambios en la infraestructura pueden transformar un plan en algo irrealizable o superfluo. La Gestión de Cambios trabaja junto con la Gestión de Continuidad de Servicios TI para garantizar que la Gestión de Continuidad de Servicios TI conozca todos cambios que pueden afectar los planes de recuperación y pueda así tomar las medidas para asegurar que el plan se complete. Adicionalmente, la Gestión de Continuidad de Servicios deberá ser notificada de todos aquellos cambios que puedan afectar a los CIs o servicios amparados en los planes de continuidad para la revisión y posible modificación de dichos planes.

7.3.9 Actividades de la Gestión de Cambios La Gestión de Cambios utiliza las siguientes actividades para procesar los cambios: -

Registro - no incluida en las actividades de la Gestión de Cambios, pero con ayuda en este proceso, porque la Gestión de Cambios es la responsable de garantizar que todos los cambios sean correctamente registrados. Aceptación - filtrar las RFCs y aceptarlas para mayor consideración. Clasificación - clasificar las RFCs por categoría y prioridad. Planificación - consolidar los cambios, planear su implementación y los recursos necesarios. Coordinación - coordinar la construcción, evaluación e implementación del cambio. Evaluación - determinar si cada cambio fue exitoso y sacar conclusiones para el próximo evento (aprendizaje).

Figura 7.3 Actividades de la Gestión de Cambios

73

Gestión de Cambios

7.4 Actividades 7.4.1 Registro Primero, se deben registrar o anotar todas las RFCs. Cuando se eleva una RFC para solucionar un problema, también se debe registrar el número de error conocido. ¿Qué constituye una RFC? No todas las peticiones de modificación son tratadas como un cambio: algunas tareas administrativas rutinarias que se encuentran bien definidas y están cubiertas por procedimientos (estandarizados) pero que no precisan de modificaciones pueden ser tratadas como Peticiones de Servicio (p. ej. cambios "categoría 0", ver 7.1.1). Esto da como resultado la siguiente clasificación de cambios: -

Cambios Estándar (en calidad de Peticiones de Servicio) - cambios bien definidos y aprobados, que están registrados de manera individual, pero no fueron evaluados por la Gestión de Cambios. Estos cambios se realizan como rutina (Nota: no todos las Peticiones de Servicio son cambios). Cambios no Estándar - todos los otros pedidos de modificación de la infraestructura administrada.

¿Dónde se originan las RFCs? Las RFCs conciernen a todos los aspectos de la infraestructura dentro del alcance de los procesos ITIL. Cualquier persona que trabaje dentro de la infraestructura puede elevar una RFC. Se pueden identificar varias fuentes de RFCs, tales como: -

-

-

74

Gestión de Problemas - propone soluciones para eliminar errores a largo plazo para estabilizar la provisión de los servicios. Clientes - pueden pedir más, menos u otros servicios. Estas peticiones pueden elevarse directamente como RFCs, o se los puede canalizar a través de la Gestión de Niveles de Servicio o de la Gestión de Relaciones con el Cliente TI. Política - los procesos tácticos y estratégicos del Set de Aprovisionamiento de Servicios y del de Gestores puede llevar a RFCs a cambiar los servicios. Por ejemplo, la Gestión de Niveles de Servicio, la Gestión de la Disponibilidad y la Gestión de la Capacidad producen planes anuales para mejorar los servicios, que después se elevarán en forma de RFCs. Legislación - si se imponen nuevos cambios regulatorios a las actividades del negocio, o si se introducen nuevos requisitos por seguridad TI, Continuidad Del negocio o Gestión de Licencias. El proceso correspondiente controla esto. Abastecedores - los abastecedores ponen a la venta nuevas versiones y actualizaciones de sus productos e identifican los errores que corrigieron. También pueden comunicar que ya no ofrecen soporte a ciertas versiones, o que no hay garantías sobre el desempeño de una versión (p. ej. por los problemas del Milenio). Por esta razón la Gestión de Problemas y la Gestión de la Disponibilidad pueden elaborar una RFC. Proyectos - un proyecto siempre provocará un número de cambios. La Gestión de Proyectos deberá coordinar esto con la Gestión de Cambios a través de los procesos pertinentes, tales como Gestión de Niveles de Servicio, Gestión de la Capacidad, etc. El resto del personal TI - en principio todos pueden elevar propuestas para mejorar los servicios. Específicamente, el personal TI puede contribuir al perfeccionamiento de los procedimientos y los manuales.

Gestión de Servicios TI basado en ITIL Registro de RFC Aquí hay algunos ejemplos de la información que se puede incluir en una RFC: -

Número de identificación de la RFC. Número de problema/error conocido asociado (si corresponde). Descripción e identificación de los CIs correspondientes. Motivo del cambio incluyendo la justificación y el beneficio para el negocio. Versión actual y nueva del CI a cambiar. Nombre, ubicación y número de teléfono de la persona que realiza la RFC, Día de emisión. Recursos y tiempo estimados.

7.4.2 Aceptación Después de registrar la RFC, la Gestión de Cambios hará una evaluación inicial para corroborar si alguna de las RFCs son poco claras, ilógicas, poco prácticas o innecesarias. Las que así resulten serán rechazadas, mencionando las razones. La persona que elevó el pedido siempre debe tener notificación de las decisiones tomadas y contar con la oportunidad de defender su petición. Un cambio provoca la modificación de los datos de la CMDB, por ejemplo: -

Un cambio en el estado de un CI existente. Un cambio en las relaciones entre un CI con otros CIs. Un nuevo CI, o la variación de un CI existente. Un nuevo propietario o ubicación del CI. Sí la RFC fuera aceptada, se incluye en un registro del cambio la información necesaria para el resto del procesamiento. Después se agregará la siguiente información al registro: Prioridad signada. Evaluación del impacto de la implementación y de la no implementación del Cambio y de los costes necesarios. Categoría. Recomendaciones del Gestor de Cambios. Fecha y hora de la autorización. Fecha estimada para la implementación del cambio. Planes de soporte. Planes de "marcha atrás". Requisitos de soporte. Plan de implementación. Información sobre el constructor y los que la ejecutan. Fecha y hora real del cambio. Fecha de evaluación. Resultados de la evaluación y problemas observados. Razones por las que se rechazó el pedido (si corresponde). Información sobre el escenario y la evaluación.

7.4.3 Clasificación Una vez que se acepta una RFC, se especifica su prioridad y su orden: -

-

La prioridad indica qué importancia tiene un cambio frente a las otras RFCs, y deriva de la urgencia y el impacto del cambio. Si un cambio se produce para corregir un error conocido, la Gestión de Problemas puede ya haber asignado un código de prioridad. Sin embargo, la Gestión de Cambios asigna el código de prioridad final después de considerar las otras RFCs en proceso. La Gestión de Cambios determina la categoría basándose en los impactos y recursos. Esta clasificación determina si se dará más consideración al pedido, e indica el significado del cambio.

75

Gestión de Cambios Determinación de la prioridad Aquí hay un ejemplo del sistema de prioridad de códigos: -

Baja prioridad - se necesita un cambio, pero puede esperar hasta un mejor momento (p. ej. El próximo lanzamiento, o mantenimiento programado). Prioridad normal - no representa gran urgencia o no implica un impacto importante, pero no se debe diferir el cambio. En la reunión de CAB se le da prioridad normal cuando se asignan los recursos. Prioridad alta - un error grave que afecta a muchos usuarios, o un error poco conveniente que afecta a un gran número de usuarios, o relacionados con otros temas urgentes. En la próxima reunión de CAB se le da la mayor prioridad a este cambio. Prioridad máxima - la RFC se produce por un problema que afecta seriamente el uso de servicios esenciales de los usuarios, o que necesita de un cambio TI urgente (p. ej. nuevas funciones por razones del negocio, una legislación de emergencia o un arreglo rápido que no puede esperar). Los cambios con esta prioridad se clasifican como "cambios de emergencia". Los cambios de emergencia no siguen los procedimientos normales, ya que los recursos deben estar disponibles de inmediato. Se puede necesitar de una reunión de emergencia de CAB o del Comité de Conducción TI. Con tal fin en especial, se debe constituir un CAB/EC (Comité de Emergencia), con autoridad suficiente para tomar decisiones de emergencia. Todos los planes hechos con anterioridad pueden demorarse o interrumpirse.

Los códigos pueden asociarse con números, p. ej. bajo-l/máximo-4. Determinación de la categoría La Gestión de Cambios determina las categorías, si es necesario junto con el CAB, que indica el impacto del cambio y la demanda que tiene para la organización TI. Algunos ejemplos de categorías: -

-

Impacto menor - un cambio que no necesita mucho trabajo. El Gestor de Cambios puede aprobar estos cambios sin presentarlos ante la CAB. Impacto sustancial - un cambio que precisa bastante esfuerzo y que tendrá un impacto sustancial en los servicios. Estos cambios se discuten en la reunión de CAB para determinar el esfuerzo necesario y el impacto potencial. Antes de la reunión, se hace circular la información entre los miembros de la CAB y posiblemente entre los especialistas y los encargados de desarrollo. Impacto mayor - un cambio para el que se necesitará mucho esfuerzo. El Gestor de Cambios necesita autorización previa de la gestión TI o del Comité de Conducción TI, tras el que se envía el cambio a CAB.

Se puede asignar número a los códigos, p. ej. menor=l/mayor=3. Muchos cambios caen dentro de las dos primeras categorías. Además también se deben especificar la clasificación, los grupos que trabajan en la solución, y los servicios afectados por el cambio.

7.4.4 Planes La Gestión de Cambios planifica los cambios utilizando un calendario de cambio, o un Programa de Cambios a Futuro (FSC). El FSC contiene detalles de todos los cambios aprobados y su planificación. Los miembros de CAB aconsejan sobre los cambios planificados, como la disponibilidad de personal, recursos, costes, aspectos de afectación del servicio, y el cliente; todo debe ser considerado. CAB actúa como un comité consejero. La Gestión de Cambios tiene autoridad delegada ya que se pronuncia en representación de la Dirección de TI. Los cambios más importantes pueden necesitar de la aprobación de la Dirección de TI, antes de presentarlos ante CAB.

76

Gestión de Servicios TI basado en ITIL La aprobación del cambio puede constar de tres aspectos: -

Aprobación financiera - análisis coste/beneficio y presupuesto Aprobación técnica - impacto, necesidad y viabilidad Aprobación del negocio - aprobación de los usuarios de las funciones necesarias y el impacto

Para conseguir una planificación eficaz, la Gestión de Cambios debe estar en contacto con las oficinas de proyecto y con todas las otras oficinas de la organización que construyen e implementan los cambios. Es más, se debe prestar especial consideración a las comunicaciones eficaz de la planificación de cambios a nivel horizontal (interdepartamental), en lo posible a través de Programa de Cambios a Futuro (FSC). Política de Cambios Las RFCs pueden combinarse en un único lanzamiento. En ese caso, un solo back-out será suficiente por si algo sale mal. Esta clase de lanzamiento debe considerarse como un único cambio, aún sí incluye muchos cambios. Los lanzamientos pueden planearse con un objetivo funcional para el negocio. Pueden incluir hardware y software, y son implementados por la Gestión de Versiones. Es aconsejable definir la política de esta sección y comunicarla a la organización TI y a los clientes (ver también Gestión de Versiones). La política debe tener como objetivo evitar la ruptura innecesaria con el usuario. Al consultar a los departamentos TI afectados, el CAB puede especificar ventanas de tiempo regulares para implementar los cambios en un horario que minimice el impacto en el servicio. Los horarios más aconsejables son los fines de semana o fuera del horario de oficina, pero siempre dependerá de los servicios afectados y de los niveles de servicio pactados para ellos. De igual manera se pueden establecer horarios en los que no se permitan cambios o en los que se produzcan pocos, como durante las horas de oficina o a fines del año financiero cuando todos los usuarios de los departamentos están haciendo los deberes periódicos. Reuniones del CAB Se debe distribuir la información sobre la planificación de un cambio antes de la reunión CAB. Antes de la reunión también se deben hacer circular los documentos y la información correspondiente sobre los puntos a tratar. El CAB debe tener cierta cantidad de puntos fijos en la agenda de sus encuentros, incluyendo: -

Cambios sin autorización. Cambios autorizados que no han sido remitidos a CAB. RFCs que deben ser evaluadas por los miembros de CAB. Cambios abiertos y cerrados. Evaluaciones de cambios pasados.

Análisis de impacto y los recursos Cuando se estiman los recursos necesarios y el impacto del cambio, los miembros de CAB, el Gestor de Cambios y demás personas involucradas (identificados por CAB) deben tener en cuenta los siguientes aspectos: -

Capacidad y rendimiento de el/los servicio(s) afectados. Fiabilidad y recuperación. Planes de la Gestión de Continuidad de Servicios T I . Planes de back-out. Seguridad. Impacto del cambio en los otros servicios.

77

Gestión de Cambios -

Registro y aprobación. Recursos necesarios y costes (soporte y mantenimiento). Cantidad y disponibilidad de los especialistas necesario. Ciclo de tiempo necesario para el cambio. Nuevos recursos a comprar y evaluar. Impacto sobre las operaciones. Cualquier conflicto con los otros cambios. Impacto de la no implementación del cambio. Los miembros de CAB también pueden aconsejar sobre la prioridad.

7.4.5 Coordinación Los cambios aprobados se comunican a los especialistas de producto que corresponde, quienes pueden luego construir e integrar los cambios. Se evalúan los cambios antes de ser implementados. La Gestión de Versiones puede cumplir un rol importante en la construcción, evaluación, implementación y despliegue de los cambios aprobados. Se debe prestar especial atención a las comunicaciones de los cambios a los grupos de soporte. Construcción No todos los cambios tienen una fase de construcción específica. Por ejemplo, los cambios estándar como la reubicación de un PC pueden planificarse e implementarse de inmediato. La construcción puede incluir la creación de una nueva versión de software, con nueva documentación, manuales, procedimientos de instalación, un plan de back-out, y cambios de hardware. La Gestión de Cambios controla y coordina, y cuenta con la ayuda de la Gestión de Versiones y la administración de línea, que debería trabajar para garantizar que existen los recursos necesarios para implementar los planes. Se deberá redactar un procedimiento de back-out como parte de la entrega de un cambio para revertir el cambio si no ofrece los resultados esperados. La Gestión de Cambios no debe aprobar el cambio en caso de no existir un procedimiento de back-out. Si el cambio impacta en el ámbito del usuario, se debe redactar un plan de comunicaciones y posiblemente de formación. El plan de implementación también se escribe durante la fase de construcción. Los indicadores de rendimiento muestran hasta qué punto el proceso de la Gestión de Cambios es exitoso al manejar los cambios de manera eficaz y eficiente, con el menor impacto adverso posible en el nivel de servicio acordado. Estos indicadores cubren temas tales como: -

La cantidad de cambios que se complete por tiempo, por categoría. Tasa a la que se implementan los cambios. Número de cambios rechazados. Número de incidentes que resultaron de los cambios. Número de back-outs relacionados con los cambios. Coste de los cambios implementados. Correlación entre los recursos estimados y los tiempos contra los reales. Número de cambios urgentes.

Examen El procedimiento de back-out, la implementación de cambio, y los resultados esperados del cambio deben ser evaluados en detalle. Se debe considerar el criterio definido antes por el CAB. En muchos casos, una evaluación por separado del entorno o una evaluación de laboratorio (piloto o maqueta) serán necesarias para la evaluación. Las primeras etapas de la evaluación pueden ser llevadas a cabo por los constructores, pero el cambio no debe implementarse sin alguna clase de evaluación independiente.

78

Gestión de Servicios TI basado en ITIL Esto a menudo se hace de dos formas -evaluación de la aceptación del usuario donde la comunidad del negocio (a menudo el cliente del cambio) evalúa la funcionalidad del cambio, y la evaluación de la aceptación operacional donde aquellos que soportan y mantienen la infraestructura cambiada realizan una evaluación independiente. Se incluirá a las áreas de soporte técnico y al Centro de Servicios que evaluarán la documentación de soporte, backup y procedimientos de recuperación, etc. También son necesarias las instrucciones claras para monitorizar la calidad de la evaluación, y documentar los resultados de la evaluación. Implementación Se puede pedir a cualquier persona en el departamento correspondiente responsable de la gestión de la infraestructura TI que implemente un cambio en la infraestructura. La Gestión de Cambios garantiza que el cambio se realice según lo programado. Debe haber un plan de comunicaciones que indique a quién se tiene que informar del cambio, por ejemplo los usuarios, el Centro de Servicios, la Administración de Redes, etc. Si no se puede evaluar un cambio correctamente, es posible aplicar el cambio a un pequeño grupo de usuarios, y evaluar los resultados antes de su implementación a gran escala.

7.4.6 Evaluación Se deben evaluar los cambios implementados con la posible excepción de los cambios estándar. Si es necesario, el CAB decide si se necesita de un seguimiento. Se deben tener en cuenta los siguientes puntos: • ¿El cambio produjo los objetivos necesarios? • ¿Los usuarios están satisfechos con el resultado? • ¿Hubo efectos colaterales? • ¿Se excedieron los costes y los esfuerzos estimados? Si el cambio fue satisfactorio, se puede cerrar la RFC. Los resultados son incluidos en la Revisión Post Implementación (PIR) o evaluación del cambio. Si el cambio no fue exitoso, entonces se retoma el proceso desde donde surgió el problema, utilizando un planteamiento modificado. A veces es mejor volver atrás y crear una RFC nueva o modificada. Seguir adelante con un cambio infructuoso crea mayores problemas. Los procedimientos con un límite de tiempo automático pueden ayudar a garantizar que no se descuiden las evaluaciones de cambio. Según la naturaleza del cambio, se puede hacer una evaluación después de unos días, o después de meses. Por ejemplo, un cambio en un PC que se utiliza todos los días puede evaluarse pasado unos días, mientras que un cambio en un sistema que se usa solo una vez por semana se puede evaluar pasados los tres meses.

7.4.7 Implementación de cambios de emergencia Por más bueno que sea la planificación, puede haber cambios que demanden prioridad absoluta. Los cambios de emergencia son muy importantes y deben realizarse lo antes posible. En muchos casos, los recursos dedicados a otras actividades deben desviarse de esos cambios. Los cambios urgentes pueden tener un serio impacto en el trabajo planeado. Así, el objetivo es minimizar la cantidad de cambios urgentes o inesperados (prioridad "máxima"). Algunas medidas preventivas incluyen: -

Garantizar que los cambios se pidan a tiempo, antes de que sean urgentes. Al remediar errores debido a cambios con poca preparación, la situación no debe regresar más allá de la versión anterior, el Estado Confiable Previo. Luego, se debe preparar con cuidado una implementación mejor.

A pesar de las medidas antes mencionadas, los cambios urgentes todavía pueden aparecer, y necesitan de procedimientos para tratarlos con rapidez, sin que la Gestión de Cambios pierda control del proceso. Si hay tiempo, el Gestor de Cambios puede organizar una reunión de emergencia del CAB/EC. Si no hay tiempo o si

79

Gestión de Cambios el pedido se realiza fuera de horas de oficina, debe existir un método alternativo para obtener autorización. Esta no debe ser una reunión cara a cara, puede ser una conferencia telefónica. Se menciona un ejemplo en el proceso de Gestión de Incidentes, donde se puede aplicar una reparación de emergencia para resolver un incidente serio. Si el tema es muy serio y la demora es inaceptable, se debe seguir el procedimiento de RFC urgente. Es posible que haya poco tiempo para las evaluaciones normales. Por ejemplo, una estación de trabajo controla una máquina grande que mezcla almidón para hacer píldoras en una fábrica farmacéutica. Si la estación de trabajo no se recupera dentro de una hora después producida la falla, la mezcla de almidón se endurece, y dos personas trabajando con martillos y cinceles tardarán dos semanas para eliminar manualmente el material endurecido. Mientras tanto, la empresa pierde miles de euros por hora por no poder fabricar pastillas. En tal caso, el Gestor de Cambios debe evaluar los riesgos, y decidir sobre la implementación del cambio. Después, se deben completar todas las etapas necesarias del proceso normal para garantizar que las evaluaciones que se evitaron se lleven a cabo, y que se actualicen los archivos (cambiar registros y la CMDB), para garantizar que aún podemos contestar a la pregunta "¿qué cambio?".

7.5 Control del proceso 7.5.1 Informes de gestión La Gestión de Cambios tiende a provocar un balance entre flexibilidad y estabilidad. Se pueden dar informes sobre los siguientes temas para mostrar la situación actual de la organización: -

Número de cambios implementados en un periodo (total y por categoría CI). Lista de las causas de los cambios y RFCs. Número de cambios exitosos implementados. Número de back-outs y sus razones. Número de incidentes relacionados con los cambios implementados (incidentes provocados por y resueltos por los cambios). Gráficos y análisis de tendencias para los periodos que corresponda.

Los indicadores de rendimiento muestran hasta qué punto el proceso de Gestión de Cambios es exitoso en el manejo eficaz y eficiente de los cambios, con el menor impacto posible adverso sobre el nivel de servicio acordado. Estos indicadores cubren temas tales como: -

80

Número de cambios implementados en un periodo (total y por categoría CI). Lista de las causas de los cambios y RFCs. Número de cambios implementados con éxito. Número de back-outs y sus razones. Número de incidentes relacionados con los cambios implementados. Gráficos y análisis de tendencias para los periodos que corresponda.

Gestión de Servicios TI basado en ITIL

7.6 Costes y problemas 7.6.1 Costes -

Costes de personal - en muchos casos, ya hay personal que coordina los cambios. Aún así, se puede incurrir en costes de personal adicionales para cumplir con las tareas del Gestor de Cambios y constituir el Consejo Asesor de Cambio. Sin embargo, hasta cierto punto estos costes se compensarán al aliviar el esfuerzo de coordinación dentro de la organización. En muchos casos, se introduce la Gestión de Cambios para mejorar la calidad de servicio, y los costes adicionales en los que se incurre se clasifican como costes de calidad. Después de una implementación exitosa de la Gestión de Cambios, los costes de coordinación de cambios se ven compensados por una reducción en el coste de resolución de incidentes y problemas.

-

Costes de herramientas - se deben determinar con anticipación los costes de hardware y software. A menudo, al introducir muchos procesos, se compra una herramienta integrada para la Gestión de Cambios, la Gestión de Configuraciones y la Gestión de Incidentes. Cuando se manejan ámbitos TI complejos, se vuelve casi imposible controlar estos procesos administrativos sin tales herramientas.

7.6.2 Problemas Se pueden encontrar los siguientes problemas al introducir la Gestión de Cambios: -

-

-

Los sistemas en los que se utiliza papel son muy difíciles de usar y presentarán demasiados problemas. Puede haber resistencia contra un paraguas de autoridad de Gestión de Cambios que monitorice todos los aspectos de la infraestructura TI. En tal caso, el personal TI debe contar con capacitación para comprender que todos los componentes de la infraestructura TI pueden tener un impacto importante sobre otro, y que los cambios que se aplican a las configuraciones precisan de coordinación total. Pueden haber intentos para implementar cambios sin seguir los procedimientos acordados. Es absolutamente imprescindible que haya una reacción contundente de la organización a tales intentos. La integridad de los procesos de la Gestión de Cambios dependen del cumplimiento total. Las quejas del personal sobre las sugerencias para mejorar los procesos de la Gestión de Cambios deben ser toleradas y bienvenidas, respectivamente, pero la falta de cumplimiento debe tratarse con decisión o el proceso se arruinará. Otros medios para garantizar el cumplimiento de los procedimientos de la Gestión de Cambios incluyen:
Llevar a cabo auditorías regulares, en lo posible por un auditor independiente, para evaluar el cumplimiento de los procedimientos de la Gestión de Cambios.
Supervisión administrativa del personal de soporte interno y externo y de los que desarrollan la actividad.
Garantizar el control de todos los CIs y las versiones protegiendo la CMDB y conviniendo que la Gestión de Configuraciones realice Auditorias de Configuración regulares.
Garantizar que la Gestión de Incidentes informe si los usuarios tienen acceso a hardware y software que no está incluido en la CMDB.
Incorporar las condiciones y los procedimientos en los contratos con los abastecedores externos.
Nombrar un Gestor de Cambios con mucha experiencia y suficiente conocimiento del negocio (este aspecto es por lo general poco valorado) y técnico.
Conseguir a la persona correcta para el rol es crucial y no debe descuidarse como generalmente es el caso.

7.6.3 Sugerencias Algunos problemas se pueden controlar implementando las siguientes sugerencias: -

Garantizar que todos los cambios sigan el procedimiento completo. Comunicarse con todo el personal TI y con todos los abastecedores para asegurarse que aceptan la Gestión de Cambios, y que no se tratan de implementar cambios sin coordinación. Asegurar que se están evaluando los cambios. Trabajar con la Gestión de Configuraciones para garantizar que se introduzcan los cambios de la CI en la CMDB.

81

Gestión de Cambios

82

Gestión de Servicios TI basado en ITIL

Capítulo 8: Gestión de Versiones 8.1 Introducción Dado que las organizaciones se vuelven cada vez más dependientes de los procesos TI, la monitorización eficaz y la protección de estos procesos también se vuelve más importante. Como la tasa de cambio también sigue creciendo, hay una mayor necesidad de mantener los cambios bajo control. Los cambios en la infraestructura TI se producen en un ambiente complejo y distribuido. En las aplicaciones cliente/servidor, esto afecta tanto al cliente como al servidor. La liberación e implementación de hardware y software exigen una preparación cuidadosa en estos casos. Una Versión (release) es un conjunto de Elementos de Configuración (CIs) nuevos y/o cambiados que están evaluados y homologados y que se introducen juntos en el entorno productivo. La versión viene definida por la RFC que implementa. La Gestión de Versiones (Release Management) se establece como un proyecto planeado para implementar los cambios en los servicios TI, y dirige todos los aspectos, técnicos y no-técnicos, de los cambios. La Gestión de Versiones tiende a garantizar la calidad del entorno de producción utilizando procedimientos formales y verifica cuándo se implementan nuevas versiones. La Gestión de Versiones se encarga de la implementación, a diferencia de la Gestión de Cambios que se ocupa de la verificación. La Gestión de Versiones trabaja muy de cerca con la Gestión de Configuraciones y con la Gestión de Cambios, para garantizar que la CMDB en común se actualice con cada versión. La Gestión de Versiones también garantiza que los contenidos de las versiones se actualicen en la Biblioteca de Software Definitiva (DSL). La CMDB también sigue el rastro de las especificaciones de hardware, instrucciones de instalación, y configuraciones de red. Los stocks de hardware, en particular de configuraciones básicas estandarizadas, se almacenan en el Depósito de Hardware Definitivo (DHS). Sin embargo, por lo general, la Gestión de Versiones pone mayor foco en el control del software que del hardware. En grandes proyectos en particular, la Gestión de Versiones debe formar parte de todo el plan de proyecto para garantizar fondos. Se puede asignar un presupuesto anual fijo para las actividades de rutina tales como cambios menores. Aunque habrá costes relacionados cuando se establezcan los procesos, éstos son menores si se los compara con los costes potenciales asociados con planificación y control del software y hardware insuficiente, como pueden ser: -

Interrupciones importantes por la escasa planificación de las versiones de software. Duplicación del trabajo porque hay copias de las diferentes versiones. Uso ineficaz de los recursos porque nadie sabe dónde encontrarlos. Pérdida de archivos fuente, lo que significa que hay que comprar o desarrollar software otra vez. Falta de protección contra los virus, lo que implica que hay que descontaminar la red.

83

Gestión de Versiones

8.1.1 Conceptos básicos Versiones Las versiones comprenden uno o más cambios autorizados. La primera subdivisión se basa en el nivel de versión. Las versiones a menudo se dividen en: -

-

Versiones mayores - lanzamiento importante de hardware y software, generalmente derivado de modificaciones substanciales en las funcionalidades. Estas versiones suelen eliminar gran cantidad de errores conocidos, incluyendo soluciones temporales y soluciones rápidas. Versiones menores de software y actualizaciones de hardware - éstas por lo general incluyen mejoras menores y soluciones a errores conocidos. Algunas de estas correcciones pueden haber sido implementadas anteriormente como reparaciones de emergencia (hotfixes), pero ahora quedan incluidas dentro de la versión. Estas versiones también aseguran que el "Estado Confiable Previo", el punto de comienzo de todas las evaluaciones, sea actualizado. Reparaciones de emergencia - normalmente implementado como una reparación rápida para un problema o error conocido.

Unidades de versión Cuando estamos reuniendo en cuenta el hardware dentro del control de gestiones normalmente surgirá la cuestión de si se cambiarán o controlarán los PCs completos o se llegará al nivel de detalle de placa, discos, memorias, etc. Así mismo, cuando nos referimos al software, los cambios se pueden realizar a nivel de sistema, suite, programa o a nivel de modulo. Un buen ejemplo es la DLL (Biblioteca de Vínculos Dinámicos) en el entorno Windows, que a menudo es compartida por varios programas. A veces, se obtiene una versión de la DDL con un paquete, que puede necesitar de una reevaluación de todos los otros paquetes de software. Este proceso también desarrolla políticas sobre el contenido mínimo de una versión. Identificación de la versión Las copias del software se pueden distribuir desde la DSL hacia los otros entornos que corresponda: -

-

Entorno de desarrollo - el desarrollo de una nueva versión se puede derivar de una versión anterior de la DSL. El número de versión se incrementa con cada nueva versión. El software sólo se puede cambiar en el entorno de desarrollo. Entorno de pruebas - es el ambiente para probar las versiones. A menudo se divide en pruebas técnicas que hacen los desarrolladores, pruebas funcionales realizadas por usuarios, pruebas de implementación hecha por desarrolladores de versión, y posiblemente una prueba de aceptación final entre los usuarios y la organización administrativa. Entorno de producción - el entorno en vivo donde se ponen a disposición del usuario los sistemas de información. Archivo - tiene versiones más viejas de software que ya no están en uso.

Dado que pueden estar disponibles muchas versiones, se les otorga identificadores únicos. La identificación de versión debe hacer referencia al CI pertinente e incluir un número de versión de dos o más dígitos, por ejemplo: -

Versiones importantes - sistema de nómina v. 1, v.2, v.3, etc. Versiones menores - sistema de nómina v. 1.1, v. 1.2, v. 1.3, etc. Versiones por arreglos de emergencia - sistema de nómina v. 1.1.1, v. 1.1.2, v. 1.1.3, etc.

La Figura 8.1 muestra la prueba y la posible modificación de cada nueva versión antes de su liberación. Como parte de esta liberación, la versión anterior es archivada por si resulta necesario un backout.

84

Gestión de Servicios TI basado en ITIL

Figura 8.1 Gestión de Versiones

Figura 8.2 Back-out de Gestión de Versiones

Tipos de versión Se debe estimar la cantidad de cambios que se pueden desarrollar, probar e implementar durante un cierto periodo. Un Paquete de Versiones, una combinación del número de cambios en un solo rollout, puede ser muy complejo para implementarlo de manera segura. El rápido desarrollo de nuevas versiones de hardware y software en el mercado significan que una versión puede ser viejo antes de que se lo pueda liberar. Por otro lado, los cambios frecuentes pueden tener un impacto adverso en el servicio. La Gestión de Cambios debe decidir el número de cambios que se pueden incluir en una versión, y de qué manera se implementará el rollout. La Gestión de Cambios puede seleccionar alguna de las siguientes opciones: -

-

-

Versión Delta - una Versión Delta sólo incluye hardware y software cambiado. Esto por lo general se relaciona con una reparación de emergencia o una reparación rápida. La desventaja de este tipo de versiones es que no siempre es posible probar todos los vínculos con el resto del entorno, y que los módulos que ya no usa el software no se borran. Una versión Delta resulta apropiada en caso de que se pueda separar el software del resto del ambiente TI. La ventaja de una Versión Delta es que da menos trabajo establecer el ambiente de prueba. Versión Completa - una Versión Completa significa que el programa se distribuye entero, incluyendo los módulos que no fueron cambiados. Esta vía es muy aconsejable cuando no está claro qué se cambió. Se probará en detalle el hardware y el software y habrá menos incidentes después de la implementación. Cuando se prepara una Versión Completa resulta más fácil juzgar si se alcanzarán los criterios de rendimiento esperados. La ventaja de una Versión Total es que se pueden implementar simultáneamente varios cambios. La preparación será más fácil ya que se pueden utilizar los script de instalación estándar. Durante la instalación también se puede aprovechar para limpiar el entorno de usuario. Sin embargo, una Versión Total requiere de una mayor preparación y más cantidad de recursos que una Versión Delta. Paquete de Versiones - un Paquete de Versiones es un conjunto de versiones (ya sean mayores o menores) agrupadas en un único paquete. Hace énfasis en largos períodos de estabilidad para los usuarios. El arreglo de errores menores de software, con los que los usuarios pueden vivir, y la incorporación de nuevas funcionalidades son actividades que a menudo se pueden combinar eficazmente. De igual manera, las actualizaciones programadas, por ejemplo de software de terceras partes como el software de sistema y las aplicaciones de ofimática son las que por lo general se tratan con un Paquete de Versiones.

85

Gestión de Versiones

Figura 8.3 Tipos de Versiones

Biblioteca de Software Definitiva (DSL) La Biblioteca de Software Definitiva (DSL) es un depósito seguro que contiene las versiones autorizadas definitivas (copias master) de todo el software de los CIs. La DSL puede estar físicamente en muchos lugares y comprende cierta cantidad de espacios securizados y cajas fuertes a prueba de incendios. La Gestión de Versiones cubre el ciclo de vida del software desde el momento que se incorpora a la DSL. Las versiones se construyen con el software homologado en la DSL. Después se desarrollan los scripts de instalación y se pueden estampar los CDs en ambientes descentralizados. La DSL puede incluir muchas versiones del mismo software, incluyendo versiones, documentación y códigos fuente archivados. Por tal motivo, la DSL debe ser respaldada a menudo, ya que no sólo contiene la versión actual sino también las versiones de back-out anteriores. Si hay muchos lugares con administración local, entonces cada lugar tendrá una copia de las DSL para hacer el despliegue del software. Depósito de Hardware Definitivo (DHS) El Depósito de Hardware Definitivo tiene repuestos y stock de hardware. Estos son componentes de repuestos y montajes que se mantienen en el mismo nivel que sus contrapartes en el ambiente en vivo. El hardware de la DHS se usa para reemplazar o reparar configuraciones similares en la infraestructura TI. Los detalles de la composición de estas configuraciones deben incluirse en la CMDB. Base de Datos de la Gestión de Configuraciones (CMDB) Durante todas las actividades de la Gestión de Versiones, es aconsejable verificar la información sobre los CIs en la CMDB. Cuando las versiones de software se incorporan en la DSL, y se incorporan las versiones de hardware en la DHS, también se actualizan los detalles de la CMDB. Para ayudar a la Gestión de Versiones, la CMDB debe contener detalles sobre: -

Los contenidos de las versiones, incluyendo CIs de hardware y software con referencia a la RFC original. CIs de hardware y software que pueden sufrir algún impacto por una versión. Detalles de la ubicación física del hardware cubierto por la versión.

Todo esto implica directamente que el nivel de detalle que se mantenga a nivel de Unidad de Versión debe de estar mapeado correctamente con el nivel de detalle que mantengamos en la CMDB.

86

Gestión de Servicios TI basado en ITIL

8.2 Objetivos La Gestión de Versiones maneja y distribuye versiones de software y hardware utilizados para la producción, que el departamento TI soporta, para proporcionar el nivel de servicio necesario. Los objetivos de la Gestión de Versiones incluyen: -

-

Planificación, coordinación e implementación (o disposición de la implementación) de software y hardware. Diseño e implementación eficaz de procedimientos para distribuir e instalar los cambios en los sistemas TI. Garantizar que el hardware y software relacionado con los cambios sean rastreables y seguros, y que sólo se instalen las versiones correctas, autorizadas y probadas. Comunicarse con los usuarios y considerar sus expectativas durante la Planificación y despliegue de las nuevas versiones Determinar la composición y planificación de un despliegue junto con la Gestión de Cambios. Implementar nuevas versiones de software y hardware en la estructura operativa, bajo el control de la Gestión de Cambios, y con el soporte de la Gestión de Configuraciones. Una versión puede incluir un número de CIs relacionados y, además del hardware y software, documentación como informes, planes y manuales del usuario y de soporte. Asegurar que las copias originales de software y su documentación legal o de licencias se encuentren bien almacenadas en la Biblioteca de Software Definitiva (DSL) y que la CMDB esté actualizada; lo mismo aplica al hardware en la DHS.

8.2.1 Ventajas Junto con la Gestión de Configuraciones y la Gestión de Cambios eficaces, la Gestión de Versiones ayuda a garantizar que: -

El software y el hardware en producción son de alta calidad, porque son desarrollados y probados bajo control de calidad antes de ser liberados. Se minimiza el riesgo de los errores en las combinaciones de software y hardware o la liberación de una versión incorrecta. El negocio maneja con cuidado sus inversiones de software, de las que depende. Hay menor cantidad de implementaciones separadas, y se prueba cada implementación en detalle. Se reduce el riesgo de los incidentes y los errores conocidos al probar y controlar la implementación. Los usuarios se ven más involucrados en la prueba de una versión. Se publica por adelantado un calendario de liberaciones (roadmap); por lo tanto, las expectativas de los usuarios están más en línea con las versiones en producción. El negocio tiene un diseño y construcción de software y hardware central, o la obtención de medios, seguido de la distribución a Las ubicaciones de producción. El negocio puede estandarizar las versiones de software y hardware entre las diferentes ubicaciones, para brindar un soporte de mayor calidad. Se reduce el riesgo del software ilegal, además del riesgo de los incidentes y problemas provocados por las versiones equivocadas o infectadas que se introducen en el ambiente en vivo. Se detectan con más facilidad las copias no autorizadas y las versiones equivocadas.

8.3 El proceso El proceso de la Gestión de Versiones incluye las siguientes actividades: -

Política y planificación de liberación de versiones. Construcción y configuración versiones. Prueba y aceptación de la versión. Planificación del despliegue. Comunicaciones, preparación y capacitación. Distribución e instalación de la versión.

87

Gestión de Versiones

Estas actividades no son cronológicas. La política de liberación de versiones y la planificación se hacen cada 6 meses o un año, mientras que las otras actividades se hacen por lo general a diario.

Figura 8.4 Gestión de Versiones

El éxito de la Gestión de Versiones depende de las entradas y de la cooperación con los otros procesos ITIL (Figura 8.4). Las interfaces más importantes son con los siguientes procesos:

8.3.1 Gestión de Configuraciones La Gestión de Configuraciones es responsable de registrar las versiones de software y hardware registradas en la CMDB como configuraciones básicas. El software agregado en la DSL y el hardware para la DHS están registrados en la CMDB a un nivel de detalle acordado. El estado de la monitorización provisto en la Gestión de Configuraciones indica el estado de cada CI, por ejemplo "uso en vivo", "a prueba", "en stock" o "archivada".

8.3.2 Gestión de Cambios La Gestión de Cambios controla la distribución. La Gestión de Cambios también es responsable de garantizar que se prueba adecuadamente la versión. Esta Gestión también decide cuántos cambios se pueden combinar en una única versión. La Gestión de Cambios describe los procedimientos para garantizar que los cambios están autorizados, incluyendo el análisis de impacto y el análisis de los recursos necesarios. En muchos casos, la Gestión de Versiones es responsable de la implementación de los cambios de software y hardware, y por lo general tiene un lugar en el Consejo Asesor de Cambios (CAB).

8.3.3 Gestión de Niveles de Servicio Un servicio TI generalmente consiste en la provisión de infraestructura de hardware junto con software estándar o software desarrollado en casa. La Gestión de Versiones es responsable de poner a disposición el hardware y el software y de manejarlo. La Gestión de Versiones monitoriza los acuerdos sobre la disponibilidad del software pactados en el proceso de la Gestión de Niveles de Servicio.

88

Gestión de Servicios TI basado en ITIL

8.3.4 Actividades de la Gestión de Versiones La figura 8.5 muestra las actividades de la Gestión de Versiones y sus vínculos con el ciclo de vida de un cambio.

Entorno de Desarrollo

Política y planificación de liberación de versiones

Diseño y desarrollo o orden y compra

Entorno de Prueba Gestión de Versiones Construcción Prueba y y aceptación configuración de la de versiones versión

Planificación del despliegue

Comunicación, preparación y capacitación

Entorno Vivo

Distribución e instalación de la versión

Biblioteca de Software Definitiva (DSL) Depósito de Hardware Definitivo (DHS) Base de Datos de la Gestión de Configuraciones (CMDB) Figura 8.4 Actividades de la Gestión de Versiones

8.4 Actividades 8.4.1 Política y planificación de liberación de versiones La Gestión de Versiones desarrolla una política de versiones para definir cómo y cuándo se configuran y despliegan las versiones. Las versiones más importantes se pueden planificar por adelantado, junto con la identificación o número de versión, para que se puedan considerar los cambios adicionados con el tiempo correcto. El Gestor de Versiones también especifica a qué nivel se pueden distribuir unos CIs independientemente de otros (unidades de versión). Esto depende de: -

El impacto potencial de la versión sobre los otros componentes. La cantidad de horas/hombre y el ciclo para construir y probar los cambios por separado comparándolo con el esfuerzo asociado para juntarlos e implementarlos simultáneamente. La dificultad de la instalación en los puestos de trabajo de los usuarios. Puede resultar más fácil instalar un programa completo porque se dispone de las técnicas o herramientas estándar para ello. La complejidad de las dependencias entre el software, hardware nuevo y el resto de la infraestructura TI cuanto más fácil es separar el hardware del software, más fácil es probarlo.

Antes de planificar una versión, se debe recopilar información sobre el ciclo de vida del producto, los productos a entregar, la descripción de los servicios TI y los niveles de servicio correspondientes, la autorización de las RFCs pertinentes, etc. Al plantear una versión se deben considerar los siguientes puntos: -

Coordinación del contenido de la versión. Acuerdo sobre el programa, los lugares y las unidades organizativas. Diseño del programa de liberación de versión. Diseño del plan de comunicaciones. Visitas a las diferentes ubicaciones para determinar qué hardware y software están en uso. Acuerdos al respecto de roles y responsabilidades. Obtener cotizaciones y negociar con los abastecedores sobre el hardware, software y los servicios de instalación y quizás de soporte. Diseño de planes de back-out. Diseño de un plan de calidad para la versión. Planificar la aceptación de la versión en la organización administrativa y con los usuarios.

89

Gestión de Versiones Los resultados de esta actividad son parte del plan de cambio, e incluyen planes para el despliegue, planes de prueba y criterios de aceptación.

8.4.2 Diseño, construcción y configuración Es aconsejable desarrollar procedimientos estándar para diseñar, construir y configurar las versiones. Una versión puede basarse en los sets de componentes (CIs) desarrollados en casa o adquiridos de terceras partes y configuradas. Las instrucciones de instalación y las instrucciones para configurar las versiones también deben tratarse como parte de la propia versión, y deben incluirse como CIs bajo el control de la Gestión de Cambios y la Gestión de Configuraciones. Es aconsejable establecer y probar todo el hardware y software en un "laboratorio" antes de instalarlo en el lugar. Los componentes de software y hardware de una versión deben estar bien configurados y registrados para que sean reproducibles. Se deben diseñar las instrucciones de operación para garantizar que se combine el mismo conjunto de componentes siempre. A menudo se reserva el hardware estandarizado que sólo se utiliza para compilar o crear imágenes. Es preferible que esta parte del proceso sea automático para que sea más confiable. Naturalmente la Gestión de Versiones cubre el software y el hardware necesarios para esto. En los entornos de desarrollo de software, esta actividad se conoce como Gestión de Construcción y se encuentra bajo la responsabilidad de la Gestión de Versiones. Plan de back-out Un plan de back-out a nivel versión Completa define las actividades necesarias para recuperar el servicio si algo sale mal. La Gestión de Cambios es la responsable del diseño de los planes de backout, sin embargo la Gestión de Versiones tiene que ayudar a que los planes de back-out sean prácticos. En particular cuando se implementa un Paquete de Versiones que combina muchas RFCs, puede ser necesario coordinar los distintos planes de back-out para la versión. En caso de que algo salga mal con la versión total o una versión Delta, es aconsejable regresar por completo la versión al Estado de Confiabilidad Previo. Si una versión no puede volverse atrás totalmente, también deben existir planes de Recuperación ante Desastres para restablecer el servicio. Es aconsejable cumplir con los requisitos del plan de back-out por adelantado, como la creación de backups y la provisión de servidores de repuesto. Para dirigir el caso donde la implementación podría llevar más de lo esperado, y donde tal atraso pusiera en peligro la normal provisión de los servicios, el plan de back-out también puede incluir las fechas límites para mostrar cuándo se debe comenzar el back-out para restaurar el servicio a tiempo (por ejemplo antes del lunes a la mañana, 7:00 de la mañana). Estas fechas límites se conocen como "punto de no retorno", ya que si cruzamos este límite seremos incapaces de completar las actividades de back-out a tiempo para no afectar a la provisión normal del servicio dentro del marco de disponibilidad acordado en los SLAs. Se debe incluir un plan de back-out en el análisis de riesgo del cambio, y los usuarios tienen que aceptar el plan. La construcción real de la versión puede incluir la compilación y la vinculación de los módulos de software, o la introducción de datos de prueba o datos como tablas de códigos zip, tarifas de impuestos, zonas horarias y

90

Gestión de Servicios TI basado en ITIL tablas de monedas además de información del usuario. Para esto se utilizan scripts de instalación automáticos, que se almacenan en la DSL junto con los planes de backout. Las versiones completas se deben identificar en la CMDB como configuraciones estándar para facilitar sus configuraciones en el futuro. Los planes de prueba cubren la prueba y la aceptación de la calidad del software, hardware, procedimientos, instrucciones de operación y scripts de rollout antes de la versión, y posiblemente las pruebas de evaluación después de la versión. También se deben probar los scripts de instalación. La información necesaria para esta actividad incluye: -

Definición de la versión. Programa de despliegue. Instrucciones para configurar y construir la versión. Descripción de los elementos a comprar u obtener licencia, y el plan de obtención de estos elementos. Scripts de instalación automáticos y planes de prueba. Copias fuente del software para su incorporación a la DSL. Planes de back-out.

8.4.3 Prueba y aceptación de la versión Un conjunto deficiente de pruebas es la causa más común de cambios y versiones no satisfactorios. Para advertir esto, antes de la implementación, la versión debe someterse a una prueba funcional de los representantes de los usuarios y una prueba operativa por parte del personal de gestión TI que considerará la operación técnica, las funciones, el aspecto operativo, el rendimiento, y la integración con el resto de la infraestructura. Las pruebas también deben incluir los scripts de instalación, los procedimientos de back-out, y cualquier cambio a los procedimientos de administración. Se debe elevar a la Gestión de Cambios una aceptación formal para cada etapa. La última etapa es aprobar la versión para su despliegue. La Gestión de Cambios debe coordinar la aceptación formal de los usuarios y el "sign-off" de los desarrolladores, antes de que la Gestión de Versiones empiece con el despliegue. Las versiones deben aceptarse en un ambiente de pruebas controlado, que consiste en configuraciones básicas similares a las del entorno final productivo. Esta situación de base para la versión debe detallarse en su definición. Se deben registrar las configuraciones básicas en la CMDB. Si no se acepta la versión se envía de vuelta a la Gestión de Cambios. Los resultados de esta actividad incluyen: -

Procedimientos de instalación probados. Componentes de versión probados. Errores conocidos y defectos de la versión (que deben set incluidos en la documentación operativa). Resultados probados. Documentación de administración y soporte. Lista de sistemas afectados. Instrucciones de operación y herramientas de diagnóstico. Planes de contingencia y planes de back-out probados. Programa de capacitación para el personal, los gestores y los usuarios. Documentos de aceptación firmados. Autorización de cambio para la versión.

91

Gestión de Versiones

8.4.4 Planificación de la implementación El plan de liberación de versiones diseñado durante las etapas previas se complementa ahora con información sobre las actividades de implementación. El plan de despliegue (rollout) incluye: -

Diseño de un programa y lista de tareas y recursos humanos necesarios. Creación de una lista de CIs a instalar y borrar, y la forma en que se deben borrar. Diseño de un plan de actividad para cada ubicación afectada por la implementación, considerando los tiempos de despliegue disponibles, y para una organización internacional, las zonas horarias. Envío de notificaciones de liberación de versión y otras comunicaciones a las partes que corresponda. Compra, almacenamiento seguro, e identificación y registro de todos los nuevos CIs en la CMDB para esta versión. Programación de reuniones con la gestión, los departamentos administrativos, la Gestión de Cambios, y los representantes de los usuarios.

Existen muchas formas de implementar un despliegue: -

La versión se puede desplegar por completo a toda la organización -el modelo Big Bang. La versión se puede desplegar por etapas, combinando varias opciones:
Incrementos funcionales, donde todos los usuarios al mismo tiempo consiguen nuevas funciones.
Incrementos por localización, donde se trata con los grupos de usuarios.
Evolutivo, donde las funciones se expanden en etapas.

8.4.5 Comunicaciones, preparación y capacitación El personal que tiene contacto con los clientes (Centro de Servicios y Gestión de Relaciones con el Cliente), el personal operativo, y los representantes de las organizaciones de usuarios deben conocer los planes, y cómo éstos afectarán su rutina de actividades. Esto se puede implementar a través de sesiones de capacitación en conjunto, cooperación, y su participación conjunta en la aceptación de las versiones. Se deben comunicar las responsabilidades, y se debe verificar que todos sean conscientes de ellas y las hayan asumido. Si el despliegue se hace en etapas, los usuarios deben saberlo y es necesario comunicarles los planes y cuándo podrán hacer uso de las nuevas funciones. Los cambios en los Acuerdos de Nivel de Servicio (SLA), en los Acuerdos de Nivel de Operaciones (OLA) y los Contratos de Soporte (UC) deben ser comunicados al personal pertinente por adelantado.

8.4.6 Distribución e instalación de versiones La Gestión de Versiones monitoriza los procesos de logística para la compra, el almacenamiento, transporte y entrega del software y hardware. El proceso tiene el soporte de procedimientos, registros, y documentos como los visados de los paquetes, para que la Gestión de Configuradotes tenga una información fiable. Las instalaciones para almacenar hardware y software deben ser seguras y solo el personal autorizado debe tener acceso a las mismas. Donde sea posible es recomendable utilizar herramientas automáticas para distribuir el software y la instalación. Esto reducirá el tiempo necesario para la distribución, e incrementará la calidad y no requerirá de mayores recursos. En general estas herramientas también facilitarán la verificación de una instalación exitosa. Antes de comenzar con la instalación, es aconsejable verificar que el ambiente donde se va a realizar el despliegue cumpla con las condiciones, tales como espacio de disco suficiente, seguridad, controles ambientales o limitaciones como aire acondicionado, espacio en el suelo, UPS / energía, tomas de corriente y de red, etc. Después de la instalación se debe actualizar la CMDB para facilitar la verificación de cualquier información al respecto del despliegue.

92

Gestión de Servicios TI basado en ITIL

8.5 Costes y problemas 8.5.1 Costes Los costes de la Gestión de Versiones incluyen: -

Costes de personal. Costes de almacenamiento para la DSL y la DHS, entornos de construcción, prueba y distribución. Costes de las herramientas de software y hardware necesario.

8.5.2 Problemas Se pueden presentar los siguientes problemas: -

-

-

Resistencia al cambio - al principio puede haber algo de resistencia entre el personal acostumbrado a los métodos familiares. Por ejemplo les puede resultar difícil aceptar que para ciertas actividades recibirán instrucciones de otra área. Para despejar sus ideas, tendrán que ser informados sobre las ventajas de la utilización de ITIL como marco de referencia. Evitar la Gestión de Versiones - el software no autorizado puede traer virus a la organización, afectar seriamente los servicios, y hacer más difícil el soporte. Se deben tomar acciones firmes con el personal y los usuarios, en particular en el entorno PC, que intenten utilizar o instalar software no autorizado. En este aspecto, muchas veces será más interesante restringir las capacidades de los usuarios para la utilización o instalación de software que fiscalizar estas actividades. Para ello será necesario demostrar a los usuarios los costes ocultos de la no utilización de estas normativas, ya que para ellos normalmente los costes de TI no son apreciables y la población de usuarios en el entorno PC suele ser muy elevada (lo que multiplica el factor de impacto de estos costes ocultos) Reparaciones de Emergencia - no se debe evitar la Gestión de Versiones, aún cuando sea necesario un cambio urgente. Distribución - si se libera software en distintas ubicaciones, se debe garantizar que sea de una forma sincronizada, para prevenir la aparición de versiones diferentes en las diferentes localizaciones. Carencia de Entorno de Pruebas - si no se cuenta con el entorno de pruebas adecuado puede ser difícil evaluar correctamente las nuevas versiones o el nuevo software antes del despliegue.

93

Gestión de Versiones

94

Gestión de Servicios TI basado en ITIL

Capítulo 9: Centro de Servicios 9.1 Introducción El Centro de Servicios (Service Desk) juega un rol importante en la ayuda al usuario. Un Centro de Servicios completo y a pleno es como la oficina central de los otros departamentos, y puede tratar las consultas de los clientes sin necesidad de personal especializado. Para el usuario, el Centro de Servicios es el único punto de contacto con la organización TI, que garantiza que encontrará la persona correcta para ayudarlo con su tema o consulta. En otras palabras, los usuarios no deben pasarse horas buscando a alguien que les ayude a solucionar sus problemas. A menudo, el Centro de Servicios también hace el seguimiento de las llamadas que se originan dentro de la organización TI. Por ejemplo, los incidentes que se detectan dentro del departamento (automáticamente o por personal), y pide el servicio que viene de la misma organización TI. Este capítulo es diferente del resto del libro porque aquí nos centramos en una función, unidad organizativa, o un departamento, mientras que el resto del libro trata de procesos. Se incluye el tema porque el Centro de Servicios juega un rol esencial en la Gestión de Servicios TI. Para hacer un enfoque global de las actividades, hablamos de Centro de Servicios en vez de Help Desk (Centro de Soporte), como se hizo durante mucho tiempo. El Help Desk por lo general se dedicaba al proceso de incidentes, en tanto que el Centro de Servicios cubre un rango de actividades de soporte más amplio. El Centro de Servicios maneja actividades relacionadas con una serie de procesos ITIL: -

El proceso primario es la Gestión de Incidentes ya que el Centro de Servicios registra y monitoriza muchos incidentes, y muchas llamadas del Centro de Servicios se relacionan con los incidentes. Esto incluye la coordinación de actividades de terceros involucrados en el manejo de incidentes. Se puede dar al Centro de Servicios la responsabilidad de instalar software y hardware y por lo tanto tiene un rol en la Gestión de Versiones o la Gestión de Cambios. Si cuando se registra un incidente, el Centro de Servicios verifica los detalles del que llama y sus recursos TI, el Centro de Servicios tiene funciones en la Gestión de Configuraciones. El Centro de Servicios puede tomar actividades relacionadas con peticiones estándar, como la instalación de conexiones LAN y la reubicación de las estaciones de trabajo. En ese caso contribuirá a la evaluación de los cambios y se involucrará con la Gestión de Cambios. El Centro de Servicios puede informar a los usuarios sobre los productos que tienen soporte y sobre los servicios a los que tienen derecho. Si el Centro de Servicios no está autorizado a satisfacer una consulta, debe informarlo con educación al usuario y notificar de la consulta a la Gestión de Niveles de Servicio.

Figura 9.1 Procesos del Centro de Servicios

95

Centro de Servicios El Centro de Servicios maneja actividades relacionadas con ITIL, p. ej. Gestión de Infraestructura (Operaciones). El Centro de Servicios mantiene contacto con los clientes a través de promociones y provisión de información sobre los servicios. El Centro de Servicios resulta una herramienta excelente para los contactos diarios con los usuarios para hacer un seguimiento de la satisfacción del cliente.

9.2 Objetivos El objetivo del Centro de Servicios es dar soporte a la provisión de los servicios acordados, garantizando acceso a la organización TI y comprometiéndose con un cierto número de actividades (de varios procesos). Al ser un punto de contacto inicial, el Centro de Servicios reduce la cantidad de trabajo de los otros departamentos TI interceptando preguntas irrelevantes y aquéllas que son fáciles de contestar. El Centro de Servicios actúa como filtro que sólo permite que pasen a un segundo o tercer nivel si resulta necesario. Como punto de contacto inicial siempre actúa de manera profesional al tratar con los usuarios y garantiza que no tengan que buscar eternamente la solución. De esta forma se garantiza que siempre habrá alguien responsable de la llamada (consulta, incidente, petición, etc.), mientras que en organizaciones en las que no existe esta figura, es el propio usuario quien tiene que mantenerse al día con el estado de su consulta y, en el caso de haber contactado con la persona equivocada, buscar quién es la persona correcta y tratar de contactar con él.

9.3 Estructura 9.3.1 Accesibilidad Una de las mayores tareas del Centro de Servicios es garantizar la accesibilidad de la organización TI. Se debe animar a los usuarios a que llamen al Centro de Servicios si tienen alguna pregunta o si necesitan ayuda. La forma en que se procesan las llamadas se pueden monitorizar con registros producidos por la central telefónica y analizarse mediante aplicaciones específicas de ACD. Para dar impresión de fiabilidad, el Centro de Servicios debe ser consistente y eficaz en el contacto con el cliente. Se puede dar soporte con procedimientos basados en cuestionarios y respuestas estándar, por ejemplo utilizando guiones o listas de verificación (checklists). Se puede utilizar amplio abanico de medios diferentes para mejorar la accesibilidad, aunque los contactos telefónicos o vía e-mail son los más comunes. También se puede usar correo de voz, fax, pasarelas de Internet, y mensajes que se generan automáticamente (p. ej. mensajes de texto a los teléfonos móviles, o buscapersonas).

9.3.2 Soporte al negocio Las llamadas se pueden dividir en incidentes que afectan la infraestructura técnica, incidentes y preguntas sobre el uso de una aplicación, preguntas sobre el estado de los servicios (progreso del incidente), cambios estándar, y otras consultas. Depende del tipo de Centro de Servicios, puede hacerse cargo de todas las llamadas o sólo de los problemas técnicos, no respondiendo consultas sobre aplicaciones del negocio. En este caso, el departamento de cliente que usa la aplicación tiene un contacto para la aplicación o un Centro de Soporte específico para las aplicaciones de negocio. Este tratará de responder preguntas de los usuarios y sólo enviará las preguntas técnicas al Centro de Servicios de la organización TI. De esa manera, el Centro de Servicios no se verá sobrecargado con preguntas relacionadas al uso de aplicaciones.

96

Gestión de Servicios TI basado en ITIL

9.3.3 Opciones estructurales Existen muchas opciones para la estructura del Centro de Servicios. Los modelos más comunes incluyen: -

Centro de Servicios Centralizado como un único punto de contacto para todos los usuarios, posiblemente con subdivisiones locales de Centro de Servicios para las aplicaciones del negocio (división de la función del Centro de Servicios). Centro de Servicios Distribuido (locales) en ciertos lugares. Generalmente, dividir el Centro de Servicios en distintas ubicaciones hará más difícil su gestión, pero da al usuario una percepción más próxima del soporte recibido. Centro de Servicios Virtual donde la ubicación es inmaterial porque se usan tecnología de comunicación que hacen que el usuario no note la localización remota del soporte.

Centro de Servicios Centralizado La Figura 9.2 muestra la función dividida del Centro de Servicios Centralizado. Si la organización TI es responsable de brindar el servicio (el Sistema de Información) y de ayudar con el uso del Sistema de Información, es mejor que el usuario pueda acceder a un Centro de Servicios como único punto de contacto. En ese caso, el Centro de Servicios es responsable de aceptar y registrar la llamada, y de monitorizar el progreso y el escalado. Aquí, el soporte de las operaciones del negocio forma parte del Centro de Servicios TI o es responsabilidad de un equipo de soporte dirigido por el Centro de Servicios. Para ello hace falta un sistema de registro de incidentes común. Si la organización TI no es responsable del soporte a las operaciones del negocio, el Help Desk de operaciones del negocio representará a los usuarios cuando se solicite servicio de soporte provisto por TI.

Figura 9.2 Función dividida del Centro de Servicios

Este modelo se puede combinar con un puente de operaciones (una concentración física de las actividades de administración operativas, p. ej. Centro de Servicios en combinación con el departamento de Operaciones) que permite comunicaciones directa entre el Centro de Servicios y la administración de operación (producción, Operaciones), donde Producción incluye Administración de Redes, Operación de Sistemas, etc. Esta comunicación directa facilita una rápida respuesta si hay errores que el Centro de Servicios no puede resolver de inmediato. Es ideal que los departamentos se encuentren físicamente próximos entre si.

97

Centro de Servicios Centro de Servicios Distribuido Los Centros de Servicios Distribuidos están dispersos entre muchos lugares, en diferentes edificios o hasta en distintos países. La Figura 9.3 da un ejemplo de la estructura del Centro de Servicios distribuido. Existe otra opción entre: -

-

-

Un punto de contacto central, que dirige las llamadas al soporte local. El Centro de Servicios central puede servir como punto de contacto inicial para los usuarios y especializarse en el registro de incidentes. El software actual de redirección de llamadas aumenta la efectividad del Centro de Servicios para atender los incidentes. Puntos de contacto locales con Un Centro de Servicios central para rastrear y monitorizar los incidentes. A menudo cuando la organización local tiene su propio lenguaje y su propia cultura se utiliza esta aproximación. También se usa cuando la organización tiene una cantidad importante de aplicaciones habituales en cada línea del negocio. Por ejemplo, una empresa química tiene más de trescientas categorías de aplicaciones de usuario, y mil aplicaciones en total. Con este nivel de customización, la única solución práctica es distribuir la función del Centro de Servicios fuera de cada línea de negocio, ya que hace falta conocimiento "en el terreno" para resolver muchos de los incidentes que se registran. La responsabilidad local en materia de costes de soporte también pueden motivar la creación de este tipo de estructuras. Un call center. Esta opción se vuelve cada vez más popular y es la más utilizada por los abastecedores. Un número de teléfono central, a menudo gratuito, brinda acceso a un menú de respuesta por voz donde el usuario puede seleccionar el tema sobre el que necesita ayuda, como e-mail o aplicaciones de ofimática. Después la llamada es dirigida a un grupo de soporte de especialistas. Estos grupos de soporte pueden estar en áreas geográficas distintas, pero esto para el usuario es irrelevante.

Figura 9-3 Centro de Servicios distribuido con control central (fuente: OGC)

Centro de Servicios Virtual El Centro de Servicios Virtual es una versión especializada y moderna del Centro de Servicios distribuido. Esta consiste en cierta cantidad de Help Desks locales que parecen formar una unidad haciendo uso de la tecnología de telecomunicaciones moderna y las redes que hacen de la ubicación algo inmaterial. El Centro de Servicios y el soporte ahora se pueden ubicar en cualquier lugar. Al utilizar diversas ubicaciones en distintas

98

Gestión de Servicios TI basado en ITIL zonas horarias alrededor del mundo ("soporte que sigue al sol") se brinda soporte con cobertura 24 horas. La desventaja del Centro de Servicios virtual es que resulta más difícil dar soporte "on-site". Por último, vemos la "autoayuda" como una forma de brindar funcionalidad "automatizada" del Centro de Servicios. La autoayuda en forma de, por ejemplo, acceso Web a la base de datos de conocimientos (buscando errores conocidos o Preguntas más Frecuentes) y registros de incidente (verificación del estado, etc.) es una manera interesante de reducir los costes y de facultar a la comunidad de usuarios finales para resolver sus problemas.

9.3.4 Personal del Centro de Servicios Los requisitos del personal del Centro de Servicios se determinan de acuerdo con la misión y la estructura del Centro de Servicios. A continuación algunos ejemplos de las misiones del Centro de Servicios y de los requisitos de los recursos humanos asociados: -

-

-

Call center - este tipo de unidad de soporte sólo registra llamadas y no da soluciones. Las llamadas se pasan a un departamento de especialistas que las maneja. En algunos casos, el registro y el direccionamiento de las llamadas pueden automatizarse utilizando sistemas de respuesta por voz. Centro de Servicios no cualificado o de registro de llamadas - se registran las llamadas, se hace una descripción en términos generales, y se direcciona de inmediato. El Centro de Servicios tiene una función de despacho, y para las llamadas que se espera que maneje, necesita gran cantidad de procedimientos estandarizados, scripts para tratar las llamadas, disciplina, y un Gestor con experiencia. La ventaja de este modelo es que se estandariza el registro de incidente. La desventaja es que el tiempo de respuesta es más largo y que las tasas de resolución en primer contacto son mucho más bajas que las de un Centro de Servicios cualificado. Centro de Servicios Cualificado - este tipo de Centro de Servicios tiene más habilidades y experiencia que el tipo anterior. Utilizando soluciones documentadas puede resolver muchos incidentes, mientras que deriva otros a grupos de especialistas. Las tasas de resolución en primer contacto son mucho más elevadas que las del Service Desk no cualificado. Centro de Servicios Experto - esta clase de Centro de Servicios tiene conocimiento especial de toda la infraestructura TI y la experiencia para resolver la mayoría de los incidentes de manera independiente.

9.3.5 Tecnología del Centro de Servicios Existen muchas opciones técnicas para establecer Centro de Soporte. Aparte de una herramienta de Gestión de Servicios eficaz, se incluyen: -

La integración de las herramientas de la gestión de servicios con las herramientas de administración de sistemas. Tecnología de comunicaciones es como Integración de Telefonía-Computadoras (CTI) o Protocolo de Voz para Internet {VOIP}. Sistemas Interactivos de Respuesta por Voz (IVR). E-mail. Servidores de fax (fax vía e-mail o Internet). Envío de llamadas a buscapersonas, teléfonos móviles, ordenadores portátiles y pocket-PC. Herramientas de gestión del conocimiento, búsqueda y diagnóstico (base de conocimiento, razonamiento basado en casos, etc.). Sistemas de administración automatizados y herramientas de red. Plataformas de auto servicio Intranet e Internet.

99

Centro de Servicios

9.4 Actividades 9.4.1 Responder a las llamadas Una llamada significa que un usuario contacta con el Centro de Servicios. Todas las llamadas deben ser registradas para facilitar la monitorización del progreso y para obtener métricas para el control del proceso. Hay dos categorías de llamadas -

-

Incidentes - todas las llamadas, excepto aquellas que se relacionan con los cambios estándar:
Informes de errores: fallas verdaderas y quejas sobre el servicio.
Peticiones de Servicio: en ITIL las Peticiones de Servicio se clasifican como incidentes, pero no incluyen fallas en la infraestructura TI. Las Peticiones de Servicio tampoco caen en la categoría de la Gestión de Cambios. Los ejemplos incluyen preguntas como "¿Cómo hago?", peticiones de información, p. ej. estado de las cuestiones, documentación o consejo, peticiones de restauración de claves, ejecución de procesos batch, restauración de archivos o de extractos de base de datos, peticiones de consumibles (incluyendo el reemplazo de un mouse, teclado, etc., si no son CIs), provisión de documentación ejemplo manual de usuarios, etc. Peticiones de Servicio también pueden ser cambios estándar. Un cambio estándar es de hecho un cambio rutinario de la infraestructura que sigue una trayectoria establecida, es la solución aceptada para un requisito específico o conjunto de requisitos, y no es tramitado en el proceso de Gestión de Cambios. Varios ejemplos son una actualización de un PC como preparación para el uso de software específico, setting up PC, software y conexiones de red para nuevos estarters, instalaciones estándar no complicadas y pedidos estándar para workstations, periféricos y aplicaciones locales. Cambios estándar son cambios, de modo que implicarán un cambio de la registrada infraestructura TI. Cambios - estos son los cambios no estándar que no son tramitados como Peticiones de Servicio. Una petición para tal cambio seguirá el proceso estándar de Gestión de Cambios, requiriendo una formal Petición de Cambio (RFC).

Nota: ITIL considera ambos tipos de llamados (informes de error y Peticiones de Servicio) como "incidentes", ya que estos llamados se tratan de igual manera. Por otro lado, la ITIL autoriza procedimientos aislados para las Peticiones de Servicio, que se separan del proceso de la Gestión de Incidentes.

9.4.2 Dando información El Centro de Servicios debe servir como fuente principal de información para los usuarios. Se puede hacer de manera pasiva (p. ej. creando un tablón de anuncios), o activamente (e-mails, mensajes registrados en pantalla, o mensajes de salva pantallas). Todos los esfuerzos deben hacerse para informar a los usuarios sobre los errores actuales o esperados, preferiblemente antes de que sufran las consecuencias. El Centro de Servicios también debe brindar información sobre los servicios nuevos y existentes, proporcionar información al respecto de los Acuerdos de Nivel de Servicio (SLAs) y pedir procedimientos y costes.

9.4.3 Coordinación con el abastecedor El Centro de Servicios también es responsable de los contactos con los abastecedores de mantenimiento. Esto cubre la reparación y reemplazo de impresoras, estaciones de trabajo y, en algunos casos, equipamiento de telecomunicaciones. Este tipo de mantenimiento puede ocuparse de gestionar los incidentes en el puro sentido de la palabra y también los incidentes en términos de cambios y peticiones.

9.4.4 Tareas de administración operativas Realizar copias de seguridad y recuperarlas, proveer de conexiones LAN, administración de espacio de disco en los servidores locales, habilitación de cuentas, autorización y reseteo de claves.

100

Gestión de Servicios TI basado en ITIL

9.4.5 Monitorización de la infraestructura En el Centro de Servicios, las herramientas pueden utilizarse para estimar el impacto de las fallas que afectan a un equipo esencial, como routers, servidores y pasarelas, sistemas de misión crítica, aplicaciones, y bases de datos. A menudo, estas herramientas pueden detectar fallas e informar a la Gestión de Incidentes automáticamente cuando se produce la falla o cuando hay amenazas. No es necesario que el Centro de Servicios utilice estas herramientas, ya que es una tarea primaria de "Operaciones", que debe brindar la información al Centro de Servicios, pero sí que es importante que el Centro de Servicios esté informado de la situación de estos fallos, con el fin de poder reaccionar adecuadamente ante los clientes y proporcionar información al respecto de la situación de las previsiones de recuperación.

9.5 Efectividad La satisfacción del cliente o usuario es la señal más importante de efectividad del Centro de Servicios. Algunos Indicadores Clave de Rendimiento son: -

¿Se atiende rápido el teléfono? (p. ej. el 90% de las llamadas se responden dentro de X segundos). ¿En cuántos minutos se dirigen las llamadas al soporte de segundo nivel (si no se pueden resolver en el Centro de Servicios)? ¿El servicio se restaura dentro de un tiempo aceptable y de acuerdo con el SLA? ¿Se avisa a los usuarios con tiempo sobre los cambios y errores actuales y a futuro?

Algunos indicadores de rendimiento solo pueden medirse a través de encuestas con el cliente, p. ej. : -

¿Se atiende el teléfono con educación? ¿Reciben los usuarios buenos consejos sobre cómo prevenir los incidentes?

9.5.1 Informes de gestión El Centro de Servicios debe verificar en forma regular (p. ej. cada seis meses) si llega a los estándares definidos. Las métricas apropiadas incluyen: -

Porcentaje de incidentes que pueden cerrarse sin recurrir a otos niveles como soporte o abastecedores de segunda o tercera línea. El número de llamadas que gestiona cada estación de trabajo/usuario y el total para el Centro de Servicios. Tiempo de resolución promedio por incidente, por impacto, o tiempo para comprender una petición. Se debe especificar tanto el ciclo de tiempo como el tiempo que se emplea para cada caso. Los informes ACD sobre el tiempo de respuesta promedio, número de llamadas que los usuarios finalizan antes de tiempo, promedio de tiempo por llamada y métricas relativas por agente del Centro de Servicios.

Se pueden fijar estándares para estas métricas, que después se utilizan para contrastar la mejora o el deterioro del servicio. La efectividad del Centro de Servicios también se puede medir a través de encuestas regulares en la organización de clientes.

9.5.2 Factores de éxito críticos Si es difícil contactar el Centro de Servicios, los usuarios no llamarán y en su lugar tratarán de resolver los errores por sí mismos, o a buscar a algún miembro de la organización que los pueda ayudar. De esta manera, el desempeño del Centro de Servicios debe alcanzar cierto nivel antes de hacer una campaña publicitaria. Si los usuarios tratan de contactar directamente a los especialistas, deben ser remitidos al Centro de Servicios. Deben existir buenos SLAs y OLAs y un catálogo de servicios para garantizar que el soporte que brinda el Centro de Servicios tenga un enfoque claro.

101

Gestión de Servicios TI basado en ITIL

Capítulo 10: Gestión de Niveles de Servicio 10. 1 Introducción La Gestión de Niveles de Servicio es el proceso de negociar, definir, medir, manejar y mejorar la calidad de los servicios TI a un coste aceptable. Todo esto se debe desarrollar en un entorno de necesidades de negocio con cambios rápidos en la tecnología. La Gestión de Niveles de Servicio trata de encontrar el balance correcto entre la provisión del servicio y la demanda, la satisfacción del cliente, y el coste de los servicios TI. Es importante que tanto el proveedor como el cliente se den cuenta de que se proporciona y se recibe un servicio mutuo. Esto se formaliza mediante el diseño, acuerdo y mantenimiento de los Acuerdos de Nivel de Servicio (SLAs), Acuerdos de Nivel de Operaciones (OLAs), Contratos de Soporte (UCs) y Planes de Calidad de Servicio.

10.1.1 Conceptos básicos TI Proveedores de Servicio TI y Clientes En teoría, cualquier persona que hace uso de servicios TI es un cliente. En muchos casos, la organización TI será el proveedor. Como la organización TI por lo general también obtiene servicios TI, y la organización TI es a la vez un cliente de los Proveedores de Servicio TI, puede haber una compleja trama de relaciones. Por ejemplo, el departamento de desarrollo de software puede pedir servicios on-line al departamento de procesamiento central, y al mismo tiempo el departamento de desarrollo puede proporcionar mantenimiento de software para garantizar la continuidad de los mismos servicios on-line. En teoría, la Gestión de Niveles de Servicio es un proceso lineal creado para definir los servicios y dar fin a los acuerdos, como por ejemplo los Contratos de Soporte (UCs) con proveedores externos, los Acuerdos de Nivel de Operaciones (OLAs) con proveedores internos, o los Acuerdos de Nivel de Servicio (SLAs) con los clientes. Sin embargo, se necesita un planteamiento flexible puesto que la distinción entre los clientes y los Proveedores de Servicio TI es poco clara. En el contexto de la Gestión de Niveles de Servicio se usan las siguientes definiciones de cliente y proveedor: -

El cliente es el representante de una organización que está autorizado a cerrar acuerdos en nombre de la organización sobre la adquisición de servicios TI. Por eso, no son los mismos que los usuarios finales de los servicios TI. El proveedor es el representante de una organización autorizado a acordar en nombre de ésta la provisión de servicios TI.

Requisitos de Nivel de Servicio (SLR) Los Requisitos de Nivel de Servicio cubren las definiciones detalladas de las necesidades del cliente, y se utilizan para desarrollar, modificar y comenzar los servicios. Los Requisitos de Nivel de Servicio pueden servir como guías para el servicio y sus SLAs, y pueden utilizarse también como una asignación de diseño. Hojas de Especificación de Servicio (Hojas Espec) Las Hojas de Especificación de Servicio describen la relación entre funcionalidad (como se acordó con el cliente, y por consiguiente dirigido externamente desde el punto de vista del proveedor) y tecnología (implementación dentro de la organización, y por lo tanto dirigido internamente) y brindar una especificación detallada del servicio. Las Hojas Espec traducen los Requisitos de Nivel de Servicio (especificaciones externas) a definiciones técnicas necesarias para prestar el servicio (especificaciones internas). Las Hojas de Espec también describen los links entre SLAs, UCs, y OLAs. Las Hojas Espec son una herramienta importante para monitorizar la correspondencia entre las especificaciones internas y externas.

103

Gestión de Niveles de Servicio Catálogo de Servicios El desarrollo de un Catálogo de Servicios puede ayudar a la organización TI a perfilarse y a presentarse como un Proveedor de Servicio TI y no sólo como la que implementa y mantiene la tecnología. El Catálogo de Servicios da una descripción detallada de los servicios operativos en el lenguaje del cliente, junto con un resumen de los niveles de servicio asociados que la organización puede dar a sus clientes. Como tal, es una herramienta de comunicaciones muy importante. El Catálogo de Servicios puede ayudar a dirigir las expectativas de los clientes y de esta manera se facilita el proceso de alineación entre los servicios del cliente y del proveedor. Este documento surge de las especificaciones externas en las Hojas Espec y por lo tanto debe redactarse en un lenguaje sencillo para el cliente, y no en forma de especificaciones técnicas. Acuerdos de Nivel de Servicio (SLA) Un Acuerdo de Nivel de Servicio es un acuerdo entre la organización TI y el cliente, en el que se detalla el servicio o los servicios a brindar. El SLA describe los servicios en términos no técnicos, de acuerdo con la percepción del cliente, y durante el tiempo que dure el acuerdo sirve como estándar para medir y ajustar los servicios TI. Los SLAs por lo general tienen una estructura jerárquica, por ejemplo los servicios generales como redes y los servicios del Centro de Servicios se definen para toda la organización y los aprueba la gerencia. Los servicios más específicos, asociados con las actividades del negocio, se acuerdan a un nivel más bajo en la organización, por ejemplo con la unidad de administración de servicio, responsable de presupuesto o representante de clientes. Programa de Mejora de Servicio (SIP) El Programa de Mejora de Servicio se implementa a menudo como un proyecto, define las actividades, fases e hitos asociados con la mejora de un servicio TI. Plan de Calidad de Servicio (SQP) El Plan de Calidad de Servicio es un documento importante ya que tiene toda la información administrativa necesaria para manejar la organización TI. El Plan de Calidad de Servicio define los parámetros del proceso de la Gestión de Servicios y de la administración de operación. El SLA es "qué" entregaremos a diferencia de la SQP que es "cómo" lo entregaremos. Incluye metas para cada proceso, en forma de Indicadores de Rendimiento. Por ejemplo, para la Gestión de Incidentes tiene los tiempos de resolución para varios niveles de impacto, y para la Gestión de Cambios tiene los tiempos del ciclo y costes de cambios estándar tale como la reubicación. Se definen los informes y los intervalos de los mismos para todos los procesos. Los Indicadores de Rendimiento derivan de los Requisitos de Nivel de Servicio y se documentan en las hojas Espec. Si los proveedores externos contribuyen a proveer los servicios, por ejemplo cuando el Centro de Servicios o el mantenimiento de PC's se realizan a través de terceros, los Indicadores de Rendimiento también se definen en los Contratos de Apoyo. Acuerdo de Nivel de Operaciones (OLA) Un Acuerdo de Nivel de Operaciones es un acuerdo con un departamento TI interno que detalla los acuerdos sobre la provisión de ciertos elementos de un servicio, como un OLA sobre la disponibilidad de la red o la disponibilidad de los servidores de impresoras. Por ejemplo, si el SLA contiene objetivos para resolver incidentes de alta prioridad, los OLAs deben incluir objetivos para cada elemento de la cadena de soporte (objetivo para el Centro de Servicios para responder llamadas, escalar, etc., objetivos para que el Soporte de Red comience a investigar y resolver errores relacionados con la red que se les asignó a ellos, etc.). Los OLAs ayudan a la organización a proporcionar los servicios. Contrato de Soporte (UC) Un Contrato de Soporte es un contrato con proveedores externos que define los acuerdos sobre la provisión de ciertos elementos de un servicio, por ejemplo el arreglo de estaciones de trabajo, o el alquiler de líneas de comunicación. Esto resulta similar a la implementación externa de un OLA. En muchas organizaciones, un departamento TI interno proporciona los servicios TI. Los SLAs y las OLAs son a menudo descripciones de lo que se acordó entre los departamentos internos, más que los contratos legales. Sin embargo, un UC con un proveedor externo se hará por lo general como un contrato formal.

104

Gestión de Servicios TI basado en ITIL

10.2 Objetivos La Gestión de Niveles de Servicio garantiza que se mantengan y mejoren continuamente los servicios TI que necesita el cliente. Esto se logra acordando, monitorizando e informando el rendimiento de la organización TI, para crear una relación de negocio eficaz entre la organización TI y sus clientes. Una Gestión de Niveles de Servicio eficaz mejora el rendimiento y los resultados de los negados del cliente creando mayor satisfacción. Dado que la organización TI conoce más lo que se espera de ella y lo que da, tendrá más posibilidades para planear, presupuestar y manejar sus servicios. Beneficios En general, la introducción de la Gestión de Niveles de Servicio tendrá los siguientes beneficios: -

Los servicios TI están diseñados para alcanzar las expectativas, como los define los Requisitos de Nivel de Servicio. El rendimiento del servicio se puede medir, lo que significa que se puede manejar e informar. Si la organización TI cobra a los clientes por el uso de los servicios TI, el cliente puede sacar conclusiones sobre la calidad del servicio y los costes correspondientes. Ya que la organización TI puede especificar los servicios y los componentes necesarios, puede tener control sobre la gestión de recursos y se pueden reducir los costes a largo plazo. Se mejora la relación con el cliente y la satisfacción del mismo. Tanto el cliente como la organización TI son conscientes de sus roles y responsabilidades, por lo que habrá menos malentendidos u omisiones.

10.3 El Proceso La Gestión de Niveles de Servicio es un proceso que vincula al proveedor de servicio TI y al cliente para esos servicios. El proceso de Gestión de Niveles de Servicio tiene varios objetivos: -

Integrar los elementos necesarios para proveer los servicios TI. Documentar los servicios describiendo claramente los elementos de los distintos documentos. Describir los servicios que se prestan al cliente en una terminología que puedan entender y que puedan consultar. Alinear la estrategia TI con las necesidades del negocio. Mejorar la Entrega del Servicio TI de forma controlada.

La Gestión de Niveles de Servicio tiene un rol central en los procesos de la Gestión de Servicios TI, y tiene fuertes vínculos con los otros procesos de Soporte y Entrega. La Gestión de Niveles de Servicio hace de puente entre el cliente, ya que le da la oportunidad de discutir las necesidades de su negocio sin empantanarse en detalles técnicos. La organización TI después traduce estas necesidades del negocio a especificaciones y actividades técnicas dentro de la organización. Podremos decir que la Gestión de Niveles de Servicio es exitosa siempre y cuando el cliente no tenga que preocuparse por la tecnología. La Gestión de Niveles de Servicio demanda cooperación eficaz y productiva con los clientes, porque la definición correcta de niveles de servicio requiere de la contribución y el esfuerzo del cliente. Si el cliente {el negocio) no se encuentra familiarizado con los temas, primero se tendrá que tratar este tema. La Figura 10.1 muestra la carga de trabajo de la Gestión de Niveles de Servicio compuesta por los dos componentes del proceso: el superior trata de lograr acuerdos y el inferior de garantizar que se cumplan los éstos.

105

Gestión de Niveles de Servicio

Figura 10.1 Proceso de la Gestión de Niveles de Servicio

La Gestión de Niveles de Servicio incluye las siguientes actividades: -

-

106

Identificación - identificar las necesidades del cliente, la gestión de la relación, y la promoción de la organización TI. Comprender los procesos del negocio y las necesidades del cliente. Definición - definir los servicios a proveer para satisfacer las necesidades y los requisitos del cliente. Estos servicios se definen en los Requisitos de Nivel de Servicio y en las Hojas de Espec de Servicio. Como resultado de esta actividad se originará el Plan de Calidad de Servicio. Finalización - finalizar el contrato, es decir negociar con el cliente el nivel de servicio requerido, en relación a los costes, y definirlo en los Acuerdos de Nivel de Servicio (SLAs). Apuntalar los SLAs con Acuerdos de Nivel de Operaciones (OLAs) y los Contratos de Apoyo (UCs). Escribir o revisar el Catálogo de Servicios especificando los servicios disponibles para el cliente. Monitorización - monitorizar los niveles de servicio. Información - redactar los Informes de Niveles de Servicio. Informar al cliente y a la organización TI en forma regular sobre los servicios reales, comparándolos con los Logros de Nivel de Servicio. Revisión - revisar el servicio junto con el cliente para determinar las oportunidades para realizar mejoras. Si es necesario, se puede comenzar con un Programa de Mejora de Servicio. Se puede establecer una comunicación continua con el cliente para conocer su experiencia e ideas sobre el servicio brindado. Esto puede dar como resultado SLAs nuevos o corregidos.

Gestión de Servicios TI basado en ITIL

Una Gestión de Niveles de Servicio completamente eficaz necesita de la introducción de los otros procesos de Soporte de Servicio y Entrega de Servicio. Todos los procesos contribuyen en algún punto con la Gestión de Niveles de Servicio. Cuando se define un servicio y los niveles de servicio asociados, se debe considerar hasta qué punto introducir los procesos de soporte. Las relaciones entre Gestión de Niveles de Servicio y los otros procesos se resumen abajo. Relación con el Centro de Servicios Aunque el Centro de Servicios es una función, no un proceso, la relación entre la función del Centro de Servicios y los procesos de la Gestión de Niveles de Servicio es en particular muy importante. El Centro de Servicios es el punto de contacto inicial para los usuarios y, en el caso de un error intenta recuperar los niveles de servicio acordados con la mayor rapidez posible, a través de la Gestión de Incidentes. Dado su contacto directo con los usuarios de los servicios TI, el Centro de Servicios generalmente puede proporcionar información valiosa sobre la percepción de calidad (satisfacción del usuario) que tienen los usuarios sobre la Gestión de Niveles de Servicio. Normalmente habrá una fuerte relación entre la satisfacción del usuario y del cliente. El Centro de Servicios también juega un rol importante en la asistencia con la definición de una respuesta y los tiempos de solución que se efectivizarán en caso de interrupción del servicio. Relación con la Gestión de la Disponibilidad La Gestión de la Disponibilidad es responsable de la ejecución y la optimización de la disponibilidad de los servicios. La Gestión de Niveles de Servicio proporciona a la Gestión de la Disponibilidad inputs sobre la disponibilidad de los servicios TI, en tanto que la Gestión de la Disponibilidad da información a la Gestión de Niveles de Servicio sobre la verdadera disponibilidad. Relación con la Gestión de la Capacidad Gestión de la Capacidad tiene a su cargo el manejo de la capacidad de la infraestructura Tl. Se establecerá un Plan de Capacidad con detalles sobre el uso actual de la infraestructura, y las previsiones de uso futuro La Gestión de la Capacidad ayuda a la Gestión de Niveles de Servicio dando información sobre el impacto de un servicio nuevo o la extensión de uno ya existente en toda la capacidad. La Gestión de la Capacidad también indica si se utiliza un servicio dentro de los límites acordados. La Gestión de Niveles de Servicio brinda información a la Gestión de la Capacidad sobre el uso esperado actualmente y en un futuro, con el que la Gestión de Niveles de Servicio se ha comprometido o se está por comprometer con el cliente. Relación con la Gestión de Incidentes & Problemas La Gestión de Incidentes y la Gestión de Problemas son buenos indicadores de la efectiva implementación de los acuerdos SLA. La Gestión de Incidentes en particular cumple un rol importante en la veloz restitución de los servicios después de un error. La Gestión de Problemas tiene como objetivo optimizar la estabilidad de los servicios tomando medidas permanentes que garanticen la no repetición de los errores. Resolver incidentes y problemas resulta esencial para proporcionar un servicio de alta calidad. La Gestión de Niveles de Servicio utiliza la información de los informes que generan estos procesos al comunicarse con el cliente. Relación con la Gestión de Cambios El SLA puede definir los cambios que el cliente puede solicitar a la organización TI, y los acuerdos para responder a estos cambios (a quién dirigir los cambios, ciclo de tiempo, costes, informar a la organización, etc.). Un cambio también puede afectar los niveles de servicio con los que se ha acordado. La Gestión de Cambios controla todos los cambios asociados a un servicio y al SLA asociado.

107

Gestión de Niveles de Servicio Relación con la Gestión de Versiones Muchos servicios TI suman la provisión de hardware de la infraestructura al software hecho a medida. La Gestión de Versiones monitoriza los acuerdos que hace la Gestión de Niveles de Servicio en cuanto a provisión de hardware y software. La Gestión de Niveles de Servicio informa sobre la calidad del servicio TI en base a los informes de la Gestión de Versiones. Relación con la Gestión de Continuidad de Servicios TI La Gestión de Continuidad de Servicios TI se ocupa de la rápida recuperación de los servicios TI en caso de desastre, y monitoriza las medidas y procedimientos correctos. Los acuerdos con el cliente sobre este tema se hacen en el proceso de Gestión de Niveles de Servicio. Después se incluyen las medidas y los costes en el SLA. Se puede acordar que ante un desastre, ciertos niveles de servicio se reduzcan temporalmente o no tengan efecto. Los cambios al servicio y el SLA pueden necesitar una modificación de las medidas y los procedimientos de continuidad definidos. Relación con la Gestión de la Seguridad Las medidas de seguridad asociadas con el servicio TI también resultan esenciales para la eficaz Gestión de Niveles de Servicio. Tanto la organización TI como el cliente tendrán ciertos requisitos de seguridad. Los acuerdos correspondientes se definen en el SLA. La Gestión de la Seguridad garantiza que se implementen, monitoricen e informen las medidas de seguridad a la Gestión de Niveles de Servicio. Relación con la Gestión de Configuraciones La Gestión de Configuraciones es responsable de introducir los detalles de las componentes (CIs) y la documentación (SLA) relacionados con el servido en la CMDB, y de dar información de su base de datos. Así, la creación o modificación de un servicio o SLA afectará la CMDB. El Centro de Servicios utiliza la CMDB para determinar el impacto de un error en los servicios, y para verificar los acuerdos sobre la respuesta y los tiempos de solución. La CMDB también se utiliza para informar sobre la calidad de los CIs, para permitir que la Gestión de Niveles de Servicio informe sobre la calidad del servicio brindado. Relación con la Gestión Financiera de los Servicios TI Si se cobra al cliente por los servicios prestados por la organización TI, esto también se incluye en el SLA. Estos pueden ser cargos por única vez, o cargos por servicios especiales o adicionales. La Gestión Financiera da información a la Gestión de Niveles de Servicio sobre los costes asociados a la provisión de un servicio. También da información sobre los métodos de facturación, y la tarifa a cobrar para cubrir los costes de un servicio.

10.4 Actividades A continuación se describen las etapas del proceso, incluyendo el flujo de trabajo del proceso y las actividades.

10.4.1 Identificación A medida que los negocios se hacen más dependientes de sus servicios TI, también aumenta la demanda para mayor calidad de servicios TI. La calidad percibida de un servicio depende de las expectativas del cliente, la Gestión actual de las percepciones del cliente, la estabilidad del servicio, y la aceptabilidad de los costes. Por estas razones, la mejor forma de dar la calidad que corresponde es discutirlo primero con el cliente. Experiencias pasadas muestran que el cliente es poco claro sobre sus expectativas, ya que asumen que simplemente se proporcionarán ciertos aspectos del servicio, sin haberlo acordado con claridad. Estos aspectos asumidos (implícitos) de los servicios TI son a menudo causa de mucha confusión. Esto marca otra vez la necesidad de que los Gestores de Nivel de Servicio conozcan bien a sus clientes, y que los ayuden a clarificar sus ideas sobre los servicios y los niveles de servicio que realmente necesitan, y a qué coste.

108

Gestión de Servicios TI basado en ITIL Los requisitos del cliente se deben expresar en valores medibles para que puedan contribuir al diseño y monitorización de los servicios TI. Si no se han acordado las métricas con el cliente, no se podrá verificar si los servicios TI cumplen los acuerdos. La Gestión de Niveles de Servicio juega un rol principal para comprender y definir lo que quiere el cliente. El primer paso a determinar en los SLAs sobre los servicios que se proporcionan hoy o que se darán en el futuro deberá ser la identificación y definición de las necesidades del cliente en los Requisitos del Nivel de Servicio. Además de hacer eso una vez durante el proceso, también se debe hacer en forma regular, inundándola con informes y revisiones, a pedido del cliente o para beneficio de la organización TI. Esta actividad puede cubrir tanto servicios nuevos como existentes.

10.4.2 Definición Definir el alcance y la profundidad de los requisitos del cliente es considerado un proceso de diseño dentro de la Gestión de Niveles de Servicio. De acuerdo al modelo de seguridad de calidad ISO 9001, un proceso de diseño debería incluir los siguientes pasos: -

diseño desarrollo producción instalación y mantenimiento.

El proceso de diseño debería ser manejado para garantizar que los resultados al final del proceso se correspondan con los requisitos del cliente. Durante el proceso de diseño, el término "externo" se refiere a las comunicaciones con los clientes, e "interno" al apoyo técnico dentro de la organización TI. El proceso de diseño comprende una serie de pasos, desde el detalle de los requisitos del cliente y su definición en estándares, hasta el desarrollo de requisitos técnicos para proporcionar el servicio. Definición de estándares externos El primer paso para cuantificar los servicios TI nuevos o existentes es definir o redefinir las expectativas del cliente sobre los servicios en términos generales. Estas expectativas se formalizan por documentado en los Requisitos de Nivel de Servicio (SLRs). Esto debe incluir a toda la organización de clientes. Es considerado el paso más difícil en la Gestión de Niveles de Servicio. Al principio de esta etapa, el Gestor de Nivel de Servicio se debe preparar para el encuentro con la organización de cliente. Las primeras preguntas a realizar son: "¿Qué se necesita del servicio TI y en qué elementos debe consistir el servicio?" Un servicio puede implicar el uso de una infraestructura limitada, como una Red WAN. Tal servicio puede contribuir a uno compuesto, como acceso a toda la información del sistema, incluyendo la infraestructura completa (WAN, LAN, estaciones de trabajo, aplicaciones, etc.). Durante estas reuniones, se debe dividir en grupos a los usuarios. La Gestión de Nivel de Servicio diseña una lista de los grupos de usuarios y sus requisitos y autoridad. Para definir los Requisitos de Nivel de Servicio es necesaria la siguiente información: -

Descripción, desde la perspectiva del cliente, de las funciones a proveer por el servicio. Horas y días en los que el servicio debe estar disponible. Requisitos de continuidad del servicio. Funciones TI necesarias para brindar el servicio. Referencias a los métodos de operación actuales o los estándares a considerar cuando se define el servicio. Referencia al SLA a modificar o reemplazar si corresponde.

La etapa de diseño traerá aparejado un documento de Requisitos de Nivel de Servicio, que estará firmado por el Gestor de Nivel de Servicio y el cliente. Mientras el departamento se encuentra trabajando en el diseño, adquisición de mercaderías e implementación se pueden modificar los Requisitos de Nivel de Servicio. Tales cambios se pueden relacionar con la factibilidad de las funciones o costes previstos. Ambas partes deben aprobar los cambios.

109

Gestión de Niveles de Servicio

Traducción a estándares internos Durante la fase de especificación, los Requisitos de Nivel de Servicio se estudian minuciosamente. Esta etapa debe proporcionar la siguiente información: -

Descripción veraz y detallada de los servicios TI y de los componentes necesarios. Especificación de la forma en que se implementará y proporcionará el servicio. Especificación del proceso de control de calidad necesario.

Figura 10.2 Etapa de especificación (fuente: OGC)

En la etapa de especificación es conveniente distinguir entre elementos de documentación para uso interno y los de uso externo (Figura 10.2). Las especificaciones para uso externo se relacionan con los objetivos acordados con los clientes y el control del proceso de diseño. Estas especificaciones se desarrollan junto con la organización de cliente, y forman la entrada de las especificaciones para uso interno. Las especificaciones para uso interno se refieren a los objetivos internos de la organización TI que se deben cumplir para satisfacer las demandas del cliente. Una vez que el proceso de Gestión de Niveles de Servicio se encuentra en marcha puede resultar muy útil establecer una separación entre las especificaciones internas y las externas. Esto significa que la organización TI no preocupa a los clientes con detalles técnicos. Desde ese momento, la gestión de niveles de servicio se relaciona con el mantenimiento de acuerdo a las especificaciones internas y externas. El Control de Documento y las Revisiones Internas contribuyen llevando el registro de los documentos, administrando las versiones y organizando auditorías regularmente. Las hojas Espec (especificaciones de servicio) describen con detalles lo que quiere el cliente (elemento externo) y su impacto en la organización TI (elemento interno). Las Hojas Espec no necesitan estar firmadas por ambas partes, sin embargo están sujetas al Control del Documento. El Catálogo de Servicios se puede diseñar en base a las especificaciones de servicio; de esta manera, los cambios en los niveles de servicio se pueden incluir inmediatamente en las Hojas Espec y en el Catálogo de Servicios. Luego se analiza el SLA junto con las Hojas Espec revisadas.

110

Gestión de Servicios TI basado en ITIL Plan de Calidad de Servicio Se recomienda incluir toda la información de gestión (indicadores de rendimiento claves) y las especificaciones para los proveedores internos y externos en un solo documento con el objeto de proporcionar más información sobre las contribuciones que cada proceso de la Gestión de Servicios hace a los servicios TI.

10.4.3 Contrato Una vez que se completa la fase de especificación, la organización TI ha de traducir las necesidades del negocio en recursos TI y configuraciones. Esta información se utiliza más tarde para diseñar o modificar los siguientes documentos. Acuerdo de Nivel de Servicio Cuando se desarrolla la estructura SLA, primero se recomienda definir los aspectos generales, tales como los servicios de red para toda la empresa y el desarrollo de un modelo SLA basado en el servicio, antes de comenzar con las negociaciones. Los SLAs pueden tener una estructura jerárquica como la de la organización de cliente, en forma de acuerdo con cierto número de grados. Cada grado cuenta con su propio nivel de detalle. Los grados superiores incluyen acuerdos sobre los servicios generales a proveer a la organización. Los grados inferiores tienen información relevante a clientes específicos. La estructura del SLA depende de un número de variables: -

Aspectos físicos de la organización:
Extensión
Complejidad
Distribución geográfica

-

Aspectos culturales:
Idioma(s) del documento (para organizaciones internacionales)
Relación entre la organización TI y el cliente
Política de fijación de precio
Uniformidad de las actividades del negocio
Organización lucrativa o no lucrativa

-

Naturaleza de las actividades del negocio:
Condiciones y términos generales
Horario del negocio - 5 x 8 horas o 7 x 24 horas

Contratos de Apoyo y Acuerdos de Nivel de Operaciones Durante el proceso de diseño se debe revisar cualquier UCs u OLAs existente. Cada persona involucrada debe conocer el UCs u OLAs para aplicarlo a la provisión de un servicio específico. Los índices de Control de Documento pueden ayudar a clarificar los vínculos con las Hojas Espec. Catálogo de Servicios - Use el lenguaje de su cliente. Evite la terminología técnica y utilice términos pertinentes al negocio. - Trate de mirar las cosas desde el punto de vista del cliente y use este planteamiento para identificar la información relevante. - Presente un diseño atractivo ya que la organización TI usa este documento para presentarse ante los clientes. - Asegúrese de que el documento esté a disposición de la mayor cantidad de stakeholders posible, por ejemplo publicándolo en un sitio Intranet o en un CD-ROM.

111

Gestión de Niveles de Servicio

10.4.4 Monitorización La Gestión de Niveles de Servicio sólo puede ser monitorizada si se definen por adelantado y con claridad los niveles de servicio que deben corresponder con los objetivos acordados externamente. La monitorización no debe limitarse a los aspectos técnicos, también debe incluir temas de procedimiento. Por ejemplo, hasta que se informa al usuario que se restableció el servicio, éste asumirá que el servicio no está disponible. La Gestión de la Disponibilidad y la de Capacidad por lo general dan información sobre la implementación de los objetivos técnicos asociados con el nivel de servicio. En algunos casos, la información también puede venir de los procesos de Soporte de Servicio, especialmente de la Gestión de Incidentes. Sin embargo, no es suficiente medir los parámetros internos porque no interesan al usuario. También se deben medir los parámetros como tiempo de respuesta, tiempo de escalamiento y soporte. Sólo se obtiene una visión completa si se combina la información de administración de sistemas y la de la Gestión de Servicios.

10.4.5 Informes Los informes de clientes (Informes de Servicio) se deben presentar a intervalos regulares como se acuerda en el SLA. Estos informes comparan los niveles de servicio acordados y los niveles de servicio que se miden en realidad. Los contenidos de los informes pueden incluir: -

Disponibilidad y tiempo ocioso durante un periodo específico. Tiempos de respuesta promedio durante las horas pico. Tiempos de transacción durante los periodos pico. Número de errores funcionales en el servicio TI. Frecuencia y duración de la degradación de servicio (servicios que no alcanzan el nivel). Número de usuarios promedio en las horas pico. Número de intentos exitosos y fallidos al intentar violar la seguridad. Proporción de capacidad de servicio utilizada. Número de cambios completos y abiertos. Coste del servicio que se brinda.

10.4.6 Revisión Se deben revisar los niveles de servicio a intervalos regulares. Es necesario considerar los siguientes aspectos: -

Acuerdos de nivel de servicio desde la revisión anterior. Problemas relacionados con los servicios. Identificación de las tendencias de los servicios. Cambios a los servicios dentro de los niveles de servicio acordados. Cambios en los procedimientos y estimación del coste de los recursos adicionales. Consecuencias que trae una fallo en el suministro de los niveles de servicio acordados.

Si los servicios TI no cumplen con los niveles de servicio acordados, se deben implementar acciones para mejorarlo: -

Desarrollo de un Programa de Mejora de Servicio. Asignación de personal y recursos adicionales. Modificación de los niveles de servicio definidos en el SLA. Modificación de los Acuerdos de Nivel de Operaciones y los Contratos de Apoyo.

En muchas organizaciones en los que se está introduciendo la Gestión de Niveles de Servicio hay discusiones sobre si se deben aplicar sanciones en caso de no cumplir con los acuerdos del SLA. Este es un tema difícil ya que la Gestión de Niveles de Servicio se basa en la interacción entre el departamento TI y los usuarios de servicio TI, a menudo dentro de la misma organización. En dicha situación, donde canto el departamento TI como los usuarios trabajan en pos de lograr los mismos objetivos corporativos, no es claro si las sanciones, en especial las multas de dinero, contribuyen a los intereses corporativos. Puede resultar mucho más útil hacer

112

Gestión de Servicios TI basado en ITIL acuerdos basados en el interés común sobre las medidas a tomar para evitar fallos y cumplir así con los niveles de servicio. Sin embargo, pueden surgir sanciones si el proveedor de servicio TI obtiene un servicio de un proveedor TI externo. Pero en ese caso es más factible que legalmente exista un contrato provisional (UC) y no un SLA.

10.5 Control del proceso Para optimizar el proceso y su control se deben identificar una serie de factores de éxito críticos. Los indicadores de rendimiento también son necesarios para medir el proceso.

10.5.1 Factores críticos de éxito e indicadores clave de rendimiento El éxito de la Gestión de Niveles de Servicio depende de los siguientes factores: -

Un Gestor de Nivel de Servicio capaz que tenga experiencia en el negocio y en el entorno TI, y una organización que ayude cuando sea necesario. Misión y objetivos claros. Campaña de concienciación para dar información a la gente sobre el proceso, para que comprendan y presten ayuda. Tareas bien definidas, autoridades y responsabilidades dentro del proceso; distinguiendo entre control del proceso y tareas operativas (contactos con el cliente).

Los siguientes indicadores clave de rendimiento se pueden utilizar para determinar la eficacia y la eficiencia del proceso de la Gestión de Niveles de Servicio: -

Elementos de servicio incluidos en el SLA. Elementos del SLA incluidos en OLAs y UCs. Elementos de los SLAs que se monitorizan y donde en los que se informa sobre las fallos. Elementos de los SLAs en los que se cumple con los niveles de servicio acordados. Defectos que se identifican y se cubren en el plan de mejora. Acciones que se toman para eliminar estos defectos. Tendencias identificadas con respecto a los niveles de servicio verdaderos.

10.5.2 Informes de gestión Los informes de gestión, a diferencia de los de nivel de servicio, no se muestran al cliente pero se utilizan para controlar y mejorar los servicios internos. Pueden tener métricas sobre los niveles de servicio que soportan en realidad y sobre tendencias como: -

Número de SIAs concluidos. Cantidad de veces en las que no se cumplió con el SLA. Coste de monitorización y medición del SLA. Satisfacción del cliente, basándose en las quejas. Estadísticas sobre incidentes, problemas y cambios. Progreso de las acciones de mejora.

10.5.3 Funciones y roles Roles La Gestión de Niveles de Servicio debe estar controlada por un Gestor de proceso. Este Gestor debe garantizar que el proceso sea eficaz y que proporcione los beneficios previstos. Esto no necesariamente significa que esta posición debe ser ocupada por una sola persona. Muchas organizaciones cuentan con muchos Gestores de Nivel de Servicio, cada uno responsable de uno o más servicios o de grupos de clientes.

113

Gestión de Niveles de Servicio Responsabilidades El Gestor de Nivel de Servicio es responsable de: -

-

Diseñar y actualizar el catálogo de servicios. Definir y mantener un proceso de Gestión de Niveles de Servicio para la organización TI, incluyendo:
Estructura SLA
OLAs con los proveedores internos
UCs con los proveedores externos Actualizar el Programa de Mejora de Servicio existente. Negociar, concluir y mantener SLAs, OLAs y Ucs. Revisar el rendimiento de la organización TI y mejorarla si es necesario.

10.6 Problemas y costes 10.6.1 Problemas Se pueden presentar los siguientes problemas: - La Gestión de Niveles de Servicio tiene que establecer una relación formal con el cliente y necesita que todo el personal TI se adhiera a los acuerdos. Para ello puede ser necesario un cambio de cultura. - Los clientes pueden necesitar ayuda para especificar los Requisitos de Nivel de Servicio. - Puede resultar muy difícil expresar las expectativas del cliente en términos de estándares medibles y costes asociados. - El Gestor de Nivel de Servicio debe ser cuidadoso con los acuerdos demasiado ambiciosos en tanto no se hayan desarrollado la planificación, las herramientas de medición y monitorización, el procedimiento, el Plan de Calidad de Servicio, y los Contratos de Apoyo. Es mejor utilizar una estrategia de mejora gradual. - Los costes generales asociados con la monitorización y la medición de los niveles de servicio son fácilmente subestimados. En grandes organizaciones puede hacer falta gran cantidad de personal dedicado. - En la práctica, muchas organizaciones TI comienzan con el Acuerdo de Nivel de Servicio y se saltan los análisis de requisitos del cliente, la etapa de diseño y el desarrollo del Plan de Calidad de Servicio. Esto puede dar como resultado un proceso difícil de manejar y que no proporciona estándares claros y mensurables. - Los documentos y procesos de la Gestión de Niveles de Servicio podrían terminar siendo fines en si mismos y no los medios para mejorar la relación entre el proveedor de servicio TI y el cliente.

10.6.2 Costes Los costes necesarios para implementar la Gestión de Niveles de Servicio pueden dividirse en las siguientes categorías: -

114

Costes de personal (Gestor de Nivel de Servicio y equipo de proyecto). Costes de formación. Costes de documentación. Costes de instalaciones, hardware y software. Costes de actividades de operación relacionadas con la actualización del Plan de Calidad de Servicio, los Acuerdos de Nivel de Servicio, y el Catálogo de Servicios.

Gestión de Servicios TI basado en ITIL

Capítulo 11: Gestión Financiera de los Servicios TI 11.1 Introducción Mucha gente ve a los servicios TI como una importante contribución al soporte de las actividades rutinarias del negocio, pero son muy pocos los que entienden que esos servicios cuestan dinero. A medida que aumenta el número de usuarios, se incrementa el presupuesto T l . Los clientes se interesan más por los gastos de TI cuando aumenta el presupuesto y, sin ayuda, no pueden orientar este gasto al negocio. Si se cobra por servicios TI y no se brinda ayuda al cliente, éste no puede relacionar los costes reales por cliente con los beneficios del negocio. La metodología ITIL fue desarrollada como una estructura de gestión de la infraestructura TI con el objetivo de promover el uso eficaz y económico de los recursos TI. Uno de los objetivos era transformar las organizaciones basadas en el presupuesto -de presupuesto fijo- en organizaciones serias y conscientes de los costes. Calidad y Costes Proporcionar servicios TI a los usuarios a un coste razonable depende de tres factores: -

Calidad - en términos de operación de:
Capacidad
Disponibilidad
Rendimiento
Recuperación ante desastres
Soporte

-

Coste - en términos de:
Gasto
Inversión

-

Requisitos del cliente
el coste y la calidad deben alinearse con las necesidades de los usuarios con relación al negocio.

Los dos primeros factores se encuentran a menudo en conflicto porque la mejora de calidad en general significa incremento de costes, en tanto que la reducción de costes implica una reducción de calidad. Sin embargo, estos dos factores se pueden balancear al centrarse en las necesidades del cliente. El conocimiento de los costes asociados con la provisión de servicios TI y la aplicación de un sistema de cobro realista para esos servicios ponen al aprovisionamiento del servicio TI en una sólida posición en el negocio. Los clientes tomarán más conciencia de los costes y sentirán que están abonando un precio justo, y de esa forma no malgastarán los recursos TI.

11.1.1 Conceptos básicos Realización de Presupuestos La realización de presupuestos involucra la predicción de los costes y el control de gasto. Esto, a menudo comienza con la preparación de un plan, previa demanda del cliente, para los servicios y los costes relacionados. Se puede hacer un pronóstico en base a datos históricos, mientras se tienen en cuenta las actuales tendencias del negocio y se confía en la experiencia del personal. De no contar con datos históricos, podría ser posible usar servicios similares como modelo. Contabilidad Contabilidad significa controlar cómo gasta el dinero la organización IT. Es muy importante poder determinar los costes para cada cliente, servicio, actividad, etc. En esta instancia, es vital comprender los temas más que establecer el coste. Precio Con precio nos referimos a todas las actividades necesarias para facturar al cliente por los servicios que se prestan. El precio incluye la determinación de el/los objetivo(s) del precio, así como también el/los algoritmo(s) necesarios para calcular el precio. Para esto es necesario un sistema confiable eficaz que cumpla las necesidades de detalle de los diferentes niveles contables: análisis, movimiento total, informes.

115

Gestión Financiera de los Servicios TI Categorías de coste Para aplicar un control de coste eficaz hace falta entender la naturaleza de los costes. Los costes a pueden clasificar de muchas formas. Para cada producto o servicio se pueden determinar los costes que contribuyen con estos y los que no -

Costes directos - costes relacionados específica y exclusivamente a un servicio TI. Por ejemplo las actividades y los materiales que se asocian en forma directa y única con un servicio específico (alquiler de línea telefónica para acceder a Internet). Costes indirectos - los costes que no están específica y únicamente relacionados con un servicio TI. Ejemplos incluyen instalaciones (p. ej. un escritorio), servicios de soporte (p. ej. administración de redes) y costes administrativos (incluyendo tiempo).

Una opción para cobrar los costes indirectos es prorratearlos entre servicios o clientes. Otra opción es utilizar el Contabilidad de Costes Basada en la Actividad (ABC). Este método comienza reuniendo todos los costes generales y asignando los costes de las actividades a los productos y servicios necesarios para el desarrollo de esas actividades. En esencia los costes se cargan con base en criterios que no sean costes directos. ABC puede ser útil como método de cobro si no hay muchos costes relacionados de manera directa con el volumen de servicio. En vez de asignar los costes indirectos arbitrariamente, ABC lo hace en base a los productos y servicios necesarios para desarrollar las actividades. Otra forma de entender los costes, es dividirlos en costes fijos y variables. -

-

Costes fijos - son independientes del volumen de producción; incluyen inversiones en hardware, software y edificios. En muchos casos, se consideran la depreciación y el interés mensual y anual más que el precio de compra. Los costes fijos continúan aunque el volumen de producción (servicio) esté reducido o interrumpido. Costes variables - son costes que cambian de nivel junto con los cambios en el volumen de producción. Como ejemplos tenemos el personal externo, los cartuchos de impresión, el papel, la calefacción o la electricidad. Estos costes se relacionan con los servicios proporcionados por lo que si se incrementa el volumen de producción, también se incrementan los costes. Los costes de capital y de operación merecen cierta distinción: Costes de capital - se relacionan con la compra de activos con la intención de utilizarlos a largo plazo dentro de la organización. Los costes se deprecian a lo largo de los años. De esa manera, los costes se suman a la depreciación más que al precio de compra. Costes de operación - son los costes diarios no asociados a los recursos de producción tangibles. Como ejemplos tenemos contratos de mantenimiento de hardware y software, costes de licencia, primas de seguro, etc.

Tipos de Coste Una vez que se define el coste contable de la estructura (p. ej. por departamento, servicio o cliente), se pueden establecer los tipos de coste a asignar el coste de los ítem en las cuentas. Los tipos de coste deben tener una descripción y estructura clara y reconocible para que sea fácil ubicarlos. Los tipos de coste se subdividen en elementos de coste. Los métodos de cobro para cada elemento de coste se puede definir en las etapas posteriores. Existen seis tipos de coste principales, algunos para los costes directos y otros para los indirectos.

Figura 11.1 Tipos y elementos de coste (fuente: OGC)

116

Gestión de Servicios TI basado en ITIL

Ejemplos de estos tipos de coste incluyen: -

Unidad de Coste de Equipamiento (ECU) - todo el hardware TI como:
Servidores
Almacenamiento en disco
Comunicación y redes
Impresoras

-

Unidad de Coste de Software (SCU) - costes directos e indirectos relacionados con el software, incluyendo:
Software del Sistema
Software de procesamiento de transacción
Sistemas de administración de base de datos
Sistemas de administración de sistemas
Sistemas de desarrollo de aplicaciones
Aplicaciones

-

Unidad de Costes de Organización (OCU) - costes directos e indirectos de personal, que pueden ser fijos o variables, como:
Salarios
Capacitación
Viajes

-

Unidad de Coste de Instalaciones (ACU) - todos los costes directos e indirectos asociados con las instalaciones:
Salas de ordenadores
Oficinas
Otras instalaciones como habitaciones de prueba, de capacitación, aire acondicionado, etc.

-

Coste de Transferencia de Unidad (TCU) - los costes asociados con los bienes y servicio de otro departamento. Es decir, cargos internos entre los departamentos de una organización.

-

Costes Contables (CA) - costes asociados a las actividades de gestión financiera.

11.2 Objetivos La Gestión Financiera tiene como objetivo ayudar a la organización TI interna administrando de una manera efectiva los costes de los recursos TI necesarios para proporcionar los servicios TI. Por esta razón, el proceso tiende a desglosar los costes del servicio TI y a relacionarlos con los distintos servicios TI provistos. De esta manera trata de ayudar con las decisiones de gestión referentes a inversiones TI y alienta el uso consciente del coste de las instalaciones TI. Al elegir los métodos de precio se puede elegir entre la recuperación total del coste, la recuperación con ayuda financiera (presupuestos), o la recuperación para tener una ganancia predefinida. Beneficios Una vez que la organización TI introduzca la Gestión Financiera, será capaz de: -

Determinar los costes de los servicios TI. Identificar y clasificar el coste de la estructura. Asignar mejor los costes de los servicios TI que se dan a los clientes internos y externos. Introducir métodos de precio para el uso de los servicios T I , si corresponde. Operar el departamento TI como unidad de negocio, si corresponde. Recuperar todos los costes, incluidos los costes de capital (inversión, reembolso, depreciación e intereses) del cliente. Evaluar a menudo los cargos para determinar sí todavía son realistas y aceptables. Modelar el comportamiento de los clientes y usuarios construyendo conciencia del coste y vinculando los costes directamente con los servicios.

Dada la naturaleza diversa de los beneficios, hacemos una distinción entre la Elaboración del Presupuesto (que tienen que ver con el Coste) y la Fijación de Precio. La ventaja más importante de la Elaboración del Presupuesto es que ayuda a realizar la gestión con una mejor información sobre los costes de provisión de los servicios TI. Esta información hace posible que la gestión TI equilibre los costes y la calidad para dar un servicio financieramente justificable.

117

Gestión Financiera de los Servicios TI

La Elaboración del Presupuesto ayuda al Gestor de Servicios TI a: -

Tomar decisiones para cada servicio, basándose en la efectividad del coste. Desarrollar un planteamiento serio para decidir sobre los servicios TI y las inversiones relacionadas. Dar más información para dar soporte al gasto, por ejemplo mostrando los costes de evitar los gastos estratégicos. Desarrollar presupuestos y planes en base a información fiable.

La ventaja principal de la Fijación de Precios es la promoción de una relación seria con el cliente. Un cliente que abona la cuenta tiene derechos y puede presentar demandas, pero también hace uso más responsable si es conciente del vínculo entre las demandas que efectúa y la factura que recibe. La Fijación de Precio permite que la Gestión de Servicios TI: -

Revise los servicios TI seriamente y realice planes de inversión basados en la recuperación del coste. Recupere los costes TI vinculándolos con el uso que se hace de los servicios. Influencie el comportamiento del cliente, por ejemplo fijando precios más altos durante las horas pico, o simplemente dando información sobre el coste y la utilización de los servicios sobre los que la gestión puede tomar medidas.

La introducción de la Fijación de Precio debe tender a influenciar el comportamiento del cliente y no a llegar a una situación en la que el cliente consiga lo que quiera solo porque paga. Por ejemplo, no es posible cumplir con los requisitos de precio de cada usuario en particular, aún cuando estos usuarios puedan abonar por ese servicio. La Fijación de Precio abre un ambiente serio para la negociación. Los clientes serán más concientes de los costes asociados con el uso de las instalaciones TI.

11.3 El Proceso El rol de TI en la industria se ha expandido mucho en los últimos años. Así, la organización TI se enfrenta con requisitos más exigentes en términos de calidad y eficiencia de coste de los servicios TI. Los desarrollos relacionados con Internet implican que la organización TI también debe tratar cada vez más con clientes y usuarios fuera del negocio. Las librerías, p. ej. ponen sus catálogos en Internet y prestan servicios a los clientes alrededor del mundo. Esto aumenta la escala de operación y por lo general resulta necesario obtener más información sobre los costes. La eficiencia de coste también precisa de acuerdos sobre los servicios a brindar y los costes razonables a cobrar por tales servicios. Las organizaciones TI deben ser más serias, y establecer un sistema de control de costes eficiente es parte de ello. Un sistema de control de coste eficiente debe cumplir con los siguientes criterios: -

Ayudar al desarrollo de una estrategia de inversión que permita la flexibilidad que proporciona la tecnología moderna. Identificar las prioridades en el uso de recursos. Cubrir los costes de todos los recursos TI utilizados en la organización, incluyendo la actualización de la información pertinente. Ayudar a la gestión en las decisiones diarias para que las que son a largo plazo puedan tomarse con el menor riesgo financiero posible. Ser flexible y capaz de responder rápidamente a los cambios en las actividades del negocio.

La Gestión Financiera ayuda al negocio en el planeamiento y la realización de sus objetivos del negocio. Se debe utilizar de manera consistente en todo el negocio, con un conflicto mínimo, para optimizar su eficiencia. En una organización TI, la Gestión Financiera se implementa a través de tres procesos principales: • • •

Elaboración de Presupuesto, Contabilidad y Fijación de Precio.

Este ciclo se ilustra en la Figura 11.2. La Gestión Financiera de los Servicios TI interactúa con casi todos los otros procesos de la Gestión de Servicios TI, pero depende y tiene más responsabilidades con los procesos que se detallan más adelante.

118

Gestión de Servicios TI basado en ITIL

Figura 11.2 Ciclo Financiero (fuente OGC)

Relación con los procesos del negocio La Gestión de Niveles de Servicio es importante para definir la visión, estrategia y planeamiento de los procesos del negocio (Figura 11.3). Aunque estas actividades caen fuera del alcance de la Gestión Financiera, contribuyen mucho con esta área. Esto se debe a que el negocio tiene una visión de futuro, que se utiliza para definir objetivos medibles que afectan a todas las unidades del negocio y que también pueden utilizarse para establecer objetivos medibles para la organización TI.

Figura 11.3 Relación con el proceso del negocio

Por eso, la estrategia TI debe basarse en los objetivos del negocio. En tanto la organización TI se familiarice más con los negocios, se crearán oportunidades para hacer uso eficiente de los costes de la nueva tecnología TL Los costes Tl de implementación y operación se deben comparar con las ventajas del negocio en términos de costes de operación reducidos y aumento del volumen de ventas.

119

Gestión Financiera de los Servicios TI Relación con la Gestión de Niveles de Servicio El SLA define las expectativas del cliente y las obligaciones de la organización de gestión TI. Los costes en los que se incurre para cumplir con los requisitos del cliente tienen un gran impacto en la forma y escala de los servicios acordados con el cliente. Ej. Gestor de Finanzas de la organización TI consulta al Gestor de Nivel de Servicio sobre temas tales como el coste de alcanzar los requisitos los negocios actuales y futuros, la política de Fijación de Precios de la organización y su efecto en los clientes, y cómo la política afecta al comportamiento del cliente. Cuanto más niveles de servicio diferentes permita el SLA para los distintos clientes, más importantes y amplios serán los beneficios de la Fijación de Precios para los servicios TI. Esto también aumentará los gastos generales resultantes de los procesos de Elaboración de Presupuesto, Contabilidad y facturación de los servicios. Relación con la Gestión de la Capacidad La provisión de la capacidad y la disponibilidad estarán influenciadas por la información de coste. Puede ser necesario discutir el coste de provisión de una capacidad incrementada y de una disponibilidad mejorada con el cliente o el negocio como un todo. La información de coste versus el beneficio del negocio pueden influenciar la decisión sobre la compra o no de capacidad adicional o la mejora o no de la disponibilidad. Relación con la Gestión de Configuraciones La Gestión de Configuraciones especifica, identifica y registra todos los cambios de todos los componentes de la infraestructura. El uso de información, incluyendo la información de coste en la CMDB facilita la recopilación de datos de costes históricos. La Gestión de Configuraciones también puede utilizarse para conciliar los datos sobre activos con los datos de los sistemas financieros.

11.4 Actividades 11.4.1 Elaboración del Presupuesto El objetivo de la Elaboración del Presupuesto es planear y controlar las actividades de una organización. La planificación corporativa y estratégica tiene que ver con los objetivos a largo plazo del negocio. Los presupuestos definen los planes financieros para los objetivos durante el periodo que cubre el presupuesto. Estos periodos por lo general abarcan de uno a cinco años. Métodos de elaboración del Presupuesto Dependiendo de la política financiera del negocio se selecciona uno de los siguientes métodos: -

Elaboración del Presupuesto Incremental - se utilizan los números del año anterior como base para el nuevo presupuesto. Luego se ajusta para reflejar los cambios que se esperan. Elaboración del Presupuesto con Base Cero - este método comienza con un papel en blanco: la Base Cero. Se ignora la experiencia pasada. Para ello cada Gestor debe justificar en sus presupuestos todas sus necesidades de recursos en términos de coste. Esto significa que se debe evaluar y decidir si se debe realizar cada gasto, como así también a qué coste. Obviamente, este método consume más tiempo, y solo se utiliza cada año o dos. El método incremental se usa para el resto de los años.

Proceso de Elaboración del Presupuesto La elaboración del presupuesto comienza identificando los factores clave que limitan el crecimiento de la empresa. En muchos negocios, es por el volumen de ventas; sin embargo, también se puede deber a la falta de espacio o materiales. A menudo, las restricciones financieras determinan el presupuesto. En este proceso se incluye la definición de los siguientes presupuestos secundarios (ignoraremos los procesos de aprobación que se utilizan en cada negocio): -

120

Presupuesto de ventas y marketing - si el volumen de ventas determina el presupuesto, entonces el departamento de marketing es responsable de una parte amplia del proceso. Un correcto análisis y evaluación de los clientes, mercados, regiones de venta, productos, etc. son esenciales para elaborar un buen presupuesto. Presupuesto de producción - el presupuesto de producción brinda información detallada sobre los servicios a ofrecer: cantidades, tiempos de entrega, personas por hora necesarias, materiales necesarios, etc. Presupuesto administrativo - basados en el servicio a proveer, se deben determinar los gastos generales de presupuesto para los departamentos que corresponda, tales como producción, ventas y distribución, investigación y desarrollo, etc. Presupuestos de coste e inversión - el presupuesto de coste se obtiene de los planes de los presupuestos anteriores. El presupuesto de inversión identifica los gastos asociados con el reemplazo y la compra de medios de producción. Los proyectos de inversión que se inician el año anterior también pueden afectar el presupuesto de inversión.

Gestión de Servicios TI basado en ITIL

Periodo Presupuestal El año financiero (fiscal) podría ser una opción clara para fijar el periodo presupuestal. Para hacer una comparación entre los números actuales y los del presupuesto, el periodo presupuestal se divide en meses u otro periodo particular, como ventanas de cuatro semanas. Algunos negocios, además de diseñar un presupuesto anual detallado, hacen una previsión general para un periodo de entre tres y cinco años. Esto da información a la gestión senior sobre las expectativas en un periodo más amplio.

11.4.2 Contabilidad Para poder dirigir una organización TI como negocio, es esencial que se identifiquen y entiendan todos los costes por los que la organización es responsable. Se deben determinar los costes aunque no se cobren al cliente. Los costes solo pueden controlarse si se entienden claramente. Esto no trata de identificar costes menores sino más bien las distintas formas en las que se pueden estructurar los costes, lo cual incrementa la comprensión de la forma en la que se gasta el dinero. Una de las actividades primarias de Contabilidad es definir los elementos de coste. Esta estructura es fija durante un año, tras el cual se puede modificar. En muchos casos, el método de contabilidad de costes se selecciona al introducir una estructura de elemento de coste en el negocio. De esta manera, la estructura de elemento de coste debe ser compatible con los métodos que adopta el negocio. En ocasiones se registran los costes para cada departamento, cliente o producto. Sin embargo, sería ideal que la estructura refleje los servicios proporcionados. Aún cuando el proceso no se utiliza para fijar el precio, resulta muy útil basar el tipo de coste de la estructura en una estructura de servicio, como la que se usa en un catálogo de servicios.

Aplicación del Negocio Contable

Aplicación del Negocio Gestión de Relaciones

Terminal Emulator entorno IBM

Aplicación del Negocio Datos de Marketing

Terminal Emulator otros entornos

Intranet, Extranet e Internet Servicios de Información

Groupware Mail & servicios de directorio

Aplicaciones de la oficina

Servicios de Archivo & Impresión

Sistema Operativo Windows 98

Estación de trabajo Línea Base-A PC de escritorio poderosa

Sistema Operativo Windows NT 4.0

Estación de trabajo Línea Base-B PC de escritorio estándar

Estación de trabajo Línea Base-C PC Laptop

Servicios de Conexión a la red (LAN & WAN) Figura 11.4 Ejemplo de estructura de servicio

En el ejemplo de la Figura 11.4 hay una estructura jerárquica de los elementos de servicio que crea la organización para proporcionar los servicios. En esta estructura, los elementos de servicio de los niveles inferiores ayudan a los niveles superiores. Cuanto más alta es la posición de los elementos dentro de la estructura, más relevante la función para el negocio.

121

Gestión Financiera de los Servicios TI Después de definir los elementos de servicio, se deben definir los elementos que se subdividen en unidad de coste para personal, hardware, software y gastos generales. La ventaja de estructurar los elementos de coste y los de servicio es que se torna visible el gasto en hardware, software y servicio de soporte. Además de una estructura basada en los costes directos como se muestra en la Figura 11.4, también se puede decidir cómo asignar los costes indirectos a los servicios. Cuanto más detallado es un servicio más fácil será entender los costes. De manera alternativa, el catálogo solo puede tener en la lista tres estaciones de trabajo estándar que incluyan todo. En este caso, el diagrama solo tendrá tres columnas y muchos menos elementos de coste. Esto puede resultar más claro, pero también será menor la cantidad de información detallada disponible. Por ejemplo, no habrá elementos de coste claros que el soporte de red pueda asignar y será por lo tanto imposible determinar el soporte necesario para la red. Los presupuestos para el año siguiente se elaboran para cada servicio y elemento de coste con base en la experiencia pasada y a las estimaciones de crecimiento para el año próximo. Estos presupuestos se monitorizan todos los meses para identificar cualquier desarrollo nuevo, como crecimiento inesperado, y para responder de acuerdo con la política del negocio, si corresponde.

11.4.3 Fijación de precios Llevar un informe de costes no es una idea nueva, pero se vuelve cada vez más importante. Sin embargo, fijar el precio de los costes internos es una tendencia nueva. La fijación de precio interna es una herramienta importante para alentar a los usuarios a usar la infraestructura TI con más cuidado. Pero, la fijación de precios para los servicios TI no resulta tan útil si no se cobra a los 'budget holders' en las organizaciones de cliente por otros servicios, como teléfono, comodidad, habitación de mail, catering y administración de personal. En otras palabras, la fijación de precios debe ser compatible con las políticas financieras de la empresa. Si la Fijación de Precios es justa, los 'budget holders' pueden asignar los costes de operación que pueden trasladar al precio de sus productos y servicios. Por lo general, al fijar el precio se tratan de recuperar todos los costes en los que se incurre. En ese caso, la organización TI opera como unidad de negocio. Esto solo es factible si se conocen los costes de operación reales de los servicios TI. Política de Fijación de Precios Es útil tratar las políticas de fijación de precios antes de establecer una tasa. Existen varios métodos de fijación de precios. El método correcto puede seleccionarse según los objetivos de la Gestión Financiera. De manera alternativa, cuando se introduce la fijación de precio en etapas, se puede utilizar una política distinta para cada etapa. Las políticas de fijación de precio son: -

Comunicaciones de información - se informa a los gestores de clientes sobre los cargos para que tomen conocimiento de los costes por el uso de los servicios TI de sus departamentos. Existen dos opciones para esto:



Calcular los costes que tienen que ver con cada unidad del negocio e informar a los gestores implicados. Como arriba, pero incluyendo los cargos a pasar, basados en un método de fijación de precio específico.

-

Flexibilidad de precio - las tarifas se determinan y se cobran en base anual. Si el proveedor de servicios toma la iniciativa de invertir en un servicio que se usa con más frecuencia, el contrato puede incluir una cláusula para cobrar costes adicionales. La alternativa es ofrecer capacidad en exceso a los otros clientes potenciales.

-

Cobro teórico - los costes se facturan pero no es necesario pagarlos. Este método permite a la organización TI ganar experiencia con el proceso y corregir cualquier error del sistema de cobro.

También da al cliente la oportunidad de acostumbrarse al cobro. Sin embargo, este método de cobro solo resulta útil si los costes eventualmente se recuperan, ya que de ser así el coste de conocimiento disminuirá. Tarifas A menudo es difícil establecer la tarifa de un servicio. Fijar la tarifa incluye las siguientes actividades: -

122

Decidir el objetivo de precio. Determinar costes directos e indirectos. Determinar las tarifas de mercado. Analizar la demanda de los servicios. Analizar el número de clientes y la competencia.

Gestión de Servicios TI basado en ITIL Para determinar la tarifa de servicio, la organización primero debe determinar el objetivo y los beneficios previstos para los clientes y el personal TI. El precio es una de las cuatro Ps en marketing: Producto, Precio, Promoción y Plaza. El precio no es solo relevante en términos de recuperación de coste incurrido, ya que también afecta la demanda del producto. Una estrategia de precio flexible se puede utilizar para promover productos o para sacarlos del mercado. Un servicio nuevo con pocos usuarios puede estar subsidiado por la ganancia de otro servicio. Antes de seleccionar la estrategia de precio se deben identificar con claridad los costes del servicio. Hay una amplia gama de políticas de precio como: -

Coste Adicional - existen en muchas formas, y todas ellas se basan en el cobro de los costes en los que se incurrió más un margen de ganancia (coste + % sobreprecio). Los costes y el margen de ganancia pueden definirse de muchas maneras, como:




Costes totales incluyendo un margen de ganancia. Costes marginales más un margen (suficiente para cubrir los costes fijos promedio, costes por ídem, y ganancia sobre capital). Por ejemplo, si la disponibilidad LAN/WAN se incluye en los cargos por conexión de red, este elemento no necesita ser incluido en otros servicios LAN. Uno de los métodos anteriores, con margen de 0%.

-

Tasa corriente - para servidos donde ya se acordó el precio.

-

Meta de rendimiento - servicios que tienen un precio determinado por adelantado.

-

Tarifa del Mercado - los precios se emparejan con lo que cobran los proveedores externos.

-

Precio Negociado por Contrato - estos precios se discuten con el cliente. Si el cliente solicita un servicio nuevo, se negocia si debe hacer cargo de todos los costes de inversión, o solo de una parte.

Se pueden otorgar descuentos por volúmenes servicio, disminuyendo el precio sí aumenta el volumen. Para distribuir la demanda en los sistemas, se pueden utilizar tarifas para horarios pico y no pico.

11.4.4 Informe El uso real de los servicios TI se factura o se comunica al cliente. Los costes se tratan en las reuniones regulares con el cliente bajo el proceso de la Gestión de Niveles de Servicio. Así, la Gestión de Niveles de Servicio obtiene la siguiente información: • Gasto de servicio TI por cliente. • Diferencia entre los cargos reales y los estimados. • Métodos de Precio y Métodos Contables utilizados. • Cualquier conflicto por los cargos con las causas y soluciones.

11.5 Control del Proceso La contabilidad forma parte de la estructura completa de la Gestión de Servicios TI y debe estar a cargo de un Gestor Financiero. Este Gestor es responsable de la implementación y administración diaria de la contabilidad y el sistema de cobro y de informar a la administración TI. El Gestor de Finanzas no necesita ser parte de la organización TI. Los informes, los factores de éxito clave y los indicadores de rendimiento pueden usarse para optimizar la Gestión Financiera.

11.5.1 Informes de Gestión El proceso de la Gestión Financiera debe suministrar informes a menudo a la gestión TI sobre temas tales como: -

Costes totales y beneficios de los servicios TI Análisis de costes para cada departamento TI, plataforma, u otra unidad relevante Costes asociados al sistema de Gestión Financiera Planeamiento de inversiones futuras Oportunidad para reducir el coste

123

Gestión Financiera de los Servicios TI

11.5.2 Factores de éxito críticos e indicadores de rendimiento Antes de utilizar la Gestión Financiera, los usuarios, el personal y la gestión TI deben recibir información del objetivo de tal uso y de los costes, y problemas potenciales asociados con tal uso. Los factores de éxito críticos para usar un sistema de cobro eficaz incluyen: -

Los usuarios deben saber por cuáles servicios se les cobra. Los usuarios deben conocer los métodos de cobro para que puedan así controlar sus costes (por ejemplo, a través de acuerdos o informes en términos de unidades de rendimiento cuantificables). El coste de comprobación del sistema debe dar detalles y justificar el gasto. La Gestión de Servicios TI debe dar sistemas equilibrados que ofrezcan servicios TI eficaces a un precio razonable. La gestión TI debe ser consciente del impacto y los costes del uso de la Gestión Financiera y debe comprometerse por completo a ello. La Gestión de Configuraciones debe proporcionar información relevante sobre la estructura de los servicios para establecer un sistema contable apropiado.

-

Los siguientes indicadores de rendimiento pueden ayudar a controlar el proceso: -

Correcto análisis de coste beneficio de los servicios prestados Los clientes consideran justos los métodos de cobro La organización TI cumple con sus objetivos financieros El cliente cambia el uso de los servicios Informes oportunos a la Gestión de Niveles de Servicio

11.5.3 Funciones y roles Algunas organizaciones TI cuentan con su propio Gestor de Finanzas, mientras que otras tienen acuerdos con departamentos de finanzas que cooperan de cerca con la Gestión TI. Como en los otros procesos la Gestión Financiera debe tener un propietario responsable del proceso y el departamento de finanzas debe establecer las pautas para elaborar presupuestos, contabilidad y sistema de cobro.

11.6 Problemas y costes 11.6.1 Problemas Se pueden presentar los siguientes problemas: -

Las actividades necesarias para registrar y monitorizar los costes resultan una nueva disciplina para el personal T I, y hay poca bibliografía al respecto. Para monitorizar y calcular, y cobrar los costes a menudo se necesita información sobre la planificación de servicios no TI, por ejemplo edificios. Resulta casi imposible obtener detalles de planificación. Es difícil encontrar personal que esté familiarizado con TI y la contabilidad. Si la estrategia corporativa y los objetivos para el desarrollo de los Sistemas de Información no se han formulado y documentado con claridad se vuelve difícil considerar las inversiones necesarias. Si no se entienden las oportunidades que proporciona el proceso, la gente será reticente a colaborar y/o cooperar. La falta de compromiso puede significar que la organización no toma en serio el proceso. Costes administrativos y de organización asociados con la planificación, introducción y puesta en marcha del proceso. Costes de las herramientas necesarias, como por ejemplo una aplicación con hardware y base de datos.

11.6.2 Costes Los costes de este proceso se pueden dividir en dos categorías: -

124

Costes administrativos y de organización asociados con la planificación, introducción y puesta en marcha del proceso. Costes de las herramientas necesarias, como por ejemplo una aplicación con hardware y base de datos.

Gestión de Servicios TI basado en ITIL

Capítulo 12: Gestión de la Capacidad 12.1 Introducción La Gestión de la Capacidad se encarga de proporcionar la capacidad necesaria para procesar y guardar los datos, en el momento justo y de manera eficiente en términos de costes. Es un acto de equilibrio. Una buena Gestión de la Capacidad elimina la compra en pánico o de ultimo minuto, o la compra de la caja más grande y... a cruzar los dedos. Ambas situaciones son costosas. Muchos centros de datos, por ejemplo, se manejan perpetuamente a un 30% o 40% o más de capacidad sin uso. Esto no es tan malo cuando se tienen algunos servidores. Pero cuando se tienen cientos de servidores como tienen muchas empresas, estos porcentuales significan la pérdida de grandes sumas de dinero. La Gestión de la Capacidad se encarga de los siguientes temas: -

¿Se puede justificar el coste de compra de capacidad de procesamiento a la luz de los requisitos del negocio, y si la capacidad de procesamiento se usa de manera eficaz (coste versus capacidad)? ¿La capacidad de procesamiento actual cumple correctamente con las demandas actuales y de futuro del cliente (oferta versus demanda)? ¿La capacidad de procesamiento disponible está rindiendo al completo (puesta a punto de la performance)? ¿Precisa con exactitud el momento en el que se debe adquirir capacidad adicional?

Pata implementar sus objetivos, la Gestión de la Capacidad debe contar con una estrecha relación con el negocio y la estrategia de procesos TI. De esta manera, este proceso es reactivo (mide y mejora) y preactivo (analiza y prevé).

12.1.1 Conceptos básicos Conceptos importantes que incluye la Gestión de la Capacidad: -

Gestión de Rendimiento - mide, monitoriza y pone a punto los componentes de rendimiento de la infraestructura TI. Aplicación del Alcance - determina la capacidad de hardware o de red para dar soporte a aplicaciones nuevas o modificadas y la carga de trabajo prevista. Modelado - utiliza modelos analíticos o de simulación para determinar los requisitos de capacidad de las aplicaciones determinando las mejores soluciones de capacidad. El modelado permite analizar varios escenarios y formular preguntas como "¿Qué pasa si...?" Planificación de capacidad - desarrolla un Plan de Capacidad, analiza la situación actual (preferentemente usando escenarios) y predice el uso futuro de la infraestructura y los recursos TI necesarios para satisfacer la demanda esperada de los servicios TI.

12.2 Objetivos La Gestión de la Capacidad tiende a proveer de manera consistente los recursos TI necesarios en el momento justo (cuando se los necesita) y a un precio justo, alineados con los requisitos actuales y futuros del cliente. Así, la Gestión de la Capacidad necesita entender además de los desarrollos del negocio que afectan al cliente, los desarrollos técnicos. Los procesos de la Gestión de la Capacidad cumplen un rol importante en la determinación de las ganancias por inversión y en la justificación del coste. Ventajas Las ventajas de la Gestión de la Capacidad son: -

Reduce riesgos asociados a los servicios existentes gracias a un manejo eficaz de los recursos y a la monitorización continua del rendimiento de los equipos. Reduce riesgos asociados a los servicios nuevos, ya que la Aplicación de Alcance implica el conocimiento de impacto de los sistemas existentes. Lo mismo se aplica con respecto a los servicios modificados. Reduce costes porque las inversiones se realizan en el momento que corresponden, ni demasiado temprano ni demasiado tarde que significa que el procedimiento de compras no tiene que hacer compras de último minuto o comprar capacidad de sobra con más anterioridad de lo necesario.

125

Gestión de Capacidad -

Reduce las interrupciones del negocio gracias a la estrecha colaboración con la Gestión de Cambios cuando se determina el impacto en la capacidad y cuando se proveen los cambios urgentes que resultan de la incorrecta estimación de capacidad. Cuanto más se utiliza la Gestión de la Capacidad se podrán hacer previsiones más fiables, lo que significa que los pedidos del cliente se pueden responder con mayor rapidez. Mayor eficacia porque la demanda y la oferta se equilibran en una fase más temprana. Los gastos relacionados con la capacidad pueden ser controlados y hasta reducidos gracias al mejor uso de la capacidad.

-

Estas ventajas mejoran la relación con el cliente. La Gestión de la Capacidad se prepara con el cliente en etapas tempranas y facilita la anticipación de los pedidos. También mejorarán las relaciones con los abastecedores. En definitiva, los acuerdos de compra, entrega, instalación y mantenimiento se pueden planear mejor.

12.3 El Proceso Como muchos procesos ITIL la Gestión de la Capacidad se remonta a los tiempos de los ordenadores mainframe. Desgraciadamente, esto significa que muchas personas piensan que la Gestión de la Capacidad sólo es relevante en los entornos mainframe. Esto se ve reforzado por la gran reducción en los costes de hardware de los últimos años. El resultado ha sido la compra de hardware en grandes cantidades sin considerar o sin tener en cuenta la Gestión de la Capacidad. El peligro aquí es que la fuente más grande de costes, riesgos, y posibles problemas en TI no se encuentran en el hardware en si. En otras palabras, la proliferación innecesaria de hardware crea un problema de administración que es mucho más caro que el propio hardware. Implementar la Gestión de la Capacidad ayudará a prevenir inversiones innecesarias y cambios de capacidad ad-hoc, ya que este último aspecto en particular puede tener un impacto negativo en la provisión de servicios. En la actualidad el coste de TI no se relaciona tanto con las inversiones, o la capacidad, sino con su gestión. Por ejemplo, un aumento excesivo en la capacidad de almacenamiento impactará en las operaciones de backup en cinta y llevará más tiempo encontrar los archivos guardados en la red. Este ejemplo ilustra un aspecto importante de la Gestión de la Capacidad: una buena Gestión de la Capacidad es tal vez el ingrediente más importante para cambiar la percepción (y la realidad) de una organización TI como un gasto fijo a al de un proveedor de servicios. Con una buena Gestión de la Capacidad, el proveedor de servicio TI verá, por ejemplo, que las dieciocho iniciativas estratégicas que se impusieron para TI este año dejará a los procesos de backup actuales obsoletos. Teniendo esto en mente, el Gestor de Capacidad puede garantizar que se vea el coste verdadero de estas iniciativas -es decir, que el coste de la nueva solución de backup sea prorrateada entre las dieciocho iniciativas. Esto es proactivo. Si, en cambio, no hay Gestión de la Capacidad, la organización TI reacciona sólo cuando la ventana de backup se encuentra excedida. En este caso, el cliente ve a la organización TI como un gasto general, que viene "mendigando dinero", simplemente porque no me proactivo al establecer las expectativas y asignar los costes por adelantado. La Gestión de la Capacidad tiene como objetivo prevenir las sorpresas y las compras a las apuradas haciendo un mejor uso de los recursos disponibles, e incrementando la capacidad en el momento justo, o controlando el uso de los recursos. La Gestión de la Capacidad también puede ayudar a coordinar las capacidades de los diferentes aspectos de un servido para garantizar que las inversiones costosas en ciertos componentes se utilicen eficazmente. Las infraestructuras TI de hoy en día son muy complejas. Esto aumenta las dependencias de capacidad entre los componentes. Por esa razón es cada vez más difícil cumplir con los niveles de servicio acordados con el cliente. Una organización TI profesional debe por lo tanto tomar un planteo integral para la Gestión de la Capacidad. La Figura 12.1 muestra las actividades principales de la Gestión de la Capacidad.

126

Gestión de Servicios TI basado en ITIL

Figura 12.1 Gestión de la Capacidad (fuente OGC)

La Gestión de la Capacidad tiene tres sub-procesos o niveles de análisis en los que se puede considerar la capacidad: -

-

Gestión de la Capacidad del Negocio ~ el objetivo de este sub-proceso es comprender las necesidades futuras del usuario. Esto se puede hacer obteniendo información del cliente, por ejemplo de planes estratégicos o llevando a cabo análisis de tendencias. Gestión de la Capacidad del Servicio - el objetivo de este sub-proceso es determinar y comprender el uso de los servicios TI (productos y servicios que se dan a los clientes). Se debe comprender el rendimiento y las cargas pico para garantizar la realización y el cumplimiento de los acuerdos de servicio correctos. Este sub-proceso es principalmente preactivo, y tiene fuertes vinculaciones con la Gestión de Niveles de Servicios para lo relacionado con la definición y negociación de Acuerdos de Servicio. Gestión de la Capacidad de Recursos - el objetivo de este sub-proceso es determinar y comprender el uso de la infraestructura TI. Ejemplos de recursos son el ancho de banda de la red, la capacidad de procesamiento, y la capacidad de disco. Los problemas potenciales se deben detectar de antemano para manejar estos recursos eficazmente. También se debe estar a la delantera con los desarrollos técnicos. Una activa monitorización de tendencias es una Importante actividad dentro de este sub-proceso.

Cuando la Gestión de la Capacidad y las necesidades del negocio se relacionan, la Gestión de la Capacidad es un elemento esencial del proceso de planificación. Sin embargo, el soporte que proporcionan los procesos de operación no debe ser subestimado. Más abajo se mencionan los vínculos con los procesos de la Gestión de Servicios. Relación con la Gestión de Incidentes Gestión de Incidentes informa a la Gestión de la Capacidad de los incidentes relacionados con los problemas de capacidad. La Gestión de la Capacidad puede dar información a la Gestión de Incidentes para diagnosticar o solucionar los problemas de capacidad.

127

Gestión de Capacidad

Relación con la Gestión de Problemas La Gestión de la Capacidad ayuda a la Gestión de Problemas en sus roles reactivos y preactivos. Las herramientas, la información, el conocimiento y la experiencia de la Gestión de la Capacidad se pueden utilizar para ayudar a la Gestión de Problemas en distintas etapas. Relación con la Gestión de Cambios La Gestión de la Capacidad puede ser parte del CAB. La Gestión de la Capacidad puede dar información sobre la necesidad de capacidad y el impacto potencial de un cambio al proveer el servicio. La información sobre los cambios es una entrada en el Plan de Capacidad. La Gestión de la Capacidad puede elevar RFCs durante la elaboración del plan. Relación con la Gestión de Versiones La Gestión de la Capacidad apoya a la planificación de la distribución cuando la red se utiliza para la distribución automática o manual. Relación con la Gestión de Configuraciones Existe una fuerte conexión entre la Base de Datos de Capacidad (CDB) y la CMDB. La información que proporciona la Gestión de la Configuración es esencial para desarrollar una CDB eficaz. Relación con la Gestión de Niveles de Servicio La Gestión de la Capacidad aconseja a la Gestión de Niveles de Servicio sobre la factibilidad de los niveles de servicio (por ejemplo tiempo y ciclo de respuesta). La Gestión de la Capacidad monitoriza los niveles de rendimiento y proporciona información para evaluar y si es necesario cambiar los niveles de servicio acordados y los informes asociados. Relación con la Gestión Financiera de los Servicios TI La Gestión de la Capacidad ayuda en la elaboración del presupuesto de inversión, análisis coste/beneficio, y en las decisiones de inversión. La Gestión de la Capacidad también da información muy importante para cobrar servicios relacionados con la capacidad, como la asignación de capacidad de la red. Relación con la Gestión de Continuidad de Servicios TI La Gestión de la Capacidad especifica la capacidad mínima necesaria para continuar con el servicio en el caso de desastre. Se deben revisar constantemente las necesidades de capacidad de la Gestión de Continuidad de Servicios TI para garantizar que reflejen los cambios diarios del entorno de operación. Relación con la Gestión de la Disponibilidad La Gestión de la Capacidad y de la Gestión de Disponibilidad están muy conectadas. El rendimiento y los problemas de capacidad pueden ser causa de pérdidas de servicios TI. De hecho, el cliente puede considerar que un rendimiento pobre es equivalente a la falta de disponibilidad. Por la gran interdependencia que existe entre ambos procesos, se los debe coordinar de manera eficaz. Los dos procesos usan las mismas herramientas y técnicas, como Análisis de Impacto de Componentes de Fallo (CFIA) y Análisis del Árbol de Fallos (FTA).

12.4 Actividades Las siguientes actividades de Gestión de Capacidad vienen descritas abajo y en menor o mayor medida son realizadas para cada uno de los subprocesos de Gestión de la Capacidad del Negocio, los Servicios y los Recursos. Algunas actividades núcleo dentro de esta área vienen ilustradas en la Figura 12.2.

Figura 12.2 Actividades iterativas en Gestión de la Capacidad

128

Gestión de Servicios TI basado en ITIL

12.4.1 Desarrollo del Plan de Capacidad El Plan de Capacidad describe la capacidad actual de la infraestructura TI y los cambios que se esperan en la demanda de los servicios TI, la sustitución de los componentes antiguos y los desarrollos técnicos. El Plan de Capacidad también define los cambios necesarios para proporcionar los niveles de servicios acordados en los SLAs y aun coste aceptable. El Plan de Capacidad describe por lo tanto no solo los cambios esperados sino también los costes asociados. Se debe diseñar un plan todos los años, y debe examinarse cada trimestre para confirmar su validez. En cierta manera, el Plan de Capacidad es la producción más importante de la Gestión de la Capacidad. Las producciones a menudo incluyen un plan anual que se sincroniza con el presupuesto o el plan de inversión, un plan a largo plazo y planes trimestrales con detalles de los cambios de capacidad programados. Con esto se consigue un conjunto de planes coherentes, donde el nivel de detalle aumenta al acercarse al horizonte proyectado.

12.4.2 Modelado El Modelo es una herramienta poderosa de la Gestión de la Capacidad y se utiliza para prever el comportamiento de la infraestructura. Las herramientas disponibles para la Gestión de la Capacidad van desde la estimación hasta la prueba extensiva de prototipos. La primera es barata y solo es útil para las actividades de rutina. La última solo da resultado para los proyectos de implementación a gran escala. Entre estos dos extremos, existen cierta cantidad de técnicas que son más veraces que la estimación, y más baratos que un piloto extenso. En orden decreciente de coste son: -

Análisis de tendencias (más barata) Modelo analítico Simulación Evaluación con línea de referencia (benchmark) (el más exacto)

Los Análisis de tendencia pueden utilizarse para obtener información de carga, pero no se pueden utilizar para predecir los tiempos de respuesta. EL modelo analítico y la simulación tienen sus ventajas y desventajas. Por ejemplo, la simulación se puede utilizar para predecir con exactitud el rendimiento de un host, posiblemente como elemento de dimensionamiento de una aplicación. Sin embargo, es un método que consume mucho tiempo. Los modelos matemáticos analíticos por lo general llevan menos tiempo, pero el resultado no es tan fiable. El de línea de referencia significa la creación de un entorno operativo real, por ejemplo en el centro de proceso de datos del abastecedor. Este entorno cumple con los requisitos de rendimiento y se utiliza para simulaciones "¿qué pasa si...?" o de cambio, como "¿qué pasa cuando un componente de aplicación se transfiere a otro sistema?" o "¿qué pasa si duplicamos el número de transacciones?".

12.4.3 Dimensionamiento de la Aplicación El Dimensionamiento de la Aplicación (Sizing) considera el hardware necesario hacer funcionar aplicaciones nuevas o que fueron cambiadas, como aplicaciones en desarrollo o que están en mantenimiento o que se puedan comprar a pedido del cliente. Estas predicciones incluyen información sobre los niveles de rendimiento esperados, el hardware necesario y los costes. Esta disciplina es en particular relevante durante las etapas iniciales de desarrollo del producto. La información clara sobre el hardware y los otros recursos TI necesarios y los costes esperados durante esta etapa son de mucho valor para la administración. Esta disciplina también contribuye al diseño de un nuevo SLA. El Dimensionamiento de la Aplicación puede necesitar de un gran esfuerzo en entornos grandes o complejos. En primer lugar, la Gestión de la Capacidad acuerda con los desarrolladores los Requisitos de Nivel de Servicio que deberá cumplir el producto. Una vez que el producto alcanzó la etapa de transmisión y aceptación, se verifica si se puede cumplir con los Niveles de Servicio acordados en términos de CPU, I/O, red, disco y utilización de memoria. Uno de los resultados del Dimensionamiento de la Aplicación son las características de carga de trabajo. Estas se pueden utilizar para predecir la capacidad necesaria, si por ejemplo el número de usuarios creciera 25%. Otras características de carga de trabajo son los requisitos de capacidad en el tiempo (picos por día, semana, año y crecimiento futuro).

12.4.4 Monitorización La monitorización de los componentes de la infraestructura tiene como objetivo garantizar que se alcancen los niveles de servicio acordados. Ejemplos de los recursos a monitorizar son: utilización de CPU, utilización de disco, de red, número de licencias, etc. (es decir, solo hay 10 licencias libres disponibles).

129

Gestión de Capacidad

12.4.5 Análisis Se deben analizar los datos monitorizados. Los análisis de tendencias se pueden utilizar para predecir la utilización futura. Esto puede dar lugar a mejoras en la eficiencia o la adquisición de componentes TI adicionales. Los análisis de actividades requieren una comprensión global de toda la infraestructura y el proceso del negocio.

12.4.6 Puesta a punto En base a los datos de monitorización que se analizaron e interpretaron, la Puesta a Punto optimiza los sistemas para la carga de trabajo esperada.

12.4.7 Implementación El objetivo de la implementación es introducir la capacidad nueva o cambiada. Si esto significa un cambio, la implementación involucra el proceso de la Gestión de Cambios.

12.4.8 Gestión de la Demanda La Gestión de la Demanda tiene como objetivo influenciar en la demanda de capacidad. Un ejemplo simple: un usuario está utilizando un informe SQL mal escrito a mitad del día, sacando a otros usuarios de la base de datos y creando una excesiva cantidad de tráfico. El Gestor de Capacidad sugiere crear un trabajo para que "corra" a la noche para que el usuario lo tenga en su escritorio a la mañana. Distinguimos entre gestión de la demanda a corto plazo y a largo plazo: -

Gestión de la demanda a corto plazo - donde una falta de capacidad recurrente puede ser una amenaza en un futuro cercano, y donde no es fácil disponer de capacidad adicional. Gestión de la demanda a largo plazo - donde el coste de los upgrades no se puede justificar, aunque hay ciertos momentos (ejemplo, entre las 10 AM y la tarde} en los que la capacidad puede resultar insuficiente.

La Gestión de la Demanda proporciona inputs importantes para el diseño, monitorización y ajuste tanto del Plan de capacidad como de los Acuerdos de Nivel de Servicio. La Gestión de la Demanda también puede proponer precios diferenciales (es decir, precios distintos a horas pico o no pico) para influenciar en el comportamiento del cliente.

12.4.9 Poblando la Base de Datos de Capacidad (CDB) Crear y poblar la CDB significa unir y actualizar la información técnica, la información del negocio, y roda la otra información que afecte a la Gestión de la Capacidad. Puede resultar imposible almacenar coda la información de capacidad en una sola base de datos física. Los gestores de red y de computación pueden utilizar sus propios planteamientos. Por lo general, la CDB hace referencia a la colección de fuentes con información de capacidad.

Figura 12.3 Fuentes de Información CDB

130

Gestión de Servicios TI basado en ITIL

12.5 Control del Proceso La Gestión de la Capacidad es más eficaz si mantiene vínculos estrechos con los otros procesos de planificación, como Gestión de la Disponibilidad y las actividades de Desarrollo de Aplicaciones. Esto alentará a que la Gestión de la Capacidad tenga un planteamiento preactivo.

12.5.1 Informes de gestión Los informes de gestión que da el proceso de la Gestión de la Capacidad incluyen por un lado, información de control del proceso en términos de características de Plan de Capacidad, recursos utilizados para implementar el progreso de las actividades de mejora, y, por otro lado, los informes de excepción sobre temas tales como: -

Discrepancias entre la utilización de capacidad real y planeada. Tendencias en las discrepancias. Impacto en los niveles de servicio. Incremento/disminución de la utilización de capacidad esperada a corto y largo plazo. Marcas que, cuando se alcancen, necesitarán de capacidad adicional.

12.5.2 Factores de éxito críticos e indicadores de rendimiento La Gestión de la Capacidad depende de los siguientes factores de éxito críticos: -

Expectativas y previsiones del negocio correctas. Comprensión de la estrategia y planificación TI y su veracidad. Apreciación de los desarrollos técnicos. Cooperación con los otros procesos.

El éxito de la Gestión de la Capacidad depende de los siguientes indicadores de rendimiento claves: Predicción de la demanda del cliente - identificación de los desarrollos de carga de trabajo y tendencias en el tiempo, y la veracidad del Plan de Capacidad. Tecnología - opciones para medir el rendimiento de todos los servicios TI, el paso para implementar la nueva tecnología y la habilidad para lograr de forma continúa los acuerdos establecidos en el SLA, aún cuando se utiliza tecnología vieja. Coste - reducción en el número de compras de último minuto, reducción de sobrecapacidad innecesaria o cara, y diseño de planes de inversión en etapas tempranas. Operaciones - reducción del número de incidentes debido a problemas de rendimiento, la habilidad para satisfacer la demanda del cliente en todo momento, y el grado hasta el que se toma en serio a la Gestión de la Capacidad.

12.5.3 Funciones y roles El rol del Gestor de Capacidad es gestionar el proceso y asegurar que el Plan de Capacidad es desarrollado y mantenido, así como que la Base de Datos de Capacidad está al día. Los Gestores de Red, de Sistemas y de Aplicaciones tienen un rol importante en la Gestión de la Capacidad. No solamente son responsables de optimizar el performance, sino que se espera que usen su experiencia en trasladar las demandas del negocio a cada uno de los sistemas que gestionan, y de ahí a determinar la capacidad requerida.

131

Gestión de Capacidad

12.6 Problemas y Costes 12.6.1 Problemas Los problemas potenciales en la Gestión de la Capacidad incluyen: Expectativas no realistas - los desarrolladores, la administración y los clientes a menudo tienen expectativas poco realistas por su desconocimiento de las posibilidades técnicas de las aplicaciones, los sistemas o las redes. Una de las tareas de la Gestión de la Capacidad es orientar estas expectativas, por ejemplo, haciendo que los desarrolladores se den cuenta del impacto de su diseño (por ejemplo para una base datos) en la capacidad y rendimiento. El efecto de la Gestión de la Capacidad también se puede sobreestimar, en particular en lo que respecta a la puesta a punto del sistema y programación de la carga de trabajo. Si la operación de los sistemas necesita de una excesiva puesta a punto, es probable que se deba a un pobre diseño de aplicación o una mala base de datos. Por lo general, la puesta a punto no puede utilizarse para obtener un mayor nivel de rendimiento del que fue originalmente diseñado el sistema. La mayoría de los sistemas grandes tienen algoritmos de programación que a menudo son más eficaces que la intervención de los administradores de sistemas. Y por supuesto, hay un coste asociado a la puesta a punto (no tiene sentido que un ingeniero con un salario alto acumule solo el 3% de mejora de rendimiento tras semanas de esfuerzo cuando con $100 de stick de memoria produciría una mejora del 10%}. Hay un coste más alto por depositar demasiada confianza en la puesta a punto que en sistemas de administración que no son, con razón, ordinarios. Los parámetros "altamente retorcidos" en distintos productos, aplicaciones, o bases de datos provocan consecuencias no intencionadas y agregan demoras a todos los procesos de gestión de servicios, mantenimiento, resolución de problemas, etc. Falta de información correcta - a menudo es difícil conseguir la información necesaria, por ejemplo para el Plan de Capacidad. Puede ser difícil obtener información fiable sobre la carga de trabajo esperada, porque se desconocen o no hay mucha información sobre los planes del cliente, al menos no en detalle. Esto también resulta difícil para el cliente, ya que el ciclo de vida de los productos es cada vez más corto. La única solución es hacer la mejor estimación posible y actualizarla con frecuencia cuando se dispone de mayor información. Inputs del abastecedor - si no existen datos históricos (por ejemplo, cuando se compra un sistema nuevo) la Gestión de la Capacidad depende de la información que proporcionan los abastecedores. Los abastecedores generalmente utilizan "benchmarks" para dar información de sus sistemas, pero dadas las grandes diferencias entre los métodos de prueba es a menudo muy difícil comparar la información y puede no reflejar el rendimiento real del sistema. Implementación en ambientes complejos - la implementación en ambientes complejos distribuidos es difícil porque la magnitud de las interfaces técnicas crean gran cantidad de dependencias de rendimiento. Determinación del nivel de monitorización correcto - las herramientas de monitorización por lo general proporcionan muchas opciones y pueden alentar a investigaciones demasiados detalladas. Cuando se compra y se utilizan estas herramientas se debe decidir de antemano a qué nivel de monitorización se deben implementar.

-

-

-

-

Estos problemas son pertinentes a la Gestión de la Capacidad de los sistemas informáticos y a las redes o a los grandes sistemas de impresión y sistemas PABX. Esto puede resultar todavía más desafiante si hay muchos departamentos responsables de estos dominios que pueden acarrear conflictos sobre las responsabilidades de la Gestión de la Capacidad.

12.6.2 Costes Durante la preparación se deben estimar los costes para establecer la Gestión de la Capacidad. Estos costes se pueden dividir en: -

132

Compra de herramientas de hardware y software tales como herramientas de monitorización, Base de Datos de Capacidad (CDB), herramientas de modelado para simulaciones y análisis de estadística, y herramientas de elaboración de informes. Costes de administración de proyectos asociados con la gestión de los procesos. Personal, capacitación y costes de soporte. Instalaciones y servicios. Una vez que se estableció el proceso, hay costes de personal, contratos de mantenimiento, etc. que se repiten.

Gestión de Servicios TI basado en ITIL

Capítulo 13: Gestión de Continuidad de Servicios TI 13.1 Introducción Muchos gestores consideran la Gestión de Continuidad de Servicios TI (ITSCM) como un lujo, para el cual no necesitan ningún recurso. Sin embargo las estadísticas muestran que los desastres destructivos son bastantes comunes. Desastre - un evento que afecta un servicio o sistema y para el que es necesario un gran esfuerzo para restaurar el nivel de rendimiento original. De esta manera, un desastre es mucho más serio que un incidente. Un desastre no es una interrupción del negocio. Esto significa que todo o parte del negocio no "está comerciando" tras el desastre. Desastres familiares incluyen fuego, relámpagos, daño por agua, robo, vandalismo y violencia, interrupción de la energía en gran escala y fallo de hardware. Los ataques terroristas, como el del Centro Mundial de Comercio en Nueva York, se vuelven más comunes. Internet también puede provocar desastres, como ataques de denegación de servicio (DoS) que destruyen las comunicaciones de toda una organización. Algunas empresas podrían haber prevenido serios problemas pensando y desarrollando Planes de Continuidad Del Negocio. Así mismo los negocios dependen cada vez más de los servicios TI lo que significa que el impacto de la pérdida de los servicios también aumenta y se torna menos aceptable. De hecho, para muchas empresas hacer negocios equivale a utilizar TI, y sin TI no pueden generar ganancia. Por lo tanto resulta imprescindible considerar de qué manera se puede salvaguardar la continuidad del negocio. Desde la publicación del modulo de Planificación de Contingencia de la CCTA ha habido muchos cambios en TI, y en la forma en que las organizaciones la utilizan. Una planificación de Contingencia tradicional solía ser parte del mandato de la organización de TI. Sin embargo hoy en día TI se encuentra mucho más integrado con los distintos aspectos del negocio. Donde la Planificación de Contingencia tradicional era primariamente reactivo (que hacer ante un desastre), el nuevo proceso de la Gestión de Continuidad de Servicios TI pone énfasis en la prevención, es decir evitar el desastre.

13.2 Objetivos El objetivo de la Gestión de Continuidad de Servicios TI es ayudar a toda la Gestión de la Continuidad del Negocio (BCM) garantizando que la infraestructura TI y los servicios TI necesarios, incluyendo Soportes y Centro de Servicios, pueden restaurarse dentro de los límites especificados tras un desastre. ITSCM puede tener un cierto número de objetivos distintos. Dado que ITSCM es parte integral de CBM, el alcance de ITSCM debe definirse en bases a los objetivos del negocio. Cuando se evalúan los riesgos se puede decidir si están dentro o fuera de los procesos ITSCM. Beneficios En tanto los negocios se vuelven cada vez más dependientes de los servicios TI, el coste de no planear y los beneficios de planear sólo se pueden identificar a través de un análisis de riesgo. Una vez que el riesgo del negocio, no tanto de los servicios TI, ha sido identificado se pueden realizar inversiones en medidas preventivas y en medidas para ocuparse de los desastres, tales como planes de recuperación. Las pautas de este capítulo se pueden utilizar para limitar y manejar el impacto de los desastres. En caso de desastres, los negocios con un proceso ITSCM tienen las siguientes ventajas: -

Pueden manejar la recuperación de sus sistemas. Pierden menos tiempo y ofrecen mejor continuidad para los usuarios. Minimizan la interrupción de sus actividades del negocio.

133

Gestión de Continuidad de Servicios TI

13.3 El Proceso La Gestión de Continuidad de Servicios TI es responsable de: -

Evaluar el impacto de la interrupción de los servicios TI tras un desastre. Identificar los servicios críticos para el negocio que requieren de medidas y de prevenciones adicionales. Definir los periodos dentro de los cuales se deben restaurar los servicios. Tomar medidas para prevenir, detectar, preparar y mitigar los efectos de los desastres o para reducir su impacto. Definir el plan a utilizar para restaurar los servicios. Desarrollar, evaluar y mantener un plan de recuperación con detalles suficientes para sobrevivir al desastre y restaurar los servicios a la normalidad tras un periodo definido.

Dado que las operaciones del negocio en su totalidad e TI se entremezclan cada vez más, se describen ambas áreas dentro del alcance ITIL: -

-

Gestión de Continuidad del Negocio (BCM) cubre el análisis de riesgo y la administración para que la organización pueda garantizar la capacidad de producción mínima necesaria o la provisión de servicio en todo momento. La BCM tiene como objetivo reducir los riesgos a un nivel aceptable y desarrollar planes para restaurar las actividades del negocio si se interrumpen por un desastre. Gestión de Continuidad de Servicios TI (ITSCM) es el proceso de manejar los desastres que afectan a los servicios TI y de mantener los servicios para permitir que el negocio siga operando.

La Gestión de Continuidad de Servicios TI es parte de toda la Gestión de Continuidad del Negocio y depende de la información que reciben del proceso BCM. La disponibilidad de los servicios TI se garantiza al combinar las medidas de reducción de riesgo (p. Ej. Instalando sistemas fiables) y al proporcionar opciones de recuperación (P. Ej. Sistema de back up y sistemas redundantes). Una exitosa implementación requiere la ayuda de toda la organización, el compromiso de la gestión y la cooperación de todo el personal. La Gestión de Continuidad de Servicios TI interactúa con todos los otros procesos de Gestión de Servicios TI y en particular con los siguientes: -

134

Gestión de Niveles de Servicio proporciona información sobre las obligaciones del servicio TI. Gestión de la Disponibilidad ayuda a ITSCM desarrollando e implementando medidas de prevención. Gestión de Configuraciones define las configuraciones básicas y la infraestructura TI para dar información a ITSCM sobre la infraestructura a restaurar en caso de desastre. Gestión de la Capacidad garantiza que los requisitos del negocio cuenten con el soporte de los recursos TI que corresponda. Gestión de Cambios garantiza que todos los planes ITSCM sean correctos y estén actualizados haciendo parte a ITSCM de todos los cambios que puedan afectar las medidas preventivas y los planes de recuperación.

Gestión de Servicios TI basado en ITIL

13.4 Actividades La figura 13.1 muestra las actividades 1TSCM. Los números refieren a las sub-secciones de la sección 13.4 en la que se describen las actividades.

Figura 13.1 Modelo de proceso ITSCM (basado en el modelo OGC)

13.4.1 Definición del alcance de ITSCM Cuando se inicia ITSCM se debe considerar a la organización como un todo, debiéndose llevar a cabo las siguientes actividades: -

-

Definición de la política - se debe definir lo antes posible la política y se debe comunicar a toda la organización para que todos los involucrados sean conscientes de la necesidad de ITSCM. La gestión debe mostrar su compromiso. Definición del alcance y las áreas relevantes - requisitos de seguridad, estándares de calidad como la serie ISO9000, estándares de Gestión de la Seguridad como BS7799, y principios de política del negocio generales que se usan para seleccionar el plan y los métodos de evaluación de riesgo y el análisis de impacto del negocio. También se identifica la estructura de gestión correcta y la estructura de proceso para hacer frente a los desastres. Asignación de recursos - establecer un ambiente ITSCM necesitará de una inversión importante en personal y recursos. También será necesario capacitar el personal para que este se encuentre preparado para implementar la etapa 2 del proceso ITSCM (requisitos y estrategia). Establecer la organización del proyecto - es aconsejable usar métodos de gestión de proyecto formales, por ejemplo PRINCE 2, soportado por software de planificación.

13.4.2 Análisis de impacto del negocio Antes de analizar los servicios TI, es aconsejable identificar por un lado las razones que tiene la empresa para incluir a la Gestión de Continuidad de Servicios TI en la Gestión de Continuidad del Negocio; y por otro el impacto en el negocio de una interrupción de servicios importante. En algunos casos, el negocio puede sobrevivir durante algún tiempo y el énfasis se debe poner sobre la restauración de los servicios, en otros casos el negocio no puede operar sin los servicios TI y el énfasis debe estar en la prevención. Muchos negocios tendrán que encontrar el balance entre los dos extremos. Las razones potenciales incluyen: -

Protección de los procesos del negocio Rápida recuperación del servicio Competencia por la supervivencia Mantenimiento de la participación de mercado Mantenimiento de la rentabilidad Protección de la reputación que perciben los clientes

135

Gestión de Continuidad de Servicios TI Las razones antes mencionadas pueden combinarse. En la industria financiera, la pérdida de información de mercado significa que el negocio perderá dinero porque se interrumpe la negociación (el principal proceso del negocio). Peor es el caso en el que exista un requisito establecido por ley para registrar toda la actividad del negocio utilizando un sistema específico; aunque se pueda seguir comerciando, tarde o temprano se infringirá el requisito legal y se impondrán multas (ganancia y necesidad de una rápida recuperación del servicio). En ambos casos, la empresa puede perder clientes y participación de mercado. Análisis de servicio Una vez que se identificaron las razones para dar inicio a ITSCM, se realiza un análisis de los servicios TI esenciales para el negocio (p. Ej. Sistema de información, aplicaciones office, de contabilidad, e-mail, etc.) y cuáles deben estar disponibles de acuerdo con los SLAs. Para algunos servicios no esenciales, se puede acordar la provisión de un servicio de emergencia con capacidad y disponibilidad limitadas. Los niveles de servicio durante la recuperación ante un desastre sólo podrán ser modificados si el cliente está de acuerdo. Para los servicios críticos, se debe encontrar el balance entre prevención y opciones de recuperación. Infraestructura A continuación se debe hacer una evaluación de las dependencias entre servicios y recursos TI. La información de la Gestión de la Disponibilidad se usa para analizar hasta qué punto los recursos TI tienen una función crítica en el soporte de los servicios TI que se describieron anteriormente. La Gestión de la Capacidad proporciona información sobre la capacidad necesaria. También se determina hasta que punto se pueden interrumpir los servicios, desde la pérdida del servicio hasta su restauración. Mas tarde, ésta información se utilizará para identificar las opciones de recuperación para cada servicio.

13.4.3 Evaluación de riesgo No hay estadísticas de desastre oficiales, pero algunos de los desastres mundiales han sido: Gas venenoso: Corte de energía: Terremotos: Ataques terroristas:

Inundaciones

Tokio Metro, Japón (Marzo 1995) Auckland, Nueva Zelanda (Diciembre 1997) Los Ángeles, USA (Enero 1994) Kobe, Japón (Enero 1995) Centro Mundial de Comercio, Nueva York, USA (Febrero 1993) Bishopsgate, Londres, Inglaterra (Abril 1993) Ciudad de Oklahoma, Oklahoma, USA (Abril 1995) Docklands, Londres, Inglaterra (Febrero 1996) Manchester, Inglaterra (Junio 1996) World Trade Center, Nueva York, USA (Septiembre 2001) Bangladesh (Julio 1996) Pakistan {Agosto 1996)

Un análisis de riesgo puede ayudar a identificar los riesgos a los que está expuesto un negocio. Tal análisis también dará información valiosa a la gestión porque identificará las amenazas y vulnerabilidades y las medidas de prevención que correspondan. Ya que es bastante caro mantener un plan de recuperación ante desastres, primero se deben tomar medidas preventivas. Una vez que se tomaron tales medidas para la mayoría de los riesgos, se determinará si aún existen riesgos que puedan necesitar de un plan de contingencia. La figura 13.2 muestra los vínculos entre análisis de riesgo y gestión de riesgo; se basa en la CCTA Risk Analysis and Management Method (CRAMM).

Figura 13.2 Modelo de evaluación de riesgo CCTA (fuente OGC)

136

Gestión de Servicios TI basado en ITIL El modelo soporta un planeamiento de contingencia eficaz al tomar un planteo en fases. Análisis de riesgo Primero se deben identificar los componentes TI relevantes (activos), tales como edificios, sistemas, datos, etc. Una identificación de activos eficaz significa que se tiene que documentar el propietario y el propósito de cada componente. La próxima etapa es analizar las amenazas y las dependencias y estimar la probabilidad (alta, media o baja) de que ocurra un desastre, por ejemplo una combinación de provisión de energía poco fiable y un área con muchas tormentas o con tormentas eléctricas. A continuación las vulnerabilidades se identifican y se clasifican (alta, media y baja). Un pararrayos brindará algo de protección contra los rayos, pero todavía pueden afectar seriamente a la red y a los sistemas. Finalmente, se evalúan las amenazas y vulnerabilidades en el contexto de los componentes TI, para dar una estimación de los riesgos. Cuando se estiman los riegos se debe considerar el alcance del proceso; de hecho, esto forma parte de la iniciación del proceso ITCSM (Fase 1). Por ejemplo, los problemas menores pueden ser solucionados con medidas de la Gestión de la Disponibilidad, y algunos de los riesgos del negocio se encuentran fuera del alcance de ITSCM.

13.4.4 Estrategia de Continuidad de Servicios TI Muchos negocios intentarán alcanzar un balance entre reducción de riesgo y planificación de recuperación. Se debe hacer una distinción entre reducción de riesgo, actividad de recuperación de las actividades del negocio, y opciones de recuperación TI La relación entre reducción de riesgo (prevención) y planificación de recuperación (opciones de recuperación) se analiza mas abajo. Medidas de prevención Las medidas de prevención se pueden tomar con base en el análisis de riesgo, mientras se considera con mucho cuidado costes y riesgos. Las medidas pueden tender a reducir la probabilidad o el impacto de las contingencias, y por lo tanto reducir el alcance del plan de recuperación. Se pueden tomar medidas contra el polvo, las temperaturas demasiado altas o bajas, fuego, interrupción de energía y robo. El resto de los riesgos están cubiertos en el plan de recuperación. El planteamiento Fuerte/Fortaleza es la forma de prevención más amplia. Elimina la vulnerabilidad, por ejemplo, construyendo un bunker con su propio abastecimiento de agua y energía. Sin embargo, esto puede traer otras vulnerabilidades, como el riesgo de fallo de la red, o barricadas, ya que la recuperación off-site será todavía más difícil. El planteamiento fuerte (fortaleza) es conveniente para los grandes centros de proceso de datos que son demasiado complejos para un plan de recuperación. Hoy en día resulta vital complementar el planteo fuerte/fortaleza con la capacidad de escaramuza, es decir, una capacidad de organización para ir al lugar en el que está el problema y tratar el mismo antes de que entre en un espiral fuera de control. Seleccionar opciones de recuperación Si todavía hay riesgos que no han sido eliminados con las medidas de prevención, se tendrán que tratar con la planificación de recuperación. Las opciones de recuperación tendrán que suministrarse de la siguiente manera para garantizar la continuidad del servicio. -

Personal y comodidad - como hacer frente al alojamiento, mobiliario, transporte, y distancias de viaje, etc. Sistema TI y redes - las opciones de recuperación se discuten mas abajo. Servicio de soporte - energía, agua, teléfonos, correo, y servicios de mensajería. Archivos - archivos, documentos, sistemas basados en papel, y materiales de referencia. Servicios de terceros - proveedores de servicios de e-mail y Internet.

Hay un número de opciones disponibles para la rápida recuperación de los servicios TI: -

No hacer nada - pocos negocios pueden seguir este planteamiento. Es probable que esto indique una actitud de no querer ver. Los departamentos que piensan que pueden sobrevivir sin instalaciones de recuperación TI pueden dar la impresión de que significan tan poco para el negocio que se los puede eliminar después de una contingencia. Sin embargo, se puede investigar para cada servicio si ésta resulta una opción aceptable.

-

Regreso al sistema manual (basado en papel) - esta opción es por lo general imposible para los servicios críticos del negocio, porque habrá poca cantidad de personal con la experiencia necesaria para usar los sistemas tradicionales. Además los sistemas basados en papel que se utilizaron antes pueden ya no estar disponibles. Sin embargo, los sistemas basados en papel pueden ser prácticos para servicios menores, no tan importantes. Muchos planes de recuperación incluyen algunas rutinas de backup basadas en papel. Por ejemplo, la opción de recuperación para una terminal de tarjeta de crédito puede ser el uso de los cupones de papel de las tarjetas de crédito.

137

Gestión de Continuidad de Servicios TI

-

Acuerdos recíprocos - esta opción puede utilizarse si dos organizaciones tienen hardware similar y acuerdan prestarse las instalaciones en caso de desastre. Para esta opción, los dos negocios deben formalizar un acuerdo y garantizar la coordinación para que los dos entornos permanezcan sin cambios. La Gestión de la Capacidad debería asegurar que la capacidad de reserva no se utilice para otros propósitos, o que se libere rápidamente. Hoy en día esta opción no es muy atractiva debido al incremento de los sistemas on line como los cajeros automáticos y los sistemas bancarios on line que tienen que estar disponibles las 24 horas, los 7 días de la semana.

-

Recuperación gradual (stand-by frío) - esta opción se puede utilizar en los negocios que pueden estar sin servicio TI por un tiempo, p. Ej. 72 horas. Provee un centro de proceso de datos vacío en una instalación fija acordada o uno móvil que se entrega en el lugar del negocio, la instalación portátil. El centro de proceso de datos se proporciona con energía, aire acondicionado, instalación de red y teléfono. Esta opción de recuperación se puede realizar por contrato con proveedores externos. Se tendrán que hacer contratos por separado con abastecedores de componentes TI para garantizar que las entregas se realicen rápidamente. La ventaja de este sistema es que la instalación se encuentra siempre disponible. Las ventajas y desventajas son diferentes para las instalaciones fijas y las portátiles, y se relacionan con temas aspectos como:





Distancia a la instalación - pocos son los proveedores que ofrecen instalaciones fijas. Estas pueden ser remotas, desventaja que se elimina con el uso de una instalación portátil. Tiempo - ubicaciones de instalaciones fijas que sólo se encuentran disponibles durante un tiempo limitado. Demora - en cualquier caso, la entrega del hardware necesario llevará algún tiempo. Red- por lo general resulta difícil proporcionar las instalaciones de red como corresponde. Las conexiones para una instalación portátil pueden proveerse en el edificio que se usa para las operaciones normales.

Recuperación Intermedia (stand-by cálido) - esta opción proporciona acceso a un ambiente de operación similar al utilizado habitualmente, en el que se puede continuar con los servicios con normalidad tras un corto periodo de cambio (24-72 horas). Existen tres versiones para esta opción:

-










Interna (retirada mutua) - si el negocio tiene muchos lugares o ambientes de test dedicados que se pueden usar para la producción. Esta opción brinda recuperación total tras un tiempo de recuperación mínimo. Las organizaciones con varios sistemas distribuidos a menudo usan una variación de este planteamiento, en los que se reserva la capacidad necesaria en cada sistema. Esta capacidad extra es monitorizada por la Gestión de la Capacidad (similar al acuerdo recíproco de opción de recuperación). Externa - algunos proveedores de servicio dan esta opción como servicio del negocio. Los costes se dividen entre los clientes. Los costes de estos arreglos dependen del hardware y software necesarios y el periodo acordado durante el que se proveen las instalaciones (p. Ej. 16 semanas). Estos arreglos a menudo se realizan para unir el periodo necesario para establecer una instalación stand-by fría. Este planteamiento es relativamente más caro y es probable que la instalación se encuentre más lejos. Móvil - la infraestructura para esta opción es un trailer listo para usar. El trailer sirve como centro de proceso de datos y tiene comodidades ambientales controladas como aire acondicionado. La organización TI debe contar con un lugar para estacionar el trailer. La provisión de energía, datos y conexiones de telecomunicaciones deben estar disponibles en ciertos puntos cerca del edificio. Las ventajas de esta opción incluyen el corto tiempo de respuesta y la proximidad al lugar de negocio. Esta opción sólo está disponible para un número de plataformas de hardware limitadas. Algunos de los abastecedores de hardware más grandes ofrecen este servicio con cierra cantidad de trailers con configuraciones de hardware estándar. En periodos acordados, por ejemplo una vez al año, el trailer visita el negocio para probar los planes de recuperación. La ventaja de esto es que también resulta posible evaluar el impacto de un upgrade a una versión nueva del sistema operativo.

-

Recuperación Inmediata (comienzo caliente, stand-by caliente) - esta opción brinda una recuperación muy rápida o inmediata de los servicios –menos de 24 horas. Ofrece un entorno de producción idéntico y refleja los datos y hasta los procesos de producción. La última opción se desarrolla por lo general con la cooperación de la Gestión de la Disponibilidad.

-

Combinación de opciones - en muchos casos un Plan de Contingencia puede utilizar una opción más cara para introducir una opción más barata. Por ejemplo, un trailer con un centro de proceso de datos operativo (comienzo caliente móvil) puede ser una solución temporal hasta que las instalaciones portátiles hayan sido establecidas y los nuevos sistemas host hayan sido entregados (comienzo móvil frío). Las operaciones normales se restauran después de arreglar el edificio y mudar los nuevos ordenadores host al mismo.

138

Gestión de Servicios TI basado en ITIL

13.4.5 Organización y planificación de la implementación Una vez que se determinó la estrategia del negocio y se optó por algo, se debe implementar el proceso ITSCM y se tienen que desarrollar en detalle los planes para las instalaciones TI Se deberá establecer una organización para implementar el proceso ITSCM. Esto puede incluir la gestión (Gestor de Crisis), la coordinación, y los equipos de recuperación para cada servicio. En el nivel más alto debe existir un plan de dirección total para los siguientes temas: -

Plan de respuesta ante emergencia Plan de evaluación de daño Plan de recuperación Plan de informes vitales (que hacer con los datos, incluyendo los informes en papel) Gestión de Crisis y planes PR

Todos estos planes se usan para evaluar las emergencias y responderlas. Luego se puede decidir si se debe iniciar el proceso de recuperación del negocio, y en ese caso, se debe activar el siguiente nivel de planes, incluyendo: -

Alojamiento y plan de servicios Sistemas informáticos y plan de red Plan de telecomunicaciones (accesibilidad y vínculos) Plan de seguridad (integridad de los datos y redes) Plan de personal Planes financieros y administrativos

13.4.6 Medidas preventivas y opciones de recuperación Se hace referencia a cuando se ponen en práctica las medidas de prevención y las opciones de recuperación que se identificaron más temprano. Las medidas de prevención para reducir el impacto de un incidente se toman junto con la Gestión de la Disponibilidad y pueden incluir: -

Uso de UPS y provisiones de energía de backup Sistemas tolerantes a fallos Almacenamiento en otro lugar y sistemas RAID, etc.

También se debe empezar a introducir acuerdos stand-by. Estos deben cubrir personal, edificios y telecomunicaciones. Aun durante el periodo de contingencia se debe empezar con la restauración a la situación normal y el pedido de componentes nuevos. Se pueden hacer contratos en suspenso con los abastecedores, es decir, que estén disponibles los pedidos firmadas con los componentes a entregar a un precio acordado. Cuando se produce el desastre, el abastecedor puede procesar la orden sin tener que enviar cotizaciones. Esta clase de contratos se deben actualizar todos los años porque los precios y los modelos cambian. Al actualizar los contratos se deben tener en cuenta las líneas de referencia de la Gestión de Configuraciones. Para establecer los acuerdos stand-by se pueden llevar a cabo las siguientes actividades: -

Negociar con terceros instalaciones de recuperación en otro lugar. Mantener y equipar las instalaciones de recuperación. Comprar e instalar hardware stand-by (contratos en suspenso). Administrar contratos en suspenso.

13.4.7 Planes de desarrollo y procedimiento para la recuperación Deben ser planes de detallados y formales, ya que los interesados deben aprobar los cambios y el plan de recuperación debe contar con mantenimiento. Estos temas también se deben comunicar. Los mayores problemas tienen que ver con los cambios en la infraestructura y los niveles de servicio acordados. Por ejemplo, migrar a una nueva plataforma de rango medio puede significar que no hay unidad equivalente en la instalación de backup para un comienzo caliente, externo. Por esta razón, la Gestión de Configuraciones juega un rol muy importante en la monitorización de las configuraciones de referencia a las que se hace referencia en el plan de recuperación. El plan también debe identificar los procesos que se necesitan para dar soporte.

139

Gestión de Continuidad de Servicios TI Plan de recuperación El Plan de recuperación debe incluir todos los elementos de la restauración de las actividades del negocio y los servicios TI, incluyendo: Introducción - describe la estructura del plan y las instalaciones de recuperación que se prevén. Actualización - discute los procedimientos y acuerdos para mantener el plan y rastrea los cambios en la infraestructura. Lista de enrutamiento - el plan esta dividido en secciones, cada una de las cuales especifica las acciones desarrolladas por un sistema específico. La lista de enrutamiento muestra qué secciones deben enviarse y a que personal. Iniciación de recuperación - describe cuánto y en qué condiciones se invoca el plan. Clasificación de contingencia - si el plan describe procedimientos para distintas contingencias se las debe describir aquí en términos de seriedad (menor, medio, mayor), duración {día, mes, semanas) y daño (menor, limitado, serio). Secciones especialistas - el plan debe dividirse en secciones basadas en las seis áreas y grupos que cubren el plan:
Administración - cómo y cuándo se invoca el plan, qué gestores y personal están involucrados, y dónde tiene la base el centro de control.
Infraestructura TI - hardware, software y telecomunicaciones a ser provistos por el sistema de recuperación, los procedimientos de recuperación, y los contratos en suspenso de compra de nuevos componentes TI.
Personal - el personal necesario en la instalación de recuperación, posible transporte a la instalación y alojamiento si la instalación se encuentra lejos del negocio.
Seguridad - instrucciones para protección contra robo, fuego y explosiones en el lugar habitual y en el remoto, e información sobre las instalaciones de almacenamiento externo como depósitos y bóvedas.
Lugares de recuperación - información sobre contratos, personal y funciones específicas, seguridad y transporte.
Restauración - procedimiento para restaurar a la situación normal (p. Ej. El edificio), condiciones entre las que se invocan estos procedimientos, y contratos en suspenso.

-

Procedimientos El plan de recuperación proporciona un marco de trabajo para diseñar los procedimientos. Es esencial tener procedimientos eficaces para que cualquiera pueda poner en marcha la recuperación siguiendo los procedimientos. Se debe mencionar: -

La instalación y evaluación del hardware y los componentes de red. La restitución de las aplicaciones, base de datos y datos.

Estos y otros procedimientos relevantes se adjuntan al plan de recuperación.

13.4.8 Evaluación Inicial La evaluación inicial es un aspecto crítico de ITSCM. Las evaluaciones se deben hacer al principio, después de cambios importantes y anualmente. El departamento TI es el responsable de evaluar la eficacia de los planes y procedimientos de los elementos TI del plan. Las evaluaciones pueden o no ser anunciadas.

13.4.9 Capacitación y conocimiento La capacitación eficaz del personal TI y otro personal y el conocimiento de todo el personal de la organización son esenciales para el éxito de cualquier proceso de Continuidad de Servicios TI. El personal TI tendrá que capacitar personal no TI en equipos de recuperación del negocio para garantizar que se encuentren familiarizados con los temas para que puedan ayudar durante las operaciones de recuperación. Las instalaciones de contingencia reales, en el lugar o en otro lugar, también deben considerar la capacitación y evaluación.

13.4.10 Revisión y auditoría Se debe verificar a menudo que los planes estén actualizados. Esto se relaciona con todos los aspectos de ITSCM. En el área TI, tal auditoría se debe realizar cada vez que se hace un cambio importante a la infraestructura TI, como introducción de nuevos sistemas, proveedores de redes y servicios. Las auditorias también deben realizarse si hay un cambio de estrategia en el departamento TI o en el negocio. Las organizaciones en las que hay cambios rápidos y frecuentes pueden implementar un programa regular de verificación de conceptos ITSCM. Cualquier cambio resultante en los planes y la estrategia se deben implementar bajo la dirección de la Gestión de Cambios.

140

Gestión de Servicios TI basado en ITIL

13.4.11 Evaluación El Plan de Recuperación debe evaluarse regularmente como si fueran las instrucciones de emergencia de un barco. Si todos tienen que estudiar el plan cuando se produce un desastre, habrá más posibilidades de que existan problemas. La evaluación también puede identificar las debilidades del plan o los cambios que se pasaron por alto. En algunos casos los cambios se pueden evaluar de antemano utilizando instalaciones de recuperación antes de introducirlos directamente en la infraestructura.

13.4.12 Gestión de Cambios La Gestión de Cambios cumple una función muy importante al mantener todos los planes al día. Se debe analizar el impacto de cualquier cambio en el Plan de Recuperación.

13.4.13 Seguridad Seguridad significa verificar si la calidad del proceso (procedimientos y documentos) es adecuada para las necesidades del negocio de la empresa.

13.5 Control del proceso El control del proceso eficaz depende de los informes de gestión, los factores de éxito críticos y los indicadores de rendimiento.

13.5.1 Informes de gestión Ante un desastre habrá informes sobre sus causas y efecto, y el nivel de éxito al resolverlo. Cualquier debilidad observada será tratada en los planes de mejora. Los informes de gestión de este proceso también incluyen informes de evaluación de las pruebas de los planes de recuperación. Estos son utilizados para la seguridad. El proceso también informa sobre los planes de recuperación como resultado de cambios significantes en cualquier otro lugar. Las amenazas nuevas también deben quedar registradas.

13.5.2 Factores de éxito críticos e indicadores de rendimiento El éxito de la Gestión de Continuidad de Servicios TI depende de: -

Un proceso de Gestión de Configuración eficaz Soporte y compromiso de toda la organización Herramientas actuales y eficaces Capacitación dedicada de cualquier persona involucrada en el proceso Pruebas regulares, no anunciadas en el plan de recuperación

Los indicadores de rendimiento incluyen: -

Número de fallos de los planes de recuperación Ganancia perdida tras un desastre Coste del proceso

13.5.3 Funciones y roles Tarea principal del Gestor de Continuidad de Servicios TI es implementar y mantener el proceso necesario para garantizar que se cumpla con los requisitos de Gestión de Continuidad del Negocio en todo momento. Se pueden identificar un número de roles y responsabilidades, diferenciándose entre las responsabilidades durante condiciones normales o condiciones de crisis. Rol Consejo

Gestión Mayor

Gestión

Líderes de grupo y miembros de grupo

Responsabilidades en condiciones normales Inicia BCM Asigna personal y recursos Define políticas Define autoridad de proceso Administra el proceso ITSCM Acepta planes, informes de pruebas, etc. Comunica y mantiene el conocimiento. Integración ITSCM dentro de BCM Lleva a cabo el análisis de riesgo Define los entregables Diseña los contratos Gestiona pruebas, evaluaciones e informes Desarrolla los entregables Negocia servicios Implementa pruebas, evaluaciones e informes Desarrollo e implementación de procedimientos

Responsabilidades en condiciones críticas Gestión de crisis Toma de decisiones corporativas / del negocio -

Coordinación y arbitración Provisión de personal, recursos y fondos

-

Invocación de mecanismos de recuperación y continuidad Dirige de dirección Informes

-

Implementación del plan de recuperación

Tabla 3.1 Ejemplos de responsabilidades ITSCM

141

Gestión de Continuidad de Servicios TI

13.6 Costes y problemas 13.6.1 Costes Los costes más importantes al introducir la Gestión de Continuidad de Servicios TI son: -

Tiempo y coste para iniciar, desarrollar, e implementar ITSCM. Las inversiones asociadas a la introducción de la gestión de riesgo y el hardware adicional resultante. Si en el momento de diseñar las configuraciones nuevas, se consideran las medidas dentro del alcance de la Gestión de la Disponibilidad, se pueden reducir los costes. Costes de continuación de los planes de recuperación que dependen de la opción seleccionada, tales como cuotas de los contratos para el comienzo caliente externo, coste de las pruebas de restitución, y el periodo durante el que las instalaciones de recuperación están disponibles. Costes operacionales de ITSCM, como pruebas, auditoria, y actualización del plan. Solo se puede incurrir estos costes tras haber considerado la elección, y comparando los costes potenciales asociados con carecer de un plan de recuperación. Aunque los costes para mantener un plan de recuperación pueden parecer elevados, a menudo son razonables comparados con el gasto total de los seguros contra incendio y robo. Además una ITSCM eficaz puede reducir el coste de los éstos.

-

13.6.2 Problemas Cuando se implementa el proceso se deben considerar los siguientes problemas potenciales: Recursos - para probar y desarrollar el plan, la organización TI deberá contar con capacidad adicional para un equipo de proyecto. Compromiso - los costes anuales deben incluirse en los presupuestos de la organización, ello implica compromiso. Acceso a las instalaciones de recuperación - todas las opciones que se discutieron arriba necesitan de la prueba de las instalaciones de recuperación. Así, los contratos deberán brindar a la organización TI acceso regular a las instalaciones de recuperación. Estimación del daño - cierto daño, como pérdida de reputación, no se puede cuantificar en dinero. Elaboración de Presupuesto - no siempre se entiende la necesidad de instalaciones de contingencia caras, otras veces los planes se recortan. Falta de compromiso de la gerencia del negocio - esto da como resultado un fallo en el desarrollo de ITSCM, aunque el cliente asuma que se han hecho los arreglos. Eventualidad perpetua - todas o muchas partes de la gestión de Continuidad de Servicios TI no están en su lugar y, en consecuencia, se pospone el progreso. En tales casos, cuando se pregunta sobre ITSCM, la respuesta será "si, nos encontramos para eso la semana que viene...", "estamos a punto de nombrar un comité para esto...", etc. Caja Negra - donde el proveedor de servicios TI ha abdicado responsabilidades, además de dejar el control a disponibilidad de ITSCM: "alguien se está ocupando de eso...". Dado que la organización ha gastado mucho dinero o ha encargado a terceros parte de sus operaciones, la gestión espera que el dinero invertido garantice su capacidad de recuperación, o que el proveedor también tenga planes en el lugar que los ayudarán a recuperarse después de una interrupción del negocio. Departamento TI - debe guiarse por los deseos y requisitos actuales del negocio, y no por las suposiciones del departamento TI sobre ellos mismos. Familiaridad con el negocio - es imprescindible que el negocio ayude al desarrollo de ITSCM identificando los temas principales. Falta de conocimiento - es esencial que la organización como un todo conozca el valor ITSCM. Sin el conocimiento y la ayuda de todo el personal, el proceso está condenado al fallo.

-

-

142

Gestión de Servicios TI basado en ITIL

Capítulo 14: Gestión de la Disponibilidad 14.1 Introducción EI ritmo de desarrollo tecnológico sigue creciendo. Por esa razón, dentro de muchas organizaciones el hardware y software necesarios se mantienen en expansión y se diversifican más, a pesar de los esfuerzos de estandarización. Las tecnologías viejas y nuevas deben trabajar juntas. Esto da como resultado estructuras de red, interfaces, e instalaciones de comunicaciones adicionales. Las operaciones del negocio dependen cada vez más de la tecnología. Unas pocas horas sin ordenador pueden tener un impacto serio en la producción y la imagen de un negocio, en particular ahora que Internet se está transformando en un mercado electrónico. Ya que los negocios del competidor están a sólo unos clicks, la lealtad del cliente y su satisfacción son más importantes que nunca. Esta es una de las razones por las que los sistemas están disponibles los siete días de la semana, las 24 horas del día.

14.1.1 Conceptos básicos La Figura 14.1 ilustra los conceptos básicos de la Gestión de la Disponibilidad.

Figura 14.1 Conceptos básicos de la Gestión de la Disponibilidad (fuente: OGC)

Disponibilidad Una alta disponibilidad significa que el servicio TI está continuamente disponible para el cliente porque hay pocos fallos y el servicio de recuperación es veloz. La disponibilidad alcanzada se indica a través de métricas. La disponibilidad del servicio depende de: -

La complejidad de la arquitectura de la infraestructura TI La fiabilidad de los componentes Habilidad para responder rápido y eficazmente a las faltas Calidad del mantenimiento y de las organizaciones de soporte y abastecedores Calidad y alcance de los procesos de gestión de operación

143

Gestión de Disponibilidad

Fiabilidad Una Fiabilidad correcta significa que el servicio está disponible durante cierto tiempo sin interrupciones. Este concepto también incluye la resistencia. La fiabilidad de un servicio aumenta si se puede prevenir la interrupción. La fiabilidad se calcula usando estadísticas. La fiabilidad de servicio se determine por la combinación de los siguientes factores: -

Fiabilidad de los componentes usados para dar un servicio Habilidad de un servicio o componente para operar eficazmente a pesar del fallo de uno o más subsistemas (resistencia) Mantenimiento preventivo para evitar interrupciones

-

Mantenimiento El mantenimiento y recuperación se relacionan con las actividades necesarias para mantener el servicio en operación, y para restituirlo cuando falla, esto incluye mantenimiento preventivo e inspecciones programadas. Estos conceptos incluyen las siguientes actividades: -

Tomar medidas para prevenir fallos Detectar fallos Hacer Realizar el diagnóstico incluyendo el diagnóstico automático que realizan los componentes Resolver el fallo Recuperación tras un fallo Restitución del servicio

Capacidad de Servicio La Capacidad de Servicio tiene que ver con las obligaciones contractuales de los proveedores de servicios externos (contratistas, terceros). Los contratos definen el soporte que deben proveer a los servicios externalizados. Ya que esto sólo interesa a parte del servicio TI, el término no se refiere a la disponibilidad total de un servicio. Si un contratista es responsable de los servicios como un todo (por ejemplo cuando termina el contrato de la administración de instalaciones), Capacidad de Servicio y disponibilidad son sinónimos. Una Gestión de la Disponibilidad eficaz necesita de una comprensión acabada de los negocios y el entorno TI. Es importante ser conscientes de que la disponibilidad simplemente no se puede "comprar": la disponibilidad debe incluirse en el diseño inicial. Finalmente, la disponibilidad depende de la complejidad de la infraestructura, la fiabilidad de los componentes, el profesionalismo de la organización TI y sus contratistas, y la calidad en si del proceso.

14.2 Objetivos El objetivo de la Gestión de la Disponibilidad es proporcionar un nivel de disponibilidad de servicio TI definido y eficiente en coste que permita al negocio alcanzar sus objetivos. Esto significa que las demandas del cliente (el negocio) deben estar en línea con lo que la infraestructura TI y la organización TI son capaces de ofrecer. Si existe una diferencia entre oferta y demanda, la Gestión de la Disponibilidad tendrá que ofrecer una solución. Además, la Gestión de la Disponibilidad garantiza que se midan los niveles de disponibilidad alcanzados y, si es necesario, se mejoren continuamente. Esto significa que el proceso incluye actividades preactivas y reactivas. Cuando se desarrolla el proceso se deben tener en cuenta las siguientes premisas: -

La introducción de Gestión de la Disponibilidad es esencial para obtener un alto grado de satisfacción del cliente. La disponibilidad y la fiabilidad determinan en gran medida cómo perciben los clientes el servicio proporcionado por la organización.

144

Gestión de Servicios TI basado en ITIL -

Siempre habrá fallos, aunque se disponga de un alto grado de disponibilidad. La Gestión de la Disponibilidad es ampliamente responsable por la respuesta profesional a tales situaciones no deseadas. El diseño del proceso demanda no solo una comprensión global d e TI, sino también una apreciación de los procesos y servicios del cliente. Combinando estos dos aspectos se pueden alcanzar los objetivos.

La Gestión de la Disponibilidad tiene un amplio alcance e incluye servicios a clientes nuevos y existentes, relaciones con proveedores internos y externos, todos los componentes de la infraestructura (hardware, software, redes, etc.) y los aspectos de organización que pueden afectar la disponibilidad, como la experiencia del personal, los procesos de gestión, y los procedimientos y herramientas.

14.2.1 Beneficios El mayor beneficio de la Gestión de la Disponibilidad es que los servicios TI que se diseñan, se implementan y manejan, cumplan con los requisitos acordados de disponibilidad. Una comprensión acabada de los procesos del negocio del cliente y de TI, combinado con una aspiración para maximizar la disponibilidad y la satisfacción del cliente dentro de las necesidades puede aportar una importante contribución a la realización de un servicio de cultura eficaz. Otros beneficios de la Gestión de la Disponibilidad son: -

Sólo hay un contacto y una persona responsable de la disponibilidad de los productos y servicios. Los productos y servicios nuevos cumplen con los requisitos y la disponibilidad estándar que se acordó con el cliente. Los costes asociados son aceptables. Los estándares de disponibilidad se monitorizan continuamente y se mejoran si corresponde. Cuando un servicio no esta disponible, se toma una acción correctiva apropiada. Se reducen la aparición y duración de la falta de disponibilidad. El énfasis se traslada de remediar los fallos a mejorar el servicio. Es más fácil para la organización TI demostrar su valor agregado.

Los siguientes procesos ITIL tienen relación con la Gestión de la Disponibilidad. Gestión de Niveles de Servicio La Gestión de servicios es responsable de negociar y manejar los Acuerdos de Nivel de Servicio, en los que la disponibilidad es uno de los elementos más importantes. Gestión de Configuraciones La Gestión de Configuraciones tiene información sobre la infraestructura y puede dar información valiosa a la Gestión de la Disponibilidad. Gestión de la Capacidad Los cambios en la capacidad a menudo afectan la disponibilidad de un servicio y los cambios a la disponibilidad afectarán la capacidad. La Gestión de la Capacidad tiene disponible mucha información, incluyendo información sobre la infraestructura TI. Así, estos dos procesos por lo general intercambian información sobre los escenarios para realizar una actualización o eliminar componentes TI, y sobre las tendencias de disponibilidad que pueden necesitar cambios en los requisitos de capacidad. Gestión de Continuidad de Servicios TI Gestión de la disponibilidad no es responsable de la restitución de los procesos del negocio después de un desastre. La Gestión de Continuidad de Servicios TI es responsable de esta tarea. ITSCM da información a la Gestión de la Disponibilidad sobre los procesos del negocio críticos. También, en la práctica, muchas medidas que se toman para mejorar la Disponibilidad mejoran a su vez la Continuidad del Servicio TI, y viceversa. Gestión de Problemas La Gestión de Problemas es responsable en forma directa de identificar y resolver las causas de problemas de disponibilidad reales o potenciales.

145

Gestión de Disponibilidad

Gestión de Incidentes La Gestión de Incidentes especifica cómo se deben resolver éstas. Este proceso da requisitos con información sobre los tiempos de recuperación, de reparación, etc. Esta información se utiliza para determinar la disponibilidad alcanzada. Gestión de la Seguridad La Gestión de la Disponibilidad tiene fuertes vínculos con la Gestión de la Seguridad. Los tres temas básicos de la Gestión de la Seguridad son: -

Confidencialidad Integridad Disponibilidad

Gestión de Cambios La Gestión de la Disponibilidad informa a la Gestión de Cambios de los temas de soporte relacionados con los servicios y elementos nuevos de la misma e inicia el proceso de Gestión de Cambios para implementar los cambios que necesitan por necesidades de disponibilidad. La Gestión de Cambios informa a la Gestión de la Disponibilidad sobre los cambios programados (FSC).

14.3 El Proceso Donde es posible, los componentes esenciales se duplican y la detección de fallos y los sistemas de corrección se utilizan para alcanzar elevados grados de disponibilidad. A menudo, los sistemas automáticos de respaldo operarán en caso de fallo. Sin embargo, también se deberán tomar medidas de organización que pueden ser proporcionadas introduciendo la Gestión de la Disponibilidad.

Figura 14.2 Entradas y producción de la Gestión de la Disponibilidad

146

Gestión de Servicios TI basado en ITIL La Gestión de la Disponibilidad puede iniciarse una vez que el negocio definió con claridad sus requisitos de disponibilidad para los servicios. Es un proceso en marcha que sólo termina cuando se elimina un servicio. Las entradas del proceso de la Gestión de la Disponibilidad (Figura 14.2) son: -

Requisitos de disponibilidad del negocio. Evaluación del impacto para todos los procesos del negocio que soporta TI. Requisitos de disponibilidad, fiabilidad, y capacidad de mantenimiento para los componentes TI de la infraestructura. Datos sobre fallos que afectan los servicios o componentes, por lo general en forma de registros e informes de incidentes y problemas. Datos de configuración y monitorización sobre los servicios y componentes. Niveles de servicio alcanzados comparados con los niveles de servicio acordados para todos los servicios cubiertos en el SLA.

Salidas: -

Disponibilidad y criterio de diseño de recuperación para servicios TI nuevos y mejorados. Tecnología necesaria para obtener la resistencia de la infraestructura necesaria para reducir o eliminar el impacto de los componentes fallados de la infraestructura. Garantías de disponibilidad, fiabilidad, y capacidad de mantenimiento de los componentes de la infraestructura necesarios para el servicio TI. Informes sobre la disponibilidad, fiabilidad y capacidad de mantenimiento alcanzadas. Requisitos de monitorización de la disponibilidad, fiabilidad y capacidad de mantenimiento alcanzadas. Un plan de Disponibilidad para la mejora preactiva de la infraestructura TI.

14.4 Actividades La Gestión de la Disponibilidad incluye un cierto número de actividades clave que tienen que ver con la planificación y la monitorización. Estas actividades son: -

Planificación
Determinar los requisitos de disponibilidad
Diseño para la disponibilidad
Diseño para la recuperación
Temas de seguridad
Gestión de mantenimientos
Desarrollo de un Plan de Disponibilidad

-

• Monitorización
Medición e informes

Estas actividades clave se discuten más adelante.

14.4.1 Determinar los requisitos de disponibilidad Estas actividades se deben llevar a cabo antes de terminar el SLA y debe mencionad los servicios TI nuevos y los cambios a los servicios existentes. Se debe tratar de decidir cuanto antes si la organización TI puede cumplir con los requisitos y cómo.

147

Gestión de Disponibilidad Estas actividades deben identificar: -

Fundones claves del negocio Definición acordada de la interrupción del servicio TI Requisitos de disponibilidad cuantificables Impacto cuantificable de las funciones del negocio en caso de interrupción de servicio TI no programada Horarios del negocio del cliente Acuerdos sobre las ventanas de mantenimiento

Definir con claridad los requisitos de disponibilidad en las primeras etapas es muy importante para prevenir la confusión y las diferencias de interpretación en las siguientes etapas. Se deben comparar los requisitos del cliente con lo que se puede ofrecer. Si existe una diferencia, se debe determinar qué impacto de coste tendrá.

14.4.2 Diseño para la disponibilidad Las vulnerabilidades que afectan los estándares de disponibilidad deben identificarse cuanto antes. Con esto se evitarán costes de desarrollo excesivos, gasto no planeado en etapas futuras, Puntos Únicos de Fallo (SPOF), costes adicionales facturados por los abastecedores y versiones demoradas. Un buen diseño, basado en los estándares de disponibilidad correctos, hará posible la firma de acuerdos de mantenimiento con los abastecedores. El proceso de diseño emplea una gama de técnicas tales como el Análisis de Impacto de Fallo de Componente (CFIA, ver sección 14.4.9) para identificar SPOFs, CRAMM's (ver capítulo sobre Gestión de Continuidad de Servicios TI) y técnicas de simulación. Sí no se pueden alcanzar los estándares de disponibilidad, la mejor opción es determinar si se puede mejorar el diseño. El uso de tecnología adicional, otros métodos, una estrategia de versiones diferente, un mejor diseño o uno distinto, y las herramientas de desarrollo pueden ser de utilidad para alcanzar los estándares. Si los requisitos son particularmente exigentes, se puede considerar el uso de otras tecnologías tolerantes a fallos, otros procesos de servicio (incidentes, problemas y Gestión de Cambios) u otros recursos adicionales de la Gestión de Servicios. Los recursos financieros de los que se dispone son los que determinan principalmente las opciones y elecciones.

14.4.3 Diseño del Mantenimiento Dado que es poco probable que la disponibilidad sea ininterrumpida, se deben considerar aquellos periodos sin disponibilidad. Cuando se interrumpe un servicio TI, es importante arreglar rápida y correctamente el fallo para cumplir con los estándares de disponibilidad acordados. El diseño de la recuperación incluye temas tales como un proceso de Gestión de Incidentes eficaz con escalados, comunicaciones, y procedimientos de soporte y recuperación apropiados. Se deben definir claramente las tareas, las responsabilidades y la autoridad.

14.4.4 Temas clave de seguridad La fiabilidad está íntimamente relacionada. Una pobre información de seguridad puede afectar la disponibilidad del servicio. Se deben considerar los temas de seguridad y su impacto en la provisión de servicios durante la fase de planificación. Una elevada disponibilidad puede contar con un soporte de seguridad de la eficaz. Algunos de los temas son: - Determinar quién se encuentra autorizado para acceder a áreas de seguridad. - Determinar autorizaciones críticas a emitir.

148

Gestión de Servicios TI basado en ITIL

14.4.5 Gestión del Mantenimiento Por lo general, siempre habrá ventanas de faltas de disponibilidad programadas. Estos periodos se pueden usar para realizar tareas preventivas, como actualizaciones de hardware y software. También se pueden implementar cambios durante este tiempo. En una economía de 24 horas, sin embargo, resulta difícil determinar las ventanas de mantenimiento correctas. Las actividades de definición, implementación, y verificación de las actividades de mantenimiento se han convertido en puntos importantes de la Gestión de la Disponibilidad. El mantenimiento se debe realizar cuando el impacto en los servicios sea mínimo. Esto significa que debe conocerse de antemano cuáles son los objetivos del mantenimiento, cuándo se debe hacer el mantenimiento y qué actividades de mantenimiento están involucradas (puede basarse en la CFIA). Esta información resulta muy importante para la Gestión de Cambios y para las otras actividades.

I4.4.6 Medición e informes La medición y los informes son actividades importantes para la Gestión de la Disponibilidad, ya que son la base de verificación de los acuerdos de servicio, la resolución de problemas y la definición de propuestas de mejora. Si no lo mides, no puedes manejarlo. Si no lo mides, no puedes mejorarlo. Si no lo mides, probablemente no te interesa. Si no puedes influenciar en ello, no lo midas. El ciclo de vida de cada incidente incluye los siguientes elementos: -

-

Momento del incidente - la hora a la que el usuario nota la falta, o cuando la falta se identifique por otros medios (técnica o físicamente). Detección - se informa al proveedor del servicio sobre el fallo. El estado del incidente es ahora "informado". El tiempo que lleva esto se conoce como hora de detección. Respuesta - el proveedor de servicio necesita tiempo para responder. Esto se conoce como hora de respuesta. Este tiempo se utiliza para el diagnóstico, que después de la reparación puede seguirse. El proceso de la Gestión de Incidentes incluye la Aceptación y Registro, la Clasificación, la Asociación, el Análisis y el Diagnóstico. Reparación - el proveedor de servicio restaura el servicio o los componentes que provocaron el fallo. Recuperación del servicio - se restituye el servicio. Esto incluye actividades como la configuración e inicialización, y restitución del servicio al usuario.

La Figura 14.3 ilustra los periodos que se pueden medir.

Figura 14.3 Medición de la Disponibilidad (fuente: OGC)

149

Gestión de Disponibilidad

Tal como lo muestra la figura, el tiempo de respuesta de la organización TI y cualquier contratista externo es uno de los factores que determinan la interrupción. Dado que la organización TI puede controlar este factor, y afecta la calidad del servicio en forma directa, se pueden incluir acuerdos al respecto del SLA. Se pueden promediar las mediciones para dar una buena impresión de los factores relevantes. Los promedios se pueden utilizar para determinar los niveles de servicio alcanzados y para estimar la disponibilidad futura esperada de un servicio. Esta información también se puede utilizar para desarrollar planes de mejora. La Gestión de la Disponibilidad usa por lo general las siguientes métricas: -

Tiempo Medio de Reparación - MTTR - tiempo medio entre la aparición del fallo y la recuperación del servicio, también conocido como Tiempo de Parada (downtime). Es la suma del tiempo de detección y el de resolución. Esta métrica se relaciona con la recuperación y la utilidad del servicio. Tiempo Medio entre Fallos - MTBF - tiempo medio entre la recuperación del incidente y la aparición del próximo, también conocido como Tiempo de Disponibilidad (uptime). Esta métrica se relaciona con la fiabilidad del servicio. Tiempo Medio entre los Incidentes del Sistema - MTBSI - tiempo medio entre la aparición de dos incidentes consecutivos. El MTBSI es la suma de MTTR y MTBF.

La tasa de MTBF y la de MTBSI indican si hay muchos fallos menores o sólo algunos mayores. Los informes de disponibilidad incluyen las siguientes métricas: -

Tasa de disponibilidad (o falta de disponibilidad) en términos de MTTR, MTBF y MTBSI. Tiempo de disponibilidad y Tiempo de Parada total. Número de fallos. Información adicional sobre fallos que real o potencialmente dan como resultado una falta de disponibilidad más alta que la acordada.

El problema con los informes de disponibilidad es que las métricas que se presentan pueden no corresponder con la percepción del cliente. Es por lo tanto importante informar sobre la disponibilidad desde el punto de vista del cliente. El informe debe proporcionar en primer lugar información sobre la disponibilidad del servicio para las funciones esenciales del negocio, los servicios de aplicación, y la disponibilidad de los componentes TI técnicos. Los informes deben redactarse en un lenguaje que el cliente pueda entender.

14.4.7 Desarrollo del Plan de Disponibilidad El Plan de Disponibilidad es uno de los documentos de más largo alcance de la Gestión de la Disponibilidad. Es un plan a largo plazo que tiene que ver con la disponibilidad para los próximos años. No es un plan de implementación para la Gestión de la Disponibilidad. El plan debería ser un documento vivo. Primero debería poner de manifiesto la situación actual y en una etapa futura se puede expandir para incluir actividades de mejora de los servicios y premisas existentes. Un plan extenso y preciso requiere una cooperación entre áreas tales como la Gestión de Niveles de Servicio, la Gestión de Continuidad de Servicios TI, la Gestión de la Capacidad, y la Gestión Financiera para los servicios TI y el Desarrollo de Aplicaciones (en forma directa o a través de la Gestión de Cambios).

14.4.8 Herramientas Para ser eficaces, la Gestión de la Disponibilidad debe contar con un número de herramientas para las siguientes actividades: -

150

Determinación del Tiempo de Parada Registro de información histórica Generación de informes Análisis estadístico Análisis de impacto

Gestión de Servicios TI basado en ITIL

La Gestión de la Disponibilidad utiliza la información de los registros de la Gestión de Incidentes, la CMDB y la Base de Datos de Capacidad. La información se puede guardar en una Base de Datos de Gestión de la Capacidad (AMDB) dedicada.

14.4.9 Métodos y técnicas Ahora hay un amplio espectro de métodos y técnicas de Gestión de la Disponibilidad para la planificación del soporte, mejora e información. Más adelante se discuten los más importantes. Análisis de Impacto del Fallo de Componente (CFIA) Este método utiliza una matriz de disponibilidad con componentes estratégicos y sus roles en cada servicio. Una CMDB eficaz, que define las relaciones entre servicios y recursos de producción puede ser de utilidad cuando se desarrolla esta matriz. Un ejemplo de una matriz CFIA en la Figura 14.4 muestra que los Item de Configuración que se marcan con una "X" para muchos servicios son elementos importantes de la infraestructura TI (análisis horizontal), y los servicios que se marcan con frecuencia con "X" son complejos y sensibles a fallos (análisis vertical). Este método también se puede aplicar a terceros (CFIA Avanzada). Elemento de Configuración: PC #1 PC #2 Cable M Cable #2 Outlet #1 Outlet #2 Segmento Ethernet Router Vínculo WAN Router Segmento NIC 5ervídor Sistema de software Aplicación Base de datos

Servicio A B B X X X X X X A B B B X

Servicio B B B B B X X X X X X X A B B B X

X = La falla significa que el sistema no está disponible A = Configuración autoprotectiva (Failsafe) B = Autoprotectivo (Failsafe), con tiempo de alteración " " = Sin impacto

Figura 14.4 Matriz CFIA (Fuente: OGC)

Análisis del Árbol de Fallos (FTA) El Análisis del Árbol de Fallos es una técnica que se usa para identificar la cadena de eventos que producen el fallo de un servicio. Se diseña un Árbol de Fallos separado para cada servicio, utilizando símbolos Boolean. El Árbol de Fallos se atraviesa desde abajo hacia arriba. El FTA distingue los siguientes eventos: -

Eventos básicos - entradas en el diagrama (círculos) como falta de energía y errores de los operadores. Estos eventos no se investigan. Eventos de resultado - nodos en el diagrama, resultado de una combinación de eventos anteriores. Eventos condicionales - los eventos que se producen bajo ciertas condiciones, como fallo del aire acondicionado. Eventos gatillo - eventos que provocan otros eventos, como un cierre automático iniciado por un UPS.

151

Gestión de Disponibilidad

Figura 14.5 Análisis de Falla TREE (fuente: OGC)

Eventos que se pueden combinar con operaciones lógicas como: - Operación AND - el Evento de Resultado ocurrirá si todas las entradas se producen al mismo tiempo. - Operación OR - el Evento de Resultado ocurrirá si se presentan una o más de las entradas. - Operación XOR - el Evento Resultante se producirá si se presenta solo una de las entradas. - Operación de inhibición/represión - el Evento Resultante ocurrirá si no se cumplen las condiciones de entrada. Análisis de Riesgo CCTA y Método de Gestión (CRAMM) Este método se trata en el capítulo sobre Gestión de Continuidad de Servicios T I.

152

Gestión de Servicios TI basado en ITIL Cálculos de Disponibilidad Las métricas que se discuten más arriba se pueden utilizar para concretar los acuerdos de disponibilidad de servicio con el cliente. Estos acuerdos se incluyen en el Acuerdo de Nivel de Servicio. La formula que se muestra a continuación se puede utilizar para determinar si la disponibilidad alcanzada cumple con los requisitos de disponibilidad acordados.

% Disponibilidad =

AST − DT × 100% AST

Figura 14.6 Formula de disponibilidad (fuente: OCC)

Los montos de Tiempo de Disponibilidad alcanzados para la diferencia entre el Tiempo de Disponibilidad Acordado (Agreed Service Time, AST) y Tiempo de Parada Actual durante el Tiempo de Disponibilidad Acordado (Actual Downtime during agreed service time, DT). Ejemplo: se acordó que el servicio puede tener un 9 8% de disponibilidad los días de la semana entre las 07:00 y las 19:00 horas, y el servicio no funcionó durante dos horas durante esta ventana, entonces el Tiempo de Disponibilidad alcanzado (porcentaje de disponibilidad) sería:

(5 ×12) − 2 × 100% = 96.7% (5 × 12) Análisis de Interrupción de Servicio (SOA) SOA es una técnica que puede emplearse para identificar las causas de los fallos para investigar la eficacia de la organización TI y sus procesos, y para presentar e implementar las propuestas de mejoras. Las características de un SOA son: -

Tiene un alto alcance ya que no se limita a la infraestructura, también cubre procesos, procedimientos y aspectos culturales. Los temas se consideran desde la perspectiva del cliente. Se implementa junto con los representantes del cliente y la organización TI {equipo SOA).

Los beneficios incluyen un planteamiento más eficaz, unas comunicaciones directas con el cliente y el abastecedor; y una base más amplia para las propuestas de mejora. Observación de Técnicas Post (TOP) Cuando se usa el método TOP, un equipo TI de especialistas dedicados pone toda su atención en un solo aspecto de la disponibilidad. Este método puede ser útil cuando las herramientas de rutina no proporcionan el soporte necesario. El TOP también puede combinar la experiencia de los diseñadores y de los gestores de sistema. Los aspectos clave de este método son un planteamiento eficaz, efectivo e informal que ofrece resultados rápidamente.

153

Gestión de Disponibilidad

14.5 Control del proceso 14.5.1 Presentación de Informes Más arriba se mencionaron los informes de disponibilidad a entregar al cliente. Se puede informar sobre las siguientes métricas para el control del proceso: -

Tiempo de detección Tiempos de respuesta Tiempos de reparación Tiempos de recuperación Uso exitoso de los métodos correctos (CFIA, CRAMM, SOA) Tiempo del procesado de implementación: servicios, SLAs, y grupos de clientes cubiertos por los SLAs

Algunas métricas se pueden determinar para cada servicio, equipo o dominio de infraestructura (red, centro de proceso de datos, y entorno de la estación de trabajo).

14.5.2 Factores de éxito críticos e indicadores de rendimiento Los factores de éxito crítico de la Gestión de la Disponibilidad son: -

El negocio debe haber definido claramente los objetivos y deseos de disponibilidad. Se debe haber constituido la Gestión de Niveles de Servicio para formalizar los acuerdos. Ambas panes deben usar las mismas definiciones de disponibilidad y Tiempo de Parada. El negocio y la organización TI deben ser conscientes de los beneficios de la Gestión de la Disponibilidad.

Los siguientes indicadores de rendimiento muestran la eficacia y eficiencia de la Gestión de la Disponibilidad: -

Porcentaje de disponibilidad (uptime) por servicio o grupo de usuarios Duración del Tiempo de Parada Frecuencia del Tiempo de Parada

14.5.3 Funciones y roles La organización puede establecer el rol del Gestor de Disponibilidad para definir el control y el proceso. La tarea del Gestor de Disponibilidad podría incluir los siguientes elementos: -

154

Definir y desarrollar el proceso en la organización. Garantizar que los servicios TI se diseñen para los niveles de servicio alcanzados (en términos de disponibilidad, fiabilidad, utilidad, mantenimiento y recuperación) se correspondan con los niveles de servicio acordados. Producir informes. Optimizar la disponibilidad de la infraestructura TI para proporcionar una mejora del coste del servicio para el negocio.

Gestión de Servicios TI basado en ITIL

14.6 Problemas y costes 14.6.1 Problemas Muchos problemas tienen que ver con la organización. Los problemas a esperar incluyen: -

La gestión senior divide la responsabilidad de la disponibilidad entre muchas disciplinas (gestores de línea, de proceso). Cada gestor se siente responsable de su propia área, y no existe coordinación total. La gestión TI no entiende el valor agregado que se proporciona a los procesos de Gestión de Incidentes, Problemas, Cambios. Se considera suficiente el nivel de disponibilidad actual. No hay apoyo para designar un único gestor responsable de proceso. El gestor de proceso no tiene la autoridad necesaria.

Aún con apoyo suficiente de la gerencia, todavía pueden haber problemas debido a: -

Infravaloración de los recursos. Falta de herramientas de medición eficaces y de elaboración de informes. Falta de otros procesos tales como Gestión de Niveles de Servicio, Gestión de Configuraciones, y Gestión de Problemas.

Estos problemas se pueden solucionar con un buen apoyo de gestión, con la persona correcta con responsabilidad total sobre el proceso, con herramientas apropiadas y con la resolución rápida y eficaz de los problemas existentes. Si no se utiliza como corresponde a la Gestión de la Disponibilidad se pueden presentar los siguientes problemas: -

Será difícil definir los estándares de disponibilidad apropiados. Será más difícil guiar a los abastecedores internos y externos. Será difícil comparar los costes de disponibilidad y falta de disponibilidad. Si durante la etapa de diseño no se consideraron los estándares de disponibilidad, la posterior modificación para alcanzar estos estándares puede resultar mucho más cara. No se cumple con los estándares de disponibilidad y se pueden provocar fallos al intentar alcanzar los objetivos comerciales. Puede disminuir la satisfacción del cliente.

Apuntar a una disponibilidad excesiva es otro problema potencial. Los costes se elevarán mucho de una manera no proporcional a los beneficios. Siempre habrá posibilidad de que exista Tiempo de Parada. La Gestión de la Disponibilidad juega un rol importante para resolver estos eventos no deseables.

155

Gestión de Disponibilidad

14.6.2 Costes Los costes de la Gestión de la Disponibilidad son: -

Coste de implementación Costes de personal Costes de instalación Herramientas de medición y elaboración de informes

La Gestión de la Disponibilidad debe identificar las inversiones necesarias para mejora la disponibilidad en etapas tempranas. Se debe realizar un análisis coste beneficio en todos los casos. En general, los costes aumentarán cuando aumente la disponibilidad requerida. Encontrar una solución óptima es una tarea importante de la Gestión de la Disponibilidad. La experiencia muestra que lo Óptimo se puede alcanzar más a menudo con recursos limitados que con una gran inversión. La discusión sobre costes y beneficios puede guiarse preguntando cuáles serán los costes si se ignora por completo a la Gestión de la Disponibilidad y se llega a una situación en la que no se cumple con los requisitos de disponibilidad acordados. Esto tendrá el siguiente impacto en el cliente: -

Productividad reducida Rotación y ganancia reducida Costes de recuperación Demandas potenciales de terceros, etc.

Los siguientes aspectos son difíciles de cuantificar pero resultan igualmente importantes: -

Pérdida de buena voluntad y clientes Pérdida de reputación y confianza Pérdida de motivación y satisfacción del personal

El proceso de la Gestión de !a Disponibilidad puede contribuir a los objetivos de la organización TI en estas áreas proporcionando los servicios requeridos a un coste aceptable y justificable.

156

Gestión de Servicios TI basado en ITIL

Capítulo 15: Gestión de la Seguridad 15.1 Introducción Los procesos del negocio ya no pueden operar sin la provisión de información. De hecho, cada vez más procesos del negocio consisten puramente de uno o más sistemas de información. La Gestión de la Seguridad de la Información es una actividad importante que tiene como objetivo controlar la provisión de información y prevenir el uso sin autorización de la misma. Durante muchos años, se ignoró a la Gestión de la Seguridad de la Información. Sin embargo, esto está cambiando. La seguridad es considerada como uno de los principales desafíos para los próximos años. Dado el amplio uso de Internet y del e-commerce está aumentando el interés en esta disciplina. Cada vez más negocios abren gateways electrónicos en sus instalaciones. Esto introduce el riesgo de intrusión y plantea algunas preguntas importantes para el negocio. ¿Qué riesgos queremos cubrir, y qué medidas se deben tomar ahora y en el próximo presupuesto? La gestión profesional debe tomar decisiones y tales decisiones sólo se pueden tomar si se lleva acabo un completo análisis del riesgo. Este análisis debe servir a la Gestión de la Seguridad para determinar los requisitos de ésta. Los requisitos de seguridad del negocio afectan a los proveedores de servicio TI y se deberían especificar en los Acuerdos de Nivel de Servicio. La Gestión de la seguridad apunta a garantizar que se provean, en todo momento, los aspectos de seguridad de los servicios al nivel que se acordó con el cliente. La seguridad es ahora un aspecto de calidad esencial de la gestión. La Gestión de la Seguridad integra la seguridad en la organización desde el punto de vista del proveedor de servicio. El Código de Buenas Prácticas para la Gestión de la Seguridad de la Información (BS 7799) ofrece una guía para desarrollar, introducir y evaluar las medidas de seguridad.

15.1.1 Conceptos Básicos La Gestión de la Seguridad se desarrolla bajo el paraguas de la Seguridad de Información que tiene como objetivo garantizar la seguridad de ésta. Seguridad se refiere a no ser vulnerable a los riesgos conocidos y a evitar los errores conocidos cuando sea posible. El objetivo es proteger el valor de la información. Este valor depende de la confidencialidad, integridad y disponibilidad. -

Confidencialidad - proteger información contra el acceso y uso no autorizado. Integridad - tener la información exacta, completa y a tiempo. Disponibilidad - disponer de acceso a la información en el momento acordado. Esto depende de la continuidad que brinden los sistemas de procesamiento de información.

Los aspectos secundarios incluyen la privacidad (confidencialidad, e integridad de la información relacionada con los individuos), el anonimato, y la verificación (poder verificar que la información se utiliza de manera correcta y que las medidas de seguridad son eficaces).

15.2 Objetivos En décadas recientes, casi todos los negocios se han vuelto más dependientes de los sistemas de información. El uso de las redes también ha crecido, no sólo dentro de los negocios sino también entre ellos, y entre los negocios y el mundo exterior. La complejidad en aumento de la infraestructura TI implica que los negocios ahora son más vulnerables a fallos técnicos, errores humanos, actos humanos malintencionados, hackers y crackers, virus de ordenadores, etc. Esta creciente complejidad necesita un planteamiento de gestión unificado. La Gestión de la Seguridad tiene vínculos con los otros procesos. Algunas actividades de seguridad son realizadas por otros procesos ITIL, bajo la supervisión de la Gestión de la Seguridad.

157

Gestión de la Seguridad La Gestión de la Seguridad tiene dos objetivos: -

Cumplir con los requisitos de seguridad de los SLAs y con otros requisitos externos relacionados con contratos, legislación, y políticas impuestas desde el exterior. Brindar Proporcionar un nivel de seguridad básico, independiente de los requisitos externos.

La Gestión de la Seguridad es esencial para mantener la operatividad de la organización TI sin interrupciones. También ayuda a simplificar la Gestión de Niveles de Servido de la Seguridad de la Información, ya que es mucho más difícil manejar gran cantidad de diferentes SLAs que un número limitado. Los SLAs especifican los requisitos de seguridad, complementados con documentos sobre políticas y otros requisitos externos. El proceso también recibe información sobre temas de seguridad de otros procesos, como por ejemplo de los incidentes de seguridad. Las salidas de los SLAs incluyen información sobre la implementación alcanzada, sobre los informes de excepción y sobre el planeamiento de seguridad de trabajo habitual. En el presente muchas organizaciones tratan la seguridad de la información a nivel estratégico con políticas de información y planes de información, y a nivel de operaciones comprando herramientas y otros productos de seguridad. Se presta poca atención a la gestión activa de la seguridad de la información, al análisis continuo, a la traducción de políticas en opciones técnicas, y a la certeza de que las medidas de seguridad siguen siendo eficaces cuando cambian los requisitos y el entorno. La consecuencia de este vínculo perdido entre el nivel estratégico y el táctico es que a nivel de gestión táctica se realizan importantes inversiones en medidas que ya nos son relevantes, en el momento en que se deberían tomar medidas más eficaces. La Gestión de la Seguridad tiene como objetivo garantizar que se tomen medidas eficaces en la Seguridad de la Información a niveles tácticos, estratégico y de operación.

15.2.1 Beneficios La Información no es un objetivo en sí mismo, sino que tiende a servir a los intereses del negocio u organización. Algunas informaciones y algunos servicios de información serán más importantes que otros para la organización. Una seguridad a medida se desarrolla al equilibrar las medidas de seguridad y el valor de la información, y las amenazas del ambiente de procesamiento. Una provisión de información eficaz, con seguridad de la información correcta es importante para la organización por dos razones: -

Razones internas - una organización sólo puede operar eficazmente si dispone cuando corresponde de la información correcta y completa. El nivel de la seguridad de la información debe ser apropiado para esto. Razones externas - los procesos en una organización crean productos y servicios que se ponen a disposición del mercado o sociedad para lograr objetivos definidos. Si no se dispone de la información correcta, se ofrecerán subproductos y servicios que no podrán utilizarse para alcanzar los objetivos y que amenazarán la supervivencia de la organización. Una adecuada Seguridad de la Información es una condición importante para disponer de una provisión de información adecuada. La importancia de la Seguridad de la Información externa por lo tanto, está determinada en parte por la importancia interna.

La Seguridad puede brindar un importante valor agregado a un sistema de información. Una seguridad eficaz contribuye a la continuidad de la organización y ayuda a alcanzar sus objetivos.

15.3 El Proceso La organization y sus sístemas de información cambian. Las listas de verificación tales como el Código de Prácticas de la Gestión de la Seguridad de la Información son estáticas y recomiendan de manera insuficiente cambios rápidos en TT. For tal razón, las actívidades de la gestión de la seguridad se deben revisar condnuamente para garantizar su eficacia. La Gestión de la Seguridad viene a ser un ciclo sin fin de planificar, hacer, chequear y actuar. Mas adelante, se tratan las actividades que desarrolla la Gestión de la Seguridad, o en otros procesos bajo el control de ésta.

158

Gestión de Servicios TI basado en ITIL

Figura 15.1 Proceso de la Gestión de la Seguridad (fuente: OGC)

La Figura 15.1 muestra el ciclo de la Gestión de la Seguridad. Los requerimientos del cliente aparecen en el margen superior derecho, como entrada del proceso. La sección de seguridad del Acuerdo de Nivel de Seguridad define estos requerimientos en términos de los servicios de seguridad y del nivel de seguridad a proporcionar. El proveedor de servicio comunica estos acuerdos a la organización en forma de Plan de Seguridad, definiendo los estándares de seguridad y los Acuerdos de Nivel de Operaciones. Se implementa el plan y se evalúa la implementación. Posteriormente, se actualizan. La Gestión de Niveles de Servicio informa a los clientes sobre estas actividades. Así, el cliente y el proveedor de servicios forman un proceso cíclico completo. El cliente puede modificar los requisitos en base a los informes y el proveedor de servicio puede ajustar el plan o su implementación teniendo en cuenta estas observaciones o puede intentar cambiar los acuerdos que define el SLA. La función de control aparece en el medio de la Figura 15.1, este diagrama se utilizará aquí para discutir las actividades de la Gestión de la Seguridad.

15.3.1 Relaciones con los otros procesos La Gestión de la Seguridad tiene relación con los otros procesos ITIL (ver Figura 1 5.2). Esto es porque los otros procesos llevan a cabo actividades relacionadas con la seguridad. Estas actividades se desarrollan normalmente bajo la responsabilidad de los procesos pertinentes y del gestor de proceso. Sin embargo, la Gestión de la Seguridad da instrucciones a los otros procesos sobre la estructura de las actividades relacionadas con la seguridad. Por lo general, estos acuerdos se definen tras una consulta entre el Gestor de Seguridad y los otros gestores de proceso.

159

Gestión de la Seguridad

Figura 152 Relaciones de la Gestión de la Seguridad con los otros procesos (fuente: OCC)

Gestión de Configuraciones

En el contexto de Seguridad de Información, la Gestión de Configuraciones es en primera instancia relevante porque puede clasificar los Ítems de Configuración (CI). Esta clasificación vincula la CI con las medidas de seguridad o procedimientos. La clasificación de un CI indica su confidencialidad, integridad y disponibilidad necesaria. Esta clasificación se basa en los registros de seguridad del SLA. El cliente de la organización TI determina la clasificación ya que solo el cliente puede decidir cuán importante es la información o los sistemas de información para el negocio. El cliente basa la clasificación en el análisis de hasta qué grado los procesos del negocio dependen del sistema de información y de la información. Después, la organización asocia la clasificación con las CIs que corresponda. La organización TI también debe implementar este conjunto de medidas de seguridad para cada nivel de clasificación. Este conjunto de medidas se puede describir en los procedimientos. Ejemplo: "Procedimiento para manejar el almacenamiento de datos a publicar con datos de personal". El SLA puede definir los conjuntos de medidas de seguridad para cada nivel de clasificación. El sistema de clasificación debe adaptarse siempre a la organización de clientes. Sin embargo, para simplificar la gestión es aconsejable utilizar un sistema de clasificación unificado, aún si la organización TI tiene más de un cliente. En resumen, la clasificación es un tema clave. La CMDB debería indicar la clasificación de cada CI. Esta clasificación vincula al CI con el conjunto de medidas de seguridad o procedimiento que corresponde. Gestión de Incidentes La Gestión de Incidentes es un proceso importante para informar sobre los incidentes de seguridad. Dependiendo de la naturaleza del incidente, los incidentes de seguridad pueden estar cubiertos por un procedimiento distinto que los otros. Por lo canto, es esencial que la Gestión de Incidentes reconozca los incidentes como tales. Cualquier incidente que pueda interferir con el alcance de los requisitos de seguridad del SLA se clasifica como incidente de seguridad. Resulta útil incluir en el SLA una descripción del tipo de incidentes a considerar como incidente de seguridad. Cualquier incidente que interfiera en el logro del nivel de seguridad básico interno (línea de referencia) cambien se clasifica como incidente de seguridad. Los usuarios no son los únicos que generan informes de incidentes. El proceso de gestión, posiblemente en base a las alarmas o los datos de auditoría de los sistemas Cambien genera informes.

160

Gestión de Servicios TI basado en ITIL

Resulta imprescindible que la Gestión de Incidentes reconozca todos los incidentes de seguridad para garantizar el comienzo de los procedimientos correctos para tratar éstos. Es aconsejable incluir los procedimientos para los diferentes tipos de incidentes de seguridad en los planes SLA y practicar el procedimiento. Además, es aconsejable acordar un procedimiento para comunicar la sucesión de éstos. Es común que haya pánico por rumores desproporcionados. De igual manera, es común que el daño resulte de un fallo en comunicar a tiempo los incidentes de seguridad. Es aconsejable dirigir todas las comunicaciones externas a través del Gestor de Seguridad. Gestión de Problemas Gestión de Problemas es responsable de identificar y solucionar los fallos de seguridad estructurales. Un problema también puede introducir un riesgo de seguridad. En ese caso, la Gestión de Problemas debe incluir a la Gestión de la Seguridad para resolver el problema. Finalmente, la solución o el workaround del problema o error conocido se deben evaluar siempre para garantizar que no introduzca nuevos problemas de seguridad. Esta verificación se debe basar en el cumplimiento del SLA y en los requisitos de seguridad interna. Gestión de Cambios Las actividades de la Gestión de Cambios generalmente se encuentran asociadas con la seguridad porque la Gestión de Cambios y de la Seguridad son interdependientes. Si se ha alcanzado un nivel de seguridad aceptable, y se maneja con el proceso de Gestión de Cambios, se puede garantizar que el mismo nivel de seguridad se proporcionará después de los cambios. Hay un número de operaciones estándar para garantizar el mantenimiento de este nivel de seguridad. Cada RFC está asociada con cierta cantidad de parámetros que gobiernan el proceso de aceptación. Los parámetros de urgencia e impacto se pueden suplementar con un parámetro de seguridad. Sí la RFC puede tener un impacto significativo en la información de seguridad entonces se necesitarán pruebas de aceptación y procedimiento más extensos. La RFC también debe incluir una propuesta para tratar los temas de seguridad. Otra vez, se deberá basar en los requisitos SLA y en el nivel básico de seguridad interna que necesita la organización TI. Así, la propuesta incluirá un conjunto de medidas de seguridad, basado en el código de prácticas. Preferentemente, el Gestor de Seguridad (y posiblemente el Oficial de Seguridad del Cliente) debe formar parte del Consejo Asesor de Cambio (CAB). Sin embargo, no se debe consultar al Gestor de Seguridad sobre todos los cambios. La seguridad por lo general debería estar integrada en las operaciones de rutina. El Gestor de Cambios debería poder decidir si ellos o el CAB necesitan información del Gestor de Seguridad. Asimismo, el Gestor de Seguridad no es necesario que esté involucrado en la selección de las medidas para las CIs cubiertas por un RFC. Esto es porque el marco de trabajo de las medidas relevantes ya debería existir. Cualquier pregunta sólo debería tener relación con la forma en que se implementan éstas. Cualquier medida de seguridad asociada a un cambio se debe implementar al mismo tiempo que éste, y debe incluirse en las pruebas. Las pruebas de seguridad no son iguales a las evaluaciones normales. Las pruebas normales tienden a investigar si las funciones definidas están disponibles. Las pruebas de seguridad, además de mencionar la disponibilidad de las funciones de seguridad, también mencionan la ausencia de otras funciones no deseables ya que podrían reducir la seguridad del sistema. En términos de seguridad, la Gestión de Cambios es uno de los procesos más importantes ya que esta gestión introduce nuevas medidas de seguridad a la infraestructura TI al realizar cambios en la misma infraestructura.

161

Gestión de la Seguridad Gestión de Versiones Todas las nuevas versiones de hardware, software, equipos de comunicaciones de datos, etc., deben estar controladas y puestas en funcionamiento por la Gestión de Versiones. Este proceso debería garantizar que: -

Se utilice el hardware y el software que corresponde. Se pruebe el hardware y el software antes de usarlos. La introducción está correctamente autorizada usando un cambio El software es legal. El software está libre de virus y que los virus no se introducen durante la distribución. Se conocen los números de versión y que la Gestión de Configuraciones los registró en la CMDB. El rollout está manejado eficazmente.

Este proceso también usa un procedimiento de aceptación regular que debería incluir aspectos de Seguridad de Información. Es muy importante considerar los aspectos de seguridad durante las pruebas y la aceptación. Esto significa que los requisitos y las medidas definidas en el SLA deberán cumplirse en todo momento. Gestión de Niveles de Servicio La Gestión de Niveles de Servicio garantiza que se definan y se alcancen los acuerdos sobre los servicios a proveer al cliente. Los Acuerdos de Nivel de Servicio también deberían mencionar las medidas de seguridad. El objetivo es optimizar el nivel de servicio provisto. La Gestión de Niveles de Servicio incluye cierta cantidad de actividades de seguridad relacionadas, en las que la Gestión de la Seguridad juega un rol muy importante. 1. 2. 3. 4. 5. 6.

Identificar las necesidades de seguridad del cliente. Naturalmente, determinar las necesidades de seguridad es responsabilidad del cliente ya que estas necesidades se basan en los intereses del negocio. Identificar la factibilidad de los requisitos de seguridad del cliente. Proponer, discutir y definir el nivel de seguridad de los servicios TI en el SLA. Identificar, desarrollar y definir los requisitos de seguridad internos para los servicios TI (Acuerdos de Nivel de Operaciones). Monitorización de los estándares de seguridad (OLAs). Elaborar informes sobre los servicios TI a proveer.

La Gestión de la Seguridad proporciona entrada y soporte a la Gestión de Niveles de Servicio en lo relacionado con las actividades 1-3. Las actividades 4 y 5 están a cargo de la Gestión de la Seguridad. La Gestión de la Seguridad y los otros procesos dan entrada a la actividad 6. El Gestor de Nivel de Servicio y el de Seguridad deciden juntos quién desarrolla las actividades. Cuando se define un SLA por lo general se asume que existe un nivel de seguridad general básico (línea de referencia). Los requisitos de seguridad adicionales del cliente se deben especificar en el SLA. Gestión de la Disponibilidad Gestión de la Disponibilidad maneja la disponibilidad técnica de los componentes TI en relación a la disponibilidad del servicio. Se asegura la calidad de disponibilidad por la continuidad, el mantenimiento, y la resistencia. La Gestión de la Disponibilidad es el proceso más importante relacionado con la disponibilidad. Como muchas medidas de seguridad benefician tanto a la disponibilidad como a los aspectos de seguridad relativos a confidencialidad e integridad, es esencial coordinar eficazmente las medidas entre la Gestión de la Disponibilidad, la Gestión de Continuidad de Servicios TI y la Gestión de la Seguridad. Gestión de la Capacidad La Gestión de la Capacidad es responsable del mejor uso posible de los recursos TI, como se acordó con el cliente. Los requisitos de rendimiento se basan en los estándares cualitativos y cuantitativos definidos por la Gestión de Niveles de Servicio. Casi todas las actividades de la Gestión de la Capacidad afectan la disponibilidad y por lo tanto a la Gestión de la Seguridad.

162

Gestión de Servicios TI basado en ITIL Gestión de Continuidad de Servicios TI La Gestión de Continuidad de Servicios TI garantiza que el impacto de cualquier contingencia se límite a los niveles acordados con el cliente. Las contingencias no necesariamente deben derivar en desastres. Las actividades más importantes son la definición, mantenimiento, implementación, y la prueba del plan de contingencia así como la toma de medidas preventivas. Dados los aspectos de seguridad, hay vínculos con la Gestión de la Seguridad. Por otro lado, la falta de cumplimiento de los requisitos de seguridad básicos pueden considerarse en si una contingencia.

15.3.2 Sección Seguridad de los Acuerdos de Nivel de Servicio El Acuerdo de Nivel de Servicio define los acuerdos con el cliente. El proceso de la Gestión de Niveles de Servicio es responsable del SLA (ver también capítulo 10). El SLA es el conductor más importante de todos los procesos IT1L. La organización TI indica hasta qué punto se logran los requisitos del SLA. Los elementos de seguridad mencionados en el SLA deben corresponderse con las necesidades de seguridad del cliente. El cliente debe identificar el significado de todos los proceso del negocio (ver Figura 15.3).

Figura 15.3 Relaciones entre los procesos (fuente: OGC)

Estos procesos del negocio dependen de los servicios TI, y por ende de la organización TI. El cliente determina los requisitos de seguridad (requisitos de Seguridad de Información SLA no incluidos en la Figura 15.3) en base al análisis de riesgo. La Figura 15.4 muestra cómo se definen los elementos de seguridad del SLA

163

Gestión de la Seguridad

Figura 15.4 Desarrollo de la sección de seguridad del SLA

Los elementos de seguridad se discuten entre el representante del cliente y el proveedor de servicio. El proveedor de servicio compara los Requisitos de Nivel de Servicio de cliente con su propio Catálogo de Servicios que describe sus medidas de seguridad estándar (Línea de Referencia de Seguridad). El cliente puede tener requisitos adicionales. El cliente y el proveedor comparan los Requisitos de Nivel de Servicio y el Catálogo de Servicios. La sección seguridad del SLA puede tratar temas como la política general de Seguridad de Información, una lista de personal autorizado, procedimientos de protección activos, restricciones sobre el copiado de datos, etc.

15.3.3 Sección Seguridad del Acuerdo de Nivel de Operaciones El Acuerdo de Nivel de Operaciones es otro documento importante. Describe los servicios que proporciona el proveedor de servicios. El proveedor debe asociar estos acuerdos con las responsabilidades dentro de la organización. El Catálogo de Servicios da una descripción general de los servicios. El Acuerdo de Nivel de Operaciones traduce estas descripciones generales en todos los servicios y sus componentes, y la manera en la que se garantizan los acuerdos de niveles de servido dentro de la organización. Ejemplo: el Catálogo de Servicios menciona "manejar las autorizaciones por usuario y por individuo". Los Acuerdos de Nivel de Operaciones detallan esto para todos los servicios relevantes que brinda la organización TI. De esta manera, se define la implementación de la medida para los departamentos que proveen servicios UNIX, VMS, NT, Oracle, etc. Cuando es posible, los Requisitos de Nivel de Servicio del cliente se interpretan en términos del Catálogo de Servicios del proveedor, y se realizan acuerdos adicionales si es necesario. Tales medidas adicionales exceden el nivel de seguridad estándar. Cuando se diseña el SLA, también se debe acordar los Indicadores Clave de Rendimiento (KPI) y el criterio para la Gestión de la Seguridad. Los KPIs son parámetros medibles (métricas) y se establecen criterios de rendimiento a niveles alcanzables. Esto es más fácil para la disponibilidad porque por lo general se puede expresar en números. Sin embargo, es mucho más difícil para la integridad y la confidencialidad. Por tal razón, la sección seguridad del SLA es normal que describa las medidas necesarias en términos abstractos. El Código de Prácticas para Gestión de la Seguridad de Información se utiliza como set básico de medidas de seguridad. El SLA también describe cómo se mide el rendimiento. La organización TI (proveedor de servicio) debe proporcionar con regularidad informes a la organización de usuarios (cliente).

164

Gestión de Servicios TI basado en ITIL

15.4 Actividades 15.4.1 Control – Política y organización de la Seguridad de Información La actividad de control en el centra de la Figura 15.4 es el primer subproceso de la Gestión de la Seguridad y se relaciona con la organización y la gestión del proceso. Esto incluye el marco de trabajo de la Gestión de la Seguridad de la Información. Este marco de trabajo incluye subprocesos: la definición de los planes de seguridad, su implementación, la evaluación de la implementación y la incorporación de la evaluación en los planes de seguridad anuales (planes de acción). También se mencionan los informes que se dan al cliente vía la Gestión de Niveles de Servicio. Esta actividad define el subproceso, las funciones de seguridad, y los roles y responsabilidades. También describe la estructura de la organización, los acuerdos de elaboración de informes y la línea de control (quién instruye a quién, quién hace qué cosa, cómo se informa de la implementación). Esta actividad implementa las siguientes medidas del Código de Prácticas. Políticas - Desarrollo e implementación de la política, vínculos con las otras políticas. - Objetivos, principios generales y significado. - Descripción de los subprocesos. - Asignación de las funciones y responsabilidades en el subproceso. - Vínculos con otros procesos ITIL y su administración. - Responsabilidad general del personal. - Manejo de los incidentes de seguridad. Organización de la Seguridad de la Información: - Marco de trabajo de la gestión. - Estructura administrativa (estructura de organización). - Asignación de responsabilidad con más detalles. - Creación de un Comité de Dirección de Seguridad de la Información. - Coordinación de la Seguridad de la Información. - Herramientas acordadas (p. ej. para análisis de riesgo y mejora de conocimiento). - Descripción del proceso de autorización de las instalaciones TI consultando al cliente. - Consejo de especialistas. - Cooperación entre organizaciones, comunicaciones internas y externas. - Auditoría de los Sistemas de Información independientes. - Principios de seguridad para acceso de terceros. - Información de Seguridad en los contratos con terceros.

15.4.2 Plan El subproceso de planificación incluye definir la sección de seguridad del SLA junto con la Gestión de Niveles de Servicio, y las actividades en los Contratos de Apoyo relacionados con la seguridad. Los objetivos en el SLA, que se definen en términos generales, se detallan y se especifican en un Acuerdo de Nivel de Operaciones. Un OLA puede ser considerado como el plan de seguridad de una unidad de organización del proveedor de Servicio y como un plan de seguridad específico, por ejemplo para cada plataforma TI, aplicación y red. El subproceso de planeamiento no sólo recibe entradas del SLA sino también de los principios de política de proveedor (del subproceso de Control). Ejemplos de estos principios incluyen:

165

Gestión de la Seguridad "Cada usuario debe ser identificable como único", y "Se brinda un nivel de seguridad básico a todos los clientes en todo momento". Los Acuerdos de Nivel de Operaciones para la Seguridad de la Información (planes de seguridad específicos) se diseñan y se implementan utilizando los procedimientos normales. Esto significa que si se necesitan actividades en otros procesos, tendrá que haber coordinación con estos procesos. Cualquier cambio necesario a la infraestructura TI los realiza la Gestión de Cambios usando las entradas que le da la Gestión de la Seguridad. El Gestor de Cambios es el responsable del proceso de Gestión de Cambios. El subproceso de Planificación se discute con la Gestión de Niveles de Servicio para definir, actualizar y cumplir con la sección de seguridad del SLA. El Gestor de Nivel de Servicio es responsable de esta coordinación. El SLA debe definir los requisitos de seguridad, si es posible en términos medibles. La sección seguridad del acuerdo debería garantizar que todos los requisitos y estándares de seguridad del cliente puedan ser alcanzados y verificados.

15.4.3 Implementar El subproceso de implementación tiene como objetivo implementar todas las medidas especificadas en los planes. Este subproceso puede contar con la ayuda de la siguiente lista de verificación: Clasificación y Gestión de los recursos TI: - Dar entradas para mantener las CIs en el CMDB. - Clasificar los recursos TI de acuerdo con las líneas básicas acordadas. Seguridad Personal: - Tareas y responsabilidades en las descripciones del trabajo. - Screening. - Acuerdos de confidencialidad para el personal. - Formación. - Guías para el personal que maneja incidentes de seguridad y observa debilidades en seguridad. - Medidas disciplinarias. - Mayor conocimiento de seguridad. Administrando la seguridad: - Implementación de las responsabilidades, implementación de la separación del trabajo. - Instrucciones de operación escritas. - La seguridad debe incluir el ciclo de vida entero, debería haber guías de referencia para el desarrollo del sistema, la prueba, aceptación y operaciones de mantenimiento y eliminación. - Separación de los ambientes de desarrollo y de pruebas de producción. - Procedimientos para tratar los incidentes (manejados por la Gestión de Incidentes). - Implementación de las instalaciones de recuperación. - Dar entradas a la Gestión de Cambios. - Implementación de medidas de protección contra virus. - Implementación de medidas de administración para ordenadores, aplicaciones, redes y servicios de red. - Manejo y seguridad de los datos a publicar. Control de Acceso: - Implementación de la política de acceso y del control de acceso. - Mantenimiento de los privilegios de acceso de los usuarios y las aplicaciones para redes, servicios e red, ordenadores y aplicaciones. - Mantenimiento de barreras de seguridad para la red (firewalls, servicios de discado, puentes y routers). - Implementación de medidas para la identificación y autentificación de los sistemas informáticos, estaciones de trabajo y PCs de la red.

166

Gestión de Servicios TI basado en ITIL

15.4.4 Evaluar Es esencial la evaluación independiente de la implementación de las medidas planeadas. Esta evaluación es necesaria para evaluar el rendimiento. Los resultados del subproceso de evaluación pueden usarse para actualizar las medidas acordadas con el cliente, y también pata su implementación. Los resultados de la evaluación pueden sugerir cambios y en ese caso se define y se eleva una RFC al proceso de Gestión de Cambios. Hay tres formas de evaluación: -

Auto-evaluaciones que se implementan primero por la línea de organización de los procesos. Auditorías internas llevadas a cabo por el auditor. Auditorías externas llevadas a cabo por auditores externos.

A diferencia de las autoevaluaciones, las auditorías no son realizadas por el mismo personal que desempeña los otros subprocesos. Esto garantiza que se separen las responsabilidades. Las auditorías también pueden ser hechas por un departamento de Auditoría Interna. También se hacen evaluaciones cuando se producen incidentes de seguridad. Las principales actividades son: -

Verificación del cumplimiento de la política de seguridad y la implementación de los planes de seguridad. Desarrollo de auditorías de seguridad de los sistemas TI. Identificación y respuesta al uso inapropiado de los recursos TI. Encargarse Responsabilizarse de los aspectos de seguridad de las otras auditorías TI.

15.4.5 Mantenimiento La seguridad necesita mantenimiento, en tanto los riesgos cambian debido a los cambios en la infraestructura TI, también lo hacen la organización y los procesos del negocio. El mantenimiento de seguridad incluye el mantenimiento de la sección de seguridad del SLA y el mantenimiento de los planes de seguridad detallados (Acuerdos de Nivel de Operaciones). El mantenimiento se lleva a cabo con base en los resultados del subproceso de Evaluación y a una evaluación de los cambios en los riesgos. Estas propuestas pueden introducirse en el subproceso de Planificación o incluirse en el mantenimiento del SLA como un todo. En cualquier caso, las propuestas se pueden incluir en las actividades del plan de seguridad anual. Todos los cambios están sujetos al proceso normal de la Gestión de Cambios.

15.4.6 Presentación de Informes La presentación de informes no es un subproceso, sino una producción de los otros subprocesos. Los informes se hacen para dar información sobre el rendimiento de seguridad alcanzado y para informar a los clientes sobre temas de seguridad. Estos informes, por lo general, se piden bajo acuerdo con el cliente. La presentación de informes es importante, para el cliente y el proveedor de servido. Los clientes deben estar bien informados sobre la eficacia y los esfuerzos (p. ej. con respecto a la implementación de medidas de seguridad) y la medidas de seguridad reales. El cliente también debe tener información sobre los incidentes de seguridad.

167

Gestión de la Seguridad A continuación se incluye una lista con algunas sugerencias de opción de informe: El subproceso de Planificación - Informes sobre el grado de cumplimiento del SLA y los Indicadores de Rendimiento Clave acordados para la seguridad. - Informes sobre los Contratos de Apoyo y cualquier problema asociado a ellos. - Informes sobre Acuerdos de Nivel de Operaciones (planes de seguridad internos) y los principios de seguridad del proveedor (p. ej. en la línea de referencia). - Informes sobre los planes de seguridad anuales y los planes de acción. - Implementación del subproceso - Informes de estado sobre la implementación de la Seguridad de Información. Esto incluye informes de progreso sobre la implementación del plan de seguridad anual, posiblemente una lista de medidas que han sido implementadas o están por serlo, capacitación, producción de análisis de riesgo adicionales, etc. - Lista de incidentes de seguridad y respuestas a esos incidentes, en forma opcional una comparación con el periodo anterior de informes - Identificación de las tendencias en los incidentes. - Estado del programa de conocimiento. Subproceso de Evaluación - Informes sobre el rendimiento de los subprocesos. - Resultados de las auditorías, revisiones y evaluaciones internas. - Peligros, identificación y amenazas nuevas. Informes específicos Para informar sobre los incidentes de seguridad definidos en el SLA, el proveedor de servicio debe contar con un canal de comunicación directo con el representante del cliente (posiblemente el Oficial de Seguridad de Información Corporativo) a través del Gestor de Nivel de Servicio, de Incidente o el Gestor de Seguridad. También se debe definir un procedimiento para comunicarse en circunstancias especiales. Aparte de la excepción en caso de circunstancias especiales, los informes se comunican a través de la Gestión de Niveles de Servicio.

15.5 Control del Proceso 15.5.1 Factores de éxito críticos e indicadores de rendimiento Los factores de éxito crítico son: -

Compromiso y participación total de la gerencia Participación del usuario en el desarrollo del proceso Responsabilidades claras y separadas

Los indicadores de rendimiento de la Gestión de la Seguridad se corresponden con los de la Gestión de Niveles de Servicio, en tanto que éstos se relacionan con los temas de seguridad cubiertos en el SLA.

15.5.2 Funciones y roles En las organizaciones TI pequeñas, una misma persona puede hacerse cargo de muchos procesos. En grandes organizaciones, muchas personas trabajarán para un proceso, como por ejemplo en la Gestión de la Seguridad. En este caso, se nombra a una persona Gestor de Seguridad. El Gestor de Seguridad es responsable por la operación eficaz del proceso de la Gestión de la Seguridad. En la organización del cliente este cargo le pertenece al Oficial de Seguridad de Información o al Oficial Corporativo de Seguridad de Información.

168

Gestión de Servicios TI basado en ITIL

15.6 Problemas y costes 15.6.1 Problemas Los siguientes temas son esenciales para la exitosa implementación de la Gestión de la Seguridad:

-

-

-

-

Compromiso - las medidas de seguridad por lo general no cuentan con aceptación inmediata, es más común la resistencia que la aceptación. A los usuarios no les gusta perder ciertos privilegios por las medidas de seguridad, aún si estas comodidades no son esenciales para su trabajo. Esto es así porque los privilegios les proporcionan cierto estatus. Se deberá realizar un esfuerzo especial para motivar a los usuarios, y para garantizar el cumplimiento de las medidas de seguridad. En el campo de la Gestión de la Seguridad en especial, la Gerencia debe ser un ejemplo ("mostrar el camino" y "dar el ejemplo"). Si no hay incidentes de seguridad, la gestión puede verse tentada a reducir el presupuesto de la Gestión de la Seguridad. Actitud - los sistemas de información no son inseguros por las debilidades técnicas, sino por los fallos al usar la tecnología. Esto por lo general se relaciona con la actitud y el comportamiento humano. Ello significa que los procedimientos de seguridad se deben integrar a las operaciones de rutina. Conocimiento - el conocimiento, o la comunicaciones es un concepto clave. A veces puede parecer un conflicto de intereses entre la comunicación y la seguridad –las comunicaciones hacen el camino mientras que la seguridad pone obstáculos. Esto significa que la implementación de las medidas de seguridad necesitan del uso de todos los métodos de comunicaciones para garantizar que los usuarios adopten el comportamiento requerido. Verificación - es posible chequear y verificar la seguridad. Esto hace referencia a las medidas introducidas, y a las razones necesarias para tomar esas medidas. Sería posible verificar que se han tornado las decisiones correctas en ciertas circunstancias. Gestión de Cambios - frecuentemente, la verificación del cumplimiento continuo eficaz del nivel básico de seguridad desaparece con el tiempo cuando se evalúan los cambios. Ambición - cuando una organización quiere hacer todo a la vez, se cometen errores. Cuando se introduce la Gestión de la Seguridad, la implementación de las medidas de organización es mucho más importante que las medidas técnicas. Modificar una organización necesita un planteo gradual y llevará tiempo. Falta de sistemas de detección - los sistemas nuevos como Internet no fueron diseñados para la detección de intrusión. Esto se debe a que el desarrollo de un sistema seguro lleva más tiempo que desarrollar uno inseguro y está en pugna con los requisitos del negocio de coste de desarrollo bajos y de poco tiempo en el mercado. Demasiada confianza en las técnicas de fuerte/fortaleza - es cada vez más común que las amenazas de seguridad vengan de lugares no anticipados. Considere el primer ataque con los virus ILOVEYOU y Nimda, y la primera instancia de los ataques de Denegación de Servicio (DOS). Es verdad que es muy importante proteger los activos de información con planteamientos tradicionales fuerte/fortaleza, pero también es importante tener una capacidad de lucha cuando se trata de eventos de seguridad. Es análogo a necesitar músculos de "contracción nerviosa lenta" y de "contracción nerviosa rápida" La organización debe tener la capacidad de poner recursos rápidamente en el lugar del problema, antes de que ese problema se saiga de control.

15.6.2 Costes Asegurar la infraestructura TI demanda personal, y por lo tanto dinero, para tomar, mantener y verificar las medidas. Sin embargo, no asegurar la infraestructura TI también tiene su coste (coste de pérdida de producción, coste de reemplazo, daño de datos, software o hardware; pérdida de reputación, multas o compensación por la falta de cumplimiento de las obligaciones contractual es). Como siempre, se debe encontrar el equilibrio.

169

Gestión de la Seguridad

170

Gestión de Servicios TI basado en ITIL

Caso: Quick Couriers El caso de estudio trata de una empresa joven en desarrollo que se enfrenta a todos los temas pertinentes de la gestión de servicios. Al final de cada sección se hacen preguntas sobre cómo guiar y fijar los conocimientos del lector. El tráfico de la ciudad de Madrid es ahora tan pesado que es difícil proporcionar un servicio de mensajería con camionetas. Por tal razón, después de su graduación, tres amigos, Eva, Antonio y Pablo decidieron crear un servicio de mensajería con bicicletas. Fundaron para tal fin "Quick Couriers" (QC). Quick Couriers entrega paquetes en el centro de la ciudad usando bicicletas reclinables. Al principio los fundadores de Quick Couriers trabajaban solos, pero ahora tienen contratos con empresas de mensajería internacionales para buscar y entregar paquetes en el centro por lo que ya no pueden trabajar solos. Ahora emplean estudiantes part-time para realizar las entregas de los paquetes y utilizan bicicletas reclinables de su empresa. Eva es la responsable de contabilidad, facturación, procesamiento de peticiones, y de mantener los contactos del negocio. Quick Couriers ha comprado un EPR y un CRM. Antonio responde el teléfono, maneja las consultas de los clientes, hace la planificación y logística de los mensajeros, y pasa los mensajes de los mismos a Eva o Pablo. Pablo hace el mantenimiento de las bicicletas, administra los repuestos y herramientas, hace el planeamiento de logística y es el instructor de los mensajeros. Los tres amigos revisaron recientemente la posición de la empresa y definieron la visión y políticas de la misma. La visión es la siguiente 'Quick Couriers debe convertirse en sinónimo de entregas express en el centro de Madrid y sus alrededores'. Para implementar esto, la empresa ha iniciado una campaña de publicidad y está incorporando más mensajeros. Tienen planeado equipar a los mensajeros con pagers y teléfonos móviles. Además tienen pedida la cotización de un sistema basado en Internet, para que los clientes puedan solicitar y hacer seguimiento de servicios de mensajería por esta vía. Otra opción que está siendo considerada es la expansión de sus operaciones comerciales, mediante la apertura de otra oficina en Barcelona o Sevilla. Por eso, han decidido que esto será crítico para el futuro de la empresa para lograr un posicionamiento comercial más profesional. En consecuencia, ellos han definido las áreas que requieren atención.

171

Caso: Quick Couriers

Gestión de Configuraciones Pablo lleva informes en papel de las herramientas, instrucciones de mantenimiento, bicicletas, trailers, repuestos, ponchos y cascos. Si se enferma o se va de vacaciones, su primo, Jorge, se hace cargo del mantenimiento. La empresa tiene ahora 20 unidades de entrega (bicicletas y trailer), 16 de las cuales se usan constantemente. Las otras cuatro se encuentran en mantenimiento o como repuesto. Quick Couriers usa dos modelos que obtiene de diferentes abastecedores. Para acelerar el mantenimiento, Pablo ha hecho una cierta cantidad de sub-repuestos de los componentes más caros y vulnerables. Por ejemplo, tiene un conjunto de frenos de disco, conjuntos de engranajes, ruedas delanteras y traseras, y conjuntos de luces. Cuando tiene tiempo, repara los conjuntos reemplazando las partes usadas o rotas, pero a veces externaliza su trabajo a su vecina, María una ciclista entusiasta que se ha jubilado por adelantado. En su taller, Pablo tiene una hilera de estantes con partes sueltas y tiene un registro para hacer un seguimiento de pedidos pendientes que ha enviado a los abastecedores. Algunas partes son intercambiables con las de las bicicletas de carrera comunes. El garaje de las bicicletas está cerca del taller. Muchos mensajeros pasan por allí para buscar el programa de entregas o para reparar sus bicicletas. Debido al incremento de volumen del negocio, Pablo ya no puede manejar sus papeles y le lleva mucho tiempo hacer los informes. Eva se queja por las facturas de herramientas y repuestos y se pregunta si podrán ahorrar. Pablo ahora ha instalado una base de datos de paquetes para hacer un seguimiento del inventario. La base de datos se llama ConFig. Tiene un informe impreso de los repuestos en el taller. También ha comprado una etiquetadora para el inventariado de los repuestos. Preguntas: 1. 2. 3. 4. 5. 6. 7. 8.

172

¿Qué inició el desarrollo de este proceso? ¿Quién está involucrado en el proceso, además de Pablo? Diseñe el alcance y el nivel de detalle de la base de datos. ¿Qué atributos de los Elementos de Configuración (CI/EC) son adecuados para Pablo? ¿Qué está involucrado en la monitorización del estado? ¿Para qué se usa la historia del estado? Dé ejemplos de algunas preguntas, p. ej. sobre tendencias, que Pablo pueda responder con la base de datos, pero que no podía responder antes. ¿Cómo llenará Pablo su base de datos? ¿Cómo garantiza Pablo que su base de datos permanezca actualizada? ¿De qué debería Pablo informar a Eva?

Gestión de Servicios TI basado en ITIL

Gestión de Incidentes y Centro de Servicios Con dieciséis mensajeros permanentemente en la calle, la carga de trabajo de Antonio de contestar el teléfono se incrementa cada vez más. El recibe constantemente pedidos de clientes, quejas sobre la demora en la entrega de los paquetes, y mensajes de los mensajeros a los que se les ha roto la bicicleta o que no pueden entregar el pedido porque la dirección es incorrecta. A Antonio le resulta muy difícil hacerse cargo de todo, y se olvida de devolver las llamadas. Eva también se da cuenta de que se olvidan algunos pedidos. Hojas de papel que se pierden, falta de división del trabajo. Mientras que se hace un gran esfuerzo para proporcionar un buen servicio, también es imposible determinar con cuánta rapidez se están resolviendo los temas. Los clientes se han comenzado a quejar sobre los fallos del servicio y todos en la empresa tienen la impresión de que la cantidad de pedidos está disminuyendo. Mientras tanto, Pablo se enfrenta con una creciente cantidad de rutas y paquetes a incluir en la planificación. Ha creado una base de datos, RoutePlan, para los paquetes y las rutas, agrupados por código postal. La ruta de cada mensajero cubre cierta cantidad de códigos postales y tiene una secuencia óptima. Muchos mensajeros pueden cubrir la misma zona. Se pidió a Antonio que manejara algunas llamadas en persona. Por ejemplo, informa a los clientes sobre la gama de servicios que ofrece Quick Couriers, y registra las quejas. Además se le encomendó que identificara qué ha sucedido con los paquetes, y que se asegure de volver a llamar a los clientes. Ahora puede acceder a la base de datos RoutePlan en el ordenador de Pablo utilizando un segmento de red instalado hace poco que une los dos ordenadores. Para seguir el rastro de los mensajes y llamadas telefónicas, Antonio ha creado una nueva base de datos, TelLog. Antonio utiliza TelLog para hacer un seguimiento de todas las llamadas y para asignarles una categoría y código de prioridad. Preguntas: 1. 2. 3. 4. 5. 6. 7.

¿Qué inició el desarrollo de este Centro de Servicios? Para este proceso ¿qué tipo de Centro de Servicios se usó primero? ¿Qué información de incidentes es pertinente a una llamada de incidente? Dé ejemplos de categorías y prioridades. ¿A quién puede llamar Antonio si no puede resolver un problema? Una comunicación eficaz con el taller es esencial. ¿Qué término se utiliza para esto en ITIL? ¿De qué manera puede Quick Couriers asegurarse de que las llamadas por incidentes no se pasan por alto, y quién es responsable de esto? 8. ¿Se brinda soporte a las Operaciones del Negocio aquí? Si es así, explique cómo. 9. ¿Qué vínculos de información querría crear para los otros sistemas, y con qué propósito? 10. ¿De qué debería informar Antonio a Pablo y a Eva?

173

Caso: Quick Couriers

Gestión de Problemas RoutePlan para enrutar el paquete, TelLog para registrar las llamadas y ConFig para los informes de stock. El servicio ha mejorado y disminuyó la presión de trabajo. Quick Couriers ahora tiene treinta mensajeros en la calle, y Eva y Antonio se casaron, en una bicicleta para dos, por supuesto. Antonio ahora también usa RoutePlan para la planificación de rutas. Un estudiante se encarga de la central telefónica y puede resolver muchos incidentes usando la documentación que le dio Antonio. La primera vez que se presenta un problema nuevo, el estudiante pide ayuda a Pablo, Antonio o Eva y luego documenta la solución para poder utilizarla la próxima vez. Si un mensajero se atasca por un problema con su bicicleta, el estudiante de la central telefónica envía un repuesto con el mensajero que se encuentra más cerca. Si el mensajero no puede solucionar el problema, Pablo utiliza el trailer para llevar la bicicleta de repuesto. Sin embargo Pablo todavía se ocupa del número de reparaciones de bicicletas. Las bicicletas de carrera son más frágiles y están en constante uso. Todo depende de cómo los mensajeros toman las curvas y los pozos. Quick Couriers tiene la impresión de que la marca A sufre menos desgaste que la marca B, pero no están seguros. Algunas partes se rompen con más frecuencia que otras, pero no está claro si esto es por el uso, o la marca. Antonio se preocupa por la cantidad de paquetes que se pierden. Aunque por lo general se pueden localizar, quieren saber cómo se puede hacer un sistema a prueba de fallos. Los mensajeros reciben un bonus por desempeño y hay un premio para el mensajero que realice la mayor cantidad de entregas por hora. Pero Antonio todavía quiere información sobre la eficacia del mensajero y su trato con el cliente para mejorar su capacitación si es necesario. A Antonio se le pidió que observara los datos en TelLog, RoutePlan y ConFig para identificar las causas subyacentes de esos fallos. Espera tener para combinar muchos datos históricos y utilizarlos para disponer de análisis de tendencias. Preguntas: 1. 2. 3. 4. 5. 6. 7.

174

¿Qué inició el desarrollo del proceso? ¿Quiénes están involucrados y cuáles son sus roles? ¿Qué actividades realiza Antonio, y cuáles son los resultados? ¿Qué información quiere obtener Antonio de los otros sistemas? Dé ejemplos de problemas y Errores Conocidos. ¿Cuáles son las responsabilidades de Antonio respecto a los Errores Conocidos? ¿De qué conclusiones informa Pablo a Eva y Antonio?

Gestión de Servicios TI basado en ITIL

Gestión de Cambios Antonio aprendió un poco en la práctica las causas raíz de los incidentes. Por ejemplo encontró que los discos de frenos de una marca se gastan más rápido que los de otra. Hay algunos mensajeros que dañan sus bicicletas con mayor frecuencia que sus colegas, y algunos paquetes se pierden porque se ponen en el trailer del mensajero equivocado. Antonio ha hecho algunas recomendaciones sobre estos temas. Como estas recomendaciones tienen que ver con las áreas que cubren Eva y Pablo, discute el impacto potencial y la cantidad de trabajo que suponen. Los eventos de la semana anterior se discuten en los encuentros semanales de los lunes por la mañana. Como se espera que Antonio presente propuestas para mejoras regularmente, ahora tiene una agenda y una lista de acciones sobre cada elemento por separado. A Pablo se le pidió que probara un tipo de freno nuevo. Después de hacerlo va a diseñar un programa de mantenimiento. Los frenos se podrán cambiar según este esquema. Esto se combinará con otro mantenimiento planificado para garantizar que las bicicletas no se retiren demasiado rápido o antes de lo previsto. Se evaluará una propuesta de un planteamiento más estructurado para clasificar y asignar los paquetes. Además se tendrán reuniones con los mensajeros que rompen sus bicicletas muy a menudo. Preguntas: 1. 2. 3. 4. 5. 6.

¿Qué inició el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? ¿Qué actividades se toman en las reuniones después de las propuestas de Antonio? Describa cómo evaluaría las diferentes propuestas, y si sería necesario un plan de apoyo. ¿Qué se podría incluir en el plan de evaluación? ¿Qué se involucra en las modificaciones de planificación? Identifique las dificultades, los riesgos, recursos necesarios e impacto esperado. ¿Qué se necesitaría para cerrar las acciones pendientes? ¿Qué otros procesos están involucrados?

175

Caso: Quick Couriers

Gestión de Versiones Cuando los mensajeros entregan el paquete al cliente, dejan sus bicicletas fuera en la acera. Antonio ha comprado algunos candados de buena calidad para evitar los robos. Las bicicletas también tienen traba-ruedas separados y candados para los trailers. Pablo guarda las llaves extra en un cajón del escritorio. Los mensajeros a veces pierden las llaves y resulta bastante complicado encontrar la llave de repuesto que corresponde. Después de un tiempo resulta difícil establecer qué llaves de repuesto se han perdido. Quick Couriers tiene que comprar a menudo nuevos candados, y ahora que su flota de bicicletas se está expandiendo, esto se está transformando en un gasto importante. Por esa razón Pablo ha decidido mejorar la gestión de las llaves y sus copias. Se define un conjunto de candados por bicicleta. Los candados están numerados y los números se encuentran en ConFig. Pablo compra una caja de seguridad para guardar las llaves originales y las copias. Preguntas: 1. 2. 3. 4. 5. 6.

176

¿Qué inició el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? ¿Qué pasos se deben tomar antes de usar un nuevo conjunto de candados? ¿Qué medidas se deben tomar antes de entregar un nuevo conjunto de copias de llave a un mensajero? ¿Reemplazaría el conjunto completo si solo falla uno de los candados? ¿Cómo se llama esto? ¿Qué pasos tomaría si sólo se reemplaza uno de los candados? ¿Cómo se llama esto?

Gestión de Servicios TI basado en ITIL

Gestión de la Disponibilidad Quick Couriers tiene cada vez más trabajo. Cuando se rompe una bicicleta lleva mucho tiempo arreglarla, y el mensajero y el paquete quedan esperando en la calle- De igual forma, si el mensajero se enferma se altera toda la programación. Los clientes se empiezan a quejarse porque las entregas llevan mucho tiempo. Eva quiere conseguir información de los desarrollos para poder incluirlos en los planes de la empresa. Los contenidos incluirán mantenimientos, tiempos de entrega, y personal. El objetivo de la empresa es poder garantizar tiempos de entrega lo más cortos posibles. Algunas ideas posibles consisten en establecer un equipo de reparación móvil, comprar una centralita telefónica con sistema de menús, y establecer un procesamiento de pedido y rastreo del sistema en Internet. Todo esto requerirá de una inversión significativa. Preguntas: 1. 2. 3. 4. 5. 6.

¿Qué inició el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? Haga una lista de los activos, las amenazas y vulnerabilidades. Utilice esta información para identificar los riesgos. ¿En qué medidas de prevención puede pensar? Haga una lista a incluir en la planificación en términos de mantenimiento, abastecedores y personal.

177

Caso: Quick Couriers

Gestión de la Capacidad El mercado cambia rápidamente. Quick Couriers está consiguiendo nuevos clientes en otros distritos y piensan expandirse a Barcelona y Sevilla. Pablo también está pensando abrir otra oficina en el aeropuerto Internacional de Madrid-Barajas. Eva tiene información empírica sobre los niveles de personal necesarios para cada ruta. Ha utilizado el sistema de RoutePlan para crear un informe que muestra, para cada ruta, cuántos paquetes se llevan cada día de la semana, en qué horario la ruta está más congestionada, y cuántos paquetes se pueden llevar en el trailer. Ha utilizado el promedio como línea de referencia, e identificó un porcentaje por encima y por debajo de la línea de referencia para cada mes y hora del día. Quiere utilizar esta información para el equipamiento y la planificación del personal. Eva utiliza esta información para hacer un informe sobre la expansión esperada y los costes de inversión necesarios. Preguntas: 1. 2. 3. 4. 5. 6.

178

¿Qué inició el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? Dé ejemplos de actividades de modelado. ¿Cómo se pueden acomodar las cargas pico sin desplegar capacidad adicional? ¿Qué actividades asisten en la estimación de recursos para comenzar una nueva ruta? ¿Qué se debería incluir en el plan de capacidad?

Gestión de Servicios TI basado en ITIL

Gestión de Continuidad de Servicios TI La semana pasada, se incendió el edificio de al lado de Quick Couriers. Eva, Antonio y Pablo se asustaron mucho. Su lugar actual es muy adecuado, y encontrar un lugar en la ciudad de Madrid es muy difícil. Se dieron cuenta de que si pasa algo igual en su edificio, les llevaría meses volver a la actividad. Por este motivo, Quick Couriers decidió incluir opciones de recuperación ante desastres en sus planes para una nueva oficina en el sur de la ciudad de Madrid. Además van a considerar alternativas en las vecindades de la ubicación actual que pueden usarse como base temporal para servir las rutas del área central. En el plan se incluyen los siguientes temas: -

Edificio Accesibilidad Personal Archivos electrónicos y sistemas Equipamiento Paquetes del cliente

Preguntas: 1. 2. 3. 4. 5. 6.

¿Qué inició el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? ¿Cuáles son las razones de la empresa para mantener un plan de recuperación ante desastres? ¿Cuáles son las amenazas, activos y vulnerabilidades? Utilice esta información para identificar los riesgos. ¿Qué medidas preventivas se pueden tomar, y qué riesgos necesitan las instalaciones de recuperación ante desastres fuera de lugar? 7. ¿Cuál es el término ITIL para un plan de recuperación ante desastres que incluye el apoyo de las instalaciones TI de otra organización? 8. Identifique los temas a incluir en un plan de apoyo en otro lugar, y describa cómo se debería evaluar. 9. ¿Cómo el plan de capacidad y los diversos planes influencian en el plan para mejorar la disponibilidad (p. ej. la oficina nueva)? 10. ¿Cuál es el efecto de la Gestión de Cambios {Comité de Cambio)? Dé un ejemplo de este caso de estudio.

179

Caso: Quick Couriers

Gestión Financiera El rango de servicios que proporciona Quick Couriers se está expandiendo. Hay tarifas más bajas para las entregas fuera de horario pico, tarifas para entregas urgentes, y descuentos por volumen. Los clientes pueden usar Internet para pedir una colección de paquetes, y rastrear la ubicación de los suyos. Sin embargo, algunos empleados de Quick Couriers se fueron y empezaron sus propios negocios lo que ha puesto presión a la calidad y los precios de los servicios. Los costes relacionados con el soporte del servicio también se ha incrementado. La empresa se vuelve cada vez más dependiente de las instalaciones TI. Eva se ha puesto en contacto con un proveedor de servicio de Internet, ha contratado una línea, y Quick Couriers ahora emplea un gestor de sistemas para garantizar la continuidad. Hay un equipo de reparación constantemente en la calle. Los costes de administración se han incrementado debido a la mayor cantidad de personal. Se han hecho inversiones en edificios, por lo que la depreciación se ha convertido en un tema relevante para la contabilidad. Los mensajeros que operan los servicios express tienen que estar disponibles en todo momento, lo que significa que a veces están sin ocupación. Se está volviendo muy difícil establecer precios que cubran los costes. Eva quiere promover ciertos servicios (los que los competidores también pueden ofrecer) cobrando menos, pero debe considerar el monto para que los nuevos precios no resulten una pérdida operativa. Eva quiere introducir un sistema de centra de costes para conseguir información sobre los costes asociados con la provisión de cada servicio. Ahora que va a tener más información sobre los costes por servicio, espera ser capaz de financiar las pérdidas de ciertos servicios con las ganancias de otros. Preguntas: 1. 2. 3. 4. 5.

180

¿Qué impidió el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? Dé ejemplos de costes fijos y variables, y de costes directos e indirectos. Dé un ejemplo de catálogo de servicio y medios de producción necesarios para los diferentes servicios. Realice un resumen del plan de política de precio.

Gestión de Servicios TI basado en ITIL

Gestión de Niveles de Servicio Eva quiere que los clientes regulares se comprometan con su negocio. Por tal razón, quiere mantener mejores contactos con ellos y formalizar contratos de servicio a largo plazo. Los clientes fijos pagarán un monto fijo por mes, en vez de pagar por separado por cada paquete o servicio. Esto le dará a la empresa una entrada fija que les facilitará el planeamiento de los servicios. Dado que Quick Couriers tiene tantas bicicletas en la calle, la empresa depende más de los abastecedores de repuestos y otros servicios. Por esta razón, Eva quiere formalizar los contratos para garantizar los tiempos de entrega. Quick Couriers contrata un nuevo empleado como contable. Su tarea es traducir las demandas del cliente en planes para servicios nuevos o modificados. Después de formalizar los contratos de Apoyo puede empezar a desarrollar un catálogo nuevo. Preguntas 1. 2. 3. 4. 5. 6. 7. 8. 9.

¿Qué inició el desarrollo de este proceso? ¿Quiénes están involucrados, y cuáles son sus roles? Describa la función del gestor contable. Dé un ejemplo de un acuerdo de marco de trabajo con un cliente regular. ¿Cómo se garantizan los servicios acordados con el cliente? ¿Qué se podría incluir en el Plan de Calidad de Servicio para la empresa? Si fuera gestor contable, ¿con quién finalizaría un SPA (u OLA)? ¿A quién informarla sobre los Logros de Servicio? ¿Cómo se planean los cambios para los servicios de bajo rendimiento?

181