Manual técnico de ITIL vs 3.0 en Español

b

IIITTTIIILLL VVVEEERRRSSSIIIÓÓÓNNN 333

CCCOOONNNJJJUUUNNNTTTOOO DDDEEE MMMEEEJJJOOORRREEESSS

PPPRRRAAACCCTTTIIICCCAAASSS

GGGEEESSSTTTIIIÓÓÓNNN SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII...

Fundamentos ITIL

DDAATTOOSS

III NNN TTTEEE GGGRRRAAACCC III ÓÓÓNNN

PPP RRROOOCCCEEESSSOOOSSS

IINNFFOORRMMAACCIIÓÓNN

AAACCCCCCEEESSS IIIBBB III LLL IIIDDDAAADDD

SSS IIISSS TTTEEEMMMAAASSS

Edwin Valencia

Fecha 2013

AAA IIISSS LLLAAAMMM III EEE NNNTTTOOO

DDD IIISSSPPPOOONNN IIIBBB III LLL IIIDDDAAADDD

PPP UUUNNN TTTOOO DDDEEE CCCOOONNN TTTRRROOOLLL

CCCEEENNN TTTRRRAAA LLL III ZZZAAADDDOOO

IIIMMMPPP OOOSSS IIIBBB III LLL IIIDDDAAADDD DDDEEE

RRREEECCCHHHAAA ZZZOOO

CCCOOONNNFFF III DDDEEE NNNCCC III AAA LLL III DDDAAADDD

AAAUUUDDD III TTTOOORRR ÍÍÍ AAA

AAAUUU TTTEEE NNN TTTIII CCC III DDDAAADDD

PPP RRR IIINNNCCC IIIPPP III OOO DDDEEE

MMMEEENNNOOORRR PPP RRR III VVV III LLLEEEGGG III OOO

III NNN TTTEEE GGGRRR III DDDAAADDD

CCCOOONNNSSS IIISSS TTTEEE NNNCCC III AAA

MMMaaannnuuuaaalll TTTééécccnnniiicccooo dddeee FFFuuunnndddaaammmeeennntttooosss...

ITIL V.3

IIINNNTTTRRROOODDDUUUCCCCCCIIIÓÓÓNNN::: Este manual técnico ha sido recopilado(Information Technologies Infraestructure Library). El objetivo principal es proporcionar a los métodos y conceptos que subyacen tras ITIL. Aunque este manual no pretende ser el sustituto de ningún programa de formación oficial, creayuda tanto para aquellos que simplemente quieren conocer algo más de ITIL como para aquellos que buscan una certificación oficial como el "Foundation Certificate en Gestión de Servicios TI".

Los procesos de COBIT se enfocan en los requerimientos de la empresa y propse necesita para cumplir con esos requerimientos. ITIL define los procesos considerados “mejores prácticas” para la administración de las TIC, se enfoca en el método y define un conjunto de procesos más detallado qunos indica una ruta para la construcción de procesos. Con la combinación de ITIL y COBIT, las organizaciones de TIC dentro de las empresas pueden lograr cumplir con los objetivos que les plantea la empresa y lo hacen al mismo tiempo que ent ITIL es un conjunto de prácticas de administración de los Servicios. Estás practicas para dar soporte a la entrega de los servicios pueden ayudar a una compañía a documentar sus procesos de TIC ITIL es parte de la base del modelo de COBIT, el cual define los objetivos de control de TI los cuales a su vez dan soporte a los procesos de negocio. ITIL proporciona las guías acerca de lo que debe hacerse para lograr la mejor práctica y COBIT tiene más que ver con probar y establecer un conjunto de objetivos para asegurar el control. COBIT es como una herramienta de auditoría y monitoreo para determinar si las cosas se han hecho bien. La documentación de procesos mediante ITIL y los objetivos de control de COBIT sque puede acelerar el cumplimiento del negocio con Sarbanes Oxley (USA) y BASEL II (Europa).

Manual Técnico

recopilado para ofrecer una guía de introducción al conjunto de Mejores Prácticas de ITIL (Information Technologies Infraestructure Library).

El objetivo principal es proporcionar a los lectores una referencia básica con la que puedan llegar a familiarizarse con los métodos y conceptos que subyacen tras ITIL.

no pretende ser el sustituto de ningún programa de formación oficial, creo que puede ser de gran a aquellos que simplemente quieren conocer algo más de ITIL como para aquellos que buscan una

certificación oficial como el "Foundation Certificate en Gestión de Servicios TI".

Los procesos de COBIT se enfocan en los requerimientos de la empresa y proporcionan una guía para determinar lo que se necesita para cumplir con esos requerimientos. ITIL define los procesos considerados “mejores prácticas” para la administración de las TIC, se enfoca en el método y define un conjunto de procesos más detallado qunos indica una ruta para la construcción de procesos.

Con la combinación de ITIL y COBIT, las organizaciones de TIC dentro de las empresas pueden lograr cumplir con los objetivos que les plantea la empresa y lo hacen al mismo tiempo que entregan servicios de alta calidad a bajo costo.

ITIL es un conjunto de prácticas de administración de los Servicios. Estás practicas para dar soporte a la entrega de los servicios pueden ayudar a una compañía a documentar sus procesos de TIC

de la base del modelo de COBIT, el cual define los objetivos de control de TI los cuales a su vez dan

ITIL proporciona las guías acerca de lo que debe hacerse para lograr la mejor práctica y COBIT tiene más que ver con robar y establecer un conjunto de objetivos para asegurar el control.

COBIT es como una herramienta de auditoría y monitoreo para determinar si las cosas se han hecho bien.

La documentación de procesos mediante ITIL y los objetivos de control de COBIT son una combinación muy poderosa que puede acelerar el cumplimiento del negocio con Sarbanes Oxley (USA) y BASEL II (Europa).

Pág. 2/321

introducción al conjunto de Mejores Prácticas de ITIL

una referencia básica con la que puedan llegar a familiarizarse con los

que puede ser de gran a aquellos que simplemente quieren conocer algo más de ITIL como para aquellos que buscan una

orcionan una guía para determinar lo que se necesita para cumplir con esos requerimientos. ITIL define los procesos considerados “mejores prácticas” para la administración de las TIC, se enfoca en el método y define un conjunto de procesos más detallado que COBIT ya que

Con la combinación de ITIL y COBIT, las organizaciones de TIC dentro de las empresas pueden lograr cumplir con los regan servicios de alta calidad a bajo costo.

ITIL es un conjunto de prácticas de administración de los Servicios. Estás practicas para dar soporte a la entrega de los

de la base del modelo de COBIT, el cual define los objetivos de control de TI los cuales a su vez dan

ITIL proporciona las guías acerca de lo que debe hacerse para lograr la mejor práctica y COBIT tiene más que ver con

COBIT es como una herramienta de auditoría y monitoreo para determinar si las cosas se han hecho bien.

on una combinación muy poderosa

ITIL V.3 Manual Técnico

Pág. 3/321

ITIL fortalece los procesos de entrega y soporte; describe como estructurar los procesos operativos pero su debilidad principal son los controles de seguridad. COBIT se enfoca en controles y métricas. También le hace falta la seguridad, pero proporciona una visión más global de los procesos de TI que la que proporciona ITIL. Las organizaciones de TIC en las empresas actualmente tienen mucha presión en cuanto a la aportación que hacen a las metas del negocio. Aprender ITIL y COBIT te permitirá: 1. Administrar las TIC desde una perspectiva de negocio para lograr las metas de la empresa 2. Establecer metas claras para los procesos, basándose en las metas de la empresa. 3. Asegurar un gobierno de TIC efectivo. 4. Establecer controles a nivel de los procesos. 5. Habilitar a los departamentos de TIC a demostrar como cumplen o exceden los requerimientos. ¿Te parece difícil de aplicar? Piensa por un momento en que sucedería si tienes un equipo de colaboradores que aplican los procesos ITIL y gracias a ello son capaces de diferenciar un INCIDENTE (que requiere de atención inmediata y restauración del servicio para que el negocio continúe operando) de un PROBLEMA (que debe ser analizado hasta encontrar la causa raíz y su acción correctiva irreversible). ¿Que tal si este mismo grupo diseña e implementa un mapa tecnológico (CMDB) de todos los componentes involucrados en la prestación del servicio? por lo que es muy fácil detectar que parte del servicio es afectada cuando un componente falla. El resultado de implementar y ejecutar los procesos ITIL siempre será una muy alta calidad en operación y prestación del servicio así como reducción de costos durante todo el ciclo de vida del servicio. Es muy importante revisar a fondo estas estrategias especialmente en estos tiempos de crisis.

ITIL V.3

CCCOOONNNTTTEEENNNIIIDDDOOO::: Las áreas a cubrir son más amplias que el clásico manual, ya que se adjuntan temas adicionales y compara enriquecerlo.

• La gestión de servicios TI • Gobierno TI • El ciclo de vida de los servicios TI • Funciones, procesos y roles • Apéndice: de ITIL v2 a ITIL v3

Adicionalmente temas como:

• Alineando COBIT® 4.1, ITIL® V3 e ISO• Integración de ITIL con PMBOK• ISO 20000. • Las 10 Cosas que debes Saber Acerca de ITIL• Aprende ITIL y COBIT para administrar las TIC con base en las prioridades de tu negocio

• CMMI. • Glosario términos ITIL.

Manual Técnico

amplias que el clásico manual, ya que se adjuntan temas adicionales y com

El ciclo de vida de los servicios TI

Apéndice: de ITIL v2 a ITIL v3

Alineando COBIT® 4.1, ITIL® V3 e ISO / IEC 27002 en beneficio de la empresa Integración de ITIL con PMBOK � PMI.

Las 10 Cosas que debes Saber Acerca de ITIL Aprende ITIL y COBIT para administrar las TIC con base en las prioridades de tu negocio

Pág. 4/321

amplias que el clásico manual, ya que se adjuntan temas adicionales y complementarios


Pág. 5/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII::: 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. o Modularidad que permite agrupar funcionalidades similares en forma de módulos auto contenidos.

ITIL V.3

o Acoplamiento flexible entre recursos y usuarios, mediante, por ejeevita que cambios o alteraciones en los recursos afecten negativamente a la experiencia de usuario.

� 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 Procesos de control o Feedback y aprendizaje

Manual Técnico

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.

: según ITIL los sistemas son grupos de componentes interrelacionados o interdependientes que laboran entre sí para conseguir un objetivo común. Los aspectos clave para el correcto

rendimiento de un sistema son:

Feedback y aprendizaje.

Pág. 6/321

mplo, sistemas redundantes, que evita que cambios o alteraciones en los recursos afecten negativamente a la experiencia de usuario.

: según ITIL los sistemas son grupos de componentes interrelacionados o interdependientes que laboran entre sí para conseguir un objetivo común. Los aspectos clave para el correcto


Pág. 7/321

GGGOOOBBBIIIEEERRRNNNOOO TTTIII 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.

ITIL V.3

EEELLL CCCIIICCCLLLOOO DDDEEE VVVIIIDDDAAA DDDEEE LLLOOOSSS 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 prinportafolios 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

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. Estos cinco libros ofrecen una guía prácomo estructurar la Gestión de Servicios TI de forma que estos estén correctamente alineados con los procesos de negocio.

Manual Técnico

SS SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII ITIL v3 estructura la gestión de los servicios TI sobre el concepto de Ciclo de Vida de los Servicios.

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

Vida del Servicio consta de cinco fases que se corresponden con los nuevos libros de ITIL: : propone tratar la gestión de servicios no sólo como una capacidad sino como un activo

: cubre los principios y métodos necesarios para transformar los objetivos estratégicos en

: cubre el proceso de transición para la implementación de nuevos servicios o su mejora.re las mejores prácticas para la gestión del día a día en la operación 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.

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. Estos cinco libros ofrecen una guía prácomo estructurar la Gestión de Servicios TI de forma que estos estén correctamente alineados con los procesos de

Pág. 8/321

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

: propone tratar la gestión de servicios no sólo como una capacidad sino como un activo

cipios y métodos necesarios para transformar los objetivos estratégicos en

: cubre el proceso de transición para la implementación de nuevos servicios o su mejora. re las mejores prácticas para la gestión del día a día en la operación del servicio.

: proporciona una guía para la creación y mantenimiento del valor ofrecido a los clientes a

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


Pág. 9/321

FFFUUUNNNCCCIIIOOONNNEEESSS,,, PPPRRROOOCCCEEESSSOOOSSS YYY RRROOOLLLEEESSS ITIL marca una clara distinción entre funciones y procesos. Una función es una unidad especializada en la realización de una cierta actividad y es la responsable de su resultado. Las funciones incorporan todos los recursos y capacidades necesarias para el correcto desarrollo de dicha actividad. Las funciones tienen como principal objetivo dotar a las organizaciones de una estructura acorde con el principio de especialización. 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. En este último caso un modelo organizativo basado en procesos puede ayudar a mejorar la productividad de la organización en su conjunto. Un proceso es un conjunto de actividades interrelacionadas orientadas a cumplir un objetivo específico. Los procesos comparten las siguientes características:

� Los procesos son cuantificables y se basan en el rendimiento. � Tienen resultados específicos. � Los procesos tienen un cliente final que es el receptor de dicho resultado. � Se inician como respuesta a un evento.

El Centro de Servicios y la Gestión del Cambio son dos claros ejemplos de función y proceso respectivamente. Sin embargo, 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. Otro concepto ampliamente utilizado es el de rol. Un rol es un conjunto de actividades y responsabilidades asignada a una persona o un grupo. Una persona o grupo puede desempeñar simultáneamente más de un rol. Hay cuatro roles genéricos 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, implementación, mantenimiento, monitorización y evaluación.

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

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

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


Pág. 10/321

AAAPPPÉÉÉNNNDDDIIICCCEEE::: DDDEEE IIITTTIIILLL VVV222 AAA IIITTTIIILLL VVV333 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. El Ciclo de Vida del Servicio se compone de cinco fases que se retroalimentan entre ellas de una manera cíclica. Los viejos conceptos de Provisión y Soporte al Servicio han sido transmutados en las cinco fases siguientes, que se retroalimentan entre ellas de una manera cíclica:

� Estrategia del Servicio: cuyo propósito es definir qué servicios se prestarán, a qué clientes y en qué mercados.

� Diseño del Servicio: responsable de desarrollar nuevos servicios o modificar los ya existentes, asegurando que cumplen los requisitos de los clientes y se adecuan a la estrategia predefinida.

� Transición del Servicio: encargada de la puesta en operación de los servicios previamente diseñados. � Operación del Servicio: responsables de todas las tareas operativas y de mantenimiento del servicio, incluida

la atención al cliente. � Mejora Continua del Servicio: a partir de los datos y experiencia acumulados propone mecanismos de mejora

del servicio. Sin embargo, 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. Aunque ITIL v3 continúa orientada a procesos, 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 de ITIL v2. ITIL v3 también introduce como elemento básico el concepto de «función», 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». Un ejemplo de función en el marco de ITIL v2 viene dado por el Centro de Servicios o Service Desk. En el siguiente diagrama se muestran las fases del Ciclo de Vida con sus procesos y funciones más destacados:

ITIL V.3

Cabe destacar las siguientes principales diferencias en los procesos definidos para ITIL v3: � Estrategia del Servicio

� Gestión del Portfolio de ServiciosServicios, incluyendo el Catálogo de Servicios prestados, los servicios retirados y los servicios en preparación, es propio de ITILv3.

� Diseño del Servicio � Gestión del Catálogo de Servicios

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 los Proveedores: su principal objetivo es obtener de los proveedoservicio a un precio asequible y adecuado al mercado. En ITIL v2 formaba parte de la Gestión de Niveles de Servicio de los proveedores.

� Gestión de la Seguridad TI: en ITIL v2 se trataba por separado en un libro específico� Transición del Servicio

Manual Técnico

Cabe destacar las siguientes principales diferencias en los procesos definidos para ITIL v3:

Gestión del Portfolio de Servicios: este proceso encargado de la definición de la cartera o Portfolio de Servicios, incluyendo el Catálogo de Servicios prestados, los servicios retirados y los servicios en preparación,

Gestión del Catálogo de Servicios: anteriormente un subproceso de la Gestión de Niveles de Servicio, es un nuevo proceso en ITIL v3 responsable del diseño de un Catálogo de Servicios enfocado a las necesidades de

: su principal objetivo es obtener de los proveedores un alto nivel de calidad en su servicio a un precio asequible y adecuado al mercado. En ITIL v2 formaba parte de la Gestión de Niveles de

: en ITIL v2 se trataba por separado en un libro específico al respecto

Pág. 11/321

gado de la definición de la cartera o Portfolio de Servicios, incluyendo el Catálogo de Servicios prestados, los servicios retirados y los servicios en preparación,

e un subproceso de la Gestión de Niveles de Servicio, es un nuevo proceso en ITIL v3 responsable del diseño de un Catálogo de Servicios enfocado a las necesidades de

res un alto nivel de calidad en su servicio a un precio asequible y adecuado al mercado. En ITIL v2 formaba parte de la Gestión de Niveles de

al respecto


Pág. 12/321

� Gestión del Conocimiento: este proceso se hallaba subdividido en varios procesos en ITIL v2, como, por ejemplo, mediante la base de datos de errores conocidos en la Gestión de Problemas. En ITIL v3 se ha convertido en un proceso por derecho propio.

� 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 la Configuración y Activos del Servicio: Amplía la Gestión de la Configuración de ITIL v2 para incorporar activos no TI.

� Evaluación: exclusivo de ITIL v3, este proceso genérico se ocupa de verificar la relación calidad/precio, el rendimiento y otros parámetros de interés asociados al servicio.

� Operación del Servicio � Gestión de Peticiones: se desgaja en ITIL v3 de la Gestión de Incidencias, encargándose de gestionar las

peticiones de cambio solicitadas por los clientes. � Gestión de Eventos: nueva, como tal, 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. � Gestión de Accesos: es un nuevo proceso en ITIL v3. 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. � Además del Centro de Servicios ITIL v3 introduce nuevas funciones:

� Gestión de Operaciones TI: responsable del mantenimiento de la infraestructura TI. � Gestión Técnica: responsable del soporte técnico a todos los agentes implicados en la Gestión del Servicio. � Gestión de Aplicaciones: responsable de la gestión de las aplicaciones de software durante todo su ciclo de

vida. � Mejora Continua del Servicio

� Sus actividades estaban subsumidas por la Gestión de Niveles de Servicio en ITIL v2. � Proceso de Mejora CSI: establece los protocolos de monitorización, seguimiento y generación de informes y

es, en particular, la responsable de generar los Planes de Mejora del Servicio (SIP). � Informes de servicio: genera los informes sobre rendimiento, resultado y calidad de los servicios ofrecidos.


Pág. 13/321


Pág. 14/321


Pág. 15/321


Pág. 16/321

DDDEEESSSAAARRRRRROOOLLLLLLAAARRR EEESSSTTTRRRAAATTTEEEGGGIIIAAASSS DDDEEE LLLOOOSSS SSSEEERRRVVVIIICCCIIIOOOSSS... Desarrollar Estrategia de los Servicios. 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. 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. Una correcta Estrategia del Servicio debe:

• Servir de guía a la hora de establecer y priorizar objetivos y oportunidades. • Conocer el mercado y los servicios de la competencia. • Armonizar la oferta con la demanda de servicios. • Proponer servicios diferenciados que aporten valor añadido al cliente. • Gestionar los recursos y capacidades necesarios para prestar los servicios ofrecidos teniendo en cuenta los

costes y riesgos asociados. • Alinear los servicios ofrecidos con la estrategia de negocio. • Elaborar planes que permitan un crecimiento sostenible. • Crear casos de negocio para justificar inversiones estratégicas.

La fase de Estrategia del Servicio es el eje que permite que las fases de Diseño, Transición y Operación del servicio se ajusten a las políticas y visión estratégica del negocio. Una correcta implementación de la estrategia del servicio va más allá del ámbito puramente TI y requiere un enfoque multidisciplinar que ayude a responder cuestiones tales como:

� ¿Qué servicios debemos ofrecer? � ¿Cuál es su valor? � ¿Cuáles son nuestros clientes potenciales? � ¿Cuáles son los resultados esperados? � ¿Qué servicios son prioritarios? � ¿Qué inversiones son necesarias? � ¿Cuál es el retorno a la inversión o ROI? � ¿Qué servicios existen ya en el mercado que puedan representar una competencia directa? � ¿Cómo podemos diferenciarnos de la competencia?

ITIL V.3

CCCRRREEEAAACCCIIIÓÓÓNNN DDDEEE VVVAAALLLOOORRR Los servicios son definidos en ITIL como un medio decostes específicos de su prestación. Pero el valor al que nos referimos no depende exclusivamente del valor económico asociado al resultado específico de cada servicio. En nuestro caso el valor incluye algunos otros intangibles entre los que se incluye la percepción del cliente. En el lado positivo de la ecuación cuentan:

� La utilidad ofrecida que debe adaptarse a las necesidades reales del cliente,� La garantía del proveedor que asegura que e

de calidad acordados, y en la negativo aspectos tales como:o La pérdida de control de todo el proceso,o Costes ocultos, o Una inferior calidad, o “caer cautivo” en manos de un proveedor de servic

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 y garantía de un servicio son con frecuencia interdependientes organización TI debe buscar un equilibrio entre ambas minimizando a su vez los aspectos que los potenciales clientes puedan percibir negativamente. La utilidad requiere que el servicio:

� cumpla los requisitos del cliente,� aumente el rendimiento � y debe resultar en un beneficio para el cliente, bien disminuyendo directamente los costes o contribuyendo a

aumentar los ingresos. 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, puede ofrecer una interesante utilidad a buen precio pero si el cliente percibe una alta sensación de riesgo no lo contratará.

Manual Técnico

Los servicios son definidos en ITIL como un medio de aportar valor al cliente sin que éste deba asumir los riesgos y

Pero el valor al que nos referimos no depende exclusivamente del valor económico asociado al resultado específico de lor incluye algunos otros intangibles entre los que se incluye la percepción del

En el lado positivo de la ecuación cuentan: utilidad ofrecida que debe adaptarse a las necesidades reales del cliente, garantía del proveedor que asegura que el servicio se prestará de forma continuada preservando los niveles

y en la negativo aspectos tales como: pérdida de control de todo el proceso,

“caer cautivo” en manos de un proveedor de servicios.

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

l cliente,

y debe resultar en un beneficio para el cliente, bien disminuyendo directamente los costes o contribuyendo a

disponible cuando se le necesite

rectamente dimensionado para cumplir sus objetivos

de mecanismos de respaldo que permitirán su continuidad Un servicio, por ejemplo, puede ofrecer una interesante utilidad a buen precio pero si el cliente percibe una alta

Pág. 17/321

aportar valor al cliente sin que éste deba asumir los riesgos y

Pero el valor al que nos referimos no depende exclusivamente del valor económico asociado al resultado específico de lor incluye algunos otros intangibles entre los que se incluye la percepción del

l servicio se prestará de forma continuada preservando los niveles

El proveedor debe tener en cuenta que el valor para el cliente está en el resultado del servicio y el impacto que éste tiene

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

y debe resultar en un beneficio para el cliente, bien disminuyendo directamente los costes o contribuyendo a

Un servicio, por ejemplo, puede ofrecer una interesante utilidad a buen precio pero si el cliente percibe una alta


Pág. 18/321

AAACCCTTTIIIVVVOOOSSS DDDEEELLL SSSEEERRRVVVIIICCCIIIOOO Para que una organización TI pueda ofrecer valor en forma de servicios debe hacer buen uso de sus recursos y capacidades. Los recursos son la “materia prima” necesaria para la prestación del servicio e incluyen el capital, las infraestructuras, aplicaciones e información. Las capacidades representan las habilidades desarrolladas a lo largo del tiempo para transformar los recursos en valor a través de la gestión, la organización, los procesos y el conocimiento. Y en la base de ambos se encuentra el personal que es en sí mismo un recurso que aporta entre otras capacidades su profesionalidad, creatividad y capacidad de liderazgo.

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. 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. A modo de ejemplo, 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”. 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.


Pág. 19/321

PPPRRROOOVVVEEEEEEDDDOOORRREEESSS DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 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

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. Cada tipo de proveedor de servicios tiene sus ventajas e inconvenientes que pasamos a analizar. 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:

Mayor control sobre los servicios prestados. Mayores niveles de personalización. Comunicación directa.

En el lado opuesto de la balanza cabe destacar:

Los recursos pueden no estar optimizados. Dificultad a la hora de incrementar las capacidades. Organizaciones más endogámicas y menos flexibles. 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. 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. Estandarización de procesos. Mayores opciones de crecimiento

Y entre las desventajas se incluyen: Asumir actividades que no aportan ventajas competitivas a la organización. Posibles conflictos de intereses entre diferentes unidades de negocio.

Proveedores de Servicios Externo (Tipo III) Estos proveedores ofrecen sus servicios en el mercado a diferentes clientes que frecuentemente serán competidores entre sí. Las ventajas de la contratación externa de los servicios son evidentes, siempre que estos no formen parte integrante del núcleo del negocio del cliente, se resumen en:

Mayor flexibilidad y oferta. Se minimizan los riesgos pues estos son compartidos entre una amplia red de clientes. Procedimientos estandarizados.

Entre las desventajas se cuentan: Altos niveles de personalización de los servicios pueden resultar costosos. El cliente puede caer cautivo de un proveedor externo.


Pág. 20/321

RRREEEDDDEEESSS DDDEEE VVVAAALLLOOORRR ITIL generaliza el concepto de cadena de valor al de red de valor que se adecua mucho mejor al caso de los servicios TI. 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. Sin embargo los modelos lineales no son capaces de modelar los procesos y actividades necesarias para la correcta gestión de un servicio TI. Aunque el modelo de cadena de valor puede seguir siendo útil en el análisis de ciertos casos ITIL 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.

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?


Pág. 21/321

LLLAAASSS 444 PPP DDDEEE LLLAAA EEESSSTTTRRRAAATTTEEEGGGIIIAAA 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. • Posición: definir y diferenciar nuestros servicios. • Planificación: establecer criterios claros de desarrollo futuro. • Patrón: mantener una coherencia en la toma de decisiones y acciones adoptadas.

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. Debe establecer las reglas generales del juego tanto dentro de la organización TI como en la relación con sus clientes. 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, cómo serán prestados y a quién, diferenciándolos de los de su competencia. Existen diversas posibilidades para posicionarse en el mercado. 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. Características como el precio, la seguridad, la calidad o el soporte técnico ofrecido pueden servir para diferenciarnos de nuestra competencia. La Planificación es esencial en un entorno en constante desarrollo que nos obligará a evolucionar constantemente nuestra estrategia del servicio. Los planes deben de establecer una hoja de ruta para alcanzar los objetivos generales establecidos. Estos planes han de realizarse para el medio largo plazo centrándose principalmente en evoluciones del Portfolio de Servicios, inversiones estratégicas, nuevos desarrollos y planes de mejora. 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. 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.

ITIL V.3

PPPRRROOOCCCEEESSSOOOSSS Los procesos asociados directamente a la fase de Estrategia son:

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

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

• Gestión de la Demanda: responsable dedemandas del mercado.

Manual Técnico

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

precio. Gestión del Portafolio de Servicios: responsable de la inversión en servicios nuevos y actualizados que ofrezcan el máximo valor al cliente minimizando a su vez los riesgos y costes asociados. Gestión de la Demanda: responsable de la armonización de la oferta de los servicios ofrecidos con las

Pág. 22/321

Gestión Financiera: responsable de garantizar la prestación de servicios con unos costes controlados y una

Gestión del Portafolio de Servicios: responsable de la inversión en servicios nuevos y actualizados que

la armonización de la oferta de los servicios ofrecidos con las


Pág. 23/321


Pág. 24/321

GGGEEESSSTTTIIIÓÓÓNNN FFFIIINNNAAANNNCCCIIIEEERRRAAA 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, 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. • No se presupuestan correctamente los gastos asociados. • Es prácticamente imposible establecer una política de precios consistente.

El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costes asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos TI necesarios. Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios, no podrán evaluar el retorno de la inversión ni podrán establecer planes consistentes de gasto tecnológico. Nota: Las propiedades y funcionalidades de la Gestión Financiera de los Servicios TI se resumen sucintamente en el siguiente interactivo:

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. Por regla general, a mayor calidad de los servicios, mayor es su coste, por lo que es necesario evaluar cuidadosamente las necesidades del cliente para que el balance entre ambos sea óptimo.


Pág. 25/321

Para lograr este objetivo, la Gestión Financiera debe:

• Evaluar los costes reales asociados a la prestación de servicios. • Proporcionar a la organización TI toda la información financiera precisa para la toma de decisiones y fijación de

precios. • Asesorar al cliente sobre el valor añadido que proporcionan los servicios TI prestados. • Evaluar, en colaboración con la Gestión del Portfolio de Servicios, un análisis financiero del retorno de la

inversión (ROI). • Llevar la contabilidad de los gastos asociados a los servicios TI.

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

• Se reducen los costes y aumenta la rentabilidad del servicio. • Se ajustan, controlan, adecuan y justifican (si es de aplicación) los precios del servicio, aumentando la

satisfacción del cliente. • Los clientes contratan servicios que le ofrecen una buena relación coste/rentabilidad. • La organización TI puede planificar mejor sus inversiones al conocer los costes reales de los servicios TI. • Los servicios TI son usados más eficazmente. • La organización TI funciona como una unidad de negocio y es posible evaluar claramente su rendimiento

global. Las principales dificultades a la hora de implementar la Gestión Financiera de los Servicios Informáticos se resumen en:

• Es difícil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos financieros y/o contables.

• Existen mú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. • Un incremento de los costes. • No hay un compromiso de toda la organización con el proceso.

Categorías de coste La clasificación de costes por servicio o producto puede realizarse en virtud de uno a más criterios:


Pág. 26/321

Costes atribuibles, directa o indirectamente, a la prestación del servicio o elaboración del producto:

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

• Costes indirectos: aquellos que no son específicos y exclusivos de un servicio, como por ejemplo, la "conectividad" de la organización TI de la que dependen tanto los servicios web como la propia plataforma general de comunicaciones. Estos costes son más difíciles de determinar y, por lo general, son prorrateados entre los diferentes servicios y productos.

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

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

• Costes variables: incluyen aquellos costes que dependen del volumen de producción y engloban, por ejemplo, los gastos de personal que presta los servicios, los fungibles, etc.

Costes que dependen del horizonte temporal:

• Costes de capital: que proviene de la amortización del inmovilizado material o inversiones a largo plazo. • Costes de operación: son los costes asociados al funcionamiento diario de la organización TI.

Tipos de coste

• Los tipos de coste son gastos de alto nivel, como hardware, software, personal, administración, ubicaciones físicas, servicios externos y costes de transferencia interdepartamentales.

Es imprescindible distinguir entre los diferentes tipos de coste para diseñar una política de precios clara y consistente. El número de tipos de costes varía dependiendo del tamaño de la organización TI y sus necesidades. Los tipos de coste se subdividen a su vez en elementos de coste. Elementos de coste del hardware, por ejemplo, serían servidores, ordenadores de sobremesa, etc.


Pág. 27/321

El siguiente diagrama muestra una típica estructura de tipos y elementos de coste para una organización TI:


Pág. 28/321

CCCOOOSSSTTTEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII Los costes de transferencia se corresponden con los cargos internos por servicios prestados por otros departamentos de la empresa o institución. Valor de provisión El valor de provisión de un servicio comprende los costes de creación del mismo, ya sean éstos tangibles o intangibles. Responde a la pregunta: «¿Cuánto cuesta mantener este servicio?» Algunos ejemplos de costes relacionados con el valor de provisión son los impuestos, los costes de licencias de hardware y software, las instalaciones, etc. 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. Valor potencial del servicio El valor potencial del servicio se refiere al valor añadido que aporta. Se basa en la percepción del servicio que se forma el cliente al considerar qué ventajas o mejorías (en términos de utilidad y garantía) representa para su negocio utilizar el servicio en lugar de sus propios activos. 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. Retorno de la inversión (ROI) El retorno de la inversión (ROI), al menos en gestión de servicios, se refiere a la capacidad de un servicio para generar valor mediante sus activos. El ROI se calcula dividiendo el beneficio neto de una actividad entre el valor neto de los activos que han intervenido en el proceso. Por lo general, dependiendo del impacto del negocio se pueden prever distintos grados de ROI. 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. Por eso, es necesario poner en práctica a la hora de calcular el ROI:

• Caso de Negocio, técnicas para identificar los imperativos de negocio que dependen de la gestión del servicio. • Pre-ROI, técnicas para analizar cuantitativamente una inversión dentro de la gestión del servicio. • Post-ROI, técnicas para analizar de forma retroactiva 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. Gracias a la VCD se puede calcular, por ejemplo, cuál será el impacto financiero de añadir o eliminar cierta unidad del servicio. En dicho análisis puede considerar las siguientes variables:

• Número y tipo de usuarios. • Número de licencias de software. • Costes de mantenimiento del centro de datos. • Mecanismos de distribución. • Número y tipo de recursos. • Coste de añadir uno o más dispositivos de almacenamiento. • Coste de añadir una o más licencias de usuario final.

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

� Presupuestos: � Análisis de la situación financiera. � Fijación de políticas financieras. � Elaboración de presupuestos.

� Contabilidad:


Pág. 29/321

� Identificación de los costes. � Definición de elementos de coste. � Monitorización de los costes.

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

Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.

Presupuestos La elaboración de presupuestos TI tiene como objetivos principales:

� Planificar el gasto e inversión TI a largo plazo. � Asegurar que los servicios TI están suficientemente financiados. � Establecer objetivos claros que permitan evaluar el rendimiento de la organización TI.

Los presupuestos realizados pueden tener diferentes horizontes temporales. Pueden ser a corto plazo, incluyendo los costes de los servicios prestados en la actualidad, o resultar de una proyección sobre la evolución prevista del negocio en dos o más años. Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales:


Pág. 30/321

� Presupuesto incremental: el presupuesto se realiza en base al histórico de presupuestos anteriores, adaptándolos a las modificaciones en los costes y el desarrollo de nuevas tecnologías, y teniendo en consideración la aparición de nuevas líneas de servicios.

� Presupuesto "desde cero": se replantea toda la estructura de costes e inversiones a partir de una "hoja en blanco" en base a los servicios prestados en la actualidad y las expectativas de crecimiento en el periodo presupuestado.

Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI es necesario identificar previamente todos los elementos de coste. La estimación de los costes asociados a esos elementos no es siempre una tarea sencilla y a menudo influyen factores externos que no se hallan bajo el control directo de la organización TI, como por ejemplo el aumento del precio de las licencias del software, etc. Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos al respecto para evitar que se conviertan en papel mojado al menor vaivén del mercado. Contabilidad En principio, la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada a otros servicios o departamentos. Sin embargo, la complejidad de las interrelaciones TI dificulta el proceso cuando los responsables de su contabilidad desconocen los mecanismos básicos y la tecnología que los sustenta. Es esencial que el proceso contable tenga en cuenta esa complejidad y a su vez no alcance un excesivo nivel de detalle que lo encarezca más allá de lo razonable. Las actividades contables deben permitir:

� Una correcta evaluación de los costes reales para su comparación con los presupuestados. � Tomar decisiones de negocio basadas en los costes de los servicios. � Evaluar la eficiencia financiera de cada uno de los servicios TI prestados. � Facturar adecuadamente, si es de aplicación, los servicios TI.

Si se desea considerar a la organización TI como otra unidad de negocio es necesario conocer en detalle tanto sus costes como sus "ingresos" (aunque estos últimos en muchos casos sólo sean nominales pues el cliente es la propia organización). Es una de las actividades principales de la Gestión Financiera identificar los denominados elementos de coste que se pueden clasificar de forma genérica en:

� Costes de hardware y software, � Costes de personal, � Costes de administración, asignando a cada servicio/cliente su parte proporcional.

Política de Precios No es habitual que se fijen los precios de los servicios TI cuando el cliente es la propia organización, pero este es un paso esencial si buscamos que se utilice eficientemente la infraestructura TI. Para que la organización TI pueda funcionar como una verdadera unidad de negocio, es imprescindible tanto conocer los costes reales de los servicios prestados como establecer una política de precios que, cuanto menos, permita recuperar los costes en los que se ha incurrido. En primer lugar, debe establecerse una política de fijación de precios. Existen múltiples opciones, entre ellas:

� Coste más margen: se establecen los costes totales del servicio y se les añade un margen de beneficios (que puede ser del 0% para "clientes internos").

� Precio de mercado: se cobran los servicios en función de las tarifas vigentes en el mercado para servicios de similar naturaleza.

� Precio negociado: se negocia directamente con el cliente cuál es el precio estipulado por los servicios. � Precio flexible: que depende de la capacidad TI realmente utilizada y/o de los objetivos cumplidos.


Pág. 31/321

Una vez determinada la política de fijación de precios se deben determinar las tarifas de los servicios en función de: � La política elegida. � Los servicios solicitados. � Factores de escala y necesidades de disponibilidad. � Los costes asociados. � Los precios vigentes en el mercado.

En algunas ocasiones estas tarifas serán usadas para una facturación real mientras que en otras sólo se utilizarán de referencia para evaluar el rendimiento teórico de la organización TI. 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. Son la Gestión de Niveles de Servicio y la Gestión del Catálogo de Servicios, respectivamente, quienes se ocupan de ello. Sin embargo, es recomendable que, en los aspectos económicos la actividad de estos procesos sea supervisada por la Gestión Financiera. Para ello es necesario que exista una comunicación fluida y convenientemente estructurada entre ambos procesos. Por un lado, principalmente la Gestión de Niveles de Servicio y la Gestión del Catálogo de Servicios, 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. � Los SLAs contratados. � Los contratos de soporte (UCs) en vigor. � Tendencias del mercado y los Planes de Mejora del Servicio (SIP).

Mientras que la Gestión Financiera debe aportar información sobre:

� Los costes reales de los servicios. � Previsiones de costes. � Desviaciones en las previsiones de costes respecto a los gastos reales. � Métodos y condiciones de pago.

Sin una estrecha colaboración entre ambos procesos, será imposible llegar a acuerdos que sean rentables y a su vez satisfactorios para el cliente. Control del proceso La responsabilidad del proceso de Gestión Financiera recae sobre el Gestor Financiero. 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. Para poder evaluar la función de la Gestión Financiera es necesario establecer tanto unos criterios claros para evaluar su éxito como unos indicadores de rendimiento específicos. Entre los primeros cabe destacar:

� ¿Conoce la organización los costes reales de los servicios TI? � ¿Los clientes perciben la política de precios como coherente y ajustada al mercado? � ¿Colaboran los responsables de los otros procesos TI con la Gestión Financiera? � ¿Están los gastos en servicios e infraestructuras TI realmente alineados con los procesos de negocio? � ¿Opera la organización TI como una verdadera unidad de negocio?

En lo que respecta a los indicadores de rendimiento, éstos deben incluir métricas que permitan evaluar si: � Los gastos TI están correctamente planificados y presupuestados. � Se cumplen los objetivos de costes e ingresos. � Se lleva a cabo una contabilidad precisa asociada a cada servicio. � Se conoce el ROI de las inversiones TI. � La organización TI funciona de manera "rentable".

La correcta elaboración de informes internos de gestión permite evaluar el rendimiento de la Gestión de Financiera según los parámetros arriba descritos y aporta información de vital importancia a la organización en su conjunto.

ITIL V.3

Entre la documentación generada cabría destacar:� Resúmenes contables. � Análisis de eficiencia de cada uno de los servicios TI.� Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología.� Planes de reducción de costes por servicio.� Análisis de impacto en el negocio (BIA) en caso de producirse una interrupción de las operaciones.

Manual Técnico

Entre la documentación generada cabría destacar:

Análisis de eficiencia de cada uno de los servicios TI. Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología.

n de costes por servicio. Análisis de impacto en el negocio (BIA) en caso de producirse una interrupción de las operaciones.

Pág. 32/321

Planes de inversión TI basados en el histórico del negocio y en previsiones de evolución de la tecnología.

Análisis de impacto en el negocio (BIA) en caso de producirse una interrupción de las operaciones.


Pág. 33/321


Pág. 34/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEELLL PPPOOORRRTTTFFFOOOLLLIIIOOO DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 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. Se ocupa, asimismo, de facilitar a los gestores de productos la tarea de evaluar los requisitos de calidad y los costes que éstos conllevan. La Gestión del Portfolio se relaciona directamente con los siguientes procesos de las fases del Ciclo de Vida:

� La Gestión Financiera, en la fase de Estrategia, proporciona al Portfolio la información necesaria para comprender en profundidad los costes del servicio.

� En la fase de Diseño, 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, ya que provee de información estratégica fundamental para orientar cualquier actividad. Nota: Las propiedades y funcionalidades de la Gestión del Portfolio se resumen sucintamente en el siguiente interactivo:

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. Para cumplir su cometido, la Gestión del Portfolio de Servicios desempeña las siguientes tareas:

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

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

� Definir de forma detallada los servicios que se ofrecerán a los clientes. Es tarea de la Gestión del Portfolio de Servicios elegir, de entre todos los servicios posibles que puede ofertar la organización TI, cuáles se ajustan mejor a los objetivos planteados, ofrecen mejores perspectivas de negocio, aportan mayor valor a los clientes, etc.

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, la organización es capaz de optimizar sus capacidades para ofrecer el mayor valor añadido, obteniendo niveles óptimos de ROI a un bajo coste.

� Al contar con unos objetivos claros que rigen las líneas estratégicas de la organización, se evita el peligro de caer en una excesiva diversificación del negocio en servicios dispares, situación que a menudo es interpretada por los clientes como signo de incoherencia.

Con los objetivos del servicio. 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. Pronto se manifiestan los síntomas de una excesiva diversificación del negocio: los servicios son difíciles de agrupar, etc.

� Al tratarse de servicios “a medida”, una vez desaparecido el cliente es muy difícil vender el servicio y por lo general, hay que desmantelarlo.

� Al retirar un servicio concreto, 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. Esto repercute en un desaprovechamiento de los recursos, ya porque se renuevan excesivamente o porque se reasignan a cometidos demasiado alejados de sus capacidades.


Pág. 35/321

� Al no existir unos objetivos claros y bien definidos, 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.

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

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

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

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

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

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.


Pág. 36/321

Definición del negocio El punto de partida de la Gestión del Portfolio de Servicios está, como es lógico, en conocer el mercado en que se va a desarrollar el servicio. No hacerlo puede acarrear consecuencias muy graves como, por ejemplo, averiguar demasiado tarde que otro competidor ofrece el mismo servicio por la mitad de precio. 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. Por tanto, 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. � Previsiones de costes directos e indirectos de la creación y mantenimiento de cada uno de esos servicios. � Necesidades de los clientes existentes o potenciales. � Ofertas de servicio de otros proveedores de la competencia. � Casos de Negocio.

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:

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

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


Pág. 37/321

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

� ¿Cuáles serán los modelos de cobro y facturación? � ¿Cuáles son las debilidades, amenazas, fortalezas y oportunidades de nuestra organización frente al

mercado? � ¿Cómo ha de ser el reparto de recursos y capacidades? � ¿Cuáles son los objetivos de la organización a largo plazo? � ¿Qué servicios serían necesarios para alcanzar esos objetivos? � ¿Qué capacidades y recursos se necesitan para crear y mantener esos servicios?

Aprobación de servicios Los planteamientos estratégicos resultantes de la fase de definición han de ser debidamente autorizados por la Gestión del Portfolio de Servicios, que no sólo es la encargada de aprobar o rechazar los servicios, sino también de asignar los recursos necesarios para suministrar el servicio. En la toma de decisión, la Gestión del Portfolio de Servicios tiene en cuenta dos factores: el valor que aporta la iniciativa y el riesgo que conlleva. Tan sólo aquellos servicios en los que ambas facetas estén equilibradas podrán ser aprobados. Las inversiones del servicio se clasifican en tres categorías estratégicas:

� Inversiones para mantener el negocio (RTB), enfocadas a la Operación del servicio. Estas inversiones apenas conllevan riesgos.

� Inversiones de crecimiento del negocio (GTB), cuyo fin es ampliar el abanico de servicios. Esta clase de inversiones conllevan un riesgo medio.

� Inversiones para transformar el negocio (TTB), encaminadas hacia nuevos espacios de mercado. Esta clase de inversiones son las que mayores riesgos comportan.

Las decisiones que pueden aplicarse a un servicio son:

� Retención: se asigna a servicios con límites de activos, procesos y sistemas bien definidos que están alineados con la estrategia general de la organización.

� Sustitución: Servicios con funcionalidades que son poco claras o bien se solapan con las de otro servicio. � Racionalización: Se aplica a portfolios con servicios que son, de hecho, múltiples versiones del mismo sistema

operativo, servicio, aplicación, etc. � Refactorización: A menudo, los servicios que encajan con los criterios funcionales y técnicos de la organización

presentan límites de procesos o sistemas enmarañados. En estos casos, el servicio puede ser refactorizado para dejar sólo la funcionalidad básica, con servicios comunes para proporcionar el resto de funcionalidades.

� Renovación: Servicios que se ajustan a los criterios de funcionalidad pero no a los técnicos. � Retirada: Servicios que no se ajustan a ninguno de los criterios y por tanto se decide desmantelar.

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. Una vez evaluadas las exigencias del mercado, definidas unas premisas estratégicas básicas, seleccionados los servicios a prestar y asignados los recursos y plazos, llega el momento de registrar esa información para que pueda ser utilizada por otros procesos del Ciclo de Vida del servicio. El documento resultante es el Portfolio de Servicios o Cartera de Servicios. El Portfolio de Servicios comprende una lista completa y detallada de los servicios administrados por la organización, describiéndolos en términos de valor para el negocio. La información disponible para cada servicio debe contemplar los siguientes aspectos:

� Requisitos y especificaciones funcionales. � Descripción detallada de los servicios prestados. � Propuesta de valor añadido. � Casos de negocio. � Prioridades. � Riesgos. � Costes asociados.


Pág. 38/321

� Ofertas y paquetes del servicio. � Modalidades de contratación y precios.

Algunos de estos servicios atañen directamente a los clientes, por lo que la información también ha de estar disponible para ellos. En cambio, la información sobre los servicios relacionados con la infraestructura de la organización es de carácter interno. Esto obliga a dividir el Portfolio de Servicios en tres subconjuntos: el Catálogo de Servicios, el Flujo de Creación del Servicio, y los Servicios Retirados. Catálogo de Servicios El Catálogo de Servicios está enfocado a los clientes, e incluye tan sólo aquellos servicios que la organización está prestando actualmente. El enfoque ha de ser comercial, y debe cuidarse mucho el lenguaje para no emplear tecnicismos. La Gestión del Catálogo de Servicios constituye un proceso aparte que veremos en el capítulo dedicado a la Estrategia del Servicio. Flujo de Creación de Servicio El Flujo de Creación de Servicio, en lugar de ocuparse de los servicios que se prestan actualmente, como hace el Catálogo de Servicios, incluye los servicios que están en fase de estudio o desarrollo. 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. Servicios Retirados Aunque un servicio haya sido retirado o esté próximo a su desmantelamiento, es importante conservar la documentación relacionada puesto que otros procesos pueden verse en la necesidad de recurrir a ella. Un ejemplo sería el Centro de Servicios, al que se le puede presentar el caso de un cliente que solicita soporte para un servicio retirado. En esta situación, 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. 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. � Número de nuevos clientes. � Número de clientes que se han cambiado a la competencia.


Pág. 39/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA DDDEEEMMMAAANNNDDDAAA Visión general Al contrario que los bienes materiales, los servicios no pueden producirse con antelación y almacenarse hasta que el cliente los solicita. Es un proceso simultáneo: la producción y el consumo tienen lugar al mismo tiempo, circunstancia que complica enormemente la planificación de la demanda. La Gestión de la Demanda se encarga de predecir y regular los ciclos de consumo, 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. Por lo general, cuanto mejor funciona un servicio, mayor demanda genera. Ésta, a su vez, provoca exigencias de capacidad que los responsables compensan, como es natural, incrementando los activos del servicio. 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: Sin embargo, el incremento de uno y otro lado del engranaje no tiene por qué ser paralelo. De ahí la importancia para la organización de la Gestión de la Demanda, que ayuda a racionalizar el uso y contratación de los recursos. 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, puede, con los informes de la Gestión de la Demanda, optimizar la planificación para ajustarse a los patrones de consumo.

� La Gestión del Portfolio de Servicios puede aprobar inversiones en capacidad extra, nuevos servicios o cambios en los servicios basándose en el consumo.

� El Catálogo del Servicio puede también trazar patrones de demanda para ciertos servicios. � La Operación del Servicio puede ajustar la asignación de recursos y planificar mejor hallando esquemas

comunes de demanda. � La Gestión Financiera puede aprobar incentivos adecuados para influir la demanda.

Nota: Las propiedades y funcionalidades de la Gestión de la Demanda se resumen sucintamente en el siguiente interactivo:


Pág. 40/321

Introducción y objetivos El objetivo principal de la Gestión de la Demanda es optimizar y racionalizar el uso de los recursos TI. Su papel cobra especial protagonismo cuando existen problemas de capacidad en la infraestructura TI, tanto por exceso como por defecto. 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. � Interrupciones parciales del servicio por errores de hardware o software. � 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. La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en consecuencia. Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Un aumento de la capacidad siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorización de la capacidad permite reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad. Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por la organización se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicos asociados a procesos automáticos (tales como campañas de marketing promocional, informes de rendimiento para clientes, etcétera). En la mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio, ahorrando a la organización una gravosa ampliación del ancho de banda. Ahora bien, si el coste añadido por aumentar el ancho de banda es marginal, puede resultar más eficiente su contratación directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en la optimización del sistema. 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. Los SP comprenden un Paquete de Nivel de Servicio (SLP), uno o más servicios esenciales y uno o más servicios de soporte. Paquete 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. Los SLP se diseñan conforme a las necesidades de un Patrón de Actividad de Negocio (PBA) particular. 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. 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). Cada LOS tiene asignado un Gestor de Producto. 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, con distintas opciones para cada segmento del mercado de acuerdo a sus

necesidades, empaquetando de manera distinta los servicios esenciales y los de soporte. 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.


Pág. 41/321

Análisis de actividad 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. El enfoque más extendido para predecir la demanda es el basado en actividades, 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.


Pág. 42/321

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.

� Asignar las unidades de demanda adicionales generadas por la actividad del negocio a elementos de la capacidad del servicio.

� Asegurarse de que, 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.

Por otro lado, 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, agrupándolos por segmentos de mercado. � Alternativas de las que disponen los clientes de esos segmentos, tanto si se trata de servicios ofrecidos por sus

propias organizaciones como de otros proveedores de la competencia. Desarrollo de la oferta Una vez realizado un análisis del negocio y concretados una serie de patrones de demanda del mismo, es el momento de racionalizar los servicios. El punto de partida consiste en distinguir dos grandes grupos de servicios:

� Servicios esenciales, sin los que el negocio no puede satisfacer las necesidades del cliente. Representan el valor que el cliente desea y por tanto, por lo que está dispuesto a pagar.

� Servicios de soporte, que pueden estar orientados a dar continuidad al servicio o a mejorar su propuesta de valor (p.ej. Centro de Atención al Usuario). Representan aquellas características que diferencian nuestro producto de otros similares ofrecidos por la competencia.

La Gestión de la Demanda toma estos elementos y, con la información que tiene a su alcance acerca del mercado y las necesidades de los clientes, define una serie de paquetes de servicio adaptados a los distintos segmentos de clientes. Los paquetes de servicio contienen una descripción detallada del servicio TI, que ha de incluir necesariamente:

� Paquete de nivel de servicio (SLP). En él se especifican los niveles de utilidad y garantía de los que disfrutarán los usuarios de los servicios.

� Uno o más servicios esenciales y su descripción. � Uno o más servicios de soporte y su descripción.

Este proceso, que podemos llamar empaquetado o paquetización, permite a la organización adaptar el suministro de un mismo servicio a distintos casos de negocio, con diferentes niveles de servicio, precios, etc.


Pág. 43/321

Adicionalmente, al definir una serie de servicios esenciales, se crea un Paquete de Servicio Esencial (CSP) cuyos activos son compartidos para todos los paquetes de servicio.

La Gestión de la Demanda debe comprobar, por último, que los distintos paquetes de servicio deben ajustarse debidamente a las restricciones financieras (p.ej. políticas de precios y facturación), técnicas (p.ej. conexión) y físicas (p.ej. disponibilidad) a las que está sometida la organización TI. Dado el caso, 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. 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.

Restringir aquellas actividades que no sean urgentes durante los periodos de mayor actividad. 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. � Número de interrupciones del servicio ocasionadas por picos de la demanda no previstos. � 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. � Número cambios no planificados que se han efectuado en el servicio con el fin de ajustarse a la demanda.

Puesta en Marcha La implementación de la Estrategia del Servicio requiere abordar aspectos metodológicos, organizativos, tecnológicos, análisis de riesgos y definición de los factores críticos de éxito entre otros. 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?


Pág. 44/321

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


Pág. 45/321

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

ITIL V.3

TTTEEECCCNNNOOOLLLOOOGGGÍÍÍAAA 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. La automatización de servicios juega en la actualidad un papel esencial en la prestación de servicios TI. 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

• 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. La gran capacidad de cálculo de los sistemas informáticos permite analizar 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.

La tecnología también nos ofrece útiles herramientas para simular y modelatan complejos como el que nos ocupa pueden resultar a veces en comportamientos inesperados e incluso contrarios a nuestra intuición. El modelado analítico y las simulaciones pueden, por ejemplo, ayudar a optimizatrabajo de nuestro Centro de Servicios.

Manual Técnico

Tratándose de la Gestión de Servicios TI es evidente que la tecnología debe jugar un papel importante en todo lo que

ios juega en la actualidad un papel esencial en la prestación de servicios TI. Aunque las infraestructuras informáticas presentes puedan carecer de la flexibilidad y capacidad de adaptación de los equipos humanos es evidente que proporcionan:

calidad consistentes

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

Pero la automatización de servicios no es el único terreno en el que la tecnología puede jugar un papel importante en la

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

La tecnología también nos ofrece útiles herramientas para simular y modelar la dinámica de la organización. Sistemas tan complejos como el que nos ocupa pueden resultar a veces en comportamientos inesperados e incluso contrarios a

El modelado analítico y las simulaciones pueden, por ejemplo, ayudar a optimizar la estructura y flujos de información y

Pág. 46/321

Tratándose de la Gestión de Servicios TI es evidente que la tecnología debe jugar un papel importante en todo lo que

ios juega en la actualidad un papel esencial en la prestación de servicios TI. Aunque las infraestructuras informáticas presentes puedan carecer de la flexibilidad y capacidad de adaptación de los equipos

El conocimiento recopilado durante la prestación del servicio es un activo que reside en la organización y no en

Pero la automatización de servicios no es el único terreno en el que la tecnología puede jugar un papel importante en la

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

r la dinámica de la organización. Sistemas tan complejos como el que nos ocupa pueden resultar a veces en comportamientos inesperados e incluso contrarios a

r la estructura y flujos de información y


Pág. 47/321

EEESSSTTTRRRAAATTTEEEGGGIIIAAASSS DDDEEE EEEXXXTTTEEERRRNNNAAALLLIIIZZZAAACCCIIIÓÓÓNNN DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 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 externalización dependerá de múltiples factores entre los que se cuentan.

• 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 o Tipo II: encargadas a unidades de servicios compartidos que prestan sus servicios a las diferentes

unidades de negocio pertenecientes a una misma corporación

• Contratación externa (Tipo III) o Tradicional: un solo proveedor de servicios se encarga de la prestación del servicio en cuestión o Múltiple:

� 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 sectores 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.


Pág. 48/321

FFFAAACCCTTTOOORRREEESSS DDDEEE ÉÉÉXXXIIITTTOOO YYY RRRIIIEEESSSGGGOOOSSS 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 riesgos están naturalmente asociados a incertidumbres y aunque en general tengan un carácter negativo en ocasiones pueden resultar en oportunidades de negocio. 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. 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 principales riesgos que afronta un proveedor de servicios se resumen en:

• Riesgos de contratación debidos a la imposibilidad de cumplir los contratos con los niveles de servicio acordados. 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 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.

• Riesgos operativos comunes a todas las organizaciones. • Riesgos de mercado debidos a una pobre diferenciación de los servicios ofrecidos o a una mala gestión de la

cartera de servicios. En lo que respecta específicamente a la fase de la Estrategia del Servicio los principales retos, 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. La formación y la comunicación continua deben formar parte integrante de la fase de Estrategia.

• Coordinación: las redes de valor no aportarán valor a los servicios si sus aportaciones no están adecuadamente coordinadas. 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.

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

Medición del rendimiento: si no lo puedes medir no lo puedes gestionar (Principio de Deming). Se deben establecer métricas para:

• El cumplimiento de los objetivos estratégicos • La calidad de los servicios

• La calidad de los procesos

• El rendimiento de la organización • Tiempos de respuesta

• Valoraciones realistas de los costes del servicio 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.


Pág. 49/321

RRREEELLLAAACCCIIIÓÓÓNNN CCCOOONNN OOOTTTRRROOOSSS CCCIIICCCLLLOOOSSS 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. Esto es algo que es particularmente cierto para la Estrategia del Servicio pues ésta debe de servir de guía al diseño, transición, operación y mejora continua del servicio. A continuación resumimos las principales interdependencias:

1. 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. 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. 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. 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. Por otro lado la Transición del Servicio debe colaborar, en aquello que le corresponde, a dar soporte a la perspectiva y posicionamiento del servicio establecidos en la fase de estrategia.

3. ESTRATEGIA Y OPERACIÓN La fase de operación es la más importante desde el punto de vista del cliente, 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. Por lo tanto un factor esencial en el enfoque estratégico de los servicios es asegurar que son operacionalmente viables. Recíprocamente, 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.

4. ESTRATEGIA Y MEJORA CONTINUA En un mundo en constante desarrollo tecnológico las estrategias no deben ser inamovibles. La estrategia debe ser continuamente rediseñada atendiendo a múltiples factores. La Mejora del Servicio debe ofrecer información a la fase de Estrategia sobre aspectos que pueden ser optimizados, tales como calidad y rendimiento, pero esto siempre debe hacerse partiendo de la perspectiva de negocio establecida durante la fase de estrategia.


Pág. 50/321


Pág. 51/321


Pág. 52/321

DDDIIISSSEEEÑÑÑOOO DDDEEE LLLOOOSSS SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII 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. 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.

• Sean eficientes en costes y rentables.

• Cumplan los estándares de calidad adoptados. • Aporten valor a clientes y usuarios.

El Diseño del Servicio debe tener en cuenta tanto los requisitos del servicio como los recursos y capacidades disponibles en la organización TI. Un desequilibrio entre ambos lados de la balanza puede resultar en servicios donde se vean comprometidas bien la funcionalidad o bien la garantía. 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. Una correcta implementación del Diseño del Servicio debe ayudar a responder cuestiones tales como:

• ¿Cuáles son los requisitos y necesidades de nuestros clientes? • ¿Cuáles son los recursos y capacidades necesarias para prestar los servicios propuestos?

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

• ¿Son necesarias nuevas inversiones para prestar los servicios con los niveles de calidad propuestos? • ¿Están todos los agentes involucrados correctamente informados sobre los objetivos y alcance de los nuevos

servicios o de las modificaciones a realizar en los ya existentes?

••• ¿Se necesita la colaboración de proveedores externos?


Pág. 53/321

PPPRRRIIINNNCCCIIIPPPIIIOOOSSS DDDEEELLL DDDIIISSSEEEÑÑÑOOO DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS ITIL contempla cinco aspectos esenciales en el Diseño del Servicio:

1. DISEÑO DE SOLUCIONES DE SERVICIO Debe incluir de forma estructurada todos los elementos clave del nuevo o modificado servicio:

• Requisitos de negocio

• Requisitos de servicio (SLR)

• Adecuación a la estrategia del servicio • Análisis funcional

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

• Análisis de costes (TCO) y retorno a la inversión • Estudio de los recursos y capacidades involucradas

• Estrategias de contratación con los proveedores externos (si estos se consideraran necesarios)

2. DISEÑO DEL PORTFOLIO DE SERVICIOS El Portfolio de Servicios es una de las principales herramientas para la gestión del servicio a través de todas las fases del ciclo de vida. Debe incluir información sobre todos los servicios ofrecidos, los servicios en fase de desarrollo y los servicios retirados en términos de valor para el negocio. La fase de Diseño del Servicio es responsable de determinar su contenido específico así como sus permisos de acceso. El Portfolio de Servicios debe contener información sobre:

• Los objetivos del servicio

• Su valor: funcionalidad y garantía • Su estado

• Los SLAs asociados

• Capacidades y recursos utilizados • Sus costes y retorno esperado

• Los controles o métricas de calidad asociados

• Los responsables del mismo • Servicios relacionados

• Proveedores externos involucrados (OLAs y UCs) Y toda aquella otra información que se pueda considerar de interés referente a la prestación del servicio.

3. DISEÑO DE LA ARQUITECTURA DEL SERVICIO

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

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

• La infraestructura TI necesaria.

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

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

• Los Planes de Despliegue del servicio.

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


Pág. 54/321

En particular deben establecerse los procesos de control para asegurar que los procesos se realizan de forma eficiente y cumplen los objetivos establecidos. Los procesos no deben ser un fin en sí mismo sino que deben tener como principal objetivo que la organización TI ofrezca servicios de valor al cliente de forma eficiente.

5. DISEÑO DE MÉTRICAS Y SISTEMAS DE MONITORIZACIÓN

Es imprescindible diseñar sistemas de medición y seguimiento que permitan evaluar tanto la calidad de los servicios prestados como la eficiencia de los procesos involucrados. Los resultados recopilados mediante estos sistemas de seguimiento y su análisis posterior, basado en métricas y métodos preestablecidos, deben de ser la principal entrada para la fase de Mejora del Servicio. Existen cuatro tipos principales de métricas a considerar:

• Progreso: cumplimiento de los calendarios previstos

• Cumplimiento: adecuación a las políticas y requisitos predefinidos. • Eficacia: calidad de los resultados obtenidos.

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


Pág. 55/321

MMMOOODDDEEELLLOOOSSS DDDEEE DDDIIISSSEEEÑÑÑOOO La opción del modelo de desarrollo del servicio puede ser determinante para el éxito o fracaso del mismo. Existen tres opciones principales, Tradicional, Ágil y Empaquetado que describimos brevemente a continuación.

1. Modelo tradicional Presupone una mayor estabilidad del servicio. El servicio requiere de un detallado estudio previo de todos los aspectos técnicos y de negocio que evite, en la medida de lo posible, la necesidad de cambios, ya sea por errores o por una funcionalidad incompleta. 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. El servicio o producto puede ser técnica y funcionalmente estable pero resultar obsoleto antes de su entrada en producción.

2. 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. 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. • 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.

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

3. Soluciones empaquetadas Existen en la actualidad muchas soluciones TI empaquetadas que simplifican el proceso de diseño del servicio. Sus ventajas se resumen en:

• Disponible rápidamente.

• Configurable. • Costes (iniciales) reducidos.

• Actualizaciones periódicas. Sus principales inconvenientes suelen residir en:

• Dificultades de integración con otros servicios/plataformas.

• Insuficiente funcionalidad debida a necesidades muy específicas.

• Potenciales altos costes de personalización y posibles incompatibilidades con las actualizaciones. 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.


Pág. 56/321

• Cuestiones financieras. • Requisitos del cliente.

• Generación de valor.

• Condiciones del mercado. • Perspectivas de negocio.

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, estatus, proveedores, etcétera. Gestión de Niveles de Servicio: responsable de acordar y garantizar los niveles de calidad de los servicios TI prestados. Gestión de la Capacidad: responsable de garantizar que la organización TI dispone de la capacidad suficiente para prestar los servicios acordados. Gestión de la Disponibilidad: responsable de garantizar que se cumplen los niveles de disponibilidad acordados en los SLA. Gestión de la Continuidad de los Servicios TI: responsable de establecer planes de contingencia que aseguren la continuidad del servicio en un tiempo predeterminado con el menor impacto posible en los servicios de carácter crítico. Gestión de la Seguridad de la Información: responsable de establecer las políticas de integridad, confidencialidad y disponibilidad de la información. Gestión de Proveedores: responsable de la relación con los proveedores y el cumplimiento de los UCs.

ITIL V.3

GGGEEESSSTTTIIIÓÓÓNNN DDDEEELLL CCCAAATTTÁÁÁLLLOOOGGGOOO DDDEEE

Visión general El Portfolio de Servicios, tal y como hemos visto, proporciona una referencia estratégica y técnica clave dentro deorganización TI, ofreciendo una descripción detallada de todos los servicios que se prestan y los recursos asignados para ello. El Catálogo de Servicios cumple exactamente la misma función, pero de cara al exterior. La existencia de dos documentos tan similares se explica porque el Portfolio de Servicios, al ser de carácter interno, no sólo contiene información sobre el funcionamiento de la organización que no interesa a los clientes, sino que está además escrito en un lenguaje demasiado técnico que no Además, el Portfolio de Servicios incluye información sobre todos los servicios que alguna vez ha prestado, presta o prestará la organización, mientras que el Catálogo prescinde de aquellos retirados opueden interesar a los clientes. La elaboración de este Catálogo de Servicios puede resultar una tarea compleja, pues es necesario alinear aspectos técnicos con políticas de negocio. Sin embargo, es un documento imprescin

• Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades.

• Delimita las funciones y compromisos de la organización TI.• Puede ser utilizado como herramienta de venta.

• Evita malentendidos entre los di Las interacciones y funcionalidades del Catálogo de Servicios se resumen sucintamente en el siguiente interactivo:

Manual Técnico

EE SSSEEERRRVVVIIICCCIIIOOOSSS

El Portfolio de Servicios, tal y como hemos visto, proporciona una referencia estratégica y técnica clave dentro deorganización TI, ofreciendo una descripción detallada de todos los servicios que se prestan y los recursos asignados para ello. El Catálogo de Servicios cumple exactamente la misma función, pero de cara al exterior.

similares se explica porque el Portfolio de Servicios, al ser de carácter interno, no sólo contiene información sobre el funcionamiento de la organización que no interesa a los clientes, sino que está además escrito en un lenguaje demasiado técnico que no es adecuado ni eficaz para la comunicación externa.

Además, el Portfolio de Servicios incluye información sobre todos los servicios que alguna vez ha prestado, presta o prestará la organización, mientras que el Catálogo prescinde de aquellos retirados o inactivos y se centra en los que

La elaboración de este Catálogo de Servicios puede resultar una tarea compleja, pues es necesario alinear aspectos técnicos con políticas de negocio. Sin embargo, 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.

Delimita las funciones y compromisos de la organización TI. Puede ser utilizado como herramienta de venta.

Evita malentendidos entre los diferentes actores implicados en la prestación de servicios.

Las interacciones y funcionalidades del Catálogo de Servicios se resumen sucintamente en el siguiente interactivo:

Pág. 57/321

El Portfolio de Servicios, tal y como hemos visto, proporciona una referencia estratégica y técnica clave dentro de la organización TI, ofreciendo una descripción detallada de todos los servicios que se prestan y los recursos asignados

similares se explica porque el Portfolio de Servicios, al ser de carácter interno, no sólo contiene información sobre el funcionamiento de la organización que no interesa a los clientes, sino que está

es adecuado ni eficaz para la comunicación externa.

Además, el Portfolio de Servicios incluye información sobre todos los servicios que alguna vez ha prestado, presta o inactivos y se centra en los que

La elaboración de este Catálogo de Servicios puede resultar una tarea compleja, pues es necesario alinear aspectos

Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades.

Las interacciones y funcionalidades del Catálogo de Servicios se resumen sucintamente en el siguiente interactivo:


Pág. 58/321

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. Para cumplir ese cometido, el Catálogo de Servicios debe:

• Describir los servicios ofrecidos de manera comprensible para personal no especializado, poniendo especial cuidado en evitar el lenguaje técnico.

• Ser utilizado como guía para orientar y dirigir a los clientes.

• Incluir, en líneas generales, 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, así como las responsabilidades asociadas a cada uno de éstos.

• Registrar los clientes actuales de cada servicio.

• Encontrarse a disposición del Centro de Servicios y de todo el personal que se halle en contacto directo con los clientes.

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, plazos e hitos y entregables contratados para el servicio), se evitan malentendidos y abusos por ambas partes.

• Al estar mejor informado sobre los recursos asociados a la prestación de un servicio, el cliente puede comprender de manera más precisa los costes asociados al mismo. Esto ayuda a incrementar su confianza hacia la organización, algo crucial a la hora de renovar o ampliar el contrato de prestación servicios.

• Al poner por escrito los responsables de cada servicio, se evitan situaciones de “vacío de poder” en las que el cliente no sabe a quién acudir.

Por otro lado, las principales dificultades que pueden surgir en relación al Catálogo de Servicios son:

• No está claro, bien dentro de la organización, bien en el Portfolio, qué servicios están en activo y cuáles han sido retirados definitivamente.

• No ha arraigado entre el personal la costumbre de consultar el Catálogo a la hora de recabar información sobre un servicio. Esto es especialmente crítico si es el Centro de Servicios el que no hace uso de él, ya que es el principal encargado del trato con los clientes.

• El Catálogo de Servicios, pese a los esfuerzos iniciales, contiene jerga técnica o alude a conceptos demasiado especializados.

• 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 no se actualiza con suficiente frecuencia, por lo que en la práctica resulta ineficaz.

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). De este modo, la información contenida en ellos puede ser utilizada por otras herramientas de gestión. El Catálogo de Servicios de Negocio 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, las relaciones entre unidades de negocio, etc. El Catálogo de Servicios Técnico


Pág. 59/321

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, servicios compartidos, componentes, elementos de configuración, etc. Esta parte del catálogo tan sólo está disponible para la organización: los clientes no pueden consultarla.

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, 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: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 60/321

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.


Pág. 61/321

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.


Pág. 62/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE NNNIIIVVVEEELLLEEESSS DDDEEE SSSEEERRRVVVIIICCCIIIOOO

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. Nota: Las interacciones y funcionalidades de la Gestión de Niveles de Servicio se resumen sucintamente en el siguiente interactivo:

ITIL V.3

IInnttrroodduucccciióónn yy OObbjjeettiivvooss

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 nec

expectativas del cliente y los costes de los servicios asociados, de forma que estos sean asumibles tanto por el cliente

La Gestión de Niveles de Servicio debe:

• Documentar todos los servicios TI ofrecidos.

• Presentar los servicios de forma comprensible para el cliente.• Centrarse en el cliente y su negocio y no en la tecnología.

• Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades.

Manual Técnico

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

La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necexpectativas 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.

ar los servicios de forma comprensible para el cliente. Centrarse en el cliente y su negocio y no en la tecnología.

Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades.

Pág. 63/321

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

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

Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades.


Pág. 64/321

• Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los servicios requeridos. (SLAs) • Establecer los indicadores claves de rendimiento del servicio TI.

• Monitorizar la calidad de los servicios acordados con el objetivo último de mejorarlos a un coste aceptable por el cliente.

• Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del Servicio (SIP). Los principales beneficios de una correcta Gestión de Niveles de Servicio son:

• Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente.

• Se facilita la comunicación con los clientes, impidiendo los malentendidos sobre las características y calidad de los servicios ofrecidos.

• Se establecen objetivos claros y cuantificables. • Se establecen claramente las responsabilidades tanto de los clientes como de los proveedores del servicio.

• Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos de actuación en caso de deterioro del servicio.

• La constante monitorización del servicio permite detectar los "eslabones más débiles de la cadena" para su mejora.

• La gestión TI conoce y comprende los servicios ofrecidos, lo que facilita los acuerdos con proveedores y subcontratistas.

• El personal del Centro de Servicios dispone de la documentación necesaria (SLAs, OLAs,etc.) para llevar una relación fluida con clientes y proveedores.

• Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante los clientes.

Estos beneficios repercuten, a la larga, en una mejora del servicio con la consecuente satisfacción de clientes y usuarios. Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en:

• No existe una buena comunicación con clientes y usuarios, por lo que los SLAs acordados no recogen sus necesidades reales.

• Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente.

• No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente.

• Los SLAs son excesivamente prolijos y técnicos, incumpliendo así sus objetivos primordiales.

• No se dedican los recursos suficientes, pues la dirección los considera como un gasto añadido y no como parte integral del servicio ofrecido.

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

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

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

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 OLAs correspondientes. Hojas de Especificación Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.


Pág. 65/321

Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de determinados procesos, sirviendo de documento de base para la elaboración de los OLAs y UCs correspondientes. 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. • Estimación de recursos.

• Indicadores clave de rendimiento.

• Procedimientos de monitorización de proveedores. En resumen, el SQP debe contener la información necesaria para que la organización TI conozca los procesos y procedimientos involucrados en el suministro de los servicios prestados, asegurando que estos se alineen con los procesos de negocio y mantengan unos niveles de calidad adecuados. Acuerdo de Nivel de Servicio (SLA) El SLA debe recoger en un lenguaje no técnico, o cuando menos comprensible para el cliente, todos los detalles de los servicios brindados. Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc. Acuerdo de Nivel de Operación (OLA) El 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. 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. 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. 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.

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

• Planificación: o Asignación de recursos. o Elaboración de un catálogo de servicios. o Desarrollo de SLAs tipo. o Herramientas para la monitorización de la calidad del servicio. o Análisis e identificación de las necesidades del cliente. o Elaboración del los Requisitos de Nivel de servicio (SLR), Hojas de Especificación del Servicio y Plan de

Calidad del Servicio (SQP).


Pág. 66/321

• Implementación de los Acuerdos de Niveles de Servicio: o Negociación. o Acuerdos de Nivel de Operación. o Contratos de Soporte.

• •Supervisión y revisión de los Acuerdos de Nivel de Servicio: o Elaboración de informes de rendimiento. o Control de los proveedores externos. o Elaboración de Programas de Mejora del Servicio (SIP).


Planificación de la Gestión

La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los estamentos de la organización TI. Y, si esto no fuera ya de por sí una labor lo suficientemente compleja, resulta imprescindible la colaboración activa de los clientes y usuarios de los servicios TI.


Pág. 67/321

El objetivo primordial de la Gestión de Niveles de Servicio es definir, negociar y monitorizar la calidad de los servicios TI ofrecidos. Si los servicios no se adecuan a las necesidades del cliente, la calidad de los mismos es deficiente o sus costes son desproporcionados, tendremos clientes insatisfechos y la organización TI será responsable de las consecuencias que se deriven de ello. Todo el proceso de planificación previo debe estar orientado a dar respuesta a las siguientes preguntas:

o ¿Qué servicios debemos ofrecer a nuestros clientes? o ¿Cuáles son las necesidades de nuestros clientes? o ¿Cuál es el nivel adecuado de calidad de servicio? o ¿Quiénes y cómo se van a suministrar esos servicios? o ¿Cuáles serán los indicadores clave de rendimiento para los servicios prestados? o ¿Disponemos de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad

acordados? La respuesta a cada una de estas preguntas debe darse en forma de documentos, algunos de carácter interno y otros accesibles a los clientes, que pasamos a describir sucintamente a continuación. Los resultados de esta interacción/negociación deben ser incorporados al documento de Requisitos de Nivel de Servicio (SLR), que debe reflejar las necesidades del cliente y sus expectativas respecto a:

• La funcionalidad y características del servicio.

• La disponibilidad del servicio.

• La interacción del servicio con su infraestructura TI o de otro tipo. • La continuidad del servicio.

• Los niveles de calidad del servicio.

• Tiempo y procedimientos de implantación del servicio. • La escalabilidad del servicio ofrecido.

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

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

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

• Cómo se implementará el servicio. Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su infraestructura, esta información deberá reflejarse en una Hoja de Especificaciones "externa" que habrá de acordarse con el cliente y sus responsables técnicos. El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios. En función de los requisitos plasmados en las Hojas de Especificación del Servicio, se elabora un plan global que permita asignar los recursos a la organización TI, establecer metas claras basadas en los indicadores de rendimiento elegidos y asegurar que los niveles de calidad ofrecidos se adaptan a las necesidades de los clientes y a los compromisos asumidos por la organización. En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportuno externalizar parte de los servicios, el SQP servirá de documento guía para el establecimiento de los contratos con los proveedores externos.


Pág. 68/321

Implementación

La fase de planificación debe concluir con la elaboración y aceptación de los acuerdos necesarios para la prestación del servicio. Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de Operación y Contratos de Soporte. Acuerdos de Nivel de Servicio Los Acuerdos de Nivel de Servicio (SLAs) deben contener una descripción del servicio que abarque desde los aspectos más generales hasta los detalles más específicos del servicio. Es conveniente estructurar los SLAs más complejos en diversos documentos, de forma que cada grupo involucrado reciba exclusivamente la información correspondiente al nivel en que se integra, ya sea en el lado del cliente o en el del proveedor. La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos entre los que se encuentran:

• La naturaleza del negocio del cliente.

• Aspectos organizativos del proveedor y cliente. • Aspectos culturales locales.

Acuerdos de Nivel de Operación Los 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. El OLA, por su naturaleza, involucra detalles sobre la prestación del servicio que deben ser opacos para el cliente pero que resultan imprescindibles a la organización TI para desarrollar y coordinar su labor. Contratos de Soporte Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de prestación de servicios. Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los Contratos de Soporte deben representar compromisos claros y perfectamente delimitados. A pesar de esta diferencia crucial, los UCs pueden considerarse como una extensión "externa" de los OLAs, en el sentido de que persiguen el mismo fin: organizar los procesos y procedimientos necesarios para la correcta provisión del servicio. 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, su rentabilidad y la satisfacción de los clientes y usuarios. La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la organización como los relacionados con la percepción de los usuarios. Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con anterioridad unos baremos de calidad del servicio que han de servir de guía en la elaboración de los informes correspondientes. Las principales fuentes de información las constituyen:

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

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

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


Pág. 69/321

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

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

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

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

• Utilización de la capacidad predefinida. • Disponibilidad del servicio.

• Tiempos de respuesta.

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

• Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OLAs. 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. 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, elaborar un Programa Mejora del Servicio (SIP). Esta función entronca con la última fase del ciclo de vida, la de Mejora Continua del Servicio. 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, pero esto no se puede llevar a cabo sin una buena gestión de los procesos involucrados. Es esencial disponer de:

• Unos objetivos claros y contrastables.

• Un equipo con experiencia liderado por un Gestor del Nivel de Servicio con la cualificación y experiencia necesarios.

• Una asignación clara de tareas y responsabilidades. Indicadores específicos de rendimiento tales como:

� Porcentaje de servicios amparados bajo SLAs. � Porcentaje de incumplimiento de los SLAs clasificados por su impacto en la calidad del servicio. � SIPs elaborados e impacto de los mismos en la calidad del servicio. � Encuestas de satisfacción del cliente.

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. Entre la documentación generada cabría destacar:

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

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

• Planes de Mejora (SIP): donde se especifiquen las acciones propuestas para la mejora del servicio TI y el impacto que estas han tenido en la calidad del servicio.


Pág. 70/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA CCCAAAPPPAAACCCIIIDDDAAADDD

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. Sin una correcta Gestión de la Capacidad, los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son insuficientes con la consecuente degradación de la calidad del servicio. Entre las responsabilidades de la Gestión de la Capacidad se encuentran:

• Asegurar que se cubren las necesidades de capacidad TI tanto presentes como futuras.

• Controlar el rendimiento de la infraestructura TI.

• Desarrollar planes de capacidad asociados a los niveles de servicio acordados. • Gestionar y racionalizar la demanda de servicios TI.


Pág. 71/321

Introducción y Objetivos

El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes, usuarios y del propio departamento TI los recursos informáticos necesarios para desempeñar de una manera eficiente sus tareas y todo ello sin incurrir en costes desproporcionados. Para ello, la Gestión de la Capacidad debe:

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

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

• Analizar el rendimiento de la infraestructura para monitorizar el uso de la capacidad existente. • Realizar modelos y simulaciones de capacidad para diferentes escenarios futuros previsibles.

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

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


Pág. 72/321

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, o por el contrario, evitar situaciones en las que la productividad se ve mermada por un insuficiente o deficiente uso de las tecnologías existentes. Ambos escenarios son habituales y a menudo se pueden encontrar conviviendo en una misma organización: directivos, clientes e informáticos deslumbrados por tecnologías que realmente no necesitan y adquieren pero que obvian aplicaciones, equipos y servicios que realmente aumentarían la productividad en sus respectivos entornos de trabajo. Una de las principales tareas de la Gestión de la Capacidad es la de matizar la percepción de que la "capacidad es barata". Aunque el aumento de la capacidad puede requerir, en primera instancia, de modestos desembolsos, debido a la reducción de costes en los equipos de hardware y aplicaciones informáticas, la administración y mantenimiento de infraestructuras desproporcionadas puede resultar, a la larga, muy cara. Los principales beneficios derivados de una correcta Gestión de la Capacidad son:

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

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

• Se evitan gastos innecesarios producidos por compras de "última hora". • Se planifica el crecimiento de la infraestructura adecuándolo a las necesidades reales de negocio.

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

• Se reducen posibles incompatibilidades y fallos en la infraestructura informática. En resumen: se racionaliza la gestión de las compras y mantenimiento de los servicios TI con la consiguiente reducción de costes e incremento en el rendimiento. La implementación de una adecuada política de Gestión de la Capacidad también se encuentra con algunas serias dificultades:

• Información insuficiente para una planificación realista de la capacidad.

• Expectativas injustificadas sobre el ahorro de costes y mejoras del rendimiento. • Insuficiencia de recursos para la correcta monitorización del rendimiento.

• Infraestructuras informáticas distribuidas y excesivamente complejas en las que es difícil un correcto acceso a los datos.

• No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados. • La rápida evolución de las tecnologías puede obligar a una revisión permanente de los planes y escenarios

contemplados.

• Un correcto 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.

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.

• Monitorización de los recursos de la infraestructura TI. • 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 proceso de Gestión de la Capacidad puede segmentarse en subprocesos que analizan las necesidades de capacidad TI desde diferentes puntos de vista:

ITIL V.3

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

• Gestión de la Capacidad del Servicio (SCM, del inglés Service Capacity Management): qurendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados.

• Gestión de la Capacidad de Recursos (CCM, del inglés Component Capacity Management): que estudia tanto el uso de la infraestructura TI como sus tque estos se utilizan eficazmente.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de la Capacidad: Nota: los botones del gráfico permiten acceder a informac

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.

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

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

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

Manual Técnico

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

Gestión de la Capacidad del Servicio (SCM, del inglés Service Capacity Management): qurendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados.

Gestión de la Capacidad de Recursos (CCM, del inglés Component Capacity Management): que estudia tanto el uso de la infraestructura TI como sus tendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizan eficazmente.

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

Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.

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

tiva a la capacidad de la infraestructura TI.

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

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

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

Pág. 73/321

Gestión de la Capacidad del Negocio (BCM, del inglés Business Capacity Management): que centra su objeto

Gestión de la Capacidad del Servicio (SCM, del inglés Service Capacity Management): que analiza el rendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados.

Gestión de la Capacidad de Recursos (CCM, del inglés Component Capacity Management): que estudia tanto endencias para asegurar que se dispone de los recursos suficientes y

ión mas detallada sobre la interrelación con otros procesos TI.

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

Los cambios necesarios para adaptar la capacidad TI a las novedades tecnológicas y las necesidades

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


Pág. 74/321

Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o bianual es importante que se monitorice su cumplimiento para adoptar medidas correctivas en cuanto se detecten desviaciones importantes del mismo. Modelado y Benchmarking Cuanto más compleja sea una infraestructura informática más difícil es prever las necesidades de capacidad futura. En esos casos, es imprescindible realizar modelos y simulaciones sobre posibles escenarios de desarrollo futuro que aseguren la correcta escalabilidad de las aplicaciones y hardware. El nivel de detalle al que se lleve este modelado dependerá de varios factores:

• Costes asociados al incremento de la capacidad. • Costes inherentes al proceso mismo de modelado y simulación.

• Alcance de los incrementos de capacidad previstos.

• La "criticalidad" de los sistemas implicados. Sopesando los anteriores factores podemos optar por:

• Un simple análisis de tendencias que permita evaluar la carga de proceso esperada en la infraestructura informática y escalar consecuentemente su capacidad actual.

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

• Realizar benchmarks (pruebas de rendimiento comparativas) con prototipos reales para asegurar la capacidad y el rendimiento de la futura infraestructura.

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, software y personal a cada servicio y aplicación. El correcto dimensionamiento requiere que la Gestión de la Capacidad disponga de información fiable sobre:

• Los niveles de servicio acordados y/o previstos (SLAs).

• Niveles de rendimiento esperados.

• Impacto de la aplicación o servicio en los procesos de negocio del cliente. • Márgenes de seguridad y disponibilidad.

• Informes de monitorización de los niveles de servicio.

• Costes asociados a los equipos de hardware y otros recursos TI necesarios. En la fase de diseño de un servicio, la Gestión de la Capacidad asegura que se dispondrá de la capacidad necesaria para llevar el proyecto a buen término. Una vez se ha puesto en marcha el servicio, también es la encargada de analizar las tendencias de uso y prever las necesidades futuras. Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicación debido a expectativas injustificadas sobre la tecnología. Se puede caer en el equívoco de que los costes asociados a la capacidad se limitan a la compra de más servidores, o más espacio de almacenamiento, etcétera, olvidando que sistemas más complejos implican unos mayores gastos de mantenimiento y administración, o ignorando los problemas que pueden conllevar dichos cambios.

Supervisión de la Capacidad

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


Pág. 75/321

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

Monitorización Su objetivo principal es asegurar que el rendimiento de la infraestructura informática se adecua a los requisitos de los SLAs. La monitorización debe incluir, además de aspectos técnicos, todos aquellos relativos a licencias y otras cuestiones de carácter administrativo. Análisis y Evaluación Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas tales como petición de aumento de la capacidad o una mejor Gestión de la Demanda. Optimización y cambios Si se ha optado por solicitar un aumento de la capacidad, se elevará una petición de cambio (RFC) a la Gestión de Cambios para que se desencadene todo el proceso necesario para la implementación del cambio. La Gestión de la Capacidad prestará su apoyo en todo el proceso y será corresponsable, junto a la Gestión de Cambios y Versiones, de asegurar que el cambio solicitado cumpla los objetivos previstos. En el caso de que una simple racionalización de la demanda sea suficiente para solventar las posibles deficiencias o incumplimientos de los SLAs, será la propia Gestión de la Capacidad la responsable de gestionar ese subproceso. Base de Datos de la Capacidad La Base de Datos de la Capacidad (CDB) debe cubrir toda la información de negocio, financiera, técnica y de servicio que reciba y genere la Gestión de la Capacidad relativas a la capacidad de la infraestructura y sus elementos.


Pág. 76/321

Idealmente la CDB debe estar interrelacionada con la CMDB para que esta última ofrezca una imagen integral de los sistemas y aplicaciones con información relativa a su capacidad. Esto no es óbice para que ambas bases de datos puedan ser "físicamente independientes".

Control del proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Capacidad. La documentación elaborada debe incluir información sobre:

• El uso de recursos.

• Desviaciones de la capacidad real sobre la planificada.

• Análisis de tendencias en el uso de la capacidad. • Métricas establecidas para el análisis de la capacidad y monitorización del rendimiento.

• Impacto en la calidad del servicio, disponibilidad y otros procesos TI. El éxito de la Gestión de la Capacidad depende de algunos indicadores clave, entre los que se encuentran:

• Correcta previsión de las necesidades de capacidad. • Reducción de los costes asociados a la capacidad.

• Más altos niveles de disponibilidad y seguridad. • Mayor satisfacción de los usuarios y clientes.

• Cumplimiento de los SLAs.


Pág. 77/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA DDDIIISSSPPPOOONNNIIIBBBIIILLLIIIDDDAAADDD

Visión general Nuestras vidas, tanto personales como profesionales, dependen cada vez más de la tecnología. Ésta nos permite acceder a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñado hace unos pocos años. Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestros proveedores tecnológicos. Con frecuencia una oferta diferente sólo se encuentra a un par de clics de distancia. Por otro lado, el rápido desarrollo tecnológico implica una constante renovación de equipos y servicios. Como proveedores 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. La Gestión de la Disponibilidad es responsable de optimizar y monitorizar los servicios TI para que estos funcionen ininterrumpidamente y de manera fiable, cumpliendo los SLAs y todo ello a un coste razonable. La satisfacción del cliente y la rentabilidad de los servicios TI dependen en gran medida de su éxito. Las interacciones y funciones de la Gestión de la Disponibilidad se resumen sucintamente en el siguiente interactivo:


Pág. 78/321

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. Las responsabilidades de la Gestión de la Disponibilidad incluyen:

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

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

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

• Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores internos y externos. Los indicadores clave sobre los que se sustenta el proceso de Gestión de la Disponibilidad se resumen en:

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

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

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

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

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


Pág. 79/321

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

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

• El cliente percibe una mayor calidad de servicio.

• Se aumentan progresivamente los niveles de disponibilidad. • Se reduce el número de incidentes.

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

• No se monitoriza correctamente la disponibilidad real del servicio.

• No existe compromiso con el proceso dentro de la organización TI. • No se dispone de las herramientas de software y personal adecuado.

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

• Falta de coordinación con los otros procesos. • Los proveedores internos y externos no reconocen la autoridad del Gestor de la Disponibilidad por falta de

apoyo de la dirección.

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

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

• Desarrollar un plan de disponibilidad donde se estimen las futuras a corto y medio plazo.

• Mantenimiento del servicio en operación y recuperación del mismo en caso de fallo. • Realizar diagnósticos periódicos sobre la disponibilidad de los sistemas y servicios.

• Evaluar la capacidad de servicio de los proveedores internos y externos.

• Monitorizar la disponibilidad de los servicios TI. • Elaborar informes de seguimiento con la información recopilada sobre disponibilidad, fiabilidad, capacidad de

mantenimiento y cumplimiento de OLAs y UCs.

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

• Asesorar a la Gestión de Cambios sobre el posible impacto de un cambio en la disponibilidad. Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 80/321

Requisitos de disponibilidad

Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de los SLAs. La disponibilidad propuesta debe encontrase en línea tanto con las necesidades reales del negocio como con las posibilidades de la organización TI. Aunque en principio todos los clientes estarán de acuerdo con unas elevadas cotas de disponibilidad es importante hacerles ver que una alta disponibilidad puede generar unos costes injustificados dadas sus necesidades reales. Quizá unas pocas horas sin un determinado servicio pueden representar poco más allá de una pequeña inconveniencia mientras que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la replicación de sistemas u otras medidas igualmente costosas que no van a tener una repercusión real en la rentabilidad del negocio. Para llevar a cabo eficientemente esta tarea es necesario que la Gestión de la Disponibilidad:

• Identifique las actividades clave del negocio.

• Cuantifique los intervalos razonables de interrupción de los diferentes servicios dependiendo de sus respectivos impactos.

• Establezca los protocolos de mantenimiento y revisión de los servicios TI.

• Determine las franjas horarias de disponibilidad de los servicios TI (24/7, 12/5, ...).

Planificación 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. El documento que debe recoger los objetivos de disponibilidad presentes y futuros y qué medidas son necesarias para su cumplimiento es el Plan de Disponibilidad. Este plan debe recoger:

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

• Herramientas para la monitorización de la disponibilidad. • Métodos y técnicas de análisis a utilizar.

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

• Planes de mejora de la disponibilidad. • Expectativas futuras de disponibilidad.

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, claro está). Para que este plan sea realista, debe contar con la colaboración de los otros procesos TI involucrados.

Diseño para la Disponibilidad

Es crucial para una correcta Gestión de la Disponibilidad participar desde el inicio en el desarrollo de los nuevos servicios TI de forma que éstos cumplan los estándares plasmados en el Plan de Disponibilidad. Un diferente nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados o en las actividades necesarias para suministrar un determinado servicio TI. Si éste se diseña sin tener en cuenta futuras necesidades de disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo, incurriendo en costes adicionales innecesarios.


Pág. 81/321

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, nos habremos de enfrentar a interrupciones del servicio. En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto indeseado sobre los niveles de disponibilidad acordados. Aunque la responsabilidad de restaurar el servicio corresponde a la Gestión de Incidencias y las actividades de recuperación han de ser coordinadas por el Centro de Servicios, la Gestión de la Disponibilidad debe prestar su asesoramiento mediante planes de recuperación que tengan en cuenta:

• Las necesidades de disponibilidad del negocio.

• Las implicaciones del incidente en la infraestructura TI y los procesos necesarios para restaurar el servicio. Gestión de las Interrupciones de Mantenimiento Independientemente de las interrupciones del servicio causadas por incidencias, es habitualmente necesario interrumpir el servicio para realizar labores de mantenimiento y/o actualización. Estas interrupciones programadas pueden afectar a la disponibilidad del servicio y por lo tanto han de ser cuidadosamente planificadas para minimizar su impacto. En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que ello sea posible, deben aprovecharse las franjas horarias de inactividad para realizar las tareas que implican una degradación o interrupción del servicio. Si el servicio es 24/7 y la interrupción es necesaria se debe:

• Consultar con el cliente acerca de la franja horaria en la que la interrupción del servicio afectará menos a sus actividades de negocio.

• Informar con antelación suficiente a todos los agentes implicados. • Incorporar dicha información a los SLAs.

Seguridad Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es una correcta Gestión de la Seguridad. Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del proceso. Es tan importante determinar cuándo el servicio estará disponible como el "quién y cómo" va a utilizarlo. La disponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra.

Monitorización de la disponibilidad La monitorización de la disponibilidad del servicio y la elaboración de los informes correspondientes son dos de las principales actividades de la Gestión de la Disponibilidad. Desde el momento de la interrupción del servicio hasta su restitución o "tiempo de parada" el incidente pasa por distintas fases que deben ser analizadas por separado:

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

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


Pág. 82/321

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

Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida de la interrupción del servicio. El cliente debe conocer estas métricas y dar su conformidad a las mismas para evitar malentendidos. En algunos casos es difícil determinar si el sistema está "caído o en funcionamiento" y la interpretación puede diferir entre proveedores y clientes, por lo tanto, estás métricas deben poder expresarse en términos que el cliente pueda entender. Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y que debe poner a disposición del cliente en los informes de disponibilidad correspondientes incluyen:

• Tiempo Medio de Parada (Downtime o (MTTR): que es el tiempo promedio de duración de una interrupción del servicio, e incluye el tiempo de detección, respuesta y resolución.

• Tiempo Medio entre Fallos (Uptime o MTBF): es el tiempo medio durante el cual el servicio está disponible sin interrupciones.

• Tiempo Medio entre Incidencias (MTBSI): es el tiempo medio transcurrido entre incidentes, que es igual a la suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos. El Tiempo Medio entre Incidentes es una medida de la fiabilidad del sistema.

Métodos y Técnicas

Aunque llevamos hablando ya un buen rato de disponibilidad, aún no hemos aportado un método para cuantificarla. Es habitual definir la disponibilidad en tanto por ciento de la siguiente manera:

donde: AST se corresponde con el tiempo acordado de servicio, DT es el tiempo de interrupción del servicio durante las franjas horarias de disponibilidad acordadas. Por ejemplo, si el servicio es 24/7 y en el último mes el sistema ha estado caído durante 4 horas por tareas de mantenimiento la disponibilidad real del servicio fue:


Pág. 83/321

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, mantenimiento y recuperación, así como elaborar planes de mejora a partir de dichos análisis. 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. Es evidente que este método requiere una CMDB correctamente actualizada. 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. 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, 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 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. Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente, haciendo especial énfasis en aspectos no exclusivamente técnicos ligados directamente a la infraestructura TI.

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. Estos informes deben incluir:

• Técnicas y métodos utilizados para la prevención y el análisis de fallos. • Información estadística sobre:

o Tiempos de detección y respuesta a los fallos. o Tiempos de reparación y recuperación del servicio. o Tiempo medio de servicio entre fallos.

• Disponibilidad real de los diferentes servicios.

• Cumplimiento de los SLAs en todo lo referente a la disponibilidad y fiabilidad del servicio. • Cumplimiento de los OLAs y UCs en todo lo referente a la capacidad de servicio prestada por los proveedores

internos y externos. Para que toda esta información sea fácil y correctamente analizada es imprescindible el establecimiento de métricas precisas que permitan determinar de forma inequívoca parámetros tales como tiempos de parada y funcionamiento. Por


Pág. 84/321

ejemplo, en el caso de un servicio online de comercio electrónico, se puede considerar que tiempos de respuesta superiores a 10 segundos son equivalentes a que el sistema esta caído, aunque estrictamente hablando el sistema termine respondiendo.

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA CCCOOONNNTTTIIINNNUUUIIIDDDAAADDD DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII

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, debido a desastres naturales u otras fuerzas de causa mayor, tenga consecuencias catastróficas para el negocio. La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamente procedimientos:

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

• Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea posible (y recomendable) tras el desastre.

La ITSCM requiere una implicación especial de los agentes involucrados pues sus beneficios sólo se perciben a largo plazo, es costosa y carece de rentabilidad directa. Implementar la ITSCM es como contratar un seguro médico: cuesta dinero, parece inútil mientras uno está sano y desearíamos nunca tener que utilizarlo, pero tarde o temprano nos alegramos de haber sido previsores.


Los objetivos principales de la Gestión de la Continuidad de los Servicios TI (ITSCM) se resumen en:

• Garantizar la pronta recuperación de los servicios (críticos) TI tras un desastre.

• Establecer políticas y procedimientos que eviten, en la medida de lo posible, las perniciosas consecuencias de un desastre o causa de fuerza mayor.


Pág. 85/321

Aunque, a priori, las políticas proactivas que prevean y limiten los efectos de un desastre sobre los servicios TI son preferibles a las exclusivamente reactivas, es importante valorar los costes relativos y la incidencia real en la continuidad del negocio para decantarse por una de ellas o por una sabia combinación de ambas. Una correcta ITSCM debe formar parte integrante de la Gestión de Continuidad del Negocio (BCM) y debe estar a su servicio. Los servicios TI no son sino una parte, aunque a menudo muy importante, del negocio en su conjunto y no tiene mayor sentido que, por ejemplo, un sistema de pedidos online siga funcionando a la perfección tras un desastre si nos resulta imposible suministrar la mercancía a nuestros clientes. Es importante diferenciar entre desastres "de toda la vida", tales como incendios, inundaciones, etcétera, y desastres "puramente informáticos", tales como los producidos por ataques distribuidos de denegación de servicio (DDOS), virus informáticos, etcétera. Aunque es responsabilidad de la ITSCM prever los riesgos asociados en ambos casos y restaurar el servicio TI con prontitud, es evidente que recae sobre la ITSCM una responsabilidad especial en el último caso pues:

• Sólo afectan directamente a los servicios TI pero paralizan a toda la organización.

• Son más previsibles y más habituales.

• La percepción del cliente es diferente: los desastres naturales son más asumibles y no se asocian a actitudes negligentes, aunque esto no sea siempre cierto.

Los principales beneficios de una correcta Gestión de la Continuidad del Servicio se resumen en:

• Se gestionan adecuadamente los riesgos.

• Se reduce el periodo de interrupción del servicio por causas de fuerza mayor.

• Se mejora la confianza en la calidad del servicio entre clientes y usuarios. • Sirve de apoyo al proceso de Gestión de la Continuidad del Negocio (BCM).

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. • No se presupuestan correctamente los costes asociados.

• No se asignan los recursos suficientes.

• No existe el compromiso suficiente con el proceso dentro de la organización y las tareas y actividades correspondientes se demoran perpetuamente para hacer frente a "actividades más urgentes".

• No se realiza un correcto análisis de riesgos y se obvian amenazas y vulnerabilidades reales.

• El personal no esta familiarizado con las acciones y procedimientos a tomar en caso de interrupción grave de los servicios.

• Falta de coordinación con la BCM.

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.

• Evaluar el impacto en el negocio de una interrupción de los servicios TI. • Analizar y prever los riesgos a los que esta expuesto la infraestructura TI.

• Establecer las estrategias de continuidad del servicio TI.

• Adoptar medidas proactivas de prevención del riesgo. • Desarrollar los planes de contingencia.

• Poner a prueba dichos planes.

• Formar al personal sobre los procedimientos necesarios para la pronta recuperación del servicio. • Revisar periódicamente los planes para adaptarlos a las necesidades reales del negocio.



Pág. 86/321

Política y Alcance El primer paso necesario para desarrollar una Gestión de la Continuidad del Servicio coherente es establecer claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política. La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión. Es imprescindible establecer el alcance de la ITSCM en función de:

• Los planes generales de Continuidad del Negocio. • Los servicios TI estratégicos.

• Los estándares de calidad adoptados.

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

• La disponibilidad de recursos. La Gestión de la Continuidad del Servicio está abocada al fracaso sino se destina una cantidad de recursos suficientes, tanto en el plano humano como de equipamiento (software y hardware). Su dimensión depende de su alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa que no dispusiera de los recursos correspondientes. Una importante parte del esfuerzo debe destinarse a la formación del personal. Éste debe interiorizar su papel en momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergencia no es el mejor momento para estudiar documentación y manuales.


Pág. 87/321

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. En la actualidad casi todas las empresas, grandes y pequeñas, dependen en mayor o menor medida de los servicios informáticos, por lo que cabe esperar que un "apagón" de los servicios TI afecte a prácticamente todos los aspectos del negocio. Sin embargo, es evidente que hay servicios TI estratégicos de cuya continuidad puede depender la supervivencia del negocio y otros que "simplemente" aumentan la productividad de la fuerza comercial y de trabajo. Cuanto mayor sea el impacto asociado a la interrupción de un determinado servicio mayor habrá de ser el esfuerzo realizado en actividades de prevención. En aquellos casos en que la "solución puede esperar" se puede optar exclusivamente por planes de recuperación. Los servicios TI han de ser analizados por la ITSCM en función de diversos parámetros:

• Consecuencias de la interrupción del servicio en el negocio:

• Pérdida de rentabilidad. • Pérdida de cuota de mercado.

• Mala imagen de marca. o Otros efectos secundarios.

• Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos de negocio. • Compromisos adquiridos a través de los SLAs.

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

Evaluación de Riesgos

Sin conocer cuáles son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar una política de prevención y recuperación ante desastre mínimamente eficaz. La Gestión de la Continuidad del Servicio debe enumerar y evaluar, dependiendo de su probabilidad e impacto, los diferentes riesgos factores de riesgo. Para ello la ITSCM debe:

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

• Analizar las posibles amenazas y estimar su probabilidad.

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


Pág. 88/321

Gracias a los resultados de este detallado análisis se dispondrá de información suficiente para proponer diferentes medidas de prevención y recuperación que se adapten a las necesidades reales del negocio. La prevención frente a riesgos genéricos y poco probables puede ser muy cara y no estar siempre justificada, sin embargo, las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas, de rápida implementación y relativamente baratas. Por ejemplo, si el riesgo de perdida de alimentación eléctrica es elevado debido, por ejemplo, a la localización geográfica se puede optar por deslocalizar ciertos servicios TI a través de ISPs que dispongan de sistemas de generadores redundantes o adquirir generadores que proporcionen la energía mínima necesaria para alimentar los CIs de los que dependen los servicios más críticos, etcétera.

Estrategias de Continuidad

La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas, que eviten la interrupción de los servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio en el menor tiempo posible. Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención y recuperación que ofrezcan las garantías necesarias a unos costes razonables. Actividades preventivas Las medidas preventivas requieren un detallado análisis previo de riesgos y vulnerabilidades. Algunos de ellos serán de carácter general: incendios, desastres naturales, etcétera, mientras que otros tendrán un carácter estrictamente informático: fallo de sistemas de almacenamiento, ataques de hackers, virus informáticos, etcétera. La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con la Gestión de la Continuidad del Negocio (BCM) y requieren medidas que implican a la infraestructura "física" de la organización. La prevención de riesgos y vulnerabilidades "lógicas" o de hardware requieren especial atención de la ITSCM. En este aspecto es esencial la estrecha colaboración con la Gestión de la Seguridad. Los sistemas de protección habituales son los de "Fortaleza" que ofrecen protección perimetral a la infraestructura TI. Aunque imprescindibles no se hallan exentos de sus propias dificultades pues aumentan la complejidad de la infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades. Actividades de recuperación Tarde o temprano, por muy eficientes que seamos en nuestras actividades de prevención, será necesario poner en marcha procedimientos de recuperación. En líneas generales existen tres opciones de recuperación del servicio:

• Cold standby: que requiere un emplazamiento alternativo en el que podamos reproducir en pocos días nuestro entorno de producción y servicio. Esta opción es la adecuada si los planes de recuperación estiman que la organización puede mantener sus niveles de servicio durante este periodo sin el apoyo de la infraestructura TI.

• Warm standby: que requiere un emplazamiento alternativo con sistemas activos diseñados para recuperar los servicios críticos en un plazo de entre 24 y 72 horas.

• Hot standby: que requiere un emplazamiento alternativo con una replicación continua de datos y con todos los sistemas activos preparados para la inmediata sustitución de la estructura de producción. Ésta es evidentemente la opción mas costosa y debe emplearse sólo en el caso de que la interrupción del servicio TI tuviera inmediatas repercusiones comerciales.


Pág. 89/321

Por supuesto, existe otra alternativa que consiste en hacer "poco o nada" y esperar que las aguas vuelvan naturalmente a su cauce: una alternativa poco recomendable para alguien que esté hojeando este curso sobre ITIL y del que suponemos que los servicios TI jugarán un papel importante en su organización.

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

• Plan de prevención de riesgos.

• Plan de gestión de emergencias.

• Plan de recuperación. Plan de prevención de riesgos Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en la infraestructura TI. Entre las medidas habituales se encuentran:

• Almacenamiento de datos distribuidos.

• Sistemas de alimentación eléctrica de soporte. • Políticas de back-ups.

• Duplicación de sistemas críticos.

• Sistemas de seguridad pasivos. Plan de gestión de emergencias Las crisis suelen provocar "reacciones de pánico" que pueden ser contraproducentes y a veces incluso más dañinas que las provocadas por el incidente que las causó. Por ello es imprescindible que en caso de situación de emergencia estén claramente determinadas las responsabilidades y funciones del personal así como los protocolos de acción correspondientes. En principio los planes de gestión de emergencias deben tomar en cuenta aspectos tales como:

• Evaluación del impacto de la contingencia en la infraestructura TI.

• Asignación de funciones de emergencia al personal del servicio TI. • Comunicación a los usuarios y clientes de una grave interrupción o degradación del servicio.

• Procedimientos de contacto y colaboración con los proveedores involucrados.

• Protocolos para la puesta en marcha del plan de recuperación correspondiente. Plan de recuperación Cuando la interrupción del servicio es inevitable, llega el momento de poner en marcha los procedimientos de recuperación. El plan de recuperación debe incluir todo lo necesario para:

• Reorganizar al personal involucrado.

• Reestablecer los sistemas de hardware y software necesarios.

• Recuperar los datos y reiniciar el servicio TI. Los procedimientos de recuperación pueden depender de la importancia de la contingencia y de la opción de recuperación asociada ("cold o hot stand-by"), pero en general involucran:

• Asignación de personal y recursos.

• Instalaciones y hardware alternativos. • Planes de seguridad que garanticen la integridad de los datos.


Pág. 90/321

• Procedimientos de recuperación de datos. • Contratos de colaboración con otras organizaciones.

• Protocolos de comunicación con los clientes. Cuando se pone en marcha un plan de recuperación no hay espacio para la improvisación, cualquier decisión puede tener graves consecuencias tanto en la percepción que de nosotros tengan nuestros clientes como en los costes asociados al proceso. Aunque pueda resultar paradójico, un "desastre" puede ser una buena oportunidad para demostrar a nuestros clientes la solidez de nuestra organización TI y por tanto, incrementar la confianza que tiene depositada en nosotros. Ya conocen el dicho: "No hay mal que por bien no venga".

Supervisión de la Continuidad

Una vez establecidas las políticas, estrategias y planes de prevención y recuperación, es indispensable que éstos no queden en papel mojado y que la organización TI esté preparada para su correcta implementación. Ello depende de dos factores clave: la correcta formación del personal involucrado y la continua monitorización y evaluación de los planes para su adecuación a las necesidades reales del negocio. Formación Es inútil disponer de unos completos planes de prevención y recuperación si las personas que eventualmente deben llevarlos a cabo no están familiarizadas con los mismos. Es indispensable que la ITSCM:

• Dé a conocer al conjunto de la organización TI los planes de prevención y recuperación. • Ofrezca formación específica sobre los diferentes procedimientos de prevención y recuperación.

• Realice periódicamente simulacros para diferentes tipos de desastres con el fin de asegurar la capacitación del personal involucrado.

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

Actualización y auditorías Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los requisitos de la organización en su conjunto. Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación. En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos procesos de actualización y auditoría pueden establecerse de forma periódica. 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, manteniendo informada a la ITSCM de los cambios realizados o previstos.

Control del proceso

La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión que incluyan información relevante para el resto de la organización TI. Estos informes deben incluir:

• Análisis sobre nuevos riesgos y evaluación de su impacto.


Pág. 91/321

• Evaluación de los simulacros de desastre realizados. • Actividades de prevención y recuperación realizadas.

• Costes asociados a los planes de prevención y recuperación.

• Preparación y capacitación del personal TI respecto a los planes y procedimientos de prevención y recuperación.

Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio es mantener la "concentración". Tras largos periodos en los que la prevención o, simple y llanamente, la suerte han impedido la existencia de graves interrupciones del servicio, se puede caer en un relajamiento que puede acarrear graves consecuencias. Por esto es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial se diluyan y la ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que "un desastre se convierta en una catástrofe". Pero si el control del proceso es importante en condiciones normales, éste se vuelve crítico durante las situaciones de crisis. La ITSCM debe garantizar:

• La puesta en marcha de los planes preestablecidos.

• La supervisión de los mismos. • La coordinación con la Gestión de Continuidad del Negocio.

• La asignación de recursos necesarios.


Pág. 92/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA SSSEEEGGGUUURRRIIIDDDAAADDD DDDEEE LLLAAA IIINNNFFFOOORRRMMMAAACCCIIIÓÓÓNNN

Visión general La Gestión de la Seguridad de la Información se remonta al albor de los tiempos. La criptología o la ciencia de la confidencialidad de la información existe desde el inicio de nuestra civilización y ha ocupado algunas de las mentes matemáticas más brillantes de la historia, especialmente (y desafortunadamente) en tiempos de guerra. Sin embargo, desde el advenimiento de las ubicuas redes de comunicación y, en especial, de Internet los problemas asociados a la seguridad de la información se han agravado considerablemente y nos afectan a todos. Que levante la mano el que no haya sido victima de algún virus informático en su ordenador, del spam (ya sea por correo electrónico o teléfono) por una deficiente protección de sus datos personales o, aún peor, del robo del número de su tarjeta de crédito. La información es consustancial al negocio y su correcta gestión debe apoyarse en tres pilares fundamentales:

• Confidencialidad: la información debe ser sólo accesible a sus destinatarios predeterminados.

• Integridad: la información debe ser correcta y completa.

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

Introducción y Objetivos Los principales objetivos de la Gestión de la Seguridad se resumen en:

• Diseñar una política de seguridad, en colaboración con clientes y proveedores, correctamente alineada con las necesidades del negocio.


Pág. 93/321

• Asegurar el cumplimiento de los estándares de seguridad acordados en los SLAs. • Minimizar los riesgos de seguridad que amenacen la continuidad del servicio.

La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de "expertos en seguridad" que desconocen los otros procesos de negocio. Si caemos en la tentación de establecer la seguridad como una prioridad en sí misma, limitaremos las oportunidades de negocio que nos ofrece el flujo de información entre los diferentes agentes implicados y la apertura de nuevas redes y canales de comunicación. La Gestión de la Seguridad debe conocer en profundidad el negocio y los servicios que presta la organización TI para establecer protocolos de seguridad que aseguren que la información esté accesible cuando es necesaria para aquellos que tengan autorización para utilizarla. 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 SLAs correspondientes para, a renglón seguido, garantizar su cumplimiento. La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos generales a los que está expuesta la infraestructura TI, y que no necesariamente tienen por qué figurar en un SLA, para asegurar, en la medida de lo posible, que no representan un peligro para la continuidad del servicio. Es importante que la Gestión de la Seguridad sea proactiva y evalúe a priori los riesgos de seguridad que pueden suponer los cambios realizados en la infraestructura, nuevas líneas de negocio, etcétera.

Los principales beneficios de una correcta Gestión de la Seguridad:

• Se evitan interrupciones del servicio causadas por virus, ataques informáticos, etcétera. • Se minimiza el número de incidentes.

• Se tiene acceso a la información cuando se necesita y se preserva la integridad de los datos.

• Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios. • Se cumplen los reglamentos sobre protección de datos.

• Mejora la percepción y confianza de clientes y usuarios en lo que respecta a la calidad del servicio.


Pág. 94/321

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

• No existe el suficiente compromiso de todos los miembros de la organización TI con el proceso. • Se establecen políticas de seguridad excesivamente restrictivas que afectan negativamente al negocio.

• No se dispone de las herramientas necesarias para monitorizar y garantizar la seguridad del servicio (firewalls, antivirus, etc.).

• El personal no recibe una formación adecuada para la aplicación de los protocolos de seguridad. • Falta de coordinación entre los diferentes procesos, lo que impide una correcta evaluación de los riesgos.

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. Para que esa colaboración sea eficaz, es necesario que la Gestión de la Seguridad:

• Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos. • Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados tanto en los servicios prestados

a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos.

• Implemente el Plan de Seguridad. • Monitorice y evalúe el cumplimiento de dicho plan.

• Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y vulnerabilidades.

• Realice periódicamente auditorías de seguridad. Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 95/321

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. Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos tales como los objetivos, responsabilidades y recursos. En particular la Política de Seguridad debe determinar:

• La relación con la política general del negocio.

• La coordinación con los otros procesos TI.

• Los protocolos de acceso a la información. • Los procedimientos de análisis de riesgos.

• Los programas de formación.

• El nivel de monitorización de la seguridad. • Qué informes deben ser emitidos periódicamente.

• El alcance del Plan de Seguridad.

• La estructura y responsables del proceso de Gestión de la Seguridad. • Los procesos y procedimientos empleados.

• Los responsables de cada subproceso.

• Los auditores externos e internos de seguridad. • Los recursos necesarios: software, hardware y personal.

Plan de Seguridad El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos como parte de los SLAs, OLAs y UCs. Este plan ha de ser desarrollado en colaboración con la Gestión del Nivel de Servicio, que es la responsable en última instancia tanto de la calidad del servicio prestado a los clientes como la del servicio recibido por la propia organización TI y los proveedores externos. El Plan de Seguridad debe 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. Siempre que sea posible, deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad acordados. Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes en todas las fases del servicio y para todos los estamentos implicados. "Una cadena es tan resistente como el más débil de sus eslabones", por lo que carece de sentido, por ejemplo, establecer una estrictas normas de acceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante algún tiempo ofreciendo la imagen de "fortaleza", pero esto valdrá de poco si alguien descubre que la "puerta de atrás está abierta".

Aplicación de las Medidas de Seguridad Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica. Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas de seguridad establecidas en la Política y el Plan de Seguridad. En primer lugar la Gestión de la Seguridad debe verificar que:

• El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al respecto.


Pág. 96/321

• Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad. • Se imparte la formación pertinente.

Es también responsabilidad directa de la Gestión de la Seguridad:

• Asignar los recursos necesarios.

• Generar la documentación de referencia necesaria. • Colaborar con el Centro de Servicios y la Gestión de Incidentes en el tratamiento y resolución de incidentes

relacionados con la seguridad.

• Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad.

• Colaborar con la Gestión de Cambios y la de Entregas y Despliegues para asegurar que no se introducen nuevas vulnerabilidades en los sistemas en producción o entornos de pruebas.

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

• Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la integridad y confidencialidad de los datos en caso de desastre.

• Establecer las políticas y protocolos de acceso a la información. • Monitorizar las redes y servicios en red para detectar intrusiones y ataques.

Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión de la 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.

Evaluación y mantenimiento Evaluación

No es posible mejorar aquello que no se conoce, por lo que resulta indispensable evaluar el cumplimiento de las medidas de seguridad, sus resultados y el cumplimiento de los SLAs. Aunque no es imprescindible, es recomendable que estas evaluaciones se complementen con auditorías de seguridad externas y/o internas realizadas por personal independiente de la Gestión de la Seguridad. 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. Independientemente de estas evaluaciones de carácter periódico, se deberán generar informes específicos cada vez que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo considera oportuno, estos informes se acompañaran de las RFCs correspondientes. Mantenimiento

La Gestión de la Seguridad es un proceso continuo y se han de mantener al día el Plan de Seguridad y las secciones de seguridad de los SLAs. Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluación arriba citada o de cambios implementados en la infraestructura o servicios TI. No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas. Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte las medidas necesarias de actualización de equipos de hardware y software, sin olvidar el apartado de formación: el factor humano es normalmente el eslabón más débil de la cadena.


Pág. 97/321

Control del proceso Al igual que en el resto de procesos TI, es necesario realizar un riguroso control del proceso para asegurar que la Gestión de la Seguridad cumple sus objetivos. Una buena Gestión de la Seguridad debe traducirse en:

• Disminución del número de incidentes relacionados con la seguridad.

• Un acceso eficiente a la información por el personal autorizado.

• Gestión proactiva, que permita identificar vulnerabilidades potenciales antes de que estas se manifiesten y provoquen una seria degradación de la calidad del servicio.

La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridad y aporta información de vital importancia a otras áreas de la infraestructura TI. Entre la documentación generada cabría destacar:

• Informes sobre el cumplimiento, en lo todo lo referente al apartado de seguridad, de los SLAs, OLAs y UCs en vigor.

• Relación de incidentes relacionados con la seguridad, calificados por su impacto sobre la calidad del servicio. • Evaluación de los programas de formación impartidos y sus resultados.

• Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI.

• Auditorías de seguridad. • Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos.


Pág. 98/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE PPPRRROOOVVVEEEEEEDDDOOORRREEESSS 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. Su principal objetivo es alcanzar la mayor calidad a un precio adecuado. Con este fin, y teniendo siempre muy presentes las pautas marcadas desde la Estrategia del Servicio, la Gestión de Proveedores se encarga de definir una estrategia de suministradores según la cual orientar su labor, que abarca: •Seleccionar nuevos suministradores para las necesidades que vayan surgiendo en el servicio. •Definir y negociar los nuevos contratos, garantizando que queda constancia de los acuerdos financieros y de calidad alcanzados. •Gestionar la relación con los proveedores, lo que incluye velar por el cumplimiento de los contratos o actualizarlos si éstos pierden vigencia. •Renovar y terminar contratos. Por otro lado, también es la encargada de que toda la información relacionada con los proveedores y los servicios que prestan (tipo, coste, contratos) esté disponible y permanentemente actualizada. 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:


Pág. 99/321

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

• Asegurar que los contratos y acuerdos con proveedores están alineados con la estrategia y necesidades de negocio de la organización.

• Gestionar la relación con los proveedores. • Gestionar el rendimiento de los proveedores.

• Negociar los contratos con los proveedores y gestionarlos a lo largo de su ciclo de vida.

• Mantener una política de proveedores y una Base de Datos de Proveedores y Contratos (SCD). 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 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, número de entregables, etc.

• Los contratos son demasiado exigentes en calidad-precio, por lo que las negociaciones con los proveedores se tornan auténticas discusiones bizantinas que acaban alargándose demasiado.

• La Gestión de Proveedores no tiene a su alcance indicadores de rendimiento del servicio o los recibe demasiado tarde, por lo que si existen retrasos o disminuciones de calidad en el suministro, no podrá actuar con eficacia para corregirlo.

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.

• Los procesos de evaluación y selección de 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.


Pág. 100/321

Requisitos de contratación

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. Han de tenerse en cuenta, también, los informes económicos proporcionados por la Gestión Financiera, 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. Por último, 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. Una vez recogidos y analizados estos inputs, la Gestión de Proveedores debe preparar:

• Requisitos que se van a exigir a los proveedores.

• Caso de Negocio inicial sobre el que trabajar durante las negociaciones con los proveedores. • 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.

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. • Referencias de otros competidores.

• Disponibilidad y capacidad.

• Aspectos financieros. Una vez elegido el proveedor, se han de negociar los términos del servicio. 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. Es importante que en el UC queden reflejadas las metas y responsabilidades del proveedor de cara al cumplimiento de los SLAs.

Clasificación y Documentación de proveedores Una vez que se han acordado y negociado los servicios de un determinado proveedor, 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). • El nivel de actuación del proveedor: Estratégico (directivos), táctico (mandos intermedios), operativo (nivel

ejecutor).

• Relaciones con otros elementos del ciclo de vida.

Gestión del Rendimiento de los proveedores

A grandes rasgos, 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, ¿cuál es el procedimiento a seguir para actualizar el CMS?


Pág. 101/321

Renovación o terminación de contratos

Esta actividad consiste en llevar a cabo renovaciones de contratos, 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. 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.

• Cambios que es preciso acometer: servicios, productos, contratos, acuerdos, objetivos.

• Perspectivas futuras de la relación con el proveedor: crecimiento, estancamiento, cambio, terminación, transferencia, etc.

• Rendimiento comercial del contrato (criterios de cobro, estructura de precios, etc.)

• Buenas prácticas para la gestión de contratos.

• Administración de proveedores y 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: � Incremento en el número de proveedores que alcanzan los objetivos establecidos en el contrato. � Reducción del número de incumplimientos de objetivos contractuales.

• Indicadores de que los servicios de apoyo están alineados con las necesidades y objetivos de la organización: � Incremento en el número de servicios y revisiones de contrato. � Incremento en el número de proveedores y objetivos contractuales alineados con los objetivos

contenidos en los SLA y SLR.

• Indicadores de que la disponibilidad de los servicios no se ve comprometida por el rendimiento de los proveedores: � Reducción en el número de interrupciones de servicio provocadas por los proveedores. � Reducción en el número de amenazas de interrupción de servicio provocadas por proveedores.

• 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: � Incremento en el número de proveedores para los que se ha asignado un responsable. � Incremento en el número de contratos en los que figura un responsable.


Pág. 102/321

PPPUUUEEESSSTTTAAA EEENNN MMMAAARRRCCCHHHAAA 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. 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. Por ejemplo, en algunos casos, 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. 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.

• La continuidad del servicio y la atenuación de riesgos. Es imprescindible seguir una metodología adecuada en la fase de implementación. El modelo CSI ofrece una guía para ello:

• Disponer de una clara estrategia.

• Saber en qué posición nos encontramos.

• Tener objetivos bien definidos. • Disponer de un plan de actuación.

• Establecer métricas que permitan evaluar el proceso.

• Disponer de mecanismos de mejora.

RACI Para que la fase de diseño resulte exitosa es imprescindible organizar adecuadamente todos los procesos y actividades implicados. Un modelo útil para la asignación de responsabilidades en la ejecución de tareas o actividades asignados a un proyecto es el llamado modelo RACI (también llamado matriz de asignación de responsabilidades) que es el acrónimo de:

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

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

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

• Informed (Informado): Las personas que deben ser informadas sobre el progreso de ejecución de la tarea. En cada tarea debe haber un único R y A. Si esto no fuera así la tarea se subdividirá hasta que así sea. Por supuesto una persona puede ser, a priori, R o A en múltiples tareas. Una matriz RACI típicamente tiene un eje vertical donde se describen las tareas o entregables en orden cronológico y en el eje horizontal los perfiles o personas implicadas en los mismos. Un ejemplo de matriz RACI viene dado por:


Pág. 103/321

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.


Pág. 104/321

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

ITIL V.3

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

Manual Técnico

A su vez la fase de Transición debe asesorar al Diseño sobre los riesgos y posibles impactos del cambio en la

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.

Ofrecer la funcionalidad requerida.

Cumplir los protocolos de seguridad requeridos.

Permitir el acceso sólo al personal autorizado.

La fase de mejora del servicio tiene como principal objetivo generar planes de mejora para todos los procesos,

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 tuvieron en cuenta los requisitos del cliente? 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.

Pág. 105/321

A su vez la fase de Transición debe asesorar al Diseño sobre los riesgos y posibles impactos del cambio en la

final del cliente sobre la calidad del servicio.

La fase de mejora del servicio tiene como principal objetivo generar planes de mejora para todos los procesos,

La satisfacción de los clientes depende en gran medida de los procesos y actividades desarrolladas en la fase de diseño:

así es necesario introducir planes de mejora que minimicen o eliminen los problemas encontrados y


Pág. 106/321


Pág. 107/321


Pág. 108/321

TTTrrraaannnsssiiiccciiióóónnn dddeee lllooosss SSSeeerrrvvviiiccciiiooosss TTTIII La misión de la fase de Transición del Servicio es hacer que los productos y servicios definidos en la fase de Diseño del Servicio se integren en el entorno de producción y sean accesibles a los clientes y usuarios autorizados. Sus principales objetivos se resumen en:

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

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

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

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

• Comunicar el cambio a todos los agentes implicados. Para cumplir adecuadamente estos objetivos es necesario que durante la fase de Transición del Servicio:

• Se planifique todo el proceso de cambio. • Se creen los entornos de pruebas y preproducción necesarios.

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

• Se establezcan planes de roll-out (despliegue) y roll-back (retorno a la última versión estable). • Se cierre el proceso de cambio con una detallada revisión post-implementación.

Como resultado de una correcta Transición del Servicio:

• Los clientes disponen de servicios mejor alineados con sus necesidades de negocio. • La implementación de nuevos servicios es más eficiente.

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

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

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

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

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.

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

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

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

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

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


Pág. 109/321

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

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, hay que ponerse manos a la obra. La Planificación y Soporte de la Transición es la encargada de coordinar los recursos de la organización TI para poner en marcha el servicio en el tiempo, calidad y coste definidos previamente. Esto incluye la definición de los entregables (contenido, plazos, niveles de calidad), así como los flujos de trabajo y los actores involucrados en la prestación del servicio, los protocolos de control de la calidad, test de pruebas, mecanismos de monitorización, reportes, etc. Sin embargo, no podemos concebir estas tareas de coordinación como una “realidad paralela”, independiente del resto del Ciclo de Vida. La Planificación y Soporte de la Transición no podría ejercer su labor sin los inputs provenientes del resto de procesos:

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

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

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

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

• Estrategia de transición y modelo de entregas. • Recopilación integral de planes de Transición del Servicio.

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


Pág. 110/321

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, coste y calidad requeridos en las especificaciones. Para ello debe asegurarse de que todas las partes implicadas adoptan una metodología de trabajo común, proporcionando un plan de transición capaz de alinear el cambio con las necesidades del cliente. Una correcta Planificación de la Transición trae consigo importantes ventajas que aportan valor al negocio:

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

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

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

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

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

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

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

• Los SACs no están alineados con los requisitos de diseño. • Los elementos de configuración que intervienen en el cambio no están preparados llegado el momento,

ocasionando retrasos en la planificación.


Pág. 111/321

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

Conceptos básicos 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. 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.

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

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

• Estrategia � Políticas generales. � Metodología. � Actores implicados (instituciones, proveedores, etc.). � Requisitos internos y externos a tener en cuenta. � Tipos de entregas.

• Preparación � Revisión de la documentación. � Comprobación de los elementos de configuración. � Identificación de los cambios de que consta la transición.

• Planificación � Definición de fases y plazos. � Asignación de recursos. � Establecimiento de SACs.



Pág. 112/321

Estrategia de transición

En primer lugar, la organización debe definir la estrategia de transición para llevar a cabo los cambios previstos en el servicio nuevo o a modificar. Los puntos clave que debe contemplar dicha estrategia incluyen:

• Propósito, objetivos y metas.

• Contexto de prestación del servicio.

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

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

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

• Roles y responsabilidades. Requisitos de formación de la plantilla involucrada. • Planificación de hitos y entregables. Frecuencia de entrega.

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

• Criterios para dar por concluido el soporte post-implantación (ELS). Las entregas pueden clasificarse, grosso modo, en los siguientes tipos:

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

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

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

Preparación de la transición

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


Pág. 113/321

• Revisión y aceptación de los inputs procedentes del resto de procesos del Ciclo de Vida. • Revisión y comprobación del paquete de diseño del servicio (SDP) creado en la fase de Diseño.

• Revisión de los SACs.

• Identificación, desarrollo y planificación de las peticiones de cambio (RFCs). • Comprobación de que la Gestión de la Configuración está actualizada.

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

Planificación de la transición

Esta es la actividad principal del proceso, y consiste en la descripción pormenorizada del flujo de trabajo que hará posible la puesta en marcha del cambio. El plan ha de ser específico para cada nueva transición, 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, los requisitos específicos acordados con el cliente, etc. El desarrollo y despliegue de cada transición debe ser compartimentado en distintas etapas:

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

• Desarrollo de la entrega y evaluación preliminar. • Validación y pruebas de la entrega.

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

• Despliegue de la nueva versión. • Soporte post-implementación.

• Revisión y cierre de la transición. Para cada una de estas etapas deben definirse los siguientes aspectos:

• Descripción de tareas y actividades. • Recursos específicos asignados a cada tarea.

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

• Incidencias que pueden presentarse y riesgos asociados. • Plazos previstos para cada fase.

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

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

Control del proceso

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

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

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

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

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


Pág. 114/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE CCCAAAMMMBBBIIIOOOSSS

Visión general Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda «evolución a mejor» requiere necesariamente de un cambio. Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: «si algo funciona, no lo toques». Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizadas. Las principales razones para la realización de cambios en la infraestructura TI son:

• Solución de errores conocidos. • Desarrollo de nuevos servicios.

• Mejora de los servicios existentes.

• Imperativo legal. • El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para

asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.

Nota: Las interacciones y funcionalidades de la Gestión de Cambios se resumen sucintamente en el siguiente interactivo:

Introducción y Objetivos El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar. La Gestión de Cambios debe trabajar para asegurar que los cambios:

• Están justificados.

• Se llevan a cabo sin perjuicio de la calidad del servicio TI.

ITIL V.3

• Están convenientemente registrados, clasificados y documentados.• Han sido cuidadosamente testeados en un entorno de prueba.

• Se ven reflejados en la CMDB.

• Pueden deshacerse mediante planes de "retirada del cambio" (backfuncionamiento tras su implementación.

Las actividades principales de la Gestión de Cambios se resumen sucintamente en el siguiente diagrama:

Los principales beneficios derivados de una correcta gestión del cambio son:

• Se reduce el número de incidentes y problemas potencial• Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un

impacto negativo en la estructura TI.

• Se reduce el número de back-

• Los cambios son mejor aceptados y s

Manual Técnico

emente registrados, clasificados y documentados. Han sido cuidadosamente testeados en un entorno de prueba.

Se ven reflejados en la CMDB.

Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto implementación.


Los principales beneficios derivados de una correcta gestión del cambio son:

Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio. Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI.

-outs necesarios.

Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".

Pág. 115/321

outs) en caso de un incorrecto


Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un


Pág. 116/321

• Se evalúan los verdaderos costes asociados al cambio, y por lo tanto es más sencillo valorar el retorno real a la inversión.

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

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

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

• Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio, independientemente de que éste se realice para solucionar un problema, mejorar un servicio o adaptarse a requisitos legales.

• No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la información sobre los CIs en la CMDB.

• Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización, lo que les incapacita para desarrollar correctamente su actividad.

• Los Gestores del Cambio no disponen de las herramientas de software adecuadas para monitorizar y documentar el proceso de forma apropiada.

• No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.

• Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o, por el contrario, el proceso de cambio se trivializa, provocando una falta de estabilidad que empobrece la calidad del servicio.

Conceptos básicos En el resto de este capítulo, se utilizará con frecuencia el concepto de Gestor de Cambios y el de Comité Asesor del Cambio (CAB), por lo que resulta conveniente describir y diferenciar sus respectivas atribuciones: Gestor de Cambios: es el responsable del proceso del cambio y, como tal, debe ser el último responsable de todas las tareas asignadas a la Gestión de Cambios. En grandes organizaciones, el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas. Comité Asesor del Cambio (CAB): es un órgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión de servicios TI. Sin embargo, en algunos casos también puede incorporar:

• Consultores externos. • Representantes de los colectivos de usuarios.

• Representantes de los principales proveedores de software y hardware.

• Modelos de Cambio: es una serie de grupos de cambios que han sido previamente clasificados, analizados y autorizados, de tal manera que se predefinen ciertos mecanismos y actividades a realizar para cada grupo. De esta manera se alcanza un control más efectivo y una implementación mucho más ágil de las RFCs.


Pág. 117/321

Alcance de la Gestión de Cambios En principio, todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta. El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de la Configuración y Activos TI: todos los cambios de CIs inventariados en la CMDB deben ser correctamente supervisados y registrados. Al igual que a la hora de implementar la Gestión de la Configuración y Activos TI, se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos estén previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas. Estos protocolos de cambio estándar deben ser cuidadosamente elaborados, pero una vez definidos permiten una gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.

Proceso

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

• Registrar, evaluar y aceptar o rechazar las RFCs recibidas.

• Planificación e implementación del cambio


Pág. 118/321

• Convocar reuniones del CAB, excepto en el caso de cambios menores, 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. Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.

Registro de peticiones

El primer paso del proceso de cambio es registrar adecuadamente las RFCs. El origen de una RFC puede ser de muy distinta índole:

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

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

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

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


Pág. 119/321

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

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

No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requieran la aprobación de la Gestión de Cambios para cada caso. Independientemente de su origen, el correcto registro inicial de una RFC requerirá, cuando menos, de los siguientes datos:

• Fecha de recepción.

• Identificador único de la RFC. • Identificador del error conocido asociado (dado el caso).

• Descripción del cambio propuesto:

• Motivación. • Propósito.

• CIs involucrados.

• Estimación de recursos necesarios para la implementación. • Tiempo estimado.

• Estatus: que inicialmente será el de "registrado". • Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un

detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre. La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos:

• Estatus actualizado: "aceptado", "rechazado", "implementado", etc.

• Fecha de aceptación (denegación) del RFC. • Evaluación preliminar de la Gestión del Cambio.

• Prioridad y categoría.

• Planes de back-out. • Recursos asignados.

• Fecha de implementación.

• Plan de implementación. • Cronograma.

• Revisión post-implementación.

• Evaluación final. • Fecha de cierre.

Aceptación y Clasificación del cambio

Aceptación Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicitó con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFC o para que pueda ser consecuentemente modificada. La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrado justificado su ulterior procesamiento.


Pág. 120/321

Clasificación 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. La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será el dato relevante para establecer el calendario de cambios a realizar. La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio. Aunque el rango de posibles prioridades pueda ser tan amplio como se desee, se debería considerar una clasificación que incluyera, al menos, los siguientes niveles de prioridad:

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

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

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

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

La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección. Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento.

Aprobación y Planificación del cambio La planificación es esencial para una buena gestión del cambio. Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede provocar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de back-out que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente. En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente. Para su aprobación, el cambio se debe evaluar minuciosamente:

• ¿Cuáles son los beneficios esperados del cambio propuesto? • ¿Justifican esos beneficios los costes asociados al proceso de cambio?

• ¿Cuáles son los riesgos asociados?


Pág. 121/321

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

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

• ¿Puede el cambio afectar los niveles establecidos de seguridad TI? En el caso de cambios que tengan un alto impacto, debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización. Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si éste ha de ser implementado aisladamente o dentro de un "paquete de cambios", que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:

• Se optimizan los recursos necesarios.

• Se evitan posibles incompatibilidades entre diferentes cambios.

• Sólo se necesita un plan de back-out. • Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.

Implementación del cambio Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestión de Entregas y Despliegues, 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 cumplen los calendarios previstos y la asignación de recursos es la adecuada.

• El entorno de pruebas es realista y simula adecuadamente el entorno de producción.

• Los planes de back-out permitirán la rápida recuperación de la última configuración estable. Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:

• Funcionalidad.

• Usabilidad.

• Accesibilidad. • La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se

encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios).

Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de Cambios como del Centro de Servicios mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles partícipes del mismo:

• Escuchando sus sugerencias. • Comunicando las ventajas asociadas.

• Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes.

Evaluación del cambio Antes de proceder al cierre del cambio, es necesario verificar que ha sido positivo para el servicio, ya porque el nivel de calidad se ha visto aumentado o porque contribuye a mejorar la productividad de la organización. Aunque la Gestión de


Pág. 122/321

Cambios es la encargada de emitir el dictamen final, es la Evaluación del servicio la que ha de proporcionar a ésta los informes. Los aspectos fundamentales a tener en cuenta son:

• ¿Se cumplieron los objetivos previstos? • ¿En qué medida se apartó el proceso de las previsiones realizadas por la Gestión de Cambios?

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

• ¿Cuál ha sido la percepción de los usuarios respecto al cambio? • ¿Se pusieron en marcha los planes de back-out en alguna fase del proceso?¿Por qué?

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

Cambios de emergencia

Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente, a veces resultan inevitables. Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia. El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:

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

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

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

Como el objetivo prioritario en estos casos es restaurar el servicio, es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a posteriori. Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. Si esto no fuera así, se podrían provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.

Control del proceso Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios. Para que estos informes ofrezcan una información precisa y de sencilla evaluación, es imprescindible elaborar métricas de referencia que cubran aspectos tales como:

• RFCs solicitados.

• Porcentaje de RFCs aceptados y aprobados.

• Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente. • Tiempo medio del cambio dependiendo del impacto y la prioridad.

• Número de cambios de emergencia realizados.

• Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc. • Numero de back-outs con una detallada explicación de los mismos.

ITIL V.3

• Evaluaciones post-implementación.• Porcentajes de cambios cerrados

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

Manual Técnico

implementación. Porcentajes de cambios cerrados sin incidencias ulteriores.

Incidencias asociadas a cambios realizados. Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios

Pág. 123/321

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


Pág. 124/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA CCCOOONNNFFFIIIGGGUUURRRAAACCCIIIÓÓÓNNN YYY AAACCCTTTIIIVVVOOOSSS DDDEEELLL SSSEEERRRVVVIIICCCIIIOOO

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

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

• Interactuar con la Gestiones de Incidencias, Problemas, Cambios y Entregas y Despliegues de manera que éstas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas, realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.

• Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias.

Las interacciones y funcionalidades de la Gestión de la Configuración y Activos TI se resumen sucintamente en el siguiente interactivo:


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


Pág. 125/321

Mantener actualizada la Base de Datos de Gestión de Configuración y Activos TI:

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

• Servicios que ofrecen los diferentes CIs.

• Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidencias, Problemas y Cambios. Los beneficios de una correcta Gestión de la Configuración y Activos TI incluyen, entre otros:

• Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. Una fuente habitual de problemas es la incompatibilidad entre diferentes CIs, drivers desactualizados, etc. 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. Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas.

• Reducción de costes. El conocimiento detallado de todos los elementos de configuración permite, por ejemplo, eliminar duplicidades innecesarias.

• Control de licencias. Se pueden identificar copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización.

• Mayores niveles de seguridad. Una CMDB actualizada permite, por ejemplo, detectar vulnerabilidades en la infraestructura.

• Mayor rapidez en la restauración del servicio. Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible.

Las principales dificultades con las que topa la Gestión de la Configuración y Activos TI son:

• Una incorrecta planificación: es esencial programar correctamente las actividades necesarias para evitar duplicaciones o incorrecciones.

• Estructura inadecuada de la CMDB: mantener actualizada una Base de Datos de Gestión de Configuración y Activos TI excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos.

• Herramientas inadecuadas: es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la CMDB.

• Falta de Coordinación con la Gestión de Cambios y la de Entregables y Despliegues, que imposibilita el correcto mantenimiento de la CMDB.

• Falta de organización: es importante que haya una correcta asignación de recursos y responsabilidades. Es preferible, cuando sea posible, que la Gestión de la Configuración y Activos TI sea llevada a cabo por personal independiente y especializado.

• Falta de compromiso: los beneficios de la Gestión de la Configuración y Activos TI no son inmediatos y son casi siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa y, consecuentemente, de los agentes implicados.

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. Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:


Pág. 126/321

• Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes: tarjetas de red, teclados, lectores de CDs, etc.

• Software: sistemas operativos, aplicaciones, protocolos de red, etc.

• Documentación: manuales, acuerdos de niveles de servicio, etc. En resumen, todos los componentes que han de ser gestionados por la organización TI. Cada información registrada sobre un CI recibe el nombre de atributo. Son ejemplos de atributos: número de versión, nombre, localización, etc. 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. • Interrelaciones entre los diferentes elementos de configuración, como, por ejemplo, relaciones "padre-hijo" o

interdependencias tanto lógicas como físicas.

• La CMDB no se limita a una mera enumeración del stock de piezas, sino que nos brinda una imagen global de la infraestructura TI de la organización.

Sistema de Gestión de la Configuración (CMS) : es un sistema de apoyo diseñado para infraestructuras de servicios TI de gran complejidad.

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.

• Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos.

• Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.

• Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

• Elaboración de informes: para evaluar el rendimiento de la Gestión de la Configuración y Activos TI y aportar información de vital importancia a otras áreas de la infraestructura TI.



Pág. 127/321

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. Por ello, su implantación es particularmente compleja. 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, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:

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

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

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

• El alcance y objetivos.

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

• Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Entregas y Despliegues y los Departamentos de Compras y Suministros.

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.

Clasificación y Registro de CIs La principal tarea de la Gestión de la Configuración y Activos TI es mantener la CMDB. Es imprescindible, para llevar a cabo esta labor con éxito, predeterminar la estructura del CMDB de manera que:

• Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.

• La información sea suficiente: debe existir, al menos, un registro de todos los sistemas críticos para la infraestructura TI.

Alcance

En primer lugar habremos de determinar 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. Por ejemplo, pueden obviarse componentes que ya han sido retirados.

• Es recomendable incorporar, al menos, la documentación asociada a proyectos, SLAs y licencias. • En general, cualquier servicio o proceso es susceptible de ser incluido en la CMDB, pero unos objetivos en

exceso ambiciosos pueden resultar contraproducentes. Nivel de detalle y Profundidad

Una vez determinado el alcance de la CMDB, es imprescindible establecer el nivel de detalle y profundidad deseados:

• Determinar los atributos que describen a un determinado CI.

• Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs. • Subcomponentes registrados independientemente.

ITIL V.3

Por ejemplo, si se decide incluir los equipos de sobre� Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.� Relaciones: conexión en red, impresoras conectadas, etc.� Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.

Nomenclatura

Aunque este sea un aspecto muy técnico, es de vital importancia predefinir los códigos de clasificación de los CIs para que el sistema sea funcional:

• La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.

• Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación).

• Los códigos no deben ser sólo utilizados para componentes de hardware sino tambisoftware.

Monitorización Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede ser de gran utilidad, por ejemplo, a la Gestión de la Disponibilidad para conocer qué CIs degradación de la calidad del servicio. 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, organizados por diferentes filetc.). Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de, digamos, los switches instalados a la hora de adoptar decisiones de compra de nuevo material:

Manual Técnico

Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB: Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.Relaciones: conexión en red, impresoras conectadas, etc. Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.

Aunque este sea un aspecto muy técnico, es de vital importancia predefinir los códigos de clasificación de los CIs para

La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.

e código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación).

Los códigos no deben ser sólo utilizados para componentes de hardware sino también para documentación y

Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede ser de gran utilidad, por ejemplo, a la Gestión de la Disponibilidad para conocer qué CIs han sido responsables de la

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, organizados por diferentes filtros (tipo, fabricante, responsable, costes,

Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de, digamos, los switches instalados a la hora de adoptar decisiones de compra de nuevo material:

Pág. 128/321

Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.

Aunque este sea un aspecto muy técnico, es de vital importancia predefinir los códigos de clasificación de los CIs para

e código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir

én para documentación y

Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede han sido responsables de la

Puede representar una ayuda para el análisis el uso de herramientas de software que ofrezcan representaciones tros (tipo, fabricante, responsable, costes,

Por ejemplo, puede resultar interesante para la Gestión Financiera la monitorización del ciclo de vida de, digamos, los


Pág. 129/321

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. El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el software "en producción". Las tareas de control deben centrarse en:

• Asegurar que todos los componentes están registrados en la CMDB. • Monitorizar el estado de todos los componentes.

• Actualizar las interrelaciones entre los CIs. • Informar sobre el estado de las licencias.

Auditorías

El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización. Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB. Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:

• Tras la implementación de una nueva CMDB.

• Antes y después de cambios mayores en la infraestructura.

• Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta.

ITIL V.3

Las auditorías deben dedicar especial atención a aspectos tales

• Uso correcto de la nomenclatura en los registros de los CIs.• Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, etc.

• Estado de los CIs actualizado.

• Cumplimiento de los niveles de alcance y detalle predeterminados.• Adecuación de la estructura de la CMDB con la de la estructura TI real.

Control del proceso

Una correcta Gestión de la Configuración y Activos TI necesita la colaboración de toda la estructura TI para mantener actualizada la información almacenada en la CM Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Configuración y Activos TI, tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras áreas de la infraestructura TI. Entre la documentación generada cabría destacar:

• Alcance y nivel de detalle de la CMDB.

• Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.

• Información sobre CIs que han estado involuc• Costes asociados al proceso.

• Sistemas de clasificación y nomenclatura utilizados.

• Informes sobre configuraciones no autorizadas y/o sin licencias.• Calidad del proceso de registro y clasificación.

• Información estadística y composición d En pequeñas organizaciones, 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.

Manual Técnico

Las auditorías deben dedicar especial atención a aspectos tales como:

Uso correcto de la nomenclatura en los registros de los CIs. Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, etc.

Estado de los CIs actualizado.

Cumplimiento de los niveles de alcance y detalle predeterminados. ecuación de la estructura de la CMDB con la de la estructura TI real.

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.

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Configuración y Activos TI, tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras


Alcance y nivel de detalle de la CMDB.

Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.

Información sobre CIs que han estado involucrados en incidentes.

Sistemas de clasificación y nomenclatura utilizados.

Informes sobre configuraciones no autorizadas y/o sin licencias. Calidad del proceso de registro y clasificación.

Información estadística y composición de la estructura TI.

En pequeñas organizaciones, es a veces conveniente combinar la Gestión de 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

sta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la

Pág. 130/321

Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, etc.

Una correcta Gestión de la Configuración y Activos TI necesita la colaboración de toda la estructura TI para mantener

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Configuración y Activos TI, tanto para conocer la estructura y adecuación de la CMDB como para aportar información de vital importancia a otras

Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.

En pequeñas organizaciones, 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

sta unificación puede resultar beneficiosa en aquellos casos en el que el volumen de la infraestructura no justifica la


Pág. 131/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE EEENNNTTTRRREEEGGGAAASSS YYY DDDEEESSSPPPLLLIIIEEEGGGUUUEEESSS

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. 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, denominada DSL en itilV2), donde se guardan copias de todo el software en producción, y los Recambios Definitivos (DS, conocido como DHS en ITIL v2), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción. Las interacciones y funcionalidades de la Gestión de Entregas y Despliegues se resumen sucintamente en el siguiente interactivo:


Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea delicada la implementación de cualquier cambio. Si la Planificación y Soporte de la Transición es la encargada de diseñar el Plan del Cambio, la Gestión de Cambios de aprobarlo y supervisarlo, y la Validación y Pruebas de testear cada nueva versión, es la Gestión de Entregas y Despliegues la que realmente pone en marcha el proceso. Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI.


Pág. 132/321

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

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

• Asegurar, en colaboración con la Gestión de Cambios y la de Configuración y Activos TI, que todos los cambios se ven correctamente reflejados en la CMDB.

• Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la DML.

• Mantener actualizado el DS. 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. • Las nuevas versiones cumplen los objetivos propuestos.

• El correcto mantenimiento de la DML impide que se pierdan (valiosas) copias de los archivos fuente.

• Se reduce el número de copias de software ilegales. • Control centralizado del software y hardware desplegado.

• Protección contra virus y problemas asociados a versiones de software incontroladas. Las principales dificultades con las que topa la Gestión de 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.

• No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las nuevas versiones de software y hardware.

• Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. Es habitual que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobre todo cuando ésta no ha sido la política tradicional de la misma.

• Se realizan cambios sin tener en cuenta a la Gestión de Entregas y Despliegues argumentado que éstos sólo son responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello.

• Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última versión estable.

• La implementación sincronizada de versiones en entornos altamente distribuidos. La solución a estos problemas pasa por:

• Un firme compromiso de la organización con la Gestión de Entregas y Despliegues y sus responsables.

• Un adecuado plan de comunicación que informe a todos los responsables y usuarios de la organización TI de las ventajas de una correcta gestión de todo el proceso de cambio.

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. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente. Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:

• Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, características técnicas, etc.


Pág. 133/321

• Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.

• Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido. Como pueden llegar a existir múltiples versiones, es conveniente definir una referencia o código que los identifique unívocamente. El sistema universalmente aceptado es:

• Versiones mayores: 1.0, 2.0, etc.

• Versiones menores: 1.1, 1.2, 1.3, etc. • Versiones de emergencia: 1.1.1, 1.1.2, etc.

• Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).

En su ciclo de vida, una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado. El siguiente diagrama nos ilustra gráficamente la evolución temporal de una versión:

El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar:

• Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.

• Versión completa: Se distribuyen todos los elementos afectados, ya hayan sido modificados o no. Aunque esta opción es obviamente más trabajosa, es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.

• Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones: de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevas versiones de los programas ofimáticos.

• Biblioteca de Medios Definitivos (DML)


Pág. 134/321

• La Biblioteca de Medios Definitivos (DML) debe contener una copia de todo el software instalado en el entorno TI. Esto incluye no sólo sistemas operativos y aplicaciones, sino también controladores de dispositivos y documentación asociada.

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 back-out. La DML debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos. 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 CIs correspondientes se hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).

Proceso

Las principales actividades de la Gestión de Entregas y Despliegues se resumen en:

• Establecer una política de planificación para la implementación de nuevas versiones. • Desarrollar o adquirir de terceros las nuevas versiones.

• Implementar las nuevas versiones en el entorno de producción.

• Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario. • Actualizar la DML, el DS y la CMDB.

• Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión. El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Entregas y Despliegues: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 135/321

Planificación de entregas Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Esto es especialmente importante para los casos de versiones menores y de emergencia, pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso. A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes factores:

• Cómo puede afectar la nueva versión a otras áreas del entramado TI.

• Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.

• Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción. • Qué planes de back-out son necesarios.

• Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI.

• Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con garantías de éxito.

• Quiénes serán los responsables directos en las diferentes etapas del proceso

• Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén puntualmente informados y puedan percibir la nueva versión como una mejora.

• Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos, gradual...

• Cuál es la vida media útil esperada de la nueva versión.

• Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio. • Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva

versión. Una herramienta clave para formular la planificación de entregas es el Modelo en V, que sirve para identificar los diferentes niveles de test necesarios para aceptar una versión durante el proceso de Validación y Pruebas.


Pág. 136/321

La metodología del Modelo en V consiste en definir, en el brazo izquierdo de la V, las especificaciones del servicio que es necesario cumplir para aceptar una versión. En el brazo derecho se van indicando, de forma paralela, las pruebas mediante las cuales se van a comprobar cada una de las especificaciones de la izquierda.

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. A veces el desarrollo se realizará "en casa" y muchas otras requerirá la participación de proveedores externos. En este segundo caso, 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, la Gestión de Entregas y Despliegues será la responsable de todo el proceso de configuración necesario. El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación requeridos para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:

• Back-up automático de datos.

• Actualizaciones necesarias de las Bases de Datos asociadas. • Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos.

• Creación de logs asociados al proceso de instalación.

• Parte integrante del desarrollo lo componen los planes de back-out asociados. É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, también conocida como rollout. El rollout puede ser de varios tipos:

• Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos. • Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versión por grupos

de trabajo o incrementando progresivamente la funcionalidad ofrecida.

• El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. En particular, los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cómo éste puede afectar a sus actividades diarias.

Es imprescindible determinar claramente:

• Los CIs que deben borrarse e instalarse y en qué orden debe realizarse este proceso. • Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.

• Qué métricas determinan la puesta en marcha de los planes de back-out y si éstos deben ser completos o parciales.

Tras la distribución, 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.

• La CMDB esté correctamente actualizada. • Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación

necesaria para poder sacar el adecuado provecho de las mismas.


Pág. 137/321

Tras la implementación, la Gestión de Entregas y Despliegues debe ser puntualmente informada por el Centro de Servicios de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.

Comunicación y Formación Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano. Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena. Es inútil disponer de un sofisticado servicio TI si los usuarios, debido a una incompleta (in)formación, no se encuentran en disposición de aprovechar sus ventajas. La (in)formación debe estructurarse en distintos niveles:

• Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el proceso.

• Cuando se considere oportuno, se impartirán cursos presenciales o remotos mediante módulos de e-learning sobre el funcionamiento de la nueva versión.

Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y puedan solicitar ayuda o soporte técnico en el uso de la nueva versión.

Control del proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Entregas y Despliegues. Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:

• Número de lanzamientos de nuevas versiones. • Número de back-outs y razones de los mismos.

• Incidencias asociadas a nuevas versiones.

• Cumplimientos de los plazos previstos para cada despliegue. • Asignación de recursos en cada caso.

• Corrección y alcance de la CMDB y la DS.

• Existencia de versiones ilegales de software. • Adecuado registro de las nuevas versiones en la CMDB.

• Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios.

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


Pág. 138/321

VVVAAALLLIIIDDDAAACCCIIIÓÓÓNNN YYY PPPRRRUUUEEEBBBAAASSS

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, por supuesto, no van a provocar ningún error inesperado cuando estén operativas. La Validación y Pruebas del Servicio se relaciona con los siguientes procesos del Ciclo de Vida:

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

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

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

• La Gestión de Entregables y Despliegues proporciona la versión a testear propiamente dicha. Una vez terminadas las sesiones de testeo, la Validación y Pruebas del Servicio ha de entregar los resultados de las mismas a la Evaluación para que elabore los informes de rendimiento que luego servirán a la Gestión de Cambios para tomar una decisión final. Nota: Las interacciones y funcionalidades de la Validación y Pruebas se resumen sucintamente en el siguiente interactivo:


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


Pág. 139/321

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Proceso

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

• Validación de paquetes de servicios, ofertas y contratos. Definición del modelo de pruebas, la planificación y los protocolos de testeo.

• Construcción del escenario de pruebas y acceso a los elementos a probar.

• Pruebas de las nuevas versiones en un entorno idéntico al entorno real de desarrollo del servicio nuevo o mejorado.

• Aceptación de los datos y elaboración de informes de resultados que registren los errores, de haberse producido.

• Limpieza del entorno de pruebas y cierre del proceso. Nota: Los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 140/321

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. 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). Cuanto mayor sea el alcance del plan de pruebas, mayores serán las garantías de fiabilidad de la nueva versión. 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, ordenada y sin pérdidas de valiosa información. Estas consideraciones se registran y estructuran en el modelo de pruebas, que incluye:

• El propio objeto de las pruebas, proporcionado por la Gestión de Entregas y Despliegues.

• Plan de Pruebas, que recoge la planificación y la estimación de plazos para cada una de las pruebas: técnicas, funcionales, etc. Puede haber uno o varios, dependiendo de las circunstancias y magnitud de los cambios.

• Guiones de pruebas, que recogen el método a emplear: cómo se va a testear cada elemento, 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.

• 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. Al final de todo el proceso, 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.

Una vez planificado el proceso, el siguiente paso consiste en la validación de los paquetes de servicios, las ofertas y los contratos (UCs). El objetivo último es asegurar que el servicio TI se corresponde con la utilidad y garantía esperadas, y que el proveedor o proveedores correspondientes están preparados para poner en funcionamiento el nuevo servicio a partir de su despliegue.


Pág. 141/321

Llegado este punto, 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, por ejemplo, los picos de demanda) y a todos los casos de uso (interfaces, perfil tecnológico de los usuarios, roles, etc).

Construcción de tests

En esta etapa, 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. La fiabilidad de las pruebas está condicionada al entorno en el que éstas tienen lugar. Si no es idéntico al escenario real en que se desplegará el servicio nuevo o modificado, los resultados de las pruebas se verán distorsionados y por tanto no servirán. De ahí la importancia de que el escenario de pruebas tenga:

• Las mismas versiones de software que la plataforma en producción.

• Los mismos dispositivos de hardware. • Clones de las bases de datos. Sólo si se utilizan las bases de datos reales pueden obtenerse informes precisos

sobre, por ejemplo, el rendimiento de las consultas, con resultados que no aparecerían de utilizar bases de datos de ejemplo con sólo unas pocas entradas.

Antes de dar comienzo a las pruebas, 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.

Pruebas En esta etapa del proceso se llevan a cabo las pruebas propiamente dichas: todos los componentes, herramientas y mecanismos que participan en el despliegue, la migración y el back-out son examinados uno por uno. El desarrollo de las pruebas puede ser automático o manual. Las principales actividades realizadas en el subproceso de pruebas deben incluir:

• Pruebas del correcto funcionamiento de la versión.

• Pruebas de los procedimientos automáticos o manuales de instalación.

• Pruebas de los planes de back-out. • Pruebas por grupo objetivo (roles), para medir la utilidad del servicio.

• Siempre que sea posible, las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales.

Durante este proceso de prueba se documentará y analizará:

• La experiencia subjetiva del usuario. • Los comentarios y sugerencias sobre usabilidad y funcionalidad o las dudas que hayan surgido durante el uso

de la nueva versión.

• La claridad de la documentación que se pondrá a disposición del usuario final.

Aceptación y reporte

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, es devuelta como “no aceptada” a la Gestión de Cambios para su reevaluación. En cambio, 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, se procede a la elaboración de un informe completo de resultados de las pruebas.


Pág. 142/321

Este documento incluye:

• Reporte de actividades realizadas. • Listas de bugs o errores detectados, si se diera el caso.

• Ideas de mejora, que se envían a la fase de CSI.

• Información y conocimiento para el SKMS. 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.

Limpieza y cierre

Por último, se procede a la limpieza del entorno de pruebas, revirtiendo los cambios incorporados durante los test (instalación de aplicaciones, importación de datos, etc.) hasta la situación inicial. En esta última etapa, el equipo encargado de las pruebas revisa el planteamiento de las mismas y verifica si la planificación se cumplió conforme a los recursos, SACs y plazos acordados. Así, se detectan aspectos mejorables para perfeccionar el proceso.

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.

• Número de errores conocidos que se registran durante la etapa de pruebas.

• Tiempo de demora en la subsanación de errores. • Número de incidentes atribuibles a las nuevas versiones.

• Porcentaje de test de aceptación del servicio que no obtienen la aprobación del cliente.


Pág. 143/321

EEEVVVAAALLLUUUAAACCCIIIÓÓÓNNN Es evidente que, 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, es preciso valorar los pros y contras, así como la relación coste-beneficio que aportará una vez esté en marcha. Aunque la decisión última recae en otros procesos, 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. Sin embargo, a pesar de ser ésta su función principal, la Evaluación no debe concebirse como una actividad puntual, sino como un proceso iterativo. Los informes preliminares de rendimiento del servicio son útiles a la hora de planificar la transición, pero han de ser contrastados con informes posteriores una vez que éstos han sido implantados. La Evaluación está estrechamente relacionada, por lo tanto, con otros procesos del Ciclo de Vida, ya que de ellos recibe los inputs necesarios para elaborar sus informes:

• El Diseño del Servicio aportará el SDP, donde figuran las características del servicio nuevo o modificado. • La Gestión de Cambios proporcionará la documentación necesaria para llevar la evaluación a cabo: registro de

la RFC, informe de impacto y riesgos previstos, etc…

• La Validación y Pruebas del Servicio suministra, por su parte, el informe de resultados de las labores de testeo. La Evaluación, por su parte, 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 Mejora Continua del Servicio detecte necesidades o carencias relacionadas con el rendimiento y proponga nuevas RFC.

Las interacciones y funcionalidades de la Evaluación se resumen sucintamente en el siguiente interactivo:


Pág. 144/321

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. No debe confundirse esta labor con la de verificar si el servicio cumple los requisitos mínimos de calidad, eficacia y utilidad, que corresponde a la Validación y Pruebas del Servicio. 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, ya sea porque incrementa su calidad o porque proporciona una mejora en la productividad. 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.

• Los resultados de la Validación y Pruebas del Servicio son incompletos o poco detallados, lo que puede resultar en una evaluación sesgada.

• El modelo de rendimiento no refleja el servicio en toda su complejidad, ocasionando un constante desequilibrio entre las estimaciones iniciales de rendimiento previsto y el rendimiento real del servicio una vez implantados los cambios.

• No se analiza el rendimiento del servicio con suficiente celo, por lo que algunos efectos imprevistos del cambio no llegan a advertirse.

Las actividades de la Evaluación se resumen en:

• Planificación de la evaluación, que consiste en analizar los efectos, tanto previstos como imprevistos, de la puesta en marcha de un cambio o nuevo servicio. Evaluación del rendimiento previsto. Se realiza antes de implementar el cambio y consiste en predecir los efectos que éste tendrá una vez esté operativo.

• Evaluación del rendimiento real. Se realiza una vez el cambio ha sido ya implementado, y consiste en analizar los efectos que ha provocado su puesta en marcha.



Pág. 145/321

Planificación de la evaluación

El propósito de la Evaluación es, 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. Con el fin de predecir el impacto de un cambio, la Evaluación considerará los siguientes factores:

• Capacidad del proveedor de Servicios (S). La capacidad de un proveedor o de una unidad de servicio para desempeñar su trabajo.

• Tolerancia (T). La capacidad que tiene el servicio para absorber cambios.

• Configuración de la Organización (O). La capacidad que tiene la organización TI para absorber cambios.

• Recursos (R). Disponibilidad de la necesaria infraestructura, personal cualificado, fondos económicos, etc. para llevar a cabo la transición.

• Modelado y medidas (M). Grado en que las predicciones formuladas a partir del modelo de rendimiento coinciden con el comportamiento real del servicio modificado.

• Personas (P). Las personas dentro del sistema y el efecto del cambio en ellas.

• Uso (U). Grado en que el servicio cumple con las expectativas de uso (p.ej. disponibilidad, capacidad, seguridad, etc.)

• Propósito (P). Grado en que el servicio se ajusta al propósito inicial. La mejor manera de garantizar que el impacto del cambio se ha comprendido en profundidad es examinarlo desde dos perspectivas:

• Efectos deliberados. En general, son beneficiosos para el servicio y deben estar alineados con los SACs definidos por la Planificación y Soporte a la Transición. Algunos ejemplos: reducción del coste del servicio, incremento del rendimiento, optimización de recursos, etc.

• Efectos imprevistos. Son muy difíciles de predecir e incluso de detectar, ya que a menudo no se manifiestan hasta que se despliega el cambio en producción.

Por lo general, suelen ser perjudiciales para el servicio y son difíciles de medir: impacto en los clientes/usuarios, 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, que toma como referencia:

• Requisitos del cliente (SLRs, SLAs).

• Rendimiento esperado o rendimiento que está previsto que el servicio obtenga una vez implantado el cambio. • Modelo de rendimiento, que no es sino una representación de la utilidad y garantía del servicio.

Si la Evaluación concluye que el rendimiento real no coincide con lo previsto, acarrea riesgos inaceptables o bien se desvía de los criterios de aceptación, entonces se interrumpen las actividades de evaluación y se genera un Informe Intermedio de Valoración, que será enviado a la Gestión de Cambios y que contemplará:

• Perfil de riesgos.

• Reporte de desviaciones (rendimiento esperado vs. real). • Recomendaciones.

• Control de calidad. Si, en cambio, la Evaluación concluye que el rendimiento previsto coincide con lo esperado, se procede al despliegue del cambio y a la evaluación del rendimiento real.


Pág. 146/321

Evaluación de rendimiento real Una vez ya se ha implantado el cambio, desde la fase de Operación se envían a la Evaluación los informes del rendimiento real que está registrando el servicio. De nuevo, se analizarán los riesgos comparando estos datos con los requisitos del cliente, el rendimiento esperado y el modelo de rendimiento. Si todo marcha según lo esperado, se genera un informe de evaluación final y se da por concluido el proceso de Evaluación. Si, en cambio, se determina que el cambio está comportando riesgos inaceptables, se están incumpliendo los criterios de aceptación o el rendimiento no alcanza las expectativas iniciales, es responsabilidad de la Evaluación alertar a la Gestión de Cambios y hacerle llegar un Informe Intermedio de Valoración en los términos descritos en el apartado anterior. Este desenlace también cierra el proceso de Evaluación, ya que si la Gestión de Cambios desea corregir la situación, se generará una nueva RFCs conforme a los planes de retirada.

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. • Número de evaluaciones entregadas en un periodo determinado.

• Número de evaluaciones que permanecen en la cola de tareas.

• Tiempo medio de elaboración de una evaluación desde que ésta es solicitada hasta que se entrega. • Desviación de las evaluaciones de rendimiento previsto respecto de las evaluaciones reales.


Pág. 147/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEELLL CCCOOONNNOOOCCCIIIMMMIIIEEENNNTTTOOO

Visión general El aspecto más beneficioso de trabajar en equipo reside en la oportunidad de compartir el saber, las ideas y la experiencia acumulada de todos los integrantes del mismo. Este fenómeno se reproduce, a mayor escala, cuando son todos los miembros de una organización los que contribuyen a crear un acervo común de conocimientos. La experiencia y conocimientos del personal, información de contacto y servicios ofrecidos por los proveedores, así como detalles sobre la rutina diaria (comportamiento de los usuarios, rendimiento de la organización, etc.) constituyen información muy útil para ahorrar tiempo y esfuerzo. La cantidad de información que una organización puede generar, incluso una de dimensiones modestas, es suficientemente voluminosa como para que resulte imprescindible una gestión centralizada de la misma. La Gestión del Conocimiento se encarga de establecer unos criterios de registro y de acometer labores periódicas de clasificación, evaluación y mejora de los datos disponibles. 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, principalmente desde la Gestión de Incidencias y Errores. De esta manera, 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. Asimismo, la Gestión de Problemas puede hacer un seguimiento del histórico de errores, establecer relaciones y determinar con mayor facilidad las causas de los mismos.

• La Gestión de Cambios aportará documentación sobre las propuestas de cambio llegadas desde la fase de Mejora Continua del Servicio, tanto si han sido preaprobadas como si se han desechado.

• La información relativa a las posibles consecuencias del error, que puede proporcionar al Centro de Servicios la posibilidad de anticiparse al cliente.

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

Nota: Las interacciones y funcionalidades de la Gestión del Conocimiento se resumen sucintamente en el siguiente interactivo:


Pág. 148/321

Introducción y Objetivos La Gestión del Conocimiento es la encargada de reunir, analizar, almacenar y compartir el conocimiento e información de la organización. El objetivo principal del proceso consiste en mejorar la eficiencia, reduciendo la necesidad de redescubrir el conocimiento. La Gestión del Conocimiento contribuye a mejorar la calidad de las decisiones que se adoptan en una organización, al garantizar que aquellos a quien corresponde tomarlas disponen de información segura y fiable. Sin embargo, una organización puede tener las herramientas adecuadas para registrar y organizar los datos, pero los buenos propósitos pueden no llegar a materializarse nunca si no existe una unidad de Gestión del Conocimiento que impulse, coordine y estructure el proceso para:

• Garantizar que el personal hace uso de las herramientas, tanto para registrar como para consultar los datos disponibles.

• Evaluar los datos recogidos, velando por que estén permanentemente actualizados. • 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, de quienes desempeñan las labores de Gestión del Conocimiento, un entendimiento profundo de los procesos que se desarrollan en la organización, así como una constante monitorización del registro, organización y aprovechamiento de los datos.

Los beneficios obtenidos de una correcta Gestión del Conocimiento son numerosos:

• No se duplica el trabajo innecesariamente. Si surge un problema que ya se presentó en el pasado, pueden recuperarse con facilidad los detalles de la solución aplicada entonces, ahorrando tiempo y esfuerzo.

• Mejor aprovechamiento de los recursos existentes.

• Prevención de situaciones de desinformación en caso de faltar los “propietarios” de los datos de acceso a una aplicación, de contacto con un cliente, etc.

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 miembros del personal no confían en los datos registrados, de modo que recurren a otras vías a la hora de buscar información.

• Los datos están mal estructurados, son incompletos o no están adaptados a la audiencia a la que van destinados, por lo que en la práctica resultan inservibles.

• Los datos se registran pero no se revisan, por lo que la información disponible está desactualizada o incompleta.

Conceptos básicos 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, procesamiento y gestión para interactuar con la Base de Datos de Gestión del Conocimiento del Servicio de la organización IT. Un SKMS está estructurado de forma estratificada, 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. Es la interfaz que permite buscar, explorar, almacenar, 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, vista de Activos y Configuración, etc.


Pág. 149/321

• Capa de procesamiento de conocimiento. Las funciones asociadas a esta capa incluyen el análisis de los datos, la elaboración de informes, la planificación, el modelado de los datos y la monitorización de los cambios a través de paneles de control.

• Capa de Integración de la Información. Es donde está la Base de Datos de Gestión, propiamente dicha, y donde se desarrollan todas las actividades de integración de datos: minería de datos, gestión de metadatos, sincronización, etc.

• Herramientas y fuentes de datos e informació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. Esta estructura es un reflejo del modo en que la Gestión del Conocimiento procesa y transforma los Datos en Saber, que es lo relevante en la toma de decisiones.

• Los Datos consisten en mediciones cuantificables y objetivas.

• Al aportar contexto a los datos (contrastando con otras fuentes de datos, interpretándolos, etc.) obtenemos Información.

• El Conocimiento se alcanza al completar la información con las experiencias, ideas y juicios de cada individuo.

• El Saber, por último, radica en tomar las decisiones adecuadas aplicando el conocimiento y el sentido común. Los Datos, la Información y el Conocimiento pueden ser registrados en bases de datos, y por lo tanto ser consultados y transferidos. El Saber, sin embargo, no puede ser capturado puesto que se refiere a la capacidad individual para hacer juicios válidos y tomar decisiones correctas.

Proceso 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: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 150/321

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.


Pág. 151/321

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.


Pág. 152/321

PPPUUUEEESSSTTTAAA EEENNN MMMAAARRRCCCHHHAAA

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 consecuentes cambios 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:

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

• Supervisando y documentando todo el proceso.


Pág. 153/321

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


Pág. 154/321

RRREEELLLAAACCCIIIÓÓÓNNN CCCOOONNN OOOTTTRRROOOSSS CCCIIICCCLLLOOOSSS 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. Por otro lado la Transición del Servicio debe colaborar, en aquello que le corresponde, a dar soporte a la perspectiva y posicionamiento del servicio establecidos en la fase de estrategia. 2. 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. 3. 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, 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.

• La información relativa a los procesos de prueba y evaluación. 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, rendimiento y rentabilidad de estos y la consecuente percepción de clientes, usuarios y organización TI. La fase de Transición es clave en este aspecto. Los cambios son la fuente principal de incidencias y problemas tanto a nivel interno (componente tecnológica) como a nivel externo (calidad del servicio). 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.


Pág. 155/321


Pág. 156/321


Pág. 157/321

OOOPPPEEERRRAAACCCIIIÓÓÓNNN DDDEEELLL SSSEEERRRVVVIIICCCIIIOOO La fase de Operación del Servicio es, sin duda, la más crítica entre todas. La percepción que los clientes y usuarios tengan de la calidad de los servicios prestados depende en última instancia de una correcta organización y coordinación de todos los agentes involucrados. Todas las otras fases del Ciclo de Vida del Servicio tienen como objetivo último que los servicios sean correctamente prestados aportando el valor y la utilidad requerida por el cliente con los niveles de calidad acordados. Es evidente que de nada sirve una correcta estrategia, diseño y transición del servicio si falla la “entrega”. Por otro lado es prácticamente imposible que la fase de Mejora Continua del Servicio sea capaz de ofrecer soluciones y cambios sin toda la información recopilada durante la fase de operación. Los principales objetivos de la fase de Operación del Servicio incluyen:

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

• Dar soporte a todos los usuarios del servicio. • Gestionar la infraestructura tecnológica necesaria para la prestación del servicio.

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

La estabilidad es necesaria pues los clientes requieren disponibilidad y muestran resistencias al cambio. Por otro lado las necesidades de negocio cambian rápidamente y eso requiere habitualmente rapidez en las respuestas. Normalmente los cambios correctamente planificados no tienen que afectar a la estabilidad del servicio pero esto requiere la colaboración de todos los agentes implicados en la Operación del Servicio que deben aportar el feedback necesario. Para evitar los problemas de inestabilidad es conveniente adoptar una actitud proactiva que permita dar respuestas a las nuevas necesidades de negocio de una forma progresiva. La actitud reactiva provoca que los cambios sólo se implementen cuando la organización TI se ve obligada a responder a estímulos externos lo que usualmente provoca un estado de “urgencia” que no es conducente a una correcta planificación del cambio. Es también esencial encontrar un correcto equilibrio entre los procesos de gestión internos orientados a gestionar y mantener la tecnología y recursos humanos necesarios para la prestación del servicio y las demandas externas de los clientes. La organización TI no debe comprometerse en la prestación de servicios para los que carezca de capacidad tecnológica o los necesarios recursos humanos ni tampoco caer en el error de engordar en exceso la infraestructura TI encareciendo innecesariamente el coste de los servicios prestados.

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

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

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

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


Pág. 158/321

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

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


Pág. 159/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE EEEVVVEEENNNTTTOOOSSS

Visión general Una vez que el servicio está operando es necesario monitorizar todos los sucesos importantes que se produzcan para poder anticiparse a los problemas, resolverlos o incluso prevenirlos. Esta función representa una tarea en sí misma y por tanto constituye un proceso independiente dentro del ciclo de vida: la Gestión de Eventos. A efectos de la operación del servicio, se denomina evento a todo suceso detectable que tiene importancia para la estructura de la organización TI, para la prestación de un servicio o para la evaluación del mismo. Ejemplos típicos de eventos son las notificaciones creadas por los servicios, los elementos de configuración o las herramientas de monitorización y control. Un aspecto clave en la Gestión de Eventos es, como resulta evidente, una buena monitorización y unos efectivos sistemas de control. Encontramos dos tipos:

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

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

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

• Eventos que indican que el servicio está operando con normalidad. • Eventos que indican una excepción.

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

• La Gestión de Eventos, además de detectar y notificar los sucesos, se encarga de clasificarlos y dimensionar su impacto en el servicio. Llegado el caso, se ocupa también de documentar el evento y derivarlo al proceso correspondiente para que tome medidas: A la Gestión de Incidencias, en caso de que el evento suponga una interrupción no planificada del servicio o fallos en uno o más CIs.

• A la Gestión de Problemas, si una incidencia se repite a menudo y no se conoce la causa que la provoca. Y también envía a la Gestión de Cambios, a través de la Mejora Continua del Servicio, nuevas solicitudes de cambio basadas en la correlación de eventos. Nota: Las propiedades y funcionalidades de la Gestión de Eventos se resumen sucintamente en el siguiente interactivo:


Pág. 160/321

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

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

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

• Contribuyendo a la Mejora Continua del Servicio mediante informes de mejora. Algunas de las ventajas que una correcta Gestión de Eventos aporta a la organización TI son:

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

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

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

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

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

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

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

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

• Adquirir las habilidades necesarias exige tiempo y dinero.


Pág. 161/321

Proceso Las actividades de la Gestión de Eventos son:

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

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

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

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

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

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

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

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

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Eventos: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.

Aparición de eventos El flujo de trabajo del proceso de Gestión de Eventos se inicia cuando aparece un evento. Los eventos ocurren continuamente, pero no todos son detectados o registrados. Por ello, es importante que todos los implicados en el diseño, desarrollo, gestión y soporte de los servicios IT y la infraestructura IT comprendan cuáles son los eventos que es preciso detectar.

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


Pág. 162/321

• Una herramienta de gestión demanda periódicamente determinados datos a un dispositivo del CI. • El propio CI genera un informe al darse unas determinadas condiciones definidas previamente.

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

En general, cuanta más información acerca del evento quede recogida en la notificación, y cuanto mejor se determine el destinatario de dicha información, más fácil resultará tomar decisiones respecto al mismo. A menudo, se registran mensajes de error codificados y el personal encargado de resolver los problemas no alcanza a comprender su significado completo. Si los roles y responsabilidades no han sido bien definidos desde la fase de Diseño, es muy probable que cuando se presente un evento que requiera una respuesta, nadie sepa quién está haciendo qué. En tal caso, hay que redactar una RFC.

Detección y filtrado de eventos Una vez generada la notificación, ésta llega a su destinatario, que puede ser un agente que trabaje sobre el sistema o bien una herramienta de gestión diseñada específicamente para recibir los datos relacionados con el evento e interpretarlos. El filtrado consiste en decidir si el suceso merece una consideración en profundidad por parte de otra unidad de gestión o si por el contrario, una vez leído puede ser ignorado. Por ejemplo, cuando se trata de un grupo de notificaciones relacionadas que se emiten de forma seriada, es habitual optar por transmitir sólo la primera. En otros CIs, en cambio, todos los eventos son significativos y se trasladan directamente a un sistema de correlación automatizado, incluso aunque la notificación esté duplicada.

Clasificación de eventos No todos los eventos son iguales ya que no tienen la misma importancia para el servicio ni la infraestructura TI y por tanto, no deben tratarse de la misma manera. La mejor manera de asignar distintas prioridades a cada evento, pero que al mismo tiempo guarden cierta coherencia, es confeccionar una clasificación de eventos. Lo más habitual es que cada organización TI disponga de su propia categorización, ya que es lo más eficaz. Sin embargo, existen tres categorías que no pueden faltar:

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

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

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

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

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

• Si existe alguna acción asociada al evento.


Pág. 163/321

• Si el evento representa una excepción. • Comparación de la cantidad de información utilizada en el evento respecto a un estándar.

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

• Categorización asignada al evento. • Nivel de prioridad asignado al evento.

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

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

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

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

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

• Notificaciones por teléfono móvil.

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

Opciones de respuesta Existen numerosas respuestas posibles a la hora de actuar frente a un evento. Entre las más comunes están:

• Registro de eventos. Independientemente de las acciones que se lleven a cabo, se documenta lo ocurrido.

• Respuesta automática. En algunos casos, se pueden programar respuestas automáticas a determinados eventos que la organización TI conoce en profundidad. Por ejemplo: reiniciar un dispositivo, cambiar un parámetro, bloquear una aplicación para evitar accesos no autorizados, etc.

• Alerta e intervención humana. La alerta tiene como objeto advertir e informar a la persona más cualificada para que desempeñe una acción específica, probablemente en un tiempo determinado y en un dispositivo concreto.

• Emisión de una solicitud de cambio (RFC). Las solicitudes de cambio pueden crearse en cuanto ocurre la excepción o en el momento en que la actividad de Correlación concluye que es necesario hacer cambios.

• Apertura de un registro de incidencia. Al igual que con la RFC, el registro de incidencias puede efectuarse en cuanto se detecta la excepción o cuando la Correlación lo considera necesario.

• Apertura de un vínculo a un registro de problema. Los problemas suelen estar asociados a uno o más incidentes. Esto ayuda al equipo encargado de la Gestión de Problemas para determinar el impacto y la severidad del problema.

Estas respuestas no tienen por qué darse de manera aislada, es decir, que la organización puede combinar dos o más de ellas para ofrecer una solución más completa al evento. Puede presentarse el caso de un evento que representa una excepción pero que no tiene un impacto directo en el servicio. Se trata de incidentes especiales en los que el registro debe hacerse de acuerdo a un Modelo de Incidentes, pero que no tienen ninguna influencia en el rendimiento al no ocasionar interrupciones del servicio.


Pág. 164/321

Revisión de acciones y cierre Antes de dar por terminado el proceso de Gestión de Eventos, es preciso revisar todas las excepciones o eventos importantes para garantizar que se han tratado correctamente.

Control del proceso A la hora de evaluar la eficiencia y efectividad del proceso de Gestión de Eventos deben verificarse los siguientes indicadores:

• Número de eventos, por categorías.

• Número de eventos, por importancia. • Número y porcentaje de eventos que requirieron de intervención humana y cómo fue esa intervención.

• Número y porcentaje de eventos que desembocaron en el registro de una nueva incidencia o solicitud de cambio.

• Número y porcentaje de eventos ocasionados por problemas ya existentes o errores conocidos. • Número y porcentaje de eventos repetidos o duplicados. Esto es relevante para optimizar la función de

Correlación.

• Número y porcentaje de eventos relacionados con problemas de rendimiento.

• Número y porcentaje de eventos que indican futuros problemas de disponibilidad. • Número y porcentaje de cada tipo de evento, por plataforma o aplicación.

• Número y ratio de eventos por comparación al número de incidentes.


Pág. 165/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE IIINNNCCCIIIDDDEEENNNCCCIIIAAASSS

Visión general La Gestión de Incidencias tiene como objetivo resolver, de la manera más rápida y eficaz posible, cualquier incidente que cause una interrupción en el servicio. La Gestión de Incidencias no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas. Por otro lado, también es importante diferenciar la Gestión de Incidencias de la Gestión de Peticiones, que se ocupa de las diversas solicitudes que los usuarios plantean para mejorar el servicio, no cuando éste falla. Las propiedades y funcionalidades de la Gestión de Incidencias se resumen sucintamente en el siguiente interactivo:

Introducción y Objetivos Los objetivos principales de la Gestión de Incidencias son:

• Detectar cualquier alteración en los servicios TI. • Registrar y clasificar estas alteraciones.

• Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente. Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios debe jugar un papel esencial en el mismo.


Pág. 166/321

El siguiente diagrama resume el proceso de Gestión de Incidencias:

Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software, según el libro de Soporte del Servicio de ITIL una incidencia es: “Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar,

una interrupción o una reducción de calidad del mismo”. Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, a excepción las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios. Los principales beneficios de una correcta Gestión de Incidencias incluyen:

• Mejorar la productividad de los usuarios.

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

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

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

• Y principalmente: mejora la satisfacción general de clientes y usuarios. Por otro lado una incorrecta Gestión de Incidencias puede acarrear efectos adversos tales como:

• Reducción de los niveles de servicio.

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

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

• Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidencias. Las principales dificultades a la hora de implementar la Gestión de Incidencias se resumen en:

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

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


Pág. 167/321

Conceptos básicos Clasificación y Registro Es frecuente que existan múltiples incidencias concurrentes, por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas. La priorización se basa esencialmente en dos parámetros:

• Impacto: determina la importancia de la incidencia dependiendo de cómo ésta afecta a los procesos de negocio y/o del número de usuarios afectados.

• Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución de la incidencia y/o el nivel de servicio acordado en el SLA.

También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes. Dependiendo de la prioridad, se asignarán los recursos necesarios para la resolución de la incidencia. La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones. Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:

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

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

ITIL V.3

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

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

El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, en el caso de PYMES, integrar diferentes niveles.

Manual Técnico

rárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapan de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución

e resumirse gráficamente* como sigue:

El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, en el caso de PYMES, integrar

Pág. 168/321

rárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapan de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución

El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, en el caso de PYMES, integrar


Pág. 169/321

Proceso El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidencias: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI

Registro y Clasificación Registro La admisión y registro de la incidencia es el primer y necesario paso para una correcta gestión del mismo. Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros. El proceso de registro debe realizarse inmediatamente, pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.

• La admisión a trámite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.

• Comprobación de que ese incidente aún no ha sido registrado: es muy habitual que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.

• Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente, tanto en los procesos internos como en las comunicaciones con el cliente.

• Registro inicial: se ha de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).


Pág. 170/321

• Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que puede ser obtenida de la propia CMDB (hardware interrelacionado), etc.

• Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios, éstos deben ser notificados para que conozcan cómo esta incidencia puede afectar su flujo habitual de trabajo.

• Clasificación La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser utilizada para la resolución del mismo. El proceso de clasificación debe implementar, al menos, los siguientes pasos:

• Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.

• Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.

• Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia, designará al personal de soporte técnico responsable de su resolución (segundo nivel).

• Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.

Análisis, Resolución y Cierre En primera instancia, se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado. Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente, se seguirán los protocolos de escalado predeterminados. Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo. Si fuera necesario, paralelamente a la resolución de la incidencia se puede emitir una Petición de Cambio (RFC) que se enviaría a la Gestión de Peticiones. Por otro lado, si la incidencia fuera recurrente y no se encontrase una solución definitiva, se deberá informar a la Gestión de Problemas para el estudio detallado de las causas subyacentes. Cuando se haya solucionado el incidente se:

• Confirma con los usuarios la solución satisfactoria del mismo.

• Incorpora el proceso de resolución al SKMS. • Reclasifica el incidente si fuera necesario.

• Actualiza la información en la CMDB sobre los elementos de configuración (CIs) implicados en el incidente.

• Cierra el incidente.

Control proceso La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidencias. Estos informes deben aportar información esencial para, por ejemplo:


Pág. 171/321

• La Gestión de Niveles de ServicioLa Gestión de Niveles de ServicioLa Gestión de Niveles de ServicioLa Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.

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

• Optimizar la asignación de recursosOptimizar la asignación de recursosOptimizar la asignación de recursosOptimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.

• Identificar erroresIdentificar erroresIdentificar erroresIdentificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente, por lo que se deberán tomar medidas correctivas.

• Disponer de Información EstadísticaDisponer de Información EstadísticaDisponer de Información EstadísticaDisponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidencias requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:

• Un correcto sistema automatizado de registro de incidentes y relación con los clientes Un SKMS que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Un SKMS actualizado permite:

• Evitar escalados innecesarios.

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

• Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una extranet, lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.

• Una CMDB que permita conocer todas las configuraciones actuales y el impacto que éstas puedan tener en la resolución del incidente.

Para el correcto seguimiento de todo el proceso, es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:

• Número de incidentes clasificados temporalmente y por prioridades.

• Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes. • Nivel de cumplimiento del SLA.

• Costes asociados.

• Uso de los recursos disponibles en el Centro de Servicios. • Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de

Servicios.

• Grado de satisfacción del cliente.


Pág. 172/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE PPPEEETTTIIICCCIIIOOONNNEEESSS

Visión general La Gestión de Peticiones, como su nombre indica, es la encargada de atender las peticiones de los usuarios proporcionándoles información y acceso rápido a los servicios estándar de la organización TI. Es importante aclarar qué entendemos por petición de servicio, un concepto que engloba las solicitudes que los usuarios pueden plantear al departamento de TI:

• Solicitudes de información o consejo. • Peticiones de cambios estándar (por ejemplo cuando el usuario olvida su contraseña y solicita una nueva)

• Peticiones de acceso a servicios IT. La Gestión de Peticiones recibe las siguientes entradas para poder iniciar su labor:

• Peticiones de servicio, planteadas por los usuarios. • RFCs, también de la misma fuente.

• Descripción detallada del servicio, proporcionada por el Portfolio de Servicios.

• Políticas de Seguridad, de la Gestión de Seguridad. Las principales razones que respaldan la implementación del proceso de Gestión de Peticiones en la organización TI son:

• Proporciona al departamento comercial un acceso rápido y efectivo a servicios estándar. Esto mejora su productividad, la calidad de los servicios comerciales y los propios productos.

• Reduce la burocracia asociada al proceso de petición de acceso a servicios nuevos o ya existentes, reduciendo asimismo los costes.

• Incrementa el nivel de control sobre los servicios al centralizar la concesión de acceso a los mismos.

• Reduce costes al centralizar la negociación con proveedores respecto al acceso a los servicios, y también al reducir el coste del soporte.

Las propiedades y funcionalidades de la Gestión de Peticiones se resumen sucintamente en el siguiente interactivo:


Pág. 173/321

Introducción y Objetivos Los objetivos de la Gestión de Peticiones incluyen:

• Proporcionar un canal de comunicación a través del cual los usuarios puedan solicitar y recibir servicios estándar para los que existe una aprobación previa.

• Proporcionar información a los usuarios y clientes sobre la disponibilidad de los servicios y el procedimiento para obtenerlos.

• Localizar y distribuir los componentes de servicios estándar solicitados. • Ayudar a resolver quejas o comentarios ofreciendo información general.

Las dificultades y desafíos a los que se puede enfrentar la Gestión de Peticiones son:

• A la hora de documentar y definir claramente el tipo de peticiones que van a ser gestionadas.

• Al establecer funcionalidades de autoayuda para que los usuarios interactúen mejor con el proceso de envío de peticiones.

• Si el alcance del proceso de Gestión de Peticiones no está bien definido, las personas implicadas no tendrán una idea clara sobre cómo se desarrollará.

• Si las interfaces de envío de peticiones tienen un diseño pobre o la implementación no es correcta, resultará muy complicado a los usuarios remitir sus sugerencias, quejas, etc.

• Si las aplicaciones de gestión interna no son adecuadas, la Gestión de Peticiones puede ver disminuida considerablemente su capacidad para asumir gran cantidad de trabajo.

• Una monitorización insuficiente o ineficaz.

Proceso Las actividades incluidas en el proceso de Gestión de Peticiones son:

• Selección de peticiones. Los usuarios, a través de las herramientas destinadas a tal fin por la Gestión de Peticiones, emiten sus peticiones conforme a una serie de tipologías predefinidas.

• Aprobación financiera de la petición. Dado que la mayoría de peticiones tienen implicaciones financieras, se considera su coste y se decide si tramitar la petición o no.

• Tramitación. La petición es cursada por la persona o personas adecuadas según cada caso. • Cierre. Tras notificar al Centro de Servicios y comprobar desde aquél que el usuario ha quedado conforme con

la gestión se procede a cerrarla. El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Peticiones: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.


Pág. 174/321

Selección de peticiones de un menú La Gestión de Peticiones hace posible que los propios usuarios emitan sus peticiones de servicio a través de una interfaz web. En ella, el cliente podrá escoger de entre las “peticiones tipo” predefinidas la que más se ajusta a su caso. Esto se puede combinar con otras herramientas destinadas a enviar la petición directamente al equipo de back-end.

Aprobación financiera La mayoría de las peticiones conllevan un gasto, independientemente de los acuerdos financieros en vigor. Por eso, antes de autorizar una petición es principal determinar primero los costes que ésta acarreará de ser cursada. Se pueden definir, para determinadas peticiones estándares, unos precios fijos que ayuden a gestionar con rapidez aquellos casos más frecuentes.

Tramitación y cierre Esta actividad consiste en cursar la propia petición, por lo que las acciones a desempeñar dependerán de la naturaleza de la misma. El Centro de Servicios puede encargarse de las más simples, mientras que otras precisarán de una intervención especializada. Algunas organizaciones disponen de grupos de expertos para cursar cada tipo de petición, o incluso derivan ciertas actividades a proveedores externos. El Centro de Servicios, independientemente de si la unidad que tramita la petición es interna o externa, debe monitorizar todo el proceso y perseguir nuevos progresos. Una vez resuelta la petición, se notifica al Centro de Servicios para que compruebe si el usuario está satisfecho con el resultado y proceda a su cierre.

Control del proceso

• Número total de peticiones de servicio. • Ruptura de peticiones de servicio en cada etapa.

• Tamaño de la copia de seguridad de las peticiones más destacadas.

• Tiempo medio que dura la gestión de cada tipo de petición de servicio. • Número y porcentaje de peticiones de servicio completadas en los tiempos acordados.

• Coste medio de cada tipo de petición de servicio.

• Nivel de satisfacción del cliente con la gestión de las peticiones de servicio.


Pág. 175/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE PPPRRROOOBBBLLLEEEMMMAAASSS

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

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

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

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

La Gestión de Problemas puede ser:

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

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

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

Introducción y Objetivos Como se explicó en la sección de Gestión de Incidencias, esta última tiene como exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar cuáles han sido los orígenes y causas del mismo. Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI, es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.


Pág. 176/321

Cabe diferenciar entre:

• Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa.

• Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas. Los principales conceptos involucrados en el proceso de Gestión de Problemas y su relación con la Gestión de Incidencias se resumen en el siguiente interactivo:

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

• Identificar, registrar y clasificar los problemas. • Dar soporte a la Gestión de Incidencias, proporcionando información y soluciones temporales o parches.

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

• Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI. • Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.

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

• Analizar tendencias para prevenir incidentes potenciales. Los principales beneficios de una correcta Gestión de Problemas:

• Un aumento de la calidad general de los servicios TI.

• Se minimiza el número de incidentes.


Pág. 177/321

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

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

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

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

• Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los agentes implicados y la supervisión de los responsables de la infraestructura TI.

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

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

• Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.

• Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.

Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que éstos se manifiesten provocando un deterioro en la calidad del servicio. El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas: Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI


Pág. 178/321

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

El Control de Problemas se compone en esencia de tres fases: 1. Identificación y Registro Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:

• La Base de Datos de Incidencias: en principio, cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante un workaround (solución temporal) es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.

• Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.

• Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explícita como incidentes.

Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales, informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI. El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto. El registro debe incorporar, entre otras, información sobre:

• Los CIs implicados.

• Causas del problema. • Síntomas asociados.

• Soluciones temporales.

• Servicios involucrados. • Niveles de prioridad, urgencia e impacto.


Pág. 179/321

• Estado: activo, error conocido, cerrado. 2. Clasificación y Asignación de Recursos La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, qué áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo. Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio). Al igual que en la Gestión de Incidencias, la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto. Una vez clasificado el problema y determinada su prioridad, se deben asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI. 3. Análisis y Diagnóstico: Error conocido Los objetivos principales del proceso de análisis son:

• Determinar las causas del problema. • Proporcionar soluciones temporales a la Gestión de Incidencias para minimizar el impacto del problema hasta

que se implementen los cambios necesarios que lo resuelvan definitivamente. Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es frecuente que el problema esté causado por:

• Errores de procedimiento.

• Documentación incorrecta. • Falta de coordinación entre diferentes áreas.

Es también posible que la causa del problema sea un bug bien conocido de alguna de las aplicaciones utilizadas. Por lo tanto, es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión. Una vez determinadas las causas del problema, éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.

Control de Errores Una vez que el Control de Problemas ha determinado las causas de un problema, es responsabilidad del Control de Errores el registro del mismo como error conocido.


Pág. 180/321

Identificación y Registro de errores El registro de los errores conocidos es de vital importancia para la Gestión de Incidencias, pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal (también llamada workaround) que permita minimizar el impacto de los incidentes asociados. Análisis y Solución Se deben investigar diferentes soluciones para el error evaluando en cada momento:

• El posible impacto de las mismas en la infraestructura TI. • Los costes asociados.

• Sus consecuencias sobre los SLAs. En algunos casos en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, puede emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios. Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:

• ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.

• ¿Es la solución provisional aportada suficiente para mantener unos niveles de calidad de servicios aceptable?

• ¿Los beneficios justifican los costes asociados? Sea cual sea la respuesta, toda la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado, se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos. Revisión Post Implementación y Cierre Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR).


Pág. 181/321

Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema, se considera concluido el proceso y se emiten los informes correspondientes. Por último, es indispensable actualizar la Base de Datos de Errores Conocidos (KEDB) para futuras ocasiones. Adicionalmente, en el caso de problemas de carácter grave, todo el proceso se somete a una Revisión de Problemas Graves para prevenir la reaparición del problema.

Control del proceso El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI, y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento. En particular, una buena gestión de problemas debe traducirse en una:

• Disminución del número de incidentes y una más rápida resolución de los mismos.

• Mayor eficacia en la resolución de problemas. • Gestión proactiva, que permita identificar problemas potenciales antes de que éstos se manifiesten o

provoquen una seria degradación de la calidad del servicio.

• La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI.


• Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidencias

• Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.

• Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente pueda permitir adoptar decisiones informadas sobre cambios de proveedores, etc.

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


Pág. 182/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE AAACCCCCCEEESSSOOO

Visión general La Gestión de Acceso a los Servicios TI es el proceso por el cual a un usuario se le brindan los permisos necesarios para hacer uso de los servicios documentados en el Catálogo de Servicios de la organización TI. En ocasiones recibe el nombre de Gestión de Derechos o Gestión de identidades. La Gestión de Acceso a los Servicios TI se relaciona con algunos procesos de la fase de Diseño:

• La Gestión de la Seguridad establece las políticas de seguridad que luego la Gestión de Acceso debe tener en cuenta a la hora de otorgar el acceso a los servicios TI.

• El Catálogo del Servicio aporta la documentación sobre los servicios cuyo acceso solicitan los usuarios.

• También se relaciona con otros procesos de la fase de Operación, como es el caso de la Gestión de Peticiones o el Centro de Servicios, procesos desde los cuales pueden llegar solicitudes de acceso a servicios.

Asimismo, proporciona información de salida para:

• Gestión de Incidencias, que se hará cargo de aquellas peticiones de acceso o actividades relacionadas con los accesos que representen una excepción.

• Gestión Técnica y Gestión de Aplicaciones, que deben monitorizar los accesos y comprobar si son autorizados o no.

Las propiedades y funcionalidades de la Gestión de Acceso a los Servicios TI se resumen sucintamente en el siguiente interactivo:

Introducción y Objetivos El objetivo de la Gestión de Acceso a los Servicios TI es otorgar permisos de acceso a los servicios a aquellos usuarios autorizados e impedírselo a los usuarios no autorizados. En una palabra, es la puesta en práctica de las políticas y acciones definidas en la Gestión de la Seguridad y la Gestión de la Disponibilidad.


Pág. 183/321

La Gestión de Acceso a los Servicios TI proporciona una serie de ventajas a la organización TI que justifican su implantación:

• Mayor garantía de confidencialidad de la información, gracias a un acceso controlado a los servicios. • Mayor efectividad de los empleados, al minimizarse los conflictos y problemas derivados de la asignación de

permisos.

• Menor probabilidad de errores en servicios críticos relacionados con la actividad de usuarios no cualificados.

• Capacidad de monitorizar el uso de los servicios y detectar casos de abuso de los mismos. • Mayor rapidez y eficacia al revocar permisos en caso de ser necesario, algo que puede ser crítico para la

seguridad en determinadas circunstancias.

• La Gestión de Acceso puede, además, ser un requisito indispensable para la adecuación a determinados estándares de calidad e incluso, a la legislación vigente (en el sector sanitario, por ejemplo).

Los principales retos a que se enfrenta habitualmente la Gestión de Acceso a los Servicios TI son:

• Verificar la identidad de los usuarios. • Verificar la identidad de la persona u organismo que autoriza la asignación de permisos.

• Verificar que el usuario está solicitando el acceso a un determinado servicio.

• Integrar múltiples niveles de permisos para un usuario concreto. • Determinar con rapidez y fiabilidad el nivel de permisos del usuario en cualquier momento.

• Gestionar cambios en los requisitos de acceso de los usuarios.

• Restringir los permisos de acceso a los usuarios no autorizados. • Mantener una base de datos actualizada donde figuren todos los usuarios y los derechos de los que gozan.

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

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

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

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

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

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

Petición de acceso La petición de acceso puede llegar a través de numerosas vías:

• Una petición estándar generada por el sistema de Recursos Humanos. Por ejemplo, al contratar a una persona, al ascenderla, transferirla o cuando abandonan la empresa.

• Una solicitud de cambio (RFC). • Una petición de servicio enviada por la Gestión de Peticiones.

• Al ejecutar una tarea automática previamente autorizada.

• Las reglas para establecer las peticiones de acceso normalmente están documentadas en el Catálogo de Servicios.


Pág. 184/321

Verificación

La Gestión de Acceso debe verificar cada petición desde dos perspectivas:

• El usuario que solicita el acceso, ¿es realmente quien dice ser?

• ¿Tiene un motivo válido para usar el servicio? El primer punto se comprueba, habitualmente, comprobando el nombre y la clave del usuario. En la mayor parte de organizaciones, estos datos bastan para acreditar al usuario, aunque depende de las políticas de seguridad y de lo sensible que sea la información registrada en el sistema del servicio (p.ej. datos biométricos). El segundo punto requiere una comprobación paralela e independiente de la que aporta el usuario. En caso de que se trate de un nuevo empleado, por ejemplo, será necesaria una notificación por escrito procedente del departamento de Recursos Humanos.

Monitorización de identidad A medida que los usuarios trabajan en la organización, sus roles van cambiando y, con ellos, sus necesidades de acceso a servicios. Algunos ejemplos de cambios incluyen:

• Cambio de tarea. En este caso, es muy posible el usuario necesite acceso a nuevos servicios, o incluso a otros completamente diferentes.

• Ascensos. Lo más probable es que el usuario requiera niveles de permisos superiores en los mismos servicios a los que ya tenía acceso.

• Dimisión o fallecimiento. Es preciso eliminar por completo el acceso para evitar que la cuenta de usuario se convierta en un agujero de seguridad.

• Jubilación. En muchas organizaciones, los empleados ya retirados todavía conservan el privilegio de acceder a ciertos servicios, como por ejemplo descuentos en sus compras en determinadas plataformas de e-commerce.

• Acción disciplinar. En algunos casos, es posible que la organización necesite restringir el acceso durante un tiempo para evitar que el usuario acceda a determinados servicios. Esta circunstancia debería estar prevista en el sistema de asignación de permisos, evitando así tener que eliminar los derechos y luego crearlos de nuevo.

• Despido. Cuando un empleado es despedido, o cuando se emprenden acciones legales contra un cliente, el acceso debe ser revocado inmediatamente. Además, la Gestión de Accesos, en conjunto con la Gestión de Seguridad, debe tomar medidas para prevenir, detectar y evitar ataques contra la organización procedentes de ese usuario.

La Gestión de Accesos debe comprender en profundidad el ciclo de vida de cada tipo de usuario y documentarlo. Esto puede servir para automatizar el proceso y ahorrar tiempo.

Registro y monitorización de accesos Además de responder a las peticiones, la Gestión de Acceso es responsable de asegurar que los permisos que ha otorgado se están usando apropiadamente. Por este motivo es necesario que la monitorización y control de los accesos esté incluida entre las actividades de las funciones de la Gestión Técnica y Gestión de Aplicaciones y en todos los otros procesos de operación de servicio. En caso de detectarse abusos, habrá que documentar la situación como una excepción y enviarla a la Gestión de Incidencias para que proceda a su resolución. La Gestión de la Seguridad de la Información juega un papel fundamental a la hora de detectar accesos no autorizados y en compararlos con los permisos que se habían asignado desde la Gestión de Accesos.


Pág. 185/321

Si se sospecha que un usuario está vulnerando las normas de acceso, haciendo un uso inapropiado de los recursos o utilizando datos de forma fraudulenta, corresponderá la Gestión de Accesos proporcionar evidencias de los datos, tiempos e incluso contenido al que el usuario tiene acceso en determinados servicios.

Eliminación y restricción de derechos Naturalmente, la Gestión de Acceso no sólo se encarga de otorgar permisos, sino también de revocarlos o limitarlos. Las circunstancias que suelen motivar la eliminación de derechos:

• Fallecimiento.

• Dimisión.

• Despido. • Cambio de roles dentro de la organización, por lo que ya no se necesita acceder al servicio

• Traslado del usuario a otra área donde existe un acceso regional distinto.

Control del proceso La eficacia del proceso de Gestión de Acceso a los Servicios TI puede controlarse mediante los siguientes indicadores:

• Número de peticiones de acceso.

• Instancias de acceso garantizado, por servicio, usuario, departamento, etc.

• Instancias de acceso garantizado por derechos de acceso de departamento o individuo. • Número de incidentes que requirieron la revocación de los permisos de acceso.

• Número de incidentes causados por una configuración incorrecta de los accesos.


Pág. 186/321

FFFUUUNNNCCCIIIOOONNNEEESSS Una función es una unidad especializada en la realización de una cierta actividad y es la responsable de su resultado. Las funciones incorporan todos los recursos y capacidades necesarias para el correcto desarrollo de dicha actividad. Las funciones involucradas en la fase de Operación del servicio son las responsables de que los servicios cumplan los objetivos solicitados por los clientes y de gestionar toda la tecnología necesaria para la prestación de dichos servicios:

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

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

Gestión Técnica: es una unidad funcional que incluye a todos los equipos, grupos y departamentos involucrados en la

gestión y soporte de la infraestructura TI.

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


Pág. 187/321

CCCEEENNNTTTRRROOO DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS

Visión general El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los usuarios y la Gestión de Servicios TI. Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio:

• Registrando y monitorizando incidentes. • Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas.

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

• Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y de Entregas y Despliegues.

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

Introducción y Objetivos Los clientes demandan, cada vez con mayor frecuencia, un soporte al servicio de alta calidad, eficiente y continuo e independiente de su localización geográfica. Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que están recibiendo una atención personalizada y ágil que les ayude a:

• Resolver rápidamente las interrupciones del servicio.

• Emitir peticiones de servicio.

• Informarse sobre el cumplimiento de los SLAs. • Recibir información comercial en primera instancia.

El punto de contacto con el cliente puede tomar diversas formas, dependiendo de la amplitud y profundidad de los servicios ofrecidos:

• Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.

• Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.

• Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización, con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente, ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como:

• Supervisión de los contratos de mantenimiento y niveles de servicio. • Canalización de las Peticiones de Servicio de los clientes.

• Gestión de las licencias de software.

• Centralización de todos los procesos asociados a la Gestión TI. Los principales beneficios de una correcta implementación del Centro de Servicios se resumen en:

• Reducción de costes mediante una eficiente asignación de recursos.

• Una mejor atención al cliente, que repercute en un mayor grado de satisfacción y fidelización del mismo.

• Apertura de nuevas oportunidades de negocio. • Centralización de procesos que mejoran la gestión de la información y la comunicación.


Pág. 188/321

• Soporte al servicio proactivo.

Implementación La implementación de un Centro de Servicios requiere una meticulosa planificación. En primera instancia deben establecerse los siguientes puntos:

• Cuáles son las necesidades. • Cuáles han de ser sus funciones.

• Quiénes serán los responsables del mismo.

• Qué cualificaciones profesionales poseerán sus integrantes. • Si se deben externalizar ciertos servicios como, por ejemplo, el soporte técnico del hardware.

• Qué estructura de Centro de Servicios (distribuido, central o virtual) se adapta mejor a nuestras necesidades y las de nuestros clientes.

• Qué herramientas tecnológicas necesitamos. • Qué métricas determinarán el rendimiento del Centro de Servicios.

Además de estas cuestiones de carácter técnico, es imprescindible ponderar otros aspectos más directamente relacionados con el "factor humano" y que son tan importantes o más que los puramente técnicos para el éxito del Centro de Servicios:

• Establecer estrictos protocolos de interacción con el cliente.

• Motivar al personal encargado de la relación directa con el cliente. • Informar a los clientes de los beneficios de este nuevo servicio de atención y soporte.

• Asegurar el compromiso de la dirección con la filosofía del Centro de Servicios.

• Sondear a los clientes para conocer mejor sus expectativas y necesidades. El objetivo NO es implementar lo más rápidamente posible un Centro de Servicios, sino implantar un Centro de Servicios cuyos objetivos se alineen con nuestros procesos de negocio, mejore la satisfacción de nuestros clientes, optimice la imagen externa de nuestra organización y nos sirva de plataforma para identificar nuevas oportunidades de negocio.

Estructura Como ya se ha comentado anteriormente, el Centro de Servicios es "EL" punto de contacto de toda la organización TI con clientes y usuarios. Es por lo tanto imprescindible que:

• Sea fácilmente accesible. • Ofrezca un servicio de calidad consistente y homogéneo.

• Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con los mismos.

• Sirva de soporte al negocio. • Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica.

Estructura lógica Los integrantes del Centro de Servicios deben:

• Conocer todos los protocolos de interacción con el cliente: guiones, checklists… • Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios.

• Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre cumplimiento de SLAs.

• Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios. • Recibir formación sobre los productos y servicios de la empresa.


Pág. 189/321

Estructura física A la hora de elegir la estructura del Centro de Servicios deben tenerse muy presentes las necesidades del servicio: locales, globales, 24/7, etc. De acuerdo a estos factores, existen distintas opciones que el Centro de Servicios puede adoptar:

• Local • Centralizado

• Virtual

• 24/7 • Especializado

En la práctica, cada organización configurará su Centro de Servicios de acuerdo a sus circunstancias y necesidades particulares. A continuación, profundizaremos en las opciones enumeradas anteriormente: Centro de Servicios Local Un Centro de Servicios Local está ubicado en el mismo lugar donde están los usuarios a los que atiende. Es muy habitual recurrir a este modelo cuando existen diferencias lingüísticas, políticas o culturales entre la organización y sus usuarios.

• Mayor fluidez en la comunicación con los usuarios. • Mayor presencia frente a los usuarios

• En cambio, su mantenimiento es caro y puede darse el caso de que el volumen de trabajo no sea suficiente para justificar el gasto.


Pág. 190/321

Centro de Servicios Centralizado Si se desea ahorrar costes, se pueden concentrar los centros de servicio locales en uno solo y canalizar el contacto con los usuarios a través de una sola estructura central. Sus ventajas principales consisten en:

• Se reducen los costes. • Se optimizan los recursos.

• Se simplifica la gestión. Sin embargo, surgen importantes inconvenientes cuando:

• Los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas, productos y servicios.

• Es preciso dar servicios de mantenimiento on-site.

Centro de Servicios Virtual En la actualidad, y gracias a las rápidas redes de comunicación existentes, la situación geográfica de los Centros de Servicios puede llegar a ser irrelevante. El principal objetivo del Centro de Servicios virtual es aprovechar las ventajas de los Centros de Servicios centralizados y distribuidos. En un Centro de Servicios virtual:

• El conocimiento está centralizado.

• Se evitan duplicidades innecesarias, con el consiguiente ahorro de costes.

• Se puede ofrecer un servicio local sin incurrir en costes adicionales.


Pág. 191/321

• La calidad del servicio es homogénea y consistente.

Centro de Servicios 24/7 Este modelo, también conocido como follow the sun, consiste en ubicar una serie de Centros de Servicios Locales en distintas zonas horarias con el fin de cubrir de forma conjunta las 24 horas del día durante los 7 días de la semana. Esta configuración es adoptada principalmente por organizaciones internacionales. Centros de Servicios Especializados En ciertas organizaciones en las que los Servicios IT son muy específicos, los incidentes relacionados con éstos se derivan a grupos especializados mejor capacitados para resolverlos.

Funciones Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los aspectos de la Gestión de Servicios TI. Sin embargo, no cabe duda de que su función principal consiste en gestionar la relación con los clientes y usuarios, manteniéndoles puntualmente informados de todos aquellos procesos de su interés. A continuación, describimos algunas de las actividades que un Centro de Servicios debería ofrecer para merecer ese nombre: Gestión de Incidentes Independientemente de que la completa gestión de las incidencias requiera la colaboración de otros departamentos y personal, el Centro de Servicios debe ofrecer una primera línea de soporte para la solución de todas las interrupciones de servicio y/o peticiones de servicio que puedan cursar los clientes y usuarios.


Pág. 192/321

Entre sus tareas específicas se incluyen:

• Registro y monitorización de cada incidencia. • Comprobación de que el servicio de soporte requerido se incluye en el SLA asociado.

• Seguimiento del proceso de escalado.

• Identificación de problemas. • Cierre de la incidencia y confirmación con el cliente.

Centro de información El Centro de Servicios debe ser la principal fuente de información de los clientes y usuarios, informando sobre:

• Nuevos servicios.

• El lanzamiento de nuevas versiones para la corrección de errores. • El cumplimiento de los SLAs.

• Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de negocio, evaluar las necesidades de los clientes y su grado de satisfacción con el servicio prestado.

El Centro de Servicios se encuentra en una situación inmejorable para ofrecer también información privilegiada a todos los procesos de gestión de los servicios TI. Es para ello imprescindible que se lleve un adecuado registro de toda la interacción con los usuarios y clientes. Relaciones con los proveedores El Centro de Servicios es, asimismo, responsable de la relación con los proveedores de servicios de mantenimiento externos. Es imprescindible, para ofrecer un servicio de calidad, una estrecha relación entre los responsables externos del mantenimiento y la Gestión de Incidencias, que debe ser canalizada a través del Centro de Servicios.

Control de la unidad La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta, obviamente, no sea responsabilidad exclusiva de éste. Es importante que se intenten establecer métricas bien definidas para medir el rendimiento del Centro de Servicios y la apreciación que los usuarios tienen de éste. En los informes de control se deben considerar aspectos tales como:

• Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax. • Porcentaje de incidentes que se cierran en primera línea de soporte.

• Porcentaje de consultas respondidas en primera instancia.

• Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto. • Cumplimiento de los SLAs.

• Número de llamadas gestionadas por cada miembro del personal del Centro de Servicios.

• Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a los servicios prestados.

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


Pág. 193/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE OOOPPPEEERRRAAACCCIIIOOONNNEEESSS

Visión general La Gestión de Operaciones es la unidad responsable del mantenimiento y la gestión continua de la infraestructura de la organización TI, y se centra especialmente en asegurar que los servicios cumplen los niveles acordados. En otras palabras, podríamos decir que la Gestión de Operaciones engloba todas las actividades del día a día dedicadas al mantenimiento de la infraestructura y a asegurar que los servicios se están prestando con normalidad. A continuación, resumiremos algunos aspectos clave de la Gestión de Operaciones:

• Trabaja para asegurar que un dispositivo, sistema o proceso está funcionando. • Lleva a cabo los planes.

• Está enfocada a las actividades a corto plazo, aunque éstas generalmente se repiten durante un largo periodo de tiempo.

• El equipo que ejecuta estas actividades ha de estar muy especializado, por lo que a menudo requiere de una formación específica.

• Hay una tendencia a establecer acciones repetitivas y fiables para asegurar el éxito de la operación del servicio.

• Es en la Gestión de Operaciones es donde el valor real de la organización se mide y distribuye. • Depende directamente de las inversiones tanto en equipamiento como recursos humanos.

• El valor generado debe superar el coste de la inversión y otros gastos indirectos.

Introducción y Objetivos Los objetivos de la Gestión de Operaciones TI consisten en:

• Mantenimiento del status quo de los procesos y actividades de la organización para alcanzar estabilidad en el día a día.

• Escrutinio regular y mejoras para alcanzar un servicio mejorado con costes reducidos, manteniendo la estabilidad.

• Aplicación rápida de habilidades operacionales para diagnosticar y resolver cualquier fallo que ocurra en las operaciones.Implementación

Esta labor se desarrolla de acuerdo a los estándares de rendimientos definidos durante la fase de Diseño. Los requisitos generales para que la Gestión de Operaciones desempeñe correctamente su trabajo son:

• Comprender en profundidad cómo se emplea la tecnología para prestar servicios.

• Comprender la importancia relativa y el impacto de esos servicios en el negocio.

• Los procedimientos y manuales que delimitan los roles operacionales tanto en la gestión de la tecnología como en la prestación de servicios.

• Disponer de un conjunto de métricas claramente diferenciadas que informen sobre la culminación de objetivos de servicio, y mantengan informados a los gestores TI sobre la eficiencia y efectividad de las Operaciones TI.

• Los equipos de operaciones TI deben comprender exactamente cómo afecta el rendimiento de la tecnología a la prestación de servicios.

• Una estrategia de gasto orientada a equilibrar los requisitos de las distintas unidades de negocio con los ahorros disponibles gracias a la optimización de la tecnología existente o la inversión en nueva tecnología.

• Una estrategia de inversión basada en retorno del valor, más que retorno del gasto.

Estructura


Pág. 194/321

En algunas organizaciones, un solo departamento se ocupa de desarrollar las actividades de la Gestión de Operaciones TI, mientras que en otros algunas actividades se centralizan y otras las asumen otros departamentos especializados de la organización. Las dos funciones de la Gestión de Operaciones, que trataremos en profundidad en el siguiente apartado, suelen conformar estructuras organizacionales por sí mismas:

• Control de Operaciones, cuya plantilla generalmente se organiza en turnos de operadores encargados de asegurar que las tareas rutinarias se llevan a cabo. El Control de Operaciones también desempeña tareas de monitorización y control, para lo que a menudo recurre a unidades específicas como el Puente de Operaciones o un Centro de Operaciones en Red.

• Gestión de Instalaciones, encargada de supervisar el mantenimiento de todo el equipamiento físico. A menudo está ubicada junto a la Gestión Técnica y de Aplicaciones en grandes centros de datos.

Funciones Las actividades de la Gestión de Operaciones TI están íntimamente ligadas con la monitorización y supervisión, al ser ésta la responsable de que la infraestructura de la organización funcione, especialmente en lo que se refiere a la prestación de servicios. A continuación, describimos algunas de las actividades que desarrolla la Gestión de Operaciones TI dentro de la organización: Control de Operaciones El objetivo de esta función consiste, como su propio nombre indica, en supervisar la ejecución y monitorización de la prestación de servicios, así como de los eventos relacionados con la infraestructura de la organización. En esta labor pueden colaborar, como ya se ha dicho, el Puente de Operaciones o el Centro de Operaciones en Red. El Control de Operaciones desempeña las siguientes tareas:

• Gestión de Consolas, que define cómo se va a llevar a cabo la observación central y evalúa la capacidad de monitorización. Con este fin, las consolas son sometidas a ejercicios de monitorización y control de actividades.

• Programación de tareas, que gestiona los trabajos rutinarios o automáticos. • Back-up y restauración de archivos en beneficio de los equipos de Gestión Técnica y de Aplicaciones, así

como de los usuarios.

• Gestión de Impresión y salidas, para la recopilación y distribución de documentos impresos u otros entregables electrónicos.

• Actividades de rendimiento o mantenimiento en beneficio de los equipos de Gestión Técnica o de Aplicaciones. Gestión de Instalaciones Esta función se ocupa de gestionar el entorno físico de la infraestructura TI: el centro de datos, los cuartos de ordenadores, todo el equipamiento energético y de enfriamiento de los mismos, etc. La Gestión de Instalaciones también incluye la coordinación de proyectos de consolidación a gran escala, ya que requieren del despliegue de una infraestructura independiente. En algunos casos, esta función puede subcontratarse, especialmente la gestión del centro de datos.

Control de la unidad El rendimiento de la unidad puede monitorizarse mediante la comprobación periódica de los siguientes indicadores:


Pág. 195/321

• Finalización con éxito de las tareas programadas. • Número de excepciones que se presentaron en las tareas y actividades programadas.

• Número de restauraciones del sistema o de datos requeridas.

• Estadísticas de instalación de equipo, incluyendo el número de elementos instalados por tipo, instalaciones exitosas, etc.

• Métricas del proceso. La Gestión de Operaciones TI ejecuta muchas actividades de otros procesos de la gestión de servicios. Su capacidad para desempeñar este trabajo se cuantificará como parte de las métricas de los otros procesos:

• Tiempo de respuesta a eventos.

• Tiempos de resolución de incidentes. • Número de incidentes relacionados con la seguridad.

• Número de escalado de incidentes y razones.

• Número de cambios implementados y retirados. • Número de cambios no autorizados que se detectaron.

• Número de versiones desplegadas de forma total y exitosa.

• Rastreo de SIPs. • Gasto por comparación al presupuesto.

• Si se delegaron tareas de mantenimiento, entonces las métricas relacionadas con estas actividades también deben reflejar:

• Rendimiento según planificación. • Número de ventanas de mantenimiento superadas.

• Objetivos de mantenimiento alcanzados (número y porcentaje).

• Las métricas relacionadas con el Mantenimiento de Instalaciones son exhaustivas, y suelen incluir: • Costes vs. presupuesto asociado al mantenimiento, construcción, seguridad, reparto, etc.

• Incidentes relacionados con el edificio (p.ej. reparaciones)

• Informes de acceso a las instalaciones. • Número de eventos e incidentes relacionados con la seguridad y cómo se resolvieron.

• Estadísticas de uso eléctrico, especialmente relacionado con cambios en la distribución y las estrategias de responsabilidad ambiental.

• Eventos o incidentes relacionados con el reparto y la distribución.


Pág. 196/321

GGGEEESSSTTTIIIÓÓÓNNN TTTÉÉÉCCCNNNIIICCCAAA

Visión general La Gestión Técnica aporta las habilidades técnicas y los recursos necesarios para dar soporte a la fase de Operación del servicio. La Gestión Técnica también toma parte en el diseño, pruebas, despliegue y mejora de los servicios TI. El papel de la Gestión Técnica es doble:

• Es la responsable del conocimiento técnico y la experiencia relacionada con la gestión de la infraestructura TI. Debe asegurarse de que el conocimiento requerido para diseñar, probar, gestionar y mejorar los servicios TI es identificado, distribuido y perfeccionado.

• Proporciona los recursos reales destinados a dar soporte al ciclo de vida. Así, la Gestión Técnica debe encargarse no sólo de que esos recursos estén disponibles en la fase de Operación, sino también de que tengan el nivel adecuado y de que realmente se estén utilizando.

• Para orientar su labor, la Gestión Técnica toma como base los requisitos definidos en la fase de Estrategia del Servicio, desarrollados en el Diseño del Servicio, validados en la Transición y perfeccionados en la Mejora Continua.

Introducción y Objetivos El objetivo principal de la Gestión Técnica consiste en ayudar en la planificación, implementación y mantenimiento de una infraestructura técnica estable para apoyar los procesos de negocio de la organización mediante:

• Una topología técnica bien diseñada, elástica y económica.

• Uso de habilidades técnicas adecuadas para mantener la infraestructura técnica en condiciones óptimas. • Uso ágil de habilidades técnicas para una diagnosis rápida y resolución de cualquier error técnico que pueda

ocurrir.

Implementación La Gestión Técnica debe procurar que exista un equilibrio entre el nivel de habilidad, la utilización y el coste de los recursos. Se trata de corregir situaciones como, por ejemplo, que se contrate un recurso de alto nivel a un coste elevado y que después sólo se utilice un 10% de sus capacidades. Algunas de las estrategias a emplear para equilibrar el gasto en recursos en Gestión Técnica son:

• Identificar cuándo se necesitan determinadas habilidades de alto nivel

• Contratar a terceros sólo en los momentos puntuales en que se necesitan sus habilidades.

• Montar un equipo táctico que, además de sus tareas propias, desempeñe tareas que requieran habilidades específicas.

Estructura La estructura de la Gestión Técnica depende de las dimensiones de la organización TI. Si ésta es pequeña, a menudo se centralizan las actividades en un solo departamento, mientras que en las de mayor tamaño se subdividen en varios departamentos especializados técnicamente. El criterio principal es, por lo tanto, la especialialización: los trabajadores se agrupan de acuerdo a sus habilidades técnicas, que a su vez dependen de la tecnología que hay que gestionar. Algunos ejemplos de equipos o departamentos de Gestión Técnica:

• Equipo/departamento central

• Equipo/departamento de servidor • Equipo/departamento de almacenamiento de datos

• Equipo/departamento de soporte de redes

• Equipo/departamento de aplicaciones de escritorio


Pág. 197/321

• Equipo/departamento de base de datos • Equipo/departamento de software intermedio

• Equipo/departamento del directorio de servicios

• Equipo/departamento de web • Equipo/departamento de telefonía basada en IP

Funciones Las actividades de la Gestión Técnica engloban: Identificar el conocimiento y experiencia necesarios para prestar servicios y gestionar la infraestructura TI:

• Documentando las habilidades que posee la organización. • Identificando las necesidades de formación.

• Diseñar y desarrollar (aunque no impartir) programas de formación relacionados con los recursos técnicos.

• Formación técnica de los usuarios. • Formación técnica del Centro de Servicios

• Formación técnica de otros equipos del ciclo de vida.

• La Gestión Técnica a menudo participa en la contratación de: • Recursos humanos, en caso de que no se puedan desarrollar las habilidades requeridas (por falta de personal,

de nivel mínimo).

• Vendedores, ya que a menudo los miembros del equipo de la Gestión Técnica son los únicos que saben exactamente los conocimientos técnicos que debe tener un comercial y cómo evaluarlos en los candidatos.

• La Gestión Técnica también se encarga de definir estándares para • Diseñar nuevas arquitecturas, participando además en la definición de las mismas durante las fases de

Estrategia y Diseño.

• Las herramientas de Gestión de Eventos y respuestas “modelo” a ciertos tipos de eventos.

• Estándares de rendimiento que luego serán utilizados por la Gestión de la Disponibilidad y la de la Capacidad. • La Gestión Técnica interviene en el diseño de:

• Nuevos servicios, participando sobre todo en la arquitectura técnica y las actividades necesarias para gestionar la infraestructura.

• Tests de funcionalidad, rendimiento y manejabilidad de servicios. • La Gestión Técnica, como guardiana de todo el conocimiento tecnológico de la infraestructura de la

organización TI, lo pone al servicio del resto de la organización en:

• La Gestión Financiera, identificando el coste de la tecnología y los recursos humanos que intervienen en la prestación de servicios.

• La Gestión de Problemas, ayudando a diagnosticarlos y resolverlos. También contribuye a validar y mantener el KEDB.

• La Gestión de Incidencias y la de Problemas, ayudando a definir los sistemas de codificación de los mismos.

• La Gestión de Incidencias, ya que a menudo los equipos de la Gestión Técnica participan como línea de soporte especializado. También colaboran en la definición de los casos de escalado.

• La Gestión de Cambios, para evaluar las RFCs, muchas de las cuales son ejecutadas a menudo por la Gestión Técnica.

• Asesoramiento sobre riesgos, identificando dependencias y definiendo contramedidas.

• La Gestión Técnica proporciona información al sistema de Gestión de Configuraciones, y en colaboración con la Gestión de Aplicaciones se asegura de que se creen los atributos y relaciones correctas entre CIs, tanto en el despliegue como en el mantenimiento del ciclo de vida de los mismos.

• En la Mejora Continua, ayudando en la tarea de identificar oportunidades de mejora.

• La Gestión Técnica también colabora en la actualización de la documentación del sistema, garantizando que la información está actualizada y es bien conocida por el personal.


Pág. 198/321

• La Gestión Técnica, además, se ocupa de investigar y desarrollar soluciones que ayuden a expandir los servicios, o que simplifiquen los que ya se prestan (reduciendo costes, p.ej.).

Control de la Unidad La Gestión Técnica puede medirse a través de los siguientes indicadores:

• Métricas de los entregables acordados. Esto puede incluir:

• Contribución a logros para el negocio • Porcentajes de transacción y disponibilidad en transacciones de negocio críticas

• Formación del Centro de Servicios

• Resolución de problemas de grabación en la KEDB • Mediciones de la calidad de los entregables

• Instalación y configuración de componentes bajo su control

• Mediciones de procesos. Los equipos de Gestión Técnica se ocupan de ejecutar numerosas actividades de otros procesos de la gestión de servicios, como por ejemplo:

• Tiempos de respuesta medios a eventos y porcentajes de completado de eventos.

• Tiempos de resolución de incidentes en segunda y tercera líneas de soporte.

• Estadísticas de resolución de problemas. • Número de incidentes escalados y razones para esos escalados.

• Número de cambios implementados y retirados.

• Número de cambios no autorizados detectados. • Rendimiento de la tecnología.

• Tiempo promedio entre incidencias de determinado equipamiento.

• Medición de las actividades de mantenimiento. • Formación y desarrollo de habilidades.


Pág. 199/321

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE AAAPPPLLLIIICCCAAACCCIIIOOONNNEEESSS

Visión general La Gestión de Aplicaciones es responsable del soporte y mantenimiento de las aplicaciones que toman parte en la Operación del servicio. Al igual que ocurría con la Gestión Técnica en relación a la infraestructura TI, la Gestión de Aplicaciones también desempeña un doble papel: Es la responsable del conocimiento técnico y la experiencia relacionada con las aplicaciones. Debe asegurarse de que el conocimiento requerido para diseñar, probar, gestionar y mejorar los servicios TI es identificado, distribuido y perfeccionado. Proporciona los recursos reales destinados a dar soporte al ciclo de vida. Así, la Gestión de Aplicaciones debe encargarse no sólo de que esos recursos estén disponibles en la fase de Operación, sino también de que tengan el nivel adecuado y de que realmente se estén utilizando. La Gestión de Aplicaciones participa, además, en las siguientes actividades del ciclo de vida:

• Diseño, prueba y mejora de las aplicaciones.

• La decisión de desarrollar una aplicación o comprársela a un tercero.

• Integrar la Gestión de Aplicaciones en el Ciclo de Vida.

Introducción y Objetivos La Gestión de Aplicaciones tiene como principal objetivo identificar los requisitos funcionales del software de aplicaciones, prestar apoyo en el diseño y desarrollo de dichas aplicaciones y colaborar en el soporte y mejora que siguen a su despliegue. Para lograr este fin, se precisa:

• Aplicaciones bien diseñadas, elásticas y que optimicen costes.

• Garantizar que la funcionalidad requerida está disponible para alcanzar los resultados de negocio deseados. • Organizar las habilidades técnicas adecuadas para mantener aplicaciones operacionales en condiciones

óptimas.

• Uso ligero de habilidades técnicas para una diagnosis rápida y la resolución de cualquier fallo técnico que pueda presentarse.

• La Gestión de Aplicaciones se encarga de que exista un equilibrio entre el nivel de los recursos y su coste.

Implementación Es habitual en las organizaciones TI dividir la Gestión de Aplicaciones en departamentos según el catálogo de aplicaciones. Esto permite una mayor especialización y un soporte más centrado. A pesar de que todos los equipos, departamentos o grupos de Gestión de Aplicaciones desempeñan actividades similares, cada aplicación o conjunto de aplicaciones precisa un conjunto específico de requisitos de gestión y operación, en función de:

• El propósito de la aplicación. Los equipos deben tener en cuenta los objetivos de negocio. • La funcionalidad de la aplicación.

• La plataforma en la que corre la aplicación.

• El tipo/marca de tecnología empleada.

Estructura


Pág. 200/321

Los equipos y departamentos de Gestión de Aplicaciones suelen organizarse según las distintas categorías de aplicaciones a las que dan soporte. Algunos ejemplos típicos son:

• Aplicaciones financieras. • Aplicaciones de mensajería y colaboración.

• Aplicaciones de RRHH

• Aplicaciones de soporte industrial • Aplicaciones de automatización de fuerza de ventas (CRM)

• Aplicaciones de procesamiento de ventas.

• Aplicaciones del centro de llamadas y marketing • Aplicaciones específicas del negocio (sanidad, seguros, banca, etc.)

• Aplicaciones TI, como Centro de Servicios, Sistemas de Gestión de la Empresa (SKMS, CMS), etc.

• Portales web. • Tienda online.

Funciones Mientras la mayoría de equipos/departamentos de Gestión de Aplicaciones se dedican a aplicaciones específicas o conjuntos de ellas, existen ciertas actividades comunes:

• Ayudar a la Gestión Técnica en la tarea de identificar el conocimiento y experiencia necesarios para gestionar las aplicaciones a la hora de prestar servicios TI.

• Diseñar y desarrollar (aunque no impartir) programas de formación destinados al usuario final. Aunque otros equipos o incluso terceros pueden ser quienes la impartan finalmente, la Gestión de Aplicaciones es responsable de que ésta sea adecuada.

• La Gestión de Aplicaciones también interviene en labores de contratación: • En caso de que ciertas habilidades no se puedan desarrollar a nivel interno (por falta de personal o de nivel), la

Gestión de Aplicaciones es la encargada de seleccionar y contratar los recursos adecuados.

• Vendedores, ya que a menudo los miembros del equipo de la Gestión de Aplicaciones son los únicos que saben exactamente los conocimientos técnicos que debe tener un comercial y cómo evaluarlos en los candidatos.

• La Gestión de Aplicaciones también se encarga de definir estándares para • Diseñar nuevas arquitecturas, participando además en la definición de las mismas durante las fases de

Estrategia y Diseño.

• Las herramientas de Gestión de Eventos y respuestas “modelo” a ciertos tipos de eventos.

• Estándares de rendimiento que luego serán utilizados por la Gestión de la Disponibilidad y la de la Capacidad. • La Gestión de Aplicaciones interviene en el diseño de:

• Nuevos servicios, contribuyendo a la definición de la arquitectura técnica y rendimiento estándar, así como en la adecuación a los niveles de servicio preestablecidos. Además, la Gestión de Aplicaciones es responsable de especificar las actividades necesarias para mantener dichas aplicaciones.

• Tests de funcionalidad, rendimiento y manejabilidad de servicios. • La Gestión de Aplicaciones, como guardiana del conocimiento relacionado con las aplicaciones, lo pone al

servicio del resto de la organización en:

• La Gestión Financiera, identificando el coste de las aplicaciones que intervienen en la prestación de servicios.

• La Gestión de Problemas, ayudando a diagnosticar y resolver aquellos que guardan relación con las aplicaciones.

• La Gestión de Incidencias y la de Problemas, ayudando a definir los sistemas de codificación de los mismos.

• La Gestión de Incidencias, ya que a menudo los equipos de la Gestión Técnica participan como línea de soporte especializado. También colaboran en la definición de los casos de escalado.

• La Gestión de Cambios, para evaluar las RFCs, muchas de las cuales son ejecutadas a menudo por la Gestión de Aplicaciones.


Pág. 201/321

• Asesoramiento sobre riesgos, identificando dependencias y definiendo contramedidas. • La Gestión de Aplicaciones es, a menudo, quien dirige el despliegue de las nuevas versiones durante la fase

de Transición.

• La Gestión de Aplicaciones proporciona información al sistema de Gestión de Configuraciones, y en colaboración con la Gestión Técnica se asegura de que se creen los atributos y relaciones correctas entre CIs, tanto en el despliegue como en el mantenimiento del ciclo de vida de los mismos.

• En la Mejora Continua, ayudando en la tarea de identificar oportunidades de mejora. • Colaborar en la actualización de la documentación del sistema, garantizando que la información está

actualizada y es bien conocida por el personal.

• Participar en las actividades operacionales que se llevan a cabo como parte de la Gestión de Operaciones.

• La Gestión de Aplicaciones también contribuye a mantener actualizadas las políticas de configuración de software.

• Investigación y desarrollo de soluciones que ayuden a expandir el Portfolio de Servicios o al menos a mejorar la prestación de los mismos.

• Proporcionar asesoramiento en riesgos, identificando servicios críticos y dependencias de sistema y definiendo e implementando contramedidas.

Control de la unidad Las métricas que reflejan el rendimiento de la Gestión de Aplicaciones dependen de las aplicaciones que se estén gestionando, pero las más típicas son:

• Métricas de los entregables acordados. Esto puede incluir: o Capacidad de los usuarios para acceder a la aplicación y sus funcionalidades. o Reportes y archivos enviados a los usuarios. o Porcentajes de éxito y disponibilidad para determinadas transacciones críticas para el negocio. o Formación del Centro de Servicios. o Registro de resolución de problemas en el sistema de Gestión del Conocimiento. o Percepción que los usuarios tienen de la calidad, en comparación con los requisitos definidos en los SLAs. o Métricas de procesos o Tiempo de respuesta a eventos y porcentajes de finalización. o Tiempos de resolución de incidentes en la segunda y tercera líneas de soporte. o Estadísticas de resolución de problemas. o Número de incidencias escaladas y razones que motivaron su escalado. o Número de cambios implementados y revertidos. o Número de cambios no autorizados que se detectaron. o Número de versiones desplegadas (total y exitosas) o Problemas de seguridad detectados y resueltos o Utilización real del sistema comparada con las previsiones del Plan de Capacidad. o Seguimiento de sesiones. o Gasto en comparación con el presupuesto. o Rendimiento de aplicaciones. Estas métricas se basan en las especificaciones de la fase de Diseño y el

rendimiento técnico contenido en los OLAs. Suelen incluir: o Tiempos de respuesta. o Disponibilidad de la aplicación. o Integridad de los datos e informes. o Métricas de las actividades de mantenimiento. o Mantenimiento llevado a cabo según la planificación. o Número de ventanas de mantenimiento que se prolongaron. o Objetivos de mantenimiento alcanzados (número y porcentaje)


Pág. 202/321

o Probabilidad de la colaboración entre los equipos de Gestión de Aplicaciones y los equipos de Desarrollo de Aplicaciones en proyectos. Métricas de:

o Tiempo invertido en proyectos. o Satisfacción del cliente y el usuario con el entregable del proyecto. o Costes de involucrarse en el proyecto. o Formación y desarrollo de habilidades. Estas métricas garantizan que la plantilla tiene las habilidades y

formación necesarias para gestionar la tecnología de la que son responsables, además de identificar áreas en las que se requiere formación adicional.


Pág. 203/321

PPPUUUEEESSSTTTAAA EEENNN MMMAAARRRCCCHHHAAA Uno de las principales dificultades para la correcta puesta en marcha de la fase de Operación del Servicio reside en el “abismo” existente entre teoría y práctica. Las fases previas del ciclo de vida de los servicios se han preocupado de diseñar, planificar y desplegar una serie de procesos y servicios que ahora han de ponerse en marcha y es frecuente eso conlleve las habituales dificultades:

• Los responsables del diseño no conocen en detalle las complicaciones asociadas a las labores de mantenimiento y tareas recurrentes de la fase de operación con las consiguientes consecuencias indeseables:

• Se toman “atajos” que rompen con las buenas prácticas de gestión. • Se crean resistencias a la aplicación de los protocolos diseñados.

• No se han asignado los recursos necesarios para implementar correctamente la fase de operación y el personal la percibe como una nueva capa “burocrática” que sólo dificulta su trabajo.

• Las estructuras de gestión no son lo suficientemente flexibles y por tanto no son capaces de asimilar la complejidad de los nuevos procesos y actividades.

• Las métricas definidas se centran en exceso en aspectos “internos” de la organización TI y obvian importantes aspectos “externos” relativos a la percepción de los clientes.

Para impedir que todo esto ocurra es imprescindible: Involucrar al personal de operación en el diseño de los servicios. Asegurarse una rápida evaluación del impacto de todos los cambios en la fase de operación. Que el personal a cargo de la fase de operación disponga desde el primer momento de todas las herramientas y tecnología necesarias para desempeñar correctamente su función según los protocolos preestablecidos.

Monitorización y control La monitorización consiste en la observación atenta de una determinada situación con el fin de detectar cambios a lo largo del tiempo. En el contexto de la fase de Operación del servicio, la monitorización implica:

Monitorizar los CIs y actividades clave.

• Asegurarse de que se cumplen las condiciones establecidas y, en caso contrario, advertir al grupo adecuado.

• Asegurar que el rendimiento y utilización de los componentes, sistemas, etc. están dentro de un rango previsto. • Detectar niveles anormales de actividad en la infraestructura.

• Detectar cambios no autorizados.

• Asegurar el cumplimiento de las políticas de la empresa. • Rastrear las salidas al negocio y garantizar que casan con los requisitos de calidad y rendimiento acordados.

• Rastrear cualquier información empleada para medir los KPIs. El modelo más extendido para definir el control es el Ciclo de Monitorización-Control. Este ciclo puede ser de dos tipos: Ciclo Abierto: se programan actividades específicas sin tener en cuenta las condiciones del entorno. Un backup periódico, que se lanza con independencia de las circunstancias, es un buen ejemplo de control de ciclo abierto. Ciclo Cerrado: se monitoriza un entorno con el fin de responder sólo a los cambios que se produzcan. Un ejemplo de esto sería un balance de carga de una red, en el que se ejercen tareas de control sólo si la monitorización indica que se está sobrepasando el tráfico normal.


Pág. 204/321

La monitorización tiene dos niveles de actuación:

• Monitorización y control interno, cuando desde un equipo o departamento se controlan los elementos y actividades de esa misma unidad.

• Monitorización y control exernos, cuando un equipo o departamento realiza el control de elementos y actividades que dependen de otros grupos, procesos o funciones.

Podemos distinguir distintos tipos de monitorización según tres factores:

• Monitorización activa vs. pasiva. La monitorización activa consiste en hacer una comprobación directa del estado de un sistema o dispositivo. La pasiva, en cambio, genera y transmite eventos a un agente de monitorización de forma automática. La pasiva es más frecuente, reservándose la activa para la diagnosis.

• Monitorización reactiva vs. preactiva. La primera está diseñada para ejecutar acciones al producirse cierto tipo de eventos o fallos. La monitorización proactiva, por otro lado, se utiliza para detectar los patrones de eventos que predicen el fallo de un dispositivo.

• Medición continuada vs. basada en excepciones. La medición continua enfoca la monitorización como un registro del rendimiento en tiempo real, mientras que la medición basada en excepciones se limita a notificar las interrupciones.


Pág. 205/321

FFFAAACCCTTTOOORRREEESSS DDDEEE ÉÉÉXXXIIITTTOOO YYY RRRIIIEEESSSGGGOOOSSS Entre los factores de éxito y retos a los que se debe confrontar la correcta implementación de la Fase de Operación del Servicio se encuentran:

• Disponer de personal convenientemente formado sobre los procesos y actividades necesarias para una correcta gestión del servicio.

• Contar con el adecuado soporte tecnológico que facilite y automatice, cuando esto sea posible, las actividades asociadas a la prestación y gestión del servicio.

• Contar con el apoyo necesario de los órganos de dirección de la organización TI para disponer de los recursos y capacidades necesarias.

• Disponer de las métricas adecuadas para evaluar la calidad de la operación del servicio.

• Generar los informes y documentación necesarios para la futura mejora del servicio. • Trabajar en estrecha colaboración con las unidades de negocio para conocer sus necesidades y garantizar que

estas son cubiertas. Los principales riesgos se resumen en:

• Diseños defectuosos del servicio que impiden una operación eficiente.

• Recursos y capacidades insuficientes. • Falta de soporte de la organización TI.


Pág. 206/321

RRREEELLLAAACCCIIIÓÓÓNNN CCCOOONNN OOOTTTRRROOOSSS CCCIIICCCLLLOOOSSS Aunque la fase de Operación del Servicio tenga entidad propia no puede ser correctamente interpretada sin conocer sus interrelaciones con las otras fases del Ciclo de Vida del Servicio. La fase de operación recibe sus inputs principales de la fase de Transición del Servicio y a su vez sirve de principal input a la fase de Mejora del Servicio. 1. OPERACIÓN Y ESTRATEGIA La fase de Operación es la más importante desde el punto de vista del cliente, 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. Por lo tanto un factor esencial en el enfoque estratégico de los servicios es asegurar que son operacionalmente viables. Recíprocamente, 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. 2. OPERACIÓN Y DISEÑO 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.

• Para conseguir estos objetivos los responsables de la Fase de Diseño deben recibir la información necesaria de la Fase de Operación sobre el uso de los servicios y las percepciones de los clientes.

3. OPERACIÓN Y TRANSICIÓN La Operación del Servicio debe suministrar a los responsables de la fase de Transición toda la información relevante sobre:

• El entorno de producción.

• El conocimiento asociado (incidencias, 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.

• La información relativa a los procesos de prueba y evaluación. 4. OPERACIÓN Y MEJORA CONTINUA La fase de Mejora Continua del Servicio depende directamente de la fase de Operación pues ésta representa la principal fuente de información para la optimización de los procesos y actividades involucrados en la prestación del servicio. Los informes generados en la fase de Operación del Servicio deben, en particular, incorporar información detallada sobre:

• Incidencias en la prestación del servicio.

• Soluciones propuestas a los problemas detectados en la fase de operación.

• Peticiones de los usuarios y clientes.


Pág. 207/321


Pág. 208/321


Pág. 209/321

MMMEEEJJJOOORRRAAA CCCOOONNNTTTIIINNNUUUAAA DDDEEELLL SSSEEERRRVVVIIICCCIIIOOO Heráclito de Éfeso dijo hace más de veinticinco siglos que «Ningún hombre puede bañarse dos veces en el mismo río». Si Heráclito fuera en la actualidad el CIO de cualquier empresa hubiera dicho «Ninguna empresa ha de contratar dos veces el mismo servicio». Efectivamente, los tiempos modernos nos exigen continuos cambios y éstos deben tener un solo objetivo en el campo de la gestión de servicios TI: ofrecer mejores servicios adaptados a las siempre cambiantes necesidades de nuestros clientes y todo ello mediante procesos internos optimizados que permitan mayores retornos a la inversión y mayor satisfacción del cliente. Pero este objetivo de mejora sólo se puede alcanzar mediante la continua monitorización y medición de todas las actividades y procesos involucrados en la prestación de los servicios TI:

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

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

• Rendimiento: los procesos son eficientes y rentables para la organización TI. • Valor: los servicios ofrecen el valor esperado y se diferencian de los de la competencia.

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

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

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

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

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

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

• Mejorar la calidad de los servicios prestados.

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

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


Pág. 210/321

CCCIIICCCLLLOOO DDDEEE DDDEEEMMMIIINNNGGG El ciclo PDCA: Planificar (Plan), Hacer (Do), Verificar (Check) y Actuar (Act), también conocido como ciclo de Deming en honor a su creador, Edwards Deming, constituye la columna vertebral de todos los procesos de mejora continua:

• Planificar: definir los objetivos y los medios para conseguirlos.

• Hacer: implementar la visión preestablecida. • Verificar: comprobar que se alcanzan los objetivos previstos con los recursos asignados.

• Actuar: analizar y corregir las desviaciones detectadas así como proponer mejoras a los procesos utilizados. Las fases del ciclo de vida del servicio son un reflejo de esta estructura básica:

En cierta medida todos y cada uno de los procesos de gestión de los servicios TI deben reproducir esa estructura asegurando que cada una de estas fases se encuentra correctamente documentada. La fase de Mejora Continua del Servicio juega un papel esencial en las etapas de verificación y actuación aunque también debe colaborar en las otras etapas de planificar y hacer:

• Ayudando a definir los objetivos y las métricas de cumplimiento asociadas.

• Monitorizando y evaluando la calidad de los procesos involucrados. • Definiendo y supervisando las mejoras propuestas.


Pág. 211/321

MMMÉÉÉTTTRRRIIICCCAAASSS No se puede mejorar aquello que no se conoce y no se puede llegar realmente a conocer aquello que no se puede medir. Es indispensable que la organización TI defina una serie de métricas que permitan determinar si se han alcanzado los objetivos propuestos así como la calidad y rendimiento de los procesos y tareas involucrados. Una organización TI debe utilizar tres tipos de métricas:

• Tecnológicas: que miden la capacidad, disponibilidad y rendimiento de las infraestructuras y aplicaciones.

• De procesos: que miden el rendimiento y calidad de los procesos de gestión de los servicios TI. • De servicios: que evalúan los servicios ofrecidos en términos de sus componentes individuales.

Las métricas deben adaptarse a los Factores Críticos de Éxito (CSFs) que describen aquello que “debe pasar” para que se cumplan los objetivos preestablecidos. Asociados a cada CSF es necesario definir una serie de Indicadores Críticos de Rendimiento (KPIs) que permitan evaluar el rendimiento y la calidad de los procesos así como su valor y adecuación. Los KPIs deben medir aspectos cualitativos y cuantitativos y deben permitir evaluar el cumplimiento de los objetivos. Si la organización TI se ha propuesto, por ejemplo, como CSF la mejora en la atención al usuario los KPIs incluirían:

• Tiempo medio de resolución de los incidentes. • Adecuación de los procesos de escalado.

• Percepción de los usuarios respecto a la atención prestada mediante encuestas de satisfacción. Es importante que los KPIs no obvien aspectos clave y que su cumplimiento sea una medida objetiva del cumplimiento de los CSFs asociados. Por ejemplo, en el caso anterior no se hace mención a los costes y una reducción de los mismos podría ser parte de los objetivos preestablecidos por lo que en ese caso los KPIs utilizados no proporcionarían todas las métricas necesarias.


Pág. 212/321

DDDIIIKKKWWW DIKW es el acrónimo de:

• Datos (Datos (Datos (Datos (DDDData)ata)ata)ata): o materia prima, que está compuesta de mensajes o símbolos sin procesar, por ejemplo, la lista de elementos de configuración de una infraestructura TI.

• Información (Información (Información (Información (IIIInformation)nformation)nformation)nformation): que proviene del análisis de un conjunto de datos, que, por ejemplo, se correspondería en el caso anterior a una distribución de proveedores por inversiones y tecnologías utilizadas.

• Conocimiento (Conocimiento (Conocimiento (Conocimiento (KKKKnowledge)nowledge)nowledge)nowledge): este proviene del proceso de interpretación de la información en términos de experiencia y reflexión. Por ejemplo, ciertos proveedores tecnológicos involucrados en servicios clave corren riesgo por no saberse adaptar al mercado y utilizar tecnologías que pueden tornarse en obsoletas.

• Sabiduría (Sabiduría (Sabiduría (Sabiduría (WiWiWiWisdom)sdom)sdom)sdom): la capacidad de tomar la mejor decisión posible basada en el conocimiento, información y datos disponibles. Por ejemplo, optar por cambiar de proveedor tecnológico para minimizar los riesgos asociados a depender de proveedores que no están correctamente alineados con las necesidades futuras del negocio.

La sabiduría es el componente esencial en lo que respecta al proceso de Mejora Continua. A partir de los datos, información y conocimiento obtenidos durante todas las fases del ciclo de vida del servicio se deben elaborar unos Planes de Mejora que incorporen los cambios necesarios para aumentar la satisfacción del cliente mejorando el rendimiento, calidad y gestión de todos los procesos implicados.


Pág. 213/321

MMMOOODDDEEELLLOOO CCCSSSIII Nunca podremos saber si hemos llegado si primero no decidimos adónde queremos ir. El proceso de Mejora Continua requiere de una serie de metas y objetivos que determinen la dirección de avance y sirvan de pilares para el resto de las actividades involucradas en el mismo. Pero la determinación de esas metas y objetivos está asimismo sometido a un proceso de constante revisión que forma parte de un ciclo descrito por el modelo CSI. Este ciclo continuo se compone de 6 fases:

1. Establecer la visión: se deben establecer metas y objetivos alineados con el modelo de negocio de la organización.

2. Conocer el estado actual: saber de dónde partimos (organización, recursos, capacidades, procesos,…) para poder utilizar ese estado como referencia de base.

3. Establecer objetivos cuantificables: a partir de la visión establecer hitos y entregables que permitan realizar un seguimiento del proceso.

4. Planificar: establecer un Plan de mejora del Servicio (SIP) que determine qué acciones son necesarias para obtener los objetivos deseados en los plazos previstos y con el nivel de calidad predeterminado.

5. Comprobar: determinar si se han cumplido los planes y se han seguido lo procesos establecidos. 6. Integrar los cambios: asegurase de que los cambios realizados forman parte de la cultura de la organización

permitiéndonos así reiniciar el ciclo con nuevo impulso.


Pág. 214/321

HHHEEERRRRRRAAAMMMIIIEEENNNTTTAAASSS YYY MMMEEETTTOOODDDOOOLLLOOOGGGÍÍÍAAASSS Una mejora propuesta no siempre implica una mejora real. Incluso tras exhaustivos procesos de análisis y planificación de las posibles mejoras se han podido obviar aspectos críticos o imponderables que pueden afectar negativamente a los servicios y procesos. Es indispensable disponer de metodologías y herramientas que permitan valorar las mejoras introducidas y comparar el “estado de situación” antes y después de la introducción de los cambios. Es imposible enumerar todas las herramientas y metodologías disponibles por lo que aquí nos centraremos en algunas de las más populares. Éste listado, aunque manisfiestamente incompleto, puede servirnos como punto de partida para ahondar en el tema. Análisis comparativo Consiste en comparar el rendimiento de las actividades y procesos llevados a cabo por la organización con aquellos que han sido considerados como “mejores prácticas”. Este análisis puede ser realizado a distintos niveles:

• Interno: comparando con otros procesos o funciones de la propia organización. • Externo: comparando con otras organizaciones competidoras o directamente con los estándares del sector.

Los resultado de este análisis deben incluir:

• Información sobre el rendimiento de la organización.

• Factores de éxito y riesgos. • Propuestas sobre nuevas líneas de actuación.

Análisis de brechas (Gap analysis) El análisis de brechas se basa en contrastar el “estado de la situación actual” y el “estado esperado o ideal”. Las diferencias entre ambas situaciones suponen las brechas que se desea eliminar. Este análisis se puede realizar a diferentes niveles: estratégico, táctico y operativo. Análisis DAFO Se centra en el análisis de las Debilidades, Amenazas, Fortalezas y Oportunidades. Las Debilidades y Fortalezas son de carácter interno y dependientes en este caso de la propia organización TI mientras que las Amenazas y Oportunidades provienen de factores de mercado u otros factores externos. El análisis DAFO puede realizarse a diferentes niveles, desde una componente o función hasta englobar a toda la

OOORRRGGGAAANNNIIIZZZAAACCCIIIÓÓÓNNN TTTIII ... Sus principales objetivos consisten en:

• Determinar las Debilidades y buscar métodos para eliminarlas. • Valorar las Amenazas e intentar minimizar su impacto.

• Conocer las propias Fortalezas y buscar la mejor manera de rentabilizarlas.

• Estudiar las Oportunidades y desarrollar estrategias que permitan aprovecharlas. Cuadro de Mando Integral (CMI) Es un método diseñado por Robert Kaplan y David Norton para evaluar la actividad de una organización en términos de cumplimiento de su plan estratégico. El Cuadro de Mando Integral (CMI) propone analizar la actividad de una organización respecto a diferentes perspectivas:


Pág. 215/321

• Financiera • Clientes

• Procesos

• Innovación y Aprendizaje Es imprescindible determinar los KPIs asociados a cada una de estas perspectivas y cuáles son los objetivos buscados. Se recomienda buscar un conjunto reducido de KPIs que luego pueda ir ampliándose con el tiempo para evitar CMIs excesivamente complejos que dificulten su implementación.


Pág. 216/321

PPPRRROOOCCCEEESSSOOOSSS Los principales procesos asociados directamente a la fase de Mejora del Servicio son: Proceso de Mejora: este es un proceso que consta de 7 pasos que describen como se deben medir la calidad y rendimiento de los procesos para generar los informes adecuados que permitan la creación de un Plan de Mejora del Servicio (SIP). Informes de Servicios TI: es el responsable de la generación de los informes que permitan evaluar los servicios ofrecidos y los resultados de las mejoras propuestas.


Pág. 217/321

PPPRRROOOCCCEEESSSOOO DDDEEE MMMEEEJJJOOORRRAAA CCCSSSIII

Visión general El Proceso de Mejora Continua (CSI) tiene como misión implementar el ciclo de Deming para la mejora de los servicios TI. El CSI permite a la organización TI:

• Conocer en profundidad la calidad y rendimiento de los servicios TI ofrecidos. • Detectar oportunidades de mejora.

• Proponer acciones correctivas.

• Supervisar su implementación. Para que el CSI sea efectivo tiene, además, que adaptarse a la visión y estrategia del negocio. Sin unos objetivos claros es imposible determinar cuáles han de ser los aspectos prioritarios en el proceso de mejora y la organización TI puede terminar volcando sus esfuerzos en aspectos irrelevantes para el desarrollo del negocio. Las interacciones y funcionalidades de la CSI se resumen sucintamente en el siguiente interactivo:

Introducción y Objetivos El Proceso de Mejora CSI se compone de siete pasos que permiten, a partir de los datos obtenidos, elaborar Planes de Mejora del Servicio que modifiquen procesos o actividades susceptibles de optimización:

• Paso 1: qué debemos medir

• Paso 2: qué podemos medir

• Paso 3: recopilar los datos necesarios. • Paso 4: procesar los datos (información).

• Paso 5: analizar los datos (conocimiento).

• Paso 6: proponer medidas correctivas (sabiduría). • Paso 7: implementar las medidas correctivas.


Pág. 218/321

Es imprescindible tener en cuenta cuál es la visión y estrategia de la organización TI con el objetivo de que aquello que se mide se alinee con las necesidades de negocio. El proceso de medición nunca debe ser un objetivo en sí mismo y debe ser periódicamente revisado para asegurar su continua adecuación a los objetivos marcado por la gestión de los servicios TI. Es necesario contar con referencias que permitan procesar y analizar correctamente los datos obtenidos. Estas referencias pueden ser internas de la organización, datos obtenidos previamente, o externas, como las provenientes de “mejores prácticas” como la propia ITIL.

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

• Decidir qué se debe medir.

• Definir lo que finalmente se medirá.

• Realizar dichas mediciones. • Procesar los datos recogidos.

• Analizar la información recabada.

• Proponer y documentar posibles mejoras en base al conocimiento adquirido. • Implementar las mejoras propuestas.

Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI.


Pág. 219/321

Qué medir Es imposible iniciar el proceso de Mejora Continua sin una idea clara de que es aquello que, en principio, debemos mejorar. Luego, en primera lugar, debemos conocer en profundidad la misión y estrategia previamente trazados por los máximos responsables de la organización TI de acuerdo con las necesidades de negocio. A partir de esa información y de la recogida a través de:

• El catalogo actual de servicios, • Los SLAs en vigor: compromisos alcanzados con nuestros clientes,

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

• Información de carácter legal y financiero, • debemos determinar aquello que se debe medir así como los CSFs y KPIs correspondientes.

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

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


Pág. 220/321

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

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

• Procesos de medida ya existentes.

• Informes generados.

• Flujos de trabajo establecidos. • Protocolos y procedimientos en vigor.

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

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

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

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

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

• ¿Se puede ver seriamente afectado el rendimiento de algún proceso? Por otro lado sólo aquello que sea finalmente medible debe incorporarse a los SLAs.

Recopilación de datos Una vez decidido lo qué se va a medir hay que decidir cómo y ponerse manos a la obra. Aunque muchas de las mediciones se pueden realizar de forma automática monitorizando la actividad de la organización TI en algunos casos esto no es posible, por ejemplo, en lo que respecta a la calidad de los informes emitidos, el cumplimiento de ciertos protocolos, etcétera. Es importante que cada proceso de medición tenga claramente asignada la persona responsable del mismo, que ésta disponga de las herramientas automáticas necesarias y se haya definido claramente el procedimiento.


Pág. 221/321

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

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

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

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

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

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

• Documentar todo el proceso.

Procesamiento de datos Para que los datos sean de utilidad deben ser previamente procesados para que sean inteligibles y útiles desde la perspectiva de negocio. Este proceso debe transformar los datos en información para así estar dispuesta para su posterior análisis. Esto no es posible sin la previa realización de ciertas tareas:

• Definir las necesidades de procesamiento en función de la estrategia predefinida.

• Analizar los SLAs vigentes para determinar los que información puede ser de utilidad para evaluar su cumplimiento.

Establecer protocolos para el procesamiento de datos: Frecuencia:

• Tiempo real

• Por lotes (diariamente, semanalmente...) • Procedimientos:

• Estructuración de los datos

• Evaluación de la calidad de los datos • Determinar los recursos y capacidades necesarios.

• Seleccionar e instalar las herramientas a utilizar.

• Formar el personal asignado a las tareas e procesamiento de datos. • Definir la estructura de los informes a entregar (plantillas).


Pág. 222/321

Como resultado de todo ello los responsables del proceso de análisis deben recibir los informes correspondientes en un formato eminentemente práctico (obviando información no relevante para el negocio) que permita su correcta interpretación.

Análisis de datos El análisis de la información previamente “digerida” permite transformar a esta en “conocimiento” orientado a determinar cuáles son los aspectos susceptibles de mejora. El principal objetivo del análisis es comprobar que:

• Se cumplen los SLAs.

• Los servicios son rentables y eficientes.

• Se siguen los procedimientos preestablecidos. • Los servicios TI cumplen los objetivos propuestos y dan soporte a la estrategia de negocio.

• Es de particular importancia analizar las tendencias pues estas nos permiten prever a corto y medio plazo posibles problemas u oportunidades.

Creación de informes El último paso, antes de entrar en lo que es la propia “acción correctiva”, es utilizar toda la información y conocimiento adquiridos a través de los pasos anteriores del proceso para permitir la toma de decisiones con “conocimiento de causa”. Esto se debe hacer mediante la presentación de informes específicamente orientados a los diferentes agentes involucrados en la gestión y prestación de los servicios TI. Se deben ajustar tanto los contenidos como el estilo de presentación (técnico, conceptual...) a cada público objetivo:

• Dirección.

• Gestores TI. • Personal técnico.

• Clientes y usuarios. El objetivo principal de estos informes es ofrecer “inteligencia” a la organización TI y sus clientes para mejorar la calidad del servicio y alinearlo con las necesidades de negocio. Es recomendable establecer una estructura clara y, en la medida de lo posible, estandarizada para toda la documentación generada que facilite el acceso a la información relevante a cada público objetivo. La documentación no debe ser excesivamente prolija y debe centrarse exclusivamente en los elementos que aporten valor. Si es posible, todos los informes generados deben estar disponibles en una intranet/extranet que permita el rápido acceso (con la jerarquía de permisos adecuada) a toda la información relevante con diferentes grados de profundidad. Los informes deben ser una herramienta eminentemente práctica. Si el público al que van dirigidos los considera farragosos o se requiere un excesivo esfuerzo para la extracción de información relevante serán probablemente ignorados y todo el proceso se verá gravemente afectado.


Pág. 223/321

Acciones correctivas Todo este complejo proceso de Mejora Continua sería poco más que una pérdida de tiempo y dinero sino aseguramos que las medidas correctivas propuestas son correctamente implementadas. Sin embargo, es conveniente establecer un calendario realista para la implementación de dichas mejoras. No es siempre la mejor solución poner en marcha simultáneamente todas las mejoras propuestas. Es imprescindible establecer prioridades que respondan a las prioridades del negocio en términos de su estrategia y visión. Una vez hecho esto las mejores propuestas han de pasar por la fase de Diseño (desarrollo) y Transición (despliegue) para su despliegue, antes de incorporarse a la decisiva fase de Operación. Durante todo este proceso es indispensable seguir midiendo y analizando para asegurar que no han cambiado las necesidades o estrategia de negocio y asegurar que todos los agentes implicados están correctamente informados y han sido capacitados para afrontar los cambios previstos. El proceso de mejora continua es a la vez susceptible de aplicarse a sí mismo, aunque, claro está, deban evitarse bucles infinitos :). El CSI debe aplicarse los mismos fundamentos que postula por lo que el ciclo de 7 pasos que lo componen debe ser utilizado para monitorizar el propio proceso de mejora y proponer las mejoras que se consideren oportunas. Para todo ello es necesario determinar:

• Los objetivos de los propios planes de mejora. • Las métricas que se aplicaran para evaluar dicho proceso.

• Los datos que es necesario recopilar.

• La información y conocimiento que se generan de ellos. • Los informes o inteligencia que se esperan generar.

• Como se implementarán dichos cambios. Es imprescindible que todo el proceso este adecuadamente documentado y se incorporen evaluaciones periódicas de todo el proceso. Se designará un gestor del CSI que será responsable de:

• Gestionar toda la comunicación asociada al proceso. • Asignar y monitorizar los recursos disponibles.

• Determinar las principales áreas de mejora en colaboración con la dirección y los propietarios de los diferentes servicios.

• Elaborar el Plan de Mejora del servicio en colaboración con la Gestión de Niveles de Servicio.

• Supervisar todo el proceso y garantizar que se adecúa a los objetivos propuesto en concepto y forma.

Control del proceso El proceso de mejora continua es a la vez susceptible de aplicarse a sí mismo, aunque, claro está, deban evitarse bucles infinitos :). El CSI debe aplicarse los mismos fundamentos que postula por lo que el ciclo de 7 pasos que lo componen debe ser utilizado para monitorizar el propio proceso de mejora y proponer las mejoras que se consideren oportunas. Para todo ello es necesario determinar:


Pág. 224/321

• Los objetivos de los propios planes de mejora. • Las métricas que se aplicaran para evaluar dicho proceso.

• Los datos que es necesario recopilar.

• La información y conocimiento que se generan de ellos. • Los informes o inteligencia que se esperan generar.

• Como se implementarán dichos cambios. Es imprescindible que todo el proceso este adecuadamente documentado y se incorporen evaluaciones periódicas de todo el proceso. Se designará un gestor del CSI que será responsable de:

• Gestionar toda la comunicación asociada al proceso. • Asignar y monitorizar los recursos disponibles.

• Determinar las principales áreas de mejora en colaboración con la dirección y los propietarios de los diferentes servicios.

• Elaborar el Plan de Mejora del servicio en colaboración con la Gestión de Niveles de Servicio. • Supervisar todo el proceso y garantizar que se adecúa a los objetivos propuesto en concepto y forma.


Pág. 225/321

IIINNNFFFOOORRRMMMEEESSS DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII

Visión general Es imposible realizar proyecciones, establecer estrategias y proponer mejoras si se desconoce el estado actual de las cosas. El proceso de Gestión de Informes tiene como principal objetivo proporcionar a todos los agentes implicados en la gestión de los servicios TI una visión objetiva, basada en datos y métricas, de la calidad y rendimiento de los servicios prestados. Este proceso tiene como input los datos recopilados a través de toda la organización TI y ofrece como output una serie de informes que aporten el conocimiento necesario para implementar mejoras funcionales, estructurales o para el negocio. Por su naturaleza este proceso requiere la estrecha colaboración de los otros procesos pues sin ésta se carecerá del adecuado punto de partida para determinar qué datos deben ser registrados, procesados, analizados y posteriormente “digeridos” y presentados como informes. Las interacciones y funcionalidades de la Generación de Informes se resumen sucintamente en el siguiente interactivo:

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

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

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

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


Pág. 226/321

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

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

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

• Comunicar la percepción de los clientes y usuarios sobre la calidad de los servicios ofrecidos. Las principales dificultades a las que se enfrenta la gestión de Generación de Informes incluyen:

• No están bien delimitadas las responsabilidades de cada uno de los agentes implicados. • La recogida de datos no se realiza correctamente o la calidad de los datos es deficiente.

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

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

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

• Selección y recopilación de los datos necesarios para la generación de informes.

• Procesado y análisis de los datos para su posterior uso. • Preparación de los contenidos para los diferentes públicos objetivo.

• Publicación de los informes predeterminados. Nota: los botones del gráfico permiten acceder a información más detallada sobre la interrelación con otros procesos TI.

Recopilación de datos Los modernos sistemas TI son capaces de registrar, manipular y procesar ingentes cantidades de datos, capacidad que no comparten sus gestores, al menos mientras las máquinas no nos sustituyan en tareas de “alto nivel” :). Es por ello imprescindible que desde el mismo inicio del proceso de recogida de datos para la elaboración de informes se seleccionen y filtren los aquellos susceptibles de aportar valor al negocio y a la gestión de los procesos TI.


Pág. 227/321

Es necesario determinar en primaria instancia:

• Qué informes se generarán. • Cuáles son los datos que se necesitan.

• A quién van a ir dirigidos los informes.

• Qué nivel de detalle incluirán. • Qué formato se utilizará.

Esto permitirá a los responsables del proceso optimizar las actividades necesarias de recogida de datos. No debemos caer en la tentación de pensar que los datos nunca sobran. Aunque si bien es cierto que al simple nivel de registro es posible y conveniente guardar la mayor cantidad posible de datos, ya que el coste de esta operación es marginal, la recopilación y preparación de los datos para su posterior análisis y proceso puede ser una tarea infinitamente más compleja y devoradora de recursos, tanto tecnológicos como humanos.

Análisis de datos Una vez recopilados los datos necesarios es necesario procesarlos y analizarlos de forma que ofrezcan información útil al negocio y a los responsables de los servicios TI. Todos los datos e información deben transformarse en conocimiento de forma que los receptores de los informes generados puedan tomar decisiones inteligentes sobre las acciones que se deban tomar (proceso DIKW). Durante el proceso y análisis de los datos se deben destacar aquellos que han tenido un impacto apreciable en el pasado y puedan tener un impacto futuro. Los datos no son sólo una fuente necesaria para tomar acciones correctivas sino también pueden ser de utilidad para futuras decisiones estratégicas o de marketing. Durante el proceso de análisis se deben evaluar la calidad y cantidad de los datos corregidos y proponer los cambios necesarios para asegurar que se dispone de la información necesaria para evaluar la calidad y rendimiento de los servicios TI prestados.

Generar documentación Tras procesar y analizar toda la información recopilada es el momento de darle forma a través de informes para proceder a su comunicación a su público objetivo. Los informes deben ser claros y comprensibles a sus lectores. Por ejemplo todos los informes dirigidos a los responsables del negocio deben obviar abstrusos aspectos técnicos que no aporten valor para la toma de decisiones de carácter estratégico. En principio los diferentes públicos objetivos incluyen:

• Los responsables del negocio: los informes que tengan este grupo como destinatario deben concentrarse en aspectos relacionados con el cumplimiento de los compromisos de nivel de servicio recogidos en los SLAs.

• Los gestores de procesos TI: están principalmente interesados en la calidad y rendimiento de los procesos TI y deben ser informados sobre el cumplimiento de los CSFs y KPIs.

• Personal técnico: necesita información (métricas, KPIs) que les permita mejorar aspectos operativos en la prestación de servicio TI.


Pág. 228/321

Cuando esto sea posible se debe mostrar la información de una forma gráfica que permita su rápida interpretación y oriente a los responsables sobre los aspectos que necesitan una lectura más detallada y productiva.

Control del proceso Los responsables del proceso de Generación de Informes deben velar por la calidad y adecuación al propósito de toda la documentación generada y al mismo tiempo generar los informes necesarios para el control y seguimiento del propio proceso. La documentación generada sobre las actividades llevadas a cabo por el proceso de Generación de Informes de incluir:

• Calendarios de entrega de toda la documentación aportada: � Descripción individual de los informes generados � Destinatarios

• Informes sobre las características y calidad de los datos recogidos: � Origen � Calidad de los mismos � Periodicidad: continua, diaria, semanal, mensual... � Recogida manual o automática � Metodologías utilizadas para el procesado y análisis de los datos. � Recursos utilizados. � Feedback recibido: dirección, gestores y propietarios de servicios y procesos, personal técnico � Propuestas de mejora.

En particular los gestores deberán velar porque los informes:

• Estén correctamente escritos en un lenguaje sencillo y directo. • Contengan toda la información necesaria.

• Faciliten la “digestión” de la información a través de gráficas y diagramas.

• Tengan una dimensión y profundidad acorde con las necesidades y conocimientos de sus destinatarios. • Sean fácilmente accesibles a todas las personas a las que van dirigidos.


Pág. 229/321

PPPUUUEEESSSTTTAAA EEENNN MMMAAARRRCCCHHHAAA La puesta en marcha de esta fase del ciclo de vida del servicio puede ser compleja y requiere una preparación previa que asegure la bondad de sus resultados:

• Se dispone de una clara visión de los objetivos.

• Existen planes de comunicación para informar a todos los agentes implicados y asegurar que estos entienden la importancia del proceso de mejora continua.

• Todas las métricas necesarias han sido definidas y se dispone de las herramientas necesarias para su utilización.

• Está disponible la estructura organizativa necesaria y los roles necesarios se hayan cubiertos.

• Existe una estrategia para implementar ágilmente los cambios que puedan tener un impacto positivo sin grandes costes y/o esfuerzo para impulsar el CSI.

Caso de negocio Una de las herramientas básicas para la puesta en marcha del CSI es la realización de un “Caso de Negocio” que permita evaluar, en términos del negocio, los potenciales beneficios de la implantación del CSI. Este caso de negocio debe ofrecer una clara respuesta a preguntas iniciales tales como:

• ¿Cuáles son nuestros objetivos? • ¿Dónde nos encontramos respecto a esos objetivos?

• ¿Qué necesitamos para alcanzarlos?

• ¿Cuál será el retorno previsto? • ¿Cómo se evaluará lo obtenido?

Que se deberán complementar con la progresiva implantación del CSI en respuestas a:

• ¿Se han cumplido los objetivos?

• ¿Qué otras posibles mejoras podemos implementar? Como parte de este caso de negocio es imprescindible establecer de forma explícita:

• Los costes: � Personal � Formación � Tecnología � Gestión � Comunicación

• Los beneficios esperados en términos de: � Mejoras en la calidad y rendimiento de servicios y procesos � Retorno a la Inversión (ROI) � Valor de la Inversión (VOI): que incluye aspectos de valor añadido de difícil medida a corto plazo:

satisfacción del cliente, recompensas emocionales para la fuerza de trabajo…


Pág. 230/321

RRREEELLLAAACCCIIIÓÓÓNNN CCCOOONNN OOOTTTRRROOOSSS CCCIIICCCLLLOOOSSS La fase de Mejora Continua del Servicio debe estar, por su propia naturaleza, estrechamente ligada a todas las restantes fases del ciclo de vida del servicio. La fase de mejora Continua del servicio recibe inputs de todas las demás fases y debe proporcionar input a cada una de ellas pues su objetivo es mejorar tanto la calidad de los servicios prestados como todos los procesos de gestión asociados. 1. MEJORA CONTINUA Y ESTRATEGIA En un mundo en constante desarrollo tecnológico las estrategias no deben ser inamovibles. La estrategia debe ser continuamente rediseñada atendiendo a múltiples factores. La Mejora del Servicio debe ofrecer información a la fase de Estrategia sobre aspectos que pueden ser optimizados, tales como calidad y rendimiento, pero esto siempre debe hacerse partiendo de la perspectiva de negocio establecida durante la fase de estrategia. 2. MEJORA CONTINUA Y DISEÑO 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. 3. MEJORA CONTINUA Y TRANSICIÓN 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, rendimiento y rentabilidad de estos y la consecuente percepción de clientes, usuarios y organización TI. La fase de Transición es clave en este aspecto. Los cambios son la fuente principal de incidencias y problemas tanto a nivel interno (componente tecnológica) como a nivel externo (calidad del servicio). 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. 4. MEJORA CONTINUA Y OPERACIÓN La fase de Mejora Continua del Servicio depende directamente de la fase de Operación pues ésta representa la principal fuente de información para la optimización de los procesos y actividades involucrados en la prestación del servicio. Los informes generados en la fase de Operación del Servicio deben, en particular, incorporar información detallada sobre:

• Incidencias en la prestación del servicio.

• Soluciones propuestas a los problemas detectados en la fase de operación. • Peticiones de los usuarios y clientes.


Pág. 231/321

ITIL V.3

AAASSSPPPEEECCCTTTOOOSSS AAA CCCOOONNNTTTEEEMMMPPPLLLA

Existen algunos aspectos a contemplar dentro del ciclo de implementación de ITIL y es conveniente también conocer el mapa de los componentes que se pueden implementar, tomando en cuenta que no es necesario que todimplementados en el proceso uncial se puede hacer paulatinamente.

Manual Técnico

LLAAARRR EEENNN LLLAAA IIIMMMPPPLLLEEEMMMEEENNNTTTAAACCCIIIÓÓÓNNN DDDEEE IIITTTIIILLL VVV...

n algunos aspectos a contemplar dentro del ciclo de implementación de ITIL y es conveniente también conocer el mapa de los componentes que se pueden implementar, tomando en cuenta que no es necesario que todimplementados en el proceso uncial se puede hacer paulatinamente.

Pág. 232/321

...333

n algunos aspectos a contemplar dentro del ciclo de implementación de ITIL y es conveniente también conocer el mapa de los componentes que se pueden implementar, tomando en cuenta que no es necesario que todos sean


Pág. 233/321

DESARROLLAR ESTRATEGIA DE LOS SERVICIOS. PPPrrroooccceeesssooo 111... DDDeeefffiiinnniiirrr eeelll MMMeeerrrcccaaadddooo...

�� La Matriz de Servicios y Mercados Atendidos. � La Matriz de Recursos de Clientes y Oportunidades.

PPPrrroooccceeesssooo 222... DDDeeesssaaarrrrrrooolll lllaaarrr lllooosss OOOfffrrreeeccciiimmmiiieeennntttooosss... � El Reporte de Servicios Calificados. � Las Propuestas de Servicios a Clientes. PPPrrroooccceeesssooo 333... DDDeeesssaaarrrrrrooolll lllaaarrr RRReeecccuuurrrsssooosss EEEssstttrrraaatttééégggiiicccooosss... � La Matriz de Correlación de Servicios y Recursos de TI. � El Reporte de Impacto en Recursos Estratégicos de TI. PPPrrroooccceeesssooo 444... PPPrrreeepppaaarrraaarrr pppaaarrraaa EEEjjjeeecccuuuccciiióóónnn (((AAAnnnááálll iiisss iiisss EEEssstttrrraaatttééégggiiicccooo)))... � El Modelo de Estrategia de Servicios. � La Visión y la Misión del Area de TI. � El Plan Estratégico del Area de TI. � El Reporte de Control y Evaluación del Plan Estratégico del Area de TI. Desarrollar Economía de los Servicios. PPPrrroooccceeesssooo 555... AAAdddmmmiiinnniiissstttrrraaarrr FFFiiinnnaaannnzzzaaasss... � El Manual de Políticas de Costeo de Servicios. � EL Cuadro de Costos de los Servicios. � El Cuadro de Precios de Venta de Referencia de los Servicios. � El Reporte de Análisis Dinámico de Variación de Costos. � El Reporte de Optimización Financiera de Aprovisionamiento de Servicios. � El Reporte Comparativo de Costos de Servicios Externos. � El Modelo Financiero de la Demanda de Servicios � El Presupuesto Anual de Ingresos. � El Presupuesto Anual de Gastos. � El Presupuesto Anual de Inversiones. � El Reporte de Análisis de Valor Real de los Servicios. � El Análisis de Impacto al Negocio de Posibles Interrupciones en Servicios. � El Reporte de Pérdidas Reales por Interrupciones en los Servicios. � El Acuerdo o Contrato de Servicios Financieros. � Las Solicitudes de Cotizaciones a Proveedores. � Las Solicitudes de Compra de Usuarios. � Las Solicitudes de Compra para Proveedores. � El Reporte de Anticipos y Pagos a Proveedores. � Los Contratos de Servicio con Proveedores. � El Reporte de Control y Liquidación de Caja Chica. � El Acuerdo o Contrato de Servicios Financieros. � El Reporte de Ingresos y Salidas de Artículos de Bodega. � El Reporte de Artículos Comprados en Tránsito. � El Reporte de Devoluciones de Artículos a Proveedores. � El Reporte de Devoluciones de Artículos de Usuarios. � El Reporte de Existencias de Artículos. � El Reporte Inventarios de Artículos en Punto de Re Orden. � El Reporte de Toma de Inventarios de Artículos y Discrepancias. � El Reporte de Inventario de Equipos de TI (Consolidado y Detallado). � El Reporte de Bajas y Cambios del Inventario de Equipos de TI. � El Reporte de Toma de Inventarios de Equipos y Discrepancias. � La Hoja de Equipos de TI Bajo Responsabilidad de Usuarios. � El Reporte de Salidas/Entradas de Equipos para Servicios Externos. � El Reporte de Salidas/Entradas de Equipos para Servicios Externos (Garantías).


Pág. 234/321

PPPrrroooccceeesssooo 666... EEEvvvaaallluuuaaarrr RRReeetttooorrrnnnooo dddeee lllaaa IIInnnvvveeerrrsssiiióóónnn... � El Caso de Negocio. � El Análisis de Retorno de la Inversión. PPPrrroooccceeesssooo 777... AAAdddmmmiiinnniiissstttrrraaarrr eeelll PPPooorrrtttaaafffooolll iiiooo dddeee SSSeeerrrvvviiiccciiiooosss... � El Portafolio de Servicios del Area de TI consolidado y por Negocios de Clientes. PPPrrroooccceeesssooo 888... AAAdddmmmiiinnniiissstttrrraaarrr lllaaa DDDeeemmmaaannndddaaa... � El Reporte de Demanda de Servicios y Recursos de TI. � La Matriz de Perfiles de Usuarios para Demanda de Servicios. � El Reporte de Paquetes de Servicios. DDDeeesssaaarrrrrrooolll lllaaarrr OOOrrrgggaaannniiizzzaaaccciiióóónnn... Proceso 9. Desarrollar Estilo de la Organización. � El Enunciado de Estilo Organizacional. PPPrrroooccceeesssooo 111000... DDDeeepppaaarrrtttaaammmeeennntttaaalll iiizzzaaarrr yyy DDDeeefffiiinnniiirrr FFFuuunnnccciiiooonnneeesss dddeee lllaaa OOOrrrgggaaannniiizzzaaaccciiióóónnn... � El Organigrama del Área de TI (Departamentos y Procesos). � El Mapa de Procesos del Area de TI. PPPrrroooccceeesssooo 111111... DDDiiissseeeñññaaarrr lllaaa OOOrrrgggaaannniiizzzaaaccciiióóónnn... � El Organigrama del Área de TI (Departamentos, Puestos y Personal). � La Documentación o Manual de Procesos � El Manual de Puestos y Funciones del Area de TI. � El Esquema de Compensación del Personal del Area de TI. � El Perfil de Competencias de Puestos y del Personal del Area de TI. � El Manual de Políticas de Contratación de Personal. � El Perfil de Capacitación de Personal del Area de TI. � El Mapa de Desarrollo de Capacitación. � El Mapa de Desarrollo de Carrera. � Las Evaluaciones de Desempeño del Personal. PPPrrroooccceeesssooo 111222... DDDeeesssaaarrrrrrooolll lllaaarrr lllaaa CCCuuullltttuuurrraaa OOOrrrgggaaannniiizzzaaaccciiiooonnnaaalll ... � El Modelo de Cultura Organizacional. � El Código de Valores, Etica y Conducta (COVEC). PPPrrroooccceeesssooo 111333... DDDeeesssaaarrrrrrooolll lllaaarrr EEEssstttrrraaattteeegggiiiaaasss dddeee AAAppprrrooovvviiisss iiiooonnnaaammmiiieeennntttooo dddeee SSSeeerrrvvviiiccciiiooosss... � El Acuerdo o Contratos de Servicios de Nómina y Recursos Humanos. � Los Contratos de Trabajo del Personal del Area de TI (Fijos y Subcontratados). � El Reporte de Evaluación del Contrato del Servicio de Nóm y RRRHH. Implementar Tácticas. PPPrrroooccceeesssooo 111444... RRReeelllaaaccciiiooonnnaaarrr EEEssstttrrraaattteeegggiiiaaa cccooonnn DDDiiissseeeñññooo dddeee SSSeeerrrvvviiiccciiiooosss... � El Modelo del Servicio. � Las Estrategias de Diseño del Servicio. � El Plan de Diseño del Servicio. � Matriz de Responsabilidades del Diseño del Servicio. � El Acta de Constitución del Proyecto (Area Diseño de Servicios). � El Enunciado de Alcance del Proyecto (Area Diseño de Servicios). � El Plan de Administración del Proyecto (Area Diseño de Servicios): o Plan de Administración del Alcance del Proyecto. o Plan de Administración del Tiempo del Proyecto. o Plan de Administración del Costo del Proyecto. o Plan de Administración de la Calidad del Proyecto. o Plan de Administración de los Recursos Humanos del Proyecto. o Plan de Administración de las Comunicaciones del Proyecto.


Pág. 235/321

o Plan de Administración de los Riesgos del Proyecto. o Plan de Administración de las Adquisiciones del Proyecto. � El Reporte de Ejecución y Control de Administración de Proyecto: o Alcance del Proyecto. o Tiempo del Proyecto. o Costo del Proyecto. o Calidad del Proyecto. o Recursos Humanos del Proyecto. o Comunicaciones del Proyecto. o Administración de los Riesgos del Proyecto. o Adquisiciones del Proyecto. PPPrrroooccceeesssooo 111555... RRReeelllaaaccciiiooonnnaaarrr EEEssstttrrraaattteeegggiiiaaa cccooonnn TTTrrraaannnsssiiiccciiióóónnn dddeee SSSeeerrrvvviiiccciiiooosss... � Las Estrategias de Transición del Servicio. � El Plan de Transición del Servicio. � Matriz de Responsabilidades de la Transición del Servicio. � El Acta de Constitución del Proyecto (Area Transición de Servicios). � El Enunciado de Alcance del Proyecto (Area Transición de Servicios). � El Plan de Administración del Proyecto (Area Transición de Servicios): o Plan de Administración del Alcance del Proyecto. o Plan de Administración del Tiempo del Proyecto. o Plan de Administración del Costo del Proyecto. o Plan de Administración de la Calidad del Proyecto. o Plan de Administración de los Recursos Humanos del Proyecto. o Plan de Administración de las Comunicaciones del Proyecto. o Plan de Administración de los Riesgos del Proyecto. o Plan de Administración de las Adquisiciones del Proyecto. � El Reporte de Ejecución y Control de Administración de Proyecto: o Alcance del Proyecto. o Tiempo del Proyecto. o Costo del Proyecto. o Calidad del Proyecto. o Recursos Humanos del Proyecto. o Comunicaciones del Proyecto. o Administración de los Riesgos del Proyecto. o Adquisiciones del Proyecto. PPPrrroooccceeesssooo 111666... RRReeelllaaaccciiiooonnnaaarrr EEEssstttrrraaattteeegggiiiaaa cccooonnn OOOpppeeerrraaaccciiióóónnn dddeee SSSeeerrrvvviiiccciiiooosss... � Las Estrategias de Operación del Servicio. � El Plan de Operación del Servicio. � Matriz de Responsabilidades de la Operación del Servicio. � El Acta de Constitución del Proyecto (Area Operación de Servicios). � El Enunciado de Alcance del Proyecto (Area Operación de Servicios). � El Plan de Administración del Proyecto (Area Operación de Servicios: o Plan de Administración del Alcance del Proyecto. o Plan de Administración del Tiempo del Proyecto. o Plan de Administración del Costo del Proyecto. o Plan de Administración de la Calidad del Proyecto. o Plan de Administración de los Recursos Humanos del Proyecto. o Plan de Administración de las Comunicaciones del Proyecto. o Plan de Administración de los Riesgos del Proyecto. o Plan de Administración de las Adquisiciones del Proyecto. � El Reporte de Ejecución y Control de Administración de Proyecto: o Alcance del Proyecto. o Tiempo del Proyecto. o Costo del Proyecto. o Calidad del Proyecto.


Pág. 236/321

o Recursos Humanos del Proyecto. o Comunicaciones del Proyecto. o Administración de los Riesgos del Proyecto. o Adquisiciones del Proyecto. PPPrrroooccceeesssooo 111777... RRReeelllaaaccciiiooonnnaaa EEEssstttrrraaattteeegggiiiaaa cccooonnn MMMeeejjjooorrraaa CCCooonnntttiiinnnuuuaaa dddeee SSSeeerrrvvviiiccciiiooosss... � Las Estrategias de Mejora Continua del Servicio. � El Plan de Mejora Continua del Servicio. � Matriz de Responsabilidades de la Mejora Continua del Servicio. � El Acta de Constitución del Proyecto (Area Mejora Continua de Servicios). � El Enunciado de Alcance del Proyecto (Area Mejora Continua de Servicios). � El Plan de Administración del Proyecto (Area Mejora Continua de Servicios): o Plan de Administración del Alcance del Proyecto. o Plan de Administración del Tiempo del Proyecto. o Plan de Administración del Costo del Proyecto. o Plan de Administración de la Calidad del Proyecto. o Plan de Administración de los Recursos Humanos del Proyecto. o Plan de Administración de las Comunicaciones del Proyecto. o Plan de Administración de los Riesgos del Proyecto. o Plan de Administración de las Adquisiciones del Proyecto. � El Reporte de Ejecución y Control de Administración de Proyecto: o Alcance del Proyecto. o Tiempo del Proyecto. o Costo del Proyecto. o Calidad del Proyecto. o Recursos Humanos del Proyecto. o Comunicaciones del Proyecto. o Administración de los Riesgos del Proyecto. o Adquisiciones del Proyecto. DISEÑAR LOS SERVICIOS. PPPrrroooccceeesssooo 111888... AAAdddmmmiiinnniiissstttrrraaarrr eeelll CCCaaatttááálllooogggooo dddeee SSSeeerrrvvviiiccciiiooosss... � El Catálogo de Servicios. PPPrrroooccceeesssooo 111999... AAAdddmmmiiinnniiissstttrrraaarrr NNNiiivvveeellleeesss dddeee SSSeeerrrvvviiiccciiiooo... � Los Acuerdos de Niveles de Servicio (SLA) por servicio � Los Requerimientos de los Niveles de Servicio (SLR). � Los Acuerdos de Niveles Operacionales (OLA). � El Reporte de Revisión de Niveles de Servicio. � El Reporte de Solicitudes de Revisión de Servicios para Mejoras. � El Reporte de Medición de Satisfacción de Clientes. � El Reporte de Solicitudes de Cambios. � El Reporte de Solicitudes de Nuevos Servicios. PPPrrroooccceeesssooo 222000... AAAdddmmmiiinnniiissstttrrraaarrr CCCaaapppaaaccciiidddaaadddeeesss dddeee RRReeecccuuurrrsssooosss... � El Plan de Capacidades (Por Servicio y por Recurso). � El Reporte de Capacidades y Rendimientos Requeridos para Servicios de TI. � El Reporte de Capacidades y Rendimientos Requeridos de Recursos de IT. � El Reporte de Variaciones en Capacidades y Rendimientos de Servicios. � El Reporte de Variaciones en Capacidades y Rend de Rec, Datos e Infor y Aplic. PPPrrroooccceeesssooo 222111... AAAdddmmmiiinnniiissstttrrraaarrr DDDiiissspppooonnniiibbbiii lll iiidddaaadddeeesss dddeee SSSeeerrrvvviiiccciiiooosss... � El Plan de Disponibilidades (Por Servicio y por Recurso). � El Documento Proyección de Interrupción de Servicios (PSO). � El Reporte de Solicitudes de Cambios. � El Reporte de Disponibilidad, Confiabilidad y Mant Requeridos para Serv de TI.


Pág. 237/321

� El Reporte de Disponibilidad, Confiabilidad y Mant Requeridos de Recursos de IT. � El Calendario de Pruebas de Disponibilidades de Recursos y Servicios. � El Reporte de Análisis de Fallas de Servicios (SFA). � El Reporte de Variaciones en Disponibilidad, Confiabilidad y Mant de Servicios. � El Reporte de Variaciones en Disponibilidad, Confiabilidad y Mant de Rec de IT. � El Reporte de Análisis de Impacto al Negocio por Interrupciones. � El Reporte de Costos Reales de Interrupciones de los Servicios. PPPrrroooccceeesssooo 222222... AAAdddmmmiiinnniiissstttrrraaarrr lllaaa CCCooonnntttiiinnnuuuiiidddaaaddd dddeeelll SSSeeerrrvvviiiccciiiooo dddeee TTTIII ... � El Plan de Continuidad de los Servicios de TI. � El Reporte de Análisis de Impacto al Negocio por Interrupciones. � El Reporte de Amenazas de los Recursos y Servicios de TI. � El Reporte de Análisis de Riesgos de Recursos y Servicios de TI. � El Reporte de Controles Preventivos de Recursos y Servicios de TI. � El Reporte de Prioridades de Recuperación de los Recursos y Servicios. � El Registro de Capacitación del Plan de Continuidad. � El Registro de Pruebas y Ejercicios del Plan de Continuidad. PPPrrroooccceeesssooo 222333... AAAdddmmmiiinnniiissstttrrraaarrr lllaaa SSSeeeggguuurrr iiidddaaaddd dddeee IIInnnfffooorrrmmmaaaccciiióóónnn... � El Manual de Políticas de la Seguridad de la Información. � El Código de Práctica de la Administración de la Seguridad de la Información. � El Reporte del Análisis de Riesgos de Recursos y Servicios de TI. � El Reporte de Controles Preventivos o Plan de Tratamiento de Riesgos. � El Reporte de Revisiones Internas y Recomendaciones para el SASI. � El Reporte de Auditorías Internas del SASI. � El Reporte de Evaluación de la Seguridad de Infor, practicado por la fuente ext. � Los Registros de Capacitación del Manual de Políticas de la Seg de la Inf. � Los Registros de Capacitación del Código de Práctica de la Ad de la Seg de Inf. PPPrrroooccceeesssooo 222444... AAAdddmmmiiinnniiissstttrrraaarrr PPPrrrooovvveeeeeedddooorrreeesss dddeee SSSeeerrrvvviiiccciiiooosss... � El Catálogo de Proveedores de Servicios. � La Base de Datos de Proveedores y Contratos (SCD). � Las Políticas de Relaciones con Proveedores. � El Plan de Mejoras de Servicios de Proveedores (SIP). � Las Evaluaciones Preliminares de Proveedores. � Las Evaluaciones de Servicios de Proveedores. � Los Acuerdos o Contratos de Servicios. � Las Solicitudes de Cambios (A,B ,C) de Proveedores y Contratos de Servicios. PPPrrroooccceeesssooo 222555... AAAdddmmmiiinnniiissstttrrraaarrr IIInnngggeeennniiieeerrr íííaaa dddeee RRReeeqqquuueeerrr iiimmmiiieeennntttooosss... � El Manual de Políticas de Requerimientos. � El Listado de Requerimientos. � La Plantilla de Requerimientos. � El Catálogo de Requerimientos (Mod Funcional, Mod Oper y Mod de Usab). � La Bitácora de Revisión de Requerimientos. � La Bitácora de Cambios de Requerimientos. � Los Proyectos de Análisis de Requerimientos. PPPrrroooccceeesssooo 222666... AAAdddmmmiiinnniiissstttrrraaarrr DDDaaatttooosss eee IIInnnfffooorrrmmmaaaccciiióóónnn... � El Manual de Políticas y Estándares de Administración de la Información. � El Modelo o Arquitectura de la Información. � Los Requerimientos de la Administración de la Información. � El Manual de Eventos Programados para la Información. � El Reporte Discrepancias de Infor entre Eventos Prog y Realizados. � El Diseño de Infraestructura de Almacenamiento (Datos). � El Reporte de Discrepancias en la Arquitectura de la Información.


Pág. 238/321

� El Modelo o Diccionario de Datos y sus Relaciones. � El Reporte de Discrepancias del Modelo o Dicc de Datos y sus Relaciones. PPPrrroooccceeesssooo 222777... AAAdddmmmiiinnniiissstttrrraaarrr lllaaasss AAAppplll iiicccaaaccciiiooonnneeesss � El Manual de Políticas y Estándares de la Administración de Aplicaciones. � El Modelo o Arquitectura de las Aplicaciones. � Los Requerimientos de las Aplicaciones. � El Portafolio de Aplicaciones. � El Control de Licencias de Aplicaciones. � El Reporte de Discrepancias de Licencias de Aplicaciones. � El Manual de Eventos Programados para las Aplicaciones. � El Reporte de Discrepancias de Aplic entre Eventos Prog y Realizados. � El Diseño de Infraestructura de Almacenamiento (Aplicaciones). � El Reporte de Discrepancias en la Arquitectura de las Aplicaciones. � La Biblioteca de Códigos (Fuente y Ejecutable) y Objetos Reusables. � El Reporte de Discrepancias entre la Biblioteca de Cód Fuente y Cód Ejecutable. � La Documentación Técnica de Aplicaciones. � La Documentación de Usuarios de Aplicaciones. TRANSICIONAR LOS SERVICIOS. PPPrrroooccceeesssooo 222888... PPPlllaaannneeeaaarrr lllaaa TTTrrraaannnsssiiiccciiióóónnn yyy SSSooopppooorrrttteee... � El Plan de Transición de Servicios. � Las Estrategias de Transición de Servicios. � La Matriz de Responsabilidades de Transición de Servicios. PPPrrroooccceeesssooo 222999... AAAdddmmmiiinnniiissstttrrraaarrr CCCaaammmbbbiiiooosss... � El Manual de Políticas de Cambios. � Las Minutas del Comité de Cambios. � Los Registros de Solicitudes de Cambios (RFC) y su Estado. � La Matriz de Impacto y Prioridades de Cambios. � El Plan de Cambios. PPPrrroooccceeesssooo 333000... AAAdddmmmiiinnniiissstttrrraaarrr RRReeecccuuurrrsssooosss yyy CCCooonnnfffiiiggguuurrraaaccciiiooonnneeesss... � El Manual de Políticas de Configuraciones. � El Diagrama de la Infraestructura Tecnológica. � El Sistema de Administración de Configuraciones. � El Plan de Configuraciones. � El Reporte de Estado de Recursos y Configuraciones. � El Reporte de Discrepancias en Recursos y Config en Ambiente de Operación. PPPrrroooccceeesssooo 333111... AAAdddmmmiiinnniiissstttrrraaarrr LLLiiibbbeeerrraaaccciiiooonnneeesss eee IIImmmpppllleeemmmeeennntttaaaccciiiooonnneeesss... � Las Políticas de Liberaciones. � Los Paquetes de Liberaciones. � El Plan de Liberaciones e Implementaciones. � El Reporte de Desviaciones para Liberaciones e Implementaciones. � El Modelo de Construcción y Pruebas. � El Reporte Final de Liberación e Implementación. PPPrrroooccceeesssooo 333222... VVVaaalll iiidddaaarrr SSSeeerrrvvviiiccciiiooosss yyy PPPrrruuueeebbbaaasss... � El Manual de Políticas de Pruebas. � El Plan de Pruebas. � El Diseño de Pruebas. � El Reporte de Validación de Servicios y Pruebas. � El Registro de Datos de Pruebas. � El Registro de Ambiente de Pruebas.


Pág. 239/321

PPPrrroooccceeesssooo 333333... EEEvvvaaallluuuaaarrr SSSeeerrrvvviiiccciiiooosss dddeee TTTrrraaannnsssiiiccciiióóónnn... � El Manual de Políticas de Evaluación de Rendimiento de Servicios. � El Plan de Evaluación de Servicio en Transición. � El Modelo de Rendimiento. � El Reporte de Evaluación de Servicios en Transición (Preliminar y Final). PPPrrroooccceeesssooo 333444... AAAdddmmmiiinnniiissstttrrraaarrr CCCooonnnoooccciiimmmiiieeennntttooosss . � La Estrategia y Etapas de Construcción Sist Admin de Conocimientos (SKMS). � La Arquitectura del Sistema de Administración de Conocimientos (SKMS). � Los Proyectos de Implementación del Sist Admin de Conocimientos (SKMS). � El Reporte de Eval del Sistema de Administración de Conocimientos (SKMS). PPPrrroooccceeesssooo 333555... AAAdddmmmiiinnniiissstttrrraaarrr CCCooommmuuunnniiicccaaaccciiiooonnneeesss yyy CCCooommmppprrrooommmiiisssooosss... � El Plan de Comunicación para Servicio en Transición. � El Reporte de Evaluación de Sesiones de Comunicación. � El Reporte de Encuestas de Evaluación de Estrategia de Comunicación. � El Reporte Final de Evaluación de Comunicación de Servicio en Transición. PPPrrroooccceeesssooo 333666... AAAdddmmmiiinnniiissstttrrraaarrr OOOrrrgggaaannniiizzzaaaccciiióóónnn yyy CCCaaammmbbbiiiooo... � El Reporte de Análisis de Cambio Organizacional. � El Enunciado de Visión de Cambio Organizacional. � El Mapa de Estrategias de Cambio Organizacional. � La Matriz de Responsabilidades del Cambio (RACI). � El Plan de Cambio Organizacional. � El Reporte de Evaluación de Progreso de Cambio Organizacional. � El Reporte Final de Evaluación de Cambio Organizacional. � El Modelo de Servicio (Actual y Nuevo). � El Modelo de Cultura Organizacional (Actual y Nuevo). � La Documentación del Organigrama (Actual y Nuevo). � La Documentación de Procesos (Actual y Nuevo). � El Esquema de Compensación (Actual y Nuevo). � La Documentación de Puestos y Funciones (Actual y Nuevo). � Los Estados Emoc del Ciclo del Cambio Individual y por Grupo (Actual y Nuevo). � El Perfil de Capacitación de Personal (Actual y Nuevo). � El Perfil de Competencias de Personal (Actual y Nuevo). � Los Medidores de Desempeño de Organ, Procesos y Puestos (Actual y Nuevo). � El Mapa de Desarrollo de Capacitación. � El Mapa de Desarrollo de Carrera. PPPrrroooccceeesssooo 333777... AAAdddmmmiiinnniiissstttrrraaarrr RRReeelllaaaccciiiooonnneeesss cccooonnn IIInnnttteeerrreeesssaaadddooosss... � El Mapa de los Interesados y su Involucramiento. � La Matriz de Impacto de los Interesados. � La Matriz de los Requerimientos de los Interesados. � La Matriz de Eventos y Relaciones con los Interesados. � El Reporte de Encuesta de Evaluación de Coord. con Intersados. OPERAR LOS SERVICIOS. PPPrrroooccceeesssooo 333888... AAAdddmmmiiinnniiissstttrrraaaccciiióóónnn dddeee EEEvvveeennntttooosss... � El Reporte de Eventos de Recursos y Configuraciones por Categorías. � El Reporte de Eventos de Aplicaciones por Categorías. � El Reporte de Eventos de Datos e Información por Categorías. � El Reporte de Eventos en Loggins y Bitácoras de Sistema por Categorías. � El Reporte de Eventos que Provocaron Incidentes en la Seg de Información. � El Reporte de Eventos Abiertos y Críticos. PPPrrroooccceeesssooo 333999... AAAdddmmmiiinnniiissstttrrraaaccciiióóónnn dddeee IIInnnccciiidddeeennnttteeesss


Pág. 240/321

� El Reporte de Incidentes de Recursos y Configuraciones por Categorías. � El Reporte de Incidentes de Aplicaciones por Categorías. � El Reporte de Incidentes de Datos e Información por Categorías. � El Reporte de Incidentes en Loggins y Bitácoras de Sistema por Categorías. � El Reporte de Incidentes que Provocaron Incidentes en la Seg de Información. � El Reporte de Incidentes por Servicio. � El Reporte de Incidentes Abiertos y Críticos. � Las Solicitudes de Análisis de Problemas. � Las Solicitudes de Cambios. PPPrrroooccceeesssooo 444000... AAAttteeennndddeeerrr RRReeeqqquuuiiisss iiiccciiiooonnneeesss dddeee SSSeeerrrvvviiiccciiiooosss � El Reporte de Solicitudes por Servicio. � El Reporte de Solicitudes por Ingeniero de Soporte a Usuarios y Soporte Técnico. � El Reporte de Solicitudes por Cliente (o Grupo de Usuarios). � El Reporte de Solicitudes Abiertas y Críticas. � El Reporte de Solicitudes Escaladas al Proceso 39 Administrar Incidentes. � El Reporte de Solicitudes Escaladas al Proceso 42 Administrar Accesos � El Reporte de Solicitudes Escaladas al Proceso 2 Desarrollar los Ofrecimientos. PPPrrroooccceeesssooo 444111... AAAdddmmmiiinnniiissstttrrraaaccciiióóónnn dddeee PPPrrrooobbbllleeemmmaaasss... � El Reporte de Problemas Cerrados. � Las Solicitudes de Cambios. � Las Notificaciones a Base de Conocimientos. PPPrrroooccceeesssooo 444222 AAAdddmmmiiinnniiissstttrrraaaccciiióóónnn dddeee AAAcccccceeesssooosss... � El Reporte de Solicitudes de Acceso y Acciones Realizadas. � El Reporte de Intentos y Violaciones y Acciones Realizadas. � El Reporte de Visitantes a Instalaciones del Area de TI. � El Reporte de Trabajos en Areas Restringidas de TI. � El Reporte de Monitoreo de Identidad de Usuarios y Actividades. � El Reporte de Monitoreo de Loggins y Bitácoras de Sistemas. MEJORAR CONTINUAMENTE LOS SERVICIOS. PPPrrroooccceeesssooo 444333... MMMeeejjjooorrraaarrr CCCooonnntttiiinnnuuuaaammmeeennnttteee lllooosss SSSeeerrrvvviiiccciiiooosss (((MMMCCCSSS)))... � El Manual de Políticas de Mejora Continua. � EL Reporte de Medidores del Negocio del Area de TI. � El Reporte de Medidores Estratégicos del Area de TI. � El Reporte de Medidores de Procesos del Area de TI. � El Plan de Mejora Continua de los Servicios. PPPrrroooccceeesssooo 444444... RRReeepppooorrrtttaaarrr AAAccctttiiivvviiidddaaadddeeesss dddeee SSSeeerrrvvviiiccciiiooosss... � El Sistema Documental de la Administración de Servicios (SDAS). � El Reporte de Incumplimiento de Custodia y Respaldo del SDAS. � La Nota de Incumplimiento de Reportes del SDAS. � El Reporte de Revisión del SDAS. � El Registro de Capacitación de cada Versión del SDAS. PPPrrroooccceeesssooo 444555... RRReeeaaalll iiizzzaaarrr MMMeeedddiiiccciiióóónnn dddeee lllooosss SSSeeerrrvvviiiccciiiooosss... � El Marco de Referencia de Medición de los Servicios. � El Reporte Integral de Medidores de Servicios. � El Balance ScoreCard de los Servicios. PPPrrroooccceeesssooo 444666... CCCaaalllcccuuulllaaarrr RRReeetttooorrrnnnooo dddeee IIInnnvvveeerrrsssiiiooonnneeesss dddeee MMMCCCSSS... � El Caso de Negocio y Retorno de Inversión de MCS.


Pág. 241/321

AAAllliiinnneeeaaannndddooo CCCOOOBBBIIITTT®®® 444...111,,, IIITTTIIILLL®®® VVV333 eee IIISSSOOO /// IIIEEECCC 222777000000222 eeennn bbbeeennneeefffiiiccciiiooo dddeee lllaaa

eeemmmppprrreeesssaaa

1. Resumen ejecutivo Cada empresa necesita ajustar la utilización de estándares y prácticas a sus requerimientos individuales. En este sentido los tres estándares/prácticas cubiertos en esta guía pueden desempeñar un papel muy útil, COBIT e ISO/IEC 27002 para ayudar a definir lo que debería hacerse, e ITIL proporciona el cómo para los aspectos de la gestión de servicios. La creciente adopción de mejores prácticas de TI se explica porque la industria de TI requiere mejorar la administración de la calidad y la confiabilidad de TI en los negocios y para responder a un creciente número de requerimientos regulatorios y contractuales. Sin embargo, existe el peligro de que las implementaciones de estas mejores prácticas, potencialmente útiles, puedan ser costosas y desenfocadas si son tratadas como guías puramente técnicas. Para ser más efectivos, las mejores prácticas deberían ser aplicadas en el contexto del negocio, enfocándose donde su utilización proporcione el mayor beneficio a la organización. La alta dirección, los gerentes, auditores, oficiales de cumplimiento y directores de TI, deberían trabajar en armonía para estar seguros que las mejores prácticas conduzcan a servicios de TI económicos y bien controlados. Las mejores prácticas de TI posibilitan y soportan:

• Una mejor gestión de TI, lo que es crítico para el éxito de la estrategia de la empresa. • Un gobierno eficaz de las actividades de TI.

• Un marco de referencia eficaz para la gestión de políticas, controles internos y prácticas definidas, lo que es necesario para que todos sepan lo que hay que hacer.

• Muchos otros beneficios, incluyendo ganancia de eficiencias, menor dependencia de expertos, menos errores, mejora de la confianza de los socios de negocios y de reguladores.

Este documento aplica en general a todas las mejores prácticas de TI pero se enfoca en tres prácticas y estándares específicos, los que están siendo ampliamente adoptados a nivel global y que han sido actualizadas para incorporar las últimas versiones:

• ITIL v3 : Publicado por la OGC (Office of Government Commerce) del gobierno británico para proporcionar un marco de referencia de mejores prácticas para la gestión de servicios de TI.

• COBIT ® 4.1: Publicado por el ITGI y posicionado como un marco de referencia de alto nivel para el control y el gobierno de TI.

• ISO/IEC 27002:2005: Publicado por ISO (International Organization for Standardization) y por IEC (International Electrotechnical Commission), derivado de la norma B S 7 799 del gobierno británico, renombrada ISO/IEC 17799:2005, para proporcionar un marco de referencia del estándar para gestión de seguridad de información.

Las descripciones de cada práctica pueden ser encontradas en el cuerpo principal de este documento. La implementación de las mejores prácticas debería ser consistente con el marco de control y la gestión de riesgos de la empresa, apropiada para la empresa e integrada con otras metodologías y prácticas que estén siendo utilizadas. Los estándares y las mejores prácticas no son una panacea; su efectividad depende de cómo se implementan y mantienen. Estas son mucho más útiles cuando son aplicadas como un bloque de principios y como un punto de partida para adaptar procedimientos específicos. Para evitar prácticas que nunca se pongan en ejecución (‘shelfware’), la dirección y el staff deben entender lo que hay que hacer, cómo hacerlo y porqué es importante hacerlo.


Pág. 242/321

La implementación debe ser adaptada a la empresa, priorizada y planificada para lograr su uso eficaz. Este documento describe algunos obstáculos que deberían ser evitados. Para lograr el alineamiento de las mejores prácticas con los requerimientos del negocio, se deberían utilizar procesos formales que soporten el buen gobierno de TI. La OGC proporciona guías de gestión a través de sus herramientas Successful Delivery Toolkit ( www.ogc.gov.uk/sdtoolkit/ ), PRINCE2 como marco de referencia de las mejores prácticas para gestión de proyectos, Managing Successful Programmes (MSP) y Management of Risk (M_o_R ): Guidance for Practitioners para gestión de riesgos (ver www.best-management-practice.com/ ). El ITGI proporciona IT Governance Implementation Guide Using COBIT. COBIT puede ser utilizado en los más altos niveles de gobierno de TI, proporcionando un marco de referencia global de control basado en el modelo de procesos de TI que el ITGI pretende se pueda adaptar a cada empresa. También hay una necesidad de procesos detallados y estandarizados para profesionales. Prácticas específicas y estándares como ITIL e ISO/IEC 27002, cubren áreas específicas y pueden ser mapeadas al marco de referencia COBIT, proporcionando así una jerarquía de materiales de orientación. Para entender mejor el mapeo entre ITIL, ISO/IEC 27002 y COBIT, vea el Apéndice I, en donde cada uno de los 34 procesos y objetivos de control de COBIT han sido mapeados a secciones específicas de ITIL e ISO/IEC 27002; el Apéndice II, donde un mapeo inverso muestra cómo es que tópicos clave de ITIL v3 mapean a COBIT 4.1; y el Apéndice III , donde un mapeo inverso muestra cómo las clasificaciones de ISO/IEC 27002 mapean a CobiT. El ITGI y la OGC continuarán actualizando sus guías para mejorar el alineamiento de la terminología y el contenido con otros documentos, facilitando la integración y reflejando las mejores prácticas más recientes.

2. Antecedentes Este compendio de gestión es el resultado de un estudio conjunto iniciado por la OGC británica y el IT Governance Institute en respuesta a la creciente importancia de las mejores prácticas de la industria de TI, así como a la necesidad para los gerentes de TI y de staff de entender mejor el valor de las mejores prácticas de TI y cómo implementarlas. Su primera publicación data de noviembre de 2005 y fue actualizada en agosto de 2008 para reflejar los cambios en COBIT 4.1 e ITIL v3. El itSMF (IT Service Management Forum) también apoyó en el estudio original. La intención de este compendio es explicar el valor de las mejores prácticas de TI a los usuarios de negocios y a la alta dirección, y cómo es que su armonización, implementación e integración puede ser fácilmente realizada. Indicadores del negocio para el uso de las mejores prácticas de TI Las mejores prácticas de TI son importantes debido a una serie de factores:

• Los directorios y los gerentes demandan mejores retornos de las inversiones en TI. Por ejemplo, TI, entrega lo que el negocio necesita para incrementar el valor de los accionistas.

• Preocupación sobre el creciente nivel de gastos de TI.

• La necesidad de cumplir los requisitos regulatorios para los controles de TI en áreas tales como la privacidad y el reporte financiero (Sarbanes-Oxley Act), y en sectores específicos como el financiero, farmacéutico y de salud.

• La selección de proveedores de servicios y la gestión de servicios de outsourcing y compras.

• El incremento de complejidad en riesgos relacionados a TI, como la seguridad de redes.

• Las iniciativas de gobierno de TI, que incluyen la adopción de marcos de referencia y mejores prácticas de control para ayudar a supervisar y mejorar las actividades críticas de TI, para incrementar el valor del negocio y reducir sus riesgos.

• La necesidad de optimizar costos a través de enfoques estandarizados, hasta donde sea posible, en lugar de enfoques específicamente desarrollados.


Pág. 243/321

• La creciente madurez y consecuente aceptación de prestigiosos marcos de referencia, tales como ITIL (Information Technology Infrastructure Library), COBIT (Control Objectives for Information and ® related Technology), ISO/IEC 27002, ISO 9002, CMM (Capability Maturity Model), PRINCE2 (Projects in Controlled Environments), MSP (Managing Successful Programmes), M_o_R (Management of Risk: ® Guidance for Practitioners) y PMBOK (Project Management Body of Knowledge).

• La necesidad de las organizaciones por evaluar su desempeño respecto de estándares generalmente aceptados y respecto de sus pares (benchmarking).

• Declaraciones de analistas que recomiendan la adopción de mejores prácticas. Por ejemplo: o “Los marcos de referencia con herramientas sólidas son esenciales para asegurar que los recursos de TI

estén alineados con los objetivos del negocio, y que los servicios y la información satisfagan los requisitos de calidad, financieros y de seguridad…. COBIT e ITIL no son mutuamente excluyentes y pueden ser combinados para obtener un poderoso marco de referencia de mejores prácticas, control y gobierno en la gestión de servicios de TI. Las empresas que quieren ubicar sus programas ITIL en el contexto de un amplio marco de referencia de gobierno y control deberían utilizar COBIT ”.

Desafíos actuales El creciente uso de estándares y mejores prácticas ha generado nuevos desafíos y demandas por guías de implementación:

• Creación de conciencia del propósito del negocio y los beneficios de estas prácticas.

• Ayuda en la toma de decisiones sobre cuáles prácticas utilizar y cómo integrarlas con las políticas y los procedimientos internos.

• Adaptación de estándares y mejores prácticas a los requerimientos específicos de la organización. (Esta nota corresponde a una investigación de Gartner que fue emitida en junio de 2002, y aún tiene gran relevancia.)

3. ¿Por qué la alta dirección necesita conocer las mejores prácticas?

Debido a su naturaleza técnica, los estándares y las mejores prácticas de TI normalmente son conocidas por los expertos (profesionales, gerentes y asesores de TI), quienes pueden adoptarlos y utilizarlos con la mejor intención; sin embargo, potencialmente no tienen un enfoque de negocio o no cuentan con la participación y la ayuda del cliente. Incluso en organizaciones donde se han implementado prácticas como COBIT e ITIL, algunos gerentes funcionales entienden poco acerca de su real propósito y no están preparados para influir sobre su utilización. Para obtener el máximo valor de las mejores prácticas para el negocio, se necesita involucrar a los clientes de los servicios de TI, dado que el uso eficaz de TI debería ser una experiencia colaborativa entre el cliente y los proveedores del servicio (internos y externos), donde el cliente fija los requerimientos. Otros grupos interesados, tales como el directorio, la alta dirección, los auditores y los reguladores también tienen un gran interés, ya sea en recibir o proporcionar la seguridad de que las inversiones en TI están debidamente protegidas y entregan valor. La Figura que a continuación se muestra resume quien tiene interés en la forma en que los estándares y las mejores prácticas de TI pueden ayudar a considerar los aspectos de gestión de TI.


Pág. 244/321

4. ¿Por qué son importantes las mejores prácticas para la empresa? El uso efectivo de TI es crítico para el éxito de la estrategia de la empresa, como se ilustra en el siguiente comentario: El uso de TI tiene el potencial para ser el mayor impulsor de riqueza económica en el siglo 21. Además de que TI ya es crítica para el éxito empresarial, proporciona oportunidades para obtener una ventaja competitiva y ofrece medios para incrementar la productividad, e incluso hará aún más en el futuro. TI también implica riesgos. Es evidente que en estos días de negocios globales, la caída de los sistemas y las redes puede resultar muy costosa para cualquier empresa. En algunas industrias, TI es un recurso competitivo necesario para diferenciarse y obtener una ventaja competitiva, mientras que en otras, no sólo determina la prosperidad sino la supervivencia. Las mejores prácticas y los estándares ayudan a posibilitar un gobierno eficaz de las actividades de TI Incrementalmente, el uso de estándares y mejores prácticas tales como ITIL, COBIT e ISO/IEC 27002, está siendo conducido por requerimientos de negocio para mejoras de desempeño, transparencia y control sobre actividades de TI. El gobierno británico reconoció prontamente la importancia de las mejores prácticas de TI, y por muchos años las desarrolló para guiar el uso de TI en las dependencias oficiales. Estas prácticas se han convertido en estándares de facto alrededor del mundo en sectores públicos y privados. ITIL se desarrolló hace más de 15 años para documentar las mejores prácticas para la gestión de servicios de TI, a través del aporte de expertos, consultores y profesionales de la industria. ISO/IEC 20000, que está alineado con ITIL, reemplazó a BS 15000 en 2005 como un nuevo estándar global en gestión de servicios. El marco IT Security Code of Practice, desarrollado inicialmente con la ayuda de la industria, se convirtió en BS 7799 y luego en ISO/IEC 17799, y ahora, en ISO/IEC 27002, el primer estándar internacional de gestión de seguridad. PRINCE, y ahora PRINCE2, fue creada por la CCTA (Central Computer and


Pág. 245/321

Telecommunications Agency) que ahora es la OGC, para proporcionar mejores prácticas para gestión de proyectos. La última actualización de PRINCE2 data del año 2009; sin embargo, los principios y contenidos principales no han variado. A inicios de la década de los 90, ISACA reconoció que los auditores, quienes tenían sus propios checklist para evaluar la efectividad de los controles de TI, hablaban en un lenguaje diferente a los profesionales de TI y a la plana gerencial. En respuesta a esta brecha en la comunicación, se creó COBIT como un marco de referencia de control de TI para la gerencia funcional, la gerencia de TI y para auditores, basado en un grupo genérico de procesos de TI significativo para la gente de TI y, con el tiempo, para la gerencia. Las mejores prácticas en COBIT representan un enfoque común para un buen control de TI, a ser implementado por gerentes funcionales y de TI, y a ser evaluadas sobre la misma base por los auditores. A lo largo de los años, COBIT ha sido desarrollado como un estándar abierto , y es cada vez más utilizado como un modelo de control para implementar y demostrar un gobierno efectivo de TI. En 1998, ISACA creó una institución afiliada, el IT Governance Institute, para supervisar el mayor desarrollo de COBIT y para mejorar la comunicación de mensajes relacionados con el gobierno de TI a los gerentes de los negocios, y particularmente, al directorio. Hoy, como cada organización trata de entregar valor a través de TI, a la vez que gestiona un complejo rango de riesgos relacionados a TI, el uso efectivo de las mejores prácticas puede ayudar a evitar la reinvención de sus propias políticas y procedimientos, optimizando el uso de escasos recursos de TI y reduciendo la incidencia de los mayores riesgos de TI, tales como:

• Proyectos fallidos.

• Inversiones perdidas. • Brechas de seguridad.

• Fallas de los sistemas.

• Fallas de proveedores para entender y satisfacer los requerimientos de los clientes. COBIT no es un estándar oficial, pero es referido así con frecuencia, convirtiéndose en el marco de referencia de facto para el control y gobierno de TI. La OGC y el ITGI están a la vanguardia de la difusión y entrega de material sobre mejores prácticas para hacer frente a estos y otros desafíos actuales. Un marco de referencia de gestión de TI para apoyar a la empresa Las organizaciones que desean implantar las mejores prácticas de TI necesitan un marco de referencia de gestión eficaz que proporcione un enfoque general consistente y que sea probable asegurar resultados exitosos al utilizar TI para apoyar la estrategia de la empresa. La OGC publica un portafolio integrado de guías para mejores prácticas, gratuito para los usuarios finales que lo usan e implantan. Este portafolio comprende PRINCE2 (Gestión de proyectos), MSP (Managing Successful Programmes ), ITIL (Gestión de servicios de TI) y M_o_R (Gestión de riesgos). Mayores detalles pueden encontrarse en la website de productos OGC www.best-management-practice.com. Otros tópicos y guías de gestión están disponibles en www.ogc.gov.uk/resource_toolkit.asp , las páginas del SD Toolkit de la website de OGC. El ITGI ha publicado las segundas ediciones de IT Governance Implementation Guide Using COBIT and Val IT, una versión de implementación rápida titulada COBIT Quickstart, así como COBIT Security Baseline for implementing IT security , que contiene un mapeo a ISO/IEC 27002. Todas estas publicaciones están alineadas con COBT 4.1. El ITGI también brinda entrenamiento en la forma de utilización de los materiales COBIT, ofreciendo una versión en línea para ayudar a los usuarios a adaptar el material COBIT para utilizarlos en sus propios ambientes. Sin embargo, los usuarios necesitan más guías sobre la forma de integrar los principales marcos de referencia con otras prácticas y estándares. En respuesta a esta necesidad, se han realizado investigaciones para el mapeo de


Pág. 246/321

COBIT con una amplia variedad de otras prácticas. En el 2004, el ITGI emprendió una iniciativa de armonización como parte de su plan de actualización de materiales COBIT. COBIT está basado en marcos de referencia establecidos, tales como CMM de SEI (Software Engineering Institute), ISO 9000, ITIL e ISO/IEC 27002; sin embargo, COBIT no incluye tareas y pasos de procesos porque, aunque está orientado a procesos de TI, es un marco de referencia para gestión y control antes que un marco de referencia para procesos. COBIT se focaliza en lo que una empresa necesita hacer, no cómo lo tiene que hacer, y la audiencia objetivo es la alta gerencia, los gerentes funcionales, los gerentes de TI y los auditores. ITIL está basado en la definición de procesos de mejores prácticas para la gestión y el soporte de servicios de TI, antes que en la definición de un marco de control de amplio alcance. Se focaliza en el método y define un grupo más compacto de procesos. Existe material adicional en ITIL v3 que proporciona un contexto estratégico y de negocios para la toma de decisiones de TI, y empieza describiendo el mejoramiento continuo del servicio como una actividad integral, promoviendo el mantenimiento de la entrega de valor a los clientes. Debido a su alto nivel, a la amplia cobertura y porque está basado en muchas prácticas existentes, frecuentemente se refiere a COBIT como un ‘integrador’, ubicando diferentes prácticas bajo un solo paraguas, y tan importante como eso, ayudando a enlazar estas varias prácticas de TI con los requerimientos del negocio. Ahora que estos estándares y mejores prácticas están siendo más utilizados en situaciones reales, las experiencias maduran y las organizaciones se mueven desde un caótico enfoque propietario de TI hacia procesos definidos y gestionados. Dado que el gobierno de TI —el concepto y la práctica actual— gana impulso y aceptación, las mejores prácticas de TI estarán mejor alineadas con los requerimientos de gobierno y del negocio, antes que a los requisitos técnicos. El gobierno de TI se ocupa de estas principales áreas de actividad de TI de la siguiente manera:

• El alineamiento estratégico, centrado en el alineamiento de TI con el negocio y con soluciones colaborativas.

• La entrega de valor, concentrado en la optimización de costos y en la demostración del valor de TI. • La gestión de riesgos, considerando el resguardo de los activos de TI (incluyendo la inversión en

proyectos), recuperación de desastres y la continuidad de las operaciones.

• La gestión de recursos, optimizando el conocimiento y la infraestructura de TI. • La medición del desempeño, el seguimiento de la entrega de proyectos y la supervisión de servicios de TI.

Un aspecto clave de cualquier iniciativa de gobierno de TI es la necesidad de definir los derechos para la decisión y la rendición de cuentas. El logro de ambos cometidos en la teoría (la organización está claramente definida) y la práctica (todos saben lo que tienen que hacer y cómo hacerlo) requiere una ® cultura correcta, políticas, controles internos y prácticas definidas. COBIT 4.0 introdujo actividades clave 4 y tablas RACI para todos los procesos de TI a fin de ayudar a guiar los roles y responsabilidades para un gobierno de TI efectivo. Los beneficios para la empresa La adopción eficaz de las mejores prácticas ayudará a obtener valor de las inversiones de TI y los servicios de TI:

• Mejorando la calidad, la respuesta y la fiabilidad de las soluciones y los servicios de TI. • Mejorando la viabilidad, previsibilidad y repetitividad de resultados de negocio exitosos.

• Ganando la confianza y el creciente involucramiento de usuarios y patrocinadores del negocio.

• Reduciendo riesgos, incidentes y fallas en los proyectos. • Mejorando la habilidad del negocio para gestionar y supervisar la realización de beneficios de TI.


Pág. 247/321

La empresa también se beneficia de la mejora de eficiencias y reducción de costos:

• Evitando la reinvención de prácticas probadas. • Reduciendo la dependencia de expertos.

• Incrementando el potencial del staff, menos experto pero correctamente entrenado.

• Superando silos verticales y comportamientos no deseados. • Incrementando la estandarización que conduzca a la reducción de costos.

• Haciéndolo más fácil para aprovechar la ayuda externa a través del uso de procesos estandarizados. En un clima de creciente regulación y preocupación sobre los riesgos relacionados a TI, las mejores prácticas ayudarán a minimizar los aspectos de cumplimiento y la preocupación de los auditores:

• Logrando el cumplimiento y la aplicación de controles internos de ‘práctica normal de negocios’. • Demostrando adherirse a buenas prácticas aceptadas y probadas de la industria.

• Mejorando la confianza y la seguridad de la dirección y los socios.

• Generando respecto de los reguladores y otros supervisores externos. Adoptar las mejores prácticas también ayuda a fortalecer las relaciones proveedor/cliente, resultando en obligaciones contractuales más fáciles de supervisar y reforzar, armonizar contratos de outsourcing multi-proveedor y mejorar la posición de mercado de aquellos proveedor es de servicios que cumplen con estándares globalmente aceptados, tales como ISO/IEC 20000 e ISO/IEC 27002. 4 Las tablas RACI identifican quiénes son Responsables, Responsables de dar cuenta, Consultados e Informados en una determinada actividad (Responsible, Accountable, Consulted and Informed).

5. COBIT, ITIL e ISO/IEC 27002: Lo que ofrecen y consideran COBIT

Los ejecutivos necesitan la certeza de que pueden confiar en los sistemas de información y en la información producida por los sistemas, y así obtener un retorno positivo de las inversiones en TI. COBIT permite que los ejecutivos de negocios entiendan mejor cómo dirigir y gestionar el uso de las TI en la empresa y el estándar de mejores prácticas que se espera de los proveedores de TI. COBIT proporciona las herramientas para dirigir y supervisar todas las actividades relacionadas con las TI. COBIT es un marco de referencia globalmente aceptado para el gobierno de TI basado en estándares de la industria y las mejores prácticas. Una vez implementado, los ejecutivos pueden asegurarse de que se ajusta de manera eficaz con los objetivos del negocio y dirigir mejor el uso de TI para obtener ventajas comerciales. COBIT brinda un lenguaje común a los ejecutivos de negocios para comunicar las metas, objetivos y resultados a los profesionales de auditoría, informática y otras disciplinas. COBIT brinda las mejores prácticas y herramientas para el monitoreo y la gestión de las actividades de TI. El uso de las TI es una inversión importante que debe ser gestionado. COBIT ayuda a los ejecutivos a comprender y gestionar las inversiones de TI durante su ciclo de vida y proporciona un método para evaluar si los servicios de TI y las nuevas iniciativas satisfacen los requisitos empresariales y sea probable que entreguen los beneficios esperados. Existe una tremenda diferencia entre las empresas que realizan una buena gestión de TI y las que no lo hacen, o no pueden. COBIT permite el desarrollo de políticas claras y mejores prácticas para la administración de TI. El marco ayuda a aumentar el valor obtenido de TI. También ayuda a las organizaciones a gestionar los riesgos relacionados con TI y a asegurar el cumplimiento, la continuidad, seguridad y privacidad. Debido a que COBIT es un conjunto de herramientas y técnicas probadas y aceptadas internacionalmente, su implementación es una señal de buena gestión en una organización. Ayuda a los profesionales de TI y a usuarios de empresas a demostrar su competencia profesional a la alta dirección. Como ocurre con muchos procesos de negocio


Pág. 248/321

genéricos, existen estándares y mejores prácticas de la industria de TI que las empresas deberían seguir cuando utilizan las TI. COBIT se nutre de estas normas y proporciona un marco para implementarlas y gestionarlas. Una vez que se identifican e implementan los principios clave de COBIT para una empresa, los ejecutivos ganan confianza en que la utilización de las TI puede ser gestionada de forma eficaz. Los ejecutivos de las empresas pueden esperar los siguientes resultados de la adopción de COBIT:

• Los gerentes y el staff de TI entenderán totalmente como es que el negocio y TI pueden trabajar en forma conjunta para la entrega exitosa de las iniciativas de TI.

• Los costos totales del ciclo de vida de TI serán más transparentes y predecibles.

• TI ofrecerá información más oportuna y de mayor calidad.

• TI entregará proyectos de mejor calidad y más exitosos. • Los requisitos de seguridad y privacidad serán más claros y la implementación será monitoreada con mayor

facilidad.

• Los riesgos de TI serán gestionados con mayor eficacia. • Las auditorías serán más eficientes y exitosas.

• El cumplimiento de TI con los requisitos regulatorios serán una práctica normal de gestión. Las versiones 4.x de COBIT, incluyen lo siguiente:

• Marco de trabajo: Explica cómo es que COBIT organiza la gestión del gobierno de TI, los objetivos de control y las mejores prácticas de los procesos y dominios de TI, y los relaciona con las necesidades del negocio. El marco contiene un conjunto de 34 objetivos de control de alto nivel, uno para cada proceso de TI, agrupados en cuatro dominios: Planificar y Organizar, Adquirir e Implementar, Entregar y dar soporte, Monitorear y Evaluar.

• Las descripciones del proceso incluyen cada uno de 34 procesos de IT, cubriendo las áreas de responsabilidad de la empresa y de TI desde el principio hasta el final.

• Los objetivos de control proveen los objetivos de gestión de las mejores prácticas genéricas para los procesos de TI.

• Las directrices de gestión ofrecen herramientas para ayudar a asignar responsabilidades y medir el desempeño.

• El modelo de madurez proporciona perfiles de los procesos de TI que describen los posibles estados actuales y futuros.

ITIL Hoy, las organizaciones dependen de las TI para satisfacer sus objetivos corporativos y sus necesidades de negocios, entregando valor a sus clientes. Para que esto ocurra de una forma gestionada, responsable y repetible, la empresa debe asegurar que los servicios recibidos de alta calidad de TI deben:

• Satisfacer las necesidades de la empresa y los requisitos de los usuarios. • Cumplir con la legislación.

• Asignarse y entregarse de forma eficaz y eficiente.

• Revisarse y mejorarse de forma continua. La gestión de servicios de TI se refiere a la planificación, aprovisionamiento, diseño, implementación, operación, apoyo y mejora de los servicios de TI que sean apropiados a las necesidades del negocio. ITIL proporciona un marco de trabajo de mejores prácticas integral, consistente y coherente para la gestión de servicios de TI y los procesos relacionados, la promoción de un enfoque de alta calidad para el logro de la eficacia y eficiencia del negocio en la gestión de servicios de TI.


Pág. 249/321

ITIL intenta respaldar mas no fijar los procesos de negocio de una organización. En este contexto, la OGC no aprueba el término "Cumplimiento con ITIL". El papel del marco de trabajo de ITIL es describir los enfoques , las funciones , los roles y procesos en los que las organizaciones pueden basar sus propias prácticas. El rol de ITIL es brindar orientación en el nivel organizacional más bajo que pueda aplicarse. Debajo de ese nivel, para implementar ITIL en una organización se requieren los conocimientos específicos de sus procesos de negocio para ajustar ITIL a fin de lograr una eficacia óptima. Es útil pensar en la estructura de gestión de servicios como una pirámide con el estándar internacional ISO/IEC 20000:2005 (www.iso.org/iso/catalogue_detail?csnumber=41332) en la cima (Figura 2). Se trata de una especificación formal y las organizaciones pueden obtener la acreditación para demostrar el cumplimiento con la norma. Por debajo de la cima está la capa de mejores prácticas de ITIL, que ayuda a asegurar y demostrar que las disposiciones de la norma se están cumpliendo. De manera similar, los procesos de ITIL pueden ser utilizados para lograr y demostrar el cumplimiento con los objetivos de control COBIT (la función de los apéndices del presente documento es mostrar la relación entre las dos estructuras). Así que si ITIL es la capa intermedia, la adaptación de ITIL para satisfacer las necesidades de una organización en particular es el nivel más bajo, la base más amplia de la implementación de ITIL. En ITIL v3, el desarrollo más significativo ha sido el paso de un marco de trabajo basado en procesos a una estructura integral que refleje el ciclo de vida de los servicios de TI. Un ejemplo de uso frecuente es ver las fases operativas de diseño, transición y operación, como los radios de una rueda, con la estrategia en el centro y la mejora continua del servicio alrededor del borde. En este nuevo contexto, los procesos clave se han actualizado, pero más significativo aún, ITIL ahora describe las funciones de gestión, las actividades y la estructura organizativa de los servicios de TI, además de los aspectos de aprovisionamiento y de estrategia, así como la integración con el negocio. Si bien hay volúmenes complementarios con un público específico en mente, la guía principal reside en cinco volúmenes, disponibles por separado o como un conjunto. Los tópicos principales de ITIL se muestran en la Figura 3 . Los vínculos de referencia son:

• Service Strategy (SS): www.best management practice.com/Official Bookshop/IT Service Management ITIL/ITIL Version 3 / Service Strategy

• Service Design (SD): www.best management practice.com/Official Bookshop/IT Service ITIL/ITIL Version 3 / Service Design

• Service Transition (ST): www.best management practice.com/Official Bookshop/IT Service Management ITIL/ITIL Version 3 / Service Transition

• Service Operation (SO): www.best management practice.com/Official Bookshop/IT Service Management ITIL/ITIL Version 3 / Service Operation

• Continual Service Improvement (CSI): www.best management practice.com/Official Bookshop/IT Service Management ITIL/ITIL Version 3 / Continual Service Improvement

ISO/IEC 27002 El estándar internacional fue publicado por la ISO (www.iso.org/ISO/home.htm) y la IEC, que establecieron el comité técnico mixto ISO/IEC JTC 1. La fuente histórica para el estándar fue BS 7799-1, cuyas partes esenciales fueron tomadas en el desarrollo de la norma ISO/IEC 17799:2005 Tecnología de la Información – Código de Prácticas para la Gestión de Seguridad de la Información. Fue desarrollado y publicado por la British Standards Institution (BSI), denominado como BS 7799-1:1999. El estándar original inglés se publicó en dos partes:

• BS 7799 Parte 1: Tecnologías de la Información – Código de Prácticas para la Gestión de Seguridad de la Información.

• BS 7799 Parte 2: Sistemas de Gestión de Seguridad de la Información – Especificaciones con guías para su uso.

La norma publicó su primera edición en el año 2000 y actualizada en junio de 2005. Se puede clasificar como las mejores prácticas actuales en materia de sistemas de gestión de seguridad de la información. La BS 7799 original fue


Pág. 250/321

revisada y reeditada en septiembre de 2002. A menudo se utiliza ISO/IEC 27002 como un término genérico para describir lo que actualmente son dos documentos diferentes:

• ISO/IEC 17799 (ahora renombrada como ISO 27002, www.iso.org/ISO/iso_catalogue/catalogue_tc/ catalogue_detail. Htm?csnumber = 50297): Un conjunto de controles de seguridad (un código de práctica).

• ISO/IEC 27001 ( www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42103, anteriormente, BS7799-2) – Una especificación estándar para un sistema de gestión de seguridad de información (SGSI).

El objetivo del estándar ISO/IEC 27002:2005 es brindar información a los responsables de la implementación de seguridad de la información de una organización. Puede ser visto como una buena práctica para desarrollar y mantener normas de seguridad y prácticas de gestión en una organización para mejorar la fiabilidad en la seguridad de la información en las relaciones inter organizacionales. En él se definen las estrategias de 133 controles de seguridad organizados bajo 11 dominios. La norma subraya la importancia de la gestión del riesgo y deja claro que no es necesario aplicar cada parte, sino sólo aquellas que sean relevantes. Los principios rectores en la norma ISO/IEC 27002:2005 son los puntos de partida para la implementación de seguridad de la información. Se basan en cualquiera de los requisitos legales o en las mejores prácticas generalmente aceptadas. Las mediciones basadas en los requisitos legales son:

• La protección y la no divulgación de datos personales. • Protección de la información interna.

• Protección de los derechos de propiedad intelectual. Las mejores prácticas mencionadas en la norma incluyen:

• La política de seguridad de la información.

• Asignación de la responsabilidad de seguridad de la información.

• Escalamiento de problemas. • Gestión de la continuidad del negocio.

Cuando se implementa un sistema de gestión de seguridad de la información, se deben considerar varios factores críticos de éxito:

• La política de seguridad, sus objetivos y actividades deberían reflejar los objetivos de negocio.

• La implementación debería considerar los aspectos culturales de la organización. • Se requiere un abierto apoyo y el compromiso de la alta dirección.

• Se requiere un conocimiento exhaustivo de los requisitos de seguridad, evaluación del riesgo y gestión del riesgo.

• El marketing efectivo de la seguridad debe dirigirse a todo el personal, incluidos los miembros de la dirección. • La política de seguridad y las medidas de seguridad deben ser comunicadas a terceros contratados.

• Los usuarios deben ser capacitados en forma adecuada.

• Se debería disponer de un sistema integral y balanceado para la medición del desempeño, que apoye la mejora continua de suministro de información.

Después de presentar información introductoria (ámbito de aplicación, términos y definiciones), se debe presentar un marco de trabajo para el desarrollo de un Sistema de Gestión de Seguridad de Información específico para la empresa, que debería consistir de al menos los siguientes componentes:

• La política de seguridad.

• Organización para la seguridad. • Clasificación de activos y su control.


Pág. 251/321

• Seguridad del personal. • Seguridad física y ambiental.

• Comunicaciones y gestión de operaciones.

• Control de acceso. • Adquisición, desarrollo y mantenimiento de sistemas.

• Gestión de la continuidad del negocio.

• Cumplimiento.

6. ¿Cuál es la mejor forma de implementar COBIT, ITIL e ISO / IEC 27002? No hay duda de que las políticas y procedimientos de gestión eficaces ayudan a asegurar que TI se gestiona como un componente más de las actividades cotidianas. La adopción de estándares y mejores prácticas facilita la rápida aplicación de buenos procedimientos y evita retrasos en la creación innecesaria de nuevos enfoques en los que hay que ponerse de acuerdo. Sin embargo, las mejores prácticas adoptadas han de ser compatibles con un marco de gestión de riesgos y de control apropiado para la organización, debiendo integrarse con otros métodos y prácticas que se estén utilizando. Los estándares y las mejores prácticas no son una panacea; su efectividad depende de cómo se implementen y se mantengan actualizados. Son muy útiles cuando se aplica como un conjunto de principios y como punto de partida para la adaptación de procedimientos más específicos. Para asegurar que las políticas y los procedimientos se utilizan con eficacia, se requiere un cambio de manera que la administración y el personal entiendan qué hacer, cómo hacerlo y por qué es importante. Para que las mejores prácticas sean eficaces, es mejor utilizar un lenguaje común y un enfoque estándar orientado hacia las necesidades reales del negocio, ya que garantiza que todos sigan el mismo conjunto de objetivos, asuntos y prioridades. Elaboración Todas las empresas necesitan adaptar el uso de estándares y prácticas tales como los presentados en este documento, para ajustar sus requisitos individuales. Los tres documentos de guía pueden desempeñar un papel muy útil. COBIT e ISO/IEC 27002 para ayudar a definir qué debería hacerse e ITIL muestra el cómo para los aspectos de la gestión de servicios. Las aplicaciones típicas para este tipo de estándares y prácticas son las siguientes:

• Para apoyar la gobernabilidad a través de: � Proporcionar una política de gestión y un marco de control. � Facilitar el proceso de asignación de propietarios, responsabilidades claras y rendición de cuentas para las

actividades de TI. � Alinear los objetivos de TI con los objetivos del negocio, definiendo prioridades y la asignación de recursos. � Asegurar el retorno de la inversión y optimizar los costos. � Asegurar la identificación de los riesgos significativos y que sean transparentes para la administración,

que se asigna la responsabilidad en la gestión del riesgo y se integre en la organización, y asegurando a la dirección que se han implementado controles eficaces.

� Asegurar que los recursos se han organizado de manera eficiente y que existe suficiente capacidad (infraestructura técnica, procesos y habilidades) para ejecutar la estrategia de TI.

� Asegurar que las actividades críticas de TI pueden ser monitoreadas y medidas, de modo que los problemas puedan ser identificados y que las medidas correctivas puedan ser adoptadas.

• Para definir los requisitos del servicio y las definiciones del proyecto, tanto internamente como

con los proveedores de servicios, por ejemplo:

� Estableciendo objetivos claros de TI relacionados al negocio así como métricas. � Definiendo los servicios y proyectos en términos de usuario final. � Elaborando acuerdos de niveles de servicio y contratos que pueden ser monitoreados por los clientes.


Pág. 252/321

� Asegurando que los requisitos del cliente han sido plasmados apropiadamente en requisitos operativos y técnicos de TI.

� Considerando los portafolios de servicios y de proyectos en conjunto, a fin de establecer las prioridades relativas, de modo que los recursos se asignen de manera equitativa y viable.

• Para verificar la capacidad profesional o demostrar competencia en el mercado a través de: � Las evaluaciones y las auditorías independientes de terceros. � Compromisos contractuales. � Constancias y certificaciones.

• Para facilitar la mejora continua por: � Evaluaciones de madurez. � Análisis de brechas. � Benchmarking. � Planificación de la mejora. � Evitar la reinvención de buenos enfoques ya probados.

• Como marco para la auditoría, evaluación y una visión externa a través de: � Criterios objetivos y mutuamente entendidos. � Benchmarking para justificar las debilidades y brechas en los controles. � Incrementando la profundidad y el valor de las recomendaciones mediante enfoques generalmente aceptados.

Priorización Para evitar implementaciones de estándares y mejores prácticas costosas y fuera de foco, las empresas necesitan priorizar dónde y cómo utilizarlos. La empresa necesita un plan de acción eficaz que se adapte a sus circunstancias y necesidades particulares. En primer lugar, es importante que la Alta Dirección asuma el liderazgo del gobierno de TI y establezca la dirección que la gestión debe seguir. La Alta Dirección debería:

• Asegurarse que TI está en la agenda.

• Cuestionar las actividades de gestión en materia de TI para asegurar que los problemas de TI son revelados.

• Guiar a la administración ayudando a alinear las iniciativas de TI con las necesidades reales del negocio.

• Asegurar que la administración valora el impacto potencial de los riesgos de TI en el negocio.

• Insistir en que el desempeño de TI sea medido y se comunique a la Alta Dirección.

• Establecer un comité de dirección de TI o consejo de gobierno de TI con la responsabilidad de comunicar los aspectos de TI a la Alta Dirección y la administración.

• Insistir en que exista un marco de gestión para el gobierno de TI basada en un enfoque común (por ejemplo, COBIT) y un marco de mejores prácticas para la gestión de servicios TI y seguridad basadas en un estándar global y de facto (por ejemplo, ITIL e ISO/IEC 27002).

Planificación Con el mandato y la dirección en marcha, la administración puede poner en práctica un enfoque de implementación. Para ayudar a que la administración decida dónde empezar y asegurar que el proceso de implementación ofrece resultados positivos en donde más se necesitan, se sugieren los siguientes pasos, basados en la guía IT Governance Implementation Guide del ITGI: 1. Establecer un marco organizativo (idealmente como parte de una iniciativa global de gobierno de TI), con objetivos y responsabilidades claras, la participación de todas las partes involucradas, quienes impulsarán la implementación y la asumirán como una iniciativa propia. 2. Alinear la estrategia de TI con los objetivos del negocio. ¿En cuáles de los objetivos de negocio actuales, TI tiene una contribución significativa? Obtener una buena comprensión del entorno empresarial, el apetito de riesgo, la


Pág. 253/321

estrategia del negocio, y su relación con TI. Las directrices de gestión de COBIT (específicamente los objetivos y las métricas), ayudan a definir los objetivos de TI. Utilizada en conjunto con ITIL, los servicios y los acuerdos de niveles de servicios (ANS) se puede definir en términos de usuario final. 3. Entender y definir los riesgos. Dados los objetivos de negocio, ¿cuáles son los riesgos relativos a la capacidad de TI para cumplirlos? Considerar lo siguiente:

• Antecedentes y patrones de desempeño. • Factores organizacionales actuales de TI.

• La complejidad y el tamaño/alcance de la infraestructura de TI existente o prevista.

• Las vulnerabilidades inherentes de la infraestructura de TI existente o prevista. • La naturaleza de las iniciativas de TI que están siendo consideradas, por ejemplo: nuevos proyectos de

sistemas, consideraciones de outsourcing, cambios en la arquitectura, etc. El proceso de COBIT para la gestión del riesgo (PO9) y la aplicación del marco de control de COBIT y los criterios de información, ayudarán a asegurar que los riesgos se identifican y se asignan. Implementar ITIL aclara los riesgos operativos y la norma ISO/IEC 27002 clarifica los riesgos de seguridad. 4. Definir las áreas objetivo y determinar las áreas de proceso de TI que son críticos para la entrega de

valor y gestionar estas áreas de riesgo. El marco de procesos COBIT puede ser utilizado como la base, respaldado por la definición en ITIL de los procesos clave de entrega de servicio y los objetivos de seguridad de la ISO/IEC 27002. La publicación Management of Risk: Guidance to Practitioner de la OGC también puede ser de ayuda en la evaluación y gestión de los riesgos en cualquiera de los cuatro niveles principales (estratégico, programa, proyecto u operativo). 5. Analizar la capacidad vigente e identificar las brechas. Realizar una evaluación de la capacidad de madurez para saber dónde es que más se necesitan mejoras. Los modelos de madurez de COBIT proporcionan una base soportada con más detalle en ITIL y las mejores prácticas de ISO/IEC 27002. 6. Desarrollar estrategias de mejora y decidir cuáles son los proyectos de mayor prioridad que ayudarán a

mejorar la gestión y el gobierno de estas áreas importantes. Esta decisión debe basarse en el beneficio potencial y la facilidad de implementación, enfocado en los procesos importantes de TI y en las competencias básicas. Se deberían perfilar proyectos específicos de mejora como parte de una iniciativa de mejora continua. Los objetivos de control de COBIT y las prácticas de control pueden ser apoyados por ITIL con mayor detalle y las guías de ISO/IEC 27002. 7. Medir los resultados, estableciendo un mecanismo de puntuación para medir el desempeño actual y monitorear los resultados de nuevas mejoras, considerando como mínimo, las siguientes preguntas clave:

• ¿La estructura organizacional apoyará la implementación de la estrategia?

• ¿Las responsabilidades de la gestión de riesgos están integradas en la organización?

• ¿Existe infraestructura que facilite y apoye la creación y el intercambio de información comercial vital? • ¿Se han comunicado las estrategias y los objetivos de manera efectiva a todos los que necesitan saber en la

organización? Los objetivos y las métricas de COBIT y el enfoque de mejora continua de siete pasos de ITIL pueden formar la base de un sistema de puntuación. 8. Repetir los pasos 2 a 7 con una frecuencia regular. Evitar obstáculos Existen otras reglas obvias pero pragmáticas que la administración debe seguir:

• Tratar la iniciativa de implementación como una actividad de proyecto con una serie de fases en lugar de un solo esfuerzo extraordinario.

• Recuerde que la implementación supone un cambio cultural, así como nuevos procesos. Por lo tanto, un factor clave de éxito es facilitar y motivar estos cambios.

• Asegúrese de que haya una comprensión clara de los objetivos.


Pág. 254/321

• Manejar las expectativas. En la mayoría de las empresas, lograr la supervisión exitosa de TI toma tiempo y es un proceso de mejora continua.

• Concéntrese primero en las áreas donde es más fácil hacer cambios y lograr mejoras, y desde allí, construir paso a paso.

• Obtener el respaldo de la Alta Dirección. Esto necesita estar basado en los principios de la mejor gestión de las inversiones de TI.

• Evitar las iniciativas que se perciben como un ejercicio puramente burocrático. • Evitar listas de verificación fuera de foco.


Pág. 255/321

IIInnnttteeegggrrraaaccciiióóónnn dddeee IIITTTIIILLL cccooonnn PPPMMMBBBOOOKKK �� PPPMMMIII...

Resumen Ejecutivo La importancia que las TI han alcanzado hoy en día es enorme. Ha dejado de ser una herramienta de soporte y/o un área accesoria para convertirse en algo totalmente necesario para cualquier empresa. Hoy en día es impensable concebir una empresa que no use las tecnologías de la información para la gestión diaria; desde las formas más básicas como el uso de una hoja Excel o del correo electrónico hasta implantaciones de inteligencia de negocios y minería de datos. Así, son muchos los problemas que se presentan al gestionar estas Tecnologías de la Información. Especial importancia reviste el cómo lograr que las TI sean una ventaja para la organización, que sean una inversión con retorno y no solamente un gasto necesario. Una respuesta a esta necesidad son los marcos de trabajo y mejores prácticas: COBIT, ITIL, CMMI, PMBOK, por ejemplo. Estas mejores prácticas se han convertido en estándares de la industria, en una necesidad para aquellas empresas que deseen gestionar eficientemente las TI, y lograr ventajas de negocio de las mismas. Su objetivo final es dar gobernabilidad a las TI. El documento que presentamos, aborda la relación que existe entre la gestión de proyectos bajo PMBOK y los procesos de soporte de servicios de ITIL.

1. Descripción Conceptual Como se mencionó anteriormente, los problemas al gestionar las TI son diversos y se presentan en distintas materias. A continuación se detallan los principales. 1.1. Mala gestión de proyectos TI

Toda iniciativa de TI que se desee implementar se debe gestionar como un proyecto, es decir, debe tener un cronograma, presupuesto y recursos determinados. Sin embargo, no siempre estos proyectos acaban según lo esperado o planificado. Varias son las razones por qué puede fracasar un proyecto de este tipo:

• Falta de compromiso y apoyo de la alta dirección.

• Toma de requerimientos y definición de alcances equivocados o incompletos.

• Carencia de un sistema de control de cambios. Una mala gestión de proyectos acarrea pérdidas económicas para una compañía: sobrecostos, productos que no se ajustan a las necesidades requeridas, personal involucrado con baja moral, y otros. 1.2. Gestión de servicios inadecuada

La infraestructura de TI de toda empresa (hardware y aplicaciones de software), tiene una sola finalidad: dar el soporte necesario para obtener beneficios tangibles, basados en la información. Por ello los servicios que dicha infraestructura ofrezca ya sea a los empleados de la organización o a los clientes externos, deben brindarse de manera eficiente, en términos de velocidad, calidad y disponibilidad. Lo que se ve en muchas compañías es que esta gestión de los servicios de TI se hace de manera desorganizada, sin un esquema de trabajo, sin métricas, sin indicadores ni metas específicas por cumplir. Las consecuencias del mal manejo de los servicios TI son: • • • • Falta de procesos de control y monitorización. Métodos de desarrollo de software inadecuados. Falta de alineamiento estratégico para las iniciativas TI. Inversiones en TI que no generan beneficios tangibles Por ello, se hace necesario un marco de trabajo que gestione de manera profesional dichas inversiones en TI, para así generar utilidades financieras para la compañía. 1.3. Respuesta de la Industria

Teniendo en cuenta los problemas mencionados, se han desarrollado varios modelos para su minimización. Es decisión de cada compañía determinar el mejor modelo de gestión, el que mejor se adapte a sus necesidades y políticas empresariales.

ITIL V.3

A continuación se describen los estándares sobre aceptados y usados para la resolución de los problemas mencionados en los puntos anteriores. 1.4. Gestión de proyectos con PMBOK

La gestión de proyectos basados en el marco de trabajo PMBOKmodelo más difundido y aceptado para la gestión de proyectos en general (no sólo proyectos de TI). Dicho modelo se basa en un conjunto de buenas prácticas divididas en 9 áreas de conocimiento, cada actividades (44 en total). Lo importante de este modelo es que nos brinda un esquema de trabajo para gestionar cada aspecto de un proyecto: desde gestión del alcance, hasta gestión de las adquisiciones.

Es importante mencionar que cada organización debe determinar que partes del marco de trabajo de PMBOK es aplicable a su compañía. Esto dependerá de la envergadura y nivel de detalle y control que se desee tener en cada proyecto. Se debe pensar en PMBOK como un conjunto puede alimentar para establecer una metodología de 1.5. Information Technology and Infrastructure Library (ITIL)

ITIL es el estándar más ampliamente conocido para la gestión dun alto nivel de disponibilidad de dichos servicios y un alto nivel de satisfacción de clientes y empleados de la compañía. ITIL se centra en brindar servicios de alta calidad para lograr la máximaParte de un enfoque estratégico basado en el triángulo procesosforma de ejecutar procesos estándar ayudados de la tecnología, para lograr la satisfacción los servicios de TI. La gestión de servicios con ITIL tiene su columna vertebral en la función de Service Desk, la cual es el punto único de contacto entre la organización y el usuario o cliente del servicio. Tener un sistema servicios basado en ITIL permitirá a la compañía:

• Tener un mayor alineamiento de TI con el negocio / enfoque a clientes. • Resolver de incidencias y problema más rápido y eficiente

• Reducir del número de llamadas al Service Desk.

• Aumentar el ratio de resolución de incidencias en primera instancia.

Manual Técnico

A continuación se describen los estándares sobre los cuales versa este documento; estos, son los más comúnmente aceptados y usados para la resolución de los problemas mencionados en los puntos anteriores.

1.4. Gestión de proyectos con PMBOK

La gestión de proyectos basados en el marco de trabajo PMBOK, creado por el Project Management Institute (PMI), es el modelo más difundido y aceptado para la gestión de proyectos en general (no sólo proyectos de TI). Dicho modelo se basa en un conjunto de buenas prácticas divididas en 9 áreas de conocimiento, cada una de las cuales se subdivide en actividades (44 en total). Lo importante de este modelo es que nos brinda un esquema de trabajo para gestionar cada aspecto de un proyecto: desde gestión del alcance, hasta gestión de las adquisiciones.

encionar que cada organización debe determinar que partes del marco de trabajo de PMBOK es aplicable a su compañía. Esto dependerá de la envergadura y nivel de detalle y control que se desee tener en cada proyecto. Se debe pensar en PMBOK como un conjunto de lineamientos generales, de los cuales una organización se puede alimentar para establecer una metodología de trabajo propia.

1.5. Information Technology and Infrastructure Library (ITIL)

ITIL es el estándar más ampliamente conocido para la gestión de servicios TI. Una correcta gestión de servicios permite un alto nivel de disponibilidad de dichos servicios y un alto nivel de satisfacción de clientes y empleados de la compañía.

ITIL se centra en brindar servicios de alta calidad para lograr la máxima satisfacción del cliente a un costo manejable. Parte de un enfoque estratégico basado en el triángulo procesos personas tecnología. En otras palabras: determina la forma de ejecutar procesos estándar ayudados de la tecnología, para lograr la satisfacción de los usuarios y clientes de los servicios de TI. La gestión de servicios con ITIL tiene su columna vertebral en la función de Service Desk, la cual es el punto único de contacto entre la organización y el usuario o cliente del servicio. Tener un sistema servicios basado en ITIL permitirá a la compañía:

Tener un mayor alineamiento de TI con el negocio / enfoque a clientes. problema más rápido y eficiente.

Reducir del número de llamadas al Service Desk.

ratio de resolución de incidencias en primera instancia.

Pág. 256/321

; estos, son los más comúnmente

, creado por el Project Management Institute (PMI), es el modelo más difundido y aceptado para la gestión de proyectos en general (no sólo proyectos de TI). Dicho modelo se

una de las cuales se subdivide en actividades (44 en total). Lo importante de este modelo es que nos brinda un esquema de trabajo para gestionar cada

encionar que cada organización debe determinar que partes del marco de trabajo de PMBOK es aplicable a su compañía. Esto dependerá de la envergadura y nivel de detalle y control que se desee tener en cada

de lineamientos generales, de los cuales una organización se

e servicios TI. Una correcta gestión de servicios permite un alto nivel de disponibilidad de dichos servicios y un alto nivel de satisfacción de clientes y empleados de la compañía.

satisfacción del cliente a un costo manejable. tecnología. En otras palabras: determina la

de los usuarios y clientes de los servicios de TI. La gestión de servicios con ITIL tiene su columna vertebral en la función de Service Desk, la cual es el punto único de contacto entre la organización y el usuario o cliente del servicio. Tener un sistema de gestión de


Pág. 257/321

• Gestionar una rápida implantación de cambios y un mejor control de estos. • Reducir el número de cambios que se requieran.

2. Integración de ITIL con PMBOK Comenzaremos destacando que la primera relación que existe entre ambos estándares es que una implementación de ITIL se debe hacer aplicando las prácticas de administración de proyectos, por ejemplo PMBOK. Las razones son variadas:

• Se requiere una visión general del proyecto. • Permite la justificación del proyecto, al presentarlo como un caso de negocio. Identifica a un gerente del

programa / proyecto.

• Facilita la formación de un equipo para el proyecto.

• Identifica con claridad el patrocinador ejecutivo, los patrocinadores del programa/proyecto, el equipo principal, el equipo de diseño, el propietario del proceso.

• Permite hacer un plan y un programa del proyecto. Permite su administración de acuerdo a un plan. A parte de la relación indicada anteriormente, ITIL y PMBOK poseen similitudes:

• Entregan un cuerpo de conocimiento y mejores prácticas en sus respectivos campos.

• Apoyan a los profesionales en sus respectivos campos. • Tienen un crecimiento y aceptación global, ya que son revisadas por profesionales en el área a nivel mundial.

• Son escalables y adaptables.

• Reconocen el rol clave de las personas y factores culturales. • Incluyen muchos de los mismos elementos aplicados a diferentes dominios.

• Ambas están orientadas a procesos. • Exponen la utilidad de los framework en las organizaciones.

• Ponen énfasis en la educación y certificación tanto a nivel introductorio como avanzado.

• Ambas acentúan el conocer el contexto y el valor de la integración. • Son independientes de tecnologías o herramientas / permiten utilizar las que estén disponibles.

• Buscan profesionalizar áreas que con frecuencia son administradas de manera no profesional.

• Ambas atacan puntos focales de atención en las empresas Ofrecen un lenguaje común y estandarizado. • No son prescriptivos sino descriptivos.

• Se adaptan a diferentes empresas, según tamaño, mercado, Se apoyan en el modelo de Deming para la mejora continua (Plan? Do? Check? Act? = PDCA).

ITIL está enfocado al ambiente IT, en cambio PMBOK se aplica a cualquier dominio. PMBOK trata cualquier dominio de gerencia que requiera la “gerencia” de un esfuerzo temporal, ITIL se aplica a la administración continua de servicios IT. PMBOK a diferencia de ITIL, está centrada en un profesional en forma individual. PMBOK posee un código de ética, ITIL no lo posee. ITIL está enfocado en las operaciones, se apoya en proyectos (PMBOK), para la implementación de iniciativas de mejores prácticas, implementación y mejoras en los procesos y en los servicios. A continuación, diremos como cada uno de estos estándares se constituye. PMBOK, como se muestra en la figura N°1, posee 9 áreas de conocimiento y 44 procesos. Estas áreas de conocimiento proveen un conjunto de las mejores prácticas en la gestión de proyectos. Cada área tiene 5 procesos: • • Iniciación. Define y autoriza el proyecto o una fase del mismo. Planificación. Define y refina los objetivos, planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto. Ejecución. Integra a personas y otros recursos para llevar a cabo el plan de gestión del proyecto. Seguimiento y Control. Mide y supervisa regularmente el avance, a fin de identificar las variaciones respecto del plan de gestión del proyecto, de tal forma que se tomen medidas correctivas cuando sea necesario para cumplir con los objetivos del proyecto. Cierre. Formaliza la aceptación del producto, servicio o resultado, y termina ordenadamente el proyecto o una fase del mismo.


Pág. 258/321

A continuación, diremos como cada uno de estos estándares se constituye. PMBOK, como se muestra posee 5 áreas de conocimiento y 46 procesos. Estas áreas de conocimiento proveen un conjunto de las mejores prácticas en la gestión de proyectos. Cada área tiene 5 procesos:

• Iniciación. Define y autoriza el proyecto o una fase del mismo.

• Planificación. Define y refina los objetivos, planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto.

• Ejecución. Integra a personas y otros recursos para llevar a cabo el plan de gestión del proyecto.

• Seguimiento y Control. Mide y supervisa regularmente el avance, a fin de identificar las variaciones respecto del plan de gestión del proyecto, de tal forma que se tomen medidas correctivas cuando sea necesario para cumplir con los objetivos del proyecto.

• Cierre. Formaliza la aceptación del producto, servicio o resultado, y termina ordenadamente el proyecto o una fase del mismo.

En forma creciente en las empresas se están constituyendo las oficinas de administración de proyectos conocidas como PMO por sus siglas en inglés. Como lo indica PMBOK, “el rol de estas oficinas puede variar de una empresa a otra desde una influencia de asesoramiento, limitada a la recomendación de políticas y procedimientos específicos sobre proyectos individuales, hasta una concesión formal de autoridad por parte de la dirección ejecutiva. En dichos casos, la PMO puede, a su vez, delegar su autoridad al director del proyecto individual. El director del proyecto tendrá soporte administrativo de la PMO a través del personal dedicado o a través de personal compartido. El equipo del proyecto incluirá miembros que estarán dedicados al proyecto o personal que se comparta con otros proyectos y que, a su vez, estén dirigidos por la PMO”. Otro concepto en el ámbito de PMBOK es el Portafolio de Proyectos que se define como “un conjunto de proyectos o programas y otros trabajos, que se agrupan para facilitar la gestión efectiva de ese trabajo, a fin de cumplir con los objetivos estratégicos de negocio. Los proyectos o programas del portafolio no necesariamente tienen que ser interdependientes o estar directamente relacionados. La recaudación y el respaldo pueden asignarse sobre la base de categorías de riesgo / recompensa, líneas de negocio específicas o tipos generales de proyectos, como la mejora de la infraestructura y del proceso interno. Las organizaciones gestionan sus portafolios sobre la base de metas específicas. Una de las metas de la gestión del portafolio es maximizar el valor del portafolio evaluando con cuidado los proyectos y programas candidatos a ser incluidos en el portafolio, y la exclusión oportuna de proyectos que no cumplan con los objetivos estratégicos del portafolio. Otras metas son equilibrar el portafolio entre inversiones incrementales y radicales, y usar los recursos de forma eficiente. Los altos gerentes o altos equipos de dirección, por lo general, asumen la responsabilidad de la gestión del portafolio para una organización”. ITIL se compone de varios servicios, ellos son:

� EEEEEEEEssssssssttttttttrrrrrrrraaaaaaaatttttttteeeeeeeeggggggggiiiiiiiiaaaaaaaa ddddddddeeeeeeee SSSSSSSSeeeeeeeerrrrrrrrvvvvvvvviiiiiiiicccccccciiiiiiiioooooooo. Provee una guía de cómo diseñar, desarrollar e implementar la gestión de servicios. Incluye la gestión financiera, administración del portafolio de servicios y los procesos de gestión de demanda.

� DDDDDDDDiiiiiiiisssssssseeeeeeeeññññññññoooooooo ddddddddeeeeeeeellllllll SSSSSSSSeeeeeeeerrrrrrrrvvvvvvvviiiiiiiicccccccciiiiiiiioooooooo. Provee una guía para el diseño y desarrollo de servicios y el proceso de administración de servicios. Incluye la administración del catálogo de servicios, administración del nivel de servicios (SLM), administración de capacidad y disponibilidad, administración de la continuidad del servicio TI (ITSCM), administración de la seguridad de la información y de proveedores.

� SSSSSSSSeeeeeeeerrrrrrrrvvvvvvvviiiiiiiicccccccciiiiiiiioooooooo ddddddddeeeeeeee TTTTTTTTrrrrrrrraaaaaaaannnnnnnnssssssssiiiiiiiicccccccciiiiiiiióóóóóóóónnnnnnnn. Provee una guía para el desarrollo y mejoramiento de la capacidad de traspaso de

servicios nuevos o cambios en los existentes en los ambientes de producción. Incluye la administración de cambio, de mantención de activos, de configuración, de versiones, de instalación, servicios de validación y de pruebas y de administración de conocimiento.

� SSSSSSSSeeeeeeeerrrrrrrrvvvvvvvviiiiiiiicccccccciiiiiiiioooooooossssssss ddddddddeeeeeeee OOOOOOOOppppppppeeeeeeeerrrrrrrraaaaaaaacccccccciiiiiiiioooooooonnnnnnnneeeeeeeessssssss. Incluye prácticas en la gestión de la operación del servicio. Incluye administración de

aplicaciones, de tecnología, de operaciones, funciones de administración de “service desk”.


Pág. 259/321

� MMMMMMMMeeeeeeeejjjjjjjjoooooooorrrrrrrraaaaaaaa CCCCCCCCoooooooonnnnnnnntttttttt iiiiiiiinnnnnnnnuuuuuuuuaaaaaaaa ddddddddeeeeeeeellllllll SSSSSSSSeeeeeeeerrrrrrrrvvvvvvvviiiiiiiicccccccciiiiiiiioooooooo. Provee una guía para la creación y mantención del valor para los clientes a través de una continua evaluación y mejoramiento de la calidad de los servicios y de la madurez total del ciclo de vida del ITSM y los procesos asociados. Combina principios, prácticas y métodos de la gerencia de calidad, de la gerencia del cambio y de la mejora de la capacidad, trabajando para mejorar cada etapa en el ciclo vida del servicio, así como los servicios actuales, los procesos, y las actividades y la tecnología relacionadas.

En ITIL existe un concepto que se denomina Administración del Portafolio de Servicios (SPM), cuya función es administrar proactivamente la inversión a través de los ciclos de vida de los servicios, es un proceso dinámico que incluye lo siguiente:

• Define: inventario de servicios, asegura los casos del negocio y valida los datos del portafolio. • Analiza: maximiza el valor del portafolio alineando y priorizando las iniciativas respecto del valor que entregan

al negocio. Aprueba: autoriza servicios y recursos para algunas iniciativas del portafolio.

• Informa: comunica las decisiones y asigna los recursos. Cabe destacar que no existe una fase equivalente de Cierre en ITIL como en PMBOK, esto se debe a que los proyectos como lo define PMBOK corresponden a un esfuerzo temporal que define un comienzo y término mientras que ITIL es una operación que nunca termina. Los servicios y los procesos requeridos están constantemente monitoreados, medidos y mejorados. Entonces, el cierre en ITIL V3 puede corresponder al retiro de un servicio. También se puede establecer una equivalencia entre PMBOK e ITIL respecto de la administración de los proyectos: En el caso de PMBOK, existe una PMO que administra el portafolio de proyectos a ejecutar, en el caso de ITIL existe un organismo denominado Comité Asesor de Cambios (CAB) que lo constituyen personas que representan a todas las áreas de TI de las áreas de negocio, su propósito es evaluar los cambios a realizar según impacto, necesidades del negocio, costo, beneficio y riesgo. Esta es la segunda similitud entre ambos estándares. La tercera relación entre ITIL y PMBOK se da en la Gestión de Cambios y Versiones que posee la primera correspondiente al Servicio de Transición. La Gestión de Cambios tiene como finalidad garantizar el uso de métodos y procedimientos estandarizados para manejar eficaz y oportunamente todos los cambios, minimizando el impacto de los incidentes relacionados con los cambios y mejorando las operaciones diarias. Dentro de sus actividades se encuentran:

� Registro y Filtrado de Cambios. � Asignación de Prioridades. � Categorización de Cambios. � Evaluación de Impactos y Recursos. � Aprobación de Cambios. � Programación de Cambios. � Coordinación de la construcción, prueba e implantación. � Revisión de Cambios. � Revisión de Post Implantación.

La Gestión de Versiones Permite una visión integral de un cambio a un servicio de IT y debe asegurar que se consideren en conjunto, tanto los aspectos técnicos como los no técnicos de una versión. Su objetivo es planear y controlar exitosamente la instalación de Software y Hardware bajo tres ambientes: ambiente de desarrollo, de pruebas controladas, y ambiente real. Los entregables de un proyecto gestionado con el modelo PMBOK pueden ser producidos y gestionados también usando el modelo ITIL para gestión de servicios. La gestión de servicios brinda un conjunto de procesos para garantizar el correcto funcionamiento de la infraestructura TI de la organización. Esta gestión de servicios involucra manejar adecuadamente los errores que puedan suceder (gestión de incidentes) y realizar ajustes en dichos servicios e infraestructura. Dichos ajustes no son ni más ni menos que proyectos de actualización de los servicios TI, que pueden ser manejados siguiendo los procesos estándar de PMBOK o con aquellos que el mismo modelo ITIL propone. Por ello, el principal punto de intersección entre ITIL y PMBOK se encuentra en el proceso de gestión del cambio.


Pág. 260/321

Señalaremos que los términos y nomenclaturas usados por cada uno de estos estándares para esta gestión del cambio varían en cada modelo. Por ejemplo: el término CCB (Change Control Board) de PMBOK es equivalente al término Change Advisory Board (CAB) de ITIL. Pero finalmente, ambos poseen actividades similares para realizar dicha gestión del cambio. El enfoque de ITIL para el manejo del cambio es orientado a garantizar la disponibilidad y operatividad del servicio dentro del contexto de un determinado Acuerdo de Nivel de Servicio, firmado con el cliente del servicio. Por otro lado, el enfoque de PMBOK respecto a esta gestión de cambios es garantizar la calidad dentro del marco de restricción que todo proyecto debe considerar:

� costo, � tiempo, � calidad � y riesgos.

Podemos decir entonces, que estos dos estándares son complementarios y superpuestos a la vez, dependiendo del enfoque que quiera dar la organización en los procesos de intersección. Se pueden usar ambos modelos en conjunto para gestionar servicios basado en ITIL y gestionar los cambios en dichos servicios usando PMBOK. Tanto la Gerencia de Proyectos como la Administración de Servicios de TI son áreas fundamentales para el éxito del Negocio. Un Proyecto no genera valor hasta que está en Operación. Los Servicios de TI exitosamente implementados son producto de Proyectos exitosos, que contemplan en sus planes la visión del negocio y de la operación continua de la solución.

3. Conclusiones Existe un sin número de estándares y marcos de trabajo para el gobierno de las TI. Se debe saber como analizar y seleccionar aquellos que mejor se adapten a cada organización. Se debe tener presente que los estándares pueden ser o no compatibles. Cada uno de ellos fue creado por personas diferentes, en tiempos distintos, en lugares distintos y con propósitos distintos. Por ello, a pesar de que puedan haber varios estándares que den solución a determina problemática, cada uno de ellos fue creado para resolver un matiz específico de dicha problemática, con un enfoque específico y con un nivel de granularidad distinto. El reto se encuentra en saber que partes de cada estándar o modelo es para cada compañía. Es de primordial importancia el saber elegir las mejores prácticas, procesos y estrategias entre todos estos modelos. A partir de las elecciones realizadas, se generará un modelo personalizado y adaptado totalmente para una organización en particular. La cantidad de estándares y la necesidad de analizarlos y elegir lo mejor para el uso dentro de la compañía, plantea distintos retos. Por lo tanto, debemos considerar lo siguiente:

� Integrar dichos estándares es muchas veces un rompecabezas. � Se puede producir sobrecarga de mejores prácticas y procedimientos. � Los costos de adopción. � Una adopción incompleta. � El tiempo requerido. � Capacitación / educación requerida y resistencia cultural. � Liderazgo y momento ideal para proponer e implantar determinado estándar.

Una buena razón para usar estos estándares y realizar una integración entre ellos, es ayudar a la organización a cumplir sus objetivos de negocio. Hay muchos estándares, y la lista seguirá creciendo. No todos pueden usarse en conjunto, lo que crea retos de integración por resolver. Se pueden adaptar partes de cada estándar y usarlas de manera personalizada en cada organización, pero no hay una manera única de hacerlo ni recetas mágicas para decidir que usar y como usarlo; pero sí guías y mucha documentación de ayuda y soporte. Cada compañía deberá elegir su propio “mix” de buenas prácticas según sus políticas, experiencia y capacidad. Finalmente, diremos que existe una problemática en la gestión de las TI en las empresas. Los estándares ayudan a solucionar dichos problemas, pero no necesariamente se deben usar todos, hay que saber cuáles usar y de qué manera integrarlos.


Pág. 261/321

IIISSSOOO 222000000000000... Resumen La existencia de normas internacionales para la gestión de servicios de TI. permite a las organizaciones de todo el mundo trabajar en colaboración y les ofrece unas directrices de gran valor para reafirmar su credibilidad en el mercado. Una nueva norma recientemente publicada, la ISO 20000, ofrece a las compañías la oportunidad de demostrar a sus clientes y accionistas la integridad y seguridad de sus operaciones, y promueve una cultura de mejora continua de la calidad en materia de gestión de servicios tecnológicos. ¿Por qué es tan importante? Porque obtener la certificación ISO 20000 proporciona a las empresas una ventaja competitiva que no tienen aquellas que no disponen de esa acreditación. Esta versión de la norma ISO 20000 plantea una pregunta a las organizaciones de todo el mundo: ¿qué debe hacer una empresa con respecto a la certificación ISO 20000? El objetivo de este documento es ayudar a responder a esta pregunta a lo largo de diferentes secciones dedicadas a:

� Describir la evolución de la norma ISO 20000. � Proporcionar una visión general del contenido de esta norma. � Explicar el impacto que puede tener la certificación ISO 20000 para las organizaciones. � Examinar la necesidad de automatizar las operaciones para responder a los requisitos de la norma y los

criterios que una solución de automatización debería cumplir. � Proponer medidas que las organizaciones pueden adoptar ahora con el fin de prepararse para obtener la

certificación ISO 20000. La evolución natural Las organizaciones que centren su estrategia en una mejora continua de la gestión de servicios de TI. se beneficiarán del cumplimiento de la última norma publicada por la organización internacional de normalización ISO (International Organization for Standards), la ISO 20000. Este nuevo estándar promueve la adopción de un modelo de procesos integrados destinado a mejorar la eficacia en la prestación de los servicios tecnológicos y establece las directrices para una gestión de servicios de TI de calidad. La publicación de la ISO 20000 demuestra que las Tecnologías de la Información (TI.) han llegado a un punto de madurez que obliga a la mayoría de las organizaciones a adoptarlas para poder sobrevivir. La documentación donde se definen las especificaciones de la norma se publicó en 2005 y se espera que los procesos de certificación se formalicen en 2006. La nueva norma se basa en la norma británica BS 15000 y está estrechamente ligada al modelo ITIL® (IT Infrastructure Library). La ISO 20000 es un código que proporciona las bases para medir y validar el éxito de una organización a la hora de implementar las buenas prácticas definidas por ITIL. Las compañías que cumplan o se estén preparando para cumplir la especificación BS 15000, o bien estén implementando el modelo ITIL, habrán recorrido ya gran parte del camino para conseguir la certificación ISO 20000 y, por consiguiente, para reforzar su credibilidad ante el mercado. La ISO 20000, que sustituye a la norma BS 15000, proporciona una fórmula estándar para verificar que las organizaciones han adoptado las mejores prácticas de Gestión de Servicios de TI. según lo establecido por el modelo ITIL, que ha estado actuando como estándar de facto en materia de gestión de servicios durante casi 20 años. La BS 15000, una norma británica publicada por primera vez en el año 2000 para impulsar la adopción de un modelo de procesos integrados destinado a una prestación más eficaz de los servicios tecnológicos, se basa en el modelo ITIL. Por último, la ISO 20000 se creó a partir de la BS 15000 (vía ‘fast track’). Puede haber otras normas, prácticas y modelos que hayan servido de referencia para la elaboración de la nueva norma, pero en este documento nos centraremos únicamente en los más relevantes: ITIL, COBIT y BS 15000.


Pág. 262/321

ITIL ITIL se compone de un conjunto de siete libros que, de una forma integrada y coherente, definen las mejores prácticas para la gestión de las diferentes áreas de servicios de TI. Sus directrices están pensadas para adaptarse a las necesidades específicas de cada organización. El modelo ITIL pertenece y depende del Office of Government Commerce (OGC) de Gran Bretaña. COBIT El control de los procesos tecnológicos se está convirtiendo en una parte esencial de las relaciones de negocio prácticamente en toda la industria y son esenciales para implementar las mejores prácticas ITIL y, de esta forma, obtener la certificación ISO 20000. Por ejemplo, el “Institute of Chartered Accountants” de Inglaterra y Gales ha publicado una guía de implementación de los requisitos de control internos como parte del código de principios de gobierno corporativo (Combined Code on Corporate Governance). Esta guía, titulada “Internal Control: Guidance for Directors on the Combined Code”, ha recibido el respaldo de la Bolsa de Londres, cuyos representantes han afirmado que “El sistema de control interno de cualquier compañía cumple una función fundamental en la gestión de riesgos que son esenciales para el logro de sus objetivos de negocio”. Por su parte, el PCAOB (Public Company Accounting Oversight Board) de EE.UU., que se constituyó a raíz de la Ley Sarbanes-Oxley de 2002 para supervisar las auditorías de las empresas privadas, cita específicamente la importancia de los sistemas de TI. Y los controles generales sobre los procesos tecnológicos como parte de sus directrices de auditoría publicadas con fecha del 9 de marzo de 2004. Finalmente, el ITGI (IT Governance Institute) ha elaborado un marco de control de la tecnología de la información bajo el nombre de Control Objectives for Information and related Technology (COBIT), que proporciona a las organizaciones una serie de directrices de gobierno de TI. para aplicar controles sobre sus procesos tecnológicos. COBIT establece un conjunto de 34 objetivos de control de las TI. De alto nivel, 13 de los cuales se basan directamente en el modelo ITIL. Estos objetivos figuran en la Tabla 1 y se clasifican por dominio. BS 15000 La norma BS 15000, estrechamente ligada a ITIL, establece una serie de requisitos mínimos que una organización debe cumplir para lograr unos procesos de gestión de servicios de TI. eficaces. También proporciona un nivel de calidad auditable para esos procesos. Abarca cinco grandes grupos de procesos: prestación de servicios, relaciones, solución de problemas, puesta en producción y control, la mayoría de los cuales se definen con detalle en las mejores prácticas ITIL. La norma ISO 20000 en detalle En mayo de 2005, los miembros de la ISO y la IEC (International Electrotechnical Commission) aprobaron el uso de la BS 15000 como base para la elaboración de la norma ISO 20000. Esto representó un importante paso adelante en el


Pág. 263/321

proceso de normalización, ya que sentaron las bases para conseguir un estándar internacional. La naturaleza de las relaciones entre proveedor y empresa determinará la forma en que se aplicarán los requisitos establecidos en la Parte 1 de la ISO 20000 para cumplir los objetivos generales. El proveedor del servicio puede ser interno o externo a la compañía. El objetivo último de la nueva norma es:

� Reducir la exposición al riesgo derivada de las operaciones � Cumplir las obligaciones contractuales � Demostrar calidad de servicio

La ISO espera que las primeras solicitudes de certificación se produzcan en 2006 y es previsible que sean las organizaciones que ya cuentan con una certificación BS 15000 las primeras en solicitar la ISO 20000 (todas ellas tienen su sede fuera de los EE.UU.). Es de esperar que, a éstas, les sigan otras organizaciones del mundo, incluidas las estadounidenses, lideradas por empresas de sectores en las que las tecnologías de la información juegan un papel fundamental para el desarrollo de su negocio.


Pág. 264/321

El contenido de la norma ISO 20000 se basa en los siguientes documentos de la BS 15000:

• Parte 1: incluye un conjunto de requisitos mínimos y promueve la adopción de un modelo de procesos integrados para realizar una gestión eficaz de los servicios que responda a las necesidades de las empresas y sus clientes.

• Parte 2: contiene un código de prácticas para la gestión de servicios (“Code of Practice for Service Management”) que analiza los elementos fundamentales de las prácticas establecidas por el modelo ITIL. Este documento pretende ayudar a las organizaciones a establecer procesos que cumplan los objetivos de la Parte 1.

Consecuencias de la norma ISO 20000 ¿Qué deben hacer las organizaciones con respecto a la norma ISO 20000? ¿Deben solicitar la certificación? Si no la solicitan, ¿qué medidas deben adoptar teniendo en cuenta la existencia de la nueva norma? Esta sección pretende ayudar a resolver estas cuestiones. ¿Conviene solicitar la certificación? Como hemos mencionado anteriormente, la certificación ISO 20000 sirve para constatar que una empresa ha implantado las mejores prácticas de gestión de servicios de TI., según se demuestra a través de una evaluación externa e independiente realizada por una empresa de auditoría autorizada que toma como referencia la norma. Este nivel de validación puede contribuir a mejorar la competitividad de la empresa. Para decidir si le conviene solicitar la certificación ISO 20000, una organización debería tener en cuenta los siguientes factores:

• La ISO 20000 es particularmente importante para organizaciones de sectores industriales en los que la calidad de los servicios de TI. es fundamental para el éxito del negocio. Esto incluye, entre otros, el sector financiero, el sanitario y el de servicios públicos como son el suministro de agua y electricidad. La certificación permite a las


Pág. 265/321

organizaciones que pertenecen a estas industrias demostrar a sus accionistas y clientes que disponen de una infraestructura tecnológica bien gestionada.

• La ISO 20000 también es importante para organizaciones que prestan servicios gestionados internamente o mediante subcontratación. La certificación les permite garantizar a sus clientes que sus entornos de TI. Se administrarán de la forma adecuada y que recibirán servicios tecnológicos de alta calidad. Los proveedores de servicios deben probar que han documentado las cinco áreas fundamentales previstas por la ISO 20000 y que cumplen todos los requisitos de la norma. La documentación debe incluir las políticas y los planes de gestión de servicios, los acuerdos de nivel de servicio, los procesos y procedimientos exigidos por la norma y sus registros de datos correspondientes.

Las empresas deben tener en cuenta las implicaciones de la certificación con respecto al cumplimiento de la normativa local. Cada vez hay más normas y leyes cuyo cumplimiento es preciso demostrar. Muchas de estas normas, como la ley Sarbanes-Oxley o la ley de portabilidad y responsabilidad de seguros médicos de 1996 (Health Insurance Portability and Accountability Act) de EE.UU. tienen que ver específicamente con los servicios tecnológicos y su gestión. En la actualidad, los inspectores no exigen la presentación de certificaciones como prueba de cumplimiento, pero podrían hacerlo en un futuro. Dado que la ISO 20000 aborda específicamente la calidad de gestión de los servicios de TI., podría convertirse en una norma internacional utilizada por los inspectores para comprobar el cumplimiento de la ley. La certificación ISO 20000 sólo se otorgará a organizaciones que realicen operaciones de gestión de servicios de TI. Y sólo certificará el buen funcionamiento de esas operaciones. Su objetivo no es certificar. Productos ni servicios de consultoría relativos a la aplicación de buenas prácticas. La certificación puede convertirse en un requisito imprescindible para poder hacer negocios con determinadas organizaciones tales como instituciones gubernamentales o empresas que Subcontratan servicios tecnológicos. Organizaciones que no solicitan la certificación: Usar la ISO 20000 como directriz Aunque inicialmente no quieran solicitar la certificación, la documentación de la norma proporciona una valiosa (y económica) fuente de referencia para aquellas organizaciones que hayan adoptado el modelo ITIL y estén implantando o vayan a implantar procesos de gestión de servicios de TI. Basados en las directrices de dicho modelo, ya que proporciona una forma normalizada de medir sus progresos en el proyecto de implantación. Asimismo, las inversiones y el esfuerzo realizados para cumplir la norma ISO 20000 podrán aprovecharse posteriormente en caso de que las organizaciones decidan solicitar finalmente la certificación o quieran demostrar que han implementado un servicio de alta calidad. La importancia de la mejora continúa. Todas las organizaciones deberían tener presente que uno de los objetivos fundamentales del modelo ITIL y, por tanto, de la ISO 20000 es validar la continua mejora de la calidad de la gestión de los servicios. El modelo de mejora permanente de la calidad se basa en los principios de Plan- Ejecución-Verificación-Acción definidos por W. EdwardsDeming y aplicados inicialmente en la industria de la fabricación. Un factor importante para lograr esta mejora contínua es realizar comprobaciones periódicas de la calidad de gestión de los servicios de TI. La ISO 20000 proporciona una forma de verificar qué tal se está comportando una organización en su objetivo de seguir mejorando la calidad de los servicios. La organización puede utilizar la ISO 20000 (y COBIT) para definir y medir sus avances en la consecución de nuevos niveles de mejora a medida que la gestión de los servicios gana en madurez.


Pág. 266/321

Importancia de la automatización para la ISO 20000 Las organizaciones modernas de informática necesitan manejar la complejidad, tanto de la infraestructura de sistemas como de los procesos necesarios para gestionarla. La ya compleja estructura de sistemas de información sigue creciendo a medida que las organizaciones implantan arquitecturas multicapa, arquitecturas orientadas a servicios y tecnologías de virtualización. Internet ha contribuido a aumentar esta complejidad con la introducción de muchos más usuarios, tanto dentro como fuera de los límites de las empresas, que ahora incluyen empleados, clientes y proveedores. Para gestionar estas infraestructuras, muchas organizaciones están adoptando las directrices del modelo ITIL para aplicar las mejores prácticas a los procesos de gestión. ITIL exige el establecimiento de procesos en numerosas disciplinas de la gestión de servicios, así como la integración de esos procesos transversalmente, a lo largo de todas las disciplinas. Es una tarea difícil de abordar a la que se suma la dificultad añadida de tener que conseguir una mejora continua (algo fundamental para la especificación ITIL y la norma ISO 20000). En este contexto tecnológico tan complejo, los procesos manuales no son viables. Las organizaciones necesitan implementar soluciones y herramientas de automatización basadas en sistemas para facilitar la administración de entornos complejos. Ventajas de la automatización La automatización reporta una serie de ventajas importantes:

• Ayuda a garantizar la integración de los procesos. Si la gestión manual favorece la delimitación de los procesos y, con ello, el mantenimiento de “áreas de poder” dentro de la organización, la automatización, por el contrario, favorece la integración de los procesos.

• Asegura la homogeneidad y sistematización de los procesos. Las personas tienden a “adaptar” los procesos manuales con el paso del tiempo para ajustarlos a sus propias necesidades, lo que provoca falta de coherencia. Sin embargo, la automatización permite establecer procesos homogéneos y sistemáticos, y obliga a utilizarlos.


Pág. 267/321

• Agiliza la implementación del modelo ITIL y, potencialmente, acelera la obtención de la certificación ISO 20000. Las soluciones de automatización basadas en ITIL pueden ayudar a la organización a implementar rápidamente las prácticas recomendadas por este modelo y acortar el periodo de obtención de la certificación.

• Ayuda a reducir costes. La automatización puede ayudar a reducir gastos de personal al minimizar los cortes del servicio y asumir la ejecución de funciones rutinarias y repetitivas que normalmente exigirían gran parte del tiempo de los miembros de la plantilla.

• Facilita el cumplimiento de la normativa. La automatización ayuda a las organizaciones a establecer e imponer el uso de buenas prácticas, además de facilitar un registro de auditoría que les permita lograr y demostrar ese cumplimiento. Selección de la solución adecuada Dada la importancia de la automatización para conseguir la certificación ISO 200000, es fundamental para cualquier organización elegir con sumo cuidado la solución que va a implantar. En esta sección se presentan algunas directrices para hacer la elección.

Compatibilidad con el modelo ITIL Dado que el modelo ITIL es fundamental para la ISO 20000, es importante elegir una solución de automatización compatible con los procesos ITIL. La solución debería incorporar procesos que abarquen todas las categorías de la gestión de servicios tecnológicos, esto es: gestión de activos, gestión de los cambios y la configuración, gestión de incidencias y problemas, gestión de lanzamientos, gestión de la capacidad y la disponibilidad, gestión financiera y gestión de nivel de servicio. Los paquetes integrados resultan mucho más eficaces desde el punto de vista financiero que las soluciones multi proveedor, que requieren un considerable trabajo de integración manual. Asimismo, uno de los principales requisitos de las directrices ITIL es la integración de los procesos entre las diferentes categorías. Por tanto, es preciso buscar un solución que integre todas las categorías ITIL desde la perspectiva de los procesos y los datos en lugar de establecer meras correspondencias entre campos. Mantenimiento de una base de datos de gestión de la configuración (CMDB) Otra consideración importante es buscar una solución que proporcione una única “fuente de referencia” para todas las áreas de TI. Esto exige una solución que utilice una base de datos de gestión de la configuración (CMDB) a fin de mantener actualizada la información sobre el entorno de sistemas. La CMDB contiene información detallada sobre todos los elementos de configuración (CI) previstos por el modelo ITIL, lo que incluye la ubicación y configuración de cada elemento, así como sus relaciones físicas y lógicas con otros elementos. La CMDB garantiza que todos los procesos operarán con datos homogéneos y precisos. Dada la complejidad y el dinamismo de la infraestructura tecnológica, es importante encontrar una solución que alimente y actualice automáticamente la base de datos cada vez que se produzca un cambio. Gestión de las TI. Desde la perspectiva del negocio Uno de los tres grandes objetivos de la ISO 20000 es alinear los servicios tecnológicos con las necesidades del negocio. Para lograr este objetivo, el departamento de informática debe gestionar los servicios de TI. Desde una perspectiva empresarial, es decir, adoptar una filosofía de Gestión de Servicios de Negocio (Business Service Management o BSM). Por tanto, es esencial buscar una solución de automatización compatible con la estrategia BSM. Uno de los requisitos fundamentales derivados de BSM es que la solución permita a los miembros del departamento de TI. Comprender las relaciones entre los componentes de la infraestructura tecnológica y los servicios de negocio que sustentan. También debería indicar el impacto que tendrán para el negocio situaciones que pueden producirse en los sistemas de TI. tales como la pérdida de rendimiento o los fallos de componentes. Sólo de esta manera, los técnicos podrán tomar decisiones en función del impacto sobre el negocio y las prioridades de la empresa. El siguiente paso Es importante comprender que la ISO 20000 no es un destino, sino un viaje permanente en busca de una verdadera gestión de servicios de TI. Orientada al negocio. Por tanto, soliciten o no la certificación ISO 20000, las empresas deberían establecer una cultura de mejora continua de esta gestión y buscar la forma de implementar todos los procesos


Pág. 268/321

de ITIL que sean relevantes para su negocio. En esta sección presentamos algunas directrices para facilitar esta búsqueda. Conocer la documentación pertinente Lo primero que los miembros del departamento de Informática deben hacer es comprender la ISO 20000 y, si aún no lo han hecho, familiarizarse con las especificaciones de ITIL y COBIT. Pueden utilizar la documentación citada en este documento como fuente de información. Evaluar la situación actual A continuación, deberán evaluar la situación actual y determinar en qué estado se encuentran sus operaciones con respecto a los requisitos de la ISO 20000. Esto les dará una idea clara del grado de acierto con el que están implementando el modelo ITIL. Las Partes 1 y 2 de la ISO 20000 pueden utilizarse como referencia para conocer los requisitos de la norma. Iniciar un programa de mejora La evaluación inicial de la situación puede utilizarse como mecanismo para verificar el estado de sus procesos, servicios y sistemas e iniciar un programa de mejora. Será preciso determinar qué pasos deben seguirse para cambiar la situación utilizando la información obtenida durante la evaluación para identificar aquellas áreas con mayor potencial de mejora. Las organizaciones que ya estén en fase de implementación del modelo ITIL pueden aprovechar su inversión en este proyecto para acelerar las mejoras. Establecer una cultura de mejora contínua Es importante recordar que el viaje emprendido con la ISO 20000 es un proceso iterativo de mejora continua y no puede llevarse a cabo de un salto. Por tanto, una vez que se han dado los primeros pasos, la organización debe volver a examinar los datos de la evaluación inicial para identificar las siguientes áreas susceptibles de mejora. Deberá proceder con un enfoque iterativo, incrementando el nivel de madurez y midiendo sus progresos a lo largo del camino, siempre con los objetivos de la norma ISO 20000, el modelo ITIL y COBIT como elementos de referencia y control. Conclusión Aunque la publicación de la norma ISO 20000 es muy reciente y la fase de certificación aún no ha comenzado, es importante que las organizaciones empiecen a evaluar el impacto potencial de la norma y decidir si deberían solicitar o no la certificación. En cualquier caso, aquellas que estén implementando o tengan previsto implementar el modelo ITIL para mejorar la calidad de sus servicios de TI. Pueden utilizar la norma como guía y forma de medir sus progresos. Pero lo que es fundamental tener claro sobre la ISO 20000 e ITIL es que ambos estándares necesitan una mejora continua que puede mejorar la credibilidad y competitividad de las empresas.


Pág. 269/321

LLLaaasss 111000 CCCooosssaaasss qqquuueee dddeeebbbeeesss SSSaaabbbeeerrr AAAccceeerrrcccaaa dddeee IIITTTIIILLL... Hasta hace unos años, nadie fuera del Reino Unido había escuchado una palabra de ITIL. Ahora parece que no hay conversación acerca de tecnología y provisión de servicios donde no se mencione este término y no hay licitación de Gobierno donde se requiera la provisión de servicio que no ponga como requisito que el proveedor de la solución deberá acreditar la certificación de varios de sus empleados bajo algunas de las especialidades de ITIL. Pero independientemente de todo el ruido que se ha hecho, muchos profesionales de TIC aún no terminan de entender de qué se trata ITIL. Aquí los principales puntos a destacar alrededor de ITIL.

1 ITIL Significa Information Technology Infrastructure Library (Biblioteca de Infraestructura de Tecnologías de Información)

ITIL contiene un conjunto integrado de mejores prácticas para la administración del ciclo de vida de los

servicios habilitados por las TI. Ofrece una serie de beneficios, incluyendo el incremento de la ventaja competitiva mediante la reducción de costos, crecimiento y agilidad para adaptarse al cambio. Otros beneficios que se logran al implementar una estrategia de ITIL son:

• Eficiencia del negocio mediante la racionalización de los procesos de TI. • Incremento del valor que ofrecen las TI mediante la integración de las operaciones de TI al negocio.

• Mejora continua de la satisfacción de los clientes y los usuarios de las TI.

2 La organización que creó ITIL y actualmente le da soporte está localizada en el Reino Unido.

El Office of Goverment Commerce (‘Oficina de comercio gubernamental, OGC OGC), es una división del Ministerio de Hacienda del Reino Unido. El enfoque general de ITIL ha estado disponible desde finales de los años 80´s y ha sido publicado en Internet durante años. Sin embargo no se conocía en el continente americano hasta que una masa crítica de compañías y publicaciones comenzaron a tomar nota del mismo. Actualmente más de 10,000 organizaciones a nivel mundial han adoptado ITIL.

3 ITIL consiste de una serie de libros que proporcionan guía y recomendaciones.

ITIL ha sido actualizado y reestructurado a fin de reflejar los cambios tecnológicos de la actualidad. Los libros de la versión 3 se enfocan en las siguientes áreas:

� Estrategia del Servicio

� Modela y planifica servicios que tienen utilidad y garantía � Diseño del Servicio

� Alta calidad, efectividad de costos y consistencia de servicios � Transición del Servicio

� Traslada servicios nuevos y servicios modificados a operaciones � Operación del Servicio

� Alcanzar efectividad y eficiencia en la entrega de los servicios � Mejora Continua del Servicio � Creación y mejora continúa del valor mediante modificaciones y adiciones.

4 Para ser exitoso, ITIL requiere de un patrocinador de muy alto nivel al interior de la organización.

Implementar las prácticas de ITIL es un cambio cultural. Las personas de la organización se quejarán y preocuparán de tener que hacer las cosas de manera diferente a como están acostumbrados. Es necesario un patrocinador de muy alto nivel para impulsar el cambio. Si no tenemos un patrocinador no vale la pena intentar implementar ITIL.


Pág. 270/321

5 ITIL no es administración de proyectos.

El enfoque de ITIL no es el de crear productos o servicios de la manera en que lo hacen los proyectos. ITIL se enfoca en la entrega de los servicios habilitados por las TI.

6 Hay poco contenido disponible acerca de ITIL. ITIL es un conjunto de mejores prácticas. Es un modelo para la entrega de servicios habilitados por las TI. Contiene algunos procesos y plantillas, pero no es una metodología y no contiene todos los detalles para su implementación. Las compañías que quieren utilizar ITIL pueden seguir los lineamientos generales y luego desarrollar por si mismas los procesos a detalle a fin de asegurarse que hacen sentido al interior de la organización.

7 ITIL no es una Herramienta.

Es posible implementar todos los aspectos de ITIL utilizando herramientas, pero no se requieren herramientas de manera obligatoria. Si la organización es pequeña, es válido utilizar plantillas sencillas y hojas de cálculo, pero si la organización es grande, será mejor utilizar herramientas de software apropiadas para soportarlo adecuadamente.

8 ITIL no es una propuesta de TODO o NADA.

Debido a que ITIL es un conjunto de enfoques para diferentes áreas, una compañía puede implementar solo partes del modelo o el modelo completo. No hay una regla que indique que se debe implementar siempre TODO.

9 ITIL se puede implementar por fases.

La mayoría de las organizaciones han implementado ITIL en etapas a lo largo de un periodo de entre 3 y 4 años.

10 Es posible certificarse en ITIL.

Hay tres niveles de certificación en ITIL y actualmente solo son aplicables a personas y no a empresas: � Foundation, Este nivel acredita un conocimiento básico de los términos del modelo de ITIL.

� Practitioner, Está destinado a quienes tienen responsabilidad en el diseño de procesos y en la planificación de actividades asociadas a los procesos. Este nivel significa que quien lo tiene entiende el modelo a un grado necesario para aplicar un proceso específico donde sea aplicable.

� Manager, Quien lo posee tiene profundos conocmientos en todas las materias relacionadas con la administración de departamentos de TI y lo habilita para implantar soluciones basadas en ITIL.


Pág. 271/321

AAAppprrreeennndddeee IIITTTIIILLL yyy CCCOOOBBBIIITTT pppaaarrraaa aaadddmmmiiinnniiissstttrrraaarrr lllaaasss TTTIIICCC cccooonnn bbbaaassseee eeennn lllaaasss ppprrriiiooorrriiidddaaadddeeesss

dddeee tttuuu nnneeegggoooccciiiooo

Los procesos de COBIT se enfocan en los requerimientos de la empresa y proporcionan una guía para determinar lo que se necesita para cumplir con esos requerimientos. ITIL define los procesos considerados “mejores prácticas” para la administración de las TIC, se enfoca en el método y define un conjunto de procesos más detallado que COBIT ya que nos indica una ruta para la construcción de procesos. Con la combinación de ITIL y COBIT, las organizaciones de TIC dentro de las empresas pueden lograr cumplir con los objetivos que les plantea la empresa y lo hacen al mismo tiempo que entregan servicios de alta calidad a bajo costo. ITIL es un conjunto de prácticas de administración de los Servicios. Estás practicas para dar soporte a la entrega de los servicios pueden ayudar a una compañía a documentar sus procesos de TIC ITIL es parte de la base del modelo de COBIT, el cual define los objetivos de control de TI los cuales a su vez dan soporte a los procesos de negocio. ITIL proporciona las guías acerca de lo que debe hacerse para lograr la mejor práctica y COBIT tiene más que ver con probar y establecer un conjunto de objetivos para asegurar el control. COBIT es como una herramienta de auditoría y monitoreo para determinar si las cosas se han hecho bien. La documentación de procesos mediante ITIL y los objetivos de control de COBIT son una combinación muy poderosa que puede acelerar el cumplimiento del negocio con Sarbanes Oxley (USA) y BASEL II (Europa). ITIL fortalece los procesos de entrega y soporte; describe como estructurar los procesos operativos pero su debilidad principal son los controles de seguridad. COBIT se enfoca en controles y métricas. También le hace falta la seguridad, pero proporciona una visión más global de los procesos de TI que la que proporciona ITIL. Las organizaciones de TIC en las empresas actualmente tienen mucha presión en cuanto a la aportación que hacen a las metas del negocio. Aprender ITIL y COBIT te permitirá: 1. Administrar las TIC desde una perspectiva de negocio para lograr las metas de la empresa 2. Establecer metas claras para los procesos, basándose en las metas de la empresa. 3. Asegurar un gobierno de TIC efectivo. 4. Establecer controles a nivel de los procesos. 5. Habilitar a los departamentos de TIC a demostrar como cumplen o exceden los requerimientos. ¿Te parece difícil de aplicar? Piensa por un momento en que sucedería si tienes un equipo de colaboradores que aplican los procesos ITIL y gracias a ello son capaces de diferenciar un INCIDENTE (que requiere de atención inmediata y restauración del servicio para que el negocio continúe operando) de un PROBLEMA (que debe ser analizado hasta encontrar la causa raíz y su acción correctiva irreversible).


Pág. 272/321

¿Que tal si este mismo grupo diseña e implementa un mapa tecnológico (CMDB) de todos los componentes involucrados en la prestación del servicio? por lo que es muy fácil detectar que parte del servicio es afectada cuando un componente falla. El resultado de implementar y ejecutar los procesos ITIL siempre será una muy alta calidad en operación y prestación del servicio así como reducción de costos durante todo el ciclo de vida del servicio. Es muy importante revisar a fondo estas estrategias especialmente en estos tiempos de crisis, ¿no crees?


Pág. 273/321

CCCMMMMMMIII... Capability Maturity Model Integration Integración de Modelos de Madurez de Capacidades Capability Maturity Model Integration o (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios. La versión actual de CMMI es la versión 1.2. Hay tres constelaciones de la versión 1.2 disponible:

• CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006.

• En él se tratan procesos de desarrollo de productos y servicios.

• CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de • 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos

del gobierno y la industria.

• CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro de la constelación CMMI-DEV, existen dos modelos: • CMMI-DEV • CMMI-DEV + IPPD (Integrated Product and Process Development) Independientemente de la constelación\modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio. Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada (por ejemplo, usando un método de evaluación como SCAMPI) y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organización, puede coger áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización. Areas de proceso El modelo CMMI v1.2(CMMI-DEV) contiene las siguientes 22 áreas de proceso:

1. Análisis de Causas y Resolución (CAR) 2. Gestión de la configuración (CM) 3. Análisis de Decisiones y Resolución (DAR) 4. Gestión Integrada de Proyectos (IPM) 5. Medición y Análisis (MA) 6. Innovación y Despliegue Organizacionales(OID) 7. Definición de procesos organizacionales (OPD) 8. Enfoque Organizacional en Procesos (OPF) 9. Rendimiento de Procesos Organizacionales (OPP) 10. Formación Organizacional (OT) 11. Monitorización y Control de Proyecto (PMC) 12. Planificación de proyecto (PP) 13. Aseguramiento de calidad de Procesos y Productos (PPQA) 14. Integración de Producto (PI) 15. Gestión Cuantitativa de Proyectos (QPM) 16. Gestión de Requerimientos (REQM) 17. Desarrollo de Requerimientos (RD) 18. Gestión de Riesgos (RSKM)


Pág. 274/321

19. Gestión de Acuerdos con Proveedores (SAM) 20. Solución Técnica (TS) 21. Validación (VAL) 22. Verificación (VER)

Historia CMMI es la evolución de CMM. CMM fue desarrollado desde 1987 hasta 1997. En 2002, se lanzo CMMI Version 1.1, luego en agosto de 2006 siguió la versión 1.2. El objetivo del proyecto CMMI es mejorar la usabilidad de modelos de madurez integrando varios modelos diferentes en un solo marco (framework). Fue creado por miembros de la industria, el gobierno y el SEI. Entre los principales patrocinadores se incluyen la Oficina del Secretario de Defensa (OSD) y la National Defense Industrial Association. Se desarrolla sobre el principio de calidad de Jurán de solvencia contrastada en los 80 en la producción industrial: "la calidad del resultado depende principalmente de la calidad de los procesos empleados en su desarrollo". Dos representaciones: Representación Continua (Continuous Representation) y Escalonada (Staged Representation) El modelo CMMI-DEV establece 5 Niveles de Madurez (Maturity Level)en su representación por etapas o escalonada para clasificar a las organizaciones, en función de qué áreas de procesos consiguen sus objetivos. Es lo que se denomina un modelo escalonado, por etapas, o centrado en la madurez de la organización. La selección de las Áreas de Proceso está prefijado, habiendo 6 o 7 (si aplica SAM) PA para el nivel de madurez 2 (ML2), 11 para el ML3, 2 para el ML4 y 2 más para el ML5, en el Nivel de Madurez 5 (ML5) debes cumplir en todas las áreas de proceso de los otros niveles (al menos hasta nivel de capacidad 3) que son 21 o 22 (si aplica SAM). El modelo para ingeniería de sistemas (SE-CMM) establece 6 Niveles de Capacidad posibles para cada una de las 22 áreas de proceso implicadas en la ingeniería de sistemas. La organización puede decidir cuáles son las Áreas de Proceso (PA) que quiere mejorar determinando así su perfil de capacidad. En el equipo de desarrollo de CMMI había defensores de ambos tipos de representaciones. El resultado fue la publicación del modelo con dos representaciones: continua y escalonada. No son equivalentes, y cada organización puede optar por adoptar la que se adapte a sus características y prioridades de mejora. Si existe una "stagging" equivalente que nos dice que un Nivel de Madurez equivale a tener en un conjunto de PA determinado un determinado Nivel de Capacidad.

� La visión continua de una organización mostrará la representación de nivel de capacidad de cada una de las áreas de proceso del modelo.

� La visión escalonada definirá a la organización dándole en su conjunto un nivel de madurez del 1 al 5. Niveles de capacidad de los procesos (representación continua).

Los 6 niveles definidos en CMMI para medir la capacidad de los procesos son: 0.- Incompleto: El proceso no se realiza, o no se consiguen sus objetivos. 1.- Ejecutado: El proceso se ejecuta y se logra su objetivo. 2.- Gestionado: Además de ejecutarse, el proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos. 3.- Definido: Además de ser un proceso gestionado se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa. 4.- Cuantitativamente gestionado: Además de ser un proceso definido se controla utilizando técnicas cuantitativas. 5.- Optimizado: Además de ser un proceso cuantitativamente gestionado, de forma sistemática se revisa y modifica o cambia para adaptarlo a los objetivos del negocio.


Pág. 275/321

Mejora continua. Componentes

� Área de proceso: Conjunto de prácticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos.

Componentes Requeridos

• Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del área de proceso.

• Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen qué se debe implementar para satisfacer el propósito del área de proceso.

Componentes Esperados • Práctica genérica: Una práctica genérica se aplica a cualquier área de proceso porque puede mejorar el

funcionamiento y el control de cualquier proceso.

• Práctica específica: Una práctica específica es una actividad que se considera importante en la realización del objetivo específico al cual está asociado. Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso.

Componentes Informativos • Propósito • Notas introductorias • Nombres • Tablas de relaciones práctica - objetivo • Prácticas • Productos típicos • Sub-prácticas: Una sub-práctica es una descripción detallada que sirve como guía para la interpretación de una

práctica genérica o específica. • Ampliaciones de disciplina: Las ampliaciones contienen información relevante de una disciplina particular y

relacionada con una práctica específica. • Elaboraciones de prácticas genéricas: Una elaboración de una práctica genérica es una guía de cómo la

práctica genérica debe aplicarse al área de proceso.

Evaluación (Appraisal)

Muchas organizaciones valoran el medir su progreso llevando a cabo una evaluación (appraisal) y ganando una clasificación del nivel de madurez o de un nivel de capacidad de logro. Este tipo de evaluaciones son realizadas normalmente por una o más de las siguientes razones:

• Para determinar que también los procesos de la organización se comparan con las mejores prácticas CMMI y determinar qué mejoras se pueden hacer.

• Para informar a los clientes externos y proveedores acerca de que también los procesos de la organización se comparan con las mejores prácticas CMMI.

• Para cumplir los requisitos contractuales de uno o más clientes. Las valoraciones de las organizaciones utilizando un modelo CMMI deben ajustarse a los requisitos definidos en el documento "Appraisal Requirements for CMMI" (ARC). La evaluación se enfoca en identificar oportunidades de mejora, y comparar los procesos de la organización con las mejores prácticas CMMI. Los equipos de evaluación usan el modelo CMMI y un método conforme a ARC para guiar su evaluación y reporte de conclusiones. Los resultados de la evaluación son usados para planear mejoras en la organización. Hay tres clases de evaluación: Clase A,B,C. El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es un Método de evaluación que cumple todos los requerimientos ARC. Una evaluación de clase A es más formal y es la única que puede resultar en una clasificación de nivel.


Pág. 276/321

El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es el método oficial SEI para proveer puntos de referencia de sistemas de calificación en relación con los modelos CMMI. SCAMPI se usa para identificar fortalezas y debilidades de los procesos, revelar riesgos de desarrollo/adquisición, y determinar niveles de capacidad y madurez. Se utilizan ya sea como parte de un proceso o programa de mejoramiento, o para la calificación de posibles proveedores. El método define el proceso de evaluación constando de preparación; las actividades sobre el terreno; observaciones preliminares, conclusiones y valoraciones; presentación de informes y actividades de seguimiento.


Pág. 277/321

GGGlllooosssaaarrriiiooo dddeee TTTééérrrmmmiiinnnooosss IIITTTIIILLL®®®,,, DDDeeefffiiinnniiiccciiiooonnneeesss yyy AAAcccrrróóónnniiimmmooosss

Término Aceptación [Acceptance] Definición Acuerdo formal que indica que un Servicio de TI, Proceso, Plan, u otro Entregable se han completado, es preciso, Confiable y cumple con los Requisitos especificados. Normalmente la Aceptación es precedida por una Evaluación o Prueba y es requerida antes de proceder con la siguiente fase de un Proyecto o Proceso. Ver Criterio de Aceptación del Servicio. Autorizado oficialmente para un Rol. Por ejemplo, una organización acreditada podría estar autorizada para impartir cursos o para dirigir una Auditoría. Un conjunto de acciones diseñadas para alcanzar un resultado específico. Normalmente, las Actividades se definen como parte de Procesos o Planes, y se documentan en Procedimientos. (Estrategia del Servicio) Cualquier Recurso o Capacidad. Los Activos de un Proveedor de Servicio incluyen todo aquello que se pueda atribuir a la entrega del Servicio. Los Activos pueden ser de los siguientes tipos:

• Administrativos, • Organizativos, • De Proceso, • De Conocimiento, • Personas, • Información, • Aplicaciones, • Infraestructura, • y de Capital. • Cualquier Capacidad o Recurso de un Proveedor de Servicio.

Ver Activos. (Transición del Servicio) El Proceso responsable por ambos, Gestión de la Configuración y Gestión de Activos. creditado [Accredited] Actividad [Activity] Activo [Asset] Activos de Servicio [Service Asset] Activos de Servicio y Gestión de la Configuración [Service Asset and Configuration Management] (SACM) Acuerdo [Agreement] Documento que describe el entendimiento formal entre dos o más partes. Un Acuerdo no tiene fuerza legal, a menos que forme parte de un Contrato. Ver Acuerdo de Nivel de Servicio, Acuerdo de Nivel de Operación. (Diseño del Servicio) (Mejora Continua del Servicio) Acuerdo entre un Proveedor de Servicio de TI y un Cliente. El SLA describe el Servicio de TI, documenta los Objetivos de Nivel de Servicio y especifica las responsabilidades del Proveedor de Servicio de TI y del Cliente. Un único SLA puede curbir varios Servicios de TI o varios Clientes. Ver Acuerdo de Nivel Operacional. Acuerdo de Nivel de Servicio [Service Level Agreement] (SLA)Acuerdo de Nivel Operativo [Operational Level Agreement] (OLA) to Alternativa [Workaround] Término Acuerdo de Nivel Operativo [Operational Level Agreement] (OLA) Definición (Diseño del Servicio) (Mejora Continua del Servicio) Consiste en el Acuerdo entre la Unidad de TI y otra parte de la misma Organización. El OLA contiene la descripción de los Servicios TI que se ofrecen a los Clientes, e incluye la definición de los bienes y Servicios que se proveen, así como los compromisos de ambas partes. Por ejemplo, podrá haber un OLA:

• Entre la Unidad de TI y el departamento de Compras, para la obtención de hardware en plazos previamente comprometidos.

• Entre el Centro de Servicio al Usuarios y un Grupo de Soporte para la realización de la Resolución del Incidente en plazos previamente acordados.. Ver también Acuerdo de Nivel de Servicio (SLA). La Actividad responsable de la Planificación de Cambios para hacer el más eficiente uso de los Recursos.

El Afinado es parte de la Gestión del Rendimiento, que incluye Monitorización del Rendimiento y la implementación de los cambios requeridos. Un término informal usado para describir un Proceso, Elemento de Configuración, Servicio de TI etc. que es capaz de cumplir sus Objetivos o Niveles de Servicio. Ser Ajustado a la Intención requiere un Diseño, implementación, Control y Mantenimiento adecuados. El límite, o grado, al que un Procedimiento de Proceso, Certificación, Contrato, etc. se aplica. Por ejemplo, el Alcance de la Gestión de Cambio puede incluir todos los Servicios


Pág. 278/321

TI Vivos y relatar Elementos de Configuración, el Alcance de un Certificado ISO/IEC 20000 puede incluir todos los Servicios de TI implementados desde un centro de datos en cuestión. (Operación del Servicio) Advertencia de que se ha superado un umbral, de que algo ha cambiado, o de que hubo un Fallo. De forma regular, las Alertas se crean y gestionan con herramientas de Gestión de Sistemas y administradas por el Proceso de Gestión de Eventos. (Diseño del Servicio) Una aproximación o Diseño que minimiza u oculta a los Usuarios de un Servicio de TI los efectos del Fallo de un: Elemento de Configuración. Las soluciones de Alta disponibilidad se diseñan para alcanzar los niveles acordados de disponibilidad y para hacer uso de técnicas como la Tolerancia a Fallos, Resistencia y recuperación rápida para reducir el número de Incidentes y el Impacto de los mismos. (Operación del Servicio) Reducción o eliminación del Impacto de un Incidente o Problema para el que una Resolución completa no está todavía disponible. Por ejemplo, re arrancando un Elemento de Configuración fallado. Las Alternativas para Problemas se documentan en los Registros de Errores Conocidos. Las Alternativas para Incidentes que no tienen asociados Registros de Problemas se documentan en el Registro de Incidencias. Afinado [Tuning] Ajuste a intención [Fit for Purpose] Alcance [Scope] Alerta [Alert] Alta Disponibilidad [High Availability] Alternativa [Workaround] Amenaza [Threat] to Análisis de Impacto de Fallos en Componentes [Component Failure Impact Analysis] (CFIA) Término Amenaza [Threat] Definición Cualquier cosa que pueda aprovechar un Vulnerabilidad. Cualquier causa potencial de un Incidente puede ser considerada una Amenaza. Por ejemplo un fuego es una Amenaza que puede aprovechar la Vulnerabilidad de moquetas inflamables. Este término es comúnmente usado en la Gestión de la Información de Seguridad y la Gestión de Continuidad del Servicio de TI, pero también aplica a otras áreas tales como Gestión de la Disponibilidad y Problemas. Una Actividad que analiza y compara los Costes y los beneficios involucrados en uno o más cursos de acción alternativos. Ver Causa de Negocio (Business Case), Valor Neto Presente, Tasa de Retorno Interna, Retorno sobre la Inversión, Valor sobre la Inversión. (Operación del Servicio) Técnica usada para la ayuda en la identificación de las posibles causas de los Problemas. Todos los datos disponibles sobre el Problema se recopilan y clasifican por fecha y hora para proporcionar una sucesión de hechos detallada. Esto permite identificar que Eventos pueden haber sido desencadenados por otros. (Diseño del Servicio) Una Actividad que identifica las causas subyacentes de una o más interrupciones del Servicio de TI. SFA identifica oportunidades y herramientas de mejora tanto de Procesos del Proveedor de Servicios de TI como de la Infraestructura de TI. SFA es más una Actividad de tipo projecto limitada en tiempo que un proceso continuo de análisis. Ver Análisis de la Causa Raíz. (Mejora Continua del Servicio) Una Actividad que compara dos conjuntos de datos e identifica las diferencias. El Análisis de huecos se usa normalmente para contrastar los Requerimientos con las entregas reales. Ver Comparativa (Diseño del Servicio) Técnica utilizada para ayudar a identificar el impacto que produce un fallo de CI sobre los Servicios de TI. Se elabora a partir de una matriz que contiene los Servicios de TI en un extremo y los CIs en el otro. Estos permite la identificación de los CIs críticos (que podrían causar el fallo de múltiples Servicios de TI) y de los Servicios de TI poco robustos (que tienen múltiples Puntos Singulares de Fallo). Análisis Coste Beneficio [Cost Benefit Analysis] Análisis Cronológico [Chronological Analysis] Análisis de Fallo en el Servicio [Service Failure Analysis] (SFA) Análisis de Huecos [Gap Analysis] Análisis de Impacto de Fallos en Componentes [Component Failure Impact Analysis] (CFIA)


Pág. 279/321

Análisis de Impacto del Negocio [Business Impact Analysis] (BIA) to Analítica de Servicio [Service Analytics] Término Análisis de Impacto del Negocio [Business Impact Analysis] (BIA) Definición (Estrategia del Servicio) BIA es la Actividad de la Gestión de la Continuidad del Negocio que identifica las Funciones Vitales del Negocio y sus dependencias. Estas dependencias pueden incluir Proveedores, personas, otros Procesos de Negocio, Servicios TI, etc. BIA define los requerimientos de recuperación para los Servicios TI. Dichos requerimientos incluyen Objetivos de Tiempos de Recuperación, Objetivos del Punto de Recuperación y los Objetivos de Nivel de Servicio mínimos para cada Servicio TI. (Operación del Servicio) (Mejora Continua del Servicio) Enfoque estructurado a la resolución de Problemas. El Problema es analizado en términos de qué, dónde, cuándo y medida. Se identifican las posibles causas. Se prueba la causa más probable. Se verifica la causa verdadera. (Operación del Servicio) Una Actividad que identifica la Causa Raíz que un Incidente o Problema. El RCA se concentra habitualmente en fallos de la Infraestructura de TI. Ver Análisis de Fallos de Servicio. Análisis de Kepner & Tregoe [Kepner & Tregoe Analysis] Análisis de la Causa Raíz [Root Cause Analysis] (RCA) Análisis de Tendencias [Trend Analysis] (Mejora Continua del Servicio) El análisis de datos para identificar patrones en el tiempo. Análisis de Tendencias es usado en Gestión de Problemas para identificar Fallos comunes o Items de Configuración frágiles, y en Gestión de la Capacidad como una herramienta de modelización para predecir el comportamiento futuro. También es usado como una herramienta de gestión para identificar deficiencias en los Procesos de Gestión del Servicio de TI. (Operación del Servicio) Técnica utilizada para ayudar a identificar el Impacto en el Negocio de uno o más Problemas. La fórmula para el cálculo del Análisis de Valor de Daños se basa en el número de Usuarios afectados, la duración del Tiempo de Parada, el Impacto para cada Usuario, y el coste para el Negocio (si es posible calcularlo). (Mejora Continua del Servicio) Una técnica que revisa y analiza los puntos fuertes y débiles internos de una Organización y alas oportunidades externas y amenazas que afronta. SWOT es el acrónimo de Fuerzas (Strengths), Debilidades ( Weaknesses), Oportunidades (Opportunities) y Amenazas (Threats). (Estrategia del Servicio) Técnica utilizada en el Gravamen del Impacto de Negocio de los Incidentes. La Analítica de Servicio Modela las dependencias entre Elementos de Configuración, y las dependencias de los Servicios de TI en los Elementos de Configuración. Análisis de Valor de Daños [Pain Value Analysis] Análisis SWOT [SWOT Analysis] Analítica de Servicio [Service Analytics] Anatomía del Rendimiento [Performance Anatomy] to Atributo [Attribute] Término Anatomía del Rendimiento [Performance Anatomy] Aplicación [Application] Definición (Estrategia del Servicio) Aproximación a la Cultura Organizativa que integra y gestiona activamente tanto la estrategia y el liderazgo, como el desarrollo del personal, la capacitación tecnológica, la gestión del rendimiento o la innovación. Programa que provee Funciones requeridas por un Servicio TI. Cada Aplicación podría ser parte de más de un Servicio TI. Una Aplicación se puede ejecutar en uno o más Servidores o Clientes. Ver Gestión de Aplicaciones, Portafolio de Aplicaciones. Sinónimo de Outsourcing Aprovisionamiento Externo [External Sourcing] Aprovisionamiento Interno [Internal Sourcing] (Estrategia del Servicio) Uso de un Proveedor Interno de Servicio para gestionar los Servios de TI. Ver Aprovisionamiento de Servicio, Proveedor de Servicio de tipo I, Proveedor de Servicio de tipo II. (Estrategia del Servicio) Provisión de Servicios desde un país cercano al país donde tiene sede el Cliente. Puede tratarse de la provisión de un Servicio de TI, o de Funciones de soporte como por ejemplo el Centro de Servicio al Usuario. Ver Aprovisionamiento Cercano, Aprovisionamiento Lejano. (Diseño del Servicio) (Mejora Continua del Servicio) Una técnica que puede usarse para determinar la cadena de Eventos que lleva a un Problema. El Árbol de Análisis de Fallos representa la cadena de Eventos empleando notación Booleana en un diagrama. (Diseño del Servicio) La estructura de un Sistema o un Servicio TI, incluyendo las Relaciones de sus Componentes y del ambiente en el que se encuentran. La Arquitectura también incluye los Estándares y las Guías que dirigen el diseño y evolución del Sistema. (Diseño del Servicio) Es una Opción de Recuperación. Un acuerdo entre dos organizaciones para compartir recursos en caso de emergencia. Por ejemplo, espacio de la Sala de ordenadores o uso de un mainframe (Transición del Servicio) Es el Proceso responsable de garantizar que la Calidad de un producto, Servicio o Proceso estará al nivel de su Valor previsto. (Transición del Servicio) Una parte de información de un Elemento de Configuración. Ejemplos: nombre, ubicación, Versión, número y Costo. Los Atributos de un CIs se registran en la Base de Datos de la Configuración (CMDB). Ver Relaciones.


Pág. 280/321

Aprovisionamiento Local [Near-Shore] Árbol de Análisis de Fallos [Fault Tree Analysis] (FTA) Arquitectura [Architecture] Arreglo Recíproco [Reciprocal Arrangement] Aseguramiento de la Calidad [Quality Assurance] (QA) Atributo [Attribute] Auditoría [Audit] to Bucle de Control de la Monitorización [Monitor Control Loop] Término Auditoría [Audit] Definición Inspección formal para verificar si un Estándar o un conjunto de Guías se está siguiendo, que sus Registros son precisos, o que las metas de Eficiencia y Efectividad se están cumpliendo. Una Auditoría la puede realizar tanto un grupo interno como uno externo Ver Certificación, Evaluación. Sinónimo de Refuerzo (Transición del Servicio) Base de datos lógica que contiene los datos empleados por el Sistema de Gestión del Conocimiento del Servicio. (Operación del Servicio) Base de datos que contiene todos los Registros de Errores Conocidos. Esta base de datos es creada por la Gestión del Problema y utilizada por Gestión del Incidente y Gestión del Problema. La Base de Datos de Errores Conocidos es parte del Sistema de Gestión del Conocimiento del Servicio. (Transición del Servicio) Base de Datos usada para almacenar Registros de Configuración durante todo su Ciclo de Vida. El Sistema de Gestión de la Configuración mantiene una o más CMDBs, y cada CMDB contiene Atributos de CIs, y Relaciones con otros CIs. Back-out [Back-out] Base de Conocimiento [Knowledge Base] Base de Datos de Errores Conocidos [Known Error Database](KEDB) Base de Datos de Gestión de la Configuración [Configuration Management Database] (CMDB) Base de datos de proveedores y contratos [Supplier and Contract Database] (SCD) Biblioteca Definitiva de Medios [Definitive Media Library] (DML) (Diseño del Servicio) Base de datos o Documento estructurado usado para gestionar los Contratos con los Proveedores durante su ciclo de vida. La SCD contiene los Atributos clave de todos los Contratos y Proveedores, y debe formar parte del Sistema de Gestión del Servicio de Conocimiento. (Transición del Servicio) Uno o más lugares donde se almacenan con seguridad las versiones definitivas aprobadas de Elementos de Configuración de Software. La DML también puede contener CIs asociado tales como licencias y documentación. La DML es un área de almacenamiento lógico única cuando haya múltiples localizaciones. Todo el software en la DML está bajo el control de Cambios y Gestión de la Entrega y es registrada en el Sistema de Gestión de Configuración. Solamente el software que está en la DML es aceptable para utilizar en una nueva Entrega. Organización de Estándares Nacionales del Reino Unido. Es responsable de crear y mantener los Estándares británicos. Vaya a http://www.bsi-global.com para mayor información. Ver ISO. (Operación del Servicio) Monitorización de la salida de una Tarea, Proceso, Servicio de TI o Elemento de Configuración; comparando dicha salida con un patrón predefinido; y tomando las acciones apropiadas en base a esta comparación. British Standards Institution [British Standards Institution] (BSI) Bucle de Control de la Monitorización [Monitor Control Loop] Buena Práctica [Best Practice] to Cambio Estándar [Standard Change] Término Buena Práctica [Best Practice] Cadena de Aprovisionamiento [Supply Chain] Definición Actividades o Procesos que se han usado con éxito por más de una Organización. ITIL es un ejemplo de Buenas Prácticas. (Estrategia del Servicio) Actividades en la Cadena de Valor acometidas por Proveedores. Una Cadena de Aprovisionamiento típicamente implica a múltiples Proveedores, cada uno de ellos aporta valor al producto o Servicio. (Estrategia del Servicio) Una secuencia de Procesos que crea un producto o Servicio que proporciona valor a un Cliente. Cada paso de la secuencia se apoya en los pasos anteriores y contribuye al conjunto del producto o Servicio. Ver Red de Valor. (Transición del Servicio) Documento que enumera todos los Cambios aprobados y su fecha prevista de implementación. Un Calendario de Cambios también se conoce también como Lista de Cambios Planificados, incluso puede contener información sobre Cambios que ya han sido implementados. Característica de un producto, Servicio o Proceso para proporcionar su propio valor. Por ejemplo, un Componente hardware puede ser considerado de alta Calidad si rinde según lo esperado y proporciona la Fiabilidad requerida. La Calidad de un Proceso requiere la capacidad para medir su Eficacia y Eficiencia, o incluso para mejorarlas si resultase necesario. Ver también Sistema de Gestión de Calidad. (Transición del Servicio) Adición, modificación o eliminación de algo que podría afectar a los Servicios de TI. El Alcance debería incluir todos los Servicios de TI, Elementos de Configuración, Procesos, Documentación etc. (Transición del Servicio) Un Cambio que debe ser introducido lo más rápido posible. Por ejemplo para resolver un Incidente Mayor o implementar un parche de Seguridad. La Gestión de Cambios normalmente tiene un Procedimiento específico para manejar Cambios de Emergencia. Ver Comité de


Pág. 281/321

Emergencia (ECAB). (Transición del Servicio) Un cambio pre-aprobado que es de bajo Riesgo, relativamente común y sigue un Procedimiento o Instrucción de Trabajo. Por ejemplo reset de claves de acceso o provisión de equipamiento estándar para un nuevo empleado. No se necesitan RFCs para implementar Cambios Estándar y son registrados y seguidos empleando otros mecanismos como Peticiones de Servicio. Ver Modelo de Cambio. Cadena de Valor [Value Chain] Calendario de Cambios [Change Schedule] Calidad [Quality] Cambio [Change] Cambio de Emergencia [Emergency Change] Cambio Estándar [Standard Change] Canal de Entrada de Servicios [Service Pipeline] to Cartera de Clientes [Customer Portfolio] Término Canal de Entrada de Servicios [Service Pipeline] Definición (Estrategia del Servicio) Una base de datos o Documento estructurado enumerando todos los Servicios de TI que se están evaluando o en Desarrollo, pero que todavía no están disponibles para los Clientes. El Canal de Entrada de Servicios proporciona una perspectiva de Negocio de los posibles futuros Servicios de TI y es parte de la Cartera de Servicios, que normalmente no se publica a los Clientes. (Diseño del Servicio) Rendimiento máximo que se puede obtener de un Elemento de Configuración o Servicio de TI en el cumplimiento de los Objetivos de Nivel de Servicio acordados. Para algunos tipos de CI, la Capacidad puede ser el tamaño o el volumen, por ejemplo en una unidad de disco. (Estrategia del Servicio) Identificación de un Coste como de capital, aún no habiendo adquirido ningún Activo. Esto se hace con el objeto de dispersar el impacto de un Coste a través de múltiples periodos contables. El ejemplo más común de ello es el desarrollo de software, o la compra de una licencia de software. Los Recursos requeridos para entregar una parte identificable de un Servicio de TI. Las Cargas de Trabajo pueden Categorizarse por Usuarios, grupos de Usuarios, o Funciones dentro de un Servicio de TI. Es usado para ayudar en el análisis y gestión de Capacidad, Rendimiento y Uso de Elementos de Configuración y Servicios de TI. El término Carga de Trabajo se usa a veces como sinónimo de Flujo. Técnica usada para ayudar a la Gestión de Demanda, cargando montos diferentes por la misma Función de Servicio TI en momentos diferentes. (Diseño del Servicio) Base de Datos o Documento estructurado que se usa para gestionar las Aplicaciones en su Ciclo de Vida. El Portafolio de Aplicaciones contiene Atributos que son claves para todas las Aplicaciones. Algunas veces se implementa el Portafolio de Aplicaciones como parte del Portafolio de Servicio, o como parte del Sistema de Gestión de la Configuración. (Estrategia del Servicio) Una base de datos o Documento estructurado usado para registrar todos los Clientes –Customers de un Proveedor de Servicio TI. La Cartera de Clientes es la visión del Gestor de Relaciones de Negocio sobre los Clientes que reciben Servicios de un Proveedor de Servicios TI. Ver Cartera de contratos, Cartera de Servicios. Capacidad [Capacity] Capitalización [Capitalization] Carga de Trabajo [Workload] Cargo diferencial [Differential Charging] Cartera de Aplicaciones [Application Portfolio] Cartera de Clientes [Customer Portfolio] Cartera de Contratos [Contract Portfolio] to Centro de Atención al Usuario [Help Desk] Término Cartera de Contratos [Contract Portfolio] Definición (Estrategia del Servicio) Una base de datos o Documento estructurado de gestión de Contractos o Acuerdos de Servicios entre un Proveedor de Servicios TI y sus Clientes. Cada Servicio TI provisto a un Cliente debería tener un Contrato u otro Acuerdo, el cual esté incluido en la Cartera de Contratos. Ver Cartera de Servicios, Catálogo de Servicios. (Estrategia del Servicio) Conjunto de todos los Servicios que son gestionados por un


Pág. 282/321

Proveedor de Servicios. La Cartera de Servicios se emplea para gestionar el Ciclo de Vida completo de todos los Servicios, e incluye tres Categorías: Canal de Entrada de Servicios (propuestos o en Desarrollo); Catálogo de Servicios (Reales o disponibles para su Despliegue); y Servicios Retirados. Ver Gestión de la Cartera de Servicios, Cartera de Contratos. (Estrategia del Servicio) Justificación para el gasto de un elemento relevante. Incluye información de Costos, beneficios, opciones, situaciones, Riesgos, y posibles problemas. Ver Análisis de Beneficio de Costo. (Diseño del Servicio) Una técnica usada para definir la funcionalidad requerida, Objetivos y para el Diseño de Pruebas. Los Casos de Uso definen escenarios realistas que describen las interacciones entre Usuarios y un Servicio de TI u otro Sistema. Ver Caso de Cambio. (Diseño del Servicio) Una base de datos o un Documento estructurado con información sobre todos los Servicios Live IT, incluyendo aquellos disponibles para la Implementación. El Catálogo de Servicios es la única parte publicada de la Carpeta de Servicios publicada a Clientes, y se utiliza para soportar la venta y entrega de los Servicios de TI. El Catálogo de servicios incluye puntos de contacto, solicitud y Procesos de petición. Ver Carpeta de Contrato. Grupo nominal de cosas que tienen algo en común. Las Categorías se usan para agrupar distintos contenidos. Por ejemplo los Tipos de Coste se usan para agrupar clases similares de Costes. Las Categorías de Incidente son usadas para agrupar tipos similares de Incidentes, Los Tipos de CIs, se usan para agrupar distintas clases de Elementos de Configuración. (Operación del Servicio) La causa original o subyacente de un Incidente o Problema. (Operación del Servicio) Un punto de contacto para Usuarios para registrar Incidentes. Un Centro de Atención al Usuario está normalmente más técnicamente focalizado que un Centro de Servicio al Usuario y no proporciona un Punto Único de Contacto. El término Centro de Atención al Usuario es a menudo usado como sinónimo del Centro de Servicio al Usuario. Cartera de Servicios [Service Portfolio] Caso de Negocio [Business Case] Caso de Uso [Use Case] Catálogo de Servicios [Service Catalogue] Categoría [Category] Causa Raíz [Root Cause] Centro de Atención al Usuario [Help Desk] Centro de Beneficio [Profit Centre] to Ciclo de Vida de Gestión del Servicio [Service Management Lifecycle] Término Centro de Beneficio [Profit Centre] Definición (Estrategia del Servicio) Unidad de Negocio que cobra por los Servicios prestados. Un Centro de beneficio puede ser creado con el objetivo de obtener una rentabilidad económica, recuperación de Costes, o de funcionar con pérdidas. Los Proveedores de Servicio de TI pueden funcionar como Centros de Coste o de Beneficios. (Estrategia del Servicio) Una Unidad de Negocio o Proyecto al cual los Costes son asignados. Un Centro de Costes no es un cargo para un Servicio provisto. Un Proveedor de Servicios TI puede ser considerado como un Centro de Coste o un Centro de Beneficio. (Operación del Servicio) Organización o Unidad de Negocio que maneja gran cantidad de llamadlas telefónicas entrantes y salientes. Ver Centro de Servicio al Usuario. (Operación del Servicio) Punto Único de Contacto entre el Proveedor de Servicio y los Usuarios. Un Centro de Servicio al Usuario típico gestiona Incidentes, Peticiones de Servicio, y también maneja la comunicación con los Usuarios. (Operación del Servicio) Estado final en el Ciclo de Vida de un Incidente, Problema, Cambio etc. Cuando el Estado es Cerrado, no se requiere ninguna acción adicional. Emisión de un certificado que acredita la Conformidad con un Estándar. La Certificación incluye una Auditoría formal realizada por un organismo independiente y Acreditado. El término Certificación también se usa para denotar la concesión de un certificado que acredita que una persona ha logrado una cualificación determinada. Las diversas fases en la vida de un Servicio de TI, Elemento de Configuración, Incidente, Problema, Cambio etc. El Ciclo de Vida define las Categorías de cada Estado y las transiciones de Estado permitidas. Por ejemplo:

• El Ciclo de Vida de una Aplicación incluye Requisitos, Diseñar, Construir, Desplegar, Operar, Optimizar. • El Ciclo de Vida Expandido del Incidente incluye Detectar, Responder, Diagnosticar, Reparar, Recuperar,

Restaurar. • El Ciclo de Vida de un Servidor puede incluir: Pedido, Recibido, En Prueba, Real, Eliminado etc. Aproximación

a la Gestión del Servicio de TI que pone énfasis la importancia de la coordinación y el Control a través de las diferentes Funciones, Procesos y Sistemas necesarios para gestionar el Ciclo de Vida total de los Servicios de TI. La aproximación del Ciclo de Vida de la Gestión del Servicio incluye la Estrategia, Diseño, Transición, Operación y Mejora Continua de los Servicios de TI.


Pág. 283/321

Centro de Costes [Cost Centre] Centro de Llamadas [Call Centre] Centro de Servicio al Usuario [Service Desk] Cerrado [Closed] Certificación [Certification] Ciclo de Vida [Lifecycle] Ciclo de Vida de Gestión del Servicio [Service Management Lifecycle] Ciclo de Vida Expandido del Incidente [Expanded Incident Lifecycle] to COBIT [COBIT] Término Ciclo de Vida Expandido del Incidente [Expanded Incident Lifecycle] Definición (Gestión de Disponibilidad) Fases detalladas en el Ciclo de Vida de un Incidente. Las fases son Detección, Diagnóstico, Reparación, Recuperación y Restauración. El Ciclo de Vida Expandido del Incidente se usa para ayudar a la comprensión de las diferentes contribuciones al Impacto de Incidentes y para Planear como controlarlas y reducirlas. Sinónimo de PDCA (Plan Do Check Act). Ciclo Deming [Deming Cycle] Cierre [Closure] (Operación del Servicio) Acción de cambiar el Estado de un Incidente, Problema, Cambio etc. a Cerrado. Acción de asignar una Categoría a algo. La Clasificación se usa con el objeto de asegurar la calidad de la información y una gestión consistente. Típicamente se Clasifican CIs, Incidentes, Problemas, Cambios etc. Clasificación [Classification] Cliente [Client] Término genérico que describe al Negocio o Cliente de Negocio. Por ejemplo Gestor de Clientes podría ser usado como sinónimo de Gerente de Cuenta. El término cliente también se usa para definir: Un ordenador usado directamente por un Usuario, como por ejemplo un PC, un portátil, o una Estación de Trabajo Parte de una Aplicación Cliente-Servidor que interactúa directamente con el Usuario. Por ejemplo un cliente de correo electrónico. Cliente [Customer] Alguien que compra bienes o Servicios. El Cliente de un Proveedor de Servicios TI es la persona o grupo que define y acuerda el Objetivo de Nivel de Servicio. El término Cliente –customer- es también informalmente usado para Usuario, por ejemplo: "Esta es una Organización focalizada en el Usuario". (Estrategia del Servicio) El receptor de un producto o Servicio del Negocio. Por ejemplo, si el Negocio es un fabricante de coches, entonces el Cliente del Negocio es quien compra un coche. Un Cliente que trabaja para un Negocio diferente al del Proveedor del Servicio de TI. Ver Proveedor Externo de Servicio, Cliente Interno. Cliente que trabaja para el mismo Negocio que el Proveedor del Servicio de TI. Ver Proveedor Interno de Servicio, Cliente Externo. (Mejora Continua del Servicio) Control Objectives for Information and related Technology (COBIT) proporciona las directrices y Mejores Prácticas para la gestión de los Procesos de TI. La publicación de COBIT la lleva a cabo el IT Governance Institute. Consultar http://www.isaca.org/ para más información. Cliente del Negocio [Business Customer] Cliente Externo [External Customer] Cliente interno [Internal Customer] COBIT [COBIT] Cobro por Noción [Notional Charging] to Confiabilidad [Reliability] Término Cobro por Noción [Notional Charging] Definición (Estrategia del Servicio) Enfoque de la Imputación de Costes para Servicios de TI. Se calculan los Cobros a los Clientes y se informa a los Clientes sobre dichos cobros, pero no se realiza ninguna transferencia de dinero. El Cobro


Pág. 284/321

por Noción se presenta a veces para asegurarse de que los Clientes son conscientes de los Costes en los que incurren, o como una fase durante la presentación de la Imputación de Costes verdadera. Directriz publicada por un organismo público o una Organización de Normalización, tales como ISO o BSI. Muchos Estándares consisten en un Código de Práctica y una Especificación. El Código de Práctica describe las Mejores Prácticas recomendadas. (Transición del Servicio) Personal que asesora al Gerente de Cambios en la Valoración, priorización y planificación de los Cambios. Este comité está formado por representantes de todas las áreas del Proveedor de Servicios de TI, del Negocio, y Proveedores Externos. (Diseño del Servicio) Aplicación software o Middleware que puede ser adquirida por un Proveedor Externo. Código de Práctica [Code of Practice] Comité de Cambios [Change Advisory Board] (CAB) Commercial off the Shelf [Commercial off the Shelf] (COTS) Comparativa [Benchmarking] (Mejora Continua del Servicio) Comparar una Referencia con una Línea Base o con una Buena Práctica. El término Comparativa también se usa para referirse a la creación de una serie de Referencias en el tiempo, y comparar los resultados para medir el progreso o la mejora. Término genérico usado para definir una parte de algo más complejo. Por ejemplo, un Sistema de computación puede ser un Componente de un Servicio de TI, una Aplicación puede ser un Componente de una Unidad de Entrega. Los Componentes que necesitan ser gestionados son los Elementos de Configuración. (Transición del Servicio) Elemento de Configuración que forma parte de una Agrupación. Por ejemplo, un CI de tipo memoria o CPU puede formar parte de un CI tipo servidor. Medida del número de Usuarios dedicados a la misma Operación al mismo tiempo. (Diseño del Servicio) (Mejora del Servicio Continua) Medida de cuánto tiempo un Elemento de Configuración o Servicio de TI puede ejecutar su Función acordada ininterrumpidamente. Generalmente medido como MTBF o MTBSI. El término Confiabilidad también puede ser utilizado para definir la probabilidad de que un Proceso, Función, etc. responda de la forma esperada. Ver Disponibilidad. Componente [Component] Componente CI [Component CI] Concurrencia [Concurrency] Confiabilidad [Reliability] Confidencialidad [Confidentiality] to Contramedida [Countermeasure] Término Confidencialidad [Confidentiality] Definición (Diseño del Servicio) Principio de seguridad que requiere que los datos deberían únicamente ser accedidos por el personal autorizado a tal efecto. (Transición del Servicio) Término genérico usado para describir un grupo de Elementos de Configuración que actúan o funcionan juntos para proveer un Servicio de TI, o un subconjunto representativo de un Servicio de TI. El término Configuración también se usa para describir los parámetros y ajustes realizados en uno o más CIs. Aseguramiento de que se sigue un Estándar o conjunto de Directrices, o de que se emplean unas prácticas de seguimiento adecuadas y consistentes. (Transición del Servicio) Un subconjunto del Consejo Asesor de Cambios que toman decisiones sobre el impacto de Cambios de Emergencia. Miembros del ECAB pueden estar decidiendo en el momento en que son llamados a reunirse, dependiendo de la naturaleza del Cambio de Emergencia. Configuración [Configuration] Conformidad [Compliance] Consejo Asesor de Cambios de Emergencia [Emergency Change Advisory Board ] (ECAB) Consejo de Dirección de TI [IT Steering Group](ISG) Grupo formal responsable de asegurarse de que el Negocio y las Estrategias y Planes del Proveedor de Servicios de TI están estrechamente alineados. Un Consejo de Dirección de TI incluye representantes senior tanto del Negocio como del Proveedor de Servicios de TI. (Estrategia del Servicio) El Proceso responsable de identificar los Costos de la entrega de Servicios TI, comparándolos con los costos presupuestados, y registrando las diferencias con el Presupuesto. (Transición del Servicio) Actividad responsable de registrar y reportar el Ciclo de Vida de cada Elemento de Configuración. Contabilización [Accounting] Contabilización de Estado [Status Accounting] Contramedida [Countermeasure]


Pág. 285/321

Puede ser usado para referirse a algún tipo de Control. El término Contramedida es muy usado cuando se refiere a medidas que incrementan la Resistencia, Tolerancia a fallos o Confiabilidad de un Servicio TI. Contratación del Servicio [Service Sourcing] to Control de Operaciones [Operations Control] Término Contratación del Servicio [Service Sourcing] Definición (Estrategia del Servicio) La Estrategia y enfoque para decidir si un Servicio se provee internamente o si se Externaliza a un Proveedor de Servicio Externo. Contratación del Servicio significa también la ejecución de esta Estrategia. La Contratación del Servicio incluye:

• Contratación Interna – Servicios Internos o Compartidos empleando Proveedores de Servicio de Tipo I o de Tipo II.

• Contratación Tradicional – Externalización completa del Servicio empleando un Proveedor de Servicio de Tipo III.

• Contratación Multiproveedor – Externalización Preferencial, en Consorcio o Selectiva, empleando Proveedores de Servicio de Tipo III.

Un Acuerdo legalmente obligatorio entre dos o más partes. (Estrategia del Servicio) Un Contrato para la entrega de uno o más Servicios de TI. El término Contrato de Servicio también se emplea para significar un Acuerdo para entregar Servicios de TI, tanto si es un Contrato legal como un SLA. Ver Cartera de Contratos (Diseño del Servicio) Un Contrato entre un Proveedor de Servicio de TI y un Tercero. El Tercero proporciona bienes o Servicios que soportan la entrega de un Servicio de TI a Clientes. El Contrato de Soporte define objetivos y responsabilidades que son requerirlas para alcanzar los Objetivos de Nivel de Servicio en un SLA. Un medio de gestión de Riesgo, asegurando que el Objetivo de Negocio es alcanzado, o asegurando que un Proceso es seguido. Ejemplos de Controles incluyen Políticas, Procedimientos, Roles, RAID, door-locks etc. Un control es llamado, algunas veces, Contramedida o medida de seguridad. Control también es un medio de gestionar el uso o comportamiento de un Elemento de Configuración, Sistema o Servicio TI. (Transición del Servicio) Actividad responsable de asegurar que la adición, modificación o eliminación de un CI se gestiona adecuadamente, por ejemplo enviando una Petición de Cambio o una Petición de Servicio. Ver COBIT. Contrato [Contract] Contrato de Servicio [Service Contract] Contrato de Soporte [Underpinning Contract] (UC) Control [Control] Control de Configuración [Configuration Control] Control de Objetivos para Información y Tecnología relacionada [Control Objectives for Information and related Technology] (COBIT) Control de Operaciones [Operations Control] Sinónimo de Control de Operaciones de TI. Control de Operaciones de TI [IT Operations Control] to Coste Marginal [Marginal Cost] Término Control de Operaciones de TI [IT Operations Control] Control del Proceso [Process Control] Definición (Operación del Servicio) Función responsable de Monitorizar y Controlar los Servicios de TI y la Infraestructura de TI. Ver Puente de Operaciones. Es la Actividad de planificación y regulación de un Proceso, con el Objetivo de garantizar un desarrollo Eficiente, Eficaz y coherente del Proceso. (Diseño del Servicio) (Operación del Servicio) Copiar los datos para proteger los originales de pérdidas de Integridad o Disponibilidad. Cambios realizados al Plan o Actividad que ya se han iniciado, para asegurarse que el mismo alcance sus Objetivos. Correcciones de dirección son realizadas como resultado de un progreso en la Monitorización. El monto de dinero gastado en una Actividad específica, Servicio TI, o Unidad de Negocio. Los Costes consisten de un coste real (dinero), coste conceptual, tal como el tiempo de la gente y Amortización. (Estrategia del Servicio) El Coste de proveer un Servicio de TI que no se puede asignarse completamente a un Cliente específico. Por ejemplo, el Coste de proveer Servidores compartidos o licencias de software. También conocido como Sobrecoste. Ver Coste Directo. (Estrategia del Servicio) Se trata de un Coste utilizado a la hora de decidir entre alternativas de inversión. Se calcula como el ingreso que se pudiera haber generado en el caso de que los Recursos disponibles se hubieran utilizado en una forma diferente. Por ejemplo, el Coste de Oportunidad en la compra de un nuevo servidor puede considerarse calculando que la inversión pudiera haberse dedicado a una Mejora del Servicio. El análisis de Coste de Oportunidad se utiliza como parte del proceso de toma de decisiones, pero no se emplea como parte del análisis financiero. (Estrategia del Servicio) Coste de proveer un Servicio TI el cual puede ser asignado completo a un específico Cliente, Centro de Costes, Proyecto, etc. Por ejemplo, costes de proveer Servidores no compartidos o licencias de software. Ver Costes Indirectos. (Estrategia del Servicio) Un Coste que no varía con el uso del Servicio de TI. Por


Pág. 286/321

ejemplo el coste de un Servidor. Ver Coste Variable. (Estrategia del Servicio) Coste de continuar proporcionando el Servicio de TI. El Coste Marginal no incluye las inversiones ya realizadas, por ejemplo el coste de desarrollar nuevo software y dar formación. Copia de Seguridad [Backup] Correcciones de dirección [Course Corrections] Coste [Cost] Coste de Incidencias [Indirect Cost] Coste de Oportunidad [Opportunity Cost] Coste Directo [Direct Cost] Coste Fijo [Fixed Cost] Coste Marginal [Marginal Cost] Coste Operacional [Operational Cost] (OPEX) to Criterio de Aceptación de Servicio [Service Acceptance Criteria] (SAC) Término Coste Operacional [Operational Cost] (OPEX) Definición Es el Coste de la ejecución de los Servicios de TI. Frecuentemente se trata de pagos. Por ejemplo, los costes de personal, el mantenimiento de hardware o el consumo eléctrico. Ver también Costes de Adquisición (Capex) (Estrategia del Servicio) Una metodología empleada para ayudar a las decisiones de inversión. TCO establece el Coste total de propiedad de un Elemento de Configuración a lo largo de su Ciclo de Vida, no sólo el Coste inicial o precio de compra. Ver Coste Total de Utilización. (Estrategia del Servicio) Una metodología empleada para ayudar a las decisiones de Inversión y Provisión de Servicio. TCU establece el Coste total para el Cliente del uso de un Servicio de TI a lo largo de todo su Ciclo de Vida. (Estrategia del Servicio) El Coste para el Proveedor del Servicio de TI de proporcionar un único Componente de un Servicio de TI. Por ejemplo el Coste de un PC, o una única Transacción. (Estrategia del Servicio) Un Coste que depende en el uso del Servicio de TI, cuantos productos se producen, el número y tipo de Usuarios, o algún otro parámetro que no puede fijarse por anticipado. Ver Dinámica de Coste Variable. Sinónimo de Costes de Operación. Coste Total de Propiedad [Total Cost of Ownership] (TCO) Coste Total de Uso [Total Cost of Utilization] (TCU) Coste Unitario [Unit Cost] Coste Variable [Variable Cost] Costes de Ejecución [Running Costs] CRAMM Metodología y herramienta para analizar y gestionar Riesgos. CRAMM fue desarrollado por el Gobierno Británico, pero es ahora propiedad privada. Información adicional disponible en http://www.cramm.com/ (Transición del Servicio) Actividad en la que se ensambla un número de Elementos de Configuración para crear una parte de un Servicio TI. El término también hace referencia a un Entregable que está autorizado para su Entrega. Por ejemplo, Creación de un Servidor. Ver Línea Base de la Configuración. (Transición del Servicio) Conjunto de criterios utilizados para asegurar que un Servicio de TI cumple con su funcionalidad y Requisitos de Calidad, y que el Proveedor de Servicio de TI está preparado para Operar el nuevo Servicio de TI una vez ha sido Implementado. Ver Aceptación. Creación [Build] Criterio de Aceptación de Servicio [Service Acceptance Criteria] (SAC) Cuadro Integral de Mando [Balanced Scorecard] to Dependencia [Dependency] Término Cuadro Integral de Mando [Balanced Scorecard] Definición (Mejora Continua del Servicio) Herramienta de gestión desarrollada por los Doctores Robert Kaplan (Harvard Business School) y David Norton. Un Cuadro Integral de Mando permite dividir la Estrategia en


Pág. 287/321

Indicadores Clave de Rendimiento (KPI). El Rendimiento frente a los KPIs se usa para demostrar lo bien que se ha alcanzado la Estrategia. El Cuadro Integral de Mando tiene 4 áreas, cada una tiene un número pequeño de KPIs. Las mismas 4 áreas se consideran en diferentes niveles de detalle en la Organización. (Transición del Servicio) Actividad que garantiza que la Infraestructura TI es la apropiada y se encuentra configurada correctamente, para albergar una Aplicación o Servicio de TI. Ver también Validación. Un conjunto de valores que es compartido por un grupo de personas, incluyendo expectativas acerca de cómo la gente debería comportarse, sus creencias, ideas y prácticas. Ver Visión. Cultura orientada al Cliente. Los Objetivos principales de una Cultura de Servicio es la satisfacción del Cliente y la ayuda al Cliente a conseguir sus Objetivos de Negocio. Realizar Actividades para cumplir una necesidad o Requerimiento. Por ejemplo proporcionar un nuevo Servicio de TI, o cumplir una Solicitud de Servicio. (Operación del Servicio) El Proceso responsable de administrar el Ciclo de Vida de todas las Peticiones de Servicio. Cualificación [Qualification] Cultura [Culture] Cultura de Servicio [Service Culture] Cumplimiento [Fulfilment] Cumplimiento de Petición [Request Fulfilment] Datos-Información-Conocimiento-Sabiduría [Data-toInformation-toKnowledge-toWisdom](DIKW) Declaración de Misión [Mission Statement] Una forma de entender las relaciones entre, datos, información, conocimiento y sabiduría. DIKW muestra cómo cada uno de éstos se construye sobre el otro. La Declaración de Misión de una Organización es una descripción breve pero completa del propósito global y las intenciones de dicha Organización. Establece lo que ha de conseguirse, pero no cómo debería hacerse. (Diseño del Servicio) Documento que contiene todos los Requerimientos para la compra de un producto o para un Servicio de TI nuevo o cambiado. Declaración de requerimientos [Statement of requirements] (SOR) Dependencia [Dependency] La resistencia directa o indirecta de un Proceso o Actividad sobre otro. Depreciación (Amortización) [Depreciation] to Diagrama de Ishikawa [Ishikawa Diagram] Término Depreciación (Amortización) [Depreciation] Derechos [Rights] Definición (Estrategia de Servicio) Medida de la reducción de valor de un Activo sobre su vida útil. Está basado en el uso, consumo u otra reducción en el valor económico de utilización. (Operación del Servicio) Los permisos concedidos a un Usuario o Rol. Por ejemplo, el Derecho a modificar una información en concreto, o a autorizar un Cambio. [(Diseño del Servicio) Proceso responsable de crear o modificar un Servicio TI o Aplicación. También usado para referirse al Rol o grupo a cargo del trabajo de Desarrollo. Documento que define los Roles, responsabilidades, aptitudes y conocimiento requeridos por una persona en particular. Una Descripción del Puesto de Trabajo puede incluir múltiples Roles, por ejemplo los Roles de Gestor de la Configuración y Gestor del Cambio pueden ser desempeñados por una sola persona. (Transición del Servicio) La Actividad responsable del movimiento de hardware, software, documentación, Procesos, etc nuevos o cambiados, en un Ambiente en Producción. Despliegue es parte del Proceso de Gestión de la Entrega y Desarrollo. Ver Rollout. (Transición del Servicio) Sinónimo de implementación. La mayoría de las veces se refiere a Implementaciones complejas o divididos en fases, o a Implementaciones en múltiples ubicaciones. (Operación del Servicio) Etapa en el Ciclo de vida del Incidente. La detección de resultados en los Incidentes llevan a conocer al Proveedor de Servicios. La detección puede ser automática, o puede ser resultado de un Incidente comunicado por un Usuario. ([Operación del Servicio) Una etapa en Ciclo de vida de Incidentes y Problemas. El propósito de Diagnóstico es identificar un Alternativa (solución temporal) para un Incidente o la Causa Raíz de un Problema. Sinónimo de Diagrama de Ishikawa. Desarrollo [Development] Descripción del Puesto de Trabajo [Job Description] Despliegue [Deployment] Despliegue [Rollout] Detección [Detection]


Pág. 288/321

Diagnóstico [Diagnosis] Diagrama de Espina de Pez [Fishbone Diagram] Diagrama de Ishikawa [Ishikawa Diagram] (Operación del Servicio) (Mejora Continua del Servicio) Una técnica que ayuda a un equipo a identificar las posibles causas de un Problema. Originalmente diseñada por Kaoru Ishikawa, el resultado de está técnica es un diagrama parecido a la espina de un pez. Dimensionamiento de las Aplicaciones [Application Sizing] to Documento [Document] Término Dimensionamiento de las Aplicaciones [Application Sizing] Definición (Diseño del Servicio) Actividad responsable de entender los Requerimientos de Recursos necesarios para apoyar una nueva Aplicación, o un Cambio mayor de una Aplicación existente. El dimensionado de las Aplicaciones ayuda a asegurar que los Servicios TI cumplen con los Objetivos de Nivel de Servicio acordados para la Capacidad y el Rendimiento. (Estrategia del Servicio) Una técnica usada para entender como son impactados los Costes totales por muchos elementos variables complejos que contribuyen a la provisión del Servicio de TI. Dinámica de Coste Variable [Variable Cost Dynamics] Dirección de TI [IT Directorate] (Mejora Continua del Servicio) Gestión Senior dentro de un Proveedor de Servicio, encargado del desarrollo y la provisión de Servicios de TI. Comúnmente usado en los departamentos del Gobierno de UK. (Diseño del Servicio) Actividad o Proceso que identifica Requerimientos y entonces define una solución que es capaz de alcanzar dichos Requerimientos. Ver Diseño del Servicio. (Diseño del Servicio) Una fase en el Ciclo de Vida de un Servicio de TI. El Diseño del Servicio incluye varios Procesos y Funciones y es el título de una de las publicaciones principales de ITIL Ver Diseño. (Diseño del Servicio) Habilidad de un Elemento de Configuración o de un Servicio TI para realizar las Funciones acordadas cuando se requiere. La Disponibilidad la determinan la Certeza, Mantenibilidad, Servicio, Rendimiento, y Seguridad. Normalmente la Disponibilidad se calcula en porcentajes. Éste cálculo se basa normalmente en el Tiempo Acordado para el Servicio y el Tiempo de Parada. Es una Buena Práctica calcular la Disponibilidad usando métricas de las salidas del Negocio respecto del Servicio TI. (Diseño del Servicio) un acercamiento o diseño para alcanzar el 100% de Disponibilidad. Un Servicio TI continuamente disponible no tiene Caída de Servicio (Downtime) planeado ni No planeado. (Operación del Servicio) El uso de la Tecnología de la Información para redirigir una llamada telefónica entrante hacia la persona más adecuada en el menor tiempo posible. Algunas veces se le llama Distribución Automatizada de Llamadas. Diseño [Design] Diseño del Servicio [Service Design] Disponibilidad [Availability] Disponibilidad Continua [Continuous Availability] Distribución Automática de Llamadas [Automatic Call Distribution] (ACD) Documento [Document] Información en forma legible. Un Documento puede ser en papel o electrónico. Por ejemplo un establecimiento de Política, Acuerdo de Nivel de Servicio, Registro de Incidentes, plano del diagrama de una sala de ordenadores. Ver Registro. Driver [Driver] to Elemento de Configuración [Configuration Item] (CI) Término Driver [Driver] Definición Algo que influye en la Estrategia, Objetivos o Requerimientos. Por ejemplo nueva legislación o las acciones de competidores. Es el Rol responsable de asegurar que un Proceso Coincide con su Propósito. Las responsabilidades del Dueño del Proceso cubren el patrocinio, Diseño, Gestión del Cambio y mejora continua del Proceso y sus Métricas. Este Rol se asigna comúnmente a la persona que desempeña también el Rol de Gestor del Proceso, aunque en grandes Organizaciones, ambos Roles pueden estar separados. (Estrategia del Servicio) La reducción en Coste que es asignada a un Servicio TI usando un Activo existente para un propósito adicional. Por ejemplo: entregar un Nuevo Servicio TI con una Infraestructura TI existente. Ver Economías de escala. (Estrategia del Servicio) La reducción en Coste promedio que es posible incrementando la utilización de un Servicio TI o un Activo. Ver Economías de Alcance. (Mejora Continua del Servicio) Una medida de si los Objetivos de un Proceso, Servicio o Actividad han sido alcanzados. Un Efectivo Proceso o Actividad es uno que alcanza sus Objetivos acordados. Ver KPI. Una medida de balance entre la Efectividad y el Coste de un Servicio, Proceso o actividad, Un Proceso de Coste Efectivo es uno que alcanza su Objetivo al mínimo Coste. Ver KPI, Retorno sobre la Inversión, Valor por Dinero. (Mejora Continua del Servicio) Una medida de si el correcto monto de


Pág. 289/321

recursos ha sido utilizado para la provisión de un Proceso, Servicio o Actividad. Un Eficiente Proceso alcanza sus Objetivos con el mínimo de cantidad de tiempo, dinero, gente u otros recursos. Ver KPI. (Estrategia del Servicio) Activo que resulta de interés para Gestión Financiera por estar por encima de un valor financiero acordado. (Transición del Servicio) Cualquier Componente que necesite ser gestionado con el objeto de proveer un Servicio de TI. La información sobre cada CI se almacena en un Registro de Configuración dentro del Sistema de Gestión de la Configuración y es mantenido durante todo su Ciclo de Vida por Gestión de la Configuración. Los CIs están bajo el control de Gestión del Cambio. Típicamente, los CIs pueden ser Servicios de TI, hardware, software, edificios, personal, y documentación formal como por ejemplo documentación sobre Procesos y SLAs. Dueño del Proceso [Process Owner] Economías de Alcance [Economies of scope] Economías de escala [Economies of scale] Efectividad [Effectiveness] Efectividad de Costes [Cost Effectiveness] Eficiencia [Efficiency] Elemento de Capital [Capital Item] Elemento de Configuración [Configuration Item] (CI) Elemento de Coste [Cost Element] to Entorno de Prueba [Test Environment] Término Elemento de Coste [Cost Element] Definición (Estrategia del Servicio) la categoría de nivel medio por la cual los Costes son asignados al Presupuesto y la Contabilidad. La categoría de más alto nivel es el Tipo de Coste. Por ejemplo el Tipo de Coste “Recursos Humanos” podría tener como elementos del coste a nóminas, beneficios sociales, viáticos, formación, horas extras, etc. Elementos de Coste adicionales se descomponen en Unidades de Coste. Por ejemplo el Elemento de Coste “Gastos generales” podría incluir Costes Unitarios de Hoteles, Transportes, Comidas, etc. Sinónimo de Producto Software Empaquetado. Empaquetado [Off the Shelf] Ensamblaje [Assembly] (Transición del Servicio) Un Elemento de Configuración hecho con otros CIs. Por ejemplo un Servidor CI puede contener CIs para el CPUs, Discos, Memoria, etc.; un Servicio TI CI puede contener distinto Hardware, Software y otros CIs. Ver Componente CI, Creación. (Servicio) un subconjunto de Infraestructura TI que es utilizada para un propósito particular. Por ejemplo: Entorno de Producción, Entorno de Prueba, Entorno de Desarrollo. Es posible para múltiples Entornos compartir Elementos de Configuración, por ejemplo Pruebas y Entornos de Producción pueden usar diferentes particiones en un único ordenador mainframe. También utilizado como un término de entorno físico para definir instalaciones, aire acondicionado, sistema eléctrico, etc. Entorno también es usado como término genérico para definir condiciones externas que influyen o afectan algo. (Transición del Servicio) Entorno controlado donde se ensamblan las Aplicaciones, los Servicios TI y otras Creaciones antes de enviarse a Prueba o al Ambiente de Producción. (Diseño del Servicio) Entorno usado para crear o modificar Servicios TI o Aplicaciones. Entornos de Desarrollo no son típicamente sujetos al mismo grado de control como son los Entornos de Pruebas o Entornos de Producción. Ver Desarrollo. (Transición del Servicio) Entorno controlado que contiene Elementos de Configuración Reales empleados para proveer Servicios de TI a los Clientes. Sinónimo de Entorno Real. Entorno [Environment] Entorno de Creación [Build Environment] Entorno de Desarrollo [Development Environment] Entorno de Producción [Live Environment] Entorno de Producción [Production Environment] Entorno de Prueba [Test Environment] (Transición del Servicio) Entorno controlado empleado para probar Items de Configuración, Creaciones, Servicios de TI, Procesos etc


Pág. 290/321

Entregable [Deliverable] to Escenario del Cambio [Change Case] Término Entregable [Deliverable] Definición Algo que debe ser provisto para cumplir un compromiso en un Acuerdo de Nivel de Servicio o un Contrato. Entregable también es usado en forma más informal para una salida planeada de cualquier Proceso. Es el resultado de la realización de una Actividad, el seguimiento de un Proceso, la entrega de un Servicio de TI, etc. El término Entregable es empleado para referirse a los resultados esperados, al igual que a los resultados reales. Ver también Objetivos. (Operación del Servicio) Un defecto o mal funcionamiento que causa Fallos de uno o más Elementos de Configuración o Servicios TI. Un error cometido por una persona o un desperfecto en un Proceso que impacta un CI o un Servicio TI es también un Error. (Operación del Servicio) Problema que posee una Causa Raíz documentada y una Solución Temporal. Los Errores Conocidos son creados y gestionados a través de su Ciclo de Vida por la Gestión del Problema. Los Errores Conocidos pueden ser identificados también por Desarrollo o Suministradores. Habilidad de un Servicio de TI, Proceso, Elemento de Configuración, etc. Para realizar su Función acordada cuando la Carga de Trabajo o el Alcance cambian. (Operación del Servicio) Información a o involucración de niveles de gestión más elevados para ayudar en un Escalado. Entregable [Outcome] Error [Errror] Error Conocido [Known Error] Escalabilidad [Scalability] Escalación Jerárquica [Hierarchic Escalation] Escalación Funcional [Functional Escalation] (Operación del Servicio) Transferir un Incidente, Problema o Cambio a un equipo técnico con mayor experiencia para ayudar en un Escalado. Escalado [Escalation] (Operación del Servicio ) Una Actividad que obtiene Recursos adicionales cuando son necesarios para alcanzar las metas de Nivel de Servicio o las expectativas del Cliente. Escalado puede ser necesario dentro de cualquier Proceso de Gestión de Servicios TI, pero es mucho más comúnmente asociado con Gestión de Incidentes, Gestión de Problemas y Gestión de quejas de Clientes. Hay dos tipos de Escalado: Funcional y Jerárquico. (Operación del Servicio) Técnica utilizada para predecir el impacto de los Cambios propuestos. Los Escenarios del Cambio usan escenarios específicos para clarificar el alcance de los Cambios propuestos y ayudar en el Análisis Coste-Beneficio. Ver Caso de Uso. Escenario del Cambio [Change Case] Especificación [Specification] to Evaluación [Assessment] Término Especificación [Specification] Definición Definición formal de Requerimientos. Una Especificación puede usarse para definir Requerimientos Técnicos u Operacionales, y puede ser interna o externa. Muchos Estándares públicos consisten en un Código de Prácticas y una Especificación. La Especificación define el Estándar frente al que una Organización puede ser Auditada. Nombre de un campo requerido en muchos tipos de Registros. Muestra la situación actual de un Elemento de Configuración, Incidente o Problema, etc en su Ciclo de Vida Requerimiento obligatorio. Por ejemplo ISO/IEC 20000 (estándar internacional), una configuración de seguridad interna estándar para Unix, o un estándar gubernamental acerca de cómo mantenerlos Registros financieros. El término estándar también se emplea para definir un Código de Prácticas o Especificación publicada por una Organización de Estándares como ISO o BSI. Ver Línea Maestra. Uso de la experiencia para proporcionar una valor aproximados para una Métrica o Coste. La Estimación también se usa en Gestión de la Capacidad y Disponibilidad como el más económico y menos preciso método de Modelización. (Estrategia del Servicio) Plan Estratégico diseñado para alcanzar determinados Objetivos. (Estrategia del Servicio) Título de una de los libros Esenciales de ITIL. La Estrategia del Servicio establece una Estrategia conjunta para los Servicios de TI y para la Gestión de Servicios de TI. (Estrategia del Servicio) El más elevado de los tres niveles de Planificación y entrega (Estratégico, Táctico y Operacional). Las Actividades Estratégicas incluyen el establecimiento de Objetivos y la Planificación a largo plazo para alcanzar la Visión global. (Transición del Servicio) La jerarquía y demás Relaciones entre todos los Elementos de Configuración que componen una Configuración. Estado [Status] Estándar [Standard] Estimación [Estimation]


Pág. 291/321

Estrategia [Strategy] Estrategia del Servicio [Service Strategy] Estratégico [Strategic] Estructura de Configuración [Configuration Structure] Etiqueta [Tag] (Estrategia del Servicio) Un código corto empleado para identificar una Categoría. Por ejemplo etiquetas EC1, EC2, EC3 etc pueden ser usadas para identificar diferentes respuestas de Clientes cuando se analizan y comparan Estrategias. El termino Etiquetar se emplea para referir la actividad de asignar Etiquetas. Inspección y análisis para verificar si un Estándar o un conjunto de Guías se está siguiendo, que sus Registros son precisos, o que las metas de Eficiencia y Efectividad se están cumpliendo. Ver Auditoría. Evaluación [Assessment] Evaluación [Evaluation] to Foro para la Gestión de los Servicios de TI [IT Service Management Forum ] (itSMF) Término Evaluación [Evaluation] Definición (Transición del Servicio) Proceso responsable de evaluar un Servicio de TI nuevo o cambiado para asegurar que los Riesgos han sido gestionados y para ayudar a determinar si proceder con el Cambio. La evaluación es también usada para comparar el Resultado medio actual con el pretendido, o comparar una alternativa con otra. Evento [Event] (Operación del Servicio) Un cambio de estado significativo para la cuestión de un Elemento de Configuración o un Servicio de TI. El término Evento también se usa como Alerta o notificación creada por un Servicio de TI, Elemento de Configuración o herramienta de Monitorización. Los Eventos requieren normalmente que el personal de Operaciones de TI tome acciones, y a menudo conllevan el registro de Incidentes. (Diseño del Servicio)Un edificio permanente, disponible para su uso cuando es necesario para el Plan de Continuidad del Servicio de TI. Ver Opción de Recuperación, Facilidad Portátil Algo que debe existir si un Proceso, Proyecto, Plan, o Servicio TI desea ser exitoso. KPIs son usados para medir el alcance de cada CSF. Por ejemplo: un CSF de "proteger Servicios TI cuando se hacen Cambios" podría ser medible por KPIs tales como "porcentaje de reducción de Cambios no exitosos", o "porcentaje de reducción de Cambios que causen Incidentes" etc. Sinónimo de Error. (Operación del Servicio) Pérdida de la habilidad de Operar de acuerdo a las Especificaciones, o de proporcionar el resultado requerido. El término Fallo puede usarse cuando nos referimos a Servicios de TI, Procesos, Actividades, Elementos de Configuración etc. Un Fallo a menudo causa un Incidente. (Diseño del Servicio) Una medida del número de Transacciones, u otras Operaciones, realizadas en un tiempo fijo. Por ejemplo 5000 correos electrónicos enviados por horas, o 200 E/S de disco por segundo. El Foro para la Gestión de los Servicios de TI (itSMF) es una Organización independiente dedicada a promover una aproximación profesional a la Gestión de los Servicios de TI. itSMF es una Organización sin ánimo de lucro con representación en gran número de países por todo el mundo (delegaciones de itSMF). itSMF y sus miembros contribuyen al desarrollo de ITIL y de los Estándares de Gestión de Servicio asociados. Ver http://www.itsmf.com/ para más información. Facilidad Fija [Fixed Facility] Factores Críticos de Éxito [Critical Success Factor] (CSF) Falla [Fault] Fallo [Failure] Flujo [Throughput] Foro para la Gestión de los Servicios de TI [IT Service Management Forum ] (itSMF) Foto Fija [Snapshot] to Gasto Operacional Término Foto Fija [Snapshot] Definición (Transición del Servicio) Estado actual de una Configuración recogido por una herramienta. Empleado también como sinónimo de Comparativa. Ver Línea Base. Ver Provisión de Servicio. Un equipo o grupo de personas y las herramientas que usan para llevar a cabo uno o más Procesos o Actividades. Por ejemplo el Centro de Servicio al Usuario. El término Función también tiene otros dos significados:


Pág. 292/321

• El propósito de un Elemento de Configuración, Persona, Equipo, Proceso o Servicio de TI. Por ejemplo una Función del Servicio de Correo Electrónico puede ser almacenar y reenviar correos, una Función de un Proceso de Negocio puede ser enviar bienes a Clientes.

• Realizar su propósito correctamente. “El ordenador funciona”. (Diseño del Servicio) Una Función de un Proceso de Negocio que es crítica para el éxito del Negocio.

Las Funciones Vitales de Negocio son consideraciones importantes para la Gestión de la Continuidad del Negocio, Gestión de la Continuidad del Servicio de TI y Gestión de la Disponibilidad. (Mejora Continua del Servicio) Actividad de mejora de la que se espera que proporcione un Retorno de la Inversión en un periodo corto de tiempo con relativamente poco Coste y esfuerzo. Ver Principio de Pareto. (Estrategia del Servicio) Una promesa o garantía que un producto o Servicio cumplirá los Requerimientos acordados. Ver Validación y Prueba de Servicio, Garantía de Servicio. (Estrategia del Servicio) Seguridad de que un Servicio de TI cumplirá los Requerimientos acordados. Puede ser un Acuerdo formal como un SLA o Contrato, o un mensaje de marketing o imagen de marca. El valor de Negocio para un Servicio de TI se crea mediante la combinación de la Utilidad del Servicio (lo que hace el Servicio) y la Garantía del Servicio (lo bien que lo hace). Ver Garantía. (Estrategia del Servicio) Coste asociado a la compra de algo que se convertirá en un Activo financiero, por ejemplo equipos informáticos o edificios. El valor de un Activo se Deprecia durante varios periodos contables. Fuente [Source] Función [Function] Función Vital de Negocio [Vital Business Function] (VBF) Ganancia Rápida [Quick Win] Garantía [Warranty] Garantía de Servicio [Service Warranty] Gasto de Capital [Capital Expenditure] (CAPEX) Gasto Operacional Sinónimo de Coste Operacional Gestión de Activos [Asset Management] to Gestión de Demanda [Demand Management] Término Gestión de Activos [Asset Management] Definición (Transición del Servicio) Proceso responsable de dar seguimiento e informar el valor la propiedad de los Activos financieros, en todo el Ciclo de Vida. La Gestión de Activos es parte de Servicios de Activos y de la Gestión de la Configuración. Ver Registro de Activos. (Operación del Servicio) Proceso responsable de gestionar y mantener el almacenamiento de datos a lo largo de su Ciclo de Vida. Gestión de Almacenamiento [Storage Management] Gestión de Aplicaciones [Application Management] Gestión de Capacidad [Capacity Management] (Diseño del Servicio) (Operación del Servicio) Función responsable de gestionar las Aplicaciones en su Ciclo de Vida. (Diseño del Servicio) Proceso responsable de asegurar que la Capacidad de los Servicios de TI y la Infraestructura de TI es capaz de proveer los Objetivos de Nivel de Servicio en los tiempos y Rentabilidad acordados. La Gestión de Capacidad tiene en cuenta todos los Recursos requeridos para proveer el Servicio de TI, y la planificación de los Requisitos de Negocio a corto, medio y largo plazo. (Diseño del Servicio) Proceso responsable de gestionar los Riesgos que podrían impactar seriamente a los Servicios de TI. ITSCM asegura que el Proveedor de Servicios de TI puede proporcionar siempre los Niveles de Servicio mínimos acordados, reduciendo el Riesgo a un nivel aceptable y Planificando la Recuperación de los Servicios de TI. ITSCM debería diseñarse de tal manera que soporte la Gestión de la Continuidad del Negocio. (Estrategia del Servicio) término general que es usado para referirse al Presupuesto y la Contabilidad, algunas veces usado como sinónimo de Gestión Financiera El Proceso responsable para gestionar las implicaciones más amplias de Continuidad de Negocio. Un equipo de Gestión de Crisis es responsable de temas Estratégicos tales como gestión de medios y confianza de accionistas, y decide cuándo invocar los Planes de Continuidad de Negocio. Actividades que entienden e influencian la demanda de Servicios de Usuarios y la provisión de Capacidad para cumplir con esas demandas. Una Gestión de Demanda de nivel Estratégico puede incluir un análisis de Modelos de Actividad de Negocio y Perfiles de Usuarios. Un nivel Táctico puede incluir el uso de Cargos Diferenciales para alentar a los Usuarios a utilizar los Servicios TI en horas de baja actividad. Ver Gestión de Capacidad.


Pág. 293/321

Gestión de Continuidad de los Servicios de TI [IT Service Continuity Management] (ITSCM) Gestión de Costes [Cost Management] Gestión de Crisis [Crisis Management] Gestión de Demanda [Demand Management] Gestión de Eventos [Event Management] to Gestión de la Cartera de Servicios [Service Portfolio Management (SPM) Término Gestión de Eventos [Event Management] Definición (Operación del Servicio) Proceso responsable de la gestión de Eventos a lo largo de su Ciclo de Vida. La gestión de Eventos es una de las principales Actividades de Operaciones de TI. (Operación del Servicio) La Función responsable de gestionar el Entorno Físico donde se localiza la Infraestructura de TI. La gestión de Facilidades incluye todos los aspectos de la gestión del Entorno físico, por ejemplo electricidad y acondicionamiento, Gestión de Acceso a edificios y Monitorización medioambiental. (Transición del Servicio) Proceso responsable de ambos, Gestión del Versión e Implementación. Gestión de Facilidades [Facilities Management] Gestión de Implementación y Versión [Release and Deployment Management] Gestión de Incidencias [Incident Management] (Operación del Servicio) Proceso responsable de la gestión del Ciclo de vida de todos los Incidentes. El objetivo primario de la Gestión de Incidencias es recuperar el Servicio de TI para los Usuarios lo antes posible. (Diseño del Servicio) (Mejora Continua del Servicio) Proceso responsable de la comprensión de la Capacidad, Utilización, y Rendimiento de los Elementos de Configuración. Se recopilan datos, se archivan y se analizan para su uso en el Plan de Capacidad. Ver Gestión de la Capacidad del Servicio. (Diseño del Servicio) (Mejora Continua del Servicio) La Actividad responsable de comprender el Rendimiento y la Capacidad de los Servicios de TI. Los Recursos usado por cada Servicio de TI y el patrón de uso con el paso del tiempo son recogidos, registrados y analizados para ser utilizados en el Plan de Capacidad. Ver Gestión de la Capacidad de Negocio, Gestión de la Capacidad de Componentes. (Diseño del Servicio) En el contexto de ITSM, la Gestión de la Capacidad del Negocio es la Actividad responsable de conocer los Requisitos de Negocio futuros para usarlos en el Plan de Capacidad. Ver Gestión de la Capacidad del Servicio. (Estrategia del Servicio) Proceso responsable de gestionar la Cartera de Servicios. La Gestión de la Cartera de Servicios considera los Servicios en términos del valor de Negocio que proporcionan. Gestión de la Capacidad de los Componentes [Component Capacity Management] (CCM) Gestión de la Capacidad de Servicio [Service Capacity Management] (SCM) Gestión de la Capacidad del Negocio [Business Capacity Management] (BCM) Gestión de la Cartera de Servicios [Service Portfolio Management (SPM) Gestión de la Configuración [Configuration Management] to Gestión de la Seguridad de Información [Information Security Management] (ISM) Término Gestión de la Configuración [Configuration Management] Definición (Transición del Servicio) Proceso responsable de mantener información sobre los Elementos de Configuración requeridos para la provisión de un Servicio de TI, incluyendo las Relaciones entre ellos. Esta información se gestiona durante todo el Ciclo de Vida del CI. La Gestión de la Configuración forma parte de un Activo del Servicio global y del Proceso de Gestión de la Configuración. Sinónimo de IT Service Continuity Management. Gestión de la Continuidad de Servicio [Service Continuity Management] Gestión de la Continuidad del Negocio [Business Continuity Management] (BCM) (Diseño del Servicio) Es el Proceso de Negocio responsable de gestionar el Riesgo que puede tener un alto impacto en el Negocio. BCM protege los intereses de los principales interesados, la reputación, la marca y las actividades que aportan valor al Negocio. Los Procesos de BCM incluyen reducir el Riesgo a un nivel aceptable y planificar el restablecimiento de los Procesos de Negocio ante una situación. BCM establece los Objetivos, el Ámbito y los Requerimientos para una Gestión de la Continuidad del Servicio. (Diseño del Servicio) Proceso responsable de definir, analizar, Planificar, medir y mejorar todos los aspectos relativos a la Disponibilidad de los Servicios TI. La Gestión de la Disponibilidad tiene la responsabilidad de que toda la Infraestructura TI, Procesos, Herramientas, Roles etc. estén de acuerdo con las Metas de Nivel de Servicio para la Disponibilidad. (Estrategia del Servicio) El Proceso o Función responsable por el mantenimiento de la Relación con el Negocio. Normalmente incluye:

• Gestionar las Relaciones personales con los directivos del Negocio


Pág. 294/321

• Proveer información a la Gestión del Portafolio de Servicios • Asegurarse de que el Proveedor de Servicios TI está satisfaciendo las necesidades de los Clientes en el

Negocio. Este Proceso está fuertemente relacionado con la Gestión de Niveles de Servicio. (Diseño del Servicio) Proceso que asegura la Confidencialidad, Integridad y Disponibilidad de los Activos de una Organización, información, datos y Servicios de TI. La Gestión de la Seguridad de la información forma parte normalmente de la Gestión de la Seguridad de la Organización, la cual tiene un ámbito más amplio que las del Proveedor de Servicio de TI e incluye accesos a edificios, llamadas de teléfonos, etc para toda la Organización. Gestión de la Disponibilidad [Availability Management] Gestión de la Relación con el Negocio [Business Relationship Management] Gestión de la Seguridad de Información [Information Security Management] (ISM) Gestión de los Servicios de Negocio [Business Service Management] (BSM) to Gestión de Sistemas [System Management] Término Gestión de los Servicios de Negocio [Business Service Management] (BSM) Definición (Estrategia del Servicio) (Diseño del Servicio) Aproximación a la gestión de Servicios de TI que tiene en cuenta los Procesos de Negocio soportados y el valor de Negocio proporcionado. Este término también hace referencia a la gestión de Servicios de Negocio proporcionados a Clientes de Negocio. Implantación y gestión de Servicios de TI de Calidad que cumplan con las necesidades del Negocio. La Gestión de los Servicios de TI es llevada a cabo por los Proveedores de Servicios de TI a través de la combinación apropiada de personas, Procesos y Tecnologías de la Información. Ver Gestión de Servicio. Sinónimo de Gestión de Operaciones de TI. Gestión de los Servicios de TI [IT Service Management] (ITSM) Gestión de Operaciones [Operations Management] Gestión de Operaciones de TI [IT Operations Management] (Operación del Servicio) Función dentro de un Proveedor de Servicio que se encarga de ejecutar las Actividades diarias necesarias para gestionar los Servicios de TI y la Infraestructura de TI que los soporta. Gestión de Operaciones de TI incluye el Control de Operaciones de TI y la Gestión de las Instalaciones. (Operación del Servicio) Es el Proceso responsable del la gestión del Ciclo de Vida de todos los Problemas. El principal Objetivo de la Gestión de Problemas es la prevención de Incidentes, al igual que la reducción del Impacto de aquellos Incidentes que no haya sido posible prevenir. El Proceso responsable por la identificación, determinación y control de Riesgos. Ver Determinación de Riesgos. La metodología OGC para la gestión de Riesgos. MoR incluye todas las Actividades necesarias para identificar y Controlar toda exposición al Riesgo que pueda tener un impacto en la consecución de los Objetivos de Negocio de la Organización. Ver http://www.m-o-r.org/ para más detalles. Sinónimo de Gestión de la Seguridad Informática. Gestión de Problemas [Problem Management] Gestión de Riesgo [Risk Management] Gestión de Riesgos [Management of Risk] (MoR) Gestión de Seguridad [Security Management] Gestión de Sistemas [System Management] La parte de la Gestión del Servicio de TI que se centra en la gestión de la Infraestructura de TI en lugar de en los Procesos. Gestión de Versión [Release Management] to Gestión del Servicio [Service Management] Término Gestión de Versión [Release Management] Definición (Transición del Servicio) Proceso responsable de la Planificación, Agendado y Control de movimiento de Versiones a Probar y de Entornos Vivos. El Objetivo primario de la Gestión de Versión es asegurarse de que la integridad del Entorno Vivo esté protegido y que los Componentes correctos son implementados. La Gestión de Versión es parte del Proceso de Gestión de Implementación y Versión. (Operación del Servicio) Proceso responsable de permitir a los Usuarios hacer uso de los Servicios de TI, datos, u otros Activos. La Gestión de Acceso ayuda a proteger la Confidencialidad, la Integridad y la Disponibilidad de los Activos, asegurando que sólo Usuarios autorizados pueden acceder o modificar los Activos. Algunas veces también es posible referirse a la Gestión del Acceso como


Pág. 295/321

Gestión de Derechos o como Gestión de la Identidad. (Diseño del Servicio) Proceso responsable de asegurar que todos los Contratos y Proveedores soportan las necesidades del Negocio, y que todos los Proveedores cumplen sus compromisos contractuales. (Transición del Servicio) Proceso responsable del control del Ciclo de Vida de los Cambios. El objetivo primario de Gestión del Cambio es permitir la ejecución de los Cambios a realizar, con la mínima afectación a los Servicios de TI. (Transición del Servicio) Proceso responsable de recoger, analizar, almacenar y compartir conocimiento e información dentro de una Organización. El propósito principal de la Gestión del Conocimiento es mejorar la Eficiencia reduciendo la necesidad de redescubrir el conocimiento. Ver Datos para la Información, el Conocimiento y el Saber, Sistema de Gestión del Conocimiento del Servicio. (Diseño del Servicio) (Mejora Continua del Servicio) Proceso responsable de negociar y asegurar el cumplimiento de los SLAs. SLM es responsable de asegurar que todos los Procesos de Gestión del Servicio de TI, Acuerdos de Nivel Operacional y Contratos de Soporte son adecuados a los Objetivos de Nivel de Servicio. SLM monitoriza y reporta los Niveles de Servicio y mantiene revisiones periódicas con el Cliente. (Mejora Continua del Servicio) Es el Proceso responsable de las Actividades del día a día dentro de la Gestión de la Capacidad. Incluye la Monitorización, detección de Umbrales, análisis de Rendimiento y Optimización, así como la implementación de Cambios relacionados con el Rendimiento o la Capacidad. La Gestión del Servicio es un conjunto de capacidades organizativas especializadas empleadas para proporcionar valor a los Clientes en forma de Servicios. Gestión del Acceso [Access Management] Gestión del aprovisionamiento [Supplier Management] Gestión del Cambio [Change Management] Gestión del Conocimiento [Knowledge Management] Gestión del Nivel de Servicio [Service Level Management] (SLM) Gestión del Rendimiento [Performance Management] Gestión del Servicio [Service Management] Gestión Financiera [Financial Management] to Gestor del Proceso [Process Manager] Término Gestión Financiera [Financial Management] Gestión Proactiva de Problemas [Proactive Problem Management] Definición (Estrategia del Servicio) La Función y Procesos responsable de gestionar los requerimientos de Presupuesto, Contabilidad y Cargos de un Proveedor de Servicio de TI (Operación del Servicio) Parte del Proceso de Gestión de Problemas. El Objetivo de la Gestión Proactiva de Problemas es la predicción de Problemas. La Gestión Proactiva de Problemas analiza los Registros de Incidencias, así como los datos recibidos por otros Procesos de Gestión de Servicios TI con el propósito de identificar posibles Problemas o tendencias que puedan causarlos. (Operación del Servicio) La Función responsable de proporcionar capacidades técnicas en el soporte de los Servicios de TI y en la gestión de la infraestructura de TI. La gestión Técnica define los roles de los Grupos de Soporte, así como las herramientas, Procesos y Procedimientos requeridos. (Mejora Continua del Servicio) Una metodología para gestionar la mejora continua mediante el uso del Sistema de Gestión de Calidad. TQM estable una Cultura, involucrando a todo el personal en la Organización en un Proceso de continua monitorización y mejora. (Estrategia del Servicio) Rol muy parecido a Gestor de la Relación con el Negocio pero incluye más aspectos comerciales. Se utiliza más cuando se trabaja con Clientes Externos. (Estrategia del Servicio) El Rol responsable de mantener la Relación con uno o más Clientes. Este Rol es a menudo combinado con el de Gestor de Nivel de Servicio. Gestión Técnica [Technical Management] Gestión Total de Calidad [Total Quality Management] (TQM) Gestor de Cuenta [Account Manager] Gestor de la Relación con el Negocio [Business Relationship Manager] (BRM) Gestor de Servicio [Service Manager] Gestor que es responsable de administrar el Ciclo de Vida de uno o más Servicios de TI de principio a fin. El término Gestor de Servicio también se emplea para referirse a un gestor dentro del Proveedor de Servicios de TI. Comúnmente empleado para referirse al Gestor de la Relación con el Negocio, Gestor de Procesos o Gestor de Cuenta o un gestor con responsabilidad en el conjunto de Servicios de TI. Es el Rol responsable de la gestión Operativa de un Proceso. Las responsabilidades del Gestor del Proceso cubren la Planificación y coordinación de todas las Actividades necesarias


Pág. 296/321

para el desarrollo, seguimiento y registro de actividad de un Proceso. Puede existir más de un Gestor del Proceso para un Proceso determinado, como pueden ser Gestores de Cambio por regiones geográficas, o Gestores de Continuidad del Servicio para cada Centro de Proceso de Datos. El Rol de Gestor del Proceso se asigna comúnmente a la persona que desempeña también el Rol de Dueño del Proceso aunque en grandes Organizaciones, ambos Roles pueden estar separados. Gestor del Proceso [Process Manager] Gobierno [Governance] to Horas de Servicio [Service Hours] Término Gobierno [Governance] Definición Asegurar que las Políticas y Estrategias se implementan, y que los Procesos requeridos se siguen correctamente. El Gobierno incluye definir los Roles y Responsabilidades, medir y reportar, y tomar acciones para resolver cualquier asunto identificado. (Mejora Continua del Servicio) Un gráfico de Monitorización del los SLA empleado para reportar y monitorizar los resultados obtenidos frente a los Objetivos de Nivel de Servicios. Un gráfico SLAM contiene normalmente un código de colores para mostrar la medida en que cada uno de los Objetivos de Nivel de Servicio ha sido alcanzado en cada uno de los 12 meses precedentes. Los pasos iniciales de la Gestión de Riesgos. Al analizar el valor de los Activos del negocio, identificando Amenazas a esos Activos, y evaluando cuan Vulnerable cada Activo es a esas Amenazas. El Gravamen de Riesgo puede ser cuantitativo (basado en información numérica) o cualitativa. (Operación del Servicio) Un grupo de personas con capacidades técnicas. Los grupos de soporte proporcionan el Soporte Técnico necesitado por todo el Proceso de Gestión del Servicio de TI. Ver Gestión Técnica. (Operación del Servicio) Un estructurado conjunto de preguntas usada por el personal del Centro de Servicios a Usuarios para asegurar que ellos realizan las preguntas correctas y les ayuda a Clasificar, Resolver y asignar Incidentes. La Guía de Diagnóstico también puede estar disponible para los Usuarios para ayudarles a diagnosticar y resolver sus propios Incidentes. (Estrategia del Servicio) Capacidad de una Organización, persona, Proceso, Aplicación, Elemento de Configuración o Servicio de TI para el desarrollo de una Actividad. Las Habilidades son Activos intangibles de una Organización. Ver Recurso. (Diseño del Servicio) Una Opción de Recuperación. El Proveedor de Servicios formalmente acuerda con el Cliente que la Recuperación de este Servicio TI no será realizada. (Transición del Servicio) Información de todos los cambios realizados sobre un Elemento de Configuración durante su ciclo de vida. La Historia del Cambio consiste en todos aquellos Registros de Cambio que aplican al CI. (Diseño del Servicio) (Mejora Continua del Servicio) Periodo de tiempo acordado durante el que un determinado Servicio de TI debe estar Disponible. Por ejemplo, Lunes-Viernes 08:00 a 17:00 exceptuando festivos. Las Horas de Servicio deben definirse en un Acuerdo de Nivel de Servicio (SLA). Gráfico SLAM [SLAM Chart] Gravamen de Riesgo [Risk Assessment] Grupo de Soporte [Support Group] Guía de Diagnóstico [Diagnostic Script] Habilidad [Capability] Hacer Nada [Do Nothing] Historia del Cambio [Change History] Horas de Servicio [Service Hours] Horas de Soporte [Support Hours] to Incidente Grave [Major Incident] Término Horas de Soporte [Support Hours] Definición (Diseño del Servicio) (Operación del Servicio) Tiempos u horas cuando el soporte está disponible para los Usuarios. Típicamente estas son las horas en las que el Centro de Servicio al Usuario está disponible. Las horas de soporte deben ser definidas en el Acuerdo de Nivel de Servicio, y pueden ser distintas de las Horas de Servicio. Por ejemplo, las Horas de Servicio pueden ser 24 horas al día, pero las Horas de Soporte pueden ser de 07:00 a 19:00. (Operación del Servicio) Un nombre único empleado para identificar a un Usuario, persona o Rol. La identidad se usa para garantizar Derechos a ese Usuario, persona o Rol. Ejemplos pueden ser Nombre de Usuario SmiithJ o el Rol de “Gestor de Cambios”. (Transición del Servicio) Actividad responsable de recopilar información sobre Elementos de Configuración y sus Relaciones, e introducir esta información en la CMDB. La Identificación de Configuración también es responsable del etiquetado de los CIs, con el objeto de que los correspondientes Registros de Configuración puedan ser


Pág. 297/321

accesibles. (Transición del Servicio) Convención de nomenclatura utilizada para identificar una Versión de forma única. La Identificación de la Versión habitualmente incluye una referencia al Elemento de Configuración y al número de versión. Por ejemplo, Microsoft Office 2003 SR2. (Operación del Servicio) (Transición del Servicio) Una medida del efecto de un Incidente, Problema o Cambio en los Procesos de Negocio. El Impacto está a menudo basado en cómo serán afectados los Niveles de Servicio. El Impacto y la Urgencia se emplean para asignar la Prioridad. (Estrategia del Servicio) Requerir pago por la provisión de Servicios de TI. La Imputación de Costes para Servicios de TI es opcional, y muchas Organizaciones optan por tratar a su Proveedor de Servicios de TI como un Centro de Coste. (Operación del Servicio) Interrupción no planificada de un Servicio de TI o reducción en la Calidad de un Servicio de TI. También lo es el Fallo de un Elemento de Configuración que no ha impactado todavía en el Servicio. Por ejemplo el Fallo de uno de los discos de un “mirror”. (Operación del Servicio) Es la Categoría más alta de Impacto para un Incidente. Un Incidente Grave tiene como consecuencia una interrupción importante en el Negocio. Identidad [Identity] Identificación de Configuración [Configuration Identification] Identificación de Versión [Release Identification] Impacto [Impact] Imputación de Costes [Charging] Incidente [Incident] Incidente Grave [Major Incident] Indicador Clave de Rendimiento [Key Performance Indicator ] (KPI) to Integración de Telefonía e Informática [Computer Telephony Integration] (CTI) Término Indicador Clave de Rendimiento [Key Performance Indicator ] (KPI) Definición (Mejora Continua del Servicio) Métrica empleada para ayudar a gestionar un Proceso, Servicio de TI o Actividad. Muchas Métricas pueden medirse, pero sólo las más importantes se definen como KPIs y son empleadas para gestionar de forma activa e informar sobre los Procesos, los Servicios de TI o las Actividades. Los KPIs deberían ser seleccionados de tal forma que aseguren el control de la Eficiencia, la Efectividad, y la Rentabilidad. Ver Factores Críticos de Éxito. Información empleada para soportar la toma de decisiones por los gerentes. La Información de Gestión a menudo es generada automáticamente por las herramientas que soportan los diversos Procesos de Gestión de Servicios de TI. La Información de Gestión suele incluir los valores de los KPIs como por ejemplo "Porcentaje de Cambios precedidos por Incidentes", o "tasa de resolución en el primer nivel". Documento que contiene detalles de uno o más KPIs u otros objetivos que han sobrepasado sus Umbrales definidos. Por ejemplo objetivos de los SLAs fallidos a punto de ello, y Métricas de Rendimiento indicando un problema potencial de Capacidad. Todo el hardware, software, redes, instalaciones etc. requeridas para Desarrollar, Probar, proveer, Monitorizar, Controlar o soportar los Servicios de TI. El término Infraestructura de TI incluye todas las Tecnologías de la Información pero no las personas, Procesos y documentación asociados. Sinónimo de Aprovisionamiento Interno. Información de Gestión [Management Information] Informe de Excepción [Exception Report] Infraestructura de TI [IT Infrastructure] Insourcing [Insourcing] Instalaciones Portátiles [Portable Facility] (Diseño del Servicio) Edificios prefabricados o vehículos de grandes dimensiones, proporcionados por Terceras Partes y trasladados de sitio cuando es necesario, como parte de un Plan de Continuidad del Servicio de TI. Ver también Opciones de Recuperación, Instalaciones Fijas. Un Documento conteniendo instrucciones detalladas que especifican exactamente qué pasos seguir para acometer una Actividad. Una Instrucción de Trabajo contiene mucho más detalle que un Procedimiento y sólo se crea cuando se necesitan instrucciones muy detalladas. (Operación del Servicio) Término genérico que cubre cualquier tipo de integración entre computadoras y Sistemas de Telefonía. Se usa típicamente para


Pág. 298/321

hacer referencia a Sistemas donde una Aplicación muestra detalles relacionados con llamadas telefónicas entrantes o salientes. Ver Distribución Automática de Llamada, Respuesta Interactiva de Voz. Instrucción de Trabajo [Work Instruction] Integración de Telefonía e Informática [Computer Telephony Integration] (CTI) Integridad [Integrity] to ITIL [ITIL] Término Integridad [Integrity] Definición (Diseño del Servicio) Un principio de seguridad que certifica que los datos y Elementos de Configuración sólo son modificados por personal y Actividades autorizados. La Integridad considera todas las posibles causas de modificación, incluyendo Fallos software y hardware, Eventos medioambientales e intervención humana. (Estrategia del Servicio) Interfaz entre el Proveedor de Servicios TI y un Usuario, Cliente, Proceso de Negocio o Proveedor. El análisis de los Interfaces del Proveedor de Servicios ayuda en la coordinación la gestión extremo a extremo de los Servicios de TI. Interfaz del Proveedor de Servicios [Service Provider Interface] (SPI) Interrupción Prevista del Servicio [Projected Service Outage] (PSO) Invocación [Invocation] (Transición del Servicio) Documento que identifica el efecto sobre los Niveles de Servicio de los Cambios planificados, Actividades de mantenimiento o los Planes de Pruebas. (Diseño del Servicio) Inicio de los pasos definidos en un plan. Por ejemplo, iniciar el Plan de Continuidad del Servicio de TI para uno o más Servicios de TI. Término genérico que se refiere a un conjunto de Estándares y Directrices para los Sistemas de Gestión de Calidad. Ver http://www.iso.org/ para más información. Ver ISO. Estándar internacional para los Sistemas de Gestión de Calidad. Ver ISO 9000, Estándar. (Mejora Continua del Servicio) Código de Práctica ISO para la Gestión de la Seguridad de la Información. Ver Estándar. Especificación ISO y Código de Práctica para la Gestión de los Servicios de TI. ISO/IEC 20000 está alineado con las Mejores Prácticas ITIL. (Diseño del Servicio) (Mejora Continua del Servicio) Especificación ISO para la Gestión de la Seguridad de la Información. El Código de Práctica correspondiente es ISO/IEC 17799. Ver Estándar. Conjunto de Mejores Prácticas para la Gestión de Servicios de TI. ITIL es propiedad de la OGC y consiste en una serie de publicaciones que aconsejan sobre la provisión de Servicios de TI de Calidad, y sobre los Procesos y las instalaciones necesarias para soportarlos. Ver http://www.itil.co.uk/ para más información. ISO 9000 ISO 9001 ISO/IEC 17799 ISO/IEC 20000 ISO/IEC 27001 ITIL [ITIL] Línea Base [Baseline] to Madurez [Maturity] Término Línea Base [Baseline] Definición (Mejora Continua del Servicio) Una Referencia que se usa como punto de marca. Por ejemplo:

• Una Línea Base de ITSM se puede usar como punto de partida para medir el resultado de un Plan de Mejora del Servicio

• Una Línea Base de Rendimiento se puede usar para medir cambios en el Rendimiento de un Servicio TI en un periodo de tiempo.

• Una Línea Base de la Gestión de la Configuración puede servir para restablecer la Infraestructura TI en una Configuración conocida en caso de un fallo de un Cambio o de un Entregable (Transición del Servicio) Una Línea de Referencia de una Configuración que ha sido formalmente acordada y se gestiona a través del proceso de Gestión del Cambio. Una Línea de Referencia de Configuración se usa como base para futuras Construcciones, Entregas y Cambios. (Estrategia del Servicio) Servicio Esencial o Servicio de Soporte que posee múltiples Paquetes del Nivel de Servicio. Una Línea de Servicio es gestionada por un Gestor de Producto y cada Paquete del Nivel de Servicio se designa para soportar un segmento de mercado en particular. Un Documento describiendo las Mejores Prácticas, que recomienda qué debe hacerse. El


Pág. 299/321

seguimiento de una Linea Maestra no es normalmente obligado. Ver Estándar. (Operación del Servicio) Llamada telefónica de un Usuario al Centro de Servicio al Usuario. Una Llamada puede derivar en el registro de un Incidente o una Petición de Servicio. (Diseño del Servicio) Técnica que ayuda a un equipo a generar ideas. Durante una sesión de Lluvia de ideas, las ideas no se revisan, pero sí en una etapa posterior. La Gestión de Problemas usa con frecuencia la Lluvia de Ideas para identificar posibles causas. (Mejora Continua del Servicio) Medida de la Fiabilidad, Eficiencia y Efectividad de un Proceso, Función, Organización etc. Los Procesos y Funciones más maduros están íntimamente alineados a los Objetivos de Negocio y a la Estrategia, y están soportados por un marco de trabajo para la mejora continua.

Línea de Referencia de Configuración [Configuration Baseline] Línea de Servicio [Line of Service] (LOS) Línea Maestra [Guideline] Llamada [Call] Lluvia de ideas [Brainstorming] Madurez [Maturity] Mantenibilidad [Maintainability] to Métricas de Tensión [Tension Metrics] Término Mantenibilidad [Maintainability] Definición (Diseño del Servicio) Medida de cómo de rápida y Efectivamente se puede restaurar un Elemento de Configuración o Servicio de TI a su funcionamiento normal después de un Fallo. La Mantenibilidad se mide y reporta frecuentemente como MTRS. El término Mantenibilidad se emplea también en el contexto de Desarrollo de Software o Desarrollo de Servicios de TI refiriéndose a la capacidad de ser Cambiado o Reparado fácilmente. Sinónimo de RACI. Matriz de Autoridad [Authority Matrix] Mejora Continua del Servicio [Continual Service Improvement] (CSI) (Mejora Continua del Servicio) Una etapa en el Ciclo de vida de un Servicio TI y el título de una de las publicaciones Medulares ITIL. La Mejora Continua del Servicio es responsable para la gestión de mejoras al Servicio TI y la Gestión de Procesos. El Desempeño de los proveedores de Servicios TI es medido continuamente y las mejoras son realizadas en los Procesos, Servicios TI e Infraestructura TI para incrementar su Eficiencia y Efectividad, y Efectividad en Costes. Ver Plan-Do-Check-Act. (Estrategia del Servicio) Todas las oportunidades que un Proveedor de Servicios de TI puede explotar para satisfacer las necesidades de negocio de los Clientes. El Mercado identifica los posibles Servicios de TI de los que un Proveedor de Servicios de TI podría desear considerar su prestación. (Mejora Continua del Servicio) Algo que se mide y reporta para ayudar a gestionar un Proceso, Servicio de TI o Actividad. Ver KPI. Métrica usada para medir la entrega de un Servicio de TI a un Cliente. Las Métricas Externas son normalmente definidas en los SLAs y reportadas a los Clientes. Ver Métrica Interna. Métrica que es empleada dentro del Proveedor de Servicio de TI para monitorizar la Eficacia, Efectividad o Efectividad en Coste de los Procesos internos de un Proveedor de Servicio de TI. Las Métricas internas no son normalmente trasladadas al Cliente del Servicio de TI. Ver Métrica Externa. (Mejora Continua del Servicio) Conjunto de Métricas relacionadas, en las cuales mejoras a una métrica tienen un efecto negativo en otra. Las Métricas de Tensión se diseñan para asegurar que se obtiene el equilibrio apropiado. Mercado [Market Space] Métrica [Metric] Métrica Externa [External Metric] Métrica interna [Internal Metric] Métricas de Tensión [Tension Metrics] Middleware [Middleware] to (eSCM-SP) Término Middleware [Middleware] Definición (Diseño del Servicio) Software que conecta uno o más Componentes o Aplicaciones software. El Middleware generalmente se adquiere de un Suministrador, en lugar de desarrollarlo dentro del Proveedor de Servicios de TI. Ver Empaquetado. Técnica que se


Pág. 300/321

emplea para predecir el comportamiento futuro de un Sistema, Proceso, Servicio de TI, Elemento de Configuración etc. El Modelado suele emplearse en Gestión Financiera, Gestión de Capacidad y Gestión de la Disponibilidad. (Estrategia del Servicio) (Diseño del Servicio) (Mejora Continua del Servicio) Técnica que utiliza Modelos matemáticos para predecir el comportamiento de un Elemento de Configuración o Servicio TI. Los Modelos Analíticos se usan con mayor frecuencia en la Gestión de la Capacidad y en la Gestión de la Disponibilidad. Ver Modelado. Representación de un Sistema, Proceso, Servicio de TI, Elemento de Configuración etc. empleado para ayudar a entender o predecir comportamientos futuros. (Transición del Servicio) Modo repetible de gestionar una Categoría particular de Cambio. Un Modelo de Cambio enumera los pasos específicos predefinidos que deberán ser seguidos para un Cambio perteneciente a esa Categoría. Los Modelos de Cambio deben ser muy simples, y que no requieran de aprobación (ej. Cambio de contraseña) o pueden ser muy complejos y que incluyan muchos pasos que requieran de aprobación (ej. Despliegue de una nueva versión de software). Ver Cambio Estándar, Comité de Cambios. (Estrategia del Servicio) un marco de referencia para ayudar a Organizaciones en sus análisis y decisiones sobre Service Sourcing Models and Strategies. eSCM-CL fue desarrollado por Carnegie Mellon University. Ver eSCM-SP. Modelado [Modelling] Modelado analítico [Analytical Modelling] Modelo [Model] Modelo de Cambio [Change Model] Modelo de Capacitación para clientes [eSourcing Capability Model for Client Organizations] (eSCM-CL) Modelo de Capacitación para Proveedores [eSourcing Capability Model for Service Providers] (eSCM-SP) (Estrategia del Servicio) Un marco de trabajo para ayudar a los Proveedores de Servicios de TI a desarrollar sus Capacidades de Gestión de Servicios de TI desde una perspectiva de Aprovisionamiento del Servicio. ESCM-CL fue desarrollado por Carnegie Mellon University. Ver eSCM-CL. Modelo de Integración de Madurez de la Capacidad [Capability Maturity Model Integration] (CMMI) to Monitorización [Monitoring] Término Modelo de Integración de Madurez de la Capacidad [Capability Maturity Model Integration] (CMMI) Definición (Mejora Continua del Servicio) El Modelo de Integración de Madurez de la Capacidad (CMMI) es una aproximación a la mejora de procesos desarrollada por el Software Engineering Institute (SEI) de la Carnegie Melon University. CMMI provee a las organizaciones de los elementos esenciales para la efectividad de los procesos. El modelo puede ser usado para habilitar la mejora de procesos a lo largo de un proyecto, una división, o una organización completa. CMMI ayuda a integrar funciones de la organización tradicionalmente separadas, fijar prioridades y objetivos en la mejora de procesos, guías para la calidad de los procesos, y proporcionar un punto de referencia para la evaluación de los procesos en curso. Consultar http://www.sei.cmu.edu/cmmi/ para más información. Ver CMM, Mejora Continua, Madurez. (Estrategia del Servicio) Modelo desarrollado por Noriaki Kano empleado para ayudar a entender las preferencias del Cliente. El Modelo de Kano considera que los Atributos de un Servicio de TI se encuentran agrupados en áreas como Factores Básicos, Factores de Agitación, Factores de Rendimiento etc. (Mejora Continua del Servicio) El Modelo de Madurez de la Capacidad para el Software (también conocido como CMM y SWCMM) es un modelo usado con el objeto de identificar las Mejores Prácticas para ayudar a incrementar la Madurez del Proceso. CMM fue desarrollado en el Software Engineering Institute (SEI) de la Carnegie Mellon University. En el año 2000, SW-CMM se actualizó como CMMI® (Modelo de Integración de Madurez de la Capacidad). El SEI ha dejado de mantener el modelo SW-CMM, sus métodos asociados de evaluación, y material de formación. (Diseño del Servicio) (Mejora Continua del Servicio) Técnica que crea un Modelo detallado para predecir el comportamiento de un Elemento de Configuración o Servicio de TI. Los Modelos de Simulación pueden ser muy precisos pero suelen son caros y tardan en crearse. Los Modelos de Simulación se crean a menudo empleando los Elementos de Configuración reales que se quieren modelizar, con Transacciones o Cargas de Trabajo artificiales. Se usan en Gestión de la Capacidad cuando se necesitan resultados precisos. A veces son denominados Comparativas de Rendimiento. Una aproximación a la evaluación del Impacto potencial de Fallos. FMEA involucra el análisis de qué podría pasar tras el fallo de cada Elemento de Configuración, hasta su efecto en el Negocio. FMEA es a menudo usado en Gestión de la Información de Seguridad y en Planificación de Continuidad del Servicio de TI. (Operación del Servicio) Observación repetida de un Elemento de Configuración, Servicio de TI o Proceso para detectar Eventos y asegurarse de que se conoce el estado actual. Modelo de Kano [Kano Model]


Pág. 301/321

Modelo de Madurez de la Capacidad [Capability Maturity Model] (CMM) Modelo de Simulación [Simulation modelling] Modos de Fallo y Análisis de Efectos [Failure Modes and Effects Analysis] (FMEA) Monitorización [Monitoring] Monitorización Activa [Active Monitoring] to Objetivo de Mantenimiento del Servicio [Service Maintenance Objective] Término Monitorización Activa [Active Monitoring] Definición (Operación del Servicio) Monitorización de un Elemento de Configuración o de un Servicio TI que utiliza de forma regular revisiones automatizadas para descubrir el estado actual. Ver Monitorización Pasiva. (Operación del Servicio) Monitorización de un Elemento de Configuración, un Servicio TI o un Proceso que depende de una Alerta o notificación para la identificación de su estado. Ver también Monitorización Activa. (Operación del Servicio) Se trata de la Monitorización que trata de encontrar patrones, a partir de Eventos, para predecir posibles Fallos futuros. Ver también Monitorización Reactiva. (Operación del Servicio) Monitorización de esa acción en respuesta a un Evento. Por ejemplo, enviando un proceso por lotes cuando un proceso anterior se completa, o enviando un Incidente cuando ocurra un Error. Ver Monitorización Proactiva. (Estrategia del Servicio) El total de una entidad u Organización compuesta por un número de Unidades de Negocio. En el contexto de ITSM, en el Negocio se incluye tanto el sector público, como el privado y organizaciones sin fines de lucro. Un Proveedor de Servicios TI provee de Servicios TI a un Cliente que es parte del Negocio. El Proveedor de Servicio TI puede ser parte del mismo Negocio que el Cliente (Proveedor de Servicio Interno) o parte de otro Negocio (Proveedor de Servicio Externo). Nivel identificado en un modelo de Madurez como el Modelo de Integración de Madurez de la Capacidad de Carnegie Mellon. Resultados medidos y reportados frente a uno o más Objetivos de Nivel de Servicio. El término Nivel de Servicio es a veces empleado para refererise a un Objetivo de Nivel de Servicio. El propósito o la intención definidos de un Proceso, una Actividad o una Organización en su totalidad. Los Objetivos se expresan generalmente como metas medibles. El término Objetivo se usa también de manera informal para querer decir Requisito. Ver Salida. (Operación del Servicio) Tiempo esperado en el que un Elemento de Configuración no estará disponible debido a una Actividad de mantenimiento programada. Monitorización Pasiva [Passive Monitoring] Monitorización Proactiva [Proactive Monitoring] Monitorización Reactiva [Reactive Monitoring] Negocio [Business] Nivel de Madurez [Maturity Level] Nivel de Servicio [Service Level] Objetivo [Objective] Objetivo de Mantenimiento del Servicio [Service Maintenance Objective] Objetivo de Nivel de Servicio [Service Level Target] to Oficina de Comercio del Gobierno [Office of Government Commerce] (OGC) Término Objetivo de Nivel de Servicio [Service Level Target] Definición (Diseño del Servicio) (Mejora Continua del Servicio) Compromiso que está documentado en un SLA. Los Objetivos de Nivel de Servicio se basan en los Requerimientos de Nivel de Servicio y son necesarios para asegurar que el Diseño del Servicio de TI es Ajustado al Propósito del mismo. Los Objetivos de Nivel de Servicio deben ser SMART y normalmente se basan en KPIs. (Operación del Servicio) La cantidad máxima de información que puede ser perdida cuando el Servicio es restaurado tras una interrupción. El Objetivo de Punto de Recuperación se expresa como una longitud de tiempo antes del Fallo. Por ejemplo, un Objetivo de Punto de Recuperación de un día debe ser soportado por Copias de Seguridad diarias, y hasta 24 horas de información pueden ser perdidas. Los Objetivos de Punto de Recuperación para cada Servicio de TI deberían ser negociados, acordado y documentado, y utilizado como Requisitos para el Diseño del Servicio y los Planes de Continuidad de TI. (Operación del Servicio) El tiempo máximo permitido para la recuperación de un Servicio de TI tras una interrupción. El Nivel de Servicio a ser provisto debe ser inferior a los Objetivos de Nivel de Servicio. Los Objetivos de Tiempo de Recuperación para cada Servicio de TI deberían ser negociados, acordados y documentados. Ver Análisis de Impacto de Negocio. (Estrategia del Servicio) El Objetivo de un Proceso de Negocio, o del Negocio como un todo. Los Objetivos del Negocio apoyan la Visión de Negocio, proveen de guías para la Estrategia de TI, y frecuentemente reciben apoyo de los Servicios TI. (Mejora Continua del Servicio) Una técnica usada en la Mejora del Servicio, investigación de


Pág. 302/321

Problemas y Gestión de la Disponibilidad. El personal de Soporte Técnico se reúne para monitorizar el comportamiento y Rendimiento de un Servicio de TI y realizar recomendaciones de mejora. (Estrategia del Servicio) Provisión de Servicios desde una localización externa al país del Cliente y, frecuentemente, en diferente continente. Puede tratarse de un Servicio de TI, o de funciones de soporte, como podría ser el Centro de Servicio al Usuario. Ver también On-shore, Near-shore. OGC consiguió la marca ITIL (derechos de autor y marca registrada). OGC es un departamento del Gobierno de UK que da soporte a la realización de la agenda de compras del gobierno gracias a su trabajo en alianzas de contratación y de sus elevados niveles de aptitudes y habilidades de compra con distintos departamentos. También proporciona soporte a proyectos complejos para el sector público. Objetivo de Punto de Recuperación [Recovery Point Objective] (RPO) Objetivo de Tiempo de Recuperación [Recovery Time Objective] (RTO) Objetivos del Negocio [Business Objective] Observación Técnica [Technical Observation](TO) Off-shore [Off-shore] Oficina de Comercio del Gobierno [Office of Government Commerce] (OGC) Oficina para la Información del Sector Público [Office of Public Sector Information] (OPSI) to Operaciones de TI [IT Operations] Término Oficina para la Información del Sector Público [Office of Public Sector Information] (OPSI) Definición OPSI licencia el material sujeto a derechos utilizado en las publicaciones relacionadas con ITIL. Existe un departamento del gobierno británico que proporciona acceso online a la legislación británica, licencia la utilización del material sujeto a derechos, gestiona su utilización comercial, mantiene el registro de información gubernamental y proporciona asistencia en relación con las publicaciones oficiales y sus derechos de reproducción. (Estrategia del Servicio) Provisión de Servicios desde el propio país del Cliente. Ver también Off-shore, Near-shore. (Diseño del Servicio) Una Estrategia para responder a una interrupción del Servicio. Las Estrategias comunes son No Hacer Nada, Alternativa Manual, Arreglo Recíproco, Recuperación Gradual, Recuperación Rápida, Recuperación Inmediata. Las Opciones de Recuperación pueden utilizar instalaciones dedicadas, o instalaciones de Terceros compartidas por múltiples Negocios. (Operación del Servicio) Gestión del día a día de un Servicio de TI, un Sistema, u otro Elemento de Configuración. El término Operación se usa también para referirse a una Actividad o Transacción predefinidas. Por ejemplo, la carga de una cinta magnética, la recogida de importes en un punto de venta, o la lectura de datos por una unidad de disco. (Diseño del Servicio) Un acercamiento o diseño para eliminar Downtime planeado de un Servicio TI. Advierta que un Elemento de Configuración puede estar caído mientras el Servicio TI está Disponible. (Operación del Servicio) Una fase en el Ciclo de Vida de un Servicio de TI. La Operación del Servicio Influye varios Procesos y Funciones y es uno de los títulos principales en las publicaciones de ITIL. El nivel inferior de los 3 niveles de la Planificación y Entrega (Estratégico, Táctico, Operacional). Las Actividades Operacionales incluyen la Planificación o entrega del día a día de un Proceso de Negocio o un Proceso de Gestión de un Servicio de TI. El término Operacional puede usarse como sinónimo del término Real. (Operación del Servicio) Actividades desempeñadas por Control de Operaciones de TI, incluyendo Gestión de Consolas, Planificación de Tareas, Backup y Restauración, y Gestión de Salida e Impresión. Operaciones de TI se utiliza también como sinónimo de Operación del Servicio. On-shore [On-shore] Opción de Recuperación [Recovery Option] Operación [Operation] Operación Continua [Continuous Operation] Operación del Servicio [Service Operation] Operacional [Operational] Operaciones de TI [IT Operations]


Pág. 303/321

Operar [Operate] to Paquete de Diseño del Servicio [Service Design Package] Término Operar [Operate] Definición Obtener un rendimiento esperado. Se dice que un Proceso o un Elemento de Configuración Opera, cuando esta proporcionando el resultado requerido. Operar también puede referirse a la realización de una o más Operaciones. Por ejemplo, Operar un ordenador consiste en la realización de las Operaciones diarias que necesita para su rendimiento correcto. (Estrategia del Servicio) La ejecución del día a día, la monitorización y la gestión de los Procesos de Negocio. (Estrategia del Servicio) Análisis de los recursos y restricciones que se tienen para un Servicio de TI para decidir si existen formas alternativas de prestar el Servicio que puedan reducir Costes o mejorar la Calidad. Revisar, Planificar y solicitar Cambios orientados a la obtención de la máxima Eficacia y Eficiencia para un Proceso, Elemento de Configuración, Aplicación, etc. Empresa, entidad legal o cualquier otra institución. Algunos ejemplos de Organizaciones que no son Empresas pueden ser la Organización Internacional de Estándares (ISO) o itSMF. El término Organización se utiliza también para referirse a cualquier entidad que disponga de Personal, Recursos y Presupuesto, como puede ser un Proyecto o una Unidad de Negocio. Ver Organización Internacional de Estandarización (ISO). Operativa del Negocio [Business Operations] Optimización de la Provisión del Servicio [Service Provisioning Optimization] (SPO) Optimizar [Optimise] Organización [Organisation] Organización Internacional de Estándares [International Standards Organisation] Organización Internacional de Estandarización [International Organization for Standardization] (ISO) Outsourcing [Outsourcing] La Organización Internacional de Estandarización (ISO) es el mayor desarrollador de Estándares del mundo. ISO es una organización no gubernamental que constituye una red de los Institutos de Estandarización nacionales de 156 países. Existe mayor información sobre ISO disponible en http://www.iso.org/ (Estrategia del Servicio) Utilización de un Proveedor de Servicios Externo para la gestión de Servicios de TI. Ver también Service Sourcing, Proveedor de Servicio de Tipo III. (Diseño del Servicio) Documento o Documentos que definen todos los aspectos de un Servicio de TI y sus Requerimientos a en cada una de las fases de su Ciclo de Vida. Se realiza un Paquete de Diseño del Servicio por cada Servicio de TI nuevo, Cambio relevante o retirada de Servicio de TI. Paquete de Diseño del Servicio [Service Design Package] Paquete de Nivel de Servicio [Service Level Package] (SLP) to Petición de Cambio [Request for Change] (RFC) Término Paquete de Nivel de Servicio [Service Level Package] (SLP) Definición (Estrategia del Servicio) Nivel definido de Utilidad y Garantía para un determinado Paquete de Servicio. Cada SLP se diseña para cumplir con las necesidades de un determinado Patrón de Actividad de Negocio. Ver Línea de Servicio. (Estrategia del Servicio) Descripción detallada de un Servicio de TI preparado para ser suministrado a los Clientes. Un Paquete del Servicio incluye un Paquete del Nivel de Servicio y uno o más Servicios Esenciales y Servicios Añadidos. (Estrategia del Servicio) Una descripción detallada de un Servicio Principal que puede ser compartido por uno o más Paquetes de Niveles de Servicio. Ver Paquete de Servicio. (Diseño del Servicio) Periodo de tiempo acordado previamente durante el cual un Servicio TI no se encontrará disponible. Las Paradas Planificadas se utilizan para la realización de tareas de mantenimiento, actualizaciones o pruebas. Ver también Ventana de Cambios, Indisponibilidad. (Estrategia del Servicio) Es un perfil de Carga de Trabajo de una o más Actividades de Negocio. Los Patrones de Actividad de Negocio se utilizan para ayudar al Proveedor de Servicios de TI a entender y planificar en función de los diferentes niveles de Actividad del Negocio. Ver también Perfil de Usuario. (Estrategia del Servicio) Un patrón de solicitud de Usuarios para Servicios de TI. Cada Perfil de Usuario incluye uno o más Patrones de Actividad de Negocio. (Estrategia del Servicio) un acercamiento a la gestión de Servicios TI, Procesos, Funciones, Activos, etc. Puede haber varias Perspectivas de Control diferentes para un mismo Servicio TI, Procesos, etc., permitiendo a diferentes individuos o equipos enfocarse en lo que es importante y relevante para su Rol específico. Ejemplo de Perspectiva de Control incluye gestión Reactiva y Proactiva dentro de Operaciones TI, o una visión de Ciclo de vida para un equipo de Proyecto de Aplicaciones. (Mejora Continua del Negocio) El entendimiento del punto de vista del Negocio por parte del Proveedor de Servicio y de los Servicios de TI, y un entendimiento del Negocio desde el punto de vista del Proveedor de Servicio. (Transición del Servicio) Propuesta formal para que se realice un Cambio. Una RFC incluye detalles del Cambio propuesto, y puede registrarse en papel o electrónicamente. El término RFC se suele confundir con Registro de Cambio, o con el Cambio en sí. Paquete de Servicio [Service Package] Paquete Principal de Servicio [Core Service Package] (CSP)


Pág. 304/321

Parada Planificada [Planned Downtime] Patrones de Actividad de Negocio [Pattern of Business Activity] (PBA) Perfil de Usuario User Profile ] [(UP) Perspectiva de Control [Control perspective] Perspectiva del Negocio [Business Perspective] Petición de Cambio [Request for Change] (RFC) Petición de Servicio [Service Request] to Planificación Término Petición de Servicio [Service Request] Definición (Operación del Servicio) Petición que hace un Usuario solicitando información, asesoramiento, un Cambio Estándar o Acceso a un Servicio de TI. Por ejemplo, la inicialización de una clave, o provisionar a un nuevo Usuario con Servicios de TI estándares. Las Peticiones de Servicio son normalmente gestionadas por un Centro de Servicio al Usuario, y no requieren que se realice una RFC. Ver Gestión de la Petición. (Transición del Servicio) Despliegue limitado de un Servicio TI, una Versión o un Proceso en el Entorno Real. Los Pilotos se utilizan para reducir el Riesgo así como para obtener respuesta y Aceptación por parte del Usuario. Ver también Prueba, Evaluación. Propuesta detallada que describe las Actividades y Recursos necesarios para la consecución de un Objetivo. Por ejemplo, el Plan para implementar un nuevo Proceso o Servicio de TI. ISO/IEC 20000 requiere un Plan como parte de la gestión de cada Proceso de Servicio de TI. (Diseño del Servicio) El Plan de Capacidad se usa para gestionar los Recursos requeridos para proveer Servicios de TI. El Plan contiene escenarios para distintas predicciones de demanda de Negocio, y las opciones valoradas para proveer los Objetivos de Nivel de Servicio acordados. (Diseño del Servicio) Plan que define los pasos necesarios para Recuperar uno o más Servicios de TI. El Plan además identificará los disparadores de la Invocación del plan, las personas que han de ser involucradas, las comunicaciones necesarias etc. El Plan de Continuidad de los Servicios de TI debería ser parte de un Plan de Continuidad del Negocio. (Diseño del Servicio) Plan que define los pasos que se requieren para el Restablecimiento de los Procesos de Negocio después de una interrupción. El Plan también identifica los disparadores para la Invocación, las personas involucradas, las comunicaciones, etc. El Plan de la Continuidad del Servicio TI es una parte importante de los Planes de Continuidad del Negocio. (Diseño del Servicio) Plan para asegurar que se puede proveer los Requerimientos de Disponibilidad actuales y futuros de los Servicios TI a Costo Efectivo. (Mejora Continua del Servicio) Un Plan formal para implementar mejoras a un Proceso o Servicio de TI. Piloto [Pilot] Plan [Plan] Plan de Capacidad [Capacity Plan] Plan de Continuidad de los Servicios de TI [IT Service Continuity Plan] Plan de la Continuidad del Negocio [Business Continuity Plan] (BCP) Plan de la Disponibilidad [Availability Plan] Plan de Mejora de Servicio [Service Improvement Plan] (SIP) Planificación Es la Actividad responsable de la creación de los Planes. Por ejemplo, la Planificación de Capacidad. Planificación de la Capacidad [Capacity Planning] to Política de Seguridad [Security Policy] Término Planificación de la Capacidad [Capacity Planning] Planificación de Tareas [Job Scheduling] Definición (Diseño del Servicio) Actividad del proceso de Gestión de Capacidad responsable de la creación de un Plan de Capacidad. (Operación del Servicio) Planificación y gestión de la ejecución de las tareas software requeridas como parte de un Servicio de TI. La Planificación de Tareas es realizada por la Gestión de Operaciones de TI, y frecuentemente se encuentra automatizada mediante herramientas software que ejecutan tareas por lotes o en línea en momentos específicos del día, de la semana, del mes o del año. (Transición del Service) El Proceso responsable de la planificación de todos los Procesos de


Pág. 305/321

Transición del Servicio y de la coordinación de los recursos que requiere. Estos Procesos de Transición del Servicio son Gestión del Cambio, Gestión de Activos de Servicio y Gestión de la Configuración, Gestión de Despliegue y Versiones, Validación de Servicio y Prueba, Evaluación y Gestión del Conocimiento. Planificación de Transición y Soporte [Transition Planning and Support] Planificar, Realizar, Comprobar, Actuar [Plan-Do-Check-Act] (Mejora Continua del Servicio) Ciclo de gestión de Procesos en cuatro etapas, atribuido a Edward Deming. Plan-Do-Check-Act es también conocido como el Ciclo de Deming. PLAN: Diseñar o revisar Procesos que soportan Servicios de TI. DO: Implementación del Plan y gestión de los Procesos. CHECK: Medición de los Procesos y de los Servicios de TI, comparación con los Objetivos marcados y generación de informes.. ACT: Planificación e implementación de Cambios para la mejora de los Procesos. Estándar de Gestión de Proyectos mantenido y publicado por el Project Management Institute. PMBOK son las siglas de Project Management Body of Knowledge (Cuerpo de Conocimiento de Gestión de Proyectos). Para más información, consultar http://www.pmi.org/. Ver también PRINCE2. Documento formal que contiene las intenciones y expectativas de gestión. Las Políticas se utilizan para dirigir las decisiones, y asegurar un desarrollo e implementación coherente y apropiado de los Procesos, Estándares, Roles, Actividades, Infraestructura de TI, etc. (Diseño del Servicio) Política que gobierna la visión de la Organización a la Gestión de la Información de Seguridad. PMBOK Política [Policy] Política de Información de Seguridad [Information Security Policy] Política de Seguridad [Security Policy] Sinónimo de Política de Seguridad Informática. Porcentaje de Uso [Percentage utilisation] to Principio de Pareto [Pareto Principle] Término Porcentaje de Uso [Percentage utilisation] Definición (Diseño del Servicio) Cantidad de tiempo que un Componente se encuentra ocupado durante un periodo de tiempo predeterminado. Por ejemplo, si una CPU está ocupada durante 1.800 segundos a lo largo de una hora, su utilización será del 50%. (Estrategia del Servicio) Valor total posible de la suma de todas las Capacidades y Recursos de un Proveedor de Servicios de TI. Se trata de un método de trabajo, o en el que el trabajo debería realizarse. Las Prácticas pueden incluir Actividades, Procesos, Funciones, Estándares y Guías. Ver también Mejores Practicas. (Estrategia del Servicio) Actividad que establece la cantidad que debe ser Cobrada a los Clientes. Es una Actividad que necesita ser completada, o una condición que necesita ser conseguida, para permitir una exitosa implementación del Plan o del Proceso. La PFS es, frecuentemente, un entregable de un Proceso que es requerido como entrada por otro Proceso. (Mejora Continua del Servicio) Proceso responsable de la generación y entrega de los informes de cumplimiento y tendencias de Niveles de Servicio. La Presentación de Informes del Servicio debe acordar con los Clientes el formato, contenido y frecuencia de los informes. La Actividad para predecir y controlar el gasto de dinero. Es un ciclo de negociaciones periódicas para establecer el Presupuesto futuro (normalmente en periodos anuales) y la monitorización y ajustes diarios del Presupuesto actual. Lista de todo el dinero que una Organización o una Unidad de Negocio ha planificado recibir y pagar en un tiempo específico. Ver Presupuesto, Planificación. Metodología de Gestión de Proyectos estándar del gobierno del Reino Unido. Para más información, consultar http://www.ogc.gov.uk/prince2/ Ver también PMBOK. (Operación del Servicio) Técnica utilizada para la asignación de prioridades a diferentes Actividades. El Principio de Pareto dice que el 80% del valor de una Actividad es generado por el 20% del esfuerzo. El Principio de Pareto se usa también en la Gestión de Problemas para priorizar la investigación de posibles causas del Problema. Potencial de Servicio [Service Potential] Práctica [Practice] Precio [Pricing] Prerequisitos para el Éxito [Prerequisite for Success] (PFS) Presentación de Informes del Servicio [Service Reporting] Presupuestar [Budgeting] Presupuesto [Budget]


Pág. 306/321

Principio de Pareto [Pareto Principle] Prioridad [Priority] to Procesos de Relación [Relationship Processes] Término Prioridad [Priority] Definición (Transición del Servicio) (Operación del Servicio) Categoría empleada para identificar la importancia relativa de un Incidente, Problema o Cambio. La Prioridad se basa en el Impacto y la Urgencia, y es utilizada para identificar los plazos requeridos para la realización de las diferentes acciones. Por ejemplo, el SLA podría indicar que los Incidentes de Prioridad 2 deben ser resueltos en menos de 12 horas. (Operación del Servicio) Causa de uno o más Incidentes. En el momento en el que se crea el Registro del Problema, no es frecuente conocer su causa, por lo que es necesario realizar su investigación mediante el Proceso de Gestión de Problemas. Documento que contiene los pasos que se deben seguir para la realización de una determinada Actividad. Los Procedimientos se definen como partes de Procesos. Ver también Instrucción de Trabajo. (Operación del Servicio) Procedimientos empleados por la Gestión de Operaciones de TI. Problema [Problem] Procedimiento [Procedure] Procedimientos de Operación Estándar [Standard Operating Procedures] (SOP) Proceso [Process] Conjunto estructurado de Actividades diseñado para la consecución de un Objetivo determinado. Los Procesos requieren de una o más entradas y producen una serie de salidas, ambas previamente definidas. Un Proceso suele incorporar la definición de los Roles que intervienen, las responsabilidades, herramientas y Controles de gestión necesarios para obtener las salidas de forma eficaz. El Proceso podrá definir las Políticas, Estándares, Guías de Actuación, Actividades, y las Instrucciones de Trabajo que fueran necesarias. Un Proceso que le pertenece y que lo conduce el Negocio. Un Proceso de Negocio contribuye a la entrega de un producto o Servicio para un Cliente del Negocio. Por ejemplo, un revendedor podría tener un Proceso de compra que ayuda a entregar Servicios a sus Clientes del Negocio. Muchos de los Procesos de Negocio están basados en Servicios TI. El nombre usado por ISO/IEC 20000 para el grupo de Proceso que incluye la Gestión de Versión. Este grupo no incluye ningún otro proceso. El Proceso de Versión también se usa como sinónimo del Proceso de Gestión de Versión. Grupo de Procesos ISO/IEC 20000 que incluye Gestión del Cambio y Gestión de Configuración. El grupo de Procesos ISO/IEC 20000 que incluye la Gestión de Relaciones de Negocios y la Gestión de Proveedores. Proceso de Negocio [Business Process] Proceso de Versión [Release Process] Procesos de Control [Control Processes] Procesos de Relación [Relationship Processes] Procesos de Resolución [Resolution Processes] to Proveedor de Servicios de Aplicaciones [Application Service Provider] (ASP) Término Procesos de Resolución [Resolution Processes] pro-forma [pro-forma] Definición El grupo de Proceso ISO/IEC 20000 que incluye la Gestión de Incidentes y la Gestión de Problemas. Plantilla o ejemplo de Documento que contiene datos de ejemplo para ser sustituidos por los valores reales una vez que estos estén disponibles. Conjunto de Proyectos y Actividades planificadas y gestionadas como como una unidad para la obtención de unos Objetivos y Entregables comunes. (Mejora Continua del Servicio) Rol responsable de la entrega de un determinado Servicio de TI. Programa [Programme] Propietario de Servicio [Service Owner] Proveedor [Supplier] (Estrategia del Servicio) (Diseño del Servicio)Tercero responsable de suministrar bienes o Servicios que son necesarios para proporcionar Servicios de TI. Ejemplos de proveedores incluyen los vendedores de hardware y software, proveedores de redes y telecomunicaciones y Organizaciones de Outsourcing. Ver Contrato de Soporte, Cadena de Suministro. (Estrategia del Servicio) Un Proveedor de Servicio Interno que está integrado dentro de una Unidad de Negocio. Puede haber varios Proveedores de Servicio de Tipo I dentro de una Organización. (Estrategia del Servicio) Un Proveedor de Servicio Interno que proporciona Servicios de TI compartidos a más de una Unidad de Negocio. (Estrategia del Servicio) Un proveedor de Servicio que proporciona Servicios de TI a Clientes Externos. Proveedor de Servicio de Tipo I [Type I Service Provider]


Pág. 307/321

Proveedor de Servicio de Tipo II [Type II Service Provider] Proveedor de Servicio de Tipo III [Type III Service Provider] Proveedor de Servicios [Service Provider] (Estrategia del Servicio) Organización que presta Servicios a uno o más Clientes Internos o Clientes Externos. El término de Proveedor de Servicios se usa a menudo como forma abreviada de Proveedor de Servicios de TI. Ver Proveedor de Servicios Tipo I, Proveedor de Servicios Tipo II, Proveedor de Servicios Tipo III. (Diseño del Servicio) Es un Proveedor Externo de Servicios que provee Servicios TI usando Aplicaciones que se ejecutan con recursos del Proveedor de Servicios. Los Usuarios acceden a las Aplicaciones del Proveedor de Servicios por medio de conexiones de red. Proveedor de Servicios de Aplicaciones [Application Service Provider] (ASP) Proveedor de Servicios de TI [IT Service Provider] to Punto Único de Contacto [Single Point of Contact] (SPOC) Término Proveedor de Servicios de TI [IT Service Provider] Proveedor Externo de Servicio [External Service Provider] Definición (Estrategia del Servicio) Proveedor de Servicio que proporciona Servicios de TI a Clientes Internos o Externos. (Estrategia del Servicio) Un Proveedor de Servicio de TI que es parte de una Organización diferente a la de su Cliente. Un Proveedor de Servicio de TI puede tener tanto Clientes Internos como Externos. Ver Proveedor de Servicio de Tipo III (Estrategia del Servicio) Proveedor de Servicio de TI que es parte de la misma Organización que su Cliente. Un Proveedor de Servicio de TI puede tener tanto Clientes Internos como Externos. Ver Proveedor de Servicio de tipo I, Proveedor de Servicio de tipo II, Insource. Un Proveedor Externo de Servicio que proporciona acceso a Internet. La mayoría de los ISP proporcionan también otros Servicios de TI, tales como hosting de páginas web. Proveedor Interno de Servicio [Internal Service Provider] Proveedor Interno de Servicio [Internet Service Provider] (ISP) Proyecto [Project] Se trata de una Organización temporal, compuesta por personal y los Activos requeridos para la obtención de los Objetivos y Entregables necesarios. Cada Proyecto tiene un Ciclo de Vida que típicamente incluye Inicio, Planificación, Ejecución, Cierre etc. Los Proyectos son habitualmente gestionados mediante metodologías formales, como puede ser PRINCE2. Ver PRINCE2 Proyectos en Entornos Controlados [PRojects IN Controlled Environments (PRINCE2)]PRINCE2) Prueba [Test] (Transición del Servicio) Una Actividad que verifica que un Elemento de Configuración, Servicio TI, Proceso, etc. cumple con sus Especificaciones o Requerimientos acordados. Ver Validación y Prueba del Servicio. Aceptación. (Operación del Servicio) Localización física para la cual los Servicios e Infraestructura de TI son monitorizados y gestionados. Puente de Operaciones [Operations Bridge] Punto Único de Contacto [Single Point of Contact] (SPOC) (Operación del Servicio) Proporcionar un único y consistente modo de comunicarse con una Organización o Unidad de Negocio. Por ejemplo, Un SPOC para un Proveedor de Servicios de TI se denomina normalmente Centro de Servicio al Usuario. Punto único de fallo [Single Point of Failure] (SPOF) to Recuperación Inmediata [Intermediate Recovery] Término Punto único de fallo [Single Point of Failure] (SPOF) Definición (Diseño del Servicio) Cualquier Elemento de Configuración que puede causar un Incidente cuando falla y para el que no se ha implementado una Contramedida. Un SPOF puede ser tanto una persona, un paso en un Proceso o Actividad como un Componente de la Infraestructura de TI. Ver Fallo. (Diseño del Servicio) (Mejora continua del Servicio) Un Modelo usado como ayuda para definir roles y responsabilidades. RACI significa Responsable, Confiable, Consultado e Informado. Ver Stakeholder. (Transición del Servicio) Se refiere a aquellos Servicios de TI o Elementos de Configuración empleados para proveer Servicio a un Cliente. (Diseño del Servicio) (Operación del Servicio) Recuperar un Elemento de configuración o un Servicio de TI al estado de funcionamiento. Recuperar un Servicio de TI frecuentemente, incluye la recuperación de datos para llegar un estado consistente. Después de la recuperación otros pasos pueden ser necesarios antes de que los Servicios de TI puedan estar disponibles para los Usuarios (Restauración). (Diseño del Servicio) Una Opción de Recuperación que también es conocida como Reserva fría. Recuperación del Servicio de TI en un período de tiempo superior a 72 horas. La recuperación Gradual normalmente emplea Facilidades Portátiles o Fijas que tienen soporte medioambiental y cableado de Red, pero no Sistemas Informáticos. El hardware y software se instalan dentro del Plan de Continuidad del Servicio de TI. (Diseño del Servicio) Una Opción de Recuperación que también es conocida como Reserva Caliente. Recuperación del Servicio de TI sin pérdida de Servicio. La Recuperación Inmediata normalmente usa tecnologías de espejados, balanceado de carga y distribución de ubicaciones. (Diseño del Servicio) Opción de Recuperación también


Pág. 308/321

conocida como Reserva Medio. Recuperación del Servicio de TI en un periodo de tiempo entre 24 y 72 horas. La recuperación Intermedia emplea normalmente Facilidades Fijas o Portátiles compartidas que contienen Sistemas informáticos y Componentes de Red. El hardware y software necesita ser configurado y los datos deben ser restaurados como parte integrante del Plan de Continuidad del Servicio de TI. RACI [RACI] Real [Live] Recuperación [Recovery] Recuperación Gradual [Gradual Recovery] Recuperación inmediata [Immediate Recovery] Recuperación Inmediata [Intermediate Recovery] Recuperación Rápida [Fast Recovery] to Registro de Activos [Asset Register] Término Recuperación Rápida [Fast Recovery] Definición (Diseño del Servicio) Una Opción de Recuperación que es también conocida como Reserva Caliente. Recuperación del Servicio de TI en un corto período de tiempo, típicamente menos de 24 horas. La Recuperación Rápida normalmente usa una Facilidad Fija dedicada con Sistemas y Software configurado y dispuesto a correr los Servicios de TI. La Recuperación Inmediata puede llevar hasta 24 horas si hay necesidad de Recuperar datos de Copias de Respaldo. (Estrategia del Servicio) Término genérico que incluye Infraestructura de TI, personal, dinero o cualquier otra cosa que pueda ayudar a entregar un Servicio de TI. Se considera a los Recursos como el Activo de una Organización. Ver Capacidad, Activos de Servicio. (Estrategia del Servicio) Un complejo conjunto de Relaciones entro 2 o más grupos u organizaciones. El valor es generado a través del intercambio de conocimiento, información, bienes o Servicios. Ver Cadena de Valor, Sociedad. Sinónimo de Tolerancia a Fallos. El término Redundante también tiene un significado de obsoleto, o de que ya no es necesario. (Mejora Continua del Servicio) Grabar el estado de algo en un punto específico en el tiempo. Una Referencia se puede crear para una Configuración, un Proceso, o cualquier otro conjunto de datos. Por ejemplo, se puede usar una Referencia en: Mejora Continua del Servicio, para establecer el estado actual para gestionar las mejoras. Gestión de la Capacidad, para documentar características de Rendimiento durante la operativa normal. Ver Comparativas, Línea Base. Recurso [Resource] Red de Valor [Value Network] Redundancia [Redundancy] Referencia [Benchmark] Registro [Record] Un Documento que contiene el resultado u otro tipo de salida desde un Proceso o Actividad. Los registros son la evidencia de que una Actividad tuvo lugar, y podría ser en papel o formato electrónico. Por ejemplo, un informe de Auditoría, un Registro de Incidente, o los minutos de una reunión. (Transición del Servicio) Una lista de Activos que incluye dueño y valor. El Registro de Activos lo mantiene la Gestión de Activos. Registro de Activos [Asset Register] Registro de Cambio [Change Record] to Reparación [Repair] Término Registro de Cambio [Change Record] Definición (Transición del Servicio) Registro que contiene los detalles de un Cambio. En cada uno de los Registros de Cambio está documentado el Ciclo de Vida de un Cambio individual. Para cada una de las Peticiones de Cambio se crea y se recibe un Registro de Cambio, incluso aquellos que son rechazados posteriormente. Los Registros de Cambio deberían hacer referencia a los Elementos de Configuración afectados por el Cambio. Los Registros de Cambio se almacenan en el Sistema de Gestión de la Configuración. (Transición del Servicio) Registro que contiene los detalles de un Elemento de Configuración. Cada Registro de Configuración documenta el Ciclo de Vida de un CI individual. Los Registros de Configuración se almacenan en una Base de Datos de Gestión de la Configuración. (Operación del Servicio) Registro que contiene los detalles de un Error Conocido. Cada Registro de Error Conocido documenta el Ciclo de Vida de un Error


Pág. 309/321

Conocido, incluyendo el Estado, la Causa Raíz y la Solución Temporal. En algunas implantaciones, un Error Conocido se documenta empleando campos adicionales de un Registro de Problemas. (Operación del Servicio) Registro que contiene los detalles de un Incidente. Cada registro de Incidencia documenta el Ciclo de Vida de un solo Incidente. (Operación del Servicio) Se trata de un Registro que contiene los detalles de cada Problema ocurrido. Cada Registro de Problemas documenta el Ciclo de Vida de cada Problema individual. (Transición del Servicio) Registro en la CMDB que define el contenido de una Versión. Un Registro de Versión tiene Relación con todos los Elementos de Configuración que se ven afectados por la Versión. Conexión o interacción entre dos personas o cosas. En la Gestión de Relaciones de Negocios es la interacción entre el Proveedor de Servicios de TI y el Negocio. En la Gestión de la Configuración es el enlace entre dos Elementos de Configuración que identifican una dependencia o conexión entre ellos. Por ejemplo, las Aplicaciones pueden ser enlazadas a los Servidores sobre los que corren, los Servicios de TI pueden tener muchos enlaces a todos los CIs que les contribuyen. (Transición del Servicio) Recuperación de un estado conocido tras una Implementación o Cambio fallido. Medida de la respuesta obtenida por un Sistema, persona, equipo, Proceso, o Servicio TI. (Operación del Servicio) El repuesto o corrección de un Elemento de Configuración fallido. Registro de Configuración [Configuration Record] Registro de Error Conocido [Known Error Record] Registro de incidencias [Incident Record] Registro de Problemas [Problem Record] Registro de Versión [Release Record] Relación [Relationship] Remedio [Remediation] Rendimiento [Performance] Reparación [Repair] Requerimiento de Nivel de Servicio [Service Level Requirement](SLR) to Restauración [Restore] Término Requerimiento de Nivel de Servicio [Service Level Requirement](SLR) Requisito [Requirement] Definición (Diseño del Servicio) (Mejora Continua del Servicio) Requerimiento del Cliente para un aspecto de un Servicio de TI. Los SLRs se basan en Objetivos de Negocio y se usan para negociar los Objetivos de Nivel de Servicio acordados. (Diseño del Servicio) Una declaración formal de lo que se necesita. Por ejemplo: un Requisito de Nivel de Servicio, un Requisito de Proyecto, o los Entregables requeridos para un Proceso. Ver Declaración de Requisitos. (Diseño del Servicio) Empleado para referirse a Recursos que no son necesarios para entregar los Servicios de TI en vivo, pero que están disponibles para soportar los Planes de Continuidad de Servicio de TI. Por ejemplo un Centro de datos de Reserva puede mantenerse para soportar Sobre avisos Calientes, Medios o Fríos. Reserva [Standby] Reserva Caliente [Hot Standby] Reserva Fría [Cold Standby] Reserva Medio [Warm Standby] Sinónimo de Recuperación Rápida o Recuperación Inmediata. Sinónimo de Recuperación Gradual. Síntoma para Intermediate Recovery. Resistencia [Resilience] (Diseño del Servicio) La habilidad de un Elemento de Configuración o Servicio de TI a resistir Fallos o de Recuperarse rápidamente tras un Fallo. Por ejemplo, un cable reforzado resistirá fallos cuando esté bajo estrés. Ver Tolerancia a Fallos. (Operación del Servicio) Acción tomada para reparar la Causa Raíz de un Incidente o Problema o para implementar una Alternativa. En ISO/IEC 20000, el Proceso de Resolución es el grupo de Procesos que incluye la Gestión de Problemas e Incidentes. (Operación del Servicio) Una forma de Distribución Automática de Llamadas que acepta entradas del Usuario, tales como presionar una tecla o instrucciones vocales, para identificar el destinatario correcto de Llamadas entrantes. (Operación del Servicio) Toma de acción para restaurar un Servicio de TI a los Usuarios tras Reparar y Recuperarse de un Incidente. Este es el Objetivo Primario de la Gestión de Incidentes. Resolución [Resolution]


Pág. 310/321

Respuesta Interactiva por Voz [Interactive Voice Response] (IVR) Restauración [Restore] Restauración de Servicio [Restoration of Service] to Sensibilidad [Responsiveness] Término Restauración de Servicio [Restoration of Service] Retiro [Retire] Definición Ver Restauración. (Transición del Servicio) Eliminación permanente de un Servicio de TI, u otro Elemento de Configuración, del Entorno Vivo. El Retiro es una fase en el Ciclo de Vida de muchos Elementos de Configuración. (Estrategia del Servicio) (Mejora de Servicio Continua) Medida del beneficio esperado en una inversión. En su significado más sencillo es el provecho neto de una inversión dividida por el valor de los Activos invertidos. Ver Valor Presente Neto, Valor de la Inversión. La evaluación de un Cambio, Problema, Proceso, Proyecto, etc. Las Revisiones habitualmente se llevan a cabo en puntos predefinidos en el ciclo de vida, y especialmente tras la Clausura. El propósito de una Revisión es asegurarse de que todos los Entregables han sido provistos, e identificar oportunidades de mejora. Ver Revisión Post Implementación. Se trata de la Revisión que se realiza tras la implementación de un Cambio o de un Proyecto. La PIR determina si el Cambio o Proyecto se completó con éxito, e identifica nuevos oportunidades de mejora. Un posible Evento que podría causar daño o pérdidas, o afectar la habilidad de alcanzar Objetivos. Un Riesgo es medido por la probabilidad de una Amenaza, la Vulnerabilidad del Activo a esa Amenaza, y por el Impacto que tendría en caso que ocurriera. (Estrategia del Servicio) Técnica empleada para ayudar a las decisiones de Gasto de Capital. IRR calcula un número que permite comparar dos o más inversiones alternativas. Un mayor IRR indica una mejor inversión. Ver Valor Neto Presente, Retorno de Inversión. Conjunto de responsabilidades, Actividades y autorizaciones concedidas a una persona o equipo. Un Rol se define en un Proceso. Una persona o equipo puede tener múltiples Roles, por ejemplo, los Roles de Administrador de Configuración y Administrador del Cambio pueden ser llevados a cabo por una misma persona y de manera individual. Ver Gestión de Seguridad Informática. Medida del tiempo tomado para responder a algo. Podría ser un Tiempo de Respuesta o una Transacción, o la velocidad en la que un Proveedor de Servicio de TI responde a un Incidente o a una Petición de Cambio, etc. Retorno de la Inversión [Return on Investment] (ROI) Revisión [Review] Revision Post Implementacion [Post Implementation Review] (PIR) Riesgo [Risk] Ritmo de Retorno interno [Internal Rate of Return] (IRR) Rol [Role] Seguridad [Security] Sensibilidad [Responsiveness] Separación de Preocupaciones [Separation of Concerns] (SoC) to Servicio Principal [Core Service] Término Separación de Preocupaciones [Separation of Concerns] (SoC) Serviciabilidad [Serviceability] Definición (Estrategia del Servicio) Aproximación al Diseño de una solución o Servicio de TI que divide el problema en partes que pueden ser resueltas de forma independiente. Esta aproximación separa “lo que” se tiene que hacer de “como“ se tiene que hacer. (Diseño del Servicio) (Mejora Continua del Servicio) Habilidad de un Proveedor de Terceros de cumplir los términos de su Contrato. Este Contrato incluye los niveles acordados de Disponibilidad Mantenibilidad y Confiabilidad de un Elemento de Configuración. Un medio de entregar valor a los Clientes facilitando Resultados que los Clientes quieren lograr sin la propiedad de Costes y Riesgos específicos. (Operación del Servicio) Aplicación que gestiona información de la Infraestructura TI disponible en un red, y relacionando Usuarios y Derechos de acceso. Un Servicio de TI que no es usado directamente por el Negocio, pero que es requerido por el Proveedor de Servicio de TI de modo que pueda proporcionar otros Servicios de TI. Por ejemplo Servicios de Directorio, servicios de nombrado o servicios de comunicación. Servicio de TI que sustenta directamente un Proceso de Negocio, en contraposición a un Servicio de Infraestructura que es usado internamente por el Proveedor de Servicios de TI y normalmente no tiene visibilidad hacía el Negocio. El término Servicio de Negocio también se usa para definir un Servicio que se provee a Clientes de Negocio a través de Unidades de Negocio. Por ejemplo la provisión de servicios financieros a Clientes de un banco, o la provisión de bienes a Clientes en una tienda de venta al por menor. La provisión exitosa de Servicios de Negocio a menudo depende de uno o más Servicios de TI. (Estrategia del Servicio) Un Servicio que posibilita o mejora un Servicio Principal. Por ejemplo, un Servicio de Directorio o un Servicio de Respaldo. Ver Paquete de Servicios. Servicio proporcionado a uno o más Clientes por un Proveedor de Servicios de TI. Un Servicio de TI se basa en el uso de las Tecnologías de la Información y soporta los Procesos de Negocio del Cliente. Un Servicio de TI se compone de una combinación de personas, Procesos y tecnología y debería estar definido en un Acuerdo de Nivel de Servicio. (Estrategia del Servicio) Un


Pág. 311/321

Servicio TI que provee Salidas básicas solicitadas por uno o más Clientes. Ver Soporte de Servicio, Paquete Principal de Servicio (Core Service Package). Servicio [Service] Servicio de Directorio [Directory Service] Servicio de Infraestructura [Infrastructure Service] Servicio de Negocio [Business Service] Servicio de Soporte [Supporting Service] Servicio de TI [IT Service] Servicio Principal [Core Service] Servicio Técnico [Technical Service] to Sistema de Gestión de la Calidad [Quality Management System] (QMS) Término Servicio Técnico [Technical Service] Servicios Gestionados [Managed Services] Definición Sinónimo de Servicio de Infraestructura. (Estrategia del Servicio) Perspectiva sobre los Servicios de TI que enfatiza el hecho de que son gestionados. El término Servicios Gestionados se emplea también como sinónimo de Servicios de TI Externalizados. (Operación del Servicio) Ordenador que está conectado a la red y que provee Funciones de software que son usadas por otros ordenadores. (Operación del Servicio) Una metodología para el uso del Centro de Servio al Usuario y los Grupos de Soporte alrededor del Mundo para proporcionar Servicio 24*7. Llamadas, Incidentes, Problemas y Solicitudes de Servicio son pasadas entre grupos en diferentes husos horarios. Número de cosas relacionadas que trabajan juntas para conseguir el Objetivo común. Por ejemplo:

• Un Sistema Informático completo, incluyendo hardware, Software y Aplicaciones. Un sistema de Gestión, incluyendo múltiples Procesos que son planeados y gestionados juntos. Por ejemplo un Sistema de Gestión de la Calidad.

• Un Sistema de Gestión de Bases de Datos o un Sistema Operativo que incluye muchos módulos de software que son diseñados para realizar un conjunto de Funciones relacionadas.

Servidor [Server] Siguiendo al Sol [Follow the Sun] Sistema [System] Sistema de Gestión [Management System] Sistema de Gestión de la Calidad [Quality Management System] (QMS) Marco de trabajo de Políticas, Procesos y Funciones que asegura que una Organización puede alcanzar sus Objetivos. (Mejora Continua del Servicio) Conjunto de Procesos reponsables de asegurar que el trabajo será realizado por una Organización con la Calidad necesaria para satisfacer las necesidades de los Objetivos de Negocio o Niveles de Servicio. Ver ISO 9000. Sistema de Gestión de la Configuración [Configuration Management System] (CMS) to SMART [SMART] Término Sistema de Gestión de la Configuración [Configuration Management System] (CMS) Definición (Transición del Servicio) Conjunto de herramientas y bases de datos usadas para gestionar los datos de Configuración de un Proveedor de Servicios de TI. El CMS también incluye información sobre Incidentes, Problemas, Errores Conocidos, Cambios y Versiones; y puede contener datos sobre empleados, Proveedores, ubicaciones, Unidades de Negocio, Clientes y Usuarios. El CMS consta de herramientas para recopilar, almacenar, gestionar, actualizar, y mostrar datos sobre todos los Elementos de Configuración y sus Relaciones. El CMS es mantenido por Gestión de la Configuración y es usado por todos los Procesos de Gestión de Servicios de TI. Ver Base de Datos de Gestión de la Configuración, Sistema de Gestión del Conocimiento del Servicio (Diseño del Servicio) Marco de Políticas, Procesos, Estándares, Líneas Maestras y herramientas que aseguran que una Organización puede alcanzar sus objetivos en la Gestión de la Seguridad de la Información.


Pág. 312/321

Sistema de Gestión de la Seguridad de Información [Information Security Management System ] (ISMS) Sistema de Gestión del Servicio de Conocimiento [Service Knowledge Management System ](SKMS) (Transición del Servicio) Conjunto de herramientas y bases de datos que se emplean para gestionar el conocimiento y la información. El SKMS incluye tanto el Sistema de Gestión de la Configuración como otras herramientas y bases de datos. El SKMS almacena, gestiona, actualiza y presenta toda la información que un Proveedor de Servicio de TI necesita para gestionar todo el Ciclo de Vida de los Servicios de TI. (Diseño del Servicio) Repositorio virtual de todos los datos del proceso de Gestión de Capacidad, típicamente almacenados en múltiples localizaciones físicas. Ver Sistema de Gestión del Conocimiento del Servicio. Sistema de Información de Gestión de la Capacidad [Capacity Management Information System] (CMIS) Sistema de Información de Gestión de la Disponibilidad [Availability Management Information System] (AMIS) SMART [SMART] (Diseño del Servicio) Repositorio virtual que contiene todos los datos de la Gestión de la Disponibilidad, comúnmente se almacena en múltiples ubicaciones físicas. Ver Service Knowledge Management System. (Diseño del Servicio) (Mejora Continua del Servicio) Acrónimo para ayudar a recordar que los objetivos en los Niveles de Acuerdo de Servicios y Planes de Proyecto deben ser Específicos (Specific), Medibles (Measurable), Alcanzables (Achievable), Relevantes (Relevant) y viables en Tiempo (Timely). Sobrecoste [Overhead] to Stakeholder [Stakeholder] Término Sobrecoste [Overhead] Sociedad [Partnership] Definición Sinónimo de Coste Indirecto Es una relación entre dos Organizaciones que supone una estrecha colaboración entre ambas, orientada a la consecución de objetivos comunes para beneficio mutuo. Un Proveedor de Servicios TI debería tener una relación de Sociedad con el Negocio, así como con aquellas Terceras Partes que sean críticas para proveer los Servicios de TI. Ver también Red de Valor. Solución Temporal que requiere intervención manual. El término Solución Temporal Manual se emplea también como el nombre de una Opción de Recuperación en la que el Proceso de Negocio Opera sin el uso de los Servicios de TI. Ésta es una medida temporal y normalmente se combina con otra Opción de Recuperación. (Operación del Servicio) El primer nivel en una jerarquía de Grupos de Soporte involucrados en la resolución de Incidentes. Cada nivel contiene capacidades más especializadas, o tiene más tiempo u otros Recursos. Ver Escalado. (Operación del Servicio) El Segundo nivel en la jerarquía de Grupos de Soporte envueltos en la resolución de Incidentes e investigación de Problemas. Cada nivel contiene más habilidades especializadas, o tiene más tiempo u otros Recursos. (Operación del Servicio) El tercer nivel en una jerarquía de Grupos de Soporte involucrada en la resolución de Incidentes e investigación de Problemas. Cada nivel contiene capacidades más especializadas, tiene más tiempo u otros Recursos. Sinónimo de Gestión Técnica. Solución Temporal Manual [Manual Workaround] Soporte de Primera línea [First-line Support] Soporte de Segunda Línea [Second-line Support] Soporte de Tercer Nivel [Third-line Support] Soporte Técnico [Technical Support] Soporte temprano [Early Life Support] (Transición del Servicio) Soporte provisto para un Servicio TI Nuevo o Cambiado para un periodo de tiempo, posterior a su Entrega. Durante el Soporte Temprano el Proveedor de Servicio TI puede revisar los KPIs, Niveles de Servicio y Monitorizar Umbrales, y proveer Recursos Adicionales para Incidentes y Gestión de Problemas. Conjunto de personas que tienen interés en una Organización, Proyecto, Servicio de TI, etc. Los Stakeholders pueden interesarse en las Actividades, Objetivos, Recursos o Entregables. Los Stakeholders pueden incluir Clientes, Asociaciones, empleados, shareholders, propietarios, etc. Ver RACI. Stakeholder [Stakeholder] Super Usuario [Super User] to Tiempo medio de caída [Downtime] Término Super Usuario [Super User] Definición (Operación del Servicio) Usuario que ayuda a otros Usuarios y asiste en la comunicación en el Centro de Servicio al Usuario o con otras partes del Proveedor de Servicios de TI. Super Usuarios normalmente proporcionan entrenamiento y soporte para Incidentes menores (Operación del Servicio) Representación gráfica de Resultados generales de Servicios TI y Disponibilidad. Imágenes de resultados pueden ser actualizadas en tiempo real y pueden también ser incluidas en gestión de reportes y páginas web. Esta herramienta puede ser utilizada para ayudar en la Gestión de Niveles de Servicio, Gestión de Eventos o Diagnóstico de Incidentes. El intermedio de los tres niveles de Planificación y entrega (Estratégico, Táctico y Operacional). Las Actividades Tácticas incluyen los Planes a medio plazo requeridos para alcanzar Objetivos específicos, típicamente a lo largo de un periodo de semanas o meses. Uso de la tecnología para el


Pág. 313/321

almacenamiento, comunicación o procesado de información. La tecnología incluye típicamente ordenadores, telecomunicaciones, Aplicaciones y otro software. La información puede incluir datos de Negocio, voz, imágenes, video, etc. La Tecnología de la Información (TI) es a menudo usada para soportar Los Procesos de Negocio a través de Servicios de TI. Una persona, grupo, o Negocio que no es parte del Acuerdo de Nivel de Servicio para un Servicio de TI, pero que es requerida para asegurar el éxito en la entrega de ese Servicio de TI. Por ejemplo, un Proveedor de software, una empresa de mantenimiento de hardware, o el departamento de .... Los requerimientos para los terceros están normalmente especificados en Contratos de Soporte o Acuerdos de Nivel Operacional. (Diseño del Servicio) Documento que especifica los Requerimientos, Alcance, Entregables, Recursos y planificación para un Proyecto o Actividad. (Diseño del Servicio) Sinónimo de Horas de Servicio, se usa frecuentemente en el cálculo de la Disponibilidad. Ver Tiempo Promedio de Reparación. Una medida del tiempo para completar una Operación o Transacción. Usado en la Gestión de Capacidad como medida del Rendimiento, y en la Gestión de Incidentes como una medida del tiempo tomado para contestar una llamada, o iniciar el Diagnóstico. (Diseño del Servicio) (Operación del Servicio) El tiempo en que un Elemento de Configuración o un Servicio TI no está Disponible durante un Tiempo Acordado de Servicio. La Disponibilidad de un Servicio TI es frecuentemente calculado desde el Tiempo Acordado de Servicio y el Downtime. Tablero de resultados [Dashboard] Táctico [Tactical] Tecnología de la Información [Information Technology] (TI) Tercero(s) [Third Party] Términos de Referencia] (TOR) Tiempo Acordado para el Servicio [Agreed Service Time] Tiempo de Respuesta [Response Time] Tiempo medio de caída [Downtime] Tiempo Medio de Reparación [Mean Time To Repair] (MTTR) to Trabajo en Curso [Work in Progress] (WIP) Término Tiempo Medio de Reparación [Mean Time To Repair] (MTTR) Definición Tiempo medio dedicado a reparar un Elemento de Configuración o Servicio de TI tras un Fallo. MTTR se mide desde que el CI o Servicio de TI falla hasta que es Reparado. MTTR no incluye el tiempo necesario para Recuperar o Restaurar. MTTR se emplea algunas veces de forma incorrecta para querer decir Tiempo Medio de Restauración del Servicio. Tiempo medio dedicado a Restaurar un Elemento de Configuración o Servicio de TI tras un Fallo. MTTR se mide desde que el CI o Servicio de TI falla hasta que está completamente Restaurado y dando su funcionalidad normal. Ver Mantenibilidad, Tiempo Medio de Reparación. (Diseño del Servicio) Métrica para medir y reportar la Fiabilidad. MTBF es el tiempo medio que un Elemento de Configuración o Servicio de TI puede realizar su Función concertada sin interrupción. Se mide desde que el CI o Servicio de TI empieza a funcionar, hasta que falla la siguiente vez. (Diseño del Servicio) Métrica para medir y reportar la Fiabilidad. MTBSI es el tiempo medio desde que un Sistema o Servicio de TI falla, hasta que falla la siguiente vez. MTBSI es igual a MTBF + MTRS. Tiempo Medio de Restauración del Servicio [Mean Time to Restore Service] (MTRS) Tiempo Medio entre Fallos [Mean Time Between Failures] (MTBF) Tiempo Medio entre Incidentes de Servicio [Mean Time Between Service Incidents] (MTBSI) Tipo de Coste [Cost Type] (Estrategia del Servicio) la categoría de más alto nivel al cual los Costes son asignados en el Presupuesto y la Contabilidad. Por ejemplo hardware, software, recursos humanos, instalaciones, costes externos y de Transferencia. Ver Elementos de Costes, Tipo de Coste. (Transición del Servicio) Categoría que se usa para Clasificar CIs. El Tipo de Elemento de Configuración identifica los Atributos y Relaciones requeridas para un Registro de Configuración. Tipos de Elementos de Configuración comunes son: hardware, Documento, Usuario etc. (Operación del Servicio) Categoría usada para la distinción entre peticiones realizadas a un Centro de Servicio al Usuario. Tipos de Llamada habituales son Incidente, Petición de Servicio y Reclamación. (Diseño del Servicio) Habilidad de un Servicio de TI ó Elemento de Configuración para continuar su Operación correcta tras el Fallo de un Componente. Ver Resistencia, Contramedida. Un Estado que significa que las Actividades han comenzado pero no están completadas. Es usado comúnmente como Estado para Incidentes, Problemas, Cambios etc. Tipo de Elemento de Configuración [CI Type] Tipo de Llamada [Call Type]


Pág. 314/321

Tolerancia a Fallos [Fault Tolerance] Trabajo en Curso [Work in Progress] (WIP) Transacción [Transaction] to Unidad de Negocio [Business Unit] Término Transacción [Transaction] Definición Una Función discreta realizada por un Servicio de TI. Por ejemplo, transferir dinero de una cuenta bancaria a otra. Un transacción simple puede involucrar numerosas adiciones, borrados y modificaciones de datos. Bien todas se completan con éxito o ninguna es realizada. (Transición del Servicio) Un cambio de estado, correspondiente al movimiento de un Servicio de TI u otro Elemento de Configuración de un estado en su Ciclo de Vida a otro. (Transición del Servicio) Uno de los estados del Ciclo de Vida de un Servicio de TI. La Transición del Servicio incluye varios Procesos y Funciones y es el título de uno de los libros Esenciales de ITIL. Ver Transición. (Operación del Servicio) Grupo o equipo de personas que realizan un Rol específico durante un periodo de tiempo fijo. Por ejemplo puede haber cuatro turnos de personal de Control de Operaciones de TI para soportar un Servicio de TI necesario las 24 horas del día. El valor de una Métrica que debe causar la generación de una Alerta, o que se tome una acción de gestión. Por ejemplo, “un incidente de prioridad 1 no resuelto en 4 horas”, “más de 5 errores leves de disco en una hora”, o “más de 10 cambios fallidos en un mes”. (Estrategia del Servicio) la categoría de nivel más bajo al cual los Costes son asignados, Unidad de Costes son usualmente cosas que pueden ser contadas fácilmente (por ej. Cantidad de personas, licencias de software) o cosas fácilmente medibles (por ej. uso de CPU, consumo de electricidad). Unidad de Coste son incluidas dentro de los Elementos de Costes, por ejemplo como un Elemento de Coste de “Gastos generales” puede incluirse la Unidad de Coste de Hoteles, Transporte, Comidas etc. Ver Tipo de Coste. (Transición del Servicio) Componentes de un Servicio de TI que normalmente son Implementados juntos. Una Unidad de Implementación habitualmente incluye suficientes Componentes para realizar una Función útil. Por ejemplo, una Unidad de Implementación podría ser un PC de Sobremesa, incluyendo Hardware, Software, Licencias, Documentación, etc. Una Unidad de Implementación distinta podría ser la Aplicación de Nóminas, incluyendo los Procedimientos de Operaciones de TI y la formación del Usuario. (Estrategia del Servicio) Segmento del Negocio que tiene sus propios Planes, Métricas, ingresos y Costes. Cada Unidad de Negocio posee Activos y los usa para crear valor para sus Clientes en forma de bienes y Servicios. Transición [Transition] Transición del Servicio [Service Transition] Turno [Shift] Umbral [Threshold] Unidad de Coste [Cost Unit] Unidad de Implementación [Release Unit] Unidad de Negocio [Business Unit] Urgencia [Urgency] to Valor en Inversión [Value on Investment] (VOI) Término Urgencia [Urgency] Definición (Transición del Servicio) (Diseño del Servicio) Una medida de del tiempo en que un Incidente, Problema o Cambio tendrá un Impacto significativo para el Negocio. Por ejemplo, un Incidente de alto Impacto puede tener una Urgencia baja, si el Impacto no afectará al Negocio hasta el final del año financiero. Impacto y Urgencia se emplean para asignar la Prioridad. (Diseño del Servicio) La facilidad mediante la cual una Aplicación, producto o Servicio de TI puede usarse. Los Requerimientos de uso se incluyen a menudo en una Declaración de Requerimientos. Una persona que usa el Servicio de TI diariamente. Los usuarios son distintos a los Clientes, dado que algunos Clientes no usan el Servicio de TI directamente. Usabilidad [Usability] Usuario [User] Utilidad [Utility] (Estrategia del Servicio) Funcionalidad ofrecida por un Producto o Servicio para satisfacer una necesidad específica. La utilidad es a menudo resumida en “lo que hace”. Ver Utilidad de Servicio. (Estrategia del Servicio) Funcionalidad de un Servicio de TI desde la perspectiva del Cliente. El valor de Negocio de un Servicio de TI se crea por


Pág. 315/321

la combinación de la Utilidad del Servicio (lo que el Servicio hace) y la Garantía del Servicio (como de bien lo hace). Ver Utilidad. (Transición del Servicio) Una Actividad que asegura que un Servicio de TI, Proceso, Plan u otro Entregable nuevo o cambiado satisface las necesidades del Negocio. La Validación asegura que los Requerimientos de Negocio son satisfechos incluso aunque estos sean cambiados desde su diseño original. Ver Verificación, Aceptación, Cualificación, Validación y Prueba del Servicio. (Transición del Servicio) Proceso responsable de la Validación y Pruebas de un Servicio de TI nuevo o con Cambios. La Validación y Pruebas del Servicio se asegura de que un Servicio de TI cumple sus Especificaciones de Diseño y satisface las necesidades del Negocio. (Estrategia del Servicio) Técnica empleada para ayudar a tomar decisiones sobre el Gasto de Capital. El VAN compara la entrada de efectivo con la salida de efectivo. Un VAN positivo indica que una inversión merece la pena. Ver Ratio Interno de Retorno, Retorno de la Inversión. (Mejora Continua del Servicio) Una medida del beneficio esperado de una inversión. VOI considera tanto los beneficios financieros como intangibles. Ver Retorno de la Inversión. Utilidad del Servicio [Service Utility] Validación [Validation] Validación y Pruebas del Servicio [Service Validation and Testing] Valor Actual Neto [Net Present Value] (NPV) Valor en Inversión [Value on Investment] (VOI) Valor por Dinero [Value for Money] to Término Valor por Dinero [Value for Money] Definición Una medida informar de la Efectividad de Costes. Valor por Dinero está a menudo basado en la comparación con el Coste de las alternativas. Ver Análisis Coste Beneficio. (Estrategia del Servicio) Medición del Coste total que supone la prestación de un Servicio de TI, y el valor total que tiene ese Servicio de TI para el Negocio. La Valoración del Servicio se usa para facilitar el acuerdo acerca del valor del Servicio de TI entre el Negocio y el Proveedor de Servicios de TI. La diferencia entre un valor previsto y el valor real medido. Usada comúnmente en Gestión Financiera, Gestión de la Capacidad y Gestión del Nivel de Servicio, pero puede aplicarse en cualquier área donde se empleen planes. Sinónimo de Ventana de Cambio. Valoración del Servicio [Service Valuation] Varianza [Variance] Ventana de Versión [Release Window] Ventana para el Cambio [Change Window] (Transición del Servicio) Tiempo acordado para el cual los Cambios o Entregas pueden ser implementados con un impacto mínimo sobre los Servicios. Las Ventanas para el Cambio normalmente están documentadas en los SLAs. (Transición del Servicio) Una Actividad que asegura que un Servicio de TI, Proceso, Plan u otro Entregable nuevo o cambiado, es completo, preciso, Confiable y está de acuerdo con su Especificación de Diseño. Ver Validación, Aceptación, Validación y Prueba del Servicio. (Transición del Servicio) Las Actividades responsables de asegurar que la información en la CMDB es precisa y que todos los Elementos de Configuración está identificados y registrados en la CMDB. La Verificación incluye comprobaciones rutinarias que son parte de otros Procesos. Por ejemplo, verificar el número de serie de un PC cuando un Usuario registra un Incidente. La Auditoría es una comprobación periódica y formal. (Transición del Servicio) Colección de hardware, software, documentación, Procesos, u otros Componentes requeridos para implementar uno o más Cambios aprobados a los Servicios de TI. Los contenidos de cada Versión son Administrados, Probados, e Implementados como una única entidad. (Transición del Servicio) Una Versión se usa para identificar una Línea Base específica o un Elemento de Configuración. Normalmente emplean una convención de nombrado que posibilita identificar la secuencia o fecha de cada línea base. Por ejemplo Aplicación de Nóminas Versión 3 contiene funcionalidades actualizadas de la Versión 2. Verificación [Verification] Verificación y Auditoría [Verification and Audit] Versión [Release] Versión [Version]


Pág. 316/321

Visión [Vision] to Vulnerabilidad [Vulnerability] Término Visión [Vision] Definición Una descripción de lo que la Organización intenta ser en el futuro. Una Visión es creada por el Equipo Directivo y se usa para influir en la Cultura y la Planificación Estratégica. (Diseño del Servicio) La fase de un Plan de Continuidad de Servicio de TI durante el cual se resumen operaciones normales completas. Por ejemplo, si un centro de información suplente ha estado en uso, entonces esta fase recuperará la información primaria, y restaurará la habilidad de invocar Planes de Continuidad de Servicios de TI una vez más. Una debilidad que puede ser aprovechada por una Amenaza. Por ejemplo un puerto abierto en el cortafuegos, una clave de acceso que no se cambia, o una alfombra inflamable. También se considera una Vulnerabilidad un Control perdido. Vuelta a la Normalidad [Return to Normal] Vulnerabilidad [Vulnerability] ASP: Proveedor de Servicios de Aplicaciones Back-out: Proceso de retirada de una versión ya desplegada Back-up: Copias de seguridad BCN: Gestión de la Capacidad del Negocio BCM: Gestión de la Continuidad del Servicio BIA: Análisis de impacto en el negocio CAB: Comité Asesor del Cambio CCM: Gestión de la Capacidad de Recursos CDB: Base de Datos de la Capacidad CFIA: Análisis del Impacto de Fallo de Componentes CI: Elemento de Configuración CIs: Elementos de Configuración CMDB: Base de Datos de la Gestión de Configuraciones CMI: Cuadro de Mando Integral CMIS: Sistema de Información de Gestión de la Capacidad CMS: Sistema de Gestión de la Configuración CRAMM: Método de Gestión y Análisis de Riesgos de la CCTA CRM: CSFs: Factores Críticos de Éxito CSI: Mejora Continua del Servicio CSP: Paquete de Servicio Esencial DAFO: Fortalezas, Debilidades, Oportunidades y Amenazas


Pág. 317/321

DML: Biblioteca de Medios Definitivos DS: Repuestos Definitivos ECAB: Comité Asesor de Cambios de Emergencia ELS: Soporte post-implantación FAQs: Preguntas Frecuentes FSC: Calendario del Cambios FTA: Análisis del Árbol de Fallos GTB: Inversiones de crecimiento del negocio ISMS: Gestión de la Seguridad de la Información ISPs: Proveedores de Servicios de Internet ITIL: Biblioteca de la Infraestructura de Tecnología de Información ITSCM: Gestión de la Continuidad de los Servicios de TI KB: Base de Conocimiento KEDB: Base de Datos de Errores Conocidos KPIs: Indicadores Críticos de Rendimiento LOPD: Ley Orgánica de Protección de Datos MTBF: Tiempo Medio entre Fallos MTBSI: Tiempo Medio entre Incidencias del Servicio MTTR: Tiempo Medio de Reparación M_o_R: Gestión de Riesgos OLA: Acuerdos de Nivel de Operación OLAs: Acuerdos de Nivel de Operación PBAs: Patrones de Actividad del Negocio PIR: Revisión Post-Implantación PSA: Disponibilidad de Servicio Prevista PSO: Parada de Servicio Prevista RACI : Encargado-Responsable-Consultado-Informado RASCI: Encargado-Responsable-Soporte-Consultado-Informado


Pág. 318/321

RCA: Análisis de la Causa Raíz RFC: Petición de Cambio RFCs: Peticiones de Cambio ROI: Retorno de la inversión RTB: Inversiones para mantener el negocio SACs: Criterios de Aceptación del Servicio SCD: Base de Datos de Proveedores y Contratos SCM: Gestión de la Capacidad del Servicio SDP: Paquete de Diseño del Servicio SIP: Plan de Mejora del Servicio SKMS: Sistema de Gestión del Conocimiento del Servicio SLA: Acuerdos de Nivel de Servicio SLAs: Acuerdos de Nivel de Servicio SLM: Responsable del Nivel del Servicio SLP: Paquete de Nivel del Servicio SLRs: Requisitos del Nivel del Servicio SOA: Análisis de Interrupción del Servicio SP: Paquete de Servicio SPs: Paquetes del Servicio SQP: Plan de Calidad del Servicio SSIP: Plan de Mejora de Proveedor de Servicios SWOT: Fortalezas, Debilidades, Oportunidades y Amenazas TCO: Coste Total de Propiedad TTB: Inversiones para transformar el negocio UC : Contrato de Soporte UCs: Contratos de Soporte VBF: Función Vital para el Negocio VOI: Valor de la Inversión


Pág. 319/321

BBBIIIOOOGGGRRRAAAFFFÍÍÍAAASSS CCCOOONNNSSSUUULLLTTTAAADDDAAASSS

Documentación de referencia ITIL: www.itil.co.uk/ COBIT: www.isaca.org/Template.cfm?Section=COBIT_ Online&TEmplate=/ContentManagement/ContentDisplay. cfm&ContentID=15633 BS ISO/IEC 20000-1:2005 y BS ISO/IEC 20000-2:2005: www.bsi-global.com/ICT/Service/bs15000-1.xalter Diferencias entre la BS 15000 la BS ISO/IEC 20000: www.bsi-global.com/ICT/Service/bip0039.xalter ISO 20000 Parte 1: www.bsi-global.com/ICT/Service/ bs15000-1.xalter ISO 20000 Parte 2: www.bsi-global.com/ICT/Service/ bs15000-2.xalter


Pág. 320/321

TTTaaabbblllaaa dddeee cccooonnnttteeennniiidddooo:::

Contenido

IIINNNTTTRRROOODDDUUUCCCCCCIIIÓÓÓNNN::: 222

CCCOOONNNTTTEEENNNIIIDDDOOO::: 444

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII ::: 555

GGGOOOBBBIIIEEERRRNNNOOO TTTIII 777

EEELLL CCCIIICCCLLLOOO DDDEEE VVVIIIDDDAAA DDDEEE LLLOOOSSS SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII 888

FFFUUUNNNCCCIIIOOONNNEEESSS,,, PPPRRROOOCCCEEESSSOOOSSS YYY RRROOOLLLEEESSS 999

OOOttt rrrooo cccooonnnccceeeppptttooo aaammmppplll iiiaaammmeeennnttteee uuuttt iii lll iii zzzaaadddooo eeesss eeelll dddeee rrrooolll ... 999

AAAPPPÉÉÉNNNDDDIIICCCEEE::: DDDEEE IIITTTIIILLL VVV222 AAA IIITTTIIILLL VVV333 111000

DDDEEESSSAAARRRRRROOOLLLLLLAAARRR EEESSSTTTRRRAAATTTEEEGGGIIIAAASSS DDDEEE LLLOOOSSS SSSEEERRRVVVIIICCCIIIOOOSSS... 111666

CCCRRREEEAAACCCIIIÓÓÓNNN DDDEEE VVVAAALLLOOORRR 111777

AAACCCTTTIIIVVVOOOSSS DDDEEELLL SSSEEERRRVVVIIICCCIIIOOO 111888

PPPRRROOOVVVEEEEEEDDDOOORRREEESSS DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 111999

RRREEEDDDEEESSS DDDEEE VVVAAALLLOOORRR 222000

LLLAAASSS 444 PPP DDDEEE LLLAAA EEESSSTTTRRRAAATTTEEEGGGIIIAAA 222111

LLLooosss ppplllaaannneeesss dddeeebbbeeennn dddeee eeessstttaaabbbllleeeccceeerrr uuunnnaaa hhhooojjjaaa dddeee rrruuutttaaa pppaaarrraaa aaalllcccaaannnzzzaaarrr lllooosss ooobbbjjjeeettt iii vvvooosss gggeeennneeerrraaallleeesss eeessstttaaabbbllleeeccciiidddooosss... 222111

PPPRRROOOCCCEEESSSOOOSSS 222222

GGGEEESSSTTTIIIÓÓÓNNN FFFIIINNNAAANNNCCCIIIEEERRRAAA 222444

VVViiisss iiióóónnn gggeeennneeerrraaalll 222444

IIInnntttrrroooddduuucccccciiióóónnn yyy ooobbbjjjeeetttiiivvvooosss 222444

CCCOOOSSSTTTEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII 222888

VVVaaalllooorrr dddeee ppprrrooovvviiisss iiióóónnn 222888

VVVaaalllooorrr pppooottteeennnccciiiaaalll dddeeelll ssseeerrrvvviiiccciiiooo 222888

RRReeetttooorrrnnnooo dddeee lllaaa iiinnnvvveeerrrsssiiióóónnn (((RRROOOIII))) 222888

DDDiiinnnááámmmiiicccaaa dddeee cccooosssttteeesss vvvaaarrr iiiaaabbbllleeesss (((VVVCCCDDD))) 222888

PPPrrreeesssuuupppuuueeessstttooosss 222999

CCCooonnntttaaabbbiii lll iiidddaaaddd 333000

PPPooolll íííttt iiicccaaa dddeee PPPrrreeeccciiiooosss 333000

SSSuuupppeeerrrvvviiisss iiióóónnn fff iiinnnaaannnccciiieeerrraaa 333111

CCCooonnntttrrrooolll dddeeelll ppprrroooccceeesssooo 333111

GGGEEESSSTTTIIIÓÓÓNNN DDDEEELLL PPPOOORRRTTTFFFOOOLLLIIIOOO DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 333444


Pág. 321/321



PPPrrroooccceeesssooo 333555

DDDeeefffiiinnniiiccciiióóónnn dddeeelll nnneeegggoooccciiiooo 333666

AAAnnnááálll iiisss iiisss dddeee ssseeerrrvvviiiccciiiooosss 333666

AAAppprrrooobbbaaaccciiióóónnn dddeee ssseeerrrvvviiiccciiiooosss 333777

PPPlllaaannniiifff iiicccaaaccciiióóónnn yyy aaaccctttuuuaaalll iiizzzaaaccciiióóónnn dddeeelll PPPooorrrtttfffooolll iiiooo 333777

CCCaaatttááálllooogggooo dddeee SSSeeerrrvvviiiccciiiooosss 333888

FFFllluuujjjooo dddeee CCCrrreeeaaaccciiióóónnn dddeee SSSeeerrrvvviiiccciiiooo 333888

SSSeeerrrvvviiiccciiiooosss RRReeetttiiirrraaadddooosss 333888

CCCooonnntttrrrooolll dddeeelll ppprrroooccceeesssooo 333888

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA DDDEEEMMMAAANNNDDDAAA 333999



CCCooonnnccceeeppptttooosss bbbááásssiiicccooosss 444000

PPPaaaqqquuueeettteee dddeee NNNiiivvveeelll dddeee SSSeeerrrvvviiiccciiiooo (((SSSLLLPPP))) 444000

PPPaaaqqquuueeettteee dddeee SSSeeerrrvvviiiccciiiooo EEEssseeennnccciiiaaalll (((CCCSSSPPP))) 444000

AAAnnnááálll iiisss iiisss dddeee aaaccctttiiivvviiidddaaaddd 444111

DDDeeesssaaarrrrrrooolll lllooo dddeee lllaaa ooofffeeerrrtttaaa 444222

PPPuuueeessstttaaa eeennn MMMaaarrrccchhhaaa 444333

OOOrrrgggaaannniiizzzaaaccciiióóónnn 444444

TTTEEECCCNNNOOOLLLOOOGGGÍÍÍAAA 444666

EEESSSTTTRRRAAATTTEEEGGGIIIAAASSS DDDEEE EEEXXXTTTEEERRRNNNAAALLLIIIZZZAAACCCIIIÓÓÓNNN DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 444777

FFFAAACCCTTTOOORRREEESSS DDDEEE ÉÉÉXXXIIITTTOOO YYY RRRIIIEEESSSGGGOOOSSS 444888

RRREEELLLAAACCCIIIÓÓÓNNN CCCOOONNN OOOTTTRRROOOSSS CCCIIICCCLLLOOOSSS 444999

111... EEESSSTTTRRRAAATTTEEEGGGIIIAAA YYY DDDIIISSSEEEÑÑÑOOO 444999

222... EEESSSTTTRRRAAATTTEEEGGGIIIAAA YYY TTTRRRAAANNNSSSIIICCCIIIÓÓÓNNN 444999

333... EEESSSTTTRRRAAATTTEEEGGGIIIAAA YYY OOOPPPEEERRRAAACCCIIIÓÓÓNNN 444999

444... EEESSSTTTRRRAAATTTEEEGGGIIIAAA YYY MMMEEEJJJOOORRRAAA CCCOOONNNTTTIIINNNUUUAAA 444999

PPPRRRIIINNNCCCIIIPPPIIIOOOSSS DDDEEELLL DDDIIISSSEEEÑÑÑOOO DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 555333

MMMOOODDDEEELLLOOOSSS DDDEEE DDDIIISSSEEEÑÑÑOOO 555555

GGGEEESSSTTTIIIÓÓÓNNN DDDEEELLL CCCAAATTTÁÁÁLLLOOOGGGOOO DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS 555777


Pág. 322/322

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE NNNIIIVVVEEELLLEEESSS DDDEEE SSSEEERRRVVVIIICCCIIIOOO 666222

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA CCCAAAPPPAAACCCIIIDDDAAADDD 777000

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA DDDIIISSSPPPOOONNNIIIBBBIIILLLIIIDDDAAADDD 777777

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA CCCOOONNNTTTIIINNNUUUIIIDDDAAADDD DDDEEE SSSEEERRRVVVIIICCCIIIOOOSSS TTTIII 888444

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE LLLAAA SSSEEEGGGUUURRRIIIDDDAAADDD DDDEEE LLLAAA IIINNNFFFOOORRRMMMAAACCCIIIÓÓÓNNN 999222

GGGEEESSSTTTIIIÓÓÓNNN DDDEEE PPPRRROOOVVVEEEEEEDDDOOORRREEESSS 999888

PPPUUUEEESSSTTTAAA EEENNN MMMAAARRRCCCHHHAAA 111000222

BBBIIIOOOGGGRRRAAAFFFÍÍÍAAASSS CCCOOONNNSSSUUULLLTTTAAADDDAAASSS 333111999

TTTaaabbblllaaa dddeee cccooonnnttteeennniiidddooo::: 333222000

Manual técnico de ITIL vs 3.0 en Español

Technology

Transcript of Manual técnico de ITIL vs 3.0 en Español