Información ITIL

Enviado por Juan Pablo Leonetti el Dom, 03/11/2019 - 05:02

ITIL puede ser definido como un conjunto de buenas prácticas destinadas a mejorar la gestión y provisión de servicios TI. Su objetivo último es mejorar la calidad de los servicios, ofrecer un marco de actuación para que estos sean solucionados con el menor impacto y a la mayor brevedad posible.

 

Gestión de servicios TI:

El objetivo de un servicio es satisfacer una necesidad sin asumir directamente las capacidades y recursos necesarios para ello.

Si deseamos, por ejemplo, mantener limpias las instalaciones de nuestra empresa disponemos de dos opciones:

  • Contratar a todo el personal y recursos necesarios asumiendo todos los costes y riesgos directos de su gestión.

  • Contratar los servicios de una empresa especializada.

Si optamos por esta segunda opción cuál es el valor aportado por la prestadora de ese servicio:

  • Utilidad: las instalaciones de la empresa se mantendrán limpias.

  • Garantía: la empresa contratada será responsable de que se realice la limpieza de forma periódica y según unos estándares de calidad predeterminados.

Una correcta gestión de este servicio requerirá:

  • Conocer las necesidades del cliente

  • Estimar la capacidad y recursos necesarios para la prestación del servicio

  • Establecer los niveles de calidad del servicio

  • Supervisar la prestación del servicio

  • Establecer mecanismos de mejora y evolución del servicio

ITIL define la Gestión de Servicios como un conjunto de capacidades organizativas para la provisión de valor a los clientes en forma de servicios.

Los principios básicos para la gestión de servicios se resumen en:

  • Especialización y coordinación: los clientes deben especializarse en la gestión de su negocio y los proveedores en la gestión del servicio.

  • El principio de Agencia: los agentes actúan como intermediarios entre el cliente o usuario y el proveedor de servicios y son los responsables de la correcta prestación de dichos servicios.

  • Encapsulación: los clientes y usuarios solo están interesados en la utilidad y garantía del servicio y no en los detalles precisos para su correcta prestación.

  • Acoplamiento flexible entre recursos y usuarios, mediante, por ejemplo, sistemas redundantes, que evita que cambios o alteraciones en los recursos afecten negativamente a la experiencia de usuario.

  • Sistemas: son grupos de componentes interrelacionados o interdependientes que forman una unidad y colaboran entre sí para conseguir un objetivo común.

 

Los aspectos clave para el correcto rendimiento de un sistema son:

  • Procesos de control

  • Feedback y aprendizaje

 

La gestión de los servicios TI sobre el concepto de Ciclo de Vida, tiene como objetivo ofrecer una visión global de la vida de un servicio desde su diseño hasta su eventual abandono sin por ello ignorar los detalles de todos los procesos y funciones.

El Ciclo de Vida del Servicio consta de cinco fases que se corresponden:

  • Estrategia del Servicio: propone tratar la gestión de servicios no sólo como una capacidad sino como un activo estratégico.

  • Diseño del Servicio: cubre los principios y métodos necesarios para transformar los objetivos estratégicos en portafolios de servicios y activos.

  • Transición del Servicio: cubre el proceso de transición para la implementación de nuevos servicios o su mejora.

  • Operación del Servicio: cubre las mejores prácticas para la gestión del día a día en la operación del servicio.

  • Mejora Continua del Servicio: proporciona una guía para la creación y mantenimiento del valor ofrecido a los clientes a través de un diseño, transición y operación del servicio optimizado.

 

ITIL marca una clara distinción entre funciones y procesos. Las funciones tienen como principal objetivo ayudar a las organizaciones logrando mayores resultados. Los procesos puede ayudar a mejorar la productividad de la organización en su conjunto.

Los procesos comparten las siguientes características:

  • Los procesos son cuantificables y se basan en el rendimiento.

  • Tienen resultados específicos.

  • Los procesos tienen un cliente final que es el receptor de dicho resultado.

  • Se inician como respuesta a un evento.

 

Otro concepto ampliamente utilizado es el de rol.

Un rol es un conjunto de actividades y responsabilidades asignada a una persona o un grupo. Una persona o grupo puede desempeñar simultáneamente más de un rol.

Hay cuatro roles genéricos en la gestión de servicios TI:

  • Gestor del Servicio: es el responsable de la gestión de un servicio durante todo su ciclo de vida: desarrollo, implementación, mantenimiento, monitorización y evaluación.

  • Propietario del Servicio: es el que presenta el servicio específico al cliente.

  • Gestor del Proceso: es el responsable de la gestión de toda la operativa asociada a un proceso en particular: planificación, organización, monitorización y generación de informes.

  • Propietario del Proceso: es el último responsable frente a la organización TI de que el proceso cumple sus objetivos. Debe asegurando en todo momento que se dispone de las métricas necesarias para su correcta monitorización, evaluación y eventual mejora

 

01- Estrategia

El objetivo es saber qué servicios deben ser ofrecidos y por qué el cliente y el mercado lo necesita.

Una correcta Estrategia del Servicio debe:

  • Servir de guía a la hora de establecer y priorizar objetivos y oportunidades.

  • Conocer el mercado y los servicios de la competencia.

  • Armonizar la oferta con la demanda de servicios.

  • Proponer servicios diferenciados que aporten valor.

  • Gestionar los recursos y capacidades necesarios para prestar los servicios ofrecidos teniendo en cuenta los costes y riesgos.

  • Alinear los servicios ofrecidos con la estrategia de negocio.

  • Elaborar planes que permitan un crecimiento sostenible.

  • Crear casos de negocio para justificar inversiones estratégicas.

Una correcta implementación de la estrategia del servicio va más allá del ámbito puramente TI y requiere un enfoque multidisciplinar que ayude a responder cuestiones tales como:

¿Qué servicios debemos ofrecer?

¿Cuál es su valor?

¿Cuáles son nuestros clientes potenciales?

¿Cuáles son los resultados esperados?

¿Qué servicios son prioritarios?

¿Qué inversiones son necesarias?

¿Cuál es el retorno a la inversión o ROI?

¿Qué servicios existen ya en el mercado que puedan representar una competencia directa?

¿Cómo podemos diferenciarnos de la competencia?

 

 

Creación de valor se genera a través de lo que ve el cliente, a través de:

  • la utilidad ofrecida que debe adaptarse a las necesidades reales del cliente,

  • la garantía del proveedor que asegura que el servicio se prestará de forma continuada preservando los niveles de calidad acordados.

 

El proveedor debe tener en cuenta que el valor para el cliente está en el resultado del servicio y el impacto que éste tiene en su negocio y no en el servicio en sí mismo.

Para que una organización TI pueda ofrecer valor en forma de servicios debe hacer buen uso de sus recursos y capacidades.

Los recursos son la “materia prima” necesaria para la prestación del servicio e incluyen el capital, las infraestructuras, aplicaciones e información.

Las capacidades representan las habilidades desarrolladas a lo largo del tiempo para transformar los recursos en valor a través de la gestión, la organización, los procesos y el conocimiento.

Y en la base de ambos se encuentra el personal que es en sí mismo un recurso que aporta entre otras capacidades su profesionalidad, creatividad y capacidad de liderazgo.

ITIL considera tres tipos diferentes de proveedores de servicios:

  • Tipo I o proveedor de servicios interno

  • Tipo II o unidad de servicios compartidos

  • Tipo III o proveedores de servicio externos

 

 

El concepto de cadena de valor se asocia naturalmente a un proceso lineal en el cual cada uno de los eslabones va añadiendo valor al producto o servicio final.

Para desarrollar una estrategia del servicio viable es necesario conocer esas redes de valor:

¿Cuáles son los nodos de esa red de valor?

¿Cuáles son sus interrelaciones?

¿Cuáles son los mecanismos de generación de valor?

¿Cómo optimizar sus flujos de trabajo?

 

Las 4 P de la estrategia: ofrecen un punto de partida adecuado para definir la Estrategia del Servicio:

  • Perspectiva: disponer de metas y valores bien definidos y asumibles.

  • Posición: definir y diferenciar nuestros servicios. 

  • Planificación: establecer criterios claros de desarrollo futuro.

  • Patrón: mantener una coherencia en la toma de decisiones y acciones adoptadas.

 

Los procesos asociados directamente a la fase de Estrategia son:

  • Gestión Financiera: responsable de garantizar la prestación de servicios con unos costes controlados y una correcta relación calidad-precio.

  • Gestión del Portfolio de Servicios: responsable de la inversión en servicios nuevos y actualizados que ofrezcan el máximo valor al cliente minimizando a su vez los riesgos y costes asociados.

  • Gestión de la Demanda: responsable de la armonización de la oferta de los servicios ofrecidos con las demandas del mercado.

 

Los principales beneficios de una correcta Gestión Financiera de los Servicios Informáticos se resumen en:

  • Se reducen los costes y aumenta la rentabilidad del servicio.

  • Se ajustan, controlan, adecuan y justifican los precios del servicio, aumentando la satisfacción del cliente.

  • Los clientes contratan servicios que le ofrecen una buena relación coste/rentabilidad.

  • La organización TI puede planificar mejor sus inversiones al conocer los costes reales de los servicios TI.

  • Los servicios TI son usados más eficazmente.

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

 

Conceptos básicos

La clasificación de costes por servicio o producto puede realizarse de forma directa o indirectamente:

  • Costes directos: son los costes relacionados específica y exclusivamente con un producto o servicio, como por ejemplo, los servidores web asociados a los servicios de Internet.

  • Costes indirectos: aquellos que no son específicos y exclusivos de un servicio, como por ejemplo, la "conectividad" de la organización TI.

Costes que dependen o no del volumen de producción:

  • Costes fijos: son independientes del volumen de producción y están normalmente relacionados con gastos.

  • Costes variables: incluyen aquellos costes que dependen del volumen de producción y engloban.

Costes que dependen del horizonte temporal:

  • Costes de capital: que proviene de la amortización o inversiones a largo plazo.

  • Costes de operación: son los costes asociados al funcionamiento diario de la organización TI.

Valor de provisión

El valor de provisión de un servicio comprende los costes de creación del mismo, ya sean éstos tangibles o intangibles. Responde a la pregunta: «¿Cuánto cuesta mantener este servicio?»

Valor potencial del servicio

