Itil Clase Acc

8/3/2019 Itil Clase Acc

http://slidepdf.com/reader/full/itil-clase-acc 1/123

Fundamentos de la Gestión TI

Gestión de Servicios TI

Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papelen la misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestiónse 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 vezgenera ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debeconsiderarse 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 formaeran equiparables con el otro material de oficina: algo importante e indispensable para el correctofuncionamiento de la organización pero poco más.

Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una partesustancial de los procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuasredes 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 TIGenerar 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



Fundamentos de la Gestión TI ¿Qué es ITIL?

Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) seha 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 lossectores a través de su adopción por innumerables compañías como base para consulta, educación ysoporte 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 paraalcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidadcreciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y quesatisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre eldesarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como unsistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposiciónde los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos demantenimiento 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, losprocesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de losdepartamentos 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. Entodos 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 dosprincipales áreas de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tardesoportados por 30 libros complementarios que cubrían una numerosa variedad de temas, desde el cableadohasta la gestión de la continuidad del negocio. A partir del año 2000, se acometió una revisión de labiblioteca. En esta revisión, ITIL ha sido reestructurado para hacer más simple el acceder a la informaciónnecesaria para administrar sus servicios. Los libros centrales se han agrupado en dos, cubriendo las áreasde 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.




Soporte al Servicio

El soporte al servicio se preocupa de de todos los aspectos que garanticen la continuidad, disponibilidad ycalidad del servicio prestado al usuario.

El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de soporteal servicio según los estándares ITIL:




Provisión del Servicio

La provisión del servicio se ocupa de los servicios ofrecidos en si mismos. En particular de los Niveles deservicio, 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 deprovisión del servicio según los estándares ITIL:



Forum ITSMF

El ITSMF es el único Forum completamente indpendiente reconocido por el sector de la Gestión de ServiciosInformáticos. Esta asociación, con fines no lucrativos, juega un papel predominante en el desarrollo ypromoció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 ydistribución de sus productos en el mercado, por lo que resulta imprescindible adoptar unos estándares quepermitan 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, ofrecercompleta información sobre los mismos y organizar seminarios y conferencias para ayudar a las empresas aresolver 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 alITSMF. Osiatis es en la actualidad una de las empresa responsables de las actividades del Forum enEspaña y Francia (Claude Durand, Director de Desarrollo de Osiatis Francia, es tesorero de la asociación enese país).



Certificaciones ITIL

EXIN e ISEB

