¿Qué es ITIL v3?

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 TI ofrecidos, evitar los problemas asociados a los mismos y en caso de que estos ocurran ofrecer un marco de actuación para que estos sean solucionados con el menor impacto y a la mayor brevedad posible. Sus orígenes se remontan a la década de los 80 cuando el gobierno británico, preocupado por la calidad de los servicios TI de los que dependía la administración, solicito a una de sus agencias, la CCTA acrónimo de Central Computer and Telecommunications Agency, para que desarrollara un estándar para la provisión eficiente de servicios TI. En la actualidad es la OGC (Office of Government Commerce) el organismo encargado de velar por este estándar y la responsable de la última versión de ITIL (v3) que data del año 2007. La OGC cuenta con la colaboración de varias organizaciones para el mantenimiento de ITIL:

itSMF: el Information Technology Management Forum es una organización independiente y reconocida internacionalmente que tiene como principal objetivo impulsar la adopción de las mejores prácticas ITIL para la gestión de servicios TI. APM Group: es una organización comercial encargada por la OGC de definir, publicar y gestionar las certificaciones ITIL así como de acreditar a los organismos examinadores. Organismos examinadores: en la actualidad existen varios organismos examinadores acreditados por APMG entre los que se encuentran EXIN, BCS/ISEB y LCS.

Gestión de servicios TI Aunque todos tengamos una idea intuitivamente clara del concepto de servicio es difícil proponer una única y sucinta definición del mismo. ITIL nos ofrece la siguiente definición: Un servicio es un medio para entregar valor a los clientes facilitándoles un resultado deseado sin la necesidad de que estos asuman los costes y riesgos específicos asociados. En otras palabras, 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 (limpiadores, productos de limpieza, etcétera) 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.

Es obvio que optar por otra opción dependerá de las circunstancias de cada empresa: su tamaño, estructura, etcétera. Sin embargo, la tendencia actual es a subcontratar todos aquellos servicios que se alejen de la actividad principal de la empresa. Un aspecto importante a destacar es que aún en el caso de que se adoptara la decisión de realizar las tareas de limpieza por personal de la empresa estas podrían ser ofrecidas por un “proveedor interno” siempre que las funciones y procesos involucrados se estructurarán consecuentemente. En cualquier caso 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 …

El objetivo de ITIL es precisamente ofrecer tanto a los proveedores como receptores de servicios TI de un marco que facilite todas estas tareas y procesos. ITIL define la Gestión de Servicios como un conjunto de capacidades organizativas especializadas 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 proveedor debe garantizar la coordinación entre los recursos y capacidades de ambos. 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. Estos deben de actuar siguiendo las indicaciones del cliente y protegiendo los intereses del cliente, los usuarios y los suyos propios. Los agentes pueden ser empleados del proveedor de servicios o incluso interfaces de interacción con el usuario en sistema gestionados automáticamente. 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. La encapsulación se consigue a través de la:

o

Separación de conceptos complejos se en diferentes partes independientes que pueden ser tratadas independientemente. Modularidad que permite agrupar funcionalidades similares en forma de módulos autocontenidos. 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.

o

o

Sistemas: según ITIL los 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:
o o

Procesos de control Feedback y aprendizaje

Gobierno TI Aunque no existe una única y universalmente adoptada definición de Gobierno TI sí existe un consenso general sobre la importancia de disponer de un marco general de referencia para la dirección, administración y control de las infraestructuras y servicios TI. Aunque ITIL es a veces considerado como un marco para el Gobierno TI sus objetivos son más modestos pues se limitan exclusivamente a aspectos de gestión. Para aclarar las diferencias quizá sea conveniente remitirnos a un ejemplo que se aparta del entorno de las TI y del que todos somos buenos conocedores: gobierno versus administración pública. El gobierno es el responsable de establecer políticas y directrices de actuación que recojan las inquietudes y cubran las necesidades de los ciudadanos. Las administraciones públicas son las encargadas de asegurar que esas políticas se implementen, ofreciendo los servicios correspondientes, asegurando el cumplimiento de las normas establecidas, prestando apoyo, recogiendo reclamaciones y propuestas, etcétera. ITIL sería en este caso el equivalente TI de un conjunto de buenas prácticas para la administración del estado pero no para su gobierno (aunque algunas veces las fronteras entre ambos no estén claramente delimitadas). Es evidente la dificultad de establecer un conjunto de buenas prácticas para el buen gobierno, sin embargo, estas existen de hecho y ejemplo de ello son la Declaración Universal de Derechos Humanos y todo el corpus del derecho internacional.

El Gobierno TI es parte integrante del Gobierno Corporativo y como tal debe centrarse en las implicaciones que los servicios e infraestructura TI tienen en el futuro y sostenibilidad de la empresa asegurando su alineación con los objetivos estratégicos. La creciente importancia de los servicios TI para las empresas nos hace creer que todos los aspectos relacionados con el Gobierno TI serán un hot topic en los próximos años y que se realizarán importantes desarrollos en este terreno.

El ciclo de vida de los servicios TI ITIL v3 estructura la gestión de los servicios TI sobre el concepto de Ciclo de Vida de los Servicios. Este enfoque 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 involucrados en la eficiente prestación del mismo. El Ciclo de Vida del Servicio consta de cinco fases que se corresponden con los nuevos libros de ITIL: 1. Estrategia del Servicio: propone tratar la gestión de servicios no sólo como una capacidad sino como un activo estratégico. 2. Diseño del Servicio: cubre los principios y métodos necesarios para transformar los objetivos estratégicos en portafolios de servicios y activos. 3. Transición del Servicio: cubre el proceso de transición para la implementación de nuevos servicios o su mejora. 4. 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. 5. Mejora Continua del Servicio: proporciona una guía para la creación y mantenimiento del valor ofrecido a los clientes a traces de un diseño, transición y operación del servicio optimizado.

Las funciones tienen como principal objetivo dotar a las organizaciones de una estructura acorde con el principio de especialización. Las funciones incorporan todos los recursos y capacidades necesarias para el correcto desarrollo de dicha actividad. Un proceso es un conjunto de actividades interrelacionadas orientadas a cumplir un objetivo específico.Estos libros no son departamentos estancos e ITIL tiene en cuenta las múltiples interrelaciones entre ellos y como estas afectan a los aspectos globales de todo el ciclo de vida del servicio. Tienen resultados específicos. Los procesos comparten las siguientes características:    Los procesos son cuantificables y se basan en el rendimiento. Funciones. procesos y roles ITIL marca una clara distinción entre funciones y procesos. Los procesos tienen un cliente final que es el receptor de dicho resultado. Estos cinco libros ofrecen una guía práctica sobre como estructurar la Gestión de Servicios TI de forma que estos estén correctamente alineados con los procesos de negocio. . En este último caso un modelo organizativo basado en procesos puede ayudar a mejorar la productividad de la organización en su conjunto. Una función es una unidad especializada en la realización de una cierta actividad y es la responsable de su resultado. Sin embargo la falta de coordinación entre funciones puede resultar en la creación de nichos contraproducentes para el rendimiento de la organización como un todo.

evaluación y eventual mejora. organización. a qué clientes y en qué mercados. Los viejos conceptos de Provisión y Soporte al Servicio han sido transmutados en las cinco fases siguientes. Otro concepto ampliamente utilizado es el de rol. Debe estar involucrado en su fase de diseño. monitorización y evaluación. Propietario del Proceso: es el último responsable frente a la organización TI de que el proceso cumple sus objetivos. El Centro de Servicios y la Gestión del Cambio son dos claros ejemplos de función y proceso respectivamente. Un rol es un conjunto de actividades y responsabilidades asignada a una persona o un grupo. asegurando que cumplen los requisitos de los clientes y se adecuan a la estrategia predefinida. Una persona o grupo puede desempeñar simultáneamente más de un rol. Gestor del Proceso: es el responsable de la gestión de toda la operativa asociada a un proceso en particular: planificación. El Ciclo de Vida del Servicio se compone de cinco fases que se retroalimentan entre ellas de una manera cíclica. Propietario del Servicio: es el último responsable cara al cliente y a la organización TI de la prestación de un servicio específico. Se inician como respuesta a un evento.  . implementación. Hay cuatro roles genéricos que juegan un papel especialmente importante 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. que se retroalimentan entre ellas de una manera cíclica:  Estrategia del Servicio: cuyo propósito es definir qué servicios se prestarán. Sin embargo. implementación y cambio asegurando en todo momento que se dispone de las métricas necesarias para su correcta monitorización. en la vida real la dicotomía entre funciones y procesos no siempre es tan evidente pues puede depender de la estructura organizativa de la empresa u organismo en cuestión. mantenimiento. Diseño del Servicio: responsable de desarrollar nuevos servicios o modificar los ya existentes.    Apéndice: de ITIL v2 a ITIL v3 La principal diferencia entre las versiones v2 y v3 de ITIL es que esta última versión basa su estructura sobre el concepto de Ciclo de Vida de los Servicios. monitorización y generación de informes.

la relación de éstos con las distintas fases del Ciclo de Vida no es tan rígida como lo era con el enfoque de Provisión y Soporte al Servicio deITIL v2. ITIL v3 no sólo supone un cambio de perspectiva sino que propone una visión mucho más integral y conceptualmente detallada de todos los aspectos involucrados en la Gestión de los Servicios y sus procesos asociados. Mejora Continua del Servicio: a partir de los datos y experiencia acumulados propone mecanismos de mejora del servicio.   Sin embargo. Aunque ITIL v3 continúa orientada a procesos. Un ejemplo de función en el marco de ITIL v2 viene dado por el Centro de Servicios o Service Desk. Transición del Servicio: encargada de la puesta en operación de los servicios previamente diseñados. incluida la atención al cliente. ITIL v3 también introduce como elemento básico el concepto de «función». En el siguiente diagrama se muestran las fases del Ciclo de Vida con sus procesos y funciones más destacados: . Operación del Servicio: responsables de todas las tareas operativas y de mantenimiento del servicio. que puede ser brevemente definida como «una unidad especializada en la realización de una cierta actividad y que es la responsable de su resultado».

los servicios retirados y los servicios en preparación. En ITIL v2 formaba parte de la Gestión de Niveles de Servicio de los proveedores. incluyendo el Catálogo de Servicios prestados.  Diseño del Servicio o Gestión del Catálogo de Servicios: anteriormente un subproceso de la Gestión de Niveles de Servicio. Gestión de los Proveedores: su principal objetivo es obtener de los proveedores un alto nivel de calidad en su servicio a un precio asequible y adecuado al mercado. es propio de ITILv3.Cabe destacar las siguientes principales diferencias en los procesos definidos para ITIL v3:  Estrategia del Servicio o Gestión del Portfolio de Servicios: este proceso encargado de la definición de la cartera o Portfolio de Servicios. o . es un nuevo proceso en ITIL v3 responsable del diseño de un Catálogo de Servicios enfocado a las necesidades de los clientes.

Gestión de la Configuración y Activos del Servicio: Amplía la Gestión de la Configuración de ITIL v2 para incorporar activos no TI. encargándose de gestionar las peticiones de cambio solicitadas por los clientes. por ejemplo. o o o  Operación del Servicio o Gestión de Peticiones: se desgaja en ITIL v3 de la Gestión de Incidencias. Validación y Pruebas del Servicio: Este proceso se desgaja en ITIL v3 de la Gestión de Versiones o Gestión del despliegue del Servicio para asegurar que se realizan todas las pruebas para validar el servicio como «adecuado en uso y propósito». Gestión de Aplicaciones: responsable de la gestión de las aplicaciones de software durante todo su ciclo de vida. En ITIL v3 se ha convertido en un proceso por derecho propio. el rendimiento y otros parámetros de interés asociados al servicio. Evaluación: exclusivo de ITIL v3. en ITIL v3 es la encargada de monitorizar el rendimiento de la infraestructura TI para la prevención de errores o interrupciones en el servicio. como. En ITIL v2 formaba parte de la Gestión de la Seguridad y se encarga de gestionar los permisos de acceso a los diferentes usuarios de un servicio.o Gestión de la Seguridad TI: en ITIL v2 se trataba por separado en un libro específico al respecto  Transición del Servicio o Gestión del Conocimiento: este proceso se hallaba subdividido en varios procesos en ITIL v2. mediante la base de datos de errores conocidos en la Gestión de Problemas.    Mejora Continua del Servicio . Gestión Técnica: responsable del soporte técnico a todos los agentes implicados en la Gestión del Servicio. este proceso genérico se ocupa de verificar la relación calidad/precio. Además del Centro de Servicios ITIL v3 introduce nuevas funciones:  o o o Gestión de Operaciones TI: responsable del mantenimiento de la infraestructura TI. Gestión de Eventos: nueva. como tal. Gestión de Accesos: es un nuevo proceso en ITIL v3.

Informes de servicio: genera los informes sobre rendimiento. Crear casos de negocio para justificar inversiones estratégicas. resultado y calidad de los servicios ofrecidos. Proponer servicios diferenciados que aporten valor añadido al cliente. Gestionar los recursos y capacidades necesarios para prestar los servicios ofrecidos teniendo en cuenta los costes y riesgos asociados. Armonizar la oferta con la demanda de servicios.    La fase de Estrategia del Servicio es el eje que permite que las fases de Diseño. Para conseguir este objetivo es imprescindible determinar en primera instancia qué servicios deben ser prestados y por qué han de ser prestados desde la perspectiva del cliente y el mercado. Alinear los servicios ofrecidos con la estrategia de negocio. o o Estrategia de los Servicios TI Ver Flash / Demo de la fase La fase de Estrategia del Servicio es central al concepto de Ciclo de vida del servicio y tiene como principal objetivo convertir la Gestión del Servicio en un activo estratégico.o Sus actividades estaban subsumidas por la Gestión de Niveles de Servicio enITIL v2. en particular. Proceso de Mejora CSI: establece los protocolos de monitorización. Una correcta Estrategia del Servicio debe:      Servir de guía a la hora de establecer y priorizar objetivos y oportunidades. la responsable de generar los Planes de Mejora del Servicio (SIP). Transición yOperación del servicio se ajusten a las políticas y visión estratégica del negocio. Conocer el mercado y los servicios de la competencia. Elaborar planes que permitan un crecimiento sostenible. seguimiento y generación de informes y es. 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? .

una inferior calidad. la garantía del proveedor que asegura que el servicio se prestará de forma continuada preservando los niveles de calidad acordados. y en la negativo aspectos tales como:     la pérdida de control de todo el proceso. Pero el valor al que nos referimos no depende exclusivamente del valor económico asociado al resultado específico de cada servicio. “caer cautivo” en manos de un proveedor de servicios .       ¿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 Los servicios son definidos en ITIL como un medio de aportar valor al cliente sin que éste deba asumir los riesgos y costes específicos de su prestación. En el lado positivo de la ecuación cuentan:   la utilidad ofrecida que debe adaptarse a las necesidades reales del cliente. En nuestro caso el valor incluye algunos otros intangibles entre los que se incluye la percepción del cliente. costes ocultos.

La garantía presupone que el servicio:     estará disponible cuando se le necesite estará correctamente dimensionado para cumplir sus objetivos sea seguro dispondrá de mecanismos de respaldo que permitirán su continuidad Un servicio. por ejemplo. Activos del servicio Para que una organización TI pueda ofrecer valor en forma de servicios debe hacer buen uso de sus recursos y capacidades. aumente el rendimiento y debe resultar en un beneficio para el cliente. puede ofrecer una interesante utilidad a buen precio pero si el cliente percibe una alta sensación de riesgo no lo contratará. bien disminuyendo directamente los costes o contribuyendo a aumentar los ingresos. . La utilidad y garantía de un servicio son con frecuencia interdependientes y a la hora de concebir un nuevo servicio la organización TI debe buscar un equilibrio entre ambas minimizando a su vez los aspectos que los potenciales clientes puedan percibir negativamente.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. La utilidad requiere que el servicio:   cumpla los requisitos del cliente.

un servicio de consultoría TI dependerá principalmente de la información y el conocimiento para aportar valor al cliente en forma de “know how”.Los recursos son la “materia prima” necesaria para la prestación del servicio e incluyen el capital. Proveedores de servicios 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 . aplicaciones e información. A modo de ejemplo. Las capacidades representan las habilidades desarrolladas a lo largo del tiempo para transformar los recursos en valor a través de la gestión. creatividad y capacidad de liderazgo. los procesos y el conocimiento. Por lo tanto la organización TI debe buscar el adecuado equilibrio entre ambos para aportar el máximo valor al cliente en forma de servicios. Y en la base de ambos se encuentra el personal que es en sí mismo un recurso que aporta entre otras capacidades su profesionalidad. las infraestructuras. Sin la información necesaria ni los conocimientos acumulados mediante la experiencia del personal que prestará el servicio los resultados no aportaran el valor buscado por el cliente. Las capacidades son por sí solas incapaces de crear valor a falta de los adecuados recursos y estos últimos serían infrautilizados en caso de carecer de las correspondientes capacidades. la organización.

Mayores opciones de crecimiento Y entre las desventajas se incluyen:   Asumir actividades que no aportan ventajas competitivas a la organización. Concentración de costes y riesgos Unidades de Servicio Compartidas (Tipo II) Este tipo de proveedor presta servicio a diferentes unidades de negocio que operan bajo un paraguas común. . Posibles conflictos de intereses entre diferentes unidades de negocio. Las ventajas de esta opción se resumen en:    Mayor control sobre los servicios prestados. Cada tipo de proveedor de servicios tiene sus ventajas e inconvenientes que pasamos a analizar. Organizaciones más endogámicas y menos flexibles. Estandarización de procesos. Proveedores de Servicios Interno (Tipo I) Esta opción sólo es recomendable cuando los servicios prestados forman parte esencial en el posicionamiento estratégico de la organización. Las ventajas de esta opción se resumen en:     Se comparten costes y riesgos entre diferentes unidades. Posicionamiento más competitivo frente a proveedores externos. Proveedores de Servicios Externo (Tipo III) Estos proveedores ofrecen sus servicios en el mercado a diferentes clientes que frecuentemente serán competidores entre sí. Comunicación directa. Mayores niveles de personalización.Aunque los aspectos generales de la gestión del servicio son comunes a todos ellos existen obvias diferencias en los aspectos organizativos en cada caso. En el lado opuesto de la balanza cabe destacar:     Los recursos pueden no estar optimizados. Dificultad a la hora de incrementar las capacidades.

Sin embargo los modelos lineales no son capaces de modelar los procesos y actividades necesarias para la correcta gestión de un servicio TI. Entre las desventajas se cuentan:   Altos niveles de personalización de los servicios pueden resultar costosos. siempre que estos no formen parte integrante del núcleo del negocio del cliente. . Se minimizan los riesgos pues estos son compartidos entre una amplia red de clientes. se resumen en:    Mayor flexibilidad y oferta.Las ventajas de la contratación externa de los servicios son evidentes. Redes de valor ITIL generaliza el concepto de cadena de valor al de red de valor que se adecua mucho mejor al caso de los servicios TI. Aunque el modelo de cadena de valor puede seguir siendo útil en el análisis de ciertos casosITIL ha extendido el concepto para abarcar redes de valor que se definen como redes de relaciones que generan valor a través de complejas interdependencias que pueden implicar a múltiples organizaciones. El cliente puede caer cautivo de un proveedor externo. Procedimientos estandarizados. 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.

Patrón: mantener una coherencia en la toma de decisiones y acciones adoptadas. Posición: definir y diferenciar nuestros servicios.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 Las 4 Ps de Mintzberg ofrecen un punto de partida adecuado para definir la Estrategia del Servicio:     Perspectiva: disponer de metas y valores bien definidos y asumibles. . Planificación: establecer criterios claros de desarrollo futuro.

la calidad o el soporte técnico ofrecido pueden servir para diferenciarnos de nuestra competencia.Una adecuada estrategia del servicio requiere de una Perspectiva que determine claramente los objetivos y las decisiones que se deben adoptar para su consecución. Los planes deben de establecer una hoja de ruta para alcanzar los objetivos generales establecidos. nuevos desarrollos y planes de mejora. Existen diversas posibilidades para posicionarse en el mercado. Debe establecer las reglas generales del juego tanto dentro de la organización TI como en la relación con sus clientes. la seguridad. inversiones estratégicas. La comunicación es un aspecto esencial pues todos los agentes implicados deben comprender fácilmente cual la perspectiva adoptada. La Posición debe definir qué servicios se prestarán. La Planificación es esencial en un entorno en constante desarrollo que nos obligará a evolucionar constantemente nuestra estrategia del servicio. Características como el precio. Se puede optar por ser un proveedor de servicios altamente especializado que sirva a un pequeño nicho del mercado o un proveedor genérico con un amplio catálogo de servicios relacionados. Estos planes han de realizarse para el medio largo plazo centrándose principalmente en evoluciones del Portfolio de Servicios. . cómo serán prestados y a quién. diferenciándolos de los de su competencia.

Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios. El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costes asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos TI necesarios. Los patrones delinean el perfil de la organización TI frente al cliente y facilitan la asignación de recursos y priorización de actividades. no podrán evaluar el retorno de la inversión ni podrán establecer planes consistentes de gasto tecnológico. Procesos 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. Nota: Las propiedades y funcionalidades de la Gestión Financiera de los Servicios TI se resumen sucintamente en el siguiente interactivo: . es frecuente que no exista una conciencia real de los costes que esta tecnología supone. Esto conlleva serias desventajas:    Se desperdician recursos tecnológicos. Es prácticamente imposible establecer una política de precios consistente. 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.El Patrón asegura la coherencia en las actividades realizadas y establece reglas procedimentales que aseguran que las actividades necesarias sean realizadas en forma y plazo. Gestión de la Demanda: responsable de la armonización de la oferta de los servicios ofrecidos con las demandas del mercado.   Gestión Financiera Visión general Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus procesos de negocio. No se presupuestan correctamente los gastos asociados.

.

.

Evaluar. mayor es su coste. por lo que es necesario evaluar cuidadosamente las necesidades del cliente para que el balance entre ambos sea óptimo. Se ajustan. Asesorar al cliente sobre el valor añadido que proporcionan los servicios TI prestados. Proporcionar a la organización TI toda la información financiera precisa para la toma de decisiones y fijación de precios. adecuan y justifican (si es de aplicación) los precios del servicio. controlan. en colaboración con la Gestión del Portfolio de Servicios. Por regla general. a mayor calidad de los servicios. la Gestión Financiera debe:   Evaluar los costes reales asociados a la prestación de servicios.Gestión Financiera Introducción y objetivos La Gestión Financiera de los Servicios Informáticos tiene como objetivo principal administrar de manera eficaz y rentable los servicios y la organización TI. . Llevar la contabilidad de los gastos asociados a los servicios TI. aumentando la satisfacción del cliente.    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. Para lograr este objetivo. un análisis financiero del retorno de la inversión (ROI).

  Las principales dificultades a la hora de implementar la Gestión Financiera de los Servicios Informáticos se resumen en:  Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos financieros y/o contables. Existen múltiples costes ocultos difíciles de evaluar por una deficiente organización financiera. No existe una estrategia clara que permita elaborar unos presupuestos ajustados a la misma.     Introducción y objetivos Conceptos básicos Categorías de coste La clasificación de costes por servicio o producto puede realizarse en virtud de uno a más criterios: . La organización TI funciona como una unidad de negocio y es posible evaluar claramente su rendimiento global.  Los clientes contratan servicios que le ofrecen una buena relación coste/rentabilidad. Un incremento de los costes. No hay un compromiso de toda la organización con el proceso. Los servicios TI son usados más eficazmente. La organización TI puede planificar mejor sus inversiones al conocer los costes reales de los servicios TI.

a la prestación del servicio o elaboración del producto:  Costes directos: son los costes relacionados específica y exclusivamente con un producto o servicio. como por ejemplo. por lo general. los gastos de personal que presta los servicios. como por ejemplo. la "conectividad" de la organización TI de la que dependen tanto los servicios web como la propia plataforma general de comunicaciones. etc.Costes atribuibles.  . Costes de operación: son los costes asociados al funcionamiento diario de la organización TI. los fungibles.  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 en inmovilizado material. los servidores web asociados a los servicios de Internet. Estos costes son más difíciles de determinar y. directa o indirectamente. son prorrateados entre los diferentes servicios y productos. por ejemplo. Costes indirectos: aquellos que no son específicos y exclusivos de un servicio. 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 del inmovilizado material o inversiones a largo plazo.

El siguiente diagrama muestra una típica estructura de tipos y elementos de coste para una organización TI: * Los costes de transferencia se corresponden con los cargos internos por servicios prestados por otros departamentos de la empresa o institución.Tipos de coste Los tipos de coste son gastos de alto nivel. El número de tipos de costes varía dependiendo del tamaño de la organización TI y sus necesidades. como hardware. serían servidores. Responde a la pregunta: «¿Cuánto cuesta mantener este servicio?» . servicios externos y costes de transferencia interdepartamentales. software. ordenadores de sobremesa. ya sean éstos tangibles o intangibles. etc. Valor de provisión El valor de provisión de un servicio comprende los costes de creación del mismo. Los tipos de coste se subdividen a su vez en elementos de coste. personal. por ejemplo. Elementos de coste del hardware. ubicaciones físicas. Es imprescindible distinguir entre los diferentes tipos de coste para diseñar una política de precios clara y consistente. administración.

al menos en gestión de servicios. Mecanismos de distribución.Algunos ejemplos de costes relacionados con el valor de provisión son los impuestos. . Por lo general. técnicas para identificar los imperativos de negocio que dependen de la gestión del servicio. técnicas para analizar de forma retroactiva una inversión dentro de la gestión del servicio. Se basa en la percepción del servicio que se forma el cliente al considerar qué ventajas o mejorías (en términos de utilidad y garantía) representa para su negocio utilizar el servicio en lugar de sus propios activos. Hay que tener en cuenta que una actividad puede reportar a la organización beneficios de carácter estratégico que no se pueden cuantificar de manera tan evidente. El valor final del servicio se calcula comparando la suma total del valor potencial de todos los componentes con el valor de provisión del servicio. se refiere a la capacidad de un servicio para generar valor mediante sus activos. Post-ROI. por ejemplo. es necesario poner en práctica a la hora de calcular el ROI:  Caso de Negocio. El ROI se calcula dividiendo el beneficio neto de una actividad entre el valor neto de los activos que han intervenido en el proceso. cuál será el impacto financiero de añadir o eliminar cierta unidad del servicio. etc. Costes de mantenimiento del centro de datos. Retorno de la inversión (ROI) El retorno de la inversión (ROI). dependiendo del impacto del negocio se pueden prever distintos grados de ROI. Gracias a la VCD se puede calcular. En dicho análisis puede considerar las siguientes variables:     Número y tipo de usuarios. Por eso. Número de licencias de software. Pre-ROI. las instalaciones. los costes de licencias de hardware y software. El valor final del servicio se calcula comparando el valor de provisión con la suma total del valor potencial de todos los componentes del servicio. técnicas para analizar cuantitativamente una inversión dentro de la gestión del servicio.   Dinámica de costes variables (VCD) La dinámica de costes variables (VCD) analiza y relaciona todas las variables que determinan los costes del servicio y cómo reaccionan a los cambios en los activos del mismo. Valor potencial del servicio El valor potencial del servicio se refiere al valor añadido que aporta.