El valor potencial del servicio se refiere al valor añadido que aporta. Se basa en la percepción del servicio que se forma el cliente al considerar qué ventajas o mejorías representa para su negocio utilizar el servicio en lugar de sus propios activos.

Retorno de la inversión (ROI)

El retorno de la inversión (ROI), al menos en gestión de servicios, se refiere a la capacidad de un servicio para generar valor mediante sus activos.

 

Las tarifas de los servicios se generan en función de:

  • Los servicios solicitados.

  • Factores de escala y necesidades de disponibilidad.

  • Los costes asociados.

  • Los precios vigentes en el mercado.

 

La Gestión del Portfolio de Servicios desempeña las siguientes tareas:

  • Conocer y analizar el mercado en el que el servicio desarrollará su actividad, detectando oportunidades, etc.

  • Plantear unas líneas estratégicas sólidas que sirvan para orientar todas las actividades del negocio hacia una serie de objetivos claros.

  • Definir de forma detallada los servicios que se ofrecerán a los clientes.

  • Una correcta Gestión del Portfolio de Servicios repercute en una serie de mejoras y beneficios notables tanto para el servicio como para el negocio en sí.

 

Las principales actividades de la Gestión del Portfolio de Servicios se resumen en:

  • Definición del negocio: qué servicios ofrece la competencia, qué oportunidades ofrece el mercado, cuáles son los “punto fuertes” de la organización,  etc.

  • Análisis de servicios: objetivos, servicios necesarios para alcanzarlos, capacidades y recursos asociados, etc.

  • Aprobación de decisiones de cara al futuro sobre los servicios: retención, sustitución, racionalización, refactorización, renovación y retirada.

  • Actualización del Portfolio de Servicios y Planificación: definición de los servicios, prioridades, riesgos, plazos, costes previstos, etc.

 

Análisis de servicios

Tras analizar el mercado, se procede a analizar cuidadosamente las posibilidades de la organización:

¿Por qué debería un cliente comprar estos servicios?

¿Por qué debería un cliente comprar estos servicios a nuestra organización y no a otros proveedores de la competencia?

¿Cuáles serán los modelos de cobro y facturación?

¿Cuáles son las debilidades, amenazas, fortalezas y oportunidades de nuestra organización frente al mercado?

¿Cómo ha de ser el reparto de recursos y capacidades?

¿Cuáles son los objetivos de la organización a largo plazo?

¿Qué servicios serían necesarios para alcanzar esos objetivos?

¿Qué capacidades y recursos se necesitan para crear y mantener esos servicios?

 

Aprobación de servicios

En la toma de decisión, la Gestión del Portfolio de Servicios tiene en cuenta dos factores: el valor que aporta la iniciativa y el riesgo que conlleva. Tan sólo aquellos servicios en los que ambas facetas estén equilibradas podrán ser aprobados.

 

La planificación consiste en la definición de las tareas y plazos de entrega en un Plan de Estrategia del Servicio que sirva para actuar en base a las decisiones adoptadas en la etapa de aprobación y recogidas en el Portfolio de Servicios.

 

La Gestión de la Demanda se encarga de predecir y regular los ciclos de consumo.

Una correcta Gestión de la Demanda aporta una serie de mejoras y beneficios:

 

 

Conceptos básicos

Un Paquete de Servicio (SP) es una descripción completa de un servicio TI que ya está disponible para ser entregado a los clientes.

Un Paquete de Nivel de Servicio (SLP) consiste en la definición de un nivel de utilidad y garantía específicos para un Paquete de Servicio concreto. Los SLP se diseñan conforme a las necesidades de un Patrón de Actividad de Negocio (PBA) particular.

Un Paquete de Servicio Esencial (CSP) es una descripción detallada de un servicio básico que puede ser compartido por dos o más Paquetes de Nivel de Servicio.

Una Línea de Servicio (LOS) es un servicio esencial o de soporte común a varios Paquetes de Nivel de Servicio (SLP). Cada LOS tiene asignado un Gestor de Producto.

 

La implementación de la Estrategia del Servicio debe contar con una fase previa de estudio donde se deben abordar cuestiones tales como:

¿Cuáles son nuestros servicios clave?

¿Cómo se diferencian de los de nuestra competencia?

¿Qué percepción tienen nuestros clientes de la calidad del servicio prestado?

¿Somos eficientes en los costes?

¿Disponemos de suficientes recursos o por el contrario estos están sobredimensionados?

¿Cuáles son nuestras capacidades clave?

¿Cuáles son las tendencias actuales del mercado y las necesidades de nuestros clientes?

 

Dependiendo de las respuestas a estas (y otras) preguntas se deben establecer:

  • Los objetivos principales de la estrategia del servicio

  • Los planes de implementación

  • Los factores que determinarán el éxito de la implantación

 

La elección de un determinado tipo de contratación ha de tomarse teniendo en cuenta:

  • Se mejorará con la contratación del servicio el valor ofrecido

  • El proveedor elegido permitirá diferenciarnos de la competencia

  • Puede resultar el proveedor una competencia en nuestros sector del mercado

  • Podríamos caer cautivos de un proveedor estratégico

  • Qué impacto en el negocio podría tener una eventual interrupción en el servicio

 

Los principales riesgos que afronta un proveedor de servicios se resumen en:

  • Riesgos de contratación debidos a la imposibilidad de cumplir los contratos con los niveles de servicio acordados.

  • Riesgos de diseño asociados a una incorrecta funcionalidad del servicio que se traduce en un pobre rendimiento.

  • Riesgos operativos comunes a todas las organizaciones.

  • Riesgos de mercado debidos a una pobre diferenciación de los servicios ofrecidos o a una mala gestión.

 

En lo que respecta específicamente a la fase de la Estrategia del Servicio los principales retos, riesgos se resumen en:

  • Gestión de la complejidad: las organizaciones TI son sistemas complejos en lo que es difícil implantar una estrategia que llegue a todos los rincones de la organización. La formación y la comunicación continua deben formar parte.

  • Coordinación: las redes de valor no aportarán valor a los servicios si sus aportaciones no están adecuadamente coordinadas

  • Preservación del valor: se deben establecer métricas que no solamente aseguren los factores de funcionalidad y garantía sino que también tengan en cuenta aspectos financieros y de eficiencia en los procesos de negocio.

  • Medición del rendimiento: si no lo puedes medir no lo puedes gestionar .

  •  Se deben establecer métricas para:

-El cumplimiento de los objetivos estratégicos

-La calidad de los servicios

-La calidad de los procesos

-El rendimiento de la organización

-Tiempos de respuesta

-Valoraciones realistas de los costes del servicio

 

 

02 -Diseño

La principal misión de la fase de Diseño del Servicio es la de diseñar nuevos servicios o modificar los ya existentes para su incorporación al catálogo de servicios y su paso al entorno de producción:

  • Se adecuen a las necesidades del mercado.

  • Sean eficientes en costes y rentables.

  • Cumplan los estándares de calidad adoptados.

  • Aporten valor a clientes y usuarios.

 

El Diseño del Servicio debe tener en cuenta tanto los requisitos del servicio como los recursos y capacidades disponibles en la organización TI. Un desequilibrio entre ambos lados de la balanza puede resultar en servicios donde se vean comprometidas bien la funcionalidad o bien la garantía.

Una correcta implementación del Diseño del Servicio debe ayudar a responder cuestiones tales como:

¿Cuáles son los requisitos y necesidades de nuestros clientes?

¿Cuáles son los recursos y capacidades necesarias para prestar los servicios propuestos?

¿Los servicios son seguros, ofrecen la disponibilidad necesaria y se garantiza la continuidad del servicio?

¿Son necesarias nuevas inversiones para prestar los servicios con los niveles de calidad propuestos?

¿Están todos los agentes involucrados correctamente informados sobre los objetivos y alcance de los nuevos servicios o de las modificaciones a realizar en los ya existentes?

¿Se necesita la colaboración de proveedores externos?

 

Cinco aspectos esenciales en el Diseño del Servicio:

1. Diseño de soluciones de servicio

Debe incluir de forma estructurada todos los elementos clave del nuevo o modificado servicio:

  • Requisitos de negocio

  • Requisitos de servicio (SLR)

  • Adecuación a la estrategia del servicio

  • Análisis funcional

  • Estudios de los servicios prestados para ver si existen módulos reutilizables de otros servicios en cartera

  • Análisis de costes (TCO) y retorno a la inversión

  • Estudio de los recursos y capacidades involucradas

  • Estrategias de contratación con los proveedores externos

 

2. Diseño del Portfolio de Servicios

El Portfolio de Servicios es una de las principales herramientas para la gestión del servicio a través de todas las fases del ciclo de vida. Debe incluir información sobre todos los servicios ofrecidos, los servicios en fase de desarrollo y los servicios retirados en términos de valor para el negocio.

La fase de Diseño del Servicio es responsable de determinar su contenido específico así como sus permisos de acceso.

El Portfolio de Servicios debe contener información sobre:

  • Los objetivos del servicio

  • Su valor: funcionalidad y garantía

  • Su estado

  • Los SLAs asociados

  • Capacidades y recursos utilizados

  • Sus costes y retorno esperado

  • Los controles o métricas de calidad asociados

  • Los responsables del mismo

  • Servicios relacionados

  • Proveedores externos involucrados (OLAs y UCs)

 

3. Diseño de la arquitectura del servicio

La arquitectura debe tener en cuanto todos los elementos necesarios para la Gestión del Servicio así como la interrelación entre ellos y el mercado. Debe ofrecer una guía para el diseño y evolución del servicio teniendo en cuenta:

  • La alineación entre la tecnología y el negocio.

  • La infraestructura TI necesaria.

  • La Gestión de las aplicaciones.

  • La Gestión de los datos y la información.

  • La Documentación y Gestión del Conocimiento.

  • Los Planes de Despliegue del servicio.

 

4. Diseño de procesos

La gestión basada en procesos es una de las señas de identidad de ITIL. En la fase de diseño del servicio se han de definir los procesos involucrados con una descripción detallada de sus actividades, funciones, organización, entradas y salidas.

En particular deben establecerse los procesos de control para asegurar que los procesos se realizan de forma eficiente y cumplen los objetivos establecidos.

Los procesos no deben ser un fin en sí mismo sino que deben tener como principal objetivo que la organización TI ofrezca servicios de valor al cliente de forma eficiente.

 