La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa "Information SystemsExamination Board" (ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. Fuerealizado en estrecha cooperación con la OGC y el itSMF. EXIN e ISEB son organizaciones sin ánimo de lucroque 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 pertinentedentro de una organización TI. Hasta la fecha, se han entregado más de 50.000 certificados Foundation aprofesionales 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 deorganizaciones, herramientas, servicios de educación y consultoría, marcos de trabajo relacionados, ypublicaciones. Desde 1990, se considera a ITIL como el marco de trabajo y la filosofía compartida porquienes utilizan las mejores prácticas ITIL en sus trabajos. Gran cantidad de organizaciones se encuentranen la actualidad cooperando internacionalmente para promover el estándar ITIL como un estándar de factopara 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

http://www.itil.co.uk/


http://www.exin.nl/

http://www.exin.nl/

http://www.itsmf.com/



http://www.exin.nl/





Gestión de Servicios TI: Caso Práctico

Para mejor ilustrar los contenidos de este "curso" cada capítulo incluye un caso práctico relacionadodirectamente con los contenidos del mismo.

Todos estos casos prácticos se refieren a una compañía (ficticia) dedicada al catering, "Cater Matters", queha 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 ylos plazos de entrega.

Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informáticoque le permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como susprocesos de producción y distribución.

La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar lametodología ITIL como la base de todos sus procesos y servicios. Entre las decisiones adoptadasconsecuentemente caben destacar:

Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con losclientes y el resto de la infraestructura TI.

Organización de sus actividades en torno 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



Centro de servicios (Service Desk)

Visión General

El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre loslos 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 todoslos procesos de soporte al servicio:

Registrando y monitorizando incidentes.

Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión deProblemas.

Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases dedatos correspondientes.

Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración conla Gestión de Cambios y Versiones

Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidadesen sus contactos con usuarios y clientes.


Introducción y Objetivos

Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente ycontinuo 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 unaatenció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 profundidadde 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 soporteté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 losservicios 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:

Supervisión de los contratos de mantenimiento y niveles de servicio.

Canalización de las Peticiones de Servicio de los clientes.

Gestión de las licencias de software.Centralización de todos los procesos asociados a la Gestión TI.

Los principales beneficios de una correcta implementció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 delmismo.

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.


Implementación

La implementación de un Service Desk requiere una meticulosa planificación. En primera instancia debeestablecerse:

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 nuestrasnecesidades 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ásdirectamente relacionados con el "factor humano" y que son tan importantes o más que los puramenteté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 unCentro de Servicios cuyos objetivos se alineen con nuestros procesos de negocio, mejoren la satisfacciónde nuestros clientes, optimicen la imagen externa de nuestra organización y nos sirva de plataforma paraidentificar nuevas oportunidades de negocio.




Estructura

Como ya se ha comentado anteriormente el Centro de Servicios es "EL" punto de contacto de toda laorganizació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 losmismos.

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

Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobrecumplimiento 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 estructuradiferente 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, productosy 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 diferentesemplazamientos 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 ydistribuidos.

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.




Actividades y Funciones

Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de laGestión de Servicios TI. Sin embargo, no cabe duda, de que su función principal es gestionar la relación conlos 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 merecerese nombre:

Gestión de Incidentes

Independientemente de que la completa gestión de las incidencias requiera la colaboración de otrosdepartamentos y personal, el Service Desk debe ofrecer una primera línea de soporte para la solución detodas 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ónprivilegiada a todos los procesos de gestión de los servicios TI. Es para ello imprescindible que se lleve unadecuado 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 demantenimiento externos.

Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externosdel mantenimiento y la Gestión de Incidentes que debe ser canalizada a través del Service Desk.




Equipo y formación

La imagen de marca de una empresa puede depender en gran medida de la calidad del servicio prestado porsu Service Desk.

Todos hemos sufrido frustrantes experiencias con grandes empresas que prometen un soporte continuo y dealta 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 laspersonas que lo integren. Es por tanto imprescindible establecer estrictos protocolos de selección yformació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.

Y, por último, recordar que sólo tenemos una oportunidad de ofrecer una buena primera impresión.




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 del Centro deServicios 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 eimpacto.

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 conseguirmediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los serviciosprestados.

Se puede optar por cerrar cada incidente o consulta con una serie de preguntas que permitan registrar laopinión del cliente respecto a la atención recibida, su satisfacción respecto a la solución ofrecida, etc. Todaesta información debe ser recopilada y analizada periódicamente para mejorar la calidad del servicio.

Centro de Servicios

Caso Practico

Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "CaterMatters" 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, lasfunciones principales del mismo:

Gestionar la primera línea de soporte de la Gestión de Incidentes.

Supervisar la calidad del servicio ofrecido respecto a los SLAs.

Ofrecer información de carácter comercial sobre los servicios ofrecidos.

Realizar encuestas periódicas sobre el grado de satisfacción del cliente.

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

Habilitar un espacio web para canalizar, en la medida de los posible, la interacción con los usuariosa través de este medio:

Formularios de consultas y alta de incidentes.



Consulta remota, mediante los web services asociados, del estado de los incidentes activos,históricos de incidencias y cumplimiento de los SLAs.

FAQs actualizadas que permitan a los usuarios consultar directamente sobre los serviciosprestados, errores conocidos, etc.

Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos deinteracció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óndel Service Desk.

Impartir formación específica:

Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del"Manual de Atención al Cliente".

Sobre las herramientas de software utilizadas.

Creación de un detallado plan de implantación progresiva del Service Desk .




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 sinoexclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entreambas.

Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguienteinteractivo:





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 SLA correspondiente.

Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (ServiceDesk) 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 sistemasde 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 queincluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información deacceso, 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 yrequiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestiónde 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 deconfiguració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 trabajandoconcurrentemente en la resolución del incidente.



Se pierde valiosa información sobre las causas y efectos de los incidentes para futurasreestructuraciones 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 yescalado.

No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puedeprovocar que se procesen peticiones que no se incluían en los servicios previamente acordadoscon el cliente.


Clasificación del Incidente

Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar unnivel 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 procesosde 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 delincidente 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 losrecursos 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 encontrarsoluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierredel incidente sin graves repercusiones.

Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. Elsiguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impactodel incidente:




Escalado y Soporte

Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente ypara ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan desu 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 elproblema.

Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisionesque se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar másrecursos 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 dePYMES




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




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 mismoCentro de Servicios o el soporte técnico, entre otros.

El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerloposteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente elproceso.

La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar enprimera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrarioreenviarlo a una autoridad competente.

Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de unusuario 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 necesariapara 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 incidenteque puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenidade la propia CMDB (hardware interrelacionado), etc.

Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estosdeben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual detrabajo.

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. Seidentifican 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 primerainstancia 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 deresolución del incidente en base al SLA correspondiente y la prioridad.




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 elmismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no soncapaces 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 lascorrespondientes bases de datos para que los agentes implicados dispongan de cumplida información sobreel estado del mismo.

Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no seencuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas parael 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 elincidente.

Cierra el incidente.


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 puntualsobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso deincumplimiento.

Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente porel servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte yatención al cliente.

Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sidofiel 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 dela 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 sobreasignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correctaimplementació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 yaregistrados y resueltos. Una (KB) actualizada permite:

Evitar escalados innecesarios.

Convertir el “know how” de los técnicos en un activo duradero de la empresa.

Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manerade 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 permitanevaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave aconsiderar 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.




Caso Práctico

El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor deuno de sus clientes.

Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días atravé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 hacevarios 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 necesitarápidamente el suministro.

Registra los datos del incidente.

Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un errorconocido y cuales son las posibles soluciones temporales

Propone una solución temporal al cliente: indica una zona reservada de la web desde la que sepueden realizar pedidos "urgentes" vía email.

Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo dela mañana.

Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de loshelados solicitados.

Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitadosantes del mediodía.

Por otro lado el departamento de sistemas:

Realiza una serie de pruebas y comprueba que, de manera general, el sistema funcionacorrectamente.

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óntemporal satisfactoria no se requiere un escalado superior.

Registra la solución temporal del incidente junto a la información proporcionada por eldepartamento de sistemas.

Da por cerrado el incidente.



Gestión de Problemas

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 losefectos 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 deprevenir incidentes incluso antes de que estos ocurran.

Las interacciones y funcionalidades de la Gestión de Problemas se resumen sucintamente en el siguienteinteractivo:





Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo elrestablecer lo más rápidamente la calidad del servicio y no el determinar cuales han sido los orígenes ycausas del mismo.

Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TIes 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 deimportancia 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ónde Incidentes se resumen en el siguiente interactivo:

Entre la funciones principales de la Gestión de Problemas figuran:

Identificar, registrar y clasificar los problemas.

Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales oparches.

Analizar y determinar las causas de los problemas y proponer soluciones.

Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en lainfraestructura TI.

Realizar un seguimiento post-implementación de todos los cambios para asegurar su correctofuncionamiento.



Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino quetambién sirvan de soporte a la estructura TI en su conjunto.

Analizar tendencias para prevenir incidentes potenciales.

Los principales beneficios de una correcta Gestión de Problemas:

Un aumento de la calidad general de los servicios TI.

Se minimiza el número de incidentes.

Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TIahorrando recursos e innecesarios escalados.

La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad,Disponibilidad y Niveles de Servicio.

Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en:

Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin éstala Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida soluciónde los incidentes y la Gestión de Problemas carecerá de la información necesaria paradeterminar, clasificar y resolver los problemas.

Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los

agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables dela infraestructura TI.

Aumento de los costes por la contratación de personal especializado, aunque estos se veansobradamente compensados por los beneficios derivados.


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 mediante RFCs queson enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de losmismos 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 queayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidaddel 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 otrosprocesos TI




Proceso - Control de Problemas

El principal objetivo del Control de Problemas es conseguir que estos se conviertan en ErroresConocidos 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 fuentesde 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 unproblema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en laestructura 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 deCapacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en queaspectos 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 laexistencia de problemas subyacentes que no se hayan manifestado de forma explicita comoincidentes.

Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificarproblemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioroen el servicio TI.

El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no enlos 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.

2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste, tales como si es unproblema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferenteselementos 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 losincidentes, 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 delproblema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente suimpacto.

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 yasí minimizar su impacto en la infraestructura TI.

3. 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 delproblema 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. Esmoneda 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 aplicacionesutilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso deaplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidosaplicables al problema en cuestión.

Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite alControl de Errores para su posterior procesamiento.




Proceso - Control de Errores

Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad delControl 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 llevarasociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impactode 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 delservicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión deCambios.

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 lainfraestructura 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 serviciosaceptable?

¿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 dedatos 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 infraestructurapropuestos.

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 laimplementació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 esteproblema se considera concluido el proceso y se emiten los informes correspondientes.


Control del Proceso

El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de lainfraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de losprocesos 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 manifiesteno 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 Problemas y aportainformació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 erroresresueltos, 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 lasestructuras TI a las necesidades de la empresa.

Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad delservicio de los productos y servicios contratados y que eventualmente puedan permitir adoptardecisiones informadas sobre cambios de proveedores, etc.

Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsablesde cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso lasresponsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unosrecursos humanos desproporcionados al proceso de identificación y solución de problemas.




Caso Práctico

El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la queno 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 casosigue 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 ciertospedidos, 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 laaplicación.

Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión deIncidentes:

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 seregistra 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 considereoportuno implementar la RFC.

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_incidentes/caso_practico_gestion_de_incidentes/caso_practico_gestion_de_incidentes.php






Gestión de Configuraciones

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 adecuadonivel 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 degestión.

Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera queestas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de losproblemas, realizar los cambios necesarios para su resolución y mantener actualizada en todomomento la CMDB.

Monitorizar periódicamente la configuración de los sistemas en el entorno de producción ycontrastarla 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:





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 mayorprovecho de la misma. La principal tarea de la Gestión de Configuraciones es llevar un registroactualizado 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 queconfiguran la infraestructura TI.

Mantener actualizada la Base de Datos de Configuraciones:

Registro actualizado de todos los CIs : identificación, tipo, ubicación, estado,...

Interrelación entre los CIs.

Servicios que ofrecen los diferentes CIs.

Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidentes, Problemas yCambios.

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. Unafuente habitual de problemas es la incompatibilidad entre diferentes CIs, drivers desactualizados,etc. La detección de estos errores sin una CMDB actualizada alarga considerablemente el ciclo devida de un problema.

Una Gestión de Cambios más eficiente. Es imprescindible conocer la estructura previa paradiseñ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 losrequisitos legales que pueden repercutir negativamente en la organización.

Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectarvulnerabilidades en la infraestructura.

Mayor rapidez en la restauración del servicio. Si se conocen todos los elementos deconfiguración y sus interrelaciones será mucho más sencillo recuperar la configuración deproducció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 necesariaspara evitar duplicaciones o incorrecciones.

Estructura inadecuada de la CMDB: mantener actualizada una base de datos de configuracionesexcesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiadosrecursos.

Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar losprocesos 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 correctomantenimiento de la CMDB.



Falta de organización: es importante que haya una correcta asignación de recursos yresponsabilidades. Es preferible, cuando sea posible, que la Gestión de Configuraciones seallevada a cabo por personal independiente y especializado.

Falta de compromiso: los beneficios de la Gestión de Configuraciones no son inmediatos y soncasi siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa yconsecuentemente de los agentes implicados.


Definiciones

A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos deconfiguración (CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente quenos 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 suscomponentes: 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 globalde la infraestructura TI de la organización.


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 ynomenclatura predefinidos.

Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizadosesté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 laconfiguració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 aportarinformació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 otrosprocesos TI.




Planificación

La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones einterdependencias 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 consideramosesenciales:

Designar un responsable: una descentralización excesiva puede generar descoordinación y llevaral traste todo el proceso.

Invertir en alguna herramienta de software adecuada a las actividades requeridas: unaorganización manual es impracticable.

Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.

Establecer claramente:El alcance y objetivos.

El nivel de detalle

El proceso de implementación: orden de importancia, cronograma, ...

Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y losDepartamentos de Compras y Suministros

Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa conlas graves consecuencias que esto supondrá para el resto de los procesos.




Clasificación y Registro

La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevaresta labor con éxito, predeterminar la estructura del CMDB de manera que:

Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo ala 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íticospara 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 servicioscríticos.

Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Porejemplo, 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 enexceso 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 profundidaddeseados:

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 losCIs 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 debeir 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 paradocumentación y software.


Monitorización

Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Estainformació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 representacionesvisuales 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:




Control

La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisicionesde componentes para mantener actualizada la CMDB.

El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debemantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estarcorrectamente 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.


Auditorías

El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con laconfiguració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 deconfiguración de hardware y software. La información recopilada puede ser utilizada para actualizar laCMDB.

Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesariocomplementar 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 oincompleta.

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.


Control del Proceso

Una correcta Gestión de Configuraciones necesita la colaboración de toda la estructura TI para manteneractualizada la información almacenada en la CMDB.

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión deConfiguraciones, tanto para conocer la estructura y adecuación de la CMDB como para aportarinformación de vital importancia a otras áreas de la infraestructura TI.


Alcance y nivel de detalle de la CMDB.

Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias deconfiguració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 éxitoy é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.


Caso Práctico

La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una "grandevoradora de recursos" si se establecen criterios excesivamente ambiciosos. Por ello la dirección de "CaterMatters" ha decidido, en una primera fase, limitar el alcance de la base de datos de configuraciones a lossistemas 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 sinnecesidad de realizar un esfuerzo desmedido por lo que se han registrado:

Configuraciones de software:

Sistemas operativos.

Aplicaciones instaladas.

Interdependencias: relaciones padre-hijo, propietarios,...

Documentación asociada.

Configuraciones de hardware:

Servidores y estaciones de trabajo.

Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,...

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 esasconfiguraciones y la realización de auditorías periódicas automatizadas.



Gestión de Cambios

Visión General

Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, yaunque esto no sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamentede 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 nuevosproblemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar muchomá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 procedimientosestablecidos 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 siguienteinteractivo:



Gestión de Cambios


El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todoslos cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientosestá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 incorrectofuncionamiento 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 cambiotenga 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 elretorno real a la inversión.

La CMDB está correctamente actualizada, algo imprescindible para la correcta gestión del resto deprocesos TI.

Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemasno críticos.



La implementación de una adecuada política de gestión de cambios también se encuentra con algunas seriasdificultades:

Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo enlo que respecta al cambio, independientemente de que este se realice para solucionar unproblema, 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 suactividad.

Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar ydocumentar adecuadamente el proceso.

No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesosasociados.

Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario elproceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad delservicio.

Gestión de Cambios

Conceptos básicos

En el resto de este capítulo se utilizará con frecuencia el concepto de Gestor de Cambios y ConsejoAsesor del Cambio (CAB), por lo que resulta conveniente describir y diferenciar sus respectivasatribuciones:

Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el últimoresponsable de todas las tareas asignadas a la Gestión de Cambios. En grandes organizacionesel Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de lasdiferentes áreas.

Consejo Asesor de Cambios (CAB): es un órgano interno, presidido por el Gestor 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:

Consultores externos.

Representantes de los colectivos de usuarios.

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 esa 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: todoslos 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 medidasimplificadora 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), esimportante crear procesos de cambio cuyos protocolos están previamente definidos y autorizados para, porejemplo, 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 permitenuna gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.



Gestión de Cambios

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


Gestión de Cambios

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 delos casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe serregistrado con información del error conocido asociado para que posteriormente pueda serevaluada correctamente la pertinencia del proceso.

Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de lainfraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones deCapacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen lasexpectativas 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 quepor regla general requieren de cambios de hardware, software y/o procedimientos.

Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versionesanteriores de paquetes de software o introducir nuevas versiones con grandes mejoras querecomienden la actualización.

Imperativo legal: un cambio de legislación (como, por ejemplo, la LOPD) puede exigir cambios enla infraestructura TI.

Otro: en principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los serviciosque pueden requerir cambios en la infraestructura.

No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repitenperiódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de la Gestión deCambios en cada caso.

Independientemente de su origen el correcto registro inicial de una RFC requerirá, cuando menos, de lossiguientes datos:

Fecha de recepción.

Identificador único de la RFC.

Identificador del error conocido asociado (dado el caso).

Descripción del cambio propuesto:

Motivación.

Propósito.

CIs involucrados.

Estimación de recursos necesarios para la implementación.

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

Gestión de CambiosAceptación y Clasificación

Aceptación

Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplementerechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si seconsidera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. En cualquierade los casos la RFC debe ser devuelta al departamento o persona que la solicito con el objetivo de que sepuedan realizar nuevas alegaciones a favor de dicha RFC o para que pueda ser consecuentementemodificada.

La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se haencontrada 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 elimpacto de la misma.

La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será eldato 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 laasignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para laimplementación del cambio.

Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar unaclasificación que incluyera, al menos, los siguientes niveles de prioridad:

Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidanactualizar 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 cambiode más alta prioridad.

Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos quedeterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en supró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 deteriorograve del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambiode 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 suimplementació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 yrequieran 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 personalespecializado para realizar tareas de asesoramiento.

Gestión de Cambios

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 lassofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puededesencadenar 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 estableantes del cambio. Pero esto obviamente no es suficiente.

En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs 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 puedenentrar 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 noaceptación) debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete decambios" 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.

