itil unidad ii fundamentos de la gestión ti
DESCRIPTION
itilTRANSCRIPT
1.- Fundamentos de la Gestión TI1.1 Gestión de Servicios TI
Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papel en la misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido en una herramienta imprescindible y clave para empresas e instituciones.
La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez genera ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una herramienta más entre muchas otras.
Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de soporte y de alguna forma eran equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la organización pero poco más.
Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una parte sustancial de los procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de ejemplo la Banca Electrónica.
Los objetivos de una buena gestión de servicios TI han de ser:
Proporcionar una adecuada gestión de la calidad
Aumentar la eficiencia
Alinear los procesos de negocio y la infraestructura TI
Reducir los riesgos asociados a los Servicios TI
Generar negocio
ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:
Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos
El establecimiento de estrategias para la gestión operativa de la infraestructura TI
1.2 ¿Qué es ITIL?
Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido en el estándar mundial de de facto en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy,ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización.
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u
obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.
ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros centrales
cubriendo las dos principales áreas de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. A partir del año 2000, se acometió una revisión de la biblioteca. En esta revisión, ITIL ha sido reestructurado para hacer más simple el acceder a la información necesaria para administrar sus servicios. Los libros centrales se han agrupado en dos, cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la duplicidad y mejorar la navegación. El material ha sido también actualizado y revisado para un enfoque conciso y claro.
1.2.1 Soporte al Servicio
El soporte al servicio se preocupa de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del servicio prestado al usuario.
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de soporte al servicio según los estándares ITIL:
1.2.3 Provisión del Servicio
La provisión del servicio se ocupa de los servicios ofrecidos en si mismos. En particular de los Niveles de servicio, su disponibilidad, su continuidad, su viabilidad financiera, la capacidad necesaria de la infraestructura TI y los niveles de seguridad requeridos
El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de provisión del servicio según los estándares ITIL:
1.2.4Forum ITSMF
El ITSMF es el único Forum completamente independiente reconocido por el sector de la Gestión de Servicios Informáticos. Esta asociación, con fines no lucrativos, juega un papel predominante en el desarrollo y promoción de un código de Mejores Prácticas para la gestión de estos servicios.
En la actualidad, las empresas dependen cada vez en mayor medida de la tecnología para la promoción y distribución de sus productos en el mercado, por lo que resulta imprescindible adoptar unos estándares que permitan la correcta gestión de los procesos informáticos asociados.
El objetivo del ITSMF es organizar una red de expertos en Gestión de Servicios Informáticos, ofrecer completa información sobre los mismos y organizar seminarios y conferencias para ayudar a las empresas a resolver los problemas que puedan encontrar en este campo, todo ello con el objetivo de mantener un alto nivel de calidad de lestos servicios gracias a la utilización de un código de Mejores Prácticas.
Más de 1000 compañias, grandes corporaciones y empresas públicas de todo el mundo pertenecen al ITSMF. Osiatis es en la actualidad una de las empresa responsables de las actividades del Forum en España y Francia (Claude Durand, Director de Desarrollo de Osiatis Francia, es tesorero de la asociación en ese país)
1.2.5 Certificaciones ITIL
EXIN e ISEB
La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information Systems Examination Board" (ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. Fue realizado en estrecha cooperación con la OGC y el itSMF. EXIN e ISEB son organizaciones sin ánimo de lucro que cooperan para ofrecer una amplia gama de certificaciones en tres niveles:
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 está basado en los requisitos para representar eficazmente el papel pertinente dentro de una organización TI. Hasta la fecha, se han entregado más de 50.000 certificados Foundation a profesionales de más de 30 países.
Hoy en día, ITIL representa mucho más que una serie de libros útiles sobre Gestión de Servicios TI. El marco de mejores prácticas en la Gestión de Servicios TI representa un conjunto completo de organizaciones, herramientas, servicios de educación y consultoría, marcos de trabajo relacionados, y publicaciones. Desde 1990, se considera a ITIL como el marco de trabajo y la filosofía compartida por quienes utilizan las mejores prácticas ITIL en sus trabajos. Gran cantidad de organizaciones se encuentran en la actualidad cooperando internacionalmente para promover el estándar ITIL como un estándar de facto para la Gestión de Servicios TI.
Enlaces de interés
Podréis encontrar información adicional en:
http://www.itil.co.uk -El Sitio Oficial de ITIL
http://www.exin.nl -Organismo de Certificación
http://www.itsmf.com -Forum Internacional de Gestión de Servicios TI
1.3 Caso Práctico
Una compañía (ficticia) dedicada al catering, "Cater Matters", ha optado por introducir la metodología ITIL para la gestión de sus servicios.
"Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye:
Servicios de comedor de grandes empresas.
Servicios de catering para colegios.
Servicios de catering para eventos (congresos, actos institucionales, ...).
Servicios de restauración para hoteles.
La logística del servicio es compleja y los niveles de servicio muy exigentes en lo que respecta a la calidad y los plazos de entrega.
Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informático que le permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como sus procesos de producción y distribución.
La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la metodología ITIL como la base de todos sus procesos y servicios. Entre las decisiones adoptadas consecuentemente caben destacar:
Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con los clientes y el resto de la infraestructura TI.
Organización de sus actividades entorno a los procesos.
Designación de responsables o gestores para cada uno de los procesos críticos.
Establecimiento de estrictos protocolos de monitorización de la calidad del servicio.
2.- CENTRO DE SERVICIOS (SERVICE DESK)
2.1 Visión General
El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los los usuarios y la Gestión de Servicios TI.
Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio:
Registrando y monitorizando incidentes.
Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas.
Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes.
Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y Versiones
Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes.
2.2 Introducción y Objetivos
Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente y continuo e independiente de su localización geográfica.
Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que estan recibiendo una atención personalizada y ágil que les ayude a:
Resolver rápidamente las interrupciones del servicio.
Emitir peticiones de servicio.
Informarse sobre el cumplimiento de los SLAs.
Recibir información comercial en primera instancia.
El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los servicios ofrecidos:
Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.
Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.
Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como:
o Supervisión de los contratos de mantenimiento y niveles de servicio.
o Canalización de las Peticiones de Servicio de los clientes.
o Gestión de las licencias de software.
o Centralización de todos los procesos asociados a la Gestión TI.
Los principales beneficios de una correcta implementación del Centro de Servicios se resumen en:
Reducción de costes mediante una eficiente asignación de recursos.
Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo.
Apertura de nuevas oportunidades de negocio.
Centralización de procesos que mejoran la gestión de la información y la comunicación.
Soporte al servicio proactivo.
2.2.1 Implementación
La implementación de un Service Desk requiere una meticulosa planificación. En primera instancia debe establecerse:
Cuáles son las necesidades.
Cuáles han de ser sus funciones.
Quiénes seran los responsables del mismo.
Qué cualificaciones profesionales poseeran sus integrantes.
Si se deben externalizar ciertos servicios, como, por ejemplo, el soporte técnico del hardware.
Qué estructura de Service Desk: distribuido, central o virtual, se adapta mejor a nuestras necesidades y las de nuestros clientes.
Qué herramientas tecnológicas necesitamos.
Qué métricas determinarán el rendimiento del Centro de Servicios.
Además de estas cuestiones de carácter técnico, es imprescindible ponderar otros aspectos más directamente relacionados con el "factor humano" y que son tan importantes o más que los puramente técnicos para el éxito del Centro de Servicios:
Establecer estrictos protocolos de interacción con el cliente.
Motivar al personal encargado de la relación directa con el cliente.
Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte.
Asegurar el compromiso de la dirección con la filosofía del Service Desk.
Sondear a los clientes para conocer mejor sus expectativas y necesidades.
El objetivo NO es implementar lo más rápidamente posible un Centro de Servicios sino implantar un Centro de Servicios cuyos objetivos se alineen con nuestros procesos de negocio, mejoren la satisfacción de nuestros clientes, optimicen la imagen externa de nuestra organización y nos sirva de plataforma para identificar nuevas oportunidades de negocio.
2.2.2 Estructura
Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto de toda la organización TI con clientes y usuarios, es por lo tanto imprescindible que:
Sea fácilmente accesible.
Ofrezca un servicio de calidad consistente y homogéneo.
Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los mismos.
Sirva de soporte al negocio.
Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica.
Estructura lógica
Los integrantes del Centro de Servicios deben:
Conocer todos los protocolos de interacción con el cliente: guiones, checklists,...
Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios.
Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre cumplimiento de SLAs.
Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios.
Recibir formación sobre los productos y servicios de la empresa.
Estructura física
Dependiendo de las necesidades de servicio: locales, globales, 24/7,...se debe de optar por una estructura diferente para el Centro de Servicios.
Existen tres formatos básicos:
Centralizado
Distribuido
Virtual
Describimos a continuación sus principales características:
Service Desk Centralizado
En este caso todo el contacto con los usuarios se canaliza a través de una sola estructura central.
Sus ventajas principales son:
Se reducen los costes.
Se optimizan los recursos.
Se simplifica la gestión.
Sin embargo surgen importantes inconvenientes cuando:
Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas, productos y servicios.
Se necesita dar servicios de mantenimiento "on-site".
Service Desk Distribuido
Este es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos geográficos (ya sean ciudades, países o continentes). Sus ventajas son obvias en estos casos, sin embargo la deslocalización de los diferentes Centros de Servicios conlleva grandes problemas:
Es generalmente más caro.
Se complica la gestión y monitorización del servicio.
Se dificulta el flujo de datos y conocimiento entre los diferentes Service Desks.
Service Desk Virtual
En la actualidad y gracias a las rápidas redes de comunicación existentes la situación geográfica de los Centros de Servicios puede llegar a ser irrelevante.
El principal objetivo del Service Desk virtual es aprovechar las ventajas de los Service Desks centralizados y distribuidos.
En un Service Desk virtual:
El "conocimiento" está centralizado.
Se evitan duplicidades innecesarias con el consiguiente ahorro de costes.
Se puede ofrecer un "servicio local" sin incurrir en costes adicionales.
La calidad del servicio es homogénea y consistente.
Centro de servicios (Service Desk)2.2.3 Actividades y Funciones
Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de Servicios TI. Sin embargo, no cabe duda, de que su función principal es gestionar la relación con los clientes y usuarios manteniéndoles puntualmente informado de todos aquellos procesos de su interés.
A continuación describimos algunas de las actividades que un Service Desk debería ofrecer para merecer ese nombre:
Gestión de Incidentes
Independientemente de que la completa gestión de las incidencias requiera la colaboración de otros departamentos y personal, el Service Desk debe ofrecer una primera línea de soporte para la solución de todas las interrupciones de servicio y/o peticiones de servicio que puedan cursar los clientes y usuarios.
Entre sus tareas específicas se incluyen:
Registro y monitorización de cada incidente.
Comprobación de que el servicio de soporte requerido se incluye en el SLA asociado.
Seguimiento del proceso de escalado.
Identificación de problemas.
Cierre del incidente y confirmación con el cliente.
Centro de información
El Service Desk debe ser la principal fuente de información de los clientes y usuarios, informando sobre:
Nuevos servicios.
El lanzamiento de nuevas versiones para la corrección de errores.
El cumplimiento de los SLAs.
...
Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio, evaluar las necesidades de los clientes y su grado de satisfacción con el servicio prestado.
El Centro de Servicios se encuentra en una situación inmejorable para ofrecer también información privilegiada a todos los procesos de gestión de los servicios TI. Es para ello imprescindible que se lleve un adecuado registro de toda la interacción con los usuarios y clientes.
Relaciones con los proveedores
El Centro de Servicios es asimismo responsable de la relación con los proveedores de servicios de mantenimiento externos.
Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externos del mantenimiento y la Gestión de Incidentes que debe ser canalizada a través del Service Desk.
2.2.4 Equipo y formación
La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado por su Service Desk.
Todos hemos sufrido frustrantes experiencias con grandes empresas que prometen un soporte continuo y de alta calidad y que a la hora de la verdad disponen de un centro de contacto con personal poco preparado, cuando no directamente mal educado.
"El éxito de su Service Desk es el éxito de su empresa" y el mismo depende en gran medida de las personas que lo integren. Es por tanto imprescindible establecer estrictos protocolos de selección y formación de su personal integrante.
Idealmente, el personal del Service Desk debe:
Compartir la filosofía de atención al cliente de la organización.
Comunicarse con corrección y buena educación y de una manera que el cliente pueda comprender.
Conocer en profundidad los servicios y productos ofrecidos.
Comprender las necesidades de los clientes y redirigirlos, si fuera necesario, a los expertos en cuestión.
Controlar todas la herramientas tecnológicas a su disposición para ofrecer un servicio de alta calidad.
Ser capaz de trabajar en equipo.
La formación impartida debe referirse a todos estos aspectos y no limitarse a la capacitación tecnológica.
También es imprescindible el compromiso de la dirección con:
Un seguimiento de cerca de los servicios prestados y su eficacia y rendimiento.
Un continuo apoyo al equipo en la siempre difícil tarea del trato directo con los clientes.
El trabajo en equipo.
2.3 Control del proceso
La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente, no sea responsabilidad exclusiva de éste.
Es importante que se intenten establecer métricas bien definidas para medir el rendimiento delCentro de Servicios y la apreciación que los usuarios tienen de éste.
En los informes de control se deben considerar aspectos tales como:
Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax.
Porcentaje de incidentes que se cierran en primera línea de soporte.
Porcentaje de consultas respondidas en primera instancia.
Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto.
Cumplimiento de los SLAs.
Número de llamadas gestionadas por cada miembro del personal del Service Desk.
Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados.
Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar la opinión del cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Toda esta información debe ser recopilada y analizada periódicamente para mejorar la calidad del servicio.
2.4 Caso Practico
Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater Matters" ha decidido implantar un Service Desk que centralice todos los contactos con clientes, proveedores y la organización TI.
Para ello se han adoptado las siguientes decisiones:
Se ha nombrado un gestor responsable del Service Desk.
Se han definido, tras un cuidadoso análisis de las necesidades de la organización y los usuarios, las funciones principales del mismo:
o Gestionar la primera línea de soporte de la Gestión de Incidentes.
o Supervisar la calidad del servicio ofrecido respecto a los SLAs.
o Ofrecer información de carácter comercial sobre los servicios ofrecidos.
o Realizar encuestas periódicas sobre el grado de satisfacción del cliente.
o Elaboración de informes periódicos con la información recopilada.
Realizar una pequeña promoción para presentar los nuevos servicios a los clientes existentes y potenciales.
Habilitar un espacio web para canalizar, en la medida de los posible, la interacción con los usuarios a través de este medio:
o Formularios de consultas y alta de incidentes.
o Consulta remota, mediante los web services asociados, del estado de los incidentes activos, históricos de incidencias y cumplimiento de losSLAs.
o FAQs actualizadas que permitan a los usuarios consultar directamente sobre los servicios prestados, errores conocidos, etc.
Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos de interacción con los usuarios dependiendo de la situación en cuestión.
Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del Service Desk.
Impartir formación específica:
o Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de Atención al Cliente".
o Sobre las herramientas de software utilizadas.
Creación de un detallado plan de implantación progresiva del Service Desk .
3.- GESTIÓN DE INCIDENTES
3.1 Visión General
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.
La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.
Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo:
3.1 Introducción y Objetivos
Los objetivos principales de la Gestión de Incidentes son:
Detectar cualquiera alteración en los servicios TI.
Registrar y clasificar estas alteraciones.
Asignar el personal encargado de restaurar el servicio según se define en el SLAcorrespondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe jugar una papel esencial en el mismo.
El siguiente diagrama resume el proceso de gestión de incidentes:
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es:
“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.
Los principales beneficios de una correcta Gestión de Incidentes incluyen:
Mejorar la productividad de los usuarios.
Cumplimiento de los niveles de servicio acordados en el SLA.
Mayor control de los procesos y monitorización del servicio.
Optimización de los recursos disponibles.
Una CMDB más precisa pues se registran los incidentes en relación con los elementos de configuración.
Y principalmente: mejora la satisfacción general de clientes y usuarios.
Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:
Reducción de los niveles de servicio.
Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.
Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.
Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.
Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:
No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.
No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.
3.2.1 Clasificación del Incidente
Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas.
El nivel de prioridad se basa esencialmente en dos parámetros:
Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.
Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA.
También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes.
Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente.
La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones.
Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:
3.2.2 Escalado y Soporte
Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado.
Básicamente hay dos tipos diferentes de escalado:
Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema.
Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.
El proceso de escalado puede resumirse gráficamente* como sigue:
* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario , integrar diferentes niveles en el caso de PYMES
3.3 Proceso
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI
3.3.1 Registro y Clasificación de Incidentes
Registro
La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo.
Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros.
El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.
La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.
Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.
Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.
Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).
Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia CMDB (hardware interrelacionado), etc.
Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.
Clasificación
La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo.
El proceso de clasificación debe implementar, al menos, los siguientes pasos:
Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.
Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.
Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).
Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.
3.3.2 Análisis, Resolución y Cierre de Incidentes
En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.
Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados.
Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.
Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a laGestión de Problemas para el estudio detallado de las causas subyacentes.
Cuando se haya solucionado el incidente se:
Confirma con los usuarios la solución satisfactoria del mismo.
Incorpora el proceso de resolución a la KB.
Reclasifica el incidente si fuera necesario.
Actualiza la información en la CMDB sobre los elementos de configuración (CI)implicados en el incidente.
Cierra el incidente.
3.4 Control del Proceso
La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.
Estos informes deben aportar información esencial para, por ejemplo:
La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.
Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:
Un correcto sistema automatizado de registro de incidentes y relación con los clientes
Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite:
o Evitar escalados innecesarios.
o Convertir el “know how” de los técnicos en un activo duradero de la empresa.
o Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.
Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.
Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:
Número de incidentes clasificados temporalmente y por prioridades.
Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
Nivel de cumplimiento del SLA.
Costes asociados.
Uso de los recursos disponibles en el Centro de Servicios.
Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
Grado de satisfacción del cliente.
3.5 Caso Práctico
El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor de uno de sus clientes.
Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos
El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días pero también observa que éste se ha guardado defectuosamente.
El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.
El operador toma, basándose en los protocolos establecidos, las siguientes decisiones:
Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita rápidamente el suministro.
Registra los datos del incidente.
Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error conocido y cuales son las posibles soluciones temporales
Propone una solución temporal al cliente: indica una zona reservada de la web desde la que se pueden realizar pedidos "urgentes" vía email.
Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la mañana.
Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los helados solicitados.
Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes del mediodía.
Por otro lado el departamento de sistemas:
Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.
No consigue identificar la causa del incidente.
Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero pre-calificando su prioridad como baja.
El Service Desk recibe la información y determina que:
Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución temporal satisfactoria no se requiere un escalado superior.
Registra la solución temporal del incidente junto a la información proporcionada por el departamento de sistemas.
Da por cerrado el incidente.
4.- GESTIÓN DE PROBLEMAS
4.1 Visión General
Las funciones principales de la Gestión de Problemas son:
Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
Determinar posibles soluciones a las mismas.
Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.
Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.
La Gestión de Problemas puede ser:
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran.
Las interacciones y funcionalidades de la Gestión de Problemas se resumen sucintamente en el siguiente interactivo:
4.1 Introducción y Objetivos
Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes y causas del mismo.
Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.
Cabe diferenciar entre:
Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa.
Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas.
Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de Incidentes se resumen en el siguiente interactivo:
4.3 Proceso
Las principales actividades de la Gestión de Problemas son el:
Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a los mismos medianteRFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.
Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI
4.3.1 Control de Problemas
El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.
El Control de Problemas se compone en esencia de tres fases:
1. Identificación y Registro
Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:
La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.
Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.
Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.
Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.
El registro debe incorporar, entre otra, información sobre:
Los CIs implicados.
Causas del problema.
Síntomas asociados.
Soluciones temporales.
Servicios involucrados.
Niveles de prioridad, urgencia e impacto.
Estado: activo, error conocido, cerrado.
Clasificación y Asignación de Recursos
La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo.
Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio).
Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI.
Análisis y Diagnóstico: Error conocido
Los objetivos principales del proceso de análisis son:
Determinar las causas del problema.
Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por:
Errores de procedimiento.
Documentación incorrecta.
Falta de coordinación entre diferentes áreas.
...
Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.
Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.
4.3.2 Control de Errores
Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.
Identificación y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados.
Análisis y Solución
Se deben investigar diferentes soluciones para el error evaluando en cada momento:
El posible impacto de las mismas en la infraestructura TI.
Los costes asociados.
Sus consecuencias sobre los SLAs.
En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios.
Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:
¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.
¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable?
¿Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá
una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.
Revisión Post Implementación y Cierre
Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR).
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.
4.4 Control del Proceso
El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento.
En particular una buena gestión de problemas debe traducirse en una:
Disminución del número de incidentes y una más rápida resolución de los mismos.
Mayor eficacia en la resolución de problemas.
Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemasy aporta información de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidentes.
Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.
Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.
Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de identificación y solución de problemas.
4.5 Caso Práctico
El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre unaincidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.
La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el modelo de Kepner y Tregoe:
Identificación del problema.
Clasificación del problema.
Establecimiento de las posibles causas.
Comprobación de la causa más probable.
Verificación de la causa verdadera.
Identificación: En nuestro caso el problema es sencillo de definir:
La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software.
Clasificación: La clasificación se adaptaría a los siguientes parámetros:
Identificación: Problemas en el registro de pedidos.
Origen: Módulo de pedidos online.
Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.
Posibles causas: Entre las causas más probables figuran:
Errores en la programación del lado cliente de la aplicación.
Errores en los módulos de registro del servidor web.
Errores de configuración de la base de datos.
Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.
Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:
Se intenta reproducir el problema.
Se comprueba que el error sólo se reproduce con una determinada marca de helados.
Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas.
Verificación:
Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.
Se introducen las modificaciones necesarias en la programación.
Se comprueba el correcto registro del pedido.
El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:
Elevar una RFC con la solución propuesta.
Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.
5.- GESTIÓN DE CONFIGURACIONES
5.1 Visión General
Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en:
Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB).
Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión.
Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versionesde manera que estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas, realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.
Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias.
Las interacciones y funcionalidades de la Gestión de Configuraciones se resumen sucintamente en el siguiente interactivo:
5.2 Introducción y Objetivos
Es evidente que no se puede gestionar correctamente lo que se desconoce.
Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la misma. La principal tarea de la Gestión de Configuraciones es llevar un registro actualizado de todos los elementos de configuración de la infraestructura TI junto con sus interrelaciones.
Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos, en particular, de la Gestión de Cambios y Versiones.
Los objetivos principales de la Gestión de Configuraciones se resumen en:
Proporcionar información precisa y fiable al resto de la organización de todos los elementos que configuran la infraestructura TI.
Mantener actualizada la Base de Datos de Configuraciones:
o Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado,...
o Interrelación entre los CIs.
o Servicios que ofrecen los diferentes CIs.
Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidentes, Problemas y Cambios.
Los beneficios de una correcta Gestión de Configuraciones incluyen, entre otros:
Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. Una fuente habitual de problemas es la incompatibilidad entre diferentesCIs, drivers desactualizados, etc. La detección de estos errores sin una CMDBactualizada alarga considerablemente el ciclo de vida de un problema.
Una Gestión de Cambios más eficiente. Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas.
Reducción de costes. El conocimiento detallado de todos los elementos de configuración permite, por ejemplo, eliminar duplicidades innecesarias.
Control de licencias. Se pueden identificar tanto copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización.
Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectar vulnerabilidades en la infraestructura.
Mayor rapidez en la restauración del servicio. Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible.
Las principales dificultades con las que topa la Gestión de Configuraciones son:
Una incorrecta planificación: es esencial programar correctamente las actividades necesarias para evitar duplicaciones o incorrecciones.
Estructura inadecuada de la CMDB: mantener actualizada una base de datos de configuraciones excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos.
Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la CMDB.
Falta de Coordinación con la Gestión de Cambios y Versiones que imposibilita el correcto mantenimiento de la CMDB.
Falta de organización: es importante que haya una correcta asignación de recursos y responsabilidades. Es preferible, cuando sea posible, que la Gestión de Configuraciones sea llevada a cabo por personal independiente y especializado.
Falta de compromiso: los beneficios de la Gestión de Configuraciones no son inmediatos y son casi siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa y consecuentemente de los agentes implicados.
5.2.1 Definiciones
A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración (CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una definición precisa de ambos.
Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:
Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes: tarjetas de red, teclados, lectores de CDs, ...
Software: sistemas operativos, aplicaciones, protocolos de red, ...
Documentación: manuales, acuerdos de niveles de servicio, ...
En resumen, todos los componentes que han de ser gestionados por la organización TI.
Base de Datos de la Gestión de Configuraciones: esta base de datos debe incluir:
Información detallada de cada elemento de configuración.
Interrelaciones entre los diferentes elemento de configuración, como, por ejemplo, relaciones "padre-hijo" o interdependencias tanto lógicas como físicas
La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la infraestructura TI de la organización.
5.3 Proceso
Las principales actividades de la Gestión de Configuraciones son:
Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones.
Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos.
Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.
Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.
Elaboración de informes: para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
5.3.1 Planificación
La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias con el resto de procesos. Por ello su implantación es particularmente compleja.
Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:
Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.
Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable.
Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.
Establecer claramente:
o El alcance y objetivos.
o El nivel de detalle
o El proceso de implementación: orden de importancia, cronograma, ...
Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y los Departamentos de Compras y Suministros
Una falta de planificación conducirá con total certeza a una Gestión de Configuracionesdefectuosa con las graves consecuencias que esto supondrá para el resto de los procesos.
5.3.2 Clasificación y Registro
La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor con éxito, predeterminar la estructura del CMDB de manera que:
Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.
La información sea suficiente: debe existir, al menos un registro de todos los sistemas críticos para la infraestructura TI.
Alcance
En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:
Es esencial incluir al menos todos los sistemas de hardware y software implicados en los servicios críticos.
Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.
Es recomendable incorporar, al menos, la documentación asociada a proyectos,SLAs y licencias.
En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes.
Nivel de detalle y Profundidad
Una vez determinado el alcance de la CMDB es imprescindible establecer el nivel de detalle y profundidad deseados:
Determinar los atributos que describen a un determinado CI.
Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs.
Subcomponentes registrados independientemente.
Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:
Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.
Relaciones: conexión en red, impresoras conectadas, etc.
Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.
Nomenclatura
Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos de clasificación de los CIs para que el sistema sea funcional:
La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.
Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación).
Los códigos no deben ser sólo utilizados para componentes de hardware sino también para documentación y software.
5.3.3 Monitorización
Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede ser de gran utilidad, por ejemplo, a la Gestión de Disponibilidad para conocer que CIs han sido responsables de la degradación de la calidad del servicio.
Puede ser de gran utilidad para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del ciclo de vida de las componentes, organizados por diferentes filtros (tipo, fabricante, responsable, costes, etc.).
Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de , digamos, los switches instalados a la hora de adoptar decisiones de compra de nuevo material:
5.3.4 Control
La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de componentes para mantener actualizada la CMDB.
El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el software "en producción".
Las tareas de control deben centrarse en:
Asegurar que todos los componentes están registrados en la CMDB.
Monitorizar el estado de todos los componentes.
Actualizar las interrelaciones entre los CIs.
Informar sobre el estado de las licencias.
5.3.5 Auditorías
El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.
Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB.
Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:
Tras la implementación de una nueva CMDB.
Antes y después de cambios mayores en la infraestructura.
Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta.
Las auditorías deben dedicar especial atención a aspectos tales como:
Uso correcto de la nomenclatura en los registros de los CIs.
Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, ...
Estado de los CIs actualizado.
Cumplimiento de los niveles de alcance y detalle predeterminados.
Adecuación de la estructura de la CMDB con la de la estructura TI real.
5.4 Control del Proceso
Una correcta Gestión de Configuraciones necesita la colaboración de toda la estructura TI para mantener actualizada la información almacenada en la CMDB.
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Configuraciones, tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
Alcance y nivel de detalle de la CMDB.
Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.
Información sobre CIs que han estado involucrados en incidentes.
Costes asociados al proceso.
Sistemas de clasificación y nomenclatura utilizados.
Informes sobre configuraciones no autorizadas y/o sin licencias.
Calidad del proceso de registro y clasificación.
Información estadística y composición de la estructura TI.
En pequeñas organizaciones es a veces conveniente combinar la Gestión de Configuraciones y Cambios para simplificar el proceso de control. La coordinación entre ambos procesos es un factor
crítico para el éxito y ésta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la total separación de estos procesos.
5.5 Caso Práctico
La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una "gran devoradora de recursos" si se establecen criterios excesivamente ambiciosos. Por ello la dirección de "Cater Matters" ha decidido, en una primera fase, limitar el alcance de la base de datos de configuraciones a los sistemas considerados críticos:
Servidores de red local.
Servidores de Internet.
Infraestructura informática del Centro de Servicios.
SLAs
Para simplificar aún más la gestión se ha decido uniformizar las configuraciones en una serie de"configuraciones de referencia" aplicables a los CIs arriba descritos.
Aunque esto ha supuesto una inversión inicial importante se ha considerado que sus ventajas eran obvias:
Reducción a medio/largo plazo de los costes asociados.
Mejora y consistencia de los servicios prestados.
Simplificación de todos los procesos asociados al soporte al servicio: Incidencias, Problemas, Cambios, Versiones, etc.
El haber optado por una serie de configuraciones estándar permite alcanzar un gran nivel de detalle sin necesidad de realizar un esfuerzo desmedido por lo que se han registrado:
Configuraciones de software:
o Sistemas operativos.
o Aplicaciones instaladas.
o Interdependencias: relaciones padre-hijo, propietarios,...
o Documentación asociada.
Configuraciones de hardware:
o Servidores y estaciones de trabajo.
o Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,...
o Documentación y controladores asociados.
SLAs e informes de seguimiento asociados.
A su vez se han instalado herramientas de gestión que permiten la monitorización remota de todas esas configuraciones y la realización de auditorías periódicas automatizada6.- s.
6.- Gestión de Cambios
6.1 Visión General
Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamente de un cambio.
Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizados.
Las principales razones para la realización de cambios en la infraestructura TI son:
Solución de errores conocidos.
Desarrollo de nuevos servicios.
Mejora de los servicios existentes.
Imperativo legal.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.
Las interacciones y funcionalidades de la Gestión de Cambios se resumen sucintamente en el siguiente interactivo:
6.2 Introducción y Objetivos
El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.
La Gestión de Cambios debe trabajar para asegurar que los cambios:
Están justificados.
Se llevan a cabo sin perjuicio de la calidad del servicio TI.
Están convenientemente registrados, clasificados y documentados.
Han sido cuidadosamente testeados en un entorno de prueba.
Se ven reflejados en la CMDB.
Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación.
Las actividades principales de la Gestión de Cambios se resumen sucintamente en el siguiente diagrama:
Los principales beneficios derivados de una correcta gestión del cambio son:
Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio.
Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI.
Se reduce el número de "back-outs" necesarios.
Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión.
La CMDB está correctamente actualizada, algo imprescindible para la correcta gestión del resto de procesos TI.
Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos.
La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:
Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un servicio o adaptarse a requisitos legales.
No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la información sobre los CIs en la CMDB.
Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad.
Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso.
No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.
Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.
6.2.1 Conceptos básicos
En el resto de este capítulo se utilizará con frecuencia el concepto de Gestor de Cambios yConsejo Asesor del Cambio (CAB), por lo que resulta conveniente describir y diferenciar sus respectivas atribuciones:
Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el último responsable de todas las tareas asignadas a la Gestión de Cambios. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas.
Consejo Asesor de Cambios (CAB): es un órgano interno, presidido por elGestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión de servicios TI. Sin embargo, en algunos casos también puede incorporar:
o Consultores externos.
o Representantes de los colectivos de usuarios.
o Representantes de los principales proveedores de software y hardware.
Alcance de la Gestión de Cambios
En principio, todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta.
El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de Configuraciones: todos los cambios de CIs inventariados en la CMDB deben ser correctamente supervisados y registrados.
Al igual que a la hora de implementar la Gestión de Configuraciones se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos están previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas.
Estos protocolos de cambio estándar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.
6.3 Proceso
Las principales actividades de la Gestión de Cambios se resumen en:
Monitorizar y dirigir todo el proceso de cambio.
Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de las RFCs y la elaboración del FSC.
Coordinar el desarrollo e implementación del cambio.
Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
6.3.1 Registro
El primer paso del proceso de cambio es registrar adecuadamente las RFCs.
El origen de una RFC puede ser de muy distinta índole:
Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso.
Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados.
Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM, etc. y que por regla general requieren de cambios de hardware, software y/o procedimientos.
Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualización.
Imperativo legal: un cambio de legislación (como, por ejemplo, la LOPD) puede exigir cambios en la infraestructura TI.
Otro: en principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura.
No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de laGestión de Cambios en cada caso.
Independientemente de su origen el correcto registro inicial de una RFC requerirá, cuando menos, de los siguientes datos:
Fecha de recepción.
Identificador único de la RFC.
Identificador del error conocido asociado (dado el caso).
Descripción del cambio propuesto:
o Motivación.
o Propósito.
o CIs involucrados.
o Estimación de recursos necesarios para la implementación.
o Tiempo estimado.
Estatus: que inicialmente será el de "registrado".
Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre.
La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:
Estatus actualizado: "aceptado", "rechazado", "implementado", ...
Fecha de aceptación (denegación) del RFC.
Evaluación preliminar de la Gestión del Cambio.
Prioridad y categoría.
Planes de "back out".
Recursos asignados.
Fecha de implementación.
Plan de implementación.
Cronograma.
Revisión post-implementación.
Evaluación final.
Fecha de cierre.
6.3.2 Aceptación y Clasificación
Aceptación
Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFCo para que pueda ser consecuentemente modificada.
La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrada justificado su ulterior procesamiento.
Clasificación
Tras su aceptación se deben asignar a la RFC una prioridad y categoría dependiendo de la urgencia y el impacto de la misma.
La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será el dato relevante para establecer el calendario de cambios a realizar.
La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio.
Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación que incluyera, al menos, los siguientes niveles de prioridad:
Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo hardware, etc.
Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad.
Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución.
Urgente: es necesario resolver un problema que esta provocando una interrupción o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente.
La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección.
Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento.
6.3.3 Aprobación y Planificación
La planificación es esencial para una buena gestión del cambio.
Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de "back out" que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.
En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar losRFCs pendientes y elaborar el FSC o calendario del cambio correspondiente.
Para su aprobación el cambio se debe evaluar minuciosamente:
¿Cuáles son los beneficios esperados del cambio propuesto?
¿Justifican esos beneficios los costes asociados al proceso de cambio?
¿Cuáles son los riesgos asociados?
¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?
¿Puede demorarse el cambio?
¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI?
¿Puede el cambio afectar los niveles establecidos de seguridad TI?
En el caso de cambios que tengan un alto impacto debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.
Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:
Se optimizan los recursos necesarios.
Se evitan posibles incompatibilidades entre diferentes cambios.
Sólo se necesita un plan de back-out.
Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.
6.3.4 Implementación
Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestión de Versiones, si lo es de supervisar y coordinar todo el proceso.
En la fase de desarrollo del cambio se deberá monitorizar el proceso para asegurar que:
Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas.
Se cumplen los calendarios previstos y la asignación de recursos es la adecuada.
El entorno de pruebas es realista y simula adecuadamente el entorno de producción.
Los planes de "back-out" permitirán la rápida recuperación de la última configuración estable.
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:
Funcionalidad.
Usabilidad.
Accesibilidad.
La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios).
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles participes del mismo:
Escuchando sus sugerencias.
Comunicando las ventajas asociadas.
Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes.
6.3.5 Evaluación
Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización.
Los aspectos fundamentales a tener en cuenta son:
¿Se cumplieron los objetivos previstos?
En que medida se aparto el proceso de las previsiones realizadas por la Gestión de Cambios.
¿Provocó el cambio problemas o interrupciones del servicio imprevistas?
¿Cuál ha sido la percepción de los usuarios respecto al cambio?
¿Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?¿Por qué?
Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.
Gestión de Cambios6.3.6 Cambios de Emergencia
Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente a veces resultan inevitables.
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia.
El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:
La reunión urgente del CAB y/o EC si esto fuera posible.
Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión del EC).
Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a posteriori.
Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.
6.4 Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:
RFCs solicitados.
Porcentaje de RFCs aceptados y aprobados.
Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
Tiempo medio del cambio dependiendo del impacto y la prioridad
Número de cambios de emergencia realizados.
Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
Numero de back-outs con una detallada explicación de los mismos.
Evaluaciones post-implementación.
Porcentajes de cambios cerrados sin incidencias ulteriores.
Incidencias asociadas a cambios realizados.
Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.
Gestión de Cambios6.5 Caso Práctico
Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de la empresa para gestionar tanto los pedidos como la cadena de suministro.
El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión de la Capacidad han informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.
Por otro lado, la dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más elevados niveles de servicio para incrementar su cuota de mercado.
Todo ello requiere un cambio sustancial en la estructura de software y hardware de los servicios de Internet y su interconexión con el software de gestión interna de la organización (ERP).
Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión de Cambios que tiene por objetivos:
Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.
Desarrollar una serie de WebServices que permitan:
o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.
Tras registrar adecuadamente la RFC:
Se le otorga el estatus de "aceptado" y se le asigna provisionalmente una prioridad normal y un alto impacto.
Se convoca una reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce y programación web.
Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso de implementación del sistema actual.
Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de Proyectos:
Una evaluación inicial de costes y recursos necesarios.
Una valoración del impacto de los cambios en la infraestructura TI.
Un cronograma preliminar del proceso.
Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles cambios.
Sopesando la documentación aportada y la estrategia de negocio de la organización el CABaprueba el cambio y:
Determina el calendario definitivo del cambio.
Asigna los recursos, internos y externos, necesarios.
Desarrolla un plan que permita la convivencia temporal de ambos sistemas online para asegurar la continuidad del servicio:
o Duplicación de toda la estructura web: se compraran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".
o Se desarrollarán aplicaciones de "traducción" que permitan mantener actualizadas las bases de datos antiguas para evitar la perdida de datos en caso de "back-out".
Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio.
Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una auditoria externa de todo el proceso.
Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de pruebas e implementación.
Tras la implementación del cambio y en colaboración con el "Soporte al Servicio" y la "Provisión del Servicio" la Gestión de Cambios:
Confirma el éxito del cambio:
o El nuevo sistema dispone de la capacidad suficiente para proporcionar los niveles de servicio y disponibilidad previstos.
o El nuevo sistema funciona sin errores aparentes.
o Los clientes y proveedores han percibido el cambio como una mejora en la prestación de servicios.
o Ha mejorado la productividad.
Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.
Evalúa el proceso.
Da por cerrado el cambio.
7.- GESTIÓN DE VERSIONES
7.1 Visión General
La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción.
La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.
La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.
Las interacciones y funcionalidades de la Gestión de Versiones se resumen sucintamente en el siguiente interactivo:
Gestión de VersionesIntroducción y Objetivos
Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea delicada la implementación de cualquier cambio.
La Gestión de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea específica de la Gestión de Versiones el diseñar, poner a prueba e instalar en el entorno de producción los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI.
Entre los principales objetivos de la Gestión de Versiones se incluyen:
Establecer una política de implementación de nuevas versiones de hardware y software.
Implementar las nuevas versiones de software y hardware en el entorno de producción tras su verificación en un entorno realista de pruebas.
Garantizar que el proceso de cambio cumpla las especificaciones de la RFCcorrespondiente.
Asegurar, en colaboración con la Gestión de Cambios y Configuraciones, que todos los cambios se ven correctamente reflejados en la CMDB.
Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la Biblioteca de Software Definitivo (DSL).
Mantener actualizado el Depósito de Hardware Definitivo (DHS).
Los beneficios de una correcta Gestión de Versiones se resumen en:
El proceso de cambio se realiza sin deterioro de la calidad de servicio.
Las nuevas versiones cumplen los objetivos propuestos.
Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado.
El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.
El correcto mantenimiento de la DSL impide que se pierdan (valiosas) copias de los archivos fuente.
Se reduce el número de copias de software ilegales.
Control centralizado del software y hardware desplegado.
Protección contra virus y problemas asociados a versiones de software incontroladas.
Las principales dificultades con las que topa la Gestión de Versiones son:
No existe una clara asignación de responsabilidades y/o la organización TI no acepta la figura dominante de la Gestión de Versiones en todo el proceso de implementación del cambio.
No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las nuevas versiones de software y hardware.
Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. Es habitual que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobre todo cuando ésta no ha sido la política tradicional de la misma.
Se realizan cambios sin tener en cuenta a la Gestión de Versiones argumentado que estos sólo son responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello.
Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última versión estable.
La implementación sincronizada de versiones en entornos altamente distribuidos.
La solución a estos problemas pasa por:
Un firme compromiso de la organización con la Gestión de Versiones y sus responsables.
Un adecuado plan de comunicación que informe a todos los responsables y usuarios de la organización TI de las ventajas de una correcta gestión de todo el proceso de cambio.
Gestión de VersionesConceptos básicos
Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.
Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:
Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, características técnicas, etc.
Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.
Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido.
Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique unívocamente. El sistema universalmente aceptado es:
Versiones mayores: 1.0, 2.0, etc.
Versiones menores: 1.1, 1.2, 1.3, etc.
Versiones de emergencia: 1.1.1, 1.1.2, etc
Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).
En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado.
El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión:
El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar:
Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.
Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no. Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.
Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas ofimáticos.
DSL
La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el entorno TI. Esto incluye no solo sistemas operativos y aplicaciones sino también controladores de dispositivos y documentación asociada.
La DSL debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en caso de que se deban implementar los planes de back-out.
La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos.
DHS
El Depósito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de producción.
Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIscorrespondientes se hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).
Gestión de VersionesProceso
Las principales actividades de la Gestión de Versiones se resumen en:
Establecer una política de planificación para la implementación de nuevas versiones.
Desarrollar o adquirir de terceros las nuevas versiones.
Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción.
Validar las nuevas versiones.
Implementar las nuevas versiones en el entorno de producción.
Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario.
Actualizar la DSL, el DHS y la CMDB.
Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Versiones:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión de VersionesPlanificación
Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Esto es especialmente importante para los casos de versiones menores y de emergencia pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso.
A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes factores:
Cómo puede afectar la nueva versión a otras áreas del entramado TI.
Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.
Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción.
Qué planes de back-out son necesarios.
Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI.
Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con garantías de éxito.
Quiénes serán los responsables directos en las diferentes etapas del proceso
Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén puntualmente informados y puedan percibir la nueva versión como una mejora.
Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos, gradual, ...
Cuál es la vida media útil esperada de la nueva versión.
Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.
Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva versión.
Gestión de VersionesDesarrollo
La Gestión de Versiones es la encargada del diseño y construcción de las nuevas versiones siguiendo las pautas marcadas en las RFCs correspondientes.
A veces el desarrollo se realizara "en la casa" y muchas otras requerirá la participación de proveedores externos. En este segundo caso, la tarea de la Gestión de Versiones será la de asegurar que el paquete o paquetes de software o hardware ofrecidos cumple las especificaciones detalladas en la RFC. Asimismo, la Gestión de Versiones será la responsable de todo el proceso de configuración necesario.
El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación necesarios para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:
Back-up automático de datos.
Actualizaciones necesarias de las Bases de Datos asociadas.
Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos.
Creación de logs asociados al proceso de instalación.
Parte integrante del desarrollo lo componen los planes de back-out asociados. Estos tendrán que tomar en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.
Gestión de VersionesValidación
Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producción una nueva versión con razonables garantías de éxito.
Las pruebas no deben limitarse a una validación de carácter técnico (ausencia de errores) sino que también deben realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple los requisitos establecidos y es razonablemente usable (siempre existe una inevitable resistencia al cambio en los usuarios que debe ser tenida en consideración).
Es importante que las pruebas incluyan los planes de back-out para asegurarnos que se podrá volver a la última versión estable de una forma rápida, ordenada y sin perdidas de valiosa información.
Las principales actividades realizadas en el proceso de prueba deben incluir:
Pruebas del correcto funcionamiento de la versión en un entorno realista.
Pruebas de los procedimientos automáticos o manuales de instalación.
Listas de "bugs" o errores detectados, si se diera el caso.
Pruebas de los planes de back-out.
Documentación para usuarios y personal de servicio.
La Gestión de Cambios será la encargada de dar la validación final a la versión para que se proceda a su instalación. Si la versión no fuera aceptada se devolverá a la Gestión de Cambiospara su reevaluación.
Gestión de VersionesImplementación
Llego el momento de la verdad: la distribución de la nueva versión, también conocida como rollout.
El rollout puede ser de varios tipos:
Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos.
Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.
El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. En particular los usuarios finales deben estar
puntualmente informados del calendario de lanzamiento y de cómo este puede afectar a sus actividades diarias.
Es imprescindible determinar claramente:
Los CIs que deben borrarse e instalarse y en que orden debe realizarse este proceso.
Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.
Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos o parciales.
Tras la distribución la Gestión de Versiones debe asegurarse de que:
Se incluya una copia de la versión en la DSL.
El DHS incorpore repuestos funcionales de los nuevos CIs.
La CMDB esté correctamente actualizada.
Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación necesaria para poder sacar el adecuado provecho de las mismas.
Tras la implementación, la Gestión de Versiones debe ser puntualmente informada por elService Desk de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.
Gestión de VersionesComunicación y Formación
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano.
Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena.
Es inútil disponer de un sofisticado servicio TI si los usuarios , debido a una incompleta (in)formación, no se encuentran en disposición de aprovechar sus ventajas.
La (in)formación debe estructurarse en distintos niveles:
Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el proceso.
Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales. Durante este proceso de prueba se documentarán y analizarán:
o La experiencia subjetiva de usuario.
o Los comentarios y sugerencias sobre usabilidad y funcionalidad. o Las dudas que hayan surgido durante el uso de la nueva versión.
o La claridad de la documentación que se pondrá a disposición del usuario final.
Cuando se considere oportuno se impartirán cursos presenciales o remotos mediante módulos de e-learning sobre el funcionamiento de la nueva versión.
Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y puedan solicitar ayuda o soporte técnico en el uso de la nueva versión.
Gestión de VersionesControl del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:
Número de lanzamientos de nuevas versiones.
Número de back-outs y razones de los mismos.
Incidencias asociadas a nuevas versiones.
Cumplimientos de los plazos previstos para cada despliegue.
Asignación de recursos en cada caso.
Corrección y alcance de la CMDB y la DHS.
Existencia de versiones ilegales de software.
Adecuado registro de las nuevas versiones en la CMDB.
Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios.
Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.
Gestión de VersionesCaso Práctico
La Gestión de Cambios ha aprobado (véase el caso práctico del capítulo anterior) un RFC que tiene como principales objetivos:
Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.
Desarrollar una serie de WebServices que permitan:
o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.
La Gestión de Versiones es la encargada del proceso de desarrollo, compra, prueba y distribución de las nuevas versiones de hardware y software asociadas. Para ello:
En colaboración con las Gestiones de Capacidad y Disponibilidad evalúa las necesidades del nuevo hardware y se encarga de su compra y configuración.
Contacta con sus proveedores habituales de desarrollo web para establecer de forma precisa las especificaciones del nuevo software y establecer un calendario de desarrollo.
Duplica la estructura web: se compran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".
Se crean scripts de traducción que permitan salvar los nuevos datos en la versión anterior para evitar su perdida en caso de back-out.
Se establece un calendario de pruebas con usuarios reales para que estos puedan probar y "aprobar" el nuevo servicio.
Se planifica un despliegue en dos fases:
I. Se implementa toda la estructura web pero los datos no se incorporan directamente en el ERP de la empresa.
II. Se completa el proceso con la integración mediante WebServices de los pedidos web en el ERP.
Se desarrolla un manual de usuario para la nueva versión y se crea una página FAQsen la web que incluyen las dudas más frecuentes elevadas por los usuarios en la fase de pruebas.
Se informa a los usuarios sobre la nueva versión y se avisa de posibles y cortas interrupciones del servicio en la fecha de instalación.
Se procede a la instalación de la nueva versión.
Se guarda una copia maestra de todo el software en la DSL.
Se actualiza la CMDB.
8.- Gestión de Niveles de ServicioVisión General
El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente.
La tecnología, al menos en lo que respecta a la gestión de servicios TI, no es un fin en sí misma sino un medio para aportar valor a los usuarios y clientes.
La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de negocio y todo ello a unos costes razonables.
Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de Servicio:
Conozca las necesidades de sus clientes.
Defina correctamente los servicios ofrecidos.
Monitorice la calidad del servicio respecto a los objetivos establecidos en los SLAs.
Las interacciones y funcionalidades de la Gestión de Niveles de Servicio se resumen sucintamente en el siguiente interactivo:
Gestión de Niveles de ServicioIntroducción y Objetivos
La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidad de los servicios TI ofrecidos.
La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidades y expectativas del cliente y los costes de los servicios asociados, de forma que estos sean asumibles tanto por el cliente como por la organización TI.
La Gestión de los Niveles de Servicio debe:
Documentar todos los servicios TI ofrecidos.
Presentar los servicios de forma comprensible para el cliente.
Centrarse en el cliente y su negocio y no en la tecnología.
Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades.
Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los servicios requeridos.
Establecer los indicadores claves de rendimiento del servicio TI.
Monitorizar la calidad de los servicios acordados con el objetivo último de mejorarlos a un coste aceptable por el cliente.
Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del Servicio (SIP).
Los principales beneficios de una correcta Gestión de Niveles de Servicio son:
Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente.
Se facilita la comunicación con los clientes impidiendo los malentendidos sobre las características y calidad de los servicios ofrecidos.
Se establecen objetivos claros y metrizables.
Se establecen claramente las responsabilidades respectivas de los clientes y proveedores del servicio.
Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos de actuación en caso de deterioro del servicio.
La constante monitorización del servicio permite detectar los "eslabones más débiles de la cadena" para su mejora.
La gestión TI conoce y comprende los servicios ofrecidos lo que facilita los acuerdos con proveedores y subcontratistas.
El personal del Service Desk dispone de la documentación necesaria (SLAs,OLAs,etc.) para llevar una relación fluida con clientes y proveedores.
Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante los clientes.
Lo que repercute a la larga en una mejora del servicio con la consecuente satisfacción de clientes y usuarios.
Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en:
No existe una buena comunicación con clientes y usuarios por lo que los SLAsacordados no recogen sus necesidades reales.
Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente.
No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente.
Los SLAs son excesivamente prolijos y técnicos incumpliendo así sus objetivos primordiales.
No se dedican los recursos suficientes pues la dirección los considera como un gasto añadido y no como parte integral del servicio ofrecido.
Problemas de comunicación: no todos los usuarios conocen las características del servicio y los niveles de calidad acordados.
No se monitoriza adecuada y consistentemente el cumplimiento de los SLAsdificultando así la mejora de la calidad del servicio.
No existe en la organización un verdadero compromiso con la calidad del servicio TI ofrecido.
Gestión de Niveles de ServicioConceptos básicos
Proveedores, clientes y usuarios
Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos.
Usuarios: las personas que utilizan el servicio.
Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el cliente.
Catálogo de Servicios
El Catálogo de Servicios no es sólo una herramienta imprescindible a la hora de simplificar la comunicación con el cliente sino que también puede ser una gran ayuda tanto a la organización interna como a la proyección exterior de la organización TI.
El Catálogo de Servicios debe:
Describir los servicios ofrecidos de manera no técnica y comprensible para clientes y personal no especializado.
Utilizarse como guía para orientar y dirigir a los clientes.
Incluir, en líneas generales, los niveles de servicio asociados con cada uno de los servicios ofrecidos.
Encontrarse a disposición del Service Desk y todo el personal que se halle en contacto directo con los clientes.
Requisitos de Nivel de Servicio (SLR)
El SLR debe incluir información detallada sobre las necesidades del cliente y sus expectativas de rendimiento y nivel de servicios.
El SLR constituye el elemento base para desarrollar el SLA y posibles OLAs correspondientes.
Hojas de Especificación
Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.
Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de determinados procesos, sirviendo de documento de base para la elaboración de los OLAs y UCscorrespondientes.
Programa de Calidad del Servicio (SQP)
El SQP debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles de calidad del servicio:
Objetivos de cada servicio.
Estimación de recursos.
Indicadores clave de rendimiento.
Procedimientos de monitorización de proveedores.
En resumen, el SQP debe contener la información necesaria para que la organización TI conozca los procesos y procedimientos involucrados en el suministro de los servicios prestados, asegurando que estos se alineen con los procesos de negocio y mantengan unos niveles de calidad adecuados.
Acuerdo de Nivel de Servicio (SLA)
El SLA debe recoger en un lenguaje no técnico, o cuando menos comprensible para el cliente, todos los detalles de los servicios brindados.
Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.
Acuerdo de Nivel de Operación (OLA)
El OLA es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio.
Contratos de Soporte (UC)
Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización TI.
Programa de Mejora del Servicio (SIP)
El SIP debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio como propuestas de mejora basadas en el avance de la tecnología.
El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a disposición de los gestores de los otros procesos TI.
Gestión de Niveles de ServicioProceso
Las principales actividades de la Gestión de Niveles de Servicio se resumen en:
Planificación:
o Asignación de recursos.
o Elaboración de un catálogo de servicios.
o Desarrollo de SLAs tipo.
o Herramientas para la monitorización de la calidad del servicio.
o Análisis e identificación de las necesidades del cliente.
o Elaboración del los Requisitos de Nivel de servicio(SLR), Hojas de Especificación del Servicio y Plan de Calidad del Servicio(SQP).
Implementación de los Acuerdos de Nivel del Servicio:
o Negociación.
o Acuerdos de Nivel de Operación.
o Contratos de Soporte.
Supervisión y revisión de los Acuerdos de Nivel de Servicio:
o Elaboración de informes de rendimiento.
o Control de los proveedores externos.
o Elaboración de Programas de Mejora del Servicio (SIP).
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión de Niveles de ServicioPlanificación
La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los estamentos de la organización TI. Y, si esto no fuera ya de por sí una labor lo suficientemente compleja, resulta imprescindible la colaboración activa de los clientes y usuarios de los servicios TI.
El objetivo primordial de la Gestión de Niveles de Servicio es definir, negociar y monitorizar la calidad de los servicios TI ofrecidos. Si los servicios no se adecuan a las necesidades del cliente, la
calidad de los mismos es deficiente o sus costes son desproporcionados, tendremos clientes insatisfechos y la organización TI será responsable de las consecuencias que se deriven de ello.
Todo el proceso de planificación previo debe estar orientado a dar respuestas a las siguiente preguntas:
¿Qué servicios debemos ofrecer a nuestros clientes?
¿Cuáles son las necesidades de nuestros clientes?
¿Cuál es el nivel adecuado de calidad de servicio?
¿Quiénes y cómo se van a suministrar esos servicios?
¿Cuáles serán los indicadores clave de rendimiento para los servicios prestados?
¿Disponemos de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados?
La respuesta a cada una de estas preguntas debe darse en forma de documentos, algunos de carácter interno y otros accesibles a los clientes, que pasamos a describir sucintamente a continuación.
En primer lugar la Gestión de Niveles de Servicio debe poner a disposición de toda la organización, pero en especial a disposición del Service Desk y la fuerza de ventas un Catálogo de Servicios.
Este catálogo de servicios debe describir, en un lenguaje comprensible para los no expertos, los productos y servicios ofrecidos junto a indicaciones generales del nivel de servicio ofrecido, tales como disponibilidad, tiempos de respuesta, etc.
La elaboración de este Catálogo de Servicios puede resultar una tarea compleja pues es necesario alinear aspectos técnicos con políticas de negocio pero es un documento imprescindible pues:
Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades.
Delimita las funciones y compromisos de la organización TI.
Puede ser utilizado como herramienta de venta.
Evita malentendidos entre los diferentes actores implicados en la prestación de servicios.
Sin embargo, en la mayoría de los casos, por muy detallado y completo que sea el Catálogo de Servicios, la complejidad de los servicios ofrecidos requiere un largo y extenso periodo de negociación con el cliente.
Los resultados de esta interacción/negociación deben ser incorporados al documento de Requisitos de Nivel de Servicio (SLR) que debe reflejar las necesidades del cliente y sus expectativas respecto a:
La funcionalidad y características del servicio.
La disponibilidad del servicio.
La interacción del servicio con su infraestructura TI o de otro tipo.
La continuidad del servicio.
Los niveles de calidad del servicio.
Tiempo y procedimientos de implantación del servicio.
La escalabilidad del servicio ofrecido.
Etc.
La información contenida en el SLR debe servir de base para elaborar la documentación interna que permita determinar "cómo" se prestara el servicio y "quién o quiénes" serán responsables del mismo.
Las Hojas de Especificación del Servicio deben contener:
Una descripción detallada, con todos los detalles técnicos necesarios, sobre como se prestará el servicio.
Cuáles serán los indicadores internos de rendimiento y calidad del servicio.
Cómo se implementará el servicio.
Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su infraestructura, está información deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de acordarse con el cliente y su responsables técnicos.
El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios.
En función de los requisitos plasmados en las Hojas de Especificación del Servicio se elabora un plan global que permita asignar los recursos a la organización TI, establecer metas claras basadas en los indicadores de rendimiento elegidos y asegurar que los niveles de calidad ofrecidos se adaptan a las necesidades de los clientes y a los compromisos asumidos por la organización.
En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportuno externalizar parte de los servicios el SQP servirá de documento guía para el establecimiento de los contratos con los proveedores externos.
Gestión de Niveles de ServicioImplementación
La fase de planificación debe concluir con la elaboración y aceptación de los acuerdos necesarios para la prestación del servicio.
Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de Operación yContratos de Soporte.
Acuerdos de Nivel de Servicio
Los SLAs deben contener una descripción del servicio que abarque desde los aspectos más generales hasta los detalles más específicos del servicio.
Es conveniente estructurar los SLAs más complejos en diversos documentos de forma que cada grupo involucrado reciba exclusivamente la información correspondiente al nivel en que se integra, ya sea en el lado del cliente como del proveedor.
La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos entre los que se encuentran:
La naturaleza del negocio del cliente.
Aspectos organizativos del proveedor y cliente.
Aspectos culturales locales.
Acuerdos de Nivel de Operación
Los OLAs son documentos de carácter interno de la propia organización TI que determinan los procesos y procedimiento necesarios para ofrecer los niveles de servicio acordados con los clientes.
El OLA, por su naturaleza, involucra detalles sobre la prestación del servicio que deben ser opacos para el cliente pero que resultan imprescindibles a la organización TI para su organización.
Contratos de Soporte
Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de prestación de servicios.
Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los Contratos de Soporte deben representar compromisos claros y perfectamente delimitados. A pesar de esta diferencia crucial, los UCs pueden considerarse como una extensión "externa" de los OLAs en el sentido de que persiguen el mismo fin: organizar los procesos y procedimientos necesarios para la correcta provisión del servicio.
Gestión de Niveles de ServicioMonitorización
El proceso de monitorización de los niveles de servicio es imprescindible si queremos mejorar progresivamente la calidad del servicio ofrecido, su rentabilidad y la satisfacción de los clientes y usuarios.
La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la organización como los relacionados con la percepción de los usuarios.
Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con anterioridad unos baremos de calidad del servicio que han de servir de guía en la elaboración de los informes correspondientes.
Las principales fuentes principales de información las constituyen:
La documentación disponible: SLAs, OLAs, UCs, etc.
La Gestión de Incidentes: que debe informar de las incidencias en el servicio y los tiempos de recuperación.
La Gestión de la Capacidad y la Disponibilidad: que debe proporcionar la información sobre la infraestructura utilizada para satisfacer la calidad de servicios acordada.
El Centro de Servicios (Service Desk): que mediante su trato diario con los clientes, usuarios y organización TI supervisa la calidad de los servicios y conoce la percepción del cliente respecto a los mismos.
Los informes de rendimiento elaborados deben cubrir factores clave tales como:
Cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio.
Quejas, justificadas o no, de los clientes y usuarios.
Utilización de la capacidad predefinida.
Disponibilidad del servicio.
Tiempos de respuesta.
Costes reales del servicio ofrecido.
Problemas detectados y cambios realizados para restaurar la calidad del servicio.
Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OLAs.
Gestión de Niveles de ServicioRevisión
La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de la calidad de los servicios ofrecidos.
Esta revisión debe realizarse en base a parámetros objetivos y metrizables resultado de la experiencia previa, los SLAs en vigencia y la evolución del Catálogo de Servicios.
Este proceso de revisión no debe limitarse a aquellos SLAs que por una razón u otra han sido incumplidos, aunque, evidentemente, en estos casos sea inexcusable, sino que debe tener como objetivo mejorar y homogeneizar la calidad del servicio.
El resultado de la revisión debe ser un Programa de Mejora del Servicio (SIP) que tome en cuenta factores tales como:
Problemas relacionados con el servicio TI y sus posibles causas.
Nuevas necesidades del cliente.
Avances tecnológicos.
Cumplimiento de los niveles de servicio.
Evaluación de los costes reales del servicio.
Implicaciones de una degradación de la calidad del servicio en la estructura organizativa del cliente.
Evaluación del rendimiento y capacitación del personal involucrado.
Reasignación de recursos.
Cumplimiento de los OLAs y UCs relacionados.
Percepción del cliente y usuarios sobre la calidad de servicio.
Necesidades de formación adicional a los usuarios de los servicios.
El SIP debe ser el documento base para negociar la renovación del SLA con el cliente y debe constituir un documento de referencia para la gestión de otros procesos TI como la Gestión de Cambios, Gestión de Problemas, etc.
Gestión de Niveles de ServicioControl del Proceso
El objetivo de la Gestión de Niveles de Servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del cliente pero esto no se puede llevar a cabo sin una buena gestión de los procesos involucrados.
Es esencial disponer de:
Unos objetivos claros y contrastables.
Un equipo con experiencia liderado por un Gestor de Niveles de Servicio con la cualificación y experiencia necesarios.
Una asignación clara de tareas y responsabilidades.
Indicadores específicos de rendimiento tales como:
o Porcentaje de servicios amparados bajo SLAs.
o Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la calidad del servicio.
o SIPs elaborados e impacto de los mismos en la calidad del servicio.
o Encuestas de satisfacción del cliente.
La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de laGestión de Niveles de Servicio y aporta información de vital importancia a otras áreas involucradas en el soporte y la provisión de los servicios TI.
Entre la documentación generada cabría destacar:
Informes Estadísticos de Rendimiento: donde se detallen los SLAs, OLAs y UCselaborados y el nivel de cumplimiento de los mismos, costes promedio asociados al proceso, etc.
Informes de Seguimiento: donde se especifiquen las acciones de monitorización realizadas, sus resultados y el grado de satisfacción de los clientes con el servicio prestado.
Planes de Mejora: donde se especifiquen las acciones propuestas para la mejora del servicio TI y el impacto que estas han tenido en la calidad del servicio.
Gestión de Niveles de ServicioCaso Práctico
La dirección de "Cater Matters" ha decidido implementar una Gestión de Niveles de Servicioque adapte a las necesidades de su organización los principios y recomendaciones de ITIL.
Para llevar a cabo esta tarea de la forma más eficiente posible se han determinado una serie de acciones iniciales que se resumen en:
Designación de un Gestor del proceso.
Elaboración de un catálogo de servicios.
Desarrollo de un Plan Integral de Calidad del Servicio.
Creación de "plantillas" para la creación de SLAs asociados a sus principales servicios.
Gestor de Niveles de Servicio
La dirección ha encargado a uno de sus directivos con más amplia experiencia en la relación con los clientes asumir el puesto de Gestor de Niveles de Servicio.
Su principal función es negociar y acordar, en representación de "Cater Matters", la provisión de servicios con los clientes.
Sus responsabilidades específicas incluyen:
Elaborar y mantener actualizado un catálogo de los servicios ofrecidos por "Cater Matters".
Determinar la estructura general de los SLAs, OLAs y UCs.
Negociar los SLAs, OLAs y UCs con clientes y proveedores
Supervisar el cumplimiento de los acuerdos de provisión del servicio con clientes y proveedores.
Mantener informados a la Dirección y la organización TI sobre el rendimiento de todo el proceso.
Determinar los Planes de Mejora del Servicio que solucionen las deficiencias en la calidad de los servicios prestados y/o adapten estos servicios a las nuevas necesidades de los clientes y a los últimos avances tecnológicos.
Interactuar con los otros procesos TI para asegurar que todos ellos reciben y aportan la información necesaria para el óptimo funcionamiento de la organización.
Elaboración del Catálogo de Servicios
Se ha decidido estructurar el Catálogo de Servicios en función de los diferentes tipos de clientes que contratan los servicios de "Cater Matters":
Particulares.
Pequeñas empresas.
Grandes corporaciones e instituciones y organismos públicos.
El objetivo del catálogo no es sólo dar a conocer los diferentes servicios sino mostrar claramente al (potencial) cliente cuales son las diferencias entre las diferentes opciones de un mismo "servicio base".
Para ello se elabora un catálogo online que permite comparar las diferentes "versiones" y realizar una estimación preliminar de los costes basándose en las diferentes opciones seleccionadas.
La descripción de cada servicio incluye información adicional sobre:
Plazos de entrega.
Disponibilidad del servicio (festivos, horarios nocturnos, etc.).
Servicios auxiliares.
WebServices asociados.
Disposiciones legales aplicables.
Programas de fidelización.
Soporte online.
Plan de Calidad del Servicio
Para asegurar la calidad del servicio se desarrolla un SQP que determina:
La responsabilidad de cada uno de los departamentos en el proceso de provisión del servicio.
Planes de contingencia en casos de deterioro grave de la calidad del servicio.
Indicadores clave de rendimiento y satisfacción del cliente.
Métodos de supervisión y seguimiento en tiempo real de los procesos involucrados en la prestación del servicio, como, por ejemplo, el reparto y la provisión de mercancía.
Protocolos de interacción del Service Desk con los clientes y usuarios.
Los niveles de seguridad, disponibilidad, capacidad y redundancia necesarios para asegurar la correcta provisión del servicio en colaboración con los responsables de dichos procesos.
SLAs prototipo
A fin de evitar que la elaboración de los SLAs se convierta en una tarea excesivamente compleja y tediosa se desarrollan plantillas para los diferentes tipos de servicios y clientes.
Cada SLA prototipo incluye:
Descripción general y no técnica de los servicios acordados.
Responsables del acuerdo tanto por el lado cliente como proveedor.
Plazos para la provisión del servicio.
Duración del acuerdo y condiciones para su renovación y/o rescisión.
Condiciones de disponibilidad del servicio.
Soporte y labores de mantenimiento asociadas.
Tiempos de respuesta.
Tiempos de recuperación en casos de incidentes.
Planes de contingencia si son de aplicación.
Métodos de facturación y cobro.
Criterios de evaluación de la calidad del servicio.
9.- Gestión Financiera de los Servicios TIVisión General
Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus procesos de negocio es moneda corriente que no exista una conciencia real de los costes que esta tecnología supone.
Esto conlleva serias desventajas:
Se desperdician recursos tecnológicos.
No se presupuestan correctamente los gastos asociados.
Es prácticamente imposible establecer una política consistente de precios.
El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costes asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos TI necesarios.
Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios no podrán evaluar el retorno a la inversión ni podrán establecer planes consistentes de inversión tecnológica.
Las propiedades y funcionalidades de la Gestión Financiera de los Servicios TI se resumen sucintamente en el siguiente interactivo:
Gestión Financiera de los Servicios TIIntroducción y Objetivos
La Gestión Financiera de los Servicios Informáticos tiene como objetivo principal administrar de manera eficaz y rentable los servicios y la organización TI.
Por regla general, a mayor calidad de los servicios mayor es su coste, por lo que es necesario evaluar cuidadosamente las necesidades del cliente para que el balance entre ambos sea óptimo.
Para lograr este objetivo la Gestión Financiera debe:
Evaluar los costes reales asociados a la prestación de servicios.
Proporcionar a la organización TI toda la información financiera precisa para la toma de decisiones y fijación de precios.
Asesorar al cliente sobre el valor añadido que proporcionan los servicios TI prestados.
Evaluar el retorno (ROI) de las inversiones TI.
Llevar la contabilidad de los gastos asociados a los servicios TI.
Los principales beneficios de una correcta Gestión Financiera de los Servicios Informáticosse resumen en:
Se reducen los costes y aumenta la rentabilidad del servicio.
Se ajustan, controlan, adecuan y justifican (si es de aplicación) los precios del servicio aumentando la satisfacción del cliente.
Los clientes contratan servicios que le ofrecen una buena relación coste/rentabilidad.
La organización TI puede planificar mejor sus inversiones al conocer los costes reales de los servicios TI.
Los servicios TI son usados más eficazmente.
La organización TI funciona como una unidad de negocio y es posible evaluar claramente su rendimiento global.
Las principales dificultades a la hora de implementar la Gestión Financiera de los Servicios Informáticos se resumen en:
Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos financieros y/o contables.
Existen múltiple costes ocultos difíciles de evaluar por una deficiente organización financiera.
No existe una estrategia clara que permita elaborar unos presupuestos ajustados a la misma.
Un incremento de los costes.
No hay un compromiso de toda la organización con el proceso.
Gestión Financiera de los Servicios TIConceptos Básicos
Categorías de coste
La clasificación de costes por servicio o producto puede realizarse en virtud de uno a más criterios:
Costes atribuibles, directa o indirectamente a la prestación del servicio o elaboración del producto:
Costes Directos: son los costes relacionados específica y exclusivamente con un producto o servicio, como por ejemplo, los servidores web asociados a los servicios de Internet.
Costes indirectos: aquellos que nos son específicos y exclusivos de un servicio, como por ejemplo, la "conectividad" de la organización TI de la que dependen tanto los servicios web como la propia plataforma general de comunicaciones. Estos costes son más difíciles de determinar y por lo general son prorrateados entre los diferentes servicios y productos.
Costes que dependen o no del "cuánto":
Costes fijos: son independientes del volumen de producción y están normalmente relacionados con gastos en inmovilizado material.
Costes variables: incluyen aquellos costes que dependen del volumen de producción y engloban, por ejemplo, los gastos de personal que presta los servicios, los fungibles, etc.
Costes que dependen del horizonte temporal:
Costes de capital: que proviene de la amortización del inmovilizado material o inversiones a largo plazo.
Costes de Operación: son los costes asociados al funcionamiento diario de la organización TI.
Tipos de coste
Es imprescindible distinguir entre los diferentes tipos de coste para diseñar una política de precios clara y consistente.
Los tipos de coste se subdividen a su vez en elementos de coste. El siguiente diagrama nos muestra una típica estructura de tipos y elementos de coste para una organización TI:
* Los costes de Transferencia se corresponden con los cargos internos por servicios prestados por otros departamentos de la empresa o institución.
Gestión Financiera de los Servicios TIProceso
Las principales actividades de la Gestión Financiera se resumen se resumen en:
Presupuestos:
o Análisis de la situación financiera.
o Fijación de políticas financieras.
o Elaboración de presupuestos.
Contabilidad:
o Identificación de los costes.
o Definición de elementos de coste.
o Monitorización de los costes.
Fijación de precios:
o Elaboración de una política de fijación de precios.
o Establecimiento de tarifas por los servicios prestados o productos ofrecidos.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión Financiera de los Servicios TIPresupuestos
La elaboración de presupuestos TI tiene como objetivos principales:
Planificar el gasto e inversión TI a largo plazo.
Asegurar que los servicios TI están suficientemente financiados.
Establecer objetivos claros que permitan evaluar el rendimiento de la organización TI.
Los presupuestos realizados pueden tener diferentes horizontes temporales. Pueden ser a corto plazo, incluyendo los costes de los servicios prestados en la actualidad, o resultar de una proyección sobre la evolución prevista del negocio en dos o más años.
Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales:
Presupuesto incremental: el presupuesto se realiza en base al histórico de presupuestos anteriores, adaptándolos a las modificaciones en los costes y el desarrollo de nuevas tecnologías, y teniendo en consideración la aparición de nuevas líneas de servicios.
Presupuesto "desde cero": se replantea toda la estructura de costes e inversiones a partir de una "hoja en blanco" en base a los servicios prestados en la actualidad y las expectativas de crecimiento en el periodo presupuestado.
Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI es necesario identificar previamente todos los elementos de coste.
La estimación de los costes asociados a esos elementos no es siempre una tarea sencilla y a menudo influyen factores externos que no se hallan bajo el control directo de la organización TI, como por ejemplo el aumento del precio de las licencias del software, etc.
Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos al respecto para evitar que se conviertan en papel mojado al menor vaivén del mercado.
Gestión Financiera de los Servicios TIContabilidad
En principio, la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada a otros servicios o departamentos. Sin embargo, la complejidad de las interrelaciones TI dificulta el proceso cuando los responsables de su contabilidad desconocen sus mecanismos básicos y la tecnología que los sustenta.
Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance un excesivo nivel de detalle que lo encarezca más allá de lo razonable.
Las actividades contables deben permitir:
Una correcta evaluación de los costes reales para su comparación con los presupuestados.
Tomar decisiones de negocio basadas en los costes de los servicios.
Evaluar la eficiencia financiera de cada uno de los servicios TI prestados.
Facturar adecuadamente, si es de aplicación, los servicios TI.
Si se desea considerar a la organización TI como otra unidad de negocio es necesario conocer en detalle tanto sus costes como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues el cliente es la propia organización).
Es una de las actividades principales de la Gestión Financiera identificar los denominadoselementos de coste que se pueden clasificar de forma genérica en:
costes de hardware y software,
costes de Personal,
costes generales,
asignando a cada servicio/cliente su parte proporcional.
Gestión Financiera de los Servicios TIPolítica de Precios
No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia organización, pero éste es un paso esencial si buscamos que se utilice eficientemente la infraestructura TI.
Para que la organización TI pueda funcionar como una verdadera unidad de negocio es imprescindible tanto conocer los costes reales de los servicios prestados como establecer una política de precios que, cuando menos, permita recuperar los costes en los que se ha incurrido.
En primer lugar debe establecerse una política de fijación de precios. Existen múltiples opciones, entre ellas:
Coste más margen: se establecen los costes totales del servicio y se les añade un margen de beneficios (que puede ser del 0% para "clientes internos").
Precio de mercado: se cobran los servicios en función de las tarifas vigentes en el mercado para servicios de similar naturaleza.
Precio negociado: se negocia directamente con el cliente cuál es el precio estipulado por los servicios.
Precio flexible: que depende de la capacidad TI realmente utilizada y/o de los objetivos cumplidos.
Una vez determinada la política de fijación de precios se deben determinar las tarifas de los servicios en función de:
La política elegida.
Los servicios solicitados.
Factores de escala y necesidades de disponibilidad.
Los costes asociados.
Los precios vigentes en el mercado.
En algunas ocasiones estas tarifas serán usadas para una facturación real mientras que en otras sólo se utilizarán de referencia para evaluar el rendimiento teórico de la organización TI.
Gestión Financiera de los Servicios TISupervisión
No es tarea de la Gestión Financiera de los Servicios TI sino de la Gestión de Niveles de Servicio negociar con los clientes y elaborar el catálogo de servicios. Sin embargo, es recomendable que, en los aspectos económicos, su actividad sea supervisada por la Gestión Financiera.
Para ello es necesario que exista una comunicación fluida y convenientemente estructurada entre ambos procesos.
Por un lado la Gestión de Niveles de Servicio debe proveer información a la Gestión Financiera sobre:
El tipo de servicios demandados por los clientes.
Los SLAs contratados.
Los contratos de soporte (UCs) en vigor.
Tendencias del mercado y Planes de Mejora del Servicio (SIP).
Mientras que la Gestión Financiera debe aportar información sobre:
Los costes reales de los servicios.
Previsiones de costes.
Desviaciones en las previsiones de costes respecto a los gastos reales.
Métodos y condiciones de pago.
Sin una estrecha colaboración entre ambos procesos será imposible llegar a acuerdos que sean rentables y a su vez satisfactorios para el cliente.
Gestión Financiera de los Servicios TIControl del Proceso
El responsable de el proceso de Gestión Financiera no ha de ser de manera imprescindible un miembro de la organización TI, es, sin embrago, imprescindible que disponga de ciertos conocimiento sobre los servicios TI y/o esté correctamente asesorado por especialistas en todo lo referente a la tecnología.
Para poder evaluar la función de la Gestión Financiera es necesario establecer tanto unos criterios claros para evaluar su éxito como unos indicadores de rendimiento específicos.
Entre los primeros cabe destacar:
¿Conoce la organización los costes reales de los servicios TI?
¿Los clientes perciben la política de precios como coherente y ajustada al mercado?
¿Colaboran los responsables de los otros procesos TI con la Gestión Financiera?
¿Están los gastos en servicios e infraestructuras TI realmente alineados con los procesos de negocio?
¿Opera la organización TI como una verdadera unidad de negocio?
En lo que respecta a los indicadores de rendimiento, estos deben incluir métricas que permitan evaluar si:
Los gastos TI están correctamente planificados y presupuestados.
Se cumplen los objetivos de costes e ingresos.
Se lleva a cabo una contabilidad precisa asociada a cada servicio.
Se conoce el ROI de las inversiones TI.
La organización TI funciona de manera "rentable".
La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Financiera según los parámetros arriba descritos y aporta información de vital importancia a la organización en su conjunto.
Entre la documentación generada cabría destacar:
Resúmenes contables.
Análisis de eficiencia de cada uno de los servicios TI.
Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología.
Planes de reducción de costes por servicio.
Gestión Financiera de los Servicios TICaso Práctico
La organización TI de "Cater Matters" lleva prestando, desde hace años, servicios esenciales tanto a la propia organización de la empresa como a los clientes externos de sus servicios de catering.
Sin embargo, hasta la fecha, los gastos TI no han sido contabilizados y presupuestados de manera específica y es, con los datos disponibles en la actualidad, imposible conocer el impacto de los servicios TI en los costes de cada uno de los servicios de catering prestados.
La gestión de "Cater Matters" quiere desarrollar una política de fijación de precios de los servicios TI que le permita trasladar sus costes al usuario final del servicio de catering,en la misma medida que ya se hace con los costes de transporte, materias primas, etc.
Para gestionar el proceso se ha nombrado a un senior manager del departamento TI y a un miembro del departamento financiero de la empresa como responsables del mismo.
El plan de trabajo a corto plazo incluye:
En colaboración con la Gestión de Configuraciones elaborar un listado de todos los CIs que intervienen en la prestación de servicios directos a los clientes.
Evaluar, prorrateando entre los diferentes servicios si esto fuera necesario, cuales son los costes asociados al uso de los mismos: amortización, mantenimiento, fungibles, etc.
Evaluar los costes de personal y los costes operativos.
Estimar los costes de difícil asignación u ocultos asociados a los servicios TI.
Evaluar los costes indirectos: instalaciones, costes administrativos, etc.
Establecer estrictos criterios contables para la administración de los costes TI.
Establecer una política de precios de coste adicional o "coste + margen".
Todas estas actividades buscan determinar con precisión los costes asociados a los servicios TI ya prestados y proponer tarifas que sean trasladas a los clientes, ya sea directamente o incluidas en otras partidas de carácter general.
Pero los objetivos de una Gestión Financiera proactiva van más allá e incluyen una correcta planificación de gastos e inversiones futuras. Para ello y en colaboración con la Gestión de Niveles de Servicio, Gestión de la Capacidad y Gestión de la Disponibilidad se estudian:
Los requisitos de los clientes y las tendencias de mercado.
El impacto en los costes de los Planes de Mejora del Servicio (SIP).
Necesidades futuras y proyecciones de la capacidad TI.
La información recopilada servirá de base para la elaboración de los primeros "presupuestos anuales TI" elaborados por la Gestión Financiera.
10.- Gestión de la CapacidadVisión General
La Gestión de la Capacidad es la encargada de que todos los servicios TI se vean respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada.
Sin una correcta Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son insuficientes con la consecuente degradación de la calidad del servicio.
Entre las responsabilidades de la Gestión de la Capacidad se encuentran:
Asegurar que se cubren las necesidades de capacidad TI tanto presentes como futuras.
Controlar el rendimiento de la infraestructura TI.
Desarrollar planes de capacidad asociados a los niveles de servicio acordados.
Gestionar y racionalizar la demanda de servicios TI.
Gestión de la CapacidadIntroducción y Objetivos
El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes, usuarios y el propio departamento TI los recursos informáticos necesarios para desempeñar de una manera eficiente sus tareas y todo ello sin incurrir en costes desproporcionados.
Para ello la Gestión de la Capacidad debe:
Conocer el estado actual de la tecnología y previsibles futuros desarrollos.
Conocer los planes de negocio y acuerdos de nivel de servicio para prever la capacidad necesaria.
Analizar el rendimiento de la infraestructura para monitorizar el uso de la capacidad existente.
Realizar modelos y simulaciones de capacidad para diferentes escenarios futuros previsibles.
Dimensionar adecuadamente los servicios y aplicaciones alineándolos a los procesos de negocio y necesidades reales del cliente.
Gestionar la demanda de servicios informáticos racionalizando su uso.
La Gestión de la Capacidad intenta evitar situaciones en las que se realizan inversiones innecesarias en tecnologías que no están adecuadas a las necesidades reales del negocio o están sobredimensionadas, o por el contrario, evitar situaciones en las que la productividad se ve mermada por un insuficiente o deficiente uso de las tecnologías existentes.
Ambos escenarios son habituales y a menudo se pueden encontrar conviviendo en una misma organización: directivos, clientes e informáticos deslumbrados por tecnologías que realmente no necesitan y adquieren pero que obvian aplicaciones, equipos y servicios que realmente aumentarían la productividad en sus respectivos entornos de trabajo.
Una de las principales tareas de la Gestión de la Capacidad es la de matizar la percepción de que la "capacidad es barata". Aunque el aumento de la capacidad puede requerir, en primera instancia, de modestos desembolsos, debido a la reducción de costes en los equipos de hardware y aplicaciones informáticas, la administración y mantenimiento de infraestructuras desproporcionadas puede resultar, a la larga, muy cara.
Los principales beneficios derivados de una correcta Gestión de la Capacidad son:
Se optimizan el rendimiento de los recursos informáticos.
Se dispone de la capacidad necesaria en el momento oportuno, evitando así que se pueda resentir la calidad del servicio.
Se evitan gastos innecesarios producidos por compras de "última hora".
Se planifica el crecimiento de la infraestructura adecuándolo a las necesidades reales de negocio.
Se reducen de los gastos de mantenimiento y administración asociados a equipos y aplicaciones obsoletos o innecesarios.
Se reducen posibles incompatibilidades y fallos en la infraestructura informática.
En resumen: se racionaliza la gestión de las compras y mantenimiento de los servicios TI con la consiguiente reducción de costes e incremento en el rendimiento.
La implementación de una adecuada política de Gestión de la Capacidad también se encuentra con algunas serias dificultades:
Información insuficiente para una planificación realista de la capacidad.
Expectativas injustificadas sobre el ahorro de costes y mejoras del rendimiento.
Insuficiencia de recursos para la correcta monitorización del rendimiento.
Infraestructuras informáticas distribuidas y excesivamente complejas en las que es difícil un correcto acceso a los datos.
No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.
La rápida evolución de las tecnologías puede obligar a una revisión permanente de los planes y escenarios contemplados.
Un correcto dimensionamiento de la propia Gestión de la Capacidad: un excesivo celo puede provocar costosos análisis de capacidad que podrían haber sido innecesarios con la compra de nuevo hardware o software.
Gestión de la CapacidadProceso
Las principales actividades de la Gestión de la Capacidad se resumen en:
Desarrollo del Plan de Capacidad.
Modelado y simulación de diferentes escenarios de capacidad.
Monitorización del uso y rendimiento de la infraestructura TI.
Gestión de la demanda.
Creación y mantenimiento de la Base de Datos de Capacidad (CDB).
El proceso de Gestión de la Capacidad puede segmentarse en subprocesos que analizan las necesidades de capacidad TI desde diferentes puntos de vista:
Gestión de la Capacidad del Negocio: que centra su objeto de atención en las necesidades futuras de usuarios y clientes.
Gestión de la Capacidad del Servicio: que analiza el rendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados.
Gestión de la Capacidad de Recursos: que estudia tanto el uso de la infraestructura TI como sus tendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizan eficazmente.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de la Capacidad:
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión de la CapacidadPlanificación
Plan de Capacidad
La elaboración del Plan de Capacidad es la tarea principal de la Gestión de Capacidad.
El Plan de Capacidad recoge:
Toda la información relativa a la capacidad de la infraestructura TI.
Las previsiones sobre necesidades futuras basadas en tendencias, previsiones de negocio y SLAs existentes.
Los cambios necesarios para adaptar la capacidad TI a las novedades tecnológicas y las necesidades emergentes de usuarios y cliente.
El Plan de Capacidad debe incluir información sobre los costes de la capacidad actual y prevista. Esta información es indispensable para que la Gestión Financiera pueda elaborar los presupuestos y previsiones financieras de manera realista.
Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o bianual es importante que se monitorice su cumplimiento para adoptar medidas correctivas en cuanto se detecten desviaciones importantes del mismo.
Modelado y Benchmarking
Cuanto más compleja sea una infraestructura informática más difícil es prever las necesidades de capacidad futura. En esos casos, es imprescindible realizar modelos y simulaciones sobre posibles escenarios de desarrollo futuro que aseguren la correcta escalabilidad de las aplicaciones y hardware.
El nivel de detalle al que se lleve este modelado dependerá de varios factores:
Costes asociados al incremento de la capacidad.
Costes inherentes al proceso mismo de modelado y simulación.
Alcance de los incrementos de capacidad previstos.
La "criticalidad" de los sistemas implicados.
Sopesando los anteriores factores podemos optar por:
Un simple análisis de tendencias que permita evaluar la carga de proceso esperada en la infraestructura informática y escalar consecuentemente su capacidad actual.
Realizar modelos y simulaciones sobre diferentes escenarios para llevar a cabo previsiones de carga y repuesta de la infraestructura informática.
Realizar benchmarks con prototipos reales para asegurar la capacidad y el rendimiento de la futura infraestructura.
Gestión de la CapacidadRecursos
Un aspecto esencial de la Gestión de la Capacidad es el de asignar recursos adecuados de hardware, software y personal a cada servicio y aplicación.
El correcto dimensionamiento requiere que la Gestión de la Capacidad disponga de información fiable sobre:
Los niveles de servicio acordados y/o previstos.
Niveles de rendimiento esperados.
Impacto de la aplicación o servicio en los procesos de negocio del cliente.
Márgenes de seguridad y disponibilidad.
Costes asociados a los equipos de hardware y otros recursos TI necesarios.
Es importante que la Gestión de la Capacidad participe en las primeras etapas de desarrollo de un producto, servicio o definición de un SLA para asegurar que se dispondrá de la capacidad necesaria para llevar el proyecto a buen término.
Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicación debido a expectativas injustificadas sobre la tecnología. Se puede caer en el equivoco de que los costes asociados a la capacidad se limitan a la compra de mas servidores, o más espacio de almacenamiento, etcétera, olvidando que sistemas más complejos implican uno mayores gastos de mantenimiento y administración, o ignorando los problemas que pueden conllevar dichos cambios.
Gestión de la CapacidadSupervisión del Proceso
La Gestión de la Capacidad es un proceso continuo e iterativo que monitoriza, analiza y evalúa el rendimiento y capacidad de la infraestructura TI y con los datos obtenidos optimiza los servicios o eleva una RFC a la Gestión de Cambios.
Tanto la información obtenida en estas actividades como la generada a partir de ella por laGestión de la Capacidad se almacena y registra en la Base de Datos de la Capacidad (CDB).
Monitorización
Su objetivo principal es asegurar que el rendimiento de la infraestructura informática se adecua a los requisitos de los SLAs.
La monitorización debe incluir, además de aspectos técnicos todos aquellos relativos a licencias y otros aspectos de carácter administrativo.
Análisis y Evaluación
Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas tales como petición de aumento de la capacidad o una mejor Gestión de la Demanda.
Optimización y cambios
Si se ha optado por solicitar un aumento de la capacidad se elevará una RFC a la Gestión de Cambios para que se desencadene todo el proceso necesario para la implementación del cambio. La Gestión de la Capacidad prestará su apoyo en todo el proceso y será corresponsable, junto a la Gestión de Cambios y Versiones de asegurar que el cambio solicitado cumpla los objetivos previstos.
En el caso de que una simple racionalización de la demanda sea suficiente para solventar las posibles deficiencias o incumplimientos de los SLAs será la propia Gestión de la Capacidad la responsable de gestionar ese subproceso.
Base de Datos de la Capacidad
La CDB debe cubrir toda la información de negocio, financiera, técnica y de servicio que reciba y genere la Gestión de la Capacidad relativas a la capacidad de la infraestructura y sus elementos.
Idealmente la CDB debe estar interrelacionada con la CMDB para que esta última ofrezca una imagen integral de los sistemas y aplicaciones con información relativa a su capacidad. Esto no es óbice para que ambas bases de datos puedan ser "físicamente independientes".
Gestión de la Capacidad
Gestión de la Demanda
El objetivo de la Gestión de la Demanda es el de optimizar y racionalizar el uso de los recursos TI.
Aunque la Gestión de la Demanda debe formar parte de las actividades rutinarias de la Gestión de la Capacidad ésta cobra especial relevancia cuando existen problemas de capacidad en la infraestructura TI.
El origen de los problemas que la Gestión de la Demanda debe subsanar a corto plazo incluyen:
Degradación del servicio por aumentos no previstos de la demanda.
Interrupciones parciales del servicio por errores de hardware o software.
La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en consecuencia.
Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Un aumento de la capacidad siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorización de la capacidad permite reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad.
Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por la organización se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicos asociados a procesos automáticos (tales como campañas de marketing promocional, informes de rendimiento para clientes, etcétera). En la mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio, ahorrando a la organización una gravosa ampliación del ancho de banda.
Ahora bien, si el coste añadido por aumentar el ancho de banda es marginal, puede resultar más eficiente su contratación directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en la optimización del sistema.
La Gestión de la Capacidad debe evaluar a priori, basandose en la experiencia y las tendencias del mercado, cuándo la solución "más potente, más grande" es económicamente más rentable (teniendo en cuenta los costes indirectos) que un análisis pormenorizado de la situación.
Gestión de la CapacidadControl del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Capacidad.
La documentación elaborada debe incluir información sobre:
El uso de recursos.
Desviaciones de la capacidad real sobre la planificada.
Análisis de tendencias en el uso de la capacidad.
Métricas establecidas para el análisis de la capacidad y monitorización del rendimiento.
Impacto en la calidad del servicio, disponibilidad y otros procesos TI.
El éxito de la Gestión de la Capacidad depende algunos indicadores clave entre los que se encuentran:
Correcta previsión de las necesidades de capacidad.
Reducción de los costes asociados a la capacidad.
Más altos niveles de disponibilidad y seguridad.
Mayor satisfacción de los usuarios y clientes.
Cumplimiento de los SLAs.
Gestión de la CapacidadCaso Práctico
Hasta la fecha, la Gestión de las Capacidad de "Cater Matters" había sido reactiva, o en otras palabras el incremento o redistribución de la capacidad se realizaba exclusivamente cuando aparecían los problemas.
Con el incremento de la importancia de los servicios TI, tanto para la organización de "Cater Matters" como para sus clientes, la dirección de la empresa ha decidido implementar las mejores prácticas ITIL para la Gestión de la Capacidad.
Para ello se ha nombrado un Gestor de la Capacidad que tiene como principales responsabilidades:
Monitorizar el rendimiento de la infraestructura TI prestando especial atención al de los servicios online, especialmente importantes a la hora de prestar un buen servicio a sus clientes.
Analizar en colaboración con la Gestión de Configuraciones el impacto de los diferentes CIs en la capacidad del sistema.
Evaluar, en colaboración con la Gestión de Niveles de Servicio, la carga de proceso, almacenamiento y ancho de banda que suponen los SLAs vigentes y previstos.
Evaluar, en colaboración con la Gestión Financiera, los costes reales de cada servicio.
Realizar informes periódicos sobre el estado de la tecnología relevante a los servicios ofrecidos.
Analizar tendencias y estadísticas de uso y carga sobre el sistema.
Los resultados de dicho trabajo deben permitir:
Elaborar un Plan de Capacidad anual que se revisara trimestralmente frente a datos reales extraídos de la monitorización del sistema y de las previsiones de negocio.
Poblar la Base de Datos de la Capacidad (CDB) para que contenga toda la información relevante a la capacidad.
Proponer mejoras del servicio.
Con el objetivo de:
Minimizar el número e impacto de futuros incidentes que degraden la calidad del servicio.
Racionalizar el uso de la capacidad de la infraestructura TI.
Disminuir los costes en infraestructura TI.
Aumentar la productividad y satisfacción del cliente.
11.- Gestión de la Continuidad del ServicioVisión General
La Gestión de la Continuidad del Servicio se preocupa de impedir que una imprevista y grave interrupción de los servicios TI, debido a desastres naturales u otras fuerzas de causa mayor, tenga consecuencias catastróficas para el negocio.
La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamente procedimientos:
Proactivos: que buscan impedir o minimizar las consecuencias de una grave interrupción del servicio.
Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea posible (y recomendable) tras el desastre.
La ITSCM requiere una implicación especial de los agentes involucrados pues sus beneficios sólo se perciben a largo plazo, es costosa y carece de rentabilidad directa. Implementar la ITSCM es como contratar un seguro médico: cuesta dinero, parece inútil mientras uno está sano y desearíamos nunca tener que utilizarlo, pero tarde o temprano nos alegramos de haber sido previsores.
Gestión de la Continuidad del ServicioIntroducción y Objetivos
Los objetivos principales de la Gestión de la Continuidad de los Servicios TI (ITSCM) se resumen en:
Garantizar la pronta recuperación de los servicios (críticos) TI tras un desastre.
Establecer políticas y procedimientos que eviten, en la medida de lo posible, las perniciosas consecuencias de un desastre o causa de fuerza mayor.
Aunque, a priori, las políticas proactivas que prevean y limiten los efectos de un desastre sobre los servicios TI son preferibles a las exclusivamente reactivas, es importante valorar los costes relativos y la incidencia real en la continuidad del negocio para decantarse por una de ellas o por una sabia combinación de ambas.
Una correcta ITSCM debe formar parte integrante de la Gestión de Continuidad del Negocio(BCM) y debe estar a su servicio. Los servicios TI no son sino una parte, aunque a menudo muy importante, del negocio en su conjunto y no tiene mayor sentido que, por ejemplo, un sistema de pedidos online siga funcionando a la perfección tras un desastre si nos resulta imposible suministrar la mercancía a nuestros clientes.
Es importante diferenciar entre desastres "de toda la vida", tales como incendios, inundaciones, etcétera, y desastres "puramente informáticos", tales como los producidos por ataques distribuidos de denegación de servicio (DDOS), virus informáticos, etcétera. Aunque es responsabilidad de la ITSCM prever los riesgos asociados en ambos casos y restaurar el servicio TI con prontitud, es evidente que recae sobre la ITSCM una responsabilidad especial en el último caso pues:
Sólo afectan directamente a los servicios TI pero paralizan a toda la organización.
Son más previsibles y más habituales.
La percepción del cliente es diferente: los desastres naturales son más asumibles y no se asocian a actitudes negligentes, aunque esto no sea siempre cierto.
Los principales beneficios de una correcta Gestión de la Continuidad del Servicio se resumen en:
Se gestionan adecuadamente los riesgos.
Se reduce el periodo de interrupción del servicio por causas de fuerza mayor.
Se mejora la confianza en la calidad del servicio entre clientes y usuarios.
Sirve de apoyo al proceso de Gestión de la Continuidad del Negocio.
Las principales dificultades a la hora de implementar la Gestión de la Continuidad del Serviciose resumen en:
Puede haber resistencia a realizar inversiones cuya rentabilidad no es inmediata.
No se presupuestan correctamente los costes asociados.
No se asignan los recursos suficientes.
No existe el compromiso suficiente con el proceso dentro de la organización y las tareas y actividades correspondientes se demoran perpetuamente para hacer frente a "actividades más urgentes".
No se realiza un correcto análisis de riesgos y se obvian amenazas y vulnerabilidades reales.
El personal no esta familiarizado con las acciones y procedimientos a tomar en caso de interrupción grave de los servicios.
Falta de coordinación con la BCM.
Gestión de la Continuidad del ServicioProceso
Las principales actividades de la Gestión de la Continuidad del Servicio se resumen en:
Establecer las políticas y alcance de la ITSCM.
Evaluar el impacto en el negocio de una interrupción de los servicios TI.
Analizar y prever los riesgos a los que esta expuesto la infraestructura TI.
Establecer las estrategias de continuidad del servicio TI.
Adoptar medidas proactivas de prevención del riesgo.
Desarrollar los planes de contingencia.
Poner a prueba dichos planes.
Formar al personal sobre los procedimientos necesarios para la pronta recuperación del servicio.
Revisar periódicamente los planes para adaptarlos a las necesidades reales del negocio.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión de la Continuidad del ServicioPolítica y Alcance
El primer paso necesario para desarrollar una Gestión de la Continuidad del Serviciocoherente es establecer claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política.
La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión.
Es imprescindible establecer el alcance de la ITSCM en función de:
Los planes generales de Continuidad del Negocio.
Los servicios TI estratégicos.
Los estándares de calidad adoptados.
El histórico de interrupciones graves de los servicios TI.
Las expectativas de negocio.
La disponibilidad de recursos.
La Gestión de la Continuidad del Servicio está abocada al fracaso sino se destina una cantidad de recursos suficientes, tanto en el plano humano como de equipamiento (software y hardware). Su dimensión depende de su alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa que no dispusiera de los recursos correspondientes.
Una importante parte del esfuerzo debe destinarse a la formación del personal. Éste debe interiorizar su papel en momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergencia no es el mejor momento para estudiar documentación y manuales.
Gestión de la Continuidad del ServicioAnálisis de Impacto
Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar determinar el impacto que una interrupción de los servicios TI pueden tener en el negocio.
En la actualidad casi todas las empresas, grandes y pequeñas, dependen en mayor o menor medida de los servicios informáticos, por lo que cabe esperar que un "apagón" de los servicios TI afecte a prácticamente todos los aspectos del negocio. Sin embargo, es evidente que hay servicios TI
estratégicos de cuya continuidad puede depender la supervivencia del negocio y otros que "simplemente" aumentan la productividad de la fuerza comercial y de trabajo.
Cuanto mayor sea el impacto asociado a la interrupción de un determinado servicio mayor habrá de ser el esfuerzo realizado en actividades de prevención. En aquellos casos en que la "solución puede esperar" se puede optar exclusivamente por planes de recuperación.
Los servicios TI han de ser analizados por la ITSCM en función de diversos parámetros:
Consecuencias de la interrupción del servicio en el negocio:
o Pérdida de rentabilidad.
o Pérdida de cuota de mercado.
o Mala imagen de marca.
o Otros efectos secundarios.
Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos de negocio.
Compromisos adquiridos a través de los SLAs.
Dependiendo de estos factores se buscará un balance entre las actividades de prevención y recuperación teniendo en cuenta sus respectivos costes financieros.
Gestión de la Continuidad del ServicioEvaluación de Riesgos
Sin conocer cuales son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar una política de prevención y recuperación ante desastre mínimamente eficaz.
La Gestión de la Continuidad del Servicio debe enumerar y evaluar, dependiendo de su probabilidad e impacto, los diferentes riesgos factores de riesgo. Para ello la ITSCM debe:
Conocer en profundidad la infraestructura TI y cuales son los elementos de configuración (CIs) involucrados en la prestación de cada servicio, especialmente los servicios TI críticos y estratégicos.
Analizar las posibles amenazas y estimar su probabilidad.
Detectar los puntos más vulnerables de la infraestructura TI.
.
Gracias a los resultados de este detallado análisis se dispondrá de información suficiente para proponer diferentes medidas de prevención y recuperación que se adapten a las necesidades reales del negocio.
La prevención frente a riesgos genéricos y poco probables puede ser muy cara y no estar siempre justificada, sin embargo, las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas, de rápida implementación y relativamente baratas.
Por ejemplo, si el riesgo de perdida de alimentación eléctrica es elevado debido, por ejemplo, a la localización geográfica se puede optar por deslocalizar ciertos servicios TI a través de ISPs que dispongan de sistemas de generadores redundantes o adquirir generadores que proporcionen la energía mínima necesaria para alimentar los CIs de los que dependen los servicios más críticos, etcétera.
Gestión de la Continuidad del ServicioEstrategias
La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas, que eviten la interrupción de los servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio en el menor tiempo posible.
Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención y recuperación que ofrezcan las garantías necesarias a unos costes razonables.
Actividades preventivas
Las medidas preventivas requieren un detallado análisis previo de riesgos y vulnerabilidades. Algunos de ellos serán de carácter general: incendios, desastres naturales, etcétera, mientras que otros tendrán un carácter estrictamente informático: fallo de sistemas de almacenamiento, ataques de hackers, virus informáticos, etcétera.
La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con la Gestión de la Continuidad del Negocio (BCM) y requieren medidas que implican a la infraestructura "física" de la organización.
La prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren especial atención de la ITSCM. En este aspecto es esencial la estrecha colaboración con la Gestión de la Seguridad.
Los sistemas de protección habituales son los de "Fortaleza" que ofrecen protección perimetral a la infraestructura TI. Aunque imprescindibles no se hallan exentos de sus propias dificultades pues aumentan la complejidad de la infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades.
Actividades de recuperación
Tarde o temprano, por muy eficientes que seamos en nuestras actividades de prevención, será necesario poner en marcha procedimientos de recuperación.
En líneas generales existen tres opciones de recuperación del servicio:
"Cold standby": que requiere un emplazamiento alternativo en el que podamos reproducir en pocos días nuestro entorno de producción y servicio. Esta opción es la adecuada si los planes de recuperación estiman que la organización puede mantener sus niveles de servicio durante este periodo sin el apoyo de la infraestructura TI.
"Warm standby": que requiere un emplazamiento alternativo con sistemas activos diseñados para recuperar los servicios críticos en un plazo de entre 24 y 72 horas.
"Hot standby": que requiere un emplazamiento alternativo con una replicación continua de datos y con todos los sistemas activos preparados para la inmediata sustitución de la estructura de producción. Ésta es evidentemente la opción mas costosa y debe emplearse sólo en el caso de que la interrupción del servicio TI tuviera inmediatas repercusiones comerciales.
Por supuesto, existe otra alternativa que consiste en hacer "poco o nada" y esperar que las aguas vuelvan naturalmente a su cauce: una alternativa poco recomendable para alguien que esté hojeando
este curso sobre ITIL y del que suponemos que los servicios TI jugarán un papel importante en su organización :-)
Gestión de la Continuidad del ServicioOrganización y Planificación
Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidas unas estrategias de prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con ese objetivo la Gestión de la Continuidad del Servicio debe elaborar una serie de documentos entre los que se incluyen:
Plan de prevención de riesgos.
Plan de gestión de emergencias.
Plan de recuperación.
Plan de prevención de riesgos
Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en la infraestructura TI.
Entre las medidas habituales se encuentran:
Almacenamiento de datos distribuidos.
Sistemas de alimentación eléctrica de soporte.
Políticas de back-ups.
Duplicación de sistemas críticos.
Sistemas de seguridad pasivos.
Plan de gestión de emergencias
Las crisis suelen provocar "reacciones de pánico" que pueden ser contraproducentes y a veces incluso más dañinas que las provocadas por el incidente que las causo. Por ello es imprescindible que en caso de situación de emergencia estén claramente determinadas las responsabilidades y funciones del personal así como los protocolos de acción correspondientes.
En principio los planes de gestión de emergencias deben tomar en cuenta aspectos tales como:
Evaluación del impacto de la contingencia en la infraestructura TI.
Asignación de funciones de emergencia al personal de servicio TI.
Comunicación a los usuarios y clientes de una grave interrupción o degradación del servicio.
Procedimientos de contacto y colaboración con los proveedores involucrados.
Protocolos para la puesta en marcha del plan de recuperación correspondiente.
Plan de recuperación
Cuando la interrupción del servicio es inevitable llego el momento de poner en marcha los procedimientos de recuperación.
El plan de recuperación debe incluir todo lo necesario para:
Reorganizar al personal involucrado.
Reestablecer los sistemas de hardware y software necesarios.
Recuperar los datos y reiniciar el servicio TI.
Los procedimientos de recuperación pueden depender de la importancia de la contingencia y de la opción de recuperación asociada ("cold o hot stand-by"), pero en general involucran:
Asignación de personal y recursos.
Instalaciones y hardware alternativos.
Planes de seguridad que garanticen la integridad de los datos.
Procedimientos de recuperación de datos.
Contratos de colaboración con otras organizaciones.
Protocolos de comunicación con los clientes.
Cuando se pone en marcha un plan de recuperación no hay espacio para la improvisación, cualquier decisión puede tener graves consecuencias tanto en la percepción que de nosotros tengan nuestros clientes como en los costes asociados al proceso.
Aunque pueda resultar paradójico, un "desastre" puede ser una buena oportunidad para demostrar a nuestros clientes la solidez de nuestra organización TI y por tanto incrementar la confianza que tiene depositada en nosotros. Ya conocen el dicho: "No hay mal que por bien no venga".
Gestión de la Continuidad del ServicioSupervisión
Una vez establecidas las políticas, estrategias y planes de prevención y recuperación es indispensable que estos no queden en papel mojado y que la organización TI esté preparada para su correcta implementación.
Ello depende de dos factores clave: la correcta formación del personal involucrado y la continua monitorización y evaluación de los planes para su adecuación a las necesidades reales del negocio.
Formación
Es inútil disponer de unos completos planes de prevención y recuperación si las personas que eventualmente deben llevarlos a cabo no están familiarizados con los mismos.
Es indispensable que la ITSCM:
De a conocer al conjunto de la organización TI los planes de prevención y recuperación.
Ofrezca formación específica sobre los diferentes procedimientos de prevención y recuperación.
Realice periódicamente simulacros para diferentes tipos de desastres con el fin de asegurar la capacitación del personal involucrado.
Facilite el acceso permanente a toda la información necesaria, por ejemplo, a través de la Intranet o portal B2E de la empresa.
Actualización y auditorías
Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los requisitos de la organización en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación.
En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos procesos de actualización y auditoria pueden establecerse de forma periódica.
La Gestión de Cambios juega un papel esencial en asegurar que los planes de recuperación y prevención estén actualizados manteniendo informada a la ITSCM de los cambios realizados o previstos.
Gestión de la Continuidad del ServicioControl del Proceso
La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión que incluyan información relevante para el resto de la organización TI.
Estos informes deben incluir:
Análisis sobre nuevos riesgos y evaluación de su impacto.
Evaluación de los simulacros de desastre realizados.
Actividades de prevención y recuperación realizadas.
Costes asociados a los planes de prevención y recuperación.
Preparación y capacitación del personal TI respecto a los planes y procedimientos de prevención y recuperación.
Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio es mantener la "concentración". Tras largos periodos en los que la prevención o, simple y llanamente, la suerte han impedido la existencia de graves interrupciones del servicio se puede caer en un relajamiento que puede acarrear graves consecuencias.
Por esto es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial se diluyan y la ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que "un desastre se convierta en una catástrofe".
Pero si el control del proceso es importante en condiciones normales éste se vuelve crítico durante las situaciones de crisis. La ITSCM debe garantizar:
La puesta en marcha de los planes preestablecidos.
La supervisión de los mismos.
La coordinación con la Gestión de Continuidad del Negocio.
La asignación de recursos necesarios.
Gestión de la Continuidad del ServicioCaso Práctico
La organización TI de "Cater Matters" carece de una Gestión de la Continuidad del Servicioque merezca ese nombre.
La gestión de "Cater Matters" es consciente de la importancia que tienen en la actualidad los servicios TI en toda su cadena de producción y distribución y pretende corregir esa situación.
De entre todos los servicios TI, los asociados a la gestión de existencias, por estar compuestas de productos perecederos, y los servicios online de pedidos son considerados de importancia estratégica por la dirección de la empresa. Por ello se decide que en primera instancia la ITSCMdebe garantizar la continuidad de dichos servicios en un plazo nunca superior a las 8 horas mientras que se establecen objetivos menos ambiciosos para otros servicios.
Se asigna a un ejecutivo senior del departamento TI el papel de gestor del proceso y se le encarga coordinar todas las actividades con la Gestión de la Continuidad del Negocio.
La Gestión de la Continuidad del Negocio ha firmado acuerdos de colaboración con otras empresas de catering para suministros de emergencia que cubran los clientes más importantes:
Servicios de catering de colegios y hospitales.
Congresos y eventos multitudinarios de todo tipo.
La coordinación en estos casos requiere el desarrollo de módulos especiales que permitan exportar las bases de datos de pedidos a formatos estándar de intercambio de datos para que estos puedan ser procesados por las otras organizaciones.
Por otro lado, se desarrolla una aplicación de gestión de emergencia de las existencias que permite administrar los pedidos a los proveedores y preservar la integridad de las existencias dependiendo de su información de caducidad y del impacto de la interrupción del negocio en las mismas.
Se establece asimismo:
Un calendario periódico de pruebas de los planes de recuperación.
Un calendario de cursos de formación sobre los protocolos de actuación en situación de emergencia.
Pero la Gestión de la Continuidad del Servicio no sólo debe aplicar medidas reactivas que mitiguen el impacto de una eventual interrupción del servicio, entre sus obligaciones se encuentran la elaboración de unos planes de prevención que eviten dichas situaciones.
Para evitar interrupciones de sus servicios online la ITSCM:
Contrata servicios de "housing" con un proveedor que dispone de conexiones con varios operadores al "backbone de Internet" y asegura alimentación eléctrica interrumpida.
Replica los sistemas críticos en diferentes localizaciones geográficas.
Supervisa la política de back-ups de los servidores de datos.
Instala sistemas de protección perimetral.
12.- Gestión de la DisponibilidadVisión General
Nuestras vidas, tanto personales como profesionales, dependen cada vez más de la tecnología. Ésta nos permite acceder a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñado hace unos pocos años.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestros proveedores tecnológicos. Con frecuencia una oferta diferente sólo se encuentra a un par de clics de distancia.
Por otro lado, el rápido desarrollo tecnológico implica una constante renovación de equipos y servicios. Como proveedores nos enfrentamos al reto de evolucionar sin apenas margen para el error pues nuestros sistemas han de encontrarse a disposición del cliente prácticamente 24/7.
La Gestión de la Disponibilidad es responsable de optimizar y monitorizar los servicios TI para que estos funcionen ininterrumpidamente y de manera fiable, cumpliendo los SLAs y todo ello a un coste razonable. La satisfacción del cliente y la rentabilidad de los servicios TI dependen en gran medida de su éxito.
Las interacciones y funciones de la Gestión de la Disponibilidad se resumen sucintamente en el siguiente interactivo:
Gestión de la DisponibilidadIntroducción y Objetivos
El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén disponibles y funcionen correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor.
Las responsabilidades de la Gestión de la Disponibilidad incluyen:
Determinar los requisitos de disponibilidad en estrecha colaboración con los clientes.
Garantizar el nivel de disponibilidad establecido para los servicios TI.
Monitorizar la disponibilidad de los sistemas TI.
Proponer mejoras en la infraestructura y servicios TI con el objetivo de aumentar los niveles de disponibilidad.
Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores internos y externos.
Los indicadores clave sobre los que se sustenta el proceso de Gestión de la Disponibilidad se resumen en:
Disponibilidad: porcentaje de tiempo sobre el total acordado en que los servicios TI han sido accesibles al usuario y han funcionado correctamente.
Fiabilidad: medida del tiempo durante el cual los servicios han funcionado correctamente de forma ininterrumpida.
Mantenibilidad: capacidad de mantener el servicio operativo y recuperarlo en caso de interrupción.
Capacidad de Servicio: determina la disponibilidad de los servicios internos y externos contratados y su adecuación a los OLAs y UCs en vigor. Cuando un servicio TI es subcontratado en su totalidad la disponibilidad y la capacidad de servicio son términos equivalentes.
.
La disponibilidad depende del correcto diseño de los servicios TI, la fiabilidad de los CIsinvolucrados, su correcto mantenimiento y la calidad de los servicios internos y externos acordados.
Los principales beneficios de una correcta Gestión de la Disponibilidad son:
Cumplimiento de los niveles de disponibilidad acordados.
Se reducen los costes asociados a un alto nivel de disponibilidad.
El cliente percibe una mayor calidad de servicio.
Se aumentan progresivamente los niveles de disponibilidad.
Se reduce el número de incidentes.
Las principales dificultades con las que topa la Gestión de la Disponibilidad son:
No se monitoriza correctamente la disponibilidad real del servicio.
No existe compromiso con el proceso dentro de la organización TI.
No se dispone de las herramientas de software y personal adecuado.
Los objetivos de disponibilidad no están alineados con las necesidades del cliente.
Falta de coordinación con los otros procesos.
Los proveedores internos y externos no reconocen la autoridad del Gestor de la Disponibilidad por falta de apoyo de la dirección.
Gestión de la DisponibilidadProceso
Entre las actividades que la Gestión de la Disponibilidad se encuentran:
Determinar cuales son los requisitos de disponibilidad reales del negocio.
Desarrollar un plan de disponibilidad donde se estimen las necesidades de disponibilidad futura a corto y medio plazo.
Mantenimiento del servicio en operación y recuperación del mismo en caso de fallo.
Realizar diagnósticos periódicos sobre la disponibilidad de los sistemas y servicios.
Evaluar la capacidad de servicio de los proveedores internos y externos.
Monitorizar la disponibilidad de los servicios TI.
Elaborar informes de seguimiento con la información recopilada sobre disponibilidad, fiabilidad, matenibilidad y cumplimiento de OLAs y UCs.
Evaluar el impacto de las políticas de seguridad en la disponibilidad.
Asesorar a la Gestión del Cambio sobre el posible impacto de un cambio en la disponibilidad.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión de la DisponibilidadRequisitos de Disponibilidad
Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de losSLAs.
La disponibilidad propuesta debe encontrase en línea tanto con los necesidades reales del negocio como con las posibilidades de la organización TI.
Aunque en principio todos los clientes estarán de acuerdo con unas elevadas cotas de disponibilidad es importante hacerles ver que una alta disponibilidad puede generar unos costes injustificados dadas sus necesidades reales. Quizá unas pocas horas sin un determinado servicio pueden representar poco más allá de una pequeña inconveniencia mientras que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la replicación de sistemas u otras medidas igualmente costosas que no van a tener una repercusión real en la rentabilidad del negocio.
Para llevar a cabo eficientemente está tarea es necesario que la Gestión de la Disponibilidad:
Identifique las actividades clave del negocio.
Cuantifique los intervalos razonables de interrupción de los diferentes servicios dependiendo de sus respectivos impactos.
Establezca los protocolos de mantenimiento y revisión de los servicios TI.
Determine las franjas horaria de disponibilidad de los servicios TI (24/7, 12/5, ...).
Gestión de la Disponibilidad
Planificación
La correcta planificación de la disponibilidad permite establecer unos niveles de disponibilidad adecuados tanto en lo que respecta a las necesidades reales del negocio como a las posibilidades de la organización TI.
El documento que debe recoger los objetivos de disponibilidad presentes y futuros y que medidas son necesarias para su cumplimiento es el Plan de Disponibilidad.
Este plan debe recoger:
La situación actual de disponibilidad de los servicios TI. Obviamente esta información debe ser actualizada periódicamente.
Herramientas para la monitorización de la disponibilidad.
Métodos y técnicas de análisis a utilizar.
Definiciones relevantes y precisas de las métricas a utilizar.
Planes de mejora de la disponibilidad.
Expectativas futuras de disponibilidad.
Es imprescindible que este plan proponga los cambios necesarios para que se cumplan los estándares previstos y colabore con la Gestión de Cambios y la Gestión de Versiones en su implementación (en caso de ser aprobados, claro está).
Para que este plan sea realista debe contar con la colaboración de los otros procesos TI involucrados.
Diseño para la Disponibilidad
Es crucial para una correcta Gestión de la Disponibilidad participar desde el inicio en el desarrollo de los nuevos servicios TI de forma que estos cumplan los estándares plasmados en el Plan de Disponibilidad.
Un diferente nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados o en las actividades necesarias para suministrar un determinado servicio TI. Si éste se diseña sin tener en cuenta futuras necesidades de disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo, incurriendo en costes adicionales innecesarios.
Gestión de la DisponibilidadMantenimiento y Seguridad
Aunque hayamos realizado un correcto diseño de los servicios según el Plan de Disponibilidady se hayan tomado todas las medidas preventivas necesarias, tarde o temprano, nos habremos de enfrentar a interrupciones del servicio.
En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto indeseado sobre los niveles de disponibilidad acordados.
Aunque la responsabilidad de restaurar el servicio corresponde a la Gestión de Incidentes y las actividades de recuperación han de ser coordinadas por el Service Desk, la Gestión de la Disponibilidad debe prestar su asesoramiento mediante planes de recuperación que tengan en cuenta:
Las necesidades de disponibilidad del negocio.
Las implicaciones del incidente en la infraestructura TI y los procesos necesarios para restaurar el servicio.
Gestión de las Interrupciones de Mantenimiento
Independientemente de las interrupciones del servicio causadas por incidencias es habitualmente necesario interrumpir el servicio para realizar labores de mantenimiento y/o actualización.
Estas interrupciones programadas pueden afectar a la disponibilidad del servicio y por lo tanto han de ser cuidadosamente planificadas para minimizar su impacto.
En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que ello sea posible, deben aprovecharse las franjas horarias de inactividad para realizar las tareas que implican una degradación o interrupción del servicio.
Si el servicio es 24/7 y la interrupción es necesaria se debe:
Consultar con el cliente en que franja horaria la interrupción del servicio afectará menos a sus actividades de negocio.
Informar con la antelación suficiente a todos los agentes implicados.
Incorporar dicha información a los SLAs.
Seguridad
Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es una correcta Gestión de la Seguridad.
Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del proceso.
Es tan importante determinar cuándo el servicio estará disponible como el "quién y cómo" va a utilizarlo. La disponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra.
Gestión de la DisponibilidadMonitorización de la Disponibilidad
La monitorización de la disponibilidad del servicio y la elaboración de los informes correspondientes son dos de las principales actividades de la Gestión de la Disponibilidad.
Desde el momento de la interrupción del servicio hasta su restitución o "tiempo de parada" el incidente pasa por distintas fases que deben ser individualizadamente analizadas:
Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo hasta que la organización TI tiene constancia del mismo.
Tiempo de respuesta: es el tiempo que transcurre desde la detección del problema hasta que se realiza un registro y diagnóstico del incidente.
Tiempo de reparación/recuperación: periodo de tiempo utilizado para reparar el fallo o encontrar un "workaround" o solución temporal al mismo y devolver el sistema a la situación anterior a la interrupción del servicio.
Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida de la interrupción del servicio. El cliente debe conocer estas métricas y dar su conformidad a las mismas para evitar malentendidos. En algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" y la interpretación puede diferir entre proveedores y clientes, por lo tanto, estás métricas deben de poder expresarse en términos que el cliente pueda entender.
Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y que debe poner a disposición del cliente en los informes de disponibilidad correspondientes incluyen:
Tiempo Medio de Parada (Downtime) : que es el tiempo promedio de duración de una interrupción de servicio, e incluye el tiempo de detección, respuesta y resolución.
Tiempo Medio entre Fallos (Uptime): es el tiempo medio durante el cual el servicio esta disponible sin interrupciones.
Tiempo Medio entre Incidentes: es el tiempo medio transcurrido entre incidentes que es igual a la suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos. El Tiempo Medio entre Incidentes es una medida de la fiabilidad del sistema.
Gestión de la DisponibilidadMétodos y Técnicas
Aunque llevamos hablando ya un buen rato de disponibilidad aún no hemos aportado un método para cuantificarla.
Es habitual definir la disponibilidad en tanto por ciento de la siguiente manera:
donde:
AST se corresponde con el tiempo acordado de servicio, DT es el tiempo de interrupción del servicio durante las franjas horarias de disponibilidad acordadas.
Por ejemplo, si el servicio es 24/7 y en el último mes el sistema ha estado caído durante 4 horas por tareas de mantenimiento la disponibilidad real del servicio fue:
La Gestión de la Disponibilidad tiene a su disposición un buen número de métodos y técnicas que le permiten determinar que factores intervienen en la disponibilidad del servicio y que le permiten consecuentemente prever que tipo de recursos se deben asignar para las labores de prevención, mantenimiento y recuperación, así como elaborar planes de mejora a partir de dichos análisis.
Entre dichas técnicas se cuentan:
CFIA
Que son las siglas de Component Failure Impact Analysis (Análisis del Impacto de Fallo de Componentes).
Mediante esté metodo se identifica el impacto que tiene en la disponibilidad de los servicios TI el fallo de cada elemento de configuración involucrado. Es evidente que este método requiere unaCMDB correctamente actualizada.
FTA
Que son las siglas de Failure Tree Analysis (Análisis del Árbol de Fallos).
Su objetivo es estudiar como se "propagan" los fallos a traves de la infraestructura TI para comprender mejor su impacto en la disponibilidad del servicio.
CRAMM
Que son las siglas de CCTA Risk Analysis and Management Method (Método de Gestión y Análisis de Riesgos de la CCTA).
Su objetivo es identificar los riesgos y vulnerabilidades a los que se haya expuesta la infraestructura TI con el objetivo de adoptar contramedidas que los reduzcan o que permitan recuperar rápidamente el servicio en caso de interrupción del mismo.
SOA
Que son las siglas de Service Outage Analysis (Análisis de Interrupción del Servicio).
Ésta técnica tiene como objetivo analizar las causas de los fallos detectados y proponer soluciones a los mismos.
Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente haciendo especial énfasis en aspectos no exclusivamente técnicos ligados directamente a la infraestructura TI.
Gestión de la DisponibilidadControl del Proceso
La Gestión de la Disponibilidad debe elaborar periódicamente informes sobre su gestión que incluyan información relevante tanto para los clientes como para el resto de la organización TI.
Estos informes deben incluir:
Técnicas y métodos utilizados para la prevención y el análisis de fallos.
Información estadística sobre:
o Tiempos de detección y respuesta a los fallos.
o Tiempos de reparación y recuperación del servicio.
o Tiempo medio de servicio entre fallos.
Disponibilidad real de los diferentes servicios.
Cumplimiento de los SLAs en todo lo referente a la disponibilidad y fiabilidad del servicio.
Cumplimiento de los OLAs y UCs en todo lo referente a la capacidad de servicio prestada por los proveedores internos y externos.
Para que toda esta información sea fácil y correctamente analizada es imprescindible el establecimiento de métricas precisas que permitan determinar de forma inequívoca parámetros tales como tiempos de parada y funcionamiento. Por ejemplo, en el caso de un servicio online de comercio electrónico se puede considerar que tiempos de respuesta superiores a 10 segundos son equivalentes a que el sistema esta caído, aunque estrictamente hablando el sistema termine respondiendo.
Gestión de la DisponibilidadCaso Práctico
La disponibilidad 12/7 es algo a lo que los clientes de "Cater Matters" otorgan una gran importancia.
Los servicios TI sólo juegan una pequeña, aunque importante, parte en los servicios prestados por la organización a sus clientes y los problemas de disponibilidad suelen proceder de procesos no directamente ligados con la tecnología. Sin embargo, una interrupción de los servicios online pueden presuponer un grave problema dado el alto volumen de pedidos que se reciben por dicho canal, la práctica totalidad, así como su importancia en el apartado de la gestión de stocks de materia prima.
La Gestión de la Disponibilidad, en colaboración con los responsables de otros procesos TI ha sido encargada de elaborar nuevos planes de disponibilidad que tengan en cuenta un rápido crecimiento del negocio que puede implicar una disponibilidad 24/7 para diferentes líneas de negocio.
La elaboración de este nuevo plan requiere:
La revisión de los UCs en vigor con los proveedores de servicios de Internet.
Definición de niveles de disponibilidad para los nuevos servicios.
Diseño para la disponibilidad 24/7 de los servicios TI ofrecidos.
Nuevos planes de gestión del mantenimiento que ahora requerirán una interrupción real del servicio.
Por otro lado, la gestión de "Cater Matters" ha decidido informar periódicamente a sus clientes sobre los niveles de rendimiento y disponibilidad de los diferentes servicios prestados. Para ello ha encargado a la Gestión de la Disponibilidad que implante los procedimientos necesarios para la medición del:
Tiempo transcurrido entre incidentes.
Tiempo de parada del servicio.
Tiempo de respuesta para cada incidente.
Retraso en el la entrega del servicio.
Que se complementarán con un módulo de cálculo estadístico y de generación automática de informes sobre el cumplimiento de los niveles de disponibilidad acordados para cada cliente.
De esta forma "Cater Matters" busca entablar una relación de confianza con sus clientes y mantener a la organización TI alerta sobre posibles degradaciones de los niveles de calidad del servicio.
13.- Gestión de la SeguridadVisión General
La Gestión de la Seguridad de la Información se remonta al albor de los tiempos. La criptología o la ciencia de la confidencialidad de la información se remonta al inicio de nuestra civilización y ha ocupado algunas de las mentes matemáticas más brillantes de la historia, especialmente (y desafortunadamente) en tiempos de guerra.
Sin embargo, desde el advenimiento de la ubicuas redes de comunicación y en especial Internet los problemas asociados a la seguridad de la información se han agravado considerablemente y nos afectan prácticamente a todos. Que levante la mano el que no haya sido victima de algún virus informático en su ordenador, del spam (ya sea por correo electrónico o teléfono) por una deficiente protección de sus datos personales o, aún peor, del robo del número de su tarjeta de crédito.
La información es consustancial al negocio y su correcta gestión debe apoyarse en tres pilares fundamentales:
Confidencialidad: la información debe ser sólo accesible a sus destinatarios predeterminados.
Integridad: la información debe ser correcta y completa.
Disponibilidad: debemos de tener acceso a la información cuando la necesitamos.
La Gestión de la Seguridad debe, por tanto, velar por que la información sea correcta y completa, esté siempre a disposición del negocio y sea utilizada sólo por aquellos que tienen autorización para hacerlo.
Las interacciones y funciones de la Gestión de la Seguridad se resumen sucintamente en el siguiente interactivo:
Gestión de la SeguridadIntroducción y Objetivos
Los principales objetivos de la Gestión de la Seguridad se resumen en:
Diseñar una política de seguridad, en colaboración con clientes y proveedores correctamente alineada con las necesidades del negocio.
Asegurar el cumplimiento de los estándares de seguridad acordados.
Minimizar los riesgos de seguridad que amenacen la continuidad del servicio.
La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de "expertos en seguridad" que desconocen los otros procesos de negocio. Si caemos en la tentación de establecer la seguridad como una prioridad en sí misma limitaremos las oportunidades de negocio que nos ofrece el flujo de información entre los diferentes agentes implicados y la apertura de nuevas redes y canales de comunicación.
La Gestión de la Seguridad debe conocer en profundidad el negocio y los servicios que presta la organización TI para establecer protocolos de seguridad que aseguren que la información esté accesible cuando se necesita por aquellos que tengan autorización para utilizarla.
Una vez comprendidos cuales son los requisitos de seguridad del negocio, la Gestión de la Seguridad debe supervisar que estos se hallen convenientemente plasmados en los SLAscorrespondientes para, a renglón seguido, garantizar su cumplimiento.
La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos generales a los que está expuesta la infraestructura TI, y que no necesariamente tienen porque figurar en un SLA, para asegurar, en la medida de lo posible, que no representan un peligro para la continuidad del servicio.
Es importante que la Gestión de la Seguridad sea proactiva y evalúe a priori los riesgos de seguridad que pueden suponer los cambios realizados en la infraestructura, nuevas líneas de negocio, etcétera.
Los principales beneficios de una correcta Gestión de la Seguridad:
Se evitan interrupciones del servicio causadas por virus, ataques informáticos, etcétera.
Se minimiza el número de incidentes.
Se tiene acceso a la información cuando se necesita y se preserva la integridad de los datos.
Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios.
Se cumplen los reglamentos sobre protección de datos.
Mejora la percepción y confianza de clientes y usuarios en lo que respecta a la calidad del servicio.
Las principales dificultades a la hora de implementar la Gestión de la Seguridad se resumen en:
No existe el suficiente compromiso de todos los miembros de la organización TI con el proceso.
Se establecen políticas de seguridad excesivamente restrictivas que afectan negativamente al negocio.
No se dispone de las herramientas necesarias para monitorizar y garantizar la seguridad del servicio (firewalls, antivirus, ...).
El personal no recibe una formación adecuada para la aplicación de los protocolos de seguridad.
Falta de coordinación entre los diferentes procesos lo que impide una correcta evaluación de los riesgos.
Gestión de la SeguridadProceso
La Gestión de la Seguridad esta estrechamente relacionada con prácticamente todos los otros procesos TI y necesita para su éxito la colaboración de toda la organización.
Para que esa colaboración sea eficaz es necesario que la Gestión de la Seguridad:
Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos.
Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados tanto en los servicios prestados a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos.
Implemente el Plan de Seguridad.
Monitorice y evalúe el cumplimiento de dicho plan.
Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y vulnerabilidades.
Realice periódicamente auditorías de seguridad.
Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.
Gestión de la SeguridadPolítica de Seguridad
Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a la Gestión de la Seguridad. Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos tales como los objetivos, responsabilidades y recursos.
En particular la Política de Seguridad debe determinar:
La relación con la política general del negocio.
La coordinación con los otros procesos TI.
Los protocolos de acceso a la información.
Los procedimientos de análisis de riesgos.
Los programas de formación.
El nivel de monitorización de la seguridad.
Qué informes deben ser emitidos periódicamente.
El alcance del Plan de Seguridad.
La estructura y responsables del proceso de Gestión de la Seguridad.
Los procesos y procedimientos empleados.
Los responsables de cada subproceso.
Los auditores externos e internos de seguridad.
Los recursos necesarios: software, hardware y personal.
Plan de Seguridad
El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos como parte de los SLAs, OLAs y UCs.
Este plan ha de ser desarrollado en colaboración con la Gestión de Niveles de Servicio que es la responsable en última instancia tanto de la calidad del servicio prestado a los clientes como la del servicio recibido por la propia organización TI y los proveedores externos.
El Plan de Seguridad debe diseñarse para ofrecer un mejor y más seguro servicio al cliente y nunca como un obstáculo para el desarrollo de sus actividades de negocio.
Siempre que sea posible deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad acordados.
Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes en todas las fases del servicio y para todos los estamentos implicados. "Una cadena es tan resistente como el más débil de sus eslabones", por lo que carece de sentido, por ejemplo, establecer una estrictas normas de acceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante algún tiempo ofreciendo la imagen de "fortaleza" pero esto valdrá de poco si alguien descubre que la "puerta de atrás está abierta".
Gestión de la SeguridadAplicación de las Medidas de Seguridad
Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica.
Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas de seguridad establecidas en la Política y el Plan de Seguridad.
En primer lugar la Gestión de la Seguridad debe verificar que:
El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al respecto.
Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad.
Se imparte la formación pertinente.
Es también responsabilidad directa de la Gestión de la Seguridad:
Asignar los recursos necesarios.
Generar la documentación de referencia necesaria.
Colaborar con el Service Desk y la Gestión de Incidentes en el tratamiento y resolución de incidentes relacionados con la seguridad.
Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad.
Colaborar con la Gestión de Cambios y Versiones para asegurar que no se introducen nuevas vulnerabilidades en los sistemas en producción o entornos de pruebas.
Proponer RFCs a la Gestión de Cambios que aumenten los niveles de seguridad.
Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la integridad y confidencialidad de los datos en caso de desastre.
Establecer las políticas y protocolos de acceso a la información.
Monitorizar las redes y servicios en red para detectar intrusiones y ataques.
Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión de la Seguridadrespecto a todas estas cuestiones y que incluso permita que ésta proponga medidas disciplinarias vinculantes cuando los empleados u otro personal relacionado con la seguridad de los servicios incumpla con sus responsabilidades.
Gestión de la SeguridadEvaluación y Mantenimiento
Evaluación
No es posible mejorar aquello que no se conoce, es por la tanto indispensable evaluar el cumplimiento de las medidas de seguridad, sus resultados y el cumplimiento de los SLAs.
Aunque no es imprescindible, es recomendable que estas evaluaciones se complementen con auditorías de seguridad externas y/o internas realizadas por personal independiente de laGestión de la Seguridad.
Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que se plasmaran en RFCs que habrán de ser evaluados por la Gestión de Cambios.
Independientemente de estas evaluaciones de carácter periódico se deberán generar informes independientes cada vez que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo considera oportuno, estos informes se acompañaran de las RFCs correspondientes.
Mantenimiento
La Gestión de la Seguridad es un proceso continuo y se han de mantener al día el Plan de Seguridad y las secciones de seguridad de los SLAs.
Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluación arriba citada o de cambios implementados en la infraestructura o servicios TI.
No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas.
Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte las medidas necesarias de actualización de equipos de hardware y software, sin olvidar el apartado de formación: el factor humano es normalmente el eslabón más débil de la cadena.
Gestión de la SeguridadControl del Proceso
Al igual que en el resto de procesos TI es necesario realizar un riguroso control del proceso para asegurar que la Gestión de la Seguridad cumple sus objetivos.
Una buena Gestión de la Seguridad debe traducirse en una:
Disminución del número de incidentes relacionados con la seguridad.
Un acceso eficiente a la información por el personal autorizado.
Gestión proactiva que permita identificar vulnerabilidades potenciales antes de que estas se manifiesten y provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridady aporta información de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
Informes sobre el cumplimiento, en lo todo lo referente al apartado de seguridad, de los SLAs, OLAs y UCs en vigor.
Relación de incidentes relacionados con la seguridad calificados por su impacto sobre la calidad del servicio.
Evaluación de los programas de formación impartidos y sus resultados.
Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI.
Auditorías de seguridad.
Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos.
Gestión de la SeguridadCaso Práctico
La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en el concepto de "fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información actualizada sobre sus pedidos, pagos pendientes, etcétera y eso requiere la interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse canales al exterior desde el núcleo TI de la organización.
La dirección de "Cater Matters" ha decidido crear una serie de Web Services que permitan el acceso a dicha información preservando su confidencialidad e integridad. Esto requiere la revisión del Plan de Seguridad y las secciones de seguridad de los SLAs en vigor.
Como medidas de seguridad básicas:
Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs autorizadas de clientes podrán disponer del servicio.
Se implementan protocolos de encriptación de los archivos XML intercambiados.
Se requiere autenticación para el acceso al servicio.
Se monitoriza la interacción con la aplicación para detectar posibles ataques externos.
Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
Se autoriza un solo canal de entrada a los servidores locales a través de los servidores web de la empresa.
Se propone una evaluación periódica del servicio con el objetivo de detectar vulnerabilidades y adoptar medidas correctivas.
El objetivo es dar un servicio de calidad y con altos niveles de seguridad que fidelice a los clientes en un tiempo de rápido desarrollo en el que la competencia se encuentra a un "solo clic de distancia".
Gestión de la SeguridadCaso Práctico
La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en el concepto de "fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información actualizada sobre sus pedidos, pagos pendientes, etcétera y eso requiere la interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse canales al exterior desde el núcleo TI de la organización.
La dirección de "Cater Matters" ha decidido crear una serie de Web Services que permitan el acceso a dicha información preservando su confidencialidad e integridad. Esto requiere la revisión del Plan de Seguridad y las secciones de seguridad de los SLAs en vigor.
Como medidas de seguridad básicas:
Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs autorizadas de clientes podrán disponer del servicio.
Se implementan protocolos de encriptación de los archivos XML intercambiados.
Se requiere autenticación para el acceso al servicio.
Se monitoriza la interacción con la aplicación para detectar posibles ataques externos.
Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
Se autoriza un solo canal de entrada a los servidores locales a través de los servidores web de la empresa.
Se propone una evaluación periódica del servicio con el objetivo de detectar vulnerabilidades y adoptar medidas correctivas.
El objetivo es dar un servicio de calidad y con altos niveles de seguridad que fidelice a los clientes en un tiempo de rápido desarrollo en el que la competencia se encuentra a un "solo clic de distancia".
Gestión de la SeguridadCaso Práctico
La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en el concepto de "fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información actualizada sobre sus pedidos, pagos pendientes, etcétera y eso requiere la interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse canales al exterior desde el núcleo TI de la organización.
La dirección de "Cater Matters" ha decidido crear una serie de Web Services que permitan el acceso a dicha información preservando su confidencialidad e integridad. Esto requiere la revisión del Plan de Seguridad y las secciones de seguridad de los SLAs en vigor.
Como medidas de seguridad básicas:
Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs autorizadas de clientes podrán disponer del servicio.
Se implementan protocolos de encriptación de los archivos XML intercambiados.
Se requiere autenticación para el acceso al servicio.
Se monitoriza la interacción con la aplicación para detectar posibles ataques externos.
Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
Se autoriza un solo canal de entrada a los servidores locales a través de los servidores web de la empresa.
Se propone una evaluación periódica del servicio con el objetivo de detectar vulnerabilidades y adoptar medidas correctivas.
El objetivo es dar un servicio de calidad y con altos niveles de seguridad que fidelice a los clientes en un tiempo de rápido desarrollo en el que la competencia se encuentra a un "solo clic de distancia".
Gestión de la SeguridadCaso Práctico
La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en el concepto de "fortificación frente a ataques" no se corresponde con las necesidades de negocio.
Es importante que los clientes de "Cater Matters" tengan acceso a información actualizada sobre sus pedidos, pagos pendientes, etcétera y eso requiere la interacción con el ERP de la empresa.
Esto, obviamente, presenta algunos problemas de seguridad adicionales pues han de abrirse canales al exterior desde el núcleo TI de la organización.
La dirección de "Cater Matters" ha decidido crear una serie de Web Services que permitan el acceso a dicha información preservando su confidencialidad e integridad. Esto requiere la revisión del Plan de Seguridad y las secciones de seguridad de los SLAs en vigor.
Como medidas de seguridad básicas:
Se limitan los rangos de IPs que pueden acceder al servicio. Sólo IPs autorizadas de clientes podrán disponer del servicio.
Se implementan protocolos de encriptación de los archivos XML intercambiados.
Se requiere autenticación para el acceso al servicio.
Se monitoriza la interacción con la aplicación para detectar posibles ataques externos.
Se guarda un registro de uso: quién, cuándo y cómo utilizó la aplicación.
Se autoriza un solo canal de entrada a los servidores locales a través de los servidores web de la empresa.
Se propone una evaluación periódica del servicio con el objetivo de detectar vulnerabilidades y adoptar medidas correctivas.
El objetivo es dar un servicio de calidad y con altos niveles de seguridad que fidelice a los clientes en un tiempo de rápido desarrollo en el que la competencia se encuentra a un "solo clic de distancia".
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_la_seguridad/caso_practico_gestion_de_la_seguridad/caso_practico_gestion_de_la_seguridad.php