Establecimiento de tarifas por los servicios prestados o productos ofrecidos. Coste de añadir una o más licencias de usuario final.  Contabilidad: o o o Identificación de los costes. Fijación de políticas financieras. Definición de elementos de coste. Elaboración de presupuestos. Proceso Las principales actividades de la Gestión Financiera se resumen en:  Presupuestos: o o o Análisis de la situación financiera. Monitorización de los costes. Coste de añadir uno o más dispositivos de almacenamiento. . Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.  Número y tipo de recursos.  Fijación de precios: o o Elaboración de una política de fijación de precios.

.

Presupuestos La elaboración de presupuestos TI tiene como objetivos principales:    Planificar el gasto e inversión TI a largo plazo. adaptándolos a las modificaciones en los costes y el desarrollo de nuevas tecnologías. Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales:  Presupuesto incremental: el presupuesto se realiza en base al histórico de presupuestos anteriores. Presupuesto "desde cero": se replantea toda la estructura de costes e inversiones a partir de una "hoja en blanco" en base a los servicios prestados en la actualidad y las expectativas de crecimiento en el periodo presupuestado. o resultar de una proyección sobre la evolución prevista del negocio en dos o más años. Establecer objetivos claros que permitan evaluar el rendimiento de la organización TI. la complejidad de las .  Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI es necesario identificar previamente todos los elementos de coste. incluyendo los costes de los servicios prestados en la actualidad. como por ejemplo el aumento del precio de las licencias del software. La estimación de los costes asociados a esos elementos no es siempre una tarea sencilla y a menudo influyen factores externos que no se hallan bajo el control directo de la organización TI. Contabilidad En principio. Sin embargo. y teniendo en consideración la aparición de nuevas líneas de servicios. la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada a otros servicios o departamentos. Asegurar que los servicios TI están suficientemente financiados. etc. Los presupuestos realizados pueden tener diferentes horizontes temporales. Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos al respecto para evitar que se conviertan en papel mojado al menor vaivén del mercado. Pueden ser a corto plazo.

Existen múltiples opciones. asignando a cada servicio/cliente su parte proporcional.    Si se desea considerar a la organización TI como otra unidad de negocio es necesario conocer en detalle tanto sus costes como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues el cliente es la propia organización). Tomar decisiones de negocio basadas en los costes de los servicios. costes de personal. si es de aplicación. los servicios TI. Precio de mercado: se cobran los servicios en función de las tarifas vigentes en el mercado para servicios de similar naturaleza. Para que la organización TI pueda funcionar como una verdadera unidad de negocio.  . Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance un excesivo nivel de detalle que lo encarezca más allá de lo razonable. Política de Precios No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia organización. Es una de las actividades principales de la Gestión Financiera identificar los denominados elementos de coste que se pueden clasificar de forma genérica en:    costes de hardware y software. cuanto menos. Facturar adecuadamente. Evaluar la eficiencia financiera de cada uno de los servicios TI prestados. es imprescindible tanto conocer los costes reales de los servicios prestados como establecer una política de precios que. debe establecerse una política de fijación de precios. pero este es un paso esencial si buscamos que se utilice eficientemente la infraestructura TI. permita recuperar los costes en los que se ha incurrido.interrelaciones TI dificulta el proceso cuando los responsables de su contabilidad desconocen los mecanismos básicos y la tecnología que los sustenta. Las actividades contables deben permitir:  Una correcta evaluación de los costes reales para su comparación con los presupuestados. En primer lugar. entre ellas:  Coste más margen: se establecen los costes totales del servicio y se les añade un margen de beneficios (que puede ser del 0% para "clientes internos"). costes de administración.

Los precios vigentes en el mercado. Los contratos de soporte (UCs) en vigor. respectivamente. en los aspectos económicos la actividad de estos procesos sea supervisada por la Gestión Financiera. es recomendable que. Para ello es necesario que exista una comunicación fluida y convenientemente estructurada entre ambos procesos. Mientras que la Gestión Financiera debe aportar información sobre:   Los costes reales de los servicios. Precio flexible: que depende de la capacidad TI realmente utilizada y/o de los objetivos cumplidos. Los costes asociados. pero también otros procesos del Ciclo de Vida deben proveer de información a la Gestión Financiera sobre:     El tipo de servicios demandados por los clientes. Factores de escala y necesidades de disponibilidad.  Una vez determinada la política de fijación de precios se deben determinar las tarifas de los servicios en función de:      La política elegida. Sin embargo. Los servicios solicitados. Tendencias del mercado y los Planes de Mejora del Servicio (SIP). quienes se ocupan de ello. En algunas ocasiones estas tarifas serán usadas para una facturación real mientras que en otras sólo se utilizarán de referencia para evaluar el rendimiento teórico de la organización TI. Previsiones de costes. . principalmente la Gestión de Niveles de Servicio y la Gestión del Catálogo de Servicios. Por un lado. Supervisión financiera No es tarea de la Gestión Financiera de los Servicios TI negociar con los clientes ni elaborar el Catálogo de Servicios. Precio negociado: se negocia directamente con el cliente cuál es el precio estipulado por los servicios. Son la Gestión de Niveles de Servicio y la Gestión del Catálogo de Servicios. Los SLAs contratados.

será imposible llegar a acuerdos que sean rentables y a su vez satisfactorios para el cliente. Es imprescindible que quien desempeñe este rol disponga de ciertos conocimientos sobre los servicios TI y/o esté correctamente asesorado por especialistas en todo lo referente a la tecnología. . La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Financiera según los parámetros arriba descritos y aporta información de vital importancia a la organización en su conjunto. Para poder evaluar la función de la Gestión Financiera es necesario establecer tanto unos criterios claros para evaluar su éxito como unos indicadores de rendimiento específicos. Entre la documentación generada cabría destacar:  Resúmenes contables.  Desviaciones en las previsiones de costes respecto a los gastos reales. éstos deben incluir métricas que permitan evaluar si:      Los gastos TI están correctamente planificados y presupuestados. Métodos y condiciones de pago. Control del proceso La responsabilidad del proceso de Gestión Financiera recae sobre el Gestor Financiero. Se cumplen los objetivos de costes e ingresos. Sin una estrecha colaboración entre ambos procesos. Se lleva a cabo una contabilidad precisa asociada a cada servicio. Entre los primeros cabe destacar:     ¿Conoce la organización los costes reales de los servicios TI? ¿Los clientes perciben la política de precios como coherente y ajustada al mercado? ¿Colaboran los responsables de los otros procesos TI con la Gestión Financiera? ¿Están los gastos en servicios e infraestructuras TI realmente alineados con los procesos de negocio? ¿Opera la organización TI como una verdadera unidad de negocio?  En lo que respecta a los indicadores de rendimiento. Se conoce el ROI de las inversiones TI. La organización TI funciona de manera "rentable".

Planes de reducción de costes por servicio. Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología. ya que provee de información estratégica fundamental para orientar cualquier actividad. En la fase de Diseño.  Análisis de eficiencia de cada uno de los servicios TI. Se ocupa. la Gestión del Catálogo de Servicios se basa por completo en el Portfolio. ya que su cometido principal consiste en elaborar una versión de éste especialmente enfocada a clientes.  Indirectamente. la Gestión del Portfolio alimenta a todas las fases del Ciclo de Vida. La Gestión del Portfolio se relaciona directamente con los siguientes procesos de las fases del Ciclo de Vida:  La Gestión Financiera. Nota: Las propiedades y funcionalidades de la Gestión del Portfolio se resumen sucintamente en el siguiente interactivo: . proporciona al Portfolio la información necesaria para comprender en profundidad los costes del servicio. Análisis de impacto en el negocio (BIA) en caso de producirse una interrupción de las operaciones. de facilitar a los gestores de productos la tarea de evaluar los requisitos de calidad y los costes que éstos conllevan. asimismo.   Visión general El objetivo primordial de la Gestión del Portfolio de Servicios consiste en definir una estrategia de servicio que sirva para generar el máximo valor controlando riesgos y costes. en la fase de Estrategia.

.

.

cuáles se ajustan mejor a los objetivos planteados. En este escenario. la organización es capaz de optimizar sus capacidades para ofrecer el mayor valor añadido.Gestión del Portfolio de Servicios Introducción y objetivos La Gestión del Portfolio de Servicios se encarga de decidir la estrategia a seguir para dar servicio a los clientes y de desarrollar las ofertas y capacidades del proveedor de servicios. situación que a menudo es interpretada por los clientes como signo de incoherencia. detectando oportunidades. aportan mayor valor a los clientes. etc.  La principal dificultad a que se enfrenta la Gestión del Portfolio de Servicios es que la dirección de la organización TI sea reacia a definir los servicios de antemano por considerar que este procedimiento limita el negocio. competencia. ofrecen mejores perspectivas de negocio. obteniendo niveles óptimos de ROI a un bajo coste. Para cumplir su cometido. Pronto se manifiestan los síntomas de una excesiva diversificación del negocio: los servicios son difíciles de agrupar.   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í:  Al conocer a fondo los recursos de que dispone y los riesgos a que se enfrenta. etc. una vez desaparecido el cliente es muy difícil vender el servicio y por lo general. de entre todos los servicios posibles que puede ofertar la organización TI. se produce una identificación de las necesidades expuestas por el cliente con los objetivos del servicio. se evita el peligro de caer en una excesiva diversificación del negocio en servicios dispares.  . 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. hay que desmantelarlo. Definir de forma detallada los servicios que se ofrecerán a los clientes. etc. Es tarea de la Gestión del Portfolio de Servicios elegir. Al contar con unos objetivos claros que rigen las líneas estratégicas de la organización. Plantear unas líneas estratégicas sólidas que sirvan para orientar todas las actividades del negocio hacia una serie de objetivos claros. Así. Entre las consecuencias negativas de esta situación podemos destacar:  El Portfolio de Servicios pierde su función como referencia estratégica y queda reducido a un mero registro de los servicios ya ofrecidos. Al tratarse de servicios “a medida”. los servicios y funcionalidades se van creando según surgen las oportunidades de negocio o el cliente va demandando nuevas mejoras.

 Proceso Las principales actividades de la Gestión del Portfolio de Servicios se resumen en:  Definición del negocio: qué servicios ofrece la competencia. etc. ya porque se renuevan excesivamente o porque se reasignan a cometidos demasiado alejados de sus capacidades. servicios necesarios para alcanzarlos. la organización se encuentra con la difícil situación de encajar recursos que poco o nada tienen que ver con los recursos de otros servicios. Aprobación de decisiones de cara al futuro sobre los servicios: retención. Esto repercute en un desaprovechamiento de los recursos. riesgos.    El siguiente diagrama muestra los procesos implicados en la correcta Gestión del Portfolio de Servicios: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI. etc. costes previstos. . Actualización del Portfolio de Servicios y Planificación: definición de los servicios. racionalización. prioridades. capacidades y recursos asociados. refactorización. Al retirar un servicio concreto. resulta muy complicado a otros procesos como por ejemplo la Gestión de Peticiones o los de la fase de Mejora Continua del Servicio aprobar o rechazar propuestas de cambio de manera ecuánime. qué oportunidades ofrece el mercado. renovación y retirada. plazos. Análisis de servicios: objetivos. cuáles son los “punto fuertes” de la organización. Al no existir unos objetivos claros y bien definidos. sustitución. etc.

.

como es lógico. Esto es aplicable tanto en el momento de la puesta en marcha de un nuevo servicio como en aquellos casos en que la Mejora Continua del Servicio plantea nuevas funcionalidades. Ofertas de servicio de otros proveedores de la competencia. Por tanto. No hacerlo puede acarrear consecuencias muy graves como. por ejemplo.    Una metodología útil para tomar decisiones respecto al orden y tiempos de las inversiones en el Portfolio de Servicios es la herramienta de Espacio de Opción: . en conocer el mercado en que se va a desarrollar el servicio. Casos de Negocio.Proceso Definición del negocio El punto de partida de la Gestión del Portfolio de Servicios está. es imprescindible hacer desde un primer momento un ejercicio de evaluación de la situación actual del negocio y definir:   Inventario de servicios ofertados o que se van a ofertar. Necesidades de los clientes existentes o potenciales. averiguar demasiado tarde que otro competidor ofrece el mismo servicio por la mitad de precio. Previsiones de costes directos e indirectos de la creación y mantenimiento de cada uno de esos servicios.

Análisis de servicios Tras analizar el mercado. Sin denominadores comunes. algo imprescindible de cara a la optimización de recursos y el equilibrio del suministro. amenazas. Además de ahorrar costes. La etapa de definición debe dar respuesta a las siguientes preguntas estratégicas:   ¿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. Se trata de concretar las líneas de actuación conforme a las prioridades de la organización. a ojos del cliente. al existir unos planteamientos que de manera subyacente implican a todos los servicios. se procede a analizar cuidadosamente las posibilidades de la organización. la Gestión de la Demanda apenas tiene margen de maniobra. se configuran unas señas de identidad que. son percibidos de forma positiva como coherencia en el negocio. 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?       .

servicio. los servicios que encajan con los criterios funcionales y técnicos de la organización presentan límites de procesos o sistemas enmarañados. múltiples versiones del mismo sistema operativo. de hecho. procesos y sistemas bien definidos que están alineados con la estrategia general de la organización. enfocadas a la Operación del servicio. Retirada: Servicios que no se ajustan a ninguno de los criterios y por tanto se decide desmantelar.Aprobación de servicios Los planteamientos estratégicos resultantes de la fase de definición han de ser debidamente autorizados por la Gestión del Portfolio de Servicios. Estas inversiones apenas conllevan riesgos. Tan sólo aquellos servicios en los que ambas facetas estén equilibradas podrán ser aprobados. aplicación.   Las decisiones que pueden aplicarse a un servicio son:  Retención: se asigna a servicios con límites de activos. Sustitución: Servicios con funcionalidades que son poco claras o bien se solapan con las de otro servicio. encaminadas hacia nuevos espacios de mercado. Esta clase de inversiones conllevan un riesgo medio. la Gestión del Portfolio de Servicios tiene en cuenta dos factores: el valor que aporta la iniciativa y el riesgo que conlleva. etc. Racionalización: Se aplica a portfolios con servicios que son. Renovación: Servicios que se ajustan a los criterios de funcionalidad pero no a los técnicos. Refactorización: A menudo. En la toma de decisión. En estos casos. Las inversiones del servicio se clasifican en tres categorías estratégicas:  Inversiones para mantener el negocio (RTB).      Planificación y actualización del Portfolio 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 acometer las decisiones adoptadas en la etapa de aprobación y recogidas en el Portfolio de Servicios. con servicios comunes para proporcionar el resto de funcionalidades. Inversiones para transformar el negocio (TTB). que no sólo es la encargada de aprobar o rechazar los servicios. el servicio puede ser refactorizado para dejar sólo la funcionalidad básica. cuyo fin es ampliar el abanico de servicios. Esta clase de inversiones son las que mayores riesgos comportan. sino también de asignar los recursos necesarios para suministrar el servicio. . Inversiones de crecimiento del negocio (GTB).

y debe cuidarse mucho el lenguaje para no emplear tecnicismos. Catálogo de Servicios El Catálogo de Servicios está enfocado a los clientes. Prioridades. El Flujo de Creación del Servicio permite hacer una prospección estratégica de cara al futuro y hacerse una idea aproximada de las líneas de crecimiento de la organización. Riesgos. e incluye tan sólo aquellos servicios que la organización está prestando actualmente. Descripción detallada de los servicios prestados. definidas unas premisas estratégicas básicas. Costes asociados. la información sobre los servicios relacionados con la infraestructura de la organización es de carácter interno. La Gestión del Catálogo de Servicios constituye un proceso aparte que veremos en el capítulo dedicado a la Estrategia del Servicio. En cambio. Casos de negocio. Ofertas y paquetes del servicio.Una vez evaluadas las exigencias del mercado. El documento resultante es el Portfolio de Servicios o Cartera de Servicios. Esto obliga a dividir el Portfolio de Servicios en tres subconjuntos: el Catálogo de Servicios. Propuesta de valor añadido. Flujo de Creación de Servicio El Flujo de Creación de Servicio. y los Servicios Retirados. el Flujo de Creación del Servicio. como hace el Catálogo de Servicios. El Portfolio de Servicios comprende una lista completa y detallada de los servicios administrados por la organización. Algunos de estos servicios atañen directamente a los clientes. en lugar de ocuparse de los servicios que se prestan actualmente. llega el momento de registrar esa información para que pueda ser utilizada por otros procesos del Ciclo de Vida del servicio. . seleccionados los servicios a prestar y asignados los recursos y plazos. La información disponible para cada servicio debe contemplar los siguientes aspectos:          Requisitos y especificaciones funcionales. El enfoque ha de ser comercial. incluye los servicios que están en fase de estudio o desarrollo. describiéndolos en términos de valor para el negocio. Modalidades de contratación y precios. por lo que la información también ha de estar disponible para ellos.

cuanto mejor funciona un servicio. a su vez. se espera del personal del Centro de Servicios que al menos conozca la existencia del servicio y tenga una idea aproximada de lo que ofrecía. los servicios no pueden producirse con antelación y almacenarse hasta que el cliente los solicita. Un ejemplo sería el Centro de Servicios. En esta situación. es importante conservar la documentación relacionada puesto que otros procesos pueden verse en la necesidad de recurrir a ella. Número de nuevos clientes. circunstancia que complica enormemente la planificación de la demanda. al que se le puede presentar el caso de un cliente que solicita soporte para un servicio retirado. La Gestión de la Demanda se encarga de predecir y regular los ciclos de consumo. Ésta. mayor demanda genera. incrementando los activos del servicio. Control del proceso Se puede medir la eficacia de la Gestión del Portfolio de Servicios a través de los siguientes indicadores:  Porcentaje de nuevos servicios planeados (que han sido desarrollados desde la Gestión del Portfolio de Servicios) Porcentaje de nuevos servicios no planeados (que han sido desarrollados sin la intervención de la Gestión del Portfolio de Servicios) Número de iniciativas estratégicas lanzadas desde la Gestión del Portfolio de Servicios. Es un proceso simultáneo: la producción y el consumo tienen lugar al mismo tiempo. Se genera así un ciclo de consumo-producción en el que el consumo es un estímulo positivo para la producción y viceversa: . como es natural. Número de clientes que se han cambiado a la competencia. provoca exigencias de capacidad que los responsables compensan. Por lo general.     Gestión de la Demanda Visión general Al contrario que los bienes materiales. adaptando la producción a los picos de mayor exigencia para asegurar que el servicio se sigue prestando de acuerdo a los tiempos y niveles de calidad acordados con el cliente.Servicios Retirados Aunque un servicio haya sido retirado o esté próximo a su desmantelamiento.

Sin embargo. De ahí la importancia para la organización de la Gestión de la Demanda. nuevos servicios o cambios en los servicios basándose en el consumo. optimizar la planificación para ajustarse a los patrones de consumo. Una correcta Gestión de la Demanda aporta una serie de mejoras y beneficios notables tanto al servicio como al negocio en sí:  La Gestión de la Capacidad. El Catálogo del Servicio puede también trazar patrones de demanda para ciertos servicios. La Gestión del Portfolio de Servicios puede aprobar inversiones en capacidad extra. con los informes de la Gestión de la Demanda. La Operación del Servicio puede ajustar la asignación de recursos y planificar mejor hallando esquemas comunes de demanda. puede. La Gestión Financiera puede aprobar incentivos adecuados para influir la demanda. el incremento de uno y otro lado del engranaje no tiene por qué ser paralelo.     Nota: Las propiedades y funcionalidades de la Gestión de la Demanda se resumen sucintamente en el siguiente interactivo: . que ayuda a racionalizar el uso y contratación de los recursos.

.

.