Gestión de Cambios

Implementación

Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encargahabitualmente 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 especificacionespredeterminadas.

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 unavaloració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 seencuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio porparte de cierto tipo de usuarios).

Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de laGestió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 sercompartida por usuarios y clientes.

Gestión de Cambios

Evaluación

Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente elimpacto 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 cierrede la RFC y toda la información se incluirá en la PIR asociada.

Gestión de Cambios

Cambios de Emergencia

Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de unaplanificació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 sehan visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuestainmediata. 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 establecerprotocolos 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 éstesucede 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 procesosasociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociadaal cambio se realicen a posteriori.

Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de laque dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambiosfuturos incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidenciasy problemas.

Gestión de Cambios

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 elaborarmé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 Cambios

Caso Práctico

Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de laempresa 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 estabadiseñado para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestiónde la Capacidad han informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue conel 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 Internety 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 derespuesta.

Desarrollar una serie de WebServices que permitan:



Integrar directamente el sistema de pedidos online en el ERP de la empresa.

Realizar un seguimiento de todo el proceso de pedido.

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

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 elproceso de implementación del sistema actual.

Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con lasGestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como conla 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 posiblescambios.

Sopesando la documentación aportada y la estrategia de negocio de la organización el CAB aprueba elcambio 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 lacontinuidad del servicio:

Duplicación de toda la estructura web: se compraran nuevos servidores para que los

antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente parael "back-out".

Se desarrollarán aplicaciones de "traducción" que permitan mantener actualizadas las basesde 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 unaauditoria externa de todo el proceso.

Elabora toda la información necesaria para que la Gestión de Versiones comience todo el procesode 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:El nuevo sistema dispone de la capacidad suficiente para proporcionar los niveles de servicioy disponibilidad previstos.

El nuevo sistema funciona sin errores aparentes.

Los clientes y proveedores han percibido el cambio como una mejora en la prestación deservicios.

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.

Gestión de VersionesVisión General

La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software yhardware instalado en el entorno de producción.

La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y deConfiguraciones para asegurar que toda la información relativa a las nuevas versiones se integraadecuadamente en la CMDB de forma que ésta se halle correctamente actualizada y ofrezca una imagenreal 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 dehardware en el entorno de producción.

Las interacciones y funcionalidades de la Gestión de Versiones se resumen sucintamente en el siguienteinteractivo:



Gestión de Versiones


Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten entarea 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íficade la Gestión de Versiones el diseñar, poner a prueba e instalar en el entorno de producción los cambiospreestablecidos.

Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a laGestió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 suverificación en un entorno realista de pruebas.

Garantizar que el proceso de cambio cumpla las especificaciones de la RFC correspondiente.

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 ainstalar sino que también permite conocer la opinión de los usuarios sobre la funcionalidad yusabilidad 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 figuradominante 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 lasnuevas versiones de software y hardware.

Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. Eshabitual que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobretodo 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óloson 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 puedenelegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse avolver 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 laorganización TI de las ventajas de una correcta gestión de todo el proceso de cambio.


Conceptos básicos

Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalaciónen el entorno de producción. Las especificaciones funcionales y técnicas de una versión están determinadasen 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 queintroducen 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 correctamentedocumentada 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 losidentifique 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 desu navegador).

En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo, pruebas, producción yarchivado.

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 laGestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habitualescabe contar:

Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene comoventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas eincompatibilidades 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 incidentestras la instalación si se han realizado las pruebas pertinentes.

Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizadadiferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI. Enalgunos casos esta opción es obligada por incompatibilidades entre una nueva versión consoftware o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevosistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programasofimáticos.

DSL

La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el entornoTI. Esto incluye no solo sistemas operativos y aplicaciones sino también controladores de dispositivos ydocumentación asociada.

La DSL debe contener el histórico completo de versiones de un mismo software para proporcionar la versiónnecesaria 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 deproducción.

Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes sehallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).


Proceso

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 deproducció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:





Planificación

Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología detrabajo. Esto es especialmente importante para los casos de versiones menores y de emergencia pues en elcaso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta laspeculiaridades de cada caso.

A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta lossiguientes 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 deproducció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 impactonegativo 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 lanueva 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énpuntualmente 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 losemplazamientos, 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 lanueva versión.


Desarrollo

La Gestión de Versiones es la encargada del diseño y construcción de las nuevas versiones siguiendo laspautas marcadas en las RFCs correspondientes.

A veces el desarrollo se realizara "en la casa" y muchas otras requerirá la participación de proveedoresexternos. En este segundo caso, la tarea de la Gestión de Versiones será la de asegurar que el paquete opaquetes de software o hardware ofrecidos cumple las especificaciones detalladas en la RFC. Asimismo, laGestió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 deinstalación necesarios para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos talescomo:

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 encuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.