5. Diseño de métricas y sistemas de monitorización

Es imprescindible diseñar sistemas de medición y seguimiento que permitan evaluar tanto la calidad de los servicios prestados como la eficiencia de los procesos involucrados.

Los resultados recopilados mediante estos sistemas de seguimiento y su análisis posterior, basado en métricas y métodos preestablecidos, deben de ser la principal entrada para la fase de Mejora del Servicio.

Existen cuatro tipos principales de métricas a considerar:

  • Progreso: cumplimiento de los calendarios previstos

  • Cumplimiento: adecuación a las políticas y requisitos predefinidos.

  • Eficacia: calidad de los resultados obtenidos.

  • Rendimiento: productividad de los procesos y gestión de los recursos utilizados.

 

 

Las funciones y procesos asociados directamente a la fase de Diseño son:

Gestión del Catálogo de Servicios: responsable de crear y mantener un catálogo de servicios de la organización TI que incluya toda la información relevante: gestores, estatus, proveedores, etcétera.

Gestión de Niveles de Servicio: responsable de acordar y garantizar los niveles de calidad de los servicios TI prestados.

Gestión de la Capacidad: responsable de garantizar que la organización TI dispone de la capacidad suficiente para prestar los servicios acordados.

Gestión de la Disponibilidad: responsable de garantizar que se cumplen los niveles de disponibilidad acordados en los SLA.

Gestión de la Continuidad de los Servicios TI: responsable de establecer planes de contingencia que aseguren la continuidad del servicio en un tiempo predeterminado con el menor impacto posible en los servicios de carácter crítico.

Gestión de la Seguridad de la Información: responsable de establecer las políticas de integridad, confidencialidad y disponibilidad de la información.

Gestión de Proveedores: responsable de la relación con los proveedores y el cumplimiento de los UCs.

 

 

Conceptos básicos

Los Requisitos de Nivel de Servicio (SLR) deben recoger información detallada sobre las necesidades del cliente y sus expectativas de rendimiento y nivel de servicios.

El documento de SLR constituye el elemento base para desarrollar los SLA y posibles OLAs correspondientes.

Hojas de Especificación

Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.

El Plan de Calidad del Servicio (SQP) debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles de calidad del servicio:

  • Objetivos de cada servicio.

  • Estimación de recursos.

  • Indicadores clave de rendimiento.

  • Procedimientos de monitorización de proveedores.

El SLA debe recoger en un lenguaje no técnico, o cuando menos comprensible para el cliente, todos los detalles de los servicios brindados.

Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.

Acuerdo de Nivel de Operación (OLA)

El Acuerdo de Nivel de Operación (OLA) es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio.

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

El Programa de Mejora del Servicio (SIP) debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio como propuestas de mejora basadas en el avance de la tecnología.

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 Servicio y Plan de Calidad del Servicio (SQP).

Implementación de los Acuerdos de Niveles de 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).

 

Todo el proceso de planificación previo debe estar orientado a dar respuesta a las siguientes preguntas:

¿Qué servicios debemos ofrecer a nuestros clientes?

¿Cuáles son las necesidades de nuestros clientes?

¿Cuál es el nivel adecuado de calidad de servicio?

¿Quiénes y cómo se van a suministrar esos servicios?

¿Cuáles serán los indicadores clave de rendimiento para los servicios prestados?

¿Disponemos de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados?

 

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.

 

La información contenida en el SLR debe servir de base para elaborar la documentación interna que permita determinar "cómo" se prestara el servicio y "quién o quiénes" serán responsables del mismo.

Las Hojas de Especificación del Servicio deben contener:

  • Una descripción detallada, con todos los detalles técnicos necesarios, sobre como se prestará el servicio.

  • Cuáles serán los indicadores internos de rendimiento y calidad del servicio.

  • Cómo se implementará el servicio.

El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios.

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

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

 

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 de Soporte.

Acuerdos de Nivel de Servicio

 

Los Acuerdos de Nivel de Servicio (SLAs) deben contener una descripción del servicio que abarque desde los aspectos más generales hasta los detalles más específicos del servicio.

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 Acuerdos de Nivel de Operación (OLAs) son documentos de carácter interno de la propia organización TI que determinan los procesos y procedimiento necesarios para ofrecer los niveles de servicio acordados con los clientes.

 

Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de prestación de servicios.

Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los Contratos de Soporte deben representar compromisos claros y perfectamente delimitados.

 

El proceso de monitorización de Niveles de Servicio es imprescindible si queremos mejorar progresivamente la calidad del servicio ofrecido, su rentabilidad y la satisfacción de los clientes y usuarios.

La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la organización como los relacionados con la percepción de los usuarios.

Las principales fuentes de información las constituyen:

  • La documentación disponible: SLAs, SLRs, OLAs, SQP, SIP, UCs, etc.

  • La Gestión de Incidencias y la Gestión de Problemas, que deben informar de las incidencias en el servicio y los tiempos de recuperación.

  • La Gestión de la Continuidad y la Gestión de la Disponibilidad, que deben proporcionar la información sobre la infraestructura utilizada para satisfacer la calidad de servicios acordada.

  • El Centro de Servicios (Service Desk), que mediante su trato diario con los clientes, usuarios y organización TI supervisa la calidad de los servicios y conoce la percepción del cliente respecto a los mismos.

 

Los informes de rendimiento elaborados deben cubrir factores clave tales como:

  • Cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio.

  • Quejas, justificadas o no, de los clientes y usuarios.

  • Utilización de la capacidad predefinida.

  • Disponibilidad del servicio.

  • Tiempos de respuesta.

  • Costes reales del servicio ofrecido.

  • Problemas detectados y cambios realizados para restaurar la calidad del servicio.

  • Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OL

 

El objetivo de la Gestión de Niveles de Servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del cliente, pero esto no se puede llevar a cabo sin una buena gestión de los procesos involucrados.

Es esencial disponer de:

  • Unos objetivos claros y contrastables.

  • Un equipo con experiencia liderado por un Gestor del Nivel de Servicio con la cualificación y experiencia 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 del servicio.

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

  • Encuestas de satisfacción del cliente.

 

Entre la documentación generada cabría destacar:

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

  • Informes de Seguimiento: donde se especifiquen las acciones de monitorización realizadas, sus resultados y el grado de satisfacción de los clientes con el servicio prestado.

  • Planes de Mejora (SIP): donde se especifiquen las acciones propuestas para la mejora del servicio TI y el impacto que estas han tenido en 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 del propio departamento TI los recursos informáticos necesarios para desempeñar de una manera eficiente sus tareas y todo ello sin incurrir en costes desproporcionados.

Para ello, la Gestión de la Capacidad debe:

  • Conocer el estado actual de la tecnología y previsibles futuros desarrollos.

  • Conocer los planes de negocio y acuerdos de nivel de servicio para prever la capacidad necesaria.

  • Analizar el rendimiento de la infraestructura para monitorizar el uso de la capacidad existente.

  • Realizar modelos y simulaciones de capacidad para diferentes escenarios futuros previsibles.

  • Dimensionar adecuadamente los servicios y aplicaciones alineándolos a los procesos de negocio y necesidades reales del cliente.

  • Gestionar la demanda de servicios informáticos racionalizando su uso.

 

Los principales beneficios derivados de una correcta Gestión de la Capacidad son:

  • Se optimiza el rendimiento de los recursos informáticos.

  • Se dispone de la capacidad necesaria en el momento oportuno, evitando así que se pueda resentir la calidad del servicio.

  • Se evitan gastos innecesarios producidos por compras de "última hora".

  • Se planifica el crecimiento de la infraestructura adecuándolo a las necesidades reales de negocio.

  • Se reducen de los gastos de mantenimiento y administración asociados a equipos y aplicaciones que han quedado obsoletos o son innecesarios.

  • Se reducen posibles incompatibilidades y fallos en la infraestructura informática.

 

El proceso de Gestión de la Capacidad puede segmentarse en subprocesos que analizan las necesidades de capacidad TI desde diferentes puntos de vista:

  • Gestión de la Capacidad del Negocio (BCM, del inglés Business Capacity Management): que centra su objeto de atención en las necesidades futuras de usuarios y clientes.

  • Gestión de la Capacidad del Servicio (SCM, del inglés Service Capacity Management): 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 (CCM, del inglés Component Capacity Management): que estudia tanto el uso de la infraestructura TI como sus tendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizan eficazmen

 

La elaboración del Plan de Capacidad es la tarea principal de la Gestión de Capacidad.

El Plan de Capacidad recoge:

  • Toda la información relativa a la capacidad de la infraestructura TI.

  • Las previsiones sobre necesidades futuras basadas en tendencias, previsiones de negocio y SLAs existentes.

  • Los cambios necesarios para adaptar la capacidad TI a las novedades tecnológicas y las necesidades emergentes de usuarios y clientes.

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

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

 

 

Monitorización

Su objetivo principal es asegurar que el rendimiento de la infraestructura informática se adecua a los requisitos de los SLAs.

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

Análisis y Evaluación

Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas tales como petición de aumento de la capacidad o una mejor Gestión de la Demanda.

Optimización y cambios

Si se ha optado por solicitar un aumento de la capacidad, se elevará una petición de cambio (RFC) a la Gestión de Cambios para que se desencadene todo el proceso necesario para la implementación del cambio. La Gestión de la Capacidad prestará su apoyo en todo el proceso y será corresponsable, junto a la Gestión de Cambios y Versiones, de asegurar que el cambio solicitado cumpla los objetivos previstos.

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

 

 

El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén disponibles y funcionen correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor.

Las responsabilidades de la Gestión de la Disponibilidad incluyen:

  • Determinar los requisitos de disponibilidad en estrecha colaboración con los clientes.

  • Garantizar el nivel de disponibilidad establecido para los servicios TI.

  • Monitorizar la disponibilidad de los sistemas TI.

  • Proponer mejoras en la infraestructura y servicios TI con el objetivo de aumentar los niveles de disponibilidad.

  • Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores internos y externos.

 