Paquete de Nivel de Servicio (SLP) . Interrupciones parciales del servicio por errores de hardware o software. Un aumento de la capacidad siempre conlleva costes que muchas veces resultan innecesarios. En la mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio. Ahora bien. tanto por exceso como por defecto. ahorrando a la organización una gravosa ampliación del ancho de banda. Los SP comprenden un Paquete de Nivel de Servicio (SLP). etcétera). Conceptos básicos Paquete de Servicio (SP) Un Paquete de Servicio (SP) es una descripción completa de un servicio TI que ya está disponible para ser entregado a los clientes. cuando menos. puede resultar más eficiente su contratación directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en la optimización del sistema. El origen de los problemas que la Gestión de la Demanda debe subsanar a corto plazo se puede encontrar en:    Degradación del servicio por aumentos no previstos de la demanda. Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Por ejemplo. informes de rendimiento para clientes. Incremento innecesario de costes ocasionado por un exceso de capacidad pensado para compensar los picos de demanda pero que realmente no aporta valor al servicio. lo sean en la menor medida posible. Una correcta monitorización de la capacidad permite reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad. uno o más servicios esenciales y uno o más servicios de soporte. Su papel cobra especial protagonismo cuando existen problemas de capacidad en la infraestructura TI. si el coste añadido por aumentar el ancho de banda es marginal. La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios críticos no se ven afectados o.Introducción y objetivos El objetivo principal de la Gestión de la Demanda es optimizar y racionalizar el uso de los recursos TI. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en consecuencia. una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por la organización se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicos asociados a procesos automáticos (tales como campañas de marketing promocional.

.  El siguiente diagrama muestra los procesos implicados en la correcta Gestión de la Demanda: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI. Paquete de Servicio Esencial (CSP) 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. Proceso Las principales actividades de la Gestión de la Demanda se resumen en:  Análisis de la actividad del negocio para determinar patrones de demanda y segmentaciones de clientes. Desarrollo de la oferta. Los SLP se diseñan conforme a las necesidades de un Patrón de Actividad de Negocio (PBA) particular. Línea de Servicio (LOS) Una Línea de Servicio (LOS) es un servicio esencial o de soporte común a varios Paquetes de Nivel de Servicio (SLP).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. con distintas opciones para cada segmento del mercado de acuerdo a sus necesidades. empaquetando de manera distinta los servicios esenciales y los de soporte. Cada LOS tiene asignado un Gestor de Producto.

Análisis de actividad .

en lo que se refiere a patrones de demanda. los planes de negocio del cliente están alineados con los planes de gestión del servicio del proveedor. y consiste en analizar los patrones de actividad del negocio (PBAs) y predecir la demanda tomando como referencia los activos del servicio que soportan esas actividades. también es clave para que la Gestión de la Demanda pueda tomar decisiones estratégicas acertadas que en esta primera etapa se recabe y analice información sobre el mercado en el que opera el servicio:  Necesidades de los clientes a los que se dará servicio.  Desarrollo de la oferta .   Por otro lado. tanto si se trata de servicios ofrecidos por sus propias organizaciones como de otros proveedores de la competencia. El enfoque más extendido para predecir la demanda es el basado en actividades. La Gestión de la Demanda basada en actividades se encarga de:  Monitorizar y analizar los patrones de actividad del proceso de negocio con el fin de predecir la demanda de servicios. Asegurarse de que. Alternativas de las que disponen los clientes de esos segmentos. Asignar las unidades de demanda adicionales generadas por la actividad del negocio a elementos de la capacidad del servicio.El primer paso a la hora de acometer la racionalización de los recursos de una organización TI consiste en conocer cuáles son las necesidades de rendimiento ocasionadas por los servicios que presta. agrupándolos por segmentos de mercado.

Centro de Atención al Usuario). El punto de partida consiste en distinguir dos grandes grupos de servicios:  Servicios esenciales. es el momento de racionalizar los servicios. Adicionalmente.  La Gestión de la Demanda toma estos elementos y. Uno o más servicios de soporte y su descripción. precios. Uno o más servicios esenciales y su descripción. En él se especifican los niveles de utilidad y garantía de los que disfrutarán los usuarios de los servicios.Una vez realizado un análisis del negocio y concretados una serie de patrones de demanda del mismo. sin los que el negocio no puede satisfacer las necesidades del cliente. . que pueden estar orientados a dar continuidad al servicio o a mejorar su propuesta de valor (p. con la información que tiene a su alcance acerca del mercado y las necesidades de los clientes. Representan aquellas características que diferencian nuestro producto de otros similares ofrecidos por la competencia.ej. Los paquetes de servicio contienen una descripción detallada del servicio TI. define una serie de paquetes de servicio adaptados a los distintos segmentos de clientes. que ha de incluir necesariamente:  Paquete de nivel de servicio (SLP). se crea un Paquete de Servicio Esencial (CSP) cuyos activos son compartidos para todos los paquetes de servicio. al definir una serie de servicios esenciales. que podemos llamar empaquetado o paquetización. Representan el valor que el cliente desea y por tanto. permite a la organización adaptar el suministro de un mismo servicio a distintos casos de negocio. con diferentes niveles de servicio. por lo que está dispuesto a pagar. Servicios de soporte.   Este proceso. etc.

La Gestión de la Demanda debe comprobar. Restringir aquellas actividades que no sean urgentes durante los periodos de mayor actividad. Número de interrupciones del servicio ocasionadas por picos de la demanda no previstos. la Gestión de la Demanda puede introducir desde la raíz algunas técnicas que ayuden a regular el consumo y racionalizar los recursos. Número de cambios planificados desde Gestión de la Demanda que se han efectuado en el servicio con el fin de ajustarse a la demanda.ej. técnicas (p. Control del proceso Se puede medir la eficacia de la Gestión de la Demanda a través de los siguientes indicadores:   Desviación de la actividad prevista en los PBAs respecto a la que se registró realmente. que los distintos paquetes de servicio deben ajustarse debidamente a las restricciones financieras (p. Dado el caso. conexión) y físicas (p.  . políticas de precios y facturación). disponibilidad) a las que está sometida la organización TI. Algunas de estas técnicas son:    Escalonar el inicio de la jornada laboral Dar prioridad a los informes y procesos por lotes Ejecutar durante la noche (o fuera de las horas de trabajo) aquellos informes y trabajos que no sean críticos. por último.ej.ej.

análisis de riesgos y definición de los factores críticos de éxito entre otros. Puesta en Marcha La implementación de la Estrategia del Servicio requiere abordar aspectos metodológicos. tecnológicos. organizativos. Organización La organización es un factor esencial en la Gestión del Servicio. ITIL considera cinco fases principales en la evolución de la organización con las siguientes características: Fase 1: Red Aspectos positivos Aspectos negativos . El proceso de implementación 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 El objetivo es poner en práctica los principios generales sobre la estrategia del servicio adaptándolos a los requisitos y necesidades propios y de nuestros clientes. Número cambios no planificados que se han efectuado en el servicio con el fin de ajustarse a la demanda.

Aspectos positivos    Aspectos negativos   Pocas estructuras formales Estructura ágil y flexible La tecnología juega un papel esencial Problemas de coordinación Dificultades a la hora de externalizar procesos y actividades Fase 2: Directiva Aspectos positivos  Aspectos negativos    Estructura jerárquica con un equipo de dirección responsable de la estrategia Actividades funcionales bien definidas Trabas a la innovación Problemas de comunicación Falta de autonomía del personal no directivo  Fase 3: Delegación Aspectos positivos  Aspectos negativos  Se delegan mayores responsabilidades a niveles jerárquicos inferiores promoviendo así la innovación Organización más descentralizada y eficiente La organización se basa más en procesos que en funciones Conflictos de intereses entre los diferentes gestores funcionales Difícil equilibrio entre el modelo de gestión basado en procesos y el basado en funciones    Fase 4: Coordinación Aspectos positivos  Aspectos negativos  Se aplican sistemas que mejoren la coordinación Se planifica la Gestión del Servicio Los servicios son considerados activos estratégicos de la organización   La respuesta a problemas y cambios puede ser menos ágil y flexible Se puede caer en excesivos procesos burocráticos  Fase 5: Colaboración .

Tecnología Tratándose de la Gestión de Servicios TI es evidente que la tecnología debe jugar un papel importante en todo lo que respecta a la prestación de servicios. Ninguna de estas fases es en sí “la correcta” y su adopción puede depender de la situación. tamaño y grado de madurez de la organización. Aunque las infraestructuras informáticas presentes puedan carecer de la flexibilidad y capacidad de adaptación de los equipos humanos es evidente que proporcionan:     Estándares de calidad consistentes Mayor rapidez de respuesta Se simplifican los procesos de monitorización y evaluación El conocimiento recopilado durante la prestación del servicio es un activo que reside en la organización y no en un personal susceptible de migrar a la competencia Reducción de costes  Pero la automatización de servicios no es el único terreno en el que la tecnología puede jugar un papel importante en la Gestión del Servicio. .Aspectos positivos  Aspectos negativos  La organización se centra en el negocio Mayor agilidad en respuesta a las necesidades del cliente La dirección es experta en relaciones laborales y en la resolución de conflictos Existe una estrategia claramente definida Se fomenta la innovación Equilibrio entre responsabilidades funcionales y las asociadas a los servicios y relaciones con los clientes (estructura matricial)  El personal puede no tener completamente claras sus funciones Líneas de mando poco definidas en la estructura matricial      Es esencial a la Estrategia del Servicio reconocer en qué fase de desarrollo se encuentra la organización para establecer la estrategia del servicio en consecuencia. La automatización de servicios juega en la actualidad un papel esencial en la prestación de servicios TI.

La externalización dependerá de múltiples factores entre los que se cuentan. Sistemas tan complejos como el que nos ocupa pueden resultar a veces en comportamientos inesperados e incluso contrarios a nuestra intuición.La gran capacidad de cálculo de los sistemas informáticos permite analizar una inmensa cantidad de datos para la búsqueda de patrones (data mining) que ofrezcan un conocimiento más detallado sobre la calidad y el rendimiento de la gestión de servicios. por ejemplo.   Cuestiones de carácter financiero Competencias clave de la organización Los posibles tipos de externalización están en relación directa con los distintos tipos de proveedores:  Contratación interna o Tipo I: encargada a proveedores internos de servicios circunscritos a cada unidad de negocio Tipo II: encargadas a unidades de servicios compartidos que prestan sus servicios a las diferentes unidades de negocio pertenecientes a una misma corporación o  Contratación externa (Tipo III) . ayudar a optimizar la estructura y flujos de información y trabajo de nuestro Centro de Servicios. El modelado analítico y las simulaciones pueden. La tecnología también nos ofrece útiles herramientas para simular y modelar la dinámica de la organización. Estrategias de externalización de servicios En diversas circunstancias puede ser recomendable la delegación en organizaciones externas la prestación de ciertos servicios e incluso la gestión de algunos procesos.

La correcta Gestión del Servicio debe trasladar los riesgos del cliente al proveedor de servicios y este último debe ser recompensado por ello (Principio de Agencia). Los riesgos están naturalmente asociados a incertidumbres y aunque en general tengan un carácter negativo en ocasiones pueden resultar en oportunidades de negocio.o Tradicional: un solo proveedor de servicios se encarga de la prestación del servicio en cuestión Múltiple:  o Principal: un solo proveedor de servicios que subcontrata a su vez a otros proveedores Consorcio: combinación de diferentes proveedores de servicios para optimizar la oferta y calidad del servicio Selectiva: múltiples proveedores gestionados directamente por la organización receptora del servicio   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 Factores de éxito y riesgos El análisis del riesgo y el establecimiento de factores clave del éxito son dos aspectos claves en el establecimiento de la Estrategia del Servicio. Los principales riesgos que afronta un proveedor de servicios se resumen en: . Cada servicio debe ser analizado y los riesgos asociados deben ser catalogados y a ser posible se diseñarán estrategias para evitarlos o minimizarlos.

Este riesgo no sólo tiene un impacto obvio en el servicio prestado sino que también afecta la percepción del cliente (garantía del servicio) dificultando la posible contratación de nuevos servicios. Riesgos operativos comunes a todas las organizaciones. Medición del rendimiento: si no lo puedes medir no lo puedes gestionar (Principio de Deming). Relación con otros ciclos . Coordinación: las redes de valor no aportarán valor a los servicios si sus aportaciones no están adecuadamente coordinadas. Riesgos de contratación debidos a la imposibilidad de cumplir los contratos con los niveles de servicio acordados. riesgos y en la medida que estos sean superados factores claves de éxito 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.    En lo que respecta específicamente a la fase de la Estrategia del Servicio los principales retos. Riesgos de diseño asociados a una incorrecta funcionalidad del servicio que se traduce en un pobre rendimiento con la consecuente menor percepción del valor. 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. Riesgos de mercado debidos a una pobre diferenciación de los servicios ofrecidos o a una mala gestión de la cartera de servicios. Esto sólo puede conseguirse mediante una cultura de cooperación que requiere de un continuo seguimiento y monitorización de las actividades y procesos para que ésta se haga efectiva. La formación y la comunicación continua deben formar parte integrante de la fase de Estrategia. Se deben establecer métricas para: o o o o o o    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 y en general todos aquellos aspectos de los que depende la aportación de valor al cliente y la eficacia de la organización TI.

La estrategia debe ser continuamente rediseñada atendiendo a múltiples factores. en aquello que le corresponde. Esto es algo que es particularmente cierto para la Estrategia del Servicio pues ésta debe de servir de guía al diseño. 4. ESTRATEGIA Y TRANSICIÓN A la hora de establecer una correcta Estrategia del Servicio es necesario conocer en profundidad sus implicaciones en la fase de Transición del Servicio. Recíprocamente. a dar soporte a la perspectiva y posicionamiento del servicio establecidos en la fase de estrategia.Ninguno de los ciclos de la fase de vida de los servicios debe ser considerado como un compartimento estanco pues sus interrelaciones con las otras fases son de vital importancia para la correcta Gestión del Servicio. Es indispensable sopesar los riesgos y potenciales beneficios asociados para establecer una estrategia que minimice los primeros maximizando a su vez los segundos.  2. Por lo tanto un factor esencial en el enfoque estratégico de los servicios es asegurar que son operacionalmente viables. Cada cambio y evolución implica costes e inevitablemente tiene un impacto en clientes y usuarios. ESTRATEGIA Y DISEÑO El principal input ofrecido a la fase de Diseño del Servicio por la fase de Estrategia es un Portfolio de Servicios orientado a cada segmento del mercado. A continuación resumimos las principales interdependencias: 1. Información sobre restricciones derivadas de los clientes o política de precios. la Operación del Servicio debe de resultar en la fuente más fiable sobre las demandas y restricciones de los clientes que servirán de guía para dar forma a la estrategia más adecuada. operación y mejora continua del servicio. ESTRATEGIA Y OPERACIÓN La fase de operación es la más importante desde el punto de vista del cliente. ESTRATEGIA Y MEJORA CONTINUA En un mundo en constante desarrollo tecnológico las estrategias no deben ser inamovibles. etcétera. 3. La estrategia debe aportar al diseño del servicio:  Modelos de servicio que ofrezcan una guía sobre como aportar valor a los servicios propuestos. . los servicios pueden ser adecuados y estar bien diseñados pero si el eslabón de la operación falla los resultados no serán los buscados y la percepción del cliente será negativa. transición. Por otro lado la Transición del Servicio debe colaborar.

El Diseño del Servicio debe seguir las directrices establecidas en la fase de Estrategia y debe a su vez colaborar con ella para que los servicios diseñados:     Se adecuen a las necesidades del mercado. 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.La Mejora del Servicio debe ofrecer información a la fase de Estrategia sobre aspectos que pueden ser optimizados. pero esto siempre debe hacerse partiendo de la perspectiva de negocio establecida durante la fase de estrategia. Cumplan los estándares de calidad adoptados. El proceso de diseño del servicio no es estanco y debe tener en cuenta que los procesos y actividades involucrados incumben a todas las fases del ciclo de vida. Un desequilibrio entre ambos lados de la balanza puede resultar en servicios donde se vean comprometidas bien la funcionalidad o bien la garantía. Sean eficientes en costes y rentables. 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. tales como calidad y rendimiento. 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?     Principios del Diseño de Servicios . Aporten valor a clientes y usuarios. Diseño de los Servicios TI 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.

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. los servicios en fase de desarrollo y los servicios retirados en términos de valor para el negocio. Debe incluir información sobre todos los servicios ofrecidos. 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 . 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 (si estos se consideraran necesarios)    2.ITIL contempla cinco aspectos esenciales en el Diseño del Servicio: 1.

La Gestión de las aplicaciones. 5. entradas y salidas. La infraestructura TI necesaria. deben de ser la principal entrada para la fase de Mejora del Servicio. basado en métricas y métodos preestablecidos. En particular deben establecerse los procesos de control para asegurar que los procesos se realizan de forma eficiente y cumplen los objetivos establecidos. 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. 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. 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. funciones. 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. Los Planes de Despliegue del servicio. organización. La Gestión de los datos y la información. 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. 4. La Documentación y Gestión del Conocimiento. . 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. Proveedores externos involucrados (OLAs y UCs) Y toda aquella otra información que se pueda considerar de interés referente a la prestación del servicio. Los resultados recopilados mediante estos sistemas de seguimiento y su análisis posterior. 3.

Modelos de diseño La opción del modelo de desarrollo del servicio puede ser determinante para el éxito o fracaso del mismo. 2. La funcionalidad tiende a ser modular de forma que ésta se pueda ir integrando incrementalmente aportando las siguientes ventajas:   Los módulos pueden ser reutilizables. Existen tres opciones principales. Modelo ágil o RAD El modelo Rápido de Desarrollo es un modelo principalmente incremental e iterativo que se basa en la creación de prototipos. El servicio requiere de un detallado estudio previo de todos los aspectos técnicos y de negocio que evite. Rendimiento: productividad de los procesos y gestión de los recursos utilizados. 1. en la medida de lo posible. ya sea por errores o por una funcionalidad incompleta. Tradicional. la necesidad de cambios. Su principal problema es que las escalas de tiempo involucradas en el desarrollo tradicional pueden ser incompatibles con las escalas de tiempo asociadas naturalmente al mercado. Permite un desarrollo distribuido que facilite la incorporación de proveedores externos en el proceso.  El concepto de prototipo implica que el proceso será por naturaleza iterativo y existirán múltiples versiones que irán incorporando progresivamente los requisitos del cliente. 3. Modelo tradicional Presupone una mayor estabilidad del servicio. El cliente tiene acceso más rápido a la funcionalidad aunque ésta pueda ser reducida lo que facilita su feedback desde las primeras fases de desarrollo. Su principal problema reside en que al no estar completamente cerrada desde un principio su arquitectura se puede entrar en un proceso inacabable de prototipos que no culmine en un servicio adecuado para su paso a producción. Ágil y Empaquetado que describimos brevemente a continuación. Soluciones empaquetadas Existen en la actualidad muchas soluciones TI empaquetadas que simplifican el proceso de diseño del servicio. El servicio o producto puede ser técnica y funcionalmente estable pero resultar obsoleto antes de su entrada en producción. Sus ventajas se resumen en: .

proveedores.    . Configurable. Gestión de Niveles de Servicio: responsable de acordar y garantizar los niveles de calidad de los servicios TI prestados. Gestión de la Disponibilidad: responsable de garantizar que se cumplen los niveles de disponibilidad acordados en los SLA. Sus principales inconvenientes suelen residir en:    Dificultades de integración con otros servicios/plataformas. estatus. etcétera. Potenciales altos costes de personalización y posibles incompatibilidades con las actualizaciones. Perspectivas de negocio. Gestión de la Capacidad: responsable de garantizar que la organización TI dispone de la capacidad suficiente para prestar los servicios acordados. Condiciones del mercado. Insuficiente funcionalidad debida a necesidades muy específicas. Cuestiones financieras. Procesos 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. Actualizaciones periódicas.    Disponible rápidamente. Generación de valor. Requisitos del cliente. La elección de uno u otro modelo de desarrollo para cada servicio es una de las principales decisiones del Diseño del Servicio y se optará por una u otra dependiendo de múltiples factores tales como:       Decisiones estratégicas basadas en la criticalidad del servicio. Costes (iniciales) reducidos.

confidencialidad y disponibilidad de la información. Puede ser utilizado como herramienta de venta. al ser de carácter interno.    Las interacciones y funcionalidades del Catálogo de Servicios se resumen sucintamente en el siguiente interactivo: . Sin embargo. tal y como hemos visto. presta o prestará la organización. pues es necesario alinear aspectos técnicos con políticas de negocio.   Gestión del Catálogo de Servicios Visión general El Portfolio de Servicios. Gestión de la Seguridad de la Información: responsable de establecer las políticas de integridad. Delimita las funciones y compromisos de la organización TI. ofreciendo una descripción detallada de todos los servicios que se prestan y los recursos asignados para ello. no sólo contiene información sobre el funcionamiento de la organización que no interesa a los clientes. es un documento imprescindible puesto que:  Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades. sino que está además escrito en un lenguaje demasiado técnico que no es adecuado ni eficaz para la comunicación externa. Evita malentendidos entre los diferentes actores implicados en la prestación de servicios. el Portfolio de Servicios incluye información sobre todos los servicios que alguna vez ha prestado. proporciona una referencia estratégica y técnica clave dentro de la organización TI. pero de cara al exterior. mientras que el Catálogo prescinde de aquellos retirados o inactivos y se centra en los que pueden interesar a los clientes. La elaboración de este Catálogo de Servicios puede resultar una tarea compleja. 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. El Catálogo de Servicios cumple exactamente la misma función. Gestión de Proveedores: responsable de la relación con los proveedores y el cumplimiento de los UCs. La existencia de dos documentos tan similares se explica porque el Portfolio de Servicios. Además.

.

los Acuerdos de Niveles de Servicio y los precios en vigor.    . Ha de recoger también otras políticas y condiciones de prestación de los servicios. en líneas generales. Ser utilizado como guía para orientar y dirigir a los clientes.Gestión del Catálogo de Servicios Introducción y Objetivos El objetivo principal del Catálogo de Servicios es compendiar toda la información referente a los servicios que los clientes deben conocer para asegurar un buen entendimiento entre éstos y la organización TI. el Catálogo de Servicios debe:  Describir los servicios ofrecidos de manera comprensible para personal no especializado. Incluir. poniendo especial cuidado en evitar el lenguaje técnico. Registrar los clientes actuales de cada servicio. así como las responsabilidades asociadas a cada uno de éstos. Para cumplir ese cometido.

  Por otro lado. Al estar mejor informado sobre los recursos asociados a la prestación de un servicio. El Catálogo de Servicios no se actualiza con suficiente frecuencia. algo crucial a la hora de renovar o ampliar el contrato de prestación servicios. por lo que en la práctica resulta ineficaz. qué servicios están en activo y cuáles han sido retirados definitivamente. De este modo. El Catálogo de Servicios revela aspectos internos sobre el funcionamiento de la organización que no interesa que los clientes conozcan. El Catálogo de Servicios de Negocio . el cliente puede comprender de manera más precisa los costes asociados al mismo. Encontrarse a disposición del Centro de Servicios y de todo el personal que se halle en contacto directo con los clientes. bien dentro de la organización. ya que es el principal encargado del trato con los clientes. Esto es especialmente crítico si es el Centro de Servicios el que no hace uso de él. se evitan situaciones de “vacío de poder” en las que el cliente no sabe a quién acudir. El Catálogo de Servicios.     Conceptos básicos Sistema de Gestión de la Configuración Muchas organizaciones integran el Portfolio y el Catálogo de servicios en una herramienta que recibe el nombre de Sistema de Gestión de la Configuración (CMS). Esto ayuda a incrementar su confianza hacia la organización. la información contenida en ellos puede ser utilizada por otras herramientas de gestión. No ha arraigado entre el personal la costumbre de consultar el Catálogo a la hora de recabar información sobre un servicio. se evitan malentendidos y abusos por ambas partes. contiene jerga técnica o alude a conceptos demasiado especializados. pese a los esfuerzos iniciales. plazos e hitos y entregables contratados para el servicio). las principales dificultades que pueden surgir en relación al Catálogo de Servicios son:  No está claro. Los principales beneficios de crear. mantener y utilizar un Catálogo de Servicios se pueden resumir en que la relación entre la organización y el cliente gana en fluidez y solidez porque:  Al poner por escrito de forma detallada los acuerdos alcanzados (características. Al poner por escrito los responsables de cada servicio. bien en el Portfolio.

registro de los servicios en activo y de la documentación asociada a los mismos. Mantenimiento y actualización del Catálogo de Servicios  El siguiente diagrama muestra los procesos implicados en la correcta Gestión del Catálogo de Servicios: . componentes. Proceso Las principales actividades de la Gestión del Catálogo de Servicios se resumen en:  Definición de las familias principales de servicios a prestar.Se denomina Catálogo de Servicios de Negocio a la información contenida en el Catálogo de Servicios que se refiere a los procesos de negocio. El Catálogo de Servicios Técnico Se denomina Catálogo de Servicios Técnico a aquellos aspectos del Catálogo de Servicios que abordan los propios servicios TI: distinción entre servicios de apoyo. elementos de configuración. etc. etc. servicios compartidos. Esta parte del catálogo tan sólo está disponible para la organización: los clientes no pueden consultarla. las relaciones entre unidades de negocio.

Proceso Definición de servicios El primer paso a la hora de definir el Catálogo de Servicios consiste en tomar los servicios recogidos en el Portfolio de Servicios y discriminar la parte “histórica”, es decir, los registros que se refieren a servicios que ya no están en activo. El siguiente punto consiste en trazar las líneas de servicio o familias principales en las que éstos se van a agrupar. Generalmente, las familias de servicios están relacionadas con las áreas funcionales en las que se desarrollan éstos. Esto aporta una visión de conjunto sobre los servicios que presta la organización, lo cual es un arma de doble filo. Si la estrategia es clara y se ha puesto en práctica con rigor a la hora de definir los servicios, de un solo vistazo al Catálogo quedarán patentes los fines de la organización. Sin embargo, si ha habido improvisación también quedará al descubierto al no existir denominadores comunes claros entre unos servicios y otros. Una vez establecido el primer nivel, el de las familias, se van detallando los servicios existentes en cada una de ellas, así como los clientes que los han contratado y la demanda prevista para cada servicio. A continuación, ofrecemos un listado resumido de los datos que debe contener el Catálogo para cada servicio:
     

Nombre y descripción. Propietario del servicio. Cliente. Otras partes implicadas (proveedores, instituciones, etc.) Fechas de versión y revisión. Niveles de servicio acordados (tiempos de respuesta, disponibilidad, continuidad, horarios, etc.) en los OLAs y SLAs. Condiciones de prestación del servicio. Precios. Cambios y excepciones.

 

Es importante insistir en que el lenguaje empleado debe ser comprensible para aquellos que no están familiarizados con la jerga técnica.

Sin embargo, en la mayoría de los casos, por muy detallado y completo que sea el Catálogo de Servicios, la complejidad de los servicios ofrecidos requiere un largo y extenso periodo de negociación con el cliente.

Mantenimiento y actualización del Catálogo de Servicios Al margen de la confección del propio Catálogo de Servicios, la gestión del mismo conlleva el desempeño de otras tareas relacionadas con su utilización y aprovechamiento que no deben pasarse por alto. En primer lugar es necesario definir en detalle los destinatarios y el propósito de la información detallada en el Catálogo. Estos planteamientos deben transmitirse después a la Gestión del Conocimiento para que organice sesiones formativas: qué contiene el catálogo, en qué casos puede resultar de utilidad, etc. Por otro lado, la Gestión del Catálogo de Servicios debe planificar las tareas de actualización de la información consignada en él. Además de programar revisiones periódicas, deben estipularse de antemano los casos que pueden requerir una “actualización extraordinaria” y los protocolos para la aprobación de estos cambios. Entre los puntos que pueden precisar actualizaciones al margen de las revisiones, destacan aquellos que o bien son críticos, o bien suelen cambiar con mucha frecuencia:
   

Estado de los servicios (“aprobado”, “en preparación”, etc.). Responsables de los servicios. Precios. Proveedores.

Control del proceso La creación y mantenimiento del Catálogo de Servicios también pueden tener un mayor o menor rendimiento, que puede medirse a través de los siguientes indicadores:
 

Nº de actualizaciones enviadas al Portfolio de Servicios. Nº de modificaciones efectuadas en el Catálogo de Servicios en un periodo determinado. Nº de accesos o solicitudes de consulta del Catálogo dentro de la organización TI.

Gestión de Niveles de Servicio Visión general El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente. La tecnología, al menos en lo que respecta a la gestión de servicios TI, no es un fin en sí misma sino un medio para aportar valor a los usuarios y clientes. La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de negocio y todo ello a unos costes razonables. Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de Servicio:
  

Conozca las necesidades de sus clientes. Defina correctamente los servicios ofrecidos. Monitorice la calidad del servicio respecto a los objetivos establecidos en los SLAs.

.

Introducción y Objetivos La Gestión de Niveles de Servicio es el proceso por el cual se definen. negocian y supervisan la calidad de los servicios TI ofrecidos. La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidades y expectativas del cliente y los costes de los servicios asociados. de forma que estos sean asumibles tanto por el cliente como por la organización TI. .

La Gestión de Niveles de Servicio debe:     Documentar todos los servicios TI ofrecidos. (SLAs) Establecer los indicadores claves de rendimiento del servicio TI. Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los servicios requeridos. Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades. Monitorizar la calidad de los servicios acordados con el objetivo último de mejorarlos a un coste aceptable por el cliente. Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del Servicio (SIP).     Los principales beneficios de una correcta Gestión de Niveles de Servicio son: . Centrarse en el cliente y su negocio y no en la tecnología. Presentar los servicios de forma comprensible para el cliente.

en una mejora del servicio con la consecuente satisfacción de clientes y usuarios. Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en:  No existe una buena comunicación con clientes y usuarios. Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente. Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos de actuación en caso de deterioro del servicio. pues la dirección los considera como un gasto añadido y no como parte integral del servicio ofrecido. impidiendo los malentendidos sobre las características y calidad de los servicios ofrecidos. lo que facilita los acuerdos con proveedores y subcontratistas.etc. Se establecen claramente las responsabilidades tanto de los clientes como de los proveedores del servicio. Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante los clientes.OLAs.      . incumpliendo así sus objetivos primordiales. Se facilita la comunicación con los clientes. Los SLAs son excesivamente prolijos y técnicos. Se establecen objetivos claros y cuantificables. La gestión TI conoce y comprende los servicios ofrecidos. Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente. La constante monitorización del servicio permite detectar los "eslabones más débiles de la cadena" para su mejora. por lo que los SLAsacordados no recogen sus necesidades reales.) para llevar una relación fluida con clientes y proveedores. a la larga. No se dedican los recursos suficientes. El personal del Centro de Servicios dispone de la documentación necesaria (SLAs. No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente. Problemas de comunicación: no todos los usuarios conocen las características del servicio y los niveles de calidad acordados.         Estos beneficios repercuten.

primordialmente. asegurando que estos se alineen con los procesos de negocio y mantengan unos niveles de calidad adecuados. Acuerdo de Nivel de Servicio (SLA) El SLA debe recoger en un lenguaje no técnico. Indicadores clave de rendimiento. En resumen. No existe en la organización un verdadero compromiso con la calidad del servicio TI ofrecido. sirviendo de documento de base para la elaboración de los OLAs yUCs correspondientes. Hojas de Especificación Las Hojas de Especificación son. el SQP debe contener la información necesaria para que la organización TI conozca los procesos y procedimientos involucrados en el suministro de los servicios prestados. o cuando menos comprensible para el cliente. dificultando así la mejora de la calidad del servicio. . No se monitoriza adecuada y consistentemente el cumplimiento de los SLAs. Procedimientos de monitorización de proveedores.  Conceptos básicos Requisitos de Nivel de Servicio (SLR) 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 OLAscorrespondientes. todos los detalles de los servicios brindados. Estimación de recursos. Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de determinados procesos. Plan de Calidad del Servicio (SQP) 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. documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.

Herramientas para la monitorización de la calidad del servicio. El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a disposición de los gestores de los otros procesos TI.Tras su firma. Análisis e identificación de las necesidades del cliente. tiempos de recuperación. Hojas de Especificación del Servicio y Plan de Calidad del Servicio (SQP). etc. por tanto. Elaboración del los Requisitos de Nivel de servicio (SLR). 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. 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. Elaboración de un catálogo de servicios.  Implementación de los Acuerdos de Niveles de Servicio: o o Negociación. Proceso Las principales actividades de la Gestión de Niveles de Servicio se resumen en:  Planificación: o o o o o o Asignación de recursos. Acuerdos de Nivel de Operación. Contrato de Soporte (UC) Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización TI. es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción. disponibilidad. Desarrollo de SLAs tipo. niveles de calidad. . Programa de Mejora del Servicio (SIP) 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.

. Control de los proveedores externos.o  Contratos de Soporte. Supervisión y revisión de los Acuerdos de Nivel de Servicio: o o o Elaboración de informes de rendimiento. Elaboración de Programas de Mejora del Servicio (SIP). Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.

Planificación de la Gestión .

que pasamos a describir sucintamente a continuación.La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los estamentos de la organización TI. Etc. resulta imprescindible la colaboración activa de los clientes y usuarios de los servicios TI. La continuidad del servicio. . 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? La respuesta a cada una de estas preguntas debe darse en forma de documentos. Tiempo y procedimientos de implantación del servicio. La interacción del servicio con su infraestructura TI o de otro tipo. Los niveles de calidad del servicio. negociar y monitorizar la calidad de los servicios TI ofrecidos. La escalabilidad del servicio ofrecido. Si los servicios no se adecuan a las necesidades del cliente. la calidad de los mismos es deficiente o sus costes son desproporcionados. La disponibilidad del servicio. si esto no fuera ya de por sí una labor lo suficientemente compleja. Los resultados de esta interacción/negociación deben ser incorporados al documento de Requisitos de Nivel de Servicio (SLR). El objetivo primordial de la Gestión de Niveles de Servicio es definir. Y. que debe reflejar las necesidades del cliente y sus expectativas respecto a:         La funcionalidad y características del servicio. algunos de carácter interno y otros accesibles a los clientes. tendremos clientes insatisfechos y la organización TI será responsable de las consecuencias que se deriven de ello.

Cómo se implementará el servicio. ya sea en el lado del cliente o en el del proveedor.   Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su infraestructura. Niveles de Operación y Contratos de Soporte. Es conveniente estructurar los SLAs más complejos en diversos documentos. sobre como se prestará el servicio. 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. Estos acuerdos incluyen los Acuerdos de Nivel de Servicio. Cuáles serán los indicadores internos de rendimiento y calidad del servicio. esta información deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de acordarse con el cliente y sus responsables técnicos. 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. el SQP servirá de documento guía para el establecimiento de los contratos con los proveedores externos. con todos los detalles técnicos necesarios. Las Hojas de Especificación del Servicio deben contener:  Una descripción detallada. 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. En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportuno externalizar parte de los servicios. de forma que cada grupo involucrado reciba exclusivamente la información correspondiente al nivel en que se integra. 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.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. . 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.

etc. 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. SQP. Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con anterioridad unos baremos de calidad del servicio que han de servir de guía en la elaboración de los informes correspondientes. A pesar de esta diferencia crucial. . los Contratos de Soporte deben representar compromisos claros y perfectamente delimitados. SIP. Monitorización de Niveles de Servicio El proceso de monitorización de Niveles de Servicio es imprescindible si queremos mejorar progresivamente la calidad del servicio ofrecido. 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.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. involucra detalles sobre la prestación del servicio que deben ser opacos para el cliente pero que resultan imprescindibles a la organización TI para desarrollar y coordinar su labor. Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo. Contratos de Soporte Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de prestación de servicios. en el sentido de que persiguen el mismo fin: organizar los procesos y procedimientos necesarios para la correcta provisión del servicio. los UCs pueden considerarse como una extensión "externa" de los OLAs. El OLA. por su naturaleza. SLRs. UCs. Las principales fuentes de información las constituyen:  La documentación disponible: SLAs. Aspectos organizativos del proveedor y cliente. Aspectos culturales locales. su rentabilidad y la satisfacción de los clientes y usuarios. OLAs.

pero esto no se puede llevar a cabo sin una buena gestión de los procesos involucrados. que mediante su trato diario con los clientes. El Centro de Servicios (Service Desk). Esta función entronca con la última fase del ciclo de vida. Es esencial disponer de: . La Gestión de Incidencias y la Gestión de Problemas. La Gestión de la Continuidad y la Gestión de la Disponibilidad. Control del proceso El objetivo de la Gestión de Niveles de Servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del cliente. Costes reales del servicio ofrecido. Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OLAs. que deben proporcionar la información sobre la infraestructura utilizada para satisfacer la calidad de servicios acordada. usuarios y organización TI supervisa la calidad de los servicios y conoce la percepción del cliente respecto a los mismos. Quejas. Disponibilidad del servicio. elaborar un Programa Mejora del Servicio (SIP). que deben informar de las incidencias en el servicio y los tiempos de recuperación. Problemas detectados y cambios realizados para restaurar la calidad del servicio. Tiempos de respuesta.   Los informes de rendimiento elaborados deben cubrir factores clave tales como:  Cumplimiento de los SLAs. En este último tramo del proceso se trata de revisar aquellos SLAs que se han incumplido buscando las razones para. a partir de este análisis. con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio. de los clientes y usuarios. Utilización de la capacidad predefinida. la de Mejora Continua del Servicio. justificadas o no.        Revisión de la calidad de los servicios La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de la calidad de los servicios ofrecidos.

Una asignación clara de tareas y responsabilidades.  Unos objetivos claros y contrastables. o o La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Niveles de Servicio y aporta información de vital importancia a otras áreas involucradas en el soporte y la provisión de los servicios TI. etc. Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la calidad del servicio. . los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración. sus resultados y el grado de satisfacción de los clientes con el servicio prestado. Un equipo con experiencia liderado por un Gestor del Nivel de Servicio con la cualificación y experiencia necesarios.   Gestión de la Capacidad Visión general La Gestión de la Capacidad es la encargada de que todos los servicios TI se vean respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada. O aún peor. Encuestas de satisfacción del cliente. Informes de Seguimiento: donde se especifiquen las acciones de monitorización realizadas. OLAs y UCselaborados y el nivel de cumplimiento de los mismos. 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. SIPs elaborados e impacto de los mismos en la calidad del servicio. los recursos son insuficientes con la consecuente degradación de la calidad del servicio. Sin una correcta Gestión de la Capacidad. costes promedio asociados al proceso. Indicadores específicos de rendimiento tales como: o o   Porcentaje de servicios amparados bajo SLAs. Entre la documentación generada cabría destacar:  Informes Estadísticos de Rendimiento: donde se detallen los SLAs. 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.

Gestionar y racionalizar la demanda de servicios TI.   Controlar el rendimiento de la infraestructura TI. . Desarrollar planes de capacidad asociados a los niveles de servicio acordados.

.

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. 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. Conocer los planes de negocio y acuerdos de nivel de servicio para prever la capacidad necesaria.Introducción y Objetivos El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes. Para ello. la Gestión de la Capacidad debe:   Conocer el estado actual de la tecnología y previsibles futuros desarrollos.     . Analizar el rendimiento de la infraestructura para monitorizar el uso de la capacidad existente. Gestionar la demanda de servicios informáticos racionalizando su uso.

clientes e informáticos deslumbrados por tecnologías que realmente no necesitan y adquieren pero que obvian aplicaciones. evitar situaciones en las que la productividad se ve mermada por un insuficiente o deficiente uso de las tecnologías existentes. de modestos desembolsos. debido a la reducción de costes en los equipos de . en primera instancia. equipos y servicios que realmente aumentarían la productividad en sus respectivos entornos de trabajo. Una de las principales tareas de la Gestión de la Capacidad es la de matizar la percepción de que la "capacidad es barata". Ambos escenarios son habituales y a menudo se pueden encontrar conviviendo en una misma organización: directivos.La Gestión de la Capacidad intenta evitar situaciones en las que se realizan inversiones innecesarias en tecnologías que no se adecuan a las necesidades reales del negocio o están sobredimensionadas. Aunque el aumento de la capacidad puede requerir. o por el contrario.

La implementación de una adecuada política de Gestión de la Capacidad también se encuentra con algunas serias dificultades:     Información insuficiente para una planificación realista de la capacidad. No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.hardware y aplicaciones informáticas. Se reducen de los gastos de mantenimiento y administración asociados a equipos y aplicaciones que han quedado obsoletos o son innecesarios. Se planifica el crecimiento de la infraestructura adecuándolo a las necesidades reales de negocio. Infraestructuras informáticas distribuidas y excesivamente complejas en las que es difícil un correcto acceso a los datos. evitando así que se pueda resentir la calidad del servicio.     En resumen: se racionaliza la gestión de las compras y mantenimiento de los servicios TI con la consiguiente reducción de costes e incremento en el rendimiento. . a la larga. Se reducen posibles incompatibilidades y fallos en la infraestructura informática. Expectativas injustificadas sobre el ahorro de costes y mejoras del rendimiento. La rápida evolución de las tecnologías puede obligar a una revisión permanente de los planes y escenarios contemplados. Insuficiencia de recursos para la correcta monitorización del rendimiento. 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.    Proceso Las principales actividades de la Gestión de la Capacidad se resumen en:  Desarrollo del Plan de Capacidad y modelado de diferentes escenarios de capacidad. Se evitan gastos innecesarios producidos por compras de "última hora". muy cara. la administración y mantenimiento de infraestructuras desproporcionadas puede resultar. Un correcto establecimiento de las dimensiones de la propia Gestión de la Capacidad: un excesivo celo puede provocar costosos análisis de capacidad que podrían haber sido innecesarios con la compra de nuevo hardware o software.

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 de Recursos (CCM. Supervisión de la capacidad y administración de la Base de Datos de la Capacidad (CDB) contenida en el Sistema de Información de Gestión de la Capacidad (CMIS).   El siguiente diagrama muestra los procesos implicados en la correcta Gestión de la Capacidad: Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI. del inglés Service Capacity Management): que analiza el rendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados. . 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 eficazmente. 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.  Monitorización de los recursos de la infraestructura TI. Gestión de la Capacidad del Servicio (SCM.

.

previsiones de negocio y SLAs existentes. Las previsiones sobre necesidades futuras basadas en tendencias.Planificación de la Capacidad Plan de Capacidad La elaboración del Plan de Capacidad es la tarea principal de la Gestión de Capacidad. El Plan de Capacidad recoge:   Toda la información relativa a la capacidad de la infraestructura TI. .

Realizar modelos y simulaciones sobre diferentes escenarios para llevar a cabo previsiones de carga y repuesta de la infraestructura informática. El nivel de detalle al que se lleve este modelado dependerá de varios factores:     Costes asociados al incremento de la capacidad. software y personal a cada servicio y aplicación. Niveles de rendimiento esperados. en principio. Sopesando los anteriores factores podemos optar por:  Un simple análisis de tendencias que permita evaluar la carga de proceso esperada en la infraestructura informática y escalar consecuentemente su capacidad actual. En esos casos. es imprescindible realizar modelos y simulaciones sobre posibles escenarios de desarrollo futuro que aseguren la correcta escalabilidad de las aplicaciones y hardware. El 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. Costes inherentes al proceso mismo de modelado y simulación. La "criticalidad" de los sistemas implicados. .   Recursos de gestión de la Capacidad Un aspecto esencial de la Gestión de la Capacidad es el de asignar recursos adecuados de hardware. Alcance de los incrementos de capacidad previstos. Aunque. el Plan de Capacidad puede tener una vigencia anual o bianual es importante que se monitorice su cumplimiento para adoptar medidas correctivas en cuanto se detecten desviaciones importantes del mismo. Modelado y Benchmarking Cuanto más compleja sea una infraestructura informática más difícil es prever las necesidades de capacidad futura. El correcto dimensionamiento requiere que la Gestión de la Capacidad disponga de información fiable sobre:   Los niveles de servicio acordados y/o previstos (SLAs). Los cambios necesarios para adaptar la capacidad TI a las novedades tecnológicas y las necesidades emergentes de usuarios y clientes. Realizar benchmarks (pruebas de rendimiento comparativas) con prototipos reales para asegurar la capacidad y el rendimiento de la futura infraestructura.

. o más espacio de almacenamiento. Informes de monitorización de los niveles de servicio. Tanto la información obtenida en estas actividades como la generada a partir de ella por la Gestión de la Capacidad se almacena y registra en la Base de Datos de la Capacidad (CDB). Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicación debido a expectativas injustificadas sobre la tecnología. o ignorando los problemas que pueden conllevar dichos cambios. olvidando que sistemas más complejos implican unos mayores gastos de mantenimiento y administración. etcétera. Se puede caer en el equívoco de que los costes asociados a la capacidad se limitan a la compra de más servidores. Márgenes de seguridad y disponibilidad.    Impacto de la aplicación o servicio en los procesos de negocio del cliente. la Gestión de la Capacidad asegura que se dispondrá de la capacidad necesaria para llevar el proyecto a buen término. Costes asociados a los equipos de hardware y otros recursos TI necesarios. En la fase de diseño de un servicio. Una vez se ha puesto en marcha el servicio. analiza y evalúa el rendimiento y capacidad de la infraestructura TI y con los datos obtenidos optimiza los servicios o eleva una RFC a la Gestión de Cambios. también es la encargada de analizar las tendencias de uso y prever las necesidades futuras. Supervisión de la Capacidad La Gestión de la Capacidad es un proceso continuo e iterativo que monitoriza.

En el caso de que una simple racionalización de la demanda sea suficiente para solventar las posibles deficiencias o incumplimientos de los SLAs. todos aquellos relativos a licencias y otras cuestiones de carácter administrativo. financiera. 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.Monitorización Su objetivo principal es asegurar que el rendimiento de la infraestructura informática se adecua a los requisitos de los SLAs. además de aspectos técnicos. Base de Datos de la Capacidad La Base de Datos de la Capacidad (CDB) debe cubrir toda la información de negocio. La documentación elaborada debe incluir información sobre:    El uso de recursos. 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. técnica y de servicio que reciba y genere la Gestión de la Capacidad relativas a la capacidad de la infraestructura y sus elementos. junto a la Gestión de Cambios y Versiones. de asegurar que el cambio solicitado cumpla los objetivos previstos. Control del proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Capacidad. La monitorización debe incluir. Esto no es óbice para que ambas bases de datos puedan ser "físicamente independientes". Análisis de tendencias en el uso de la capacidad. Optimización y cambios Si se ha optado por solicitar un aumento de la capacidad. será la propia Gestión de la Capacidad la responsable de gestionar ese subproceso. La Gestión de la Capacidad prestará su apoyo en todo el proceso y será corresponsable. . Idealmente la CDB debe estar interrelacionada con la CMDB para que esta última ofrezca una imagen integral de los sistemas y aplicaciones con información relativa a su capacidad. Desviaciones de la capacidad real sobre la planificada.

Como proveedores de servicios TI nos enfrentamos al reto de evolucionar sin apenas margen para el error pues nuestros sistemas han de encontrarse a disposición del cliente prácticamente 24/7. disponibilidad y otros procesos TI.  El éxito de la Gestión de la Capacidad depende de algunos indicadores clave. Métricas establecidas para el análisis de la capacidad y monitorización del rendimiento. cumpliendo los SLAs y todo ello a un coste razonable. Más altos niveles de disponibilidad y seguridad. el rápido desarrollo tecnológico implica una constante renovación de equipos y servicios. Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestros proveedores tecnológicos. Mayor satisfacción de los usuarios y clientes. tanto personales como profesionales. Gestión de la Disponibilidad Visión general Nuestras vidas. Con frecuencia una oferta diferente sólo se encuentra a un par de clics de distancia. entre los que se encuentran:      Correcta previsión de las necesidades de capacidad. La satisfacción del cliente y la rentabilidad de los servicios TI dependen en gran medida de su éxito. Las interacciones y funciones de la Gestión de la Disponibilidad se resumen sucintamente en el siguiente interactivo: . Impacto en la calidad del servicio. La Gestión de la Disponibilidad es responsable de optimizar y monitorizar los servicios TI para que estos funcionen ininterrumpidamente y de manera fiable. Ésta nos permite acceder a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñado hace unos pocos años. Reducción de los costes asociados a la capacidad. Cumplimiento de los SLAs. dependen cada vez más de la tecnología. Por otro lado.

.

.

Garantizar el nivel de disponibilidad establecido para los servicios TI. 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. Monitorizar la disponibilidad de los sistemas TI. Las responsabilidades de la Gestión de la Disponibilidad incluyen:     Determinar los requisitos de disponibilidad en estrecha colaboración con los clientes. Fiabilidad: medida del tiempo durante el cual los servicios han funcionado correctamente de forma ininterrumpida.  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.    .Introducción y Objetivos El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén disponibles y funcionen correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor. Capacidad de mantenimiento: capacidad de recuperar el servicio en caso de interrupción. Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores internos y externos. Proponer mejoras en la infraestructura y servicios TI con el objetivo de aumentar los niveles de disponibilidad.

Los principales beneficios de una correcta Gestión de la Disponibilidad son:      Cumplimiento de los niveles de disponibilidad acordados. Falta de coordinación con los otros procesos. . Se aumentan progresivamente los niveles de disponibilidad. Los objetivos de disponibilidad no están alineados con las necesidades del cliente. la fiabilidad de los CIsinvolucrados. su correcto mantenimiento y la calidad de los servicios internos y externos acordados. Se reduce el número de incidentes. No se dispone de las herramientas de software y personal adecuado. Las principales dificultades con las que topa la Gestión de la Disponibilidad son:       No se monitoriza correctamente la disponibilidad real del servicio. Los proveedores internos y externos no reconocen la autoridad del Gestor de la Disponibilidad por falta de apoyo de la dirección. El cliente percibe una mayor calidad de servicio. No existe compromiso con el proceso dentro de la organización TI. Se reducen los costes asociados a un alto nivel de disponibilidad.La disponibilidad depende del correcto diseño de los servicios TI.

Monitorizar la disponibilidad de los servicios TI. Desarrollar un plan de disponibilidad donde se estimen las futuras a corto y medio plazo.        Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI. Asesorar a la Gestión de Cambios sobre el posible impacto de un cambio en la disponibilidad. . fiabilidad. Elaborar informes de seguimiento con la información recopilada sobre disponibilidad. capacidad de mantenimiento y cumplimiento de OLAs y UCs. Evaluar la capacidad de servicio de los proveedores internos y externos. 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 el impacto de las políticas de seguridad en la disponibilidad.Proceso Entre las actividades que la Gestión de la Disponibilidad se encuentran:   Determinar cuáles son los requisitos de disponibilidad reales del negocio.

.

Determine las franjas horarias de disponibilidad de los servicios TI (24/7. La disponibilidad propuesta debe encontrase en línea tanto con las necesidades reales del negocio como con las posibilidades de la organización TI. Establezca los protocolos de mantenimiento y revisión de los servicios TI.Requisitos de disponibilidad Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de losSLAs. Cuantifique los intervalos razonables de interrupción de los diferentes servicios dependiendo de sus respectivos impactos.). Aunque en principio todos los clientes estarán de acuerdo con unas elevadas cotas de disponibilidad es importante hacerles ver que una alta disponibilidad puede generar unos costes injustificados dadas sus necesidades reales. . Para llevar a cabo eficientemente esta tarea es necesario que la Gestión de la Disponibilidad:   Identifique las actividades clave del negocio. Quizá unas pocas horas sin un determinado servicio pueden representar poco más allá de una pequeña inconveniencia mientras que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la replicación de sistemas u otras medidas igualmente costosas que no van a tener una repercusión real en la rentabilidad del negocio.. 12/5..   Planificación de la disponibilidad .

En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto indeseado sobre los niveles de disponibilidad acordados. . Definiciones relevantes y precisas de las métricas a utilizar. claro está). Un diferente nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados o en las actividades necesarias para suministrar un determinado servicio TI. Para que este plan sea realista. debe contar con la colaboración de los otros procesos TI involucrados. Diseño para la Disponibilidad Es crucial para una correcta Gestión de la Disponibilidad participar desde el inicio en el desarrollo de los nuevos servicios TI de forma que éstos cumplan los estándares plasmados en el Plan de Disponibilidad. Planes de mejora de la disponibilidad.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. Expectativas futuras de disponibilidad. Métodos y técnicas de análisis a utilizar. incurriendo en costes adicionales innecesarios. Mantenimiento y Seguridad Aunque hayamos realizado un correcto diseño de los servicios según el Plan de Disponibilidad y se hayan tomado todas las medidas preventivas necesarias. tarde o temprano. Herramientas para la monitorización de la disponibilidad. Este plan debe recoger:  La situación actual de disponibilidad de los servicios TI. nos habremos de enfrentar a interrupciones del servicio.      Es imprescindible que este plan proponga los cambios necesarios para que se cumplan los estándares previstos y colabore con la Gestión de Cambios y la Gestión de Entregas y Despliegues en su implementación (en caso de ser aprobados. Si éste se diseña sin tener en cuenta futuras necesidades de disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo. 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. Obviamente esta información debe ser actualizada periódicamente.

Las implicaciones del incidente en la infraestructura TI y los procesos necesarios para restaurar el servicio. Monitorización de la disponibilidad La monitorización de la disponibilidad del servicio y la elaboración de los informes correspondientes son dos de las principales actividades de la Gestión de la Disponibilidad. Gestión de las Interrupciones de Mantenimiento Independientemente de las interrupciones del servicio causadas por incidencias. Estas interrupciones programadas pueden afectar a la disponibilidad del servicio y por lo tanto han de ser cuidadosamente planificadas para minimizar su impacto.Aunque la responsabilidad de restaurar el servicio corresponde a la Gestión de Incidencias y las actividades de recuperación han de ser coordinadas por el Centro de Servicios. Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del proceso.   Seguridad Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es una correcta Gestión de la Seguridad. la Gestión de la Disponibilidad debe prestar su asesoramiento mediante planes de recuperación que tengan en cuenta:   Las necesidades de disponibilidad del negocio. Si el servicio es 24/7 y la interrupción es necesaria se debe:  Consultar con el cliente acerca de la franja horaria en la que la interrupción del servicio afectará menos a sus actividades de negocio. En aquellos casos en que los servicios no son 24/7 es obvio que. 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: . La disponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra. deben aprovecharse las franjas horarias de inactividad para realizar las tareas que implican una degradación o interrupción del servicio. es habitualmente necesario interrumpir el servicio para realizar labores de mantenimiento y/o actualización. Es tan importante determinar cuándo el servicio estará disponible como el "quién y cómo" va a utilizarlo. Informar con antelación suficiente a todos los agentes implicados. siempre que ello sea posible. Incorporar dicha información a los SLAs.

Tiempo Medio entre Incidencias (MTBSI): es el tiempo medio transcurrido entre incidentes. aún no hemos aportado un método para cuantificarla. Tiempo Medio entre Fallos (Uptime o MTBF): es el tiempo medio durante el cual el servicio está disponible sin interrupciones.   Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida de la interrupción del servicio. 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. respuesta y resolución. 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. estás métricas deben poder expresarse en términos que el cliente pueda entender. Es habitual definir la disponibilidad en tanto por ciento de la siguiente manera: .   Métodos y Técnicas Aunque llevamos hablando ya un buen rato de disponibilidad. que es igual a la suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos. Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo hasta que la organización TI tiene constancia del mismo. e incluye el tiempo de detección. por lo tanto. Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y que debe poner a disposición del cliente en los informes de disponibilidad correspondientes incluyen:  Tiempo Medio de Parada (Downtime o (MTTR): que es el tiempo promedio de duración de una interrupción del servicio. El Tiempo Medio entre Incidentes es una medida de la fiabilidad del sistema. El cliente debe conocer estas métricas y dar su conformidad a las mismas para evitar malentendidos. En algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" y la interpretación puede diferir entre proveedores y clientes.

. si el servicio es 24/7 y en el último mes el sistema ha estado caído durante 4 horas por tareas de mantenimiento la disponibilidad real del servicio fue: La Gestión de la Disponibilidad tiene a su disposición un buen número de métodos y técnicas que le permiten determinar qué factores intervienen en la disponibilidad del servicio y que le permiten consecuentemente prever qué tipo de recursos se deben asignar para las labores de prevención. Es evidente que este método requiere una CMDB correctamente actualizada. Método de Gestión y Análisis de Riesgos de la CCTA (CRAMM) El CRAMM (siglas de CCTA Risk Analysis and Management Method) tiene como objetivo identificar los riesgos y vulnerabilidades a los que está expuesta la infraestructura TI. así como elaborar planes de mejora a partir de dichos análisis. Por ejemplo.donde: AST se corresponde con el tiempo acordado de servicio. Análisis de Interrupción del Servicio (SOA) El SOA (siglas de Service Outage Analysis) es una técnica cuyo objetivo consiste en analizar las causas de los fallos detectados y proponer soluciones a los mismos. mantenimiento y recuperación. con el objetivo de adoptar contramedidas que los reduzcan o que permitan recuperar rápidamente el servicio en caso de interrupción del mismo. Análisis del Árbol de Fallos (FTA) El FTA (siglas de Failure Tree Analysis) tiene como objetivo estudiar cómo se "propagan" los fallos a través de la infraestructura TI para comprender mejor su impacto en la disponibilidad del servicio. Entre dichas técnicas se cuentan: Análisis del Impacto de Fallo de Componentes (CFIA) El CFIA (siglas de Component Failure Impact Analysis) es un método mediante el cual se identifica el impacto que tiene en la disponibilidad de los servicios TI el fallo de cada elemento de configuración involucrado. DT es el tiempo de interrupción del servicio durante las franjas horarias de disponibilidad acordadas.

Tiempos de reparación y recuperación del servicio. haciendo especial énfasis en aspectos no exclusivamente técnicos ligados directamente a la infraestructura TI. se puede considerar que tiempos de respuesta superiores a 10 segundos son equivalentes a que el sistema esta caído. en el caso de un servicio online de comercio electrónico. . Cumplimiento de los OLAs y UCs en todo lo referente a la capacidad de servicio prestada por los proveedores internos y externos. debido a desastres naturales u otras fuerzas de causa mayor. Control del proceso La Gestión de la Disponibilidad debe elaborar periódicamente informes sobre su gestión que incluyan información relevante tanto para los clientes como para el resto de la organización TI. aunque estrictamente hablando el sistema termine respondiendo. Cumplimiento de los SLAs en todo lo referente a la disponibilidad y fiabilidad del servicio.Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente. Gestión de la Continuidad de Servicios TI Visión general La Gestión de la Continuidad del Servicio se preocupa de impedir que una imprevista y grave interrupción de los servicios TI. tenga consecuencias catastróficas para el negocio. Estos informes deben incluir:   Técnicas y métodos utilizados para la prevención y el análisis de fallos. Por ejemplo.   Disponibilidad real de los diferentes servicios. Tiempo medio de servicio entre fallos.  Para que toda esta información sea fácil y correctamente analizada es imprescindible el establecimiento de métricas precisas que permitan determinar de forma inequívoca parámetros tales como tiempos de parada y funcionamiento. La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamente procedimientos:  Proactivos: que buscan impedir o minimizar las consecuencias de una grave interrupción del servicio. Información estadística sobre: o o o Tiempos de detección y respuesta a los fallos.

 Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea posible (y recomendable) tras el desastre. La ITSCM requiere una implicación especial de los agentes involucrados pues sus beneficios sólo se perciben a largo plazo. . es costosa y carece de rentabilidad directa. Implementar laITSCM es como contratar un seguro médico: cuesta dinero. pero tarde o temprano nos alegramos de haber sido previsores. parece inútil mientras uno está sano y desearíamos nunca tener que utilizarlo.

.

tales como los producidos por ataques distribuidos de denegación de servicio (DDOS). inundaciones. etcétera. aunque a menudo muy importante. virus informáticos. y desastres "puramente informáticos". del negocio en su conjunto y no tiene mayor sentido que. en la medida de lo posible. Es importante diferenciar entre desastres "de toda la vida". es importante valorar los costes relativos y la incidencia real en la continuidad del negocio para decantarse por una de ellas o por una sabia combinación de ambas. Aunque. etcétera. las políticas proactivas que prevean y limiten los efectos de un desastre sobre los servicios TI son preferibles a las exclusivamente reactivas. Una correcta ITSCM debe formar parte integrante de la Gestión de Continuidad del Negocio (BCM) y debe estar a su servicio.ntroducción y Objetivos Los objetivos principales de la Gestión de la Continuidad de los Servicios TI (ITSCM) se resumen en:   Garantizar la pronta recuperación de los servicios (críticos) TI tras un desastre. a priori. Aunque es responsabilidad de la ITSCM prever los riesgos asociados en ambos casos y restaurar el servicio . las perniciosas consecuencias de un desastre o causa de fuerza mayor. Establecer políticas y procedimientos que eviten. Los servicios TI no son sino una parte. tales como incendios. por ejemplo. un sistema de pedidos online siga funcionando a la perfección tras un desastre si nos resulta imposible suministrar la mercancía a nuestros clientes.

Son más previsibles y más habituales. Evaluar el impacto en el negocio de una interrupción de los servicios TI. Analizar y prever los riesgos a los que esta expuesto la infraestructura TI. aunque esto no sea siempre cierto. No existe el compromiso suficiente con el proceso dentro de la organización y las tareas y actividades correspondientes se demoran perpetuamente para hacer frente a "actividades más urgentes". La percepción del cliente es diferente: los desastres naturales son más asumibles y no se asocian a actitudes negligentes. No se asignan los recursos suficientes. No se presupuestan correctamente los costes asociados.TI con prontitud. Sirve de apoyo al proceso de Gestión de la Continuidad del Negocio (BCM). Falta de coordinación con la BCM. No se realiza un correcto análisis de riesgos y se obvian amenazas y vulnerabilidades reales.    Proceso Las principales actividades de la Gestión de la Continuidad de los Servicios TI se resumen en:    Establecer las políticas y alcance de la ITSCM. . Las principales dificultades a la hora de implementar la Gestión de la Continuidad del Servicio se resumen en:     Puede haber resistencia a realizar inversiones cuya rentabilidad no es inmediata. Se mejora la confianza en la calidad del servicio entre clientes y usuarios. Se reduce el periodo de interrupción del servicio por causas de fuerza mayor. El personal no esta familiarizado con las acciones y procedimientos a tomar en caso de interrupción grave de los servicios. es evidente que recae sobre la ITSCM una responsabilidad especial en el último caso pues:    Sólo afectan directamente a los servicios TI pero paralizan a toda la organización. Los principales beneficios de una correcta Gestión de la Continuidad del Servicio se resumen en:     Se gestionan adecuadamente los riesgos.

 Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.     Establecer las estrategias de continuidad del servicio TI. Formar al personal sobre los procedimientos necesarios para la pronta recuperación del servicio. Revisar periódicamente los planes para adaptarlos a las necesidades reales del negocio. Adoptar medidas proactivas de prevención del riesgo. . Desarrollar los planes de contingencia. Poner a prueba dichos planes.

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.Política y Alcance El primer paso necesario para desarrollar una Gestión de la Continuidad del Serviciocoherente es establecer claramente sus objetivos generales. su alcance y el compromiso de la organización TI: su política.

Las expectativas de negocio. Otros efectos secundarios. Cuanto mayor sea el impacto asociado a la interrupción de un determinado servicio mayor habrá de ser el esfuerzo realizado en actividades de prevención. dependen en mayor o menor medida de los servicios informáticos.  Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos de negocio.     Los servicios TI estratégicos. Su dimensión depende de su alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa que no dispusiera de los recursos correspondientes. por lo que cabe esperar que un "apagón" de los servicios TI afecte a prácticamente todos los aspectos del negocio. Los servicios TI han de ser analizados por la ITSCM en función de diversos parámetros:  Consecuencias de la interrupción del servicio en el negocio: o o o o Pérdida de rentabilidad. Una importante parte del esfuerzo debe destinarse a la formación del personal. grandes y pequeñas. tanto en el plano humano como de equipamiento (software y hardware). Éste debe interiorizar su papel en momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergencia no es el mejor momento para estudiar documentación y manuales. Sin embargo. 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. Los estándares de calidad adoptados. es evidente que hay servicios TI estratégicos de cuya continuidad puede depender la supervivencia del negocio y otros que "simplemente" aumentan la productividad de la fuerza comercial y de trabajo. Pérdida de cuota de mercado. En la actualidad casi todas las empresas. Mala imagen de marca. La disponibilidad de recursos. . La Gestión de la Continuidad del Servicio está abocada al fracaso sino se destina una cantidad de recursos suficientes. En aquellos casos en que la "solución puede esperar" se puede optar exclusivamente por planes de recuperación. El histórico de interrupciones graves de los servicios TI.

La prevención frente a riesgos genéricos y poco probables puede ser muy cara y no estar siempre justificada. 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. las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas. 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. sin embargo. los diferentes riesgos factores de riesgo. de rápida implementación y relativamente baratas. La Gestión de la Continuidad del Servicio debe enumerar y evaluar. Detectar los puntos más vulnerables de la infraestructura TI. si el riesgo de perdida de alimentación eléctrica es elevado debido. Analizar las posibles amenazas y estimar su probabilidad. Compromisos adquiridos a través de los SLAs. a la localización geográfica se puede optar por deslocalizar ciertos servicios TI a través de ISPsque dispongan de sistemas de generadores redundantes o adquirir generadores que . dependiendo de su probabilidad e impacto. Dependiendo de estos factores se buscará un balance entre las actividades de prevención y recuperación teniendo en cuenta sus respectivos costes financieros. especialmente los servicios TI críticos y estratégicos.   Gracias a los resultados de este detallado análisis se dispondrá de información suficiente para proponer diferentes medidas de prevención y recuperación que se adapten a las necesidades reales del negocio. Por ejemplo. por ejemplo.

etcétera. etcétera. En líneas generales existen tres opciones de recuperación del servicio:  Cold standby: que requiere un emplazamiento alternativo en el que podamos reproducir en pocos días nuestro entorno de producción y servicio.  . etcétera. Los sistemas de protección habituales son los de "Fortaleza" que ofrecen protección perimetral a la infraestructura TI. Aunque imprescindibles no se hallan exentos de sus propias dificultades pues aumentan la complejidad de la infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades. que eviten la interrupción de los servicios. La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con la Gestión de la Continuidad del Negocio (BCM) y requieren medidas que implican a la infraestructura "física" de la organización. Actividades preventivas Las medidas preventivas requieren un detallado análisis previo de riesgos y vulnerabilidades. Actividades de recuperación Tarde o temprano. Warm standby: que requiere un emplazamiento alternativo con sistemas activos diseñados para recuperar los servicios críticos en un plazo de entre 24 y 72 horas. Esta opción es la adecuada si los planes de recuperación estiman que la organización puede mantener sus niveles de servicio durante este periodo sin el apoyo de la infraestructura TI.proporcionen la energía mínima necesaria para alimentar los CIs de los que dependen los servicios más críticos. En este aspecto es esencial la estrecha colaboración con la Gestión de la Seguridad. mientras que otros tendrán un carácter estrictamente informático: fallo de sistemas de almacenamiento. desastres naturales. La prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren especial atención de la ITSCM. Estrategias de Continuidad La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas. o medidas reactivas. Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención y recuperación que ofrezcan las garantías necesarias a unos costes razonables. ataques de hackers. virus informáticos. que recuperen unos niveles aceptables de servicio en el menor tiempo posible. será necesario poner en marcha procedimientos de recuperación. por muy eficientes que seamos en nuestras actividades de prevención. Algunos de ellos serán de carácter general: incendios.

analizados los riesgos y vulnerabilidades y definidas unas estrategias de prevención y recuperación es necesario asignar y organizar los recursos necesarios. Plan de gestión de emergencias Las crisis suelen provocar "reacciones de pánico" que pueden ser contraproducentes y a veces incluso más dañinas que las provocadas por el incidente que las causó. Ésta es evidentemente la opción mas costosa y debe emplearse sólo en el caso de que la interrupción del servicio TI tuviera inmediatas repercusiones comerciales. 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 recuperación. Políticas de back-ups. Por supuesto. 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. existe otra alternativa que consiste en hacer "poco o nada" y esperar que las aguas vuelvan naturalmente a su cauce: una alternativa poco recomendable para alguien que esté hojeando este curso sobre ITIL y del que suponemos que los servicios TI jugarán un papel importante en su organización :-) Organización y Planificación Una vez determinado el alcance de la ITSCM. Sistemas de alimentación eléctrica de soporte. Hot standby: que requiere un emplazamiento alternativo con una replicación continua de datos y con todos los sistemas activos preparados para la inmediata sustitución de la estructura de producción. Por ello es imprescindible que en caso de situación de emergencia estén claramente determinadas las responsabilidades y funciones del personal así como los protocolos de acción correspondientes. Sistemas de seguridad pasivos. . Plan de gestión de emergencias. Duplicación de sistemas críticos.

Recuperar los datos y reiniciar el servicio TI. Reestablecer los sistemas de hardware y software necesarios.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. Planes de seguridad que garanticen la integridad de los datos. 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"). Supervisión de la Continuidad .   Plan de recuperación Cuando la interrupción del servicio es inevitable. Instalaciones y hardware alternativos. Comunicación a los usuarios y clientes de una grave interrupción o degradación del servicio. llega el momento de poner en marcha los procedimientos de recuperación. Protocolos de comunicación con los clientes. pero en general involucran:       Asignación de personal y recursos. Ya conocen el dicho: "No hay mal que por bien no venga". Asignación de funciones de emergencia al personal del servicio TI. Protocolos para la puesta en marcha del plan de recuperación correspondiente. Aunque pueda resultar paradójico. incrementar la confianza que tiene depositada en nosotros. Procedimientos de recuperación de datos. Contratos de colaboración con otras organizaciones. cualquier decisión puede tener graves consecuencias tanto en la percepción que de nosotros tengan nuestros clientes como en los costes asociados al proceso. Procedimientos de contacto y colaboración con los proveedores involucrados. un "desastre" puede ser una buena oportunidad para demostrar a nuestros clientes la solidez de nuestra organización TI y por tanto. Cuando se pone en marcha un plan de recuperación no hay espacio para la improvisación. El plan de recuperación debe incluir todo lo necesario para:    Reorganizar al personal involucrado.

Formación Es inútil disponer de unos completos planes de prevención y recuperación si las personas que eventualmente deben llevarlos a cabo no están familiarizadas con los mismos.Una vez establecidas las políticas. Ofrezca formación específica sobre los diferentes procedimientos de prevención y recuperación. La Gestión de Cambios juega un papel esencial a la hora de asegurar que los planes de recuperación y prevención están actualizados. Control del proceso La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión que incluyan información relevante para el resto de la organización TI. Realice periódicamente simulacros para diferentes tipos de desastres con el fin de asegurar la capacitación del personal involucrado. Facilite el acceso permanente a toda la información necesaria. por ejemplo. es indispensable que éstos no queden en papel mojado y que la organización TI esté preparada para su correcta implementación. estrategias y planes de prevención y recuperación. Estos informes deben incluir: . manteniendo informada a la ITSCM de los cambios realizados o previstos.    Actualización y auditorías Tanto las políticas. Ello depende de dos factores clave: la correcta formación del personal involucrado y la continua monitorización y evaluación de los planes para su adecuación a las necesidades reales del negocio. estos procesos de actualización y auditoría pueden establecerse de forma periódica. estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los requisitos de la organización en su conjunto. En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable. a través de la Intranet o portal B2E de la empresa. Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación. Es indispensable que la ITSCM:  Dé a conocer al conjunto de la organización TI los planes de prevención y recuperación.

Actividades de prevención y recuperación realizadas. La información es consustancial al negocio y su correcta gestión debe apoyarse en tres pilares fundamentales: . Sin embargo. especialmente (y desafortunadamente) en tiempos de guerra. La ITSCM debe garantizar:     La puesta en marcha de los planes preestablecidos. Evaluación de los simulacros de desastre realizados. del spam (ya sea por correo electrónico o teléfono) por una deficiente protección de sus datos personales o. la suerte han impedido la existencia de graves interrupciones del servicio. Tras largos periodos en los que la prevención o. Por esto es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial se diluyan y la ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que "un desastre se convierta en una catástrofe". se puede caer en un relajamiento que puede acarrear graves consecuencias. Gestión de la Seguridad de la Información Visión general La Gestión de la Seguridad de la Información se remonta al albor de los tiempos. La supervisión de los mismos. Que levante la mano el que no haya sido victima de algún virus informático en su ordenador. del robo del número de su tarjeta de crédito. La coordinación con la Gestión de Continuidad del Negocio. Preparación y capacitación del personal TI respecto a los planes y procedimientos de prevención y recuperación. Pero si el control del proceso es importante en condiciones normales. éste se vuelve crítico durante las situaciones de crisis. Costes asociados a los planes de prevención y recuperación.     Análisis sobre nuevos riesgos y evaluación de su impacto. desde el advenimiento de las ubicuas redes de comunicación y. simple y llanamente. La asignación de recursos necesarios. aún peor. La criptología o la ciencia de la confidencialidad de la información existe desde el inicio de nuestra civilización y ha ocupado algunas de las mentes matemáticas más brillantes de la historia. Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio es mantener la "concentración". de Internet los problemas asociados a la seguridad de la información se han agravado considerablemente y nos afectan a todos. en especial.

Disponibilidad: debemos de tener acceso a la información cuando la necesitamos. Confidencialidad: la información debe ser sólo accesible a sus destinatarios predeterminados.   La Gestión de la Seguridad debe. Nota: Las interacciones y funciones de la Gestión de la Seguridad se resumen sucintamente en el siguiente interactivo: . esté siempre a disposición del negocio y sea utilizada sólo por aquellos que tienen autorización para hacerlo. Integridad: la información debe ser correcta y completa. velar por que la información sea correcta y completa. por tanto.

.

limitaremos las oportunidades de negocio que nos ofrece el flujo de información entre los diferentes agentes implicados y la apertura de nuevas redes y canales de comunicación. La Gestión de la Seguridad debe conocer en profundidad el negocio y los servicios que presta la organización TI para establecer protocolos de seguridad que aseguren que la información esté accesible cuando es necesaria para aquellos que tengan autorización para utilizarla. . correctamente alineada con las necesidades del negocio. Una vez comprendidos cuáles son los requisitos de seguridad del negocio. la Gestión de la Seguridad debe supervisar que estos se hallen convenientemente plasmados en los SLAscorrespondientes para. Si caemos en la tentación de establecer la seguridad como una prioridad en sí misma. Asegurar el cumplimiento de los estándares de seguridad acordados en los SLAs. a renglón seguido.Introducción y Objetivos Los principales objetivos de la Gestión de la Seguridad se resumen en:  Diseñar una política de seguridad.   La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de "expertos en seguridad" que desconocen los otros procesos de negocio. garantizar su cumplimiento. Minimizar los riesgos de seguridad que amenacen la continuidad del servicio. en colaboración con clientes y proveedores.

Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios. etcétera. Los principales beneficios de una correcta Gestión de la Seguridad:  Se evitan interrupciones del servicio causadas por virus. ataques informáticos.    . etcétera.La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos generales a los que está expuesta la infraestructura TI. Se tiene acceso a la información cuando se necesita y se preserva la integridad de los datos. que no representan un peligro para la continuidad del servicio. para asegurar. en la medida de lo posible. Es importante que la Gestión de la Seguridad sea proactiva y evalúe a priori los riesgos de seguridad que pueden suponer los cambios realizados en la infraestructura. Se minimiza el número de incidentes. nuevas líneas de negocio. y que no necesariamente tienen por qué figurar en un SLA.

nuevos riesgos y vulnerabilidades. lo que impide una correcta evaluación de los riesgos. No se dispone de las herramientas necesarias para monitorizar y garantizar la seguridad del servicio (firewalls.     Proceso La Gestión de la Seguridad está estrechamente relacionada con prácticamente todos los otros procesos TI y necesita para su éxito la colaboración de toda la organización. El personal no recibe una formación adecuada para la aplicación de los protocolos de seguridad.      Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI. antivirus. Las principales dificultades a la hora de implementar la Gestión de la Seguridad se resumen en:  No existe el suficiente compromiso de todos los miembros de la organización TI con el proceso. etc. Falta de coordinación entre los diferentes procesos.). Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados tanto en los servicios prestados a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos. es necesario que la Gestión de la Seguridad:  Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos. Monitorice y evalúe el cumplimiento de dicho plan. Para que esa colaboración sea eficaz. Mejora la percepción y confianza de clientes y usuarios en lo que respecta a la calidad del servicio.  Se cumplen los reglamentos sobre protección de datos. Se establecen políticas de seguridad excesivamente restrictivas que afectan negativamente al negocio. Realice periódicamente auditorías de seguridad. . Supervise proactivamente los niveles de seguridad analizando tendencias. Implemente el Plan de Seguridad.

.

En particular la Política de Seguridad debe determinar: . Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos tales como los objetivos.Política y Plan de Seguridad Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a la Gestión de la Seguridad. responsabilidades y recursos.

Los procedimientos de análisis de riesgos. Este plan ha de ser desarrollado en colaboración con la Gestión del Nivel de Servicio. Aplicación de las Medidas de Seguridad . Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes en todas las fases del servicio y para todos los estamentos implicados. Los programas de formación. "Una cadena es tan resistente como el más débil de sus eslabones". pero esto valdrá de poco si alguien descubre que la "puerta de atrás está abierta". establecer una estrictas normas de acceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. La estructura y responsables del proceso de Gestión de la Seguridad. El alcance del Plan de Seguridad. que es la responsable en última instancia tanto de la calidad del servicio prestado a los clientes como la del servicio recibido por la propia organización TI y los proveedores externos. por ejemplo. Plan de Seguridad El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos como parte de los SLAs.             La relación con la política general del negocio. Quizá con ello podamos engañar a algún cliente durante algún tiempo ofreciendo la imagen de "fortaleza". Los protocolos de acceso a la información. deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad acordados. por lo que carece de sentido. Los responsables de cada subproceso. Los auditores externos e internos de seguridad. Qué informes deben ser emitidos periódicamente. El nivel de monitorización de la seguridad. Siempre que sea posible. El Plan de Seguridad debe ser diseñado con el fin de ofrecer un mejor y más seguro servicio al cliente y nunca como un obstáculo para el desarrollo de sus actividades de negocio. La coordinación con los otros procesos TI. hardware y personal. OLAs y UCs. Los procesos y procedimientos empleados. Los recursos necesarios: software.

Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad. Colaborar con el Centro de Servicios y la Gestión de Incidentes en el tratamiento y resolución de incidentes relacionados con la seguridad. Proponer RFCs a la Gestión de Cambios que aumenten los niveles de seguridad. Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la integridad y confidencialidad de los datos en caso de desastre. Colaborar con la Gestión de Cambios y la de Entregas y Despliegues para asegurar que no se introducen nuevas vulnerabilidades en los sistemas en producción o entornos de pruebas. Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas de seguridad establecidas en la Política y el Plan de Seguridad. Evaluación y mantenimiento Evaluación . En primer lugar la Gestión de la Seguridad debe verificar que:  El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al respecto. Se imparte la formación pertinente.   Es también responsabilidad directa de la Gestión de la Seguridad:    Asignar los recursos necesarios. Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad. Generar la documentación de referencia necesaria. Establecer las políticas y protocolos de acceso a la información. Monitorizar las redes y servicios en red para detectar intrusiones y ataques.Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica.       Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión de la Seguridad respecto a todas estas cuestiones y que incluso permita que ésta proponga medidas disciplinarias vinculantes cuando los empleados u otro personal relacionado con la seguridad de los servicios incumplan con sus responsabilidades.

Aunque no es imprescindible. etcétera. ataques de denegación de servicio. No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas. Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluación arriba citada o de cambios implementados en la infraestructura o servicios TI. y que adopte las medidas necesarias de actualización de equipos de hardware y software. sin olvidar el apartado de formación: el factor humano es normalmente el eslabón más débil de la cadena. sus resultados y el cumplimiento de los SLAs. por lo que resulta indispensable evaluar el cumplimiento de las medidas de seguridad. Independientemente de estas evaluaciones de carácter periódico. Una buena Gestión de la Seguridad debe traducirse en:    Disminución del número de incidentes relacionados con la seguridad. Mantenimiento La Gestión de la Seguridad es un proceso continuo y se han de mantener al día el Plan de Seguridad y las secciones de seguridad de los SLAs. . Gestión proactiva. Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y vulnerabilidades frente a virus. La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridad y aporta información de vital importancia a otras áreas de la infraestructura TI. es necesario realizar un riguroso control del proceso para asegurar que la Gestión de la Seguridad cumple sus objetivos. Un acceso eficiente a la información por el personal autorizado. que permita identificar vulnerabilidades potenciales antes de que estas se manifiesten y provoquen una seria degradación de la calidad del servicio. es recomendable que estas evaluaciones se complementen con auditorías de seguridad externas y/o internas realizadas por personal independiente de laGestión de la Seguridad. De nuevo. si la Gestión de la Seguridad lo considera oportuno. estos informes se acompañaran de las RFCs correspondientes.No es posible mejorar aquello que no se conoce. se deberán generar informes específicos cada vez que ocurra algún incidente grave relacionado con la seguridad. Control del proceso Al igual que en el resto de procesos TI. spyware. Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que se plasmarán en RFCs que habrán de ser evaluados por la Gestión de Cambios.

lo que incluye velar por el cumplimiento de los contratos o actualizarlos si éstos pierden vigencia. Gestionar la relación con los proveedores. coste. Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos. Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI. contratos) esté disponible y permanentemente actualizada.    Por otro lado. de losSLAs. garantizando que queda constancia de los acuerdos financieros y de calidad alcanzados.      Gestión de Proveedores Visión general La Gestión de Proveedores se ocupa de gestionar la relación con los suministradores de servicios de los que depende la organización TI. Definir y negociar los nuevos contratos. Renovar y terminar contratos. Con este fin. que abarca:  Seleccionar nuevos suministradores para las necesidades que vayan surgiendo en el servicio.Entre la documentación generada cabría destacar:  Informes sobre el cumplimiento. en lo todo lo referente al apartado de seguridad. la Gestión de Proveedores se encarga de definir una estrategia de suministradores según la cual orientar su labor. Su principal objetivo es alcanzar la mayor calidad a un precio adecuado. Auditorías de seguridad. Relación de incidentes relacionados con la seguridad. también es la encargada de que toda la información relacionada con los proveedores y los servicios que prestan (tipo. OLAs y UCs en vigor. Evaluación de los programas de formación impartidos y sus resultados. y teniendo siempre muy presentes las pautas marcadas desde la Estrategia del Servicio. El siguiente diagrama interactivo resume sucintamente los principales aspectos de la metodología de la Gestión de Proveedores según los estándares ITIL: . calificados por su impacto sobre la calidad del servicio.

.

.

     Los principales riesgos a los que se enfrenta la Gestión de Proveedores son:  La Gestión de la Demanda no proporciona las directrices básicas para racionalizar el gasto. por lo que si existen retrasos o disminuciones de calidad en el suministro.    Conceptos básicos Proveedores. Asegurar que los contratos y acuerdos con proveedores están alineados con la estrategia y necesidades de negocio de la organización. .Introducción y Objetivos La ventaja principal de una adecuada Gestión de Proveedores radica en que la organización TI obtiene mayores beneficios al contratar a aquellos suministradores que brindan el mejor servicio al menor coste. Mantener una política de proveedores y una Base de Datos de Proveedores y Contratos (SCD). clientes y usuarios Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos. por lo que la Gestión de Proveedores se ve forzada a improvisar los niveles de capacidad a contratar de los suministradores. Los contratos en vigor son demasiado vagos y no contemplan objetivos fácilmente cuantificables como horas de trabajo. Usuarios: las personas que utilizan el servicio. Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el cliente. Negociar los contratos con los proveedores y gestionarlos a lo largo de su ciclo de vida. Gestionar el rendimiento de los proveedores. La Gestión de Proveedores no tiene a su alcance indicadores de rendimiento del servicio o los recibe demasiado tarde. Gestionar la relación con los proveedores. etc. por lo que las negociaciones con los proveedores se tornan auténticas discusiones bizantinas que acaban alargándose demasiado. Los contratos son demasiado exigentes en calidad-precio. no podrá actuar con eficacia para corregirlo. número de entregables. Los principales objetivos de la Gestión de Proveedores consisten en:  Aportar el máximo valor añadido al menor coste en aquellos servicios que prestan los proveedores.

Los procesos de evaluación y selección de proveedores. Proceso La Gestión de Proveedores se ocupa de definir y gestionar:      Los requisitos de contratación que se van a exigir a los proveedores. La clasificación y documentación de la relación con los proveedores. Gestión del Rendimiento de los proveedores Renovación o terminación. Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI. . incluyendo por supuesto copias de los contratos (UCs) en vigor. Es aconsejable que la Base de Datos de Proveedores y Contratos esté integrada en el Sistema de Gestión de la Configuración (CMS) y en el Sistema de Gestión del Conocimiento del Servicio (SKMS).Base de Datos de Proveedores y Contratos (SCD) La Base de Datos de Proveedores y Contratos (SCD) es un repositorio documental donde se archiva toda la información relacionada con los proveedores y los servicios que prestan.

Requisitos de contratación .

Disponibilidad y capacidad. también. Caso de Negocio inicial sobre el que trabajar durante las negociaciones con los proveedores. Evaluación y Selección de proveedores A la hora de elegir un nuevo suministrador han de tenerse en cuenta:     Su adecuación a los requisitos previamente definidos. Aspectos financieros. Es importante que en el UC queden reflejadas las metas y responsabilidades del proveedor de cara al cumplimiento de los SLAs. Una vez recogidos y analizados estos inputs. se deben estudiar a fondo en el Catálogo de Servicios las condiciones del servicio a prestar y el papel que desempeñarán los proveedores en el proceso. Garantizando en todo momento que tanto los requisitos como las premisas básicas de negociación están alineados con la estrategia general de la organización TI. Han de tenerse en cuenta. los niveles de calidad acordados con los clientes desde la Gestión de Niveles de Servicio. y la previsión de la capacidad necesaria para desplegar el servicio que haya definido la Gestión de la Demanda. los informes económicos proporcionados por la Gestión Financiera. Referencias de otros competidores.La primera tarea que la Gestión de Proveedores debe llevar a cabo es analizar las estrategias generales de la organización y los servicios que se prestan para definir las necesidades de contratación. se han de negociar los términos del servicio. Clasificación y Documentación de proveedores Una vez que se han acordado y negociado los servicios de un determinado proveedor. Por último. es preciso crear una Base de Datos de Proveedores y Contratos (SCD) donde se recogerá toda la información relacionada:  Contratos de provisión del servicio (UCs). Una vez elegido el proveedor. El resultado debe quedar reflejado en el Contrato de Provisión del Servicio (UC). . un documento legal que atestigua la relación entre la organización TI y el suministrador. la Gestión de Proveedores debe preparar:   Requisitos que se van a exigir a los proveedores.

Cambios que es preciso acometer: servicios. objetivos. cambio. asesorar a la dirección acerca de si éstos son relevantes y terminar la relación contractual en caso de que ya no se necesiten más los servicios del proveedor. etc. ¿cuál es el procedimiento a seguir para actualizar el CMS?  Renovación o terminación de contratos Esta actividad consiste en llevar a cabo renovaciones de contratos.    Control del proceso Algunos indicadores clave que sirven para evaluar el proceso de Gestión de Proveedores:  Indicadores de que el negocio no se ha visto afectado por el nivel de calidad en los servicios que prestan los proveedores: . táctico (mandos intermedios). terminación. productos. estancamiento. Administración de proveedores y contratos. acuerdos. Relaciones con otros elementos del ciclo de vida. El nivel de actuación del proveedor: Estratégico (directivos). etc. transferencia. se trata de verificar si efectivamente se están cumpliendo los niveles de calidad y disponibilidad acordados en los contratos:   ¿El suministrador se integra adecuadamente a los procesos de la organización TI? ¿Cuál es el procedimiento para informar al proveedor en caso de recibir una incidencia en el Centro de Servicios? Si un elemento de configuración relacionado con el proveedor cambia. estructura de precios. contratos. operativo (nivel ejecutor). Rendimiento comercial del contrato (criterios de cobro.) Buenas prácticas para la gestión de contratos. Perspectivas futuras de la relación con el proveedor: crecimiento.  Gestión del Rendimiento de los proveedores A grandes rasgos. Los aspectos a considerar para tomar la decisión de renovar a un proveedor incluyen:    El buen funcionamiento del contrato y su relevancia de cara al futuro.

o  Indicadores de que la organización es consciente de que pueden aparecer problemas en la gestión de proveedores y conoce quién debe ocuparse de ellos: o Incremento en el número de proveedores para los que se ha asignado un responsable. La continuidad del servicio y la atenuación de riesgos. o  Indicadores de que los servicios de apoyo están alineados con las necesidades y objetivos de la organización: o o Incremento en el número de servicios y revisiones de contrato. Si por limitaciones presupuestarias o cualquier otra causa esto no fuera posible deberán establecerse prioridades dependientes de los planes existentes de Mejora del Servicio. problemas preexistentes de capacidad pueden determinar que este sea el primer proceso a implementar o simplemente mejorar. En cualquier caso la organización TI debe ser consciente de que sin los inputs de los otros procesos cualquiera de éstos implementado de forma aislada corre un alto riesgo de fracaso. Incremento en el número de proveedores y objetivos contractuales alineados con los objetivos contenidos en los SLA y SLR. o Puesta en marcha Los procesos asociados a la fase de Diseño son muy interdependientes entre sí por lo que resulta altamente recomendable su implementación simultánea.  Indicadores de que la disponibilidad de los servicios no se ve comprometida por el rendimiento de los proveedores: o Reducción en el número de interrupciones de servicio provocadas por los proveedores. Por ejemplo.o Incremento en el número de proveedores que alcanzan los objetivos establecidos en el contrato. Reducción en el número de amenazas de interrupción de servicio provocadas por proveedores. Reducción del número de incumplimientos de objetivos contractuales. . Incremento en el número de contratos en los que figura un responsable. en algunos casos. Es esencial que todas las actividades desarrolladas en la fase de diseño esten regidas por:    Los requisitos de los clientes y los SLAs ya en vigor. Las necesidades del negocio.

R o A en múltiples tareas.</strong Informed (Informado): Las personas que deben ser informadas sobre el progreso de ejecución de la tarea. Tener objetivos bien definidos. 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. Establecer métricas que permitan evaluar el proceso. Si esto no fuera así la tarea se subdividirá hasta que así sea. Un ejemplo de matriz RACI viene dado por: . RACI Para que la fase de diseño resulte exitosa es imprescindible organizar adecuadamente todos los procesos y actividades implicados. Accountable (Responsable): es el único responsable de la correcta ejecución de la tarea. Saber en qué posición nos encontramos.Es imprescindible seguir una metodología adecuada en la fase de implementación. Disponer de mecanismos de mejora. El modeloCSI ofrece una guía para ello:       Disponer de una clara estrategia. Por supuesto una persona puede ser.   En cada tarea debe haber un único R y A. 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. <strongConsulted (Consultado): las personas que deben ser consultadas para la realización de la tarea. Disponer de un plan de actuación. a priori.

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.

Tecnología Es conveniente disponer de herramientas que faciliten todo el proceso de Diseño del Servicio. En líneas generales se debe tener en cuenta que todas las herramientas utilizadas deben estar al servicio de los procesos y no al contrario. Es habitual caer en el error de adaptar los procesos a las herramientas en vez de buscar o adaptar las herramientas para que se ajusten a nuestros requisitos, lo que puede empañar los esfuerzos de planificación y definición previos. A la hora de escoger las herramientas adecuadas puede servir de ayuda el uso de un análisis MoSCoW:

M (must have): Funcionalidades esenciales de las que debe disponer la herramienta

S (should have): funcionalidades importantes de las que debe disponer la herramienta pero que “pueden esperar” y admiten soluciones temporales. C (could have): funcionalidades adicionales que mejorarían el rendimiento o usabilidad de la herramienta. W (will not have it now): funcionalidades accesorias que sería interesante añadir en el futuro pero que ahora son prescindibles.

Otras variables a tener en cuenta a la hora de hacer una determinada elección incluyen:
     

Reputación del proveedor de la herramienta. Qué tipo de soporte se ofrece. Si el paquete incluye formación para los usuarios. Periodicidad y coste de las actualizaciones. Plataforma tecnológica. Compatibilidad con otras herramientas ya integradas en la organización TI.

Factores de éxito y riesgos Los principales retos y riesgos que se afrontan en la implantación de la fase de Diseño del Servicio se resumen en:

Falta de madurez en la organización para afrontar los cambios organizativos requeridos. Resistencias del personal a adoptar nuevos métodos de trabajo. Falta de preparación o pobre comunicación sobre los objetivos buscados. Tecnologías de apoyo inadecuadas. Desconocimiento de los requisitos de los clientes y las condiciones del mercado. Limitaciones presupuestarias. Desviaciones respecto a la estrategia predefinida. Sistemas ineficaces de monitorización del rendimiento. Problemas de sincronización entre todos los agentes implicados. Falta de recursos o infrautilización de los mismos.

        

Relación con otros ciclos La fase de Diseño recibe sus inputs principales de la fase de Estrategia y Mejora del Servicio y a su vez sirve de principal input a las fases de Transición y Operación. Un correcto diseño debe seguir de cerca las pautas estratégicas preestablecidas y debe a su vez tomar en cuenta las restricciones provenientes de la fase de Transición y especialmente Operación. La fase de diseño representa la interfaz entre el mundo de las ideas y el mundo real. De nada sirve un servicio conceptualmente bien diseñado si se ignoran restricciones impuestas por la falta de recursos y ausencia de capacidades o si éstas no son correctamente asignadas. 1. DISEÑO Y ESTRATEGIA El principal input ofrecido a la fase de Diseño del Servicio por la fase de Estrategia es un Portfolio de Servicios orientado a cada segmento del mercado. La estrategia debe aportar al diseño del servicio:

Modelos de servicio que ofrezcan una guía sobre como aportar valor a los servicios propuestos. Información sobre restricciones derivadas de los clientes o política de precios, etcétera.

2. DISEÑO Y TRANSICIÓN La fase de transición debe disponer de toda la documentación necesaria para elaborar los planes de cambio y realizar el despliegue del servicio:
   

Planes de capacidad y disponibilidad Paquetes de servicio SLAs Planes de continuidad TI

A su vez la fase de Transición debe asesorar al Diseño sobre los riesgos y posibles impactos del cambio en la calidad del servicio. 3. DISEÑO Y OPERACIÓN La fase de operación es la más crítica y de ella depende la percepción final del cliente sobre la calidad del servicio. Por lo tanto un factor esencial en el diseño del servicio es tener en cuenta la operativa del mismo. El diseño debe:

     

Ser usable. Ser sostenible y escalable. Ofrecer la funcionalidad requerida. Ser eficiente. Cumplir los protocolos de seguridad requeridos. Permitir el acceso sólo al personal autorizado.

4. DISEÑO Y MEJORA CONTINUA La fase de mejora del servicio tiene como principal objetivo generar planes de mejora para todos los procesos, actividades y servicios… La satisfacción de los clientes depende en gran medida de los procesos y actividades desarrolladas en la fase de diseño:
  

¿Resulto la capacidad suficiente? ¿Se cumplieron los SLAs? ¿Se tuvieron en cuenta los requisitos del cliente?

Si esto no fuera así es necesario introducir planes de mejora que minimicen o eliminen los problemas encontrados y aporten una guía para las mejoras necesarias en las soluciones y arquitecturas empleadas.

Transición de los Servicios TI

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.

Se creen los entornos de pruebas y preproducción necesarios. Este proceso da soporte a prácticamente todos los aspectos de la Gestión del Servicio   . 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. Se mantienen correctamente actualizadas las bases de datos de configuración y activos del servicio. Para cumplir adecuadamente estos objetivos es necesario que durante la fase de Transición del Servicio:    Se planifique todo el proceso de cambio. 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. Se dispone de una Base de Conocimiento actualizada a disposición del personal responsable de la operación del servicio y sus usuarios. Se realicen todas las pruebas necesarias para asegurar la adecuación del nuevo servicio a los requisitos predefinidos.   Como resultado de una correcta Transición del Servicio:    Los clientes disponen de servicios mejor alineados con sus necesidades de negocio.    Procesos 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. Comunicar el cambio a todos los agentes implicados. Se cierre el proceso de cambio con una detallada revisión post-implementación. implementado y documentado. probado. Los servicios responden mejor a los cambios del mercado y a los requisitos de los clientes. La implementación de nuevos servicios es más eficiente. evaluado. Se controlan los riesgos y se dispone de planes de contingencia que eviten una degradación prolongada del servicio. Se establezcan planes de roll-out (despliegue) y roll-back (retorno a la última versión estable).

test de pruebas. probar e implementar las nuevas versiones de los servicios según las directrices marcadas en la fase de Diseño del Servicio. calidad y coste definidos previamente. Contiene toda la información del servicio registrada en el Catálogo de Servicios. Por supuesto. SLRs. mecanismos de monitorización. Esto incluye la definición de los entregables (contenido. hay que ponerse manos a la obra.   Por su parte. la Planificación también proporciona documentación de salida a otros procesos. dichos cambios deben contar con la autorización formal del Gestor del Cambio o del Comité de Cambios (CAB). etc. 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. incluyendo los requisitos que éste debe cumplir (SLAs. Gestión de Entregas y Despliegues: Responsable de desarrollar. . 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. 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. la percepción de sus usuarios. Evaluación: responsable de evaluar la calidad general de los servicios. así como los flujos de trabajo y los actores involucrados en la prestación del servicio. independiente del resto del Ciclo de Vida. los protocolos de control de la calidad. Sin embargo. plazos. etc. Validación y pruebas: responsable de garantizar que los servicios cumplen los requisitos preestablecidos antes de su paso al entorno de producción. Definición del paquete de entrega y otras especificaciones de diseño. su rentabilidad. desarrollo. 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). niveles de calidad). OLAs. especialmente a los de la fase de Transición:  Estrategia de transición y modelo de entregas. su utilización. diseño. reportes. no podemos concebir estas tareas de coordinación como una “realidad paralela”.). implementación y operación.    Planificación y Soporte a la Transición Visión general 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.

Nota: Las interacciones y funcionalidades de la Planificación y Soporte a la Transición se resumen sucintamente en el siguiente interactivo: . Información sobre riesgos y posibles impactos del cambio en la calidad del servicio.  Recopilación integral de planes de Transición del Servicio.

proporcionando un plan de transición capaz de alinear el cambio con las necesidades del cliente. coste y calidad requeridos en las especificaciones. .Introducción y objetivos 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. Para ello debe asegurarse de que todas las partes implicadas adoptan una metodología de trabajo común.

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. Estas labores de soporte consisten principalmente en informar sobre los procesos. . se minimizan los tiempos muertos y por tanto los retrasos. la adecuación a los requisitos planteados inicialmente. El servicio prestado está mejor alineado con los requisitos del cliente y los proveedores.   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. La información sobre los elementos de configuración relacionados con el cambio no está actualizada. Al existir un cronograma general del que todos los procesos tienen conocimiento. sistemas y herramientas de apoyo a la Transición del Servicio. Revisión Post-Implantación (PIR) 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. ocasionando el incumplimiento de plazos o de acuerdos con el cliente. La valoración de la RFC en cuanto a su impacto y los recursos que precisará es incompleta o errónea.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. etc.      Conceptos básicos Petición de Cambio (RFC) Una Petición de Cambio o RFC es una petición formal para efectuar modificaciones en uno o más CIs. e incluso con la propia estrategia interna de la organización. pero a menos que el cliente lo reclame no se hace una reflexión final sobre el rendimiento. Se monitoriza cada uno de los pasos de la transición. ocasionando retrasos en la planificación.

). Identificación de los cambios de que consta la transición. etc. Actores implicados (instituciones. Tipos de entregas. Metodología. Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI. Requisitos internos y externos a tener en cuenta. Comprobación de los elementos de configuración.  Planificación o o o Definición de fases y plazos. . Asignación de recursos.Proceso Las principales actividades de la Planificación y Soporte a la Transición se resumen en:  Estrategia o o o o o Políticas generales.  Preparación o o o Revisión de la documentación. proveedores. Establecimiento de SACs.

.

Frecuencia de entrega.        Las entregas pueden clasificarse.). Se implementan de manera individual para resolver errores conocidos o problemas que no pueden esperar.Estrategia de transición En primer lugar. legislación vigente. etc. acuerdos contractuales.   . Requisitos particulares del servicio.) Marco de trabajo a adoptar (políticas. proveedores. grosso modo. ya que suelen implicar un aumento de las funcionalidades.3. Entrega menor.65”) Criterios de evaluación y de aceptación de las RFCs. Organizaciones y terceros interesados (socios estratégicos. Requisitos de formación de la plantilla involucrada. protocolos de autorización. etc. Se consideran de esta clase los despliegues que incluyan la instalación de nuevo hardware y software. Suelen consistir en paquetes de pequeñas mejoras. a menudo correspondientes a soluciones provisionales a problemas concretos. “versión 1.) Roles y responsabilidades. Los puntos clave que debe contemplar dicha estrategia incluyen:    Propósito. Entrega de emergencia. Criterios para dar por concluido el soporte post-implantación (ELS). ej. etc. Requisitos externos que deban tenerse en cuenta (estándares. en los siguientes tipos:  Entrega mayor. Contexto de prestación del servicio. objetivos y metas. la organización debe definir la estrategia de transición para llevar a cabo los cambios previstos en el servicio nuevo o a modificar. Planificación de hitos y entregables.1. Convenios de nomenclatura que se han adoptado para denominar las entregas (p.

Soporte post-implementación. desarrollo y planificación de las peticiones de cambio (RFCs). personal interno.Preparación de la transición La preparación consiste en una revisión general de toda la información recabada. proveedores. Criterios de aceptación o SACs para determinar si se puede pasar a la siguiente etapa. así como de los elementos (recursos materiales. Revisión de los SACs. 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. Revisión y cierre de la transición. Desarrollo de la entrega y evaluación preliminar. etc. 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. y consiste en la descripción pormenorizada del flujo de trabajo que hará posible la puesta en marcha del cambio.      Planificación de la transición Esta es la actividad principal del proceso. Para cada una de estas etapas deben definirse los siguientes aspectos:    Descripción de tareas y actividades. Revisión y comprobación del paquete de diseño del servicio (SDP) creado en la fase de Diseño.) que intervendrán en la ejecución de los cambios. El plan ha de ser específico para cada nueva transición. Despliegue de la nueva versión. Identificación. Recursos específicos asignados a cada tarea. Validación y pruebas de la entrega. .  Revisión y aceptación de los inputs procedentes del resto de procesos del Ciclo de Vida. Comprobación de que el servicio está preparado para pasar a la fase de Operación. los requisitos específicos acordados con el cliente. etc. ya que deben tomarse en cuenta aspectos concretos del servicio como el volumen de elementos de configuración (CIs) implicados en la prestación del mismo.

y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias. Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas. puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizadas.    Gestión de Cambios Visión general Vivimos en una época de continuos cambios. Retrasos en proyectos. Una buena Planificación y Soporte a la Transición tenderá a agrupar varias entregas y despliegues en una programación global. Las principales razones para la realización de cambios en la infraestructura TI son:  Solución de errores conocidos.  Incidencias que pueden presentarse y riesgos asociados. Porcentaje de entregas (respecto al total de entregables) que se ajustaron a lo acordado con el cliente en cuanto a coste. Plazos previstos para cada fase. debe hacerse una revisión exhaustiva de los planes estratégicos una vez terminados. Ajuste al presupuesto del proyecto. no lo toques». es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: «si algo funciona. calidad y alcance. Por último. comparando el consumo de recursos humanos y financieros previstos con los que se usaron realmente. . es evidente que toda «evolución a mejor» requiere necesariamente de un cambio. Tendemos a asociar la idea de cambio con la de progreso. y aunque esto no sea necesariamente así. el número de versiones desplegadas (rollout) que han sido objeto de planificación y soporte. comparando las fechas de entrega reales con las que en un principio se habían definido en la planificación. Control del proceso El propietario de este proceso es el Jefe de Proyecto (Project Manager). Sin embargo. de tal manera que cada despliegue significativo será gestionado como un proyecto aparte. Es decir. En él recae la responsabilidad de controlar y medir los siguientes indicadores:  Número de proyectos gestionados.

si éste se lleva a cabo. . se haga de la forma más eficiente. siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI. El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que. Imperativo legal.   Desarrollo de nuevos servicios. Mejora de los servicios existentes.

.

.

Se llevan a cabo sin perjuicio de la calidad del servicio TI.Introducción y Objetivos El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar. Las actividades principales de la Gestión de Cambios se resumen sucintamente en el siguiente diagrama: . clasificados y documentados. Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación. Se ven reflejados en la CMDB. Están convenientemente registrados. Han sido cuidadosamente testeados en un entorno de prueba. La Gestión de Cambios debe trabajar para asegurar que los cambios:       Están justificados.

y por lo tanto es más sencillo valorar el retorno real a la inversión. La CMDB está correctamente actualizada.Los principales beneficios derivados de una correcta gestión del cambio son:  Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio. Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".      . Se reduce el número de back-outs necesarios. Se evalúan los verdaderos costes asociados al cambio. Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI. algo imprescindible para la correcta gestión del resto de procesos TI.

por el contrario. presidido por el Gestor de Cambios. En grandes organizaciones. No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados. en algunos casos también puede incorporar: o o o  Consultores externos. Sin embargo. mejorar un servicio o adaptarse a requisitos legales. formado principalmente por representantes de las principales áreas de la gestión de servicios TI. . Representantes de los principales proveedores de software y hardware. el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas. La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:  Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambiossobre todo en lo que respecta al cambio. por lo que resulta conveniente describir y diferenciar sus respectivas atribuciones:  Gestor de Cambios: es el responsable del proceso del cambio y. No se siguen los procedimientos establecidos y. Los Gestores del Cambio no disponen de las herramientas de software adecuadas para monitorizar y documentar el proceso de forma apropiada. debe ser el último responsable de todas las tareas asignadas a la Gestión de Cambios. Representantes de los colectivos de usuarios. como tal. provocando una falta de estabilidad que empobrece la calidad del servicio. necesidades y estructura TI de la organización. Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o. lo que les incapacita para desarrollar correctamente su actividad. independientemente de que éste se realice para solucionar un problema. Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos. no se actualiza correctamente la información sobre los CIs en la CMDB. servicios. Comité Asesor del Cambio (CAB): es un órgano interno. en particular. Los encargados de la Gestión de Cambios no conocen a fondo las actividades. se utilizará con frecuencia el concepto de Gestor de Cambios y el de Comité Asesor del Cambio (CAB).      Conceptos básicos En el resto de este capítulo. el proceso de cambio se trivializa.

un PC de referencia con todas sus componentes de hardware y software predefinidas). todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo. de tal manera que se predefinen ciertos mecanismos y actividades a realizar para cada grupo. Modelos de Cambio: es una serie de grupos de cambios que han sido previamente clasificados. es importante crear procesos de cambio cuyos protocolos estén previamente definidos y autorizados para. Estos protocolos de cambio estándar deben ser cuidadosamente elaborados. Alcance de la Gestión de Cambios En principio. por ejemplo. 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. . Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta. Al igual que a la hora de implementar la Gestión de la Configuración y Activos TI. De esta manera se alcanza un control más efectivo y una implementación mucho más ágil de las RFCs. realizar los cambios asociados a las configuraciones de referencia antes citadas. 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. analizados y autorizados.

evaluar y aceptar o rechazar las RFCs recibidas.  . para la aprobación de las RFCs y la elaboración del FSC. Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.Proceso Las principales actividades de la Gestión de Cambios se resumen en:    Registrar. Planificación e implementación del cambio Convocar reuniones del CAB. excepto en el caso de cambios menores.

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

el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso. Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados. Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. Otro: en principio cualquier empleado. Independientemente de su origen. Propósito. En la mayoría de los casos. por ejemplo. la LOPD) puede exigir cambios en la infraestructura TI. esta solución acarrea un cambio en la infraestructura TI. Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. Identificador del error conocido asociado (dado el caso). Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requieran la aprobación de la Gestión de Cambios para cada caso. Estimación de recursos necesarios para la implementación. En este caso. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad. de los siguientes datos:     Fecha de recepción. Imperativo legal: un cambio de legislación (como. el correcto registro inicial de una RFC requerirá. cuando menos. Tiempo estimado. por ejemplo. Descripción del cambio propuesto: o o o o o Motivación. Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar. cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura.      No siempre un cambio implica una RFC. Identificador único de la RFC. software y/o procedimientos. CIs involucrados. y que por regla general requieren de cambios de hardware. a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM. etc. . 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.

La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:             Estatus actualizado: "aceptado". Fecha de aceptación (denegación) del RFC. Fecha de cierre. Estatus: que inicialmente será el de "registrado". Prioridad y categoría. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicitó con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFC o para que pueda ser consecuentemente modificada. Revisión post-implementación. "implementado". Una RFC puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrado justificado su ulterior procesamiento. Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre. Aceptación y Clasificación del cambio Aceptación Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. etc. Planes de back-out. Clasificación . "rechazado". Recursos asignados. Plan de implementación. Evaluación preliminar de la Gestión del Cambio. Evaluación final. Fecha de implementación. Cronograma.

El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución. al menos. La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será el dato relevante para establecer el calendario de cambios a realizar. Un cambio aparentemente menor puede provocar una reacción en cadena con resultados catastróficos.    La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad. se debería considerar una clasificación que incluyera. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección. Aprobación y Planificación del cambio La planificación es esencial para una buena gestión del cambio. Es imprescindible. Urgente: es necesario resolver un problema que está provocando una interrupción o deterioro grave del servicio. Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento. Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. los cambios de esta categoría se pueden dividir en menores. etc. por ejemplo. pues está asociado a errores conocidos que deterioran apreciablemente la calidad del servicio.Tras su aceptación se debe asignar a la RFC una prioridad y categoría dependiendo de la urgencia y el impacto de la misma. Los cambios de esta categoría pueden clasificarse a su vez en normales y de emergencia. los siguientes niveles de prioridad:  Baja: puede ser conveniente realizar este cambio junto a otros cuando. La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de recursos necesarios. Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. . se decidan actualizar ciertos paquetes de software o se compre nuevo hardware. significativos y mayores. los plazos previstos y el nivel de autorización requerido para la implementación del cambio. Alta: un cambio que debe realizarse sin demora. A su vez. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente. Aunque el rango de posibles prioridades pueda ser tan amplio como se desee.

debe también consultarse a la direcciónpues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización. Para su aprobación.como mínimo. algo de lo que se encarga habitualmente la Gestión de Entregas y Despliegues. Implementación del cambio Aunque la Gestión de Cambios NO es la encargada de implementar el cambio. Sólo se necesita un plan de back-out. En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente. Esto tiene algunas ventajas:     Se optimizan los recursos necesarios. 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. sí lo es de supervisar y coordinar todo el proceso. En la fase de desarrollo del cambio se deberá monitorizar el proceso para asegurar que:  Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas. Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación. disponer siempre de planes de back-out que permitan la recuperación de la última configuración estable antes del cambio. Se evitan posibles incompatibilidades entre diferentes cambios. 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. . Pero esto obviamente no es suficiente.

   Se cumplen los calendarios previstos y la asignación de recursos es la adecuada. Comunicando las ventajas asociadas. Es función tanto de la Gestión de Cambios como del Centro de Servicios mantener informados a los usuarios de los futuros cambios y. Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes. Usabilidad. El entorno de pruebas es realista y simula adecuadamente el entorno de producción. Aunque la Gestión de Cambios es la encargada de emitir el dictamen final. Los planes de back-out permitirán la rápida recuperación de la última configuración estable. hacerles partícipes del mismo:    Escuchando sus sugerencias. es la Evaluación del servicio la que ha de proporcionar a ésta los informes. La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios). Si es posible. Accesibilidad. ya porque el nivel de calidad se ha visto aumentado o porque contribuye a mejorar la productividad de la organización. Los clientes y proveedores no deben percibir el cambio como algo inesperado. Evaluación del cambio Antes de proceder al cierre del cambio. 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é?    . es necesario verificar que ha sido positivo para el servicio. debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:    Funcionalidad. dentro de lo posible.