Validación

Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producciónuna 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éndeben realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple losrequisitos establecidos y es razonablemente usable (siempre existe una inevitable resistencia al cambio enlos 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 suinstalación. Si la versión no fuera aceptada se devolverá a la Gestión de Cambios para su reevaluación.


Implementació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 losemplazamientos.

Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versiónpor grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.

El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sustareas y responsabilidades específicas. En particular los usuarios finales deben estar puntualmenteinformados 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 localizacionesgeográficas.

Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben sercompletos 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 laformació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 el Service Desk de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda estainformación deberá ser analizada para asegurar que las próximas versiones incorporen las sugerenciasrecibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedantener futuros cambios.


Comunicació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 elfactor humano.

Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar eleslabó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 seencuentran 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 conanterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver paraparticipar, a su discreción, en el proceso.

Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupode usuarios finales. Durante este proceso de prueba se documentarán y analizarán:

La experiencia subjetiva de usuario.

Los comentarios y sugerencias sobre usabilidad y funcionalidad. o Las dudas que hayansurgido durante el uso de la nueva versión.

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 ypuedan solicitar ayuda o soporte técnico en el uso de la nueva versión.


Control 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 elaborarmé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 delos usuarios.

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.


Caso Práctico

La Gestión de Cambios ha aprobado (véase el caso práctico del capítulo anterior) un RFC que tiene comoprincipales objetivos:

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_cambios/caso_practico_gestion_de_cambios/caso_practico_gestion_de_cambios.php






Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad derespuesta.

Desarrollar una serie de WebServices que permitan:

Integrar directamente el sistema de pedidos online en el ERP de la empresa.

Realizar un seguimiento de todo el proceso de pedido.

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 lasnuevas versiones de hardware y software asociadas. Para ello:

En colaboración con las Gestiones de Capacidad y Disponibilidad evalúa las necesidades delnuevo hardware y se encarga de su compra y configuración.

Contacta con sus proveedores habituales de desarrollo web para establecer de forma precisa lasespecificaciones del nuevo software y establecer un calendario de desarrollo.

Duplica la estructura web: se compran nuevos servidores para que los antiguos puedan prestarservicio 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 elERP de la empresa.

II. Se completa el proceso con la integración mediante WebServices de los pedidos web en elERP.

Se desarrolla un manual de usuario para la nueva versión y se crea una página FAQs en la web queincluyen 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 delservicio 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.

Gestión de Niveles de Servicio

Visió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 unmedio 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 conprocesos 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 elsiguiente interactivo:



La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidadde los servicios TI ofrecidos.

La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidadesy expectativas del cliente y los costes de los servicios asociados, de forma que estos sean asumibles tantopor 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 susnecesidades.

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 costeaceptable 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 delcliente.

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

Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos deactuació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 conproveedores 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 SLAs acordados norecogen sus necesidades reales.

Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que enservicios 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 nocomo parte integral del servicio ofrecido.

Problemas de comunicación: no todos los usuarios conocen las características del servicio y losniveles de calidad acordados.

No se monitoriza adecuada y consistentemente el cumplimiento de los SLAs dificultando así lamejora de la calidad del servicio.



No existe en la organización un verdadero compromiso con la calidad del servicio TI ofrecido.


Conceptos 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óncon el cliente sino que también puede ser una gran ayuda tanto a la organización interna como a laproyecció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 noespecializado.

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 derendimiento 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 yprecisan 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, sirviendode documento de base para la elaboración de los OLAs y UCs correspondientes.

Programa de Calidad del Servicio (SQP)

El SQP debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles decalidad 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 losprocesos y procedimientos involucrados en el suministro de los servicios prestados, asegurando que estos sealineen 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 losdetalles de los servicios brindados.

Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo loque respecta a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramentedefinidos 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 ycompromisos de los diferentes departamentos de la organización TI en la prestación de un determinadoservicio.

Contratos de Soporte (UC)

Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propiaorganización TI.



Programa de Mejora del Servicio (SIP)

El SIP debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio comopropuestas 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 estarinternamente a disposición de los gestores de los otros procesos TI.


Proceso

Las principales actividades de la Gestión de Niveles de Servicio se resumen en:

Planificación:

Asignación de recursos.

Elaboración de un catálogo de servicios.

Desarrollo de SLAs tipo.

Herramientas para la monitorización de la calidad del servicio.

Análisis e identificación de las necesidades del cliente.Elaboración del los Requisitos de Nivel de servicio(SLR ), Hojas de Especificación del Servicioy Plan de Calidad del Servicio(SQP).

Implementación de los Acuerdos de Nivel del Servicio:

Negociación.

Acuerdos de Nivel de Operación.

Contratos de Soporte.

Supervisión y revisión de los Acuerdos de Nivel de Servicio:

Elaboración de informes de rendimiento.

Control de los proveedores externos.

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 otrosprocesos 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ácticamentetodos los estamentos de la organización TI. Y, si esto no fuera ya de por sí una labor lo suficientementecompleja, 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 delos servicios TI ofrecidos. Si los servicios no se adecuan a las necesidades del cliente, la calidad de losmismos es deficiente o sus costes son desproporcionados, tendremos clientes insatisfechos y la organizaciónTI 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 decalidad acordados?



La respuesta a cada una de estas preguntas debe darse en forma de documentos, algunos de carácterinterno 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, peroen 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 yservicios 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 alinearaspectos 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, lacomplejidad 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 permitadeterminar "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á elservicio.

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 exigenciasté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 serviciosprestados y contener información detallada sobre todos los procesos TI involucrados en la prestación de losservicios.

En función de los requisitos plasmados en las Hojas de Especificación del Servicio se elabora un plan globalque permita asignar los recursos a la organización TI, establecer metas claras basadas en los indicadores derendimiento elegidos y asegurar que los niveles de calidad ofrecidos se adaptan a las necesidades de losclientes y a los compromisos asumidos por la organización.

En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportunoexternalizar parte de los servicios el SQP servirá de documento guía para el establecimiento de los contratoscon los proveedores externos.




Implementació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 y Contratos deSoporte.

Acuerdos de Nivel de Servicio

Los SLAs deben contener una descripción del servicio que abarque desde los aspectos más generales hastalos detalles más específicos del servicio.

Es conveniente estructurar los SLAs más complejos en diversos documentos de forma que cada grupoinvolucrado reciba exclusivamente la información correspondiente al nivel en que se integra, ya sea en ellado 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 yprocedimiento 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 elcliente 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 procesode prestación de servicios.

Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los Contratos de Soportedeben representar compromisos claros y perfectamente delimitados. A pesar de esta diferencia crucial, losUCs pueden considerarse como una extensión "externa" de los OLAs en el sentido de que persiguen elmismo fin: organizar los procesos y procedimientos necesarios para la correcta provisión del servicio.


Monitorización

El proceso de monitorización de los niveles de servicio es imprescindible si queremos mejorarprogresivamente 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ámetrosinternos 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 unosbaremos de calidad del servicio que han de servir de guía en la elaboración de los informescorrespondientes.



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 derecuperació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 alos 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 incidentesresponsables 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.


Revisión

La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de lacalidad de los servicios ofrecidos.

Esta revisión debe realizarse en base a parámetros objetivos y metrizables resultado de la experienciaprevia, 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 yhomogeneizar la calidad del servicio.

El resultado de la revisión debe ser un Programa de Mejora del Servicio (SIP) que tome en cuenta factorestales 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 undocumento de referencia para la gestión de otros procesos TI como la Gestión de Cambios, Gestión deProblemas, 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 lasatisfacción del cliente pero esto no se puede llevar a cabo sin una buena gestión de los procesosinvolucrados.

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 yexperiencia necesarios.

Una asignación clara de tareas y responsabilidades.

Indicadores específicos de rendimiento tales como:

Porcentaje de servicios amparados bajo SLAs.

Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la calidad delservicio.

SIPs elaborados e impacto de los mismos en la calidad del servicio.

Encuestas de satisfacción del cliente.

La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión deNiveles de Servicio y aporta información de vital importancia a otras áreas involucradas en el soporte y laprovisión de los servicios TI.


Informes Estadísticos de Rendimiento: donde se detallen los SLAs, OLAs y UCs elaborados yel nivel de cumplimiento de los mismos, costes promedio asociados al proceso, etc.

Informes de Seguimiento: donde se especifiquen las acciones de monitorización realizadas, susresultados 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 yel impacto que estas han tenido en la calidad del servicio.


Caso Práctico

La dirección de "Cater Matters" ha decidido implementar una Gestión de Niveles de Servicio que 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 accionesiniciales 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 clientesasumir 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 servicioscon 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 losservicios 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 quecontratan 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 unaestimació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óndel 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 lacorrecta 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 tediosase 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.



Gestión Financiera de los Servicios TI

Visión General

Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamentetodos sus procesos de negocio es moneda corriente que no exista una conciencia real de los costes que estatecnologí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 losservicios TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursosTI necesarios.

Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios no podránevaluar 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:





La Gestión Financiera de los Servicios Informáticos tiene como objetivo principal administrar demanera 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 evaluarcuidadosamente 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 yfijació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áticos se resumenen:

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 aumentandola 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 losservicios TI.

Los servicios TI son usados más eficazmente.

La organización TI funciona como una unidad de negocio y es posible evaluar claramente surendimiento global.

Las principales dificultades a la hora de implementar la Gestión Financiera de los ServiciosInformáticos se resumen en:



Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectosfinancieros 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.


Conceptos 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 oservicio, 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 propiaplataforma general de comunicaciones. Estos costes son más difíciles de determinar y por logeneral 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 congastos 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 largoplazo.

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

Los tipos de coste se subdividen a su vez en elementos de coste. El siguiente diagrama nos muestra unatí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 otrosdepartamentos de la empresa o institución.


Proceso

Las principales actividades de la Gestión Financiera se resumen se resumen en:

Presupuestos:

Análisis de la situación financiera.

Fijación de políticas financieras.

Elaboración de presupuestos.



Contabilidad:

Identificación de los costes.

Definición de elementos de coste.

Monitorización de los costes.

Fijación de precios:

Elaboración de una política de fijación de precios.Establecimiento de tarifas por los servicios prestados o productos ofrecidos.



Presupuestos

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 laevolució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 decrecimiento en el periodo presupuestado.

Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI esnecesario 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 menudoinfluyen factores externos que no se hallan bajo el control directo de la organización TI, como por ejemplo elaumento del precio de las licencias del software, etc.

Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos alrespecto para evitar que se conviertan en papel mojado al menor vaivén del mercado.


Contabilidad

En principio, la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada aotros servicios o departamentos. Sin embargo, la complejidad de las interrelaciones TI dificulta el procesocuando los responsables de su contabilidad desconocen sus mecanismos básicos y la tecnología que lossustenta.

Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance un excesivo nivelde 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 detalletanto sus costes como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues elcliente es la propia organización).

Es una de las actividades principales de la Gestión Financiera identificar los denominados elementos de coste que se pueden clasificar de forma genérica en:

costes de hardware y software,

costes de Personal,

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_financiera/introduccion_objetivos_gestion_financiera/conceptos_basicos_gestion_financiera.php






costes generales,

asignando a cada servicio/cliente su parte proporcional.