Los indicadores clave sobre los que se sustenta el proceso de Gestión de la Disponibilidad se resumen en:

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

  • Fiabilidad: medida del tiempo durante el cual los servicios han funcionado correctamente de forma ininterrumpida.

  • Capacidad de mantenimiento: capacidad de recuperar el servicio en caso de interrupción.

  • Capacidad de Servicio: determina la disponibilidad de los servicios internos y externos contratados y su adecuación a los OLAs y UCs en vigor. Cuando un servicio TI es subcontratado en su totalidad la disponibilidad y la capacidad de servicio son términos equivalentes.

  • La disponibilidad depende del correcto diseño de los servicios TI, la fiabilidad de los CIs involucrados, su correcto mantenimiento y la calidad de los servicios internos y externos acordados.

 

Los principales beneficios de una correcta Gestión de la Disponibilidad son:

  • Cumplimiento de los niveles de disponibilidad acordados.

  • Se reducen los costes asociados a un alto nivel de disponibilidad.

  • El cliente percibe una mayor calidad de servicio.

  • Se aumentan progresivamente los niveles de disponibilidad.

  • Se reduce el número de incidentes.

  • Las principales dificultades con las que topa la Gestión de la Disponibilidad son:

  • No se monitoriza correctamente la disponibilidad real del servicio.

  • No existe compromiso con el proceso dentro de la organización TI.

  • No se dispone de las herramientas de software y personal adecuado.

  • Los objetivos de disponibilidad no están alineados con las necesidades del cliente.

  • Falta de coordinación con los otros procesos.

  • Los proveedores internos y externos no reconocen la autoridad del Gestor de la Disponibilidad por falta de apoyo de la dirección.

 

Entre las actividades que la Gestión de la Disponibilidad se encuentran:

  • Determinar cuáles son los requisitos de disponibilidad reales del negocio.

  • Desarrollar un plan de disponibilidad donde se estimen las futuras 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, capacidad de mantenimiento y cumplimiento de OLAs y UCs.

  • Evaluar el impacto de las políticas de seguridad en la disponibilidad.

  • Asesorar a la Gestión de Cambios sobre el posible impacto de un cambio en la disponibilidad.

 

 

Para llevar a cabo eficientemente esta 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 horarias de disponibilidad de los servicios TI (24/7, 12/5, ...).

 

La correcta planificación de la disponibilidad permite establecer unos niveles de disponibilidad adecuados tanto en lo que respecta a las necesidades reales del negocio como a las posibilidades de la organización TI.

El documento que debe recoger los objetivos de disponibilidad presentes y futuros y qué medidas son necesarias para su cumplimiento es el Plan de Disponibilidad.

Este plan debe recoger:

  • La situación actual de disponibilidad de los servicios TI. Obviamente esta información debe ser actualizada periódicamente.

  • Herramientas para la monitorización de la disponibilidad.

  • Métodos y técnicas de análisis a utilizar.

  • DefIniciones relevantes y precisas de las métricas a utilizar.

  • Planes de mejora de la disponibilidad.

  • Expectativas futuras de disponibilidad.

 

 

Desde el momento de la interrupción del servicio hasta su restitución o "tiempo de parada" el incidente pasa por distintas fases que deben ser analizadas por separado:

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

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

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

 

Las principales actividades de la Gestión de la Continuidad de los Servicios TI se resumen en:

 

Política y Alcance

El primer paso necesario para desarrollar una Gestión de la Continuidad del Servicio coherente es establecer claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política.

La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión.

Es imprescindible establecer el alcance de la ITSCM en función de:

  • Los planes generales de Continuidad del Negocio.

  • Los servicios TI estratégicos.

  • Los estándares de calidad adoptados.

  • El histórico de interrupciones graves de los servicios TI.

  • Las expectativas de negocio.

  • La disponibilidad de recursos.

 

Análisis de Impacto

Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar determinar el impacto que una interrupción de los servicios TI pueden tener en el negocio.

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 de negocio.

  • Compromisos adquiridos a través de los SLAs.

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

  • Evaluación de Riesgos

Sin conocer cuáles son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar una política de prevención y recuperación ante desastre mínimamente eficaz.

La Gestión de la Continuidad del Servicio debe enumerar y evaluar, dependiendo de su probabilidad e impacto, los diferentes riesgos factores de riesgo. Para ello la ITSCM debe:

  • Conocer en profundidad la infraestructura TI y cuales son los elementos de configuración (CIs) involucrados en la prestación de cada servicio, especialmente los servicios TI críticos y estratégicos.

  • Analizar las posibles amenazas y estimar su probabilidad.

  • Detectar los puntos más vulnerables de la infraestructura TI.

 

Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidas unas estrategias de prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con ese objetivo la Gestión de la Continuidad del Servicio debe elaborar una serie de documentos entre los que se incluyen:

  • Plan de prevención de riesgos.

  • Plan de gestión de emergencias.

  • Plan de recuperación.

  • Plan de prevención de riesgos

Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en la infraestructura TI.

Entre las medidas habituales se encuentran:

  • Almacenamiento de datos distribuidos.

  • Sistemas de alimentación eléctrica de soporte.

  • Políticas de back-ups.

  • Duplicación de sistemas críticos.

  • Sistemas de seguridad pasivos.

  • Plan de gestión de emergencias

 

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 del 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, llega el momento de poner en marcha los procedimientos de recuperación.

El plan de recuperación debe incluir todo lo necesario para:

  • Reorganizar al personal involucrado.

  • Reestablecer los sistemas de hardware y software necesarios.

  • Recuperar los datos y reiniciar el servicio TI.

Los procedimientos de recuperación pueden depender de la importancia de la contingencia y de la opción de recuperación asociada ("cold o hot stand-by"), pero en general involucran:

  • Asignación de personal y recursos.

  • Instalaciones y hardware alternativos.

  • Planes de seguridad que garanticen la integridad de los datos.

  • Procedimientos de recuperación de datos.

  • Contratos de colaboración con otras organizaciones.

  • Protocolos de comunicación con los clientes.

 

RACI

Para que la fase de diseño resulte exitosa es imprescindible organizar adecuadamente todos los procesos y actividades implicados.

Un modelo útil para la asignación de responsabilidades en la ejecución de tareas o actividades asignados a un proyecto es el llamado modelo RACI (también llamado matriz de asignación de responsabilidades) que es el acrónimo de:

  • Responsible (Encargado): es la persona encargada de hacer la tarea en cuestión.

  • Accountable (Responsable): es el único responsable de la correcta ejecución de la tarea.

  • <>Consulted (Consultado): las personas que deben ser consultadas para la realización de la tarea.

  • Informed (Informado): Las personas que deben ser informadas sobre el progreso de ejecución de la tarea.

En cada tarea debe haber un único R y A. Si esto no fuera así la tarea se subdividirá hasta que así sea. Por supuesto una persona puede ser, a priori, R o A en múltiples tareas.

Una matriz RACI típicamente tiene un eje vertical donde se describen las tareas o entregables en orden cronológico y en el eje horizontal los perfiles o personas implicadas en los mismos.

 

Existen variaciones menores de este modelo que incluyen nuevos roles.

Por ejemplo en RASCI se incluye:

  • Support (Soporte): que se corresponde con las personas encargadas de facilitar el soporte necesario para la realización de la tarea.

Y el RACI-VS que introduce los roles de:

  • Verify (Vericador): encargado de supervisar la tarea y su adecuación a los estándares preestablecidos.

  • Sign (Signatario o firmante): encargado de dar la aprobación.

 

 

03 Transición

 

La misión de la fase de Transición del Servicio es hacer que los productos y servicios definidos en la fase de Diseño del Servicio se integren en el entorno de producción y sean accesibles a los clientes y usuarios autorizados.

Sus principales objetivos se resumen en:

  • Supervisar y dar soporte a todo el proceso de cambio del nuevo (o modificado) servicio.

  • Garantizar que los nuevos servicios cumplen los requisitos y estándares de calidad estipulados en las fases de Estrategia y la de Diseño.

  • Minimizar los riesgos intrínsecos asociados al cambio reduciendo el posible impacto sobre los servicios ya existentes.

  • Mejorar la satisfacción del cliente respecto a los servicios prestados.

  • Comunicar el cambio a todos los agentes implicados.

Para cumplir adecuadamente estos objetivos es necesario que durante la fase de Transición del Servicio:

  • Se planifique todo el proceso de cambio.

  • Se creen los entornos de pruebas y preproducción necesarios.

  • Se realicen todas las pruebas necesarias para asegurar la adecuación del nuevo servicio a los requisitos predefinidos.

  • Se establezcan planes de roll-out (despliegue) y roll-back (retorno a la última versión estable).

  • Se cierre el proceso de cambio con una detallada revisión post-implementación.

Como resultado de una correcta Transición del Servicio:

  • Los clientes disponen de servicios mejor alineados con sus necesidades de negocio.

  • La implementación de nuevos servicios es más eficiente.

  • Los servicios responden mejor a los cambios del mercado y a los requisitos de los clientes.

  • Se controlan los riesgos y se dispone de planes de contingencia que eviten una degradación prolongada del servicio.

Se mantienen correctamente actualizadas las bases de datos de configuración y activos del servicio.

Se dispone de una Base de Conocimiento actualizada a disposición del personal responsable de la operación del servicio y sus usuarios.

 

 

Las principales funciones y procesos asociados directamente a la Fase de Transición del Servicio son:

  • Planificación y soporte a la Transición: responsable de planificar y coordinar todo el proceso de transición asociado a la creación o modificación de los servicios TI.

  • Gestión de Cambios: responsable de supervisar y aprobar la introducción o modificación de los servicios prestados garantizando que todo el proceso ha sido convenientemente planificado, evaluado, probado, implementado y documentado.

  • Gestión de la Configuración y Activos del Servicio: responsable del registro y gestión de los elementos de configuración (CIs) y activos del servicio. Este proceso da soporte a prácticamente todos los aspectos de la Gestión del Servicio

  • Gestión de Entregas y Despliegues: Responsable de desarrollar, probar e implementar las nuevas versiones de los servicios según las directrices marcadas en la fase de Diseño del Servicio.

  • Validación y pruebas: responsable de garantizar que los servicios cumplen los requisitos preestablecidos antes de su paso al entorno de producción.

  • Evaluación: responsable de evaluar la calidad general de los servicios, su rentabilidad, su utilización, la percepción de sus usuarios, etcétera

  • Gestión del Conocimiento: gestiona toda la información relevante a la prestación de los servicios asegurando que esté disponible para los agentes implicados en su concepción, diseño, desarrollo, implementación y operación.

 