El procedimiento a seguir en estos casos debe estar debidamente previsto. Es. Para que estos informes ofrezcan una información precisa y de sencilla evaluación. esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. puede ser necesario constituir un equipo específico. Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente. sin embargo. se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:   La reunión urgente del CAB si esto fuera posible. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia. que serían fuente de nuevas incidencias y problemas. a veces resultan inevitables. Porcentaje de RFCs aceptados y aprobados. debe encontrar una respuesta inmediata. ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización. se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.Si la evaluación final determina que el proceso y los resultados han sido satisfactorios.  Como el objetivo prioritario en estos casos es restaurar el servicio. Si esto no fuera así. más reducido. es imprescindible elaborar métricas de referencia que cubran aspectos tales como:    RFCs solicitados. Cambios de emergencia Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente. configuraciones registradas incorrectas. Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios. 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). Por ejemplo. que se denomina CAB de Emergencia (ECAB). 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. Cualquier interrupción del servicio de alto impacto. . etc. se podrían provocar situaciones de cambios futuros incompatibles. En ciertos casos en los que el número de integrantes o sus circunstancias hagan de ello algo inviable.

Numero de back-outs con una detallada explicación de los mismos. Porcentaje de cambios exitosos en primera instancia. Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias. duración. Proporcionar información precisa sobre la configuración TI a la Planificación y Soporte a la Transición en su papel de coordinación del cambio para que ésta pueda establecer las fases y plazos en que se articulará la Transición.    Las interacciones y funcionalidades de la Gestión de la Configuración y Activos TI se resumen sucintamente en el siguiente interactivo: .       Tiempo medio del cambio dependiendo del impacto y la prioridad. Evaluaciones post-implementación. encontrar rápidamente la causa de los problemas. nº de cambios aprobados por reunión. realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB. Porcentajes de cambios cerrados sin incidencias ulteriores. etc. Problemas. Número de cambios de emergencia realizados. segunda instancia. etc. Incidencias asociadas a cambios realizados. Cambios y Entregas y Despliegues de manera que éstas puedan resolver más eficientemente las incidencias. Número de reuniones del CAB con información estadística asociada: número de asistentes. Visión general Las cuatro principales funciones de la Gestión de la Configuración y Activos TI pueden resumirse en:  Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB). Interactuar con la Gestiones de Incidencias.