Polí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 tantoconocer los costes reales de los servicios prestados como establecer una política de precios que, cuandomenos, 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 debeneficios (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 enfunció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 seutilizarán de referencia para evaluar el rendimiento teórico de la organización TI.


Supervisió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 losaspectos 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 ambosprocesos.

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 asu vez satisfactorios para el cliente.


Control del Proceso

El responsable de el proceso de Gestión Financiera no ha de ser de manera imprescindible un miembro dela organización TI, es, sin embrago, imprescindible que disponga de ciertos conocimiento sobre los serviciosTI 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 denegocio?

¿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 deFinanciera según los parámetros arriba descritos y aporta información de vital importancia a la organizaciónen su conjunto.


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.




Caso Práctico

La organización TI de "Cater Matters" lleva prestando, desde hace años, servicios esenciales tanto a lapropia 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 maneraespecífica y es, con los datos disponibles en la actualidad, imposible conocer el impacto de los servicios TIen 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 lepermita trasladar sus costes al usuario final del servicio de catering,en la misma medida que ya se hace conlos costes de transporte, materias primas, etc.

Para gestionar el proceso se ha nombrado a un senior manager del departamento TI y a un miembro deldepartamento 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 queintervienen en la prestación de servicios directos a los clientes.

Evaluar, prorrateando entre los diferentes servicios si esto fuera necesario, cuales son los costesasociados 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 prestadosy proponer tarifas que sean trasladas a los clientes, ya sea directamente o incluidas en otras partidas decará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.



Gestión de la Capacidad

Visión General

La Gestión de la Capacidad es la encargada de que todos los servicios TI se vean respaldados por unacapacidad de proceso y almacenamiento suficiente y correctamente dimensionada.

Sin una correcta Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizaninversiones 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.





El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes, usuarios y elpropio departamento TI los recursos informáticos necesarios para desempeñar de una manera eficiente sustareas 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 ynecesidades 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 entecnologías que no están adecuadas a las necesidades reales del negocio o están sobredimensionadas, o porel contrario, evitar situaciones en las que la productividad se ve mermada por un insuficiente o deficienteuso 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 adquierenpero que obvian aplicaciones, equipos y servicios que realmente aumentarían la productividad en susrespectivos 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, demodestos desembolsos, debido a la reducción de costes en los equipos de hardware y aplicacionesinformáticas, la administración y mantenimiento de infraestructuras desproporcionadas puede resultar, a lalarga, 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 resentirla 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 aplicacionesobsoletos 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 consiguientereducció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 conalgunas 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 uncorrecto acceso a los datos.

No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesosasociados.

La rápida evolución de las tecnologías puede obligar a una revisión permanente de los planes yescenarios contemplados.

Un correcto dimensionamiento de la propia Gestión de la Capacidad: un excesivo celo puedeprovocar costosos análisis de capacidad que podrían haber sido innecesarios con la compra denuevo hardware o software.


Proceso

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 necesidadesde 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 sustendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizaneficazmente.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de la Capacidad:



Planificació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 necesidadesemergentes de usuarios y cliente.

El Plan de Capacidad debe incluir información sobre los costes de la capacidad actual y prevista. Estainformación es indispensable para que la Gestión Financiera pueda elaborar los presupuestos y previsionesfinancieras de manera realista.

Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o bianual es importante que semonitorice su cumplimiento para adoptar medidas correctivas en cuanto se detecten desviacionesimportantes del mismo.

Modelado y Benchmarking

Cuanto más compleja sea una infraestructura informática más difícil es prever las necesidades de capacidadfutura. En esos casos, es imprescindible realizar modelos y simulaciones sobre posibles escenarios dedesarrollo 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 lainfraestructura informática y escalar consecuentemente su capacidad actual.

Realizar modelos y simulaciones sobre diferentes escenarios para llevar a cabo previsiones de cargay repuesta de la infraestructura informática.

Realizar benchmarks con prototipos reales para asegurar la capacidad y el rendimiento de la futurainfraestructura.


Recursos

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 fiablesobre:

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 unproducto, servicio o definición de un SLA para asegurar que se dispondrá de la capacidad necesaria parallevar el proyecto a buen término.

Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicacióndebido a expectativas injustificadas sobre la tecnología. Se puede caer en el equivoco de que los costesasociados 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 yadministración, o ignorando los problemas que pueden conllevar dichos cambios.


Supervisión del Proceso

La Gestión de la Capacidad es un proceso continuo e iterativo que monitoriza, analiza y evalúa elrendimiento y capacidad de la infraestructura TI y con los datos obtenidos optimiza los servicios o eleva unaRFC a la Gestión de Cambios.

Tanto la información obtenida en estas actividades como la generada a partir de ella por la Gestión de laCapacidad 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 losrequisitos de los SLAs.

La monitorización debe incluir, además de aspectos técnicos todos aquellos relativos a licencias y otrosaspectos de carácter administrativo.

Análisis y Evaluación



Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas talescomo 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 paraque 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 yVersiones 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 posiblesdeficiencias o incumplimientos de los SLAs será la propia Gestión de la Capacidad la responsable degestionar 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 laGestió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 imagenintegral de los sistemas y aplicaciones con información relativa a su capacidad. Esto no es óbice para queambas bases de datos puedan ser "físicamente independientes".


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 laCapacidad é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 quelos servicios críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar acabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca lasprioridades 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 dela capacidad siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorizaciónde la capacidad permite reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si esposible una redistribución a largo plazo de la carga de trabajo que permita dar un servicio de calidad sinaumento de la capacidad.

Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por laorganización se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicosasociados 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 dehoras punta sin degradar la calidad del servicio, ahorrando a la organización una gravosa ampliación delancho de banda.

Ahora bien, si el coste añadido por aumentar el ancho de banda es marginal, puede resultar más eficiente sucontratación directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en laoptimización del sistema.

La Gestión de la Capacidad debe evaluar a priori, basandose en la experiencia y las tendencias delmercado, cuándo la solución "más potente, más grande" es económicamente más rentable (teniendo encuenta los costes indirectos) que un análisis pormenorizado de la situación.




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


Caso Práctico

Hasta la fecha, la Gestión de las Capacidad de "Cater Matters" había sido reactiva, o en otras palabras elincremento 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" comopara sus clientes, la dirección de la empresa ha decidido implementar las mejores prácticas ITIL para laGestió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 serviciosonline, 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 lacapacidad 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 realesextraí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 ala 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.

Gestión de la Continuidad del Servicio

Visión General

La Gestión de la Continuidad del Servicio se preocupa de impedir que una imprevista y graveinterrupción de los servicios TI, debido a desastres naturales u otras fuerzas de causa mayor, tengaconsecuencias catastróficas para el negocio.

La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamenteprocedimientos:

Proactivos: que buscan impedir o minimizar las consecuencias de una grave interrupción delservicio.

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 percibena largo plazo, es costosa y carece de rentabilidad directa. Implementar la ITSCM es como contratar unseguro médico: cuesta dinero, parece inútil mientras uno está sano y desearíamos nunca tener queutilizarlo, pero tarde o temprano nos alegramos de haber sido previsores.





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 perniciosasconsecuencias 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 serviciosTI son preferibles a las exclusivamente reactivas, es importante valorar los costes relativos y la incidenciareal 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) ydebe estar a su servicio. Los servicios TI no son sino una parte, aunque a menudo muy importante, delnegocio en su conjunto y no tiene mayor sentido que, por ejemplo, un sistema de pedidos online sigafuncionando a la perfección tras un desastre si nos resulta imposible suministrar la mercancía a nuestrosclientes.

Es importante diferenciar entre desastres "de toda la vida", tales como incendios, inundaciones, etcétera, ydesastres "puramente informáticos", tales como los producidos por ataques distribuidos de denegación deservicio (DDOS), virus informáticos, etcétera. Aunque es responsabilidad de la ITSCM prever los riesgosasociados 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 aactitudes negligentes, aunque esto no sea siempre cierto.

http://www.osiatis.es/seguridad_informatica/index.php?/archives/4_Ataques_DoS_y_DDoS.html








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 Servicio seresumen 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 yactividades correspondientes se demoran perpetuamente para hacer frente a "actividades másurgentes".

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.