Una vez definida una estrategia general y acordadas desde la fase de Diseño las especificaciones sobre cómo se van a prestar los servicios, hay que ponerse manos a la obra. La Planificación y Soporte de la Transición es la encargada de coordinar los recursos de la organización TI para poner en marcha el servicio en el tiempo, calidad y coste definidos previamente.

Esto incluye la definición de los entregables (contenido, plazos, niveles de calidad), así como los flujos de trabajo y los actores involucrados en la prestación del servicio, los protocolos de control de la calidad, test de pruebas, mecanismos de monitorización, reportes, etc.

Sin embargo, no podemos concebir estas tareas de coordinación como una “realidad paralela”, independiente del resto del Ciclo de Vida. La Planificación y Soporte de la Transición no podría ejercer su labor sin los inputs provenientes del resto de procesos:

  • Paquete de diseño del servicio (SDP). Contiene toda la información del servicio registrada en el Catálogo de Servicios, incluyendo los requisitos que éste debe cumplir (SLAs, SLRs, OLAs, etc.).

  • La Gestión de Cambios enviará toda la información relacionada con la propuesta de cambio (RFC) que se va a ejecutar durante la transición. Por supuesto, dichos cambios deben contar con la autorización formal del Gestor del Cambio o del Comité de Cambios (CAB).

  • Definición del paquete de entrega y otras especificaciones de diseño.

Por su parte, la Planificación también proporciona documentación de salida a otros procesos, especialmente a los de la fase de Transición:

  • Estrategia de transición y modelo de entregas.

  • Recopilación integral de planes de Transición del Servicio.

  • Información sobre riesgos y posibles impactos del cambio en la calidad del servicio.

  • El principal cometido de este proceso consiste, como ya hemos esbozado, en coordinar y planificar los recursos necesarios para desplegar una nueva versión del servicio en el tiempo, coste y calidad requeridos en las especificaciones.

  • Para ello debe asegurarse de que todas las partes implicadas adoptan una metodología de trabajo común, proporcionando un plan de transición capaz de alinear el cambio con las necesidades del cliente.

Una correcta Planificación de la Transición trae consigo importantes ventajas que aportan valor al negocio:

  • Incrementa la capacidad de la organización para manejar de forma simultánea un gran volumen de cambios y versiones.

  • El servicio prestado está mejor alineado con los requisitos del cliente y los proveedores, e incluso con la propia estrategia interna de la organización.

  • Al existir un cronograma general del que todos los procesos tienen conocimiento, se minimizan los tiempos muertos y por tanto los retrasos.

  • Entre las dificultades que pueden obstaculizar la Planificación de la Transición encontramos:

  • La relación entre los recursos disponibles para prestar el servicio y la calidad exigida en los requisitos está desequilibrada, ocasionando el incumplimiento de plazos o de acuerdos con el cliente.

  • La información sobre los elementos de configuración relacionados con el cambio no está actualizada.

  • La valoración de la RFC en cuanto a su impacto y los recursos que precisará es incompleta o errónea.

  • Los SACs no están alineados con los requisitos de diseño.

  • Los elementos de configuración que intervienen en el cambio no están preparados llegado el momento, ocasionando retrasos en la planificación.

  • Se monitoriza cada uno de los pasos de la transición, pero a menos que el cliente lo reclame no se hace una reflexión final sobre el rendimiento, la adecuación a los requisitos planteados inicialmente, etc.

 

 

Conceptos básicos

Una Petición de Cambio o RFC es una petición formal para efectuar modificaciones en uno o más CIs.

La Revisión Post-Implantación o PIR es una fase de soporte posterior a la implementación de los cambios en la que la Planificación y Soporte a la Transición asesora a todas las partes implicadas.

Estas labores de soporte consisten principalmente en informar sobre los procesos, sistemas y herramientas de apoyo a la Transición del Servicio.

Las principales actividades de la Planificación y Soporte a la Transición se resumen en:

Estrategia

  • Políticas generales.

  • Metodología.

  • Actores implicados (instituciones, proveedores, etc.).

  • Requisitos internos y externos a tener en cuenta.

  • Tipos de entregas.

Preparación

  • Revisión de la documentación.

  • Comprobación de los elementos de configuración.

  • Identificación de los cambios de que consta la transición.

Planificación

  • Definición de fases y plazos.

  • Asignación de recursos.

  • Establecimiento de SACs.

  • Estrategia de transición

  • En primer lugar, la organización debe definir la estrategia de transición para llevar a cabo los cambios previstos en el servicio nuevo o a modificar.

Los puntos clave que debe contemplar dicha estrategia incluyen:

  • Propósito, objetivos y metas.

  • Contexto de prestación del servicio.

  • Requisitos externos que deban tenerse en cuenta (estándares, legislación vigente, acuerdos contractuales, etc.). Requisitos particulares del servicio.

  • Organizaciones y terceros interesados (socios estratégicos, proveedores, etc.)

  • Marco de trabajo a adoptar (políticas, protocolos de autorización, etc.)

  • Roles y responsabilidades. Requisitos de formación de la plantilla involucrada.

  • Planificación de hitos y entregables. Frecuencia de entrega.

  • Convenios de nomenclatura que se han adoptado para denominar las entregas (p. ej. “versión 1.1.3.65”)

  • Criterios de evaluación y de aceptación de las RFCs.

  • Criterios para dar por concluido el soporte post-implantación (ELS).

  • Las entregas pueden clasificarse, grosso modo, en los siguientes tipos:

  • Entrega mayor. Se consideran de esta clase los despliegues que incluyan la instalación de nuevo hardware y software, ya que suelen implicar un aumento de las funcionalidades.

  • Entrega menor. Suelen consistir en paquetes de pequeñas mejoras, a menudo correspondientes a soluciones provisionales a problemas concretos.

  • Entrega de emergencia. Se implementan de manera individual para resolver errores conocidos o problemas que no pueden esperar.

 

La preparación consiste en una revisión general de toda la información recabada, así como de los elementos (recursos materiales, personal interno, proveedores, etc.) que intervendrán en la ejecución de los cambios.

  • Revisión y aceptación de los inputs procedentes del resto de procesos del Ciclo de Vida.

  • Revisión y comprobación del paquete de diseño del servicio (SDP) creado en la fase de Diseño.

  • Revisión de los SACs.

  • Identificación, desarrollo y planificación de las peticiones de cambio (RFCs).

  • Comprobación de que la Gestión de la Configuración está actualizada.

  • Comprobación de que la Transición está preparada para llevarse a cabo.

El desarrollo y despliegue de cada transición debe ser compartimentado en distintas etapas:

  • Adquisición y evaluación de los CIs y otros componentes.

  • Desarrollo de la entrega y evaluación preliminar.

  • Validación y pruebas de la entrega.

  • Comprobación de que el servicio está preparado para pasar a la fase de Operación.

  • Despliegue de la nueva versión.

  • Soporte post-implementación.

  • Revisión y cierre de la transición.

Para cada una de estas etapas deben definirse los siguientes aspectos:

  • Descripción de tareas y actividades.

  • Recursos específicos asignados a cada tarea.

  • Criterios de aceptación o SACs para determinar si se puede pasar a la siguiente etapa.

  • Incidencias que pueden presentarse y riesgos asociados.

  • Plazos previstos para cada fase.

  • Una buena Planificación y Soporte a la Transición tenderá a agrupar varias entregas y despliegues en una programación global, de tal manera que cada despliegue significativo será gestionado como un proyecto aparte.

  • Por último, debe hacerse una revisión exhaustiva de los planes estratégicos una vez terminados.

  • Control del proceso

El propietario de este proceso es el Jefe de Proyecto (Project Manager). En él recae la responsabilidad de controlar y medir los siguientes indicadores:

  • Número de proyectos gestionados. Es decir, el número de versiones desplegadas (rollout) que han sido objeto de planificación y soporte.

  • Porcentaje de entregas (respecto al total de entregables) que se ajustaron a lo acordado con el cliente en cuanto a coste, calidad y alcance.

  • Ajuste al presupuesto del proyecto, comparando el consumo de recursos humanos y financieros previstos con los que se usaron realmente.

  • Retrasos en proyectos, comparando las fechas de entrega reales con las que en un principio se habían definido en la planificación.

 

 

Conceptos básicos

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

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

Comité Asesor del Cambio (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.

Modelos de Cambio: es una serie de grupos de cambios que han sido previamente clasificados, analizados y autorizados, de tal manera que se predefinen ciertos mecanismos y actividades a realizar para cada grupo. De esta manera se al

 

El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de la Configuración y Activos TI: todos los cambios de CIs inventariados en la CMDB deben ser correctamente supervisados y registrados.

Al igual que a la hora de implementar la Gestión de la Configuración y Activos TI, se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos estén previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas.

Estos protocolos de cambio estándar deben ser cuidadosamente elaborados, pero una vez definidos permiten una gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.

 

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

 

Registro de peticiones

El primer paso del proceso de cambio es registrar adecuadamente las RFCs.

El origen de una RFC puede ser de muy distinta índole:

  • Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayoría de los casos, esta solución acarrea un cambio en la infraestructura TI. En este caso, el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso.

  • Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados.

  • Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM, etc. y que por regla general requieren de cambios de hardware, software y/o procedimientos.

  • Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualización.

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

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

 

 

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

  • Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo hardware, etc.

  • Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad. A su vez, los cambios de esta categoría se pueden dividir en menores, significativos y mayores.

  • Alta: un cambio que debe realizarse sin demora, pues está asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución.

  • Urgente: es necesario resolver un problema que está provocando una interrupción o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente. Los cambios de esta categoría pueden clasificarse a su vez en normales y de emergencia.

 

Para su aprobación, el cambio se debe evaluar minuciosamente:

¿Cuáles son los beneficios esperados del cambio propuesto?

¿Justifican esos beneficios los costes asociados al proceso de cambio?

¿Cuáles son los riesgos asociados?

¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?

¿Puede demorarse el cambio?

¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI?

¿Puede el cambio afectar los niveles establecidos de seguridad TI?

En el caso de cambios que tengan un alto impacto, debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.

Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si éste ha de ser implementado aisladamente o dentro de un "paquete de cambios", que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:

  • Se optimizan los recursos necesarios.

  • Se evitan posibles incompatibilidades entre diferentes cambios.

  • Sólo se necesita un plan de back-out.

  • Se simplifica el proceso de actualización de la CMDB y la revisión post-implementac

 

Evaluación del cambio

Antes de proceder al cierre del cambio, es necesario verificar que ha sido positivo para el servicio, ya porque el nivel de calidad se ha visto aumentado o porque contribuye a mejorar la productividad de la organización. Aunque la Gestión de Cambios es la encargada de emitir el dictamen final, es la Evaluación del servicio la que ha de proporcionar a ésta los informes.

Los aspectos fundamentales a tener en cuenta son:

¿Se cumplieron los objetivos previstos?

¿En qué medida se apartó el proceso de las previsiones realizadas por la Gestión de Cambios?

¿Provocó el cambio problemas o interrupciones del servicio imprevistas?

¿Cuál ha sido la percepción de los usuarios respecto al cambio?

¿Se pusieron en marcha los planes de back-out en alguna fase del proceso?¿Por qué?

Si la evaluación final determina que el proceso y los resultados han sido satisfactorios, se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.

 

Cambios de emergencia

Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente, a veces resultan inevitables.

Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia.

El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:

  • La reunión urgente del CAB si esto fuera posible.

  • En ciertos casos en los que el número de integrantes o sus circunstancias hagan de ello algo inviable, puede ser necesario constituir un equipo específico, más reducido, que se denomina CAB de Emergencia (ECAB).

  • Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión del CAB e incluso del ECAB).

  • Como el objetivo prioritario en estos casos es restaurar el servicio, es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a posteriori.

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

 