.

.

de la Gestión de Cambios y la de Entregables y Despliegues. Es esencial conocer en detalle la infraestructura TI de nuestras organizaciones para obtener el mayor provecho de la misma. en particular. Esto no es una labor sencilla y requiere la colaboración de los Gestores de los otros procesos.Gestión de la Configuración y Activos del Servicio Introducción y Objetivos Es evidente que no se puede gestionar correctamente lo que se desconoce. . junto con sus interrelaciones. La principal tarea de la Gestión de la Configuración y Activos TIes llevar un registro actualizado de todos los elementos de configuración de la infraestructura TI.

Mayores niveles de seguridad. drivers desactualizados. Control de licencias. Interrelación entre los CIs. ubicación. etc.Problemas y Cambios.  . detectar vulnerabilidades en la infraestructura. Estructura inadecuada de la CMDB: mantener actualizada una Base de Datos de Gestión de Configuración y Activos TI excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos. Mayor rapidez en la restauración del servicio. Servicios que ofrecen los diferentes CIs.Los objetivos principales de la Gestión de la Configuración y Activos TI se resumen en:  Proporcionar información precisa y fiable al resto de la organización de todos los elementos que configuran la infraestructura TI. Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible.. etc. Los beneficios de una correcta Gestión de la Configuración y Activos TI incluyen. Una fuente habitual de problemas es la incompatibilidad entre diferentes CIs.      Las principales dificultades con las que topa la Gestión de la Configuración y Activos TI son:  Una incorrecta planificación: es esencial programar correctamente las actividades necesarias para evitar duplicaciones o incorrecciones. en particular. por ejemplo. a la Gestión de Incidencias. por ejemplo.  Servir de apoyo a los otros procesos. Una CMDB actualizada permite. Mantener actualizada la Base de Datos de Gestión de Configuración y Activos TI: o o o  Registro actualizado de todos los CIs: identificación. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización. La detección de estos errores sin una CMDB actualizada alarga considerablemente el ciclo de vida de un problema. Una Gestión de Cambios más eficiente. que redunda en una mayor calidad de servicio. entre otros:  Resolución más rápida de los problemas. El conocimiento detallado de todos los elementos de configuración permite. Reducción de costes. eliminar duplicidades innecesarias. Se pueden identificar copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus. tipo. Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas. estado..