Proceso

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.





Política y Alcance

El primer paso necesario para desarrollar una Gestión de la Continuidad del Servicio coherente esestablecer 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 laimplantación de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a lainversió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 derecursos suficientes, tanto en el plano humano como de equipamiento (software y hardware). Su dimensióndepende de su alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa queno dispusiera de los recursos correspondientes.



Una importante parte del esfuerzo debe destinarse a la formación del personal. Éste debe interiorizar supapel en momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergenciano es el mejor momento para estudiar documentación y manuales.


Análisis de Impacto

Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar determinar el impacto queuna 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 losservicios informáticos, por lo que cabe esperar que un "apagón" de los servicios TI afecte a prácticamentetodos los aspectos del negocio. Sin embargo, es evidente que hay servicios TI estratégicos de cuyacontinuidad puede depender la supervivencia del negocio y otros que "simplemente" aumentan laproductividad 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 elesfuerzo realizado en actividades de prevención. En aquellos casos en que la "solución puede esperar" sepuede 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:

Pérdida de rentabilidad.

Pérdida de cuota de mercado.

Mala imagen de marca.

Otros efectos secundarios.

Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos denegocio.

Compromisos adquiridos a través de los SLAs.

Dependiendo de estos factores se buscará un balance entre las actividades de prevención y recuperaciónteniendo en cuenta sus respectivos costes financieros.


Evaluación de Riesgos

Sin conocer cuales son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar unapolí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 eimpacto, 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 yestraté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 puedenresultar 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 lalocalización geográfica se puede optar por deslocalizar ciertos servicios TI a través de ISPs que dispongande sistemas de generadores redundantes o adquirir generadores que proporcionen la energía mínimanecesaria para alimentar los CIs de los que dependen los servicios más críticos, etcétera.


Estrategias

La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas, que eviten lainterrupción de los servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio en elmenor tiempo posible.

Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención yrecuperació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 deellos serán de carácter general: incendios, desastres naturales, etcétera, mientras que otros tendrán uncarácter estrictamente informático: fallo de sistemas de almacenamiento, ataques de hackers, virusinformáticos, etcétera.

La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con laGestió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 laITSCM. 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 lainfraestructura TI. Aunque imprescindibles no se hallan exentos de sus propias dificultades pues aumentanla 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á necesarioponer 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 derecuperación estiman que la organización puede mantener sus niveles de servicio durante esteperiodo sin el apoyo de la infraestructura TI.

"Warm standby": que requiere un emplazamiento alternativo con sistemas activos diseñados pararecuperar 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 datosy con todos los sistemas activos preparados para la inmediata sustitución de la estructura deproducción. Ésta es evidentemente la opción mas costosa y debe emplearse sólo en el caso deque 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 vuelvannaturalmente a su cauce: una alternativa poco recomendable para alguien que esté hojeando este cursosobre ITIL y del que suponemos que los servicios TI jugarán un papel importante en su organización :-)


Organización y Planificación

Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidas unasestrategias de prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con eseobjetivo la Gestión de la Continuidad del Servicio debe elaborar una serie de documentos entre los quese 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ásdañinas que las provocadas por el incidente que las causo. Por ello es imprescindible que en caso desituació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 derecuperació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 derecuperació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ónpuede 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 anuestros clientes la solidez de nuestra organización TI y por tanto incrementar la confianza que tienedepositada en nosotros. Ya conocen el dicho: "No hay mal que por bien no venga".


Supervisión

Una vez establecidas las políticas, estrategias y planes de prevención y recuperación es indispensable queestos 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 eventualmentedeben 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 lacapacitación del personal involucrado.

Facilite el acceso permanente a toda la información necesaria, por ejemplo, a través de la Intranet oportal B2E de la empresa.

Actualización y auditorías

Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar queresponden 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ónde 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 deactualizació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ónestén actualizados manteniendo informada a la ITSCM de los cambios realizados o previstos.


Control del Proceso

La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión queincluyan 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 yrecuperació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 hanimpedido la existencia de graves interrupciones del servicio se puede caer en un relajamiento que puedeacarrear graves consecuencias.

Por esto es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial sediluyan y la ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que "undesastre se convierta en una catástrofe".

Pero si el control del proceso es importante en condiciones normales éste se vuelve crítico durante lassituaciones 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.


Caso Práctico

La organización TI de "Cater Matters" carece de una Gestión de la Continuidad del Servicio que merezcaese nombre.

La gestión de "Cater Matters" es consciente de la importancia que tienen en la actualidad los servicios TI entoda 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 productosperecederos, y los servicios online de pedidos son considerados de importancia estratégica por la direcciónde la empresa. Por ello se decide que en primera instancia la ITSCM debe garantizar la continuidad dedichos 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 coordinartodas 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 decatering 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 basesde datos de pedidos a formatos estándar de intercambio de datos para que estos puedan ser procesados porlas otras organizaciones.

Por otro lado, se desarrolla una aplicación de gestión de emergencia de las existencias que permiteadministrar los pedidos a los proveedores y preservar la integridad de las existencias dependiendo de suinformació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 elimpacto de una eventual interrupción del servicio, entre sus obligaciones se encuentran la elaboración deunos 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.



Gestión de la Disponibilidad

Visión General

Nuestras vidas, tanto personales como profesionales, dependen cada vez más de la tecnología. Ésta nospermite acceder a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñadohace unos pocos años.

Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestrosproveedores tecnológicos. Con frecuencia una oferta diferente sólo se encuentra a un par de clics dedistancia.

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 nuestrossistemas 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 estosfuncionen 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 siguienteinteractivo:





El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén disponiblesy funcionen correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de losSLAs 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 dedisponibilidad.

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 resumenen:

Disponibilidad: porcentaje de tiempo sobre el total acordado en que los servicios TI han sidoaccesibles al usuario y han funcionado correctamente.

Fiabilidad: medida del tiempo durante el cual los servicios han funcionado correctamente de formaininterrumpida.

Mantenibilidad: capacidad de mantener el servicio operativo y recuperarlo en caso deinterrupción.

Capacidad de Servicio: determina la disponibilidad de los servicios internos y externoscontratados y su adecuación a los OLAs y UCs en vigor. Cuando un servicio TI es subcontratadoen 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 CIs involucrados, sucorrecto 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.


Proceso

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.





Requisitos de Disponibilidad

Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de los SLAs.

La disponibilidad propuesta debe encontrase en línea tanto con los necesidades reales del negocio como conlas posibilidades de la organización TI.

Aunque en principio todos los clientes estarán de acuerdo con unas elevadas cotas de disponibilidad esimportante hacerles ver que una alta disponibilidad puede generar unos costes injustificados dadas susnecesidades 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 sininterrupciones puede requerir la replicación de sistemas u otras medidas igualmente costosas que no van atener 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, ...).




Planificación