Control del proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.

Para que estos informes ofrezcan una información precisa y de sencilla evaluación, es imprescindible elaborar métricas de referencia que cubran aspectos tales como:

RFCs solicitados.

Porcentaje de RFCs aceptados y aprobados.

Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.

Tiempo medio del cambio dependiendo del impacto y la prioridad.

Número de cambios de emergencia realizados.

Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.

Numero de back-outs con una detallada explicación de los mismos.

Evaluaciones post-implementación.

Porcentajes de cambios cerrados sin incidencias ulteriores.

Incidencias asociadas a cambios realizados.

Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.

 

El objetivo primordial de la Validación y Pruebas del Servicio consiste en garantizar que las nuevas versiones cumplen los requisitos mínimos de calidad acordados con el cliente y que, por supuesto, no van a provocar ningún error inesperado cuando estén operativas.

La Validación y Pruebas del Servicio se relaciona con los siguientes procesos del Ciclo de Vida:

  • La Gestión del Catálogo de Servicios envía a la Validación y Pruebas el Catálogo de Servicios Técnico, que incluye información detallada sobre modelo de servicio (servicios suministrados, soporte, activos que lo conforman, etc.).

  • La Gestión de Niveles de Servicio facilita los SLRs acordados con el cliente y las Hojas de Especificación, que recogen, desde un punto de vista más técnico, el nivel de calidad que debe cumplir la versión.

  • La Planificación y Soporte de la Transición y la Gestión de Cambios aportan tanto la estrategia general de Transición en el servicio como toda la documentación de la RFC particular (valoración de riesgos, recursos asociados).

  • La Gestión de Entregables y Despliegues proporciona la versión a testear propiamente dicha.

  • Una vez terminadas las sesiones de testeo, la Validación y Pruebas del Servicio ha de entregar los resultados de las mismas a la Evaluación para que elabore los informes de rendimiento que luego servirán a la Gestión de Cambios para tomar una decisión final.

  • La Validación y Pruebas del Servicio es la encargada de probar cada nueva versión en un entorno idéntico al real antes de proceder a su implantación. El objetivo último del proceso consiste en detectar y prevenir aquellos errores causados por incompatibilidades imprevistas, y verificar que se cumplen los niveles de utilidad y garantía establecidos.

Para cumplir este cometido, la Validación y Pruebas del Servicio se encarga de:

  • Diseñar y mantener un entorno de pruebas, es decir, una réplica exacta del escenario en el que el servicio desarrolla su actividad.

  • Conocer a fondo las funcionalidades del servicio y mantener listados actualizados de todos los casos de uso para poder hacer chequeos completos.

  • Conocer a fondo los requisitos de calidad del servicio acordados con el cliente para poder garantizar que las nuevas versiones los cumplen.

  • Planificar y llevar a cabo un calendario de pruebas que cubra todas las funcionalidades registradas para el servicio.

Los beneficios de una correcta Validación y Pruebas del Servicio se resumen en:

  • Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado.

  • Al haber menos incidentes, también se reduce significativamente el volumen de llamadas que llegan al Centro de Servicios.

  • Los problemas y errores conocidos pueden ser detectados, aislados y diagnosticados en el entorno de pruebas mucho mejor que en el entorno real.

  • Se ahorran costes, puesto que es mucho menos “caro” resolver errores en un entorno de pruebas que en uno real.

  • El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar, sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.

La Validación y Pruebas del Servicio puede encontrarse con las siguientes dificultades:

  • El Catálogo de Servicios Técnico omite algunas funcionalidades del servicio, ya sea por no estar suficientemente actualizado o por falta de detalle, por lo que la Validación y Pruebas del Servicio no las incluye en su plan de pruebas.

  • La Gestión de Entregas y Despliegues no actualiza con suficiente frecuencia su entorno de desarrollo, lo que deriva en la necesidad de efectuar varias pruebas previas hasta pulir la versión desde un punto de vista técnico antes de examinar su utilidad y garantía.

  • La Gestión de Entregas y Despliegues no conoce o a fondo los requisitos definidos en los SLRs y SLAs, por lo que son necesarias evaluaciones preliminares hasta alcanzar el nivel de rendimiento mínimo.

  • No se define suficiente con claridad la metodología a emplear durante las pruebas, o ésta se aparta demasiado de los SLRs acordados con el cliente, por lo que las pruebas resultan ser ineficaces.

 

Las principales actividades de la Validación y Pruebas del Servicio se resumen en:

 

 

 

04- Operación

 

La fase de Operación del Servicio es, sin duda, la más crítica entre todas. La percepción que los clientes y usuarios tengan de la calidad de los servicios prestados depende en última instancia de una correcta organización y coordinación de todos los agentes involucrados.

Todas las otras fases del Ciclo de Vida del Servicio tienen como objetivo último que los servicios sean correctamente prestados aportando el valor y la utilidad requerida por el cliente con los niveles de calidad acordados. Es evidente que de nada sirve una correcta estrategia, diseño y transición del servicio si falla la “entrega”.

Por otro lado es prácticamente imposible que la fase de Mejora Continua del Servicio sea capaz de ofrecer soluciones y cambios sin toda la información recopilada durante la fase de operación.

Los principales objetivos de la fase de Operación del Servicio incluyen:

  • Coordinar e implementar todos los procesos, actividades y funciones necesarias para la prestación de los servicios acordados con los niveles de calidad aprobados.

  • Dar soporte a todos los usuarios del servicio.

  • Gestionar la infraestructura tecnológica necesaria para la prestación del servicio.

  • Uno de los aspectos esenciales en la Operación del Servicio es la búsqueda de un equilibrio entre estabilidad y capacidad de respuesta.

  • La estabilidad es necesaria pues los clientes requieren disponibilidad y muestran resistencias al cambio. Por otro lado las necesidades de negocio cambian rápidamente y eso requiere habitualmente rapidez en las respuestas.

  • Normalmente los cambios correctamente planificados no tienen que afectar a la estabilidad del servicio pero esto requiere la colaboración de todos los agentes implicados en la Operación del Servicio que deben aportar el feedback necesario.

Para evitar los problemas de inestabilidad es conveniente adoptar una actitud proactiva que permita dar respuestas a las nuevas necesidades de negocio de una forma progresiva. La actitud reactiva provoca que los cambios sólo se implementen cuando la organización TI se ve obligada a responder a estímulos externos lo que usualmente provoca un estado de “urgencia” que no es conducente a una correcta planificación del cambio.

Es también esencial encontrar un correcto equilibrio entre los procesos de gestión internos orientados a gestionar y mantener la tecnología y recursos humanos necesarios para la prestación del servicio y las demandas externas de los clientes.

La organización TI no debe comprometerse en la prestación de servicios para los que carezca de capacidad tecnológica o los necesarios recursos humanos ni tampoco caer en el error de engordar en exceso la infraestructura TI encareciendo innecesariamente el coste de los servicios prestados.

Los principales procesos asociados directamente a la Fase de Operación del Servicio son:

  • Gestión de Eventos: responsable de monitorizar todos los eventos que acontezcan en la infraestructura TI con el objetivo de asegurar su correcto funcionamiento y ayudar a prever incidencias futuras.

  • Gestión de Incidencias: responsable de registrar todas las incidencias que afecten a la calidad del servicio y restaurarlo a los niveles acordados de calidad en el más breve plazo posible.

  • Petición de Servicios TI: responsable de gestionar las peticiones de usuarios y clientes que habitualmente requieren pequeños cambios en la prestación del servicio.

  • Gestión de Problemas: responsable de analizar y ofrecer soluciones a aquellos incidentes que por su frecuencia o impacto degradan la calidad del servicio

  • Gestión de Acceso a los Servicios TI: responsable de garantizar que sólo las personas con los permisos adecuados pueda acceder a la información de carácter restringido.

 

Una vez que el servicio está operando es necesario monitorizar todos los sucesos importantes que se produzcan para poder anticiparse a los problemas, resolverlos o incluso prevenirlos. Esta función representa una tarea en sí misma y por tanto constituye un proceso independiente dentro del ciclo de vida: la Gestión de Eventos.

A efectos de la operación del servicio, se denomina evento a todo suceso detectable que tiene importancia para la estructura de la organización TI, para la prestación de un servicio o para la evaluación del mismo. Ejemplos típicos de eventos son las notificaciones creadas por los servicios, los elementos de configuración o las herramientas de monitorización y control.

Un aspecto clave en la Gestión de Eventos es, como resulta evidente, una buena monitorización y unos efectivos sistemas de control. Encontramos dos tipos:

Herramientas de monitorización activa. Se comprueban los CIs uno a uno para verificar su estado y disponibilidad. Si detecta excepciones, la herramienta de monitorización genera una alerta y la envía al equipo o mecanismo de control asignado.