etc. cuando sea posible. monitores. Cada información registrada sobre un CI recibe el nombre de atributo. que imposibilita el correcto mantenimiento de la CMDB. por ejemplo. etc. protocolos de red. etc. Es preferible. Falta de compromiso: los beneficios de la Gestión de la Configuración y Activos TI no son inmediatos y son casi siempre indirectos. localización.   En resumen. etc. consecuentemente. impresoras. Interrelaciones entre los diferentes elementos de configuración. constituyen diferentes elementos de configuración. Elementos de configuración: todos. La CMDB no se limita a una mera enumeración del stock de piezas. A modo de ejemplo citaremos:  Dispositivos de hardware como PCs.    Introducción y Objetivos Conceptos básicos A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración (CI) y base de datos de Gestión de la Configuración y Activos TI (CMDB) es por lo tanto conveniente que nos detengamos para dar una definición precisa de ambos. sino que nos brinda una imagen global de la infraestructura TI de la organización. así como sus componentes: tarjetas de red. como. lo que puede provocar el desinterés de la gestión de la empresa y. teclados. . relaciones "padre-hijo" o interdependencias tanto lógicas como físicas. Base de Datos de la Gestión de la Configuración y Activos TI: esta base de datos debe incluir:   Información detallada de cada elemento de configuración. Falta de organización: es importante que haya una correcta asignación de recursos y responsabilidades. Falta de Coordinación con la Gestión de Cambios y la de Entregables y Despliegues. Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la CMDB. lectores de CDs. todos los componentes que han de ser gestionados por la organización TI. Software: sistemas operativos. Documentación: manuales. tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen. que la Gestión de la Configuración y Activos TI sea llevada a cabo por personal independiente y especializado. etc. aplicaciones. acuerdos de niveles de servicio. de los agentes implicados. routers. Son ejemplos de atributos: número de versión. nombre.