La correcta planificación de la disponibilidad permite establecer unos niveles de disponibilidad adecuadostanto 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 sonnecesarias 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 seractualizada 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 (encaso 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 losnuevos 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 lasactividades necesarias para suministrar un determinado servicio TI. Si éste se diseña sin tener en cuentafuturas necesidades de disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo,incurriendo en costes adicionales innecesarios.


Mantenimiento y Seguridad

Aunque hayamos realizado un correcto diseño de los servicios según el Plan de Disponibilidad y se hayantomado todas las medidas preventivas necesarias, tarde o temprano, nos habremos de enfrentar ainterrupciones del servicio.

En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto indeseadosobre 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 elservicio.

Gestión de las Interrupciones de Mantenimiento



Independientemente de las interrupciones del servicio causadas por incidencias es habitualmente necesariointerrumpir 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 sercuidadosamente planificadas para minimizar su impacto.

En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que ello sea posible, debenaprovecharse 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 susactividades 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 correctaGestió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. Ladisponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente ala otra.


Monitorizació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 pasapor distintas fases que deben ser individualizadamente analizadas:

Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo hasta que laorganización TI tiene constancia del mismo.

Tiempo de respuesta: es el tiempo que transcurre desde la detección del problema hasta que serealiza un registro y diagnóstico del incidente.

Tiempo de reparación/recuperación: periodo de tiempo utilizado para reparar el fallo oencontrar un "workaround" o solución temporal al mismo y devolver el sistema a la situaciónanterior a la interrupción del servicio.



Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida dela interrupción del servicio. El cliente debe conocer estas métricas y dar su conformidad a las mismas paraevitar malentendidos. En algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" yla interpretación puede diferir entre proveedores y clientes, por lo tanto, estás métricas deben de poderexpresarse 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 adisposición del cliente en los informes de disponibilidad correspondientes incluyen:

Tiempo Medio de Parada (Downtime) : que es el tiempo promedio de duración de unainterrupció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 estadisponible sin interrupciones.

Tiempo Medio entre Incidentes: es el tiempo medio transcurrido entre incidentes que es igual ala suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos. El Tiempo Medio entreIncidentes es una medida de la fiabilidad del sistema.


Métodos y Técnicas

Aunque llevamos hablando ya un buen rato de disponibilidad aún no hemos aportado un método paracuantificarla.

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 tareasde 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 lepermiten determinar que factores intervienen en la disponibilidad del servicio y que le permitenconsecuentemente 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 decada elemento de configuración involucrado. Es evidente que este método requiere una CMDB 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 comprendermejor su impacto en la disponibilidad del servicio.

CRAMMQue son las siglas de CCTA R isk Analysis and Management Method (Método de Gestión y Análisis de Riesgosde la CCTA).

Su objetivo es identificar los riesgos y vulnerabilidades a los que se haya expuesta la infraestructura TI conel objetivo de adoptar contramedidas que los reduzcan o que permitan recuperar rápidamente el servicio encaso 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 losmismos.

Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente haciendoespecial énfasis en aspectos no exclusivamente técnicos ligados directamente a la infraestructura TI.


Control del Proceso

La Gestión de la Disponibilidad debe elaborar periódicamente informes sobre su gestión que incluyaninformació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:

Tiempos de detección y respuesta a los fallos.

Tiempos de reparación y recuperación del servicio.

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 losproveedores internos y externos.

Para que toda esta información sea fácil y correctamente analizada es imprescindible el establecimiento demé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 considerarque tiempos de respuesta superiores a 10 segundos son equivalentes a que el sistema esta caído, aunqueestrictamente hablando el sistema termine respondiendo.


Caso 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 laorganización a sus clientes y los problemas de disponibilidad suelen proceder de procesos no directamenteligados con la tecnología. Sin embargo, una interrupción de los servicios online pueden presuponer un graveproblema dado el alto volumen de pedidos que se reciben por dicho canal, la práctica totalidad, así como suimportancia 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 sidoencargada de elaborar nuevos planes de disponibilidad que tengan en cuenta un rápido crecimiento delnegocio 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 delservicio.

Por otro lado, la gestión de "Cater Matters" ha decidido informar periódicamente a sus clientes sobre losniveles de rendimiento y disponibilidad de los diferentes servicios prestados. Para ello ha encargado a laGestió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 sobreel 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 laorganización TI alerta sobre posibles degradaciones de los niveles de calidad del servicio.



Gestión de la Seguridad

Visión General

La Gestión de la Seguridad de la Información se remonta al albor de los tiempos. La criptología o laciencia de la confidencialidad de la información se remonta al inicio de nuestra civilización y ha ocupadoalgunas 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 losproblemas asociados a la seguridad de la información se han agravado considerablemente y nos afectanprácticamente a todos. Que levante la mano el que no haya sido victima de algún virus informático en suordenador, del spam (ya sea por correo electrónico o teléfono) por una deficiente protección de sus datospersonales 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 pilaresfundamentales:

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 siguienteinteractivo:





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" quedesconocen los otros procesos de negocio. Si caemos en la tentación de establecer la seguridad como unaprioridad en sí misma limitaremos las oportunidades de negocio que nos ofrece el flujo de información entrelos 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 laorganización TI para establecer protocolos de seguridad que aseguren que la información esté accesiblecuando 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 debesupervisar que estos se hallen convenientemente plasmados en los SLAs correspondientes 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á expuestala infraestructura TI, y que no necesariamente tienen porque figurar en un SLA, para asegurar, en lamedida 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 quepueden 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 alnegocio.

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


Proceso

La Gestión de la Seguridad esta estrechamente relacionada con prácticamente todos los otros procesos TIy 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 losservicios prestados a los clientes como en los acuerdos de servicio firmados con proveedoresinternos 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 yvulnerabilidades.

Realice periódicamente auditorías de seguridad.





Política de Seguridad

Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a laGestión de la Seguridad. Su complejidad e intricadas interrelaciones necesitan de una política global claraen 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 delos SLAs, OLAs y UCs.

Este plan ha de ser desarrollado en colaboración con la Gestión de Niveles de Servicio que es laresponsable en última instancia tanto de la calidad del servicio prestado a los clientes como la del serviciorecibido 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 comoun 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 deseguridad acordados.

Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes entodas 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 deacceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañara algún cliente durante algún tiempo ofreciendo la imagen de "fortaleza" pero esto valdrá de poco si alguiendescubre que la "puerta de atrás está abierta".


Aplicació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 ponenen práctica.

Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas deseguridad 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 responsabilidadesal respecto.

Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo yresponsabilidad.

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 deincidentes relacionados con la seguridad.

Instalar y mantener las herramientas de hardware y software necesarias para garantizar laseguridad.

Colaborar con la Gestión de Cambios y Versiones para asegurar que no se introducen nuevasvulnerabilidades en los sistemas en producción o entornos de pruebas.

Proponer RFCs a la Gestión de Cambios que aumenten los niveles de seguridad.

http://www.osiatis.es/seguridad_informatica/index.php?/archives/30_Inyeccion_de_SQL.html






Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra laintegridad 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 Seguridad respecto a

todas estas cuestiones y que incluso permita que ésta proponga medidas disciplinarias vinculantes cuandolos empleados u otro personal relacionado con la seguridad de los servicios incumpla con susresponsabilidades.


Evaluación y Mantenimiento

Evaluación

No es posible mejorar aquello que no se conoce, es por la tanto indispensable evaluar el cumplimiento de lasmedidas 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 la Gestión de la Seguridad.

Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que seplasmaran 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 informesindependientes cada vez que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si laGestió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 ylas 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 decambios implementados en la infraestructura o servicios TI.

No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridadobsoletas.

Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos yvulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte lasmedidas necesarias de actualización de equipos de hardware y software, sin olvidar el apartado deformación: el factor humano es normalmente el eslabón más débil de la cadena.


Control del Proceso

Al igual que en el resto de procesos TI es necesario realizar un riguroso control del proceso para asegurarque 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 semanifiesten 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 Seguridad y aportainformación de vital importancia a otras áreas de la infraestructura TI.


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

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.


Caso Práctico

La gestión de "Cater Matters" es consciente que un enfoque sobre la seguridad basado exclusivamente en elconcepto 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 suspedidos, 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 alexterior 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 adicha información preservando su confidencialidad e integridad. Esto requiere la revisión del Plan deSeguridad 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

Itil Clase Acc

Documents

Transcript of Itil Clase Acc