Herramientas de monitorización pasiva. Detectan y correlacionan alertas operacionales generadas por los propios CIs.

Los eventos no tienen por qué ser siempre negativos o extraordinarios, también pueden ser rutinarios. De hecho, podemos distinguir varios tipos de eventos dependiendo de su impacto:

Eventos que indican que el servicio está operando con normalidad.

Eventos que indican una excepción.

Eventos que indican una operación inusual pero no excepcional, y que requieren una monitorización exhaustiva.

La Gestión de Eventos, además de detectar y notificar los sucesos, se encarga de clasificarlos y dimensionar su impacto en el servicio. Llegado el caso, se ocupa también de documentar el evento y derivarlo al proceso correspondiente para que tome medidas:

A la Gestión de Incidencias, en caso de que el evento suponga una interrupción no planificada del servicio o fallos en uno o más CIs.

A la Gestión de Problemas, si una incidencia se repite a menudo y no se conoce la causa que la provoca.

Y también envía a la Gestión de Cambios, a través de la Mejora Continua del Servicio, nuevas solicitudes de cambio basadas en la correlación de eventos.

El principal objetivo de la Gestión de Eventos, en su función de monitorizar todos los sucesos importantes, consiste en detectar y escalar condiciones de excepción para así contribuir a una operación normal del servicio:

Proporcionando puntos de entrada para varios procesos de la fase de Operación (p. ej. Gestión de Incidencias).

Posibilitando la comparación entre el rendimiento real del servicio con los estándares de diseño y los SLAs.

Contribuyendo a la Mejora Continua del Servicio mediante informes de mejora.

Algunas de las ventajas que una correcta Gestión de Eventos aporta a la organización TI son:

  • Ayuda a la detección temprana de incidentes, llegando incluso a evitar que éstos se manifiesten a los usuarios.

  • Además, la coordinación directa con otros procesos hace posible que éstos reaccionen con mayor rapidez, resultando en una mayor eficiencia de toda la organización TI.

Posibilita la monitorización automatizada de determinadas actividades. Es más barata que una monitorización en tiempo real y disminuye considerablemente el periodo de inactividad del servicio que media entre la aparición del incidente y su resolución definitiva.

Proporciona la base para las operaciones automatizadas, que incrementan la eficiencia y descargan de trabajo a los recursos humanos que, así, pueden ser empleados en otras tareas como diseñar nuevas funcionalidades, etc.

Entre los principales desafíos que pueden obstaculizar la labor de la Gestión de Eventos encontramos:

  • Dificultades en la obtención de fondos para contratar las herramientas necesarias y el esfuerzo necesario para configurarlas y explotar sus beneficios.

  • Los niveles de filtrado no son adecuados, bien por exceso (se gestionan eventos sin impacto real en el servicio) o por defecto (algunos eventos de importancia no se detectan hasta que es demasiado tarde)

  • No existe suficiente compromiso con la Gestión de Eventos en otros procesos del ciclo de vida, ocasionando retrasos en la repuesta a los eventos.

  • Adquirir las habilidades necesarias exige tiempo y dinero.

 

Las actividades de la Gestión de Eventos son

  • Aparición de eventos. El proceso se inicia cuando ocurre el suceso, ya sea detectado o no.

  • Notificación de eventos. El evento es notificado al equipo o responsable de gestión.

  • Detección y filtrado de eventos. La notificación llega a un agente o herramienta de gestión que la lee e interpreta el suceso con el fin de determinar si merece mayor atención o no.

  • Clasificación de eventos. Se le asigna una categoría y un nivel de prioridad.

  • Correlación. Se analiza si existen eventos similares, así como la importancia del evento en sí mismo y se decide si es necesario tomar medidas.

  • Disparadores. Se ponen en marcha los mecanismos necesarios para dar respuesta al evento.

  • Opciones de respuesta. Se eligen las soluciones a adoptar.

  • Revisión de acciones y cierre. Se revisan las excepciones o eventos importantes para determinar si se han tratado correctamente. Se cierra el proceso de Gestión de Eventos.

 

Aparición de eventos

El flujo de trabajo del proceso de Gestión de Eventos se inicia cuando aparece un evento. Los eventos ocurren continuamente, pero no todos son detectados o registrados.

Por ello, es importante que todos los implicados en el diseño, desarrollo, gestión y soporte de los servicios IT y la infraestructura IT comprendan cuáles son los eventos que es preciso detectar.

Notificación de eventos

La mayoría de los elementos de configuración (CIs) son diseñados para comunicar información sobre sí mismos de las siguientes formas:

Una herramienta de gestión demanda periódicamente determinados datos a un dispositivo del CI.

El propio CI genera un informe al darse unas determinadas condiciones definidas previamente.

Las notificaciones de eventos pueden estar registradas en un formato propietario, aunque la mayoría de los CIs emplean el estándar SNMP (Simple Network Management Protocol).

En general, cuanta más información acerca del evento quede recogida en la notificación, y cuanto mejor se determine el destinatario de dicha información, más fácil resultará tomar decisiones respecto al mismo. A menudo, se registran mensajes de error codificados y el personal encargado de resolver los problemas no alcanza a comprender su significado completo.

Si los roles y responsabilidades no han sido bien definidos desde la fase de Diseño, es muy probable que cuando se presente un evento que requiera una respuesta, nadie sepa quién está haciendo qué. En tal caso, hay que redactar una RFC.

 

Detección y filtrado de eventos

Una vez generada la notificación, ésta llega a su destinatario, que puede ser un agente que trabaje sobre el sistema o bien una herramienta de gestión diseñada específicamente para recibir los datos relacionados con el evento e interpretarlos.

El filtrado consiste en decidir si el suceso merece una consideración en profundidad por parte de otra unidad de gestión o si por el contrario, una vez leído puede ser ignorado. Por ejemplo, cuando se trata de un grupo de notificaciones relacionadas que se emiten de forma seriada, es habitual optar por transmitir sólo la primera.

En otros CIs, en cambio, todos los eventos son significativos y se trasladan directamente a un sistema de correlación automatizado, incluso aunque la notificación esté duplicada.

 

Clasificación de eventos

No todos los eventos son iguales ya que no tienen la misma importancia para el servicio ni la infraestructura TI y por tanto, no deben tratarse de la misma manera.

La mejor manera de asignar distintas prioridades a cada evento, pero que al mismo tiempo guarden cierta coherencia, es confeccionar una clasificación de eventos. Lo más habitual es que cada organización TI disponga de su propia categorización, ya que es lo más eficaz. Sin embargo, existen tres categorías que no pueden faltar:

Informativo. Se asigna a aquellos eventos que no requieren, en principio, ninguna respuesta y que por tanto no representan una excepción.

Alerta. Se asigna a aquellos eventos que indican que el servicio se aproxima a un umbral. Su objetivo es notificar a las personas, herramientas o procesos apropiados para que revisen la situación y tomen las medidas necesarias para evitar que se produzca una excepción.

Excepción. Se asigna a los eventos cuando indican que el servicio está operando de manera irregular: los SLAs y OLAs se han incumplido, etc. Las excepciones pueden representar un fallo total, un cese en una funcionalidad o una disminución del rendimiento. Sin embargo, no tienen por qué ser errores.

 

Correlación

La Correlación consiste en dimensionar la importancia del evento y, si se diera el caso, establecer conexiones con otros eventos relacionados para ahorrar tiempo. La importancia y significado del evento en sí mismo depende de los siguientes factores:

Número de eventos similares registrados con anterioridad.

Número de elementos de configuración (CIs) que generan eventos similares.

Si existe alguna acción asociada al evento.

Si el evento representa una excepción.

Comparación de la cantidad de información utilizada en el evento respecto a un estándar.

Si se requieren datos adicionales para investigar el evento con posterioridad o incluso datos procedentes de otros sistemas de información.

Categorización asignada al evento.

Nivel de prioridad asignado al evento.

 

Disparadores

Una vez que la Correlación ha reconocido la importancia de un evento, es preciso poner en marcha los mecanismos pertinentes para que se produzca una respuesta desde dentro de la organización TI. A este mecanismo, que sirve como desencadenante de una tarea o serie de tareas, lo denominamos “disparador”.

Existen varios tipos de disparadores:

Disparadores de Incidentes. Crean un registro en el Sistema de Gestión de Incidencias, generando un input para este proceso de la fase de Operación.

Disparadores de Cambios. Generan una solicitud de cambio (RFC) y enviándola a la Gestión de Cambios, en la fase de Transición.

Disparadores procedentes de una RFC aprobada o desautorizada. Se envía toda la información relacionada para que la Gestión de Cambios investigue lo ocurrido.

Scripts automatizados que ejecutan acciones específicas (p. ej. reiniciar un equipo).

Notificaciones por teléfono móvil.

Disparadores de base de datos, que restringen el acceso de un usuario a determinados registros o campos, o que crean/eliminan entradas en la base de datos.

 

 

La Gestión de Incidencias tiene como objetivo resolver, de la manera más rápida y eficaz posible, cualquier incidente que cause una interrupción en el servicio.

La Gestión de Incidencias no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

Por otro lado, también es importante diferenciar la Gestión de Incidencias de la Gestión de Peticiones, que se ocupa de las diversas solicitudes que los usuarios plantean para mejorar el servicio, no cuando éste falla.

 

Los objetivos principales de la Gestión de Incidencias son:

  • Detectar cualquier 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 Serviciosdebe jugar un papel esencial en el mismo.

  • Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, a excepción las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc.

  • Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el Inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidencias incluyen:

  • Mejorar la productividad de los usuarios.

  • Cumplimiento de los niveles de servicio acordados en el SLA.

  • Mayor control de los procesos y monitorización del servicio.

  • Optimización de los recursos disponibles.

  • Una CMDB más precisa, pues se registran los incidentes en relación con los elementos de configuración.

  • Y principalmente: mejora la satisfacción general de clientes y usuarios.

Por otro lado una incorrecta Gestión de Incidencias puede acarrear efectos adversos tales como:

  • Reducción de los niveles de servicio.

  • Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución de la incidencia.

  • Se pierde valiosa información sobre las causas y efectos de las incidencias para futuras reestructuraciones y evoluciones.

  • Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidencias.

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

  • No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.

  • No existe un margen operativo que permita gestionar los “picos” de incidencias, por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.

 

 