Proceso Las principales actividades de la Gestión de la Configuración y Activos TI son:  Planificación: determinar los objetivos y estrategias de la Gestión de la Configuración y Activos TI. Elaboración de informes: para evaluar el rendimiento de la Gestión de la Configuración y Activos TI y aportar información de vital importancia a otras áreas de la infraestructura TI. nivel de profundidad y nomenclatura predefinidos.Sistema de Gestión de la Configuración (CMS) : es un sistema de apoyo diseñado para infraestructuras de servicios TI de gran complejidad. Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.     . Clasificación y Registro: los CIs deben ser registrados conforme al alcance. Realización de auditorías: para asegurar que la información registrada en la CMDBcoincide con la configuración real de la estructura TI de la organización.

.

al menos. Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable. Aunque ofrecer un detallado plan de implementación de la Gestión de la Configuración y Activos TI va mucho más allá de lo que aquí podemos ofrecer. etc. Por ello.Planificación de la configuración La Gestión de la Configuración y Activos TI es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias con el resto de procesos. creemos conveniente. activos. Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks. destacar algunos puntos que consideramos esenciales:  Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso. su implantación es particularmente compleja. Establecer claramente:    .

 Alcance En primer lugar habremos de determinar qué sistemas y componentes TI van a ser incluidos en la CMDB:  Es esencial incluir al menos todos los sistemas de hardware y software implicados en los >servicios críticos. Se debe determinar qué CIs deben incluirse dependiendo del estado de su ciclo de vida. al menos.. la documentación asociada a proyectos.o o o  El alcance y objetivos. El nivel de detalle. Nivel de detalle y Profundidad Una vez determinado el alcance de la CMDB. Es recomendable incorporar. cronograma. El proceso de implementación: orden de importancia.   En general. Es imprescindible. pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes. es imprescindible establecer el nivel de detalle y profundidad deseados:   Determinar los atributos que describen a un determinado CI. cualquier servicio o proceso es susceptible de ser incluido en la CMDB. . al menos. SLAs y licencias. La información sea suficiente: debe existir.. Por ejemplo. para llevar a cabo esta labor con éxito. pueden obviarse componentes que ya han sido retirados. Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs. predeterminar la estructura del CMDB de manera que:  Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar. en una dejación de responsabilidades. Coordinar el proceso estrechamente con la Gestión de Cambios. un registro de todos los sistemas críticos para la infraestructura TI. Una falta de planificación conducirá con total certeza a una Gestión de la Configuración y Activos TI defectuosa con las graves consecuencias que esto supondrá para el resto de los procesos. a la larga. Gestión de Entregas y Despliegues y los Departamentos de Compras y Suministros. Clasificación y Registro de CIs La principal tarea de la Gestión de la Configuración y Activos TI es mantener la CMDB.

estado. Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación). es de vital importancia predefinir los códigos de clasificación de los CIs para que el sistema sea funcional:  La identificación debe ser. fabricante.   Monitorización . por supuesto. Los códigos no deben ser sólo utilizados para componentes de hardware sino también para documentación y software. sistema operativo. Subcomponentes registrados independientemente. procesador. tarjetas gráficas. propietario. etc.   Nomenclatura Aunque este sea un aspecto muy técnico. coste. Por ejemplo. etc. discos duros. impresoras conectadas. Profundidad: tarjetas de red. etc. Relaciones: conexión en red. única y si es posible interpretable por los usuarios. si se decide incluir los equipos de sobremesa en la CMDB:  Atributos: Fecha de compra.

por ejemplo. . El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. debe estar correctamente registrado todo el software "en producción". puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de. organizados por diferentes filtros (tipo. Informar sobre el estado de las licencias. Asimismo. Puede representar una ayuda para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del ciclo de vida de los componentes. Monitorizar el estado de todos los componentes.Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Por ejemplo. a la Gestión de la Disponibilidadpara conocer qué CIs han sido responsables de la degradación de la calidad del servicio. etc. costes. Esta información puede ser de gran utilidad. fabricante. Las tareas de control deben centrarse en:     Asegurar que todos los componentes están registrados en la CMDB.). responsable. Actualizar las interrelaciones entre los CIs. los switches instalados a la hora de adoptar decisiones de compra de nuevo material: Control de CIs La Gestión de la Configuración y Activos TI debe estar puntualmente informada de todos los cambios y adquisiciones de componentes para mantener actualizada la CMDB. digamos.

La información recopilada puede ser utilizada para actualizar la CMDB. es necesario complementar estos datos con auditorías manuales. Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Configuración y Activos TI. Cumplimiento de los niveles de alcance y detalle predeterminados. SLAs. etc. Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración. Entre la documentación generada cabría destacar:   Alcance y nivel de detalle de la CMDB. Si el alcance de la CMDB incluye aspectos como documentación.    Una correcta Gestión de la Configuración y Activos TI necesita la colaboración de toda la estructura TI para mantener actualizada la información almacenada en la CMDB. centralizada y automática de los elementos de configuración de hardware y software. Información sobre CIs que han estado involucrados en incidentes. Estado de los CIs actualizado. personal. etc. Costes asociados al proceso. cambios realizados. Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta. tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la infraestructura TI. Éstas deben realizarse con cierta frecuencia y al menos:    Tras la implementación de una nueva CMDB. Existen herramientas que permiten una gestión remota.Auditorías El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización. Las auditorías deben dedicar especial atención a aspectos tales como:   Uso correcto de la nomenclatura en los registros de los CIs. Comunicación con la Gestión de Cambios: información sobre RFCs . Antes y después de cambios mayores en la infraestructura.   . Adecuación de la estructura de la CMDB con la de la estructura TI real.

donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción. conocido como DHS en ITIL v2).    Sistemas de clasificación y nomenclatura utilizados. En pequeñas organizaciones. Gestión de Entregas y Despliegues Visión general La Gestión de Entregas y Despliegues es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción. es a veces conveniente combinar la Gestión de la Configuración y Activos TI y la de Cambios para simplificar el proceso de control. La coordinación entre ambos procesos es un factor crítico para el éxito y esta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la total separación de estos procesos. denominada DSL en itilV2). Información estadística y composición de la estructura TI. y los Recambios Definitivos (DS. Informes sobre configuraciones no autorizadas y/o sin licencias. donde se guardan copias de todo el software en producción. La Gestión de Entregas y Despliegues debe colaborar estrechamente con la Gestión de Cambios y la de Configuración y Activos TI La Gestión de Entregas y Despliegues también debe mantener actualizada la Biblioteca de Medios Definitivos (DML. Calidad del proceso de registro y clasificación. Las interacciones y funcionalidades de la Gestión de Entregas y Despliegues se resumen sucintamente en el siguiente interactivo: .

.

.

Archivar copias idénticas del software en producción. Mantener actualizado el DS. laGestión de Cambios de aprobarlo y supervisarlo. en colaboración con la Gestión de Cambios y la de Configuración y Activos TI. y la Validación y Pruebas de testear cada nueva versión. así como de toda su documentación asociada. Garantizar que el proceso de cambio cumpla las especificaciones de la RFCcorrespondiente.Introducción y Objetivos Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea delicada la implementación de cualquier cambio. Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI. Las nuevas versiones cumplen los objetivos propuestos. es la Gestión de Entregas y Despliegues la que realmente pone en marcha el proceso. Asegurar. en la DML. que todos los cambios se ven correctamente reflejados en la CMDB. Entre los principales objetivos de la Gestión de Entregas y Despliegues se incluyen:  Establecer una política de implementación de nuevas versiones de hardware y software. Si la Planificación y Soporte de la Transición es la encargada de diseñar el Plan del Cambio. Implementar las nuevas versiones de software y hardware en el entorno de producción después de que la Validación y Pruebas las haya verificado en un entorno realista.      Los beneficios de una correcta Gestión de Entregas y Despliegues se resumen en:   El proceso de cambio se realiza sin deterioro de la calidad de servicio. .

según su impacto en la infraestructura TI. La implementación sincronizada de versiones en entornos altamente distribuidos. No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las nuevas versiones de software y hardware. Protección contra virus y problemas asociados a versiones de software incontroladas.  Conceptos básicos Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno de producción. Control centralizado del software y hardware desplegado. Es habitual que existan reticencias a adoptar sistemas estandarizados en toda la organización.    Las principales dificultades con las que topa la Gestión de Entregas y Despliegues son:  No existe una clara asignación de responsabilidades y/o la organización TI no acepta la figura dominante de la Gestión de Entregas y Despliegues en todo el proceso de implementación del cambio. sobre todo cuando ésta no ha sido la política tradicional de la misma. Las versiones pueden clasificarse. Un adecuado plan de comunicación que informe a todos los responsables y usuarios de la organización TI de las ventajas de una correcta gestión de todo el proceso de cambio. Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio.      La solución a estos problemas pasa por:  Un firme compromiso de la organización con la Gestión de Entregas y Despliegues y sus responsables. El correcto mantenimiento de la DML impide que se pierdan (valiosas) copias de los archivos fuente. en: . Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última versión estable. Se realizan cambios sin tener en cuenta a la Gestión de Entregas y Despliegues argumentado que éstos sólo son responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente. Se reduce el número de copias de software ilegales.

0. Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.3. Versiones de emergencia: 1. 1.1. El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión: El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. pruebas. en la ayuda la versión de su navegador). producción y archivado.1.1. En su ciclo de vida.2. etc.1. es conveniente definir una referencia o código que los identifique unívocamente. Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad. Versiones menores: 1. 1. características técnicas.   Como pueden llegar a existir múltiples versiones. 1. El sistema universalmente aceptado es:    Versiones mayores: 1.2. por ejemplo. Entre las opciones más habituales cabe contar: . una versión puede encontrase en diversos estados: desarrollo. Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido. etc. etc. 2. Aunque en algunos casos esta clasificación se refina aún más (vea.0. etc.

es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes. Versión delta: sólo se testean e instalan los elementos modificados. ya hayan sido modificados o no. . En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. por ejemplo. Versión completa: Se distribuyen todos los elementos afectados. Aunque esta opción es obviamente más trabajosa. Recambios Definitivos (DS) El almacén de Recambios Definitivos (DS) contiene piezas de repuesto para los CIs en el entorno de producción. Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIscorrespondientes se hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB). Pensemos. La DML debe ser almacenada en un entorno seguro y es conveniente que se realicen backupperiódicos.   Biblioteca de Medios Definitivos (DML) La Biblioteca de Medios Definitivos (DML) debe contener una copia de todo el software instalado en el entorno TI. La DML debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en caso de que se deban implementar los planes de backout. Implementar las nuevas versiones en el entorno de producción. Esto incluye no sólo sistemas operativos y aplicaciones. Desarrollar o adquirir de terceros las nuevas versiones. sino también controladores de dispositivos y documentación asociada. Proceso Las principales actividades de la Gestión de Entregas y Despliegues se resumen en:    Establecer una política de planificación para la implementación de nuevas versiones. Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones: de esta forma se ofrece una mayor estabilidad al entorno TI. en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevas versiones de los programas ofimáticos. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.

  El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Entregas y Despliegues: . el DS y la CMDB. Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario. Actualizar la DML. Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.

pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso.Planificación de entregas Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión. Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción. A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes factores:   Cómo puede afectar la nueva versión a otras áreas del entramado TI. Esto es especialmente importante para los casos de versiones menores y de emergencia.  .

sincronizado en todas los emplazamientos.        Una herramienta clave para formular la planificación de entregas es el Modelo en V.  Qué planes de back-out son necesarios.. Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con garantías de éxito. Quiénes serán los responsables directos en las diferentes etapas del proceso Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén puntualmente informados y puedan percibir la nueva versión como una mejora. Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.. delta. Qué tipo de despliegue es el más adecuado: completo. gradual. Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI. . Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva versión. Cuál es la vida media útil esperada de la nueva versión. que sirve para identificar los diferentes niveles de test necesarios para aceptar una versión durante el proceso de Validación y Pruebas.

Fragmentado: ya sea bien espacial o temporalmente. En el brazo derecho se van indicando.  . Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos. si esto fuera necesario o simplemente recomendable. Por ejemplo. A veces el desarrollo se realizará "en casa" y muchas otras requerirá la participación de proveedores externos. en el brazo izquierdo de la V. Actualizaciones necesarias de las Bases de Datos asociadas. Creación de logs asociados al proceso de instalación. las especificaciones del servicio que es necesario cumplir para aceptar una versión. El rollout puede ser de varios tipos:  Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos. Éstos tendrán que tomar en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes Implementación de la entrega Llegó el momento de la verdad: la distribución de la nueva versión. En este segundo caso. Desarrollo del despliegue La Gestión de Entregas y Despliegues es la encargada del diseño y construcción de las nuevas versiones siguiendo las pautas marcadas en las RFCs correspondientes.La metodología del Modelo en V consiste en definir.  Parte integrante del desarrollo lo componen los planes de back-out asociados. la Gestión de Entregas y Despliegues será la responsable de todo el proceso de configuración necesario. las pruebas mediante las cuales se van a comprobar cada una de las especificaciones de la izquierda. todos los scripts de instalación requeridos para el despliegue de la versión. también conocida comorollout. introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida. la tarea de la Gestión de Entregas y Despliegues será la de asegurar que el paquete o paquetes de software o hardware ofrecidos cumple o cumplen las especificaciones detalladas en la RFC. Asimismo. de forma paralela. El desarrollo debe incluir. Estos scripts deberán tener en cuenta aspectos tales como:    Back-up automático de datos.

en el proceso.  Tras la distribución. los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cómo éste puede afectar a sus actividades diarias. la Gestión de Entregas y Despliegues debe ser puntualmente informada por el Centro de Servicios de los comentarios. que cuando se aborden cuestiones de carácter técnico se obvie el factor humano. incidentes. etc. y a su vez un grave error.El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. no se encuentran en disposición de aprovechar sus ventajas. Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas. debido a una incompleta (in)formación. La (in)formación debe estructurarse en distintos niveles:  Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar. es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena. Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación necesaria para poder sacar el adecuado provecho de las mismas. . Comunicación y Formación Es frecuente. la Gestión de Entregas y Despliegues debe asegurarse de que:     Se incluya una copia de la versión en la DML. El DS incorpore repuestos funcionales de los nuevos CIs. Qué métricas determinan la puesta en marcha de los planes de back-out y si éstos deben ser completos o parciales. Salvo contadas excepciones. La CMDB esté correctamente actualizada. En particular. a su discreción. Es imprescindible determinar claramente:   Los CIs que deben borrarse e instalarse y en qué orden debe realizarse este proceso. que la nueva versión haya podido suscitar. Es inútil disponer de un sofisticado servicio TI si los usuarios. quejas. Tras la implementación. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.

por supuesto. Cuando se considere oportuno. Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y puedan solicitar ayuda o soporte técnico en el uso de la nueva versión. se impartirán cursos presenciales o remotos mediante módulos de e-learning sobre el funcionamiento de la nueva versión.  Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Entregas y Despliegues. Adecuado registro de las nuevas versiones en la CMDB. Incidencias asociadas a nuevas versiones. Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:          Número de lanzamientos de nuevas versiones. Cumplimientos de los plazos previstos para cada despliegue. 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.). Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios. Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión. Existencia de versiones ilegales de software. etc. soporte. que incluye información detallada sobre modelo de servicio (servicios suministrados. no van a provocar ningún error inesperado cuando estén operativas. activos que lo conforman. Número de back-outs y razones de los mismos. . Corrección y alcance de la CMDB y la DS.  Validación y Pruebas Visión general 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. Asignación de recursos en cada caso.

  Una vez terminadas las sesiones de testeo. desde un punto de vista más técnico. 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 Gestión de Niveles de Servicio facilita los SLRs acordados con el cliente y las Hojas de Especificación. 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 RFCparticular (valoración de riesgos. La Gestión de Entregables y Despliegues proporciona la versión a testear propiamente dicha. que recogen. recursos asociados). .

.

Introducción y Objetivos 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. Conocer a fondo los requisitos de calidad del servicio acordados con el cliente para poder garantizar que las nuevas versiones los cumplen. y verificar que se cumplen los niveles de utilidad y garantía establecidos. también se reduce significativamente el volumen de llamadas que llegan al Centro de Servicios. la Validación y Pruebas del Servicio se encarga de:  Diseñar y mantener un entorno de pruebas. Conocer a fondo las funcionalidades del servicio y mantener listados actualizados de todos los casos de uso para poder hacer chequeos completos. El objetivo último del proceso consiste en detectar y prevenir aquellos errores causados por incompatibilidades imprevistas. Al haber menos incidentes. Planificar y llevar a cabo un calendario de pruebas que cubra todas las funcionalidades registradas para el servicio. una réplica exacta del escenario en el que el servicio desarrolla su actividad.  .    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. Para cumplir este cometido. es decir.

puesto que es mucho menos “caro” resolver errores en un entorno de pruebas que en uno real. por lo que la Validación y Pruebas del Servicio no las incluye en su plan de pruebas. ofertas y contratos. o ésta se aparta demasiado de los SLRs acordados con el cliente. La Gestión de Entregas y Despliegues no actualiza con suficiente frecuencia su entorno de desarrollo. No se define suficiente con claridad la metodología a emplear durante las pruebas. por lo que las pruebas resultan ser ineficaces. de haberse producido. la planificación y los protocolos de testeo.     . 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. sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones. Aceptación de los datos y elaboración de informes de resultados que registren los errores. La Gestión de Entregas y Despliegues no conoce o a fondo los requisitos definidos en los SLRs y SLAs. Los problemas y errores conocidos pueden ser detectados. Pruebas de las nuevas versiones en un entorno idéntico al entorno real de desarrollo del servicio nuevo o mejorado.   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. Se ahorran costes. por lo que son necesarias evaluaciones preliminares hasta alcanzar el nivel de rendimiento mínimo. ya sea por no estar suficientemente actualizado o por falta de detalle. Definición del modelo de pruebas. Limpieza del entorno de pruebas y cierre del proceso. aislados y diagnosticados en el entorno de pruebas mucho mejor que en el entorno real.    Proceso Las principales actividades de la Validación y Pruebas del Servicio se resumen en:  Validación de paquetes de servicios. El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar. Construcción del escenario de pruebas y acceso a los elementos a probar.

Validación. planificación y verificación de tests Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producción una nueva versión con razonables garantías de éxito. .

que recogen el método a emplear: cómo se va a testear cada elemento. y que el proveedor o proveedores correspondientes están preparados para poner en funcionamiento el nuevo servicio a partir de su despliegue. Cuanto mayor sea el alcance del plan de pruebas. que incluye:  El propio objeto de las pruebas. Una vez planificado el proceso. Llegado este punto. ordenada y sin pérdidas de valiosa información. por ejemplo. Construcción de tests En esta etapa. El objetivo último es asegurar que el servicio TI se corresponde con la utilidad y garantía esperadas. Puede haber uno o varios. Al final de todo el proceso. proporcionado por la Gestión de Entregas y Despliegues. . la Validación y Pruebas del Servicio se ocupa de recopilar todos los componentes de la versión y de poner a punto el entorno de pruebas en las condiciones necesarias para su correcto desarrollo. Es importante que las pruebas incluyan los planes de back-out para asegurarnos de que se podrá volver a la última versión estable de una forma rápida. dependiendo de las circunstancias y magnitud de los cambios. será también la responsable de elaborar el registro final de todas las tareas realizadas y de verificar que la planificación se cumplió punto por punto. qué datos se van a tomar como indicadores y los baremos de calidad que determinarán si la prueba ha sido un éxito o un fracaso. que recoge la planificación y la estimación de plazos para cada una de las pruebas: técnicas. el siguiente paso consiste en la validación de los paquetes de servicios. Estas consideraciones se registran y estructuran en el modelo de pruebas. Guiones de pruebas. roles. etc. etc). mayores serán las garantías de fiabilidad de la nueva versión. funcionales. los picos de demanda) y a todos los casos de uso (interfaces.   La Dirección y Validación de Pruebas es la unidad encargada de supervisar el correcto desempeño de las tareas descritas en el Plan de Pruebas. perfil tecnológico de los usuarios. Plan de Pruebas.Las pruebas no deben limitarse a una validación de carácter técnico (ausencia de errores) sino que también deben realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple los requisitos establecidos y es razonablemente usable (siempre existe una inevitable resistencia al cambio en los usuarios que debe ser tenida en consideración). las ofertas y los contratos (UCs). también se repasan los diseños y planes de pruebas para verificar que todo está completo y que se ajusta a los perfiles de riesgo previstos (teniendo en cuenta.

 Aceptación y reporte . El desarrollo de las pruebas puede ser automático o manual. La claridad de la documentación que se pondrá a disposición del usuario final. Las principales actividades realizadas en el subproceso de pruebas deben incluir:     Pruebas del correcto funcionamiento de la versión. Pruebas de los planes de back-out. por ejemplo. De ahí la importancia de que el escenario de pruebas tenga:    Las mismas versiones de software que la plataforma en producción. todos estos componentes son pre-testeados para garantizar que sólo participarán en ellas aquellos que cumplen con los más estrictos criterios de calidad. Los mismos dispositivos de hardware. con resultados que no aparecerían de utilizar bases de datos de ejemplo con sólo unas pocas entradas. Los comentarios y sugerencias sobre usabilidad y funcionalidad o las dudas que hayan surgido durante el uso de la nueva versión. el rendimiento de las consultas. los resultados de las pruebas se verán distorsionados y por tanto no servirán. las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales. la migración y elback-out son examinados uno por uno. herramientas y mecanismos que participan en el despliegue.La fiabilidad de las pruebas está condicionada al entorno en el que éstas tienen lugar. Clones de las bases de datos. Durante este proceso de prueba se documentará y analizará:   La experiencia subjetiva del usuario. Pruebas por grupo objetivo (roles). Antes de dar comienzo a las pruebas. Si no es idéntico al escenario real en que se desplegará el servicio nuevo o modificado. para medir la utilidad del servicio. Pruebas de los procedimientos automáticos o manuales de instalación. Siempre que sea posible. Sólo si se utilizan las bases de datos reales pueden obtenerse informes precisos sobre. Pruebas En esta etapa del proceso se llevan a cabo las pruebas propiamente dichas: todos los componentes.

En esta última etapa. Número de errores conocidos que se registran durante la etapa de pruebas. Número de incidentes atribuibles a las nuevas versiones. En cambio. Información y conocimiento para el SKMS. Tiempo de demora en la subsanación de errores.) hasta la situación inicial. etc. si el análisis es favorable y existen garantías de que la versión cumple las condiciones necesarias para obtener el consentimiento del cliente.La aceptación consiste en la comparación de los datos reales obtenidos en las pruebas con los SACs. Si la versión no cumple los requisitos mínimos preestablecidos. revirtiendo los cambios incorporados durante los test (instalación de aplicaciones. se procede a la limpieza del entorno de pruebas. se procede a la elaboración de un informe completo de resultados de las pruebas. . Este documento incluye:     Reporte de actividades realizadas. Control del proceso La eficacia de la Validación y Pruebas del Servicio puede ser evaluada teniendo en cuenta los siguientes indicadores:      Porcentaje de componentes que no superan los test de aceptación. Listas de bugs o errores detectados. Así. importación de datos. que se envían a la fase de CSI. Ideas de mejora. si se diera el caso. es devuelta como “no aceptada” a la Gestión de Cambios para su reevaluación. Limpieza y cierre Por último. el equipo encargado de las pruebas revisa el planteamiento de las mismas y verifica si la planificación se cumplió conforme a los recursos. Este documento es el que más adelante servirá a la Evaluación para elaborar informes de rendimiento del servicio que a su vez serán tenidos en cuenta por la Gestión de Cambios a la hora de validar o no el cambio. Porcentaje de test de aceptación del servicio que no obtienen la aprobación del cliente. SACs y plazos acordados. se detectan aspectos mejorables para perfeccionar el proceso.

Los informes preliminares de rendimiento del servicio son útiles a la hora de planificar la transición.   La Evaluación. La Mejora Continua del Servicio detecte necesidades o carencias relacionadas con el rendimiento y proponga nuevas RFC. a pesar de ser ésta su función principal.Evaluación Es evidente que. donde figuran las características del servicio nuevo o modificado. informe de impacto y riesgos previstos. el informe de resultados de las labores de testeo. Sin embargo. sino como un proceso iterativo. ya que de ellos recibe los inputs necesarios para elaborar sus informes:  El Diseño del Servicio aportará el SDP. con otros procesos del Ciclo de Vida. la Evaluación no debe concebirse como una actividad puntual. toma los datos proporcionados por estos procesos y genera una serie de informes de evaluación que servirán para que:  La Gestión de Cambios cuente con la información de contexto necesaria para aprobar o no cada solicitud de cambio. La Evaluación está estrechamente relacionada. La Gestión de Cambios proporcionará la documentación necesaria para llevar la evaluación a cabo: registro de la RFC.  . por su parte. a la hora de tomar cualquier decisión relacionada con la incorporación de un nuevo servicio o de un cambio en uno ya existente. etc… La Validación y Pruebas del Servicio suministra. así como la relación coste-beneficio que aportará una vez esté en marcha. por su parte. pero han de ser contrastados con informes posteriores una vez que éstos han sido implantados. es preciso valorar los pros y contras. es la Evaluación la encargada de recoger y analizar toda la información disponible sobre el cambio o nuevo servicio y elaborar los informes necesarios para tomar estas decisiones. por lo tanto. Aunque la decisión última recae en otros procesos.

.

.

eficacia y utilidad. .Evaluación Introducción y Objetivos La Evaluación es un proceso transversal que se ocupa de valorar el rendimiento de un elemento específico o conjunto de elementos del servicio y de generar un informe completo al respecto. Se realiza antes de implementar el cambio y consiste en predecir los efectos que éste tendrá una vez esté operativo. Los resultados de la Validación y Pruebas del Servicio son incompletos o poco detallados. tanto previstos como imprevistos. Se realiza una vez el cambio ha sido ya implementado. que consiste en analizar los efectos. y consiste en analizar los efectos que ha provocado su puesta en marcha. El modelo de rendimiento no refleja el servicio en toda su complejidad. <liEvaluación del rendimiento previsto. por lo que algunos efectos imprevistos del cambio no llegan a advertirse. ya sea porque incrementa su calidad o porque proporciona una mejora en la productividad.  Evaluación del rendimiento real. que corresponde a la Validación y Pruebas del Servicio. Algunas dificultades que pueden obstaculizar las actividades de la Evaluación son:  Las evaluaciones no se gestionan con suficiente agilidad y se generan cuellos de botella que retrasan la implementación del cambio. El objetivo principal de la Evaluación consiste en proporcionar la información suficiente para determinar con seguridad si un aspecto del servicio es útil para el negocio. lo que puede resultar en una evaluación sesgada.    Proceso Las actividades de la Evaluación se resumen en:  Planificación de la evaluación. de la puesta en marcha de un cambio o nuevo servicio. No se analiza el rendimiento del servicio con suficiente celo. ocasionando un constante desequilibrio entre las estimaciones iniciales de rendimiento previsto y el rendimiento real del servicio una vez implantados los cambios. No debe confundirse esta labor con la de verificar si el servicio cumple los requisitos mínimos de calidad.

Proceso Planificación de la evaluación .

sobrecarga de la red… Evaluación de rendimiento previsto Consiste en una evaluación de los riesgos derivados de la ejecución de un cambio. Uso (U). . Personas (P). Recursos (R). SLAs). suelen ser perjudiciales para el servicio y son difíciles de medir: impacto en los clientes/usuarios. capacidad. La capacidad de un proveedor o de una unidad de servicio para desempeñar su trabajo. Con el fin de predecir el impacto de un cambio. etc. incremento del rendimiento. La capacidad que tiene la organización TI para absorber cambios. fondos económicos. optimización de recursos. Grado en que el servicio cumple con las expectativas de uso (p. seguridad. etc. Disponibilidad de la necesaria infraestructura. ya que a menudo no se manifiestan hasta que se despliega el cambio en producción. Configuración de la Organización (O). etc. Modelado y medidas (M). para llevar a cabo la transición. Efectos imprevistos.        La mejor manera de garantizar que el impacto del cambio se ha comprendido en profundidad es examinarlo desde dos perspectivas:  Efectos deliberados.ej. la Evaluación considerará los siguientes factores:  Capacidad del proveedor de Servicios (S). personal cualificado. Algunos ejemplos: reducción del coste del servicio. Tolerancia (T). La capacidad que tiene el servicio para absorber cambios. disponibilidad. como se ha dicho. analizar el impacto de un cambio en el servicio con el fin de recabar toda la información relevante para tomar una decisión respecto a la implantación del mismo. son beneficiosos para el servicio y deben estar alineados con los SACs definidos por la Planificación y Soporte a la Transición.El propósito de la Evaluación es. Las personas dentro del sistema y el efecto del cambio en ellas. que toma como referencia:  Requisitos del cliente (SLRs. En general. Grado en que el servicio se ajusta al propósito inicial.  Por lo general.) Propósito (P). Grado en que las predicciones formuladas a partir del modelo de rendimiento coinciden con el comportamiento real del servicio modificado. Son muy difíciles de predecir e incluso de detectar.

 Rendimiento esperado o rendimiento que está previsto que el servicio obtenga una vez implantado el cambio. real). Si todo marcha según lo esperado. el rendimiento esperado y el modelo de rendimiento. Evaluación de rendimiento real Una vez ya se ha implantado el cambio.  Si la Evaluación concluye que el rendimiento real no coincide con lo previsto. se generará una nueva RFCs conforme a los planes de retirada. en cambio. desde la fase de Operación se envían a la Evaluación los informes del rendimiento real que está registrando el servicio. Si. que no es sino una representación de la utilidad y garantía del servicio. se están incumpliendo los criterios de aceptación o el rendimiento no alcanza las expectativas iniciales. en cambio. . se analizarán los riesgos comparando estos datos con los requisitos del cliente. Modelo de rendimiento. Reporte de desviaciones (rendimiento esperado vs. se genera un informe de evaluación final y se da por concluido el proceso de Evaluación. Este desenlace también cierra el proceso de Evaluación. Recomendaciones. acarrea riesgos inaceptables o bien se desvía de los criterios de aceptación. Control del proceso El proceso de Evaluación puede medirse a través de los siguientes indicadores:  Número de evaluaciones solicitadas para nuevos servicios o cambios en un periodo determinado. se procede al despliegue del cambio y a la evaluación del rendimiento real. De nuevo. se determina que el cambio está comportando riesgos inaceptables. la Evaluación concluye que el rendimiento previsto coincide con lo esperado. que será enviado a la Gestión de Cambios y que contemplará:     Perfil de riesgos. ya que si la Gestión de Cambios desea corregir la situación. Si. entonces se interrumpen las actividades de evaluación y se genera un Informe Intermedio de Valoración. Control de calidad. es responsabilidad de la Evaluación alertar a la Gestión de Cambios y hacerle llegar unInforme Intermedio de Valoración en los términos descritos en el apartado anterior.

Desviación de las evaluaciones de rendimiento previsto respecto de las evaluaciones reales. Asimismo.) constituyen información muy útil para ahorrar tiempo y esfuerzo. establecer relaciones y determinar con mayor facilidad las causas de los mismos. información de contacto y servicios ofrecidos por los proveedores. que puede proporcionar al Centro de Servicios la posibilidad de anticiparse al cliente. La información relativa a las posibles consecuencias del error. incluso una de dimensiones modestas. La Gestión del Conocimiento se encarga de establecer unos criterios de registro y de acometer labores periódicas de clasificación. La cantidad de información que una organización puede generar. Tiempo medio de elaboración de una evaluación desde que ésta es solicitada hasta que se entrega. etc.   Número de evaluaciones entregadas en un periodo determinado. es suficientemente voluminosa como para que resulte imprescindible una gestión centralizada de la misma. Número de evaluaciones que permanecen en la cola de tareas. Este fenómeno se reproduce. La experiencia y conocimientos del personal. puede confeccionarse un registro que recibe el nombre de KEDB y que ayuda a minimizar el tiempo de catalogación y solución de los mismos en el futuro. De esta manera. principalmente desde la Gestión de Incidencias y Errores. la Gestión de Problemas puede hacer un seguimiento del histórico de errores. tanto si han sido preaprobadas como si se han desechado.  Gestión del Conocimiento Visión general El aspecto más beneficioso de trabajar en equipo reside en la oportunidad de compartir el saber. rendimiento de la organización. Una buena Gestión del Conocimiento ha de colaborar estrechamente con los procesos de las otras fases del Ciclo de Vida para documentar y analizar:  Los errores detectados y las soluciones aportadas en cada caso.   . cuando son todos los miembros de una organización los que contribuyen a crear un acervo común de conocimientos. La Gestión de Cambios aportará documentación sobre las propuestas de cambio llegadas desde la fase de Mejora Continua del Servicio. a mayor escala. así como detalles sobre la rutina diaria (comportamiento de los usuarios. las ideas y la experiencia acumulada de todos los integrantes del mismo. evaluación y mejora de los datos disponibles.

por último.La Gestión del Conocimiento es la encargada. . de centralizar toda esta información en un repositorio denominado Sistema de Gestión del Conocimiento del Servicio (SKMS).

analizar. reduciendo la necesidad de redescubrir el conocimiento. almacenar y compartir el conocimiento e información de la organización. El objetivo principal del proceso consiste en mejorar la eficiencia.Introducción y Objetivos La Gestión del Conocimiento es la encargada de reunir. .

tanto para registrar como para consultar los datos disponibles. de contacto con un cliente. organización y aprovechamiento de los datos. así como una constante monitorización del registro. Sin embargo. una organización puede tener las herramientas adecuadas para registrar y organizar los datos.La Gestión del Conocimiento contribuye a mejorar la calidad de las decisiones que se adoptan en una organización. coordine y estructure el proceso para:  Garantizar que el personal hace uso de las herramientas. Los datos se registran pero no se revisan.    Introducción y Objetivos Conceptos básicos . al garantizar que aquellos a quien corresponde tomarlas disponen de información segura y fiable. por lo que la información disponible está desactualizada o incompleta. pero los buenos propósitos pueden no llegar a materializarse nunca si no existe una unidad de Gestión del Conocimiento que impulse. etc. pueden recuperarse con facilidad los detalles de la solución aplicada entonces. velando por que estén permanentemente actualizados. Si surge un problema que ya se presentó en el pasado. un entendimiento profundo de los procesos que se desarrollan en la organización. Los miembros del personal no confían en los datos registrados. Los beneficios obtenidos de una correcta Gestión del Conocimiento son numerosos:  No se duplica el trabajo innecesariamente. de modo que recurren a otras vías a la hora de buscar información. son incompletos o no están adaptados a la audiencia a la que van destinados. Prevención de situaciones de desinformación en caso de faltar los “propietarios” de los datos de acceso a una aplicación. ahorrando tiempo y esfuerzo. Analizar las necesidades de información de ciertos departamentos y coordinar la correcta transferencia de conocimiento desde aquellos que poseen los datos.   Estas funciones requieren. Mejor aprovechamiento de los recursos existentes. de quienes desempeñan las labores de Gestión del Conocimiento.   Las principales dificultades que se presentan a la hora de abordar la Gestión del Conocimiento consisten en:  Los miembros del personal están saturados de trabajo y no disponen de tiempo para documentar los datos o dan prioridad a otras tareas más urgentes. Los datos están mal estructurados. Evaluar los datos recogidos. por lo que en la práctica resultan inservibles.

sincronización. explorar. no puede ser capturado puesto que se refiere a la capacidad individual para hacer juicios válidos y tomar decisiones correctas. Las funciones asociadas a esta capa incluyen el análisis de los datos. Es la interfaz que permite buscar. procesamiento y gestión para interactuar con la Base de Datos de Gestión del Conocimiento del Servicio de la organización IT. vista de Activos y Configuración. En esta capa es donde se estructura la información    Estructura DIKW El concepto DIKW (Datos-Información-Conocimiento-Saber) recoge y relaciona las distintas unidades de conocimiento en un proceso lineal que va de menor a mayor. y por lo tanto ser consultados y transferidos. radica en tomar las decisiones adecuadas aplicando el conocimiento y el sentido común. propiamente dicha. El Saber. gestión de metadatos. etc.Sistema de Gestión del Conocimiento del Servicio (SKMS) Un Sistema de Gestión del Conocimiento del Servicio o SKMS es una herramienta que proporciona funcionalidades de presentación. y donde se desarrollan todas las actividades de integración de datos: minería de datos. que es lo relevante en la toma de decisiones. recuperar y actualizar los datos a través de una serie de interfaces específicas para cada proceso interesado: vista de Gestión de la Calidad. el modelado de los datos y la monitorización de los cambios a través de paneles de control. El Saber. ideas y juicios de cada individuo. interpretándolos. Al aportar contexto a los datos (contrastando con otras fuentes de datos. Proceso . la planificación. Capa de procesamiento de conocimiento. Capa de Integración de la Información. almacenar. Es donde está la Base de Datos de Gestión. Un SKMS está estructurado de forma estratificada.   Los Datos. Herramientas y fuentes de datos e información. sin embargo. El Conocimiento se alcanza al completar la información con las experiencias. Esta estructura es un reflejo del modo en que la Gestión del Conocimiento procesa y transforma los Datos en Saber. la elaboración de informes. la Información y el Conocimiento pueden ser registrados en bases de datos. por último. en varias capas que se articulan en torno a la base de datos donde se almacena la información propiamente dicha:  Capa de presentación.   Los Datos consisten en mediciones cuantificables y objetivas. etc.) obtenemos Información. etc.

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

Definir una estrategia de Gestión del Conocimiento y difundirla a toda la organización TI. Ayudar a la transferencia de conocimiento entre personas, equipos y departamentos. Gestionar la información y los datos para garantizar su calidad y utilidad. Uso del SKMS.

  

El siguiente diagrama muestra los procesos implicados en la correcta Gestión del Conocimiento:

Estrategia de conocimiento A la hora de planificar el proceso de Gestión del Conocimiento es preciso definir, desarrollar y difundir:

Una serie de políticas generales referentes a los datos: qué registrar, cuándo hacerlo, cómo estructurar los datos, etc. Las condiciones de administración: qué clase de información es susceptible de ser corregida o eliminada. Los roles: quién registra la información, quién la revisa, quién la valida, quienes la pueden consultar libremente. Procedimientos de registro, revisión y validación de la información.

Transferencia de conocimiento Es tarea de la Gestión del Conocimiento, en primera instancia, transmitir a todos los miembros de la organización TI la importancia de registrar la información relacionada con su trabajo en las herramientas dispuestas para ello. Por otro lado, es también su labor instalar una cultura de aprendizaje constante entre los miembros del personal. No sólo se trata de hacer que los empleados registren los datos, sino

también motivarlos a que acudan a las fuentes de conocimiento para completar aquello que no saben. Asimismo, la Gestión del Conocimiento se ocupa de:

Detectar las necesidades de conocimiento existentes en la organización, tanto a nivel particular como grupal. Conocer en todo momento quién o quiénes poseen esa información. Establecer el canal adecuado para que los “propietarios” del conocimiento puedan transferirlo a quienes lo necesitan: seminarios, anuncios, boletín, periódico.

 

Gestión del conocimiento La Gestión del Conocimiento debe garantizar que la información disponible sea completa y esté puntualmente actualizada, ya que de otro modo puede resultar inútil. Las labores de gestión comportan una monitorización exhaustiva de los cambios registrados en el SKMS, y una serie de tareas asociadas a esta revisión:
  

Iniciar y gestionar procesos de borrado de información. Determinar la periodicidad de las revisiones. Detectar y subsanar incoherencias en los datos registrados.

Uso del SKMS En el SKMS han de estar disponibles todos los documentos generados por el resto de procesos:
 

Gobierno de TI: Cartera de Servicios, informes, CSI, Riesgos y otras cuestiones. Calidad: Políticas, procesos, procedimientos, formularios, plantillas, listas de comprobación. Servicios: Catálogo de Servicios, SPs, informes del servicio. Activos y Configuración: Activo financiero, información del CMS, informes de estado, datos de la CMDB, fuentes definitivas. Centro de Servicios / Soporte: Catálogo de Servicios, clientes, usuarios, grupos de interés, CIs, incidencias, problemas, cambios, entregas, rendimiento de las configuraciones.

 

Control del proceso

Las métricas de referencia para evaluar si la Gestión del Conocimiento está desarrollando correctamente su labor son:
 

Número de solicitudes de entradas nuevas recibidas en un periodo específico. Número de solicitudes de modificaciones/actualizaciones enviadas en un periodo específico. Número de entradas nuevas publicadas en la base de datos del SKMS en un periodo específico. Número de entradas modificadas en la base de conocimiento en un periodo específico. Número de incidentes que recurrieron a entradas existentes en la base de conocimiento en un periodo específico. Tiempo ahorrado gracias al uso de la base de conocimiento. Se calcula comparando el tiempo medio de resolución de incidentes que se cerraron empleando la base de conocimiento con los que no la usaron. Número de peticiones de autoayuda que declararon que la base de conocimiento ayudó en la resolución de un asunto en un periodo determinado.

 

PUESTA EN MARCHA La puesta en marcha de la Transición del servicio puede ser un proceso complejo. En organizaciones no lo suficientemente maduras se puede percibir como una simple burocratización del proceso asociado al cambio. Es evidente que es imprescindible dimensionar correctamente toda la estructura organizativa asociada y en el caso de pequeñas organizaciones TI, aunque no sea la solución optima, asumir que diferentes roles puedan recaer en la misma persona o equipo. Para que la implementación sea un éxito:

Se deben analizar los problemas surgidos en el pasado debidos a una deficiente implementación de los cambios. Se debe comunicar adecuadamente a clientes y miembros de la organización TI las ventajas asociadas y como una correcta gestión de la Transición podría haber evitado estas situaciones. La puesta en marcha debe ser incremental incorporando la fase de Transición principalmente a nuevos servicios y proyectos evitando en lo posible interferencias con proyectos ya consolidados o en marcha.

Se deben evaluar cuidadosamente en cada caso las ventajas e inconvenientes asociados y planificar consecuentemente el proceso de introducción de la fase de transición.

Organización Los cambios y los nuevos productos y servicios provocan con frecuencia los consecuentescambios organizativos. Estos cambios organizativos pueden implicar:
   

Transferencia de personal Reorganizaciones jerárquicas Cambios procedimentales Recapacitación del personal

Todos estos cambios pueden ser percibidos positivamente por los miembros de la organización TI o por el contrario pueden ser causa de tensiones internas y problemas de carácter personal. Las personas son un componente esencial en los procesos de cambio y evolución y es habitual que las personas muestren sus resistencias y miedos. Es esencial que la fase de transición tome en cuenta este componente emocional actuando en consecuencia:

Analizando las consecuencias organizativas del cambio incluyendo factores tecnológicos y humanos. Dando soporte a todas las personas y equipos implicados. Evaluando la capacitación del personal involucrado tanto en el proceso de transición como de operación del servicio. Garantizando que el personal involucrado dispone de los recursos necesarios. Asegurando el correcto acceso a toda la información necesaria asociada a los nuevos productos y servicios:
o o o o o

 

 

Estrategias. Análisis de mercados. Guías técnicas y manuales. Matrices RACI. Plan de comunicación.

Supervisando y documentando todo el proceso.

Tecnología La tecnología juega un papel crucial en dos aspectos primordiales:
 

Como apoyo a los procesos involucrados en la fase de transición. Como requisito para la implementación de los propios cambios.

La fase de transición puede ser intrínsecamente compleja en organizaciones con una fuerte dependencia tecnológica. La organización del workflow, las pruebas y la generación de toda la documentación asociada al cambio requieren por regla general disponer de herramientas de apoyo que permitan:

Gestionar adecuadamente la base de datos de configuración y activos del servicio para asegurar que está refleja en todo momento una instantánea actualizada de la infraestructura TI. Gestionar el versionado de los servicios. Gestionar de forma ágil y flexible toda la documentación generada. Acceder rápidamente a todo el conocimiento necesario. Supervisar las pruebas realizadas sobre calidad y rendimiento de los nuevos servicios. Supervisar el despliegue de los nuevos servicios. Mantener puntualmente informados a todos los agentes participantes en esta fase de transición.

     

Por otro lado es imprescindible que la infraestructura TI disponga de la tecnología adecuada para la prestación de los servicios nuevos o modificados. Aunque esto pueda parecer una verdad de perogrullo es habitual que organizaciones TI “reactivas” no afronten actualizaciones tecnológicas necesarias hasta que éstas se hacen imperativas por una clara degradación del servicio. Habitualmente nuevos servicios requieren actualizaciones de hardware y software que impidan una degradación de la calidad cuando estos se ven forzados a sus límites de capacidad. Normalmente estas actualizaciones desembocan en procesos de cambio secundarios que es necesario analizar, planificar y supervisar de igual manera y con los mismos niveles de exigencia.

Factores de éxito y riesgos Entre los factores de éxito y retos a los que se debe confrontar la correcta implementación de la Fase de Transición del Servicio se encuentran:

Encontrar el equilibrio entre estabilidad y (r)evolución: los clientes y usuarios quieren servicios estables y siempre operativos pero tienen necesidades cambiantes a las que debe dar respuesta la organización TI. Coordinar los procesos asociados a la Transición del servicio entre ellos y con los asociados a las otras fases del ciclo de vida. Evitar la burocratización del proceso de cambio sin por ello perder el control sobre el mismo. Crear una cultura de intercambio de información y conocimiento que evite los “guetos deknow-how”. Disponer de la adecuada estructura tecnológica y organizativa. Crear los necesarios mecanismos de control y métricas asociadas para la supervisión de todos los procesos, tareas y procedimientos. Desarrollar un workflow que permita la integración de todos los agentes implicados.

 

Los principales riesgos se resumen en:
    

Incrementos injustificados del gasto. Deficiente comunicación entre los agentes implicados. Inmadurez de la organización para asumir los cambios culturales necesarios. Incumplimiento de los protocolos por supuestas razones de urgencia. Falta de recursos para un implementación en exceso ambiciosa.

Relación con otros ciclos Aunque la fase de Transición es una de las mejor delimitadas no debe interpretarse como un compartimento estanco del ciclo de vida del servicio. La fase de Transición recibe sus inputs principales de la fase de Diseño del Servicio y a su vez sirve de principal input a la fase de Operación pero tiene a su vez un fuerte impacto en las restantes fases. 1. TRANSICIÓN Y ESTRATEGIA A la hora de establecer una correcta Estrategia del Servicio es necesario conocer en profundidad sus implicaciones en la fase de Transición del Servicio. Cada cambio y evolución implica costes e inevitablemente tiene un impacto en clientes y usuarios. Es indispensable sopesar los riesgos y potenciales beneficios asociados para establecer una estrategia que minimice los primeros maximizando a su vez los segundos.

TRANSICIÓN Y OPERACIÓN La Operación del Servicio debe suministrar información relevante sobre:   El entorno de producción El conocimiento asociado (incidencias. 2. La fase de Mejora Continua es por sí misma una de las principales fuentes de cambio introduciendo mejoras en los procesos y ajustando la calidad y rentabilidad de los servicios .Por otro lado la Transición del Servicio debe colaborar. usuarios y organización TI. La fase de Transición es clave en este aspecto.  4. TRANSICIÓN Y MEJORA CONTINUA La principal misión de la fase de Mejora Continua es mejorar todos los procesos y tareas involucrados en la prestación del servicio con el objetivo último de mejorar la calidad. en aquello que le corresponde. Los cambios son la fuente principal de incidencias y problemas tanto a nivel interno (componente tecnológica) como a nivel externo (calidad del servicio). 3. percepción de clientes y usuarios…) a servicios similares a los que se han de desplegar. La Transición del Servicio debe poner a disposición de la fase de Operación:  Toda la documentación necesaria asociada al uso y mantenimiento de los nuevos o actualizados servicios. rendimiento y rentabilidad de estos y la consecuente percepción de clientes. La información relativa a los procesos de prueba y evaluación. a dar soporte a la perspectiva y posicionamiento del servicio establecidos en la fase de estrategia. TRANSICIÓN Y DISEÑO La fase de diseño debe proveer de toda la documentación necesaria para elaborar los planes de cambio y realizar el despliegue del servicio:     Planes de capacidad y disponibilidad SPs SLAs Planes de continuidad TI A su vez la fase de Transición debe asesorar al Diseño sobre los riesgos y posibles impactos del cambio en la calidad del servicio.