Escalado y Soporte

Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado.

Básicamente hay dos tipos de escalado:

  • Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver la incidencia.

  • Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapan de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.

El proceso de escalado puede resumirse gráficamente* como sigue:

 

 

Aprobación financiera

La mayoría de las peticiones conllevan un gasto, independientemente de los acuerdos financieros en vigor. Por eso, antes de autorizar una petición es principal determinar primero los costes que ésta acarreará de ser cursada.

Se pueden definir, para determinadas peticiones estándares, unos precios fijos que ayuden a gestionar con rapidez aquellos casos más frecuentes.

Las funciones principales de la Gestión de Problemas son:

  • Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.

  • Determinar posibles soluciones a las mismas.

  • Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.

  • Realizar Revisiones Post-Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.

La Gestión de Problemas puede ser:

  • Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.

  • Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que éstos ocurran.

 

 

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

  • 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 que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.

  • Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que éstos se manifiesten provocando un deterioro en la calidad del servicio.

  • Control de Problemas

  • El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.

 

 

Las actividades de la Gestión de Acceso a los Servicios TI incluyen:

  • Petición de acceso, que puede llegar por distintas vías como el departamento de RRHH, una solicitud de cambio, una instrucción autorizada…

  • Verificación. Se comprueba la identidad del usuario que solicita el acceso, así como de aquellos que lo autorizan. También se examina si los motivos para otorgar el acceso son pertinentes.

  • Monitorización de identidad. Los cambios en la asignación de permisos suelen estar asociados a un cambio de estatus dentro de la organización: ascensos, despidos, jubilaciones…

  • Registro y monitorización de accesos. La Gestión de Accesos es responsable de asegurar que los permisos que ha otorgado se están usando apropiadamente.

  • Eliminación y restricción de derechos. En algunos casos, los derechos pueden ser eliminados por completo: fallecimiento, dimisión, despido, traslados…

 

Una función es una unidad especializada en la realización de una cierta actividad y es la responsable de su resultado. Las funciones incorporan todos los recursos y capacidades necesarias para el correcto desarrollo de dicha actividad.

Las funciones involucradas en la fase de Operación del servicio son las responsables de que los servicios cumplan los objetivos solicitados por los clientes y de gestionar toda la tecnología necesaria para la prestación de dichos servicios:

  • Centro de Servicios: responsable de todo los procesos de interacción con los usuarios de los servicios TI.

  • Gestión de Operaciones TI: responsable de la operación diaria del servicio.

  • Gestión Técnica: es una unidad funcional que incluye a todos los equipos, grupos y departamentos involucrados en la gestión y soporte de la infraestructura TI.

  • Gestión de Aplicaciones: esta unidad funcional es la responsable de la gestión del ciclo de vida de la aplicaciones TI

 

 

05 -Mejora

Mejora Continua del Servicio

Pero este objetivo de mejora sólo se puede alcanzar mediante la continua monitorización y medición de todas las actividades y procesos involucrados en la prestación de los servicios TI:

  • Conformidad: los procesos se adecúan a los nuevos modelos y protocolos.

  • Calidad: se cumplen los objetivos preestablecidos en plazo y forma.

  • Rendimiento: los procesos son eficientes y rentables para la organización TI.

  • Valor: los servicios ofrecen el valor esperado y se diferencian de los de la competencia.

Los principales objetivos de la fase de Mejora Continua del servicio se resumen en:

  • Recomendar mejoras para todos los procesos y actividades involucrados en la gestión y prestación de los servicios TI.

  • Monitorizar y analizar los parámetros de seguimiento de Niveles de Servicio y contrastarlos con los SLAs en vigor.

  • Proponer mejoras que aumenten el ROI y VOI asociados a los servicios TI.

  • Dar soporte a la fase de estrategia y diseño para la definición de nuevos servicios y procesos/ actividades asociados a los mismos.

Los resultados de esta fase del ciclo de vida han de verse reflejados en Planes de Mejora del Servicio que incorporen toda la información necesaria para:

  • Mejorar la calidad de los servicios prestados.

  • Incorporar nuevos servicios que se adapten mejor a los requisitos de los clientes y el mercado.

  • Mejorar y hacer más eficientes los procesos internos de la organización TI.

 

Los principales procesos asociados directamente a la fase de Mejora del Servicio son:

  • Proceso de Mejora: este es un proceso que consta de 7 pasos que describen como se deben medir la calidad y rendimiento de los procesos para generar los informes adecuados que permitan la creación de un Plan de Mejora del Servicio (SIP).

  • Informes de Servicios TI: es el responsable de la generación de los informes que permitan evaluar los servicios ofrecidos y los resultados de las mejoras propuestas.

 

 

Las principales actividades del Proceso de Mejora Continua se resumen en:

 

Qué medir

Es imposible iniciar el proceso de Mejora Continua sin una idea clara de que es aquello que, en principio, debemos mejorar. Luego, en primera lugar, debemos conocer en profundidad la misión y estrategia previamente trazados por los máximos responsables de la organización TI de acuerdo con las necesidades de negocio.

A partir de esa información y de la recogida a través de:

El catalogo actual de servicios,

Los SLAs en vigor: compromisos alcanzados con nuestros clientes,

Los SLRs: peticiones y requisitos expresados para que los servicios se adecúen a las necesidades del negocio,

Información de carácter legal y financiero,

debemos determinar aquello que se debe medir así como los CSFs y KPIs correspondientes. 

En todo este proceso es necesaria la colaboración de los propietarios del servicio que conocen en profundidad las actividades necesarias para la prestación de los servicios y los procesos de gestión asociados.

 

Qué se puede medir

Cuando ya dispongamos de una lista de todo aquello que deseamos medir es necesario asegurarse que nuestros objetivos son realistas.

En algunos casos puede ocurrir, ya sea porque no se dispone de las herramientas necesarias o simplemente porque la organización carece del grado de madurez necesario, que no se puedan implementar, con una mínima garantía de éxito, ciertas métricas.

Para limitar los procesos de medida a aquellos realmente asequibles a la organización TI es necesario tener en cuenta los:

  • Procesos de medida ya existentes.

  • Informes generados.

  • Flujos de trabajo establecidos.

  • Protocolos y procedimientos en vigor.

  • Tras el análisis de la situación debe generarse:

  • Una lista de definitiva de métricas, CSFs y KPIs a implementar

  • Un informe con los requisitos necesarios (recursos y capacidades) para llevar a cabo las mediciones propuestas.

Es importante tener en cuenta a la hora de alcanzar un compromiso sobre lo que realmente se va a medir cuáles son los riesgos de ignorar ciertas métricas:

¿Se puede resentir gravemente la calidad de los servicios prestados?

¿Se puede ver seriamente afectado el rendimiento de algún proceso?

Por otro lado sólo aquello que sea finalmente medible debe incorporarse a los SLAs.

Recopilación de datos

Una vez decidido lo qué se va a medir hay que decidir cómo y ponerse manos a la obra.

Aunque muchas de las mediciones se pueden realizar de forma automática monitorizando la actividad de la organización TI en algunos casos esto no es posible, por ejemplo, en lo que respecta a la calidad de los informes emitidos, el cumplimiento de ciertos protocolos, etcétera.

Es importante que cada proceso de medición tenga claramente asignada la persona responsable del mismo, que ésta disponga de las herramientas automáticas necesarias y se haya definido claramente el procedimiento.

Las actividades habituales en el proceso de medición incluyen:

  • Definición del calendario o frecuencia de toma de datos (en el caso automático este proceso puede ser continuo).

  • Análisis de las herramientas necesarias para el proceso de medición y registro.

  • Instalación, configuración, personalización y pruebas de funcionamiento de dichas herramientas.

  • Analizar la disponibilidad y capacidad de la infraestructura necesaria.

  • Monitorizar la calidad y adecuación al propósito de los datos recogidos: establecer métricas.

  • Preparar los datos para que sean accesibles y útiles.

  • Documentar todo el proceso.

 

 

Informes de Servicios TI

Visión general

Es imposible realizar proyecciones, establecer estrategias y proponer mejoras si se desconoce el estado actual de las cosas. El proceso de Gestión de Informes tiene como principal objetivo proporcionar a todos los agentes implicados en la gestión de los servicios TI una visión objetiva, basada en datos y métricas, de la calidad y rendimiento de los servicios prestados.

Este proceso tiene como input los datos recopilados a través de toda la organización TI y ofrece como output una serie de informes que aporten el conocimiento necesario para implementar mejoras funcionales, estructurales o para el negocio.

Por su naturaleza este proceso requiere la estrecha colaboración de los otros procesos pues sin ésta se carecerá del adecuado punto de partida para determinar qué datos deben ser registrados, procesados, analizados y posteriormente “digeridos” y presentados como informes.

El objetivo principal de la Gestión de Informes consiste en mantener puntualmente informados a los responsables y personal de la organización TI sobre la calidad, rendimiento de los actuales servicios TI y desarrollos realizados o planificados cara al futuro.

La Gestión de Informes es esencial para:

  • Garantizar que todos los responsables de la gestión de procesos TI disponen del conocimiento necesario para tomar decisiones informadas.

  • Se dispone de todas las métricas necesarias para evaluar de forma global la calidad de los servicios prestados.

  • Crear un marco unificado para la generación y difusión de informes que simplifique el acceso a la información.

  • Los beneficios de una correcta gestión de este proceso se resumen en:

  • Ofrecer al conjunto de la organización TI una instantánea periódica sobre el estado de los servicios TI prestados.

  • Facilitar la toma de decisiones estratégicas en base a información objetiva.

  • Comunicar la percepción de los clientes y usuarios sobre la calidad de los servicios ofrecidos.

  • Las principales dificultades a las que se enfrenta la gestión de Generación de Informes incluyen:

  • No están bien delimitadas las responsabilidades de cada uno de los agentes implicados.

  • La recogida de datos no se realiza correctamente o la calidad de los datos es deficiente.

  • Los informes generados son meramente técnicos y apenas aportan “inteligencia” al negocio.

  • La presentación de los informes no se adecua a su público objetivo: insuficiente información gráfica, lenguaje excesivamente técnico, falta de precisión…

Las principales actividades de la Gestión de Informes de servicios TI se resumen en:

 

https://lhconsultingroup.com/